architext 0.0.3 → 0.0.5

package/dist/templates/zh-Hant/docs/global/vision.md

@@ -1,82 +0,0 @@
----
-description: Project Constitution: Vision, Personas, Principles & Boundaries.
----
-
-# Product Vision: [項目名稱]
-
-> **Version:** 1.0.0
-> **Status:** Active
-> **Role:** The "Constitution" of the project. All Tasks and Specs must align with this.
-
-## 1. Core Vision (核心願景)
-
-**Elevator Pitch:**
-[產品名稱] 是一個 [目標市場/類別] 平台，旨在幫助 [目標用戶] 解決 [核心痛點]，通過 [核心解決方案/獨特點] 實現 [最終價值]。
-
-**North Star Metric (北極星指標):**
-
-* [指標名稱]: [描述 - 例如：用戶每日專注時長]
-
----
-
-## 2. Target Audience (目標用戶與畫像)
-
-### Primary Persona (核心用戶)
-
-* **Role:** [例如：備考的學生]
-* **Key Traits:** [關鍵詞]
-* **Pain Points:**
-  * [痛點 1]
-  * [痛點 2]
-* **Goals:**
-  * [希望達成的結果]
-
----
-
-## 3. Product Principles (產品原則)
-
-* **[原則 1]:** [例如：極簡優先 - 任何增加點擊的操作都需要額外理由]
-* **[原則 2]:** [例如：鼓勵而非懲罰 - 完不成任務時給鼓勵，而不是紅色的警告]
-
----
-
-## 4. Design & Experience (設計與體驗語言) [?UI]
-
-> **Note:** 本節僅適用於有 UI 的專案。具體色值和圓角定義請嚴格參閱 `[[__DOCS_DIR__]]/global/design_tokens.json`。
-
-### Visual Style (視覺風格)
-
-* **Keywords:** [例如：溫暖、專注、無干擾]
-* **Density:** [例如：大留白，沉浸式]
-* **Animation:** [例如：輕微的微交互，不要花哨的轉場]
-
-### Tone of Voice (文案語調)
-
-* **Personality:** [例如：像一個陪讀的夥伴，而不是嚴厲的老師]
-* **Do's:** [例如：用"我們一起"代替"你應該"]
-* **Don'ts:** [例如：不要使用機械的錯誤碼報錯]
-
----
-
-## 5. Boundaries (邊界與反目標)
-
-### In Scope (核心範圍)
-
-* [核心功能 A]
-* [核心功能 B]
-
-### Out of Scope (明確不做)
-
-* **[反目標 1]:** [例如：不做社交排行榜]
-* **[反目標 2]:** [例如：不提供深色模式切換（默認即深色）]
-
----
-
-## 🤖 AI Maintenance Guide
-
-**Trigger**: 僅在項目初始化 (`/archi.start`) 或重大戰略轉型 (`/archi.revise`) 時修改。
-
-**Action**:
-1.  **Alignment**: 確保 Section 3 (Principles) 與 `02_tech_stack.md` 中的技術選型不衝突。
-2.  **Completeness**: 必須填滿所有 `[ ]` 佔位符，嚴禁保留 "Example" 字樣。
-3.  **Consistency**: 所有的 Task Spec (`.spec.md`) 都必須引用此文件的 Vision 以確保不跑題。

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

