@loomhelm/multi-task-flow 0.0.0-stage → 0.2.1

package/toolkit/skills/docs/vendor/dot-codex/specs/m3k8q-review-proof-dedupe-wait-guard/SPEC.md

@@ -0,0 +1,137 @@
+# Review proof 去重与等待语义守卫
+
+> 当前有效规范以本文为准；实现覆盖与当前状态见 `./IMPLEMENTATION.md`，关键演进原因见 `./HISTORY.md`。
+
+## 背景 / 问题陈述
+
+- session `019cf2d3-8b9f-78a0-8c0e-81b3b59d082f` 暴露出两个编排层面的真问题：
+  - 外层把 `exec_command(... tty=true)` 返回的 review `session_id` 当成 agent id 去 `wait`，直接打出 `invalid agent id 43198`；
+  - review proof 生命周期没有被统一收口，导致外层既可能在 live proof 存在时再次发起新的 `codex review`，也可能用 `sleep && codex review` 这类延迟包装重启 proof。
+- `docs/specs/review-proof-ownership/SPEC.md` 已经解决了“达到 `startup_success` 后，active review proof 不再属于共享等待预算”的 ownership 问题，但它没有把 proof identity、exec-session waiting 语义、retry/dedupe 规则做成单一共享真相源。
+- 当前相关规则分散在 `$codex-review-loop`、`$flow-continue`、`$project-engineering-workflow`、PR 短规约和 prompts 之间。partial-read 场景下，agent 很容易只读到局部规则，继续复发“错误等待语义”或“重复起 review”的问题。
+
+## 目标 / 非目标
+
+### Goals
+
+- 明确 review proof 的最小共享契约：proof identity、live-proof dedupe、exec-session waiting、restart gate、dead-session classification。
+- 禁止把 `exec_command` 返回的 review `session_id` 当成 agent id 去 `wait` / `wait_agent`。
+- 禁止在同一 live proof 仍未终态时，再次启动同义 `codex review` proof。
+- 把这套规则收敛成一份短规约，供 `$codex-review-loop`、`$flow-continue`、shared workflow 与相关 prompts 统一引用，顺手瘦身重复文案。
+- 新增 focused replay checker，至少覆盖真实 session 的等待误用，以及 synthetic live-proof duplicate launch 负例。
+
+### Non-goals
+
+- 不修改 Codex runtime 或 CLI 的底层进程管理实现。
+- 不把“主流程等待期间是否继续做别的事”单独定义为缺陷。
+- 不重写全部 flow/PR skills；只定向收紧本次事故相关的 review-proof 契约。
+
+## 范围（Scope）
+
+### In scope
+
+- 更新 `docs/specs/README.md` 与本规格。
+- 新增共享 review-proof 短规约。
+- 更新 `$codex-review-loop`、`$flow-continue`、`$project-engineering-workflow`、PR 诊断短规约与相关 prompts，使其引用同一套 review-proof 生命周期规则。
+- 新增 replay checker 与 replay fixtures / cases。
+
+### Out of scope
+
+- 修改 `gh CLI` 远端操作语义。
+- 修改 `config.toml` 或其他与本问题无关的本地配置。
+- 为所有历史 session 建立通用的大而全回放框架。
+
+## 需求（Requirements）
+
+### MUST
+
+- review proof 的共享身份必须收紧为 `proof_key = <repo_root>:<head_sha>:<base_ref>:<review_profile>`。
+- raw replay / JSONL 无法直接稳定读取 `head_sha` 时，focused checker 可以退化为更保守的可观测代理键（如 `workdir + --base + effort/profile`），但文档契约本身不能退回 branch 级粗粒度去重。
+- live proof 的最小定义必须包含：proof 已启动且尚未进入 terminal state；达到 `startup_success` 后，它还自动成为 `active review proof`。
+- shared review-proof contract 必须把 `startup_success` 绑定到“首条真正审查进展输出”；`thinking` / `exec` / findings / 最终结论都能满足该条件，但 banner/header 与 prompt 回显单独出现不能提前耗尽 init timeout / restart 语义。
+- 在 review wave 中，同一 `proof_key + wave_id + lane` 存在 live proof 时，任何入口都只能复用并轮询；不同 lane 可以并行，不得为同一 lane 再次启动新的 `codex review` proof。
+- `exec_command(... tty=true)` 返回的 review `session_id` 只能用于 exec-session 轮询（如 `write_stdin(session_id=...)`）；禁止把它送进 agent 等待接口。
+- `Unknown process id`、session missing、stdin closed、明确退出码，都必须先进入 dead-session / terminal-state classification；只有 proof 已被归类为可重启终态，才允许重启。
+- `sleep && codex review`、`nohup codex review`、外层 wrapper 托管 review 生命周期等非 direct launch 形式，必须继续判为不合格。
+- direct launch 即使请求了 `--sandbox read-only`，runtime sandbox 真相也必须来自 proof banner / 会话输出，而不是命令字面值本身。
+- `$codex-review-loop`、`$flow-continue`、shared workflow、相关 prompts 不得各自复制一大段 review-proof 生命周期正文；应引用单一短规约，只保留入口独有职责。
+
+### SHOULD
+
+- 相关入口文件前 100-150 行就能看到“exec session 不是 agent”“live proof 不得重开”的关键 guardrail。
+- focused checker 输出应给出具体行号与最小证据，便于把真实 session 当回归样例长期保留。
+
+## 功能与行为规格（Functional/Behavior Spec）
+
+### Shared review-proof contract
+
+- 共享短规约只承担五类判断：
+  - proof identity / live-proof dedupe
+  - direct launch / exec-session waiting 语义
+  - `startup_success` 之后的 ownership
+  - restart gate / dead-session classification
+  - stale-proof 与 freshness/base 变化后的处理
+- `startup_success` 的共享判据必须只接受真正审查进展输出；banner/preamble 与 prompt 回显都不能被视为“成功启动”，但它们也不能被误当成真实审查内容本身。
+- shared PR diagnosis contract 继续拥有 PR freshness / approval / wait-state / convergence drag blocker 诊断，但 active review proof 的生命周期细节改为引用新的 review-proof contract。
+
+### Thin entry skills / prompts
+
+- `$codex-review-loop`
+  - 负责 proof 的启动、findings 收敛、输出字段与当前 invocation 的修复循环。
+  - proof identity、exec-session wait 语义、restart gate、禁止 deferred launch 的规则统一引用共享短规约。
+- `$flow-continue`
+  - 负责恢复顺序与路由。
+  - 一旦恢复出的当前 gate 是 live review proof，只能 relay / poll；不得 route 成 agent wait，也不得因为 generic continue 再次拉起同义 proof。
+- shared workflow / prompts
+  - 只保留“何时需要 proof”“proof 对 merge / local-merge 的门禁意义”，不再自己重写 lifecycle。
+
+### Focused replay checker
+
+- checker 读取 replay JSONL，至少提取：
+  - review `exec_command` 启动参数与 `tty=true`
+  - `Process running with session ID <n>` 这类 exec-session 证据
+  - `wait` / `wait_agent` / `write_stdin` 的调用目标
+  - 非 direct launch（如 `sleep && codex review`）
+  - live proof 尚未终态时的 duplicate launch
+- checker 必须至少支持以下 finding：
+  - `EXEC_SESSION_WAIT_MISUSE`
+  - `NON_DIRECT_REVIEW_LAUNCH`
+  - `DUPLICATE_LIVE_REVIEW_LAUNCH`
+
+## 验收标准（Acceptance Criteria）
+
+- Given session `019cf2d3-8b9f-78a0-8c0e-81b3b59d082f` When 跑 focused replay checker Then 必须至少报出 `EXEC_SESSION_WAIT_MISUSE`。
+
+- Given session `019cf2d3-8b9f-78a0-8c0e-81b3b59d082f` When 跑 focused replay checker Then 应额外报出 `NON_DIRECT_REVIEW_LAUNCH`，因为存在 `sleep && codex review` 式 deferred launch。
+
+- Given replay 中已有一个 live review proof 尚未终态 When assistant 再次启动同义 `codex review` Then checker 必须报 `DUPLICATE_LIVE_REVIEW_LAUNCH`。
+
+- Given replay 中只有单个 review proof 被正常轮询并明确退出 When 跑 checker Then 不得误报 duplicate launch 或 wait misuse。
+
+- Given `$codex-review-loop`、`$flow-continue`、shared workflow、相关 prompts 的顶部片段 When 只读前 100-150 行 Then 应能看到共享 review-proof contract 引用、`exec session != agent`、以及 live proof 不得重开的关键约束。
+
+## 非功能性验收 / 质量门槛（Quality Gates）
+
+### Testing
+
+- `python3 -m py_compile bin/review_proof_replay_check.py`
+- `python3 bin/review_proof_replay_check.py --cases docs/specs/review-proof-dedupe-wait-guard/replay/cases.txt`
+- `git diff --check`
+
+### Quality checks
+
+- 目标 skill / prompt 的前 150 行人工 spot-check
+- 重复规则 grep：确认 review-proof 生命周期规则已集中到共享短规约
+
+## 风险 / 假设
+
+- 风险：若未来新增新的 review-proof 入口但不引用共享短规约，partial-read 漂移仍可能复发。
+- 风险：focused checker 只看到 JSONL 中可观测事实，因此 duplicate launch 的自动判定采用保守代理键；这适合回归守卫，但不是 runtime 级唯一真相源。
+- 假设：当前最值得防回归的是真实 session 的等待误用和 deferred launch，再配一个 synthetic duplicate-live case 即可覆盖这次事故族。
+
+## 参考（References）
+
+- Session `019cf2d3-8b9f-78a0-8c0e-81b3b59d082f`
+- `docs/specs/review-proof-ownership/SPEC.md`
+- `docs/specs/pr-skill-diagnosis-thinning/SPEC.md`
+- `skills/project-engineering-workflow/references/pr-diagnosis-short-contract.md`

