MatrixSpec 工作流演进
2026-10-11 研究快照
H0–H0601 归档研究记录 · 2026-10-11 迁入快照

MatrixSpec 工作流演进：阶段、证据与成本

这项研究观察 MatrixSpec 如何从一代软件任务的失败轨迹找出问题，修改 harness 的规则与角色流程，再用下一代结果检验这些修改。评测和控制器在 Workflow Arena 仓完成，基础 CLI 来自 MatrixSpec。先读实验范围与方法，再看三个研究问题与仓库、提交及运行版本。

固定 24 个有效行为单元 D8 计入分母 代际对比为描述性观察

实验总览

每代使用 D1–D8 八个任务、每题三次的完整 24-cell 分母。外层评测链固定为 Prepare → Run → Freeze → Audit → Judge → Summarize：先冻结匿名产物，再由两个独立 Blind Judge 评分，形成 48 份评分。流程完成、外部 focused / product 验证、Audit、Judge 与 Candidate/Harness tokens 分开记账。查看跨代汇总数据

思路：由失败轨迹形成可检验的干预

图 1 · 从冻结结果到下一代干预的分析循环

冻结本代

保存完整分母、轨迹和结果；成功运行与失败运行一起进入分析。

逐格找出 What

Luna/xhigh 从每个 cell 的轨迹提取可复核的模式与异常。

全批解释 Why

Sol/high 比对整批、成功反例与替代解释；人类确认 Weakness。

选择并再评测

选择 Proposal，获授权后实施，再读下一代的多本账与反证。

事后分析角色与被测实验执行角色不同。H0 → H1 → H02 → H03 → H04 后，H05 与 H052 是从 H04 分出的 sibling；H052 再到 H0601。Bare / no-SDD 是独立对照，不进入 H 演进谱系。查看完整谱系与边界

模型设置：角色和强度随代际变化

这里修改 harness 与模型配置，没有训练权重。下表 Luna、Terra 分别指 gpt-5.6-luna、gpt-5.6-terra；high/xhigh 是推理强度设置。Candidate 负责交付，Operator 推动阶段，Reviewer 审查，两个独立 Blind Judge 为冻结产物评分。事后轨迹分析另用 Luna/xhigh 提 What、gpt-5.6-sol/high 判 Why、Sol/xhigh 协调，不属于下表的被测执行配置。

按代际汇总的模型与角色配置
条件被测执行角色Operator / Blind Judge角色边界
H0 同模型基线Terra / high：Candidate、Validator、ReviewerTerra / xhigh与 H0601 的被测执行模型一致；Judges 强度不同
H0 早期历史记录Luna / xhigh：Candidate、Validator、ReviewerTerra / xhigh产生 H0 W-03 的轨迹分析起点；不进入下方同模型比较
H1–H04Terra / high：Candidate/HarnessTerra / xhighH1 仍有 Validator、Reviewer；H02 起取消独立 Validation
H05Terra / high：Candidate/HarnessTerra / xhigh三类角色使用 priority
H052、H0601Terra / high：CandidateTerra / high两阶段；无独立 Reviewer
Bare / no-SDDTerra / high：Candidate无 Operator；双 Judge 为 Terra / high无 Reviewer；独立对照
模型配置的来源与核对边界

2026-10-02 按归档配置复核的摘录；不是新增实验。H0 的 experiments/matrixspec-harness-evolution-h0/generation.json 角色字段与 engine/drivers/matrixspec-evolution/harness.ps1:505–508 固定路径可核对 Candidate、Validator、Reviewer 的模型；H1–H04 分别见 experiments/matrixspec-harness-evolution-{h1,h02,h03-formal,h04-formal}/generation.json 的 roles 字段。模型运行与评测对账表提供 H0–H04 模型与成本入口。

H05 见 experiments/matrixspec-harness-evolution-h05-formal/generation.json:16–19；22 格源 commit 58bab7b59b89b9d75059602b1ee7cee15df8218c，另 2 格 replacement 为 5087c368157a448320c948e789d55d68b9bfc3ba。H052 固定于 a601aa86730c620e5a3ef777c32d535d59c82ece，各任务配置为 experiments/<task>-matrixspec-lean-v1/experiment.json（D8 为 experiments/prometheus-utf8-negotiation-matrixspec-lean-v1-evaluator-fixed-v1/experiment.json），Operator/Judge 继承同模型与强度的路径见 engine/drivers/matrixspec-profiled/harness.ps1:988,2318。H0601 固定于 afab51580435e8e71d1b80a52d22b72ecd774151，八份 experiments/<task>-matrixspec-lean-h0601-eval-r1/experiment.json 与同一 driver 的 :993,2323,2339 可追溯其模型与双 Judge；有效结果汇总也记录 replacement Judge 配置。H05/H052/H0601 原始配置未完整随本站打包，本站保留配置摘录，完整配置需在上述固定源码中查看。

观察与结论：控制面逐步收束，结果仍要分账

演进方向从多阶段检查逐步转为更清楚的责任、单一终止合同与逐项 REQ 可见证据。下方选择 H0 Terra/high 与 H0601 Terra/high：两端的被测执行模型及强度一致，但角色流程、Operator / Judge 条件和验证合同仍有差异。差值是描述性观察，不能证明某一项 Proposal 的因果收益或唯一最优结构。

分开读结果H0 Terra/high → H0601 Terra/high
Candidate/Harness tokens292,164,097 → 84,836,263减少 207,327,834（70.96%）；H0601 为 H0 的 29.04%
Blind Judge 均分88.0625 → 94.333348 份评分总分 4,227 → 4,528；+6.2708 点（相对 +7.12%）；Judge 强度不同
Workflow 完成14/24 → 24/24+10 个 cell；流程完成不等于产品全过
外部验证 / AuditH0 focused 15/24；H0601 external focused 18/24H0601 treatment audit 13/24，pre-hidden visible verification 9/24；验证口径各自独立

H052 也呈现 workflow 24/24、product 19/24 的分栏现象。跨代汇总 JSON与H0601 有效结果汇总保留完整数据与限制。

初始工作流

最早的 SDD：H0 的七个阶段

先看各阶段负责什么，再看后续代际改动了哪一项。这里描述 MatrixSpec a93d0b8 的原始 v1 合同；Luna 和 Terra 正式 H0 均使用这一阶段顺序。

