kenaz 0.3.22 → 0.3.23

package/core/.kenaz/main-memory/kenaz/pipeline/003_feature_id_system.md

@@ -1,46 +0,0 @@
-# Feature ID System - 功能 ID 系統
-
-**記憶 ID**: kenaz/pipeline/003
-**類型**: Naming Convention
-**標籤**: #pipeline #feature-id #ppl-106
-**建立時間**: 2026-02-10
-**規則來源**: PPL-106
-
----
-
-## 命名格式
-
-**F-XXX**（3 位數字）
-
-範例：
-- F-001: 用戶認證系統
-- F-016: 統一開發流程規範
-- F-017: 記憶系統建立
-
-## 自動分配流程
-
-1. 檢查現有 Feature ID（避免重複）
-2. 分配新 ID（遞增）
-3. 記錄 Feature 概述到 `dev/features/F-XXX.md`
-
-## Feature 文檔結構
-
-```markdown
-# F-XXX: 功能名稱
-
-## 概述
-...
-
-## 任務列表
-- TASK_147: ...
-- TASK_148: ...
-
-## 相關文檔
-- PRD: docs/prd/xxx.md
-- 設計稿: docs/design/xxx.md
-```
-
-## 參考
-
-- `.rule/pipeline/task-execution.yaml` - PPL-106
-- `dev/features/` - Feature 文檔目錄

package/core/.kenaz/main-memory/kenaz/rules/001_gen_007_self_containment.md

@@ -1,108 +0,0 @@
-# GEN-007: Project Self-Containment - 專案自包含原則
-
-**記憶 ID**: kenaz/rules/001
-**類型**: Critical Rule
-**標籤**: #rules #gen-007 #kenaz-ai #critical
-**建立時間**: 2026-02-10
-**適用於**: 所有使用 Kenaz AI 的專案
-**嚴重程度**: 🔴 MUST（必須遵守）
-
----
-
-## 規則定義
-
-**所有操作必須在專案資料夾內進行**
-
-這是 Kenaz AI 系統的核心原則，確保專案的可移植性和可追蹤性。
-
-## 規則內容
-
-### 1. 所有輸出必須在專案內
-
-**正確**：
-```bash
-# 日誌寫入專案內
-.formation/logs/solo/session_001.log
-
-# 狀態文件在專案內
-dev/pipeline/TASK_QUEUE.json
-```
-
-**錯誤**：
-```bash
-# ❌ 日誌在系統 temp 目錄
-C:\Users\User\AppData\Local\Temp\agent_output.log
-
-# ❌ 使用外部工具產生的輸出在專案外
-```
-
-### 2. 所有狀態必須在專案內
-
-**狀態文件**：
-- `dev/pipeline/TASK_QUEUE.json` - 任務佇列
-- `dev/pipeline/LOCK_STATE.json` - 路徑鎖定狀態
-- `.kenaz/docs/registry.json` - 文檔註冊表
-
-### 3. 所有配置必須在專案內
-
-**配置文件**：
-- `dev/pipeline/PIPELINE_CONFIG.json` - Pipeline 配置
-- `.kenaz/cortex.yaml` - RAG 引擎配置
-
-### 4. 所有日誌必須在專案內
-
-**日誌結構**：
-```
-.formation/logs/
-├── solo/                # 單 Agent 日誌
-├── squad/               # Squad 陣型日誌
-├── legion/              # Legion 陣型日誌
-└── unit/                # Unit 陣型日誌
-```
-
-## 實際應用
-
-### Formation System 遵循 GEN-007
-
-| 要求 | 實現方式 |
-|------|---------|
-| 日誌在專案內 | `.formation/logs/` |
-| 狀態在專案內 | 專案內狀態文件 |
-| 背景執行輸出在專案內 | 輸出重定向到專案日誌 |
-| 專案可移植性 | 複製專案即可運行 |
-
-### 調用工具遵循 GEN-007
-
-**正確方式**：
-```bash
-# 使用專案內工具，輸出在專案內
-node .formation/tools/runner.js --formation solo --task TASK_113
-```
-
-**錯誤方式**：
-```bash
-# ❌ 輸出在專案外
-# 輸出位置: C:\Users\User\AppData\Local\Temp\...
-```
-
-## 違反後果
-
-**違反 GEN-007 會導致**：
-- ❌ 專案無法移植到其他機器
-- ❌ 無法追蹤執行歷史
-- ❌ 無法恢復失敗狀態
-- ❌ 團隊成員無法協作
-
-## 檢查清單
-
-執行操作前檢查：
-
-- [ ] 日誌文件路徑是否在專案內？
-- [ ] 狀態文件路徑是否在專案內？
-- [ ] 使用的工具是否符合 GEN-007？
-- [ ] 背景執行的輸出是否重定向到專案內？
-- [ ] 專案複製到其他機器後是否仍可運行？
-
-## 參考文檔
-
-- `.rule/general/project-self-containment.yaml` - 規則定義

