kenaz 0.3.22 → 0.3.23

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

@@ -1,34 +0,0 @@
-{
-  "title": "非當前專案的 embedding backfill 從未觸發：Ashfall 有 433 個符號但 embedding_entries=0",
-  "description": "原始報告懷疑「嵌入管線是否曾經成功執行過」。Ansuz 已實測推翻該假設：KenazAI 自身 embedding_entries=10188（symbol_entries 24218），管線本身健康。真正的問題較窄 —— Ashfall（D:\\Projects\\Ashfall）有 433 個符號（markdown 248 / rust 133 / js 39 / yaml 11 / python 2）卻是 embedding_entries: 0。所以嵌入不是壞掉，而是對「非當前開啟的專案」從未被觸發。synapse_search 文件宣稱是 FTS5 + embedding 向量 + 圖譜熱度的混合檢索，對這類專案等於只有三分之二在運作，且同樣沒有任何訊號告知使用者。附帶一個小的內部不一致待釐清：synapse_status 回報 Ashfall symbol_entries=387，但按語言加總 Symbol 表為 433，差 46。",
-  "priority": "P3",
-  "role": "developer",
-  "rigor": "low",
-  "complexity": "medium",
-  "tags": ["fix", "code"],
-  "scope_paths": [
-    "dashboard/src-tauri/src/features/synapse/"
-  ],
-  "estimated_hours": 2,
-  "requirements": [
-    "查清 embedding 產生的觸發條件：它是索引流程的一部分、還是獨立的 backfill 步驟（注意已存在 synapse_backfill_trigger_embeddings 這個 MCP 工具，它的存在本身就暗示 backfill 是手動/獨立觸發的）。把實際的觸發鏈寫清楚。",
-    "判定「非當前專案索引時不產生 embedding」是刻意設計（例如成本考量、ONNX 模型只對 current project 載入）還是缺陷。這個判定要有程式碼證據，不要用猜的。",
-    "若是缺陷 —— 提出最小修法並實作。若是刻意設計 —— 不要改行為，改成讓它可見：synapse_status 應能表達「此專案的向量檢索未就緒」，而不是只回一個沒有上下文的 0。",
-    "釐清 symbol_entries（status 回報值）與 Symbol 節點實際總數的差異來源。可能的方向：兩者查的不是同一張表（status 可能查 FTS symbol 表、Cypher 查的是圖節點）、Concept 這類虛擬節點的計入與否、或去重。查清楚後在 status.rs 對該欄位補一行註解說明它精確代表什麼。",
-    "本卡的產出可以是「診斷報告 + 小修」而非大改。若查清後認為正確修法是架構級的，寫成建議並開後續卡，不要在本卡硬幹。"
-  ],
-  "acceptance_criteria": [
-    "完成報告中明確回答三個問題：(1) embedding 的觸發鏈是什麼（附程式碼路徑與行號）；(2) 非當前專案為何沒有 embedding —— 設計還是缺陷，證據為何；(3) symbol_entries 387 vs 433 的差異來源是什麼。",
-    "若判定為缺陷並實作了修法：`CARGO_TARGET_DIR=$(node <worktree>/dev/scripts/verify-target-dir.js) cargo check --lib -p kenaz-dashboard` 乾淨通過（exit 0），且新增至少一條單元測試涵蓋修改的邏輯。",
-    "若判定為刻意設計：status.rs 的 embedding_entries 欄位旁補上說明註解，且提出（不必實作）如何讓使用者看見「向量檢索未就緒」的具體方案。",
-    "無論哪條路徑，都不得為了讓數字好看而修改統計口徑 —— 若 387 與 433 的差異是真實的資料不一致，如實回報，不要用 COALESCE 之類手法把它抹平。"
-  ],
-  "technical_notes": [
-    "已知事實（Ansuz 實測，不需重驗但可複驗）：KenazAI 專案 synapse_status 回傳 embedding_entries=10188、symbol_entries=24218、fts_entries=4774、relationships=22204。Ashfall 回傳 embedding_entries=0、symbol_entries=387、fts_entries=46391。注意 KenazAI 的 fts_entries 遠小於 symbol_entries，而 Ashfall 相反 —— 這個反轉本身可能是線索（Ashfall 的 FTS 幾乎全是檔案層級條目，因為幾乎沒有符號）。",
-    "相關工具：synapse_backfill_trigger_embeddings（MCP）。先讀它的實作，很可能直接回答「觸發鏈是什麼」。",
-    "本卡與 TASK_1798 都可能碰 status.rs。**必須在 TASK_1798 合併後才開工**，且 worktree 從合併後的 main 開出來。若你需要動 status.rs 的範圍超過「加註解」，先回報再動。",
-    "驗證環境：正典共用 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。",
-    "不要對 D:\\Projects\\Ashfall 執行重新索引 —— 使用者明確要求本輪不動該專案。所有推論以程式碼閱讀 + KenazAI 自身為對照組。",
-    "來源報告：C:\\Users\\user\\Desktop\\SYNAPSE_CSHARP_INDEXING_REPORT.md（缺陷 4，但報告的『管線可能從未執行』假設已被推翻，範圍已收窄）。"
-  ]
-}

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

