@peterxiaoyang/superspec 0.1.0

package/templates/workflow/prompts/verifier.md

@@ -0,0 +1,85 @@
+---
+description: "Completion evidence and verification specialist (STANDARD)"
+argument-hint: "task description"
+---
+<identity>
+You are Verifier. Prove or disprove completion with direct evidence.
+</identity>
+
+<goal>
+Turn claims into reproducible proof or proof gaps by checking code, diffs, commands, diagnostics, tests, artifacts, and acceptance criteria. Missing evidence is a gap, not a pass, and the main thread remains responsible for final adjudication.
+</goal>
+
+<constraints>
+<scope_guard>
+- Verify claims against observable evidence; do not trust implementation summaries.
+- Distinguish failed behavior from unavailable or missing proof.
+- Prefer fresh command output when available.
+</scope_guard>
+
+<ask_gate>
+<!-- OMX:GUIDANCE:VERIFIER:CONSTRAINTS:START -->
+- Default reports to outcome-first, evidence-dense verdicts: name the claim, success criteria, validation evidence, gaps, and stop condition before adding process detail.
+- Keep collaboration style direct and concise; do not expand verification scope beyond what materially proves or disproves the claim.
+- For multi-step verification, start with a concise preamble that names the first check; keep intermediate updates brief and evidence-based.
+- AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local inspect-test-verify work; keep inspecting, testing, and verifying without permission handoff.
+- ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.
+- On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next verification action or evidence-backed verdict.
+- Use absolute language only for true invariants: safety, security, side-effect boundaries, required output fields, workflow state transitions, and product contracts.
+- Keep gathering evidence until the verdict is grounded or blocked by a missing acceptance target or unavailable proof source.
+- If correctness depends on additional tests, diagnostics, or inspection, keep using those tools until the verdict is grounded; stop once enough evidence proves the core claim.
+- More verification effort does not mean unrelated tool churn; gather the proof that matters, not every possible artifact.
+<!-- OMX:GUIDANCE:VERIFIER:CONSTRAINTS:END -->
+- Ask only when the acceptance target is materially unclear and cannot be derived from repo or task history.
+</ask_gate>
+</constraints>
+
+<execution_loop>
+1. State what must be proven.
+2. Inspect relevant files, diffs, outputs, and artifacts.
+3. Run or review the commands that directly prove the claim.
+4. Report proof status, evidence, gaps, risks, and any blocked proof source.
+</execution_loop>
+
+<success_criteria>
+- Acceptance criteria are checked directly.
+- Evidence is concrete and reproducible.
+- Missing proof is called out explicitly.
+- The verdict is grounded and actionable.
+</success_criteria>
+
+<verification_loop>
+<!-- OMX:GUIDANCE:VERIFIER:INVESTIGATION:START -->
+5) If a newer user instruction only changes the current verification target or report shape, apply that override locally without discarding earlier non-conflicting acceptance criteria; preserve traceability from each claim to evidence, validation command, or explicit proof gap.
+<!-- OMX:GUIDANCE:VERIFIER:INVESTIGATION:END -->
+Keep gathering the required evidence until the verdict is grounded or the proof source is unavailable.
+</verification_loop>
+
+<tools>
+Use Read/Grep/Glob for evidence, diagnostics/test/build commands for behavior, and diff/history inspection when scope depends on recent changes.
+</tools>
+
+<style>
+<output_contract>
+## Verdict
+- PASS / FAIL / PARTIAL
+
+## Evidence
+- `command or artifact` — result
+
+## Gaps
+- Missing or inconclusive proof
+
+## Risks
+- Remaining uncertainty or follow-up needed
+</output_contract>
+
+<scenario_handling>
+- If the user says `continue`, keep gathering the required evidence instead of restating a partial verdict.
+- If the user says `merge if CI green`, check relevant statuses, confirm they are green, and report the gate outcome.
+</scenario_handling>
+
+<stop_rules>
+Stop only when the verdict is evidence-backed or the needed proof source/authority is unavailable.
+</stop_rules>
+</style>

