# 从 Root Cause 到 H1/H5：两张 Proposal Card 如何驱动 Codex 处理 W-03

## 直接答案

> 迁入说明（2026-10-11）：本文来自 Workflow Arena 的研究档案。下文“主归档”和“main”指原来源仓；本目录仅发布可复核的汇总与选卡证据，未打包的原始材料以文字来源定位信息保留。链接与本机路径已为离线阅读整理；原始文件 hash 和发布文件 hash 分开记录，见本目录的来源核验清单。

MatrixSpec 的 Root Cause & Proposal 流程不是让模型从失败日志直接猜补丁，而是依次完成“冻结事实、描述行为、推断根因、人工确认、提出单一策略干预”。最终的 Proposal Card 也不是实现说明书，而是一张带有证据边界、因果假设、策略杠杆、行为预测、否决条件和回归风险的探索地图。

这正是它能够驱动 Codex 探索代码仓的原因：卡片明确说明系统行为应该从什么变成什么，却故意不预填 target file、patch 或 prompt diff。Codex 因而必须沿真实责任链回答：负面结论在哪里产生、谁解析它、谁调用 `accept`、谁拥有 workflow state、是否存在反向 transition、旧 confirmation 如何失效、修复角色如何重新进入，以及 completion receipt 能否表达修订后的有效状态。

对 W-03 而言，同一个 Weakness 可以派生两张真正不同的策略卡：

```text
P-01 / H1-inspired：Default Validation Stage Compression
删除默认 standalone Validation，缩小跨阶段 blocker handoff 的问题面

P-02 / H5-inspired：Reachable Cross-Stage Repair
保留 checker，把负面结论变成 typed control signal，建立 back/invalidation/repair 链
```

W-03 是从 H0 运行轨迹推导出的 Harness Weakness；H1 与 H5 是两种不同的干预方向。H1 通过减少默认阶段规避 C018 类型的 Validation dead-end，但不能解决 C004/C015 的 Review dead-end；H5 通过控制面返修链直接处理 Validation/Review 的跨阶段 blocker。两张卡必须分别实验，不能合并后再把结果归因给其中一个机制。

## 先说明一条证据边界

本轮正式 analysis run `h0-root-cause-20260809-a` 已完成 24-cell bundle、Luna Pattern Extraction 和 Sol Root Cause Mining，但其 [handoff.json](../archive/matrixspec-evolution/analyses/H0/h0-root-cause-20260809-a/handoff.json) 仍记录：

```text
userRootCauseConfirmation = pending
proposalGeneration = not_started
```

因此，正式产物中存在 [W-03 Weakness Card](../archive/matrixspec-evolution/analyses/H0/h0-root-cause-20260809-a/weakness-shortlist.json)，却没有已经落盘的 W-03 `proposals.yaml`。本文后面两张 Proposal Card 是在用户明确要求拆分后，严格按固定 schema 新生成的候选卡，不冒充当时已经生成的历史产物，也不回写冻结 evidence。

这一区分很重要：Weakness Card 回答“为什么会发生”，Proposal Card 回答“下一代只改变哪个策略、预期首先看到什么、什么结果会否决它”。如果把二者合并，分析者很容易因为预先知道 H5，而把所有日志倒推成“缺少 `backStage`”。规范明确要求 Weakness 不得提前规定 mutation，正是为了避免这种后见之明偏差。[运行规格：Sol Root Cause Mining](matrixspec-root-cause-proposal-session.md)

## 整个流程是怎么做的

完整流程可以压缩成下面这张责任链：

```mermaid
flowchart TD
    A["MAIN 冻结 24-cell evidence"] --> B["Exporter 生成可追溯 Trajectory IR"]
    B --> C["Luna 逐 cell 提取行为 Pattern"]
    C --> D["Coordinator 聚合同类 Pattern"]
    D --> E["Sol 跨 run/task 推断 Harness Weakness"]
    E --> F{"用户确认 Root Cause shortlist?"}
    F -- "否" --> G["修正、否决或保留 unresolved"]
    F -- "是" --> H["生成 0..N 张单策略 Proposal Card"]
    H --> I{"用户选择 Proposal?"}
    I -- "选择" --> J["交给实施方做仓库探索和干预实验"]
    I -- "不选择" --> K["终止或重做 Proposal"]
```

这条链刻意把事实、描述、因果和干预分开。

### 1. 先冻结完整 denominator

MAIN 提供 `analysis-request.json`，冻结 `parentHarness`、`generation`、`analysisRunId`、analysis workspace、task summaries、排除项和允许引用的历史。分析角色不能自己挑“看起来更有问题”的日志，也不能用旧聊天、缓存或 dashboard 替代 evidence receipt。[运行规格：MAIN 冷启动调用合同](matrixspec-root-cause-proposal-session.md)

所有合格 `valid_behavior` cell 都进入固定 24-cell denominator，成功运行也必须作为负例和反证。这样，W-03 不能因为三个失败案例就被写成“H0 必然失败”；它只能陈述 C004、C015、C018 的支持范围，并保留 C013、C017 等不支持简单泛化的运行。[运行规格：24-cell coverage](matrixspec-root-cause-proposal-session.md)

