@aipper/aiws-spec 0.0.43 → 0.0.45

package/docs/ws-goal-contract.md

@@ -171,14 +171,25 @@ ws-goal 在执行 pipeline delegation（管道委托，见 1.§ 第四步）之
 ═══════════════════════
 ```
 
-#### 2.5.4 确认门禁
+#### 2.5.4 确认门禁（分级处理）
 
-报告输出后，必须等待用户确认：
+报告输出后，按影响等级分级处理：
+
+| 等级 | 行为 |
+|------|------|
+| **NONE** | 自动继续。发现项记录到 Audit Trail，不阻断 |
+| **LOW** | 自动继续。输出提示，发现项记录到 Audit Trail |
+| **MED** | 自动继续。输出警告信息，发现项记录到 Audit Trail |
+| **HIGH** | **阻断**。必须等待用户确认后才能继续 |
+
+**HIGH 阻断确认选项**：
 - **继续** → 进入 pipeline delegation
 - **暂停** → goal status=paused，报告写入 Audit Trail
 - **先清理** → goal status=paused，输出清理建议步骤
 
-用户未确认，不得进入 delegation。
+用户未确认 HIGH 阻断项，不得进入 delegation。
+
+> **设计原则**：LOW/MED 发现项不应阻断工作流。它们被记录到 Audit Trail 供后续回溯，但不需要用户停下当前工作。HIGH 发现项才是真正的风险门禁，必须有用户显式授权放行。
 
 ---
 
@@ -379,9 +390,50 @@ Auto-resume 时输出以下通知（含问题级进度展示，但不需要用
 2. 启发式判断已 frozen 问题：找到第一个未回答的问题标记，之前的都算 frozen
 3. 生成 state.json，status=in_progress
 
----
+#### 3.2.9 上下文感知 INTAKE（Context-Aware Intake）
+
+**问题**：用户可能在未使用 ws-goal 的情况下已经开始工作（如直接修 bug、做重构、编写代码）。此时执行 ws-goal，PHASE 0 INTAKE 从空白开始提问，用户需要重新陈述已做的工作，体验割裂。
+
+**方案**：PHASE 0 在开始对抗式审问前，先扫描工作区获取上下文信号，预填充 intake 的初始答案。
+
+**扫描信号**：
+
+| 信号 | 来源 | 可靠性 |
+|------|------|--------|
+| 未提交变更 | `git diff --stat` | 高（具体文件与改动量） |
+| 最近提交 | `git log --oneline -5` | 高（可反映近期工作主题） |
+| Change 分支 | `git branch --list 'change/*'` | 高（aiws 管理的分支） |
+| 孤立 intake 草稿 | `.aiws/plan/*.intake.md` | 高（aiws 工件） |
+| 进行中的 intake | `.aiws/intake/*.state.json` | 高（aiws 工件） |
+| 暂存的工作 | `git stash list` | 中（可能有无关的 stash） |
+
+**不使用的信号**：会话日志（短暂/有损）、lsp_diagnostics（与意图无关）。
+
+**退化处理**：非 git 目录下，所有 git 命令（`git diff --stat`、`git log`、`git branch --list`、`git stash list`）应检测并静默跳过，对应信号标记为 `unavailable`。扫描退化为仅依赖非 git 信号（孤立 intake 草稿、进行中的 intake state.json）。若全部信号均不可用，输出"未检测到现有工作上下文"，intake 从空白开始。
+
+**大篇幅截断**：`git diff --stat` 输出超过 20 行（约 20 个文件）时，截断为"`<N> files changed, <+M>/-R`"总计行，不再逐文件列出。完整 diff 可通过 `git diff --stat` 查看。`git log --oneline -5` 保持最多 5 条不变。
+
+**输出格式**：
+
+```text
+═══ 工作区上下文 ═══
+未提交改动: BizDeviceRepo.kt (+12 -0) — 修复 activeType 过滤
+最近提交:   "fix: device/pages filter activeType and deviceId"
+Change 分支: change/fix-auth (3 commits, 未合并)
+孤立 Intake: .aiws/plan/20240115-auth-intake.md (3/5 问题已冻结)
+════════════════════
+```
+
+**预填规则**：
 
-### 3.3 Evidence Type Registry
+1. 扫描输出作为上下文摘要，嵌入 intake 草案开头
+2. 对抗式审问的初始问题答案以此上下文预填（用户可见并可修改确认）
+3. 预填内容不影响 checkpoint 机制——所有 checkpoint 仍为 pending，不从预填内容推导阶段完成
+4. 工作区上下文扫描是 intake 阶段的内部实现细节，不影响外部协议接口（goal.md、state.json 格式不变）
+5. 若扫描无任何发现（空工作区），输出"未检测到现有工作上下文"，intake 从空白开始
+6. 预填的 intake 问题答案状态为 `prefill_pending`（非 `frozen`）。用户必须显式确认后状态才变为 `frozen`。此规则将"no checkpoint backfilling"原则延续到 intake 问题级：预填是初始提示（prompt），不从预填内容推导问题已冻结，不绕过用户的确认权。`.aiws/intake/<id>.state.json` 中问题 `status` 字段在预填状态下仍保持 `pending`，直到用户确认后才写入 `frozen`。
+
+**设计原则**：缩短用户输入成本，不改变审计完整性。上下文预填是提示（prompt）而非判断（judgment）——用户始终拥有最终确认权。
 
 完成审计使用的证据类型：
 
@@ -1030,6 +1082,14 @@ Instructions: Continue from the failed phase. Do NOT redo completed phases.
 
 当前协议依赖主 session 在 phase 完成后手动判断"已完成 phase X，现在开始 phase Y"。这个判断是纯机械的，每次都重复一样逻辑。Auto-Advance 将此机械工作自动化，减少阶段转换摩擦。
 
+**覆盖范围**：Auto-Advance 适用于完整 phase 生命周期，不仅限于 pipeline 内部的 PLAN→DEV→REVIEW→FINISH 阶段间推进。它同样适用于：
+- INTAKE → GOAL_DEF（intake 无 UNRESOLVED_BRANCH 时自动推进）
+- GOAL_DEF → DEP_CHECK（goal 定义完成后自动进入依赖链预检）
+- DEP_CHECK → WS_ANALYSIS（依赖链通过后自动进入工作区分析）
+- WS_ANALYSIS → PLAN（工作区分析无 HIGH 阻断项时自动进入 PLAN）
+
+唯一需要人工确认的 phase 转换：**当前 phase 存在真实阻断项时**（UNRESOLVED_BRANCH、依赖链 UNHEALTHY、工作区分析 HIGH、PLAN 多分支无明确推荐）。这些阻断必须由 §2.5.4、§2.4.3 或 §7.9.2 的规则产生，不得在无阻断时额外询问用户。
+
 #### 7.8.2 Mechanism
 
 使用基于 **state.json checkpoint 文件产出**的自动推进，不依赖文本标记（如 `PHASE_DONE` 字符串）：
@@ -1127,3 +1187,124 @@ Auto-Advance 在降级模式下仍然适用，但推进逻辑调整：
 - 全 goal 降级模式（§6.8.5）下，Auto-Advance 的 phase 序列变为：`intake → goal_def → dep_check → ws_analysis → plan → dev (degraded) → review → finish`
 
 **即**：降级模式改变的是*执行方式*（batch-edit vs delegation），不改变 checkpoint 状态机。Auto-Advance 不关心执行方式，只关心 checkpoint 状态。
+
+### 7.9 Structured Decision Support
+
+#### 7.9.1 Motivation
+
+某些决策点（如 PLAN 产出后的多分支选择）需要业务判断，不能完全自动化。但是，当前模式要求用户从原始计划产出中自行推导选项和权衡，认知负担高。
+
+**原则**：AI 做分析、结构化和建议，用户做决策。不在无阻断时提问，但在真正需要判断时提供预处理的选项。
+
+#### 7.9.2 触发条件
+
+结构化决策支持适用于以下场景：
+
+| 场景 | 产出物 | 说明 |
+|------|--------|------|
+| **PLAN 多分支选择** | PLAN 产出包含多个可行路径 | 如"Phase1&2 vs Phase3 vs 修 P0 stub" |
+| **修复方案选择** | 同一问题有多种修复方式 | 如"回滚 vs 热修复 vs 临时规避" |
+| **优先级排序** | 多个独立任务需决定执行顺序 | 如"先修高风险 bug vs 先加固测试" |
+
+#### 7.9.3 输出格式
+
+当出现多分支时，主 session 必须将选项格式化为结构化建议块：
+
+```text
+══════ 决策建议 ══════
+分支 A：<标题>
+  内容：<该分支包含的具体工作>
+  风险：<风险评估>
+  预估：<时间/工作量>
+  推荐理由：<何时选择此分支>
+
+分支 B：<标题>
+  内容：<该分支包含的具体工作>
+  风险：<风险评估>
+  预估：<时间/工作量>
+  推荐理由：<何时选择此分支>
+
+推荐：<分支 A/B/C 及理由>
+═══════════════════════
+```
+
+用户从选项中确认选择。仅在无明确推荐时（如各分支风险/收益相近）才需要用户主动分析。
+
+#### 7.9.4 与 Oracle 集成
+
+当 PLAN 产出包含多分支时，可委托 Oracle 分析各分支的代码级影响，生成结构化建议块：
+
+```
+PLAN 产出 → Oracle 读 PLAN + 代码扫描 + git 历史
+  → 分析各分支风险/工作量/依赖
+  → 输出结构化建议块（§7.9.3 格式）
+  → 主 session 呈现给用户
+```
+
+Oracle 的 role 是**决策支持**（decision support），不是**决策制定**（decision making）。用户始终拥有最终决策权。
+
+### 7.10 Oracle-Advisor Protocol Role
+
+#### 7.10.1 定义
+
+Oracle-Advisor 是一个可选的协议角色，用于在决策点提供分析支持。它不是一个独立的阶段或执行者，而是在主 session 编排中按需调用的**只读顾问**。
+
+#### 7.10.2 触发条件
+
+| 决策点 | 自动执行 | Oracle 参与模式 |
+|--------|---------|----------------|
+| Intake → Plan 转换 | ✅ 自动（无阻断时） | 无需 Oracle |
+| 工作区分析 LOW/MED | ✅ 自动（§2.5.4） | 无需 Oracle |
+| 工作区分析 HIGH | ❌ 用户确认 | Oracle 可辅助分析 HIGH 项是否可降级 |
+| 依赖链 UNHEALTHY | ❌ 用户确认（§2.4.3） | Oracle 可分析 UNHEALTHY 的实际影响范围 |
+| PLAN 多分支选择 | ❌ 用户决策（§7.9） | **Oracle 生成结构化建议块（§7.9.3）** |
+| 阶段间推进 | ✅ Auto-Advance（§7.8） | 无需 Oracle |
+
+#### 7.10.3 角色约束
+
+| 维度 | 约束 |
+|------|------|
+| **读取范围** | 仅当前决策点相关的工件（PLAN 产出、代码扫描片段、git 历史摘要）。不得读取未关联文件 |
+| **写入范围** | 仅写入 `changes/<id>/analysis/oracle-decision-<phase>.md` 或显示在会话输出中。不得修改任何代码/工件 |
+| **输出格式** | 必须包含：分析摘要、置信度信号、推荐选项及理由、升级路径 |
+| **不可访问时** | 降级为不依赖 Oracle 的建议，仍用 §7.9.3 格式输出（由主 session 直接生成结构化块） |
+
+#### 7.10.4 工件格式
+
+Oracle 的分析输出必须写入 `changes/<id>/analysis/oracle-decision-<phase>.md`：
+
+```markdown
+---
+oracle_advisor:
+  phase: <phase 名称>
+  triggered_at: <ISO 8601>
+  confidence: high | medium | low
+---
+
+## 分析摘要
+
+<5 行以内的分析总结>
+
+## 置信度信号
+
+| 信号 | 评估 | 说明 |
+|------|------|------|
+| 证据完整性 | high/medium/low | 所需工件是否齐全 |
+| 规范规则 | deterministic/ambiguous | 规范是否明确规定了行为 |
+| 业务依赖 | none/partial/critical | 决策是否需要业务上下文 |
+
+## 推荐选项
+
+<结构化建议块，见 §7.9.3>
+
+## 升级路径
+
+<如果 confidence=medium 或 low，说明什么条件下应升级到用户>
+```
+
+#### 7.10.5 与 §7.8 Auto-Advance 的关系
+
+- Auto-Advance 负责**机械性 phase 推进**（无分支、无阻断时自动走）
+- Oracle-Advisor 负责**决策点分析**（有分支或阻断时提供结构化建议）
+- 两者不重叠：Auto-Advance 在无阻断时自动推进；Oracle-Advisor 在决策点提供信息支持
+- Oracle-Advisor 分析完成后，主 session 或用户做出最终决定，然后 Auto-Advance 继续推进

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aipper/aiws-spec",
-  "version": "0.0.43",
+  "version": "0.0.45",
   "description": "AIWS spec and templates (single source of truth).",
   "type": "module",
   "files": [

package/templates/workspace/.opencode/command/ws-bugfix.md

@@ -13,8 +13,8 @@ description: 缺陷修复：禅道 MCP 拉单、图片证据落盘并汇总 fix_
 1) 先运行 `/ws-preflight`。
 2) 若当前不在 `change/<change-id>` 分支 / worktree，先建立 change 上下文：
    - 工作区先保持干净
-   - 仓库已有提交：优先 `aiws change start <change-id> --hooks --worktree`
-   - superproject + submodule：优先 `aiws change start <change-id> --hooks --worktree --submodules`
+   - 仓库已有提交：优先 `aiws change start <change-id> --hooks --switch`
+   - superproject + submodule：优先 `aiws change start <change-id> --hooks --switch`
    - 仓库尚无提交 / 不满足 worktree 前置条件：回退 `aiws change start <change-id> --hooks --no-switch`
 3) 若上一步创建了 worktree：后续 bug 证据、CSV 更新、`/ws-dev` 修复都必须在该 worktree 中继续。
 4) 通过已配置 zentao MCP 拉取 bug 字段与附件列表。

package/templates/workspace/.opencode/command/ws-dev.md

@@ -14,11 +14,11 @@ description: 开发：在 AIWS 约束下完成小步交付
 2) 建立变更归因（推荐）：
    - ⚠️ 若准备切分支/创建 worktree，先看 `git status --porcelain`；否则切换上下文后，未提交改动可能“看起来丢了”。
    - 若当前目录已经是 `change/<change-id>` worktree（例如由 `/ws-plan` 创建）：直接在这里继续，不要再创建第二个 worktree，也不要回原工作区写代码。
-   - 若非空仅因为 `/ws-plan` 生成了 `plan/...` 或 `changes/<change-id>/...`，这是预期行为；此时优先 `aiws change start <change-id> --hooks --no-switch`，若仍要 `--switch/--worktree`，先提交这些规划工件。
+   - 若非空仅因为 `/ws-plan` 生成了 `plan/...` 或 `changes/<change-id>/...`，这是预期行为；此时优先 `aiws change start <change-id> --hooks --no-switch`，若仍要 `--switch`，先提交这些规划工件。
    - 推荐更安全（默认）：`aiws change start <change-id> --hooks --no-switch`（只创建分支/工件 + 启用 hooks；不切分支）
    - 准备进入实现时：若当前已在 `change/<change-id>` 直接继续；若需切换到该分支，先确认除规划工件外无额外未提交改动，再执行：`git switch change/<change-id>`
    - 若你明确要“一键切分支”（不推荐，且 dirty 会被拦截）：`aiws change start <change-id> --hooks --switch`
-   - superproject + submodule（推荐）：`aiws change start <change-id> --hooks --worktree --submodules`
+   - superproject + submodule（推荐）：`aiws change start <change-id> --hooks --switch`
    - 若后续需要在 detached submodule 内提交：先挂到 `aiws/pin/<target-branch>`；不要直接切 `change/<change-id>` / `main` / `master`
    - 或手工：`git switch -c change/<change-id>`，并创建 `changes/<change-id>/proposal.md` 与 `changes/<change-id>/tasks.md`（参考 `changes/README.md`）
 3) 如涉及需求调整：先 `/ws-req-review` → 用户确认后再 `/ws-req-change`（避免需求漂移）。

package/templates/workspace/.opencode/command/ws-plan.md

@@ -14,7 +14,7 @@ description: 规划：生成可落盘 plan 工件
    - 若检测到 `.opencode/oh-my-opencode.json` 或当前会话明确可用 `planner-sisyphus` / `explore` / `librarian`：优先按 `packages/spec/docs/opencode-omo-adapter.md` 借用这些 agent。
    - 计划主框架优先 `planner-sisyphus`；结构探索优先 `@explore`；规范/文档查证优先 `@librarian`。
 2) 若当前不在 `change/<change-id>` 分支 / worktree，先调用 `aiws change start <change-id>` 建立上下文：
-   - 仓库已有提交：优先 `aiws change start <change-id> --hooks --worktree`；若声明了 submodules，加 `--submodules`
+   - 仓库已有提交：优先 `aiws change start <change-id> --hooks --switch`
    - 仓库尚无提交 / 不满足 worktree 前置条件：回退 `aiws change start <change-id> --hooks --no-switch`
 3) 若上一步创建了 worktree：切到输出的 `worktree:` 路径，后续所有计划文件都写在该 worktree 中。
 4) 生成或更新计划文件：`plan/YYYY-MM-DD_HH-MM-SS-<slug>.md`。

package/templates/workspace/.opencode/commands/ws-bugfix.md

@@ -13,8 +13,8 @@ description: 缺陷修复：禅道 MCP 拉单、图片证据落盘并汇总 fix_
 1) 先运行 `/ws-preflight`。
 2) 若当前不在 `change/<change-id>` 分支 / worktree，先建立 change 上下文：
    - 工作区先保持干净
-   - 仓库已有提交：优先 `aiws change start <change-id> --hooks --worktree`
-   - superproject + submodule：优先 `aiws change start <change-id> --hooks --worktree --submodules`
+   - 仓库已有提交：优先 `aiws change start <change-id> --hooks --switch`
+   - superproject + submodule：优先 `aiws change start <change-id> --hooks --switch`
    - 仓库尚无提交 / 不满足 worktree 前置条件：回退 `aiws change start <change-id> --hooks --no-switch`
 3) 若上一步创建了 worktree：后续 bug 证据、CSV 更新、`/ws-dev` 修复都必须在该 worktree 中继续。
 4) 通过已配置 zentao MCP 拉取 bug 字段与附件列表。

package/templates/workspace/.opencode/commands/ws-dev.md

@@ -14,11 +14,11 @@ description: 开发：在 AIWS 约束下完成小步交付
 2) 建立变更归因（推荐）：
    - ⚠️ 若准备切分支/创建 worktree，先看 `git status --porcelain`；否则切换上下文后，未提交改动可能“看起来丢了”。
    - 若当前目录已经是 `change/<change-id>` worktree（例如由 `/ws-plan` 创建）：直接在这里继续，不要再创建第二个 worktree，也不要回原工作区写代码。
-   - 若非空仅因为 `/ws-plan` 生成了 `plan/...` 或 `changes/<change-id>/...`，这是预期行为；此时优先 `aiws change start <change-id> --hooks --no-switch`，若仍要 `--switch/--worktree`，先提交这些规划工件。
+   - 若非空仅因为 `/ws-plan` 生成了 `plan/...` 或 `changes/<change-id>/...`，这是预期行为；此时优先 `aiws change start <change-id> --hooks --no-switch`，若仍要 `--switch`，先提交这些规划工件。
    - 推荐更安全（默认）：`aiws change start <change-id> --hooks --no-switch`（只创建分支/工件 + 启用 hooks；不切分支）
    - 准备进入实现时：若当前已在 `change/<change-id>` 直接继续；若需切换到该分支，先确认除规划工件外无额外未提交改动，再执行：`git switch change/<change-id>`
    - 若你明确要“一键切分支”（不推荐，且 dirty 会被拦截）：`aiws change start <change-id> --hooks --switch`
-   - superproject + submodule（推荐）：`aiws change start <change-id> --hooks --worktree --submodules`
+   - superproject + submodule（推荐）：`aiws change start <change-id> --hooks --switch`
    - 若后续需要在 detached submodule 内提交：先挂到 `aiws/pin/<target-branch>`；不要直接切 `change/<change-id>` / `main` / `master`
    - 或手工：`git switch -c change/<change-id>`，并创建 `changes/<change-id>/proposal.md` 与 `changes/<change-id>/tasks.md`（参考 `changes/README.md`）
 3) 如涉及需求调整：先 `/ws-req-review` → 用户确认后再 `/ws-req-change`（避免需求漂移）。

package/templates/workspace/.opencode/commands/ws-plan.md

@@ -14,7 +14,7 @@ description: 规划：生成可落盘 plan 工件
    - 若检测到 `.opencode/oh-my-opencode.json` 或当前会话明确可用 `planner-sisyphus` / `explore` / `librarian`：优先按 `packages/spec/docs/opencode-omo-adapter.md` 借用这些 agent。
    - 计划主框架优先 `planner-sisyphus`；结构探索优先 `@explore`；规范/文档查证优先 `@librarian`。
 2) 若当前不在 `change/<change-id>` 分支 / worktree，先调用 `aiws change start <change-id>` 建立上下文：
-   - 仓库已有提交：优先 `aiws change start <change-id> --hooks --worktree`；若声明了 submodules，加 `--submodules`
+   - 仓库已有提交：优先 `aiws change start <change-id> --hooks --switch`
    - 仓库尚无提交 / 不满足 worktree 前置条件：回退 `aiws change start <change-id> --hooks --no-switch`
 3) 若上一步创建了 worktree：切到输出的 `worktree:` 路径，后续所有计划文件都写在该 worktree 中。
 4) 生成或更新计划文件：`plan/YYYY-MM-DD_HH-MM-SS-<slug>.md`。

package/templates/workspace/.opencode/scripts/ws-plan-setup-worktree.sh

@@ -22,9 +22,9 @@ fi
 
 if [[ "${has_commits}" -eq 1 ]]; then
   if [[ "${has_submodules}" -eq 1 ]]; then
-    aiws change start "${change_id}" --hooks --worktree --submodules
+    aiws change start "${change_id}" --hooks --switch
   else
-    aiws change start "${change_id}" --hooks --worktree
+    aiws change start "${change_id}" --hooks --switch
   fi
 else
   aiws change start "${change_id}" --hooks --no-switch

package/templates/workspace/.opencode/skills/p-aiws-change-start/SKILL.md

@@ -5,7 +5,7 @@ description: 私有：切分支并初始化变更工件（可选安装 hooks）
 
 目标：
 - 切到分支 `change/<change-id>` 并初始化 `.aiws/changes/<change-id>/` 工件
-  - 若检测到 `.gitmodules`（git submodules），默认优先使用 `--worktree`（失败则回退为 `--no-switch`），避免切走 superproject 分支导致 submodule 状态混乱
+  - 若检测到 `.gitmodules`（git submodules），默认使用 `--no-switch` 避免切走 superproject 分支导致 submodule 状态混乱；传 `--switch` 可强制切换
 
 要求：
 - 需要 git 仓库；若不是 git 仓库先 `git init`
@@ -26,8 +26,6 @@ fi
 - `--hooks`：同时执行 `aiws hooks install .`
 - `--title <title>`：写入标题
 - `--no-design`：不生成 design.md
-- `--switch`：显式允许切换 superproject 分支（仅在存在 `.gitmodules` 时有意义）
+- `--switch`：显式切换 superproject 分支（默认存在 `.gitmodules` 时不切换，传此参数强制切换）
 - `--no-switch`：不切换当前分支（仅确保 `change/<change-id>` 分支存在并初始化工件）；适用于 superproject + submodule 场景
-- `--worktree`：用 `git worktree` 创建独立工作区并在其中 checkout `change/<change-id>`（推荐用于 superproject + submodule）
-  - `--worktree-dir <path>`：覆盖 worktree 目录
-  - `--submodules`：在 worktree 内执行 `git submodule update --init --recursive`
+- `--allow-dirty`：允许 dirty 工作区执行 start（不推荐）

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

@@ -24,11 +24,11 @@ description: 使用时机：从禅道/外部系统拉取 bug 进行修复时。
        echo "error: dirty before ws-bugfix"; exit 2
      fi
      if git rev-parse --verify HEAD >/dev/null 2>&1; then
-       if [[ -f .gitmodules ]] && git config --file .gitmodules --get-regexp '^submodule\..*\.path$' >/dev/null 2>&1; then
-         aiws change start <change-id> --hooks --worktree --submodules
-       else
-         aiws change start <change-id> --hooks --worktree
-       fi
+      if [[ -f .gitmodules ]] && git config --file .gitmodules --get-regexp '^submodule\..*\.path$' >/dev/null 2>&1; then
+        aiws change start <change-id> --hooks --switch
+      else
+        aiws change start <change-id> --hooks --switch
+      fi
      else
        aiws change start <change-id> --hooks --no-switch
      fi

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

@@ -62,7 +62,7 @@ description: 使用时机：需要修改代码、配置、测试时。触发词
 - `git status --porcelain` 仅有计划/工件文件 → 继续
 - 创建新 change：`aiws change start <change-id> --hooks --no-switch`
 - 切换分支：先确认无未提交改动，再 `git switch change/<change-id>`
-- 有 submodule：准备好 `submodules.targets`（`--submodules` 标志自动处理）
+- 有 submodule：准备好 `submodules.targets`（`aiws change start` 自动检测 `.gitmodules`）
 
 ### 3. 实现策略：默认 dispatch aiws-worker（Subagent-First）
 

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

@@ -44,26 +44,48 @@ ws-goal 不做的事：
         v. 若用户选择全量重跑 → 重置 state.json 所有 checkpoints 为 pending，status=active，从头开始
    c) 若未找到 state.json 但有 status=active 或 status=paused 的 .md 文件（旧格式迁移）：
       - 按 §7.6 迁移策略处理（自动生成 state.json 后全量重跑）
-1) 读取真值文件（`AI_PROJECT.md`、`REQUIREMENTS.md`、`AI_WORKSPACE.md`），确认项目规则与边界。
-2) **运行改进后的 `/ws-intake`**（对抗式审问模式）对 goal objective 做逐条审问：
+1) **工作区上下文扫描（Context-Aware Intake）**：在开始 intake 问题前，先扫描工作区获取已有工作的上下文信号，用于预填充 intake 的初始问题答案：
+   - `git diff --stat`（未暂存的改动文件列表）
+   - `git log --oneline -5`（最近提交记录）
+   - `git branch --list 'change/*'`（已有 change 分支及状态）
+   - `git stash list`（暂存的工作）
+   - `.aiws/plan/*.intake.md`（孤立 intake 草稿）
+   - `.aiws/intake/*.state.json`（进行中的 intake）
+   - 扫描结果输出为压缩的上下文摘要：
+
+```text
+═══ 工作区上下文 ═══
+未提交改动: BizDeviceRepo.kt (+12 -0) — 修复 activeType 过滤
+最近提交:   "fix: device/pages filter activeType and deviceId"
+Change 分支: change/fix-auth (3 commits, 未合并)
+孤立 Intake: .aiws/plan/20240115-auth-intake.md (3/5 问题已冻结)
+════════════════════
+```
+
+2) 将扫描到的上下文传递给下一步的 intake 对抗式审问，作为初始问题答案的预填参考。用户可见预填内容并可修改确认。
+
+3) **运行改进后的 `/ws-intake`**（对抗式审问模式）对 goal objective 做逐条审问：
+   - 步骤 1 扫描的上下文自动作为 intake 问题的预填答案（用户可见并可修改）
    - 推荐答案模式：对事实类/选择类问题先给出推荐（参考 `recommendAnswers` 配置）
    - 决策树分支遍历：每条回答展开对应子分支，直到所有叶节点被消费
    - 对抗式审问层：自动探查代码库寻找矛盾信号，挑战隐含假设，探测边缘案例
-3) **产出 intake 草案**：写入 `plan/<timestamp>-<slug>.intake.md`，包含完整的决策树遍历记录
-4) **阻塞检查**：若 intake 草案中存在 `UNRESOLVED_BRANCH`，输出阻塞报告并暂停。用户必须显式确认忽略或补充信息后才能进入 PHASE 1。
-5) 将 intake 审问结果（已冻结的目标范围、约束、边界）传递到后续 goal objective 定义。
-5a) **记录 checkpoint**：更新 `.aiws/goals/<goal-id>.state.json` → checkpoint `intake=complete` + `completed_at`
+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`
+
+> **Auto-Advance**：若步骤 5 无 UNRESOLVED_BRANCH，步骤 6→6a→PHASE 1 自动推进，不需询问用户确认。参见 §7.8。
 
 ### PHASE 1 — GOAL 定义
 
-6) 接受用户输入的 goal objective，明确目标范围与验收标准（基于 PHASE 0 的 intake 产出）。
-7) 按 ws-goal-contract.md 的目标模板生成目标文件，写入 `.aiws/goals/<goal-id>.md`。
-7a) 同时创建 `.aiws/goals/<goal-id>.state.json`（§7.2 格式），初始状态：
+7) 接受用户输入的 goal objective，明确目标范围与验收标准（基于 PHASE 0 的 intake 产出）。
+8) 按 ws-goal-contract.md 的目标模板生成目标文件，写入 `.aiws/goals/<goal-id>.md`。
+8a) 同时创建 `.aiws/goals/<goal-id>.state.json`（§7.2 格式），初始状态：
     - `status`: "active"
     - `current_phase`: "intake"
     - 所有 checkpoints: `{"status": "pending", "attempts": 0, "completed_at": null, "error": null}`
-8) 输出 completion audit checklist，列出每个 goal 的完成标准与验证方式。
-8a) **记录 checkpoint**：更新 `.aiws/goals/<goal-id>.state.json` → checkpoint `goal_def=complete` + `completed_at`
+9) 输出 completion audit checklist，列出每个 goal 的完成标准与验证方式。
+9a) **记录 checkpoint**：更新 `.aiws/goals/<goal-id>.state.json` → checkpoint `goal_def=complete` + `completed_at`
 
 ### PHASE 2 — 预检与管道委托
 
@@ -74,16 +96,31 @@ ws-goal 不做的事：
   - 失败 → checkpoint `status=failed` + `error=<message>`
   - 暂停 goal → `status=paused`（全局）
 
-8b) **依赖链预检**：按 ws-goal-contract.md §2.4 执行上游依赖链健康检查。
+10) **依赖链预检**：按 ws-goal-contract.md §2.4 执行上游依赖链健康检查。
     - 通过后：更新 checkpoint `dep_check=complete`
     - 阻断时：更新 state.json `status=paused`，记录 error，结束
 
-9) **Workspace State Analysis**：分析 dirty/submodule/change artifacts/git 状态，输出影响等级报告，用户确认后才能继续。参考 `/ws-goal` command 的 step 4.5 完整流程。
+11) **Workspace State Analysis**：分析 dirty/submodule/change artifacts/git 状态，输出分级影响报告。按 §2.5.4 分级处理：
+   - NONE/LOW → 自动继续，记录到 Audit Trail
+   - MED → 自动继续，输出警告
+   - **HIGH** → 阻断，必须等待用户确认后才能继续
    - 通过后：更新 checkpoint `ws_analysis=complete`
-10) **Phase-Level Pipeline Delegation**：预检 + 分析通过后，将 goal 拆分为 PLAN→DEV→REVIEW→FINISH 四个 phase 顺序执行，每个 phase 委托给独立轻量子 agent，主 session 验证每个 phase 产出后决定继续/重试/暂停。参考 `/ws-goal` command 的 step 5 完整流程。
+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`
      - 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`
+
+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 协议。仅以下情况需要人工确认：
+     - INTAKE 阶段存在 UNRESOLVED_BRANCH（步骤 4）
+     - 工作区分析存在 HIGH 阻断项（步骤 11）
+     - 依赖链 UNHEALTHY（步骤 10）
+     - PLAN 存在多分支需用户选择（步骤 13）
+     除此之外的 phase 边界自动推进，不需要询问用户。

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

@@ -105,6 +105,6 @@ oMo 回退：
 输出要求：
 - `Plan file:` <实际写入的路径>
 - `Change context:` <当前 change 分支或 worktree 路径；若新建了 worktree 需明确写出>
-- `Next:` 推荐下一步（先 `$ws-plan-verify`，通过后再 `$ws-dev`；或 `aiws change start <change-id> --hooks`，superproject + submodule 可用 `--worktree`）
+- `Next:` 推荐下一步（先 `$ws-plan-verify`，通过后再 `$ws-dev`；或 `aiws change start <change-id> --hooks`，superproject + submodule 可用 `--switch`）
 
 > 运行时行为约束：`packages/spec/docs/run-behavior-guidelines.md`