package/core/.kenaz/main-memory/kenaz/rules/001_rule_priority_system.md

@@ -1,121 +0,0 @@
-# 規則優先級系統
-
-**ID**: KNZ-RULES-001
-**分類**: rules
-**標籤**: #rule-priority #conflict-resolution #governance
-
-## 核心概念
-
-Kenaz AI 使用分層規則系統，當規則衝突時以高優先級為準。
-
-## 優先級順序
-
-| 優先級 | 來源 | 說明 |
-|-------|------|------|
-| 1 (最高) | `.rule/` | 專案核心規則，所有人必須遵守 |
-| 2 | `CLAUDE.md` | 專案級指令與工作流程 |
-| 3 | `.claude/skills/` | Agent 行為定義 |
-| 4 | `.agents/skills/` | 外部安裝的最佳實踐 |
-
-## 規則載入流程
-
-### 1. 讀取規則索引
-```bash
-cat .rule/INDEX.yaml
-```
-
-### 2. 按優先級載入規則
-```yaml
-rules:
-  - id: GEN-001
-    priority: 1
-    category: general
-    file: .rule/general/principles.yaml
-
-  - id: GEN-007
-    priority: 1
-    category: general
-    file: .rule/general/project-self-containment.yaml
-```
-
-### 3. 衝突解決
-當兩個規則衝突時：
-1. 比較優先級數字（1 > 2 > 3 > 4）
-2. 相同優先級時，檢查規則類別（general > pipeline）
-3. 相同類別時，後定義的規則覆蓋先定義的
-
-## 關鍵規則範例
-
-### GEN-007: 專案自包含原則
-```yaml
-id: GEN-007
-title: "專案自包含原則"
-priority: 1
-description: "所有操作必須在專案資料夾內進行"
-
-requirements:
-  - 日誌文件在專案內
-  - 狀態文件在專案內
-  - 背景 agent 輸出在專案內
-  - 專案可移植性（複製即可運行）
-
-violations:
-  - 使用外部 temp 目錄
-  - 依賴外部配置
-  - 輸出到系統目錄
-```
-
-## 規則升級機制
-
-### 從失敗到規則
-```
-失敗發生 → 記錄到 .failure/
-    ↓
-重複發生（>2 次）
-    ↓
-提升為 .rule/ 規則
-    ↓
-成為強制約束
-```
-
-### 升級標準
-1. **重複性**：失敗模式重複發生 >2 次
-2. **影響範圍**：影響多個 Agent 或功能
-3. **嚴重程度**：Critical 或 High 級別
-4. **可預防性**：可通過規則預防
-
-## 規則文件結構
-
-```yaml
-id: "XXX-001"
-title: "規則標題"
-priority: 1
-category: "general|team|pipeline|code"
-tags: ["tag1", "tag2"]
-
-description: |
-  規則的詳細說明
-
-requirements:
-  - 需求 1
-  - 需求 2
-
-violations:
-  - 違規情況 1
-  - 違規情況 2
-
-examples:
-  good:
-    - 正確範例 1
-  bad:
-    - 錯誤範例 1
-
-related_rules:
-  - GEN-001
-  - TEAM-001
-```
-
-## 參考資料
-
-- `.rule/INDEX.yaml` - 規則索引
-- `.rule/general/principles.yaml` - 核心原則

package/core/.kenaz/main-memory/kenaz/rules/003_ppl_002_task_archival.md