package/toolkit/skills/docs/vendor/dot-codex/specs/m3k8q-review-proof-dedupe-wait-guard/replay/cases.txt

@@ -0,0 +1,5 @@
+# status path expected_code
+fail ../../../../sessions/2026/03/16/rollout-2026-03-16T02-47-56-019cf2d3-8b9f-78a0-8c0e-81b3b59d082f.jsonl EXEC_SESSION_WAIT_MISUSE
+fail ../../../../sessions/2026/03/16/rollout-2026-03-16T02-47-56-019cf2d3-8b9f-78a0-8c0e-81b3b59d082f.jsonl NON_DIRECT_REVIEW_LAUNCH
+fail negative-live-proof-duplicate-launch.jsonl DUPLICATE_LIVE_REVIEW_LAUNCH
+pass positive-single-proof-polling.jsonl -

package/toolkit/skills/docs/vendor/dot-codex/specs/m3k8q-review-proof-dedupe-wait-guard/replay/negative-live-proof-duplicate-launch.jsonl

@@ -0,0 +1,4 @@
+{"type":"response_item","payload":{"type":"function_call","name":"exec_command","arguments":"{\"cmd\":\"codex -m gpt-5.4 -c model_reasoning_effort=\\\"high\\\" --sandbox read-only -a never review --base origin/main\",\"workdir\":\"/tmp/demo\",\"tty\":true}","call_id":"call_launch_1"}}
+{"type":"response_item","payload":{"type":"function_call_output","call_id":"call_launch_1","output":"Command: /bin/zsh -lc 'codex -m gpt-5.4 -c model_reasoning_effort=\"high\" --sandbox read-only -a never review --base origin/main'\nChunk ID: a1\nWall time: 1.0000 seconds\nProcess running with session ID 101\nOriginal token count: 0\nOutput:\nOpenAI Codex v0.x\n"}}
+{"type":"response_item","payload":{"type":"function_call","name":"exec_command","arguments":"{\"cmd\":\"codex -m gpt-5.4 -c model_reasoning_effort=\\\"high\\\" --sandbox read-only -a never review --base origin/main\",\"workdir\":\"/tmp/demo\",\"tty\":true}","call_id":"call_launch_2"}}
+{"type":"response_item","payload":{"type":"function_call_output","call_id":"call_launch_2","output":"Command: /bin/zsh -lc 'codex -m gpt-5.4 -c model_reasoning_effort=\"high\" --sandbox read-only -a never review --base origin/main'\nChunk ID: a2\nWall time: 1.0000 seconds\nProcess running with session ID 102\nOriginal token count: 0\nOutput:\nOpenAI Codex v0.x\n"}}

package/toolkit/skills/docs/vendor/dot-codex/specs/m3k8q-review-proof-dedupe-wait-guard/replay/positive-single-proof-polling.jsonl

@@ -0,0 +1,6 @@
+{"type":"response_item","payload":{"type":"function_call","name":"exec_command","arguments":"{\"cmd\":\"codex -m gpt-5.4 -c model_reasoning_effort=\\\"high\\\" --sandbox read-only -a never review --base origin/main\",\"workdir\":\"/tmp/demo\",\"tty\":true}","call_id":"call_launch_ok"}}
+{"type":"response_item","payload":{"type":"function_call_output","call_id":"call_launch_ok","output":"Command: /bin/zsh -lc 'codex -m gpt-5.4 -c model_reasoning_effort=\"high\" --sandbox read-only -a never review --base origin/main'\nChunk ID: b1\nWall time: 1.0000 seconds\nProcess running with session ID 201\nOriginal token count: 0\nOutput:\nOpenAI Codex v0.x\n"}}
+{"type":"response_item","payload":{"type":"function_call","name":"write_stdin","arguments":"{\"session_id\":201,\"chars\":\"\",\"yield_time_ms\":1000}","call_id":"call_poll_1"}}
+{"type":"response_item","payload":{"type":"function_call_output","call_id":"call_poll_1","output":"Chunk ID: b2\nWall time: 1.0000 seconds\nProcess running with session ID 201\nOriginal token count: 0\nOutput:\nthinking\n"}}
+{"type":"response_item","payload":{"type":"function_call","name":"write_stdin","arguments":"{\"session_id\":201,\"chars\":\"\",\"yield_time_ms\":1000}","call_id":"call_poll_2"}}
+{"type":"response_item","payload":{"type":"function_call_output","call_id":"call_poll_2","output":"Chunk ID: b3\nWall time: 1.0000 seconds\nProcess exited with code 0\nOriginal token count: 0\nOutput:\nno findings\n"}}

package/toolkit/skills/docs/vendor/dot-codex/specs/mainline-baseline-topic-branch-freshness/HISTORY.md

