@aipper/aiws-spec 0.0.27 → 0.0.29

package/docs/workflow-governance-rules.schema.json

@@ -1,9 +1,47 @@
 {
   "type": "object",
-  "required": ["version", "description", "governanceRules", "guidanceRules"],
+  "required": ["version", "description", "workflowStateSuffix", "stateEnum", "governanceRules", "guidanceRules"],
   "properties": {
     "version": { "type": "integer" },
     "description": { "type": "string", "minLength": 1 },
+    "workflowStateSuffix": {
+      "type": "object",
+      "required": ["description", "values", "stateSuffixMap"],
+      "properties": {
+        "description": { "type": "string", "minLength": 1 },
+        "values": {
+          "type": "array",
+          "minItems": 6,
+          "items": { "type": "string", "pattern": "^(intake|planning|dev|review|deliver|completed)$" }
+        },
+        "stateSuffixMap": {
+          "type": "object",
+          "minProperties": 6,
+          "additionalProperties": { "type": "string", "pattern": "^\\[workflow-state:session:[a-z]+\\]$" }
+        }
+      },
+      "additionalProperties": false
+    },
+    "stateEnum": {
+      "type": "object",
+      "required": ["values", "stageMapping"],
+      "properties": {
+        "values": {
+          "type": "array",
+          "minItems": 6,
+          "items": { "type": "string", "pattern": "^(intake|planning|dev|review|deliver|completed)$" }
+        },
+        "stageMapping": {
+          "type": "object",
+          "minProperties": 6,
+          "additionalProperties": {
+            "type": "array",
+            "items": { "type": "string" }
+          }
+        }
+      },
+      "additionalProperties": false
+    },
     "governanceRules": {
       "type": "array",
       "minItems": 1,

package/docs/workflow-router-rules.json

@@ -16,7 +16,7 @@
     "kind": "skill",
     "summary": "默认 workflow bootstrap/router：先读真值，再把任务路由到正确的 `ws-*` 入口。",
     "outputContract": [
-      "Root / Found / Missing",
+      "Root / Found / Missing / Intent status",
       "Task intent / Binding status / Route",
       "Why / Next"
     ]
@@ -32,6 +32,11 @@
       "action": "判断当前任务是在做需求变更、实现、评审、收尾还是交接。",
       "why": "先判 workflow，再决定进入哪个 skill；不能一开始就跳进实现。"
     },
+    {
+      "step": "check_intent_freeze",
+      "action": "判断需求是否已经冻结；若存在多条待确认问题或需要多轮沟通，先进入 intake 阶段。",
+      "why": "中大型需求在计划前往往需要多轮澄清；router 应该先把问题冻结，而不是把沟通负担全部塞给 `ws-plan`。"
+    },
     {
       "step": "check_binding",
       "action": "检查任务是否具备 `Req_ID` / `Problem_ID` / change 上下文 / Verify 入口等最小绑定。",
@@ -60,6 +65,14 @@
       "gate": "必须先问 1-3 个关键澄清问题，然后停止。",
       "rationale": "router 的职责是阻断模糊任务，而不是用猜测替代路由。"
     },
+    {
+      "id": "needs_intake",
+      "intent": "需求存在多条待确认问题，尚未冻结",
+      "match": "任务是新需求或中大型变更；目标方向大致明确，但存在多条待确认问题、需要逐条沟通，或用户明确要求先多轮澄清再进入计划。",
+      "routeTo": "ws-intake",
+      "gate": "先逐条澄清并冻结结论；未形成 intake 草案前不进入 `ws-plan`。",
+      "rationale": "`ws-intake` 负责把多轮需求沟通收敛为轻量草案，避免 `ws-plan` 同时承担反复澄清与正式计划落盘。"
+    },
     {
       "id": "requirements_change",
       "intent": "需求/验收/合同变更",
@@ -79,7 +92,7 @@
     {
       "id": "finish_request",
       "intent": "收尾/合并/推送/cleanup",
-      "match": "用户要求 finish、merge、push、收尾、交付完成、清理 worktree 或 branch。",
+      "match": "用户要求 finish、merge、push、收尾、交付完成、清理 change 分支。",
       "routeTo": "ws-finish",
       "gate": "必须满足 finish gate，不能跳过 validate / push / cleanup。",
       "rationale": "finish 是独立治理阶段，不能与普通实现混用。"
@@ -95,10 +108,10 @@
     {
       "id": "plan_first",
       "intent": "中大型实现或需要建立 change 上下文",
-      "match": "任务是多步实现、跨文件、跨模块、需要方案、需要新建 change/worktree，或当前还没有计划工件。",
+      "match": "任务是多步实现、跨文件、跨模块、需要方案、需要新建 change 分支，且需求已经冻结或已有可消费的 intake 草案。",
       "routeTo": "ws-plan",
       "gate": "plan 过 gate 前不进入 `ws-dev`。",
-      "rationale": "medium/complex 任务必须先生成可落盘计划，避免 router 直接跳进实现。"
+      "rationale": "medium/complex 任务在需求冻结后必须先生成可落盘计划，避免 router 直接跳进实现。"
     },
     {
       "id": "direct_implementation",
@@ -107,6 +120,22 @@
       "routeTo": "ws-dev",
       "gate": "若执行中发现复杂度升高，必须回退到 `ws-plan`。",
       "rationale": "router 允许明确的小步任务直接实现，但必须保留回退计划阶段的门；若用户明确要走轻量入口，可在实现阶段显式使用 `ws-dev-lite` 作为 `ws-dev` 的 facade。"
+    },
+    {
+      "id": "design_first",
+      "intent": "需要先出设计方案",
+      "match": "任务涉及新流程、新模块、新架构或对现有架构有显著影响的方向决策，需要先出设计方案再进入实现。",
+      "routeTo": "ws-design",
+      "gate": "design 未完成 review 前，不进入 `ws-plan`。",
+      "rationale": "复杂或高影响改动应先出设计方案，让设计过审后再投入实现，避免返工。"
+    },
+    {
+      "id": "spec_update",
+      "intent": "需要更新规范/文档/验收标准",
+      "match": "任务涉及更新 AI_PROJECT.md、REQUIREMENTS.md、AI_WORKSPACE.md 中的规范说明、验收标准或 contract 文档。",
+      "routeTo": "ws-spec-update",
+      "gate": "spec 更新必须先过 review，再同步到真值文件。",
+      "rationale": "规范更新与功能变更不同，router 应优先引导到 spec 维护链而非直接实现。"
     }
   ],
   "routeCases": [
@@ -126,6 +155,14 @@
       "expectedRoute": "clarify",
       "why": "这种场景必须先澄清意图和绑定，不能猜测实现。"
     },
+    {
+      "id": "case_needs_intake",
+      "scenario": "任务方向大致明确，但存在多条待确认问题，需要逐条沟通后再计划。",
+      "request": "做一个新的 change intake 流程，我想先一条一条把需求和边界聊清楚，再进入正式计划。",
+      "expectedRuleId": "needs_intake",
+      "expectedRoute": "ws-intake",
+      "why": "这类需求不是完全不清晰，但还没有冻结，适合先走 intake。"
+    },
     {
       "id": "case_requirements_change",
       "scenario": "任务要修改 REQUIREMENTS、requirements CSV 或 workflow 真值。",
@@ -145,7 +182,7 @@
     {
       "id": "case_finish_request",
       "scenario": "用户要求合并、push、cleanup 或 finish 当前 change。",
-      "request": "把 demo-change finish 掉并 push，顺便 cleanup worktree。",
+      "request": "把 demo-change finish 掉并 push，顺便 cleanup。",
       "expectedRuleId": "finish_request",
       "expectedRoute": "ws-finish",
       "why": "finish 是独立治理阶段，必须先走 finish gate。"
@@ -160,7 +197,7 @@
     },
     {
       "id": "case_plan_first",
-      "scenario": "任务是跨文件、多步实现，且需要先建立 change/worktree 或方案。",
+      "scenario": "任务是跨文件、多步实现，且需要先建立 change 分支或方案。",
       "request": "实现 dashboard 的阶段治理视图并补测试，需要新建 change 和计划。",
       "expectedRuleId": "plan_first",
       "expectedRoute": "ws-plan",
@@ -173,19 +210,37 @@
       "expectedRuleId": "direct_implementation",
       "expectedRoute": "ws-dev",
       "why": "小步明确实现允许直接进入 dev；若用户明确要轻量直修，可进一步显式使用 ws-dev-lite，但治理归属仍收敛到 ws-dev。"
+    },
+    {
+      "id": "case_design_first",
+      "scenario": "任务需要先出设计方案再进入实现。",
+      "request": "设计 dashboard 架构，出方案后再实现。",
+      "expectedRuleId": "design_first",
+      "expectedRoute": "ws-design",
+      "why": "高影响改动应先出设计方案，过审后再投入实现。"
+    },
+    {
+      "id": "case_spec_update",
+      "scenario": "任务涉及更新规范或验收标准文档。",
+      "request": "更新 AI_WORKSPACE.md 中的验证命令说明。",
+      "expectedRuleId": "spec_update",
+      "expectedRoute": "ws-spec-update",
+      "why": "规范更新应先走 spec 维护链，直接实现会绕过 review 门禁。"
     }
   ],
   "clarificationTriggers": [
     "用户只说“继续”“优化一下”“看一下”，但没有明确目标对象或当前阶段。",
     "无法把任务绑定到 `Req_ID` / `Problem_ID` / change 上下文。",
     "没有可复现验证入口，且无法从 `AI_WORKSPACE.md` 推断。",
-    "当前描述同时包含需求变更、实现和收尾，但没有明确优先级。"
+    "当前描述同时包含需求变更、实现和收尾，但没有明确优先级。",
+    "同一个任务包含多条待确认问题，且用户希望逐条、多轮沟通。"
   ],
   "universalRules": [
     "router 自己不是实现阶段；先判定 workflow，再进入具体 `ws-*` skill。",
     "除缺失真值场景外，router 至少要给出一个明确的 `Route:` 结果或明确的澄清问题。",
     "当 `routeTo=clarify` 时，必须停止，不直接写代码。",
-    "当 `routeTo=ws-plan` / `ws-dev` / `ws-review` / `ws-finish` / `ws-handoff` / `ws-req-review` 时，后续行为必须遵循对应 skill 契约。",
+    "当 `routeTo=ws-intake` 时，必须先逐条冻结问题并产出 intake 草案；不要跳过到 `ws-plan`。",
+    "当 `routeTo=ws-plan` / `ws-dev` / `ws-review` / `ws-finish` / `ws-handoff` / `ws-req-review` / `ws-intake` 时，后续行为必须遵循对应 skill 契约。",
     "任何 route 都不能绕过 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`。"
   ],
   "notes": [

package/docs/workflow-router-rules.md

@@ -22,7 +22,7 @@ router 在做任何 workflow 判断前，必须先读取：
 - kind: `skill`
 - summary: 默认 workflow bootstrap/router：先读真值，再把任务路由到正确的 `ws-*` 入口。
 - output contract:
-  - Root / Found / Missing
+  - Root / Found / Missing / Intent status
   - Task intent / Binding status / Route
   - Why / Next
 
@@ -32,6 +32,7 @@ router 在做任何 workflow 判断前，必须先读取：
 | --- | --- | --- |
 | `read_truths` | 先定位项目根，并读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`。 | router 不能绕过真值文件，否则会把 workflow 判断建立在会话猜测上。 |
 | `classify_intent` | 判断当前任务是在做需求变更、实现、评审、收尾还是交接。 | 先判 workflow，再决定进入哪个 skill；不能一开始就跳进实现。 |
+| `check_intent_freeze` | 判断需求是否已经冻结；若存在多条待确认问题或需要多轮沟通，先进入 intake 阶段。 | 中大型需求在计划前往往需要多轮澄清；router 应该先把问题冻结，而不是把沟通负担全部塞给 `ws-plan`。 |
 | `check_binding` | 检查任务是否具备 `Req_ID` / `Problem_ID` / change 上下文 / Verify 入口等最小绑定。 | 缺失绑定时必须阻断或回退到 `ws-plan`，避免无归因实现。 |
 | `route_or_clarify` | 给出单一路由结果；若意图不明确，则先问关键澄清问题并停止。 | default-routed workflow 的关键不是自动执行，而是避免模糊任务直接进入实现。 |
 
@@ -41,12 +42,15 @@ router 在做任何 workflow 判断前，必须先读取：
 | --- | --- | --- | --- | --- | --- |
 | `missing_truths` | 仓库未初始化或真值缺失 | 缺失任一真值文件，或无法确定项目根目录。 | `ws-preflight` | 先补齐真值或确认项目根，不进入实现。 | 所有后续 skill 都依赖真值文件；缺失时 router 只能回退到 preflight/init 路径。 |
 | `unclear_intent` | 用户目标、归因或验收不清晰 | 无法明确当前是需求变更、实现、评审、finish 还是 handoff；或无法明确 `Req_ID` / `Problem_ID` / Verify。 | `clarify` | 必须先问 1-3 个关键澄清问题，然后停止。 | router 的职责是阻断模糊任务，而不是用猜测替代路由。 |
+| `needs_intake` | 需求存在多条待确认问题，尚未冻结 | 任务是新需求或中大型变更；目标方向大致明确，但存在多条待确认问题、需要逐条沟通，或用户明确要求先多轮澄清再进入计划。 | `ws-intake` | 先逐条澄清并冻结结论；未形成 intake 草案前不进入 `ws-plan`。 | `ws-intake` 负责把多轮需求沟通收敛为轻量草案，避免 `ws-plan` 同时承担反复澄清与正式计划落盘。 |
 | `requirements_change` | 需求/验收/合同变更 | 任务涉及 `REQUIREMENTS.md`、requirements CSV、spec contract、验收标准或 workflow 真值变更。 | `ws-req-review` | 先做需求评审，再决定是否进入 `ws-plan` / `ws-dev`。 | 需求真值变更必须先过 review，不能直接编码。 |
 | `review_request` | 审计/评审/找风险 | 用户明确要求 review、audit、评审、找 bug、识别风险或检查回归。 | `ws-review` | 先给 findings；除非用户另行要求，不先改代码。 | 评审任务与实现任务的输出契约不同，必须优先走 review。 |
-| `finish_request` | 收尾/合并/推送/cleanup | 用户要求 finish、merge、push、收尾、交付完成、清理 worktree 或 branch。 | `ws-finish` | 必须满足 finish gate，不能跳过 validate / push / cleanup。 | finish 是独立治理阶段，不能与普通实现混用。 |
+| `finish_request` | 收尾/合并/推送/cleanup | 用户要求 finish、merge、push、收尾、交付完成、清理 change 分支。 | `ws-finish` | 必须满足 finish gate，不能跳过 validate / push / cleanup。 | finish 是独立治理阶段，不能与普通实现混用。 |
 | `handoff_request` | 交接/归档总结 | 用户要求 handoff、交接说明、archive summary、会话总结或接力说明。 | `ws-handoff` | 先确认 change 已 finish 或 archive 上下文存在。 | handoff 依赖已有证据与归档上下文，不应在实现前触发。 |
-| `plan_first` | 中大型实现或需要建立 change 上下文 | 任务是多步实现、跨文件、跨模块、需要方案、需要新建 change/worktree，或当前还没有计划工件。 | `ws-plan` | plan 过 gate 前不进入 `ws-dev`。 | medium/complex 任务必须先生成可落盘计划，避免 router 直接跳进实现。 |
+| `plan_first` | 中大型实现或需要建立 change 上下文 | 任务是多步实现、跨文件、跨模块、需要方案、需要新建 change 分支，且需求已经冻结或已有可消费的 intake 草案。 | `ws-plan` | plan 过 gate 前不进入 `ws-dev`。 | medium/complex 任务在需求冻结后必须先生成可落盘计划，避免 router 直接跳进实现。 |
 | `direct_implementation` | 小步实现/修复/配置调整 | 目标明确、归因清晰、验证入口明确，且无需先改 requirements 或单独评审。 | `ws-dev` | 若执行中发现复杂度升高，必须回退到 `ws-plan`。 | router 允许明确的小步任务直接实现，但必须保留回退计划阶段的门；若用户明确要走轻量入口，可在实现阶段显式使用 `ws-dev-lite` 作为 `ws-dev` 的 facade。 |
+| `design_first` | 需要先出设计方案 | 任务涉及新流程、新模块、新架构或对现有架构有显著影响的方向决策，需要先出设计方案再进入实现。 | `ws-design` | design 未完成 review 前，不进入 `ws-plan`。 | 复杂或高影响改动应先出设计方案，让设计过审后再投入实现，避免返工。 |
+| `spec_update` | 需要更新规范/文档/验收标准 | 任务涉及更新 AI_PROJECT.md、REQUIREMENTS.md、AI_WORKSPACE.md 中的规范说明、验收标准或 contract 文档。 | `ws-spec-update` | spec 更新必须先过 review，再同步到真值文件。 | 规范更新与功能变更不同，router 应优先引导到 spec 维护链而非直接实现。 |
 
 ## Route Cases
 
@@ -54,12 +58,15 @@ router 在做任何 workflow 判断前，必须先读取：
 | --- | --- | --- | --- | --- | --- |
 | `case_missing_truths` | 仓库未初始化或真值缺失时，不能直接开始实现。 | 在一个还没执行 aiws init 的仓库里继续开发这个功能。 | `missing_truths` | `ws-preflight` | 缺失真值文件时只能先补齐 preflight/init 路径。 |
 | `case_unclear_continue` | 用户只说继续，但没有明确当前 change、归因或验证入口。 | 继续。 | `unclear_intent` | `clarify` | 这种场景必须先澄清意图和绑定，不能猜测实现。 |
+| `case_needs_intake` | 任务方向大致明确，但存在多条待确认问题，需要逐条沟通后再计划。 | 做一个新的 change intake 流程，我想先一条一条把需求和边界聊清楚，再进入正式计划。 | `needs_intake` | `ws-intake` | 这类需求不是完全不清晰，但还没有冻结，适合先走 intake。 |
 | `case_requirements_change` | 任务要修改 REQUIREMENTS、requirements CSV 或 workflow 真值。 | 更新 REQUIREMENTS.md 和 requirements/requirements-issues.csv，补充验收标准。 | `requirements_change` | `ws-req-review` | 需求真值变更必须先做需求评审。 |
 | `case_review_request` | 用户明确要求 review、审计、找风险或检查回归。 | review 这批改动，先给我风险和回归点，不要先改代码。 | `review_request` | `ws-review` | 评审任务的输出契约是 findings，不应直接进入实现。 |
-| `case_finish_request` | 用户要求合并、push、cleanup 或 finish 当前 change。 | 把 demo-change finish 掉并 push，顺便 cleanup worktree。 | `finish_request` | `ws-finish` | finish 是独立治理阶段，必须先走 finish gate。 |
+| `case_finish_request` | 用户要求合并、push、cleanup 或 finish 当前 change。 | 把 demo-change finish 掉并 push，顺便 cleanup。 | `finish_request` | `ws-finish` | finish 是独立治理阶段，必须先走 finish gate。 |
 | `case_handoff_request` | 用户要求 handoff、交接说明、archive summary 或接力文档。 | 给这个 change 写 handoff，并补 archive summary。 | `handoff_request` | `ws-handoff` | handoff 依赖已有 finish/archive 上下文，不能当成普通实现。 |
-| `case_plan_first` | 任务是跨文件、多步实现，且需要先建立 change/worktree 或方案。 | 实现 dashboard 的阶段治理视图并补测试，需要新建 change 和计划。 | `plan_first` | `ws-plan` | 中大型实现应先落盘计划，再进入 dev。 |
+| `case_plan_first` | 任务是跨文件、多步实现，且需要先建立 change 分支或方案。 | 实现 dashboard 的阶段治理视图并补测试，需要新建 change 和计划。 | `plan_first` | `ws-plan` | 中大型实现应先落盘计划，再进入 dev。 |
 | `case_direct_implementation` | 任务是小步明确修复，归因和验证入口都已清楚。 | 修复 codex install-skills 的默认路径，并补一条可复现回归。 | `direct_implementation` | `ws-dev` | 小步明确实现允许直接进入 dev；若用户明确要轻量直修，可进一步显式使用 ws-dev-lite，但治理归属仍收敛到 ws-dev。 |
+| `case_design_first` | 任务需要先出设计方案再进入实现。 | 设计 dashboard 架构，出方案后再实现。 | `design_first` | `ws-design` | 高影响改动应先出设计方案，过审后再投入实现。 |
+| `case_spec_update` | 任务涉及更新规范或验收标准文档。 | 更新 AI_WORKSPACE.md 中的验证命令说明。 | `spec_update` | `ws-spec-update` | 规范更新应先走 spec 维护链，直接实现会绕过 review 门禁。 |
 
 ## 必须先澄清的情形
 
@@ -67,13 +74,15 @@ router 在做任何 workflow 判断前，必须先读取：
 - 无法把任务绑定到 `Req_ID` / `Problem_ID` / change 上下文。
 - 没有可复现验证入口，且无法从 `AI_WORKSPACE.md` 推断。
 - 当前描述同时包含需求变更、实现和收尾，但没有明确优先级。
+- 同一个任务包含多条待确认问题，且用户希望逐条、多轮沟通。
 
 ## 统一规则
 
 - router 自己不是实现阶段；先判定 workflow，再进入具体 `ws-*` skill。
 - 除缺失真值场景外，router 至少要给出一个明确的 `Route:` 结果或明确的澄清问题。
 - 当 `routeTo=clarify` 时，必须停止，不直接写代码。
-- 当 `routeTo=ws-plan` / `ws-dev` / `ws-review` / `ws-finish` / `ws-handoff` / `ws-req-review` 时，后续行为必须遵循对应 skill 契约。
+- 当 `routeTo=ws-intake` 时，必须先逐条冻结问题并产出 intake 草案；不要跳过到 `ws-plan`。
+- 当 `routeTo=ws-plan` / `ws-dev` / `ws-review` / `ws-finish` / `ws-handoff` / `ws-req-review` / `ws-intake` 时，后续行为必须遵循对应 skill 契约。
 - 任何 route 都不能绕过 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`。
 
 ## 说明

package/docs/workflow-stage-contracts.json

@@ -8,6 +8,7 @@
   ],
   "standardChain": [
     "ws-preflight",
+    "ws-intake",
     "ws-plan",
     "ws-plan-verify",
     "ws-dev",
@@ -19,9 +20,8 @@
   ],
   "notes": [
     "ws-deliver 用于多 repo / submodule 场景的顺序提交与交付准备。",
-    "ws-finish 用于 fast-forward 合并、push、worktree cleanup，并在完整 finish 后自动归档 change。",
+    "ws-finish 用于 fast-forward 合并、push、change 分支清理，并在完整 finish 后自动归档 change。",
     "ws-handoff 通常在 finish 自动归档后使用，用于查看/补充归档交接说明。",
-    "若存在独立 change worktree，治理信号应优先读取该 worktree；若 worktree metadata 已 stale，则降级为 warning 并回退到当前 worktree。"
   ],
   "stages": [
     {
@@ -30,21 +30,29 @@
       "requiredInputs": "项目根；AI_PROJECT.md；REQUIREMENTS.md；AI_WORKSPACE.md",
       "requiredOutputs": "Root / Found / Missing / Key rules / Next",
       "blockers": "无法确定项目根；真值缺失",
-      "next": "ws-plan 或 ws-dev"
+      "next": "ws-intake / ws-plan 或 ws-dev"
+    },
+    {
+      "stage": "ws-intake",
+      "goal": "逐条澄清问题并冻结需求结论，产出可被计划阶段消费的草案",
+      "requiredInputs": "任务描述；真值文件；当前已知绑定与约束；若已存在则读取最新 intake 草案",
+      "requiredOutputs": "plan/*.intake.md；Open Questions / Resolved Questions / Frozen Decisions / Draft Scope / Draft Verify / Ready for ws-plan",
+      "blockers": "任务目标完全无法识别；关键真值缺失；无法把当前问题收敛为 frozen 或 deferred",
+      "next": "继续 intake 或进入 ws-plan"
     },
     {
       "stage": "ws-plan",
       "goal": "建立 change 绑定并落盘计划",
-      "requiredInputs": "任务描述；真值文件；proposal.md（若存在）",
+      "requiredInputs": "任务描述；真值文件；proposal.md（若存在）；若已有则优先消费最新 intake 草案",
       "requiredOutputs": "plan/...；Bindings；Verify；Risks；Evidence；Next",
-      "blockers": "绑定不清；dirty 工作区无法安全建 context；无法写盘",
+      "blockers": "绑定不清；需求尚未冻结；dirty 工作区无法安全建 context；无法写盘",
       "next": "ws-plan-verify"
     },
     {
       "stage": "ws-plan-verify",
-      "goal": "检查计划是否满足严格契约",
+      "goal": "检查计划是否满足严格契约，并做多视角方案审查",
       "requiredInputs": "plan/...；proposal.md；当前 change",
-      "requiredOutputs": "Quality gate；Fix list；可执行最小计划摘要",
+      "requiredOutputs": "Quality gate；Perspective findings；Fix list；可执行最小计划摘要",
       "blockers": "strict 校验失败；无法定位 change",
       "next": "修计划后重跑或进入 ws-dev"
     },
@@ -84,7 +92,7 @@
       "stage": "ws-finish",
       "goal": "安全合并、push、cleanup，并自动归档",
       "requiredInputs": "干净工作区；已提交的 change；push 目标；submodule 真值（若有）",
-      "requiredOutputs": "Merge；Push；Worktree cleanup；Archive/Handoff；Evidence",
+      "requiredOutputs": "Merge；Push；Change 分支清理；Archive/Handoff；Evidence",
       "blockers": "dirty 工作区；ff 失败；submodule 无法安全 push",
       "next": "ws-handoff"
     },

package/docs/workflow-stage-contracts.md

@@ -12,26 +12,26 @@
 
 默认链路：
 
-`ws-preflight` -> `ws-plan` -> `ws-plan-verify` -> `ws-dev` -> `ws-review` -> `ws-commit` -> `ws-deliver` -> `ws-finish` -> `ws-handoff`
+`ws-preflight` -> `ws-intake` -> `ws-plan` -> `ws-plan-verify` -> `ws-dev` -> `ws-review` -> `ws-commit` -> `ws-deliver` -> `ws-finish` -> `ws-handoff`
 
 说明：
 - ws-deliver 用于多 repo / submodule 场景的顺序提交与交付准备。
-- ws-finish 用于 fast-forward 合并、push、worktree cleanup，并在完整 finish 后自动归档 change。
+- ws-finish 用于 fast-forward 合并、push、change 分支清理，并在完整 finish 后自动归档 change。
 - ws-handoff 通常在 finish 自动归档后使用，用于查看/补充归档交接说明。
-- 若存在独立 change worktree，治理信号应优先读取该 worktree；若 worktree metadata 已 stale，则降级为 warning 并回退到当前 worktree。
 
 ## 阶段表
 
 | Stage | 目标 | 必需输入 | 必需输出 | 阻断条件 | 下一步 |
 | --- | --- | --- | --- | --- | --- |
-| `ws-preflight` | 对齐真值文件与协作约束 | 项目根；AI_PROJECT.md；REQUIREMENTS.md；AI_WORKSPACE.md | Root / Found / Missing / Key rules / Next | 无法确定项目根；真值缺失 | ws-plan 或 ws-dev |
-| `ws-plan` | 建立 change 绑定并落盘计划 | 任务描述；真值文件；proposal.md（若存在） | plan/...；Bindings；Verify；Risks；Evidence；Next | 绑定不清；dirty 工作区无法安全建 context；无法写盘 | ws-plan-verify |
-| `ws-plan-verify` | 检查计划是否满足严格契约 | plan/...；proposal.md；当前 change | Quality gate；Fix list；可执行最小计划摘要 | strict 校验失败；无法定位 change | 修计划后重跑或进入 ws-dev |
+| `ws-preflight` | 对齐真值文件与协作约束 | 项目根；AI_PROJECT.md；REQUIREMENTS.md；AI_WORKSPACE.md | Root / Found / Missing / Key rules / Next | 无法确定项目根；真值缺失 | ws-intake / ws-plan 或 ws-dev |
+| `ws-intake` | 逐条澄清问题并冻结需求结论，产出可被计划阶段消费的草案 | 任务描述；真值文件；当前已知绑定与约束；若已存在则读取最新 intake 草案 | plan/*.intake.md；Open Questions / Resolved Questions / Frozen Decisions / Draft Scope / Draft Verify / Ready for ws-plan | 任务目标完全无法识别；关键真值缺失；无法把当前问题收敛为 frozen 或 deferred | 继续 intake 或进入 ws-plan |
+| `ws-plan` | 建立 change 绑定并落盘计划 | 任务描述；真值文件；proposal.md（若存在）；若已有则优先消费最新 intake 草案 | plan/...；Bindings；Verify；Risks；Evidence；Next | 绑定不清；需求尚未冻结；dirty 工作区无法安全建 context；无法写盘 | ws-plan-verify |
+| `ws-plan-verify` | 检查计划是否满足严格契约，并做多视角方案审查 | plan/...；proposal.md；当前 change | Quality gate；Perspective findings；Fix list；可执行最小计划摘要 | strict 校验失败；无法定位 change | 修计划后重跑或进入 ws-dev |
 | `ws-dev` | 实施最小改动并验证 | 真值文件；归因目标；计划（medium/complex） | Changed；Verify；Evidence；Next | 无法归因；没有验证入口；change 上下文不安全 | ws-review / ws-commit |
 | `ws-review` | 审计规范、风险与验证完整性 | 当前 diff；验证结果；真值文件 | review 文件；Top risks；Next | 无改动可审；无法写审计证据 | ws-commit 或修复后重审 |
 | `ws-commit` | 串联 review、validate、commit 确认 | staged diff；review 证据；validate stamp；用户确认的 message | Evidence；Context；Commit | 无 staged changes；submodule dirty；validate 失败；message 未确认 | ws-deliver / ws-finish |
 | `ws-deliver` | 在 submodule 场景下完成顺序提交与证据收敛 | change 上下文；.gitmodules；submodules.targets；各 repo 状态 | submodule 提交摘要；superproject 提交摘要；Evidence | submodule 真值不完整；不在正确 change；commit 未确认 | ws-finish |
-| `ws-finish` | 安全合并、push、cleanup，并自动归档 | 干净工作区；已提交的 change；push 目标；submodule 真值（若有） | Merge；Push；Worktree cleanup；Archive/Handoff；Evidence | dirty 工作区；ff 失败；submodule 无法安全 push | ws-handoff |
+| `ws-finish` | 安全合并、push、cleanup，并自动归档 | 干净工作区；已提交的 change；push 目标；submodule 真值（若有） | Merge；Push；Change 分支清理；Archive/Handoff；Evidence | dirty 工作区；ff 失败；submodule 无法安全 push | ws-handoff |
 | `ws-handoff` | 查看/补充可接力的归档交接说明 | 已归档的 change | changes/archive/.../handoff.md；Next | 无法定位已归档 change；handoff 无法生成或读取 | 新 change 通过 Depends_On 接力 |
 
 ## 统一规则

package/package.json

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

package/templates/workspace/.agents/skills/using-aiws/SKILL.md

@@ -9,6 +9,7 @@ description: 默认 workflow bootstrap/router：先读真值，再路由到正
 - 作为默认入口，先读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
 - 先判定当前任务属于哪个 workflow，再进入具体 `ws-*` skill
 - 若任务意图、归因或验证入口不明确：先澄清，不直接进入实现
+- 若任务方向大致明确但仍有多条待确认问题：先进入 `$ws-intake` 冻结需求，再进入计划
 
 阶段定位：
 - bootstrap/router 阶段；负责 workflow 分流，而不是直接完成实现。
@@ -23,6 +24,7 @@ description: 默认 workflow bootstrap/router：先读真值，再路由到正
 必需输出：
 - `Root:` 当前项目根
 - `Found:` 实际读取到的真值文件
+- `Intent status:` 当前需求是否已经冻结
 - `Task intent:` 当前任务意图分类
 - `Binding:` `Req_ID` / `Problem_ID` / change 上下文是否清晰
 - `Route:` 选中的下一步 skill
@@ -48,18 +50,28 @@ description: 默认 workflow bootstrap/router：先读真值，再路由到正
    - 输出下一步：先 `aiws init .`（或 `npx @aipper/aiws init .`），然后重新执行 `$using-aiws`
    - 此时 route 视为 `$ws-preflight`
 3) 根据 `packages/spec/docs/workflow-router-rules.json` 判定任务属于哪一类：
-   - 需求/验收/合同变更：`$ws-req-review`
-   - 评审/审计/找风险：`$ws-review`
-   - finish / merge / push / cleanup：`$ws-finish`
-   - handoff / archive summary：`$ws-handoff`
-   - 中大型实现、需要方案、需要 change/worktree：`$ws-plan`
+    - 需求/验收/合同变更：`$ws-req-review`
+    - 评审/审计/找风险：`$ws-review`
+    - finish / merge / push / cleanup：`$ws-finish`
+    - handoff / archive summary：`$ws-handoff`
+    - 新需求或中大型变更，且存在多条待确认问题 / 用户要求逐条多轮沟通：`$ws-intake`
+    - 需要先出设计方案（design 未过审前不进入实现）：`$ws-design`
+    - 需要更新规范/验收标准（必须先过 review）：`$ws-spec-update`
+    - 中大型实现、需要方案、需要 change/worktree，且需求已经冻结：`$ws-plan`
    - 小步明确实现/修复/配置调整：`$ws-dev`（若是 simple/local 单点修复，且用户明确希望走轻量入口，可显式进入 `$ws-dev-lite`）
 4) 若任务意图或归因不明确：
    - 只问 1-3 个关键澄清问题
    - 明确写出缺的是什么：意图、`Req_ID` / `Problem_ID`、verify、change 上下文
    - 然后停止；不要直接写代码
-5) 若已确定 route：
+5) 若任务方向大致明确，但同一个任务包含多条待确认问题、范围尚未冻结，或用户明确说“想一条一条聊清楚再计划”：
+   - 输出 `Intent status: not_frozen`
+   - `Route: $ws-intake`
+   - `Why:` 说明当前不适合直接进入 `$ws-plan`
+   - `Next:` 进入 `$ws-intake`
+   - 然后在同一轮中继续遵循 `$ws-intake` 的契约
+6) 若已确定 route：
    - 先输出：
+     - `Intent status:`
      - `Task intent:`
      - `Binding:`
      - `Route:`
@@ -69,17 +81,19 @@ description: 默认 workflow bootstrap/router：先读真值，再路由到正
    - 否则：
      - `Next:` 进入对应主 skill
    - 然后在同一轮中继续遵循对应 skill 的契约
-6) 路由约束：
+7) 路由约束：
    - router 自己不是实现阶段；不要在给出 route 之前直接改代码
    - 除非用户只想听判断结果，否则给出 route 后应继续按对应 skill 的规则推进
    - 一次只选择一个主 route；不要把 `ws-plan` / `ws-dev` / `ws-review` / `ws-finish` 混成并行终态
-7) 若执行过程中发现复杂度升高：
+8) 若执行过程中发现复杂度升高：
    - 从 `$ws-dev` 回退到 `$ws-plan`
+   - 从 `$ws-plan` 回退到 `$ws-intake`（当发现需求并未冻结）
    - 从 `$ws-finish` 回退到前置门禁而不是硬推完成
 
 输出模板：
 - `Root:` <path>
 - `Found:` <files>
+- `Intent status:` <frozen / not_frozen>
 - `Task intent:` <分类>
 - `Binding:` <清晰 / 缺失项>
 - `Route:` <$ws-... 或 clarify>

package/templates/workspace/.agents/skills/ws-commit/SKILL.md

@@ -1,130 +1,18 @@
 ---
 name: ws-commit
-description: 提交（当前分支可直提；submodule 感知；先审计/门禁再 commit）
+description: `aiws ws-commit` 的薄包装入口
 ---
 
-用中文输出（命令/路径/代码标识符保持原样不翻译）。
+# ws-commit
 
-目标：
-- 支持在**当前分支直接提交**（不要求必须先切 `change/<change-id>`）
-- 提交前审计与证据落盘（`$ws-review`）
-- 提交前门禁校验与证据落盘（`aiws validate . --stamp`）
-- 最后执行 `git commit`（commit 前必须让用户确认 message；不使用 `--no-verify` 绕过 hooks）
-- 若仓库含 submodule：提交前识别并提示正确顺序（先 submodule，再 superproject）
- - 若你经常遇到 submodule detached：建议日常拉取使用 `$ws-pull`（尽量把 submodule “挂回分支”且不改变 gitlink commit）
+`aiws ws-commit` 的薄包装入口。
 
-安全约束（强制）：
-- 不自动 `git add -A`（避免误提交）；只在用户明确指示时才执行 staging 命令
-- 不自动 push
-- 不写入任何 secrets
-- 检测到 submodule 有未提交改动时，不允许直接提交 superproject（先处理 submodule）
-- commit message 优先使用中文（命令/路径/代码标识符保持原样不翻译）；格式建议：`<类型>: <简述>`（例如 `修复: 登录页空指针`、`功能: 新增 submodule targets 校验`、`重构: 提取共享脚本`）
-- 若启用了 `.githooks/commit-msg`：默认按仓库角色区分
-  - superproject / root 仓库（存在 `.gitmodules`）默认允许自由 commit message
-  - submodule / 普通仓库默认提示优先中文
-  - 只有在 `git config aiws.commitMessagePolicy strict` 时才会拒绝全英文首行（`Merge/Revert/fixup!/squash!` 例外）
-
-阶段定位：
-- commit gate；负责在提交前收敛 review、validate 和 message 确认，不允许跳过 hooks。
-
-必需输入：
-- 当前分支与 staged diff
-- `$ws-review` 生成的审计证据
-- `aiws validate . --stamp` 生成的校验证据
-- 用户确认后的 commit message
-
-必需输出：
-- `证据（Evidence）:` review 文件路径 + validate stamp 路径
-- `上下文（Context）:` 当前分支、submodule 检测结果、阻断原因（若有）
-- `提交信息（Commit）:` 最终提交信息
-
-阻断条件：
-- 没有 staged changes
-- submodule 工作区不干净或 detached 处理不完整
-- 用户未确认 commit message
-- validate 失败
-
-完成判定：
-- 提交已完成，证据路径明确，且没有通过 `--no-verify` 绕过门禁。
-
-执行步骤（建议）：
-1) 运行 `$ws-preflight`（确保真值文件就绪）。
-2) 运行 `$ws-review`（优先生成审计证据：`changes/<change-id>/review/codex-review.md`；无 `change-id` 时回退 `.agentdocs/tmp/review/codex-review.md`）。
-3) 运行门禁校验并写 stamp：
 ```bash
 if [[ -x "./node_modules/.bin/aiws" ]]; then
-  ./node_modules/.bin/aiws validate . --stamp
+  ./node_modules/.bin/aiws ws-commit
 elif command -v aiws >/dev/null 2>&1; then
-  aiws validate . --stamp
+  aiws ws-commit
 else
-  npx @aipper/aiws validate . --stamp
-fi
-```
-4) 输出当前提交上下文（必须输出给用户确认）：
-```bash
-git branch --show-current
-git status --porcelain
-```
-5) 检测是否存在 submodule（有则进入 submodule 感知模式）：
-```bash
-if [[ -f .gitmodules ]]; then
-  git config --file .gitmodules --get-regexp '^submodule\..*\.path$' || true
-else
-  echo "[info] no .gitmodules"
-fi
-```
-6) 若存在 submodule，逐个检查子仓库工作区是否干净：
-```bash
-while read -r _ sub_path; do
-  [[ -z "${sub_path:-}" ]] && continue
-  echo "== submodule: ${sub_path} =="
-  git -C "${sub_path}" rev-parse --abbrev-ref HEAD 2>/dev/null || true
-  git -C "${sub_path}" status --porcelain || true
-done < <(git config --file .gitmodules --get-regexp '^submodule\..*\.path$' 2>/dev/null || true)
-```
-判定规则（强制）：
-- 任一 submodule `git status --porcelain` 非空：停止 superproject commit，先在对应 submodule 完成 commit，再回到 superproject 更新并提交 gitlink。
-- 若该 submodule 当前为 detached HEAD：先按 `.gitmodules` 的目标分支挂到 `aiws/pin/<target_branch>`；不要直接切 `change/<change-id>` / `main` / `master` 来“解 detached”。
-处理指引（detached submodule）：
-```bash
-cur_branch="$(git branch --show-current)"
-change_id="$(echo "${cur_branch}" | sed -n 's|^change/||p')"
-targets="changes/${change_id}/submodules.targets"
-
-source tools/ws_resolve_sub_target.sh
-ws_resolve_sub_target "${sub_path}" "${sub_name}" "${targets}" "${cur_branch}" || exit 2
-target_branch="${_resolved_branch}"
-remote="${_resolved_remote}"
-
-git -C "${sub_path}" fetch "${remote}" --prune
-if ! git -C "${sub_path}" show-ref --verify --quiet "refs/remotes/${remote}/${target_branch}"; then
-  echo "error: missing ${remote}/${target_branch} for submodule path=${sub_path}"
-  exit 2
+  npx @aipper/aiws ws-commit
 fi
-git -C "${sub_path}" checkout -B "aiws/pin/${target_branch}" HEAD
-git -C "${sub_path}" branch --set-upstream-to "${remote}/${target_branch}" "aiws/pin/${target_branch}" >/dev/null 2>&1 || true
 ```
-7) 检查当前 staging 内容（必须输出给用户确认）：
-```bash
-git status --porcelain
-git diff --staged --submodule=short
-```
-8) 若没有 staged changes：停止并提示用户先明确要提交哪些文件（例如 `git add -p` 或 `git add <path>`）。
-9) 生成中文 commit message 草案（格式：`<类型>: <简述>`），输出给用户确认后再执行。
-   - 类型参考：`功能` / `修复` / `重构` / `文档` / `测试` / `构建` / `杂项`
-   - 简述用一句话概括本次改动的"为什么"而非"改了什么"
-   - 命令/路径/代码标识符保持原样不翻译
-   - 若用户给出全英文 message：优先改写成中文；若用户明确要求保留英文，也可以提交（但 strict 模式下会被 hook 拒绝）
-10) 执行提交（不带 `--no-verify`）：
-```bash
-git commit -m "<message>"
-```
-11) 输出提交结果（可选）：
-```bash
-git show --stat --oneline -1
-```
-
-输出要求：
-- `证据（Evidence）:` `changes/<change-id>/review/codex-review.md`（无 `change-id` 时回退 `.agentdocs/tmp/review/codex-review.md`） + `.agentdocs/tmp/aiws-validate/*.json`
-- `上下文（Context）:` 当前分支 + 是否检测到 submodule + 若阻断则给出阻断原因
-- `提交信息（Commit）:` 最终使用的 commit message（仅当用户确认后）