Add Memory Core runtime freshness to healthcheck

Context

During the v13 cost-safety workstream, the source/config state and the running Memory Core MCP process diverged in a way the healthcheck did not make falsifiable.

Observed sequence:

• Local dev was refreshed and the ignored ai/config.mjs overlay was migrated to the current provider defaults: chatProvider: 'openAiCompatible' and modelProvider: 'openAiCompatible'.
• The running Memory Core MCP healthcheck still reported providers.summary.active = 'gemini', model = 'gemini-3.5-flash', local = false, and a configured Gemini key.
• The source-level fix was already present; the stale value came from the still-running MCP process, not from the migrated config source.
• Evidence was posted on #12742: https://github.com/neomjs/neo/issues/12742#issuecomment-4650364477

Duplicate and adjacency sweep:

• Live latest-open sweep: checked the latest 20 open issues at 2026-06-08T15:14:50Z. #12768 is adjacent but scoped to trimming Memory Core healthcheck token cost; no equivalent Memory Core runtime-freshness issue was open.
• Targeted live search for "Memory Core runtime freshness healthcheck" found #12765 closed, #12768 open, and older non-equivalent health/readiness work.
• #12765 / PR #12766 implemented the runtime-freshness minimum for github-workflow only. Its PR body explicitly kept scope to that minimum server.
• KB ticket semantic sweep for "Memory Core runtime freshness healthcheck stale config migration" returned older non-equivalent Memory Core health/readiness tickets (#10127, #10949, #12382, etc.). #12382 was response/count staleness; this ticket is runtime source/config identity staleness.
• Exact source/docs grep found runtimeFreshness only in ai/services/github-workflow/HealthService.mjs, not in the Memory Core service or OpenAPI schema.

The Problem

Agents and operators need to distinguish three states quickly:

1. the checked-out source/config has the correct local-first provider defaults;
2. the running MCP process booted from older config/source and needs restart/reload;
3. the healthcheck payload is genuinely reporting a current remote provider path.

Today, Memory Core reports provider blocks and liveness, but not enough runtime identity to tell whether those provider blocks came from the current checkout/config or a stale long-lived process. That produces a bad debugging loop: the healthcheck is technically healthy, but it can send agents back into already-fixed source code or duplicate ticket creation.

This is especially risky in the cost-safety workstream because stale remote-provider readings can look like a regression in AiConfig or provider routing when the actual fix is an operator restart of the MCP process.

The Architectural Reality

Relevant current surfaces:

• ai/services/memory-core/HealthService.mjs builds the Memory Core healthcheck payload and reports provider blocks, topology, orchestration state, and availability.
• ai/mcp/server/memory-core/openapi.yaml publishes the Memory Core healthcheck schema to clients/agents.
• ai/services/github-workflow/HealthService.mjs now has the precedent implementation from #12765 / PR #12766: a compact runtimeFreshness block that exposes source/schema/config drift for the running MCP process.
• ai/scripts/setup/initServerConfigs.mjs can migrate ignored config overlays, but that does not restart already-running MCP servers.
• ADR 0019 says AiConfig is the reactive Provider SSOT. This issue must not re-implement or mutate config resolution; it should only compare runtime identity/freshness signals around the current SSOT-owned surface.
• #12768 is the paired constraint: the Memory Core healthcheck should become leaner, not gain a broad migration census or expensive deep diagnostics.

The Fix

Add a compact runtimeFreshness diagnostic to Memory Core healthcheck, analogous in intent to the GitHub Workflow implementation but shaped for Memory Core's provider/config surface.

Expected implementation shape:

• Capture enough boot-time identity to recognize the running MCP process: boot git SHA/source identity, OpenAPI/schema digest where cheap, and relevant config/template identity for provider routing.
• Resolve current identity cheaply at healthcheck time and compare it to the boot snapshot.
• Report current, stale, or unknown with concise details and a restart/reload hint when stale.
• Keep stale runtime identity as warning metadata, not a generic service outage. A stale process can still answer mailbox queries; the point is to stop false source-level debugging.
• Update the Memory Core OpenAPI schema and unit coverage.
• Coordinate with #12768 so this field remains compact and does not re-expand the healthcheck payload that ticket is trimming.

Contract Ledger Matrix

Decision Record Impact

Aligned with ADR 0019. This ticket reads around the AiConfig-owned surface for runtime freshness, but it must not create a new config alias, fallback default, pass-through config object, or mutation path.

Acceptance Criteria

• Memory Core healthcheck exposes a compact runtimeFreshness block with current, stale, and unknown outcomes.
• The block compares boot-time identity against current checkout/config/schema identity enough to detect the observed post-migration stale-runtime class.
• A stale runtime produces a concise restart/reload hint while preserving the service's true health status.
• ai/mcp/server/memory-core/openapi.yaml documents the new healthcheck surface.
• Unit tests cover current, stale, and unknown branches via injected identity/config readers; no live MCP restart is required.
• The PR body explicitly coordinates with #12768 and shows that the default healthcheck payload remains lean.

Out of Scope

• Automatically restarting Memory Core, the harness, or any MCP server.
• Reopening #12742 or #12769; their source/provider default work remains complete.
• Moving the Memory Core healthcheck trim/migration-census work owned by #12768.
• Changing provider defaults or adding fallback model names. Runtime freshness observes drift; it does not decide provider routing.
• Solving Knowledge Base ask_knowledge_base synthesis provider routing; that remains covered by the adjacent cost-safety lane.

Avoided Traps

• Do not treat providers.summary.active = 'gemini' after a migrated config as proof that source defaults are still wrong.
• Do not broaden Claude's #12768 healthcheck-trim ticket; this is the missing diagnostic counterpart.
• Do not add expensive healthcheck probes to make the freshness signal feel comprehensive. Compact falsifiability is the goal.
• Do not rely on package version alone. The failure mode is running-process/source-config drift, not release-version drift.

Related

Parent: #12740

Related: #12742, #12765, #12766, #12768, #12769

Origin Session ID: e8f07ef9-ef7e-4815-8ff4-7abe13720621

Handoff Retrieval Hints:

• query_raw_memories("Memory Core runtimeFreshness healthcheck summary.active gemini stale config migration #12742 #12765 #12768")
• query_documents(query="Memory Core runtime freshness healthcheck stale config migration", type="ticket")
• Source anchors: ai/services/memory-core/HealthService.mjs, ai/mcp/server/memory-core/openapi.yaml, ai/services/github-workflow/HealthService.mjs