architext 0.0.2

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

@@ -0,0 +1,131 @@
+<protocol_map>
+  **Trigger**: `/archi.map`
+  **Goal**: 扫描项目实际目录结构，与 `map.json` 比对，识别新增/过期/变动，经用户确认后更新架构地图。
+
+<meta>
+    <style>Systematic, Precise, Architecture-Aware</style>
+    <language>简体中文</language>
+    <principles>
+      1.  **Scan vs Map**: 以实际文件系统为 Ground Truth，map.json 为旧快照。
+      2.  **Smart Granularity**: 默认目录级；单文件承载多职责时须细化到文件级。
+      3.  **Architecture Inference**: 新条目的层级归类须参考现有 map 模式 + `02_tech_stack.md`。
+      4.  **Batch Confirm**: 所有变更一次性展示，用户批量确认。
+    </principles>
+</meta>
+
+<step_1_scan>
+    **Role**: 测量员
+    **Action**:
+    1.  **Read Map**: 读取 `[[__DOCS_DIR__]]/global/map.json` — 当前架构地图。
+    2.  **Read Tech Stack**: 读取 `02_tech_stack.md` — 目录结构约定、架构模式。
+    3.  **Scan Directory Tree**: 扫描项目目录结构。
+        - **排除**: `.git/`, `node_modules/`, `dist/`, `build/`, `[[__DOCS_DIR__]]/`, 及 `.gitignore` 中声明的路径。
+        - **深度**: 跟随 map.json 现有条目的粒度模式。如现有条目含文件级 → 扫描时也到文件级。
+
+    **Output**: 内部数据（实际目录树 + 现有 map 结构），不输出给用户。
+</step_1_scan>
+
+<step_2_diff>
+    **Role**: 比对分析师
+    **Action**: 将实际目录树与 map.json 逐条比对，归类为三种差异。
+
+    | 差异类型 | 判定条件 | 处理 |
+    |:---|:---|:---|
+    | **新增** (New) | 实际存在但 map 中无记录 | 须归类后登记 |
+    | **过期** (Stale) | map 中有记录但实际已不存在 | 直接移除 |
+    | **疑似重命名** (Renamed) | map 中的路径不存在，但有一个新路径结构/内容高度相似 | 标记为重命名候选 |
+
+    ### 文件级检测
+
+    对新增目录中的文件做快速扫描（读取导出/声明），识别**单文件多职责**的情况：
+    - 一个文件导出多个不相关的 class/function/module
+    - 一个入口文件聚合注册了多个子模块（如路由注册、Store 注册）
+    - 一个文件同时服务多个 Task
+
+    发现此类文件 → 粒度细化到文件级，在 map 中单独登记并描述其包含的职责。
+
+    **Output**: 差异列表（内部），进入 step_3。
+</step_2_diff>
+
+<step_3_classify>
+    **Role**: 首席架构师
+    **Action**: 对新增条目做架构归类。
+
+    ### 归类策略
+
+    1.  **模式匹配**: 参考 map.json 中同层级已有条目的归类。如 `src/services/auth/` 属于 "Service Layer"，则 `src/services/payment/` 大概率也属于 "Service Layer"。
+    2.  **Tech Stack 约定**: `02_tech_stack.md` 中定义的目录结构规则（如 "commands/ 下为 Task Layer"）。
+    3.  **内容推断**: 读取文件内容（import 关系、导出类型），判断其架构角色。
+    4.  **无法确定**: 标记为 `[?]`，交由用户在确认阶段指定。
+
+    对每个新增条目填充：
+    - `path`: 目录或文件路径
+    - `layer`: 架构层级
+    - `description`: 一句话描述职责
+    - `[?文件级]` `contains`: 该文件包含的子职责列表
+
+    **Output**: 已归类的新增条目列表（内部），进入 step_4。
+</step_3_classify>
+
+<step_4_propose>
+    **Role**: 咨询顾问
+    **Action**: 向用户展示完整变更清单。
+
+    **Output**:
+    ```
+    ### 架构地图变更提案
+
+    **扫描范围**: [项目根目录]
+    **当前 map 条目数**: N | **变更后**: M
+
+    ---
+
+    #### 过期条目 (将移除)
+    | 路径 | 原层级 |
+    |:---|:---|
+    | src/legacy/old-module/ | Service Layer |
+
+    #### 新增条目 (将登记)
+    | 路径 | 层级 | 描述 | 粒度 |
+    |:---|:---|:---|:---|
+    | src/services/payment/ | Service Layer | 支付服务模块 | 目录 |
+    | src/utils/validators.ts | Shared Layer | 表单校验 + 数据校验 + API 参数校验 | 文件 |
+    | src/routes/api.ts [?] | [待指定] | 聚合注册多条 API 路由 | 文件 |
+
+    #### 疑似重命名
+    | 原路径 | 新路径 | 置信度 |
+    |:---|:---|:---|
+    | src/helpers/ | src/utils/ | 高 (文件内容匹配) |
+
+    ---
+    > 回复 **OK** 确认全部；或指定修改：
+    > - "src/routes/api.ts 属于 App Layer"
+    > - "src/helpers/ 不是重命名，保留原条目"
+    > - "新增 src/config/ 为 Config Layer"
+    ```
+
+    **Gate**: 用户确认后进入 step_5。
+</step_4_propose>
+
+<step_5_apply>
+    **Role**: 系统管理员
+    **Action**:
+    1.  按用户确认的变更清单更新 `[[__DOCS_DIR__]]/global/map.json`：
+        - 移除过期条目
+        - 添加新增条目（含层级、描述）
+        - 处理重命名（更新路径，保留其他元数据）
+    2.  更新 `lastUpdated` 字段。
+
+    **Terminal Gate** (禁止跳过，须在输出总结前全部完成):
+    | 步骤 | 命令 | 通过条件 |
+    |:---|:---|:---|
+    | 1 | `npx archi render` | `.md` 视图生成完成 |
+
+    **Output**: 更新摘要：
+    - **移除**: N 条过期条目
+    - **新增**: N 条（含 M 条文件级）
+    - **重命名**: N 条
+    - **当前 map 总条目数**: X
+</step_5_apply>
+
+</protocol_map>

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

