diff --git a/docs/ROOT_PROGRAM_ARCHITECTURE.md b/docs/ROOT_PROGRAM_ARCHITECTURE.md new file mode 100644 index 0000000..7a3cb1d --- /dev/null +++ b/docs/ROOT_PROGRAM_ARCHITECTURE.md @@ -0,0 +1,104 @@ +# 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 `programs` table, 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.