Make Memory Core provider-key diagnostics local-first

Context

The operator corrected a stale premise during the active Agent Harness / Memory Core work: GEMINI_API_KEY is no longer the right assumed key for current local/provider-routed flows; the ask path can use a custom role-specific key, and Memory Core should not imply that setting the old shared Gemini key is the universal repair.

This is a bounded residual under the still-open cost-safety parent. #12740 largely closed the silent remote-spend class through local-first defaults, KB ask routing, harness key hygiene, and backfill pacing, but current Memory Core health/error surfaces still carry Gemini-specific diagnostics.

V-B-A evidence before filing:

• ai/config.template.mjs now defaults chatProvider / modelProvider to openAiCompatible, not Gemini.
• ai/services/memory-core/HealthService.mjs:1149 checks whether the configured providers need Gemini, but :1314 still emits GEMINI_API_KEY not set - summarization features unavailable as the degraded detail.
• ai/services/memory-core/HealthService.mjs:1458-:1466 still documents GEMINI_API_KEY as required for all memory operations, even though local generation and local embeddings can be healthy without it.
• test/playwright/unit/ai/mcp/server/memory-core/Server.spec.mjs pins the stale GEMINI_API_KEY not set - summarization features unavailable text in server error expectations.
• ai/services/memory-core/MemoryService.mjs:871-:894 already routes mini-summary generation through buildChatModel({modelProvider: aiConfig.modelProvider, ...}), so the user-facing diagnostic should describe the active configured provider, not a global Gemini-only repair.
• ai/services/knowledge-base/SearchService.mjs now uses NEO_KB_ASK_API_KEY for ask synthesis via askSynthesis.apiKey, so KB ask no longer proves a shared GEMINI_API_KEY requirement.

Memory-mining / historical context:

• Prior incident session e8f07ef9-ef7e-4815-8ff4-7abe13720621 mapped the Gemini cost-safety cluster and filed #12740.
• Prior #12759 / #12741 work fixed a sibling health-gate pattern by making the Knowledge Base gate provider-aware and local-provider-safe rather than Gemini-key-bound.
• #12740 latest triage already recommended reducing the parent to bounded residual leaves if any remaining current-state mismatch survives V-B-A.

Live duplicate / freshness sweeps immediately before creation:

• Live latest-open sweep checked the latest 30 open issues at 2026-06-15T04:27Z, including newly opened #13299, #13297, #13287, #13295, #13012, #12740, and adjacent Memory Core/Agent Harness tickets; no equivalent provider-key diagnostic leaf found.
• Targeted live searches for GEMINI_API_KEY Memory Core ask provider custom key, memory core GEMINI_API_KEY summary provider custom env, Memory Core summarization provider GEMINI_API_KEY, and Memory Core mini-summary provider defaults #12740 found only the parent #12740, closed #12741, closed #12744, and unrelated/closed entries.
• A2A in-flight claim sweep checked the latest 50 all-state messages at 2026-06-15T04:27Z; recent claims covered #13289, #13295, #13292, #13287, and #13167, with no Memory Core provider-key diagnostic claim.
• Local exact sweep over resources/content/issues and resources/content/discussions found #12740 / #12743 historical mentions, not an open leaf for this residual.
• KB ticket semantic sweep for Memory Core health GEMINI_API_KEY summarization provider local first ticket surfaced #12768, #12450, and #12671 context, not an equivalent open ticket.

The Problem

Memory Core can be configured local-first today, but its health/error vocabulary still teaches operators and agents the older Gemini-only mental model. During degraded states, a user without GEMINI_API_KEY but with valid local/provider-specific config can see or inherit guidance implying the old key is required.

That is more than stale prose: these strings feed MCP errors, tests, GitHub artifacts, and future KB/Memory retrieval. Agents then re-assert the wrong premise, as happened in this session.

The Architectural Reality

• Provider choice is owned by AiConfig. ADR 0019 says to read resolved leaves at use sites and avoid parallel provider aliases unless a successor decision explicitly changes the SSOT.
• Memory Core summary and mini-summary paths already consume aiConfig.modelProvider through buildChatModel().
• Memory Core embedding readiness is also provider-dependent; Gemini requires GEMINI_API_KEY, but local OpenAI-compatible / Ollama paths have different readiness predicates.
• HealthService already exposes providers.summary and providers.embedding; those blocks are the right place to tell operators which provider is active and what key/host is missing.
• Server-level MCP error tests currently pin the stale string, so the correction must include test expectations.

The Fix

Make Memory Core health and server error diagnostics provider-specific and local-first:

• Replace the generic GEMINI_API_KEY not set - summarization features unavailable detail with a provider-aware detail derived from the active aiConfig.modelProvider / embedding provider state.
• Update ensureHealthy() JSDoc and nearby comments to stop claiming both ChromaDB and GEMINI_API_KEY are required for all memory operations.
• Preserve the existing gate behavior where an embed-dependent tool still fails when the configured embedder is unavailable.
• Update focused server/HealthService unit expectations so tests pin provider-aware diagnostics instead of the stale Gemini-only wording.
• Do not add a new summaryProvider SSOT; use the existing resolved provider leaves per ADR 0019.

Contract Ledger Matrix

Decision Record impact

aligned-with ADR 0019. This ticket should read resolved AiConfig provider leaves and must not introduce a parallel provider selector.

Acceptance Criteria

• Memory Core no longer emits GEMINI_API_KEY not set - summarization features unavailable as the generic summarization degraded detail when the active provider context should be described instead.
• ensureHealthy() documentation no longer claims GEMINI_API_KEY is required for all memory operations.
• MCP server error tests are updated to expect provider-aware diagnostics while preserving the existing exempt/non-exempt tool behavior.
• At least one focused test proves local-first provider config does not ask the operator to set GEMINI_API_KEY.
• Gemini-specific missing-key messaging remains available only when the active configured provider is actually gemini.

Out of Scope

• Changing provider defaults; #12742 already did that.
• Reworking KB ask synthesis; #12741 already did that and the current ask path uses NEO_KB_ASK_API_KEY.
• Rewriting embedding provider implementation internals beyond the diagnostic surface required here.
• Closing parent #12740; this leaf only removes one current residual.

Avoided Traps

• Treating absence of GEMINI_API_KEY as proof Memory Core should degrade in local-first deployments.
• Adding a new summary-provider SSOT instead of using AiConfig's existing provider leaves.
• Weakening the health gate so embed-dependent tools run without a working embedder.
• Bundling this with unrelated cost-safety residuals like live-AI test opt-in or billing reconciliation.

Related

Parent: #12740 Related: #12741, #12742, #12744, #12743

Release classification: post-release cost-safety residual (boardless unless operator elevates).

Origin Session ID: e8f07ef9-ef7e-4815-8ff4-7abe13720621 Retrieval Hint: "Memory Core provider-key diagnostics GEMINI_API_KEY local-first healthcheck ensureHealthy #12740 residual"