### 2. 把原始轨迹变成可复核的 Trajectory IR

每个逻辑 cell 被按 stage、session 和 actor 切成独立 segment。IR 保存原始日志路径、行范围、frozen hash 和可逆 `sourceRef`，但只复制理解行为所需的事件。这样 Luna 可以看到真实的 message、tool call、错误、状态和 handoff，同时任何局部判断都能回到原始轨迹复核。[运行规格：Trajectory IR](matrixspec-root-cause-proposal-session.md)

这里的关键不是“把日志总结短”，而是建立一条不会丢失来源的事实层：后面的 Pattern、Weakness 和 Proposal 都是派生物，不能反过来覆盖 raw evidence。

### 3. Luna 只回答 What

Luna 对每个 cell 独立提取三类行为 Pattern：

- `omission`：存在公开 obligation 和完成机会，但预期动作、证据或状态没有出现；
- `repeated_exploration`：在外部状态没有合理变化时，又探索此前已获得信息的同一目标；
- `zero_information_gain`：动作消耗了可观察成本，却没有新增知识、改变 artifact/controller state、关闭 obligation 或产生决策所需证据。

这一层不回答根因，也不能看到一个失败结局就把此前所有动作解释成错误。重复 Review 本身不自动是 Pattern；只有 source、Controller state 和输入没有变化，而后续动作也没有产生新信息时，才可能成立。[运行规格：Luna Pattern Extraction](matrixspec-root-cause-proposal-session.md)

对 W-03，Luna 提供的是类似这样的局部事实：

```text
下游 checker 发现 upstream blocker
→ 当前角色只能写 validation.md 或 review.md
→ source artifact 与 Controller state 没有改变
→ 后续又检查同一个目标，或仅在报告中清除结论
```

它此时不能直接写“应该增加 `matspec back`”。

### 4. Coordinator 聚合，Sol 才回答 Why

Coordinator 按相同 obligation、target 或 state transition 聚合同类 Pattern，保留每次 occurrence 的独立 raw refs，并避免把一个 Controller incident 产生的重复日志算成多个独立行为事件。[运行规格：Pattern Evidence 聚合](matrixspec-root-cause-proposal-session.md)

之后，单个 Sol 一次消费完整批次、成功负例、coverage 和 outcome sidecar，必须显式完成：

1. 定位 `First Divergence`；
2. 判断 Harness attribution；
3. 说明跨 run/task 的支持范围；
4. 考虑替代解释；
5. 检查同一 Harness 下的反证；
6. 写出可证伪的反事实预测；
7. 给出 `high / medium / low` 置信度。

W-03 因而不是“三次 Review 失败”的别名，而是一条更精确的因果假设：

> Reviewer 或 Validator 已经发现 blocker 的 source 位于另一个 stage/artifact，但当前角色只能改自己的报告；Controller 既没有把责任交还给能修改 source 的 owner，也没有形成稳定 terminal。最早偏离发生在 blocker 被发现后，workflow 没有产生 source/state-changing 的下一步。

W-03 只给 `medium` 置信度，因为严格 artifact ownership 可能是有意设计，C017 在获得新 Operator 信息后完成，C013 在 source 真变化后重跑 Finalization 也产生了新信息。真正可疑的不是“再次进入同一 stage”，而是相同 blocker、source、Controller 语义状态和决策输入下的无增量重入。

### 5. 两个人工关口防止模型自动越权

Root Cause shortlist 必须先交给用户确认、修正或否决；沉默不算批准。只有确认后才能生成 Proposal。[运行规格：人工关口一](matrixspec-root-cause-proposal-session.md)

Proposal 交付后，用户可以选一张、不选或要求重做。选卡也不等于授权实施、运行实验或修改冻结 evidence。[运行规格：人工关口二](matrixspec-root-cause-proposal-session.md)

这两个关口把“模型认为值得研究”与“用户决定干预哪条因果杠杆”分开。

## Proposal Card 的生成逻辑

一张卡不是从一个错误码直接生成，而是从一个已经确认的 Weakness 生成。合法数量是 `0..N`：没有清晰策略可以输出零张；同一 Weakness 可以有多个真正不同的策略替代方案；但换 target file、prompt wording 或 patch 写法不能伪装成多张不同卡。

每张卡必须同时满足四个条件：[运行规格：Change Proposal Card](matrixspec-root-cause-proposal-session.md)

1. 证据能回溯到已确认 Weakness；
2. 只改变一个主要 Harness 策略杠杆；
3. 至少给出一个直接验证该因果杠杆的行为预测；
4. 预先写出足以否决提案的条件。

对 W-03，可以形成两个非同义的单一杠杆：

1. 改变默认 workflow topology：移除 standalone Validation，减少一次跨阶段 checker handoff；
2. 改变 Controller recovery semantics：保留 checker，把 negative verdict 变成可达 repair 或稳定 terminal。

第一张卡不宣称修复通用责任链；第二张卡不通过删除 checker 获得收益。这样的拆分让后续实验能够区分“少一个阶段”与“同一阶段获得可恢复控制面”的因果贡献。

## 原来的 W-03 是什么，现在为什么拆成两张 Proposal Card

