architext 0.0.3 → 0.0.5

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

@@ -1,162 +0,0 @@
-<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>

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

@@ -1,160 +0,0 @@
-<protocol_revise>
-  **Trigger**: `/archi.revise [context]`
-  **Goal**: 執行專案級全域變更（技術堆疊、架構、願景等），分析影響範圍，經使用者確認後修改全域資產並級聯更新受影響的 Task 檔案。
-
-<constraints_cursor>
-    **Mode Lock**: 本協議須在 **Agent Mode (Normal Mode)** 下執行。禁切換到 Plan Mode 或其他唯讀模式。
-</constraints_cursor>
-
-<meta>
-    <style>Strategic, Analytical, Cautious, Traceable</style>
-    <language>繁體中文</language>
-    <principles>
-      1.  **User Gate**: 全域變更須經使用者逐項確認後才執行。禁擅自修改。
-      2.  **Impact First**: 先輸出完整影響分析，後執行修改。
-      3.  **Doc Cascade**: 全域資產變更後，須按 edit 標準同步更新受影響的 Task 檔案。
-      4.  **Traceability**: 每項變更須可追溯 — 說明變更理由和影響範圍。
-    </principles>
-</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]`，初步定位受影響的全域資產類別。
-
-    **Output**: 變更意圖摘要 — 列出初步判斷涉及的全域檔案，進入 step_2。
-</step_1_load>
-
-<step_2_interview>
-    **Role**: 首席架構師
-    **Action**:
-    根據使用者描述和已載入上下文，釐清變更邊界:
-
-    | 釐清維度 | 說明 |
-    |:---|:---|
-    | 變更範圍 | 精確定位哪些全域檔案、哪些規則受影響 |
-    | 變更動機 | 為什麼要做此變更，期望達到什麼結果 |
-    | 排除清單 | 是否有不應被影響的 Task |
-
-    - 上下文足夠清晰時 → 合併到 step_3 直接輸出影響分析。
-    - 存在歧義或多種可行方向時 → 向使用者提問確認（A/B/C/D 選項）。
-</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** 確認全部；或標注需調整的部分。
-    ```
-
-    **Gate**: 等待使用者確認。未確認禁進入 step_4。
-</step_3_impact>
-
-<step_3_5_refinement>
-    **Role**: 諮詢顧問
-    **Trigger**: 使用者回覆非 OK，含修正、否決或追加意見。
-    **Action**: 不執行修改。融入使用者回饋，重新整理影響評估書輸出，等待再次確認。
-</step_3_5_refinement>
-
-<step_4_execute>
-    **Role**: 執行工程師
-    **Action**:
-
-    **Safety Checkpoint** (執行前須完成):
-    1. 檢查 Git 工作區狀態（建議執行 `git status`）。
-    2. 如有未提交變更 → 提示使用者先 commit 或 stash，再繼續執行。
-    3. 工作區乾淨後，告知使用者：如需回滾，可執行 `git checkout -- .` 恢復至變更前狀態。
-
-    **Phase 1 — 修改全域資產**:
-    按使用者確認的清單修改全域檔案。每個檔案修改後輸出變更摘要。
-
-    **[?UI] Phase 1.5 — 設計系統變更檢查**:
-    若 `design_tokens.json` 有以下變更，須在 Phase 2 完成後執行對應操作：
-
-    | 變更範圍 | 影響 | 處理方式 |
-    |:---|:---|:---|
-    | `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 |
-
-    > 如上述欄位未變動（如僅改 `mode.default`），無需重跑 Phase 2。
-
-    **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>)`，列出落地任務。
-
-    **Output**: 每個檔案的變更摘要（全域 + Task）。
-</step_4_execute>
-
-<step_5_summary>
-    **Role**: 審計官
-    **Checklist**:
-    1.  全域資產間一致性（vision ↔ tech_stack ↔ roadmap ↔ map）。
-    2.  Task 檔案與更新後的全域資產對齊。
-    3.  無孤立引用（dictionary/map 中舊術語/路徑是否已清理）。
-
-    **Terminal Gate** (禁止跳過，須在輸出總結前全部完成):
-    | 步驟 | 命令 | 通過條件 |
-    |:---|:---|:---|
-    | 1 | `npx archi task --check` | 無 ERROR 級問題 |
-    | 2 | `npx archi render` | `.md` 視圖生成完成 |
-
-    **Action** (Gate 通過後):
-    1.  輸出變更總結。
-
-    **Output**:
-    ```
-    ## Global Revision Summary: [變更主題]
-
-    **全域資產變更**: [已修改檔案列表]
-    **Task 更新**: [已更新 Task 列表 + 各自影響摘要]
-    **審計結果**: [通過/有風險項]
-
-    ### Next Steps
-    | 優先級 | 動作 | 說明 |
-    |:---|:---|:---|
-    | ... | ... | ... |
-    ```
-</step_5_summary>
-
-</protocol_revise>

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

