Motir

Type · planning bug (a falsified precondition on a test card) · filed by motir run MOTIR-4053, 2026-09-02 · the fix is already applied to the card, on the record.

The premise, and what falsified it

MOTIR-4079 (the story's gate, motir-ai) asked for the chain file → name the key → propose → read the edge back → confirm the story is NOT ready while the bug is open, and IS once it closes, with the last two as THE assertion, and named motir-core as "the readiness computation this asserts against, reached through the shipped read rather than re-derived."

Readiness of a PROPOSED story lives in motir-core (planValidityService.validateProjectedWorkItem, served to motir-ai over POST /api/internal/ai/validate-plan). No motir-ai lane runs motir-core. Verified against origin/main @ 0240a17:

• motir-ai/CLAUDE.md § Testing conventions: motir-ai's tests use motir-ai's OWN Postgres, never motir-core's; every suite that touches the boundary mocks src/core/coreClient.js (git grep -l "vi.mock('../src/core/coreClient.js'" tests → 20+ files), and tests/planValidationSeam.test.ts drives the validation client against a recorded fixture of core's wire shape — the discipline that exists precisely because the lane cannot reach core.
• So a readiness verdict produced inside motir-ai's suite would be a fake's verdict — a re-derivation of the thing the card said not to re-derive.

This is the lesson "A test lane's ability to drive a path is a property of the LANE'S CONFIG, never of a sibling test's subject" (global, c6085ctcyup76rg7gqre06jkr), and it was reinforced with occurrenceRef: MOTIR-4079 — the card inferred from what toolSurfaceTwoVerbs.test.ts is ABOUT (driving executors on a phase) to what the lane can DO (read core's readiness), and the boundary between the two is a config file nobody opened.

The disposition — the assertion was RELOCATED, not dropped

Per that lesson's own rule (never write the reachable subset and drop the assertions that needed it), the readiness assertion was written where the mechanism lives:

• motir-core tests/integration/ai/logBugRoute.test.ts → "THE COMPOSITION (MOTIR-4053)": file through the real route, append a proposal add with blockedByRefs: [<the bug's id>], and drive validateProjectedWorkItem against a real database — valid: false with the bug as the blocker while it is todo, valid: true once it is done. Landed on MOTIR-4076's commit (the route card), because that is the repository the read lives in.
• motir-ai tests/logBugComposition.test.ts (MOTIR-4079) asserts links 1 and 2 through the shipped path and that the run REACHES the read — the validate_plan executor is invoked with the proposed story's ref and relays core's verdict (a verbatim wire fixture) unchanged.

MOTIR-4079's body carries an amendment naming this split.

What the plan should have said

A test card whose assertion reads a computation in ANOTHER repository owes that repository's card the assertion, and says on its own body which links it asserts on its side. The one-repo-per-subtask gate already forces the split of DELIVERABLES; what it does not force is asking, per acceptance criterion, which repository's runtime produces the fact this criterion reads — the check the reinforced lesson prescribes (walk the path, list every boundary that leaves the process, name the seam). No new lesson is owed: the existing one covers the case exactly.

Evidence

• motir-ai CLAUDE.md § Testing conventions (real Postgres = motir-ai's own; contract suites fake the injected client).
• motir-ai tests/planValidationSeam.test.ts header — the recorded-fixture discipline for the validation seam.
• motir-core tests/integration/ai/logBugRoute.test.ts — where the readiness verdict is now asserted.