docs(phase8): document enrollment operations

New: PHASE8_ENROLLMENT_OPERATIONS.md (phase summary), WINTER_BREAK_CAMP_OPERATIONS.md
(the real operational walkthrough), REGISTRATION_AND_GUARDIAN_COMMUNICATIONS.md,
OFFERING_ADMIN_GUIDE.md.

Updated: ROOTNODE_ACADEMY_BUSINESS_AND_PRODUCT_ARCHITECTURE.md (BUILT NOW/PHASE 8 BUILT
table), OFFERING_AND_REGISTRATION_MODEL.md (both ordering bugs, launch readiness,
registration enforcement), STUDENT_GUARDIAN_DATA_MODEL.md (guardian communications now
wired), WEBSITE_ENROLLMENT_INTEGRATION.md (the real, live registration contract with
worked examples, replacing the old speculative future-flow section), platform/README.md
(test list).

Co-Authored-By: Claude Sonnet 5 <[email protected]>

docs/OFFERING_ADMIN_GUIDE.md

@@ -0,0 +1,69 @@
+# 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.