Motir

A RULE has two homes: motir-meta/prompts/plan-rules/ (the human source-of-record) and motir-ai's SHARED_PLANNING_RULES (the always-injected planner prompt). MOTIR-3153 sharpened gate 14(c) in the first; this mirrors it into the second, which is a different repository and therefore its own card and its own pull request.

src/llm/planningRulePacks.ts already carries the ORDERING axis verbatim in AC_SATISFIABLE_INSIDE_THE_BOUNDARY — "DOES THE CRITERION READ ON STATE THAT EXISTS ONLY AFTER THIS CARD'S OWN PR HAS MERGED?" — and, like the meta text before this pass, it stops at "belongs to a different card". The shipped planner therefore splits the criteria out correctly and is silent about where the new card may hang, which is the exact half that failed on MOTIR-3010.

The limb to mirror

A post-merge card hangs OUTSIDE the container it verifies — a sibling the container blocks — never as a child, because completing a container CASCADES done onto every child from any status (blocked included), and the parent's own merge is what completes it. "The merge closed it" and "it was verified" must not be able to be the same event. The tell: a child whose criteria read the DEPLOYMENT — a live-tenant read, a pulled artifact, a platform API — under a parent whose merge closes the parent.

Acceptance criteria

• AC_SATISFIABLE_INSIDE_THE_BOUNDARY (or whichever pack constant carries the ORDERING axis at the time) states the placement limb and its tell, in the mirror's own register — the pack constants are SHOUTED prose, not the meta file's markdown, so this is a re-statement and not a paste.
• The limb says which placement is correct (outside the container, a sibling it blocks) rather than describing the hazard and leaving the choice open.
• Whatever guard pins these constants — a snapshot, a length budget, a lint over the pack registry — is updated in the same pull request rather than worked around.
• The mirrored text and motir-meta/prompts/plan-rules/core.md gate 14(c) say the same thing; a reader comparing them finds no rule in one that is absent from the other.

Context refs

• motir-ai/src/llm/planningRulePacks.ts — AC_SATISFIABLE_INSIDE_THE_BOUNDARY, the ORDERING axis
• motir-meta/prompts/plan-rules/core.md gate 14(c) — the source-of-record half, landed by MOTIR-3153 (motir-meta#265)
• motir-meta/prompts/plan-rules/CORPUS-MAINTENANCE.md — RULES vs LESSONS, and the mirror obligation
• MOTIR-3010 · notes.html #327 — the incident