---
id: w5/m10/t003
title: Capture Render's live add-domain DNS-instructions flow
worker: worker5
status: done
estimate: 30m
depends_on: []
---

## Objective

Capture Render's actual post-add custom-domain experience as the design source: what DNS instructions appear (record type, host, target) for a subdomain vs an apex, how verification state is presented, and whether/how a manual "Verify" re-check exists — so t004/t005 build against observed behavior, not guesses.

## Context

- The m7/m11.5 pattern: capture the live Render dashboard (Playwright MCP, screenshots to `.playwright-mcp/` with bare filenames) or, if no Render login is available, fall back to render.com/docs/custom-domains + the captured artifacts in `docs/render-artifacts/` and say so.
- Known from docs: Render shows the CNAME target + verification state and re-checks until the cert issues (`w5/006`); apex domains get ANAME/ALIAS-or-A-record guidance.
- bex's current shape for comparison: `DomainView{domainType, verificationStatus, serverStatus}` (`lego/backend/internal/apps/domains.go`), with no DNS-target field and no explicit verify verb (ledger row "Verify / DNS instructions" is ◐).

## Steps

1. Drive Render's add-domain flow live (or docs-fallback) for one subdomain and one apex; record the exact instruction text/fields and the re-check behavior.
2. Note Render's REST `POST …/custom-domains/{id}/verify` semantics vs the dashboard behavior.
3. Write findings + screenshots into a short capture note (extend `docs/render-artifacts/`) for t004/t005 to consume.

## Files

- `docs/render-artifacts/` (new capture note + screenshots in `.playwright-mcp/`)

## Acceptance criteria

- [ ] Subdomain and apex instruction shapes captured (record type, host, target, copy affordances).
- [ ] Verification/re-check behavior documented (automatic cadence vs manual verify).
- [ ] Fallback (docs-only) explicitly noted if the live dashboard was unreachable.

## Out of scope

- Any implementation (t004/t005).
