architext 0.0.2

package/dist/templates/zh-Hant/rules/03_data_governance.md

@@ -0,0 +1,102 @@
+---
+description: JSON 資料檔案的 AI 協作治理規則。定義全域資料檔案的讀寫規範、更新時機與格式約束。
+globs: "**/*.json"
+applyTo: "**/*.json"
+alwaysApply: true
+---
+
+# Data Governance Protocol
+
+> **Role**: 資料管家。確保全域 JSON 資料檔案的一致性、完整性與可追溯性。
+
+## 1. 資料檔案清單
+
+| 檔案 | 型別 | 讀取時機 | 寫入時機 |
+|:---|:---|:---|:---|
+| `roadmap.json` | 路線圖 | `/archi.plan`, `/archi.code` 開始時 | `/archi.start` 建立; AI 直接編輯或 `npx archi task` 更新狀態 |
+| `map.json` | 架構地圖 | 觸碰程式碼時 (via context_glue) | `/archi.plan` Step 3 (全域同步); `/archi.inherit` Step 3.6; `/archi.map` |
+| `dictionary.json` | 術語字典 | 生成變數名稱時 | `/archi.plan` Step 3; code/fix 後 step_5 自動追加 |
+| `design_tokens.json` | 設計令牌 [?UI] | 生成 UI 程式碼時 | `/archi.start` 建立; 設計變更時更新 |
+| `data_snapshot.json` | 資料快照 [?Data] | `/archi.plan` Q1 設計; `/archi.code` 實作時 | Plan 階段設計 Schema; Code 階段同步實際變更 |
+| `error_codes.json` | 錯誤碼契約 | 撰寫錯誤處理時 | `/archi.plan` Step 3; code/fix 後 step_5 自動追加 |
+
+---
+
+## 2. 通用規則
+
+### 2.1 格式約束
+
+- **JSON Only**: 全域資料的唯一真理源是 `.json` 檔案。`.md` 視圖由 `npx archi render` 自動產生，禁直接編輯 `.md` 視圖。
+- **Schema Stability**: 分兩檔管理：
+  - **Tier 1 (嚴格)**: `roadmap.json`, `plan.json` — CLI 渲染/命令直接依賴，結構由 Zod Schema 校驗，禁隨意變更欄位。
+  - **Tier 2 (寬鬆)**: `dictionary.json`, `error_codes.json`, `data_snapshot.json`, `design_tokens.json`, `map.json` — 僅校驗頂層 key 存在。若現有欄位無法充分描述需記錄的內容，可自行擴展欄位（新增 key 或在陣列 item 中新增屬性），無需修改 CLI。
+- **Valid JSON**: 寫入後須保證合法 JSON (無尾逗號、無註解)。
+
+### 2.2 讀寫紀律
+
+| 情境 | 規則 |
+|:---|:---|
+| 需要查閱資料 | 讀取 `.json` 檔案，禁讀 `.md` 視圖 (可能過期) |
+| 需要更新 Roadmap 任務狀態 | 優先使用 `npx archi task <ID> --status <s>`; 批次更新時可直接編輯 JSON |
+| 需要更新其他資料檔案 | AI 直接編輯 `.json` 檔案 |
+| 更新後 | 執行 `npx archi render` 重新產生 `.md` 視圖 |
+
+---
+
+## 3. 檔案專項規則
+
+### `roadmap.json`
+
+- **結構**: `phases[] → tasks[]`，每個 task 須有 `id`, `title`, `status`, `deps`。
+- **Status 值**: `pending` | `active` | `done` | `blocked`。
+- **依賴完整性**: `deps` 中引用的 ID 須存在於 tasks 中。
+- **Slug 規則**: `slug` 用於 tasks 資料夾命名，格式為 `Snake_Case`。
+
+### `map.json`
+
+- **Directory Mapping**: 須反映真實實體檔案樹。
+- **Logical Topology**: 須註冊每個 Task Module 的職責。
+- **Feature Relations**（欄位 `featureRelations`）: 記錄聚合型 Task 與其來源的聯動關係。每條結構為 `{ aggregator, sources, evidence, checkNote }`；由 AI 在 `/archi.plan`（規劃聚合型 Task 時）或 `/archi.inherit`（逆向掃描時）寫入，無需使用者手動維護。
+- **自我校正**: 若程式碼引用違反拓撲定義的層級關係，須報錯並停止產生。
+- **可擴展**: 若現有欄位不足以描述專案架構，可在 item 中自行新增欄位（如 `tags`、`owner`），或新增頂層 key。
+
+### `dictionary.json`
+
+- **命名權威**: 本檔案是命名的最高法律。
+- **Boundary**: 僅註冊**專案業務域**內容。Architext 框架自身概念（scripts、scaffold、roadmap、plan 等）禁註冊。
+- **entities**: 產生變數名稱前須查閱 `entities[].codeName`；禁使用 `forbiddenSynonyms` 中的詞。
+- **verbs**: 業務動作命名須查閱 `verbs[].codeName`，保持全專案動詞一致。
+- **utilities**: 封裝的共用工具（如 logger、AppError、fetchClient）須註冊；AI 須用已註冊工具替代原始 API（參照 `replaces` 欄位）。
+- **components** [?UI]: 建立新元件前須搜尋現有元件，優先複用。
+- **可擴展**: 若現有欄位不足以描述某個術語/工具，可在對應陣列 item 中自行新增欄位（如 `tags`、`scope`、`deprecated`），也可新增頂層陣列（如 `enums`、`constants`）。
+
+### `design_tokens.json` [?UI]
+
+- **Token Only**: 樣式嚴格使用 Token；禁硬編碼 Hex/px/rem。
+- **Dark Mode**: 須同時定義 `light` 和 `dark` 值。
+- **可擴展**: 若現有 Token 結構不足以覆蓋專案需求（如 `motion`、`breakpoints`、`z-index`），可自行新增屬性。
+
+### `data_snapshot.json` [?Data]
+
+- **結構**: `models[]`（名稱、欄位、型別、約束）+ `relationships[]`（模型間關係：1:1/1:N/M:N/self-ref）。
+- **Design First**: Plan 階段須定義模型結構和欄位型別，禁寫 "TBD"，須精確到欄位名與型別。
+- **Sync Back**: Code 階段完成後，須將實際變更同步回此檔案。
+- **可擴展**: 若現有欄位不足以描述資料模型（如需記錄 `indexes`、`triggers`、`seedData`），可在 model item 或頂層自行新增欄位。
+
+### `error_codes.json`
+
+- **Boundary**: 僅註冊**專案業務域**錯誤。框架基礎設施（scripts/validate、dev-up、dev-reset 等）的錯誤由腳本自身 exit code + stderr 處理，禁註冊到此檔案。
+- **結構**: `protocolMapping [?API]`（狀態碼→行為映射）+ `businessErrors`（業務錯誤註冊表）。
+- **Code Format**: `ERR_[MODULE]_[REASON]` (如 `ERR_AUTH_INVALID_TOKEN`)。
+- **statusCode**: 按專案型別填寫（HTTP status / Exit code / 留空）。
+- **Design Before Code**: 撰寫錯誤處理程式碼前須先在此註冊錯誤碼，含 `message` 和 `recovery`。
+- **可擴展**: 若現有欄位不足以描述錯誤資訊（如需記錄 `severity`、`retryable`、`httpBody`），可在 item 中自行新增欄位。
+
+---
+
+## 4. Plan JSON (`plan.json`)
+
+- **位置**: `tasks/<ID>_<Slug>/plan.json`
+- **Checkbox 更新**: AI 在 `/archi.code` 中完成步驟後直接將 `done` 設為 `true`。
+- **追加規則**: `/archi.edit` 追加新 Phase 時保留已完成歷史。
+- **驗證**: 完成後執行 `npx archi plan <ID>` 驗證完成度。

