Create or copy event

Happy path

Path A — Create from scratch

The most common first-event flow. The organizer has a name, a date, a location, and an idea of capacity. They want to get past the form and into the configurable surface as quickly as possible.

1. From the home dashboard, click Create event.

   The button is a primary CTA in the header chrome (always-visible) and also appears as the first card in the home grid for users with zero events. Clicking opens a modal — not a full-page navigation — so the user keeps their place if they cancel.

2. Choose Start from scratch in the modal's two-card layout (the other card is "Copy from past event").

   The two-card chooser is the modal's only content; no clutter. Each card has an icon, a one-line description, and a clickable hit area covering the full card.

3. Fill in the minimum fields: name, start date/time, end date/time, timezone, location.

   Capacity is optional at this step (defaults to "unlimited" with a warning). Timezone defaults to the user's browser timezone but is editable. Date pickers respect the timezone — the inputs show local time in that zone, not UTC. As the user types the name, a slug preview appears below it; the slug is editable but auto-generated.

4. Click Create.

   The button enters a loading state with the form fields locked (so no double-submit). The request hits POST /v1/admin/events and on success the modal dismisses and the page navigates to /admin/events/<event-id>/setup.

5. Land in the Event Setup hub with sane defaults.

   The hub shows the event's name and date prominently. A checklist on the right ("Add an access type · Configure registration email · Invite guests · Publish your event page") guides the next action. The default access type is "General Admission" with capacity matching the event's overall capacity, so the user can ship a one-tier event with zero further configuration.

Path B — Copy from past event

Heavier than Path A. The user is choosing what to bring forward and what to start fresh.

1. Click Copy from past event in the chooser modal.

   The modal expands to a two-pane layout: left is a searchable list of the user's past events (sorted by most-recent end date), right is a copy-options panel that's empty until a source is picked.

2. Pick a source event.

   The right pane fills with checkboxes for what to copy: Access types (default on), Email designs (default on), Registration questions (default on), Guest list (default off — opt-in because it brings PII), Schedule / agenda (default on if present), Brand & colors (default on). Each row has a count next to it ("12 access types", "4 email designs") so the user knows what they're bringing.

3. Adjust copy options, fill in name + new dates.

   The new event's name defaults to "<Source name> (Copy)" but the field is highlighted so the user is nudged to rename. Start/end dates do NOT default — the user must enter them, because dragging old dates forward silently is a foot-gun.

4. Click Create copy. The request hits POST /v1/admin/events with a source_event_id field and the per-section copy flags.

   On the backend this is a multi-table copy in a single D1 batch transaction (per the existing event-clone code path at workers/events/src/routes/events.ts:2667). On success the page navigates to the new event's setup hub. A toast confirms the count of copied items: "Created Annual Gala 2026 with 12 access types and 4 email designs."

Failure modes

The interesting ones — most of these don't show up in unit tests but absolutely show up in user trust if mishandled. Component-tier failure modes (focus trap escapes, esc-form-submit leaks, backdrop close when disabled, scroll leaks, missing aria-modal, layered z-index leaks, initial focus on hidden elements) are owned by the ui-modal component story and inherited automatically — not re-listed here. EF-008's failure modes below are the EF-008-specific ones: validation, copy-source-deleted, partial-copy, name-collision races.

Edge cases

Page evaluation

Color contrast

Field labels ≥4.5:1, error text ≥4.5:1 against its background. The "required" asterisk is red (≥3:1) but also has aria-label="required" so screen readers don't depend on color. Disabled "Copy from past event" card (when user has no past events) has its disabled state communicated with both opacity and a "no past events to copy from" caption — never opacity alone.

Keyboard navigation

Modal traps focus while open. Tab progresses through the two-card chooser, then form fields top-to-bottom, then submit + cancel. Esc closes. Date pickers are keyboard-accessible (arrow keys to navigate the calendar, Enter to select). Submit can be triggered by Cmd/Ctrl+Enter while any field is focused.

Screen reader

Modal opens with focus on the modal title for context. Aria-live "polite" region announces validation errors as they appear. The two-card chooser is a radiogroup; the cards are radio elements (visually styled as cards but semantically radios) so screen-reader users know one-of-two semantics.

Acceptance signals

• POST /v1/admin/events returns 201 with the new event's id and slug.
• Browser URL changes to /admin/events/<event-id>/setup.
• D1 row exists in events with the submitted name, dates, timezone, capacity, and company_id matching the user's workspace.
• For copy: D1 rows exist in the per-section tables (access_types, email_designs, etc.) for the new event, with foreign keys all pointing at the new event's id (no leaks to the source).
• For copy: source event is unchanged — no rows mutated in the source.
• Setup hub renders with the event's name and date in the H1.
• Setup checklist shows "Add an access type · Configure registration email · Invite guests · Publish your event page" with the first item highlighted as the suggested next action.
• Toast confirms creation (or copy summary including counts).
• document.title is set to the event name + "· Setup".
• No console errors at severity ≥ warn from Voyage origins.

Stable test attributes

