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.