From bd0a10fbfb31b05a6264d083f27d85a6f7d5d50c Mon Sep 17 00:00:00 2001 From: ced4568 Date: Wed, 26 Aug 2026 11:21:09 -0500 Subject: [PATCH] docs(phase6c): pilot readiness standard, pilot curriculum manifest, ROOT 11 scope MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds the four required Phase 6C documents: - ROOT_PILOT_READINESS_STANDARD.md — the explicit 8-point sufficiency bar used to judge every module this phase, replacing any fixed activity-count assumption. - ROOT11_DEVOPS_PLATFORM_SCOPE.md — evaluates all 7 proposed ROOT 11 modules individually (READY TO AUTHOR NOW / PARTIAL-LESSON-ONLY / REQUIRES FUTURE LAB ENVIRONMENT), with what current infra supports vs. what GitOps/CI-CD/ IaC/observability would each require. - ROOT_PILOT_CURRICULUM.md — the authoritative pilot manifest: instructor-led as the first pilot's delivery mode, honest READY/PARTIAL/DEFERRED/NOT IN PILOT status per course and module, and what is intentionally excluded (ROOT 01-04 never authored, ROOT 08 non-capstone-gating and deferred, ROOT 11 modules 2-7, three practice-bank modules instructor-led-only this pilot). - PHASE6C_CURRICULUM_COMPLETION.md — the phase's own record of what was upgraded, why, the bug found and fixed, and the pilot readiness conclusion. Updates ROOT_CURRICULUM_COVERAGE_MATRIX.md with the verified before/after module counts (21->22 modules, 6->16 READY) and per-module upgrade rationale, and ROOT_CAPSTONE_READINESS.md with a re-review confirming the unlock gate's 6 stages, and ROOT 08/09's non-gating status, are unchanged by this phase's curriculum expansion. Co-Authored-By: Claude Sonnet 5 --- docs/PHASE6C_CURRICULUM_COMPLETION.md | 150 ++++++++++++++++++++++++ docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md | 64 ++++++++++ docs/ROOT_CAPSTONE_READINESS.md | 26 ++++ docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md | 51 +++++++- docs/ROOT_PILOT_CURRICULUM.md | 118 +++++++++++++++++++ docs/ROOT_PILOT_READINESS_STANDARD.md | 83 +++++++++++++ 6 files changed, 488 insertions(+), 4 deletions(-) create mode 100644 docs/PHASE6C_CURRICULUM_COMPLETION.md create mode 100644 docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md create mode 100644 docs/ROOT_PILOT_CURRICULUM.md create mode 100644 docs/ROOT_PILOT_READINESS_STANDARD.md diff --git a/docs/PHASE6C_CURRICULUM_COMPLETION.md b/docs/PHASE6C_CURRICULUM_COMPLETION.md new file mode 100644 index 0000000..e6a0ad7 --- /dev/null +++ b/docs/PHASE6C_CURRICULUM_COMPLETION.md @@ -0,0 +1,150 @@ +# Phase 6C — Curriculum Completion + Assessment Bank + ROOT 11 Scope + +Phase 6C's mission: upgrade PARTIAL modules toward the gold-module standard, build a real +assessment bank from previously-unwired content, resolve ROOT 11's scope, and produce an +explicit, honest pilot-ready determination. This document records what was actually done and +why, using the existing content/assessment model throughout — no new application code was +required. + +## Baseline verification + +Confirmed at start: branch `main`, clean tree, HEAD = `origin/main` = +`2db136875f30809afa9c82f36e96605802bf7ee2`, descending from the Phase 6B milestone +(`git merge-base --is-ancestor`, confirmed). Phase 6B's own final report claimed 17 PARTIAL +modules; a direct database query showed the real figure was 15 out of 21 total modules — this +correction is recorded in `docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md`. + +## Readiness standard + +`docs/ROOT_PILOT_READINESS_STANDARD.md` defines READY as sufficiency, not a fixed activity +count: enough instruction/scaffolding that a student can reasonably perform the practical work, +checked against an 8-point standard (concept instruction, demonstrated reasoning, self-check, +guided bridge, operational-context closing, instructor notes, self-paced sufficiency, resolved +references). Modules were checked against this bar individually, not mechanically padded to six +activities each. + +## Modules upgraded (15 PARTIAL → 6 PARTIAL, 16 READY) + +**Full gold-pattern upgrades** (lesson/demonstration/knowledge-check/guided-exercise/lab(s)/ +reflection), each with new content authored and existing lab activities preserved and only +resequenced: +- `root-06-m03-jobs-cronjobs-daemonsets` +- `root-07-m04-ingress-networkpolicy-foundations` +- `root-07-m02-configuration-and-secrets` (converted in place from a bare 5-lab bank — the last + networking/config module with no front-door teaching) +- `root-09-m02-serviceaccounts-and-rbac` +- `root-09-m03-network-and-supplychain-security` +- `root-10-m03-troubleshooting-framework` (only guided-exercise + reflection were missing) + +**Bookend-only upgrade** (lesson + reflection wrapped around an existing, otherwise-complete +practice bank, rather than a full six-part redesign — because the gap was framing, not +per-task teaching): +- `root-05-m01-pods-and-kubectl-basics` — 20 independent kubectl-fluency tasks, each already + carrying its own explanation in its scenario description. Added a short lesson explaining why + the module is structured as breadth practice, and a reflection asking students to name their + own remaining gaps. + +**Documented exceptions** (status promoted to READY with no new activities, because adding the +"missing" activity type would have actively undermined the module's intentional design): +- `root-12-m01-real-ops-incidents` — adding a knowledge-check or guided-exercise would + contradict its deliberate "you are responsible for this environment" unguided design. +- `root-capstone-m01-operate-and-recover` — its single `capstone` activity IS the terminal + exam; the readiness/prep teaching already lives in the preceding, already-READY + `root-capstone-m02-capstone-readiness`. +- `root-09-m04-cluster-hardening-and-runtime` — Phase 6B already documented this as + intentionally survey-depth ("not core, not daily-driver"); it now has a lesson, hands-on + labs, and a real assessment checkpoint (below), which is sufficient for its scope without + forcing a demonstration/guided-exercise pattern that would misrepresent it as core content. + +**Intentionally deferred, not upgraded this phase:** +- `root-08-m01-storage-fundamentals`, `root-08-m02-scheduling-resource-governance` — ROOT 08 + does not gate the capstone (the `rootnode-path.json` unlock stages are foundation, workloads, + networking, configuration, troubleshooting, real-ops; storage/scheduling was never one of + them). Given realistic effort constraints, these were prioritized below the + capstone-critical path and below the security-assessment mandate. Left PARTIAL, classified + DEFERRED/optional-supplementary in the pilot manifest. +- `root-06-m01-deployments-and-workloads`, `root-07-m01-services-and-networking`, + `root-10-m02-general-troubleshooting` — dense hands-on practice banks that sit alongside an + already-fully-taught sibling module in the same course (root-06-m02, root-07-m03/m04, + root-10-m01/m03). Rather than author three more full teaching layers under time constraints, + classified as instructor-led-only for the first pilot (an instructor supplies the missing + framing live); fully self-paced delivery of exactly these three is deferred. See + `docs/ROOT_PILOT_CURRICULUM.md`. + +## Content authored this phase + +20 new Markdown content files (demonstrations, guided exercises, knowledge checks, lessons, +reflections) across ROOT 05, 06, 07, 09, 10, and 11 — each following the established +`## Instructor Notes` convention (instructor-only content below that heading, stripped from +student-visible payload by `content.js`'s existing `splitContent()`). Every demonstration +follows OBSERVE → HYPOTHESIS → INSPECT → CHANGE → VERIFY; every guided exercise bridges lesson +to lab without revealing the lab's exact answer; every knowledge check tests reasoning over +recall; every reflection closes with a named, transferable engineering principle. + +## Assessment bank (Section 9) + +New `assessment_definitions` row `rootnode-security-assessment` (type `exam`, 60 minutes, +`hint_policy: disabled`), using the existing Phase 3B assessment engine unmodified. Pool: 3 +required hands-on CORE security scenarios (`cks-pod-security-context`, `cks-rbac-least-privilege`, +`cks-network-policy`) plus 4 random-draw groups covering SecurityContext hardening depth, +RBAC/ServiceAccount depth, network/supply-chain depth, and the 7 previously-unwired CKS MCQs as +one pool — 9 scenarios drawn per attempt, server-authoritative (verified live: a real student +session draw returned 9 scenario IDs matching the pool spec, no client input accepted). Wired +into `root-09-m04-cluster-hardening-and-runtime` as an `assessment`-type activity — the natural +home for a security checkpoint, not a new module. + +## Remaining unwired scenarios (Section 13) + +Recomputed after the security-assessment wiring consumed the 7 previously-unwired CKS MCQs: +**2 scenarios remain unwired** — `cluster-upgrade-mcq` and `etcd-backup-mcq`, both Cluster +Administration/CKA-track content (kubeadm upgrade order, etcd backup/restore). No current ROOT +module teaches cluster administration at that level; classified **future-curriculum**, not +neglect. One scenario that WAS unwired, `readiness-probe-task` (a constructive "author a +readiness probe" Lab, distinct from the existing diagnostic `rootnode-probe-port-mismatch` +Lab), was wired as an **optional practice** activity in `root-10-m01-health-probes-and-troubleshooting` +using the existing `is_required` model from Phase 6B — no second practice system built. + +## ROOT 11 (Section 11-12) + +`docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md` evaluates all 7 proposed modules individually. Only one +was authored (`root-11-m01-devops-platform-thinking`, folding in the closely-related "Platform +Engineering & DX" idea) — a lesson, knowledge check, and reflection, explicitly telling +students which future topics (GitOps, CI/CD, IaC, observability) require infrastructure this +platform doesn't yet provide. No fake labs were built. ROOT 11 moved from `planned` to +`partial` at the course level — an intentional, documented scope, not an unexplained +placeholder. + +## New application code + +None. Every genuine gap this phase was satisfiable with existing tables (`course_modules`, +`module_activities`, `assessment_definitions`) and the existing content-delivery pipeline. One +real bug was found and fixed during authoring (see below) but required no schema or API change. + +## Bug found and fixed + +An early draft of migration 024 set `root-11-m01-devops-platform-thinking`'s +`course_modules.prerequisites` to a COURSE id (`root-10-kubernetes-troubleshooting-observability`) +instead of a MODULE id — `course_modules.prerequisites` and `courses.prerequisites` are +different namespaces. Caught by actually running `infra/scripts/validate-course-content.js` +against the rebuilt database (`FAIL — module root-11-m01-devops-platform-thinking lists a +prerequisite that doesn't exist`). Verified via direct query that the course-level gate was +already correctly set from Phase 6A's migration 022. Fixed by emptying the module-level field +(the course-level gate already fully enforces the dependency) and documenting why in the +migration's SQL comments. + +## Content validation (Section 24) + +`infra/scripts/validate-course-content.js` (new, permanent) checks: no duplicate course/module/ +activity ids; no orphan modules/activities; every scenario_id and assessment_definition_id +resolves to a real row/file; every prerequisite id resolves and contains no cycles; no sequence +collisions; instructor notes never leak into student-visible content (verified by actually +invoking `content.js`'s real `loadContent()`); every content_path resolves to a real file. Final +run: **22 courses/modules loaded, 163 activities, 98 scenario files, 0 errors.** + +## Pilot readiness determination + +See `docs/ROOT_PILOT_CURRICULUM.md` for the full manifest. Every module in the pilot's required +completion path (ROOT 05-07, 09-10, 12, Capstone) meets the READY bar for instructor-led +delivery; three specific practice-bank modules are instructor-led-only this pilot; ROOT 08 and +ROOT 11 modules 2-7 are explicitly outside the required path. The first pilot is scoped as +instructor-led, and within that scope, the curriculum is ready. diff --git a/docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md b/docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md new file mode 100644 index 0000000..e6da2a0 --- /dev/null +++ b/docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md @@ -0,0 +1,64 @@ +# ROOT 11 — DevOps & Platform Engineering: Scope Decision + +Phase 6C's mandate for ROOT 11 was to stop it being an undefined `planned` placeholder by +making an explicit, evidence-based scope decision — not to fake seven hands-on labs the current +platform cannot honestly deliver. This document is that decision. + +## Purpose and learning outcomes + +ROOT 11 exists to give a student who has just finished ROOT 05-10 (Kubernetes hands-on) and +ROOT 12 (incident response) the vocabulary and mental model to see their skills as part of a +larger DevOps/platform engineering practice, and an honest map of what comes next once the +platform can support it hands-on. It is explicitly NOT meant to teach GitOps, CI/CD, or +Infrastructure as Code as hands-on skills in this phase. + +## The seven proposed modules, evaluated against current architecture + +| # | Proposed module | Classification | Why | +|---|---|---|---| +| 1 | Sysadmin → Platform Thinking | **READY TO AUTHOR NOW** | Pure orientation/reframing content. No new infrastructure needed — it's built entirely on ROOT_'s existing curriculum, referenced explicitly. Authored this phase as `root-11-m01-devops-platform-thinking`. | +| 2 | GitOps & Declarative Delivery | **REQUIRES FUTURE LAB ENVIRONMENT** | Needs a Git repository the student can push to and a deployment-automation controller (ArgoCD or Flux) watching it. The Lab platform provisions an isolated k3s VM per student today; it does not provision or wire a Git remote or a GitOps controller. Faking this with a Kubernetes-only scenario would teach "apply a manifest," not GitOps — a materially wrong mental model. | +| 3 | CI/CD Fundamentals | **REQUIRES FUTURE LAB ENVIRONMENT** | Needs a CI runner (even a minimal one) that can check out code, run a pipeline, and produce an artifact or trigger a deploy. No such runner exists in the Lab image or Platform API today. | +| 4 | Infrastructure as Code | **REQUIRES FUTURE LAB ENVIRONMENT** | Needs a provisioning target and a tool like Terraform/OpenTofu applying against it. Kubernetes objects are already declarative, but IaC's actual lesson is about provisioning infrastructure *below* Kubernetes — cloud resources, networking, the cluster itself — which this platform doesn't expose to a student sandbox. | +| 5 | Observability & SLO Thinking | **PARTIAL-LESSON-ONLY** | The conceptual half (what SLIs/SLOs are, error budgets, why "is the Pod Running" isn't observability) can be taught honestly without a metrics stack. A genuinely hands-on version needs Prometheus/Grafana (or equivalent) wired into the Lab VM, which doesn't exist today. Recommend authoring the lesson-only half in a future sub-phase; do not build the metrics stack this phase. | +| 6 | Platform Engineering & DX | **READY TO AUTHOR NOW** (folded into module 1) | Conceptually adjacent enough to module 1 that a separate module would duplicate content. Its core ideas (self-service, golden paths, reducing cognitive load) are already covered in `root-11-m01`. | +| 7 | Reliability / Automation / Operational Ownership | **PARTIAL-LESSON-ONLY** | Largely already covered hands-on by ROOT 12 (Real Ops incidents) and ROOT 10 (troubleshooting framework). A short lesson connecting those two courses' skills explicitly to "reliability engineering" as a named discipline is legitimate future content; a new hands-on lab would duplicate ROOT 12 rather than teach something new. | + +## What was actually authored this phase + +Only module 1 (folded with module 6's ideas) — `root-11-m01-devops-platform-thinking` — a +lesson, knowledge check, and reflection. No Lab activity exists for ROOT 11 and none was +faked. The lesson explicitly tells students which future topics (GitOps, CI/CD, IaC, +observability) require infrastructure this course doesn't yet provide, rather than staying +silent about the gap. + +## What current infrastructure supports vs. what future modules need + +**Supports today:** Kubernetes/k3s hands-on labs via the existing Lab VM provisioning +(Platform API → Provisioner → Lab Router), the existing assessment engine, and the existing +content/course model — sufficient for orientation and conceptual lesson content referencing +Kubernetes skills already taught. + +**Would need building for modules 2-4, and the hands-on half of 5 and 7 (future phases, +NOT this phase):** +- A Git hosting target reachable from a student's Lab VM, plus a GitOps controller + (ArgoCD/Flux) pre-installed or installable in that VM. +- A minimal CI runner (self-hosted GitHub Actions runner, Drone, or similar) wired to a + student-scoped repository. +- A provisioning target IaC tooling can act against — even a scoped-down one (e.g., Terraform + against a mock/local provider) — plus the tooling itself in the Lab image. +- A metrics/logging stack (Prometheus + Grafana at minimum) installed per-Lab-VM or shared with + per-student scoping, for the hands-on half of Observability. + +None of this was built in Phase 6C, per its explicit "do NOT build" list (Section 26). + +## Pilot inclusion recommendation + +Include `root-11-m01-devops-platform-thinking` in the first pilot as a **closing orientation +module** — no hands-on requirement, explicitly scoped as conceptual. Do not present ROOT 11 as +a complete course in pilot marketing or instructor materials; present it as "orientation now, +hands-on modules 2-7 in a future phase once the required lab environments exist." This keeps +the pilot honest about what ROOT 11 currently is versus what it will become. + +See [`docs/ROOT_PILOT_CURRICULUM.md`](ROOT_PILOT_CURRICULUM.md) for how this fits the overall +pilot manifest. diff --git a/docs/ROOT_CAPSTONE_READINESS.md b/docs/ROOT_CAPSTONE_READINESS.md index d4b97b2..22dba5e 100644 --- a/docs/ROOT_CAPSTONE_READINESS.md +++ b/docs/ROOT_CAPSTONE_READINESS.md @@ -85,3 +85,29 @@ gap was also found and fixed in `e2e-phase5b.js`'s own capstone-completion test, included the `real-ops` stage in its completion loop — it was passing only because the very bug this phase fixes let an incomplete curriculum still start the capstone. See that test file's own comment for detail. + +## 5. Phase 6C re-review against the expanded curriculum + +Re-checked every item this doc depends on against Phase 6C's changes and found no gap requiring +a fix: + +- **The unlock gate's 6 stages are unchanged**: Foundation, Workloads, Networking, + Configuration, Troubleshooting, Real Ops (`rootnode-path.json`). Phase 6C added and upgraded + modules within those stages' courses (ROOT 05-07, 10) plus ROOT 09 (Security) and the new + ROOT 11 orientation — **ROOT 08 (Storage & Scheduling) and ROOT 09 (Security) do not appear + among the 6 gating stages and still do not gate the capstone.** This is documented + architecture, not an oversight — confirmed by direct test + (`platform/test/e2e-phase6c.js`, "the capstone unlock gate is unaffected by ROOT 09 (security) + being incomplete") rather than assumed. +- **`root-capstone-m01-operate-and-recover`** was promoted from `partial` to `ready` this phase + as a documented exception (no activity added — its single `capstone` activity IS the exam; + see `docs/PHASE6C_CURRICULUM_COMPLETION.md`). This changes only its content-model status + label, not the real unlock gate described in §3-4 above, which remains entirely independent. +- **Random draw pools, timing, hint policy, and completion rule** for `rootnode-capstone` itself + were not touched by Phase 6C — no scenario content this phase added or changed feeds that + pool. +- **The Capstone Readiness module (§1)** required no changes — its 4 activities and their + relationship to the (still unchanged) real unlock gate remain accurate as described above. + +No redesign was made or needed; Phase 6C's curriculum expansion did not require reopening the +capstone engine. diff --git a/docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md b/docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md index 8c91b7e..4568eef 100644 --- a/docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md +++ b/docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md @@ -2,10 +2,53 @@ Phase 6B §1 — maps every scenario Phase 6B puts to structured use, with an intentional reason for each placement (not coverage-percentage padding). Built from -`docs/ROOT_CURRICULUM_INVENTORY.md`'s evidence. Statuses: **READY** (a student can actually -learn from it end to end — see `docs/COURSE_AUTHORING_STANDARD.md`'s bar), **PARTIAL** (real -lesson + labs, missing one or more of demonstration/knowledge-check/guided-exercise), **PLANNED** -(structure only, no content), **GAP** (no suitable scenario exists at all). +`docs/ROOT_CURRICULUM_INVENTORY.md`'s evidence. Statuses: **READY** (meets +`docs/ROOT_PILOT_READINESS_STANDARD.md`'s bar), **PARTIAL** (real lesson + labs, missing one or +more of demonstration/guided-exercise/reflection), **PLANNED** (structure only, no content), +**GAP** (no suitable scenario exists at all). + +## Phase 6C verification (superseding Phase 6B's own self-reported counts) + +Baseline (start of Phase 6C), run directly against the database and filesystem +(`infra/scripts/validate-course-content.js`, 0 errors) rather than trusted from Phase 6B's +narrative report, which had miscounted: **21 modules total — 6 READY, 15 PARTIAL** (Phase 6B's +final report claimed 17 PARTIAL; the real count, re-verified here, was 15). + +**After Phase 6C's upgrades: 22 modules total — 16 READY, 6 PARTIAL.** (22, not 21: Phase 6C +added `root-11-m01-devops-platform-thinking`, ROOT 11's first real module — see +`docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md`.) 75 activities now carry content_path (up from 73), +163 activities total (up from 140), and unwired scenarios dropped from 10 (Phase 6B) to 2 +(`cluster-upgrade-mcq`, `etcd-backup-mcq` — both Cluster Administration/CKA-track content with +no current ROOT module to host them; see `docs/ROOT_PILOT_CURRICULUM.md`'s "not in pilot" +section). Full before/after detail and rationale per module is in +`docs/PHASE6C_CURRICULUM_COMPLETION.md`. + +**READY (16):** `root-05-m00-kubernetes-mental-model` (Phase 6A gold standard, unchanged), +`root-05-m01-pods-and-kubectl-basics` (Phase 6C: added bookending lesson + reflection around +its 20-task kubectl-fluency bank), `root-06-m02-deployments-scaling-updates` (unchanged), +`root-06-m03-jobs-cronjobs-daemonsets` (Phase 6C: added demonstration, guided exercise, +reflection — full gold pattern), `root-07-m02-configuration-and-secrets` (Phase 6C: added +lesson, demonstration, knowledge check, guided exercise, reflection — was a bare 5-lab bank), +`root-07-m03-services-and-service-discovery` (unchanged), `root-07-m04-ingress-networkpolicy-foundations` +(Phase 6C: full gold pattern added), `root-09-m01-security-model-and-securitycontext` +(unchanged), `root-09-m02-serviceaccounts-and-rbac` (Phase 6C: full gold pattern added), +`root-09-m03-network-and-supplychain-security` (Phase 6C: full gold pattern added), +`root-09-m04-cluster-hardening-and-runtime` (Phase 6C: documented exception — survey depth by +design, now anchored by a real security assessment), `root-10-m01-health-probes-and-troubleshooting` +(Phase 6A gold standard; Phase 6C added one optional practice lab), `root-10-m03-troubleshooting-framework` +(Phase 6C: added guided exercise + reflection), `root-12-m01-real-ops-incidents` (Phase 6C: +documented exception — deliberately unguided by design, status promoted with no new activities), +`root-capstone-m01-operate-and-recover` (Phase 6C: documented exception — the capstone exam IS +the module), `root-capstone-m02-capstone-readiness` (unchanged). + +**PARTIAL (6, all with a documented pilot disposition in `docs/ROOT_PILOT_CURRICULUM.md`):** +`root-06-m01-deployments-and-workloads`, `root-07-m01-services-and-networking`, +`root-10-m02-general-troubleshooting` (all three: dense practice banks, sibling module in the +same course already carries the taught concept — instructor-led only for the first pilot, +self-paced deferred), `root-08-m01-storage-fundamentals`, `root-08-m02-scheduling-resource-governance` +(ROOT 08 does not gate the capstone; deferred as optional supplementary content this phase), +`root-11-m01-devops-platform-thinking` (honest, lesson-only by design — no hands-on Lab exists +for ROOT 11 yet). ## Duplicate concepts identified (handled explicitly, not silently mapped twice) diff --git a/docs/ROOT_PILOT_CURRICULUM.md b/docs/ROOT_PILOT_CURRICULUM.md new file mode 100644 index 0000000..184e59e --- /dev/null +++ b/docs/ROOT_PILOT_CURRICULUM.md @@ -0,0 +1,118 @@ +# ROOT Pilot Curriculum — Authoritative Manifest + +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 +[`docs/ROOT_PILOT_READINESS_STANDARD.md`](ROOT_PILOT_READINESS_STANDARD.md) for what READY +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) + +The first pilot is scoped as **instructor-led**, not fully self-paced. Every module below that +is marked READY meets the self-paced bar (no "your instructor will explain this" gaps). A +smaller set of modules — flagged explicitly — are READY for instructor-led delivery only, +because they are dense hands-on practice banks whose sibling module in the same course already +carries the taught concept; 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. + +## Program: ROOT_ (root-kubernetes-foundations) + +| Course | Pilot status | Notes | +|---|---|---| +| ROOT 01 Computing & Linux Foundations | **NOT IN PILOT** | Never authored (status `planned`, zero modules). Out of Phase 6C's scope; students are assumed to arrive with basic Linux/CLI comfort for this pilot. | +| ROOT 02 Linux Administration & Networking | **NOT IN PILOT** | Same as above. | +| ROOT 03 Git & Collaborative Development | **NOT IN PILOT** | Same as above. | +| ROOT 04 Containers & Docker | **NOT IN PILOT** | Same as above. | +| ROOT 05 Kubernetes Foundations | **IN PILOT** | See modules below. | +| ROOT 06 Kubernetes Application Workloads | **IN PILOT** | See modules below. | +| ROOT 07 Kubernetes Networking & Configuration | **IN PILOT** | See modules below. | +| ROOT 08 Kubernetes Storage & Scheduling | **DEFERRED — optional supplementary** | Does not gate the capstone (`rootnode-path.json`'s six stages never included storage/scheduling). Both modules remain PARTIAL (lesson+knowledge-check only, no demo/guided/reflection). Offer as optional supplementary content to instructors who want it; do not count it in the pilot's required completion path. | +| ROOT 09 Kubernetes Security | **IN PILOT** | See modules below. | +| ROOT 10 Kubernetes Troubleshooting & Observability | **IN PILOT** | See modules below. | +| ROOT 11 DevOps & Platform Engineering | **IN PILOT — orientation only** | Lesson-only closing module. Hands-on GitOps/CI-CD/IaC/Observability content explicitly deferred; see scope doc. | +| ROOT 12 Real Ops | **IN PILOT** | READY. | +| ROOT Capstone | **IN PILOT** | READY. | + +## Module-level detail (courses IN pilot only) + +### ROOT 05 — Kubernetes Foundations +| Module | Status | Prerequisite | Outcome | Delivery | Required/Optional | Labs/Assessment | +|---|---|---|---|---|---|---| +| root-05-m00-kubernetes-mental-model | READY | none | Explain desired vs. actual state; run first kubectl commands | Self-paced or instructor-led | 6 required | 1 lab | +| root-05-m01-pods-and-kubectl-basics | READY | m00 | Broad kubectl command fluency (labels, JSONPath, patch, dry-run, etc.) | Self-paced or instructor-led (lesson+reflection added Phase 6C) | 22 required | 20 labs/MCQs | + +### ROOT 06 — Kubernetes Application Workloads +| Module | Status | Prerequisite | Outcome | Delivery | Required/Optional | Labs/Assessment | +|---|---|---|---|---|---|---| +| root-06-m02-deployments-scaling-updates | READY | ROOT 05 | Scale and roll out/back Deployments with confidence | Self-paced or instructor-led | 7 required | 1 lab | +| root-06-m03-jobs-cronjobs-daemonsets | READY | m02 | Choose the correct workload primitive for a given job | Self-paced or instructor-led (upgraded Phase 6C) | 7 required | 2 labs | +| root-06-m01-deployments-and-workloads | **PARTIAL — instructor-led only** | ROOT 05 | Deeper Deployment practice bank (8 tasks, no bookending lesson) | **Instructor-led only this pilot**; self-paced deferred | 8 required | 8 labs | + +### ROOT 07 — Kubernetes Networking & Configuration +| Module | Status | Prerequisite | Outcome | Delivery | Required/Optional | Labs/Assessment | +|---|---|---|---|---|---|---| +| root-07-m03-services-and-service-discovery | READY | ROOT 06 | Explain Service types and discovery | Self-paced or instructor-led | 6 required | 1 lab | +| root-07-m02-configuration-and-secrets | READY | m03 | Choose ConfigMap vs. Secret vs. env var vs. volume correctly | Self-paced or instructor-led (new lesson/demo/KC/guided/reflection Phase 6C) | 10 required | 5 labs | +| root-07-m04-ingress-networkpolicy-foundations | READY | m02 | Trace request routing through Ingress; plan network isolation | Self-paced or instructor-led (upgraded Phase 6C) | 7 required | 2 labs | +| root-07-m01-services-and-networking | **PARTIAL — instructor-led only** | ROOT 06 | Deeper Services/networking practice bank (4 tasks, no bookending lesson) | **Instructor-led only this pilot**; self-paced deferred | 4 required | 4 labs | + +### ROOT 09 — Kubernetes Security +| Module | Status | Prerequisite | Outcome | Delivery | Required/Optional | Labs/Assessment | +|---|---|---|---|---|---|---| +| root-09-m01-security-model-and-securitycontext | READY | ROOT 07 | Harden a Pod's SecurityContext with reasoning, not memorization | Self-paced or instructor-led | 9 required + 3 optional | labs | +| root-09-m02-serviceaccounts-and-rbac | READY | m01 | Write least-privilege RBAC | Self-paced or instructor-led (upgraded Phase 6C) | 10 required + 1 optional | 6 labs | +| root-09-m03-network-and-supplychain-security | READY | m02 | Apply default-deny NetworkPolicy and supply-chain controls | Self-paced or instructor-led (upgraded Phase 6C) | 9 required + 2 optional | 6 labs | +| root-09-m04-cluster-hardening-and-runtime | READY (survey depth, documented exception) | m03 | Survey-level exposure to runtime/cluster hardening topics, checked with a real assessment | Self-paced or instructor-led | 4 required + 2 optional | 4 labs + **RootNode Kubernetes Security Assessment** (9-scenario timed exam) | + +### ROOT 10 — Kubernetes Troubleshooting & Observability +| Module | Status | Prerequisite | Outcome | Delivery | Required/Optional | Labs/Assessment | +|---|---|---|---|---|---|---| +| root-10-m01-health-probes-and-troubleshooting | READY | ROOT 09 | Configure and diagnose liveness/readiness probes | Self-paced or instructor-led | 6 required + 1 optional | 1 required lab + 1 optional lab (readiness-probe-task, wired Phase 6C) | +| root-10-m03-troubleshooting-framework | READY | m01 | Apply the seven-step Observe→Evidence→...→Prevent-Recurrence framework to novel failures | Self-paced or instructor-led (upgraded Phase 6C) | 7 required | 2 labs | +| root-10-m02-general-troubleshooting | **PARTIAL — instructor-led only** | m01 | Deeper troubleshooting practice bank (6 tasks, no bookending lesson) | **Instructor-led only this pilot**; self-paced deferred | 6 required | 6 labs | + +### ROOT 11 — DevOps & Platform Engineering +| Module | Status | Prerequisite | Outcome | Delivery | Required/Optional | Labs/Assessment | +|---|---|---|---|---|---|---| +| root-11-m01-devops-platform-thinking | PARTIAL (honest, lesson-only by design) | ROOT 10 (course-level gate) | Name DevOps/platform engineering practices already exercised in ROOT 05-10/12; understand what's still missing for GitOps/CI-CD/IaC/observability | Self-paced or instructor-led | 3 required | none — orientation only | + +### ROOT 12 — Real Ops +| Module | Status | Prerequisite | Outcome | Delivery | Required/Optional | Labs/Assessment | +|---|---|---|---|---|---|---| +| root-12-m01-real-ops-incidents | READY (documented exception — deliberately unguided by design) | ROOT 10 | Run structured incident response without a hint system | Instructor-led recommended for first exposure; self-paced viable given deliberate design | 6 required | 4 incident labs | + +### ROOT Capstone +| Module | Status | Prerequisite | Outcome | Delivery | Required/Optional | Labs/Assessment | +|---|---|---|---|---|---|---| +| root-capstone-m02-capstone-readiness | READY | ROOT 12 | Confirm readiness before attempting the capstone | Self-paced or instructor-led | 4 required | checklist/prep activities | +| root-capstone-m01-operate-and-recover | READY (documented exception — the capstone IS the module) | m02 + capstone unlock gate | Operate and recover a production-like environment under real ops discipline | Instructor-observed recommended | 1 required | capstone exam | + +## Instructor prep requirements + +Every module marked "instructor-led only" or "instructor-led recommended" above requires the +instructor to have read that module's Instructor Notes section (timing, misconceptions, +discussion prompts) before delivering it live — this content already exists for every upgraded +module (see `docs/ROOT_PILOT_READINESS_STANDARD.md` checklist item 6). No additional +instructor-only prep material was created outside the per-activity Instructor Notes. + +## What is intentionally NOT in the first pilot + +- ROOT 01-04 (never authored). +- ROOT 08 Kubernetes Storage & Scheduling (non-capstone-gating; both modules remain PARTIAL). +- ROOT 11 modules 2-7 (GitOps, CI/CD, IaC, hands-on Observability, hands-on Reliability) — see + scope doc. +- Fully self-paced delivery of root-06-m01, root-07-m01, and root-10-m02 specifically — these + three run instructor-led in the first pilot; self-paced delivery for exactly these three + modules is deferred pending an authored teaching layer for each. +- `cluster-upgrade-mcq` and `etcd-backup-mcq` (Cluster Administration category) — no current + ROOT module teaches kubeadm-based cluster administration or etcd backup/restore; these two + scenarios stay unwired pending a future Cluster Administration module, not due to neglect. + +## Bottom line + +Every module the pilot's required completion path depends on (ROOT 05-07, 09-10, 12, Capstone) +meets the READY bar for instructor-led delivery. Three specific modules run instructor-led only +this pilot. ROOT 08 and most of ROOT 11 are explicitly out of the required path. Given that +scope, the pilot curriculum, delivered instructor-led, is ready. diff --git a/docs/ROOT_PILOT_READINESS_STANDARD.md b/docs/ROOT_PILOT_READINESS_STANDARD.md new file mode 100644 index 0000000..5033008 --- /dev/null +++ b/docs/ROOT_PILOT_READINESS_STANDARD.md @@ -0,0 +1,83 @@ +# ROOT_ Pilot Readiness Standard + +Phase 6C §2 — the explicit bar a module must clear to be called READY for the first paid ROOT_ +pilot. Extends `docs/COURSE_AUTHORING_STANDARD.md` with a pass/fail checklist rather than +general authoring guidance, and replaces ad hoc judgment calls with a documented rule every +module in `docs/ROOT_PILOT_CURRICULUM.md` is checked against. + +## The standard is about sufficiency, not a fixed activity count + +Phase 6A/6B's gold-standard pattern (lesson → demonstration → knowledge check → guided exercise +→ lab → reflection) is a strong DEFAULT for an operational skill module, not a mechanical +checklist to force onto every module regardless of subject. The actual test is: + +> **Does the learner have enough instruction and scaffolding to reasonably perform the practical +> work, understand why it matters, and check their own understanding — without an instructor +> filling a gap the content itself should have closed?** + +A module can be READY with fewer activities if the subject genuinely doesn't need all six. A +module can have all six activities and still not be READY if any of them fails its own bar +below (a "lab" with no framing, a "knowledge check" that only tests recall of the immediately +preceding paragraph). + +## The READY checklist + +A module is READY only if ALL of the following are true: + +1. **Concept instruction exists and is substantive.** A `lesson` (or equivalent) activity + explains the underlying mental model — what problem this solves, how it actually works, what + goes wrong when it's misunderstood — not a restated scenario description or a bullet list of + commands with no explanation of why. +2. **The learner sees the reasoning demonstrated, not just described**, wherever the subject + involves diagnosing or configuring something non-trivial. This can be a `demonstration` + activity, OR — for a purely conceptual/orientation module where there's nothing to + diagnose — folded into the lesson itself with a worked example. A module that skips this + entirely for an operational/troubleshooting subject is not READY. +3. **The learner can check their own understanding** before attempting independent work — a + `knowledge_check` (or, for an orientation module with no lab, a reflection that serves the + same self-check purpose) that tests INTERPRETATION and REASONING (see + `docs/COURSE_AUTHORING_STANDARD.md` §9's examples), not trivia. +4. **The learner is not dropped into a lab cold.** Where a `lab` activity exists, either a + `guided_exercise` bridges lesson to lab, OR the lesson/demonstration already gave the learner + everything they need to attempt the lab's specific task without guessing at the mechanism + being tested. A bare lab reference with a one-line "go do this" intro and no prior teaching + of the concept it tests is NOT READY, regardless of how good the lab's own hints are — Labs + are the laboratory, not the whole course (Phase 6A's own founding principle). +5. **The module closes with operational context**, where the subject has real production + consequences — a `reflection` connecting what was practiced to why it matters beyond passing + validation (see `docs/COURSE_AUTHORING_STANDARD.md` §15's Real Ops takeaway examples). A + purely conceptual orientation module (e.g. Capstone Readiness) may satisfy this through its + own closing content rather than a separate reflection activity. +6. **Instructor notes exist wherever a live class would benefit from them** — at minimum on the + lesson and any demonstration/guided-exercise activity: timing, a likely misconception, and + (for a demonstration) a demo plan. Not required on every activity type (a bare lab activity + with no `content_path` has nothing to attach notes to). +7. **Self-paced sufficiency**: nothing in the module says or implies "your instructor will + explain this" for content available to self-paced students. If an activity is genuinely + instructor-only (rare in this content model — everything self-paced students can reach uses + the same file), it must be excluded from self-paced delivery structurally, not by a + disclaimer. +8. **Every reference resolves** — `scenario_id` points at a real scenario file, + `assessment_definition_id` at a real definition, `content_path` at a real file that actually + loads (`infra/scripts/validate-course-content.js` proves this mechanically; a human read- + through confirms the CONTENT itself, not just that the file exists). + +## What does NOT make a module READY + +- Having a `lab` activity. A scenario reference is necessary, never sufficient. +- Having headings that look like a lesson. Prose volume is not instruction quality. +- Existing in the database with `status = 'ready'`. That field is the AUTHOR's claim — this + document is the actual bar it's checked against, and `docs/ROOT_PILOT_CURRICULUM.md` is where + every claim gets verified against this checklist by a human, not just by the field's value. +- Passing `e2e-phase6c.js`'s structural checks alone. Automated tests prove the DATA MODEL is + correct (references resolve, completion derives correctly) — they cannot judge whether a + lesson's explanation is actually good. That judgment is made once, explicitly, per module, + and recorded in the pilot manifest. + +## DEFERRED / NOT IN PILOT is not a failure + +A module that doesn't meet this bar is not a defect to apologize for — it's an honest status. +`docs/ROOT_PILOT_CURRICULUM.md` uses DEFERRED (real content exists, not yet pilot-quality) and +NOT IN PILOT (deliberately excluded — e.g. ROOT 01-04, most of ROOT 11) as first-class, +legitimate outcomes. Marking something READY that isn't is a worse outcome than an honestly +smaller pilot.