Auth / register
Read · form. Registration should make identity, requirements, and recovery visible before the user commits.
Open original (Vercel, verified 30 Aug 2026; HTTP 200)
Original (cited)
Live URL: vercel.com/signup
The official page is a registration surface with social alternatives, account fields, an agreement notice, and proof that the product is used in production. This block map records the observed structure, not Vercel's logos, assets, or copy.
Vercel wordmark
H1 Your first deploy is just a sign-up away.
social sign-in options (Google · GitHub · OpenAI · Apple)
email + password registration form
Terms of Service + Privacy Policy agreement
customer proof / release-cycle and uptime metrics
The page presents the same registration message in responsive variants. The reusable jobs are identity entry, explicit consent, and a credible path into the product.
Gelium remake
This is how that registration structure lands in Gelium: a native form, explicit labels, a terms checkbox, one primary submit, and a recovery link. The action is a product integration seam, not a claim that Gelium ships an account service here.
Account start
Create a workspace account
Start with the identity you will use to deploy, review, and recover access.
A real registration handler should return the same form with HTTP 422, preserved values where safe, aria-invalid="true", and X-Gelium-Validation: true for an optional HTMX fragment swap. It should never repopulate a password value.
Keep / adapt
| Kept | Gelium primitive | Rejected | Why |
|---|---|---|---|
| Clear registration entry point | native form + labeled ui-text-field inputs |
Copied wordmark or social logos | Identity is the job; another product's brand is not |
| Email and password sequence | native input with autocomplete and constraints |
Unlabeled floating controls | Labels and browser semantics must survive no-JS |
| Explicit agreement | ui-checkbox inside the form |
Consent hidden in small print | The user must understand what the submit includes |
| One commit action | ui-button ui-button-primary |
Multiple competing primary buttons | Registration needs one next move |
| Field-level recovery | ui-validation-summary links + recovery anchor |
Silent client-only errors | 422 feedback must be persistent and navigable |
Ask before copying
- Which identity providers are actually approved, and what account-linking policy protects users from duplicate identities?
- What password, passkey, rate-limit, bot-defense, and email-verification requirements apply before this form is connected?
- Where should failed registration return the user, and which fields are safe to preserve in a 422 response?