[E01] Event Overview — Stage-Aware Single-Event Dashboard

Summary

The landing page when a user drills into a single specific event. One page that morphs with the event’s stage — Draft → Registration open → Pre-race → Post-event — surfacing the KPIs, checklists, and role lanes that matter at each stage. Reuses the C01 shell + the Event Title Panel pattern that sits above every inner event screen.

This is not the Events workspace landing (which is E05 and shows multiple events). E01 is what you see after clicking a specific event row from E05 or from the sidebar’s "Events" entry.

Actor & Context

Actor:

  • Event organiser — primary owner; checks readiness, monitors registrations, signs off go/no-go, closes out post-event.

  • Finance — focuses on revenue/orders during Reg open, recon during Post-event.

  • Timing team — focuses on category/sync state during Pre-race.

  • Project manager — tracks Plane-side todos during Draft; checklist progress during Pre-race.

Frequency: high during a registration window or in the days surrounding an event; low otherwise.

Precondition: user is authenticated, has the current event’s tenant selected, has access to this specific event.

Entry point:

  • From the sidebar’s "Events" nav (current tenant’s events list).

  • From the E05 Active Events list or Recent Events list (click a row).

  • From a notification linking to a specific event.

  • Direct URL: …/<tenant>/events/<event-slug> lands here.

The Stage Model

E01’s hero variation is driven by event.stage, computed from event lifecycle dates + status. Four stages, four different layouts in the same shell:

Stage What dominates the layout

draft

Readiness checklist — what’s left to publish, who needs to sign what off, external coordination (permits, vendors, volunteers). Project plan link (Plane) for PM follow-ups.

open (registration open)

Live KPIs + timeline — registrations, orders, revenue, average order, days to close. Daily timeline chart. Category-fill bars. Compact role-lane strip (organiser / finance / project).

prerace

Go / no-go checklist with blocking items flagged red. Timing team sync state. Start-pack print state. Days-to-event countdown.

post

Summary banner + three role lanes: Finance recon, Results publishing, Compliance & Reports. Each lane has its own KPIs + checklist.

The stage stepper (Draft → Reg → Pre → Post) sits below the title panel and above the body. Stages auto-advance based on lifecycle dates; user can also pin/advance manually for dry runs (open question — see below).

Main Flow

  1. Bootstrap. SPA receives the event slug from the URL, calls GET /api/events/{slug-or-id}. Response carries the event’s identity, current stage, key stats.

  2. Render shell + title panel + stepper. Sidebar from C01; Event Title Panel from C01’s reserved pattern (icon + name + status tag + key stats + Event-overview button). Stage stepper renders below the title.

  3. Render the stage-specific body. Switch on event.stage:

    1. draft → Readiness layout (checklist hero + Plane link + role focus)

    2. open → KPI band + timeline + category fill + role lanes

    3. prerace → Go/no-go hero + timing sync + start-pack state

    4. post → Summary banner + finance recon + results publishing + compliance lanes

  4. Update on tick. Live counts (registrations, revenue) refresh on a poll or push (TBD per WS5/E05 sweep design). Other content is request-time fresh.

  5. The user proceeds by clicking through into a sub-screen (Categories, Races, Participants, Results), advancing the stepper, or opening role-specific deep-links (Plane, finance recon, etc.).

Alternative Flows

  • AF-1 — Manually advance/regress stage. During testing or during a stage that doesn’t cleanly auto-advance (e.g. an event where registration closed but stage hasn’t ticked), the organiser can pin the stage manually. Open question (see below) — current design hints at this but doesn’t specify the affordance.

  • AF-2 — User has insufficient role. A user who is STAFF (no EVENT_MANAGER / RESULTS_OFFICER role) sees E01 in read-only mode: KPIs and checklists render, but action buttons ("Open analytics", "Manage", "Open in Plane") are disabled or hidden. Sub-screen links work where the user has access.

  • AF-3 — Cross-stage actions. Some actions cross stages — e.g. a finance correction during post-event, or a permit re-issue triggered during pre-race. These deep-link into the relevant feature page (Finance / Compliance) and return to E01 unchanged.

  • AF-4 — Empty / loading states. First load of a freshly created event shows the Draft layout with most checklist items unticked. KPIs in Reg-open / Pre-race show — until the first tick of data is in.

  • AF-5 — Print-friendly post-event summary. Out of v1 scope; flagged as a future ask. The Post-event summary banner has natural print value (board reports, sponsor packs).