@@ -1,48 +0,0 @@
-# PPL-002: Completed Task Archival - 已完成任務封存
-
-**記憶 ID**: kenaz/rules/003
-**類型**: Critical Rule
-**標籤**: #rules #ppl-002 #pipeline #critical
-**建立時間**: 2026-02-10
-**嚴重程度**: 🔴 MUST（必須遵守）
-
----
-
-## 規則定義
-
-**已完成任務必須封存到 `.memory/COMPLETED_TASKS.json`**
-
-## 目的
-
-- ✅ 防止佇列污染
-- ✅ 保持 TASK_QUEUE.json 輕量
-- ✅ 保留歷史記錄
-
-## 封存流程
-
-```bash
-# 手動封存
-/archive
-
-# 自動封存（Multi-Agent Scheduler）
-# 任務完成後自動移動到 .memory/
-```
-
-## TASK_QUEUE.json 結構
-
-**只存活躍任務**：
-```json
-{
-  "tasks": [
-    {"id": "TASK_001", "status": "pending"},
-    {"id": "TASK_002", "status": "in_progress"}
-  ]
-}
-```
-
-**不存 completed 任務**
-
-## 參考
-
-- `.rule/pipeline/PPL-002-completed-task-archival.yaml`
-- `.failure/pipeline/FAIL-003-task-queue-pollution.yaml`

package/core/.kenaz/main-memory/kenaz/system/001_dual_track_task_system.md

