architext 0.0.3 → 0.0.5

package/dist/templates/zh/docs/prompts/remove.md

@@ -14,104 +14,52 @@
 </meta>
 
 <step_1_resolve>
-    **Role**: 系统分析师
     **Action**:
-    1.  **Resolve ID**: 从 `[[__DOCS_DIR__]]/global/roadmap.json` 解析 `<id>` → Task Name、Slug、状态。
+    1.  **Resolve ID**: 从 roadmap.json 解析 `<id>` → Task Name、Slug、状态。
     2.  **ID Not Found** → 报错并列出可用任务 ID。
-    3.  **Load Context**:
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/` — 全部文档（spec.md, ui.md, plan.json 等）
-        - `[[__DOCS_DIR__]]/global/roadmap.json` — 任务依赖关系
-        - `[[__DOCS_DIR__]]/global/map.json` — 架构注册
-        - `99_context_glue.md` — 代码↔文档关联
+    3.  **Load**: task docs 目录、roadmap.json（依赖关系）、map.json（架构注册）、99_context_glue.md（关联）。
 
     **Output**: 目标 Task 基本信息（ID、名称、状态、关联文件数）。
 </step_1_resolve>
 
 <step_2_impact>
-    **Role**: 影响评估官
     **Action**: 逐层扫描，生成影响清单。
 
     ### 2.1 依赖检查（阻塞级）
 
-    扫描 `roadmap.json` 中所有任务的 `deps` 字段，找出依赖 `<id>` 的任务。
+    扫描 roadmap.json 所有任务 `deps`，找出依赖 `<id>` 的任务。
 
     | 情况 | 处理 |
     |:---|:---|
-    | 无下游依赖 | 通过，继续 |
-    | 有下游依赖且状态为 `pending`/`blocked` | 列出受影响任务，询问用户：移除依赖关系后继续，还是中止 |
-    | 有下游依赖且状态为 `active`/`done` | **阻塞** — 这些任务可能已使用该 Task 的接口/组件。须先用 `/archi.edit` 解耦后再移除 |
+    | 无下游依赖 | 通过 |
+    | 有下游依赖且 `pending`/`blocked` | 列出，询问：移除依赖后继续 or 中止 |
+    | 有下游依赖且 `active`/`done` | **阻塞** — 须先 `/archi.edit` 解耦 |
 
     ### 2.2 代码文件识别
 
-    通过以下方式定位该 Task 的代码文件：
-    1.  `99_context_glue.md` 中与 `<id>` 关联的代码路径。
-    2.  `map.json` 中该 Task 注册的模块/目录。
-    3.  `plan.json` 中任务提及的文件路径。
-    4.  扫描代码目录，查找以 Slug 命名或在目录结构中明确归属的文件。
+    通过以下方式定位代码文件：context_glue 关联路径、map.json 注册模块、plan.json 提及的文件、以 Slug 命名或明确归属的文件。
 
     ### 2.3 全局引用扫描
 
     | 文件 | 扫描内容 |
     |:---|:---|
-    | `roadmap.json` | 任务条目 + 其他任务 `deps` 中的引用 |
-    | `map.json` | 模块注册条目 + `featureRelations` 中以被删 Task 为 aggregator 的条目 |
+    | `roadmap.json` | 任务条目 + deps 引用 |
+    | `map.json` | 模块条目 + featureRelations 中以被删 Task 为 aggregator 的条目 |
     | `99_context_glue.md` | 关联条目 |
-    | `dictionary.json` | 该 Task 独占的术语（仅标记，不自动删） |
-    | `error_codes.json` | 该 Task 独占的错误码（仅标记，不自动删） |
+    | `dictionary.json` | 独占术语（仅标记） |
+    | `error_codes.json` | 独占错误码（仅标记） |
 
     ### 2.4 聚合联动检查
 
-    读取 `map.json.featureRelations`，判断被删 Task 是否属于某聚合方的 `sources` 覆盖范围。
-
-    | 情况 | 处理 |
-    |:---|:---|
-    | 不在任何聚合方的 sources 范围内 | 无需特殊处理 |
-    | 在聚合方 sources 范围内 | 在影响报告中列出，提示删除后须检查聚合方内容是否需要同步移除 |
-    | 被删 Task 本身是 aggregator | 同时移除 `featureRelations` 中该条记录 |
+    [[SUBAGENT: archi-feature-relations|mode: cleanup, context: 检查被删 Task 在 featureRelations 中的引用，输出影响报告]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-feature-relations/SKILL.md`，按 mode: cleanup 的逻辑执行）]]
 
     ### 2.5 跨 Task 引用
 