package/templates/workflow/skills/superspec-apply/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: superspec-apply
+description: "3.在 SuperSpec RED/GREEN guard 检查下执行 tasks，并从 OpenSpec `openspec instructions apply` 获取任务上下文、顺序和进度。 / Apply tasks under SuperSpec RED/GREEN guard checks, delegating task context, ordering, and progress to OpenSpec `openspec instructions apply`."
+---
+
+# SuperSpec Apply
+
+## 语言规则 / Language
+
+- 默认使用简体中文撰写所有人类可读产物、分析、报告、说明和 OpenSpec 文档正文。
+- 保留命令、路径、JSON 字段、gate 名、task/test id、代码标识符和外部 API 名称的原文。
+- 当 OpenSpec 模板要求固定标题或字段时，保留模板结构，只将正文内容写成中文。
+
+在 propose package 完成后使用本 skill 执行实现任务。**Task context、ordering 和 progress 来自 OpenSpec native apply instructions**（`openspec instructions apply`）；SuperSpec 为每个 task 包上一层 RED/GREEN guard checks。
+
+## 边界 / Boundaries
+
+- 先桥接 repo-local OpenSpec apply skill：读取 `.codex/skills/openspec-apply-change/SKILL.md`，并复用其中的 change status、`contextFiles`、task list、progress 和 dynamic instruction 协议。
+- SuperSpec 覆盖 OpenSpec apply skill 的直接实现循环：对应 SuperSpec RED/GREEN guard 允许之前，不要编辑实现，也不要勾选 task。
+- Apply 只能在 propose package 完成后开始。
+- Task list、`contextFiles` 和 dynamic instruction **必须**来自 `openspec instructions apply --json`。不要自行发明 task list，也不要跳过 native context files。
+- 主线程负责编排和编辑；role review evidence 仍必须来自 native subagents。
+- `check-task-edit` 允许之前，不得进行 task 的实现编辑。`check-task-complete` 允许之前，不得勾选 task checkbox。
+- `openspec instructions apply --json` 返回 `state:"all_done"` 只表示 `tasks.md` 当前全部勾选；它不等于 workflow 已经通过 review。若存在 live/pass 的 `kind:"main_adjudication"` 且 `review_decision:"request_changes"`，必须先按其路由决定是 reopen 既有 task，还是停止并回 propose / change update。
+- 若存在 live/pass 的 `main_adjudication(review_decision:"request_changes")` 或 unresolved `task_reopen`，apply 必须把 reopen 分支视为高优先级状态；此时忽略 OpenSpec `state:"all_done"` 的归档建议，不得结束 apply。
+- 对已完成 task 的合法回退路径固定为：补齐 reopen package（`task_reopen` + 配套 `status:"superseded"` evidence）-> `check-task-reopen` -> 仅把目标 task 的 checkbox 从 `[x]` 改回 `[ ]` -> 重新 RED/GREEN -> `check-task-complete` -> 勾回 `[x]` -> `task_reopen_resolved`。这些 reopen lifecycle evidence 一律由 `superspec-apply` 主线程创建。不要把 reopen 当普通 pending task，也不要绕过 guard 直接手工回退。
+- 若当前仓库尚未暴露 `check-task-reopen` 或等效 reopen-aware apply surface，本 skill 必须 fail-closed：报告协议未启用，不得建议 archive，也不得手工回退 checkbox。
+- v1 evidence 是 audit-only/self-reported；实际命令输出应尽量记录到 `.superspec/raw/`。
+
+## 步骤 / Steps
+
+1. 对 apply isolation 和 execution mode 使用 AskUserQuestion，并等待明确选择。
+2. 当 dirty worktree、untracked files 或 branch state 需要决策时，使用 AskUserQuestion 处理 branch handling。
+3. 验证 apply readiness：
+   ```text
+   superspec guard check-apply-ready --change "<change>"
+   ```
+4. 获取 native apply context 和 task list：
+   ```text
+   openspec instructions apply --change "<change>" --json
+   ```
+   读取 `contextFiles` 下的每个路径，遵守 `openspec-apply-change` 的要求。把返回的 task list、progress 和 dynamic instruction 作为实现 source of truth，并按 `tasks.md` 的结构化字段（`dependencies`、`parallel_group`、`read_scope`、`write_scope`、`test_refs`、`invariant_refs`）判断串行/并行顺序。
+5. 先判断是否进入 review 驱动的 reopen 分支：
+   - 如果 native apply 返回 `state:"all_done"`，但当前 change 仍有 live/pass 的 `kind:"main_adjudication"` 且 `review_decision:"request_changes"`，或已经存在 unresolved `task_reopen`，不要把它当成“可归档”。
+   - 若 `request_changes_route:"reopen_tasks"`，读取 `reopen_task_ids`，逐个判断当前 task 所处阶段：
+     - 如果该 task 仍是 `[x]`，说明还处于首次回退前；先由主线程基于本轮 review 的结构化 output 写出该 task 的 `task_reopen` evidence 与配套 `status:"superseded"` evidence，形成完整 reopen package，再执行：
+     ```text
+     superspec guard check-task-reopen --change "<change>" --task-id "<task-id>"
+     ```
+       只有该 guard `allow` 后，才允许把对应 task 从 `- [x]` 改为 `- [ ]`，并把它重新纳入本轮 apply。
+     - 如果该 task 已经是 `[ ]`，且当前 `tasks.md` 已匹配授权后的 `after_tasks_sha256`，说明它已经处于合法 reopened apply；此时直接续跑 `check-task-edit -> RED/GREEN -> check-task-complete`，不要重复创建 `task_reopen`，也不要再次执行 pre-revert `check-task-reopen`。
+   - 若 `request_changes_route:"change_update"`，停止 apply，回 propose / change update；不要试图通过 reopen 继续实现。
+6. 对每个 pending task（包括刚刚合法 reopen 的 task），在任何实现编辑前执行：
+   ```text
+   superspec guard check-task-edit --change "<change>" --task-id "<task-id>"
+   ```
+7. 在 runtime/business implementation edits 前产出 RED evidence，除非有允许的 `no_tdd_reason` 或处于 characterization mode。RED/GREEN evidence 必须引用 task 的 `test_refs`，并在 task 声明 `invariant_refs` 时同步记录 `invariant_refs`。若 task 来自 reopen，本轮 successor GREEN / alternative verification / manual verification 必须携带同一 `reopen_id`。
+8. 按 native dynamic instruction 和 `contextFiles` 指引，实现最小 task scope。
+9. 产出 GREEN evidence，保留 `test_id`、`invariant_refs`、命令、输出摘要和 raw log ref。
+10. 勾选 task 前执行：
+   ```text
+   superspec guard check-task-complete --change "<change>" --task-id "<task-id>"
+   ```
+   然后按 native apply semantics 将 task 从 `- [ ]` 改为 `- [x]`。
+11. 如果该 task 来自 reopen，在重新勾回 `[x]` 后写入 `kind:"task_reopen_resolved"` evidence，关闭本轮 reopen 授权；不要复用旧 reopen 生命周期。reopen 只授权：
+    - 写该 task 的 reopen / supersede / resolved evidence
+    - 回退并恢复该 task 的 checkbox
+    - 在该 task 既有 `write_scope` 内返工
+    若需要修改 sibling task 的 `write_scope`，停止并对 sibling 单独 reopen，或回 propose / 新开 change。
+12. 如果 scope expands，停止并通过 AskUserQuestion 重新设计或拆分新 change。
+
+遇到任何 guard `block` 就停止。

package/templates/workflow/skills/superspec-archive/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: superspec-archive
+description: "5.通过原生 `openspec archive` 归档 SuperSpec OpenSpec change，并执行 SuperSpec preservation checks。 / Archive an SuperSpec OpenSpec change via native `openspec archive` with SuperSpec preservation checks."
+---
+
+# SuperSpec Archive
+
+## 语言规则 / Language
+
+- 默认使用简体中文撰写所有人类可读产物、分析、报告、说明和 OpenSpec 文档正文。
+- 保留命令、路径、JSON 字段、gate 名、task/test id、代码标识符和外部 API 名称的原文。
+- 当 OpenSpec 模板要求固定标题或字段时，保留模板结构，只将正文内容写成中文。
+
+仅在 `review_complete` passes（其中已经包含 final verification）后使用本 skill。
+
+## 边界 / Boundaries
+
+- 通过 native CLI 桥接 OpenSpec archive，不手动重实现 archive。可以读取 repo-local `.codex/skills/openspec-archive-change/SKILL.md` 来获取 selection/status guardrails，但其中手动 `mkdir`/`mv` archive procedure 在这里由 `openspec archive` 取代。
+- Archive 仍是 native `openspec archive`：它会移动 change、**更新 main specs（delta->main sync）**，并默认 **validates**。当前 SuperSpec v1 固定使用 `openspec archive -y "<change>"`，不暴露 `--skip-specs` 分支，且不允许 `--no-validate`。
+- SuperSpec 只检查 `archive_ready` 和 archived sidecar preservation；不重新实现移动、spec sync 或 validation。
+- preservation manifest 必须覆盖 `.superspec/artifacts/business-invariants.md`、`.superspec/artifacts/test-contract.md`、`.superspec/evidence/invariants/`、`.superspec/evidence/test-contract/`、RED/GREEN evidence、review/verification evidence，以及 archive evidence 本身。
+- v1 archive control 通过显式 guard checks 和 preservation verification 执行。
+
+## 步骤 / Steps
+
+1. 对 final `archive_ready` confirmation 使用 AskUserQuestion，等待明确选择。记录 archive-scoped human-confirmation evidence。当前 v1 不询问也不使用 `--skip-specs`；若 change 不应同步 specs，应先回到 propose/change update 调整 OpenSpec 包，而不是在 archive 阶段跳过。
+2. 检查 archive readiness 并生成 preservation manifest：
+   ```text
+   superspec guard check-archive-ready --change "<change>"
+   ```
+   生成的 manifest 是 archive 前证据快照，必须能追踪 business-invariants、test-contract 和对应 invariant review evidence 的 sha256。
+3. 运行 native OpenSpec archive（移动 change、同步 delta->main specs、执行 validation）：
+   ```text
+   openspec archive -y "<change>"
+   ```
+4. 根据 manifest 验证 archived `.superspec/` preservation：
+   ```text
+   superspec guard check-archived --change "<change>"
+   ```
+
+遇到任何 guard `block` 就停止。

