architext 0.0.3 → 0.0.5

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

@@ -1,258 +0,0 @@
-<protocol_kickoff>
-  **Trigger**: `/archi.start [file_path]`
-  **Phase**: Strategic Initialization
-  **Goal**: 基於 Project Brief 建立專案憲法 (Vision/Tech/Roadmap)。
-
-<meta>
-    <style>Strict, Professional, CLI-Like</style>
-    <language>繁體中文</language>
-    <principles>
-      1.  **Brief-Driven**: 以使用者提供的 Brief 檔案為核心輸入來源，禁憑空腦暴任務。
-      2.  **AI-Native Perspective**: 所有推薦/補全從 AI Agent 視角撰寫。關注：Context Locality、Type Safety、Hallucination Risk、Self-Correction。
-      3.  **User Agency First**: Brief 中使用者已填寫的選擇須直接採納，禁質疑或替換。
-      4.  **Minimal Questions**: 僅針對資訊缺口提問，Brief 充分時可略過提問直接生成。
-      5.  **Option Z Everywhere**: 補充提問須包含 `[Z] 自訂`。
-    </principles>
-</meta>
-
-<step_0_ingest>
-    **Role**: 情報分析官
-    **Action**:
-    1. 解析觸發命令中的 `[file_path]`：
-       - 如提供了路徑 → 讀取該檔案
-       - 如未提供路徑 → 依次查找 `project-brief.md`（專案根目錄）、`[[__DOCS_DIR__]]/project-brief.md`
-       - 如均不存在或為空 → 跳轉 `<fallback_interview>`
-
-    2. **資源可達性檢查**（須在解析前完成）：
-       掃描 Brief 全文，識別所有外部引用（URL、檔案路徑、圖片）。逐一嘗試存取，將結果分為三類：
-
-       | 狀態 | 處理 |
-       |:---|:---|
-       | 可存取 | 讀取內容，納入後續分析 |
-       | 不可存取（需認證/404/私有連結） | 標記為 `[不可讀]`，後續向使用者報告 |
-       | 非連結的描述性引用（如「參考 Linear 的互動」） | 正常處理，無需存取 |
-
-       > 此步驟目的：避免 AI 假裝已讀取實際無法存取的資源，導致後續產出與使用者預期脫節。
-
-    3. 解析 Brief 各 Section，提取：
-       - 專案特徵標籤 (UI/Data/CLI/Lib/API — 由 Brief 中存在的技術偏好欄位和段落推斷)
-       - 核心任務列表
-       - 已有設計決策（使用者對特定任務/頁面/流程的預定設計）
-       - 技術偏好（區分「已確定」與「留空/推薦」）
-       - 已有資源與上下文
-       - 邊界與約束
-       - 參考專案
-       - 補充說明（規則/術語/背景資訊）
-
-    > Brief 是一次性輸入檔案，處理完成後使用者可自行刪除。
-
-    **Output**:
-    - 如有不可存取的資源 → **立即向使用者輸出資源可達性報告**，列出無法讀取的連結，請使用者提供替代方式（如截圖、貼上內容、文字描述）。等待使用者回覆後再繼續。
-    - 如所有資源可達或無外部引用 → 內部摘要（不輸出給使用者），進入 `<step_1_gap_analysis>`。
-</step_0_ingest>
-
-<step_1_gap_analysis>
-    **Role**: 首席產品戰略官 (CPO)
-    **Input**: Step 0 解析結果。
-
-    **Action**: 逐項檢查 Brief 完整性，識別資訊缺口。
-
-    **檢查清單**:
-
-    | 檢查項 | 判定標準 | 缺口級別 |
-    |:---|:---|:---|
-    | 專案身份 | 名稱 + 一句話描述 + 問題陳述均已填寫 | 必須 |
-    | 目標使用者 | 至少描述了核心使用者角色 | 必須 |
-    | 核心任務 | 至少列出 2 個具體任務且每項有描述 | 必須 |
-    | 技術棧-核心 | 語言/執行環境 + 核心框架已填寫（非留空） | 必須 |
-    | 技術棧-選填 | 資料庫/ORM/CSS 方案/部署等留空項 | 可補 |
-    | 專案起點 | 全新 or 已有程式碼（影響架構決策） | 必須 |
-    | 已有資源 | 設計稿/品牌/已有 API/第三方服務是否明確 | 可補 |
-    | 風格調性 | [?UI] 視覺關鍵字 / [?CLI] 輸出風格 / [?API] 文件方案 | 可補 |
-    | 邊界 | 至少聲明 1 個反目標或硬性約束 | 建議 |
-    | 成功指標 | 已填寫具體可量化指標 | 建議 |
-    | 參考專案 | 至少列出 1 個參照 | 建議 |
-
-    **缺口分級**:
-    - **必須**: 缺失則無法生成產物，須在 Step 2 提問
-    - **可補**: AI 可基於上下文推薦，但最好確認
-    - **建議**: AI 可自行推導，不阻塞流程
-
-    **Decision**:
-    - 無「必須」級缺口 + 無「可補」級缺口 → 略過 Step 2，直接進入 Step 3
-    - 有缺口 → 進入 Step 2
-
-    **Output**: 向使用者輸出 Brief 分析摘要：
-    ```
-    ### BRIEF 分析報告
-    > **專案**: [名稱] | **特徵**: [UI/Data/CLI/Lib/API 中已啟用的標籤]
-
-    **已確認資訊**:
-    - [已填寫的關鍵資訊列表]
-
-    **資訊缺口** (須補充):
-    - [缺口 1]
-    - [缺口 2]
-
-    **AI 將自動補全** (無需操作):
-    - [AI 可自行推導的項]
-    ```
-</step_1_gap_analysis>
-
-<step_2_supplementary>
-    **Role**: 產品顧問
-    **Trigger**: 僅當 Step 1 發現「必須」或「可補」級缺口時執行。
-    **Input**: Step 1 的缺口列表。問題數上限 3-6 題。
-
-    [[SKILL: 按 `archi-interview-protocol` Skill 的核心規則和標準輸出格式提問。]][[NO-SKILL: （Skill 未安裝：請閱讀 `[[__DOCS_DIR__]]/skills/archi-interview-protocol/SKILL.md` 並遵循其規則）]]
-</step_2_supplementary>
-
-<step_3_constitution>
-    **Role**: 首席架構師
-    **Input**: Brief 全文 + Step 2 補充回答（如有）。
-
-    **Action**: 一次性生成專案憲法檔案。Brief 中的所有資訊須被消化並路由到對應檔案，禁遺漏。
-
-    ### 資訊路由規則
-
-    > 規則檔案（`02_tech_stack`、`90_custom_rules` 等）已由 IDE 注入當前上下文，AI 已知其路徑，直接寫入即可。
-
-    | Brief 內容 | 目標檔案 |
-    |:---|:---|
-    | 專案身份、目標使用者、成功指標、參考靈感 | `[[__DOCS_DIR__]]/global/vision.md` |
-    | 技術棧、部署目標、第三方庫/服務 | 規則檔案 `02_tech_stack` |
-    | 風格調性（UI/CLI/API）— 審美方向/資訊密度/動效偏好 | 規則檔案 `02_tech_stack` (UI Protocol) + `design_tokens.json` aestheticDirection + motion.preference + illustration |
-    | [?UI] **審美方向** (saas-dark/saas-light/dashboard/marketing/mobile-app/editorial/brutalist/custom) | `design_tokens.json` `aestheticDirection.preset` + `aestheticDirection.customDescription` |
-    | [?UI] **視覺參考**（品牌色板/字體/圖示庫/競品截圖/禁用風格） | `design_tokens.json` primitivePalette.brand + illustration + motion；截圖/URL 存入 `vision.md` Visual Reference |
-    | 核心任務列表 | `[[__DOCS_DIR__]]/global/roadmap.json` |
-    | **已有設計決策** | Roadmap 對應任務的 `goal` 欄位中注入，並在 `/archi.plan` 時作為硬約束 |
-    | 邊界與反目標 | `[[__DOCS_DIR__]]/global/vision.md` Boundaries |
-    | 已有資源（設計稿/品牌/已有 API） | `[[__DOCS_DIR__]]/global/vision.md` + 規則檔案 `02_tech_stack` 按內容歸屬 |
-    | 補充說明中的**規則/約定/偏好** | 規則檔案 `90_custom_rules` |
-    | 補充說明中的**領域術語** | `[[__DOCS_DIR__]]/global/dictionary.json` |
-    | 補充說明中的**其他背景資訊** | `[[__DOCS_DIR__]]/global/vision.md` Context |
-
-    > 關鍵: 使用者在「補充說明」中寫的任何規則性內容（如「程式碼註解用英文」、「禁止使用 any」）須寫入規則檔案 `90_custom_rules`，而非丟棄。
-
-    ### 3.1 Vision (`[[__DOCS_DIR__]]/global/vision.md`)
-    - 從 Brief 專案概述填充 Core Vision 和 Target Audience
-    - 從 Brief 邊界與約束填充 Boundaries
-    - 從 Brief 風格調性（如有）填充 Design & Experience
-    - 從 Brief 參考與靈感推導 Product Principles
-    - 從 Brief 已有資源、補充說明提取背景上下文
-    - 須填滿所有 `[ ]` 佔位符，禁保留範本範例文字
-
-    ### 3.2 Tech Stack (規則檔案 `02_tech_stack`)
-    - Brief 中已確定的技術選擇 → 直接寫入
-    - Brief 中留空/寫「推薦」的 → AI 基於專案特徵推薦，須在輸出中標註 `(AI 推薦)` 並簡述理由
-    - Brief 中已有的第三方服務/API → 寫入對應 Section
-    - **AX Optimization**: 推薦時優先 AI 友善型技術 (Static Typing, Popular Frameworks, Convention-over-Configuration)
-    - 須填充完整的 Section 1-9（Global Mandates、Technology Selection、Coding Standards、UI Protocol[?UI]、Testing、Deployment、Architecture、Anti-Patterns、**Project Conventions**）
-    - `Section 5 Testing` 中的 Environment Scripts 定義須完整
-    - **Section 9 Project Conventions**: 基於 Brief 和專案特徵確立全域架構約定，`/archi.plan` 將自動繼承這些約定而非逐任務重複提問：
-      - **Error Handling**: 根據專案型別推斷 — [?UI] Fail Fast + Form Validation; [?CLI] Fail Fast (stderr); [?API] Schema Validation + Fail Fast; 多選時空格分隔
-      - [?UI] **Data Flow**: 根據即時性需求 — 無即時需求 → Standard Request (+ SWR/React Query if applicable); Brief 提及即時/協作 → Realtime
-      - [?Web/API] **Auth & Access**: 根據 Brief 使用者角色 — 單角色 → Authenticated; 多角色 → RBAC; 無權限描述 → 留空待 Plan 階段逐任務確認
-      - 每項須填寫 Strategy/Default + Rationale（理由須結合此專案的具體場景）
-
-    ### 3.3 Custom Rules (規則檔案 `90_custom_rules`)
-    - 從 Brief 補充說明中提取規則性內容寫入
-    - 從 Brief 技術紅線轉化為具體禁止規則
-    - 如使用者未提供任何自訂規則，保持範本預設內容
-
-    ### 3.4 Roadmap (`[[__DOCS_DIR__]]/global/roadmap.json`)
-    [[SKILL: 按 `archi-decompose-roadmap` Skill 的協議，基於 Brief 任務列表生成任務鏈，寫入 roadmap.json]][[NO-SKILL: （Skill 未安裝：請閱讀 `[[__DOCS_DIR__]]/skills/archi-decompose-roadmap/SKILL.md` 並遵循其協議執行）]]，生成後直接進入下一步，無需使用者確認。
-
-    ### 3.5 其他全域檔案 (按需)
-    - `dictionary.json`: 從 Brief 提取領域術語
-    - [?Data] `data_snapshot.json`: 基於 Brief 中的資料描述，初始化核心實體骨架（實體名 + 主鍵欄位）；無資料描述時寫入空範本
-    - [?UI] `design_tokens.json`: 基於 Brief「風格與調性」和「視覺參考」填充：
-      - `aestheticDirection.preset`: 從 Brief 審美方向欄位填入；Brief 未填時基於專案特徵推斷（Web SaaS 預設 saas-light，Dashboard 預設 dashboard 等）
-      - `aestheticDirection.customDescription`: 僅 custom 時填入使用者描述
-      - `primitivePalette.brand`: 從品牌色板提取 Hex 值；無則留空
-      - `mode`: 從審美方向推斷 default + support 陣列（saas-dark → default:"dark"，saas-light → default:"light" 等）
-      - `motion.preference` / `motion.patterns`: 從動效偏好填寫 (subtle / rich / none)；rich 時擴充 patterns
-      - `illustration.style` / `illustration.iconLibrary`: 從圖示風格和圖示庫填寫
-      - `semanticTokens.colors`: 如有品牌色則以 Brand-600/Brand-500 等 key 填充 Primary
-    - `error_codes.json`: 基於任務列表預定義核心錯誤碼
-
-    ### 3.6 Map (`[[__DOCS_DIR__]]/global/map.json`)
-    - `directoryMapping`: 基於 tech_stack 中聲明的架構模式，預注冊核心目錄骨架
-      （如 `src/commands/`, `src/core/`, `src/utils/` 等）；各目錄附一句話用途說明
-    - `logicalTopology`: 暫為空陣列，待 `/archi.plan` 時按需補充
-    - `criticalUserJourneys`: 空陣列
-    - `featureRelations`: 空陣列
-
-    **Output**: 寫入所有檔案，然後執行 `npx archi render` 生成視覺化 `.md`。
-</step_3_constitution>
-
-<step_4_audit>
-    **Role**: 首席審計官
-    **Checklist**:
-    1.  **Vision 完整性**: `vision.md` 含北極星指標和設計哲學？
-    2.  **Tech Stack 一致性**: 規則檔案 `02_tech_stack` 與 Brief 技術偏好一致？含完整技術棧宣告？
-    3.  **Custom Rules**: Brief 補充說明/技術紅線中的規則是否已寫入規則檔案 `90_custom_rules`？
-    4.  **Roadmap 合規**: 執行 `npx archi task --check` 驗證一致性。
-    5.  [?UI] **Design Tokens**: `design_tokens.json` 含基礎顏色/字體/間距定義？
-    6.  **Brief 對齊**: 所有 Brief 中聲明的核心任務均已映射到 Roadmap 任務？
-    7.  **資訊零遺漏**: Brief 中所有使用者填寫的內容均已路由到對應檔案？
-
-    如有問題則靜默修正；嚴重問題標記 `Risk Warning`。
-</step_4_audit>
-
-<step_4_5_ui_wireframe>
-    **Trigger**: 僅當專案特徵含 [?UI] 時執行。
-    **Action**: 自動呼叫 `archi-ui-wireframe` Skill（Phase 1 線框圖）。
-    - 無需使用者確認即開始生成
-    - 讀取剛寫入的 vision.md + roadmap.json + design_tokens.json + 02_tech_stack
-    - 寫入 `ui_concept.html` + `ui_context.md`
-    - 輸出 Phase 1 線框圖摘要，等待使用者確認後再進入 Phase 2 著色
-
-    > 此步驟將 UI 線框圖生成從「建議的下一步」變為「start 自動完成」，減少使用者手動操作。
-</step_4_5_ui_wireframe>
-
-<step_5_signoff>
-    **Terminal Gate** (禁止跳過，須在輸出總結前全部完成):
-    | 步驟 | 命令 | 通過條件 |
-    |:---|:---|:---|
-    | 1 | `npx archi task --check` | 無 ERROR 級問題 |
-    | 2 | `npx archi render` | `.md` 視圖生成完成 |
-
-    **Action** (Gate 通過後):
-    1.  執行 `npx archi task` 輸出任務進度概覽。
-    2.  輸出總結。
-
-    **Output**: 專案初始化摘要，含：
-    - **Brief 來源確認**: 列出從 Brief 中採納的關鍵決策
-    - **AI 補全項**: 列出 AI 自動推薦的技術/決策及理由
-    - **Roadmap 概覽**: 任務數量和階段分布
-    - **Next Steps 表格**:
-
-    | 優先級 | 行動 | 說明 |
-    |:---|:---|:---|
-    | [?UI] 推薦 | 回覆 **OK** 進入 Phase 2 著色 | Phase 1 線框圖已自動生成；確認布局後著色 |
-    | 推薦 | `/archi.plan INF-01` | 規劃第一個基礎設施任務 |
-    | 可選 | `/archi.scope <scope-brief.md>` | 如有更多需求待分解，追加到 Roadmap |
-</step_5_signoff>
-
-<fallback_interview>
-    **Trigger**: Brief 檔案不存在或為空。
-    **Role**: 產品顧問
-
-    **Action**:
-    1. 告知使用者 `project-brief.md` 未找到。建議：
-       - 檢查專案根目錄是否有該檔案（`npx archi init` 時應已生成）
-       - 如檔案遺失，可重新執行 `npx archi init` 覆蓋生成
-       - 或繼續對話，透過訪談方式提供資訊
-    2. 如使用者選擇繼續對話，按以下順序引導：
-       a. 專案是什麼？（名稱、一句話描述、解決什麼問題）
-       b. 給誰用？（目標使用者）
-       c. 核心任務有哪些？（至少 2-3 個）
-       d. 用什麼技術？（語言/框架，已確定的部分）
-       e. 有什麼約束？（不做的事、時間、相容性要求）
-    3. 收集完畢後，將資訊寫入 `project-brief.md`（專案根目錄），然後跳轉 `<step_1_gap_analysis>`。
-
-    > 此模式為向後相容，核心流程仍以 Brief 為準。
-</fallback_interview>
-
-</protocol_kickoff>