-    扫描其他 Task 的 `spec.md`，检查是否引用了被删 Task 的接口、组件或数据。发现引用则标注为 `[Breaking]`。
-
-    **Output**: 向用户输出影响报告：
-    ```
-    ### 下线影响报告: <ID> <Name>
-
-    **Task 状态**: [status]
-
-    **将删除的文档**:
-    - [[__DOCS_DIR__]]/tasks/<id>_<slug>/  (N 个文件)
-
-    **将删除的代码**:
-    | 文件/目录 | 来源 |
-    |:---|:---|
-    | src/xxx/xxx.ts | context_glue |
-    | src/xxx/ | map.json |
-
-    **全局引用清理**:
-    - roadmap.json: 移除任务 <id>，清理 N 处 deps 引用
-    - map.json: 移除 N 个模块条目
-    - context_glue: 移除 N 条关联
+    扫描其他 Task 的 `spec.md`，检查是否引用了被删 Task 的接口/组件/数据。发现引用则标注 `[Breaking]`。
 
-    **[?有]术语/错误码残留** (须人工确认):
-    - dictionary.json: [term1], [term2]
-    - error_codes.json: [ERR_XXX]
+    **Output**: 向用户输出下线影响报告 — 含 Task 状态、将删除的文档和代码（文件/来源表）、全局引用清理项（roadmap/map/context_glue）、（有）术语/错误码残留（须人工确认）、（有）聚合联动表、（有）跨 Task 引用 [Breaking] 表。末尾：OK 确认执行 / 中止取消。
 
-    **[?有]聚合联动** (须检查):
-    | 聚合方 | checkNote |
-    |:---|:---|
-    | [aggregator ID/路径] | [checkNote 内容] |
-
-    **[?有]跨 Task 引用 [Breaking]**:
-    | 引用方 | 引用内容 | 建议 |
-    |:---|:---|:---|
-    | FEAT-005 spec.md | 调用了 <id> 的 UserAPI | 先 /archi.edit FEAT-005 解耦 |
-
-    ---
-    > 回复 **OK** 确认执行；回复 **中止** 取消操作。
-    ```
-
-    **Gate**: 用户回复 OK 后进入 step_3。有 `[Breaking]` 跨 Task 引用时须再次警告。
+    **Gate**: 用户回复 OK 后进入 step_3。有 `[Breaking]` 引用时须再次警告。
 </step_2_impact>
 
 <step_3_execute>
@@ -122,35 +70,35 @@
     |:---|:---|:---|
     | 1 | 删除代码文件/目录 | step_2 识别的代码路径 |
     | 2 | 删除 Task 文档目录 | `[[__DOCS_DIR__]]/tasks/<id>_<slug>/` |
-    | 3 | 更新 `roadmap.json` | 移除任务条目；清理其他任务 `deps` 中对 `<id>` 的引用 |
-    | 4 | 更新 `map.json` | 移除该 Task 注册的模块条目；若该 Task 本身是 aggregator，同时移除其 `featureRelations` 条目 |
-    | 5 | 更新 `99_context_glue.md` | 移除该 Task 的关联条目 |
+    | 3 | 更新 `roadmap.json` | 移除任务条目；清理 deps 引用 |
+    | 4 | 更新 `map.json` | 移除模块条目 + featureRelations 条目 |
+    | 5 | 更新 `99_context_glue.md` | 移除关联条目 |
     | 6 | [?有独占术语] 更新 `dictionary.json` | 移除或标注废弃 |
     | 7 | [?有独占错误码] 更新 `error_codes.json` | 移除或标注废弃 |
-    | 8 | [?有聚合联动] 检查聚合方代码 | 确认聚合方中对被删 Task 的引用已清理 |
+    | 8 | [?有聚合联动] 检查聚合方代码 | 确认引用已清理 |
 
-    每步完成后记录操作日志（文件路径 + 操作类型）。
+    每步完成后记录操作日志。
 </step_3_execute>
 
 <step_4_verify>
-    **Role**: 验证工程师
-    **Terminal Gate** (禁止跳过，须在 step_5 输出前全部完成):
+    **Terminal Gate** (禁止跳过): 标准检查 (task --check + render)。
     | 步骤 | 命令 | 通过条件 |
     |:---|:---|:---|
