kenaz 0.3.18 → 0.3.19

package/core/.system/collaboration/README.md

@@ -7,8 +7,7 @@
 **設計理念**：
 - **目錄即狀態**：任務狀態由檔案所在目錄決定，無需在檔案中維護狀態欄位
 - **YAML 格式**：人類可讀，支援多行文字和結構化資料
-- **雙層 API**：task-api.js（完整功能）+ task-api-json.js（JSON 輸出供 Dashboard 使用）
-- **向後相容**：與舊 TASK_QUEUE.json 格式相容，支援平滑遷移
+- **單一 API**：task-api.js（完整功能 + CLI，`--format json` 輸出機器可讀 JSON）
 
 ---
 
@@ -18,8 +17,7 @@
 .collaboration/
 ├── core/                    # 核心 API
 │   ├── task-api.js          # 主 API（完整功能 + CLI）
-│   ├── task-api-json.js     # JSON 輸出包裝（供 Dashboard 使用）
-│   └── migrate-legacy.js    # 遷移工具（dev/pipeline → .collaboration）
+│   └── migrate-legacy.js    # 一次性遷移工具（dev/pipeline → tasks）
 ├── tasks/                   # 任務檔案（目錄即狀態）
 │   ├── backlog/             # 待處理任務 (status: pending)
 │   ├── active/              # 進行中任務 (status: in_progress)
@@ -191,69 +189,9 @@ node <core>/k-cli/dist/index.js task get TASK_XXX --project-path . --json
 
 ---
 
-### 2. task-api-json.js（JSON 輸出包裝）
+### 2. JSON 輸出
 
-**用途**：包裝 `task-api.js`，輸出純 JSON 格式（與舊版 TASK_QUEUE.json 相容），供 Tauri Dashboard 使用。
-
-**使用方式**：
-
-```bash
-# 輸出所有任務（JSON 格式）
-node .collaboration/core/task-api-json.js
-
-# 輸出單個任務
-node .collaboration/core/task-api-json.js --task TASK_194
-```
-
-**輸出格式**：
-
-```json
-{
-  "version": "3.3.0",
-  "tasks": [
-    {
-      "id": "TASK_194",
-      "hash": "357cd130-e843-4718-b858-7cc56bdae4e5",
-      "title": "系統文檔：.collaboration 新任務系統",
-      "status": "in_progress",
-      "priority": "P1",
-      "role": "developer",
-      "rigor": "medium",
-      "tags": ["docs"],
-      "complexity": "simple",
-      "estimated_hours": 0.3,
-      "dependencies": [],
-      "scope_paths": [".system/collaboration/"],
-      "requirements": ["閱讀核心 JS 檔案", "建立 README.md"],
-      "acceptance_criteria": ["README.md 涵蓋 API 使用方式"],
-      "created_by": {
-        "name": "{os_user}",
-        "git_user": "{git_user}",
-        "timestamp": "2026-02-18T15:07:00.995Z"
-      },
-      "_file_path": ".collaboration/tasks/active/TASK_194_{git_user}.yaml",
-      "_source": "collaboration"
-    }
-  ],
-  "statistics": {
-    "total": 124,
-    "pending": 2,
-    "in_progress": 1,
-    "completed": 108,
-    "blocked": 0,
-    "cancelled": 13
-  },
-  "metadata": {
-    "last_updated": "2026-02-18T15:30:00.000Z",
-    "directories": ["backlog", "active", "done", "cancel", "blocked", "archived"]
-  }
-}
-```
-
-**關鍵轉換**：
-- `role` 向後相容為 `agent_type`
-- 人員欄位 (`created_by`, `executed_by`) 轉為 `TaskPerson` 格式（匹配 Rust struct）
-- 陣列欄位確保為字串陣列（避免物件混入）
+需要機器可讀輸出時用 `node .collaboration/core/task-api.js list --format json`。
 
 ---
 
@@ -306,118 +244,19 @@ keywords: []
 
 ## 與舊系統的關係
 
