ced4568andClaude Sonnet 5
87ad1251ce
Adds PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md (the phase's own record: what was authored, the dash-vs-bash scenario bug found and fixed, the pre-existing lock-enforcement gap found and fixed, the regression fallout that fix revealed in earlier suites and why each was a stale test assumption rather than a platform bug, and honest test/rehearsal/regression results). Updates ROOT_FOUNDATIONS_PILOT_READINESS.md (full re-audit: all 4 ROOT Foundations courses now READY, not inherited blindly from Phase 6D), ROOT_PROGRAM_DURATION_MODEL.md (real ROOT 02-04 duration data: 24.7 combined hours, landing inside Phase 6D's own estimated range; 67.9 hours across the full authored program), ROOT_PILOT_CURRICULUM.md (ROOT 02-04 move from NOT IN PILOT to IN PILOT with full module-level detail; the pilot is now genuinely self-paced-capable for the entire foundational half, not just instructor-led), ROOT_PROGRAM_ARCHITECTURE.md and ROOT_CURRICULUM_COVERAGE_MATRIX.md (course/module/scenario totals), and ROOT_FOUNDATIONS_ARCHITECTURE.md (marked as-built, not just as-designed). Co-Authored-By: Claude Sonnet 5 <[email protected]>
125 lines
10 KiB
Markdown
125 lines
10 KiB
Markdown
# 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 | **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`. |
|
|
|
|
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.
|
|
|
|
## 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.
|