package/templates/workflow/skills/superspec-explore/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: superspec-explore
+description: "1.探索并澄清需求，进入 SuperSpec propose 前完成 OpenSpec explore 立场和 critic 复核。 / Explore and clarify requirements before SuperSpec propose, adopting OpenSpec's explore stance plus critic review."
+---
+
+# SuperSpec Explore
+
+## 语言规则 / Language
+
+- 默认使用简体中文撰写所有人类可读产物、分析、报告、说明和 OpenSpec 文档正文。
+- 保留命令、路径、JSON 字段、gate 名、task/test id、代码标识符和外部 API 名称的原文。
+- 当 OpenSpec 模板要求固定标题或字段时，保留模板结构，只将正文内容写成中文。
+
+在 init 之后、编写 OpenSpec proposal package 之前使用本 skill。
+
+## 边界 / Boundaries
+
+- 先桥接 repo-local OpenSpec explore skill：读取 `.codex/skills/openspec-explore/SKILL.md`，并遵守其中的 explore 立场与 `OpenSpec Awareness` 指引。
+- SuperSpec 在 OpenSpec explore 之上增加更严格的边界：**只思考和调查，不实现**。主线程可以读代码、搜索代码并创建 `discovery.md` evidence，但不能修改应用代码，也不能在本阶段编写 OpenSpec planning artifacts。如果 OpenSpec explore 建议把决策沉淀到 proposal/specs/design/tasks，请先记录到 discovery，再交给 `superspec-propose`，由 `openspec instructions` 生成 OpenSpec artifacts。
+- Explore 只产出需求和上下文证据；不完成 OpenSpec proposal、specs、design 或 tasks。
+- 需求 critique evidence 必须来自 repo-local `critic` native subagent。
+- v1 evidence 是 audit-only/self-reported；除非有 OpenSpec facts 支撑，不要把它描述成强制运行时事实。
+
+## 范围收敛透明度 / Scope Transparency
+
+- Agent 可以在 explore/propose 前基于证据收敛范围，但不得静默收窄用户目标。
+- 当用户目标、现有实现或合理利益相关方预期自然覆盖多个层级、模块、入口、流程、角色或行为，而 discovery/proposal/design 只准备覆盖其中一部分时，必须显式记录纳入范围、排除范围、排除理由、已知或可合理推断的影响，以及仍未知但会影响范围判断的风险。
+- 不能把“本轮先做最小改动”“默认不处理其他模块”“按当前实现猜测无影响”作为隐式排除理由；这些都必须写成可审查的范围决策。
+- `critic` 必须阻塞未说明的关键范围收窄：如果范围收敛会改变用户合理预期、验收口径、兼容承诺、测试边界或后续实现风险，而 artifact 没有说明纳入/排除/理由/影响，则不能通过 explore/propose handoff。
+
+## 审查披露循环 / Review Disclosure Loop（DISC Phase 1）
+
+多角色审查发现的问题**不允许主线程自行消化**。material 问题（`scope` / `non_goal` / `acceptance` / `business_semantics` / `design_boundary`）必须以原文披露给用户，拿到用户裁决后才能继续。
+
+- critic review evidence 必须携带 `review_round_id`（形如 `explore_complete-r<N>`，从 r1 连续编号）和结构化 `findings[]`：每条 finding 含 `finding_id`、`finding_uid`（`<gate>:<evidence_id>:<finding_id>`）、`finding_type`（`blocker|scope_risk|open_question|agent_assumption|non_blocking_finding`）、`category`、`material_categories[]`、material 时的 `decision_scope_key`，以及 reviewer 原话 `summary`。分类字段的 producer 是 reviewer，主线程不得改写（P0-2）。
+- 每轮审查后主线程写 `kind:"main_review_digest"` evidence（`created_by:"main-thread"`），逐条覆盖该轮所有 findings：身份字段与 `summary` **逐字拷贝** origin finding，给出 `disposition`（`fixed|false_positive|accepted_deviation|user_decided|needs_user_decision`）、`rationale`、`route`/`route_reason` 和 per-disposition proof；`target_refs` 钉住当前 discovery blob；`source_review_evidence_refs` 引用本轮全部 role review；round>1 时 `previous_digest_refs` 串接上一轮 digest。
+- **material finding 一律走用户 checkpoint**：digest 先以 `status:"blocked"` + `needs_user_decision` 记录，然后把 finding 原文 + A/B/C/D 选项 +（每个选项对 scope / non-goals / acceptance / tests 的影响面）呈现给用户。用户裁决记录为 `kind:"user_review_decision"`（`created_by:"user"`，`finding_uids` 精确到 `finding_uid`，`decision_scope_key`、`material_categories[]`、`confirmed_refs` 钉住用户看到的 blob）。D 选项必须保留 `user_text` 原文并填 `structured_decision`（scope/non_goals/acceptance_impact/test_impact + requires_artifact_update/requires_rereview 布尔值）。
+- 用户裁决导致 discovery 修改后：更新 artifact → supersede 过期的旧轮 review → 重跑 critic（round k>1 的 prompt **必须**内嵌工具渲染的 finding ledger，由 `render_finding_ledger` 生成，guard 逐字校验）→ 写新一轮 digest（终态 disposition 引用 `user_decision_refs`，artifact 修改时附 `artifact_update_refs`）。
+- material finding 的任何终态 disposition（含 `fixed`/`false_positive`）必须引用 `user_decision_refs[]`、有效 `standing_authorization_refs[]` 或 `baseline_decision_refs[]`；standing authorization 只能由用户创建、按 category 授权、永不覆盖 blocker。
+- finding history 是 append-only：旧 blocker 不会因 clean 重审而消失，必须拿到终态 disposition；同 gate 超过 3 轮仍未收敛时停止迭代，把未决 findings 整体升级给用户（`escalate_round_budget`）。
+- 历史 change 的旧式 critic evidence（无 `review_round_id`/`findings[]`）维持原判定口径，不被追溯 block。
+
+## 步骤 / Steps
+
+1. 确保项目级 SuperSpec surfaces 已存在：
+   ```text
+   superspec init --scope project
+   ```
+2. 创建或打开 native OpenSpec change root，然后确认 change-scoped guard readiness 并拉取 native context：
+   ```text
+   openspec new change "<change>"   # 仅当该 change 不存在时执行
+   superspec guard check-init --change "<change>"
+   openspec list --json
+   openspec status --change "<change>" --json   # changeRoot / artifactPaths / actionContext for grounding
+   ```
+3. 保持 OpenSpec explore 立场，同时遵守 SuperSpec 输出边界：可以自由调查和澄清，但本阶段只写 SuperSpec sidecar evidence。
+4. 主线程直接调查当前实现：定位相关文件、隐藏契约、约束、风险和 source anchors。
+5. 启动 repo-local `critic` native subagent（round r1），审查歧义、遗漏场景、矛盾、scope risk 和范围收敛透明度；如存在未显式说明的关键范围收窄，critic 必须 block。critic 输出按上方披露循环要求落成带 `review_round_id` + `findings[]` 的 evidence。
+6. 写入合并后的 discovery artifact：
+   ```text
+   openspec/changes/<change>/.superspec/artifacts/discovery.md
+   ```
+7. 在 `.superspec/evidence/discovery/` 记录 critic evidence，包含 `execution_mode:"native_subagent"`、`agent_role`、`agent_id`、`output_ref`、`source_anchors` 和 `target_refs`。
+8. 按披露循环处理 findings：写本轮 `main_review_digest`；存在 material finding 时**停下来向用户披露并等待 `user_review_decision`**，再按裁决更新 discovery / 重跑 critic / 写新一轮 digest，直到最新轮 clean 且 ledger 无未终态 finding。
+9. 验证 explore completion：
+   ```text
+   superspec guard check-enter --change "<change>" --gate explore_complete
+   ```
+
+遇到任何 guard `block` 就停止。disclosure 相关 block（`missing_review_digest`、`needs_user_decision_pending`、`finding_unresolved`、`user_decision_unbound`、`ledger_injection_missing`、`round_budget_exhausted` 等）的唯一合法出路是回到披露循环或升级给用户，不允许绕过。

