ced4568andClaude Sonnet 5
788fb197e0
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]>
75 lines
4.9 KiB
Markdown
75 lines
4.9 KiB
Markdown
# 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.
|