@aipper/aiws-spec 0.0.42 → 0.0.44

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

@@ -45,39 +45,43 @@ OpenCode + oMo 优先策略：
 步骤（建议）：
 1) 先做 preflight：定位项目根目录，读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`，输出约束摘要。
    - 若检测到 oMo：优先让 `@oracle` 做独立审查；必要时再让 `@explore` / `@librarian` 补上下文。
-1.5) **Triage**：preflight 后立即判断本 change 是否需要双审查：
+2) **Change Scope Assessment**：在深入审查前，先获取变更上下文。
+   - 执行 `git diff --stat HEAD` 查看变更文件及行数
+   - 执行 `git log --oneline -3` 查看最近提交
+   - 使用此上下文将审查聚焦在变更区域，各 reviewer agent 无需独立发现变更范围
+3) **Triage**：preflight 后立即判断本 change 是否需要双审查：
    - 需要双审查的条件：改动涉及 REQUIREMENTS 真值、跨 3+ 文件、涉及安全/数据一致性、或准备 finish
-   - 若需要双审查：在步骤 3 开始时即标注 "dual-review: required"，并规划 spec-review + quality-review 两条并行路径
-    - 若不需要双审查：继续通用 review 流程，标注 "dual-review: not-required"
-    - **不得等到 step 6 才决定是否需要双审查**——风险判定必须前置
-   - **Triage 输出格式**：
-     ```
-     Triage: dual-review: required | not-required
-     Rationale: <one reason>
-     Spec review scope: <what to check> (if required)
-     Quality review scope: <what to check> (if required)
-     ```
-   - Findings 格式要求：每个 finding 必须有 [Critical/Warning/Info] 级别标签 + 归因到 SPEC/QUALITY/REGRESSION 类别
-3) 基于 `git status` / `git diff`（以及你实际运行过的测试结果），对照 `AI_PROJECT.md` 与 `REQUIREMENTS.md` 检查：
+   - 若需要双审查：在步骤 4 开始时即标注 "dual-review: required"，并规划 spec-review + quality-review 两条并行路径
+     - 若不需要双审查：继续通用 review 流程，标注 "dual-review: not-required"
+     - **不得等到 step 7 才决定是否需要双审查**——风险判定必须前置
+    - **Triage 输出格式**：
+      ```
+      Triage: dual-review: required | not-required
+      Rationale: <one reason>
+      Spec review scope: <what to check> (if required)
+      Quality review scope: <what to check> (if required)
+      ```
+    - Findings 格式要求：每个 finding 必须有 [Critical/Warning/Info] 级别标签 + 归因到 SPEC/QUALITY/REGRESSION 类别
+4) 基于 `git status` / `git diff`（以及你实际运行过的测试结果），对照 `AI_PROJECT.md` 与 `REQUIREMENTS.md` 检查：
    - 是否存在越界目录改动/危险操作
    - 是否有可复现验证命令与证据
    - 是否维护了 `.aiws/changes/<change-id>/` 或相关 `issues/*.csv`
    - 若存在 `analysis/` / `patches/`：审查这些委托工件是否已被主 agent 理解、是否需要采用/拒绝，并把结论写入 review 文件
-4) Workflow State Suffix 审计（检查 4 种后缀使用是否一致）：
+5) Workflow State Suffix 审计（检查 4 种后缀使用是否一致）：
    - `session` 后缀：只由 ws-dev-lite / ws-intake 写入，标记会话级进度（如 `[workflow-state:session:in_progress]`）
    - `gate` 后缀：由 ws-dev / ws-plan-verify 写入，标记计划/实现门禁结果（如 `[workflow-state:gate:plan_passed]`）
    - `plan` 后缀：由 ws-plan 写入，标记计划阶段状态（如 `[workflow-state:plan:in_progress]`）
    - `gateway` 后缀：由 ws-finish / ws-deliver 写入，标记交付门禁结果（如 `[workflow-state:gateway:finish_gate_ok]`）
    - 检查当前 change 中使用的后缀类型是否正确对应所在阶段；若出现混用（如 session 与 gate 在同一文件），在审计报告中标记异常并说明应该修正的方向。
-5) 将审计落盘到（目录不存在则创建）：
+6) 将审计落盘到（目录不存在则创建）：
    - 默认：`.aiws/changes/<change-id>/review/codex-review.md`
    - 回退：`.aiws/tmp/review/codex-review.md`（仅在无法确定 `change-id` 时使用）
    - 若已有其它 reviewer 文件：不要覆盖它们；当前 reviewer 应写自己的文件或更新自己的汇总文件
-6) 若 triage 标记为 `dual_review_required`，继续补齐 dual review gate：
+7) 若 triage 标记为 `dual_review_required`，继续补齐 dual review gate：
    - 运行/收敛 `$ws-spec-review`，落盘 `.aiws/changes/<change-id>/review/spec-review.md`（或回退 `.aiws/tmp/review/spec-review.md`）
    - 运行/收敛 `$ws-quality-review`，落盘 `.aiws/changes/<change-id>/review/quality-review.md`（或回退 `.aiws/tmp/review/quality-review.md`）
    - 不要把单个 `codex-review.md` 误当成 finish gate 已完成
-7) 回复中输出：
+8) 回复中输出：
    - `证据（Evidence）:` 证据文件路径
    - `主要风险（Top risks）:` 3–8 条（高→低）
    - `下一步（Next）:` 最小修复清单 + 最小验证命令
@@ -86,3 +90,5 @@ OpenCode + oMo 优先策略：
 - 不打印 secrets。
 - 不执行破坏性命令。
 - 若 oMo agent 不可用，回退为当前 agent 本地 review，不阻断流程。
+
+> 运行时行为约束：`packages/spec/docs/run-behavior-guidelines.md`

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

@@ -40,19 +40,23 @@ OpenCode + oMo 优先策略：
 步骤（建议）：
 1) 先运行 `$ws-preflight`。
    - 若检测到 oMo：优先让 `@oracle` 做 spec review 草稿；需要补规范上下文时再调用 `@librarian`。
-2) 对照 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md` 检查：
+2) **Change Scope Assessment**：在深入审查前，先获取变更上下文。
+   - 执行 `git diff --stat HEAD` 查看变更文件及行数
+   - 执行 `git log --oneline -3` 查看最近提交
+   - 使用此上下文将审查聚焦在变更区域，各 reviewer agent 无需独立发现变更范围
+3) 对照 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md` 检查：
    - 当前改动能否归因到 `Req_ID` / `Problem_ID`
    - `plan/...`、`proposal.md`、`tasks.md`、`evidence/` 是否与改动保持一致
    - 是否存在越界目录改动、危险操作、未声明的非目标扩张
    - 是否已经准备好可复现验证入口
-3) 把结论落盘到：
+4) 把结论落盘到：
    - 默认：`.aiws/changes/<change-id>/review/spec-review.md`
    - 回退：`.aiws/tmp/review/spec-review.md`
-4) 输出：
-   - `证据（Evidence）:`
-   - `阻断项（Blockers）:`
+5) 输出：
+   - `证据（Evidence）:` — 按严重级别处理：**BLOCKER/HIGH** 附完整证据链（归因/路径引用）；**WARNING** 仅给 1 行结论；**通过项** 不输出或仅 "✓ 通过"
+   - `阻断项（Blockers）:` requirements 归因 / gate / evidence 缺口
    - `警告（Warnings）:`
-   - `下一步（Next）:`
+   - `下一步（Next）:` 修复项与最小验证命令
 
 重点：
 - 这是 spec / gate review，不是代码质量 review。
@@ -62,3 +66,5 @@ OpenCode + oMo 优先策略：
 - 不打印 secrets。
 - 不执行破坏性命令。
 - 若 oMo agent 不可用，回退为当前 agent 本地 spec review。
+
+> 运行时行为约束：`packages/spec/docs/run-behavior-guidelines.md`