kenaz 0.3.22 → 0.3.24

package/core/dev/FREYA_DOWNSTREAM_BUGS_2026-09-19.md

@@ -1,44 +0,0 @@
-# Freya 下游 BUG 回饋處理
-
-回饋日期：2026-09-19。調查日期：2026-09-20（Asia/Taipei）。本文件記錄開發工作樹的驗證，不代表已發布安裝版或 Freya 現場已恢復。
-
-任務卡依本 session 指示放在 quotation；實際修改為 KenazAI core，不修改 quotation 應用程式。Jev 因供應商 waitlist 暫不進行實測。
-
-## 原始回饋與查證
-
-| 回饋 | 當前程式證據 | 處理 |
-| --- | --- | --- |
-| [Synapse wedge 與 full reindex 逾時](https://drive.google.com/file/d/1ftZatRH5PeYvhJIgtpiZ8_pcXjORJuOP/view) | connection::with_connection 每次建立獨立寫入 connection，沒有同 DB writer 排他；index::save_failed_state 對所有錯誤累加失敗；MCP tool_synapse_index 等待完整 spawn_blocking。 | TASK_29 處理寫入競爭與可查詢索引工作；TASK_31 處理 post-complete 失敗。尚Rust 驗證通過，詳見下方。 |
-| [stale stream lease 累積](https://drive.google.com/file/d/1TAFYQ2OdAdgarERj6p7LOKCWKdBnQcoB/view) | 已有批次 reap（24h）及定點 reap（8h liveness），但 register 不自動清理。boot 已支援明確 conversation-id 或 transcript basename。 | TASK_28 在 register 保守清理超過 24h 的 stale lease；保留當前、恢復中、live、時間不明的 lease。缺真實 conversation-id 的警告保留。 |
-| [dispatch subagent 契約不一致](https://drive.google.com/file/d/1pzHa-KrWvIeKhDIg6d8oy7bgDHk31ph9/view) | elixir 指令漏 --skill；promptText 與 isolation 刻意放頂層，不能整包當 Agent 工具參數。model translation 已走 stderr，但 resource lock 訊息仍走 stdout，ignore helper 不在 stderr 保護區。 | TASK_28 補齊 stdout 純 JSON；TASK_30 修指令及欄位解讀，保留既有 isolation 和 modelTranslation 契約。 |
-| [task-api create 旗標與品質門檻](https://drive.google.com/file/d/1A2E_P3YHQDx3cXqxeLYzxPc3IjNKvTXS/view) | help 仍暗示單旗標接受多值；實際要重複旗標；--args-file 已實作。 | TASK_28 修 help，明列 requirements/acceptance/technical notes 最少 3/3/2 條及 JSON 檔案用法，未更換 parser。 |
-
-## 重要判讀
-
-TASK_1959 已在目前 HEAD（45b0136da）合併：server 收到 inscribe 後可將受阻寫入保存在 spool，且 busy gate 改為 per-project。這不代表交易衝突根因已修，也不能保護尚未送達 server 的 HTTP 請求。
-
-13 次 socket hang up 不能直接稱為 13 次重試。cognitive.js 的 triggerPassiveRuneExtraction 對 changed files（上限 20）逐檔 fire-and-forget；目前回應 body 直接丟棄。milestone.js 則把預篩 parse/error/timeout 與正常空集合都轉成 []，讓失敗也觸發 unfiltered generalize。TASK_31 分開處理這兩種狀態。
-
-進一步查證顯示 /temporal/replay-episodes 沒有在 temporal.rs 註冊，GeneralizeRequest 也沒有接收 preFilterClusters。generalize_inner 仍查舊的 project/.synapse 圖位置，查詢失敗轉為空結果；目前已有 SQLite get_episode_symbol_lists 可取相同用途的 episode-symbol 資料。TASK_32 負責補路由、傳遞失敗及讓 filter 實際作用，不只修改 client 的錯誤訊息。
-
-stream lease 不以「程序 PID 仍存在」作唯一存活證據；原本 8h heartbeat 規則保留。自动回收採既有 24h 門檻並在刪除前重讀。此重讀不是跨程序原子 compare-and-delete，仍存在極小讀刪間隙；未宣稱完全消除競爭。沒有在本次測試刪除真實 lease，也不在缺 identity 時臆造 conversation-id 或跳過安全註冊。
-
-dispatchMode 缺省仍維持既有 formation 相容行為，不強制改成 auto。回饋只證明下游檔案缺鍵，不能據此覆寫使用者路由策略。
-
-## 驗證紀錄
-
-TASK_29 的新 MCP 契約：synapse_index 預設最多等待 1000ms，可用 wait_ms 0–5000 調整；快速完成保留既有 status=ok 與統計欄位，長工作回 status=accepted 與 job_id。以相同 projectPath 呼叫 synapse_status 並帶 job_id 可查 running/succeeded/failed、進度與結果，不需要開啟圖資料庫。相同專案與選項的工作尚在執行時，重複提交會回現有工作；不同選項須先確認既有工作結果。工作歷史只保留本程序最近 64 件，Dashboard 重啟後不保留，不能宣稱為持久化 job queue。
-
-TASK_32 在開啟 memory.db 前要求專案目錄與資料庫檔案已存在，錯誤不建立空資料庫來假裝成功。既有 MemoryDb::open 仍可能執行 schema/startup 維護，這不是新增的唯讀 connection。generalize 改讀 SQLite episode symbols，並依每個 cluster 的 episode-symbol 配對篩選；省略 preFilterClusters 保留手動無篩選行為，明確傳 [] 則選不到任何資料。JS 健康空 replay 仍省略此欄位，保留既有空集合行為。
-
-- TASK_28 新增隔離測試：6/6；主代理獨立重跑通過。
-- 主代理另獨立重跑 subagent-bifrost-guard 41、boot-lease-reuse 7、m1-claim-gate 16、m1-hmap-convid 56，全部通過。合計 126 項 assertions/checks；其中四個舊套件各自彙總，並非 node:test 顯示 126 個 test cases。
-- elixir.yaml 經 js-yaml 解析成功，--skill=do 與 promptText 指引檢查通過。
-- TASK_31：主代理獨立執行 bounded-http.test.js，16/16 通過。批次逐筆送出、總期限 10 秒、回應上限 1MB；首次失敗停止，單一摘要區分 successful/spooled/failed/skipped。HTTP 200 不等於写入成功。預篩失敗回 null 並跳過 generalize，健康空集合 [] 保留原有行為。
-- TASK_31 範圍限 passive extraction 與 milestone；主 post-complete.js 的其他 inline fan-out 未改。主函式仍同步、背景請求保留既有生命週期；強制 process.exit 可截斷。未送出的寫入沒有 durable client spool，回應遺失亦可能是完成狀態未知，不能宣稱資料零遺失。
-- TASK_29 / TASK_32：Rust 編譯與連結成功。透過既有 dev/scripts/run-rust-tests.js 補上 Windows Common Controls manifest，以 CARGO_TARGET_DIR=C:/t/kenaz-verify 避開執行中 tauri dev 的 DLL 鎖；不修改正式 DLL 或系統設定。
-- 主代理獨立執行測試程式：replay_ 8、writer_ 6、index_jobs_ 3、index_admission_precedes_destructive_rebuild 1、connection::tests 29、index::tests 50、memory::tests 61，全部通過。扣除重複的兩項 index 測試，共 156 項不重複 Rust 測試；JavaScript 共 142 項檢查。不是全庫測試，也不是安裝版現場驗收。
-- 真實 Kuzu 暫存資料庫已重現第二個寫入交易遭拒，第一個 rollback 後第二個可成功；Windows 可能將原始文字包成 native exception，正式分類器仍不將所有原生例外視為暫時競爭。排隊、其他資料庫與讀取的獨立性、錯誤釋放、工作去重與失敗查詢、實際 HTTP router、非空 SQLite 資料的篩選效果均有通過測試。
-- 後續項目：既有 release_project 保留 local Arc 至 close_db 返回，會使 idle release 等待 drain timeout；connection 套件此次耗時 34.76 秒。本次沒有修改該生命週期，應另行驗證並修復。全工作區 diff check 另發現 .synapse/turn_outcome_shadow.jsonl 有既有衝突標記；本次修改範圍的 diff check 通過，未改該狀態檔。
-
-所有變更尚未 commit/merge、未打包或發布。Freya 的安裝版本、現場日誌與更新後重現結果尚未取得，因此不將現場 bug 標成已關閉。

package/core/dev/GLOBAL_MEMORY_IDENTITY_CONSOLIDATION.md

@@ -1,263 +0,0 @@
-# Global Memory Identity Consolidation (TASK_2050)
-
-Phase 1 only: root cause, the writer fix, a dry-run-capable migration
-function, and real numbers computed against a disposable copy of this
-machine's `~/.kenaz/cortex/global_memory.db`. The migration's non-dry-run
-path is implemented but **not executed** by this task and **not wired to
-any caller**.
-
-## Symptom
-
-`global_runes.project_id` / `project_name` (read-only `GROUP BY` over the
-live DB) showed the same repo registered under up to 8 different
-identities. Top rows for this repo alone:
-
-| project_id | project_name | rune rows |
-|---|---|---|
-| `proj_1776613204237_0p34i5y` | KenazAI | 7320 |
-| `unregistered_C___Users__user__Documents__GitHub__KenazAI` | KenazAI | 6431 |
-| `default` | Kenaz | 6378 |
-| `unregistered_C__Users_user_Documents_GitHub_KenazAI` | KenazAI | 3430 |
-| `proj_1775750941226_3f6dcn8` | KenazAI | 3407 |
-| `unregistered_..._.formation_worktrees_task_task_1065` | task_task_1065 | 2194 |
-| `unregistered_..._.formation_worktrees_task_task_962` | task_task_962 | 2012 |
-| `proj_1774545608638_gyvs5lz` | KenazAI | 1998 |
-| `unregistered__c_Users_user_Documents_GitHub_KenazAI` | KenazAI | 6 |
-| `unregistered_..._KenazAI_dashboard` | dashboard | 5 |
-
-CognitiveLabs (a different, smaller sub-project) carried the same pattern
-in miniature: `proj_1775339532602_0kcmwhf` (290 rows) and
-`unregistered_C__Users_user_Documents_GitHub_CognitiveLabs` (6 rows).
-
-## Root cause
-
-Three independent bugs compound into this, all in
-`dashboard/src-tauri/src/features/cortex/`:
-
-**1. The `unregistered_*` id was minted from the raw path string, not a
-normalized one.**
-`sync.rs::find_project_by_path` (pre-TASK_2050, the fallback branch at the
-end of the function) did:
-
-```rust
-id: format!("unregistered_{}", path_str.replace(['/', '\\', ':'], "_"))
-```
-
-`path_str` is `project_path.to_string_lossy()` — the caller's path,
-verbatim. This has no case-folding and no slash-direction normalization,
-so the SAME filesystem path produces a DIFFERENT id depending on:
-- slash direction (`C:/Users/...` vs `C:\Users\...`) — both map to
-  underscores, but a path that had already been through one JSON
-  encode/decode round-trip without un-escaping (`\\` as two literal
-  backslash characters) produces DOUBLE underscores where a clean path
-  produces one — this is the `unregistered_C___Users__...` vs
-  `unregistered_C__Users_...` split above.
-- drive-letter case (`C:` vs `c:`) — `unregistered__c_Users_...` (note the
-  leading underscore from the lone lowercase `c` before the colon-turned-
-  underscore).
-
-**2. No notion of "repo root."**
-Every subdirectory or worktree ever passed as `project_path` minted its
-OWN `unregistered_<path>` id instead of resolving to the repo it lives
-under. This machine's history shows three distinct worktree/subdir shapes,
-none collapsed:
-- `<repo>/.formation/worktrees/<name>` (Formation dispatch worktrees)
-- `<repo>/.claude_worktrees/<name>` (Claude Code worktree agents)
-- `<parent>/.kenaz-worktrees/<repo-name>/<wt-name>` (sibling-style
-  worktrees — **this is this very session's own working directory**:
-  `C:/Users/user/Documents/GitHub/.kenaz-worktrees/KenazAI/wt-0722c428-36164`)
-- a bare subdirectory (`.../KenazAI/dashboard`)
-
-Each of these synced independently at some point and each minted its own
-`unregistered_*` id.
-
-**3. `registry.rs`/`projects.json` never deduped re-registrations by
-path.** `proj_1774545608638_gyvs5lz` and `proj_1775750941226_3f6dcn8` (both
-labeled "KenazAI" in `global_runes`, 1998 and 3407 rows) are **not** in the
-current `~/.kenaz/projects.json` at all — they're leftovers from earlier
-registration cycles that got deregistered and re-registered under a fresh
-`proj_*` id each time (the CURRENT registration is
-`proj_1776613204237_0p34i5y`). `registry.rs::find_project_path_by_id`
-(`dashboard/src-tauri/src/features/cortex/registry.rs:108`) simply has no
-entry for a stale id and returns `None` — nothing before TASK_2050
-resolved that back to "this is still the same repo."
-
-**Compounding factor: `default` and a `proj_*` id can point at the exact
-same real path without comparing equal as strings.** `projects.json`'s
-`default` entry (the core project, fixed id) and, on this machine, the
-KenazAI project's own `proj_1776613204237_0p34i5y` entry both have
-`"path": "__kenaz_core__"` — a virtual token resolved at read time by
-`virtual_path::resolve()` (`dashboard/src-tauri/src/common/virtual_path.rs:16`)
-using the `KENAZ_SOURCE_DIR` env var. Any code comparing raw id/path
-strings (rather than resolving the token first) will never see these two
-as the same repo — this is why the consolidation migration below resolves
-`default` via the registry's actual core project path, not the literal
-token (see "core token pitfall" note in `identity_consolidation.rs`).
-
-## The fix (this task)
-
-**Writer** — `sync.rs`:
-- `canonical_repo_root(project_path: &Path) -> PathBuf` (new): collapses
-  all three worktree shapes above to their repo root, and any other
-  subdirectory to the nearest ancestor containing a `.git` entry (file or
-  directory — a git worktree's `.git` is a file).
-- `find_project_by_path` now canonicalizes first, then looks up (or
-  mints) an identity for the canonical root via `hints::slug()` — the SAME
-  normalization TASK_2049's read-time self-echo exclusion
-  (`hints::is_same_repo`) already relies on — instead of a raw
-  char-replace. `hints::slug` was `pub(crate)`-exposed for this reuse.
-- `registry.rs::find_project_by_canonical_path` (new): finds a registered
-  project by slug-normalized path match instead of exact/lowercased
-  string match, and when `projects.json` carries more than one entry for
-  the same path, deterministically prefers the core project, then the
-  lexicographically smallest id.
-
-Going forward, every sync for the same repo — worktree, subdir, or a
-differently-encoded path string — mints the SAME identity. Unit tests:
-`sync.rs::task_2050_canonical_repo_root_tests::*` (9 tests covering all
-three worktree shapes, the `.formation`-without-`worktrees` false-positive
-guard, bare subdirs, the `.git`-file worktree form, and `hints::slug`
-equivalence for the exact KenazAI/CognitiveLabs variant strings above).
-
-**Migration** — new file
-`dashboard/src-tauri/src/features/cortex/identity_consolidation.rs`:
-- `cluster_identities()`: pure, resolver-injected clustering of every
-  `(project_id, project_name)` pair currently in `global_runes` into
-  canonical repo clusters, using the same slug-prefix logic as
-  `hints::is_same_repo` generalized from "is this the current project" to
-  "do these two identities share a repo root at all." Canonical-id
-  priority: a CURRENTLY-registered `proj_*` id > `default` > any `proj_*`
-  id ever seen (even stale) > shortest/lexicographically-smallest
-  remaining id.
-- `find_duplicate_rune_ids()`: within a cluster, groups rows by
-  `(symbol_stable_id, whitespace-normalized content)`; every row past the
-  first (kept by highest `confidence`, tie-broken by most recent
-  `created_at`) is a duplicate.
-- `run_consolidation(conn, dry_run, ...)`: dry-run reads and reports only;
-  non-dry-run wraps identity rewrite (`global_runes` + `global_sigils` +
-  `sync_state`) + duplicate deletion + an FTS5 rebuild
-  (`INSERT INTO global_runes_fts(global_runes_fts) VALUES('rebuild')`) in
-  one `unchecked_transaction()` — nothing commits if any step errors.
-  Idempotent: a second call after a successful non-dry-run finds zero
-  clusters with pending merges/duplicates.
-- `consolidate_global_memory(db_path, dry_run)`: the real-world entry
-  point — non-dry-run first does `PRAGMA wal_checkpoint(FULL)` then
-  `std::fs::copy`s the DB to `<path>.bak_<unix_ts>` before touching
-  anything. **Not called from anywhere else in the codebase** — Phase 1
-  scope is "implement, do not wire up or run non-dry-run."
-
-Scope note: the migration rewrites the `project_id`/`project_name`
-COLUMNS only. The `id`/`original_id` composite key text
-(`{project_id}::{original_id}`, minted at sync time) is left as-is —
-rewriting it would also require updating `alaya_exported.original_id`
-(which references the old composite) and is deferred past Phase 1. This
-is safe: `id` stays a unique, stable primary key either way, and every
-reader keys off the `project_id` COLUMN, not a re-derivation from `id`.
-
-Unit/fixture tests: `identity_consolidation.rs::task_2050_cluster_tests::*`
-(9 tests, pure `cluster_identities()` — KenazAI's 10 variants into one
-cluster, the stale-vs-registered `proj_*` tie-break, CognitiveLabs
-clustering while staying distinct from KenazAI, stale-id-by-name
-fallback, unrelated projects staying separate, `default` merging via the
-resolved core path, the "kenazai" vs "kenazai2" boundary guard, and
-registered-name overriding a drifted recorded name) and
-`identity_consolidation.rs::task_2050_run_consolidation_tests::*` (5
-tests against a real `GlobalMemoryDb::open_at` fixture — dry-run reports
-without mutating, non-dry-run rewrites + dedups inside one transaction,
-idempotent second run, empty DB).
-
-## Dry-run numbers (real, computed without cargo)
-
-Per the worktree dispatch rules, this session cannot run `cargo build`/
-`cargo test`, so `cluster_identities()` + `find_duplicate_rune_ids()` were
-re-implemented in a read-only Node.js script
-(`node:sqlite`, `DatabaseSync(..., { readOnly: true })`) and run against a
-**disposable copy** of the real DB
-(`cp ~/.kenaz/cortex/global_memory.db <temp>/task_2050_global_memory_copy.db`,
-never the live file — rule 7). The script mirrors `slug()` and the
-clustering/dedup algorithm field-for-field, and resolves the
-`__kenaz_core__` virtual token to this machine's real KenazAI checkout
-path (confirmed via `virtual_path.rs`'s own test fixture and the dominant
-`unregistered_C__Users_user_Documents_GitHub_KenazAI*` identities in the
-data) rather than comparing the literal token — this is the exact "core
-token pitfall" noted above; an earlier draft of the script that compared
-the literal token produced two separate KenazAI clusters instead of one,
-which is how that pitfall was caught. Both the copy and the script were
-deleted after use; nothing was written to the live DB.
-
-| Canonical identity | Identities merged | Rows total | Rows rewritten | Duplicates removed |
-|---|---|---|---|---|
-| `proj_1776613204237_0p34i5y` (KenazAI) | 24 | 33,201 | 25,881 | 25,813 |
-| `proj_1776272260652_95upqs6` (dear-cs) | 0 | 5,807 | 0 | 3,317 |
-| `proj_1781780904403_spf1f5l` (jiayao) | 0 | 450 | 0 | 6 |
-| `proj_1775339532602_0kcmwhf` (CognitiveLabs) | 1 | 296 | 6 | 6 |
-| `proj_1786456211214_xlzb0sc` (quotation) | 3 | 43 | 4 | 0 |
-| **Total** | **28** | — | **25,891** | **29,142** |
-
-("Rows rewritten" is the pre-dedup row count of every non-canonical
-identity — the UPDATE runs before duplicate DELETE, so a row that gets
-deleted as a duplicate is still counted as rewritten first, matching what
-`ClusterReport.rune_rows_rewritten` / `run_consolidation`'s non-dry-run
-path actually does.)
-
-The KenazAI duplicate count (25,813 of 33,201 rows, ~78%) is large but
-plausible: most of the 24 merged identities are short-lived Formation/
-Claude/kenaz worktrees, each of which synced a near-complete copy of the
-main repo's rune set at the time it branched. dear-cs's 3,317 duplicates
-under a SINGLE identity (no merge) show the same pattern can occur without
-any identity split at all — repeated re-syncs re-inserting near-identical
-content under fresh `original_id`s.
-
-Other projects in the DB (esp32, trip, Alaya, analyze, KenazCEO, demo1,
-SoundDrop, deardear_web, AgentSystem_demo, and a handful of one-off
-`unregistered_*` rows from `/AppData/Local/Temp` test runs and one
-literal `unregistered_.` from a caller that passed a relative `"."`
-path) had zero identities to merge and zero duplicates — omitted from the
-table above (a cluster is only reported when `identities_merged() > 0` or
-it has pending duplicates, matching `run_consolidation`'s actual filter).
-
-## Does the identity string leave this machine?
-
-**`project_id` (the encoded-path identity string, e.g.
-`unregistered_C__Users_user_Documents_GitHub_KenazAI`,
-`proj_1776613204237_0p34i5y`) — no, never.** `project_name` (the human
-label, e.g. `"KenazAI"`) — yes, already, today, unaffected by this task
-either way.
-
-Evidence: `dashboard/src-tauri/src/features/cortex/alaya/mod.rs:177-190`'s
-`SeedRecord` (what actually gets exported/uploaded to the Alaya hub) has
-fields `seed_type`, `content`, `source_symbol`, `confidence`,
-`project_name`, `exported_at` — **there is no `project_id` field on this
-struct at all**. Both construction sites
-(`alaya/hub_client.rs:100-105`, file-based JSONL export, and
-`alaya/hub_client.rs:601-608`, the async hub-upload path) set
-`project_name: r.project_name.clone()` sourced from `global_runes`, and
-neither references `project_id`. `upload_seeds_to_hub_blocking` /
-`upload_seeds_async` (`hub_client.rs:253/313`) POST a
-`Vec<SeedRecord>` (via `serde_json`) to `{hub.url}/api/v1/seeds/upload` —
-whatever `SeedRecord` serializes is exactly what crosses the wire.
-
-So this migration is purely local-machine bookkeeping as far as
-`project_id` goes (it never left and still won't). `project_name` already
-leaves today; after consolidation, rows that used to carry a
-worktree/subdir label (`"task_task_1065"`, `"dashboard"`) as their
-`project_name` will instead carry the clean canonical name (`"KenazAI"`)
-when re-exported — a minor quality improvement to what's already being
-sent, not a new exposure.
-
-## What Phase 2 (not this task) still needs
-
-- Decide whether to also rewrite `id`/`original_id` (and
-  `alaya_exported.original_id` in lock-step) for full internal
-  consistency, or leave the composite-key scope decision from Phase 1 as
-  permanent.
-- Actually run `consolidate_global_memory(path, dry_run: false)` against
-  the real DB, behind an explicit reviewed operation (CLI flag or a
-  one-time startup migration gate), after this Phase 1 lands and the
-  numbers above are re-verified with `cargo test` (this session could not
-  run cargo).
-- The lone `unregistered_.` identity (37 rows, `project_name: "unknown"`)
-  has no recoverable path — some past caller passed a relative `"."`
-  `project_path`. Not mergeable without more information; left as a
-  residual oddity for Phase 2 to decide (delete, or leave as its own
-  permanent bucket).

package/core/dev/GUARD_EFFECTIVENESS_DESIGN.md

@@ -1,180 +0,0 @@
-# Guard Effectiveness Grounding — R0 Design
-
-> **Status**: DESIGN (measure-first gate). Not yet a task.
-> **Origin**: 2026-06-15 Ansuz session. User shared Akshay Pachaar tweet → Opik article
-> "Your Agent Harness Should Repair Itself" (failure → executable regression test →
-> self-improving loop). This design extracts the *one transferable idea* and grounds it
-> against KenazAI's already-existing (but half-dormant) Reflection-to-Control pipeline.
-> **Sibling track**: `dev/PREDICTION_GROUNDING_DESIGN.md` §8 (recall-confidence grounding).
-> Both attack the same root: **the acted_on ceiling** — KenazAI converts failures into
-> *advisory memory* whose behavior-change rate has a structural ceiling (~6–12%), and we
-> have no observable signal for whether the advice ever worked.
-
----
-
-## 1. The idea worth stealing (and the part to reject)
-
-Opik's marketed loop: tracing → AI diagnosis → **plain-English assertion compiled to an
-LLM-as-judge test** → each failure becomes a regression test that hardens the harness.
-
-KenazAI already exceeds Opik on tracing (Norn ΔGraph, Hippocampus), diagnosis (Huginn,
-Heimdall), and sandbox (live dashboard, worktree dispatch). The **only** transferable
-idea is: **stop relying on self-report that a lesson changed behavior; infer effectiveness
-from observable outcomes.**
-
-**Reject**: a hard blocking gate as the default. KenazAI's "agent" is open-ended Claude
-Code sessions, not a deterministic pipeline. A pre-gate that *refuses* on a fuzzy predicate
-will false-positive and block legitimate work. Hard gates are a *Tier-A subset* (R1),
-gated on evidence — not the starting point.
-
----
-
-## 2. Ground-truth state (verified 2026-06-15, not asserted)
-
-KenazAI's Reflection-to-Control pipeline (`TASK_1071` + schema `TASK_1075` + v2 fields
-`TASK_1161/1163`) is the same mechanism in embryo. Evidence:
-
-| Stage | Status | Evidence |
-|-------|--------|----------|
-| promote: rune/episode/manual → guard | ✅ live | `lesson-guard.js promote`; 11 guards L-001..L-011 |
-| inject at phase enter (advisory text) | ✅ live | `phase-gate.js readLessonGuardsForPhase`; L-002/L-004 `injection_count: 14` |
-| self-reported acted_on | ⚠️ ~dead | L-004: **14 injections / 0 acted_on**; L-002: 14 / 1 |
-| `failure_signature` detector field | ❌ dormant | schema v2 defines it; **0 of 11 guards set it** (`grep -c` = 0) |
-| detector ENGINE | ✅ **BUILT, but no caller** | `.specialist/tools/failure-detector.js` (TASK_1163): 5 detectors, shadow→live→auto-expire, hit_rate math — all complete |
-| detector WIRING to post-complete | ❌ **never done** | engine header says "Used by: attribution-report.js" but `grep failure-detector .formation/tools/attribution-report.js` = **0 matches**. Stale/aspirational comment. Only reachable via its own CLI, which nothing automated calls. |
-| outcome scoring → `hit_rate` | ⚠️ engine ready, never fed | `failure-detector.updateGuardStats` computes it, but with no caller + no signatures it never runs |
-| `precompute` pre-execute block | ⚠️ partial | L-002/L-004 carry `precompute` (gitLogShort / gitCommitsAhead) but no runner enforces it; display-only |
-
-**The gap, precisely (CORRECTED 2026-06-15 after reading `failure-detector.js`)**: the
-executable-detector ENGINE is **fully built** (TASK_1163) — NOT greenfield. Dormancy is
-two-fold: (1) the engine has **no production caller** (`attribution-report.js`, which runs
-at post-complete, never invokes it), and (2) **no guard carries a `failure_signature` /
-`detector_mode`**. Since 2026-04-11 the entire subsystem has been dead code. R0 = **wire
-the existing engine + seed 2 signatures**, ~a config + integration task, not a build.
-
-**Open integration question**: lesson guards are injected at *Ansuz phase-gate* (interactive
-session chart), but `failure-detector` keys off a *task* chart's `lesson_guards_injected`.
-R0 must resolve which chart actually records injected lesson guards, and feed the detector
-from the right source.
-
-**Why it matters** (ties to TASK_1652's NULL verdict): TASK_1652 couldn't measure whether
-recall changes behavior because acted_on is too sparse. The guard layer has the *same*
-ceiling with hard numbers — L-004 injected 14×, acted_on 0×. We have **zero evidence**
-whether the worktree stale-base guard ever prevented the failure it encodes. The
-`failure_signature`/`hit_rate` fields were designed to answer exactly this and were never
-connected.
-
----
-
-## 3. R0 scope — measure-first (the ONLY thing built first)
-
-Build the dormant detector half and **measure**, before any enforcement change.
-
-### 3.1 Deliverables (CORRECTED — engine already exists)
-1. **Wire the existing `failure-detector.js` engine into post-complete.** It is already
-   built but has no caller. Integrate `runDetectorsForTask(taskId, guardSnapshots, pcResult)`
-   into the post-complete path (alongside / inside `attribution-report.js`, which already
-   runs there). Do NOT rebuild the engine.
-2. **Resolve the chart-source question** (§2 open integration question): determine where
-   `lesson_guards_injected` is actually recorded (Ansuz session chart vs worker-task chart)
-   and feed the detector the correct snapshots. This is the real integration work.
-3. **Seed `failure_signature` + `detector_mode: shadow` on L-004 and L-010** (see §4).
-   Shadow mode is built-in: first 10 detections log to `guard_detector_shadow.jsonl` with
-   NO stat mutation / NO auto-expire — exactly the measure-first behavior we want.
-4. **Measure** via the built-in `failure-detector.js shadow-log` + `lesson-guard.js status
-   --verbose`. The shadow→live unlock and auto-expire (hit_rate<0.3 after 5 live) lifecycle
-   already exists — R0 only needs to reach the end of shadow and review.
-
-### 3.2 Detector types — USE THE ENGINE'S EXISTING 5 (do not invent new)
-`failure-detector.js` already ships 5 detector types. R0 reuses two; no new detector code:
-| Engine `detector_type` | Inspects | Fires `failure_detected` when | R0 use |
-|------------------------|----------|-------------------------------|--------|
-| `git_commit_pattern` | task branch commits | revert commit, OR `failure_signature` keyword in commit msg, OR large line delta | L-004 (approximate — catches reverts/overreach that correlate with stale-base) |
-| `merge_conflict` | task status + failure_reason | status=blocked AND failure_reason~merge_conflict | **L-010 (exact fit)** |
-| `acceptance_grep_miss` / `regression_test_failure` / `surprise_file_in_scope` | — | — | not used in R0 |
-
-`failure_signature` is set as an **object** (`{type, ...}`); `validateGuardEntry` already
-accepts object-with-`type` (schema says string — known drift, F3 documents object form).
-The engine's 3-state result (`failure_detected` / `failure_avoided` / `null`=undetectable)
-already excludes the unmeasurable — matches TASK_1652 discipline.
-
-**Known limitation to verify in shadow**: `git_commit_pattern` matches keywords against
-commit *messages*, not raw diff — so L-004's true signature ("new file mode 100644" in
-diff) is NOT directly detectable by the current engine. R0 uses the revert/delta heuristic
-as a proxy; if shadow shows it's too coarse, a diff-level detector is an engine extension
-deferred to R1 (not built speculatively in R0).
-
-### 3.3 Baseline = forward-only (F2 resolved 2026-06-15)
-**No history mining.** Measurement starts at R0 landing; the detector records
-`failure_detected` / `failure_avoided` going forward only. Cleaner (no noisy transcript
-archaeology, detector stays a pure forward function), at the cost of a slower path to N≥5.
-
-**Honest limitation**: with the guard always injected and no no-guard control, `hit_rate`
-measures **co-occurrence** (guard-present → failure avoided), not proven causation. That is
-acceptable for an R0 *measurement-capability* gate. Causal proof (intermittent injection /
-A/B) is explicitly deferred to a possible R1 experiment — do NOT claim causation from R0.
-
-### 3.4 Success / NULL criteria (gate for R1)
-This is a **gate**, exactly like TASK_1652's R0. Decide R1 only on evidence:
-- **SIGNAL** → for ≥1 guard, signature produced `inferred_acted_on + inferred_failure ≥ 5`
-  detectable events AND `failure_detected` rate is informatively low (guard-present
-  sessions mostly avoid the failure). → candidate for R1 (where a control A/B can test
-  causation).
-- **NULL** → signatures fire too rarely to compute (< 5 detectable events over the window),
-  OR `failure_detected` stays high despite guard present (advisory text isn't preventing
-  the failure). → close R1, but R0 still delivered the *measurement capability* (net
-  positive) and flags which guards to **expire** (injected-much / failure-still-occurs =
-  noise, e.g. L-004's 14-inject/0-acted profile).
-
----
-
-## 4. Which guards qualify for R0 (mechanically detectable only)
-| Guard | Lesson | Signature type | Detectable? |
-|-------|--------|---------------|-------------|
-| **L-004** | worktree stale-base → `new file mode 100644` mass-rebase | `git_diff_pattern` | ✅ strong — already has `precompute: gitCommitsAhead` |
-| **L-010** | edit inside active task scope → post-complete conflict / stash leak | `post_complete_conflict` | ✅ — 29-stash incident is the ground-truth pattern |
-| L-002 | run synapse_pulse before editing phase-gate.js callers | — | ❌ no observable outcome signature (process, not outcome) |
-| L-005..L-009, L-011 | DDx / exo-cortex / staleness reflexes | — | ❌ cognitive process, not mechanically detectable |
-
-R0 backfills **L-004 and L-010 only**. The rest stay advisory + self-report — they are
-genuinely not outcome-detectable, and pretending otherwise would manufacture fake metrics
-(the [[feedback_label_ritual_displaces_perception]] trap).
-
----
-
-## 5. R1 — hard pre-gate (GATED on R0 SIGNAL, + user sign-off)
-Only for guards whose **precondition is a computable predicate** (the `precompute` field's
-original intent: "pre-execute compliance block") AND whose R0 `hit_rate` proves the
-failure is real and the guard correlates with avoiding it:
-- L-004: at dispatch time, if `gitCommitsAhead(baseRef) > 10` → **block dispatch**, force
-  baseRef refresh. (Predicate already computed; today it's display-only.)
-- L-010: before Edit/Write, if target ∈ any `active/*.yaml` scope_paths → **refuse**, surface options.
-
-R1 is the literal "Opik executable test" — but applied only to the thin subset where the
-predicate is deterministic, so false-positives are near-zero. Everything fuzzy stays Tier-B
-(retrospective score). Not in R0.
-
----
-
-## 6. Non-goals / risks
-- **NOT** adopting Opik (GEN-007 self-contained; our cognitive layer is deeper).
-- **NOT** hard-gating fuzzy/cognitive guards — brittle, false-positive prone.
-- **NOT** trusting self-reported `record-acted-on` as the effectiveness signal — that IS
-  the ceiling we're routing around.
-- **Risk**: detector false-positives inflate `inferred_failure`. Mitigation: `undetectable`
-  third state; detectors are pure + unit-testable; audit log is append-only for forensics.
-- **Risk**: schema/code drift on `failure_signature` type. Mitigation: R0 resolves it
-  (bump schema to allow object form, document in REFLECTION_TO_CONTROL.md).
-
----
-
-## 7. Open forks (need user decision before R0 task is scoped)
-- **F1 — dispatch path**: R0 is rigor:medium, single-subsystem (`.specialist/tools` + 2
-  guard edits). Subagent (interactive) vs Formation? Leaning **subagent** (same-project,
-  not multi-hour).
-- **F2 — baseline source**: ✅ RESOLVED 2026-06-15 → **forward-only**. No history mining;
-  detector measures from R0 landing forward. `hit_rate` = co-occurrence, not causation
-  (see §3.3). Causal A/B deferred to R1. Trade-off accepted: slower to N≥5, cleaner data.
-- **F3 — schema version bump**: resolve `failure_signature` string→object as schema v3, or
-  keep v2 and lean on the existing permissive validator? v3 is cleaner but touches the
-  contract doc.