Motir

Telemetry about the planner, filed from the design run of MOTIR-4017 (story MOTIR-4016). The correction is already applied — the design Part states the measured answers and the card's criteria are amended on the record — so this card schedules nothing and holds nothing up.

What was asserted, and what the render measured

Both claims were authored into MOTIR-4016's story body AND into MOTIR-4017's own acceptance criteria, and both were derived from reading the source rather than from opening the page.

1. "at 1366×768 with the orb mounted the computed height is 536px against a min-h of 544px — so the page SCROLLS."

Measured on origin/main @ f9b9443e7, against a real next start server on a seeded tenant: document.documentElement.scrollHeight === window.innerHeight at 1440×900, 1366×768, 1280×800 and 1920×1080. The page does not scroll at any of them. The arithmetic in the claim is right — 536 vs 544 — and the CONSEQUENCE is wrong: the shell's pb-(--shell-bottom-clearance) (96px with the orb) absorbs the 8px overshoot. The actual shipped defect is a 91–99px dead band under the graph, which is a different thing to assert and a different thing to test for.

2. "how many nodes can a level hold and still arrive at or above the floor?" — ARRIVAL_MIN_SCALE = 0.80.

That number does not exist for this surface. The plan detail's canvas is the 1fr of a grid-cols-[1fr_22rem], so the rail takes 352px and the canvas is 782px wide at 1440×900, 708 at 1366×768 and 622 at 1280×800, against a 1000px world box at three columns. The WIDTH term (W−96)/1000 alone caps the arrival at 0.686 / 0.612 / 0.526 — below the floor — so at three of the four viewports no level of three or more nodes can reach it, whatever the story does. A six-node level measures 0.686. A criterion asking for "the count that still clears 0.80" answers two at 1440×900, which would send every plan to the list.

Why both were plausible

ARRIVAL_MIN_SCALE is a ROADMAP number: it was derived in design/roadmap/design-notes.md against the roadmap's canvas, which is the full content width and gets (1136−96)/1000 = 1.04. The constant lives in lib/planning/canvasGeometry.ts with no note that it is surface-relative, and ProjectRoadmapCanvas has four consumers, three of which sit inside the two-pane PlanningWorkspace shell. A constant derived on one mount and read on another looks exactly like a constant.

The scroll claim has the same shape one tier down: min-h exceeding a computed height DOES normally scroll a page — unless an ancestor has already reserved padding that absorbs it, which is a fact about the shell rather than about the page.

The takeaway

Both claims are of the form "the surface does X", and both were written from the component source. The design card's own rule — render the surface at the viewports before drawing a pixel — is what caught them, and it caught them on the FIRST card of the story, before six code children were sized against them.

The generalisable half: a card that quantifies over a rendered surface owes the render, not the arithmetic — and a constant borrowed from another surface's design owes a check that the borrowing surface can reach it.

What was already done

• MOTIR-4017's §2 and §6 criteria are amended on the record with the measurement.
• design/ai-planning/design-notes.md Part XIII §0 states both falsifications, §2 gives the measured budget and §6 the 24-point arrival table and the predicate the measurement supports (a node count of 12).
• Every child of MOTIR-4016 has had the corrected answers written onto its acceptance criteria.

Acceptance criteria

• This card is a RECORD. It closes when a reader has seen it; there is no build work, no repo and no sprint.