Filed by motir run MOTIR-1143 while drawing the motir.co landing's routing contract. The correction is ALREADY in the asset — design/marketing/landing.design-notes.md marks the door NOT READ YET and specifies the fallback — so this card is telemetry about the plan, not scheduled build work.
MOTIR-1143's own table specifies three cross-origin doors, and two of them carry an ?intent parameter into motir-core:
| door | target | who reads it |
|---|---|---|
| 2 · import an existing project | app.motir.co/sign-in?intent=import | nobody |
| 3 · start free — just the tracker | app.motir.co/sign-up?intent=tracker | MOTIR-3639 — "8.2.10 Carry the tracker intent across the auth round trip — motir.co → /sign-up → /home" |
The tracker half was noticed and carved into its own card. The import half, specified in the same table on the same day, was not — and MOTIR-1152 (the card that builds the landing) is pinned to motir-marketing, so it cannot own a motir-core reader even in principle.
Measured on origin/main 2026-08-28:
git grep -n "intent" origin/main -- 'app/(auth)' 'lib/onboarding'
→ one hit, the word "intentionally" in a comment. No query parameter named `intent` is read anywhere.
app/(auth)/sign-in/page.tsx reads next and draft and nothing else; app/(auth)/sign-up/page.tsx reads next alone and says so in its own comment.
The door DEGRADES gracefully rather than breaking: without the parameter a visitor lands on the shipped /onboarding entrance, whose DEFAULT panel already draws the import row (MOTIR-1461). They arrive in the right place and click once more. So nothing is broken today — which is exactly why an unowned parameter can sit in a design asset indefinitely, being implemented as a link that goes somewhere reasonable and does nothing it was specified to do.
Two parameters written into one table are two seams, and carving one of them is what makes the other invisible. MOTIR-3639's existence is what makes this hard to see: a reader checking whether the intent hand-off is owned finds a card, named for the journey, blocked in the right place — and stops. The gap is not that nobody looked; it is that looking found a card.
?intent=import on app.motir.co/sign-in and routing it to the /onboarding entrance's EXISTING branch, or a decision on the record says the parameter is dropped and the door ships as a plain ?next= link.?-parameter the landing's door table specifies is checked for a reader on motir-core's origin/main AND for an owning card, and the result is stated per parameter.validate_work_item returns three reference entries. None is acted on, and here is why per entry — every one of them is PROVENANCE (where the finding came from), not substrate this card consumes:
in_progress, likely-missing-edge) — the design that specifies the contract and where the finding was made. This card consumes nothing from it: its own remedy is a motir-core reader, which is buildable today against surfaces that shipped months ago. No edge, and none is expressible: this card's parent is MOTIR-1465 and 1143's is MOTIR-656, so a leaf-level blocked_by would be the cross-parent edge plan-rules/core.md gate 7 forbids.blocked, likely-missing-edge) — named to establish that the build card structurally CANNOT own the missing half (wrong repository). Same cross-container reasoning; no edge.blocked, advisory) — the tracker twin, cited as the model for what the import half needs. Not consumed; no edge.And no blocked_by is owed to anything, deliberately. A planning bug under MOTIR-1465 is a RECORD: the correction is already applied to the asset, nobody scheduled this, and it holds nothing up. That is the planner-bug-home contract in run.md, not an omission.
relates_to)./onboarding entrance whose default panel is the graceful fallback.