-    | 1 | `npx archi task --check` | 无 ERROR 级问题，无悬空依赖 |
-    | 2 | `npx archi render` | `.md` 视图生成完成 |
-    | 3 | 运行项目构建命令 | 零编译错误 |
-
-    | 检查项 | 通过标准 |
-    |:---|:---|
-    | Roadmap 一致性 | `--check` 通过，无悬空依赖 |
-    | 构建 | 零编译错误 |
-    | 残留引用 | 代码中无对已删模块的 import/require |
+    | 3 | 运行项目构建命令 | 零编译错误；无对已删模块的 import/require |
 
     构建失败或发现残留引用 → 定位并修复后重检。
 </step_4_verify>
 
 <step_5_summary>
+    **Pre-signoff Checklist** (输出前须逐项确认):
+    □ 代码文件/目录 — 已删除（step_3 操作 #1）
+    □ tasks/<id>_<slug>/ 文档目录 — 已删除（step_3 操作 #2）
+    □ roadmap.json — 任务条目 + deps 引用 — 已清理（step_3 操作 #3）
+    □ map.json — 模块条目 + featureRelations — 已清理（step_3 操作 #4）
+    □ 99_context_glue.md — 关联条目 — 已清理（step_3 操作 #5）
+    □ （有独占术语/错误码）dictionary.json + error_codes.json — 已处理
+    □ Terminal Gate — 项目构建通过，无残留 import 引用（step_4）
+
     **Output**: 下线完成摘要：
     - **已删除**: 文档 N 个文件、代码 N 个文件
     - **已清理**: roadmap / map / context_glue 中的引用

package/dist/templates/zh/docs/prompts/revise.md

@@ -18,19 +18,10 @@
 </meta>
 
 <step_1_load>
-    **Role**: 系统分析师
     **Action**:
-    1.  **Read Global Assets**:
-        - `[[__DOCS_DIR__]]/global/vision.md`
-        - `[[__DOCS_DIR__]]/global/roadmap.json`
-        - `[[__DOCS_DIR__]]/global/map.json`
-        - `[[__DOCS_DIR__]]/global/dictionary.json`
-        - `[[__DOCS_DIR__]]/global/error_codes.json`
-        - `02_tech_stack.md`
-        - [?UI] `[[__DOCS_DIR__]]/global/design_tokens.json`
-        - [?Data] `[[__DOCS_DIR__]]/global/data_snapshot.json`
-    2.  **Scan Task Index**: 扫描 `[[__DOCS_DIR__]]/tasks/` 目录，建立 Task 索引（ID、名称、状态）。
-    3.  **Intent Analysis**: 根据用户 `[context]`，初步定位受影响的全局资产类别。
+    1.  **Load**: 全部全局资产（vision/roadmap/map/dictionary/error_codes/02_tech_stack + 条件: design_tokens/data_snapshot）。
+    2.  **Scan Task Index**: 扫描 tasks/ 目录，建立 Task 索引（ID、名称、状态）。
+    3.  **Intent Analysis**: 根据 `[context]`，初步定位受影响的全局资产类别。
 
     **Output**: 变更意图摘要 — 列出初步判断涉及的全局文件，进入 step_2。
 </step_1_load>
@@ -51,110 +42,78 @@
 </step_2_interview>
 
 <step_3_impact>
-    **Role**: 影响分析师
     **Constraint**: **纯输出，禁修改任何文件**。此步骤为「变更影响评估书」。
 
-    **Output Format**:
-    ```
-    ## 变更影响评估: [变更主题]
-
-    ### 1. 全局资产变更清单
-    | 文件 | 变更内容 | 类型 |
-    |:---|:---|:---|
-    | vision.md | [具体改什么，或"无需变更"] | 修改/无变更 |
-    | 02_tech_stack.md | [...] | ... |
-    | roadmap.json | [...] | ... |
-    | map.json | [...] | ... |
-    | dictionary.json | [...] | ... |
-    | data_snapshot.json | [...] | ... |
-    | design_tokens.json | [...] | ... |
-    | error_codes.json | [...] | ... |
-
-    ### 2. 受影响 Task 清单
-    | Task ID | 名称 | 影响点 | 程度 |
-    |:---|:---|:---|:---|
-    | INF-001 | [名称] | [spec/ui/plan 的哪些部分受影响] | 高/中/低 |
-
-    ### 3. 需用户决策的项目（如有）
-    - [?] [不确定项描述 + 选项]
-    - [?] ...
-
-    ---
-    > 回复 **OK** 确认全部；或标注需调整的部分。
-    ```
+    **Output**: 变更影响评估 — 含全局资产变更清单表（文件/变更内容/类型）、受影响 Task 清单表（ID/名称/影响点/程度）、需用户决策项（如有）。末尾附确认指引：OK 确认全部；或标注需调整部分。
 
     **Gate**: 等待用户确认。未确认禁进入 step_4。
 </step_3_impact>
 
 <step_3_5_refinement>