-### 雙軌制說明
-
-專案同時維護兩套任務系統，處於**漸進式遷移**階段：
-
-| 系統 | 路徑 | ID 範圍 | 格式 | 狀態 | 適用場景 |
-|------|------|---------|------|------|---------|
-| **新系統（Collaboration）** | `.collaboration/tasks/{status}/` | TASK_151~196+ | 目錄 + YAML | ✅ 主力系統（推薦） | 手動協作、簡單流程 |
-| **舊系統（Pipeline）** | `dev/pipeline/TASK_QUEUE.json` + `completed/` | TASK_134~187 | JSON + YAML | ⚠️ 相容支援（逐步淘汰） | 排程器、Multi-Agent 並行開發 |
-
-**查詢任務時必須兩邊都查**：
-- 新系統：`node .collaboration/core/task-api.js get TASK_XXX`
-- 舊系統：`dev/pipeline/completed/TASK_XXX_*.yaml` 或 `dev/pipeline/TASK_QUEUE.json`
-
----
-
-### 詳細差異對照
-
-| 特性 | Pipeline System（舊） | Collaboration System（新） | 說明 |
-|------|---------------------|--------------------------|------|
-| **狀態管理** | JSON 索引集中式 | 目錄分散式 | 新系統移動檔案即改變狀態，簡化流程 |
-| **任務格式** | JSON 索引 + YAML 檔案 | 純 YAML（目錄即狀態） | 新系統無需在 YAML 中維護狀態欄位 |
-| **查詢介面** | Python API + JSON | Node.js CLI + JSON 輸出 | 新系統支援 `--help` 和過濾查詢 |
-| **路徑鎖定** | ✅ `lock_manager.py` | ❌ 無 | 舊系統支援並行開發衝突檢測 |
-| **依賴解析** | ✅ `dependency_resolver.py` | ⚠️ 基礎支援 | 舊系統有拓撲排序、循環檢測、關鍵路徑 |
-| **統計查詢** | ✅ 豐富（含關鍵路徑、依賴圖） | ⚠️ 基礎（僅數量統計） | 舊系統功能更完善 |
-| **排程器整合** | ✅ Single-Agent、Multi-Agent | ⚠️ Formation 有限支援 | 舊系統為排程器設計 |
-| **Dashboard 支援** | ✅ Tauri API 呼叫 | ✅ Tauri API 呼叫 | 兩者皆支援 JSON 輸出 |
-| **衝突避免** | ✅ `scope_paths` + 路徑鎖定 | ⚠️ `scope_paths` 欄位（無自動檢測） | 舊系統自動防衝突 |
-| **孤兒鎖定清理** | ✅ 自動清理 | ❌ 不適用 | 舊系統處理 Agent crash |
-| **驗證腳本** | ✅ `validate_pipeline.ps1` | ❌ 無 | 舊系統有一致性檢查 |
-| **複雜度** | ⚠️ 較高（需理解鎖定機制） | ✅ 較低（目錄即狀態） | 新系統更易上手 |
-| **適用場景** | 排程器、並行開發 | 手動協作、簡單流程 | 根據場景選擇系統 |
-
-**選擇建議**：
-- ✅ **使用新系統（Collaboration）**：手動協作、簡單任務流程、不需要並行開發
-- ✅ **使用舊系統（Pipeline）**：需要自動化排程器、Multi-Agent 並行開發、路徑衝突檢測
-
----
-
-### 遷移方向
-
-**目標**：逐步將 Pipeline 系統的功能整合到 Collaboration 系統，最終淘汰舊系統。
-
-**階段 1：雙軌制運行**（當前階段）
-- ✅ 兩套系統並存，保持相容
-- ✅ 新任務優先建立在 Collaboration 系統
-- ✅ Formation 系統已支援三層 fallback（新系統 → 舊 YAML → 舊 JSON）
-
-**階段 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、規則文檔移除舊系統引用
-
-**遷移工具**：
-```bash
-# 匯出新系統任務為舊格式（供排程器使用）
-node .collaboration/core/migrate-legacy.js export
+`dev/pipeline/TASK_QUEUE.json` 的舊任務佇列已凍結，不再新增或更新。所有任務在 `.kenaz/tasks/{status}/`（YAML，目錄即狀態）；`.collaboration/tasks/` 只在 `.kenaz/tasks/` 不存在時作為 legacy fallback。查舊任務可參考 `dev/pipeline/` 的歷史檔案，新任務一律用 task-api。
 
-# 匯入舊系統任務到新系統（未來遷移用）
-node .collaboration/core/migrate-legacy.js import
-
-# 雙向同步（開發中）
-node .collaboration/core/migrate-legacy.js sync
-```
-
-**相關文檔**：
-- 舊系統文檔：`.system/pipeline/README.md`
-- 遷移腳本：`.collaboration/core/migrate-legacy.js`
-- Formation 整合：`.formation/tools/loader.js:180-220`
+`migrate-legacy.js` 為一次性遷移工具，僅供查閱歷史資料格式。
 
 ---
 