@@ -1,150 +0,0 @@
-<protocol_audit>
-  **Trigger**: `/archi.audit [id]`
-  **Goal**: 獨立深度程式碼審查。帶 `<id>` 審查該任務的程式碼實現；無 `<id>` 執行專案級體檢。不修改程式碼，僅輸出審查報告與修復工單。
-
-<meta>
-    <style>Investigative, Thorough, Evidence-Based</style>
-    <language>繁體中文</language>
-    <principles>
-      1.  **Read-Only**: 禁改任何程式碼檔案。審查 ≠ 修復。
-      2.  **Evidence-Based**: 每個發現須附檔案路徑、行號、程式碼片段。
-      3.  **Actionable Output**: 每個問題須附推薦修復命令（`/archi.fix`, `/archi.edit` 等）。
-      4.  **Vision Anchored**: 始終以 `vision.md` 為方向基準，偵測偏離。
-      5.  **Report Persistence**: 審查結果須寫入檔案 — 任務級 → `tasks/<id>_*/audit.md`（覆蓋），專案級 → `audits/YYYY-MM-DD.md`（按日期存檔，同日覆蓋）。
-    </principles>
-</meta>
-
-<step_1_resolve>
-    **Role**: 系統分析師
-    **Mode Gate**:
-
-    | 輸入 | 模式 | 後續步驟 |
-    |:---|:---|:---|
-    | `/archi.audit <id>` | 任務級深度審查 | step_2_task → step_3_report |
-    | `/archi.audit` | 專案級體檢 | step_2_project → step_3_report |
-
-    **任務級 — Resolve ID**:
-    1.  從 `[[__DOCS_DIR__]]/global/roadmap.json` 解析 `<id>` → Task Name、Slug、狀態。
-    2.  **Status Gate** — 僅 `active` 或 `done` 可審查:
-
-        | 狀態 | 處理 |
-        |:---|:---|
-        | `active` / `done` | 通過 |
-        | `pending` | 拒絕 — 無程式碼可審查，先執行 `/archi.plan` + `/archi.code` |
-        | `blocked` | 拒絕 — 前置依賴未完成 |
-
-    3.  **Load Context**:
-        - `[[__DOCS_DIR__]]/global/vision.md` — 專案方向基準
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/spec.md` — 功能邏輯
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/plan.json` — 任務清單
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/ui.md` — 任務 UI 範圍聲明(如存在)
-        - [?UI] `[[__DOCS_DIR__]]/global/ui_context.md` — AI 畫面索引（定位對應畫面 ID）
-        - [?UI] `[[__DOCS_DIR__]]/global/ui_concept.html` — 唯讀視覺參考（#10 合規對比的視覺標準源）
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/audit.md` — 上次審計報告(如存在，用於對比)
-        - `02_tech_stack.md` — 技術紅線
-        - [?UI] `[[__DOCS_DIR__]]/global/design_tokens.json`
-        - [?Data] `[[__DOCS_DIR__]]/global/data_snapshot.json`
-    4.  讀取該任務對應的所有程式碼檔案。
-
-    **專案級 — Load Overview**:
-    1.  讀取 `[[__DOCS_DIR__]]/global/vision.md`、`roadmap.json`、`map.json`。
-    2.  讀取 `02_tech_stack.md`。
-    3.  掃描 `[[__DOCS_DIR__]]/tasks/` 目錄結構。
-    4.  讀取專案程式碼入口檔案與關鍵模組。
-
-    **Output**: 審查範圍與上下文清單。
-</step_1_resolve>
-
-<step_2_task>
-    **Role**: 首席審計官
-    **Scope**: 任務級深度程式碼審查（僅 `/archi.audit <id>` 時執行）。
-
-    逐維度審查，每個發現須附 `檔案:行號` + 程式碼片段 + 嚴重級別：
-
-    | # | 維度 | 審查要點 |
-    |:---|:---|:---|
-    | 1 | **Vision 對齊** | 實現方向與 `vision.md` 有無衝突或偏離 |
-    | 2 | **Spec 完整性** | 程式碼是否覆蓋 `spec.md` 全部場景與邊界 |
-    | 3 | **Plan 真實性** | 標記 `done` 的任務是否在程式碼中落地（防虛標） |
-    | 4 | **邏輯正確性** | 業務邏輯錯誤、矛盾、遺漏分支、狀態機缺陷 |
-    | 5 | **Bug 獵殺** | 空值/undefined、競態、資源洩漏、死迴圈、off-by-one |
-    | 6 | **錯誤處理** | 吞錯、靜默失敗、錯誤傳播鏈完整性、使用者可見回饋 |
-    | 7 | **Tech Stack 合規** | 對照 `02_tech_stack.md`：違禁模式、過時 API、硬編碼 |
-    | 8 | **安全性** | 敏感資訊洩露、輸入未校驗、注入風險、權限檢查 |
-    | 9 | **效能** | 不必要全量匯入/大迴圈/無用計算/記憶體洩漏/N+1 查詢 |
-    | 10 | [?UI] **Design 合規** | 樣式是否用 Token 定義的視覺模式；無硬編碼魔法值；實現與 `ui_concept.html` 對應畫面視覺一致 |
-    | 11 | [?Data] **資料一致性** | 欄位名/型別與 `data_snapshot.json` 是否一致 |
-    | 12 | [?I18n] **I18n 合規** | 無硬編碼字串；須用 Key/字典引用 |
-    | 13 | **Orphan .gitkeep** | 目錄已有其他檔案時仍存在 `.gitkeep` — 須刪除 |
-    | 14 | **Spec-Code 漂移** | 程式碼中的介面/型別/行為是否與 `spec.md` 一致；手動變更是否已同步到文件 |
-    | 15 | [?UI] **UI 引用完整性** | `ui.md` 中的 `ref: ui_concept.html#S-XX` 指針是否仍然有效；被引用的畫面/元件是否因 edit/revise 後已改名或刪除 |
-
-    **Output**: 按維度分組的發現列表，每項含級別、位置、描述。
-</step_2_task>
-
-<step_2_project>
-    **Role**: 首席審計官
-    **Scope**: 專案級健康體檢（僅 `/archi.audit` 無參數時執行）。
-
-    | # | 檢查項 | 說明 |
-    |:---|:---|:---|
-    | 1 | **Vision 漂移** | `roadmap.json` 任務方向與 `vision.md` 是否一致 |
-    | 2 | **架構一致性** | `map.json` vs 實際目錄結構，有無漂移或未註冊模組 |
-    | 3 | **Roadmap 健康度** | 一致性 + 進度統計 + 長期 blocked 任務 + 依賴環偵測 |
-    | 4 | **檔案完整度** | 各 Task 是否有 spec.md + plan.json；有無孤兒目錄 |
-    | 5 | **Tech Stack 全域合規** | 抽查關鍵入口與模組，偵測全域性違規 |
-    | 6 | **跨 Task 一致性** | 重複邏輯、命名衝突、介面不一致 |
-    | 7 | **Orphan .gitkeep** | 目錄已有其他檔案時仍存在 `.gitkeep` — 須刪除 |
-
-    掃描後標註優先級，推薦需深度審查的 Task：
-    - `done` 但 plan 未全部完成的
-    - 程式碼量大但無測試的
-    - 長期 `active` 未推進的
-
-    **Output**: 專案健康概覽 + 深度審查推薦列表。
-</step_2_project>
-
-<step_3_report>
-    **Role**: 報告撰寫員
-    **Action**:
-
-    **Issue Classification**:
-
-    | 級別 | 含義 | 範例 |
-    |:---|:---|:---|
-    | `CRITICAL` | 須修復，阻塞發布 | 邏輯錯誤、安全漏洞、資料損壞風險 |
-    | `WARNING` | 應修復，有風險 | 缺少錯誤處理、效能隱患、Spec 覆蓋不全 |
-    | `INFO` | 建議最佳化 | 命名不規範、缺少註解、可簡化的程式碼 |
-
-    **Issue Format** (每項須包含):
-    ```
-    [LEVEL] 檔案路徑:行號 — 維度名
-      描述：具體問題
-      -> 推薦修復：/archi.fix <ID> <描述> 或 /archi.edit <ID> <描述>
-    ```
-
-    **Action Routing** (根據問題型別推薦命令):
-
-    | 問題型別 | 推薦命令 |
-    |:---|:---|
-    | Bug（邏輯錯誤、邊界遺漏） | `/archi.fix <ID> <描述>` |
-    | Spec 缺漏（功能未完整實現） | `/archi.edit <ID> <補充描述>` |
-    | 架構級問題（全域違規） | `/archi.revise <描述>` |
-    | 功能未完成（plan 虛標 done） | `/archi.code <ID>` |
-    | 小問題（命名、註解、簡化） | 下次 `/archi.code` 時一併處理 |
-
-    **Report Structure**:
-    1.  審查概要（模式、範圍、日期）
-    2.  發現列表（按級別排序：CRITICAL → WARNING → INFO）
-    3.  統計摘要（各級別數量）
-    4.  修復工單彙總（可直接執行的命令列表）
-    5.  Next Steps 表格
-
-    **Write Report File**:
-    - 任務級 → `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/audit.md`（覆蓋式）
-    - 專案級 → `[[__DOCS_DIR__]]/audits/YYYY-MM-DD.md`（按日期存檔，同日覆蓋）
-
-    **Output**: 完整審查報告（同時輸出到對話和寫入檔案）。
-</step_3_report>
-
-</protocol_audit>

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

