主题：应用部分 5. 规范的变异测试
难度级别：中级
预计学习时间：6-8 小时（理论：2-3 小时，实践：4-5 小时）
前置条件： 熟悉 JSON Schema 和 Given/When/Then 规范结构
完成第一卷第 9 部分（验证事实与验证）
完成第一卷第 20 部分（SDD 反模式）
具备基本的命令行和 Python 3 操作技能
理解图结构基础（有向图、DFS）
具备版本控制系统（Git）使用经验
学习目标： 使用固定 seed 运行确定性变异生成器，并在重复运行时复现相同的 mutation_id 集合
配置验证回路，使其在预期的 Given/When/Then 步骤拒绝变异体，并返回精确的诊断代码
计算并解释免疫向量指标（strict_reject_rate、depth_of_diagnostics、recovery_time_p95_ms），并应用阈值进行 CI 门禁
将每个变异体与具体的 JSON Schema 规则和规范步骤关联，确保在 SDD 中的可追溯性
在 capstone/validation.md 中形成最小可审查痕迹，以将变异测试集成到合并流程中
概述：规范变异测试是一种处于标准化前沿的工程实践，它将验证器从语法守卫转变为解剖诊断工具。该方法的核心是：可控地"破坏"正确的规范（base_spec.json），创建退化的事件流程场景，并要求验证器在严格定义的步骤捕获每个缺陷，且返回可预测的诊断代码。关键原则是"一个变异体对应一个预期失败"。结果是一个由三个分量组成的免疫向量指标：strict_reject_rate（在预期步骤严格拒绝的比例）、depth_of_diagnostics（停止前诊断的有效深度）和 recovery_time_p95_ms（到稳定裁决的时间）。该实践与"规范优先"（spec-first）方法紧密关联，并将荒谬案例转化为针对未来有毒需求的回归测试集。学习材料基于 examples/stress-mutator/ 中的可运行示例，涉及事件 appointment_latency_spike 和四种变异算子：Nullify、FutureTime、EscalationCycle、PriorityContradiction。
核心概念： 规范变异测试：一种技术，其中参考工件（base_spec.json）被变异算子可控地扭曲，测试回路必须捕获每个缺陷。与手动创建单个缺陷（第 2 章）的区别在于大规模性和可复现性；与反例验证（第 4 章）的区别在于绑定到算子目录；与文件仲裁（第 8 章）的区别在于生成而非检查现成工件。
免疫指标（immunity score）：验证器鲁棒性的向量指标，由三个分量组成：strict_reject_rate（在预期步骤严格拒绝的案例比例）、depth_of_diagnostics（拒绝前诊断的有效深度，以 stack_route 中有意义的步骤数衡量）、recovery_time_p95_ms（返回稳定裁决的时间）。作为向量而非标量引入，以避免严格性提高伴随诊断盲区或性能退化的情况。
"一个变异体对应一个预期失败"原则：变异工厂的主要规则。每个变异体恰好包含一处变更，并具有固定的 expected_failure，包含诊断代码和停止点 halt_before。禁止使原因定位不可能的复合变异。错误示例：一个变异体同时清空 service_id、展开升级图并反转优先级。正确示例：Nullify 算子仅清空 severity，expected_failure.code = EMPTY_REQUIRED_FIELD，halt_before = When:evaluate_sla_window。
变异工厂：基于正确 base_spec.json 的确定性变异器。将规范解析为 AST，包含 Given/When/Then 节点、SLA 矩阵、升级规则和 JSON Schema 片段。应用固定 seed 的算子以确保可复现性。对验证者（Verifier）与实现者（Implementor）的对决至关重要：争议案例可以复现，交给双方角色并检查合同违反。
变异算子：Nullify（清空字段——空字符串、null、空数组）、FutureTime（将时间戳移至协商的 now 之后的未来）、EscalationCycle（在升级图中添加反向边）、PriorityContradiction（引入相互矛盾的优先级规则）。未来扩展：RecursiveDependency（计算字段之间的间接递归）。
验证器疫苗接种：规范变异测试的形象说法。验证器接收可控损坏的输入，并必须在预期步骤拒绝它们。将荒谬案例转化为防止回归的"疫苗"。
退化场景类别：空字段（任何没有它就无法选择安全操作的空值：空字符串、空所有者数组、缺失的 severity、service_id、runbook_ref）、时间异常（形式上正确的 ISO 标签但因果关系被破坏）、可逆升级循环（所有者的无限重新定义）、递归依赖（具有潜在无限展开的间接计算链）。
确定性与 seed：固定生成器种子（例如 20260517）保证重复运行时 manifest.json 的逐位相同。连续两次运行具有相同顺序的 mutation_id 是最低质量控制。没有确定性就无法建立回归基线和角色对决。
JSON Schema 之外的图检查：JSON Schema 擅长检查数据形式，但无法表达路由的拓扑行为。对于 EscalationCycle，验证器构建有向图并运行 white/gray/black 状态的 DFS。检测到 gray 节点返回最小循环。对于 PriorityContradiction——类似的反向转换控制，区分代码 CYCLE_ESCALATION 和 PRIORITY_REVERSAL。
时间锚点和最大反应延迟策略：三个必需锚点：event_detected_at、event_received_at、来自受控时间源的协商 now。三个失败代码：INVALID_TIME_ANCHOR（response_timestamp 在未来——输入负载问题）、NEGATIVE_RESPONSE_LAG（负延迟——规范化问题）、STALE_INCIDENT_WINDOW（事件超出窗口——SLA 规则问题）。不同代码对 SDD 日志至关重要。
递归依赖和最大解析深度：与循环的区别在于没有短回路。典型链：owner ← priority ← blast_radius ← owner_group ← owner。展开限制（例如 8）带尝试轨迹。超出 → RECURSION_LIMIT 带字段链，而非伪装为超时。保护 LLM 执行器免于无限细化。
变异 CI 门禁：违反任一阈值时阻止合并：strict_reject_rate < 0.98、depth_of_diagnostics < 3、recovery_time_p95_ms > 1200。还阻止旧 mutation_id 的遗漏、诊断深度恶化、时间限制超出。示例：python3 scripts/ci_gate.py --strict-reject-min 0.98 --diag-depth-min 3 --recover-ms-p95 1200 --fail-on-regression。
可审查痕迹和 SDD 证据：capstone/validation.md 中的最小片段：seed、算子列表、三个免疫指标、裁决。完整痕迹：mutation_id、规范差异、原始和变异片段、拒绝日志、诊断代码、stack_route、JSON Schema 规则链接。目录 out/mutations 是本地的，不提交；真相来源是可复现命令。
实践练习： 标题：验证变异生成器的确定性
问题：给定正确的 base_spec.json 和 seed=20260517 的 mutate_specs.py 脚本。需要证明生成器是确定性的：连续两次运行应产生相同的 manifest.json。一名学生运行了一次脚本并看到 4 个变异文件。审查者无法检查可复现性。修正流程并解释为什么一次运行不够。
解答：步骤 1：第一次运行：python3 scripts/mutate_specs.py --base base/base_spec.json --seed 20260517 --operators Nullify,FutureTime,EscalationCycle,PriorityContradiction --out out/mutations_run1。保存 manifest.json。步骤 2：删除 out/mutations_run1 并用完全相同的命令和 out/mutations_run2 再次运行。步骤 3：通过 diff out/mutations_run1/manifest.json out/mutations_run2/manifest.json 比较。预期：0 行差异。步骤 4：与标准比较：diff out/mutations_run1/manifest.json manifest.example.json。预期：0 行。步骤 5：检查 mutation_id 顺序稳定性：jq '.mutations | map(.mutation_id)' out/mutations_run1/manifest.json 应与 run2 匹配。解释：一次运行无法区分确定性生成器和随机噪声。只有重复运行才能创建回归基线。没有这一点，验证者/实现者对决和 CI 检查都不可能。
难度：初级
标题：通过诊断深度定位变异体泄漏
问题：Nullify 变异体清空 severity。验证器在 Then:notify_primary_owner 步骤停止，代码为 MISSING_OWNER，而非 When:evaluate_sla_window 上预期的 EMPTY_REQUIRED_FIELD。strict_reject_rate = 1.0（全部拒绝），但 depth_of_diagnostics = 1.2（低于阈值 3）。分析为什么这是回归，并描述验证器和 expected_failures.json 中的最小更改以恢复阈值。
解答：步骤 1：诊断问题。空的 severity 渗透太深：验证器没有在入口（Given:incident_received）检查字段的必需性，并尝试用无效数据计算所有者。这产生了向未分类事件错误通知的风险。步骤 2：在规范化器中添加 guard：在 evaluate_sla_window 阶段之前检查 severity.minLength 和 severity ∈ enum。步骤 3：更新 fake_validator.py：severity 为空时返回 EMPTY_REQUIRED_FIELD，halt_before = When:evaluate_sla_window，stack_route = ['schema.normalize', 'Given:incident_received', 'field.severity.check', 'halt']。步骤 4：检查 expected_failures.json：对于 mutation_id m_20260517_nullify_855e4297f7，预期 code=EMPTY_REQUIRED_FIELD，halt_before=When:evaluate_sla_window，depth=4。步骤 5：重新运行 immunity_score.py。预期：strict_reject_rate 保持 1.0，depth_of_diagnostics 恢复到 ≥3，recovery_time_p95_ms 单独检查。教训：高 strict_reject_rate 掩盖了诊断盲区。免疫向量指标捕获了这种回归。
难度：中级
标题：考虑算子优先级的 CI 门禁配置
问题：事后分析历史显示，60% 的生产事件与错误时间窗口相关，25% 与升级循环相关，10% 与空字段相关，5% 与优先级冲突相关。每次运行的令牌预算为 100 个变异体。标准均匀分布（每类 25 个）不能反映历史脆弱性。重建算子选择策略，论证选择并展示这如何影响 expected_failures.json 和免疫阈值。
解答：步骤 1：将均匀分布替换为按历史加权的分布：FutureTime 40 个变异体，EscalationCycle 25 个，Nullify 20 个，PriorityContradiction 10 个，5 个保留给新模式。步骤 2：在 mutate_specs.py 中设置 --operator-weights FutureTime=0.40,EscalationCycle=0.25,Nullify=0.20,PriorityContradiction=0.10。步骤 3：更新 expected_failures.json：增加时间代码的详细程度（INVALID_TIME_ANCHOR、NEGATIVE_RESPONSE_LAG、STALE_INCIDENT_WINDOW），为每个子类型设置不同的 halt_before。步骤 4：重新评估阈值：随着变异体数量增加，strict_reject_rate 可以提高到 0.99，depth_of_diagnostics 保持 ≥3（但时间异常要求 ≥4），recovery_time_p95_ms 通过优化图检查降低到 1000。步骤 5：在 ci_gate.py 中添加 --weighted-fail-on-regression，不仅比较全局指标，还比较每个算子的 strict_reject_rate。步骤 6：在 validation.md 中记录论证："根据 2024 年 Q1-Q3 事后分析提高 FutureTime 优先级，参见事件 #INC-2047、#INC-2089"。教训：定向模糊测试检查历史脆弱点，而非将预算浪费在均匀混沌上。
难度：高级
标题：递归依赖的追踪和 max_resolution_depth 配置
问题：RecursiveDependency 变异体创建链：owner 从 priority 计算，priority 从 blast_radius，blast_radius 请求 owner_group，owner_group 需要 owner。验证器在 30 秒后超时崩溃。stack_route 缺失。开发者建议"简单地将超时增加到 60 秒"。反驳此方案，实施带可复现轨迹的 max_resolution_depth，并展示 validation.md 中的记录。
解答：步骤 1：拒绝增加超时：这掩盖问题，使 CI 不可预测，不提供修复合同的诊断。步骤 2：在 fake_validator.py 中添加带解析栈跟踪的依赖解析器：resolution_stack = []，进入字段时 push，退出时 pop，重复 push 同一字段时检测循环。步骤 3：设置 max_resolution_depth = 8。超出时返回 RECURSION_LIMIT 带完整链：['owner', 'priority', 'blast_radius', 'owner_group', 'owner']。步骤 4：在日志中添加尝试轨迹：resolution_attempts 带每个步骤的时间戳。这允许区分递归和复杂依赖。步骤 5：在 immunity_score.py 中检查 RecursiveDependency 变异体的 depth_of_diagnostics 包含解析轨迹（计为检测前的 len(resolution_attempts)）。步骤 6：validation.md 中的记录：``yaml stress_run: seed: 20260517 operators: [Nullify, FutureTime, EscalationCycle, PriorityContradiction, RecursiveDependency] recursive_guard: max_resolution_depth: 8 verdict: PASS strict_reject_rate: "1.0 >= 0.98" depth_of_diagnostics: "5 >= 3" recovery_time_p95_ms: "400 <= 1200" `` 教训：无限展开应该是可观察和可控的，而非被超时替代。
难度：高级
案例研究： 标题：在自动事件管理平台中实施变异测试
场景：SRE 平台团队（150 名工程师，40 个微服务）通过入口处的 JSON Schema 验证器自动化管道管理事件。在一系列生产事件之后——其中空 severity 字段渗透到通知阶段并导致向 VP on-call 的错误升级——团队决定实施规范变异测试。基础场景是 appointment_latency_spike（SLA 10 分钟，升级 appointments_oncall → sre_lead）。
挑战：三个关键问题：（1）验证器检查 JSON 语法但不捕获语义缺陷——由于模式错误，空字符串 severity 通过了 minLength=0；（2）缺乏可复现性：手动测试用例是临时创建的，在规范更新时丢失；（3）CI 遗漏回归，因为唯一指标"所有测试通过"掩盖了诊断恶化——验证器开始返回 GENERIC_VALIDATION_FAILED 而非精确代码，调试时间从 15 分钟增加到 4 小时。
解决方案：团队基于课程中的 stress-mutator 实施了变异工厂。步骤 1：固定 seed=20240715 和 4 个算子（Nullify、FutureTime、EscalationCycle、PriorityContradiction），根据事件历史 FutureTime=0.45 优先。步骤 2：将每个变异体与 Given/When/Then 步骤和 JSON Schema 规则关联——例如，Nullify(severity) → Given:incident_received，$.properties.severity.minLength。步骤 3：带阈值的免疫向量指标：strict_reject_rate ≥ 0.98，depth_of_diagnostics ≥ 3，recovery_time_p95_ms ≤ 1200。步骤 4：CI 门禁，任何违反或旧 mutation_id 遗漏时阻止合并。步骤 5：SDD 证据：mutation_id、差异、stack_route、规则链接。步骤 6：图检查添加 white/gray/black 状态的 DFS，时间检查添加三个锚点和三个失败代码。
结果：3 个月内：strict_reject_rate 从 0.71 提高到 0.99，depth_of_diagnostics 从 1.8 到 4.2，recovery_time_p95_ms 从 3400 到 890 毫秒。空字段导致的错误升级减少 94%。与验证相关的事件调查时间从 4 小时中位数降至 25 分钟。关键回归在 PR 阶段被捕获：开发者更改检查顺序，将 FutureTime 变异体的 halt_before 从 When:evaluate_sla_window 移到 Then:notify_owner；CI 门禁阻止合并，团队在分析前回滚更改。
经验教训： 免疫向量指标至关重要：如果没有三分量控制，strict_reject_rate 提高到 0.99 而 depth_of_diagnostics 降至 1.2 将是虚假成功
确定性（固定 seed）允许将变异转化为回归测试集：旧 mutation_id 成为防止未来更改的"疫苗"
带 stack_route 和 JSON Schema 链接的 SDD 证据将新工程师入职时间从一周缩短到一天
按事后分析历史优先化算子比均匀分布更有效：FutureTime 45% 预算覆盖 78% 历史缺陷
相关概念： 免疫指标（strict_reject_rate、depth_of_diagnostics、recovery_time_p95_ms）
"一个变异体对应一个预期失败"原则
确定性与 seed
变异 CI 门禁
JSON Schema 之外的图检查
SDD 证据和可审查痕迹
标题：因忽视 recovery_time 导致大版本发布失败
场景：电子商务平台准备黑色星期五促销。验证团队添加了 50 个新变异算子来检查支付管道规范。strict_reject_rate = 0.97，depth_of_diagnostics = 3.5——在阈值内。CI 门禁通过了版本。
挑战：recovery_time_p95_ms 由于支付路由循环的复杂图检查，从 800 毫秒悄悄增长到 4500 毫秒。在峰值负载期间，验证器成为瓶颈：12% 的请求在验证时超时，级联触发重试和下游服务过载。团队在发布时未检查 recovery_time，认为它是"辅助指标"。
解决方案：45 分钟内回滚版本。分析显示，每次请求都对 200 个节点的升级图执行 DFS，而非缓存拓扑排序。优化：加载规范时预执行图分析，变异时增量检查。引入硬阈值 recovery_time_p95_ms ≤ 1200 并阻止合并。连续 3 次运行超过 800 毫秒时添加告警。
结果：优化后 recovery_time_p95_ms 降至 600 毫秒。黑色星期五期间验证器处理 340% 峰值负载无超时。关键流程变更：recovery_time 成为免疫向量的平等分量，而非"奖励"指标。
经验教训： 三分量免疫向量防止为优化一个指标而损害其他指标
recovery_time 对生产负载至关重要："正确"但拖慢 CI 的验证器会诱发变通做法和生产故障
拓扑不变时增量图检查比每次请求全量 DFS 更高效
相关概念： 免疫指标和 recovery_time_p95_ms
变异 CI 门禁
JSON Schema 之外的图检查
增量验证
学习建议： 按顺序学习材料：先运行示例（步骤 1-7），然后理论核心概念，然后自测题。不运行脚本就阅读理论会产生理解的幻觉
必须使用相同 seed 重复运行并通过 diff 比较 manifest.json。这是不可跳过的最低质量控制。用截图或终端副本固定结果
创建对应表：变异算子 → 退化场景类别 → Given/When/Then 步骤 → JSON Schema 规则 → 诊断代码 → 预期 halt_before。此表是配置自己项目的基础
实验违反阈值：临时修改 fake_validator.py 以遗漏变异体或移动 halt_before，观察免疫向量的哪个分量捕获它。对回归的实际理解比理论知识更重要
视觉学习风格：在纸上绘制课程 mermaid 图表的流程图，标记您的项目与教学 appointment_latency_spike 的不同之处
听觉学习风格：向同事或在语音消息中解释"一个变异体对应一个预期失败"原则。如果 60 秒内无法清楚表述——返回材料
动觉学习风格：修改 base_spec.json 添加新字段（例如 runbook_ref），为其创建 Nullify 算子，更新 expected_failures.json 并运行完整管道。手动创建新算子加速掌握
将可选的 Qwen Code 步骤用作审查训练，而非替代可运行检查。将其输出与您的 immunity_score.py 事实比较——差异表明理解或工具问题
在单独文件中维护"变异日志"：每次运行固定 seed、算子、三个指标、意外行为。此日志将成为 capstone/validation.md 的基础并帮助跟踪学习进度
转向生产轨道（阈值校准、CI 门禁）时参考附录 D.1，但仅在熟练通过最小场景后。过早深入校准细节会分散对基础原理理解的注意力
小组学习：组织"对决"——一名参与者更改 base_spec.json 或 fake_validator.py，另一名必须找出哪个 mutation_id 损坏。这模拟验证者与实现者的真实交互
额外资源： 教学示例 stress-mutator 源代码：book2/examples/stress-mutator/ —— 包含 base_spec.json、变异脚本、验证和免疫计算的可运行示例。所有实践步骤的主要来源
Github spec kit：https://github.com/github/spec-kit —— 本章依赖的"规范优先"（spec-first）方法。合同先于代码规划和实现
第一卷第 9 部分（验证事实）：../book/part-09-feature-validation.md —— Given/When/Then 事实纪律，没有它变异没有意义。变异体检查预期步骤的失败事实
第一卷第 20 部分（SDD 反模式）：../book/part-20-sdd-antipatterns.md —— 与变异算子绑定的经典过程错误目录
第 11 部分（教学功能 /agents）：../book/part-11-second-feature-phase.md —— 教学案例 appointment_latency_spike 的来源
第 12 部分（MVP 和空评论文本）：../book/part-12-mvp.md —— 事实纪律的最简单示例：空评论文本必须被拒绝。此处相同逻辑推广到算子集合
第 10 部分（goodhart-validator 和 ci_gate.py）：examples/goodhart-validator/scripts/ci_gate.py —— 带阈值 CI 门禁的类似概念示例
附录 D.1（阈值校准）：appendix-d-threshold-calibration.md#d1-变异测试-第-5-章 —— 完整生产轨道："低/默认/高"表、阈值偏移练习、重新评估信号
JSON Schema 文档：https://json-schema.org/ —— 形式约束参考，由模式外的图和时间检查补充
有向图循环检测算法（DFS white/gray/black）：Tarjan 的经典实现或 CLRS（Cormen、Leiserson、Rivest、Stein）—— EscalationCycle 和 RecursiveDependency 的基础
总结：规范变异测试将验证器从被动的语法守卫转变为主动的解剖诊断工具。关键原则：固定 seed 的确定性变异工厂、严格的"一个变异体对应一个预期失败"规则、三分量免疫向量指标（strict_reject_rate、depth_of_diagnostics、recovery_time_p95_ms）、每个变异体绑定到 Given/When/Then 步骤和 JSON Schema 规则、阻止回归的 CI 门禁、带 mutation_id 和 stack_route 轨迹的 SDD 证据。教学最小要求——运行 examples/stress-mutator/ 产生可复现 manifest.json，所有变异体通过预期失败，免疫指标为绿色。可审查痕迹在 capstone/validation.md 中固定为 seed、算子、三个指标和裁决。该实践旨在为真实自动事件管理项目创建退化规范生成器，其中荒谬案例成为防止有毒需求和隐藏级联故障的回归防护。