首先要校正一个容易混淆的叫法：原来的 W-03 是一张 **Weakness Card**，不是一张已经选定措施的 Proposal Card。它描述的是一个根因假设及其证据边界；现在的 P-01、P-02 才是从这个根因派生出来的两张 **Proposal Card**。

### 原始 W-03 Weakness Card

原始卡的核心内容可以压缩为：

```text
W-03：跨阶段 blocker 没有可达修复责任链
置信度：medium
支持：C004 / C015 / C018，覆盖 3 个 task family，三者均 workflow_failed

First Divergence：
Reviewer 或 Validator 发现 blocker 位于另一个 stage/artifact；
当前角色只能修改自己的报告，不能修改 source artifact，
也没有观察到能够改变 Controller state 的返回路径。

根因假设：
H0 能识别跨阶段矛盾，却不能把问题稳定交还给可修复的责任角色，
也没有在不可达时立即形成稳定 terminal。

主要反证与边界：
严格 artifact ownership 可能是有意约束；C017 获得新的 Operator 信息后完成，
C013 在 source 真变化后重跑也产生了有效信息。因此问题不是“所有重跑”，
而是 source、Controller state 和决策输入均未变化时的重复。

可证伪预测：
发现 out-of-scope blocker 后，下一步应当修改 source artifact/state，
或者稳定结束为 blocked；如果仍对相同 digest 重跑 checker，
或只修改报告便声称矛盾消失，则继续支持该根因。
```

这张 Weakness Card 没有规定必须“删除 Validation”，也没有规定必须“增加 back”。它只冻结了一条行为断链：

```text
checker 发现 upstream blocker
→ 当前 checker 没有 source ownership
→ Controller 没有可达的责任转移
→ source/state 不变
→ 报告层假清除、无增量复审，或者 workflow failure
```

### 现在拆出的两张 Proposal Card

| 卡片 | 选择的干预位置 | 核心措施 | 能直接覆盖的证据 |
| --- | --- | --- | --- |
| P-01 / H1-inspired | 断链发生之前 | 从默认低风险 workflow 删除 standalone Validation，减少一次 downstream checker handoff | C018 的 Validation dead-end |
| P-02 / H5-inspired | 断链发生之时 | 保留 checker，把 negative verdict 变成 Controller 控制信号，并提供 back/invalidation/owner repair 或稳定 terminal | C004、C015、C018 的 Validation/Review dead-end |

二者的因果关系可以画成同一条链上的两个切入点：

```mermaid
flowchart LR
    A["upstream artifact 已确认"] --> B["downstream Validation / Review"]
    B --> C["发现 upstream blocker"]
    C --> D["checker 无 source ownership"]
    D --> E["Controller 无可达 repair route"]
    E --> F["报告层假清除 / unchanged recheck / failure"]

    P1["P-01 / H1：默认路径不设置 standalone Validation"] -. "减少 C018 进入 B 的机会" .-> B
    P2["P-02 / H5：negative verdict → back / invalidation / owner repair 或 terminal"] -. "修复 C 到 E 的责任链" .-> E
```

因此，一个根因能够对应两个措施，并不是把同一补丁拆成两张卡，而是对同一个因果模型提出两个不同的干预：

1. **减少问题面的措施**：P-01 不让默认低风险 run 经过那一次 standalone Validation handoff，从而使 C018 不再以相同结构发生。它改变的是 workflow topology。
2. **修复失效机制的措施**：P-02 接受 checker 仍会发现 upstream blocker，并让 Controller 能阻止错误确认、回退状态、交还责任或安全终止。它改变的是 recovery semantics。

这个区别也解释了为什么两张卡的覆盖范围不同。C018 的 first divergence 在 Validation，所以 P-01 可以直接命中；C004、C015 的 first divergence 在 Review，而 H1 的精简流程仍保留 Review，因此 P-01 不能宣称解决它们。P-02 处理的是 Validation 和 Review 共用的控制面断链，所以三例都属于它的直接目标。

两张卡也不能在同一个 generation 中同时启用。若同时删除 Validation 又增加 back-route，即使 C018 消失，也无法判断是因为它不再进入 Validation，还是因为责任链已经可以返修。分别实验才能回答两个不同问题：

```text
P-01：少一次独立 checker handoff，是否足以降低 validation-specific failure，且不丢 obligation？
P-02：在保留 checker 的前提下，可达 repair/terminal 是否消除了 W-03 的控制面断链？
```

## 最终 Proposal Card 是什么格式，为什么这样设计

固定 schema 由六个功能区组成：[运行规格：固定 schema](matrixspec-root-cause-proposal-session.md)

| 功能区 | 它回答的问题 | 它防止的错误 |
| --- | --- | --- |
| `proposal_id / parent_harness / source_weakness` | 这是哪一代、哪个 Weakness 的哪张候选卡？ | 脱离代际与根因来源复用卡片 |
| `evidence` | 哪些 task/run 支持，实际影响落在哪些指标？ | 先有方案再挑例子、把三个 occurrence 泛化为所有失败 |
| `root_cause` | 当前因果假设是什么，置信度多高？ | 把用户确认的研究假设写成已经证明的事实 |
| `strategy_change` | 当前策略是什么，只改变哪个主要杠杆，为什么直接命中根因？ | 把同一策略的不同文件或 patch 包装成多张卡 |
| `expected_effect` | 首先应观察到什么行为变化，哪些 Pattern 应下降，结果指标预期如何变化？ | 只许愿“质量更高”，却没有直接因果观测点 |
| `rejection_conditions / regression_risks` | 什么结果会否决提案，新策略可能制造什么新故障？ | 只看局部成功、忽略等价循环、false terminal 和回归 |

