[ClaydeCode]

Closes #13. Supersedes FreeshardBase/web-terminal#47 for the root UI: Sundial is replacing the web-terminal, so the owner email work lands here.

What is in it

Owner card, first in Settings, bound to the owner's user row (GET/PATCH /protected/users/me), not to the identity and not to the controller profile.

• Name writes through via PATCH {display_name} (reuses fs-editable-text).
• Email: PATCH {email} makes it the candidate (pending_email); the live value changes only on confirmation. States: no address (a prompt, not an error), pending (live address plus the candidate, Send again, Discard; a new address replaces the candidate), set. When GET /protected/settings reports email_enabled: false the address is set directly and there is no resend control. Note: the issue names oidc.email_verification as the signal; email_enabled from /protected/settings is what shard_core actually exposes.
• A 502 from the PATCH is not a failed save. When it carries shard_core's JSON detail, the candidate is stored and only the mail did not go out: the card refetches the row, says exactly that and offers Send again. A successful resend clears the message. A bare 502 from the proxy (shard_core down, nothing stored) stays a failed save. 429 shows the server's detail; 403 says only the owner can change the address.
• Emptying the field clears the address (PATCH {email: null}), as web-terminal#47 did.
• Settings keeps one card instance across its full re-renders, so a WS update neither refetches the row nor throws away an edit in progress.
• Pending/confirm pattern (the issue asks for one): pendingChange() in js/components/pending-change.js renders a candidate in a dashed sheet with a state label, a status line or warning, and equal-weight follow-up actions. The state derivation stays a pure, unit-tested function next to the feature (js/owner-email.js). Documented in agents.md.

Confirmation landing at /?confirm_email=<token>. main.js takes the token out of the URL (history.replaceState) before routing and hands it to the new confirm-email view. The anonymous-to-welcome redirect leaves that route alone, because the link is usually opened on a device that was never paired. It works at / and under /sundial/. The view confirms only on a click (mail scanners and prefetchers would otherwise spend the single-use token) and never logs the token.

The owner email leaves the public and duplicate places: no mailto on Welcome, no email field on Public, no Owner / Owner email in the Settings About list (that was the controller's copy of the same values). The unused i18n keys are gone.

Mock dev server: users/me (GET, PATCH), resend, discard, settings, confirm-email. Under just serve, /?confirm_email=dev-token confirms the mock candidate; --no-email mimics a self-hosted shard.

Difference from the issue: 204 either way

POST /public/users/confirm-email answers 204 whether or not the token matched (anything else would let a caller probe for pending addresses; checked in shard_core/web/public/users.py on freeshard main), 422 on a malformed body and 429 on a flood of misses. So the landing cannot report success or failure. Its copy is hedged: "If the link was still valid, your address is now confirmed…", it names the one-hour expiry, and it points to Send again in Settings. 429 and network failures get their own messages.

Review panel

Rebased onto main after #44 merged; the only conflict was js/main.js boot (both imports kept, PUBLIC_ROUTES plus #44's oidcReturnQuery() on the welcome redirect). Then five fresh reviewers ran one at a time against the diff and the issue, without the implementer's reasoning, each fix committed before the next reviewer started.

Reviewer	Blocking	Resolution
Adversarial (correctness)	none	Fixed three confirmed advisories in be7fd5c: focus left the email input on every 30 s disk-usage re-render of Settings; a save, resend or discard rebuilt both fields and threw away an edit in the other; confirming an unchanged address PATCHed it again, which re-sent the confirmation mail and spent the send budget.
Test adversary	3	All fixed in 3910239: the token URL being pushStated instead of replaced, a delayed self-firing confirm (the 100 ms sleep is now a fake clock run for a minute), and a failed discard showing success were each invisible to the suite. Also added tests for confirm and resend being disabled while in flight, 422 on confirm, 429 on resend, an unreadable /settings, markup in a candidate address, and token-free Referers on boot requests. Each new test was checked against a mutation of the code under it.
DevEx / readability	1	Fixed in 1a90589: the confirm view's state comment omitted invalid. Also took the cheap advisories (naming, why-comments, test names stated as behaviour, agents.md wording).
Security	none	Fixed in a49af31: a paired browser opening /?confirm_email=T&oidc_rd=... left for the authorize URL and dropped the token unspent (also flagged by the adversarial reviewer).
UX (Daylight Instrument, rendered)	3	All fixed in 0a8fa17: the landing asked to confirm "this address" with no address on the page; the after-click hint pointed to Settings on a device that may never have been paired; the pending block never said mail keeps going to the live address until confirmation. German copy reworked where flagged.

Open advisories, not done here:

• Toasts double-escape interpolated values (t() escapes, the toast sets textContent), so a&b@x.org would show as a&b@x.org. Repo-wide, the same applies to existing toasts such as toast.installFailed.
• Focus falls to <body> after Send again, Discard and Confirm (the buttons are rebuilt).
• Small layout points: [empty] directly above "No address yet.", two stacked "cannot send email" sentences when mail is off and a candidate exists, the pending note at body size next to small hints, the candidate in mono next to the live address in sans.
• owner-card.js tracks its load lifecycle in three fields (#loaded, #loadFailed, #user === null); one state field would read better.
• freeshard-core, not this PR: the resend POST is reachable from a form on an app subdomain (domain-scoped cookie, no CSRF check); pairing.py makes pairing codes with random.choices instead of secrets.
• Rollout: the mail link is https://<shard>/?confirm_email=, so it only reaches Sundial on shards where Sundial serves /.

Recommended reading order

1. js/owner-email.js: token parsing, the three states, the 502 discriminator
2. js/components/pending-change.js, js/components/owner-card.js: the pattern and the card
3. js/views/settings.js: wiring, About removal
4. js/main.js, js/views/confirm-email.js, js/components/dock.js: the landing
5. js/views/welcome.js, js/views/public.js, js/store.js: removals
6. js/i18n/*.json, css/ui.css, css/views.css
7. tools/dev_server.py, then tests/unit/owner-email.test.js, tests/e2e/owner.spec.js, tests/e2e/confirm-email.spec.js, tests/e2e/owner-email-public.spec.js
8. agents.md

Verification

• just check: all modules parse. python3 tools/check_i18n.py: 0 problems.
• npm run test:unit: 129/129 pass. E2e: 94/94 pass (after the rebase onto Return to the app login after pairing (oidc_rd) #44 and the review fixes below).
• Mutation check: each new test was run against a deliberate mutation of the code under it, 24 mutations in total, and every one made its test fail. Among them: dropping the refetch after the 502 (the first read has no candidate and later reads have the normalised one, so only the refetch can show it), keeping the delivery message after a resend, treating any 502 as delivered, confirming one tick after mount (the test drains a tick before asserting), dropping confirm-email from the anonymous allow-list, keeping the token in the URL, logging the token, offering resend with mail disabled, re-adding the Welcome mailto and the Public email field, re-rendering or refetching the card on re-attach. Two control edits (comment-only) left the tests green, which confirms the harness detects a change in result.
• Visual check of the card's pending state and the landing in headless Chromium.
• Not tested against a real shard_core: the API shape was taken from shard_core on freeshard main (web/protected/users.py, web/public/users.py, web/protected/settings.py, service/owner_email.py, data_model/user.py).

🤖 Generated with Claude Code