@aipper/aiws-spec 0.0.47 → 0.0.49

package/templates/workspace/.opencode/skills/ws-frontend-design/SKILL.md

@@ -23,34 +23,21 @@ description: 使用时机：需要前端设计、UI/UX 实现时。触发词：
 - `Interaction thesis:` 2-3 个动效想法及其如何改善层级/氛围/可感知性
 
 ## 设计默认值
-- 从构图开始，不从组件库开始
-- 第一屏优先海报感（poster），不是文档感（document）
-- 默认先找强视觉锚点：大图、主视觉平面、关键产品画面、主数据工作区
-- 默认不做卡片墙；优先 section / column / divider / media block / list / plain layout
-- 默认最多两套字体、一种强调色；已有品牌系统则优先跟随
-- 优先靠留白、尺度、裁切、对比、对齐建立层级，再考虑装饰
+- 构图优先于组件库；第一屏偏海报感，非文档感
+- 强视觉锚点：大图 / 主视觉平面 / 产品画面 / 主数据工作区
+- 避免卡片墙；用 section / column / divider / media / list / plain layout
+- ≤两套字体、一种强调色（有品牌系统则跟随）；靠留白、尺度、裁切、对比、对齐建层级
 
 ## Landing 规则
-默认结构：
-- Hero：品牌/产品名、承诺、CTA、一个主视觉
-- Support：一个具体能力 / 证明点
-- Detail：氛围、流程、产品深度或故事
-- Final CTA：开始、注册、联系、访问
-Hero 强约束：
-- 一个 section 只承载一个 dominant idea
-- 默认 full-bleed hero；仅内层文字列约束宽度
-- 品牌名 > headline > body > CTA
-- 不要 hero cards / stat strips / logo clouds / pill soup / floating dashboards
-- headline desktop 约 2-3 行；mobile 一眼读完
-- 有固定 header 时占用首屏预算；header + hero 不超出 viewport
-- 若去掉主视觉后首屏仍几乎成立，说明图像太弱
+结构：Hero（名/承诺/CTA/主视觉）→ Support（能力/证明）→ Detail（氛围/流程/故事）→ Final CTA
+Hero：每 section 一个 dominant idea；默认 full-bleed（仅文字区限宽）；品牌名 > headline > body > CTA
+禁止：hero cards / stat strips / logo clouds / pill soup / floating dashboards
+headline desktop 约 2-3 行、mobile 一眼读完；header+hero 不超 viewport；主视觉去掉后首屏仍成立=图像太弱
 
 ## App-UI 规则
-- 偏克制：少颜色、少 chrome、清晰栅格、密度适中、信息可扫读
-- 优先组织为 primary workspace → navigation → secondary context → action
-- card 只用作交互容器；否则改回 plain layout
-- 不要把常规产品 UI 做成营销落地页
-- 文案优先 orientation / status / action；不要首页口号 / 情绪隐喻 / 执行摘要横幅
+- 克制：少色、少 chrome、清晰栅格、可扫读；primary workspace → nav → secondary context → action
+- card 仅作交互容器，否则 plain layout；勿把产品 UI 做成营销页
+- 文案偏 orientation / status / action；忌口号 / 情绪隐喻 / 摘要横幅
 
 ## 图像与媒体
 - 图像必须承担叙事任务，不能只是补背景
@@ -78,14 +65,9 @@ Hero 强约束：
 - 图像上的文字必须保证对比度与点击区域可用
 - 必须同时考虑 desktop / mobile；验证命令优先引用 `AI_WORKSPACE.md`
 
-## 硬规则
-默认不堆卡片 / hero cards / SaaS card grid。每 section 一个 dominant idea。最多两套字体、一种强调色。产品 UI 后不加装饰渐变，图像后不堆文字，不用 filler copy。
-
-## 实现检查（交付前自检）
-- 第一屏能否一眼看出品牌/产品；是否有明确视觉锚点
-- 只扫标题能否理解页面；每个 section 是否只有一个职责
-- card 是否真有必要；动效是否真正提升层级/氛围
-- 去掉装饰阴影后页面是否仍成立
+## 实现检查（交付前）
+- 首屏品牌/锚点明确；扫标题即可懂页；每 section 单一职责
+- card 有必要；动效真提升层级；去装饰阴影后页面仍成立
 
 ## 输出要求
 - `Mode:` `landing | app-ui | polish-only`

