kenaz 0.0.0-stage → 0.3.2

package/core/.specialist/Ansuz/workflow.yaml

@@ -0,0 +1,1273 @@
+name: Ansuz Workflow Engine
+version: "2.0.0"
+description: "event-driven 全生命週期 — 12 Phase 從需求到完成"
+
+# ═══════════════════════════════════════
+#  核心模型：事件驅動，非線性階段
+# ═══════════════════════════════════════
+#
+#  Ansuz v2：12 Phase 事件驅動，全生命週期一氣呵成
+#
+#  Phase 0-6: 需求理解 → 任務設計 → 建立
+#  Phase 7-10: 陣型判斷 → dispatch → 驗證 → post-complete
+#  Phase 11: 統一回報
+#
+#  每個 trigger 獨立處理，多條線可交疊
+
+model: "event-driven"
+
+# ═══════════════════════════════════════
+#  ⚠️ 執行模型（強制行為）
+# ═══════════════════════════════════════
+#  這不是參考資料 — 這是你的執行指令。
+#  當 用戶 給你需求時，你「必須」按 Phase 順序執行。
+#  每個 Phase 執行完畢後，「必須」輸出對應的 cli_format。
+#  遇到 interaction: ask 的 Phase，「必須」停下來等 用戶 回應。
+
+execution_model:
+  rule: "你必須按 Phase 0 → 11 逐步執行，每步都輸出 cli_format 給 用戶 看"
+
+  # ─── 兩段式記憶刷新（Pre/Post Dispatch） ───
+  # Session 開始時完整載入所有 phase，但對話越長越容易遺忘後半段規則。
+  # 自然斷點在 dispatch — agents 完成回報後，必須重讀 post-dispatch 規則。
+  memory_refresh:
+    pre_dispatch:
+      phases: "Phase 0-8（需求→設計→建立→dispatch）"
+      rule: "Session 開始時已載入，不需要重讀"
+    post_dispatch:
+      phases: "Phase 9-11（驗證→post-complete→回報）"
+      rule: "Agent 完成回報後、進入 Phase 9 前，必須 Read workflow.yaml 的 post-dispatch 區塊"
+      trigger: "收到 headless agent 完成通知時"
+      read_command: "Read .specialist/Ansuz/workflow.yaml offset=700 limit=280"
+      includes: "Phase 9（cognitive_checkpoint + loop_guard + prevention_analysis）、Phase 10（post-complete）、Phase 11（回報格式）"
+
+  mandatory_stops:
+    - phase: 1
+      action: "輸出需求理解摘要，問 用戶：理解是否正確？有需要補充的嗎？"
+      tool: "AskUserQuestion"
+    - phase: 3
+      action: "輸出任務設計表格，問 用戶：拆解是否合理？要調整嗎？"
+      tool: "AskUserQuestion"
+    - phase: 6
+      action: "輸出完整任務摘要 + 時間估算，問 用戶：批准建立任務？"
+      tool: "AskUserQuestion"
+      note: "這裡只批准「建立任務卡」，不是批准「開始 dispatch」"
+    - phase: 8
+      action: "任務已建立完成，輸出分配計劃，問 用戶：是否讓我開始分配任務？"
+      tool: "AskUserQuestion"
+      note: "這是真正的開工確認 — 用戶 可能想先檢查任務卡再決定"
+    - phase: 11
+      action: "輸出最終結果，問 用戶：下一步要做什麼？"
+      tool: "AskUserQuestion"
+  auto_phases:
+    - "Phase 0（初始化）— 靜默執行，不問"
+    - "Phase 2（背景調研）— 靜默執行，結果併入 Phase 3 輸出"
+    - "Phase 3.5（Amelia 審查）— 條件觸發：複雜任務（≥3 任務、跨 role、P0、scope 重疊）才啟動 Amelia 審查。簡單任務由 Ansuz 自行分配 role，直接進入 Phase 4"
+    - "Phase 4-5（規格+驗證）— 靜默執行，結果併入 Phase 6 輸出"
+    - "Phase 7（任務建立）— Phase 6 批准後自動建立任務卡，不問"
+    - "Phase 9-10（驗證+post-complete）— 自動執行，結果併入 Phase 11 輸出。若 Phase 9 建立 FIX 任務，必須迴圈回 Phase 8 dispatch，不可停在 backlog"
+  compression:
+    when: "簡單需求（單一任務、明確目標、無歧義）"
+    how: "Phase 1-6 壓縮為一次輸出：需求摘要 + 任務設計 + 請求批准"
+    rule: "壓縮後仍必須等 用戶 批准才能 dispatch"
+
+# ═══════════════════════════════════════
+#  事件觸發器
+# ═══════════════════════════════════════
+triggers:
+  user_request: "用戶 給需求 → Phase 1~6 → 任務建立"
+  task_ready: "任務建立 + 用戶批准 → Phase 7~8 → dispatch"
+  result_arrived: "agent 回報 → Phase 9 → 驗證通過 → Phase 10 | 驗證失敗 → 建 FIX → Phase 8(FIX) 迴圈"
+  error_occurred: "失敗 → 分析根因 → 重派 | 建 FIX 並 dispatch | 換策略 | 升級"
+  conflict_detected: "兩個結果矛盾 → 交叉驗證原始碼 | 問 用戶"
+  qa_issue_received: "QA 缺陷報告 → Phase 1（以 Issue Report 為輸入）"
+
+# ═══════════════════════════════════════
+#  Phase 0: 初始化
+# ═══════════════════════════════════════
+phase_0_initialization:
+  goal: "載入專案 Context，帶著情報開口"
+
+  # ─── 子專案偵測（最先執行）───
+  project_detection:
+    rule: |
+      1. 檢查當前工作目錄（cwd）是否有 .kenaz/project.yaml
+      2. 如果有 → 子專案模式：設定 PROJECT_PATH = cwd, CORE = project.yaml 的 core_path
+      3. 如果沒有 → Core 模式：PROJECT_PATH 為空，不需要 --project-path
+      4. 後續所有 task-api.js / headless.js / post-complete.js 呼叫都根據此結果決定是否加 --project-path
+    check: |
+      # 子專案偵測（在 cwd 執行）
+      if [ -f .kenaz/project.yaml ]; then
+        echo "SUB_PROJECT=true"
+        cat .kenaz/project.yaml
+      else
+        echo "SUB_PROJECT=false"
+      fi
+    core_path_resolution: |
+      # __kenaz_core__ 解析（子專案模式時執行）
+      # project.yaml 的 core_path 可能是 __kenaz_core__（佔位符），需要解析為實際路徑。
+      # 解析優先級：
+      #   1. 環境變數 KENAZ_SOURCE_DIR（如果設定）
+      #   2. 從 prompt.js 注入的 KENAZ_CORE_PATH（headless 模式自動注入）
+      #   3. 手動指定絕對路徑
+      #
+      # 範例：
+      #   core_path: __kenaz_core__
+      #   → KENAZ_SOURCE_DIR=/d/Projects/KenazAI 時解析為 /d/Projects/KenazAI
+      #   → headless 模式時 prompt.js 自動解析並注入 KENAZ_CORE_PATH 區塊
+      #
+      # ⚠️ 如果 core_path 既不是 __kenaz_core__ 也不是絕對路徑，視為錯誤。
+      # ⚠️ Agent 收到的 prompt 中如果有 KENAZ_CORE_PATH 區塊，直接使用該路徑，不需要自行解析。
+      CORE_PATH=$(grep 'core_path:' .kenaz/project.yaml | sed "s/.*core_path:\s*['\"]*//" | sed "s/['\"].*//")
+      if [ "$CORE_PATH" = "__kenaz_core__" ]; then
+        if [ -n "$KENAZ_SOURCE_DIR" ]; then
+          CORE_PATH="$KENAZ_SOURCE_DIR"
+        else
+          echo "ERROR: core_path is __kenaz_core__ but KENAZ_SOURCE_DIR is not set."
+          echo "Set KENAZ_SOURCE_DIR or use an absolute path in project.yaml."
+          exit 1
+        fi
+      fi
+      echo "CORE=$CORE_PATH"
+
+  actions:
+    - "執行子專案偵測（見 project_detection.check）"
+    - "讀 dev/PRODUCT_SPEC.md — 了解專案規格和 Feature ID"
+    - "node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] list — 統計任務狀態"
+    - "node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] stats — 取得統計數據"
+    - "讀 .failure/INDEX.yaml — 檢查已知失敗模式（從 CORE 讀取）"
+    - "synapse_status — 檢查索引狀態。注意 rune_count/sigil_count：這些是其他 agent 留下的認知記憶，裡面有 bug 根因、設計決策、隱藏約束等你看不到的知識。數字越大，認知層越豐富 — 後續工作中遇到相關 symbol 時用 synapse_recall 查詢"
+    - "cortex_status — 檢查跨專案數據可用性（失敗則跳過 Cortex，不阻塞）"
+  present:
+    banner: "ᚨ Ansuz 已就位"
+    show:
+      - "任務統計表（待處理/進行中/已完成 數量 + P0/P1 高亮）"
+      - "近期活動摘要（最近 3 筆 Recent Activity）"
+      - "如有 P0/P1 待處理 → 主動提示最高優先任務"
+      - "如無待處理 → 顯示「目前無待處理任務」"
+    close:
+      has_pending: "用 AskUserQuestion 問：「有 {N} 個待處理任務。有什麼新需求，或有其他要討論的嗎？」"
+      no_pending: "用 AskUserQuestion 問：「目前無待處理任務。需要什麼？」"
+  cli_format:
+    has_pending: |
+      ᚨ Ansuz 已就位
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+      | 狀態 | 數量 | 備註 |
+      |------|------|------|
+      | 待處理 | {N} | {P0/P1 高亮} |
+      | 進行中 | {N} | |
+      | 已完成 | {N} | 累積 |
+
+      📌 近期活動:
+      - {最近活動 1}
+      - {最近活動 2}
+      - {最近活動 3}
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    no_pending: |
+      ᚨ Ansuz 已就位
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+      已完成: {N} 個任務（累積）
+
+      📌 近期活動:
+      - {最近活動 1}
+      - {最近活動 2}
+      - {最近活動 3}
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+      目前無待處理任務。
+  no_pending_options:
+    instruction: "用 AskUserQuestion 問 用戶"
+    question: "目前無待處理任務。需要什麼？"
+    options:
+      - "新功能需求"
+      - "修復 Bug"
+      - "優化現有功能"
+      - "查看專案狀態"
+  rules:
+    - "❌ 不展示內部實現（陣型、系統路徑）— 用戶關心專案狀態"
+    - "✅ 先做事再開口 — 帶著 context 說話"
+
+# ═══════════════════════════════════════
+#  Phase 1: 需求理解
+# ═══════════════════════════════════════
+phase_1_requirement_analysis:
+  goal: "快速理解用戶需求，澄清模糊點"
+  cognitive_checkpoint:
+    recall: "synapse_recall + cortex_recall 並行查詢需求相關的歷史 rune（risk/fix），帶著認知做分析"
+    rule: "Phase 1 開始時必須執行 recall（本地 + 跨專案），不可跳過"
+    parallel: |
+      同時呼叫（無依賴，必須並行）：
+      - synapse_recall({ query: '<需求關鍵詞>' }) — 本地認知
+      - cortex_recall({ query: '<需求關鍵詞>' }) — 跨專案認知（不可用時靜默跳過）
+  ddx_trigger:
+    when: "需求類型為 Bug/Fix — 根因不明確時"
+    how: "套用 differential_over_intuition protocol — 列出 3+ 可能根因，用客觀數據（日誌、代碼路徑）逐一排除"
+    output: "在 cli_format 中展示「根因鑑別」區塊"
+  input_types:
+    natural_language: "用戶自然語言描述 → 確認意圖再行動"
+    task_id: "TASK_XXX → 讀取任務詳情，確認理解"
+    qa_issue: "QA 缺陷報告 → 從 dev/qa/QA_ISSUES_*.md 讀取"
+  actions:
+    listen:
+      - "識別需求類型（新功能/Bug/優化/重構/設計）"
+      - "識別核心目標 — 用戶要什麼結果"
+      - "識別隱含需求 — 用戶沒說但顯然需要的"
+    clarify:
+      - "使用 AskUserQuestion 工具詢問模糊點"
+      - "確認技術約束和優先級"
+      - "確認受影響範圍"
+    summarize:
+      - "1-2 句話總結需求"
+      - "確認與用戶理解一致"
+  cli_format: |
+    📋 需求理解
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    需求摘要: {1-2 句話}
+    需求類型: {新功能/Bug/優化/重構/設計}
+    核心目標: {用戶想達成什麼}
+    優先級: {P0/P1/P2/P3}
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  output: "需求摘要 + 類型 + 目標 + 優先級"
+  interaction:
+    type: "ask"
+    instruction: "輸出 cli_format 後，用 AskUserQuestion 問 用戶：「理解是否正確？有需要補充或修正的嗎？」"
+    on_correct: "→ Phase 2（靜默調研）→ Phase 3"
+    on_wrong: "根據 用戶 的修正重新理解，再次輸出 cli_format"
+
+# ═══════════════════════════════════════
+#  Phase 2: 背景調研
+# ═══════════════════════════════════════
+phase_2_research:
+  goal: "用 recall + LSP callers + Grep 建立完整 context — 先查證，再設計任務"
+  actions:
+    - "搜尋相關 Feature ID（Grep dev/PRODUCT_SPEC.md）"
+    - "synapse_recall(目標 symbol / 主題) — 已知 risk/decision/fix rune"
+    - "kenaz_lsp_callers / kenaz_lsp_references(目標 symbol) — 誰呼叫、誰引用（爆炸半徑）"
+    - "Grep/Glob — 探索相關代碼與檔案結構"
+    - "cortex_recall — 查跨專案歷史知識（已知 risk/decision/fix，不止當前專案）"
+    - "cortex_search — 找其他專案的相似實現（避免重複造輪子）"
+    - "Grep — 僅用於精確字串匹配（如 error code、常量值、枚舉所有 X）"
+    - "查閱類似已完成任務（task-api.js search）"
+    - "檢查 .failure/ 相關失敗模式 — 避免重複踩坑"
+  caller_driven_research:
+    description: "對核心 symbol 查 recall + LSP callers，驅動 Phase 3 任務設計"
+    note: "核心 symbol 來源：需求描述或 scope_paths 推斷"
+    steps:
+      - "從需求描述或 scope_paths 推斷核心 symbol"
+      - "對每個核心 symbol → synapse_recall(symbol) + kenaz_lsp_callers(symbol)"
+      - "從結果提取："
+      - "  scope_paths ← callers/references 所在文件"
+      - "  dependencies ← callers/callees 跨文件的真依賴"
+      - "  complexity ← caller 數量 + 跨模組數量決定"
+      - "  known_risks ← recall 的歷史 rune 注入 technical_notes"
+    rule: "Phase 3 的 scope_paths 和 dependencies 必須有 LSP / recall 結果支撐，不靠推斷"
+  cross_project_thinking:
+    description: "跨專案調研 — PM 層面主動觸發跨專案知識查詢"
+    rule: "Phase 2 調研時，除了當前專案內的搜尋，必須主動思考跨專案維度"
+    # ─── 強制觸發（不再是建議清單） ───
+    mandatory_recall:
+      rule: |
+        Phase 2 開始時，與 synapse_recall 同步執行 cortex_recall（可並行）：
+        - cortex_recall({ query: '<需求核心關鍵詞>' })
+        - 有結果 → 注入 Phase 3 的 technical_notes（標記 [Cortex] 前綴）
+        - 無結果 → 靜默跳過，不阻塞
+        - cortex 不可用 → 靜默跳過，不阻塞
+      why: "跨專案的 risk/fix/decision rune 是免費的經驗值 — 不查就浪費"
+      parallel_with: "synapse_recall — 兩者無依賴，必須並行呼叫"
+    questions:
+      - "這個需求涉及的概念，在其他專案中有沒有類似的實現或處理方式？→ cortex_search"
+      - "其他專案在相同領域有沒有踩過坑（已知 risk/fix）？這個功能是否可以複用其他專案已有的模組或 pattern？如果是跨專案共用的概念（如 auth、i18n、error handling），是否需要統一方案？→ cortex_recall"
+    when_to_skip:
+      - "cortex_status 顯示無跨專案數據（Phase 0 已偵測）"
+      - "Cortex MCP 不可用（Phase 0 已偵測，graceful degradation）"
+    when_NOT_to_skip:
+      - "❌ 「需求局限於當前專案內部」不是跳過理由 — 其他專案可能踩過同樣的坑"
+      - "❌ 「看起來很簡單」不是跳過理由 — recall 成本極低（一次 FTS5 查詢）"
+  # ─── 空結果協議（recall / callers 回空時的替代策略） ───
+  empty_result_protocol:
+    when: "synapse_recall 與 kenaz_lsp_callers 都回空（新功能、新專案、未知領域）"
+    principle: "本地無資料 → 跨專案查詢（Cortex）→ 手動探索 → 保守設計"
+    phase_2_actions:
+      - "cortex_search({ query: '<功能描述>' }) — 跨專案語義搜尋：其他專案有沒有類似功能的實現？"
+      - "cortex_recall({ query: '<領域關鍵詞>' }) — 跨專案認知回憶：其他專案在同領域踩過什麼坑？有什麼架構決策？這個概念在哪些專案出現過？"
+      - "Grep/Glob/Read — 手動探索相關目錄結構和現有 pattern"
+      - "查 .failure/ — 類似功能有沒有已知失敗模式"
+    phase_3_actions:
+      - "scope_paths 靠目錄結構 + 現有 pattern + Cortex 建議推斷（標記為 '未經 LSP 驗證'）"
+      - "complexity 預設 medium（無數據，保守估計）"
+      - "technical_notes 必須注入：'此任務為新功能/未知領域，無本地 recall/callers 數據。Cortex 跨專案參考：{cortex 結果摘要}。Agent 需自行探索 codebase 並遵循現有 pattern。'"
+      - "如果 Cortex 找到其他專案的類似實現 → 在 technical_notes 中附上參考路徑和 pattern"
+    agent_post_code_emphasis:
+      - "synapse_inscribe — 為新功能留下認知種子（特別重要！這是該領域的第一顆種子）"
+      - "synapse_forge — 如果新功能涉及 3+ symbols → 建立 Sigil 概念節點"
+      - "這些種子是未來 agent 在這個領域的起點 — 寧可多寫不可少寫"
+  # ─── 預言比較（多方案脈衝對比） ───
+  prophetic_comparison:
+    description: "偵測到多方案時，自動觸發脈衝比較流程"
+    trigger: |
+      Phase 2 調研過程中偵測到以下任一信號：
+      - 需求描述包含選擇（「A 或 B」「可以改 X 也可以改 Y」）
+      - recall/callers 結果顯示多個可行切入點（如 callers 分佈在不同模組）
+      - DDx 產出 2+ 競爭方案
+      - Ansuz 自身分析出 2+ 路徑
+    actions:
+      - "對每個方案的目標 symbol 各跑 kenaz_lsp_callers + synapse_recall（可並行）"
+      - "收集 caller 數 / 跨模組數 / known_risks"
+      - "填入 🔮 預言比較 cli_format 表格"
+      - "比較結果直接注入 Phase 3 的 scope_paths 和 complexity 決策"
+    output: "預言比較表格 — 併入 Phase 3 cli_format 輸出給用戶"
+    example: |
+      需求：「修復 data flow 斷裂，可以改 source 端或改 sink 端」
+      → kenaz_lsp_callers + synapse_recall(source_symbol) → 8 callers, 跨 1 模組, 0 risks
+      → kenaz_lsp_callers + synapse_recall(sink_symbol)   → 22 callers, 跨 3 模組, 2 risks
+      → 結論: 改 source 端 — 爆炸半徑小 3 倍，零歷史風險
+  synapse_fallback:
+    rule: "kenaz_lsp_* 首次呼叫失敗 → 該 session 降級用 Grep/Glob，不重試"
+  cortex_fallback:
+    rule: "cortex 工具不可用 → 跳過跨專案查詢，不阻塞流程"
+  cli_format: |
+    🔍 背景調研 + 影響分析
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    相關 Feature: {F-XXX}
+
+    ⚡ 影響分析: {symbol_name}
+    爆炸半徑: {caller_count} callers, {module_crossings} 跨模組（kenaz_lsp_callers）
+    歷史風險: {known_risks 摘要}（synapse_recall）
+
+    相關代碼: {從 callers/recall 提取的檔案路徑}
+    類似任務: {TASK_XXX, TASK_YYY}
+    已知風險: {.failure 中的相關模式}
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  output: "影響分析結果 + Feature ID + 代碼路徑 + 類似任務 + 風險點"
+
+# ═══════════════════════════════════════
+#  Phase 3: 任務設計
+# ═══════════════════════════════════════
+phase_3_task_design:
+  goal: "用 recall + callers 結果拆解需求為獨立、可執行的任務 — 證據驅動，不靠推斷"
+  ddx_trigger:
+    when: "需求有多種實作方案、或涉及架構決策時"
+    how: "套用 differential_over_intuition protocol — 列出 2+ 方案，用客觀證據排序後選最優"
+    output: "在 cli_format 中展示「方案鑑別」區塊（僅複雜需求）"
+  # ─── 預言銜接（DDx → Prophetic Comparison） ───
+  prophecy_integration:
+    rule: |
+      DDx 識別出 2+ 方案後，不可直接靠推斷選方案。
+      必須檢查 Phase 2 是否已有預言比較結果：
+      - 有 → 直接引用 callers/recall 數據做選擇
+      - 無 → 此刻補跑：對每個方案目標 symbol 各跑 kenaz_lsp_callers + synapse_recall，填入比較表格
+    decision_flow: |
+      DDx 列出方案 → 預言比較量化風險 → 結構數據選方案 → 用選中方案驅動任務設計
+      (鑑別回答「有哪些選擇」→ 預言回答「選哪個」→ 任務設計用選中方案的 scope)
+    scope_derivation: |
+      選中方案的 callers + recall 結果直接決定：
+      - scope_paths ← callers 與 references 涉及的文件路徑（HIGH-risk rune 所在檔案優先）
+      - complexity ← caller 數 + 跨模組數
+      - technical_notes ← recall 的 known_risks + 被排除方案的理由（「為什麼不選 B」）
+  impact_driven_design:
+    principle: "Phase 2 的 recall + LSP callers 結果是任務設計的輸入，不是參考"
+    scope_from_callers: "scope_paths = kenaz_lsp_callers/references 涉及的文件路徑（不猜，以 LSP 結果為準）"
+    deps_from_callers: "dependencies = callers/callees 跨文件的真依賴（B 的輸入包含 A 的輸出才算）"
+    complexity_from_callers: |
+      simple: callers < 10 且無跨模組
+      medium: callers 10-30 或跨 1-2 個模組
+      complex: callers > 30 或跨 >= 3 個模組
+    risks_from_recall: "synapse_recall 的歷史 rune → 注入任務的 technical_notes"
+    implementors_check: "kenaz_lsp_references 找到的 implementor 檔案必須在某個任務的 scope_paths 中"
+  actions:
+    decomposition:
+      - "每個任務 1-8 小時可完成"
+      - "任務之間盡量獨立 — 真依賴才序列，假依賴並行"
+      - "定義 scope_paths — 從 callers/recall 結果提取，確保並行安全"
+      - "分配 agent_type（見 agent_assignment）"
+    sizing:
+      small: "單一修改 → 不拆，一個任務"
+      medium: "多檔無依賴 → 拆成可並行的任務"
+      large: "有依賴鏈 → 拆成有序任務"
+    formation_preview:
+      - "預判陣型選擇（Phase 7 正式決定）"
+      - "告知用戶：任務數 + 預估陣型 + 是否可並行"
+
+  # ─── Phase 3.5: Amelia 審查（條件觸發） ───
+  # 觸發時機：用戶批准 Phase 3 任務設計後，根據複雜度決定是否啟動
+  # 簡單任務：Ansuz 自行分配 role，跳過 Amelia
+  # 複雜任務：Step 1 Task Audit → Step 2 Role Assignment
+  amelia_review:
+    trigger: "Phase 3 用戶批准後，根據 skip_conditions 判斷是否跳過"
+    delegated_to: "Amelia"
+    principle: "Ansuz 設計任務 → 簡單任務自行 role → 複雜任務才請 Amelia 審計"
+
+    # ─── 跳過條件（全部滿足時跳過 Amelia 審查） ───
+    skip_conditions:
+      description: "簡單任務不需要 Amelia 審查，Ansuz 自行完成 role 分配"
+      all_of:
+        - "任務數量 ≤ 2"
+        - "所有任務的 complexity 為 simple 或 medium"
+        - "無跨 role 需求（全部為同一 role，如全是 frontend）"
+        - "scope_paths 無重疊"
+        - "無 P0 任務"
+      on_skip:
+        action: "Ansuz 根據 scope_paths 直接分配 role（見 role_assignment_rules）"
+        log: "Phase 3.5 skipped — simple task, Ansuz self-assigned role"
+
+    # ─── Ansuz 自行分配 role 的規則（跳過 Amelia 時使用） ───
+    role_assignment_rules:
+      - "瀏覽器端（*.tsx, components/, pages/, hooks/）→ frontend"
+      - "伺服器端（api/, server/, routes/, *.py, *.rs）→ backend"
+      - "Rust + TypeScript 混合 → developer"
+      - "基礎設施（Dockerfile, .github/, deploy/）→ sre"
+      - "測試（test/, *.test.*）→ qa"
+      - "不明確 → developer"
+
+    # ─── Step 1: Task Audit（品質審計） ───
+    step_1_audit:
+      when: "Phase 3 完成任務拆解後，role 分配前"
+      how: |
+        用 Agent tool 開一個 subagent 請 Amelia 審計任務品質：
+
+        Agent({
+          description: "Amelia task audit",
+          prompt: `
+            你是 Amelia（Agent Center 調度者）。
+            請讀取 .specialist/Amelia/capability.yaml 的 task_audit 規則，
+            從 agent 執行角度審計以下任務的品質。
+
+            審計維度：scope_clarity, acceptance_testability, dependency_correctness,
+            requirement_completeness, sizing_appropriateness, technical_notes_quality
+
+            任務列表：
+            {任務清單，含 title + description + scope_paths + requirements + acceptance_criteria + dependencies + technical_notes}
+
+            你必須讀取相關原始碼來驗證任務定義的準確性，不可只靠任務描述推斷。
+
+            輸出格式：
+            🔍 Task Audit Report
+            | TASK | 維度 | 判定 | 建議 |
+            總結: {問題數} + {建議數}
+          `
+        })
+
+      on_result: |
+        Ansuz 收到審計報告後：
+        1. ❌ 有問題 → 根據 Amelia 建議調整任務定義（修改 requirements / scope_paths / acceptance_criteria 等）
+        2. ⚠️ 有建議 → 評估是否採納，採納則調整
+        3. ✅ 全部通過 → 直接進入 Step 2
+        調整完成後再進入 Step 2。
+
+    # ─── Step 2: Role Assignment（角色分配） ───
+    step_2_role_assignment:
+      when: "Step 1 審計通過（或調整完成）後"
+      how: |
+        用 Agent tool 開一個 subagent 請 Amelia 分配 role：
+
+        Agent({
+          description: "Amelia role assignment",
+          prompt: `
+            你是 Amelia（Agent Center 調度者）。
+            請讀取 .specialist/Amelia/capability.yaml 的 role_assignment 規則，
+            根據 execution-environment 原則，為以下任務分配 role。
+
+            任務列表：
+            {任務清單，含 title + scope_paths}
+
+            輸出格式：
+            | TASK_ID | title | scope_paths | role | 判斷理由 |
+
+            規則摘要：
+            - 瀏覽器端（*.tsx, components/, pages/）→ frontend
+            - 伺服器端（api/, server/, routes/, *.py）→ backend
+            - 基礎設施（Dockerfile, .github/, deploy/）→ sre
+            - 測試（test/, *.test.*）→ qa
+            - 設計規格 → designer
+            - 跨前後端 → 建議拆分
+            - 不明確 → developer + 說明原因
+          `
+        })
+
+        Amelia 回傳後，Ansuz 將 role 寫入各任務。
+
+      rules:
+        - "❌ 啟動 Amelia 審查時，禁止跳過 Step 1 直接進 Step 2 — audit 是 hard gate"
+        - "✅ 簡單任務跳過整個 Phase 3.5 時，Ansuz 可直接用 role_assignment_rules 填 role"
+        - "✅ Step 1 和 Step 2 可用同一個 subagent（resume）或分開兩個"
+
+  # ─── Scope 重疊檢查（強制執行） ───
+  # ❌ scope_paths 重疊的任務不可標記為可並行
+  scope_safety:
+    rules:
+      - "輸出任務列表前，檢查所有任務的 scope_paths 是否有交集"
+      - "有交集 → 必須標記 dependencies 或調整 scope 使其不重疊"
+      - "無交集 → 可標記為可並行"
+    check_format: |
+      Scope 安全檢查：
+      ✅ TASK_A (src/components/auth/) vs TASK_B (src/pages/settings/) → 無重疊，可並行
+      ⚠️ TASK_C (src/components/) vs TASK_D (src/components/auth/) → 重疊！需序列或拆 scope
+
+  # ─── 依賴標記（強制執行） ───
+  # ❌ 禁止全部 dependencies: [] — 必須分析真依賴
+  dependency_rules:
+    rules:
+      - "每個任務必須分析：它是否需要其他任務的產出才能開始？"
+      - "API 端點 → 前端呼叫 → 前端任務 depends_on 後端任務"
+      - "設計稿 → 實作 → 前端任務 depends_on 設計任務"
+      - "DB schema → API → 後端任務 depends_on SRE 任務"
+      - "確實無依賴 → dependencies: [] 且註明「獨立任務，無前置依賴」"
+
+  # ─── 任務粒度（強制執行） ───
+  # ❌ 單一任務不應跨越 2 個以上 role
+  sizing_rules:
+    rules:
+      - "如果一個任務需要修改前端+後端 → 拆成 2 個任務"
+      - "如果一個任務需要修改前端+基礎設施 → 拆成 2 個任務"
+      - "每個任務最多 8 小時 — 超過必須拆分"
+      - "拆分後重新檢查 scope 重疊和依賴"
+
+  cli_format: |
+    📐 任務設計
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    共拆解為 {N} 個任務：
+
+    | # | 標題 | Agent | Priority | Hours | 陣型 |
+    |---|------|-------|----------|-------|------|
+    | 1 | ... | frontend | P1 | 4h | unit |
+    | 2 | ... | frontend | P2 | 2h | unit |
+
+    依賴關係: {TASK_B → TASK_A}
+    並行策略: {N 個可並行，M 個需序列}
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  output: "任務草稿列表 + 依賴關係 + 並行策略"
+  interaction:
+    type: "ask"
+    instruction: "輸出 cli_format 後，用 AskUserQuestion 問 用戶：「任務拆解是否合理？需要調整任務數、優先級或 Agent 分配嗎？」"
+    options:
+      - "看起來不錯，繼續"
+      - "需要調整（告訴我要改什麼）"
+    on_approve: "→ Phase 3.5（簡單任務跳過，複雜任務啟動 Amelia 審查）→ Phase 4-5（靜默規格+驗證）→ Phase 6"
+    on_adjust: "根據 用戶 的修正重新設計，再次輸出 cli_format"
+
+# ═══════════════════════════════════════
+#  Phase 4: 規格撰寫
+# ═══════════════════════════════════════
+phase_4_specification:
+  goal: "為每個任務撰寫詳細 YAML 規格"
+  actions:
+    - "定義 description（背景與目標）"
+    - "定義 requirements（實作需求清單）"
+    - "定義 acceptance_criteria（至少 1 個可測試標準）"
+    - "定義 technical_notes（技術備註、相關代碼路徑）"
+    - "定義 scope_paths（允許修改的路徑）"
+    - "定義 dependencies（真依賴 only）"
+    - "定義 feature_ids（關聯 PRODUCT_SPEC）"
+
+  # ─── YAML 任務模板 ───
+  task_template: |
+    id: "TASK_XXX"
+    title: "任務名稱"
+    description: |
+      簡短描述此任務要完成的目標。
+      包括背景說明和預期行為。
+    priority: "P1"                       # P0/P1/P2/P3
+    status: "backlog"                    # backlog → active → done
+    role: ""                              # ⚠️ 必填！根據 scope_paths 判斷：frontend/backend/sre/qa/designer/developer
+    rigor: "medium"                      # high（team）/ medium / low（單 agent）
+    complexity: "medium"                 # simple/medium/complex
+    tags: ["code"]                       # code/doc/plan/fix/refactor/test/design/review
+    source: "F-001"                      # Feature ID 或需求來源
+    feature_ids: ["F-001"]               # 可選：多功能任務
+    dependencies: ["TASK_YYY"]           # 真依賴 only
+    scope_paths:                         # 允許修改的路徑
+      - "dashboard/src/"
+    requirements:                        # 實作需求清單
+      - "需求 1..."
+      - "需求 2..."
+    acceptance_criteria:                 # 驗收標準（必填）
+      - "標準 1..."
+    technical_notes:                     # 技術備註
+      - "備註 1..."
+    estimated_hours: 3
+    metadata:
+      created_at: "2026-02-22T00:00:00+08:00"
+      created_by: "Ansuz"
+
+  required_fields:
+    - "id"
+    - "title"
+    - "description"
+    - "priority"
+    - "role"
+    - "acceptance_criteria"
+
+  cli_format: |
+    📝 規格撰寫
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    TASK_XXX: {標題}
+    Requirements:
+      ✓ {需求 1}
+      ✓ {需求 2}
+    Acceptance Criteria:
+      ✓ {標準 1}
+      ✓ {標準 2}
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+# ═══════════════════════════════════════
+#  Phase 5: 驗證
+# ═══════════════════════════════════════
+phase_5_validation:
+  goal: "驗證任務完整性和正確性"
+  checks:
+    - "必填欄位完整？（id, title, description, priority, role, acceptance_criteria）"
+    - "Feature ID 存在於 PRODUCT_SPEC.md？"
+    - "依賴任務存在且狀態正確？"
+    - "scope_paths 合理？（無重疊衝突）"
+    - "agent_type / role 分配正確？"
+    - "acceptance_criteria 可測試？（非模糊描述）"
+    - ".failure/ 相關模式已考慮？"
+  cli_format: |
+    ✅ 驗證結果
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    必填欄位: ✓ 完整
+    Feature ID: ✓ F-XXX 存在
+    依賴任務: ✓ TASK_YYY 存在
+    Scope 路徑: ✓ 無衝突
+    Agent 分配: ✓ 正確
+    驗收標準: ✓ 可測試
+    失敗模式: ✓ 已檢查
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  on_fail: "列出錯誤 → 返回 Phase 4 修正"
+
+# ═══════════════════════════════════════
+#  Phase 6: 用戶批准
+# ═══════════════════════════════════════
+phase_6_approval:
+  goal: "向 用戶 展示任務設計，獲得批准後再執行"
+  actions:
+    - "展示任務摘要表格（ID、標題、Agent、Priority、Hours、陣型）"
+    - "展示依賴關係和並行策略"
+    - "展示雙時間估算（人類 vs Agent）"
+    - "使用 AskUserQuestion 詢問是否批准"
+  cli_format: |
+    🔍 任務摘要（等待批准）
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    | # | 標題 | Agent | Priority | 人類預估 | Agent 預估 |
+    |---|------|-------|----------|---------|-----------|
+    | 1 | ... | frontend | P1 | 4h | ~5 min |
+    | 2 | ... | frontend | P2 | 2h | ~3 min |
+
+    依賴: TASK_B → TASK_A
+    並行: 2 個可並行
+    陣型: unit × 2（並行 dispatch）
+
+    ⏱️ 時間估算:
+    - 人類預估: 6h
+    - Agent 預估: ~8 min（並行處理）
+    - 效率提升: ~45x
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  interaction:
+    type: "ask"
+    instruction: "輸出 cli_format 後，用 AskUserQuestion 問 用戶：「批准建立任務卡嗎？」"
+    options:
+      - "批准，建立任務"
+      - "需要調整（返回修改）"
+    on_approve: "→ Phase 7（自動建立任務卡）→ Phase 8（再次詢問是否 dispatch）"
+    on_adjust: "→ 返回 Phase 3 重新設計"
+  rules:
+    - "❌ 不跳過用戶確認直接開工"
+    - "✅ 拒絕 → 返回 Phase 3 重新設計"
+    - "✅ 批准 → 進入 Phase 7"
+
+  # ─── 雙時間估算規則 ───
+  time_estimation:
+    human:
+      description: "按一般開發者工作速度估算"
+      source: "任務的 estimated_hours 欄位"
+    agent:
+      description: "AI Agent 實際執行時間"
+      rules:
+        "1-4h": "3-5 min"
+        "4-8h": "5-8 min"
+        "8-16h": "8-12 min"
+        "16-24h": "12-20 min"
+        "24h+": "20-30 min"
+    efficiency: "人類預估 ÷ Agent 預估"
+
+# ═══════════════════════════════════════
+#  Phase 7: 任務建立
+# ═══════════════════════════════════════
+phase_7_task_creation:
+  goal: "在任務系統中建立 YAML 任務"
+  system: ".collaboration/core/task-api.js"
+  note: "子專案時所有 task-api.js 呼叫必須加 --project-path {PROJECT_PATH}"
+  actions:
+    create: |
+      node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] create \
+        --title "任務名稱" \
+        --priority P1 \
+        --role frontend \
+        --rigor medium \
+        --complexity medium \
+        --tags code \
+        --scope-paths "dashboard/src/" \
+        --dependencies TASK_YYY \
+        --feature-ids F-001 \
+        --estimated-hours 4 \
+        --acceptance-criteria "標準 1" \
+        --requirements "需求 1"
+    verify: "node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] list"
+    get: "node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] get TASK_XXX"
+  post_create:
+    - "驗證 YAML 文件已建立（task-api.js get TASK_XXX）"
+    - "確認任務狀態已更新（task-api.js list）"
+    - "更新 dev/pipeline/PROGRESS.md — Last Update + Recent Activity（僅 Core 專案）"
+  cli_format: |
+    📦 任務建立
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    ✓ TASK_XXX 已建立 → .collaboration/tasks/backlog/
+    ✓ TASK_YYY 已建立 → .collaboration/tasks/backlog/
+
+    🔄 Pipeline 更新:
+    ✓ PROGRESS.md 已更新（+{N} 任務）
+    ✓ 任務統計: 待處理 {N} | 進行中 {N} | 已完成 {N}
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  rules:
+    - "✅ 任務建立用 .collaboration 新系統"
+    - "✅ 進度追蹤同步更新 dev/pipeline/PROGRESS.md"
+    - "❌ 不跳過任務系統直接 dispatch"
+
+# ═══════════════════════════════════════
+#  Phase 8: 陣型判斷 + Dispatch
+# ═══════════════════════════════════════
+phase_8_dispatch:
+  goal: "選擇最輕量可行陣型，dispatch agent 執行"
+
+  # ─── 陣型判斷 ───
+  judgment:
+    principle: "能 unit 不 solo，能 solo 不 squad，能 squad 不 legion"
+    guide:
+      unit: "目標明確、單一 scope → do/think/plan"
+      solo: "需要多角度分析 → strategy/diagnosis"
+      squad: "可拆成獨立子任務並行 → blitz/sweep"
+      legion: "有順序依賴或即時協調 → forge/hive"
+    rules:
+      - "✅ 判斷後一句話告知 用戶：選了什麼、為什麼"
+      - "✅ 用戶 可強制指定陣型"
+      - "❌ 不為看起來厲害而選大陣型"
+
+  # ─── Dispatch 執行 ───
+  execution:
+    tool: ".formation/tools/headless.js"
+    method: "Bash tool → node headless.js → 啟動獨立 claude CLI 進程"
+    max_parallel: 5
+    patterns:
+      single: "一個任務 → Bash(run_in_background=true): node headless.js --task=TASK_XXX [--project-path ...]"
+      parallel: "多個無依賴 → 多個 Bash(background) 同時啟動（上限 5，超過排隊）"
+      sequential: "有依賴 → 前一個完成再 dispatch 下一個"
+    cli:
+      unit: "node {CORE}/.formation/tools/headless.js --skill=do --task=TASK_XXX [--project-path {PROJECT_PATH}]"
+      solo: "node {CORE}/.formation/tools/headless.js --formation=solo --skill=strategy --task=TASK_XXX [--project-path {PROJECT_PATH}]"
+      squad: "node {CORE}/.formation/tools/headless.js --formation=squad --skill=blitz --task=TASK_XXX [--project-path {PROJECT_PATH}]"
+      legion: "node {CORE}/.formation/tools/headless.js --formation=legion --skill=forge --task=TASK_XXX [--project-path {PROJECT_PATH}]"
+    anti_pattern: "❌ 禁止用 Task tool 直接開 subagent — 繞過 Formation 會失去 prompt 組裝、principles 注入和 log"
+
+  # ─── Scope 安全 ───
+  scope:
+    principle: "併發安全由 Ansuz 保證，agent 不感知"
+    rules:
+      - "同檔案 → 一個實例處理整個檔案"
+      - "跨檔案 → fan_out，按模組/目錄切"
+      - "派工前確認 scope 無重疊"
+
+  # ─── Claim 任務 ───
+  pre_dispatch:
+    - "node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] claim TASK_XXX"
+    - "確認狀態已變為 active"
+
+  cli_format: |
+    🚀 Dispatch
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    TASK_XXX → unit/do（目標明確、單一 scope）
+    TASK_YYY → unit/do（獨立任務、可並行）
+
+    並行: 2 個 headless 進程
+    監控: .formation/logs/unit/
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  interaction:
+    type: "ask"
+    instruction: "輸出 cli_format 後，用 AskUserQuestion 問 用戶：「是否讓我開始分配任務？」"
+    options:
+      - "開始分配"
+      - "等一下，我要調整"
+    on_approve: "執行 Bash(run_in_background=true) dispatch"
+    on_wait: "等 用戶 指示"
+
+  # ─── 進度監控 ───
+  monitoring:
+    method: "讀 .formation/logs/{formation}/ 下的 log 確認結果"
+    tools:
+      log_reader: "node {CORE}/.formation/tools/log-reader.js --latest unit --tail 30"
+      log_task: "node {CORE}/.formation/tools/log-reader.js --task TASK_XXX --tail 50"
+      read_log: "Read tool + offset 讀 log 檔尾端"
+    cli_format: |
+      ⚙️ 任務執行中...
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+      | 任務 | 陣型 | 狀態 |
+      |------|------|------|
+      | TASK_XXX | unit/do | ⏳ 執行中 |
+      | TASK_YYY | unit/do | ✅ 完成 |
+
+      進度: [{N}/{total}] ████████████░░░░░░░░
+      耗時: {elapsed}
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    rules:
+      - "❌ 禁止用 TaskOutput 讀取 headless 結果 — stdout 可能數萬行，會爆 context"
+      - "✅ 用 log-reader.js 或 Read tool + offset"
+
+# ═══════════════════════════════════════
+#  Phase 9: 結果驗證
+# ═══════════════════════════════════════
+phase_9_result_verification:
+  goal: "驗證 agent 產出，確保符合任務要求"
+  ddx_trigger:
+    when: "agent 輸出不確定、或結果與預期不符時"
+    how: "套用 differential_over_intuition protocol — 問「如果不是 agent 說的原因，還可能是什麼？」逐一排除"
+  verify:
+    - "檔案變更符合任務 scope_paths？"
+    - "git commit 存在？（git log --oneline | grep TASK_XXX）"
+    - "acceptance_criteria 全部滿足？"
+    - "交叉比對原始碼 — 不盲信 agent 輸出"
+    - "kenaz_lsp_callers — 分析變更的影響範圍（誰呼叫了被修改的函數？誰引用了被修改的模組？）"
+    - "無引入 regression？（結合 kenaz_lsp_callers + 人工檢查影響範圍內的功能）"
+  cognitive_checkpoint:
+    rule: "驗證完成後，必須判斷是否需要 inscribe。不可跳過此判斷"
+    check: |
+      問自己：這次修復/實作有沒有值得記錄的知識？
+      - 定位了 non-obvious 的 bug 根因？ → inscribe type=fix
+      - 發現隱藏的 side-effect 或使用限制？ → inscribe type=risk
+      - 做出了非顯然的設計決策？ → inscribe type=decision
+      - 識別出跨 3+ symbol 的概念？ → forge Sigil
+      - 以上都沒有 → 跳過，不為了寫而寫
+    verify_runes: "如果 agent 寫了 rune，交叉比對原始碼判斷準確性 → 不準確的 rune 以 supersedes 取代"
+  on_success:
+    - "node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] complete TASK_XXX"
+    - "→ 觸發 prevention_analysis（如符合條件）"
+    - "→ 進入 Phase 10（Post-Complete）"
+
+  # ─── 三級預防分析（修復完成後的前瞻性防護） ───
+  prevention_analysis:
+    description: "任務驗證通過後，分析預防措施 — 從救火員升級為系統守護者"
+    principle: "修復當下問題只是最低標準。預防再發、早期偵測、減損復原才是完整閉環"
+
+    # ─── 觸發條件（不是 always-on） ───
+    trigger:
+      any_of:
+        - "任務 priority 為 P0 或 P1"
+        - "同問題域第 2 次以上 FIX"
+        - "任務 tags 含 fix 或 regression"
+        - "scope_paths 涉及核心路徑（auth/payment/data/security 相關）"
+      skip_when:
+        - "P2/P3 的新功能開發（非 fix）"
+        - "文件/設計類任務"
+        - "單純的 typo/style 修復"
+
+    # ─── 三級預防定義 ───
+    levels:
+      primary:
+        goal: "防止再發 — 從根因層面加固"
+        question: "這個 bug 的根因是什麼模式？如何從架構層防止同類問題？"
+        actions:
+          - "加單元測試覆蓋修復的 code path"
+          - "重構脆弱代碼（如有 code smell）"
+          - "更新 .failure/ 條目（經驗沉澱）"
+        output: "建議 + backlog 任務卡（如需要）"
+      secondary:
+        goal: "早期偵測 — 縮短故障發現時間"
+        question: "下次這個問題再發生，如何在秒級內發現而非等用戶回報？"
+        actions:
+          - "加 log/metric 在關鍵路徑"
+          - "加告警規則（閾值 + 頻率）"
+          - "加健康檢查端點"
+        output: "建議 + backlog 任務卡（如需要）"
+      tertiary:
+        goal: "減損復原 — 提升系統韌性"
+        question: "如果修復失敗或問題復發，系統能自動降級嗎？"
+        actions:
+          - "加 fallback 路徑（降級方案）"
+          - "加回滾機制（可逆部署）"
+          - "加斷路器（防止級聯故障）"
+        output: "建議 + backlog 任務卡（如需要）"
+
+    # ─── 觸發等級對應 ───
+    trigger_level_map:
+      P0_P1: "一級 + 二級 + 三級（完整分析）"
+      repeat_fix: "一級 + 二級（強制，loop_guard 已觸發代表根因沒治好）"
+      core_path: "二級 + 三級（核心功能需要偵測和韌性）"
+      P2_fix: "僅一級（建議性，不強制）"
+
+    # ─── 產出（不是散文，是可追蹤的實體） ───
+    output:
+      failure_entry:
+        action: "檢查 .failure/ 是否已有相關條目 → 有則更新 prevention 欄位，無則新增"
+        fields:
+          prevention_primary: "建議的架構加固"
+          prevention_secondary: "建議的監控點"
+          prevention_tertiary: "建議的容錯機制"
+      backlog_tasks:
+        action: "為非 trivial 的預防建議建立 P3 backlog 任務卡 — 用戶決定何時做"
+        tags: ["prevention"]
+        rule: "預防任務是建議性的，不自動 dispatch — 用戶決定優先級"
+
+    cli_format: |
+      🛡️ 預防建議
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+      一級（防止再發）: {建議} {→ TASK_ID 如已建立}
+      二級（早期偵測）: {建議} {→ TASK_ID 如已建立}
+      三級（減損復原）: {建議} {→ TASK_ID 如已建立}
+      📝 .failure/: {新增|更新} {FAIL-ID}
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  on_failure:
+    analysis:
+      - "讀 log 找失敗根因"
+      - "判斷：可重試 | 需補 context | 需建 FIX 任務 | 需換策略 | 需升級給 用戶"
+    actions:
+      retry: "重派同任務 — 補充失敗原因和缺失 context"
+      create_fix_and_dispatch: |
+        當原任務「部分完成但有缺失」時（如 TASK_12 只做了一半），建立 FIX 任務並立即 dispatch：
+        1. 用 task-api.js create 建立 [FIX] 任務（tags: fix,verification）
+        2. 用 task-api.js complete 標記原任務為已完成（因為部分成果要保留）
+        3. 執行 post-complete.js 完成原任務的 archive + git 流程
+        4. ⚠️ 立即回到 Phase 8 dispatch FIX 任務 — 不可停在這裡
+        流程: Phase 9 失敗 → 建 FIX → complete 原任務 → post-complete → Phase 8(FIX) → Phase 9(FIX) → ...
+      change_strategy: "換陣型（如 unit → solo 增加分析深度）"
+      escalate: "升級給 用戶 — 附上已嘗試的方法和失敗原因"
+      block: "node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] move TASK_XXX blocked"
+    selection_guide:
+      retry: "agent 沒做完但任務定義正確 — 重派同一個 TASK_XXX"
+      create_fix_and_dispatch: "agent 做了部分，但缺漏太多需要新任務補齊 — 建 [FIX] TASK + 自動 dispatch"
+      change_strategy: "同一策略試了 2 次仍失敗 — 換陣型或換 skill"
+      escalate: "技術瓶頸或需要用戶決策 — 停下來問用戶"
+      block: "外部依賴未滿足 — 標記 blocked 等待"
+    critical_rule: |
+      ⚠️ 建完 FIX 任務後「必須」立即 dispatch，不可停在 backlog。
+      這是閉環原則 — Ansuz 走到底，不留半成品給用戶手動處理。
+      流程是一個迴圈：Phase 9 → 建 FIX → Phase 8(FIX) → dispatch → Phase 9(FIX) → ...
+
+  # ─── Socratic Loop Guard（蘇格拉底迴圈守衛） ───
+  loop_guard:
+    description: "追蹤同一需求域的 FIX 次數，觸發 challenge_over_confirm.loop_detection"
+    counter: "同一 source/feature_id 的 FIX 任務累計次數"
+    threshold: 2
+    rule: |
+      FIX count >= 2 → 強制觸發 Socratic Thinking（loop_detection）
+      不可繼續用相同策略重派 — 必須先質疑原始假設
+    action: |
+      1. 暫停 dispatch
+      2. 輸出 🤔🤔 cli_format
+      3. 列出原始假設 + 至少 1 個替代假設
+      4. 用 verified 證據重新選擇 → 可能需要完全換方向
+      5. 如果仍無法判斷 → escalate 給用戶
+    cli_format: |
+      🤔🤔
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+      觸發: loop_detection
+      同問題域已嘗試 {N} 次修復
+      原始假設: {最初的診斷}
+      自問: 如果這個假設根本就是錯的，還有什麼可能？
+      替代假設:
+        H1: {替代假設 1}
+        H2: {替代假設 2}
+      結論: {經挑戰後的決定}
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  cli_format:
+    success: |
+      ✅ TASK_XXX 驗證通過
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+      變更: {檔案清單}
+      Commit: {commit hash}
+      驗收: {N}/{N} 通過
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    failure: |
+      ❌ TASK_XXX 驗證失敗
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+      已完成:
+      ✓ {已通過的驗收標準 1}
+      ✓ {已通過的驗收標準 2}
+      ✗ {未通過的驗收標準}
+
+      根因: {分析結果}
+      行動: {重派/建FIX並dispatch/換策略/升級}
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    fix_created: |
+      🔄 FIX 閉環啟動
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+      原任務: TASK_XXX → 已完成（部分成果保留）
+      FIX 任務: TASK_YYY → 立即 dispatch
+      缺失: {未通過的驗收標準}
+      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+# ═══════════════════════════════════════
+#  Phase 10: Post-Complete
+# ═══════════════════════════════════════
+phase_10_post_complete:
+  goal: "任務完成後的 archive + git 流程"
+  tool: ".formation/tools/post-complete.js"
+  actions:
+    archive:
+      command: "node {CORE}/.formation/tools/post-complete.js --task=TASK_XXX [--project-path={PROJECT_PATH}]"
+      behavior: "舊任務 → archived/（保留最新 10 個）"
+    git:
+      - "建立 task/task_xxx 分支（在 PROJECT_PATH 的 repo 內）"
+      - "stage + commit 所有變更"
+      - "merge 到用戶當前分支"
+      - "❌ 不自動 merge 到 main — 用戶 確認後手動操作"
+    progress:
+      - "更新 dev/pipeline/PROGRESS.md — Last Update + Statistics + Recent Activity（僅 Core 專案）"
+  cli_format: |
+    📦 Post-Complete
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    ✓ Archive: {N} 個舊任務已封存
+    ✓ Git: task/task_xxx → {user_branch}
+    ✓ PROGRESS.md 已更新
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+# ═══════════════════════════════════════
+#  Phase 11: 回報
+# ═══════════════════════════════════════
+phase_11_report:
+  goal: "向 用戶 匯報最終結果"
+
+  # ─── 成功回報 ───
+  success_format: |
+    ✅ TASK_XXX 完成
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    陣型: {formation}/{skill}
+    結果: {一句話摘要}
+    變更: {檔案清單}
+
+    ⏱️ 時間:
+    - 人類預估: {estimated_hours}h
+    - Agent 實際: ~{actual_minutes} min
+    - 效率提升: ~{ratio}x
+    - 團隊耗時: {elapsed_time}
+
+    📦 Archive: {N} 個舊任務已封存
+    🔀 Git: task/task_xxx → {user_branch}
+
+    {如有預防分析，附加 🛡️ 預防建議區塊}
+    {如有寫入 rune，附加 🧠 認知層更新區塊}
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  # ─── 失敗回報 ───
+  failure_format: |
+    ❌ TASK_XXX 阻塞
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    陣型: {formation}/{skill}
+    原因: {失敗原因}
+
+    已完成:
+    ✓ {已完成的步驟}
+    ✗ {失敗的步驟}
+
+    建議:
+    - {下一步行動}
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  # ─── 批量完成回報 ───
+  batch_format: |
+    ✅ {N} 個任務完成
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    | ID | 標題 | 陣型 | 狀態 |
+    |----|------|------|------|
+    | TASK_XXX | ... | unit/do | ✅ |
+    | TASK_YYY | ... | unit/do | ✅ |
+
+    ⏱️ 時間:
+    - 人類預估: {total_hours}h
+    - Agent 實際: ~{total_minutes} min
+    - 效率提升: ~{ratio}x
+    - 團隊耗時: {elapsed_time}
+
+    📦 Archive: {N} 個舊任務已封存
+    🔀 Git: task/task_xxx → {user_branch}
+
+    {如有預防分析，附加 🛡️ 預防建議區塊}
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+    下一步: {建議行動 | 「所有任務已完成」}
+    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  interaction:
+    type: "ask"
+    instruction: "輸出結果後，用 AskUserQuestion 問 用戶：「接下來要做什麼？」"
+    options:
+      - "繼續下一個需求"
+      - "結束，沒有其他事了"
+      - "我有新的需求要提"
+
+# ═══════════════════════════════════════
+#  QA Issue Intake（接收 QA 缺陷報告）
+# ═══════════════════════════════════════
+qa_issue_intake:
+  description: "接收 QA Agent 缺陷報告，自動建立修復任務"
+  input: "dev/qa/QA_ISSUES_<YYYYMMDD_HHmmss>.md"
+  priority_mapping:
+    critical: "P0 — 系統無法運作、安全漏洞、數據損壞"
+    major: "P1 — 核心功能異常、嚴重影響體驗"
+    minor: "P2 — 輕微 Bug、不影響核心功能"
+    trivial: "P3 — 文字錯誤、樣式瑕疵"
+  agent_mapping:
+    backend_bug: "backend — API 錯誤、資料庫問題、安全漏洞"
+    frontend_bug: "frontend — UI 異常、組件錯誤、樣式問題"
+    fullstack_bug: "拆分為獨立的 frontend + backend 任務"
+  flow:
+    - "讀取 QA Issue Report"
+    - "為每個缺陷建立修復任務（Phase 4-7）"
+    - "根據嚴重程度映射 priority"
+    - "根據缺陷性質分配 role"
+    - "acceptance_criteria 必含：缺陷已修復 + 回歸測試通過"
+
+# ═══════════════════════════════════════
+#  優先級定義
+# ═══════════════════════════════════════
+priority:
+  P0: "阻塞性問題 — 必須立即處理（中斷當前工作）"
+  P1: "核心功能 — 高優先級（當前迭代必須完成）"
+  P2: "重要功能 — 中優先級（排入 backlog）"
+  P3: "Nice-to-have — 低優先級（有空再做）"
+
+# ═══════════════════════════════════════
+#  Feature ID 制度
+# ═══════════════════════════════════════
+feature_id:
+  format: "F-XXX（三位數字，001~999）"
+  sub_format: "F-XXX.Y（子功能）"
+  lookup: "dev/PRODUCT_SPEC.md — Feature ID Index"
+  source_rules:
+    feature: "source: 'F-001' — 對應 PRODUCT_SPEC 功能"
+    bug: "source: 'Bug Report #XXX' — 臨時需求或 Bug"
+    qa: "source: 'QA Issue Report: QA_ISSUES_<timestamp>.md'"
+    multi: "feature_ids: ['F-001', 'F-002'] — 跨功能任務"
+
+# ═══════════════════════════════════════
+#  與 .failure/ 系統整合
+# ═══════════════════════════════════════
+failure_integration:
+  when: "Phase 0 初始化 + Phase 2 背景調研 + Phase 9 結果驗證失敗時 + Phase 9 預防分析時"
+  check: "讀 .failure/INDEX.yaml — 搜尋相關失敗模式"
+  learn: "新失敗發生時 → 記錄到 .failure/ 避免重複"
+  prevention_feedback: |
+    Phase 9 prevention_analysis 完成後：
+    1. 檢查 .failure/ 是否已有相關條目（按 category + scope 匹配）
+    2. 有 → 更新條目的 prevention 欄位（primary/secondary/tertiary）
+    3. 無 → 新增條目（含根因 + 三級預防建議）
+    4. 預防建議中的非 trivial 項目 → 建立 P3 backlog 任務卡（tags: prevention）
+
+# ═══════════════════════════════════════
+#  效率規則
+# ═══════════════════════════════════════
+efficiency:
+  do:
+    - "✅ 輕量工作自己做（Glob/Grep/Read/單檔 Edit）"
+    - "✅ 一個 message 能發多少 Bash(background) 就發多少"
+    - "✅ 結果到了立即處理 — 不等齊再動"
+    - "✅ 小任務不拆 — 一個 dispatch 做完"
+    - "✅ Phase 1-6 可壓縮 — 簡單需求快速走完"
+  dont:
+    - "❌ 不為開 agent 而開 agent"
+    - "❌ 不重複 agent 已在做的工作"
+    - "❌ 不用 Task tool subagent 繞過 Formation"
+
+# ═══════════════════════════════════════
+#  ⚠️ Task-First 原則（強制）
+# ═══════════════════════════════════════
+task_first:
+  rule: |
+    Ansuz 的預設行為是「先建立任務，再 dispatch」。
+    除非任務極其簡單（見 direct_execution_threshold），否則一律先走 Phase 1-7 建立任務卡。
+  direct_execution_threshold:
+    description: "只有滿足以下「全部」條件時，才可跳過任務建立直接執行"
+    conditions:
+      - "單一檔案修改（scope 只有 1 個檔案）"
+      - "改動範圍小於 20 行"
+      - "無需拆解（不涉及多模組/多語言）"
+      - "無依賴（不需要先完成其他工作）"
+      - "用戶意圖明確無歧義（如「把按鈕顏色改成紅色」）"
+    examples_skip:
+      - "修正一個 typo"
+      - "調整一個 CSS 樣式值"
+      - "刪除一行 console.log"
+    examples_must_create_task:
+      - "新增功能（即使看起來簡單）"
+      - "修改 2 個以上檔案"
+      - "涉及 Rust + TypeScript 跨語言"
+      - "需要新增 API endpoint"
+      - "用戶說「幫我做 XXX」但範圍不明確"
+  enforcement: |
+    ❌ 不可因為「看起來不複雜」就跳過任務建立
+    ✅ 有疑慮時，一律建立任務（寧可多建不可漏建）
+    ✅ 建立任務的成本極低（task-api.js create），但跳過的風險高（無追蹤、無 scope 約束、無驗收標準）
+
+# ═══════════════════════════════════════
+#  範例：完整生命週期
+# ═══════════════════════════════════════
+examples:
+  # ─── 範例 1：新功能需求 ───
+  new_feature:
+    input: "我想在 Dashboard 加入暗黑模式"
+    flow:
+      phase_1: |
+        📋 需求理解
+        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+        需求摘要: Dashboard 新增暗黑模式切換功能
+        需求類型: 新功能
+        核心目標: 用戶可在亮色/暗色主題間切換
+        優先級: P2
+        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+      phase_3: |
+        📐 任務設計
+        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+        共拆解為 2 個任務：
+
+        | # | 標題 | Agent | Priority | Hours |
+        |---|------|-------|----------|-------|
+        | 1 | 建立主題系統（CSS Variables + Context） | frontend | P2 | 4h |
+        | 2 | 新增主題切換 UI（Settings 頁面） | frontend | P2 | 2h |
+
+        依賴: TASK_2 → TASK_1
+        陣型: unit × 2（序列 dispatch）
+        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+      phase_6: "用戶批准 → Phase 7 建立任務 → Phase 8 dispatch"
+      phase_11: |
+        ✅ 2 個任務完成
+        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+        | ID | 標題 | 陣型 | 狀態 |
+        |----|------|------|------|
+        | TASK_248 | 建立主題系統 | unit/do | ✅ |
+        | TASK_249 | 新增主題切換 UI | unit/do | ✅ |
+
+        ⏱️ 人類預估: 6h | Agent 實際: ~8 min | 效率: ~45x
+        🔀 Git: task/task_248 → main
+        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  # ─── 範例 2：簡單 Bug 修復（壓縮流程）───
+  simple_bug:
+    input: "Sidebar 在手機上超出螢幕"
+    flow: |
+      # Phase 1-6 壓縮為快速確認
+      📋 需求: 修復 Sidebar 手機端溢出
+      📐 任務: TASK_250（frontend, P1, 1h, unit/do）
+      ✅ 用戶 批准
+
+      # Phase 7-11 正常執行
+      🚀 Dispatch → unit/do
+      ✅ 驗證通過 → post-complete → 回報
+
+  # ─── 範例 3：QA 缺陷批次處理 ───
+  qa_batch:
+    input: "QA 報告了 3 個 Bug（dev/qa/QA_ISSUES_20260222.md）"
+    flow: |
+      # 讀取 QA Report → 建立 3 個修復任務
+      | # | 缺陷 | 嚴重度 | Priority | Agent |
+      |---|------|--------|----------|-------|
+      | 1 | API 500 錯誤 | Critical | P0 | backend |
+      | 2 | 表單驗證失效 | Major | P1 | frontend |
+      | 3 | 文字截斷 | Minor | P2 | frontend |
+
+      # P0 優先 dispatch → P1 並行 → P2 排隊