[richshaw]

Fixes #378. Part of the work for #347.

Stacked on #385. Must merge after #383 too: the Settings help text and the help page point to removing someone on the Responses tab, which #383 adds. The full order is #380 → #383 → #379 → #381 → #385 → #389.

The problem

• A signup's requireEmail setting could only be changed through the AI connector or the API. Organizers had no way to make the email optional themselves.
• The "Sorry, this link isn't working" page told everyone to try the link in their confirmation email. Someone who signed up without an email has none.
• Nothing told an organizer what to do when someone without an email loses their link.

The fix

• The Settings tab has a new "Sign-up form" section: "Ask for an email address", Required (the default) or Optional, then Save. After a save, "Saved" shows next to the button.
• A line under the choices says what the one picked means:
  • Required: "We email everyone their link to change or cancel."
  • Optional: "People can leave it blank. They get no emails, not even reminders, so they need to save their link. If they lose it, they can sign up again and you can remove the old one on the Responses tab."
  • CSS shows the line for the radio picked (group-has-[…:checked]), so it changes as soon as the radio does, before a save, with no script. Each radio is described by its own line for screen readers.
• It is a plain server form, so the tab adds no script. It sends only requireEmail, which updateSignup merges over the stored settings.
• A refused save shows on the tab in plain words, not the service's developer message.
  • A viewer reads "You don’t have edit access." The Build tab used to say "You no longer have edit access.", though a viewer never had it. Both tabs now share the new words.
