应用部分 13. 实践考核：构建生产环境 SDD 闭环

状态：建议。 本部分不引入新机制。它将第二卷整合为一条可验证的路线，仿照第一卷的实践考核。目标是证明你能够完成从遗留痕迹到由事实而非智能体置信度所允许的生产环境 SDD 场景。

建议在完成第 1–12 章后进行考核。如果你是选择性阅读本卷，可将本部分作为缺失工件清单：capstone/ 包中的任何空白都表明需要返回哪一章。如果不清楚如何将文件整合为一个案例，请回到第 0 部分：它设定了 AgentClinic-production 的实验框架，并解释了何为教学最低要求。

目标

考核结束时，你应该拥有一个连贯的证据包，用于 AgentClinic-production：

• 带有来源的恢复需求；
• 受控缺陷规范的修复版本；
• 包含不可变和可变规则的 constitution.md；
• 至少一个反例和一条对决记录；
• 本地 Spec CI 或其可运行替代方案；

• judgment.md 或先例记录；
• 预算控制和反古德哈特控制；
• 就绪性网关（readiness gate）和阻塞项清单；
• 反模式诊断检查表。

考核通过的标准并非所有文件看起来完整，而是另一个人能够打开该包、重复关键检查，并理解为何该解决方案可以安全放行，或为何必须推迟。

最终案例

围绕一个生产环境事件开展工作。推荐的主要案例是 high_memory_usage，因为它涵盖了第 11 部分中的 webhook 规范化、就绪性网关和试运行。如果围绕对决和文件仲裁进行考核，可选择 autoscale_200pct 作为替代。不要在同一考核中混合两个案例。

最低要求设定：

• AgentClinic-production 收到来自 Grafana 或 PagerDuty 的告警；
• 遗留痕迹不完整：部分规则来自事后分析，部分来自 QWEN.md，部分来自口头实践；
• 自动修复看似有用，但可能违反影响半径限制、层级预算或反古德哈特不变量；
• 放行前需要证明规范、计划、检查和就绪性之间互不矛盾。

包结构

创建目录：

capstone/
  README.md
  genealogy.md
  poisoned-spec.md
  fixed-spec.md
  constitution.md
  validation.md
  judgment.md
  budget-note.md
  goodhart-note.md
  readiness.md
  antipattern-audit.md

如果在实际项目中工作，名称可以调整。但文件角色必须保持一致：来源、缺陷、修复、规则、事实、仲裁、预算、指标、就绪性和流程审计。

在填写自己的包之前，请先打开 [examples/templates/capstone-dossier.md](examples/templates/capstone-dossier.md)。这是 high_memory_usage 首次通过的参考"黄金路径"：它展示了通过考核所需的最少事实量，而不将章节变成冗长的生产文档。

将其作为篇幅限制器使用。如果你的 capstone/README.md 或 validation.md 明显长于参考模板，请先检查是否混入了完整跟踪的工件：scorebook、metric_network、完整的 out/duel.json、整个预算计划或详细的聊天历史。

在第 1–12 章中，寻找"如何进入 capstone/"的区块。首次通过时，它比完整的工件清单更重要。如果该区块要求转移一行内容、一个被接受的候选方案、一个防御性不变量或一个就绪性裁决，不要将证据包扩展到完整的生产跟踪文件。

开始前，在 capstone/README.md 中写下五行模板：

Incident-case:
Главный риск:
Ключевая проверка:
Главный блокер:
Следующее исправление:

默认路线中，第一行应为 Incident-case: high_memory_usage。如果选择了 autoscale_200pct，请立即注明，不要将 high_memory_usage 添加为同等案例。

如果这些行无法填写，说明包尚未围绕单一案例整合。

最低教学场景

教学案例

将 [examples/real-api/](examples/real-api/) 中的 high_memory_usage 作为默认路线。如果选择了 [examples/tribunal/](examples/tribunal/) 中的 autoscale_200pct，请直接在 capstone/README.md 中注明，不要将 high_memory_usage 添加为同等案例。目标是构建一个可复现的小型证据包，而非完美的生产流程：一个事件、一个规范缺陷、一个反例或就绪性结论、一个阻塞项清单。

