Reconcile aiConfig.architecture reads vs engine config key

Context

Surfaced during #10001 ticket-intake (PR #10121, merged 2026-04-20) while mapping the Memory Core's ChromaDB client wiring. Two call sites read aiConfig.architecture, but the config template exposes the key as engine. The || 'hybrid' fallback in both call sites silently masks the mismatch — the config key is effectively non-functional today.

The Problem

• ai/mcp/server/memory-core/config.template.mjs:155 defines engine: 'hybrid' with JSDoc explaining it as "The target Storage Architecture to use."
• ai/mcp/server/memory-core/managers/CollectionProxy.mjs:22 reads aiConfig.architecture || 'hybrid' inside getManagers().
• ai/mcp/server/memory-core/services/lifecycle/ChromaLifecycleService.mjs:53 reads aiConfig.architecture === 'chroma' || aiConfig.architecture === 'hybrid' inside initAsync().
• Neither call site consults aiConfig.engine. A curator flipping engine: 'chroma' in a custom config would observe no behavior change; the fallback to 'hybrid' wins either way.

The drift was noted in PR #10121's intake sweep but left out-of-scope for that work. Filing now per the follow-up commitment documented in that PR's body.

The Architectural Reality

The engine config key was introduced during #9922 Two-Pillar Hybrid RAG (per the template JSDoc: "The default is explicitly 'hybrid' per Epic #9922 Two-Pillar RAG architecture."). The read path was authored against aiConfig.architecture — likely an earlier key name that survived in the consumers while the canonical key renamed. No consumer today actually gates on the value; both branches of the OR always evaluate to 'hybrid'.

This is a latent mis-wiring, not a live bug. But any future work that depends on the flag (e.g., flipping to 'chroma'-only mode, or introducing a third value) will silently no-op until the mismatch is resolved.

The Fix

Pick one canonical key and align both sides. Options:

• A: Align consumers to engine — edit CollectionProxy.mjs + ChromaLifecycleService.mjs to read aiConfig.engine. Smaller diff; respects the config template's naming.
• B: Align config to architecture — rename engine → architecture in both config templates + gitignored config.mjs mirrors. Preserves consumer code; more surface area.

Recommended: Option A. The config template is the documentation surface for operators; its key name should not change. Consumers are the outliers.

Acceptance Criteria

• CollectionProxy.mjs reads aiConfig.engine (not aiConfig.architecture).
• ChromaLifecycleService.mjs reads aiConfig.engine (not aiConfig.architecture).
• No other consumer of aiConfig.architecture remains — verified via grep across ai/ and test/.
• Existing Playwright tests still pass — no behavior change expected since all current values resolve to 'hybrid' via the fallback.
• New test asserting that an aiConfig.engine flip (e.g. to 'chroma') actually changes observable behavior in getManagers() and ChromaLifecycleService.initAsync().

Out of Scope

• Introducing new engine values beyond 'hybrid' and 'chroma' — this ticket is pure reconciliation.
• Refactoring CollectionProxy / ChromaLifecycleService beyond the name fix. Any hybrid-vs-chroma behavioral cleanup is a separate ticket.

Related

• Surfaced in PR #10121 (#10001) intake sweep
• Config template: ai/mcp/server/memory-core/config.template.mjs:155
• Consumers: ai/mcp/server/memory-core/managers/CollectionProxy.mjs:22, ai/mcp/server/memory-core/services/lifecycle/ChromaLifecycleService.mjs:53
• Introduced by Epic #9922 (Two-Pillar Hybrid RAG)

Origin Session ID: 1c001810-be28-4554-bb56-c98f9b91bbfb