Candidate 撰写文档并实施；第 5 阶段有独立 Validator，第 7 阶段有独立 Reviewer。H0 实验的前五阶段由 Operator 模拟产品负责人确认，并非真人逐格确认；原生 MatrixSpec 预期由用户确认。Controller 负责阶段接受与状态推进，文档结构通过不等于内容已被机器证明。

  1. 01 / proposal

    需求澄清

    把请求还原成要解决的问题，确定可观察成功标准、范围、不做什么、已确认决定与未决问题。

    产物proposal.md

    进入下一步文档写好，Operator 确认问题与范围后，由 Controller 接受。

  2. 02 / delta-spec

    规格增量

    把确认需求写成新增、修改、删除的业务规则、异常和数据约束，说明最终行为应是什么。

    产物delta-spec.md

    进入下一步Operator 确认规则与验收口径后，由 Controller 接受。

  3. 03 / delta-design

    设计增量

    设计实现方式、接口、数据流、取舍与风险，说明准备怎么做。

    产物delta-design.md

    进入下一步Operator 确认影响产品契约的设计决定后，由 Controller 接受。

  4. 04 / tasks

    任务拆解

    把设计拆成编号任务，逐项写明涉及文件、上下文、具体动作与验证方式，并安排最终全量文档刷新。

    产物tasks.md，含 Files / Context / Do / Verify。

    进入下一步Operator 确认任务覆盖已确认义务后，由 Controller 接受。

  5. 05 / validation

    实施前一致性验证

    独立检查提案、规格、设计与任务是否相互覆盖，是否与全量文档冲突，是否仍有未决决定或环境迁移、兼容风险。这是实施前审计划，不是运行产品测试。

    产物validation.md；意见为“可进入实现”或“实现前需修订”。

    进入下一步报告写好、Operator 确认后由 Controller 接受；当时程序不自动核对报告中的“允许进入实现”是否为“是”。

  6. 06 / implementation

    实施

    按确认任务修改代码与测试，自行验证，并更新任务状态。

    产物代码、测试、更新后的 tasks.md；没有独立 implementation.md。

    进入下一步阶段就绪后，H0 检查 tasks.md 无待办 / 进行中（pending / in-progress）；阻塞任务也可作为已结束状态继续记账，不等于问题已解决。此时尚无 H03 的逐项义务证据门。

  7. 07 / review

    实现后审查

    独立 Reviewer 对照产品 diff、验证证据与已确认文档，给出 Approved 或 Changes Required。

    产物review.md。

    进入下一步H0 Controller 解析 Decision: Approved 才接受；未批准时由 Candidate 修复后再审，最多四轮审查。此时还没有 H04 的当前且通过的检查凭据绑定。

以上文件共同位于 matspec/changes/<change>/。七阶段之后刷新全量 spec / design 并完成 done 归档；随后外层 Freeze 独立执行 focused tests，不属于第 5 阶段的前置验证。

合同与实测的边界：规范要求阶段产物完整，不表示机器已证明每条业务语义。H0 CLI 的阶段接受主要检查前序确认、文件存在和非模板占位；内容判断由 Operator / Reviewer 承担。

查看固定版本与原始路径

这是固定源码合同的摘录，不是逐格实测语义达成证明。MatrixSpec a93d0b8d804db4b7864159f8b04234a457c18f1e：workflow-packs/matspec/workflow.yaml:3–49、src/constants.js:1–107、workflow-packs/matspec/templates/delta/{proposal,delta-spec,delta-design,tasks,validation,review}.md、src/state.js:153–195,223–262、src/validation.js:69–80。H0 Terra 的 WorkArena 固定版本 d716d5cbef7ac7bd4913b148b8367c57cee36dfa：engine/drivers/matrixspec-evolution/harness.ps1:467–569（前五阶段）、:572–614（实施）、:617–639（审查）、:642–672（最终化）、:884–888（外部测试）；早期 Luna 的 a083c4da577e6144a04e65dd96ab62f2c6cb48b2 / c217bce043a0356d9e2a16f94a85a0fa7a9040e7 使用相同阶段规则。原始配置文件未全部随本站打包；可继续核对模型对账表和代际简史。

规则变化

每代改了哪个环节

沿 H0 到 H04 的主线，再分别看 H04 的 H05、H052 两个后继。图中标签表示规则变化，不代表新增的工作流阶段。

图 2 · 代际演进

每一代改了哪条规则？

阶段数量变化与阶段通过、回退规则变化是两件事。顺着竖线读 H0 到 H04；H04 后分成 H05 与 H052 两条独立路线，只有 H052 继续到 H0601。下文解释固定合同与干预意图，不表示收益已被证明。

  1. H0 · 基线
    无父代7 个阶段初始合同

    先建立七阶段 SDD 流程

    覆盖环节：提案、规格、设计、任务、前置验证、实施、审查。每一环的职责与进入下一步的条件见上方 H0 七阶段。

  2. H1 / H01 · 父代 H0
    7 → 7 阶段加跨阶段恢复规则

    超出检查者权限的问题可以退回修复

    改哪一环：Validation / Review 的负面结论，以及对应的上游工件。

    旧：发现超出检查者权限的上游问题时，只能写报告，当前角色不能修改出错文件；H0 原有普通代码修复与 Review 重审仍可进行。

    新：负面结论可触发 blocked / back，使受影响的下游确认失效；退给能修改的角色，修改后重新确认、复查。没有增加阶段，也没有删除 Validation。

    查看 H0 W-03 → P-02 Card
  3. H02 · 父代 H1
    7 → 6 阶段删阶段、转移职责

    去掉独立前置验证阶段

    改哪一环：删独立 Validation；必要的独立验证交给后续 Review。

    旧：前置 Validator 发现上游问题，仍可能无权修复。

    新：Review 承担必要验证；失败沿 H1 已有恢复路径交回修复角色。测试与验证义务继续存在。

    新顺序：proposal → delta-spec → delta-design → tasks → implementation → review。

    查看 H1 P-01 Card
  4. H03 · 父代 H02
    6 → 6 阶段改就绪标准

    实施结束前逐项对上需求证据

    改哪一环：Implementation 进入 Review 之前的就绪判断；没有新增证据阶段。

    旧：汇总完成或测试通过的信号，可能早于逐项义务真正落实。

    新：每项确认义务都对应实现证据和验证证据，否则保持 pending，不进入 Review；Review 与恢复规则保留。

    查看 H02 P-01 Card
  5. H04 · 父代 H03
    6 → 6 阶段改审查批准标准

    审查批准必须有当前检查凭据

    改哪一环：Review 的正向批准标准。

    旧：Reviewer 写下 Approved，可能与 Controller 看到的红色或陈旧验证结果矛盾。

    新：正向 Review 必须引用当前变更、当前产品版本且通过的 Controller focused 检查凭据；一句 Approved 不能覆盖真实检查。

    此干预 Card 来自 H02 agent-derived W-02/P-01；代码父代仍是 H03。

    查看 H02 agent-derived P-01 Card

从 H04 分出两条独立路线

H05 和 H052 是同一父代的 sibling，图中并列；H05 不通向 H052。

路线 A · H04 → H05
H05 · 父代 H04
6 → 6 阶段加冲突恢复规则

把上游冲突退回真正该改的环节

改哪一环：跨阶段权威冲突的恢复路由；六阶段和 H04 审查门保留。

旧：规格、设计等上游内容冲突，可能反复退给无权修改上游的 tasks 环节。

