npm - kenaz - Versions diffs - 0.3.22 → 0.3.24 - Mend

kenaz 0.3.22 → 0.3.24

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (474) hide show

package/core/dev/pipeline/WORKFLOW_GUIDE.md DELETED Viewed

@@ -1,824 +0,0 @@
-# Pipeline Workflow Guide
-# Pipeline 完整使用指南
-> **版本**: 1.0.0
-> **最後更新**: 2026-02-09
-> **相關規則**: `.rule/pipeline/task-execution.yaml` (PPL-101 至 PPL-112)
----
-## 📑 目錄
-- [概述](#概述)
-- [核心概念](#核心概念)
-- [完整工作流程](#完整工作流程)
-- [任務卡模板](#任務卡模板)
-- [實際範例](#實際範例)
-- [最佳實踐](#最佳實踐)
-- [常見問題 FAQ](#常見問題-faq)
-- [參考文檔](#參考文檔)
----
-## 概述
-Pipeline 系統是 KenazAI 專案的任務管理與執行系統，支援：
-- ✅ **任務拆分**：將大型功能拆分為 15-20 分鐘可完成的小任務
-- ✅ **依賴管理**：自動處理任務間的依賴關係
-- ✅ **並行執行**：無衝突任務自動並行，提升效率
-- ✅ **Team 模式**：支援 Leader + Workers 團隊協作
-- ✅ **自動化**：任務完成後自動更新狀態、啟動下一個任務
-- ✅ **Git 整合**：每個任務至少產生 1 個 commit
-### 目錄結構
-```
-dev/pipeline/
-├── WORKFLOW_GUIDE.md          # 📘 本文檔（完整使用指南）
-├── README.md                  # 📄 簡介與快速開始
-├── PROGRESS.md                # 📊 進度追蹤
-├── TASK_QUEUE.json            # 🗂️ 任務佇列（所有任務狀態）
-├── PIPELINE_CONFIG.json       # ⚙️ Pipeline 配置
-├── tasks/                     # 📋 待處理任務卡
-│   ├── TASK_147_*.yaml
-│   ├── TASK_148_*.yaml
-│   └── ...
-├── completed/                 # ✅ 已完成任務（封存）
-└── logs/                      # 📝 執行日誌
-```
----
-## 核心概念
-### 1. 任務粒度（PPL-101）
-**標準**：每個任務應在 15-20 分鐘內完成。
-| 粒度 | 說明 | 範例 |
-|------|------|------|
-| ✅ **適當** | 15-20 分鐘 | 建立單一 API 端點、實現一個組件、更新一份文檔 |
-| ❌ **過大** | > 1 小時 | 「建立完整認證系統」（應拆分為 5+ 個任務） |
-| ❌ **過小** | < 5 分鐘 | 「修改變數名稱」（應合併到其他任務） |
-**拆分原則**：
-- 一個任務 = 一個功能點/組件/API/文檔
-- 每個任務必須有明確的驗收標準
-- 避免跨多個模組的大任務
-### 2. agent_type 命名（PPL-105）
-決定任務由誰執行：
-| agent_type | 說明 | 調用方式 |
-|-----------|------|---------|
-| `developer_team` | Developer Team（多角色） | Formation 系統調度 |
-| `developer` | 單一 Developer Agent | 主 session 執行 |
-| `strategy_team` | Strategy Team（策略分析） | Formation 系統調度 |
-| `strategy` | 單一 Strategy Agent | 主 session 執行 |
-**選擇規則**（PPL-104）：
-- **預設使用 Team 模式**（`xxx_team`）
-- 只在極簡單任務（< 10 分鐘）時使用單一 Agent
-### 3. 依賴管理（PPL-102）
-任務間的依賴關係：
-```yaml
-# TASK_148 依賴 TASK_147
-dependencies:
-  - "TASK_147"  # 必須等待 TASK_147 完成
-```
-**依賴規則**：
-- 無依賴（`dependencies: []`）→ 立即執行
-- 有依賴 → 等待依賴任務完成
-- 系統自動檢查依賴是否滿足
-### 4. 並行執行（PPL-103）
-**並行條件**：
-- 無依賴關係
-- 無 `scope_paths` 衝突
-**範例**：
-```yaml
-# 可並行（不同文件）
-TASK_A: scope_paths: ["CLAUDE.md"]
-TASK_B: scope_paths: ["docs/workflows/"]
-# 不可並行（路徑衝突）
-TASK_A: scope_paths: [".rule/pipeline/"]
-TASK_B: scope_paths: [".rule/pipeline/task-execution.yaml"]  # 包含在 A 中
-```
----
-## 完整工作流程
-### Lead Agent 12 步流程
-**參考**：CLAUDE.md - Lead Agent 開發流程
-```
-Stage 1-3: 需求分析與拆分
-    ↓
-1. 接收用戶需求
-2. 自動分配 Feature ID (F-XXX)
-3. 拆分任務（15-20 分鐘）
-    ↓
-Stage 4-6: 執行規劃
-    ↓
-4. 判斷 agent_type（Team 優先）
-5. 分析依賴與路徑衝突
-6. 規劃 commit 策略
-    ↓
-Stage 7-9: 展示計劃與執行
-    ↓
-7. 展示計劃給用戶 ⭐
-8. 等待用戶確認
-9. 建立任務卡（YAML）
-    ↓
-Stage 10-12: 執行與監控
-    ↓
-10. 啟動執行（Team 或單一 Agent）
-11. 監控與自動化
-12. 失敗處理
-```
-### Worker Agent 執行流程
-```
-Worker Agent 開始執行
-    ↓
-1. 讀取任務定義（TASK_XXX.yaml）
-2. 記錄執行過程到日誌
-3. 執行開發工作
-4. 驗證驗收標準（PPL-112）
-    ↓
-5. 建立 Git Commit（PPL-109）
-    - Commit message: [TASK_XXX] 描述
-    - 至少 1 個 commit
-    ↓
-6. 更新任務狀態
-    - TASK_QUEUE.json: status="completed"
-    - 記錄 completed_at, git_commit
-    ↓
-7. 記錄執行日誌
-    - type: COMPLETE
-    - 包含 commit hash
-```
----
-## 任務卡模板
-### 標準 YAML 模板
-```yaml
-# TASK_XXX: 任務標題
-# Schema: dev/schemas/TASK.schema.json
-id: "TASK_XXX"
-title: "任務標題（簡短描述）"
-description: |
-  詳細描述任務內容、背景、目標。
-  背景：
-  - 說明為什麼需要這個任務
-  - 當前狀況與問題
-  目標：
-  - 清楚說明要達成什麼
-  - 具體的輸出或成果
-priority: "P0"  # P0（最高）/ P1 / P2 / P3（最低）
-status: "pending"  # pending / in_progress / completed / blocked / cancelled
-agent_type: "developer_team"  # xxx_team（Team 模式）或 xxx（單一 Agent）
-source: "F-XXX"  # 來源 Feature ID
-feature_ids:
-  - "F-XXX"  # 所屬功能
-dependencies:
-  - "TASK_YYY"  # 依賴的任務 ID（可選）
-  - "TASK_ZZZ"
-scope_paths:
-  - "路徑/文件1"  # 會修改的文件或目錄
-  - "路徑/文件2"
-requirements:
-  - "需求 1：清楚描述要做什麼"
-  - "需求 2：可驗證的具體需求"
-  - "需求 3：..."
-acceptance_criteria:
-  - "驗收標準 1：可測試的標準"
-  - "驗收標準 2：明確的成功條件"
-  - "驗收標準 3：..."
-technical_notes:
-  - "技術說明 1：實現細節或注意事項"
-  - "技術說明 2：參考文檔或範例"
-estimated_hours: 0.33  # 預估時數（20 分鐘 = 0.33）
-complexity: "simple"  # simple / medium / complex
-related_tasks:
-  - "TASK_AAA"  # 相關任務（可選）
-  - "TASK_BBB"
-metadata:
-  created_at: "2026-02-09T20:00:00+08:00"
-  created_by: "Lead Agent"
-  discussion_summary: "簡短總結"
-```
-### 快速模板（最小化版本）
-```yaml
-id: "TASK_XXX"
-title: "任務標題"
-description: "詳細描述"
-priority: "P1"
-status: "pending"
-agent_type: "developer_team"
-source: "F-XXX"
-feature_ids: ["F-XXX"]
-dependencies: []
-scope_paths: ["路徑"]
-requirements:
-  - "需求 1"
-acceptance_criteria:
-  - "驗收標準 1"
-estimated_hours: 0.33
-complexity: "simple"
-```
----
-## 實際範例
-### 範例 1：簡單任務（單一文件修改）
-**場景**：修復 README 中的錯字
-**任務卡**：
-```yaml
-id: "TASK_200"
-title: "修復 README 錯字與格式"
-description: |
-  修復 README.md 中的拼字錯誤和格式問題。
-  背景：
-  - 用戶回報 README 有多處錯字
-  - 標題格式不一致
-  目標：
-  - 修正所有拼字錯誤
-  - 統一標題格式
-priority: "P3"
-status: "pending"
-agent_type: "developer"  # 簡單任務，使用單一 Agent
-source: "Bug Report"
-feature_ids: ["F-020"]
-dependencies: []
-scope_paths:
-  - "README.md"
-requirements:
-  - "修正拼字錯誤（至少 5 處）"
-  - "統一標題格式（使用 ## 和 ###）"
-  - "檢查連結有效性"
-acceptance_criteria:
-  - "README.md 無拼字錯誤"
-  - "標題格式統一"
-  - "所有連結可正常訪問"
-estimated_hours: 0.08  # 5 分鐘
-complexity: "simple"
-```
-**執行流程**：
-```bash
-# 1. Lead Agent 建立任務卡
-# 2. 單一 Developer Agent 執行（主 session）
-# 3. 修改 README.md
-# 4. 建立 commit
-git commit -m "[TASK_200] 修復 README 錯字與格式
-- 修正 5 處拼字錯誤
-- 統一標題格式
-- 檢查所有連結
-Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>"
-# 5. 更新 TASK_QUEUE.json: status="completed"
-```
-**執行時間**：5 分鐘
----
-### 範例 2：複雜任務（搜尋功能改進）
-**場景**：改進統一文檔系統的搜尋功能，支援規則 ID 搜尋
-**任務拆分**（依賴鏈）：
-```yaml
-# TASK_151: 分析當前搜尋邏輯
-id: "TASK_151"
-title: "分析當前搜尋邏輯缺陷"
-description: |
-  分析統一文檔系統的搜尋邏輯，找出無法搜尋規則 ID 的原因。
-priority: "P0"
-agent_type: "developer_team"
-source: "F-017"
-dependencies: []
-scope_paths:
-  - "kenaz-cortex/src/docs/search.py"
-estimated_hours: 0.25
-```
-```yaml
-# TASK_152: 設計規則 ID 搜尋方案
-id: "TASK_152"
-title: "設計規則 ID 搜尋方案"
-description: |
-  設計支援規則 ID 搜尋的方案（如 GEN-007, AGT-005）。
-priority: "P0"
-agent_type: "developer_team"
-source: "F-017"
-dependencies: ["TASK_151"]  # 依賴 TASK_151
-scope_paths:
-  - "kenaz-cortex/docs/design/search_enhancement.md"
-estimated_hours: 0.33
-```
-```yaml
-# TASK_153: 實現 YAML 深度解析
-id: "TASK_153"
-title: "實現 YAML 深度解析"
-description: |
-  實現 YAML 深度解析，提取嵌套的規則 ID（rules[].id）。
-priority: "P0"
-agent_type: "developer_team"
-source: "F-017"
-dependencies: ["TASK_152"]  # 依賴 TASK_152
-scope_paths:
-  - "kenaz-cortex/src/docs/parser.py"
-estimated_hours: 0.42
-```
-**執行流程**：
-```
-用戶需求: "改進搜尋功能，支援規則 ID 搜尋"
-    ↓
-Lead Agent 分析與拆分
-    ├─ Feature ID: F-017
-    ├─ 拆分為 3 個任務
-    └─ 建立依賴鏈: 151 → 152 → 153
-    ↓
-展示計劃給用戶
-    ↓
-用戶確認 "好，開始"
-    ↓
-執行 TASK_151（分析）
-    - Developer Team 執行
-    - 產生分析報告
-    - Git commit: abc1234
-    ↓
-TASK_151 完成 → 自動啟動 TASK_152（設計）
-    - Developer Team 執行
-    - 產生設計文檔
-    - Git commit: def5678
-    ↓
-TASK_152 完成 → 自動啟動 TASK_153（實現）
-    - Backend Team 執行
-    - 實現代碼 + 測試
-    - Git commit: ghi9012
-    ↓
-F-017 完成！
-總執行時間: ~1 小時（順序執行，因為有依賴）
-總 Git commits: 3 個
-```
----
-### 範例 3：並行任務（多文檔更新）
-**場景**：更新多個文檔系統，互不依賴
-**任務拆分**（並行執行）：
-```yaml
-# TASK_160: 更新 .rule 文檔
-id: "TASK_160"
-title: "更新 .rule 規則文檔"
-description: "新增最新規則到 .rule/INDEX.yaml"
-priority: "P1"
-agent_type: "developer_team"
-source: "F-018"
-dependencies: []  # 無依賴
-scope_paths:
-  - ".rule/INDEX.yaml"
-  - ".rule/pipeline/"
-estimated_hours: 0.25
-```
-```yaml
-# TASK_161: 更新 Formation 文檔
-id: "TASK_161"
-title: "更新 Formation 系統文檔"
-description: "更新 Agent 協作流程說明"
-priority: "P1"
-agent_type: "developer_team"
-source: "F-018"
-dependencies: []  # 無依賴
-scope_paths:
-  - ".formation/"
-estimated_hours: 0.25
-```
-**執行流程**：
-```
-用戶需求: "更新所有系統文檔"
-    ↓
-Lead Agent 分析
-    ├─ 拆分為 2 個任務
-    ├─ TASK_160: scope_paths: [".rule/"]
-    ├─ TASK_161: scope_paths: [".formation/"]
-    └─ 無路徑衝突！→ 可並行執行 ✅
-    ↓
-展示計劃
-    - 並行策略：160 和 161 同時執行
-    ↓
-用戶確認
-    ↓
-並行啟動
-    ├─ 啟動 TASK_160（Developer Team 1）
-    └─ 啟動 TASK_161（Developer Team 2）
-    ↓
-同時執行（背景）
-    ├─ Team 1: 更新 .rule 文檔
-    └─ Team 2: 更新 .formation 文檔
-    ↓
-兩個任務都完成
-    ├─ Git commit: abc1234 (TASK_160)
-    └─ Git commit: def5678 (TASK_161)
-    ↓
-F-018 完成！
-總執行時間: ~15 分鐘（並行執行，非 30 分鐘）
-總 Git commits: 2 個
-```
-**效率提升**：
-- 順序執行：25 + 25 = 50 分鐘
-- 並行執行：max(25, 25) = 25 分鐘
-- **節省 50%** 時間！
----
-## 最佳實踐
-### 1. 任務拆分
-✅ **好的拆分**：
-- 每個任務 15-20 分鐘
-- 單一職責（一個功能點）
-- 明確的驗收標準
-- 獨立可測試
-❌ **不好的拆分**：
-- 任務過大（> 1 小時）
-- 跨多個模組
-- 驗收標準模糊
-- 依賴過多
-**範例對比**：
-```yaml
-# ❌ 不好：任務過大
-id: "TASK_BAD"
-title: "建立完整認證系統"
-estimated_hours: 8  # 太大！
-# ✅ 好：拆分為多個任務
-id: "TASK_GOOD_1"
-title: "建立用戶註冊 API"
-estimated_hours: 0.33
-id: "TASK_GOOD_2"
-title: "建立用戶登入 API"
-estimated_hours: 0.33
-id: "TASK_GOOD_3"
-title: "建立 JWT Token 驗證"
-estimated_hours: 0.25
-```
-### 2. agent_type 選擇
-**決策樹**：
-```
-任務複雜度？
-  ├─ < 10 分鐘 → developer（單一 Agent）
-  └─ > 15 分鐘 → developer_team（Team 模式）✅
-```
-**Team 模式優先**（PPL-104）：
-- ✅ API 開發
-- ✅ UI 組件
-- ✅ 功能實現
-- ✅ P0/P1 高優先級任務
-**單一 Agent 可用**：
-- ✅ 文檔小修改
-- ✅ 變數重命名
-- ✅ 簡單 Bug 修復（< 10 分鐘）
-### 3. 依賴管理
-✅ **清楚的依賴**：
-```yaml
-# 清楚標示依賴關係
-TASK_152:
-  dependencies: ["TASK_151"]  # 必須等待 151
-```
-✅ **避免循環依賴**：
-```yaml
-# ❌ 錯誤：循環依賴
-TASK_A: dependencies: ["TASK_B"]
-TASK_B: dependencies: ["TASK_A"]  # 循環！
-```
-✅ **最小化依賴**：
-```yaml
-# 只標示直接依賴，不需要標示傳遞依賴
-TASK_153:
-  dependencies: ["TASK_152"]  # 只需標示 152
-  # 不需要標示 151（通過 152 已傳遞）
-```
-### 4. scope_paths 管理
-✅ **明確路徑**：
-```yaml
-scope_paths:
-  - "CLAUDE.md"  # 具體文件
-  - "docs/workflows/LEAD_AGENT_12_STEPS.md"  # 具體文件
-```
-✅ **目錄級別**（當修改多個文件時）：
-```yaml
-scope_paths:
-  - ".rule/pipeline/"  # 整個目錄
-```
-❌ **避免過於寬泛**：
-```yaml
-scope_paths:
-  - "."  # ❌ 太寬泛！
-  - "src/"  # ❌ 太大！
-```
-### 5. Git Commit 策略
-✅ **每個任務至少 1 個 commit**（PPL-109）：
-```bash
-git commit -m "[TASK_148] 更新 CLAUDE.md - 新增 Lead Agent 開發流程"
-```
-✅ **允許多個階段性 commits**：
-```bash
-git commit -m "[TASK_150] 建立 WORKFLOW_GUIDE.md - 新增核心概念"
-git commit -m "[TASK_150] 建立 WORKFLOW_GUIDE.md - 新增 3 個範例"
-git commit -m "[TASK_150] 建立 WORKFLOW_GUIDE.md - 新增 FAQ"
-```
-✅ **Commit message 格式**：
-```
-[TASK_XXX] 簡短描述（< 50 字元）
-- 詳細說明 1
-- 詳細說明 2
-Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
-```
----
-## 常見問題 FAQ
-### Q1: 如何決定任務拆分粒度？
-**A**: 使用「15-20 分鐘規則」（PPL-101）。
-**判斷方法**：
-1. 任務能否在 1 次 Agent 執行中完成？
-2. 任務是否只做一件事（單一職責）？
-3. 任務是否有明確的驗收標準？
-**範例**：
-- ✅ 好：「建立用戶登入 API - POST /api/auth/login」（20 分鐘）
-- ❌ 太大：「建立完整認證系統」（應拆分為 5+ 個任務）
-- ❌ 太小：「修改變數名稱」（應合併到其他任務）
----
-### Q2: 何時使用 Team 模式 vs 單一 Agent？
-**A**: **預設使用 Team 模式**（PPL-104），除非任務極簡單。
-**使用 Team 模式**（`xxx_team`）：
-- ✅ 複雜功能開發（> 15 分鐘）
-- ✅ 需要多角色分工（開發 + 測試 + 文檔）
-- ✅ P0/P1 高優先級任務
-- ✅ 需要審查機制的代碼
-**使用單一 Agent**（`xxx`）：
-- ✅ 簡單任務（< 10 分鐘）
-- ✅ 文檔小修改
-- ✅ 變數重命名
-- ✅ P3 低優先級小任務
-**對比**：
-| 場景 | 單一 Agent | Team 模式 |
-|------|-----------|----------|
-| 速度 | 快（順序執行） | 慢（分工協作） |
-| 品質 | 單一視角 | 多角色審查 ⭐ |
-| 文檔 | 可能遺漏 | 專職文檔專家 ⭐ |
-| 測試 | 事後考慮 | 專職測試工程師 ⭐ |
-**參考**：`.formation/` - agent_type 與陣型配置
----
-### Q3: 如何處理任務失敗？
-**A**: 遵循 PPL-108 規則，立即停止並報告。
-**Worker Agent 必須**：
-1. 立即停止後續步驟
-2. 記錄失敗原因到日誌
-3. 更新任務狀態為 `blocked`
-4. 通知 Leader（透過團隊日誌）
-5. **不可靜默失敗或繼續執行**
-**範例**：
-```bash
-# 1. 記錄失敗到執行日誌
-echo "[$(date '+%H:%M:%S')] ⚠️ 問題: 驗收標準未滿足" >> .formation/logs/*.log
-# 2. 更新狀態
-# TASK_QUEUE.json: status="blocked"
-# 3. 通知 Leader（透過日誌或結構化輸出）
-```
-**Leader Agent 處理**：
-1. 讀取失敗日誌
-2. 分析失敗原因
-3. 決定：重試 / 跳過 / 調整計劃
-4. 向用戶報告
-**參考**：`.rule/pipeline/task-execution.yaml` (PPL-108)
----
-### Q4: 如何管理依賴關係？
-**A**: 使用 `dependencies` 字段明確標示（PPL-102）。
-**基本規則**：
-- 無依賴：`dependencies: []` → 立即執行
-- 有依賴：`dependencies: ["TASK_XXX"]` → 等待完成
-- 系統自動檢查依賴是否滿足
-**最佳實踐**：
-1. **只標示直接依賴**（不需傳遞依賴）
-   ```yaml
-   TASK_153:
-     dependencies: ["TASK_152"]  # 只需標示 152
-     # 不需要標示 151（通過 152 已傳遞）
-   ```
-2. **避免循環依賴**
-   ```yaml
-   # ❌ 錯誤
-   TASK_A: dependencies: ["TASK_B"]
-   TASK_B: dependencies: ["TASK_A"]
-   ```
-3. **最小化依賴數量**
-   ```yaml
-   # ✅ 好：單一依賴
-   dependencies: ["TASK_147"]
-   # ❌ 不好：過多依賴
-   dependencies: ["TASK_A", "TASK_B", "TASK_C", "TASK_D"]
-   ```
-**檢查工具**（未來）：
-```bash
-# 檢查依賴鏈
-python dev/pipeline/orchestrator/dependency_resolver.py --check
-```
----
-### Q5: 如何判斷任務可並行？
-**A**: 檢查兩個條件（PPL-103, PPL-111）：
-**並行條件**：
-1. ✅ 無依賴關係（`dependencies: []`）
-2. ✅ 無 `scope_paths` 衝突
-**衝突檢測**：
-```yaml
-# ✅ 無衝突（可並行）
-TASK_A: scope_paths: ["CLAUDE.md"]
-TASK_B: scope_paths: ["docs/workflows/"]
-→ 路徑不重疊 ✅
-# ❌ 有衝突（不可並行）
-TASK_A: scope_paths: [".rule/pipeline/"]
-TASK_B: scope_paths: [".rule/pipeline/task-execution.yaml"]
-→ B 包含在 A 中 ❌
-```
-**Lead Agent 檢測邏輯**：
-```javascript
-function canParallel(taskA, taskB) {
-  // 1. 檢查依賴
-  if (taskA.dependencies.includes(taskB.id)) return false;
-  if (taskB.dependencies.includes(taskA.id)) return false;
-  // 2. 檢查路徑衝突
-  for (const pathA of taskA.scope_paths) {
-    for (const pathB of taskB.scope_paths) {
-      if (pathB.startsWith(pathA) || pathA.startsWith(pathB)) {
-        return false;  // 路徑重疊
-      }
-    }
-  }
-  return true;  // 可並行 ✅
-}
-```
-**效率提升範例**：
-```
-順序執行：TASK_A (20 分鐘) → TASK_B (20 分鐘) = 40 分鐘
-並行執行：TASK_A (20 分鐘) ‖ TASK_B (20 分鐘) = 20 分鐘
-節省 50% 時間！
-```
----
-## 參考文檔
-### 規則與指南
-| 文檔 | 路徑 | 說明 |
-|------|------|------|
-| **Pipeline 執行規則** | `.rule/pipeline/task-execution.yaml` | PPL-101 至 PPL-112，核心規則 |
-| **Lead Agent 流程** | `CLAUDE.md` | 完整 12 步開發流程 |
-| **Formation 系統** | `.formation/` | agent_type 與陣型配置 |
-### 規則索引（PPL-XXX）
-| 規則 ID | 標題 | 說明 |
-|---------|------|------|
-| PPL-101 | 任務拆分粒度標準 | 15-20 分鐘可完成 |
-| PPL-102 | 依賴管理規則 | dependencies 字段 |
-| PPL-103 | 並行執行策略 | 無依賴 + 無路徑衝突 |
-| PPL-104 | Team 優先原則 | 預設使用 xxx_team |
-| PPL-105 | agent_type 命名規則 | developer vs developer_team |
-| PPL-106 | Feature ID 自動分配 | F-XXX 格式 |
-| PPL-107 | 工作啟動前展示計劃 | 必須等待用戶確認 ⭐ |
-| PPL-108 | 任務失敗立即報告 | 不可靜默失敗 |
-| PPL-109 | 階段性 Git Commit 策略 | 至少 1 個 commit |
-| PPL-110 | 任務完成後續動作 | 自動化流程（6 步驟） |
-| PPL-111 | scope_paths 衝突檢測 | 防止並行衝突 |
-| PPL-112 | 驗收標準驗證 | 完成前必須驗證 |
-完整規則定義：`.rule/pipeline/task-execution.yaml`
----
-**版本歷史**：
-- **1.0.0** (2026-02-09): 初始版本，整合 TASK_147-149 內容
-**貢獻者**：Developer Team Worker
-**相關任務**：TASK_147, TASK_148, TASK_149