规范还明确禁止在卡中写 mechanism taxonomy、mutation family、target file、patch 或 prompt diff，也禁止在没有历史效应量和统计功效依据时编造百分比、分数差、cell 数或 tool-call 阈值。[运行规格：Proposal 约束](matrixspec-root-cause-proposal-session.md)

这种格式看起来不如一张 patch ticket 具体，但它对探索代码仓更有价值：它冻结的是必须改变的外部行为和不能破坏的不变量，而不是分析者尚未验证的实现猜测。

## 从 W-03 派生的两张 Proposal Card

下面两张卡是当前用户明确要求后新生成的候选卡，不是 `h0-root-cause-20260809-a` 当时已经落盘的正式 `proposals.yaml`。`P-01 / P-02` 是本文候选 ID；若以后写入正式 analysis run，仍需由该 run 冻结完整稳定引用。

### P-01：Default Validation Stage Compression（H1-inspired）

```yaml
proposal_id: P-01
parent_harness: H0
source_weakness: W-03

evidence:
  summary: >
    W-03 由 C004、C015、C018 三个 workflow_failed cell 支持。C018 的
    First Divergence 直接发生在 standalone Validation：Validator 识别
    upstream design/tasks 冲突，却只能写 validation.md，也没有 Controller
    back-route。C004/C015 的相同 dead-end 发生在 Review，作为本策略不能
    消除完整 W-03 的明确边界。
  affected_tasks:
    - pytest-addini-type-expressions
  affected_runs:
    - h0-pytest-addini-type-expressions-r3
  observed_impact:
    quality: >
      主要影响是 workflow/evidence validity；没有证据证明删除 Validation
      本身会提高产品质量，C004/C015 也表明 Review blocker 仍可能存在。
    completion: >
      C018 未进入 Review，最终 workflow_failed；不把 C004/C015 的
      Review failure 计为本策略的直接 affected run 或预期修复。
    cost: >
      C018 在 validation-only write scope 中产生报告改写和权限请求；
      standalone checker 也增加一次 actor、artifact、accept 和 handoff。
    stability: >
      Validation handoff 的不可达责任链可以通过不进入该独立阶段而消失，
      但直接证据只有一个 Validation occurrence，不能据此声称跨 task 稳定。

root_cause:
  hypothesis: >
    H0 的 stage-scoped ownership 允许 downstream checker 发现 upstream
    矛盾，却没有可达 repair owner 或 Controller transition，导致报告层
    假清除或对未变化 source state 的重复检查。
  confidence: medium

strategy_change:
  current_strategy: >
    默认 H0 workflow 在 implementation 前要求 standalone Validation；
    Validator 只能写 validation.md，跨阶段 blocker 因而增加一次必须由
    Controller 正确路由的 handoff。
  proposed_strategy: >
    对默认低风险 workflow 移除 standalone Validation stage，使已确认的
    upstream planning artifacts 直接进入 implementation，并继续保留独立
    Review。需要实现前独立一致性验证的任务显式选择保留 Validation 的
    Standard/Full profile。本卡不同时引入 back/revise Controller transition。
  rationale: >
    唯一主要杠杆是默认 workflow topology。它通过减少一个独立 checker
    handoff 直接避免 C018 类型的 validation-only dead-end，同时保持高风险
    profile 和 Review 可用；它不宣称修复 Review 的跨阶段责任链。

expected_effect:
  behavioral_change: >
    默认低风险 run 在 upstream planning stages 确认后直接进入
    implementation，不创建、不进入也不 accept validation.md。需要
    standalone Validation 的任务仍能通过显式 profile 获得该阶段。
  targeted_pattern_change: >
    C018 类型的 validation-report-only clearance、validation-only authority
    request 和无状态增量 Validation 重入应消失；C004/C015 的 Review pattern
    不属于本卡承诺消除的范围。
  expected_metrics:
    quality: >
      不预设上升；相同 focused tests 与 Blind Judge 下应至少没有可归因回归，
      并重点观察明确 obligation 是否只是更晚被 Review 发现。
    completion: >
      只预期 validation-specific dead-end 减少；不预设 Review failure 改善。
    cost: >
      默认路径的 Validation actor、artifact、accept 和 handoff 开销应消失，
      但不预先编造 token、tool-call 或 wall-time 降幅。
    stability: >
      默认路径少一个跨角色 transition；高风险任务的 profile routing 必须稳定。

rejection_conditions:
  - "默认流程只是把 Validation 换名或藏进另一独立 actor，产生等价 handoff。"
  - "C018 的同一 obligation 只是被推迟到 Implementation/Review 才首次发现。"
  - "删除 Validation 后出现可归因的 focused-test、Judge 或 completion 回归。"
  - "本应进入 Standard/Full 的高风险任务被错误路由到无 Validation 默认流程。"
  - "Standard/Full 不再保留其独立 Validation 能力。"
  - "实验把 C004/C015 的 Review dead-end 误报为已由本策略解决。"

regression_risks:
  - "W-02 obligation-evidence gap 加重，开放义务更晚才被 Review 具体化。"
  - "tasks/implementation handoff 承担更多一致性责任，但现有完成门不足。"
  - "Review 成为唯一独立 checker 后负载和 late-discovery 成本上升。"
  - "profile 选择规则过宽，使高风险变更失去实现前独立验证。"
```

