Planning bug: MOTIR-3487 claims an E2E lane 'already has every piece' from a sibling spec's SUBJECT — the spec seeds the ledger and its own header says the writer path has no seam

Found by motir run MOTIR-3417, guard #4, against origin/main@ccf0c7e8. The correction is already submitted as plan cmt9x420c00r4i2n8ysrzcym8; this is the telemetry about how the card came to say something false.

The defect

MOTIR-3487 opens with a section headed "The lane already has every piece this needs — verified on origin/main@7e97e2ed", and adds "This card assembles existing scaffolding; it stands nothing new up. Each of these was read before being named."

Two of the four pieces it names do not do what it says:

• tests/e2e/migrate-index-fleet.spec.ts is described as "already driv[ing] the index fleet to indexed through the fake orchestrator … so no real container and no Fly credential is involved." It SEEDS job_run ledger rows (recordIndexSucceeded / recordIndexRunning / recordIndexFailed, 8 call sites) and never executes the writer path.
• tests/e2e/_helpers/migrate-index-seed.ts is named beside it as if it were fleet scaffolding. Its exports are ledger seeders.

The spec's own header says so, in the file the card cites: "The writer side (boot → poll → settle against the orchestrator port) is not reachable from a browser-driven server at all: bootIndexContainer first mints a motir-ai run credential and resolves a GitHub pre-signed tarball URL, and neither has an E2E seam."

Why the claim was plausible

The spec's SUBJECT is the index fleet, its filename says so, it uses the fake orchestrator, and it does drive a repo to indexed — on the surface that reads the ledger. Every one of those is true. What is false is the inference from "this spec is about the index fleet" to "this lane can execute the index fleet", and the two are separated by a boundary that lives in playwright.config.ts rather than in the spec.

The evidence that settles it

grep -rn 'tarball\|run-credential' lib/test-*mock*.ts returns nothing; grep -rn 'GITHUB_APP_PRIVATE_KEY' playwright.config.ts tests/e2e/ returns nothing.

What it cost, and what it would have cost

It cost this run one card: MOTIR-3487 is Blocked and its prerequisite is proposed. What it would have cost if the premise had gone unchecked is the thing worth recording — the reachable half of the card (coalescing, repo independence, the dashboard) is writable against the QUEUE ROW, so the cheap path is to write those three, skip assertions 3 and 4, and close the card green. The story's criterion "a supervisor survives a worker restart mid-run … asserted by a test that actually restarts, not by reading the code" would then have been discharged by nothing.

The rule that would have prevented it

A card claiming an existing test LANE can drive a path is making a claim about the lane's CONFIGURATION, not about any spec's subject matter. It is checked by naming, per external dependency the path crosses, the seam that stubs it — and grepping the lane's config for that seam. A sibling spec that looks like it exercises a path is not evidence; its header frequently says which half it actually covers.

Acceptance criteria

• MOTIR-3487's evidence section is corrected on the record: the two mis-described pieces named for what they are, and the claim "it stands nothing new up" withdrawn.
• The authoring rule above lands wherever the corpus keeps precondition-verification guidance, stated as a check on the LANE'S CONFIG rather than on a sibling spec.
• The lesson recorded for this incident is linked from here.

Context refs

• MOTIR-3487 — the card, and its BLOCKED comment carrying the full evidence table
• Plan cmt9x420c00r4i2n8ysrzcym8 — the correction, awaiting review
• tests/e2e/migrate-index-fleet.spec.ts — the cited spec, and the header that says what it does not cover
• playwright.config.ts vs playwright.acceptance.config.ts — the two lanes and what each sets