kenaz 0.0.0-stage → 0.3.2

package/core/.kenaz/specialist/verify_1838.js

@@ -0,0 +1,124 @@
+'use strict';
+/**
+ * TASK_1838 verification — rerunnable.
+ * Prereq: .formation/tools/dispatch-registry.old.js = pre-fix version
+ *   (git show <pre-fix>:.formation/tools/dispatch-registry.js > .formation/tools/dispatch-registry.old.js)
+ *
+ * Arms:
+ *  A (control / bug repro): OLD cleaner against writer-produced locks — must clear NOTHING
+ *    real (only the ROOT-coincidence lock), proving the pre-fix formula never matched.
+ *  B (fix): NEW cleaner, called as headless does for a core dispatch — stale locks cleared,
+ *    non-stale locks (30min pid:null serial lock, fresh live-pid lock, fresh merge-lock) SURVIVE.
+ *  C (fix, cross-project caller): NEW cleaner called with a foreign projectRoot — still finds
+ *    locks in core ROOT/.formation (writer's directory).
+ *  D: merge-lock semantics unchanged — stale (>10min) merge-lock cleared by BOTH arms.
+ */
+const fs = require('fs');
+const path = require('path');
+const { spawnSync } = require('child_process');
+
+const TOOLS = path.join(__dirname, '..', '..', '.formation', 'tools');
+const { ROOT, dispatchLockPath } = require(path.join(TOOLS, 'utils'));
+const newReg = require(path.join(TOOLS, 'dispatch-registry'));
+
+// Control arm: auto-extract the pre-fix cleaner from git (parent of the fix commit).
+const OLD_FILE = path.join(TOOLS, 'dispatch-registry.old.js');
+const FIX_COMMIT = 'd98832e9'; // [TASK_1838] task completed
+if (!fs.existsSync(OLD_FILE)) {
+  const out = spawnSync('git', ['show', `${FIX_COMMIT}~1:.formation/tools/dispatch-registry.js`],
+    { cwd: ROOT, encoding: 'utf8' });
+  if (out.status !== 0) { console.error('Cannot extract pre-fix dispatch-registry.js:', out.stderr); process.exit(2); }
+  fs.writeFileSync(OLD_FILE, out.stdout);
+}
+const oldReg = require(OLD_FILE);
+process.on('exit', () => { try { fs.unlinkSync(OLD_FILE); } catch { /* keep tree clean */ } });
+
+const FORM = path.join(ROOT, '.formation');
+const MERGE_LOCK = path.join(FORM, '.merge-lock');
+const FAKE_REPO = 'D:\\Fake\\OtherRepo'; // cross-project target (never exists)
+
+let pass = 0, fail = 0;
+function check(label, cond) {
+  if (cond) { pass++; console.log(`  ✅ ${label}`); }
+  else { fail++; console.log(`  ❌ ${label}`); }
+}
+
+function writeLock(file, { pid, ageMin, field = 'startedAt' }) {
+  fs.writeFileSync(file, JSON.stringify({
+    taskId: 'T_1838_TEST', pid,
+    [field]: new Date(Date.now() - ageMin * 60000).toISOString(),
+  }));
+}
+function sweep() {
+  for (const n of fs.readdirSync(FORM)) {
+    if (n.startsWith('.dispatch-lock-') || n === '.merge-lock') fs.unlinkSync(path.join(FORM, n));
+  }
+}
+function deadPid() {
+  const r = spawnSync(process.execPath, ['-e', '']);
+  return r.pid; // process has exited => dead pid
+}
+
+// Guard: refuse to run over real locks
+const preexisting = fs.readdirSync(FORM).filter(n => n.startsWith('.dispatch-lock-') || n === '.merge-lock');
+if (preexisting.length) { console.error('Real locks present, aborting:', preexisting); process.exit(2); }
+
+const L_default = dispatchLockPath(null);            // core dispatch (projectPath=null)
+const L_cross   = dispatchLockPath(FAKE_REPO);       // cross-project dispatch
+const L_serial  = dispatchLockPath('C:\\fake-serial');   // live TASK_1833 serial lock (pid:null, 30min)
+const L_livepid = dispatchLockPath('C:\\fake-livepid');  // fresh live-pid lock
+const L_deadpid = dispatchLockPath('C:\\fake-deadpid');  // fresh dead-pid lock
+const L_rootkey = dispatchLockPath(ROOT);            // the ONE coincidence case the old formula matched
+
+function makeFixtures() {
+  sweep();
+  writeLock(L_default, { pid: null, ageMin: 120 });          // stale — should be cleared
+  writeLock(L_cross,   { pid: null, ageMin: 120 });          // stale — should be cleared
+  writeLock(L_serial,  { pid: null, ageMin: 30 });           // NOT stale (<60min) — must survive
+  writeLock(L_livepid, { pid: process.pid, ageMin: 5 });     // alive + fresh — must survive
+  writeLock(L_deadpid, { pid: deadPid(), ageMin: 1 });       // dead pid — should be cleared
+  writeLock(L_rootkey, { pid: null, ageMin: 120 });          // stale, ROOT-coincidence key
+  writeLock(MERGE_LOCK, { pid: process.pid, ageMin: 1, field: 'acquiredAt' }); // fresh — must survive
+}
+
+console.log('\n══ Arm A: PRE-FIX cleaner (control / bug reproduction) ══');
+makeFixtures();
+oldReg.cleanupStaleLocks(null); // headless core dispatch: cleanupStaleLocks(projectPath || ROOT) → root=ROOT
+check('A1 stale .dispatch-lock-default SURVIVES old cleaner (bug reproduced)', fs.existsSync(L_default));
+check('A2 stale cross-project lock SURVIVES old cleaner (bug reproduced)', fs.existsSync(L_cross));
+check('A3 old cleaner DID clear the ROOT-coincidence lock (control validity: old code runs)', !fs.existsSync(L_rootkey));
+check('A4 fresh merge-lock survives old cleaner', fs.existsSync(MERGE_LOCK));
+
+console.log('\n══ Arm B: POST-FIX cleaner, core dispatch caller ══');
+makeFixtures();
+newReg.cleanupStaleLocks(null);
+check('B1 stale .dispatch-lock-default CLEARED', !fs.existsSync(L_default));
+check('B2 stale cross-project lock CLEARED', !fs.existsSync(L_cross));
+check('B3 stale ROOT-key lock CLEARED', !fs.existsSync(L_rootkey));
+check('B4 dead-pid lock CLEARED', !fs.existsSync(L_deadpid));
+check('B5 30min pid:null serial lock SURVIVES (60min authority, not 10min)', fs.existsSync(L_serial));
+check('B6 fresh live-pid lock SURVIVES', fs.existsSync(L_livepid));
+check('B7 fresh merge-lock SURVIVES', fs.existsSync(MERGE_LOCK));
+
+console.log('\n══ Arm C: POST-FIX cleaner, cross-project caller (projectRoot=foreign repo) ══');
+makeFixtures();
+newReg.cleanupStaleLocks(FAKE_REPO); // headless sub-project dispatch passes the target path
+check('C1 stale core lock cleared even when caller targets another repo', !fs.existsSync(L_default));
+check('C2 stale cross-project lock cleared', !fs.existsSync(L_cross));
+check('C3 live serial lock still survives', fs.existsSync(L_serial));
+
+console.log('\n══ Arm D: merge-lock semantics unchanged (both arms clear a stale one) ══');
+sweep();
+writeLock(MERGE_LOCK, { pid: null, ageMin: 20, field: 'acquiredAt' }); // >10min, no pid
+oldReg.cleanupStaleLocks(null);
+check('D1 old cleaner clears 20min merge-lock', !fs.existsSync(MERGE_LOCK));
+writeLock(MERGE_LOCK, { pid: null, ageMin: 20, field: 'acquiredAt' });
+newReg.cleanupStaleLocks(null);
+check('D2 new cleaner clears 20min merge-lock (semantics preserved)', !fs.existsSync(MERGE_LOCK));
+writeLock(MERGE_LOCK, { pid: process.pid, ageMin: 1, field: 'acquiredAt' });
+newReg.cleanupStaleLocks(null);
+check('D3 new cleaner keeps fresh live merge-lock', fs.existsSync(MERGE_LOCK));
+
+sweep();
+console.log(`\n═══ RESULT: ${pass} passed, ${fail} failed ═══`);
+process.exit(fail ? 1 : 0);

package/core/.kenaz/tmp/heimdall_proposal_fc7e0944.json

@@ -0,0 +1,10 @@
+{
+  "projectPath": "C:/Users/user/Documents/GitHub/KenazAI",
+  "title": "task-api updateTask still uses direct-parent _status_dir derivation (residual of TASK_1843 bug class)",
+  "description": "Commit fc7e0944 (TASK_1843) fixed _loadTaskFile's status resolution by walking the ancestor dir chain, because basename(dirname(filePath)) yields 'TASK_XXX' for directory-layout cards (active/TASK_XXX/TASK_XXX.yaml) and poisoned _status_dir. Heimdall commit scan found ONE residual instance of the same pattern: .collaboration/core/task-api.js line ~1545, updateTask same-status branch sets updatedTask._status_dir = path.basename(path.dirname(filePath)). For directory-layout cards, updateTask's RETURN VALUE carries _status_dir='TASK_XXX', now inconsistent with getTask (which returns 'active' via the fixed path). Current blast radius is LOW - persisted YAML is clean and all known _status_dir consumers (post-complete.js GC/reconcile, fake-stream.js) read via getTask - but any caller trusting updateTask's return (e.g. CLI update JSON output) inherits the poisoned field. Proposed fix: extract the TASK_1843 ancestor-walk into a shared helper used by both _loadTaskFile and updateTask (no duplicate parallel impls). Evidence: synapse_pulse on _loadTaskFile (3 runes), repo-wide grep for the pattern (single residual hit), risk rune rune_9fa7db416fe74d14a65895fd26361188 inscribed on updateTask.",
+  "category": "bug_fix",
+  "priority": "medium",
+  "affectedFiles": [".collaboration/core/task-api.js"],
+  "estimatedHours": 0.5,
+  "source": "code_watch:risk_rune:task1843_updatetask_status_dir_residual"
+}

package/core/.kenaz/tmp_heimdall_proposal_8d3e392.json

@@ -0,0 +1,13 @@
+{
+  "projectPath": "C:/Users/user/Documents/GitHub/KenazAI",
+  "title": "TASK_1684 validation doc conflicts with code-probed evidence: Goodhart guard marked COMPLETE but gate-ON path is unwired; significance claims ignore cluster-effective-n",
+  "description": "Commit 8d3e3925d 新增 dev/TASK_1684_P3_2_REMEASURE_VALIDATION.md，其結論將作為 Phase 4 flag 開啟決策的依據，但與兩筆高信度既有證據直接衝突：\n\n1. Requirement (B) 標記 COMPLETE（'Goodhart guard implemented, 5/5 unit tests'）— 但同日 code probe（rune_85d43cb4, confidence 0.95, proposal AXON_c8c8d0ee）證實：novelty_weight 只被寫成 sidecar 欄位，reflex_reconcile.js:286 存的是 raw weightedMean，_loadOutcomeComponentShadow 讀取時也不乘 novelty_weight。gate-ON 路徑上 Goodhart guard 實際不存在；5/5 測試只覆蓋 gate-OFF。(B) 應標 INCOMPLETE until AXON_c8c8d0ee 修復落地 + gate-ON 測試。\n\n2. '0.9607 effect size (highly significant)' / 'Statistical power: High' — 與 2026-08-03 已簽核的 P3-3c 分析（rune_11c13fb0）衝突：28 turns 塌縮成 5 個 resolution clusters（12/8/4/2/2），Kish effective n=3.4，cluster-adjusted 95% CI = [-0.964, +0.958]（整個值域）。hit 類只有 n=2 且共享同一 predictor value。文件宣稱的 significance 正是該 rune 明文警告的 'bare r without clustering correction ships a number that looks like evidence and is not'。upstream 綁定約束 TASK_1848（attribution population，5 clusters 不動則所有 P3 gate 結構性 underpowered）在文件中完全未提及。\n\n3. 內部不一致：標題稱 '22 attributable turns'，表格為 n=28（2 hits + 26 misses）；資料來源標 'reconciled 2026-08-07' 但 commit message 稱 2026-08-12 shadow。\n\n建議：在 Phase 4 flag 決策前修訂該文件 — (B) 降為 pending AXON_c8c8d0ee、significance 段落加 cluster-adjusted CI、補 TASK_1848 依賴。'UNBLOCKS TASK_1582' 的結論在 cluster count 未增加前不成立。",
+  "category": "bug_fix",
+  "priority": "high",
+  "affectedFiles": [
+    "dev/TASK_1684_P3_2_REMEASURE_VALIDATION.md",
+    ".specialist/Ansuz/tools/reflex_reconcile.js",
+    ".specialist/Ansuz/tools/reflex_reward.js"
+  ],
+  "source": "code_watch:commit:8d3e3925d:validation_doc_overclaim"
+}

package/core/.kenaz/tmp_props.json

