kenaz 0.3.5 → 0.3.6

package/core/k-cli/test/TEST_SPEC.md

@@ -14,7 +14,7 @@ npm run build && npm test
 
 ## 前置條件
 
-- Claude CLI 可用（`task create` 和 `dispatch run` 會 spawnClaude）
+- Claude CLI 可用（`task create` 會 spawnClaude）
 - `npm run build` 必須先執行
 
 ## 測試環境
@@ -64,20 +64,8 @@ npm run build && npm test
 - `k-cli task get TASK_A --project-path test/sandbox/`
 - 驗證：輸出含 TASK_A 詳細資訊
 
-### Test 6: dispatch run（指定任務）
-- 使用 Test 5 的 TASK_A
-- `k-cli dispatch run TASK_A --project-path test/sandbox/`
-- 驗證：Ansuz 讀 role → 判斷陣型 → headless.js 執行，輸出含 TASK_A
-
-### Test 7: dispatch status（等待任務完成）
-- `k-cli dispatch status TASK_A --project-path test/sandbox/`
-- 輪詢直到任務完成（或 timeout）
-- 驗證：輸出含 TASK_A 相關資訊，最終狀態為 done
-
-### Test 8: dispatch run --auto（自動掃描）
-- `k-cli dispatch run --auto --project-path test/sandbox/`
-- 驗證：自動掃描 backlog，dispatch TASK_B 和 TASK_C（或剩餘待處理任務）
-- 驗證：輸出含掃描結果
+### Test 6-8: 已移除
+- `dispatch run` 已刪除（Formation headless 調度已退役），`dispatch status` 失去可驗證的前置動作，一併移出測試
 
 ### Test 9: task delete → verify
 - 使用 Test 5 的 TASK_A
@@ -99,11 +87,9 @@ npm run build && npm test
    - 驗證：輸出含 `dry-run`，不呼叫 spawnClaude
 3. `k-cli task delete TASK_B --project-path test/sandbox/ --dry-run`
    - 驗證：輸出含 `dry-run`，任務仍存在
-4. `k-cli dispatch run TASK_B --project-path test/sandbox/ --dry-run`
-   - 驗證：輸出含 `dry-run`，不呼叫 spawnClaude
-5. `k-cli specialist run --agent Amelia 測試 --project-path test/sandbox/ --dry-run`
+4. `k-cli specialist run --agent Amelia 測試 --project-path test/sandbox/ --dry-run`
    - 驗證：輸出含 `dry-run`，不呼叫 spawnClaude
-6. `k-cli project install k-cli --project-path test/sandbox/ --dry-run`
+5. `k-cli project install k-cli --project-path test/sandbox/ --dry-run`
    - 驗證：輸出含 `dry-run`
 
 ## 結果格式
@@ -116,9 +102,6 @@ k-cli Test Suite
 [ 3/11] project status        ✅ PASS
 [ 4/11] specialist list       ✅ PASS
 [ 5/11] task create × 3       ✅ PASS
-[ 6/11] dispatch run           ✅ PASS
-[ 7/11] dispatch status        ✅ PASS
-[ 8/11] dispatch run --auto    ✅ PASS
 [ 9/11] task delete             ✅ PASS
 [10/11] specialist run Amelia  ✅ PASS
 [11/11] --dry-run              ✅ PASS

package/core/k-cli/test/run.sh

@@ -280,62 +280,6 @@ test_5_task_create() {
   return 0
 }
 