@@ -1,160 +0,0 @@
-<protocol_code>
-  **Trigger**: `/archi.code <id>`
-  **Goal**: 基於 `tasks/<id>_<Slug>/plan.json` 任務清單，完成功能開發；遵循 `02_tech_stack.md`（[?UI] 同時遵循 `design_tokens.json`）；通過建置、型別、Lint、格式化、測試與審計。
-
-<meta>
-    <style>Deterministic, Type-Safe, SOTA-First</style>
-    <language>繁體中文</language>
-    <principles>
-      1.  **Frontmatter Preservation**: 禁改已有檔案的 YAML Frontmatter。
-      2.  **Follow Conventions**: 僅用儲存庫已有庫與模式；先讀後改。
-      3.  **Security First**: 禁引入/列印密鑰；敏感資訊不落盤。
-      4.  **SOTA Pattern Check**: 拒絕過時寫法；採用 tech_stack 定義的最佳實務。
-      5.  **No Commit Policy**: 未經授權不提交；以補丁呈現變更。
-      6.  **Static Check First**: 須通過所有靜態檢查(型別/Lint/格式化)。
-      7.  **Plan Completion Gate**: 結束前驗證 Plan 完成度。AI 可完成的任務須全部完成，僅豁免「人工介入」和「不可抗力」類。
-    </principles>
-</meta>
-
-<step_1_resolve>
-    **Role**: 系統分析師
-    **Action**:
-    1.  **Resolve ID**: 從 `[[__DOCS_DIR__]]/global/roadmap.json` 解析 `<id>` → Task Name、Slug、階段/狀態。
-    2.  **Status Gate** — 僅 `active` 可進入 code 流程:
-
-        | 狀態 | 處理 |
-        |:---|:---|
-        | `active` 🟢 | 通過，繼續 |
-        | `pending` ⏳ | 拒絕 — 提示先執行 `/archi.plan <ID>` |
-        | `blocked` 🧱 | 拒絕 — 前置依賴未完成 |
-        | `done` ✅ | 拒絕 — 已完成，如需修改用 `/archi.edit <ID>` |
-
-    3.  **Load Context** (用 Roadmap `📁 Slug` 定位):
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/spec.md` — 邏輯與場景
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/ui.md` — 本任務 UI 範圍聲明(如存在)
-        - [?UI] `[[__DOCS_DIR__]]/global/ui_context.md` — AI 畫面索引（畫面 ID/路由/狀態/導覽關係/共享元件）
-        - [?UI] `[[__DOCS_DIR__]]/global/ui_concept.html` — 唯讀視覺參考（實作時以此校準布局結構，禁基於此重新設計，設計已在 ui.md 確定）
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/plan.json` — 任務拆解（含 `notes` 速記，執行時須參照）
-        - `02_tech_stack.md` — 技術紅線
-        - [?UI] `[[__DOCS_DIR__]]/global/design_tokens.json`
-        - [?Data] `[[__DOCS_DIR__]]/global/data_snapshot.json`
-
-    **Output**: 待實施任務的原子清單，標註依賴與順序。
-</step_1_resolve>
-
-<step_2_plan>
-    **Role**: Tech Lead
-    **Action**:
-    生成執行藍圖（根據專案型別動態調整）：
-    - **Phase A (Domain/Data/API)**: 資料模型/介面/校驗
-    - **Phase B (UI/Presentation)**: 元件結構/樣式（僅用 Design Token）；非 UI 專案調整為對應展示層
-    - **Phase C (Integration)**: 端到端串聯（狀態管理、路由、資料流、錯誤處理）
-
-    每項任務寫出完成判定標準：靜態檢查通過、測試通過、符合 tech_stack 規範。
-
-    **Output**: 面向實施的原子任務列表(Checkbox)。
-</step_2_plan>
-
-<step_3_implement>
-    **Role**: 資深工程師
-    **Protocol**:
-    - **Read First**: 修改前須讀取目標檔案；遵循專案現有程式碼風格。
-    - **Use Existing Stack**: 僅用 `02_tech_stack.md` 宣告的技術與庫。
-    - [?UI] **Design Tokens Only**: 樣式嚴格使用 Token/Preset 定義的視覺模式；禁硬編碼魔法值（顏色、尺寸、間距等）。
-    - **Type-Safe**: 補齊型別定義；用專案技術棧的型別系統守護邊界。
-    - **Code Organization**: 遵循 `02_tech_stack.md` 中定義的架構模式與檔案歸位策略。
-    - **Comments**: 解釋 Why 而非 What；拒絕廢話註解。
-    - **Naming**: 自解釋命名；拒絕 `a`, `b`, `tmp` 等無意義名（迴圈變數 `i` 除外）。
-    - **Error Handling**: 禁吞錯/禁靜默失敗；須正確傳播錯誤並給呼叫方可觀測回饋（UI: Toast；CLI: Exit Code；API: Status Code + Body）。
-    - **Robustness**: 顯式處理邊界(Loading/Error/Empty/Timeout)；禁只寫 Happy Path。
-    - **SOTA**: 遵循 tech_stack 定義的最佳實務；拒絕明確禁止的過時模式。
-    - **Scaffold Safety**: 鷹架在非空目錄可能覆蓋檔案 — 須在新目錄生成並保護 `[[__DOCS_DIR__]]/`；刪除/覆蓋操作須先列清單並確認。
-    - **.gitkeep Cleanup**: 空目錄可用 `.gitkeep` 占位以便 Git 追蹤；向目錄新增其他檔案時須刪除該目錄下的 `.gitkeep`。
-    - **Patch Output**: 以補丁形式輸出變更，附 Code Reference。
-    - **Progress Tracking**: 每完成一個 task 後，立即更新 `plan.json` 對應 task 的 `done: true`；禁在 signoff 時批次更新（會話中斷後進度將丟失）。
-
-    **Action**: 按 Phase A/B/C 逐項實施；每項產出完整、工程化的程式碼（含必要測試）；新增檔案/目錄須與 tech_stack 一致。
-</step_3_implement>
-
-<step_4_validate>
-    **Role**: 驗證工程師
-    **Action** (失敗須修復後重跑；命令以 `02_tech_stack.md` Section 5 為準):
-
-    **Automated Check**: 執行 `[[__DOCS_DIR__]]/scripts/validate`（如存在）；否則按以下清單逐項手動執行。
-
-    | Phase | 檢查項 | 要求 |
-    |:---|:---|:---|
-    | **Static** | Build | 零編譯錯誤 |
-    | | Type Check | 零型別錯誤 |
-    | | Lint | 零 Lint 錯誤（警告須說明原因） |
-    | | Format | 符合格式規範（失敗則自動修復後重檢） |
-    | **Test** | Existing Tests | 執行已有測試套件全部通過；禁因新程式碼破壞舊測試 |
-    | | New Coverage | 為新增/修改的關鍵邏輯補充測試；純樣式調整可豁免 |
-
-    **Task Verification (硬性要求)**
-
-    > 禁僅通過程式碼審查或自動化測試就標記完成；須實際執行目標功能並驗證。
-    > 如 dev server 未啟動，先執行 `[[__DOCS_DIR__]]/scripts/dev-up`。
-    > **優先讀取 `notes.驗證`**: 先讀當前 task 的 `notes` 字段末尾 `驗證: [...]` 部分，以其指定操作執行具體 e2e；`notes` 無驗證字段時按下表型別兜底。
-
-    | 專案型別 | 驗證動作 | 通過標準 |
-    |:---|:---|:---|
-    | [?Web] | 瀏覽器操作目標功能路徑 | 渲染正常，互動無報錯，主控台無異常 |
-    | [?API] | 呼叫新增/修改的 endpoint | 狀態碼與 Body 符合 spec |
-    | [?CLI] | 執行目標命令（含正常參數 + 邊界參數） | stdout 符合預期，exit code 正確 |
-    | [?Lib] | 執行範例程式碼或 playground 驗證匯出 API | 無執行時錯誤，回傳值正確 |
-    | [?Mobile] | 模擬器/真機操作目標功能 | 介面正常，互動響應 |
-    | [?Desktop] | 啟動應用操作目標功能 | 視窗正常，功能可用 |
-
-    **Evidence**: Output 須附驗證結果（命令輸出摘要 / 截圖 / 錯誤日誌）。
-    **Fallback**: 驗證持續失敗且懷疑環境問題 → `[[__DOCS_DIR__]]/scripts/dev-reset` → `[[__DOCS_DIR__]]/scripts/dev-up` → 重試。
-
-    **Output**: 每項檢查 ✅/❌ 狀態與原因；Task Verification 證據。
-</step_4_validate>
-
-<step_5_audit>
-    **Role**: 首席審計官
-    **Checklist**:
-    1.  **Tech Consistency**: 與 `02_tech_stack.md` 一致（庫/模式/API 風格）。
-    2.  [?UI] **Design Compliance**: 樣式僅用 Token/Preset 視覺模式；無硬編碼魔法值。
-    3.  [?Data] **Data Integrity**: 符合 `data_snapshot.json`；欄位名/型別一致。
-    4.  **SOTA**: 拒絕過時模式；採用 tech_stack 最佳實務。
-    5.  [?UI] **Accessibility**: 含必要無障礙屬性。
-    6.  [?I18n] **I18n**: 無硬編碼字串；須用 Key/字典引用。
-    7.  **Performance**: 避免不必要大依賴/全量匯入/無用計算/記憶體洩漏。
-    8.  **Security**: 無敏感資訊洩露；輸入有校驗。
-    9.  **Static Check Zero**: 所有靜態檢查問題已解決。
-    10. **step_4 Gate**: 確認 step_4 所有檢查（Static + Test + Task Verification）已通過。
-    11. **聯動檢查**: 讀取 `[[__DOCS_DIR__]]/global/map.json` 中的 `featureRelations` 陣列，將本次實現的功能與各條 `sources` 欄位做語義對比。命中時輸出提示：`⚠️ 聯動: [aggregator] — [checkNote]`，提醒在當前實現完成後確認聚合方是否需要同步。`featureRelations` 為空則跳過。
-    12. **資料治理**: 本次實現引入新內容時，須直接寫入對應全域索引：
-
-        | 觸發條件 | 檔案 | 動作 |
-        |:---|:---|:---|
-        | 新業務實體 · 動作 · 共享工具 | `dictionary.json` | 直接追加寫入 |
-        | 新錯誤情境 | `error_codes.json` | 直接追加寫入 |
-        | [?Data] Schema 實際變更 | `data_snapshot.json` | 直接同步 |
-
-    細節問題可 Auto-Fix 並說明；重大風險標註 `⚠️ Risk` 並提出替代方案。
-</step_5_audit>
-
-<step_6_signoff>
-    **Terminal Gate** (禁止跳過，須在輸出總結前全部完成):
-    | 步驟 | 命令 | 通過條件 |
-    |:---|:---|:---|
-    | 1 | `npx archi plan <ID>` | 全部完成或僅豁免項；未通過禁簽收，回到 step_3 |
-    | 2 | `npx archi task <ID> --status done` | 任務狀態已更新 |
-    | 3 | `npx archi task --check` | 無 ERROR 級問題 |
-    | 4 | `npx archi render` | `.md` 視圖生成完成 |
-
-    **Action** (Gate 通過後):
-    1.  確認 `plan.json` 各 task `done` 標記已全部更新（應在 step_3 實時完成，此處做最終校驗）。
-    2.  **Drift Warning**: 對比本次程式碼變更與 `spec.md` 的關鍵點位（介面簽名、回傳型別、Gherkin 場景關鍵操作）。如發現程式碼超出 spec 覆蓋範圍 → 標注 `⚠️ Spec 漂移`，建議執行 `/archi.edit <ID>` 同步文件。
-    3.  輸出完成任務清單與補丁連結(Code Reference)。
-    4.  提供下一步建議與 Git Commit Suggestion（Conventional Commits）。
-
-    **Checkpoint** (Output 前須確認): □ Terminal Gate 全部執行
-
-    **Output**: 完成摘要，含已完成任務、豁免項(如有)、Git Commit 建議、Next Steps 表格。
-</step_6_signoff>
-
-</protocol_code>

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

@@ -1,87 +0,0 @@
-<protocol_edit>
-  **Trigger**: `/archi.edit <id> [context]`
-  **Goal**: 基於新需求/修改意見，更新已納管模組的 Spec/UI 文件，並追加開發計畫。
-
-<meta>
-    <style>Collaborative, Iterative, Traceable</style>
-    <language>繁體中文</language>
-    <principles>
-      1.  **Doc First**: 須先改文件 (Spec/UI)，再生成 Plan。禁跳過文件直接改程式碼計畫。
-      2.  **Incremental**: 僅追加新 Task 到 Plan，保留已完成歷史（除非需回滾）。
-      3.  **Conflict Check**: 檢查新需求是否與 tech_stack / design_tokens 衝突。
-      4.  **Frontmatter Preservation**: 禁破壞現有文件 Metadata。
-    </principles>
-</meta>
-
-<step_1_load>
-    **Role**: 產品經理
-    **Action**:
-    - 讀取 `[[__DOCS_DIR__]]/tasks/<ID>_<Slug>/` 下的 spec.md、ui.md、plan.json。
-    - [?UI] 讀取 `[[__DOCS_DIR__]]/global/ui_context.md`（定位本功能對應的畫面範圍及導覽關係）。
-    - 檢測 spec.md 中的 `Spec-Status` 欄位：
-      - `Full` → 正常流程，進入 step_2。
-      - `Stub` → 進入 step_1_5_enrich。
-    - [?重大 UX 變更] 快速搜尋同類產品最佳實務。
-</step_1_load>
-
-<step_1_5_enrich>
-    **Role**: 逆向工程師
-    **Trigger**: spec.md 中 `Spec-Status: Stub`（由 `/archi.inherit` 生成的輕量快照）。
-
-    **Action**:
-    1. 告知使用者：「該功能僅有輕量快照，須先補全完整 spec 才能執行修改。」
-    2. 從 stub 的「關聯檔案」section 提取原始碼路徑。
-    3. 逐一讀取關聯檔案，中度掃描（入口 + 核心邏輯）。
-    4. 基於程式碼分析，將 stub 補全為完整 spec：
-       - 保留原有概述和關鍵流程
-       - 補充 Gherkin Scenarios（覆蓋正常流程 + 異常路徑）
-       - 補充介面/型別定義（如該功能是其他功能的上游）
-    5. 更新 `Spec-Status: Stub → Full`。
-    6. [?UI] 如模組有 UI → 同步生成或更新 `ui.md`（範圍聲明）；如須新增畫面，提示使用者執行 `archi-ui-wireframe` Skill（Skill 會同步更新 `ui_concept.html` + `ui_context.md`）。
-    7. 生成 `plan.json`（全部 task 為 done，記錄已實作內容）。
-    8. 向使用者輸出補全後的 spec 摘要。
-
-    **Gate**: 使用者確認補全內容正確後，繼續 step_2_refine_docs。
-    **異常**: 關聯檔案不存在/已移動 → 提示使用者更新路徑。
-</step_1_5_enrich>
-
-<step_2_refine_docs>
-    **Role**: 需求分析師 & 設計師
-    **Action**:
-    - 根據 `[context]` 修改 spec.md（邏輯/規則變更）和 ui.md（結構/互動變更）。
-    - [?UI 修改] 透過 Skill 同步更新 `ui_concept.html` + `ui_context.md`（Skill 為兩個檔案的唯一寫者）：
-
-      | 變更類型 | 判定標準 | 處理方式 |
-      |:---|:---|:---|
-      | 無畫面影響 | 僅邏輯/資料變更，無視覺差異 | 僅改 spec.md，`ui_concept.html` / `ui_context.md` 不動 |
-      | 輕微 UI 調整 | 新增/修改狀態、彈窗、局部區域，不改整體版面 | 呼叫 Skill（修改畫面模式）更新兩個檔案，輸出 `MODIFIED: S-XX` |
-      | 畫面結構變更 | 版面重構、新增獨立畫面、導覽路徑變化 | 呼叫 Skill（修改畫面模式）更新兩個檔案，輸出 `MODIFIED: S-XX`；若已完成 Phase 2 著色，同步重新著色 |
-      | 功能縮減 | 畫面/區域整體移除 | 呼叫 Skill（刪除畫面模式）更新兩個檔案，輸出 `REMOVED: S-XX` |
-
-    - 需求模糊時向使用者提問 (A/B/C/D 選項) 確認細節。
-
-    **Output**: 更新後的 Spec、UI 文件及 `ui_concept.html` / `ui_context.md` 變更摘要。
-</step_2_refine_docs>
-
-<step_3_update_plan>
-    **Role**: Tech Lead
-    **Action**:
-    - 在 `plan.json` 的 `phases` 陣列中追加新 Phase 物件。
-    - 列出具體 Tasks (API update, UI tweak, Test update)；每項須可驗證。
-    - **狀態轉換**: 若當前任務 status=`done`，追加 Phase 後須將狀態重置為 `active`（否則後續 `/archi.code` 將被 Status Gate 拒絕）。
-
-    **Terminal Gate** (禁止跳過，須在 step_4 輸出前全部完成):
-    | 步驟 | 命令 | 通過條件 |
-    |:---|:---|:---|
-    | 1 | `npx archi render` | `.md` 視圖生成完成 |
-    | 2 | [當前 status=done] `npx archi task <ID> --status active` | 任務狀態已重置為 active |
-
-    **Output**: 追加了新任務的 plan.json；若執行了狀態轉換，輸出 `MODIFIED: roadmap.json <ID>.status done→active`。
-</step_3_update_plan>
-
-<step_4_summary>
-    **Action** (Gate 須在 step_3 完成):
-    **Output**: Task 更新摘要，含 Spec/UI/Plan 變更概要和 Next Steps 表格。推薦執行 `/archi.code <ID>`。
-</step_4_summary>
-
-</protocol_edit>

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

@@ -1,86 +0,0 @@
-<protocol_fix>
-  **Trigger**: `/archi.fix [id] <context>`
-  **Goal**: 針對 Bug 進行診斷並直接執行修復。若未提供 `[id]`，自動定位相關功能模組。
-
-<meta>
-    <style>Diagnostic, Surgical, Spec-Compliant</style>
-    <language>繁體中文</language>
-    <principles>
-      1.  **Spec Immutable**: 禁改 `spec.md` / `ui.md`（除非 Bug 本身是檔案錯誤）。
-      2.  **Reproduction**: 須先構想複現步驟或測試案例。
-      3.  **Root Cause**: 須分析根因，而非修補表面。
-      4.  **Test-Driven**: 修復計畫須含新增測試案例。
-      5.  **Auto-Discovery**: 若未指定 ID，透過 Context 語意搜尋定位 Task。
-    </principles>
-</meta>
-
-<step_1_diagnose>
-    **Role**: 故障分析師
-    **Action**:
-    1.  **Resolve Target**:
-        - 有 `<id>`: 鎖定 `tasks/<ID>_<Slug>/`。
-        - 無 `<id>`: 分析 `[context]` 搜尋最相關模組。
-          唯一匹配 → 自動鎖定 | 多個匹配 → 列出候選詢問 | 無法定位 → 報錯請求指定 ID。
-    2.  讀取目標目錄下所有檔案 (`spec.md`, `ui.md`, `plan.json`) 與相關程式碼。
-    3.  讀取 `02_tech_stack.md`（確保修復方式不違反技術紅線）和 `[[__DOCS_DIR__]]/global/vision.md`（確保修復方向不偏離專案願景）。
-    4.  分析 `[context]`，結合程式碼邏輯定位潛在故障點。
-    5.  **Hypothesis**: 提出 1-3 個根因假設。
-
-    **Output**: 故障診斷報告 (Root Cause Analysis)。
-</step_1_diagnose>
-
-<step_2_plan_fix>
-    **Role**: Tech Lead
-    **Action**:
-    - 更新 `[[__DOCS_DIR__]]/tasks/<ID>_<Slug>/plan.json`，在 `phases` 陣列中追加 phase 物件，`name` 為 `Bugfix: <Bug Title>`。
-    - Tasks: 1) 建立複現測試(Red) 2) 修復(Green) 3) 迴歸測試。
-
-    **Terminal Gate** (禁止跳過，須在 step_5 輸出前全部完成):
-    | 步驟 | 命令 | 通過條件 |
-    |:---|:---|:---|
-    | 1 | `npx archi render` | `.md` 視圖生成完成 |
-
-    **Output**: 追加了修復任務的 plan.json。
-</step_2_plan_fix>
-
-<step_3_execute_fix>
-    **Role**: 資深工程師 (Surgical Fix — 僅改 Bug，禁擴散)
-    **Action**:
-    - 根據 Plan 直接修改程式碼。
-    - 僅修復 Bug，禁藉機重構或改無關程式碼。
-    - 錯誤處理遵循 `code.md` 規範（禁吞錯/禁靜默失敗）。
-</step_3_execute_fix>
-
-<step_4_verify>
-    **Role**: QA 工程師
-    **Terminal Gate** (禁止跳過，須在 step_5 輸出前全部完成):
-    | 步驟 | 命令 | 通過條件 |
-    |:---|:---|:---|
-    | 1 | 運行建置命令 | 建置成功 |
-    | 2 | 運行型別檢查 | 零型別錯誤 |
-    | 3 | 運行 Lint/Format | 通過 |
-    | 4 | 運行測試 | 複現測試 + 迴歸測試通過 |
-
-    任何失敗須修復至通過。
-</step_4_verify>
-
-<step_4_5_plan_update>
-    **Role**: Tech Lead
-    **Action**:
-    1. 更新 `plan.json`：將 Bugfix Phase 中已完成的 tasks 的 `done` 設為 `true`。
-    2. [當前 status=`done` 且 Bugfix Phase 全部通過] → 保持 `done` 不變。
-    3. [Bugfix Phase 有未通過項] → 執行 `npx archi task <ID> --status active`；signoff 輸出中標注須重新 `/archi.code` 完成剩餘修復。
-
-    **Output**: `MODIFIED: plan.json Bugfix Phase done 標記`（如狀態變更，附 `MODIFIED: roadmap.json <ID>.status`）。
-</step_4_5_plan_update>
-
-<step_5_summary>
-    **Output**: Bug 修復摘要，含 Root Cause 分析、修復內容、新增測試，以及 Next Steps 表格：
-
-    | 優先級 | 動作 | 說明 |
-    |:---|:---|:---|
-    | 推薦 | `/archi.audit <ID>` | 重新審查，確認修復完整且無新引入問題 |
-    | 可選 | `/archi.code <ID>` | 如有 Bugfix Phase 未完成項，繼續實作 |
-</step_5_summary>
-
-</protocol_fix>

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

@@ -1,69 +0,0 @@
-<protocol_help>
-  **Trigger**: `/archi.help [question]`
-  **Goal**: 專案導航與上下文問答。分析專案當前狀態，推薦下一步操作；或基於專案上下文回答使用者問題。
-
-<meta>
-    <style>Concise, Contextual, Actionable</style>
-    <language>繁體中文</language>
-    <principles>
-      1.  **Context-Aware**: 基於專案真實狀態回答，禁憑空猜測。
-      2.  **Actionable Output**: 每次輸出須含可執行的下一步建議（具體指令 + 參數）。
-      3.  **Minimal Token**: 精簡輸出，不複述使用者已知資訊。僅呈現推理結論與建議。
-      4.  **No Audit**: 不做深度審計（那是 `/archi.audit` 的職責）。聚焦導航與問答。
-    </principles>
-</meta>
-
-<step_1_load_context>
-    **Role**: 專案觀察員
-    **Action**:
-    1.  讀取 `[[__DOCS_DIR__]]/global/roadmap.json` — 僅提取每個 task 的 `id/title/status/deps/tag` 欄位；`goal/notes` 欄位跳過（導航和狀態聚合不需要這些詳情）。
-    2.  掃描 `[[__DOCS_DIR__]]/tasks/` 目錄 — 取得已有 Task 及其檔案完整度（有無 spec.md / ui.md / plan.json）。
-    3.  [?question] 若使用者帶了問題，根據問題語義定位相關檔案（spec / plan / vision / tech_stack / data_snapshot 等），按需讀取。
-
-    **Output**: 內部上下文（不直接輸出給使用者）。
-</step_1_load_context>
-
-<step_2_route>
-    **Role**: 路由器
-    **Action**: 根據輸入分支：
-
-    | 輸入 | 分支 |
-    |:---|:---|
-    | 無參數 | → step_3_navigate（專案導航） |
-    | 有 `[question]` | → step_4_answer（上下文問答） |
-
-</step_2_route>
-
-<step_3_navigate>
-    **Role**: 專案導航員
-    **Action**:
-    1.  **判斷專案階段**:
-
-        | 訊號 | 階段 | 建議 |
-        |:---|:---|:---|
-        | roadmap.json 不存在 | 未初始化 | 新專案 → `/archi.start`；已有程式碼 → `/archi.inherit` |
-        | 有 roadmap 但無 Task 目錄 | 已啟動，未規劃 | 執行 `/archi.scope` 規劃新任務 |
-        | 有 Legacy stub (Spec-Status: Stub) | 已繼承，未補全 | 執行 `/archi.edit LEG-xx` 補全 spec |
-        | 有 active 任務且 plan.json 完整 | 可編碼 | 執行 `/archi.code <ID>` |
-        | 有 active 任務但缺 spec/plan | 規劃未完成 | 執行 `/archi.plan <ID>` 補全 |
-        | 所有任務 done | 已完成 | 執行 `/archi.scope` 規劃新任務或發佈 |
-        | 有 blocked 任務 | 存在阻塞 | 提示阻塞原因與前置依賴 |
-
-    2.  **輸出格式**:
-        - 一句話總結當前狀態
-        - 推薦的下一步操作（含具體指令）
-        - 如有多個可選路徑，列出優先級排序（最多 3 個）
-</step_3_navigate>
-
-<step_4_answer>
-    **Role**: 專案顧問
-    **Action**:
-    1.  解析 `[question]` 語義，定位相關專案檔案。
-    2.  讀取相關檔案，綜合回答。
-    3.  若問題涉及操作（如「怎麼做 X」），回答須包含具體指令建議。
-    4.  若資訊不足以回答，明確告知缺少什麼，而非編造。
-
-    **Output**: 基於專案上下文的簡潔回答 + 相關檔案引用。
-</step_4_answer>
-
-</protocol_help>