Registration form — /e/{slug}/register/{registrationForm}

Who opens it: a parent on a phone, signing up more than one person, once.

What they came to do: put their family in, correctly, without filling anything twice.

True when they leave: everyone who should be registered is, the household is linked by one email, and they know it worked.

Decisions already made

• Server-side validation from the schema, run identically by Livewire and by a plain POST — a browser without JavaScript is validated the same way, not less.
• A repeater row becomes a dependent with a guardian pointer, which is what makes one email cover a family (I6).
• Multi-page forms keep a draft for 72 hours, and the link to resume is shown rather than emailed.
• Dates of birth decide attendee type and whether a guardian is required, so the age rules run on the day the type says (age_as_of), not today.
• A honeypot, not a CAPTCHA: a bot-check that blocks a grandparent is a worse failure than a spam registration.
• The same component renders the builder's preview, so what an organizer previews is what a visitor gets.
• Form logic (week 12) shows and hides fields and pages as answers change, and the server evaluates it again on submit: a field that was hidden is not stored even if the browser sent it, and a field logic requires cannot be skipped. The step counter counts only the pages this person will see.
• Photos, files and signatures (week 12) are kept privately and opened only through links that expire; a consent records when and from where it was given. A registrant editing their answers later sees what is attached but cannot swap it — that is a conversation with the organizers.

Open questions

• The no-JavaScript path advances one page per POST. Acceptable, but untested with real people on slow connections.
• Repeater rows have no "copy from the person above" (same last name, same address), which is most of the typing.
• Nothing warns a parent that they are being registered too when they only meant to sign up a child.