# Phase 6F — ROOT_ V1 Curriculum Integration & Pilot Readiness

Phase 6F's mission: not more curriculum breadth, but integration, polish, and full-program QA —
answering, with evidence, "could RootNode Academy responsibly enroll a real student into ROOT_ V1
and take them through the intended learning journey?"

## Baseline verification

Confirmed at start: branch `main`, clean tree, HEAD = `origin/main` = Phase 6E's
`87ad1251ce4aee8597ef29a446e44b1247d68b1c`. Content validation: 0 errors, 13 courses, 48
modules, 312 activities, 126 scenario files — matching Phase 6E's own final numbers exactly.

## ROOT_ V1 scope — defined in `docs/ROOT_V1_CURRICULUM_MANIFEST.md`

12 of 13 existing courses are in V1 (all genuinely READY except ROOT 11, intentionally PARTIAL as
a single bonus orientation module). ROOT 08 is excluded (`visibility=draft`). See that document
for the full course-by-course table, and `docs/ROOT_V1_PREREQUISITE_MAP.md` /
`docs/ROOT_V1_ASSESSMENT_MAP.md` for the prerequisite graph and assessment coverage.

## The central integration finding: three "instructor-led-only" modules are load-bearing for the legacy Capstone gate

Auditing Phase 6E's own flagged limitation (three bare practice-bank modules) against the
pre-existing `rootnode-path.json` Capstone `unlock_rule` found their scenario_ids are not
generic extra practice — they are the *literal* content of three of its six gating stages. An
initial attempt to reclassify them `is_required=false` was caught and reverted before commit
(see `030_phase6f_capstone_gate_correction.sql`'s own header) once this was understood, in favor
of giving each a short, real intro-lesson activity instead — closing the self-paced gap without
touching the legacy gate's actual requirements. Full detail in
`docs/ROOT_V1_CURRICULUM_MANIFEST.md`.

A second, similar discovery came out of the end-to-end rehearsal (see below): the SAME legacy
gate also requires two scenarios (`services-mcq`, and all 5 of `root-07-m02`'s configuration
scenarios) that are not course-content-model prerequisites of anything on the path to
`root-capstone`. A student could reach "root-capstone unlocked" at the course layer while the
underlying assessment start route still 403s for an unrelated reason. **This is a real,
pre-existing gap, not introduced by Phase 6F** — flagged as a known limitation below rather than
fixed, since closing it is a real product decision (add root-07 as a course-layer Capstone
prerequisite, or extend the legacy stage list) that Phase 6F's mandate doesn't unilaterally make.

## Course-level status audit correction

`courses.status` had drifted stale for ROOT 05, 06, 07, 09, 10, 12, and Capstone — every module
in each had already reached real `ready` content in an earlier phase, but the course-level field
was never bumped. Corrected in `029_phase6f_root_v1_integration.sql`, verified against the live
module-level data, not assumed from prior phase reports.

## Capstone gate strengthened (Step 7)

`root-capstone.prerequisites` now also requires `root-09-kubernetes-security`, alongside the
pre-existing `root-12-real-ops` — the Capstone's own scenario pool has zero security-scenario
overlap, and ROOT 09 only reached genuine READY status this same phase. The pre-existing
six-stage legacy gate was deliberately left unchanged. See `docs/ROOT_CAPSTONE_READINESS.md` §1b
and `031_phase6f_capstone_security_prerequisite.sql`.

## ROOT_ V1 program + Lab orientation (new)

No orientation content existed anywhere before this phase. Added `root-01-m00-welcome-to-root`
— a new required front-door module (program overview, the Learn/Practice/Lab/Troubleshoot/
Validate loop, self-paced vs. instructor-led, assessments/Capstone, and a full Lab-lifecycle
orientation covering disposability, hints, reset, and help-requests) — sequenced before what was
previously ROOT 01's first module. See `032_phase6f_root_v1_orientation.sql`.

## Cascading regression fallout from these real changes

Every genuine content/schema change this phase (the orientation module, the three practice-bank
intro lessons, the new Capstone prerequisite) shifted real completion sequences that Phase 6A-6E's
own e2e suites and rehearsal scripts had hardcoded. Found and fixed, each with the underlying gap
named explicitly in a code comment: resume-pointer assertions in `e2e-phase6a/6b/6d/6e.js` and
`test-phase6d-foundations-rehearsal.js`/`test-phase6e-foundations-rehearsal.js`; missing new
intro-lesson completions in `foundations-helper.js`'s `completeThroughRoot06`/`completeThroughRoot10`
and in `e2e-phase6a.js`/`e2e-phase6b.js`'s own inline completion sequences; a stale course-status
assertion in `e2e-phase6b.js`; a draft-activity-visibility test in `e2e-phase6b.js` that had
targeted the now-fully-excluded ROOT 08 (repointed at ROOT 09); and a new completion chain
(root-07-m03/m04, all of ROOT 09) added to `e2e-phase6b.js`'s `bypass` student flow, now needed
because `root-capstone` gates on ROOT 09 too. None were platform bugs — every one was a stale
test assumption the newly-added/changed content revealed, the same pattern Phase 6E established.

## Testing

`platform/test/e2e-phase6f.js` — 17/17 passing (fresh stack): V1 manifest/status correctness,
ROOT 08 exclusion (both DB-level and student-visibility), no cycles/missing prerequisite nodes,
ROOT 01-04 re-verified ready, the new orientation module's unlock behavior, optional-activity
handling under the full Capstone-eligible chain, the strengthened Capstone gate in both
directions (locked with only ROOT 12 done; unlocked once ROOT 09 is also done; direct-API bypass
still rejected), version-bump content stability, instructor-notes RBAC (including on locked, not
just draft, content), cross-student isolation, full V1 course-list completeness for a fresh
enrollment, logout/login persistence, and an explicit age-independence check (no age/grade column
exists on `students`, enrollment never asks for one).

## Multi-student pilot rehearsal

`infra/scripts/drills/test-phase6f-root-v1-pilot.js` — 22/22 passing against a real, freshly-built
stack: a real cohort + live classroom session with three students in genuinely different states —
Student A on track (real manual-marker progression), Student B hitting a REAL Lab validation
failure, sending a real Need Help request, the instructor seeing and acknowledging it live, then
Student B genuinely fixing the failure with real shell commands and passing for real; Student C
having their real disposable Lab reaped mid-task via a real admin destroy (simulating an idle-
reaper event), confirming their academic progress survived intact, then recreating a fresh Lab
and resuming the same task. Instructor visibility distinguishes all three states; cross-student
isolation confirmed with real, not assumed, evidence (A's manual-marker progress vs. B's
Lab-only progress).

## End-to-end ROOT_ V1 rehearsal

`infra/scripts/drills/test-phase6f-root-v1-end-to-end.js` — 14/14 passing: one real student,
entirely through the real student API (no admin shortcut, no direct database completion write),
progressing ROOT 01→02→03→04 (via the established foundations helper) →05→06→09→10→12→
Capstone-eligible, with a genuine real-Lab checkpoint (a real nested-Docker container-networking
diagnose-and-fix, re-proven live on this specific student rather than assumed from an earlier
phase's rehearsal). Confirms direct API cannot skip ahead at the ROOT 06→09/10/12/Capstone
boundary. Ends with the real `rootnode-capstone` assessment genuinely `201`-startable — the
strongest possible proof the full V1 pathway is real, not merely "the course tree says complete."

## Regression

Full fresh-stack reruns after every fix: 6A (23/23), 6B (26/26), 6C (17/17), 6D (21/21), 6E
(23/23), 6F (17/17) — all green, each run against its own freshly-reset stack per the established
convention. `git diff` for this phase touches migrations/content/tests/docs only — no
`platform/api/src` application-code change was needed (unlike Phase 6E, which needed exactly
one). Phase 5A/5B/5C were not re-run: this phase's classroom/help-request/environment-destroy
usage (in the multi-student rehearsal) exercises routes those suites already cover, and no code
in `classroom.js`/`enrollment.js`/`notifications.js` was touched.

## Frontend, Lab image, nested Docker, k3s

Frontend: `npm run build` clean, no code changes this phase (content/schema only). Lab image:
rebuilt for every fresh-stack test/rehearsal run this phase; standalone Lab boot and real bash
task completion proven in the multi-student rehearsal (Students A/B/C); nested Docker proven in
both the end-to-end rehearsal's real container-networking fix and the earlier ROOT 04 content
itself; k3s health reconfirmed unaffected (the Phase 6E rehearsal's own k3s-health assertion was
rerun fresh, post-Phase-6F-migrations, and still passes).

## Resource observations (development-environment only, not production capacity numbers)

Real Lab boot-to-ready during rehearsals: consistently well under the existing dev-stack norm
established in Phase 6D/6E (no regression from added content — content changes don't touch Lab
boot code). Three concurrent student Labs in the multi-student rehearsal (A idle, B and C active
simultaneously) provisioned and ran without contention on a single dev host. No anomalies,
crashes, or resource exhaustion observed. These are qualitative development-environment
observations only — real capacity planning remains the dedicated production-server benchmark's
job, unchanged from every prior phase's own caveat.

## New application code and why

None. Every V1 integration requirement (orientation content, practice-bank framing, the
Capstone/ROOT 09 edge, the stale-status correction, the ROOT 08 exclusion) was satisfiable with
the existing `courses`/`course_modules`/`module_activities` schema and the existing `visibility`/
`status`/`is_required`/`prerequisites` mechanisms — consistent with this phase's own "integrate,
don't build" mandate.

## Documentation

New: `ROOT_V1_CURRICULUM_MANIFEST.md`, `ROOT_V1_PREREQUISITE_MAP.md`, `ROOT_V1_ASSESSMENT_MAP.md`,
`ROOT_V1_SYLLABUS.md`, `ROOT_V1_INSTRUCTOR_GUIDE.md`, `ROOT_V1_STUDENT_REQUIREMENTS.md`,
`ROOT_V1_INSTRUCTOR_LED_PILOT.md`, `WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md`, this document.
Updated: `ROOT_PROGRAM_ARCHITECTURE.md` (course-sequence table, prerequisite-chain notes),
`ROOT_PILOT_CURRICULUM.md` (self-paced-readiness correction), `ROOT_PROGRAM_DURATION_MODEL.md`
(real post-integration totals), `ROOT_CAPSTONE_READINESS.md` (§1b, the new third gate).
Reviewed, no change needed: `ROOT_FOUNDATIONS_PILOT_READINESS.md`, `COURSE_AUTHORING_STANDARD.md`,
`ENGINEERING_SOP.md`, `REMOTE_AND_SELF_PACED_ARCHITECTURE.md`, `platform/README.md`'s
architecture sections (its test list was updated — see below).

## Known limitations

- **The legacy six-stage Capstone unlock_rule and the course-layer prerequisite chain are not
  fully congruent**: `root-07-m01`'s `services-mcq` and all 5 of `root-07-m02`'s configuration
  scenarios gate the legacy assessment-start route but are not course-layer prerequisites of
  anything on the path to `root-capstone`. Found via this phase's own end-to-end rehearsal;
  documented, not fixed — closing it is a real product decision (extend the legacy stage list,
  or add ROOT 07 as a course-layer Capstone prerequisite) outside a "polish and integrate" phase.
- ROOT 11's remaining six modules (CI/CD, GitOps, IaC) require lab infrastructure not yet built —
  unchanged, explicitly out of scope again this phase.
- Instructor-led vs. self-paced timing remains prose in Instructor Notes, not a database field —
  unchanged from every prior phase.
- No placement testing or instructor-override UI — explicitly out of scope; the age-independence
  requirement (Step 29) is satisfied architecturally (no age/grade column, no age-based gate
  anywhere in enrollment) rather than through a placement mechanism, since none was authorized.

## Recommended Phase 7 scope

Phase 7 is explicitly the business/product architecture layer per this phase's own authorization
— formalizing the INIT_/COMPILE_/ROOT_/BOOTCAMP_ family model, delivery-mode separation from
curriculum, and (informed by `docs/WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md`) whatever camp/
registration/payment platform work the business decides to build around ROOT_ V1's now-proven
Option A (Linux & Systems Foundations Camp) as a first commercial offering.