新：识别 authority conflict，找到最早确实需要变化的工件和责任环节；修改并重确认，或明确优先级后，才让下游重入。不是一律回到 proposal。

查看 H04 P-04 Card

此路线在本图止于 H05。

路线 B · H04 → H052 → H0601
H052 · 父代 H04
6 → 2 阶段删独立阶段、统一终止合同

变更规格确认后，换新会话实施

删与留：保留 delta-spec（界面名 Change Spec）→ implementation（新会话 Implement）；删除独立 proposal、delta-design、tasks、review 阶段及其文件。Validation 早在 H02 已删。

旧 → 新：实施中的两个完成标记相互竞争 → 只暴露 MATSPEC_STAGE_READY；确认具体版本 Change Spec 后，再给全新 Implement 会话。

Change Spec 承载目标、范围、产品义务和必要决定；Implement 自行安排内部步骤。收尾取消刷新 Full Spec / Full Design；产品验证与 Audit 仍单独计量，产品测试红项不自动否定流程完成。阶段精简是后续实际采用的设计，独立 Review 批准门并未搬入 Spec。

查看 H04 P-01 Card
H0601 · 父代 H052
2 → 2 阶段改交接与证据标准

规格语义与逐项验证都有当前证据

只改两个门：两阶段不变；没有新增独立 Review / Validation。

Change Spec 交接，旧 → 新：仅有章节、REQ 和 digest 确认仍可能漏掉公开义务 → 逐项检查规格语义、公开名称与保留行为；不确定时不交接。

Implement 证据，旧 → 新：汇总验证可能与单条需求脱节 → 每条 REQ 声明可运行的验证方法，由 Controller 独立执行并绑定当前 Spec / 产物；证据缺失或陈旧阻断可信结束，产品测试红项如实记录，不要求全部变绿。

查看 H052 P-01 / P-02 Cards

Bare / no-SDD：独立对照

不走 SDD，直接执行软件任务，用来参照 harness 流程的额外投入与交付结果。Bare 不是 H0 的祖先，也不是演进代际。

共同外层评测：每个环节做什么

这套评测链用于各条件的结果收集，不是被测 harness 的阶段，也不表示 generation 继承。

  1. Prepare准备任务与固定输入条件
  2. Run按该模型与 harness 条件执行
  3. Freeze固定产物和轨迹
  4. Audit核查执行是否符合约定
  5. Judge对冻结交付进行独立盲评
  6. Summarize分别汇总流程完成、验证、评分与成本
查看可复制的 Mermaid 谱系（页面无需渲染器）
flowchart TB
    subgraph LINEAGE["MatrixSpec 代际演进"]
        H0["H0：七阶段基线"] --> H1["H1/H01：七阶段；加跨阶段回退"]
        H1 --> H02["H02：六阶段；删独立 Validation"]
        H02 --> H03["H03：六阶段；改 Implement 就绪门"]
        H03 --> H04["H04：六阶段；改 Review 批准门"]
        H04 --> H05["H05：六阶段；加上游冲突恢复"]
        H04 --> H052["H052：两阶段；Change Spec → fresh Implement"]
        H052 --> H0601["H0601：两阶段；改 Spec 交接与 Implement 证据门"]
    end
    Bare["Bare / no-SDD：独立直接执行对照"]
    subgraph OUTER["共同外层评测：独立于被测 harness 阶段"]
        Prepare["准备任务与输入"] --> Run["按条件执行"] --> Freeze["固定产物与轨迹"]
        Freeze --> Audit["核查执行约定"] --> Judge["独立盲评"] --> Summarize["分栏汇总结果"]
    end
查看固定合同版本与细部标准

以下是 WorkArena descriptor、固定 MatrixSpec 源码合同与归档 Proposal 的摘录；原始配置未完整随本站打包，路径只作固定源码定位。代际简史说明实际采用的设计与结果。

  • H1：WorkArena experiments/matrixspec-harness-evolution-h1/generations/H1.json 固定 MatrixSpec commit 2291c4b5b119e00df751d841a81e12afdecac443。
  • H02：WorkArena experiments/matrixspec-harness-evolution-h02/generations/H02.json 固定 MatrixSpec commit af038b14125bfc4d1c89a5dc1148ba1af28e35e5。
  • H03：WorkArena experiments/matrixspec-harness-evolution-h03/generations/H03.json 固定 MatrixSpec commit 6a5a17e9a137d5e253b7f427002bbd03bf193546。H04 的 WorkArena experiments/matrixspec-harness-evolution-h04/generations/H04.json 复用同一 MatrixSpec pin，另加 WorkArena Controller 的正向 Review gate；其 Card 来自 H02 agent-derived 分析。
  • H05：WorkArena commit 5087c368157a448320c948e789d55d68b9bfc3ba 的 experiments/matrixspec-harness-evolution-h05/generations/H05.json 与 earliest-authority-owner 规则。
  • H052：WorkArena commit a601aa86730c620e5a3ef777c32d535d59c82ece 的 packs/capabilities/matrixspec-lean-v1/overlays/workflow.lean.yaml:3、delta-spec.md:8、engine/drivers/matrixspec-lean/harness.ps1:42、driver.ps1:189。两阶段合同还设 requiresFullSpec:false、requiresFullDesign:false、finalization.require_updated=[]。
  • H0601：WorkArena commit afab51580435e8e71d1b80a52d22b72ecd774151 保留两阶段；engine/drivers/matrixspec-lean/harness.ps1:112 处理语义确认，同文件 :452 逐项执行验证、:549 检查证据 currentness；engine/drivers/matrixspec-lean/driver.ps1:145 说明 EXHAUSTED 不算确认。Change Spec 必须逐项覆盖公开名称、签名或说明非产品合同，且结构有效、无未决决定并获得 CONFIRM；不确定则 CONTINUE。Implement 验证声明含命令、环境、目录、超时；缺失或损坏证据阻断可信结束，真实测试失败按事实记录。
研究问题

三个问题与回答

先直接回答三个问题，再看后面的结果和实例；每个答案下都附有可核对的依据。

Q1 / 结果与成本

H0 的流程投入是否转化为任务完成和交付质量？

有帮助，但 H0 过重。与 Bare 相比，H0 Terra/high 的盲评分从 72.44 升到 88.06，记录 tokens 约为 6.9 倍；H0 自身只有 14/24 个流程完成，较重的阶段与交接仍会卡住。后来 H0601 的评分为 94.33，记录 tokens 比 H0 少约 71%，显示有效约束可以在更短的流程中保留。

依据：跨代汇总、Bare 结果与总览比较。
Q2 / 从轨迹到下一代

如何从失败轨迹提出可检验的下一代方案？

先找到失败发生的具体位置，再针对这个卡点改流程，用下一轮实验看是否解决。早期 H0 Luna/xhigh 轨迹中，C018 发现设计矛盾却只能改验证报告，C004/C015 则在问题没变时反复审查。由此形成 W-03：发现问题的人缺少把问题交回原负责人修好的路径。选中的 P-02 把“退回—修正源文件—重新确认”接入流程，形成 H1；H1 补上了这条路，但只完成 10/24 次流程，其他卡点仍需继续处理。

