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.