-## 整合與使用場景
-
-### 1. Formation 系統整合
-
-`.formation/tools/loader.js` 已更新為三層 fallback：
-1. 優先讀取新系統（`.collaboration/tasks/`）
-2. 降級讀取舊 YAML（`dev/pipeline/completed/`）
-3. 最終降級讀取舊 JSON（`dev/pipeline/TASK_QUEUE.json`）
-
-### 2. Dashboard 整合
-
-Tauri Dashboard 透過 Rust API 呼叫 `task-api-json.js`：
-```rust
-// dashboard/src-tauri/src/features/task/manager.rs
-pub async fn get_tasks() -> Result<TaskQueue, TaskError> {
-    let output = Command::new("node")
-        .args(&[".collaboration/core/task-api-json.js"])
-        .output()?;
-    let json = String::from_utf8(output.stdout)?;
-    serde_json::from_str(&json)
-}
-```
+## 使用場景
 
-### 3. Dev Agent 整合
+Ansuz 派工前先開卡（`create`），subagent 完成後 `complete`；任務卡的 scope_paths 供並行任務避免路徑衝突（無自動檢測，由派工者檢查）。
 
-Dev Agent 使用新系統查詢任務：
 ```bash
 # 列出待辦任務
-node .collaboration/core/task-api.js list --status pending --role developer
+node .collaboration/core/task-api.js list --status backlog --role developer
 
 # 認領任務
 node .collaboration/core/task-api.js claim TASK_194
@@ -554,16 +393,13 @@ async moveTask(taskId, newStatus) {
 - **Claim 保號**：共享模式下從 Pool 認領任務保留原編號；只有真正的本地檔案碰撞才重編號（碰撞時先比對 `hash` 欄位 — 相同代表同一張卡返家，原地更新不重編）。重編號從 lease 消耗（counter 在共享模式下只記錄最後消耗的 lease 編號，不是配號權威）。
 - **Relay 端**：`id_counters` 表以 `(team_id, project)` 隔離，單一 transaction 內原子配號。
 
-**相關實作**：`task-api.js generateTaskID()/_allocateFromRelay()`、`dashboard/src/app/api/tasks/move/route.ts`（claim 路徑）、`yggdrasil-relay/src/routes/tasks.rs allocate_ids`（端點文檔見 `yggdrasil-relay/DESIGN.md`）。
+**相關實作**：`task-api.js generateTaskID()/_allocateFromRelay()`、`yggdrasil-relay/src/routes/tasks.rs allocate_ids`（端點文檔見 `yggdrasil-relay/DESIGN.md`）。
 
 ---
 
 ## 參考連結
 
 - YAML 範例：`.collaboration/tasks/TASK_Example_{git_user}.yaml`
-- 舊系統文檔：`.system/pipeline/README.md`（待建立）
-- Formation 整合：`.formation/tools/loader.js:180-220`
-- Dashboard 整合：`dashboard/src-tauri/src/features/task/manager.rs`
 
 ---
 

package/core/CLAUDE.md

@@ -38,7 +38,7 @@ session 開始時先鎖定語言（對照用戶第一條訊息 + cwd/CLAUDE.md
   - 「這個檔案有哪些 symbol？」→ `kenaz_lsp_symbols`
 - **文字 / 概念搜尋** → `Grep` / `Glob`（精確字串、正則、枚舉；需用 `|` 猜多個關鍵字時，就多組關鍵字一起 Grep）。
 - Session 初始化時用 `ToolSearch "kenaz_lsp"` 偵測 LSP 工具。ToolSearch 未找到 → 該 session 全程降級用 Grep/Glob。
-- 修改非 trivial symbol 前：用 `kenaz_lsp_references` / `kenaz_lsp_callers` 看影響範圍（FAIL-009）。trivial 改動可跳過。
+- 修改非 trivial symbol 前：用 `kenaz_lsp_references` / `kenaz_lsp_callers` 看影響範圍。trivial 改動可跳過。
 - 所有 `kenaz_lsp_*` 呼叫必須明確帶 `projectPath`。
 
 **記憶系統已移除（2026-10-11，TASK_2411）**：Synapse / Hippocampus / Cortex recall / embeddings 與 Alaya seeds/bijas 已移除，`synapse_*`、`hippocampus_*`、`cortex_*`、`alaya_recall` 不再存在；教訓用 `kenaz learn add` 與 Claude 原生記憶檔；`~/.kenaz/cortex/*.db` 與 `.synapse/` 資料留在磁碟上、不再開啟。
@@ -97,12 +97,7 @@ KenazAI 是一個 Claude Code 多 Agent 協作系統，包含：
 | `/產品` | 需求分析、PRD |
 | `/設計` | UI/UX 設計 |
 | `/評估` | 深度評估 |
-| `/sre` | Supabase 管理、部署、SLO/Error Budget |
-| `/init` | 初始化新專案 |
-| `/進度` | 查看開發進度 |
 | `/spec` | 規格優化與文件整理 |
-| `/strategy` | 策略智庫 |
-| `/sunny` | 內部系統開發模式 |
 
 完整指令列表見 `.claude/commands/`。
 

package/core/KENAZ_CORE_VERSION

@@ -1 +1 @@
-0.3.18
+0.3.19

package/core/dev/scripts/js-yaml-resolution.test.js

@@ -17,7 +17,7 @@ const path = require('path');
 const { spawnSync } = require('child_process');
 
 const ROOT = path.resolve(__dirname, '..', '..');
-const TARGETS = ['dev/scripts/check-file-size.js', '.memory/tools/memory-agent.js'];
+const TARGETS = ['dev/scripts/check-file-size.js'];
 // Shipped modules (not CLIs): static check only. cognitive.js swallowed the missing
 // module in a try/catch and silently returned fallback rules in kenaz-core.
 const MODULES = ['.formation/tools/post-complete/cognitive.js'];

package/core/dev/scripts/run-rust-tests.js

@@ -1,24 +1,12 @@
 #!/usr/bin/env node
 /**
- * run-rust-tests.js — make `cargo test --lib` actually runnable on Windows (TASK_1619).
+ * run-rust-tests.js — build the kenaz-dashboard lib test binary and run it (TASK_1619).
  *
- * Root cause: the kenaz-dashboard lib unittest binary needs the Common-Controls v6
- * manifest (rfd crate statically imports comctl32!TaskDialogIndirect, which only
- * exists in the v6 SxS assembly). build.rs emits `cargo:rustc-link-arg-tests=
- * /MANIFEST:EMBED + /MANIFESTINPUT:test.manifest`, but cargo applies those flags
- * only to integration test targets (tests/), NOT to the lib unittest unit —
- * verified empirically 2026-06-11: the build-script output file contains the
- * directives while the rustc -v link invocation does not. Result: the loader
- * binds comctl32 5.82 from WinSxS and dies with STATUS_ENTRYPOINT_NOT_FOUND
- * (0xc0000139, bash exit 127) before any test runs.
- *
- * A global `cargo:rustc-link-arg` is NOT safe: tauri-build already embeds an
- * RT_MANIFEST resource for the app binary; adding /MANIFESTINPUT there creates
- * a duplicate-manifest link failure.
- *
- * Fix here: build with --no-run, copy the test exe to a stable fresh name
- * (the copy's new timestamp busts the per-path SxS activation-context cache),
- * drop an external .manifest beside it, then exec it with passthrough args.
+ * Builds with --no-run (so compiler errors can be rendered readably from the JSON
+ * message stream), locates the lib unittest executable and execs it with the filter
+ * and passthrough args. The Windows Common-Controls manifest workaround this script
+ * used to carry was only needed for rfd's static TaskDialogIndirect import; rfd is
+ * gone and the test exe starts fine without any manifest.
  *
  * Usage:
  *   node dev/scripts/run-rust-tests.js [test-filter] [-- extra-harness-args]
@@ -36,7 +24,6 @@ const { verifyTargetDir } = require('./verify-target-dir.js');
 
 const repoRoot = path.resolve(__dirname, '..', '..');
 const crateDir = path.join(repoRoot, 'dashboard', 'src-tauri');
-const manifestSrc = path.join(crateDir, 'test.manifest');
 
 // TASK_2058: parse `[test-filter] [-- extra-harness-args]`.
 //
@@ -137,7 +124,7 @@ function main() {
   const exeArgs = buildExeArgs(process.argv.slice(2));
 
   // TASK_1879: default to the canonical shared verify target dir. Avoids both
-  // Windows MAX_PATH (vendor/kuzu CMake) and the live tauri-dev lock on the
+  // Windows MAX_PATH and the live tauri-dev lock on the
   // repo's own target/. Explicit CARGO_TARGET_DIR still wins.
   const env = { ...process.env };
   if (!env.CARGO_TARGET_DIR) {
@@ -192,31 +179,8 @@ function main() {
     fail(`could not locate lib test executable (got: ${testExe})`);
   }
 
-  // 3. Non-Windows: no manifest problem — run the artifact directly.
-  if (process.platform !== 'win32') {
-    const direct = spawnSync(testExe, exeArgs, { stdio: 'inherit' });
-    process.exit(direct.status ?? 1);
-  }
-
-  // 4. Windows: copy to a stable name + external manifest (cache-busting copy).
-  if (!fs.existsSync(manifestSrc)) {
-    fail(`test.manifest not found at ${manifestSrc}`);
-  }
-  const runDir = path.dirname(testExe);
-  const runExe = path.join(runDir, 'kenaz_dashboard_unit_tests.exe');
-  fs.copyFileSync(testExe, runExe); // fresh timestamp invalidates SxS manifest cache
-  fs.copyFileSync(manifestSrc, `${runExe}.manifest`);
-  // Stage the PDB too so panic backtraces keep symbols (best effort).
-  const pdb = testExe.replace(/\.exe$/i, '.pdb');
-  if (fs.existsSync(pdb)) {
-    try {
-      fs.copyFileSync(pdb, runExe.replace(/\.exe$/i, '.pdb'));
-    } catch {
-      /* non-fatal */
-    }
-  }
-
-  const run = spawnSync(runExe, exeArgs, { stdio: 'inherit' });
+  // 3. Run the artifact directly.
+  const run = spawnSync(testExe, exeArgs, { stdio: 'inherit' });
   process.exit(run.status ?? 1);
 }
 

