MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-3910

THE CUTOVER — the apex moves, the certificate is issued, and every external registration follows

Blocked
Description

The out-of-band half, and the only part of this epic no pull request can carry. Every other story ends merged and deployed with nothing a visitor can see having changed. This story is where the change becomes real: the apex records, the certificate, the deployed origin values, and the external registrations that break a live journey if they lag.

Why it is a story of its own — the DEPLOY BOUNDARY

A container is completed by merging the pull request that carries its children's work, and completing a container closes its children. So every card whose acceptance criteria read a deployed environment — dig, fly certs show, curl -sI https://motir.co/, a console — has no legal position inside a container whose own merge produces that deployment: its pull request will not open while such a child is un-landed, and the child cannot be done until it merges. That is what went wrong in the first version of this epic, and it is why the post-deploy work is a container of its own that the code stories blocks.

Scope

  1. The apex. Repoint motir.co at whichever origin the ADR chose, read from the platform at the time. Change only the address records — the zone also carries the mail exchangers, a single v=spf1, the DKIM key, the shared DMARC policy and Search Console's verification token, all published by other cards for other reasons. Two v=spf1 at one name is a permanent permerror that fails CLOSED and takes human and transactional mail down together; deleting the verification record un-verifies the Domain property for every subdomain.
  2. The certificate, confirmed from the platform's own output rather than from a repository file.
  3. The deployed origin values — the public-site origin and MOTIR_BASE_URL as they are actually set on the running application, read back after setting.
  4. The external registrations, in the same sitting: Google OAuth authorised redirect URIs, Better-Auth trustedOrigins as deployed, any baked-in origin in the CLI or MCP defaults, and the Search Console sitemap submission.

⚠️ Every state claim in this story's cards is a HYPOTHESIS with a verified-no-change exit

These cards act on systems no agent can read. Each step re-reads before it writes, and where a reading differs from what the card records, it STOPS and the deviation is written up before anything changes. A DNS zone is exactly the shape where a stale premise is destructive.

Boundary

  • motir-marketing is NOT retired. The first version of this epic ended by emptying and archiving that repository, because it assumed the landing was moving into motir-core. That direction is reversed: motir-marketing keeps the landing and gains /legal, so it is a live repository with a live deployment. Nothing here retires anything.
  • It ships no diff. Every child is manual / human; there is no pull request and no repository to pin.
  • It decides nothing. The ADR is MOTIR-3876's; this story performs what that record chose.

Verification recipe

  1. https://motir.co — the landing renders, with its doors.
  2. Explore, Docs, a public project and a legal document each render on motir.co, under one chrome.
  3. https://motir.co/robots.txt and /sitemap.xml — one of each, listing the surfaces this host serves.
  4. https://app.motir.co/explore — a permanent redirect to https://motir.co/explore, query preserved.
  5. Sign in from the landing — the visitor arrives in the application on app.motir.co, and the session cookie is still host-only.
  6. Mail to and from the moooon mailbox still delivers, after the DNS edit.

Acceptance criteria

  • Every child is done; the story ships no pull request in any repository.
  • Every platform reading is pasted into a close-out comment with its timestamp — the platform's own words, not a summary, and no step is accepted on a repository file or a dashboard screenshot alone.
  • The zone's MX and TXT records are byte-identical before and after; the diff is the address records only.
  • A test mail is sent and received both ways after the DNS edit, proving the mail records survived it.
  • The journey above holds end to end against the live hosts.
  • If any reading differs from what a card records, the card STOPS and the deviation is written up before anything is changed.

Context refs

  • MOTIR-3876 — the ADR that chose the arrangement this story performs; this story is blocked_by it
  • MOTIR-2596 — the apex record table and the SPF / DMARC warnings this story obeys
  • MOTIR-1155 — the Search Console Domain property and its apex verification record
  • MOTIR-1455 — provisioned the records this story repoints
  • 8.10 — the launch smoke reads the addresses this story publishes

Advisory dispositions

  • reference → 8.10 (severity advisory): not consumed; the dependency runs the other way. The launch story's smoke reads the addresses this story publishes, so if either edge is owed it is 8.10 blocked_by this story — a story-level edge between two siblings under this epic, which is 8.10's to carry when it is next planned. This story consumes nothing 8.10 produces.