### P-02：Reachable Cross-Stage Repair（H5-inspired）

```yaml
proposal_id: P-02
parent_harness: H0
source_weakness: W-03

evidence:
  summary: >
    C004、C015、C018 分别来自三个 task family，均为 workflow_failed。
    下游 Reviewer 或 Validator 识别了位于其他 stage/artifact 的 blocker，
    但当前角色没有可达的 source/state-changing repair path；后续出现了
    报告层假清除、对未变化 source 的复审，或无法改变 Controller 状态的请求。
  affected_tasks:
    - bat-sanitize
    - prometheus-utf8-negotiation
    - pytest-addini-type-expressions
  affected_runs:
    - h0-bat-sanitize-r1
    - h0-prometheus-utf8-negotiation-r3
    - h0-pytest-addini-type-expressions-r3
  observed_impact:
    quality: >
      主要影响是 evidence/workflow validity，而不是一种统一产品缺陷；
      部分实现检查已经通过，但跨 artifact 矛盾仍开放。
    completion: >
      三个 occurrence cell 都未完成 workflow。
    cost: >
      重复 Review、focused checks、报告改写和权限请求没有伴随 source-state 改变。
    stability: >
      相同 dead-end 形态同时出现在 Validation 和 Review，并跨越不同任务生态。

root_cause:
  hypothesis: >
    H0 可以识别跨阶段矛盾，却没有把 blocker 稳定交还给可修改 source 的
    责任角色，也没有在不可达时形成稳定 terminal，导致报告层假清除或
    对未变化 source state 的重复检查。
  confidence: medium

strategy_change:
  current_strategy: >
    Validation/Review 的负面结论主要停留在 checker 报告中；Controller
    没有把该结论绑定为阻止 accept、改变 currentStage、失效旧 confirmation
    并重新分配修复责任的语义控制信号。
  proposed_strategy: >
    将负面 verdict 的处置权交给 Controller。合法且可达时，执行持久化
    back transition，使 repair target 及其 downstream confirmation 失效，
    由 adapter 路由给目标 owner 修复、重新确认并重入 checker；目标非法、
    不可达，或同一 blocker 在相同 source、Controller state 和 decision input
    下再现时，稳定结束为 behavioral blocked failure。本卡不删除 checker；
    back 是条件能力，可以发生零次或多次，不是每个 run 的固定必经步骤。
  rationale: >
    唯一主要杠杆是跨阶段 blocker 的 Controller-owned disposition。repair
    与 terminal 是该处置的两个分支；策略不放宽严格 artifact ownership，
    也不改变任务、测试、质量标准、Judge 或正式 cell 分母。

expected_effect:
  behavioral_change: >
    形成合法 negative verdict 后，当前 checker 不再被确认；下一步要么出现
    可审计的 back/invalidation、目标 source 修改和重新确认，要么稳定终止。
    不再只改 checker 报告，也不在相同 recovery context 下重复检查。
  targeted_pattern_change: >
    C004/C015/C018 所代表的报告层假清除、unchanged re-review 和
    zero-information-gain recovery loop 应消失。
  expected_metrics:
    quality: >
      不预设 Judge 分数上升；首先保持现有质量门，并减少带开放 blocker 的假完成。
    completion: >
      只在 blocker 存在可达 owner 的 cell 中有望提高；不可达场景应更干净地失败。
    cost: >
      无 source/state 增量的 Review、Validation、权限请求和报告改写应减少。
    stability: >
      相同 blocker context 应得到确定的 repair 或 terminal 结果，而不是随机循环。

rejection_conditions:
  - "negative verdict 后当前 Validation/Review 仍被 accept。"
  - "只修改 checker 报告便声称 source blocker 已消失。"
  - "back 后 repair target 或 downstream 的旧 confirmation 仍保持有效。"
  - "source、Controller state 与 decision input 未变化时仍重复同一 checker。"
  - "旧循环只是被替换成等价的 back/review 循环。"
  - "C013/C017 类型的真实 source 变化或新 Operator 信息被误判为停滞。"
  - "本来可修复的 blocker 被过早终止，造成可归因的 completion 或质量回归。"

regression_risks:
  - "repairTarget 路由错误，导致角色越过严格 artifact ownership。"
  - "target/downstream invalidation 过宽，造成不必要的重做成本。"
  - "invalidation 过窄，保留依赖旧 artifact 的陈旧 confirmation。"
  - "blocker identity 或状态摘要不稳定，导致漏检停滞或制造 false terminal。"
  - "Arena event/completion ledger 仍按单向流程解释，无法证明最终 confirmation 有效。"
```

