Event Setup hub

Happy path

The organizer lands on /admin/events/:eventId/setup — either via the post-create redirect from EF-008, or by clicking an event in the home dashboard's recent-events card, or from a deep link in a Slack message. Within ~5 seconds they understand what state the event is in, what's left to configure, and what the most useful single action is.

1. Land on the setup hub.

   Page H1 is the event's name. Subtitle shows the date range in the event's timezone (with timezone label). Breadcrumb: Workspace › Events › <Event name> › Setup. Document title: "<Event name> · Setup".

2. Read the at-a-glance status row.

   A single horizontal row immediately below the H1 shows: capacity / registered / waitlisted / status (draft / published / archived). Each is a concrete number with a color-coded label. The row never wraps to multiple lines; on narrow viewports it scrolls horizontally with the leftmost (capacity) sticky.

3. Scan the configuration sections.

   The hub is organized into named sections in a deterministic order: Basics (name, dates, location, description), Access types (ticket types, capacity per tier, transferability), Email designs (invitation, confirmation, declination, reminder, post-event), Audience (invited list, group invite, import), Branding (logo, colors, fonts), Public page (Canvas-driven event site), Schedule (agenda items if a multi-session event), Reports (link out to the report center, scoped to this event). Each section is a card with a status pill and a CTA. Sections that are not applicable to this event type are hidden, not shown disabled.

4. See the next-action highlight.

   A right-rail or top-of-content checklist surfaces the single most useful next action — algorithmically determined: if no access type, "Add an access type"; if access type but no email design associated, "Configure invitation email"; if those are done, "Invite guests"; if those are done, "Publish your event page". The checklist is never more than 4 items visible at a time; deeper items collapse into a "Show all checklist items" affordance.

5. Click into a section.

   Each section's CTA navigates to a dedicated configuration page (/admin/events/:eventId/access-types, /admin/events/:eventId/designs, etc.). The setup hub is the home base; sub-pages have a back link to the hub. Sub-page navigation does NOT lose the hub's scroll position (browser back returns to the hub at the same scroll offset).

6. Publish.

   A persistent Publish event CTA in the page header is disabled when prerequisites are missing (no access type, no public-page slug, etc.) with a tooltip naming what's needed. When all prerequisites are met, the button is primary-styled and clicking it opens a confirm modal. Publish transitions events.status from draft to published; the URL of the public page becomes live; the hub's status pill updates.

Failure modes

Edge cases

Page evaluation

Acceptance signals

• URL matches ^/admin/events/[a-z0-9-]+/setup/?$.
• H1 contains the event's name (matched against the API-fetched value).
• Status row is visible above the fold at 1280×800 with capacity / registered / waitlisted / status all rendered.
• The next-action checklist has at least one highlighted item OR a "concluded" state if the event is past.
• document.title matches ^.+ · Setup$.
• Each visible section card has a status pill AND a CTA AND either a populated state OR an empty state.
• Publish CTA is in the page header; visibility teeth — never hidden via display:none / visibility:hidden / opacity:0 / aria-hidden when the user has permission.
• No console errors at severity ≥ warn from Voyage origins.
• TTI under 2s on broadband.
• No layout shift > 0.1 in the first 5s.

Stable test attributes

This trunk's contract — every data-test attribute the Aperture admin code MUST expose on the event setup hub. Branches that root in event-setup inherit these without re-declaring.

Visibility teeth. Each attribute must be present AND effectively visible when the relevant state is active. Hiding without removal is a Ratchet violation.

Agent test plan

preconditions:
- trunkStoryId: admin-shell-access  (auth, shell rendered)

After admin-shell setup:
1. navigate to /admin/events/${fixture.eventId}/setup
2. wait for [data-test=setup-hub]
3. assert acceptance signals: URL match, H1 has event name, status row visible above fold, checklist has highlighted item, document.title ends with " · Setup", no console errors, TTI < 2s, CLS < 0.1

- archived-event: navigate to a known-archived event, assert archived-event-banner visible AND unarchive affordance present
- stale-config: open hub, advance clock 6 minutes, focus tab, assert auto-refetch fired
- concurrent-edit: stub a 409 RESOURCE_GONE on access-type save, assert concurrent-edit-banner with form values preserved
- publish-prereq-missing: load a fresh event with no access type, click publish-cta, assert publish-prereq-popover visible with unmet items listed AND deep-links present
- publish-race: stub publish endpoint to return 409 ALREADY_PUBLISHED, assert hub re-fetches and reflects published state without an error toast
- unpublish-destructive-confirm: click unpublish on a published event, assert ui-modal opens with closeOnBackdrop=false AND requires typing the event name AND submit is not auto-focused
- section-data-500: stub /v1/admin/events/:id/email-designs to 500, assert setup-section-error visible inside setup-section-designs AND other sections still interactive