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 does not exist yet in this repository (rootnodeacademy.com is built separately) — the integration contract it needs is ready (docs/WEBSITE_REGISTRATION_AND_CHECKOUT.md), but nobody has built the website-side form yet.
• See docs/WINTER_BREAK_LAUNCH_CHECKLIST.md for the full go/no-go list.