Files
rootnode-academy/docs/WINTER_BREAK_CAMP_OPERATIONS.md
T
ced4568andClaude Sonnet 5 788fb197e0 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]>
2026-08-26 23:59:42 -05:00

4.9 KiB

Winter Break Camp Operations

Phase 8 §29 — 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-8, end to end, entirely from /admin. No payment step exists yet — this document covers everything up to and including the point where a real payment/checkout would plug in.

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.
  • Registration → guardian/adult → agreement → (simulated) confirmation → enrollment → cohort → activation → classroom → real Lab work, proven end to end in infra/scripts/drills/test-phase8-winter-camp-registration.js (12/12 passing).

Still genuinely unknown, deliberately left editable, never invented by this phase:

  • Exact dates, venue, real capacity, and price.
  • 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.

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. 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.
  6. Check launch readiness — the offering detail page's readiness panel should show every check green before publishing. If instructor/curriculum/agreements are configured but dates/ location/capacity aren't final yet, readiness will honestly show that.
  7. 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.
  8. Registrations arrive — via the website integration (once wired — see docs/WEBSITE_ENROLLMENT_INTEGRATION.md's documented future flow) or entered directly by an admin for a phone/in-person sign-up.
  9. Guardian/adult completes the agreement — recorded via the registration's own agreement acceptance action.
  10. Payment step (future, not built) — this is the one step this phase does not implement. Today, an admin manually transitions a registration to confirmed once payment is verified by whatever process exists outside the platform; a future phase's real payment integration would do this automatically on a verified commerce event, the same shape /api/integrations/enrollments already uses for direct program enrollment.
  11. Convert to enrollment — creates the real student account (or matches an existing one), the real academic enrollment, and real cohort membership.
  12. 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.
  13. Classroom day — Prepare Labs for the cohort, start the classroom session, students join and work through real ROOT 01-02 content and Labs.
  14. Offering completion — in_progress → completed once the camp concludes.

Known blockers before this can actually open to the public

  • Real dates, venue, capacity, and price are not yet decided (this document does not invent them).
  • The agreement text requires professional legal review (see docs/ STUDENT_GUARDIAN_DATA_MODEL.md).
  • No payment processing exists — step 10 above is manual until a future phase builds it.
  • The website's own registration UI does not exist yet in this repository (rootnodeacademy.com is built separately) — the integration contract it needs is ready (docs/WEBSITE_ENROLLMENT_INTEGRATION.md), but nobody has built the website-side form yet.