-# =========================================
-# Test 6: dispatch run (specific task)
-# =========================================
-test_6_dispatch_run() {
-  local task_id
-  task_id=$(cat "$SANDBOX/.test_task_a" 2>/dev/null) || { echo "  No TASK_A from test 5"; return 1; }
-  log "  Dispatching: $task_id"
-
-  run_cmd $KCLI dispatch run "$task_id" --project-path "$SANDBOX"
-  local output="$LOG_CMD_OUTPUT"
-  assert_contains "dispatch run" "$output" "$task_id" || return 1
-  return 0
-}
-
-# =========================================
-# Test 7: dispatch status (wait for done)
-# =========================================
-test_7_dispatch_status() {
-  local task_id
-  task_id=$(cat "$SANDBOX/.test_task_a" 2>/dev/null) || { echo "  No TASK_A from test 5"; return 1; }
-
-  # Poll up to 10 times (10 sec intervals)
-  local i output
-  for i in $(seq 1 10); do
-    log "  --- Poll $i/10 ---"
-    run_cmd $KCLI dispatch status "$task_id" --project-path "$SANDBOX"
-    output="$LOG_CMD_OUTPUT"
-    if echo "$output" | grep -qi "done\|complete\|finished"; then
-      log "  ✓ Task completed"
-      return 0
-    fi
-    sleep 10
-  done
-
-  # After polling, still check if task is in done dir
-  if [ -d "$SANDBOX/.kenaz/tasks/done/$task_id" ]; then
-    log "  ✓ Task found in done dir"
-    return 0
-  fi
-
-  # Accept any output containing the task ID as partial pass
-  assert_contains "dispatch status" "$output" "$task_id" || return 1
-  return 0
-}
-
-# =========================================
-# Test 8: dispatch run --auto
-# =========================================
-test_8_dispatch_auto() {
-  run_cmd $KCLI dispatch run --auto --project-path "$SANDBOX"
-  local output="$LOG_CMD_OUTPUT"
-  # Should scan backlog and attempt to dispatch remaining tasks
-  assert_contains "dispatch auto" "$output" "backlog\|scan\|dispatch\|TASK_\|no.*task\|0 " || return 1
-  return 0
-}
-
 # =========================================
 # Test 9: task delete -> verify
 # =========================================
