# 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.