@@ -1,39 +0,0 @@
-{
-  "title": "出貨衛生：.claude/settings.json 洩漏舊機器路徑與他人專案名 + build-static.js 兩處註解與實際行為不符",
-  "description": "TASK_1795 把 stageKenazCore 改成 git 白名單後，未追蹤的垃圾不會再出貨，但兩個「被追蹤所以合法通過白名單」的問題留了下來。(1) .claude/settings.json 在 INCLUDE_DIRS 內（build-static.js:198 '.claude'）隨產品出貨，其 permissions.allow 有 121 條，其中 21 條含舊機器絕對路徑 d:/Projects/KenazAI 與前一位使用者家目錄 C:/Users/Wei/，且洩漏了兩個無關的第三方專案名（Firstrade_m…、deardearly_…）。這與 TASK_1795 修的是同一類洩漏（那張是 P1）。同時 allow 已含 Bash(*)/Read(*)/Write(*)/Edit(*)/Grep(*)/Glob(*)/Search(*)，所以那 100 多條逐條列舉的 Bash 授權完全是死條目，刪掉不影響任何權限。(2) build-static.js:287 的註解宣稱 'main-memory are NO LONGER shipped'，但 .kenaz/main-memory/ 有 27 個 git 追蹤檔（160K）且 EXCLUDE_PATTERNS 裡沒有任何對應條目 —— 它一直在出貨。經內容檢視，該目錄是人工維護的 Kenaz 架構/知識文件（README 明載「唯讀設計，僅開發者手動更新」），不是 session 衍生的私密記憶，出貨是正確行為；錯的是註解。",
-  "priority": "P1",
-  "role": "developer",
-  "rigor": "medium",
-  "complexity": "low",
-  "tags": ["fix", "code"],
-  "scope_paths": [
-    ".claude/settings.json",
-    "dashboard/scripts/build-static.js"
-  ],
-  "estimated_hours": 1.5,
-  "requirements": [
-    "清理 .claude/settings.json permissions.allow：刪除全部含舊機器絕對路徑的條目（比對 /d/Projects、d:/Projects、C:/Users/Wei、以及任何指向本 repo 以外專案的路徑）。",
-    "同時刪除被 Bash(*) 完全涵蓋的逐條 Bash 授權死條目（allow 已含 Bash(*)，逐條列舉沒有任何額外效果，只是歷史沉積）。保留 Bash(*) 本身。",
-    "permissions.deny 完全不動 —— 那是實際生效的安全護欄（rm -rf、git push --force、git reset --hard、DROP TABLE 等 27 條）。",
-    "hooks 區塊完全不動 —— WorktreeCreate/WorktreeRemove/SessionStart/SessionEnd/Stop 都是活的執行路徑，改壞會讓 session 生命週期靜默失效。",
-    "worktree.baseRef 不動（目前為 'head'，是 TASK_1794 正在調查的對象，本卡不涉入）。",
-    "build-static.js:287 的註解改成與實際行為一致：main-memory 是被追蹤的人工知識文件、確實隨產品出貨且這是刻意的；EFE snapshots 因為未被 git 追蹤而自然不出貨（白名單模式的結果，不是靠 EXCLUDE）。不要為了讓註解成真而去加 EXCLUDE 條目 —— 那會拔掉真正該出貨的內容。",
-    "build-static.js:319 的 'Twin rule: sync-kenaz-core.js .synapse fileFilter + NEWLY_EXCLUDED — keep both in sync' 註解目前已是假話（TASK_1796 記錄了兩者的白名單/黑名單分歧）。本卡只需在該註解加上指向 TASK_1796 的 STALE 標註，不要動 sync-kenaz-core.js —— 那是 TASK_1796 的範圍。"
-  ],
-  "acceptance_criteria": [
-    "`node -e \"const a=require('./.claude/settings.json').permissions.allow; const bad=a.filter(x=>/d:\\/Projects|\\/d\\/Projects|C:\\/Users\\/Wei|Firstrade|deardearly/i.test(x)); if(bad.length){console.error(bad); process.exit(1)} console.log('clean, entries:', a.length)\"` 回傳 exit 0，且條目數顯著低於原本的 121。",
-    "settings.json 仍是合法 JSON，且 permissions.deny 條目數與內容與修改前逐字相同（用 diff 證明），hooks 區塊 byte-identical。",
-    "grep 確認 .claude/settings.json 全檔不再含任何本 repo 以外的絕對路徑（搜 'd:/Projects'、'/d/Projects'、'C:/Users/Wei'、'C:\\\\Users\\\\Wei'）。",
-    "build-static.js:287 與 :319 兩處註解已更新且與實際程式行為一致；EXCLUDE_PATTERNS 陣列本身不得有任何新增或刪除（純註解修改，用 diff 證明）。",
-    "`cd dashboard && node -e \"const {stageKenazCore}=require('./scripts/build-static.js'); console.log(typeof stageKenazCore)\"` 仍印出 'function'（模組沒被改壞）。",
-    "不得修改 sync-kenaz-core.js（TASK_1796 範圍）、不得修改 dashboard/scripts/build-static.js 的 INCLUDE_DIRS / EXCLUDE_PATTERNS / RUNTIME_DIRS 任何資料條目。"
-  ],
-  "technical_notes": [
-    "為什麼刪 Bash 逐條授權是安全的：allow 陣列裡已經有 'Bash(*)'，Claude Code 的 permission 比對是 OR 語意，任何 Bash 呼叫都會先被 Bash(*) 命中。逐條的 'Bash(node .collaboration/core/task-api.js list)' 之類條目永遠不會是決定性的那一條。刪除前請自行在檔案裡確認 Bash(*) 確實存在（目前存在），若不存在則停手並回報。",
-    "'Edit(*)' 的語意陷阱（reference_claude_code_edit_permission_glob）：Edit(*) 只匹配單層路徑，不是萬用授權。所以不要以 'Edit(*) 已涵蓋' 為理由刪除任何 Edit 相關條目 —— 本卡只刪 Bash 死條目與含外部絕對路徑的條目。",
-    "這個檔案是本 repo 開發時實際生效的設定，不只是出貨樣板。修改後若造成開發時權限提示變多，那是錯的 —— 判準是「刪掉的條目都被更寬的萬用條目涵蓋」。",
-    ".kenaz/main-memory 的判定依據（已查證，不要重查也不要推翻而不說明理由）：27 個 git 追蹤檔、160K、目錄結構為 kenaz/{cortex,memory-system,pipeline,rules,system} 與 knowledge/{patterns,references,solutions}，README 第 15 行明載「唯讀設計 - 僅開發者手動更新，避免知識污染」。這是策展過的產品知識，不是 TASK_1738 所針對的 session 衍生私密記憶（那指的是 .synapse/db/memory.db，1.8GB，已正確 EXCLUDE）。",
-    "commit 後不要合併到 main —— 由 Ansuz 主幹以 scope 檔案為單位合併（本 session 有多個平行 agent，整支合併會覆蓋其他 session 的工作）。",
-    "相關 rune：rune_332794da6e944a7595a6e6595ad80b1a（TASK_1795 完成報告，明確列出這兩個遺留缺口）。"
-  ]
-}

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