package/core/dev/scripts/rust-verify-worktree.js

@@ -5,8 +5,8 @@
  *
  * PROBLEM: a Rust-scoped worktree subagent cannot safely run `cargo`/
  * `run-rust-tests.js` in its OWN task worktree. That worktree is a fresh
- * source root, so kuzu (a [patch] path dependency, see verify-target-dir.js)
- * has to be rebuilt from scratch via CMake — 10+ minutes, which blows the
+ * source root, so the whole dependency tree (see verify-target-dir.js)
+ * has to be rebuilt from scratch — minutes, which blows the
  * Bash foreground timeout and, per prompt.js rule 13/feedback_agent_orphan_
  * build_holds_lock, leaves an orphan cargo holding the shared target-dir
  * lock forever.
@@ -14,7 +14,7 @@
  * FIX: ONE canonical, reused worktree (this script owns it) that agents
  * check out their branch into, run a single narrow test filter in, and
  * hand back. The cache stays warm across dispatches because it is always
- * the SAME source root (kuzu's build artifacts are keyed per source root).
+ * the SAME source root (build artifacts are keyed per source root).
  *
  * Marker file `.kenaz-rust-verify` inside the worktree is the safety
  * invariant: every subcommand that would touch (create/checkout/lock in)
@@ -67,7 +67,7 @@ const RUNNER_REL_PATH = path.join('dev', 'scripts', 'run-rust-tests.js');
 // and the old `path.resolve(__dirname, '..', '..')` returned the WORKTREE
 // root, not the main repo — deriving a stray `<repoRoot>/.kenaz-worktrees/
 // <repoRoot-basename>/rust-verify` path nested inside the task worktree
-// and paying a cold kuzu build, exactly what this script exists to avoid.
+// and paying a cold build, exactly what this script exists to avoid.
 //
 // Fix: ask git. `git rev-parse --git-common-dir` always resolves to the
 // MAIN repo's shared `.git` directory, even when run from a linked

package/core/dev/scripts/verify-target-dir.js

@@ -6,9 +6,9 @@
  * generators, taskgen templates, verify scripts, formation runner/integration)
  * must take the value from here instead of inventing its own directory.
  *