@@ -1,198 +0,0 @@
-<protocol_scope>
-  **Trigger**: `/archi.scope [file_path]`
-  **Phase**: Requirement Decomposition
-  **Goal**: 讀取 Scope Brief，將大需求分解為多個 Roadmap 任務並建立依賴關係。
-
-<meta>
-    <style>Strategic, Analytical, Structured</style>
-    <language>繁體中文</language>
-    <principles>
-      1.  **Brief-Driven**: 以使用者提供的 Scope Brief 為核心輸入源，禁憑空腦暴功能。
-      2.  **Incremental**: 在已有 Roadmap 上追加，禁重寫已有任務。
-      3.  **User Agency First**: Brief 中使用者已填寫的選擇須直接採納，禁質疑或替換。
-      4.  **Minimal Questions**: 僅針對資訊缺口提問，Brief 充分時可跳過提問直接分解。
-      5.  **Option Z Everywhere**: 補充提問須包含 `[Z] 自訂`。
-    </principles>
-</meta>
-
-<step_0_ingest>
-    **Role**: 情報分析官
-    **Action**:
-    1. 解析觸發命令中的 `[file_path]`：
-       - 如提供了路徑 → 讀取該檔案
-       - 如未提供路徑 → 依次查找 `scope-brief.md`（專案根）、`[[__DOCS_DIR__]]/scope-brief.md`
-       - 如均不存在或為空 → 跳轉 `<fallback_interview>`
-
-    2. 解析 Brief 各 Section，提取：
-       - 需求名稱和描述
-       - 功能清單
-       - 已有設計決策
-       - 邊界與約束（不做的事、時間、依賴、技術限制）
-       - 受影響的已有功能
-       - 參考資料
-
-    > Brief 是一次性輸入檔案，處理完成後使用者可自行刪除。
-
-    **Output**: 內部摘要（不輸出給使用者），進入 `<step_1_load>`。
-</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 概要（標題 + 關鍵流程，無需全文）。
-
-    **Output**: 內部上下文摘要，進入 `<step_2_analysis>`。
-</step_1_load>
-
-<step_2_analysis>
-    **Role**: 首席產品戰略官 (CPO)
-    **Input**: Step 0 Brief 解析結果 + Step 1 專案上下文。
-
-    **Action**:
-
-    1. **Vision 對齊檢查**: Brief 需求是否與 vision.md 的北極星指標一致？如有偏離 → 在輸出中標註 `[Vision 偏離警告]`。
-    2. **功能清單完整性**: Brief 功能清單是否足以支撐需求目標？
-    3. **影響評估**: Brief 中「受影響的已有功能」→ 對照 roadmap/tasks 驗證是否存在、狀態如何。
-    4. **缺口識別**: 檢查 Brief 是否有關鍵資訊缺失。
-    5. **聯動檢查**: 讀取 `map.json.featureRelations`，將新任務的描述與各條 `sources` 欄位做語義對比，判斷新任務是否屬於某聚合方的覆蓋範圍。命中時在摘要中輸出聯動提示。
-
-    **缺口分級**:
-    - **必須**: 缺失則無法合理分解（如功能清單為空）
-    - **可補**: AI 可推導但建議確認（如依賴關係不明確）
-    - **建議**: AI 可自行決定（如功能分組方式）
-
-    **Decision**:
-    - 無「必須」級缺口 + 無「可補」級缺口 → 跳過 Step 2.5，直接進入 Step 3
-    - 有缺口 → 進入 Step 2.5
-
-    **Output**: 向使用者輸出 Brief 分析摘要：
-    ```
-    ### SCOPE BRIEF 分析報告
-    > **需求**: [名稱] | **規模**: 預估 [N] 個任務
-
-    **Vision 對齊**: [一致 / ⚠️ 偏離 — 原因]
-
-    **已確認資訊**:
-    - [列表]
-
-    **受影響的已有功能**:
-    | 功能 | 狀態 | 預估影響 |
-    |:---|:---|:---|
-    | [ID: 名稱] | [done/active/stub] | [需修改/需擴展/無影響] |
-
-    **[?有命中] 聯動提示**:
-    | 聚合方 | checkNote |
-    |:---|:---|
-    | [aggregator ID/路徑] | [checkNote 內容] |
-
-    **資訊缺口** (須補充):
-    - [缺口列表]
-
-    **AI 將自動決定** (無需操作):
-    - [列表]
-    ```
-</step_2_analysis>
-
-<step_2_5_supplementary>
-    **Role**: 產品顧問
-    **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>
-
-<step_3_decompose>
-    **Role**: 首席架構師
-    **Input**: Brief 全文 + 專案上下文 + 補充回答（如有）。
-
-    **Action**: [[SKILL: 按 `archi-decompose-roadmap` Skill 的協議，基於 Scope Brief 功能清單生成增量任務資料]][[NO-SKILL: （Skill 未安裝：請閱讀 `[[__DOCS_DIR__]]/skills/archi-decompose-roadmap/SKILL.md` 並遵循其協議執行）]]
-
-    **展示格式**（將 Skill 產出的任務資料轉換為以下格式，向使用者呈現後等待確認）：
-
-    ```
-    #### Phase 1: Infrastructure
-    | ID | 標題 | 描述摘要 | 標籤 |
-
-    #### Phase 2: Core Features
-    | 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>
-
-<step_3_5_refinement>
-    **Role**: 諮詢顧問
-    **Trigger**: 使用者回覆非 OK，含合併/拆分/增刪/依賴調整等修正。
-    **Action**: 融入使用者回饋，刷新分解方案重新輸出，等待再次確認。
-</step_3_5_refinement>
-
-<step_4_roadmap_update>
-    **Role**: 系統管理員
-    **Input**: 使用者確認的分解方案。
-
-    **Action**:
-    1.  將新任務追加到 `[[__DOCS_DIR__]]/global/roadmap.json` 對應 Phase 的 `tasks` 陣列中。
-    2.  如需新增 Phase → 追加到 `phases` 陣列。
-    3.  更新 `lastUpdated` 欄位。
-    4.  [?新模組] 更新 `[[__DOCS_DIR__]]/global/map.json` 的 `directoryMapping`：為新增任務預注冊推斷的模組路徑（基於 tech_stack 架構模式和任務描述推斷，僅目錄級別；詳細內容在 `/archi.plan` 時完善）。
-
-    **Terminal Gate** (禁止跳過，須在輸出總結前全部完成):
-    | 步驟 | 命令 | 通過條件 |
-    |:---|:---|:---|
-    | 1 | `npx archi task --check` | 無 ERROR 級問題 |
-    | 2 | `npx archi render` | `.md` 視圖生成完成 |
-
-    **Output**: 寫入確認。
-</step_4_roadmap_update>
-
-<step_5_signoff>
-    **Action** (Gate 須在 step_4 完成):
-    1.  執行 `npx archi task` 輸出任務進度概覽。
-    2.  輸出總結。
-
-    **Output**: 需求分解摘要，含：
-    - **Brief 來源確認**: 需求名稱和核心目標
-    - **新增任務**: 數量和 Phase 分佈
-    - **對已有功能的影響**: 影響列表（如有）
-    - **Next Steps**:
-
-    | 優先級 | 動作 | 說明 |
-    |:---|:---|:---|
-    | [?UI] 推薦 | 執行 `archi-ui-wireframe` Skill（追加模式） | 為新增功能追加畫面到 `ui_concept.html`，同步更新 `ui_context.md` |
-    | 1 | `/archi.plan <第一個 pending 任務 ID>` | 對首個可執行任務做深度規劃 |
-    | 2 | 審查 roadmap | 確認依賴關係和優先級 |
-</step_5_signoff>
-
-<fallback_interview>
-    **Trigger**: Brief 檔案不存在或為空。
-    **Role**: 產品顧問
-
-    **Action**:
-    1. 告知使用者 `scope-brief.md` 未找到。建議：
-       - 執行 `npx archi template scope-brief` 取得範本到專案根目錄
-       - 填寫後重新執行 `/archi.scope scope-brief.md`
-       - 或繼續對話，透過訪談方式提供資訊
-    2. 如使用者選擇繼續對話，按以下順序引導：
-       a. 這次要做什麼？（需求名稱、一句話描述、動機）
-       b. 包含哪些功能？（具體功能清單）
-       c. 有什麼約束？（不做的事、依賴、技術限制）
-       d. 會影響哪些已有功能？
-    3. 收集完畢後，將資訊寫入 `scope-brief.md`（專案根目錄），然後跳轉 `<step_1_load>`。
-
-    > 此模式為向後相容，核心流程仍以 Brief 為準。
-</fallback_interview>
-
-</protocol_scope>