kenaz 0.3.18 → 0.3.20

package/core/.rule/pipeline/auto-update.yaml

@@ -1,282 +0,0 @@
-rule_id: PPL-003
-title: 任務完成後必須更新 Pipeline 系統
-category: pipeline
-severity: critical
-status: active
-created_at: 2026-02-06
-author: PM Lead (Product Manager Agent)
-
-description: |
-  當任務完成並提交 Git commit 時，必須同步更新 Pipeline 系統的所有相關文件。
-  這是防止 FAIL-003（TASK_QUEUE 污染）問題的核心規則。
-
-context: |
-  問題背景：
-  - Pipeline 多次出現不一致（PROGRESS.md 說完成，TASK_QUEUE.json 說 pending）
-  - 已完成任務文件未歸檔到 completed/ 目錄
-  - 統計數據不一致，影響進度追蹤
-  - 用戶反覆提到 "Pipeline 常常不對"
-
-  根本原因：
-  - Developer Agent 未執行完整的 Pipeline 更新流程
-  - 缺少自動化驗證機制
-  - 缺少強制性檢查清單
-
-requirements:
-  1_update_task_queue:
-    description: 更新 TASK_QUEUE.json 中任務的狀態與元數據
-    steps:
-      - 更新任務的 status 為 "completed"
-      - 填寫 completed_at（ISO 8601 格式，含時區）
-      - 填寫 completed_by（Agent 名稱）
-      - 填寫 git_commit（Git commit hash，如果有）
-      - 重新計算 statistics 統計數據（pending, in_progress, blocked, completed, total）
-      - 更新 last_updated 時間戳
-    validation:
-      - 執行 JSON 語法驗證：node -e "JSON.parse(require('fs').readFileSync('dev/pipeline/TASK_QUEUE.json', 'utf8'))"
-      - 確保統計數據與實際任務狀態一致
-
-  2_move_task_file:
-    description: 將任務文件從 tasks/ 移動到 completed/
-    steps:
-      - 確認任務文件在 tasks/ 目錄存在
-      - 移動文件到 completed/ 目錄（保持文件名不變）
-      - 驗證文件成功移動（tasks/ 中已無該文件）
-      - 驗證文件在 completed/ 中存在
-    example: |
-      # PowerShell
-      Move-Item "dev/pipeline/tasks/TASK_XXX.yaml" "dev/pipeline/completed/"
-
-      # Bash
-      mv dev/pipeline/tasks/TASK_XXX.yaml dev/pipeline/completed/
-
-  3_update_progress:
-    description: 更新 PROGRESS.md 的進度記錄
-    steps:
-      - 更新 "Last Update" 區塊（時間、Agent、Action）
-      - 更新 "Current Queue Status" 統計數據
-      - 更新 "Pending Tasks" 列表（移除已完成任務）
-      - 更新 "Recently Completed" 列表（加入剛完成的任務）
-      - 新增 "Recent Activity" 記錄
-    validation:
-      - 確保 PROGRESS.md 的統計數據與 TASK_QUEUE.json 一致
-      - 確保無 Markdown 格式錯誤
-
-  4_verify_consistency:
-    description: 驗證 Pipeline 系統一致性
-    steps:
-      - 執行驗證腳本：.\dev\scripts\validate_pipeline.ps1
-      - 確保無錯誤輸出
-      - 如果有錯誤，執行自動修復：.\dev\scripts\fix_pipeline.ps1
-    mandatory: true
-    failure_action: "修復不一致後再 commit"
-
-enforcement:
-  who_must_follow:
-    - Developer Agent（單一任務開發）
-    - PM Lead（多任務並行整合，遵循 TEAM-002）
-    - Backend Team / Frontend Team（團隊模式開發）
-    - 所有完成任務的 Agent
-
-  when_to_apply:
-    - 任務完成並準備提交 Git commit 時
-    - PM Lead 整合多個團隊的成果時
-    - 手動標記任務為 completed 時
-
-  verification_timing:
-    - Git commit 前（pre-commit hook）
-    - 任務完成後立即執行
-    - 每日自動檢查（可選）
-
-violation_consequence:
-  immediate:
-    - Pipeline 不一致，進度追蹤錯誤
-    - 可能重複執行已完成任務
-    - 統計數據不準確，影響決策
-    - Git commit 被 pre-commit hook 阻止
-
-  long_term:
-    - 累積技術債，需要手動修復
-    - 團隊協作效率降低
-    - 用戶信任度下降（"Pipeline 常常不對"）
-
-automation:
-  validation_script: dev/scripts/validate_pipeline.ps1
-  fix_script: dev/scripts/fix_pipeline.ps1
-  git_hook: .git/hooks/pre-commit
-
-checklist:
-  title: "Pipeline 更新完成檢查清單"
-  items:
-    - label: "TASK_QUEUE.json 已更新任務 status 為 completed"
-      required: true
-    - label: "TASK_QUEUE.json 已填寫 completed_at, completed_by, git_commit"
-      required: true
-    - label: "TASK_QUEUE.json statistics 已更新"
-      required: true
-    - label: "TASK_QUEUE.json JSON 語法驗證通過"
-      required: true
-    - label: "任務文件已移動到 dev/pipeline/completed/"
-      required: true
-    - label: "tasks/ 目錄中已無該任務文件"
-      required: true
-    - label: "PROGRESS.md Last Update 已更新"
-      required: true
-    - label: "PROGRESS.md Statistics 已更新"
-      required: true
-    - label: "PROGRESS.md Pending Tasks 列表已更新"
-      required: true
-    - label: "PROGRESS.md Recently Completed 已加入"
-      required: true
-    - label: "validate_pipeline.ps1 驗證通過"
-      required: true
-    - label: "日誌已寫入 dev/pipeline/logs/"
-      required: false
-
-examples:
-  good_practice: |
-    # 完整的 Pipeline 更新流程範例
-
-    ## Step 1: 更新 TASK_QUEUE.json
-    ```json
-    {
-      "id": "TASK_XXX",
-      "status": "completed",  // ✓ 更新狀態
-      "completed_at": "2026-02-06T22:00:00+08:00",  // ✓ 填寫時間
-      "completed_by": "Developer Agent",  // ✓ 填寫執行者
-      "git_commit": "a1b2c3d"  // ✓ 填寫 commit hash
-    }
-
-    "statistics": {
-      "pending": 0,      // ✓ 重新計算
-      "completed": 10    // ✓ 增加 1
-    }
-
-    "last_updated": "2026-02-06T22:00:00+08:00"  // ✓ 更新時間
-    ```
-
-    ## Step 2: 移動文件
-    ```powershell
-    Move-Item "dev/pipeline/tasks/TASK_XXX.yaml" "dev/pipeline/completed/"
-    ```
-
-    ## Step 3: 更新 PROGRESS.md
-    ```markdown
-    ## Last Update
-    - **Time**: 2026-02-06 22:00
-    - **Agent**: Developer Agent
-    - **Action**: TASK_XXX 完成！...
-
-    ### Pending Tasks
-    無待處理任務  // ✓ 移除已完成任務
-
-    ### Recently Completed
-    | TASK_XXX | ... ✅ |  // ✓ 加入剛完成的任務
-    ```
-
-    ## Step 4: 驗證一致性
-    ```powershell
-    .\dev\scripts\validate_pipeline.ps1
-    # 輸出：✅ Pipeline 狀態完全一致！
-    ```
-
-    ## Step 5: Git Commit
-    ```bash
-    git add .
-    git commit -m "[TASK_XXX] 完成任務描述"
-    # pre-commit hook 自動驗證 Pipeline，通過後提交
-    ```
-
-  bad_practice: |
-    # ❌ 錯誤的做法（導致 Pipeline 不一致）
-
-    ## 錯誤 1: 只更新 PROGRESS.md，忘記 TASK_QUEUE.json
-    ```markdown
-    ## Last Update
-    - **Action**: TASK_XXX 完成！
-    ```
-
-    但 TASK_QUEUE.json 中 TASK_XXX 仍然是 "status": "pending"  ❌
-
-    ## 錯誤 2: 更新狀態但不移動文件
-    ```json
-    { "id": "TASK_XXX", "status": "completed" }  // ✓ 狀態更新
-    ```
-
-    但文件還在 tasks/ 目錄  ❌
-
-    ## 錯誤 3: 移動文件但不更新統計
-    ```powershell
-    Move-Item "tasks/TASK_XXX.yaml" "completed/"  // ✓ 文件移動
-    ```
-
-    但 statistics.completed 沒有增加  ❌
-
-    ## 錯誤 4: 直接 commit 不驗證
-    ```bash
-    git commit -m "完成"  # ❌ 沒有執行 validate_pipeline.ps1
-    ```
-
-    結果：Pipeline 不一致，用戶抱怨 "Pipeline 常常不對"
-
-prevention_tools:
-  automated_validation:
-    script: dev/scripts/validate_pipeline.ps1
-    description: 自動檢查 Pipeline 一致性
-    usage: |
-      # 基本驗證
-      .\dev\scripts\validate_pipeline.ps1
-
-      # 詳細模式
-      .\dev\scripts\validate_pipeline.ps1 -Detailed
-
-      # 自動修復
-      .\dev\scripts\validate_pipeline.ps1 -Fix
-
-  automated_fix:
-    script: dev/scripts/fix_pipeline.ps1
-    description: 自動修復 Pipeline 不一致
-    usage: |
-      # 執行修復
-      .\dev\scripts\fix_pipeline.ps1
-
-      # 模擬運行（不實際修改）
-      .\dev\scripts\fix_pipeline.ps1 -DryRun
-
-  git_hook:
-    file: .git/hooks/pre-commit
-    description: Git commit 前自動驗證 Pipeline
-    setup: |
-      # 建立 pre-commit hook
-      .\dev\scripts\setup_git_hooks.ps1
-
-related_failures:
-  - FAIL-003: TASK_QUEUE 污染問題
-  - 多次 Pipeline 不一致事件（2026-02-06 兩次）
-
-related_rules:
-  - PPL-002: 已完成任務必須封存到 .memory/
-  - TEAM-002: PM Lead 團隊成果整合規則
-  - AGT-005: 失敗時必須查閱失敗經驗
-
-maintenance:
-  review_frequency: 每月
-  next_review: 2026-03-06
-  effectiveness_metric: Pipeline 不一致事件發生次數（目標：0 次/月）
-
-notes: |
-  這個規則是從多次 Pipeline 不一致事件中總結出來的核心預防措施。
-
-  重要性：
-  - Critical 級別：違反此規則會導致整個 Pipeline 系統失效
-  - 必須嚴格執行，無例外
-
-  執行難度：
-  - 已提供自動化工具（validate, fix, git hook）
-  - 有明確的檢查清單
-  - 有詳細的範例
-
-  預期效果：
-  - 完全消除 Pipeline 不一致問題
-  - 提升團隊協作效率
-  - 增強用戶信任度

