rootnode-academy/docs/PHASE6F_ROOT_V1_PILOT_READINESS.md

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.