依据：H0 W-03 证据、H1 进化入口和H1 结果。
Q3 / 演进后的控制面

为什么各代工作流采用了这些阶段和规则？

这些变化主要围绕三件事：让问题能被修好、减少重复交接、把检查落到具体需求。H1/H05 把上游冲突退回该改的人与文件；H02 删去独立 Validation，H052 进一步压到规格→实施两阶段，减少文档维护和阶段切换；H03/H04/H0601 逐步要求实现与验证有具体依据，H0601 先把规格说清楚再开工，而不是增加新阶段兜底。

依据：进化入口、代际结果与逐代规则图。
代际台账

各代的任务完成、验证结果与成本

每代都保留两个不同入口：进化记录说明为什么选择当前干预，正式结果记录说明运行后观察到什么。以下比较使用完整 24 个实验单元，包含 D8。

进化入口

进化记录：实际选中的方案

generation · analysisRunId · W/P

点进去应该立即看到上一代暴露的问题、实际选中的 Weakness/Proposal，以及当前代改变了哪一个策略杠杆。

打开进化入口索引子页面 →
正式结果入口

正式结果：运行后的观察

aggregate · Judge · cost · scope

这里记录各代实际跑出的成绩。H05 和 H052 是从 H04 分出的两条路线。

打开代际结果子页面 →
稳定引用提醒例如 H0 / h0-root-cause-20260809-a / P-02。不能只写同名的 P-01，更不能从代码父代猜卡片来源。
读表提示

评分看交付表现，Token 看模型用量，流程完成数看能否顺利走完。并排读这几项，更容易看出一代流程的得失。

MatrixSpec 代际、Judge 分数、token 总量与独立 comparator 的完整 24-cell 台账
当前代 / 条件进化入口 / 稳定引用主要杠杆完整 /24 结果总 tokens
Candidate / Harness 归档口径		结果入口
H0 Terra/high
同模型比较基线		无上游 Card
H0 的另一被测模型条件，不是新 generation		同一 H0 harness；被测执行模型与 H0601 均为 Terra/high。workflow 14/24focused 15/24 · Judge 88.0625（4,227/48）292,164,097Terra/high bundle跨代汇总 JSON
模型与成本对账
H0 Luna/xhigh
历史演进起点		无上游 Card
H0 / h0-root-cause-20260809-a / W-03		产生 W-03 的历史分析基线；不用于本页同模型端点比较。workflow 18/24focused 19/24 · Judge 90.1250597,146,805Luna/xhigh bundleH0 历史结果叙事
H0 Luna result ↗
H1 / H01H0 / h0-root-cause-20260809-a / W-03 → P-02structured blocked verdict、back、invalidation、owner repair、reconfirm。workflow 10/24focused 18/24 · Judge 93.5208316,713,117主视图 costH1 正式 generation 叙事
当前归档没有独立 H1 generation-result 文件。
H02H1 / h1-root-cause-20260811-a / W-01 → P-01删除 standalone Validation；验证责任并入 Review。workflow 17/24focused 19/24 · Judge 94.4792247,515,656主视图 costH02 结果叙事
H03H02 / h02-root-cause-20260811-a / W-01 → P-01逐项 obligation → implementation evidence → verification evidence。workflow 18/24focused 18/24 · Judge 94.8958276,702,480主视图 costH03 generation-result.json ↗
H04H02 / h02-agent-analysis-20260811-a / W-02 → P-01
agent-derived → Controller-Evidence-Bound Review		positive Review 绑定 current / passed focused receipt。workflow 12/24focused 17/24 · Judge 89.7917219,748,287主视图 costH04 generation-result.json ↗
H05H04 / h04-postformal-20260812-019ff55f-a / W-04 → P-04authority conflict 路由到最早必须变化的权威 owner。workflow 15/24focused 20/24 · Judge 95.0000259,151,137主视图 costH05 generation-result.json ↗
H052H04 / h04-postformal-20260812-019ff55f-a / W-01 → P-01single terminal contract；workflow、product、Audit 分栏。workflow 24/24product 19/24 · Judge 92.7708116,857,308主视图 costH052 修正后主结果 ↗
旧 D8 selection 快照（非修正后主结果）↗
H0601H052 / h052-postformal-20260814-019ff5c4-a / W-01/P-01 + W-02/P-02semantic closure；每个 REQ 自带 current-bound visible evidence。workflow 24/24audit 13/24 · external focused 18/24 · Judge 94.333384,836,263正式 H0601（口语 H06）H0601 effective summary ↗
Bare / no-SDD无进化入口
独立 comparator，不入 H lineage		direct-Candidate；不使用 SDD、Operator 或 Reviewer。candidate terminal 24/24focused/hidden 17/24 · Judge 72.437542,327,170Candidate-onlyBare generation-result.json ↗
H052 两版结果旧 D8 selection 快照的 Judge 总分为 4,375（D8 为 384）；修正后主结果为 4,453（D8 为 462），均含 48 份评分。差值 78 全部来自按 fresh D8 替换口径纳入的新 D8 结果，两版分别保留；主表使用修正后均分 92.7708。
三种方案并排看

Bare、H0 Terra/high 与 H0601 的评分和用量

三种条件的被测 Candidate 都使用 Terra/high。比较卡保留精确数值，下方竖柱帮助看出分数和记录用量各自的差距。

Bare → H0 Terra/high

评分提高，用量也增加

Judge 均分+15.625072.4375 → 88.0625
总分 3,477 → 4,227 / 4,800
相对 +21.57%
总 tokens+249,836,92742,327,170 → 292,164,097
+590.25% · 约 6.90×

H0 加入规格、设计、任务拆解和检查复核，盲评分更高；更多文档读写和角色交接也带来明显的 token 开销。

H0 Terra/high → H0601

评分继续提高，用量明显减少

Judge 均分+6.270888.0625 → 94.3333
总分 4,227 → 4,528 / 4,800
相对 +7.12%
总 tokens−207,327,834292,164,097 → 84,836,263
−70.96% · H0601 为 29.04%

后续代际先删独立 Validation，再把流程压到规格→实施两阶段；规格确认和逐需求验证仍被保留、加强。

图 3 · Bare、H0 与 H0601 的评分和用量两项指标各用自己的零起点刻度；H0 指 Terra/high 条件，精确值见上方比较卡。

盲评均分 0–100 分

  1. 72.44Bare
  2. 88.06H0
  3. 94.33H0601

记录 tokens 0–300 百万

  1. 42.3MBare
  2. 292.2MH0
  3. 84.8MH0601

图中最直观的一点是：H0 比 Bare 用量高得多，H0601 则以更低的记录用量保留了较高评分。流程如何变化，见下文的简短讨论。

