Planning bug: two MOTIR-3249 children were pinned to ONE repo while their criteria need the other

Found while running motir run MOTIR-3249 (2026-08-20). Two of the story's seven children are pinned to a single repository and cannot be satisfied there. Neither is a straddle the author overlooked in prose — both cards NAME the other repository's file in their own Context refs, so the pin and the body disagree with each other on the card itself.

The two

MOTIR-3252 — pinned motir-core, needs motir-ai. Its criteria require the dispatch to decide "a snapshot exists AND its codegraphVersion matches the engine the container will run" and to carry a pre-signed GET. motir-core knows neither fact and cannot mint the grant: CodeRepo is motir-ai's table (grep -rn 'snapshotKey\|codegraphVersion' motir-core/lib returns nothing on origin/main), and ADR §5 states the container path holds "no object-storage credential — motir-ai mints a single-key upload grant instead", which is equally true of motir-core. Run as the two-PRs-one-card contract flow (run.md guard #5, check 2): motir-ai#257 mints, motir-core#2223 forwards.

MOTIR-3250 — pinned motir-ai, one criterion needs motir-core. "The timings appear in the job's returned output, so /v1/events/<id>/runs shows them without shell access to the container." The container → motir-core channel is the exit code and nothing else: lib/orchestrator/types.ts's ContainerStatus carries state / terminal / timestamps / exitCode and no log or output surface — its own comment says "the container writes no ledger row and its logs are the operator's" — and IndexDispatchOutcome.settled carries a teardown reason, a verdict derived from that exit code, and usage. Nothing under lib/orchestrator/ reads container logs. The premise that a container's returned output reaches the Inngest run record is FALSE, and no motir-ai change can make it true.

Why the shape detector did not catch either

validate_work_item's likely-repo-straddle reads a card's acceptance criteria for paths in a repository other than its targetRepo. Both cards name the other repository only in their Context refs — MOTIR-3252 lists motir-ai/src/codegraph/graphSnapshotStore.ts and motir-ai/prisma/schema.prisma; MOTIR-3250 lists motir-core/lib/services/codeGraphIndexDispatchService.ts — and their criteria are written in prose that names no path at all. validate_work_item returned valid: true with no shape advisory for either.

The fix, which is a rule change and not a row edit

1. MOTIR-3252 should carry the repository SET (targetRepos: ['motir-core', 'motir-ai']) rather than a single pin — run.md's own words for this case: "that card should usually be re-pinned to carry the set instead."
2. MOTIR-3250's Inngest-visibility criterion belongs to a motir-core card that does not exist — a container → dispatcher telemetry channel is its own piece of work, not a line inside a motir-ai instrumentation card.
3. The candidate general rule: gate 1's repo check should read a card's Context refs as well as its criteria. A ref naming <other-repo>/path on a card pinned elsewhere is the same claim as a criterion naming it, and it is the form these two took. Whether that belongs in the shipped likely-repo-straddle detector or in the authoring bar is the question this bug asks — notes.html #219 says: if the check already ships, widen the check rather than writing prose beside it.

Acceptance criteria

• MOTIR-3252 carries both repositories (or the split is recorded as two cards, with the reason).
• MOTIR-3250's Inngest-visibility criterion is cut from that card and lives on a motir-core card, or is recorded as declined with the evidence above.
• The repo-pin check reads Context refs as well as acceptance criteria, in whichever tier already owns it, with a test over a card shaped like MOTIR-3252.