Motir

Found by motir run MOTIR-3909, which refused the parent-run at step 0 (2026-09-01). The correction is already submitted as plan cmtj252v60022hvphvlio2sf3; this card is the defect RECORD, and it holds up nothing.

The defect

MOTIR-3909 was authored as a single container whose own acceptance criteria imply two merges separated by a deployment:

• MOTIR-4012 (manual/human) required "sign in on app.motir.co and confirm a signed-in page load is not held, then confirm a new sign-up records an acceptance" — a reading of the DEPLOYED application, whose manifest reader (MOTIR-4007) is a child of the same story.
• MOTIR-4013 was blocked_by MOTIR-4012, and MOTIR-4014 / MOTIR-4015 blocked_by that.

A parent-run puts every child in ONE pull request, so no ordering of these children finishes the story: run.md step 6 will not open the pull request while a child is un-landed, applyStatusTransition refuses the flip with CONTAINER_HAS_OPEN_CHILDREN, and the merge that would unblock MOTIR-4012 also CASCADES done onto it — green and unperformed.

What makes it worth a card rather than a note

The rule was already written down, in this epic, by this epic. MOTIR-3910's own body says:

"every card whose acceptance criteria read a deployed environment … has no legal position inside a container whose own merge produces that deployment: its pull request will not open while such a child is un-landed, and the child cannot be done until it merges. That is what went wrong in the first version of this epic, and it is why the post-deploy work is a container of its own that the code stories blocks."

MOTIR-3909 was authored after that paragraph, under the same epic, and reintroduced the shape. So the corpus mechanism that failed is not the rule is missing — the rule is in plan-rules/kind-container.md (COUNT THE MERGES A CONTAINER'S OWN CRITERIA IMPLY) and in core.md gate 14(c)/(d), and it was additionally restated in prose one story away.

Why nothing caught it

Every automated signal read clean on 2026-09-01, and each was correct:

They all answer "has every work item this one waits on reached done?", and the thing being waited on is a deployment, which is not a work item. The shape advisory family comes closest — likely-ordering-violation reads a criterion for post-merge phrasing — but it fires on a card's own criteria in isolation and this defect is a property of the card's PLACEMENT relative to its container.

The correction, already submitted

Plan cmtj252v60022hvphvlio2sf3 splits at the deploy boundary: MOTIR-3909 keeps the manifest half; a new sibling story under MOTIR-3875, blocked_by it, takes the live-gate confirmation, the deletion and its own two test gates. MOTIR-4012 is re-scoped to its set-and-read-back half and STAYS in MOTIR-3909, which is what keeps that story inert on arrival.

⚠️ The second half, which is the part a rule does not yet carry

The split as prescribed would have traded a deadlock for a silent compliance gap. MOTIR-3909 merges, deploys, and app.motir.co reads an unset manifest: recordAcceptance writes zero rows and resolveOutstanding answers [], both deliberately, so the service records no acceptances and holds nobody at /re-consent — with no error and no red test — until somebody performs the later container.

The global lesson's own remedy for this is "default to the pre-change answer … a tested arm on the card that ships the switch", which here would mean adding a filesystem fallback to lib/legal/documents.ts that the next story then removes — real work, and it re-introduces the exact coupling the story exists to break. The cheaper remedy is an ORDERING one and the corpus does not name it: a configuration value is inert until something reads it, so provision the later half's configuration INSIDE the earlier container, before its own merge. That is what the correction does, and it is the takeaway this bug carries into the lesson store.

Acceptance criteria

• The global lesson czi51tod80damzg90329pb90u is reinforced against occurrence MOTIR-3909 — DONE 2026-09-01, recurrenceCount: 2, counted: true.
• A lesson recording the provision-the-configuration-first remedy is written to the store, with its scope decided and stated. It is not a duplicate of czi51tod80damzg90329pb90u: that row prescribes a tested default ARM, and this one names the ordering alternative that needs no code.
• plan-rules/kind-container.md's merge-count section gains the same limb — that a deploy-boundary split creates an inertness obligation on the EARLIER container, and that where the later half supplies CONFIGURATION the obligation is discharged by ordering rather than by a fallback.
• The TWO HOMES are both covered (core.md gate 19): the plan-rules/ pack AND SHARED_PLANNING_RULES in motir-ai. Read the constant and say per hunk whether the mirror carries that region; where a clause is deliberately not mirrored, say so with the grep that excluded it.
• Nothing in this card re-litigates the split itself — plan cmtj252v60022hvphvlio2sf3 is the correction and a person approves it.

Context refs

• motir-meta/prompts/plan-rules/kind-container.md — COUNT THE MERGES A CONTAINER'S OWN CRITERIA IMPLY, the rule that was not applied
• motir-meta/prompts/plan-rules/core.md — gate 14(c)/(d) (the placement clause) and gate 19 (the two homes)
• motir-meta/prompts/run.md — motir run <parent>'s third refusal, which is what caught it
• motir-ai/src/seed/lessons.base.ts — the global corpus, and SHARED_PLANNING_RULES beside it
• MOTIR-3910 — the story whose own body already carried the rule
• MOTIR-3909 — the card this was filed about; relates_to

Advisory dispositions

• No blocked_by is owed to MOTIR-3909. This card's deliverable is a corpus change in motir-meta and motir-ai; it reads nothing MOTIR-3909 produces and none of its criteria stand on that story's branch. The relates_to carries the discovery trace, which is all that is owed here (run.md's planner-bug-home rule — the blocked_by limb fires only where the new card CONSUMES the found-in card).
• The remaining reference advisories name the cards this bug is ABOUT, quoted as evidence. They are the record, not a dependency.