-    **Role**: 咨询顾问
     **Trigger**: 用户回复非 OK，含修正、否决或追加意见。
     **Action**: 不执行修改。融入用户反馈，刷新影响评估书重新输出，等待再次确认。
+
+    用户回复 OK → 进入 step_4_execute。
 </step_3_5_refinement>
 
 <step_4_execute>
-    **Role**: 执行工程师
     **Action**:
 
     **Safety Checkpoint** (执行前须完成):
     1. 检查 Git 工作区状态（建议执行 `git status`）。
-    2. 如有未提交变更 → 提示用户先 commit 或 stash，再继续执行。
-    3. 工作区干净后，告知用户：如需回滚，可执行 `git checkout -- .` 恢复到变更前状态。
+    2. 如有未提交变更 → 提示用户先 commit 或 stash。
+    3. 工作区干净后，告知用户：如需回滚，可执行 `git checkout -- .`。
 
     **Phase 1 — 修改全局资产**:
     按用户确认的清单修改全局文件。每个文件修改后输出变更摘要。
 
-    **[?UI] Phase 1.5 — 设计系统变更检查**:
-    若 `design_tokens.json` 有以下变更，须在 Phase 2 完成后执行对应操作：
+    **（仅ui项目） Phase 1.5 — 设计系统变更检查**:
+    若 `design_tokens.json` 有以下变更，须通知用户需重跑 `archi-ui-wireframe` 重新生成：
 
-    | 变更范围 | 影响 | 处理方式 |
-    |:---|:---|:---|
-    | `primitivePalette.brand` / `semanticTokens.colors` | 品牌色/语义色变化 | 通知用户：需重跑 `archi-ui-wireframe` Phase 2（全量重着色） |
-    | `semanticTokens.typography` | 字体变化 | 通知用户：需重跑 Phase 2 |
-    | `motion.preference` / `motion.patterns` | 动效变化 | 通知用户：需重跑 Phase 2 |
-    | `illustration.iconLibrary` | 图标库变化 | 通知用户：需重跑 Phase 2 |
-    | `layout` (radius/spacing/shadow) | 组件尺寸/圆角变化 | 通知用户：需重跑 Phase 2 |
+    | 变更范围 | 影响 |
+    |:---|:---|
+    | `primitivePalette.brand` / `semanticTokens.colors` | 品牌色/语义色变化 |
+    | `semanticTokens.typography` | 字体变化 |
+    | `motion.preference` / `motion.patterns` | 动效变化 |
+    | `illustration.iconLibrary` | 图标库变化 |
+    | `layout` (radius/spacing/shadow) | 组件尺寸/圆角变化 |
 
-    > 如上述字段未变动（如仅改 `mode.default`），无需重跑 Phase 2。
+    > 如上述字段未变动（如仅改 `mode.default`），无需重跑。
 
     **Phase 2 — 级联更新 Task 文档**:
     对每个受影响的 Task，按 `/archi.edit` 标准执行:
