diff --git a/docs/PHASE6F_ROOT_V1_PILOT_READINESS.md b/docs/PHASE6F_ROOT_V1_PILOT_READINESS.md new file mode 100644 index 0000000..3fe3910 --- /dev/null +++ b/docs/PHASE6F_ROOT_V1_PILOT_READINESS.md @@ -0,0 +1,185 @@ +# 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. diff --git a/docs/ROOT_CAPSTONE_READINESS.md b/docs/ROOT_CAPSTONE_READINESS.md index 22dba5e..9226880 100644 --- a/docs/ROOT_CAPSTONE_READINESS.md +++ b/docs/ROOT_CAPSTONE_READINESS.md @@ -27,6 +27,19 @@ This module derives its own completion the same way every other lesson-only modu capstone assessment engine checks before allowing a start (see §3 below for why these two gates are deliberately independent). +## 1b. A third, independent gate added in Phase 6F + +Phase 6F added `root-09-kubernetes-security` to `root-capstone`'s own `courses.prerequisites` +array (alongside the pre-existing `root-12-real-ops`) — a course-content-model-level gate, +distinct from both this readiness module (still non-gating) and the curriculum-path +`unlock_rule` in §3 below (still unchanged: six K8s scenario stages, no security stage). This +means the `root-capstone` COURSE itself (visible in the student/instructor course tree) is now +locked until ROOT 09 is also complete, even though the underlying `/api/assessments/rootnode- +capstone/start` route's own gate did not change. See `docs/ROOT_V1_CURRICULUM_MANIFEST.md` +Step 7 for the full evidence and reasoning, and `031_phase6f_capstone_security_prerequisite.sql` +for the migration. This adds a third independent layer rather than blurring the existing two — +consistent with this document's own §3 reasoning for keeping enforcement layers separate. + ## 2. What was NOT built No answers, no exact scenario IDs from the current pool, no capstone-specific hint content diff --git a/docs/ROOT_PILOT_CURRICULUM.md b/docs/ROOT_PILOT_CURRICULUM.md index abaf05c..a3c9263 100644 --- a/docs/ROOT_PILOT_CURRICULUM.md +++ b/docs/ROOT_PILOT_CURRICULUM.md @@ -1,5 +1,10 @@ # ROOT Pilot Curriculum — Authoritative Manifest +**Updated for Phase 6F**: `docs/ROOT_V1_CURRICULUM_MANIFEST.md` is now the canonical technical +definition of ROOT_ V1 scope (what's included/excluded and why). This document's own course-by- +course pilot table below remains accurate but its Phase 6E-era claim about three practice-bank +modules needing instructor-led delivery is now stale — see the correction immediately below. + This is the single authoritative answer to "what are we actually teaching in the first paid pilot." It uses honest READY / PARTIAL / DEFERRED / NOT IN PILOT labels — nothing here is marketed as more finished than it is. See @@ -7,17 +12,15 @@ marketed as more finished than it is. See means and [`docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md`](ROOT11_DEVOPS_PLATFORM_SCOPE.md) for the ROOT 11 scope decision referenced below. -## Pilot delivery mode: instructor-led (cohort-based), with a fully self-paced foundation +## Pilot delivery mode: fully self-paced-capable as of Phase 6F -The first pilot is scoped as **instructor-led** as its recommended default, not because most of -the curriculum requires it — as of Phase 6E, ROOT 01-04 (the entire foundational half) and every -Kubernetes/security/troubleshooting/real-ops/capstone module EXCEPT three specific practice-bank -modules meet the full self-paced bar (no "your instructor will explain this" gaps, verified -programmatically). Those three flagged modules — dense hands-on practice banks whose sibling -module in the same course already carries the taught concept — are READY for instructor-led -delivery only; running them live lets an instructor supply framing a self-paced student wouldn't -get. Fully self-paced delivery of those specific modules is deferred to a future phase pending an -authored teaching layer for each. See Section 16 discussion below. +As of Phase 6E, ROOT 01-04 (the entire foundational half) met the full self-paced bar. Three +specific practice-bank modules (`root-06-m01`, `root-07-m01`, `root-10-m02`) were flagged as +instructor-led-only — dense hands-on scenario banks with no lesson framing of their own. +**Phase 6F closed this gap**: each received a short, real intro-lesson activity explaining what +the bank is and how to use it (`docs/ROOT_V1_CURRICULUM_MANIFEST.md` Step 4) — all three, and +their parent courses, are now genuinely self-paced-ready. Instructor-led delivery remains fully +supported and recommended for a first cohort, but is no longer required by any content gap. ## Program: ROOT_ (root-kubernetes-foundations) diff --git a/docs/ROOT_PROGRAM_ARCHITECTURE.md b/docs/ROOT_PROGRAM_ARCHITECTURE.md index c9a2ec9..5ebe761 100644 --- a/docs/ROOT_PROGRAM_ARCHITECTURE.md +++ b/docs/ROOT_PROGRAM_ARCHITECTURE.md @@ -29,15 +29,15 @@ prerequisite chain (01→02→03→04→05) enforced server-side. | 2 | Linux Administration & Networking | **READY** | Phase 6E: 6 modules, real Linux/networking scenarios, a wired assessment — see `docs/PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md`. Real prerequisite: ROOT 01 complete. | | 3 | Git & Collaborative Development | **READY** | Phase 6E: 6 modules, real local-Git scenarios (including a real merge conflict and a real local-bare-remote push), a wired assessment. Real prerequisite: ROOT 02 complete. | | 4 | Containers & Docker | **READY** | Phase 6E: 8 modules using the nested Docker Engine (built and verified Phase 6D, `docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md` §3), real container scenarios, a wired assessment. Real prerequisite: ROOT 03 complete. | -| 5 | Kubernetes Foundations | **PARTIAL** | Phase 6B added a READY front-door module (`root-05-m00-kubernetes-mental-model` — full lesson/demo/knowledge-check/guided-exercise/lab/reflection) sequenced before the existing 20-scenario bare-lab bank (`root-05-m01`), which now sits behind it. | -| 6 | Kubernetes Application Workloads | **PARTIAL** | Phase 6B added a READY `root-06-m02-deployments-scaling-updates` and a PARTIAL `root-06-m03-jobs-cronjobs-daemonsets`, both in front of the existing bare-lab bank. | -| 7 | Kubernetes Networking & Configuration | **PARTIAL** | Phase 6B added a READY `root-07-m03-services-and-service-discovery` and a PARTIAL `root-07-m04-ingress-networkpolicy-foundations`. The existing configuration bank (`root-07-m02`) still has no authored teaching content — an honest, documented gap. | -| 8 | Kubernetes Storage & Scheduling | **PARTIAL** | Phase 6B wired the real scenario content the inventory identified (PV/PVC, StorageClass, taints/tolerations, PDB, quotas/limits) into two new PARTIAL modules — moved off PLANNED for the first time. | -| 9 | Kubernetes Security | **PARTIAL** | Phase 6B built the 22-scenario CKS-style bank into four modules (Security Model & SecurityContext — READY; ServiceAccounts & RBAC, Network & Supply Chain Security, Cluster Hardening & Runtime — all PARTIAL), classifying scenarios CORE/GUIDED/INDEPENDENT/ADVANCED/ASSESSMENT-BANK rather than exposing them as 22 disconnected tasks — moved off PLANNED. | -| 10 | Kubernetes Troubleshooting & Observability | **PARTIAL** | The Phase 6A gold-standard module (READY, unmodified) plus a new PARTIAL `root-10-m03-troubleshooting-framework` (the generalized Observe/Evidence/Hypothesis/Test/Repair/Validate/Prevent framework) and the existing bare-lab bank, now sequenced last. | -| 11 | DevOps & Platform Engineering Foundations | **PLANNED** | No CI/CD/IaC/GitOps scenario content exists anywhere in this repository — unchanged, out of Phase 6B's authoring scope. | -| 12 | RootNode Real Ops | **PARTIAL** | Phase 6B added an incident-response framing lesson and a post-incident reflection wrapping the existing 4-scenario module — the incidents themselves are unchanged, still deliberately un-guided. | -| 13 | ROOT Capstone — Operate and Recover a Production-Like Environment | **PARTIAL** | Phase 6B added a READY Capstone Readiness module (orientation, no answers) sequenced before the existing capstone assessment module — see `docs/ROOT_CAPSTONE_READINESS.md`. | +| 5 | Kubernetes Foundations | **READY** (Phase 6F) | Phase 6B added a READY front-door module (`root-05-m00-kubernetes-mental-model`) sequenced before the 20-scenario bare-lab bank (`root-05-m01`), which itself already carried a lesson+reflection wrapper — Phase 6F's audit found both modules genuinely ready and corrected the stale course-level status. | +| 6 | Kubernetes Application Workloads | **READY** (Phase 6F) | Phase 6B's READY `root-06-m02` and `root-06-m03` remain unchanged; Phase 6F gave the practice-bank `root-06-m01` a real intro-lesson activity, closing the last gap. | +| 7 | Kubernetes Networking & Configuration | **READY** (Phase 6F) | Phase 6C already converted `root-07-m02` to a full teaching module; Phase 6F gave the practice-bank `root-07-m01` a real intro-lesson activity, closing the last gap. | +| 8 | Kubernetes Storage & Scheduling | PARTIAL — **excluded from ROOT_ V1** | Phase 6B's two PARTIAL modules are unchanged; Phase 6F excluded the whole course from ROOT_ V1 (`visibility=draft`) since nothing downstream requires it — see `docs/ROOT_V1_CURRICULUM_MANIFEST.md`. | +| 9 | Kubernetes Security | **READY** (Phase 6F) | Phase 6B's four modules (all real CKS-style content) were already individually ready; Phase 6F's audit corrected a stale course-level status field. Now also a required Capstone prerequisite (Step 7). | +| 10 | Kubernetes Troubleshooting & Observability | **READY** (Phase 6F) | The Phase 6A gold-standard module and Phase 6C's `root-10-m03` remain unchanged; Phase 6F gave the practice-bank `root-10-m02` a real intro-lesson activity, closing the last gap. | +| 11 | DevOps & Platform Engineering Foundations | **PARTIAL, by design** | One real orientation module exists (lesson/knowledge-check/reflection); Phase 6F repositioned it explicitly as an optional bonus module, not a promise of a full course — see `docs/ROOT_V1_CURRICULUM_MANIFEST.md`. Deeper CI/CD/IaC/GitOps content remains unbuilt, unchanged. | +| 12 | RootNode Real Ops | **READY** (Phase 6F) | Phase 6B's framing lesson/reflection wrapping the existing 4-scenario module was already complete; Phase 6F's audit corrected a stale course-level status. | +| 13 | ROOT Capstone — Operate and Recover a Production-Like Environment | **READY** (Phase 6F) | Phase 6B's Capstone Readiness module was already complete; Phase 6F's audit corrected a stale course-level status and added ROOT 09 as a joint course-level prerequisite alongside ROOT 12 — see `docs/ROOT_CAPSTONE_READINESS.md` §1b. | No course is marked READY at the course level in Phase 6A — that's honest: a course only earns READY once every module in it has real teaching content, and Phase 6A deliberately built exactly @@ -80,6 +80,14 @@ real student, verified live on both a fully-completed student and a fresh one. A gap in the direct-API completion route (found while proving this chain, unrelated to any single phase's own content) is also fixed this phase — see that document for detail. +**Updated for Phase 6F** (`docs/ROOT_V1_CURRICULUM_MANIFEST.md`): ROOT 05, 06, 07, 09, 10, 12, +and Capstone all reached genuine course-level READY status (a stale-status audit correction plus +real intro-lesson authoring for three practice-bank modules). ROOT 08 was excluded from ROOT_ V1 +(`visibility=draft`). ROOT 11 stays PARTIAL by design, repositioned as an optional orientation +bonus. `root-capstone`'s own prerequisites now also require ROOT 09 (Security) complete, +alongside the pre-existing ROOT 12 requirement. A new required orientation module +(`root-01-m00-welcome-to-root`) now precedes ROOT 01's original first module. + ## Deviations from the spec's suggested sequence, and why The authorization's suggested sequence listed Security (09) after Storage/Scheduling (08) and diff --git a/docs/ROOT_PROGRAM_DURATION_MODEL.md b/docs/ROOT_PROGRAM_DURATION_MODEL.md index fb02b99..5793d33 100644 --- a/docs/ROOT_PROGRAM_DURATION_MODEL.md +++ b/docs/ROOT_PROGRAM_DURATION_MODEL.md @@ -1,48 +1,47 @@ # ROOT_ Program Duration Model -Phase 6E §28 — recalculated from actual authored activities in the live database. Run: -`SELECT c.course_id, SUM(a.estimated_duration_minutes) ... GROUP BY c.course_id` against the -current schema, same method as Phase 6D's original version of this document. +Phase 6F Step 25 (built on Phase 6E §28) — recalculated from actual authored activities in the +live database after Phase 6F's curriculum integration (orientation module + the three +practice-bank intro lessons). Run: `SELECT c.course_id, SUM(a.estimated_duration_minutes) ... +GROUP BY c.course_id` against the current schema, same method as every prior version of this +document. ## Per-course totals (self-paced estimate) -| Course | Activities | Minutes | Hours | -|---|---|---|---| -| ROOT 01 Computing & Linux Foundations | 35 | 338 | 5.6 | -| ROOT 02 Linux Administration & Networking | 37 | 388 | 6.5 | -| ROOT 03 Git & Collaborative Development | 31 | 312 | 5.2 | -| ROOT 04 Containers & Docker | 43 | 444 | 7.4 | -| ROOT 05 Kubernetes Foundations | 28 | 403 | 6.7 | -| ROOT 06 Kubernetes Application Workloads | 22 | 295 | 4.9 | -| ROOT 07 Kubernetes Networking & Configuration | 27 | 353 | 5.9 | -| ROOT 08 Kubernetes Storage & Scheduling | 15 | 250 | 4.2 | -| ROOT 09 Kubernetes Security | 40 | 745 | 12.4 | -| ROOT 10 Kubernetes Troubleshooting & Observability | 20 | 277 | 4.6 | -| ROOT 11 DevOps & Platform Engineering | 3 | 35 | 0.6 | -| ROOT 12 Real Ops | 6 | 115 | 1.9 | -| ROOT Capstone | 5 | 120 | 2.0 | -| **Total (all authored content)** | **312** | **4,075** | **67.9** | +| Course | Activities | Minutes | Hours | In ROOT_ V1? | +|---|---|---|---|---| +| ROOT 01 Computing & Linux Foundations | 38 | 353 | 5.9 | Yes | +| ROOT 02 Linux Administration & Networking | 37 | 388 | 6.5 | Yes | +| ROOT 03 Git & Collaborative Development | 31 | 312 | 5.2 | Yes | +| ROOT 04 Containers & Docker | 43 | 444 | 7.4 | Yes | +| ROOT 05 Kubernetes Foundations | 28 | 403 | 6.7 | Yes | +| ROOT 06 Kubernetes Application Workloads | 23 | 299 | 5.0 | Yes | +| ROOT 07 Kubernetes Networking & Configuration | 28 | 356 | 5.9 | Yes | +| ROOT 08 Kubernetes Storage & Scheduling | 15 | 250 | 4.2 | **No — excluded** | +| ROOT 09 Kubernetes Security | 40 | 745 | 12.4 | Yes (required for Capstone) | +| ROOT 10 Kubernetes Troubleshooting & Observability | 21 | 280 | 4.7 | Yes | +| ROOT 11 DevOps & Platform Engineering (orientation only) | 3 | 35 | 0.6 | Yes (optional bonus) | +| ROOT 12 Real Ops | 6 | 115 | 1.9 | Yes (required for Capstone) | +| ROOT Capstone | 5 | 120 | 2.0 | Yes | +| **Total (all authored content, incl. excluded ROOT 08)** | **318** | **4,100** | **68.3** | | +| **ROOT_ V1 total (excludes ROOT 08)** | **303** | **3,850** | **64.2** | | -**ROOT Foundations (01-04) subtotal: 146 activities, 1,482 minutes, 24.7 hours.** This is now -real, measured data — Phase 6D's own version of this document correctly flagged the eventual -"20-25 hour" range as a planning ESTIMATE pending real authorship; the actual total (24.7 hours) -landed inside that estimated range. +ROOT 01's activity/minute count grew by 3 activities / 15 minutes this phase (the new +`root-01-m00-welcome-to-root` orientation module). ROOT 06/07/10 each grew by 1 activity / 3-4 +minutes (their new practice-bank intro lessons). See `docs/ROOT_V1_CURRICULUM_MANIFEST.md` for +why. + +**ROOT Foundations (01-04) subtotal: 149 activities, 1,497 minutes, 25.0 hours.** ## Self-paced vs. instructor-led -As in Phase 6D's version of this document: the figures above are self-paced estimates (the sum -of each activity's own `estimated_duration_minutes`). Instructor-led classroom time is still not -a separate summable database field — every Instructor Notes section documents approximate live- -facilitation timing in prose (e.g. ROOT 02 Module 3's "25 minutes read; 15-20 minutes live with -discussion — longer than a typical lesson, deliberately"), but this remains per-activity -guidance embedded in Markdown, not a column a query can sum. A future phase could add a distinct +Unchanged from Phase 6D/6E: the figures above are self-paced estimates (the sum of each +activity's own `estimated_duration_minutes`). Instructor-led classroom time is still not a +separate summable database field — every Instructor Notes section documents approximate live- +facilitation timing in prose. A future phase could add a distinct `estimated_duration_minutes_instructor_led` column if precise classroom scheduling becomes a -real, measured need. - -As a conservative approximation, instructor-led delivery of the full 67.9-hour curriculum should -be expected to run somewhat longer once live discussion and demonstration time is added — -consult the relevant Instructor Notes before scheduling a live cohort session, don't treat the -self-paced total as a classroom-time promise. +real, measured need. See `docs/ROOT_V1_INSTRUCTOR_LED_PILOT.md` for the cohort packaging this +duration model supports. ## What this is NOT @@ -51,12 +50,10 @@ Not a marketing duration, not a promise, not a certification-hours figure. `docs/COURSE_AUTHORING_STANDARD.md` §4) — this total will get more accurate as real completion- time data accumulates from actual students, not before. -## Program completeness +## Program completeness — ROOT_ V1 vs. the full authored program -With ROOT 01-04 now authored, the ROOT_ program's structured curriculum (excluding ROOT 08, -deliberately deferred as non-capstone-gating, and ROOT 11 modules 2-7, deferred pending future -lab infrastructure — see `docs/ROOT_PILOT_CURRICULUM.md`) now runs a complete, measured -beginning-to-advanced path: Linux fundamentals → Linux administration/networking → Git → -containers → Kubernetes → security → troubleshooting → real operations → capstone. This is the -first phase where the FULL foundational-to-capstone path has real, authored content and a real -measured duration at every step, not a partial curriculum starting mid-stack. +ROOT_ V1 (`docs/ROOT_V1_CURRICULUM_MANIFEST.md`) is 64.2 of the program's 68.3 authored hours — +everything except ROOT 08, deliberately excluded as non-Capstone-gating and not yet authored to +V1 standard. ROOT 11's remaining six modules were never counted in either total (they don't +exist yet, unlike ROOT 08's PARTIAL-but-real content) — see `docs/ROOT_CURRICULUM_COVERAGE_ +MATRIX.md` for the honest READY/PARTIAL/PLANNED breakdown across the entire program. diff --git a/docs/ROOT_V1_ASSESSMENT_MAP.md b/docs/ROOT_V1_ASSESSMENT_MAP.md new file mode 100644 index 0000000..14b488d --- /dev/null +++ b/docs/ROOT_V1_ASSESSMENT_MAP.md @@ -0,0 +1,53 @@ +# ROOT_ V1 Assessment Map + +Phase 6F Step 8 — every formal assessment in ROOT_ V1, what it actually tests, and how it +relates to course completion. Formative checks (knowledge checks, guided exercises) exist inside +every module and are not separately catalogued here — see `docs/COURSE_CONTENT_MODEL.md` for +how they're modeled. + +| Course | Assessment | Required scenarios | Random pool | Hints | Duration | +|---|---|---|---|---|---| +| ROOT 01 | `rootnode-linux-foundations-assessment` | linux-shell-basics, linux-permissions-foundations | 2 from a 4-task pool + 2 MCQ | disabled | 30 min | +| ROOT 02 | `rootnode-linux-networking-assessment` | linux-network-inspection, linux-troubleshooting-framework | 2 from a 4-task pool + 2 MCQ | disabled | 35 min | +| ROOT 03 | `rootnode-git-fundamentals-assessment` | git-everyday-basics, git-branching-and-merge | 1 task + 2 MCQ | disabled | 35 min | +| ROOT 04 | `rootnode-containers-assessment` | docker-cli-basics, docker-build-image | 2 from a 3-task pool + 2 MCQ | disabled | 40 min | +| ROOT 09 | `rootnode-security-assessment` | cks-pod-security-context, cks-rbac-least-privilege, cks-network-policy | 2+1+2 across three CKS-style pools | disabled | 60 min | +| — | `rootnode-capstone` | rootnode-runaway-monitor, broken-deployment, rootnode-probe-port-mismatch, rootnode-enforce-limits | 1 each from workloads/config/troubleshooting pools | flagged (visible but logged) | 90 min | +| — | `rootnode-quick-assessment` | none | draws from workloads/networking/troubleshooting/real-ops pools | disabled | 60 min | + +`rootnode-quick-assessment` is a pre-existing, general Kubernetes proficiency check not wired to +any single course's completion — it predates the course-content-model layer and is left as-is +(unaffected by this phase, still reachable via `/api/assessments/rootnode-quick-assessment/start` +for practice/diagnostic use, e.g. by an instructor assessing a transfer student's baseline). + +## Relationship to course completion + +Every course-gating assessment (ROOT 01/02/03/04/09) is wired to exactly one `assessment`-type +activity (`completion_behavior = 'auto_assessment'`) inside that course's last module. Passing +it is derived the same way a scenario Lab's completion is derived — from a real +`achievements` row written on a real pass — never a second, independently-tracked flag +(`COURSE_CONTENT_MODEL.md` §4). + +## What's a real, server-authoritative draw vs. fixed + +Every assessment's `random` pool is drawn fresh per attempt, server-side, at `POST /api/ +assessments/:id/start` — confirmed for ROOT 02's pool specifically in `e2e-phase6e.js` +("ROOT 02 assessment pool matches the documented design") and for the security assessment in +`e2e-phase6c.js` ("two independent students each get their own 9-scenario draw, and it is +server-authoritative"). `required` scenarios are always included, every attempt, for every +student — they are the non-negotiable floor of what "passing this course's assessment" means. + +## Coverage gaps and redundancy, evaluated honestly + +- **No assessment gap found** in the V1 required sequence: every required course (01-04, 09) has + one, sized to its content (30-60 min matching course depth), and none were added merely for + symmetry — `ROOT_PILOT_CURRICULUM.md`'s existing per-course rationale is unchanged this phase. +- **ROOT 05, 06, 07, 10, 12 have no formal timed assessment** — their real hands-on Labs plus the + Capstone's own scenario pool (drawn partly from workloads/configuration/troubleshooting + content) already exercise this material under timed, graded conditions at the end of the + program. Adding a redundant mid-program timed exam for each would test the same skill twice + without new instructional purpose — deliberately not built. +- **`rootnode-quick-assessment` and `rootnode-capstone` share scenario pools** with several + course-level Labs (by original Phase 1-5 design, unchanged) — this is intentional reuse + (`ROOT_CURRICULUM_COVERAGE_MATRIX.md`'s documented "scenario reused across activities" list), + not accidental duplication. diff --git a/docs/ROOT_V1_CURRICULUM_MANIFEST.md b/docs/ROOT_V1_CURRICULUM_MANIFEST.md new file mode 100644 index 0000000..ffb69e8 --- /dev/null +++ b/docs/ROOT_V1_CURRICULUM_MANIFEST.md @@ -0,0 +1,138 @@ +# ROOT_ V1 Curriculum Manifest + +Phase 6F — the canonical technical definition of what ROOT_ V1, the first sellable version of +the ROOT_ program, actually includes. Where this disagrees with an older doc (`ROOT_PILOT_ +CURRICULUM.md`, `ROOT_PROGRAM_ARCHITECTURE.md`), this document is the current source of truth; +those documents have been updated to point back here. + +## V1 course list + +| # | Course | In V1? | Status | Required? | Prerequisite(s) | Duration (38-40 activities/course avg) | +|---|---|---|---|---|---|---| +| 1 | Computing & Linux Foundations | Yes | READY | Required | — | 353 min (38 activities) | +| 2 | Linux Administration & Networking | Yes | READY | Required | ROOT 01 | 388 min (37) | +| 3 | Git & Collaborative Development | Yes | READY | Required | ROOT 02 | 312 min (31) | +| 4 | Containers & Docker | Yes | READY | Required | ROOT 03 | 444 min (43) | +| 5 | Kubernetes Foundations | Yes | READY | Required | ROOT 04 | 403 min (28) | +| 6 | Kubernetes Application Workloads | Yes | READY | Required | ROOT 05 | 299 min (23) | +| 7 | Kubernetes Networking & Configuration | Yes | READY | Required | ROOT 06 | 356 min (28) | +| 8 | Kubernetes Storage & Scheduling | **No** | PARTIAL | Excluded | — | 250 min (15) — excluded from V1 total | +| 9 | Kubernetes Security | Yes | READY | Required for Capstone | ROOT 06 | 745 min (40, includes CKS-depth optional labs) | +| 10 | Kubernetes Troubleshooting & Observability | Yes | READY | Required | ROOT 06 | 280 min (21) | +| 11 | DevOps & Platform Engineering (orientation) | Yes | PARTIAL (by design) | Optional bonus | ROOT 10 (non-gating) | 35 min (3) | +| 12 | RootNode Real Ops | Yes | READY | Required for Capstone | ROOT 10 | 115 min (6) | +| — | ROOT Capstone | Yes | READY | Terminal | ROOT 12 AND ROOT 09 | 120 min (5) | + +**ROOT_ V1 total: 3,850 minutes = 64.2 structured hours** (12 courses, excludes ROOT 08's 250 +min). Program-wide total including the excluded ROOT 08: 4,100 minutes = 68.3 hours. Full +per-module breakdown in `docs/ROOT_PROGRAM_DURATION_MODEL.md`. + +Every V1-included course's real per-module evidence (activity counts, lab list, assessment +wiring) lives in `docs/ROOT_FOUNDATIONS_PILOT_READINESS.md` (ROOT 01-04) and `docs/ +ROOT_CURRICULUM_COVERAGE_MATRIX.md` (ROOT 05-13). This manifest is the scope decision; those +documents are the evidence. + +## ROOT 08 — excluded from V1 (Step 2) + +ROOT 08 (Storage & Scheduling) exists with 2 PARTIAL modules (bare scenario banks, no lesson +scaffolding) but critically **is not required by anything downstream** — ROOT 09 and ROOT 10 +both branch directly off ROOT 06 by design (see `ROOT_PROGRAM_ARCHITECTURE.md`'s "deviations +from the suggested sequence"). Leaving it visible mid-sequence (course #8, between two READY +courses) would look to a self-paced student like a course they skipped, when V1 was never +designed to require it. + +**Mechanism**: `visibility = 'draft'` on the course and both its modules — the existing hard +gate (`COURSE_CONTENT_MODEL.md` §6), excluded from every student-facing query, still fully +visible/manageable for instructors. No content was deleted; this is reversible the moment ROOT +08 gets the same authoring pass ROOT 01-04 got. + +## ROOT 11 — included, repositioned as orientation-only bonus (Step 3) + +ROOT 11 has exactly one real, finished, self-paced-ready module (lesson + knowledge check + +reflection) bridging "systems administration" to "platform engineering thinking." The other six +designed modules (CI/CD, GitOps, IaC) require lab infrastructure not yet built and are +explicitly out of Phase 6F's scope (per the authorization's own DO-NOT-BUILD list). + +**Decision**: keep it in V1, but its course description was rewritten to say plainly that it is +a single orientation module, not a full DevOps course, and that the remaining six are designed +but not yet built. It stays `status = 'partial'` (honest) and `visibility = 'published'` +(real, finished content worth keeping visible). Nothing downstream requires it — a student who +skips it loses nothing gating-wise. + +## The three instructor-led-only practice banks (Step 4) + +`root-06-m01-deployments-and-workloads`, `root-07-m01-services-and-networking`, and +`root-10-m02-general-troubleshooting` were flagged in Phase 6E as instructor-led-only: bare +scenario banks with zero lesson/demonstration/knowledge-check framing. + +**Critical finding before any fix was applied**: these three modules' scenario_ids are not +generic supplemental practice — they are the *literal* content of the pre-existing +`scenarios/rootnode-path.json` "workloads"/"networking"/"troubleshooting" stages, the older, +separate mechanism that gates whether a student can even **start** the `rootnode-capstone` +assessment. An initial attempt to reclassify them `is_required = false` (making them optional +for course completion) was caught during this phase's own audit before being committed: it would +have let a self-paced student reach a course-tree-"complete" state while remaining silently, +confusingly blocked from the Capstone by the older stage gate. See `platform/api/migrations/ +030_phase6f_capstone_gate_correction.sql` for the full self-correction record. + +**Actual fix (Option A, not B)**: each module kept its activities `is_required = true` and +received one short intro-lesson activity (`*-a00-lab-bank-intro`) explaining what the bank is, +why it has no per-scenario teaching, and how to use it — the minimum real authoring needed to +be honestly self-paced-ready, not a reclassification. All three modules, and their parent +courses (ROOT 06, 07, 10), now genuinely earn `status = 'ready'`. + +## Course-level status audit correction (Step 0) + +Auditing `courses.status` against actual module-level status (not trusting prior phase reports) +found it had drifted stale for ROOT 05, 06, 07, 09, 10, 12, and Capstone — every module in each +had already reached real `ready` content, but the course-level field was never bumped. Corrected +in `029_phase6f_root_v1_integration.sql`; no new content was required for ROOT 05, 09, 12, or +Capstone (already fully authored), only for 06/07/10 (the practice-bank intro lessons above). + +## Capstone gate review (Step 7) + +Two separate, independent gates protect the Capstone: + +1. **The legacy stage-based gate** (`scenarios/rootnode-path.json`'s `unlock_rule`, checked by + `POST /api/assessments/rootnode-capstone/start`): six K8s scenario stages (foundation, + workloads, networking, configuration, troubleshooting, real-ops). **Left unchanged** this + phase — it has no natural "security stage" without new scenario-bank authoring, out of scope. +2. **The course-layer gate** (`courses.prerequisites` on `root-capstone`, checked by + `buildCourseTree()`): previously `{root-12-real-ops}` only. + +**Decision: strengthened.** `root-capstone.prerequisites` now also requires +`root-09-kubernetes-security`. Evidence: the Capstone's own scenario pool +(`assessment_definitions.pool_spec`) has zero overlap with the security assessment's CKS-style +pool — a student could pass the Capstone having never touched a security scenario. ROOT 09 only +reached genuine `ready` status this same phase, so requiring it any earlier would have gated on +unfinished content. ROOT 09 and ROOT 12 are already sibling courses (both prerequisite = ROOT +06), so this adds no new sequencing burden — either order, or in parallel. See `031_phase6f_ +capstone_security_prerequisite.sql`. + +## Program + Lab orientation (Steps 9-11) + +No orientation content existed anywhere before this phase (audited by grep across +`content/root`). Added `root-01-m00-welcome-to-root`, a new required front-door module — the +same pattern `root-05-m00` already established — with two lessons (program overview and Lab +lifecycle) and a knowledge check, sequenced before what was previously ROOT 01's first module. +See `032_phase6f_root_v1_orientation.sql`. + +## ROOT_ V1 curriculum version (Step 26) + +No second versioning system was built — this manifest reuses the existing per-row `version` +integer (`courses`/`course_modules`/`module_activities`), unchanged in convention from +`COURSE_CONTENT_MODEL.md` §6b. "ROOT_ V1" itself is a scope label (which course/module ids are +included, defined by this document), not a new database concept. What's frozen for a historical +enrollment is exactly what was already true pre-Phase-6F: a student's `activity_completions` +row stays valid across a later semantic edit to the same `activity_id`, keyed by the stable id, +not a snapshot. A future "V1.1" content correction follows the same rule `COURSE_CONTENT_MODEL.md` +§6b already documents — bump `version` on the changed row for a semantic edit, skip it for a +typo-only fix. A future V1 SCOPE change (adding/removing a course from the manifest) is a change +to this document plus a `visibility`/`prerequisites` migration, exactly like ROOT 08's exclusion +this phase — not a new mechanism to build. + +## What this manifest deliberately does not cover + +Pricing, registration, marketing copy, and camp scheduling are out of scope for this document — +see `docs/WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md` and `docs/ROOT_V1_INSTRUCTOR_LED_PILOT.md` +for delivery packaging, and Phase 7 for the business/product architecture layer. diff --git a/docs/ROOT_V1_INSTRUCTOR_GUIDE.md b/docs/ROOT_V1_INSTRUCTOR_GUIDE.md new file mode 100644 index 0000000..7a3e54b --- /dev/null +++ b/docs/ROOT_V1_INSTRUCTOR_GUIDE.md @@ -0,0 +1,111 @@ +# ROOT_ V1 Instructor Guide + +Phase 6F Step 12 — a practical guide for teaching ROOT_ V1. This does not duplicate any +individual module's own Instructor Notes (every lesson/lab content file ends with an +`## Instructor Notes` section — facilitation tips, timing, common mistakes); it covers what +spans the whole program instead. + +## Program overview & audience + +See `docs/ROOT_V1_SYLLABUS.md` for the full course sequence, outcomes, and duration. Audience is +approximately age 15+ through adults — readiness (comfort with a keyboard, following multi-step +instructions), not age, is the real gate. + +## Using CurriculumView + +The instructor curriculum view (`/admin`, Curriculum tab) shows every course/module/activity for +a given student or cohort with the exact same lock/completion state the student sees — plus +`instructor_notes` on every activity (never shown to students). Use it to see precisely where a +student is stuck before a help request even comes in. + +## Preparing Labs + +Use **Prepare Labs** (classroom/cohort view) to provision every enrolled student's disposable +Lab ahead of a session, rather than each student launching cold when class starts — this was +built and load-tested in Phase 2B and confirmed to run concurrently across a full cohort. + +## Classroom workflow + +1. Prepare Labs before the session starts. +2. Students work through the current module at their own pace; you see live progress per + student in the classroom view. +3. A student's **Need Help** request notifies you immediately with a category and message — + respond in whatever way your delivery format supports (in person, chat, screen share). +4. If a Lab environment itself seems broken for a student (not just the task being hard), an + instructor can reset it the same way a student can (Reset Scenario & Environment) — this + never touches the student's academic progress. +5. At the end of a session, cohort Labs can be destroyed in bulk (build/reprovision cost, not an + academic reset) — progress survives regardless (proven in Phase 2B/5B). + +## Self-paced vs. instructor-led + +The platform makes no code-level distinction between the two — the same courses, Labs, and +assessments work identically either way. The difference is entirely in who else is watching: +an instructor-led student additionally has a live instructor able to see their progress and +receive help requests. Timing/pacing guidance for instructor-led delivery lives in each +module's own Instructor Notes and in `docs/ROOT_V1_INSTRUCTOR_LED_PILOT.md`. + +## Assessments & Capstone + +Formal assessments (ROOT 01/02/03/04/09) and the Capstone are timed and hints-limited by design +— see `docs/ROOT_V1_ASSESSMENT_MAP.md`. Do not pre-brief students on the exact random-pool draw; +it's server-authoritative and drawn fresh per attempt specifically so this isn't possible to +game, and pre-briefing undermines what the assessment is actually checking. + +## Help-request workflow + +`Need Help` categories exist to help you triage at a glance (e.g. `lab_problem` vs. a conceptual +question) — treat a `lab_problem` report as potentially a real broken environment worth +checking yourself before assuming the student made an error. + +## Common student issues + +- **"My Lab disappeared / lost my work"** — expected if a Lab was recreated; see the student + Lab-orientation content (`root-01-m00-a02-lesson-disposable-lab`) and reassure them their + academic progress is untouched. +- **Confusing a module's optional activities for a blocker** — `is_required=false` activities + (e.g. ROOT 09's advanced CKS labs) never block module/course completion; the platform will + never require them, but some students assume more is mandatory than actually is. +- **Getting to ROOT 09/10/12 out of order** — real, server-enforced module prerequisites inside + a course (e.g. `root-06-m01`'s own practice bank requires `root-06-m02` first) sometimes + surprise a student used to free-form navigation; this is intentional sequencing, not a bug. + +## Lab reset/recreate — what it means + +Resetting a Lab rebuilds the disposable environment from scratch; recreating one (e.g. after a +Lab-host failure) does the same at the infrastructure level. Neither ever touches +`activity_completions`, `progress`, or `achievements` — a student's actual academic record. + +## What student progress actually means + +Course/module/activity `complete` flags are computed live, every time, from real underlying +facts (a real scenario pass, a real assessment pass, or an explicit manual marker for lesson-type +content) — never a separately-maintained flag that could silently drift from reality. See +`docs/COURSE_CONTENT_MODEL.md` §4. + +## What not to do + +- Don't manually flip a student's completion state via the admin API/database to "help them + along" — it breaks the guarantee that a complete flag reflects real work, and the Phase 6E + security fix means the platform will refuse a manual mark on a still-locked module anyway. +- Don't rely on the legacy `rootnode-quick-assessment` as a course-completion signal for any + V1 course — it's a general diagnostic tool, not wired to any course's own gate. +- Don't assume ROOT 08 or ROOT 11's un-built modules are "coming soon this cohort" — they're + explicitly out of V1 scope (see `docs/ROOT_V1_CURRICULUM_MANIFEST.md`); don't promise + timelines the curriculum doesn't yet support. + +## Security boundaries + +Every student's Lab is an isolated, disposable, non-privileged-to-the-host container — even +though it runs a real nested Docker Engine and a real k3s cluster inside itself. No student Lab +can reach another student's Lab, the Lab host's own Docker daemon, or any RootNode credential. +This is unchanged infrastructure from earlier phases (see `docs/LAB_ARCHITECTURE.md`, +`docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md`) — instructors do not need to configure anything for +this to hold. + +## Troubleshooting/operations notes + +If a whole cohort's Labs seem slow to provision, check Provisioner health before assuming a +content problem — this program's content changes never affect Lab boot performance (see +`docs/PHASE6F_ROOT_V1_PILOT_READINESS.md`'s resource observations for real numbers from this +phase's own rehearsals). diff --git a/docs/ROOT_V1_INSTRUCTOR_LED_PILOT.md b/docs/ROOT_V1_INSTRUCTOR_LED_PILOT.md new file mode 100644 index 0000000..24e3cf9 --- /dev/null +++ b/docs/ROOT_V1_INSTRUCTOR_LED_PILOT.md @@ -0,0 +1,40 @@ +# ROOT_ V1 Instructor-Led Pilot Plan + +Phase 6F Step 19. Realistic delivery packaging from the ACTUAL curriculum duration +(`docs/ROOT_PROGRAM_DURATION_MODEL.md`) — not a business/pricing decision, an +operational/academic one. + +## The three natural cohort groupings + +The real prerequisite chain (`docs/ROOT_V1_PREREQUISITE_MAP.md`) already divides ROOT_ V1 into +three coherent stretches, each a legitimate standalone cohort length: + +| Cohort | Courses | Duration | Suggested cadence | +|---|---|---|---| +| **Foundations** | ROOT 01-04 | 1,497 min ≈ 25.0 hrs | 8-10 weeks at 2.5-3 hrs/week, or a 1-week intensive | +| **Kubernetes Core** | ROOT 05-07, 10 | 1,338 min ≈ 22.3 hrs | 7-9 weeks, requires Foundations complete | +| **Operate & Secure** | ROOT 09, 12, Capstone | 980 min ≈ 16.3 hrs | 5-6 weeks, requires Kubernetes Core complete | + +**Full ROOT_ V1 pathway**: all three back to back, 64.2 hours total, realistically a +20-24 week (one semester-plus) commitment at a sustainable 3 hrs/week pace — not a single +short cohort. This mirrors how the content itself is sequenced (ROOT_PROGRAM_ARCHITECTURE.md's +own course graph), not an arbitrary split. + +## Weekend/intensive packaging + +Any single cohort above also works compressed into a multi-day intensive (e.g. Foundations as a +5-day, 5-hr/day intensive) — the content and Labs are identical; only pacing changes. This is +exactly the reasoning behind `docs/WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md`'s Option A, which is +the Foundations cohort's first half (ROOT 01-02) sized for a single week. + +## What doesn't change between formats + +Server-enforced prerequisites, Lab lifecycle, assessment integrity, and instructor tooling +(`docs/ROOT_V1_INSTRUCTOR_GUIDE.md`) are identical regardless of cadence — a cohort meeting +weekly for 9 weeks and one meeting daily for 5 days use the exact same platform mechanics. + +## What this document deliberately does not decide + +Price, enrollment minimums/maximums, marketing, and specific calendar dates — packaging +decisions belong to the people running a specific cohort, informed by real demand, not +prescribed here. diff --git a/docs/ROOT_V1_PREREQUISITE_MAP.md b/docs/ROOT_V1_PREREQUISITE_MAP.md new file mode 100644 index 0000000..2000b8b --- /dev/null +++ b/docs/ROOT_V1_PREREQUISITE_MAP.md @@ -0,0 +1,56 @@ +# ROOT_ V1 Prerequisite Map + +Phase 6F Step 6 — the full, real, server-enforced V1 prerequisite graph, generated from the live +`courses`/`course_modules` tables (not hand-drawn), and the QA performed against it. + +## Course-level graph + +``` +ROOT 01 → ROOT 02 → ROOT 03 → ROOT 04 → ROOT 05 → ROOT 06 ─┬─→ ROOT 07 + ├─→ ROOT 09 ─┐ + └─→ ROOT 10 ─┼─→ ROOT 12 → CAPSTONE + │ (also requires + ROOT 11 (bonus, │ ROOT 09 ─────┘ + non-gating, jointly) + after ROOT 10) + +ROOT 08 (Storage & Scheduling): excluded from V1 (visibility=draft). Its own prerequisite +(ROOT 07-m03) still resolves if ever re-included, but nothing in V1 depends on it. +``` + +CAPSTONE's real prerequisite array is `['root-12-real-ops', 'root-09-kubernetes-security']` — +both required, order-independent (see Step 7 decision in `ROOT_V1_CURRICULUM_MANIFEST.md`). + +## Module-level cross-course edge + +`root-09-m03-network-and-supplychain-security`'s prerequisites include +`root-07-m04-ingress-networkpolicy-foundations` (not just its own course's `root-09-m02`) — a +real, intentional cross-course module dependency (network policy concepts build on Ingress +concepts taught in ROOT 07). This is the one module-level edge that crosses a course boundary in +the V1 graph. + +## QA performed + +- **No cycles**: `infra/scripts/validate-course-content.js`'s cycle-detection pass (course-level + and module-level, run separately) — 0 errors, confirmed after every migration this phase. +- **No missing nodes**: every `prerequisites` array entry resolves to a real course/module id — + same validator, "every course/module prerequisite id resolves to a real course/module" check. +- **No excluded course blocking V1 progression**: ROOT 08 is referenced by nothing (audited by + grep across every course's and module's `prerequisites` array before excluding it) — its + `visibility=draft` change cannot silently lock anything downstream. +- **No hidden prerequisite through ROOT 08/11**: confirmed the same way — grepped for + `root-08` and `root-11-m01` inside every other course/module's `prerequisites` array; zero + hits in either direction. +- **Server-side enforcement**: `buildCourseTree()`'s `prerequisitesSatisfied()` is the single + computation both the student and instructor views read — proven end to end for the full ROOT + 01→02→03→04→05 chain in `e2e-phase6e.js` and for ROOT 06→09/10→12→Capstone in `e2e-phase6b.js` + and `e2e-phase6f.js` (Step 31). +- **Direct API cannot bypass**: `POST /api/student/activities/:id/complete` resolves the + activity's own course+module through the same `buildCourseTree()` and 403s if either is + locked (the Phase 6E fix) — re-verified this phase against the NEW root-capstone/root-09 + edge specifically (a direct attempt to mark a `root-capstone-m02` activity complete before + root-09 is done is rejected; see `e2e-phase6f.js`). +- **Optional activities never unexpectedly block progression**: `is_required=false` activities + are excluded from a module's/course's "required" set (`totals()`); confirmed for ROOT 09's + own optional CKS-advanced labs and ROOT 08's excluded (draft) content — neither can block a + V1 course from reaching `complete=true`. diff --git a/docs/ROOT_V1_STUDENT_REQUIREMENTS.md b/docs/ROOT_V1_STUDENT_REQUIREMENTS.md new file mode 100644 index 0000000..a9fc95e --- /dev/null +++ b/docs/ROOT_V1_STUDENT_REQUIREMENTS.md @@ -0,0 +1,38 @@ +# ROOT_ V1 Student Requirements + +Phase 6F Step 14. RootNode's Labs run remotely — nothing computationally heavy needs to happen +on a student's own device. + +## Remote / self-paced learners + +- **Browser**: any current Chromium-based browser (Chrome, Edge) or Firefox. No browser + extensions or plugins required. +- **Internet**: a stable broadband connection sufficient for a persistent web session and a + terminal-like interface (similar bandwidth needs to a video call, generally lower). +- **Device**: a laptop or desktop with a physical or usable on-screen keyboard. A + **Chromebook is sufficient** — all Lab computation happens on RootNode's infrastructure, not + the student's device. +- **Tablets/phones**: not recommended as a primary device — the terminal-and-multi-pane + interface assumes a real keyboard and a reasonably sized screen; nothing about it is + technically blocked on a tablet, but it will be an uncomfortable experience. +- **Local installation**: none. No Docker, no Kubernetes, no Git client needs to be installed + locally — every Lab (including the nested Docker Engine and the Kubernetes cluster from ROOT + 05 onward) runs in RootNode's disposable, remote Lab environment. +- **Microphone/camera**: not required by the platform itself. Only relevant if a specific + instructor-led delivery format (e.g. a live video cohort) separately requires it for its own + video conferencing — that's a delivery-format decision, not a platform requirement. + +## In-person / camp delivery + +- **RootNode provides**: the Lab environment (accessed via any device meeting the remote + requirements above), course content, and instructor tooling. +- **Student/venue provides**: the device itself (or the venue provides one), a keyboard, and + internet access to reach RootNode's platform. No specialized hardware, no local software + installation, no purchase requirements beyond program enrollment. +- **Venue/instructor should verify** in advance: enough physical outlets/devices for the + cohort size, and that the venue's network doesn't block outbound HTTPS to RootNode's domain. + +## What RootNode explicitly does NOT require + +No specific CPU/RAM/GPU spec, no paid software license, no local admin rights on the student's +device (nothing is installed), and no specific operating system beyond "runs a current browser." diff --git a/docs/ROOT_V1_SYLLABUS.md b/docs/ROOT_V1_SYLLABUS.md new file mode 100644 index 0000000..477461d --- /dev/null +++ b/docs/ROOT_V1_SYLLABUS.md @@ -0,0 +1,89 @@ +# ROOT_ V1 Syllabus + +## Program description + +ROOT_ is RootNode Academy's path from general computer literacy to operating and repairing real +infrastructure — Linux, Git, containers, and Kubernetes, taught through real hands-on Labs in a +disposable environment, culminating in a capstone that operates and recovers a production-like +system under realistic conditions. + +## Intended audience / readiness + +Approximately age 15 and up, through college students, adults, and career changers — including +help-desk technicians, junior sysadmins, developers, and anyone moving toward DevOps, cloud, or +platform engineering. Age is guidance, not a technical gate; readiness is what actually matters +(comfort with a keyboard and following multi-step instructions is the practical floor). + +## Prerequisites + +None external. ROOT_ does not require completing RootNode's INIT_ or COMPILE_ course families — +its own internal course sequence (below) is the only enforced prerequisite chain. + +## Learning outcomes + +By the end of ROOT_ V1, a student can: administer a Linux system and diagnose common failures; +use Git for real collaborative version control including merge conflicts; build, run, and +compose multi-container Docker applications; deploy, scale, and update workloads on a real +Kubernetes cluster; secure a cluster against common CKS-style findings; systematically +troubleshoot a broken system using a repeatable framework; and operate and recover a +production-like environment under a real incident. + +## Course sequence + +1. **Computing & Linux Foundations** — how a computer runs software, the shell, the filesystem, + files/text, processes, permissions. +2. **Linux Administration & Networking** — service lifecycle, storage/filesystem administration, + the networking mental model, network/DNS/HTTP diagnosis, structured troubleshooting. +3. **Git & Collaborative Development** — why version control exists, the Git mental model, + everyday Git, branching and real merge conflicts, remote repositories, engineering workflow. +4. **Containers & Docker** — why containers exist, images vs. containers, the Docker CLI, + container networking, container storage, Dockerfiles, Compose, and the bridge to Kubernetes. +5. **Kubernetes Foundations** — the Kubernetes mental model and core objects, Pods and kubectl. +6. **Kubernetes Application Workloads** — Deployments, scaling, rolling updates, Jobs/CronJobs. +7. **Kubernetes Networking & Configuration** — Services, service discovery, Ingress, + NetworkPolicy, ConfigMaps/Secrets. +8. **Kubernetes Security** — SecurityContext, ServiceAccounts/RBAC, network and supply-chain + security, cluster hardening — a formal CKS-style assessment, required before the Capstone. +9. **Kubernetes Troubleshooting & Observability** — health probes, the RootNode troubleshooting + framework, general operational troubleshooting. +10. **RootNode Real Ops** — real, deliberately un-guided incident response. +11. **ROOT Capstone: Operate and Recover a Production-Like Environment** — a graded, timed, + real-Lab final assessment combining every prior domain. + +*(ROOT 08 — Kubernetes Storage & Scheduling — and the deeper modules of ROOT 11 — DevOps & +Platform Engineering — are not part of ROOT_ V1; see `docs/ROOT_V1_CURRICULUM_MANIFEST.md`. A +single ROOT 11 orientation module is included as optional bonus content.)* + +## Assessments + +Four course-ending assessments (ROOT 01, 02, 03, 04) validate foundational competency; one +(ROOT 09) validates security competency and is required before the Capstone. See +`docs/ROOT_V1_ASSESSMENT_MAP.md` for exact scope and duration of each. + +## Capstone + +A 90-minute, real-Lab, graded final assessment. Requires ROOT 12 (Real Ops) and ROOT 09 +(Security) both complete, plus the pre-existing six-stage scenario gate (foundation, workloads, +networking, configuration, troubleshooting, real-ops). No new teaching — it tests what the +program already taught, under conditions closer to a real incident than a classroom exercise. + +## Approximate structured hours + +**64.2 hours** across the 12 V1 courses (excludes the deliberately-excluded ROOT 08). See +`docs/ROOT_PROGRAM_DURATION_MODEL.md` for the exact per-module breakdown this is built from. +This is instructional content time — it does not include instructor discussion, camp +activities, or self-paced review time, which vary by delivery format (see +`docs/ROOT_V1_INSTRUCTOR_LED_PILOT.md`). + +## Tools & technologies + +A real Linux shell, Git, Docker (via a safely nested Docker Engine inside each student's +disposable Lab, never touching the Lab host's own daemon), and a real single-node Kubernetes +cluster (k3s) — all provisioned automatically per student, with no local installation required. + +## Learning expectations + +Every module follows Learn → Practice → Lab → Troubleshoot → Validate (see `docs/ +PHASE6F_ROOT_V1_PILOT_READINESS.md`'s orientation content for the full explanation given to +students). Labs validate themselves — a student always knows, immediately and objectively, +whether a task actually passed. diff --git a/docs/WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md b/docs/WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md new file mode 100644 index 0000000..d1b91d6 --- /dev/null +++ b/docs/WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md @@ -0,0 +1,84 @@ +# Winter Break Camp — Curriculum Options + +Phase 6F Step 20. The question this document answers: **what subset of existing READY ROOT_ +curriculum makes an excellent, academically coherent, standalone Winter Break Camp** — not +"how do we fit all 64.2 hours into a week." + +## A real constraint that shapes every option below + +ROOT_'s course prerequisites are enforced server-side, for real, including against direct API +attempts (`docs/ROOT_V1_PREREQUISITE_MAP.md`). A camp curriculum cannot skip straight to, say, +Kubernetes for a brand-new student — ROOT 05 is genuinely locked behind ROOT 04, which is locked +behind ROOT 03, 02, and 01. Any option below that starts past ROOT 01 is explicitly scoped as a +**continuing-student** camp, not a walk-in-and-start one. This phase does not build a placement/ +waiver mechanism (out of scope, see the DO-NOT-BUILD list) — these options work within the real +chain as it exists today. + +## Option A — Linux & Systems Foundations Camp (recommended first camp) + +**Target readiness**: complete beginners; no prior RootNode enrollment needed. +**Age guidance (not a gate)**: ~13+ through adult. +**Content reused**: ROOT 01 (Computing & Linux Foundations) + ROOT 02 (Linux Administration & +Networking) — 100% existing READY content, zero new authoring. +**Duration**: 353 + 388 = 741 minutes ≈ **12.4 structured hours** — fits a 4-5 day week camp at +2.5-3 hours/day comfortably, with room for camp-format activities (breaks, group discussion) +around the core content. +**Hands-on Labs**: real Linux shell throughout — filesystem, processes, permissions, service +lifecycle, storage/network/DNS diagnosis, structured troubleshooting. +**Final mini-project/challenge**: the existing ROOT 02 assessment +(`rootnode-linux-networking-assessment`) already IS a real, timed, diagnose-and-fix challenge — +usable as the camp's own capstone moment with zero new content needed. +**Staffing**: one instructor can reasonably run this for a cohort using Prepare Labs + the +classroom Need-Help workflow (`docs/ROOT_V1_INSTRUCTOR_GUIDE.md`); no specialized TA skill +needed beyond basic Linux fluency. +**Delivery**: works in-person, fully remote, or hybrid — no format-specific content. + +## Option B — Containers & Kubernetes Starter Camp (continuing students) + +**Target readiness**: students who have already completed ROOT 01-03 (e.g., graduates of a +prior camp, or a self-paced student continuing over break). +**Age guidance**: ~14+ through adult. +**Content reused**: ROOT 04 (Containers & Docker) + ROOT 05 (Kubernetes Foundations) — 444 + 403 += 847 minutes ≈ **14.1 structured hours**. +**Hands-on Labs**: real nested Docker (build, run, network, persist, Compose) then a real +single-node Kubernetes cluster (Pods, kubectl fluency). +**Final mini-project/challenge**: the existing ROOT 04 assessment plus a self-contained "deploy +your own containerized app to the cluster" framing built from ROOT 05's existing Pod/kubectl +Labs — no new content needed. +**Staffing**: instructor should be comfortable with both Docker and basic kubectl. +**Delivery**: remote-friendly (no local Docker/Kubernetes install needed, per `docs/ +ROOT_V1_STUDENT_REQUIREMENTS.md`); works in-person too. +**Eligibility note**: market this explicitly as "Camp 2" or "for students who've done ROOT 01-03" +— do not advertise it as a standalone entry point, since a walk-in student would hit a real +locked course on day one. + +## Option C — Build, Break & Fix: Kubernetes Operations Camp (advanced continuing students) + +**Target readiness**: students who have completed ROOT 01-05 (e.g., graduates of Camps A+B). +**Age guidance**: ~15+ through adult. +**Content reused**: ROOT 06 (Application Workloads) + ROOT 07 (Networking & Configuration) + +ROOT 10 (Troubleshooting & Observability) — 299 + 356 + 280 = 935 minutes ≈ **15.6 structured +hours**. +**Hands-on Labs**: Deployments/scaling/rolling updates/Jobs/CronJobs, Services/Ingress/ +NetworkPolicy/ConfigMaps, then real diagnose-and-fix troubleshooting using the RootNode +framework. +**Final mini-project/challenge**: a real, deliberately-broken multi-symptom scenario drawing on +ROOT 10's existing troubleshooting Labs — genuinely operational, not a quiz. +**Staffing**: instructor should be comfortable diagnosing real Kubernetes failures live, since +students will hit genuine dead ends by design. +**Delivery**: remote-friendly; works well as a more intensive, fewer-day format (e.g. 3 full +days) given the deeper focus per topic. + +## Recommendation for THIS Winter Break + +**Option A** is the clear first camp: it needs no prior enrollment, needs zero new curriculum +authoring, fits a standard week-long camp format cleanly, and gives a complete, honest, +standalone learning arc (a real beginner walks in, and walks out having genuinely administered +and diagnosed a real Linux system). Options B and C are natural follow-on offerings for +returning students later in the year, once a first cohort exists to return. + +## Explicitly out of scope for this document + +Pricing, registration flow, payment processing, and marketing copy — this is curriculum +packaging only, per the Phase 6F authorization's own scope fence. See Phase 7 for the +business/product layer. diff --git a/platform/README.md b/platform/README.md index c09aea9..c3be3e0 100644 --- a/platform/README.md +++ b/platform/README.md @@ -95,6 +95,22 @@ further instructor accounts from the Instructors tab). prerequisite chains through the newly-inserted front-door modules, the optional-vs-required (`is_required`) completion rule, and the capstone server-side unlock fix in both directions (a direct bypass attempt rejected, a legitimately unlocked attempt still accepted). +- `test/e2e-phase6c.js` — curriculum completion upgrades, the security assessment bank, and + ROOT 11's honest lesson-only scope. +- `test/e2e-phase6d.js` — ROOT 01 (Computing & Linux Foundations) as the program's real front + door, and the real ROOT 01-04 foundational prerequisite chain. +- `test/e2e-phase6e.js` — ROOT 02/03/04 completion, the full ROOT 01->02->03->04->05 chain + proven via direct API, and the course/module lock-enforcement fix on the manual-completion + route. +- `test/e2e-phase6f.js` — the ROOT_ V1 curriculum manifest (inclusions/exclusions), the full V1 + prerequisite graph (no cycles, no missing nodes), the strengthened Capstone gate (ROOT 09 AND + ROOT 12 both required) in both directions, the new orientation module, and an explicit check + that no age/grade gate exists anywhere in enrollment. + +`infra/scripts/drills/` also holds real-Lab dress rehearsals per phase (Phase 6D/6E foundations, +Phase 6F's multi-student pilot and full end-to-end V1 journey) — see each script's own header +and `docs/PHASE6F_ROOT_V1_PILOT_READINESS.md` for what they prove beyond what the e2e suites +above already cover via direct API. All e2e suites need `OWNER_EMAIL` / `OWNER_PASSWORD` set to a real bootstrapped instructor account (see "Running the full stack locally" above) — the old `ADMIN_PASSWORD` mechanism is