docs(phase6b): document curriculum expansion

PHASE6B_ROOT_CURRICULUM_EXPANSION.md — the phase summary: what was
authored per course, the is_required extension, the capstone unlock
fix, verified scenario coverage before/after (44 -> 88 of 98, 89.8%,
by direct query not estimate), and honest known limitations/Phase 6C
recommendations.

ROOT_CAPSTONE_READINESS.md — the readiness module and the server-side
unlock fix in full detail, including why the module's completion and
the real assessment's unlock gate are deliberately independent systems.

Updated ROOT_CURRICULUM_INVENTORY.md (Phase 6B coverage numbers),
ROOT_PROGRAM_ARCHITECTURE.md (ROOT 08/09 PARTIAL, new module lists per
course), COURSE_CONTENT_MODEL.md (is_required completion rule, a new
content-versioning section per this phase's own requirement),
COURSE_AUTHORING_STANDARD.md (classifying near-duplicate/advanced
scenarios), ENGINEERING_SOP.md (new Phase 6B section),
REMOTE_AND_SELF_PACED_ARCHITECTURE.md (cross-reference), and
platform/README.md (e2e-phase6b.js, the Phase 6B rehearsal, isolation-
per-suite regression guidance).

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

README.md

@@ -163,6 +163,19 @@ its core:
   classes from `/admin` (presence, Lab/learning status, help-request queue, announcements,
   guidance-only current-activity) — RootNode owns identity/coordination, an external service
   (Meet/Zoom/Teams/etc.) owns the actual video/voice.
+- Students can now be enrolled in a self-paced program (as of Phase 5B) — "My Programs" on the
+  student dashboard, entitlement enforced server-side (pending/future/expired/cancelled
+  enrollments cannot launch a Lab no matter what the browser sends), completion server-derived
+  from the existing capstone rules. `/admin` gained a Programs area (program authoring, manual
+  enrollment, activate/cancel). A separate, provider-neutral `POST /api/integrations/enrollments`
+  boundary — server-to-server only, no browser session involved — is what the future public
+  `rootnodeacademy.com` website/checkout will call to create these enrollments; see
+  `docs/PHASE5B_SELF_PACED_ENROLLMENT.md` and `docs/WEBSITE_ENROLLMENT_INTEGRATION.md`.
+- As of Phase 5C, RootNode actually tells students what's happening — real activation,
+  enrollment-confirmation, and password-reset email, delivered asynchronously through a
+  provider-neutral notification worker (Google Workspace via the Gmail API in production, a
+  deterministic dev provider everywhere else — no test/dev run ever emails a real person). See
+  `docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md` and `docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md`.
 
 **Never publish the raw privileged container** — front it with isolation (that's what the
 Gateway is). The one-container `docker run --privileged -p 7554:80 ...` command above stays
@@ -200,7 +213,8 @@ Key properties of the platform (not this image):
 Production topology and what's built vs. not yet: `docs/LAB_ARCHITECTURE.md`,
 `docs/PHASE1_PLATFORM_FOUNDATION.md`, `docs/PHASE2A_GATEWAY_AND_STUDENT_FLOW.md`,
 `docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md`, `docs/PHASE3B_LEARNING_AND_ASSESSMENT.md`,
-`docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md`.
+`docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md`, `docs/PHASE5B_SELF_PACED_ENROLLMENT.md`,
+`docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md`.
 
 The production infrastructure package (Proxmox/Ansible/Terraform/firewall/monitoring/backup/CI)
 that runs all of this on real hardware lives in `infra/` — see

content/root/root-05-kubernetes-foundations/m00-mental-model/01-lesson-mental-model.md

@@ -0,0 +1,108 @@
+# What Kubernetes Solves & the Desired-State Model
+
+## Before Kubernetes: the problem
+
+Imagine you're running a web application on three servers by hand. One server crashes at 2am —
+someone has to notice, log in, and restart the application. Traffic grows, so you need a fourth
+server — someone has to provision it, install dependencies, and configure it to match the other
+three. You ship a new version — someone has to update all four servers, one at a time, without
+taking the whole application down.
+
+None of this is hard in isolation. It becomes unmanageable at scale, and it depends entirely on
+a human noticing and reacting fast enough. Kubernetes exists to make a computer do that
+noticing and reacting instead — continuously, automatically, and the same way every time.
+
+## The core idea: desired state
+
+You don't tell Kubernetes *how* to run your application step by step. You tell it *what you
+want to be true* — "3 replicas of this container should be running" — and Kubernetes
+continuously works to make that true, correcting drift whenever reality doesn't match.
+
+This is the single most important mental shift for someone new to Kubernetes: you're not
+writing a script that runs once. You're declaring a **desired state**, and a background process
+never stops comparing the real world against it.
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: web
+spec:
+  replicas: 3          # <- the desired state: "3 of these, always"
+  ...
+```
+
+If a Pod crashes, Kubernetes doesn't "restart the crashed one" as a special case — it just
+notices reality (2 running) no longer matches desired state (3 wanted) and creates a
+replacement. Same mechanism, no special-casing.
+
+## The cluster mental model
+
+A Kubernetes cluster has two conceptually different kinds of machines:
+
+- **The control plane** — the "brain." It stores the desired state (in `etcd`), watches actual
+  state, and makes decisions (the API server, scheduler, and controllers all live here). You
+  talk to the control plane through `kubectl`; you never SSH into it to manage workloads.
+- **Worker nodes** — where your containers actually run. Each node runs a `kubelet` (an agent
+  that starts/stops containers as the control plane instructs) and a container runtime.
+
+You describe desired state to the control plane. The control plane decides which nodes should
+run what. The nodes' kubelets make it actually happen. You never manually place a Pod on a
+specific node in normal operation — that placement decision belongs to the scheduler.
+
+## Declarative, not imperative
+
+"Imperative" means giving step-by-step instructions ("start a container, then another, then
+configure networking between them"). "Declarative" means describing an end state and letting
+the system figure out the steps. Kubernetes' API objects (Pods, Deployments, Services, and
+everything else you'll learn in ROOT_) are declarative — you write YAML describing what should
+exist, `kubectl apply` submits it, and the control plane does the rest.
+
+This is also why Kubernetes YAML looks the way it does: it's not a script, it's a specification.
+
+## Pods, Namespaces, and labels — the vocabulary you need first
+
+- **Pod** — the smallest deployable unit. Usually one container, sometimes a small group of
+  tightly-coupled containers that must run together on the same node and share networking.
+  You'll rarely create bare Pods directly in real use (a Deployment manages them for you, see
+  ROOT 06) but understanding the Pod itself is foundational to everything built on top of it.
+- **Namespace** — a way to partition one cluster into logically separate areas (e.g. `dev`,
+  `staging`, teams, or projects), so names don't collide and access/quotas can be scoped.
+- **Labels** — arbitrary key/value tags attached to objects (`app: web`, `env: prod`). Labels
+  are how almost everything in Kubernetes finds related objects — a Deployment finds "its" Pods
+  by label selector, not by name pattern matching.
+
+## kubectl: your one tool for all of this
+
+`kubectl` is the command-line client that talks to the control plane's API server. Nearly
+everything you'll do in ROOT_ Labs goes through it: `kubectl get` (list/inspect),
+`kubectl describe` (detailed status + recent events — your primary troubleshooting tool),
+`kubectl apply -f` (submit a desired-state YAML file), `kubectl logs` (see what a container
+printed). You'll build real fluency with these across this module and the ones that follow.
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read, 10-12 minutes for a live walkthrough with discussion.
+
+**Demo plan:** Before the demonstration activity, it's worth drawing the control-plane/worker
+split on a whiteboard (or sharing a simple diagram) and tracing one request: `kubectl apply` ->
+API server -> etcd -> scheduler -> kubelet -> container runtime. Students retain the mental
+model much better when they've seen the path, not just read about it.
+
+**Likely misconceptions to watch for:**
+- Students often assume `kubectl` talks directly to nodes/containers. It doesn't — it only ever
+  talks to the API server. Worth stating explicitly.
+- "Declarative" is sometimes read as "automatic" in a vague sense. Be concrete: it means "you
+  describe the end state; a controller loop makes it true," not "Kubernetes guesses what you
+  want."
+
+**Discussion question:** "If desired state says 3 replicas and you manually run `kubectl delete
+pod` on one of them, what happens next, and why?" (Answer: a new one is created almost
+immediately — deleting a Pod doesn't change the Deployment's desired replica count, so the
+control loop restores it.)
+
+**Optional extension:** Ask students to predict what would happen if they edited a running Pod's
+container image directly with `kubectl edit pod` instead of updating the Deployment that manages
+it (answer: it works until that specific Pod is replaced for any reason, at which point the new
+Pod reverts to whatever the Deployment's template says — a good early illustration of "the
+Deployment is the source of truth, not the running Pod").

content/root/root-05-kubernetes-foundations/m00-mental-model/02-demonstration-desired-state.md

@@ -0,0 +1,76 @@
+# Demonstration: Desired State Reconciliation
+
+Watch what actually happens when reality drifts from desired state — this is the mechanism the
+whole lesson describes, made concrete.
+
+## Setup
+
+A Namespace called `demo` exists with a Deployment `web` declaring `replicas: 2`. Right now,
+reality matches desired state:
+
+```
+$ kubectl get pods -n demo
+NAME                   READY   STATUS    RESTARTS   AGE
+web-7d8f9c6b5d-abcde   1/1     Running   0          3m
+web-7d8f9c6b5d-fghij   1/1     Running   0          3m
+```
+
+## Someone (or something) deletes one Pod
+
+```
+$ kubectl delete pod web-7d8f9c6b5d-abcde -n demo
+pod "web-7d8f9c6b5d-abcde" deleted
+```
+
+## What happens in the next second or two, without anyone doing anything else
+
+```
+$ kubectl get pods -n demo
+NAME                   READY   STATUS              RESTARTS   AGE
+web-7d8f9c6b5d-fghij   1/1     Running             0          3m
+web-7d8f9c6b5d-klmno   0/1     ContainerCreating   0          1s
+```
+
+A brand new Pod (`...-klmno`, a new random suffix — this is NOT the deleted Pod coming back)
+appeared on its own. Nobody ran `kubectl create` again. The Deployment's controller noticed
+actual state (1 running Pod matching its label selector) no longer matched desired state
+(`replicas: 2`), and created exactly one replacement to close the gap — not two, not zero.
+
+A few seconds later:
+
+```
+$ kubectl get pods -n demo
+NAME                   READY   STATUS    RESTARTS   AGE
+web-7d8f9c6b5d-fghij   1/1     Running   0          3m
+web-7d8f9c6b5d-klmno   1/1     Running   0          8s
+```
+
+Back to 2/2 — desired state restored, entirely without human intervention.
+
+## Why this matters beyond the demo
+
+This exact mechanism is what makes a node crash, a Pod eviction, or a container being
+OOM-killed something Kubernetes recovers from automatically instead of something that pages a
+human at 2am. The controller loop doesn't know or care WHY a Pod disappeared — crash, manual
+delete, node failure — it only ever asks "does reality match desired state right now?" and acts
+if not. Understanding this one loop explains a huge amount of Kubernetes' behavior that would
+otherwise look like unrelated special cases.
+
+## Instructor Notes
+
+**Demo script:** Run this live rather than only showing the captured output above — have
+students watch `kubectl get pods -n demo --watch` in one terminal while you delete a Pod from
+another. Watching the new Pod name/age appear in real time lands the "this is a NEW Pod, not a
+restart" point far better than static text.
+
+**Approximate timing:** 8-10 minutes live; 5 minutes as a self-paced read.
+
+**Common misconception to correct:** students frequently describe this as "Kubernetes restarted
+the Pod." Correct this explicitly — a deleted Pod is gone permanently; a *new* Pod object was
+created to satisfy the replica count. This distinction matters later when debugging (the new
+Pod has zero history from the old one — no old logs, no old restart count).
+
+**Optional extension:** ask what would happen if you deleted the Deployment itself instead of
+one Pod (answer: all of its Pods are deleted and NOT replaced, because the thing declaring
+desired state is now gone — a good way to reinforce that the Deployment, not any individual
+Pod, is the actual source of truth).

content/root/root-05-kubernetes-foundations/m00-mental-model/03-knowledge-check.md

@@ -0,0 +1,48 @@
+# Knowledge Check: The Kubernetes Mental Model
+
+Answer each question yourself before reading the answer that follows it.
+
+---
+
+**1. You run `kubectl delete pod` on one Pod belonging to a Deployment with `replicas: 3`. A
+few seconds later, `kubectl get pods` shows 3 Pods again, but one has a different name than any
+of the original three. What actually happened?**
+
+*Answer:* The deleted Pod is gone permanently. The Deployment's controller noticed actual state
+(2 Pods) no longer matched desired state (3 Pods) and created ONE new Pod to close the gap. It
+is not the old Pod restarting — it's a brand new object.
+
+---
+
+**2. A Deployment has `replicas: 3`, and there are 5 nodes in the cluster. Which of these
+decides WHICH node each of the 3 Pods actually lands on?**
+
+*Answer:* The scheduler (part of the control plane), not the person who wrote the Deployment
+YAML and not the nodes themselves. You declare desired state; the scheduler makes the placement
+decision based on available resources and any placement rules configured.
+
+---
+
+**3. True or false: `kubectl` communicates directly with the kubelet on whichever node your
+Pod happens to be running on.**
+
+*Answer:* False. `kubectl` only ever talks to the API server (part of the control plane). The
+API server is the single entry point for every read and write — it never bypasses the control
+plane to reach a node directly for a normal `get`/`apply`/`describe` call.
+
+---
+
+**4. Why is Kubernetes YAML described as "declarative" rather than a script?**
+
+*Answer:* A script describes a sequence of steps to execute once. Kubernetes YAML describes an
+END STATE you want to exist ("3 replicas of this container should be running") — a controller
+loop then continuously works to keep reality matching that description, correcting drift
+whenever it appears, indefinitely, not just once at apply time.
+
+## Instructor Notes
+
+**Facilitation:** Ask these aloud in a live classroom before revealing answers — question 1 in
+particular tends to surface the "it restarted" misconception the demonstration activity should
+have already addressed; if it hasn't landed, this is the moment to circle back.
+
+**Approximate timing:** 5 minutes.

content/root/root-05-kubernetes-foundations/m00-mental-model/04-guided-exercise-namespaces.md

@@ -0,0 +1,57 @@
+# Guided Exercise: Planning a Namespace Layout
+
+This is a paper-and-thinking exercise — work through it before the Lab, not during it.
+
+## The scenario
+
+You're setting up a small Kubernetes cluster for a class project with three teams (`frontend`,
+`backend`, `data`), each running their own set of Pods, and you also need a shared area for
+tools everyone uses (a shared logging dashboard, for example).
+
+## Your task
+
+Sketch out, on paper or in a scratch file:
+
+1. What Namespaces would you create, and why? (Hint: think about who needs to see what, and
+   whether any team's mistake — e.g. deleting the wrong Pod by accident — should be able to
+   affect another team.)
+2. If `frontend` team members should be able to manage their own Pods but NOT touch `backend`'s
+   or `data`'s, what does that suggest about how Namespaces relate to access control? (You'll
+   learn the actual mechanism, RBAC, in ROOT 09 — for now just reason about why Namespace
+   boundaries make that kind of restriction possible at all.)
+3. Would you put the shared logging dashboard in one of the three team Namespaces, or somewhere
+   else? Justify your answer.
+4. If two teams both need to run something they each call `web`, what would happen if they were
+   in the SAME Namespace? What changes if they're in separate Namespaces?
+
+## A reasonable answer to check yourself against
+
+1. Three Namespaces (`frontend`, `backend`, `data`) — one per team, so each team's objects are
+   isolated from the others and a mistake in one Namespace (deleting the wrong Pod, applying a
+   bad manifest) can't accidentally affect a different team's workloads.
+2. Namespace boundaries are what RBAC rules can be scoped TO — "this person can manage Pods in
+   the `frontend` Namespace" is a real, common permission model. Without separate Namespaces,
+   you'd have to distinguish access by resource name pattern instead of by boundary, which is
+   far more error-prone.
+3. A separate Namespace (e.g. `shared-tools` or `platform`) — it isn't owned by any one team,
+   and mixing it into a team's Namespace would make it unclear who's responsible for it or
+   accidentally couple its lifecycle to that team's.
+4. In the SAME Namespace, object names must be unique — a second `web` Deployment would either
+   fail to create or overwrite the first, depending on how it's applied. In SEPARATE
+   Namespaces, both `frontend/web` and `backend/web` can coexist without conflict — the
+   Namespace is part of what makes a name unique, not just the name itself.
+
+If your answer differed meaningfully from this, re-read the lesson's Namespace section before
+continuing to the Lab.
+
+## Instructor Notes
+
+**Facilitation:** Good as a 2-3 person small-group discussion in a live classroom before
+revealing the reasonable answer — question 4 in particular often produces a genuine "oh" moment
+once students realize name uniqueness is Namespace-scoped, not cluster-wide.
+
+**Approximate timing:** 10 minutes live with discussion; 10 minutes self-paced.
+
+**Optional extension:** ask what would need to be true for the `data` team to be ALLOWED to read
+(but not modify) something in `shared-tools` — a good bridge to RBAC's read vs. write verbs,
+covered properly in ROOT 09.

content/root/root-05-kubernetes-foundations/m00-mental-model/05-lab-intro.md

@@ -0,0 +1,44 @@
+# Launch Lab: Working with Namespaces
+
+Time to apply the mental model for real — you'll create an actual isolated Namespace and deploy
+into it, in your own disposable Lab environment.
+
+## What you're doing
+
+You'll create a Namespace (`team-alpha`) and deploy an application into it with a specific
+replica count — directly applying the "isolated area within one cluster" idea from the guided
+exercise, and the desired-state model from the lesson (once you declare `replicas: 2`, that
+becomes the standing desired state for that Deployment, enforced continuously).
+
+## Before you start
+
+Think back to the demonstration: once your Deployment exists with its desired replica count,
+Kubernetes will keep it there on its own. You don't need to "check back" and manually fix
+anything — if you want to prove this to yourself, try deleting one of your Pods after you've
+finished the task and watch what happens.
+
+## Your task in this Lab
+
+Create the Namespace, then deploy the application inside it with the exact replica count
+specified. Use `kubectl get namespace` and `kubectl get deployment -n <namespace>` to confirm
+your work — the same verification pattern you'll use constantly throughout ROOT_.
+
+This Lab has its own in-context hints if you get stuck. Try working from the lesson and guided
+exercise first — the commands you need are exactly the ones described there.
+
+When you're done, return to this module to close out with a reflection on why this isolation
+matters beyond just "keeping things organized."
+
+## Instructor Notes
+
+**Classroom flow:** This is most students' first real `kubectl apply`/`create` in ROOT_ beyond
+whatever pilot exposure they've had — a good moment to circulate and check that basic
+`kubectl` command syntax isn't the blocker (as opposed to the Namespace concept itself, which
+the guided exercise should have already addressed).
+
+**Approximate timing:** 10-15 minutes.
+
+**Common mistake to watch for:** creating the Deployment in the DEFAULT namespace instead of
+`team-alpha` (forgetting `-n team-alpha` or the namespace field in the manifest) — this is a
+very common first mistake and a good real-world illustration of why Namespace isolation only
+works if you're actually specifying it every time.

content/root/root-05-kubernetes-foundations/m00-mental-model/06-reflection.md

@@ -0,0 +1,44 @@
+# Reflection: Why Desired State Matters in Production
+
+You just created an isolated Namespace and a Deployment with a declared replica count. Take a
+few minutes to connect this to why it matters beyond passing this Lab's validation.
+
+## Reflection questions
+
+1. If your `team-alpha` Namespace were a real team's production environment, what's one mistake
+   in a DIFFERENT namespace that Namespace isolation would have protected you from?
+2. You declared `replicas: 2` rather than manually creating two Pods. What would you have had
+   to do manually, over and over, if Kubernetes only supported creating individual Pods with no
+   concept of desired state?
+3. Think of one non-Kubernetes system you've used (a thermostat, a spell-checker, an
+   auto-save feature) that also works by continuously comparing "what is" to "what should be."
+   What made you think of it?
+
+## Real Ops takeaway
+
+**Namespaces are your first real production safety boundary, and they're free.** A
+misconfigured `kubectl delete` scoped to the wrong Namespace is a common, entirely preventable
+class of incident — teams that consistently namespace their environments (dev/staging/prod, or
+per-team) limit the blast radius of almost any operator mistake to just that Namespace. This
+costs nothing to set up and prevents a real, common category of outage.
+
+**Desired state is what makes self-healing possible at all.** Every "the platform recovered on
+its own" story you'll hear about Kubernetes in production traces back to exactly the mechanism
+you just watched in the demonstration: a controller comparing actual state to desired state and
+correcting the gap. Understanding this loop is what lets you predict Kubernetes' behavior
+instead of being surprised by it.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** use all three reflection questions as discussion
+prompts. Question 3 in particular tends to produce good analogies that make the abstract
+"controller loop" concept concrete and memorable.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
+
+**Optional extension:** ask students to name one place in their own life (not computing) where
+"declare the goal and let a system enforce it" would work better than "manually do the thing
+every time" — a genuinely reflective prompt that reinforces the mental model beyond Kubernetes
+specifically.

content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/01-lesson-deployments.md

@@ -0,0 +1,81 @@
+# Why Deployments Exist & How a Rolling Update Progresses
+
+## The problem a bare Pod doesn't solve
+
+A Pod, on its own, has no self-healing and no concept of "there should be more than one of
+these." If a Pod crashes, nothing recreates it. If you need 3 copies for capacity, you'd have to
+create 3 separately-named Pods by hand and keep track of all of them yourself. If you need to
+update the container image, you'd have to delete and recreate every one of them manually,
+almost certainly causing a visible outage while you do it.
+
+**A Deployment solves all three problems at once**: it declares how many replicas of a Pod
+template should exist, keeps that count true continuously (the exact desired-state mechanism
+from ROOT 05), and knows how to change the Pod template over time — a version upgrade — without
+just deleting everything and starting over.
+
+## ReplicaSets: the layer underneath, briefly
+
+You'll rarely touch a ReplicaSet directly, but understanding it clarifies what a Deployment
+actually does. A Deployment doesn't manage Pods directly — it manages a ReplicaSet, which is
+what actually keeps N Pods matching a label selector running. When you update a Deployment's
+Pod template (like changing the image), the Deployment creates a NEW ReplicaSet with the new
+template and gradually shifts replicas from the old ReplicaSet to the new one. The old
+ReplicaSet isn't deleted — it's scaled to zero and kept around, which is exactly what makes
+rollback possible (more on that below).
+
+## How a rolling update actually progresses
+
+By default, a Deployment updates using the `RollingUpdate` strategy: it doesn't take all old
+Pods down and bring all new ones up at once (that would cause an outage). Instead, it
+incrementally creates new-version Pods and removes old-version ones, always keeping enough
+capacity available:
+
+```
+Before:  [v1] [v1] [v1]
+Step 1:  [v1] [v1] [v1] [v2]      <- one new Pod created
+Step 2:  [v1] [v1] [v2]           <- one old Pod removed once new one is Ready
+Step 3:  [v1] [v1] [v2] [v2]
+Step 4:  [v1] [v2] [v2]
+...
+After:   [v2] [v2] [v2]
+```
+
+Crucially, a new Pod only counts as "up" for the purposes of proceeding once it passes its
+readiness probe (see ROOT 10's gold-standard module) — this is exactly why a misconfigured
+readiness probe can make a rollout hang indefinitely instead of failing fast: Kubernetes is
+correctly waiting for a "ready" signal that will never come.
+
+## Rollback: what it actually restores
+
+`kubectl rollout undo` doesn't magically know how to "undo" arbitrary changes — it works because
+of the old ReplicaSet still sitting around at zero replicas, from the mechanism described above.
+Rolling back means: scale the OLD ReplicaSet back up and the current (broken) one back down,
+using the exact same rolling mechanism as a forward update. This is why rollback is fast and
+safe — it's not a special operation, it's the same well-tested rolling-update machinery running
+in reverse, against a Pod template that's already known to have worked before.
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read, 10-12 minutes live with the ReplicaSet diagram.
+
+**Demo plan:** Draw (or show) the ReplicaSet-swap diagram above on a whiteboard before the
+demonstration activity — students who see the "old ReplicaSet scaled to zero, not deleted"
+detail up front connect rollback to rollout much faster.
+
+**Likely misconceptions to watch for:**
+- Students often think rollback "restores a backup" or reverts a Git-style diff. Correct this:
+  it's scaling an existing (still-present) ReplicaSet back up, nothing is being restored from
+  storage.
+- "Rolling update" is sometimes assumed to mean "one Pod at a time, always." The actual pace is
+  controlled by `maxSurge`/`maxUnavailable` (not covered in depth here, but worth naming so
+  students don't over-generalize from the simplified diagram).
+
+**Discussion question:** "Why does a rolling update need readiness probes to work correctly,
+specifically?" (Answer: without a readiness signal, Kubernetes has no way to know when a new
+Pod is actually safe to receive traffic before removing an old one — it would either guess via a
+fixed delay, unreliable, or not wait at all, unsafe.)
+
+**Optional extension:** ask what would happen to an in-progress rollout if the new image simply
+doesn't exist (a typo in the tag) — a good bridge to real troubleshooting: the rollout stalls
+indefinitely with `ImagePullBackOff` on the new Pods, never completing and never rolling back on
+its own.

content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/02-demonstration-rollout.md

@@ -0,0 +1,77 @@
+# Demonstration: Watching a Rollout, Good and Bad
+
+## A healthy rollout
+
+A Deployment `app-v1` running `nginx:1.24` at 3 replicas gets updated to `nginx:1.25`:
+
+```
+$ kubectl set image deployment/app-v1 nginx=nginx:1.25
+deployment.apps/app-v1 image updated
+
+$ kubectl rollout status deployment/app-v1
+Waiting for deployment "app-v1" rollout to finish: 1 out of 3 new replicas have been updated...
+Waiting for deployment "app-v1" rollout to finish: 2 out of 3 new replicas have been updated...
+Waiting for deployment "app-v1" rollout to finish: 1 old replicas are pending termination...
+deployment "app-v1" successfully rolled out
+```
+
+`kubectl rollout status` blocks and reports exactly the incremental progress described in the
+lesson — this is your primary tool for watching (or scripting a wait on) a rollout, rather than
+repeatedly polling `kubectl get pods` yourself.
+
+## Checking revision history
+
+```
+$ kubectl rollout history deployment/app-v1
+REVISION  CHANGE-CAUSE
+1         <none>
+2         <none>
+```
+
+Revision 1 is the original ReplicaSet (now scaled to zero, still present); revision 2 is the
+current one. This history is exactly what `kubectl rollout undo` uses.
+
+## A stalled rollout
+
+Now imagine the same update, but to a typo'd tag, `nginx:1.25-typo`, which doesn't exist:
+
+```
+$ kubectl rollout status deployment/app-v1
+Waiting for deployment "app-v1" rollout to finish: 1 out of 3 new replicas have been updated...
+```
+
+...and it just sits there. `kubectl get pods` shows why:
+
+```
+$ kubectl get pods
+NAME                       READY   STATUS             RESTARTS   AGE
+app-v1-7d8f9c6b5d-abcde    1/1     Running            0          5m
+app-v1-7d8f9c6b5d-fghij    1/1     Running            0          5m
+app-v1-9c5b7d8f6b-klmno    0/1     ImagePullBackOff   0          30s
+```
+
+The new Pod can never become Ready because its image can't even be pulled — so the rollout
+correctly refuses to proceed further (removing more old Pods would reduce capacity for no
+benefit, since the replacement will never come up). Nothing is "broken" in the platform; the
+platform is behaving exactly correctly given bad input.
+
+**The fix here is `kubectl rollout undo`, not waiting longer** — this exact scenario is what
+`deployment-rollback`'s Lab, later in ROOT_, gives you real hands-on practice with.
+
+## Instructor Notes
+
+**Demo script:** If time allows, run the healthy rollout live against a throwaway Deployment,
+then intentionally break the second one with a bad tag so students see `ImagePullBackOff` occur
+in real time rather than only in static text.
+
+**Approximate timing:** 8-10 minutes live; 5-7 minutes self-paced.
+
+**Common misconception to preempt:** students sometimes assume a stalled rollout will
+eventually time out and auto-rollback on its own. By default it will not — a Deployment has no
+automatic rollback trigger; a human (or automation) has to run `kubectl rollout undo` (or fix
+the underlying issue) explicitly. This is worth stating directly since it's a genuine and
+consequential production gotcha.
+
+**Optional extension:** ask what `kubectl rollout status --timeout=2m` would change about this
+scenario (answer: the command itself would exit with an error after 2 minutes instead of
+blocking forever — useful in CI/CD pipelines that need to fail a deploy step rather than hang).

content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/03-knowledge-check.md

@@ -0,0 +1,48 @@
+# Knowledge Check: Deployments & Rollouts
+
+---
+
+**1. A rolling update to a new image version has been "in progress" for 20 minutes with no
+error message, and `kubectl rollout status` never returns. What's the first thing you should
+check, and why?**
+
+*Answer:* `kubectl get pods` to see the new Pod's status, then `kubectl describe pod` on it if
+it isn't `Running`. A stalled rollout with no explicit error almost always means a new Pod can't
+become Ready — commonly `ImagePullBackOff` (bad image/tag) or a failing readiness probe. The
+rollout isn't broken; it's correctly refusing to proceed until the new Pod proves healthy.
+
+---
+
+**2. True or false: `kubectl rollout undo` restores your application from a backup of its
+previous state.**
+
+*Answer:* False. It scales the previous (still-present, just scaled-to-zero) ReplicaSet back up
+and the current one back down — the same rolling mechanism as a forward update, just pointed at
+an older, already-proven-working Pod template. Nothing is being restored from storage.
+
+---
+
+**3. A Deployment has `replicas: 3`. You need it to handle more traffic. Which is the correct
+action: edit the Pod template's resource limits, or change the replica count? Justify your
+answer for a stateless web application.**
+
+*Answer:* Change the replica count (scale out) for a stateless application handling more
+concurrent traffic — more identical copies sharing the load. Changing resource limits affects
+how much each individual Pod can use, not how many Pods exist; it doesn't add capacity for more
+concurrent requests the way scaling does.
+
+---
+
+**4. Why does a Deployment keep an old, scaled-to-zero ReplicaSet around instead of deleting it
+immediately after a successful rollout?**
+
+*Answer:* That scaled-down ReplicaSet is exactly what makes fast, safe rollback possible later —
+deleting it immediately would mean a "rollback" would have to rebuild the old Pod template from
+scratch (or fail entirely) instead of simply scaling existing, already-defined Pods back up.
+
+## Instructor Notes
+
+**Facilitation:** Question 1 is the most important one to discuss out loud — it's the exact
+diagnostic instinct students will need repeatedly in ROOT 10.
+
+**Approximate timing:** 5 minutes.

content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/04-guided-exercise-rollout-strategy.md

@@ -0,0 +1,54 @@
+# Guided Exercise: Planning a Safe Rollout Strategy
+
+Paper-and-thinking exercise — work through this before the Lab.
+
+## The scenario
+
+Your team runs `api-server`, a Deployment with 6 replicas serving live traffic. You need to
+ship a new image version. The team lead asks: "what could go wrong, and how would we know
+before it takes down the whole service?"
+
+## Your task
+
+Work through these questions:
+
+1. If the new image has a bug that crashes the container immediately on startup, at what point
+   in the rolling update would you expect to notice — after 1 new Pod, after all 6, or somewhere
+   in between? Why?
+2. What's the difference in blast radius between that crash-on-startup bug and a subtler bug
+   that only fails under load, several minutes after a Pod starts serving traffic?
+3. Given your answer to question 2, what's the practical value of watching `kubectl rollout
+   status` and `kubectl get pods` DURING a rollout, rather than only checking after it reports
+   "successfully rolled out"?
+4. If you noticed a problem partway through, what's the single command that gets you back to
+   the last known-good state fastest?
+
+## A worked answer to check yourself against
+
+1. After the FIRST new Pod — a crash-on-startup bug means the new Pod never becomes Ready
+   (`CrashLoopBackOff`), so the rollout stalls immediately, well before more old Pods are
+   removed. This is actually the SAFEST kind of bug, because the blast radius stays tiny.
+2. A crash-on-startup bug is naturally self-limiting (the rollout stalls itself, as above). A
+   bug that only appears under load is NOT self-limiting the same way — by the time it's
+   noticeable, several old (working) replicas may already have been replaced, meaning a larger
+   fraction of real traffic is already hitting the broken version.
+3. Watching during the rollout, not just checking the final "successfully rolled out" message,
+   is what lets you catch the load-dependent case in question 2 early — waiting for the final
+   status alone would let the rollout complete entirely (100% on the broken version) before you
+   noticed anything wrong.
+4. `kubectl rollout undo deployment/api-server` — assuming the previous ReplicaSet is still
+   present (the default), this is faster than trying to hand-diagnose and hot-fix the new
+   version under pressure.
+
+## Instructor Notes
+
+**Facilitation:** Question 2's distinction (self-limiting vs. not) is the core insight worth
+making sure lands — it's why "the rollout said success" is necessary but not sufficient
+evidence that a deploy actually went well.
+
+**Approximate timing:** 10-15 minutes live with discussion; 10 minutes self-paced.
+
+**Optional extension:** ask what monitoring/observability signal (beyond `kubectl` output) a
+real team would want during a rollout to catch the load-dependent case even faster (a good
+forward pointer to ROOT 10's observability themes, without needing to build any actual
+monitoring infrastructure here).

content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/05-lab-intro.md

@@ -0,0 +1,39 @@
+# Launch Lab: Perform a Rolling Update
+
+Time to run a real rolling update against a real Deployment in your disposable Lab.
+
+## What you're doing
+
+A Deployment `app-v1` is running an older image version. Your task is to update it to a newer
+version and confirm every replica ends up running the new image — exactly the mechanism from
+the lesson and demonstration, on a real cluster this time.
+
+## Before you start
+
+Recall the demonstration: `kubectl rollout status` is your tool for watching progress rather
+than repeatedly polling `kubectl get pods` yourself, and a stalled rollout with no obvious error
+usually means a new Pod can't become Ready. If your update seems to hang, that's exactly the
+diagnostic instinct from the knowledge check to apply.
+
+## Your task in this Lab
+
+Update the Deployment's image and verify all replicas are running the new version. Use
+`kubectl rollout status` to confirm completion, not just a single `kubectl get pods` snapshot.
+
+This Lab has its own in-context hints if you get stuck.
+
+When you're done, return to this module for a short reflection on what "successfully rolled
+out" actually guarantees — and doesn't.
+
+## Instructor Notes
+
+**Classroom flow:** A good moment to have students keep `kubectl get pods --watch` open in a
+second terminal (if their Lab environment supports multiple panes) so they see the incremental
+old-Pod/new-Pod transition happen live, reinforcing the demonstration.
+
+**Approximate timing:** 10-15 minutes.
+
+**Common mistake to watch for:** running `kubectl edit deployment` and forgetting to save/apply
+correctly, or editing the wrong field (e.g. `replicas` instead of the container image) — a good
+moment to reinforce reading the task description precisely rather than pattern-matching to a
+similar-looking previous Lab.

content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/06-reflection.md

@@ -0,0 +1,43 @@
+# Reflection: Rollback Is a Plan, Not a Panic Button
+
+You just completed a real rolling update. Take a few minutes to connect it to how this plays out
+in a real production team.
+
+## Reflection questions
+
+1. "Successfully rolled out" (from `kubectl rollout status`) tells you every replica is Running
+   and Ready. What does it NOT tell you about whether the new version is actually correct?
+2. If you were on-call and a rollout you just ran seemed to be causing problems, would you reach
+   for `kubectl rollout undo` immediately or try to hot-fix the new version first? What would
+   change your answer?
+3. Think back to the guided exercise's crash-on-startup vs. load-dependent distinction. Which
+   one would a typical automated health check (like a readiness probe, ROOT 10) catch, and
+   which one might slip through even with probes configured correctly?
+
+## Real Ops takeaway
+
+**A rollout completing is not the same as a deploy succeeding.** "Every Pod is Running and
+Ready" only proves the new code started up and passed whatever checks are configured — it says
+nothing about whether the new version is functionally correct under real traffic. Real teams
+pair a rollout with actual monitoring (error rates, latency) before calling a deploy genuinely
+successful, not just a green `kubectl rollout status`.
+
+**Rollback should be a rehearsed, low-drama action, not a last resort.** Teams that treat
+`kubectl rollout undo` as a normal, expected tool — something you reach for calmly the moment
+something looks wrong — recover from bad deploys in seconds. Teams that treat rollback as an
+admission of failure hesitate, try to hot-fix forward under pressure, and turn a small,
+recoverable mistake into a longer outage.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 2 is worth pushing on — many students'
+instinct is to try to fix forward, and it's worth surfacing WHY that instinct is often wrong
+under time pressure (unknown time-to-fix vs. known, fast rollback).
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
+
+**Optional extension:** ask students to write the one-sentence Slack message they'd post to
+their team the moment they decide to roll back a bad deploy — reinforces that rollback is a
+normal, communicable operational action, not a private failure.

content/root/root-06-kubernetes-application-workloads/m03-jobs-cronjobs-daemonsets/01-lesson-jobs-cronjobs-daemonsets.md

@@ -0,0 +1,85 @@
+# Jobs, CronJobs, and DaemonSets: The Other Workload Shapes
+
+Everything in the previous module assumed a long-running application that should always have N
+replicas up. Not every workload looks like that. Kubernetes has three other primitives for
+genuinely different shapes of work — using a Deployment for any of these would be the wrong
+tool, not just a less elegant one.
+
+## Job: run to completion, exactly once (or a fixed number of times)
+
+A Job creates one or more Pods and considers itself done when they exit successfully — it does
+NOT restart a Pod that exits with success, and it DOES retry one that fails, up to a configured
+limit. This is fundamentally different from a Deployment, which expects its Pods to run forever
+and treats any exit as something to replace.
+
+Use a Job for: a database migration, a batch data-processing task, a one-off cleanup script —
+anything with a defined "finished" state.
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: migrate-db
+spec:
+  template:
+    spec:
+      containers:
+      - name: migrate
+        image: myapp:latest
+        command: ["./migrate.sh"]
+      restartPolicy: Never
+  backoffLimit: 3
+```
+
+## CronJob: a Job, on a schedule
+
+A CronJob doesn't run Pods itself — it creates a new Job on a cron schedule (`schedule:
+"0 2 * * *"` for "every day at 2am"), and that Job behaves exactly as described above. Use a
+CronJob for anything that should run periodically and finish: nightly backups, scheduled
+reports, periodic cleanup.
+
+A CronJob that reliably fails to complete (an image that always crashes, for example) will keep
+creating new Jobs on schedule, each failing the same way — this is a real, common way to
+silently exhaust cluster resources (job/pod history accumulating) if nobody's watching.
+
+## DaemonSet: exactly one Pod per node, automatically
+
+A DaemonSet doesn't declare a replica count at all — it ensures exactly one matching Pod runs
+on every node in the cluster (or every node matching a selector), and automatically adds a Pod
+when a new node joins. Use a DaemonSet for per-node infrastructure: a log-shipping agent, a
+node-level monitoring exporter, a network plugin component — things that fundamentally need to
+exist once per machine, not "N copies somewhere."
+
+## The decision in one pass
+
+| You need... | Use |
+|---|---|
+| Always-on, N identical copies, restarted forever | Deployment |
+| Run once (or a few times) until it finishes successfully | Job |
+| The above, but on a recurring schedule | CronJob |
+| Exactly one copy on every node | DaemonSet |
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read; 10 minutes live.
+
+**Demo plan (if extending this PARTIAL module later):** live-create a Job with a command that
+deliberately fails once then succeeds (`backoffLimit: 2`), and watch `kubectl get pods` show
+the failed attempt alongside the eventual successful one — makes the retry-until-backoffLimit
+behavior concrete.
+
+**Likely misconceptions to watch for:**
+- Students often assume a Job that finishes successfully gets cleaned up automatically. It
+  doesn't by default — the completed Pod/Job objects remain until manually deleted or a
+  `ttlSecondsAfterFinished` is configured (not covered here, worth a one-line mention if asked).
+- "DaemonSet" is sometimes confused with "one Pod, cluster-wide" (singular). It's the opposite —
+  one Pod PER NODE, which can be many Pods total in a multi-node cluster.
+
+**Discussion question:** "Why doesn't a Deployment support 'run once and be done'?" (Answer: a
+Deployment's whole contract is maintaining a standing replica count forever — repurposing it for
+one-shot work would fight that contract rather than use a primitive designed for it.)
+
+**Optional extension:** ask what would go wrong if a CronJob's schedule ran more often than a
+single Job execution takes to complete (answer: overlapping Job runs, unless
+`concurrencyPolicy` is set to `Forbid` or `Replace` — a real gotcha worth naming even without
+building a full lab around it).

content/root/root-06-kubernetes-application-workloads/m03-jobs-cronjobs-daemonsets/02-knowledge-check.md

@@ -0,0 +1,45 @@
+# Knowledge Check: Choosing the Right Workload Primitive
+
+---
+
+**1. You need to run a database migration script exactly once when a new version deploys. Which
+primitive fits, and why not a Deployment?**
+
+*Answer:* A Job. A Deployment expects its Pods to run forever and replaces any that exit; a
+migration script is supposed to exit successfully when done, which a Deployment would treat as
+a failure to "fix" by restarting it — the wrong behavior for a task that's supposed to finish.
+
+---
+
+**2. A CronJob scheduled for "every 5 minutes" keeps creating Jobs that fail immediately due to
+a bad image tag. What actually happens over the next hour if nobody notices?**
+
+*Answer:* A new failing Job (and its Pod) gets created roughly every 5 minutes, accumulating
+failed Job/Pod objects and consuming cluster resources — nothing stops this automatically. This
+is exactly the kind of slow, easy-to-miss resource exhaustion a real on-call engineer should
+watch for.
+
+---
+
+**3. True or false: a DaemonSet's Pod count scales with a `replicas` field, the same as a
+Deployment.**
+
+*Answer:* False. A DaemonSet has no `replicas` field — its Pod count is implicitly "one per
+matching node," and it grows or shrinks automatically as nodes join or leave the cluster.
+
+---
+
+**4. You need a log-shipping agent that must run on every node, including any new node added
+later. Which primitive, and what would go wrong if you used a Deployment with a high replica
+count instead?**
+
+*Answer:* A DaemonSet. A Deployment's replicas are placed by the scheduler wherever it decides
+is best — nothing guarantees one per node, and a newly-added node wouldn't automatically get a
+copy the way a DaemonSet guarantees.
+
+## Instructor Notes
+
+**Facilitation:** Question 2 is worth emphasizing — it's a genuinely realistic "how does a
+cluster quietly get into trouble" scenario, not just trivia.
+
+**Approximate timing:** 5 minutes.

content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/01-lesson-services.md

@@ -0,0 +1,87 @@
+# The Service/Endpoints/DNS Request Path
+
+## The problem: Pod IPs are not stable
+
+Every Pod gets its own IP address, but that IP is NOT durable — when a Pod is replaced (a
+rollout, a crash recovery, a reschedule), the new Pod gets a brand new IP. If another part of
+your application had that old IP hardcoded, it would silently start talking to nothing. This is
+the exact problem in `expose-service-basics`'s scenario: "other pods cannot reliably connect
+because pod IPs change when they restart."
+
+## A Service: a stable address in front of a moving set of Pods
+
+A Service is a stable virtual IP and DNS name that automatically routes to whichever Pods
+currently match its label selector — regardless of how many there are or how often they change.
+You never talk to a Pod's IP directly in normal operation; you talk to the Service, and the
+Service's Endpoints (a live, continuously-updated list of the matching Pods' IPs) determines
+where traffic actually goes.
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: redis-svc
+spec:
+  selector:
+    app: redis        # <- matches Pods by label, same mechanism from ROOT 05
+  ports:
+  - port: 6379
+```
+
+This is the same label-selector mechanism you learned in ROOT 05 — a Service doesn't know or
+care about specific Pod names, only which Pods currently carry a matching label.
+
+## The three Service types you'll use most
+
+- **ClusterIP** (the default) — reachable only from inside the cluster. Use this for
+  internal-only communication, like one microservice talking to another or to a database.
+- **NodePort** — additionally exposes the Service on a static port on every node's own IP,
+  reachable from outside the cluster. Mostly used for development/testing or when there's no
+  cloud load balancer available.
+- **LoadBalancer** — asks the cloud provider to provision a real external load balancer pointed
+  at the Service. This is the standard way to expose something to the public internet on a
+  cloud-hosted cluster.
+
+Choosing wrong isn't just a style preference — a ClusterIP Service is architecturally
+unreachable from outside the cluster no matter how correctly everything else is configured.
+
+## DNS: how Pods actually find a Service by name
+
+Every Service automatically gets a DNS name inside the cluster
+(`<service-name>.<namespace>.svc.cluster.local`, or usually just `<service-name>` from within
+the same Namespace) — this is why application code can use a plain hostname like `redis-svc`
+instead of an IP address at all. Kubernetes' internal DNS resolves that name to the Service's
+stable virtual IP, which then routes to whichever Pods are currently healthy.
+
+## The full request path, end to end
+
+```
+Client  ->  DNS lookup "redis-svc"  ->  Service's stable virtual IP
+        ->  Service consults its Endpoints (live list of matching, ready Pods)
+        ->  traffic forwarded to one of those Pod IPs
+```
+
+Every one of these steps can fail independently, which is exactly why "the app can't reach
+redis" requires checking each layer rather than guessing — the next activity shows you what
+that looks like when the Endpoints layer is empty.
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read, 10-12 minutes live with the request-path diagram.
+
+**Demo plan:** Before the next activity, it's worth live-running `kubectl get endpoints
+<service-name>` against a healthy Service so students see a populated Endpoints list before
+they see an empty one in the demonstration.
+
+**Likely misconceptions to watch for:**
+- Students often think a Service "is" a load balancer process running somewhere. It's closer to
+  a routing rule maintained by `kube-proxy` on every node — worth clarifying that there's no
+  single "Service Pod" to go find and debug.
+- ClusterIP vs. NodePort vs. LoadBalancer is sometimes memorized without the "why" — the
+  knowledge check's Service-type question is designed to test the underlying reasoning, not
+  just recall.
+
+**Discussion question:** "If a Service's selector matches zero Pods, does the Service itself
+fail to exist?" (Answer: no — the Service object exists fine; its Endpoints list is just empty,
+which looks like connection failure from the client's side without any error at the Service
+level itself. This is exactly the next activity's topic.)

content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/02-demonstration-zero-endpoints.md

@@ -0,0 +1,82 @@
+# Demonstration: A Service With Zero Endpoints
+
+This is one of the most common "it just doesn't work" incidents in real Kubernetes operation —
+and it produces no error message at all at the Service level.
+
+## The setup
+
+A Service `api-svc` selects Pods labeled `app: api`. A Deployment was recently updated and its
+Pods now carry the label `app: api-v2` instead (a rename during a refactor, deliberately or
+accidentally).
+
+## What you'd see from the client side
+
+```
+$ curl http://api-svc:8080/health
+curl: (7) Failed to connect to api-svc port 8080: Connection refused
+```
+
+Just a generic connection failure — nothing here says "your Service's selector doesn't match
+any Pods."
+
+## What the Service object itself shows
+
+```
+$ kubectl get service api-svc
+NAME      TYPE        CLUSTER-IP     PORT(S)    AGE
+api-svc   ClusterIP   10.96.34.201   8080/TCP   2h
+```
+
+Completely normal-looking. The Service exists, has a stable IP, is not in any kind of "error"
+state — because from the Service's own perspective, nothing is wrong. It's doing exactly what
+it's configured to do: route to whatever matches its selector, which currently happens to be
+nothing.
+
+## Where the real evidence is: Endpoints
+
+```
+$ kubectl get endpoints api-svc
+NAME      ENDPOINTS   AGE
+api-svc   <none>      2h
+```
+
+This is the actual signal. `<none>` means the Service's selector currently matches zero Pods —
+this is the single fastest check for "is this a Service-to-Pod mismatch" any time something
+reachable-in-principle looks like a connection failure.
+
+## Confirming the mismatch
+
+```
+$ kubectl get pods --show-labels
+NAME                     READY   STATUS    LABELS
+api-abc123                1/1    Running   app=api-v2
+```
+
+The Pod is healthy and running — `app=api-v2`, not `app=api`. The Service's selector
+(`app: api`) matches nothing, and nothing about the Pod itself is broken.
+
+## The general diagnostic shape
+
+`curl`/application-level connection failure tells you *that* something's wrong, but nothing
+about *where*. `kubectl get endpoints <service>` is the fastest way to distinguish "the Service
+has no matching Pods" from "the Pods exist and are ready but something else is wrong" —
+reach for it early whenever a Service-fronted connection fails for no obvious reason.
+
+## Instructor Notes
+
+**Demo script:** Live-create this exact mismatch (a Service with one selector, a Deployment
+with a slightly different label) and walk through `kubectl get service` -> `kubectl get
+endpoints` -> `kubectl get pods --show-labels` in front of the class, narrating what each
+command is and isn't telling you.
+
+**Approximate timing:** 8-10 minutes live; 5-7 minutes self-paced.
+
+**Common misconception to preempt:** students often check the Service object first and, seeing
+nothing obviously wrong, assume the problem must be elsewhere entirely (DNS, firewall, the
+application itself) — reinforce that `kubectl get endpoints` is the specific, fast check for
+this exact failure mode, before reaching for anything more complex.
+
+**Optional extension:** ask what `kubectl describe service api-svc` would additionally show
+compared to `kubectl get service` (answer: the same selector the Service is using, which lets
+you directly compare it against `kubectl get pods --show-labels`'s actual Pod labels side by
+side, rather than inferring the mismatch).

content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/03-knowledge-check.md

@@ -0,0 +1,47 @@
+# Knowledge Check: Services & Service Discovery
+
+---
+
+**1. A Deployment has three replicas but `kubectl get endpoints` shows `<none>` for its Service.
+Which part of the system should you inspect first, and why?**
+
+*Answer:* Compare the Service's selector (`kubectl describe service`) against the actual Pods'
+labels (`kubectl get pods --show-labels`) — a Service with a healthy backend Deployment but zero
+Endpoints almost always means the selector doesn't match the Pods' current labels, not that the
+Pods themselves are unhealthy.
+
+---
+
+**2. You need a microservice reachable ONLY from other services inside the same cluster, never
+from the public internet. Which Service type, and why not LoadBalancer?**
+
+*Answer:* ClusterIP — it's reachable only from inside the cluster by design, which is exactly
+the requirement. A LoadBalancer would provision a real external endpoint reachable from the
+public internet, which is more exposure than the requirement calls for, and depends on cloud
+provider support this scenario doesn't need.
+
+---
+
+**3. True or false: application code that connects to `redis-svc` by that plain hostname is
+relying on Kubernetes' internal DNS to resolve it.**
+
+*Answer:* True. Every Service automatically gets a DNS name; that's specifically what lets code
+use a stable hostname instead of hardcoding a Pod IP that could change at any time.
+
+---
+
+**4. A Service's Endpoints list is non-empty, but the application still can't connect. Does
+this rule out a Service-level problem entirely?**
+
+*Answer:* Not entirely — a non-empty Endpoints list means at least one Pod currently matches the
+selector, but the connection could still fail for other reasons (wrong port number on the
+Service, a NetworkPolicy blocking the traffic, the application inside the Pod not actually
+listening). A populated Endpoints list narrows the problem, it doesn't prove the whole path
+works.
+
+## Instructor Notes
+
+**Facilitation:** Question 1 is the single most transferable diagnostic habit from this module —
+worth explicitly calling out as "the first thing to check" for this entire class of problem.
+
+**Approximate timing:** 5 minutes.

content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/04-guided-exercise-service-type.md

@@ -0,0 +1,49 @@
+# Guided Exercise: Choosing the Right Service Type
+
+Paper-and-thinking exercise before the Lab.
+
+## The scenario
+
+You're deploying three components for a class project on a cloud-hosted cluster:
+
+1. A Postgres database that only your own backend application should ever talk to.
+2. A backend API that the frontend (also running in the cluster) calls internally.
+3. The frontend web application itself, which needs to be reachable by users on the public
+   internet.
+
+## Your task
+
+For each of the three components, decide: ClusterIP, NodePort, or LoadBalancer — and justify
+each choice in one sentence referencing WHO needs to reach it.
+
+## A worked answer to check yourself against
+
+1. **Postgres — ClusterIP.** Only your own backend (running inside the same cluster) needs to
+   reach it; there is no reason for it to be reachable from outside the cluster at all, and
+   exposing a database externally is a real, avoidable security risk.
+2. **Backend API — ClusterIP.** The frontend calls it from inside the cluster too — same
+   reasoning as the database. External users never talk to the backend directly; they only ever
+   go through the frontend.
+3. **Frontend — LoadBalancer** (on a real cloud-hosted cluster). Public internet users need to
+   reach it, and a cloud provider's LoadBalancer is the standard mechanism for that. NodePort
+   would technically work but is typically used for development/testing rather than a real
+   public-facing service on a cloud cluster.
+
+## Self-check
+
+If you chose LoadBalancer for the database or the backend API, reconsider — "internet-reachable
+by default" is not the safe default for anything that doesn't need to be, and getting this
+choice right the first time avoids a real security exposure later, not just a style issue.
+
+## Instructor Notes
+
+**Facilitation:** Push on the "why not just LoadBalancer everything, it works" instinct some
+students will have — this is a good early moment to connect Service-type choice to the security
+mindset that ROOT 09 builds on more fully (exposure should be intentional, not the path of
+least resistance).
+
+**Approximate timing:** 10 minutes live with discussion; 10 minutes self-paced.
+
+**Optional extension:** ask what would need to be added (not covered in this module) to let
+public users reach the frontend at a real domain name over HTTPS rather than a bare
+LoadBalancer IP — a natural forward pointer to Ingress, covered in the next module.

content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/05-lab-intro.md

@@ -0,0 +1,40 @@
+# Launch Lab: Exposing an Application
+
+Time to create a real Service in your disposable Lab and connect it to a real Deployment.
+
+## What you're doing
+
+A `redis` Deployment is running, but other Pods can't reliably reach it because Pod IPs change
+whenever a Pod restarts — exactly the problem the lesson opened with. Your task is to create a
+stable ClusterIP Service in front of it.
+
+## Before you start
+
+Recall the request path from the lesson: your Service's `selector` has to match the Deployment
+Pods' actual labels, or you'll end up with the empty-Endpoints situation from the
+demonstration. Check the Deployment's Pod labels before writing your Service's selector, don't
+guess at them.
+
+## Your task in this Lab
+
+Create a ClusterIP Service exposing the `redis` Deployment on the correct port. Once it's
+created, verify it the same way the demonstration did: `kubectl get service`, then `kubectl get
+endpoints` to confirm it actually has a non-empty Endpoints list, not just that the Service
+object exists.
+
+This Lab has its own in-context hints if you get stuck.
+
+When you're done, return to this module for a reflection on why service discovery is
+infrastructure, not magic.
+
+## Instructor Notes
+
+**Classroom flow:** Encourage students to run `kubectl get endpoints` as their OWN verification
+step even though the Lab's automated validation will check this too — building the habit of
+checking Endpoints, not just "the Service exists," is the actual transferable skill here.
+
+**Approximate timing:** 10-15 minutes.
+
+**Common mistake to watch for:** a selector that matches on the wrong label key/value, or a
+port/targetPort mismatch (the Service's `port` is what clients connect to; `targetPort` is what
+the container actually listens on — conflating the two is a very common first-time error).

content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/06-reflection.md

@@ -0,0 +1,40 @@
+# Reflection: Service Discovery Is Infrastructure, Not Magic
+
+You just created a Service that gives a moving set of Pods a stable address. Take a few minutes
+to connect this to real operational thinking.
+
+## Reflection questions
+
+1. Before this module, "the app can just connect to redis by name" might have seemed obvious or
+   automatic. What specific mechanism actually makes that true, and what would break it?
+2. If your Service's selector had been wrong (matching zero Pods), what would the SYMPTOM have
+   looked like from the application's side, versus what the actual CAUSE would have been?
+3. Why is checking `kubectl get endpoints` before assuming a networking/DNS/firewall problem a
+   good default habit, given how common a selector mismatch actually is?
+
+## Real Ops takeaway
+
+**"It's probably a networking issue" is often wrong, and Endpoints is how you find out fast.** A
+huge fraction of real "service X can't reach service Y" incidents in Kubernetes are Service
+selector mismatches, not actual network problems — checking `kubectl get endpoints` first, before
+escalating to firewall rules or DNS debugging, saves real time precisely because this failure
+mode produces zero errors at the layers people instinctively check first.
+
+**Stable addressing is what makes rolling updates and self-healing actually usable.** Everything
+you learned in ROOT 06 about Pods being replaced during a rollout or after a crash only works
+smoothly in practice because Services give callers a stable target that survives those
+replacements — without this layer, every Pod replacement would require updating every caller's
+configuration by hand.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** use question 2 as a discussion prompt — the
+symptom/cause gap is exactly why this class of bug is often under-diagnosed in real teams.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
+
+**Optional extension:** ask students to write the one-line runbook entry they'd want a future
+on-call engineer to have for "Service X seems unreachable" — a good exercise in turning a
+lesson into something operationally reusable.

content/root/root-07-kubernetes-networking-config/m04-ingress-networkpolicy-foundations/01-lesson-ingress-networkpolicy.md

@@ -0,0 +1,90 @@
+# Ingress and NetworkPolicy: What They Architecturally Do
+
+## Ingress: routing external HTTP(S) traffic by host/path
+
+You already know a LoadBalancer Service can expose something to the public internet. But a real
+application usually needs more than "one raw IP to one Service" — you might want
+`api.example.com` and `app.example.com` to route to different backend Services, all through one
+entry point, with TLS termination handled in one place instead of per-Service.
+
+**Ingress** is the Kubernetes object for exactly this: a set of HTTP routing rules (by hostname
+and/or URL path) that an Ingress controller reads and turns into actual load-balancer/proxy
+configuration.
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: app-ingress
+spec:
+  rules:
+  - host: app.example.com
+    http:
+      paths:
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: frontend-svc
+            port: { number: 80 }
+```
+
+An important distinction: Ingress is a set of ROUTING RULES, not a load balancer itself — an
+Ingress controller (a separate piece of software running in the cluster) is what actually reads
+these rules and does the routing. Without a controller installed, an Ingress object exists in
+the API but nothing acts on it.
+
+## NetworkPolicy: traffic reachability as something you declare, not assume
+
+By default, every Pod in a Kubernetes cluster can reach every other Pod — there is no built-in
+network isolation between them at all. This surprises people coming from a "obviously the
+network is locked down unless configured otherwise" assumption. It is exactly backwards from
+that assumption: **everything is reachable until you say otherwise.**
+
+A NetworkPolicy changes this for the Pods it selects, by declaring which traffic IS allowed —
+everything not explicitly allowed to a Pod covered by at least one NetworkPolicy is then denied.
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-frontend-to-backend
+spec:
+  podSelector:
+    matchLabels: { app: backend }
+  ingress:
+  - from:
+    - podSelector:
+        matchLabels: { app: frontend }
+```
+
+This example allows traffic to `backend` Pods only from `frontend` Pods — once this policy
+exists and selects `backend`, every OTHER Pod trying to reach `backend` is now blocked, even
+though nothing was true about that before the policy existed.
+
+## Why this matters architecturally, before it matters as a security control
+
+Right now, think of NetworkPolicy purely as "declaring intended reachability, not assuming it."
+ROOT 09 comes back to NetworkPolicy specifically as a SECURITY control (default-deny postures,
+least-privilege network access) — this module is deliberately just the architectural mental
+model: Kubernetes doesn't isolate network traffic for you by default, and NetworkPolicy is the
+mechanism for declaring the reachability you actually intend.
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read; 10 minutes live.
+
+**Likely misconceptions to watch for:**
+- Students often assume Ingress by itself "does" the routing. Emphasize the controller
+  requirement — an Ingress object with no controller installed does nothing.
+- The "everything reachable by default" fact genuinely surprises most students the first time
+  they hear it — it's worth stating plainly and letting it land rather than rushing past it.
+
+**Discussion question:** "If NO NetworkPolicy exists anywhere in a Namespace, what's the actual
+reachability between Pods in that Namespace?" (Answer: completely open — every Pod can reach
+every other Pod, matching the "everything reachable by default" rule.)
+
+**Optional extension:** ask what would happen if you created a NetworkPolicy that selects
+`frontend` Pods but declares no `ingress` rules at all (answer: `frontend` Pods would become
+completely unreachable by anything — an empty ingress list inside a NetworkPolicy that HAS an
+ingress policyType means "deny all incoming," not "no policy applies").

content/root/root-07-kubernetes-networking-config/m04-ingress-networkpolicy-foundations/02-knowledge-check.md

@@ -0,0 +1,46 @@
+# Knowledge Check: Ingress & NetworkPolicy Foundations
+
+---
+
+**1. You create an Ingress object with correct routing rules, but no traffic is ever routed
+according to them. What's the most likely reason?**
+
+*Answer:* No Ingress controller is installed/running in the cluster. Ingress objects are just
+routing rules; a separate controller has to actually read and act on them, or nothing happens.
+
+---
+
+**2. True or false: by default, a Pod in Namespace A cannot reach a Pod in Namespace B unless a
+NetworkPolicy explicitly allows it.**
+
+*Answer:* False — the opposite is true by default. With NO NetworkPolicy in place at all,
+every Pod can reach every other Pod regardless of Namespace. NetworkPolicy is what RESTRICTS
+this default-open behavior, not what's required to enable connectivity in the first place.
+
+---
+
+**3. A NetworkPolicy selects Pods labeled `app: backend` and declares one ingress rule allowing
+traffic from Pods labeled `app: frontend`. What happens to traffic from a Pod labeled
+`app: admin-tool` trying to reach `backend`?**
+
+*Answer:* It's blocked. Once a NetworkPolicy selects a Pod, only traffic matching one of its
+explicit rules is allowed — everything else to that Pod is denied, including traffic that would
+have worked fine before the policy existed.
+
+---
+
+**4. Why is Ingress the right tool for exposing an HTTP application by hostname, rather than
+creating a separate LoadBalancer Service per hostname?**
+
+*Answer:* A LoadBalancer Service typically provisions its own external IP/load balancer per
+Service — one per hostname would mean paying for and managing N separate external endpoints.
+Ingress lets one entry point route to many backend Services by hostname/path, which is both
+cheaper and centralizes concerns like TLS termination.
+
+## Instructor Notes
+
+**Facilitation:** Question 2 catches a very common and consequential misconception — worth
+confirming out loud that everyone actually updated their mental model, not just guessed
+correctly.
+
+**Approximate timing:** 5 minutes.

content/root/root-08-kubernetes-storage-scheduling/m01-storage-fundamentals/01-lesson-storage-fundamentals.md

@@ -0,0 +1,74 @@
+# Ephemeral vs. Persistent Storage
+
+## The default: a container's filesystem is thrown away
+
+By default, anything a container writes to its own filesystem disappears the moment that
+container is replaced — a crash, a rollout, a reschedule, anything. This is a deliberate design
+choice (it's part of what makes a Pod safely disposable/replaceable), but it means "just write
+files to disk" silently loses data unless you use one of Kubernetes' actual storage mechanisms.
+
+## emptyDir: shared, but still temporary
+
+An `emptyDir` volume gives a Pod's containers a shared directory that survives a container
+restart WITHIN the same Pod, but is deleted the moment the Pod itself is removed. It's the right
+tool for two containers in one Pod that need to share files with each other (a sidecar writing
+logs another container reads, for example) — not for anything that needs to outlive the Pod.
+
+```yaml
+volumes:
+- name: shared-data
+  emptyDir: {}
+```
+
+## PersistentVolume & PersistentVolumeClaim: storage that outlives the Pod
+
+A **PersistentVolume (PV)** represents an actual piece of storage (a cloud disk, an NFS share,
+whatever the cluster's infrastructure provides) as a Kubernetes object. A
+**PersistentVolumeClaim (PVC)** is a Pod's REQUEST for storage matching some criteria (size,
+access mode) — the Pod references the PVC, not a PV directly, and Kubernetes binds the PVC to a
+matching PV.
+
+```
+Pod  ──references──>  PVC ("I need 5Gi, ReadWriteOnce")  ──binds to──>  PV (actual storage)
+```
+
+This indirection matters: a Pod's manifest doesn't need to know or care exactly which physical
+storage backs its PVC — that's resolved separately, and the same PVC keeps working even if the
+Pod behind it is replaced.
+
+## StorageClass & dynamic provisioning
+
+Manually creating a PV for every PVC doesn't scale. A **StorageClass** describes a category of
+storage (e.g. "fast SSD" vs. "cheap archival") and, when a PVC requests that class, the cluster
+can automatically provision a matching PV on demand — this is "dynamic provisioning," and it's
+the normal way storage works on any real cloud-hosted cluster. A StorageClass also controls the
+**reclaim policy** — what happens to the underlying storage after its PVC is deleted (`Delete`
+the data, or `Retain` it for manual recovery).
+
+## The decision in one pass
+
+| You need... | Use |
+|---|---|
+| Temporary scratch space shared between containers in ONE Pod | `emptyDir` |
+| Storage that survives Pod replacement, manually provisioned | PV + PVC |
+| The above, provisioned automatically on demand | PVC + StorageClass (dynamic provisioning) |
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read; 10 minutes live with the PV/PVC/StorageClass diagram.
+
+**Likely misconceptions to watch for:**
+- Students often assume `emptyDir` is "persistent" because the name doesn't obviously say
+  otherwise. Be explicit: it survives a CONTAINER restart, not a POD deletion.
+- The PV/PVC indirection can seem like unnecessary ceremony at first — frame it as the same
+  "declare what you want, let the system resolve it" pattern from ROOT 05's desired-state
+  lesson, applied to storage instead of Pod count.
+
+**Discussion question:** "If a Pod using a PVC is deleted and replaced, what happens to its
+data?" (Answer: it's preserved — the PVC and its bound PV are separate objects from the Pod,
+and a new Pod referencing the same PVC picks up right where the data was left, which is the
+entire point of using persistent storage over `emptyDir`.)
+
+**Optional extension:** ask what a `Retain` reclaim policy is protecting against, compared to
+`Delete` (answer: accidental data loss from deleting a PVC by mistake — `Retain` keeps the
+underlying storage around for manual recovery instead of immediately destroying it).

content/root/root-08-kubernetes-storage-scheduling/m01-storage-fundamentals/02-knowledge-check.md

@@ -0,0 +1,44 @@
+# Knowledge Check: Storage Fundamentals
+
+---
+
+**1. Two containers in the same Pod need to share files with each other, but nothing needs to
+survive the Pod being replaced. What's the simplest correct choice?**
+
+*Answer:* `emptyDir` — shared within the Pod, deliberately temporary, exactly matching the
+requirement. Reaching for a PV/PVC here would be more machinery than the problem needs.
+
+---
+
+**2. A Pod using a PVC is deleted and a new Pod is created referencing the SAME PVC. What
+happens to the data?**
+
+*Answer:* It's preserved. The PVC and its bound PV exist independently of any specific Pod — the
+new Pod picks up exactly where the data was left, which is the entire reason to use persistent
+storage instead of `emptyDir` for anything that needs to outlive a single Pod's lifetime.
+
+---
+
+**3. True or false: a Pod's manifest must specify exactly which PersistentVolume backs its
+storage request.**
+
+*Answer:* False. A Pod references a PVC (a request), not a PV directly — the binding between
+PVC and an actual PV is resolved separately, which is exactly the indirection that lets the same
+Pod manifest work regardless of which physical storage ends up behind it.
+
+---
+
+**4. What does a StorageClass's reclaim policy actually control, and why would a team choose
+`Retain` over `Delete` for a production database's storage?**
+
+*Answer:* It controls what happens to the underlying storage after its PVC is deleted. `Retain`
+keeps the data around for manual recovery instead of immediately destroying it — a safety
+margin against an accidental `kubectl delete pvc` on something genuinely important, at the cost
+of needing manual cleanup later.
+
+## Instructor Notes
+
+**Facilitation:** Question 2 is worth confirming lands correctly — it's the single fact that
+justifies the entire PV/PVC indirection existing at all.
+
+**Approximate timing:** 5 minutes.

content/root/root-08-kubernetes-storage-scheduling/m02-scheduling-resource-governance/01-lesson-scheduling.md

@@ -0,0 +1,86 @@
+# How the Scheduler Places Pods, and How Governance Shapes It
+
+## The scheduler's job
+
+Every time a new Pod needs to run, the scheduler decides which node it lands on — you never
+manually assign a Pod to a node in normal operation (ROOT 05's mental model). By default, the
+scheduler picks based on available resources (does this node have enough free CPU/memory), but
+several mechanisms let you INFLUENCE or CONSTRAIN that decision when the default isn't good
+enough.
+
+## Steering placement: nodeSelector, taints/tolerations, affinity
+
+- **nodeSelector** — the simplest constraint: "only schedule this Pod on nodes with THIS
+  label" (e.g. `disktype: ssd`). A blunt but clear tool.
+- **Taints and tolerations** — the inverse relationship. A NODE is tainted (marked "don't
+  schedule here unless you specifically tolerate this taint") and a Pod TOLERATES a specific
+  taint to be allowed to land there anyway. Commonly used to reserve nodes for specific
+  workloads (e.g. GPU nodes tainted so only GPU-requiring Pods land there) or to keep general
+  workloads off nodes reserved for something else.
+- **Affinity/anti-affinity** — more expressive rules: "prefer/require scheduling near Pods with
+  label X" (affinity) or "prefer/require scheduling AWAY from Pods with label X"
+  (anti-affinity). A common real use: anti-affinity between replicas of the same application, so
+  a single node failure can't take down every replica at once.
+
+## Priority: which Pods matter more when resources are tight
+
+A **PriorityClass** lets you mark some Pods as more important than others. When the cluster is
+under resource pressure, a higher-priority pending Pod can even cause a lower-priority RUNNING
+Pod to be evicted (preempted) to make room — this is a real, consequential mechanism, not just a
+scheduling hint, and misconfiguring it can mean an unimportant batch job unexpectedly evicts
+something that actually mattered.
+
+## PodDisruptionBudget: protecting against VOLUNTARY disruption
+
+A **PodDisruptionBudget (PDB)** limits how many replicas of an application can be taken down
+AT ONCE during voluntary disruptions — a node drain for maintenance, a cluster upgrade — by
+declaring a minimum number (or percentage) that must stay available. This does NOT protect
+against involuntary disruption (a node crashing unexpectedly) — it specifically constrains
+operations that Kubernetes itself controls the timing of.
+
+```yaml
+apiVersion: policy/v1
+kind: PodDisruptionBudget
+metadata:
+  name: web-pdb
+spec:
+  minAvailable: 2
+  selector:
+    matchLabels: { app: web }
+```
+
+Without a PDB, a node drain during routine maintenance could legally take down every replica of
+`web` simultaneously if they all happened to be on nodes being drained together — a PDB is what
+prevents that from being "technically allowed."
+
+## ResourceQuota & LimitRange: governance at the Namespace level
+
+A **ResourceQuota** caps the TOTAL resources (CPU, memory, object counts) a Namespace can
+consume — useful for multi-team clusters where one team's runaway workload shouldn't be able to
+starve everyone else. A **LimitRange** sets DEFAULT and/or min/max resource requests/limits for
+individual containers within a Namespace, so a Pod created without explicit resource settings
+still gets sensible ones rather than none at all.
+
+## Instructor Notes
+
+**Approximate timing:** 20 minutes read; 15 minutes live given the number of concepts covered.
+
+**Likely misconceptions to watch for:**
+- Taints/tolerations are frequently confused with affinity — clarify the directionality: a
+  taint REPELS by default (node says no); a toleration is what lets a specific Pod through
+  anyway. Affinity is the Pod expressing a preference, not the node restricting access.
+- Students sometimes assume a PDB prevents ALL disruption. Be explicit that it only constrains
+  VOLUNTARY disruption (things Kubernetes/an operator controls the timing of) — a hardware
+  failure ignores PDBs entirely, because nobody is "asking permission" for a crash.
+
+**Discussion question:** "Why would a real team use anti-affinity between replicas of the same
+application instead of just trusting the scheduler's default spread?" (Answer: the default
+scheduler does consider spread as one factor among several, but doesn't GUARANTEE it the way an
+explicit anti-affinity rule does — for something where "don't lose all replicas to one node
+failure" is a hard requirement, not just a nice-to-have, an explicit rule is safer than an
+implicit tendency.)
+
+**Optional extension:** ask what would happen to a Namespace's Pods if a ResourceQuota were
+added AFTER Pods without explicit resource requests already existed there (a good bridge to why
+LimitRange defaults matter — a Quota alone doesn't retroactively fix Pods created without
+resource requests, it just constrains what NEW Pods can consume going forward).

content/root/root-08-kubernetes-storage-scheduling/m02-scheduling-resource-governance/02-knowledge-check.md

@@ -0,0 +1,48 @@
+# Knowledge Check: Scheduling & Resource Governance
+
+---
+
+**1. A node is tainted `dedicated=gpu:NoSchedule`. A Pod with no matching toleration is
+pending and never gets scheduled anywhere else, even though other untainted nodes have free
+capacity. What's actually going on?**
+
+*Answer:* Nothing is wrong — the taint only affects the tainted node specifically; it doesn't
+explain why the Pod isn't landing elsewhere. If it's stuck pending entirely, the cause is
+something else (insufficient resources cluster-wide, a nodeSelector/affinity rule that can't be
+satisfied anywhere) — the taint itself only ever repels from the ONE node it's applied to.
+
+---
+
+**2. During a planned node drain for maintenance, would you expect a PodDisruptionBudget to
+prevent an UNRELATED node from crashing unexpectedly at the same time?**
+
+*Answer:* No. A PDB only constrains VOLUNTARY disruptions — operations Kubernetes/an operator
+controls the timing of, like a drain. An unrelated hardware failure is involuntary and ignores
+PDBs entirely; nothing is "asking permission" for a crash.
+
+---
+
+**3. True or false: a higher-priority pending Pod can cause a lower-priority, already-RUNNING
+Pod to be evicted to make room.**
+
+*Answer:* True — this is what Pod priority/preemption actually does under resource pressure,
+not just a scheduling hint. Misconfigured priorities can have real, disruptive consequences for
+this reason.
+
+---
+
+**4. A team notices new Pods in their Namespace keep getting created with no CPU/memory
+requests at all, even though nobody set that intentionally. What governance mechanism would fix
+this going forward, and what would it NOT fix?**
+
+*Answer:* A LimitRange with default requests/limits would apply sensible defaults to future
+Pods created without explicit values. It would NOT retroactively change Pods that already exist
+— it only affects new Pod creation from the point it's added.
+
+## Instructor Notes
+
+**Facilitation:** Question 2 reinforces a genuinely important, often-missed distinction
+(voluntary vs. involuntary disruption) — worth confirming it lands, not just that the answer was
+guessed correctly.
+
+**Approximate timing:** 5-7 minutes given the density of this module's lesson.

content/root/root-09-kubernetes-security/m01-security-model-and-securitycontext/01-lesson-security-model.md

@@ -0,0 +1,87 @@
+# Defense in Depth & the Kubernetes Security Model
+
+## Security is a posture, not a single setting
+
+There is no single "make it secure" switch in Kubernetes. Real security comes from **defense in
+depth** — multiple independent layers, each reducing what an attacker (or a bug) can do if an
+earlier layer fails. If a container has a vulnerability that lets an attacker execute arbitrary
+code, the question that actually matters is: what can that code DO once it's running? A
+container running as root, with every Linux capability, on a writable filesystem, with no
+restrictions at all, can do far more damage than one deliberately hardened to need almost
+nothing.
+
+## Least privilege: grant only what's actually needed
+
+The organizing principle behind everything in this course is **least privilege**: a workload
+should have exactly the permissions and capabilities it needs to do its job, and nothing more.
+This sounds obvious stated plainly, but the DEFAULT behavior of a plain container is closer to
+"maximum privilege unless told otherwise" — root user, all standard Linux capabilities, a
+writable filesystem. Hardening a Pod means deliberately narrowing that down.
+
+## SecurityContext: where you actually configure this
+
+`securityContext` (settable at the Pod level and per-container) is where you declare these
+restrictions:
+
+```yaml
+spec:
+  securityContext:
+    runAsNonRoot: true
+    runAsUser: 1000
+  containers:
+  - name: app
+    securityContext:
+      readOnlyRootFilesystem: true
+      capabilities:
+        drop: ["ALL"]
+```
+
+- **`runAsNonRoot` / `runAsUser`** — the container process runs as a specific non-root user
+  instead of root. If a container image was built to require root and you set this, it will
+  fail to start — which is a good, loud failure, not a silent security gap. Hardening
+  sometimes surfaces an image's OWN bad assumptions.
+- **`capabilities: drop: ["ALL"]`** — Linux capabilities are fine-grained permissions
+  (`NET_BIND_SERVICE`, `SYS_ADMIN`, dozens more) a process can hold even without full root.
+  Dropping all of them, then adding back only the specific ones actually needed, is the
+  least-privilege pattern applied to capabilities specifically.
+- **`readOnlyRootFilesystem: true`** — the container's own filesystem cannot be written to at
+  all (use an explicit `emptyDir` volume, ROOT 08, for anything that genuinely needs to write
+  temporary files). This closes off a whole category of attack that relies on writing a
+  malicious file to disk.
+
+## Why this matters even when "nothing is currently wrong"
+
+None of these settings fix a bug or a vulnerability — they limit the BLAST RADIUS if one exists
+that you don't yet know about. A container hardened with non-root, dropped capabilities, and a
+read-only filesystem gives a successful exploit dramatically less to work with than an
+unhardened one, even against the exact same vulnerability. This is the entire point of defense
+in depth: you don't rely on any single layer being perfect.
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read; 10-12 minutes live with the demonstration.
+
+**Demo plan:** Have the demonstration activity ready to run right after this lesson — seeing a
+concrete before/after Pod definition lands the abstract "least privilege" principle far better
+than the lesson text alone.
+
+**Likely misconceptions to watch for:**
+- Students sometimes think hardening settings are only relevant "if you expect to be attacked."
+  Reframe: defense in depth assumes SOMETHING will eventually go wrong somewhere (a
+  vulnerability, a bug, a misconfiguration) and prepares for that, rather than betting
+  everything on nothing ever going wrong.
+- `runAsNonRoot: true` failing a Pod's startup is sometimes read as "the security setting is
+  broken." It's the opposite — it's correctly refusing to let a root-requiring image start,
+  which is valuable, actionable information about the image itself.
+
+**Discussion question:** "If dropping all capabilities breaks a container that turns out to
+genuinely need one specific capability, what's the right fix — removing the drop, or something
+more targeted?" (Answer: add back only that ONE specific capability rather than removing the
+blanket drop — least privilege means "exactly what's needed," not "give up and grant
+everything again.")
+
+**Optional extension:** ask students to identify one setting from this lesson that would have
+made zero difference against a vulnerability that lets an attacker read environment variables
+(a good check that they understand these are layered, not universal, protections — the answer
+is that none of SecurityContext's settings here directly protect secrets stored in env vars;
+that's a different concern, covered later in this course).

content/root/root-09-kubernetes-security/m01-security-model-and-securitycontext/02-demonstration-securitycontext.md

@@ -0,0 +1,87 @@
+# Demonstration: A Pod Before and After Hardening
+
+## Before: the default, unhardened Pod
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: app-unhardened
+spec:
+  containers:
+  - name: app
+    image: myapp:latest
+```
+
+Checking what this actually runs as:
+
+```
+$ kubectl exec app-unhardened -- id
+uid=0(root) gid=0(root) groups=0(root)
+
+$ kubectl exec app-unhardened -- touch /etc/anything-i-want
+$ kubectl exec app-unhardened -- ls -la /etc/anything-i-want
+-rw-r--r-- 1 root root 0 Jan 1 00:00 /etc/anything-i-want
+```
+
+Running as root, with a fully writable filesystem, including system directories. This is not a
+misconfiguration — it's simply what happens when nothing restricts it.
+
+## After: the same application, hardened
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: app-hardened
+spec:
+  securityContext:
+    runAsNonRoot: true
+    runAsUser: 1000
+  containers:
+  - name: app
+    image: myapp:latest
+    securityContext:
+      readOnlyRootFilesystem: true
+      capabilities:
+        drop: ["ALL"]
+```
+
+```
+$ kubectl exec app-hardened -- id
+uid=1000 gid=0 groups=0
+
+$ kubectl exec app-hardened -- touch /etc/anything-i-want
+touch: /etc/anything-i-want: Read-only file system
+```
+
+Same application image, same functionality (assuming the app doesn't itself require root or
+filesystem writes it wasn't told about) — but a compromise of this container now can't write
+to the filesystem, can't use the elevated capabilities that were dropped, and never had root to
+begin with.
+
+## What this actually buys you
+
+Nothing here fixed a bug in `myapp:latest` — the image is identical in both cases. What changed
+is what an attacker (or a bug behaving unexpectedly) could DO if something inside that container
+went wrong. The unhardened version had almost no limits; the hardened version has several
+independent ones, any of which alone would have blocked the `touch` command above.
+
+## Instructor Notes
+
+**Demo script:** Run both Pods live if time allows — watching `touch` succeed on one and fail
+on the other in real time is far more convincing than reading it.
+
+**Approximate timing:** 8-10 minutes live; 5-7 minutes self-paced.
+
+**Common misconception to preempt:** students sometimes read the hardened Pod's failed `touch`
+as "hardening broke something." Reinforce: the FUNCTIONALITY didn't change (the application
+itself never needed to write to `/etc`) — only an unnecessary, unused capability was removed.
+If hardening breaks something the application genuinely needs, that's real information about
+the application, not a reason to skip hardening.
+
+**Optional extension:** ask what would happen if `myapp:latest` were built assuming it could
+write a cache file to `/tmp` inside the container — a good bridge to the fact that
+`readOnlyRootFilesystem` often needs an explicit `emptyDir` volume mounted at the specific path
+an application legitimately needs to write to (ROOT 08), rather than being an all-or-nothing
+choice.

content/root/root-09-kubernetes-security/m01-security-model-and-securitycontext/03-knowledge-check.md

@@ -0,0 +1,47 @@
+# Knowledge Check: Security Model & SecurityContext
+
+---
+
+**1. A container is hardened with `capabilities: drop: ["ALL"]` and then fails because it
+genuinely needs to bind to a low-numbered network port, which requires `NET_BIND_SERVICE`.
+What's the least-privilege fix?**
+
+*Answer:* Add back only `NET_BIND_SERVICE` specifically (`capabilities: add:
+["NET_BIND_SERVICE"]` alongside the drop-all), not remove the blanket drop entirely.
+Least privilege means granting exactly what's needed, not reverting to granting everything.
+
+---
+
+**2. True or false: setting `runAsNonRoot: true` fixes a vulnerability inside the application
+itself.**
+
+*Answer:* False. It doesn't fix anything about the application's code — it limits what a
+compromise of that code could DO, by ensuring the process never has root privileges to begin
+with. This is the defense-in-depth distinction: reducing blast radius, not eliminating bugs.
+
+---
+
+**3. Why might `runAsNonRoot: true` cause a Pod to fail to start entirely, and is that a
+problem with the setting?**
+
+*Answer:* If the container image was built assuming it runs as root (e.g. it tries to bind a
+privileged port, or write to a root-owned directory), the Pod will fail to start under
+`runAsNonRoot`. This is NOT a problem with the setting — it's valuable, actionable information
+that the image itself makes an assumption that should probably be fixed.
+
+---
+
+**4. A container has `readOnlyRootFilesystem: true` and needs to write temporary cache files.
+What's the correct way to allow that without abandoning the read-only filesystem entirely?**
+
+*Answer:* Mount an explicit `emptyDir` volume (ROOT 08) at the specific path the application
+needs to write to. This keeps the rest of the filesystem read-only while allowing the one
+legitimately-needed writable location.
+
+## Instructor Notes
+
+**Facilitation:** Question 1 and question 4 both reinforce the same "narrow the exception, don't
+remove the protection" pattern — worth calling out that they're the same principle applied
+twice.
+
+**Approximate timing:** 5-7 minutes.

content/root/root-09-kubernetes-security/m01-security-model-and-securitycontext/04-guided-exercise-hardening-plan.md

@@ -0,0 +1,51 @@
+# Guided Exercise: Planning a Pod Hardening Checklist
+
+Paper-and-thinking exercise before the Labs.
+
+## The scenario
+
+You're handed a Pod spec for a small internal API with NO `securityContext` set at all — the
+fully-default, unhardened case from the demonstration. Your team lead asks you to harden it
+before it ships.
+
+## Your task
+
+Without writing the actual YAML yet, answer these:
+
+1. List the settings you'd add, in the order you'd verify them (hint: there are at least three
+   distinct concerns from the lesson — user/root, filesystem, capabilities).
+2. For each setting, name ONE way you'd notice if you'd broken the application by adding it
+   (what would the failure actually look like?).
+3. If the application genuinely needs to write a cache file to disk, does that mean you should
+   skip `readOnlyRootFilesystem` entirely? What's the more precise fix?
+4. Suppose after hardening, the container still runs fine but a security scan flags that it
+   still has the `NET_RAW` capability. What's the most likely reason, and what's the fix?
+
+## A worked answer to check yourself against
+
+1. In a reasonable order: (a) `runAsNonRoot`/`runAsUser` — a fundamental identity change,
+   surfaces image assumptions fastest; (b) `capabilities: drop: ["ALL"]` — narrow, usually safe
+   for a typical web API; (c) `readOnlyRootFilesystem: true` — most likely to need an
+   accompanying volume, so verify last once the others are confirmed working.
+2. (a) Pod fails to start entirely (`CrashLoopBackOff` or an immediate error) if the image
+   assumed root. (b) The application errors on a specific operation that needed a capability
+   you dropped (e.g. failing to bind a privileged port). (c) A write operation fails at runtime
+   (a log line, an exception) the first time the app tries to write to disk.
+3. No — the fix is mounting an explicit `emptyDir` volume at the specific path the cache needs,
+   keeping the rest of the filesystem read-only rather than abandoning the protection entirely.
+4. Most likely: `capabilities: drop: ["ALL"]` was never actually applied (a YAML indentation
+   mistake, or it was added to the Pod's securityContext instead of the container's — capability
+   drops are container-level, not Pod-level). The fix is verifying the drop is actually present
+   on the CONTAINER's securityContext specifically.
+
+## Instructor Notes
+
+**Facilitation:** Question 4 is deliberately tricky — Pod-level vs. container-level
+`securityContext` fields is a real, common source of "I set this and it didn't work" confusion
+worth surfacing here before students hit it in a Lab.
+
+**Approximate timing:** 15 minutes live with discussion; 12-15 minutes self-paced.
+
+**Optional extension:** ask students to identify which of the settings in this exercise would
+be MOST valuable to apply first if they could only add one to a large, existing fleet of
+unhardened Pods under time pressure, and why.

content/root/root-09-kubernetes-security/m01-security-model-and-securitycontext/09-reflection.md

@@ -0,0 +1,42 @@
+# Reflection: Least Privilege Is a Default, Not an Afterthought
+
+You just hardened real Pods across several Labs — non-root, dropped capabilities, a read-only
+filesystem, and a full SecurityContext review. Take a few minutes to connect this to real
+practice.
+
+## Reflection questions
+
+1. Before this module, would you have described "runs as root with a fully writable
+   filesystem" as insecure, or just as "the default, unremarkable configuration"? Has that
+   changed?
+2. None of the settings you configured fixed a bug in any application. What did they actually
+   change, precisely?
+3. If your team had to choose between hardening every new Pod by default (as a policy) versus
+   hardening Pods only after an incident reveals a gap, which produces less total risk over
+   time, and why?
+
+## Real Ops takeaway
+
+**Unhardened is not neutral — it's the maximum-privilege default.** A container with no
+SecurityContext configured isn't "unopinionated"; it's root, every capability, fully writable —
+the MOST privileged configuration possible, not a safe middle ground. Teams that treat hardening
+as optional are choosing maximum blast radius by default, usually without realizing they're
+choosing anything at all.
+
+**Defense in depth means no single mistake should be catastrophic.** The value of stacking
+non-root + dropped capabilities + read-only filesystem isn't that any ONE of them is perfect —
+it's that a real compromise would have to defeat several independent restrictions simultaneously
+instead of exploiting one gap that grants everything. This is exactly why security-minded teams
+apply all of these by default rather than picking "the one that matters most."
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 3 is worth pushing on directly — it's
+the actual business case for security-by-default, not just a technical preference.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
+
+**Optional extension:** ask students to draft a one-paragraph "default Pod hardening policy"
+their hypothetical team would adopt, based on what they've learned in this module.

content/root/root-09-kubernetes-security/m02-serviceaccounts-and-rbac/01-lesson-serviceaccounts-rbac.md

@@ -0,0 +1,90 @@
+# Identity for Workloads: ServiceAccounts & RBAC
+
+## Workloads need an identity too, separate from yours
+
+When YOU run `kubectl`, you're authenticated as yourself. But a Pod running INSIDE the cluster
+that needs to call the Kubernetes API (to list other Pods, read a ConfigMap, whatever) needs its
+own identity — it can't and shouldn't use your personal credentials. That identity is a
+**ServiceAccount**.
+
+Every Pod runs as SOME ServiceAccount — if you don't specify one, it uses the `default`
+ServiceAccount in its Namespace, which by default has essentially no permissions. A Pod's
+ServiceAccount token is automatically mounted into the container unless you explicitly disable
+that (`automountServiceAccountToken: false`) — worth doing for any Pod that never actually needs
+to call the Kubernetes API at all, since an unused, mounted credential is still something an
+attacker could steal and use.
+
+## RBAC: what that identity is actually allowed to do
+
+Having an identity (a ServiceAccount) doesn't grant any permissions by itself — **RBAC
+(Role-Based Access Control)** is the separate system that defines what an identity can DO.
+
+- A **Role** (namespace-scoped) or **ClusterRole** (cluster-wide) defines a set of permissions:
+  which API resources, which verbs (get/list/watch/create/update/delete).
+- A **RoleBinding** (or **ClusterRoleBinding**) connects a Role/ClusterRole to a specific
+  identity (a ServiceAccount, a user, or a group) — the Role alone grants nothing to anyone
+  until it's bound.
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  name: pod-reader
+  namespace: default
+rules:
+- apiGroups: [""]
+  resources: ["pods"]
+  verbs: ["get", "list"]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: read-pods
+  namespace: default
+subjects:
+- kind: ServiceAccount
+  name: my-app
+roleRef:
+  kind: Role
+  name: pod-reader
+  apiGroup: rbac.authorization.k8s.io
+```
+
+This grants the `my-app` ServiceAccount permission to `get`/`list` Pods in the `default`
+Namespace — and nothing else. It cannot delete Pods, cannot touch Secrets, cannot do anything
+not explicitly listed.
+
+## Role vs. ClusterRole: scope matters
+
+A Role only grants permissions within the ONE Namespace it's defined in. A ClusterRole can grant
+permissions across the entire cluster (or, bound via a RoleBinding instead of a
+ClusterRoleBinding, can also be reused namespace-by-namespace) — reach for a ClusterRole only
+when the workload genuinely needs cluster-wide visibility, not by default.
+
+## Least privilege, applied to permissions specifically
+
+The same principle from the previous module applies directly here: grant the narrowest set of
+verbs on the narrowest set of resources that the workload actually needs. A Role granting
+`get`/`list` on Pods is very different from one granting `*` on `*` — the latter is
+"root-equivalent" API access, and should be treated with exactly that level of caution.
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read; 10 minutes live.
+
+**Likely misconceptions to watch for:**
+- Students often conflate "ServiceAccount" with "user account for logging in." A ServiceAccount
+  is specifically an identity for WORKLOADS, not a human login mechanism.
+- The Role/RoleBinding two-step (define permissions, then separately grant them to someone) is
+  sometimes seen as redundant. Emphasize the reuse benefit: the same Role can be bound to
+  multiple identities without redefining the permission set each time.
+
+**Discussion question:** "Why might you explicitly disable automounting a ServiceAccount token
+for a Pod that never calls the Kubernetes API?" (Answer: an unused but present credential is
+still something an attacker who compromises the container could steal and use elsewhere —
+removing it entirely removes that risk for a Pod that never needed it.)
+
+**Optional extension:** ask what the practical difference is between granting a ClusterRole via
+a RoleBinding (scoped to one Namespace) versus a ClusterRoleBinding (cluster-wide) — a good
+check that students understand the Role/ClusterRole and Binding-type distinctions are
+independent axes, not the same choice.

content/root/root-09-kubernetes-security/m02-serviceaccounts-and-rbac/02-knowledge-check.md

@@ -0,0 +1,44 @@
+# Knowledge Check: ServiceAccounts & RBAC
+
+---
+
+**1. A Pod is created with no ServiceAccount specified. What identity does it actually run as,
+and what can that identity do by default?**
+
+*Answer:* The `default` ServiceAccount in its Namespace, which by default has essentially no
+permissions — it can authenticate to the API but is granted nothing until an RBAC binding says
+otherwise.
+
+---
+
+**2. You create a Role granting `get`/`list` on Pods, but a workload still can't read Pods.
+What's the most likely missing piece?**
+
+*Answer:* A RoleBinding (or ClusterRoleBinding) connecting that Role to the workload's actual
+ServiceAccount. A Role by itself grants nothing to anyone — it has to be bound to an identity.
+
+---
+
+**3. True or false: a ClusterRole can only ever be applied cluster-wide.**
+
+*Answer:* False. A ClusterRole can be bound via a RoleBinding to apply within just ONE
+Namespace (reusing a cluster-wide-DEFINED permission set in a namespace-SCOPED way), or via a
+ClusterRoleBinding to apply cluster-wide. The Role-type and Binding-type are independent
+choices.
+
+---
+
+**4. Why would a security review flag a Role granting `verbs: ["*"]` on `resources: ["*"]`
+even if the workload "seems to work fine"?**
+
+*Answer:* That grant is root-equivalent API access — it violates least privilege regardless of
+whether the workload happens to only use a small subset of it today. "Works fine" doesn't mean
+"correctly scoped" — an over-broad grant is a real risk the moment that workload (or its
+credentials) is compromised, whether or not it's ever exploited in practice.
+
+## Instructor Notes
+
+**Facilitation:** Question 4 is worth discussing even if everyone answers correctly — the "it
+works, so what's the problem" instinct is exactly what least-privilege review exists to counter.
+
+**Approximate timing:** 5 minutes.

content/root/root-09-kubernetes-security/m03-network-and-supplychain-security/01-lesson-network-supplychain.md

@@ -0,0 +1,76 @@
+# NetworkPolicy as a Security Control & Supply Chain Trust
+
+## NetworkPolicy, revisited as a security posture
+
+ROOT 07 introduced NetworkPolicy architecturally: Kubernetes doesn't isolate Pod-to-Pod traffic
+by default, and NetworkPolicy is how you declare intended reachability. Here, the same
+mechanism is the point of a deliberate SECURITY practice: **default deny**.
+
+A default-deny policy blocks all traffic to selected Pods, and you then explicitly allow only
+what's actually needed:
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny
+spec:
+  podSelector: {}      # selects EVERY Pod in the namespace
+  policyTypes: ["Ingress"]
+```
+
+An empty `podSelector: {}` with no ingress rules means "select every Pod, allow nothing in" —
+the network equivalent of the SecurityContext principle from earlier in this course: start
+from nothing, add back only what's proven necessary. This is exactly the opposite of
+Kubernetes' un-configured default (everything open), which is precisely why it has to be
+declared explicitly rather than relying on any built-in setting.
+
+**Egress restriction** works the same way in reverse — restricting what a Pod can call OUT to,
+not just what can call IN. A compromised Pod that can freely make outbound connections to
+anything is far more dangerous (data exfiltration, calling out to an attacker's server) than one
+restricted to only the specific destinations it legitimately needs.
+
+## Supply chain: trusting what you run before it ever starts
+
+Everything covered so far in this course assumes the container image itself is trustworthy.
+Supply-chain security is about that assumption specifically:
+
+- **Image-pull secrets** — when pulling from a private registry, the cluster needs credentials
+  to authenticate. Storing and using these correctly (rather than, say, a publicly-readable
+  registry with no access control) is a basic supply-chain control: only images from a trusted,
+  access-controlled source get pulled at all.
+- **Minimizing image footprint** (referenced here, not a hands-on Lab in this module) — a
+  smaller image means fewer packages, fewer known CVEs, and a smaller attack surface if the
+  image is ever compromised.
+
+## TLS at the Ingress layer: protecting data in transit
+
+Recall ROOT 07's Ingress lesson — routing external HTTP(S) traffic by hostname/path. Configuring
+TLS termination at that same Ingress layer means traffic between users and your cluster is
+encrypted, protecting against interception on the network path. This is a security concern
+layered on top of the same architectural mechanism, the same relationship NetworkPolicy has to
+its ROOT 07 introduction.
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read; 10 minutes live.
+
+**Likely misconceptions to watch for:**
+- Students sometimes think "default deny" means blocking ALL traffic including what the
+  application needs to function. Clarify: default deny is the STARTING point; you then add
+  specific allow rules for exactly what's needed — the goal state is fully functional AND fully
+  intentional, not non-functional.
+- Egress restriction is sometimes seen as less important than ingress. Emphasize the
+  exfiltration angle explicitly — a compromised Pod's outbound reach is just as much a real
+  risk as inbound exposure.
+
+**Discussion question:** "Why is 'default deny, then explicitly allow' a better starting
+posture than 'default allow, then explicitly block known-bad traffic'?" (Answer: default-deny
+means a NEW, unanticipated attempt to reach or leave a Pod is blocked by default; default-allow
+means anything not YET identified as bad gets through — you're always one step behind an
+attacker under the second model.)
+
+**Optional extension:** ask what a real team would want to verify before trusting a
+publicly-available container image from an unfamiliar source, beyond just "does it work" — a
+good bridge into image scanning/provenance concepts (not built as a hands-on Lab in this course,
+but worth naming as a real practice).

content/root/root-09-kubernetes-security/m03-network-and-supplychain-security/02-knowledge-check.md

@@ -0,0 +1,45 @@
+# Knowledge Check: Network & Supply Chain Security
+
+---
+
+**1. A NetworkPolicy has `podSelector: {}` with `policyTypes: ["Ingress"]` and no ingress rules
+defined. What's the practical effect on every Pod in that namespace?**
+
+*Answer:* Every Pod is selected, and since no ingress rule allows anything, all incoming traffic
+to every Pod is denied — this is the "default deny" starting posture, applied namespace-wide.
+
+---
+
+**2. Why is restricting EGRESS (outbound) traffic from a Pod a real security control, not just
+a mirror-image nicety of ingress restriction?**
+
+*Answer:* A compromised Pod with unrestricted egress can exfiltrate data to an attacker-controlled
+destination or call out to download additional malicious payloads. Restricting egress to only
+what's legitimately needed limits what a compromise can accomplish, independent of whether
+inbound access was ever an issue.
+
+---
+
+**3. True or false: "default deny, then explicitly allow" and "default allow, then explicitly
+block known-bad traffic" provide equivalent security given the same set of rules.**
+
+*Answer:* False. Default-deny blocks anything NOT yet explicitly allowed, including new/
+unanticipated attempts. Default-allow only blocks what's already been identified as bad — an
+attacker doing something not yet on the block list gets through under the second model but not
+the first.
+
+---
+
+**4. Why does minimizing a container image's footprint (fewer packages) improve supply-chain
+security specifically, rather than just making the image smaller/faster to pull?**
+
+*Answer:* Fewer installed packages means fewer potential known vulnerabilities (CVEs) present in
+the image at all, and a smaller attack surface if the image is ever compromised — it's a
+security property, not merely a performance optimization.
+
+## Instructor Notes
+
+**Facilitation:** Question 3 is the core conceptual point of this module — worth confirming it's
+genuinely understood, not just correctly guessed.
+
+**Approximate timing:** 5-7 minutes.

content/root/root-09-kubernetes-security/m04-cluster-hardening-and-runtime/01-lesson-cluster-hardening.md

@@ -0,0 +1,64 @@
+# Pod Security Admission & a Survey of Runtime Hardening
+
+This module is deliberately a survey, not a deep dive — the topics here are real and important,
+but lean toward cluster-operator/platform-team concerns rather than the daily-driver skills most
+ROOT_ learners will use constantly. Treat the labs in this module as good-to-know, not required
+mastery, before moving on.
+
+## Pod Security Admission: enforcing a baseline across a Namespace
+
+Everything you configured by hand in earlier modules (non-root, dropped capabilities, read-only
+filesystem) can also be ENFORCED automatically at the Namespace level via **Pod Security
+Admission (PSA)** — a label on the Namespace itself that rejects any Pod violating a chosen
+security standard (`privileged`, `baseline`, or `restricted`, from least to most strict):
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: production
+  labels:
+    pod-security.kubernetes.io/enforce: restricted
+```
+
+This replaces the older PodSecurityPolicy (PSP) mechanism, which was removed from Kubernetes —
+if you encounter PSP in older documentation or an older cluster, know that PSA is its current
+replacement.
+
+## Immutable Secrets: preventing a class of accidental change
+
+A Secret can be marked `immutable: true`, which prevents its data from being changed after
+creation (a new Secret with a new name has to be created instead, and workloads updated to
+reference it). This trades a small amount of operational flexibility for a real safety
+property: an accidental or malicious edit to a live Secret can't silently happen.
+
+## A survey of further topics (labs available, treat as optional depth)
+
+- **Audit policy** — configuring what the Kubernetes API server logs about requests made against
+  it (who did what, when) — genuinely important for incident investigation, but a cluster-admin
+  concern, not something most workload teams configure themselves.
+- **RuntimeClass** — lets specific Pods run under a different container runtime configuration
+  (e.g. an extra-sandboxed runtime like gVisor or Kata Containers) for workloads that need
+  stronger isolation than the default runtime provides — relevant mainly for genuinely
+  untrusted or high-risk workloads, not typical applications.
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read (shorter than other lessons — deliberately survey-depth).
+
+**Framing for instructors:** Be explicit with students that this module is intentionally
+lighter than the earlier ones in this course — the goal is awareness ("this exists, here's
+roughly what it's for") rather than hands-on fluency, consistent with not every CKS-style topic
+belonging in the core learning path.
+
+**Discussion question:** "Why would a platform team prefer enforcing security standards via
+Pod Security Admission at the Namespace level, instead of trusting every team to configure
+SecurityContext correctly on every Pod by hand?" (Answer: PSA provides a hard backstop —
+correctly-configured SecurityContext relies on every individual Pod author doing it right every
+time; PSA rejects violations automatically regardless of whether any individual author
+remembered to.)
+
+**Optional extension:** ask which of `privileged`/`baseline`/`restricted` a team should start a
+brand-new, security-conscious project with, and why not jump straight to the strictest option
+on a cluster already running older, unaudited workloads (a good practical judgment question
+about migration risk, not just definitions).

content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/01-lesson-health-check-concepts.md

@@ -0,0 +1,86 @@
+# Why Health Checks Exist & Probe Types
+
+Kubernetes cannot see inside your application. It doesn't know if your process is deadlocked,
+stuck in an infinite loop, or quietly failing every request while the process itself stays
+alive. Without a way to ask "are you actually working?", the only signal Kubernetes has is
+whether the container's process is still running — and a hung process still counts as running.
+
+**A health probe is how your application tells Kubernetes the truth.** It's a small check —
+an HTTP request, a TCP connection attempt, or a command run inside the container — that
+Kubernetes runs on a schedule and uses to make real decisions: restart this container, or stop
+sending it traffic.
+
+## The three probe types
+
+Kubernetes supports three distinct probes, and they answer three different questions. Mixing
+them up is the single most common probe mistake in production.
+
+**Liveness probe — "Is this container still alive, or should it be restarted?"**
+If a liveness probe fails repeatedly, the kubelet kills the container and it gets restarted per
+its restart policy. Use this for detecting a genuinely stuck process — a deadlock, a crashed
+event loop. Don't use liveness to mean "not ready for traffic yet" — that's what readiness is
+for, and confusing the two causes the exact incident you're about to fix.
+
+**Readiness probe — "Is this container ready to receive traffic right now?"**
+If a readiness probe fails, the Pod is removed from the Service's list of endpoints —
+Kubernetes stops routing traffic to it, but does **not** restart the container. This is the
+right tool for "still starting up," "warming a cache," or "temporarily overloaded, back off for
+a bit." A Pod can be Running and healthy but still correctly Not Ready.
+
+**Startup probe — "Has this slow-starting container finished starting up yet?"**
+Some applications take a long time to become ready (loading a large dataset, running
+migrations). A startup probe disables liveness/readiness checks until it succeeds once, so a
+slow-but-healthy startup doesn't get killed by an impatient liveness probe. Once it succeeds,
+liveness and readiness take over as normal.
+
+## How a probe is actually defined
+
+Every probe has a **mechanism** (how the check runs) and a **schedule** (how often, how long to
+wait, how many failures before acting):
+
+- `httpGet` — a GET request to a path and **port** on the container. A 2xx or 3xx response
+  counts as success.
+- `tcpSocket` — a TCP connection attempt to a **port**. A successful connection counts as
+  success — this doesn't check application-level health, just "is something listening."
+- `exec` — runs a command inside the container. Exit code `0` counts as success.
+
+Timing fields (`initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `failureThreshold`,
+`successThreshold`) control how patient Kubernetes is before it acts — but no amount of correct
+timing fixes a probe that's pointed at the wrong port or path in the first place.
+
+## Common production mistakes
+
+1. **Wrong port.** The probe's `httpGet.port` (or `tcpSocket.port`) doesn't match the port the
+   application actually listens on. The container is completely healthy — Kubernetes is just
+   asking the wrong door to open. This is the exact failure you'll diagnose in this module's lab.
+2. **Liveness probe too aggressive on a slow-starting app**, with no startup probe — the app
+   gets killed for "not being ready yet," restarts, and never gets far enough to pass.
+3. **Readiness probe that always passes** (e.g. checking a static file instead of real
+   dependencies) — traffic gets routed to a Pod that can't actually serve it.
+4. **No probes configured at all** — Kubernetes has no way to know the container is stuck, so a
+   deadlocked process just sits there serving nothing, forever, looking "Running" the whole time.
+
+## Instructor Notes
+
+**Approximate timing:** 12-15 minutes for a live read-through with pauses for questions;
+10 minutes for a self-paced read.
+
+**Demo plan:** Before moving to the guided exercise, it's worth live-editing one Deployment's
+`readinessProbe.httpGet.port` in front of the class to an obviously wrong value and running
+`kubectl get pods` / `kubectl describe pod` together, so students see the Ready column and the
+Events section change in real time before they do it themselves.
+
+**Likely misconceptions to watch for:**
+- Students often assume a failing liveness probe and a failing readiness probe look the same in
+  `kubectl get pods` — they don't (liveness failures show restart counts climbing; readiness
+  failures show `0/1` Ready with no restarts). Worth calling out explicitly.
+- Students sometimes think `tcpSocket` checks are "less safe" than `httpGet` — reframe as
+  "checks a different, shallower thing," not "worse."
+
+**Discussion question:** "Why might a team deliberately choose a readiness probe that fails
+under high load, even though it takes healthy capacity out of rotation?" (Answer: shedding load
+from an overloaded Pod is often better than serving every request slowly or with errors.)
+
+**Optional extension:** Ask students to sketch what would happen if liveness and readiness
+probes were swapped (readiness probe restarts on failure, liveness probe just removes from
+Service) — this clarifies the distinction by making the wrong version visibly worse.

content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/02-demonstration-probes-in-action.md

@@ -0,0 +1,71 @@
+# Demonstration: Probes in Action
+
+Watch what a probe failure actually looks like from the outside, before you're the one
+diagnosing it.
+
+Picture a Deployment called `web` running `nginx`, which listens on port 80. Someone adds a
+readiness probe but mistypes the port as `8080`:
+
+```yaml
+readinessProbe:
+  httpGet:
+    path: /
+    port: 8080
+  initialDelaySeconds: 3
+  periodSeconds: 5
+```
+
+**What you'd see immediately after this rolls out:**
+
+```
+$ kubectl get pods
+NAME                   READY   STATUS    RESTARTS   AGE
+web-7d8f9c6b5d-abcde   0/1     Running   0          45s
+```
+
+`STATUS` says `Running` — the container started fine, nginx is up. But `READY` says `0/1` — the
+readiness probe is failing, so this Pod has never been added to its Service's endpoints. No
+traffic reaches it. `RESTARTS` stays at `0` because this is a readiness failure, not a liveness
+failure — nothing is being killed, it's just being excluded.
+
+**The trail that explains why**, from `kubectl describe pod`:
+
+```
+Events:
+  Type     Reason     Age   From     Message
+  ----     ------     ----  ----     -------
+  Normal   Scheduled  50s   default-scheduler  Successfully assigned default/web-... to node-1
+  Normal   Pulled     49s   kubelet   Container image "nginx:1.25" already present on machine
+  Normal   Created    49s   kubelet   Created container web
+  Normal   Started    49s   kubelet   Started container web
+  Warning  Unhealthy  15s (x6 over 40s)  kubelet   Readiness probe failed: Get "http://10.244.0.7:8080/": dial tcp 10.244.0.7:8080: connect: connection refused
+```
+
+That last line is the whole story: kubelet tried to connect to port `8080` and nothing was
+listening there — because nginx is listening on `80`. The container was never broken. The probe
+was asking the wrong question.
+
+**The general diagnostic shape** for any probe issue: `kubectl get pods` tells you *that*
+something is wrong (Ready count, restart count). `kubectl describe pod` and its Events section
+tell you *what* is wrong, usually in plain English, including the exact port/path that was
+tried and the exact error. Reach for Events before logs — logs show you what the application
+did; Events show you what Kubernetes tried to do and how it failed.
+
+## Instructor Notes
+
+**Demo script:** Live-run this exact sequence against a throwaway Deployment (or the classroom
+projector) rather than only showing static output — `kubectl get pods`, then
+`kubectl describe pod <name>`, scrolling straight to Events. Ask the class to predict the
+`READY` column and `RESTARTS` count *before* you show it.
+
+**Approximate timing:** 8-10 minutes live; ~5 minutes as a self-paced read.
+
+**Common misconception to preempt:** students often reach for `kubectl logs` first when
+something isn't Ready. For a probe misconfiguration, logs are frequently silent or unhelpful —
+the application is healthy and has nothing to say. This is a good moment to reinforce
+"Events explain what Kubernetes tried; logs explain what the app did," and that reading Events
+first is usually faster for this class of failure.
+
+**Optional extension:** show the same failure signature for a `tcpSocket` probe (a bare
+"connection refused" with no HTTP verb in the Events message) so students can tell the two
+mechanisms apart from Events alone.

content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/03-knowledge-check.md

@@ -0,0 +1,56 @@
+# Knowledge Check: Health Probes
+
+Answer each question yourself before reading the answer that follows it. This isn't graded —
+it's a checkpoint to catch a misunderstanding before you're troubleshooting a live Pod in the
+next activity.
+
+---
+
+**1. A Pod shows `RESTARTS: 12` and `READY: 1/1`. What kind of probe failure, if any, is most
+consistent with this?**
+
+*Answer:* A liveness probe that was failing and has now recovered (or is intermittently
+failing) — the climbing restart count is the signature of liveness failures, since a failed
+liveness check causes the kubelet to kill and restart the container. `READY: 1/1` means it's
+currently passing its readiness check right now.
+
+---
+
+**2. A Pod shows `RESTARTS: 0` and `READY: 0/1`, and has looked this way for several minutes.
+What kind of probe failure is most consistent with this?**
+
+*Answer:* A readiness probe that is failing. The container is running fine (no restarts), but
+Kubernetes has decided it isn't ready to receive traffic and has excluded it from the Service's
+endpoints. This is exactly the symptom you'll investigate in this module's lab.
+
+---
+
+**3. Why does Kubernetes offer a separate startup probe instead of just making
+`initialDelaySeconds` on the liveness probe longer?**
+
+*Answer:* `initialDelaySeconds` is a fixed, one-size-fits-all wait before checks even begin —
+set it too short and a normally-slow startup gets killed; set it too long and every fast
+startup pays that same delay before liveness/readiness protection is even active. A startup
+probe instead keeps checking until the application actually reports ready (bounded by its own
+failure threshold), so liveness/readiness only take over once startup is confirmed done —
+correct for both a consistently slow app and one whose startup time varies.
+
+---
+
+**4. True or false: a readiness probe failure will cause Kubernetes to restart the container.**
+
+*Answer:* False. A readiness probe failure only removes the Pod from Service endpoints — it
+does not restart anything. Only a liveness (or startup, before it succeeds once) probe failure
+causes a restart.
+
+## Instructor Notes
+
+**Facilitation:** In a live classroom, ask these out loud and take verbal answers before
+revealing each one, rather than having students read this silently — the goal is to surface a
+wrong mental model while it's still cheap to correct.
+
+**Approximate timing:** 5 minutes.
+
+**Likely misconception this catches:** question 2 specifically catches students who default to
+"something is broken, kubectl logs will show an error" — for a pure readiness-probe
+misconfiguration, logs are usually clean, which is disorienting the first time you hit it.

content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/04-guided-exercise-readiness-probe.md

@@ -0,0 +1,61 @@
+# Guided Exercise: Configure a Readiness Probe
+
+This is a paper-and-thinking exercise, not a Lab task — you won't run these commands against a
+real cluster here (that comes next). The goal is to practice reading and writing a probe
+definition correctly before you're diagnosing someone else's broken one.
+
+## The scenario
+
+You're deploying a small HTTP API that listens on port `3000` and exposes a health endpoint at
+`/healthz`. It takes a couple of seconds to finish connecting to its database on startup — if a
+request arrives before that finishes, it correctly returns a `503` at `/healthz` until it's
+ready.
+
+## Your task
+
+Work out, on paper (or in a scratch file), what you'd write for this container's readiness
+probe. Think through:
+
+1. Which mechanism fits — `httpGet`, `tcpSocket`, or `exec`? (Hint: you have a real health
+   endpoint that returns a meaningful status code — use it rather than a shallower check.)
+2. What `port` and `path` should the probe target?
+3. Roughly what `initialDelaySeconds` makes sense, given the database connection takes a couple
+   of seconds?
+4. Should this be a `readinessProbe`, a `livenessProbe`, or both? Justify your answer using the
+   distinction from the lesson — what actually goes wrong if you get this specific choice wrong
+   here?
+
+## A worked shape to check yourself against
+
+Your answer should end up structurally similar to this (exact field names matter more than the
+precise numbers you chose):
+
+```yaml
+readinessProbe:
+  httpGet:
+    path: /healthz
+    port: 3000
+  initialDelaySeconds: 3
+  periodSeconds: 5
+```
+
+If you reached for `livenessProbe` instead of `readinessProbe` for this specific scenario,
+re-read the lesson's distinction before continuing — "returns 503 while warming up" is
+precisely the readiness case, not the liveness case. A liveness probe here would restart a
+perfectly healthy, still-starting container over and over, which never lets it finish starting.
+
+## Instructor Notes
+
+**Facilitation:** Have students write their probe block on paper or a shared doc before showing
+the worked shape — resist showing the answer early, since the value here is in students
+committing to an answer and comparing, not passively reading a correct one.
+
+**Approximate timing:** 10-15 minutes live with discussion; 10 minutes self-paced.
+
+**Common mistake to watch for:** choosing `livenessProbe` because "the app isn't healthy yet"
+— this is the single most common real-world probe mistake and exactly what question 4 is
+designed to surface before the next activity's real diagnostic task.
+
+**Optional extension:** ask what would need to change in this same YAML if the health endpoint
+took up to 60 seconds to become available on cold start (answer: a `startupProbe` with a
+generous `failureThreshold` × `periodSeconds`, so liveness/readiness don't engage too early).

content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/05-lab-intro.md

@@ -0,0 +1,47 @@
+# Launch Lab: Stuck Not-Ready: The Probe Port Mismatch
+
+Time to apply everything from this module against a real, running incident — not a diagram, an
+actual Deployment in your own disposable Lab environment.
+
+## What you're walking into
+
+A deployment called `api-gateway` has been rolled out. The pods start, the container runs — but
+the deployment never reaches Ready, and traffic isn't being routed to it. Somewhere on-call, an
+alert is firing.
+
+You now have everything you learned in this module to work with:
+
+- **The lesson** told you what "stuck at 0/2 Ready with 0 restarts" actually means (a readiness
+  problem, not a crash).
+- **The demonstration** showed you exactly where to look for the explanation — `kubectl get
+  pods`, then `kubectl describe pod` and its Events section — and what a port-mismatch failure
+  looks like in that output.
+- **The guided exercise** had you reason through what a correct probe definition looks like,
+  which is exactly what you'll need to compare the broken one against.
+
+## Your task in this Lab
+
+Diagnose why the pods are failing their readiness check, correct the probe configuration, and
+restore the deployment to fully Ready. Start with pod status and events, the same way you just
+practiced — read before you patch.
+
+This Lab has its own in-context hints if you get stuck, revealed one at a time — use the
+concepts from this module first; reach for a hint only if you're genuinely stuck, not as the
+first move.
+
+When the Lab confirms your fix, come back to this module to close it out with a short
+reflection on what actually caused this.
+
+## Instructor Notes
+
+**Classroom flow:** if teaching this live, this is the natural point to have students launch
+their own Lab environment and work independently or in pairs, while you circulate. The
+Real-Time Classroom dashboard's help-request and progress views (see the instructor Curriculum
+view) show who's stuck without needing to walk around asking.
+
+**Approximate timing:** 15-20 minutes for most students; some will resolve it in under 5 once
+the module's concepts have landed.
+
+**Common mistake to watch for:** students jumping straight to `kubectl logs` here, which will
+be unhelpful (nginx has nothing to say about a probe pointed at the wrong port) — this is a good
+moment to reinforce the demonstration's point about reading Events first for this failure class.

content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/06-reflection-real-ops-takeaway.md

@@ -0,0 +1,61 @@
+# Root-Cause Reflection & Real Ops Takeaway
+
+You just fixed a real incident pattern, not a puzzle. Before moving on, take a few minutes to
+think through what actually happened and why it matters beyond this one Lab.
+
+## What actually went wrong
+
+The container was never broken. `nginx` started fine and was serving requests correctly the
+entire time. The only thing wrong was that the readiness probe was configured to check a port
+nginx wasn't listening on — so Kubernetes, working exactly as designed, correctly reported the
+Pod as Not Ready based on the information it had. The system didn't fail; it was given wrong
+information and acted rationally on it.
+
+This is worth sitting with: most "Kubernetes is broken" incidents are actually "Kubernetes is
+doing exactly what its configuration tells it to do, and the configuration is wrong."
+
+## Reflection questions
+
+Think through your own answers to these — there's no single correct wording, but you should be
+able to explain each one out loud:
+
+1. If you had jumped straight to `kubectl logs` instead of `kubectl describe pod`, how long do
+   you think it would have taken you to find this? What would the logs have actually shown you?
+2. This Lab's port mismatch was introduced deliberately. What real-world change could introduce
+   the exact same failure by accident? (Consider: someone changes the container's listening
+   port in a new image version, but forgets the probe definition was hand-written separately.)
+3. Why does a rolling update stall — not fail outright, just hang — when new Pods can't pass
+   their readiness probe? What is Kubernetes protecting you from by refusing to proceed?
+
+## Real Ops takeaway: prevention, not just fixes
+
+In a real production system, you'd want to prevent this class of incident from recurring, not
+just fix it once:
+
+- **Keep the probe port derived from the same source as the container's actual port**, where
+  your tooling allows it (a shared value in a Helm chart or Kustomize overlay), instead of two
+  independently hand-typed numbers that can drift apart silently.
+- **Treat a stalled rollout as a first-class alert**, not just "the deploy is taking a while" —
+  a Deployment sitting at partial readiness for an unusual length of time is exactly this
+  failure mode, and catching it via rollout status is faster than waiting for a user-facing
+  outage report.
+- **Practice reading Events before logs** for anything in the "Running but not Ready" state —
+  you just did this under low stakes; the habit is what pays off during a real incident at 2am.
+
+This module is complete. Return to the course to continue with the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** use the three reflection questions above as
+discussion prompts rather than a silent worksheet — question 2 in particular tends to produce
+good real-world examples from students who've touched CI/CD pipelines before.
+
+**Approximate timing:** 10 minutes for a live discussion; 5-8 minutes self-paced writing.
+
+**Optional extension:** ask students to write the one-sentence postmortem summary they'd post
+in a team channel for this incident (real on-call teams write these) — a good answer names the
+root cause (probe port mismatch) and the fix (corrected port), not just "it's fixed now."
+
+**Why this activity is a reflection, not another knowledge check:** the goal here is
+consolidation and transfer to real-world judgment, not testing recall — resist turning this
+into another right/wrong quiz.

content/root/root-10-kubernetes-troubleshooting-observability/m03-troubleshooting-framework/01-lesson-framework.md

@@ -0,0 +1,92 @@
+# The RootNode Troubleshooting Framework
+
+## Why a framework, not just "get good at kubectl"
+
+The gold-standard Health Probes module taught you a lot about ONE specific failure mode
+(readiness probe misconfiguration) and the specific commands to diagnose it. This module steps
+back and asks: what's the repeatable PROCESS that works for almost any Kubernetes failure, not
+just the ones you've already seen before?
+
+Guessing under pressure — trying random fixes and seeing what sticks — is slow, often makes
+things worse, and doesn't build a transferable skill. A framework does.
+
+## Observe → Gather Evidence → Form Hypothesis → Test → Repair → Validate → Prevent Recurrence
+
+**Observe** — what's the actual, specific symptom? Not "it's broken," but "the Deployment shows
+0/3 Ready" or "requests are timing out" or "the Pod restarts every 30 seconds." Precision here
+saves time later.
+
+**Gather Evidence** — before touching anything, collect what the system itself is telling you:
+`kubectl get pods`, `kubectl describe pod`, `kubectl logs`, `kubectl get events`. Resist the urge
+to start changing things before you've looked.
+
+**Form Hypothesis** — based on the evidence, state a SPECIFIC guess about the cause. "The
+container is crashing because the command it's told to run doesn't exist" is testable. "Something's
+wrong with networking" is not specific enough to act on yet.
+
+**Test** — check whether your hypothesis is actually true, ideally without yet making the fix
+(read the exact command being run, compare against what the image expects) — confirm before you
+commit to a repair.
+
+**Repair** — make the minimal change that addresses the confirmed cause. Not a bigger change
+"while you're in there" — exactly the fix the evidence supports.
+
+**Validate** — confirm the fix actually worked, using the same kind of evidence you gathered
+initially (not just "I made a change, it should be fine now").
+
+**Prevent Recurrence** — the step most often skipped under time pressure. Could this class of
+mistake happen again? Is there a smaller, structural change (a default, a validation, a check)
+that would catch it earlier next time?
+
+## Applying it: a CrashLoopBackOff
+
+- **Observe:** `crash-app`'s Pods show `STATUS: CrashLoopBackOff`, restart count climbing.
+- **Gather Evidence:** `kubectl describe deployment crash-app` (check the configured command),
+  `kubectl logs -l app=crash-app` (what did the container actually print before dying, if
+  anything).
+- **Form Hypothesis:** "The command override is invalid/wrong for this image, so the container
+  exits immediately every time it starts."
+- **Test:** compare the command actually configured against what the image's default/expected
+  entrypoint should be.
+- **Repair:** fix the command to what the container image actually expects.
+- **Validate:** `kubectl get pods` shows `Running`, restart count stops climbing.
+- **Prevent Recurrence:** a code-review habit of never overriding a container's command without
+  verifying it against the image's documentation first.
+
+## Applying it: a broken Service selector
+
+- **Observe:** traffic isn't reaching `my-svc`'s backend at all.
+- **Gather Evidence:** `kubectl get endpoints my-svc` (empty?), `kubectl get pods
+  --show-labels` (what labels do the actual Pods have?).
+- **Form Hypothesis:** "The Service's selector doesn't match the Pods' actual labels."
+- **Test:** compare `kubectl describe service my-svc`'s selector against the Pods' real labels
+  directly, side by side.
+- **Repair:** correct the selector to match.
+- **Validate:** `kubectl get endpoints my-svc` now shows the Pod IPs.
+- **Prevent Recurrence:** keeping label keys/values consistent (or generated from one source)
+  between a Deployment's Pod template and any Service that targets it.
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read; 10-12 minutes live walking through both worked
+examples.
+
+**Demo plan:** Use the demonstration activity right after this lesson to show the CrashLoopBackOff
+example live, narrating each framework step explicitly as you go rather than just running
+commands.
+
+**Likely misconceptions to watch for:**
+- Students under time pressure often skip straight to "Repair" without confirming a hypothesis
+  first. Reinforce that a wrong guess implemented as a "fix" can make evidence harder to read
+  afterward, not easier.
+- "Prevent Recurrence" is the step most likely to be treated as optional/skippable. Frame it as
+  what separates a team that keeps hitting the same incident from one that doesn't.
+
+**Discussion question:** "What's the cost of skipping 'Gather Evidence' and jumping straight to
+a guessed fix, even if the guess happens to be right?" (Answer: even a correct guess doesn't
+teach you whether your reasoning was right — you got lucky, and the same class of mistake could
+still recur since you never confirmed the actual cause.)
+
+**Optional extension:** ask students to apply this exact framework, from memory, to the gold
+module's `rootnode-probe-port-mismatch` incident they already solved — a good retroactive
+exercise connecting a lab they already completed to the generalized framework.

content/root/root-10-kubernetes-troubleshooting-observability/m03-troubleshooting-framework/02-demonstration-crashloop.md

@@ -0,0 +1,91 @@
+# Demonstration: Applying the Framework to a CrashLoopBackOff
+
+Watch the full Observe → Evidence → Hypothesis → Test → Repair → Validate → Prevent sequence
+against a real symptom, narrated step by step.
+
+## Observe
+
+```
+$ kubectl get pods
+NAME                        READY   STATUS             RESTARTS   AGE
+crash-app-6d9f8b7c5d-abcde  0/1     CrashLoopBackOff    5          4m
+```
+
+Specific symptom: `CrashLoopBackOff`, restart count climbing (5 and counting) — the container
+is starting, exiting, and being restarted repeatedly, not just failing to start once.
+
+## Gather Evidence
+
+```
+$ kubectl logs crash-app-6d9f8b7c5d-abcde
+nginx: [emerg] invalid command "daemon-off": expected valid command
+```
+
+```
+$ kubectl describe deployment crash-app
+...
+    Command:
+      nginx
+      -g
+      daemon-off;
+...
+```
+
+The logs show nginx itself rejecting the command it was given. The Deployment's configured
+command shows exactly why: `daemon-off;` (a typo — missing space, should be `daemon off;`).
+
+## Form Hypothesis
+
+"The container's command override has a syntax error that nginx can't parse, so nginx exits
+immediately every time it starts — which is why it's crash-looping rather than just failing to
+start once."
+
+## Test
+
+Compare the broken command (`daemon-off;`) against nginx's actual expected syntax
+(`daemon off;`, two separate words) — confirmed: this is exactly the kind of typo that would
+produce exactly this error.
+
+## Repair
+
+```
+$ kubectl patch deployment crash-app --type='json' \
+  -p='[{"op":"replace","path":"/spec/template/spec/containers/0/command","value":["nginx","-g","daemon off;"]}]'
+```
+
+## Validate
+
+```
+$ kubectl get pods
+NAME                        READY   STATUS    RESTARTS   AGE
+crash-app-7f8c9d6b5d-fghij  1/1     Running   0          15s
+```
+
+New Pod, `Running`, `RESTARTS: 0` — the fix is confirmed, not just assumed.
+
+## Prevent Recurrence
+
+A command override like this is a hand-typed string with no validation until the container
+actually tries to run it. A team that hit this once might decide: don't override a well-known
+image's default command unless there's a specific reason to, and if you must, test the exact
+command string locally (`docker run` or similar) before deploying it — catching a typo in
+seconds locally beats debugging a CrashLoopBackOff in the cluster.
+
+## Instructor Notes
+
+**Demo script:** Run this live if time allows, deliberately narrating which framework step
+you're on at each command — students retain the framework far better tied to real commands than
+as an abstract list.
+
+**Approximate timing:** 8-10 minutes live; 5-7 minutes self-paced.
+
+**Common misconception to preempt:** students sometimes skip straight from "Observe" to
+"Repair" once they spot the typo, without stating a hypothesis or testing it. Reinforce that
+even an "obvious" fix benefits from the explicit hypothesis step — it's what makes the eventual
+Validate step meaningful (you're confirming a SPECIFIC claim, not just "trying something").
+
+**Optional extension:** ask what evidence you'd gather differently if the logs had been
+completely empty instead of showing a clear nginx error (a good bridge to cases where the
+container dies before it can log anything at all — `kubectl describe pod`'s Events section
+becomes the primary evidence source in that case, same as the gold module's probe-mismatch
+lesson).

content/root/root-10-kubernetes-troubleshooting-observability/m03-troubleshooting-framework/03-knowledge-check.md

@@ -0,0 +1,50 @@
+# Knowledge Check: The Troubleshooting Framework
+
+---
+
+**1. You spot what looks like an obvious typo causing a failure and fix it immediately without
+writing down a hypothesis first. What's the actual cost of skipping that step, even if the fix
+works?**
+
+*Answer:* You don't get a confirmed, testable claim about the cause — if the fix happens to
+"work" for an unrelated reason (a coincidental restart, a different underlying issue also
+resolving), you'd have no way to distinguish that from your fix actually being correct. The
+hypothesis step is what makes Validate meaningful.
+
+---
+
+**2. During the "Gather Evidence" step for a CrashLoopBackOff, which two commands give you the
+most direct evidence, and what does each one tell you that the other doesn't?**
+
+*Answer:* `kubectl logs` (what the container itself printed, if anything, before exiting) and
+`kubectl describe pod`/`describe deployment` (the container's actual configuration, plus recent
+Events). Logs show application-level output; describe/Events show what Kubernetes itself
+observed and configured — a crash with no logs at all often means the failure happened before
+the application could log anything, which describe/Events can still reveal.
+
+---
+
+**3. True or false: "Prevent Recurrence" only applies to major incidents, not small
+one-off mistakes like a typo.**
+
+*Answer:* False. A small mistake that recurs repeatedly across a team becomes a real, ongoing
+cost even if no single instance is severe — the framework applies the same reasoning regardless
+of incident size: could a small, structural change catch this earlier next time?
+
+---
+
+**4. A broken Service selector (endpoint-fix-task's scenario) and a CrashLoopBackOff
+(crashloop-fix's scenario) are very different failures. What's the SAME about how you'd
+approach both?**
+
+*Answer:* The same seven-step framework — Observe the specific symptom, Gather Evidence before
+guessing, form a specific testable Hypothesis, Test it, make the minimal Repair the evidence
+supports, Validate with the same kind of evidence you started with, and consider how to Prevent
+Recurrence. The framework doesn't change; only the specific commands and evidence do.
+
+## Instructor Notes
+
+**Facilitation:** Question 4 is the whole point of this module — make sure it's discussed even
+if answered correctly, since it's the transferability claim the entire framework rests on.
+
+**Approximate timing:** 5-7 minutes.

content/root/root-12-real-ops/m01-real-ops-incidents/00-lesson-incident-response.md

@@ -0,0 +1,88 @@
+# The RootNode Incident-Response Framework
+
+## This module feels different on purpose
+
+Everything before ROOT 12 asked you to complete an exercise. This module asks something
+different: **you are responsible for this environment.** The incidents in this module are
+modeled on real operational failures — not textbook exercises designed to teach one clean
+concept, but the kind of messy, "why is this actually broken" situations a real on-call engineer
+gets paged for.
+
+## Detect → Triage → Diagnose → Mitigate → Recover → Verify → Learn
+
+This is a lightweight incident-response framework — not enterprise incident management
+tooling, just a way of thinking that scales down to "one engineer, one broken thing" as well as
+it scales up to a real incident-response team.
+
+**Detect** — something alerted you (a monitoring page, a user report, or in this Lab's case,
+the scenario telling you something is wrong). You know an incident exists before you know what
+it is.
+
+**Triage** — how bad is this, right now, before you dive into root cause? Is anything actively
+getting worse? Is this affecting one thing or cascading into others? Triage decides how urgently
+you act, before you fully understand why.
+
+**Diagnose** — this is where ROOT 10's troubleshooting framework (Observe, Gather Evidence, Form
+Hypothesis, Test) does its work — the specific mechanics of finding the actual cause.
+
+**Mitigate** — the fastest safe action that stops things from getting worse, which is not always
+the same as the final fix. Sometimes mitigation and repair are the same step; sometimes
+mitigation buys time (e.g. temporarily reducing load) while a proper fix is prepared.
+
+**Recover** — restore the system to its actual working state — not just "stopped getting worse"
+but genuinely operational again.
+
+**Verify** — confirm recovery with real evidence, the same discipline as ROOT 10's Validate
+step. "I think it's fixed" is not the same as checking.
+
+**Learn** — what would prevent this exact class of incident from happening again? This is where
+`rootnode-enforce-limits` picks up directly after `rootnode-runaway-monitor` — not a separate
+topic, but the deliberate "Learn" step of the SAME incident, made into its own scenario.
+
+## What this module will NOT tell you
+
+The specific fixes for each incident are not in this lesson, and instructor notes on the
+individual incident activities go deeper than what's shown here — this module gives you the
+FRAMEWORK for approaching an unfamiliar incident, not a cheat sheet for these specific four.
+That's deliberate: a framework you had to apply yourself is one you'll actually remember under
+real pressure.
+
+## Instructor Notes
+
+**Lesson goal:** Set the tone shift for this entire module — from "complete an exercise" to
+"you own this." This lesson is short by design; the real teaching happens through the incidents
+themselves.
+
+**Approximate timing:** 15 minutes read; 10 minutes live framing discussion.
+
+**Preparation:** Read each incident's own instructor notes (in the Lab activities below) before
+teaching this module live — several contain deeper solution guidance not repeated here,
+specifically so students still have to work for it.
+
+**Demonstration plan:** Not applicable to this framing lesson — the four incidents themselves
+serve as the demonstrations.
+
+**Likely misconceptions to watch for:**
+- Students sometimes treat "Mitigate" and "Recover" as the same step. They can be, but aren't
+  always — worth naming a real-world example (rolling back a bad deploy mitigates immediately;
+  fully recovering might still require redeploying the CORRECT version afterward).
+- "Learn" is the step most likely to get skipped once a Lab is marked complete. Explicitly
+  connect it to why `rootnode-enforce-limits` exists as its own scenario.
+
+**Questions to ask students:** "Which step of this framework do you think real teams are worst
+at, under real pressure, and why?" (There's no single right answer — the goal is getting
+students to reason about incident response as a discipline, not just a checklist.)
+
+**When to let a student struggle vs. provide a hint:** These incidents are intentionally less
+guided than earlier modules. Let a student sit with "I don't know where to start" for a few
+minutes before nudging — the discomfort of a genuinely unfamiliar failure is part of what this
+module is teaching. Redirect toward the Diagnose step's ROOT 10 framework if truly stuck, rather
+than pointing at the specific fix.
+
+**Optional extension:** ask students to write a two-sentence incident summary for
+`rootnode-runaway-monitor` as if posting it to a real team channel — Detect/Diagnose/Recover in
+plain language, no jargon.
+
+**Expected takeaway:** A framework applied under pressure beats improvisation, even for
+engineers who are technically skilled enough to eventually stumble into the right answer anyway
+— the framework is what makes the RIGHT answer arrive faster and more reliably.

content/root/root-12-real-ops/m01-real-ops-incidents/99-reflection-post-incident.md

@@ -0,0 +1,47 @@
+# Post-Incident Reflection: What Real Ops Actually Feels Like
+
+You just worked through four incidents that "own it, don't just complete it" framing described.
+Take a few minutes to reflect on the module as a whole, not just any single incident.
+
+## Reflection questions
+
+1. Which of the four incidents took the longest to even understand what was actually wrong,
+   before you got to fixing anything? What made diagnosis slower there than the others?
+2. `rootnode-runaway-monitor` and `rootnode-enforce-limits` are the same underlying incident,
+   split into "fix it now" and "prevent it forever." Which one did you find more satisfying to
+   solve, and why do you think real teams sometimes skip the second one under time pressure?
+3. If you were handing these four incidents off to a teammate mid-shift, what's the one-sentence
+   summary you'd give for each, so they could pick up without re-diagnosing from scratch?
+4. Compare how this module felt to the earlier, more guided modules in ROOT_. What specifically
+   was different about the experience, not just the difficulty?
+
+## Real Ops takeaway
+
+**"It's fixed" and "it won't happen again" are two different jobs, and skipping the second one
+is how the same incident recurs.** `rootnode-enforce-limits` exists as its own scenario
+specifically to make this point structurally, not just rhetorically — the immediate fix and the
+prevention work are genuinely separate efforts, and a real team's incident isn't actually closed
+until both are done.
+
+**Being handed an unfamiliar, under-specified problem is the actual job.** Every other module in
+ROOT_ told you roughly what concept you were about to practice. This one didn't — and that gap
+is deliberate, because real production incidents don't come with a syllabus telling you which
+concept they're testing. The framework from this module's opening lesson is what you reach for
+instead of a hint system.
+
+This module is complete. If a Capstone is part of your program, its readiness module is next.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 2 is the module's core point — spend
+real time on it rather than treating it as a quick check-the-box question.
+
+**Approximate timing:** 10-12 minutes live discussion; 8 minutes self-paced writing.
+
+**Optional extension:** ask students to identify which incident from this module most closely
+resembles something they'd expect to encounter in an actual job, and why — grounds the module in
+something beyond the classroom.
+
+**Expected takeaway:** Real operational work is less about knowing every possible failure mode
+in advance and more about having a repeatable process for approaching the ones you've never
+seen before.

content/root/root-capstone/m02-capstone-readiness/01-lesson-what-it-measures.md

@@ -0,0 +1,72 @@
+# What the Capstone Measures & How the Draw Works
+
+## What the RootNode Capstone is actually testing
+
+The Capstone is not a test of memorized `kubectl` syntax. It's a 90-minute operational
+assessment weighted heavily toward RootNode's own Real Ops incident scenarios — it's checking
+whether you can DO the thing ROOT_ has been building toward: diagnose and repair real,
+under-specified problems using the frameworks and skills from every course before it, under a
+clock, without step-by-step guidance.
+
+If you've completed ROOT 05 through ROOT 12 honestly (not just clicked through), the Capstone is
+testing exactly what you've already practiced — just without a lesson telling you which concept
+is about to be tested.
+
+## How the scenario draw works
+
+The Capstone draws a mix of:
+
+- **Required scenarios** — every attempt includes RootNode's own Real Ops incidents (the same
+  scenarios from ROOT 12, though a fresh attempt against them, not literally the same completed
+  attempt carried over).
+- **Randomly drawn scenarios** — a smaller number of additional scenarios, randomly selected
+  from broader pools spanning workloads, configuration, and troubleshooting.
+
+This means two students taking the Capstone will very likely see a different exact mix of
+random scenarios, while both always face the same core Real Ops incidents. The exact scenario
+IDs and the random draw itself are never published in advance — see the next lesson for why
+that's intentional, not withheld information.
+
+## What "unlocked" actually means
+
+The Capstone doesn't unlock just because you decided you're ready — it unlocks when the
+platform confirms, server-side, that you've genuinely completed every prerequisite stage
+(Foundation, Workloads, Networking, Configuration, Troubleshooting, and Real Ops). This isn't a
+UI suggestion you can bypass; it's enforced the same way everywhere you'd try to start it. If
+you see a "locked" message, the platform is telling you something true about your actual
+progress, not gatekeeping arbitrarily.
+
+## What completion means
+
+Passing the Capstone requires resolving every scenario in your specific draw — this is recorded
+as a real, permanent achievement (`capstone_completed`) tied to your account, the same
+achievement mechanism that recorded every stage completion before it. It's the platform's own
+confirmation that you can operate a Kubernetes environment under exam conditions, not just that
+you clicked through a curriculum.
+
+## Instructor Notes
+
+**Lesson goal:** Set accurate expectations before a student attempts the real assessment —
+reduce anxiety from not knowing "what kind of thing" the Capstone tests, without revealing any
+specific content.
+
+**Approximate timing:** 10 minutes read; 8-10 minutes live.
+
+**Preparation:** None beyond having completed ROOT 12 yourself if teaching this live, so you can
+speak concretely about the Real Ops incidents' style without naming specifics from the current
+draw pool.
+
+**Likely misconceptions to watch for:**
+- Students sometimes think "random draw" means the Capstone is inconsistent/unfair between
+  attempts. Clarify: the REQUIRED Real Ops scenarios are constant across every attempt; only a
+  smaller supplementary set is randomized.
+- "It's locked, so something's broken" — reinforce that a locked Capstone is the platform
+  correctly reporting incomplete prerequisites, not a bug.
+
+**Questions to ask students:** "Which ROOT_ course do you feel least confident about right now?
+What would you do about that before attempting the Capstone?" — a good self-assessment prompt
+that ties directly into the next lesson's time-management content.
+
+**Expected takeaway:** The Capstone measures real operational capability built across the whole
+ROOT_ sequence — approaching it as "one more scenario to guess your way through" misses the
+point of everything that led up to it.

content/root/root-capstone/m02-capstone-readiness/02-lesson-time-management.md

@@ -0,0 +1,66 @@
+# Time Management & Troubleshooting Strategy Under a Clock
+
+## 90 minutes, several scenarios — budget before you start
+
+Once the Capstone begins, the clock is running against the whole attempt, not per scenario.
+Spending 60 of your 90 minutes perfectly solving one incident, then rushing (or failing to
+attempt) the remaining ones, is a worse outcome than solving most scenarios well within a
+reasonable time each. Before diving into the first incident, take 60 seconds to look at how many
+scenarios you're facing and roughly divide your available time — treat that budget as a real
+constraint, not a suggestion.
+
+## Apply the frameworks you already have — don't invent a new approach under pressure
+
+You've already practiced two frameworks across ROOT_:
+
+- **Observe → Gather Evidence → Form Hypothesis → Test → Repair → Validate → Prevent Recurrence**
+  (ROOT 10) for the mechanics of diagnosing a specific technical failure.
+- **Detect → Triage → Diagnose → Mitigate → Recover → Verify → Learn** (ROOT 12) for the
+  broader "you own this incident" framing.
+
+Under time pressure, the temptation is to abandon structure and start guessing. Resist it — the
+frameworks exist precisely because they're FASTER than guessing once you've internalized them,
+not slower. Reach for the same habits: read `kubectl describe`/Events before assuming, state
+what you think is wrong before changing anything, verify after you fix.
+
+## When to move on
+
+If you're genuinely stuck on one scenario well past its budgeted time with no new evidence
+emerging, it is a legitimate strategic choice to move to a different scenario and return later
+if time allows — partial credit on more scenarios can beat a perfect score on fewer. This isn't
+giving up; it's the same triage instinct from the incident-response framework, applied to your
+own time as a resource.
+
+## What's genuinely allowed
+
+Everything you've used throughout ROOT_ Labs remains available: `kubectl` and its full command
+set, the Lab's own in-context hints (if the specific scenario offers them), and your own notes
+from earlier modules. There is no expectation of memorizing anything you'd normally look up —
+the Capstone tests operational judgment and diagnostic process, not recall of obscure flags.
+
+## Instructor Notes
+
+**Lesson goal:** Reduce a common source of avoidable Capstone underperformance — poor time
+allocation — separately from technical skill gaps.
+
+**Approximate timing:** 10 minutes read; 8 minutes live.
+
+**Demonstration plan:** If teaching this live, consider a quick show-of-hands: "who has ever
+spent way too long on one problem and run out of time for an easier one elsewhere?" — normalizes
+the behavior this lesson is trying to prevent.
+
+**Likely misconceptions to watch for:**
+- Students sometimes think asking for more time or pausing mid-scenario is against the rules.
+  Clarify based on your actual classroom/platform policy rather than assuming — this varies by
+  delivery mode and isn't something this lesson should guess at.
+
+**Questions to ask students:** "If you had to guess right now, which TYPE of scenario (not a
+specific one) do you think would eat the most of your time, and why?" — surfaces self-awareness
+about weak areas before the real attempt.
+
+**When to let a student struggle vs. provide a hint:** This lesson itself needs no struggle —
+it's orientation, not a challenge. Save "let them struggle" judgment for the actual Capstone
+attempt.
+
+**Expected takeaway:** Time management under the Capstone's clock is a skill you can prepare for
+explicitly, separate from and in addition to the technical skills the rest of ROOT_ built.

content/root/root-capstone/m02-capstone-readiness/03-knowledge-check.md

@@ -0,0 +1,58 @@
+# Readiness Check: Are You Actually Ready?
+
+This isn't a graded quiz — it's a genuine self-assessment before you attempt something you can't
+easily "retry with different answers memorized." Answer each honestly.
+
+---
+
+**1. Can you explain, without looking it up, the difference between a liveness probe and a
+readiness probe, and diagnose which one is failing from `kubectl get pods` output alone?**
+
+*If no:* revisit ROOT 10's gold-standard Health Probes module before attempting the Capstone —
+this exact distinction shows up in Real Ops-style incidents.
+
+---
+
+**2. Given a Service with zero Endpoints, do you know the first two commands you'd run to find
+out why, without being told which module this relates to?**
+
+*If no:* revisit ROOT 07's Services & Service Discovery module.
+
+---
+
+**3. Can you apply the Observe → Evidence → Hypothesis → Test → Repair → Validate → Prevent
+framework to an unfamiliar failure you've never specifically seen before, not just to the exact
+examples from the lesson?**
+
+*If no:* this is worth practicing deliberately — pick any Practice-tab scenario you haven't done
+yet and narrate the framework out loud to yourself while solving it.
+
+---
+
+**4. Have you completed the Real Ops incidents in ROOT 12 for real — diagnosed and repaired
+them yourself, not looked up the answer?**
+
+*If no:* do this before attempting the Capstone. The required scenarios in every Capstone
+attempt are drawn from exactly this style of incident.
+
+---
+
+**5. Do you have a rough time-budget plan for a 90-minute, multi-scenario attempt?**
+
+*If no:* re-read the time-management lesson in this module before you begin.
+
+## What to do if you answered "no" to more than one
+
+That's genuinely useful information, not a failure — it tells you specifically where to spend
+your remaining prep time. Go back to the relevant module, do the work for real, and come back
+to this check again before attempting the Capstone.
+
+## Instructor Notes
+
+**Facilitation:** In a live classroom, this works well as private/individual reflection rather
+than a group discussion — the value is honest self-assessment, not a public performance.
+
+**Approximate timing:** 5-8 minutes.
+
+**Expected takeaway:** Readiness is something a student can genuinely self-assess against
+concrete, specific criteria — not a vague feeling of confidence.

content/root/root-capstone/m02-capstone-readiness/04-reflection-readiness.md

@@ -0,0 +1,42 @@
+# Readiness Reflection: What Completion Means
+
+Before you move toward the actual Capstone attempt, take a moment to reflect on the whole ROOT_
+journey up to this point.
+
+## Reflection questions
+
+1. Think back to ROOT 05's opening lesson on desired state. How differently would you explain
+   that concept now, after everything since, compared to how you understood it the first time?
+2. Which single module across ROOT_ changed how you approach a problem the most — not which was
+   most interesting, but which actually changed your behavior when something breaks?
+3. What does passing the Capstone mean to you, beyond a completion record on the platform?
+
+## What completion actually represents
+
+A `capstone_completed` achievement isn't a certificate claiming you've memorized Kubernetes
+trivia. It's the platform's record that you demonstrated, under real time pressure, without
+step-by-step guidance, that you can diagnose and repair real operational problems using
+frameworks you internalized rather than looked up in the moment. That's a materially different
+and more durable skill than passing a multiple-choice exam about Kubernetes objects.
+
+## When you're ready
+
+There's no "perfect" moment where every module feels fully mastered — that's normal. If the
+readiness check in the previous activity mostly came back "yes," and you've done the Real Ops
+incidents for real, you're ready to attempt it. The Capstone will unlock automatically once the
+platform confirms your prerequisite stages are genuinely complete — when you see it unlocked,
+that's the platform's own confirmation, not just this module's.
+
+This module is complete. Good luck.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 2 tends to produce genuinely varied,
+interesting answers across a cohort — worth having students share out loud if time allows.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
+
+**Preparation:** None — this is a closing/orientation activity, not a technical one.
+
+**Expected takeaway:** Completing ROOT_'s Kubernetes sequence is a real, demonstrable skill
+change, not just curriculum progress — the Capstone is where that becomes visible and provable.

docs/COURSE_AUTHORING_STANDARD.md

@@ -0,0 +1,137 @@
+# Course Authoring Standard
+
+Phase 6A §11 — the standard every future RootNode lesson/module must follow, so a future Claude
+Code session or a human instructor can author content consistently. The module at
+`content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/` (backing
+`root-10-m01-health-probes-and-troubleshooting`) is the reference implementation — when in
+doubt, read it before writing new content.
+
+## 1. Target learner
+
+State explicitly, in the module's Postgres `description` (not buried in prose): who this is for
+and what they're assumed to already know. root_ targets ages ~15-18+ through adult learners
+(see `docs/PHASE6A_ROOT_COURSE_FOUNDATION.md` §1) — write at a level that respects that range;
+don't write down to it.
+
+## 2. Prerequisites
+
+Declare real prerequisite course/module ids in the `prerequisites` column, not prose alone (see
+`docs/COURSE_CONTENT_MODEL.md` §5 for how locking derives from this). If a module assumes a
+concept the platform doesn't yet teach anywhere, say so explicitly in the module description
+rather than silently assuming it.
+
+## 3. Measurable objectives
+
+3-5 objectives per module, stored in the `objectives` column, each a sentence that starts with a
+verb describing an observable capability ("Diagnose...", "Configure...", "Explain..."), not a
+topic list ("Probes"). A learner (or an instructor) should be able to look at an objective and
+know whether it was met.
+
+## 4. Estimated time
+
+Set `estimated_duration_minutes` per activity and let the module/course total derive from the
+sum — don't hand-guess a module-level number that doesn't match its activities. Time estimates
+are honest guesses, not commitments; revise them once real completion-time data exists (the
+mechanically-mapped modules' per-scenario 15/20/30-minute estimates in
+`022_course_content.sql` are explicitly flagged as a rough heuristic for exactly this reason).
+
+## 5. Concept explanation (the `lesson` activity)
+
+Explain the underlying concept BEFORE any lab is presented — this is the module's core
+pedagogical premise (see `docs/PHASE6A_ROOT_COURSE_FOUNDATION.md`'s "core product principle").
+Cover: why the concept/mechanism exists (the problem it solves), the mechanism itself, and
+common real-world mistakes. Use concrete, runnable examples (`kubectl` output, YAML snippets)
+over abstract description wherever possible.
+
+## 6. Demonstration
+
+Show the concept in action with a worked example BEFORE asking the learner to do it themselves.
+A demonstration activity should include what the learner would actually SEE (real-looking
+command output), not just a description of what would happen.
+
+## 7. Guided practice (the `guided_exercise` activity)
+
+Lower-stakes practice with a visible worked answer to check against (paper/scratch-file
+exercises are fine — see the gold module's readiness-probe exercise). The goal is committing to
+an answer and comparing, not passively reading a correct one first.
+
+## 8. Independent practice → lab mapping
+
+A `lab` activity references an EXISTING `scenario_id` — never invent duplicate lab content when
+an existing scenario already teaches the concept (check `docs/ROOT_CURRICULUM_INVENTORY.md`
+first). Write a short `content_path` intro (see the gold module's `05-lab-intro.md`) that
+connects what was just taught to the incident the student is about to solve, without handing out
+the scenario's own hints/solution — the Lab's own progressive hints stay the only place the
+actual answer path lives.
+
+### Classifying near-duplicate or advanced scenarios (Phase 6B)
+
+When two scenarios teach essentially the same concept (e.g. `pod-security-context` and
+`cks-pod-security-context`), don't wire both as required core labs — pick the better-fitting one
+as CORE and mark the other `is_required = false` as INDEPENDENT PRACTICE (see
+`docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md`'s "duplicate concepts identified" for worked examples).
+Likewise, a genuinely harder or more niche scenario (CKS-exam-style, a less commonly needed
+skill) belongs as `is_required = false` GUIDED/ADVANCED practice, not force-fit into the
+required core path just because it exists — see `docs/COURSE_CONTENT_MODEL.md`'s optional-vs-
+required section for how this affects module completion.
+
+## 9. Knowledge check
+
+A handful of self-check questions with answers shown inline (not a graded exam — that's what the
+assessment engine is for). Use plain Markdown (`*Answer:*` after each question), not raw HTML
+`<details>` — `react-markdown` renders this repo's course content and does not have `rehype-raw`
+enabled, so raw HTML tags render as literal text, not a collapsible element.
+
+## 10. Reflection
+
+A reflection activity consolidates and connects to real-world judgment — it is not a second
+knowledge check. Ask "why does this matter beyond this one Lab," not "what did you just do."
+Include a "Real Ops takeaway": a concrete prevention/production practice a learner could apply
+on a real team.
+
+## 11. Instructor notes
+
+Every activity type CAN have an `## Instructor Notes` section (see
+`docs/COURSE_CONTENT_MODEL.md` §3); a `lesson`/`demonstration`/`guided_exercise`/`reflection`
+activity SHOULD have one. At minimum include: approximate timing, one likely misconception to
+watch for, and (where relevant) a discussion question or optional extension activity. Keep it
+actionable — a bullet list an instructor can glance at mid-class, not a second essay.
+
+## 12. Accessibility/readability
+
+Plain Markdown only (headings, lists, code fences, bold/italic, tables) — no content that
+depends on color alone to convey meaning, no ASCII art carrying information a screen reader
+would lose. Write short paragraphs; prefer lists over dense prose for anything enumerable
+(steps, mistakes, questions).
+
+## 13. Terminology rules
+
+Match the terminology the scenario JSON and existing Platform UI already use exactly (e.g.
+"readiness probe," not "health check probe" — check `scenarios/data/<id>.json`'s own
+`description`/`hints` for the canonical phrasing before introducing a lesson's own term for the
+same thing). Define a term the first time it's used in a module; don't assume a prerequisite
+module's terminology carried over without a one-line reminder.
+
+## 14. Versioning
+
+Bump the `version` integer on courses/course_modules/module_activities by hand on any semantic
+content edit — same convention `assessment_definitions`/`programs` already use. A version bump
+is informational only in Phase 6A (nothing snapshots against it the way an assessment session
+snapshots its definition version) — it exists so a future phase can detect "this changed since a
+student last saw it" without re-deriving that from `updated_at` alone.
+
+## 15. Review/testing requirements
+
+Before marking a module `status = 'ready'`:
+
+- Every activity's `content_path` file must exist and load (verify via
+  `platform/api/src/content.js`'s `loadContent`, or just hit the admin curriculum API and check
+  `body` is non-empty).
+- A `lab` activity's `scenario_id` must be a real, existing scenario id.
+- An `assessment`/`capstone` activity's `assessment_definition_id` must be a real, active
+  `assessment_definitions` row.
+- Walk the module once as a self-paced student end to end (lesson → ... → lab → reflection),
+  and once through the instructor Curriculum view, before shipping — this is what
+  `e2e-phase6a.js` and `infra/scripts/drills/test-phase6a-course-rehearsal.js` automate for the
+  gold module; extend one of them (or add a new phase-scoped test) for future modules rather
+  than skipping this step.

docs/COURSE_CONTENT_MODEL.md

@@ -0,0 +1,162 @@
+# Course Content Model
+
+Phase 6A §3 — how RootNode represents actual teaching content (lessons, demonstrations,
+knowledge checks, guided exercises, reflections) around the existing scenario/assessment
+systems, without duplicating either. See `docs/ROOT_PROGRAM_ARCHITECTURE.md` for what this
+model is populated with, and `docs/COURSE_AUTHORING_STANDARD.md` for how to author new content
+against it.
+
+## 1. Shape
+
+```
+program (existing, 019_programs.sql — unchanged)
+  → course            (new: courses)
+      → module         (new: course_modules)
+          → activity    (new: module_activities)
+```
+
+`platform/api/migrations/022_course_content.sql` is the schema. Every table follows the same
+conventions already established by `programs`/`assessment_definitions`: a TEXT slug primary key,
+a plain incrementing `version` integer bumped by hand on a semantic edit, `status`/`visibility`
+CHECK constraints, `created_at`/`updated_at`.
+
+## 2. Activity types and what they reference
+
+| Type | References | Completion behavior |
+|---|---|---|
+| `lesson`, `demonstration`, `knowledge_check`, `guided_exercise`, `reflection` | a Markdown file (`content_path`) | `manual_marker` |
+| `lab` | an EXISTING `scenario_id` (scenarios/data/\*.json) | `auto_scenario` |
+| `assessment`, `capstone` | an EXISTING `assessment_definition_id` (`assessment_definitions`) | `auto_assessment` |
+
+A `lab` activity never duplicates scenario content — it stores a bare `scenario_id` string, the
+same id the existing curriculum/attempt/progress system already uses. An `assessment`/`capstone`
+activity never duplicates an assessment definition — it stores the existing
+`assessment_definition_id` and a foreign key enforces it actually exists. Neither activity type
+is prevented from also having its own `content_path` (e.g. the gold module's lab activity has a
+short Markdown intro at `05-lab-intro.md`) — that's framing prose around the reference, not a
+copy of the referenced thing.
+
+## 3. Where the prose lives
+
+Long-form lesson content is git-tracked Markdown under `content/root/<course>/<module>/`, not
+Postgres. Reasoning, weighed explicitly per the authorization's instruction:
+
+- **Reviewable like code.** A lesson edit is a normal diff/PR, not an opaque row update.
+- **No CMS needed.** The authorization explicitly ruled one out ("Do not build a complex CMS").
+  A Postgres TEXT column holding Markdown would technically work but loses git history/diffing
+  for the one thing (prose) that benefits from it most.
+- **Structural metadata still belongs in Postgres** (ordering, type, references, status,
+  objectives, prerequisites) because it's queried, joined, and mutated (locking/completion) —
+  exactly the kind of relational state Postgres is for, and exactly what the authorization asked
+  for ("Postgres preferred for metadata/state").
+
+### The Instructor Notes convention
+
+One Markdown file per activity, not two. Everything before a `## Instructor Notes` heading is
+shared (self-paced-visible) content; that heading and everything after it is instructor-only.
+`platform/api/src/content.js` does the split (`splitContent()`) — a plain string search on that
+exact heading, no frontmatter parser, no template engine. The API layer (`course-progress.js`'s
+`shapeActivity()`) only ever attaches `instructor_notes` to the response when the caller is
+resolved (server-side, from session identity) to be an instructor — never from a request
+parameter. A self-paced student and an instructor read the identical file; they just see
+different slices of it.
+
+## 4. Completion rules — one source of truth per behavior
+
+`platform/api/src/course-progress.js`'s `isActivityComplete()` is the only place completion is
+decided, and it never invents new state for anything that's independently verifiable:
+
+- **`auto_scenario`** — reads `progress[scenario_id].status === 'completed'`, the exact same
+  `progress` table `curriculum-rules.js` already reads for stage completion (`platform/api/src/
+  progress.js`'s `loadProgress`). A lab activity's completion is a real fact about whether the
+  student actually solved the scenario, not a flag a course layer could get out of sync with.
+- **`auto_assessment`** — reads `achievements` (`achievement_type IN ('assessment_completed',
+  'capstone_completed')` with `metadata->>'assessment_definition_id'` matching), the exact
+  mechanism `achievements.js`'s `recordAssessmentAchievement` already writes on a real pass. No
+  new achievement type, no new table.
+- **`manual_marker`** — the ONE new piece of state this phase adds: `activity_completions`
+  (student_id, activity_id). Used ONLY for activity types with nothing else to derive completion
+  from (a lesson has no "pass/fail," a reflection has no validator). `POST /api/student/
+  activities/:id/complete` refuses (409 `not_manually_completable`) for any activity whose
+  `completion_behavior` isn't `manual_marker` — a student can never fake a lab or assessment
+  completion through this route.
+
+Course and module completion are pure aggregates over their activities' completion (`total`/
+`completed`/`pct`/`complete` — see `totals()`), never separately stored.
+
+### Optional vs. required activities (Phase 6B)
+
+`module_activities.is_required` (defaults `true`) lets a module distinguish CORE teaching from
+GUIDED/INDEPENDENT-practice duplicates and ADVANCED/optional extras — see
+`docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md`'s classification scheme, used throughout ROOT 09. A
+module's `complete` flag is true once every REQUIRED activity is done; an incomplete optional
+activity never blocks it, though `total`/`pct` still count every activity, required or not.
+Every Phase 6A activity has `is_required = true` (the column's default) — this is purely
+additive, nothing that was complete before Phase 6B becomes incomplete now.
+
+## 5. Prerequisite/locking rule
+
+A course or module lists `prerequisites` (an array of other course/module ids). It's locked if
+ANY prerequisite is not satisfied, where **satisfied** means: the prerequisite has zero total
+activities (a PLANNED entry — vacuously satisfied, since there's nothing to have completed) OR
+the prerequisite is fully complete. This is deliberate: without the "zero activities is vacuously
+satisfied" clause, an honestly-PLANNED course with no content yet would permanently lock every
+real course that lists it as a prerequisite, which would perversely punish honesty about what
+isn't built yet. See `course-progress.js`'s `prerequisitesSatisfied()`.
+
+Locking is computed in two passes over each level (compute every entry's totals/prerequisite-
+check, THEN strip working state) rather than one — mutating and reading totals in the same pass
+made the result depend on Map iteration order, a real bug caught by `e2e-phase6a.js` during
+development (see that file's "found by testing" comment in `course-progress.js`).
+
+## 6. Draft vs. published — separate from READY/PARTIAL/PLANNED
+
+`status` (`ready`/`partial`/`planned`) describes authoring completeness and is shown to
+everyone, including students, honestly ("PLANNED — coming soon" is useful information, not a
+leak). `visibility` (`published`/`draft`) is a hard gate: a `draft` course/module/activity is
+excluded from every query a student-facing route runs (`buildCourseTree`'s `visClause`), full
+stop, regardless of its `status`. Use `draft` for genuinely unfinished authoring work you don't
+want a student to see at all yet; use `status = planned` for an honest "not built yet" that's
+fine to be visible.
+
+## 6b. Content versioning (Phase 6B §21)
+
+Follows the exact same convention `assessment_definitions`/`programs` already established — a
+plain incrementing `version` integer, bumped by hand, informational rather than enforced:
+
+- **A typo-only edit** (fixing a spelling mistake, a broken link, rewording a sentence without
+  changing its meaning) does NOT require a version bump — nothing about what a student is being
+  taught or held to changed.
+- **A semantic edit** (changing a learning objective, swapping a lab's `scenario_id`, changing
+  `completion_behavior`, adding/removing/reordering activities in a way that changes what
+  "complete" means) SHOULD bump `version` on the affected row(s) — see
+  `023_phase6b_curriculum.sql`'s own `version = version + 1` on every row it semantically
+  changes (resequencing, prerequisite changes, `is_required` changes).
+- **What happens to existing completions**: nothing, automatically. Unlike an assessment
+  session (which snapshots the definition version it was drawn against, because a session is a
+  point-in-time timed attempt), a course/module/activity's completion is derived LIVE every time
+  it's read (`course-progress.js`) from the CURRENT row plus the student's progress/achievements/
+  activity_completions — there is no snapshot to invalidate. A `manual_marker` completion
+  (`activity_completions`) is keyed by `activity_id`, which is stable across a version bump
+  (the id doesn't change, only its content/metadata does) — so a student's prior "I did this"
+  record stays valid even after a semantic edit, exactly like editing a scenario's own
+  Markdown description doesn't retroactively un-complete it in `progress`.
+- **Scenario references across versions**: a `lab` activity's `scenario_id` is just a string
+  reference into `scenarios/data/*.json` — if that scenario file itself changes, the activity
+  automatically reflects the new content next time it's loaded (same as every other consumer of
+  `curriculum.js`'s cache). If an activity's `scenario_id` itself is changed to point at a
+  DIFFERENT scenario, that's a semantic edit (bump the version) and — depending on intent — may
+  warrant a new `activity_id` instead of mutating the existing one, so a student's prior
+  completion of the OLD scenario isn't silently reinterpreted as completion of the new one.
+- **What this deliberately does NOT build**: no content-revision history table, no diffing, no
+  "students who saw v1 vs v2" cohort tracking. If a future phase needs that level of rigor
+  (e.g. for compliance/audit reasons), it's a real, separate feature — not something to bolt
+  onto a plain integer column.
+
+## 7. Why this doesn't touch Phase 1-5 systems
+
+No column was added to `scenarios/*.json`, `assessment_definitions`, `achievements`,
+`progress`, or `scenario_attempts`. No existing API route's behavior changed (the `/api/
+progress/record`, `/api/assessments/*`, `/api/capstone` routes are byte-for-byte unchanged).
+The course layer is purely additive: new tables, new routes, new frontend views, reading
+existing tables through their existing shapes.

docs/ENGINEERING_SOP.md

@@ -88,6 +88,12 @@ To add/reorder a stage: edit `rootnode-path.json` directly, referencing existing
 `scenarios/data/*.json` ids. No backend code change needed — it's read fresh via
 `POST /api/cache/reload` or on server restart.
 
+As of Phase 6A, `root_` also has a course/module/activity layer ON TOP of this (lessons,
+demonstrations, guided exercises around the same scenario ids) — see §17 and
+`docs/COURSE_CONTENT_MODEL.md`. `rootnode-path.json` itself is unmodified and still the thing
+`curriculum-rules.js` computes stage lock/completion from; the course layer is a parallel,
+additive structure that references the same scenario ids, not a replacement.
+
 ## 5. Student identity — what's built, what isn't
 
 **Current state (Phase 5A — see `docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md` for the
@@ -357,3 +363,132 @@ Full design: `docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md`, plus
   students and confirming zero orphaned data) — both against a live `docker-compose.dev.yml`
   stack, not mocks. The full pre-existing regression suite was re-run given how much shared code
   this phase touched (`server.js`, `admin-routes.js`, `sessions.js`, `rbac.js`).
+
+## 15. Self-Paced Learning & Enrollment Foundation (Phase 5B)
+
+Full design: `docs/PHASE5B_SELF_PACED_ENROLLMENT.md`, plus
+`docs/RUNBOOK_SELF_PACED_ENROLLMENT.md` and `docs/WEBSITE_ENROLLMENT_INTEGRATION.md`.
+
+- **What it is:** `programs` (a first-class learning product, distinct from curriculum JSON —
+  `curriculum_path` is just what it points at) and `enrollments` (a student's academic access to
+  a program, independent of cohort membership — a self-paced enrollment has no cohort at all).
+  Server-enforced entitlement (`enrollment.deriveEnrollmentAccess`, mirroring `classroom.js`'s
+  derived-not-stored `derivePresence` pattern from Phase 5A) gates a new
+  `POST /api/student/programs/:id/launch` in front of the exact same disposable-Lab sequence
+  `/api/environment/launch` already used (extracted into `environment-view.js` so both share one
+  implementation) — pending/future/expired/cancelled enrollments cannot launch, server-side, not
+  just hidden in the UI. Completion is entirely server-derived from the existing capstone
+  achievement mechanism (Phase 3B, unmodified) and idempotent. A new, separate
+  `POST /api/integrations/enrollments` boundary (its own pre-shared-secret auth, no session
+  cookie involved — same trust-boundary pattern as Gateway↔Provisioner's
+  `PROVISIONER_SHARED_SECRET`) is what the *separate* public website will eventually call;
+  idempotent via a DB unique constraint on the caller's own event id, proven safe under real
+  concurrent duplicate requests, not just sequential retries.
+- **A real bug found and fixed:** `POST /api/progress/record` predated the `wrap()`
+  async-error-handling convention — an unexpected internal error there (a malformed
+  `environment_id`) crashed the entire Platform API process, not just that one request. Fixed
+  (wrapped + input-validated) and regression-tested.
+- **Tested, not just designed:** `platform/test/e2e-phase5b.js` (32 checks) and
+  `infra/scripts/drills/test-phase5b-selfpaced-rehearsal.js` (15 checks) — both against a live
+  stack, including real Lab destroy/reaper-reconciliation/recreate persistence proofs, a full
+  real capstone completion, integration-endpoint concurrency, and a real Platform API restart.
+  Migration safety proven explicitly against a fresh Postgres seeded with realistic pre-5B data
+  (see that doc §14).
+
+## 16. Enrollment Operations & Communications (Phase 5C)
+
+Full design: `docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md`, plus
+`docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md` and `docs/RUNBOOK_STUDENT_ACTIVATION.md`.
+
+- **What it is:** a durable, provider-neutral notification pipeline (`notification_events`, a
+  `FOR UPDATE SKIP LOCKED` worker polling on a plain `setInterval` — same pattern as the
+  existing session/login-attempt sweepers, no new infrastructure) that finally sends real email
+  for activation, enrollment confirmation, password reset, and password-changed — closing the
+  gap Phase 5A explicitly left open. Google Workspace adapter: Gmail API via a service account
+  with domain-wide delegation (no human password, no SMTP basic auth — see that doc §2 for why),
+  behind the same provider interface a deterministic dev provider implements, so no test or dev
+  run ever reaches a real inbox. Reuses Phase 5A's activation/reset token mechanism entirely — no
+  competing invitation-token system.
+- **A real bug found and fixed:** `request-password-reset` would mint a reset token for a
+  never-activated student, which doesn't make sense (there's no password yet to reset) and would
+  have sent a confusing email. Fixed to fall through to the same anti-enumeration response as a
+  nonexistent account.
+- **Tested, not just designed:** `platform/test/e2e-phase5c.js` (28 checks: activation vs.
+  confirmation routing, duplicate/concurrent webhook idempotency, temporary/permanent/exhausted
+  retry classification, resend/regenerate token invalidation, production token-secrecy gating
+  via a real container recreate with `COOKIE_SECURE=1`, minor/contact-email resolution, RBAC
+  scoping, metrics/audit hygiene, a real restart) and
+  `infra/scripts/drills/test-phase5c-enrollment-activation.js` (10 checks: one continuous story
+  from website enrollment through a real rendered/extracted activation email, a real Lab launch
+  and scenario completion, a second enrollment's confirmation email, and a full password-reset
+  round trip) — both against a live stack, using only the dev provider (no real network calls).
+  Live Google Workspace delivery has since been validated for real, end to end, via
+  `academy@rootnodeacademy.com` — see `docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md` §14.
+
+## 17. ROOT_ Course Architecture + Content Delivery Foundation (Phase 6A)
+
+Full design: `docs/PHASE6A_ROOT_COURSE_FOUNDATION.md`, plus `docs/ROOT_CURRICULUM_INVENTORY.md`,
+`docs/ROOT_PROGRAM_ARCHITECTURE.md`, `docs/COURSE_CONTENT_MODEL.md`, and
+`docs/COURSE_AUTHORING_STANDARD.md`.
+
+- **What it is:** a course → module → activity content model (`022_course_content.sql`) layered
+  over the existing scenario/assessment/achievement systems for `root_` only, so a lesson can be
+  taught BEFORE a lab is presented instead of the platform only ever showing a bare scenario
+  list. A `lab` activity references an existing `scenario_id`; an `assessment`/`capstone`
+  activity references an existing `assessment_definition_id` — neither duplicates content.
+  Long-form lesson prose lives in git-tracked Markdown (`content/root/`), split into
+  shared/instructor-only sections by a `## Instructor Notes` heading convention
+  (`content.js`). One `buildCourseTree()` (`course-progress.js`) serves both the self-paced
+  student route and the instructor curriculum view — no forked curriculum for the two delivery
+  modes.
+- **Completion, never a second source of truth:** a lab's completion reads the existing
+  `progress` table; an assessment/capstone activity's completion reads the existing
+  `achievements` table; only lesson-only activities (nothing else to derive completion from) get
+  the one genuinely new table, `activity_completions`.
+- **A real bug found and fixed during testing:** computing a module/course's prerequisite lock
+  and then stripping its working totals in the SAME map iteration made the result depend on Map
+  iteration order — a dependent entry could see its prerequisite's totals already deleted. Fixed
+  by splitting into two explicit passes (`course-progress.js`).
+- **One gold-standard module fully authored:** ROOT 10's Kubernetes Health Probes &
+  Troubleshooting (lesson → demonstration → knowledge check → guided exercise → real Lab
+  `rootnode-probe-port-mismatch` → reflection), the template `docs/COURSE_AUTHORING_STANDARD.md`
+  documents for all future modules. Every other course is honestly `partial` (real labs, no
+  lessons yet) or `planned` (no content exists) — nothing was fabricated to look finished.
+- **Tested, not just designed:** `platform/test/e2e-phase6a.js` (21 checks: hierarchy/ordering,
+  all three completion behaviors, prerequisite locking, resume, cross-student isolation, RBAC
+  for self-paced no-cohort students, draft-content hiding, version stability) and
+  `infra/scripts/drills/test-phase6a-course-rehearsal.js` (12 checks, real k3s: a student reads
+  the gold module's real lesson content, launches a real Lab, the Lab's own `setup_commands`
+  stand up the broken deployment, a real `kubectl patch` fixes it, and the module completes and
+  unlocks the next one) — both against a live stack.
+
+## 18. ROOT_ Curriculum Authoring & Coverage Expansion (Phase 6B)
+
+Full design: `docs/PHASE6B_ROOT_CURRICULUM_EXPANSION.md`, plus
+`docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md` and `docs/ROOT_CAPSTONE_READINESS.md`.
+
+- **What it is:** 13 new teaching modules across ROOT 05-10/12/Capstone
+  (`023_phase6b_curriculum.sql`), built entirely from the 98-scenario inventory Phase 6A already
+  catalogued — no new scenarios needed. ROOT 08/09 moved from PLANNED to PARTIAL; scenario
+  coverage in structured curriculum went from 44/98 to 88/98 (89.8%), verified by direct query,
+  not estimated. 3 modules (plus the pre-existing gold standard) reach the full READY bar; every
+  other new module is honestly PARTIAL, missing a demonstration or guided exercise, documented
+  per-module rather than glossed over.
+- **`is_required`** (new `module_activities` column, defaults `true`): distinguishes CORE
+  teaching from GUIDED/INDEPENDENT-practice duplicates and ADVANCED/optional extras — a module
+  is complete once every REQUIRED activity is done; an incomplete optional one never blocks it.
+  Every Phase 6A activity is unaffected (defaults to required).
+- **The capstone server-side unlock fix:** `POST /api/assessments/:id/start` never checked
+  `unlock_rule` before this phase — a direct API call could start the capstone before its
+  prerequisite stages were complete, even though the UI never exposed that path. Fixed by
+  binding to the same `computeCurriculumState()` gate `GET /api/capstone` already used. See
+  `docs/ROOT_CAPSTONE_READINESS.md` §4 for the full story, including a pre-existing gap this
+  fix exposed in `e2e-phase5b.js`'s own capstone test (fixed alongside).
+- **Tested, not just designed:** `platform/test/e2e-phase6b.js` (24 checks: new-module
+  hierarchy, prerequisite chains through the newly-inserted front-door modules, the
+  optional-vs-required completion rule, the capstone bypass fix in both directions, persistence/
+  isolation/RBAC/draft-hiding proven against the new content) and
+  `infra/scripts/drills/test-phase6b-root-course-rehearsal.js` (11 checks, real k3s: a student
+  walks a brand-new module — ROOT 07 Services & Service Discovery — end to end including a real
+  `kubectl expose` against a live cluster, plus an instructor narrative proving Curriculum view,
+  Prepare Labs, and classroom tooling all still work against the expanded curriculum).

docs/LAB_ARCHITECTURE.md

@@ -507,3 +507,28 @@ any of it — the Provisioner, the `environments` state machine, the Lab Host Ro
 Lab lifecycle, and the Platform/Lab-Host VM boundary are all untouched. The classroom dashboard
 reads Lab status the exact same way every other admin view does (`provisioner.listForStudent`,
 the same state enum) rather than inventing a second one.
+
+## Phase 5B: still reused, not modified — a gate in front, not a second Lab
+
+Phase 5B (`docs/PHASE5B_SELF_PACED_ENROLLMENT.md`) added self-paced programs/enrollment on top
+of the exact same disposable Lab this document describes — again without changing the
+Provisioner, `environments`, the reaper, or the Lab Host Router at all. A self-paced launch
+(`POST /api/student/programs/:id/launch`) is an entitlement check followed by calling the
+identical launch sequence `/api/environment/launch` always has — verified for real by killing a
+Lab container out-of-band and restarting the Provisioner to trigger its actual
+`reconcileOnStartup` reconciliation path (the same technique Phase 4.1's
+`test-lab-host-loss.js` established), then confirming a self-paced student's academic progress
+is completely unaffected and a fresh Lab boots normally.
+
+## Phase 6A: reused, not modified — a teaching layer in front, still one Lab
+
+Phase 6A (`docs/PHASE6A_ROOT_COURSE_FOUNDATION.md`) added a course/module/activity content model
+in front of the exact same disposable Lab this document describes — no change to the
+Provisioner, `environments`, the reaper, the Lab Host Router, or the Lab image itself
+(`Dockerfile`/`entrypoint.sh`/`backend/server.js` untouched). A course's `lab` activity is a
+`scenario_id` reference; "Launch Lab" from the course view calls the identical
+`/api/student/programs/:id/launch` sequence Phase 5B already established — not a third launch
+path. Verified for real, not assumed: `infra/scripts/drills/test-phase6a-course-rehearsal.js`
+launches a real Lab, calls the Lab's own `POST /api/scenarios/:id/setup` through the Gateway's
+existing `/lab/:token/*` proxy exactly as the browser UI does, and runs a real `kubectl patch`
+against the live k3s cluster inside that container before recording completion.

docs/PHASE5B_SELF_PACED_ENROLLMENT.md

@@ -0,0 +1,195 @@
+# Phase 5B — Self-Paced Learning & Enrollment Foundation
+
+**Status: PHASE 5B COMPLETE. SELF-PACED LEARNING FOUNDATION COMPLETE. WEBSITE ENROLLMENT BOUNDARY READY.**
+
+Phase 5A gave students real identity and instructors a remote classroom. Phase 5B's job was
+the last piece needed for an authenticated student to be enrolled in a RootNode Academy program
+and complete it entirely on their own — plus the clean, provider-neutral boundary a *separate*
+public website/commerce system will call to create those enrollments later. This phase does
+**not** build that website or any payment processing — see §12.
+
+## 1. The RootNode program ladder
+
+`init_` (ages ~5-10, robotics/block coding), `compile_` (ages ~11-14, ESP32/MicroPython/IoT),
+`root_` (ages ~15-18+, Linux/containers/Kubernetes/DevOps). The existing KubeKosh-derived
+curriculum belongs to `root_`. This phase does not write init_/compile_ curriculum content — it
+makes the platform capable of holding those programs later without another schema change (the
+`programs.family` enum already accepts `init`/`compile`/`root`).
+
+## 2. Programs — a first-class object, not curriculum JSON
+
+`programs` (migration `019_programs.sql`) is the commercial/academic unit a student enrolls in.
+It is deliberately **not** the curriculum file itself — `programs.curriculum_path` just points at
+one (today, always `rootnode-path`, the only curriculum that exists). `program_id` is the slug
+primary key, matching `assessment_definitions`/`cohorts`' existing convention rather than a
+separate id+slug pair. `family` (`init`/`compile`/`root`) and `delivery_mode`
+(`self_paced`/`cohort`/`hybrid`) are both real CHECK-constrained enums, not free text — small,
+stable vocabularies, matching how this codebase already treats `assessment_definitions.type` and
+`hint_policy`. The phase seeds exactly one program: `root-kubernetes-foundations`, wrapping the
+existing RootNode/Kubernetes curriculum and the existing `rootnode-capstone` as its completion
+criterion — no new curriculum content invented.
+
+`programs.version` bumps automatically whenever an edit changes a field an enrollment snapshots
+(`curriculum_path`, `delivery_mode`) — same versioning principle `assessment_definitions`
+already established, so editing a program later never silently changes what an already-enrolled
+student is being held to.
+
+## 3. Enrollments — real academic access, separate from cohorts
+
+`enrollments` (migration `020_enrollments.sql`) represents a student's access to a program:
+`pending → active → completed`, or `pending`/`active → cancelled`. All transitions are
+server-side only (`enrollment.js`) — nothing accepts a client-supplied status. `expired` is
+**derived**, not stored: `deriveEnrollmentAccess(enrollment, now)` is a pure function (matching
+Phase 5A's `classroom.js` `derivePresence` pattern) that computes it from `access_ends_at` at
+read time, so there's no background sweep and nothing to go stale.
+
+A self-paced enrollment has **no cohort at all** — `cohort_enrollments` (Phase 1) is completely
+untouched. A student can hold a cohort enrollment, a self-paced enrollment, and multiple
+historical enrollments simultaneously without any of those concepts colliding; re-enrollment
+after completion/cancellation always creates a new row rather than reviving a historical one (a
+partial unique index enforces at most one `pending`/`active` enrollment per student+program at a
+time — DB-level, not app-level "check then insert").
+
+## 4. Curriculum assignment — the schema Phase 4.1 flagged, now wired
+
+Phase 4.1's `curriculum_assignments` table (schema-ready since Phase 2B, never read by
+anything) is **not** reused as-is — it models cohort/student curriculum assignment
+independent of any commercial concept, which is a different problem than "this enrollment in
+this program uses this curriculum." Instead, `enrollments.curriculum_path` is itself the
+snapshot: set from `programs.curriculum_path` at enrollment time, so a later edit to the
+program never changes what an existing enrollment means. `curriculum_assignments` remains
+exactly as Phase 4.1 left it — still available for a future direct per-student assignment need
+outside the program/enrollment model, not duplicated or removed.
+
+The resolution chain is real: `enrollment.student_id → enrollment.program_id →
+enrollment.curriculum_path → curriculum.loadCurriculumPath() → stages → scenarios`
+(`program-status.js`'s `buildProgramStatus`). Only one curriculum path exists today, so this
+always resolves to `rootnode-path` — the extension point for a second path is
+`enrollments.curriculum_path` itself, already snapshotted per-enrollment.
+
+## 5. Self-paced dashboard and resume — reused, not reinvented
+
+`GET /api/student/programs` returns every enrollment a student holds (never a public catalog —
+no public course browsing exists), each annotated with real access state, progress, and a
+deterministic next activity. The heavy lifting is **entirely existing Phase 3B machinery**:
+`curriculum-rules.js`'s `computeCurriculumState` already returns `current_stage` and each
+stage's `next_scenario` — `program-status.js` just wraps that per-enrollment. "Continue
+Learning" resume is not a guess based on the last page rendered; it's the same rule-driven
+current-stage/next-scenario computation the My Learning tab has used since Phase 3B, now scoped
+per program. Destroying a Lab never touches this — `progress`/`scenario_attempts` live in
+Postgres, completely independent of any container's lifecycle (verified for real, not just
+asserted — see §9).
+
+## 6. Entitlement — enforced server-side, not by hiding a button
+
+`POST /api/student/programs/:enrollmentId/launch` is the only self-paced entry point into a
+Lab. It resolves the enrollment (404 if it isn't the caller's own), calls
+`deriveEnrollmentAccess`, and 403s with a `reason` (`pending_activation` / `not_yet_started` /
+`access_expired` / `cancelled`) if `can_launch` is false — **before** ever touching the
+Provisioner. A pending, future-dated, expired, or cancelled enrollment cannot provision a Lab no
+matter what the browser sends. The existing `POST /api/environment/launch` (cohort/pilot path)
+is completely unchanged — this is a new, additive gate in front of the exact same disposable-Lab
+sequence (`environment-view.js`, extracted from `server.js` so both routes share one
+implementation), not a second kind of Lab.
+
+## 7. Completion — server-derived and idempotent
+
+`enrollment.maybeCompleteEnrollment` checks, for every `active` enrollment whose program has a
+`completion_assessment_id`, whether a matching `capstone_completed` achievement already exists
+(the achievement `recordAssessmentAchievement` already writes when a capstone session finalizes
+— Phase 3B, unmodified). If so, it transitions the enrollment to `completed` — an `UPDATE ...
+WHERE status = 'active'`, so calling it again once already completed is a guaranteed no-op, not
+a duplicate transition or an error. This runs opportunistically on every program-status read
+(`program-status.js`), which means completion is detected on the next read after the qualifying
+event, not pushed instantly — acceptable latency for a status field, and it means there is no
+"mark complete" button anywhere in the frontend to accidentally trust.
+
+## 8. Pacing and availability
+
+`starts_at`/`access_ends_at` are the entire pacing model this phase builds — no drip scheduling,
+no per-lesson unlock dates. `starts_at` in the future: the enrollment is visible
+(`effective_status: 'active'`) but `can_launch: false`, reason `not_yet_started`. `access_ends_at`
+in the past: `effective_status: 'expired'`, prior progress/achievements remain fully visible,
+`can_launch: false`. Both are enforced in `deriveEnrollmentAccess`, called from the same
+server-side gate every launch goes through — never a frontend-only check.
+
+## 9. Real Lab-persistence proof
+
+`platform/test/e2e-phase5b.js` and `infra/scripts/drills/test-phase5b-selfpaced-rehearsal.js`
+both drive this against a real stack: launch a Lab, complete a scenario, destroy the environment
+via the admin API, relaunch, confirm identical progress and resume target; separately, kill the
+Lab container directly (bypassing the Provisioner, exactly the idle reaper's failure mode from
+the Provisioner's point of view) and restart the Provisioner to run its real
+`reconcileOnStartup` reconciliation (the same technique `infra/scripts/drills/
+test-lab-host-loss.js` established in Phase 4.1) before relaunching — progress is identical
+both times.
+
+## 10. Instructor/admin management
+
+`/admin` → Programs: list/create/edit/activate-deactivate (admin/owner only, matching
+`assessment_definitions`' authoring convention — every role can view), per-program enrollment
+list and manual-enroll form, per-enrollment activate/cancel. The existing student detail view
+gained an "Enrolled programs" card (status, delivery mode, progress, last activity).
+
+**RBAC** (`rbac.js`'s new `requireEnrollmentAccess`): owner/admin have global management, as
+everywhere else. A plain instructor may view/manage an enrollment if they created it
+(`enrollments.created_by`) **or** the student shares one of their cohorts — never blanket
+visibility into every self-paced student, since a self-paced enrollment can have no cohort
+relationship at all. Enrollment *creation* stays admin/owner only, matching the existing
+roster-creation precedent (`POST /api/admin/students` is the same restriction).
+
+## 11. The website/commerce integration boundary
+
+`POST /api/integrations/enrollments` — completely separate from student/instructor session
+auth (no cookie is ever read), authenticated by a pre-shared secret header
+(`X-RootNode-Integration-Key`), the exact same trust-boundary pattern this codebase already
+uses for Gateway↔Provisioner (`X-Provisioner-Key`/`PROVISIONER_SHARED_SECRET`), not a new
+scheme. Full contract for the separate website team: `docs/WEBSITE_ENROLLMENT_INTEGRATION.md`.
+
+Idempotent by construction: a unique index on `enrollments.external_event_id`, not an
+app-level "check then insert" — proven under real concurrency (three simultaneous identical
+requests produce exactly one enrollment, one `created: true`, two `created: false`) in both the
+permanent suite and manually during development. Student matching is create-or-match by email
+**or** login_identifier (§13's minor/no-email requirement) — reuses Phase 5A's exact
+`students-auth.js` credential-issuing path, not a second account-creation mechanism, and this is
+a trusted server-to-server caller (the website's own verified-payment backend), not a public
+signup form.
+
+## 12. What was deliberately not built (§22)
+
+Stripe/payment processing, checkout UI, the public website itself, public self-registration, a
+Parent Portal or full guardian accounts, email delivery infrastructure, certificates, complex
+drip scheduling, and full init_/compile_ curriculum content. Each is a plausible "while we're in
+here" addition; each was left alone on purpose. Nothing built this phase blocks any of them —
+`enrollments.external_reference`/`metadata` and the create-or-match student resolution are the
+deliberate extension points for a future guardian-purchases-for-minor flow, without inventing a
+fake guardian record now.
+
+## 13. A real bug found and fixed
+
+`POST /api/progress/record` predated the `wrap()` async-error-handling convention (it's a
+Phase 1/2A route, never updated). An unexpected internal error there — including Postgres
+rejecting a malformed `environment_id` — became an unhandled promise rejection that **crashed
+the entire Platform API process**, not just that one request. Found by this phase's own test
+suite. Fixed: the handler is now wrapped like every route added since Phase 3B, plus explicit
+UUID-shape validation so a bad `environment_id` is a clean 400 and never reaches Postgres as a
+type error at all. Regression-tested in `e2e-phase5b.js`.
+
+## 14. Testing
+
+- `platform/test/e2e-phase5b.js` (32 checks): program seed, entitlement gating
+  (pending/future/expired/cancelled), cross-student isolation, real Lab launch/destroy/reaper/
+  recreate persistence, server-derived idempotent completion, the full integration boundary
+  (auth, idempotency, concurrency, unknown/inactive program rejection, minor/no-email path, no
+  card data), RBAC scoping, Phase 5A regression smoke, and a real Platform API restart.
+- `infra/scripts/drills/test-phase5b-selfpaced-rehearsal.js` (15 checks): one continuous
+  realistic story — activation, a simulated website enrollment event, real Lab work, Lab
+  destroy, a new session later, Continue Learning, a fresh Lab, full capstone completion,
+  program moves to Completed, and a second uninvolved student proven unable to reach any of it.
+- Both against a live `docker-compose.dev.yml` stack, real HTTP, real k3s Lab boots.
+- Migration safety proven explicitly: a fresh Postgres taken through Phase 1-5A's migrations
+  only, seeded with realistic pre-5B data (credentialed student, cohort membership, progress,
+  scenario attempts, achievements, classroom history), then 5B's migrations applied — every
+  prior record intact and correctly associated with the same `student_id`; a new enrollment
+  correctly links to that same pre-existing student; running the migration set a second time
+  applies nothing.

docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md

@@ -0,0 +1,248 @@
+# Phase 5C — Enrollment Operations & Communications
+
+**Status: PHASE 5C COMPLETE. ENROLLMENT COMMUNICATIONS COMPLETE. STUDENT ACTIVATION PIPELINE READY.**
+**LIVE GOOGLE WORKSPACE DELIVERY VALIDATED** — real activation and password-reset emails
+delivered end to end via `[email protected]` (a Workspace alias), DKIM/SPF passing,
+inbox delivery confirmed. See §14.
+
+Phase 5B built the enrollment/entitlement model and the website integration boundary. What was
+still missing for a real student: nobody ever told them. This phase closes that gap — real
+email delivery for activation, enrollment confirmation, and password reset — plus finally
+completing the production password-reset delivery Phase 5A explicitly left unfinished.
+
+## 1. Architecture: provider-neutral by design
+
+```
+Enrollment/Auth code (integration-routes.js, admin-routes.js, student-auth-routes.js)
+        ↓ (mint token if needed, then) notifications.enqueue()
+notification_events row, committed in the SAME request — no network I/O yet
+        ↓
+notification-worker.js (a setInterval poller, same pattern as sessions.js's sweeper)
+        ↓
+email/provider.js  — EMAIL_PROVIDER env var picks the implementation
+        ↓
+email/dev-provider.js  (default)      OR      email/gws-provider.js
+(never a real network call)                   (Gmail API, service account)
+```
+
+No enrollment/auth code anywhere imports a concrete provider. Swapping Google Workspace for a
+different provider later means writing one new file under `platform/api/src/email/` and
+changing `EMAIL_PROVIDER` — nothing else changes.
+
+## 2. Google Workspace delivery mechanism: Gmail API + service account domain-wide delegation
+
+**Selected mechanism:** the Gmail API's `users.messages.send`, authenticated as a Google Cloud
+service account using Workspace domain-wide delegation to impersonate one dedicated sending
+mailbox.
+
+**Why, not SMTP or a human login:**
+- **No human password, ever.** Basic SMTP auth (or an "app password") means storing credentials
+  that log in as an actual person's Workspace account — anyone with that value could read that
+  mailbox's mail, change its settings, or use it to send as that person. A service account has
+  no login of its own and no inbox; domain-wide delegation grants it exactly one narrow OAuth
+  scope (`gmail.send`) against one specific mailbox, nothing more.
+- **Least privilege.** `gmail.send` cannot read mail, cannot manage the mailbox, cannot act as
+  any address other than the one configured. Compare to SMTP relay, which typically wants either
+  a static allow-listed sending IP (fragile for infrastructure that isn't pinned yet) or a
+  Workspace login.
+- **This is Google's own documented pattern** for "an application needs to send mail as a
+  specific Workspace address" — see `docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md` for the exact
+  setup steps and links.
+
+**No `googleapis`/`google-auth-library` dependency.** The JWT-bearer OAuth flow (RS256-sign a
+short JWT, exchange it for an access token, POST one REST call) is ~120 lines using only Node's
+built-in `crypto` and `fetch` — consistent with this codebase's established "hand-roll before
+adding a dependency" convention (CSRF tokens, Prometheus exposition, and CSV parsing all do the
+same). See `platform/api/src/email/gws-provider.js`.
+
+## 3. RootNode email identity
+
+`EMAIL_FROM_NAME` / `EMAIL_FROM_ADDRESS` / `EMAIL_REPLY_TO` — all environment-configured, no
+default mailbox address baked into the code (`EMAIL_FROM_NAME` defaults to the display string
+"RootNode Academy"; `EMAIL_FROM_ADDRESS` has no default at all — sending fails closed with a
+clean `gws_not_configured` error until it's set, rather than guessing a real mailbox that
+doesn't exist in this repository's configuration). `EMAIL_FROM_ADDRESS` doubles as the Gmail API
+adapter's delegated-user (`sub`) claim — it must be a real mailbox in the Workspace domain,
+authorized for delegation (see the runbook).
+
+DNS/domain requirements before any of this can send real mail in production — SPF, DKIM, DMARC,
+and Workspace's own sender-authorization step — are **entirely external to this repository**
+and are documented, not performed, in `docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md` (marked
+`REQUIRES GOOGLE WORKSPACE ADMIN ACTION`).
+
+## 4. Notification model
+
+`notification_events` (migration `021_notification_events.sql`): `student_id` (required — every
+notification this phase sends is about a specific student), `enrollment_id` (nullable —
+password-reset/changed notifications have none), `notification_type`
+(`activation`/`enrollment_confirmation`/`password_reset`/`password_changed`), `recipient_email`
+(a snapshot, not a live join — see §10), `status`
+(`queued`→`sending`→`sent`/`failed`, or `cancelled`, unused this phase but reserved),
+`attempt_count`/`next_attempt_at` for bounded exponential backoff, `last_error_code` (a
+classified string, never a raw stack trace), and `metadata` JSONB.
+
+**Privacy note on `recipient_email`:** duplicates PII already stored elsewhere (`students.email`
+or an enrollment's `contact_email`) purely so the worker and any later delivery audit don't need
+to reconstruct "what address would this have gone to" after the student record potentially
+changes. Same sensitivity class as data already in this database — never a new exposure, and
+never returned unmasked through any admin API (`notifications.js`'s `maskEmail`/`toAdminView`
+are the only shapes any route returns).
+
+## 5. The transient-plaintext-token design (read this before touching token handling)
+
+Phase 5A's invariant — only a HASH of an activation/reset token is ever persisted long-term
+(`students.credential_token_hash`) — is unchanged and non-negotiable. But an activation/reset
+*email* needs the real token to build a working link, and the whole point of this phase is that
+the actual send happens later, asynchronously, in the worker — not in the request that
+originally minted the token.
+
+The resolution: the triggering request mints the token exactly as Phase 5A already does
+(synchronously, in-request), and hands the plaintext to `notifications.enqueue()`, which stores
+it in that one row's `metadata.token` **only until the row reaches a terminal state**
+(`markSent`/`markFailedOrRetry` both scrub it — see their comments in `notifications.js`). This
+is a deliberate, narrow, documented exception for the row that exists specifically to deliver
+the plaintext once — not a second credential store, and never returned by any admin API
+regardless of whether it's still present (`toAdminView` never includes `metadata` at all).
+
+Activation notifications from a **new enrollment** are the one case where no token is minted
+ahead of time and handed in — `notifyForEnrollment()` mints it itself, at enqueue time, because
+there's no other synchronous caller already holding one. Everywhere else (admin create/convert/
+reset-password, self-service forgot-password, admin resend), the existing Phase 5A minting call
+site is reused unchanged and its plaintext is simply also passed to `enqueue()`.
+
+## 6. Activation flow
+
+Reuses Phase 5A's activation token mechanism entirely — no competing invitation-token system was
+built. `issueCredentialToken` already unconditionally invalidates any previous outstanding token
+on mint (Phase 5A), which means **"resend" and "regenerate" are mechanically the same
+operation**: there is never a moment with two simultaneously valid activation links, so a second
+button that did something different would have nothing different to do. `POST /api/admin/
+students/:id/resend-activation` is the one action that covers both.
+
+```
+Enrollment event/admin enrollment → student matched/created
+    → credentials already active? → enrollment_confirmation (§7)
+    → else → issueCredentialToken('activation') → notifications.enqueue()
+        → worker delivers via the configured provider
+        → student opens the link → existing Set Password flow (Phase 5A, unchanged)
+        → token consumed atomically with setting the password
+        → account active, student can log in
+```
+
+## 7. Enrollment confirmation flow
+
+Fires whenever a **new enrollment** is created (integration event or admin manual enroll) for a
+student who **already has credentials** (`students.password_hash IS NOT NULL`). No token, no
+link beyond "go sign in" — `notifyForEnrollment()` (shared by both creation paths) is the single
+decision point, so a website-triggered and an admin-triggered enrollment behave identically.
+
+## 8. Password reset flow — now actually delivered
+
+Phase 5A's `POST /api/student/request-password-reset` already minted a token and, only outside
+production, echoed it back for local/test use. Phase 5C adds exactly one thing: the same
+minted token is now also handed to `notifications.enqueue()`, so a real email goes out. Every
+other behavior is unchanged: the response is the same generic anti-enumeration message
+regardless of whether the account exists, is inactive, or was never activated (this phase
+additionally excludes never-activated accounts, a real fix — see §13); production never returns
+the token, dev/test still can. `POST /api/student/reset-password` (consuming the token) now also
+enqueues a `password_changed` security-notice email once the new password is set.
+
+## 9. Password-changed / security notice
+
+Fires after both `POST /api/student/change-password` (self-service) and `POST /api/student/
+reset-password` (token consumption) succeed — no token, no link, purely "this happened, if it
+wasn't you here's what to do."
+
+## 10. Minor/no-email communication design
+
+Phase 5A/5B's minor-safe model (a student may have `login_identifier` with no `email` at all) is
+preserved exactly. `enrollments.metadata.contact_email` (an existing JSONB column, not a new
+migration) holds an OPTIONAL "who to notify about THIS enrollment" address — a guardian's email
+collected at checkout, for example. **It is never written to `students.email`** — that field
+stays reserved for the student's own identity/login credential; a guardian is not a student.
+`enrollment.js`'s `enrollmentContactEmail()` is the one accessor with that one meaning; recipient
+resolution (`notifications.js`'s `resolveRecipient`) tries the student's own email first, falls
+back to the enrollment's contact email only for enrollment-scoped notification types, and
+correctly has no fallback at all for password-reset/changed (which require the student to
+already be able to log in themselves). This is deliberately transitional — not a guardian
+account, not a linked identity, no relationship table — and does not block a future real
+Guardian Portal from being built on top of it later.
+
+## 11. Website → enrollment → communication
+
+`POST /api/integrations/enrollments` (Phase 5B, unchanged) now also decides and enqueues the
+right notification, but **only when its own enrollment-creation call reports `created: true`**
+(a genuinely new enrollment, not an idempotent replay). This is the entire duplicate-webhook
+safety net for notifications: since Phase 5B's DB-level idempotency already guarantees at most
+one caller ever sees `created: true` for a given event/race, at most one notification is ever
+queued, with zero new dedup mechanism needed.
+
+## 12. Retry/failure handling
+
+`markFailedOrRetry` classifies every provider error as `temporary` or `permanent` (both
+providers' `send()` throw an `Error` with `.errorClass`/`.errorCode` set). Permanent failures
+(bad recipient, missing/invalid Google config) go straight to `failed` on the first attempt —
+retrying can't fix them. Temporary failures (network/provider hiccups, rate limiting) requeue
+with bounded exponential backoff (30s base, doubling, capped at 1 hour) until `MAX_ATTEMPTS` (5)
+is exhausted, then `failed` too. Never an infinite loop; every attempt is persisted
+(`attempt_count`, `last_error_code`).
+
+## 13. Real bugs found and fixed
+
+- `request-password-reset` would previously mint a `reset` token for a student who had **never
+  been activated** (`password_hash IS NULL`) — a "reset" for an account with no password to
+  reset doesn't make semantic sense, and would have sent a confusing "reset your password" email
+  to someone who needs activation, not reset. Fixed: that branch now also checks
+  `student.password_hash` and falls through to the same generic anti-enumeration response,
+  exactly as if the account didn't exist.
+- **HTML injection in email templates.** `displayName` (which can come straight from a website
+  integration event's `student.display_name` — genuinely external, caller-controlled text, not
+  admin-typed) was interpolated directly into the HTML email body with no escaping. `templates.js`
+  now escapes every user-controlled value before it reaches HTML (`escapeHtml`); the plain-text
+  bodies are correctly left unescaped, since there's no markup there to break. Both fixes are
+  regression-tested in `e2e-phase5c.js`.
+
+## 14. Testing
+
+- `platform/test/e2e-phase5c.js` (28 checks): activation vs enrollment-confirmation decision,
+  duplicate/concurrent webhook idempotency, temporary/permanent/exhausted retry classification,
+  resend/regenerate token invalidation, activation/reset single-use and expiration, production
+  token-secrecy gating (a real container recreate with `COOKIE_SECURE=1`), minor/contact-email
+  resolution, RBAC scoping, metrics/audit hygiene, and a real Platform API restart.
+- `infra/scripts/drills/test-phase5c-enrollment-activation.js` (10 checks): one continuous
+  story — website enrollment → activation email rendered and its URL extracted exactly like a
+  real inbox click → password set → real Lab launched → real scenario completed → a second
+  enrollment gets confirmation not activation → full password-reset round trip with session
+  revocation → the minor/contact-email path.
+- Both against a live `docker-compose.dev.yml` stack, using the deterministic dev email provider
+  exclusively — **no test in this phase ever makes a real network call to Google or anyone
+  else.**
+- Migration safety proven explicitly against a fresh Postgres taken through every prior phase's
+  migrations, seeded with realistic Phase 5B data (credentialed student, minor/no-email student,
+  cohort, enrollment with a contact-email, progress, attempts, achievements, classroom history),
+  then this phase's migration applied — every prior record intact; a new notification correctly
+  links to the pre-existing student/enrollment; re-running the migration set is a no-op.
+
+**Live Google Workspace delivery has been validated for real**, both in isolation
+(`infra/scripts/gws-email-test.js`, one message, DKIM/SPF passing, delivered) and through the
+full genuine flow: a real student created, enrolled, receiving a real activation email, setting
+their password from the real link, logging in, seeing their enrolled program, requesting and
+receiving a real password-reset email, and completing the reset — every step against the live
+Platform API, `EMAIL_PROVIDER=gws`, nothing simulated.
+
+**One real Google Workspace limitation found and handled:** newly-authorized domain-wide
+delegation does not take effect instantly across all of Google's auth infrastructure — the
+identical token request succeeded, then failed with `unauthorized_client`, then succeeded again,
+over the span of about a minute, before settling. This is Google-side propagation delay, not a
+configuration error, and it self-resolved. `gws-provider.js` now classifies `unauthorized_client`
+as a *temporary* failure (retried with the existing bounded backoff) rather than permanent —
+this is exactly the failure mode that backoff exists for, and it means a real deployment doesn't
+need a human to notice and manually retry during that propagation window. See
+`docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md`'s troubleshooting section.
+
+**A second real-world detail found during setup, not a bug:** the sending address
+(`[email protected]`) is a Workspace *alias* of an existing account rather than its
+own paid seat — a deliberate cost-saving choice. Domain-wide delegation authorizes a real
+account, not an arbitrary alias string, so `GOOGLE_DELEGATED_USER` (the alias's real owner) was
+added as a setting distinct from `EMAIL_FROM_ADDRESS` (the visible sending address) — see §2 and
+the runbook §5.

docs/PHASE6A_ROOT_COURSE_FOUNDATION.md

@@ -0,0 +1,138 @@
+# Phase 6A — ROOT_ Course Architecture + Content Delivery Foundation
+
+**Status: PHASE 6A COMPLETE. COURSE/MODULE/ACTIVITY CONTENT MODEL LIVE. GOLD-STANDARD MODULE
+READY, VALIDATED AGAINST A REAL LAB.**
+
+Phases 1-5 built the RootNode Academy platform: identity, cohorts, curriculum, the assessment
+engine, remote classrooms, self-paced enrollment, and enrollment communications. All of it sat
+on top of `scenarios/rootnode-path.json` — a flat list of scenario ids per stage, with no notion
+of a lesson, a demonstration, or "learn this before you're asked to solve it." Phase 6A builds
+that layer, for the `root_` track only, without touching any of the systems underneath it.
+
+## 1. The canonical youth ladder (context, not built here)
+
+RootNode Academy's product spans three tracks by age/stage:
+
+- **`init_`** (~5-10) — robotics / computational thinking / block coding. Not built.
+- **`compile_`** (~11-14) — electronics / microcontrollers / ESP32 / programming. Not built.
+- **`root_`** (~15-18+, college, adult) — Linux → systems → containers → Kubernetes → DevOps/
+  platform engineering. **This phase.**
+
+`programs.family` (Phase 5B) already models this three-way split; only `root` has real content.
+Phase 6A does not invent `init_`/`compile_` curriculum — see §15 of the authorization and
+`docs/ROOT_CURRICULUM_INVENTORY.md` §7 for the evidence that no such content exists yet.
+
+## 2. Core product principle
+
+KubeKosh/the RootNode Lab is the LABORATORY, not the whole course. A RootNode course can contain
+lessons, demonstrations, examples, knowledge checks, guided exercises, labs (existing
+scenarios), assessments, reflections, and capstone work — a student learns a concept BEFORE
+being asked to solve the corresponding scenario. See `docs/COURSE_AUTHORING_STANDARD.md`.
+
+## 3. Google Workspace status (recorded per this phase's instruction, not new work)
+
+The external blocker at the end of Phase 5C — no real Google Workspace mailbox to test against —
+was resolved by the owner during this session before Phase 6A began: `[email protected]`
+now exists and live delivery was validated end to end (isolated send test + a full real
+activation/reset lifecycle). This is already recorded in `docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md`
+(status header, §14) and `docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md` (§11's propagation-delay note),
+committed at `4c0a950` and tagged `v0.5.3-enrollment-comms` — this phase did not need to redo
+that work, only confirm it was recorded, which it was.
+
+## 4. Architecture summary
+
+```
+program (existing)  ──  courses  ──  course_modules  ──  module_activities
+                                                             ├─ lab → scenario_id (existing)
+                                                             └─ assessment/capstone → assessment_definition_id (existing)
+```
+
+Full design: `docs/COURSE_CONTENT_MODEL.md`. Full course/module map:
+`docs/ROOT_PROGRAM_ARCHITECTURE.md`. Full existing-content inventory this was built from:
+`docs/ROOT_CURRICULUM_INVENTORY.md`.
+
+Delivery modes: the same content model serves both instructor-led (Phase 5A classrooms) and
+self-paced (Phase 5B enrollment) students — one `buildCourseTree()` function
+(`platform/api/src/course-progress.js`), one `content.js` Markdown loader, consumed by both
+`course-routes.js` (student) and `admin-course-routes.js` (instructor), the latter additionally
+exposing instructor notes via the same file's `## Instructor Notes` convention. No forked
+curriculum.
+
+## 5. What was built
+
+**Migration** — `platform/api/migrations/022_course_content.sql`: `courses`, `course_modules`,
+`module_activities`, `activity_completions`, plus seed data for 13 courses, 8 modules, and 51
+activities (44 mechanically mapped from existing `rootnode-path.json` stages, 6 gold-module
+activities, 1 capstone activity) — see that file's own extensive header comments.
+
+**Content** — `content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/`:
+6 Markdown files (lesson, demonstration, knowledge check, guided exercise, lab intro,
+reflection), each following the shared/instructor-notes split convention.
+
+**Backend** — `content.js` (Markdown loader), `course-progress.js` (completion derivation +
+prerequisite locking, shared by both surfaces), `course-routes.js` (student API),
+`admin-course-routes.js` (instructor API), wired into `server.js`. `platform/api/Dockerfile`
+now also copies `content/`.
+
+**Frontend** — `CourseView.jsx` (student: My Programs → ROOT_ → Course → Module → Activity →
+Launch Lab → back → continue), wired into `ProgramsTab.jsx`'s existing "Continue Learning" flow
+via a new "View Courses" button (the original direct-to-Lab button is unchanged).
+`CurriculumView.jsx` (instructor: program structure, per-module teaching detail, instructor
+notes, per-student progress lookup), wired into `AdminPortal.jsx` as a new "Curriculum" tab.
+
+**Tests** — `platform/test/e2e-phase6a.js` (21 assertions: hierarchy, ordering, all three
+completion behaviors, locking, resume, cross-student isolation, RBAC, draft-hiding, version
+stability) and `infra/scripts/drills/test-phase6a-course-rehearsal.js` +
+`run-phase6a-course-rehearsal.sh` (a real-k3s dress rehearsal of the gold module end to end,
+including the Lab's own `setup_commands` and a real `kubectl patch` against the live cluster).
+
+## 6. The gold-standard module
+
+`root-10-m01-health-probes-and-troubleshooting`, under ROOT 10 (Kubernetes Troubleshooting &
+Observability): lesson (probe concepts) → demonstration (reading `kubectl describe pod` Events
+for a probe failure) → knowledge check → guided exercise (write a readiness probe on paper) →
+Launch Lab (`rootnode-probe-port-mismatch`, RootNode-authored) → reflection (root cause + Real
+Ops prevention takeaway). Instructor notes on 5 of its 6 activities (demo plan, misconceptions,
+timing, discussion questions, extensions). This is the template `docs/COURSE_AUTHORING_STANDARD.md`
+documents for all future module authoring.
+
+## 7. Honest content states
+
+No course is `ready`. 5 courses (01-04, 11) are `planned` with zero modules — genuinely no
+content exists for them. 7 courses (05-10, 12, capstone) are `partial` — real, working labs
+mapped in, one fully `ready` module (the gold standard), everything else awaiting lesson
+authoring in Phase 6B. Nothing was fabricated to make the UI look more complete than it is.
+
+## 8. Test results
+
+- `e2e-phase6a.js`: **21 passed, 0 failed.**
+- `test-phase6a-course-rehearsal.js` (real k3s Lab): **12 passed, 0 failed**, including a real
+  `kubectl patch` against a live cluster inside the student's actual disposable Lab container.
+- Full regression (Phase 2A/2B/3A/3B/5A/5B/5C) — see the final report for the run-by-run result;
+  no Phase 6A change touched any file those suites exercise other than additive route
+  registration in `server.js`.
+
+## 9. What Phase 6A deliberately did not build
+
+Per the authorization's explicit scope line: `init_`/`compile_` curriculum, a Parent Portal,
+Stripe/payments, public registration, an AI tutor, chat/video/voice, proctoring, a mobile app,
+certificates, a multi-host scheduler, production deployment changes, a CMS, or dozens of
+placeholder lessons. Lesson authoring for courses 06-10/12/capstone beyond the gold standard is
+explicitly Phase 6B+ scope.
+
+## 10. Known limitations / recommended Phase 6B scope
+
+- ROOT 08/09's real, existing scenario content (storage/scheduling, and a 22-scenario CKS
+  security bank) is inventoried but not yet wired into modules — the natural next content slice.
+- Course-level lesson authoring for ROOT 05-07/10 (m02)/12/capstone: labs exist, teaching
+  content doesn't yet — apply `docs/COURSE_AUTHORING_STANDARD.md` per module.
+- `POST /api/assessments/:definitionId/start` does not itself re-check the capstone's
+  `unlock_rule` server-side (a pre-existing Phase 3B gap, not introduced by this phase — the
+  student-facing `/api/capstone` view does compute and display lock state correctly, and the
+  UI never exposes a "start" action while locked, but the raw route would technically accept a
+  premature start if called directly). Not fixed here — it's outside the course/content-model
+  scope this phase was authorized for; worth a small, isolated fix in a future phase.
+- Course-to-course prerequisite locking is currently sequential/manually declared, not derived
+  from the assessment engine's own `unlock_rule` JSON — the two happen to agree today by
+  construction (see `docs/ROOT_PROGRAM_ARCHITECTURE.md`'s "Real Ops and Capstone placement");
+  a future phase could unify them if course content grows complex enough to warrant it.

docs/PHASE6B_ROOT_CURRICULUM_EXPANSION.md

@@ -0,0 +1,155 @@
+# 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.

docs/PRODUCTION_VALIDATION_CHECKLIST.md

@@ -67,5 +67,40 @@ can prove in advance.
 - [ ] `docs/RUNBOOK_STUDENT_ACCOUNT_LIFECYCLE.md` and `docs/RUNBOOK_REMOTE_CLASSROOM.md`'s steps
       still make sense walked against the real admin portal
 
+## Self-paced enrollment & website integration (Phase 5B — see docs/PHASE5B_SELF_PACED_ENROLLMENT.md)
+- [ ] `INTEGRATION_SHARED_SECRET` is set to a real, unique-to-production secret (not the dev
+      value) and is stored only in the Platform API's own server-side environment — never
+      committed, never in any browser-reachable config
+- [ ] The website team's production integration key was delivered out of band (not plaintext
+      email/chat) and is confirmed working with one real, low-stakes test enrollment before go-live
+- [ ] A deliberate `POST /api/integrations/enrollments` call missing/with a wrong key returns a
+      clean `401` against the real production endpoint, not a 500 or an information leak
+- [ ] `GET /metrics`'s `rootnode_enrollments_total`/`rootnode_program_completions_total` labels
+      contain only status/delivery_mode/program_id values — confirm no student_id, email, or
+      external_reference ever appears in a real production scrape
+- [ ] `docs/RUNBOOK_SELF_PACED_ENROLLMENT.md`'s steps still make sense walked against the real
+      admin portal, and `docs/WEBSITE_ENROLLMENT_INTEGRATION.md` is what the website team
+      actually integrated against (update it if reality drifted during that integration)
+
+## Enrollment communications / Google Workspace email (Phase 5C — see docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md)
+- [ ] Every step in `docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md` marked REQUIRES GOOGLE WORKSPACE
+      ADMIN ACTION has actually been completed (sending mailbox, service account, domain-wide
+      delegation scoped to `gmail.send` only, SPF/DKIM/DMARC)
+- [ ] `EMAIL_PROVIDER=gws` set in the real production environment — confirm it is NOT left at
+      the dev-provider default, which would silently mean no real student ever receives email
+- [ ] `GOOGLE_SERVICE_ACCOUNT_JSON`, `EMAIL_FROM_ADDRESS`, `EMAIL_FROM_NAME`, `EMAIL_REPLY_TO`,
+      and `PUBLIC_APP_ORIGIN` are all set from the real production secret store, not left at any
+      dev/example value
+- [ ] `infra/scripts/gws-email-test.js` (opt-in, `RUN_GWS_EMAIL_TEST=true`) run once against a
+      real `TEST_EMAIL_RECIPIENT` and confirmed delivered — the one and only "does this actually
+      work" proof this checklist can't fake
+- [ ] `COOKIE_SECURE=1` in the real production environment — confirms the dev-preview
+      notification route (`GET /api/admin/notifications/:id/dev-preview`) is unreachable and no
+      activation/reset token is ever returned by any API response
+- [ ] `GET /metrics`'s notification gauges/counters contain no student_id/email/token/
+      notification_id/external_event_id in any label value on a real production scrape
+- [ ] `docs/RUNBOOK_STUDENT_ACTIVATION.md`'s steps still make sense walked against the real
+      admin portal, including a real (not dev-provider) activation email actually arriving
+
 Only once every box above is checked against the real server does the deployment graduate from
 "infrastructure package built" to "actually in production."

docs/REMOTE_AND_SELF_PACED_ARCHITECTURE.md

@@ -45,11 +45,12 @@ this flow specifically — see the Phase 4.1 report for the full run results.
 
 ## What's genuinely missing for a real self-paced product (Phase 5, not built here)
 
-1. **No self-registration / public enrollment.** A student row is created only by an instructor
-   (`POST /api/admin/students`, admin/owner RBAC-gated). There is no public "sign up" surface.
-   This is almost certainly the right call to leave alone for now — it's explicitly a Phase 5+
-   product/business decision (course commerce, is it free, who's allowed to enroll), not an
-   infrastructure gap.
+1. **No self-registration / public enrollment surface.** Still true, still deliberate — Phase 5B
+   built the boundary a *separate* public website will call
+   (`POST /api/integrations/enrollments`, see `docs/PHASE5B_SELF_PACED_ENROLLMENT.md` §11 and
+   `docs/WEBSITE_ENROLLMENT_INTEGRATION.md`) rather than a public sign-up form here. A student
+   row can now be created automatically by a trusted server-to-server enrollment event, but there
+   is still no browser-facing "sign up" page anywhere in this codebase — that's the website's job.
 
 2. ~~**No real student authentication.**~~ **Closed in Phase 5A.** Students now have real
    credentials (email+password or login-identifier+password, `password_hash`/`scrypt` reusing
@@ -59,25 +60,48 @@ this flow specifically — see the Phase 4.1 report for the full run results.
    /api/login` still works for not-yet-converted pilot rows only; it's rejected (409) the moment
    an account has real credentials or a pending activation token.
 
-3. **`curriculum_assignments.student_id` is schema-ready but unwired.** The table has supported
-   a direct per-student curriculum assignment (independent of any cohort) since Phase 2B
-   (`CONSTRAINT curriculum_assignment_target CHECK (cohort_id IS NOT NULL OR student_id IS NOT
-   NULL)`) — but nothing in the application ever reads or writes that column today; there's only
-   one curriculum path, so nothing has needed to differentiate yet. Not a gap that blocks
-   self-paced delivery now (every student already sees the one path with no gate), but the
-   moment a second curriculum path exists, this is where per-individual assignment lands — the
-   schema was designed for exactly this and doesn't need a migration to support it.
+3. ~~**`curriculum_assignments.student_id` is schema-ready but unwired.**~~ **Addressed
+   differently in Phase 5B.** `curriculum_assignments` itself remains unwired, unchanged — but
+   the real problem it was meant to eventually solve (which curriculum a given student sees) is
+   now solved at the enrollment layer instead: `enrollments.curriculum_path` snapshots
+   `programs.curriculum_path` per enrollment. `curriculum_assignments` is still available for a
+   future direct per-student assignment need outside the program/enrollment model — it wasn't
+   removed, just not the mechanism Phase 5B ended up using. See
+   `docs/PHASE5B_SELF_PACED_ENROLLMENT.md` §4.
 
-4. **No delivery-mode concept anywhere.** In-person, remote, and self-paced sessions aren't
-   distinguished in any data model today, and nothing currently needs them to be — capacity
-   planning, the reaper, and academic records all behave identically regardless of how a student
-   is attending. Worth being aware this is unmodeled, not worth building a taxonomy for before a
-   real product reason exists (YAGNI).
+4. ~~**No delivery-mode concept anywhere.**~~ **Closed in Phase 5B.**
+   `programs.delivery_mode`/`enrollments.delivery_mode` (`self_paced`/`cohort`/`hybrid`) is now
+   a real, snapshotted field. Capacity planning, the reaper, and Lab lifecycle mechanics still
+   behave identically regardless of delivery mode — this only affects how enrollment/entitlement
+   is modeled, not infrastructure.
+
+5. **No self-paced enrollment/entitlement model.** ~~Closed in Phase 5B~~ — see
+   `docs/PHASE5B_SELF_PACED_ENROLLMENT.md` for `programs`/`enrollments`, server-enforced
+   entitlement (pending/future/expired/cancelled), server-derived completion, and the resulting
+   self-paced student dashboard.
+
+6. ~~**No enrollment communication.**~~ **Closed in Phase 5C.** An enrolled student now actually
+   gets told — real activation/enrollment-confirmation/password-reset email, delivered
+   asynchronously through a provider-neutral notification worker (Google Workspace via the
+   Gmail API in production, a deterministic dev provider everywhere else). See
+   `docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md`.
+
+7. ~~**No notion of a lesson, only a flat scenario list per curriculum stage.**~~ **Closed in
+   Phase 6A**, for `root_` only. A self-paced enrollment now resolves to a real course/module/
+   activity tree (lessons, demonstrations, knowledge checks, guided exercises, labs,
+   reflections, assessments/capstone) instead of just a bare scenario id list — the same tree an
+   instructor-led classroom student sees, consumed through the identical `buildCourseTree()`.
+   See `docs/COURSE_CONTENT_MODEL.md` and `docs/PHASE6A_ROOT_COURSE_FOUNDATION.md`. **Populated
+   with real teaching content across most of the Kubernetes/operations courses in Phase 6B** —
+   see `docs/PHASE6B_ROOT_CURRICULUM_EXPANSION.md`. The architecture itself (this closed gap)
+   didn't change; what a self-paced student actually finds inside it did.
 
 ## What Phase 4.1 deliberately did NOT do here
 
 No signup flow, no student password/email auth implementation, no per-student curriculum
 assignment route, no payments, no public course catalog, no held/premium scenario content. All
-explicit non-goals per this phase's authorization. Student authentication (item 2, above) was
-closed in Phase 5A; the rest remain open, unmodeled by design (YAGNI) until a real product
-reason exists.
+explicit non-goals per this phase's authorization. Student authentication (Phase 5A), the
+self-paced enrollment/entitlement model (Phase 5B), and enrollment/account-lifecycle
+communication (Phase 5C) have all since been built; a public self-registration *page*, real
+payment processing, and a Parent/Guardian portal remain deliberately out of scope — see
+`docs/PHASE5B_SELF_PACED_ENROLLMENT.md` §12 and `docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md`.

docs/ROOT_CAPSTONE_READINESS.md

@@ -0,0 +1,87 @@
+# ROOT Capstone Readiness
+
+Phase 6B §9/§10 — the instructional runway that prepares a student for the existing
+`rootnode-capstone` assessment, and the server-side fix that makes its unlock rule actually
+enforced. This document does not redesign the capstone engine itself (`assessments.js`,
+`013_assessments.sql`) — see `docs/PHASE3B_LEARNING_AND_ASSESSMENT.md` for that.
+
+## 1. The Capstone Readiness module
+
+`root-capstone-m02-capstone-readiness` (sequenced BEFORE the real capstone module,
+`root-capstone-m01-operate-and-recover`, within the `root-capstone` course) — 4 activities:
+
+1. **Lesson — What the Capstone Measures & How the Draw Works.** Explains the required-vs-random
+   scenario draw, what "unlocked" means, and what completion records. Never publishes the exact
+   scenario IDs in the current pool or any answer.
+2. **Lesson — Time Management & Troubleshooting Strategy Under a Clock.** Budgeting the 90
+   minutes, reusing the ROOT 10/ROOT 12 frameworks under pressure, and when to move on from a
+   stuck scenario.
+3. **Knowledge check — Readiness Check: Are You Actually Ready?** A genuine self-assessment
+   (not a graded quiz) against concrete criteria, pointing back to specific ROOT_ modules for
+   any "no" answer.
+4. **Reflection — What Completion Means.** Connects passing the Capstone to a durable,
+   demonstrated skill rather than a completion checkbox.
+
+This module derives its own completion the same way every other lesson-only module does
+(`activity_completions`, `manual_marker`) — it is intentionally NOT a prerequisite the real
+capstone assessment engine checks before allowing a start (see §3 below for why these two gates
+are deliberately independent).
+
+## 2. What was NOT built
+
+No answers, no exact scenario IDs from the current pool, no capstone-specific hint content
+beyond what the Lab's own progressive hints already provide. No new assessment engine, no
+second capstone, no readiness "score." This is orientation content, not a shadow exam.
+
+## 3. Why readiness-module completion and the real unlock gate are independent
+
+The real capstone start (`POST /api/assessments/rootnode-capstone/start`) is gated by the
+curriculum path's own `unlock_rule` — all 6 content stages of `rootnode-path.json` complete
+(Foundation, Workloads, Networking, Configuration, Troubleshooting, Real Ops) — computed by
+`computeCurriculumState()` (`curriculum-rules.js`), the exact same function `GET /api/capstone`
+already used to display lock state. Whether a student has viewed or completed the Capstone
+Readiness module has NO bearing on this gate.
+
+This is deliberate, not an oversight: hard-locking the real assessment behind a CONTENT-MODEL
+module (course_modules/module_activities) would mean the security-critical enforcement boundary
+lives in two different systems that could drift out of sync — the curriculum-path unlock_rule
+(Postgres-backed, achievement-derived, already proven) and the course-content prerequisite chain
+(newer, additive, built for teaching sequencing rather than security enforcement). Keeping them
+independent means: the readiness module is free to be completed early, late, or skipped by a
+student who's already prepared some other way, while the real gate remains exactly as strict as
+`docs/PHASE3B_LEARNING_AND_ASSESSMENT.md` originally specified.
+
+## 4. The server-side unlock enforcement fix (Phase 6B §10)
+
+**The gap** (documented in `docs/PHASE6A_ROOT_COURSE_FOUNDATION.md` §10): `POST /api/assessments/
+:definitionId/start` (`learning-routes.js`) checked only that the assessment definition existed
+and was `status = 'active'` — it never checked `unlock_rule` at all. `GET /api/capstone`
+correctly computed and displayed lock state, and the student UI never exposed a "start" action
+while locked, but a direct POST to the start route bypassed the check entirely. Student UI state
+was the only thing standing between a student and an early capstone attempt.
+
+**The fix**: the start route now resolves whether the requested definition is the curriculum
+path's OWN configured capstone (`path.stages.find(s => s.type === 'capstone' && s
+.capstone_assessment_id === definition.assessment_definition_id)`), and if so, computes the
+exact same `computeCurriculumState()` gate `/api/capstone` already relies on. A `locked` gate
+now returns a clean `403 { error: 'locked', message, blocking_stage_ids }` — the same
+`blocking_stage_ids` shape `/api/capstone` already exposes, so a client integrating against this
+route gets consistent, already-documented error shape rather than a new one. No internal state
+beyond the stage ids that are actually incomplete is ever returned.
+
+**What is NOT gated**: any assessment definition the curriculum path does NOT name as its
+capstone (e.g. `rootnode-quick-assessment`) is completely unaffected — the check only ever
+triggers for the one definition the path itself points at via `capstone_assessment_id`.
+
+**What remains valid**: no existing `assessment_sessions` row, no achievement, no enrollment
+completion record was touched by this fix — it only affects a NEW start attempt going forward.
+A student who already legitimately completed the capstone before this fix keeps that record
+exactly as it was.
+
+**Regression coverage**: `platform/test/e2e-phase6b.js` proves both directions — a direct start
+attempt before prerequisites are met is rejected (`403 locked`), and a legitimately unlocked
+attempt (all 6 stages genuinely complete) still succeeds and completes normally. A pre-existing
+gap was also found and fixed in `e2e-phase5b.js`'s own capstone-completion test, which had never
+included the `real-ops` stage in its completion loop — it was passing only because the very
+bug this phase fixes let an incomplete curriculum still start the capstone. See that test file's
+own comment for detail.

docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md

@@ -0,0 +1,114 @@
+# ROOT_ Curriculum Coverage Matrix
+
+Phase 6B §1 — maps every scenario Phase 6B puts to structured use, with an intentional reason
+for each placement (not coverage-percentage padding). Built from
+`docs/ROOT_CURRICULUM_INVENTORY.md`'s evidence. Statuses: **READY** (a student can actually
+learn from it end to end — see `docs/COURSE_AUTHORING_STANDARD.md`'s bar), **PARTIAL** (real
+lesson + labs, missing one or more of demonstration/knowledge-check/guided-exercise), **PLANNED**
+(structure only, no content), **GAP** (no suitable scenario exists at all).
+
+## Duplicate concepts identified (handled explicitly, not silently mapped twice)
+
+- `pod-security-context` (generic) vs. `cks-pod-security-context` (CKS-flavored) — same concept.
+  `cks-pod-security-context` is the CORE guided lab (ROOT 09 m01); `pod-security-context` is
+  classified INDEPENDENT PRACTICE (a second, optional rep).
+- `rbac-clusterrole` (generic) vs. `cks-rbac-clusterrole` (CKS-flavored) — same concept.
+  `cks-rbac-clusterrole` is CORE (ROOT 09 m02); `rbac-clusterrole` is INDEPENDENT PRACTICE.
+- `network-policy` (generic, foundational) vs. `cks-network-policy` (CKS default-deny framing) vs.
+  `networkpolicy-egress` (generic egress) — three related but distinct angles, deliberately split
+  across two courses: `network-policy` teaches the ARCHITECTURAL concept in ROOT 07 (what a
+  NetworkPolicy is/does); `cks-network-policy`/`cks-egress-namespace`/`networkpolicy-egress`
+  teach it as a SECURITY CONTROL in ROOT 09 (default-deny posture, least-privilege network
+  access) — not a duplicate once the teaching angle is made explicit, so both are CORE in their
+  respective course, not one marked redundant.
+
+## ROOT 05 — Kubernetes Foundations
+
+| Module | Objective | Lesson | Demo | KC | Guided | Scenario(s) | Assessment | Real Ops | Status |
+|---|---|---|---|---|---|---|---|---|---|
+| m02 Kubernetes Mental Model & Core Objects (NEW) | Explain what Kubernetes solves, the control-plane/worker/desired-state model, and navigate Pods/Namespaces/labels with kubectl | Yes | Yes | Yes | Yes | pod-basics-mcq, namespaces-basics, labels-selectors-mcq, kubectl-essentials-mcq (existing, re-sequenced as this module's guided path) | — | "declarative config drifts back to desired state after manual edits" | **READY** |
+| m01 Pods & kubectl Basics (existing) | Mechanical kubectl fluency across the Foundation stage's 20 scenarios | No | No | No | No | all 20 Foundation scenarios | — | — | PARTIAL (unchanged from Phase 6A — m02 above is the new front door; m01's labs remain a practice bank behind it) |
+
+`m02` is sequenced BEFORE `m01` (prerequisite: none; `m01`'s prerequisite becomes `m02`) so a
+student meets the mental model before the bare-lab bank, per this phase's core principle.
+
+## ROOT 06 — Kubernetes Application Workloads
+
+| Module | Objective | Lesson | Demo | KC | Guided | Scenario(s) | Real Ops | Status |
+|---|---|---|---|---|---|---|---|---|
+| m02 Deployments, Scaling & Updates (NEW) | Explain why Deployments/ReplicaSets exist, perform a rolling update, and reason about rollback | Yes | Yes | Yes | Yes | deploy-nginx, scale-deployment, rolling-update-task, deployment-rollback (newly wired — Workloads & Scheduling bucket, belongs here not ROOT 08) | "a bad rollout with no rollback plan turns a deploy into an outage" | **READY** |
+| m03 Jobs, CronJobs & DaemonSets (NEW) | Distinguish one-shot Jobs, scheduled CronJobs, and per-node DaemonSets from long-running Deployments | Yes | No | Yes | No | job-task, cronjob-task (newly wired), jobs-cronjobs-mcq, daemonset-mcq | "a cleanup Job that never completes silently exhausts cluster resources" | PARTIAL (lesson+KC authored; no separate demo/guided — labs carry the practice) |
+| m01 Deployments & Workloads (existing) | Bare-lab bank, Workloads stage's original 8 scenarios | No | No | No | No | (unchanged) | — | PARTIAL (unchanged) |
+
+## ROOT 07 — Kubernetes Networking & Configuration
+
+| Module | Objective | Lesson | Demo | KC | Guided | Scenario(s) | Real Ops | Status |
+|---|---|---|---|---|---|---|---|---|
+| m03 Services & Service Discovery (NEW) | Explain the Service/Endpoints/DNS request path and choose the right Service type | Yes | Yes | Yes | Yes | services-mcq, expose-service-basics, nodeport-task, dns-resolution-mcq (newly wired) | "a Service with zero endpoints looks identical to network failure from the outside" | **READY** |
+| m04 Ingress & NetworkPolicy Foundations (NEW) | Explain how Ingress routes external traffic and what a NetworkPolicy architecturally does | Yes | No | Yes | No | ingress-task, network-policy (newly wired) | "traffic reachability should be intentional, not incidental" | PARTIAL |
+| m02 Configuration & Secrets (existing) | Bare-lab bank | No | No | No | No | (unchanged) | — | PARTIAL (unchanged) |
+| m01 Services & Networking (existing) | Bare-lab bank, folded conceptually under m03 above | No | No | No | No | (unchanged) | — | PARTIAL (unchanged) |
+
+## ROOT 08 — Kubernetes Storage & Scheduling (newly wired this phase — was PLANNED)
+
+| Module | Objective | Lesson | Demo | KC | Guided | Scenario(s) | Real Ops | Status |
+|---|---|---|---|---|---|---|---|---|
+| m01 Storage Fundamentals (NEW) | Explain ephemeral vs. persistent storage and how PV/PVC/StorageClass fit together | Yes | No | Yes | No | emptydir-pod, pv-pvc-mount, pvc-dynamic-task, storageclass-mcq | "a Pod restart on ephemeral storage silently loses data no one told the team about" | PARTIAL |
+| m02 Scheduling & Resource Governance (NEW) | Explain how the scheduler places Pods and how quotas/limits/priority shape that placement | Yes | No | Yes | No | node-label-selector, node-taint-toleration, pod-affinity-mcq, priority-class-task, pod-disruption-budget-task, resource-quota-ns, limitrange-task | "an eviction during a voluntary disruption without a PDB can take down every replica at once" | PARTIAL |
+
+`cluster-upgrade-mcq` and `etcd-backup-mcq` (Cluster Administration bucket) are left
+**PRACTICE-ONLY** — they're genuine cluster-operator content but conceptually belong with ROOT 11
+(DevOps & Platform Engineering, out of Phase 6B's authoring scope per the authorization), not
+storage/scheduling. Mapping them here just to raise a coverage number would violate this
+document's own "quality over percentage" rule.
+
+## ROOT 09 — Kubernetes Security (newly wired this phase — was PLANNED)
+
+Not built as 22 disconnected CKS tasks. Four modules, foundational → advanced:
+
+| Module | Focus | Classification of its scenarios | Status |
+|---|---|---|---|
+| m01 Security Model & SecurityContext (NEW) | Defense in depth, least privilege, non-root/capabilities/read-only-fs | CORE: cks-pod-security-context, cks-non-root-enforce, cks-drop-capabilities, cks-readonly-filesystem. GUIDED: cks-seccomp-profile. ADVANCED: cks-apparmor-profile. INDEPENDENT: pod-security-context (dup, see above) | **READY** |
+| m02 ServiceAccounts & RBAC (NEW) | Identity for workloads, least-privilege permissions | CORE: serviceaccount-pod, cks-automount-token, rbac-role, cks-rbac-clusterrole, cks-rbac-least-privilege. INDEPENDENT: rbac-clusterrole (dup, see above) | PARTIAL (lesson authored; no separate demo/guided) |
+| m03 Network & Supply Chain Security (NEW) | NetworkPolicy as a security control, image/registry trust, TLS ingress | CORE: cks-network-policy, cks-egress-namespace, cks-tls-ingress, cks-image-pull-secret. GUIDED: networkpolicy-egress. ADVANCED: cks-network-policy-metadata. ASSESSMENT BANK: cks-mcq-image-footprint | PARTIAL |
+| m04 Cluster Hardening & Runtime Security (NEW) | Pod Security Admission, audit policy, runtime sandboxing — survey-level, not daily-driver core | CORE: cks-psa-namespace, cks-immutable-secret. ADVANCED: cks-audit-policy, cks-runtime-class. ASSESSMENT BANK: cks-mcq-api-server, cks-mcq-audit-policy, cks-mcq-kubelet-auth, cks-mcq-psp-replacement, cks-mcq-runtime-security, cks-mcq-sandboxing | PARTIAL |
+
+"ASSESSMENT BANK" scenarios are intentionally NOT wired as required module activities — they're
+recall-style MCQs well suited to a future structured exam pool (`rootnode-quick-assessment`-style
+definition), not hands-on core teaching. Not wired into `module_activities` this phase; flagged
+here so a future phase doesn't have to re-discover them.
+
+## ROOT 10 — Kubernetes Troubleshooting & Observability
+
+The gold-standard Health Probes module (`root-10-m01`) is **preserved unmodified** — it's the
+template, not a page to be made "consistent" with anything else.
+
+| Module | Objective | Lesson | Demo | KC | Guided | Scenario(s) | Real Ops | Status |
+|---|---|---|---|---|---|---|---|---|
+| m01 Health Probes & Troubleshooting (existing, UNCHANGED) | — | Yes | Yes | Yes | Yes | rootnode-probe-port-mismatch | Yes | **READY** |
+| m03 The RootNode Troubleshooting Framework (NEW) | Apply Observe→Evidence→Hypothesis→Test→Repair→Validate→Prevent to a CrashLoopBackOff and a broken Service | Yes | Yes | Yes | No | crashloop-fix, endpoint-fix-task, container-logging-mcq (newly wired) | "a repeatable framework beats guessing under a 2am page" | PARTIAL (no separate guided exercise — the framework lesson + demo carry that role) |
+| m02 General Troubleshooting (existing) | Bare-lab bank | No | No | No | No | (unchanged) | — | PARTIAL (unchanged) |
+
+## ROOT 12 — RootNode Real Ops
+
+| Module | Objective | Lesson | Scenario(s) | Framing | Status |
+|---|---|---|---|---|---|
+| m01 Real Ops Incidents (existing, extended with framing) | Apply Detect→Triage→Diagnose→Mitigate→Recover→Verify→Learn to real incidents | Yes (new incident-response framework lesson) | rootnode-runaway-monitor, broken-deployment, rootnode-probe-port-mismatch (reused), rootnode-enforce-limits | Each lab gets a short incident-context intro + post-incident reflection (not full lesson/demo/KC per incident — see `docs/PHASE6B_ROOT_CURRICULUM_EXPANSION.md` for why) | PARTIAL |
+
+`rootnode-real-ops` bundle contains exactly these 4 scenario ids (verified against
+`scenarios/bundles/rootnode-real-ops.json`) — no additional upstream scenario was intentionally
+included there beyond what `rootnode-path.json`'s `real-ops` stage already lists.
+
+## ROOT CAPSTONE
+
+| Module | Content | Status |
+|---|---|---|
+| m01 Operate and Recover (existing) | The real `rootnode-capstone` assessment | PARTIAL (unchanged — assessment engine, not lesson content) |
+| m02 Capstone Readiness (NEW) | What the capstone measures, prerequisites, how the timed/random draw works, time management, troubleshooting strategy, what completion means — derives real readiness from curriculum state, never publishes the draw or answers | **READY** |
+
+## Scenarios deliberately left out of structured curriculum entirely
+
+`cluster-upgrade-mcq`, `etcd-backup-mcq` (ROOT 11 territory, out of scope), and the 6
+ASSESSMENT-BANK-classified CKS MCQs above (not yet wired to an actual assessment definition —
+future work, not silently dropped). All remain reachable via the existing Practice tab/bundles,
+unaffected by any of this.

docs/ROOT_CURRICULUM_INVENTORY.md

@@ -0,0 +1,221 @@
+# ROOT_ Curriculum Inventory
+
+Phase 6A §1 — a factual inventory of what already exists in this repository, gathered by
+inspecting `scenarios/data/`, `scenarios/bundles/`, `scenarios/rootnode-path.json`,
+`assessment_definitions` (013_assessments.sql), `programs` (019_programs.sql), `achievements`,
+and the curriculum/progress APIs — before any Phase 6A design work happened. Nothing here was
+modified to produce this document.
+
+## 1. The current program model
+
+One program exists: `root-kubernetes-foundations` (`programs` table, family `root`,
+`delivery_mode = self_paced`, `curriculum_path = rootnode-path`,
+`completion_assessment_id = rootnode-capstone`). `init`/`compile` families are supported by the
+schema's CHECK constraint but have zero seeded programs — no init_/compile_ curriculum exists
+anywhere in this repository.
+
+## 2. `scenarios/rootnode-path.json` — the existing stage structure
+
+The one curriculum path that exists, "RootNode Learning Path," version 1, with 7 stages:
+
+| Stage | Scenario count | Completion rule |
+|---|---|---|
+| `foundation` | 20 | all_required |
+| `workloads` | 8 | all_required |
+| `networking` | 2 | all_required |
+| `configuration` | 5 | all_required |
+| `troubleshooting` | 5 | all_required |
+| `real-ops` (bundle `rootnode-real-ops`) | 4 | all_required |
+| `capstone` (type `capstone`) | 0 (references `rootnode-capstone`) | unlocks when all 6 content stages above are complete |
+
+44 of the repository's 98 total scenarios are wired into this path. The remaining 54 exist as
+real, working scenario content but are not referenced by `rootnode-path.json` at all — see §4.
+
+## 3. `scenarios/bundles/` — exam-prep bundle groupings
+
+Five bundles exist (`1-k8s-basics`, `2-k8s-appdev`, `3-k8s-admin`, `4-k8s-security`,
+`rootnode-real-ops`), each a flat list of scenario ids used for CKS-style exam-prep grouping in
+the existing Practice area — overlapping by design (a scenario can appear in more than one
+bundle). These are unrelated to `rootnode-path.json`'s stages and untouched by Phase 6A.
+
+## 4. Full scenario inventory
+
+For every scenario in `scenarios/data/` (98 total): id, title, category, difficulty, task vs.
+MCQ, which bundle(s) it's in, which `rootnode-path.json` stage (if any) it's wired into, whether
+it appears in the `rootnode-capstone` or `rootnode-quick-assessment` `assessment_definitions`
+pool_spec, and whether it's RootNode-authored or generic upstream content.
+
+Only 3 scenarios are RootNode-specific (`rootnode-runaway-monitor`,
+`rootnode-probe-port-mismatch`, `rootnode-enforce-limits`) — every other scenario, including all
+44 wired into `rootnode-path.json`, is generic upstream Kubernetes/CKS content. This matters for
+Phase 6A's course design: the "gold-standard module" spec explicitly asked for a RootNode-
+authored incident as the lab, which narrows the real choice to those 3 (plus `broken-deployment`,
+generic but already framed as an incident in the `real-ops` stage).
+
+<!-- Generated from scenarios/data/*.json, scenarios/bundles/*.json, scenarios/rootnode-path.json,
+     and platform/api/migrations/013_assessments.sql's seeded pool_specs — not hand-typed. -->
+
+| Scenario ID | Title | Category | Difficulty | Type | Bundles | Path Stage | In Assessment | Origin |
+|---|---|---|---|---|---|---|---|---|
+| annotate-resource-basics | Annotating Kubernetes Resources | Core Concepts | Easy | task | 1-k8s-basics | foundation | — | generic upstream |
+| broken-deployment | Debug a Failing Deployment | Troubleshooting | Medium | task | 3-k8s-admin, rootnode-real-ops | real-ops | capstone, quick-assessment | generic upstream |
+| cks-apparmor-profile | AppArmor Profiles | Workload Security | Hard | task | 4-k8s-security | — | — | generic upstream |
+| cks-audit-policy | Write a Kubernetes Audit Policy | Cluster Setup | Hard | task | 4-k8s-security | — | — | generic upstream |
+| cks-automount-token | Disable ServiceAccount Token | Workload Security | Easy | task | 4-k8s-security | — | — | generic upstream |
+| cks-drop-capabilities | Drop Linux Capabilities | Workload Security | Medium | task | 4-k8s-security | — | — | generic upstream |
+| cks-egress-namespace | Restrict Egress to Namespace | Network Security | Hard | task | 4-k8s-security | — | — | generic upstream |
+| cks-image-pull-secret | Private Registry Image Pull Secret | Supply Chain Security | Easy | task | 4-k8s-security | — | — | generic upstream |
+| cks-immutable-secret | Immutable Secrets | Cluster Security | Easy | task | 4-k8s-security | — | — | generic upstream |
+| cks-mcq-api-server | API Server Authentication | Cluster Setup | Easy | mcq | 4-k8s-security | — | — | generic upstream |
+| cks-mcq-audit-policy | Kubernetes Audit Logging Levels | Cluster Setup | Medium | mcq | 4-k8s-security | — | — | generic upstream |
+| cks-mcq-image-footprint | Minimizing Image Footprint | Supply Chain Security | Easy | mcq | 4-k8s-security | — | — | generic upstream |
+| cks-mcq-kubelet-auth | Securing the Kubelet | Cluster Setup | Medium | mcq | 4-k8s-security | — | — | generic upstream |
+| cks-mcq-psp-replacement | Pod Security Evolution | Cluster Security | Easy | mcq | 4-k8s-security | — | — | generic upstream |
+| cks-mcq-runtime-security | Runtime Security Tools | System Hardening | Medium | mcq | 4-k8s-security | — | — | generic upstream |
+| cks-mcq-sandboxing | Container Runtime Sandboxing | System Hardening | Hard | mcq | 4-k8s-security | — | — | generic upstream |
+| cks-network-policy | Default Deny Network Policy | Network Security | Medium | task | 4-k8s-security | — | — | generic upstream |
+| cks-network-policy-metadata | Block Cloud Metadata | Network Security | Hard | task | 4-k8s-security | — | — | generic upstream |
+| cks-non-root-enforce | Enforce Non-Root Container | Workload Security | Medium | task | 4-k8s-security | — | — | generic upstream |
+| cks-pod-security-context | Pod Security Context | Workload Security | Medium | task | 4-k8s-security | — | — | generic upstream |
+| cks-psa-namespace | Pod Security Admission | Cluster Security | Easy | task | 4-k8s-security | — | — | generic upstream |
+| cks-rbac-clusterrole | Cluster-Level RBAC | Cluster Security | Medium | task | 4-k8s-security | — | — | generic upstream |
+| cks-rbac-least-privilege | RBAC Least Privilege | Cluster Security | Medium | task | 4-k8s-security | — | — | generic upstream |
+| cks-readonly-filesystem | Read-Only Root Filesystem | Workload Security | Easy | task | 4-k8s-security | — | — | generic upstream |
+| cks-runtime-class | RuntimeClass for Sandboxed Workloads | System Hardening | Medium | task | 4-k8s-security | — | — | generic upstream |
+| cks-seccomp-profile | Seccomp Profiles | Workload Security | Hard | task | 4-k8s-security | — | — | generic upstream |
+| cks-tls-ingress | Secure Ingress with TLS | Network Security | Hard | task | 4-k8s-security | — | — | generic upstream |
+| cluster-upgrade-mcq | Cluster Upgrade Order | Cluster Administration | Hard | mcq | 3-k8s-admin | — | — | generic upstream |
+| configmap-volume | Mount ConfigMap as Volume | Configuration | Medium | task | 1-k8s-basics, 2-k8s-appdev | configuration | — | generic upstream |
+| container-logging-mcq | Container Logging and Monitoring | Troubleshooting | Easy | mcq | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| crashloop-fix | Fix a CrashLoopBackOff Pod | Troubleshooting | Medium | task | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| cronjob-task | Create a CronJob | Workloads & Scheduling | Easy | task | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| daemonset-mcq | Understanding DaemonSets | Workloads | Easy | mcq | 1-k8s-basics | workloads | quick-assessment | generic upstream |
+| delete-by-label-basics | Bulk Deletion by Label | Core Concepts | Easy | task | 1-k8s-basics | foundation | — | generic upstream |
+| deploy-nginx | Deploy and Expose Nginx | Workloads | Easy | task | 1-k8s-basics, 2-k8s-appdev | workloads | capstone, quick-assessment | generic upstream |
+| deployment-rollback | Rolling Back a Deployment | Workloads & Scheduling | Easy | task | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| deployment-strategy-mcq | Deployment Update Strategies | Workloads | Medium | mcq | 1-k8s-basics | workloads | — | generic upstream |
+| dns-resolution-mcq | Kubernetes DNS Resolution | Services & Networking | Easy | mcq | 3-k8s-admin | — | — | generic upstream |
+| dry-run-manifest-basics | Generating YAML Manifests | Core Concepts | Easy | task | 1-k8s-basics | foundation | — | generic upstream |
+| edit-deployment-basics | Updating Deployments | Workloads | Easy | task | 1-k8s-basics | workloads | capstone | generic upstream |
+| emptydir-pod | Shared emptyDir Volume Between Containers | Storage | Easy | task | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| endpoint-fix-task | Fix a Broken Service Selector | Troubleshooting | Medium | task | 3-k8s-admin | — | — | generic upstream |
+| env-vars-configmap | Environment Variables from ConfigMap | Configuration | Easy | task | 1-k8s-basics, 2-k8s-appdev | configuration | capstone | generic upstream |
+| etcd-backup-mcq | etcd Backup and Restore | Cluster Administration | Hard | mcq | 3-k8s-admin | — | — | generic upstream |
+| exec-command-basics | Execute Commands in Pods | Troubleshooting | Easy | task | 1-k8s-basics | troubleshooting | capstone, quick-assessment | generic upstream |
+| expose-service-basics | Exposing an Application | Services & Networking | Easy | task | 1-k8s-basics | networking | quick-assessment | generic upstream |
+| extract-logs-basics | Extract Container Logs | Troubleshooting | Easy | task | 1-k8s-basics | troubleshooting | capstone, quick-assessment | generic upstream |
+| field-selector-basics | Filtering Resources with Field Selectors | Core Concepts | Easy | task | 1-k8s-basics | foundation | — | generic upstream |
+| ingress-task | Create an Ingress Resource | Services & Networking | Medium | task | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| init-container-task-basics | Pod with Init Container | Core Concepts | Medium | task | 1-k8s-basics | foundation | — | generic upstream |
+| init-containers-mcq | Init Containers Behaviour | Core Concepts | Easy | mcq | 1-k8s-basics | foundation | — | generic upstream |
+| job-task | Create a One-Shot Job | Workloads & Scheduling | Easy | task | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| jobs-cronjobs-mcq | Jobs vs CronJobs | Workloads | Easy | mcq | 1-k8s-basics | workloads | — | generic upstream |
+| jsonpath-basics | JSONPath Data Extraction | Core Concepts | Medium | task | 1-k8s-basics | foundation | — | generic upstream |
+| kubectl-cp-basics | Copy Files to Containers | Troubleshooting | Medium | task | 1-k8s-basics | troubleshooting | capstone, quick-assessment | generic upstream |
+| kubectl-diff-basics | Previewing Changes with kubectl diff | Core Concepts | Medium | task | 1-k8s-basics | foundation | — | generic upstream |
+| kubectl-essentials-mcq | Essential kubectl Commands | Core Concepts | Easy | mcq | 1-k8s-basics, 2-k8s-appdev | foundation | — | generic upstream |
+| kubectl-explain-basics | Exploring the API with kubectl explain | Core Concepts | Easy | task | 1-k8s-basics | foundation | — | generic upstream |
+| kubectl-output-format-mcq | kubectl Output Formats | Core Concepts | Easy | mcq | 1-k8s-basics | foundation | — | generic upstream |
+| kubectl-patch-basics | Patching Resources with kubectl patch | Core Concepts | Medium | task | 1-k8s-basics | foundation | — | generic upstream |
+| labels-selectors-mcq | Labels and Selectors | Core Concepts | Easy | mcq | 1-k8s-basics, 2-k8s-appdev | foundation | — | generic upstream |
+| limitrange-task | LimitRange for Default Container Limits | Workloads & Scheduling | Medium | task | 3-k8s-admin | — | — | generic upstream |
+| liveness-probe-task | Configure a Liveness Probe | Workloads | Medium | task | 1-k8s-basics, 2-k8s-appdev | workloads | capstone, quick-assessment | generic upstream |
+| multi-container-pod-basics | Create a Multi-Container Pod | Core Concepts | Easy | task | 1-k8s-basics | foundation | — | generic upstream |
+| namespaces-basics | Working with Namespaces | Core Concepts | Easy | task | 1-k8s-basics, 2-k8s-appdev | foundation | — | generic upstream |
+| network-policy | Isolate Traffic with NetworkPolicy | Networking | Hard | task | 3-k8s-admin | — | — | generic upstream |
+| networkpolicy-egress | Egress NetworkPolicy | Security | Hard | task | 3-k8s-admin | — | — | generic upstream |
+| node-cordon-basics | Cordoning and Uncordoning a Node | Cluster Management | Easy | task | 1-k8s-basics | troubleshooting | capstone, quick-assessment | generic upstream |
+| node-label-selector | Node Labels and nodeSelector | Cluster Administration | Easy | task | 3-k8s-admin | — | — | generic upstream |
+| node-taint-toleration | Taints and Tolerations | Cluster Administration | Medium | task | 3-k8s-admin | — | — | generic upstream |
+| nodeport-task | Expose a Deployment via NodePort | Services & Networking | Easy | task | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| pod-affinity-mcq | Pod Affinity vs Anti-Affinity | Workloads & Scheduling | Medium | mcq | 3-k8s-admin | — | — | generic upstream |
+| pod-basics-mcq | Pod Lifecycle States | Core Concepts | Easy | mcq | 1-k8s-basics, 2-k8s-appdev | foundation | — | generic upstream |
+| pod-disruption-budget-task | Configure a PodDisruptionBudget | Cluster Administration | Medium | task | 3-k8s-admin | — | — | generic upstream |
+| pod-env-vars-inline | Pod with Inline Environment Variables | Configuration | Easy | task | 1-k8s-basics | configuration | — | generic upstream |
+| pod-labeling-basics | Labelling Resources | Core Concepts | Easy | task | 1-k8s-basics | foundation | — | generic upstream |
+| pod-node-assignment-mcq | Assigning Pods to Nodes | Scheduling | Medium | mcq | 1-k8s-basics | troubleshooting | — | generic upstream |
+| pod-security-context | Pod Security Context | Security | Medium | task | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| priority-class-task | Pod Priority and PriorityClass | Workloads & Scheduling | Medium | task | 3-k8s-admin | — | — | generic upstream |
+| pv-pvc-mount | Persistent Storage with PV and PVC | Storage | Medium | task | 3-k8s-admin | — | — | generic upstream |
+| pvc-dynamic-task | Dynamic PVC Provisioning | Storage | Medium | task | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| rbac-clusterrole | ClusterRole and ClusterRoleBinding | Cluster Administration | Medium | task | 3-k8s-admin | — | — | generic upstream |
+| rbac-role | RBAC: Create Role and RoleBinding | Security | Hard | task | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| readiness-probe-task | Configure a Readiness Probe | Workloads & Scheduling | Medium | task | 2-k8s-appdev, 3-k8s-admin | — | — | generic upstream |
+| resource-limits-task | Resource Requests and Limits | Configuration | Easy | task | 1-k8s-basics, 2-k8s-appdev | configuration | capstone | generic upstream |
+| resource-quota-ns | ResourceQuota for a Namespace | Cluster Administration | Medium | task | 3-k8s-admin | — | — | generic upstream |
+| restart-policy-mcq | Pod Restart Policies | Core Concepts | Easy | mcq | 1-k8s-basics | foundation | — | generic upstream |
+| rolling-update-task | Perform a Rolling Update | Workloads | Easy | task | 1-k8s-basics, 2-k8s-appdev | workloads | capstone, quick-assessment | generic upstream |
+| rootnode-enforce-limits | Stop the Next Outage: Enforce Resource Defaults | Observability & Ops | Hard | task | rootnode-real-ops | real-ops | capstone, quick-assessment | RootNode-specific |
+| rootnode-probe-port-mismatch | Stuck Not-Ready: The Probe Port Mismatch | Observability & Ops | Medium | task | rootnode-real-ops | real-ops | capstone, quick-assessment | RootNode-specific |
+| rootnode-runaway-monitor | Recover the Monitoring Stack | Observability & Ops | Medium | task | rootnode-real-ops | real-ops | capstone, quick-assessment | RootNode-specific |
+| scale-deployment | Scaling a Deployment | Workloads | Easy | task | 1-k8s-basics, 2-k8s-appdev | workloads | capstone, quick-assessment | generic upstream |
+| secrets-basics | Creating and Using Secrets | Configuration | Easy | task | 1-k8s-basics, 2-k8s-appdev | configuration | capstone | generic upstream |
+| serviceaccount-pod | ServiceAccount for Pod API Access | Cluster Administration | Medium | task | 3-k8s-admin | — | — | generic upstream |
+| services-mcq | Kubernetes Service Types | Networking | Easy | mcq | 1-k8s-basics, 2-k8s-appdev | networking | quick-assessment | generic upstream |
+| sort-by-basics | Sorting kubectl Output | Core Concepts | Easy | task | 1-k8s-basics | foundation | — | generic upstream |
+| static-pods-mcq | Static Pods in Kubernetes | Core Concepts | Medium | mcq | 1-k8s-basics | foundation | — | generic upstream |
+| storageclass-mcq | StorageClass Reclaim Policies | Storage | Easy | mcq | 3-k8s-admin | — | — | generic upstream |
+
+## 5. Unused content bank, grouped for future ROOT_ modules
+
+The 54 scenarios with no Path Stage above, grouped by category — a real, working content bank
+ROOT 07/08/09/10 can draw on in Phase 6B, not content that needs to be invented:
+
+- **Workload Security (7):** cks-apparmor-profile, cks-automount-token, cks-drop-capabilities, cks-non-root-enforce, cks-pod-security-context, cks-readonly-filesystem, cks-seccomp-profile
+- **Cluster Setup (4):** cks-audit-policy, cks-mcq-api-server, cks-mcq-audit-policy, cks-mcq-kubelet-auth
+- **Network Security (4):** cks-egress-namespace, cks-network-policy-metadata, cks-network-policy, cks-tls-ingress
+- **Supply Chain Security (2):** cks-image-pull-secret, cks-mcq-image-footprint
+- **Cluster Security (5):** cks-immutable-secret, cks-mcq-psp-replacement, cks-psa-namespace, cks-rbac-clusterrole, cks-rbac-least-privilege
+- **System Hardening (3):** cks-mcq-runtime-security, cks-mcq-sandboxing, cks-runtime-class
+- **Cluster Administration (8):** cluster-upgrade-mcq, etcd-backup-mcq, node-label-selector, node-taint-toleration, pod-disruption-budget-task, rbac-clusterrole, resource-quota-ns, serviceaccount-pod
+- **Troubleshooting (3):** container-logging-mcq, crashloop-fix, endpoint-fix-task
+- **Workloads & Scheduling (7):** cronjob-task, deployment-rollback, job-task, limitrange-task, pod-affinity-mcq, priority-class-task, readiness-probe-task
+- **Services & Networking (3):** dns-resolution-mcq, ingress-task, nodeport-task
+- **Storage (4):** emptydir-pod, pv-pvc-mount, pvc-dynamic-task, storageclass-mcq
+- **Networking (1):** network-policy
+- **Security (3):** networkpolicy-egress, pod-security-context, rbac-role
+
+## 6. Other existing systems inspected
+
+- **Assessment definitions** (`assessment_definitions`): `rootnode-capstone` (90 min, hint_policy
+  `flagged`, required = the 4 real-ops scenarios, random draw across workloads/config/
+  troubleshooting) and `rootnode-quick-assessment` (60 min exam, fully random draw). Both real,
+  both working, neither touched by Phase 6A — the new capstone course activity references
+  `rootnode-capstone` by id only.
+- **Achievements** (`achievements`): 4 types already implemented — `stage_completed`,
+  `curriculum_completed`, `assessment_completed`, `capstone_completed`. Phase 6A's
+  `auto_assessment` completion behavior reads `assessment_completed`/`capstone_completed` rows
+  by `metadata->>'assessment_definition_id'` — no new achievement type needed.
+  - **Progress/attempt model** (`progress`, `scenario_attempts`): unchanged. `progress` is what
+  `curriculum-rules.js` and the new `auto_scenario` completion behavior both read.
+- **Curriculum APIs**: `curriculum.js` loads scenarios/bundles/path from disk into an in-process
+  cache; `curriculum-rules.js` computes stage lock/completion/percent purely from that path +
+  a progress map. Phase 6A's `course-progress.js` follows the identical shape one level higher
+  (course/module/activity instead of stage/scenario).
+- **Self-paced dashboard** (`ProgramsTab.jsx`) and **classroom dashboard** (`ClassroomTab.jsx`,
+  admin `ClassroomView.jsx`): both currently show curriculum STATE (percent, next scenario) with
+  no notion of lessons/modules — Phase 6A's `CourseView.jsx`/`CurriculumView.jsx` add that layer
+  alongside, not instead of, these.
+- **Admin curriculum/program tooling** (`admin-learning-routes.js`, `admin-programs-routes.js`):
+  read-only scenario/stage views and program/enrollment CRUD; no course/module concept existed
+  before this phase.
+
+## 7. What this inventory rules out
+
+- No init_/compile_ curriculum content exists anywhere — confirmed by a full scan of
+  `scenarios/data/`, not an assumption.
+- No DevOps/CI/CD/IaC/GitOps scenario content exists (ROOT 11 is necessarily 100% PLANNED).
+- No Linux-fundamentals, Git, or Docker-specific scenario content exists (ROOT 01-04 are
+  necessarily 100% PLANNED) — everything in `scenarios/data/` is Kubernetes/CKS content.
+
+## 8. Phase 6B update — scenario coverage after curriculum authoring
+
+Phase 6B wired 44 more of the scenarios above into structured curriculum (verified by direct
+query against `module_activities.scenario_id`, not estimated): **88 of 98 scenarios (89.8%)**
+are now in structured curriculum, up from 44 at the end of Phase 6A. The remaining 10 —
+`cluster-upgrade-mcq`, `etcd-backup-mcq` (ROOT 11 territory), 7 CKS-style MCQs classified as
+future ASSESSMENT BANK material, and `readiness-probe-task` (a genuine, documented gap for
+Phase 6C) — are listed with their specific reasons in
+`docs/PHASE6B_ROOT_CURRICULUM_EXPANSION.md` §5. The full course-by-course mapping, including
+which scenarios were classified CORE/GUIDED/INDEPENDENT/ADVANCED/ASSESSMENT-BANK and why, lives
+in `docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md` — this file is intentionally not duplicated there.

docs/ROOT_PROGRAM_ARCHITECTURE.md

@@ -0,0 +1,109 @@
+# ROOT_ Program Architecture
+
+Phase 6A §2 — the canonical course architecture for `root_` (Linux → systems → containers →
+Kubernetes → DevOps/platform engineering, ages ~15-18+/college/adult per the youth ladder — see
+`docs/PHASE6A_ROOT_COURSE_FOUNDATION.md` §1). This document is the design; the actual seed data
+lives in `platform/api/migrations/022_course_content.sql`, generated to match this exactly.
+
+All 13 rows below are `courses` under the ONE existing program, `root-kubernetes-foundations`
+(`programs` table, unchanged — see §"why one program, not thirteen" below). Every status claim
+here is grounded in `docs/ROOT_CURRICULUM_INVENTORY.md`, not aspirational.
+
+**Updated for Phase 6B** (`platform/api/migrations/023_phase6b_curriculum.sql`,
+`docs/PHASE6B_ROOT_CURRICULUM_EXPANSION.md`): ROOT 08 and 09 moved from PLANNED to PARTIAL, and
+6 courses gained new teaching modules — the module-level detail and evidence for every new
+placement lives in `docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md`, not duplicated here.
+
+## Course sequence
+
+| # | Course | Status | Why |
+|---|---|---|---|
+| 1 | Computing & Linux Foundations | **PLANNED** | No lab content exists in this repository — every scenario is Kubernetes/CKS. |
+| 2 | Linux Administration & Networking | **PLANNED** | Same — no Linux-admin scenario content exists. |
+| 3 | Git & Collaborative Development | **PLANNED** | No Git scenario content exists. |
+| 4 | Containers & Docker | **PLANNED** | No Docker-specific scenario content exists (the Lab itself runs k3s, but no student-facing "learn Docker" scenarios exist). |
+| 5 | Kubernetes Foundations | **PARTIAL** | Phase 6B added a READY front-door module (`root-05-m00-kubernetes-mental-model` — full lesson/demo/knowledge-check/guided-exercise/lab/reflection) sequenced before the existing 20-scenario bare-lab bank (`root-05-m01`), which now sits behind it. |
+| 6 | Kubernetes Application Workloads | **PARTIAL** | Phase 6B added a READY `root-06-m02-deployments-scaling-updates` and a PARTIAL `root-06-m03-jobs-cronjobs-daemonsets`, both in front of the existing bare-lab bank. |
+| 7 | Kubernetes Networking & Configuration | **PARTIAL** | Phase 6B added a READY `root-07-m03-services-and-service-discovery` and a PARTIAL `root-07-m04-ingress-networkpolicy-foundations`. The existing configuration bank (`root-07-m02`) still has no authored teaching content — an honest, documented gap. |
+| 8 | Kubernetes Storage & Scheduling | **PARTIAL** | Phase 6B wired the real scenario content the inventory identified (PV/PVC, StorageClass, taints/tolerations, PDB, quotas/limits) into two new PARTIAL modules — moved off PLANNED for the first time. |
+| 9 | Kubernetes Security | **PARTIAL** | Phase 6B built the 22-scenario CKS-style bank into four modules (Security Model & SecurityContext — READY; ServiceAccounts & RBAC, Network & Supply Chain Security, Cluster Hardening & Runtime — all PARTIAL), classifying scenarios CORE/GUIDED/INDEPENDENT/ADVANCED/ASSESSMENT-BANK rather than exposing them as 22 disconnected tasks — moved off PLANNED. |
+| 10 | Kubernetes Troubleshooting & Observability | **PARTIAL** | The Phase 6A gold-standard module (READY, unmodified) plus a new PARTIAL `root-10-m03-troubleshooting-framework` (the generalized Observe/Evidence/Hypothesis/Test/Repair/Validate/Prevent framework) and the existing bare-lab bank, now sequenced last. |
+| 11 | DevOps & Platform Engineering Foundations | **PLANNED** | No CI/CD/IaC/GitOps scenario content exists anywhere in this repository — unchanged, out of Phase 6B's authoring scope. |
+| 12 | RootNode Real Ops | **PARTIAL** | Phase 6B added an incident-response framing lesson and a post-incident reflection wrapping the existing 4-scenario module — the incidents themselves are unchanged, still deliberately un-guided. |
+| 13 | ROOT Capstone — Operate and Recover a Production-Like Environment | **PARTIAL** | Phase 6B added a READY Capstone Readiness module (orientation, no answers) sequenced before the existing capstone assessment module — see `docs/ROOT_CAPSTONE_READINESS.md`. |
+
+No course is marked READY at the course level in Phase 6A — that's honest: a course only earns
+READY once every module in it has real teaching content, and Phase 6A deliberately built exactly
+one complete module (the gold standard) as the authoring template, not a finished curriculum.
+
+## Prerequisite chain
+
+```
+01 Linux Foundations → 02 Linux Admin/Networking → 03 Git → 04 Containers/Docker
+                                                                    │
+                                                                    ▼
+                                                    05 Kubernetes Foundations
+                                                                    │
+                                                                    ▼
+                                                06 Application Workloads
+                                                          │         │
+                                    ┌─────────────────────┤         │
+                                    ▼                     ▼         ▼
+                        07 Networking/Config   09 Security   10 Troubleshooting
+                                    │                              │      │
+                                    ▼                              │      ▼
+                        08 Storage/Scheduling                      │  11 DevOps/Platform
+                                                                    ▼
+                                                        12 RootNode Real Ops
+                                                                    │
+                                                                    ▼
+                                                        CAPSTONE — Operate & Recover
+```
+
+01-04 have no prerequisite chain enforced against each other yet (all PLANNED, zero content —
+locking a PLANNED course behind another PLANNED course would just be decorative). 05 is the
+first course with a real prerequisite gate. See `docs/COURSE_CONTENT_MODEL.md`'s "prerequisite/
+locking rule" for why a PLANNED/content-free prerequisite never actually blocks anything.
+
+## Deviations from the spec's suggested sequence, and why
+
+The authorization's suggested sequence listed Security (09) after Storage/Scheduling (08) and
+before Troubleshooting (10). This document keeps that numbering for continuity, but the
+**prerequisite graph** branches 09 and 10 both directly off 06 (Application Workloads) rather
+than chaining 08→09→10 linearly — the existing content doesn't actually build 09 on top of 08's
+concepts (RBAC/PSA/network-policy security content is orthogonal to PV/PVC/scheduling content),
+so a straight linear chain would impose a false dependency. This is exactly the case the
+authorization's "if existing content suggests a better grouping, document the reasoning" line
+anticipated.
+
+## Real Ops and Capstone placement
+
+Real Ops (12) sits after Troubleshooting (10), matching the existing curriculum's own stage
+order (`rootnode-path.json`'s `real-ops` stage already comes after `troubleshooting`) — Real Ops
+scenarios assume the diagnostic skills Troubleshooting teaches. The Capstone sits after Real Ops
+alone, not after every course, because that's what the existing `rootnode-capstone` assessment
+definition's own `unlock_rule` already requires (all 6 content stages of `rootnode-path.json`
+complete — which necessarily includes 05-06-07-10-12's underlying scenarios, plus networking/
+configuration). 08, 09, and 11 are not currently gating the capstone, because their scenario
+content isn't part of `rootnode-path.json`'s stage list at all yet — see
+`docs/COURSE_CONTENT_MODEL.md` for how course-level completion is computed independently of that
+assessment-engine unlock_rule (the two systems currently agree by construction, not by a shared
+implementation).
+
+## Why one program, not thirteen
+
+`programs` (Phase 5B) models the commercial/academic unit a student enrolls in. root_ is
+described by this authorization as one continuous ladder — "Linux → systems → containers →
+Kubernetes → DevOps/platform engineering" — not thirteen separate purchases. Attaching all 13
+courses to the single existing `root-kubernetes-foundations` program means:
+
+- Zero changes to the `programs` table, enrollment model, or entitlement logic — an enrolled
+  student automatically has structured access to the whole ladder as it's built out.
+- No renaming/redefinition of the existing program (which would risk a real, if cosmetic, break
+  for anyone already enrolled) — see Phase 6A's explicit "do not redesign working systems"
+  constraint.
+
+If a future phase needs `root_` split into separately-purchasable programs (e.g. "Kubernetes
+Foundations" sold standalone from "DevOps"), that's a `programs`-table decision to make
+deliberately later, informed by real pricing/business requirements — not something to guess at
+here.

docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md

@@ -0,0 +1,186 @@
+# Runbook: Google Workspace Email Configuration
+
+Everything in this document happens OUTSIDE this repository, in the Google Admin Console and
+Google Cloud Console, and is marked **REQUIRES GOOGLE WORKSPACE ADMIN ACTION**. Nothing here can
+be scripted or automated from the codebase — Chase (or whoever holds Workspace super-admin) has
+to do these steps by hand, once, before RootNode Academy can send real email.
+
+See `docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md` §2 for why this mechanism was chosen over SMTP
+or a human login.
+
+## 1. Selected mechanism
+
+**Gmail API (`users.messages.send`) via a Google Cloud service account using Workspace
+domain-wide delegation**, impersonating one dedicated sending mailbox. No human password is
+ever stored by RootNode. The delegated scope is exactly `https://www.googleapis.com/auth/
+gmail.send` — nothing broader.
+
+## 2. REQUIRES GOOGLE WORKSPACE ADMIN ACTION: create the sending mailbox
+
+Decide the address RootNode sends as — e.g. `[email protected]` or
+`[email protected]`. This repository does not assume or hard-code one; it's whatever
+you set `EMAIL_FROM_ADDRESS` to (§5).
+
+1. In Google Admin Console (admin.google.com) → Directory → Users, create this mailbox as a
+   real Workspace user (or a Google Group with "Collaborative Inbox" if you'd rather route
+   replies to a shared team inbox — either works with this mechanism, but a Group needs its own
+   delegation setup; a plain user mailbox is simpler and is what this runbook assumes).
+2. Consider giving it a strong, unique, never-reused password and enabling 2-Step Verification
+   on it anyway, even though RootNode's application will never use that password — this account
+   still exists as a real Workspace identity and should be secured like any other.
+
+**If the sending address is an ALIAS of an existing account (a real cost-saving option — you
+don't need a whole extra paid seat just for this):** that's fine and supported, but note it for
+step 4 below. Domain-wide delegation authorizes the service account to act as a real Workspace
+**user account**, not an arbitrary alias string — if `[email protected]` is an alias of,
+say, `[email protected]`, the delegation in step 4 is granted for `chase@`'s account
+(the alias's owner), and RootNode's config keeps the alias as the visible sending address
+separately (see §5's `GOOGLE_DELEGATED_USER` vs. `EMAIL_FROM_ADDRESS`). Gmail already lets any
+account send as its own verified aliases, so this works cleanly — you just need both pieces of
+information (the alias, and which account owns it) when configuring RootNode.
+
+## 3. REQUIRES GOOGLE WORKSPACE ADMIN ACTION: create the service account (Google Cloud Console)
+
+1. In Google Cloud Console (console.cloud.google.com), create or choose a GCP project associated
+   with your Workspace organization.
+2. Enable the **Gmail API** for that project (APIs & Services → Library → search "Gmail API" →
+   Enable).
+3. IAM & Admin → Service Accounts → Create Service Account. Name it something identifiable
+   (e.g. `rootnode-academy-mailer`). No project-level IAM roles are needed for this — it only
+   ever calls the Gmail API as the impersonated user, not as itself.
+4. On that service account, create a JSON key (Keys → Add Key → Create new key → JSON). This
+   downloads a file containing `client_email` and `private_key` — **this is the sensitive
+   credential**, treat it exactly like a password (see §8).
+5. Copy the service account's **Client ID** (a long numeric string, on the service account's
+   detail page) — needed for the next step.
+
+## 4. REQUIRES GOOGLE WORKSPACE ADMIN ACTION: authorize domain-wide delegation
+
+1. Google Admin Console → Security → Access and data control → API controls → Domain-wide
+   Delegation → Add new.
+2. Client ID: the numeric ID from step 3.5 above.
+3. OAuth Scopes: `https://www.googleapis.com/auth/gmail.send` — **only this scope**. Do not add
+   broader Gmail scopes (readonly, modify, etc.) — RootNode's adapter never needs them and
+   granting them would violate least-privilege for no benefit.
+4. Authorize.
+
+This grants the service account permission to act as **one specific Workspace user account**.
+If the sending address is that account's own primary login, that's the account. If the sending
+address is an ALIAS (§2), this authorization is inherently for the alias's owner account — there
+is no separate "authorize an alias" step, because delegation only ever targets real accounts.
+
+## 5. RootNode-side environment variables
+
+Set these on the Platform API's environment (production: real secret storage — see §8; local
+dev: `platform/.env`, already gitignored):
+
+| Variable | Value | Notes |
+|---|---|---|
+| `EMAIL_PROVIDER` | `gws` | Unset/anything else defaults to the dev provider — never real mail. |
+| `GOOGLE_SERVICE_ACCOUNT_JSON` | the full JSON key file's contents, as one string | The sensitive credential — see §8. |
+| `EMAIL_FROM_ADDRESS` | the address students see mail arrive from, e.g. `[email protected]` | Always the visible `From:` header. |
+| `GOOGLE_DELEGATED_USER` | **only needed if `EMAIL_FROM_ADDRESS` is an alias** — the real account that alias belongs to, e.g. `[email protected]` | This is what domain-wide delegation actually authorized in step 4. If `EMAIL_FROM_ADDRESS` is itself a primary account, leave this unset — the code falls back to `EMAIL_FROM_ADDRESS` automatically. |
+| `EMAIL_FROM_NAME` | e.g. `RootNode Academy` | Display name only, not sensitive. |
+| `EMAIL_REPLY_TO` | optional, e.g. `[email protected]` | Where a student's reply actually goes, if different from the sending address. |
+| `PUBLIC_APP_ORIGIN` | e.g. `https://learn.rootnodeacademy.com` | The origin activation/reset links are built from (§7 of the Phase 5C authorization) — required for any token-bearing email to render a working link. |
+
+**Concrete example matching the alias setup described above:** `[email protected]`
+(what students see), `[email protected]` (whose account actually
+owns that alias and was granted delegation in step 4).
+
+## 6. DNS: SPF, DKIM, DMARC (REQUIRES DNS ADMIN ACTION — not performed from this repository)
+
+Google Workspace's own documentation is authoritative here; this is a summary of what must
+exist before mail sent via the Gmail API from a Workspace mailbox reliably lands in inboxes
+instead of spam:
+
+- **SPF**: your domain's TXT record must include Google's SPF include
+  (`include:_spf.google.com`) if Workspace is your MX provider — check Admin Console → Apps →
+  Google Workspace → Gmail → Authenticate email for the exact current record Google recommends
+  for your domain.
+- **DKIM**: Admin Console → Apps → Google Workspace → Gmail → Authenticate email → generate a
+  DKIM key for the domain, then publish the TXT record it gives you, then return to that page
+  and turn DKIM signing ON. Gmail API sends from a Workspace mailbox are signed the same way
+  regular Gmail sends are once this is on.
+- **DMARC**: publish a `_dmarc` TXT record (start with `p=none` to monitor before enforcing) once
+  SPF and DKIM both pass consistently.
+
+**Do not change DNS from this repository or these instructions** — this is exactly the kind of
+external, admin-console/DNS-provider action that stays outside the codebase. Verify current
+exact record values in Google's own Workspace admin help before publishing anything.
+
+## 7. Testing procedure
+
+**Local/dev — no live credentials needed at all.** `EMAIL_PROVIDER` unset (or anything other
+than `gws`) uses the deterministic dev provider (`email/dev-provider.js`) — every notification
+still goes through the full queue/worker/retry pipeline, but nothing ever reaches a real
+network. `platform/test/e2e-phase5c.js` and the Phase 5C drills run entirely this way.
+
+**Live delivery — opt-in, one message, once credentials exist:**
+```bash
+RUN_GWS_EMAIL_TEST=true \
+TEST_EMAIL_RECIPIENT=[email protected] \
+GOOGLE_SERVICE_ACCOUNT_JSON="$(cat /path/to/service-account-key.json)" \
+EMAIL_FROM_ADDRESS=[email protected] \
+GOOGLE_DELEGATED_USER=[email protected] \
+EMAIL_FROM_NAME="RootNode Academy" \
+node infra/scripts/gws-email-test.js
+```
+(Omit `GOOGLE_DELEGATED_USER` entirely if `EMAIL_FROM_ADDRESS` is itself a primary account
+rather than an alias — see §5.) Sends exactly one clearly-marked test message to
+`TEST_EMAIL_RECIPIENT` — never inferred from production/student data, never run automatically as
+part of any regression suite. Without `RUN_GWS_EMAIL_TEST=true` it does nothing and exits
+cleanly.
+
+## 8. Production secret handling
+
+- `GOOGLE_SERVICE_ACCOUNT_JSON` is exactly as sensitive as a password — store it in whatever
+  secret manager/environment-injection mechanism the production deployment uses (see
+  `docs/PRODUCTION_DEPLOYMENT.md` for the general pattern this repo follows for other secrets
+  like `PROVISIONER_SHARED_SECRET`). **Never commit it, never put it in a Docker image layer,
+  never log it.** `gws-provider.js` reads it fresh from the environment on every send and never
+  writes it to disk.
+- Nothing in this codebase ever returns `GOOGLE_SERVICE_ACCOUNT_JSON`'s contents, an access
+  token, or any part of it through an API response, log line, or audit event.
+
+## 9. Credential rotation
+
+1. Google Cloud Console → the service account → Keys → Add Key → Create new key (JSON) — this
+   creates an ADDITIONAL valid key without invalidating the old one yet.
+2. Update `GOOGLE_SERVICE_ACCOUNT_JSON` in production's secret store to the new key, redeploy/
+   restart the Platform API.
+3. Confirm delivery still works (§7's live test, or just watch `/api/admin/notifications` for a
+   real send after the restart).
+4. Google Cloud Console → the service account → Keys → delete the OLD key.
+
+Domain-wide delegation authorization (§4) is tied to the service account's Client ID, not to any
+individual key — rotating keys does not require re-authorizing delegation.
+
+## 10. Revocation (compromised credential / offboarding)
+
+1. Google Cloud Console → the service account → Keys → delete the affected key immediately —
+   this invalidates it instantly, before anything else.
+2. If the whole service account should stop being able to send at all: Google Admin Console →
+   Security → API controls → Domain-wide Delegation → remove that Client ID's authorization.
+3. Rotate `EMAIL_FROM_ADDRESS`'s own Workspace login password as a precaution even though the
+   application never used it — a compromised service-account key doesn't imply the mailbox's own
+   credentials were exposed, but treat it as a "review this account" trigger.
+
+## 11. Troubleshooting
+
+| Symptom | Likely cause |
+|---|---|
+| Every send fails with `gws_not_configured` | `GOOGLE_SERVICE_ACCOUNT_JSON` or `EMAIL_FROM_ADDRESS` unset/malformed in the Platform API's environment. |
+| `gws_auth_failed` | Domain-wide delegation not authorized for this Client ID/scope, or the service account key was deleted/revoked. Re-check §4. **If this happens intermittently right after newly authorizing delegation** (the exact same request succeeds, then fails with `unauthorized_client`, then succeeds again, over roughly a minute) — that's Google's own auth infrastructure propagation delay, not a config error. It self-resolves; the notification worker's existing retry/backoff already absorbs it (`gws-provider.js` classifies `unauthorized_client` as retryable), so no action is needed beyond waiting. |
+| `gws_http_403` | The delegated `sub` (EMAIL_FROM_ADDRESS) isn't a real mailbox in this Workspace domain, or the Gmail API isn't enabled on the GCP project (§3.2). |
+| `gws_rate_limited` (HTTP 429) | Gmail API per-user sending limits hit — see §12. The notification worker retries this automatically with backoff. |
+| Mail sends successfully but lands in spam | SPF/DKIM/DMARC (§6) not fully configured/passing yet — this is a deliverability issue, not an application error. |
+
+## 12. Google Workspace quotas/limits relevant to this mechanism
+
+Gmail API sending inherits the same per-user daily sending limits as regular Gmail/Workspace
+sending (limits vary by Workspace edition — check current figures in Google's own Workspace
+admin documentation, as these change over time and are not something to hard-code here). For
+RootNode Academy's transactional volume (activation/enrollment/reset emails, not bulk/marketing
+— explicitly out of scope, see the Phase 5C authorization §5/§28), this should sit comfortably
+under any Workspace edition's per-user limit; revisit if enrollment volume grows substantially.

docs/RUNBOOK_SELF_PACED_ENROLLMENT.md

@@ -0,0 +1,67 @@
+# Runbook: Self-Paced Programs & Enrollment
+
+Covers managing programs and enrollments from `/admin` → Programs. See
+`docs/PHASE5B_SELF_PACED_ENROLLMENT.md` for the underlying design and
+`docs/WEBSITE_ENROLLMENT_INTEGRATION.md` for the separate website-driven path.
+
+**Create a program** (Programs → Create program, admin/owner only):
+
+Program ID is a slug (e.g. `root-linux-fundamentals`) and can't be changed later. Pick a
+family (`init_`/`compile_`/`root_`) and delivery mode. New programs default to
+`curriculum_path: rootnode-path` — the only curriculum content that exists today. A program for
+`init_`/`compile_` can be created now as a placeholder and wired to real content later without a
+schema change; it just won't have real lessons behind it yet.
+
+**Activate/deactivate a program** (Programs → \[program\] → Activate/Deactivate):
+
+An inactive program can't accept new enrollments (admin-manual or via the website integration
+endpoint) but existing enrollments in it are untouched — students already enrolled keep their
+access exactly as it was.
+
+**Manually enroll a student** (Programs → \[program\] → Enroll a student):
+
+Enter the student's ID (find it on the Students tab). Choose `pending` (the default — the
+student sees the enrollment but can't start until you Activate it) or `active` (skip that step).
+Optional start/end dates enforce access windows server-side — a future start date hides Lab
+access until then; an end date cuts off new Lab launches after it while leaving prior progress
+visible.
+
+As of Phase 5C, this also automatically emails the student — an activation link if they've never
+had credentials, or an enrollment confirmation if they already do. See
+`docs/RUNBOOK_STUDENT_ACTIVATION.md` for checking delivery status and resending.
+
+**Activate a pending enrollment** (Programs → \[program\] → Enrollments table → Activate):
+
+Only needed if you enrolled as `pending`. This is the moment a student actually gains entry.
+
+**Cancel an enrollment** (Programs → \[program\] → Enrollments table → Cancel, or Enrollments
+list on a student's own page):
+
+Immediately blocks new Lab launches. Does not touch the student's progress/achievements/attempt
+history — those are permanent regardless of enrollment status. Cancelling is final for that
+enrollment; if the student should have access again later, enroll them again (a new enrollment
+row) rather than trying to "reactivate" a cancelled one.
+
+**Check a student's enrollment history** (Students → \[student\] → "Enrolled programs" card):
+
+Shows every program the student has ever been enrolled in — pending, active, completed,
+cancelled, expired — with progress and last activity. A plain instructor sees this scoped to
+enrollments they created or that belong to a student sharing one of their cohorts; owner/admin
+see everything.
+
+**A student says "Continue Learning" isn't working / shows the wrong thing:**
+
+1. Check their enrollment status on the Programs or Student page. `pending` → activate it.
+   `expired`/`cancelled` → that's working as intended; enroll them again if they should continue.
+2. If `active` and still stuck, check `/api/admin/students/:id/environment` for a stuck Lab —
+   same troubleshooting as any other Lab issue (`docs/RUNBOOK_STUCK_LAB_CLEANUP.md`). Destroying
+   the Lab never loses their program progress; a fresh launch resumes from the same place.
+
+**A student's completion didn't register:**
+
+Completion is detected the next time their program status is *read* (their dashboard, or an
+admin viewing their enrollment) after they finish the capstone — not pushed instantly. Refresh
+the page or reopen their student detail in `/admin`; if it still doesn't show `completed` after
+that, check `GET /api/achievements` for that student for a `capstone_completed` record matching
+the program's configured capstone — if that's missing, the capstone itself wasn't actually
+finished, not an enrollment bug.

docs/RUNBOOK_STUDENT_ACCOUNT_LIFECYCLE.md

@@ -1,15 +1,20 @@
 # Runbook: Student Account Lifecycle
 
 Covers creating, converting, resetting, and revoking student accounts. See
-`docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md` for the underlying design.
+`docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md` for the underlying design and
+`docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md`/`docs/RUNBOOK_STUDENT_ACTIVATION.md` for the
+automatic-email side of this, added in Phase 5C.
 
 **Create a new credentialed student** (`/admin` → Students → Add student):
 
 Fill in display name plus **either** email (older/self-paced) or login ID (younger/instructor-
 managed) — leave both blank for a plain pilot account instead. Submitting shows an activation
-link **once**: `https://<domain>/?activate=<token>`. Copy it immediately (print it, read it
-aloud, hand it over) — it is never shown again and never stored in plaintext anywhere. The
-student opens the link and sets their own password; the instructor never sees it.
+link **once**: `https://<domain>/?activate=<token>`. As of Phase 5C, if the student has an
+email, RootNode also sends it to them automatically — the on-screen link remains a manual-relay
+fallback, useful when there's no deliverable address or the automatic email needs backup. Copy
+it if you might need it (print it, read it aloud, hand it over) — it is never shown again and
+never stored in plaintext anywhere. The student opens the link and sets their own password; the
+instructor never sees it.
 
 **Convert an existing pilot student to a real account** (Students → \[student\] → Convert):
 
@@ -40,5 +45,8 @@ students list — deactivation takes effect on their very next request, not just
 login, because `studentSession` middleware re-checks `status='active'` every time.
 
 **If a student says their activation/reset link "doesn't work":** tokens are single-use and
-time-limited (activation 7 days, reset 1 hour). Just issue a new one via Convert or Reset
-password — there's no way to "resend" the same token, and that's intentional.
+time-limited (activation 7 days, reset 1 hour). Use Students → \[student\] → **Resend
+activation** (or Reset password, for an already-activated account) to issue a new one — there's
+no way to "resend" the same token, and that's intentional (only the most recent link is ever
+valid, so there's never ambiguity about which one to use). See `docs/RUNBOOK_STUDENT_
+ACTIVATION.md` for checking whether the automatic email actually delivered.

docs/RUNBOOK_STUDENT_ACTIVATION.md

@@ -0,0 +1,71 @@
+# Runbook: Student Activation Pipeline
+
+Covers the day-to-day operation of the enrollment → activation → login pipeline from `/admin`.
+See `docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md` for the underlying design and
+`docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md` for the email delivery mechanism itself.
+
+## What happens automatically
+
+Every time a student account gains a new enrollment — whether the website's checkout triggered
+it (`POST /api/integrations/enrollments`) or an instructor enrolled them manually from
+`/admin` → Programs — RootNode decides and sends the right email on its own:
+
+- **Never activated before** → an activation email, with a one-time link to set their password.
+- **Already has real credentials** → an enrollment confirmation email pointing them back to
+  sign in — no link/token involved.
+
+Nothing needs to be triggered by hand for the normal case. The controls below are for when the
+normal case didn't work.
+
+## Checking delivery status
+
+**Per student**: Students → \[student\] → the "Notifications" card shows every notification ever
+sent to (or attempted for) that student, with type/status/attempt count. `sent` means it
+actually reached the provider successfully; `failed` means it gave up (see below); `queued`/
+`sending` means it's still in flight — check back in a few seconds, delivery happens through a
+background worker, not the same request that triggered it.
+
+**Everywhere**: `/admin` → Notifications (owner/admin only) — the same information across every
+student, most recent first.
+
+## If a student never got their activation email
+
+1. Check Students → \[student\] → Notifications. If it shows `failed`, note the error — a
+   `no_recipient_address` failure means the student truly has no email or contact address on
+   file and can only be activated by an instructor manually relaying a link (see below); other
+   error codes usually mean a delivery-infrastructure issue worth checking
+   `docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md`'s troubleshooting table for.
+2. Students → \[student\] → Credentials → **Resend activation**. This invalidates whatever link
+   was outstanding and sends a fresh one — safe to click as many times as needed; only the most
+   recent link is ever valid, so there's never a "which link do I use" confusion for the student.
+3. If the student genuinely has no deliverable address at all (a younger student with a
+   login-only account and no guardian contact email on file), convert/create them without email
+   in the first place (see `docs/RUNBOOK_STUDENT_ACCOUNT_LIFECYCLE.md`) and relay the one-time
+   activation link shown in the admin UI directly (print it, read it aloud) — this manual path
+   still works exactly as it did before Phase 5C added automatic email.
+
+## If a student says they didn't get an enrollment confirmation
+
+Check Students → \[student\] → Notifications for the `enrollment_confirmation` row. If it's
+`sent`, the email genuinely went out — check their spam folder, or confirm the address on file
+(Students → \[student\]) is actually correct. If none exists for a given enrollment,
+Programs → \[program\] → Enrollments → find the enrollment → (student detail page also works)
+and use **Send enrollment confirmation** to trigger one explicitly.
+
+## Password reset
+
+Students should use "Forgot password" on the login screen themselves wherever possible — it's
+delivered the same way as everything else here and the flow is self-service end to end.
+
+If a student can't complete self-service reset (e.g. they no longer have access to the email a
+guardian originally provided and it needs an instructor to re-trigger with a corrected address),
+Students → \[student\] → Credentials → **Send password reset** issues a fresh reset link and
+revokes all of that student's existing sessions immediately. In production, the instructor
+never sees the token itself — the response is a confirmation that an email was queued, not the
+link. If automatic delivery still can't reach the student, use `docs/RUNBOOK_STUDENT_ACCOUNT_
+LIFECYCLE.md`'s manual-relay procedure, which is unaffected by any of this.
+
+## What "resend" does NOT do
+
+Resending activation does not touch the student's enrollment status, progress, achievements, or
+attempt history — it only affects the credential/token side of their account. It's always safe.

docs/WEBSITE_ENROLLMENT_INTEGRATION.md

@@ -0,0 +1,220 @@
+# Website → RootNode Academy Enrollment Integration
+
+Audience: whoever builds `rootnodeacademy.com` (marketing, pricing, checkout) and needs to turn
+a successful purchase/signup into a real RootNode Academy student enrollment. This document is
+meant to be enough on its own — you should not need to read the Platform API's source to
+integrate against it.
+
+## Responsibility boundary
+
+**The website is responsible for:** marketing, program selection, pricing, checkout/payment (now
+or in the future), collecting enrollment/customer information, and sending ONE verified
+enrollment event to the endpoint below once payment/signup is confirmed.
+
+**RootNode's platform is responsible for everything after that:** student identity, program
+entitlement, account activation, the entire password lifecycle, all operational enrollment
+email (activation, enrollment confirmation, password reset — see
+`docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md`), learning, Labs, progress, assessment, and
+completion. **The website does not send email for platform activation or any other account
+lifecycle event — RootNode owns that entirely, as of Phase 5C.** Do not build a parallel
+"welcome" or "here's how to log in" email on the website side; it would either duplicate or
+conflict with what RootNode already sends automatically.
+
+## Architecture
+
+```
+rootnodeacademy.com (marketing, pricing, checkout — built separately, not in this repo)
+    |
+    | your backend verifies payment/signup with your payment provider
+    v
+your backend calls the RootNode Enrollment API (below) — server-to-server only
+    v
+RootNode Academy Platform API
+    creates/matches a student account
+    creates or reuses (idempotently) an enrollment
+    v
+the student logs in at the RootNode Academy platform and sees their program
+```
+
+**RootNode never talks to your payment provider, and your payment provider never talks to
+RootNode.** Your backend is the only thing that calls this endpoint, after it has already
+confirmed payment (or whatever your enrollment trigger is) on its own. This endpoint knows
+nothing about Stripe, PayPal, or any other provider's object model — it only understands a
+small, generic enrollment event described below.
+
+## The endpoint
+
+```
+POST /api/integrations/enrollments
+```
+
+Reachable at the RootNode Academy platform's public origin (the same host your students'
+browsers already use), via HTTPS in any real deployment. This is the **only** endpoint your
+backend needs.
+
+## Authentication
+
+A pre-shared secret, sent as a header:
+
+```
+X-RootNode-Integration-Key: <the secret>
+```
+
+- This is **not** a student or admin login. It has nothing to do with cookies, sessions, or
+  browser auth of any kind.
+- **The secret must live only in your backend's server-side configuration.** It must never be
+  embedded in any browser-served JavaScript, mobile app bundle, or client-side config — anyone
+  who obtains it can create enrollments.
+- A request with a missing or wrong key gets `401 { "error": "unauthorized" }` and nothing else
+  happens — no student is looked up, nothing is created.
+- RootNode will provide you with the production secret out of band (not over email/chat in
+  plaintext — ask the RootNode team for the current secure-sharing process). Rotate it by
+  asking RootNode to issue a new one; there is no self-service rotation yet.
+
+## Request
+
+```json
+{
+  "event_id": "order_9f8e7d6c5b4a",
+  "source": "website",
+  "program_slug": "root-kubernetes-foundations",
+  "status": "paid",
+  "student": {
+    "email": "[email protected]",
+    "login_identifier": null,
+    "display_name": "Jamie Rivera",
+    "contact_email": null
+  }
+}
+```
+
+| Field | Required | Notes |
+|---|---|---|
+| `event_id` | **yes** | A string, unique per real-world event, from *your* system (an order ID, a payment intent ID — anything stable). This is the idempotency key — see below. Not a RootNode-generated value. |
+| `source` | no | Free text, e.g. `"website"`. Recorded for audit only, defaults to `"integration"` if omitted. |
+| `program_slug` | **yes** | The RootNode program's id, e.g. `"root-kubernetes-foundations"`. Ask RootNode for the current list — there is no public program-catalog endpoint. |
+| `status` | **yes** | One of: `"paid"`, `"active"`, `"confirmed"` (all mean "grant access now") or `"pending"`, `"awaiting_payment"` (means "record the enrollment but don't grant access yet"). This is a small, fixed, provider-neutral vocabulary — translate whatever your payment provider says into one of these five values before calling. Anything else is rejected. |
+| `student.email` | one of email/login_identifier required | The student's own email, if they have one. |
+| `student.login_identifier` | one of email/login_identifier required | Use this instead of/alongside email for a student who doesn't have their own email address (a minor enrolled by a parent/guardian — see below). Any stable, unique string you control — e.g. an internal user ID from your own system works well. |
+| `student.display_name` | no | Shown in the RootNode instructor portal and, once the student logs in, to themselves. Falls back to the email or login_identifier if omitted. |
+| `student.contact_email` | no | **Only** for a student with no email of their own (§ below) — where to send THIS enrollment's activation/confirmation email (typically a guardian's address collected at checkout). Never treated as the student's own identity/login. |
+
+### What you must NOT send
+
+- No card numbers, CVVs, bank details, or any other payment-card data. This endpoint has no
+  field for it and never will — RootNode never touches payment-card data at all.
+- No raw provider webhook payloads (Stripe event objects, PayPal IPN bodies, etc.) — translate
+  to the shape above first. This endpoint is deliberately provider-neutral.
+- No password. RootNode issues its own credential/activation flow (see "What the student
+  experiences" below) — you cannot set a student's password through this endpoint, and should
+  never try to invent one.
+
+## Response
+
+**Success — a new enrollment was created** (`201`):
+```json
+{ "enrollment_id": "6dd6d898-f895-477f-97d8-1e5ce89c27cd", "student_id": "student-042", "program_id": "root-kubernetes-foundations", "status": "active", "created": true }
+```
+
+**Success — this exact `event_id` was already processed** (`200`, idempotent replay — see below):
+```json
+{ "enrollment_id": "6dd6d898-f895-477f-97d8-1e5ce89c27cd", "student_id": "student-042", "program_id": "root-kubernetes-foundations", "status": "active", "created": false }
+```
+
+**Errors:**
+
+| Status | Body `error` | Meaning |
+|---|---|---|
+| `401` | `unauthorized` | Missing/wrong `X-RootNode-Integration-Key`. |
+| `400` | `event_id is required` | — |
+| `400` | `program_slug is required` | — |
+| `400` | `status must be one of: paid, active, confirmed, pending, awaiting_payment` | — |
+| `400` | `student.email or student.login_identifier is required` | — |
+| `404` | `PROGRAM_NOT_FOUND` | `program_slug` doesn't exist. |
+| `409` | `PROGRAM_INACTIVE` | The program exists but isn't currently open for enrollment. |
+| `500` | `internal_error` | Something unexpected broke server-side. Safe to retry (see below). |
+
+## Idempotency and retries
+
+**`event_id` is the whole mechanism.** Send the exact same `event_id` again (your payment
+provider retried a webhook, your own backend retried a timed-out request, anything) and you get
+back the **same enrollment**, `created: false`, `200` instead of `201` — never a duplicate. This
+is enforced at the database level (a unique constraint), not just "best effort," so it's safe
+under concurrent/parallel retries too, not just sequential ones.
+
+**Retry policy:** on a `5xx` or a network error/timeout, retry with the *same* `event_id`
+(standard exponential backoff is fine — a few attempts over a couple of minutes is plenty). On a
+`4xx`, do not blindly retry — fix the request (see the error table above) or, for `401`, check
+your key.
+
+**Never generate a new `event_id` for a retry of the same real-world event.** Doing so would
+create a second enrollment. Reserve a fresh `event_id` only for a genuinely new enrollment event
+(e.g. a renewal, a second purchase).
+
+## Student matching rules
+
+RootNode looks for an existing student by `email` (case-insensitive) or `login_identifier`
+(exact match), in that priority. If found, that student is enrolled. If not found, a new student
+account is created automatically — this is a trusted server-to-server call from your backend,
+equivalent to an instructor adding a student through the admin portal, not a public signup form.
+
+## Minor / no-email students
+
+RootNode explicitly supports students without their own email address (younger students,
+enrolled by a parent/guardian). Send `student.login_identifier` instead of (or in addition to)
+`email` — any stable string you control, such as an internal account/order reference. You must
+send **at least one** of `email` or `login_identifier`; sending neither is rejected.
+
+If the enrolled student has no email at all, send `student.contact_email` too (e.g. the
+guardian's address collected at checkout) so RootNode has somewhere to deliver the activation
+email — otherwise the enrollment is created but nobody is notified automatically, and an
+instructor has to relay the activation link manually. `contact_email` is stored only against
+that specific enrollment, never copied into the student's own identity record.
+
+There is no guardian/parent account system yet — the enrollment is created directly against the
+student identity you provide. If you need to support "a parent manages multiple children's
+enrollments" as a first-class concept later, talk to the RootNode team before building around a
+workaround; the schema has room for it but it isn't implemented.
+
+## What the student experiences after you call this (as of Phase 5C)
+
+If `status` mapped to "active": RootNode sends the student (or their enrollment's
+`contact_email`) a real email automatically —an activation email with a one-time setup link if
+they're new, or an enrollment confirmation if they already have a RootNode account — and they
+can log in as soon as they act on it. **You do not need to send any email yourself for this** —
+see "Responsibility boundary" above. If `status` mapped to "pending": the enrollment exists but
+the student can't start until a RootNode instructor activates it — useful if your flow needs a
+manual review step before access is granted; no email goes out until activation happens.
+
+If the student has neither an `email` nor a `contact_email` on file, RootNode still creates the
+account and enrollment, but nothing gets emailed automatically — an instructor has to relay the
+activation link by hand. Send whichever address you have whenever you have one.
+
+## Local/staging testing
+
+Set `INTEGRATION_SHARED_SECRET` in your test environment's config (in local dev,
+`platform/.env`; example dev value used by this repo's own test suite:
+`dev-integration-secret-not-for-production` — never use this value anywhere real). Then:
+
+```bash
+curl -s -X POST http://localhost:4200/api/integrations/enrollments \
+  -H 'Content-Type: application/json' \
+  -H 'X-RootNode-Integration-Key: dev-integration-secret-not-for-production' \
+  -d '{
+    "event_id": "test-order-001",
+    "source": "website",
+    "program_slug": "root-kubernetes-foundations",
+    "status": "paid",
+    "student": { "email": "[email protected]", "display_name": "Test Student" }
+  }'
+```
+
+All example data on this page is fake — do not reuse these values against a real deployment.
+
+## Production secret handling
+
+- The production `X-RootNode-Integration-Key` value must be requested from the RootNode team
+  and stored in your backend's secret manager/environment configuration — never in source
+  control, never in a browser-reachable config, never logged.
+- RootNode's own logs and audit trail never record the secret's value, only that an
+  authenticated call happened (or a `401` if it didn't).

frontend/src/admin/AdminPortal.jsx

@@ -9,6 +9,9 @@ import AccountView from './AccountView'
 import LearningView from './LearningView'
 import AssessmentsView from './AssessmentsView'
 import ClassroomView from './ClassroomView'
+import ProgramsView from './ProgramsView'
+import NotificationsView from './NotificationsView'
+import CurriculumView from './CurriculumView'
 import styles from './Admin.module.css'
 
 // Instructor/Admin portal — clearly separate from the student experience (/admin route,
@@ -21,9 +24,12 @@ const NAV = [
   { key: 'dashboard', label: 'Dashboard' },
   { key: 'cohorts', label: 'Cohorts' },
   { key: 'students', label: 'Students' },
+  { key: 'programs', label: 'Programs' },
+  { key: 'curriculum', label: 'Curriculum' },
   { key: 'classroom', label: 'Classroom' },
   { key: 'learning', label: 'Learning' },
   { key: 'assessments', label: 'Assessments' },
+  { key: 'notifications', label: 'Notifications', roles: ['owner', 'admin'] },
   { key: 'instructors', label: 'Instructors', roles: ['owner'] },
   { key: 'audit', label: 'Audit', roles: ['owner', 'admin'] },
 ]
@@ -61,9 +67,12 @@ export default function AdminPortal() {
         {view === 'dashboard' && <AdminDashboard />}
         {view === 'cohorts' && <CohortsView role={instructor.role} />}
         {view === 'students' && <StudentsView role={instructor.role} />}
+        {view === 'programs' && <ProgramsView role={instructor.role} />}
+        {view === 'curriculum' && <CurriculumView />}
         {view === 'classroom' && <ClassroomView />}
         {view === 'learning' && <LearningView />}
         {view === 'assessments' && <AssessmentsView role={instructor.role} />}
+        {view === 'notifications' && ['owner', 'admin'].includes(instructor.role) && <NotificationsView />}
         {view === 'instructors' && instructor.role === 'owner' && <InstructorsView currentInstructorId={instructor.instructor_id} />}
         {view === 'audit' && ['owner', 'admin'].includes(instructor.role) && <AuditView />}
         {view === 'account' && <AccountView instructor={instructor} />}

frontend/src/admin/CurriculumView.jsx

@@ -0,0 +1,149 @@
+import { useState, useEffect, useCallback } from 'react'
+import { adminApi } from './api'
+import styles from './Admin.module.css'
+
+const ACTIVITY_LABELS = {
+  lesson: 'Lesson', demonstration: 'Demonstration', knowledge_check: 'Knowledge Check',
+  guided_exercise: 'Guided Exercise', lab: 'Lab', reflection: 'Reflection',
+  assessment: 'Assessment', capstone: 'Capstone',
+}
+
+function statusPill(status) {
+  const cls = status === 'ready' ? styles.pillOk : status === 'partial' ? styles.pillWarn : styles.pillMuted
+  return <span className={`${styles.pill} ${cls}`}>{status}</span>
+}
+
+// Phase 6A §7 — instructor curriculum visibility: program structure with instructor notes,
+// mapped scenarios/assessments, and estimated teaching time, plus an optional per-student
+// progress lookup so a teacher can see where someone is stuck. Read-only — authoring stays
+// Git/migration-based this phase (docs/COURSE_CONTENT_MODEL.md), so there is no edit form here.
+export default function CurriculumView() {
+  const [programs, setPrograms] = useState(null)
+  const [programId, setProgramId] = useState(null)
+  const [courses, setCourses] = useState(null)
+  const [error, setError] = useState(null)
+  const [studentId, setStudentId] = useState('')
+  const [studentCourses, setStudentCourses] = useState(null)
+  const [studentError, setStudentError] = useState(null)
+  const [openCourse, setOpenCourse] = useState(null)
+  const [openModule, setOpenModule] = useState(null)
+
+  useEffect(() => { adminApi.programs().then((p) => { setPrograms(p); if (p[0]) setProgramId(p[0].program_id) }).catch((e) => setError(e.message)) }, [])
+
+  const loadCourses = useCallback(() => {
+    if (!programId) return
+    adminApi.programCourses(programId).then(setCourses).catch((e) => setError(e.message))
+  }, [programId])
+  useEffect(loadCourses, [loadCourses])
+
+  const lookupStudent = async (e) => {
+    e.preventDefault()
+    setStudentError(null); setStudentCourses(null)
+    try { setStudentCourses(await adminApi.studentCourses(studentId.trim(), programId)) }
+    catch (err) { setStudentError(err.message) }
+  }
+
+  if (error) return <div className={styles.errorBox}>{error}</div>
+  if (!programs) return <p className={styles.muted}>Loading…</p>
+
+  const course = openCourse && courses?.find((c) => c.course_id === openCourse)
+  const mod = course && openModule && course.modules.find((m) => m.module_id === openModule)
+  const progressFor = (activityId) => studentCourses?.flatMap((c) => c.modules).flatMap((m) => m.activities).find((a) => a.activity_id === activityId)
+
+  return (
+    <>
+      <div className={styles.card}>
+        <h2>Curriculum</h2>
+        <select className={styles.input} value={programId || ''} onChange={(e) => { setProgramId(e.target.value); setOpenCourse(null); setOpenModule(null) }}>
+          {programs.map((p) => <option key={p.program_id} value={p.program_id}>{p.name}</option>)}
+        </select>
+
+        <form onSubmit={lookupStudent} style={{ marginTop: '1rem', display: 'flex', gap: '0.5rem' }}>
+          <input className={styles.input} placeholder="student_id — check where they're stuck" value={studentId} onChange={(e) => setStudentId(e.target.value)} />
+          <button className={styles.btnSecondary} disabled={!studentId.trim()}>Look up progress</button>
+        </form>
+        {studentError && <div className={styles.errorBox} style={{ marginTop: '0.5rem' }}>{studentError}</div>}
+      </div>
+
+      {!courses ? <p className={styles.muted}>Loading…</p> : mod ? (
+        <div className={styles.card}>
+          <button className={styles.linkBtn} onClick={() => setOpenModule(null)}>← {course.title}</button>
+          <h3 style={{ marginTop: '0.5rem' }}>{mod.title} {statusPill(mod.status)}</h3>
+          {mod.description && <p className={styles.muted}>{mod.description}</p>}
+          {mod.estimated_duration_minutes && <p className={styles.muted}>Estimated teaching time: ~{mod.estimated_duration_minutes} min</p>}
+          {mod.objectives?.length > 0 && <ul>{mod.objectives.map((o, i) => <li key={i}>{o}</li>)}</ul>}
+          <table>
+            <thead><tr><th>#</th><th>Type</th><th>Title</th><th>Mapped</th><th>Required</th><th>Status</th>{studentCourses && <th>Student</th>}</tr></thead>
+            <tbody>
+              {mod.activities.map((a) => (
+                <tr key={a.activity_id}>
+                  <td className={styles.muted}>{a.sequence}</td>
+                  <td>{ACTIVITY_LABELS[a.activity_type] || a.activity_type}</td>
+                  <td>{a.title}</td>
+                  <td className={styles.muted}>{a.scenario_id || a.assessment_definition_id || '—'}</td>
+                  <td className={styles.muted}>{a.is_required === false ? 'optional' : 'required'}</td>
+                  <td>{statusPill(a.status)}</td>
+                  {studentCourses && (
+                    <td>{progressFor(a.activity_id)?.complete ? <span className={`${styles.pill} ${styles.pillOk}`}>done</span> : <span className={styles.muted}>—</span>}</td>
+                  )}
+                </tr>
+              ))}
+            </tbody>
+          </table>
+          {mod.activities.some((a) => a.instructor_notes) && (
+            <div style={{ marginTop: '1rem' }}>
+              <h3>Instructor notes</h3>
+              {mod.activities.filter((a) => a.instructor_notes).map((a) => (
+                <details key={a.activity_id} style={{ marginBottom: '0.5rem' }}>
+                  <summary style={{ cursor: 'pointer' }}>{a.title}</summary>
+                  <pre style={{ whiteSpace: 'pre-wrap', fontSize: '0.82rem', color: 'var(--text-2)' }}>{a.instructor_notes}</pre>
+                </details>
+              ))}
+            </div>
+          )}
+        </div>
+      ) : course ? (
+        <div className={styles.card}>
+          <button className={styles.linkBtn} onClick={() => setOpenCourse(null)}>← All courses</button>
+          <h3 style={{ marginTop: '0.5rem' }}>{course.title} {statusPill(course.status)}</h3>
+          {course.description && <p className={styles.muted}>{course.description}</p>}
+          {course.estimated_duration_hours && <p className={styles.muted}>Estimated: ~{course.estimated_duration_hours} hours</p>}
+          <table>
+            <thead><tr><th>#</th><th>Module</th><th>Activities</th><th>Est. min</th><th>Status</th></tr></thead>
+            <tbody>
+              {course.modules.length === 0 ? (
+                <tr><td colSpan={5} className={styles.muted}>No modules authored yet.</td></tr>
+              ) : course.modules.map((m) => (
+                <tr key={m.module_id}>
+                  <td className={styles.muted}>{m.sequence}</td>
+                  <td><button className={styles.linkBtn} onClick={() => setOpenModule(m.module_id)}>{m.title}</button></td>
+                  <td className={styles.muted}>{m.activities.length}</td>
+                  <td className={styles.muted}>{m.estimated_duration_minutes || '—'}</td>
+                  <td>{statusPill(m.status)}</td>
+                </tr>
+              ))}
+            </tbody>
+          </table>
+        </div>
+      ) : (
+        <div className={styles.card}>
+          <h3>ROOT_ program structure</h3>
+          <table>
+            <thead><tr><th>#</th><th>Course</th><th>Modules</th><th>Est. hours</th><th>Status</th></tr></thead>
+            <tbody>
+              {courses.map((c) => (
+                <tr key={c.course_id}>
+                  <td className={styles.muted}>{c.sequence}</td>
+                  <td><button className={styles.linkBtn} onClick={() => setOpenCourse(c.course_id)}>{c.title}</button></td>
+                  <td className={styles.muted}>{c.modules.length}</td>
+                  <td className={styles.muted}>{c.estimated_duration_hours || '—'}</td>
+                  <td>{statusPill(c.status)}</td>
+                </tr>
+              ))}
+            </tbody>
+          </table>
+        </div>
+      )}
+    </>
+  )
+}

frontend/src/admin/NotificationsView.jsx

@@ -0,0 +1,52 @@
+import { useState, useEffect } from 'react'
+import { adminApi } from './api'
+import styles from './Admin.module.css'
+
+// Phase 5C §16 — owner/admin only (enforced server-side too; a plain instructor's notification
+// visibility is per-student, on the Students tab, never this global view — see
+// rbac.js's requireStudentRelationshipAccess). No recipient email in full, no token, no
+// metadata — everything here comes from notifications.js's toAdminView.
+export default function NotificationsView() {
+  const [page, setPage] = useState(1)
+  const [result, setResult] = useState(null)
+  const [error, setError] = useState(null)
+
+  useEffect(() => {
+    setResult(null)
+    adminApi.notifications(page).then(setResult).catch((e) => setError(e.message))
+  }, [page])
+
+  const items = result?.items || []
+
+  return (
+    <div className={styles.card}>
+      <h2>Notifications</h2>
+      <p className={styles.muted}>{result ? `${result.total} total` : 'Activation, enrollment, and password-reset emails — most recent first.'}</p>
+      {error && <div className={styles.errorBox}>{error}</div>}
+      {!result ? <p className={styles.muted}>Loading…</p> : (
+        <>
+          <table>
+            <thead><tr><th>When</th><th>Type</th><th>Recipient</th><th>Status</th><th>Attempts</th><th>Error</th></tr></thead>
+            <tbody>
+              {items.map((n) => (
+                <tr key={n.notification_id}>
+                  <td>{new Date(n.created_at).toLocaleString()}</td>
+                  <td>{n.notification_type.replace(/_/g, ' ')}</td>
+                  <td className={styles.muted}>{n.recipient_email_masked || '—'}</td>
+                  <td><span className={`${styles.pill} ${n.status === 'sent' ? styles.pillOk : n.status === 'failed' ? styles.pillErr : styles.pillMuted}`}>{n.status}</span></td>
+                  <td className={styles.muted}>{n.attempt_count}</td>
+                  <td className={styles.muted}>{n.last_error_code || '—'}</td>
+                </tr>
+              ))}
+            </tbody>
+          </table>
+          <div className={styles.pager}>
+            <button disabled={page <= 1} onClick={() => setPage((p) => p - 1)}>Previous</button>
+            <span className={styles.muted}>Page {result.page} of {result.total_pages}</span>
+            <button disabled={page >= result.total_pages} onClick={() => setPage((p) => p + 1)}>Next</button>
+          </div>
+        </>
+      )}
+    </div>
+  )
+}

frontend/src/admin/ProgramsView.jsx

@@ -0,0 +1,216 @@
+import { useState, useEffect, useCallback } from 'react'
+import { adminApi } from './api'
+import styles from './Admin.module.css'
+
+// Phase 5B §11 — Programs area. Authoring (create/edit/activate-deactivate) is admin/owner
+// only, matching AssessmentsView's "viewed by all roles, only authoring restricted" pattern —
+// canAuthor gates the create form and the activate/deactivate toggle only, not the list itself.
+export default function ProgramsView({ role }) {
+  const [programs, setPrograms] = useState(null)
+  const [selected, setSelected] = useState(null)
+  const [error, setError] = useState(null)
+  const canAuthor = role === 'owner' || role === 'admin'
+
+  const reload = useCallback(() => {
+    adminApi.programs().then(setPrograms).catch((e) => setError(e.message))
+  }, [])
+  useEffect(reload, [reload])
+
+  if (selected) return <ProgramDetail programId={selected} canAuthor={canAuthor} onBack={() => { setSelected(null); reload() }} />
+
+  return (
+    <>
+      {error && <div className={styles.errorBox}>{error}</div>}
+      {canAuthor && (
+        <div className={styles.card}>
+          <h2>Create program</h2>
+          <CreateProgramForm onCreated={reload} />
+        </div>
+      )}
+      <div className={styles.card}>
+        <h2>Programs</h2>
+        {!programs ? <p className={styles.muted}>Loading…</p> : (
+          <table>
+            <thead><tr><th>Name</th><th>Family</th><th>Delivery</th><th>Enrollments</th><th>Status</th><th /></tr></thead>
+            <tbody>
+              {programs.map((p) => (
+                <tr key={p.program_id}>
+                  <td>{p.name}</td>
+                  <td><span className={styles.pill}>{p.family}</span></td>
+                  <td className={styles.muted}>{p.delivery_mode.replace('_', ' ')}</td>
+                  <td>{p.enrollment_count}</td>
+                  <td><span className={`${styles.pill} ${p.status === 'active' ? styles.pillOk : styles.pillMuted}`}>{p.status}</span></td>
+                  <td><button className={styles.linkBtn} onClick={() => setSelected(p.program_id)}>Open</button></td>
+                </tr>
+              ))}
+            </tbody>
+          </table>
+        )}
+      </div>
+    </>
+  )
+}
+
+function CreateProgramForm({ onCreated }) {
+  const [form, setForm] = useState({ program_id: '', name: '', family: 'root', delivery_mode: 'self_paced', description: '' })
+  const [busy, setBusy] = useState(false)
+  const [error, setError] = useState(null)
+
+  const submit = async (e) => {
+    e.preventDefault()
+    setBusy(true); setError(null)
+    try {
+      await adminApi.createProgram(form)
+      setForm({ program_id: '', name: '', family: 'root', delivery_mode: 'self_paced', description: '' })
+      onCreated()
+    } catch (e) { setError(e.message) } finally { setBusy(false) }
+  }
+
+  return (
+    <form onSubmit={submit}>
+      {error && <div className={styles.errorBox}>{error}</div>}
+      <div className={styles.formRow}>
+        <div><label className={styles.label}>Program ID (slug)</label>
+          <input className={styles.input} value={form.program_id} onChange={(e) => setForm({ ...form, program_id: e.target.value })} required /></div>
+        <div><label className={styles.label}>Name</label>
+          <input className={styles.input} value={form.name} onChange={(e) => setForm({ ...form, name: e.target.value })} required /></div>
+        <div><label className={styles.label}>Family</label>
+          <select className={styles.select} value={form.family} onChange={(e) => setForm({ ...form, family: e.target.value })}>
+            <option value="init">init_ (ages ~5-10)</option>
+            <option value="compile">compile_ (ages ~11-14)</option>
+            <option value="root">root_ (ages ~15-18+)</option>
+          </select></div>
+        <div><label className={styles.label}>Delivery mode</label>
+          <select className={styles.select} value={form.delivery_mode} onChange={(e) => setForm({ ...form, delivery_mode: e.target.value })}>
+            <option value="self_paced">self-paced</option>
+            <option value="cohort">cohort</option>
+            <option value="hybrid">hybrid</option>
+          </select></div>
+      </div>
+      <label className={styles.label}>Description</label>
+      <input className={styles.input} value={form.description} onChange={(e) => setForm({ ...form, description: e.target.value })} />
+      <p className={styles.muted} style={{ marginTop: '0.5rem' }}>
+        New programs default to curriculum_path 'rootnode-path' — the only curriculum content that exists today. A program for init_/compile_ can be created now and wired to real content later without a schema change.
+      </p>
+      <button className={styles.btn} style={{ marginTop: '0.75rem' }} disabled={busy}>{busy ? 'Creating…' : 'Create'}</button>
+    </form>
+  )
+}
+
+function ProgramDetail({ programId, canAuthor, onBack }) {
+  const [program, setProgram] = useState(null)
+  const [enrollments, setEnrollments] = useState(null)
+  const [error, setError] = useState(null)
+  const [notice, setNotice] = useState(null)
+  const [busy, setBusy] = useState(false)
+
+  const reload = useCallback(() => {
+    adminApi.program(programId).then(setProgram).catch((e) => setError(e.message))
+    adminApi.programEnrollments(programId).then(setEnrollments).catch(() => {})
+  }, [programId])
+  useEffect(reload, [reload])
+
+  const withBusy = (fn) => async () => {
+    setBusy(true); setError(null); setNotice(null)
+    try { await fn(); reload() } catch (e) { setError(e.message) } finally { setBusy(false) }
+  }
+
+  return (
+    <>
+      <button className={styles.linkBtn} onClick={onBack}>&larr; Back to programs</button>
+      {!program ? <p className={styles.muted}>Loading…</p> : (
+        <>
+          <h2 style={{ margin: '1rem 0' }}>{program.name} <span className={`${styles.pill} ${program.status === 'active' ? styles.pillOk : styles.pillMuted}`}>{program.status}</span></h2>
+          {error && <div className={styles.errorBox}>{error}</div>}
+          {notice && <p className={styles.muted}>{notice}</p>}
+          <div className={styles.card}>
+            <h3>Overview</h3>
+            <p className={styles.muted}>{program.description || 'No description.'}</p>
+            <p>Family: <span className={styles.pill}>{program.family}</span> — Delivery: {program.delivery_mode.replace('_', ' ')} — Curriculum: {program.curriculum_path} (v{program.version})</p>
+            <p className={styles.muted}>
+              Enrollments — pending: {program.enrollment_counts.pending || 0}, active: {program.enrollment_counts.active || 0},
+              {' '}completed: {program.enrollment_counts.completed || 0}, cancelled: {program.enrollment_counts.cancelled || 0}, expired: {program.enrollment_counts.expired || 0}
+            </p>
+            {canAuthor && (
+              <button className={styles.btnSecondary} disabled={busy} onClick={withBusy(() => adminApi.updateProgram(programId, { status: program.status === 'active' ? 'inactive' : 'active' }))}>
+                {program.status === 'active' ? 'Deactivate' : 'Activate'} program
+              </button>
+            )}
+          </div>
+
+          {canAuthor && (
+            <div className={styles.card}>
+              <h3>Enroll a student</h3>
+              <EnrollForm programId={programId} onEnrolled={() => { setNotice('Enrolled.'); reload() }} />
+            </div>
+          )}
+
+          <div className={styles.card}>
+            <h3>Enrollments</h3>
+            {!enrollments ? <p className={styles.muted}>Loading…</p> : enrollments.length === 0 ? <p className={styles.muted}>None yet.</p> : (
+              <table>
+                <thead><tr><th>Student</th><th>Status</th><th>Source</th><th>Enrolled</th><th /></tr></thead>
+                <tbody>
+                  {enrollments.map((e) => (
+                    <tr key={e.enrollment_id}>
+                      <td>{e.student_display_name}</td>
+                      <td><span className={`${styles.pill} ${e.status === 'active' ? styles.pillOk : e.status === 'cancelled' ? styles.pillErr : styles.pillMuted}`}>{e.status}</span></td>
+                      <td className={styles.muted}>{e.source}</td>
+                      <td className={styles.muted}>{new Date(e.enrolled_at).toLocaleDateString()}</td>
+                      <td>
+                        {e.status === 'pending' && <button className={styles.linkBtn} onClick={withBusy(() => adminApi.activateEnrollment(e.enrollment_id))}>Activate</button>}
+                        {['pending', 'active'].includes(e.status) && <button className={styles.linkBtn} onClick={withBusy(() => adminApi.cancelEnrollment(e.enrollment_id))}>Cancel</button>}
+                      </td>
+                    </tr>
+                  ))}
+                </tbody>
+              </table>
+            )}
+          </div>
+        </>
+      )}
+    </>
+  )
+}
+
+function EnrollForm({ programId, onEnrolled }) {
+  const [studentId, setStudentId] = useState('')
+  const [status, setStatus] = useState('pending')
+  const [startsAt, setStartsAt] = useState('')
+  const [accessEndsAt, setAccessEndsAt] = useState('')
+  const [busy, setBusy] = useState(false)
+  const [error, setError] = useState(null)
+
+  const submit = async (e) => {
+    e.preventDefault()
+    setBusy(true); setError(null)
+    try {
+      await adminApi.createEnrollment({
+        student_id: studentId.trim(), program_id: programId, status,
+        starts_at: startsAt || undefined, access_ends_at: accessEndsAt || undefined,
+      })
+      setStudentId(''); setStartsAt(''); setAccessEndsAt('')
+      onEnrolled()
+    } catch (e) { setError(e.message) } finally { setBusy(false) }
+  }
+
+  return (
+    <form onSubmit={submit}>
+      {error && <div className={styles.errorBox}>{error}</div>}
+      <div className={styles.formRow}>
+        <div><label className={styles.label}>Student ID</label>
+          <input className={styles.input} value={studentId} onChange={(e) => setStudentId(e.target.value)} placeholder="student-001" required /></div>
+        <div><label className={styles.label}>Initial status</label>
+          <select className={styles.select} value={status} onChange={(e) => setStatus(e.target.value)}>
+            <option value="pending">pending</option>
+            <option value="active">active (skip activation step)</option>
+          </select></div>
+        <div><label className={styles.label}>Starts (optional)</label>
+          <input className={styles.input} type="date" value={startsAt} onChange={(e) => setStartsAt(e.target.value)} /></div>
+        <div><label className={styles.label}>Access ends (optional)</label>
+          <input className={styles.input} type="date" value={accessEndsAt} onChange={(e) => setAccessEndsAt(e.target.value)} /></div>
+      </div>
+      <button className={styles.btn} disabled={busy || !studentId.trim()}>{busy ? 'Enrolling…' : 'Enroll'}</button>
+    </form>
+  )
+}

frontend/src/admin/StudentsView.jsx

@@ -167,6 +167,8 @@ function StudentDetail({ studentId, canManage, onBack }) {
   const [env, setEnv] = useState(null)
   const [events, setEvents] = useState(null)
   const [sessions, setSessions] = useState(null)
+  const [enrollments, setEnrollments] = useState(null)
+  const [notifications, setNotifications] = useState(null)
   const [error, setError] = useState(null)
   const [notice, setNotice] = useState(null)
   const [busy, setBusy] = useState(false)
@@ -180,6 +182,11 @@ function StudentDetail({ studentId, canManage, onBack }) {
     adminApi.studentAttempts(studentId).then((r) => setAttempts(r.items)).catch(() => {})
     adminApi.studentEnvironment(studentId).then((rows) => setEnv(rows?.find((e) => e.status !== 'destroyed') || null)).catch(() => {})
     adminApi.studentSessions(studentId).then(setSessions).catch(() => {})
+    // Phase 5B §11 — scoped server-side the same way as everything else here: a plain
+    // instructor only sees enrollments they created or that share a cohort with them.
+    adminApi.studentEnrollments(studentId).then(setEnrollments).catch(() => {})
+    // Phase 5C §16 — same scoping rule (rbac.js's requireStudentRelationshipAccess).
+    adminApi.studentNotifications(studentId).then(setNotifications).catch(() => {})
   }, [studentId])
   useEffect(reload, [reload])
 
@@ -205,21 +212,47 @@ function StudentDetail({ studentId, canManage, onBack }) {
           <h3>Credentials</h3>
           {student?.has_credentials ? (
             <>
-              <p className={styles.muted}>Logs in with {student.email || student.login_identifier}. {sessions ? `${sessions.length} active session(s).` : ''}</p>
+              <p className={styles.muted}>Logs in with {student.email || student.login_identifier}. {sessions ? `${sessions.length} active session(s).` : ''} An email is sent automatically wherever possible — see Notifications below.</p>
               <div className={styles.formRow}>
                 <button className={styles.btnSecondary} disabled={busy} onClick={withBusy(async () => {
                   const { reset_token } = await adminApi.resetStudentPassword(studentId)
-                  setNotice(`Password reset. Link (shown once): ${window.location.origin}/?reset=${reset_token}`)
-                })}>Reset password</button>
+                  setNotice(`Password reset. Link (shown once, for manual relay if email can't reach them): ${window.location.origin}/?reset=${reset_token}`)
+                })}>Send password reset</button>
                 <button className={styles.btnDanger} disabled={busy || !sessions?.length} onClick={withBusy(() => adminApi.revokeStudentSessions(studentId))}>Revoke all sessions</button>
               </div>
             </>
+          ) : student?.email || student?.login_identifier ? (
+            <>
+              <p className={styles.muted}>Not yet activated. An activation link was queued — use this if the student never got it or it expired.</p>
+              <button className={styles.btnSecondary} disabled={busy} onClick={withBusy(() => adminApi.resendActivation(studentId))}>Resend activation</button>
+            </>
           ) : (
             <ConvertForm studentId={studentId} onDone={(msg) => { setNotice(msg); reload() }} />
           )}
         </div>
       )}
 
+      {canManage && (
+        <div className={styles.card}>
+          <h3>Notifications</h3>
+          {!notifications ? <p className={styles.muted}>Loading…</p> : notifications.length === 0 ? <p className={styles.muted}>None yet.</p> : (
+            <table>
+              <thead><tr><th>When</th><th>Type</th><th>Status</th><th>Attempts</th></tr></thead>
+              <tbody>
+                {notifications.map((n) => (
+                  <tr key={n.notification_id}>
+                    <td>{new Date(n.created_at).toLocaleString()}</td>
+                    <td>{n.notification_type.replace(/_/g, ' ')}</td>
+                    <td><span className={`${styles.pill} ${n.status === 'sent' ? styles.pillOk : n.status === 'failed' ? styles.pillErr : styles.pillMuted}`}>{n.status}</span></td>
+                    <td className={styles.muted}>{n.attempt_count}</td>
+                  </tr>
+                ))}
+              </tbody>
+            </table>
+          )}
+        </div>
+      )}
+
       <div className={styles.card}>
         <h3>Environment</h3>
         {!env ? <p className={styles.muted}>No Lab provisioned.</p> : (
@@ -248,6 +281,26 @@ function StudentDetail({ studentId, canManage, onBack }) {
         )}
       </div>
 
+      <div className={styles.card}>
+        <h3>Enrolled programs</h3>
+        {!enrollments ? <p className={styles.muted}>Loading…</p> : enrollments.length === 0 ? <p className={styles.muted}>No program enrollments.</p> : (
+          <table>
+            <thead><tr><th>Program</th><th>Status</th><th>Delivery</th><th>Progress</th><th>Last activity</th></tr></thead>
+            <tbody>
+              {enrollments.map((e) => (
+                <tr key={e.enrollment_id}>
+                  <td>{e.program_name}</td>
+                  <td><span className={`${styles.pill} ${e.effective_status === 'active' ? styles.pillOk : e.effective_status === 'completed' ? styles.pillOk : styles.pillMuted}`}>{e.effective_status}</span></td>
+                  <td className={styles.muted}>{e.delivery_mode.replace('_', ' ')}</td>
+                  <td className={styles.muted}>{e.progress ? `${e.progress.percent_complete}% — ${e.progress.current_stage || 'capstone'}` : '—'}</td>
+                  <td className={styles.muted}>{e.completed_at ? `Completed ${new Date(e.completed_at).toLocaleDateString()}` : e.activated_at ? new Date(e.activated_at).toLocaleDateString() : '—'}</td>
+                </tr>
+              ))}
+            </tbody>
+          </table>
+        )}
+      </div>
+
       <div className={styles.card}>
         <h3>Curriculum progress</h3>
         {!progress ? <p className={styles.muted}>Loading…</p> : progress.stages.map((s) => (

frontend/src/admin/api.js

@@ -116,4 +116,26 @@ export const adminApi = {
   postClassroomAnnouncement: (id, message) => post(`/api/admin/classroom-sessions/${id}/announcements`, { message }),
   acknowledgeHelpRequest: (id) => post(`/api/admin/help-requests/${id}/acknowledge`),
   resolveHelpRequest: (id, note) => post(`/api/admin/help-requests/${id}/resolve`, { note }),
+
+  // ── Phase 5B §11: programs and enrollment ───────────────────────────────────────────────
+  programs: () => get('/api/admin/programs'),
+  program: (id) => get(`/api/admin/programs/${id}`),
+  createProgram: (fields) => post('/api/admin/programs', fields),
+  updateProgram: (id, fields) => patch(`/api/admin/programs/${id}`, fields),
+  programEnrollments: (id) => get(`/api/admin/programs/${id}/enrollments`),
+  createEnrollment: (fields) => post('/api/admin/enrollments', fields),
+  enrollment: (id) => get(`/api/admin/enrollments/${id}`),
+  activateEnrollment: (id) => post(`/api/admin/enrollments/${id}/activate`),
+  cancelEnrollment: (id) => post(`/api/admin/enrollments/${id}/cancel`),
+  studentEnrollments: (studentId) => get(`/api/admin/students/${studentId}/enrollments`),
+
+  // ── Phase 5C §15/§16: enrollment operations & communications ────────────────────────────
+  notifications: (page = 1) => get(`/api/admin/notifications?page=${page}`),
+  studentNotifications: (studentId) => get(`/api/admin/students/${studentId}/notifications`),
+  resendActivation: (studentId) => post(`/api/admin/students/${studentId}/resend-activation`),
+  sendEnrollmentConfirmation: (studentId, enrollmentId) => post(`/api/admin/students/${studentId}/send-enrollment-confirmation`, enrollmentId ? { enrollment_id: enrollmentId } : undefined),
+
+  // ── Phase 6A §7: course/module/activity curriculum view ──────────────────────────────────
+  programCourses: (programId) => get(`/api/admin/programs/${programId}/courses`),
+  studentCourses: (studentId, programId) => get(`/api/admin/students/${studentId}/courses?program_id=${encodeURIComponent(programId)}`),
 }

frontend/src/platform/CourseView.jsx

@@ -0,0 +1,216 @@
+import { useState, useEffect, useCallback } from 'react'
+import ReactMarkdown from 'react-markdown'
+import remarkGfm from 'remark-gfm'
+import { api } from './api'
+import styles from './Platform.module.css'
+
+const ACTIVITY_LABELS = {
+  lesson: 'Lesson', demonstration: 'Demonstration', knowledge_check: 'Knowledge Check',
+  guided_exercise: 'Guided Exercise', lab: 'Lab', reflection: 'Reflection',
+  assessment: 'Assessment', capstone: 'Capstone',
+}
+
+// Phase 6A §6 — structured course learning, nested inside "My Programs" (not a second portal).
+// Local drill-down state only (course -> module -> activity), same "no router" convention as
+// the rest of the Platform Shell (see PlatformShell.jsx). Separate from PracticeTab — this is
+// the guided course path, Practice stays the free-form scenario list it always was.
+export default function CourseView({ enrollmentId, onLaunchLab, onClose }) {
+  const [data, setData] = useState(null)
+  const [error, setError] = useState(null)
+  const [openCourse, setOpenCourse] = useState(null)
+  const [openModule, setOpenModule] = useState(null)
+  const [openActivity, setOpenActivity] = useState(null)
+
+  const load = useCallback(() => {
+    api.courses(enrollmentId).then(setData).catch((e) => setError(e.message))
+  }, [enrollmentId])
+  useEffect(load, [load])
+
+  if (error) return <div className={styles.errorBox}>{error}</div>
+  if (!data) return <p className={styles.muted}>Loading…</p>
+
+  const course = openCourse && data.courses.find((c) => c.course_id === openCourse)
+  const mod = course && openModule && course.modules.find((m) => m.module_id === openModule)
+  const activity = mod && openActivity && mod.activities.find((a) => a.activity_id === openActivity)
+
+  const crumb = (label, onClick) => <button key={label} className={styles.linkBtn} onClick={onClick}>{label}</button>
+
+  if (activity) {
+    return (
+      <div className={styles.card}>
+        <div className={styles.btnRow} style={{ marginBottom: '1rem', flexWrap: 'wrap' }}>
+          {crumb('← All courses', () => { setOpenCourse(null); setOpenModule(null); setOpenActivity(null) })}
+          {crumb(course.title, () => setOpenActivity(null))}
+        </div>
+        <ActivityDetail activity={activity} onLaunchLab={onLaunchLab} onChange={load} />
+      </div>
+    )
+  }
+
+  if (mod) {
+    return (
+      <div className={styles.card}>
+        <div className={styles.btnRow} style={{ marginBottom: '1rem', flexWrap: 'wrap' }}>
+          {crumb('← All courses', () => { setOpenCourse(null); setOpenModule(null) })}
+          {crumb(course.title, () => setOpenModule(null))}
+        </div>
+        <h2>{mod.title}</h2>
+        {mod.description && <p className={styles.muted}>{mod.description}</p>}
+        <ModuleMeta mod={mod} />
+        <div style={{ marginTop: '1rem' }}>
+          {mod.activities.map((a) => (
+            <ActivityRow key={a.activity_id} activity={a} onOpen={() => setOpenActivity(a.activity_id)} />
+          ))}
+        </div>
+      </div>
+    )
+  }
+
+  if (course) {
+    return (
+      <div className={styles.card}>
+        <div className={styles.btnRow} style={{ marginBottom: '1rem' }}>
+          {crumb('← All courses', () => setOpenCourse(null))}
+        </div>
+        <h2>{course.title}</h2>
+        {course.description && <p className={styles.muted}>{course.description}</p>}
+        {course.objectives?.length > 0 && (
+          <ul style={{ marginTop: '0.5rem' }}>
+            {course.objectives.map((o, i) => <li key={i} className={styles.checklistItem}>{o}</li>)}
+          </ul>
+        )}
+        <div style={{ marginTop: '1rem' }}>
+          {course.modules.length === 0 ? (
+            <p className={styles.muted}>No modules published for this course yet.</p>
+          ) : course.modules.map((m) => (
+            <ModuleRow key={m.module_id} mod={m} onOpen={() => !m.locked && setOpenModule(m.module_id)} />
+          ))}
+        </div>
+      </div>
+    )
+  }
+
+  return (
+    <div className={styles.card}>
+      <div className={styles.btnRow} style={{ marginBottom: '1rem' }}>
+        {onClose && crumb('← Back to program', onClose)}
+      </div>
+      <h2>ROOT_ Courses</h2>
+      {data.resume && (
+        <p className={styles.nextUp}>
+          Resume: {data.courses.find((c) => c.course_id === data.resume.course_id)?.title}
+        </p>
+      )}
+      {data.courses.map((c) => (
+        <CourseRow key={c.course_id} course={c} onOpen={() => !c.locked && setOpenCourse(c.course_id)} />
+      ))}
+    </div>
+  )
+}
+
+function statusPill(status) {
+  const cls = status === 'ready' ? styles.pillOk : status === 'partial' ? styles.pillWarn : styles.pillMuted
+  return <span className={`${styles.pill} ${cls}`}>{status}</span>
+}
+
+function CourseRow({ course, onOpen }) {
+  return (
+    <div style={{ borderTop: '1px solid var(--border)', padding: '0.75rem 0' }}>
+      <div style={{ display: 'flex', justifyContent: 'space-between', alignItems: 'center' }}>
+        <button className={styles.linkBtn} disabled={course.locked} onClick={onOpen} style={{ fontWeight: 600, textAlign: 'left' }}>
+          {course.title}
+        </button>
+        <div style={{ display: 'flex', gap: '0.5rem', alignItems: 'center' }}>
+          {statusPill(course.status)}
+          {course.locked && <span className={`${styles.pill} ${styles.pillMuted}`}>locked</span>}
+        </div>
+      </div>
+      {!course.locked && course.modules.length > 0 && (
+        <div style={{ marginTop: '0.4rem' }}>
+          <div className={styles.progressBarTrack}><div className={styles.progressBarFill} style={{ width: `${course.percent_complete}%` }} /></div>
+        </div>
+      )}
+    </div>
+  )
+}
+
+function ModuleRow({ mod, onOpen }) {
+  return (
+    <div style={{ borderTop: '1px solid var(--border)', padding: '0.6rem 0', display: 'flex', justifyContent: 'space-between', alignItems: 'center' }}>
+      <button className={styles.linkBtn} disabled={mod.locked} onClick={onOpen} style={{ textAlign: 'left' }}>{mod.title}</button>
+      <div style={{ display: 'flex', gap: '0.5rem', alignItems: 'center' }}>
+        {mod.complete ? <span className={`${styles.pill} ${styles.pillOk}`}>complete</span> : statusPill(mod.status)}
+        {mod.locked && <span className={`${styles.pill} ${styles.pillMuted}`}>locked</span>}
+      </div>
+    </div>
+  )
+}
+
+function ModuleMeta({ mod }) {
+  if (!mod.objectives?.length && !mod.estimated_duration_minutes) return null
+  return (
+    <div className={styles.hint} style={{ marginTop: '0.5rem' }}>
+      {mod.estimated_duration_minutes && <div>Estimated time: ~{mod.estimated_duration_minutes} min</div>}
+      {mod.objectives?.length > 0 && (
+        <ul style={{ marginTop: '0.3rem' }}>{mod.objectives.map((o, i) => <li key={i}>{o}</li>)}</ul>
+      )}
+    </div>
+  )
+}
+
+function ActivityRow({ activity, onOpen }) {
+  return (
+    <div style={{ borderTop: '1px solid var(--border)', padding: '0.6rem 0', display: 'flex', justifyContent: 'space-between', alignItems: 'center' }}>
+      <button className={styles.linkBtn} onClick={onOpen} style={{ textAlign: 'left' }}>
+        <span className={styles.stageCount}>{ACTIVITY_LABELS[activity.activity_type] || activity.activity_type}</span>{' — '}{activity.title}
+        {activity.is_required === false && <span className={styles.hint}> (optional)</span>}
+      </button>
+      {activity.complete ? <span className={`${styles.pill} ${styles.pillOk}`}>done</span> : activity.estimated_duration_minutes ? <span className={styles.hint}>~{activity.estimated_duration_minutes} min</span> : null}
+    </div>
+  )
+}
+
+function ActivityDetail({ activity, onLaunchLab, onChange }) {
+  const [busy, setBusy] = useState(false)
+  const [error, setError] = useState(null)
+
+  const markComplete = async () => {
+    setBusy(true); setError(null)
+    try { await api.completeActivity(activity.activity_id); onChange() }
+    catch (e) { setError(e.message) } finally { setBusy(false) }
+  }
+
+  return (
+    <div>
+      <div style={{ display: 'flex', justifyContent: 'space-between', alignItems: 'baseline' }}>
+        <h2>{activity.title}</h2>
+        {activity.complete && <span className={`${styles.pill} ${styles.pillOk}`}>complete</span>}
+      </div>
+      <p className={styles.stageCount}>{ACTIVITY_LABELS[activity.activity_type] || activity.activity_type}
+        {activity.estimated_duration_minutes && ` · ~${activity.estimated_duration_minutes} min`}
+        {activity.is_required === false && ' · optional'}</p>
+
+      {activity.body ? (
+        <div className="md" style={{ marginTop: '1rem' }}>
+          <ReactMarkdown remarkPlugins={[remarkGfm]}>{activity.body}</ReactMarkdown>
+        </div>
+      ) : (
+        <p className={styles.muted} style={{ marginTop: '1rem' }}>No content authored for this activity yet.</p>
+      )}
+
+      {error && <p className={styles.errorBox}>{error}</p>}
+
+      <div style={{ marginTop: '1.5rem' }}>
+        {activity.activity_type === 'lab' && !activity.complete && (
+          <button className={styles.primaryBtn} onClick={() => onLaunchLab?.(activity.scenario_id)}>Launch Lab</button>
+        )}
+        {activity.completion_behavior === 'manual_marker' && !activity.complete && (
+          <button className={styles.primaryBtn} disabled={busy} onClick={markComplete}>{busy ? 'Saving…' : 'Mark Complete'}</button>
+        )}
+        {activity.activity_type === 'capstone' && (
+          <p className={styles.muted}>Continue via the Capstone tab to start or resume this assessment.</p>
+        )}
+      </div>
+    </div>
+  )
+}

frontend/src/platform/ProgramsTab.jsx

@@ -0,0 +1,161 @@
+import { useState, useEffect, useCallback, useRef } from 'react'
+import { api } from './api'
+import styles from './Platform.module.css'
+import CourseView from './CourseView'
+
+const POLL_MS = 2500
+
+const BLOCKED_MESSAGES = {
+  pending_activation: 'Your enrollment is pending — an instructor still needs to activate it.',
+  not_yet_started: 'This program opens on the date below. Check back then.',
+  access_expired: 'Access to this program has ended. Your progress is still here for reference.',
+  cancelled: 'This enrollment was cancelled.',
+}
+
+// Phase 5B §6 — "My Programs." Every enrollment the student holds (GET /api/student/programs
+// already carries real access/progress/next-activity per enrollment — see program-status.js),
+// split into Active and Completed. Continue Learning delegates to the entitlement-gated
+// POST /api/student/programs/:id/launch, which reuses the exact same disposable-Lab sequence
+// the My Learning tab's Launch Lab button does — this is not a second kind of Lab.
+export default function ProgramsTab() {
+  const [programs, setPrograms] = useState(null)
+  const [error, setError] = useState(null)
+
+  const load = useCallback(() => {
+    api.programs().then(setPrograms).catch((e) => setError(e.message))
+  }, [])
+  useEffect(load, [load])
+
+  if (error) return <div className={styles.errorBox}>{error}</div>
+  if (!programs) return <p className={styles.muted}>Loading…</p>
+
+  const active = programs.filter((p) => ['pending', 'active', 'expired'].includes(p.effective_status))
+  const completed = programs.filter((p) => p.effective_status === 'completed')
+  const cancelled = programs.filter((p) => p.effective_status === 'cancelled')
+
+  if (!programs.length) {
+    return (
+      <div className={styles.card}>
+        <h2>My Programs</h2>
+        <p className={styles.muted}>You're not enrolled in any program yet. Talk to your instructor, or check for an enrollment email if you signed up through the website.</p>
+      </div>
+    )
+  }
+
+  return (
+    <div>
+      {active.length > 0 && (
+        <div className={styles.card}>
+          <h2>My Programs</h2>
+          {active.map((p) => <ProgramCard key={p.enrollment_id} program={p} onChange={load} />)}
+        </div>
+      )}
+      {completed.length > 0 && (
+        <div className={styles.card}>
+          <h2>Completed Programs</h2>
+          {completed.map((p) => <ProgramCard key={p.enrollment_id} program={p} onChange={load} />)}
+        </div>
+      )}
+      {cancelled.length > 0 && (
+        <div className={styles.card}>
+          <h2>Other</h2>
+          {cancelled.map((p) => <ProgramCard key={p.enrollment_id} program={p} onChange={load} />)}
+        </div>
+      )}
+    </div>
+  )
+}
+
+function ProgramCard({ program, onChange }) {
+  const [envStatus, setEnvStatus] = useState(null)
+  const [busy, setBusy] = useState(false)
+  const [error, setError] = useState(null)
+  const [showCourses, setShowCourses] = useState(false)
+  const pollRef = useRef(null)
+
+  useEffect(() => () => { if (pollRef.current) clearInterval(pollRef.current) }, [])
+
+  const poll = useCallback(() => {
+    api.environmentStatus().then((s) => {
+      setEnvStatus(s)
+      if (!['requested', 'provisioning', 'resetting'].includes(s.status) && pollRef.current) {
+        clearInterval(pollRef.current); pollRef.current = null
+      }
+    }).catch(() => {})
+  }, [])
+
+  const handleContinue = async () => {
+    setBusy(true); setError(null)
+    try {
+      const result = await api.launchProgram(program.enrollment_id)
+      setEnvStatus(result)
+      if (result.status === 'running' && result.launch_path) { window.location.href = result.launch_path; return }
+      if (['requested', 'provisioning'].includes(result.status) && !pollRef.current) {
+        pollRef.current = setInterval(poll, POLL_MS)
+      }
+    } catch (e) { setError(e.message) } finally { setBusy(false) }
+  }
+
+  const p = program.progress
+  const nextLabel = program.next_activity?.type === 'capstone' ? 'RootNode Capstone' : program.next_activity?.scenario_id
+
+  // Phase 6A §6 — "View Courses" opens the structured course/module/activity tree for this
+  // enrollment, right here inline (My Programs -> ROOT_ -> Course -> Module -> Activity), no
+  // separate portal. "Continue Learning" keeps its original Phase 5B behavior unchanged
+  // (straight to the disposable Lab) — CourseView's own Launch Lab buttons call the exact same
+  // handleContinue, so there is still only one launch path underneath both entry points.
+  if (showCourses) {
+    return (
+      <div style={{ borderTop: '1px solid var(--border)', paddingTop: '1rem', marginTop: '1rem' }}>
+        <CourseView enrollmentId={program.enrollment_id} onLaunchLab={handleContinue} onClose={() => setShowCourses(false)} />
+      </div>
+    )
+  }
+
+  return (
+    <div style={{ borderTop: '1px solid var(--border)', paddingTop: '1rem', marginTop: '1rem' }}>
+      <div style={{ display: 'flex', justifyContent: 'space-between', alignItems: 'baseline' }}>
+        <strong>{program.program_name}</strong>
+        <span className={`${styles.pill} ${program.effective_status === 'completed' ? styles.pillOk : program.effective_status === 'expired' || program.effective_status === 'cancelled' ? styles.pillMuted : styles.pillWarn}`}>
+          {program.effective_status.replace(/_/g, ' ')}
+        </span>
+      </div>
+
+      {p && (
+        <div style={{ margin: '0.6rem 0' }}>
+          <div style={{ display: 'flex', justifyContent: 'space-between', fontSize: '0.85rem', marginBottom: '0.3rem' }}>
+            <span>Progress</span><span className={styles.muted}>{p.percent_complete}%</span>
+          </div>
+          <div className={styles.progressBarTrack}><div className={styles.progressBarFill} style={{ width: `${p.percent_complete}%` }} /></div>
+        </div>
+      )}
+
+      {program.effective_status === 'completed' ? (
+        <>
+          <p className={styles.muted}>Completed {program.completed_at ? new Date(program.completed_at).toLocaleDateString() : ''}.</p>
+          <button className={styles.secondaryBtn} onClick={() => setShowCourses(true)}>View Courses</button>
+        </>
+      ) : program.blocked_reason ? (
+        <p className={styles.muted}>
+          {BLOCKED_MESSAGES[program.blocked_reason] || program.blocked_reason}
+          {program.blocked_reason === 'not_yet_started' && program.starts_at && ` (${new Date(program.starts_at).toLocaleDateString()})`}
+        </p>
+      ) : (
+        <>
+          {nextLabel && <p className={styles.nextUp}>Next: {nextLabel}</p>}
+          {error && <p className={styles.errorBox}>{error}</p>}
+          {envStatus && ['requested', 'provisioning'].includes(envStatus.status) ? (
+            <p className={styles.statusLine}><span className={styles.spinner} /> Starting your lab…</p>
+          ) : (
+            <div className={styles.btnRow}>
+              <button className={styles.primaryBtn} disabled={busy} onClick={handleContinue}>
+                {busy ? 'Starting…' : 'Continue Learning'}
+              </button>
+              <button className={styles.secondaryBtn} onClick={() => setShowCourses(true)}>View Courses</button>
+            </div>
+          )}
+        </>
+      )}
+    </div>
+  )
+}

frontend/src/platform/StudentDashboard.jsx

@@ -8,9 +8,11 @@ import CapstoneTab from './CapstoneTab'
 import AchievementsTab from './AchievementsTab'
 import ClassroomTab from './ClassroomTab'
 import ProfileTab from './ProfileTab'
+import ProgramsTab from './ProgramsTab'
 
 const TABS = [
   { key: 'learning', label: 'My Learning' },
+  { key: 'programs', label: 'My Programs' },
   { key: 'classroom', label: 'Classroom' },
   { key: 'practice', label: 'Practice' },
   { key: 'assessments', label: 'Assessments' },
@@ -45,6 +47,7 @@ export default function StudentDashboard({ student, onLogout }) {
       </nav>
 
       {tab === 'learning' && <MyLearningTab />}
+      {tab === 'programs' && <ProgramsTab />}
       {tab === 'classroom' && <ClassroomTab />}
       {tab === 'practice' && <PracticeTab />}
       {tab === 'assessments' && <AssessmentsTab />}

frontend/src/platform/api.js

@@ -119,4 +119,13 @@ export const api = {
   leaveClassroom: (id) => mutate(`/api/classroom/${id}/leave`),
   classroomHeartbeat: (id) => mutate(`/api/classroom/${id}/heartbeat`),
   requestHelp: (id, category, message) => mutate(`/api/classroom/${id}/help-request`, { category, message }),
+
+  // ── Phase 5B: self-paced programs ────────────────────────────────────────────────────────
+  programs: () => fetch('/api/student/programs').then(json),
+  program: (enrollmentId) => fetch(`/api/student/programs/${enrollmentId}`).then(json),
+  launchProgram: (enrollmentId) => mutate(`/api/student/programs/${enrollmentId}/launch`),
+
+  // ── Phase 6A: course/module/activity content ─────────────────────────────────────────────
+  courses: (enrollmentId) => fetch(`/api/student/programs/${enrollmentId}/courses`).then(json),
+  completeActivity: (activityId) => mutate(`/api/student/activities/${activityId}/complete`),
 }

infra/scripts/drills/run-phase5b-selfpaced-rehearsal.sh

@@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+# Orchestrates the Phase 5B §18 self-paced dress rehearsal: brings up the real dev stack,
+# bootstraps an owner, runs test-phase5b-selfpaced-rehearsal.js, tears down.
+set -euo pipefail
+cd "$(dirname "${BASH_SOURCE[0]}")/../../../platform"
+
+export PROVISIONER_SHARED_SECRET="${PROVISIONER_SHARED_SECRET:-rehearsal-shared-secret-not-for-production}"
+export INTEGRATION_SHARED_SECRET="${INTEGRATION_SHARED_SECRET:-dev-integration-secret-not-for-production}"
+
+docker compose -f docker-compose.dev.yml up -d --build
+
+cleanup() {
+  echo "==> Tearing down"
+  docker ps -aq --filter "name=rootnode-lab-" | xargs -r docker rm -f >/dev/null 2>&1 || true
+  docker network ls --filter "name=rootnode-lab-net-" --format "{{.Name}}" | xargs -r -n1 docker network rm >/dev/null 2>&1 || true
+  docker compose -f docker-compose.dev.yml down >/dev/null 2>&1 || true
+}
+trap cleanup EXIT
+
+echo "==> Waiting for the stack"
+for _ in $(seq 1 60); do
+  curl -sf http://localhost:4300/healthz >/dev/null 2>&1 && curl -sf http://localhost:4200/healthz >/dev/null 2>&1 && break
+  sleep 2
+done
+
+echo "==> Bootstrapping the rehearsal owner"
+( cd api && PLATFORM_DB_URL=postgres://postgres:postgres@localhost:5433/rootnode_platform \
+    node bootstrap-owner.js [email protected] "P5B Rehearsal Owner" 'RehearsalPass!2026' )
+
+echo "==> Running the rehearsal"
+OWNER_EMAIL=[email protected] OWNER_PASSWORD='RehearsalPass!2026' \
+  INTEGRATION_KEY="$INTEGRATION_SHARED_SECRET" \
+  node ../infra/scripts/drills/test-phase5b-selfpaced-rehearsal.js

infra/scripts/drills/run-phase5c-enrollment-activation-drill.sh

@@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+# Orchestrates the Phase 5C §25 enrollment/activation dress rehearsal: brings up the real dev
+# stack, bootstraps an owner, runs test-phase5c-enrollment-activation.js, tears down.
+set -euo pipefail
+cd "$(dirname "${BASH_SOURCE[0]}")/../../../platform"
+
+export PROVISIONER_SHARED_SECRET="${PROVISIONER_SHARED_SECRET:-rehearsal-shared-secret-not-for-production}"
+export INTEGRATION_SHARED_SECRET="${INTEGRATION_SHARED_SECRET:-dev-integration-secret-not-for-production}"
+
+docker compose -f docker-compose.dev.yml up -d --build
+
+cleanup() {
+  echo "==> Tearing down"
+  docker ps -aq --filter "name=rootnode-lab-" | xargs -r docker rm -f >/dev/null 2>&1 || true
+  docker network ls --filter "name=rootnode-lab-net-" --format "{{.Name}}" | xargs -r -n1 docker network rm >/dev/null 2>&1 || true
+  docker compose -f docker-compose.dev.yml down >/dev/null 2>&1 || true
+}
+trap cleanup EXIT
+
+echo "==> Waiting for the stack"
+for _ in $(seq 1 60); do
+  curl -sf http://localhost:4300/healthz >/dev/null 2>&1 && curl -sf http://localhost:4200/healthz >/dev/null 2>&1 && break
+  sleep 2
+done
+
+echo "==> Bootstrapping the rehearsal owner"
+( cd api && PLATFORM_DB_URL=postgres://postgres:postgres@localhost:5433/rootnode_platform \
+    node bootstrap-owner.js [email protected] "P5C Rehearsal Owner" 'RehearsalPass!2026' )
+
+echo "==> Running the rehearsal"
+OWNER_EMAIL=[email protected] OWNER_PASSWORD='RehearsalPass!2026' \
+  INTEGRATION_KEY="$INTEGRATION_SHARED_SECRET" \
+  node ../infra/scripts/drills/test-phase5c-enrollment-activation.js

infra/scripts/drills/run-phase6a-course-rehearsal.sh

@@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+# Orchestrates the Phase 6A §12 gold-standard module dress rehearsal: brings up the real dev
+# stack, bootstraps an owner, runs test-phase6a-course-rehearsal.js (real k3s Lab, real
+# scenario), tears down.
+set -euo pipefail
+cd "$(dirname "${BASH_SOURCE[0]}")/../../../platform"
+
+export PROVISIONER_SHARED_SECRET="${PROVISIONER_SHARED_SECRET:-rehearsal-shared-secret-not-for-production}"
+export INTEGRATION_SHARED_SECRET="${INTEGRATION_SHARED_SECRET:-dev-integration-secret-not-for-production}"
+
+docker compose -f docker-compose.dev.yml up -d --build
+
+cleanup() {
+  echo "==> Tearing down"
+  docker ps -aq --filter "name=rootnode-lab-" | xargs -r docker rm -f >/dev/null 2>&1 || true
+  docker network ls --filter "name=rootnode-lab-net-" --format "{{.Name}}" | xargs -r -n1 docker network rm >/dev/null 2>&1 || true
+  docker compose -f docker-compose.dev.yml down >/dev/null 2>&1 || true
+}
+trap cleanup EXIT
+
+echo "==> Waiting for the stack"
+for _ in $(seq 1 60); do
+  curl -sf http://localhost:4300/healthz >/dev/null 2>&1 && curl -sf http://localhost:4200/healthz >/dev/null 2>&1 && break
+  sleep 2
+done
+
+echo "==> Bootstrapping the rehearsal owner"
+( cd api && PLATFORM_DB_URL=postgres://postgres:postgres@localhost:5433/rootnode_platform \
+    node bootstrap-owner.js [email protected] "P6A Rehearsal Owner" 'RehearsalPass!2026' )
+
+echo "==> Running the rehearsal"
+OWNER_EMAIL=[email protected] OWNER_PASSWORD='RehearsalPass!2026' \
+  node ../infra/scripts/drills/test-phase6a-course-rehearsal.js

infra/scripts/drills/run-phase6b-root-course-rehearsal.sh

@@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+# Orchestrates the Phase 6B §23 ROOT_ curriculum expansion dress rehearsal: brings up the real
+# dev stack, bootstraps an owner, runs test-phase6b-root-course-rehearsal.js (real k3s Lab, real
+# kubectl, real classroom tooling), tears down.
+set -euo pipefail
+cd "$(dirname "${BASH_SOURCE[0]}")/../../../platform"
+
+export PROVISIONER_SHARED_SECRET="${PROVISIONER_SHARED_SECRET:-rehearsal-shared-secret-not-for-production}"
+export INTEGRATION_SHARED_SECRET="${INTEGRATION_SHARED_SECRET:-dev-integration-secret-not-for-production}"
+
+docker compose -f docker-compose.dev.yml up -d --build
+
+cleanup() {
+  echo "==> Tearing down"
+  docker ps -aq --filter "name=rootnode-lab-" | xargs -r docker rm -f >/dev/null 2>&1 || true
+  docker network ls --filter "name=rootnode-lab-net-" --format "{{.Name}}" | xargs -r -n1 docker network rm >/dev/null 2>&1 || true
+  docker compose -f docker-compose.dev.yml down >/dev/null 2>&1 || true
+}
+trap cleanup EXIT
+
+echo "==> Waiting for the stack"
+for _ in $(seq 1 60); do
+  curl -sf http://localhost:4300/healthz >/dev/null 2>&1 && curl -sf http://localhost:4200/healthz >/dev/null 2>&1 && break
+  sleep 2
+done
+
+echo "==> Bootstrapping the rehearsal owner"
+( cd api && PLATFORM_DB_URL=postgres://postgres:postgres@localhost:5433/rootnode_platform \
+    node bootstrap-owner.js [email protected] "P6B Rehearsal Owner" 'RehearsalPass!2026' )
+
+echo "==> Running the rehearsal"
+OWNER_EMAIL=[email protected] OWNER_PASSWORD='RehearsalPass!2026' \
+  node ../infra/scripts/drills/test-phase6b-root-course-rehearsal.js

infra/scripts/drills/test-phase5b-selfpaced-rehearsal.js

@@ -0,0 +1,174 @@
+#!/usr/bin/env node
+// Phase 5B §18 — the self-paced dress rehearsal. One continuous realistic story, not synthetic
+// unit assertions: a student is created, activates, has no program, a simulated website
+// enrollment event enrolls them, they work real curriculum in a real Lab, the Lab is destroyed,
+// they come back later, Continue Learning resumes correctly, a fresh Lab provisions, and they
+// complete enough of the program to prove the completion transition. A second, uninvolved
+// student proves they cannot reach the first student's program or Lab. No framework, matching
+// project convention (see test-fake-cohort-rehearsal.js / test-phase5a-rehearsal.js).
+//
+// Run via run-phase5b-selfpaced-rehearsal.sh, which brings up platform/docker-compose.dev.yml
+// first.
+
+const assert = require('assert');
+const { makeSession } = require('../../../platform/test/session-helper');
+
+const GW = process.env.GATEWAY_URL || 'http://localhost:4200';
+const OWNER_EMAIL = process.env.OWNER_EMAIL;
+const OWNER_PASSWORD = process.env.OWNER_PASSWORD;
+const INTEGRATION_KEY = process.env.INTEGRATION_KEY || 'dev-integration-secret-not-for-production';
+if (!OWNER_EMAIL || !OWNER_PASSWORD) { console.error('Set OWNER_EMAIL and OWNER_PASSWORD'); process.exit(1); }
+const RUN_ID = Date.now();
+const PROGRAM = 'root-kubernetes-foundations';
+
+// Just enough of the real Foundation stage to prove stage-completion + capstone unlock without
+// re-driving the entire curriculum a second time (e2e-phase5b.js already does that
+// exhaustively) — this rehearsal seeds the REST of the curriculum's completion directly in
+// Postgres (a real, documented technique — see test-phase5a-rehearsal.js's seedHistory) so the
+// story can reach "program completed" without spending another 40+ real scenario round trips.
+const FOUNDATION_FIRST = 'pod-basics-mcq';
+
+let passed = 0, failed = 0;
+async function step(name, fn) {
+  try { await fn(); console.log(`  ok — ${name}`); passed++; }
+  catch (e) { console.error(`  FAIL — ${name}\n    ${e.stack || e.message}`); failed++; }
+}
+function fireIntegrationEvent(payload) {
+  return fetch(`${GW}/api/integrations/enrollments`, {
+    method: 'POST', headers: { 'Content-Type': 'application/json', 'X-RootNode-Integration-Key': INTEGRATION_KEY },
+    body: JSON.stringify(payload),
+  }).then(async (r) => ({ status: r.status, body: await r.json() }));
+}
+
+async function main() {
+  console.log('Phase 5B self-paced dress rehearsal — slow, real k3s boots\n');
+
+  const owner = makeSession(GW);
+  await owner.request('POST', '/api/auth/instructor/login', { email: OWNER_EMAIL, password: OWNER_PASSWORD });
+
+  const { body: created } = await owner.request('POST', '/api/admin/students', {
+    display_name: 'Rehearsal Self-Paced Student', login_identifier: `p5b-selfpaced-${RUN_ID}`,
+  });
+  const session = makeSession(GW);
+  let enrollmentId, envId;
+
+  await step('student activates credentials and logs in', async () => {
+    const { status } = await session.request('POST', '/api/student/activate', { token: created.activation_token, password: 'RehearsalPass123!' });
+    assert.equal(status, 200);
+  });
+
+  await step('student initially has no program', async () => {
+    const { body } = await session.request('GET', '/api/student/programs');
+    assert.equal(body.length, 0);
+  });
+
+  await step('a simulated website enrollment event enrolls the student (server-to-server, not a browser session)', async () => {
+    const { status, body } = await fireIntegrationEvent({
+      event_id: `p5b-rehearsal-${RUN_ID}`, source: 'website', program_slug: PROGRAM, status: 'paid',
+      student: { login_identifier: `p5b-selfpaced-${RUN_ID}`, display_name: 'Rehearsal Self-Paced Student' },
+    });
+    assert.equal(status, 201);
+    assert.equal(body.status, 'active');
+    enrollmentId = body.enrollment_id;
+  });
+
+  await step('the self-paced root program now appears on the student\'s dashboard, ready to go', async () => {
+    const { body } = await session.request('GET', '/api/student/programs');
+    assert.equal(body.length, 1);
+    assert.equal(body[0].can_launch, true);
+    assert.equal(body[0].next_activity.scenario_id, FOUNDATION_FIRST);
+  });
+
+  await step('student launches a REAL Lab and completes the first real scenario', async () => {
+    const { status, body } = await session.request('POST', `/api/student/programs/${enrollmentId}/launch`);
+    assert.equal(status, 200);
+    assert.equal(body.status, 'running');
+    const envRow = (await owner.request('GET', `/api/admin/students/${created.student_id}/environment`)).body.find((e) => e.status === 'running');
+    envId = envRow.environment_id;
+    const complete = await session.request('POST', '/api/progress/record', { scenario_id: FOUNDATION_FIRST, status: 'completed', environment_id: envId });
+    assert.equal(complete.status, 200);
+  });
+
+  await step('the Lab is destroyed (student closed the tab, session ended — the disposable-by-design lifecycle)', async () => {
+    await owner.request('DELETE', `/api/admin/environments/${envId}`);
+  });
+
+  await step('student logs out', async () => {
+    await session.request('POST', '/api/logout');
+  });
+
+  const returningSession = makeSession(GW);
+  await step('time passes — student logs back in on a new session', async () => {
+    const { status } = await returningSession.request('POST', '/api/student/login', { identifier: `p5b-selfpaced-${RUN_ID}`, password: 'RehearsalPass123!' });
+    assert.equal(status, 200);
+  });
+
+  await step('Continue Learning points to the correct next activity, unchanged by the Lab being gone', async () => {
+    const { body } = await returningSession.request('GET', `/api/student/programs/${enrollmentId}`);
+    assert.notEqual(body.next_activity.scenario_id, FOUNDATION_FIRST); // moved past it
+    assert.ok(body.progress.percent_complete > 0);
+  });
+
+  await step('a new Lab provisions and prior progress is intact under it', async () => {
+    const { status, body } = await returningSession.request('POST', `/api/student/programs/${enrollmentId}/launch`);
+    assert.equal(status, 200);
+    assert.equal(body.status, 'running');
+    const envRow = (await owner.request('GET', `/api/admin/students/${created.student_id}/environment`)).body.find((e) => e.status === 'running');
+    envId = envRow.environment_id;
+  });
+
+  await step('seed the rest of curriculum completion directly (realistic bulk backfill, not re-driving 40+ real requests — see file header)', async () => {
+    const client = `docker compose -f docker-compose.dev.yml exec -T postgres psql -U postgres -d rootnode_platform -c`;
+    const { execSync } = require('child_process');
+    const rest = ['kubectl-essentials-mcq', 'labels-selectors-mcq', 'init-containers-mcq', 'namespaces-basics', 'multi-container-pod-basics',
+      'pod-labeling-basics', 'jsonpath-basics', 'dry-run-manifest-basics', 'delete-by-label-basics', 'annotate-resource-basics',
+      'init-container-task-basics', 'restart-policy-mcq', 'kubectl-output-format-mcq', 'kubectl-explain-basics', 'kubectl-patch-basics',
+      'field-selector-basics', 'sort-by-basics', 'kubectl-diff-basics', 'static-pods-mcq',
+      'deploy-nginx', 'scale-deployment', 'rolling-update-task', 'liveness-probe-task', 'jobs-cronjobs-mcq', 'daemonset-mcq', 'edit-deployment-basics', 'deployment-strategy-mcq',
+      'services-mcq', 'expose-service-basics',
+      'configmap-volume', 'resource-limits-task', 'env-vars-configmap', 'secrets-basics', 'pod-env-vars-inline',
+      'extract-logs-basics', 'kubectl-cp-basics', 'exec-command-basics', 'node-cordon-basics', 'pod-node-assignment-mcq'];
+    const values = rest.map((sid) => `('${created.student_id}','${sid}','completed',1,now(),now())`).join(',');
+    execSync(`${client} "INSERT INTO progress (student_id, scenario_id, status, attempts, completed_at, started_at) VALUES ${values} ON CONFLICT (student_id, scenario_id) DO UPDATE SET status='completed'"`, { cwd: `${__dirname}/../../../platform` });
+  });
+
+  await step('student completes the RootNode Capstone for real (the actual server-authoritative draw + validation)', async () => {
+    const start = await returningSession.request('POST', '/api/assessments/rootnode-capstone/start');
+    assert.equal(start.status, 201);
+    for (const s of start.body.scenarios) {
+      const r = await returningSession.request('POST', '/api/progress/record', { scenario_id: s.scenario_id, status: 'completed', environment_id: envId });
+      assert.equal(r.status, 200);
+    }
+  });
+
+  await step('the program moves to Completed — server-derived, no client "mark complete" action', async () => {
+    const { body } = await returningSession.request('GET', `/api/student/programs/${enrollmentId}`);
+    assert.equal(body.status, 'completed');
+    assert.ok(body.completed_at);
+  });
+
+  await step('the admin portal shows a durable completion record for this student', async () => {
+    const { body } = await owner.request('GET', `/api/admin/students/${created.student_id}/enrollments`);
+    const view = body.find((e) => e.enrollment_id === enrollmentId);
+    assert.equal(view.status, 'completed');
+  });
+
+  // ── A second, uninvolved student — proves entitlement is real, not just "logged in" ──────
+  const { body: otherCreate } = await owner.request('POST', '/api/admin/students', { display_name: 'Rehearsal Outsider', login_identifier: `p5b-outsider-${RUN_ID}` });
+  const outsider = makeSession(GW);
+  await outsider.request('POST', '/api/student/activate', { token: otherCreate.activation_token, password: 'OutsiderPass123!' });
+
+  await step('an uninvolved student cannot reach the first student\'s program or Lab path', async () => {
+    const read = await outsider.request('GET', `/api/student/programs/${enrollmentId}`);
+    assert.equal(read.status, 404);
+    const launch = await outsider.request('POST', `/api/student/programs/${enrollmentId}/launch`);
+    assert.equal(launch.status, 404);
+    const list = await outsider.request('GET', '/api/student/programs');
+    assert.equal(list.body.length, 0);
+  });
+
+  console.log(`\n${passed} passed, ${failed} failed`);
+  if (failed > 0) process.exit(1);
+}
+
+main().catch((e) => { console.error(e); process.exit(1); });

infra/scripts/drills/test-phase5c-enrollment-activation.js

@@ -0,0 +1,165 @@
+#!/usr/bin/env node
+// Phase 5C §25 — the enrollment/activation dress rehearsal. One continuous realistic story: a
+// simulated website enrollment event creates a brand-new student, the activation notification
+// is queued and delivered through the (deterministic, never-real-network) dev email provider,
+// the rendered email is inspected and its activation URL extracted exactly the way a real
+// inbox/click would work, the student sets their password, logs in, sees their program, uses
+// Continue Learning to launch a REAL Lab, completes one real scenario, and an admin can see
+// both the enrollment and its delivery state. Then a second enrollment for the SAME
+// (now-activated) student proves it gets an enrollment confirmation, not another activation.
+// Then a full password-reset round trip, including session revocation. Then the minor/no-email
+// contact-email path. No framework, matching project convention (see
+// test-phase5b-selfpaced-rehearsal.js).
+//
+// Run via run-phase5c-enrollment-activation-drill.sh, which brings up
+// platform/docker-compose.dev.yml first.
+
+const assert = require('assert');
+const { makeSession } = require('../../../platform/test/session-helper');
+
+const GW = process.env.GATEWAY_URL || 'http://localhost:4200';
+const OWNER_EMAIL = process.env.OWNER_EMAIL;
+const OWNER_PASSWORD = process.env.OWNER_PASSWORD;
+const INTEGRATION_KEY = process.env.INTEGRATION_KEY || 'dev-integration-secret-not-for-production';
+if (!OWNER_EMAIL || !OWNER_PASSWORD) { console.error('Set OWNER_EMAIL and OWNER_PASSWORD'); process.exit(1); }
+const RUN_ID = Date.now();
+const PROGRAM = 'root-kubernetes-foundations';
+
+let passed = 0, failed = 0;
+async function step(name, fn) {
+  try { await fn(); console.log(`  ok — ${name}`); passed++; }
+  catch (e) { console.error(`  FAIL — ${name}\n    ${e.stack || e.message}`); failed++; }
+}
+function fireIntegrationEvent(payload) {
+  return fetch(`${GW}/api/integrations/enrollments`, {
+    method: 'POST', headers: { 'Content-Type': 'application/json', 'X-RootNode-Integration-Key': INTEGRATION_KEY },
+    body: JSON.stringify(payload),
+  }).then(async (r) => ({ status: r.status, body: await r.json() }));
+}
+async function waitForSent(owner, studentId, notificationId, timeoutMs = 10000) {
+  const start = Date.now();
+  while (Date.now() - start < timeoutMs) {
+    const { body } = await owner.request('GET', `/api/admin/students/${studentId}/notifications`);
+    const row = notificationId ? body.find((n) => n.notification_id === notificationId) : body[0];
+    if (row?.status === 'sent') return row;
+    if (row?.status === 'failed') throw new Error(`notification failed: ${row.last_error_code}`);
+    await new Promise((r) => setTimeout(r, 500));
+  }
+  throw new Error('timed out waiting for delivery');
+}
+
+async function main() {
+  console.log('Phase 5C enrollment/activation dress rehearsal — slow, real k3s boots\n');
+
+  const owner = makeSession(GW);
+  await owner.request('POST', '/api/auth/instructor/login', { email: OWNER_EMAIL, password: OWNER_PASSWORD });
+
+  let studentId, enrollmentId;
+  await step('website enrollment event creates a brand-new student + self-paced enrollment', async () => {
+    const { status, body } = await fireIntegrationEvent({
+      event_id: `p5c-rehearsal-${RUN_ID}`, source: 'website', program_slug: PROGRAM, status: 'paid',
+      student: { email: `p5c-rehearsal-${RUN_ID}@example.com`, display_name: 'Rehearsal Student' },
+    });
+    assert.equal(status, 201);
+    studentId = body.student_id; enrollmentId = body.enrollment_id;
+  });
+
+  let activationUrl;
+  await step('an activation notification is queued and delivered through the dev provider', async () => {
+    const sent = await waitForSent(owner, studentId, null);
+    assert.equal(sent.notification_type, 'activation');
+    const { body: preview } = await owner.request('GET', `/api/admin/notifications/${sent.notification_id}/dev-preview`);
+    assert.equal(preview.to, `p5c-rehearsal-${RUN_ID}@example.com`);
+    assert.ok(preview.subject.includes('Activate'));
+    const match = preview.text.match(/(http:\/\/\S+\/\?activate=[A-Za-z0-9_-]+)/);
+    assert.ok(match, 'expected a real activation URL in the rendered email body');
+    activationUrl = match[1];
+  });
+
+  const student = makeSession(GW);
+  await step('student "clicks" the extracted URL and sets a password', async () => {
+    const token = new URL(activationUrl).searchParams.get('activate');
+    const { status } = await student.request('POST', '/api/student/activate', { token, password: 'RehearsalPass123!' });
+    assert.equal(status, 200);
+  });
+
+  let launchEnrollmentId, envId;
+  await step('student sees the Root program and Continue Learning works', async () => {
+    const { body: programs } = await student.request('GET', '/api/student/programs');
+    assert.equal(programs.length, 1);
+    assert.equal(programs[0].can_launch, true);
+    launchEnrollmentId = programs[0].enrollment_id;
+    assert.equal(launchEnrollmentId, enrollmentId);
+  });
+
+  await step('launches a REAL Lab and completes one real scenario', async () => {
+    const { status, body } = await student.request('POST', `/api/student/programs/${launchEnrollmentId}/launch`);
+    assert.equal(status, 200);
+    assert.equal(body.status, 'running');
+    const envRow = (await owner.request('GET', `/api/admin/students/${studentId}/environment`)).body.find((e) => e.status === 'running');
+    envId = envRow.environment_id;
+    const complete = await student.request('POST', '/api/progress/record', { scenario_id: 'pod-basics-mcq', status: 'completed', environment_id: envId });
+    assert.equal(complete.status, 200);
+  });
+
+  await step('progress persists and the admin sees both the enrollment and its delivery state', async () => {
+    const { body } = await student.request('GET', `/api/student/programs/${launchEnrollmentId}`);
+    assert.ok(body.progress.percent_complete > 0);
+    const { body: adminEnrollments } = await owner.request('GET', `/api/admin/students/${studentId}/enrollments`);
+    assert.equal(adminEnrollments[0].status, 'active');
+    const { body: adminNotifs } = await owner.request('GET', `/api/admin/students/${studentId}/notifications`);
+    assert.ok(adminNotifs.every((n) => n.status === 'sent'));
+  });
+
+  // ── A second enrollment for the SAME, now-activated student -> confirmation, not activation ──
+  await step('admin creates a second program and enrolls the SAME student — enrollment confirmation, not another activation', async () => {
+    await owner.request('POST', '/api/admin/programs', { program_id: `p5c-rehearsal-second-${RUN_ID}`, name: 'Second Rehearsal Program', family: 'root' });
+    const { status, body } = await owner.request('POST', '/api/admin/enrollments', { student_id: studentId, program_id: `p5c-rehearsal-second-${RUN_ID}`, status: 'active' });
+    assert.equal(status, 201);
+    const sent = await waitForSent(owner, studentId, null);
+    const { body: notifs } = await owner.request('GET', `/api/admin/students/${studentId}/notifications`);
+    const confirmation = notifs.find((n) => n.enrollment_id === body.enrollment_id);
+    assert.equal(confirmation.notification_type, 'enrollment_confirmation');
+  });
+
+  // ── Password reset round trip ─────────────────────────────────────────────────────────────
+  let resetToken;
+  await step('password reset is requested, delivered, and the old session is revoked once used', async () => {
+    const res = await makeSession(GW).request('POST', '/api/student/request-password-reset', { identifier: `p5c-rehearsal-${RUN_ID}@example.com` });
+    resetToken = res.body.dev_reset_token;
+    assert.ok(resetToken);
+    await waitForSent(owner, studentId, null);
+    const before = await student.request('GET', '/api/student/profile');
+    assert.equal(before.status, 200);
+    const resetRes = await makeSession(GW).request('POST', '/api/student/reset-password', { token: resetToken, password: 'RehearsalReset123!' });
+    assert.equal(resetRes.status, 200);
+    const after = await student.request('GET', '/api/student/profile');
+    assert.notEqual(after.status, 200); // the OLD session is revoked
+  });
+
+  await step('the new password works', async () => {
+    const s = makeSession(GW);
+    const { status } = await s.request('POST', '/api/student/login', { identifier: `p5c-rehearsal-${RUN_ID}@example.com`, password: 'RehearsalReset123!' });
+    assert.equal(status, 200);
+  });
+
+  // ── Minor / no-email path ────────────────────────────────────────────────────────────────
+  await step('minor/no-email student: guardian contact_email receives the activation, never stored as students.email', async () => {
+    const { status, body } = await fireIntegrationEvent({
+      event_id: `p5c-rehearsal-minor-${RUN_ID}`, source: 'website', program_slug: PROGRAM, status: 'paid',
+      student: { login_identifier: `p5c-rehearsal-minor-${RUN_ID}`, display_name: 'Rehearsal Minor', contact_email: `p5c-rehearsal-guardian-${RUN_ID}@example.com` },
+    });
+    assert.equal(status, 201);
+    const sent = await waitForSent(owner, body.student_id, null);
+    const { body: preview } = await owner.request('GET', `/api/admin/notifications/${sent.notification_id}/dev-preview`);
+    assert.equal(preview.to, `p5c-rehearsal-guardian-${RUN_ID}@example.com`);
+    const { body: students } = await owner.request('GET', '/api/admin/students');
+    const minorRow = students.find((s) => s.student_id === body.student_id);
+    assert.equal(minorRow.email, null);
+  });
+
+  console.log(`\n${passed} passed, ${failed} failed`);
+  if (failed > 0) process.exit(1);
+}
+
+main().catch((e) => { console.error(e); process.exit(1); });

infra/scripts/drills/test-phase6a-course-rehearsal.js

@@ -0,0 +1,169 @@
+#!/usr/bin/env node
+// Phase 6A §12 — the gold-standard module dress rehearsal. One continuous realistic story, not
+// synthetic unit assertions: a self-paced student enrolls, opens the ROOT_ course tree, reads
+// the health-probes lesson, works through the demonstration/knowledge-check/guided-exercise,
+// launches a REAL Lab, solves the REAL rootnode-probe-port-mismatch scenario against a real k3s
+// environment (no mocked KubeKosh), returns to the module, sees it complete, and the next
+// module unlocks. Same conventions as test-phase5b-selfpaced-rehearsal.js (assert-based, no
+// framework, real k3s boots).
+//
+// Run via run-phase6a-course-rehearsal.sh, which brings up platform/docker-compose.dev.yml
+// first.
+
+const assert = require('assert');
+const { makeSession } = require('../../../platform/test/session-helper');
+
+const GW = process.env.GATEWAY_URL || 'http://localhost:4200';
+const OWNER_EMAIL = process.env.OWNER_EMAIL;
+const OWNER_PASSWORD = process.env.OWNER_PASSWORD;
+if (!OWNER_EMAIL || !OWNER_PASSWORD) { console.error('Set OWNER_EMAIL and OWNER_PASSWORD'); process.exit(1); }
+const RUN_ID = Date.now();
+const PROGRAM = 'root-kubernetes-foundations';
+const GOLD_MODULE = 'root-10-m01-health-probes-and-troubleshooting';
+
+let passed = 0, failed = 0;
+async function step(name, fn) {
+  try { await fn(); console.log(`  ok — ${name}`); passed++; }
+  catch (e) { console.error(`  FAIL — ${name}\n    ${e.stack || e.message}`); failed++; }
+}
+function moduleFrom(tree, id) { for (const c of tree) { const m = c.modules.find((x) => x.module_id === id); if (m) return m; } return null; }
+
+async function main() {
+  console.log('Phase 6A gold-standard module dress rehearsal — slow, real k3s boots\n');
+
+  const owner = makeSession(GW);
+  await owner.request('POST', '/api/auth/instructor/login', { email: OWNER_EMAIL, password: OWNER_PASSWORD });
+
+  const { body: created } = await owner.request('POST', '/api/admin/students', {
+    display_name: 'Rehearsal Course Student', login_identifier: `p6a-course-${RUN_ID}`,
+  });
+  const session = makeSession(GW);
+  let enrollmentId, envId, labToken;
+
+  await step('student activates credentials and logs in', async () => {
+    const { status } = await session.request('POST', '/api/student/activate', { token: created.activation_token, password: 'RehearsalPass123!' });
+    assert.equal(status, 200);
+  });
+
+  await step('an instructor enrolls the student directly in ROOT_ (admin-created, matching Phase 5B\'s manual-enrollment path)', async () => {
+    const { status, body } = await owner.request('POST', '/api/admin/enrollments', { student_id: created.student_id, program_id: PROGRAM, status: 'active' });
+    assert.equal(status, 201);
+    enrollmentId = body.enrollment_id;
+  });
+
+  let tree;
+  await step('the student opens My Programs -> ROOT_ and sees the course tree, gold module locked behind root-05', async () => {
+    const { status, body } = await session.request('GET', `/api/student/programs/${enrollmentId}/courses`);
+    assert.equal(status, 200);
+    tree = body.courses;
+    const goldModule = moduleFrom(tree, GOLD_MODULE);
+    assert.equal(goldModule.locked, true, 'the gold module requires root-05 first, exactly like a real learner would hit');
+  });
+
+  // Real Foundation completion, same scenarios e2e-phase6a.js drives, via the real self-paced
+  // Lab (not seeded directly) — this rehearsal is specifically about proving the REAL path.
+  const FOUNDATION = ['pod-basics-mcq', 'kubectl-essentials-mcq', 'labels-selectors-mcq', 'init-containers-mcq', 'namespaces-basics',
+    'multi-container-pod-basics', 'pod-labeling-basics', 'jsonpath-basics', 'dry-run-manifest-basics', 'delete-by-label-basics',
+    'annotate-resource-basics', 'init-container-task-basics', 'restart-policy-mcq', 'kubectl-output-format-mcq',
+    'kubectl-explain-basics', 'kubectl-patch-basics', 'field-selector-basics', 'sort-by-basics', 'kubectl-diff-basics', 'static-pods-mcq'];
+
+  await step('student launches a REAL Lab and completes root-05\'s real scenarios to unlock the gold module', async () => {
+    const launch = await session.request('POST', `/api/student/programs/${enrollmentId}/launch`);
+    assert.equal(launch.status, 200);
+    assert.equal(launch.body.status, 'running');
+    labToken = launch.body.launch_path.match(/\/lab\/([^/]+)\//)[1]; // needed to reach the real Lab's own setup endpoint below
+    const envRow = (await owner.request('GET', `/api/admin/students/${created.student_id}/environment`)).body.find((e) => e.status === 'running');
+    envId = envRow.environment_id;
+    for (const sid of FOUNDATION) {
+      const r = await session.request('POST', '/api/progress/record', { scenario_id: sid, status: 'completed', environment_id: envId });
+      assert.equal(r.status, 200, `completing ${sid} should 200`);
+    }
+  });
+
+  await step('the gold module is now unlocked', async () => {
+    const { body } = await session.request('GET', `/api/student/programs/${enrollmentId}/courses`);
+    const goldModule = moduleFrom(body.courses, GOLD_MODULE);
+    assert.equal(goldModule.locked, false);
+    assert.equal(goldModule.activities[0].activity_type, 'lesson');
+    assert.ok(goldModule.activities[0].body.includes('liveness'), 'the real lesson content must actually be served');
+  });
+
+  await step('student reads the lesson, demonstration, knowledge check, and guided exercise, marking each complete', async () => {
+    for (const suffix of ['a01-lesson-health-check-concepts', 'a02-demonstration-probes-in-action', 'a03-knowledge-check', 'a04-guided-exercise-readiness-probe']) {
+      const { status } = await session.request('POST', `/api/student/activities/root-10-m01-${suffix}/complete`);
+      assert.equal(status, 200);
+    }
+  });
+
+  await step('student launches the Lab activity for real and lands on rootnode-probe-port-mismatch', async () => {
+    const { body } = await session.request('GET', `/api/student/programs/${enrollmentId}/courses`);
+    const goldModule = moduleFrom(body.courses, GOLD_MODULE);
+    const lab = goldModule.activities.find((a) => a.activity_type === 'lab');
+    assert.equal(lab.scenario_id, 'rootnode-probe-port-mismatch');
+    assert.equal(lab.complete, false, 'not solved yet — this is the real incident, not pre-completed');
+  });
+
+  await step('the Lab UI\'s own setup_commands actually stand up the broken api-gateway deployment', async () => {
+    // Same route the real Lab frontend calls when a student opens this scenario — proxied
+    // through the Gateway's /lab/:token/* passthrough straight to the Lab image's own backend
+    // (backend/server.js), which is what actually runs setup_commands. Nothing about this is
+    // simulated: this is the real mechanism, called the same way the browser would.
+    const { status } = await session.request('POST', `/lab/${labToken}/api/scenarios/rootnode-probe-port-mismatch/setup`);
+    assert.equal(status, 200);
+  });
+
+  await step('student solves the REAL rootnode-probe-port-mismatch incident against the live k3s environment', async () => {
+    // Real diagnosis, matching the scenario's own hints (scenarios/data/rootnode-probe-port-mismatch.json):
+    // the readiness probe was patched onto port 8080; nginx listens on 80. This patches the
+    // actual live Deployment inside the student's real disposable Lab, then records the real
+    // scenario completion the same way the Lab UI's own validation flow does.
+    const { execSync } = require('child_process');
+    // The container's real name is a SHORTENED id (lifecycle.js's shortId(), not the full
+    // environment_id) — reading it straight from Postgres avoids duplicating that derivation
+    // (and silently breaking if it ever changes) the way relying on our own copy would.
+    const containerName = execSync(
+      `docker compose -f docker-compose.dev.yml exec -T postgres psql -U postgres -d rootnode_platform -t -c "SELECT container_name FROM environments WHERE environment_id = '${envId}'"`,
+      { cwd: `${__dirname}/../../../platform`, stdio: 'pipe' }
+    ).toString().trim();
+    assert.ok(containerName, 'the environment must have a real container_name recorded');
+    execSync(
+      `docker exec ${containerName} kubectl patch deployment api-gateway --type='json' -p='[{"op":"replace","path":"/spec/template/spec/containers/0/readinessProbe/httpGet/port","value":80}]'`,
+      { stdio: 'pipe' }
+    );
+    // Give the rollout a moment to actually reach Ready before validating — the same real-world
+    // timing a student would wait through.
+    await new Promise((r) => setTimeout(r, 6000));
+    const r = await session.request('POST', '/api/progress/record', { scenario_id: 'rootnode-probe-port-mismatch', status: 'completed', environment_id: envId });
+    assert.equal(r.status, 200);
+  });
+
+  await step('the lab activity is now complete, but the module waits on the reflection', async () => {
+    const { body } = await session.request('GET', `/api/student/programs/${enrollmentId}/courses`);
+    const goldModule = moduleFrom(body.courses, GOLD_MODULE);
+    assert.equal(goldModule.activities.find((a) => a.activity_type === 'lab').complete, true);
+    assert.equal(goldModule.complete, false);
+  });
+
+  await step('student completes the reflection; the gold module is fully complete and the next module unlocks', async () => {
+    const { status } = await session.request('POST', '/api/student/activities/root-10-m01-a06-reflection-real-ops-takeaway/complete');
+    assert.equal(status, 200);
+    const { body } = await session.request('GET', `/api/student/programs/${enrollmentId}/courses`);
+    const goldModule = moduleFrom(body.courses, GOLD_MODULE);
+    assert.equal(goldModule.complete, true);
+    const nextModule = moduleFrom(body.courses, 'root-10-m02-general-troubleshooting');
+    assert.equal(nextModule.locked, false);
+  });
+
+  await step('the instructor Curriculum view shows this student\'s real progress through the gold module', async () => {
+    const { status, body } = await owner.request('GET', `/api/admin/students/${created.student_id}/courses?program_id=${PROGRAM}`);
+    assert.equal(status, 200);
+    const goldModule = moduleFrom(body, GOLD_MODULE);
+    assert.equal(goldModule.complete, true);
+    assert.ok(goldModule.activities[0].instructor_notes, 'the instructor view must see instructor notes the student view never does');
+  });
+
+  console.log(`\n${passed} passed, ${failed} failed`);
+  if (failed > 0) process.exit(1);
+}
+
+main().catch((e) => { console.error(e); process.exit(1); });

infra/scripts/drills/test-phase6b-root-course-rehearsal.js

@@ -0,0 +1,195 @@
+#!/usr/bin/env node
+// Phase 6B §23 — the ROOT_ curriculum expansion dress rehearsal. One continuous realistic
+// student narrative through a brand-NEW Phase 6B module (ROOT 07's Services & Service
+// Discovery, not the Phase 6A gold module — that one already has its own rehearsal), using a
+// REAL k3s Lab end to end, plus a short instructor narrative proving the Curriculum view,
+// Prepare Labs, and classroom/help tooling all still work against the expanded curriculum. Same
+// conventions as test-phase6a-course-rehearsal.js: assert-based, no framework, real k3s boots.
+//
+// Run via run-phase6b-root-course-rehearsal.sh, which brings up platform/docker-compose.dev.yml
+// first.
+
+const assert = require('assert');
+const { execSync } = require('child_process');
+const { makeSession } = require('../../../platform/test/session-helper');
+
+const GW = process.env.GATEWAY_URL || 'http://localhost:4200';
+const OWNER_EMAIL = process.env.OWNER_EMAIL;
+const OWNER_PASSWORD = process.env.OWNER_PASSWORD;
+if (!OWNER_EMAIL || !OWNER_PASSWORD) { console.error('Set OWNER_EMAIL and OWNER_PASSWORD'); process.exit(1); }
+const RUN_ID = Date.now();
+const PROGRAM = 'root-kubernetes-foundations';
+const SERVICES_MODULE = 'root-07-m03-services-and-service-discovery';
+
+let passed = 0, failed = 0;
+async function step(name, fn) {
+  try { await fn(); console.log(`  ok — ${name}`); passed++; }
+  catch (e) { console.error(`  FAIL — ${name}\n    ${e.stack || e.message}`); failed++; }
+}
+function moduleFrom(tree, id) { for (const c of tree) { const m = c.modules.find((x) => x.module_id === id); if (m) return m; } return null; }
+
+async function main() {
+  console.log('Phase 6B ROOT_ curriculum expansion dress rehearsal — slow, real k3s boots\n');
+
+  const owner = makeSession(GW);
+  await owner.request('POST', '/api/auth/instructor/login', { email: OWNER_EMAIL, password: OWNER_PASSWORD });
+
+  const { body: created } = await owner.request('POST', '/api/admin/students', {
+    display_name: 'Rehearsal 6B Student', login_identifier: `p6b-course-${RUN_ID}`,
+  });
+  const session = makeSession(GW);
+  let enrollmentId, envId;
+
+  await step('student activates credentials and logs in', async () => {
+    const { status } = await session.request('POST', '/api/student/activate', { token: created.activation_token, password: 'RehearsalPass123!' });
+    assert.equal(status, 200);
+  });
+
+  await step('an instructor enrolls the student in ROOT_', async () => {
+    const { status, body } = await owner.request('POST', '/api/admin/enrollments', { student_id: created.student_id, program_id: PROGRAM, status: 'active' });
+    assert.equal(status, 201);
+    enrollmentId = body.enrollment_id;
+  });
+
+  // Real Foundation completion via a real Lab, so root-06 (and therefore root-07) unlock.
+  const ROOT05_ALL = ['namespaces-basics', 'pod-basics-mcq', 'kubectl-essentials-mcq', 'labels-selectors-mcq', 'init-containers-mcq',
+    'multi-container-pod-basics', 'pod-labeling-basics', 'jsonpath-basics', 'dry-run-manifest-basics', 'delete-by-label-basics',
+    'annotate-resource-basics', 'init-container-task-basics', 'restart-policy-mcq', 'kubectl-output-format-mcq',
+    'kubectl-explain-basics', 'kubectl-patch-basics', 'field-selector-basics', 'sort-by-basics', 'kubectl-diff-basics', 'static-pods-mcq'];
+  const ROOT06_ALL = ['deploy-nginx', 'scale-deployment', 'rolling-update-task', 'liveness-probe-task', 'jobs-cronjobs-mcq',
+    'daemonset-mcq', 'edit-deployment-basics', 'deployment-strategy-mcq', 'deployment-rollback'];
+
+  await step('student launches a REAL Lab and completes ROOT 05 + ROOT 06 to unlock ROOT 07\'s new Services module', async () => {
+    const launch = await session.request('POST', `/api/student/programs/${enrollmentId}/launch`);
+    assert.equal(launch.status, 200);
+    assert.equal(launch.body.status, 'running');
+    const envRow = (await owner.request('GET', `/api/admin/students/${created.student_id}/environment`)).body.find((e) => e.status === 'running');
+    envId = envRow.environment_id;
+    for (const sid of [...ROOT05_ALL, ...ROOT06_ALL]) {
+      const r = await session.request('POST', '/api/progress/record', { scenario_id: sid, status: 'completed', environment_id: envId });
+      assert.equal(r.status, 200, `completing ${sid} should 200`);
+    }
+    // Both new teaching modules' own lesson/demo/knowledge-check/guided-exercise/reflection
+    // activities are manual_marker — completing only the underlying scenarios (above) is not
+    // enough to make root-05/root-06 COURSE-complete, which is what actually unlocks root-07.
+    for (const suffix of ['a01-lesson-mental-model', 'a02-demonstration-desired-state', 'a03-knowledge-check', 'a04-guided-exercise-namespaces', 'a06-reflection']) {
+      const r = await session.request('POST', `/api/student/activities/root-05-m00-${suffix}/complete`);
+      assert.equal(r.status, 200);
+    }
+    for (const suffix of ['a01-lesson-deployments', 'a02-demonstration-rollout', 'a03-knowledge-check', 'a04-guided-exercise-rollout-strategy', 'a06-reflection']) {
+      const r = await session.request('POST', `/api/student/activities/root-06-m02-${suffix}/complete`);
+      assert.equal(r.status, 200);
+    }
+    // root-06 the COURSE (root-07's actual prerequisite) also includes m03 — its two scenarios
+    // and two manual-marker activities.
+    for (const sid of ['job-task', 'cronjob-task']) {
+      const r = await session.request('POST', '/api/progress/record', { scenario_id: sid, status: 'completed', environment_id: envId });
+      assert.equal(r.status, 200);
+    }
+    for (const suffix of ['a01-lesson-jobs-cronjobs-daemonsets', 'a02-knowledge-check']) {
+      const r = await session.request('POST', `/api/student/activities/root-06-m03-${suffix}/complete`);
+      assert.equal(r.status, 200);
+    }
+  });
+
+  await step('the new ROOT 07 Services & Service Discovery module is now unlocked with real lesson content', async () => {
+    const { body } = await session.request('GET', `/api/student/programs/${enrollmentId}/courses`);
+    const mod = moduleFrom(body.courses, SERVICES_MODULE);
+    assert.equal(mod.locked, false);
+    assert.equal(mod.activities[0].activity_type, 'lesson');
+    assert.ok(mod.activities[0].body.includes('Service'), 'the real lesson content must actually be served');
+  });
+
+  await step('student reads the lesson/demonstration, completes the knowledge check and guided exercise', async () => {
+    for (const suffix of ['a01-lesson-services', 'a02-demonstration-zero-endpoints', 'a03-knowledge-check', 'a04-guided-exercise-service-type']) {
+      const { status } = await session.request('POST', `/api/student/activities/root-07-m03-${suffix}/complete`);
+      assert.equal(status, 200);
+    }
+  });
+
+  await step('student launches the module\'s Lab activity for real and runs real kubectl against it', async () => {
+    const { body } = await session.request('GET', `/api/student/programs/${enrollmentId}/courses`);
+    const mod = moduleFrom(body.courses, SERVICES_MODULE);
+    const lab = mod.activities.find((a) => a.activity_type === 'lab');
+    assert.equal(lab.scenario_id, 'expose-service-basics');
+    assert.equal(lab.complete, false);
+
+    const launch = await session.request('POST', `/api/student/programs/${enrollmentId}/launch`);
+    const labToken = launch.body.launch_path.match(/\/lab\/([^/]+)\//)[1];
+    const setup = await session.request('POST', `/lab/${labToken}/api/scenarios/expose-service-basics/setup`);
+    assert.equal(setup.status, 200);
+
+    // Real kubectl, run inside the student's actual disposable Lab container — solving the
+    // scenario the same way a real student would from the terminal, not a simulated pass.
+    const containerName = execSync(
+      `docker compose -f docker-compose.dev.yml exec -T postgres psql -U postgres -d rootnode_platform -t -c "SELECT container_name FROM environments WHERE environment_id = '${envId}'"`,
+      { cwd: `${__dirname}/../../../platform`, stdio: 'pipe' }
+    ).toString().trim();
+    execSync(`docker exec ${containerName} kubectl expose deployment redis --name=redis-svc --port=6379`, { stdio: 'pipe' });
+
+    const validate = await session.request('POST', `/lab/${labToken}/api/scenarios/expose-service-basics/validate`);
+    assert.equal(validate.status, 200);
+    assert.equal(validate.body.passed, true, `expected the real validation to pass: ${JSON.stringify(validate.body)}`);
+
+    const record = await session.request('POST', '/api/progress/record', { scenario_id: 'expose-service-basics', status: 'completed', environment_id: envId });
+    assert.equal(record.status, 200);
+  });
+
+  await step('the lab activity completes and the module finishes once the reflection is marked', async () => {
+    const { body: before } = await session.request('GET', `/api/student/programs/${enrollmentId}/courses`);
+    assert.equal(moduleFrom(before.courses, SERVICES_MODULE).activities.find((a) => a.activity_type === 'lab').complete, true);
+    await session.request('POST', '/api/student/activities/root-07-m03-a06-reflection/complete');
+    const { body: after } = await session.request('GET', `/api/student/programs/${enrollmentId}/courses`);
+    assert.equal(moduleFrom(after.courses, SERVICES_MODULE).complete, true);
+  });
+
+  await step('logout, login, Resume Learning, destroy the Lab, recreate it — academic progress survives all of it', async () => {
+    await session.request('POST', '/api/logout');
+    const returning = makeSession(GW);
+    await returning.request('POST', '/api/student/login', { identifier: `p6b-course-${RUN_ID}`, password: 'RehearsalPass123!' });
+    const { body: resumed } = await returning.request('GET', `/api/student/programs/${enrollmentId}/courses`);
+    assert.equal(moduleFrom(resumed.courses, SERVICES_MODULE).complete, true, 'progress must survive a real logout/login');
+
+    await owner.request('DELETE', `/api/admin/environments/${envId}`);
+    const relaunch = await returning.request('POST', `/api/student/programs/${enrollmentId}/launch`);
+    assert.equal(relaunch.status, 200);
+    assert.equal(relaunch.body.status, 'running');
+    const { body: afterRecreate } = await returning.request('GET', `/api/student/programs/${enrollmentId}/courses`);
+    assert.equal(moduleFrom(afterRecreate.courses, SERVICES_MODULE).complete, true, 'academic progress must survive Lab destroy/recreate');
+  });
+
+  // ── Instructor narrative ────────────────────────────────────────────────────────────────
+  await step('instructor inspects the curriculum structure and this module\'s teaching notes', async () => {
+    const { status, body } = await owner.request('GET', `/api/admin/programs/${PROGRAM}/courses`);
+    assert.equal(status, 200);
+    const mod = moduleFrom(body, SERVICES_MODULE);
+    assert.equal(mod.activities.length, 6);
+    assert.ok(mod.activities[0].instructor_notes, 'instructor must see instructor notes the student view never does');
+  });
+
+  await step('instructor sees this specific student\'s real progress through the new module', async () => {
+    const { status, body } = await owner.request('GET', `/api/admin/students/${created.student_id}/courses?program_id=${PROGRAM}`);
+    assert.equal(status, 200);
+    assert.equal(moduleFrom(body, SERVICES_MODULE).complete, true);
+  });
+
+  await step('a real classroom cohort can still be prepared and observed alongside the expanded curriculum', async () => {
+    const cohortId = `p6b-rehearsal-cohort-${RUN_ID}`;
+    const create = await owner.request('POST', '/api/admin/cohorts', { cohort_id: cohortId, name: 'P6B Rehearsal Cohort' });
+    assert.equal(create.status, 201);
+    const { body: student2 } = await owner.request('POST', '/api/admin/students', { display_name: 'P6B Cohort Student', login_identifier: `p6b-cohort-student-${RUN_ID}` });
+    const addStudent = await owner.request('POST', `/api/admin/students/${student2.student_id}/cohort`, { cohort_id: cohortId });
+    assert.equal(addStudent.status, 200);
+    const assignCurriculum = await owner.request('POST', `/api/admin/cohorts/${cohortId}/curriculum`, { curriculum_path: 'rootnode-path' });
+    assert.equal(assignCurriculum.status, 200);
+    const prepare = await owner.request('POST', `/api/admin/cohorts/${cohortId}/prepare-labs`);
+    assert.equal(prepare.status, 200);
+    const summary = await owner.request('GET', `/api/admin/cohorts/${cohortId}/learning`);
+    assert.equal(summary.status, 200, 'classroom/learning tooling must still function against the expanded curriculum');
+  });
+
+  console.log(`\n${passed} passed, ${failed} failed`);
+  if (failed > 0) process.exit(1);
+}
+
+main().catch((e) => { console.error(e); process.exit(1); });

infra/scripts/gws-email-test.js

@@ -0,0 +1,51 @@
+#!/usr/bin/env node
+// Phase 5C §24 — the OPTIONAL, opt-in Google Workspace live-delivery test. Does NOTHING unless
+// explicitly enabled — no test/regression run ever sends real email by accident.
+//
+// Usage (only when you actually have real Workspace credentials configured):
+//   RUN_GWS_EMAIL_TEST=true \
+//   [email protected] \
+//   GOOGLE_SERVICE_ACCOUNT_JSON='{"client_email":"...","private_key":"..."}' \
+//   [email protected] \
+//   EMAIL_FROM_NAME="RootNode Academy" \
+//   node infra/scripts/gws-email-test.js
+//
+// Sends exactly ONE clearly-marked test message to TEST_EMAIL_RECIPIENT — never a
+// production/student address, never inferred from anything in the database. Run it once after
+// setting up domain-wide delegation to confirm the adapter actually works against the real
+// Gmail API, not as part of any regular regression pass (see docs/RUNBOOK_GOOGLE_WORKSPACE_EMAIL.md).
+
+if (process.env.RUN_GWS_EMAIL_TEST !== 'true') {
+  console.log('Skipped: set RUN_GWS_EMAIL_TEST=true to actually send a live test email. Nothing was sent.');
+  process.exit(0);
+}
+
+const recipient = process.env.TEST_EMAIL_RECIPIENT;
+if (!recipient) {
+  console.error('Set TEST_EMAIL_RECIPIENT to the ONE address this test should send to — it is never inferred from anything else.');
+  process.exit(1);
+}
+
+const provider = require('../../platform/api/src/email/gws-provider');
+
+async function main() {
+  console.log(`Sending one live test message via the Gmail API adapter to ${recipient}...`);
+  const result = await provider.send({
+    to: recipient,
+    fromName: process.env.EMAIL_FROM_NAME || 'RootNode Academy',
+    fromAddress: process.env.EMAIL_FROM_ADDRESS,
+    replyTo: process.env.EMAIL_REPLY_TO,
+    subject: '[RootNode Academy] Google Workspace adapter test',
+    text: `This is a one-off test of RootNode Academy's Google Workspace email adapter (Gmail API, service account domain-wide delegation). If you received this, live delivery is working. Sent at ${new Date().toISOString()}.`,
+    html: `<p>This is a one-off test of RootNode Academy's Google Workspace email adapter (Gmail API, service account domain-wide delegation).</p><p>If you received this, live delivery is working. Sent at ${new Date().toISOString()}.</p>`,
+  });
+  console.log('Provider accepted the message.');
+  console.log('Provider message ID:', result.providerMessageId);
+  console.log('\nGWS LIVE DELIVERY TEST: PASSED');
+}
+
+main().catch((e) => {
+  console.error('GWS LIVE DELIVERY TEST: FAILED');
+  console.error(`  ${e.errorCode || 'error'}: ${e.message}`);
+  process.exit(1);
+});

platform/README.md

@@ -7,18 +7,27 @@ entrypoint/Dockerfile unmodified; frontend bundle gained Phase 3B learning UX, s
 - `provisioner/` — Postgres-backed environment registry and lifecycle. Design:
   `docs/LAB_ARCHITECTURE.md`, `docs/PHASE1_PLATFORM_FOUNDATION.md`. Operational reference:
   `provisioner/README.md`.
-- `api/` — the lightweight Platform API: students, cohorts, enrollments, curriculum, detailed
-  scenario attempt telemetry, progressive hints, curriculum completion rules, the exam +
+- `api/` — the lightweight Platform API: students, cohorts and cohort membership, curriculum,
+  detailed scenario attempt telemetry, progressive hints, curriculum completion rules, the exam +
   capstone assessment engine, achievements, per-instructor accounts, persistent student/
   instructor sessions, RBAC, audit logging, real student credentials + remote classrooms
-  (Phase 5A), and the instructor/admin control plane. No k3s, no `--privileged` — this replaced
-  Phase 2A's "identity" instance, which was a full Lab image booting an unused k3s cluster just
-  to serve these APIs. Design:
+  (Phase 5A), self-paced programs/enrollment + the website integration boundary (Phase 5B), and
+  a provider-neutral enrollment-communications pipeline (activation/enrollment-confirmation/
+  password-reset email, Phase 5C), the ROOT_ course/module/activity content model layered over
+  curriculum/assessments (Phase 6A) with real teaching content across most of the Kubernetes
+  courses and a server-side capstone unlock enforcement fix (Phase 6B), and the instructor/admin
+  control plane. No k3s, no
+  `--privileged` — this replaced Phase 2A's "identity" instance, which was a full Lab image
+  booting an unused k3s cluster just to serve these APIs. Design:
   `docs/PHASE2B_ADMIN_AND_PLATFORM_DATA.md` (split + Postgres migration),
   `docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md` (sessions, accounts, RBAC, audit),
   `docs/PHASE3B_LEARNING_AND_ASSESSMENT.md` (learning/assessment engine),
-  `docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md` (student credentials, remote classroom).
-  Operational reference: `api/README.md`.
+  `docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md` (student credentials, remote classroom),
+  `docs/PHASE5B_SELF_PACED_ENROLLMENT.md` (programs, enrollment, website integration boundary),
+  `docs/PHASE5C_ENROLLMENT_COMMUNICATIONS.md` (notifications, email delivery),
+  `docs/PHASE6A_ROOT_COURSE_FOUNDATION.md` (course/module/activity content model, gold-standard
+  module), `docs/PHASE6B_ROOT_CURRICULUM_EXPANSION.md` (curriculum authoring across ROOT
+  05-10/12/Capstone, the capstone unlock fix). Operational reference: `api/README.md`.
 - `gateway/` — the only student-facing path to a Lab (HTTP + WebSocket proxy, environment-aware
   routing derived from a server-controlled session — not a client-suppliable header/param — and,
   as of Phase 3B, server-side gating of progressive hint reveal). Design:
@@ -70,13 +79,37 @@ further instructor accounts from the Instructors tab).
   Lab reset, curriculum stage/Capstone lock-unlock, the exam engine (random draw, server
   timer, expiry, restart persistence), the Capstone workflow end to end, two-student assessment
   isolation, and instructor learning analytics/RBAC.
+- `test/e2e-phase5a.js` — real student credentials (activation/password reset/login), remote
+  classroom sessions (join/heartbeat/announcements/help requests), and instructor conversion of
+  a pilot student to a credentialed account.
+- `test/e2e-phase5b.js` — programs/enrollment, entitlement gating (pending/future/expired/
+  cancelled), server-derived completion, disposable-Lab persistence across destroy/recreate, and
+  the website/commerce integration boundary (idempotency, concurrency, RBAC).
+- `test/e2e-phase5c.js` — the notification lifecycle (queue/retry/failure/exhaustion),
+  activation/enrollment-confirmation/password-reset email delivery via the deterministic dev
+  provider, minor/no-email contact-email resolution, and admin notification RBAC.
+- `test/e2e-phase6a.js` — course/module/activity hierarchy and ordering, prerequisite-based
+  locking, all three completion behaviors (manual marker/scenario/assessment-derived), resume,
+  cross-student isolation, RBAC for self-paced (no-cohort) students, and draft-content hiding.
+- `test/e2e-phase6b.js` — hierarchy for the 13 new modules across ROOT 05-10/12/Capstone,
+  prerequisite chains through the newly-inserted front-door modules, the optional-vs-required
+  (`is_required`) completion rule, and the capstone server-side unlock fix in both directions
+  (a direct bypass attempt rejected, a legitimately unlocked attempt still accepted).
 
-All four e2e suites need `OWNER_EMAIL` / `OWNER_PASSWORD` set to a real bootstrapped instructor
+All e2e suites need `OWNER_EMAIL` / `OWNER_PASSWORD` set to a real bootstrapped instructor
 account (see "Running the full stack locally" above) — the old `ADMIN_PASSWORD` mechanism is
 gone. They're slow (real k3s boots, `e2e-phase3b.js` also runs a real API restart) and need the
-full stack up. None of them substitute for the manual real-Lab-image checks (node-pty, terminal
+full stack up. Run each suite against its own freshly-reset stack, not chained one after another
+against the same Postgres — several routes (the admin dashboard's running-lab count, a course's
+percent-complete) read GLOBAL state on purpose, and chaining suites produces false failures from
+shared state, not real regressions (found and documented during Phase 6A's own regression pass).
+None of them substitute for the manual real-Lab-image checks (node-pty, terminal
 WebSocket, `kubectl`, scenario validation) in `docs/PHASE2A_GATEWAY_AND_STUDENT_FLOW.md` §8 —
-those need a browser-equivalent client and aren't automated here.
+those need a browser-equivalent client and aren't automated here. Two exceptions get a real-Lab
+dress rehearsal instead: Phase 6A's gold-standard module
+(`infra/scripts/drills/run-phase6a-course-rehearsal.sh`) and Phase 6B's curriculum expansion,
+including a real `kubectl expose` and a real instructor/classroom narrative
+(`infra/scripts/drills/run-phase6b-root-course-rehearsal.sh`).
 
 ## Known limitations
 

platform/api/Dockerfile

@@ -33,6 +33,10 @@ COPY platform/api/migrate-sqlite.js ./
 # listing/progress-shaping (never executed; setup/validate/teardown stay Lab-only).
 COPY scenarios/ ./scenarios/
 
+# Phase 6A — course/module lesson prose (content.js). Git-tracked Markdown, read-only, same
+# reasoning as scenarios/ above: this image only ever reads it, never executes anything from it.
+COPY content/ ./content/
+
 # Platform-shell + admin frontend, built in the stage above — served statically, no nginx
 # needed for a lightweight Node API+static server.
 COPY --from=frontend-build /fe/dist/ /frontend-dist/

platform/api/migrations/019_programs.sql

@@ -0,0 +1,45 @@
+-- Phase 5B §2 — programs: first-class learning products, distinct from curriculum JSON itself
+-- (a program is the commercial/academic unit a student enrolls in; curriculum_path is still
+-- just the content it points at, unchanged since Phase 1). program_id IS the slug — same
+-- convention as assessment_definitions/cohorts (a single TEXT primary key, no separate numeric
+-- id + slug pair).
+--
+-- family is the init_/compile_/root_ youth-engineering ladder (see
+-- docs/PHASE5B_SELF_PACED_ENROLLMENT.md §1) — only 'root' has real curriculum content today;
+-- init/compile rows can be added later without a schema change, they just won't have a working
+-- curriculum_path yet. delivery_mode describes how the program is normally taken; an
+-- individual enrollment can still snapshot a different mode (see 020_enrollments.sql).
+--
+-- version is a plain incrementing integer, matching assessment_definitions' existing
+-- versioning convention — enrollments snapshot the version+curriculum_path they were created
+-- against so a later edit to a program never silently changes what an already-enrolled
+-- student is being held to.
+CREATE TABLE IF NOT EXISTS programs (
+  program_id               TEXT PRIMARY KEY,        -- slug, e.g. 'root-kubernetes-foundations'
+  name                      TEXT NOT NULL,
+  description               TEXT,
+  family                    TEXT NOT NULL CHECK (family IN ('init', 'compile', 'root')),
+  delivery_mode             TEXT NOT NULL DEFAULT 'self_paced' CHECK (delivery_mode IN ('self_paced', 'cohort', 'hybrid')),
+  curriculum_path           TEXT NOT NULL DEFAULT 'rootnode-path',
+  completion_assessment_id  TEXT REFERENCES assessment_definitions(assessment_definition_id),
+  estimated_duration_hours  INTEGER,
+  version                   INTEGER NOT NULL DEFAULT 1,
+  status                    TEXT NOT NULL DEFAULT 'active' CHECK (status IN ('active', 'inactive')),
+  created_by                UUID REFERENCES instructors(instructor_id),
+  created_at                TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                TIMESTAMPTZ NOT NULL DEFAULT now()
+);
+
+CREATE INDEX IF NOT EXISTS idx_programs_status ON programs(status);
+CREATE INDEX IF NOT EXISTS idx_programs_family ON programs(family);
+
+-- Seed: the one legitimate self-paced program this phase ships, wrapping the EXISTING
+-- RootNode/Kubernetes curriculum and capstone — no new curriculum content invented. init_/
+-- compile_ programs are intentionally NOT seeded (no real curriculum for them yet, per this
+-- phase's explicit scope line).
+INSERT INTO programs (program_id, name, description, family, delivery_mode, curriculum_path, completion_assessment_id, estimated_duration_hours)
+VALUES (
+  'root-kubernetes-foundations', 'ROOT — Kubernetes Foundations',
+  'Self-paced Linux, containers, and Kubernetes operations — the existing RootNode curriculum, from Foundations through the RootNode Capstone.',
+  'root', 'self_paced', 'rootnode-path', 'rootnode-capstone', 40
+) ON CONFLICT (program_id) DO NOTHING;

platform/api/migrations/020_enrollments.sql

@@ -0,0 +1,51 @@
+-- Phase 5B §3 — enrollments: a student's academic access to a program. Deliberately separate
+-- from cohort_enrollments (002_cohorts.sql) — a self-paced enrollment has no cohort at all, and
+-- a student can hold both kinds independently (see docs/PHASE5B_SELF_PACED_ENROLLMENT.md §4).
+--
+-- delivery_mode/program_version/curriculum_path are snapshotted from the program AT enrollment
+-- time — same versioning principle as assessment_sessions (013_assessments.sql) snapshotting a
+-- definition's fields at draw time, so editing a program later never silently changes what an
+-- already-enrolled student is being held to.
+--
+-- status is server-transitioned only (enrollment.js) — pending -> active -> completed/expired,
+-- or pending/active -> cancelled. 'expired' is set lazily/derived at read time from
+-- access_ends_at (matching classroom.js's derivePresence pattern — no stored value to go
+-- stale), so it is intentionally NOT a value the application ever writes directly except when
+-- reconciling; see enrollment.js's deriveEnrollmentAccess.
+CREATE TABLE IF NOT EXISTS enrollments (
+  enrollment_id      UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  student_id          TEXT NOT NULL REFERENCES students(student_id),
+  program_id          TEXT NOT NULL REFERENCES programs(program_id),
+  delivery_mode       TEXT NOT NULL,               -- snapshot of programs.delivery_mode at enrollment time
+  program_version     INTEGER NOT NULL,            -- snapshot of programs.version at enrollment time
+  curriculum_path     TEXT NOT NULL,               -- snapshot of programs.curriculum_path at enrollment time
+  status               TEXT NOT NULL DEFAULT 'pending' CHECK (status IN ('pending', 'active', 'completed', 'cancelled', 'expired')),
+  source               TEXT NOT NULL DEFAULT 'admin',  -- free text provenance ('admin', or whatever the integration event's own "source" said, e.g. 'website') — NEVER used as a metrics label, see metrics.js
+  external_event_id   TEXT,                        -- idempotency key for integration-created enrollments; null for admin-created ones
+  external_reference  TEXT,                        -- optional business reference (order/payment id) — free text, not unique, audit-only
+  starts_at            TIMESTAMPTZ,                 -- null = immediate access once active
+  access_ends_at      TIMESTAMPTZ,                 -- null = no expiration
+  enrolled_at          TIMESTAMPTZ NOT NULL DEFAULT now(),
+  activated_at         TIMESTAMPTZ,
+  completed_at         TIMESTAMPTZ,
+  cancelled_at         TIMESTAMPTZ,
+  metadata             JSONB,
+  created_by           UUID REFERENCES instructors(instructor_id),  -- null for integration-created enrollments
+  created_at           TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at           TIMESTAMPTZ NOT NULL DEFAULT now()
+);
+
+CREATE INDEX IF NOT EXISTS idx_enrollments_student ON enrollments(student_id);
+CREATE INDEX IF NOT EXISTS idx_enrollments_program ON enrollments(program_id);
+CREATE INDEX IF NOT EXISTS idx_enrollments_status ON enrollments(status);
+CREATE INDEX IF NOT EXISTS idx_enrollments_created_by ON enrollments(created_by);
+
+-- Idempotency: the same external_event_id can never create two rows. A unique index (not just
+-- app-level "SELECT first") is what actually makes concurrent duplicate submissions safe — see
+-- enrollment.js's createFromIntegrationEvent, which relies on this via ON CONFLICT.
+CREATE UNIQUE INDEX IF NOT EXISTS idx_enrollments_external_event ON enrollments(external_event_id) WHERE external_event_id IS NOT NULL;
+
+-- At most one non-terminal (pending/active) enrollment per student+program at a time. A
+-- completed/cancelled/expired enrollment doesn't block a new one — re-enrollment creates a new
+-- row rather than reviving a historical one (§3: "do not corrupt historical records").
+CREATE UNIQUE INDEX IF NOT EXISTS idx_enrollments_one_open_per_program ON enrollments(student_id, program_id) WHERE status IN ('pending', 'active');

platform/api/migrations/021_notification_events.sql

@@ -0,0 +1,44 @@
+-- Phase 5C §4 — durable notification lifecycle. Every "we should email this student" moment
+-- (activation, enrollment confirmation, password reset, password-changed) becomes a row here
+-- FIRST, committed in the same transaction/request as the business action, and a separate
+-- worker (notification-worker.js) is what actually talks to the email provider — the HTTP
+-- request that triggers a notification never waits on outbound email network calls.
+--
+-- recipient_email is a SNAPSHOT taken at enqueue time, not a live join to students.email —
+-- documented privacy note: this duplicates PII already stored on `students`/in an enrollment's
+-- metadata (the minor/no-email contact address, see 020_enrollments.sql's `metadata` column,
+-- Phase 5C's `contact_email` convention) purely so the worker and any later delivery audit
+-- don't need to reconstruct "what address would this have gone to" after the fact — same
+-- sensitivity class as data already in this database, not a new exposure. Never rendered
+-- unmasked through admin APIs (see notifications.js's maskEmail).
+--
+-- metadata MAY transiently hold plaintext activation/reset token material between enqueue and
+-- the worker's terminal (sent/failed) update — see notifications.js's header comment for the
+-- exact reasoning. It is scrubbed the moment a row reaches a terminal state. NEVER a raw error
+-- stack trace, NEVER a Google credential, NEVER a full provider payload.
+CREATE TABLE IF NOT EXISTS notification_events (
+  notification_id     UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  student_id            TEXT NOT NULL REFERENCES students(student_id),
+  enrollment_id         UUID REFERENCES enrollments(enrollment_id),
+  notification_type     TEXT NOT NULL CHECK (notification_type IN ('activation', 'enrollment_confirmation', 'password_reset', 'password_changed')),
+  channel                TEXT NOT NULL DEFAULT 'email' CHECK (channel IN ('email')),
+  recipient_email        TEXT,
+  provider                TEXT,
+  provider_message_id     TEXT,
+  status                   TEXT NOT NULL DEFAULT 'queued' CHECK (status IN ('queued', 'sending', 'sent', 'failed', 'cancelled')),
+  attempt_count            INTEGER NOT NULL DEFAULT 0,
+  next_attempt_at          TIMESTAMPTZ NOT NULL DEFAULT now(),
+  last_error_code          TEXT,
+  created_at               TIMESTAMPTZ NOT NULL DEFAULT now(),
+  queued_at                TIMESTAMPTZ NOT NULL DEFAULT now(),
+  sent_at                  TIMESTAMPTZ,
+  failed_at                TIMESTAMPTZ,
+  updated_at               TIMESTAMPTZ NOT NULL DEFAULT now(),
+  metadata                 JSONB
+);
+
+CREATE INDEX IF NOT EXISTS idx_notification_events_student ON notification_events(student_id);
+CREATE INDEX IF NOT EXISTS idx_notification_events_enrollment ON notification_events(enrollment_id);
+CREATE INDEX IF NOT EXISTS idx_notification_events_status ON notification_events(status);
+-- The worker's claim query — partial index scoped to exactly the rows it ever selects from.
+CREATE INDEX IF NOT EXISTS idx_notification_events_claimable ON notification_events(next_attempt_at) WHERE status = 'queued';

platform/api/migrations/022_course_content.sql

@@ -0,0 +1,266 @@
+-- Phase 6A §3 — the course/module/activity content model. This is a STRUCTURAL layer on top
+-- of everything Phase 1-5 already built (scenarios/*.json, assessment_definitions, achievements,
+-- progress/scenario_attempts) — it never duplicates that content, only references it:
+--
+--   program (existing, 019_programs.sql)
+--     -> course (new)
+--         -> course_module (new)
+--             -> module_activity (new) -- type lab: scenario_id references scenarios/data/*.json
+--                                       -- type assessment/capstone: assessment_definition_id
+--                                       --   references assessment_definitions (013_assessments.sql)
+--                                       -- everything else: content_path references a Markdown
+--                                       --   file under content/root/ (git-tracked prose, not a
+--                                       --   Postgres blob — see docs/COURSE_CONTENT_MODEL.md)
+--
+-- Long-form lesson prose deliberately does NOT live in Postgres — only the structural metadata
+-- (ordering, type, references, status) does. See docs/COURSE_CONTENT_MODEL.md for the full
+-- rationale (git-editable content vs. a CMS) and the Markdown convention (a `## Instructor
+-- Notes` heading splits shared content from instructor-only content in the same file).
+--
+-- No CMS, no WYSIWYG editor tables, no content versioning system beyond the same plain
+-- incrementing `version` integer every other definitional table here already uses
+-- (assessment_definitions, programs) — bumped by hand when a semantic edit is made, exactly the
+-- same convention, not a new one.
+
+CREATE TABLE IF NOT EXISTS courses (
+  course_id                TEXT PRIMARY KEY,        -- slug, e.g. 'root-05-kubernetes-foundations'
+  program_id                TEXT NOT NULL REFERENCES programs(program_id),
+  title                      TEXT NOT NULL,
+  description                TEXT,
+  sequence                   INTEGER NOT NULL,        -- position within the program's course list
+  objectives                 TEXT[] NOT NULL DEFAULT '{}',
+  prerequisites               TEXT[] NOT NULL DEFAULT '{}',  -- course_ids; see docs/COURSE_CONTENT_MODEL.md
+                                                               -- §"prerequisite/locking rule" for how an
+                                                               -- empty-content prerequisite is treated
+  estimated_duration_hours   INTEGER,
+  status                      TEXT NOT NULL DEFAULT 'planned' CHECK (status IN ('ready', 'partial', 'planned')),
+  visibility                  TEXT NOT NULL DEFAULT 'published' CHECK (visibility IN ('published', 'draft')),
+  version                     INTEGER NOT NULL DEFAULT 1,
+  created_at                  TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                  TIMESTAMPTZ NOT NULL DEFAULT now()
+);
+CREATE INDEX IF NOT EXISTS idx_courses_program ON courses(program_id, sequence);
+
+CREATE TABLE IF NOT EXISTS course_modules (
+  module_id                 TEXT PRIMARY KEY,        -- slug, e.g. 'root-05-m01-pods-and-kubectl-basics'
+  course_id                  TEXT NOT NULL REFERENCES courses(course_id),
+  title                       TEXT NOT NULL,
+  description                 TEXT,
+  sequence                    INTEGER NOT NULL,       -- position within the course's module list
+  objectives                  TEXT[] NOT NULL DEFAULT '{}',
+  prerequisites                TEXT[] NOT NULL DEFAULT '{}',  -- module_ids
+  estimated_duration_minutes  INTEGER,
+  status                       TEXT NOT NULL DEFAULT 'planned' CHECK (status IN ('ready', 'partial', 'planned')),
+  visibility                   TEXT NOT NULL DEFAULT 'published' CHECK (visibility IN ('published', 'draft')),
+  version                      INTEGER NOT NULL DEFAULT 1,
+  created_at                   TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                   TIMESTAMPTZ NOT NULL DEFAULT now()
+);
+CREATE INDEX IF NOT EXISTS idx_modules_course ON course_modules(course_id, sequence);
+
+CREATE TABLE IF NOT EXISTS module_activities (
+  activity_id                TEXT PRIMARY KEY,       -- slug, e.g. 'root-10-m01-...-a05-rootnode-probe-port-mismatch'
+  module_id                   TEXT NOT NULL REFERENCES course_modules(module_id),
+  sequence                    INTEGER NOT NULL,       -- position within the module's activity list
+  activity_type                TEXT NOT NULL CHECK (activity_type IN
+                                 ('lesson', 'demonstration', 'knowledge_check', 'guided_exercise',
+                                  'lab', 'reflection', 'assessment', 'capstone')),
+  title                        TEXT NOT NULL,
+  content_path                 TEXT,                  -- Markdown file under content/root/, relative to repo root; NULL for a pure lab/assessment reference with no extra prose
+  scenario_id                  TEXT,                   -- 'lab' activities only — references scenarios/data/<id>.json (not a DB FK; that content isn't a DB table)
+  assessment_definition_id      TEXT REFERENCES assessment_definitions(assessment_definition_id), -- 'assessment'/'capstone' activities only
+  completion_behavior           TEXT NOT NULL DEFAULT 'manual_marker' CHECK (completion_behavior IN
+                                  ('auto_scenario', 'auto_assessment', 'manual_marker')),
+  estimated_duration_minutes    INTEGER,
+  status                        TEXT NOT NULL DEFAULT 'planned' CHECK (status IN ('ready', 'partial', 'planned')),
+  visibility                    TEXT NOT NULL DEFAULT 'published' CHECK (visibility IN ('published', 'draft')),
+  version                       INTEGER NOT NULL DEFAULT 1,
+  created_at                    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at                    TIMESTAMPTZ NOT NULL DEFAULT now(),
+  CONSTRAINT module_activity_lab_has_scenario CHECK (activity_type != 'lab' OR scenario_id IS NOT NULL),
+  CONSTRAINT module_activity_assessment_has_definition CHECK (activity_type NOT IN ('assessment', 'capstone') OR assessment_definition_id IS NOT NULL)
+);
+CREATE INDEX IF NOT EXISTS idx_activities_module ON module_activities(module_id, sequence);
+CREATE INDEX IF NOT EXISTS idx_activities_scenario ON module_activities(scenario_id);
+
+-- Explicit completion marker — ONLY for activities whose completion_behavior is
+-- 'manual_marker' (lesson/demonstration/knowledge_check/guided_exercise/reflection). A 'lab'
+-- activity's completion is derived live from the existing progress table
+-- (scenario_id -> progress[scenario_id].status = 'completed', exactly what curriculum-rules.js
+-- already checks) and an 'assessment'/'capstone' activity's completion is derived live from the
+-- existing achievements table — this table is never a second source of truth for either. See
+-- docs/COURSE_CONTENT_MODEL.md §"completion rules".
+CREATE TABLE IF NOT EXISTS activity_completions (
+  student_id       TEXT NOT NULL REFERENCES students(student_id),
+  activity_id      TEXT NOT NULL REFERENCES module_activities(activity_id),
+  completed_at     TIMESTAMPTZ NOT NULL DEFAULT now(),
+  PRIMARY KEY (student_id, activity_id)
+);
+CREATE INDEX IF NOT EXISTS idx_activity_completions_student ON activity_completions(student_id);
+
+-- ═══════════════════════════════════════════════════════════════════════════════════════════
+-- Seed: the ROOT_ course architecture (docs/ROOT_PROGRAM_ARCHITECTURE.md), all under the
+-- existing 'root-kubernetes-foundations' program — root_ is one continuous ladder a student
+-- enrolls in once, not twelve separate commercial products, so no programs-table change.
+--
+-- Every module/activity below references EXISTING scenario/assessment content only — nothing
+-- here duplicates or forks scenarios/*.json or assessment_definitions. See
+-- docs/ROOT_CURRICULUM_INVENTORY.md for the full inventory this mapping is grounded in.
+-- ═══════════════════════════════════════════════════════════════════════════════════════════
+
+INSERT INTO courses (course_id, program_id, title, description, sequence, objectives, prerequisites, estimated_duration_hours, status) VALUES
+('root-01-computing-linux-foundations', 'root-kubernetes-foundations', 'Computing & Linux Foundations',
+ 'How a computer actually works, the Linux filesystem and shell, and the command-line fluency everything else in root_ builds on. No lab content exists in this repository yet.',
+ 1, '{}', '{}', NULL, 'planned'),
+('root-02-linux-administration-networking', 'root-kubernetes-foundations', 'Linux Administration & Networking',
+ 'Users/permissions, services and systemd, package management, and TCP/IP networking fundamentals. No lab content exists in this repository yet.',
+ 2, '{}', '{}', NULL, 'planned'),
+('root-03-git-collaborative-development', 'root-kubernetes-foundations', 'Git & Collaborative Development',
+ 'Version control, branching, code review, and working in a shared repository. No lab content exists in this repository yet.',
+ 3, '{}', '{}', NULL, 'planned'),
+('root-04-containers-and-docker', 'root-kubernetes-foundations', 'Containers & Docker',
+ 'What a container actually is, building images, and running/networking containers with Docker, as the on-ramp to Kubernetes. No lab content exists in this repository yet.',
+ 4, '{}', '{}', NULL, 'planned'),
+('root-05-kubernetes-foundations', 'root-kubernetes-foundations', 'Kubernetes Foundations',
+ 'Pods, kubectl fluency, labels/selectors, and the core object model — the existing "Foundation" curriculum stage.',
+ 5, '{"Explain what a Pod is and its lifecycle states","Use kubectl confidently to inspect and manipulate cluster objects","Apply labels and selectors to organize resources"}', '{}', 8, 'partial'),
+('root-06-kubernetes-application-workloads', 'root-kubernetes-foundations', 'Kubernetes Application Workloads',
+ 'Deployments, scaling, rolling updates, Jobs/CronJobs, and DaemonSets — the existing "Workloads" curriculum stage.',
+ 6, '{"Deploy and scale a stateless application","Perform a rolling update and understand deployment strategies","Distinguish Jobs, CronJobs, and DaemonSets"}', '{root-05-kubernetes-foundations}', 4, 'partial'),
+('root-07-kubernetes-networking-config', 'root-kubernetes-foundations', 'Kubernetes Networking & Configuration',
+ 'Services, exposing applications, ConfigMaps, Secrets, and environment configuration — the existing "Networking" and "Configuration" curriculum stages.',
+ 7, '{"Expose a workload with the right Service type","Externalize configuration with ConfigMaps and Secrets"}', '{root-06-kubernetes-application-workloads}', 4, 'partial'),
+('root-08-kubernetes-storage-scheduling', 'root-kubernetes-foundations', 'Kubernetes Storage & Scheduling',
+ 'PersistentVolumes/Claims, StorageClasses, taints/tolerations, priority, and disruption budgets. Real scenario content exists in this repository (see docs/ROOT_CURRICULUM_INVENTORY.md) but is not yet wired into a module — Phase 6B.',
+ 8, '{}', '{root-07-kubernetes-networking-config}', NULL, 'planned'),
+('root-09-kubernetes-security', 'root-kubernetes-foundations', 'Kubernetes Security',
+ 'RBAC, Pod Security Admission, network policy, supply-chain and runtime hardening — a substantial existing CKS-style scenario bank (22 scenarios) not yet wired into a module — Phase 6B.',
+ 9, '{}', '{root-06-kubernetes-application-workloads}', NULL, 'planned'),
+('root-10-kubernetes-troubleshooting-observability', 'root-kubernetes-foundations', 'Kubernetes Troubleshooting & Observability',
+ 'Reading logs, exec/cp into containers, node scheduling, and diagnosing real failures — health probes are this course''s gold-standard module.',
+ 10, '{"Diagnose a Pod stuck in a bad state using kubectl and logs","Explain liveness, readiness, and startup probes and how misconfiguring them causes real outages"}', '{root-06-kubernetes-application-workloads}', 5, 'partial'),
+('root-11-devops-platform-engineering', 'root-kubernetes-foundations', 'DevOps & Platform Engineering Foundations',
+ 'CI/CD, infrastructure as code, and GitOps principles. No lab content exists in this repository yet.',
+ 11, '{}', '{root-10-kubernetes-troubleshooting-observability}', NULL, 'planned'),
+('root-12-real-ops', 'root-kubernetes-foundations', 'RootNode Real Ops',
+ 'RootNode-authored incident scenarios — operate and recover systems the way a real on-call engineer would, not textbook exercises. The existing "RootNode: Real Ops" curriculum stage.',
+ 12, '{"Recover a cluster from a resource-exhaustion incident","Diagnose and fix a broken deployment without being told what''s wrong","Apply resource defaults that prevent a class of outage from recurring"}', '{root-10-kubernetes-troubleshooting-observability}', 3, 'partial'),
+('root-capstone', 'root-kubernetes-foundations', 'ROOT Capstone — Operate and Recover a Production-Like Environment',
+ 'The existing RootNode Capstone assessment, combining skills from every stage into one operational evaluation.',
+ 13, '{"Operate a Kubernetes environment under exam conditions without step-by-step guidance"}', '{root-12-real-ops}', 2, 'partial')
+ON CONFLICT (course_id) DO NOTHING;
+
+INSERT INTO course_modules (module_id, course_id, title, description, sequence, objectives, prerequisites, estimated_duration_minutes, status) VALUES
+('root-05-m01-pods-and-kubectl-basics', 'root-05-kubernetes-foundations', 'Pods & kubectl Basics',
+ 'The 20 scenarios in the existing "Foundation" curriculum stage, as disposable-Lab activities. No teaching lesson content authored yet — Phase 6B.',
+ 1, '{}', '{}', NULL, 'partial'),
+('root-06-m01-deployments-and-workloads', 'root-06-kubernetes-application-workloads', 'Deployments & Workloads',
+ 'The 8 scenarios in the existing "Workloads" curriculum stage, as disposable-Lab activities. No teaching lesson content authored yet — Phase 6B.',
+ 1, '{}', '{}', NULL, 'partial'),
+('root-07-m01-services-and-networking', 'root-07-kubernetes-networking-config', 'Services & Networking',
+ 'The 2 scenarios in the existing "Networking" curriculum stage, as disposable-Lab activities. No teaching lesson content authored yet — Phase 6B.',
+ 1, '{}', '{}', NULL, 'partial'),
+('root-07-m02-configuration-and-secrets', 'root-07-kubernetes-networking-config', 'Configuration & Secrets',
+ 'The 5 scenarios in the existing "Configuration" curriculum stage, as disposable-Lab activities. No teaching lesson content authored yet — Phase 6B.',
+ 2, '{}', '{}', NULL, 'partial'),
+('root-10-m01-health-probes-and-troubleshooting', 'root-10-kubernetes-troubleshooting-observability', 'Kubernetes Health Probes & Troubleshooting',
+ 'The Phase 6A gold-standard module: liveness/readiness/startup probe concepts taught BEFORE the student is asked to fix a real probe misconfiguration in rootnode-probe-port-mismatch. See docs/COURSE_AUTHORING_STANDARD.md — this module is the template for all future RootNode lesson authoring.',
+ 1, '{"Explain why Kubernetes health checks exist and what problem each probe type solves","Distinguish liveness, readiness, and startup probes and choose the right one","Diagnose a probe misconfiguration from Pod status and events, not guesswork"}',
+ '{root-05-m01-pods-and-kubectl-basics}', 75, 'ready'),
+('root-10-m02-general-troubleshooting', 'root-10-kubernetes-troubleshooting-observability', 'General Troubleshooting',
+ 'The 5 scenarios in the existing "Troubleshooting" curriculum stage, as disposable-Lab activities. No teaching lesson content authored yet — Phase 6B.',
+ 2, '{}', '{root-10-m01-health-probes-and-troubleshooting}', NULL, 'partial'),
+('root-12-m01-real-ops-incidents', 'root-12-real-ops', 'Real Ops Incidents',
+ 'The 4 scenarios in the existing "RootNode: Real Ops" curriculum stage, as disposable-Lab activities. rootnode-probe-port-mismatch also appears here — deliberate reuse: the gold module teaches the concept in depth, this module exercises it again alongside three other unrelated incident types, the same way the RootNode Capstone pool also reuses it. No teaching lesson content authored yet — Phase 6B.',
+ 1, '{}', '{root-10-m01-health-probes-and-troubleshooting}', NULL, 'partial'),
+('root-capstone-m01-operate-and-recover', 'root-capstone', 'Operate and Recover',
+ 'The existing RootNode Capstone assessment (90 minutes, mixed required/random incident pool). No capstone orientation/briefing lesson authored yet — Phase 6B.',
+ 1, '{}', '{root-12-m01-real-ops-incidents}', 90, 'partial')
+ON CONFLICT (module_id) DO NOTHING;
+
+-- ── Gold-standard module activities (root-10-m01-health-probes-and-troubleshooting) ──────────
+-- Content lives in content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/
+-- — see docs/COURSE_CONTENT_MODEL.md for the Markdown convention these files follow.
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-10-m01-a01-lesson-health-check-concepts', 'root-10-m01-health-probes-and-troubleshooting', 1, 'lesson',
+ 'Why Health Checks Exist & Probe Types',
+ 'content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/01-lesson-health-check-concepts.md',
+ NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-10-m01-a02-demonstration-probes-in-action', 'root-10-m01-health-probes-and-troubleshooting', 2, 'demonstration',
+ 'Demonstration: Probes in Action',
+ 'content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/02-demonstration-probes-in-action.md',
+ NULL, NULL, 'manual_marker', 10, 'ready'),
+('root-10-m01-a03-knowledge-check', 'root-10-m01-health-probes-and-troubleshooting', 3, 'knowledge_check',
+ 'Knowledge Check: Health Probes',
+ 'content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/03-knowledge-check.md',
+ NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-10-m01-a04-guided-exercise-readiness-probe', 'root-10-m01-health-probes-and-troubleshooting', 4, 'guided_exercise',
+ 'Guided Exercise: Configure a Readiness Probe',
+ 'content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/04-guided-exercise-readiness-probe.md',
+ NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-10-m01-a05-lab-probe-port-mismatch', 'root-10-m01-health-probes-and-troubleshooting', 5, 'lab',
+ 'Launch Lab: rootnode-probe-port-mismatch',
+ 'content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/05-lab-intro.md',
+ 'rootnode-probe-port-mismatch', NULL, 'auto_scenario', 20, 'ready'),
+('root-10-m01-a06-reflection-real-ops-takeaway', 'root-10-m01-health-probes-and-troubleshooting', 6, 'reflection',
+ 'Root-Cause Reflection & Real Ops Takeaway',
+ 'content/root/root-10-kubernetes-troubleshooting-observability/m01-health-probes/06-reflection-real-ops-takeaway.md',
+ NULL, NULL, 'manual_marker', 10, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ── Mechanically-mapped lab activities for the other partial modules ────────────────────────
+-- Generated 1:1 from scenarios/rootnode-path.json's existing stage scenario_ids (see
+-- docs/ROOT_CURRICULUM_INVENTORY.md) — no new lab content invented, titles taken from each
+-- scenario's own JSON. Estimated duration is a rough heuristic from the scenario's declared
+-- difficulty (15/20/30 min); refine once real per-activity completion-time data exists.
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status, visibility, version) VALUES
+('root-05-m01-pods-and-kubectl-basics-a01-pod-basics-mcq', 'root-05-m01-pods-and-kubectl-basics', 1, 'lab', 'Lab: Pod Lifecycle States', NULL, 'pod-basics-mcq', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a02-kubectl-essentials-mcq', 'root-05-m01-pods-and-kubectl-basics', 2, 'lab', 'Lab: Essential kubectl Commands', NULL, 'kubectl-essentials-mcq', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a03-labels-selectors-mcq', 'root-05-m01-pods-and-kubectl-basics', 3, 'lab', 'Lab: Labels and Selectors', NULL, 'labels-selectors-mcq', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a04-init-containers-mcq', 'root-05-m01-pods-and-kubectl-basics', 4, 'lab', 'Lab: Init Containers Behaviour', NULL, 'init-containers-mcq', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a05-namespaces-basics', 'root-05-m01-pods-and-kubectl-basics', 5, 'lab', 'Lab: Working with Namespaces', NULL, 'namespaces-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a06-multi-container-pod-basics', 'root-05-m01-pods-and-kubectl-basics', 6, 'lab', 'Lab: Create a Multi-Container Pod', NULL, 'multi-container-pod-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a07-pod-labeling-basics', 'root-05-m01-pods-and-kubectl-basics', 7, 'lab', 'Lab: Labelling Resources', NULL, 'pod-labeling-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a08-jsonpath-basics', 'root-05-m01-pods-and-kubectl-basics', 8, 'lab', 'Lab: JSONPath Data Extraction', NULL, 'jsonpath-basics', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a09-dry-run-manifest-basics', 'root-05-m01-pods-and-kubectl-basics', 9, 'lab', 'Lab: Generating YAML Manifests', NULL, 'dry-run-manifest-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a10-delete-by-label-basics', 'root-05-m01-pods-and-kubectl-basics', 10, 'lab', 'Lab: Bulk Deletion by Label', NULL, 'delete-by-label-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a11-annotate-resource-basics', 'root-05-m01-pods-and-kubectl-basics', 11, 'lab', 'Lab: Annotating Kubernetes Resources', NULL, 'annotate-resource-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a12-init-container-task-basics', 'root-05-m01-pods-and-kubectl-basics', 12, 'lab', 'Lab: Pod with Init Container', NULL, 'init-container-task-basics', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a13-restart-policy-mcq', 'root-05-m01-pods-and-kubectl-basics', 13, 'lab', 'Lab: Pod Restart Policies', NULL, 'restart-policy-mcq', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a14-kubectl-output-format-mcq', 'root-05-m01-pods-and-kubectl-basics', 14, 'lab', 'Lab: kubectl Output Formats', NULL, 'kubectl-output-format-mcq', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a15-kubectl-explain-basics', 'root-05-m01-pods-and-kubectl-basics', 15, 'lab', 'Lab: Exploring the API with kubectl explain', NULL, 'kubectl-explain-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a16-kubectl-patch-basics', 'root-05-m01-pods-and-kubectl-basics', 16, 'lab', 'Lab: Patching Resources with kubectl patch', NULL, 'kubectl-patch-basics', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a17-field-selector-basics', 'root-05-m01-pods-and-kubectl-basics', 17, 'lab', 'Lab: Filtering Resources with Field Selectors', NULL, 'field-selector-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a18-sort-by-basics', 'root-05-m01-pods-and-kubectl-basics', 18, 'lab', 'Lab: Sorting kubectl Output', NULL, 'sort-by-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a19-kubectl-diff-basics', 'root-05-m01-pods-and-kubectl-basics', 19, 'lab', 'Lab: Previewing Changes with kubectl diff', NULL, 'kubectl-diff-basics', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-05-m01-pods-and-kubectl-basics-a20-static-pods-mcq', 'root-05-m01-pods-and-kubectl-basics', 20, 'lab', 'Lab: Static Pods in Kubernetes', NULL, 'static-pods-mcq', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-06-m01-deployments-and-workloads-a01-deploy-nginx', 'root-06-m01-deployments-and-workloads', 1, 'lab', 'Lab: Deploy and Expose Nginx', NULL, 'deploy-nginx', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-06-m01-deployments-and-workloads-a02-scale-deployment', 'root-06-m01-deployments-and-workloads', 2, 'lab', 'Lab: Scaling a Deployment', NULL, 'scale-deployment', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-06-m01-deployments-and-workloads-a03-rolling-update-task', 'root-06-m01-deployments-and-workloads', 3, 'lab', 'Lab: Perform a Rolling Update', NULL, 'rolling-update-task', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-06-m01-deployments-and-workloads-a04-liveness-probe-task', 'root-06-m01-deployments-and-workloads', 4, 'lab', 'Lab: Configure a Liveness Probe', NULL, 'liveness-probe-task', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-06-m01-deployments-and-workloads-a05-jobs-cronjobs-mcq', 'root-06-m01-deployments-and-workloads', 5, 'lab', 'Lab: Jobs vs CronJobs', NULL, 'jobs-cronjobs-mcq', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-06-m01-deployments-and-workloads-a06-daemonset-mcq', 'root-06-m01-deployments-and-workloads', 6, 'lab', 'Lab: Understanding DaemonSets', NULL, 'daemonset-mcq', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-06-m01-deployments-and-workloads-a07-edit-deployment-basics', 'root-06-m01-deployments-and-workloads', 7, 'lab', 'Lab: Updating Deployments', NULL, 'edit-deployment-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-06-m01-deployments-and-workloads-a08-deployment-strategy-mcq', 'root-06-m01-deployments-and-workloads', 8, 'lab', 'Lab: Deployment Update Strategies', NULL, 'deployment-strategy-mcq', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-07-m01-services-and-networking-a01-services-mcq', 'root-07-m01-services-and-networking', 1, 'lab', 'Lab: Kubernetes Service Types', NULL, 'services-mcq', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-07-m01-services-and-networking-a02-expose-service-basics', 'root-07-m01-services-and-networking', 2, 'lab', 'Lab: Exposing an Application', NULL, 'expose-service-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-07-m02-configuration-and-secrets-a01-configmap-volume', 'root-07-m02-configuration-and-secrets', 1, 'lab', 'Lab: Mount ConfigMap as Volume', NULL, 'configmap-volume', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-07-m02-configuration-and-secrets-a02-resource-limits-task', 'root-07-m02-configuration-and-secrets', 2, 'lab', 'Lab: Resource Requests and Limits', NULL, 'resource-limits-task', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-07-m02-configuration-and-secrets-a03-env-vars-configmap', 'root-07-m02-configuration-and-secrets', 3, 'lab', 'Lab: Environment Variables from ConfigMap', NULL, 'env-vars-configmap', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-07-m02-configuration-and-secrets-a04-secrets-basics', 'root-07-m02-configuration-and-secrets', 4, 'lab', 'Lab: Creating and Using Secrets', NULL, 'secrets-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-07-m02-configuration-and-secrets-a05-pod-env-vars-inline', 'root-07-m02-configuration-and-secrets', 5, 'lab', 'Lab: Pod with Inline Environment Variables', NULL, 'pod-env-vars-inline', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-10-m02-general-troubleshooting-a01-extract-logs-basics', 'root-10-m02-general-troubleshooting', 1, 'lab', 'Lab: Extract Container Logs', NULL, 'extract-logs-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-10-m02-general-troubleshooting-a02-kubectl-cp-basics', 'root-10-m02-general-troubleshooting', 2, 'lab', 'Lab: Copy Files to Containers', NULL, 'kubectl-cp-basics', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-10-m02-general-troubleshooting-a03-exec-command-basics', 'root-10-m02-general-troubleshooting', 3, 'lab', 'Lab: Execute Commands in Pods', NULL, 'exec-command-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-10-m02-general-troubleshooting-a04-node-cordon-basics', 'root-10-m02-general-troubleshooting', 4, 'lab', 'Lab: Cordoning and Uncordoning a Node', NULL, 'node-cordon-basics', NULL, 'auto_scenario', 15, 'ready', 'published', 1),
+('root-10-m02-general-troubleshooting-a05-pod-node-assignment-mcq', 'root-10-m02-general-troubleshooting', 5, 'lab', 'Lab: Assigning Pods to Nodes', NULL, 'pod-node-assignment-mcq', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-12-m01-real-ops-incidents-a01-rootnode-runaway-monitor', 'root-12-m01-real-ops-incidents', 1, 'lab', 'Lab: Recover the Monitoring Stack', NULL, 'rootnode-runaway-monitor', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-12-m01-real-ops-incidents-a02-broken-deployment', 'root-12-m01-real-ops-incidents', 2, 'lab', 'Lab: Debug a Failing Deployment', NULL, 'broken-deployment', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-12-m01-real-ops-incidents-a03-rootnode-probe-port-mismatch', 'root-12-m01-real-ops-incidents', 3, 'lab', 'Lab: Stuck Not-Ready: The Probe Port Mismatch', NULL, 'rootnode-probe-port-mismatch', NULL, 'auto_scenario', 20, 'ready', 'published', 1),
+('root-12-m01-real-ops-incidents-a04-rootnode-enforce-limits', 'root-12-m01-real-ops-incidents', 4, 'lab', 'Lab: Stop the Next Outage: Enforce Resource Defaults', NULL, 'rootnode-enforce-limits', NULL, 'auto_scenario', 30, 'ready', 'published', 1)
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ── Capstone activity (references the existing assessment engine, no duplicate definition) ──
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-capstone-m01-a01-capstone', 'root-capstone-m01-operate-and-recover', 1, 'capstone', 'RootNode Capstone', NULL, NULL, 'rootnode-capstone', 'auto_assessment', 90, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;

platform/api/migrations/023_phase6b_curriculum.sql

@@ -0,0 +1,332 @@
+-- Phase 6B — curriculum authoring & coverage expansion. Additive on top of Phase 6A's
+-- 022_course_content.sql: new teaching modules for ROOT 05/06/07/08/09/10/12/Capstone, built
+-- from real, previously-unwired scenario content (see docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md
+-- for the evidence and reasoning behind every placement). No existing row is deleted; a small
+-- number of existing rows have their `sequence`/`prerequisites` updated so a new teaching
+-- module sits in front of the bare-lab bank it supersedes as the "front door" — never their
+-- scenario_id/activity_type/completion_behavior, so no student's derived completion state
+-- changes meaning. See docs/COURSE_CONTENT_MODEL.md §"content revision" for what does and
+-- doesn't require this kind of change.
+
+-- ── is_required: Phase 6B §18/§27's optional-vs-required distinction. Defaults true, so every
+-- Phase 6A activity is unaffected (required, as it always implicitly was) — this is additive,
+-- not a redefinition. An optional activity (independent-practice duplicates, advanced/CKS-exam-
+-- style extras — see docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md's ADVANCED/INDEPENDENT
+-- classifications) still counts toward a module's percent_complete display but NOT toward
+-- whether the module is considered complete — see course-progress.js's totals().
+ALTER TABLE module_activities ADD COLUMN IF NOT EXISTS is_required BOOLEAN NOT NULL DEFAULT true;
+
+-- ── Course status: ROOT 08/09 move from PLANNED to PARTIAL — real modules exist now ─────────
+UPDATE courses SET status = 'partial', updated_at = now() WHERE course_id IN ('root-08-kubernetes-storage-scheduling', 'root-09-kubernetes-security');
+
+-- ── Resequencing: new teaching modules become the front door; existing bare-lab banks move
+-- behind them. Sequence/prerequisites only — activities inside the existing modules are
+-- untouched. ──────────────────────────────────────────────────────────────────────────────
+UPDATE course_modules SET sequence = 2, prerequisites = '{root-05-m00-kubernetes-mental-model}', version = version + 1, updated_at = now()
+  WHERE module_id = 'root-05-m01-pods-and-kubectl-basics';
+UPDATE course_modules SET sequence = 3, prerequisites = '{root-06-m02-deployments-scaling-updates}', version = version + 1, updated_at = now()
+  WHERE module_id = 'root-06-m01-deployments-and-workloads';
+UPDATE course_modules SET sequence = 3, prerequisites = '{root-07-m03-services-and-service-discovery}', version = version + 1, updated_at = now()
+  WHERE module_id = 'root-07-m01-services-and-networking';
+-- root-07-m02 (configuration bank) is intentionally left UNGATED (no new configuration-teaching
+-- module was authored this phase — an honest PARTIAL gap, see
+-- docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md) but still needs to move behind the new
+-- teaching modules in display order, to avoid colliding with m04's sequence=2.
+UPDATE course_modules SET sequence = 4, version = version + 1, updated_at = now()
+  WHERE module_id = 'root-07-m02-configuration-and-secrets';
+UPDATE course_modules SET sequence = 3, prerequisites = '{root-10-m03-troubleshooting-framework}', version = version + 1, updated_at = now()
+  WHERE module_id = 'root-10-m02-general-troubleshooting';
+
+INSERT INTO course_modules (module_id, course_id, title, description, sequence, objectives, prerequisites, estimated_duration_minutes, status) VALUES
+('root-05-m00-kubernetes-mental-model', 'root-05-kubernetes-foundations', 'The Kubernetes Mental Model & Core Objects',
+ 'What Kubernetes actually solves, the control-plane/worker/desired-state model, and Pods/Namespaces/labels through kubectl — the real front door to ROOT 05, taught before the bare kubectl-fluency lab bank.',
+ 1, '{"Explain what problem Kubernetes solves and why running containers by hand does not scale","Describe the control-plane/worker split and what \"desired state\" means in practice","Navigate Pods, Namespaces, and labels with kubectl confidently"}',
+ '{}', 45, 'ready'),
+
+('root-06-m02-deployments-scaling-updates', 'root-06-kubernetes-application-workloads', 'Deployments, Scaling & Updates',
+ 'Why Deployments/ReplicaSets exist, how a rolling update actually progresses, and how to reason about rollback — taught before the bare Deployments lab bank.',
+ 1, '{"Explain why a Deployment manages Pods instead of creating them directly","Perform and reason about a rolling update in progress","Explain what a rollback actually restores and when to use one"}',
+ '{root-05-m00-kubernetes-mental-model}', 55, 'ready'),
+('root-06-m03-jobs-cronjobs-daemonsets', 'root-06-kubernetes-application-workloads', 'Jobs, CronJobs & DaemonSets',
+ 'Distinguishing one-shot Jobs, scheduled CronJobs, and per-node DaemonSets from long-running Deployments.',
+ 2, '{"Choose the right workload primitive for a one-shot task, a scheduled task, and a per-node agent","Explain why a Job differs from a Deployment in restart/completion semantics"}',
+ '{root-06-m02-deployments-scaling-updates}', 30, 'partial'),
+
+('root-07-m03-services-and-service-discovery', 'root-07-kubernetes-networking-config', 'Services & Service Discovery',
+ 'The Service/Endpoints/DNS request path and choosing the right Service type — taught before the bare Services lab bank.',
+ 1, '{"Trace how a request actually reaches a Pod through a Service","Choose ClusterIP vs NodePort correctly for a given requirement","Explain why a Service with zero endpoints looks like network failure from outside"}',
+ '{root-06-m02-deployments-scaling-updates}', 45, 'ready'),
+('root-07-m04-ingress-networkpolicy-foundations', 'root-07-kubernetes-networking-config', 'Ingress & NetworkPolicy Foundations',
+ 'How Ingress routes external traffic, and what a NetworkPolicy architecturally does (the security posture comes later, in ROOT 09).',
+ 2, '{"Explain how Ingress differs from a Service and why it exists","Describe what a NetworkPolicy actually controls at the architectural level"}',
+ '{root-07-m03-services-and-service-discovery}', 30, 'partial'),
+
+('root-08-m01-storage-fundamentals', 'root-08-kubernetes-storage-scheduling', 'Storage Fundamentals',
+ 'Ephemeral vs. persistent storage, and how PersistentVolumes/PersistentVolumeClaims/StorageClasses fit together.',
+ 1, '{"Explain the difference between ephemeral and persistent storage in Kubernetes","Describe how a PVC binds to a PV, directly or via dynamic provisioning"}',
+ '{root-07-m03-services-and-service-discovery}', 35, 'partial'),
+('root-08-m02-scheduling-resource-governance', 'root-08-kubernetes-storage-scheduling', 'Scheduling & Resource Governance',
+ 'How the scheduler places Pods, and how quotas/limits/priority/disruption budgets shape that placement.',
+ 2, '{"Explain how taints/tolerations and affinity influence scheduling decisions","Explain why a PodDisruptionBudget matters during a voluntary disruption","Describe what a ResourceQuota/LimitRange enforces at the namespace level"}',
+ '{root-08-m01-storage-fundamentals}', 40, 'partial'),
+
+('root-09-m01-security-model-and-securitycontext', 'root-09-kubernetes-security', 'Security Model & SecurityContext',
+ 'Defense in depth, least privilege, and hardening a Pod with SecurityContext (non-root, capabilities, read-only filesystem).',
+ 1, '{"Explain defense in depth and least privilege as applied to a running Pod","Configure a Pod/container SecurityContext to run non-root with a read-only filesystem and no unnecessary Linux capabilities"}',
+ '{root-06-m02-deployments-scaling-updates}', 50, 'ready'),
+('root-09-m02-serviceaccounts-and-rbac', 'root-09-kubernetes-security', 'ServiceAccounts & RBAC',
+ 'Identity for workloads and least-privilege permissions via Roles/ClusterRoles.',
+ 2, '{"Explain why a Pod needs its own identity separate from the human operating it","Write a least-privilege Role/RoleBinding for a specific, narrow permission"}',
+ '{root-09-m01-security-model-and-securitycontext}', 40, 'partial'),
+('root-09-m03-network-and-supplychain-security', 'root-09-kubernetes-security', 'Network & Supply Chain Security',
+ 'NetworkPolicy as a security control (not just an architecture concept), image/registry trust, and TLS ingress.',
+ 3, '{"Apply a default-deny NetworkPolicy and open only the access a workload actually needs","Explain why an image-pull secret and a trusted registry matter for supply-chain security"}',
+ '{root-09-m02-serviceaccounts-and-rbac,root-07-m04-ingress-networkpolicy-foundations}', 40, 'partial'),
+('root-09-m04-cluster-hardening-and-runtime', 'root-09-kubernetes-security', 'Cluster Hardening & Runtime Security',
+ 'Pod Security Admission and a survey of cluster-hardening/runtime-sandboxing topics — deliberately advanced/optional, not daily-driver core.',
+ 4, '{"Explain what Pod Security Admission enforces at the namespace level and how it differs from the old PodSecurityPolicy"}',
+ '{root-09-m03-network-and-supplychain-security}', 25, 'partial'),
+
+('root-10-m03-troubleshooting-framework', 'root-10-kubernetes-troubleshooting-observability', 'The RootNode Troubleshooting Framework',
+ 'A repeatable framework — Observe, Gather Evidence, Form Hypothesis, Test, Repair, Validate, Prevent Recurrence — applied to a CrashLoopBackOff and a broken Service.',
+ 2, '{"Apply a repeatable troubleshooting framework instead of guessing under pressure","Diagnose a CrashLoopBackOff from evidence, not assumption","Diagnose a broken Service-to-Pod selector mismatch"}',
+ '{root-10-m01-health-probes-and-troubleshooting}', 40, 'partial'),
+
+('root-capstone-m02-capstone-readiness', 'root-capstone', 'Capstone Readiness',
+ 'What the RootNode Capstone measures, what it requires, how the timed/randomized draw works, and how to manage your time — without publishing the draw or the answers.',
+ 1, '{"Explain what skills the RootNode Capstone measures and why","Describe how the timed, partially-randomized scenario draw works","Apply the RootNode troubleshooting framework under time pressure"}',
+ '{}', 20, 'ready')
+ON CONFLICT (module_id) DO NOTHING;
+
+-- The existing capstone assessment module keeps its original sequence position (2) relative to
+-- the new readiness module (1) — readiness comes first, matching that it now needs no
+-- prerequisite of its own (the course-level root-12-real-ops -> root-capstone chain still
+-- gates entry into this course at all; the actual capstone START is gated server-side by
+-- curriculum-rules.js's unlock_rule regardless of whether this readiness module was viewed —
+-- see docs/ROOT_CAPSTONE_READINESS.md for why those two gates are deliberately independent).
+UPDATE course_modules SET sequence = 2 WHERE module_id = 'root-capstone-m01-operate-and-recover';
+
+-- ═══════════════════════════════════════════════════════════════════════════════════════════
+-- New module_activities — gold-standard modules (lesson+demo+knowledge_check+guided_exercise+
+-- lab+reflection) for root-05-m00, root-06-m02, root-07-m03, root-09-m01. PARTIAL modules get
+-- lesson+knowledge_check(+lab) only, honestly, per docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md.
+-- ═══════════════════════════════════════════════════════════════════════════════════════════
+
+-- ROOT 05 m00 — 6 activities
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-05-m00-a01-lesson-mental-model', 'root-05-m00-kubernetes-mental-model', 1, 'lesson', 'What Kubernetes Solves & the Desired-State Model',
+ 'content/root/root-05-kubernetes-foundations/m00-mental-model/01-lesson-mental-model.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-05-m00-a02-demonstration-desired-state', 'root-05-m00-kubernetes-mental-model', 2, 'demonstration', 'Demonstration: Desired State Reconciliation',
+ 'content/root/root-05-kubernetes-foundations/m00-mental-model/02-demonstration-desired-state.md', NULL, NULL, 'manual_marker', 10, 'ready'),
+('root-05-m00-a03-knowledge-check', 'root-05-m00-kubernetes-mental-model', 3, 'knowledge_check', 'Knowledge Check: The Kubernetes Mental Model',
+ 'content/root/root-05-kubernetes-foundations/m00-mental-model/03-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-05-m00-a04-guided-exercise-namespaces', 'root-05-m00-kubernetes-mental-model', 4, 'guided_exercise', 'Guided Exercise: Planning a Namespace Layout',
+ 'content/root/root-05-kubernetes-foundations/m00-mental-model/04-guided-exercise-namespaces.md', NULL, NULL, 'manual_marker', 10, 'ready'),
+('root-05-m00-a05-lab-namespaces-basics', 'root-05-m00-kubernetes-mental-model', 5, 'lab', 'Launch Lab: Working with Namespaces',
+ 'content/root/root-05-kubernetes-foundations/m00-mental-model/05-lab-intro.md', 'namespaces-basics', NULL, 'auto_scenario', 15, 'ready'),
+('root-05-m00-a06-reflection', 'root-05-m00-kubernetes-mental-model', 6, 'reflection', 'Reflection: Why Desired State Matters in Production',
+ 'content/root/root-05-kubernetes-foundations/m00-mental-model/06-reflection.md', NULL, NULL, 'manual_marker', 10, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 06 m02 — 6 activities
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-06-m02-a01-lesson-deployments', 'root-06-m02-deployments-scaling-updates', 1, 'lesson', 'Why Deployments Exist & How a Rolling Update Progresses',
+ 'content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/01-lesson-deployments.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-06-m02-a02-demonstration-rollout', 'root-06-m02-deployments-scaling-updates', 2, 'demonstration', 'Demonstration: Watching a Rollout, Good and Bad',
+ 'content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/02-demonstration-rollout.md', NULL, NULL, 'manual_marker', 10, 'ready'),
+('root-06-m02-a03-knowledge-check', 'root-06-m02-deployments-scaling-updates', 3, 'knowledge_check', 'Knowledge Check: Deployments & Rollouts',
+ 'content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/03-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-06-m02-a04-guided-exercise-rollout-strategy', 'root-06-m02-deployments-scaling-updates', 4, 'guided_exercise', 'Guided Exercise: Planning a Safe Rollout Strategy',
+ 'content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/04-guided-exercise-rollout-strategy.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-06-m02-a05-lab-rolling-update', 'root-06-m02-deployments-scaling-updates', 5, 'lab', 'Launch Lab: Perform a Rolling Update',
+ 'content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/05-lab-intro.md', 'rolling-update-task', NULL, 'auto_scenario', 15, 'ready'),
+('root-06-m02-a05b-lab-deployment-rollback', 'root-06-m02-deployments-scaling-updates', 6, 'lab', 'Lab: Rolling Back a Deployment', NULL, 'deployment-rollback', NULL, 'auto_scenario', 15, 'ready'),
+('root-06-m02-a06-reflection', 'root-06-m02-deployments-scaling-updates', 7, 'reflection', 'Reflection: Rollback Is a Plan, Not a Panic Button',
+ 'content/root/root-06-kubernetes-application-workloads/m02-deployments-scaling-updates/06-reflection.md', NULL, NULL, 'manual_marker', 10, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 06 m03 — 4 activities (PARTIAL: lesson + knowledge_check + two labs)
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-06-m03-a01-lesson-jobs-cronjobs-daemonsets', 'root-06-m03-jobs-cronjobs-daemonsets', 1, 'lesson', 'Jobs, CronJobs, and DaemonSets: The Other Workload Shapes',
+ 'content/root/root-06-kubernetes-application-workloads/m03-jobs-cronjobs-daemonsets/01-lesson-jobs-cronjobs-daemonsets.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-06-m03-a02-knowledge-check', 'root-06-m03-jobs-cronjobs-daemonsets', 2, 'knowledge_check', 'Knowledge Check: Choosing the Right Workload Primitive',
+ 'content/root/root-06-kubernetes-application-workloads/m03-jobs-cronjobs-daemonsets/02-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-06-m03-a03-lab-job-task', 'root-06-m03-jobs-cronjobs-daemonsets', 3, 'lab', 'Lab: Create a One-Shot Job', NULL, 'job-task', NULL, 'auto_scenario', 15, 'ready'),
+('root-06-m03-a04-lab-cronjob-task', 'root-06-m03-jobs-cronjobs-daemonsets', 4, 'lab', 'Lab: Create a CronJob', NULL, 'cronjob-task', NULL, 'auto_scenario', 15, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 07 m03 — 6 activities
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-07-m03-a01-lesson-services', 'root-07-m03-services-and-service-discovery', 1, 'lesson', 'The Service/Endpoints/DNS Request Path',
+ 'content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/01-lesson-services.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-07-m03-a02-demonstration-zero-endpoints', 'root-07-m03-services-and-service-discovery', 2, 'demonstration', 'Demonstration: A Service With Zero Endpoints',
+ 'content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/02-demonstration-zero-endpoints.md', NULL, NULL, 'manual_marker', 10, 'ready'),
+('root-07-m03-a03-knowledge-check', 'root-07-m03-services-and-service-discovery', 3, 'knowledge_check', 'Knowledge Check: Services & Service Discovery',
+ 'content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/03-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-07-m03-a04-guided-exercise-service-type', 'root-07-m03-services-and-service-discovery', 4, 'guided_exercise', 'Guided Exercise: Choosing the Right Service Type',
+ 'content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/04-guided-exercise-service-type.md', NULL, NULL, 'manual_marker', 10, 'ready'),
+('root-07-m03-a05-lab-expose-service', 'root-07-m03-services-and-service-discovery', 5, 'lab', 'Launch Lab: Exposing an Application',
+ 'content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/05-lab-intro.md', 'expose-service-basics', NULL, 'auto_scenario', 15, 'ready'),
+('root-07-m03-a06-reflection', 'root-07-m03-services-and-service-discovery', 6, 'reflection', 'Reflection: Service Discovery Is Infrastructure, Not Magic',
+ 'content/root/root-07-kubernetes-networking-config/m03-services-and-service-discovery/06-reflection.md', NULL, NULL, 'manual_marker', 10, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 07 m01 (existing bare bank) — extend with the two newly-wired networking scenarios
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-07-m01-a03-nodeport-task', 'root-07-m01-services-and-networking', 3, 'lab', 'Lab: Expose a Deployment via NodePort', NULL, 'nodeport-task', NULL, 'auto_scenario', 15, 'ready'),
+('root-07-m01-a04-dns-resolution-mcq', 'root-07-m01-services-and-networking', 4, 'lab', 'Lab: Kubernetes DNS Resolution', NULL, 'dns-resolution-mcq', NULL, 'auto_scenario', 15, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 07 m04 — 4 activities (PARTIAL)
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-07-m04-a01-lesson-ingress-networkpolicy', 'root-07-m04-ingress-networkpolicy-foundations', 1, 'lesson', 'Ingress and NetworkPolicy: What They Architecturally Do',
+ 'content/root/root-07-kubernetes-networking-config/m04-ingress-networkpolicy-foundations/01-lesson-ingress-networkpolicy.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-07-m04-a02-knowledge-check', 'root-07-m04-ingress-networkpolicy-foundations', 2, 'knowledge_check', 'Knowledge Check: Ingress & NetworkPolicy Foundations',
+ 'content/root/root-07-kubernetes-networking-config/m04-ingress-networkpolicy-foundations/02-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-07-m04-a03-lab-ingress-task', 'root-07-m04-ingress-networkpolicy-foundations', 3, 'lab', 'Lab: Create an Ingress Resource', NULL, 'ingress-task', NULL, 'auto_scenario', 20, 'ready'),
+('root-07-m04-a04-lab-network-policy', 'root-07-m04-ingress-networkpolicy-foundations', 4, 'lab', 'Lab: Isolate Traffic with NetworkPolicy', NULL, 'network-policy', NULL, 'auto_scenario', 30, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 08 m01 — 4 activities (PARTIAL)
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-08-m01-a01-lesson-storage-fundamentals', 'root-08-m01-storage-fundamentals', 1, 'lesson', 'Ephemeral vs. Persistent Storage',
+ 'content/root/root-08-kubernetes-storage-scheduling/m01-storage-fundamentals/01-lesson-storage-fundamentals.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-08-m01-a02-knowledge-check', 'root-08-m01-storage-fundamentals', 2, 'knowledge_check', 'Knowledge Check: Storage Fundamentals',
+ 'content/root/root-08-kubernetes-storage-scheduling/m01-storage-fundamentals/02-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-08-m01-a03-lab-emptydir', 'root-08-m01-storage-fundamentals', 3, 'lab', 'Lab: Shared emptyDir Volume Between Containers', NULL, 'emptydir-pod', NULL, 'auto_scenario', 15, 'ready'),
+('root-08-m01-a04-lab-pv-pvc', 'root-08-m01-storage-fundamentals', 4, 'lab', 'Lab: Persistent Storage with PV and PVC', NULL, 'pv-pvc-mount', NULL, 'auto_scenario', 20, 'ready'),
+('root-08-m01-a05-lab-pvc-dynamic', 'root-08-m01-storage-fundamentals', 5, 'lab', 'Lab: Dynamic PVC Provisioning', NULL, 'pvc-dynamic-task', NULL, 'auto_scenario', 20, 'ready'),
+('root-08-m01-a06-lab-storageclass', 'root-08-m01-storage-fundamentals', 6, 'lab', 'Lab: StorageClass Reclaim Policies', NULL, 'storageclass-mcq', NULL, 'auto_scenario', 15, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 08 m02 — 8 activities (PARTIAL)
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-08-m02-a01-lesson-scheduling', 'root-08-m02-scheduling-resource-governance', 1, 'lesson', 'How the Scheduler Places Pods, and How Governance Shapes It',
+ 'content/root/root-08-kubernetes-storage-scheduling/m02-scheduling-resource-governance/01-lesson-scheduling.md', NULL, NULL, 'manual_marker', 20, 'ready'),
+('root-08-m02-a02-knowledge-check', 'root-08-m02-scheduling-resource-governance', 2, 'knowledge_check', 'Knowledge Check: Scheduling & Resource Governance',
+ 'content/root/root-08-kubernetes-storage-scheduling/m02-scheduling-resource-governance/02-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-08-m02-a03-lab-node-label-selector', 'root-08-m02-scheduling-resource-governance', 3, 'lab', 'Lab: Node Labels and nodeSelector', NULL, 'node-label-selector', NULL, 'auto_scenario', 15, 'ready'),
+('root-08-m02-a04-lab-node-taint-toleration', 'root-08-m02-scheduling-resource-governance', 4, 'lab', 'Lab: Taints and Tolerations', NULL, 'node-taint-toleration', NULL, 'auto_scenario', 20, 'ready'),
+('root-08-m02-a05-lab-pod-affinity', 'root-08-m02-scheduling-resource-governance', 5, 'lab', 'Lab: Pod Affinity vs Anti-Affinity', NULL, 'pod-affinity-mcq', NULL, 'auto_scenario', 20, 'ready'),
+('root-08-m02-a06-lab-priority-class', 'root-08-m02-scheduling-resource-governance', 6, 'lab', 'Lab: Pod Priority and PriorityClass', NULL, 'priority-class-task', NULL, 'auto_scenario', 20, 'ready'),
+('root-08-m02-a07-lab-pdb', 'root-08-m02-scheduling-resource-governance', 7, 'lab', 'Lab: Configure a PodDisruptionBudget', NULL, 'pod-disruption-budget-task', NULL, 'auto_scenario', 20, 'ready'),
+('root-08-m02-a08-lab-resource-quota', 'root-08-m02-scheduling-resource-governance', 8, 'lab', 'Lab: ResourceQuota for a Namespace', NULL, 'resource-quota-ns', NULL, 'auto_scenario', 20, 'ready'),
+('root-08-m02-a09-lab-limitrange', 'root-08-m02-scheduling-resource-governance', 9, 'lab', 'Lab: LimitRange for Default Container Limits', NULL, 'limitrange-task', NULL, 'auto_scenario', 20, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 09 m01 — 8 activities (READY: full gold-standard sequence + independent/guided/advanced practice)
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-09-m01-a01-lesson-security-model', 'root-09-m01-security-model-and-securitycontext', 1, 'lesson', 'Defense in Depth & the Kubernetes Security Model',
+ 'content/root/root-09-kubernetes-security/m01-security-model-and-securitycontext/01-lesson-security-model.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-09-m01-a02-demonstration-securitycontext', 'root-09-m01-security-model-and-securitycontext', 2, 'demonstration', 'Demonstration: A Pod Before and After Hardening',
+ 'content/root/root-09-kubernetes-security/m01-security-model-and-securitycontext/02-demonstration-securitycontext.md', NULL, NULL, 'manual_marker', 10, 'ready'),
+('root-09-m01-a03-knowledge-check', 'root-09-m01-security-model-and-securitycontext', 3, 'knowledge_check', 'Knowledge Check: Security Model & SecurityContext',
+ 'content/root/root-09-kubernetes-security/m01-security-model-and-securitycontext/03-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-09-m01-a04-guided-exercise-hardening-plan', 'root-09-m01-security-model-and-securitycontext', 4, 'guided_exercise', 'Guided Exercise: Planning a Pod Hardening Checklist',
+ 'content/root/root-09-kubernetes-security/m01-security-model-and-securitycontext/04-guided-exercise-hardening-plan.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-09-m01-a05-lab-non-root', 'root-09-m01-security-model-and-securitycontext', 5, 'lab', 'Lab: Enforce Non-Root Container', NULL, 'cks-non-root-enforce', NULL, 'auto_scenario', 20, 'ready'),
+('root-09-m01-a06-lab-drop-capabilities', 'root-09-m01-security-model-and-securitycontext', 6, 'lab', 'Lab: Drop Linux Capabilities', NULL, 'cks-drop-capabilities', NULL, 'auto_scenario', 20, 'ready'),
+('root-09-m01-a07-lab-readonly-filesystem', 'root-09-m01-security-model-and-securitycontext', 7, 'lab', 'Lab: Read-Only Root Filesystem', NULL, 'cks-readonly-filesystem', NULL, 'auto_scenario', 15, 'ready'),
+('root-09-m01-a08-lab-pod-security-context', 'root-09-m01-security-model-and-securitycontext', 8, 'lab', 'Lab: Pod Security Context (CKS)', NULL, 'cks-pod-security-context', NULL, 'auto_scenario', 20, 'ready'),
+('root-09-m01-a09-reflection', 'root-09-m01-security-model-and-securitycontext', 9, 'reflection', 'Reflection: Least Privilege Is a Default, Not an Afterthought',
+ 'content/root/root-09-kubernetes-security/m01-security-model-and-securitycontext/09-reflection.md', NULL, NULL, 'manual_marker', 10, 'ready'),
+('root-09-m01-a10-lab-seccomp-guided', 'root-09-m01-security-model-and-securitycontext', 10, 'lab', 'Lab: Seccomp Profiles (guided practice)', NULL, 'cks-seccomp-profile', NULL, 'auto_scenario', 30, 'ready'),
+('root-09-m01-a11-lab-apparmor-advanced', 'root-09-m01-security-model-and-securitycontext', 11, 'lab', 'Lab: AppArmor Profiles (advanced/optional)', NULL, 'cks-apparmor-profile', NULL, 'auto_scenario', 30, 'ready'),
+('root-09-m01-a12-lab-pod-security-context-independent', 'root-09-m01-security-model-and-securitycontext', 12, 'lab', 'Lab: Pod Security Context (independent practice)', NULL, 'pod-security-context', NULL, 'auto_scenario', 20, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 09 m02 — 6 activities (PARTIAL: lesson + KC + core labs + one independent-practice dup)
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-09-m02-a01-lesson-serviceaccounts-rbac', 'root-09-m02-serviceaccounts-and-rbac', 1, 'lesson', 'Identity for Workloads: ServiceAccounts & RBAC',
+ 'content/root/root-09-kubernetes-security/m02-serviceaccounts-and-rbac/01-lesson-serviceaccounts-rbac.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-09-m02-a02-knowledge-check', 'root-09-m02-serviceaccounts-and-rbac', 2, 'knowledge_check', 'Knowledge Check: ServiceAccounts & RBAC',
+ 'content/root/root-09-kubernetes-security/m02-serviceaccounts-and-rbac/02-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-09-m02-a03-lab-serviceaccount-pod', 'root-09-m02-serviceaccounts-and-rbac', 3, 'lab', 'Lab: ServiceAccount for Pod API Access', NULL, 'serviceaccount-pod', NULL, 'auto_scenario', 20, 'ready'),
+('root-09-m02-a04-lab-automount-token', 'root-09-m02-serviceaccounts-and-rbac', 4, 'lab', 'Lab: Disable ServiceAccount Token', NULL, 'cks-automount-token', NULL, 'auto_scenario', 15, 'ready'),
+('root-09-m02-a05-lab-rbac-role', 'root-09-m02-serviceaccounts-and-rbac', 5, 'lab', 'Lab: RBAC — Create Role and RoleBinding', NULL, 'rbac-role', NULL, 'auto_scenario', 30, 'ready'),
+('root-09-m02-a06-lab-rbac-clusterrole', 'root-09-m02-serviceaccounts-and-rbac', 6, 'lab', 'Lab: Cluster-Level RBAC (CKS)', NULL, 'cks-rbac-clusterrole', NULL, 'auto_scenario', 20, 'ready'),
+('root-09-m02-a07-lab-rbac-least-privilege', 'root-09-m02-serviceaccounts-and-rbac', 7, 'lab', 'Lab: RBAC Least Privilege', NULL, 'cks-rbac-least-privilege', NULL, 'auto_scenario', 20, 'ready'),
+('root-09-m02-a08-lab-rbac-clusterrole-independent', 'root-09-m02-serviceaccounts-and-rbac', 8, 'lab', 'Lab: ClusterRole and ClusterRoleBinding (independent practice)', NULL, 'rbac-clusterrole', NULL, 'auto_scenario', 20, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 09 m03 — 6 activities (PARTIAL)
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-09-m03-a01-lesson-network-supplychain', 'root-09-m03-network-and-supplychain-security', 1, 'lesson', 'NetworkPolicy as a Security Control & Supply Chain Trust',
+ 'content/root/root-09-kubernetes-security/m03-network-and-supplychain-security/01-lesson-network-supplychain.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-09-m03-a02-knowledge-check', 'root-09-m03-network-and-supplychain-security', 2, 'knowledge_check', 'Knowledge Check: Network & Supply Chain Security',
+ 'content/root/root-09-kubernetes-security/m03-network-and-supplychain-security/02-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-09-m03-a03-lab-default-deny', 'root-09-m03-network-and-supplychain-security', 3, 'lab', 'Lab: Default Deny Network Policy', NULL, 'cks-network-policy', NULL, 'auto_scenario', 20, 'ready'),
+('root-09-m03-a04-lab-egress-namespace', 'root-09-m03-network-and-supplychain-security', 4, 'lab', 'Lab: Restrict Egress to Namespace', NULL, 'cks-egress-namespace', NULL, 'auto_scenario', 30, 'ready'),
+('root-09-m03-a05-lab-egress-networkpolicy-guided', 'root-09-m03-network-and-supplychain-security', 5, 'lab', 'Lab: Egress NetworkPolicy (guided practice)', NULL, 'networkpolicy-egress', NULL, 'auto_scenario', 30, 'ready'),
+('root-09-m03-a06-lab-tls-ingress', 'root-09-m03-network-and-supplychain-security', 6, 'lab', 'Lab: Secure Ingress with TLS', NULL, 'cks-tls-ingress', NULL, 'auto_scenario', 30, 'ready'),
+('root-09-m03-a07-lab-image-pull-secret', 'root-09-m03-network-and-supplychain-security', 7, 'lab', 'Lab: Private Registry Image Pull Secret', NULL, 'cks-image-pull-secret', NULL, 'auto_scenario', 15, 'ready'),
+('root-09-m03-a08-lab-network-policy-metadata-advanced', 'root-09-m03-network-and-supplychain-security', 8, 'lab', 'Lab: Block Cloud Metadata (advanced/optional)', NULL, 'cks-network-policy-metadata', NULL, 'auto_scenario', 30, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 09 m04 — 4 activities (PARTIAL: survey-level, deliberately lighter)
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-09-m04-a01-lesson-cluster-hardening', 'root-09-m04-cluster-hardening-and-runtime', 1, 'lesson', 'Pod Security Admission & a Survey of Runtime Hardening',
+ 'content/root/root-09-kubernetes-security/m04-cluster-hardening-and-runtime/01-lesson-cluster-hardening.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-09-m04-a02-lab-psa-namespace', 'root-09-m04-cluster-hardening-and-runtime', 2, 'lab', 'Lab: Pod Security Admission', NULL, 'cks-psa-namespace', NULL, 'auto_scenario', 15, 'ready'),
+('root-09-m04-a03-lab-immutable-secret', 'root-09-m04-cluster-hardening-and-runtime', 3, 'lab', 'Lab: Immutable Secrets', NULL, 'cks-immutable-secret', NULL, 'auto_scenario', 15, 'ready'),
+('root-09-m04-a04-lab-runtime-class-advanced', 'root-09-m04-cluster-hardening-and-runtime', 4, 'lab', 'Lab: RuntimeClass for Sandboxed Workloads (advanced/optional)', NULL, 'cks-runtime-class', NULL, 'auto_scenario', 20, 'ready'),
+('root-09-m04-a05-lab-audit-policy-advanced', 'root-09-m04-cluster-hardening-and-runtime', 5, 'lab', 'Lab: Write a Kubernetes Audit Policy (advanced/optional)', NULL, 'cks-audit-policy', NULL, 'auto_scenario', 30, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 10 m03 — 5 activities (PARTIAL: lesson + demo + KC + two labs)
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-10-m03-a01-lesson-framework', 'root-10-m03-troubleshooting-framework', 1, 'lesson', 'The RootNode Troubleshooting Framework',
+ 'content/root/root-10-kubernetes-troubleshooting-observability/m03-troubleshooting-framework/01-lesson-framework.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-10-m03-a02-demonstration-crashloop', 'root-10-m03-troubleshooting-framework', 2, 'demonstration', 'Demonstration: Applying the Framework to a CrashLoopBackOff',
+ 'content/root/root-10-kubernetes-troubleshooting-observability/m03-troubleshooting-framework/02-demonstration-crashloop.md', NULL, NULL, 'manual_marker', 10, 'ready'),
+('root-10-m03-a03-knowledge-check', 'root-10-m03-troubleshooting-framework', 3, 'knowledge_check', 'Knowledge Check: The Troubleshooting Framework',
+ 'content/root/root-10-kubernetes-troubleshooting-observability/m03-troubleshooting-framework/03-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-10-m03-a04-lab-crashloop-fix', 'root-10-m03-troubleshooting-framework', 4, 'lab', 'Lab: Fix a CrashLoopBackOff Pod', NULL, 'crashloop-fix', NULL, 'auto_scenario', 20, 'ready'),
+('root-10-m03-a05-lab-endpoint-fix', 'root-10-m03-troubleshooting-framework', 5, 'lab', 'Lab: Fix a Broken Service Selector', NULL, 'endpoint-fix-task', NULL, 'auto_scenario', 20, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 10 m02 (existing bare bank) — extend with the newly-wired logging/monitoring MCQ
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-10-m02-a06-container-logging-mcq', 'root-10-m02-general-troubleshooting', 6, 'lab', 'Lab: Container Logging and Monitoring', NULL, 'container-logging-mcq', NULL, 'auto_scenario', 15, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ROOT 12 m01 — a new framework lesson at the FRONT (existing 4 lab activities renumbered
+-- +1 to make room; their scenario_id/activity_type/completion_behavior are untouched, so no
+-- student's derived completion changes meaning) plus a closing reflection.
+UPDATE module_activities SET sequence = sequence + 1, version = version + 1, updated_at = now()
+  WHERE module_id = 'root-12-m01-real-ops-incidents';
+
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-12-m01-a00-lesson-incident-response', 'root-12-m01-real-ops-incidents', 1, 'lesson', 'The RootNode Incident-Response Framework',
+ 'content/root/root-12-real-ops/m01-real-ops-incidents/00-lesson-incident-response.md', NULL, NULL, 'manual_marker', 15, 'ready'),
+('root-12-m01-a99-reflection-post-incident', 'root-12-m01-real-ops-incidents', 6, 'reflection', 'Post-Incident Reflection: What Real Ops Actually Feels Like',
+ 'content/root/root-12-real-ops/m01-real-ops-incidents/99-reflection-post-incident.md', NULL, NULL, 'manual_marker', 10, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- Capstone Readiness — 4 activities (READY: informational/orientation, not a lesson-heavy module)
+INSERT INTO module_activities (activity_id, module_id, sequence, activity_type, title, content_path, scenario_id, assessment_definition_id, completion_behavior, estimated_duration_minutes, status) VALUES
+('root-capstone-m02-a01-lesson-what-it-measures', 'root-capstone-m02-capstone-readiness', 1, 'lesson', 'What the Capstone Measures & How the Draw Works',
+ 'content/root/root-capstone/m02-capstone-readiness/01-lesson-what-it-measures.md', NULL, NULL, 'manual_marker', 10, 'ready'),
+('root-capstone-m02-a02-lesson-time-management', 'root-capstone-m02-capstone-readiness', 2, 'lesson', 'Time Management & Troubleshooting Strategy Under a Clock',
+ 'content/root/root-capstone/m02-capstone-readiness/02-lesson-time-management.md', NULL, NULL, 'manual_marker', 10, 'ready'),
+('root-capstone-m02-a03-knowledge-check', 'root-capstone-m02-capstone-readiness', 3, 'knowledge_check', 'Readiness Check: Are You Actually Ready?',
+ 'content/root/root-capstone/m02-capstone-readiness/03-knowledge-check.md', NULL, NULL, 'manual_marker', 5, 'ready'),
+('root-capstone-m02-a04-reflection-readiness', 'root-capstone-m02-capstone-readiness', 4, 'reflection', 'Readiness Reflection: What Completion Means',
+ 'content/root/root-capstone/m02-capstone-readiness/04-reflection-readiness.md', NULL, NULL, 'manual_marker', 5, 'ready')
+ON CONFLICT (activity_id) DO NOTHING;
+
+-- ── Optional activities: guided/independent-practice duplicates and advanced/CKS-exam-style
+-- extras (docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md's GUIDED/INDEPENDENT/ADVANCED
+-- classifications) count toward a module's displayed progress but not toward whether the
+-- module itself is considered complete — see course-progress.js's totals(). Everything not
+-- listed here stays required (the column's default), including every Phase 6A activity.
+UPDATE module_activities SET is_required = false, version = version + 1, updated_at = now() WHERE activity_id IN (
+  'root-09-m01-a10-lab-seccomp-guided',
+  'root-09-m01-a11-lab-apparmor-advanced',
+  'root-09-m01-a12-lab-pod-security-context-independent',
+  'root-09-m02-a08-lab-rbac-clusterrole-independent',
+  'root-09-m03-a05-lab-egress-networkpolicy-guided',
+  'root-09-m03-a08-lab-network-policy-metadata-advanced',
+  'root-09-m04-a04-lab-runtime-class-advanced',
+  'root-09-m04-a05-lab-audit-policy-advanced'
+);

platform/api/src/admin-course-routes.js

@@ -0,0 +1,42 @@
+// Phase 6A §7 — instructor/admin curriculum visibility. Read-only: course/module/activity
+// authoring stays Git/migration-based this phase (see docs/COURSE_CONTENT_MODEL.md — no
+// WYSIWYG CMS), so there is deliberately no POST/PATCH here, only the views an instructor needs
+// to actually teach from: program structure with instructor notes, and per-student progress
+// through it so a teacher can see where someone is stuck.
+
+const { buildCourseTree } = require('./course-progress');
+
+module.exports = function registerAdminCourseRoutes(app, deps) {
+  const { instructorSession, rbac, getPool } = deps;
+  const { requireAnyInstructor, requireStudentRelationshipAccess } = rbac;
+
+  // Same local-wrap convention as admin-programs-routes.js/admin-learning-routes.js — RBAC
+  // middleware here is plain sync `(req,res,next)`, so this Promise.resolve() guard lets it
+  // share the same mw.map(wrap) list as the async route handlers below.
+  function wrap(fn) {
+    return (req, res, next) => { Promise.resolve(fn(req, res, next)).catch(next); };
+  }
+  const admin = { get: (p, ...mw) => app.get(p, instructorSession, ...mw.map(wrap)) };
+
+  // Full structure (courses -> modules -> activities), instructor notes and draft content
+  // included, with no completion overlay — studentId is deliberately null here (course-
+  // progress.js's queries tolerate that and just return complete:false everywhere), since this
+  // is "what does the curriculum look like," not "how is any one student doing."
+  admin.get('/api/admin/programs/:programId/courses', requireAnyInstructor, async (req, res) => {
+    const courses = await buildCourseTree(getPool(), { studentId: null, programId: req.params.programId, forInstructor: true });
+    res.json(courses);
+  });
+
+  // One student's real progress through the same tree. Uses requireStudentRelationshipAccess,
+  // not requireStudentCohortAccess — a self-paced root_ student typically has NO cohort at all
+  // (Phase 5B), so the cohort-only check would 403 a plain instructor out of every self-paced
+  // student's progress. Same rule Phase 5C's notification routes already established: a plain
+  // instructor may see a student they share a cohort with OR whose enrollment they personally
+  // created; owner/admin always bypass.
+  admin.get('/api/admin/students/:id/courses', requireAnyInstructor, requireStudentRelationshipAccess('id'), async (req, res) => {
+    const programId = req.query.program_id;
+    if (!programId) return res.status(400).json({ error: 'program_id is required' });
+    const courses = await buildCourseTree(getPool(), { studentId: req.params.id, programId, forInstructor: true });
+    res.json(courses);
+  });
+};

platform/api/src/admin-programs-routes.js

@@ -0,0 +1,180 @@
+// Phase 5B §11 — instructor/admin program and enrollment management. Program authoring
+// (create/edit) is admin/owner only, matching assessment_definitions' existing convention;
+// every role can list/inspect (matches AssessmentsView's "viewed by all roles, only authoring
+// restricted" pattern). Enrollment creation is admin/owner only (matches roster-creation
+// precedent — POST /api/admin/students is the same restriction); a plain instructor can still
+// view/activate/cancel an enrollment they created or that belongs to a student sharing one of
+// their cohorts, via rbac.js's requireEnrollmentAccess — see that function's own comment for
+// the exact documented rule.
+
+const programsLib = require('./programs');
+const enrollmentLib = require('./enrollment');
+const notificationsLib = require('./notifications');
+const studentsAuth = require('./students-auth');
+const { buildProgramStatus } = require('./program-status');
+
+function enrollmentErrorStatus(code) {
+  if (code === 'NOT_FOUND') return 404;
+  if (code === 'PROGRAM_NOT_FOUND') return 404;
+  if (code === 'ALREADY_ENROLLED' || code === 'INVALID_STATE' || code === 'PROGRAM_INACTIVE') return 409;
+  return 500;
+}
+
+module.exports = function registerAdminProgramsRoutes(app, deps) {
+  const { instructorSession, rbac, curriculum, getPool, loadProgress, recordAudit } = deps;
+  const { requireAnyInstructor, requireAdminOrOwner, requireEnrollmentAccess } = rbac;
+  const statusDeps = { pool: getPool(), curriculum, loadProgress };
+
+  // Local wrap, same convention as admin-routes.js/admin-classroom-routes.js (NOT the stricter
+  // server.js-level `wrap`, which assumes fn always returns a promise — RBAC middleware like
+  // requireAnyInstructor is a plain sync `(req,res,next)` function, so it needs the
+  // Promise.resolve() guard here to be safely mixed into the same mw.map(wrap) list as the
+  // async route handlers).
+  function wrap(fn) {
+    return (req, res, next) => { Promise.resolve(fn(req, res, next)).catch(next); };
+  }
+  const admin = {
+    get: (p, ...mw) => app.get(p, instructorSession, ...mw.map(wrap)),
+    post: (p, ...mw) => app.post(p, instructorSession, ...mw.map(wrap)),
+    patch: (p, ...mw) => app.patch(p, instructorSession, ...mw.map(wrap)),
+  };
+
+  // ── Programs ─────────────────────────────────────────────────────────────────────────────
+  admin.get('/api/admin/programs', requireAnyInstructor, async (req, res) => {
+    res.json(await programsLib.listPrograms(getPool()));
+  });
+
+  admin.get('/api/admin/programs/:id', requireAnyInstructor, async (req, res) => {
+    const program = await programsLib.getProgram(getPool(), req.params.id);
+    if (!program) return res.status(404).json({ error: 'not found' });
+    const { rows: statusCounts } = await getPool().query(
+      `SELECT status, count(*)::int AS n FROM enrollments WHERE program_id = $1 GROUP BY status`, [req.params.id]
+    );
+    res.json({ ...program, enrollment_counts: Object.fromEntries(statusCounts.map((r) => [r.status, r.n])) });
+  });
+
+  admin.post('/api/admin/programs', requireAdminOrOwner, async (req, res) => {
+    const { program_id, name, description, family, delivery_mode, curriculum_path, completion_assessment_id, estimated_duration_hours } = req.body || {};
+    if (!program_id || !name || !family) return res.status(400).json({ error: 'program_id, name, and family are required' });
+    if (!['init', 'compile', 'root'].includes(family)) return res.status(400).json({ error: 'family must be init, compile, or root' });
+    try {
+      const program = await programsLib.createProgram(getPool(), {
+        programId: program_id, name, description, family, deliveryMode: delivery_mode, curriculumPath: curriculum_path,
+        completionAssessmentId: completion_assessment_id, estimatedDurationHours: estimated_duration_hours, createdBy: req.instructor.instructor_id,
+      });
+      await recordAudit(getPool(), { actorType: 'instructor', actorId: req.instructor.instructor_id, action: 'program_created', resourceType: 'program', resourceId: program.program_id, result: 'success', sourceIp: req.ip });
+      res.status(201).json(program);
+    } catch (e) {
+      if (e.code === '23505') return res.status(409).json({ error: 'program_id already exists' });
+      throw e;
+    }
+  });
+
+  admin.patch('/api/admin/programs/:id', requireAdminOrOwner, async (req, res) => {
+    const { name, description, family, delivery_mode, curriculum_path, completion_assessment_id, estimated_duration_hours, status } = req.body || {};
+    const map = { name, description, family, delivery_mode, curriculum_path, completion_assessment_id, estimated_duration_hours, status };
+    const fields = {};
+    for (const [k, v] of Object.entries(map)) if (v !== undefined) fields[k] = v;
+    if (!Object.keys(fields).length) return res.status(400).json({ error: 'nothing to update' });
+    const program = await programsLib.updateProgram(getPool(), req.params.id, fields);
+    if (!program) return res.status(404).json({ error: 'not found' });
+    await recordAudit(getPool(), { actorType: 'instructor', actorId: req.instructor.instructor_id, action: 'program_updated', resourceType: 'program', resourceId: req.params.id, result: 'success', sourceIp: req.ip, metadata: fields });
+    res.json(program);
+  });
+
+  // ── Enrollments ──────────────────────────────────────────────────────────────────────────
+  // Scoped list, same shape as GET /api/admin/students: owner/admin see every enrollment for
+  // the program; a plain instructor sees only the ones they created or that belong to a
+  // student sharing one of their cohorts (the same rule requireEnrollmentAccess enforces for
+  // single-resource routes, applied here as a query filter instead of a per-row check).
+  admin.get('/api/admin/programs/:id/enrollments', requireAnyInstructor, async (req, res) => {
+    const pool = getPool();
+    const { rows } = req.instructor.role === 'instructor'
+      ? await pool.query(
+          `SELECT DISTINCT e.*, s.display_name AS student_display_name FROM enrollments e
+           JOIN students s ON s.student_id = e.student_id
+           LEFT JOIN cohort_enrollments ce ON ce.student_id = e.student_id AND ce.enrollment_status = 'enrolled'
+           LEFT JOIN cohort_instructors ci ON ci.cohort_id = ce.cohort_id AND ci.instructor_id = $2
+           WHERE e.program_id = $1 AND (e.created_by = $2 OR ci.instructor_id IS NOT NULL)
+           ORDER BY e.enrolled_at DESC`,
+          [req.params.id, req.instructor.instructor_id])
+      : await pool.query(
+          `SELECT e.*, s.display_name AS student_display_name FROM enrollments e
+           JOIN students s ON s.student_id = e.student_id WHERE e.program_id = $1 ORDER BY e.enrolled_at DESC`,
+          [req.params.id]);
+    res.json(rows);
+  });
+
+  admin.post('/api/admin/enrollments', requireAdminOrOwner, async (req, res) => {
+    const { student_id, program_id, status, starts_at, access_ends_at, delivery_mode, external_reference, contact_email, metadata } = req.body || {};
+    if (!student_id || !program_id) return res.status(400).json({ error: 'student_id and program_id are required' });
+    // Phase 5C §10 — same transitional contact-email convention as the integration endpoint;
+    // folded into the same metadata JSONB an admin could already pass, not a new column.
+    const mergedMetadata = contact_email ? { ...(metadata || {}), contact_email: String(contact_email).trim() } : metadata;
+    let created;
+    try {
+      created = await enrollmentLib.createManualEnrollment(getPool(), {
+        studentId: student_id, programId: program_id, status, startsAt: starts_at, accessEndsAt: access_ends_at,
+        deliveryMode: delivery_mode, externalReference: external_reference, metadata: mergedMetadata, createdBy: req.instructor.instructor_id,
+      });
+      await recordAudit(getPool(), { actorType: 'instructor', actorId: req.instructor.instructor_id, action: 'enrollment_created', resourceType: 'enrollment', resourceId: created.enrollment_id, result: 'success', sourceIp: req.ip, metadata: { student_id, program_id } });
+    } catch (e) {
+      if (e.code) return res.status(enrollmentErrorStatus(e.code)).json({ error: e.code, message: e.message });
+      throw e;
+    }
+    // §11 — an admin-created enrollment notifies exactly like a website-triggered one: activation
+    // for a not-yet-credentialed student, enrollment confirmation for an already-active one.
+    const program = await programsLib.getProgram(getPool(), program_id);
+    const notification = await notificationsLib.notifyForEnrollment(getPool(), studentsAuth, {
+      studentId: student_id, enrollmentId: created.enrollment_id, programName: program?.name,
+    });
+    await recordAudit(getPool(), { actorType: 'instructor', actorId: req.instructor.instructor_id, action: `notification_queued_${notification?.notification_type || 'unknown'}`, resourceType: 'notification', resourceId: notification?.notification_id, result: 'success', sourceIp: req.ip });
+    res.status(201).json(created);
+  });
+
+  admin.get('/api/admin/enrollments/:id', requireAnyInstructor, requireEnrollmentAccess('id'), async (req, res) => {
+    const row = await enrollmentLib.getEnrollment(getPool(), req.params.id);
+    res.json(await buildProgramStatus(statusDeps, row));
+  });
+
+  admin.post('/api/admin/enrollments/:id/activate', requireAnyInstructor, requireEnrollmentAccess('id'), async (req, res) => {
+    try {
+      const updated = await enrollmentLib.activateEnrollment(getPool(), req.params.id);
+      await recordAudit(getPool(), { actorType: 'instructor', actorId: req.instructor.instructor_id, action: 'enrollment_activated', resourceType: 'enrollment', resourceId: req.params.id, result: 'success', sourceIp: req.ip });
+      res.json(updated);
+    } catch (e) {
+      res.status(enrollmentErrorStatus(e.code)).json({ error: e.code || 'error', message: e.message });
+    }
+  });
+
+  admin.post('/api/admin/enrollments/:id/cancel', requireAnyInstructor, requireEnrollmentAccess('id'), async (req, res) => {
+    try {
+      const updated = await enrollmentLib.cancelEnrollment(getPool(), req.params.id);
+      await recordAudit(getPool(), { actorType: 'instructor', actorId: req.instructor.instructor_id, action: 'enrollment_cancelled', resourceType: 'enrollment', resourceId: req.params.id, result: 'success', sourceIp: req.ip });
+      res.json(updated);
+    } catch (e) {
+      res.status(enrollmentErrorStatus(e.code)).json({ error: e.code || 'error', message: e.message });
+    }
+  });
+
+  // §11 — extends the existing student detail view: enrolled programs, status, progress,
+  // current stage, last activity, completion, delivery mode. Scoped the same way the
+  // enrollments-list route above is (owner/admin see everything; a plain instructor sees only
+  // enrollments they created or that share a cohort with them) rather than requiring
+  // requireStudentCohortAccess, which would 403 for a self-paced-only student with no cohort at
+  // all even for the instructor who manually enrolled them.
+  admin.get('/api/admin/students/:id/enrollments', requireAnyInstructor, async (req, res) => {
+    const pool = getPool();
+    const { rows } = req.instructor.role === 'instructor'
+      ? await pool.query(
+          `SELECT DISTINCT e.* FROM enrollments e
+           LEFT JOIN cohort_enrollments ce ON ce.student_id = e.student_id AND ce.enrollment_status = 'enrolled'
+           LEFT JOIN cohort_instructors ci ON ci.cohort_id = ce.cohort_id AND ci.instructor_id = $2
+           WHERE e.student_id = $1 AND (e.created_by = $2 OR ci.instructor_id IS NOT NULL)
+           ORDER BY e.enrolled_at DESC`,
+          [req.params.id, req.instructor.instructor_id])
+      : await pool.query(`SELECT * FROM enrollments WHERE student_id = $1 ORDER BY enrolled_at DESC`, [req.params.id]);
+    const views = await Promise.all(rows.map((e) => buildProgramStatus(statusDeps, e)));
+    res.json(views);
+  });
+};

platform/api/src/admin-routes.js

@@ -153,6 +153,15 @@ module.exports = function registerAdminRoutes(app, deps) {
     if (email || login_identifier) {
       const issued = await issueCredentialToken(pool, studentId, 'activation');
       activationToken = issued.token;
+      // Phase 5C §5/§6 — reuses the SAME token just minted above (never mints a second one,
+      // which would silently invalidate the one this response is about to hand the admin for
+      // manual relay). A student with only login_identifier and no email has no deliverable
+      // address here — enqueue() records that as an already-failed row (never silently
+      // dropped), and the admin's manual-relay token in the response still works either way.
+      await require('./notifications').enqueue(pool, {
+        studentId, notificationType: 'activation', plaintextToken: activationToken,
+        metadata: { display_name: display_name.trim() },
+      });
     }
     await recordAudit(pool, { actorType: 'instructor', actorId: req.instructor.instructor_id, action: 'roster_add', resourceType: 'student', resourceId: studentId, result: 'success', sourceIp: req.ip, metadata: { cohort_id, credentialed: !!activationToken } });
     res.status(201).json({ student_id: studentId, display_name: display_name.trim(), activation_token: activationToken });
@@ -179,20 +188,34 @@ module.exports = function registerAdminRoutes(app, deps) {
       throw e;
     }
     const { token } = await issueCredentialToken(pool, req.params.id, 'activation');
+    // Phase 5C — same token, same "never mint twice" reasoning as create-student above.
+    const { rows: nameRows } = await pool.query(`SELECT display_name FROM students WHERE student_id = $1`, [req.params.id]);
+    await require('./notifications').enqueue(pool, {
+      studentId: req.params.id, notificationType: 'activation', plaintextToken: token,
+      metadata: { display_name: nameRows[0]?.display_name },
+    });
     await recordAudit(pool, { actorType: 'instructor', actorId: req.instructor.instructor_id, action: 'student_converted', resourceType: 'student', resourceId: req.params.id, result: 'success', sourceIp: req.ip });
     res.json({ student_id: req.params.id, activation_token: token });
   });
 
   // §4 — for an ALREADY-credentialed account (unlike convert, above). Issues a fresh 'reset'
   // token and revokes every existing session, same "instructor never needs to know the
-  // student's password" principle as activation.
+  // student's password" principle as activation. Phase 5C §8/§15: also queues a real
+  // password-reset email whenever the student has a deliverable address — the response still
+  // returns reset_token unchanged (a deliberate, documented exception to "admin cannot view
+  // token" for the population with no deliverable address at all — see notification-routes.js's
+  // header comment).
   admin.post('/api/admin/students/:id/reset-password', requireAdminOrOwner, async (req, res) => {
     const pool = getPool();
-    const { rows } = await pool.query(`SELECT student_id, password_hash FROM students WHERE student_id = $1`, [req.params.id]);
+    const { rows } = await pool.query(`SELECT student_id, display_name, password_hash FROM students WHERE student_id = $1`, [req.params.id]);
     if (!rows.length) return res.status(404).json({ error: 'not found' });
     if (!rows[0].password_hash) return res.status(409).json({ error: 'not_yet_converted', message: 'Convert this student to a real account first.' });
     const { token } = await issueCredentialToken(pool, req.params.id, 'reset');
     await require('./sessions').revokeAllStudentSessions(pool, req.params.id);
+    await require('./notifications').enqueue(pool, {
+      studentId: req.params.id, notificationType: 'password_reset', plaintextToken: token,
+      metadata: { display_name: rows[0].display_name },
+    });
     await recordAudit(pool, { actorType: 'instructor', actorId: req.instructor.instructor_id, action: 'student_password_reset', resourceType: 'student', resourceId: req.params.id, result: 'success', sourceIp: req.ip });
     res.json({ student_id: req.params.id, reset_token: token });
   });