package/core/.rule/pipeline/task-execution.yaml

@@ -1,365 +0,0 @@
-# .rule/pipeline/task-execution.yaml
-# Pipeline 任務執行規則 - 定義完整的任務執行規範
-
-_meta:
-  category: "pipeline"
-  priority: 1  # 高優先級（僅次於核心原則）
-  applies_to:
-    - "ai_agent"
-    - "lead_agent"
-  last_updated: "2026-02-09"
-  description: |
-    定義 Lead Agent 和所有 Agent 執行 Pipeline 任務的標準流程。
-    涵蓋任務拆分、依賴管理、並行執行、Team 選擇等核心流程。
-
-rules:
-  # ======================================
-  # 任務拆分與粒度
-  # ======================================
-  - id: "PPL-101"
-    title: "任務拆分粒度標準"
-    description: |
-      任務應拆分為 15-20 分鐘可完成的單元。
-      拆分依據：
-      - 一個任務 = 一個功能點/組件/API/文檔
-      - 避免過大任務（> 1 小時）或過小任務（< 5 分鐘）
-      - 每個任務必須有明確的驗收標準
-    severity: "must"
-    rationale: |
-      適當粒度確保：
-      - 並行執行效率最大化
-      - 失敗範圍可控（易於重試）
-      - 進度追蹤準確
-    examples:
-      - good: "建立用戶登入 API - POST /api/auth/login"
-      - bad: "建立完整認證系統（太大）"
-      - bad: "修改變數名稱（太小，應合併到其他任務）"
-
-  # ======================================
-  # 依賴管理
-  # ======================================
-  - id: "PPL-102"
-    title: "依賴管理規則"
-    description: |
-      任務定義必須明確 dependencies 字段。
-      - 無依賴（dependencies: []）：立即執行
-      - 有依賴：等待依賴任務完成
-      - 依賴任務 ID 必須存在於 Pipeline
-    severity: "must"
-    rationale: "確保執行順序正確，避免前置條件未滿足"
-    examples:
-      - task: "TASK_002: 實現登入 API"
-        dependencies: ["TASK_001"]  # 依賴 TASK_001（資料庫架構）
-      - task: "TASK_003: 建立登入頁面"
-        dependencies: ["TASK_002"]  # 依賴 TASK_002（API）
-
-  # ======================================
-  # 並行執行
-  # ======================================
-  - id: "PPL-103"
-    title: "並行執行策略"
-    description: |
-      系統自動判斷可並行任務：
-      - 無依賴 + 無 scope_paths 衝突 → 可並行
-      - 有依賴或路徑衝突 → 順序執行
-
-      Lead Agent 職責：
-      - 識別可並行任務（dependencies: []）
-      - 檢查 scope_paths 衝突（PPL-111）
-      - 啟動多個 Agent 執行
-    severity: "should"
-    rationale: "最大化並行效率，縮短總執行時間"
-    examples:
-      - scenario: "3 個獨立 API 開發任務"
-        approach: "同時啟動 3 個 Backend Agent"
-      - scenario: "前端依賴後端 API"
-        approach: "先執行後端，再執行前端"
-
-  # ======================================
-  # Agent Type 命名規則
-  # ======================================
-  - id: "PPL-105"
-    title: "agent_type 命名規則"
-    description: |
-      任務定義中的 agent_type 字段命名規範：
-      - 直接使用 Agent 名稱（developer, strategy, backend 等）
-      - 必須與 .claude/skills/ 中的 Agent 名稱一致
-    severity: "must"
-    rationale: "確保 Lead Agent 能正確調用對應的 Team 或 Agent"
-    examples:
-      - correct: "agent_type: developer"  # 調用 Developer Agent
-      - correct: "agent_type: strategy"  # 調用 Strategy Agent
-      - incorrect: "agent_type: developer-agent"  # 錯誤格式（應用底線）
-
-  # ======================================
-  # Feature ID 自動分配
-  # ======================================
-  - id: "PPL-106"
-    title: "Feature ID 自動分配"
-    description: |
-      Lead Agent 拆分任務時：
-      - 為同一功能的任務分配相同 feature_id
-      - Feature ID 格式：F-XXX（3 位數字）
-      - 記錄於任務的 feature_ids 字段（陣列）
-
-      用途：
-      - 追蹤功能完整度
-      - 過濾相關任務
-      - 生成功能報告
-    severity: "must"
-    rationale: "實現功能級追蹤，而非僅任務級"
-    examples:
-      - feature: "F-016: 統一開發流程規範"
-        tasks:
-          - "TASK_147: 建立 task-execution.yaml"
-          - "TASK_148: 更新 Lead Agent Skill"
-          - "TASK_149: 建立測試案例"
-
-  # ======================================
-  # 工作啟動流程
-  # ======================================
-  - id: "PPL-107"
-    title: "工作啟動前展示計劃"
-    description: |
-      Lead Agent 開始執行前必須：
-      1. 讀取 F-XXX 文檔（如果指定）
-      2. 讀取所有相關 TASK_XXX.yaml
-      3. 分析任務範圍和依賴
-      4. **展示完整執行計劃給用戶**（含任務列表、優先級、並行策略）
-      5. 等待用戶確認
-      6. 開始執行
-    severity: "must"
-    rationale: |
-      防止誤解需求、避免不必要的工作、確保用戶對計劃有控制權
-    examples:
-      - good: |
-          Lead Agent: "分析完成，計劃執行 5 個任務：
-          - TASK_147 (P0): 建立規則文檔
-          - TASK_148 (P1): 更新 Lead Agent
-          - TASK_149 (P1): 建立測試
-
-          並行策略：147 和 149 可並行。
-
-          是否開始執行？"
-      - bad: "已讀取任務，開始執行。"  # 未展示計劃
-
-  # ======================================
-  # 任務失敗處理
-  # ======================================
-  - id: "PPL-108"
-    title: "任務失敗立即報告"
-    description: |
-      任務失敗時 Worker Agent 必須：
-      1. 立即停止後續步驟
-      2. 記錄失敗原因到日誌
-      3. 更新任務狀態為 blocked
-      4. 通知 Leader
-      5. 不可靜默失敗或繼續執行
-    severity: "must"
-    rationale: "早期發現問題，避免錯誤傳播，節省調試時間"
-    examples:
-      - failure_scenario: "API 測試失敗"
-        correct_action: |
-          1. 記錄失敗日誌
-          2. 更新 TASK_QUEUE.json: status=blocked
-          3. 通知 Leader Agent 任務已阻塞
-      - incorrect: "測試失敗但繼續建立 commit（錯誤傳播）"
-
-  # ======================================
-  # Git Commit 策略
-  # ======================================
-  - id: "PPL-109"
-    title: "階段性 Git Commit 策略"
-    description: |
-      Worker Agent 執行任務時：
-      - 完成一個階段 → 建立一次 commit
-      - Commit message 必須包含 [TASK_XXX] 標記
-      - 任務完成時至少產生 1 個 commit
-      - 允許多個 commit（對應不同階段）
-    severity: "must"
-    rationale: "提供可驗證的輸出，便於追蹤和回滾"
-    examples:
-      - single_commit: "[TASK_147] 建立 Pipeline 執行規則文檔"
-      - multiple_commits: |
-          - "[TASK_148] 更新 Lead Agent Skill - 新增 Stage 1-3"
-          - "[TASK_148] 更新 Lead Agent Skill - 新增 Stage 4-6"
-          - "[TASK_148] 更新 Lead Agent Skill - 新增範例和測試"
-
-  # ======================================
-  # 任務完成後續動作
-  # ======================================
-  - id: "PPL-110"
-    title: "任務完成後續動作"
-    description: |
-      Worker Agent 完成任務後自動執行：
-      1. 建立 Git commit（包含 [TASK_XXX]）
-      2. 更新 TASK_QUEUE.json: status=completed
-      3. 記錄執行日誌
-      4. 檢查是否有依賴此任務的其他任務（解除阻塞）
-
-      Leader Agent 檢測到完成後：
-      1. 驗證輸出（Git commit 存在）
-      2. 檢查驗收標準是否滿足
-      3. 啟動下一個任務（如果有）
-    severity: "must"
-    rationale: "自動化流程，確保 Pipeline 持續運行"
-
-  # ======================================
-  # Scope Paths 衝突檢測
-  # ======================================
-  - id: "PPL-111"
-    title: "scope_paths 衝突檢測"
-    description: |
-      Lead Agent 啟動任務前必須檢測：
-      - 讀取所有 in_progress 任務的 scope_paths
-      - 檢查新任務的 scope_paths 是否衝突
-      - 衝突定義：路徑重疊（包含或被包含）
-
-      衝突處理：
-      - 有衝突 → 等待衝突任務完成
-      - 無衝突 → 啟動新任務
-    severity: "must"
-    rationale: "防止多個 Agent 同時修改相同文件，避免 Git 衝突"
-    examples:
-      - conflict: |
-          - TASK_A: scope_paths: [".rule/pipeline/"]
-          - TASK_B: scope_paths: [".rule/pipeline/task-execution.yaml"]
-          → 衝突（B 包含在 A 中）
-      - no_conflict: |
-          - TASK_A: scope_paths: [".rule/pipeline/"]
-          - TASK_B: scope_paths: [".rule/general/"]
-          → 無衝突（路徑不重疊）
-
-  # ======================================
-  # 回歸保護（Regression Guard）
-  # ======================================
-  - id: "PPL-113"
-    title: "回歸保護 — Agent + Script 協作模型"
-    description: |
-      Agent 判斷要跑什麼測試，透過 --test-cmd 傳給 post-complete.js 執行。
-      腳本依序跑每組測試、記錄結果、處理閉環。
-
-      === 流程 ===
-      1. Agent 完成任務後，根據 scope_paths 和實際修改的檔案判斷需要哪些測試
-      2. Agent 透過 --test-cmd 參數傳給 post-complete.js（可多次指定）
-      3. 腳本依序執行每組測試，記錄結果
-      4. 全過 → 繼續 commit + merge
-      5. 有失敗 → 開 FIX 單（閉環），繼續 commit
-
-      === Agent 傳遞測試指令 ===
-      post-complete.js --task=TASK_XXX \
-        --test-cmd "node dev/scripts/rust-verify-worktree.js run <branch> <filter>"
-
-      如果 Agent 未傳 --test-cmd，腳本 fallback 到自動偵測所有可用測試套件。
-
-      === Agent 測試判斷指引 ===
-      - 修改 dashboard/src-tauri/ (Rust, kenaz-server) → --test-cmd "node dev/scripts/rust-verify-worktree.js run <branch> <filter>"（Dashboard 前端與 pty-server 已於 2026-10-11 移除）
-      - 修改 kenaz-cortex/ (Python) → --test-cmd "cd kenaz-cortex && pytest"
-      - 只修改 .yaml/.md/設定檔 → --skip-tests（無需測試）
-      - 修改多個子系統 → 多個 --test-cmd，分別指定
-
-      === 閉環機制（不阻塞 Pipeline）===
-      - 測試失敗時，腳本自動開 FIX 單（P1, tags: fix,regression）
-      - FIX 單含防重複機制（已有未解決 regression 單則跳過建立）
-      - 當前任務照常 commit + merge（不中止）
-      - FIX 單排入 backlog 等待下一輪執行
-
-      === 重要限制 ===
-      - 只跑已有的測試，不要求 Agent 額外寫測試
-      - Agent 判斷 + 腳本執行，兩者互補
-      - 失敗時記錄到執行日誌，不自動重試
-    severity: "must"
-    rationale: |
-      Agent 比腳本更了解上下文，能精準判斷需要哪些測試。
-      腳本負責可靠執行、結果收集、閉環處理。
-      Agent 忘記傳參時，auto-detect fallback 保底。
-      防止 Agent 完成 TASK_B 時意外破壞 TASK_A 的功能。
-    examples:
-      - scenario: "修改了 kenaz-server 的 Rust 與 plugin 的 JS"
-        action: |
-          Agent 判斷：改了 dashboard/src-tauri/ 和 plugins/kenaz/scripts/
-          → post-complete.js --task=TASK_XXX \
-              --test-cmd "node dev/scripts/rust-verify-worktree.js run <branch> peer" \
-              --test-cmd "node --test plugins/kenaz/scripts/kenaz.test.js"
-          → 腳本依序跑 2 組測試
-          → 全過 → 繼續 PPL-109 commit
-      - scenario: "只修改了 Python 後端 API"
-        action: |
-          Agent 判斷：只改了 kenaz-cortex/
-          → post-complete.js --task=TASK_XXX \
-              --test-cmd "cd kenaz-cortex && pytest"
-          → 全過 → 繼續
-      - scenario: "只修改了 .rule/ YAML 設定"
-        action: |
-          Agent 判斷：純設定檔，無對應測試
-          → post-complete.js --task=TASK_XXX --skip-tests
-      - scenario: "Agent 忘記傳 --test-cmd"
-        action: |
-          → post-complete.js --task=TASK_XXX（無 --test-cmd）
-          → 腳本 fallback：自動偵測所有測試套件
-          → 依序執行找到的測試
-
-  # ======================================
-  # 驗收標準驗證
-  # ======================================
-  - id: "PPL-112"
-    title: "驗收標準驗證"
-    description: |
-      Worker Agent 完成任務後：
-      - 讀取任務的 acceptance_criteria
-      - 逐項檢查是否滿足
-      - 在日誌中記錄驗證結果
-      - 只有全部滿足才標記為 completed
-
-      驗證方式：
-      - 文件存在性：檢查路徑
-      - Git commit：git log -1 --oneline | grep "[TASK_XXX]"
-      - 語法正確：執行語法檢查工具
-    severity: "must"
-    rationale: "確保任務輸出符合要求，提高品質"
-    examples:
-      - criteria: "README.md 已更新，包含新章節"
-        verification: |
-          1. 檢查文件存在: test -f README.md
-          2. 檢查內容: grep "新章節" README.md
-          3. 檢查 commit: git log -1 | grep "[TASK_XXX]"
-
-# ======================================
-# 快速參考
-# ======================================
-quick_reference:
-  lead_agent_checklist:
-    - "讀取 F-XXX 和所有 TASK_XXX.yaml"
-    - "分析任務、依賴、scope_paths"
-    - "展示執行計劃給用戶（PPL-107）"
-    - "等待用戶確認"
-    - "檢查 scope_paths 衝突（PPL-111）"
-    - "啟動 Agent 執行任務"
-    - "監控執行狀態"
-    - "驗證輸出（Git commit + 驗收標準）"
-
-  worker_agent_checklist:
-    - "讀取任務定義"
-    - "記錄階段日誌（想法、行動、結果）"
-    - "執行開發工作"
-    - "失敗時立即報告（PPL-108）"
-    - "執行回歸測試（PPL-113）"
-    - "完成時建立 commit（PPL-109）"
-    - "驗證驗收標準（PPL-112）"
-    - "更新 TASK_QUEUE.json: status=completed"
-
-  task_yaml_template:
-    id: "TASK_XXX"
-    title: "任務標題"
-    description: "詳細描述"
-    priority: "P0"  # P0/P1/P2/P3
-    status: "pending"  # pending/in_progress/completed/blocked
-    agent_type: "developer"  # Agent 名稱
-    source: "F-XXX"  # Feature ID
-    feature_ids: ["F-XXX"]  # 所屬功能
-    dependencies: []  # 依賴任務 ID
-    scope_paths: []  # 修改路徑
-    requirements: []  # 需求列表
-    acceptance_criteria: []  # 驗收標準
-    estimated_hours: 0.25
-    complexity: "simple"  # simple/medium/complex