-    1.  更新 `spec.md`（逻辑/规则因全局变更而需调整的部分）。
-    2.  [?UI] 更新 `ui.md`（范围/交互因全局变更而需调整的部分）；如屏幕结构受影响，运行 `archi-ui-wireframe` Skill（局部更新模式）同步更新 `ui_concept.html` + `ui_context.md`。
-    3.  在 `plan.json` 的 `phases` 中追加新 Phase: `Phase X: Global Revision — [变更主题] (<Date>)`，列出落地任务。
+    1.  更新 `spec.md`。
+    2.  （仅ui项目） 更新 `ui.md`；如屏幕结构受影响，[[SKILL: archi-ui-wireframe|运行 skill（局部更新模式）同步更新]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-ui-wireframe/SKILL.md` 并遵循其协议执行）]]。
+    3.  在 `plan.json` 追加新 Phase: `Phase X: Global Revision — [变更主题] (<Date>)`。
 
-    **Output**: 每个文件的变更摘要（全局 + Task）。
+    **Output**: 每个文件的变更摘要（全局 + Task）。进入 step_5_verify。
 </step_4_execute>
 
-<step_5_summary>
-    **Role**: 审计官
-    **Checklist**:
-    1.  全局资产间一致性（vision ↔ tech_stack ↔ roadmap ↔ map）。
-    2.  Task 文档与更新后的全局资产对齐。
-    3.  无孤立引用（dictionary/map 中旧术语/路径是否已清理）。
+<step_5_verify>
+    **Role**: 独立审查官
 
-    **Terminal Gate** (禁止跳过，须在输出总结前全部完成):
-    | 步骤 | 命令 | 通过条件 |
-    |:---|:---|:---|
-    | 1 | `npx archi task --check` | 无 ERROR 级问题 |
-    | 2 | `npx archi render` | `.md` 视图生成完成 |
+    [[SUBAGENT: archi-silent-audit|mode: plan-docs, context: 审查 step_4 Phase 2 级联更新的 Task 文档，确保与修改后的全局资产一致]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-silent-audit/SKILL.md`，按 mode: plan-docs 的审查维度表逐项检查）]]
 
-    **Action** (Gate 通过后):
-    1.  输出变更总结。
+    [[INCLUDE: shared/verify-result-handling.md]]
+</step_5_verify>
 
-    **Output**:
-    ```
-    ## Global Revision Summary: [变更主题]
+<step_6_summary>
+    **Role**: 首席审计官
 
-    **全局资产变更**: [已修改文件列表]
-    **Task 更新**: [已更新 Task 列表 + 各自影响摘要]
-    **审计结果**: [通过/有风险项]
+    **Pre-signoff Checklist** (Gate 通过后、输出前须逐项确认):
+    □ step_4 Safety Checkpoint — Git 工作区已确认（无未提交变更或已告知用户）
+    □ Phase 1 — 所有确认的全局资产已修改，每个文件有变更摘要输出
+    □ （仅ui项目，设计系统有变更）已通知用户重跑 archi-ui-wireframe
+    □ Phase 2 — 每个受影响 Task 的 spec.md 已更新 + plan.json 已追加 Revision Phase
+    □ Step 5 Silent Audit — 已执行，所有 CRITICAL 问题已修复
+    □ 一致性确认: vision ↔ tech_stack ↔ roadmap ↔ map 无孤立引用（旧术语/路径已清理）
+
+    **Terminal Gate** (禁止跳过): 标准检查 (task --check + render)。
+
+    **Action** (Gate 通过后):
+    1.  输出变更总结。
 
-    ### Next Steps
-    | 优先级 | 动作 | 说明 |
-    |:---|:---|:---|
-    | ... | ... | ... |
-    ```
-</step_5_summary>
+    **Output**: Global Revision Summary — 含全局资产变更文件列表、Task 更新列表及影响摘要、审计结果、Next Steps 表格。
+</step_6_summary>
 
 </protocol_revise>

package/dist/templates/zh/docs/prompts/scope.md

@@ -1,5 +1,5 @@
 <protocol_scope>
-  **Trigger**: `/archi.scope [file_path]`
+  **Trigger**: `/archi.scope [file_path]` | 自然语言触发时由 Workflow Dispatch 自动加载
   **Phase**: Requirement Decomposition
   **Goal**: 读取 Scope Brief，将大需求分解为多个 Roadmap 任务并建立依赖关系。
 
@@ -12,6 +12,7 @@
       3.  **User Agency First**: Brief 中用户已填写的选择须直接采纳，禁质疑或替换。
       4.  **Minimal Questions**: 仅针对信息缺口提问，Brief 充分时可跳过提问直接分解。
       5.  **Option Z Everywhere**: 补充提问须包含 `[Z] 自定义`。
+      6.  **IDE-Native First**: 利用 IDE 原生能力驱动执行节奏，本协议定义质量标准和检查点，不对抗 IDE 的规划/执行机制。
     </principles>
 </meta>
 
@@ -21,15 +22,10 @@
     1. 解析触发命令中的 `[file_path]`：
        - 如提供了路径 → 读取该文件
        - 如未提供路径 → 依次查找 `scope-brief.md`（项目根）、`[[__DOCS_DIR__]]/scope-brief.md`
+       - 如用户通过自然语言描述需求进入（无 file_path 参数）且上述文件均不存在 → 跳转 `<fallback_interview>`
        - 如均不存在或为空 → 跳转 `<fallback_interview>`
 
