Motir

Verify, on the LIVE deployment, that the capability MOTIR-3878 shipped actually works end to end — a real customer domain, a real certificate issued by Fly on the motir-marketing app, and the canonical served from it. Every acceptance criterion here is a read of the platform or of a live host, never of a file in a repository.

Why this is a sibling of the story under the epic, not a child of it

A card whose criteria read the deployment cannot live inside the story it verifies: completing a container cascades done onto every child, and the story's own last merge is what completes it — so a child that reads production would be closed by the event it is meant to check (plan-rules/core.md gate 14(c)). It therefore hangs beside the story under the epic, blocked_by the story. That edge crosses kinds (task ← story); it is the shape the gate prescribes and is recorded here rather than left implicit.

Recipe

1. Precondition read. fly secrets list -a motir-core shows FLY_CERTS_TOKEN, FLY_CERTS_APP and MOTIR_PUBLIC_TENANT_DOMAIN; fly certs list -a motir-marketing shows the base domain and its wildcard issued (both were the provisioning cards' job — this step confirms nothing regressed).
2. Tenant subdomain. In a workspace you control, claim a subdomain in Settings → Public address; open https://<sub>.<base>/<identifier> from a browser with no Motir session — it renders the project; curl -sI https://motir.co/p/<identifier> answers 301 with location on the new address.
3. Customer domain. Point a domain you control (a subdomain by CNAME, following the pane's instructions), add it, create the TXT, press Verify; watch the state move unverified → pending → issued in the pane. Read the SAME state from the platform: fly certs check <host> -a motir-marketing reports the certificate issued, and curl -sI https://<host>/ answers 200 with a valid chain (openssl s_client -connect <host>:443 -servername <host> shows the issuer).
4. Primary. Press Make primary; curl -s https://<host>/ | grep -o '<link rel="canonical"[^>]*>' names https://<host>/; the subdomain address and motir.co/p/<identifier> both 301 to it; https://<host>/sitemap.xml and /robots.txt name only that host.
5. Rename. Rename the subdomain; the old one 301s to the new one and is refused when re-claimed by another workspace.
6. Failure state. Remove the TXT (or point the CNAME away) and let the status job run; the pane shows the failure state the design draws, with an action a customer can take.
7. Record every command and its output on this card, and publish the browser recording of steps 2–5 to the card.

Acceptance criteria

• Each numbered step above has its command and the literal output pasted on this card, dated, with the host names used.
• fly certs check <host> -a motir-marketing for the customer domain reports the certificate as issued, and the browser shows a valid certificate for the same host.
• The canonical, og:url, sitemap.xml and robots.txt read from the primary host name only that host; the two non-primary addresses answer 301 to it.
• The renamed subdomain's previous name still redirects after the rename.
• A recording of the settings flow and the resulting public page is attached to this card.

Context refs

• MOTIR-3878 — the story this verifies; its verification recipe is the source of steps 2–5
• motir-core/docs/decisions/public-tenant-addresses.md — the ADR (Q5 names the certificate path being read; Q6 the canonical rule)
• Fly — https://fly.io/docs/flyctl/certs/ (fly certs check, fly certs list)