- * Why a short path at all (Windows): vendor/kuzu's CMake object paths exceed
- * MAX_PATH (260) when the target dir sits under the repo or a worktree
- * (worktree paths add ~40 chars). A short root like C:/t/... keeps CMake alive.
+ * Why a short path at all (Windows): deep C/C++ dependency object paths
+ * can approach MAX_PATH (260) when the target dir sits under the repo or a
+ * worktree (worktree paths add ~40 chars). A short root like C:/t/... avoids it.
  *
  * Why ONE shared directory (user decision 2026-08-22): the previous convention
  * — "each dispatch invents a unique dir (C:/t/vis, C:/t/emb, C:/t1599, ...)
@@ -27,10 +27,10 @@
  * cargo.exe / build-script-build.exe at 0% CPU with NO rustc children
  * (nothing is compiling). Only in the orphan case kill the holder.
  *
- * Cache-heat caveat: kuzu is a [patch] path dependency, so its build artifacts
- * are keyed per source root. Verifies from the SAME checkout (main repo, or a
+ * Cache-heat caveat: workspace crates' build artifacts are keyed per
+ * source root. Verifies from the SAME checkout (main repo, or a
  * reused worktree) get the warm cache; a verify from a NEW worktree path
- * recompiles kuzu but coexists in the same dir without invalidating others.
+ * recompiles them but coexists in the same dir without invalidating others.
  * The dir therefore still grows across many distinct worktree roots — when it
  * gets too big, delete the whole canonical dir while no cargo is running; it
  * is pure cache and rebuilds itself.

package/core/plugins/kenaz/INVENTORY.md

@@ -13,7 +13,7 @@ off = every hook exits before reading stdin. assist = silent telemetry/bookkeepi
 | agent-flow POST (Notification, Pre/PostToolUse, PostToolUseFailure, SessionEnd, Stop, SubagentStart/Stop; user-level curl) | ship | assist | skipped silently when backend down |
 | SessionStart agent-flow ping | ship | assist | |
 | SessionStart guidance (new, replaces injecting CLAUDE.md) | ship | full | `guidance.md` |
-| _run-user-prompt.js (runs handoff-staleness, fatigue-check, daemon-outbox, turn-context, task-bridge, lease-touch, stream-delta) | ship | full | prints context |
+| _run-user-prompt.js (runs daemon-outbox, turn-context, task-bridge, correction-detect; see DEFAULT_HOOKS) | ship | full | prints context |
 | memory-guard.js | ship | full | |
 | synapse-first-investigation.js | ship | full | |
 | task-bridge.js (PostToolUse Task*) | ship | assist | |
@@ -26,19 +26,19 @@ off = every hook exits before reading stdin. assist = silent telemetry/bookkeepi
 
 Hooks only act in Kenaz projects (`.kenaz/project.yaml`, `_project-guard.js`): run `/kenaz init` once in a fresh project.
 
-## Commands (25)
+## Commands (13)
 | Class | Commands |
 |---|---|
-| ship (12 + new `/kenaz`) | Ansuz, Amelia, architect, dev, incident, review, security, spec, strategy, 產品, 設計, 評估 |
-| core | Huginn, sunny, lead, agent-worker, canary |
-| retire | archive, init, 進度, 開發, legacy_dev, 產品檢視, product-review, multi-agent, dev, lead (user retired 2026-10-09 with Formation) |
+| ship (11 + new `/kenaz`) | Ansuz, Amelia, architect, incident, review, security, spec, 產品, 設計, 評估 |
+| core | Huginn, canary, agent-worker (invoked by the Rust scheduler with `--task`/`--agent`) |
+| removed | strategy (Strategy Agent skill gone), archive, init, 進度, legacy_dev, 產品檢視, product-review, sunny (Pipeline / TASK_QUEUE / retired-subsystem commands; `/dev`, `/lead`, `/開發`, `multi-agent` retired earlier with Formation) |
 
-## Skills (45)
+## Skills
 | Class | Skills |
 |---|---|
 | ship (34) | architect_agent, assessment_agent, backend_agent, backend_engineer, code_reviewer, dev_agent, designer, developer, feature_agent, frontend_agent, incident_response, product_manager, qa_engineer, security_agent, spec_optimizer, sre_agent, adapt, animate, audit, bolder, clarify, colorize, critique, delight, distill, extract, frontend-design, harden, normalize, onboard, optimize, polish, quieter, ui-ux-pro-max |
-| core | heimdall, huginn, sunny, optimization_agent |
-| retire | legacy_dev |
+| core | heimdall, huginn, optimization_agent |
+| removed | legacy_dev, sunny |
 | third-party / domain (not shipped; install separately from .agents/skills) | vercel-react-best-practices, supabase-postgres-best-practices, remotion-best-practices, pcb-review |
 
 ## Open items / caveats

package/core/plugins/kenaz/commands/architect.md

@@ -17,8 +17,7 @@
    - 撰寫模組接口規範
 
 4. **產出文件**：
-   - 更新 `dev/pipeline/TASK_QUEUE.json`
-   - 建立任務文件至 `dev/pipeline/tasks/`
+   - 用 `node "${CLAUDE_PLUGIN_ROOT}/hooks/core-resolve.js" .collaboration/core/task-api.js create` 建立任務卡（`.kenaz/tasks/backlog/`）
    - 撰寫接口文檔至 `docs/`
 
 請開始執行系統架構設計。

package/core/plugins/kenaz/commands/spec.md

@@ -4,7 +4,7 @@
 
 ## 使用場景
 
-- 完成重要里程碑後，需要整理記憶點
+- 完成重要里程碑後，需要整理文件與任務狀態
 - 需要更新 PRODUCT_SPEC.md 的 Feature 狀態
 - 需要從 .failure/ 提取失敗經驗
 - 定期維護文件（建議每週）

package/core/plugins/kenaz/commands//347/224/242/345/223/201.md

@@ -10,6 +10,6 @@
    - 深度理解用戶需求
    - 進行需求分析
    - 將需求拆解為開發任務
-   - 將任務寫入 Pipeline 系統
+   - 用 `node "${CLAUDE_PLUGIN_ROOT}/hooks/core-resolve.js" .collaboration/core/task-api.js create` 建立任務卡（`.kenaz/tasks/backlog/`），完成後建議交給 `/Ansuz` 派工
 
 請開始執行產品需求分析。

package/core/plugins/kenaz/guidance.md

@@ -1,5 +1,5 @@
 [Kenaz plugin: mode full] Kenaz MCP tools (kenaz-dashboard) are available when kenaz-server runs on localhost:18080.
 - Code navigation: kenaz_lsp_callers / kenaz_lsp_references / kenaz_lsp_definition / kenaz_lsp_symbols (always pass projectPath). Text search: Grep/Glob.
 - Collaboration: kenaz_peer_send / kenaz_peer_threads (other sessions, other machines, Codex), /kenaz ygg status|join.
-- Reply in the user's language. Commands: /Ansuz, /Amelia, /review, /security, /incident, /spec, /strategy.
+- Reply in the user's language. Commands: /Ansuz, /Amelia, /review, /security, /incident, /spec.
 - Switch: /kenaz off | assist | full (or env KENAZ_MODE). off disables every Kenaz hook.

package/core/plugins/kenaz/scripts/sync.js

@@ -16,7 +16,7 @@ const SKILLS = [
   'adapt', 'animate', 'audit', 'bolder', 'clarify', 'colorize', 'critique', 'delight', 'distill', 'extract',
   'frontend-design', 'harden', 'normalize', 'onboard', 'optimize', 'polish', 'quieter', 'ui-ux-pro-max',
 ];
-const COMMANDS = ['Amelia', 'Ansuz', 'architect', 'incident', 'review', 'security', 'spec', 'strategy', '產品', '設計', '評估'];
+const COMMANDS = ['Amelia', 'Ansuz', 'architect', 'incident', 'review', 'security', 'spec', '產品', '設計', '評估'];
 
 // Core-relative references become plugin-relative / core-resolved.
 // In a user's project (npm install) the core lives in ~/.kenaz/core, not the project folder, so a

package/core/plugins/kenaz/skills/architect_agent/SKILL.md

@@ -13,7 +13,7 @@ description: 架構設計、需求拆解、任務分派、接口定義、多Agen
 2. **任務拆解**：將大型需求拆解為可獨立執行的任務單元
 3. **Scope 定義**：為每個任務定義精確的路徑範圍（避免衝突）
 4. **接口設計**：定義模組之間的接口規範，確保整合順利
-5. **任務分派**：將任務寫入 `TASK_QUEUE.json` 並分派給適合的 Agent
+5. **任務分派**：以 task-api 建立任務卡並指定適合的 role
 
 ## 技能
 * **系統分析**：識別系統架構邊界和模組劃分
@@ -24,9 +24,8 @@ description: 架構設計、需求拆解、任務分派、接口定義、多Agen
 
 ## 文件路徑
 * **產品規格**：`dev/PRODUCT_SPEC.md`
-* **任務佇列**：`dev/pipeline/TASK_QUEUE.json`
-* **進度追蹤**：`dev/pipeline/PROGRESS.md`
-* **待處理任務**：`dev/pipeline/tasks/`
+* **任務卡**：`.kenaz/tasks/{backlog,active,done,blocked,cancel}/`（YAML，目錄即狀態）
+* **任務 API**：`node "${CLAUDE_PLUGIN_ROOT}/hooks/core-resolve.js" .collaboration/core/task-api.js`
 * **接口文檔**：
   - `docs/api_spec.md`（API 接口）
   - `docs/component_spec.md`（組件接口）
@@ -171,97 +170,17 @@ def assign_agent(task: Task) -> str:
 
 > "接口定義已撰寫至 [文件路徑]"
 
-### 5. 產出任務檔案
-**將任務寫入 Pipeline 系統。**
+### 5. 產出任務卡
+**用 task-api 建立任務卡**（`node "${CLAUDE_PLUGIN_ROOT}/hooks/core-resolve.js" .collaboration/core/task-api.js --help` 列出全部欄位）。
 
-1. **建立任務文件**（`dev/pipeline/tasks/TASK_XXX_描述.md`）
-   - 檔案名稱格式：`TASK_XXX_簡短英文描述.md`
-   - 例如：`TASK_022_login_ui.md`
-
-2. **寫入 TASK_QUEUE.json**：
-   ```json
-   {
-       "id": "TASK_XXX",
-       "title": "實作用戶登入 UI",
-       "status": "pending",
-       "priority": "P1",
-       "estimated_hours": 4,
-       "scope": ["src/components/auth/", "src/utils/auth.ts"],
-       "dependencies": ["TASK_AAA"],
-       "blocked_by": ["TASK_AAA"],
-       "blocks": [],
-       "source": "用戶需求 / PRD P1 項目",
-       "source_file": "TASK_XXX_login_ui.md",
-       "created_at": "2026-01-31T10:00:00.000Z"
-   }
-   ```
-
-   **重要**：`source_file` 字段必須與步驟 1 建立的任務文件名稱一致，Dashboard 依賴此字段讀取任務詳細描述。
-
-3. **更新 PROGRESS.md**
-
-> "已建立 [N] 個新任務，已更新 TASK_QUEUE.json"
-
----
-
-## 使用 Orchestrator 模組
-
-Architect Agent 可以使用 `dev/pipeline/orchestrator/` 中的工具：
-
-### 任務佇列管理
-```python
-from dev.pipeline.orchestrator.task_queue import (
-    TaskQueue, Task, TaskStatus, TaskPriority, AgentType, TaskScope
-)
-
-# 載入任務佇列
-queue = TaskQueue("dev/pipeline/TASK_QUEUE.json")
-
-# 建立新任務
-new_task = Task(
-    id="TASK_022",
-    title="實作用戶登入 UI",
-    status=TaskStatus.PENDING,
-    priority=TaskPriority.P1,
-    scope=TaskScope(paths=["src/components/auth/"], files=[]),
-    dependencies=["TASK_021"],
-    assigned_agent=AgentType.FRONTEND
-)
-
-queue.add_task(new_task)
-queue.save()
-```
-
-### 依賴驗證
-```python
-from dev.pipeline.orchestrator.dependency_resolver import DependencyResolver
-
-resolver = DependencyResolver()
-
-# 添加任務和依賴
-resolver.add_task("TASK_022", dependencies=["TASK_021"])
-resolver.add_task("TASK_023", dependencies=["TASK_021", "TASK_022"])
-
-# 驗證無循環依賴
-if not resolver.validate_no_cycles():
-    cycle = resolver.get_cycle()
-    print(f"檢測到循環依賴: {cycle}")
-
-# 查看依賴圖
-print(resolver.visualize())
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/hooks/core-resolve.js" .collaboration/core/task-api.js create --title "實作用戶登入 UI" --description "..."   --priority P1 --role frontend --tags code
+node "${CLAUDE_PLUGIN_ROOT}/hooks/core-resolve.js" .collaboration/core/task-api.js update TASK_XXX --append --acceptance-criteria "..." --technical-notes "..."
 ```
 
-### 路徑鎖定檢查
-```python
-from dev.pipeline.orchestrator.lock_manager import PathLockManager
-
-lock_manager = PathLockManager("dev/pipeline/LOCK_STATE.json")
+每張卡寫明 scope_paths（精確路徑，避免並行衝突）、dependencies（不得循環）、requirements、acceptance_criteria。
 
-# 檢查路徑是否被鎖定
-if lock_manager.is_locked("src/components/auth/"):
-    holder = lock_manager.get_lock_holder("src/components/auth/")
-    print(f"路徑已被 {holder} 鎖定")
-```
+> "已建立 [N] 張任務卡：TASK_..."
 
 ---
 
@@ -284,7 +203,7 @@ if lock_manager.is_locked("src/components/auth/"):
    - TASK_023 → TASK_022
    - TASK_024 → TASK_022
 5. 撰寫接口規範
-6. 更新 TASK_QUEUE.json
+6. 以 task-api 建立任務卡
 ```
 
 ### 範例 2：處理並行開發

package/core/plugins/kenaz/skills/assessment_agent/SKILL.md

@@ -285,5 +285,4 @@ Agent 分析：
 ### 相關系統
 - `.rule/` - 規則系統（評估發現的重複問題可提升為規則）
 - `.failure/` - 失敗學習系統（評估時參考失敗經驗）
-- `.memory/` - 記憶系統（評估經驗可沉澱為記憶）
 - `dev/PRODUCT_SPEC.md` - 產品規格（功能評估對應 Feature ID）