@@ -0,0 +1,15 @@
+# Mainline baseline and topic branch freshness contract 演进历史（#7uqp8）
+
+> 这里记录关键演进原因；规范正文仍以 `./SPEC.md` 为准。
+
+## Decision Trace
+
+- 新建 `#7uqp8`，因为“显式 `$dev-plan` 的具体开发基线输出合同”与“shared workflow 的 topic branch freshness 准备”跨越了 planner 与 execution 两个层面，不能继续挤在 `#5dvcj` 或 `#w7yqp` 的边角里。
+- 默认策略改用“目标仓库主干基线”而不是硬编码 `origin/main` 作为长期语义；但 owner-facing 最终计划值必须仍然落成具体 ref，不能把抽象策略词直接冒充最终答案。
+- Step 1 被重新定义为“建立正确且新鲜的 topic-branch 执行上下文”，而不是单纯检查“当前是不是在 topic branch”。
+
+## References
+
+- `./SPEC.md`
+- `./IMPLEMENTATION.md`
+- Legacy compatibility identity: `#7uqp8`.

package/toolkit/skills/docs/vendor/dot-codex/specs/mainline-baseline-topic-branch-freshness/IMPLEMENTATION.md

@@ -0,0 +1,68 @@
+# Mainline baseline and topic branch freshness contract 实现状态
+
+> 当前有效规范仍以 `./SPEC.md` 为准；这里记录实现覆盖、交付进度与 rollout 相关事实。
+
+## Current Status
+
+- Implementation: 已实现
+- Lifecycle: active
+- Catalog note: 规格已建立，等待 skill / checker / replay / solution 全量收敛
+
+## Coverage / rollout summary
+
+- 已创建独立 topic spec，明确这次规则不再硬塞进 `docs/specs/dev-plan-default-fast-track-auto-lock/SPEC.md` 或 `docs/specs/git-skill-convergence/SPEC.md`。
+- `AGENTS.md` 已补齐 owner-facing current truth：
+  - 显式 `$dev-plan` 必须输出具体 `开发基线`
+  - shared workflow 的“无 topic branch 自动建 / 已有 topic branch Step 1 预同步 / Step 4 再复核”合同
+- `skills/dev-plan/SKILL.md` 已新增 `开发基线` 必填约束、默认解析规则与 skeleton 示例。
+- `skills/project-engineering-workflow/SKILL.md` 已把 Step 1 改成“建立正确且新鲜的 topic-branch 执行上下文”，并补了 Step 1 预同步与 Step 4 二次复核的口径。
+- `skills/git-branch/SKILL.md`、`skills/git-sync/SKILL.md`、`skills/fast-flow/SKILL.md` 已完成最小依赖文案对齐。
+- `bin/plan_contract_check.ts` 已新增：
+  - 缺失 `开发基线` 的拦截
+  - 抽象主干词作为最终值的拦截
+  - 主人显式 baseline 与计划最终值不一致的拦截
+- checker 的 planning-session reset 逻辑已收紧：
+  - 已锁定计划中的 standalone flow restatement 不再清空主人显式 baseline
+  - 普通 scope clarification 里的产品词组（如 `new plan file upload API`）不再误判成新的独立计划请求
+- checker 的 owner baseline 抽取已补足自然语言显式基线：
+  - ``基于 \``...\` 开发``/``from ...` 这类 directional wording 会被识别为主人显式 baseline
+  - `请把导入页面也规划进去，其他不变` 这类 scope clarification 不再误清当前 planning session
+- checker 的 baseline / session 误报边界已继续收紧：
+  - `BASE_REF=...` 形式现在也会被识别为主人显式 baseline
+  - bare `base=...` / `base:...` 形式现在也会被识别为主人显式 baseline
+  - ``branch protection``、``use \``main.ts\` as the parser reference` 这类普通产品/文件短语不再被误抽成 baseline
+  - `plan.md` / `planning UI` 这类 scope clarification 不再因为包含 `plan` 词根而误触发新 planning session reset
+  - `开发基线用 upstream/release-2026q3` 这类中文简写现在也会被识别为主人显式 baseline，不再漏掉 mismatch
+  - owner baseline 比较会接受 `origin/main` 与 `refs/remotes/origin/main` 这类等价 remote ref 表达
+  - `开发基线从 A 改为 B` / `开发基线改为 B` 这类 replace clause 现在会以新的显式 baseline 为准，不再错误沿用被替换掉的旧值
+  - `请重新规划这个任务` 这类 verb-form re-plan 请求现在会正确打开新的 planning window，不再把上一轮显式 baseline 泄漏到下一轮计划
+  - `重新规划这个任务，收口改为 merge-ready` 这类同时带 re-plan 与 continuation 词的请求，现在会优先按新的 planning window 处理，而不是被 continuation 词提前截走
+  - `请帮我规划这个任务：...` 这类 plain-language 新计划请求现在会正确打开新的 planning window，不再被上一轮 flow/baseline 污染
+  - `请用 $dev-plan 给我一份 merge queue API 的计划` 这类任务名含 `merge` 词根的新请求，不再被误当成 continuation
+  - `开发基线使用 qa`、`base=rc` 这类 1-2 字符的 plain short ref baseline，现在也会被识别成主人显式 baseline，不再漏掉 mismatch
+  - plain baseline 末尾如果是 Git 允许的 `,` / `;` 这类合法字符，现在会原样保留；只有真正的 continuation 子句（如 `, 并继续`）才会被裁掉
+  - `基于 new plan file upload API 规划这个任务` 这类 directional 产品词组，不再被误抽成 owner baseline；plain directional baseline 只有在值显式带 `branch/ref/commit` 限定词，或本身长得像真实 ref/commit 时才会进入比较
+  - ``基于 \``docs/specs/.../SPEC.md\` 规划这个任务``这类 backtick 包裹的 spec/doc 输入，不再被 plain directional baseline 分支误抽成 owner baseline；需要显式``开发基线...``/``BASE_REF=...``/``基于 ... 开发` 这类更强 Git 语义才会锁定 baseline
+  - `请按 normal 把计划页面上传 API 也规划进去，flow 和开发基线都不变` 这类 scope clarification，不再因为产品词里的 `计划` 两字误触发新的 planning window reset
+  - 合法 git ref 即使包含 `default` / `mainline` / `todo` 等词根，也不会再被 placeholder / abstract-baseline 规则误伤
+  - `目标仓库主干基线` / `远程主干基线` 这类组合抽象词组，现在会继续被视为抽象默认策略词，而不是被误当成合法 ref
+  - `origin/HEAD` / `upstream/HEAD` 这类常见 bare remote symbolic HEAD alias，以及 `refs/remotes/origin/HEAD` 这类 fully-qualified remote HEAD alias，现在都会被稳定拒绝，不再依赖 checker 当前仓库里恰好存在同名 remote
+  - 合法 branch ref 即使最后一个 path component 恰好是 `HEAD`（如 `feature/HEAD`），也不会再被 remote symbolic HEAD alias 规则误伤
+  - `bin/plan_contract_check.ts` 已去掉会依赖临时写盘的 here-string 输入路径，使 fresh review proof 在 read-only sandbox 下也能直接执行 checker，而不会因为 shell 临时文件失败而误报 `NO_PROPOSED_PLAN`
+- review proof 暴露的后续边界问题也已补齐：
+  - `topic/foo`、`feature/todo-cleanup` 这类 ref 内部包含 `to` 词根的合法 branch baseline，不会再被 replace-clause regex 截断成尾巴
+  - 在 `request_user_input(flow_type)` 之后，`请按 normal 继续出计划` 这类自然语言 flow 回答不再清空先前显式 baseline
+  - 显式 `$dev-plan` 新请求现在会先于 continuation heuristics 判定；像 `请用 $dev-plan 继续给我一份新的可执行计划` 这类同句带 `继续` 的 fresh request，也会正确打开新的 planning window
+  - `todo` / `default` / `pending` 这类与 placeholder 词根重合但本身是合法 git ref 的 baseline，现在会优先按 concrete ref 接受；真正的 `TBD` 类占位词仍然拒绝
+  - `feature/README.md` 这类“看起来像文档路径”但语法上合法的 git ref baseline，现在也会按 concrete ref 保留；只有真正的文件系统路径（如 `./docs/specs/foo/SPEC.md`）仍会被拒绝
+- replay fixtures / `CASES.txt` 已补齐默认主干 concrete ref、显式 branch、显式 commit、缺失基线、抽象基线、忽略主人 baseline、standalone flow restatement、directional 产品词误报与 scope clarification false-positive 的 focused coverage，并已通过全套回放。
+- `docs/solutions/workflow-issues/git-skill-convergence.md` 已刷新 reusable guidance。
+
+## Remaining Gaps
+
+- None currently tracked after local validation.
+
+## References
+
+- `./SPEC.md`
+- `./HISTORY.md`

