[christophersesugh]

Why main has been red since 2026-09-25

Two tests in packages/mcp-server/tests/factory.test.ts failed on every CI run:

FAIL factory.test.ts > ... > lazy wiring > initializes on the first vector operation and recalls semantically
  AssertionError: expected "vi.fn()" to be called 1 times, but got 0 times
FAIL factory.test.ts > ... > local mode with zero API keys > recall falls back to the lexical path when the adapter is absent
  AssertionError: expected "vi.fn()" to be called at least once

Root cause — not timing

The lexical assertions inside those same tests passed. Recall worked; only the mock call count was wrong. That ruled out a race.

createMemoFSMcpRuntimeFromConfig delegates the lazy adapter load into @memofs/core. Core is consumed as a built dist (exports → ./dist/index.mjs) and therefore sits outside vitest's module graph — so vi.mock("@memofs/adapter-transformers") never intercepts the import(adapterModule) inside it. CI builds core before testing (test:run dependsOn ^build), so the real adapter was constructed while the mock recorded zero calls. Local runs only passed because resolution happened to differ, which is why this was not reproducible off-CI.

Three further tests asserted the mock was not called — in CI those passed trivially and asserted nothing at all.

Fix

local-embedder.ts already documented a seam for exactly this ("Injected factory for tests so the dynamic import is not exercised") but it was never plumbed through.

• Threaded the optional adapterFactory through RuntimeFactoryOptions. Production callers omit it, so the adapter stays an optional peer dependency and behaviour is unchanged.
• Converted all five embedder-wiring tests to inject it, so assertions hold regardless of externalisation, bundling, or install state.
• Removed the dead module mock, vi.hoisted, and the beforeEach reset.

Verified

Typecheck clean, Biome clean, 48/48 in the mcp-server suite, changeset added per CONTRIBUTING.

Not reproducible locally, so this CI run is the real confirmation.

Note

The ruleset required a status check named Quality Checks, which no workflow produces — only Validate exists. That has been corrected to Validate, and admins can now bypass on PR merge, so this is mergeable.

This is also unblocking #32, #33, and #34.