# 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: `academy@rootnodeacademy.com`
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.