package/toolkit/skills/docs/vendor/dot-codex/specs/mainline-baseline-topic-branch-freshness/SPEC.md

@@ -0,0 +1,166 @@
+# Mainline baseline and topic branch freshness contract
+
+> 当前有效规范以本文为准；实现覆盖与当前状态见 `./IMPLEMENTATION.md`，关键演进原因见 `./HISTORY.md`。
+
+## 背景 / 问题陈述
+
+- repo 现有合同已经分别覆盖了显式 `$dev-plan` 的 flow lock（如 `docs/specs/dev-plan-default-fast-track-auto-lock/SPEC.md`）与 canonical git skill surface（如 `docs/specs/git-skill-convergence/SPEC.md`），但还没有一个长期主题专门定义“开发基线默认值”和“topic branch 新鲜度”的统一真相。
+- 结果是三层语义可能分裂：运行时文案说“默认按主干”，计划输出里却可能只写抽象词，实际执行又可能继续停留在 detached HEAD、默认分支，或已经过时的 topic branch 上。
+- 主人要求默认按“目标仓库主干基线”推进；若主人显式指定了 branch 或 commit，就必须原样尊重；若没有指定，则只有非常强的 Git 事实才应触发“也许不是主干”的确认。
+- 这条规则既涉及显式 `$dev-plan` 的 owner-facing 合同，也涉及 shared workflow 在 Step 1/Step 4 如何准备并维持一个正确且不过时的开发上下文，因此需要独立 topic spec 统一收敛。
+
+## 目标 / 非目标
+
+### Goals
+
+- 为显式 `$dev-plan` 新增“具体开发基线”合同：`Flow Decision` 必须写出 concrete branch 或 commit，不能只停留在“远程主干”“目标仓库主干”之类抽象表述。
+- 固化默认基线决策：主人显式给 branch/commit 时原样保留；主人未指定时，默认解析为目标仓库主干的具体 ref，并优先输出 branch，只有 branch 不可用或主人明确给 commit 时才输出 commit SHA。
+- 把计划阶段的非主干确认触发器收紧到两类强 Git 事实：唯一 open PR base，或显式 upstream 集成分支；除此之外默认按目标仓库主干基线规划。
+- 把 shared workflow 的 Step 1 改成“先拿到正确且新鲜的执行上下文”：
+  - 没有 topic branch 时，基于已解析基线通过 `$git-branch` 自动创建 topic branch；
+  - 已有 topic branch 时，进入 spec/实现前先做一次 `$git-sync` 预同步；
+  - Step 4 继续按既有 confirmed-base gate 复核并必要时再次同步。
+- 保持 planner 合同、运行时文案、checker、replay fixtures 与 reusable solution 同口径，避免同一条规则在不同入口说法不同。
+
+### Non-goals
+
+- 不把 Step 4 的 factual `BASE_REF` 解析硬编码成永远优先 `origin/main`；release 分支、open PR base、upstream 集成分支等既有强事实优先级仍然保留。
+- 不把“计划里必须声明开发基线”扩展到未显式 `$dev-plan` 的普通规划回复。
+- 不引入新的 branch naming policy，也不修改 remote URL、upstream、push 目标、认证或传输配置。
+- 不为这次规则调整新增 workflow glossary 或 ADR；长期真相继续放在 spec、solution 与 active workflow docs。
+
+## 范围（Scope）
+
+### In scope
+
+- `docs/specs/README.md`
+- `docs/specs/mainline-baseline-topic-branch-freshness/*`
+- `AGENTS.md`
+- `skills/dev-plan/SKILL.md`
+- `skills/project-engineering-workflow/SKILL.md`
+- `skills/fast-flow/SKILL.md`
+- `skills/git-branch/SKILL.md`
+- `skills/git-sync/SKILL.md`
+- `bin/plan_contract_check.ts`
+- `skills/dev-plan/references/replay-cases/*`
+- `docs/solutions/workflow-issues/git-skill-convergence.md`
+
+### Out of scope
+
+- `normal` / `fast-track` / `local-merge` 的业务终点语义重写
+- GitHub PR merge/runtime 逻辑
+- remote/auth/transport 配置变更
+- `CONTEXT.md` 或 browser-only 术语扩写
+
+## 需求（Requirements）
+
+### MUST
+
+- 显式 `$dev-plan` 产出的每个 `<proposed_plan>` 都必须在 `Flow Decision` 中声明 `开发基线`，且最终值只能是具体 branch/ref 或 commit SHA。
+- `开发基线` 不得只写抽象默认策略词，例如“远程主干”“目标仓库主干”“主干基线”；若需要表达默认策略，可在说明文字中出现，但最终值必须落到具体 ref。
+- 当主人显式指定 branch 或 commit 作为 base 时，计划输出必须原样保留该事实，不能被默认主干 ref 覆盖。
+- 当主人未显式指定 base 时，计划阶段只允许以下两类强 Git 事实触发“可能不是主干基线”的确认：
+  - 当前 topic branch 关联的唯一 open PR base；
+  - 明确指向非 topic 集成分支的 upstream。
+- 除上述两类强事实外，显式 `$dev-plan` 默认按目标仓库主干基线规划，并在最终计划中输出解析后的具体 ref。
+- shared workflow 的 Step 1 必须支持两条路径：
+  - 若当前没有 topic branch，且工作区状态允许安全切换，则先解析开发基线，再通过 `$git-branch` 从该基线创建 topic branch；
+  - 若当前已经在 topic branch 上，则在进入 Step 2 前先完成一次 `$git-sync` 预同步。
+- shared workflow 的 Step 1 若处于 detached HEAD、默认分支或其他“需要移动当前工作副本”的场景，而工作区又存在 dirty/歧义风险，仍必须阻断并只问 1 个关键问题。
+- shared workflow 的 Step 4 必须继续执行既有 confirmed-base gate，并明确它是对 Step 1 上下文准备结果的第二次复核；若 branch 在 Step 1 已同步但到 Step 4 又落后，仍需再次 `$git-sync`。
+- `git-branch` 必须允许调用方把“已解析开发基线”作为 `BASE_REF` 传入，用于从正确 ref 建立 topic branch，而不是默认假设 detached `HEAD` 就是正确起点。
+- `git-sync` 必须明确：shared workflow 的 Step 1 topic-branch 预同步，与 Step 4 confirmed-base 同步一样，都属于可复用的“confirmed base sync”路径；Step 1 只是更早执行，不代表可以跳过 Step 4 复核。
+- `AGENTS.md`、`skills/dev-plan/SKILL.md`、`skills/project-engineering-workflow/SKILL.md`、相关 flow/git skills、`bin/plan_contract_check.ts` 与 replay fixtures 必须表达同一条规则。
+
+### SHOULD
+
+- owner-facing 文案可以使用“目标仓库主干基线”描述默认策略，但要同时清楚区分：这只是默认决策规则，不是最终 `开发基线` 字段允许输出的抽象值。
+- 新的 replay fixtures 应同时覆盖 branch 与 commit 两类正例，避免后续 checker 只偏向某一种 ref 形态。
+
+## 功能与行为规格（Functional/Behavior Spec）
+
+### 显式 `$dev-plan` 的开发基线合同
+
+- `Flow Decision` 固定字段仍包含 `flow_type`、`flow_source`、`lock_status`；在此基础上新增 owner-facing 必填行：`开发基线`。
+- `开发基线` 的允许值：
+  - fully-qualified remote branch/ref，例如 `origin/main`、`upstream/release/2026-q3`
+  - local branch/ref，仅当主人显式指定或当前上下文明确要求保留该本地 ref
+  - full commit SHA
+- `开发基线` 的禁止值：
+  - 纯抽象策略词，如“远程主干”“目标仓库主干”“默认主干”“mainline baseline”
+  - 缺失值、空值、`TBD`/`待确认`
+- 解析优先级固定为：
+  1. 主人显式给出的 base branch / commit
+  2. 唯一 open PR base
+  3. 显式 upstream 集成分支
+  4. 目标仓库主干基线的具体 ref
+- 当解析结果同时存在“默认主干策略说明”和“具体 ref”时，owner-facing 计划的最终值只写具体 ref；策略说明可以出现在 Summary / Assumptions 中，但不能替代最终值。
+
+### shared workflow 的 topic branch / freshness 合同
+
+- Step 1 的目标不再只是“确认当前就在 topic branch 上”，而是“让当前 run 在进入 spec / 实现前拿到一个安全、正确、不过时的 topic-branch 执行上下文”。
+- 若当前没有 topic branch：
+  - clean 且无风险时，先解析开发基线，再调用 `$git-branch ACTION=create-topic BASE_REF=<resolved-base>` 建立 topic branch；
+  - dirty 或存在切换风险时，阻断并只问 1 个关键问题。
+- 若当前已在 topic branch：
+  - Step 1 先解析一个 provisional-to-confirmed 的开发基线；
+  - 若该基线已经足够确认，则通过 `$git-sync` 先做一次预同步；
+  - 若连 Step 1 都无法唯一确认真实 base，则阻断并只问 1 个关键问题，而不是带着旧 branch 继续实现。
+- Step 4 仍然是 `可开 PR（local）` 的 confirmed-base gate：
+  - 它必须重新 fetch / 复核 canonical `BASE_REF`；
+  - 若 branch 相对该 `BASE_REF` 再次落后，必须再次 `$git-sync`；
+  - Step 1 的预同步永远不能被当作 Step 4 已完成的替代证据。
+
+## 验收标准（Acceptance Criteria）
+
+- Given 显式 `$dev-plan` 计划里缺少 `开发基线` When `bin/plan_contract_check.ts` 检查该回放 Then 必须报出缺失开发基线的 finding。
+
+- Given 显式 `$dev-plan` 计划把 `开发基线` 写成“目标仓库主干”或“远程主干” When checker 检查该回放 Then 必须报出抽象开发基线不合法的 finding。
+
+- Given 主人没有显式指定 base，且仓库没有 open PR base / 显式 upstream 集成分支 When agent 产出显式 `$dev-plan` Then 最终计划应按目标仓库主干基线解析为具体 ref，而不是只写抽象词。
+
+- Given 主人显式给出 branch 或 commit When agent 产出显式 `$dev-plan` Then `开发基线` 必须原样保留该 branch 或 commit。
+
+- Given 当前 run 处于 detached/default branch 且没有 topic branch，工作区干净 When shared workflow 进入 Step 1 Then 它必须先解析正确 base，再通过 `$git-branch` 从该 base 创建 topic branch，而不是直接阻断。
+
+- Given 当前 run 已在 topic branch 上 When shared workflow 进入 Step 1 然后 Step 4 Then Step 1 必须先做一次 `$git-sync` 预同步，Step 4 仍必须继续 confirmed-base 复核并在需要时再次同步。
+
+- Given 当前 run 处于 detached/default branch 或需要移动当前工作副本，但工作区 dirty 或存在歧义风险 When shared workflow 进入 Step 1 Then 它仍然必须阻断并只问 1 个关键问题，而不是静默建分支或静默切换。
+
+## 验收清单（Acceptance checklist）
+
+- [x] 显式 `$dev-plan` 的 `开发基线` 合同已写清楚并落到 checker。
+- [x] 默认主干策略与最终具体 ref 输出的区别已写清楚。
+- [x] shared Step 1 自动建 branch / Step 1 预同步 / Step 4 再复核的双阶段 freshness 合同已写清楚。
+- [x] dirty / detached/default-branch 风险场景仍保持单问题阻断。
+- [x] replay fixtures 覆盖无显式 base、显式 branch、显式 commit、缺失基线、抽象基线五类场景。
+- [x] reusable solution 与 owner-facing current truth 已同步。
+
+## 非功能性验收 / 质量门槛（Quality Gates）
+
+### Testing
+
+- `bun run bin/plan_contract_check.ts --cases skills/dev-plan/references/replay-cases/CASES.txt`
+- `git diff --check`
+- active runtime grep：确认 `AGENTS.md`、`skills/dev-plan/SKILL.md`、`skills/project-engineering-workflow/SKILL.md`、`skills/git-branch/SKILL.md`、`skills/git-sync/SKILL.md`、`skills/fast-flow/SKILL.md` 对该规则的说法一致
+
+### Quality checks
+
+- spot-check `Flow Decision` 示例，确认最终值只写具体 branch/commit
+- spot-check Step 1/Step 4 文字，确认双阶段 sync 没被写成一次性 shortcut
+
+## 风险 / 开放问题 / 假设（Risks, Open Questions, Assumptions）
+
+- 风险：如果只收紧 `dev-plan` checker、不修改 shared workflow，agent 仍可能在 stale branch 上继续实现，导致“计划写对了，执行上下文还是错的”。
+- 风险：如果把“目标仓库主干基线”误写成永远等于 `origin/main`，会破坏 release / upstream / PR base 等既有强事实优先级。
+- 假设：显式 `$dev-plan` 的 owner-facing 合同允许新增 1 条中文固定行 `开发基线`，而不需要再引入新的英文字段 schema。
+
+## 参考（References）
+
+- `docs/specs/dev-plan-default-fast-track-auto-lock/SPEC.md`
+- `docs/specs/git-skill-convergence/SPEC.md`
+- `skills/dev-plan/SKILL.md`
+- `skills/project-engineering-workflow/SKILL.md`
+- `skills/git-branch/SKILL.md`
+- `skills/git-sync/SKILL.md`
+- `bin/plan_contract_check.ts`

