docs(phase6f): document ROOT_ V1 pilot readiness
New: PHASE6F_ROOT_V1_PILOT_READINESS.md (phase summary), ROOT_V1_CURRICULUM_MANIFEST.md (canonical V1 scope), 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. Updated: ROOT_PROGRAM_ARCHITECTURE.md (course-sequence table reflects real V1 statuses), ROOT_PILOT_CURRICULUM.md (self-paced-readiness correction), ROOT_PROGRAM_DURATION_MODEL.md (real post-integration totals: 64.2 V1 hours / 68.3 program-wide), ROOT_CAPSTONE_READINESS.md (§1b, the new root-09 course-layer gate), platform/README.md (test list). Co-Authored-By: Claude Sonnet 5 <[email protected]>
This commit is contained in:
Claude Sonnet 5
@@ -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.
|
||||
@@ -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
|
||||
|
||||
@@ -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)
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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).
|
||||
@@ -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.
|
||||
@@ -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`.
|
||||
@@ -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."
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user