MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-3190

Planning bug: a design card specified a CONSTRUCTION (a true normal-offset band) without checking it was geometrically possible at the mark's own proportions

Done
Description

Found running MOTIR-3181 on 2026-08-19 (motir run MOTIR-1343, the parent-run's design chain). The card is Blocked and a re-scope plan is submitted (cmt0t4o8o01oqi2phg2dlcvbk); this bug is the telemetry, not the fix.

What happened

MOTIR-3181 diagnosed the wave band's defect correctly and in detail — the lower edge is a vertical TRANSLATE of the upper one, so the perpendicular width is 384 · cos θ and pinches to ~41% of the crest weight. Everything in that diagnosis holds up. It then prescribed the remedy — "the lower edge is the upper edge's offset curve at a fixed perpendicular distance" — with an acceptance criterion of ≥ 0.90 measured evenness and a constraint to keep the same aspect and visual rhythm.

Those three cannot hold together, and one number settles it: an offset folds wherever the offset distance exceeds the curve's radius of curvature, the approved crest's tightest bend has R = 66.5 units, and the band is ~300 units wide. Every fold-free alternative flattens the wave into an aspect-2–3 ribbon that reads WORSE at 16 px than the pinch does. Full evidence and the amplitude sweep are on MOTIR-3181, with the specimen render attached.

The tell, and why nothing caught it

The card was authored to an unusually high standard — it read the shipped path, verified the G1 joins were already fine and said so, named what was NOT wrong, and pinned a measurable target instead of "make it smoother". That care is what made the gap invisible: the diagnosis was verified against shipped reality and the PRESCRIPTION was not. A remedy is a claim about what is constructible, and this one was checked for coherence rather than for feasibility.

It also produced a metric that would have passed a broken mark. The first emitted band measured evenness 0.9992 — comfortably over the card's 0.90 gate — while the render showed the lower edge crossing itself near the right cap. min/max perpendicular width cannot see a self-intersection at all, so the criterion the card chose to gate on was satisfied by geometry nobody would ship. A run that trusted the number over the render would have merged it.

The rule this is evidence for

Sibling of the precondition-verification rule, one step further along: that rule asks whether the things a card CONSUMES exist. This asks whether the thing a card SPECIFIES can exist.

A card that prescribes a CONSTRUCTION — a geometry, a schema shape, an algorithm with a stated bound — owes a feasibility check on the construction, not only an existence check on its inputs. Where the construction has a closed-form obstruction (a curvature bound, a cardinality, a complexity floor), the plan-time check is arithmetic and costs minutes; discovering it at run time costs the card.

And its corollary, which is the part with teeth for a design card:

A measurable acceptance criterion is not automatically a sufficient one. State what the metric CANNOT see, and pair it with the render. Here the missing half was one sentence: "and the emitted path does not self-intersect."

Acceptance criteria

  • The general rule above is added to plan-rules/phase-deepen.md beside the precondition-verification rule (the closest existing kin), with the corollary in type-design.md where the design-authoring bar lives.
  • The lesson is in notes.html with this fixture: the numbers, the 0.9992-with-a-fold observation, and the tell (a well-verified DIAGNOSIS beside an unverified PRESCRIPTION).
  • No product code changes.

Context refs

  • MOTIR-3181 — the card, its Blocked comment, and the attached specimen render.
  • MOTIR-3182 — the approval card the re-scope turns into a CHOICE between measured options.
  • plan-rules/phase-deepen.md — the precondition-verification rule this extends.