@@ -0,0 +1,253 @@
+<protocol_plan>
+  **Trigger**: `/archi.plan <ID> [context]`
+  **Goal**: 通过深度架构访谈，定义功能的 Spec/UI/Plan。
+  **Input**:
+  - `<ID>` (必填): Roadmap 中已存在的任务 ID。须先通过 `/archi.scope` 或 `/archi.inherit` 创建任务。
+  - `[context]` (可选): 任务的已知上下文（如用户需求描述、参考资料、约束条件）。提供时作为 step_2 访谈的前置输入，减少提问。
+
+<constraints_cursor>
+    **Mode Lock**: 本协议须在 **Agent Mode (Normal Mode)** 下执行。禁切换到 Plan Mode 或其他只读模式。
+</constraints_cursor>
+
+<meta>
+    <style>Architectural, Exhaustive, Strict, Technology-Agnostic</style>
+    <language>简体中文</language>
+    <principles>
+      1.  **Global First**: 局部功能的诞生须伴随全局索引 (Map/Data/Dict) 的更新。
+      2.  **AI-Native Perspective**: 所有选项 Pros/Cons 从 AI Agent 视角撰写。关注：Context Locality、Type Safety、Boilerplate、Ambiguity。
+      3.  **Flexible Interaction**: 选项为启发式建议，支持多选、混合或自定义。
+      4.  **Audit-Gated**: 只有通过审计的文档才能交付。
+    </principles>
+</meta>
+
+<step_1_load>
+    **Role**: 系统分析师
+    **Action**:
+    1.  **Read Roadmap**: 读取 `[[__DOCS_DIR__]]/global/roadmap.json`。
+        - **Pre-flight**: 仅读取 `<ID>` 对应的任务条目及其直接 deps 的 `id/title/status`；检查 deps 是否已完成，未完成则拒绝 Plan（除非用户强制）。无需加载其他任务数据。
+    2.  **Read Vision**: 读取 `[[__DOCS_DIR__]]/global/vision.md` — 仅提取北极星指标和设计哲学段落；其余章节跳过。
+    3.  **Read Tech Stack**: `02_tech_stack.md` (技术红线 + **Section 9 项目约定**)。
+        - 提取 Section 9 中的全局架构约定（Error Handling / Data Flow / Auth & Access），供 step_2 约定继承使用。
+    4.  [?UI] **Read Design Tokens**: `[[__DOCS_DIR__]]/global/design_tokens.json`。
+    4.5 [?UI] **Read UI Context**: `[[__DOCS_DIR__]]/global/ui_context.md`（如存在）。
+        - 从屏幕索引中定位本功能对应的屏幕 ID（如 S-03）及其负责的状态。
+        - 锁定屏幕范围，供 step_4 生成 `ui.md §1` 时直接填入，禁自行发明新屏幕 ID。
+        - 若 `ui_context.md` 不存在 → 跳过，`ui.md` 按完整 ITP 格式填写。
+    5.  [?Data] **Read Data Model**: `[[__DOCS_DIR__]]/global/data_snapshot.json`。
+    6.  **Read Dependency Context** (如有依赖任务):
+        - 仅读依赖任务 `spec.md` 的 Interface/Type 定义段（`## Interface` 或 `## Types` 章节）；不读 Scenarios 等其余内容。
+        - 仅当当前 spec/plan 出现 `ref: tasks/<dep_id>/spec.md#X` 引用时执行；无引用时跳过。
+        - **Stub 兼容**: 如依赖任务的 Spec-Status 为 Stub，从 stub"关联文件"提取源码，读入口文件提取公共接口/导出类型，作为上游接口参考。
+        - 避免重复定义上游接口，确保对接点精确对齐。
+
+    **Output**: 向用户输出 **Task Context Brief**：
+    ```
+    ### Task Context: [功能名称] ([ID])
+
+    **目标**: [roadmap task 的 goal，如含 [用户预设] 须高亮标注]
+    **上游依赖**: [已完成的依赖任务及其关键接口/类型，无则写"无"]
+    **项目特征**: [已激活的 UI/Data/CLI/Lib/API 标签]
+    **技术约束**: [来自 02_tech_stack.md 的关键红线]
+    **设计哲学**: [来自 vision.md 的北极星指标和设计原则]
+    **项目约定**: [来自 02_tech_stack.md §9 — Error Handling: X | Data Flow: X | Auth: X，无则写"未设置"]
+    ```
+    内部保留完整上下文素材，进入 step_2。
+</step_1_load>
+
+<step_1_5_complexity>
+    **Role**: 产品顾问
+    **Action**: 评估功能复杂度，决定是否走完整 step_2 流程：
+
+    **① 粒度红线检查（优先于复杂度判定）**：
+
+    | 指标 | 上限 |
+    |:---|:---|
+    | 预估 spec.md Scenario 数 | ≤ 6 个 |
+    | 预估 plan.json Phase 数 | ≤ 4 个 |
+
+    > 预估方法：根据 step_1 加载的 roadmap task goal 和依赖上下文，快速列举核心行为路径数量。超出上限即触发，无需精确计算。
+
+    **② 复杂度判定（粒度通过后执行）**：
+
+    | 信号 | 判定 | 流程 |
+    |:---|:---|:---|
+    | 无依赖 + 无新实体 + 无架构决策 + 预估 ≤3 tasks | **Simple** | 跳过 step_2 访谈，直接生成 spec + plan |
+    | 有依赖 或 有新实体 或 需架构决策 | **Standard** | 正常执行 step_2 Unified Proposal |
+
+    **Simple 模式**:
+    - 跳过 5 维度架构建议和 User Confirm Gate
+    - spec 精简为 1-2 个 Gherkin 场景
+    - plan 精简为单 Phase
+    - signoff 时确认（替代 step_2 的 Gate）
+</step_1_5_complexity>
+
+<step_2_interview>
+    **Role**: 架构师
+
+    ---
+
+    ### Unified Proposal (一次性提案)
+
+    **核心原则**: 将功能设计和架构决策**合并为一次输出**，用户一次确认或覆写即可。
+
+    **Action**:
+
+    #### Part 1: Task Design (功能设计)
+
+    AI 根据功能性质**自行决定输出哪些模块**，从以下素材库中选取适用项：
+
+    | 素材 | 适用场景 |
+    |:---|:---|
+    | 流程描述（用户旅程/系统流程/命令流程） | 有多步交互或处理链时 |
+    | 核心实体与数据 | 涉及新增或修改实体时；已有实体用 `→ ref: data_snapshot.json#EntityName` 引用 |
+    | 交互面（页面/命令/端点/方法） | 有用户或外部接触面时 |
+    | 已有决策 | goal 含 `[用户预设]` 时 → 高亮标注，严格遵守 |
+
+    **引用规则**:
+    - global 中已定义的实体/类型 → `ref: data_snapshot.json#X`，仅描述本功能**新增或修改**的部分
+    - 设计哲学/原则 → `ref: vision.md#原则名`，无需复述
+    - 上游接口 → `ref: tasks/<dep_ID>/spec.md#接口名`
+    - 已有设计 Token/组件 → `ref: design_tokens.json#preset` / `ref: dictionary.json#component`
+
+    **通用要求**: 用此功能的具体实体名、操作名描述，禁泛化
+
+    #### Part 2: Architecture Recommendations (架构建议)
+
+    [[SKILL: 按 `archi-plan-options` Skill 的三步选用逻辑（约定继承 → 标签路由 → 推荐 vs 展开），从五个维度的选项库中为本功能生成架构建议]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-plan-options/SKILL.md` 并遵循其三步选用逻辑执行）]]
+
+    展开 Q-table 时，格式遵循 [[SKILL: `archi-interview-protocol` Skill 的标准输出格式]][[NO-SKILL: `[[__DOCS_DIR__]]/skills/archi-interview-protocol/SKILL.md`]]。
+
+    #### Output Format
+
+    ```
+    ## Task Proposal: [功能名称] ([ID])
+
+    ### 功能设计
+    [按复杂度级别输出，见上方 Part 1]
+
+    ### 架构建议
+    | 维度 | 推荐 | 来源 | 理由 |
+    |:---|:---|:---|:---|
+    | 核心结构 | [推荐选项] | 功能推荐 | [结合此功能的 1-2 句理由] |
+    | 交互模式 | [推荐选项] | 功能推荐 | [理由] |
+    | 错误处理 | [项目约定值] | 项目约定 | ref: 02_tech_stack.md §9 |
+    | ... | ... | ... | ... |
+
+    [仅对需要用户裁决的维度展开选项表]:
+    **[Q<n>] 问题标题**
+    > 为什么需要用户决定（一句话）
+
+    | ID | 选项 | 说明 | AI+ | AI- |
+    |:---|:---|:---|:---|:---|
+    | A [推荐] | ... | 具体行为（2-3句） | 完整句子 | 完整句子 |
+    | B | ... | ... | ... | ... |
+    | Z | 自定义 | (请描述) | - | - |
+
+    ---
+    > 回复 **OK** 接受全部建议；或标注要修改的部分，如：
+    > - 设计修正: "注册不需要邮箱验证步骤"
+    > - 维度覆写: "核心结构=C, 错误处理=B D"
+    > - 问题回答: "Q1=B"
+    ```
+
+    **Goal**: 锁定 `spec`, `ui`(如适用), `data_snapshot.json`(如适用)。
+
+    **⌨️ INPUT**: 回复 **OK** 全部接受；或自由文本标注修改项。无需按固定格式。
+</step_2_interview>
+
+<step_2_5_refinement>
+    **Role**: 咨询顾问
+    **Trigger**: 用户回复非 OK，含修正、疑问、覆写或明显逻辑冲突。
+    **Action**: 不生成文档。融入用户反馈，刷新 Unified Proposal 重新输出，等待再次确认。
+    - 如是功能设计疑问 → 给出替代方案对比，重新提出设计
+    - 如是架构维度疑问 → 结合此功能具体场景解释差异，更新推荐
+    - 如是维度覆写 → 直接替换推荐并调整相关设计
+</step_2_5_refinement>
+
+<step_3_global_sync>
+    **Role**: 系统管理员
+    **Constraint**: 在生成 Task 文档**之前**，须先更新以下全局文件。
+
+    **Boundary**: 仅注册**项目业务域**内容。Architext 框架概念（scripts、scaffold、roadmap、plan 等）和框架基础设施错误禁注册到全局文件。
+
+    **Action Checklist**:
+    1.  **`map.json`**: 在 `directoryMapping` 注册 `[[__DOCS_DIR__]]/tasks/<ID>_<Slug>`；在 `logicalTopology` 定义模块职责与依赖。
+    2.  **`dictionary.json`**: 提取提案中的**项目业务**新术语填入 `entities`/`verbs`；注册新共享工具到 `utilities`；注册新公共组件到 `components`。
+    3.  [?Data] **`data_snapshot.json`**: 根据架构建议中核心结构的选择新增/修改 Schema。禁写"待定"，须写出字段名和类型。
+    4.  **`error_codes.json`**: 根据架构建议中错误处理的选择注册新**业务**错误码。框架脚本错误由 exit code + stderr 处理，禁注册。
+    5.  **`map.json` featureRelations**: 判断本 Task 是否属于「聚合型 Task」——即其核心职责是**列举、汇总或动态反映**其他一类 Task（如「列出所有命令」「汇总所有页面入口」「注册所有路由」）。若是，在 `featureRelations` 中追加一条记录：
+        ```json
+        {
+          "aggregator": "<本 Task ID 或文件路径>",
+          "sources": "<一句话描述聚合来源范围，如'所有 CLI 命令类 Task'>",
+          "evidence": "<依据，如'spec.md §X 描述本 Task 会动态列出所有 Y 类 Task'>",
+          "checkNote": "此类 Task 新增或删除时，检查 <aggregator> 是否需要同步"
+        }
+        ```
+        若非聚合型 Task，跳过此步。
+
+    **Output**: 上述文件的变更 Diff (简要)。
+</step_3_global_sync>
+
+<step_4_generate>
+    **Role**: 文档工程师
+    **Input**: 确认的 Unified Proposal（功能设计 + 架构建议）+ 已更新的全局上下文。
+    **Action**: 在 `[[__DOCS_DIR__]]/tasks/<ID>_<Slug>/` 下生成标准文档。
+
+    **1. `spec.md`** (必须):
+    - 模板: `templates/spec.template.md`。
+    - 基于确认的功能设计和架构建议，转化为 Gherkin Scenarios。
+    - 每个 Scenario 须对应功能设计中的具体流程步骤或异常路径，禁凭空编造场景。
+    - 若为上游任务，须包含明确的 Interface/Type 定义。
+
+    **2. `ui.md`** [?UI]:
+    - 模板 `templates/ui.template.md`。
+    - **有 `ui_context.md`（主路径）**:
+      1. **UI 偏差检查**（写 `ui.md` 前必须执行）：对比 step_2 确认的功能设计与 `ui_context.md` 中的屏幕索引，识别偏差：
+
+         | 偏差类型 | 判定标准 | 处理方式 |
+         |:---|:---|:---|
+         | 无偏差 | 屏幕索引与设计一致 | 直接写 `ui.md`，引用屏幕 ID |
+         | 轻微增量 | 新增状态/弹窗/局部区域，不改整体布局 | 调用 `archi-ui-wireframe` Skill（Plan 细化模式）更新 `ui_concept.html` + `ui_context.md`，在 `ui.md` 注明 `MODIFIED: S-XX` |
+         | 结构性偏差 | 布局重构、新增独立屏幕、流程路径变化 | **暂停**，向用户输出偏差说明，等待 **OK** 后调用 Skill 更新 `ui_concept.html` + `ui_context.md`，再写 `ui.md` |
+
+      2. 完成偏差处理后，按 `ui.template.md` 填写屏幕范围声明和差异组件。
+    - **无 `ui_context.md`（降级路径）**: 按完整 ITP v3.0 描述组件树，引用 `design_tokens.json` Token 定义。
+
+    **3. `plan.json`** (必须):
+    - 模板: `templates/plan.template.json`。
+    - 根据项目类型动态调整 Phase；确保每个 Task 上下文自包含。
+    - 任务描述中明确 "Additive Only" + "Respect Unknowns"。
+    - **`decisions`**: 按各维度填写；`choice` 支持多选（如 `A B`，空格分隔）、自定义（`Z: …`）；`rationale` 须填写理由，供 code 阶段参照，禁留空。
+    - **`notes`**: 每个 task 的 `notes` 须填写：`[范围] · [spec 引用] · [关键约束] · 验证: [具体操作]`；供 `/archi.code` step_4 精确定位并执行 e2e，禁留空。
+      > 示例：`实现 POST /auth/login · spec §3.1 · JWT 禁含 password · 验证: curl POST /auth/login 返回 200 + token 字段`
+    - 生成后运行 `npx archi render` 生成可读的 `.md` 视图。
+</step_4_generate>
+
+<step_5_audit>
+    **Role**: 首席审计官
+    **Checklist**:
+    1.  **Design Fidelity**: Spec 中的 Scenarios 是否完整覆盖确认的功能设计（流程步骤和异常路径）？
+    2.  **Tech Consistency**: 是否用了未声明技术？
+    3.  **Data Integrity**: Scenario 中的实体和字段是否与确认的核心实体一致？
+    4.  **Error Handling**: 是否覆盖架构建议中错误处理的选择？
+    5.  **AX Compliance**: 是否遵守 Anti-Clobbering 和 Interface Stability？
+
+    如有问题则静默修正；严重问题标记 `⚠️ Risk Warning`。
+</step_5_audit>
+
+<step_6_signoff>
+    **Terminal Gate** (禁止跳过，须在输出总结前全部完成):
+    | 步骤 | 命令 | 通过条件 |
+    |:---|:---|:---|
+    | 1 | `npx archi task --check` | 无 ERROR 级问题 |
+    | 2 | `npx archi task <ID> --status active` | 任务已标记为进行中 |
+    | 3 | `npx archi render` | `.md` 视图生成完成 |
+
+    **Action** (Gate 通过后):
+    1.  输出总结。
+
+    **Output**: Task 定义摘要，含架构建议确认表（各维度最终选择及理由）和 Next Steps 表格。
+</step_6_signoff>
+
+</protocol_plan>

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

@@ -0,0 +1,162 @@
+<protocol_remove>
+  **Trigger**: `/archi.remove <id>`
+  **Goal**: 将指定 Task 从项目中彻底下线——删除文档、代码、全局引用，确保零残留。
+
+<meta>
+    <style>Surgical, Cautious, Thorough</style>
+    <language>简体中文</language>
+    <principles>
+      1.  **Dependency Safety**: 有其他任务依赖此 Task 时，须先解除依赖才能继续。
+      2.  **Confirmation Gate**: 删除操作不可逆，须向用户展示完整影响并获得明确确认。
+      3.  **Zero Residue**: 清理须覆盖全部关联层面（文档/代码/全局数据/寻址条目）。
+      4.  **No Side Effects**: 仅删除目标 Task 相关内容，禁触碰无关文件。
+    </principles>
+</meta>
+
+<step_1_resolve>
+    **Role**: 系统分析师
+    **Action**:
+    1.  **Resolve ID**: 从 `[[__DOCS_DIR__]]/global/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` — 代码↔文档关联
+
+    **Output**: 目标 Task 基本信息（ID、名称、状态、关联文件数）。
+</step_1_resolve>
+
+<step_2_impact>
+    **Role**: 影响评估官
+    **Action**: 逐层扫描，生成影响清单。
+
+    ### 2.1 依赖检查（阻塞级）
+
+    扫描 `roadmap.json` 中所有任务的 `deps` 字段，找出依赖 `<id>` 的任务。
+
+    | 情况 | 处理 |
+    |:---|:---|
+    | 无下游依赖 | 通过，继续 |
+    | 有下游依赖且状态为 `pending`/`blocked` | 列出受影响任务，询问用户：移除依赖关系后继续，还是中止 |
+    | 有下游依赖且状态为 `active`/`done` | **阻塞** — 这些任务可能已使用该 Task 的接口/组件。须先用 `/archi.edit` 解耦后再移除 |
+
+    ### 2.2 代码文件识别
+
+    通过以下方式定位该 Task 的代码文件：
+    1.  `99_context_glue.md` 中与 `<id>` 关联的代码路径。
+    2.  `map.json` 中该 Task 注册的模块/目录。
+    3.  `plan.json` 中任务提及的文件路径。
+    4.  扫描代码目录，查找以 Slug 命名或在目录结构中明确归属的文件。
+
+    ### 2.3 全局引用扫描
+
+    | 文件 | 扫描内容 |
+    |:---|:---|
+    | `roadmap.json` | 任务条目 + 其他任务 `deps` 中的引用 |
+    | `map.json` | 模块注册条目 + `featureRelations` 中以被删 Task 为 aggregator 的条目 |
+    | `99_context_glue.md` | 关联条目 |
+    | `dictionary.json` | 该 Task 独占的术语（仅标记，不自动删） |
+    | `error_codes.json` | 该 Task 独占的错误码（仅标记，不自动删） |
+
+    ### 2.4 聚合联动检查
+
+    读取 `map.json.featureRelations`，判断被删 Task 是否属于某聚合方的 `sources` 覆盖范围。
+
+    | 情况 | 处理 |
+    |:---|:---|
+    | 不在任何聚合方的 sources 范围内 | 无需特殊处理 |
+    | 在聚合方 sources 范围内 | 在影响报告中列出，提示删除后须检查聚合方内容是否需要同步移除 |
+    | 被删 Task 本身是 aggregator | 同时移除 `featureRelations` 中该条记录 |
+
+    ### 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 条关联
+
+    **[?有]术语/错误码残留** (须人工确认):
+    - dictionary.json: [term1], [term2]
+    - error_codes.json: [ERR_XXX]
+
+    **[?有]聚合联动** (须检查):
+    | 聚合方 | checkNote |
+    |:---|:---|
+    | [aggregator ID/路径] | [checkNote 内容] |
+
+    **[?有]跨 Task 引用 [Breaking]**:
+    | 引用方 | 引用内容 | 建议 |
+    |:---|:---|:---|
+    | FEAT-005 spec.md | 调用了 <id> 的 UserAPI | 先 /archi.edit FEAT-005 解耦 |
+
+    ---
+    > 回复 **OK** 确认执行；回复 **中止** 取消操作。
+    ```
+
+    **Gate**: 用户回复 OK 后进入 step_3。有 `[Breaking]` 跨 Task 引用时须再次警告。
+</step_2_impact>
+
+<step_3_execute>
+    **Role**: 外科医生
+    **Action**: 按以下顺序执行（顺序不可调整）。
+
+    | # | 操作 | 对象 |
+    |:---|:---|:---|
+    | 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 的关联条目 |
+    | 6 | [?有独占术语] 更新 `dictionary.json` | 移除或标注废弃 |
+    | 7 | [?有独占错误码] 更新 `error_codes.json` | 移除或标注废弃 |
+    | 8 | [?有聚合联动] 检查聚合方代码 | 确认聚合方中对被删 Task 的引用已清理 |
+
+    每步完成后记录操作日志（文件路径 + 操作类型）。
+</step_3_execute>
+
+<step_4_verify>
+    **Role**: 验证工程师
+    **Terminal Gate** (禁止跳过，须在 step_5 输出前全部完成):
+    | 步骤 | 命令 | 通过条件 |
+    |:---|:---|:---|
+    | 1 | `npx archi task --check` | 无 ERROR 级问题，无悬空依赖 |
+    | 2 | `npx archi render` | `.md` 视图生成完成 |
+    | 3 | 运行项目构建命令 | 零编译错误 |
+
+    | 检查项 | 通过标准 |
+    |:---|:---|
+    | Roadmap 一致性 | `--check` 通过，无悬空依赖 |
+    | 构建 | 零编译错误 |
+    | 残留引用 | 代码中无对已删模块的 import/require |
+
+    构建失败或发现残留引用 → 定位并修复后重检。
+</step_4_verify>
+
+<step_5_summary>
+    **Output**: 下线完成摘要：
+    - **已删除**: 文档 N 个文件、代码 N 个文件
+    - **已清理**: roadmap / map / context_glue 中的引用
+    - **构建状态**: 通过/失败
+    - **[?有]须人工跟进**: 术语/错误码/跨 Task 引用残留
+    - **Git Commit Suggestion**: `feat(remove): decommission <ID> <Name>`
+</step_5_summary>
+
+</protocol_remove>