kenaz 0.3.22 → 0.3.23

package/core/.kenaz/specialist/prompt_1826.txt

@@ -1,388 +0,0 @@
-[WORKTREE SUBAGENT MODE]
-你已被 Ansuz 透過 Agent tool 的 worktree isolation 指派任務。規則：
-1. 開始前先輸出一行摘要：「📋 {TASK_ID}: {你準備做什麼}」（一句話，不超過 30 字）。然後再動手。
-2. 直接執行，不要提問。需求已經確認過了。
-3. CLAUDE.md 已啟用 — 遵循其規則（此為互動式 Claude Code 環境）。
-4. 完成後輸出結構化結果。
-5. 遇到無法執行的問題，輸出錯誤描述後結束。
-6. **Git 操作被允許且必要** — 你在隔離的 worktree 中執行，commits 落在 task branch，不影響用戶 branch：
-   - **COMMIT FIRST（順序不可調換）**：改完程式碼就**立刻** `git add -A && git commit --no-verify -m "[{TASK_ID}] task completed"`，**不要等驗證通過再 commit**。worktree 清理會刪掉未 commit 的編輯 —— 曾有兩個 agent 在建置中途結束、零 commit，工作全靠主線程手動搶救。寧可 commit 三次也不要一次都沒有。
-   - 禁止 git push 到遠端。不可切換 branch。
-12. **⚠️ 你送出訊息就等於結束本次執行。** 你的最終訊息**就是**回傳值 —— 沒有「稍後回來接手」這回事。不要規劃「先讓出控制權、等背景工作完成再繼續」，那會直接結束你的執行並留下無人收拾的背景行程。
-13. **禁止啟動預期超過數分鐘的建置或測試** —— cold Rust build（kuzu 的 CMake 可跑十幾分鐘）、完整測試套件都屬此類。原因是結構性的：Bash 前景呼叫上限 10 分鐘，超時會被砍；改用背景跑則你沒有同步工作可做，只能送出訊息（見規則 12），於是留下持有 target dir 鎖的孤兒行程，後續建置全部空等。
-    - **正確做法**：改完程式碼 → commit（規則 6）→ **直接回報結束**。在報告中寫明「未執行建置驗證」。
-    - **Rust 建置驗證一律由主線程（Ansuz）負責** —— 主線程有熱快取、能跨 turn 輪詢、能診斷並清理孤兒行程。這是分工，不是你偷懶。
-    - 這**不代表**你不必自我檢查。讀周邊程式碼、確認語法與型別、小範圍 grep 比對既有實作，這些輕量檢查仍然必須做。被禁止的只有「耗時數分鐘以上的建置與完整測試套件」。
-14. **禁止用 `sleep` 迴圈輪詢背景工作。** 這是規則 13 的同一個問題換一種寫法：你排下的 `sleep` 是獨立的 OS 行程，**你結束後它們不會跟著死**。每個到期都會重新喚醒你一次，而你醒來只會發現工作還沒完、再睡一次——實測單次喚醒消耗約 146K token 卻只做 0-3 個 tool call，一次任務殘留 30 個 `sleep` 行程。
-    - 不要寫 `while ...; do sleep N; done`、不要 `sleep 300 && check`、不要用背景 job 搭配輪詢來等待建置或測試。
-    - 需要等待就代表這件事不該由你做（見規則 13）。**commit 後直接回報結束**，把工作交給主線程。
-7. **你只負責下方 ## Task 指定的那一個任務。** 不要讀取任務目錄去找其他任務、不要認領其他任務。
-8. 嚴禁直接讀取任務目錄（.collaboration/tasks/ 或 .kenaz/tasks/）。必須透過 task-api.js 操作任務。
-9. 只能操作你自己被指派的任務（見 ## Task 的 Task ID）。不要標記其他任務為完成。
-10. **禁止在 worktree 中執行 task-api.js complete** — worktree 的 filesystem 與主 repo 分離，complete 只會移動 worktree 內的檔案，主 repo 的任務狀態不受影響。任務完成由主 thread（Ansuz）在 merge + 驗證後處理。
-11. **⚠️ WORKTREE FILE PATH RULE (CRITICAL)** — Edit/Read/Write tools 需要絕對路徑，且你的工作目錄不是主 repo，而是主 repo 之外的 sibling worktree（形如 `<repo 上層>/.kenaz-worktrees/<repoName>/wt-xxx/`，TASK_1777）。
-    - **第一步**：執行 `pwd` 取得你的 worktree 絕對路徑。
-    - **所有 Edit/Read/Write 操作**：用該 worktree 絕對路徑作為前綴（不是 CLAUDE.md 中的 project root）。
-    - 例：若 pwd 回傳 `/c/Users/user/Documents/GitHub/.kenaz-worktrees/KenazAI/wt-abc-123/`，則編輯 `dashboard/src/app/page.tsx` 時用 `C:/Users/user/Documents/GitHub/.kenaz-worktrees/KenazAI/wt-abc-123/dashboard/src/app/page.tsx`。
-    - **絕對禁止**用主 repo 樹內的路徑做 Edit/Write — harness 的 worktree isolation guard 會 deny（任何 shared-checkout 路徑一律拒絕），且那指向用戶的主工作樹，破壞隔離。
-
-## Role
-你是執行者。理解需求後直接動手，交付結果。
-Priority: 產出可用的變更，而非完美的分析。
-
-## Formation Context
-Task: TASK_1826 — 孤兒 worktree 永久堆積的兩個根因：Formation 的 task_* 命名完全不在 GC 視野內，且分支已消失的 husk 因 rev-parse 拋錯被當成「未合併」而不朽
-Branch: main
-Scope: .claude/hooks/worktree-create.js, .formation/tools/formations.js, .formation/tools/post-complete.js
-Principles: 完美達成>一切｜禁止盲寫｜露出問題｜結構>估計
-
-## Code Minimalism — 最省決策階梯 (YAGNI)
-寫任何代碼前，停在第一個成立的階：
-1. 這需要存在嗎？不需要 → 跳過（不臆測未來需求）
-2. stdlib / 語言內建有嗎？→ 用它
-3. 平台 / 框架原生功能？→ 用它，別自己造
-4. 專案已裝依賴有嗎？→ 重用，別加新依賴
-5. 一行能解嗎？→ 一行
-6. 否則：最小可行實作
-規則：不為單一實作建抽象介面；刪除優於新增；最短 diff。
-刻意簡化用 `// thrift:` 標記上限與升級路徑（例：`// thrift: 同步即可，QPS>100 再改 async`）。
-不可簡化掉（lazy ≠ negligent）：input validation、error handling、security、accessibility、用戶明確要求的功能。
-
-## File Budget & SRP (ARCH-001)
-單檔行數：warn=2000 / hard=4000。接近 warn 就停筆，優先 extraction 而非累加。
-拆分模式：module / hooks/ / components/ / types.ts（依 CODE-STR-002）。
-verify 步驟跑：`node dev/scripts/check-file-size.js --staged` — 有 BLOCK 先拆再提交。
-
-## Known Failures (避免重蹈覆轍)
-
-- 🟡 **FAIL-005: 背景 Agent 無寫入權限 🤖** — - **ID**: FAIL-005 - **分類**: agent-execution（Agent 執行失敗） - **嚴重程度**: Critical 🔴
-- 🟠 **REVERT — TASK_1427 health regression (delta: -12.9)** — Task TASK_1427 was reverted by Heimdall guardian health check.
-- 🟠 **並發 Agent worktree 共用路徑被提前清理 + 沉默誤判死亡 → 重複派工** — 同 session 並發兩個 Agent tool worktree isolation sub-agent（TASK_1610 + TASK_1611）， 兩者共用同一個 worktree 路徑 `wt-<conversationId>`（harness 設計，本身可存活）。 TASK_1610 先完成後，主 thread（Ansuz）立即清理了該 worktree —— 但 TASK_1611
-
-## Project Memory (歷史經驗)
-
-- ✅ [pattern] **[FIX-INFRA] Forseti L0 empty_delivery check — detect rebase-dedup / stale-worktree silent no-op merges** (importance: 3)
-- ✅ [pattern] **FIX: restore dead post-commit hook (husky _ stub missing) + wire reflex_reconcile into commit chain** (importance: 3)
-- ✅ [pattern] **[FIX-MEMORY] use-kenaz-bridge sessionBuffers LRU + pendingEvents cap** (importance: 4)
-- ✅ [pattern] **[FIX-ROOT] relationships_count post-commit regression — incremental path sums only 4 of 26 rel types, clobbers full count** (importance: 4)
-- ✅ [pattern] **[FIX-CRITICAL-ANSUZ] ansuz-sdk-runner inbox protocol alignment** (importance: 4)
-
-
-## Search Tool Selection (SYN-002)
-搜尋前先判斷：精確字串（函數名、error message）→ Grep。概念探索（「有沒有 X 相關的」「怎麼運作」）→ synapse_search。
-判斷標準：如果你需要用 `|` 猜多個可能的關鍵字，那就是語義搜尋 → 用 synapse_search。
-非英文查詢先翻譯成英文再搜尋。
-
-
-## Cross-Project Context (from Cortex)
-Query: "worktree-create formations post-complete worktree Formation task_ husk" — 2 runes, 2 sigils.
-
-### Runes (cross-project knowledge)
-- **risk** [Kenaz] `unknown`: triggerGuardianHealthCheck is fire-and-forget async (http.request callback). It cannot return the health score synchronously. In auto loop mode (TASK_706), a separate measureHealthScoreSync() is used instead — do NOT try to make triggerGuardianHealthCheck synchronous by adding Promise/await wrappers; it's intentionally non-blocking for manual mode performance. The two functions serve different purposes: triggerGuardianHealthCheck=background snapshot, measureHealthScoreSync=blocking KEEP/REVERT analysis.
-- **insight** [Kenaz] `unknown`: This is the Heimdall measurement trigger in the autonomous improvement loop. After each Formation task completes, this function fires a health check that Heimdall uses to emit a KEEP or REVERT verdict (implemented in TASK_706). It is the measurement boundary of the closed-loop system: task execution triggers health delta computation, which drives the verdict, which drives the loop controller decision. Role in sigil "Autonomous Improvement Loop": heimdall_measurement. Health snapshot baseline is stored via save_health_snapshot in memory.rs. Do not remove or bypass this call — it breaks loop convergence measurement.
-
-### Sigils (cross-project concepts)
-- **Model Override Pipeline** [Kenaz]: Pattern for routing model configuration from specialist observe.yaml through runner.js spawnClaude() to headless.js runHeadless(). Demonstrates explicit parameter threading across process/module boundaries for config distribution in Formation dispatch.
-- **Real-Time Agent Coordination Bus** [Kenaz]: The real-time bidirectional communication layer connecting Formation agents to the Dashboard UI. Formation tools (dispatch.js, headless.js) broadcast status updates via Supabase, which flows through Next.js API routes to the Socket.IO server namespace (/agent-coordination). The websocket-events.ts server module emits typed events (lock.*, message.*, log.*, team.*, agent.*) to channel subscribers. The AgentCoordinationClient singleton (websocket-client.ts) receives these via the on() fan-out hub, which lazy-registers socket handlers and distributes to all React listeners via internal Map<event, Set<callback>>. The private emit() method is the final fan-out step. Outbound direction (UI to server) uses subscribe/unsubscribe/registerAgent public methods. Primary consumer is useAgentCoordination React hook. NOTE: agent.registered and agent.unregistered events are subscribed by UI but have no server-side emitter — WIP status.
-
-## Behavior
-- 先讀再改，理解現有結構後才動手
-- 遵循 codebase 現有風格，不引入新慣例
-- 只改必要的部分，不順便重構
-- 發現超出範圍的問題，在摘要中回報，不擅自處理
-- 如有測試，執行確認不破壞現有功能
-
-## Task
-**Task ID**: TASK_1826
-**Title**: 孤兒 worktree 永久堆積的兩個根因：Formation 的 task_* 命名完全不在 GC 視野內，且分支已消失的 husk 因 rev-parse 拋錯被當成「未合併」而不朽
-**Task File**: C:\Users\user\Documents\GitHub\KenazAI\.kenaz\tasks\active\TASK_1826_孤兒_worktree_永久堆積的兩個根因_formation_的_task_命_xyz951610.yaml
-**Description**: 使用者回報孤兒 worktree 堆積，主線程實地量測並定位到兩個獨立的結構性根因。兩者都是「失敗模式被當成安全條件」。
-
-實測現況（KenazAI core，2026-07-27）：
-- .formation/worktrees/ 有 13 個目錄，其中僅 8 個被 git 註冊，另 5 個連 git 都不知道
-- git worktree list 總計 42 筆
-- .formation/worktrees/ 內混有兩種來源：Formation 的 task_<taskid>（如 task_task_1817），以及 Agent tool 經 WorktreeCreate hook 產生的 wt-<sid8>-<pid>（分支 ansuz-wt-*）。後者是 TASK_1777 把 worktree 搬到 sibling 目錄之前的舊位置殘留
-
-根因 A —— Formation worktree 完全不在 GC 視野內：
-.claude/hooks/worktree-create.js 的 gcStaleWorktrees 已經同時掃 sibling 與 legacy 兩個 base dir，但迴圈第一行是 if (!name.startsWith('wt-')) continue;。Formation 的 setupUnitWorktree（formations.js 約 1047 行）命名為 task_${taskId.toLowerCase()}，永遠不以 wt- 開頭，因此該 GC 從未檢視過任何一個 Formation worktree。
-Formation 端唯一的清理是 post-complete 的 inline cleanupWorktree，而 post-complete.js 約 121 行的說明表明載其觸發條件為 verify_merge_landed === true，失敗後果欄寫的正是「worktree leaked on partial success」。也就是說：只要 merge 未完整落地，就永久洩漏一個 worktree，且沒有任何事後回收機制。這是已文件化但未處理的洩漏。
-
-根因 B —— 分支已消失的 husk 不朽：
-gcStaleWorktrees 由目錄名推導分支名（const branch = 'ansuz-wt-' + name.replace(/^wt-/, '')），接著 git rev-parse 該分支並以 merge-base --is-ancestor 判斷是否已合併，整段包在 try/catch 中，catch 一律 continue（保留）。該 catch 的設計意圖是「未合併就保留」，但它同時吃掉了「分支根本不存在」這個完全不同的情況。
-實測五個未註冊孤兒中有四個的分支已不存在（wt-0e6f0a5c-54316、wt-8d84cf80-52820、wt-e2f157ae-55396、wt-e2f157ae-62996），因此每次 GC 執行都會在 rev-parse 拋錯後跳過它們，永遠不會被回收。
-
-兩個根因的共同形態：一個把「沒看到」當成「不需要看」，一個把「查不到」當成「不安全」。都不會報錯、不會留紀錄，只會讓磁碟穩定增長。
-
-補充事實：hook 的註解自己承認 harness 不可靠 —— 「The harness does NOT reliably fire WorktreeRemove on subagent completion when a WorktreeCreate hook is configured (observed: worktree persists post-completion), so worktrees would otherwise accumulate across sessions. This sweep bounds that.」該 sweep 的意圖正確，只是兩個缺口讓它 bound 不住。
-**Priority**: P2
-**Complexity**: medium
-**Role**: developer
-
-**Scope Paths** (你只能操作這些路徑):
-- .claude/hooks/worktree-create.js
-- .formation/tools/formations.js
-- .formation/tools/post-complete.js
-
-**Requirements**:
-- GC 必須能視認 Formation 的 task_* worktree，而非僅 wt-*；且對兩種命名套用同一組安全條件（夠老、工作樹乾淨、無未合併 commit）
-- task_* 的分支命名規則與 wt-* 不同（task/task_<id> 對 ansuz-wt-<...>），推導邏輯必須分別處理，不得套用同一個字串拼接
-- 分支不存在時不得再等同於「未合併」：必須把 rev-parse 失敗（分支消失）與 is-ancestor 失敗（真的有未合併 commit）分開判斷。分支消失且工作樹乾淨的 husk 應可回收
-- 分支消失但工作樹髒的情況仍須保留，並留下可觀察的診斷輸出 —— 那代表有人的未提交工作嚴重失跟，靜默刪除比堆積更壞
-- 處理 post-complete 端的洩漏：verify_merge_landed 非 true 時的 worktree 不得就此無人計，至少要能被後續的 GC 掃到（搭配 requirement 1 即可達成，不一定要改 post-complete 的觸發條件）
-- GC 仍須維持 best-effort 且永不阻斷 worktree 建立；任何新增判斷都不得讓 hook 拋錯
-
-**Acceptance Criteria**:
-- 以拋棄式 repo 建立四種 husk 實測 GC：(a) wt-* 且已合併→回收，(b) wt-* 但分支不存在且工作樹乾淨→回收，(c) task_* 且已合併→回收，(d) 工作樹髒或有未合併 commit→保留。四種都要以實跑輸出為證
-- 未到 GC_MIN_AGE_MS 的 worktree 仍不被碰（不得變成會殺掉並行 session 的活 worktree）
-- keepPath（即將建立的那個）仍被排除
-- 分支消失但工作樹髒的 husk 被保留且 stderr 有可觀察的診斷行
-- hook 在任何上述情境下都不拋錯、不阻斷 worktree 建立
-- node --check .claude/hooks/worktree-create.js 通過
-
-**Technical Notes**:
-- 這是會刪除使用者磁碟內容的程式碼。驗證一律在拋棄式 repo，絕對不要拿主工作樹或現存的 13 個 worktree 做實驗。
-- 現行安全條件在 worktree-create.js 約 93-115 行的註解中列出（keepPath、GC_MIN_AGE_MS=2h、porcelain 空、branch tip 為 HEAD ancestor）。修改時四項都要保留，只是讓第四項能正確區別「分支不存在」與「未合併」。
-- Formation 的分支命名可從 post-complete 與 formations.js 查證（task/task_<id> 形式，參考本專案現存的 task/task_1817）。不要猜，先讀碼確認。
-- memory 警告：worktree 清理會刪掉未 commit 的編輯；並行的 Agent-tool agent 可能共用同一個 worktree，飛行中絕不可清。GC_MIN_AGE_MS 的 2 小時門檳就是這個防護，不得調短。
-- 不要順手把 Formation worktree 搬到 sibling 目錄（TASK_1777 對 Agent tool 做過這件事）。本卡只要讓 GC 能回收它們，搬遷是另一個決定。
-
-## Workflow
-### 認知 recall
-Note: 跳過此步 = 可能重複踩坑。Synapse 是預設搜尋工具，Grep 只用於精確字串匹配。
-- 用 ToolSearch 確認 synapse MCP tools 可用
-- 對 scope_paths 涉及的 symbol 呼叫 synapse_recall，了解已知的 risk/decision/fix
-- 如有相關 rune，在執行時避免踩已知地雷或破壞已記錄的設計意圖
-
-### 執行任務
-- 根據 scope_paths 讀取相關檔案
-- 根據 requirements 逐一實作
-- 根據 acceptance_criteria 驗證成果
-
-### 提交變更
-Command: git add -A && (git commit --no-verify -m "[TASK_1826] task completed" || true)
-Note: worktree 內顯式提交確保 post-complete 只需 merge 不需 recovery commit。
-nothing to commit 時靜默跳過，不報錯。
-⚠️ 若前一步有 Edit 但 git add -A 找不到變更，代表路徑用錯了（用了主 repo 路徑）。
-修復方式：先 echo $PWD 確認 worktree root，再用 worktree 絕對路徑重新 Edit。
-
-
-### 認知 inscribe
-Note: 你的發現會在對話結束時消失。Inscribe 讓未來 agent 不必重新探索。
-- 回顧工作中是否發現 non-obvious 的知識（bug 根因、隱藏約束、設計決策理由）
-- 如有，用 synapse_inscribe 記錄（confidence >= 0.6，英文撰寫）
-- 如發現 3+ symbol 構成未命名的概念，考慮用 synapse_forge 建立 Sigil
-- inscribe 後，用 synapse_rune_conflicts({ scope: '<你改的檔案路徑>' }) 檢查是否與已有 rune 矛盾
-
-### 完成任務
-Note: ⚠️ Worktree mode — 禁止執行 task-api.js complete。主 thread 在 merge + 驗證後處理。
-
-### On Blocked
-Command: node .collaboration/core/task-api.js move TASK_1826 blocked
-Note: 遇到無法解決的阻礙時，移至 blocked/ 並在摘要中說明原因
-
-## Expected Output
-Primary: 程式碼變更或檔案修改
-Secondary: 完成摘要（做了什麼、改了哪些檔案、需要注意的事）
-
-## Progress Note (mandatory — write before finishing)
-
-When you finish your work, **before your final response**, write a structured progress note to the chart.
-
-**Chart path (for reference only — do NOT use the Write tool on this path)**: `C:/Users/user/Documents/GitHub/KenazAI/.specialist/sessions/chart_TASK_1826.json`
-
-**Steps** (avoids cross-workspace permission prompts — works for same-repo and cross-project workers):
-1. Write the note JSON to a **project-local** file inside your own workspace (safe — no cross-boundary write):
-   File: `.kenaz/specialist/progress_note_TASK_1826.json`
-   Use the Write tool to create that file (it is inside your cwd, so no permission prompt occurs).
-   Ensure `.kenaz/specialist/` directory exists first (create it if absent).
-
-2. Run the phase-gate note subcommand via **Bash** to merge it into the core chart:
-   ```bash
-   node "C:/Users/user/Documents/GitHub/KenazAI/.specialist/tools/phase-gate.js" note --task=TASK_1826 --from-file=".kenaz/specialist/progress_note_TASK_1826.json"
-   ```
-   *(The note file is in your local workspace — no cross-workspace Write; phase-gate note merges it into the core chart atomically)*
-
-**Progress Note Schema** (ONE entry to append to `progress_notes`):
-
-```json
-{
-  "task_id": "TASK_1826",
-  "timestamp": "<ISO-8601>",
-  "changes": { "files_modified": ["<paths>"], "files_created": [], "files_deleted": [], "total_lines": 0 },
-  "acceptance_criteria": [
-    { "criterion": "以拋棄式 repo 建立四種 husk 實測 GC：(a) wt-* 且已合併→回收，(b) wt-* 但分支不存在且工作樹乾淨→回收，(c) task_* 且已合併→回收，(d) 工作樹髒或有未合併 commit→保留。四種都要以實跑輸出為證", "status": "pass|fail|partial", "evidence": "<brief>" },
-    { "criterion": "未到 GC_MIN_AGE_MS 的 worktree 仍不被碰（不得變成會殺掉並行 session 的活 worktree）", "status": "pass|fail|partial", "evidence": "<brief>" },
-    { "criterion": "keepPath（即將建立的那個）仍被排除", "status": "pass|fail|partial", "evidence": "<brief>" },
-    { "criterion": "分支消失但工作樹髒的 husk 被保留且 stderr 有可觀察的診斷行", "status": "pass|fail|partial", "evidence": "<brief>" },
-    { "criterion": "hook 在任何上述情境下都不拋錯、不阻斷 worktree 建立", "status": "pass|fail|partial", "evidence": "<brief>" },
-    { "criterion": "node --check .claude/hooks/worktree-create.js 通過", "status": "pass|fail|partial", "evidence": "<brief>" },
-  ],
-  "findings": ["<non-obvious discoveries, traps, design decisions>"],
-  "deviations": ["<anything done differently from the plan; REQUIRED to document a skipped inscribe>"],
-  "cognitive_output": { "runes": ["<rune_ids -- [] if none>"], "sigils": ["<sigil_ids -- [] if none>"] }
-}
-```
-
-**Rules**:
-- Evaluate EVERY Acceptance Criterion; use exact criterion text from the task.
-- `changes`: list ALL files touched (created/modified/deleted).
-- `findings`: non-obvious constraints, design traps, discoveries -- [] if none.
-- `cognitive_output.runes/sigils` = IDs from synapse calls ([] if none); if you skip inscribe, say why in `deviations` (verify-identity reads it as the skip explanation).
-- If the chart file does not exist, the note subcommand creates it automatically -- NEVER use the Write tool on the chart path directly.
-
-
-## Before You Start — Cognitive Recall (mandatory verdict)
-Before writing any code, you MUST perform a cognitive recall (synapse_recall or synapse_pulse) on the symbols you are about to modify.
-
-Output exactly one of these lines before you start coding:
-
-```
-📡 Cognitive Recall: {one-line summary of what pulse/recall revealed}
-```
-
-Or, if you consciously decide to skip:
-
-```
-📡 Cognitive Recall: SKIP — {reason why recall is unnecessary}
-```
-
-You may SKIP, but you must say why. Silence is not allowed.
-
-## Before You Finish — Don't Let Your Discovery Die
-You just spent real effort understanding this code. When this conversation ends, everything you learned disappears — unless you write it down.
-
-Ask yourself:
-- Did you trace a bug to a root cause that wasn't obvious from the code? → The next agent will waste hours rediscovering it. **inscribe type=fix**
-- Did you find a function that behaves differently than its name suggests, or has a hidden constraint? → That's a trap waiting to spring. **inscribe type=risk**
-- Did you choose approach A over B for a reason that isn't obvious? → Without your reasoning, someone will undo your work. **inscribe type=decision**
-- Did you realize that 3+ symbols are actually part of the same concept? → Give it a name. **synapse_forge** a Sigil.
-
-If none of these apply, skip. Don't write for the sake of writing.
-
-When you do write:
-- **English only** — code is English, runes should be too. This is mandatory: all memory write fields (synapse_inscribe content/context, hippocampus episode scope/lesson/summary) MUST be in English. SQLite FTS5 tokenizer does not handle CJK — Chinese content will return 0 results on recall. (Rule: MEM-LANG-001)
-- confidence >= 0.6 — if you're guessing, don't inscribe.
-- One good rune > three mediocre ones.
-- ⚠️ **Always pass `projectPath` to all Synapse tool calls** — use the projectPath determined in Phase 0. Multi-session collisions occur when concurrent sessions omit projectPath and fall back to the global default project.
-
-Every rune you inscribe will be recalled by the next agent who touches the same symbol. Your insight becomes their head start.
-
-## Cognitive Checkpoint (mandatory — include in your final output)
-At the very end of your response, output this block exactly:
-
-```
-## Cognitive Checkpoint
-Pre-code: RECALLED — {what you found} | or SKIP — {reason}
-Post-code: INSCRIBED — {rune_id} | or SKIP — {reason}
-```
-
-Both verdicts are required. You may SKIP either, but you must state why.
-
-
-## Cortex Context (Related Files Preview)
-The following files are in your scope. Review them before making changes.
-
-### .claude/hooks/worktree-create.js (304 lines)
-```
-#!/usr/bin/env node
-'use strict';
-
-/**
- * worktree-create.js — Claude Code `WorktreeCreate` hook.
- *
- * PROBLEM (TASK_1586): The Agent/Task tool's `isolation: "worktree"` creates the
- * isolated worktree from the SESSION cwd's git repo. In production the Kenaz
- * dashboard launches the interactive session with cwd = kenaz-core (a bundled
- * file COPY — NOT a git checkout), while the user's actual project is a separate
- * git repo. The harness then fails: "not in a git repository".
- *
- * FIX: when configured as a WorktreeCreate hook, the harness DELEGATES worktree
- * creation entirely to this script (it no longer runs `git worktree add` itself).
- * This script:
- *   - Branch 1 (dev / same-repo): session cwd IS a git repo → create the worktree
- *     in that repo at the harness-proposed path (faithful passthrough).
- *   - Branch 2 (production): session cwd is NOT a git repo → resolve the active
- *     project from ~/.kenaz/projects.json (same source as Rust get_current_project)
- *     and create the worktree inside THAT git repo.
- *   - No git target resolvable → exit non-zero with a readable message so the
- *     dispatch degrades cleanly instead of surfacing a raw harness error.
- *
- * Contract (code.claude.com/docs hooks.md):
- *   stdin  JSON: { session_id, transcript_path, cwd, hook_event_name,
- *                  worktree_path (proposed, ignorable), isolation_reason }
- *   env:        CLAUDE_PROJECT_DIR, CLAUDE_SESSION_ID
- *   stdout:     the chosen worktree path (exit 0). Path is fully hook-controlled
- *               and MAY live in a different git repo than cwd.
- *   non-zero:   blocks worktree creation.
-... (truncated)
-```
-
-### .formation/tools/formations.js (1195 lines)
-```
-'use strict';
-/**
- * Formations
- *
- * Formation launcher functions extracted from headless.js (TASK_890).
- * Contains all launchXxx functions and worktree management helpers.
- *
- * Exports: launchHuginnThink, launchUnit, launchSolo, launchSquad,
- *          launchLegion, launchLegacy, createWorktree, removeWorktree,
- *          cleanupAllWorktrees
- *
- * Internal: squadSynthesis, waitAll, printResults, hasSuccess
- */
-
-const fs = require('fs');
-const path = require('path');
-const { execSync } = require('child_process');
-const {
-  buildSquadSynthesisPrompt, buildSquadDebatePrompts,
-  buildLegionLeadPrompt, HEADLESS_PREFIX,
-} = require('./prompt');
-const { runHeadless, runLegionLead, runner: formationRunner } = require('./runner');
-const {
-  ROOT, getLogDir,
-  createWorktree: createTaskWorktree, removeWorktree: removeTaskWorktree,
-  ensureWorktreeDirIgnored, readWorktreeConfig,
-} = require('./utils');
-const { postComplete } = require('./post-complete');
-const {
-  waitForDispatchSlot, registerDispatch, unregisterDispatch,
-... (truncated)
-```
-
-### .formation/tools/post-complete.js (3927 lines)
-```
-#!/usr/bin/env node
-/**
- * Formation Post-Complete
- * 任務完成後的自動化處理：Archive 清理 + Git 分支管理
- *
- * 支援多專案：projectPath 指定子專案時，所有 git/archive/task 操作
- * 都在子專案的 repo 中執行（而非 KenazAI core）。
- *
- * 流程：
- *   1. Archive 檢查：done 任務超過 N 個時，將最舊的移到 archived/
- *   2. Git 分支：建立 task branch → commit → merge 到用戶分支
- *
- * Usage:
- *   node .formation/tools/post-complete.js --task=TASK_XXX
- *   node .formation/tools/post-complete.js --task=TASK_XXX --project-path=/path/to/sub
- *   node .formation/tools/post-complete.js --task=TASK_XXX --keep=10
- *   node .formation/tools/post-complete.js --task=TASK_XXX --skip-git
- *   node .formation/tools/post-complete.js --task=TASK_XXX --skip-archive
- *   node .formation/tools/post-complete.js --task=TASK_XXX --dry-run
- *   node .formation/tools/post-complete.js --task=TASK_XXX \
- *     --test-cmd "cd dashboard && npm test" \
- *     --test-cmd "cd dashboard/pty-server && cargo test"
- */
-
-/* =============================================================================
- * STRUCTURAL AUDIT — post-complete pipeline (TASK_1137, 2026-04-11)
- * ============================================================================
- *
- * Context: ~5939-line orchestrator accumulated 13 incremental bug fixes
- * (B1-B3, B5-B13) across B1-B14 fix chain sessions.  Health score stuck at
-... (truncated)
-```

