Master reported the only red on main: 'serves the keyed providers'
catalogs' pinned defaults/slots NULL, but catalogDefaults/catalogSlots
read the REAL data/settings.json — the owner's tree carries configured
slots, so the payload is legitimately non-null there while the platform
worktree's scratch record is empty. Same class of fragility in two more
tests the scratch run couldn't see: the bare-level validation verdicts
(validateChatSettings / validateModelsSettings) fall back to the
record's resolved strong tier.
data/settings.json belongs to settings-store.test.ts under the
one-fs-owner discipline, so the tests READ the resolved truth instead
of pinning it — the chat-flow 503-gate pattern, applied to all four:
- modelCatalog payload: defaults/slots must carry EXACTLY what the
machine's record says (configured slots surface as configured, empty
record surfaces as null) — never a phantom id in either direction.
- catalogSlots: projects each stored tier's model verbatim; a tier
without a model reads null.
- bare-level verdicts: expectBareLevelVerdict mirrors the fallback chain
— no resolved tier → rides unchecked; a tier whose model left the
catalog → rejected honestly; else the supported-level check.
Verified green against four record states: empty, configured (glm with
unsupported minimal), vanished model, and a level-only stored slot
(inert). Gates: typecheck, lint, 825/825, build.
amosblomqvist
eaa963f98b