kenaz 0.0.0-stage → 0.3.2

package/core/.kenaz/specialist/rune_ember_autonomous_dispatch_gate.md

@@ -0,0 +1,24 @@
+# Rune: emberAutonomousDispatch Gate in huginn-loop
+
+**type**: decision
+**confidence**: 0.9
+**symbols**: `.formation/tools/loop.js:buildAnsuzPrompt`, `.kenaz/dashboard-models.json:emberAutonomousDispatch`
+
+## Insight
+
+`loop.js` checks `dashboard-models.json.emberAutonomousDispatch` before including dispatch instructions in the Ansuz prompt.
+
+- `emberAutonomousDispatch = true` → Ansuz creates tasks AND dispatches them + monitors completion (original behavior)
+- `emberAutonomousDispatch = false` (current default) → Ansuz creates tasks in **backlog only**, no dispatch, exits immediately
+
+## Why This Matters
+
+An agent observing the huginn-loop and seeing no dispatch happen will be confused — the prompt code looks like it should dispatch. The gate is invisible unless you read `dashboard-models.json`. This was introduced intentionally to let users manually review tasks before dispatch (safety valve for autonomous mode).
+
+## When It Applies
+
+Any session interpreting huginn-loop behavior or debugging why tasks are landing in backlog instead of being dispatched. Check `emberAutonomousDispatch` in `dashboard-models.json` first.
+
+## Date
+
+2026-05-22 (Auto-Loop iteration 6 observation)

package/core/.kenaz/specialist/rune_post_dispatch_verification_pattern.md