-    2. 解析 Brief 各 Section，提取：
-       - 需求名称和描述
-       - 任务清单
-       - 已有设计决策
-       - 边界与约束（不做的事、时间、依赖、技术限制）
-       - 受影响的已有任务
-       - 参考资料
+    2. 解析 Brief 各 Section，提取：需求名称和描述、任务清单、已有设计决策、边界与约束、受影响的已有任务、参考资料。
 
     > Brief 是一次性输入文件，处理完成后用户可自行删除。
 
@@ -37,13 +33,9 @@
 </step_0_ingest>
 
 <step_1_load>
-    **Role**: 系统分析师
     **Action**:
-    1.  **Read Vision**: `[[__DOCS_DIR__]]/global/vision.md` — 仅读北极星指标和 Boundaries 段落；其余章节跳过。
-    2.  **Read Roadmap**: `[[__DOCS_DIR__]]/global/roadmap.json` — 仅提取每个 task 的 `id/title/status/deps/tag` 字段（跳过 `goal/notes`，需求分解不需要这些详情）；读取当前最大 ID 水位用于新任务编号。
-    3.  **Read Tech Stack**: `02_tech_stack.md` — 技术约束。
-    4.  **Read Map**: `[[__DOCS_DIR__]]/global/map.json` — 仅读 `directoryMapping` 和 `featureRelations`；`logicalTopology` 和 `criticalUserJourneys` 跳过。
-    5.  **Scan Tasks**: 扫描 `[[__DOCS_DIR__]]/tasks/` 目录 — 了解已有 Task 概要（标题 + 关键流程，无需全文）。
+    1.  **Load**: vision.md（仅北极星+Boundaries）、roadmap.json（仅 id/title/status/deps/tag + 当前最大 ID 水位）、02_tech_stack.md、map.json（仅 directoryMapping + featureRelations）。
+    2.  **Scan Tasks**: 扫描 tasks/ 目录 — 了解已有 Task 概要（标题+关键流程，无需全文）。
 
     **Output**: 内部上下文摘要，进入 `<step_2_analysis>`。
 </step_1_load>
@@ -54,64 +46,33 @@
 
     **Action**:
 
