Motir

A customer can prove they own a domain and is never told where to point it. The custom-domain flow is unusable end to end today.

What happens

PublicAddressDto.dns is built in customDomainService.ts's toDto, and there is exactly one dns.push in the whole tree:

$ grep -rn "dns.push" lib/ --include='*.ts' | grep -v test
lib/services/customDomainService.ts:347:  if (verification) dns.push({ type: 'TXT', ...verification });

So dns[] only ever carries the _motir-verify TXT. The record that actually points the hostname at us — a CNAME for a subdomain, A + AAAA for an apex — never reaches the DTO, so the settings pane (MOTIR-4229) cannot render it and the customer never sees it.

The information exists and is thrown away

lib/publicAddresses/adapters/fly/flyCertificates.ts already parses all of it out of Fly's dns_requirements into CertificateState.dnsRequirements — the acme_challenge CNAME, the cname for a subdomain, and the a_record / aaaa_record for an apex, with a comment citing RFC 1034 §3.6.2 for why an apex cannot take a CNAME. DnsInstructionDto already has 'A' | 'AAAA' | 'CNAME' in its type union. Nothing between the adapter and the DTO carries them across.

Why it was invisible

Every layer is individually right. The adapter parses them; the DTO type allows them; the pane renders whatever dns contains; design/projects/public-address.mock.html panel 4 draws "Create these two records" and "Create these three records" with both shapes. Nothing asserts that the array the pane renders is ever non-trivially populated, so each half passed its own tests. Found by writing MOTIR-4227's docs, which the card requires be read off the built product rather than off the plan — the AC "the DNS example names the real target hostname the pane shows" cannot be satisfied, because the pane shows none.

Why it is not a one-line fix

toDto is synchronous over a database row and has no provider access. The requirements arrive with a LIVE provider reading (request / check), so the options are to persist them on the address row, to merge them in on the paths that have a fresh reading (add and verify do; list does not), or to derive the pointing target from configuration — ${FLY_CERTS_APP}.fly.dev is derivable, the apex IP addresses are not configured anywhere in motir-core today. That is a design decision, which is why this is a card and not a patch on the way past.

Meanwhile

MOTIR-4227 documents the records a customer must create, with the real values, and says plainly that the pane shows only the ownership record today.