Acceptance Criteria

  • E01 renders inside the C01 shell with the Event Title Panel above the stage stepper above the body.

  • Stage is computed from event.lifecycleDates + event.status and matches the design’s mapping (Draft / Reg open / Pre-race / Post-event).

  • Each stage’s body matches the design’s grid (Draft 1.5fr+1fr two-row; Reg open 5-KPI top band + 1.5fr+1fr two-row + 3-col role-lane strip; Pre-race 1.5fr+1fr two-row hero; Post-event banner + 3-lane row).

  • Workspace accent (Events indigo #4f46e5) is used in tags, KPI delta indicators, and the active stepper step. No other dominant colour.

  • All "Manage" / "Open" / "View" links navigate to the corresponding sub-screen and preserve the breadcrumb.

  • Title Panel’s "Event overview" button navigates back to E01 from any sub-screen.

  • Live KPIs (Reg-open) refresh without a full page reload.

  • Read-only mode for STAFF role hides or disables actions but preserves the layout.

API Surface

A non-trivial number of admin-service endpoints feed each stage’s body. Expect WS3 (OpenAPI client generation) to surface these naturally — the list below is illustrative.

Call Purpose

GET /api/events/{id}

Event identity, status, dates, stage classifier inputs.

GET /api/events/{id}/readiness (NEW or composite)

Draft-stage checklist data: event basics, publishing items, external coordination items, blocked-by reasons. Likely composed gateway-side from existing per-aspect endpoints.

GET /api/events/{id}/registrations/summary

Reg-open KPIs: counts, revenue, daily timeline, category fill.

GET /api/events/{id}/preflight (NEW or composite)

Pre-race go/no-go checklist: assignment counts, payment outstanding, timing sync state, start-pack readiness.

GET /api/events/{id}/postevent (NEW or composite)

Post-event finance recon, results publish state, compliance reports list.

GET /api/events/{id}/categories

Categories with fill counts (Reg-open category bars).

GET /api/events/{id}/timing-sync

Timing system sync state per target (RaceTec / MyLaps / public tracker).

Plane integration

Existing project-management integration (out of admin-service surface). Read-only KPIs (open tasks / overdue / milestones).

POST /api/events/{id}/stage (optional)

Manual stage advance. Captured under AF-1.

The composite-or-new question for readiness, preflight, postevent mirrors the C01 tenant-glance discussion: gateway composite from existing per-aspect endpoints is preferred when those endpoints exist; a new admin-service composite endpoint when they don’t and it would otherwise be many calls. Decide per-stage during E01 implementation.

Out of Scope

  • The Events workspace landing showing multiple events (E05).

  • Sub-screens reached from E01 — Categories, Races, Participants, Results — each owned by E02 / E03 / E04 / etc.

  • Notifications panel (C01 § Notifications).

  • The Title Panel reusable component itself (C01 reserves the pattern; E01 just consumes it).

Design Anchors

Open Questions

  1. Stage computation. Is event.stage derived dynamically from dates + status, or is it a stored column on the event record? Implications for caching, read consistency, and AF-1 manual advance.

  2. AF-1 manual stage advance affordance. The design hints at "advance manually for dry runs" but doesn’t render the control. Where does the toggle live — Title Panel? Stepper itself? An admin-only menu? Defer to next E01 design pass.

  3. Live KPI refresh cadence. Reg-open KPIs are "live". Polling interval (5s / 30s / 60s) vs push (SSE / WebSocket via Async Signal & Sweep, Feature #403)? Lean polling at 60s for v1; revisit if the Reg-open dashboard becomes a heavily-watched page.

  4. Cross-event deep-links. "Open in Plane" — does this open a new tab or in-app iframe? Plane is external; new tab is the expected pattern.

  5. Stage tagging on past events. Once an event passes through Post-event and the recon/results lanes are all green, does it stay on the Post-event stage forever, or move to a hidden "Closed" stage that only surfaces on E05 Recent Events for special follow-ups? Affects E05’s Recent panel filter.

  6. Empty / failed stage data. If a sub-call fails (timing-sync down), does the relevant card show an error tile, hide, or fall back to "No data"?

  7. Print / export for Post-event summary. v1 scope?

Forward-Engineering Backlog

  1. Event.stage field — confirmed as derived (not stored) preferable; enum: DRAFT, REGISTRATION_OPEN, PRE_RACE, POST_EVENT, optionally CLOSED. Mapper from existing fields.

  2. Composite endpoints — readiness, preflight, postevent — at minimum, agree the shape DTOs and the gateway-vs-admin-service split per stage. Will need per-stage tickets under Epic #533 once E01 implementation starts.

  3. Plane integration — out of admin-service; uses existing Plane API key configuration. Token belongs to admin-service config (gateway proxies if needed). Existing pattern for external integrations in EMS.

  4. Live KPIs streaming — defer; polling is fine for v1.

  5. Role-lane visibility — driven by OrgPermission.role (Feature #534). E.g. only FINANCE role sees the "Finance" role-lane card on Reg-open. Currently the design renders all lanes; gating per role is implementation-time.

Reference Implementation

File Role

admin-portal-app/src/app/features/events/event-overview/event-overview.component.ts

Orchestrator — reads event, picks the stage component

…/event-overview/draft-overview.component.ts

Draft-stage layout

…/event-overview/reg-open-overview.component.ts

Reg-open layout

…/event-overview/pre-race-overview.component.ts

Pre-race layout

…/event-overview/post-event-overview.component.ts

Post-event layout

…/event-overview/stage-stepper.component.ts

The 4-step indicator above the body

@ems/shared-ui Card / KPI / Checklist / BarChart / RoleLane primitives

Reusable components extracted to the shared library

Design Conventions Reverse-Engineered (for Implementation)

Useful patterns to carry into the Angular implementation:

  • Card primitive — title + tag + action + body. Used everywhere on E01. Should live in @ems/shared-ui.

  • KPI primitive — value (large) + unit (smaller) + label (caps small) + delta (smaller, tone-coloured up/down/neutral). 5-up KPI band on Reg-open.

  • Checklist primitive — items[].label / done / sub / blocked / tag. Variable-height row supporting nested tags (Approved / Pending / Blocking / In review).

  • BarChart primitive — small bar chart per day with a highlighted bar; used for the daily timeline. Stacked-pattern below shows time-of-day if needed.

  • CategoryBars primitive — labelled progress bar per category with caps; used for category fill.

  • RoleLane primitive — title bar + KPI grid + checklist for the post-event lanes. Configurable accent colour per role.

These all promote to @ems/shared-ui (WS4) — they’re shared across E01, E05, and future M-screens.

Change History

Date Change

2026-04-27

Initial reverse-engineered draft from E01 Claude Design canvas. The design is rich and substantively complete for the four stages — promoted to handoff-ready. Open questions captured for next design pass and implementation kickoff.