This is the contract between the story and the Aperture admin code. Every data-test attribute below MUST be exposed by the code, in the named location, with the named purpose. Adding new attributes is fine; removing a listed attribute is a Ratchet violation requiring STORY-LOOSENING-APPROVED: in the commit message.

Visibility teeth. Each attribute below must be present in the document AND effectively visible per the runtime predicate (no display:none, visibility:hidden, opacity:0, zero bounding rect, off-screen positioning, or aria-hidden="true" on it or any ancestor). Where the row's purpose implies interactivity (a button, an input, a checkbox, a clickable card), it must additionally satisfy effectively interactive: no pointer-events:none, no disabled unless explicitly stipulated, focusable, not occluded at its center point. Hiding without removal is treated identically to removal — both require the loosening token. See PREDICATES.md for the full runtime definition.

When the harness reports "selector [data-test=…] not found," the response is to add the attribute in the code, not to remove the probe. Probes are the Ratchet's teeth.

Agent test plan

preconditions:
- trunkStoryId: admin-shell-access
  state: logged-in-as-organizer
  fixtures:
    user: [email protected]
    workspace: aperture
- shellPage: home-dashboard
  expect:
    - createEventCtaVisible: true
    - viewportSize: 1280x800

1. click [data-test=create-event-cta]
2. expect modal[data-test=create-event-modal] visible, focus inside
3. click [data-test=chooser-from-scratch]
4. expect form[data-test=create-event-form-scratch] visible
5. fill [name=name] = "Pilot Event 2026 ${random}"
6. fill [name=startUtc] = "2026-06-15T14:00"
7. fill [name=endUtc]   = "2026-06-15T17:00"
8. fill [name=timezone] = "America/New_York"
9. fill [name=location] = "Test Venue"
10. click button[data-test=create-event-submit]
11. expect URL match /admin/events/[a-z0-9-]+/setup/
12. capture: { eventId: , slug: , snapshot }
13. assert toast[data-test=event-created-toast] visible
14. fetch /v1/admin/events/${eventId} via auth helper, assert row matches form input
15. assert document.title contains the event name
16. assert h1 = the event name
17. assert setup-checklist[data-test=setup-checklist] visible with first-item-highlighted

preconditions:
- a fixture event "Source Pilot Event ${YYYY}" exists in the workspace with:
    - 3 access types
    - 2 email designs
    - 12 invited guests

1. click [data-test=create-event-cta]
2. click [data-test=chooser-copy-from-past]
3. expect picker[data-test=source-picker] visible
4. type into picker search: "Source Pilot"
5. click first picker result
6. expect copy-options pane visible with 6 checkboxes
7. assert checkbox[name=copy-access-types] checked-by-default with label "3 access types"
8. assert checkbox[name=copy-guest-list] unchecked-by-default with label "12 guests"
9. fill [name=name]    = "Copy of Source Pilot ${random}"
10. fill [name=startUtc] = "2026-06-15T14:00"
11. fill [name=endUtc]   = "2026-06-15T17:00"
12. click button[data-test=create-copy-submit]
13. expect URL match /admin/events/[a-z0-9-]+/setup/
14. capture: { eventId, snapshot }
15. assert toast text contains "3 access types and 2 email designs"
16. fetch /v1/admin/events/${eventId} and assert source-event-id NOT mutated

For each failure mode in §failure-modes, the harness has a probe:
- validation-name-missing: submit empty form, assert inline error "Name is required" next to name field, no toast
- end-before-start: fill end-date before start-date, assert inline error on end-date with text "End time must be after start time"
- year-plus warning: fill range >365d, assert soft warning visible, suggested range link works
- network-failure: stub POST /v1/admin/events to network-fail, assert error message above form, form input preserved, retry includes idempotency-key header
- server-500: stub to 500 with X-Request-Id, assert error message includes request ID
- permission-403: log in as a read-only user (separate fixture), assert Create button disabled with tooltip
- quota-exceeded: stub to 402 with quota error, assert upgrade page link, form input preserved across redirect
- copy-source-deleted: stub source-fetch to 404 mid-flow, assert picker re-opened with struck-through source
- copy-cross-permission: copy from a source with private guests, assert toast says "X of Y guests copied"
- copy-partial-failure: stub to 500 mid-batch, assert no orphan event row
- concurrent-name-collision: simulate two parallel creates, assert both succeed with distinct slugs
- modal-cancel: open modal, type, hit Esc, re-open, assert form is empty

At the chooser modal, create form, copy form, and post-create setup hub:
- axe-core: no violations of impact 'serious' or 'critical'
- color contrast: body ≥4.5:1, error text ≥4.5:1, required-asterisk ≥3:1 (color) AND aria-label="required"
- focus-trap: tab through modal, assert focus stays inside; assert Esc closes
- focus-return: close modal, assert focus returns to the create-event-cta trigger
- screen-reader: modal title is the focus on open; aria-live polite region announces validation errors
- mobile-viewport (375x667): two-card chooser stacks; modal becomes full-screen sheet; submit is sticky-bottom
- document.title: per-page-distinct, includes event name post-create