数据说明：这些分数、完成数和 tokens 怎么计

盲评均分按 0–100 分显示，每个实验单元有两份独立评分。三种条件的被测 Candidate 都是 Terra/high，但 Bare 只统计 Candidate 用量且没有 Operator / Reviewer；H0 与 H0601 统计 Candidate/Harness，用到的 Operator、Judge 强度、角色结构和工作流并不完全相同。Bare 的 24/24 指 Candidate 正常结束，不等于 H0 的流程完成；完整分母含 D8。

H0601 的 24/24 流程完成之外，规则执行审计、外部专项验证、隐藏验收前的候选可见验证分别为 13/24、18/24、9/24；这些是不同检查，不能合成一个通过率。模型与成本对账和跨代汇总保留完整数值。

产生 W-03 的历史 H0 Luna/xhigh 是另一被测模型条件：workflow 18/24、focused 19/24、Judge 90.1250、Candidate/Harness 597,146,805 tokens。历史的 Bare → H0 Luna 比较为 Judge +17.6875 点、tokens +554,819,635（+1310.79%）；H0 Luna → H0601 为 Judge +4.2083 点、tokens −512,310,542（−85.79%）。它们不参与上方同被测模型比较。H0 Luna 归档结果。

这条路线并非每次改动都立刻变好。H1 的流程完成为 10/24，H04 为 12/24；H052 虽达到 24/24 流程完成，产品验证仍是 19/24。到 H0601，流程完成保持 24/24，具体检查仍有未通过项。上表与代际简史可逐代核对这些变化。

分析方法

轨迹分析方法：从逐格事实到候选方案

左列是分析合同，右列是 H0 W-03 在归档中的具体证据。逐格观察先于跨任务解释；用户确认根因后，才进入方案生成与选择。

01

规范 / freeze冻结完整 denominator

MAIN 提供 parentHarness、generation、analysisRunId、24-cell summaries、排除项与 authority receipt；成功运行也必须作为反证。

固定分母，不挑“看起来最有问题”的日志。

H0 实案 / receipt24/24 included

H0 的 24 个 selected valid behavior cells 全部 included、0 excluded；8 个 non-selected infrastructure-invalid physical attempts 只留在 coverage/history。

打开 coverage.json ↗
02

规范 / IR把轨迹变成可复核段

Trajectory IR 按 stage、session、actor 切分，保留 sourceRef、行范围、frozen hash、event/tool/wait 计数。

事实层可逆；派生物不能覆盖 raw evidence。

H0 实案 / refsW-03 证据入口

W-03 的 raw refs 写在 shortlist JSON；主归档保留 shortlist、pattern evidence 与 coverage，但原始 raw-sessions JSONL 未随归档提供。

打开 W-03 shortlist ↗
03

规范 / Luna逐 cell 产出可回溯的 What

不是只给一句标签：先覆盖该 cell 的 stage/session segment，再把 claim 绑定到 obligation 或 target、before/after 或 information delta、局部成本、直接证据、反证和 raw refs；证据不足时必须 abstain。

它不跨 run 解释 Why，也不生成 Proposal。

H0 实案 / patternsC004 · C015 · C018

局部事实分别指向 unchanged review、scope 外 V-1 contradiction、validation report-only clearance；这些事实还不能直接推出“应该增加 back”。

打开 pattern evidence ↗
04

规范 / Coordinator + Sol先聚合，再回答 Why

24 份 Pattern Evidence 齐备后，Coordinator 按 obligation、target、state transition 去重但保留每次 raw ref；单个 Sol 才消费完整批次、成功负例、coverage 与 outcome sidecar，检查 First Divergence、attribution、alternatives、counterevidence、counterfactual、confidence。

recurrence 和 scope 不等于 causal proof。

H0 实案 / WeaknessW-03 = medium

支持范围仅 3 个 task family / 3 个 workflow_failed cell；C017、C013 等 counterevidence 保留了 medium confidence，而不是唯一根因。

查看 W-03 条目 ↗
05

规范 / gate 01用户确认 Root Cause

Coordinator 提交 shortlist、支持范围、替代解释、反证与 confidence；用户可确认、修改或否决。沉默不是批准。

只有确认后才生成 Proposal。

H0 实案 / handoff当时仍 pending

归档 handoff 记录 userRootCauseConfirmation=pending、proposalGeneration=not_started；当时没有历史 proposals.yaml。

打开 archived handoff ↗
06

规范 / gate 02生成 0..N 张单杠杆卡

Proposal 必须有直接行为预测与 rejection conditions；不写 target file、patch、prompt diff，不编造百分比或 cell 阈值。

用户可选一张、不选或要求重做。

H0 实案 / choiceP-02 后来被选中

当前 Proposal 文档明确 P-01/P-02 是后来按用户要求生成的候选；历史选择是 P-02 / H5-inspired，形成正式 H1。

选择卡 ≠ 实施授权 ≠ 正式实验授权。
逐格观察协议

“逐 cell 只回答 What”具体意味着什么？

一个 cell 是逻辑行为单元，不是某个单独 JSONL 文件。Luna 只能在该 cell 的 frozen Trajectory IR、结果 sidecar、输出 schema 与允许上下文内工作；它要把“看见了什么”写成可回到原始轨迹的局部证据，而不是把失败结局倒推成根因。

展开输入、判定协议与 H0 三个 cell 实案
输入约束

先锁输入，不让模型自选日志

Coordinator 从 MAIN receipt 接收 parentHarness、generation、analysisRunId、24-cell coverage 与显式排除项。每个 included cell 的输入只包含：

  • 按 stage、session、actor 切分的 Trajectory IR。
  • message、tool call/result、错误、路径、命令、wait、compaction、局部状态事件。
  • outcome sidecar、workflow obligation、evidence completeness 与 frozen raw refs。
覆盖与轨迹分段

先证明“看全了这一格”

每个 segment 需要有 stage key、actor、session/parent session、sourceRef、行范围与 hash；不能确定 stage 就写 null，不能靠命名猜。成功运行同样进入分析，作为“同一 Harness 下没有触发 Pattern”的反例。

  • 日志不可读时询问 MAIN，不自行改判 validity。
  • retry 草稿、失败调用、普通侦察输出不进入 accepted Pattern Evidence。
输出约束

What 要带证据，不是标签

每个 candidate 至少写 claim、segment、obligation/target、information delta 或 before/after、局部成本、直接证据、反证、confidence 与 raw refs。没有 obligation、完成机会或足够 evidence，就输出 abstention。

  • 输出可以为空数组；不能为了凑三类 Pattern 制造候选。
  • 不写跨 run 根因、不写 mutation、不写 Proposal。
Pattern A / 公开义务遗漏

公开义务没有出现

只有同时存在公开 obligation、合理完成机会、预期动作/证据/状态缺失，并且 evidence 范围足以判断“未出现”，才能提出 omission。

