Summary
StatusResult (Models/QueryResults.cs:241-310) reports DB-level facts (Files, Symbols, References, Languages) and readiness flags but exposes zero process-level health: no GC.GetTotalMemory(false) snapshot, no GC.GetGCMemoryInfo().HeapSizeBytes, no per-generation collection counts, no working-set size. Users running cdidx as a long-lived MCP server cannot tell whether memory growth is the index DB on disk or the process heap, can't diagnose "MCP server slow" as GC pressure vs. SQLite contention, and have no early-warning before OOM kill.
Distinct from #1632 (no doctor / env-summary subcommand) — that is about environment detection at startup; C278 is about runtime process-health reporting on every status invocation.
Where
src/CodeIndex/Models/QueryResults.cs:241-310 (StatusResult shape)src/CodeIndex/Database/DbReader.FilesStatus.cs:358-433 (GetStatus producer)
Suggested approach
(1) Add a process sub-object to StatusResult with heap_bytes, gc_gen0_count, gc_gen1_count, gc_gen2_count, working_set_bytes. (2) Compute via GC.GetGCMemoryInfo() and Process.GetCurrentProcess().WorkingSet64. (3) Default the field on (it's free to compute), document that it's read at status-call time so values reflect "now" not historical peak.
Summary
StatusResult(Models/QueryResults.cs:241-310) reports DB-level facts (Files, Symbols, References, Languages) and readiness flags but exposes zero process-level health: noGC.GetTotalMemory(false)snapshot, noGC.GetGCMemoryInfo().HeapSizeBytes, no per-generation collection counts, no working-set size. Users running cdidx as a long-lived MCP server cannot tell whether memory growth is the index DB on disk or the process heap, can't diagnose "MCP server slow" as GC pressure vs. SQLite contention, and have no early-warning before OOM kill.Distinct from #1632 (no doctor / env-summary subcommand) — that is about environment detection at startup; C278 is about runtime process-health reporting on every status invocation.
Where
src/CodeIndex/Models/QueryResults.cs:241-310(StatusResult shape)src/CodeIndex/Database/DbReader.FilesStatus.cs:358-433(GetStatus producer)Suggested approach
(1) Add a
processsub-object toStatusResultwithheap_bytes,gc_gen0_count,gc_gen1_count,gc_gen2_count,working_set_bytes. (2) Compute viaGC.GetGCMemoryInfo()andProcess.GetCurrentProcess().WorkingSet64. (3) Default the field on (it's free to compute), document that it's read at status-call time so values reflect "now" not historical peak.