两张卡都没有指定 target file 或 patch。P-01 迫使 Codex 找到 workflow/profile 选择与 obligation handoff；P-02 迫使 Codex 找到 verdict、accept、back、state invalidation、owner handler 和 completion ledger。二者不能在同一代同时启用，否则无法区分收益来自阶段删除还是 repair chain。

## 卡片如何促使 Codex 探索代码仓

Codex 可以把 Proposal Card 的每个字段转换成仓库问题，而不是立即开始编辑：

| 卡片 | 仓库探索问题 | 典型搜索入口 |
| --- | --- | --- |
| P-01 `current_strategy` | 默认 workflow 为什么必须进入 Validation？ | `defaultProfile`、`profiles`、`workflow.yaml`、`validation` |
| P-01 `behavioral_change` | 删除独立阶段后由谁决定 implementation readiness，Review 是否仍保留？ | workflow stage order、handler mapping、`required_for_done` |
| P-01 `regression_risks` | 原 Validation obligation 是消失了，还是更晚才被发现？ | tasks/review inputs、focused tests、Judge、completion receipt |
| P-02 `current_strategy` | 负面结论在哪里从控制信号降格成 Markdown？ | `Decision: Approved`、`verdict`、Validation/Review handler |
| P-02 `proposed_strategy` | 谁拥有 `accept`、`currentStage`、`confirmed` 和反向 transition？ | `acceptStage`、`confirmStageInState`、`backStage`、`repairTarget` |
| P-02 `rejection_conditions` | 旧 confirmation、重复 stage event 或 false terminal 在哪里被允许或拒绝？ | `stage-accepted`、`duplicate-stage-event`、completion record |

一个最小的只读探索序列会是：

```bash
rg -n "Decision.*Approved|validation|review|accept|confirmed" \
  engine/drivers/matrixspec-evolution

rg -n "defaultProfile|profiles:|workflowProfile|key: validation" \
  workflow-packs src README.md

rg -n "STAGE_VERDICT_BLOCKED|repairTarget|backStage|backtrack" \
  src test workflow-packs

git show ed422c123a9ccdfde896ad27045a343bdd08f198 -- \
  workflow-packs/matspec/pack.yaml \
  workflow-packs/matspec/workflow.light.yaml \
  workflow-packs/matspec/workflow.standard.yaml src/workflow.js

git log --reverse --oneline -S'STAGE_VERDICT_BLOCKED' -- src test
git log --reverse --oneline -S'repairTarget' -- src test workflow-packs
git show ed422c123a9ccdfde896ad27045a343bdd08f198 -- \
  src/stage-verdict.js src/state.js src/integrations.js test/cli.test.js
```

P-01 的搜索会在 `ed422c1` 找到 profile 先例：`pack.yaml` 把 Light 设为默认，Light 删除 standalone Validation，而 Standard/Full 仍保留。需要注意，真实 `ed422c1` 还同时删除默认 `delta-design` 并捆绑 H5、metrics 等其他变化；P-01 只抽取“删除默认 standalone Validation”这一 W-03 相关杠杆，不授权整包 cherry-pick。

P-02 的第一组搜索会在当前 `matrixspec-evolution` H0 adapter 找到断链：

- Validation handler 在 artifact 生成后直接调用 `accept`，没有 Controller-owned negative disposition。evolution harness（未打包来源：`WorkArena:engine/drivers/matrixspec-evolution/harness.ps1#L546`）
- Review 只用 `Decision: Approved` 正则判断是否通过；不通过时让 Candidate 直接改 implementation，再重复 Review，但没有 MatrixSpec back/invalidation。evolution harness（未打包来源：`WorkArena:engine/drivers/matrixspec-evolution/harness.ps1#L597`）
- stage event 合同拒绝 duplicate 和 non-monotonic `stage-accepted`，因此现有 ledger 本身也无法表达 back 后重新确认同一个阶段。event contract（未打包来源：`WorkArena:engine/drivers/matrixspec-evolution/contract.ps1#L207`）

同一仓库还提供了一个有价值的 integration 参照：`matrixspec-profiled` 的 Validation loop 已经消费 `STAGE_VERDICT_BLOCKED`、读取 `repairTarget`、调用 `back --to`，并从目标文档阶段开始重新生成、确认和重入 Validation。profiled Validation loop（未打包来源：`WorkArena:engine/drivers/matrixspec-profiled/harness.ps1#L1284`） 因此，仓库探索会得到三层互补证据：

```text
matrixspec-evolution：当前 H0 adapter 的断链
MatrixSpec ed422c1：runtime recovery primitive
matrixspec-profiled：外部 adapter 消费该 primitive 的已有实例
```

这把 W-03 从“Reviewer 不够聪明”的泛泛描述，收敛成具体控制面断链：

```text
checker detection
→ report
╳ 没有 machine-readable negative control signal
╳ 没有 state-changing back
╳ 没有目标 owner re-entry
╳ ledger 不能表达 revision 后的重新确认
```

P-02 再沿 Git 历史寻找最早出现的对应机制，也会命中 `ed422c123a9ccdfde896ad27045a343bdd08f198`。同一个历史 commit 同时包含 H1 与 H5 相关能力，但两张 Proposal 仍按因果杠杆拆开。