@@ -1,197 +0,0 @@
-# 雙軌制任務系統
-
-**ID**: KNZ-SYSTEM-001
-**分類**: system
-**標籤**: #task-system #dual-track #collaboration #pipeline #migration
-
-## 核心概念
-
-Kenaz AI 專案有**兩套任務管理系統**，處於漸進式遷移階段：
-- **新系統（Collaboration）**：目錄即狀態架構，輕量易用
-- **舊系統（Pipeline）**：JSON + YAML 架構，功能豐富但複雜
-
-## 系統對比
-
-| 特性 | 新系統（Collaboration） | 舊系統（Pipeline） |
-|------|----------------------|------------------|
-| **路徑** | `.collaboration/tasks/{status}/` | `dev/pipeline/TASK_QUEUE.json` + `completed/` |
-| **ID 範圍** | TASK_151~196+ | TASK_134~187 |
-| **格式** | 目錄 + YAML | JSON 索引 + YAML 檔案 |
-| **狀態** | ✅ 主力系統（推薦） | ⚠️ Legacy（相容支援） |
-| **適用場景** | 手動協作、簡單流程 | 排程器、Multi-Agent 並行開發 |
-
-## 關鍵差異
-
-### 優勢對比
-
-**新系統優勢**：
-- ✅ 目錄即狀態，移動檔案 = 改變狀態
-- ✅ 純 YAML，人類可讀
-- ✅ Node.js CLI，支援過濾查詢
-- ✅ 簡單易用，學習曲線低
-
-**舊系統優勢**：
-- ✅ 路徑鎖定（`lock_manager.py`）防止並行衝突
-- ✅ 完整依賴解析（拓撲排序、循環檢測、關鍵路徑）
-- ✅ 統計查詢豐富（依賴圖、執行時間預估）
-- ✅ 排程器整合完善（Single-Agent、Multi-Agent）
-
-### 功能差異
-
-| 功能 | 新系統 | 舊系統 |
-|------|--------|--------|
-| **路徑鎖定** | ❌ 無 | ✅ lock_manager.py |
-| **依賴解析** | ⚠️ 基礎支援 | ✅ 完整（拓撲排序、循環檢測） |
-| **並行衝突檢測** | ❌ 無自動檢測 | ✅ 自動檢測 |
-| **統計查詢** | ⚠️ 基礎（僅數量統計） | ✅ 豐富（含關鍵路徑、依賴圖） |
-| **排程器整合** | ⚠️ Formation 有限支援 | ✅ Single-Agent、Multi-Agent |
-| **驗證工具** | ❌ 無 | ✅ validate_pipeline.ps1 |
-| **複雜度** | ✅ 簡單（目錄即狀態） | ⚠️ 較高（需理解鎖定機制） |
-
-## 查詢方式
-
-### 新系統查詢
-
-```bash
-# 列出所有任務
-node .collaboration/core/task-api.js list
-
-# 過濾查詢
-node .collaboration/core/task-api.js list --status pending --role developer
-
-# 取得單個任務
-node .collaboration/core/task-api.js get TASK_194
-
-# JSON 輸出（供 Dashboard 使用）
-node .collaboration/core/task-api-json.js
-```
-
-### 舊系統查詢
-
-```bash
-# JSON 索引
-cat dev/pipeline/TASK_QUEUE.json
-
-# YAML 檔案
-ls dev/pipeline/completed/TASK_XXX_*.yaml
-
-# Python API
-python -c "from dev.pipeline.orchestrator.task_queue import TaskQueue; print(TaskQueue().get_next_task())"
-```
-
-### 查詢策略
-
-**重要**：查詢任務時**必須兩邊都查**：
-1. 先查新系統：`node .collaboration/core/task-api.js get TASK_XXX`
-2. 若無結果，查舊系統：`cat dev/pipeline/TASK_QUEUE.json` + `ls dev/pipeline/completed/`
-
-## 整合狀態
-
-### Formation 系統
-
-`.formation/tools/loader.js` 已實現**三層 fallback**：
-1. 優先讀取新系統（`.collaboration/tasks/`）
-2. 降級讀取舊 YAML（`dev/pipeline/completed/`）
-3. 最終降級讀取舊 JSON（`dev/pipeline/TASK_QUEUE.json`）
-
-### Dashboard 整合
-
-Tauri Dashboard 同時支援兩套系統：
-- 新系統：呼叫 `task-api-json.js`
-- 舊系統：呼叫 `task_queue.py`
-
-### 排程器
-
-| 排程器 | 新系統支援 | 舊系統支援 |
-|--------|-----------|-----------|
-| **Single-Agent** (`START_DEV_AGENT.bat`) | ⚠️ 有限 | ✅ 完整 |
-| **Multi-Agent** (`START_MULTI_AGENT.bat`) | ❌ 無 | ✅ 完整 |
-| **Formation** | ✅ 三層 fallback | ✅ 完整 |
-
-## 遷移方向
-
-### 階段 1：雙軌制運行（當前階段）
-- ✅ 兩套系統並存，保持相容
-- ✅ 新任務優先建立在 Collaboration 系統
-- ✅ Formation 系統已支援三層 fallback
-- ⚠️ 舊系統功能凍結，不再新增特性
-
-### 階段 2：功能補齊（計劃中）
-- [ ] 實現路徑鎖定機制（移植 `lock_manager.py` 到 Node.js）
-- [ ] 增強依賴解析（拓撲排序、循環檢測、關鍵路徑）
-- [ ] 建立驗證工具（`validate_collaboration.js`）
-- [ ] 統計查詢增強（依賴圖、執行時間預估）
-
-### 階段 3：排程器遷移（計劃中）
-- [ ] 更新 Single-Agent 排程器使用新系統
-- [ ] 更新 Multi-Agent 排程器使用新系統
-- [ ] 保留舊系統的 Python orchestrator 模組作為參考實現
-
-### 階段 4：全面遷移（計劃中）
-- [ ] 將 `dev/pipeline/TASK_QUEUE.json` 中的任務匯入新系統
-- [ ] 封存舊系統文件至 `.legacy/`
-- [ ] 更新 CLAUDE.md、規則文檔移除舊系統引用
-
-## 選擇建議
-
-### 使用新系統（Collaboration）的情況
-
-- ✅ 手動協作開發
-- ✅ 簡單任務流程
-- ✅ 不需要並行開發
-- ✅ 需要快速上手
-
-### 使用舊系統（Pipeline）的情況
-
-- ✅ 需要自動化排程器
-- ✅ Multi-Agent 並行開發
-- ✅ 需要路徑衝突檢測
-- ✅ 複雜依賴關係管理
-
-## 相關文檔
-
-| 文檔 | 路徑 | 說明 |
-|------|------|------|
-| **新系統文檔** | `.system/collaboration/README.md` | 完整 API 文檔 |
-| **舊系統文檔** | `.system/pipeline/README.md` | Legacy System |
-| **對比表** | `.system/collaboration/README.md#詳細差異對照` | 詳細功能對比 |
-| **遷移指引** | `.system/collaboration/README.md#遷移方向` | 遷移路線圖 |
-| **Migration 工具** | `.collaboration/core/migrate-legacy.js` | 新舊系統轉換 |
-
-## 最佳實踐
-
-### 建立任務時
-
-**推薦流程**：
-1. 優先建立在新系統（`.collaboration/`）
-2. 若需要排程器執行，使用 `migrate-legacy.js export` 匯出到舊系統
-3. 避免手動在兩邊同時建立（容易不同步）
-
-### 查詢任務時
-
-**必須兩邊都查**：
-```bash
-# Step 1: 查新系統
-node .collaboration/core/task-api.js get TASK_XXX
-
-# Step 2: 若無結果，查舊系統
-ls dev/pipeline/completed/TASK_XXX_*.yaml
-cat dev/pipeline/TASK_QUEUE.json | grep "TASK_XXX"
-```
-
-### 更新狀態時
-
-- 新系統：使用 `task-api.js move` 指令
-- 舊系統：更新 `TASK_QUEUE.json` + 移動 YAML 檔案
-
-## 已知問題
-
-1. **ID 衝突**：兩套系統 ID 範圍不同，但若同時建立可能重複
-2. **狀態不同步**：手動操作可能導致兩邊狀態不一致
-3. **Migration 工具未完善**：雙向同步功能尚未實現
-
-## 更新歷史
-
-- **2026-02-19**: 建立文檔（TASK_197）
-- **2026-02-18**: Formation 整合三層 fallback（TASK_194）
-- **2026-02-14**: Collaboration 系統 v3.0 發布

