Mirror the widened design-allocation sweep into `SHARED_PLANNING_RULES` — the shipped planner must sweep the TREE, not the asset's key list
Repo: motir-ai. One PR. The second home of the widening that MOTIR-2450 lands in motir-meta/prompts/plan-rules.md.
Why this card exists
A standing planning RULE has TWO homes:
motir-meta/prompts/plan-rules.md— the MANUAL planner.SHARED_PLANNING_RULESinmotir-ai/src/llm/treeGeneration.ts— the SHIPPED planner. Its own comment calls it "the encoding ofplan-rules.md", and it is composed by both fresh tree generation and re-planning (src/jobs/handlers/replan.tsimports it), so a rule missing here is missing from every plan the product generates.
The design-allocation limb is already mirrored there — MOTIR-2156 put the TAKES-as-well-as-GIVES half in. So this card amends an existing passage rather than adding one; the mirrored text carries the same asset-bounded discharge the source did, and therefore the same defect.
What to mirror
LIFT the wording from the plan-rules.md design-allocation limb as MOTIR-2450 leaves it — do not re-derive it. Compressed to the constant's register, it must preserve both load-bearing changes:
- The sweep is over the TREE, not the asset's key list. The
MOTIR-<n>keys a design names say where to START; a re-slice between the design's authoring and its merge puts the affected card outside that list entirely. Fixture: the asset named its story asMOTIR-2255andgrep -c 'MOTIR-2282'over it returned0, whileMOTIR-2282was the story whose shipping premise the design had invalidated. - GIVES/TAKES reads on an element, a STRUCTURE, or a PREMISE — not elements alone. A design that replaces a layout topology or invalidates a card's shipping gate answers "neither" to the element-only question.
Edit (c) of the source card — re-homing the run-time half off run.md guard #3 — is run.md's and has no mirror: the shipped planner authors plans, it does not execute a design gate. Do not carry it over.
Scope BOUNDARY
SHARED_PLANNING_RULES (and its test) only. It does NOT change any job handler, prompt assembly, or generation behaviour beyond the rule text. It does NOT touch motir-meta — that is MOTIR-2450's PR, which this card is blocked_by.
Acceptance criteria
- The design-allocation passage in
SHARED_PLANNING_RULESstates the sweep is over the TREE with the asset's key list as a starting point only, and asks GIVES/TAKES over an element, a structure or a premise — in the constant's existing register and formatting. - The wording is lifted from the merged
plan-rules.mdlimb rather than re-derived — quote the source paragraph in the PR body beside the mirrored text so the two are diffable by eye. - A test asserts the constant contains both changes (match the existing assertions' style in the constant's own spec — enumerate the existing design-allocation assertions from MOTIR-2156 first and extend them, rather than adding a parallel test).
- Both the fresh-generation and re-plan composition paths still include the constant — asserted, not assumed:
src/jobs/handlers/replan.tsimports it and that import is covered.
Context refs
motir-ai/src/llm/treeGeneration.ts—SHARED_PLANNING_RULES, and the design-allocation passage MOTIR-2156 added. ⚠️grepsilently finds nothing in this file (very long lines) — search with python/node.motir-ai/src/jobs/handlers/replan.ts— the re-plan composition path that imports it.motir-meta/prompts/plan-rules.md— the source wording (MOTIR-2450).- MOTIR-2448 / MOTIR-2099 — recent mirrors, for precedent on shape and size.