rootnode-academy/docs/OFFERING_ADMIN_GUIDE.md

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.