kenaz 0.3.22 → 0.3.24

package/core/dev/PRODUCT_SPEC.md

@@ -1,317 +0,0 @@
----
-spec_version: "1.0.0"
-last_modified: "2026-02-20"
-changelog:
-  - version: "1.1.0"
-    date: "2026-02-20"
-    changes:
-      - "F-007 duplicate fix → 錯誤學習系統 renamed to F-008"
-      - "F-005, F-015 marked deprecated"
-      - "F-009 completed (evolved to Formation system)"
-      - "F-018, F-019 marked completed"
-      - "MVP Scope Phase 2 updated (F-004 → F-019)"
-  - version: "1.0.0"
-    date: "2026-02-02"
-    changes:
-      - "Initial versioned specification"
-      - "Added Feature ID system (F-001 ~ F-006)"
-      - "Desktop App (F-006) marked as in_progress"
----
-
-# Product Specification: Kenaz Dashboard
-
-## Overview
-
-Kenaz Dashboard 是一個 **多 Agent 協作視覺化看板**，讓開發者能即時監控 AI Agent 的工作狀態、管理任務流程、審核優化提案，並追蹤資源消耗。
-
-**核心價值**：將隱藏在終端機 Log 和 JSON 檔案中的開發狀態，轉化為直觀的視覺化介面，解決多 Agent 協作的「黑盒效應」。
-
-## Target Users
-
-- 使用 Kenaz AI 多 Agent 系統的開發者
-- 需要監控 AI 開發進度的專案管理者
-- 想要控制 Token 消耗預算的用戶
-
-## Feature ID Index
-
-| Feature ID | Title | Priority | Status |
-|------------|-------|----------|--------|
-| F-001 | 任務狀態牆 (Task Board) | P0 | completed |
-| F-002 | Agent 監控器 (Agent Monitor) | P0 | completed |
-| F-003 | 優化提案區 (Optimization Proposals) | P1 | completed |
-| F-004 | ~~RAG 狀態面板 (RAG Status)~~ | P2 | deprecated |
-| F-005 | ~~Token 消耗追蹤 (Token Tracker)~~ | P2 | deprecated |
-| F-006 | 桌面應用程式 (Desktop App) | P1 | completed |
-| F-007 | 統一後端架構 (Unified Backend) | P1 | completed |
-| F-008 | 錯誤學習系統 (.failure) | P1 | completed |
-| F-009 | 多角色團隊協作系統 (Formation) | P0 | completed |
-| F-015 | ~~.matrix Token 優化系統~~ | P0 | deprecated |
-| F-018 | 結構化 RAG 精準度優化 (Structured RAG) | P1 | completed |
-| F-019 | Kenaz Cortex Panel 優化 | P1 | completed |
-
----
-
-## Core Features
-
-### F-001: 任務狀態牆 (Task Board)
-- **ID**: F-001
-- **Description**: Kanban 風格的任務看板，分為 Backlog / Active / Done 三欄
-- **Priority**: P0
-- **Status**: completed
-- **Details**:
-  - 顯示任務卡片（標題、優先級、負責 Agent）
-  - Active 欄位顯示檔案路徑鎖定標籤
-  - 卡片閃爍效果表示 Agent 正在操作
-  - 依賴關係可視化（被阻塞的任務顯示為灰色）
-
-### F-002: Agent 監控器 (Agent Monitor)
-- **ID**: F-002
-- **Description**: 左側欄顯示所有 Agent 的即時狀態
-- **Priority**: P0
-- **Status**: completed
-- **Details**:
-  - 狀態指示：思考中 / 檢索 RAG / 寫入中 / 閒置
-  - 當前操作描述（例：「正在檢索 auth.ts...」）
-  - Agent 頭像與名稱標識
-
-### F-003: 優化提案區 (Optimization Proposals)
-- **ID**: F-003
-- **Description**: 右側區域顯示 AI 自我增強建議
-- **Priority**: P1
-- **Status**: completed
-- **Details**:
-  - 燈泡圖示提示新提案
-  - 展開查看優化理由與代碼對比（Diff View）
-  - [Accept] / [Ignore] 按鈕一鍵操作
-  - Accept 後自動轉入任務佇列
-
-### F-004: ~~RAG 狀態面板 (RAG Status)~~ [DEPRECATED]
-- **ID**: F-004
-- **Description**: ~~顯示 RAG 索引狀態與手動同步功能~~
-- **Priority**: P2
-- **Status**: deprecated
-- **Deprecated Reason**: 已被 F-019 Kenaz Cortex Panel 取代，RAG 功能整合進 Cortex Control Panel
-
-### F-019: Kenaz Cortex Panel 優化
-- **ID**: F-019
-- **Description**: Cortex Control Panel 修復與優化，整合雙層記憶管理
-- **Priority**: P1
-- **Status**: completed
-- **Replaces**: F-004
-- **Details**:
-  - 移除舊 RAG Status Panel，統一使用 Kenaz Cortex Panel
-  - 修復所有 Cortex API 端點 404 問題
-  - Conscious Memory（專案記憶）：切換專案時自動聯動
-  - Subconscious Memory（全局記憶）：鎖定開發者指定的 ChromaDB，用戶不可更換
-  - Export/Import GPU Embedding 工作流程
-  - Agent 使用監控
-  - 手動檔案索引
-
-### F-005: ~~Token 消耗追蹤 (Token Tracker)~~ [DEPRECATED]
-- **ID**: F-005
-- **Description**: ~~即時統計 Token 使用量與預估費用~~
-- **Priority**: P2
-- **Status**: deprecated
-- **Deprecated Reason**: 已棄用
-
-## Technical Requirements
-
-### Frontend
-- **Framework**: Next.js 14+ (App Router)
-- **UI Library**: shadcn/ui + Tailwind CSS
-- **State Management**: React Query (TanStack Query)
-- **Real-time**: Polling (1-2 秒) 或 WebSocket
-
-### Backend
-- **API Routes**: Next.js API Routes
-- **External API**: Python FastAPI (Orchestrator)
-- **File Watching**: chokidar 或 fs.watch
-
-### Data Sources
-| 檔案路徑 | 用途 |
-|---------|------|
-| `dev/pipeline/tasks/*.md` | 任務定義 |
-| `dev/pipeline/PROGRESS.md` | 進度追蹤 |
-| `dev/pipeline/TASK_QUEUE.json` | 任務佇列 |
-| `dev/pipeline/LOCK_STATE.json` | 路徑鎖定狀態 |
-| `dev/pipeline/AGENT_STATE.json` | Agent 狀態 |
-| `dev/pipeline/SELF_ENHANCEMENT_STATUS.json` | 自我增強狀態 |
-| `dev/pipeline/logs/*.log` | Agent 操作日誌 |
-| `.claude/METRICS.json` (新增) | Token 消耗統計 |
-
-### API Endpoints (Python Orchestrator)
-| Method | Endpoint | Description |
-|--------|----------|-------------|
-| GET | `/api/tasks` | 獲取所有任務 |
-| GET | `/api/agents` | 獲取 Agent 狀態 |
-| GET | `/api/metrics` | 獲取 Token 統計 |
-| POST | `/api/proposals/:id/accept` | 核准優化提案 |
-| POST | `/api/proposals/:id/ignore` | 忽略優化提案 |
-| POST | `/api/rag/sync` | 觸發 RAG 同步 |
-
-## Page Layout
-
-```
-+------------------+------------------------+------------------+
-|                  |                        |                  |
-|  Agent Monitor   |     Task Board         |  Optimization    |
-|  (Left Sidebar)  |     (Kanban)           |  Proposals       |
-|                  |                        |  (Right Panel)   |
-|  - Agent 1: Idle |  Backlog | Active | Done                  |
-|  - Agent 2: 寫入  |    [Card]  [Card]  [Card]  |  [Lightbulb]   |
-|  - Agent 3: RAG  |    [Card]  [Card]  [Card]  |  [Accept]      |
-|                  |                        |  [Ignore]        |
-+------------------+------------------------+------------------+
-|                     Status Bar / Token Tracker               |
-+--------------------------------------------------------------+
-```
-
-## Success Metrics
-
-- 開發者能在 3 秒內了解當前專案狀態
-- 優化提案審核時間從閱讀 Markdown 的 5 分鐘縮短至 30 秒
-- 減少 50% 的終端機與 IDE 之間的 Context 切換
-
-## MVP Scope
-
-**Phase 1 (MVP)**:
-1. 任務狀態牆（基本 Kanban）
-2. Agent 監控器（狀態顯示）
-3. 基礎 API 串接
-
-**Phase 2**:
-4. 優化提案區 + 一鍵審核
-5. ~~RAG 狀態面板~~ → 已被 F-019 Kenaz Cortex Panel 取代
-
-**Phase 3**:
-6. Token 消耗追蹤
-7. 依賴關係圖
-8. Diff View 代碼對比
-
-**Phase 4 (Desktop App)**:
-9. Tauri 桌面應用打包
-10. Rust PTY 終端機整合
-11. 自動更新機制
-
----
-
-### F-006: 桌面應用程式 (Desktop App)
-- **ID**: F-006
-- **Description**: 將 Dashboard 打包成可本地執行的輕量級桌面應用程式
-- **Priority**: P1
-- **Status**: completed
-- **Details**:
-  - 使用 Tauri 框架整合 Next.js（更輕量、效能更好）
-  - 使用 Rust portable-pty 替代 node-pty（原生終端機）
-  - 支援 Windows 平台（優先），後續擴展 macOS/Linux
-  - 連接 GitHub Releases 檢查更新
-  - 自動下載並安裝新版本
-  - 更新進度 UI 顯示與用戶通知
-
-### F-008: 錯誤學習系統 (.failure)
-- **ID**: F-008
-- **Description**: 建立失敗經驗記錄系統，讓 AI Agent 能從錯誤中學習並避免重複失敗
-- **Priority**: P1
-- **Status**: completed
-- **Completed**: 2026-02-05
-- **Details**:
-  - 失敗記錄分類系統（Agent 執行、代碼品質、架構、Pipeline、數據完整性）
-  - 失敗嚴重程度定義（Critical/High/Medium/Low）
-  - 標準化失敗記錄模板（根因分析、解決方案、預防措施）
-  - Agent 工作流程整合（執行前檢查、失敗時學習）
-  - 自動化工具（記錄失敗腳本、檢查失敗模式腳本）
-  - 失敗經驗轉化為規則的機制（`.failure/` → `.rule/`）
-
-### Technical Requirements (Desktop)
-- **Framework**: Tauri 2.x + Rust
-- **PTY Library**: portable-pty (Rust)
-- **Auto Update**: tauri-plugin-updater
-- **Update Server**: GitHub Releases
-- **Build Tool**: tauri-cli + tauri-action
-
----
-
-### F-009: 多角色團隊協作系統 (Formation)
-- **ID**: F-009
-- **Description**: 多角色協作模式，已演進為 Formation 系統（unit/solo/squad/legion 四種陣型）
-- **Priority**: P0
-- **Status**: completed
-- **Completed**: 2026-02-06（MVP）→ 已演進為 Formation 系統
-- **Details**:
-  - 團隊結構定義系統（TEAM.yaml）
-  - 成員角色定義（members/*.yaml）
-  - 權限矩陣與衝突防止（permissions/scope_matrix.yaml）
-  - 工作流程引擎（workflows/*.yaml）
-  - 團隊調度器（orchestrator/team_scheduler.py）
-  - 訊息佇列與共享上下文（communication/）
-  - 路徑鎖定機制（防止多成員同時寫入同一文件）
-  - 審批流程（關鍵操作需多人同意）
-
-**團隊範例**：
-- **Product Manager Team**（已實作）：PM Lead, Doc Specialist, Assessment Analyst, Research Specialist, QA Validator, Code Reviewer
-- **Backend Team**（規劃中）：Backend Lead, API Developer, Database Specialist, Doc Specialist, QA Engineer, Security Specialist, Performance Engineer
-- **Frontend Team**（規劃中）：Frontend Lead, UI Developer, UX Specialist, Doc Specialist, QA Engineer, Accessibility Expert
-
-**核心機制**：
-1. **權限管理**：每個成員只能訪問特定路徑（R/W/E/X 權限）
-2. **並行執行**：多個成員同時工作（如 Doc + Assessment + Research 並行分析）
-3. **衝突防止**：排他性路徑鎖定（如 TASK_QUEUE.json 同時只能一人寫入）
-4. **工作流程**：標準化流程（8 階段任務建立流程）
-5. **團隊通訊**：訊息佇列與共享上下文
-
-### Technical Requirements (.team)
-- **Language**: Python 3.9+ (orchestrator)
-- **Configuration**: YAML (團隊、成員、權限、工作流程)
-- **Orchestration**: asyncio (並行執行)
-- **Communication**: JSON (訊息佇列、共享上下文)
-- **Lock Management**: 文件鎖定機制（first-come-first-served）
-
----
-
-## Feature ID Reference Guide
-
-**Feature ID 格式**: `F-XXX`（三位數字，支援 001 ~ 999）
-
-**任務追溯**：當建立新任務時，`source` 欄位應引用對應的 Feature ID，例如：
-- `source: "F-001"` → 追溯到任務狀態牆功能
-- `source: "F-006"` → 追溯到桌面應用程式功能
-
-**子功能 ID**：若需要細分功能，可使用 `F-XXX.Y` 格式：
-- `F-006.1` → Desktop App - Tauri 初始化
-- `F-006.2` → Desktop App - Rust PTY 整合
-
----
-
-### F-007: 統一後端架構 (Unified Backend)
-- **ID**: F-007
-- **Description**: 統一 Tauri IPC 和 HTTP API，減少維護成本，讓瀏覽器/手機能訪問完整功能
-- **Priority**: P1
-- **Status**: completed
-- **Details**:
-  - 在 Rust 後端新增 HTTP Server（使用 axum）
-  - HTTP routes 調用現有的 core 邏輯（scheduler/core.rs 等）
-  - 前端 api.ts 在 Web 模式改調 Rust HTTP API
-  - 移除冗餘的 Next.js API Routes
-  - 支援區域網路訪問（手機預覽 UI）
-
-### Technical Requirements (Unified Backend)
-- **HTTP Framework**: axum (Rust)
-- **Port**: 8080 (可配置)
-- **啟動時機**: Tauri 應用啟動時自動啟動 HTTP server
-- **API 路徑**: `/api/*` (與現有 Next.js routes 相容)
-
----
-
-### F-015: ~~.matrix Token 優化系統~~ [DEPRECATED]
-- **ID**: F-015
-- **Description**: ~~建立極簡 DSL 格式的規則存儲系統，達成 5-10:1 Token 壓縮比~~
-- **Priority**: P0
-- **Status**: deprecated
-- **Deprecated Reason**: 已棄用，方向已改變
-
----
-
-*Generated by Product Manager Agent | 2026-01-29*
-*Updated with Feature ID System | 2026-02-02*
-*Updated with F-007 Unified Backend | 2026-02-05*
-*Updated with F-015 .matrix System | 2026-02-07*

package/core/dev/PROJECT_REGISTRY_DUPLICATE_ASSESSMENT.md

@@ -1,86 +0,0 @@
-# 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

@@ -1,181 +0,0 @@
-# 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.