package/toolkit/skills/docs/vendor/dot-codex/specs/mandatory-local-review-proof/HISTORY.md

@@ -0,0 +1,17 @@
+# History
+
+- Target advancement is separated from adopting a new review base: running review/CI rounds finish against their bound identity, then the parent handles accumulated drift. New-base adoption retains full fresh coverage; child reviewers report only, sharing the parent's repair count.
+- Readiness requires executed evidence for changed critical boundaries. Placement and repair accounting are consolidated in the workflow and review-proof owners, without a task-specific boundary checklist or review ledger.
+- Mandatory direct review evolved from universal proof to Agent-assessed tiers.
+- Direct review evidence replaces receipt-led review orchestration so current diff review, validation, CI, and GitHub facts remain independently useful.
+- Formal review moved behind a Review Readiness gate with runtime fresh launch; plans now express policy and profile recommendations rather than named reviewers. Repair refresh is delta-based with full refresh for uncertain, shared-contract, high-risk, or base-drift changes.
+- Base-drift refresh now requires and records the observed replacement base SHA before accepting refreshed lane results.
+- Readiness vocabulary and direct-plan fields now enforce the complete gate; terminal replay records require clear structured evidence and local-merge shares the same readiness prerequisite. Scope, actual profile, and unknown evidence fields now fail closed, and base-drift requires a changed base SHA.
+- Direct-plan validation now rejects vague Tier 3/4 strategy/profile wording: the strategy must express runtime formal-lane creation or launch, and the recommendation must name a concrete supported model and effort pair.
+- Review replay now fails closed on unknown disposition tokens instead of treating malformed evidence as report-only or repairable.
+- Review replay now also requires explicit readiness evidence for launch and a demonstrated finding before an In-Scope repair can mutate the candidate.
+- Structured review evidence now fails closed for unsupported actual profiles and unknown embedded finding dispositions.
+- Repair replay now rejects observation-only evidence for an In-Scope batch, and direct formal policy fields cannot be duplicated ambiguously.
+- Malformed or missing structured finding kinds now fail closed before terminal evidence is recorded.
+- Terminal clear evidence may contain a blocking finding; `unchecked` is reserved for missing, stale, malformed, or unavailable review output.
+- Repair eligibility now uses a priority-aware threshold: an initial-wave P2-only finding may be repaired optionally, later P2 repair requires a P0/P1 or qualifying current-Candidate CI trigger, and P2/P3-only results may clear with a recorded low-priority resolution and next-stop owner report.

