rootnode-academy/docs/PHASE6C_CURRICULUM_COMPLETION.md

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