package/templates/workflow/skills/superspec-propose/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: superspec-propose
+description: "2.生成 SuperSpec propose 包，将 artifact 编写委托给 OpenSpec `openspec instructions`，并叠加 SuperSpec design review / business-invariants / test-contract / tasks gates。 / Produce the SuperSpec propose package by delegating artifact authoring to OpenSpec `openspec instructions`, with SuperSpec design review / business-invariants / test-contract / tasks gates layered on top."
+---
+
+# SuperSpec Propose
+
+## 语言规则 / Language
+
+- 默认使用简体中文撰写所有人类可读产物、分析、报告、说明和 OpenSpec 文档正文。
+- 保留命令、路径、JSON 字段、gate 名、task/test id、代码标识符和外部 API 名称的原文。
+- 当 OpenSpec 模板要求固定标题或字段时，保留模板结构，只将正文内容写成中文。
+
+在 explore 完成后使用本 skill，用于生成完整 OpenSpec planning package。Artifact 编写必须委托给 OpenSpec native instruction engine（`openspec instructions`）；SuperSpec 只在其外层增加 adversarial review gates、sidecar business invariants、sidecar test contract 和 tasks metadata。
+
+## 边界 / Boundaries
+
+- 先桥接 repo-local OpenSpec propose skill：读取 `.codex/skills/openspec-propose/SKILL.md`，并复用其中的 artifact-order / `openspec status` / `openspec instructions` 编写协议。
+- SuperSpec 覆盖 OpenSpec propose skill 的 one-shot completion 形态：本阶段不创建或选择 change，也不能不经 SuperSpec gates 一次性完成所有 artifacts。`superspec-explore` 负责 change 创建和 discovery；本 skill 负责 gated artifact authoring。
+- OpenSpec artifacts（`proposal.md`、`specs/**/*.md`、`design.md`、`tasks.md`）**必须**通过 `openspec instructions <artifact> --json` 编写，使用其返回的 `template`/`rules`/`context`。**不要手写 OpenSpec artifacts 绕过 native engine**，否则会丢失 schema template、project context 和 validation alignment。
+- Propose 阶段拥有 SuperSpec sidecar planning artifacts：`.superspec/artifacts/business-invariants.md`、`.superspec/artifacts/test-contract.md`。任务依赖、读写范围、TDD 元数据和映射关系直接写入 `tasks.md` 的结构化字段，不再维护单独的 JSON 任务图文件。
+- Internal propose gates：`explore_complete`、`proposal_reviewed`（`propose.proposal_reviewed`）、`design_complete`（`propose.design_reviewed`）、`invariants_reviewed`（`propose.invariants_reviewed`）、`test_contract_drafted`（`propose.test_plan_drafted`）、`tasks_complete`（`propose.tasks_mapped`）、最终 `propose_complete`。
+- `proposal_reviewed` 是硬性 internal gate（DISC Phase 2），不是 advisory note：`proposal.md` 完成后必须运行带 `review_round_id`（`proposal_reviewed-r<N>`）和 `findings[]` 的 `critic` review，并由主线程记录 `main_review_digest`。guard 对该 gate 不提供 legacy 豁免——没有 round-tagged review + digest 一律 block。审查披露循环规则（material findings 必须经 `user_review_decision` 用户裁决、findings ledger 不可抹除、digest 链与轮次连续性）与 `superspec-explore` skill 的「审查披露循环 / Review Disclosure Loop」一节完全一致。
+- `design_complete`、`invariants_reviewed`、`test_contract_drafted` 在出现 round-tagged review evidence 后进入同一披露循环（DISC Phase 3）；旧式无 `review_round_id`/`findings[]` 的 review evidence 维持 grandfathered 口径（P2-3），但**新写的 review 必须走完整披露**。
+- `tasks_complete` 仅在新增 round-tagged role review 后才纳入披露循环（本 gate 本身不强制 role review；一旦 agent 为 tasks 写了带 findings 的 review，就必须 digest + 用户裁决闭环）。
+- proposal review 的 route 约束：若 finding 证明 discovery 本身不完整或 scope 不清，处置 route 必须是 `return_explore`（回 `superspec-explore` 补事实层），不得在 proposal 内静默补范围；仅措辞/意图不一致且不改 scope 时才可 `stay_same_gate_fix`。
+- design review 的 route 约束：scope / non-goal 与上游不一致时用 `return_explore_or_proposal_reviewed`；设计边界/架构取舍用 `stay_same_gate_user_decision`。
+- invariants / test-contract review 的 route 约束：业务语义/不变量真相不确定、验收口径变更等 material finding 用 `stay_same_gate_user_decision`；若需回改 spec/design 表达，用 `return_explore_or_proposal_reviewed`。
+- tasks review 的 route 约束：task 映射 / test_refs / read-write scope 问题用 `stay_same_gate_fix`；若验收口径本身错了，用 `return_test_contract_drafted` 回 test-contract gate，不得静默改 tasks 消化 material acceptance 问题。
+- Role-gate evidence 必须来自 native subagents。v1 evidence 是 audit-only/self-reported；除非有 OpenSpec facts 支撑，不要把它描述成强制运行时事实。
+
+## 步骤 / Steps
+
+1. 验证 explore completion：
+   ```text
+   superspec guard check-enter --change "<change>" --gate explore_complete
+   ```
+2. 从 OpenSpec 获取 artifact build order：
+   ```text
+   openspec status --change "<change>" --json
+   ```
+   按 `openspec-propose` 的说明解析 `applyRequires`、`artifacts`（status + dependencies）、`planningHome`、`changeRoot`、`artifactPaths` 和 `actionContext`。按依赖顺序编写 artifacts（proposal -> specs -> design -> tasks）。
+3. 对每个状态为 `ready` 的 OpenSpec artifact，都通过 native engine 编写：
+   ```text
+   openspec instructions <artifact-id> --change "<change>" --json
+   ```
+   - 读取 `dependencies` artifacts 和 `.superspec/artifacts/discovery.md` 作为上下文。
+   - 使用 `template` 写入 `resolvedOutputPath`；把 `context`/`rules` 当约束使用，不要复制进产物正文。
+   - 重新运行 `openspec status --change "<change>" --json`，确认 artifact 变为 `done`，再执行对应 SuperSpec 层。
+4. `proposal.md` 编写并经 `openspec status` 确认为 `done` 后、开始 `specs/**`/`design.md` 前：执行 `proposal_reviewed` 披露循环：
+   - 启动 `critic` native-subagent review，范围限定在 proposal 的 scope / intent / non-goals / hidden assumptions；evidence 必须带 `review_round_id`（`proposal_reviewed-r<N>`）、`findings[]` 和 pinned `target_refs`（`proposal.md` + `.superspec/artifacts/discovery.md`）。
+   - 主线程记录 `main_review_digest`，给每个 finding 写处置：material findings（scope / non_goal / acceptance / business_semantics / design_boundary）必须 `needs_user_decision` 并停下来，用 AskUserQuestion 把原文和 A/B/C/D 选项抛给用户，拿到 `user_review_decision` 后才能继续；发现 discovery 不完整时 route 用 `return_explore` 回 explore，不得自行补范围。
+   - 修订 `proposal.md` 后必须重跑 `critic`（新一轮 round），直到 clean round + digest 通过，然后验证：
+   ```text
+   superspec guard check-enter --change "<change>" --gate propose.proposal_reviewed
+   ```
+   guard 未放行前不要开始编写 `specs/**` 或 `design.md`（两者的 artifact entry gate 都是 `proposal_reviewed`）。
+5. `design.md` 编写后：获取 `architect`、`critic`、`test-engineer` 的 native-subagent review evidence（带 `review_round_id` `design_complete-r<N>` + `findings[]` + 全量 pinned target：`proposal.md` + `design.md` + `specs/**/*.md` + discovery）。主线程记录 `main_review_digest`；material findings 必须停下来向用户披露并等待 `user_review_decision`，按裁决改 design/specs 后 supersede 旧轮并重审。对于 design option selection 和 final design confirmation，使用 AskUserQuestion 并等待明确选择；记录 human-confirmation evidence，然后验证：
+   ```text
+   superspec guard check-enter --change "<change>" --gate propose.design_reviewed
+   ```
+6. `specs/**` 和 `design.md` 编写后、`test-contract.md` 编写前：起草 `.superspec/artifacts/business-invariants.md`。每条 `INV-*` 必须有 statement、scope、source anchors、acceptance_refs、risk_refs、confidence、enforcement_level、test_refs_or_review_only_reason；记录 rejected candidates，防止把当前实现习惯误升格为业务真相。获取 `critic` + `test-engineer` review evidence（带 `review_round_id` `invariants_reviewed-r<N>` + `findings[]` + pinned target：business-invariants + design + specs glob）。主线程记录 `main_review_digest`；material 业务语义 finding 必须 `needs_user_decision` 并等待用户裁决，不得把实现习惯静默升格为 invariant 真相。然后验证：
+   ```text
+   superspec guard check-enter --change "<change>" --gate propose.invariants_reviewed
+   ```
+7. `business-invariants.md` 完成后、`tasks.md` 编写前：起草 `.superspec/artifacts/test-contract.md`，覆盖 specs 中每个 `#### Scenario` 和命中本 change scope 的 hard `INV-*`，包含 TEST ids、关联 INV ids、预期 RED reasons、预期 GREEN criteria 和 commands。获取 `test-engineer` + `critic` review evidence（带 `review_round_id` `test_contract_drafted-r<N>` + `findings[]` + pinned target：test-contract + invariants + design + specs glob）。主线程记录 `main_review_digest`；验收口径变更等 material finding 必须用户裁决。然后验证：
+   ```text
+   superspec guard check-enter --change "<change>" --gate propose.test_plan_drafted
+   ```
+8. 通过 `openspec instructions tasks` 编写 `tasks.md` 时：为每个 task 补充 `requirement_refs`、`invariant_refs`（必须是 business-invariants `INV-*` ids 的子集）、`test_refs`（必须是 test-contract TEST ids 的子集）、`read_scope`、`write_scope`、dependencies、TDD metadata，以及需要时的 parallel group。若 reviewer 对 task 映射提出 round-tagged findings，走 `tasks_complete-r<N>` 披露循环（pinned target：tasks + test-contract + invariants + design + specs glob）；验收口径问题 route 用 `return_test_contract_drafted`，映射问题用 `stay_same_gate_fix`。对于 tasks review confirmation，使用 AskUserQuestion 并等待明确选择；记录 human-confirmation evidence，然后验证：
+   ```text
+   superspec guard check-enter --change "<change>" --gate propose.tasks_mapped
+   ```
+9. 验证 apply readiness：
+   ```text
+   superspec guard check-apply-ready --change "<change>"
+   ```
+
+遇到任何 guard `block` 就停止。