不是“结果失败所以前面都错”；要能指出缺失对象与完成机会。
Pattern B / 重复探索

同一目标被无增量重探

必须定位 earlier/later segment、明确 repeated target、说明 new information delta，并排除权限变化、外部状态变化或合理重验。重复 Review 本身不自动成立。

没有状态变化 ≠ 没有合理理由；理由无法排除时 abstain。
Pattern C / 零信息增量

花了局部成本却没有新信息

动作消耗了可观察成本，但没有新增知识、改变 artifact/controller state、关闭 obligation，或产生后续决策需要的新证据，才可归入 zero information gain。

等待、轮询、失败调用只有在没有状态信息时才进入该类。
C004 / S007 / REVIEW

第一次重审有增量，后续才是重复

第一次 post-change re-review 看到真实 diff 和新的 C1 regression；后续同一 full-spec/design finalization target 再进入 Review 时，implementation/test surface 没有变化，仍是 Changes Required。

What：later review 的 before/after decision、source/test state 与输入 digest 均未变。
分类：repeated_exploration + zero_information_gain；第一次重审不应被倒算成浪费。
查看 C004 Pattern Evidence ↗
C015 / S007 / REVIEW

检查结果通过，矛盾仍在写权限外

实现 focused suite 报告 175 passed，但同一个 V-1 empty-name cross-artifact contradiction 仍然存在；后续 Review 只把文案从 Current 改成 Latest，没有改变 source 或 Controller state。

What：target、decision 与 contradiction 保持不变，只有 report wording 变化。
分类：repeated_exploration + zero_information_gain；不能从这一步直接写“应增加 back”。
查看 C015 Pattern Evidence ↗
C018 / S005 / VALIDATION

只可写 validation.md，源文档没有转移

Validator 发现 design/tasks 冲突，但 Controller 只暴露 validation.md；后续重复请求没有新的 design-stage authorization、write path、controller payload 或 source artifact state。

What：权限边界和状态不变是可定位事实。
分类：zero_information_gain；对更强的 repeated-exploration 结论保持 abstain，不能把 constrained scope 本身写成产品缺陷。
查看 C018 Pattern Evidence ↗
What 与 Why 的分界：“C015 在同一个 V-1 contradiction 上重跑 focused checks，source digest 没变”是 Luna 可以提交的 What；“H0 需要 Controller-owned back/invalidation”要等完整 Pattern batch、反证与 Sol 的跨 run/task 分析，并经过用户确认 Weakness 后才有资格进入 Proposal。
Coordinator / 聚合

聚合不是简单计数

Coordinator 按相同 obligation、target 或 state transition 合并同类候选，保留每个 occurrence 的独立 raw refs，区分 run/task/generation/runtime provenance，并避免把同一 Controller incident 的重复日志算成多个独立行为。

只有 24 个 included cell 的 Pattern Evidence 全部齐备，才交给单个 gpt-5.6-sol / high；不能先分给多个 Sol 再拼接 Root Cause。

Sol / 七项检查

Sol 如何把 What 变成可筛选 Weakness

  1. First Divergence：找最早从合理轨迹偏离的位置。
  2. Harness attribution：落到 Workflow、Information Flow、Knowledge、Artifact、Verification、Agent Responsibility 或 Recovery。
  3. Cross-run/task/generation：写清支持范围，而不是只报高频。
  4. Alternative explanations：考虑 handoff、上游质量、任务难度、下游指令与模型随机性。
  5. Counterevidence：检查同一 Harness 下没有触发 Pattern 的成功负例。
  6. Counterfactual prediction：写出改策略后首先应改变的行为。
  7. Confidence：用 high/medium/low 表达证据基础，允许 unresolved。
fact layer24-cell IR + raw refs
behavior layerPattern Evidence
human gate 01用户确认 Weakness
intervention layer0..N Proposal → 用户选卡
当时分析协议的调用约束

以下复述归档中的分析运行协议：当时原生 subagent / spawn_agent 不能可靠选择 Luna，每个 included cell 经本地 codex exec --ephemeral --ignore-user-config，read-only、无 web/network、fresh ephemeral invocation；不由默认子代理、Sol、Terra 或 Coordinator 代写。这是历史协议记录，不代表当前产品能力声明。

附录：当时的 Luna 本地调用命令
codex exec --ephemeral --ignore-user-config --json \
  -m gpt-5.6-luna -c model_reasoning_effort="xhigh" \
  -c web_search="disabled" -c approval_policy="never" \
  -s read-only -C <analysis-run-workspace> \
  --output-schema <luna-pattern-schema> -o <cell-output> -
Coordinator / 演进协调

组织证据，不替模型补证据

gpt-5.6-sol / xhigh
  • 检查合同、维护 handoff、集成 24-cell。
  • 根据已确认 Weakness 生成 Proposal。
  • 不实施 Proposal，不运行实验。
Luna / 逐格模式提取

逐 cell 语义化行为

gpt-5.6-luna / xhigh
  • 一次调用只覆盖一个 cell，保留 raw refs。
  • 只回答 What，不做跨运行 Root Cause。
  • 校验 model、effort、sandbox、input binding 与 schema。
Sol / 根因分析

跨 run/task 聚合 Why

gpt-5.6-sol / high
  • 消费完整 Pattern batch、成功负例和结果变量。
  • 保留 alternatives、counterevidence、unresolved。
  • 不把高频直接等同因果，不规定实现细节。
人工确认 / Weakness

确认 Weakness，才允许 Proposal

用户可以确认、修改或否决 Root Cause shortlist；证据不足的 Pattern 保持 unresolved。

SHORTLIST → 用户确认 / 修改 / 否决 → 0..N Proposal
人工选择 / Proposal

选择 Proposal，仍不等于执行

用户可选一张、不选或要求重做。实施、正式实验、Judge 与结果解释属于后续授权链。

CARDS → 用户选择 → 实施授权 → 正式实验授权
H0 冻结轨迹

H0 失效案例：W-03 的跨阶段修复断点

这一案例解释历史分析如何形成候选干预，与上文 Terra/high 端点成绩比较使用不同的 H0 模型条件。

W-03 来自更早的 H0 Luna/xhigh 冻结轨迹，并非从上述 Terra/high 端点数据反推。C004、C015、C018 分属三个任务族，三格均未完成流程。共同断点发生在检查者已经识别上游矛盾之后：C018 的 Validator 知道问题位于 delta-design.md，却只能修改 validation.md；C004/C015 在源问题未变化时重复进入 Review。这支持一个较窄的假设：检测之后缺少可达的源文件修复路径，或及时记录为阻塞结束的状态转换。H0 Weakness shortlist保留逐格证据。

