Motir

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.

The defect

MOTIR-1143's own table specifies three cross-origin doors, and two of them carry an ?intent parameter into motir-core:

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.

Why it is not urgent, and still not nothing

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.

The takeaway

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.

Acceptance criteria

• A card owns reading ?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.
• Whichever way it goes, the motir-marketing landing asset and MOTIR-1152's criteria agree with it — the asset is the routing contract 1152 builds to, so a table it no longer matches is the same defect one layer down. This is a HAND-OFF to whoever schedules the remedy, not a measurement this card takes: read the asset as it stands on motir-marketing's default branch at that time.
• The ownership sweep is run per ROW rather than per table: every ?-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.

Advisory dispositions

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:

• MOTIR-1143 (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.
• MOTIR-1152 (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.
• MOTIR-3639 (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.

Context refs

• MOTIR-1143 — the design that specifies the contract (the relates_to).
• MOTIR-3639 — the tracker twin, already carved. The model for what the import half needs.
• MOTIR-1152 — the build, pinned to motir-marketing, which structurally cannot own the motir-core half.
• MOTIR-1461 — the shipped /onboarding entrance whose default panel is the graceful fallback.