package/templates/workflow/skills/superspec-review/SKILL.md

@@ -0,0 +1,237 @@
+---
+name: superspec-review
+description: "4.在 review 阶段完成 SuperSpec implementation review 和 final verification gates。"
+---
+
+# SuperSpec Review
+
+在 implementation tasks 完成后使用本 skill。它完成一个合并后的 review 阶段：实现代码审查 guidance、SuperSpec critic guidance、最终验证、主线程终局 adjudication 和 `review_complete` guard 检查。旧 `superspec-verify` / `check-verify-ready` 只是兼容入口，不再作为独立 user-visible workflow。
+
+## 语言规则 / Language
+
+- 默认使用简体中文撰写所有人类可读产物、分析、报告、说明和 OpenSpec 文档正文。
+- 保留命令、路径、JSON 字段、gate 名、task/test id、代码标识符和外部 API 名称的原文。
+- 当 OpenSpec 模板要求固定标题或字段时，保留模板结构，只将正文内容写成中文。
+
+## 硬边界
+
+- `review_complete` 是 allow-only gate。只有 `main_adjudication.review_decision:"allow"` 才允许进入 `check-review-complete` / `archive_ready`。
+- allow path 的 `review_complete` 必须包含 `kind:"source_guidance"`（`code-reviewer`、`architect`、`critic`）、`kind:"verification_review"`（`verifier`、`critic`）、`kind:"final_test"` 和非角色 `kind:"main_adjudication"`；其中 `openspec validate` 输出必须被 `verification_review.openspec_validate_ref` 引用。`request_changes` 分支不应伪装成 `review_complete`。
+- `superspec-review` 直接拥有并执行 repo-local review 协议：本阶段必须先启动 `code-reviewer`、`architect`、`critic` native subagent 产出 `source_guidance`；若走 allow path，再完成 final verification；随后由主线程读取关键 source 与必要的 verification evidence，写出唯一 `main_adjudication`。
+- 不要把 code review 外包给全局/独立 `code-review` skill、OMX runtime workflow 或普通 markdown 报告；不需要单独安装 `code-review` skill。全局 `code-review` skill 只能作为机制参考，gate 只认 repo-local SuperSpec role surfaces 和 `.superspec` evidence schema。
+- 所有 review / critic / verifier role evidence 都必须来自 repo-local native subagents。不要用 main-thread self-review、同名 global prompt、普通 markdown 报告或 `execution_mode:"direct"` 替代。
+- review-phase native subagent 只能给 guidance，不能替代主线程最终裁决。主线程必须在读取关键 source 与 verification evidence 之后，通过 `main_adjudication` 显式记录：看了哪些关键 source、采纳或驳回了哪些 claim、最终为什么 allow/block。
+- `main_adjudication` 的作者边界固定为 `execution_mode:"direct"` + `created_by:"main-thread"`；它不得携带 `agent_role`、`agent_id`、`prompt_ref`。不要留“像主线程”的自由格式。
+- review 没有直接回改 `tasks.md` 的权限。若 review 认定“原已完成 task 的完成证明失效”，主线程只能写出结构化 `request_changes` 裁决，为 apply 提供 reopen 授权；不要在 review 阶段直接把 task 从 `[x]` 改回 `[ ]`。
+- `review_decision:"request_changes"` 必须显式声明路由：`request_changes_route:"reopen_tasks"` 表示回 apply 返工既有 task；`request_changes_route:"change_update"` 表示回 propose / change update。不要把需求/范围/设计问题伪装成 task reopen。
+- `review_decision:"request_changes"` 时，`verification_evidence_refs` 必须为空；不要在 request-changes round 里补写 allow-path verification 再尝试过 `review_complete`。
+- 路由裁决遵循单值优先级：只要同一轮 review 中仍存在任何必须回 propose / change update 的 blocker，`request_changes_route` 就必须取 `change_update`；只有当所有未解决 blocker 都可由既有 task 返工闭环时，才允许取 `reopen_tasks`。
+- `task_reopen`、配套 `status:"superseded"` evidence 和 `task_reopen_resolved` 不由 review 写入；它们的作者边界固定在 `superspec-apply` 主线程。
+- 阻断 findings 必须有 dispositions 和 rollback targets。遇到任何 guard `block` 就停止。
+- 如果 verification fails，且需要在修复与接受偏差之间做选择，使用 structured user input / AskUserQuestion；不要使用默认值、历史偏好或沉默作为确认。
+
+## 仓库本地角色入口
+
+Review 前必须确认这些 SuperSpec distribution files 存在；缺失、无效或当前 Codex surface 无法从它们启动 native subagents 时，review gate 必须 block：
+
+```text
+superspec guard check-init --change "<change>"
+```
+
+Required project-scope files: `.codex/agents/code-reviewer.toml`、`.codex/prompts/code-reviewer.md`、`.codex/agents/architect.toml`、`.codex/prompts/architect.md`、`.codex/agents/critic.toml`、`.codex/prompts/critic.md`、`.codex/agents/verifier.toml`、`.codex/prompts/verifier.md`。
+
+## 执行步骤
+
+1. 检查 review readiness：
+   ```text
+   superspec guard check-review-ready --change "<change>"
+   ```
+2. 从 `git diff`、OpenSpec artifacts、tasks、business invariants、test contract、red/green evidence 和 `.superspec` evidence 构建审查范围。
+3. 运行 repo-local review guidance：
+   - 启动 repo-local `code-reviewer` native subagent，记录 `kind:"source_guidance"`。
+   - 启动 repo-local `architect` native subagent，记录 `kind:"source_guidance"`。
+   - 启动独立 repo-local `critic` native subagent，审查 superspec-specific scope drift、隐藏假设、业务不变量是否被测试/实现扭曲、遗漏的 rollback targets 和 evidence 充分性，并记录 `kind:"source_guidance"`。
+4. 主线程读取关键 source，准备 adjudication 输入：
+   - 从每条 `source_guidance.source_refs` 中判断哪些内容需要亲自加载。
+   - `source_refs` / `required_load_refs` 使用 `pinned_ref = {path, blob_sha}`；其中 `pinned_ref.path` 一律是 repo-root relative path。`required_load_refs` 必须按 `(path, blob_sha)` 精确包含于 `source_refs`。
+   - 对所有 `required_load_refs` 做真实读取，并在 `loaded_refs` 中记录同样的 `pinned_ref`；`loaded_refs` 必须按 `(path, blob_sha)` 精确覆盖全部 `required_load_refs`，同一路径不同 blob 不算已加载。
+   - 对所有 `required_claim_ids` 写出结构化 `claim_adjudications[] = {claim_id, decision, rationale}`。
+   - 对所有 `blocking_findings[*].finding_id` 写出结构化 `finding_adjudications[] = {finding_id, decision, rationale}`。
+   - `claim_adjudications[].decision` 使用 `accept | reject | needs_fix`；`needs_fix` 不是 allow 终态。
+   - `finding_adjudications[].decision` 使用 `dismissed | accepted_fixed | accepted_deviation | needs_fix`；只有前三者是 allow 终态。
+5. 先判断本轮是否进入 `reopen_authorization` 分支：
+   - 当 blocking finding 已具备 `completion_invalidity_class`，且 `scope_expansion:false`，并且问题指向“既有 task 的完成证明失效”时，本轮 review 进入 `reopen_authorization`。
+   - 若同一轮 review 仍存在任何 scope / requirement / design / artifact blocker 需要回 propose 或 change update，则不得进入 `reopen_authorization`；此时 `request_changes_route` 必须改为 `change_update`。
+   - 在 `reopen_authorization` 分支中：
+     - 供 v1 guard / apply 消费的最小 reopen 映射只有一条：被主线程选入 `blocking_source_evidence_refs` 的 `code-reviewer source_guidance`，其 `blocking_findings[*].affected_task_ids` 必须覆盖待 reopen 的 task。
+     - 主线程稍后写出的 `main_adjudication` 必须包含 `review_decision:"request_changes"`、`request_changes_route:"reopen_tasks"`、`blocking_source_evidence_refs`、`reopen_task_ids`
+     - 不调用 `check-review-complete`
+     - 不生成面向 allow 的 `verification_review` / `final_test` evidence
+6. 仅在 allow 评估 path 执行 final verification：
+   ```text
+   openspec validate "<change>"
+   ```
+   - 运行 test contract 要求的项目/test commands，并记录 `kind:"final_test"` evidence；最小字段为 `gate:"review_complete"`、`test_command`、可读的 `output_ref`，并依赖 canonical evidence `status:"pass"` 作为通过状态。
+   - 生成 task matrix、invariant matrix 和 scope drift assessment。
+   - 启动 repo-local `verifier` native subagent，复核 completion evidence、测试充分性、OpenSpec validation 和 task matrix，并记录 `kind:"verification_review"`。
+   - 启动 repo-local `critic` native subagent，复核 scope drift、accepted deviations 和 evidence 充分性，并记录 `kind:"verification_review"`。
+   - `verification_review` 只提供 proof/gap，不替代主线程 adjudication；若发现新的 blocking issue，则本轮 review 保持 block，修复后重跑 verification，再进入终局 adjudication。
+7. 主线程写入唯一一条 `kind:"main_adjudication"` evidence：
+   - allow path 必须同时引用 `source_guidance` 和 `verification_review` / `final_test` evidence。
+   - 若任何 verification gap 仍未闭环，不得写出 allow 所需的终局 adjudication。
+   - 若结论是 `review_decision:"request_changes"`，必须同时写清 `request_changes_route`：
+     - `reopen_tasks`：显式列出 `reopen_task_ids`，把问题退回 apply 修复既有 task。
+     - `change_update`：显式说明需要回 propose / change update；此时 `reopen_task_ids` 必须为空。
+   - `request_changes` 只负责给出结构化回退方向，不直接修改 task checkbox。
+8. 仅在 allow path 检查 review completion：
+   ```text
+   superspec guard check-review-complete --change "<change>"
+   ```
+   - 只有终局 allow path 才应执行并通过这一步。
+   - 如果本轮 `main_adjudication.review_decision:"request_changes"`，则本轮 review 的正确出口是停止并回到对应路由；不要把 `request_changes` 轮次伪装成 `review_complete`。
+
+## Review Guidance 协议
+
+`superspec-review` 直接拥有 review guidance 协议。本阶段必须启动 repo-local `code-reviewer`、`architect`、`critic` native subagents，记录结构化 `source_guidance` evidence；allow path 还要补齐 final verification，然后由主线程写出唯一一条 `main_adjudication`。
+
+不要为 code review 调用另一个 skill 或 workflow。不要用 `$code-review`、global skills、OMX runtime workflows、main-thread self-review 或普通 markdown 报告替代这些 guidance lanes。
+
+## Review 到 Apply 的回退协议
+
+- 当 review 发现的是“既有 task 的验收条件没有真正满足”，主线程必须把这类问题写成可机判的 `request_changes` 裁决，而不是留在自由文本里等待人工理解。
+- `request_changes_route:"reopen_tasks"` 是唯一允许进入 `task_reopen -> apply_fix` 的 review 路由；对应 `reopen_task_ids` 必须明确列出受影响 task。
+- `request_changes_route:"change_update"` 表示问题属于需求、范围、设计或 artifact 边界，正确出口是回 propose / change update，而不是 reopen 现有 task。
+- 若同一轮 review 同时存在 reopen-compatible blocker 与 change-update blocker，必须按 `change_update` 裁决；不要把混合 blocker 压缩成 reopen。
+- 返工完成后的新一轮 review，必须 supersede 旧的 `request_changes` `main_adjudication` 以及它依赖的相关 source evidence，避免旧阻断裁决继续留在 live/pass 集合中。
+- 对仍停留在 legacy `.irsflow/*` review evidence 的 change，进入 reopen 协议前应先执行一次 review-only backfill：在 `.superspec/evidence/reviews/` 下重跑结构化 `source_guidance` 与 `main_adjudication`，但不要把旧 `.irsflow` evidence 直接并入 live 集合。
+- review 不负责创建 `task_reopen` / `status:"superseded"` / `task_reopen_resolved`；这些 lifecycle evidence 由 apply 主线程接管。
+
+### 必需 native subagent guidance
+
+`code-reviewer` guidance 负责实现审查：
+
+- 规格一致性：实现匹配 OpenSpec requirements、tasks 和 test contract。
+- 正确性：业务行为、边界条件、回归风险、错误处理和数据一致性。
+- 安全性：硬编码密钥、注入风险、XSS/CSRF、认证/授权绕过和敏感数据泄露。
+- 测试充分性：red/green evidence 可信度、关键路径覆盖和 changed-diff coverage。
+- 代码质量：复杂度、重复、命名、可维护性、性能热点、N+1 以及掩盖问题的 fallback/workaround code。
+
+`architect` guidance 负责设计审查：
+
+- 边界与接口：系统边界、契约、模块耦合和数据流。
+- 取舍风险：长期维护风险、隐藏依赖、扩展成本和回滚难度。
+- 反方论证：反对原样 approve 的最强理由。
+`critic` guidance 负责反方论证：
+
+- 质疑主线程可能忽略的边界、范围漂移、证据跳读和 accepted deviation。
+- 标记哪些 source 必须由主线程亲自加载，而不是只看 summary。
+- 把“subagent 只是导游，不是最终裁决者”落实成可机检的 claims / loads。
+
+### 严重级别
+
+- `CRITICAL`：安全漏洞、数据丢失、权限绕过或严重生产事故风险。
+- `HIGH`：明确 bug、主要业务回归、验收阻断或严重架构风险。
+- `MEDIUM`：次要缺陷、可维护性问题、测试缺口、性能风险或边界风险。
+- `LOW`：风格、命名或小型可读性建议。
+
+### 综合规则
+
+- subagent 可以报告风险、缺口、建议和推荐动作，但不能直接决定 `review_complete` allow。
+- `review_complete` 只接受主线程 `main_adjudication` 作为最终裁决 proof；没有它即使所有 subagent 都写了 “pass” 也必须 block。
+- `required_load_refs` 必须被主线程真实读取并记录到 `loaded_refs`，并且按 `(path, blob_sha)` 精确匹配，否则 block。
+- `required_claim_ids` 必须被主线程显式 adjudicate，否则 block。
+- 每个 `blocking_findings[*].finding_id` 都必须被主线程显式 adjudicate；有 blocker 没有 `finding_adjudications[]`、或 decision 仍是 `needs_fix` 时，直接 block。
+
+## 证据契约
+
+每个 evidence file 都必须包含通用 schema 字段：
+
+- `schema_version`
+- `evidence_id`
+- `change_id`
+- `gate`
+- `kind`
+- `created_at`
+- `created_by`
+- `status:"pass"|"fail"|"blocked"|"superseded"`
+
+每条 review native-subagent `kind:"source_guidance"` evidence 都必须包含：
+
+- `gate:"review_complete"`
+- `kind:"source_guidance"`
+- `execution_mode:"native_subagent"`
+- `agent_role`（仅 `code-reviewer`、`architect`、`critic`）
+- `agent_id`
+- `prompt_ref`
+- `output_ref`
+- `source_anchors`
+- `target_refs`：非空 `{path, blob_sha}` 列表，指向被审查目标，并且在 evidence 创建时保持 fresh；对于 review-phase `source_guidance`，其中 `path` 一律是 repo-root relative path
+- `source_refs`：主线程可进一步读取的原始 source/artifact/log refs，使用 `pinned_ref = {path, blob_sha}`，其中 `path` 一律是 repo-root relative path
+- `required_load_refs`：主线程必须亲自读取的关键 refs，使用 `pinned_ref = {path, blob_sha}`，并且必须是 `source_refs` 的精确子集
+- `required_claim_ids`：主线程必须在 `main_adjudication` 中显式处理的 claim ids
+- `base_ref`
+- `head_ref`
+- `reviewed_files`：repo-root relative path 列表
+- `blocking_findings`
+- `non_blocking_findings`
+- `finding_dispositions[] = {finding_id, recommendation, rationale}`，并且必须对每个 `blocking_findings[*].finding_id` 恰好覆盖一次
+- `rollback_targets`
+
+若某条 `blocking_findings[*]` 用于 `reopen_authorization`，则该 finding 还必须包含：
+
+- `affected_task_ids`
+
+`violated_test_ids` / `violated_requirement_refs` / `why_completion_invalid` / `required_fix` 等更重的 reopen lifecycle 字段可以作为详细 overlay 保留在专门设计文档中，但不属于 v1 canonical guard 必填项。
+
+主线程 `kind:"main_adjudication"` evidence 必须包含：
+
+- `gate:"review_complete"`
+- `kind:"main_adjudication"`
+- `execution_mode:"direct"`
+- `created_by:"main-thread"`
+- `output_ref`
+- `review_decision`
+- `request_changes_route`（当 `review_decision:"request_changes"` 时必填，v1 仅允许 `reopen_tasks | change_update`）
+- `source_evidence_refs`
+- `blocking_source_evidence_refs`
+- `reopen_task_ids`（仅 `request_changes_route:"reopen_tasks"` 时允许非空）
+- `verification_evidence_refs`（allow path 必填且必须覆盖本轮 `verification_review` / `final_test`；`reopen_authorization` path 允许为空）
+- `loaded_refs`（`pinned_ref = {path, blob_sha}`，其 `path` 同样必须是 repo-root relative path，并且必须精确覆盖全部 `required_load_refs`）
+- `claim_adjudications[] = {claim_id, decision, rationale}`
+- `finding_adjudications[] = {finding_id, decision, rationale}`
+- `raw_artifact_refs`（仅在高风险/冲突/accepted deviation/无法复现实验等需要原始材料时强制）
+
+`source_evidence_refs` 必须指向对应 `source_guidance` 的 live/pass evidence id；allow path 的 `verification_evidence_refs` 必须指向本轮 `verification_review` / `final_test` 的 live/pass evidence id，`reopen_authorization` path 则保持为空。普通 markdown 链接只能作为人类可读材料，不能满足 gate proof。`main_adjudication` 不得携带 `agent_role`、`agent_id`、`prompt_ref`。每个 `required_claim_id` 必须被 `claim_adjudications[]` 恰好处理一次；每个 `blocking_findings[*].finding_id` 必须被 `finding_adjudications[]` 恰好处理一次。
+
+补充约束：
+
+- `blocking_source_evidence_refs` 必须是 `source_evidence_refs` 的子集。
+- `review_decision:"request_changes"` 时必须显式写出 `request_changes_route`；不要让 apply 从自由文本猜测回退方向。
+- `request_changes_route:"reopen_tasks"` 时，`reopen_task_ids` 必须非空，并且只包含当前 review 明确认定完成证明失效的 task。
+- `request_changes_route:"change_update"` 时，`reopen_task_ids` 必须为空。
+
+最终验证 native-subagent role evidence 应使用 `kind:"verification_review"`，并且必须包含：
+
+- `openspec_validate_ref`
+- `task_matrix_ref`
+- `invariant_matrix_ref`
+- `scope_drift_ref`
+- `test_evidence_refs`
+- `scope_drift`
+
+`kind:"final_test"` evidence 必须至少包含：
+
+- `gate:"review_complete"`
+- `test_command`
+- `output_ref`
+
+并依赖 canonical evidence `status:"pass"` 作为 allow 所需的成功状态；`output_ref` 必须指向本次终局测试运行的可读日志/结果。
+
+在 `review_complete` 判定中，只接受 `gate:"review_complete"` 的 `verification_review` / `final_test` 证据。`check-verify-ready` / `verify_complete` 只是兼容命令别名，不得单独扩大证据来源。
+
+## 停止条件
+
+- 任一 guard command 返回 `block` 时立即停止。
+- 任何 `required_load_refs` 未被主线程读取、任何 `required_claim_ids` 未被主线程 adjudicate、任何 `blocking_findings[*].finding_id` 未被 `finding_adjudications[]` 恰好处置一次、其 decision 仍为 `needs_fix` 时，必须停止并补证据；若当前走 allow path，任何 final verification proof 缺失同样必须停止并补证据。
+- 如果本轮 `main_adjudication.review_decision:"request_changes"`，停止在 route 明确后的 handoff 上：`reopen_tasks` 回 apply，`change_update` 回 propose / change update。
+- 只有 `check-review-complete` 返回 `allow` 后才算完成。