kenaz 0.3.18 → 0.3.19

package/core/.rule/general/cortex-memory-recall.yaml

@@ -1,446 +0,0 @@
-# .rule/general/cortex-memory-recall.yaml
-# Cortex 記憶回想規則 - Agent 何時使用 RAG 語義搜尋 vs 傳統搜尋
-# 優先級：此規則凌駕於 CLAUDE.md 和 .claude/skills/ 中的定義
-
-_meta:
-  category: "general"
-  priority: 1
-  applies_to:
-    - "ai_agent"
-  last_updated: "2026-02-13"
-  created_by: "基於 11 場景對比測試（RAG vs Grep/Glob/Symbols）的實證數據"
-
-rules:
-  # =============================================================================
-  # CTX-001: Cortex 記憶回想觸發條件
-  # =============================================================================
-  - id: "CTX-001"
-    title: "Cortex 記憶回想觸發條件"
-    description: |
-      定義 Agent 何時應使用 Cortex RAG 語義搜尋（cortex_search）進行記憶回想。
-      Cortex 適合「理解性」查詢，不適合「精確性」查詢。
-    severity: "must"
-    rationale: "基於實測數據，RAG 在語義理解場景顯著優於傳統搜尋"
-
-    # 必須使用 Cortex RAG 的場景
-    must_use_cortex:
-      - trigger: "任務開始前的上下文建立"
-        tool: "cortex_context 或 cortex_overview"
-        description: |
-          開始新任務時，先用 cortex_context 獲取專案結構，
-          再用 cortex_search 搜尋任務相關的代碼片段。
-        example:
-          query: "用戶認證 API 設計"
-          purpose: "找到現有的認證相關代碼和設計決策"
-
-      - trigger: "歷史決策回溯（為什麼）"
-        tool: "cortex_search"
-        description: |
-          當需要理解「為什麼這樣設計」「之前做過什麼決定」時，
-          RAG 能從 .memory/, .kenaz/, CLAUDE.md 中找到設計理由。
-        example:
-          query: "為什麼選擇 Leader + Worker 團隊模式"
-          expected_score: ">= 0.65"
-
-      - trigger: "跨模組架構理解"
-        tool: "cortex_search"
-        description: |
-          當任務涉及多個模組的交互關係時，RAG 能跨文件找到
-          interface 定義、規則、實現代碼之間的關聯。
-        example:
-          query: "task queue dependency resolver parallel execution"
-          expected_score: ">= 0.60"
-
-      - trigger: "概念/語義搜尋（特別是中文）"
-        tool: "cortex_search"
-        description: |
-          當查詢是自然語言描述而非精確關鍵字時，RAG 的語義理解
-          能找到概念相關但用詞不同的文件。
-        example:
-          query: "失敗經驗學習機制 如何從錯誤中學習"
-          expected_score: ">= 0.65"
-
-      - trigger: "探索不熟悉的功能區域"
-        tool: "cortex_search + cortex_symbols"
-        description: |
-          當 Agent 對某個功能區域不熟悉時，先用 cortex_search
-          找到相關代碼片段，再用 cortex_symbols 定位具體函數。
-        example:
-          query: "團隊成員之間的通信機制"
-
-      - trigger: "失敗模式檢索（AGT-005 增強）"
-        tool: "cortex_search"
-        description: |
-          當任務失敗需要查閱失敗經驗時，除了讀取 .failure/INDEX.yaml，
-          也可用 cortex_search 搜尋語義相關的失敗記錄。
-        example:
-          query: "JSON 解析失敗 BOM 編碼問題"
-
-      - trigger: "代碼關聯與依賴分析"
-        tool: "cortex_search"
-        description: |
-          當需要理解某個組件/模組的依賴關係、調用者、相關文件時，
-          RAG 能一次返回源碼、調用者、型別定義等跨文件關聯。
-          比 Grep 多次查詢再拼湊高效得多。
-        example:
-          query: "TerminalPanel 依賴哪些 hooks 和 context"
-
-      - trigger: "尋找設計模式/最佳實踐"
-        tool: "cortex_search"
-        description: |
-          當需要找到專案中的複用規則、設計模式、最佳實踐文件時，
-          RAG 能從 .rule/、.agents/skills/、.kenaz/ 中找到相關規範。
-          Grep 只能匹配字面量，無法理解「複用模式」等概念。
-        example:
-          query: "可複用的 React hook 自定義 hooks pattern"
-
-    # 禁止使用 Cortex RAG 的場景
-    must_not_use_cortex:
-      - trigger: "精確字串/正則搜尋"
-        use_instead: "Grep"
-        description: |
-          當查詢是精確字串、配置值、正則表達式時，
-          RAG 的語義搜尋會返回無關結果（測試得分 0.44）。
-        examples:
-          - "hnsw:space.*cosine"
-          - "embedding_model.*bge-m3"
-          - "import.*SentenceTransformer"
-          - "TODO|FIXME|HACK"
-
-      - trigger: "文件名/路徑查找"
-        use_instead: "Glob"
-        description: |
-          當需要找到特定文件或匹配文件模式時，
-          Glob 精確且即時，RAG 會返回構建產物噪音。
-        examples:
-          - "**/*.test.ts"
-          - "**/TerminalPanel*"
-          - "src/components/**/*.tsx"
-
-      - trigger: "精確符號定位（函數、類名）"
-        use_instead: "cortex_symbols"
-        description: |
-          當已知函數名/類名，需要找到定義位置時，
-          cortex_symbols 返回精確的 file:line 和簽名。
-        examples:
-          - "run_ctags → ctags_runner.py:84"
-          - "GitSyncManager → git_sync.py:76"
-          - "useMediaQuery → use-media-query.ts:10"
-
-      - trigger: "已知文件路徑，需要讀取內容"
-        use_instead: "Read"
-        description: |
-          如果已經知道要讀取哪個文件，直接 Read。
-          不要先搜尋再讀取。
-
-      - trigger: "統計/計數查詢"
-        use_instead: "Grep (count mode)"
-        description: |
-          統計某個模式出現的次數（如 useState 使用次數），
-          Grep count 模式更準確。
-
-      - trigger: "枚舉型查詢（列出所有 X）"
-        use_instead: "Grep (pattern mode)"
-        description: |
-          當需要列出所有自定義 hooks、所有 API endpoints、所有 interface 時，
-          Grep 精確模式匹配更適合枚舉。RAG 語義搜尋會混入噪音。
-        examples:
-          - "export function use[A-Z]  →  列出所有自定義 hooks"
-          - "app.get\\(|app.post\\(  →  列出所有 API routes"
-          - "export interface  →  列出所有 interface"
-
-  # =============================================================================
-  # CTX-002: 搜尋工具選擇決策樹
-  # =============================================================================
-  - id: "CTX-002"
-    title: "搜尋工具選擇決策樹"
-    description: |
-      Agent 遇到搜尋需求時，按此決策樹選擇最佳工具。
-      遵循「精確優先，語義補充」原則。
-    severity: "should"
-    rationale: "避免用錯工具浪費 token 和時間"
-
-    decision_tree: |
-      查詢需求
-      │
-      ├── 知道精確文件路徑？
-      │   └── YES → Read（直接讀取）
-      │
-      ├── 知道文件名/模式？
-      │   └── YES → Glob（文件發現）
-      │
-      ├── 知道精確字串/正則？
-      │   └── YES → Grep（精確匹配）
-      │
-      ├── 知道函數名/類名？
-      │   └── YES → cortex_symbols（符號定位）
-      │
-      ├── 需要理解「為什麼」或「怎麼運作」？
-      │   └── YES → cortex_search（語義搜尋）
-      │
-      ├── 需要跨模組/跨文件的關聯理解？
-      │   └── YES → cortex_search（語義搜尋）
-      │
-      ├── 需要專案整體結構？
-      │   └── YES → cortex_context / cortex_overview
-      │
-      └── 其他
-          └── 先 Grep，結果太多或不精確 → cortex_search
-
-    # ==========================================================================
-    # content_type 過濾器（語法糖，大幅提升搜尋精度）
-    # ==========================================================================
-    content_type_filter:
-      description: |
-        cortex_search 支援 content_type 參數，自動轉換為 file_path 前綴過濾。
-        善用此參數可大幅減少噪音、提升結果相關性。
-      mapping:
-        rule: ".rule/ 目錄下的規則文件"
-        memory: ".memory/ 目錄下的記憶文件"
-        doc: "docs/ 目錄下的文檔"
-        code: "排除 .rule/, .memory/, .failure/, docs/（只搜代碼）"
-      usage_examples:
-        - scenario: "尋找相關規則"
-          query: "React hook 複用規則"
-          content_type: "rule"
-          benefit: "只搜 .rule/，避免代碼和文檔噪音"
-        - scenario: "尋找實際代碼實現"
-          query: "task queue parallel execution"
-          content_type: "code"
-          benefit: "排除規則和文檔，只返回源碼"
-        - scenario: "回顧歷史決策"
-          query: "選擇 Leader Worker 模式的原因"
-          content_type: "memory"
-          benefit: "只搜 .memory/，精準命中經驗記錄"
-      best_practice: |
-        1. 知道要找規則 → content_type=rule
-        2. 知道要找代碼 → content_type=code
-        3. 知道要找經驗 → content_type=memory
-        4. 不確定在哪 → 不加 content_type（全域搜尋）
-
-    tool_summary:
-      cortex_search:
-        strength: "語義理解、概念搜尋、跨模組關聯、歷史決策"
-        weakness: "精確匹配差、技術術語弱"
-        best_score_range: "0.60-0.70"
-        noise_threshold: "< 0.50 的結果通常是噪音"
-        tip: "善用 content_type 參數（rule/code/memory/doc）可大幅提升精度"
-
-      cortex_symbols:
-        strength: "精確符號定位、函數簽名、file:line 定位"
-        weakness: "只能按名稱搜尋，不支援語義"
-        best_for: "已知函數/類名時的快速定位"
-
-      cortex_context:
-        strength: "專案結構概覽、目錄樹、核心類型"
-        weakness: "大型專案會自動切換到精簡模式"
-        best_for: "開始新任務前的上下文建立"
-
-      cortex_overview:
-        strength: "專案級概覽、模組關係、技術棧"
-        weakness: "首次生成較慢（需要 Map-Reduce）"
-        best_for: "理解整個專案架構"
-
-      grep:
-        strength: "精確匹配、正則、配置值、統計計數"
-        weakness: "不理解語義、結果無排序"
-        best_for: "精確字串/模式搜尋"
-
-      glob:
-        strength: "文件名匹配、即時、無噪音"
-        weakness: "只能按文件名搜尋"
-        best_for: "文件發現和定位"
-
-  # =============================================================================
-  # CTX-003: 任務階段性記憶回想
-  # =============================================================================
-  - id: "CTX-003"
-    title: "任務階段性記憶回想"
-    description: |
-      定義 Agent 在任務執行的不同階段，應如何使用 Cortex 進行記憶回想。
-      與 AGT-001（記憶點優先載入）和 AGT-004（任務前置流程）整合。
-    severity: "should"
-    rationale: "確保 Agent 在正確的時機獲取正確深度的知識"
-
-    phases:
-      - phase: "Phase 0: 任務接收（補充 AGT-004）"
-        timing: "收到任務需求時"
-        actions:
-          - tool: "cortex_context"
-            purpose: "獲取專案結構和核心類型（自動判斷全量/RAG）"
-            required: false
-            condition: "Agent 對專案結構不熟悉時"
-          - tool: "cortex_search"
-            purpose: "搜尋任務相關的已有代碼和設計決策"
-            required: false
-            condition: "任務涉及已有功能的修改或擴展時"
-            example_query: "用戶認證 API 設計"
-
-      - phase: "Phase 1: 設計決策"
-        timing: "需要做技術選型或架構決策時"
-        actions:
-          - tool: "cortex_search"
-            purpose: "搜尋過去的設計決策和架構模式"
-            required: true
-            example_query: "為什麼選擇 React Query 而非 SWR"
-          - tool: "cortex_search"
-            purpose: "搜尋 .memory/ 和 .kenaz/ 中的經驗記錄"
-            required: true
-            example_query: "狀態管理最佳實踐"
-
-      - phase: "Phase 2: 實現開發"
-        timing: "實際寫代碼時"
-        actions:
-          - tool: "cortex_symbols"
-            purpose: "定位需要修改的函數/類"
-            required: false
-            condition: "需要修改已有代碼時"
-          - tool: "Grep"
-            purpose: "查找精確的 import 路徑、配置值"
-            required: false
-          - tool: "cortex_search"
-            purpose: "查找相似組件/模式作為參考"
-            required: false
-            condition: "需要開發類似功能時"
-
-      - phase: "Phase 3: 問題排查"
-        timing: "遇到錯誤或 Bug 時"
-        actions:
-          - tool: "cortex_search"
-            purpose: "搜尋 .failure/ 中的相關失敗經驗"
-            required: true
-            example_query: "JSON 解析失敗 BOM 編碼"
-          - tool: "Grep"
-            purpose: "定位錯誤訊息出現的位置"
-            required: false
-
-      - phase: "Phase 4: 任務完成"
-        timing: "任務完成後"
-        actions:
-          - tool: "cortex_search"
-            purpose: "驗證新代碼與現有架構是否一致"
-            required: false
-            condition: "修改了核心模組時"
-
-  # =============================================================================
-  # CTX-004: 搜尋品質保障
-  # =============================================================================
-  - id: "CTX-004"
-    title: "搜尋品質保障"
-    description: |
-      定義如何判斷搜尋結果品質，以及何時應切換到其他工具。
-    severity: "should"
-    rationale: "避免 Agent 使用低品質搜尋結果做出錯誤決策"
-
-    quality_thresholds:
-      high_confidence: ">= 0.65"
-      acceptable: "0.55 - 0.65"
-      low_confidence: "0.45 - 0.55"
-      noise: "< 0.45"
-
-    actions_by_quality:
-      - range: ">= 0.65"
-        action: "直接使用結果"
-        description: "高信心度，結果高度相關"
-
-      - range: "0.55 - 0.65"
-        action: "可參考，但建議交叉驗證"
-        description: "中等信心度，可能部分相關"
-
-      - range: "0.45 - 0.55"
-        action: "切換到 Grep/Glob 重新搜尋"
-        description: "低信心度，結果可能不相關"
-
-      - range: "< 0.45"
-        action: "忽略結果，使用精確搜尋"
-        description: "噪音，應完全忽略"
-
-    fallback_strategy: |
-      當 cortex_search 結果不佳時：
-      1. 嘗試重新措辭查詢（更具體或更通用）
-      2. 切換到 cortex_symbols（如果查詢含函數/類名）
-      3. 切換到 Grep（如果查詢含精確字串）
-      4. 使用 cortex_context 獲取全局結構後，再針對性搜尋
-
-    known_limitations:
-      - issue: "構建產物噪音"
-        description: ".next/ 和其他構建目錄的文件會被索引，導致重複結果"
-        workaround: "忽略路徑中包含 .next/, dist/, build/, target/ 的結果"
-
-      - issue: "純英文技術術語搜尋偏弱"
-        description: "bge-m3 對純英文技術術語的語義理解不如中文概念搜尋"
-        workaround: "技術術語搜尋優先用 Grep 或 cortex_symbols"
-
-      - issue: "大 chunk 拆分可能影響上下文完整性"
-        description: "超過 1024 tokens 的 chunk 被拆分為多個 part"
-        workaround: "搜尋到 part N 時，考慮也讀取相鄰的 part"
-
-# =============================================================================
-# 與其他規則的整合
-# =============================================================================
-integration:
-  with_AGT_001:
-    description: |
-      AGT-001 要求先讀取 .memory/CONTEXT.md。
-      CTX-001 補充：讀取 CONTEXT.md 後，可用 cortex_search
-      搜尋任務相關的深度知識。
-
-  with_AGT_004:
-    description: |
-      AGT-004 定義任務前置流程。
-      CTX-003 的 Phase 0 補充 AGT-004 的 Context 獲取階段，
-      加入 Cortex 語義搜尋步驟。
-
-  with_AGT_005:
-    description: |
-      AGT-005 要求失敗時查閱 .failure/。
-      CTX-001 補充：除了讀取 .failure/INDEX.yaml，
-      還可用 cortex_search 語義搜尋相關失敗經驗。
-
-  with_pipeline:
-    description: |
-      Pipeline 任務執行（PPL-101~112）過程中，
-      CTX-003 的四個階段分別對應任務的不同執行步驟。
-
-# =============================================================================
-# 快速參考（Agent 檢查清單）
-# =============================================================================
-quick_reference:
-  use_cortex_search_when:
-    - "需要理解「為什麼」某個功能這樣設計"
-    - "需要找到跨多個模組的相關代碼"
-    - "用中文描述想找的功能/概念"
-    - "需要從 .memory/ 或 .failure/ 中找到經驗記錄"
-    - "探索不熟悉的代碼區域"
-    - "需要找到相似的實現模式作為參考"
-    - "理解組件/模組的依賴關係和調用者"
-    - "尋找設計模式、最佳實踐、複用規則"
-    - "跨文件的代碼關聯（如 WebSocket 相關的所有代碼）"
-
-  content_type_cheat_sheet:
-    "找規則/規範": "content_type=rule"
-    "找源代碼": "content_type=code"
-    "找經驗/決策": "content_type=memory"
-    "找文檔": "content_type=doc"
-    "不確定": "不加 content_type"
-
-  use_grep_when:
-    - "查找精確字串（配置值、import 路徑）"
-    - "使用正則表達式搜尋"
-    - "統計某個模式的出現次數"
-    - "查找 TODO/FIXME 標記"
-    - "枚舉型查詢（列出所有自定義 hooks、所有 API routes）"
-
-  use_cortex_symbols_when:
-    - "知道函數名或類名，需要找定義位置"
-    - "需要查看函數簽名"
-    - "列出某個文件中的所有符號"
-
-  use_glob_when:
-    - "知道文件名或部分名稱"
-    - "按副檔名搜尋（*.tsx, *.py）"
-    - "查找目錄結構"
-
-  use_read_when:
-    - "已經知道精確的文件路徑"
-    - "需要讀取完整文件內容"

