rootnode-academy/docs/PHASE6B_ROOT_CURRICULUM_EXPANSION.md

Phase 6B — ROOT_ Curriculum Authoring & Coverage Expansion

Status: PHASE 6B COMPLETE. 13 NEW TEACHING MODULES AUTHORED ACROSS ROOT 05-10/12/CAPSTONE. CAPSTONE SERVER-SIDE UNLOCK ENFORCEMENT FIXED. VALIDATED AGAINST A REAL LAB.

Phase 6A built the course/module/activity content model and one gold-standard module. Phase 6B is the primary content-authoring phase: real, substantial teaching content across the Kubernetes/operations portion of root_, built strictly from the existing 98-scenario inventory — no new scenarios were needed or created (see §7).

1. What was authored

13 new modules across 7 courses, all evidence-mapped in docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md:

Course	New module(s)	Depth
ROOT 05	Kubernetes Mental Model & Core Objects	READY — full gold-standard pattern
ROOT 06	Deployments, Scaling & Updates	READY — full gold-standard pattern
ROOT 06	Jobs, CronJobs & DaemonSets	PARTIAL — lesson + knowledge check + labs
ROOT 07	Services & Service Discovery	READY — full gold-standard pattern
ROOT 07	Ingress & NetworkPolicy Foundations	PARTIAL — lesson + knowledge check + labs
ROOT 08	Storage Fundamentals	PARTIAL — lesson + knowledge check + labs
ROOT 08	Scheduling & Resource Governance	PARTIAL — lesson + knowledge check + labs
ROOT 09	Security Model & SecurityContext	READY — full gold-standard pattern + guided/independent/advanced practice
ROOT 09	ServiceAccounts & RBAC	PARTIAL — lesson + knowledge check + labs
ROOT 09	Network & Supply Chain Security	PARTIAL — lesson + knowledge check + labs
ROOT 09	Cluster Hardening & Runtime Security	PARTIAL — survey-depth lesson + labs
ROOT 10	The RootNode Troubleshooting Framework	PARTIAL — lesson + demonstration + knowledge check + labs
ROOT 12	Incident-response framing added to the existing Real Ops module	PARTIAL — framework lesson + reflection wrapping the existing incidents
ROOT Capstone	Capstone Readiness	READY — orientation module, see docs/ROOT_CAPSTONE_READINESS.md

3 modules reach READY by the honest bar in docs/COURSE_AUTHORING_STANDARD.md (introduction, objectives, concept lesson, demonstration, knowledge check, guided practice, lab, reflection, instructor notes, estimated duration, all present) — plus the pre-existing gold-standard Health Probes module, unchanged. Every other new module is honestly PARTIAL: real lesson content and real labs, missing one or more of demonstration/guided-exercise (documented per-module in the coverage matrix, not glossed over).

ROOT 08 and ROOT 09 moved from PLANNED to PARTIAL at the course level — real content now exists where Phase 6A left them structurally empty.

2. The is_required extension (Phase 6B, not Phase 6A)

