rootnode-academy/docs/WINTER_BREAK_CAMP_OPERATIONS.md

# Winter Break Camp Operations

Phase 8 §29 (payment step updated in Phase 9) — how to actually run the Winter Break Linux &
Systems Foundations Camp (`docs/WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md` Option A) using the
platform built in Phases 7-9, end to end, entirely from `/admin`. As of Phase 9, real
checkout/payment (Stripe test mode today, live mode once real credentials exist) is part of this
flow — see `docs/PHASE9_COMMERCE_AND_LAUNCH.md` and `docs/WINTER_BREAK_LAUNCH_CHECKLIST.md`.

## What already exists vs. what Chase still fills in

**Already representable, real, tested:**
- The curriculum package (ROOT 01-02, referencing the real, unmodified courses).
- The offering itself, in DRAFT, with delivery mode `camp`, and a real price.
- Registration → guardian/adult → agreement → real checkout → verified webhook → confirmation →
  enrollment → cohort → activation → classroom → real Lab work, proven end to end in
  `infra/scripts/drills/test-phase9-winter-camp-commerce.js` (13/13 passing, test payment
  provider, no live money) — plus failed-payment retry, abandoned-checkout seat release, and a
  last-seat checkout race, none of which existed in Phase 8's own rehearsal.

**Still genuinely unknown, deliberately left editable, never invented by this phase:**
- Exact dates, venue, real capacity, and price (the price FIELD is real and editable; the actual
  dollar amount to charge is still Chase's call).
- The actual agreement text (a plain-language placeholder only — see `docs/
  STUDENT_GUARDIAN_DATA_MODEL.md`'s legal-review list).
- Whether registration opens before or after a specific marketing push.
- Real Stripe credentials — until they exist, the platform runs on the deterministic test
  provider, functionally complete but not yet validated against Stripe's own live systems. See
  `docs/STRIPE_INTEGRATION_RUNBOOK.md`.

## The operational sequence

1. **Create the location** — `/admin` → Offerings → (via the offering create form's location
   dropdown) or directly if a location admin surface is added later; today, an admin/owner uses
   `POST /api/admin/locations` (documented in `docs/OFFERING_ADMIN_GUIDE.md`) once the real venue
   is known.
2. **Create the curriculum package** — `winter-linux-systems-v1`, referencing
   `root-01-computing-linux-foundations` and `root-02-linux-administration-networking` in
   sequence. This step is a one-time setup — the same package can back every future Winter Break
   Camp offering.
3. **Create the cohort** and **the offering** — delivery mode `camp`, referencing the program,
   the curriculum package, and (once known) the location and capacity.
4. **Assign the lead instructor** — both at the offering level (`instructor_offerings`, Phase 7)
   and the cohort level (`cohort_instructors`, unchanged since Phase 2A) — the offering detail
   page's own instructor step, or the two admin routes directly.
5. **Set the price** — `PATCH /api/admin/offerings/:id` with `price_amount`/`price_currency`
   (or leave `price_amount` unset for a free offering). Confirm `PAYMENT_PROVIDER` is configured
   (`test` for rehearsal, `stripe` with real credentials for a live launch — see `docs/
   STRIPE_INTEGRATION_RUNBOOK.md`).
6. **Configure the required agreement(s)** — create the agreement definition (title + plain-
   language summary) and link it to the offering. **The actual legal text still needs
   professional review before this camp is opened to real families** — see below.
7. **Check launch readiness** — the offering detail page's readiness panel should show every
   check green before publishing, including the new `price` and `payment_provider` checks. If
   instructor/curriculum/agreements/price are configured but dates/location/capacity aren't
   final yet, readiness will honestly show that.
8. **Publish, then open registration** — `draft → published → enrollment_open`. Only once
   `enrollment_open` does the offering appear in the public offerings API and accept real
   registrations.
9. **Registrations arrive** — via the website integration (contract ready, see
   `docs/WEBSITE_REGISTRATION_AND_CHECKOUT.md`) or entered directly by an admin for a phone/
   in-person sign-up.
10. **Guardian/adult completes the agreement, then checkout** — the agreement acceptance and
    checkout-creation endpoints are both live (Phase 9); checkout is blocked until the agreement
    is accepted.
11. **Payment confirmation** — a verified, idempotent webhook (never a browser redirect) is what
    actually confirms payment and walks the registration to `confirmed`. A failed payment leaves
    the registration retriable without releasing the seat; an abandoned checkout or an expired,
    unpaid reservation releases it.
12. **Convert to enrollment** — happens automatically on payment confirmation for a priced
    offering (or a manual admin transition for a free one) — creates the real student account
    (or matches an existing one), the real academic enrollment, and real cohort membership.
13. **Account activation** — the student's (or, for a minor, the guardian's) real one-time
    activation token, delivered the same way every other RootNode activation email already is.
14. **Classroom day** — Prepare Labs for the cohort, start the classroom session, students join
    and work through real ROOT 01-02 content and Labs.
15. **Offering completion** — `in_progress → completed` once the camp concludes.

## Known blockers before this can actually open to the public

- Real dates, venue, capacity, and the actual dollar price are not yet decided (this document
  does not invent them — the platform fields to hold them are real and ready).
- The agreement text requires professional legal review (see `docs/
  STUDENT_GUARDIAN_DATA_MODEL.md`).
- Real Stripe credentials do not exist yet — the commerce pipeline is built and tested against
  the deterministic test provider only; see `docs/STRIPE_INTEGRATION_RUNBOOK.md` for going live.
- The website's own registration/checkout UI is now built (rootnodeacademy.com, a separate
  repository not owned by this one) against `docs/WEBSITE_REGISTRATION_AND_CHECKOUT.md`'s
  contract — but it has nothing to talk to yet, since `ROOTNODE_API_URL`/
  `ROOTNODE_INTEGRATION_KEY` point at no real Platform API (none is deployed — see `docs/
  PHASE10_PRODUCTION_DEPLOYMENT.md`). Its own real pricing (`docs/
  ROOTNODE_PRICING_AND_OFFERS_V1.md`) has already been published on the live site.
- See `docs/WINTER_BREAK_LAUNCH_CHECKLIST.md` for the full go/no-go list.