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