准备

• 阅读所选可运行示例的 README。
• 从 [examples/templates/](examples/templates/) 复制所需模板。
• 创建空目录 capstone/。
• 预先决定什么算作阻塞项：薄弱的 evidence_ref、优先级冲突、违反 manual_review_floor、预算超支或就绪性低于阈值。

步骤

1. 填写 capstone/genealogy.md：一条恢复的需求、至少两个来源、置信度级别和开放问题。
2. 创建 capstone/poisoned-spec.md：仅引入一个缺陷——优先级冲突、循环或越界隐藏出口。

1. 创建 capstone/fixed-spec.md：通过例外规则、模式或明确的否定需求修复缺陷。
2. 填写 capstone/constitution.md：至少两个 immutable_principles、一条带 ttl、max_scope、rollback_condition 的 mutable_rule，以及简短的 governance_protocol。
3. 为所选案例运行一个可运行示例。

• 对于 high_memory_usage——使用第 11 部分"最低教学场景"中的命令：一个正面就绪性、一个阻塞状态保持、一个允许和一个禁止的空运行。readiness_block_stateful.json 和 delete_namespace 命令预期返回代码 1——这不是示例故障，而是 capstone/validation.md 阻塞项的来源。
• 对于 autoscale_200pct——使用第 8 部分"最低教学场景"中的三个脚本：run_duel.py、check_invariants.py、write_judgment.py。

此处不重复完整命令，以免考核沦为复制粘贴。如果你同时打开了两章，请按相同顺序执行其步骤。

1. 将结果转入 capstone/validation.md：命令、预期事实、实际结果和放行阻塞项。对于 real-api，正面就绪性通过展示允许路径，readiness_block_stateful.json 提供状态保持阻塞项，delete_namespace 展示预先约定操作的边界。如果命令来自其他可运行目录，请解释什么原则被转入主要案例。
2. 填写 capstone/judgment.md：APPROVE、DENY 或 DEFERRED 裁决、原因、evidence_ref、下一步。judgment.md 是特定争议的决策记录；重复出现的冲突类别额外记录在 capstone/precedents.md 中，包含五个字段（case_id / verdict / evidence_ref / applies_to / next_check），参见第 8 部分。
3. 添加 capstone/budget-note.md：local-coder 拒绝时会发生什么、什么限制保护 frontier-reviewer、何时触发应急模式。
4. 添加 capstone/goodhart-note.md：哪个目标指标可能开始失真、哪个守护指标对其进行限制。

1. 填写 capstone/readiness.md：最终评估、阻塞条件、为何带证据的 23/25 优于不带证据的 25/25。
2. 执行第 12 部分的诊断检查表，并在 capstone/antipattern-audit.md 中记录三个风险。
3. 完成 capstone/README.md：一段背景说明、命令清单、最终状态和放行前修复清单。

第 12 步后，以新审查员身份重读 capstone/README.md。其中应可见的不是所有细节，而是检查路线：需求从何而来、何处损坏、运行了什么命令、得出什么裁决、什么阻塞了生产放行。

首次通过的最低 capstone/README.md 可压缩为五行：

Incident-case: high_memory_usage
Главный риск: auto-remediation без полного audit_trace или backup evidence
Ключевая проверка: python3 scripts/check_readiness.py --readiness fixtures/readiness_block_stateful.json
Главный блокер: stateful workload без backup_verified блокирует действие
Следующее исправление: добавить evidence_ref для backup и повторить dry-run

控制事实

如果其他读者能够打开 capstone/README.md 并在无需你的聊天历史的情况下回答五个问题，该包即适合考核：

1. 恢复了什么需求，证据从何而来？
2. 引入了什么缺陷，如何修复？
3. 实际运行了什么检查？
4. 为何文件仲裁或就绪性网关的裁决如此？
5. 生产放行前还有什么阻塞项？