package/toolkit/skills/docs/vendor/dot-codex/specs/mandatory-local-review-proof/IMPLEMENTATION.md

@@ -0,0 +1,31 @@
+# Implementation
+
+- Shared Late PR resolution preserves repair eligibility and the three canonical dispositions when a concrete deferral is considered after a completed review boundary. Main-Agent evidence distinguishes current-PR repairs from authorized follow-up handoffs without changing reviewer schemas. Batch counts support diagnosis and continuation without limiting authorized in-scope repairs.
+
+- Formal review is routed by the shared delivery contracts and flow consumers. Readiness, wait, classification, pre-write accounting, and verification therefore have one convergence path without a standalone review-loop runtime stage.
+- The retired standalone review-loop instructions and their private anchor are removed; historical migration fixtures remain only where they translate legacy task text to the current reviewer binding.
+- Stateful/concurrent readiness calls for executed boundary validation; review result placement and cumulative CI/review repair accounting point to their shared contracts rather than creating tracked result-refresh commits.
+- Shared delivery skills use direct Tier 1..4 review evidence at PR and local-merge convergence.
+- The review contract defines lane scope, profile guidance, direct repair refresh, finding disposition, and high-risk full refresh without ledger orchestration.
+- Review Readiness is checked before runtime formal launch; direct plans carry Tier, rationale, runtime strategy, and profile guidance without reviewer scheduling, and changed Candidates receive fresh reviewers.
+- Main-agent disposition keeps repair in scope and diagnoses recurring root causes; design returns stop ordinary convergence and observations remain report-only.
+- ReviewReplay checks the diagnosis trigger before repair and keeps owner approval separate from in-scope repair count.
+- Current lane evidence binds `repo_root` and the active flow anchor carries the cumulative Repair Batch count; missing or stale evidence remains `unchecked` and blocks clear.
+- `ReviewReplay` contract tests also reject mismatched base/head, lane, scope, review profile, locked flow, ownership promise, or Repair Batch count before a continuation can relaunch a lane.
+- Active review Spec checks now mutate-test every required disposition, `unchecked` evidence, and complete anchor field across all four owned Specs.
+- Continuation tests independently reject stale base/head, lane, scope, profile, flow, ownership, and batch-count anchors.
+- Repair replay now requires an explicit `In-Scope Review Finding` before any candidate mutation or Repair Batch launch.
+- Actual review-base adoption requires an observed replacement SHA and fresh required lanes; missing replacement evidence is `unchecked`. Ordinary target advancement keeps the live round bound and is handled at its end; old results are not relabeled across bases.
+- Direct plan checks require a Tier 1..4 value, a tier-consistent runtime strategy that names a runtime launch/create action, and a concrete host-supported model/effort pair; Tier 1/2 remain assessment/advisory-only while Tier 3/4 require readiness-gated formal lanes.
+- Runtime launch checks the autonomous model allowlist and a session-scoped `agent-model` directive captured by the first non-empty `UserPromptSubmit` line before accepting an explicit exception.
+- `ReviewReplay` stores and validates the structured lane evidence fields before moving a required lane to terminal clear state, including exact lane scope, non-empty actual profile, and rejection of unknown fields.
+- `ReviewReplay` rejects disposition tokens outside the three canonical values before repair classification; malformed dispositions cannot become report-only or enter a Repair Batch.
+- `ReviewReplay` requires an explicit readiness success for initial launch and a non-empty demonstrated finding before an In-Scope Repair Batch.
+- `ReviewReplay` rejects unsupported actual model/effort pairs and unknown dispositions embedded in structured findings before terminal clear state.
+- `ReviewReplay` requires an `In-Scope` repair to have a demonstrated finding, not merely a non-empty observation list; direct formal fields are unique.
+- Structured finding objects now require the explicit `demonstrated` or `observation` kind before terminal evidence is accepted.
+- A blocking finding in complete clear terminal evidence remains a finding for disposition; only missing, stale, malformed, or unavailable evidence stays `unchecked`.
+- Priority-aware repair eligibility is owned by the shared review-proof contract: the initial Formal Review Wave permits an optional P2-only repair; later P2 repair requires a P0/P1 or qualifying current-Candidate CI trigger; low-priority findings can clear with `repair_not_required_low_priority` and a next-stop owner report, while P3 findings remain non-blocking targets.
+- The instruction architecture checker asserts this canonical Spec's disposition, evidence, Candidate-anchor fields, and behavioral boundary in isolated-copy tests.
+- The checker also guards the readiness vocabulary and the `0017` ADR binding across the active review Specs.
+- The flow receipt TypeScript adapter remains validation/lifecycle infrastructure; its review orchestration is listed for later removal in `../workflow-execution-receipts/contracts/review-orchestration-retirement.md`.