package/core/.kenaz/specialist/rune_efe_salience_gap.md

@@ -1,21 +0,0 @@
----
-name: efe_salience_component_gap
-description: EFE Active Inference implementation missing Salience component for downstream state info gain
-metadata:
-  type: insight
-  confidence: 0.88
-  author: agent:Muninn
-  session_id: ansuz-prompt-1779233477147
-  symbol_id: dashboard/src-tauri/src/features/synapse/efe.rs:efe_score:function
-  timestamp: 2026-05-20T00:02:13Z
----
-
-**Architecture insight**: EFE (Expected Free Energy) implementation in `efe.rs` maps Risk, Ambiguity, Novelty, and Complexity dimensions from the canonical Active Inference Framework, but lacks the **Salience** component that captures downstream state information gain. 
-
-**Why it matters**: Salience quantifies how much observing a state reduces uncertainty about future outcomes; without it, EFE scoring underestimates the value of information-seeking behaviors.
-
-**Proposed fix**: Use graph structure's CALLS edge count to identify "gateway" symbols — functions that appear in many call chains indicate high information gain when modified. This provides a proxy for downstream state coupling.
-
-**Related symbols**: 
-- `dashboard/src-tauri/src/features/synapse/efe.rs` (scoring logic)
-- `.synapse/db` (KuzuDB graph storing CALLS edges)

