rootnode-academy/docs/PHASE6A_ROOT_COURSE_FOUNDATION.md

Phase 6A — ROOT_ Course Architecture + Content Delivery Foundation

Status: PHASE 6A COMPLETE. COURSE/MODULE/ACTIVITY CONTENT MODEL LIVE. GOLD-STANDARD MODULE READY, VALIDATED AGAINST A REAL LAB.

Phases 1-5 built the RootNode Academy platform: identity, cohorts, curriculum, the assessment engine, remote classrooms, self-paced enrollment, and enrollment communications. All of it sat on top of scenarios/rootnode-path.json — a flat list of scenario ids per stage, with no notion of a lesson, a demonstration, or "learn this before you're asked to solve it." Phase 6A builds that layer, for the root_ track only, without touching any of the systems underneath it.

1. The canonical youth ladder (context, not built here)

RootNode Academy's product spans three tracks by age/stage:

• init_ (~5-10) — robotics / computational thinking / block coding. Not built.
• compile_ (~11-14) — electronics / microcontrollers / ESP32 / programming. Not built.
• root_ (~15-18+, college, adult) — Linux → systems → containers → Kubernetes → DevOps/ platform engineering. This phase.

programs.family (Phase 5B) already models this three-way split; only root has real content. Phase 6A does not invent init_/compile_ curriculum — see §15 of the authorization and docs/ROOT_CURRICULUM_INVENTORY.md §7 for the evidence that no such content exists yet.

2. Core product principle

KubeKosh/the RootNode Lab is the LABORATORY, not the whole course. A RootNode course can contain lessons, demonstrations, examples, knowledge checks, guided exercises, labs (existing scenarios), assessments, reflections, and capstone work — a student learns a concept BEFORE being asked to solve the corresponding scenario. See docs/COURSE_AUTHORING_STANDARD.md.