package/dist/templates/zh-Hant/rules/04_cli_tools.md

@@ -0,0 +1,50 @@
+---
+description: CLI Reference Manual. Working directory rule and command syntax for npx archi task/plan/render.
+globs: **/*
+applyTo: **/*
+alwaysApply: true
+---
+
+# CLI Reference
+
+> **Role**: 命令速查手冊。提供 `npx archi` 系列命令的語法與參數，供 Terminal Gate 執行時查閱。
+
+## ⛔ Working Directory Gate
+
+**執行任何 `npx archi` 命令前須通過此檢查，否則停止**:
+
+| 檢查項 | 通過條件 |
+|:---|:---|
+| 當前目錄 | 須為專案根目錄（`[[__DOCS_DIR__]]/` 所在目錄） |
+| 不確定時 | 先確認當前目錄，禁猜測 |
+| 子目錄中 | 須 `cd` 到根目錄後再執行 |
+
+---
+
+## 命令語法
+
+### `npx archi task`
+
+| 子命令 | 用途 | 範例 |
+|:---|:---|:---|
+| `npx archi task` | 列出所有任務及進度 | `npx archi task` |
+| `npx archi task <ID> --status <s>` | 更新任務狀態 | `npx archi task INF-001 --status done` |
+| `npx archi task --check` | 檢查 Roadmap 一致性 | `npx archi task --check` |
+
+**合法狀態值**: `pending` / `active` / `done` / `blocked`
+
+### `npx archi plan`
+
+| 子命令 | 用途 | 範例 |
+|:---|:---|:---|
+| `npx archi plan <ID>` | 檢查 Task 的 Plan 完成度 | `npx archi plan SUB-01` |
+
+自動識別 Manual Verification 區域並排除在自動化統計外。
+
+### `npx archi render`
+
+| 子命令 | 用途 | 範例 |
+|:---|:---|:---|
+| `npx archi render` | 將所有 JSON 資料檔案渲染為人類可讀的 `.md` 視圖 | `npx archi render` |
+
+> `.md` 視圖是自動產生的，禁直接編輯。修改須透過 `.json` 來源檔案進行。