## W-03 与 H1 是怎么对应上的

P-01 直接针对 C018：如果默认低风险 workflow 根本不进入 standalone Validation，那么 Validator 因只能写 `validation.md` 而无法修订 upstream design/tasks 的 dead-end 就不会以相同形态发生。这个对应是结构性规避，不是 recovery 修复。

它不能覆盖 C004/C015，因为两者的 blocker 出现在 Review，而 H1 Light 仍保留独立 Review。因此 P-01 的成功判据必须限于 validation-specific pattern，且必须把“同一 obligation 是否更晚才被 Implementation/Review 发现”作为 W-02 回归检查。

## W-03 与 H5 是怎么对应上的

H5 不是仓库中的原生阶段编号，而是我们对 post-H0 能力演进的分析标签。与 W-03 直接对应的是 `ed422c1` 引入的 structured semantic verdict、blocked accept 和 back transition；后续 `7290445` 的通用 stage checks 是另一层结构强化，不应和 W-03 recovery core 混成同一个因果杠杆。

### 1. Markdown verdict 变成结构化控制输入

`src/stage-verdict.js` 的 `parseStageVerdict` 对 Validation 和 Review 解析 YAML front matter：

- Validation：`allow | revise`；
- Review：`approved | changes-required`；
- blocking verdict 至少需要 blocker；
- blocking verdict 需要 `repairTarget` 或 `reviseStages`。

这命中 W-03 的第一个缺口：负面结论不再只是一段供人阅读的报告，而能被 `acceptStage` 稳定消费。

### 2. negative verdict 在确认之前 fail closed

`acceptStage` 先解析 verdict。若为 negative，它返回 `STAGE_VERDICT_BLOCKED`、blockers 和 `repairTarget`，并在 `confirmStageInState` 与 `saveState` 之前结束。只有当 target 是 workflow 中合法的 earlier stage 时，`next` 才建议执行 `matspec back`；否则仍然 fail closed，但只返回修订当前 checker artifact 的提示，原始 H5 没有 typed unreachable terminal。

因此，Validator 或 Reviewer 发现 blocker 后，当前 checker 不会被误确认成成功 handoff。这正对应 Proposal Card 的第一条行为预测和第一条否决条件。

### 3. backStage 建立可恢复的状态回退基础

`backStage` 检查 target 存在且早于当前阶段，然后：

1. 将 target 及所有 downstream stage 设为 `confirmed=false`；
2. 清除依赖旧确认的 verdict/repair metadata；
3. 把 `currentStage` 设为 `repairTarget`；
4. 记录包含 `from / to / reason / invalidated` 的 `backtrack` history；
5. 保存 state，并让下一步重新执行 `matspec go --json`。

这不是“允许 Controller 直接改早期 artifact，同时保留旧 `confirmed=true`”。它先使旧确认失效，让 workflow state 不再错误声称当前 source 已被确认，并重新开放目标阶段。`backStage` 本身不认识 `repairOwner`，真正把目标阶段路由给有写权限角色仍由外部 adapter 完成；source 与 workflow 的重新闭合，要等 owner 真正修复并重新确认后才发生。

### 4. 测试覆盖了基础状态闭环

`ed422c1` 的测试覆盖两条关键路径：

```text
Validation revise → delta-spec
→ accept blocked
→ back 到 delta-spec
→ 失效 delta-spec 及下游
→ 修复并重新确认
→ Validation allow

Review changes-required → implementation
→ accept blocked
→ back 到 implementation
→ 重新确认 implementation
→ Review approved
→ done
```

Validation case 同时覆盖了 `delta-spec.md` 的真实修改；Review case 只覆盖 back、implementation 重新确认、重新 Review 和 done，并没有修改 product code 或验证产品修复本身。因此，这些测试证明 runtime state 可以完成 recovery loop，但完整 owner repair 仍需由 adapter 和对应 handler 实现。

所以 H5 不只是“多一个 verdict 字段”，而是 recovery responsibility chain 所需的一组基础 runtime primitive：

```text
detect
→ block accept
→ identify target
→ invalidate
→ move currentStage
→ adapter-owned repair
→ reconfirm
→ recheck
```

### 5. 逐项对应

| W-03 暴露的断点 | H5 core 的对应机制 |
| --- | --- |
| 负面结论只留在 Markdown | structured verdict |
| Controller 不知道这是阻断信号 | `STAGE_VERDICT_BLOCKED` |
| checker 仍可能被确认 | blocked 分支在 confirmation 前返回 |
| 不知道应回到哪里 | `repairTarget / reviseStages` |
| 没有改变 workflow state 的路径 | `matspec back` / `backStage` |
| 旧确认继续声称有效 | target/downstream `confirmed=false` |
| 责任角色拿不到目标阶段 | `currentStage=repairTarget` 重新开放目标阶段；adapter 仍需路由给 owner |
| 缺少回退审计 | `history.action=backtrack` |
| 修复后无法重新检查 | downstream 重新确认并再次进入 checker |

这就是 W-03 与 H5 的核心对应关系：W-03 从 trajectory 说明“责任链在哪里断了”，Proposal Card 把它变成“Controller 应拥有负面 verdict 的路由”这一单一策略杠杆，H5 则提供了与该杠杆同构的已有实现原型。