package/templates/workspace/.opencode/skills/ws-goal/SKILL.md

@@ -17,6 +17,40 @@ ws-goal 不做的事：
 - 不替换 review/commit/finish 门禁
 - 不 auto-chain 到下一个 goal（但在同一 goal 内支持多组顺序调度 §6）
 
+
+## Phase Boundary Authority (TOOLING-003D / contract §10)
+
+**Sole writer**: `aiws goal advance` is the **only** allowed writer for phase-boundary fields in `.aiws/goals/<goal-id>.state.json`:
+- `status` (active/complete/paused/…)
+- `current_phase`
+- checkpoint `status` / `completed_at` / `error` / `attempts` for phase transitions
+
+**MUST at every phase boundary** (after verifying the phase is actually done):
+```bash
+aiws goal advance --goal-id <goal-id> [--json]
+# optional explicit jump (prerequisites must be complete):
+aiws goal advance --goal-id <goal-id> --phase <next_phase>
+# dirty / drift recovery or §7.6 migration (active .md, missing state.json):
+aiws goal advance --goal-id <goal-id> --heal
+# preview:
+aiws goal advance --goal-id <goal-id> --dry-run
+```
+
+**FORBIDDEN**:
+- Hand-editing `state.json` checkpoint/status/`current_phase` fields to "mark complete" or "start next phase"
+- Freehand JSON patches as the normal advance path
+- Treating model memory of progress as authoritative over CLI state
+
+**Allowed without advance**:
+- Create initial `state.json` once when defining a new goal (all checkpoints pending, status=active) — first transition still goes through `advance`
+- Read state for inject / resume summary
+- Write Progress Notes / goal `.md` human text (not machine FSM fields)
+
+**Dirty states**: `aiws goal validate-state` rejects inconsistent FSM snapshots. Heal via `advance --heal` or `validate-state --heal`, then continue with `advance`.
+
+**Platform continuation** (Ralph 主 / Boulder 辅) may re-invoke advance; they do **not** own the FSM write path.
+
+
 前置条件：
 1) 先运行 `/ws-preflight`（对齐 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`）。
 
@@ -38,10 +72,10 @@ ws-goal 不做的事：
              - （b）跳过该 phase（标记 complete，继续下一个）
              - （c）暂停并 handoff
         iv. 用户选择后：
-             - 若选择 a）→ 设置 `current_phase` 到最近一个非 complete 的 checkpoint，注入 §7.5 continuation context 并恢复执行
-             - 若选择 b）→ 标记当前 failed phase 为 complete，设置 `current_phase` 到下一个 phase
+             - 若选择 a）→ `aiws goal advance --goal-id <id> --heal`（如需）后从当前 phase 恢复；注入 §7.5 continuation context
+             - 若选择 b）→ 用 `aiws goal advance --goal-id <id> --phase <next>`（prereq 已满足时）跳过；**禁止**手改 JSON
              - 若选择 c）→ 输出 handoff 建议，结束
-        v. 若用户选择全量重跑 → 重置 state.json 所有 checkpoints 为 pending，status=active，从头开始
+        v. 若用户选择全量重跑 → 通过 heal/migration 或新建 state（CLI），不要 freehand 重置 JSON
    c) 若未找到 state.json 但有 status=active 或 status=paused 的 .md 文件（旧格式迁移）：
       - 按 §7.6 迁移策略处理（自动生成 state.json 后全量重跑）
 1) **工作区上下文扫描（Context-Aware Intake）**：在开始 intake 问题前，先扫描工作区获取已有工作的上下文信号，用于预填充 intake 的初始问题答案：
@@ -72,7 +106,7 @@ Change 分支: change/fix-auth (3 commits, 未合并)
 4) **产出 intake 草案**：写入 `plan/<timestamp>-<slug>.intake.md`，包含完整的决策树遍历记录，并在草案开头嵌入**步骤 1 的工作区上下文摘要**作为上下文来源记录
 5) **阻塞检查**：若 intake 草案中存在 `UNRESOLVED_BRANCH`，输出阻塞报告并暂停。用户必须显式确认忽略或补充信息后才能进入 PHASE 1。
 6) 将 intake 审问结果（已冻结的目标范围、约束、边界）传递到后续 goal objective 定义。
-6a) **记录 checkpoint**：更新 `.aiws/goals/<goal-id>.state.json` → checkpoint `intake=complete` + `completed_at`
+6a) **记录 checkpoint（sole writer）**：phase 验证通过后运行 `aiws goal advance --goal-id <goal-id>`（完成 intake → 启动 goal_def）。**禁止**手改 state.json。
 
 > **Auto-Advance**：若步骤 5 无 UNRESOLVED_BRANCH，步骤 6→6a→PHASE 1 自动推进，不需询问用户确认。参见 §7.8。
 
@@ -85,42 +119,41 @@ Change 分支: change/fix-auth (3 commits, 未合并)
     - `current_phase`: "intake"
     - 所有 checkpoints: `{"status": "pending", "attempts": 0, "completed_at": null, "error": null}`
 9) 输出 completion audit checklist，列出每个 goal 的完成标准与验证方式。
-9a) **记录 checkpoint**：更新 `.aiws/goals/<goal-id>.state.json` → checkpoint `goal_def=complete` + `completed_at`
+9a) **记录 checkpoint（sole writer）**：`aiws goal advance --goal-id <goal-id>`（完成 goal_def → 下一 phase）。**禁止**手改 state.json。
 
 ### PHASE 2 — 预检与管道委托
 
-**Checkpoint 记录规则**（贯穿整个 Phase 2）：
-- 每个 phase 边界必须更新 `.aiws/goals/<goal-id>.state.json`：
-  - 进入 phase → `current_phase=<phase>`，对应 checkpoint `status=in_progress`
-  - 完成 phase → checkpoint `status=complete` + `completed_at=ISO8601`
-  - 失败 → checkpoint `status=failed` + `error=<message>`
-  - 暂停 goal → `status=paused`（全局）
+**Checkpoint 记录规则**（贯穿整个 Phase 2，TOOLING-003D）：
+- 每个 phase 边界 **必须** 调用 `aiws goal advance --goal-id <goal-id>`（sole writer）
+- 进入/完成 phase 的 `current_phase` 与 checkpoint 状态由 advance 写入
+- 失败/暂停：优先通过 advance/heal 路径或文档化的 CLI；**禁止**手改 JSON 推进
+- dirty 时：`aiws goal advance --goal-id <goal-id> --heal` 或 `aiws goal validate-state --heal`
 
 10) **依赖链预检**：按 ws-goal-contract.md §2.4 执行上游依赖链健康检查。
-    - 通过后：更新 checkpoint `dep_check=complete`
-    - 阻断时：更新 state.json `status=paused`，记录 error，结束
+    - 通过后：`aiws goal advance --goal-id <goal-id>`（完成 dep_check）
+    - 阻断时：在 Progress Notes 记录 error；状态机暂停语义见 contract（勿手改 JSON 伪装 complete）
 
-11) **Workspace State Analysis**：分析 dirty/submodule/change artifacts/git 状态，输出分级影响报告。按 §2.5.4 分级处理：
+11) **Workspace State Analysis**：分析 dirty/submodule/change artifacts/git 状态，输出分级影响报告。按 §2.5.4 分级处理（SSOT：**HIGH → 自动解决**，默认不阻断）：
    - NONE/LOW → 自动继续，记录到 Audit Trail
    - MED → 自动继续，输出警告
-   - **HIGH** → 阻断，必须等待用户确认后才能继续
-   - 通过后：更新 checkpoint `ws_analysis=complete`
+   - **HIGH** → 按 contract §2.5.4 自动处理：dirty 时执行 `git stash push --keep-index -m "ws-goal auto-stash: <goal-id>"`；若 stash 失败 → 警告用户并暂停。完成后执行 `git stash pop`。submodule 等问题按 contract 处理；仅自动化失败时提示，**不**默认等人确认
+   - 通过后：`aiws goal advance --goal-id <goal-id>`（完成 ws_analysis）
 12) **Phase-Level Pipeline Delegation**：预检 + 分析通过后，将 goal 拆分为 PLAN→DEV→REVIEW→FINISH 四个 phase 顺序执行，每个 phase 委托给独立轻量子 agent，主 session 验证每个 phase 产出后决定继续/重试/暂停。参考 `/ws-goal` command 的 step 5 完整流程。
-     - 每个 pipeline phase 开始前：更新 state.json `current_phase`，对应 checkpoint `status=in_progress`
+     - 每个 pipeline phase 验证通过后：`aiws goal advance --goal-id <goal-id>`（sole writer）
+     - **Prompt Inline Diff（T2）**：构造 REVIEW 委托 prompt 时，必须内联 `git diff` 输出（`git diff HEAD --stat` + `git diff HEAD` 或 `git diff <change-base>..HEAD`），将 change scope 与具体改动注入 prompt，使 reviewer 无需额外上下文查询。DEV 委托 prompt 同理可附 diff 引用。
      - Granularity Gate（c-i）：在 DEV 委托前运行；检查 granularity_ok=true、design_context 和 internal_tasks 非空
      - 粒度不达标（granularity_ok != true）→ 阻断并输出报告，暂停 goal
      - 粒度达标后进入 DEV delegation（c-ii）
-     - 每个 pipeline phase 通过后：更新 checkpoint `status=complete` + `completed_at`
-    - 每个 pipeline phase 失败后：更新 checkpoint `status=failed` + `error`，递增 `attempts`
+     - 失败：Progress Notes 记 error；不要手改 checkpoint 伪装 complete
 
 13) **PLAN 多分支决策支持**：当 PLAN 产出包含多个可行执行路径时（如"先 Phase 1&2 vs 先修 P0 stub"），不得停下询问用户"选哪个"。改为：
      - 用 §7.9.3 格式输出结构化建议块（含各分支内容、风险、预估、推荐）
      - 可调用 Oracle 分析各分支的代码级影响来生成建议块（§7.10）
      - 用户确认选择后继续执行；仅当各分支风险/收益接近无推荐时才需用户主动分析
 
-14) **Auto-Advance**：所有 phase 间推进（INTAKE→GOAL_DEF→DEP_CHECK→WS_ANALYSIS→PLAN→DEV→REVIEW→FINISH）遵循 §7.8 Auto-Advance 协议。仅以下情况需要人工确认：
+14) **Auto-Advance（协议 §7.8 + CLI §10）**：所有 phase 间推进（INTAKE→GOAL_DEF→DEP_CHECK→WS_ANALYSIS→PLAN→DEV→REVIEW→FINISH）在验证通过后 **必须** 执行 `aiws goal advance`。协议描述语义；**写权威是 CLI**。仅以下情况需要人工确认后再 advance：
      - INTAKE 阶段存在 UNRESOLVED_BRANCH（步骤 4）
-     - 工作区分析存在 HIGH 阻断项（步骤 11）
      - 依赖链 UNHEALTHY（步骤 10）
      - PLAN 存在多分支需用户选择（步骤 13）
-     除此之外的 phase 边界自动推进，不需要询问用户。
+     **注意**：workspace HIGH **不是**默认人工门禁（§2.5.4 自动解决）。除此之外的 phase 边界在验证通过后直接 advance。
+     每次 advance 成功后执行下方 **Platform Continuation Binding** 镜像刷新。

package/templates/workspace/.opencode/skills/ws-plan/SKILL.md

@@ -13,9 +13,7 @@ description: 使用时机：需要生成执行计划、建立 change 绑定时
 - 计划必须包含“主索引绑定”：`Change_ID` / (`Req_ID` or `Problem_ID`) / `Contract_Row` / `Plan_File` / `Evidence_Path`
 
 OpenCode + oMo 优先策略：
-- 若检测到 `.opencode/oh-my-opencode.json`，或当前会话明确可用 `planner-sisyphus` / `explore` / `librarian`，优先按 `packages/spec/docs/opencode-omo-adapter.md` 借用这些 agent。
-- 计划主框架优先交给 `planner-sisyphus`；代码结构探索优先交给 `@explore`；规范/文档/依赖查证优先交给 `@librarian`。
-- 主 agent 负责回收这些结果并最终落盘 `plan/...`；不要把“调用了 oMo agent”当作已经完成计划。
+- 有 oMo 时按 `packages/spec/docs/opencode-omo-adapter.md` 优先委托 `planner-sisyphus` / `@explore` / `@librarian`；主 agent 回收结果并落盘 `plan/...`（调用 agent ≠ 完成计划）。
 
 约束：
 - 不写入任何 secrets（token、账号、内网端点等不得进入 git）
@@ -33,11 +31,7 @@ OpenCode + oMo 优先策略：
 - 若已有计划：当前 `plan/...` 文件
 
 必需输出：
-- `Plan file:` 实际写入的 `plan/...`
-- `Change context:` 当前生效的 `change/<change-id>` 分支或 worktree
-- `Bindings:` `Change_ID` / `Req_ID|Problem_ID` / `Contract_Row` / `Plan_File` / `Evidence_Path`
-- `Verify:` 可复现验证命令与预期
-- `Next:` 先 `$ws-plan-verify`，通过后再 `$ws-dev`
+- `Plan file:` / `Change context:` / `Bindings:` / `Verify:` / `Next:`（先 `$ws-plan-verify`，通过后再 `$ws-dev`）
 
 阻断条件：
 - 任务目标或归因绑定不清晰
@@ -52,7 +46,7 @@ OpenCode + oMo 优先策略：
    - 若检测到 oMo：优先让 `planner-sisyphus` 生成 planning draft；若需要补结构探索，再委托 `@explore` / `@librarian`。
 2) 若用户任务描述不清：先问 1-3 个关键澄清问题（不要猜）。
 3) 判断复杂度：`simple / medium / complex`（给出一句理由），并估算步骤数。Granularity gate：每步必须 ≤3 个原子操作（read/edit/write/run）。若某步超过此限，拆细后再写入计划。
- 4) 识别或建立主索引 / change 上下文：
+4) 识别或建立主索引 / change 上下文：
    - 若存在 `.aiws/changes/<change-id>/proposal.md`：读取其中 `Change_ID` / `Req_ID` / `Problem_ID` / `Contract_Row` / `Evidence_Path`
    - 若缺失关键绑定：先补齐 proposal（至少 `Change_ID`、`Req_ID|Problem_ID`、`Contract_Row`）再继续生成计划
    - 若当前不在 `change/<change-id>` 分支 / worktree，且本次任务需要新建 change：
@@ -71,15 +65,19 @@ OpenCode + oMo 优先策略：
    - `Goal`：要达成什么
    - `Non-goals`：明确不做什么（避免 scope creep）
    - `Scope`：将改动的文件/目录清单（不确定就写 `TBD` 并说明如何确定）
-    - `Plan`：分步执行（每步尽量落到具体文件/命令；必要时拆 Phase）。每步必须 ≤3 个原子操作；若某步超限，拆成多步。
+   - `Plan`：分步执行（每步尽量落到具体文件/命令；必要时拆 Phase）。每步必须 ≤3 个原子操作；若某步超限，拆成多步。
    - `Submodules`（当存在 `.gitmodules` 且声明了 submodule 条目时，强制）：声明“本次 change 的 submodule 目标分支真值”（用于同一 superproject 分支内的多渠道交付；也避免仅靠 `.gitmodules` 默认分支导致交付推送到错误分支）
    - `Verify`：可复现命令 + 期望结果（优先引用 `AI_WORKSPACE.md` 的入口；必要时补充 e2e）
-    - `Risks & Rollback`：风险点 + 回滚方案（例如 git 回滚、`aiws rollback`、恢复备份等）
-    - 若 intake 草案包含 `Error States` 或 `Rollback Plan`：必须显式引用并纳入本计划的 `Risks & Rollback` 中，不能丢弃 intake 已识别的问题
+   - `Risks & Rollback`：风险点 + 回滚方案（例如 git 回滚、`aiws rollback`、恢复备份等）
+   - 若 intake 草案包含 `Error States` 或 `Rollback Plan`：必须显式引用并纳入本计划的 `Risks & Rollback` 中，不能丢弃 intake 已识别的问题
    - `Evidence`：计划文件路径；若创建了变更工件则附 `.aiws/changes/<change-id>/...`
 7) 若存在 change proposal：回填并对齐 `proposal.md` 的 `Plan_File`（必要时同步 `Contract_Row` / `Evidence_Path`），保证 plan/proposal 一致。
 8) 运行 `$ws-plan-verify` 作为执行前质量门（计划不过长、不跑偏、验证可复现）。
    - 通过后：标记 `[workflow-state:plan:DONE]` 或 `[workflow-state:gate:plan_passed]`，表示 plan 阶段已收敛。
+8a) **Task Granularity Gate（T3）**：在 plan→dev 交接前，逐条验证计划中每步 ≤3 个原子操作（read/edit/write/run）：
+    - 若 any 步超限：拆细后再重新通过 ws-plan-verify，**不** 允许带着粗粒度任务进入 ws-dev
+    - 仅当全部通过后才可标记 plan 完成并进入 ws-dev
+    - 此门禁同样适用于 goal pipeline 的 Granularity Gate（c-i）—— ws-plan 的产出必须能通过下游检查
 9) 若计划涉及“需求/验收”变更：先用 `$ws-req-review` 评审 → 用户确认后再 `$ws-req-change` 落盘（避免需求漂移）。
 10) 多步任务（≥2 步）：后续进入实现时，使用 `update_plan` 工具跟踪 `pending → in_progress → completed`。
 
@@ -87,20 +85,8 @@ oMo 回退：
 - 若当前没有 oMo、没有 `planner-sisyphus`，或你无法稳定调用相关 agent：直接回退为普通 OpenCode `plan` / 当前 agent 本地规划。
 - 回退不改变 AIWS 的要求：`plan/...` 仍必须落盘，bindings / verify / risks / evidence 仍必须完整。
 
-补充：submodule 目标分支真值（强约束；同一 superproject 分支内可多渠道）
-- 背景：`.gitmodules submodule.<name>.branch` 适合作为“团队默认分支真值”，但当同一 superproject 分支需要在不同交付中选择不同 submodule 目标分支（多渠道）时，仅靠 `.gitmodules` 不足。
-- 强约束：当 `.gitmodules` 声明了 submodule 条目时，门禁会要求本次 change 存在该文件且覆盖所有 submodule path（否则 `aiws validate .` / `aiws change validate --strict` 阻断）。
-- 约定：为本次 change 落盘一个“交付目标分支映射”文件，并在后续 `$ws-dev`/`$ws-deliver`/`$ws-finish` 优先使用它：
-  - 文件：`.aiws/changes/<change-id>/submodules.targets`
-  - 格式：每行一个 submodule（忽略空行与 `#` 注释），字段用空白分隔（推荐 `TAB`）：
-    - 第 1 列：submodule path（例如 `vendor/foo`）
-    - 第 2 列：target branch（例如 `release/channel-a`）
-    - 第 3 列（可选）：remote 名（默认 `origin`）
- - 生成模板：
-   ```bash
-   bash .opencode/scripts/ws-plan-gen-submodule-targets.sh <change-id>
-   ```
-- 计划里必须写清：本次交付选择的 `targets` 内容，以及后续在 `$ws-dev` 进入编码前会把 submodules 挂到 `aiws/pin/<target_branch>`（必要时先 `fetch`）。
+补充：submodule 目标分支真值
+- 规范见 `packages/spec/docs/ws-goal-contract.md` §delivery-targets；落盘 `.aiws/changes/<change-id>/submodules.targets`（可用 `bash .opencode/scripts/ws-plan-gen-submodule-targets.sh <change-id>`）。有 `.gitmodules` 时门禁强制要求覆盖所有 submodule path；计划须写清 targets，后续 `$ws-dev` 前挂到 `aiws/pin/<target_branch>`。
 
 输出要求：
 - `Plan file:` <实际写入的路径>