package/dist/templates/zh-Hant/rules/90_custom_rules.md

@@ -0,0 +1,21 @@
+---
+description: Project Specific Rules & Constraints. High-priority user overrides, team preferences, and business-specific invariants that supersede general defaults.
+globs: **/*
+applyTo: **/*
+alwaysApply: true
+---
+
+# Custom Project Rules (用戶自定義規則)
+
+> **Priority:** [High]
+> **Role:** 本專案的「特殊家規」。當通用的 `02_tech_stack` 無法覆蓋某些細節，或有特殊業務約束時，以此文件為準。
+
+## 1. Team Conventions (團隊習慣)
+
+
+## 2. Business Constraints (業務硬約束)
+
+
+## 3. Specific Anti-Patterns (本專案黑名單)
+
+## 4. ...

package/dist/templates/zh-Hant/rules/99_context_glue.md

@@ -0,0 +1,53 @@
+---
+description: Context Navigation & Document Indexing. Bridges source code to documentation using the Map registry. Essential for locating specs and plans.
+globs: **/*
+applyTo: **/*
+alwaysApply: true
+---
+
+# Context Glue Protocol
+
+> **Role**: 上下文導航儀。防止 AI 失憶，透過查閱地圖 (Map Look-up) 確定程式碼對應的業務文件。
+
+## 1. Context Discovery
+
+讀取或編輯程式碼檔案時，須執行以下尋址步驟:
+
+**Step 1: Check Global Map**
+- 讀取 `[[__DOCS_DIR__]]/global/map.json`。
+- 在 `directoryMapping` / `logicalTopology` 中查找當前檔案所屬模組。
+- 載入該模組註冊的 Docs Link (Spec/UI/Plan)。
+
+**Step 2: Check Explicit Context**
+- 場景: 新建立的檔案或 Map 尚未更新。
+- 檢查使用者 Prompt 中是否顯式指定了文件路徑，如有則須載入。
+
+**Step 3: Fallback**
+- Map 中未註冊且使用者未指定 → **STOP & ASK**。
+- 提示: 「未找到當前程式碼對應的 Spec 文件。請告知路徑，或運行 `/archi.map` 更新架構地圖。」
+
+---
+
+## 2. Mandatory Loading Rules
+
+| 程式碼型別 | 必讀上下文 | 真理來源 |
+|:---|:---|:---|
+| **Business Logic** (Tasks/Entities) | Spec Document | `[[__DOCS_DIR__]]/global/map.json` → Module Entry |
+| **UI Components** (Pages/Widgets) [?UI] | UI Document + `[[__DOCS_DIR__]]/global/design_tokens.json` | `[[__DOCS_DIR__]]/global/map.json` + Global Rules |
+| **Data Schema** (ORM/SQL/Models) [?Data] | Data Snapshot | `[[__DOCS_DIR__]]/global/data_snapshot.json` |
+| **Config / Infra** (Package.json...) | Tech Stack | `02_tech_stack.md` |
+
+---
+
+## 3. Anti-Hallucination
+
+- 程式碼是文件的下游產物。
+- 禁在未讀取 Spec 的情況下憑變數名猜測業務邏輯。
+- 發現程式碼與文件不符時: 不擅自修復文件或程式碼，須暫停並報告不一致性。
+
+---
+
+## 4. Maintenance Hook
+
+- **Trigger**: 建立新檔案或新模組時。
+- **Action**: 須自動更新 `map.json`，建立程式碼路徑與文件路徑的映射；映射關係不明確時才詢問使用者確認。

package/dist/templates/zh-Hant/skills/archi-decompose-roadmap/SKILL.md