package/core/.rule/general/pipeline.yaml

@@ -1,246 +0,0 @@
-# Pipeline 系統規則
-# 定義任務管理、佇列、統計的標準規範
-
-_meta:
-  version: "1.0.0"
-  category: "general"
-  last_updated: "2026-02-05"
-  description: |
-    Pipeline 系統的核心規則，確保任務管理的一致性和可追溯性。
-
-# ============================================================
-# PPL-001: 統計數據必須累積制
-# ============================================================
-PPL-001:
-  title: "統計數據必須採用累積制"
-  severity: must
-  applies_to: [ai_agent, human_developer]
-
-  description: |
-    TASK_QUEUE.json 的統計數據必須反映**整體專案進度**，
-    而非僅當前佇列狀態。
-
-  rationale: |
-    - Agent 需要了解專案的整體進度（已完成多少任務）
-    - 只顯示當前佇列會誤導 Agent 認為專案剛開始
-    - 累積統計幫助評估專案成熟度和風險
-
-  rules:
-    - id: "PPL-001.1"
-      rule: "`total` 必須包含所有任務（佇列 + 已完成）"
-      example: "total = 52 (2 pending + 50 completed)"
-
-    - id: "PPL-001.2"
-      rule: "`completed` 必須從 .memory/COMPLETED_TASKS.json 計算"
-      example: "completed = 50"
-
-    - id: "PPL-001.3"
-      rule: "`pending/in_progress/blocked` 反映當前佇列狀態"
-      example: "pending = 2 (只計算 tasks 陣列中的 pending 任務)"
-
-    - id: "PPL-001.4"
-      rule: "metadata 必須包含 `completed_archive` 指向封存位置"
-      example: 'metadata.completed_archive = ".memory/COMPLETED_TASKS.json"'
-
-  correct_example: |
-    {
-      "statistics": {
-        "total": 52,
-        "pending": 2,
-        "in_progress": 0,
-        "blocked": 0,
-        "completed": 50,
-        "cancelled": 0
-      },
-      "metadata": {
-        "completed_archive": ".memory/COMPLETED_TASKS.json"
-      }
-    }
-
-  incorrect_example: |
-    {
-      "statistics": {
-        "total": 2,        // ❌ 只計算當前佇列
-        "completed": 0     // ❌ 忽略已完成任務
-      }
-    }
-
-# ============================================================
-# PPL-002: 已完成任務必須封存
-# ============================================================
-PPL-002:
-  title: "已完成任務必須封存到 .memory/"
-  severity: must
-  applies_to: [ai_agent, human_developer]
-
-  description: |
-    TASK_QUEUE.json 只保留 active 任務（pending/in_progress/blocked），
-    已完成任務必須移到 .memory/COMPLETED_TASKS.json。
-
-  rationale: |
-    - 保持 TASK_QUEUE.json 精簡，提升載入和解析效率
-    - 已完成任務的元數據仍需保留以供查詢和統計
-    - 避免 Scheduler 重複載入已完成任務
-
-  rules:
-    - id: "PPL-002.1"
-      rule: "TASK_QUEUE.json 的 tasks 陣列只包含 active 任務"
-      definition: "active = pending | in_progress | blocked"
-
-    - id: "PPL-002.2"
-      rule: "completed 任務移動流程"
-      steps:
-        - "從 dev/pipeline/tasks/ 移到 dev/pipeline/completed/"
-        - "從 TASK_QUEUE.json tasks 陣列移除"
-        - "新增到 .memory/COMPLETED_TASKS.json"
-        - "更新 statistics.completed 計數"
-
-    - id: "PPL-002.3"
-      rule: "定期執行清理腳本"
-      frequency: "當 TASK_QUEUE.json 中有 completed 任務時"
-
-  cleanup_script: |
-    const data = JSON.parse(fs.readFileSync('dev/pipeline/TASK_QUEUE.json', 'utf8'));
-    const completed = JSON.parse(fs.readFileSync('.memory/COMPLETED_TASKS.json', 'utf8'));
-
-    // 只保留 active 任務
-    data.tasks = data.tasks.filter(t =>
-      ['pending', 'in_progress', 'blocked'].includes(t.status)
-    );
-
-    // 更新統計
-    data.statistics = {
-      total: data.tasks.length + completed.length,
-      pending: data.tasks.filter(t => t.status === 'pending').length,
-      in_progress: data.tasks.filter(t => t.status === 'in_progress').length,
-      blocked: data.tasks.filter(t => t.status === 'blocked').length,
-      completed: completed.length,
-      cancelled: 0
-    };
-
-# ============================================================
-# PPL-003: COMPLETED_TASKS.json 格式規範
-# ============================================================
-PPL-003:
-  title: "已完成任務封存格式規範"
-  severity: must
-  applies_to: [ai_agent, human_developer]
-
-  description: |
-    .memory/COMPLETED_TASKS.json 必須包含足夠的元數據，
-    以便查詢和分析歷史任務。
-
-  required_fields:
-    - field: "id"
-      type: "string"
-      example: "TASK_075"
-
-    - field: "title"
-      type: "string"
-      example: "Agents Page 組件化重構"
-
-    - field: "priority"
-      type: "string"
-      example: "P1"
-
-    - field: "agent_type"
-      type: "string"
-      example: "frontend"
-
-    - field: "source"
-      type: "string"
-      example: "User Request - Code Architecture"
-
-    - field: "estimated_hours"
-      type: "number"
-      example: 3
-
-    - field: "complexity"
-      type: "string"
-      example: "medium"
-
-    - field: "source_file"
-      type: "string"
-      example: "TASK_075_agents_page_component_refactor.yaml"
-
-  optional_fields:
-    - "completed_at"
-    - "description"
-    - "scope_paths"
-
-  format_example: |
-    [
-      {
-        "id": "TASK_075",
-        "title": "Agents Page 組件化重構",
-        "priority": "P1",
-        "agent_type": "frontend",
-        "source": "User Request",
-        "estimated_hours": 3,
-        "complexity": "medium",
-        "source_file": "TASK_075_agents_page_component_refactor.yaml"
-      }
-    ]
-
-# ============================================================
-# PPL-004: Scheduler 同步規則
-# ============================================================
-PPL-004:
-  title: "Scheduler 只從 tasks/ 同步"
-  severity: must
-  applies_to: [ai_agent]
-
-  description: |
-    Multi-Agent Scheduler 同步任務時，只應從 dev/pipeline/tasks/
-    讀取，不應從 completed/ 同步歷史任務。
-
-  rationale: |
-    - 避免將已完成任務重新加入佇列
-    - 防止統計數據污染
-    - 保持 TASK_QUEUE.json 精簡
-
-  rules:
-    - id: "PPL-004.1"
-      rule: "Scheduler 啟動時只掃描 tasks/ 目錄"
-      path: "dev/pipeline/tasks/*.yaml"
-
-    - id: "PPL-004.2"
-      rule: "忽略 completed/ 目錄"
-      path: "dev/pipeline/completed/*.yaml"
-
-    - id: "PPL-004.3"
-      rule: "任務完成後立即移動文件"
-      steps:
-        - "mv dev/pipeline/tasks/TASK_XXX.yaml dev/pipeline/completed/"
-        - "從 TASK_QUEUE.json 移除該任務"
-
-# ============================================================
-# PPL-005: PROGRESS.md 精簡原則
-# ============================================================
-PPL-005:
-  title: "PROGRESS.md 只保留必要資訊"
-  severity: should
-  applies_to: [ai_agent, human_developer]
-
-  description: |
-    PROGRESS.md 應簡潔明瞭，避免冗長的歷史記錄。
-    詳細歷史資料應查詢 .memory/COMPLETED_TASKS.json。
-
-  required_sections:
-    - section: "Statistics"
-      content: "累積統計數據（含完成率）"
-
-    - section: "Current Queue"
-      content: "當前待處理和執行中任務"
-
-    - section: "Recent Activity"
-      content: "最近 5-10 條活動記錄"
-
-    - section: "Notes"
-      content: "封存位置、文件結構說明"
-
-  max_length: "100 lines"
-
-  deprecated_sections:
-    - "完整歷史任務列表（改用 .memory/COMPLETED_TASKS.json）"
-    - "詳細依賴圖（過於複雜，改用任務文件內的 dependencies）"