package/toolkit/skills/docs/vendor/dot-codex/specs/mandatory-local-review-proof/SPEC.md

@@ -0,0 +1,111 @@
+# Local Review Necessity And Evidence
+
+## Related ADRs
+
+- [0003 External Fact Delivery Gates](../../adr/0003-external-fact-delivery-gates.md)
+- [0014 Direct Review Evidence](../../adr/0014-direct-review-evidence.md)
+- [0016 Bind Review Repairs to Approved Scope](../../adr/0016-bind-review-repairs-to-approved-scope.md)
+- [0017 Review Readiness And Runtime Launch](../../adr/0017-review-readiness-and-runtime-launch.md)
+- [0032 Flow-Scoped Model Profile Allowlists](../../adr/0032-flow-scoped-model-profile-allowlists.md)
+- [0038 Direct Review Terra Profile](../../adr/0038-direct-review-terra-profile.md)
+- [0033 Empirical Acceptance and Repair Autonomy](../../adr/0033-empirical-acceptance-and-repair-autonomy.md)
+- [0034 Priority-Aware Review Repair Eligibility](../../adr/0034-priority-aware-review-repair-eligibility.md)
+
+## Context and Scope
+
+This topic covers direct `normal`, `fast-track`, and `local-merge` delivery, PR create/merge handoffs, and continuation. Historical multi-conversation coordination remains a separate compatibility state machine. The flow receipt TypeScript adapter remains the validation/lifecycle helper, but is outside the review execution and delivery decision path. There is no separate review-loop Skill in this workflow; formal convergence is owned by the shared review-proof contract and its flow consumers.
+
+Formal review has a Review Readiness gate: approved behavior and acceptance, scope, and required contracts must be stable; no design decision may remain unresolved; and the current Candidate must complete applicable validation and visual evidence before any formal lane launches at runtime. A plan records a Tier, rationale, runtime strategy, and profile recommendation, never a reviewer schedule or model identity. For a direct PR, `Step 4 Ready` records readiness and applicable pre-PR proof without completed PR-stage findings or dispositions; after exact live PR head/base binding, the CI tracker and PR-stage formal review start in the first round and the main Agent waits for both terminal states before convergence. Local-merge formal review still completes before Step 5L.
+
+## Requirements
+
+### REQ-DIRECT-REVIEW-EVIDENCE
+
+Every direct delivery MUST record an Agent-owned Tier 1..4 assessment, rationale, and current base/head. Tier 1 has no review gate. Tier 2 permits advisory review. Tier 3 requires fresh clear evidence from contract, state-concurrency, failure-data-safety, and test-platform lanes. Tier 4 adds one or two selected dynamic lanes from ui-accessibility, security, database-migration, and release-infra.
+
+For the PR path, `Step 4 Ready` MUST NOT require completed PR-stage findings or dispositions. After exact live PR head/base binding, required-CI tracking and fresh PR-stage formal lanes MUST start in the first round, and the main Agent MUST wait for both CI and all required lanes to reach terminal state before finding disposition, writing, commit, or a Repair Batch. The local-merge path MUST complete formal review before Step 5L.
+
+Each required lane is a read-only sub-agent review in the candidate worktree. Its structured result binds the candidate `repo_root`, current base/head, reviewed scope, actual model and effort, and findings. A lane is terminal only when those fields and an explicit clear evidence status are present and bound to the current candidate; missing fields or non-clear status remain `unchecked`, and the reviewed scope must equal the lane's declared paths or invariants with no unknown schema fields. It does not depend on child IDs, transcripts, or a receipt ledger. Missing, malformed, stale, or unavailable evidence blocks Tier 3/4 delivery and remains `unchecked`. A complete terminal result with `evidence_status=clear` may contain a blocking finding; that finding is classified under the disposition rules below rather than being converted into an evidence-state failure.
+
+Initial review runs every required lane for a ready Candidate. A repair refreshes lanes whose declared paths or invariants changed; retained results require inspectable source base/head and Git delta within the active run. Unknown scope, security, schema, transaction, protocol, concurrency, persistence, migration, or shared review-contract changes refresh every required lane. Ordinary target movement preserves the bound round under `../pr-freshness-gate/SPEC.md`; actually adopting a new review base refreshes all required lanes and binds that new SHA, with missing evidence remaining `unchecked`. Automatic cross-base reuse is unavailable. The parent groups root causes, validates repairs, and preserves the cumulative Repair Batch count for diagnosis and continuation; child lanes only report findings. The parent autonomously repairs proven in-scope findings within the selected flow's authorization, including after three batches. Near three batches or on a recurring root cause, it diagnoses scope, baseline, implementation and tests before continuing. No receipt-held permit, freeze, or retry state is used.
+
+### REQ-DIRECT-REVIEW-DISPOSITION
+
+Stateful/concurrent readiness MUST include executed behavioral validation of changed critical boundaries; check-only or blocked runs are insufficient. Evidence placement follows the shared workflow; cumulative repair accounting follows the review-proof contract and `../pr-convergence-batching/SPEC.md`.
+
+The main Agent classifies every demonstrated finding from a terminal review result against the approved behavior, acceptance, and non-negotiable safety boundaries:
+
+- `In-Scope Review Finding` enters the current Repair Batch only when its repair preserves the settled design and implementation scope, the terminal structured result contains a demonstrated finding, and the priority-aware repair threshold below is satisfied; only valuable, proven, in-scope items qualify, and late-PR resolution may explicitly hand an eligible item to follow-up;
+- `Design-Returning Review Finding` stops ordinary repair and convergence and returns the task for a new design decision before any changed Candidate is reviewed;
+- `Review Observation` is reported without creating a repair obligation or a new formal review wave.
+
+Any other disposition token is malformed evidence and must fail closed before repair or clear classification. Missing readiness evidence is also not approval: formal launch requires an explicit successful readiness fact, and a missing fact blocks launch.
+
+A formal review is clear when every required lane has valid terminal evidence, validation and applicable CI are clear, and there is no unresolved Design-Returning finding or `repair_required` resolution. A demonstrated P2/P3 or lower finding with `repair_not_required_low_priority` may accompany clear evidence and is reported at the next owner-facing stop. A suggestion without a demonstrated in-scope violation is a Review Observation. Missing, stale, malformed, or unavailable reviewer output remains `unchecked` evidence and is never fixed as a finding or treated as clear.
+
+### REQ-DIRECT-REVIEW-REPAIR-THRESHOLD
+
+The main Agent MUST classify priority after confirming that a finding is valuable, proven, in-scope, and not Design-Returning. `P0` and `P1` are high-priority; `P2`, `P3`, and lower values are low-priority. Unknown or missing priority remains unresolved and cannot be silently treated as low-priority.
+
+The first Formal Review Wave for the current flow is the initial ready-Candidate wave before any Repair Batch has been counted. In that wave, an eligible P2-only finding MAY receive `repair_resolution=repair_required`; P3 and lower findings do not create a repair obligation. If the main Agent makes no write, a P2-only result may clear with `repair_resolution=repair_not_required_low_priority`.
+
+From the second Formal Review Wave onward, a low-priority P2 MAY receive `repair_required` only when the terminal round also contains an eligible P0/P1 finding or a qualifying current-Candidate CI failure. A qualifying CI failure is attributable to in-scope code, tests, or configuration and is repairable under the selected flow. Infrastructure failure, flakiness, cancellation, timeout, missing results, or other unavailable CI evidence does not authorize an opportunistic P2 repair. P3 and lower findings remain non-blocking.
+
+When a P0/P1 or qualifying CI trigger opens a Repair Batch, an eligible P2 may be included only when it shares the approved scope or affected invariant of that batch. An unrelated P2 receives `repair_not_required_low_priority`. A P3 change that is unavoidable collateral of an approved repair is recorded as collateral, not as a separate repair target.
+
+The main Agent MUST record `repair_resolution` separately from the reviewer's three canonical dispositions. Allowed values are `repair_required`, `repair_not_required_low_priority`, and `deferred_follow_up`. The low-priority resolution is not a fourth reviewer disposition and does not turn a demonstrated finding into `Review Observation`. Design-Returning findings, safety boundaries, required acceptance, and other non-negotiable gates remain blockers regardless of priority.
+
+### REQ-DIRECT-REVIEW-LATE-RESOLUTION
+
+PR convergence follows the shared review-proof contract's Late PR resolution when the main Agent considers a concrete deferral after a terminal review/CI round. First preserve the valuable/proven/in-scope eligibility test; ineligible suggestions do not become repair or automatic follow-up work. PR-introduced P0/P1 findings stay prioritized in the current PR; unknown priority or attribution remains unresolved. Batch count alone neither requires deferral nor restricts in-scope repairs.
+
+The main Agent MUST record `resolution=current_pr|deferred_follow_up` and the independent `repair_resolution` separately from the three canonical dispositions and unchanged reviewer schema, with finding reference, priority, PR-introduction evidence, reason and authorized handoff scope/status. An explicit deferred handoff may remove that item's source-review blocker while remaining a real defect awaiting follow-up; it does not waive validation, CI, empirical evidence or non-negotiable safety boundaries. A low-priority finding without a first-wave exception or P0/P1/qualifying-CI trigger may clear with `repair_not_required_low_priority` and no follow-up obligation. Deferral consumes no Repair Batch, resets no source count, and grants no new write authorization. Local-merge and standalone without an authorized PR path do not gain PR delivery behavior.
+
+### REQ-DIRECT-REVIEW-MODEL
+
+Direct review inherits the exact six-profile allowlist and lane-local selection contract from [Workflow Agent Model Selection](../workflow-agent-model-selection/SPEC.md): ordinary review uses profiles 1-3 and defaults to profile 1, complex or rigorous review uses profiles 3-4, and special or high-risk review uses profiles 5-6 with a lane-specific escalation reason. Each formal lane binds its own profile; four-to-six lane count does not replace that policy with a shared profile.
+
+The ordered allowlist is:
+
+1. `gpt-6-luna + high`
+2. `gpt-6-luna + max`
+3. `gpt-5.6-luna + xhigh`
+4. `gpt-5.6-luna + max`
+5. `gpt-6.1-terra + xhigh`
+6. `gpt-6.1-sol + medium`
+
+Only a complete owner-specified `model + effort` pair is an override. The flow passes that exact pair to runtime without capability prechecking or fallback; runtime support or rejection remains authoritative. Model-only or effort-only text is not an override.
+
+Autonomous delegated launches are limited to `gpt-6.1-sol`, `gpt-6.1-terra`, `gpt-6-luna`, and `gpt-5.6-luna`. A non-autonomous supported model requires the exact standalone first non-empty prompt line `agent-model: <model>`; `agent-model: auto` removes the override. The override is session-scoped until replaced or removed and is not inherited by a fresh task.
+
+A live lane is waited on or relayed, and a terminal agent is retired rather than reused. A changed candidate requires a fresh `fork_turns=none` reviewer; an unaffected structured result may be retained only when its source facts and Git delta remain directly inspectable. Elapsed time alone is not review failure. A demonstrated issue whose remedy needs new behavior, a new contract, or wider scope is classified as `Design-Returning Review Finding` and ordinary repair/review stops until the design is resolved. Exhausting an orchestration wait budget is a non-terminal blocker, not review failure; only an explicit owner stop or terminal provider/runtime failure makes the lane unavailable. An
+
+<!-- review-anchor-contract:mandatory-spec:start -->
+
+owner-stopped lane is not retried by continuation without a new owner instruction or changed candidate, and live-lane uniqueness is scoped to the current flow invocation/thread. A non-terminal wait anchor carries `repo_root`, base SHA, head SHA, lane, scope, review profile, current locked flow, ownership promise, and cumulative Repair Batch count so continuation can only wait or relay that lane after verifying the matching Candidate; missing context requires owner input rather than a guessed relaunch. A continuation without the matching `repo_root`/base/head and count cannot relaunch or reset review work.
+
+<!-- review-anchor-contract:mandatory-spec:end -->
+
+## Verification
+
+### VER-DIRECT-REVIEW-EVIDENCE covers: REQ-DIRECT-REVIEW-EVIDENCE, REQ-DIRECT-REVIEW-MODEL
+
+- Tier 3/4 summaries bind the current base/head, lanes, scope, actual profile, and structured findings;
+- changed scope reruns only affected lanes; high-risk, unknown, or adoption of a different review base reruns all required lanes, while ordinary target advancement waits for the round boundary;
+- retained lanes are available only while their directly inspectable source result and Git delta remain in the active convergence run;
+- direct-flow contract tests cover base-drift refresh, finding disposition, design-return stops, recovery-anchor fields, and owner-stop continuation behavior;
+- the shared review contract and subagent status interface expose the complete recovery-anchor field set;
+- PR convergence requires current review evidence together with validation, required CI, and live GitHub facts;
+- direct PR evidence starts after exact live PR head/base binding in the first round with CI tracking, while local-merge evidence completes before Step 5L;
+- The flow receipt adapter is not called to assess, run, retain, or finalize review.
+
+### VER-DIRECT-REVIEW-DISPOSITION covers: REQ-DIRECT-REVIEW-DISPOSITION, REQ-DIRECT-REVIEW-REPAIR-THRESHOLD
+
+- terminal findings are classified as In-Scope, Design-Returning, or Observation;
+- observations remain report-only, low-priority accepted findings are recorded without blocking clear, design-returning findings stop ordinary convergence, and missing evidence remains `unchecked`;
+- initial-wave P2-only repair, later P0/P1 or qualifying-CI triggers, unrelated P2 acceptance, P3 collateral handling, and next-stop owner reporting are covered by the priority-aware repair threshold.
+
+### VER-DIRECT-REVIEW-LATE-RESOLUTION covers: REQ-DIRECT-REVIEW-LATE-RESOLUTION
+
+- Replay covers eligibility before priority, autonomous repairs after three batches, diagnosis triggers, current-PR P0/P1, unknown attribution, mixed current/deferred findings, and explicit handoff evidence.
+- A deferred-only candidate may clear review with valid terminal lanes; missing evidence, failed validation/CI, design returns and unresolved current-PR findings retain their blockers.