MatrixSpec 代际演进简史
直接答案
这条演进线不是单纯追逐更高分，而是每一代从上一代轨迹中找出一个可证伪的 Weakness，再选择一个主要 Proposal 做下一代干预：
Mermaid source preserved; this page has no external renderer.flowchart LR
H0["H0<br/>恢复责任不可达"] --> H1["H1 / H01<br/>加入可达 back / repair"]
H1 --> H02["H02<br/>删除独立 Validation"]
H02 --> H03["H03<br/>逐义务 Implementation readiness"]
H03 --> H04["H04<br/>Review 绑定 Controller evidence"]
H04 --> H05["H05<br/>修复跨阶段权威冲突路由"]
H04 --> H052["H052<br/>统一终止合同并压缩为 Spec → Implement"]
H052 --> H0601["H0601<br/>语义闭包 + REQ 级可见证据"]
Bare["Bare / no-SDD comparator baseline<br/>独立于 H generation"]
这里的仓库正式 generation ID 是 H1；历史讨论中也把它称为 H01。H04 之后不是 H04 → H05 → H052 的串行关系，而是从同一个 H04 证据分裂出的两条独立路线：
- H05：选择 H04 post-formal
W-04 → P-04，解决跨阶段权威冲突被退回错误 owner 的问题。 - H052：选择 H04 post-formal
W-01 → P-01，解决同一 Implement context 同时暴露两个终止合同的问题；后续又明确采用更精简的 Change Spec → fresh Implement 工作流，并把产品验证与 Audit 作为非阻断测量。 - H0601：直接继承 H052
a601aa8，处理 H052 retrospective W-01/P-01（semantic closure）与 W-02/P-02（REQ-bound visible evidence）。仓库没有 canonical H06/W-xx Weakness Card；H060101–H060103 是结构检查码，不是 Weakness ID。
演化简史统一使用每一代完整 /24 统计，D8 始终计入分母。本文只发布完整 24-cell 口径。
一眼看懂每一代
| 代际 | 进化入口 | 主要改动 | 完整 /24 描述性结果 | 结论 |
|---|
| H0 | 基线，无上游 Card；运行后暴露 W-03 | 提供基线与 Root Cause，不是 treatment | workflow 18/24；focused 19/24；Judge 90.1250 | 找到了控制面问题；尚未解决 |
| H1 / H01 | H0 W-03 → P-02 | structured blocked verdict、back、invalidation、repair、reconfirm/recheck | workflow 10/24；focused 18/24；Judge 93.5208 | 建立了可达恢复能力，但聚合 completion 没有提升；同时换了 Candidate 模型，不能单因果归因 |
| H02 | H1 W-01 → P-01 | 删除 standalone Validation，把必要验证责任并入 Review；保留 v2 recovery | workflow 17/24；focused 19/24；Judge 94.4792 | 相对 H1：workflow +7、focused +1，tokens -21.85%；方向改善但不是随机因果证明 |
| H03 | H02 W-01 → P-01 | readiness 改为逐项 义务 → 实现证据 → 验证证据 | workflow 18/24；focused 18/24；Judge 94.8958 | 相对 H02：workflow +1、Judge +0.4167；focused -1、tokens +11.79%，说明闭包更强但有成本 |
| H04 | H02 agent-derived W-02 → P-01 | positive Review 必须绑定 current/passed focused receipt | workflow 12/24；focused 17/24；Judge 89.7917 | false-terminal predicate 为 0，但 H03 也是 0；completion/Judge 下滑，不能称为收益已证实 |
| H05 | H04 W-04 → P-04 | authority conflict 成为独立 recovery outcome，路由到最早必须变化的权威 owner | workflow 15/24；focused 20/24；Judge 95.0000 | 相对 H04：workflow/focused 各 +3；两格自然冲突 2/2 正确路由并重确认。Fast/priority 与运行 amendment 使总体提升只能描述性解释 |
| H052 | H04 W-01 → P-01 | 单一终止合同；进一步形成 exact Change Spec → fresh Implement；质量与 Audit 非阻断 | workflow 24/24；product 19/24；Audit finding runs 3/24；Judge 92.7708 | 相对 H04：workflow +12、product +2、Judge +2.9792、tokens -46.82% |
| H0601 | H052 W-01/P-01 + W-02/P-02 | 保持两阶段架构；Operator exact-digest 语义确认；EXHAUSTED 不确认；每个 REQ 声明并独立执行 Candidate-visible verification | workflow 24/24；treatment audit 13/24；external focused 18/24；pre-hidden visible verification 9/24；Judge 4528/4800 = 94.3333 | 三类红项包含 adoption、currentness、tool/runtime 等不同失败，不能合并成 product quality；Judge uplift 只作描述性记录 |
独立对照：Bare / no-SDD comparator baseline
Bare 是独立的 direct-Candidate condition comparator，不是 H lineage 的新一代，也不是 MatrixSpec treatment。它不使用 SDD、Operator 或 Reviewer，capabilities={}，但保留普通 multi-agent 与同一套 Prepare → Run → Freeze → Audit → Judge → Summarize 评测链。Bare 不适用 workflowCompleted；Candidate terminal、focused/hidden acceptance、Blind Judge 与成本必须分栏。
| Condition | Valid cells | Candidate terminal | Focused/hidden acceptance | Blind Judge | Candidate-only cost |
|---|
| Bare / no-SDD | 24/24 | 24/24 | 17/24 | 48/48；sum 3,477；mean 72.44 | 42,327,170 tokens / 721 tools / 553.842237 credits |
Bare 最有解释力的参照是 H0 Terra/high 条件：两边 Candidate 都是 gpt-5.6-terra / high，任务和正式分母也都是 D1–D8 × 3。它仍不是严格单变量实验：Bare 没有 SDD、Operator 或 Reviewer，Bare Judge 是 terra/high、H0 Judge 是 terra/xhigh，而且 Bare 成本只计 Candidate，H0 成本计 Candidate/Harness 中的 Candidate、Validator 与 Reviewer。演化主线里的 H0 正式基线仍是产生 H0 Weakness 的 Luna/xhigh bundle；这里选择 Terra/high 只是为了让空白对照的 Candidate 条件更接近。
| 指标 | Bare / no-SDD | H0 Terra/high | 描述性差异 |
|---|
| Valid cells | 24/24 | 24/24 | 相同 |
| 流程终态 | Candidate terminal 24/24 | workflow completed 14/24 | 不可直接相减：两个字段不是同一语义 |
| Focused/hidden acceptance | 17/24 | 15/24 | Bare +2 cells |
| Blind Judge mean | 72.4375 | 88.0625 | Bare -15.6250 |
| Tokens | 42,327,170 | 292,164,097 | Bare -249,836,927（-85.51%） |
| Tool calls | 721 | 4,386 | Bare -3,665（-83.56%） |
| Credits | 553.842237 | 3,776.08 | Bare -3,222.237763（-85.33%） |
这个空白对照给出的不是“Bare 胜过或输给 H0”的单一结论，而是一个清晰的取舍：Bare 的已报告成本 footprint 显著更低，全部 Candidate 都正常 terminal，focused/hidden acceptance 还多通过 2 格；但 Blind Judge 均分低 15.625。因此，终止得更快、账面成本更低，不等于交付质量更高。反过来，也不能把 H0 的全部 Judge 优势都归因于 SDD，因为角色拓扑、Judge effort、成本统计范围和流程语义同时不同。Bare 只作为 H0 的外部空白参照，不进入任何演化箭头，也不参与 H0→H1 的代际增量计算。
完整成本与相邻代际变化如下：
| 条件 | Candidate/Harness tokens | Tools | Credits |
|---|
| H0 Luna/xhigh | 597,146,805 | 6,592 | 6,903.95 |
| H0 Terra/high 模型条件 | 292,164,097 | 4,386 | 3,776.08 |
| H1 主视图 | 316,713,117 | 5,393 | 4,460.56 |
| H02 | 247,515,656 | 4,196 | 3,546.00 |
| H03 | 276,702,480 | 4,279 | 3,917.75 |
| H04 | 219,748,287 | 3,605 | 3,370.82 |
| H05 | 259,151,137 | 4,082 | 3,913.95 |
| H052 | 116,857,308 | 1,258 | 1,891.35391 |
| H0601 | 84,836,263 | 1,199 | 1,171.61 |
| Bare / no-SDD comparator | 42,327,170 | 721 | 553.842237 |
| 跳转 | Workflow 变化 | Product/focused 变化 | Judge mean 变化 | Candidate tokens 变化 |
|---|
| H0 Luna → H1 | -8 cells | -1 cell | +3.3958 | -280,433,688（-46.96%） |
| H1 → H02 | +7 cells | +1 cell | +0.9583 | -69,197,461（-21.85%） |
| H02 → H03 | +1 cell | -1 cell | +0.4167 | +29,186,824（+11.79%） |
| H03 → H04 | -6 cells | -1 cell | -5.1042 | -56,954,193（-20.58%） |
| H04 → H05 | +3 cells | +3 cells | +5.2083 | +39,402,850（+17.93%） |
| H04 → H052 | +12 cells | +2 cells | +2.9792 | -102,890,979（-46.82%） |
| H052 → H0601 | 0 cells | 不直接合并；H0601 分列 audit 13/24、external focused 18/24、pre-hidden visible 9/24 | +1.5625 | -32,021,045（-27.40%） |
H0→H1 采用产生 H0 Weakness 的 Luna/xhigh bundle。若只比较 H0 Terra/high → H1，则是 workflow 14→10、focused 15→18、Judge 88.0625→93.5208；它仍不是单变量对照。
H0：先发现“能发现、不能关闭”
H0 的关键 Weakness 是 W-03 — Unreachable cross-stage repair ownership。Validator 或 Reviewer 能指出 blocker 位于另一个 stage/artifact，但当前角色只能修改自己的报告；Controller 既不能把责任交还给真正能修改 source 的 owner，也没有稳定的 blocked terminal。于是问题可能被“写进报告”，却没有真实 source/state 变化。
从这个 Weakness 拆出了两个互斥方向：
P-01 / H1-inspired：删除默认独立 Validation。P-02 / H5-inspired：保留 checker，但让 negative verdict 成为 typed Controller signal，并提供 back、invalidation 和 owner repair。
当时选择的是 P-02 / H5-inspired，实际下一代仓库 ID 为 H1。这里的 “H5-inspired” 是策略谱系，不是另一个正式 generation。
H0 的主要收益不是某个干预分数，而是建立了后续演进的证据基线和 Root Cause：恢复失败的首个分歧不在“模型不肯修”，而在 Controller 没有可达的责任转移。
权威入口：H0 Weakness shortlist；H0 W-03 Proposal 文档。
H1 / H01：让跨阶段恢复真正可达
H1 落地了 H0 选择的 reachable-repair 方向：增加 structured blocked verdict、back、confirmation invalidation、owner repair、reconfirm 和 recheck。流程仍包含七个阶段：
proposal → delta-spec → delta-design → tasks → validation → implementation → review
它的机制收益是，跨阶段失败第一次成为 Controller 可以执行的状态变化，而不再只是自然语言建议。可惜正式结果也显示：可达不等于闭包完成。H1 workflow 为 10/24，低于 H0 的 18/24；focused 为 18/24，Judge 为 93.5208。
这不能简单判定 P-02 无效，因为 H0→H1 同时把 Candidate/Harness 从 Luna/xhigh 换成了 Terra/high，而且控制面发生了较大重构。可确认的收益是恢复能力被建立；聚合 completion 是否改善，当代证据没有支持。
H1 重新分析后确认了三个 Weakness，其中下一代选中的是 W-01：独立 Validation 能发现上游 tasks/artifact blocker，但仍只能停留在 Validation 权限边界，无法关闭问题。对应选择 H1/h1-root-cause-20260811-a/P-01。
权威入口：H1 Weakness；H1 Proposal。
H02：删除独立 Validation，减少权限断点
H02 采用 H1 W-01 → P-01：删除 standalone Validation，把必要的独立验证责任并入 Review。Review 要么基于验证证据批准，要么通过已有的 back/recovery 把 blocker 返回负责修复的工作阶段；删除的是一个 stage，不是 focused tests、验证义务或质量检查。
H02 因而变为六阶段：
proposal → delta-spec → delta-design → tasks → implementation → review
同时继续保留 H1 的 v2 structured verdict/back/recheck。
相对 H1，H02 workflow 从 10/24 上升到 17/24，focused 从 18/24 到 19/24，Judge 从 93.5208 到 94.4792；Candidate tokens 从 316,713,117 降到 247,515,656，约下降 21.85%。这是整条链上第一次同时看到 completion、质量观测和成本方向改善。
不过这仍是代际观察，而非随机、配对的单变量实验；尤其要防止原来的问题只是从 Validation 迁移到 Review。
H02 的正式 RCA 随后提取出 W-01：Harness 可能根据 aggregate/task-complete 信号过早认定 implementation ready，而逐项公开义务还没有对应实现或验证证据。用户选择了 H02/h02-root-cause-20260811-a/P-01，作为 H03 的 treatment。
权威入口：H02 Weakness；H02 Proposal。
H03：把 Implementation readiness 变成逐义务闭包
H03 保持 H02 的六阶段和 v2 recovery，只改变 readiness recognition：Candidate 必须对已确认的公开义务给出 obligation → implementation evidence → verification evidence；证据不足时 readiness 保持 pending，并在进入 Review 前暴露缺口。
相对 H02，workflow 从 17/24 升到 18/24，Judge 从 94.4792 升到 94.8958；但 focused 从 19/24 降到 18/24，tokens 从 247,515,656 增至 276,702,480。因此它的观察性收益是更高的流程完成和 Judge 分数，代价是 readiness accounting 带来额外成本，且产品验证没有同步提升。
H03 没有独立 post-H03 Weakness Card。随后形成 H04 的不是“H03 新 RCA”，而是 H02 agent-derived candidate 中的另一条旁支：W-02 — Review approval 未绑定 controller verification truth。
正式结果入口：H03 formal result。
H04：尝试消除 Review approved 与红色验证结果的矛盾
H04 采用上述 agent-derived W-02 → P-01 — Controller-Evidence-Bound Review Approval。它要求 positive Review 绑定当前、同 revision、同 product projection 且 passed=true 的 Controller focused receipt；有效 done 也间接继承这条 proof。
H04 的目标是避免一种 false terminal：Reviewer 写了 Approved，但 Controller 自己运行的 focused verification 实际失败。正式结果中该 predicate 为 0，12 个 completed cells 都有匹配的 receipt anchors。
但这不能证明 H04 treatment 产生了收益，因为 H03 的同一 predicate 也是 0。同时，workflow 从 H03 的 18/24 降到 12/24，focused 从 18/24 到 17/24，Judge 从 94.8958 降到 89.7917。H04 说明这个安全门在结构上成立，但没有显示 completion 或 Judge uplift，而且后来确认这条 gate 不应被泛化成所有后续 workflow 的通用真理。
H04 post-formal RCA 随后产生两条被分别采用的路线：
W-04 → P-04：authority-conflict recovery，进入 H05。W-01 → P-01：single terminal-contract ownership，进入 H052。
权威入口：H04 Weakness；H04 Proposal。
H05 分支：把跨阶段权威冲突退回真正的 owner
H05 选择 H04 W-04 → P-04。首个分歧是：Implementation 已指出 confirmed delta artifacts 与 downstream tasks/Operator 的权威冲突，但 H04 连续把问题退回 tasks；tasks 无权消除上游权威，最终只是重复 re-entry。
H05 把 authority-conflict 变成独立 recovery outcome：由 Controller/Operator 选择最早必须改变的权威工件；只有该工件发生变化、重新确认，或者记录明确 precedence 后，才允许 downstream re-entry。
正式 H05-P04-FAST-FORMAL-20260812-R1 已完成：workflow 15/24、focused 20/24、Judge 95。相对 H04，workflow 和 focused 各增加 3 格。更直接的机制证据是两格自然触发 authority conflict，2/2 都在目标权威工件改变并重新确认后才重入，未出现 unchanged-authority re-entry。
这些收益仍不能解释成 P-04 的普遍单因果效果：H05 使用 Fast/priority 条件，正式运行还经历了基础设施 replacement 和 framework amendment。它能支持的是“这套路由在两次自然冲突上按设计工作”，不是“所有总体指标上涨都来自 P-04”。
正式结果入口：H05 formal result。
H052 分支：统一终止合同，并把流程完成与质量测量分开
H052 选择 H04 W-01 → P-01。H04 的 D1-r2/r3 同一 Implementation context 同时暴露两套终止合同：Controller 要求 readiness markers，而 frozen task 要求 legacy IMPLEMENTATION_COMPLETE。两个 Candidate 都遵循后者，产品 focused 是绿色、Judge 分别接近满分，却在进入 Review 前被 Controller 确定性判 missing-ready-readiness。
P-01 原始杠杆是：execution 时只暴露一个 Controller-owned terminal contract，task 保留产品义务但不再定义竞争 sentinel。H052 最终又在此基础上形成更大的精简设计：
Change Spec Session → fresh Implement Session → Controller accept/archive
- Spec Agent 与 Operator 只确认一个 exact-digest Change Spec。
- fresh Implement 只接收 confirmed Change Spec 和当前 repository。
- Implement 只有唯一
MATSPEC_STAGE_READY 终止合同。 - focused verification 与 Audit findings 仍完整记录，但属于实验测量，不再拥有 workflow 终止权。
- 只有模型、网络、runtime/input、Controller、状态或 evidence 损坏等基础设施失败可以阻断。
直接目标 D1 从 H04 workflow 1/3 变为 H052 3/3，focused 保持 3/3，Judge 从 98.8333 到 100；三格都只输出唯一的新 sentinel，旧 mismatch 没有复现。
H052 完整结果为 workflow 24/24、product verification 19/24、Audit finding runs 3/24、Judge 92.7708333，Candidate tokens 116,857,308。相对 H04，workflow 增加 12 格，product 增加 2 格，tokens 下降约 46.82%，tools 下降约 65.10%。Product-red cells 和有 Audit finding 的 cells 仍保持 workflow completed，说明 completion 与质量/compliance 已按设计分栏。
不能把上述总体收益全部归给 P-01：H052 同时改变了阶段数量、权威工件结构、session isolation、terminal contract 和非阻断质量语义。最强的直接机制支持仍是 D1 的竞争终止合同消失。
权威入口：H052 exact selection 与 Judge result。
H05 vs H052：Judge 分差集中在三个 outlier，不是普遍退化
完整 /24 主表中，H05 Judge 总分为 4,560/4,800，均值 95.0000；H052 为 4,453/4,800，均值 92.7708。H052 少 107 分，均值低 2.2292。D8 在两边都计入主统计：H05 为 459/600，H052 为 462/600，H052 反而多 3 分。因此完整差值来自 D1–D7 的 -110，再被 D8 的 +3 略微抵消；D1–D7 只用于解释完整 /24 差值，不是另一个发布口径。
| Task | H052 相对 H05 的 Judge 总分变化 |
|---|
| D1 CLI | +11 |
| D2 ESLint | 0 |
| D3 pytest-plugin | +16 |
| D4 pytest-addini | -23 |
| D5 Bat | -29 |
| D6 SQLModel | -50 |
| D7 Axum | -35 |
| D8 Prometheus | +3 |
| 完整 24 cells | -107 |
D1–D7 中，H05 为 4,101/4,200，H052 为 3,991/4,200。其中三个 matching outlier cells 合计造成 H052 -116 分：
| Outlier | H05 → H052 | First Divergence / 归因 |
|---|
| D6 SQLModel r3 | 100/100 → 73/82（-45） | confirmed Spec 已要求 ordinary/generated fields 保持；Implement 却把 PydanticUndefined 传入 ForeignKey，造成普通 generated column 回归。属于明确的 Implement 产品缺陷。 |
| D4 pytest-addini r1 | 100/100 → 81/83（-36） | 新测试生成重复 Union parametrization IDs，导致 collection 失败，同时 public typing/docs 不完整。属于明确的 Implement 验证与产品缺陷。 |
| D7 Axum r3 | 100/100 → 84/81（-35） | Change Spec 只写 generic submission method，没有闭合公共 API method name；Implement 选择 spawn，而 consumer 使用 execute 后编译失败。这里既有 Spec closure 缺陷，也有未公开 method name 约束，不能把全部 35 分都解释成纯产品缺陷。 |
去掉这三个 outlier 后，其余 18 cells 的 H05 为 3,501/3,600 = 97.25，H052 为 3,507/3,600 = 97.4167；H052 反而多 6 分、均值高 0.1667。所以观察到的 Judge 下滑不是普遍退化，而是高度集中在少数复杂 trajectory。
这三个 outlier 也正好是 H052 D1–D7 中仅有的三个 productVerification=failed cells。它们的 workflow 仍然 completed，且 workflowBlocking=false，说明“workflow completion、product verification、Audit findings、Judge 分栏”按设计生效，并非 Controller 漏记。另一个需要保留的 warning 是 D5 Bat r1：focused 为 green，但 Judge 只有 85/86；First Divergence 是 Change Spec 对 show-all/cat preserved behavior 出现语义漂移并遗漏 changelog 义务，Implement 又漏掉 first-line BOM seam，而 focused hook 没覆盖完整义务。这证明 green focused receipt 不等于所有 confirmed obligations 都已满足。
H052 的收益主要是提高 workflow completion、降低成本，并把 product red 留作测量后继续归档；因此 24/24 completion 从不意味着所有实现都经过修复。当前低分集中体现的是一次性 Change Spec 闭包失误，以及 fresh Implement 的深层兼容/typing 回归，后面没有独立 Review/backtrack 再修一轮。若继续改善质量，杠杆应落在 Spec semantic closure 与 Implement 自验证/repair，而不是恢复 Controller 对 product red 的流程阻断权。
这仍是描述性 RCA：可以说“这些 selected outputs 中 H052 的 Judge 均值更低，差异集中在上述 outliers”；不能据此断言 P-04 优于 P-01，也不能断言多阶段必然优于两阶段。H05 与 H052 的模型 effort、priority、workflow、dense baseline、backtrack、验证 manifest 和 replacement 路径并非同一控制条件。
证据入口：H05 formal result；H052 selected results；H052 outliers：D6 r3、D4 r1、D7 r3、D5 r1。
H0601：把 confirmed Spec 升级为语义闭包，并把证据绑定到每个 REQ
H0601 的精确谱系是 H04 W-01/P-01 → H052 a601aa8 → H052 retrospective W-01/P-01 + W-02/P-02 → H0601。两组 retrospective Cards 是对用户此前已选择、实施并完成评测的历史决策做固化，不是新的 pending Proposal；Weakness Cards 与 Proposal Cards 已进入主归档。H0601 没有新建 canonical H06 Weakness Card，也不把 H060101–H060103 结构检查码冒充 Weakness ID。
False semantic closure
H052 已经具备 Change Spec → exact-digest confirmation → fresh Implement → Controller terminalization，但章节、REQ 和确认存在仍可能掩盖公开 API identity、preserved behavior、precedence/default/fallback、docs/changelog 或真实 open decision 的缺失；max-turn EXHAUSTED 也可能被误当成 confirmed handoff。
H0601 保持两阶段架构，不增加 Proposal、Design、Tasks、Validation、Review 或第二产品合同。每个 REQ 必须写清 public surface 与公开名称/签名，或者给出真实的 not-product-contract 理由；Operator 只对 exact digest 做语义确认，未知就 CONTINUE。只有 CONFIRM + 结构有效 + 无开放决定 才 handoff，EXHAUSTED 保持 unconfirmed、workflow-blocking。Spec Agent 只在自己认为 draft ready 时运行 SDD-owned Candidate-visible 结构自检；Controller 不参与该 repair loop，也不发明产品答案。
Obligation-to-visible-evidence disconnect
H052 的 visible verification 来自 task-level focused tests 或自由 shell commands，没有绑定 confirmed Spec 的具体 REQ。于是 pytest green 可能没有覆盖 static typing obligation，命令链或 || true 也可能吞掉前序失败。
H0601 让每个 REQ 声明 category + argv + env + cwd + timeoutSeconds。Controller 以 shell=false 独立执行每条声明，记录真实 start/exit/timeout，以及分离的 stdout/stderr path、bytes 和 hash，并把 receipt 绑定到 exact Spec digest 与 current product projection。Evidence 必须完整且 current 才能 terminal；命令 red 如实进入 productVerification=failed，但不把诚实完成的 workflow 伪装成失败。
一句话概括：H0601 把“存在 confirmed Spec”升级为“exact-digest Spec 已语义闭包”，把“运行 task tests”升级为“每个 REQ 自带、独立执行且 current-bound 的 Candidate-visible evidence”。
Effective evaluation 与 Judge replacement
有效结果是 workflow 24/24 completed、48 个有效 Judge 总分 4,528/4,800、均值 94.3333。任务均值分别为 D1 100.00、D2 98.33、D3 98.67、D4 87.33、D5 88.50、D6 93.00、D7 98.50、D8 fixed-v1 90.33。
三个诊断维度必须分栏：treatment audit passed 13/24、external focused tests passed 18/24、pre-hidden Candidate-visible verification passed 9/24。这些红项包含 adoption、receipt currentness、工具缺失和封闭 runtime 等不同原因，不能合并成单一 product quality，也不能覆盖 Judge 结论。
D1 R3 原 Judge-01 的 0 被确认无效：它只读取 product.diff 1–360 行，随后在 baseline 搜索，而它声称缺失的方法实际位于 diff 第 452 和 513 行。用户授权对同一冻结 package 做 source-slot replacement；replacement 为 100，D1 R3 的有效双分变为 [100,100]。旧无效 bundle append-only 归档，promotion.json 绑定旧、新 hash 与相同 packageHash；只重新运行零模型 Summarize，没有重跑 Candidate、Operator、Controller、hidden evaluator 或 campaign。
权威入口：H0601 effective summary；Judge promotion。
Bare / no-SDD comparator：直接实现的独立参照
Bare 固定使用 gpt-5.6-terra / high Candidate 与两个 gpt-5.6-terra / high Blind Judges，覆盖 D1–D8 各 3 次。24 格全部形成有效冻结交付并由 Candidate 正常 terminal；其中 focused/hidden acceptance 为 17/24，Judge 总分 3,477/4,800、均值 72.4375（展示为 72.44）。单 cell pilot 未进入正式分母（pilotIncludedCells=0）。
| Task | Focused/hidden acceptance | Judge mean |
|---|
| D1 CLI | 3/3 | 79.17 |
| D2 ESLint | 3/3 | 47.67 |
| D3 pytest-plugin | 3/3 | 99.50 |
| D4 pytest-addini | 3/3 | 65.50 |
| D5 Bat | 3/3 | 92.50 |
| D6 SQLModel | 2/3 | 92.67 |
| D7 Axum | 0/3 | 67.50 |
| D8 Prometheus | 0/3 | 35.00 |
Wave 1 中 D3 的三个 Judge-01 slot 遇到 chatgpt.com connection refused；Candidate packages 已经冻结，因此只做 Judge-only recovery，candidateRerun=false。原失败证据 append-only 保留，最终补齐 D3 6/6 Judge outputs。该事件属于 Judge infrastructure，不归因于 Candidate，也不改变 Bare 的 24-cell Candidate 分母。
权威入口：Bare generation result；D3 invalid Judge archive（未打包）。正式证据 commit 为 50d67753fe185df084453614410132f69eb28006；其结果现已复制进 main 归档，原 evidence commit 本身仍保持独立历史。
收益应该怎样理解
- 机制收益优先于均分。 某代可以修复明确状态机缺陷，却因为模型随机性、任务分布或更严格 admission 而没有聚合 uplift。
- Proposal 是可证伪假设，不是已证明因果。 本文中的“收益”首先表示下一代观测方向，以及 targeted mechanism 是否按预测工作。
- H05 与 H052 不能直接排成前后代。 它们分别解决 H04 的不同 Weakness，并且执行条件、工作流和成本语义不同。
- D8 始终进入统计。 所有代际表都保持完整
/24；任务级拆分只用于解释完整差值，不构成另一个主视图。详细记录见 模型运行与评测对账表。 - H0 Terra/high 是模型条件，不是另一个 workflow generation。 它用于比较被测模型，不改变上述
H0 → H1 → H02 → H03 → H04 控制面谱系。 - H0601 没有新的 Weakness Card namespace。 它只处理 H052 已观察到的两个问题，不能事后创造
H06/W-xx 或把结构检查码当成 Weakness。 - Bare 只提供外部参照。 它不属于 H treatment lineage；Candidate terminal、focused/hidden acceptance、Judge 与成本互相正交，不能用其中一列替代另一列。
边界与验证
- 本文是代际决策索引，不替代各代 descriptor、冻结 task summaries、Judge packages/results、Weakness Cards 或 Proposal Cards。
- 这里引用的每代结果均使用完整
/24；本文没有发布 D1–D7-only 主表。 - H1 主视图按用户授权使用 supplemental D5 replacement，原始 H1 D5 权重为 0，只保留历史证据。
- H05 与 H052 的匿名 Judge packages、results、task reports 和 aggregate 已复制到 主归档（未打包）；原 campaign 仍保留其独立执行身份。
- H0601 的 task reports、Judge recovery 和有效汇总已从 cleanup snapshot 恢复到主归档；完整匿名 packages/results 与 raw sessions 未被 snapshot 捕获，归档明确标记这一缺口。
- Bare aggregate、八份 task summary 和 D3 invalid Judge archive 已进入独立 evidence commit
50d6775；Judge recovery receipts 位于该 worktree 的 gitignored .scratch，本地存在但不属于该 commit。Bare 不定义 workflowCompleted。 - 除 H04 post-formal RCA 已明确拆出的 H05/H052 路线外，不应仅凭 Proposal 编号相同就跨 namespace 串联；稳定引用必须包含 generation 与 analysisRunId。
保留原始 Markdown 内容（展开查看权威文本）
# MatrixSpec 代际演进简史
## 直接答案
> 迁入说明（2026-10-11）：本文来自 Workflow Arena 的研究档案。下文“主归档”和“main”指原来源仓；本目录仅发布可复核的汇总与选卡证据，未打包的原始材料以文字来源定位信息保留。链接与本机路径已为离线阅读整理；原始文件 hash 和发布文件 hash 分开记录，见本目录的来源核验清单。
这条演进线不是单纯追逐更高分，而是每一代从上一代轨迹中找出一个可证伪的 Weakness，再选择一个主要 Proposal 做下一代干预：
```mermaid
flowchart LR
H0["H0<br/>恢复责任不可达"] --> H1["H1 / H01<br/>加入可达 back / repair"]
H1 --> H02["H02<br/>删除独立 Validation"]
H02 --> H03["H03<br/>逐义务 Implementation readiness"]
H03 --> H04["H04<br/>Review 绑定 Controller evidence"]
H04 --> H05["H05<br/>修复跨阶段权威冲突路由"]
H04 --> H052["H052<br/>统一终止合同并压缩为 Spec → Implement"]
H052 --> H0601["H0601<br/>语义闭包 + REQ 级可见证据"]
Bare["Bare / no-SDD comparator baseline<br/>独立于 H generation"]
```
这里的仓库正式 generation ID 是 `H1`；历史讨论中也把它称为 `H01`。H04 之后不是 `H04 → H05 → H052` 的串行关系，而是从同一个 H04 证据分裂出的两条独立路线：
- **H05**：选择 H04 post-formal `W-04 → P-04`，解决跨阶段权威冲突被退回错误 owner 的问题。
- **H052**：选择 H04 post-formal `W-01 → P-01`，解决同一 Implement context 同时暴露两个终止合同的问题；后续又明确采用更精简的 `Change Spec → fresh Implement` 工作流，并把产品验证与 Audit 作为非阻断测量。
- **H0601**：直接继承 H052 `a601aa8`，处理 H052 retrospective `W-01/P-01`（semantic closure）与 `W-02/P-02`（REQ-bound visible evidence）。仓库没有 canonical `H06/W-xx` Weakness Card；`H060101`–`H060103` 是结构检查码，不是 Weakness ID。
演化简史统一使用每一代完整 `/24` 统计，D8 始终计入分母。本文只发布完整 24-cell 口径。
## 一眼看懂每一代
| 代际 | 进化入口 | 主要改动 | 完整 `/24` 描述性结果 | 结论 |
| --- | --- | --- | --- | --- |
| H0 | 基线，无上游 Card；运行后暴露 W-03 | 提供基线与 Root Cause，不是 treatment | workflow `18/24`；focused `19/24`；Judge `90.1250` | 找到了控制面问题；尚未解决 |
| H1 / H01 | [H0 W-03 → P-02](matrixspec-evolution-entries.md#h1--h01) | structured blocked verdict、back、invalidation、repair、reconfirm/recheck | workflow `10/24`；focused `18/24`；Judge `93.5208` | 建立了可达恢复能力，但聚合 completion 没有提升；同时换了 Candidate 模型，不能单因果归因 |
| H02 | [H1 W-01 → P-01](matrixspec-evolution-entries.md#h02) | 删除 standalone Validation，把必要验证责任并入 Review；保留 v2 recovery | workflow `17/24`；focused `19/24`；Judge `94.4792` | 相对 H1：workflow `+7`、focused `+1`，tokens `-21.85%`；方向改善但不是随机因果证明 |
| H03 | [H02 W-01 → P-01](matrixspec-evolution-entries.md#h03) | readiness 改为逐项 `义务 → 实现证据 → 验证证据` | workflow `18/24`；focused `18/24`；Judge `94.8958` | 相对 H02：workflow `+1`、Judge `+0.4167`；focused `-1`、tokens `+11.79%`，说明闭包更强但有成本 |
| H04 | [H02 agent-derived W-02 → P-01](matrixspec-evolution-entries.md#h04) | positive Review 必须绑定 current/passed focused receipt | workflow `12/24`；focused `17/24`；Judge `89.7917` | false-terminal predicate 为 0，但 H03 也是 0；completion/Judge 下滑，不能称为收益已证实 |
| H05 | [H04 W-04 → P-04](matrixspec-evolution-entries.md#h05) | authority conflict 成为独立 recovery outcome，路由到最早必须变化的权威 owner | workflow `15/24`；focused `20/24`；Judge `95.0000` | 相对 H04：workflow/focused 各 `+3`；两格自然冲突 2/2 正确路由并重确认。Fast/priority 与运行 amendment 使总体提升只能描述性解释 |
| H052 | [H04 W-01 → P-01](matrixspec-evolution-entries.md#h052) | 单一终止合同；进一步形成 exact Change Spec → fresh Implement；质量与 Audit 非阻断 | workflow `24/24`；product `19/24`；Audit finding runs `3/24`；Judge `92.7708` | 相对 H04：workflow `+12`、product `+2`、Judge `+2.9792`、tokens `-46.82%` |
| H0601 | [H052 W-01/P-01 + W-02/P-02](matrixspec-evolution-entries.md#h0601) | 保持两阶段架构；Operator exact-digest 语义确认；EXHAUSTED 不确认；每个 REQ 声明并独立执行 Candidate-visible verification | workflow `24/24`；treatment audit `13/24`；external focused `18/24`；pre-hidden visible verification `9/24`；Judge `4528/4800 = 94.3333` | 三类红项包含 adoption、currentness、tool/runtime 等不同失败，不能合并成 product quality；Judge uplift 只作描述性记录 |
### 独立对照：Bare / no-SDD comparator baseline
Bare 是独立的 direct-Candidate condition comparator，不是 H lineage 的新一代，也不是 MatrixSpec treatment。它不使用 SDD、Operator 或 Reviewer，`capabilities={}`，但保留普通 multi-agent 与同一套 `Prepare → Run → Freeze → Audit → Judge → Summarize` 评测链。Bare 不适用 `workflowCompleted`；Candidate terminal、focused/hidden acceptance、Blind Judge 与成本必须分栏。
| Condition | Valid cells | Candidate terminal | Focused/hidden acceptance | Blind Judge | Candidate-only cost |
| --- | ---: | ---: | ---: | ---: | ---: |
| Bare / no-SDD | 24/24 | 24/24 | 17/24 | 48/48；sum `3,477`；mean `72.44` | `42,327,170` tokens / `721` tools / `553.842237` credits |
Bare 最有解释力的参照是 **H0 Terra/high 条件**：两边 Candidate 都是 `gpt-5.6-terra / high`，任务和正式分母也都是 D1–D8 × 3。它仍不是严格单变量实验：Bare 没有 SDD、Operator 或 Reviewer，Bare Judge 是 `terra/high`、H0 Judge 是 `terra/xhigh`，而且 Bare 成本只计 Candidate，H0 成本计 Candidate/Harness 中的 Candidate、Validator 与 Reviewer。演化主线里的 H0 正式基线仍是产生 H0 Weakness 的 Luna/xhigh bundle；这里选择 Terra/high 只是为了让空白对照的 Candidate 条件更接近。
| 指标 | Bare / no-SDD | H0 Terra/high | 描述性差异 |
| --- | ---: | ---: | ---: |
| Valid cells | 24/24 | 24/24 | 相同 |
| 流程终态 | Candidate terminal `24/24` | workflow completed `14/24` | **不可直接相减**：两个字段不是同一语义 |
| Focused/hidden acceptance | 17/24 | 15/24 | Bare `+2` cells |
| Blind Judge mean | 72.4375 | 88.0625 | Bare `-15.6250` |
| Tokens | 42,327,170 | 292,164,097 | Bare `-249,836,927`（`-85.51%`） |
| Tool calls | 721 | 4,386 | Bare `-3,665`（`-83.56%`） |
| Credits | 553.842237 | 3,776.08 | Bare `-3,222.237763`（`-85.33%`） |
这个空白对照给出的不是“Bare 胜过或输给 H0”的单一结论，而是一个清晰的取舍：Bare 的**已报告成本 footprint** 显著更低，全部 Candidate 都正常 terminal，focused/hidden acceptance 还多通过 2 格；但 Blind Judge 均分低 `15.625`。因此，**终止得更快、账面成本更低，不等于交付质量更高**。反过来，也不能把 H0 的全部 Judge 优势都归因于 SDD，因为角色拓扑、Judge effort、成本统计范围和流程语义同时不同。Bare 只作为 H0 的外部空白参照，不进入任何演化箭头，也不参与 H0→H1 的代际增量计算。
完整成本与相邻代际变化如下：
| 条件 | Candidate/Harness tokens | Tools | Credits |
| --- | ---: | ---: | ---: |
| H0 Luna/xhigh | 597,146,805 | 6,592 | 6,903.95 |
| H0 Terra/high 模型条件 | 292,164,097 | 4,386 | 3,776.08 |
| H1 主视图 | 316,713,117 | 5,393 | 4,460.56 |
| H02 | 247,515,656 | 4,196 | 3,546.00 |
| H03 | 276,702,480 | 4,279 | 3,917.75 |
| H04 | 219,748,287 | 3,605 | 3,370.82 |
| H05 | 259,151,137 | 4,082 | 3,913.95 |
| H052 | 116,857,308 | 1,258 | 1,891.35391 |
| H0601 | 84,836,263 | 1,199 | 1,171.61 |
| Bare / no-SDD comparator | 42,327,170 | 721 | 553.842237 |
| 跳转 | Workflow 变化 | Product/focused 变化 | Judge mean 变化 | Candidate tokens 变化 |
| --- | ---: | ---: | ---: | ---: |
| H0 Luna → H1 | -8 cells | -1 cell | +3.3958 | -280,433,688（-46.96%） |
| H1 → H02 | +7 cells | +1 cell | +0.9583 | -69,197,461（-21.85%） |
| H02 → H03 | +1 cell | -1 cell | +0.4167 | +29,186,824（+11.79%） |
| H03 → H04 | -6 cells | -1 cell | -5.1042 | -56,954,193（-20.58%） |
| H04 → H05 | +3 cells | +3 cells | +5.2083 | +39,402,850（+17.93%） |
| H04 → H052 | +12 cells | +2 cells | +2.9792 | -102,890,979（-46.82%） |
| H052 → H0601 | 0 cells | 不直接合并；H0601 分列 audit `13/24`、external focused `18/24`、pre-hidden visible `9/24` | +1.5625 | -32,021,045（-27.40%） |
H0→H1 采用产生 H0 Weakness 的 Luna/xhigh bundle。若只比较 H0 Terra/high → H1，则是 workflow `14→10`、focused `15→18`、Judge `88.0625→93.5208`；它仍不是单变量对照。
## H0：先发现“能发现、不能关闭”
H0 的关键 Weakness 是 `W-03 — Unreachable cross-stage repair ownership`。Validator 或 Reviewer 能指出 blocker 位于另一个 stage/artifact，但当前角色只能修改自己的报告；Controller 既不能把责任交还给真正能修改 source 的 owner，也没有稳定的 blocked terminal。于是问题可能被“写进报告”，却没有真实 source/state 变化。
从这个 Weakness 拆出了两个互斥方向：
- `P-01 / H1-inspired`：删除默认独立 Validation。
- `P-02 / H5-inspired`：保留 checker，但让 negative verdict 成为 typed Controller signal，并提供 back、invalidation 和 owner repair。
当时选择的是 `P-02 / H5-inspired`，实际下一代仓库 ID 为 **H1**。这里的 “H5-inspired” 是策略谱系，不是另一个正式 generation。
H0 的主要收益不是某个干预分数，而是建立了后续演进的证据基线和 Root Cause：恢复失败的首个分歧不在“模型不肯修”，而在 Controller 没有可达的责任转移。
权威入口：[H0 Weakness shortlist](../archive/matrixspec-evolution/analyses/H0/h0-root-cause-20260809-a/weakness-shortlist.json)；[H0 W-03 Proposal 文档](matrixspec-proposal-card-w03-h5.md)。
## H1 / H01：让跨阶段恢复真正可达
H1 落地了 H0 选择的 reachable-repair 方向：增加 structured blocked verdict、`back`、confirmation invalidation、owner repair、reconfirm 和 recheck。流程仍包含七个阶段：
`proposal → delta-spec → delta-design → tasks → validation → implementation → review`
它的机制收益是，跨阶段失败第一次成为 Controller 可以执行的状态变化，而不再只是自然语言建议。可惜正式结果也显示：**可达不等于闭包完成**。H1 workflow 为 `10/24`，低于 H0 的 `18/24`；focused 为 `18/24`，Judge 为 `93.5208`。
这不能简单判定 P-02 无效，因为 H0→H1 同时把 Candidate/Harness 从 Luna/xhigh 换成了 Terra/high，而且控制面发生了较大重构。可确认的收益是恢复能力被建立；聚合 completion 是否改善，当代证据没有支持。
H1 重新分析后确认了三个 Weakness，其中下一代选中的是 `W-01`：独立 Validation 能发现上游 tasks/artifact blocker，但仍只能停留在 Validation 权限边界，无法关闭问题。对应选择 `H1/h1-root-cause-20260811-a/P-01`。
权威入口：[H1 Weakness](../archive/matrixspec-evolution/analyses/H1/h1-root-cause-20260811-a/weakness-shortlist.yaml)；[H1 Proposal](../archive/matrixspec-evolution/analyses/H1/h1-root-cause-20260811-a/proposals.yaml)。
## H02：删除独立 Validation，减少权限断点
H02 采用 H1 `W-01 → P-01`：删除 standalone Validation，把必要的独立验证责任并入 Review。Review 要么基于验证证据批准，要么通过已有的 back/recovery 把 blocker 返回负责修复的工作阶段；删除的是一个 stage，不是 focused tests、验证义务或质量检查。
H02 因而变为六阶段：
`proposal → delta-spec → delta-design → tasks → implementation → review`
同时继续保留 H1 的 v2 structured verdict/back/recheck。
相对 H1，H02 workflow 从 `10/24` 上升到 `17/24`，focused 从 `18/24` 到 `19/24`，Judge 从 `93.5208` 到 `94.4792`；Candidate tokens 从 `316,713,117` 降到 `247,515,656`，约下降 `21.85%`。这是整条链上第一次同时看到 completion、质量观测和成本方向改善。
不过这仍是代际观察，而非随机、配对的单变量实验；尤其要防止原来的问题只是从 Validation 迁移到 Review。
H02 的正式 RCA 随后提取出 `W-01`：Harness 可能根据 aggregate/task-complete 信号过早认定 implementation ready，而逐项公开义务还没有对应实现或验证证据。用户选择了 `H02/h02-root-cause-20260811-a/P-01`，作为 H03 的 treatment。
权威入口：[H02 Weakness](../archive/matrixspec-evolution/analyses/H02/h02-root-cause-20260811-a/weakness-shortlist.yaml)；[H02 Proposal](../archive/matrixspec-evolution/analyses/H02/h02-root-cause-20260811-a/proposals.yaml)。
## H03：把 Implementation readiness 变成逐义务闭包
H03 保持 H02 的六阶段和 v2 recovery，只改变 readiness recognition：Candidate 必须对已确认的公开义务给出 `obligation → implementation evidence → verification evidence`；证据不足时 readiness 保持 pending，并在进入 Review 前暴露缺口。
相对 H02，workflow 从 `17/24` 升到 `18/24`，Judge 从 `94.4792` 升到 `94.8958`；但 focused 从 `19/24` 降到 `18/24`，tokens 从 `247,515,656` 增至 `276,702,480`。因此它的观察性收益是更高的流程完成和 Judge 分数，代价是 readiness accounting 带来额外成本，且产品验证没有同步提升。
H03 没有独立 post-H03 Weakness Card。随后形成 H04 的不是“H03 新 RCA”，而是 H02 agent-derived candidate 中的另一条旁支：`W-02 — Review approval 未绑定 controller verification truth`。
正式结果入口：[H03 formal result](../archive/matrixspec-evolution/evaluations/h03/generation-result.json)。
## H04：尝试消除 Review approved 与红色验证结果的矛盾
H04 采用上述 agent-derived `W-02 → P-01 — Controller-Evidence-Bound Review Approval`。它要求 positive Review 绑定当前、同 revision、同 product projection 且 `passed=true` 的 Controller focused receipt；有效 `done` 也间接继承这条 proof。
H04 的目标是避免一种 false terminal：Reviewer 写了 Approved，但 Controller 自己运行的 focused verification 实际失败。正式结果中该 predicate 为 `0`，12 个 completed cells 都有匹配的 receipt anchors。
但这不能证明 H04 treatment 产生了收益，因为 H03 的同一 predicate 也是 `0`。同时，workflow 从 H03 的 `18/24` 降到 `12/24`，focused 从 `18/24` 到 `17/24`，Judge 从 `94.8958` 降到 `89.7917`。H04 说明这个安全门在结构上成立，但没有显示 completion 或 Judge uplift，而且后来确认这条 gate 不应被泛化成所有后续 workflow 的通用真理。
H04 post-formal RCA 随后产生两条被分别采用的路线：
- `W-04 → P-04`：authority-conflict recovery，进入 H05。
- `W-01 → P-01`：single terminal-contract ownership，进入 H052。
权威入口：[H04 Weakness](../archive/matrixspec-evolution/analyses/H04/h04-postformal-20260812-019ff55f-a/weakness-shortlist.yaml)；[H04 Proposal](../archive/matrixspec-evolution/analyses/H04/h04-postformal-20260812-019ff55f-a/proposals.yaml)。
## H05 分支：把跨阶段权威冲突退回真正的 owner
H05 选择 H04 `W-04 → P-04`。首个分歧是：Implementation 已指出 confirmed delta artifacts 与 downstream tasks/Operator 的权威冲突，但 H04 连续把问题退回 tasks；tasks 无权消除上游权威，最终只是重复 re-entry。
H05 把 `authority-conflict` 变成独立 recovery outcome：由 Controller/Operator 选择最早必须改变的权威工件；只有该工件发生变化、重新确认，或者记录明确 precedence 后，才允许 downstream re-entry。
正式 `H05-P04-FAST-FORMAL-20260812-R1` 已完成：workflow `15/24`、focused `20/24`、Judge `95`。相对 H04，workflow 和 focused 各增加 3 格。更直接的机制证据是两格自然触发 authority conflict，2/2 都在目标权威工件改变并重新确认后才重入，未出现 unchanged-authority re-entry。
这些收益仍不能解释成 P-04 的普遍单因果效果：H05 使用 Fast/priority 条件，正式运行还经历了基础设施 replacement 和 framework amendment。它能支持的是“这套路由在两次自然冲突上按设计工作”，不是“所有总体指标上涨都来自 P-04”。
正式结果入口：[H05 formal result](../archive/matrixspec-evolution/evaluations/h05/generation-result.json)。
## H052 分支：统一终止合同，并把流程完成与质量测量分开
H052 选择 H04 `W-01 → P-01`。H04 的 D1-r2/r3 同一 Implementation context 同时暴露两套终止合同：Controller 要求 readiness markers，而 frozen task 要求 legacy `IMPLEMENTATION_COMPLETE`。两个 Candidate 都遵循后者，产品 focused 是绿色、Judge 分别接近满分，却在进入 Review 前被 Controller 确定性判 `missing-ready-readiness`。
P-01 原始杠杆是：execution 时只暴露一个 Controller-owned terminal contract，task 保留产品义务但不再定义竞争 sentinel。H052 最终又在此基础上形成更大的精简设计：
`Change Spec Session → fresh Implement Session → Controller accept/archive`
- Spec Agent 与 Operator 只确认一个 exact-digest Change Spec。
- fresh Implement 只接收 confirmed Change Spec 和当前 repository。
- Implement 只有唯一 `MATSPEC_STAGE_READY` 终止合同。
- focused verification 与 Audit findings 仍完整记录，但属于实验测量，不再拥有 workflow 终止权。
- 只有模型、网络、runtime/input、Controller、状态或 evidence 损坏等基础设施失败可以阻断。
直接目标 D1 从 H04 workflow `1/3` 变为 H052 `3/3`，focused 保持 `3/3`，Judge 从 `98.8333` 到 `100`；三格都只输出唯一的新 sentinel，旧 mismatch 没有复现。
H052 完整结果为 workflow `24/24`、product verification `19/24`、Audit finding runs `3/24`、Judge `92.7708333`，Candidate tokens `116,857,308`。相对 H04，workflow 增加 12 格，product 增加 2 格，tokens 下降约 `46.82%`，tools 下降约 `65.10%`。Product-red cells 和有 Audit finding 的 cells 仍保持 workflow completed，说明 completion 与质量/compliance 已按设计分栏。
不能把上述总体收益全部归给 P-01：H052 同时改变了阶段数量、权威工件结构、session isolation、terminal contract 和非阻断质量语义。最强的直接机制支持仍是 D1 的竞争终止合同消失。
权威入口：[H052 exact selection 与 Judge result](../archive/matrixspec-evolution/evaluations/h052/verified-results.json)。
## H05 vs H052：Judge 分差集中在三个 outlier，不是普遍退化
完整 `/24` 主表中，H05 Judge 总分为 `4,560/4,800`，均值 `95.0000`；H052 为 `4,453/4,800`，均值 `92.7708`。H052 少 `107` 分，均值低 `2.2292`。D8 在两边都计入主统计：H05 为 `459/600`，H052 为 `462/600`，H052 反而多 `3` 分。因此完整差值来自 D1–D7 的 `-110`，再被 D8 的 `+3` 略微抵消；D1–D7 只用于解释完整 `/24` 差值，不是另一个发布口径。
| Task | H052 相对 H05 的 Judge 总分变化 |
| --- | ---: |
| D1 CLI | +11 |
| D2 ESLint | 0 |
| D3 pytest-plugin | +16 |
| D4 pytest-addini | -23 |
| D5 Bat | -29 |
| D6 SQLModel | -50 |
| D7 Axum | -35 |
| D8 Prometheus | +3 |
| **完整 24 cells** | **-107** |
D1–D7 中，H05 为 `4,101/4,200`，H052 为 `3,991/4,200`。其中三个 matching outlier cells 合计造成 H052 `-116` 分：
| Outlier | H05 → H052 | First Divergence / 归因 |
| --- | ---: | --- |
| D6 SQLModel r3 | `100/100 → 73/82`（-45） | confirmed Spec 已要求 ordinary/generated fields 保持；Implement 却把 `PydanticUndefined` 传入 `ForeignKey`，造成普通 generated column 回归。属于明确的 Implement 产品缺陷。 |
| D4 pytest-addini r1 | `100/100 → 81/83`（-36） | 新测试生成重复 Union parametrization IDs，导致 collection 失败，同时 public typing/docs 不完整。属于明确的 Implement 验证与产品缺陷。 |
| D7 Axum r3 | `100/100 → 84/81`（-35） | Change Spec 只写 generic submission method，没有闭合公共 API method name；Implement 选择 `spawn`，而 consumer 使用 `execute` 后编译失败。这里既有 Spec closure 缺陷，也有未公开 method name 约束，不能把全部 35 分都解释成纯产品缺陷。 |
去掉这三个 outlier 后，其余 18 cells 的 H05 为 `3,501/3,600 = 97.25`，H052 为 `3,507/3,600 = 97.4167`；H052 反而多 `6` 分、均值高 `0.1667`。所以观察到的 Judge 下滑不是普遍退化，而是高度集中在少数复杂 trajectory。
这三个 outlier 也正好是 H052 D1–D7 中仅有的三个 `productVerification=failed` cells。它们的 workflow 仍然 completed，且 `workflowBlocking=false`，说明“workflow completion、product verification、Audit findings、Judge 分栏”按设计生效，并非 Controller 漏记。另一个需要保留的 warning 是 D5 Bat r1：focused 为 green，但 Judge 只有 `85/86`；First Divergence 是 Change Spec 对 show-all/cat preserved behavior 出现语义漂移并遗漏 changelog 义务，Implement 又漏掉 first-line BOM seam，而 focused hook 没覆盖完整义务。这证明 green focused receipt 不等于所有 confirmed obligations 都已满足。
H052 的收益主要是提高 workflow completion、降低成本，并把 product red 留作测量后继续归档；因此 `24/24` completion 从不意味着所有实现都经过修复。当前低分集中体现的是一次性 Change Spec 闭包失误，以及 fresh Implement 的深层兼容/typing 回归，后面没有独立 Review/backtrack 再修一轮。若继续改善质量，杠杆应落在 Spec semantic closure 与 Implement 自验证/repair，而不是恢复 Controller 对 product red 的流程阻断权。
这仍是描述性 RCA：可以说“这些 selected outputs 中 H052 的 Judge 均值更低，差异集中在上述 outliers”；不能据此断言 `P-04` 优于 `P-01`，也不能断言多阶段必然优于两阶段。H05 与 H052 的模型 effort、priority、workflow、dense baseline、backtrack、验证 manifest 和 replacement 路径并非同一控制条件。
证据入口：[H05 formal result](../archive/matrixspec-evolution/evaluations/h05/generation-result.json)；[H052 selected results](../archive/matrixspec-evolution/evaluations/h052/verified-results.json)；H052 outliers：D6 r3（未打包来源：`WorkArena:campaigns/sqlmodel-field-constraints-matrixspec-lean-v1/runs/sln-r3/`）、D4 r1（未打包来源：`WorkArena:campaigns/pytest-addini-type-expressions-matrixspec-lean-v1/runs/paln-r1/`）、D7 r3（未打包来源：`WorkArena:campaigns/axum-custom-executor-matrixspec-lean-v1/runs/aln-r3/`）、D5 r1（未打包来源：`WorkArena:campaigns/bat-sanitize-matrixspec-lean-v1/runs/bln-r1/`）。
## H0601：把 confirmed Spec 升级为语义闭包，并把证据绑定到每个 REQ
H0601 的精确谱系是 `H04 W-01/P-01 → H052 a601aa8 → H052 retrospective W-01/P-01 + W-02/P-02 → H0601`。两组 retrospective Cards 是对用户此前已选择、实施并完成评测的历史决策做固化，不是新的 pending Proposal；[Weakness Cards](../archive/matrixspec-evolution/analyses/H052/h052-postformal-20260814-019ff5c4-a/weakness-shortlist.yaml) 与 [Proposal Cards](../archive/matrixspec-evolution/analyses/H052/h052-postformal-20260814-019ff5c4-a/proposals.yaml) 已进入主归档。H0601 没有新建 canonical H06 Weakness Card，也不把 `H060101`–`H060103` 结构检查码冒充 Weakness ID。
### False semantic closure
H052 已经具备 `Change Spec → exact-digest confirmation → fresh Implement → Controller terminalization`，但章节、REQ 和确认存在仍可能掩盖公开 API identity、preserved behavior、precedence/default/fallback、docs/changelog 或真实 open decision 的缺失；max-turn `EXHAUSTED` 也可能被误当成 confirmed handoff。
H0601 保持两阶段架构，不增加 Proposal、Design、Tasks、Validation、Review 或第二产品合同。每个 REQ 必须写清 public surface 与公开名称/签名，或者给出真实的 `not-product-contract` 理由；Operator 只对 exact digest 做语义确认，未知就 `CONTINUE`。只有 `CONFIRM + 结构有效 + 无开放决定` 才 handoff，`EXHAUSTED` 保持 unconfirmed、workflow-blocking。Spec Agent 只在自己认为 draft ready 时运行 SDD-owned Candidate-visible 结构自检；Controller 不参与该 repair loop，也不发明产品答案。
### Obligation-to-visible-evidence disconnect
H052 的 visible verification 来自 task-level focused tests 或自由 shell commands，没有绑定 confirmed Spec 的具体 REQ。于是 pytest green 可能没有覆盖 static typing obligation，命令链或 `|| true` 也可能吞掉前序失败。
H0601 让每个 REQ 声明 `category + argv + env + cwd + timeoutSeconds`。Controller 以 `shell=false` 独立执行每条声明，记录真实 start/exit/timeout，以及分离的 stdout/stderr path、bytes 和 hash，并把 receipt 绑定到 exact Spec digest 与 current product projection。Evidence 必须完整且 current 才能 terminal；命令 red 如实进入 `productVerification=failed`，但不把诚实完成的 workflow 伪装成失败。
一句话概括：H0601 把“存在 confirmed Spec”升级为“exact-digest Spec 已语义闭包”，把“运行 task tests”升级为“每个 REQ 自带、独立执行且 current-bound 的 Candidate-visible evidence”。
### Effective evaluation 与 Judge replacement
有效结果是 workflow `24/24` completed、48 个有效 Judge 总分 `4,528/4,800`、均值 `94.3333`。任务均值分别为 D1 `100.00`、D2 `98.33`、D3 `98.67`、D4 `87.33`、D5 `88.50`、D6 `93.00`、D7 `98.50`、D8 fixed-v1 `90.33`。
三个诊断维度必须分栏：treatment audit passed `13/24`、external focused tests passed `18/24`、pre-hidden Candidate-visible verification passed `9/24`。这些红项包含 adoption、receipt currentness、工具缺失和封闭 runtime 等不同原因，不能合并成单一 product quality，也不能覆盖 Judge 结论。
D1 R3 原 Judge-01 的 `0` 被确认无效：它只读取 `product.diff` 1–360 行，随后在 baseline 搜索，而它声称缺失的方法实际位于 diff 第 452 和 513 行。用户授权对同一冻结 package 做 source-slot replacement；replacement 为 `100`，D1 R3 的有效双分变为 `[100,100]`。旧无效 bundle append-only 归档，`promotion.json` 绑定旧、新 hash 与相同 packageHash；只重新运行零模型 Summarize，没有重跑 Candidate、Operator、Controller、hidden evaluator 或 campaign。
权威入口：[H0601 effective summary](../archive/matrixspec-evolution/results/H0601/campaigns/cli-item-list-fields-matrixspec-lean-h0601-eval-r1-judge-recovery-20260814-r1/h0601-effective-summary.md)；[Judge promotion](../archive/matrixspec-evolution/results/H0601/campaigns/cli-item-list-fields-matrixspec-lean-h0601-eval-r1-judge-recovery-20260814-r1/promotion.json)。
## Bare / no-SDD comparator：直接实现的独立参照
Bare 固定使用 `gpt-5.6-terra / high` Candidate 与两个 `gpt-5.6-terra / high` Blind Judges，覆盖 D1–D8 各 3 次。24 格全部形成有效冻结交付并由 Candidate 正常 terminal；其中 focused/hidden acceptance 为 `17/24`，Judge 总分 `3,477/4,800`、均值 `72.4375`（展示为 `72.44`）。单 cell pilot 未进入正式分母（`pilotIncludedCells=0`）。
| Task | Focused/hidden acceptance | Judge mean |
| --- | ---: | ---: |
| D1 CLI | 3/3 | 79.17 |
| D2 ESLint | 3/3 | 47.67 |
| D3 pytest-plugin | 3/3 | 99.50 |
| D4 pytest-addini | 3/3 | 65.50 |
| D5 Bat | 3/3 | 92.50 |
| D6 SQLModel | 2/3 | 92.67 |
| D7 Axum | 0/3 | 67.50 |
| D8 Prometheus | 0/3 | 35.00 |
Wave 1 中 D3 的三个 Judge-01 slot 遇到 `chatgpt.com` connection refused；Candidate packages 已经冻结，因此只做 Judge-only recovery，`candidateRerun=false`。原失败证据 append-only 保留，最终补齐 D3 `6/6` Judge outputs。该事件属于 Judge infrastructure，不归因于 Candidate，也不改变 Bare 的 24-cell Candidate 分母。
权威入口：[Bare generation result](../archive/matrixspec-evolution/evaluations/bare/generation-result.json)；D3 invalid Judge archive（未打包来源：`WorkArena:archive/matrixspec-evolution/evaluations/bare/campaigns/bare-baseline-20260813-r1-pytest-plugin-entry-points/evaluation/invalid-judge-attempts/judge-recovery-01/`）。正式证据 commit 为 `50d67753fe185df084453614410132f69eb28006`；其结果现已复制进 `main` 归档，原 evidence commit 本身仍保持独立历史。
## 收益应该怎样理解
1. **机制收益优先于均分。** 某代可以修复明确状态机缺陷，却因为模型随机性、任务分布或更严格 admission 而没有聚合 uplift。
2. **Proposal 是可证伪假设，不是已证明因果。** 本文中的“收益”首先表示下一代观测方向，以及 targeted mechanism 是否按预测工作。
3. **H05 与 H052 不能直接排成前后代。** 它们分别解决 H04 的不同 Weakness，并且执行条件、工作流和成本语义不同。
4. **D8 始终进入统计。** 所有代际表都保持完整 `/24`；任务级拆分只用于解释完整差值，不构成另一个主视图。详细记录见 [模型运行与评测对账表](../experiments/matrixspec-harness-evolution-h0/model-evaluation-ledger.md#d8-evaluator-amendment-与完整-24-cell-口径)。
5. **H0 Terra/high 是模型条件，不是另一个 workflow generation。** 它用于比较被测模型，不改变上述 `H0 → H1 → H02 → H03 → H04` 控制面谱系。
6. **H0601 没有新的 Weakness Card namespace。** 它只处理 H052 已观察到的两个问题，不能事后创造 `H06/W-xx` 或把结构检查码当成 Weakness。
7. **Bare 只提供外部参照。** 它不属于 H treatment lineage；Candidate terminal、focused/hidden acceptance、Judge 与成本互相正交，不能用其中一列替代另一列。
## 边界与验证
- 本文是代际决策索引，不替代各代 descriptor、冻结 task summaries、Judge packages/results、Weakness Cards 或 Proposal Cards。
- 这里引用的每代结果均使用完整 `/24`；本文没有发布 D1–D7-only 主表。
- H1 主视图按用户授权使用 supplemental D5 replacement，原始 H1 D5 权重为 0，只保留历史证据。
- H05 与 H052 的匿名 Judge packages、results、task reports 和 aggregate 已复制到 主归档（未打包来源：`WorkArena:archive/matrixspec-evolution/`）；原 campaign 仍保留其独立执行身份。
- H0601 的 task reports、Judge recovery 和有效汇总已从 cleanup snapshot 恢复到主归档；完整匿名 packages/results 与 raw sessions 未被 snapshot 捕获，归档明确标记这一缺口。
- Bare aggregate、八份 task summary 和 D3 invalid Judge archive 已进入独立 evidence commit `50d6775`；Judge recovery receipts 位于该 worktree 的 gitignored `.scratch`，本地存在但不属于该 commit。Bare 不定义 `workflowCompleted`。
- 除 H04 post-formal RCA 已明确拆出的 H05/H052 路线外，不应仅凭 Proposal 编号相同就跨 namespace 串联；稳定引用必须包含 generation 与 analysisRunId。