• Delete on the same tab now puts its refusal in the same plain words, for example "No longer available.", instead of "signup not found".
• The Build tab's "Saved" look and its error copy move into one shared, server-safe module (src/components/ui/save-notice.tsx). Settings reuses them instead of adding a third style.
• The form spaces its parts with a gap, so it doesn't shift after a save.
• The "link isn't working" page now tells everyone to contact the organizer. It mentions the confirmation email only for those who got one.
• Help, "Create and publish your first signup": a new section, "Let people sign up without an email", with a screenshot.
  • Its first step warns first that a phone's Settings link at the very top is for the account, then points at the signup's Settings tab.
  • It says the email box will read "Email (optional)" before the reader chooses Save.
  • When someone loses their link: ask them to sign up again. If their slot is full, remove them on the Responses tab first. Otherwise remove the old one, which is higher up the list (it's oldest first).
  • It says "email address" for what people type, and says everyone sees their link on screen after signing up. The passages Let participants sign up without an email where the organizer allows it #385 added get the same words.
• docs/writing-help.md: "sign-up" joins the words not to use for a spot. Beside "signup" it reads as the same word spelt two ways, and the participant pages now say "spot" (Show that a sign-up was cancelled when its edit link is opened again #380).

Tests

• actions.db.test.ts runs the actions against Postgres:
  • an owner's save is stored and comes back saying Saved;
  • a viewer is refused with "You don’t have edit access.", and nothing is written or revalidated;
  • a missing signup reads "No longer available.", for Save and for Delete.
• SaveStatus.test.tsx: the Build tab tells a refused viewer "You don’t have edit access."
• organizer.spec.ts:
  • only the line for the choice picked shows, it swaps when the radio changes before a save, and each radio is described by its own line;
  • Optional, then a participant signs up with no email, then Required again.
• The help walkthrough clicks through the new steps, sees the sign-up on the Responses tab, and takes the screenshot.
• Both specs set up their signup through a shared createPublishedSignup helper.
• gone-message.test.ts checks the new wording.
• All of these pass:
  • pnpm lint && pnpm typecheck && pnpm knip && pnpm test (1088)
  • pnpm test:db (401)
  • pnpm build && pnpm budgets (the Settings page is 123.6 kB of 125; /s/[slug] is 130.2 kB of 131)
  • e2e: organizer, public-commit, edit-token, a11y, commit-sheet, signup-not-found and every help walkthrough

Left out on purpose

• "Saved" stays on screen until the next navigation, like ?published=1 and ?disconnected=1 elsewhere.
• Save writes the choice on screen even if another tab changed the setting since. An explicit Save of what you see should win, and the form only sends the one setting it owns.
• Publish, Close and Delete still send a viewer to the error page, because the refusal is thrown rather than returned. That predates this PR and is A viewer who chooses Publish, Close or Delete gets the error page #390.
• The help page doesn't name or link the Remove button: it comes from Let organizers remove one person from a slot #383, which isn't in this branch.
• Renaming the phone header's "Settings" link to "Account", which would let the help drop its warning. It and the account page's heading are on main, and another help page and three tests use the name, so it's a separate change.

🤖 Generated with Claude Code

https://claude.ai/code/session_0159b8Nfy3w7F8BVwvn37Fc3

---

Generated by Claude Code

[richshaw]

Review summary

I reviewed only this PR's own commit (7c86ffa), diffed against its merge-base with #385's branch (e9bf7b9). The code-review pass posted 14 inline comments. I checked each one against the code: 10 hold up and are ranked below, and I withdrew 4 in place (reasons at the end). I found no blocking problems. The policy guard still judges the save (updateSignup calls requireWorkspaceWrite), the action sends only requireEmail, and the screenshot is exactly twice its stated size. src/help/articles.test.tsx and gone-message.test.ts pass at this head (26 tests).

Findings, ranked

Medium

1. settings/page.tsx:83: The on-screen help says "If they lose it, you can remove them on the Responses tab". On this branch the Responses tab has no remove action. That comes from #383, which is still open and is stacked on a different branch (claude/issue-375-cancelled-edit-link). If this PR merges first, the UI promises a way out that doesn't exist. The PR body already keeps Remove out of the help page for this reason, but not out of the Settings text.

Low
2. create-and-publish-a-signup.tsx:191 (posted on line 178, because 191 isn't in the diff): The Reminders paragraph still says "If a slot has a date, people who take it get a reminder email". The new section says the opposite for anyone who left the email blank.
3. gone-message.ts:36: In "If you got a confirmation email, try its link again, or contact the organizer…", the "contact the organizer" part can be read as falling under the "if". Someone with no email then has no clear next step.
4. settings/page.tsx:93: "Saved" comes from ?saved=1 and is never cleared. It stays next to a radio that was changed but not saved, and comes back on reload. ?published=1 and ?disconnected=1 work the same way, so this is minor.
5. tests/e2e/organizer.spec.ts:101: The PR body and CHANGELOG say a viewer is refused and sees the tab's error, but no test runs the new ServiceException catch.

Nits
6. CHANGELOG.md:21: The CHANGELOG still says "Settings keeps only the danger zone".
7. actions.ts:45: The tab's error shows raw service messages, such as "your role cannot modify this workspace". deleteSignupAction and Connected apps already do the same, so this is polish, not a regression. The comment's "legacy groupByFieldRefs with two entries" case is speculative: the schema has always capped that list at one.
8. actions.ts:47: Only this action catches the guard's throw. publishAction and deleteSignupAction still send a viewer to the error page. A shared helper would cover all of them. This gap was there before the PR.
9. settings/page.tsx:94: This is another one-off "Saved" notice (CLAUDE.md asks to reuse banners and notices). SaveStatus is a client component, so reusing it as it is would add script to this page. Extracting a small server-safe notice is the option that keeps the page script-free.
10. tests/e2e/organizer.spec.ts:107: The post() helper and the create, add-slot and publish setup are duplicated in the help walkthrough. Inline setup is already the usual pattern across the e2e specs.

Withdrawn after verification (edited in place)

• settings/page.tsx:53, refused save keeps the refused radio: This doesn't happen. In Next 15.5, a redirect() from an action rejects with a redirect error, and the segment's RedirectBoundary remounts the page subtree, so the radios come back with the stored value. Without JavaScript it's a full page load, with the same result.
• settings/page.tsx:53, key remount drops focus: Wrong cause. The RedirectBoundary remounts the page on every redirect, not the key, so the suggested fix wouldn't change anything.
• actions.ts:40, stale tab overwrites: Not a bug. The form sends only the one setting it owns, which is what #314 protects. An explicit Save of the value on screen should win.
• actions.ts:51, if (refused) truthiness: No reachable error has an empty message. fromZodError falls back to 'invalid input'.

---

Generated by Claude Code