该假设在原分析中仅为 medium 置信度。C017 通过 Operator 澄清取得新信息后完成，C013 重验时实际修改了源文档，C004 首次重审也伴随真实代码和测试变化。预期干预行为应是源文件或状态真实改变，或明确结束为 blocked，而非只改报告或对相同状态重复审查。P-02 进入 H1 后，流程完成为 10/24，不能把新增恢复能力直接等同整体完成率改善；相对产生 W-03 的 Luna 基线，这条历史比较还跨了被测模型。反证与范围、H1 结果可分别复核。

H0 / W-03 / MEDIUM

Unreachable cross-stage repair ownership

First Divergence 出现在 blocker 被发现之后：report 可以被改写，source 和 Controller state 却不变；于是同一个 digest 被重审，或矛盾被报告层“清除”。

覆盖24 / 24included valid behavior
流程18 / 6completed / failed
专项验证19 / 24tests passed
模式45 · 4 · 10omit · repeat · no-gain

C004

bat-sanitize

Review 在 unchanged finalization blocker 之后重新进入，仍保留同一个 Changes Required。首次 re-review 伴随真实实现/测试变化，只有后续 unchanged re-entry 支持 W-03。

shortlist / C004 ↗

C015

prometheus-utf8-negotiation

V-1 跨 artifact contradiction 仍在 reviewer writable scope 外，却重复跑 focused checks；实现检查可以绿色，source owner 仍未改变矛盾。

shortlist / C015 ↗

C018

pytest-addini-type-expressions

Validation 不编辑 delta-design.md，却在 validation.md 中短暂清除 design/task conflict；随后请求 design-stage authority，却没有 Controller transition。

shortlist / C018 ↗

第一分歧的形状

checker 发现 blocker→source 属于别的 stage→当前角色只能写 report→state 不变→假清除 / unchanged re-review / failure

Scope：H0 only；3 个 task family；C004、C015、C018 均 workflow_failed。主要影响是 evidence/workflow validity，不是统一产品缺陷。

反证与可证伪预测

C017 在 operator clarification 后获得新信息并完成；C013 在 source 真变化后重跑并产生新信息；C015 的 constrained scope 可能是正确的完整性约束。

预测：检测到 out-of-scope source contradiction 后，下一步应修改 source/state，或稳定结束为 blocked；不应对相同 digest 重审，也不应只修改 report 就声称冲突消失。

方案选择

干预方案与选择

H0 W-03 后形成两种不同干预：P-01 调整阶段结构，P-02 增加跨阶段恢复规则。历史上选中 P-02 并形成 H1；卡片中的预测和否决条件仍须与后续结果分开读。

P-01 / H1 启发

Default Validation Stage Compression

H0 / h0-root-cause-20260809-a / W-03 → P-01
干预规则对默认低风险 workflow 移除 standalone Validation；Standard / Full profile 仍可显式保留。

针对的断点

减少 C018 类型 validation-only dead-end 与一次 downstream checker handoff；不承诺解决 C004/C015 的 Review dead-end。

预期可观察行为

  • 默认 run 不再进入 validation.md 独立 accept。
  • report-only clearance 与无增量 Validation 重入减少。
  • 不预设整体 quality 或 completion uplift。

否决条件

  • Validation 只是改名或藏入另一 actor，形成等价 handoff。
  • obligation 被推迟到 Implementation/Review 才首次发现。
  • 错误 profile routing 或可归因回归。
这是“减少问题面”，不是修复通用 responsibility chain。
打开 P-01 Card ↗
P-02 / H5 启发

Reachable Cross-Stage Repair

H0 / h0-root-cause-20260809-a / W-03 → P-02
历史上选中
干预规则保留 checker，把 negative verdict 变成 Controller-owned signal：back、invalidation、owner repair，或稳定 blocked terminal。

针对的断点

同时瞄准 C004、C015、C018 的 Validation/Review 跨阶段 dead-end。

预期可观察行为

  • negative verdict 不再被错误 accept；旧 confirmation 先失效。
  • 可修 blocker 出现 back → source change → reconfirm → recheck。
  • 不可达或相同 context 再现时稳定结束，不进入 report-only loop。

否决条件

  • negative verdict 后仍可 accept，或旧 confirmation 仍有效。
  • source、Controller state、decision input 不变却重复 checker。
  • 把 C013/C017 的真实新信息误判为停滞。
这是“修复断链”，不是承诺 Judge uplift。H5 原型也不自动证明已有 owner、digest、stagnation 或 typed terminal。
打开 P-02 Card ↗
来源 WeaknessH0 / W-03
用户选择P-02 / H5-inspired
正式代际H1 / H01
标签与事实

H5-inspired 是 P-02 的策略谱系标签；仓库正式 generation ID 是 H1（历史文字也写作 H01）。H04 代码基于 H03，但 H04 的进化入口是 H02 agent-derived W-02 → P-01，不能从代码父代倒推卡片来源。

形态的边界

原始 H5 core 提供 structured verdict、blocked accept、repairTarget、back/invalidation、reconfirm/recheck；stable blocker identity、repairOwner/writable scope、source/controller/decision-input digest、stagnation detection、typed unreachable terminal、revision-aware ledger 仍是后续强化，不应倒写成原型已经具备。

结论

最后，怎么理解这两次变化

从流程变化看，主要可以这样理解。

Bare → H0：加入规格、设计、任务拆解和独立检查后，做什么、怎么做、交付是否到位都有了更多约束，有助于减少遗漏、提升交付质量；代价是多轮文档读写、检查和角色交接，所以 Token 也明显增加。

H0 → H0601：先删除独立的前置 Validation，后来把流程压到“确认规格 → 实施”两阶段，减少重复文档和多轮交接；同时把功夫留在规格确认和逐条需求验证上。这可以解释为什么流程变短、Token 更少，评分仍能提高。逐代规则与代际结果可对照阅读。

查看其他检查结果与归档限制

中间代也有反例：H1 流程完成 10/24，H04 为 12/24。H052 虽完成 24/24，产品验证仍是 19/24。缩短流程和收紧检查并不会让每一项结果同时上升。以上是流程层面的解释，单个环节的因果贡献仍需另行检验。

当前样本限于八项任务、每项三次。H0601 D1 R3 的有效评分使用相同冻结交付物的 Judge-only replacement；完整匿名包与原始 sessions 未全部随归档保存。H0601 有效结果汇总记载具体缺口。

独立对照

Bare / no-SDD 不在演化箭头里

24/24 terminal

Candidate 正常 terminal；focused/hidden acceptance 17/24；Blind Judge mean 72.4375。它不适用 workflowCompleted，不能替代 H0→H1 代际增量。

Candidate-only：42,327,170 tokens · 721 tools · 553.842237 credits。
打开 Bare generation result ↗
H0601 / 结果分栏

红项不能合并成 product quality

Judge 94.3333

完整结果同时报告 treatment audit 13/24、external focused 18/24、pre-hidden Candidate-visible verification 9/24；红项原因包含 adoption、currentness、工具缺失与封闭 runtime。