-    1. **Vision 对齐检查**: Brief 需求是否与 vision.md 的北极星指标一致？如有偏离 → 在输出中标注 `[Vision 偏离警告]`。
-    2. **任务清单完整性**: Brief 任务清单是否足以支撑需求目标？
-    3. **影响评估**: Brief 中"受影响的已有任务" → 对照 roadmap/tasks 验证是否存在、状态如何。
-    4. **缺口识别**: 检查 Brief 是否有关键信息缺失。
-    5. **联动检查**: 读取 `map.json.featureRelations`，将新任务的描述与各条 `sources` 字段做语义对比，判断新任务是否属于某聚合方的覆盖范围。命中时在摘要中输出联动提示。
+    1. **Vision 对齐检查**: Brief 需求是否与 vision.md 北极星一致？偏离 → 标注 `[Vision 偏离警告]`。
+    2. **任务清单完整性**: 是否足以支撑需求目标？
+    3. **影响评估**: Brief 中"受影响的已有任务" → 对照 roadmap/tasks 验证。
+    4. **缺口识别**: Brief 是否有关键信息缺失。
+    5. **联动检查**: [[SUBAGENT: archi-feature-relations|mode: check, context: 将新任务描述与 featureRelations sources 做语义对比，命中时输出联动提示]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-feature-relations/SKILL.md`，按 mode: check 的逻辑执行）]]
 
-    **缺口分级**:
-    - **必须**: 缺失则无法合理分解（如任务清单为空）
-    - **可补**: AI 可推导但建议确认（如依赖关系不明确）
-    - **建议**: AI 可自行决定（如任务分组方式）
+    **缺口分级**: 必须 → 无法分解 | 可补 → AI 可推导建议确认 | 建议 → AI 自决
 
-    **Decision**:
-    - 无"必须"级缺口 + 无"可补"级缺口 → 跳过 Step 2.5，直接进入 Step 3
-    - 有缺口 → 进入 Step 2.5
+    **Decision**: 无"必须"+"可补"缺口 → 跳 Step 3 | 有缺口 → 进入 Step 3
 
-    **Output**: 向用户输出 Brief 分析摘要：
-    ```
-    ### SCOPE BRIEF 分析报告
-    > **需求**: [名称] | **规模**: 预估 [N] 个任务
-
-    **Vision 对齐**: [一致 / ⚠️ 偏离 — 原因]
-
-    **已确认信息**:
-    - [列表]
-
-    **受影响的已有任务**:
-    | 任务 | 状态 | 预估影响 |
-    |:---|:---|:---|
-    | [ID: 名称] | [done/active/stub] | [需修改/需扩展/无影响] |
-
-    **[?有命中] 联动提示**:
-    | 聚合方 | checkNote |
-    |:---|:---|
-    | [aggregator ID/路径] | [checkNote 内容] |
-
-    **信息缺口** (须补充):
-    - [缺口列表]
-
-    **AI 将自动决定** (无需操作):
-    - [列表]
-    ```
+    **Output**: 向用户输出 SCOPE BRIEF 分析报告 — 含需求名/预估规模、Vision 对齐状态、已确认信息、受影响已有任务表（任务/状态/预估影响）、（有命中）联动提示表、信息缺口、AI 自动决定项。进入 step_3_supplementary（有缺口）或 step_4_decompose（无缺口）。
 </step_2_analysis>
 
-<step_2_5_supplementary>
-    **Role**: 产品顾问
+<step_3_supplementary>
     **Trigger**: 仅当 Step 2 发现"必须"或"可补"级缺口时执行。
     **Input**: Step 2 的缺口列表。问题数上限 3 题。
 
-    [[SKILL: 按 `archi-interview-protocol` Skill 的核心规则和标准输出格式提问。]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-interview-protocol/SKILL.md` 并遵循其规则）]]
-</step_2_5_supplementary>
+    [[SKILL: archi-interview-protocol|按 skill 的核心规则和标准输出格式提问。]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-interview-protocol/SKILL.md` 并遵循其规则）]]
+</step_3_supplementary>
 
-<step_3_decompose>
+<step_4_decompose>
     **Role**: 首席架构师
     **Input**: Brief 全文 + 项目上下文 + 补充回答（如有）。
 
-    **Action**: [[SKILL: 按 `archi-decompose-roadmap` Skill 的协议，基于 Scope Brief 任务清单生成增量任务数据]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-decompose-roadmap/SKILL.md` 并遵循其协议执行）]]
+    **Action**: [[SKILL: archi-decompose-roadmap|按 skill 的协议，基于 Scope Brief 任务清单生成增量任务数据。]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-decompose-roadmap/SKILL.md` 并遵循其协议执行）]]
 
-    **展示格式**（将 Skill 产出的任务数据转换为以下格式，向用户呈现后等待确认）：
+    **展示格式**（将 Skill 产出转换为以下格式，向用户呈现后等待确认）：
 
     ```
     #### Phase 1: Infrastructure
@@ -121,45 +82,45 @@
     | ID | 标题 | 描述摘要 | 依赖 | 标签 |
 
     #### Execution Batches（并行执行批次）
-    （从 deps 拓扑排序推导，列出每批可同时开工的任务）
     Batch 1（立即可开工）: ...
     Batch 2（等 Batch 1 全完）: ...
 
     #### NFR 横切关注点（已归并，不入 Roadmap）
-    （来自 Skill 的 NFR 归并清单）
     - [NFR 名称] → 注入 [任务 ID] | 影响：[其他任务 ID]
     ```
 
-    **Gate**: 用户回复 **OK** 后进入 step_4；未确认禁写入 Roadmap。用户可在确认前修正方案（合并/拆分/调整依赖）。
-</step_3_decompose>
+    **Gate**: 用户回复 **OK** 后进入 step_5_roadmap_update；未确认禁写入 Roadmap。
+</step_4_decompose>
 
-<step_3_5_refinement>
-    **Role**: 咨询顾问
+<step_4_5_refinement>
     **Trigger**: 用户回复非 OK，含合并/拆分/增删/依赖调整等修正。
     **Action**: 融入用户反馈，刷新分解方案重新输出，等待再次确认。
-</step_3_5_refinement>
 
-<step_4_roadmap_update>
-    **Role**: 系统管理员
+    用户回复 OK → 进入 step_5_roadmap_update。
+</step_4_5_refinement>
+
+<step_5_roadmap_update>
     **Input**: 用户确认的分解方案。
 
     **Action**:
-    1.  将新任务追加到 `[[__DOCS_DIR__]]/global/roadmap.json` 对应 Phase 的 `tasks` 数组中。
+    1.  将新任务追加到 roadmap.json 对应 Phase 的 `tasks` 数组中。
     2.  如需新增 Phase → 追加到 `phases` 数组。
-    3.  更新 `lastUpdated` 字段。
-    4.  [?新模块] 更新 `[[__DOCS_DIR__]]/global/map.json` 的 `directoryMapping`：为新增任务预注册推断的模块路径（基于 tech_stack 架构模式和任务描述推断，仅目录级别；详细内容在 `/archi.plan` 时完善）。
+    3.  更新 `lastUpdated`。
+    4.  （新模块）更新 map.json `directoryMapping`：为新增任务预注册推断的模块路径。
 
-    **Terminal Gate** (禁止跳过，须在输出总结前全部完成):
-    | 步骤 | 命令 | 通过条件 |
-    |:---|:---|:---|
-    | 1 | `npx archi task --check` | 无 ERROR 级问题 |
-    | 2 | `npx archi render` | `.md` 视图生成完成 |
+    **Terminal Gate** (禁止跳过): 标准检查 (task --check + render)。
+
+    **Output**: 写入确认。进入 step_6_signoff。
+</step_5_roadmap_update>
 
-    **Output**: 写入确认。
-</step_4_roadmap_update>
+<step_6_signoff>
+    **Pre-signoff Checklist** (输出前须逐项确认):
+    □ 分解方案已获用户明确确认（回复 OK 后才写入 roadmap — step_4 Gate）
+    □ roadmap.json — 任务已追加（非覆盖），lastUpdated 已更新
+    □ （有新模块）map.json directoryMapping — 新任务模块路径已预注册
+    □ step_5 Terminal Gate — task --check + render 已通过
 
-<step_5_signoff>
-    **Action** (Gate 须在 step_4 完成):
+    **Action** (Gate 须在 step_5 完成):
     1.  运行 `npx archi task` 输出任务进度概览。
     2.  输出总结。
 
@@ -171,28 +132,27 @@
 
     | 优先级 | 动作 | 说明 |
     |:---|:---|:---|
-    | [?UI] 推荐 | 运行 `archi-ui-wireframe` Skill（追加模式） | 为新增任务追加屏幕到 `ui_concept.html`，同步更新 `ui_context.md` |
+    | （仅ui项目） 推荐 | [[SKILL: archi-ui-wireframe|运行 skill（追加模式）]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-ui-wireframe/SKILL.md` 并遵循其协议执行）]] | 为新增任务追加屏幕到 `ui_concept.html` |
     | 1 | `/archi.plan <第一个 pending 任务 ID>` | 对首个可执行任务做深度规划 |
     | 2 | 审查 roadmap | 确认依赖关系和优先级 |