package/core/.kenaz/specialist/task1825_update.json

@@ -1,43 +0,0 @@
-{
-  "title": "驗收訊號鏈六層全部靜默回報通過：runtime verdict 寫進沒人讀的欄位、fix 卡的 FAIL 產不出 FIX 卡、LLM verifier 逾時直接回報 pass",
-  "description": "本卡於 2026-07-27 由 Ansuz 依實測改寫。原描述的方向（把 post-complete step 1.5 的 VERIFICATION_FAILED 接上完成關卡）已被測量否定，改寫理由完整保留在 technical_notes，因為那個誤讀本身有教育價值。\n\n【原描述說對的部分，已逐行複查屬實】\n- post-complete.js:2296 的完成判斷只看 isVerifiedMergeSuccess(result.git)，完全不參考任何驗收結果\n- post-complete.js:2144 的註解明文寫著 VERIFICATION_FAILED 不擋 merge\n- post-complete.js:2469 的安全網條件是 isVerifiedMergeSuccess(result.git) && !result.taskCompleted，不要求 complete() 曾被嘗試\n\n【原描述沒看到的部分：驗收有兩套實作，原描述指的是沒有作用的那一套】\n(A) .formation/tools/verify-acceptance.js（565 行）— 由 post-complete/git-merge.js:945 在 gitBranchAndMerge 內部呼叫。spawn headless Haiku 讀 git diff 判斷散文條件，結果寫入 result.git.acceptance，被 post-complete.js:2298（寫進 task notes）與 3622（完成摘要）讀取。只在「找不到卡」或「沒有 acceptance_criteria」時 skip，實際覆蓋 1538/1720 張卡。\n(B) .formation/tools/post-complete/verify-acceptance.js（486 行）— 由 post-complete.js:2133 呼叫，HTTP 打 Rust backend :18080。結果寫入 result.acceptanceRuntime，而該欄位在全檔案只有這一個引用，寫入後再也沒有人讀。原描述要改的 VERIFICATION_FAILED 屬於這一套。\n\n【測量結果，判定式照 isToolCallShaped 原樣重寫】\n- 1720 張卡、1538 張有 acceptance_criteria、6713 條條件，其中工具形狀者 7 條（0.10%），涵蓋 7 張卡\n- 控制組（放寬成整份檔案任何位置提到 4 個已知工具名的上界）：60/1720 = 3.5%\n- 因此 (B) 的 verdict 在 99.5% 以上的情況必定是 SKIP。把它接上關卡等於做一道永遠不會觸發的閘門。\n- 進一步：全 repo grep acceptance_verdict 在 .kenaz/tasks/ 命中 0 筆，代表 (B) 的 writeVerdictToTask 從未成功寫入過任何一張卡——四個 SKIP early-return（388/393/399/432）都在它之前返回。這套驗證器至今對系統的淨影響是零。\n\n【本卡要修的：整條驗收訊號鏈的每一個降級路徑都回報通過】\n1. verify-acceptance.js:449 — spawn 逾時（120s）直接 return { pass: true, error: 'timeout' }。逾時被當成通過。\n2. verify-acceptance.js:457 — 失敗處理的條件是 !verifyResult.pass && !verifyResult.error，所以只要解析出錯就同時跳過 FIX 卡建立與 saveReport，整個失敗完全不留痕跡。\n3. verify-acceptance.js:462-465 — 原卡若帶 fix tag 則 fixSkipped=true，不建立 FIX 卡。全 repo 517/1720（30.1%）的卡帶 fix tag，而這正是最常驗收失敗的族群。失敗的唯一產物是一行 log 與一則 note。\n4. post-complete.js:2134 — result.acceptanceRuntime 寫入後無人讀取，完成摘要 3622 只印 result.git.acceptance。\n5. 對照：.formation/reports/verify/ 至今只有 16 份失敗報告，而終態卡片約 1686 張。\n\n【已決定的事，不要重新決策】\ndone/ 的語義維持「程式碼已合併」，本卡不改變它。理由有二：其一，post-complete.js:2291-2295 的註解記載這個設計曾經是反過來的（AC 失敗擋住完成），因為造成 active/ 卡片堆積而被刻意反轉；其二，(A) 的 FAIL 是一個 Haiku 讀 diff 的判斷，把 done/ 的生死交給它，正是本卡技術註記所禁止的「拿另一個自我宣告當獨立證據」。\n\n本卡的目標因此是：讓驗收失敗停止靜默——失敗必須可見、必須有歸宿、降級路徑不得偽裝成通過。不是加關卡。",
-  "priority": "P2",
-  "rigor": "high",
-  "complexity": "medium",
-  "tags": ["fix", "code", "post-complete", "verification", "silent-failure"],
-  "scope_paths": [
-    ".formation/tools/verify-acceptance.js",
-    ".formation/tools/post-complete.js",
-    ".formation/tools/post-complete/verify-acceptance.js",
-    ".formation/tools/post-complete/git-merge.js"
-  ],
-  "requirements": [
-    "非目標，且必須主動維持：不得改變 done/ 的語義。驗收失敗但 merge 成功的卡片仍然進 done/。任何讓卡片因驗收失敗而停在 active/ 或 blocked/ 的改動都超出本卡範圍，會重演 post-complete.js:2291-2295 記載的 pile-up。",
-    "verify-acceptance.js:449 的逾時路徑不得回報 pass:true。逾時是「沒有測到」，必須與「測到且通過」在回傳值上可區分，且該區分要一路傳到完成摘要。",
-    "verify-acceptance.js:457 的 error 路徑不得同時吞掉 saveReport。解析失敗或 spawn 失敗至少要留下一份報告或一則 note，讓事後可稽核。",
-    "verify-acceptance.js:462-465 的 fix-tag 迴圈防護必須保留（不要改成無條件建 FIX 卡，那會產生無限鏈），但失敗必須有替代歸宿：在原卡上留下明確可查詢的失敗標記（notes 或 vitals），使「這張卡驗收沒過但仍進了 done/」可以被一條查詢列出來。歸宿形式自行設計，但必須可被 grep 或 task-api 查到。",
-    "result.acceptanceRuntime 必須二選一，不得留第三種模糊狀態：要嘛接上（至少進完成摘要，與 result.git.acceptance 同級待遇），要嘛連同 post-complete.js:2133 的呼叫一起移除。選擇的理由寫進 commit message。考量點：測量顯示它至今從未寫成過一筆 acceptance_verdict。",
-    "post-complete.js:2469 的安全網本卡不改行為，但必須在原地補上註解說明其不變量：它不要求 complete() 曾被嘗試，因此任何未來想用「不設 taskCompleted」來擋住卡片的關卡都會被它繞過。這是給下一個人的路標，不是本卡的行為改動。",
-    "post-complete.js 標頭約 40-60 行的 step 說明表必須與改動後的實際行為一致。"
-  ],
-  "acceptance_criteria": [
-    "驗證一律在拋棄式 repo 或完整快照後進行，不得拿使用者的真實任務卡做第一次實驗；報告中須註明使用的驗證環境",
-    "以一張刻意讓驗收失敗、且 tags 含 fix 的測試卡實跑 post-complete：卡片仍進 done/（語義未變），且失敗標記可被實際查詢列出——附上查詢指令與其輸出",
-    "以一張刻意讓驗收失敗、tags 不含 fix 的測試卡實跑：仍建立 FIX 卡，行為與修改前一致，以實跑輸出為證",
-    "以一張驗收會通過的卡實跑：行為與修改前一致，以實跑輸出為證",
-    "逾時路徑實跑驗證：以縮短 timeout 或 stub spawn 觸發，回傳值與完成摘要皆不得呈現為通過，附實跑輸出",
-    "result.acceptanceRuntime 的處置以證據收尾：若接上，附一張工具形狀驗收卡的實跑摘要輸出；若移除，附 grep -rn acceptanceRuntime .formation/ 命中 0 的輸出",
-    "Rust backend 離線時整條 post-complete 不得卡死或報錯中斷，以實跑輸出為證",
-    "post-complete 相關測試全綠：post-complete 27/27、task1536 7/7、task1543 4/4、worktree-rescue 3/3。node:test 格式印的是「ℹ pass N」不是「# pass N」，請讀 N 的數字，不要只讀 exit code",
-    "標頭 step 說明表與實際行為一致"
-  ],
-  "technical_notes": [
-    "改寫紀錄（保留誤讀以資借鑑）：原卡假設 post-complete step 1.5 的 VERIFICATION_FAILED 是該接上關卡的訊號。實測否定——isToolCallShaped 要求 criterion 字面包含 hippocampus_episode_recall / synapse_knowledge_gaps / synapse_health_metrics / synapse_health 其一且含斷言運算子，6713 條驗收條件命中 7 條。原卡自己的驗收條件（「post-complete 27/27」「以實跑輸出為證」）全是 shell 形狀，會被自己的機制 SKIP 掉。",
-    "兩套 verify-acceptance 同名但不是重複實作，不要合併：.formation/tools/verify-acceptance.js 是 LLM 判斷（廣覆蓋，被讀取），.formation/tools/post-complete/verify-acceptance.js 是 MCP 工具呼叫（0.10% 覆蓋，不被讀取）。git-merge.js:14 require 的是前者。",
-    "post-complete.js:2298 讀的是 result.git.acceptance（前者的產物），不是 2134 寫入的 result.acceptanceRuntime（後者的產物）。這兩個名字近似的欄位是本卡最容易改錯地方。",
-    "post-complete.js:2291-2295 的註解記載此設計曾被反轉過一次，原因是 active/ 堆積。不要再反轉回去。",
-    "TASK_1536 的 reconciliation（約 2395-2465）已經負責「done/ 但 merge 未落地」的回收。本卡的失敗標記不得與它互相拉扯，特別是不要也去搬動卡片狀態。",
-    "feedback_post_complete_false_positive_merge：merged=true 曾經說謊。設計失敗標記時不要把另一個自我宣告當成獨立證據。",
-    "本卡屬於 Huginn 那則被反覆驗證的 advisory「silent success across 6+ subsystems」的具體實例：這條鏈上每一個降級路徑都回報通過，沒有任何一個會崩或報錯。"
-  ]
-}

