# Offering Admin Guide

Phase 8 — how to actually run an offering from `/admin` → Offerings, end to end. Pairs with
`docs/OFFERING_AND_REGISTRATION_MODEL.md` (the underlying data model) and `docs/
WINTER_BREAK_CAMP_OPERATIONS.md` (the specific Winter Break Camp walkthrough).

## Creating an offering

**Offerings → Create offering.** Required: offering ID, URL slug, name, program, delivery mode.
Optional at creation: capacity (blank = unlimited), a location. Dates, the registration window,
organization, cohort, curriculum package, and agreement requirements are all set from the
offering's own detail page after creation — a new offering always starts `draft`, invisible to
the public offerings API and closed to registration, so there's no rush to fill in everything
before saving.

## The detail page

Opening an offering shows:

- **Overview** — status, seats, and the only status-transition buttons the offering can
  actually take next (the ones the UI doesn't show are ones the server would reject anyway —
  see `docs/OFFERING_AND_REGISTRATION_MODEL.md`'s transition diagram).
- **Launch readiness** — a live, server-computed checklist (curriculum, instructor, dates,
  location, capacity, registration window, agreements configured). This is the same check the
  server itself could use to gate opening registration — it is never just a frontend hint.
- **Required agreements** — which agreement definitions this offering requires before a
  registration can convert to enrollment, with a form to add another.
- **Registrations / roster** — every registration against this offering, with a form to add one
  directly (useful for phone/in-person sign-ups an instructor is entering by hand).

## Moving an offering through its lifecycle

`draft → published → enrollment_open → full/in_progress → completed`, or `→ cancelled` from
anywhere non-terminal. Only real, server-allowed transitions ever appear as buttons. `full` is
not automatic — an offering set to `enrollment_open` that happens to be at capacity will reject
new registrations with a clear error, but only moves to the visible `full` status when someone
explicitly sets it (or the very next registration attempt trips it) — check the readiness
panel/registration list to know why registration is currently unavailable.

## Working a registration

Open a registration from the offering's roster to see its own detail: registrant/guardian info,
agreement status (required vs. accepted vs. missing), lifecycle transition buttons, and its
communication history (every notification queued for it, with recipient always masked). Once a
registration is `confirmed` and every required agreement is accepted, **Convert to enrollment**
appears — this is the one action that creates the real student account (or matches an existing
one), the real academic enrollment, and real cohort membership if the offering has a cohort.

## Agreements

**Agreements** (reachable from an offering's "Required agreements" section) lets you define a
new agreement (title + a plain-language summary — never legal text, see `docs/
STUDENT_GUARDIAN_DATA_MODEL.md`) and associate it with any offering that needs it. A registration
cannot convert to enrollment while any required agreement is unaccepted.

## Guardians

A minor's registration always carries a linked guardian — create one from the registration form
when registering a minor by hand, or let the website integration create/match one automatically
from a real submission (see `docs/WEBSITE_ENROLLMENT_INTEGRATION.md`). Guardian records are
admin/owner-only — a plain instructor's cohort access to a student's academic progress is
unchanged, but guardian contact detail is not part of that.

## What the admin UI deliberately does not do

No pricing/payment fields, no legal-document authoring, no bulk email composer — every
communication is a templated, transactional notification triggered by a real lifecycle event
(see `docs/REGISTRATION_AND_GUARDIAN_COMMUNICATIONS.md`), never a free-form message an admin
types and blasts out.