Summary
When fold_ready=false, the CLI status command populates degraded_reason, recommended_action, and alternative_action via BuildFoldNotReadyExplanation() (src/CodeIndex/Cli/QueryCommandRunner.cs:1644-1648). The MCP status tool (src/CodeIndex/Mcp/McpToolHandlers.cs:937-954) does not mirror this logic — it only emits hotspotFamilyDegradedReason and sqlGraphContractDegradedReason. So MCP clients see the readiness bit drop but receive no actionable explanation. CLI vs MCP signal asymmetry.
Where
src/CodeIndex/Cli/QueryCommandRunner.cs:1644-1648 (CLI fold-degradation explanation)src/CodeIndex/Mcp/McpToolHandlers.cs:937-954 (ExecuteStatus — fold context missing)src/CodeIndex/Models/QueryResults.cs:331-344 (StatusResult fields defined but partially populated)
Suggested approach
- Extract the fold-degradation reason logic (
BuildFoldNotReadyExplanation, BuildFoldBackfillCommand, etc.) into a shared helper module reachable from both CLI and MCP.
- In
McpToolHandlers.ExecuteStatus(), after the hotspot/sql population, populate the symmetric fold fields when fold_ready is false.
- Consider introducing a nested
FoldSignal record parallel to the existing HotspotFamilySignal / SqlGraphContractSignal for shape parity.
- Add an integration test comparing CLI
status --json and MCP status response: assert identical degradation metadata for a fold-degraded fixture DB.
- Document the readiness signal contract once in
DEVELOPER_GUIDE.md so both paths reference one source of truth.
- Update the status-contract section of
CLAUDE.md / AGENTS.md to mention the parity requirement.
Summary
When
fold_ready=false, the CLIstatuscommand populatesdegraded_reason,recommended_action, andalternative_actionviaBuildFoldNotReadyExplanation()(src/CodeIndex/Cli/QueryCommandRunner.cs:1644-1648). The MCPstatustool (src/CodeIndex/Mcp/McpToolHandlers.cs:937-954) does not mirror this logic — it only emitshotspotFamilyDegradedReasonandsqlGraphContractDegradedReason. So MCP clients see the readiness bit drop but receive no actionable explanation. CLI vs MCP signal asymmetry.Where
src/CodeIndex/Cli/QueryCommandRunner.cs:1644-1648(CLI fold-degradation explanation)src/CodeIndex/Mcp/McpToolHandlers.cs:937-954(ExecuteStatus — fold context missing)src/CodeIndex/Models/QueryResults.cs:331-344(StatusResult fields defined but partially populated)Suggested approach
BuildFoldNotReadyExplanation,BuildFoldBackfillCommand, etc.) into a shared helper module reachable from both CLI and MCP.McpToolHandlers.ExecuteStatus(), after the hotspot/sql population, populate the symmetric fold fields whenfold_readyis false.FoldSignalrecord parallel to the existingHotspotFamilySignal/SqlGraphContractSignalfor shape parity.status --jsonand MCPstatusresponse: assert identical degradation metadata for a fold-degraded fixture DB.DEVELOPER_GUIDE.mdso both paths reference one source of truth.CLAUDE.md/AGENTS.mdto mention the parity requirement.