module_activities.is_required (new column, defaults true — every Phase 6A activity is unaffected) lets a module distinguish CORE activities from GUIDED/INDEPENDENT-practice duplicates and ADVANCED/optional extras (ROOT 09's CKS-style content, mostly). A module is "complete" once every REQUIRED activity is done — an incomplete optional activity never blocks it, though it still counts toward the displayed percent. See docs/COURSE_CONTENT_MODEL.md's updated completion-rules section.

3. The capstone server-side unlock fix

Full detail in docs/ROOT_CAPSTONE_READINESS.md §4. Summary: POST /api/assessments/ :definitionId/start previously never checked unlock_rule — a direct API call could start the capstone before its prerequisite stages were genuinely complete, even though the UI never exposed a way to trigger this. Fixed by binding to the same computeCurriculumState() gate GET /api/capstone already used. Found while fixing this: e2e-phase5b.js's own capstone test had been passing only because of this exact gap (it never completed the real-ops stage before attempting to start) — fixed alongside the platform code, not routed around.

4. Content quality bar applied honestly

No module was marked READY merely for having activity rows, headings, or scenario references. The ROOT 08/09 storage/scheduling/security modules are real, substantive lessons with real knowledge checks — but without a demonstration or guided exercise, they're PARTIAL, not READY, by this project's own stated standard. See the coverage matrix for the specific gap in each.

5. Scenario coverage before/after

Verified by direct query against module_activities.scenario_id, not estimated.

Before Phase 6B: 44 of 98 scenarios wired into structured curriculum (all via Phase 6A's mechanical mapping of rootnode-path.json's existing stages).

After Phase 6B: 88 of 98 scenarios (89.8%) now in structured curriculum — 44 newly wired this phase: deployment-rollback (added to ROOT 06 m02 as hands-on rollback practice alongside its lesson), job-task, cronjob-task (ROOT 06 m03); nodeport-task, dns-resolution-mcq (ROOT 07 m01), ingress-task, network-policy (ROOT 07 m04); emptydir-pod, pv-pvc-mount, pvc-dynamic-task, storageclass-mcq (ROOT 08 m01), node-label-selector, node-taint-toleration, pod-affinity-mcq, priority-class-task, pod-disruption-budget-task, resource-quota-ns, limitrange-task (ROOT 08 m02); cks-non-root-enforce, cks-drop-capabilities, cks-readonly-filesystem, cks-pod-security-context, cks-seccomp-profile, cks-apparmor-profile, pod-security-context (ROOT 09 m01); serviceaccount-pod, cks-automount-token, rbac-role, cks-rbac-clusterrole, cks-rbac-least-privilege, rbac-clusterrole (ROOT 09 m02); cks-network-policy, cks-egress-namespace, cks-tls-ingress, cks-image-pull-secret, networkpolicy-egress, cks-network-policy-metadata (ROOT 09 m03); cks-psa-namespace, cks-immutable-secret, cks-runtime-class, cks-audit-policy (ROOT 09 m04); crashloop-fix, endpoint-fix-task (ROOT 10 m03), container-logging-mcq (ROOT 10 m02, existing bank).

10 scenarios remain unwired, each with a specific, documented reason rather than an oversight: cluster-upgrade-mcq, etcd-backup-mcq (ROOT 11/DevOps territory, explicitly out of Phase 6B's authoring scope); 7 CKS-style MCQs classified as ASSESSMENT BANK material (cks-mcq-api-server, cks-mcq-audit-policy, cks-mcq-kubelet-auth, cks-mcq-psp-replacement, cks-mcq-runtime-security, cks-mcq-sandboxing, cks-mcq-image-footprint) — recall-style questions better suited to a future structured exam pool than hands-on core teaching, flagged for that future use rather than silently dropped; and readiness-probe-task — a real, unused candidate for independent practice in ROOT 06 or ROOT 10 that this phase simply didn't get to, honestly left for Phase 6C rather than force-mapped at the last minute. Quality of mapping, not percentage, drove every placement decision — see the coverage matrix's "duplicate concepts identified" section for how near-duplicate scenarios were handled deliberately rather than both force-fit into "core."

6. Knowledge-check and guided-exercise approach

Every new knowledge check uses scenario-interpretation and reasoning questions ("A Deployment has three replicas but the Service has zero endpoints — which part of the system should you inspect first, and why?"), never "what command was shown two paragraphs ago." Every guided exercise bridges lesson to lab without revealing the lab's answer — modeled directly on the existing gold module's own guided exercise. No new knowledge-check engine capability was needed; the existing Markdown + manual-marker model was sufficient throughout.

7. Why no new scenarios were created

Every learning objective this phase authored had a suitable existing scenario — the 54-scenario unused bank Phase 6A inventoried was exactly the content Phase 6B needed. No objective was found that genuinely required new hands-on lab content with no existing scenario able to serve it, so no new rootnode-* scenario was created this phase (see the authorization's explicit justification bar in its §17 — none of the three required conditions were met for any specific gap identified during authoring).

8. What Phase 6B deliberately did not build

Per the authorization's explicit scope line: init_/compile_ curriculum, deep authoring of ROOT 01-04 or ROOT 11 (both remain structurally PLANNED, as Phase 6A left them — genuinely no scenario content exists for either), a Parent Portal, payments, public registration, an AI tutor, chat/video/voice, proctoring, a mobile app, certificates, a multi-host scheduler, production deployment changes, an LMS/CMS, a WYSIWYG authoring system, or complex drip scheduling. The Provisioner, Gateway, Lab Router, student/instructor authentication, enrollment architecture, and notification architecture were not redesigned — the one fix made (capstone unlock) was the smallest correct change to the assessment engine's existing route, not a redesign of the engine itself.

9. Test results

• e2e-phase6b.js: 24 passed, 0 failed.
• test-phase6b-root-course-rehearsal.js (real k3s Lab, real kubectl expose, real classroom tooling): 11 passed, 0 failed.
• Full regression (2A/2B/3A/3B/5A/5B/5C/6A), each run in isolation per the convention Phase 6A established — see the final report for the run-by-run result and the two pre-existing test gaps found and fixed along the way (in e2e-phase5b.js and e2e-phase6a.js, both caused by this phase's own intentional, documented behavior changes, not by a defect).

10. Known limitations / recommended Phase 6C scope

• ROOT 06/07/08/09/10's PARTIAL modules are missing a demonstration and/or guided exercise — the natural next authoring pass, module by module, using the 3 READY modules as templates.
• ROOT 09's 7 ASSESSMENT-BANK-classified MCQs are inventoried but not yet wired into an actual assessment definition.
• ROOT 11 (DevOps & Platform Engineering) remains entirely PLANNED — no scenario content exists anywhere in this repository for CI/CD, IaC, or GitOps concepts; a future phase would need to either author new rootnode-* scenarios for it or explicitly scope it out of root_.
• The Capstone Readiness module's completion is intentionally independent of the real capstone's unlock gate (see docs/ROOT_CAPSTONE_READINESS.md §3) — worth revisiting only if a future phase has a concrete reason to couple them, not as a default assumption.