8.3.6 Build the motir-marketing landing (new repo) — THREE cross-origin doors: idea hero · import existing · start free

Type: code · Executor: coding_agent · Repo: motir-marketing. The targetRepo pin is deliberately NOT set yet — motir-marketing is not among the workspace's connected repositories (gh repo list moooon-B-V, 2026-08-26), and an unknown pin fails the whole approve in resolveAuthoredTargetRepoInProject. Pin it once MOTIR-1455 provisions and connects the repo.

▶ REPLAN 2026-06-30 (Yue). Build the public marketing landing in the motir-marketing repo (motir.co) from the MOTIR-1143 design + MOTIR-1144 copy, consuming the shared design-system package (MOTIR-1456).

▶ AMENDED 2026-08-26 — a THIRD door. The landing was scoped to two entries while Motir has three onboarding journeys; the non-AI tracker path (MOTIR-655) had no route from the public web at all. Entry 3 below is what this amendment adds.

Server-render the landing: top nav, hero, feature blocks, social proof, footer. Then wire all three doors. Each is a cross-origin hand-off; no connect / import / chat / source-selection UI is built here — every one of those is owned downstream (7.15 / 7.17 / 7.3), and this card stops at the redirect.

• Entry 1 — hero idea input (start fresh). Submit → the pre-auth draft API (MOTIR-1458, done): POST the idea → draftId → redirect to motir-core/sign-in?draft=<id>. motir-core preserves it through auth and pre-fills the shipped /onboarding entrance's CARRIED panel (MOTIR-1462, reusing MOTIR-1022's seam). NOT a query param — the idea travels as a draft id.
• Entry 2 — "import an existing project" CTA. Repo / Jira / Linear → motir-core/sign-in?intent=import (no idea draft). After auth → the /onboarding existing branch → 7.15 / 7.17.
• Entry 3 — "Start free" (NEW). The tertiary, non-AI door into motir-core's tracker onboarding. Build the target from the seam contract MOTIR-1118 records — do not assume the shape written here. The working assumption is motir-core/sign-up?intent=tracker, and it is only an assumption: /sign-up reads no such parameter today, and the shipped cross-auth preservation seam (MOTIR-1458) targets /sign-**in**, so the route and the carrier are both open questions that 1118 settles for BOTH ends at once. After auth the reader lands on /home, which renders the shipped create-first door, and MOTIR-1168 reads the intent to open the 8.2 first-run. This end of the seam only has to emit the link correctly — the door works whether or not 1168 has shipped, because /home's no-project state is already actionable (motir-core/docs/decisions/home-scope.md §2.2). That is why this card carries no blocked_by into 8.2.

Root generateMetadata; the entity-signal SEO root (MOTIR-1154) lands here because motir.co is the brand root. Responsive + a11y per the design.

The cross-origin base URL is configuration, not a literal. The motir-core origin differs between local, preview and production, so read it from one env var and fail the build loudly when it is unset — three doors hardcoding app.motir.co is three places to be wrong. Adding a required env var to a deployment creates a provisioning obligation: file the manual provisioning card before this one closes if MOTIR-1455 has not already set it.

Acceptance criteria

• The landing renders the full responsive page from the shared DS package + the MOTIR-1143 design + the MOTIR-1144 copy, with all three doors present and reachable by keyboard.
• Entry 1: the hero submit forwards through the pre-auth draft API and lands on motir-core/sign-in?draft=<id>; the idea survives auth into the onboarding entrance, verified end to end. No idea is dropped on long input or across OAuth, and a failed POST renders the designed error state rather than silently discarding what was typed.
• Entry 2: the import CTA links to motir-core/sign-in?intent=import.
• Entry 3: the "Start free" nav entry and hero sub-line link to the route and parameter MOTIR-1118's record pins (motir-core/sign-up?intent=tracker unless that record says otherwise). Quote the record on the PR, so both ends of the seam are demonstrably built from one source.
• All three targets are built from ONE configured motir-core origin; the build fails with a named error when that variable is unset (assert this with a test, not by inspection).
• No connect / import / source-selection / chat UI ships on the marketing site.
• Build + CI green in motir-marketing.

Context refs

• blocked_by: MOTIR-1455 (scaffold + domain + CI) · MOTIR-1456 (DS package) · MOTIR-1143 (design) · MOTIR-1144 (copy) · MOTIR-1458 (done — the draft receiver) · MOTIR-1150 (done — brand mark)
• relates: MOTIR-1022 (the preservation seam reused) · MOTIR-1459 (the /onboarding fork entries 1–2 land in) · MOTIR-655 (the first-run entry 3 lands in)
• EVIDENCE, not deliverables (they live in motir-core): app/(auth)/sign-in/page.tsx — reads ?draft and holds a signed-in reader on the page when one is present · docs/decisions/home-scope.md §2.2–2.3 — what a ?intent=tracker visitor meets after auth

⚠️ NO blocked_by ONTO MOTIR-1118 — a deliberate exclusion, not an oversight. This card READS 1118's record and does not CONSUME its output: the criterion above ships the assumed /sign-up?intent=tracker and lets the record override it, so the card is buildable whether or not 1118 has landed. The edge was drawn and then removed on evidence: validate_work_item on MOTIR-656 returned valid: false with it, because 1118 sits outside 8.3's subtree — the edge would have made the whole marketing story un-finishable, and a lift to the story tier (656 blocked_by 655) would hold the brand mark, the SEO root and the directory listings behind first-run for work only ONE of 8.3's children reads. The mitigation is a criterion, not an edge: the PR quotes the record, so both ends of the seam are demonstrably built from one source. If the record later pins something the assumption contradicts, that is a re-scope of this card, not a missing dependency.