kenaz 0.0.0-stage → 0.3.2

package/core/dev/PROJECT_REGISTRY_DUPLICATE_ASSESSMENT.md

@@ -0,0 +1,86 @@
+# Assessment: KenazAI repo registered twice in `~/.kenaz/projects.json`
+
+TASK_2055 · assessment only · 2026-09-26
+
+## 0. The fact on disk
+
+`~/.kenaz/projects.json` (read directly, this session):
+
+```json
+{
+  "currentProjectId": "proj_1776613204237_0p34i5y",
+  "projects": [
+    { "id": "default", "name": "Kenaz", "path": "__kenaz_core__",
+      "is_core": true,  "core_path": "__kenaz_core__" },
+    ...,
+    { "id": "proj_1776613204237_0p34i5y", "name": "KenazAI", "path": "__kenaz_core__",
+      "is_core": false, "core_path": "__kenaz_core__",
+      "createdAt": "2026-04-19T15:40:04.237Z" },
+    ...
+  ]
+}
+```
+
+Both entries resolve `__kenaz_core__` to the same real path (`common::virtual_path::resolve`), i.e. one repo, two ids. `currentProjectId` currently points at the **non-core** `proj_1776613204237_0p34i5y` entry, not at `default`.
+
+## 1. Root cause — confirmed from the actual seed code
+
+**`default` is minted by two independent, well-behaved seeders**, both hard-coding `id: "default"` and `is_core: true`, never colliding with each other:
+- `dashboard/src-tauri/src/lib.rs:309-383` `auto_seed_project_config()` — runs on every Tauri startup (`lib.rs:1562`), strips any existing `is_core:true` entry and re-inserts a fresh `{"id":"default", ..., "is_core":true}` at index 0. **This alone would re-seed `default` if it were ever deleted** — it runs unconditionally on every launch, not just first-run.
+- `dashboard/src-tauri/src/infrastructure/http_server/routes/projects.rs:110-203` `seed_from_config_json()` — HTTP-route fallback, only fires when `projects.json` doesn't exist at all; also mints `id: "default"`.
+
+**`proj_1776613204237_0p34i5y` was NOT auto-seeded.** It was created by the user (or a click automated on the user's behalf) through the "Add Project" UI flow:
+- `dashboard/src/contexts/ProjectContext.tsx:57-58` `generateId()` → `` `proj_${Date.now()}_${random}` `` — `1776613204237` is literally `Date.now()` at the moment of creation, which decodes to `2026-04-19T15:40:04.237Z`, matching the entry's own `createdAt` field exactly.
+- `dashboard/src/contexts/ProjectContext.tsx:743-756` `addProject()` — called by the two UI call sites below — assigns a fresh `generateId()` id and pushes the entry **unconditionally**. There is no check anywhere in `addProject()` against `path`/`core_path` already matching an existing (especially `is_core`) entry.
+- Call sites, both from the "Add Project" dialog, both hard-coding `is_core: false`:
+  - `dashboard/src/components/project-selector/NewProjectDialog.tsx:217-223` — `addProject({ name: projectName, path: trimmedPath, ..., is_core: false, core_path: resolvedCorePath || null })`
+  - `dashboard/src/app/page.tsx:1229` — `addProject({ name, path: dir.replace(/\\/g,'/'), pipelinePath: 'dev/pipeline' })`
+
+So the mechanism is: at some point the user pointed the "Add Project" folder picker at the KenazAI core repo itself (or a symlink/junction to it) and confirmed. `addProject()` had no idea that path was already the registered core, minted a second id, and wrote it in as a normal (`is_core:false`) sub-project named "KenazAI".
+
+**Would deleting `proj_1776613204237_0p34i5y` be re-seeded?** No, not automatically, by the same mechanism that created it — no seed/auto-register code path ever mints a `proj_*` id; that only happens through the interactive `addProject()` UI flow. But the *effects* of the duplicate come back the moment a user (or an automated UI-driving agent) repeats the same manual mistake — nothing in `addProject()`/`NewProjectDialog.tsx` was fixed to reject "path already registered." `auto_seed_project_config()` and `seed_from_config_json()` only touch/recreate the `is_core:true` (`default`) entry; they never touch or recreate `proj_*` entries, and deleting `proj_1776613204237_0p34i5y` would leave `default` untouched.
+
+## 2. Consumer table
+
+Legend: **id-first** = looks up `currentProjectId` by exact `id` match, falling back to `is_core:true` only if no id match (so today, with `currentProjectId = proj_1776613204237_0p34i5y`, these resolve to the **non-core** entry, name `"KenazAI"`, `is_core:false`). **is_core-first** = ignores `currentProjectId`, always finds the `is_core:true` entry directly (immune to which id is "current").
+
+| Consumer | File:line | Id used | Resolution style | Impact if the `proj_` entry disappears / today's impact |
+|---|---|---|---|---|
+| Core dir resolution (Ansuz daemon init) | `dashboard/src-tauri/src/lib.rs:2559-2569` | `currentProjectId` → path | id-first, `virtual_path::resolve()`'d | Path resolves correctly either way (both ids → same real path). No breakage on deletion. |
+| Ansuz daemon watcher poll loop | `dashboard/src-tauri/src/features/ansuz_daemon/mod.rs:158-183` | `currentProjectId` → path | id-first, resolved | Same — path-equivalent, safe either way. |
+| Session lease "active project" filter | `dashboard/src-tauri/src/features/session/active_projects.rs:190-203` | `currentProjectId` → path | id-first, **NOT** `virtual_path::resolve()`'d | Returns literal `"__kenaz_core__"` string (unresolved token) regardless of which entry wins — pre-existing bug, not created by the duplicate, but the duplicate is what's live today. Breaks lease-path comparison against real session paths. |
+| Prefrontal background project-root resolver | `dashboard/src-tauri/src/features/prefrontal/background.rs:105-128` | `currentProjectId`, falls back to `is_core:true` | id-first (id match wins over is_core fallback), resolved | Path-equivalent — safe. If `proj_` entry removed, falls through to `default`/is_core, still correct. |
+| Proposal manager active-root resolver | `dashboard/src-tauri/src/features/proposal/manager.rs:264-289` | same pattern | id-first, resolved | Same — safe either way. |
+| MCP `kenaz_project_current` / project list | `dashboard/src-tauri/src/infrastructure/http_server/routes/mcp.rs:150-171` | same pattern | id-first | Returns `(projects, current_id)` — a caller matching by name (`"KenazAI"` vs `"Kenaz"`) would see the sub-project's name, not the core's. |
+| Synapse route resolvers (2 fns) | `dashboard/src-tauri/src/infrastructure/http_server/routes/synapse.rs:249-289` and `:307-344` | same pattern | id-first, resolved via `core_path` first | Path-equivalent — safe. |
+| Cortex registry — canonical id chooser | `dashboard/src-tauri/src/features/cortex/registry.rs:205-227` `choose_canonical_id()` | both ids as candidates | **Explicitly prefers `default`** over any `proj_*` id (TASK_2053, tested at `registry.rs:266-274`) | Already the fix point: this is the one place in the codebase that was rewritten specifically *because of* this duplicate (see `identity_consolidation` / `sync.rs` — TASK_2050/2053 commits in this branch's history). Deleting `proj_` entry: harmless, `default` still wins by rule 1. |
+| Cortex cross-project self-echo filter | `dashboard/src-tauri/src/features/cortex/hints.rs:229-280` `query_cross_project_runes()` / `is_same_repo` | `current_project_id` param (whatever the caller passed) + path-based fallback via `registry::find_project_path_by_id` | Path/identity-aware, already hardened (TASK_2049) | Self-correcting regardless of which id is "current" — already treats both ids as the same repo. |
+| **Frontend: Project switcher dropdown (visible symptom)** | `dashboard/src/components/project-selector/ProjectSelector.tsx:120` `userProjects = projects.filter(p => !p.is_core)` | filters by `is_core`, not id | — | **The `proj_1776613204237_0p34i5y` "KenazAI" entry shows up as a selectable sub-project in the UI**, indistinguishable from a real sub-project like `deardearly_management`. This is how a user can (re-)select it and re-trigger the bug below. |
+| **Frontend: current-project resolution + "is this a sub-project" gate** | `dashboard/src/contexts/ProjectContext.tsx:698-741` (`currentProject`, `corePath`) and `:805-822` (auto-ensure `.kenaz/` structure effect) | `currentProjectId` (id-first, no is_core fallback in `currentProject`) | — | **Confirmed live defect.** Because `currentProjectId` = the `is_core:false` `proj_` entry, `ProjectContext.tsx:809` (`if (currentProject.is_core \|\| !currentProject.path) return;`) does **not** short-circuit, so the effect calls `tauriCommands.initProject(currentProject.path, ...)` treating the **core repo itself as a sub-project**. Evidence: `.kenaz/project.yaml` in this very repo (both this worktree and the main checkout `C:\Users\user\Documents\GitHub\KenazAI\.kenaz\project.yaml`) contains `# Kenaz AI Sub-Project Configuration` / `project_name: "KenazAI"` / `core_path: "__kenaz_core__"` — the core repo self-registered as its own sub-project. (File's `created_at: 2026-03-13`, *before* `proj_1776613204237_0p34i5y`'s `createdAt: 2026-04-19` — so this specific file predates today's duplicate and may be residue of an earlier, already-repaired instance of the same failure mode; it corroborates the mechanism rather than being proof of this exact incident.) |
+| **Frontend: "Add Project" duplicate-creation path** | `dashboard/src/contexts/ProjectContext.tsx:743-756` `addProject()`, `NewProjectDialog.tsx:217-223`, `page.tsx:1229` | mints new `proj_*` id unconditionally | — | Root cause (§1) and the only path by which a *third* duplicate could be created tomorrow — no path-collision guard exists here today. |
+| Global-memory sync writer | `dashboard/src-tauri/src/features/cortex/sync.rs` (`find_project_by_path` → `registry::find_project_by_canonical_path`) | resolves by canonical path, delegates to `choose_canonical_id` | already hardened (TASK_2050/2053, this branch) | Already fixed — was the actual live-incident source (repo background: "caused three rounds of global_memory duplication"). |
+| `.claude/hooks/worktree-create.js:106-115` `resolveTargetRepo()` | raw `fs.readFileSync` + `JSON.parse`, **no virtual-token resolve** | id-first via `pj.currentProjectId` | JS, unresolved | `proj.path` for either core-identified entry is the **literal string `"__kenaz_core__"`**, not a real path → `isGitRepo("__kenaz_core__")` is false → `resolveTargetRepo()` returns `null` regardless of which id is current. Pre-existing gap, not created by the duplicate (same failure for `default`), but currently masked because `worktree-create.js:723` only calls this as one fallback among several (grep: `resolveTargetRepo` at lines 106, 723). |
+| `.specialist/tools/ansuz-boot-fast.js:293-303` `readProjectsJsonSync()` | raw `fs.readFileSync` + `JSON.parse`, no virtual-token resolve, id-first | same as above | Returns literal `"__kenaz_core__"` for `currentProjectPath` when current entry is either core id; `getDashboardCurrentProject()` (`:327-329`) tries this **before** falling back to the (correctly-resolving) HTTP endpoint `fetchCurrentProjectHttp()` (`:305-325`), so a non-null-but-wrong sync answer can win over a correct HTTP one. Same failure for `default` — orthogonal to which id is picked, but live today because `currentProjectId` is currently a core-identified id. |
+| `.claude/hooks/core-resolve.js:100-107, :158-163` | `.find(p => p.is_core)` | is_core-first, ignores `currentProjectId` entirely | Immune — always finds `default` directly by flag, never looks at the duplicate. |
+| `.collaboration/core/task-api.js` `resolveTasksDir` | — | none (grep: 0 matches for `currentProjectId`/`projects.json` in this file) | Not a consumer — resolves task dirs from cwd/`--project-path`, never reads the registry. |
+| `.formation/*`, `.collaboration/hooks/*` other than above | — | none found (grep across `.formation`, `.specialist`, `.collaboration`, `.claude/hooks` for `currentProjectId`/`projects.json`/`project_id` returned only the files listed above) | Not consumers. |
+
+Search method for completeness: `grep -rln "currentProjectId\|current_project_id" dashboard/src-tauri/src dashboard/src dev/scripts .collaboration .formation` (27 Rust hits / 9 files, 25 TS hits / 3 files — counts above), plus `grep -rln "currentProjectId\|projects\.json\|project_id\b" .formation .specialist .collaboration .claude/hooks` (10 files, all covered in the table or confirmed non-consumers).
+
+## 3. Options
+
+**Option A — remove the `proj_` entry, repoint `currentProjectId` to `default`.**
+Steps: (1) stop the Dashboard, (2) edit `~/.kenaz/projects.json`: delete the `proj_1776613204237_0p34i5y` object, set `"currentProjectId": "default"`, (3) restart Dashboard, verify `auto_seed_project_config()` doesn't reintroduce a second core entry (it won't — it only ever writes `id:"default"`), (4) verify `ProjectSelector.tsx` dropdown no longer shows a "KenazAI" sub-project, (5) verify `.kenaz/project.yaml`'s self-sub-project registration doesn't get recreated (the `is_core` short-circuit at `ProjectContext.tsx:809` now correctly fires since `currentProject.is_core` will be `true`).
+Risk: low. Every id-first Rust consumer in the table already resolves the same real path for both ids (`virtual_path::resolve` is symmetric), so no path regression. The one behavior *change* is desired: `currentProject.is_core` becomes `true` again, which is the correct state. `choose_canonical_id` already prefers `default` unconditionally, so cortex/global_memory identity is unaffected. Must also fix `addProject()` (§1) with a path-collision guard, or a future "Add Project" click recreates the exact same problem.
+
+**Option B — keep both entries, mark the `proj_` one as an alias in the registry schema.**
+Would require: a new `aliasOf`/`canonicalId` field in the `Project` type (`ProjectContext.tsx:16-26`, `routes/projects.rs:20-34`), every id-first consumer in the table updated to resolve through the alias, `ProjectSelector.tsx:120`'s `userProjects` filter updated to also exclude aliases, and `choose_canonical_id`/`is_same_repo` updated to treat "alias" as authoritative rather than inferring canonicalness from timestamp/`is_core`. This touches ~9 Rust files, 3+ TS files, and duplicates the exact per-consumer knowledge that TASK_2053's `choose_canonical_id` already centralizes — net new surface area to keep in sync, for a state (two live ids for one repo) that has no legitimate use case here (unlike, say, a real rename-with-history feature). Not worth building for a single already-known-bad row.
+
+**Option C — leave as is.**
+The immediate global_memory duplication is patched (`choose_canonical_id`, TASK_2053, this branch, tests passing per commit history). But: (a) the entry still shows in the UI as a selectable sub-project (`ProjectSelector.tsx:120`), inviting a user to click it and re-trigger the self-sub-project `initProject()` bug (§2, `ProjectContext.tsx:805-822`); (b) `currentProjectId` staying on a non-`default`/non-`is_core` id is exactly the state that made `ProjectContext.tsx:809`'s short-circuit fail; (c) it remains a trap for the next engineer who writes a *new* id-first-without-is_core-fallback consumer (as CLAUDE.md's task background states was the original motivation).
+
+## Recommendation
+
+**Option A.** It is a five-minute, low-risk data fix (`choose_canonical_id` already guarantees `default` wins identity resolution regardless, so nothing downstream regresses), it removes the visible UI trap (`ProjectSelector.tsx:120`) and the confirmed live self-sub-project defect (`ProjectContext.tsx:809`/`.kenaz/project.yaml`), and it costs far less than Option B's schema/consumer-update surface for a case with no legitimate use for two live ids. Pair it with a one-line guard in `addProject()` (`ProjectContext.tsx:743`) / `NewProjectDialog.tsx` rejecting a `path`/`core_path` that already resolves to an existing entry's `path`/`core_path`, so the same manual mistake can't recreate the duplicate.
+
+**Addendum (TASK_2062, 2026-09-27):** step (4) above was wrong — after removing the `proj_` entry, the core project didn't just stop appearing as a duplicate "KenazAI" sub-project, it disappeared from the dropdown entirely and became unselectable: `ProjectSelector.tsx:120`'s `userProjects` filter excluded *every* `is_core` entry (there was no other one left to filter out), and `ProjectContext.tsx`'s `currentProject` resolver silently redirected any core selection to the first sub-project. The duplicate had been the user's only way to select the core repo. Fixed by listing the core project first in `ProjectSelector.tsx` (selectable, badged, no delete control) and removing the redirect in `ProjectContext.tsx`'s `currentProject` — see TASK_2062.

package/core/dev/STARTUP_TIMELINE_TASK_1995.md

@@ -0,0 +1,181 @@
+# TASK_1995 R1 — Startup timeline instrumentation + blocking-in-async audit
+
+Scope: R1 only (instrument, no behavior change). R2 (moving the blocking
+work off the runtime) is a separate, unscoped task. This document is the
+R1 deliverable: a table of every task/thread spawned inside `lib.rs`'s
+`.setup()` closure, whether its closure calls a blocking API directly on
+the tokio runtime (i.e. without `spawn_blocking` or a dedicated
+`std::thread`), and the evidence line numbers.
+
+## Evidence
+
+- rune_386048f8 (2026-08-21): the 30 x 500ms TCP ready-wait
+  (`infrastructure::nextjs_sidecar::probe_frontend_ready`,
+  `ProbeBudget::initial()`) measured at 76.6s wall-clock twice — nominal
+  15s, ~5x factor.
+- TASK_1995 never-listens fixture (`dev/scripts/task1961/run-fixture.js
+  --arm=never-listens`) reproduced 75983ms / 75799ms on the release build,
+  0.2.235 and 0.2.237 — the 5x factor is stable across releases, ruling
+  out a one-off regression.
+- Hypothesis (unconfirmed by this task — R1 only *exposes* the evidence,
+  it does not prove causation): the shared tokio multi-thread runtime's
+  worker pool is starved by blocking calls made directly inside async
+  tasks spawned from `.setup()`, so `tokio::time::sleep(500ms)` inside the
+  ready-wait loop cannot be polled and resumed promptly even after its
+  timer fires.
+
+## What R1 added (instrumentation only)
+
+- `dashboard/src-tauri/src/infrastructure/startup_timeline.rs` — new
+  module. `mark(label)` records `(label, t_ms since first mark, calling
+  thread name)` into a bounded (`MAX_ENTRIES = 512`) `Vec` behind a
+  `Mutex`, and logs one `tracing::info!(target: "startup_timeline", ...)`
+  line per call. `entries()` reads the timeline back.
+- `~25` `mark()` call sites added across `lib.rs`'s `run()`/`.setup()` —
+  see the table below (column "Timeline marks added") for exactly which
+  ones bracket which spawn site.
+- `infrastructure::nextjs_sidecar::probe_frontend_ready`: per-TCP-attempt
+  timing (`nominal_ms` vs `actual_ms`, `max_gap_ms` = worst single
+  attempt's overrun) logged once at the end of the TCP phase, and one
+  `startup_timeline` line per HTTP hop (`hop`, `budget_ms`, `actual_ms`,
+  `status`). No change to attempt counts, intervals, or break conditions.
+- `GET /api/health` now additionally returns `startup_timeline: [{label,
+  t_ms, thread}]` (additive field; existing fields unchanged).
+
+None of the above changes probe budgets, port handling, ordering, or any
+sleep duration — purely read-only measurement (R4 compliance).
+
+## Audit table — spawn sites inside `.setup()`
+
+`.setup(|app| { ... Ok(()) })` spans `lib.rs:1332-3506` (post-instrumentation
+line numbers; pre-instrumentation the closure was `1329-3463`). All 34
+concurrency primitives below are inside it. "Blocking in async?" = a
+blocking API (std::fs, rusqlite/KuzuDB open, ONNX load, std::process
+spawn/wait, std::thread::sleep, blocking HTTP) called directly inside an
+`async` closure/fn body, NOT wrapped in `spawn_blocking` and NOT run on a
+dedicated `std::thread`.
+
+| # | Site (lib.rs line, post-instrumentation) | Mechanism | Blocking in async? | Evidence (line, call) |
+|---|---|---|---|---|
+| 1 | ~1376 MCP server startup | `tauri::async_runtime::spawn` | Not verified deeply this pass (bounded effort) — `start_mcp_servers` (`features/plugins/mod.rs:155`) loops `list_plugins()` + awaits `mcp_host.start_plugin_server(...).await`, which itself spawns child MCP server processes. Flagged **possible** — child process spawn may share the same `cmd.spawn()`-is-synchronous issue as #16 below. | `features/plugins/mod.rs:155-175` |
+| 2 | ~1420 Yggdrasil remote-ref poller | `tauri::async_runtime::spawn` | **No** direct blocking seen in `remote_poll::start`'s hot path — gated off by default (`remote_poll_enabled=false`); `load_config().await` and `poll_once` are `.await`ed. Not a startup-window contributor while disabled. | `features/remote_poll/mod.rs:93-131` |
+| 3 | ~1613 ONNX warmup thread | `std::thread::Builder::spawn` (own OS thread) | **Isolated — safe.** `eager_init_engine()` (blocking: ONNX model load) runs on a dedicated named thread (`"onnx-warmup"`), not a tokio worker. | `lib.rs` ONNX block; `features/synapse/embedding.rs::eager_init_engine` |
+| 4 | ~1633 ΔGraph gap recovery thread | `std::thread::Builder::spawn` (own OS thread) | **Isolated — safe**, same pattern as #3. `MemoryDb::open()` (rusqlite `Connection::open_with_flags`, blocking) + `delta_graph::recover_gap` + `heat::init_for_project` all run on the dedicated `"delta-gap-recovery"` thread, not a tokio worker. | `lib.rs:1636-1680`; `features/synapse/memory/mod.rs:276-288` (the actual blocking open call, safely isolated here) |
+| 5 | ~1786 startup hook backfill | `tauri::async_runtime::spawn(async {...})`, 5s initial `sleep` | `backfill_all_registered_projects(...).await` — not deep-audited this pass; async signature suggests non-blocking, but its internals were out of the bounded-effort budget. | `lib.rs` hook backfill block |
+| 6 | ~1805 hippocampus consolidation daemon | `tauri::async_runtime::spawn(async {...})`, 60s initial `sleep`, then every 6h | **Yes.** `MemoryDb::open(&db_path)` (rusqlite, blocking disk I/O — journal mode pragma, busy_timeout) called directly inside the async task body, no `spawn_blocking`. | `lib.rs` consolidation block: `features::synapse::memory::MemoryDb::open(&db_path)`; sink fn at `features/synapse/memory/mod.rs:276` |
+| 7 | ~1858 Alaya bija sync daemon | `tauri::async_runtime::spawn(async {...})`, 30s initial `sleep`, then hourly | **Yes.** `GlobalMemoryDb::open()` (rusqlite, blocking) called directly inside the async task, no `spawn_blocking`. The bija-linker step correctly uses `spawn_blocking` (good precedent already in this file). | `lib.rs` alaya block: `GlobalMemoryDb::open()`; sink fn at `features/cortex/global_memory.rs:151` |
+| 8 | ~1929 MCP+HTTP+sidecar mega-task | `tauri::async_runtime::spawn(async move {...})` (never returns — ends in `std::future::pending().await`) | **Yes, several sub-blocks** — see rows 8a-8d below. This is the SAME task that later runs the ready-wait loop (#17), so anything blocking earlier in this task's own body delays reaching the ready-wait, and anything blocking on OTHER tokio workers concurrently can starve the ready-wait's own `sleep()` resumption. | `lib.rs:1929` |
+| 8a | ~1934-1961 port cleanup | `std::thread::spawn` x2 (own OS threads) for `kill_process_on_port` | **Isolated — safe.** Blocking netstat/taskkill work is on dedicated OS threads; only the `done_rx.recv_timeout` wait (bounded 3s) blocks the task's own progress, by design. | `lib.rs` port-cleanup block |
+| 8b | ~2149 EMBER daemon auto-start check | `tokio::task::spawn_blocking` | **Correctly isolated** — good precedent: `std::fs::read_to_string(&models_path)` + child process spawn (`cmd.spawn()`, `common::process::hidden_command`) all inside `spawn_blocking`. | `lib.rs` EMBER block |
+| 8c | ~2247-2260 Ansuz wake-up gate + watchdog | inline in the mega-task (not wrapped) | **Yes.** `std::fs::read_to_string(&models_path)` (line ~2211, `ansuz_wakeup_enabled` check) runs directly in the mega-task body — small file, but still a synchronous disk read on a shared worker thread, on every app launch, unconditionally. | `lib.rs` ansuz wakeup gate |
+| 8d | ~2283-2295 Ansuz wake-up task itself | `tokio::spawn(async move {...})`, 3s initial sleep | **Yes.** `pid_file.exists()` + `std::fs::read_to_string(&pid_file)` + `std::fs::remove_file(&pid_file)` all called directly (not `tokio::fs`, not `spawn_blocking`) inside the async task. | `lib.rs` ansuz wake-up task, `pid_file` handling |
+| 8e | ~2360-2367 Ansuz daemon watcher: "selected project" resolution | inline in the mega-task (not wrapped) | **Yes, explicitly acknowledged in-code.** `std::fs::read_to_string(&projects_file)` inside a sync closure, called directly in the mega-task body. The existing comment reads *"Read projects.json directly (avoid block_in_place in async context)"* — the author knew this blocks and chose it over `block_in_place` anyway. | `lib.rs` "Auto-start Ansuz daemon watcher" block, `let selected_project_path: Option<String> = (|| { ... std::fs::read_to_string(&projects_file) ... })();` |
+| 9 | ~2360 `ansuz_daemon::start(...)` | `tokio::spawn(run_daemon(...))` inside `features::ansuz_daemon::mod.rs:133` | **Yes — the strongest single suspect found this pass.** `run_daemon`'s loop sleeps only **500ms** between iterations (`ansuz_daemon/mod.rs:290`) — the SAME nominal interval as the ready-wait TCP loop. Every iteration unconditionally does `std::fs::read_to_string(&projects_file)` (`ansuz_daemon/mod.rs:152`, direct `std::fs`, not `tokio::fs`), and when a runner PID is tracked, ALSO `std::fs::read_to_string(&models_path)` (`ansuz_daemon/mod.rs:229`, same pattern) every iteration. This loop is started (via `ansuz_daemon::start(...)`, `lib.rs` ~2360) BEFORE the Next.js sidecar is spawned in the same overall startup sequence, so it is running concurrently with the ready-wait loop for its entire duration, contending for worker threads on the identical 500ms cadence. On a cold/AV-scanned disk (the exact condition TASK_1907 measured `GET /` taking 60s+ under) `std::fs::read_to_string` can itself block far longer than the nominal interval. | `features/ansuz_daemon/mod.rs:152, 229, 290` |
+| 10 | ~2404-2429 session watcher spawn | `tokio::spawn(async move {...})`, 4s initial sleep, then `session_watcher::start(...)` | **No** — `run_watcher_with_dir` uses `tokio::fs::read_to_string` (async), not a raw blocking read. Good precedent. | `features/session_watcher/mod.rs:188` |
+| 11 | ~2446 (`#[cfg(not(debug_assertions))]`) Next.js port-availability check | inline, `std::net::TcpListener::bind` | **Technically blocking**, but `bind()`/`drop()` are near-instant syscalls, not a real contributor. Noted for completeness only. | `lib.rs` port_available block |
+| 12 | ~2517 Next.js sidecar `cmd.spawn()` | inline in the mega-task (not wrapped) | **Yes — second strongest suspect.** `tokio::process::Command::spawn()` is a SYNCHRONOUS method (not `.await`ed) — process creation (`CreateProcessW` on Windows) runs directly on whichever tokio worker thread is polling this task. On a cold/AV-scanned install this can be arbitrarily slow (same AV-scan mechanism TASK_1907 measured making `GET /` take 60s+). Now bracketed by `startup_timeline::mark("nextjs_sidecar_spawn_start"/"_done")` so a live repro can show its actual cost. | `lib.rs:2517-2524` (`match cmd.spawn() {`) |
+| 13 | ~2560 stream loggers | `tokio::spawn` x2 inside `spawn_nextjs_stream_loggers` | **No** — uses `tokio::io::AsyncBufReadExt` / async `BufReader`; `append_sidecar_log`'s `std::fs` calls run per log line, inside the async task but each is small/append-only; not flagged as a primary suspect (lower call frequency, not on the ready-wait's own critical path). | `infrastructure/nextjs_sidecar.rs:431-447` |
+| 14 | ~2578 splash status ticker | `tokio::spawn(async move {...})` | **No** — only `tokio::time::sleep` + a webview `eval()` call (IPC, not disk/DB). | `lib.rs` splash_ticker block |
+| 15 | ~2599 (in-line, same mega-task) `probe_frontend_ready(...).await` — **the ready-wait itself** | awaited call, not spawned | N/A — this is the loop being measured, not a spawn site. Its own body is now instrumented (per-attempt/per-hop timing, this task's R1 scope). | `infrastructure/nextjs_sidecar.rs:135-284` |
+| 16 | ~2698 health monitor | `tokio::spawn(async move {...})`, 20s grace, then every 15s | **Partially.** The hot path uses `tokio::time::timeout` + `tokio::net::TcpStream::connect` (non-blocking) and `tokio::task::...` is NOT used, but the respawn branch calls `new_cmd.spawn()` (same synchronous-spawn issue as #12) and `c.kill().await` / `c.wait().await` (these ARE async on `tokio::process::Child`, fine). Respawn's `cmd.spawn()` synchronous cost is the same class of issue as #12, just on the restart path instead of first boot. | `lib.rs` respawn block, `new_cmd.spawn()` |
+| 17 | ~2884 dev-mode route warmer (`#[cfg(debug_assertions)]`) | inline in the mega-task | **No** — uses `reqwest` async client + `tokio::time::sleep`; debug builds only, not relevant to the release-build fixture this task measures against. | `lib.rs` dev warm_routes block |
+| 18 | ~2939 PTY server start | `pty_launcher.start().await` | Not deep-audited this pass (bounded effort); `PtyServerLauncher::start` at `infrastructure/pty_server_launcher/launcher.rs:206` is `async fn`, awaited — likely fine, flagged for a future pass if R2 needs it. | `lib.rs:2939` |
+| 19 | ~2960-3010 heat/pulse/reaper periodic-save tasks | `tauri::async_runtime::spawn` x3, first tick after 300s/interval | **Reaper is correctly isolated** (`tokio::task::spawn_blocking(reap_idle_once)`, `lib.rs` reaper block — good precedent, explicit comment cites TASK_1924 convention). Heat/pulse saves (`heat::save_all_caches()`, `pulse::save_all_caches()`) are called directly — not deep-audited, but their first tick fires after 300s, well outside the 0-76s ready-wait window, so not flagged as a contributor to THIS measurement. | `lib.rs` periodic-save blocks |
+| 20 | ~3206 Synapse auto-index watcher | `tauri::async_runtime::spawn(async {...})`, loop every 30s | **Correctly isolated for the heavy calls** — `git2::Repository::open` and `features::synapse::index::run_index` are both wrapped in `tokio::task::spawn_blocking` (good precedent, explicit TASK_1927/1983 comments). Lighter calls (`get_index_state`, `watcher_decision`) not audited but are pure/JSON-state reads, not flagged. | `lib.rs:3236, 3336` (`tokio::task::spawn_blocking`) |
+| 21 | ~3441 (`#[cfg(not(debug_assertions))]`) updater startup check | `tauri::async_runtime::spawn`, 15s delay | Not deep-audited (bounded effort); release-only. | `lib.rs` updater block |
+
+## Top suspects (ranked)
+
+1. **`ansuz_daemon::run_daemon` loop — `features/ansuz_daemon/mod.rs:152,
+   229, 290`.** Runs on the SAME 500ms cadence as the ready-wait's own
+   `tokio::time::sleep`, started before the sidecar spawn, does a direct
+   (non-`tokio::fs`, non-`spawn_blocking`) `std::fs::read_to_string` EVERY
+   iteration, unconditionally. The single clearest "runs concurrently, on
+   the same tokio worker pool, on the same nominal interval, doing
+   synchronous disk I/O every cycle" candidate found this pass.
+2. **Next.js sidecar `cmd.spawn()` — `lib.rs:2517-2524`** (and the
+   structurally identical respawn call in the health monitor, `lib.rs`
+   ~row 16). `tokio::process::Command::spawn()` is synchronous; on a
+   cold/AV-scanned install this is exactly the class of delay TASK_1907
+   measured (`GET /` up to 60836ms) — but here it would block a tokio
+   *worker thread*, not just this task's own progress, degrading every
+   other task sharing that runtime, including the ready-wait loop that
+   runs moments later in the SAME task.
+3. **Hippocampus consolidation (`MemoryDb::open`, `lib.rs` ~1805-1858+
+   `features/synapse/memory/mod.rs:276`) and Alaya sync
+   (`GlobalMemoryDb::open`, `features/cortex/global_memory.rs:151`)
+   daemons.** Both open a rusqlite connection directly inside an async
+   task, no `spawn_blocking`. Their 60s/30s initial delays put them near
+   the tail of the 76s measured window, not the start — lower-confidence
+   contributor to the FIRST ~20s of the loop, more plausible for the
+   later attempts within the same 76s run.
+4. **`lib.rs` "Auto-start Ansuz daemon watcher" project-path resolution**
+   (`std::fs::read_to_string(&projects_file)`, explicitly commented as an
+   intentional block-avoiding-`block_in_place` choice) — a single call at
+   startup, not a loop, so lower severity than #1, but confirms the
+   pattern is a known, deliberate tradeoff elsewhere in this file too.
+
+## Root cause (measured) — R2b
+
+R1's top suspects above (`ansuz_daemon::run_daemon`'s 500ms `std::fs`
+loop, the synchronous `cmd.spawn()` calls, the rusqlite `MemoryDb::open`
+daemons) were a *hypothesis* — "the shared tokio runtime is starved by
+blocking calls" — built on a node-based control (rune_386048f8) that
+connected to the never-listens fixture's port in ~1ms and was read as
+proof the runtime, not the connect itself, was slow. That control was
+misleading: it measured Node/libuv's connect path, not the Winsock path
+`tokio::net::TcpStream::connect` actually uses on Windows.
+
+Direct measurement on this Windows machine, connecting to an UNBOUND
+loopback port:
+
+- curl: ECONNREFUSED after ~2.07s
+- .NET `TcpClient`: ECONNREFUSED after 2118ms
+- Node/libuv `net.connect`: refused after ~1ms (the misleading control)
+
+`probe_frontend_ready`'s TCP ready-wait loop (`ProbeBudget::initial()`,
+30 attempts, 500ms nominal interval) had **no timeout wrapped around the
+`TcpStream::connect` call itself**. Measured tonight on the release exe
+(0.2.238, after R2) with the never-listens fixture, the ready-wait still
+took **76190ms**; R1's own per-attempt timing line reported:
+
+```
+ready-wait TCP phase timing attempts=30 nominal_ms=14500 actual_ms=76182 max_gap_ms=2071
+```
+
+Every attempt costs a uniform ~2.5s (~2.07-2.12s refused-connect +
+~0.5s sleep) — not a handful of unusually slow outliers, which is what
+runtime starvation (occasional worker-thread contention) would look
+like. A uniform per-attempt cost close to the measured Winsock
+refused-connect latency is the signature of a missing per-attempt
+bound, not starvation: **30 x (~2.07-2.12s refused-connect + 0.5s
+sleep) ≈ 77s**, matching the measured 76190ms almost exactly.
+
+**Corrected conclusion:** the never-listens ready-wait's ~5x-nominal
+wall-clock cost is explained by Winsock's refused-connect latency on
+this Windows machine (~2s/attempt, unbounded) times 30 attempts — not
+by tokio runtime starvation from the R1 audit's blocking-in-async call
+sites. The fix (this task, R2b) wraps each TCP attempt in
+`tokio::time::timeout(budget.tcp_connect_timeout, TcpStream::connect(..))`
+with a 200ms budget (a listening localhost port completes the handshake
+in <5ms), treating a timeout exactly like a refused connect.
+
+The R1 audit table's "Blocking in async?" findings (`ansuz_daemon`'s
+500ms `std::fs::read_to_string` loop, synchronous `cmd.spawn()` calls,
+`MemoryDb::open`/`GlobalMemoryDb::open` inside async tasks, etc.) are
+real code-hygiene issues worth fixing on their own merits — direct
+blocking I/O on a shared tokio worker thread is bad practice regardless
+of whether it caused this particular symptom — but they are **not** the
+cause of the measured 76190ms never-listens ready-wait. That gap is
+fully accounted for by the unbounded per-attempt connect latency above.
+
+## Explicitly NOT done in R1
+
+- No blocking call was moved to `spawn_blocking` or a dedicated thread.
+- No timing/interval/ordering was changed anywhere (`nextjs_sidecar.rs`
+  probe logic, `ansuz_daemon` loop interval, spawn ordering in `.setup()`).
+- Rows marked "not deep-audited this pass" (MCP host child-process
+  startup, hook backfill, PTY server start, updater check, heat/pulse
+  periodic saves) were scoped out to keep this pass bounded — R2 (or a
+  follow-up audit) should re-visit those before claiming the full
+  blocking-call inventory is exhaustive.