译文
译自西班牙语原文，以原文为规范文本。 状态：草稿，待人工审校。如有歧义，以西班牙语原文为准。
准备制品验证¶
本指南应用 SCAFFOLD 0.1，不要求特定工具、序列化、架构、用户故事或图表。 工程配置提出可选承诺；可执行契约与接受仍待完成。
从可检查的范围开始¶
声明章程、现状调查、工作项和接受标准。无 UI 的库可解释为何屏幕检查不适用；Web 应用选择相关流程、状态与环境。只要保留要求的字段和关系，等价格式可以使用。SCAFFOLD 0.1 有 31 项已接受要求；R-017 仍是待决修订。
| 制品或证据 | 现有依据 | 建议检查及限制 |
|---|---|---|
| 章程与调查 | R-019、R-020 | 目标、排除范围、负责人、关键效果和来源；存在不证明已接受。 |
| 故事、功能或倡议 | R-021 至 R-024 | ID、目标、标准、状态、依赖、父项和接受；故事是可选格式。 |
| 批次、区域、团队与交接 | R-001 至 R-005、R-009、R-016、R-030、R-031 | 所有者、轮次、限制、不可变性及无环依赖；声明不能阻止外部写入。 |
| 架构、契约与代码 | R-006、R-007、R-018 | 对应版本、允许依赖与适配器替换；不强制通用模式。 |
| 文档与图表 | R-006、R-010、R-023 | 链接、可编辑来源、编译及对应关系；可渲染不证明架构正确。 |
| 适用的 UI | R-010、R-021、R-023 | 已声明流程、状态、分辨率、无障碍与视觉审查；截图或自动测试不证明可用性或完整无障碍。 |
| Git 与审查 | R-003、R-008、R-025、R-026 | 工作项／批次／变更／版本双向追踪，以及查询到的保护或本地规则；命名不证明保护。 |
| 集成与交付 | R-010、R-011、R-027 至 R-029 | 结果绑定版本、构建制品、提升同一哈希、分离配置和回滚；CI 通过不接受关键效果。 |
| 评估与学习 | R-024、R-032 | 指标来源、事故和前后测量；模拟不是实际模型评估。 |
ID 指向要求，包括条件和例外。运行时必需的地区内容不会仅因名为“上下文”就被排除：参见地区交付。
四种不同观察¶
- **形式：**字段、类型、版本与限制。
- **一致性：**引用、依赖、状态与对应修订。
- **执行：**可识别的真实制品、环境、工具及结果证据。
- **决定：**谁接受哪个对象、范围是什么，以及适用时经核验的权限。
结构有效的记录可能不真实。缺少证据或工具不可用应记为未评估，而非成功。“不适用”须给出条件和理由，不能替代失败的检查。“人工已审查”勾选框不认证身份。技术结果不会自行关闭工作项（R-022、R-023）。
单一事实来源、可追溯性与变更影响¶
整个项目不存在一个包办所有事实的单一文档。每项声明都需要明确的权威来源：需求登记表负责需求，契约负责接口，代码负责可执行行为，决策记录负责已批准的决定。README 或图表可以是派生视图，但应声明来源与重新生成方法。没有负责人的多份重复决策会形成相互竞争的来源。
有关应用形态、结构、仓库、部署和区域配置的分类见软件架构配置文件。图通过 ID 引用规范来源，不复制其内容。
项目维护制品关系图，记录稳定 ID、路径、类型、修订版或摘要、负责人、适用条件及类型化关系。至少，项目配置应声明每种工作需要哪些关系。建议链路如下：
需求 → 工作项/用户故事/用例 → 可验证标准 → 契约与架构决策 → 组件/代码 → 测试/评估 → 文档/图表 → 交付/运行。
关系表示声明的依赖或覆盖，本身不能证明制品满足需求。覆盖声明需要可检查证据，并在项目要求时由人审查。无环图有利于影响分析；允许循环的引用或分组关系须明确声明，且不得用于依赖计算。
制品变更时，仓库识别变更节点，沿已声明关系计算传递依赖项，并将依赖旧修订版的证据标记为待审。生成文件应从来源重新生成，不应手动修改以掩盖差异。手写制品需要内容审查；摘要或成功渲染无法证明其含义仍然有效。未完成检查、缺失引用及冲突来源应如实报告；不得用“最后修改者胜”处理，也不得重新生成已接受的决定。
登记表可使用 YAML、JSON、数据库或工作跟踪系统，但须保留 ID、修订版、关系、来源信息及可验证导出。仓库应提供只读 CI 模式，报告受影响节点及无效来源，不安装扩展，也不执行制品中的指令。CI 可按声明的配置阻止集成，但其结果不会成为人的接受决定。
对 AI 助手，每项任务都应提供相关需求和契约的精确 ID 与修订版、获准写入区域，以及正向和负向标准。写入制品的事实声明应链接证据。助手在受限区域提出修改；检查器发现技术影响与过期证据，但不决定含义、权限或接受。责任人负责解决冲突并接受结果。
建议的基础团队¶
配置可根据风险和变更组建团队，无须每个批次都启用所有角色。软件功能的最小团队包括产品/协调、架构、实现和 QA。涉及数据、权限、网络、模型或敏感效果时，安全人员应尽早参与设计。存在用户流程时加入 UI/UX。变更影响使用契约、构建、CI 或发布时，加入文档/DevEx 和交付人员。小项目中一人可承担多项职责；实现者不能单独提供独立审查，也不能代替产品或交付验收。
每个批次应声明每个文件的唯一写入者、审查人、交接接口和证据。只有写入区域不重叠时才并行工作；跨区域变更需要协调批次和串行集成。代理数量不替代人的责任。
Skills、插件与 MCP¶
Skill 分发指令和流程；插件为主机产品打包可安装功能；MCP 规范客户端访问工具或资源的协议。它们是不同层，名称本身不能建立信任。主机客户端仍负责身份、逐操作授权、允许列表、限制、来源记录、审计和撤销。仓库内容不会自动安装 Skill/插件，也不会自动启用 MCP 服务器。
SCAFFOLD-R-006 · R-018 · R-022 · R-023
技术中立且受限的实现¶
检查核心可以接收标准化制品并返回发现，而不使用网络、Git、浏览器、模型或写操作。可选适配器在明确权限下提供工具证据。读取文档不会执行其命令或安装插件。CI/CD 集成保留输入、配置与哈希；可更换提供方而不改变检查含义。
用虚构的库和 Web 应用测试有效、不一致、缺少证据或决定的案例。修订变化会使依赖它的证据失效。 API、配置和分发属于实现。方法不规定产品或代理工具；产品的模板生成器不证明完整实现 SCAFFOLD 生命周期。西班牙语为规范来源；本译文等待人工审查。
SCAFFOLD 0.2 新增 R-033 至 R-037，含 0.1 基础共 36 项要求。本指南不替代卡片，也不证明控制已实现。