Status. Proposed design only. Nothing in this vault is GGA client approval. The GGA client documents are supplied drafts: see GGA-Source-Digest. No application, service or test has been executed; every scenario is Not executed. Delivery fees and dates are open.

Step 08 · Sessions, events and member dashboard

Goal. Fortnightly session occurrences, the major event, registration with capacity and waitlist, and the member dashboard.

Blueprint delivery stage: Stage 3 (Delivery-Options-Comparison).

Former 1.3 name: Daily tracking views. The file name and the step number are kept as stable identifiers (as with the historical DG prefix), so existing links and the step-08 label stay valid.

Not started. This is a specification; no code has been written. The primary-step mapping is an index, not proof that each full scenario can be completed in its step: see Dependency-and-Regression-Table.

Prerequisites

Steps 01, 02, 03, 04, 05, 06, 07 as needed by the table in Dependency-and-Regression-Table; the strict prerequisite is the previous step’s exit evidence. Policy-independent scaffolding may start after the overall start conditions; decision-dependent behaviour and its final oracle stay blocked until the named authority decides. Proposed defaults are recommendations, never prerequisites. Blocked decisions: GL08-staged, GL01-staged, Q22, GQ04-staged.

Changes (illustrative, not a final schema)

Sources: Blueprint pages cited per item (GGA-Requirement-Register).

Build items:

  • Occurrences with topic, host, guest, date, timezone, link, capacity and status; one major event with venue, programme, capacity, budget owner and delivery lead (p. 9)
  • Registration: eligibility check, unique occurrence and user, atomic capacity, waitlist promotion on cancellation (pp. 9, 15)
  • Confirmation, calendar file, 24-hour and 1-hour reminders from the current occurrence version; changes cancel obsolete jobs (pp. 9, 16)
  • Attendance stored apart from registration; recordings only with permission (p. 9)
  • Member dashboard: profile status, relevant opportunities, upcoming sessions, pending consent, introduction progress, contribution as a separate status (p. 10)

Expected outputs and invariants

Capacity is never exceeded under concurrency; an existing registration stays valid if the profile later becomes overdue while a new one needs refreshed data.

Tests-first subset

Primary scenarios of this step (write these tests first): T30, GS15-staged, GS16-staged, GS29-staged.

Assertions to write first: new GGA scenarios GS15-staged, GS16-staged, GS29-staged. Legacy scenarios whose primary step is this one: T30. Each follows its replacing GS scenario; the 1.3 text is history (Scenario-Dispositions).

Method: make one meaningful test fail for the expected reason, implement the minimum behaviour, refactor without changing the observable contract. A scenario whose decision is still pending stays Blocked by that decision; no oracle is invented.

Deferred integration checks

Scenarios whose primary step is this one but whose full variants need later components:

  • T30: needs step 09 (through GS05, GS29).
  • GS29-staged: needs step 09. Introduction progress (06) and contribution status (09).

Follow-up verification brought here

Scenarios (of any step) that can only be completed or rechecked once this step exists:

  • GS05-staged: Enforcement on discovery (05), pitch (06) and registration (08).
  • GS31-staged: Every screen must be exercised; final audit in 10.

Decisions GGA must settle (dependent behaviour stays blocked until the named authority decides)

GL08-staged, GL01-staged, Q22, GQ04-staged

Exit evidence

Concurrent registration and cancellation behave on a named build; GS15 and GS16 can be verified here; GS29 is verified in part until contribution status exists (09).

Evidence is recorded only for a named build and fixture. A software scenario is not recorded as Passed until all its relevant variants have been exercised on a named integrated build (step 11).

Navigation: Step-07-Outbox-Worker-Email ← this step → Step-09-DG-Membership-Tool-and-Metadata · Implementation-Order-Overview