@@ -0,0 +1,31 @@
+---
+type: insight
+name: post_dispatch_verification_gate
+symbol_id: ansuz.rs::PostDispatchValidation
+confidence: 0.78
+author: agent:Muninn
+created: 2026-05-21T12:06:57.531Z
+related_symbols: [ansuz.rs::DispatchWorkflow, task_api.js::merge_process]
+---
+
+# Post-Dispatch Verification Pattern: Branch Containment Check
+
+**Operational Insight**: After dispatching a subagent to a worktree, Ansuz does NOT immediately review code changes. Instead, it first runs `git branch --contains <commit>` to verify the commit actually reached the target branch.
+
+**Why This Matters**:
+- Silent merge failures in post-complete handlers can leave commits orphaned (on worktree branch, never merged to main)
+- Code review of a "missing" commit wastes time and may miss the actual failure mode
+- Branch containment check is a fast gate that filters for this failure class before expensive diff review
+
+**Pattern Observed** (from snapshot #8):
+```
+1. Subagent completes (worktree isolation)
+2. Ansuz queries: git log --all --oneline --grep=<topic>
+3. Ansuz finds commit hash (e.g., 3803e05d)
+4. Ansuz verifies: git branch --contains 3803e05d
+5. ONLY IF commit is on xyz951610: proceed to git diff review
+```
+
+**Related Failure**: This pattern was likely formalized after [[post_complete_merge_stuck_states]] (task merge discrepancy incidents in snapshots #13).
+
+**Recommendation**: Encode this as a pre-commit gate in task-api.complete() — always verify branch containment before signing off on merge=true.

package/core/.kenaz/specialist/rune_surprise_proxy_improvement.md

@@ -0,0 +1,28 @@
+---
+name: surprise_proxy_prediction_accuracy_mismatch
+description: Surprise score uses recency proxy instead of actual prediction accuracy from curiosity engine
+metadata:
+  type: risk
+  confidence: 0.79
+  author: agent:Muninn
+  session_id: ansuz-prompt-1779233477147
+  symbol_id: dashboard/src-tauri/src/features/synapse/efe.rs:surprise_score:function
+  timestamp: 2026-05-20T00:02:15Z
+---
+
+**Hidden constraint**: EFE Surprise component (in `efe.rs` line 1001) uses **recency** as a proxy for `(1 - prediction_accuracy)`, treating recently-modified symbols as "surprising" under the assumption they're harder to predict.
+
+**Problem**: This is a weak proxy. The curiosity engine already computes actual **prediction accuracy** (probability that the next symbol to change matches expectations), but the Surprise score ignores it in favor of a time-decay heuristic.
+
+**Better approach**: Leverage the co-change model's **prediction accuracy** (already computed in `curiosity.rs`) as a direct measure of surprise. Symbols where the model's prediction failed (low accuracy) are genuinely surprising; symbols that are merely recent might be deterministic and boring.
+
+**Trade-off**: 
+- Current (recency proxy): Simple, O(1) lookup, but misses actual information value
+- Proposed (prediction accuracy): More accurate, requires cross-module dependency on curiosity engine state
+
+**Related components**:
+- `dashboard/src-tauri/src/features/synapse/efe.rs:surprise_score()` (current implementation)
+- `dashboard/src-tauri/src/features/synapse/curiosity.rs` (prediction accuracy source)
+- `dashboard/src-tauri/src/features/synapse/co_change.rs` (co-change model backing)
+
+**Risk mitigation**: Cache prediction accuracy in Preamble or use incremental computation to avoid latency spike.

package/core/.kenaz/specialist/rune_worktree_dispatch_pattern.md

@@ -0,0 +1,31 @@
+---
+type: pattern
+name: worktree_isolated_dispatch_workflow
+symbol_id: ansuz.rs::DispatchWorkflow
+confidence: 0.72
+author: agent:Muninn
+created: 2026-05-21T12:06:57.531Z
+related_symbols: [formation_lead.rs, task_api.js::create, agent.rs::isolation]
+---
+
+# Worktree-Isolated Dispatch Pattern for Multi-Agent Execution
+
+**Pattern Identified**: Ansuz uses a consistent workflow for dispatching complex tasks to subagents while maintaining code safety and verification:
+
+1. **Task Activation**: Move task to "active" status via kenaz_task_update (task ID published, scope locked)
+2. **Dispatch Setup**: Create wrapper task containing full implementation prompt, model constraints, and scope
+3. **Worktree Isolation**: Launch subagent with `isolation=worktree` flag (creates isolated git worktree branch)
+4. **Subagent Execution**: Agent works independently, makes commits to worktree branch
+5. **Post-Dispatch Verification**: 
+   - Check if commit reached target branch (`git branch --contains`)
+   - Diff review only after branch verification passes
+   - Validate against codebase rules
+
+**Benefits**:
+- Worktree isolation prevents filesystem conflicts when multiple agents touch same files
+- Clear separation between subagent's work (worktree) and main branch state
+- Verification gate catches merge failures before code review
+
+**Related**: This pattern successfully unblocked TASK_1446 (VarFlow) and TASK_1466 (Yggdrasil identity), both complex multi-file changes. See snapshot #7 for initial dispatch, snapshot #8 for post-dispatch verification.
+
+**Constraint**: Subagent MUST explicitly commit changes; worktree cleanup deletes uncommitted edits. See [[feedback_worktree_must_commit]].

package/core/.kenaz/specialist/rune_yaml_filter_desync_fix.md

@@ -0,0 +1,26 @@
+---
+name: yaml_filter_propagation_desync
+description: YAML filter applied in efe.rs but missing from preamble.rs, causing concept-card pollution in DDx
+metadata:
+  type: fix
+  confidence: 0.82
+  author: agent:Muninn
+  session_id: ansuz-prompt-1779233477147
+  related_commit: e86f9543
+  timestamp: 2026-05-20T00:02:14Z
+---
+
+**Root cause**: Commit e86f9543 added `is_yaml_candidate()` filter to `efe.rs` to prevent YAML concept-card keys from polluting EFE scoring, but the same filter was **not propagated** to `preamble.rs::build_ddx_section()`, which still includes YAML keys in DDx warnings.
+
+**Symptom**: DDx output contains spurious YAML concept-card warnings (keys like `schema:ansuz_rules:yaml`) mixed with legitimate code symbols.
+
+**Fix**: Apply stable_id substring match to both modules:
+- Check if `stable_id` contains `.yaml:` or `.yml:` pattern
+- Skip such entries in both `efe.rs` score calculation AND `preamble.rs` DDx section building
+- ~5 LOC change (string matching on `stable_id` format `{file_path}:{name}:{kind}`)
+
+**Symbol boundaries**:
+- `dashboard/src-tauri/src/features/synapse/efe.rs:is_yaml_candidate()` (source of truth)
+- `dashboard/src-tauri/src/features/synapse/preamble.rs:build_ddx_section()` (needs patch)
+
+**Verification**: Post-fix, DDx output should exclude all YAML-sourced keys.

package/core/.kenaz/specialist/rune_yggdrasil_project_identity_folder_name.md

@@ -0,0 +1,24 @@
+---
+type: decision
+name: yggdrasil_project_identity_git_remote
+symbol_id: yggdrasil.rs::ProjectIdentity
+confidence: 0.85
+author: agent:Muninn
+created: 2026-05-21T12:06:57.531Z
+related_symbols: [yggdrasil.rs, relay_protocol, project_scoping]
+---
+
+# Yggdrasil Project Identity Design Decision
+
+**Decision**: Yggdrasil relay scopes rooms, nodes, and tasks by **git remote URL** instead of folder name for project identity.
+
+**Why**: 
+- Folder names are local filesystem artifacts; they differ across machines and can be renamed without changing the actual project
+- Git remote URL is a stable, globally unique identifier for the actual repository
+- Decouples project identity from local environment, enabling true multi-machine collaboration
+
+**Implementation**: Commit 3803e05d on xyz951610 refactored yggdrasil.rs to extract and use git remote URL from environment or configuration instead of deriving identity from `std::env::current_dir()`.
+
+**Implication**: This enables Yggdrasil relay to maintain consistent project scope across desktop client ↔ relay server ↔ multiple CI/agent workers, all with different folder structures.
+
+**Test Coverage**: TASK_1466 includes Settings UI changes to allow users to configure project identity source (should default to git remote, with fallback option).

package/core/.kenaz/specialist/sessions/chart_TASK_1599.json

@@ -0,0 +1,41 @@
+{
+  "task_id": "TASK_1599",
+  "session_date": "2026-06-11",
+  "progress": [
+    {
+      "phase": "P1 - task-api.js create command patch",
+      "status": "DONE",
+      "notes": "Added --args-file transport to create command. camelCase+snake_case dual key resolution via fromFile(). CLI flags override file values. Validation (quality gate, error on missing/invalid file) preserved."
+    },
+    {
+      "phase": "P2 - task-api.js update command patch",
+      "status": "DONE",
+      "notes": "Added --args-file transport to update command with same pattern. updateFileData/fromUpdateFile resolver. All existing update fields supported via file transport."
+    },
+    {
+      "phase": "P3 - kenaz.rs tool_task_create rewrite",
+      "status": "DONE",
+      "notes": "Replaced argv vector build with JSON temp file approach. TmpFileGuard Drop struct guarantees cleanup on all exit paths. serde_json::json! macro builds payload from MCP args. Unique temp file: pid + subsec_nanos."
+    },
+    {
+      "phase": "P4 - node --check verification",
+      "status": "DONE",
+      "notes": "task-api.js syntax OK after both patches."
+    },
+    {
+      "phase": "P5 - functional test 60KB CJK+emoji",
+      "status": "DONE",
+      "notes": "Created task via --args-file with 61KB payload (22K chars), CJK/emoji/arrows all preserved in YAML. No mojibake. No BOM."
+    },
+    {
+      "phase": "P6 - regression test normal CLI flags",
+      "status": "DONE",
+      "notes": "Normal flag-based create still works. Quality gate fires correctly."
+    }
+  ],
+  "cargo_check": "DEFERRED (onnxruntime.dll lock when dashboard running -- proven constraint documented in ADDENDA)",
+  "files_modified": [
+    ".collaboration/core/task-api.js",
+    "dashboard/src-tauri/src/infrastructure/http_server/routes/mcp_tools/kenaz.rs"
+  ]
+}

package/core/.kenaz/specialist/sessions/hmap_028aa781-aad2-48c0-9a61-5540565d4a7f.json

@@ -0,0 +1,5 @@
+{
+  "conversation_id": "028aa781-aad2-48c0-9a61-5540565d4a7f",
+  "boot_sid": "boot-1785095994290-24936",
+  "bound_at": "2026-07-26T22:00:37.526Z"
+}

package/core/.kenaz/specialist/sessions/hmap_20210387-0c64-400c-9d0a-53042a0cbd89.json

@@ -0,0 +1,5 @@
+{
+  "conversation_id": "20210387-0c64-400c-9d0a-53042a0cbd89",
+  "boot_sid": "boot-1784868462336-25784",
+  "bound_at": "2026-07-24T04:49:44.587Z"
+}

package/core/.kenaz/specialist/sessions/hmap_c1375c5d-fd9f-44bd-a83e-353ecbb0392f.json

@@ -0,0 +1,5 @@
+{
+  "conversation_id": "c1375c5d-fd9f-44bd-a83e-353ecbb0392f",
+  "boot_sid": "boot-1786552071759-33876",
+  "bound_at": "2026-08-12T16:46:07.322Z"
+}

package/core/.kenaz/specialist/sessions/scratch_028aa781-aad2-48c0-9a61-5540565d4a7f.json

@@ -0,0 +1,6 @@
+{
+  "session_id": "boot-1785095994290-24936",
+  "conversation_id": "028aa781-aad2-48c0-9a61-5540565d4a7f",
+  "pid": 2176,
+  "started_at": "2026-07-26T19:59:54.335Z"
+}

package/core/.kenaz/specialist/sessions/scratch_0acc0fb3-24f9-453f-9e92-6ef1cdf03a7c.json

@@ -0,0 +1,6 @@
+{
+  "session_id": "boot-1784928621627-33020",
+  "conversation_id": "0acc0fb3-24f9-453f-9e92-6ef1cdf03a7c",
+  "pid": 11368,
+  "started_at": "2026-07-24T21:30:21.660Z"
+}

package/core/.kenaz/specialist/sessions/scratch_20210387-0c64-400c-9d0a-53042a0cbd89.json

@@ -0,0 +1,6 @@
+{
+  "session_id": "boot-1784868462336-25784",
+  "conversation_id": "20210387-0c64-400c-9d0a-53042a0cbd89",
+  "pid": 14980,
+  "started_at": "2026-07-24T04:47:42.374Z"
+}

package/core/.kenaz/specialist/sessions/scratch_2f10623e-b7a1-4647-905e-9dc7c4d99f9c.json

@@ -0,0 +1,6 @@
+{
+  "session_id": "boot-1784920910838-31920",
+  "conversation_id": "2f10623e-b7a1-4647-905e-9dc7c4d99f9c",
+  "pid": 35584,
+  "started_at": "2026-07-24T19:21:50.887Z"
+}

package/core/.kenaz/specialist/sessions/scratch_5a38b62d-608a-488c-82f0-7e47e95e0905.json

@@ -0,0 +1,6 @@
+{
+  "session_id": "boot-1784959921363-30344",
+  "conversation_id": "5a38b62d-608a-488c-82f0-7e47e95e0905",
+  "pid": 36860,
+  "started_at": "2026-07-25T06:12:01.402Z"
+}

package/core/.kenaz/specialist/sessions/scratch_5d9758ef-d9b6-4ffe-a017-3ed26d0a313b.json

@@ -0,0 +1,6 @@
+{
+  "session_id": "boot-1784918993786-9900",
+  "conversation_id": "5d9758ef-d9b6-4ffe-a017-3ed26d0a313b",
+  "pid": 20972,
+  "started_at": "2026-07-24T18:49:53.835Z"
+}

package/core/.kenaz/specialist/sessions/scratch_c1375c5d-fd9f-44bd-a83e-353ecbb0392f.json

@@ -0,0 +1,6 @@
+{
+  "session_id": "boot-1786557954504-30888",
+  "conversation_id": "c1375c5d-fd9f-44bd-a83e-353ecbb0392f",
+  "pid": 33732,
+  "started_at": "2026-08-12T18:05:54.540Z"
+}

package/core/.kenaz/specialist/sessions/scratch_c9f3c711-b73d-4fcd-ad2a-7b2bc024ee77.json

@@ -0,0 +1,6 @@
+{
+  "session_id": "boot-1786471408394-16480",
+  "conversation_id": "c9f3c711-b73d-4fcd-ad2a-7b2bc024ee77",
+  "pid": 14964,
+  "started_at": "2026-08-11T18:03:28.426Z"
+}

package/core/.kenaz/specialist/sessions/scratch_e72e5274-1c81-4655-a05a-f87d1ecb2917.json

@@ -0,0 +1,6 @@
+{
+  "session_id": "boot-1784989318944-2896",
+  "conversation_id": "e72e5274-1c81-4655-a05a-f87d1ecb2917",
+  "pid": 16472,
+  "started_at": "2026-07-25T14:21:58.985Z"
+}

package/core/.kenaz/specialist/sessions/scratch_f740cdbe-f756-41fc-98fb-2b1413d51901.json

@@ -0,0 +1,6 @@
+{
+  "session_id": "boot-1786091982696-5792",
+  "conversation_id": "f740cdbe-f756-41fc-98fb-2b1413d51901",
+  "pid": 36484,
+  "started_at": "2026-08-07T08:39:42.740Z"
+}

package/core/.kenaz/specialist/t1777_probe.txt

@@ -0,0 +1 @@
+probe-initial-content

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

@@ -0,0 +1,43 @@
+{
+  "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/task1827_update.json

@@ -0,0 +1,43 @@
+{
+  "title": "GC 無法判定「工作是否已落地」：合併流程不留痕跡，推論法已證偽，21 個 worktree 裡 19 個乾淨卻永不回收",
+  "description": "本卡於 2026-07-27 第二次改寫（第一次是同日修正「13 個裡有 7 個」的錯誤量測）。改寫依據是主線程對現況的完整重新量測，原始範圍陳述已作廢。\n\n【現況實測】\nGC 看得到的 worktree 共 21 個：.kenaz-worktrees/KenazAI 13 個、.formation/worktrees 8 個。分類如下：\n- clean 但 UNMERGED：19 個 —— 這才是絕大多數。它們沒有任何髒檔，純粹因為分支 tip 不是 HEAD 的祖先而被保留\n- merged 且各有 1 個髒檔：2 個 —— 這是本卡原本唯一涵蓋的族群\n\n磁碟：.formation/worktrees 2.0 GB ＋ .kenaz-worktrees 970 MB ＝ 約 3.0 GB（另有第三家族見下）。\n\n【推論法已被證偽，這是本卡的核心】\n主線程在 2026-07-27 親手以 file-scoped checkout 合併了 ansuz-wt-68ed9c57-12936（TASK_1825），逐檔比對確認內容與 main 完全一致，並跑過四套測試。即便如此：\n- git cherry main ansuz-wt-68ed9c57-12936 仍判定它有 1 個 commit 在 main 找不到等價 patch\n- 它的分支 tip 也不是 HEAD 的祖先\n這是一個已知答案的控制組：工作確實落地了，而兩種推論法都答錯。原因是 file-scoped checkout 加另開新 commit 會產生不同的 parent 脈絡，patch-id 因此不同；ancestry 更是從一開始就不成立。\n\n結論：GC 不可能靠 ancestry 或 patch 等價去推論「工作是否已落地」。這不是實作沒寫好，是資訊在合併當下就沒有被保存下來。\n\n【本卡的方向：不推論，由落地的人記錄】\n合併成功的那一刻，執行合併者知道事實。讓它寫下來，GC 只負責讀。這同時解掉 19 個既有目錄與未來的持續累積，而不需要任何啟發式猜測。\n\n必須覆蓋兩條合併路徑，只做一條等於沒做：\n(a) 自動路徑：post-complete/git-merge.js 的 gitBranchAndMerge 合併成功後\n(b) 人工路徑：Ansuz 主線程的 file-scoped checkout 合併（目前沒有任何程式碼，是主線程手動操作）—— 因此必須提供一個可被人工呼叫的子指令或 CLI\n\n【次要範圍：daemon 髒檔辨識】\n那 2 個 merged 但被髒檔卡住的 worktree 仍要處理，但實測推翻了原本的分類假設：\n\n| worktree | 唯一髒檔 | git status | 性質 |\n|---|---|---|---|\n| wt-595952d1-22448 | .kenaz/specialist/ansuz_project_pins.json | ?? 未追蹤 | daemon 狀態，可再生 |\n| wt-cfc76e4c-70088 | .formation/TASK_1739_HANDOFF.md | ?? 未追蹤 | agent 產出的 handoff 文件，不是 daemon 掉落物 |\n\n原卡把第二個描述成「單一 daemon 狀態檔」，實測不成立。兩者都是未追蹤檔，所以「已追蹤原始碼才算真實工作」這條二分法對這兩個標本都不適用 —— 真正需要的是在未追蹤檔之內做出區別。\n\n【明確排除在本卡之外】\n第三個 worktree 家族 .claude/worktrees/agent-*：21 個目錄、1.7 GB、git 有註冊，但 GC 的兩個 base dir 都不包含它，因此完全在視野外。實測其 mtime 全部落在 2026-07-24 至 07-25、26 小時以上未動，且昨日整場 dispatch 完全沒有新增 —— TASK_1586 的 redirect hook 已經堵住源頭。這是凍結的歷史遺留，屬一次性稽核清理，不是 GC 設計問題。本卡不得把 GC 擴張到該目錄（harness 擁有，誤刪會殺掉活著的 agent）。",
+  "priority": "P2",
+  "rigor": "high",
+  "complexity": "medium",
+  "tags": ["fix", "code", "worktree", "gc", "disk", "silent-failure"],
+  "scope_paths": [
+    ".claude/hooks/worktree-create.js",
+    ".formation/tools/post-complete/git-merge.js",
+    ".kenaz/specialist/daemon-manifest.yaml"
+  ],
+  "requirements": [
+    "核心：合併成功時寫下 landed 註記，GC 改為讀取該註記，不再以 ancestry 或 patch 等價推論落地與否。兩條合併路徑都要覆蓋：post-complete/git-merge.js 的自動合併，以及主線程 file-scoped 手動合併所需的可呼叫子指令或 CLI。只做自動路徑等於沒做，因為目前絕大多數合併是人工路徑。",
+    "註記格式必須是可稽核、人可讀、可手動檢視與撤銷的持久化形式（純文字 / JSON / git ref 皆可）。不得只存在於記憶體或需要啟動 dashboard 才能讀取。選擇的理由寫進筆記。",
+    "GC 的回收條件必須是合取：有 landed 註記 AND 無已追蹤原始碼的未提交修改 AND 目錄 mtime 超過 GC_MIN_AGE_MS AND 不是 keepPath。缺少 landed 註記時一律保留，不得有任何繞過。",
+    "次要範圍：未追蹤檔的 daemon 噪音辨識。兩個標本的髒檔都是 ?? 未追蹤（ansuz_project_pins.json 與 TASK_1739_HANDOFF.md），所以 tracked/untracked 二分無法區別它們，必須明確定義未追蹤檔案中何者屬於可丟棄的 daemon 噪音，並說明為何不採用其他候選方案。",
+    "不得直接拿現行 daemon-manifest.yaml 當白名單就了事 —— 已查證它漏掉 .claude/settings.json、.kenaz/channel_heartbeats.jsonl、.synapse/prediction_resolution_log.jsonl、.kenaz/specialist/ansuz_project_pins.json 四個實際會變髒的檔案。若選擇靠 manifest，必須同時補齊，並確認不影響 TASK_1818 已拆分的兩個區段語意。",
+    "任何情況下，位於已追蹤原始碼的未提交修改都必須視為真實工作而保留。",
+    "保留某個 worktree 時必須輸出可觀察的診斷行，指名是哪個條件、哪個檔案造成保留。目前完全無聲，使用者無從得知為何清不掉。",
+    "保持 keepPath 排除與 GC_MIN_AGE_MS=2h 兩項現行條件不變；GC_MIN_AGE_MS 絕對不可調短。",
+    "不得把 GC 的掃描範圍擴張到 .claude/worktrees/ —— 該目錄由 harness 擁有，誤刪會殺掉執行中的 agent。那 21 個目錄的清理另案處理。"
+  ],
+  "acceptance_criteria": [
+    "全部驗證在拋棄式 repo 進行，不得對本專案現存的任何 worktree 執行實際刪除；報告中須註明驗證環境",
+    "拋棄式 repo 實跑：有 landed 註記 + 髒檔僅含 daemon 噪音 + 已過 2h → 被回收，以實跑輸出為證",
+    "拋棄式 repo 實跑：有 landed 註記 + 存在已追蹤原始碼的未提交修改 → 保留，且診斷行指名該檔案，以實跑輸出為證",
+    "拋棄式 repo 實跑：無 landed 註記（且刻意讓分支 tip 不是 HEAD 祖先，重現本卡的控制組情境）→ 保留，以實跑輸出為證",
+    "拋棄式 repo 實跑：目錄 mtime 未滿 2h → 完全不碰，以實跑輸出為證",
+    "人工合併路徑：以子指令或 CLI 手動寫入 landed 註記後，同一個 worktree 從「保留」轉為「可回收」，以前後兩次實跑輸出對照為證",
+    "自動合併路徑：post-complete 合併成功後確實寫入 landed 註記，以實跑輸出或既有測試覆蓋為證",
+    "回歸：post-complete 27/27、task1536 7/7、task1543 4/4、worktree-rescue 3/3 全綠（node:test 印「ℹ pass N」，讀 N 不要只讀 exit code）",
+    "對本 repo 現況執行唯讀 dry-run，輸出 21 個 GC 可見 worktree 的分類表（可回收 / 保留＋原因），附完整輸出。不得實際刪除任何一個。"
+  ],
+  "technical_notes": [
+    "控制組證據，這是本卡方向的依據：ansuz-wt-68ed9c57-12936 由主線程於 2026-07-27 以 file-scoped checkout 合併（commit ee897397），逐檔驗證內容與 main 一致且四套測試全綠。即便如此 git cherry 仍報它有 1 個 commit 無等價 patch，且 tip 不是 HEAD 祖先。已知答案的案例上兩種推論法都答錯 —— 不要再嘗試改良推論，資訊必須在合併當下被記錄。",
+    "GC 現況在 .claude/hooks/worktree-create.js 的 gcStaleWorktrees()：只掃兩個 base dir（<repoParent>/.kenaz-worktrees/<repoName> 與 <repo>/.formation/worktrees），且檔名須以 wt- 或 task_ 開頭。TASK_1826 剛修過 task_ 命名不在視野內與 husk rev-parse 拋錯兩個問題。",
+    "TASK_1826 的教訓，量測時務必先確認：沒有自己 .git 的 husk，git -C <husk> status --porcelain 會向上解析到主 repo，回報的是主 repo 的狀態。五個 husk 曾因此全部量到同一個 dirty=76。",
+    "本卡不改變 post-complete 的完成語義，也不搬動任何任務卡狀態。",
+    "現況磁碟：.formation/worktrees 2.0 GB、.claude/worktrees 1.7 GB、.kenaz-worktrees 970 MB，合計約 4.7 GB。",
+    "原 requirement 6 的「以現存 13 個 worktree 驗證該回收 7 個、該保留 6 個」已作廢：實測 GC 可見者為 21 個，其中僅 2 個 merged。"
+  ]
+}

package/core/.kenaz/specialist/task1828_update.json

@@ -0,0 +1,43 @@
+{
+  "title": "handoff 讀回端全部指向 M3 已廢棄的單數檔：Rust 回傳三個空欄位，relay 通知摘要靜默退化成泛用字串",
+  "description": "本卡於 2026-07-27 依實測補正。原描述的核心診斷正確，但漏了一個真實消費者、錯記了一個不 stale 的檔案，且「哪個位置才對」其實程式碼裡已有答案，不需要再決策。\n\n【已在程式碼中確定的事實：不必再決策】\nansuz-handoff-snapshot.js 第 452-458 行的註解寫明 TASK_1760 M3 遷移：per-session slot 在 handoffs/<sessionId>.json，單數的 ansuz_session_handoff.json「read-only after this migration; new writes go to per-session slot」。AGENTS.override.md 第 599 與 653 行也已寫明「boot readers check handoffs/ first, fall back to legacy slot」。\n\n因此 handoffs/<sessionId>.json 是正確位置，單數檔是 legacy。本卡不需要再重新選一次，只需要讓所有讀回端跟上這個已經做過的決定。\n\n附帶事實：core 的 .kenaz/specialist/ 底下根本沒有 ansuz_session_handoff.json，所以每一個依賴它的讀取都是 existsSync=false 的無聲失敗。\n\n【五個讀回端 / 引用，逐一實測】\n1. kenaz.rs:1327 — tool_ansuz_handoff_snapshot 只讀單數檔來填 handoff_path / session_id / generated_at。本 session 已連續複現四次，三個欄位每次都是空字串，只有 cli_output 與 isbar_summary 帶著腳本 stdout 原文。呼叫端無法從結構化回傳得知檔案寫到哪。\n2. post-complete.js:2843 — 原卡未提及，這是使用者看得見的那條。它讀單數檔取 isbar.situation.current_topic 作為 relay task_completed 通知的摘要。檔案不存在 → existsSync false → 永遠退回泛用的「[TASK_XXX] task completed」。M3 遷移之後每一則跨節點完成通知都失去了當時的 session 主題。\n3. git-merge.js:30 PRESERVE_WORKING_TREE — TASK_1627 專門為單數檔加了保護，註解寫「live-doc: updated each session turn」。它保護的是一個不存在的檔案，而這份保護的存在又讓後來的人相信它存在。\n4. elixir.yaml:28 — HANDOFF LIVE DOC mandate 明文要求 Ansuz「Update ansuz_session_handoff.json」。這條指示本身是錯的，會讓每一個 session 的 Ansuz 相信自己在維護一個單數 live-doc。\n5. AGENTS.override.md — 原卡列它為 stale，實測不成立。599 與 653 兩行已經正確描述 handoffs/ 優先、legacy 僅 fallback 的語意；只有 588 行的行文仍用單數檔名指稱 ISBAR 這個概念。不要為了「修好它」而改動已經正確的語意。\n\n另外 ansuz-handoff-snapshot.js:458 宣告了 legacyHandoffPath 之後全檔未再使用，是遷移留下的死變數。\n\n【命名分歧】\nhandoffs/ 目錄下兩套命名並存：ansuz-prompt-<timestamp>.json 與 <conversation-uuid>.json，來自不同呼叫端對 sessionId 的推導方式。數量會隨歸檔浮動（開卡時 4+12，本 session 稍後為 1+5），所以不要以數量作為驗收依據，要以「命名規則是否收斂」為準。\n\n【這是什麼類別的缺陷】\n沒有任何一處會崩、會警告。空字串看起來像「這個工具本來就不回傳那些欄位」，泛用摘要看起來像「摘要本來就長這樣」。這與本 session 另外兩張卡（1825 的驗收降級路徑、1827 的 GC 靜默保留）屬同一類。",
+  "priority": "P2",
+  "rigor": "medium",
+  "complexity": "medium",
+  "tags": ["fix", "code", "handoff", "silent-failure", "drift"],
+  "scope_paths": [
+    "dashboard/src-tauri/src/infrastructure/http_server/routes/mcp_tools/kenaz.rs",
+    ".specialist/Ansuz/tools/ansuz-handoff-snapshot.js",
+    ".formation/tools/post-complete.js",
+    ".formation/tools/post-complete/git-merge.js",
+    ".specialist/Ansuz/elixir.yaml"
+  ],
+  "requirements": [
+    "⚠️ 建置禁令，違反會破壞使用者環境：dashboard backend 目前在 18080 活著（實測 http 200），且 tauri dev 的 watcher 會對 *.rs 觸發重建。你在隔離 worktree 中「只改程式碼、不執行任何 cargo build / cargo check / npm build」。Rust 的實際重建與活體驗證由主線程負責。改完 commit 後直接回報。",
+    "kenaz.rs 的讀回路徑改為以 handoffs/<sessionId>.json 為主、單數檔僅作 back-compat fallback，使回傳的 handoff_path / session_id / generated_at 真的有值。sessionId 的來源必須明確：若 Rust 端無從得知腳本用了哪個 sessionId，則改為解析腳本 stdout 或取 handoffs/ 中最新者，並在註解說明取捨。",
+    "post-complete.js:2843 的 relay 摘要讀取改為同一套解析（handoffs/ 優先、legacy fallback），讓跨節點完成通知重新帶上 session 主題。這是本卡使用者可感知的部分，不可略過。",
+    "git-merge.js:30 的 PRESERVE_WORKING_TREE 條目要處理：若單數檔確定不再被寫入，保護它就沒有意義。移除或改為保護 handoffs/ 目錄，二選一，理由寫進註解。注意該陣列上方的註解明文要求「不要為了其他 daemon 檔擴張這個陣列」，請遵守其原意。",
+    "elixir.yaml:28 的 HANDOFF LIVE DOC mandate 必須改為指向 handoffs/<sessionId>.json，不得繼續指示 Ansuz 維護一個不存在的單數檔。這是行為指示，錯了會讓每一個 session 都照錯的做。",
+    "ansuz-handoff-snapshot.js:458 的死變數 legacyHandoffPath：移除，或若讀回端需要它就明確使用它。不得留著宣告而不用。",
+    "AGENTS.override.md 不在 scope 內，不要改它 —— 599/653 兩行的語意已經正確。原卡把它列為 stale 是誤判。",
+    "兩套 sessionId 命名（ansuz-prompt-<ts> 與 <conversation-uuid>）必須收斂成一套，或在筆記中明確記錄為何兩者都必須存在、以及讀回端如何在兩者並存時正確選擇。",
+    "不得處理另一個 session 回報的「子專案 handoff 落到 core」—— 那條需要先釐清 kenaz-core binary 版本差異，不屬本卡。"
+  ],
+  "acceptance_criteria": [
+    "【agent 可自驗】以 node 直接呼叫 ansuz-handoff-snapshot.js 產生一份 handoff，再以 node 執行你新寫的讀回解析邏輯，證明它取得非空的 path / session_id / generated_at，附實跑輸出",
+    "【agent 可自驗】post-complete.js 的 relay 摘要路徑：以一份 isbar.situation.current_topic 有值的 handoff 實測，證明摘要不再退回泛用字串，附實跑輸出",
+    "【agent 可自驗】兩套命名並存時讀回端選中的是哪一個，以實跑輸出證明選擇邏輯確定且可預期（例如同時放入 ansuz-prompt-<ts> 與 <uuid> 兩份，看它選誰）",
+    "【agent 可自驗】Rust 側只做語法層面自我檢查（讀周邊程式碼、比對既有 serde/path 用法），並在報告中明確寫出「未執行任何建置」",
+    "【agent 可自驗】既有 JS 測試不退步：post-complete 27/27、task1536 7/7、task1543 4/4、worktree-rescue 3/3（node:test 印「ℹ pass N」，讀 N 不要只讀 exit code）",
+    "【主線程驗證，agent 不必也不得執行】合併後由主線程觸發活體重建，實呼叫一次 ansuz_handoff_snapshot，確認 handoff_path / session_id / generated_at 三個欄位皆非空且 handoff_path 逐字對應磁碟上實際存在的檔案",
+    "全 repo 不再有任何「寫入端寫 A、讀回端讀 B」的殘留：附上 grep -rn ansuz_session_handoff 的結果，每一處命中都要能說明它為何仍該存在（back-compat fallback 或純註解）"
+  ],
+  "technical_notes": [
+    "dashboard backend 在 18080 活著（實測 http 200）。rune_tauri_dev_selective_watcher：tauri dev 的 watcher 對 *.rs 觸發重建與重啟，對 JS/TS 不觸發。你在 worktree 中編輯不會驚動主樹的 watcher，但主樹一旦合併就會重建 —— 這正是主線程負責活體驗證的原因。",
+    "worktree 內的 cargo 驗證在本專案是假信心：build.rs 與 vendor CMake 的 MAX_PATH 問題會讓它失敗或誤導（reference_worktree_rust_verify_recipe）。不要嘗試繞過建置禁令。",
+    "M3 遷移的權威來源是 ansuz-handoff-snapshot.js 452-458 行的註解與 AGENTS.override.md 599/653。讀它們，不要自己重新發明位置規則。",
+    "kenaz.rs 的讀回在 1327 行附近；tool_ansuz_handoff_snapshot 約 1285 行起。",
+    "handoffs/ 目錄的檔案數會被歸檔機制與 archiveHandoffToHippocampus 改變（本 session 從 17 降到 6），所以任何以「目錄下有 N 個檔」為前提的驗證都不可靠。",
+    "本卡與 TASK_1825、TASK_1827 屬同一缺陷類別：降級路徑靜默回報正常值。空字串與泛用摘要都不會觸發任何告警。"
+  ]
+}

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

@@ -0,0 +1,38 @@
+{
+  "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

@@ -0,0 +1,44 @@
+{
+  "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）。"
+  ]
+}