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]>

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.

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.

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.

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)
 

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.

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.