package/core/.kenaz/specialist/taskgen/consolidation_i.json

@@ -1,38 +0,0 @@
-{
-  "title": "consolidation_scores 投影層吃掉 consolidated/key_facts 欄位，製造 1222 個 episode 的永久假積壓",
-  "description": "Huginn advisory（2026-07-24）回報「20 closed episodes overdue for consolidation（~94 天）」。實際查證後這是假警報，且成因是兩個可修的缺陷。(1) 投影層欄位遺失：episode ep_69e66c5f0377 在 .synapse/db/memory.db 裡 consolidated='warm'、key_facts 長度 1649 字元，但 hippocampus_consolidation_scores 對外回傳 consolidated:\"\" 與 key_facts:\"\"。消費者因此完全無法分辨「尚未整併」與「已在 warm 層整併」。這與 search.rs 漏投影 symbol_id 是同一類缺陷（rune_4920686de6484cb68b5ead49943ea44d）：內部有值、投影沒帶出去、序列化乾淨、型別無錯，除非追 DB→query→投影→消費者四段否則發現不了。(2) 候選過濾語意過寬：consolidation_scores 的 WHERE 是 e.consolidated NOT IN ('archived','cool-merged')，所以 consolidated='warm' 的 1222 個 episode 全部留在候選池。實測分布：warm 1222 / archived 369 / 空字串 67（closed 共 1658）。synapse_maintain 把這個池標成 'queued for consolidation review'，數字永遠不會下降，Huginn 於是週期性產生無法被解決的 advisory。實測佐證：hippocampus_consolidate 掃了 500 個 episode，compressed=0 / cool_merged=0 / archived=0 —— 因為真的沒東西要做，是報表在說謊。",
-  "priority": "P2",
-  "role": "developer",
-  "rigor": "low",
-  "complexity": "low",
-  "tags": ["fix", "code", "test"],
-  "scope_paths": [
-    "dashboard/src-tauri/src/features/synapse/memory/episode.rs",
-    "dashboard/src-tauri/src/infrastructure/http_server/routes/mcp_tools/hippocampus.rs"
-  ],
-  "estimated_hours": 2,
-  "requirements": [
-    "修正 consolidation_scores 的欄位投影：consolidated 與 key_facts 在 DB 有值時必須如實回傳。先確認遺失發生在哪一層 —— SQL SELECT 沒選這兩欄、Rust struct 沒有對應欄位、或 MCP 的 json!{} 投影沒帶出去 —— 再對症修，不要三層都亂改。",
-    "釐清並修正候選語意。consolidated='warm' 的 episode 已完成 warm 層壓縮，只是仍可能符合 cool-merge 條件（需 3+ 共同 touched_symbols，多數永遠不會符合）。把「所有非 archived/cool-merged」一律當成待辦是錯的語意。建議做法：候選池區分 pending_warm（consolidated='' 且超過 min_age_days）與 eligible_for_cool（consolidated='warm' 且真的有 3+ 共同 symbols 的同伴），回傳中分開表達。",
-    "synapse_maintain 的 overdue_episodes 區塊改為只計入真正可行動的項目（pending_warm + 真正可 cool-merge 者），且 diagnosis 文字要能反映實情。目前的 '20 closed episodes are queued for consolidation review' 在 compressed=0 的情況下是誤導。",
-    "count 欄位不要只回 top_n 截斷後的數量 —— 若總候選有 1289 個而只顯示 3 個，必須讓消費者知道總數與被截斷的事實（no silent truncation）。",
-    "不要為了讓指標歸零而放寬或收緊門檻 —— 判準是「回報的數字等於實際可執行的工作量」。若修正後 pending_warm 真的是 67，那就誠實回報 67。"
-  ],
-  "acceptance_criteria": [
-    "新增單元測試驗證投影完整性：以 fixture episode（consolidated='warm'、key_facts 非空）呼叫 consolidation_scores，斷言回傳的 consolidated 與 key_facts 與寫入值相符（不是空字串）。這條測試是本卡的核心，必須存在。",
-    "新增單元測試驗證候選分類：consolidated='' 且夠老 → pending_warm；consolidated='warm' 且無共同 symbol 同伴 → 不計入待辦；consolidated='archived' → 兩者皆不計入。",
-    "手動複驗並貼出證據：呼叫 hippocampus_consolidation_scores 後，ep_69e66c5f0377 的 consolidated 應為 'warm'、key_facts 應為長度 1649 左右的 JSON 陣列字串（現況兩者皆為 \"\"）。",
-    "呼叫 synapse_maintain 後，overdue_episodes.count 應等於實際可執行的整併工作量，且與 hippocampus_consolidate 的 compressed+cool_merged 輸出不再矛盾（現況：maintain 說 20 個待辦，consolidate 說 0 個可做）。",
-    "`CARGO_TARGET_DIR=$(node <worktree>/dev/scripts/verify-target-dir.js) cargo check --lib -p kenaz-dashboard` 乾淨通過（exit 0），測試以 `node <worktree>/dev/scripts/run-rust-tests.js <filter>` 全數通過（腳本自動套用正典 CARGO_TARGET_DIR）。",
-    "既有 episode 相關測試全數通過，且不得修改 memory.db 的 schema 或既有資料。"
-  ],
-  "technical_notes": [
-    "已查證的事實（Ansuz 實測，可複驗，不需重新調查）：episodes 表中 status='closed' 的 consolidated 分布為 warm 1222 / archived 369 / 空字串 67。ep_69e66c5f0377：consolidated='warm'、length(key_facts)=1649、entry_count=6、recall_count=2、age 95 天。hippocampus_consolidate 實跑結果：scored=500、compressed=0、cool_merged=0、archived=0、zero_activity_cleared=0。",
-    "已排除的假設（不要重走）：warm 壓縮沒有失敗。我一開始懷疑 compress_warm_episodes 的 created_at CASE（TASK_1641 修過 epoch-Z 格式）漏接第三種格式導致靜默落選，實測否定 —— '1776708033Z' 經 CASE 正確解析為 1776708033，且那些 episode 的 consolidated 早已是 'warm'。compress_warm_episodes 回 0 是正確行為。",
-    "關鍵程式位置：consolidation_scores 的 SQL 在 features/synapse/memory/episode.rs 第 247 行起，候選過濾條件在第 267 行（`AND e.consolidated NOT IN ('archived', 'cool-merged')`）。consolidate 的三層流程在 mcp_tools/hippocampus.rs 第 590-663 行。",
-    "同類前例：search.rs 的 json!{} 投影層曾靜默漏掉 symbol_id（rune_4920686de6484cb68b5ead49943ea44d），修法是補齊全部 5 個投影點，並確認 response_compression.rs 的白名單沒有把新欄位濾掉。本卡修投影時請比照檢查有沒有第二個投影點。",
-    "這張卡的價值不在 2 小時的程式碼，而在它關掉一個會週期性消耗注意力的假訊號 —— Huginn 已經為此產生 advisory，Ansuz 已經為此花了一個 session 的查證。假警報的成本是複利的。",
-    "驗證環境：正典共用 CARGO_TARGET_DIR（來源 dev/scripts/verify-target-dir.js，Windows 為 C:/t/kenaz-verify）避開 vendor/kuzu 的 Windows MAX_PATH，不要自創新目錄（TASK_1879）；並行驗證被 cargo 檔案鎖串行化，'Blocking waiting for file lock' + CPU 近 0 是正常等待不是 hang；不可共用主工作樹 target/（被 live tauri dev 佔用）；不要用 cargo test --lib（STATUS_ENTRYPOINT_NOT_FOUND，TASK_1619），用 dev/scripts/run-rust-tests.js。",
-    "memory.db 是 158MB 且被 live dashboard 開著 —— 唯讀查詢用 node:sqlite readOnly 模式，不要寫入。"
-  ]
-}

