Motir

A help page on motir.co/docs that tells a customer how to give their public project its own address — written for the person editing DNS records at their registrar, not for an engineer. It documents SHIPPED behaviour, so it follows the pane and the canonical card; every instruction in it is read off the built product, not off this plan.

What ships — in motir-marketing, the docs surface's own conventions

• app/docs/public-address/page.tsx registered in lib/docs.ts and app/docs/_components/DocsNav.tsx the way the existing pages are (/docs/cli, /docs/mcp, /docs/sandbox — read lib/docs.ts for the registry shape and how a page reaches the sitemap), with the page's metadata and its JSON-LD in the docs pattern.
• Sections, in the order a customer meets them:
  1. Your Motir address — what <label>.<base>/<identifier> is, who can claim it (a workspace admin), the rules for a label, and the promise: an old address keeps redirecting after a rename and is never given to anyone else, with the rename limit stated as the product enforces it.
  2. Connecting your own domain — which plans include it (state the GATE as the product states it — available on paid plans — and link the pricing page; do NOT restate tier numbers that billing-tiering.md owns), subdomain vs apex, the two records with a worked example (CNAME roadmap → <app>.fly.dev; TXT _motir-verify.roadmap → <token>; and the A/AAAA shape for an apex), the Verify step, and how long issuance typically takes.
  3. What each status means — a table, one row per customer-domain status the pane shows (unverified · verifying · pending certificate · issued · failed · expired · revoked), with the meaning in plain words and what to do; the row set equals the product's enum — copy the labels from messages/en.json, not from memory.
  4. Which address is the real one — the primary rule (the customer domain once made primary, else the Motir address), that every other address redirects there, and why search engines see one page.
  5. Removing a domain, and what happens to the certificate.
  6. Troubleshooting — the three commonest DNS mistakes (a CNAME at an apex, a proxying DNS provider in front of the record, a stale TXT), each with the symptom the pane shows.
• Voice: the docs surface's existing register (read two shipped pages first); second person; no internal card keys, no repository paths, no environment-variable names — a customer does not have those.
• Cross-links: from the pane's help affordance (part 2 draws a Learn more link — confirm the URL this page lands at matches what the pane links) and from /docs's index.

Acceptance criteria

• motir.co/docs/public-address renders inside the docs chrome, appears in DocsNav and in the sitemap through the registry, and its metadata / JSON-LD follow the docs pattern; the docs tests in tests/docs/ cover the new entry.
• The status table has exactly one row per customer-domain status the product's en.json labels, with matching wording; the DNS example names the real target hostname the pane shows.
• The page states the plan gate as the product states it and links the pricing page; it does not name a numeric cap.
• The rename promise and the primary rule are stated in the words the pane uses, verified against the built product, and the Learn more link in the pane resolves to this page.
• No file outside motir-marketing is touched.

Context refs

• motir-marketing/lib/docs.ts · app/docs/_components/DocsNav.tsx · app/docs/cli/page.tsx · app/docs/sandbox/page.tsx · tests/docs/docs.test.ts — the docs surface and its registry
• pane 1 · pane 2 — the labels and the Learn more door; the canonical card — the primary rule as shipped
• motir-core/messages/en.json — the status labels to copy
• Notion connect-a-custom-domain-with-notion-sites, Canny setting-up-your-custom-domain, Statuspage set-a-custom-domain-and-ssl — the mirrors' help pages, for structure and register