译文
译自西班牙语原文，以原文为规范文本。 状态：草稿，待人工审校。如有歧义，以西班牙语原文为准。
SCAFFOLD 0.1：要求
已接受版本——2026 年 10 月 13 日；2026 年 10 月 14 日补全。 现行有效的要求共 31 条：
SCAFFOLD-R-001 至 SCAFFOLD-R-016，以及 SCAFFOLD-R-018 至 SCAFFOLD-R-032。
人工接受决定。
西班牙语文本具有规范效力。
按项目阶段划分的要求
各卡片的通用字段
这些字段适用于本页中每一张已接受的卡片。必须、不得、应当 与 可以 的含义遵循规范性用语，该用语由 SCAFFOLD 0.1 采用，且未修改 ASILO 或 MILPA。
| 字段 |
值 |
| 状态与版本 |
accepted · SCAFFOLD 0.1 · R-001 至 R-016 及 R-018 自 2026 年 10 月 13 日起；R-019 至 R-032 自 2026 年 10 月 14 日起。 |
| 类别 |
与技术无关的工程要求。R-019 至 R-032 还涵盖软件项目管理，并且与跟踪工具和代码托管服务无关。 |
| 一般范围 |
在声明采用 SCAFFOLD 0.1 的仓库中构建软件的人员与助手。R-019 至 R-032 另适用于该软件的规划、集成与交付，依据负责人于 2026 年 10 月 14 日的决定。 |
| 例外 |
人类负责人记录原因、范围、期限、风险、回滚方案和复审日期。R-012 与 R-013 规定了特定程序；它们不免除 ASILO/MILPA。偏离某项应当要求，必须记录理由并接受相应风险。 |
| 来源 |
SCAFFOLD 自有的编辑语料，经已登记的人工决定整合进 0.1 版本。“依据”字段保留与 ASILO 0.1 和 MILPA 0.1 的关系，但不构成对二者的修订。 |
| 接受证据 |
人工决定，以及方法仓库中单独的登记文件 reference/scaffold-accepted-0.1-sha256.json。 |
| 未来决定 |
修订需要新的已标识版本和人工决定；修订案 R-017 不在本版本之内。 |
每张卡片补充问题、范围与适用条件、人类责任人、可验证的表述、预期证据、残余风险和依据。项目须指明由谁担任这些角色。阅读卡片时须结合这些通用字段。
卡片中提到的角色
角色是职责，不是职位。同一个人可以担任多个角色；在一人项目中，该人担任全部角色。智能体不担任任何角色。
| 角色 |
负责 |
| 产品负责人 |
目标、项目章程、工作清单的排序，以及对已完成工作的验收。 |
| 协调负责人 |
区域、节奏、小组、分配和定期回顾。 |
| 技术负责人 |
架构、契约、分支模型、依赖和技术现状盘点。 |
| 交付负责人 |
环境、制品晋级、部署、回滚和发布版本。 |
| 批次负责人 |
某一具体批次：区域、助手、交接和结果。 |
| 小组负责人 |
一个由人员、智能体或两者混合组成的小组，以及对其智能体的监督。 |
R-001 至 R-018 的卡片以任务来指称其责任人（“负责……的人”）。项目须指明各卡片由哪个角色担任；若未指明，则由协调负责人负责。
SCAFFOLD-R-001
| 字段 |
内容 |
| 问题 |
写入冲突。 |
| 范围与适用条件 |
助手修改的每一条路径。 |
| 责任人 |
仓库的协调负责人。 |
| 可验证的表述 |
一条路径不得有多于一个已声明的写入所有者。共享路径必须声明为共享，并附上项目确定的轮换规则。 |
| 预期证据 |
区域地图、所有者或共享轮换，以及变更涉及的路径。 |
| 残余风险 |
工具可能无视该地图。 |
| 依据 |
引用：清单中的受限区域（MILPA-R-004）。新增：按路径的所有者与轮换。 |
SCAFFOLD-R-002
| 字段 |
内容 |
| 问题 |
缺乏协调的跨区变更。 |
| 范围与适用条件 |
一项变更涉及多个所有者的区域。 |
| 责任人 |
批次负责人。 |
| 可验证的表述 |
涉及多于一个所有者区域的变更，必须在一个批次中进行，该批次须列明这些区域和一名负责人。 |
| 预期证据 |
带有区域、负责人和相关变更的批次。 |
| 残余风险 |
指定负责人并不能避免错误的合并。 |
| 依据 |
引用：执行期间不可扩大范围（ASILO-R-004）。新增：以批次作为跨区变更的单位。 |
SCAFFOLD-R-003
| 字段 |
内容 |
| 问题 |
变更没有归属。 |
| 范围与适用条件 |
SCAFFOLD 范围内的所有变更。 |
| 责任人 |
变更负责人。 |
| 可验证的表述 |
每项变更必须能够归属到一名负责人；若有助手参与，还须归属到产出该变更的助手。 |
| 预期证据 |
记录有参与的人员和助手的变更记录。 |
| 残余风险 |
所声明的归属可能是虚假或不完整的。 |
| 依据 |
相关：作为规则、要求、原则或决定提出的陈述的来源（MILPA-R-001）。新增：变更的归属。 |
SCAFFOLD-R-004
| 字段 |
内容 |
| 问题 |
启动时引用了不存在的内容，或上下文过多。 |
| 范围与适用条件 |
为有助手参与的任务准备初始上下文。 |
| 责任人 |
任务上下文负责人。 |
| 可验证的表述 |
仓库应当声明一份启动上下文：即助手最先阅读的、现行有效工件的简短清单。被引用的内容必须存在。每项任务仍受其自身上下文预算的约束，包括数据最高分类和有效期。 |
| 预期证据 |
入口清单、引用的存在性，以及该任务的预算。 |
| 残余风险 |
现行有效的工件可能包含不正确的信息。 |
| 依据 |
相关：按任务划分的上下文预算，不在任务之间复用（ASILO-R-003）。新增：每份预算可纳入的入口目录。 |
SCAFFOLD-R-005
| 字段 |
内容 |
| 问题 |
更换助手时工作丢失或被改动。 |
| 范围与适用条件 |
在一个批次内更换助手。 |
| 责任人 |
批次负责人，并明确交出方和接收方。 |
| 可验证的表述 |
在批次内更换助手时，交出方必须留下一份交接说明，包含指南中的字段和一个状态。已被领取的说明不得编辑；若目标改变，须说明理由后取消并另开一份。更换工具并不带来权限或连续性。 |
| 预期证据 |
字段完整的说明、状态、历史，以及领取时的指纹。 |
| 残余风险 |
一份完整的说明可能错误描述实际状态。 |
| 依据 |
无已接受依据：上下文指南将交接描述为说明性技术，而非标准。新增：义务、状态、由接收方领取，以及领取后不得编辑。 |
SCAFFOLD-R-006
| 字段 |
内容 |
| 问题 |
契约、架构与代码互不兼容。 |
| 范围与适用条件 |
维护或修改其中某一工件。 |
| 责任人 |
这些工件的技术负责人。 |
| 可验证的表述 |
契约、架构图和代码必须声明各自对应的版本，并且仓库应当能够检查：其中之一的变更不会在无提示的情况下使另一方过时。 |
| 预期证据 |
对应的版本和检查结果，或偏离该应当要求的理由。 |
| 残余风险 |
已同步的工件可能共有同一个错误。 |
| 依据 |
相关：带契约和版本的项目间关联（MILPA-R-007）；当配置允许时，依赖规则应当自动检查（ASILO-R-002）。新增：单个仓库内部的同步，其检查的效力与 ASILO-R-002 相同（应当）。 |
SCAFFOLD-R-007
| 字段 |
内容 |
| 问题 |
针对未知的他方契约进行实现。 |
| 范围与适用条件 |
助手针对另一单元的契约工作。 |
| 责任人 |
该任务的负责人。 |
| 可验证的表述 |
针对另一单元的契约工作的助手，必须在其上下文中收到该契约及其版本。 |
| 预期证据 |
已授权的上下文，包含所用的契约和版本。 |
| 残余风险 |
已提供的契约可能不完整。 |
| 依据 |
引用：MILPA-R-007。新增：将他方契约交付至上下文。 |
SCAFFOLD-R-008
| 字段 |
内容 |
| 问题 |
引入的依赖没有可识别的审查。 |
| 范围与适用条件 |
添加或变更第三方依赖。 |
| 责任人 |
依赖审查负责人。 |
| 可验证的表述 |
添加或变更第三方依赖，必须记录由谁审查以及原因。 |
| 预期证据 |
已记录的依赖变更、审查人和理由。 |
| 残余风险 |
审查可能发现不了漏洞或不兼容之处。 |
| 依据 |
无已接受依据。ASILO-R-001 处理的是模型的输出及其读取的数据，而非依赖链。新增：依赖审查。 |
SCAFFOLD-R-009
| 字段 |
内容 |
| 问题 |
工作没有目标、边界，也没有可验证的收尾。 |
| 范围与适用条件 |
在仓库中与助手一起进行的工作。 |
| 责任人 |
批次负责人。 |
| 可验证的表述 |
工作必须组织为功能、修正、重构或调研类型的批次，并具有目标、负责人、区域、助手、时间区间、状态和结果。成本记录为数据或“未知”，绝不作为伪装的估算。 |
| 预期证据 |
记录有类型、目标、负责人、区域、助手、时间区间、状态、结果，以及成本或“未知”的登记。 |
| 残余风险 |
完整的登记并不能证明工作的质量。 |
| 依据 |
相关：在用于决策的报告中区分事实与假设（MILPA-R-002）；每次自动化执行在成本、动作和时间上的限制（ASILO-R-007），批次不能取代这些限制。新增：组织单元、成本登记和收尾。 |
SCAFFOLD-R-010
| 字段 |
内容 |
| 问题 |
合并时没有检查，或关键影响没有人工决定。 |
| 范围与适用条件 |
在合并批次之前，或在产生被列为关键的影响之前。 |
| 责任人 |
集成与关键影响的负责人。 |
| 可验证的表述 |
合并批次之前，必须执行仓库所声明的检查。助手不得自行合并或部署项目的关键影响目录所包含的内容；其余内容遵循已声明的检查。 |
| 预期证据 |
检查结果，以及针对关键影响的知情确认。 |
| 残余风险 |
检查和人工审查可能遗漏错误。 |
| 依据 |
相关：ASILO-R-005 要求有明确的关键影响目录，其最低内容包括向第三方发布或发送；部署可能属于其中。新增：每次合并的检查，以及将合并或部署明确列为该目录的候选项。人工决定仅限于已列入目录的内容，因为 ASILO-R-005 提醒，对一切事项都要求批准会导致不读就批准。 |
SCAFFOLD-R-011
| 字段 |
内容 |
| 问题 |
工程配置被发布到了产品之中。 |
| 范围与适用条件 |
构建用于部署的制品。 |
| 责任人 |
构建与发布负责人。 |
| 可验证的表述 |
仅属于工程层的配置（区域、说明、批次、编程助手的配置），必须排除在所部署的制品之外，并在已构建的制品上检查。 |
| 预期证据 |
在已构建制品上进行的清单与检查，证明已排除。 |
| 残余风险 |
清单可能遗漏文件或内嵌的数据。 |
| 依据 |
无已接受依据。ASILO-R-002 要求声明各层及其依赖规则，而非排除文件。新增：经过检查的排除。 |
SCAFFOLD-R-012
| 字段 |
内容 |
| 问题 |
探索绕过了控制，或在没有收尾的情况下变成了正式工作。 |
| 范围与适用条件 |
项目决定启用探索模式。 |
| 责任人 |
授权探索及其产出的人。 |
| 可验证的表述 |
项目可以声明一种隔离的探索模式。在启动之前，必须明确允许暂停的区域、同步和批次检查，其范围和期限，以及负责人。其余 SCAFFOLD 要求、ASILO/MILPA 要求、权限、数据限制以及对关键影响的审查仍然有效。所有结果必须被丢弃，或在合并之前进入带有适用检查的正式批次。 |
| 预期证据 |
事先声明的可暂停控制和限制，以及登记为丢弃或正式批次的产出。 |
| 残余风险 |
探索的隔离可能失效。 |
| 依据 |
相关：用于非正式临时材料的独立位置（MILPA-R-006），以及已标记且不发布的探索性关联（MILPA-R-007 的例外）。新增：正式模式及其产出。 |
SCAFFOLD-R-013
| 字段 |
内容 |
| 问题 |
紧急情况被当作无限期的授权。 |
| 范围与适用条件 |
使用紧急通道来跳过工程检查。 |
| 责任人 |
启用该通道并负责事后复审的人。 |
| 可验证的表述 |
用于跳过工程检查的紧急通道，必须事先定义，使用时必须留下记录，并以事后复审收尾。它不免除 ASILO-R-005 所要求的审查，该审查按该卡片的紧急例外，可在事前或事后进行。 |
| 预期证据 |
事先的程序、使用记录和事后复审，以及相应的 ASILO-R-005 决定。 |
| 残余风险 |
事后复审并不能撤销所有影响。 |
| 依据 |
引用：事先定义的紧急情况（ASILO-R-005）。新增：面向工程层的程序。 |
SCAFFOLD-R-014
| 字段 |
内容 |
| 问题 |
跨仓库写入，既无范围也无契约。 |
| 范围与适用条件 |
一个根目录协调多个仓库。 |
| 责任人 |
仓库间协调的负责人。 |
| 可验证的表述 |
复合项目的根目录必须声明其协调哪些仓库，以及它们通过何种契约通信。除非通过在该子仓库中开启的批次，否则不得从根目录向子仓库写入。 |
| 预期证据 |
子仓库清单、契约，以及在受影响的子仓库中开启的批次。 |
| 残余风险 |
清单可能无法反映真实结构。 |
| 依据 |
引用：清单中的父节点，继承不在 0.1 范围内（MILPA-R-004）；范围不得宽于调用者的范围（ASILO-R-004）。新增：层级之间的工作方向。 |
SCAFFOLD-R-015
| 字段 |
内容 |
| 问题 |
根目录的上下文在没有子仓库批次的情况下吸收了代码。 |
| 范围与适用条件 |
在复合根目录中准备任务。 |
| 责任人 |
根目录上下文的负责人。 |
| 可验证的表述 |
从根目录出发，上下文必须限于子仓库的清单、契约、地图和说明；其代码须通过子仓库的批次引入。根目录的每项任务仍受其自身上下文预算的约束。 |
| 预期证据 |
根目录的预算和来源清单；用于访问其代码的子仓库批次。 |
| 残余风险 |
清单或说明可能暴露意料之外的信息。 |
| 依据 |
引用：按任务允许的来源（ASILO-R-003）。新增：面向协调层级的默认规则。 |
SCAFFOLD-R-016
| 字段 |
内容 |
| 问题 |
在依赖尚未完成或存在环的情况下关闭批次。 |
| 范围与适用条件 |
一个批次依赖另一个批次。 |
| 责任人 |
依赖方批次的负责人。 |
| 可验证的表述 |
依赖另一批次的批次必须声明这一点，并且不得先于它关闭。依赖不得形成环。 |
| 预期证据 |
已声明的依赖、无环检查，以及关闭时的状态。 |
| 残余风险 |
未声明的依赖可能被忽视。 |
| 依据 |
无已接受依据。MILPA-R-007 处理项目之间的关联，而非批次之间的依赖。新增：批次间依赖与禁止成环。 |
SCAFFOLD-R-018
| 字段 |
内容 |
| 问题 |
在过时的契约或关联之上开展新工作。 |
| 范围与适用条件 |
使用被标记为过时的契约或关联。 |
| 责任人 |
使用它的批次的负责人。 |
| 可验证的表述 |
过时的契约或关联不得用于功能类型的批次；可以用于以将其淘汰为目标的批次。 |
| 预期证据 |
契约或关联的状态，以及批次的类型和淘汰目标。 |
| 残余风险 |
过时状态可能没有及时更新。 |
| 依据 |
相关：MILPA-R-007 要求关联有“状态”，但未定义其取值。新增：“过时”这一取值及其对批次的影响。 |
SCAFFOLD-R-019
| 字段 |
内容 |
| 问题 |
在没有商定目标、范围和负责人的情况下进行构建；每个人或助手各自推断目的。 |
| 范围与适用条件 |
所有声明采用 SCAFFOLD 的项目，无论是从零开始，还是在既有工作之上采用该方法。 |
| 责任人 |
产品负责人。 |
| 可验证的表述 |
在开启第一个功能类型批次之前，项目必须有一份项目章程，包含目标、所解决的问题、范围与排除项、产品、协调、技术和交付的负责人、关键影响目录、数据限制，以及可观察的成功标准。章程必须带有版本和日期；对它的修改必须记录为产品负责人的决定。 |
| 预期证据 |
带有版本的章程、已指明的负责人、关键影响目录和变更历史。 |
| 残余风险 |
一份完整的章程也可能描述了错误的目标。 |
| 依据 |
引用：清单中的人类负责人与范围（MILPA-R-004）；关键影响目录（ASILO-R-005）。新增：以章程作为规划性工作的起点。 |
SCAFFOLD-R-020
| 字段 |
内容 |
| 问题 |
在既有系统上采用该方法却不知道现状：依据假设来规划，并重新讨论已经做出的决定。 |
| 范围与适用条件 |
在已有代码、用户或承诺的仓库、产品或项目上采用 SCAFFOLD。 |
| 责任人 |
技术负责人。 |
| 可验证的表述 |
在既有工作之上采用 SCAFFOLD 时，项目必须登记一份现状盘点，包括：仓库与环境清单、现有检查及其最近一次结果、在用的发布版本、已知所有者、已知的技术债与风险，以及进行中的工作。每项数据必须标记为有来源的事实或假设。进行中的工作必须转化为工作项，或附理由予以舍弃。 |
| 预期证据 |
带日期的现状盘点，事实与假设分开，以及由其创建的工作项。 |
| 残余风险 |
无人记得的内容不会出现在现状盘点中。 |
| 依据 |
引用：事实、推断与假设分开（MILPA-R-002）。新增：以现状盘点作为项目任何阶段的入口。 |
SCAFFOLD-R-021
| 字段 |
内容 |
| 问题 |
无人提出的工作，没有判断其何时完成的标准，也无从查明为何要做。 |
| 范围与适用条件 |
项目中所有规划性工作。 |
| 责任人 |
产品负责人。 |
| 可验证的表述 |
规划性工作必须登记为工作项，具有稳定的标识符、类型、目标、可验证的验收标准、负责人、状态、依赖，以及父工作项或无。功能或修正类型的批次必须至少引用一个工作项；调研或重构类型的批次可以不带工作项而开启，但须声明其理由。标识符不得重复使用。 |
| 预期证据 |
工作项完整的工作清单，以及与之关联的批次。 |
| 残余风险 |
写得很好的验收标准也可能要求了错误的东西。 |
| 依据 |
相关：工作批次（SCAFFOLD-R-009）；批次间依赖（SCAFFOLD-R-016）。新增：工作项作为规划单元，区别于执行它的批次。 |
SCAFFOLD-R-022
| 字段 |
内容 |
| 问题 |
由助手、工具或先到者来决定构建什么以及先后顺序。 |
| 范围与适用条件 |
对规划性工作进行排序、验收或舍弃。 |
| 责任人 |
产品负责人。 |
| 可验证的表述 |
工作清单的顺序、对已完成工作项的验收及其舍弃，必须由已声明担任该角色的人来决定。助手可以提出工作项、标准和顺序；不得在没有记录某人的决定的情况下重新排序、验收或舍弃。 |
| 预期证据 |
排序与验收的历史，以及做出决定的人。 |
| 残余风险 |
有人可能不经审查就验收。 |
| 依据 |
相关：对关键影响的人工审查（ASILO-R-005）。新增：优先级与工作验收属于人工决定。 |
SCAFFOLD-R-023
| 字段 |
内容 |
| 问题 |
开始了尚不明确的工作，并把未完成的工作宣告为已完成。 |
| 范围与适用条件 |
工作项进入进行中，或被标记为已完成。 |
| 责任人 |
协调负责人，负责就绪条件和完成定义；验收遵循 SCAFFOLD-R-022。 |
| 可验证的表述 |
项目必须声明带版本的开始就绪条件和完成定义。一个工作项，如果其验收标准和完成定义尚未经过检查，或者没有人验收，不得标记为已完成。完成定义必须包含仓库的合并前检查（SCAFFOLD-R-010）。 |
| 预期证据 |
带版本的定义，以及对每个已完成的工作项，已执行的检查和验收人。 |
| 残余风险 |
薄弱的完成定义会放过未完成的工作。 |
| 依据 |
在 ASILO/MILPA 中无已接受依据。新增：就绪条件与完成定义。 |
SCAFFOLD-R-024
| 字段 |
内容 |
| 问题 |
开启的工作多于完成的工作，团队不同步，同样的问题反复出现。 |
| 范围与适用条件 |
所有有进行中工作的项目。 |
| 责任人 |
协调负责人。 |
| 可验证的表述 |
项目必须声明其节奏：固定时长的周期，或持续流动。在持续流动中，必须按状态，或按人员和小组，声明进行中工作的上限。无论采用何种节奏，项目都必须声明对已完成工作的回顾以及流程改进的周期，并在进行时记录日期、参与者和约定事项；每项约定应当转化为工作项。 |
| 预期证据 |
已声明的节奏、适用时的进行中工作上限，以及回顾和改进的会议记录。 |
| 残余风险 |
会议可能照开而毫无改变。 |
| 依据 |
在 ASILO/MILPA 中无已接受依据。新增：节奏、进行中工作上限和定期回顾。 |
SCAFFOLD-R-025
| 字段 |
内容 |
| 问题 |
不知道哪项变更实现了哪项工作，也不知道某个发布版本包含哪些工作。 |
| 范围与适用条件 |
所有工作分支、已提交的变更、合并请求和发布版本。 |
| 责任人 |
技术负责人。 |
| 可验证的表述 |
每个工作分支和每个合并请求必须引用其所实现的工作项或批次的标识符。每项已提交的变更必须在机器可读的字段中满足 SCAFFOLD-R-003。必须能够从一个发布版本获得其包含的工作项清单，也能从一个工作项获得其变更。 |
| 预期证据 |
已声明的命名约定、分支、变更和请求中的引用，以及一个按发布版本列出工作项的查询。 |
| 残余风险 |
引用可能指向错误的工作项。 |
| 依据 |
引用：变更的归属（SCAFFOLD-R-003）。相关：来源（MILPA-R-001）。新增：工作、变更与发布版本之间的双向可追溯性。 |
SCAFFOLD-R-026
| 字段 |
内容 |
| 问题 |
变更在没有审查和检查的情况下进入主分支，或分支存在太久以致合并它本身成了另一个项目。 |
| 范围与适用条件 |
人员或助手在其中工作的、使用版本控制的仓库。 |
| 责任人 |
技术负责人。 |
| 可验证的表述 |
仓库必须声明其分支模型：主分支、分支类型、由谁合并以及采用哪些检查。主分支必须受保护：助手不得在没有经人审查的合并请求的情况下向其写入。工作分支应当只属于一个批次，并具有已声明的最长存续期。除非已声明轮换，两个助手不得同时向同一分支写入。 |
| 预期证据 |
已声明的分支模型；在托管服务中配置的保护，或在没有服务时，已声明的规则以及对主分支历史的检查；开启中分支的存续时长。 |
| 残余风险 |
保护可能被关闭，或存在被遗忘的例外。 |
| 依据 |
引用：写入区与轮换（SCAFFOLD-R-001）；合并前检查（SCAFFOLD-R-010）。新增：分支模型与主分支保护。对合并请求的审查是代码审查；它不是 ASILO-R-005 所说的对关键影响的确认，后者仍仅限于已列入目录的内容。 |
SCAFFOLD-R-027
| 字段 |
内容 |
| 问题 |
环境没有声明用途：测试中使用真实数据、环境之间共享密钥、谁有权限谁就部署。 |
| 范围与适用条件 |
运行软件的所有环境：本地、集成、测试、预生产、生产或其他。 |
| 责任人 |
交付负责人。 |
| 可验证的表述 |
项目必须声明其环境，包括用途、允许的数据分类最高值、密钥的来源、谁可以在其中部署以及准入检查。分类使用带名称和已定义取值的量表（MILPA-R-003）。使用密钥的环境必须拥有自己的密钥，不与其他环境共享。非生产环境不得接收高于其所声明取值的真实数据，除非有已登记的例外。部署到生产必须列入关键影响目录。 |
| 预期证据 |
环境声明，以及记录有人员和检查的部署登记。 |
| 残余风险 |
数据副本可能通过未声明的途径离开其环境。 |
| 依据 |
引用：敏感数据与密钥（ASILO-R-006）；关键影响（ASILO-R-005）。新增：已声明的环境，以及将部署到生产作为关键影响；SCAFFOLD-R-010 已预见该目录会包含部署。 |
SCAFFOLD-R-028
| 字段 |
内容 |
| 问题 |
进入生产的并非经过测试的那个，也没有已知的回滚方式。 |
| 范围与适用条件 |
在环境之间晋级制品，或进行部署。 |
| 责任人 |
交付负责人。 |
| 可验证的表述 |
在环境之间晋级的制品，必须就是通过检查的那一个，并以其加密指纹标识，且不得按环境重新构建；各环境的配置另行注入。在部署到生产之前，必须存在回滚计划。部署时必须记录发布版本、指纹、环境、授权人和结果。若紧急通道（SCAFFOLD-R-013）部署的制品不同于已检查的制品，必须记录其指纹和被省略的内容，并且该部署纳入事后复审。 |
| 预期证据 |
每次晋级中的制品指纹、回滚计划和部署登记。 |
| 残余风险 |
回滚可能无法撤销对数据的更改。 |
| 依据 |
相关：将工程层排除出制品（SCAFFOLD-R-011）。新增：制品在环境之间的身份与回滚。 |
SCAFFOLD-R-029
| 字段 |
内容 |
| 问题 |
发布版本没有声明的含义，也没有记录变更了什么、由谁授权。 |
| 范围与适用条件 |
发布或部署软件的某个发布版本。 |
| 责任人 |
交付负责人。 |
| 可验证的表述 |
项目必须声明其版本号方案，以及何种变更要求提升哪个组件的版本号。每个已发布的发布版本必须在版本控制中有不可变的标签、根据其工作项及其所含的无工作项批次生成的发布说明、已标明的不兼容变更，以及授权人。向第三方发布遵循关键影响目录（ASILO-R-005）。已发布的标签不得移动到另一项变更上。 |
| 预期证据 |
已声明的方案、标签、发布说明和授权。 |
| 残余风险 |
不兼容变更可能未被标明。 |
| 依据 |
相关：带契约和版本的关联（MILPA-R-007）；版本同步（SCAFFOLD-R-006）。新增：版本号方案与发布版本登记。 |
SCAFFOLD-R-030
| 字段 |
内容 |
| 问题 |
无人对一组智能体负责，或人类团队不清楚每个助手能做什么。 |
| 范围与适用条件 |
项目以小组方式工作：由人员、智能体或两者混合组成的团队。 |
| 责任人 |
协调负责人。 |
| 可验证的表述 |
每个小组必须声明其负责人、成员、写入区以及其接受的工作类型。小组中的每个智能体必须有智能体配置，包含范围、每次执行的限制（ASILO-R-007）和监督它的人；该配置不是 MILPA-R-006 所说的项目配置。仅由智能体组成的小组不得接受工作、对工作清单排序、批准自己的结果或授权部署。 |
| 预期证据 |
每个小组的卡片，包含负责人、成员、配置和区域。 |
| 残余风险 |
所声明的监督可能并未实际履行。 |
| 依据 |
引用：每个智能体的身份与范围（ASILO-R-004）；预算（ASILO-R-007）。新增：以小组作为带有人类负责人的分配单元。 |
SCAFFOLD-R-031
| 字段 |
内容 |
| 问题 |
分配了工作却不知道由谁来做，也不知道是否在现有产能之内；智能体的产能与人员的产能被混为一谈。 |
| 范围与适用条件 |
分配工作项或批次。 |
| 责任人 |
协调负责人。 |
| 可验证的表述 |
每个进行中的工作项必须有一名负责人，即使由智能体执行。规划必须区分人员的产能（以可用时间衡量）与智能体的产能（受预算以及其结果所需的人工审查限制）。估算必须登记为估算，与实测数据分开。 |
| 预期证据 |
含负责人的分配、按类型声明的产能，以及与数据分开的估算。 |
| 残余风险 |
人工审查可能成为瓶颈而未被度量。 |
| 依据 |
相关：成本作为数据或“未知”（SCAFFOLD-R-009）；事实与假设（MILPA-R-002）。新增：分配与有区分的产能。 |
SCAFFOLD-R-032
| 字段 |
内容 |
| 问题 |
在没有度量的情况下宣称流程在改进，事件被遗忘而毫无改变。 |
| 范围与适用条件 |
向生产环境交付软件或将其发布的项目。 |
| 责任人 |
协调负责人，事件方面与交付负责人共同负责。 |
| 可验证的表述 |
项目必须声明其度量哪些交付指标、如何获得这些指标以及度量周期。每起生产事件和每次回滚必须有事后复审，包含事实、作为假设的可能原因以及行动；每项行动必须转化为工作项。不得在没有改进前后度量的情况下宣称有所改进。 |
| 预期证据 |
带有来源的指标、事件复审，以及由此创建的工作项。 |
| 残余风险 |
指标可能提升了，而结果并没有改善。 |
| 依据 |
引用：事实、推断与假设（MILPA-R-002）。相关：对 AI 故障的评估（ASILO-R-008）。新增：交付度量与事件复审。 |
不在 0.1 版本之内的待定修订案
SCAFFOLD-R-017
状态：proposed。不是现行有效的要求。
对 MILPA-R-007 的修订提案；该要求目前规定在两端都声明每一个关联。 已于 2026 年 10 月 13 日决定提出该提案；尚未被接受。若被接受：与未声明其端点的系统之间的关联，必须标记为外部，并附上所用的他方契约及其版本或获取日期，并且交接说明不得以外部方作为接收方。在其被接受之前，适用 MILPA-R-007 及其现行例外。
它与 MILPA-R-007 现行内容相抵触（后者唯一的例外是探索性关联）。相关：外部内容不可信（ASILO-R-001）。
与 ASILO 和 MILPA 的关系
“依据”字段区分引用、相关和无已接受依据，范围是 ASILO/MILPA。“无已接受依据”是指该要求在 SCAFFOLD 中是新增的，而不是指它在 SCAFFOLD 0.1 中没有被接受。它自身被接受，并不会将要求转移到另一个方法中。R-017 保持其作为对 MILPA 的拟议修订案的状态，需要另行决定。
SCAFFOLD-R-005 使用这一开放的字段格式，它独立于具体产品，并已在 SCAFFOLD 0.1 中被接受。说明性的上下文指南提供了所引用各部分的含义。不要求特定的序列化方式、文件扩展名或软件产品：
| 字段 |
内容 |
| 标识符 |
在仓库内唯一。 |
| 交出方与接收方 |
谁交出，谁接收。 |
| 说明的状态 |
abierta、tomada、bloqueada_por、cerrada 或 cancelada。这是一套自有的方案；它不会成为要求、关联或批次的状态。 |
| 被阻塞于 |
另一份说明的标识符，或无。 |
| 来源 |
若是被退回的，则为其来源说明；否则为无。 |
| 有效期 |
日期，或未声明。仅作提示；其本身不会改变状态。 |
| 目标、引用与审查、当前限制 |
上下文指南中的各部分。 |
| 结果；事实、推断与假设；决定；下一步行动 |
上下文指南中的各部分。 |
| 状态历史 |
每次变更的日期、状态、操作人和原因。 |
| 领取时的指纹 |
领取者所读内容的加密摘要。 |
关闭一份说明表示其工作已经结束；并不表示批准或接受其内容。
与交接说明的格式一样，这些格式是字段清单，不强制序列化方式或产品。任务管理器、仓库中的文件或电子表格均可满足它们。模板页面通过一个虚构示例展示它们。
| 格式 |
要求 |
最少字段 |
| 项目章程 |
R-019 |
版本与日期；目标；问题；范围与排除项；产品、协调、技术和交付的负责人；关键影响目录；数据限制；可观察的成功标准；变更历史。 |
| 现状盘点 |
R-020 |
日期；仓库与环境；检查及最近一次结果；在用的发布版本；所有者；技术债与风险；进行中的工作及其去向；每项数据均为有来源的事实或假设。 |
| 工作项 |
R-021 |
标识符；类型（iniciativa、función、corrección、reestructuración、investigación 或另行声明的类型）；目标；验收标准；负责人；状态；父项；依赖；实现它的批次、分支、变更和发布版本。 |
| 工作项状态 |
R-021、R-023 |
propuesto、listo、en_curso、en_revisión、terminado 或 descartado。这是一套自有的方案：它不是批次、说明或要求的状态。 |
| 合并请求 |
R-025、R-026 |
工作项或批次；分支；负责人；参与的助手；检查及结果；人工审查人；所涉及的关键影响，或无。 |
| 部署登记 |
R-027、R-028 |
发布版本；制品指纹；环境；授权人；检查；回滚计划；结果与时间。 |
| 发布说明 |
R-029 |
发布版本与标签；包含的工作项；不兼容变更；授权人；日期。 |
| 小组卡片 |
R-030 |
名称；负责人；人员与智能体成员；每个智能体的配置、范围、预算和监督人；区域；所接受的工作类型。 |
关闭、完成或部署只是登记一个事实；其本身并不批准结果的质量。
仍然存在的风险
声明区域并不能阻止工具在区域之外写入；说明可能说谎；已同步的契约可能是错误的；完整的批次登记可能记录的是糟糕的工作；有人可能不读就合并。排好序的工作清单可能排错了序；完成定义可能很薄弱；指标可能提升了，而产品并没有变好。SCAFFOLD 使事情有序并可见；它不会消除冲突、错误或幻觉。
返回 SCAFFOLD。