package/core/.kenaz/specialist/taskgen/csharp_a.json

@@ -1,44 +0,0 @@
-{
-  "title": "Synapse C# Phase 1：符號抽取核心 — 836 個 .cs 檔目前抽出 0 符號（靜默）",
-  "description": "Unity/C# 專案（D:\\Projects\\Ashfall）的 .cs 檔有進 File 表（836 筆）但 Symbol 表完全沒有 csharp 這一列，`MATCH (f:File)-[:DEFINES]->(s:Symbol) WHERE f.extension='cs' RETURN count(s)` 回傳 0。根因已定位：scanner.rs 的 detect_symbol_language() 不認 'cs' 副檔名（回 None），導致 scanner.rs 第 764 行整段符號抽取被跳過，沒有任何 warning。本卡實作 C# 的符號層抽取（class/struct/interface/enum/record/method/property/field/namespace），讓 synapse_search / synapse_pulse / synapse_context 在 C# 專案上可用。關係層（CALLS/IMPLEMENTS/EXTENDS/IMPORTS）由後續卡處理，本卡不做。",
-  "priority": "P1",
-  "role": "developer",
-  "rigor": "medium",
-  "complexity": "medium",
-  "tags": ["code", "fix", "test"],
-  "scope_paths": [
-    "dashboard/src-tauri/Cargo.toml",
-    "dashboard/src-tauri/src/features/synapse/symbols.rs",
-    "dashboard/src-tauri/src/features/synapse/scanner.rs",
-    "dashboard/src-tauri/src/features/synapse/preamble.rs"
-  ],
-  "estimated_hours": 4,
-  "requirements": [
-    "Cargo.toml 加入 tree-sitter-c-sharp = \"0.23.5\"（與現用 tree-sitter-rust 0.23.2 / tree-sitter-go 0.23.4 同世代 ABI，搭配 tree-sitter 0.26.6）。",
-    "scanner.rs detect_symbol_language()：新增 \"cs\" => Some(\"csharp\")。不要動既有 7 個副檔名的行為。",
-    "symbols.rs extract_symbols()：新增 \"csharp\" => extract_csharp_symbols(source, file_path) 分支。",
-    "實作 extract_csharp_symbols：抽取 class / struct / interface / enum / record / delegate 為型別符號；method_declaration / constructor_declaration / property_declaration / field_declaration 為成員符號。成員必須帶上所屬型別名，讓 scanner 的 find_class_symbol_id 能建立 MEMBER_OF 關係（比照既有 extract_python_class / extract_typescript_symbols 的做法）。",
-    "namespace 處理：C# 的 namespace 有 block 形式與 file-scoped 形式（`namespace Foo;`）兩種，兩種都要能穿透到內層型別，不可只支援 block 形式（Unity 專案兩種都常見）。",
-    "簽章（signature）比照既有語言：取宣告首行（含修飾詞、泛型參數、參數列、回傳型別），不含 body。可參考 extract_rust_first_line / extract_go_first_line 的做法新增 extract_csharp_first_line。",
-    "ERROR node recovery：比照既有語言（recover_symbols_from_error_python 等）處理部分解析失敗的檔案，避免編輯中的檔案整個掉光。",
-    "symbols.rs 的 parse_to_tree() 與 parse_incremental() 兩處 language→tree_sitter::Language 對照表（約 2445 行與 2467 行）都要補 \"csharp\" 分支，否則增量解析路徑對 C# 無效。",
-    "preamble.rs 約 2118 行的 language→副檔名對照表補 \"csharp\" => &[\".cs\"]。"
-  ],
-  "acceptance_criteria": [
-    "新增 Rust 單元測試（放在 symbols.rs 既有 #[cfg(test)] 區塊，比照既有語言的測試風格），以內嵌 C# fixture 字串驗證：(1) block namespace 內的 public class 被抽出且 kind 正確；(2) file-scoped namespace（`namespace Foo;`）內的 class 同樣被抽出；(3) class 內的 method 與 property 被抽出且能關聯到所屬 class 名；(4) interface / enum / struct / record 各自被抽出且 kind 正確；(5) 含語法錯誤的 C# 片段仍能抽出前面合法的符號（ERROR recovery）。",
-    "測試以 `node <worktree>/dev/scripts/run-rust-tests.js csharp` 執行並全數通過（腳本自動套用正典 CARGO_TARGET_DIR，來源 dev/scripts/verify-target-dir.js），log 貼進完成報告（不要用裸 cargo test --lib，會 STATUS_ENTRYPOINT_NOT_FOUND，見技術註記）。",
-    "`CARGO_TARGET_DIR=$(node <worktree>/dev/scripts/verify-target-dir.js) cargo check --lib -p kenaz-dashboard` 乾淨通過（exit 0，讀 ${PIPESTATUS[0]} 不要讀 pipe 尾端）。",
-    "detect_symbol_language 對既有 7 個副檔名的回傳值完全不變（加一條回歸測試斷言 py/ts/tsx/js/jsx/rs/go/md/yaml 的既有映射）。",
-    "不得修改 calls.rs / implements.rs / imports.rs / exports.rs / dataflows.rs / varflows.rs — 關係層是下一張卡的範圍，越界會與平行 agent 衝突。"
-  ],
-  "technical_notes": [
-    "驗證環境（強制照做，否則會撞 Windows MAX_PATH 與 SxS manifest 兩個已知坑）：worktree 內的 Rust 驗證必須用正典共用 CARGO_TARGET_DIR（來源 dev/scripts/verify-target-dir.js，Windows 為 C:/t/kenaz-verify），否則 vendor/kuzu 的 CMake 路徑超過 MAX_PATH 直接失敗。不要自創新目錄（TASK_1879）；並行驗證被 cargo 檔案鎖串行化，'Blocking waiting for file lock' + CPU 近 0 是正常等待不是 hang。",
-    "cargo test --lib 會編得過但執行時 STATUS_ENTRYPOINT_NOT_FOUND (0xc0000139) — 這是 TASK_1619 記錄的 Common-Controls v6 manifest 問題（rfd crate 靜態 import comctl32!TaskDialogIndirect）。唯一可行路徑是 `node dev/scripts/run-rust-tests.js <filter>`，它會 --no-run 建置、複製 exe、旁邊放外部 manifest 再執行。",
-    "若 build.rs 因 tauri.conf.json 的 resources glob 驗證而 panic（訊息形如 `resource path resources\\onnx\\arctic-embed-xs doesn't exist`），從主工作樹複製 `dashboard/src-tauri/resources/onnx/` 進 worktree 並設 SKIP_SIDECAR_STAGING=1。先裸跑一次，失敗再補這步。",
-    "主工作樹的 target/ 正被 live tauri dev（backend 18080）佔用，絕對不要共用主樹的 target 目錄。",
-    "本卡驗收刻意只到單元測試層級 — 使用者明確要求不重建 dashboard、不對 D:\\Projects\\Ashfall 重新索引。真實 Unity 專案的端到端驗證是後續獨立步驟，不要在本卡宣稱已端到端驗證。",
-    "參考實作：extract_go_symbols（結構最接近，Go 也是 type + method 分離的語言）與 extract_typescript_symbols（class 成員 MEMBER_OF 的處理方式）。",
-    "C# 特有陷阱：partial class（同名型別散在多檔，各自產生符號是可接受的）、泛型型別名（`Foo<T>` 的符號名建議只取 `Foo`，泛型參數留在 signature 裡，與既有語言一致）、attribute（`[SerializeField]` 等，不應被誤判為符號，但應併入被修飾符號的 start_line 或 signature，比照 Python decorated_definition 的處理）。",
-    "來源報告：C:\\Users\\user\\Desktop\\SYNAPSE_CSHARP_INDEXING_REPORT.md（缺陷 1）。"
-  ]
-}