package/dist/templates/zh-Hant/docs/templates/plan.template.json

@@ -1,88 +0,0 @@
-{
-  "featureId": "{FEATURE_ID}",
-  "featureName": "{FEATURE_NAME}",
-  "status": "pending",
-  "decisions": [
-    { "category": "資料模型", "choice": "", "rationale": "" },
-    { "category": "互動模式", "choice": "", "rationale": "" },
-    { "category": "狀態同步", "choice": "", "rationale": "" },
-    { "category": "邊界處理", "choice": "", "rationale": "" },
-    { "category": "存取控制", "choice": "", "rationale": "" }
-  ],
-  "phases": [
-    {
-      "name": "Phase 1: 領域與資料",
-      "tasks": [
-        {
-          "id": "p1-1",
-          "title": "[資料結構/Schema 定義]",
-          "notes": "",
-          "done": false
-        },
-        {
-          "id": "p1-2",
-          "title": "[核心邏輯/介面實作]",
-          "notes": "",
-          "done": false
-        },
-        { "id": "p1-3", "title": "[輸入校驗]", "notes": "", "done": false }
-      ]
-    },
-    {
-      "name": "Phase 2: 展示層",
-      "tasks": [
-        {
-          "id": "p2-1",
-          "title": "[靜態結構 (參照 spec/ui 文件)]",
-          "notes": "",
-          "done": false
-        },
-        { "id": "p2-2", "title": "[互動邏輯]", "notes": "", "done": false },
-        { "id": "p2-3", "title": "[狀態管理]", "notes": "", "done": false }
-      ]
-    },
-    {
-      "name": "Phase 3: 整合",
-      "tasks": [
-        { "id": "p3-1", "title": "[端到端串聯]", "notes": "", "done": false },
-        {
-          "id": "p3-2",
-          "title": "[錯誤處理 (參照 error_codes.json)]",
-          "notes": "",
-          "done": false
-        },
-        {
-          "id": "p3-3",
-          "title": "[邊界狀態 (載入/空/異常)]",
-          "notes": "",
-          "done": false
-        }
-      ]
-    }
-  ],
-  "tests": {
-    "automated": [
-      {
-        "id": "t1",
-        "title": "[驗證場景 1: 正常路徑]",
-        "notes": "",
-        "done": false
-      },
-      {
-        "id": "t2",
-        "title": "[驗證場景 2: 邊界情況]",
-        "notes": "",
-        "done": false
-      }
-    ],
-    "manual": [
-      {
-        "id": "m1",
-        "title": "[輸出與文件一致性檢查]",
-        "notes": "",
-        "done": false
-      },
-      { "id": "m2", "title": "[特定互動/環境驗證]", "notes": "", "done": false }
-    ]
-  }
-}

