architext 0.0.2

package/dist/templates/zh-Hant/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-Hant/docs/prompts/plan.md

@@ -0,0 +1,252 @@
+<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」
+    ```
+
+    **⌨️ 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-Hant/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 本身是 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>