package/templates/workspace/.opencode/skills/ws-quality-review/SKILL.md

@@ -27,6 +27,7 @@ OpenCode + oMo 优先策略：
 - `证据（Evidence）:` `.aiws/changes/<change-id>/review/quality-review.md` 或回退 `.aiws/tmp/review/quality-review.md`
 - `主要发现（Findings）:` 高到低排序的问题 / 风险 / 缺失测试
 - `下一步（Next）:` 最小修复项与回归命令
+- 证据分级规则：BLOCKER/HIGH 发现需要展开证据（代码引用/日志/上下文）；PASS/LOW 发现一行结论即可
 
 阻断条件：
 - 没有可审改动

package/templates/workspace/.opencode/skills/ws-spec-review/SKILL.md

@@ -28,6 +28,7 @@ OpenCode + oMo 优先策略：
 - `证据（Evidence）:` `.aiws/changes/<change-id>/review/spec-review.md` 或回退 `.aiws/tmp/review/spec-review.md`
 - `阻断项（Blockers）:` requirements 归因 / gate / evidence 缺口
 - `下一步（Next）:` 修复项与最小验证命令
+- 证据分级规则：BLOCKER/HIGH 发现需要展开证据（代码引用/日志/上下文）；PASS/LOW 发现一行结论即可
 
 阻断条件：
 - 无法定位项目根或真值文件