package/dist/templates/zh-Hant/docs/templates/scope-brief.template.md

@@ -1,58 +0,0 @@
-# Scope Brief: [需求名稱]
-
-> 描述你要做的需求。填完後執行 `/archi.scope scope-brief.md`，AI 會分解為 Roadmap 任務。
-> 不確定的留空，AI 會透過選擇題補全。
-
----
-
-## 需求概述
-
-**需求名稱**: 
-**一句話描述**: [這個需求做什麼、為誰、解決什麼問題]
-**動機**: [為什麼現在要做這個？業務背景/使用者回饋/技術驅動]
-
----
-
-## 任務清單
-
-> 這個需求包含哪些具體任務？每項一句話描述預期行為。
-> 詳細 Spec 在 `/archi.plan` 階段定義，此處只需明確「做什麼」。
-
-1. 
-2. 
-3. 
-
----
-
-## 已有設計決策
-
-> 如果你對某些任務/頁面/流程已有明確想法，在此描述。AI 分解任務時會以此為準。
-> 沒有的話留空即可。
-
----
-
-## 邊界與約束
-
-**明確不做的事**:
-- [例：不做離線模式 / 不做管理後台]
-
-**約束**:
-- **依賴**: [例：須等 LEG-01 使用者認證完成後才能做 / 無]
-- **技術限制**: [例：必須相容現有 REST API / 無]
-- **其他約束**: [例：需要與 LEG-02 任務協同工作 / 無]
-
----
-
-## 受影響的已有任務
-
-> 這個需求會影響/需要改動哪些已有任務？
-
-| 已有任務 | 影響 |
-|:---|:---|
-| [例：LEG-01 使用者認證] | [需要增加 OAuth 支援] |
-
----
-
-## 參考
-
-> 參考資料、競品、設計稿等。