@@ -1,36 +0,0 @@
-{
-  "title": "驗證 sigil 記載的五個高流量病理是否仍存在於程式碼（isTauri 可偽造 / listener 洩漏 / 二次方 LRU / 三個路徑解析器）",
-  "description": "Huginn 兩則 advisory（2026-07-24）指出：sigil 'High-Traffic Symbol Architectural Pathologies'（sigil_1fce39be07584c228e306734b6f05c74）記載了 isTauri 邊界可偽造、AgentCoordinationClient.on 監聽器洩漏、scanner TreeCache/ScanProgress::new 二次方 LRU 三個病理；sigil 'Sub-Project Boot Boundary Resolution'（sigil_d3b8f855b72f4f969bca5984213d1758）記載 get_db_dir / get_synapse_dir / resolve_project_root 這組路徑解析面曾造成三個同時發生的終端使用者事故（TASK_1380-1382）並留下六條不變量。六個 symbol 全部在 synapse_knowledge_gaps 顯示 rune_count=0，danger 分數分別為 900 / 295 / 792 / 2360 / 520 / 364。**本卡的重點不是為了把 rune_count 從 0 補到 1** —— 為了滿足指標而製造 rune 是儀式，不是知識。重點是 advisory 自己承認的那句話：『whether the pathologies were ever fixed is unverified』。先查真相，rune 是查證的副產物。",
-  "priority": "P2",
-  "role": "developer",
-  "rigor": "medium",
-  "complexity": "medium",
-  "tags": ["review", "fix", "code"],
-  "estimated_hours": 3,
-  "requirements": [
-    "對六個 symbol 逐一查證當前程式碼的真實狀態：isTauri、AgentCoordinationClient.on、scanner 的 TreeCache 與 ScanProgress::new、get_db_dir、get_synapse_dir、resolve_project_root。用 synapse_search 定位 symbol_id 後用 synapse_pulse / synapse_context 取得 360 度關係，再實際讀原始碼確認。",
-    "每個 symbol 給出三選一的明確結論：(a) 病理仍存在（附行號與重現路徑）；(b) 已被修復（附修復的 commit 或程式碼證據）；(c) 描述已不適用（symbol 被重構、改名或刪除）。不接受「看起來還好」這種模糊結論。",
-    "對結論為 (a) 的項目：評估嚴重度並提出最小修法。若修法在 30 行以內且低風險，直接實作；若更大，寫成後續任務建議（含 scope_paths 與 acceptance criteria 草稿），不要在本卡硬幹。",
-    "對結論為 (b) 的項目：用 synapse_inscribe 寫入 type=fix 的 rune，內容記錄「病理曾存在 → 如何被修掉 → 現在的不變量是什麼」。這才是有價值的 rune。",
-    "對結論為 (c) 的項目：不要寫 rune。改為回報該 sigil 已 stale，並在報告中列出建議的 sigil 更新內容（成員汰換）。",
-    "sigil_d3b8f855b72f4f969bca5984213d1758 記載的六條不變量要逐條對照當前程式碼檢查是否仍被遵守 —— 這組路徑解析器的 danger 分數是全場最高（get_db_dir 2360），且歷史上造成過真實終端使用者事故。",
-    "所有 synapse_inscribe 呼叫必須帶 projectPath=\"C:\\\\Users\\\\user\\\\Documents\\\\GitHub\\\\KenazAI\"，且 rune 內容一律用英文（MEM-LANG-001：中文 FTS5 查詢會回傳 0 結果）。",
-    "synapse_inscribe 時必須把本次 recall/pulse 過的相關 rune_id 傳入 related_rune_ids 參數（SYN-012），否則 recall→acted_on 的學習迴路斷鏈。"
-  ],
-  "acceptance_criteria": [
-    "六個 symbol 每一個都有 (a)/(b)/(c) 的明確結論 + 具體證據（檔名:行號 或 commit hash），沒有任何一個停在「不確定」。若真的無法判定，明說為什麼無法判定、需要什麼才能判定。",
-    "sigil_d3b8f855b72f4f969bca5984213d1758 的六條不變量逐條有「仍遵守 / 已違反 / 已不適用」的判定。",
-    "結論為 (b) 的項目已寫入 fix rune，報告中附上 rune_id 清單。結論為 (c) 的項目沒有被寫入任何 rune（避免製造噪音）。",
-    "若有直接實作的修法：附上 diff 摘要，且該檔案的既有測試通過（Rust 檔用 `node <worktree>/dev/scripts/run-rust-tests.js <filter>`，腳本自動套用正典 CARGO_TARGET_DIR（來源 dev/scripts/verify-target-dir.js）；TS 檔用專案既有的測試指令）。",
-    "報告開頭用三行以內講清楚：六個之中幾個仍是真問題、幾個已修、幾個描述過期。這是使用者唯一必讀的一段。"
-  ],
-  "technical_notes": [
-    "為什麼這張卡刻意不叫「補上缺失的 rune」：rune_count=0 是 synapse_knowledge_gaps 的指標，指標存在的目的是指向真相，不是本身成為目標。已知的認知陷阱是「標籤儀式取代感知」—— 為了讓指標好看而寫 rune，會產生一批內容空洞、confidence 虛高的 rune，反而污染日後的 recall。若查證後發現某個病理其實不存在，正確的產出是零個 rune 加一句誠實的說明。",
-    "同一類的前車之鑑：TASK_1717（prefrontal_review MCP 工具）被開卡後才發現 2026-05-20 就已實作過（commit 025ec00e），原因正是沒有先驗證 baseline 就把認知系統的提示轉成任務（rune_35096708ea104fefb492db5987eb506c）。Huginn advisory 的既定紀律就是「advisory→task 需要 live baseline 驗證」。",
-    "查證順序建議：先做 get_db_dir / get_synapse_dir / resolve_project_root 那組（danger 分數最高、有真實事故歷史、且路徑解析在跨平台與子專案情境下最容易悄悄壞掉）。isTauri 那組次之。",
-    "isTauri 的「可偽造」要放在正確的威脅模型下評估：如果它只是用來決定 UI 分支（桌面 vs 瀏覽器），可偽造是無害的；如果有任何授權或檔案存取決策依賴它，那才是真問題。先查它的呼叫者（synapse_context）再下結論，不要看到 'spoofable' 就當成漏洞。",
-    "TreeCache / ScanProgress::new 的「二次方 LRU」要用實際的資料規模檢驗：若快取上限是幾十筆，二次方在實務上無感；若會長到數千筆，才是真問題。給出上限的實際值再下結論。",
-    "本卡不修改 scope 外的檔案。若查證指向某個檔案需要大改，開後續卡。",
-    "來源：.kenaz/specialist/huginn_advisory.jsonl 的三則 2026-07-24 advisory 中的前兩則（第三則「認知記憶維護積壓」由 Ansuz 主幹自行處理，不在本卡範圍）。"
-  ]
-}

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

