Filed by motir run MOTIR-2695 (2026-08-11). The correction is already applied to the plan — this card is the telemetry, and it holds up nothing.
MOTIR-2694 decided residency option (a) — "embed in motir-core, expose a search endpoint the planner calls … (a) keeps the data where it already is and makes motir-ai ask rather than hold" — and planned MOTIR-2696 as "Schema + write path (motir-core)", targetRepo: motir-core, one PR. Its step 5 even names the hazard correctly — "Embedding is an EXTERNAL call: it must not sit inside the work-item write transaction" — so the plan knew a network call was involved.
What it never asked was who makes that call.
origin/main 2026-08-11)motir-core cannot produce an embedding. LLM_GATEWAY, EMBEDDING and embeddings return zero hits across its lib/ and app/. There is no provider key, no gateway token, and no embedding seam — by design: motir-ai's docs/decisions/embedding-provider.md §1 puts every embedding call through the 9.0 metering gateway from the closed service, and motir-ai is the half that holds LLM_GATEWAY_TOKEN.
So the card as planned was unbuildable as a single-repo PR. Every way of closing the gap needs a motir-ai deliverable — a POST /v1/embeddings for motir-core to call, or an ai-side pusher — except "give motir-core its own gateway credential", which puts an LLM credential in the open-source repo and creates a second metering identity for one tenant's spend. The gap was structural, not a matter of which option won.
POST /v1/embeddings in motir-ai, blocked_by MOTIR-2695, and now blocking MOTIR-2696. A foundation two consumers need is its own card, not a fold-in to the first consumer.motir-ai call, the pgvector CI image) written into its body, so a sibling card no longer describes a mechanism the ADR replaced (notes.html #51).motir-core docs/decisions/plan-tree-embeddings.md §6.2) records the decision, the rejected credential-in-core alternative, and the gap itself.The precondition-verification rule: a card pinned to a repo is a claim that the repo can do the work. Residency was reasoned about as a data question — where the bytes rest — and the ADR still answers it the same way. The unasked half was the capability question: the service that stores a derived artifact is not automatically the service that can derive it. Those two questions come apart precisely at an open-core boundary, which is where this plan sat.
It fired at the right place. The entrance card was ordered first exactly so the shape would be settled before anything built on it, and the gap cost one new card instead of a blocked motir run on MOTIR-2696 discovering it at worktree time. The defect is real; the sequencing worked.
None in product code. The plan correction above is the fix. Close this once MOTIR-2695's PR merges; it exists so the pattern is countable.