-</step_5_signoff>
+</step_6_signoff>
 
 <fallback_interview>
-    **Trigger**: Brief 文件不存在或为空。
-    **Role**: 产品顾问
+    **Trigger**: Brief 文件不存在或为空，或用户以自然语言描述需求进入。
 
     **Action**:
-    1. 告知用户 `scope-brief.md` 未找到。建议：
+    1. 告知用户将通过对话梳理需求。建议：
        - 运行 `npx archi template scope-brief` 获取模板到项目根目录
        - 填写后重新运行 `/archi.scope scope-brief.md`
        - 或继续对话，通过访谈方式提供信息
-    2. 如用户选择继续对话，按以下顺序引导：
-       a. 这次要做什么？（需求名称、一句话描述、动机）
-       b. 包含哪些任务？（具体任务列表）
-       c. 有什么约束？（不做的事、依赖、技术限制）
-       d. 会影响哪些已有任务？
-    3. 收集完毕后，将信息写入 `scope-brief.md`（项目根目录），然后跳转 `<step_1_load>`。
-
-    > 此模式为向后兼容，核心流程仍以 Brief 为准。
+    2. 如用户选择继续对话，按以下维度引导（已知信息可跳过，每个维度 1-2 题）：
+       a. **动机与目标**: 为什么要做这个？解决什么问题？期望达成什么效果？
+       b. **范围**: 包含哪些功能/模块？不包含什么？
+       c. **任务拆分**: 心中有没有大致的任务划分？（没有则 AI 在 step_3 代为拆分）
+       d. **约束**: 技术限制、时间约束、依赖？
+       e. **影响**: 会影响哪些已有功能？
+    3. 收集完毕后，将信息写入 `scope-brief.md`（项目根目录），格式遵循 scope-brief 模板结构。
+    4. 告知用户 brief 已生成，然后跳转 `<step_1_load>` 继续执行。
 </fallback_interview>
 
 </protocol_scope>