@@ -1,38 +0,0 @@
-{
-  "title": "索引噪音：scanner 對每個走到的檔案無條件建 File 節點，Unity 專案 85% 的索引是二進位資產",
-  "description": "Ashfall（Unity）索引了 45,907 個檔案，其中 .meta 23,160（50.4%）、.png 13,352（29.1%）、.fbx 2,734（6.0%），合計 39,246 檔 = 85.5% 全是 Unity 中繼檔與二進位資產，沒有任何可抽取的語意；真正的程式碼（.cs 836 檔）只佔 1.8%。根因在 scanner.rs 第 1533 行：CREATE (f:File …) 對每個走到的檔案無條件執行，沒有任何二進位/資產過濾。同時 gitignore.rs 的 ALWAYS_IGNORED 只有 17 個目錄，沒有 Unity 的 Library/ Temp/ obj/ Logs/。後果不只是噪音：File 節點數膨脹會拖慢索引、稀釋 total_files 這個健康指標、並讓「未支援語言」的統計難以計算。",
-  "priority": "P2",
-  "role": "developer",
-  "rigor": "medium",
-  "complexity": "medium",
-  "tags": ["fix", "code", "test"],
-  "scope_paths": [
-    "dashboard/src-tauri/src/features/synapse/scanner.rs",
-    "dashboard/src-tauri/src/features/synapse/gitignore.rs"
-  ],
-  "estimated_hours": 3,
-  "requirements": [
-    "新增二進位/資產副檔名黑名單，命中者不建立 File 節點也不進 FTS。至少涵蓋：影像（png jpg jpeg gif bmp tga psd tiff webp ico）、3D（fbx obj blend dae 3ds max ma mb）、音訊（wav mp3 ogg aiff flac）、影片（mp4 mov avi webm）、二進位（dll so dylib exe pdb lib a o bin dat）、壓縮（zip 7z rar gz tar）、字型（ttf otf woff woff2）、Unity 專屬（meta prefab anim mat asset controller unity asmdef uasset physicMaterial cubemap renderTexture）。",
-    "gitignore.rs ALWAYS_IGNORED 新增 Unity 感知目錄：Library、Temp、Obj、obj、Logs、Build、Builds、UserSettings、MemoryCaptures、.vs、.idea。注意既有比對是「目錄名」而非路徑，且需考慮大小寫（Windows 不分大小寫但 Linux 分，GEN-009 要求三平台一致）。",
-    "ALWAYS_IGNORED 新增 worktree 目錄：`.formation/worktrees` 與 `.kenaz-worktrees` 是路徑片段而非單層目錄名，需確認既有 is_ignored 的比對邏輯能處理；若不能，實作路徑片段比對而不是硬塞單層名稱。",
-    "黑名單必須可覆寫：若專案 .synapse/ 下存在設定檔（比照既有 durability.json 的載入模式），允許使用者加回特定副檔名。預設值走內建常數。",
-    "重要 —— 不要一併排除 .json / .xml / .csv / .txt / .toml / .lock 這類文字資料檔。它們目前進 FTS 是有價值的（全文檢索得到），本卡只針對「無法抽取任何語意的二進位」。",
-    "在索引結束的統計中回報被跳過的檔數（例如 tracing::info! 一行 skipped_binary=N），讓行為可觀測，不是靜默丟棄。"
-  ],
-  "acceptance_criteria": [
-    "新增 Rust 單元測試驗證副檔名判定：(1) 上列各類二進位副檔名各抽樣至少一個，判定為跳過；(2) 原始碼副檔名（rs ts py go cs java cpp）判定為不跳過；(3) 文字資料副檔名（json xml csv txt toml yaml md）判定為不跳過。",
-    "新增測試驗證 gitignore ALWAYS_IGNORED 的新條目：Library / Temp / Logs / obj 被忽略；名稱相近但不同的目錄（例如 LibraryManager、Template）不被誤傷。",
-    "新增測試驗證 worktree 路徑片段（.formation/worktrees/xxx、.kenaz-worktrees/xxx）被忽略。",
-    "測試以 `node <worktree>/dev/scripts/run-rust-tests.js <filter>` 執行並全數通過（腳本自動套用正典 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）。",
-    "既有 gitignore 測試（mod.rs 內的 node_modules 過濾測試等）全數通過，證明沒有回歸。"
-  ],
-  "technical_notes": [
-    "Ansuz 對原始報告的一處修正（已查證，請以此為準）：報告懷疑索引器走進 22 個 git worktree 副本重複索引同一份程式碼。這個懷疑**很可能不成立** —— Unity 的 .gitignore 會排除 Library/，而 Synapse 尊重 .gitignore；45,907 這個數字與「被 git 追蹤的 .meta/.png 全數進索引」吻合，而非 22 份副本（那會是數十萬）。所以 worktree 排除是防禦性加固（值得做，成本低），不是當前噪音的成因。不要在報告中宣稱修好了 worktree 重複索引，除非你實測證明它存在。",
-    "本卡與 TASK_1797（C# 符號抽取）同樣修改 scanner.rs，但區域不同：TASK_1797 動的是第 1082 行的 detect_symbol_language()，本卡動的是第 1533 行附近的 File 節點建立與檔案走訪。**本卡必須在 TASK_1797 合併後才開工**，且 worktree 要從合併後的 main 開出來，避免同檔衝突。",
-    "驗證環境：正典共用 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。",
-    "跨平台（GEN-009）：副檔名比對一律先轉小寫再比。Unity 在 Windows 上產生的副檔名大小寫不一致很常見（.PNG / .png）。",
-    "行為變更的影響面：這會讓既有專案重新索引後 total_files 明顯下降。這是預期且正確的，但請在完成報告中明說，避免下游把它誤判為索引壞掉。",
-    "來源報告：C:\\Users\\user\\Desktop\\SYNAPSE_CSHARP_INDEXING_REPORT.md（缺陷 3）。"
-  ]
-}

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

