主题：附录C. 应用级SDD检查清单
难度级别：中级
预计学习时间：8-12小时（理论+实践）
前置条件： 已完成SDD课程第一卷的学习（规范前、实现前和合并前的基础检查清单）
理解工件结构：requirements.md、plan.md、validation.md、QWEN.md
具备CI/CD工作经验和对Git工作流的基本理解
熟悉以下概念：领域模型、API契约、JSON Schema
已阅读应用卷的第0部分（选择学习用incident-case）
学习目标： 将附录C的检查清单作为应用级SDD每个阶段的操作参考，从准备到最终生产验收
实施质量控制机制：规范网关（Spec CI）、文件仲裁、毒化规范和带明确回滚条件的自动修复
通过12项诊断识别并消除应用级周期的反模式，在≥3项失败时做出停止自动化的决策
形成完整的capstone工件包并具备可追溯性：genealogy.md、poisoned/fixed对、judgment.md及证据基础
概述：应用卷的附录C是一个操作参考——建立在第一卷基础检查清单之上的增强层。它涵盖应用级周期的八个关键控制点：工作准备、从遗留系统恢复规范、引入毒化规范以验证流程、启用Spec CI、对有争议变更进行文件仲裁、优化生产指标并防范古德哈特定律效应、自动修复事件、审计反模式和最终生产验收。每个检查清单都设计为网关：必须通过检查才能进入下一阶段。流程模板（合并请求、回顾、/clear请求和重新规划请求）放在examples/templates/目录中。应用级的特点在于从"拥有工件"转向"工件在生产环境中的证据性运作"：每个需求都可追溯，每个变更都有依据，每个风险都由不变量控制。
核心概念： 规范网关（spec ci）：自动化的检查机制，在违反结构规则时阻止变更推进。要求：稳定的REQ-*标识符、计划到需求的反向追溯、JSON示例的模式验证、信息丰富的错误消息（文件、行号、规则、原因、操作）。Spec CI作为"执行前的闸门"运作，而非事后的评审。
毒化规范（poisoned spec）：流程验证方法：引入恰好一个受控缺陷，描述预期症状，记录恢复标准。修复必须涉及spec/plan/validation中的至少两项，而非仅文本解释。检验质量控制系统能否发现并定位错误。
文件仲裁：通过文件差异而非聊天讨论来解决争议的机制。角色：协调员（流程）、实现者（代码）、验证者（可验证的证据）。重复性决策记录在precedents.md中。设有转为人工评审的停止条件。
古德哈特定律与反古德哈特指标：原则：当指标成为目标时，它就不再是好的指标。防护：每个目标指标都配对一个不变量指标，设有行为扭曲时停止的"红色按钮"规则。更改阈值即更改风险，需遵循相应程序。
影响半径（blast radius）：自动修复时受影响系统的边界。控制问题：影响半径是否已知、是否有dry-run、执行前是否记录回滚条件、影响半径扩大或再次失败时是否需要人工确认。高风险事件需要两个独立的恢复确认。
痕迹（trace）与evidence ref：决策的可复现标识符：来源、策略版本、提示词哈希。QWEN.md中的每条记录包含作者、证据和TTL。trace字段必须有evidence_ref。确保系统的可审计性和漂移调试。
可变规则与ttl：有有效期的规则。禁止：无TTL或TTL>90天的规则。强制复审防止过时限制僵化和治理中的技术债务积累。
预算上限与层级（tiers）：系统层级切换时的财务和运营控制。每次切换都有预算上限和应急模式。防止扩展时的成本失控增长。
人工评审底线（Manual review floor）：不依赖KPI数值的不可动摇的人工检查最低限度。防止关键决策的完全自动化。即使达到高自动化水平也予以保留。
Genealogy.md：最终包的工件：需求、来源、置信度级别、开放问题。确保规范每个元素的来源透明度和对不确定性的诚实态度。
练习： 标题：应用级周期准备度审计
问题：你收到了一个声称已准备好开始应用卷的团队仓库。检查以下事实：(1) capstone/目录缺失，(2) README中未区分[runnable]和[project script]，(3) requirements.md存在，但plan.md通过文本隐式引用而非通过REQ-*标识符，(4) validation.md包含无模式的JSON示例。列出阻塞项和带优先级的消除计划。
解答：步骤1：阻塞项——capstone/缺失。操作：创建目录结构，规划最终包。步骤2：阻塞项——命令类型未区分。操作：遍历所有章节，明确标记，更新README。步骤3：阻塞项——缺乏稳定标识符。操作：引入REQ-*编号，更新plan.md添加直接链接。步骤4：阻塞项——示例无法验证。操作：创建JSON Schema，在CI中添加验证。优先级：3和4——对Spec CI至关重要，1和2——对最终验收至关重要。期限：2个工作日。
难度：中级
标题：毒化规范设计
问题：你的支付处理系统有需求REQ-PAY-07："操作超时——30秒"。创建一个毒化规范：引入恰好一个缺陷，描述预期症状，设定恢复标准。确保修复至少涉及spec/plan/validation中的两个工件。
解答：步骤1：缺陷——在plan.md中将超时改为300秒（服务配置部分），保持requirements.md不变。步骤2：症状——p99延迟指标将升至45秒以上，用户会在服务器完成操作前在客户端收到超时，导致支付重复。步骤3：恢复标准——p99延迟<<10秒，validation.md中无重复（通过trace_id检查）。步骤4：修复涉及：plan.md（恢复为30秒），validation.md（添加trace_id+超时一致性检查）。requirements.md无需更改，这展示了职责分离。
难度：中级
标题：反古德哈特协议事件分析
问题：团队优化了"每日关闭工单数"指标。一个月后：工单2分钟关闭，但复发率上升400%，客户满意度下降。指标达到150%目标。团队想"将标准提高到200%"。应用指标优化前的检查清单。
解答：步骤1：停止——应用红色按钮规则：复发率增长>50%——停止条件。步骤2：分离：目标指标（工单/天）与不变量（复发率<<10%，NPS>30）分离。步骤3：回放：不仅检查聚合值（平均值），还要检查行为漂移——解决时间分布、"快速关闭→重新打开"的相关性。步骤4：痕迹：记录策略版本、接受150%决策的提示词哈希。步骤5：阈值变更——作为风险变更处理：需要反古德哈特指标分析、安全部门批准、更新governance_protocol。结论：提高到200%——拒绝，恢复至100%并添加复发率不变量。
难度：高级
标题：文件仲裁模拟
问题：争议：实现者在plan.md中添加了步骤"API响应缓存24小时"，验证者拒绝——需求REQ-DATA-03要求"数据在1小时内保持最新"。协调员在聊天中收到15条带论据的消息。应用文件仲裁协议。
解答：步骤1：停止聊天讨论，宣布转入文件仲裁。步骤2：实现者创建分支，包含两个plan.md版本：(A)原始24小时缓存，(B)修改为1小时缓存+陈旧数据fallback。步骤3：验证者提供可验证证据：(A)与(B)的差异、带时间旅行时效性检查的JSON测试、两个版本的CI日志。步骤4：决策：接受(B)，记录在precedents.md中："缓存与时效性冲突时——fallback至陈旧数据，TTL=要求时效性"。步骤5：停止条件：若争议涉及存储架构——上报架构委员会。解决时间：2小时，而非2天聊天。
难度：中级
标题：反模式审计：决策制定
问题：对假设团队进行12项检查清单审计。事实：(1) constitution.md仅在冲刺结束时检查，(2) mutable_rules中有3条规则无TTL，(3) 毒化规范失败后仅更改了README中的解释，(4) CI失败——放宽了validation.md，(5) "部署/天"指标无反古德哈特配对。其余项目——正面。附录C要求什么决策？
解答：步骤1：统计负面回答：5项（1、2、3、4、5）。步骤2：应用规则：≥3项负面回答→禁止添加新自动化层。步骤3：优先级：项目4（CI失败时放宽验证）——关键，需立即回滚和根因分析。项目3——第二关键，需重新进行毒化规范周期并更改工件。项目2——运营性，指定负责人，设置90天TTL。项目1和5——结构性，纳入冲刺计划。步骤4：控制：2周后重新审计，目标——≤2项负面回答。
难度：高级
案例研究： 标题：金融科技初创公司支付平台引入Spec CI
场景：50个微服务、8个团队、每天200+PR的初创公司。问题：40%的生产回滚由实现与需求不符引起，同时requirements.md存在但未与代码关联。管理层决策："一个月内引入自动化"。
挑战：团队将要求理解为"又一个CI"。实施了检查requirements.md文件存在的机制，但未检查结构。2个月后：文件存在，但REQ-*标识符重复，plan.md引用不存在的需求，validation.md中的JSON示例未经验证。回滚未减少。管理层要求"加强自动化"——添加语义ML检查。
解决方案：应用附录C的"启用规范网关前"检查清单。停止：发现5项检查中有7项违规。决策——不添加ML，而是解决基础失败。行动：(1) 用领域前缀标准化REQ-*（PAY-、AUTH-、LED-），(2) 引入反向追溯：plan.md每项以[REQ-...]开头，(3) 所有API示例的JSON Schema，(4) 结构化CI消息：文件、行号、规则、原因、操作。关键：Spec CI设为必需状态检查——失败时PR被阻止。
结果：6周后：需求不符导致的回滚从40%降至8%。评审时间缩短30%，因为验证者获得了机器可验证的工件。4个月后：添加反古德哈特指标"从不符发现到修复的时间"——防止了向"漂亮但无用"的requirements.md的扭曲。
经验教训： 无基础网关的自动化加剧混乱而非秩序——≥3项失败规则有效
CI消息必须是可操作的：开发者理解失败原因耗时<<2分钟
plan→需求的反向追溯允许需求变更时自动找到受影响任务
相关概念： 规范网关（Spec CI）
需求反向追溯
≥3项失败时停止自动化规则
标题：受控影响半径的自动事件修复
场景：云提供商，Kubernetes集群自动扩展系统。夜间峰值事件：API延迟上升300%，触发器启动，系统开始扩展——创建了500个而非50个新pod，耗尽集群预算并导致相邻服务级联故障。
挑战：原始自动修复系统没有：(1) 影响半径限制，(2) 扩展dry-run，(3) 记录的回滚条件，(4) 扩大时的人工确认。"智能"系统基于聚合值做决策，未检查行为漂移。
解决方案：应用"优化生产指标前"和"自动修复前"检查清单。引入：(1) 影响半径——单个服务最多2倍当前副本，无人工确认禁止级联扩展；(2) dry-run：Kubernetes调度器模拟及资源评估；(3) 回滚条件：若扩展后5分钟延迟未下降——回滚至原始状态；(4) 影响半径>1个服务的事件需双重恢复确认。
结果：下一次类似峰值：系统创建45个pod（在2倍限制内），延迟恢复正常。Dry-run预测集群CPU耗尽——触发器切换至应急模式，将流量重定向至备用区域。恢复时间从47分钟缩短至8分钟。事件成本：从$120K（SLA罚款+资源超支）降至$3K（流量切换）。
经验教训： 无限制的影响半径不是自动修复，而是自动灾难
分布式系统中的dry-run必须考虑全局资源，而非仅目标服务的本地指标
执行前记录的回滚条件防止事件恐慌中的"遗忘"
相关概念： 影响半径（Blast Radius）
Dry-run与安全预检
古德哈特定律的红色按钮规则
双重恢复确认
标题：最终生产验收：从聊天到证据基础
场景：4人团队完成6个月计费系统迁移项目。准备验收时发现：capstone/README.md包含与客户聊天的历史副本，genealogy.md缺失，judgment.md只有一句话"一切正常"，没有poisoned/fixed对。
挑战：团队将应用周期理解为"写代码并在聊天中解释"。工件是回顾性创建的，无可追溯性。客户需要可审计的基础以进行监管检查（PCI DSS）。
解决方案：应用"最终生产验收前"检查清单作为恢复框架。行动：(1) README.md重写：通过领域模型描述案例，不提及聊天；(2) 为每个关键需求创建genealogy.md（PAN存储、加密、审计）——含来源（PCI DSS条款）、置信度级别（高/中/低）、开放问题；(3) 恢复poisoned/fixed对：在PAN验证中引入缺陷，在validation.md中记录修复；(4) judgment.md： verdict"有条件适用"，原因——genealogy中有2个中等置信度级别，evidence_ref指向测试，下一步——季度重新评估；(5) 添加预算和反古德哈特层及阻断性不变量。
结果：验收通过，标记"需提高置信度"。监管检查：genealogy.md被接受为需求来源的证据。一季度后：2个开放问题关闭，置信度提高，judgment.md更新为"适用"。团队将genealogy创建与开发并行实施，而非回顾性进行。
经验教训： 过程中创建的Genealogy.md需10%时间；回顾性恢复需300%
genealogy中的开放问题不是软弱的表现，而是诚实的标志；其缺失引发怀疑
带verdict"有条件适用"和计划的judgment.md，比无依据的"适用"更有价值
相关概念： Genealogy.md与置信度级别
Poisoned/fixed对作为流程证据
带verdict和下一步的judgment.md
就绪性结论：阻塞项与改进项的区分
学习建议： 将检查清单作为网关而非形式：负面回答时——停止并消除，而非勾选"稍后修复"
创建物理或数字"项目护照"——附录C的8个控制点表格，记录通过日期、负责人、证据链接
视觉学习者：构建流程图——从"开始前"到"最终验收"——并标记每个阶段使用的examples/templates/模板
实践者：对当前项目进行12项反模式检查清单审计；真实负面回答计数比理论阅读更有力
听觉学习者：成对讨论案例——通过角色扮演更好理解文件仲裁中的协调员、实现者、验证者角色
从第一次争议起记录"先例"（precedents.md）——重复情况的时间节省超过维护成本
将TTL用作规则的"死亡提醒"：到期前一周设置日历提醒
额外资源： 流程模板（examples/templates/）：pr-template.md——带需求强制链接的合并请求结构；retrospective.md——聚焦证据的回顾格式；clear-prompt.md和replan-prompt.md——/clear和重新规划的最小请求
第0部分——生产实验室：选择和准备学习用incident-case，区分[runnable]和[project script]，创建capstone/
第12部分——生产反模式：附录C快速检查清单针对的12项反模式的完整解析
第一卷附录C：规范前、实现前、合并前的基础检查清单——应用级构建的基础
JSON Schema规范：创建validation.md验证模式的文档（json-schema.org）
PCI DSS需求检查清单：创建带监管可追溯性的genealogy.md的外部需求来源示例
总结：应用卷的附录C将SDD从方法论转变为操作系统：八个带明确网关的控制点、12项反模式审计作为流程健康传感器、带证据基础的最终验收。关键原则：执行前网关（而非事后评审）、文件仲裁替代聊天讨论、指标的反古德哈特防护、自动修复的受控影响半径、≥3项失败时停止自动化。成功应用不需要死记硬背，而是内在接受文化："负面回答不是失败，而是被阻止的生产失败"。