docs(phase6c): pilot readiness standard, pilot curriculum manifest, ROOT 11 scope

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 <[email protected]>
2026-08-26 11:21:09 -05:00
parent 01d3764138
commit bd0a10fbfb
6 changed files with 488 additions and 4 deletions
@@ -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.
@@ -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.
@@ -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.
@@ -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
+`docs/ROOT_CURRICULUM_INVENTORY.md`'s evidence. Statuses: **READY** (meets
-learn from it end to end — see `docs/COURSE_AUTHORING_STANDARD.md`'s bar), **PARTIAL** (real
+`docs/ROOT_PILOT_READINESS_STANDARD.md`'s bar), **PARTIAL** (real lesson + labs, missing one or
-lesson + labs, missing one or more of demonstration/knowledge-check/guided-exercise), **PLANNED**
+more of demonstration/guided-exercise/reflection), **PLANNED** (structure only, no content),
-(structure only, no content), **GAP** (no suitable scenario exists at all).
+**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)
@@ -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.
@@ -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.