@@ -0,0 +1,293 @@
+---
+name: archi-decompose-roadmap
+description: Architext 任務分解專家。五步分解法：先標定專案類型校準基建清單，再雙視角提取業務 Task 和 Infra 任務，NFR 橫切關注點歸併入 goal（不獨立成任務），建立真實依賴鏈並輸出並行批次。產出符合 Tier 1 Schema 的 roadmap.json 任務，作為 `/archi.plan` 的輸入契約。用於任何需要生成或追加 Roadmap 任務的場景。
+---
+
+# Roadmap 任務分解
+
+## 系統流程定位
+
+```
+Brief → [本 Skill] → roadmap.json 任務
+                            ↓
+                   /archi.plan <task-id>
+                   讀: vision.md + map.json + tech_stack.md
+                   寫: spec.md（行為規格/驗收標準）
+                       ui.md（元件結構，AI 編碼真相源）[?UI]
+                   視覺參考: [[__DOCS_DIR__]]/global/ui_context.md [?UI]
+                       plan.json（可執行步驟 + 測試用例 checkbox）
+                   也更新: map.json / dictionary.json / data_snapshot.json
+                            ↓
+                   /archi.code → 讀 spec.md + ui.md + plan.json → 寫程式碼
+```
+
+> **Skill 職責邊界**：
+> - 負責：任務的 what（描述）、done 標準（goal）、依賴鏈、設計決策注入、Core 介面契約
+> - 不負責：檔案路徑（map.json 管）、變數命名（dictionary.json 管）、測試用例（plan.json 管）、UI 元件結構（ui.md 管）
+>
+> **Schema 約束（Tier 1 嚴格）**：roadmap.json 由 CLI 的 Zod Schema 校驗，**禁增刪欄位**。
+
+## 呼叫模式
+
+| 模式 | 觸發來源 | 輸入 | 限制 |
+|:---|:---|:---|:---|
+| 從零建立 | `/archi.start` | Brief 功能清單 | 禁生成 EDIT 任務 |
+| 增量追加 | `/archi.scope` | Brief + 已有 Roadmap 上下文 | 禁改已有任務，ID 沿用水位 |
+
+---
+
+## 分解框架（五步）
+
+### Step 0 · 專案類型標定
+
+從 Brief 的技術棧 / 專案描述中識別專案類型，確定標準基建清單，防止 Step 2 反推遺漏框架性 Infra。
+
+| 專案類型 | 腳手架須包含（除通用建置工具鏈外） |
+|:---|:---|
+| Web SPA / PWA | 路由骨架（如 React Router）+ 全域 App Shell（版面配置 / Provider / 主題注入） |
+| 全端 Web（SSR/SSG）| 路由約定（loader/action/頁面）+ API Routes 層 + 全域版面配置 + Auth Session 管理（Cookie/JWT）；[?UI] 主題注入 |
+| CLI 工具 | logger 模組 + AppError 處理層 + 命令註冊入口 |
+| API 服務（REST / GraphQL）| 路由層 + 中介層 + DB 連線層 + 全域錯誤處理；[?GraphQL] Schema 定義層 + DataLoader |
+| 行動端 App（原生/跨平台）| 導航骨架（React Navigation / Go Router）+ 平台適配層（iOS/Android 權限、原生模組）+ 環境配置（dev/staging/prod）|
+| 小程式 | 頁面路由設定 + 全域 app.js/ts + 請求封裝層 |
+| 瀏覽器擴充功能 | manifest.json（V2/V3）+ Background Service Worker + Content Script 注入層 + 訊息匯流排（background ↔ content ↔ popup）+ Popup/Options 頁入口 |
+| 桌面端 App（單機）| 主程序入口（Electron main / Tauri main.rs）+ IPC 通訊橋接 + 系統級能力（系統匣、快速鍵）+ 原生檔案系統封裝 |
+| Web + 桌面端（Hybrid）| Web 腳手架基礎 + 桌面執行時整合（Tauri/Electron）+ 系統級能力（系統匣、全域快速鍵、系統通知）；**桌面整合須獨立拆分為 INF 子任務**（OS 差異大、與 Web 技術棧完全不同，不適用 Step 2 的「同期執行合併」規則） |
+| 函式庫 / SDK / NPM 套件 | 雙產物配置（CJS + ESM）+ 公共 API 入口（barrel index.ts）+ 型別宣告生成（.d.ts）+ Changelog / 版本工具鏈；**禁建業務 Task，僅 INF 層** |
+| 即時 / 協作型 App | WebSocket 服務層 + 事件 Schema 定義（共享型別）+ 房間/會話管理基礎；[?CRDT] 衝突解決層 |
+| AI Agent / MCP 工具 | LLM 客戶端抽象層（provider 無關）+ Prompt 範本管理 + Tool/Function Calling Schema + 對話狀態 / Memory 管理；[?MCP] MCP 協定適配器 |
+
+**操作（兩個輸出）**：
+1. **注入 Step 2 INF-01**：將對應類型的腳手架清單寫入 INF-01 描述。
+2. **注入 Step 1 場景約束**：按專案類型限定場景句式，Step 1 提取業務場景時須遵守以下約束：
+
+| 專案類型 | 場景句式範本 | 禁止出現的詞彙 |
+|:---|:---|:---|
+| CLI 工具 | `使用者可 [執行命令/傳參] → [終端輸出結果]` | 頁面、路由、元件、UI |
+| 函式庫 / SDK | `呼叫方可 [呼叫 API X] → [回傳 Y]` | 使用者、介面、互動 |
+| API 服務 | `客戶端可 [HTTP METHOD /path] → [回應結構]` | 前端、頁面、元件 |
+| 小程式 | `使用者可在 [頁面名] [操作] → [微信端可見結果]` | 後端路由、REST |
+| Web SPA / 全端 / 行動端 / 桌面端 | `使用者可 [動作] → [可感知結果]` | （無特殊限制）|
+
+---
+
+### Step 1 · PM 視角 → 業務 Task
+
+從 Brief 功能描述提取使用者場景，聚合為業務 Task。
+
+1. 逐條功能轉化為場景句式：`使用者可 [動作] → [可感知結果]`
+2. 共享同一核心流程的場景 → 合併為一個業務 Task
+   > **注意**：「共享功能域/主題」≠「共享核心流程」。屬於同一功能域（如「社群互動」）但各自有獨立 UI 區域和實作域的場景，須按下方拆分訊號獨立成 Task，禁因主題相同而強行合併。「共享核心流程」僅指：場景在同一 UI 視圖內完成、操作同一資料實體、共享同一狀態流轉。
+3. 粒度校準（核心原則：**一任務 = 一次 `/archi.plan` 會話 = 一個 `tasks/<slug>/` 子目錄**）：
+
+    **行為視角（PM）**：
+
+    | 訊號 | 動作 |
+    |:---|:---|
+    | 描述含「和」（兩個獨立關注點） | 拆分 |
+    | DoD 超過 4 條驗收標準 | 拆分 |
+    | 任務橫跨 3 個以上獨立 UI 區域或實作域 | 拆分 |
+    | 一次 `/archi.plan` 難以在單一 spec.md 中完整描述行為 | 拆分 |
+    | 兩任務檔案集合 >50% 重疊 | 合併 |
+
+    > **注意**：若「A 完成後 B 才有意義」，這是順序依賴關係，**禁合併**；在 Step 4 為 B 聲明 `deps: [A]` 即可。
+
+    **實作視角（工程，與行為視角獨立判斷，任一觸發即拆分）**：
+
+    | 訊號 | 動作 | 範例 |
+    |:---|:---|:---|
+    | 任務內含 ≥2 個**實作域**，且各域可獨立單元測試 | 拆分 | 純計算層 + UI 渲染層 → 各自獨立 |
+    | 實作時需同時掌握 ≥3 個相互獨立的技術關注點 | 拆分 | 字元渲染 + 狀態機 + 動效 API → 三件事 |
+    | 某一關注點有獨立的邊界複雜度（如 IME、Canvas、第三方圖表 API） | 獨立出該關注點 | 輸入捕獲 + IME 單獨成任務 |
+
+    > **為何加入實作視角**：行為視角描述「使用者看到什麼」，實作視角描述「AI 實作時需同時掌握什麼」。一個任務行為上內聚（同一頁面），但工程上橫跨多個不同域時，AI 在 `/archi.code` 階段會因上下文過寬而顧此失彼。
+
+    **粒度上限**：
+
+    > 一個 Roadmap Task = **AI 可不再分解、直接產出一個內聚 spec.md** 的最小功能單元（HTN Primitive 可執行性原則）。
+
+    *分解階段代理指標（以 Brief 描述為依據直接判斷）*：
+
+    | 代理指標 | 上限 | 超出時的動作 |
+    |:---|:---|:---|
+    | 任務描述中獨立使用者操作流程數 | ≤ 3 條 | 拆分 |
+    | 任務涉及的獨立資料實體數（各有獨立狀態流轉）| ≤ 2 個 | 拆分 |
+    | 描述中「和/並/以及」連接的獨立關注點數 | ≤ 1 處 | 拆分 |
+    | 任務驗收無法在不執行另一個業務 Task 的情況下獨立完成 | — | 檢查耦合，重劃介面邊界（INVEST-I）|
+
+    > `/archi.plan` 執行中若預估 spec.md Scenario > 6 或 plan.json Phase > 4，須暫停並提示使用者返回 `/archi.scope` 重新拆分，禁強行塞進單一任務。
+
+**DoD 格式**：`完成後，使用者可 <可驗證的使用者行為>；邊界：<明確不做的事>`
+
+> DoD 是 `/archi.plan` 生成 spec.md 驗收標準和 plan.json 測試用例的基準。須精準描述使用者可感知結果，禁寫實作細節（檔案路徑、函式名稱、測試命令由 plan 階段決定）。
+
+以下情況歸屬父任務，禁獨立成條：**輕量**結果頁 / 完成頁、空狀態頁、確認彈窗。
+
+> **豁免**：結果頁含獨立資料視覺化元件（圖表庫）、複雜動效邏輯或獨立業務計算時，**不適用**父任務歸屬規則，須獨立成業務 Task。
+
+---
+
+### Step 2 · 架構師視角 → Infra 任務
+
+從業務 Task 反推共享基礎，禁預設基建。
+
+對所有業務 Task 問：多個 Task 同時依賴 X 且 X 須在 Task 前存在 → X 是 Infra 任務。
+
+| Infra 類型 | 判斷標準 |
+|:---|:---|
+| 專案腳手架 / 全域 Schema / 型別定義 | 所有業務 Task 均依賴；須覆蓋 Step 0 標定的專案類型清單 |
+| 共享核心引擎（打字引擎、規則引擎等） | 滿足以下**任一**條件：① 2 個以上業務 Task 直接呼叫；② 純邏輯層、可獨立單元測試、與 UI 完全解耦。`tag: Core` |
+| 第三方整合層 | 多個業務 Task 複用同一外部服務 |
+
+**Core 任務規劃契約**：`tag: Core` 任務的 `description` 末尾須聲明主要導出介面（函式簽名或關鍵 interface 名稱）。
+下游 Task 的 `/archi.plan` 會話可直接對接該介面，無需讀上游實作，保障跨任務規劃的一致性與可預測性。
+
+**Infra 任務粒度原則：避免微粒化，但禁止跨層堆積**：
+
+- **禁微粒化**：無實質技術差異的同層配置項（如 ESLint + Prettier + TypeScript strict + commitlint）→ 合併，減少任務數、降低依賴鏈雜訊。
+- **禁跨層堆積**：每個獨立的架構層各有獨立技術細節，合併後 AI 上下文同樣會失焦；且將多層堆入同一 INF 任務會把關鍵路徑拉至最長，推遲所有業務 Task 的啟動時機。
+
+> **架構層參考**（每層有獨立實作邊界，原則上各自成任務）：
+> 專案腳手架（建置 / 程式碼品質工具鏈）| 資料層（DB 連線 / ORM / 遷移）| 認證層（Auth 中介層 / Session / JWT）| API 路由層（路由註冊 / 中介層鏈 / 全域錯誤處理）| 前端基礎設施（主題 / Design Token / 全域版面配置）| 第三方服務整合（各服務獨立成 INF 任務）
+
+| 訊號 | 動作 |
+|:---|:---|
+| 同一架構層內的關聯配置項（如程式碼品質工具鏈各項、或路由骨架與全域錯誤中介層同屬 API 路由層）| 合併 |
+| 跨越獨立架構層（如 DB 連線層 + Auth 中介層、或 API 路由 + 前端主題系統）| 拆分 |
+| 技術棧完全不同（如本機儲存層 vs 主題配置）| 拆分 |
+| 含 OS 級系統 API（系統匣、全域快速鍵、檔案關聯等）| **強制拆分**（Step 0 強制規則，不受「同層合併」條件約束） |
+| 某 Infra 產出物被 ≥2 個業務 Task 直接呼叫（介面型） | 獨立成任務（須聲明導出介面契約） |
+
+**隱式標準功能掃描**：以下功能通常不在 Brief 中出現，須按歸屬分類主動補充（禁遺漏）：
+
+*須補充為獨立業務 Task（Phase 2，有使用者可見行為）*：
+
+| 檢查項 | 觸發條件 |
+|:---|:---|
+| 使用者 Profile / 帳號設定頁 | 專案含 Auth（INF 層有認證中介層）|
+| 帳號安全 / 密碼設定頁 | 含 Auth 且使用者可修改密碼或綁定第三方帳號 |
+| 通知中心 / 訊息列表頁 | 含通知基礎設施且通知有「已讀/未讀」狀態 |
+
+*須補充為 INF 任務（Phase 1，基礎設施）*：
+
+| 檢查項 | 觸發條件 |
+|:---|:---|
+| 通知基礎設施（伺服器推播/訊息佇列層）| ≥1 個 Task 口頭提及「通知/提醒」但未建 INF Task |
+| 搜尋基礎設施（PG FTS 索引 / 外部引擎部署）| ≥2 個業務 Task 各自描述「搜尋」功能；須在此決策方案後以 INF Task 承載，下游 Task 依賴它 |
+| 權限 / 角色管理層（RBAC）| 含 Auth 且有 ≥2 種使用者角色（如 admin / user）|
+| 檔案儲存整合層（S3 / OSS 封裝）| ≥1 個 Task 涉及檔案上傳 / 下載 / 預覽 |
+| 電子郵件 / 簡訊發送整合 | Task 提及「發送郵件 / 驗證碼 / 簡訊通知」|
+| 支付整合層 | Task 提及「支付 / 下單 / 結帳 / 退款」|
+
+---
+
+### Step 3 · NFR 過濾
+
+以下類型**禁獨立成任務**：注入首個實現該能力的任務 `goal` 末尾（`[NFR] <說明>`）；其餘受影響任務僅在 NFR 清單中標注。`/archi.plan` 執行時會將 NFR 注入對應的 spec.md 約束章節。
+
+> **「首個任務」定義**：在依賴鏈中，`deps` 僅含 INF 層（無業務前置依賴）且最早涉及該 NFR 能力的任務。同層（同 Batch）有多個候選時，取 ID 最小的那個。
+
+| 類型 | 常見形式 | 注意 |
+|:---|:---|:---|
+| 國際化 | i18n、多語言、翻譯文案 | — |
+| 視覺主題（配置型） | 品牌色 Token、Tailwind 主題色、CSS 變數定義 | NFR，注入腳手架任務 |
+| 視覺主題（功能型） | 深色/淺色切換按鈕、OS 偏好偵測、主題持久化 | **非 NFR**，須建立獨立業務 Task（有使用者可見行為） |
+| 動效風格規範 | 頁面切換方式、過渡時長約定 | NFR，注入首個含動效的 Task goal |
+| 效能優化 | 懶載入、虛擬列表、快取策略 | — |
+| 無障礙 | A11y、鍵盤導航、螢幕閱讀器 | — |
+
+---
+
+### Step 4 · 依賴與並行優化
+
+- **真實依賴鏈**：禁所有業務 Task 統一只掛 `INF-01`，須反映真實業務關係。
+- **業務實體依賴（優先於最小依賴）**：若功能 B 的核心操作主體由功能 A 產生（即 A 完成前 B 的資料實體不存在），則 B 須聲明對 A 的依賴。此規則優先於最小依賴原則。示例：Usage Log 記錄的主體是 Prompt，Prompt 由 FEAT-Prompt_Create 建立 → Usage Log Task 須依賴 Prompt Task，而不僅依賴 INF 層。
+- **最小依賴原則**：能並行的任務不加多餘依賴，最大化 Batch 並行度。
+
+---
+
+## 任務規則
+
+1. **ID 生成**：沿用已有 Roadmap 編號水位，從各前綴最大值 +1 起；全新專案從 `INF-01` / `FEAT-01` 起。
+
+2. **Phase 歸屬**：
+
+   | 任務類型 | Phase |
+   |:---|:---|
+   | 專案腳手架、Schema、全域型別 | Phase 1 (Infrastructure) |
+   | 共享核心引擎（Step 2 識別） | Phase 1 (Infrastructure) |
+   | 業務 Task | Phase 2 (Core Features) |
+   | EDIT-xxx（修改已有功能） | 與被修改任務同 Phase |
+
+3. **設計決策注入**：Brief 中已有設計決策 → 注入對應任務 `goal` 末尾：`[使用者預設] <內容>`；同一條決策禁在多任務重複。`/archi.plan` 將其視為不可更改的硬約束，直接寫入 spec.md，不再提問。
+
+4. **EDIT 任務**：需修改已有功能 → 建立 `EDIT-xxx`（`tag: Edit`），goal 注明修改範圍；僅增量追加模式下使用。
+
+5. **Slug 命名**：`slug` 即 `tasks/<slug>/` 資料夾名，須清晰表達任務內容，格式為 `Pascal_Snake_Case`（如 `Typing_Engine_Core`）。每個任務對應唯一一個 task 子目錄，禁重名。
+
+---
+
+## Task JSON Schema（Tier 1 嚴格，禁增刪欄位）
+
+```json
+{
+  "id": "FEAT-01",
+  "title": "Task Title In English",
+  "status": "pending | blocked",
+  "description": "<1-2 句說明這個任務要建置什麼、涵蓋哪些範圍。Core 任務須在末尾聲明主要導出介面>",
+  "goal": "完成後，使用者可 <可驗證的使用者行為>；邊界：<明確不做的事>",
+  "deps": ["INF-01"],
+  "tag": "Infra | Core | Feature | Edit",
+  "slug": "Task_Title_Snake_Case"
+}
+```
+
+`deps` 為空或全部 `done` → `pending`；有未完成 deps → `blocked`
+
+---
+
+## 中間產物
+
+> 此 Skill 為子程序：產出結構化資料後，控制權交還呼叫方。
+> - `/archi.scope` → 呼叫方展示給使用者確認，OK 後寫入 `roadmap.json`
+> - `/archi.start` → 呼叫方直接寫入 `roadmap.json`
+
+產出三部分資料：
+
+**① 任務資料**（直接對應 `roadmap.json` 的 phases/tasks 結構）：
+
+```json
+{
+  "phases": [
+    {
+      "id": "phase-1",
+      "name": "Infrastructure",
+      "tasks": [
+        { "id": "INF-01", "title": "...", "status": "pending", "description": "...", "goal": "...", "deps": [], "tag": "Infra", "slug": "..." }
+      ]
+    },
+    {
+      "id": "phase-2",
+      "name": "Core Features",
+      "tasks": [
+        { "id": "FEAT-01", "title": "...", "status": "blocked", "description": "...", "goal": "...", "deps": ["INF-01"], "tag": "Feature", "slug": "..." }
+      ]
+    }
+  ]
+}
+```
+
+**② NFR 歸併清單**（須隨任務資料一併返回給呼叫方；呼叫方寫入 roadmap 時追加為 `nfr` 頂層欄位；`/archi.plan` 的 `step_1_load` 須讀取此清單）：
+
+| NFR 名稱 | 注入任務 ID | 約束內容摘要 | 影響範圍（其他相關任務 ID）|
+|:---|:---|:---|:---|
+| （範例）i18n | FEAT-01 | 所有文案須透過 i18n key 引用，禁硬編碼字串 | FEAT-02, FEAT-03 |
+
+**③ 並行執行批次**（DAG 拓撲層次圖，同一 Layer 內任務可交給不同 AI 會話並行處理）：
+
+```
+Layer 0 ║ INF-01
+Layer 1 ║ INF-02 · INF-03              ← 均依賴 INF-01
+Layer 2 ║ FEAT-01 · FEAT-02            ← 各自依賴 INF-02 / INF-03
+Layer 3 ║ FEAT-03                      ← 依賴 FEAT-01
+```