如果至少一个问题需要作者口头解释，该包尚未准备就绪。

可审查痕迹

不要将可运行示例的 out/ 转入最终包。最终痕迹是简短的 capstone/，包含能回答上述五个问题的文件。如果在自己的仓库中工作，请固定此证据包，而非本地运行目录。

快速问题

请书面回答，不使用 Qwen Code。

1. genealogy.md 与 validation.md 有何区别？
2. 为何受控缺陷规范必须恰好包含一个缺陷？
3. 影子规范何时可进入 QWEN.md 但不进入 requirements.md？
4. 为何 Spec CI 不能替代验证者？
5. judgment.md 必须包含什么才能使争议可重复？

1. 即使 KPI 良好，为何不能将 manual_review_floor 归零？
2. 什么使 token_health 比简单计算消耗令牌更有用？
3. 为何没有 evidence_ref 的就绪性分数不构成放行许可？
4. 何时 DEFERRED 优于形式上的 APPROVE？
5. 第 12 部分的哪个反模式最常破坏你的包？

评分标准

按 30 分评估包。五个类别各 6 分，反映生产环境 SDD 的五个支柱：事实来源、可验证性、争议解决、约束维持和包清晰度。等权重意味着一个强类别不能补偿弱类别，每个类别内的 6 个点覆盖典型盲区而不至于过度细化。

来源与规范 — 6 分

• 1：genealogy.md 将需求与至少两个来源关联；
• 1：争议事实未被冒充为已批准需求；
• 1：poisoned/fixed 对包含一个缺陷和一个修复；
• 1：修复改变的是可验证工件，而非仅解释；
• 1：constitution.md 区分不可变和可变层；
• 1：可变规则具有 ttl、max_scope、rollback_condition。

检查与事实 — 6 分

• 1：至少运行一个 book2/examples/ 中的可运行示例；
• 1：结果转入 validation.md 并附命令和预期；
• 1：负面或阻塞场景被明确描述；
• 1：Spec CI 或其等效物检查需求与计划的关联；
• 1：就绪性或试运行不绕过阻塞条件；
• 1：out/ 未被冒充为可审查工件。

仲裁与角色 — 6 分

• 1：judgment.md 包含裁决、原因和 evidence_ref；
• 1：验证者/实现者/安全角色不混淆，协调者仅维护 judgment.md；
• 1：反例最小化或明确标注为非最小化；
• 1：争议存在 DEFERRED 或下一步可验证步骤；
• 1：先例记录方式使其可复用；
• 1：安全否决或其等效物不能被多数票绕过。

生产约束 — 6 分

• 1：预算场景描述廉价层级失效；
• 1：frontier-reviewer 受风险或配额限制；
• 1：反古德哈特对将 KPI 与守护指标关联；
• 1：manual_review_floor 得以保留；
• 1：就绪性分数附证据；
• 1：回滚或阻塞项在放行前指明。

包清晰度 — 6 分

• 1：capstone/README.md 无需外部聊天即可解释案例；
• 1：命令清单可在本地重复或替换为可运行等效链接；
• 1：阻塞项与改进项分离；
• 1：章节和模板链接有助于追溯来源；
• 1：第 12 部分诊断检查表已执行；
• 1：包不包含与所选案例无关的多余机制。

25–30 分 — 生产环境 SDD 闭环已准备好团队审查。

19–24 分 — 闭环适用于教学通过，但需加强证据或阻塞项。

低于 19 分 — 返回第 1–12 章的最低场景并缩小案例规模。

考核后做什么

不要将整个包作为模板转入生产环境。选择两三个最有用的工件并优先自动化：

• 如果需求来源经常丢失——从 genealogy.md 开始；
• 如果 CI 漏过薄弱规范——从 Spec CI 开始；
• 如果争议反复出现——从 judgment.md 和 precedents.md 开始；
• 如果 KPI 开始失真——从反古德哈特 validation.md 开始。

第二卷的主要成果不是一套术语，而是要求在有风险的自动操作前提供可验证痕迹的习惯。