13 courses (ROOT 01-12 + Capstone) under the existing single root-kubernetes-foundations program — root_ is one continuous ladder a student enrolls in once, not thirteen separate purchases. Honest READY/PARTIAL/PLANNED states grounded in the actual inventory: no course reaches READY yet, 5 are fully PLANNED (no Linux/Git/Docker/DevOps scenario content exists anywhere in this repo), 7 are PARTIAL (real labs, no lessons yet). Documents the prerequisite graph and why it deviates from a strictly linear 01->12 chain where the existing content doesn't actually support one. Co-Authored-By: Claude Sonnet 5 <[email protected]>
8.1 KiB
ROOT_ Program Architecture
Phase 6A §2 — the canonical course architecture for root_ (Linux → systems → containers →
Kubernetes → DevOps/platform engineering, ages ~15-18+/college/adult per the youth ladder — see
docs/PHASE6A_ROOT_COURSE_FOUNDATION.md §1). This document is the design; the actual seed data
lives in platform/api/migrations/022_course_content.sql, generated to match this exactly.
All 13 rows below are courses under the ONE existing program, root-kubernetes-foundations
(programs table, unchanged — see §"why one program, not thirteen" below). Every status claim
here is grounded in docs/ROOT_CURRICULUM_INVENTORY.md, not aspirational.
Course sequence
| # | Course | Status | Why |
|---|---|---|---|
| 1 | Computing & Linux Foundations | PLANNED | No lab content exists in this repository — every scenario is Kubernetes/CKS. |
| 2 | Linux Administration & Networking | PLANNED | Same — no Linux-admin scenario content exists. |
| 3 | Git & Collaborative Development | PLANNED | No Git scenario content exists. |
| 4 | Containers & Docker | PLANNED | No Docker-specific scenario content exists (the Lab itself runs k3s, but no student-facing "learn Docker" scenarios exist). |
| 5 | Kubernetes Foundations | PARTIAL | Real content: the existing "Foundation" stage's 20 scenarios, wrapped as one module (root-05-m01-pods-and-kubectl-basics). No teaching lesson content authored yet — bare labs only. |
| 6 | Kubernetes Application Workloads | PARTIAL | The existing "Workloads" stage's 8 scenarios, one module. Bare labs only. |
| 7 | Kubernetes Networking & Configuration | PARTIAL | The existing "Networking" (2) and "Configuration" (5) stages, two modules. Bare labs only. |
| 8 | Kubernetes Storage & Scheduling | PLANNED | Real scenario content exists (PV/PVC, StorageClass, taints/tolerations, PDB — see inventory §5) but is not yet wired into a module. Deliberately left PLANNED rather than fabricating a module shell with no honest content behind it — Phase 6B. |
| 9 | Kubernetes Security | PLANNED | A substantial 22-scenario CKS-style bank exists (RBAC, PSA, network policy, supply chain, runtime hardening) but is not yet wired into a module — Phase 6B. |
| 10 | Kubernetes Troubleshooting & Observability | PARTIAL | Contains the Phase 6A gold-standard module (READY) plus the existing "Troubleshooting" stage's remaining 5 scenarios as a second, bare-lab module. |
| 11 | DevOps & Platform Engineering Foundations | PLANNED | No CI/CD/IaC/GitOps scenario content exists anywhere in this repository. |
| 12 | RootNode Real Ops | PARTIAL | The existing "RootNode: Real Ops" stage's 4 scenarios (3 RootNode-authored + 1 generic), one module. Bare labs, no teaching content — the gold module already gives one of these four (rootnode-probe-port-mismatch) a full teaching treatment elsewhere; this module exercises it again alongside the other three, deliberately (see module notes below). |
| 13 | ROOT Capstone — Operate and Recover a Production-Like Environment | PARTIAL | The existing, fully working rootnode-capstone assessment (90 min, mixed required/random pool). No capstone orientation/briefing lesson authored yet. |
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 one complete module (the gold standard) as the authoring template, not a finished curriculum.
Prerequisite chain
01 Linux Foundations → 02 Linux Admin/Networking → 03 Git → 04 Containers/Docker
│
▼
05 Kubernetes Foundations
│
▼
06 Application Workloads
│ │
┌─────────────────────┤ │
▼ ▼ ▼
07 Networking/Config 09 Security 10 Troubleshooting
│ │ │
▼ │ ▼
08 Storage/Scheduling │ 11 DevOps/Platform
▼
12 RootNode Real Ops
│
▼
CAPSTONE — Operate & Recover
01-04 have no prerequisite chain enforced against each other yet (all PLANNED, zero content —
locking a PLANNED course behind another PLANNED course would just be decorative). 05 is the
first course with a real prerequisite gate. See docs/COURSE_CONTENT_MODEL.md's "prerequisite/
locking rule" for why a PLANNED/content-free prerequisite never actually blocks anything.
Deviations from the spec's suggested sequence, and why
The authorization's suggested sequence listed Security (09) after Storage/Scheduling (08) and before Troubleshooting (10). This document keeps that numbering for continuity, but the prerequisite graph branches 09 and 10 both directly off 06 (Application Workloads) rather than chaining 08→09→10 linearly — the existing content doesn't actually build 09 on top of 08's concepts (RBAC/PSA/network-policy security content is orthogonal to PV/PVC/scheduling content), so a straight linear chain would impose a false dependency. This is exactly the case the authorization's "if existing content suggests a better grouping, document the reasoning" line anticipated.
Real Ops and Capstone placement
Real Ops (12) sits after Troubleshooting (10), matching the existing curriculum's own stage
order (rootnode-path.json's real-ops stage already comes after troubleshooting) — Real Ops
scenarios assume the diagnostic skills Troubleshooting teaches. The Capstone sits after Real Ops
alone, not after every course, because that's what the existing rootnode-capstone assessment
definition's own unlock_rule already requires (all 6 content stages of rootnode-path.json
complete — which necessarily includes 05-06-07-10-12's underlying scenarios, plus networking/
configuration). 08, 09, and 11 are not currently gating the capstone, because their scenario
content isn't part of rootnode-path.json's stage list at all yet — see
docs/COURSE_CONTENT_MODEL.md for how course-level completion is computed independently of that
assessment-engine unlock_rule (the two systems currently agree by construction, not by a shared
implementation).
Why one program, not thirteen
programs (Phase 5B) models the commercial/academic unit a student enrolls in. root_ is
described by this authorization as one continuous ladder — "Linux → systems → containers →
Kubernetes → DevOps/platform engineering" — not thirteen separate purchases. Attaching all 13
courses to the single existing root-kubernetes-foundations program means:
- Zero changes to the
programstable, enrollment model, or entitlement logic — an enrolled student automatically has structured access to the whole ladder as it's built out. - No renaming/redefinition of the existing program (which would risk a real, if cosmetic, break for anyone already enrolled) — see Phase 6A's explicit "do not redesign working systems" constraint.
If a future phase needs root_ split into separately-purchasable programs (e.g. "Kubernetes
Foundations" sold standalone from "DevOps"), that's a programs-table decision to make
deliberately later, informed by real pricing/business requirements — not something to guess at
here.