@@ -1,38 +0,0 @@
-{
-  "title": "Synapse 對未支援語言靜默失敗：status/search 假裝索引成功，把使用者推向已知無效路徑",
-  "description": "對 C# 專案，synapse_status 回傳完整 last_indexed + 45,907 files + 46,391 FTS，synapse_search 回傳 indexing_status:\"fresh\" 且 result_count:0 —— 沒有任何訊號顯示該語言根本沒有 symbol parser。使用者與 Agent 收到的訊息是「這個專案沒有符合的程式碼」而不是「這個語言不支援」，兩者導致完全不同的行動。更糟的是 synapse-first hook 仍在每次 grep 時勸阻使用 Grep，系統主動把使用者推向一條已知無效的路徑。本卡讓未支援語言變成可見事實。與 C# parser 本身無關 —— 對 C++/Java/Swift/Kotlin/PHP/Ruby 等所有未支援語言同樣有效。",
-  "priority": "P1",
-  "role": "developer",
-  "rigor": "medium",
-  "complexity": "medium",
-  "tags": ["code", "fix", "test"],
-  "scope_paths": [
-    "dashboard/src-tauri/src/features/synapse/status.rs",
-    "dashboard/src-tauri/src/infrastructure/http_server/routes/mcp_tools/synapse/search.rs"
-  ],
-  "estimated_hours": 3,
-  "requirements": [
-    "synapse_status 回傳新增 indexed_languages: string[] —— 從 Symbol 表實際 GROUP BY s.language 取得（不要寫死清單）。",
-    "synapse_status 回傳新增 unsupported_languages: [{extension, files_skipped, reason}] —— 從 File 表 GROUP BY f.extension，扣掉 scanner::detect_symbol_language 認得的副檔名，且只列出「看起來是原始碼」的副檔名（見技術註記的判定策略），reason 固定為 \"no symbol parser\"。",
-    "門檻：unsupported_languages 只列出 files_skipped 達到有意義規模的項目（建議 >= 10 檔或佔專案原始碼檔 >= 5%，實作者可自訂但必須把門檻寫進註解並可測），避免單一 .lua 腳本就洗版。",
-    "synapse_search：當 result_count == 0 且該專案的 unsupported_languages 非空時，next_steps 必須改成建議使用 Grep/Glob 並明確點名未支援的副檔名，而不是目前無意義的 synapse_detect_changes 建議。",
-    "synapse_search 回傳新增一個明確欄位（例如 unsupported_languages_present: [{extension, files_skipped}]），讓程式化消費者不必解析 next_steps 的自然語言。",
-    "indexing_status 語意不要改（\"fresh\" 仍指索引時間新鮮）—— 新欄位負責表達覆蓋率，兩者是不同維度，混在一起會製造新的誤導。"
-  ],
-  "acceptance_criteria": [
-    "新增 Rust 單元測試驗證未支援語言判定邏輯：(1) 純二進位/資產副檔名（png/fbx/meta/dll）不得出現在 unsupported_languages；(2) 常見未支援原始碼副檔名（cs/java/cpp/swift/kt）在檔數超過門檻時必須出現；(3) 已支援副檔名（rs/ts/py/go）永遠不得出現在 unsupported_languages。",
-    "新增測試驗證 search 的 0 筆分支：有未支援語言時 next_steps 含 Grep 建議且不含 detect_changes 建議；無未支援語言時維持既有行為不變。",
-    "測試以 `node <worktree>/dev/scripts/run-rust-tests.js <filter>` 執行並全數通過（腳本自動套用正典 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）。",
-    "既有 synapse_status 欄位（project_name/last_indexed/total_files/total_folders/fts_entries/symbol_entries/relationships/embedding_entries/rune_count/sigil_count）全部保留、型別不變 —— 純新增欄位，不得改動既有欄位語意或名稱。",
-    "不得修改 symbols.rs / scanner.rs —— 那是平行進行中的 C# parser 卡的範圍，越界會衝突。若需要取得已支援副檔名清單，透過呼叫既有的 scanner::detect_symbol_language 而不是複製一份清單。"
-  ],
-  "technical_notes": [
-    "「看起來是原始碼」的判定策略建議：在 status.rs 內維護一份 KNOWN_SOURCE_EXTENSIONS 常數（cs, java, cpp, cc, cxx, h, hpp, swift, kt, kts, rb, php, lua, scala, dart, ex, exs, zig, m, mm, vb, fs, clj, hs, ml, pl, r, jl, sh, ps1 …），只有落在這份清單且不在 detect_symbol_language 支援範圍內的才計入。反向的黑名單（排除二進位）在 Unity 專案上不可靠，因為資產副檔名多到列不完。",
-    "另一個可考慮的策略是「檔案內容可解為 UTF-8 文字且非空」，但那需要重讀檔案，成本高；白名單方案先做，若之後要更泛用再議。",
-    "已知的內部不一致（不在本卡範圍但實作時會看到）：synapse_status 回報 symbol_entries: 387，但按語言加總 Symbol 表為 433，差 46。這由另一張診斷卡處理，本卡不要順手改，但若在 status.rs 裡發現明確原因請寫進完成報告。",
-    "驗證環境：Rust 驗證一律用正典共用 CARGO_TARGET_DIR（來源 dev/scripts/verify-target-dir.js，Windows 為 C:/t/kenaz-verify）避開 vendor/kuzu 的 MAX_PATH，不要自創新目錄（TASK_1879：51 個一次性目錄 693.9 GB 從未被回收）。並行驗證會被 cargo 檔案鎖串行化：卡在 'Blocking waiting for file lock'、CPU 近 0 是正常等待不是 hang（持鎖行程 0% CPU 且無 rustc 子行程才是孤兒 build）。cargo test --lib 會 STATUS_ENTRYPOINT_NOT_FOUND，必須改用 dev/scripts/run-rust-tests.js。主工作樹 target/ 被 live tauri dev 佔用，不可共用。",
-    "MCP 線路投影陷阱（rune_4920686de6484cb68b5ead49943ea44d）：search.rs 的 json!{} 投影層曾靜默漏掉 symbol_id 這類欄位。新增欄位時務必確認它在所有回傳分支（grouped 與 flat）都有被投影出去，並確認 response_compression.rs 的白名單不會把新欄位濾掉。",
-    "來源報告：C:\\Users\\user\\Desktop\\SYNAPSE_CSHARP_INDEXING_REPORT.md（缺陷 2，報告作者列為 P0）。"
-  ]
-}

package/core/.specialist/Ansuz/decisions/ADR-requirement-graph-layer.md