3. Google Workspace status (recorded per this phase's instruction, not new work)

The external blocker at the end of Phase 5C — no real Google Workspace mailbox to test against — was resolved by the owner during this session before Phase 6A began: [email protected] now exists and live delivery was validated end to end (isolated send test + a full real activation/reset lifecycle). This is already recorded in docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md (status header, §14) and docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md (§11's propagation-delay note), committed at 4c0a950 and tagged v0.5.3-enrollment-comms — this phase did not need to redo that work, only confirm it was recorded, which it was.

4. Architecture summary

program (existing)  ──  courses  ──  course_modules  ──  module_activities
                                                             ├─ lab → scenario_id (existing)
                                                             └─ assessment/capstone → assessment_definition_id (existing)

Full design: docs/COURSE_CONTENT_MODEL.md. Full course/module map: docs/ROOT_PROGRAM_ARCHITECTURE.md. Full existing-content inventory this was built from: docs/ROOT_CURRICULUM_INVENTORY.md.

Delivery modes: the same content model serves both instructor-led (Phase 5A classrooms) and self-paced (Phase 5B enrollment) students — one buildCourseTree() function (platform/api/src/course-progress.js), one content.js Markdown loader, consumed by both course-routes.js (student) and admin-course-routes.js (instructor), the latter additionally exposing instructor notes via the same file's ## Instructor Notes convention. No forked curriculum.

5. What was built

Migration — platform/api/migrations/022_course_content.sql: courses, course_modules, module_activities, activity_completions, plus seed data for 13 courses, 8 modules, and 51 activities (44 mechanically mapped from existing rootnode-path.json stages, 6 gold-module activities, 1 capstone activity) — see that file's own extensive header comments.

Content — content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/: 6 Markdown files (lesson, demonstration, knowledge check, guided exercise, lab intro, reflection), each following the shared/instructor-notes split convention.

Backend — content.js (Markdown loader), course-progress.js (completion derivation + prerequisite locking, shared by both surfaces), course-routes.js (student API), admin-course-routes.js (instructor API), wired into server.js. platform/api/Dockerfile now also copies content/.

Frontend — CourseView.jsx (student: My Programs → ROOT_ → Course → Module → Activity → Launch Lab → back → continue), wired into ProgramsTab.jsx's existing "Continue Learning" flow via a new "View Courses" button (the original direct-to-Lab button is unchanged). CurriculumView.jsx (instructor: program structure, per-module teaching detail, instructor notes, per-student progress lookup), wired into AdminPortal.jsx as a new "Curriculum" tab.

Tests — platform/test/e2e-phase6a.js (21 assertions: hierarchy, ordering, all three completion behaviors, locking, resume, cross-student isolation, RBAC, draft-hiding, version stability) and infra/scripts/drills/test-phase6a-course-rehearsal.js + run-phase6a-course-rehearsal.sh (a real-k3s dress rehearsal of the gold module end to end, including the Lab's own setup_commands and a real kubectl patch against the live cluster).

6. The gold-standard module

root-10-m01-health-probes-and-troubleshooting, under ROOT 10 (Kubernetes Troubleshooting & Observability): lesson (probe concepts) → demonstration (reading kubectl describe pod Events for a probe failure) → knowledge check → guided exercise (write a readiness probe on paper) → Launch Lab (rootnode-probe-port-mismatch, RootNode-authored) → reflection (root cause + Real Ops prevention takeaway). Instructor notes on 5 of its 6 activities (demo plan, misconceptions, timing, discussion questions, extensions). This is the template docs/COURSE_AUTHORING_STANDARD.md documents for all future module authoring.

7. Honest content states

No course is ready. 5 courses (01-04, 11) are planned with zero modules — genuinely no content exists for them. 7 courses (05-10, 12, capstone) are partial — real, working labs mapped in, one fully ready module (the gold standard), everything else awaiting lesson authoring in Phase 6B. Nothing was fabricated to make the UI look more complete than it is.

8. Test results

• e2e-phase6a.js: 21 passed, 0 failed.
• test-phase6a-course-rehearsal.js (real k3s Lab): 12 passed, 0 failed, including a real kubectl patch against a live cluster inside the student's actual disposable Lab container.
• Full regression (Phase 2A/2B/3A/3B/5A/5B/5C) — see the final report for the run-by-run result; no Phase 6A change touched any file those suites exercise other than additive route registration in server.js.

9. What Phase 6A deliberately did not build

Per the authorization's explicit scope line: init_/compile_ curriculum, a Parent Portal, Stripe/payments, public registration, an AI tutor, chat/video/voice, proctoring, a mobile app, certificates, a multi-host scheduler, production deployment changes, a CMS, or dozens of placeholder lessons. Lesson authoring for courses 06-10/12/capstone beyond the gold standard is explicitly Phase 6B+ scope.

10. Known limitations / recommended Phase 6B scope

• ROOT 08/09's real, existing scenario content (storage/scheduling, and a 22-scenario CKS security bank) is inventoried but not yet wired into modules — the natural next content slice.
• Course-level lesson authoring for ROOT 05-07/10 (m02)/12/capstone: labs exist, teaching content doesn't yet — apply docs/COURSE_AUTHORING_STANDARD.md per module.
• POST /api/assessments/:definitionId/start does not itself re-check the capstone's unlock_rule server-side (a pre-existing Phase 3B gap, not introduced by this phase — the student-facing /api/capstone view does compute and display lock state correctly, and the UI never exposes a "start" action while locked, but the raw route would technically accept a premature start if called directly). Not fixed here — it's outside the course/content-model scope this phase was authorized for; worth a small, isolated fix in a future phase.
• Course-to-course prerequisite locking is currently sequential/manually declared, not derived from the assessment engine's own unlock_rule JSON — the two happen to agree today by construction (see docs/ROOT_PROGRAM_ARCHITECTURE.md's "Real Ops and Capstone placement"); a future phase could unify them if course content grows complex enough to warrant it.