应用部分 13. 实践考核：搭建 production SDD 闭环

状态：建议。 本部分不引入新机制。它将第二卷整合为一条可验证的路线，参照第一卷实践考核的样式。目标是证明你能够沿着 production SDD 场景走通从 legacy 痕迹到可被事实（而非 agent 自信）放行的解决方案。

考核最好在第 1–12 章之后完成。如果你是选择性阅读本卷，可将本部分作为缺失制品的地图：capstone/ 包中的任何空白都指明应回到哪一章。如果不清楚如何将各文件串联成一个案例，请回到第 0 部分：它设定了 AgentClinic-production 的实验框架，并说明了教学最低要求。

目标

到考核结束时，你应当拥有针对 AgentClinic-production 的一份相互关联的证据包：

• 已还原的需求及其出处（provenance）；
• 已修正的、可控带缺陷的规范；
• 包含不可变规则与可变规则的 constitution.md；
• 至少一个反例和一份对决记录；
• 本地 Spec CI 或其可运行等价物；

• judgment.md 或一份判例记录；
• 预算与 anti-Goodhart 控制；
• 就绪门（readiness gate）与阻塞项清单；
• 反模式诊断清单。

考核通过的标志不是所有文件看起来都填满了，而是另一个人能打开该包、复现关键检查并理解为何该方案可被安全放行，或为何必须推迟。

汇总案例

围绕一个 production 事件工作。推荐的主案例是 high_memory_usage，因为它会贯穿 webhook 规范化、readiness 门以及第 11 部分的试运行。如果你围绕对决与文件仲裁来组织考核，也可以选择 autoscale_200pct 替代之。不要在一次考核中混用两个案例。

最小化问题陈述：

• AgentClinic-production 收到来自 Grafana 或 PagerDuty 的告警；
• legacy 痕迹不完整：部分规则来自事后复盘（post-mortem），部分来自 QWEN.md，部分来自口头实践；
• 自动化修复看起来有用，但可能违反影响半径限制、层级预算或 anti-Goodhart 不变量；
• 在放行之前需证明规范、计划、验证与 readiness 之间不相互矛盾。

包结构

创建目录：

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 通关的「黄金路径」参考：它展示了考核所需的足够事实量，同时不让章节膨胀为庞大的 production 文档。

将其作为规模约束。如果你的 capstone/README.md 或 validation.md 明显超过该参考的长度，请先检查是否混入了完整轨道的制品：scorebook、metric_network、完整的 out/duel.json、全部 budget plan，或详尽的聊天记录。

在第 1–12 章中寻找「如何进入 capstone/」一节。在首次通关时，它比章节完整制品清单更重要。如果该节说只需迁移一行、一个被接受的候选、一条防御性不变量或一份 readiness 结论，就不要把证据包扩展为完整 production 轨道的全部文件。

开始前，在 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 作为第二个等价的案例添加进来。目标不是搭建完美的 production 流程，而是一个小型、可复现的证据包：一个事件、一个规范缺陷、一个反例或 readiness 结论、一份阻塞项清单。

准备

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

步骤

1. 填写 capstone/genealogy.md：一条已还原需求、最少两个来源、置信级别与一个开放问题。
2. 创建 capstone/poisoned-spec.md：恰好引入一个缺陷——优先级冲突、循环或越界的隐式出口。
3. 创建 capstone/fixed-spec.md：用排除规则、模式或显式负向需求来修复该缺陷。
4. 填写 capstone/constitution.md：最少两条 immutable_principles、一条带 ttl、max_scope、rollback_condition 的 mutable_rule，以及一段简短的 governance_protocol。
5. 为所选案例运行一个可运行示例。

• 对于 high_memory_usage——使用第 11 部分「最小化教学场景」一节的命令：一次正向 readiness、一次阻塞的 stateful、一次允许与一次禁止的 dry-run。带有 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 试运行展示允许路径；readiness_block_stateful.json 给出 stateful 阻塞项；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：哪个目标指标可能开始骗人，哪个 guard 指标约束它。
5. 填写 capstone/readiness.md：最终评分、阻塞条件，以及为何有证据的 23/25 优于无证据的 25/25。
6. 走一遍第 12 部分的诊断清单，并在 capstone/antipattern-audit.md 中记录三项风险。
7. 完成 capstone/README.md：一段背景描述、命令清单、最终状态与进入 production 前的待修复清单。

完成第 12 步后，以新评审者身份重读 capstone/README.md。其中应呈现的不是全部细节，而是一条可复核的路线：需求从何而来、哪里坏了、跑了哪条命令、得出何种判定，以及什么阻塞着 production 放行。