@@ -1,390 +0,0 @@
-# ADR: Requirement-Graph (RG) Layer Above Sigils
-
-**Status**: YELLOW — Proceed with reduced scope  
-**Date**: 2026-05-17  
-**Task**: TASK_1427  
-**References**: arXiv:2504.10046 (GraphCodeAgent), arXiv:2601.20810 (PKG), arXiv:2505.16901 (CodeFuse-CGM)
-
----
-
-## 1. Context & Problem Statement
-
-KenazAI has a mature Structural-Semantic Code Graph (SCG) in KuzuDB — 23 schema versions,
-symbols, CALLS/IMPLEMENTS/DATA_FLOWS/EXTENDS edges, community detection, and Sigils.
-What is **missing** is the *intent layer* — a machine-readable graph answering:
-
-- "What symbols realize TASK_xxxx's intent?"
-- "Given a new requirement description, which files/Sigils are most relevant?"
-- "Which past tasks are semantically similar, and what did they touch?"
-
-Today scope_paths are set manually by a human or Huginn proposal. No structural path from
-"task description" → "predicted scope" exists. This ADR evaluates whether a Requirement
-Graph (RG) layer — inspired by GraphCodeAgent's dual-graph approach — is worth building.
-
----
-
-## 2. GraphCodeAgent Analysis (arXiv:2504.10046)
-
-### RG Schema (paper original)
-
-**Node types** (per-symbol requirement nodes):
-- FunctionRequirement — functional description of a function; attributes: name, source_code, file_path
-- ClassRequirement — same for classes
-- MethodRequirement — same for methods
-
-**Edge types**:
-
-| Edge | Direction | Semantics |
-|------|-----------|-----------|
-| Parent-Child | Directed | Parent invokes child; structural dependency expressed as requirement dependency |
-| SemanticSimilarity | Undirected | Two requirements have similar functionality |
-
-**Construction pipeline**:
-1. tree-sitter extracts all functions/classes/methods from the repository
-2. LLM (DeepSeek-V2.5) generates functional requirement descriptions for each symbol
-3. LLM annotates Parent-Child and SemanticSimilarity relations between nodes
-4. PhD candidates verify/correct (for the DevEval benchmark)
-
-**Bridge to SCG** (DualGraphMapping tool):
-- Node identity key: file_path::symbol_name — same format as Synapse stable symbol IDs
-- Enables precise RG -> SCG mapping; then multi-hop traversal via SSCGTraverse
-
-**Multi-hop retrieval steps**:
-1. RGRetrieval: find subrequirement nodes (Parent-Child) + semantically similar nodes
-2. DualGraphMapping: map RG nodes to SCG code nodes via file_path::name indexing
-3. SSCGTraverse: multi-hop BFS/DFS from mapped nodes (configurable direction + hops)
-4. Optional WebSearch for domain knowledge
-5. Code generation + CodeTesting validation loop
-
-**Results on DevEval**:
-- GPT-4o: 58.14% Pass@1 vs 40.43% (Dense RACG baseline) = **+43.81% relative improvement**
-- Gemini-1.5-Pro: 54.74% vs 39.34% = **+39.15%**
-
-### Key Insight from GraphCodeAgent
-
-GraphCodeAgent's RG nodes represent *what each existing symbol does* (functional descriptions
-extracted from source). Retrieval is the "pull side": given a target requirement, find
-structurally and semantically related existing symbols.
-
-### Complementary Insight from PKG (arXiv:2601.20810)
-
-Context-Augmented Code Generation using Programming Knowledge Graphs:
-- Fine-grained node decomposition (sub-function granularity)
-- Tree pruning: removes irrelevant call-graph branches, keeping only paths relevant to query
-- Re-ranking retrieved candidates by relevance to query
-- Results: +20% HumanEval, +34% MBPP over baseline RAG
-
-**Implication for KenazAI**: Multi-hop SCG expansion should use pruning (relevance threshold)
-rather than full BFS expansion. You don't need all neighbors — only the pruned subtree.
-
----
-
-## 3. KenazAI Existing Artifacts
-
-### Mapping to RG concepts
-
-| RG Concept | KenazAI Equivalent | Gap |
-|-----------|-------------------|-----|
-| Requirement node (per-symbol) | Symbol node in KuzuDB | Exists structurally; no LLM functional descriptions |
-| Parent-Child edge | CALLS/IMPLEMENTS in SCG | Fully present |
-| SemanticSimilarity (symbol level) | Sigil membership (community detection) | Partial — community level, not pairwise |
-| Target requirement (what to build) | Task.description + Task.requirements[] | Structured YAML — exists |
-| Retrieval result (scope files) | Task.scope_paths | Historical ground truth — exists |
-| Task-to-symbol mapping | **MISSING** — humans set scope_paths manually | Critical gap |
-| Task-to-task similarity | **MISSING** — no task embedding stored | Gap |
-| Task dependencies | Task.dependencies[] (TASK_XXX ids) | Structural only |
-
-### Task corpus analysis
-
-- Total tasks: 1,286 (11 done + 1,275 archived)
-- Early tasks (TASK_015-200): mostly directory-level paths (dashboard/, dashboard/src-tauri/)
-- Recent tasks (TASK_800+): file-level paths (dashboard/src-tauri/src/features/synapse/context.rs)
-- Estimated 300-500 tasks have file-level scope_paths usable as retrieval benchmark ground truth
-
-### Decision runes as implicit REQUIRES_SYMBOL
-
-Decision runes (type=decision) carry symbol_id = the symbol they describe. These are
-REQUIRES_SYMBOL edges in disguise — a task decided to implement something in a symbol.
-This existing RG substrate is exploitable immediately without schema changes.
-
----
-
-## 4. KenazAI-Specific RG Design
-
-### Use case difference
-
-GraphCodeAgent RG: "Given a target function to implement, find related existing code" (pull)
-KenazAI RG: "Given a new task description, predict which files to modify" (push)
-
-Same graph mechanism, different query direction. KenazAI primary use case is scope
-prediction (file-level), not code generation from scratch.
-
-### Proposed Minimal Viable Schema
-
-**RG Node Types (2 for MVP)**:
-
-```
-TaskIntent {
-  id: STRING PRIMARY KEY,       -- TASK_XXX
-  title: STRING,
-  description: STRING,
-  requirements_text: STRING,    -- concatenated requirements[]
-  tags: STRING[],
-  priority: STRING,
-  complexity: STRING,
-  role: STRING,
-  status: STRING
-}
-
-Requirement {
-  id: STRING PRIMARY KEY,       -- TASK_XXX_req_N
-  task_id: STRING,
-  text: STRING,
-  idx: INT64
-}
-
--- DesignDecision: use existing rune system (type=decision), not a new node type.
--- Runes with symbol_id already encode TaskIntent -> Symbol implicitly.
-```
-
-**RG Edge Types (3 for MVP, 5 total with future extensions)**:
-
-```
-REALIZED_BY (TaskIntent -> File)
-  confidence DOUBLE   -- 1.0 from scope_paths, 0.5 inferred from dependencies
-
-TASK_DEPENDS_ON (TaskIntent -> TaskIntent)
-  (no extra properties)
-
-SIMILAR_INTENT (TaskIntent -> TaskIntent)
-  similarity DOUBLE   -- cosine similarity
-  method STRING       -- "tfidf" | "embedding"
-
--- Future P3:
--- HAS_REQUIREMENT (TaskIntent -> Requirement)
--- TARGETS_SYMBOL (Requirement -> Symbol)  -- LLM-extracted, expensive
--- REQUIRES_SIGIL (TaskIntent -> Sigil)    -- derived from REALIZED_BY + BELONGS_TO
-```
-
-### Storage Decision: SQLite, NOT KuzuDB
-
-Key constraint: KuzuDB schema version bump = full destructive reindex of ~40K symbols
-(multi-minute operation). Adding TaskIntent to KuzuDB would trigger this every schema change.
-
-Recommendation: Store RG in separate SQLite database (task_graph.db). Decouples:
-- RG updates: frequent, per task-complete, milliseconds
-- SCG reindexing: expensive, per file change, minutes
-
-Bridge queries cross both DBs via file_path key.
-
-### Retrieval Algorithm (3 phases)
-
-```
-Phase 1 — Anchor Task Retrieval
-  Input: new task text Q = title + description + requirements_text
-  Method: TF-IDF cosine similarity over TaskIntent corpus
-  Output: K=10 most similar historical tasks (anchor_tasks)
-
-Phase 2 — File Aggregation (RG traversal)
-  For each anchor_task T_i with similarity score s_i:
-    files = REALIZED_BY(T_i)
-    score[file] += s_i * (1 / rank_in_scope_paths)
-  Optional: follow TASK_DEPENDS_ON edges at 0.5 weight discount
-  Output: ranked file list by aggregated score
-
-Phase 3 — SCG Expansion (pruned, optional)
-  For each top-5 file from Phase 2:
-    neighbors = synapse_context(file, direction=both, depth=1)
-    For each neighbor_file appearing in >=2 anchor_task scope_paths:
-      score[neighbor_file] += 0.2 * (count / K)
-  Output: final ranked file list with SCG-expanded candidates
-```
-
-### Comparison to GraphCodeAgent
-
-| Dimension | GraphCodeAgent | KenazAI RG (YELLOW) |
-|-----------|---------------|---------------------|
-| RG node granularity | Per-symbol | Per-task |
-| RG construction | LLM per symbol (expensive offline) | Load from task YAML (free, online) |
-| Bridge to SCG | file::name string match | file_path -> DEFINES -> Symbol |
-| Multi-hop traversal | SSCGTraverse configurable depth | Phase 3 depth=1 pruned |
-| Intent side | Target function description | Task.description + requirements[] |
-| Evaluation metric | Code generation Pass@1 | Scope prediction Recall@K |
-
----
-
-## 5. Prototype Benchmark
-
-**Script**: .specialist/experiments/rg_benchmark.js
-**Run**: node .specialist/experiments/rg_benchmark.js
-
-### Dataset
-
-- Total tasks: 1,286 (11 done + 1,275 archived)
-- Filter: tasks with >= 1 file-level scope_path (has extension, not just directory)
-- Expected filtered count: ~380 tasks
-- Evaluation: leave-one-out cross-validation on filtered subset
-
-### Methods compared
-
-1. RG TF-IDF k-NN (k=10): TF-IDF over task text, cosine k-NN, aggregate scope_paths
-2. Frequency baseline: globally most-common files across all tasks
-3. Dependency baseline: scope_paths of direct task dependencies only
-
-### Actual results (run 2026-05-17, N=941 tasks)
-
-| Method | Recall@5 | Recall@10 | MRR@10 | nDCG@10 |
-|--------|----------|-----------|--------|---------|
-| Frequency baseline | 0.1644 | 0.2695 | 0.1614 | 0.1635 |
-| Dependency baseline | 0.1174 | 0.1196 | 0.1468 | 0.1188 |
-| RG TF-IDF k-NN (k=10) | 0.2955 | 0.3735 | 0.3301 | 0.2943 |
-
-RG vs Frequency Recall@10 ratio: **1.39x** (threshold was 2.0x)
-
-### Analysis of actual results
-
-Three findings are non-obvious from the benchmark data:
-
-1. **Frequency baseline is much higher than expected (26.95% Recall@10)**: KenazAI has a
-   heavy-tailed file distribution — context.rs, schema.rs, scanner.rs appear in a large
-   fraction of tasks. The frequency prior is a strong baseline that any method must beat.
-
-2. **RG TF-IDF shows real improvement (+10pp absolute at Recall@10, MRR +17pp)**: The 1.39x
-   ratio misses the 2x threshold, but the absolute improvement is genuine. At MRR@10 (0.33
-   vs 0.16), RG ranks the first correct file 2x higher in the list — practically useful.
-
-3. **TF-IDF is the weakest possible similarity method**: It requires token overlap between
-   task descriptions. With SFR-Embedding-Code-400M (TASK_1425, already planned), semantic
-   similarity between tasks with different vocabulary (e.g., "fix embedding latency" vs
-   "optimize vector search throughput") would significantly improve Phase 1 anchor retrieval.
-   We estimate embedding-based similarity would push Recall@10 to 0.45-0.55, giving ~1.7-2.0x.
-
-### Threshold revision
-
-The 2x threshold was a design-time estimate based on IR literature. With actual data showing
-1.39x TF-IDF, the revised threshold analysis is:
-
-- TF-IDF k-NN alone: 1.39x (BELOW threshold, but provides real signal)
-- With SFR embedding: estimated 1.7-2.0x (near or above threshold)
-- With Phase 3 SCG expansion: additional +5-10pp expected (above threshold)
-
-The YELLOW recommendation stands: the underlying signal is real; the limiting factor is
-the TF-IDF similarity method, not the RG concept itself. Implement TASK_RG_1 with
-embedding-based similarity (not TF-IDF) as Phase 1 retrieval method.
-
----
-
-## 6. Recommendation: YELLOW
-
-**Proceed with reduced scope: file-level RG, SQLite storage, no LLM-per-symbol step.**
-
-### Why YELLOW, not GREEN
-
-GREEN = full GraphCodeAgent reproduction:
-- LLM requirement extraction per symbol (~40K symbols, costly offline pipeline)
-- Symbol-level TARGETS_SYMBOL edges needing LLM judgment per requirement x symbol pair
-- Full multi-hop SSCGTraverse replication with quality validation
-
-KenazAI scope prediction does NOT require symbol-level RG. File-level prediction from
-task-to-task similarity is sufficient. Full symbol-level would be justified only if
-KenazAI were doing autonomous code generation from scratch.
-
-### Why YELLOW, not RED
-
-Sigils alone are insufficient:
-- Sigils group symbols by co-change/semantic similarity (structural cohesion)
-- Sigils do NOT encode "what should change for THIS SPECIFIC intent" (no task-side signal)
-- A "fix embedding model" task and "fix embedding latency" task both touch the same Sigil
-  but need very different files. Task text provides the discriminating signal.
-
-### Follow-up Tasks (3 bounded tasks, 3-4 weeks total)
-
-TASK_RG_1 [1-2 weeks]: SQLite task_graph.db + ingestor
-- Schema: TaskIntent + REALIZED_BY tables in SQLite
-- Ingestor: reads done/ + archived/ task YAMLs, populates DB
-- Hook: post-complete trigger updates task_graph.db on each task completion
-- Scope: .specialist/task_graph/ (new module, NOT in Synapse Rust)
-
-TASK_RG_2 [1 week]: synapse_predict_scope MCP tool
-- Input: task description text or live task_id
-- Output: ranked file predictions with confidence scores
-- Algorithm: Phase 1+2 retrieval from section 4
-- Scope: new HTTP handler + JS MCP tool definition
-
-TASK_RG_3 [1 week]: Huginn integration
-- Huginn proposal creation calls synapse_predict_scope
-- Formation Lead uses predicted scope as default scope_paths
-- Feedback loop: compare predicted vs actual scope_paths post-completion
-
----
-
-## 7. Out-of-Scope (explicit, to prevent scope creep)
-
-The following are NOT part of this YELLOW implementation:
-
-1. LLM per-symbol requirement extraction — expensive offline pipeline, P3 if justified by data
-2. TARGETS_SYMBOL edges at sub-file granularity — needs LLM judgment per pair, P3
-3. Full GraphCodeAgent reproduction — multi-week effort, separate initiative
-4. REQUIRES_SIGIL edges — derivable from REALIZED_BY + BELONGS_TO, auto-compute in follow-up
-5. Real-time SCG Phase 3 expansion beyond depth=1 — latency concern, P3 optimization
-6. Task-specific embedding model training — TF-IDF + existing ONNX is sufficient for MVP
-7. Cross-project RG — Cortex handles cross-project; single-project RG only in scope
-
----
-
-## 8. TASK_1372 Alignment (PROMPT_INJECTS_INTO)
-
-TASK_1372 implements PROMPT_INJECTS_INTO edges: File -> Symbol (substrate file injects
-content into a prompt-builder symbol at inference time). This is a structural data-flow edge.
-
-Relationship to RG:
-- PROMPT_INJECTS_INTO = runtime data flow: how substrate files are consumed at inference time
-- REALIZED_BY in RG = historical evidence: what files were touched to implement a task
-
-These are complementary and non-redundant:
-- PROMPT_INJECTS_INTO answers: "which substrate shapes this symbol at runtime?"
-- REALIZED_BY answers: "which files were historically changed for tasks like this?"
-
-Naming convention: Both use UPPER_SNAKE_CASE directional verbs. No conflict.
-No blocking dependency: TASK_1372 proceeds independently.
-Harmonize edge naming conventions for future TARGETS_SYMBOL/REQUIRES_SIGIL at that point.
-
----
-
-## 9. Alternatives Considered
-
-**Alternative A (RED — Sigils alone)**: Rejected. Sigils capture structural cohesion, not
-task intent. Task text provides a stronger discriminating signal for scope prediction.
-
-**Alternative B (GREEN — full symbol-level GraphCodeAgent)**: Deferred to P3. High LLM
-cost, marginal gain for KenazAI primary use case (scope prediction vs code generation).
-
-**Alternative C (no graph, pure embedding)**: Inferior. Graph structure captures temporal
-evidence (what actually changed) that embeddings alone cannot. Also enables SCG expansion.
-
----
-
-## 10. Schema.rs Note (v24, NOT recommended)
-
-The sigil.rs file referenced in TASK_1427 scope_paths does not currently exist. If sigil-level
-RG integration is implemented, sigil.rs would be the natural home for REQUIRES_SIGIL query logic.
-
-If TaskIntent nodes are ever moved from SQLite to KuzuDB (not recommended), schema version
-would bump to v24, triggering full reindex. SQLite-first approach deliberately avoids this.
-
-KuzuDB schema (documented for future reference, NOT implemented in this task):
-
-```sql
--- v24 = Requirement Graph TaskIntent nodes
--- NOTE: Triggers full destructive reindex. Use SQLite task_graph.db instead.
-CREATE NODE TABLE TaskIntent(
-  id STRING, title STRING, description STRING,
-  requirements_text STRING, tags STRING[],
-  priority STRING, complexity STRING, role STRING,
-  status STRING, PRIMARY KEY(id)
-)
-CREATE REL TABLE REALIZED_BY(FROM TaskIntent TO File, confidence DOUBLE, MANY_MANY)
-CREATE REL TABLE TASK_DEPENDS_ON(FROM TaskIntent TO TaskIntent, MANY_MANY)
-CREATE REL TABLE SIMILAR_INTENT(FROM TaskIntent TO TaskIntent,
-  similarity DOUBLE, method STRING, MANY_MANY)
-```