[E09] Event Participant Detail

Summary

Full-page view + edit screen for a single Event Participant. Surfaces the same content E02’s slide-in side panel renders briefly, plus deeper editing affordances (person attributes, EP-specific fields, audit trail) that don’t fit in a 480px panel.

Carved out as a distinct screen during the E02 2026-04-30 review pass: E02’s side-panel Edit action had no destination, and the editing surface needs more space than the panel can sensibly host. E09 is that destination.

Primary callers:

  • E02 — Open detail link in the side panel; deep-link via /events/{eventId}/participants/{epId}.

  • (Future) shared-route consumers across other event-participant lists.

Actor & Context

Actor: event organiser, race director, tenant admin. Frequency: per-EP — opened when the operator needs more than the side-panel’s read-only summary (correcting attributes, reviewing audit trail, deeper investigation). Precondition: an EP exists; user has read access; pinned event context (EP belongs to the routed event). Entry point: /events/{eventId}/participants/{epId}.

Main Flow

Stub — full flow design in the next session.

  1. Operator arrives at /events/{eventId}/participants/{epId} (deep-link or via E02 side-panel "Open detail" link).

  2. Page renders EP header (name, primary number chip, category, active state) + tabbed body.

  3. Operator views or edits content in the body.

  4. Back to list link returns to E02 with previous filter state preserved (URL query params).

Open Design Questions (for next session)

  1. Tab structure: which sections are tabs (e.g. Person attributes, Race assignments, Orders, Audit trail) vs. inline-scrolled?

  2. Edit affordances: inline-edit per field vs. dedicated edit dialogs for grouped fields?

  3. Person vs. EP attributes: Person identity is shared across EPs in different events; editing Person attributes from inside an event context has cascading implications. Where does the boundary sit?

  4. Permission model: who can edit which fields? Per-org? Per-role?

  5. Audit trail surfacing: is the EP audit log on its own tab, or surfaced contextually (e.g. number-history alongside the number-assignment section)?

  6. Ordering / reordering: can the operator change EP race assignment / category from this screen, or are those flows centralised on E02 (click-to-change)?

  7. Substitute / Make inactive: do these row-level actions also surface here, or stay E02-only?

Acceptance Criteria

  • Use-case page authored.

  • Status design-todo → in-design → handoff-ready after Claude Design pass.

  • :design-url: populated.

  • Tab structure resolved.

  • Edit affordance pattern resolved.

  • Person-vs-EP attribute boundary resolved.

  • Permission model documented.

  • Cross-references E02 + relevant Person screen (TBD).

API Surface

Call Purpose

GET /api/event-participants/{id}

EP detail (existing endpoint).

Person GET / PATCH endpoints (TBD)

Person attribute view / edit — depends on the Person-vs-EP boundary decision.

EP audit-log endpoint (TBD)

Audit trail surfacing — endpoint may need to be created.

Out of Scope

  • Number reassignment — owned by C04; E09 invokes it but doesn’t reimplement.

  • Category change — owned by FU-1 multi-step impact dialog (see E02); E09 invokes it but doesn’t reimplement.

  • Substitute flow — owned by FU-2 (see E02); E09 may surface the entry point but the flow lives elsewhere.

Design Anchors

Notes

Participants are scoped to events (an EP is Person × Event), so the Person-vs-EP boundary on edit affordances is the central design question. A Person edit screen exists conceptually elsewhere (TBD); E09 should defer Person-attribute edits to that screen rather than duplicating them.

Design pending. This is a placeholder stub created during the E02 2026-04-30 review pass to cover the gap left by E02’s side-panel Edit link. Next steps: design discussion in the dedicated screen-design Claude Code session, working through the Open Design Questions list above, then update this .adoc with decisions and derive a v1 Claude Design prompt for hand-off.