@@ -0,0 +1 @@
+{"success":true,"data":{"proposals":[{"affected_files":["sym_240d78ed_run_incremental_index_702","sym_07deee87_extract_typescript_symbols_453",".collaboration/hooks/install.js","dashboard/src-tauri/src/features/synapse/community_detector.rs","dashboard/src-tauri/src/infrastructure/http_server/routes/agent_flow.rs","sym_9eba08de_parse_detail_level_31","sym_7aa98693_search_symbols_260","dashboard/src/components/agent-flow/hooks/simulation/handle-message-events.ts","dashboard/src/lib/yggdrasil-client.ts","sym_7aa98693_fst_prefilter_candidates_852","sym_7aa98693_build_grouped_response_1201",".formation/tools/loop.js","sym_6f0fe7f0_router_176","sym_6f0fe7f0_get_loop_config_128","sym_4ce07b71_eager_init_engine_371","sym_7aa98693_build_grouped_response_1223","src/features/synapse/search.rs",".collaboration/core/task-api.js","dashboard/src/components/agent-flow/visualizer/chat-panel.tsx","dashboard/src-tauri/src/infrastructure/http_server/routes/temporal.rs","sym_52019570_main_664","sym_4d576603_detect_processes_49","src/features/synapse/db_pool.rs","dashboard/src-tauri/src/features/synapse/scanner.rs",".synapse/rules/SEC-001.yaml","dashboard/src/hooks/use-task-inbox.ts",".specialist/Ansuz/tools/reflex_executor.js","dashboard/src-tauri/src/features/synapse/reflex_neurons.rs",".formation/tools/post-complete/health.js","dashboard/src/lib/tauri-commands.ts","dashboard/src-tauri/src/features/session_watcher/mod.rs","dashboard/src/components/terminal/TerminalPanel.tsx","sym_07deee87_extract_symbols_93",".formation/tools/headless.js","dashboard/src-tauri/src/features/synapse/delta_graph.rs","sym_240d78ed_run_index_460","sym_6f0fe7f0_put_loop_config_147","dashboard/src-tauri/src/features/synapse/schema.rs","dashboard/src-tauri/src/features/synapse/symbols.rs","sym_4bfaa014_run_community_detection_28",".specialist/Muninn/skills/observe.yaml","sym_4ce07b71_compute_embedding_534",".formation/tools/runner.js",".claude/hooks/core-resolve.js","sym_4ce07b71_compute_embeddings_batch_682",".specialist/shared/guard_schema.json",".formation/tools/process-state.js","sym_7aa98693_hybrid_search_455",".specialist/tools/phase-gate.js","dashboard/src/components/agent-flow/bridge/use-kenaz-bridge.ts","dashboard/src/hooks/use-task-pool.ts","dashboard/src-tauri/src/features/synapse/poc.rs","dashboard/src/components/agent-flow/visualizer/canvas/bubble-utils.ts","dashboard/src-tauri/src/features/synapse/memory.rs","sym_07deee87_extract_typescript_symbols_463","dashboard/src-tauri/src/features/hippocampus/episode.rs","sym_4bfaa014_build_and_write_communities_652","dashboard/src-tauri/src/infrastructure/http_server/routes/yggdrasil.rs","sym_240d78ed_IndexState_281","sym_36346c2a_save_health_snapshot_2039","sym_240d78ed_apply_layer3_partial_update_1262","dashboard/src-tauri/src/features/synapse/index.rs","sym_52f2b539_TreeCache_1803","sym_52f2b539_FileHashStore_560","sym_4bfaa014_run_community_detection_29","dashboard/src/components/agent-flow/visualizer/index.tsx","sym_52f2b539_compute_sha1_532","dashboard/src/lib/agent-coordination/websocket-client.ts","dashboard/src-tauri/src/features/synapse/context.rs","dashboard/src-tauri/src/features/synapse/anomaly.rs","sym_8351c01e_wishes_router_300","sym_b3379609_router_1780","sym_eb47be15_init_schema_on_conn_43","sym_3e8589bf_triggerGuardianHealthCheck_327",".formation/tools/dispatch.js","sym_4ce07b71_EmbeddingEngine_74","sym_7aa98693_SearchIndex_37","sym_07deee87_extract_symbols_83","sym_240d78ed_INDEX_FEATURE_VERSION_254","sym_7aa98693_fts5_search_with_scores_296","src/features/synapse/index.rs","dashboard/src-tauri/src/infrastructure/http_server/routes/synapse.rs",".specialist/Ansuz/guards/lesson_guards.yaml",".specialist/tools/lesson-guard.js","dashboard/src/components/task-board/TaskBoard.tsx",".formation/tools/dispatch-registry.js","dashboard/src/components/agent-flow/visualizer/canvas/draw-misc.ts",".specialist/Ansuz/phases/phase_9.yaml","sym_240d78ed_Durability_159",".formation/tools/post-complete.js","dashboard/src-tauri/src/infrastructure/http_server/routes/wishes.rs","sym_4bfaa014_build_and_write_communities_560","dashboard/src/components/yggdrasil/use-pool-actions.ts","dashboard/src-tauri/src/infrastructure/http_server/routes/loop_config.rs","sym_eb47be15_init_schema_on_conn_37","sym_7aa98693_delete_by_file_path_238","dashboard/src-tauri/src/infrastructure/http_server/routes/mcp_tools/synapse.rs","dashboard/src/components/agent-flow/visualizer/canvas/draw-bubbles.ts","sym_52019570_spawnHuginn_416",".specialist/Ansuz/phases/phase_11.yaml","dashboard/src/components/agent-flow/visualizer/canvas/draw-agents.ts","sym_52f2b539_scan_file_incremental_2001",".specialist/Ansuz/phases/phase_0.yaml","sym_240d78ed_run_full_index_504","dashboard/src/components/agent-flow/visualizer/session-transcript-panel.tsx","dashboard/src-tauri/src/features/synapse/process_detector.rs","sym_52019570_buildAnsuzPrompt_487","sym_6fc3cf1e_query_symbol_context_inner_101","dashboard/src-tauri/src/features/task/manager.rs","dashboard/src-tauri/src/features/synapse/embedding.rs","dashboard/src-tauri/src/features/synapse/search.rs","sym_240d78ed_DurabilityConfig_174"],"category":"refactoring","created_at":"2026-06-10T18:29:31.252039100+00:00","description":"26 sigil(s) have member symbols with runes written after last refresh: Task Pool Handoff Safety Pattern, Health Metric Trending Pipeline, Sub-Project Boot Boundary Resolution, Live Reflex Feedback Loop, Guard Schema Evolution Pipeline, Task Path Resolution, Lesson Guard Injection Pipeline, High-Traffic Symbol Architectural Pathologies, SEC-001 Unsanitized Input Detection Pipeline, Process Lifecycle Cleanup Pipeline, ΔGraph Commit Pipeline, Bubble Conversation Overlay System, Canvas Label Rendering Pipeline, AXON Bridge Pattern, Agent Flow Dual Data Source Pipeline, PTY-to-UI Mirroring Pipeline, Anchor Resolution Workflow, Incremental Index Optimization Stack, Durability-Graded Incremental Indexing, Autonomous Improvement Loop, Synapse MCP Enhancement Pipeline, Model Override Pipeline, Real-Time Agent Coordination Bus, FST Per-File Index Strategy, Facade Pattern for Code Intelligence, Synapse DB Read-Write Separation. Review and re-forge or inscribe to advance their refreshed_at.","diffs":[],"estimated_hours":null,"id":"AXON_44bdcf58","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":"2026-07-09T17:30:26.388096800+00:00","source":"stale_sigils_batch","status":"ignored","title":"Refresh stale sigils (26 sigil(s) need review)","updated_at":"2026-07-09T17:30:26.388096800+00:00"},{"affected_files":[],"category":"code_quality","created_at":"2026-06-20T04:23:51.511126600+00:00","description":"verify_health_mock.py line 9 sets ROOT = 'C:/Users/user/Documents/GitHub/jiayao' as a hardcoded string literal. gen_health_mock.py correctly derives ROOT via os.path.dirname(os.path.dirname(os.path.abspath(__file__))). The verifier will silently fail on any machine other than the original author's, or if the project is moved. Fix: replace the literal with the same __file__-relative derivation used by the generator.","diffs":[],"estimated_hours":null,"id":"AXON_a7570ca0","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":"2026-07-07T16:21:04.884572500+00:00","source":"commit_analysis:static_read","status":"ignored","title":"verify_health_mock.py: hardcoded absolute path breaks portability","updated_at":"2026-07-07T16:21:04.884572500+00:00"},{"affected_files":["sym_52019570_spawnHuginn_416","sym_4ce07b71_eager_init_engine_371","sym_7aa98693_search_symbols_260","dashboard/src-tauri/src/features/synapse/context.rs",".specialist/Ansuz/phases/phase_11.yaml","dashboard/src-tauri/src/features/synapse/symbols.rs","dashboard/src-tauri/src/features/synapse/schema.rs","sym_9eba08de_parse_detail_level_31","sym_8351c01e_wishes_router_300","sym_b3379609_router_1780","sym_eb47be15_init_schema_on_conn_37","dashboard/src-tauri/src/features/synapse/memory.rs","src/features/synapse/search.rs","sym_4ce07b71_compute_embedding_534","sym_07deee87_extract_typescript_symbols_453","dashboard/src-tauri/src/features/synapse/search.rs","sym_4ce07b71_compute_embeddings_batch_682",".formation/tools/runner.js",".formation/tools/loop.js","sym_4bfaa014_run_community_detection_29","sym_6fc3cf1e_query_symbol_context_inner_101",".formation/tools/post-complete.js","dashboard/src-tauri/src/infrastructure/http_server/routes/loop_config.rs","sym_6f0fe7f0_get_loop_config_128","sym_07deee87_extract_symbols_83","src/features/synapse/db_pool.rs","sym_7aa98693_SearchIndex_37","sym_6f0fe7f0_router_176","sym_7aa98693_build_grouped_response_1223","sym_4ce07b71_EmbeddingEngine_74",".formation/tools/dispatch-registry.js","sym_4d576603_detect_processes_49","sym_4bfaa014_build_and_write_communities_652","sym_7aa98693_hybrid_search_455","dashboard/src-tauri/src/infrastructure/http_server/routes/mcp_tools/synapse.rs","sym_7aa98693_fst_prefilter_candidates_852","sym_4bfaa014_run_community_detection_28","dashboard/src/components/agent-flow/visualizer/session-transcript-panel.tsx","sym_7aa98693_fts5_search_with_scores_296","dashboard/src-tauri/src/infrastructure/http_server/routes/wishes.rs",".specialist/Ansuz/phases/phase_0.yaml","dashboard/src-tauri/src/infrastructure/http_server/routes/synapse.rs","sym_6f0fe7f0_put_loop_config_147","sym_36346c2a_save_health_snapshot_2039","sym_7aa98693_delete_by_file_path_238",".formation/tools/dispatch.js","dashboard/src-tauri/src/features/synapse/community_detector.rs","sym_7aa98693_build_grouped_response_1201","dashboard/src/lib/agent-coordination/websocket-client.ts","sym_52019570_buildAnsuzPrompt_487","sym_eb47be15_init_schema_on_conn_43","sym_07deee87_extract_symbols_93",".specialist/Muninn/skills/observe.yaml",".specialist/Ansuz/phases/phase_9.yaml","dashboard/src-tauri/src/features/synapse/embedding.rs","dashboard/src/components/agent-flow/bridge/use-kenaz-bridge.ts","dashboard/src-tauri/src/features/synapse/poc.rs","sym_52019570_main_664","sym_4bfaa014_build_and_write_communities_560","sym_3e8589bf_triggerGuardianHealthCheck_327","sym_07deee87_extract_typescript_symbols_463","dashboard/src-tauri/src/features/synapse/process_detector.rs","src/features/synapse/index.rs","dashboard/src/components/terminal/TerminalPanel.tsx",".formation/tools/headless.js"],"category":"refactoring","created_at":"2026-07-20T07:01:33.532996+00:00","description":"10 sigil(s) have member symbols with runes written after last refresh: AXON Bridge Pattern, PTY-to-UI Mirroring Pipeline, Anchor Resolution Workflow, Autonomous Improvement Loop, Synapse MCP Enhancement Pipeline, Model Override Pipeline, Real-Time Agent Coordination Bus, FST Per-File Index Strategy, Facade Pattern for Code Intelligence, Synapse DB Read-Write Separation. Review and re-forge or inscribe to advance their refreshed_at.","diffs":[],"estimated_hours":null,"id":"AXON_b7ca8be7","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"stale_sigils_batch","status":"pending","title":"Refresh stale sigils (10 sigil(s) need review)","updated_at":null},{"affected_files":[],"category":"code_quality","created_at":"2026-07-24T19:39:08.818741500+00:00","description":"TASK_1791 added targeted reap (reap --session-id=<sid>). Two residual weaknesses in cmdReap: (1) fs.unlinkSync is wrapped in try/catch with the error swallowed, then 'reaped <label>' prints unconditionally -- on Windows EBUSY/EPERM (antivirus scan, concurrent hook read) the lease file survives but the user sees success; next boot the banner re-flags the same lease, which is the exact 'command claims success / state persists' UX class TASK_1791 fixed. (2) unlink path uses leasePath(one.session_id) from parsed file content instead of leasePath(sid) from the lookup key -- if content and filename ever diverge, reap deletes a nonexistent path and still reports success. Fix is ~3 lines: unlink by sid, check fs.existsSync after unlink, warn + exit 1 on failure.","diffs":[],"estimated_hours":null,"id":"AXON_1547e289","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:commit:0fb03768","status":"pending","title":"stream-lease targeted reap prints 'reaped' even when unlink fails (false success on Windows file locks)","updated_at":null},{"affected_files":[],"category":"code_quality","created_at":"2026-07-24T19:56:14.660096800+00:00","description":"codex-cli 0.144.1 emits item.type 'file_change' for file edits, but the translation branch in .formation/bifrost/openai/relay.js translateEvent() that emits the Claude Edit tool_use event (and fires PreToolUse/PostToolUse hooks) is gated on 'file_edit' only (~line 233). Consequence: every codex-dispatched agent performs real file edits with NO PreToolUse(Edit) hook, NO Edit tool_use in the stream, and NO PostToolUse(Edit) hook, silently bypassing scope enforcement, the synapse-first reflex, canary integrity checks, and post-edit logging. TASK_1786 (commit 952416b8) added file_change to the num_turns counter only, so turn metrics now look healthy while the translation/hook path still drops the event: the improved metric masks the gap. Explicitly reported out-of-scope in the TASK_1786 commit message. Fix: alias file_change into the file_edit translation branch (or add a case) so it emits the Edit tool_use + hooks; audit file_read for the same upstream rename risk. Evidence: rune_638d68443e2e49e3b52e966195345360 (risk, 0.85), verified against TASK_1779-batch codex transcripts.","diffs":[],"estimated_hours":null,"id":"AXON_b6953693","metadata":null,"priority":"P1","related_task_id":null,"resolved_at":null,"source":"code_watch:commit:952416b8","status":"pending","title":"bifrost relay: codex file edits bypass Edit tool_use + PreToolUse/PostToolUse hooks (file_change vs file_edit)","updated_at":null},{"affected_files":[".formation/tools/headless.js"],"category":"bug_fix","created_at":"2026-07-24T20:02:53.737995500+00:00","description":"Commit 1d3c7684 (TASK_1787) added a read-only self-claim guard to launch() in .formation/tools/headless.js to suppress the spurious 'already claimed' warning of DEFECT-F. The guard reads two identity files: (1) .kenaz/locks/claim_<task>.json (fields owner_conversation_id / owner_session) and (2) .kenaz/specialist/current_stream.json (fields conversation_id / session_id). VERIFIED: no code anywhere in the repo (JS or Rust, including task-api.js claim path) writes either file, and both are absent on disk. Both readFileSync throw ENOENT -> the catch swallows it -> selfClaimed stays false -> execution ALWAYS falls through to the normal claim subprocess. The guard degrades safely (no regression), but the spurious warning it targets is NOT suppressed: only the reader half landed. Fix requires the writer half — the dispatching Ansuz stream must persist current_stream.json (conversation_id/session_id) AND write the claim marker (owner_conversation_id, or owner_session fallback) before spawning headless.js. Evidence rune: rune_faab3b3c49cd4f79aad109f4660270ab. Recommendation: land the writer half, or add an integration assertion so an inert guard is not mistaken for a working fix. The Bifröst adapter change in the same commit (--bifrost-adapter -> resolveLaunchBifrostAdapter, line 227) is correctly wired end-to-end; no issue there.","diffs":[],"estimated_hours":1.5,"id":"AXON_7bf6979e","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune","status":"pending","title":"TASK_1787 self-claim guard is inert — DEFECT-F not actually fixed","updated_at":null},{"affected_files":[],"category":"code_quality","created_at":"2026-07-24T20:10:53.886083200+00:00","description":"Commit 157e8dd0 (TASK_1792) adds a --force escape hatch to targeted reap and states (commit message + inline comment) that --force 'is deliberately rejected by bulk reap -- overriding liveness must always name a specific session'. The implementation does NOT reject it: in cmdReap (stream-lease.js:139-151), force is only consumed inside the sid branch; `reap --force` without --session-id (or with bare `--session-id` which parses to true) falls through to the bulk path where the flag is silently dropped and an ordinary 24h-threshold bulk reap runs. An operator invoking the crash-recovery escape hatch but omitting the session id sees normal bulk output ('nothing to reap' / reaped list) with zero indication the override was ignored -- defeating the discoverability goal this very commit pursued ('recovery path discoverable at the point of failure'). Fix is one guard in the bulk path: if(force){stderr 'error: --force requires --session-id=<sid>'; exit 1}. Secondary note: the new --force unlink reuses the swallowed try/catch unlink already flagged in AXON_1547e289; that existing proposal now also covers the force path (worst case: force-reaping a session whose lease file is concurrently locked by lease-touch prints 'reaped' on failure).","diffs":[],"estimated_hours":null,"id":"AXON_40eecfe7","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:commit:157e8dd0","status":"pending","title":"stream-lease bulk reap silently ignores --force, contradicting documented 'rejected' behavior","updated_at":null},{"affected_files":["dashboard/scripts/build-static.js","dashboard/scripts/sync-kenaz-core.js",".formation/tools/post-complete.js"],"category":"security","created_at":"2026-07-24T20:27:42.256891200+00:00","description":"Commit 0d23ce97 deleted 25 muninn one-off probe scripts (10 tracked, 1344 LOC) that had shipped inside the Tauri bundle. Root cause remains open: both staging paths copy .formation/ from the WORKING TREE with no root-level ephemera filter, so the next probe script ships again.\n\nEvidence (verified 2026-07-25):\n1. dashboard/scripts/build-static.js stageKenazCore() EXCLUDE_PATTERNS (line 196+) excludes only .formation/logs|state|worktrees. It has .kenaz/specialist/muninn_snapshot_ (line 320) but NO .formation/muninn_* or .formation/tmp_* pattern.\n2. dashboard/scripts/sync-kenaz-core.js SYNC_RULES (line 36-40): { src: .formation, exclude: [logs,state,worktrees], fileFilter: !*.log } — root-level *.js passes through. Twin gap.\n3. Neither staging path consults .gitignore (which already declares .formation/muninn_*.js at line 349) nor daemon-manifest.yaml exclusions — three exclusion lists exist and none reaches the bundle path.\n4. Secondary: .formation/tools/post-complete.js:464 isDaemonNoise regex (TASK_1622) matched only 3 of the 10 deleted filenames (muninn_snapshot_[0-9]+ / muninn_rune_check); variants muninn_episode_task_*, muninn_snapshot_*_episode, muninn_snapshot_ansuz_* were invisible to the worktree-staging noise sweep.\n5. Impact before deletion: 25/217 staged .js were ephemera; 8 embedded the developer absolute home path (privacy leak into distributed bundles); 1 unparseable file was bundled raw because obfuscation failure only warns (build-static 'Failed to obfuscate' path) — obfuscation-fail = ship-unobfuscated is itself a silent leak channel.\n\nSuggested fix (minimal): add .formation/ root ephemera patterns (muninn_*, tmp_*, episode_writer*) to BOTH build-static.js EXCLUDE_PATTERNS and sync-kenaz-core.js fileFilter (keep-both-in-sync convention already documented at build-static.js:204). Consider widening post-complete.js:464 regex to muninn_[a-z0-9_]+ to cover naming variants. Optionally: escalate obfuscation parse failure from warn to fail for staged .js.","diffs":[],"estimated_hours":null,"id":"AXON_aa66f3d9","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:commit:0d23ce97","status":"pending","title":"kenaz-core staging ships .formation/ working-tree ephemera — probe-script deletion fixed symptom only","updated_at":null},{"affected_files":["dashboard/scripts/build-static.js",".kenaz/main-memory/",".kenaz/efe_snapshots/",".claude/settings.json"],"category":"security","created_at":"2026-07-24T20:50:03.143631200+00:00","description":"Commit 24e5cc1f (TASK_1795) converted stageKenazCore to a git-tracked whitelist — this correctly closes the untracked-ephemera leak (AXON_aa66f3d9 item 1) and makes obfuscation failure fatal (item 5). Three residual gaps verified 2026-07-25, none covered by pending AXON_aa66f3d9:\n\n1. COMMENT/CODE DIVERGENCE (build-static.js:287): 'TASK_1738 REVERSED: EFE snapshots + main-memory are NO LONGER shipped... See EXCLUDE_PATTERNS additions below for full list' — but EXCLUDE_PATTERNS contains NO '.kenaz/main-memory/' or '.kenaz/efe_snapshots/' entry. Verified via git ls-files: 28 tracked .kenaz/main-memory/ files + 67 tracked .kenaz/efe_snapshots/TASK_*_efe.json ship in every bundle. EFE snapshots are per-task free-energy session telemetry (same class as the excluded .kenaz/experiments/). TASK_1795's own rune (rune_332794da) flags main-memory as 'needs arbitration' — arbitrate: either add both EXCLUDE entries or fix the comment to say they intentionally ship.\n\n2. WHITELIST PINS FILE NAMES, NOT CONTENT: the new loop copies working-tree bytes of tracked files (copyFileSync), so tracked-but-locally-modified session-state files ship their dirty session content — e.g. .kenaz/channel_heartbeats.jsonl, .kenaz/specialist/motivational_state.json, .kenaz/specialist/ansuz_self_model.json are modified in the working tree right now (ansuz_self_model is EXCLUDE'd; the other two are not). The commit title's 'stage from git, not the working tree' holds for the file LIST only. Fix options: stage content via 'git show :<path>' / git archive for .kenaz session-state paths, or extend EXCLUDE to the remaining mutable session-state jsonl files (channel_heartbeats, guard_detector_shadow, phase9_dispatch_outcomes...).\n\n3. .claude/settings.json ships user-machine absolute allowlist paths (declared out of scope in TASK_1795; content-level privacy leak, needs its own pass).\n\nStill open under AXON_aa66f3d9 (do not duplicate): sync-kenaz-core.js SYNC_RULES blacklist twin; post-complete.js isDaemonNoise regex variants.","diffs":[],"estimated_hours":null,"id":"AXON_5ebe6fe8","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:commit:24e5cc1f","status":"pending","title":"kenaz-core bundle: TASK_1738 comment claims main-memory/EFE excluded but 95 tracked files still ship; whitelist pins names not content","updated_at":null},{"affected_files":["dashboard/scripts/build-static.js",".kenaz/efe_snapshots/"],"category":"bug_fix","created_at":"2026-07-24T21:52:03.609620+00:00","description":"Commit 70ab40bb (TASK_1799), whose stated purpose is correcting false build-staging comments, introduced a new false one. build-static.js:290 now reads: 'EFE snapshots (.kenaz/efe_snapshots/) are untracked, so the git whitelist (TASK_1795) already keeps them out — no EXCLUDE entry exists or is needed for either.' Verified false at this commit: git ls-files .kenaz/efe_snapshots/ returns 67 tracked JSON files (TASK_1099..recent), git check-ignore exits 1 (not ignored), .kenaz is in INCLUDE_DIRS (build-static.js:203), and no EXCLUDE entry matches — the 67 files SHIP in the kenaz-core bundle. Likely cause: author saw only the newest snapshots (untracked working-tree files, e.g. TASK_1789_efe.json) in git status and generalized to the whole directory. Impact: the comment asserts the opposite of pending proposal AXON_5ebe6fe8's EFE half and will bias its arbitration toward wrongful dismissal; internal task/dispatch EFE data keeps shipping. Note: the main-memory half of AXON_5ebe6fe8 IS now arbitrated by TASK_1799 (ships intentionally, hand-curated product knowledge) — that half can be closed. Fix: (a) decide EFE disposition — either git rm --cached + .gitignore .kenaz/efe_snapshots/, or add an EXCLUDE_PATTERNS entry; (b) correct the line-290 comment to match the decision. The settings.json half of 70ab40bb verified clean: allow 121→32 with Bash(*) retained, deny 27 byte-identical, no stale machine paths remain.","diffs":[],"estimated_hours":0.5,"id":"AXON_47a7c9ef","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:build-static-efe-false-comment","status":"pending","title":"Commit 70ab40bb comment falsely claims .kenaz/efe_snapshots/ untracked — 67 tracked files still ship; comment undermines pending AXON_5ebe6fe8","updated_at":null},{"affected_files":[],"category":"code_quality","created_at":"2026-07-25T07:27:07.619326500+00:00","description":"TASK_1800 (d61f2c4f) added C# CALLS extraction; extraction itself is sound, but the shared resolution cascade in scanner.rs was tuned for Rust/JS lowercase naming and C# PascalCase slips past both guards. Evidence: (1) same_file strategy (scanner.rs:2104-2120) matches callee_simple_name against any function/method Symbol in the file, receiver-blind, at confidence 0.90 -- above the <0.7 gate that activates is_common_method_name (scanner.rs:2134), so the guard can never fire on it. Unity MonoBehaviours define Update/Start/Awake/OnEnable/OnDestroy in nearly every file: `base.Update()` inside an override will resolve to the override itself (self-loop CALLS edge at 0.90), and `obj.Start()` in any file defining its own Start() resolves to the wrong same-file method. The commit's own test fixture (base.Update() inside Update()) is the self-loop case. (2) generic_names.rs GENERIC_METHOD_NAMES contains zero PascalCase C#/Unity entries (verified by grep), so the L2 guard is a no-op for csharp even on low-confidence receiver_match (0.60) edges, which insert freely above the 0.5 consumer threshold. Net effect: the first real Unity project indexed will get systematically inflated synapse_impact blast radii -- and per the commit's own NOT VERIFIED note, no .cs project has ever been indexed e2e, so this is invisible to the current test suite. Cheap fixes, in order of leverage: (a) add Unity message names + System.Object members (PascalCase) to GENERIC_METHOD_NAMES; (b) make same_file skip callees whose raw text carries an explicit non-this receiver (callee_name contains '.' with prefix not in {this, base}); (c) resolve base.X via the EXTENDS parent instead of same-file. Rune: rune_4d660c43690a4a73a826e316127f9849. Fold into the multi-language epic proposed by Muninn (rune_555c713c) alongside the existing e2e-verification gap (rune_e1af1dc9).","diffs":[],"estimated_hours":null,"id":"AXON_e546d8ee","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:commit_analysis:d61f2c4f","status":"pending","title":"C# CALLS resolution: Unity PascalCase names bypass all precision guards (self-loops + wrong-receiver edges on first real Unity index)","updated_at":null},{"affected_files":[".formation/tools/prompt.js"],"category":"code_quality","created_at":"2026-07-25T13:23:09.405570500+00:00","description":"Commit 3e038e81（TASK_1805 rule 14）本身已驗證無誤（node --check + 實際 dispatch smoke test），但暴露三項累積中的結構債：(1) prompt.js 現為 1997 行，距 ARCH-001 warn=2000 僅 3 行，下一次編輯即跨線；(2) SUBAGENT_PREFIX 與 SUBAGENT_PREFIX_DIRECT 的編號規則呈 1-6, 12, 13, 14, 7-11 亂序——三次 hot-fix 插入（規則 12/13/14）都直接塞在規則 6 後而未重排，dispatch prompt 的「見規則 N」交叉引用目前仍正確，但列表已非單調遞增，繼續插入只會更亂；(3) 規則 12/13/14 在兩個 prefix 間逐字複製，最近三個 commit（32557e83→3e038e81）都必須成對同步編輯，且 commit message 記錄了一次未跳脫反引號差點讓 prompt.js 整檔停止解析——此檔是所有 dispatch 的單點故障。建議：抽出共用規則字串常數（一處維護、兩處插值）、順序重排編號並同步更新交叉引用、並將 prefix 常數群抽到獨立模組（如 .formation/tools/prompt-prefixes.js）以脫離 file budget 邊緣。驗證閘：node --check + dispatch.js --dispatch-mode=subagent 輸出比對（規則集逐條 diff 應為零差異）。","diffs":[],"estimated_hours":null,"id":"AXON_7e78c7b9","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:commit_analysis","status":"pending","title":"prompt.js 結構債：檔案觸及 ARCH-001 warn 邊緣＋subagent 規則區塊雙重複製與亂序編號","updated_at":null},{"affected_files":[],"category":"other","created_at":"2026-07-25T15:24:40.528473300+00:00","description":"Verified at commit cc4f6049 (TASK_1811 Phase 1 instrumentation). accumulate_heat_and_fire keys the neuron map with heat_{symbol_id} (pulse.rs:2292) but Neuron::new_heat stores the UNPREFIXED id in neuron.symbol_id (pulse.rs:830-832). Every other special channel (engagement, anchor, surprise, fatigue) stores the fully prefixed id — heat is the one asymmetric channel. Consequence 1 (live defect): the TASK_1052 LTP exclusion in try_fire (pulse.rs:1085, starts_with(\"heat_\")) is always false for heat neurons, so a heat neuron firing >= LTP_THRESHOLD in 7d is promoted to Tonic with earned baseline, violating the documented standard-symbol-only contract; apply_dynamic_baselines then keeps recency_factor=1.0 for actively edited symbols, making the promotion self-sustaining. Consequence 2 (booby trap): the obvious TASK_1811 Phase 2 remedy for heat PE saturation (measured sat_pct 41.7%) — adding heat_ to the anchor_/surprise_ exemption list — is silently inert. Recommended fix: replace prefix-string dispatch with a channel enum/flag on Neuron (durable design flagged when TASK_1809 shipped); if instead prefixing the stored id, first audit neuron.symbol_id consumers (apply_dynamic_baselines HeatEngine lookup; the raw-id inject/enqueue_pulse_target calls in accumulate_heat_and_fire are correct and must not change). Runes: rune_63126a883e78457e9807e5525bdeb662 (new_heat), rune_3aca86b846734bf8a1c2a9d913ce4e19 (try_fire, measured saturation table).","diffs":[],"estimated_hours":null,"id":"AXON_37b74833","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:pulse_heat_prefix_inert","status":"pending","title":"heat neurons store unprefixed symbol_id: LTP exclusion is inert, and any prefix-keyed PE remedy (TASK_1811 Phase 2) will silently no-op","updated_at":null},{"affected_files":["dashboard/src-tauri/src/features/synapse/pulse.rs","dashboard/src-tauri/src/features/synapse/pulse_channels.rs"],"category":"refactoring","created_at":"2026-07-25T16:02:05.053078300+00:00","description":"TASK_1811 (cc4f6049 + e5b6caf9) grew pulse.rs by ~980 lines (446-line saturation instrumentation test module in Phase 1, +534 net in Phase 2). The file was already over the ARCH-001 hard limit before the task (~4823) and now sits at 5803 lines; the check-file-size gate never fired because commits go in with --no-verify (team norm). The fix itself is sound — divergence in pulse_propagation.rs / imagination.rs was closed by delegating to neuron.effective_fire_threshold(), serde defaults cover backward-compatible cache loads, and load_cache reclassifies channels by map key. This proposal is purely structural: (1) extract NeuronChannel enum + the delta-domain predictor/gate logic (expected_delta / delta_scale / pe_observations, classify, effective_fire_threshold) into the existing pulse_channels.rs sibling — the split pattern is already established (pulse_propagation.rs, pulse_query.rs, pulse_replay.rs); (2) move the 19-scenario saturation instrumentation test module to its own test file. Both moves are mechanical; behavioral contracts (anchor step-7 fire, outcome no-early-fire) are already pinned by the suite (1356 tests).","diffs":[],"estimated_hours":3.0,"id":"AXON_a83ba2aa","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:commit:e5b6caf9","status":"pending","title":"pulse.rs breached ARCH-001 hard limit (5803 > 4000 lines) — extract NeuronChannel/predictor + saturation tests","updated_at":null},{"affected_files":["dashboard/src-tauri/src/features/synapse/scanner.rs","dashboard/src-tauri/src/features/synapse/scanner.rs:TreeCache:class","dashboard/src-tauri/src/features/synapse/scanner.rs:new:method"],"category":"refactoring","created_at":"2026-07-25T17:28:09.063256300+00:00","description":"Commit 4714fe95 (TASK_1803) fixed the quadratic LRU in TreeCache::get/insert (access_order.retain O(capacity) on every access, capacity 5000 under the global TREE_CACHE Mutex) by replacing access_order: Vec<String> with a monotonic access_counter + per-entry last_access stamp. Verified landed on main; suite 1356/0 x3. Sigil sigil_1fce39be (High-Traffic Symbol Architectural Pathologies) still carries member scanner.rs:new:method with role quadratic_lru — DOUBLY stale: (1) the attribution was always wrong (ScanProgress::new is a pure atomics constructor; the LRU lived in TreeCache::get/insert — symbol-name collision on new), and (2) the pathology is now fixed. This sigil misdirection already cost TASK_1803 a disproof cycle; future recalls near ScanProgress::new will keep surfacing a false pathology. Action: re-forge or edit sigil_1fce39be — remove the quadratic_lru member (or re-point to scanner.rs:TreeCache:class with role quadratic_lru_FIXED referencing rune_d8f2782ced514795971775c3831f7023). Not covered by pending AXON_b7ca8be7 (its 10-sigil list excludes this sigil). Residual perf note (documented, deliberately accepted in rune): cold scan >5000 distinct files still pays O(capacity) per insert min-scan; get-hit path is O(1).","diffs":[],"estimated_hours":null,"id":"AXON_c6f10cd1","metadata":null,"priority":"P3","related_task_id":null,"resolved_at":null,"source":"code_watch:stale_sigil:sigil_1fce39be","status":"pending","title":"Retire/re-point sigil_1fce39be quadratic_lru member — pathology fixed and misattributed","updated_at":null},{"affected_files":[],"category":"other","created_at":"2026-07-26T09:49:40.403515200+00:00","description":"Commit 25672ccd ([TASK_1813]) carries TASK_1814 full implementation (dispatch_mode field + post_models validation + ModelSelectionPanel Dispatch Routing UI, +184 lines) while its message states 'the write side is TASK_1814' (implying deferred). git log --grep=TASK_1814 on main returns nothing; original TASK_1814 commits (9b964614, 4a1be1da) exist only on worktree branch ansuz-wt-e989b14a-13892. Verified: git diff 9b964614..25672ccd on both TASK_1814 files is EMPTY (content parity, branch safe to delete). Code health of the landed change verified clean: camelCase serde on StoredModels/ModelsPayload matches the dispatch.js reader and UI writer; refusal-wording parity with kenaz.rs intact (3 JS branches vs 2 Rust is by design); routing guard placed before lease acquisition. Recommended: (1) confirm TASK_1814 card is done with a note that it landed via 25672ccd, (2) delete branch ansuz-wt-e989b14a-13892, (3) provenance rune rune_e35552182be54c229e7a7be7fbc32cee inscribed on post_models.","diffs":[],"estimated_hours":null,"id":"AXON_f82edb07","metadata":null,"priority":"P3","related_task_id":null,"resolved_at":null,"source":"code_watch:commit_scan:25672ccd","status":"pending","title":"Mixed-change commit 25672ccd: TASK_1814 landed under TASK_1813 header - reconcile task bookkeeping and delete stale worktree branch","updated_at":null},{"affected_files":[".formation/tools/headless.js",".formation/tools/dispatch.js",".formation/tools/utils.js","dashboard/src-tauri/src/infrastructure/http_server/routes/mcp_tools/kenaz.rs"],"category":"code_quality","created_at":"2026-07-26T09:56:08.387437800+00:00","description":"Commit 845bf64e (TASK_1813) added loadDispatchRouting() in dispatch.js:1072 with strict semantics: candidate order project-first-then-core, ALL fields taken from the FIRST parseable file (so family/adapter/model can never mix across two dashboard-models.json files), empty string -> null. This mirrors Rust load_dispatch_routing (kenaz.rs:200) and the commit stakes correctness on that parity.\n\nBut the JS side already had a THIRD reader that violates exactly this invariant: headless.js:888-905 resolves dispatchModel with a candidate loop that breaks only when the parsed file hasOwnProperty('dispatchModel') - a parseable PROJECT file lacking that key falls through to CORE. Meanwhile the _dashboardModels cache is overwritten on every parse attempt, and resolveAgentModel() (headless.js:915-933) reads agent models (huginnModel/heimdallModel/...) from that cache - or, when cold, does its own loop with yet different semantics (first-PARSEABLE wins). Net effect: which file supplies the per-agent models depends on whether the project file happens to contain a dispatchModel key. That is cross-field coupling between unrelated config keys, and it is the precise 'fields mixed across two files' split-brain that loadDispatchRouting's header comment declares must never happen.\n\nrune_eb530386 (TASK_1813 decision) already prescribes the remedy: 'if a third JS consumer of dispatchFamily appears, promote loadDispatchRouting into utils.js next to readDashboardModels'. The third consumer of the candidate-chain pattern already exists and predates the rune.\n\nRecommendation: (1) move loadDispatchRouting to utils.js (exported next to readDashboardModels), (2) have headless.js call it once and derive both dispatchModel fallback and resolveAgentModel from routing.models, deleting the two inline loops, (3) keep dispatch.js importing the shared function. Side benefit: direct headless.js invocations (scheduler/cron/CLI without --dispatch-model) gain the same dispatchFamily fail-loud guard; today they rely on runner.js model-id->adapter resolution, which does fail loudly for unknown ids but with a less actionable message. Verified data points: 18/18 subagent-bifrost-guard tests pass on merged tree; refusal phrase 'refusing to silently dispatch with the native Claude CLI' present in both kenaz.rs (643,650) and dispatch.js (1139,1141,1146) - cross-language drift-grep intact.","diffs":[],"estimated_hours":1.5,"id":"AXON_99377169","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:coupling","status":"pending","title":"dashboard-models.json now has 3 divergent JS readers - headless.js per-key fallthrough can mix fields across project/core files","updated_at":null},{"affected_files":[".formation/tools/dispatch.js"],"category":"code_quality","created_at":"2026-07-26T15:15:55.475142300+00:00","description":"Follow-up to TASK_1822 (commit 2a16539c). The commit's own principle — 'a silent skip would read as this was reviewed when it was not' — is applied to binary files but NOT to the catch { /* skip unreadable files */ } path in buildCortexContext (.formation/tools/dispatch.js:~582). Two residual gaps: (1) fs.readFileSync(fullPath, 'utf-8') still loads the ENTIRE file to produce an 8 KB preview; a text file above V8's string limit (~512 MB, e.g. SQL dump / large log / dataset CSV in scope_paths) throws ERR_STRING_TOO_LONG and the file silently vanishes from the Cortex Context section — same ambiguity class as the original external report (issue 7). Permission errors vanish the same way. (2) The full-file read is transiently memory-expensive for large text files even when it succeeds. Suggested minimal fix: in the catch, push a section header '### {sp} (unreadable — content preview skipped: {err.code})'; optionally reuse the isBinaryFile fd-read pattern to read only the first CORTEX_PREVIEW_MAX_BYTES instead of the whole file (costs the exact totalLines count — could report 'first 30 lines' instead). Evidence: synapse_pulse on buildCortexContext (0 dependents, LOW blast radius); fix rune rune_f64a7de2ce6248ce9d668d02ce7f9c7f documents the intended contract that this path violates.","diffs":[],"estimated_hours":0.5,"id":"AXON_39f6e59a","metadata":null,"priority":"P3","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:buildCortexContext_silent_skip","status":"pending","title":"buildCortexContext: annotate skipped unreadable files and bound the preview read","updated_at":null},{"affected_files":[],"category":"code_quality","created_at":"2026-07-26T15:25:40.306803200+00:00","description":"Commit ed2ba580 (TASK_1818) split daemon-manifest.yaml into state_files (revert+exclude) and commit_exclude_files (exclude only), moving .kenaz/dashboard-models.json into the latter because it is USER config, not daemon state. The commit explicitly declared dashboard/src/lib/daemon-managed-paths.ts a known out-of-scope follow-up - but that file is NOT documentation-only. use-git-status.ts:147 and :174 filter git-status touching_files through isDaemonManagedPath(), feeding Yggdrasil cross-node detectConflicts() (TASK_1532 Bug C). STATE_FILES line 48 still lists .kenaz/dashboard-models.json, so the dashboard classifies user config as daemon churn. Post-1818 consequence in deployments that TRACK the file (the exact class where the original data-loss fired): the file now stays permanently dirty (never reverted, excluded from task commits) and the dashboard permanently hides that dirt from git status / conflict detection - the user is never prompted to commit their own config change. Also, the mirror header (lines 5-9) mandates lockstep sync with the manifest and only knows two categories, so a future 'sync' could remove the entry entirely and silently change conflict-detection behavior. Suggested fix: mirror the manifest split - add a COMMIT_EXCLUDE_FILES list to daemon-managed-paths.ts with its own comment stating whether user configs should still be filtered from touching_files (per-node preference: probably yes for cross-node conflict purposes, but that must be an explicit decision, not a stale classification). ~10 LOC, single file.","diffs":[],"estimated_hours":null,"id":"AXON_e0eb44d6","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":"2026-07-26T22:38:34.988771400+00:00","source":"code_watch:mirror_drift","status":"ignored","title":"daemon-managed-paths.ts mirror not updated after TASK_1818 manifest split - dashboard still classifies dashboard-models.json as daemon state","updated_at":"2026-07-26T22:38:34.988771400+00:00"},{"affected_files":["dashboard/src-tauri/src/features/proposal/manager.rs",".specialist/Heimdall/capability.yaml"],"category":"bug_fix","created_at":"2026-07-26T16:09:56.307953800+00:00","description":"Source: Heimdall commit scan of 7beb1a51 [TASK_1821] (meta-finding: a real TASK_1821 proposal was itself rejected as duplicate, which surfaced this bug).\n\nDEFECT: proposal/manager.rs create_proposal (~line 842) -> source_has_active_proposal (line 907) rejects a proposal as DUPLICATE when ANY existing Pending|Accepted proposal shares a byte-identical `source` string. No time window, no title/affected_files/symbol discrimination — pure source equality (line 910: `p.source.as_deref() == Some(source)`).\n\nHeimdall assigns a CONSTANT source per category (capability.yaml proposal_categories.source_field): performance=code_watch:hotspot, code_quality=code_watch:coupling, bug_fix=code_watch:risk_rune, security=code_watch:security_rune, refactoring=code_watch:dead_code. So AT MOST ONE pending proposal can exist per category for the whole project; every later distinct finding in that category is silently dropped as `duplicate`.\n\nLIVE EVIDENCE: PROP_001 (source=code_watch:risk_rune, Pending, created 2026-03-19) has blocked EVERY risk_rune proposal for 4+ months. My TASK_1821 finding (appendWorkflow rigor gate fail-open, rune_f49e2b06910e45198e06001c798b8bb2) was rejected by it today. capability.yaml intends dedup of the same PROBLEM within 7 days; the code dedups the same CATEGORY forever.\n\nThe cross_project category is already immune because its source encodes problem identity (cortex:cross_project:{module_pair_hash}) — that is the correct pattern the 5 code_watch categories violate.\n\nFIX (pick/combine): (a) Heimdall emits problem-scoped sources, e.g. code_watch:risk_rune:{symbol_id}; (b) source_has_active_proposal also compares affected_files AND applies a 7-day recency window so stale pending proposals stop blocking; (c) GC/expire stale auto-sourced pending proposals. Rune: rune_2398a010354c4b7ca37dd76f67766bd8.","diffs":[],"estimated_hours":1.5,"id":"AXON_dad796f2","metadata":null,"priority":"P1","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:manager_dedup_source_collision","status":"pending","title":"Heimdall proposal dedup is keyed on category source only — silently drops all but the first risk/bug finding","updated_at":null},{"affected_files":[".formation/tools/prompt.js"],"category":"bug_fix","created_at":"2026-07-26T16:10:06.081630300+00:00","description":"Source: Heimdall commit scan of 7beb1a51 [TASK_1821]. TASK_1821 added a rigor:high self-complete prohibition gate in appendWorkflow (.formation/tools/prompt.js ~line 1062): `try { taskRigor = JSON.parse(taskData).rigor || null } catch {}`. This assumes taskData is always a JSON STRING. But the file's own JSDoc (line ~109) contracts taskData as {string|object}, and resolveModules (line ~119, same file) already handles both: `typeof taskData === 'string' ? JSON.parse(taskData) : taskData`. appendWorkflow does not.\n\nNo live bug today: all callers (dispatch.js/headless.js/headless-v2.js/legacy-scheduler.js) feed taskData from loader.js loadTask(), which always returns a STRING (task-api.js `get` emits JSON — verified, carries `rigor` field; legacy YAML/queue emit YAML strings that fail JSON.parse but have no rigor field, so null is harmless). Directional trap: if any future caller passes the parsed-object form the JSDoc permits, JSON.parse(object) throws -> taskRigor=null -> the rigor:high gate silently FAILS OPEN, self-completing exactly the high-rigor cards it exists to protect (the TASK_188 premature-completion class TASK_1821 was built to prevent).\n\nFix (one line, mirror resolveModules): `const parsed = typeof taskData === 'string' ? JSON.parse(taskData) : taskData; taskRigor = parsed?.rigor || null;` (keep inside try/catch). Rune: rune_f49e2b06910e45198e06001c798b8bb2 (linked to design rune rune_6d781a8dc8e449b99c935dcf639bc321).","diffs":[],"estimated_hours":0.20000000298023224,"id":"AXON_a208a905","metadata":null,"priority":"P3","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:appendWorkflow_taskdata_object_failopen","status":"pending","title":"appendWorkflow rigor gate fails open if taskData is an object (defensive parse)","updated_at":null},{"affected_files":[],"category":"code_quality","created_at":"2026-07-26T16:10:41.054250200+00:00","description":"Commit 57b1aa1b (TASK_1821) removed executor self-complete for rigor:high cards on the Formation/headless/serial path: appendWorkflow now replaces the 'task-api.js complete' step with a prohibition note, deferring closure to the dispatcher-side post-complete pipeline. The commit message itself states the residual gap plainly: post-complete's Step 2.5 safety net fires on isVerifiedMergeSuccess(result.git) && !result.taskCompleted — merge success ALONE. Runtime acceptance (~post-complete.js:2130) logs 'VERIFICATION_FAILED — log clearly but do NOT block merge'. Net effect: a rigor:high card whose acceptance criteria FAIL still lands in done/. TASK_1821 moved the close later but did not make it conditional on verification, so the rigor:high promise ('closed after merge + independent verification') is currently half-true: independent verification runs but has no veto. Follow-up change: for rigor:high cards only, make post-complete route VERIFICATION_FAILED to blocked/ (or keep in active/ with a flag) instead of done/ — scoped to rigor:high to avoid destabilizing the default path. Secondary robustness note (same commit): the new rigor extraction is a bare JSON.parse(taskData) whose catch silently disables the guard. loader.js loadTask has two legacy fallbacks (loadTaskFromLegacyYaml, loadTaskFromLegacyQueue) that return raw YAML text, and resolveModules/appendFormationPreamble in the same file use the defensive typeof taskData === 'string' pattern — a future caller passing a parsed object would also silently turn the guard off. Failure mode of the guard is silent-open; consider reusing the shared string|object parse and warn-once on parse failure for rigor:high candidates.","diffs":[],"estimated_hours":null,"id":"AXON_fb489a69","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:task1821_rigor_verify_gate","status":"pending","title":"rigor:high deferral (TASK_1821) lands on a non-gating verifier — post-complete still closes cards on merge success alone","updated_at":null},{"affected_files":[],"category":"bug_fix","created_at":"2026-07-26T16:39:36.106119500+00:00","description":"TASK_1826 (commit 39225b74) fixed gcStaleWorktrees for the wt-* and task_* families in the sibling layout and .formation/worktrees — verified sound, and the 5 real husks will be reclaimed on the next hook firing. But a THIRD pool is structurally uncovered: .claude/worktrees/agent-* holds 21 registered worktrees (~89MB each, ~1.9GB total, created 2026-07-25..26) plus 21 worktree-agent-* branches. Coverage gaps, all verified: (1) .claude/worktrees is not in wtDirs (worktree-create.js:129-132) and 'agent-' is not a recognized name family, so the new GC never examines them. (2) worktree-remove.js only removes the single worktree_path it is handed, and NO worktree-hooks.log exists anywhere in the repo despite both hooks logging unconditionally on every invocation — the WorktreeCreate/Remove hooks have never fired in this project dir (they fire in the prod bundle context where CLAUDE_PROJECT_DIR differs; interactive Claude Code sessions create harness-native agent-* worktrees the hooks never see). (3) Decisive design constraint: naively adding this pool to gcStaleWorktrees would retain 19/21 forever, because their branches fail merge-base --is-ancestor even though every sampled task (TASK_1791/1795/1803/1804) landed on main by content — this project merges agent work via cherry-pick/scoped-checkout, so SHAs are rewritten and even patch-id equivalence (git cherry) is only partial (e.g. worktree-agent-a047bed8: 0/2 patch-equivalent yet TASK_1804 is on main as c57ba623). Reclaim policy for this pool therefore needs one of: (a) content-aware equivalence (git cherry/patch-id) as a weaker secondary signal plus age, (b) task-completion cross-check (branch's [TASK_XXXX] subjects vs main log / task-api done state), or (c) root-causing why WorktreeRemove never fires for interactive-session agent worktrees and fixing that upstream so the pool stops growing. Same disease TASK_1826 cured, one pool over; per-branch triage before any deletion, mirroring the husk audit discipline of TASK_1826.","diffs":[],"estimated_hours":null,"id":"AXON_3e937c6d","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:commit_39225b74:worktree_gc_coverage","status":"pending","title":"Third worktree pool .claude/worktrees/agent-* (21 dirs, ~1.9GB) has zero GC coverage — and ancestry-based reclaim cannot work for it","updated_at":null},{"affected_files":[],"category":"bug_fix","created_at":"2026-07-26T19:05:06.747194300+00:00","description":"TASK_1827 (d09c70b3) makes worktree reclaim a 'strict conjunction, no bypass', but one conjunct silently self-disables. In gcStaleWorktrees (.claude/hooks/worktree-create.js), the staleness guard is `if (tip && marker.tip && tip !== marker.tip) keep`. When a ledger entry has tip=null, the guard never fires for ANY current branch state. Null-tip markers are legal and expected: cliMarkLanded explicitly writes tip=null when the branch is already deleted ('marker still valid'), and recordLandedMarker in git-merge.js degrades to tip=null on any rev-parse failure. HAZARD PATH: (1) TASK_X first attempt lands, mark-landed runs after branch cleanup -> ledger entry {branch: task/task_X, tip: null}; (2) task is RE-DISPATCHED (same task id -> same branch name task/task_X, same worktree name task_X — retries are common, see .kenaz/specialist/dispatch_err_181x series); (3) second agent commits work (policy REQUIRES agents to always commit, so clean-porcelain-with-unmerged-commits is the NORMAL abandoned state) and the session dies; (4) after 2h idle, GC finds the stale incarnation-1 marker via byBranch, tip check is skipped (marker.tip null), dirt check passes (all committed), worktree removed AND `git branch -D task/task_X` force-deletes the unverified commits. This is exactly the data-loss direction the card was built to prevent. Note the ledger never expires entries, so the stale-marker window is unbounded. When both tips are present the mismatch guard works and re-dispatch is protected — the hole is ONLY the null-tip case. FIX (one conjunct): if the branch currently EXISTS but marker.tip is null, keep with a diagnostic ('marker predates branch recreation / tip unrecorded — re-run mark-landed to refresh'), i.e. change the guard to `if (tip && (!marker.tip || tip !== marker.tip)) keep`. mark-landed on an existing branch always records the real tip, so the remediation cost is one command, consistent with the card's own remediation pattern.","diffs":[],"estimated_hours":null,"id":"AXON_cfff56d4","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:commit:d09c70b3","status":"pending","title":"GC landed-marker with null tip skips the tip-staleness conjunct — branch-name reuse on re-dispatch can reclaim unverified commits","updated_at":null},{"affected_files":[],"category":"code_quality","created_at":"2026-07-26T19:41:39.510355400+00:00","description":"Commit 3dfaa8b9 (TASK_1827 fix) repaired worktree-create.js after a require.main===module guard silently disabled the WorktreeCreate hook. The root enabling condition is still repo-wide: .claude/settings.json wires 19 hook invocations across 18 distinct hook files as node -e \"require(<file>)\" (lines 11-200), so hook execution is a REQUIRE SIDE-EFFECT and require.main is undefined in that context. Any future addition of the standard CLI idiom `if (require.main === module)` to any of these files reproduces the exact TASK_1827 failure: process exits 0 having done nothing. Failure asymmetry makes this worse for the other 17 files: worktree-create was caught within a day only because the harness validates its stdout (one worktree path); nearly all other wired hooks are advisory/fire-and-forget (lease-touch heartbeats, lease-release, task-bridge, reflex-feedback, handoff-snapshot-*, pulse-before-*, synapse-first-*, fatigue-check, daemon-outbox-hook, turn-context, stream-delta, handoff-staleness) where exit-0-with-no-output IS the success signature — the same guard there means invisible functionality loss (heartbeats stop, pulse injection stops) with zero error surface. Only core-resolve.js is safely guarded because its wiring (settings.json line 51) execFileSync-launches it as a direct script. PROPOSED FIX (minimal, ~30 LOC): a static check (pre-commit or dev/scripts) that parses .claude/settings.json for node -e require(...) hook wirings and flags any referenced hook file containing require.main === module without an accompanying require.main === undefined dispatch branch (the three-way pattern now documented in worktree-create.js:664-679). Secondary latent edge worth one comment: an ESM-entry process importing one of these hook files as a library also sees require.main === undefined and would trigger the hook flow; library consumers must stay CJS require() (current consumers: post-complete/git-merge.js — CJS, safe).","diffs":[],"estimated_hours":null,"id":"AXON_967c4a99","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:hook_entry_contract:3dfaa8b9","status":"pending","title":"Hook entry contract (node -e require side-effect) is implicit and silently breakable repo-wide — TASK_1827 trap class covers 18 more hook files","updated_at":null},{"affected_files":[".specialist/tools/ansuz-boot-fast.js",".formation/tools/post-complete.js",".claude/hooks/handoff-staleness.js",".specialist/tools/phase-gate.js",".claude/hooks/reflex-feedback.js",".kenaz/specialist/daemon-manifest.yaml","dashboard/src/lib/daemon-managed-paths.ts","dashboard/src-tauri/src/infrastructure/http_server/routes/mcp_tools/kenaz.rs"],"category":"bug_fix","created_at":"2026-07-26T19:58:30.201833900+00:00","description":"Commit a05afe7a (TASK_1828) migrated two readers (kenaz.rs tool_ansuz_handoff_snapshot, post-complete.js readLatestHandoff) to select the newest generated_at under .kenaz/specialist/handoffs/. Two gaps remain.\n\n(1) ARCHIVE RACE (new, not acknowledged anywhere): ansuz-boot-fast.js loadMultiSlotHandoffs() (line ~113) ARCHIVES every handoffs/ slot after reading — renameSync into handoff_archive/ with a timestamp suffix. Every Ansuz quick boot therefore empties handoffs/. After a boot, post-complete.js readLatestHandoff finds nothing (it does not consult handoff_archive/), falls back to the legacy singular slot which no longer exists in kenaz-core, and every relay task_completed summary degrades to the generic '[TASK_X] task completed' again — exactly the symptom TASK_1828 fixed, reintroduced in the post-boot window until the next handoff write. The Rust tool is partially shielded by its stage-1 stdout parse; post-complete has no stage 1. Evidence: handoffs/ currently holds 9 slots; a Muninn rune (rune_c0700b72) counted 17 earlier today — the count oscillates because boots drain the directory the new readers now depend on. Fix direction: either boot-fast stops archiving (copy instead of rename, or archive only slots older than N days), or the new readers add handoff_archive/ as a stage between handoffs/ and the legacy slot.\n\n(2) UNDERCOUNTED RESIDUAL READERS: the commit message's 'known remaining stale readers' list omits at least: phase-gate.js:111 ANSUZ_HANDOFF_PATH (active handoff lifecycle — parses and even unlinks the 'corrupted active slot' at ~2227, all against the retired singular file); ansuz-boot-fast.js:77 loadAndArchiveHandoff (legacy branch); daemon-manifest.yaml:64 and daemon-managed-paths.ts:43 (revert-list entries for an untracked file — dead config that misleads, same class the commit itself removed from PRESERVE_WORKING_TREE); build-static.js:250 (harmless exclusion of a nonexistent file). Live false-positive evidence for the acknowledged handoff-staleness.js reader: this very scan session received '⚠️ ISBAR handoff stale' from the UserPromptSubmit hook — it fires on every prompt because the singular file it stat()s (line 21) never exists, and its nudge text still instructs agents to update the retired file. Recommend one card converging the full reader/archival lifecycle on handoffs/ rather than per-file patches.","diffs":[],"estimated_hours":null,"id":"AXON_a42999a6","metadata":null,"priority":"P1","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:task1828_handoff_archive_race","status":"pending","title":"TASK_1828 handoffs/-first readers race boot-fast read-and-archive; residual singular-slot readers exceed the commit's acknowledged list","updated_at":null},{"affected_files":[],"category":"code_quality","created_at":"2026-07-26T22:36:52.609886100+00:00","description":"Heimdall scan of commit ee921153 (TASK_1830). The commit fixed revert-daemon-state.js isManagedByManifest by moving .kenaz/specialist/handoffs/ from state_files to static_paths (the only section that gets an endsWith('/') prefix test there) and correctly mirrored it into daemon-managed-paths.ts STATIC_PATHS (whose DIR_PREFIXES loop, lines 96-98, handles it). But there is a THIRD matcher twin the commit did not touch: .formation/tools/post-complete.js isDaemonManagedPath (L451-467). It matches BOTH getDaemonStateFiles() and getDaemonStaticPaths() with exact includes() (L454); directory semantics come only from a hardcoded prefix list (.tmp/, .formation/state/, .formation/analytics/, .formation/signals/, a .synapse cache regex) that predates the manifest. Trailing-slash manifest entries absent from that hardcoded list are invisible to this classifier — today that is .kenaz/specialist/handoffs/ (moved to static_paths PRECISELY to get prefix semantics) and .formation/.synapse/. Live impact is currently MASKED by two accidents: (1) the verbatim directory entries flow through getDaemonPathsToUnstage/listDaemonManagedPaths into git pathspecs (git diff --cached -- <dir>/, git checkout HEAD -- <dir>/), which prefix-match directories natively, so B10 unstage and pre-merge revert still cover handoffs/ contents; (2) handoffs/ is gitignored (.gitignore:331) so slots rarely appear as tracked churn. The trap: isDaemonManagedPath is exported (post-complete.js:3956) and also drives the staged-path discovery filter (L518); any current or future consumer that STRING-classifies paths (exactly how use-git-status.ts uses the TS twin) silently misclassifies files under these directories as real work. Worse, the TASK_1830 manifest comment says 'only static_paths gets the endsWith(/) prefix test (see revert-daemon-state.js isManagedByManifest)' — a reader will assume all three matchers agree; two do, this one does not. Suggested fix (~4 LOC + 1 test): in post-complete.js isDaemonManagedPath, after the exact includes() check, loop getDaemonStaticPaths() and return true when entry ends with '/' and normalized.startsWith(entry) (same shape as revert-daemon-state.js L105-109); add a post-complete.test.js case asserting isDaemonManagedPath('.kenaz/specialist/handoffs/abc.json') === true. Long-term this is the third argument for the already-documented daemon-filter.js extraction (post-complete.js L274) so one matcher serves all consumers.","diffs":[],"estimated_hours":null,"id":"AXON_4226b26b","metadata":null,"priority":"P3","related_task_id":null,"resolved_at":null,"source":"code_watch:matcher_divergence","status":"pending","title":"post-complete.js isDaemonManagedPath is the third matcher twin and lacks the static_paths trailing-slash prefix test TASK_1830 just fixed elsewhere","updated_at":null},{"affected_files":[],"category":"code_quality","created_at":"2026-07-26T22:38:53.319649300+00:00","description":"Follow-up surfaced while verifying TASK_1823 (commit 5b3fdee6, daemon-managed-paths.ts resync - which is correct and complete: 31/31 state_files + 26/26 static_paths parity). The mirror deliberately covers only state_files + static_paths, but daemon-manifest.yaml now carries a gc_disposable_paths list (TASK_1827) whose entries get GC semantics ONLY - no touching_files filtering. Two of them are git-TRACKED daemon logs that are dirty right now in the working tree and are re-dirtied by daemons continuously: .kenaz/channel_heartbeats.jsonl and .synapse/prediction_resolution_log.jsonl. Because isDaemonManagedPath() does not match them, use-git-status.ts:147/:174 passes them into Yggdrasil touching_files, so every node perpetually reports them and cross-node detectConflicts() sees permanent phantom overlap - the exact TASK_1532 Bug C class the filter exists to prevent. A third case: dashboard/src-tauri/.synapse/memory-shared.json (tracked, dirty) is a cwd-relative daemon dropping (Synapse writing relative to the tauri dev cwd) that the root-relative manifest entry .synapse/memory-shared.json can never match. Suggested root fix, following the 8d9a0182 precedent (untrack per-machine runtime state): git rm --cached + gitignore the three paths - they are machine-local runtime logs, not shared source. Alternative if history retention is wanted: add them to the mirror + manifest static_paths. NOT proposed for .claude/settings.json / ansuz_project_pins.json (also gc_disposable): settings.json holds user-authored permission edits whose dirt SHOULD surface (TASK_1818 lesson).","diffs":[],"estimated_hours":0.5,"id":"AXON_7d28e132","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:daemon_dirt_touching_files","status":"pending","title":"Tracked, perpetually-dirty daemon logs bypass the touching_files filter - persistent cross-node conflict noise","updated_at":null},{"affected_files":[],"category":"code_quality","created_at":"2026-07-27T08:32:55.560064900+00:00","description":"Commit 1017c07f removed kenaz-core JS obfuscation (former build-static.js Step 4), but the two canonical staging-semantics headers still list it as an intentional prod-only difference: (1) dashboard/scripts/sync-kenaz-core.js:14-17 lists prod-only extras as 'kenaz-core.kpkg via encryptBundle(), exportCortexSeed(), JS obfuscation'; (2) dashboard/scripts/kenaz-core-staging.js:11-12 lists build-static extras as 'size report, kpkg encryption, cortex seed export, obfuscation'. These headers are the TASK_1796 single-source documentation of dev/prod staging divergence - an agent reading them will believe prod stage content differs from dev by obfuscation, when the stages now converge on content too. Precedent for cost: rune_88c1cbb0 records a false comment at build-static.js:290 (claiming efe_snapshots untracked) that booby-trapped a later arbitration. Fix is two one-line comment edits removing the obfuscation mention. Verified clean otherwise: OBFUSCATION_CONFIG still consumed by obfuscateServerJs (Step 9, line 447), zero dangling obfuscateKenazCoreJs references in code, _obf_reflex.js measurement artifact already removed.","diffs":[],"estimated_hours":null,"id":"AXON_6df0eddc","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"heimdall:commit_scan:1017c07f","status":"pending","title":"Stale dev/prod-divergence headers still claim kenaz-core JS obfuscation after its removal","updated_at":null},{"affected_files":["dashboard/scripts/sync-version.js","dashboard/package.json","dashboard/src-tauri/tauri.conf.json","dashboard/src-tauri/Cargo.toml","dashboard/src-tauri/Cargo.lock"],"category":"code_quality","created_at":"2026-07-27T09:54:56.833742900+00:00","description":"Commit 17b253d1 manually repaired a version split that was live on the remote: package.json + Cargo.toml at 0.2.212, tauri.conf.json at 0.2.214, shipped artifact at 0.2.219 - no single file was authoritative. Mechanism (dashboard/scripts/sync-version.js): tauri:build runs --bump which increments package.json and rewrites tauri.conf.json + Cargo.toml on disk, but nothing commits or verifies the result; Cargo.lock is only updated by the next cargo build. A partial/lost commit (rune_bc54722b records a scoped checkout eating an uncommitted Cargo.toml bump during TASK_1797/1798 merge) leaves the four sources disagreeing, and --align-from-production only patches package.json when local is BEHIND production, so it cannot heal an internal split. Minimal fix per YAGNI: add a --check mode to sync-version.js that asserts package.json == tauri.conf.json == Cargo.toml (and the kenaz-dashboard entry in Cargo.lock) and exits 1 on mismatch, wired into the release flow or pre-push; alternatively make the release build commit the bump it produces. Without a guard this drift will recur - it already did at least twice (two distinct stale values on remote).","diffs":[],"estimated_hours":null,"id":"AXON_26026783","metadata":null,"priority":"P3","related_task_id":null,"resolved_at":null,"source":"code_watch:commit:17b253d1","status":"pending","title":"sync-version --bump mutates 3 tracked files at build time with no commit/agreement guard - version drift already recurred on remote","updated_at":null},{"affected_files":[".collaboration/core/task-api.js"],"category":"bug_fix","created_at":"2026-07-30T18:31:40.245527900+00:00","description":"Commit 11d3ffdb (TASK_1832) converted the update path's field gates from truthiness to presence (!== null) so empty values clear fields, and made non-clearable identity fields (--title/--priority/--role/--rigor/--complexity) reject an explicit empty value with exit 1. One field was missed: line 3057 still reads `const hours = getArg('--estimated-hours'); if (hours) updates.estimated_hours = parseFloat(hours);`. Consequences: (1) `update --estimated-hours \"\"` exits 0, reports success, and changes nothing — the exact silent-no-op defect class TASK_1832 removed from the other nine fields; (2) any truthy non-numeric value (e.g. `--estimated-hours abc`) writes NaN into the YAML card unguarded — the --args-file path at line 3027 (`if (fH != null) updates.estimated_hours = parseFloat(fH)`) has the same NaN hole and, unlike the CLI path, already accepts '' and would write NaN for it. Suggested fix (one decision + ~4 lines): decide whether estimated_hours is clearable (empty → delete/null the field) or identity-like (empty → add to the reject-loudly loop at line 3040), then gate on !== null and reject Number.isNaN(parsed) with exit 1 on both the CLI and args-file paths.","diffs":[],"estimated_hours":0.5,"id":"AXON_c64c0283","metadata":null,"priority":"P3","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:task1832_estimated_hours_residual","status":"pending","title":"task-api update: --estimated-hours is the one field TASK_1832 left truthiness-gated (silent no-op on empty, NaN on non-numeric)","updated_at":null},{"affected_files":[".formation/tools/forseti-verify.js",".formation/tools/utils.js"],"category":"code_quality","created_at":"2026-07-30T18:55:21.453142200+00:00","description":"TASK_1833 (commit 7970df3b) created utils.dispatchLockPath() as the single source of truth for the dispatch-lock file path, and migrated dispatch.js (serial_lock mode) and formations.js (setupUnitWorktree) to call it. The third call site — forseti-verify.js:714-715 — was NOT migrated: it still computes the path inline as `const projectKey = (projectPath||'default').replace(/[\\\\/:]/g,'_').toLowerCase(); path.join(ROOT,'.formation',`.dispatch-lock-${projectKey}`)` and does not import from ./utils at all.\n\nSEVERITY: latent, not active. Verified byte-identical at this commit, so L1 verify and dispatch currently DO serialize against the same lock file — no live bug. But this is precisely the 'copy-the-check, don't call it' anti-pattern the whole task was written to end. utils.js dispatchLockPath's own docstring flags it: 'byte-compatible with the historical inline computation in forseti-verify.js (line ~714) — if you change it here, forseti-verify must move with it or the two stop excluding each other.' The pattern has recurred twice before (runes eb53038640 / 9fe1bdb57d).\n\nFAILURE MODE: the day dispatchLockPath's formula changes (new separator in projectKey normalization, changed filename prefix, ROOT relocation), forseti-verify's L1 dispatch lock silently stops sharing a lock file with Formation + sub-agent dispatches. L1 verification then runs concurrently with a dispatch writing into the SAME shared working tree, reintroducing the .git/index.lock data loss (measured 2026-07-31) that TASK_1833 exists to prevent. The regression is silent — no error surfaces, the two locks just quietly stop excluding each other.\n\nFIX (~3 lines): add `const { dispatchLockPath } = require('./utils')` to forseti-verify.js and replace lines 714-715 with `const lockFile = dispatchLockPath(projectPath);`. Optional follow-up: migrate forseti's own acquireDispatchLock to utils.tryAcquireDispatchLock for full de-duplication (larger change — forseti's API returns a {release} handle, utils' returns {acquired, holder, broke}).\n\nRune: rune_7b53d10aea0841cbb4ae0a31753f919f (risk, confidence 0.82).","diffs":[],"estimated_hours":0.25,"id":"AXON_792c420e","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:coupling:dispatch_lock_path_forseti","status":"pending","title":"forseti-verify.js retains a 3rd inline copy of the dispatch-lock path formula TASK_1833 consolidated","updated_at":null},{"affected_files":[".formation/tools/dispatch-registry.js",".formation/tools/utils.js",".formation/tools/headless.js"],"category":"bug_fix","created_at":"2026-07-30T19:31:24.118780600+00:00","description":"Commit 7c79ad1e (TASK_1833) unified shared-tree serialization on one lock file (utils.dispatchLockPath -> .formation/.dispatch-lock-<key>) with holder-aware breaking in tryAcquireDispatchLock: stale >60min, dead-pid, corrupted. Sub-agent serial_lock holders are written pid:null BY DESIGN (the dispatch CLI exits immediately; its pid proves nothing about the agent), so they are protected ONLY by the 60min age gate or explicit release after merge.\n\nHOWEVER dispatch-registry.js cleanupStaleLocks (TASK_1391, line 162) deletes the SAME file under a different, stricter authority: `dead || ageMs > 600000` — i.e. ANY lock older than 10 minutes is removed even when the holder is alive (pid:null locks have no liveness signal at all; even live-pid formation locks are age-cleared). It runs at every headless.js dispatch start (line 258, cleanupStaleLocks(projectPath || ROOT)), and its key formula matches dispatchLockPath for sub-project paths — same file.\n\nResurrection scenario: (1) Ansuz sub-agent dispatch to a use_worktree:false project (e.g. Unity) acquires serial_lock, pid:null; agent works in the shared tree. (2) >10min later a Formation/headless dispatch targets the same project. (3) cleanupStaleLocks deletes the live lock; setupUnitWorktree acquires a fresh one. (4) Two writers in one shared tree — exactly the index.lock silent-loss hazard TASK_1833 measured at ~25% and fixed. The formations.js comment claims 'Formation and sub-agent dispatches against the same project serialize against EACH OTHER'; cleanupStaleLocks breaks precisely that property. This is the 4th instance of the sibling-path-diverges-from-guard family (rune_eb53038640e246dea32764f89b18bfa1, rune_9fe1bdb57d834750ac443b1d7f09e965).\n\nSuggested fix direction: make cleanupStaleLocks defer to the same authority — share one constant + holder-aware staleness from utils (pid:null locks only cleared at >=60min; live-pid locks never age-cleared while alive), or simply have it call tryAcquireDispatchLock semantics instead of its own age check. Secondary inconsistencies to fold in: (a) dispatchLockPath(null) uses key 'default' while cleanupStaleLocks derives the core key from ROOT — core '.dispatch-lock-default' is never cleaned (safe direction, but dead code path); (b) serial_lock release on the sub-agent path is convention-only (Ansuz must delete the surfaced lockFile after merge — no machinery in post-complete does it), so a forgotten release blocks the project's next dispatch up to 60min.","diffs":[],"estimated_hours":null,"id":"AXON_c5f43916","metadata":null,"priority":"P1","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:dispatch_lock_ttl_authority_split","status":"pending","title":"Dispatch-lock authority split: cleanupStaleLocks clears LIVE locks at 10min, undermining TASK_1833's 60min serialization guarantee","updated_at":null},{"affected_files":[],"category":"code_quality","created_at":"2026-07-30T19:44:06.342259300+00:00","description":"Measured 2026-07-31 (Heimdall, commit 4440aa1c scan): 14 stale-session wt-<sid8>-<pid> worktrees (10 from one 2026-07-26 session, wt-e989b14a-*) remain registered with distinct unmerged heads, even though gcStaleWorktrees runs on EVERY WorktreeCreate hook invocation (worktree-create.js:526) and ran again this session. Root cause: GC only reclaims trees whose branch is main-ancestor or has a landed marker, but the sub-agent merge flow (Ansuz scoped-checkout/cherry-pick, SHA-rewriting) never calls the mark-landed CLI - it is convention-only, and nothing in post-complete or the merge helpers writes appendLandedMarker for this path. Landed work is therefore indistinguishable from unmerged work and GC correctly keeps everything, forever. Same convention-only-release defect family as the serial_lock release gap (rune_0c289daf) - 5th instance of guard-exists-but-sibling-path-never-invokes-it. Proposed fix: the scoped-checkout merge/verification flow should call worktree-create.js mark-landed (or git-merge.js appendLandedMarker) for the source branch after content-verified landing; alternatively GC could adopt the content-aware landing check already prescribed for the agent-* pool (AXON_3e937c6d - related but distinct family, that pool is outside wtDirs entirely). Evidence trail: rune_6685f07e57c84310829a2d638263e1a9.","diffs":[],"estimated_hours":null,"id":"AXON_a1286274","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:worktree_gc_gap","status":"pending","title":"Sub-agent merge path never records landed markers - wt-* worktrees accumulate despite GC firing","updated_at":null},{"affected_files":[],"category":"refactoring","created_at":"2026-07-30T19:44:41.308464100+00:00","description":"TASK_1838 unified the dispatch-lock staleness verdict into utils.dispatchLockStaleness (constant DISPATCH_LOCK_STALE_MS=60min), consumed by BOTH tryAcquireDispatchLock and dispatch-registry.cleanupStaleLocks, and both are now EXPORTED. forseti-verify.js is the LAST site still inlining the shared logic on the SAME lock file, and it imports neither: (1) path at ~L715 recomputes .dispatch-lock-<key> inline instead of utils.dispatchLockPath(projectPath); (2) acquireDispatchLock at ~L203 hard-codes `age > 3_600_000` + dead-pid, a 4th inline copy of dispatchLockStaleness (whose docstring forbids a second inline threshold). Byte-identical TODAY = NO active bug, but LATENT: if dispatchLockPath's formula or DISPATCH_LOCK_STALE_MS changes, forseti's L1 verify lock silently stops excluding Formation + sub-agent dispatches on the shared working tree, reopening the .git/index.lock silent data-loss (~25%, measured 2026-07-31) TASK_1833/1838 exist to prevent. FIX (~4 lines): `const { dispatchLockPath, dispatchLockStaleness } = require('./utils')`; use dispatchLockPath(projectPath) at ~L715 and dispatchLockStaleness(holder) at ~L203. Ref runes: rune_fbf899b2 (TASK_1838 fix), rune_7b53d10a-superseded (now broadened). Low priority: latent, not active.","diffs":[],"estimated_hours":null,"id":"AXON_3fa34f42","metadata":null,"priority":"P3","related_task_id":null,"resolved_at":null,"source":"code_watch:copy_the_check:forseti_dispatch_lock","status":"pending","title":"Migrate forseti-verify.js to shared dispatch-lock primitives (last copy-the-check leg)","updated_at":null},{"affected_files":[".formation/tools/dispatch-registry.js",".formation/tools/integration.js"],"category":"bug_fix","created_at":"2026-07-30T19:50:27.662410200+00:00","description":"Heimdall commit scan of 5a3c9473 (TASK_1838). The dispatch-lock TTL-authority split was fixed, but the merge-lock arm carries the same shape: cleanupStaleLocks ages .merge-lock by acquiredAt||startedAt (never refreshed) and ignores heartbeat_at, while integration.js heartbeatAgeMs reads heartbeat_at||acquiredAt and its takeover rule requires pid-dead AND heartbeat-stale (C.1: never force-acquire a live lock). A live integration merge holding the lock >10min with alive pid and fresh heartbeats is unlinked by any concurrent dispatch start (dead=false, ageMs>maxAgeMs suffices) - the next wx-create acquirer then runs a second main-advancing merge concurrently (index-corruption class C.1). One-line fix in dispatch-registry.js cleanupStaleLocks merge-lock arm: read data.heartbeat_at || data.acquiredAt || data.startedAt, aligning field priority with heartbeatAgeMs; legacy post-complete locks (no heartbeat_at) keep identical semantics. NOTE: the commit message out-of-scope claim (integration.js writes heartbeat_at only / always-expired) is FALSE - integration.js:105 writes acquiredAt; do not chase that phantom. Evidence rune: rune_8a2682bd2adf45e4b79df44f08aeda14. Severity MEDIUM: >10min merge holds are rare and acquireMergeLock already soft-breaks at 60s timeout.","diffs":[],"estimated_hours":0.5,"id":"AXON_628f0867","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:merge_lock_heartbeat_ignored","status":"pending","title":"cleanupStaleLocks merge-lock arm ignores heartbeat_at - can unlink a live integration merge lock at >10min","updated_at":null},{"affected_files":[".formation/tools/utils.js"],"category":"code_quality","created_at":"2026-07-31T13:41:32.446418600+00:00","description":"Commit cb5f615e (TASK_1833) widened resolveWorktreeDecision source union to dispatch-param|env|project-config|default, with default documented as: no lever fired - the project never chose worktree mode (the case Unity-style projects most need to SEE).\n\nResidual gap: readWorktreeConfig (utils.js:234) only tests /^use_worktree:[space]*false/m; the project-config label is set exclusively inside that false branch (utils.js:242). A project.yaml that EXPLICITLY declares use_worktree: true therefore reports source=default - telling the operator the project never chose worktree mode when it explicitly did. Same misattribution class the commit fixed, inverted: instead of env-attributed-to-yaml, it is yaml-attributed-to-nobody.\n\nBehavioral impact: none (useWorktree value is correct; no consumer branches on source - verified dispatch.js:402 resolveDispatchIsolation, dispatch.js isolation metadata pass-through, formations.js:1065 print-only). Diagnostic impact: the default label is not trustworthy as a nobody-chose-this signal, which was the commit stated reason for adding it.\n\nFix is one branch: also match /^use_worktree:[space]*true/m and set useWorktreeSource=project-config (value already defaults true, so only the label changes).\n\nSecondary: the four-label matrix was verified live against a throwaway repo but has zero durable test coverage (no test in .formation/tools/__tests__ references use_worktree or the source labels); a table test over {yaml absent, yaml true, yaml false, env true, env false, override} would pin both this fix and the landed one.","diffs":[],"estimated_hours":0.5,"id":"AXON_ba11feb2","metadata":null,"priority":"P3","related_task_id":null,"resolved_at":null,"source":"code_watch:commit:cb5f615e:worktree_provenance_residual","status":"pending","title":"readWorktreeConfig: explicit use_worktree:true is labeled 'default' - inverted residual of the TASK_1833 provenance fix","updated_at":null},{"affected_files":[".collaboration/core/task-api.js"],"category":"bug_fix","created_at":"2026-08-03T05:48:02.351521800+00:00","description":"Commit fc7e0944 (TASK_1843) fixed _loadTaskFile's status resolution by walking the ancestor dir chain, because basename(dirname(filePath)) yields 'TASK_XXX' for directory-layout cards (active/TASK_XXX/TASK_XXX.yaml) and poisoned _status_dir. Heimdall commit scan found ONE residual instance of the same pattern: .collaboration/core/task-api.js line ~1545, updateTask same-status branch sets updatedTask._status_dir = path.basename(path.dirname(filePath)). For directory-layout cards, updateTask's RETURN VALUE carries _status_dir='TASK_XXX', now inconsistent with getTask (which returns 'active' via the fixed path). Current blast radius is LOW - persisted YAML is clean and all known _status_dir consumers (post-complete.js GC/reconcile, fake-stream.js) read via getTask - but any caller trusting updateTask's return (e.g. CLI update JSON output) inherits the poisoned field. Proposed fix: extract the TASK_1843 ancestor-walk into a shared helper used by both _loadTaskFile and updateTask (no duplicate parallel impls). Evidence: synapse_pulse on _loadTaskFile (3 runes), repo-wide grep for the pattern (single residual hit), risk rune rune_9fa7db416fe74d14a65895fd26361188 inscribed on updateTask.","diffs":[],"estimated_hours":0.5,"id":"AXON_9f42a4d4","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":"2026-08-03T13:59:54.015384500+00:00","source":"code_watch:risk_rune:task1843_updatetask_status_dir_residual","status":"ignored","title":"task-api updateTask still uses direct-parent _status_dir derivation (residual of TASK_1843 bug class)","updated_at":"2026-08-03T13:59:54.015384500+00:00"},{"affected_files":[],"category":"bug_fix","created_at":"2026-08-03T14:00:08.007282500+00:00","description":"Commit 67eeb1ae (TASK_1846) closed the updateTask write-path _status_dir bug and declared moveTask correct. moveTask _status_dir=targetDir IS correct, but two adjacent directory-layout gaps remain unclaimed: (1) FLATTENING: newFilePath=join(tasksDir,targetDir,basename(oldFilePath)) (line ~1630) moves only the YAML of a directory-layout card (active/TASK_X/TASK_X.yaml -> flat done/TASK_X.yaml), orphaning the old card directory and any sibling artifacts. (2) SWEEP BLIND SPOT: the Step-4 anti-resurrection sweep (lines ~1655-1667) unlinks only flat dir/fileName paths; a git-restored directory-layout copy survives, and post-TASK_1843 the two copies report conflicting directory-derived statuses -- the dual-truth state the sweep exists to prevent. Latent today (0 directory-layout cards in core .kenaz/tasks) but the layout demonstrably occurs (TASK_1843 was triggered by a real card via kenaz_dispatch_status). Suggested fix: reuse _resolveStatusDirName in moveTask, relocate the whole card directory (or at minimum sweep dir/TASK_ID/ variants in Step 4). Evidence: risk rune rune_b32d5da6e25344de9cd5e41de6c764fd on moveTask; fix-chain runes 4e369456/9fff0d90/cd7bb75d; note prior sibling proposal AXON_9f42a4d4 (updateTask residual) was implemented by TASK_1846 and closed.","diffs":[],"estimated_hours":null,"id":"AXON_7a4fdc4e","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:task1846_movetask_dirlayout_residual","status":"pending","title":"moveTask directory-layout gaps: card flattening + residual-sweep blind spot (TASK_1843/1846 family, third callsite)","updated_at":null},{"affected_files":[],"category":"bug_fix","created_at":"2026-08-03T14:45:59.919221200+00:00","description":"Commit 57af18f9 ([TASK_1850] task completed) adds heimdall_notify() to .githooks/post-commit and documents the ownership decision, but two activation steps are missing, so the entire fix is a no-op. (1) The commit exists only on worktree branch ansuz-wt-7e3f9ccc-5080 - main HEAD is f20e7803 and does not contain it. (2) core.hooksPath in the main repo still points at the absolute .git/hooks path (explicitly set), so even after merge the tracked .githooks/post-commit stays inert. Evidence: the active .git/hooks/post-commit (norn-hook v2, 2026-06-17) contains the Heimdall trigger but ZERO references to predict-neighborhood or reflex_reconcile; .synapse/prediction_feed_state.json last_called_ms is frozen at 2026-07-25 02:55 - the exact starvation TASK_1848 diagnosed and TASK_1850 was built to fix. Required actions, in order: (a) land ansuz-wt-7e3f9ccc-5080 onto main via Formation Lead flow, (b) in the MAIN repo (not a worktree) run: git config core.hooksPath .githooks, (c) verify the next commit advances prediction_feed_state.json. The task decision rune (rune_9c21b685) itself warned the flip must be done in the main repo - this proposal is that missing step surfacing as work.","diffs":[],"estimated_hours":null,"id":"AXON_cfc02b23","metadata":null,"priority":"P1","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:57af18f9","status":"pending","title":"TASK_1850 hook consolidation is inert: commit stranded on worktree branch, core.hooksPath never flipped - prediction feed still starving","updated_at":null},{"affected_files":[".specialist/Ansuz/tools/reflex_executor.js"],"category":"bug_fix","created_at":"2026-08-03T14:57:08.961588900+00:00","description":"Residual defect in the TASK_1849 fix (commit 1043a40c5, reflex_executor.js). _deriveSymbols keys candidates by file path and MERGES line_ranges from all tools into one union per file: a Read with offset contributes a window [offset, offset+limit||2000] (up to 2000 lines, uncapped by actual file length), while Edit contributes exact ranges from locating new_string. resolveFilePath then intersects the UNION against Symbol.start_line/end_line and ranks narrowest-symbol-first under MAX_STIM_SYMBOLS=5. Consequence: when a turn Reads a file with offset and then Edits it — the dominant tool pattern, since Edit requires a prior Read — small bystander symbols anywhere inside the Read window can crowd the edited symbol out of the top-5, and read-window bystanders enter resolved_symbols as full symbol identity (file_level:false), feeding both thalamus_stimulate and P3 exact attribution. This partially reintroduces the imprecision class TASK_1849 was fixing, in weaker form (attended-but-not-edited symbols instead of arbitrary file-head symbols). The commit's verification probes were Edit-only synthetic turns and never exercised the Read+Edit merge path. Suggested fix: evidence-strength tiering — when a candidate has Edit-derived ranges, drop Read-window ranges for that candidate (or track ranges per evidence class and only grant symbol identity from edit-class ranges); also cap the Read default window at the file's real line count.","diffs":[],"estimated_hours":null,"id":"AXON_cc7be5ef","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:reflex_executor_read_window_dilution","status":"pending","title":"Reflex resolution: Read offset windows merge into Edit line ranges and dilute symbol precision","updated_at":null},{"affected_files":["dashboard/src-tauri/src/features/synapse/connection/mod.rs","dashboard/src-tauri/src/lib.rs","dashboard/src-tauri/src/infrastructure/http_server/routes/"],"category":"bug_fix","created_at":"2026-08-03T16:03:56.975544400+00:00","description":"Commit 36a69e10d (TASK_1852) added pub fn evicting_keys() and pub fn clear_evicting() in synapse/connection/mod.rs as the non-restart recovery for a wedged evicting flag (the 2026-08-03 outage). Verified by grep: outside tests and doc comments, evicting_keys() is only called inside an eprintln! in lib.rs:2600, and clear_evicting() has ZERO callers — no Tauri command, no HTTP route, no MCP tool wires either one. Both log messages (connection/mod.rs:1081, lib.rs:2598) instruct the operator to recover via clear_evicting(), but a pub Rust fn in a running process cannot be invoked from outside; actual recovery for a wedged flag is therefore still a Dashboard restart. The observe half is partially served by the escalation log, but only after a 5-min backoff and only on stderr. Suggested fix (small): expose both through an existing runtime surface — a GET/POST pair under /api/synapse/ (pool-status / pool-clear-evicting) or fold them into the synapse_maintain MCP tool. The safety caveat in the clear_evicting doc (never clear a live Phase-2 drain) must travel with the endpoint, e.g. require the key to have been continuously flagged for N minutes before allowing the clear.","diffs":[],"estimated_hours":2.0,"id":"AXON_a2d17ce3","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:risk_rune:clear_evicting_unreachable","status":"pending","title":"clear_evicting()/evicting_keys() have no runtime call path — the logged recovery hint points at an uncallable function","updated_at":null},{"affected_files":["dashboard/src-tauri/src/features/proposal/manager.rs",".specialist/Heimdall/capability.yaml","dev/pipeline/OPTIMIZATION_PROPOSALS.json"],"category":"bug_fix","created_at":"2026-08-03T16:04:24.924375700+00:00","description":"Measured live 2026-08-04 by Heimdall itself: POST /api/proposals/create with source=code_watch:risk_rune returned DUPLICATE because PROP_001 (created 2026-03-19, still pending in dev/pipeline/OPTIMIZATION_PROPOSALS.json) occupies that exact source key. source_has_active_proposal (features/proposal/manager.rs:844 async, :1018 sync) blocks any new proposal whose source string equals a Pending/Accepted one, with no time bound — but .specialist/Heimdall/capability.yaml documents the dedup as 7 days. The proposal GC (expire at RETENTION_DAYS) did not expire PROP_001. Net effect: every Heimdall commit-scan since March that used the documented generic source keys (code_watch:risk_rune etc.) had its proposal silently dropped as duplicate; the agent sees only the string duplicate with no pointer to the blocker. Fixes, either or both: (1) make dedup time-bounded to match the documented 7-day window, or ensure GC actually expires stale pending proposals in this file; (2) update Heimdall capability.yaml to mandate problem-specific source keys (code_watch:risk_rune:{slug}), matching the cortex:cross_project:{hash} pattern already in use. Also worth triaging PROP_001 itself (dual Heimdall trigger dedup) — pending since March.","diffs":[],"estimated_hours":1.5,"id":"AXON_4fa0d93e","metadata":null,"priority":"P2","related_task_id":null,"resolved_at":null,"source":"code_watch:proposal_dedup_unbounded","status":"pending","title":"Proposal dedup is unbounded-while-pending on exact source key — one stale March proposal has silently blocked all code_watch:risk_rune proposals for 4.5 months","updated_at":null},{"affected_files":[],"category":"bug_fix","created_at":"2026-08-12T14:27:27.311204600+00:00","description":"Commit ac3b7d586 claims 'When ON: outcome_component = surprise x novelty_weight' but the multiplication does not exist anywhere. Evidence: (1) reflex_reconcile.js:286 writes outcome_component_shadow: weightedMean (raw, unweighted) with novelty_weight:292 as a SIBLING field that nothing consumes; (2) reflex_reward.js _loadOutcomeComponentShadow returns row.outcome_component_shadow directly and never reads row.novelty_weight. Consequence: the day the flag flips ON, live health_delta receives raw surprise with zero novelty gating - the exact Goodhart exposure requirement (B) was built to prevent. All 5 new unit tests assert gate-OFF behavior only, so the sole path that matters (ON) is untested and the defect is invisible to the suite. This also invalidates the planned Phase-2 A/B: the 'staged' treatment arm would test an ungated mapping, not the fork-A design. Fix is one line in either file (multiply weightedMean * novelty_weight into outcome_component_shadow at write time, OR apply row.novelty_weight at read time in the loader - pick ONE side to avoid double-application) plus at least one gate-ON test with a temp shadow fixture verifying a stale turn (novelty_weight 0.5) yields half the component of a novel turn. Positive note worth keeping: the loader scans from end-of-file (keep-last), which correctly handles the known --reset duplicate-turn_id trap from rune_11c13fb0. Secondary validity caveat: rune_11c13fb0 measured the A/B gate as structurally pinned at effective n=3.4 (5 resolution clusters); TASK_1848 is completed but before running Phase 2, verify its lever actually raised CLUSTER count, else the A/B answers 'no difference' for every mapping and passing it is not evidence.","diffs":[],"estimated_hours":null,"id":"AXON_c8c8d0ee","metadata":null,"priority":"P1","related_task_id":null,"resolved_at":null,"source":"code_watch:commit:ac3b7d586","status":"pending","title":"TASK_1684 fork-A latent defect: novelty_weight is written but never applied - flipping OUTCOME_COMPONENT_GATE injects UN-gated surprise, the Goodhart guard is decorative","updated_at":null}],"statistics":{"accepted":0,"expired":0,"ignored":4,"pending":40,"total":44},"total":44}}