package/core/.kenaz/specialist/taskgen/csharp_b.json

@@ -1,40 +0,0 @@
-{
-  "title": "Synapse C# Phase 2：關係抽取（CALLS / IMPLEMENTS / EXTENDS / IMPORTS / EXPORTS）",
-  "description": "TASK_1797 讓 C# 有了 Symbol 節點，但 synapse_impact / synapse_orphans / synapse_trace_route / synapse_pain_paths / synapse_pulse 的爆炸半徑全部建立在符號之間的「關係」上 —— 沒有這一層，C# 專案會停在「看得到符號、看不到影響」的半殘狀態，而那正是原始報告抱怨的「看起來健康實則是空的」的變體。本卡補齊 C# 的關係層：方法呼叫（CALLS）、介面實作與基底類別（IMPLEMENTS / EXTENDS，C# 用同一個 `: Base, IFoo` 語法表達兩者，需要判別）、using 指示詞（IMPORTS）、public 成員（EXPORTS）。依賴 TASK_1797 先落地。",
-  "priority": "P1",
-  "role": "developer",
-  "rigor": "medium",
-  "complexity": "medium",
-  "tags": ["code", "fix", "test"],
-  "dependencies": ["TASK_1797"],
-  "scope_paths": [
-    "dashboard/src-tauri/src/features/synapse/calls.rs",
-    "dashboard/src-tauri/src/features/synapse/implements.rs",
-    "dashboard/src-tauri/src/features/synapse/imports.rs",
-    "dashboard/src-tauri/src/features/synapse/exports.rs"
-  ],
-  "estimated_hours": 5,
-  "requirements": [
-    "calls.rs extract_calls()：新增 \"csharp\" 分支，抽取 invocation_expression（含 this.Foo()、obj.Foo()、Namespace.Type.StaticFoo()、base.Foo()）與 object_creation_expression（new Foo() 視為對建構式的呼叫）。比照既有 extract_rust_calls / extract_go_calls 的回傳形狀。",
-    "implements.rs：C# 的 base_list（`class Foo : Bar, IBaz`）同時表達繼承與介面實作，且語法上無法直接分辨。採用命名慣例 + 位置啟發式：base_list 第一項若非 I 開頭大寫（C# 慣例 IFoo）則視為 EXTENDS，其餘視為 IMPLEMENTS；interface 宣告的 base_list 一律視為 IMPLEMENTS（介面繼承介面）。此啟發式必須寫進程式碼註解並附上「為什麼不能完全準確」的說明。",
-    "implements.rs 也要處理 struct（C# 的 struct 只能實作介面、不能繼承）與 record（可繼承 record）。",
-    "imports.rs：抽取 using 指示詞 —— 一般 using（`using System.Collections;`）、static using（`using static Foo.Bar;`）、別名 using（`using Alias = Foo.Bar;`）、global using（`global using X;`，C# 10+，Unity 專案常見）。判定 is_external 的規則：以 System. / UnityEngine. / UnityEditor. / Microsoft. 開頭者視為外部依賴，其餘視為專案內。",
-    "exports.rs：抽取 public / protected internal 的型別與成員作為對外介面。internal 與 private 不計入。",
-    "dataflows.rs 與 varflows.rs 本卡**不做** —— 既有語言也只有 rust 有實作，C# 補這兩層的邊際效益低且 VARFLOW 本身有已知的變數身分追蹤缺陷（rune_varflow_architecture_insight）。若你判斷該做，寫進報告建議，不要直接動手。"
-  ],
-  "acceptance_criteria": [
-    "每個修改的檔案都要有對應的 Rust 單元測試，以內嵌 C# fixture 驗證：calls（this./obj./static/base./new 五種形式各一）、implements+extends（class 只繼承、class 只實作、class 兩者都有、interface 繼承 interface、struct 實作 interface 共五種）、imports（一般/static/別名/global 四種 + 內外部判定）、exports（public 計入、private/internal 不計入）。",
-    "測試以 `node <worktree>/dev/scripts/run-rust-tests.js csharp` 執行並全數通過（腳本自動套用正典 CARGO_TARGET_DIR，來源 dev/scripts/verify-target-dir.js），log 貼進完成報告。",
-    "`CARGO_TARGET_DIR=$(node <worktree>/dev/scripts/verify-target-dir.js) cargo check --lib -p kenaz-dashboard` 乾淨通過（exit 0，讀 ${PIPESTATUS[0]}）。",
-    "既有語言（rust/go/typescript/javascript/python）在這四個檔案的抽取行為完全不變 —— 執行既有的 calls/implements/imports/exports 相關測試全數通過，log 貼進報告。",
-    "不得修改 symbols.rs / scanner.rs / Cargo.toml —— 那是 TASK_1797 的範圍，本卡開始時它應已合併；若發現 csharp 分支不存在，代表依賴未滿足，停手並回報，不要自己補。"
-  ],
-  "technical_notes": [
-    "前置條件：TASK_1797 必須已合併進 main 且 worktree 是從合併後的 main 開出來的。開工第一件事是確認 `symbols.rs` 的 extract_symbols() 有 \"csharp\" 分支、`scanner.rs` 的 detect_symbol_language() 認得 \"cs\"。不成立就停手回報。",
-    "驗證環境：正典共用 CARGO_TARGET_DIR（來源 dev/scripts/verify-target-dir.js，Windows 為 C:/t/kenaz-verify）避開 vendor/kuzu 的 Windows MAX_PATH，不要自創新目錄（TASK_1879）；並行驗證被 cargo 檔案鎖串行化，'Blocking waiting for file lock' + CPU 近 0 是正常等待不是 hang；不可共用主工作樹 target/（被 live tauri dev 佔用）；不要用 cargo test --lib（STATUS_ENTRYPOINT_NOT_FOUND 0xc0000139，TASK_1619 的 Common-Controls manifest 問題），必須用 dev/scripts/run-rust-tests.js。build.rs 若因 resources glob panic，複製主樹的 dashboard/src-tauri/resources/onnx/ 並設 SKIP_SIDECAR_STAGING=1。",
-    "IMPLEMENTS/EXTENDS 啟發式的誠實邊界：C# 沒有語法層級的區分，`class Foo : Bar` 的 Bar 究竟是 class 還是 interface，只有做完整型別解析才能確定，而 Synapse 是單檔 tree-sitter 抽取、沒有跨檔型別解析。命名慣例（IFoo）在 Unity 生態幾乎普遍遵守，但不是保證。這是刻意接受的近似 —— 請在程式碼註解與完成報告中誠實標明，不要宣稱準確。",
-    "一個更準確但成本更高的替代方案（列入報告供未來評估，本卡不做）：先建立全專案的型別名→kind 索引（TASK_1797 已產生 Symbol 節點含 kind），在關係解析階段查表判定 base_list 每一項是 class 還是 interface。這需要關係抽取從「純單檔」變成「需要符號表」，是架構層級的改動。",
-    "Unity 特有情境：MonoBehaviour 子類別極常見（`class Foo : MonoBehaviour`），MonoBehaviour 是外部型別、專案內沒有對應 Symbol 節點。EXTENDS 邊指向不存在的節點時的處理方式請比照既有語言的做法（查 calls.rs / implements.rs 現有的 unresolved 處理），不要新造機制。",
-    "commit 後不要合併 main —— 由 Ansuz 主幹以 scope 檔案為單位合併。"
-  ]
-}