首次通关的最小 capstone/README.md 不超过五行：

Incident-case: high_memory_usage
主要风险：在缺少完整 audit_trace 或 backup 证据的情况下进行 auto-remediation
关键检查：python3 scripts/check_readiness.py --readiness fixtures/readiness_block_stateful.json
主要阻塞项：缺少 backup_verified 的 stateful 工作负载会阻塞操作
下一步修复：为 backup 添加 evidence_ref 并重跑 dry-run

检验事实

当另一位读者能打开 capstone/README.md 并在无聊天记录的情况下回答以下五个问题时，该包即通过考核：

1. 还原了哪条需求，证据从何而来？
2. 引入了什么缺陷，如何修复？
3. 实际运行了哪项检查？
4. 为什么文件仲裁的判定或就绪门是这个结果？
5. 在 production 之前还剩下什么阻塞项？

如果其中任何一个问题都需要作者口头说明，则该包尚未就绪。

可评审痕迹

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

快速提问

书面作答，不要使用 Qwen Code。

1. genealogy.md 与 validation.md 有何区别？
2. 为什么可控带缺陷的规范应恰好包含一个缺陷？
3. 影子规范何时会进入 QWEN.md 而不进入 requirements.md？
4. 为什么 Spec CI 不能替代 Verifier？
5. judgment.md 必须包含什么，才能让争议可被复现？
6. 为什么 manual_review_floor 即使在 KPI 良好时也不能归零？
7. token_health 比单纯统计消耗的 token 更有用的原因是什么？
8. 为什么没有 evidence_ref 的 readiness 分数不能作为放行依据？
9. 何时 DEFERRED 优于形式上的 APPROVE？
10. 第 12 部分中哪种反模式最常破坏你的包？

评分标准

按 30 分评分。五个类别各 6 分，对应 production-SDD 的五个支柱：事实出处、可验证性、争议解决、约束保持与包的清晰度。等权重意味着一项强项不能弥补弱项；而在每个类别内部，6 个要点覆盖常见盲点而不至于过度细化。

出处与规范 — 6 分

• 1：genealogy.md 将需求与至少两个来源关联；
• 1：争议性事实未被当作 approved 需求；
• 1：poisoned/fixed 对包含一个缺陷与一项修复；
• 1：修复改变了可验证制品，而不仅是解释；
• 1：constitution.md 区分 immutable 与 mutable 层；
• 1：mutable 规则具有 ttl、max_scope、rollback_condition。

检查与事实 — 6 分

• 1：运行了 book2/examples/ 中至少一个可运行示例；
• 1：结果连同命令与预期迁移到 validation.md；
• 1：负向或阻塞场景被显式描述；
• 1：Spec CI 或其等价物检查需求与计划的关联；
• 1：就绪或试运行（dry-run）未绕过阻塞条件；
• 1：out/ 未被当作可评审制品。

仲裁与角色 — 6 分

• 1：judgment.md 包含判定、原因与 evidence_ref；
• 1：Verifier/Implementor/Safety 角色未混用，Coordinator 仅维护 judgment.md；
• 1：反例为最简或显式标注为非最简；
• 1：争议存在 DEFERRED 或下一步可验证步骤；
• 1：判例以可被再次引用的方式记录；
• 1：Safety-veto 或其等价物不能被多数票推翻。

Production 约束 — 6 分

• 1：预算场景描述了廉价层失败的情形；
• 1：frontier-reviewer 受风险或配额限制；
• 1：anti-Goodhart 对将 KPI 与 guard 指标关联；
• 1：manual_review_floor 被保留；
• 1：readiness 分数伴随证据；
• 1：回滚（rollback）或阻塞项在放行前已指明。

包的清晰度 — 6 分

• 1：capstone/README.md 在无外部聊天的情况下解释案例；
• 1：命令清单可在本地复现或通过可运行等价物替代；
• 1：阻塞项与改进项分开；
• 1：指向章节与模板的链接有助于回溯；
• 1：第 12 部分的诊断清单已通过；
• 1：包不包含与所选案例无关的多余机制。

25–30 分 — production SDD 闭环可接受团队评审。

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

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

考核之后

不要将整包作为模板原样迁入 production。选择两到三件最有用的制品并优先自动化它们：

• 如果需求出处最常丢失——从 genealogy.md 开始；
• 如果 CI 漏过薄弱规范——从 Spec CI 开始；
• 如果争议反复出现——从 judgment.md 与 precedents.md 开始；
• 如果 KPI 开始骗人——从 anti-Goodhart validation.md 开始。

第二卷的主要成果不是一套术语，而是在放行危险自动操作之前要求留下可验证痕迹的习惯。