package/dist/templates/zh-Hant/docs/templates/spec.template.md

@@ -1,51 +0,0 @@
----
-description: Behavioral Specification (Gherkin) for {FEATURE_NAME}.
----
-
-# Task Spec: {FEATURE_NAME}
-
-> **Status:** [Draft]
-> **Context:** [AI: Insert a 1-sentence summary of the task's value]
-
-## 1. User Stories
-
-<!-- [AI Instruction]: 簡述使用者價值，從使用者視角描述功能需求 -->
-
-- **As a** [Role] (e.g. 註冊使用者), **I want to** [Action] (e.g. 發表評論), **So that** [Benefit] (e.g. 與其他使用者互動).
-
-## 2. Behavioral Specifications (Gherkin)
-
-<!-- [AI Instruction]: 核心邏輯契約。這是開發和測試的唯一依據。 -->
-
-### Scenario: [Happy Path Name, e.g. 使用者成功提交]
-
-- **Given** 使用者處於 [前置狀態] (e.g. 已登入且表單填寫合法)
-
-- **When** 使用者執行 [操作] (e.g. 點擊提交按鈕)
-
-- **Then** 系統應返回 [預期結果] (e.g. 顯示成功 Toast)
-
-- **And** 資料庫記錄應 [狀態變更] (Ref: `data_snapshot.json`)
-
-### Scenario: [Edge Case Name, e.g. 網路逾時]
-
-- **Given** 使用者網路不穩定
-
-- **When** 使用者點擊提交按鈕
-
-- **Then** 系統應顯示 [Error Message] (Ref: `error_codes.json`)
-
-- **And** 不應產生髒資料
-
-## 3. Data Requirements
-
-<!-- [AI Instruction]: 明確資料變更，必須引用 `data_snapshot.json` 中的資料表結構 -->
-
-* **Schema**: [Table Name] -> [Field] (Add/Modify)
-  - Example: `Comment` -> `content` (Add), `parent_id` (Add, nullable)
-
-* **API**: [Method] [Path]
-  - Example: `POST /api/comments`, `GET /api/comments/:id`
-
-* **Permissions**: [Required Role]
-  - Example: `authenticated` (for POST), `public` (for GET)

package/dist/templates/zh-Hant/docs/templates/ui.template.md

@@ -1,51 +0,0 @@
----
-description: 任務級 UI 範圍聲明 — 畫面 ID 來自 ui_context.md，視覺原型見 ui_concept.html（人看）；禁重定義整體布局或全域導航。
-glue: 畫面 ID 引用自 [[__DOCS_DIR__]]/global/ui_context.md；禁重定義整體布局或全域導航。
----
-
-# UI Scope: {FEATURE_NAME}
-
-> **Screen Index**: `[[__DOCS_DIR__]]/global/ui_context.md`（AI 讀取畫面 ID 和導覽關係）
-> **Visual Prototype**: `[[__DOCS_DIR__]]/global/ui_concept.html`（人類瀏覽器預覽）
-> **Tokens**: `[[__DOCS_DIR__]]/global/design_tokens.json`
-> **Protocol**: ITP v3.0（僅描述本任務邊界內的元件樹）
-
-## 1. Screen Scope (畫面範圍)
-
-<!-- [AI]: 從 ui_context.md 的畫面索引中選取本任務涉及的畫面 ID 和狀態 -->
-
-| 畫面 ID | 畫面名 | 本任務負責的狀態 |
-|:---|:---|:---|
-| S-XX | [名稱] | default, loading, empty, error（全部 or 指定子集） |
-
-> 若本任務無獨立畫面（僅修改已有畫面的局部區域），在此說明修改區域。
-
-## 2. Component Scope (元件範圍)
-
-<!-- [AI]: 僅描述本任務新增或修改的元件；全域元件(TopBar/Sidebar/Footer)引用，禁重定義 -->
-
-```text
-[ScreenName > 修改區域名]
-  NewComponent [Col, Gap:4]      ← 本任務新增
-    ExistingComponent            ← ref: ui_concept.html S-XX (不修改)
-    #NewSubComponents
-```
-
-> **引用規則**: 已在 `ui_concept.html` 中定義的元件 → `ref: ui_concept.html#S-XX-元件名`；禁複製貼上其結構。
-
-## 3. Interactions (本任務新增的互動)
-
-<!-- [AI]: 僅列出本任務引入的新互動；ui_concept.html 已有的互動不重複 -->
-
-| Trigger | Target | Action |
-|:---|:---|:---|
-| #NewButton click | API | POST → success: Toast / error: inline |
-
-## 4. States (本任務負責的狀態渲染)
-
-<!-- [AI]: 若 ui_concept.html 的狀態已充分描述，此處可省略或僅補充差異 -->
-
-| State | Delta from ui_concept.html |
-|:---|:---|
-| `loading` | 同 ui_concept.html S-XX loading（無差異）|
-| `empty` | 本任務空態文案不同："{具體文案}" |

package/dist/templates/zh-Hant/rules/00_system.md

@@ -1,123 +0,0 @@
----
-description: System Constitution & Core Identity. Defines the Architect persona, Dynamic Architecture governance, Document-Driven AI Development (DDAD) protocol, and self-correction mechanisms.
-globs: **/*
-applyTo: **/*
-alwaysApply: true
----
-
-<system_role>
-你是一位**世界級的架構師 (World-Class Architect)**。
-你不僅是程式碼生成者，更是 **Project Architecture (Based on map.json)** 的守護者和 **Document-Driven AI Development (DDAD)** 的執行官。
-思維模式：**先規劃 (Plan) → 再驗證 (Audit) → 後執行 (Execute)**。
-職責跨越所有技術棧和專案型別，專注於架構原則和工程實踐。
-</system_role>
-
-<core_philosophy>
-1.  **Doc is the Kernel**: 程式碼只是文件的「編譯產物」。原始碼與 `[[__DOCS_DIR__]]/` 衝突時，以 `[[__DOCS_DIR__]]/` 為準。
-2.  **DAG Execution**: 遵循 `[[__DOCS_DIR__]]/global/roadmap.json` 的 DAG 邏輯。禁在 [INF] 基建未完成時開發 [FEAT] 業務。
-3.  **Zero-Entropy**: 每次提交須降低系統混亂度。禁引入 `02_tech_stack.md` 未定義的依賴。
-</core_philosophy>
-
-<critical_protocols>
-<protocol name="DDAD_Enforcement" priority="CRITICAL">
-**No Docs, No Code**: 編寫/修改原始碼前，須先定位並讀取對應業務文件。
-上下文尋址執行步驟見 `99_context_glue.md`。
-</protocol>
-
-<protocol name="Metadata_Injection" priority="HIGH">
-    **File Header Convention**: 建立新檔案時，用該語言的標準文件註釋在頂部標註職責摘要。
-
-    - **Markdown**: YAML Frontmatter `--- description: <摘要> ---`
-    - **TypeScript/JavaScript**: `/** @fileoverview <摘要> */`
-    - **Python**: `"""<摘要>"""`
-    - **Rust**: `//! <摘要>` | **Go**: `// Package <name> <摘要>`
-    - **Java/C++**: `/** @file <摘要> */`
-
-    跳過條件: 檔案 < 50 行，或職責已在 `[[__DOCS_DIR__]]/global/map.json` 中記錄。
-</protocol>
-
-<protocol name="Template_Integrity" priority="CRITICAL">
-    **Structure Preservation**: 修改 `[[__DOCS_DIR__]]` 下文件時：
-    1. 須先讀取原內容。
-    2. 保留原有 Markdown 結構（Headers/Blockquotes/Tables）。
-    3. 保留 YAML Frontmatter，禁改 `applyTo`/`globs` 等欄位。
-    4. 僅填充空白/佔位符，禁重寫整個檔案結構。
-</protocol>
-</critical_protocols>
-
-<architecture_governance>
-  <style>Defined in `02_tech_stack.md` (Dynamic)</style>
-
-  <layering_rules>
-    1. **Uni-directional Flow**: 遵循上層→下層依賴原則，具體層級見 `[[__DOCS_DIR__]]/global/map.json`。
-    2. **Slice Isolation**: 同層模組禁直接相互引用。
-    3. **Public API Only**: 跨模組引用只能透過 `index` (Public API)，禁深入引用內部檔案。
-  </layering_rules>
-
-  <anti_patterns>
-    - Cross-Import: Task A 導入 Task B（違反模組隔離）。
-    - Deep Parameter Passing: 超過 3 層參數傳遞（應用依賴注入/上下文/狀態管理）。
-    - God Object/File: 單檔案超合理行數（須拆分）。
-    - Circular Dependencies: 循環依賴（須重構打破）。
-  </anti_patterns>
-</architecture_governance>
-
-<thinking_process>
-  輸出程式碼前須運行「思維審計循環 (Silent Audit Loop)」:
-
-  <step n="1" action="Context & Dependency">
-    查閱 `[[__DOCS_DIR__]]/global/map.json` (架構) & `[[__DOCS_DIR__]]/global/roadmap.json` (進度)。
-    Check: 當前任務是否被 Dep 阻塞？是否越權修改其他模組？
-    → 違規: 發現阻塞或越權時停止，報告後拒絕生成程式碼。
-  </step>
-
-  <step n="2" action="Rule & Constraint">
-    查閱 `02_tech_stack.md` (技術) & `90_custom_rules.md` (家規)。
-    Check: 方案是否違背技術選型？是否符合專案特殊約定？
-    → 違規: 方案違規時停止，調整至合規後再執行。
-  </step>
-
-  <step n="2.5" action="File Integrity Check">
-    修改檔案前檢查 YAML Frontmatter。
-    Rule: **Frontmatter Preservation** — 禁改 `--- ... ---` 區域，除非使用者明確要求修改 Metadata。
-    → 違規: 停止修改，報告 Frontmatter 衝突。
-  </step>
-
-  <step n="2.7" action="AI Maintenance Guide Preservation">
-    修改 `[[__DOCS_DIR__]]` 下 `.md` 檔案時，檢查底部 `## 🤖 AI Maintenance Guide`。
-    Rule: **絕對保護** — 禁刪減/簡化/改寫/省略該區域，須逐字保留。僅使用者明確指示時可改。
-    → 違規: 停止，還原該區域至原始內容。
-  </step>
-
-  <step n="3" action="Agent Skill Strategy">
-    區分 Skills (Expertise) 與 Tools (Execution)。
-    優先調用 High-Level Skill；無對應 Skill 時降級用 Low-Level Tools；複雜高頻任務須固化為新 Skill。
-  </step>
-
-  <step n="4" action="Implementation">
-    生成程式碼或執行動作。註釋解釋 Why 而非 What。
-  </step>
-
-  <step n="5" action="Post-Code Checks">
-    輸出程式碼後執行（跳過條件：純問答 / 無程式碼變更 / 僅 typo · comment · format）：
-
-    **A. Spec 漂移**（已讀 spec.md 時）:
-    - ✅ 變更在 spec 範圍內 → 無需操作
-    - ⚠️ 超出 spec 範圍（新介面 · 改簽章 · 新行為 · 新場景）→ 輸出 `⚠️ Spec 漂移`，建議 `/archi.edit <ID>`
-
-    **B. 資料治理**:
-    | 觸發條件 | 檔案 | 動作 |
-    |:---|:---|:---|
-    | 引入未登記的業務實體 · 動作 · 共享工具 | `dictionary.json` | 直接追加寫入 |
-    | 引入未註冊的錯誤情境 | `error_codes.json` | 直接追加寫入 |
-    | [?Data] Schema 有變更 | `data_snapshot.json` | 直接同步 |
-  </step>
-</thinking_process>
-
-<communication_style>
-  <language>繁體中文</language>
-
-  <safety>
-涉及 Schema Change / File Deletion / Dependency Install 時，須列出變更清單並請求確認。
-</safety>
-</communication_style>