# 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. **Updated for Phase 6B** (`platform/api/migrations/023_phase6b_curriculum.sql`, `docs/PHASE6B_ROOT_CURRICULUM_EXPANSION.md`): ROOT 08 and 09 moved from PLANNED to PARTIAL, and 6 courses gained new teaching modules — the module-level detail and evidence for every new placement lives in `docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md`, not duplicated here. **Updated for Phase 6D** (`platform/api/migrations/025_phase6d_root_foundations_root01.sql`, `docs/PHASE6D_ROOT_FOUNDATIONS.md`): ROOT 01 fully authored and moved to READY — see `docs/ROOT_FOUNDATIONS_ARCHITECTURE.md` for its module-level design and `docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md` for why no new activity type was needed. ROOT 02-04 remain PLANNED (architecture designed, content not yet authored) but now carry a real prerequisite chain (01→02→03→04→05) enforced server-side. ## Course sequence | # | Course | Status | Why | |---|---|---|---| | 1 | Computing & Linux Foundations | **READY** | Phase 6D: 6 modules, real Linux/shell scenarios using the existing generic scenario engine, a wired assessment — see `docs/PHASE6D_ROOT_FOUNDATIONS.md`. | | 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 | **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 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 ``` **Updated for Phase 6D:** 01→02→03→04→05 became a real, server-side prerequisite chain (`courses.prerequisites`). At that point ROOT 01 was real content and 02-04 remained PLANNED, so ROOT 02 was the only course the chain actually locked; 03/04/05 stayed vacuously satisfied until their own prerequisite course was authored — see `docs/COURSE_CONTENT_MODEL.md`'s "prerequisite/locking rule" for why a PLANNED/content-free prerequisite never actually blocks anything. **Updated for Phase 6E** (`docs/PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md`): ROOT 02, 03, and 04 are now real, authored, READY courses — the ENTIRE 01→02→03→04→05 chain now genuinely gates for a real student, verified live on both a fully-completed student and a fresh one. A pre-existing 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 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.