package/dist/templates/zh-Hant/skills/archi-interview-protocol/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: archi-interview-protocol
+description: Architext 補充訪談協議。規範資訊缺口的提問方式：選擇題優先、AI 推薦 + [推薦] 標註、[Z] 自訂兜底、AI+/AI- 完整分析、選項說明描述具體行為。產出標準 Q-table 和 INPUT 提示行，供 /archi.start、/archi.scope、/archi.plan 的補充確認步驟引用。
+---
+
+# 補充訪談協議
+
+## 系統流程定位
+
+```
+資訊缺口出現
+    ↓
+[本 Skill] → Q-table 輸出 → 等待使用者 INPUT
+                                    ↓
+                            調用方繼續後續步驟
+```
+
+> **Skill 的職責邊界**：
+> - 負責：問題如何提（格式/規則/語氣）
+> - 不負責：問什麼內容（由調用方的缺口列表決定）、使用者回答後如何處理（由調用方決定）
+
+## 調用方與觸發條件
+
+| 調用方 | 觸發步驟 | 觸發條件 | 問題數上限 |
+|:---|:---|:---|:---|
+| `/archi.start` | step_2_supplementary | Brief 有「必須/可補」級缺口 | 3-6 題 |
+| `/archi.scope` | step_2_5_supplementary | Brief 有「必須/可補」級缺口 | ≤3 題 |
+| `/archi.plan` | step_2 Part 2 Q-table | 架構維度 2+ 合理選項且選擇顯著影響實現 | 按需，能推薦就不展開 |
+
+---
+
+## 核心規則
+
+### 原則：選擇題優先
+
+禁開放式提問（如「你想用什麼資料庫？」）。所有問題以選擇題形式呈現，AI 基於上下文給出推薦預設選項，使用者只需確認或換選。目標：使用者不需要專業知識也能做出合理決策。
+
+### 規則清單
+
+| # | 規則 | 細節 |
+|:---|:---|:---|
+| 1 | **僅問缺口** | 調用方已明確回答的內容禁再提問；Brief 中使用者已填寫的選擇直接採納 |
+| 2 | **選項數量** | 每題 3-5 個選項 + `[Z] 自訂`；選項過多說明問題需要拆分 |
+| 3 | **推薦標註** | AI 從選項中選出最合理方案，標註 `[推薦]`；須結合當前專案上下文，禁機械套用 |
+| 4 | **[Z] 兜底** | 每題必含 `[Z] 自訂 (請描述)`，給無法用預設選項表達的需求留出口 |
+| 5 | **選項說明完整** | 說明須包含：① 這個選項是什麼 ② 選了之後專案/程式碼會怎樣 ③ 適合什麼場景（共 2-3 句）；禁一詞概括 |
+| 6 | **AI+/AI- 完整句子** | 從 AI Agent 執行視角說明優勢和風險；須為完整句子；禁寫「無」——每個方案必有取捨 |
+| 7 | **合併相關問題** | 強相關的缺口合併為一題，減少使用者決策次數；弱相關才拆題 |
+
+---
+
+## 標準輸出格式
+
+```
+### 補充確認
+
+**[Q<n>] 問題標題**
+> 為什麼需要這個資訊（一句話，讓使用者理解作答的必要性）
+
+| ID | 選項 | 說明 | AI+ | AI- |
+|:---|:---|:---|:---|:---|
+| A [推薦] | 選項名 | 是什麼 + 選了會怎樣 + 適合什麼場景（2-3 句） | 完整句子 | 完整句子 |
+| B | ... | ... | ... | ... |
+| C | ... | ... | ... | ... |
+| Z | 自訂 | (請描述) | - | - |
+
+（多題時重複上方 Q-table 結構）
+
+---
+**INPUT**: `Q1答案 | Q2答案 | ...`（題與題用 `|` 分隔；單題多選用空格，如 `A B`）
+```
+
+---
+
+## 常見錯誤示例
+
+| 錯誤寫法 | 問題 | 正確寫法 |
+|:---|:---|:---|
+| `A \| PostgreSQL` | 一詞概括，無法判斷選哪個 | `A \| PostgreSQL \| 關聯式資料庫，適合有明確 Schema 和關聯查詢的場景...` |
+| `AI+: 效能好` | 不是完整句子，無實質資訊 | `AI+: 結構化 Schema 讓 AI 直接從型別定義推斷 CRUD 程式碼，減少猜測` |
+| `AI-: 無` | 每個方案必有取捨，「無」即逃避 | `AI-: 遷移腳本須隨 Schema 演化同步維護，AI 容易遺漏欄位變更` |
+| Q 裡問 Brief 已回答的技術堆疊 | 重複提問降低信任感 | 跳過，直接採納使用者已填寫的選擇 |
+
+---
+
+> **中間產物**：此 Skill 為子程序，產出 Q-table 後控制權交還調用方，等待使用者 INPUT 回覆後調用方繼續執行。