## 为什么不能说 H5 已经完整解决 W-03

原始 H5 仍有重要缺口：

- parser 保留 legacy fallback，Arena 若要求稳定正式协议，还需要 structured-only adapter gate；
- blocker 可以是字符串，也可以没有稳定 ID；
- `repairTarget` 在 parser 层仍接近自由字符串，没有绑定明确 `repairOwner` 和 writable scope；
- negative verdict 本身没有持久化，只有真正执行 back 后才进入 state/history；
- accept 与 back 是两条命令，不是绑定同一 blocker receipt 的原子 transaction；
- 没有 source digest、Controller semantic state digest 或 stagnation detection；
- 没有不可达 blocker 的 typed terminal；
- 当前 `matrixspec-evolution` H0 adapter 的固定 stage-index loop 和单调 event ledger 还不能消费 back/reaccept。

因此，忠实移植 H5 应分成两层理解：

```text
H5 core：
structured verdict
→ blocked accept
→ repairTarget
→ back-time target validation
→ back/invalidation
→ repair/reconfirm/recheck

Arena 安全强化：
structured-only
→ stable blocker identity
→ source/controller/decision-input comparison
→ unreachable 或 stagnant 时 typed behavioral terminal
→ revision-aware event/completion receipt
```

后一层是为了让 H5 core 在正式 Arena 中可验证、可恢复、可终止；不能倒写成 `ed422c1` 当时已经实现了 owner、digest 或 stagnation。

## 两张卡分别能带来什么收益

P-01 最先应产生的是结构变化：默认低风险 run 不再进入 standalone Validation，C018 类型的 validation-only dead-end 与该阶段的 actor/artifact/accept/handoff 开销消失。它不承诺 C004/C015 改善，也不预设整体 completion 或质量上升；如果同一 obligation 只是更晚被 Review 发现，或者 W-02 加重，就应否决。

P-02 最先应产生的是 recovery 行为变化：negative Validation/Review 不再被错误 accept；repairable blocker 产生可审计的 back/invalidation 和 owner repair；不可达或相同 recovery context 再现时形成稳定 behavioral failure。它以 C004/C015/C018 为目标范围，但仍不能预设 completion 或 Judge 分数提高。

两张卡共同禁止用臆造百分比证明成功。P-01 看“阶段是否真的消失且义务未丢失”，P-02 看“blocker 是否真的进入 source/state-changing repair 或安全 terminal”。只有分别运行，才能判断收益来自阶段压缩还是返修控制面。

## 边界与验证

已确认的事实是：

- Root Cause & Proposal 规格明确要求 `24-cell evidence → Pattern → Weakness → 人工确认 → Proposal`，并禁止 Provider 实施或运行实验；
- 正式 run `h0-root-cause-20260809-a` 已产出 W-03 Weakness，但当时尚未生成正式 Proposal；
- 当前用户已明确要求从 W-03 生成两张候选卡；P-01 改默认 topology，P-02 改 negative-verdict recovery policy，它们不是历史 `proposals.yaml`；
- 当前 `matrixspec-evolution` H0 adapter 的 Validation/Review 控制面仍存在无 typed back-route、固定前向 stage event 的断链；
- `ed422c1` 的 Light profile 是 P-01 的历史先例，但该 commit 同时捆绑删除 `delta-design` 和其他能力，不能整包视作 P-01；
- `ed422c1` 确实引入 structured verdict、`STAGE_VERDICT_BLOCKED` 和 `backStage`，构成 W-03 所需责任链的核心原型。

尚未由现有证据证明的是：

- W-03 是三个失败 cell 的唯一根因；
- 删除 standalone Validation 必然保持 obligation coverage，或能够解决 C004/C015；
- 移植 H5 必然提高 workflow completion 或 Judge 分数；
- owner、digest、stagnation 和 typed terminal 已存在于原始 H5；
- 任何具体 target file 或 patch 仅凭 Proposal Card 就已经获得实施授权。

最小验证路径是：

1. 复核 [Root Cause & Proposal 运行规格](matrixspec-root-cause-proposal-session.md) 的 evidence、Weakness、Proposal 和人工关口合同；
2. 复核 [weakness-shortlist.json](../archive/matrixspec-evolution/analyses/H0/h0-root-cause-20260809-a/weakness-shortlist.json) 中 W-03 的 C004/C015/C018、反证和 counterfactual prediction；
3. 比较当前 Validation/Review handler（未打包来源：`WorkArena:engine/drivers/matrixspec-evolution/harness.ps1#L546`） 与 event contract（未打包来源：`WorkArena:engine/drivers/matrixspec-evolution/contract.ps1#L207`）；
4. 对 P-01 复核 `ed422c1` 的 `pack.yaml`、Light/Standard/Full workflow，并验证 Validation obligation 没有静默丢失；
5. 对 P-02 复核 `ed422c1` 的 `src/stage-verdict.js`、`src/state.js`、`src/integrations.js` 和 `test/cli.test.js`；
6. 只有在两个独立 generation、各自实验条件和 rejection conditions 冻结后，才分别判断 Proposal 是否成立。