package/core/.kenaz/main-memory/knowledge/patterns/001_json_bom_issue.md

@@ -1,78 +0,0 @@
-# JSON BOM Issue - JSON 文件 BOM 編碼問題
-
-**記憶 ID**: knowledge/patterns/001
-**類型**: Common Issue
-**標籤**: #json #windows #encoding #failure
-**建立時間**: 2026-02-10
-**適用於**: 所有使用 Windows 的專案
-**失敗記錄**: FAIL-002
-
----
-
-## 問題描述
-
-Windows 產生的 JSON 文件可能帶有 UTF-8 BOM（Byte Order Mark），導致 JSON 解析失敗。
-
-## 症狀
-
-```bash
-SyntaxError: Unexpected token  in JSON at position 0
-```
-
-- 文件看起來正常，但 `JSON.parse()` 失敗
-- 使用文字編輯器可能看不到 BOM
-
-## 根本原因
-
-Windows 編輯器（如 Notepad）預設使用 UTF-8 with BOM 編碼。
-
-## 解決方案
-
-### 1. 一鍵修復（推薦）
-
-```bash
-node .failure/tools/fix_json.js file.json
-```
-
-自動執行：
-- 移除 BOM
-- 驗證 JSON 語法
-- 格式化 JSON
-- 創建備份
-
-### 2. 批量檢查
-
-```bash
-node .failure/tools/check_bom.js
-```
-
-檢查所有 JSON 文件是否有 BOM 問題。
-
-### 3. 手動移除
-
-```bash
-node .failure/tools/remove_bom.js file.json
-```
-
-## 預防措施
-
-### 編輯 JSON 後立即驗證
-
-```bash
-# 驗證語法
-node -e "JSON.parse(require('fs').readFileSync('file.json', 'utf8'))"
-
-# 或使用專用工具
-node .failure/tools/validate_json.js file.json
-```
-
-### 使用正確的編輯器
-
-- ✅ VS Code（配置為 UTF-8 without BOM）
-- ✅ Notepad++（選擇 UTF-8 without BOM）
-- ❌ Windows Notepad（預設 UTF-8 with BOM）
-
-## 相關記憶
-
-- `.failure/data-integrity/FAIL-002-json-bom-encoding.yaml` - 失敗記錄
-- `C:\Users\User\.claude\projects\D--repo-side-ava-KenazAI\memory\topics\json-best-practices.md` - JSON 最佳實踐