Motir

Type: manual · Executor: human · NEW in the 2026-06-30 8.3 replan. Stand up the new motir-marketing repo (the public marketing site is no longer motir-core's app/page.tsx).

✅ UNBLOCKED 2026-08-27 — the host is decided: FLY. MOTIR-2854 landed docs/decisions/marketing-site-hosting.md (motir-core#2383). motir.co is served by a second Fly app, motir-marketing, in org moooon, region iad — Q1. This card's title, its host bullet and its second acceptance criterion have been re-scoped accordingly; the ADR's §7 is the authority if this body and it ever disagree.

The Vercel option is gone in both senses. It was rejected on the merits (ADR §2, quoting application-hosting.md §5), and separately the project was DELETED on 2026-08-26 by MOTIR-2396 — "deleted, not downgraded; both production URLs 404". There is nothing left to attach to.

Read 2026-08-27: motir-marketing still does not exist, and motir.co apex + www still resolve to nothing — so nothing here has been started. Originally surfaced by MOTIR-2518's Vercel sweep.

▶️ RUN 2026-08-28 — everything reachable from a terminal is DONE; the DNS records and the origin allowlist are the remainder. The repo, the Fly app, the app-scoped token, CI, a deployed scaffold and both certificates all exist; https://motir-marketing.fly.dev/ serves 200 and motir.co still resolves to nothing pending two Spaceship records. The full readings — including the pool / floor / VM-size measurement this card owes — are in the provisioning comment on this card. Its record tables are the authority for what exists; this body is the scope.

• Create the motir-marketing GitHub repo (same org/owner as motir-core; CLA/branch-protection consistent with motir-core).
• Create the Fly app motir-marketing in org moooon, primary region iad, beside motir-core and motir-ai. fly.toml configures; it does not provision — the machine set comes from the deploy, and the pool/floor from fly scale count, which this card sets and RECORDS from the platform rather than from the file (application-hosting.md Amendment 7).
• Mint an APP-scoped deploy token — flyctl tokens create deploy -a motir-marketing — and set it as the repository's FLY_API_TOKEN. Not an org token: an app token cannot create Machines and cannot see sibling apps, and it does carry registry.fly.io write for its own app.
• Attach the domain: fly certs add motir.co and fly certs add www.motir.co, then write the two DNS records at Spaceship (the zone stays there — nameservers launch1/launch2.spaceship.net):
  • motir.co → A + AAAA, the app's dedicated addresses read from fly ips list.
  • www.motir.co → CNAME to the app's Fly hostname, the shape app.motir.co already uses.
  • ⚠️ DO NOT TOUCH THE APEX MX / TXT RECORDS, and do not write a second v=spf1. MOTIR-2596 published the apex mail records on 2026-08-26; two v=spf1 at one name is a permanent SPF permerror that fails CLOSED. The apex TXT set grew again on 2026-08-27: MOTIR-1155 added google-site-verification=0qj6BfE6tIjXBQo8zSZHtfGxbLcCUbtNStGC_m55XUA, and deleting it un-verifies the Search Console property for the whole domain. Read both cards' record tables before adding anything to this zone. And the apex cannot take a CNAME at all while those records exist (RFC 1034 §3.6.2) — which is why A/AAAA above, and part of why Fly was chosen (ADR §3).
• Coordinate with story 8.5 (domain/SSL) so the app domain and motir.co don't collide. (app.motir.co already resolves to Fly's motir-core; the apex and www are free.)
• Wire CI (lint + build) mirroring motir-core's gates, then its deploy job — superfly/flyctl-actions/setup-flyctl + flyctl deploy --local-only --app motir-marketing, on push to main, in its OWN non-cancelling concurrency group (fly-deploy-marketing). Mirror the SHAPE, do not copy ci.yml: it declares needs on seven jobs that will not exist. ADR §4 has the table.
• Configure the cross-origin allowlist both ways: motir.co may POST to motir-core's draft endpoint (8.3.13); motir-core /login accepts the redirect from motir.co.
• Submit the marketing sitemap once the site actually serves — MOVED to 8.3.7 on 2026-08-28. There is nothing here to submit: this card ships an empty scaffold, and the sitemap it would name is 8.3.7's deliverable in the new repo. The deferred tail of MOTIR-1155 — add https://motir.co/sitemap.xml to the existing verified Search Console Domain property, which needs no new property, no new verification and no token — now lives with the card that builds the file, along with the "Couldn't fetch" settling behaviour. What stays here is the record this card must NOT disturb: MOTIR-1155's google-site-verification= apex TXT, above.

The Next.js app skeleton + the landing code are the build subtask (8.3.6); this card is the repo/domain/deploy provisioning only. Note the host implies output: 'standalone' + a Dockerfile, not a static export — that constraint belongs to 8.3.6.

⚠️ The scaffold this card deploys is CRAWL-BLOCKED on purpose. app/robots.ts in motir-marketing ships disallow: / — a thin placeholder indexed at the apex is worse than no page at all. Flipping it off is 8.3.7's, named in the file's own comment. This card must not flip it: doing so would index the placeholder.

Acceptance criteria

• motir-marketing repo exists with CI green on an empty scaffold; motir.co resolves to its production deploy on the Fly app motir-marketing, and www.motir.co with it.
• The apex mail records are unchanged after the DNS work — re-dig motir.co MX and TXT and confirm MOTIR-2596's values are byte-identical, with exactly ONE v=spf1, and that MOTIR-1155's google-site-verification= TXT is still present (Search Console reports the property as unverified if it is dropped).
• The pool and availability floor are recorded on this card as read from the platform (fly status / fly scale count), not from fly.toml.
• Origin allowlist confirmed between motir.co and motir-core (for 8.3.13).

No PR in motir-core — type: manual, done on the user's confirmation.

Moved off this card 2026-08-28 — a note, NOT a criterion. The sitemap-submission criterion ("https://motir.co/sitemap.xml is submitted to the existing verified Search Console Domain property and reports Success") now sits on 8.3.7, which owns robots + sitemap and is the card that creates the file. Every criterion remaining above is provisioning; that one was content, and it was unmeetable against a one-page placeholder. This card is NOT blocked_by 8.3.7 — the edge runs the other way and already exists (this card blocks it); reading a dependency out of this paragraph would close a cycle.

Context refs

• docs/decisions/marketing-site-hosting.md — Q1 (the host), Q2 (the DNS records and the apex constraint), Q3 (the CI shape), §7 (what this card owes), §8 (what it deliberately leaves to this card).
• docs/decisions/application-hosting.md — Amendment 7 (a fly.toml cannot provision; the floor is the availability decision), Q7 (the CDN trigger, if egress ever justifies one).
• MOTIR-1155 — the apex google-site-verification= TXT this card must not disturb. Its Search Console property is already created and DNS-verified and covers this host; the sitemap submission INTO it moved to 8.3.7 on 2026-08-28.