@@ -412,19 +356,12 @@ test_11_dry_run() {
   output="$LOG_CMD_OUTPUT"
   assert_contains "delete dry-run" "$output" "dry-run\|dry.run\|dryRun" || return 1
 
-  # 4. dispatch run --dry-run
-  log "  --- dry-run: dispatch run ---"
-  run_cmd $KCLI dispatch run "$tb" --project-path "$SANDBOX" --dry-run
-  output="$LOG_CMD_OUTPUT"
-  assert_contains "dispatch dry-run" "$output" "dry-run\|dry.run\|dryRun" || return 1
-
-  # 5. specialist run --dry-run
   log "  --- dry-run: specialist run ---"
   run_cmd $KCLI specialist run --agent Amelia "test" --project-path "$SANDBOX" --dry-run
   output="$LOG_CMD_OUTPUT"
   assert_contains "specialist dry-run" "$output" "dry-run\|dry.run\|dryRun" || return 1
 
-  # 6. project install --dry-run
+  # 4. project install --dry-run
   log "  --- dry-run: project install ---"
   run_cmd $KCLI project install k-cli --project-path "$SANDBOX" --dry-run
   output="$LOG_CMD_OUTPUT"
@@ -441,9 +378,6 @@ run_test 2  "ping"                   test_2_ping
 run_test 3  "project status"         test_3_project_status
 run_test 4  "specialist list"        test_4_specialist_list
 run_test 5  "task create x3"         test_5_task_create
-run_test 6  "dispatch run"           test_6_dispatch_run
-run_test 7  "dispatch status"        test_7_dispatch_status
-run_test 8  "dispatch run --auto"    test_8_dispatch_auto
 run_test 9  "task delete"            test_9_task_delete
 run_test 10 "specialist run Amelia"  test_10_specialist_run
 run_test 11 "--dry-run"              test_11_dry_run

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

@@ -23,6 +23,7 @@ ARGUMENTS 含 `[專案: X]` 或 `--project-path X` → PROJECT_PATH = X，下方
 - 有**對照組**：證明測試在舊程式上會失敗，或修改前後結果不同。
 - subagent 回報「未驗證」的項目，由你補驗或明講仍未驗證。
 - 合併：`git merge` 後跑相關測試（或 `node "${CLAUDE_PLUGIN_ROOT}/hooks/core-resolve.js" .specialist/Ansuz/tools/verify-and-land.js`），用這個專案自己的測試指令。
+- 檔案長度：verify-and-land 合併前會跑 `check-file-size`（警告 1000 / 上限 2000 行，既有超長檔只擋「未配套拆分的增長」）；被擋就按職責拆成 module / component / hook。
 - 只在 Kenaz 核心 repo 本身：Rust 測試走 `npm run test:rust` / `dev/scripts/rust-verify-worktree.js`。
 
 ## 回報

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kenaz",
-  "version": "0.3.5",
+  "version": "0.3.6",
   "description": "Install Kenaz (plugin, hooks, kenaz-server) for Claude Code and Codex: npx kenaz install",
   "bin": {
     "kenaz": "bin/kenaz.js"
@@ -20,11 +20,11 @@
     "test": "node --test lib/cli.test.js"
   },
   "optionalDependencies": {
-    "@kenazai/server-darwin-arm64": "0.3.5",
-    "@kenazai/server-darwin-x64": "0.3.5",
-    "@kenazai/server-linux-arm64": "0.3.5",
-    "@kenazai/server-linux-x64": "0.3.5",
-    "@kenazai/server-win32-x64": "0.3.5"
+    "@kenazai/server-darwin-arm64": "0.3.6",
+    "@kenazai/server-darwin-x64": "0.3.6",
+    "@kenazai/server-linux-arm64": "0.3.6",
+    "@kenazai/server-linux-x64": "0.3.6",
+    "@kenazai/server-win32-x64": "0.3.6"
   },
   "license": "UNLICENSED",
   "repository": {

package/core/.formation/legion/forge.yaml

@@ -1,299 +0,0 @@
-skill: forge
-formation: legion
-version: "1.0"
-
-name: Forge
-description: |
-  順序流水線：設計 → 打造 → 淬煉。
-  一個人設計藍圖，多個人照藍圖打造，一個人驗收淬煉。
-  每個階段的產出是下一階段的輸入。階段之間有回饋循環 — 打造時發現設計問題可以即時回報修正。
-  這是 Legion 最經典的模式：有序、有回饋、有品質把關。
-
-# ─────────────────────────────────────────
-# 溝通模式（核心設計）
-# ─────────────────────────────────────────
-
-topology: pipeline
-# designer → implementer(s) → reviewer
-#     ↑ 回饋修正 ←─────────────↓
-
-communication:
-  core_pattern: |
-    順序傳遞 + 回饋循環：
-    1. Designer 產出藍圖（介面契約、架構設計、遷移計劃）
-    2. Implementer(s) 按藍圖執行，遇到問題即時回報 Designer
-    3. Reviewer 驗收每個 Implementer 的產出，不通過則打回修正
-    4. 全部通過後，Reviewer 通知 Team Lead
-
-  triggers:
-    - name: 藍圖發布
-      when: Designer 完成或更新設計
-      who: designer → all implementers + reviewer
-      content: 介面契約、架構設計、分工建議
-
-    - name: 問題回報
-      when: Implementer 發現藍圖有問題（設計不可行、漏洞、矛盾）
-      who: implementer → designer
-      content: 問題描述、影響範圍、建議修正
-
-    - name: 跨邊界通知
-      when: Implementer 修改了影響其他 Implementer 的介面
-      who: implementer → implementer
-      content: 修改的介面、舊 → 新、需要對方配合的變更
-
-    - name: 完成通知
-      when: Implementer 完成分配的工作
-      who: implementer → reviewer
-      content: 完成的模組、修改的檔案、風險點
-
-    - name: 審查結果
-      when: Reviewer 完成審查
-      who: reviewer → implementer
-      content: 通過 / 需修正（附具體問題和位置）
-
-    - name: 全部通過
-      when: 所有 Implementer 的產出都通過審查
-      who: reviewer → team-lead
-      content: 審查摘要、整體品質評估
-
-  broadcast_policy: |
-    只在以下情況 broadcast：
-    - 藍圖有破壞性變更（所有人都要更新認知）
-    - Team Lead 調整分工
-    其他一律用 message 直接溝通。
-
-# ─────────────────────────────────────────
-# 成員定義（動態，由 Lead 根據任務決定）
-# ─────────────────────────────────────────
-
-members:
-  roles:
-    - id: designer
-      name: Designer
-      count: 1
-      description: |
-        設計藍圖的人。可以是架構師、API 設計師、遷移規劃者 — 取決於任務。
-        核心產出：藍圖（介面契約、架構圖、遷移步驟、分工建議）。
-      responsibilities:
-        - 分析需求，設計解決方案
-        - 定義介面契約（型別、函數簽名、模組邊界）
-        - 規劃實作順序和分工建議
-        - 回應 Implementer 的問題回報，必要時更新藍圖
-      sends_to: [implementers, reviewer]
-      receives_from: [implementers, reviewer]
-
-    - id: implementer
-      name: Implementer
-      count: "1-3（由 Lead 根據任務規模決定）"
-      description: |
-        按藍圖打造的人。拿到 Designer 的藍圖和分配的範圍，執行實作。
-        發現問題即時回報 Designer，不要自己猜。
-      responsibilities:
-        - 按藍圖和分配的範圍執行實作
-        - 更新所有受影響的引用和依賴
-        - 跨邊界變更時通知其他 Implementer
-        - 完成後通知 Reviewer
-      sends_to: [designer, other_implementers, reviewer]
-      receives_from: [designer, other_implementers, reviewer]
-
-    - id: reviewer
-      name: Reviewer
-      count: 1
-      description: |
-        淬煉品質的人。驗收每個 Implementer 的產出，確保符合藍圖、無遺漏、品質達標。
-        發現問題直接打回對應 Implementer，架構層級問題升級給 Designer。
-      responsibilities:
-        - 審查每個 Implementer 的產出
-        - 驗證介面一致性（新介面在所有消費端正確使用）
-        - 檢查舊名稱/舊路徑殘留
-        - 執行測試，確認不破壞現有功能
-      sends_to: [implementers, designer, team-lead]
-      receives_from: [implementers, designer]
-
-# ─────────────────────────────────────────
-# 生命週期
-# ─────────────────────────────────────────
-
-lifecycle:
-  phases:
-    - phase: design
-      description: Designer 分析需求、產出藍圖
-      lead_actions:
-        - 建立團隊（TeamCreate）
-        - 派出 Designer
-        - 等待藍圖產出
-      exit_criteria:
-        - Designer 產出完整藍圖（介面契約 + 分工建議）
-        - Lead 確認藍圖合理
-
-    - phase: build
-      description: Implementer(s) 按藍圖執行，Reviewer 同步就位
-      lead_actions:
-        - 根據藍圖的分工建議，派出 Implementer(s) 和 Reviewer
-        - Broadcast 藍圖給所有成員
-        - 監控跨邊界溝通，協調衝突
-      member_actions:
-        - Implementer(s) 按分配的範圍執行
-        - 遇到問題 → SendMessage 給 Designer
-        - 完成 → SendMessage 給 Reviewer
-        - Reviewer 逐一審查
-
-    - phase: temper
-      description: 全面驗證、修正、淬煉品質
-      lead_actions:
-        - 確認所有 Implementer 的產出通過 Reviewer 審查
-        - 處理未通過的修正循環（Reviewer → Implementer → Reviewer）
-        - 全量測試
-      exit_criteria:
-        - 所有模組通過審查
-        - 無編譯/型別錯誤
-        - 測試通過
-        - Grep 確認無舊名稱殘留
-
-    - phase: teardown
-      description: 收集成果、關閉團隊
-      lead_actions:
-        - 收集 Designer 的藍圖文件
-        - 收集 Implementer 的變更清單
-        - 收集 Reviewer 的審查結果
-        - 整合為完成報告
-        - shutdown_request 給所有成員
-
-# ─────────────────────────────────────────
-# 輸入輸出
-# ─────────────────────────────────────────
-
-input:
-  required:
-    - task: 任務 ID 或描述
-  optional:
-    - blueprint: 已有的設計藍圖（如有，跳過 design 階段）
-    - scope: 限制範圍
-    - preserve: 不可修改的檔案或介面
-
-output:
-  primary: |
-    完成報告：
-    - 藍圖摘要（Designer 產出）
-    - 修改的檔案列表（按 Implementer 分組）
-    - 審查結果（Reviewer 產出）
-    - 測試結果
-  secondary: |
-    - 發現但未處理的技術債
-    - 建議的後續任務
-
-# ─────────────────────────────────────────
-# 行為準則（Team Lead）
-# ─────────────────────────────────────────
-
-behavior:
-  - 先 design 再 build — 不要跳過藍圖直接開工
-  - Designer 的藍圖是唯一的真相來源（single source of truth）
-  - Implementer 之間的分工要明確，避免改同一個檔案
-  - Reviewer 說「需修正」時，必須修完才能進入 temper
-  - 控制團隊規模：1 Designer + 1~3 Implementers + 1 Reviewer（最多 5 人）
-  - 結束前用 Grep 掃描舊名稱殘留
-
-# ─────────────────────────────────────────
-# 成員 Prompt 模板
-# ─────────────────────────────────────────
-
-member_prompts:
-  designer: |
-    ## Role
-    你是 Forge 的 Designer — 鍛造的第一步，設計藍圖。
-
-    ## 你的職責
-    - 分析需求，設計解決方案
-    - 產出藍圖：介面契約、架構設計、實作步驟、分工建議
-    - 回應 Implementer 的問題回報
-
-    ## 溝通
-    - 藍圖完成 → broadcast 給所有成員
-    - 收到問題回報 → 評估後更新藍圖並通知
-    - 藍圖有破壞性變更 → broadcast
-
-    ## 任務
-    {designer_task_description}
-
-  implementer: |
-    ## Role
-    你是 Forge 的 Implementer — 鍛造的核心，按藍圖打造。
-
-    ## 你的職責
-    - 按 Designer 的藍圖執行你負責的部分
-    - 更新所有受影響的引用和依賴
-    - 發現問題即時回報 Designer，不要自己猜
-
-    ## 溝通
-    - 跨邊界變更 → SendMessage 給其他 Implementer
-    - 發現藍圖問題 → SendMessage 給 Designer
-    - 完成 → SendMessage 給 Reviewer
-    - 收到審查意見 → 修正後回覆 Reviewer
-
-    ## 你負責的範圍
-    {implementer_scope}
-
-    ## 藍圖
-    {blueprint}
-
-  reviewer: |
-    ## Role
-    你是 Forge 的 Reviewer — 鍛造的最後一步，淬煉品質。
-
-    ## 你的職責
-    - 審查每個 Implementer 的產出
-    - 驗證介面一致性
-    - 檢查舊名稱/舊路徑殘留
-    - 執行測試
-
-    ## 溝通
-    - 審查通過 → SendMessage 給對應 Implementer 確認
-    - 需要修正 → SendMessage 給對應 Implementer（附問題詳情）
-    - 架構問題 → SendMessage 給 Designer
-    - 全部通過 → SendMessage 給 team-lead
-
-    ## 藍圖
-    {blueprint}
-
-# ─────────────────────────────────────────
-# 任務系統整合
-# ─────────────────────────────────────────
-
-collaboration:
-  task_api: node .collaboration/core/task-api.js
-
-  workflow:
-    - step: 讀取任務
-      run: node .collaboration/core/task-api.js get {task_id}
-
-    - step: 認領任務
-      run: node .collaboration/core/task-api.js claim {task_id}
-
-    - step: design 階段
-      actions:
-        - 建立團隊（TeamCreate）
-        - 派出 Designer 分析並設計
-        - 等待藍圖產出
-
-    - step: build 階段
-      actions:
-        - 根據藍圖分工，派出 Implementer(s) 和 Reviewer
-        - Broadcast 藍圖
-        - 監控溝通，協調衝突
-
-    - step: temper 階段
-      actions:
-        - 確認所有產出通過審查
-        - 處理修正循環
-        - 全量測試
-
-    - step: teardown
-      actions:
-        - 收集成果，關閉團隊
-
-    - step: 完成任務
-      run: node .collaboration/core/task-api.js complete {task_id}
-
-  on_blocked:
-    run: node .collaboration/core/task-api.js move {task_id} blocked