主 workflow 24/24；D8 仍计入完整分母。
打开 H0601 effective summary ↗
比较口径完整 /24 是主视图，D8 始终计入。代际差值记录观察结果，不能单独证明某张方案卡的因果收益。
附录：继续核对档案的步骤与页面边界
Session 阅读清单

新 Session 的五个检查动作

  1. 锁定 generation、analysisRunId、authority receipt 与 /24 coverage。
  2. 从 evolution entry 找到真实选中的 Weakness / Proposal，不从命名猜。
  3. 打开 formal result，分开读 workflow、quality、cost、Judge。
  4. 读反证与 scope，把 Proposal 当作可证伪预测。
  5. 重新确认用户是否分别授权实施与正式实验。

页面范围

不重写冻结 evidence

本次只迁入研究文档与公开证据副本，调整相对链接和历史本机路径；不修改原始 campaign、Judge 结果或冻结实验。原始 hash 与发布 hash 分开记录。

不运行实验角色

没有 Candidate、Operator、Reviewer、Judge 或 campaign 调度；Luna 命令只作为规范展示。

不替用户作因果结论

代际分数与机制收益保持 descriptive boundary；需要冻结干预实验才能检验 Proposal。

仓库与版本

评测在哪里跑，SDD 改动提交在哪里

这条研究线跨两个仓库。每个 commit 必须连着仓名和用途读；实现提交、基础 runtime、正式执行版本与当前 HEAD 分别回答不同问题。

Workflow Arena 是评测与实验控制器。它维护任务、冻结产物、Audit、Blind Judge、结果汇总以及驱动 MatrixSpec 的 harness。H052 的两阶段流程和 H0601 的语义确认、可见验证主要提交在它的 engine/drivers/matrixspec-lean/ 与 packs/capabilities/matrixspec-lean-v1/overlays/ 中。

MatrixSpec 是基础 CLI 与工作流状态机。H1 所需的 verdict/back/invalidation 回退能力在 MatrixSpec 分支中实现。H052、H0601 的 capability 则固定基础 MatrixSpec 7290445，运行时再叠加 Workflow Arena 的 driver 与 workflow/template overlays。这次将研究网页迁入 MatrixSpec，不表示已把那些实验流程移植到 MatSpec 产品。

已核验的关键实现与运行版本；完整 SHA 和可达性见 git-provenance.json
记录所属仓库commit它固定什么
H0 基础 runtimeMatrixSpeca93d0b8H0 加载的 CLI/工作流源码版本，不能替代评测平台版本。
H0 正式执行Workflow ArenaLuna Lane A a083c4d / B c217bce；Terra/high d716d5c不同模型条件与 lane 的执行回执；不能把后来的 d716d5c 倒写成全部 H0 的执行 pin。
H1 回退实现MatrixSpec58b71b7实现 formal verdict backtracking。本地分支对象可核验；它不是 H1 正式 runtime pin，也没有可访问的 GitHub commit 页面。
H1 / H02 / H03–H04 runtime独立 MatrixSpec checkout 的 manifest 记录2291c4b / af038b1 / 6a5a17e正式 descriptor 声明的 runtime；目前只确认为 manifest pin，不声称这些对象已经存在于 MatrixSpec GitHub 镜像。
H052 / H0601 基础MatrixSpec7290445Lean 基础 runtime；在两代 capability 中固定，新增实验流程仍由 Workflow Arena overlays 提供。
H052 两阶段实现Workflow Arena2537d05引入 confirmed Change Spec → fresh Implement；a601aa8 是后续 D8 evaluator 修正后的条件版本。
H0601 可见验证与确认Workflow Arenaa105758、2a5b1d0逐 REQ 绑定 Candidate-visible verification，确认前自检 Change Spec。正式 factor identity 为 H0601-da2b42b，实现提交与 factor identity 分开保存。

谱系是 H0 → H1 → H02 → H03 → H04，然后分成 H05 与 H052 → H0601 两条路线；Bare 是独立对照。代码父版本、选卡来源和正式执行条件分别保存，不能仅凭一个短 SHA 或相同 Proposal 编号串联。

发布范围：本目录是 2026-10-11 的静态研究快照，包含原网页真正引用的汇总、Weakness/Proposal 与匿名分析片段。原始轨迹、完整 Judge packages、运行 HOME 和部分历史 worktree 仅本机存在或已缺失，未随本次文档提交发布；原文“主归档”和“main”指 Workflow Arena 的来源归档。

完整 Git provenance：仓库、完整 SHA、runtime pins 与可达性 · 来源核验：原始 hash 与发布 hash · 研究快照说明。无法访问远端的提交以本地核验记录为入口。当前 HEAD 只说明核验时仓库的位置，不替代历史执行 pin。

来源

证据来源

以下列出代际结果、实际选中的方案卡和 H0 分析回执。本快照内部的证据入口使用相对路径；本页连同本地样式文件可离线阅读，GitHub 提交链接需联网。

方法协议

Root Cause & Proposal Session 运行规格

docs/matrixspec-root-cause-proposal-session.md

角色模型、Luna 本地调用边界、24-cell coverage、Weakness / Proposal schema 与两个人工关口。

实案叙事

从 Root Cause 到 H1/H5

docs/matrixspec-proposal-card-w03-h5.md

W-03 如何拆出 P-01 / P-02，为什么是两条不同策略，以及 H5 core 的实现边界。

冻结 H0 证据

H0 Weakness shortlist

archive/matrixspec-evolution/analyses/H0/h0-root-cause-20260809-a/weakness-shortlist.json

W-03 条目、C004/C015/C018、counterevidence、scope、counterfactual 与 raw refs。

证据边界

边界与验证

已归档的结果、当前材料缺口与离线检查路径分别列在下方；本页的机制解释不替代原始轨迹或实验回执。

已确认与当前缺口

  • H0 W-03 只支持 C004/C015/C018 的 H0-only 中等置信度假设；Proposal 是可证伪策略。
  • H0 handoff 在历史分析时仍是 confirmation pending；P-01/P-02 是后来按用户要求生成的候选卡。
  • W-03 JSON 的 raw-sessions 引用未随本静态快照提供原始 JSONL；页面只暴露 archived shortlist / pattern evidence / coverage。
  • H0601 的完整匿名 packages/results 与 raw sessions 未全部由 cleanup snapshot 捕获；effective summary 标注了这一点。
  • 本页不替代 descriptor、原始日志、Judge package 或用户决定；运行时状态可能随 checkout 与授权变化。

最小离线检查路径

对本文件做三项轻量检查即可复核交付边界：

  • 解析 HTML，确认结构闭合且只引用本地样式文件，没有远程 script / stylesheet / font / image。
  • 以本目录解析所有相对 href，确认目标文件与章节锚点存在。
  • 在宽屏与窄屏打开；检查宽表与图只在自己的 overflow 容器内滚动；再运行 git diff --check。

离线承诺：本页无 CDN、无远程字体或远程脚本/样式；连同本地样式文件可离线阅读，原生 details 即使无脚本也可读。