feat(curriculum): Phase 6C module upgrades, security assessment bank, ROOT 11 orientation

Upgrades six PARTIAL modules to the gold-module standard (lesson/demonstration/
knowledge-check/guided-exercise/lab(s)/reflection), preserving every existing lab
activity_id and scenario_id: root-06-m03 (jobs/cronjobs/daemonsets), root-07-m04
(ingress/networkpolicy), root-07-m02 (configuration/secrets, converted in place
from a bare 5-lab bank), root-09-m02 (serviceaccounts/rbac), root-09-m03
(network/supply-chain security), root-10-m03 (troubleshooting framework).

root-05-m01 (20-task kubectl-fluency bank) gets a minimal bookending lesson +
reflection rather than a full redesign, since each task already carries its own
explanation. root-12-m01, root-capstone-m01, and root-09-m04 are promoted to
READY via documented exceptions (no new activities) where adding one would
misrepresent their intentional design.

Wires a new rootnode-security-assessment (exam, 60min, hint_policy disabled)
using the existing Phase 3B assessment engine: 3 required hands-on CORE
scenarios + 4 random-draw pools covering SecurityContext, RBAC, network
policy, and the 7 previously-unwired CKS MCQs. Wires the previously-unwired
readiness-probe-task scenario as an OPTIONAL practice lab in root-10-m01,
using the existing is_required model.

Adds root-11-m01-devops-platform-thinking — an honest, lesson-only ROOT 11
orientation module naming DevOps/platform engineering practices already
exercised in ROOT 05-10/12, explicit that GitOps/CI-CD/IaC/observability need
lab infrastructure this platform doesn't yet provide. No fake labs.

Adds infra/scripts/validate-course-content.js: cross-checks the DB against
scenario/content files for duplicate ids, orphans, invalid references, cycles,
sequence collisions, instructor-notes leakage, and (new) self-paced content
deferring explanation to a live instructor. 0 errors against the resulting
22 courses/modules, 163 activities, 98 scenario files.

No application code changed — every gap was satisfiable with existing tables
(course_modules, module_activities, assessment_definitions) and the existing
content-delivery pipeline.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

content/root/root-05-kubernetes-foundations/m01-pods-and-kubectl-basics/00-lesson-kubectl-fluency.md

@@ -0,0 +1,49 @@
+# Building kubectl Fluency: Why Twenty Small Reps Beat One Big Lecture
+
+## What this module is, and why it looks different from the last one
+
+ROOT 05's mental model module (m00) taught you the CONCEPT of desired state and gave you your
+first `kubectl` commands. This module does something deliberately different: it's a breadth
+drill across the everyday `kubectl` vocabulary you'll type dozens of times a day as a working
+Kubernetes engineer — labels, JSONPath, dry-run manifests, patch, field selectors, sort-by,
+diff, init containers, static Pods, and more.
+
+There's no single narrative thread connecting these twenty tasks, and that's intentional. Real
+`kubectl` fluency isn't one big insight — it's having enough of these small, specific commands
+already in muscle memory that you're not stopping to look up syntax while you're mid-incident.
+Each task below explains the specific concept it covers in its own description; your job is to
+work through them, not to memorize a lecture first.
+
+## How to approach this module
+
+- **Don't try to do them in one sitting if you don't need to.** These are independent — skip
+  around, come back to ones you found awkward, and don't feel obligated to treat this as one
+  continuous session.
+- **Read each task's own explanation before reaching for the hint.** Every one of these
+  twenty tasks includes real context in its description — that context IS the teaching content
+  for that specific command. The hint is there for when you're stuck, not as the first thing to
+  read.
+- **Notice which commands you reach for confidently versus which ones you have to think about.**
+  That gap is exactly what the reflection at the end of this module asks you to name.
+- **This breadth matters more than it looks like it does.** `kubectl explain`, `--dry-run`,
+  JSONPath output, and `kubectl patch` in particular are commands experienced engineers use
+  constantly and newer engineers often don't know exist at all — this module exists specifically
+  to close that gap early.
+
+## Instructor Notes
+
+**Lesson goal:** Frame this module correctly before students hit it — it's a breadth-practice
+bank, not a single-concept lesson, and the individual task descriptions carry the teaching
+content. Without this framing, students sometimes expect a lecture and are confused when they
+land directly on twenty short tasks.
+
+**Approximate timing:** 5 minutes to introduce; the module itself runs long (20 tasks) and is
+meant to be worked through at each student's own pace, live or between sessions.
+
+**Facilitation for a live cohort:** Consider live-demoing 2-3 of the less obvious ones
+(`kubectl explain`, JSONPath output, `kubectl patch`) rather than all twenty — the goal is to
+unblock students on the commands they're least likely to have seen before, not to walk through
+every task.
+
+**Expected takeaway:** Kubernetes fluency is built from a large vocabulary of small, reliable
+commands, not just conceptual understanding — this module is where that vocabulary gets built.

content/root/root-05-kubernetes-foundations/m01-pods-and-kubectl-basics/21-reflection.md

@@ -0,0 +1,40 @@
+# Reflection: Naming Your Gaps While They're Still Cheap to Close
+
+You just worked through twenty independent `kubectl` tasks. Before moving on, take a few
+minutes to consolidate what actually stuck versus what you'd need to look up again.
+
+## Reflection questions
+
+1. Which THREE of these twenty commands do you feel genuinely confident using again right now,
+   without a hint? Name them specifically.
+2. Which ONE command surprised you the most — either because you didn't know it existed, or
+   because it did something different than you expected?
+3. `kubectl explain`, `kubectl patch`, and JSONPath output are commands a lot of engineers never
+   learn early and end up rediscovering the hard way, mid-incident, years later. Now that you've
+   used all three, where do you think you'd actually reach for one of them in a real debugging
+   situation?
+
+## Real Ops takeaway
+
+**Fluency gaps are cheap to close now and expensive to close later.** Right now, not knowing
+`kubectl patch` costs you a few minutes rereading this module. In a live incident six months
+from now, not knowing it costs you minutes you don't have while a Service is down. Naming your
+gaps here, while the stakes are zero, is how you make sure you close them before they matter.
+
+**Breadth practice is not busywork.** It's easy to dismiss twenty small tasks as less valuable
+than one big project — but the twenty small tasks are what make the big project fast to execute
+later. This is the same discipline you'll rely on for the rest of ROOT_: build the vocabulary
+now, apply it under pressure later.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 3 works well as a round-robin — go
+person to person and have each name a different command, so the group collectively surfaces
+most of the twenty rather than converging on the same one or two obvious answers.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
+
+**Expected takeaway:** Students should leave this module able to name their own remaining gaps
+specifically, not just feel generally "done" with kubectl basics.