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

@@ -150,12 +150,32 @@ its core:
   the browser (`docs/PHASE2A_GATEWAY_AND_STUDENT_FLOW.md`, session model in
   `docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md` §3, hint gating in
   `docs/PHASE3B_LEARNING_AND_ASSESSMENT.md` §3).
-- The student flow (roster login → curriculum dashboard → Launch Lab → practice/assessments/
-  capstone → achievements) lives in `frontend/src/platform/`; the instructor/admin portal
-  (per-instructor login, cohorts, students, instructor accounts, audit log, classroom
-  "Prepare Labs," environment controls, learning analytics, assessment/capstone management)
-  lives in `frontend/src/admin/` at the `/admin` route — both additions alongside the existing
-  Lab UI, not a rewrite of it.
+- The student flow (real login (email or instructor-assigned login ID) or legacy pilot roster
+  entry → curriculum dashboard → Launch Lab → practice/assessments/capstone → achievements →
+  live classroom → profile) lives in `frontend/src/platform/`; the instructor/admin portal
+  (per-instructor login, cohorts, students with credential/CSV-import management, a remote
+  classroom control center, instructor accounts, audit log, environment controls, learning
+  analytics, assessment/capstone management) lives in `frontend/src/admin/` at the `/admin`
+  route — both additions alongside the existing Lab UI, not a rewrite of it.
+- Students authenticate with real credentials as of Phase 5A (email+password or
+  login-identifier+password, first-login/reset via a single-use token an instructor relays) —
+  see `docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md`. Instructors run live, remote-capable
+  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
@@ -192,7 +212,9 @@ 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/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md`, `docs/PHASE3B_LEARNING_AND_ASSESSMENT.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,37 +88,42 @@ 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
 
-**Built (backend only, as of this doc):**
-- `students` table: `student_id` (`student-NNN`, sequential), `display_name`, `cohort`,
-  `created_at`, `last_active_at`.
-- Login model: **instructor roster, pick-your-name, no password.** `POST /api/roster` adds
-  a student (instructor-only action, currently unauthenticated at the API level — see
-  "not built" below). `GET /api/roster?cohort=X` lists names for a dropdown.
-  `POST /api/login` just validates the id exists and returns it; the frontend is expected to
-  hold onto `student_id` and send it back as an `X-Student-Id` header on every request.
-- `progress` table now keyed on `(student_id, scenario_id)` instead of `scenario_id` alone —
-  each student's completion/attempts/hints are isolated. Verified by smoke test: two students
-  answering the same scenario don't affect each other's state, and pre-migration data was
-  preserved under `student_id = 'unassigned'`.
-- Exam `sessions` now carry `student_id` (set at session start), so exam history and the
-  timer-reset-on-submit logic are correctly scoped per student instead of leaking across
-  whoever's browser hits the API next.
+**Current state (Phase 5A — see `docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md` for the
+full design):**
+- `students.student_id` (`student-NNN`, sequential) is still the FK every other table hangs off
+  of and never changes across an account's lifecycle, including conversion.
+- Real credentials: `email` and `login_identifier` (independently optional/unique — email for
+  older/self-paced students, an instructor-assigned login ID for younger ones), `password_hash`
+  reusing `instructors`' exact `scrypt` machinery (`src/auth/password.js`). A student with
+  neither field set is a plain **pilot** account, unchanged since Phase 2A: `POST /api/login
+  { student_id }`, no password, instructor-roster-only.
+- First login/reset is one shared, single-use, hashed, time-limited token mechanism
+  (`students-auth.js`) — instructors never see or set a student's actual password.
+- Sessions are the same Postgres-backed `sessions` table instructors use (opaque, HttpOnly,
+  hashed, revocable, CSRF-protected); login is rate-limited the same Postgres-backed way as
+  instructor login (Phase 4.1), now also applied to students.
+- Per-student `progress`/`scenario_attempts`/exam `sessions` isolation (below) and real
+  concurrent multi-student Lab isolation (Phase 1's Provisioner/k3s-per-student model) were both
+  already in place well before this — Phase 5A only changed how a student proves who they are,
+  not how their data or Labs are isolated.
 
-**Not built yet — do not assume these exist:**
-- **No frontend UI.** No login screen, no name picker, no roster-add form. The API works;
-  nothing calls it yet. This is the next slice.
-- **No auth on `/api/roster` POST.** Anyone who can reach the API can add a "student."
-  Fine for a dev instance, not fine once this is reachable by actual students — needs an
-  instructor-only gate before that happens (ties into the instructor dashboard, roadmap
-  item 3).
-- **No concurrency / isolation.** Exam sessions are still global-single-active
-  (`WHERE status='active' LIMIT 1` — see `server.js`), and there is one shared k3s cluster
-  for the whole instance. Per-student identity ≠ per-student environment. **Multiple students
-  cannot yet use this platform at the same time without stepping on each other.** That's
-  roadmap item 4 (isolation) and it gates real classroom/minors use, same as the plan called
-  out — this SOP is not claiming that gate is cleared.
+**Not built — deliberate non-goals, not gaps (Phase 5A §37):**
+- No public self-registration — accounts are still instructor-created/converted/imported only.
+- No email delivery infrastructure — password reset works via an instructor-issued token today;
+  self-service reset returns a real token only in non-production, by design.
+- No Parent/Guardian portal — the schema doesn't block adding one later, but none exists.
+
+**Historical note, kept for context:** earlier drafts of this section described a pre-Phase-2A
+state (`X-Student-Id` header, unauthenticated roster POST, one shared cluster) that no longer
+reflects any deployed version of this codebase; that content has been superseded by the above.
 
 ## 6. Schema migration pattern
 
@@ -146,9 +151,11 @@ Order agreed 2026-08-17/18. Status as of this doc:
    (§12), student-facing tabs (My Learning/Practice/Assessments/Capstone/Achievements) at
    `frontend/src/platform/`.
 3. Student accounts / persistent progress — **done**, Postgres-authoritative as of Phase 2B
-   (§9), sessions persistent as of Phase 3A (§10). Roster name-picking is still classroom/pilot
-   identification, not strong student auth — documented, not silently glossed over
-   (docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md §7).
+   (§9), sessions persistent as of Phase 3A (§10). Real student credentials (email or
+   login-identifier + password, first-login/reset token flow) closed the remaining "pick your
+   name" gap as of Phase 5A — see §5 above and
+   docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md. Pilot (no-login) accounts still work
+   unchanged for anyone not yet converted.
 4. Instructor dashboard — **done** (§9/§10). Full admin portal at `/admin`: dashboard, cohort
    and student management, classroom Prepare/Destroy Labs, per-instructor accounts with
    owner/admin/instructor roles, audit log.
@@ -332,4 +339,156 @@ Full design: `docs/PHASE4_1_PREPRODUCTION_HARDENING.md`, plus
 - **Known limitation carried forward:** real remote/self-paced delivery needs actual student
   authentication (today's `student_id`-only login relies on instructors controlling who gets a
   valid id) — see `docs/REMOTE_AND_SELF_PACED_ARCHITECTURE.md` for the full accounting of what
-  already works vs. what's genuinely Phase 5 scope.
+  already works vs. what's genuinely Phase 5 scope. **Closed in Phase 5A, below.**
+
+## 14. Student Identity & Remote Classroom (Phase 5A)
+
+Full design: `docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md`, plus
+`docs/RUNBOOK_STUDENT_ACCOUNT_LIFECYCLE.md` and `docs/RUNBOOK_REMOTE_CLASSROOM.md`.
+
+- **What it is:** two deliverables built on the Phase 4.1 milestone. (A) Real student accounts —
+  email-or-login-identifier + password, reusing `instructors`' exact credential machinery, a
+  single first-login/reset token mechanism, deactivation enforced per-request — replacing pilot
+  "pick your name" identification without touching a single existing pilot student's progress.
+  (B) A remote classroom control center — scheduled/live/ended sessions, derived (not stored)
+  presence via heartbeat, a live instructor dashboard combining real Provisioner Lab state and
+  real academic records, a help-request queue, guidance-only announcements/current-activity, and
+  a generic external meeting-URL field. Explicitly **not** video/voice/chat/shell-takeover —
+  RootNode owns identity and coordination, an external service owns the call.
+- **Tested, not just designed:** `platform/test/e2e-phase5a.js` (21 checks: the two-student RBAC
+  matrix and full password-security checklist, including a real Platform API restart proving
+  rate-limit state survives it) and `infra/scripts/drills/test-phase5a-rehearsal.js` (15 checks:
+  5 pilot students with seeded real history, a live classroom, help requests, **a real
+  mid-rehearsal API restart** proving classroom/session/presence recovery, then converting two
+  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

@@ -498,3 +498,37 @@ mechanism for reaching a Lab container (it assumes Gateway and Lab share a Docke
 breaks once they're genuinely on separate VMs); Phase 4.1
 (`docs/PHASE4_1_PREPRODUCTION_HARDENING.md`) built and simulation-tested the fix, a Lab Host
 Router (`platform/lab-router/`).
+
+## Phase 5A: reused, not modified
+
+Phase 5A (`docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md`) added real student accounts and a
+remote classroom control center on top of everything this document describes, without changing
+any of it — the Provisioner, the `environments` state machine, the Lab Host Router, disposable
+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/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md

@@ -0,0 +1,195 @@
+# Phase 5A — Student Identity & Remote Classroom
+
+**Status: PHASE 5A COMPLETE. STUDENT IDENTITY COMPLETE. REMOTE CLASSROOM FOUNDATION COMPLETE.**
+
+Phase 4.1 closed the last pre-production infrastructure gap without real hardware. Phase 5A's
+job — still without real hardware — was the last real *product* gap flagged along the way: pilot
+students identify themselves by picking a name from a list, and there was no way for an
+instructor to run a live, remote-capable class through the platform itself. This phase replaces
+pilot identification with real accounts and adds a remote classroom control center. It does
+**not** add video, voice, chat, or any A/V — those stay Meet/Zoom/Teams's job; RootNode owns
+identity, presence, curriculum guidance, Lab status, help requests, and instructor control.
+
+## 1. Student identity model
+
+`students` (migration `017_student_credentials.sql`) gained `email`, `login_identifier`,
+`password_hash`, `last_login_at`, and a single credential-token triple
+(`credential_token_hash`/`_purpose`/`_expires_at`) — all nullable, all additive. `email` and
+`login_identifier` are independently unique (partial unique indexes, `WHERE ... IS NOT NULL`)
+and both optional: an older/self-paced student gets an email, a younger instructor-managed
+student gets an instructor-assigned login ID, neither is required, and nothing here blocks a
+future `guardian_id` FK for a Parent Portal — deliberately not built this phase (§37).
+
+A student with **neither** field set is unchanged from before Phase 5A: a plain pilot row,
+identified with `POST /api/login { student_id }`. Setting either field (via account creation or
+`/convert`) is what makes an account "real." `password_hash` reuses `platform/api/src/auth/
+password.js` (scrypt, `salt:hash`) verbatim — the same function instructors use, no second
+hashing scheme.
+
+## 2. Credential lifecycle — one token mechanism, not two
+
+Activation ("first login") and password reset are the same problem: a time-limited, single-use
+secret that lets someone set a new password. `students-auth.js`'s `issueCredentialToken`/
+`consumeCredentialToken` implement it once (SHA-256-hashed at rest, plaintext returned exactly
+once in the API response, never logged), with `purpose` (`activation` | `reset`) distinguishing
+the two callers. Activation tokens live 7 days, reset tokens 1 hour. `consumeCredentialToken` is
+atomic: token verification, password hashing, `password_hash` write, and token-clearing happen
+in one statement — there is no window where a token is "spent" but the password isn't set.
+
+Instructors never see or choose a student's password (§5's "instructor creates account →
+temporary credential" flow): `POST /api/admin/students`, `/convert`, and `/reset-password` all
+return a token (activation or reset), which the instructor relays out of band (printed, read
+aloud, handed over). The admin UI surfaces the resulting `?activate=<token>`/`?reset=<token>`
+link once and never again — there is no "view credentials" screen anywhere.
+
+## 3. Password reset without email delivery
+
+No email-sending infrastructure exists yet, and this phase deliberately doesn't fake one.
+`POST /api/student/request-password-reset` always returns an identical generic response
+regardless of whether the identifier exists (anti-enumeration) and never echoes the token in
+production. In non-production (`isProduction` false, i.e. `COOKIE_SECURE !== '1'`) it also
+returns `dev_reset_token` so local/CI flows can complete the loop without a real inbox — a
+documented dev/test path, not a production feature. The realistic production path today is
+instructor-triggered: `POST /api/admin/students/:id/reset-password`. Real email delivery is a
+named, not-yet-built follow-up, not something silently promised.
+
+## 4. Session and login security — reused, not duplicated
+
+Students and instructors share the exact same `sessions` table and mechanism
+(`sessions.js`: opaque tokens, HttpOnly, SameSite, hashed at rest, revocable), differentiated
+only by `session_type`/`student_id` vs `instructor_id`. `studentSession` middleware now
+re-verifies `status = 'active'` on **every** request (previously only checked session
+existence) — deactivating a student takes effect immediately, matching `instructorSession`'s
+existing behavior, not just at next login (verified in `e2e-phase5a.js`).
+
+Rate limiting reuses Phase 4.1's Postgres-backed `tooManyAttempts` (`security.js`) with a
+`student:` key prefix — 8 attempts / 5 minutes, survives a Platform API restart because it's a
+table, not an in-memory Map (verified with a real restart in both `e2e-phase5a.js` and the
+rehearsal drill). CSRF reuses the existing double-submit cookie pattern (`rn_csrf_s`).
+
+**A real bug this closed:** the legacy `POST /api/login` (bare `student_id`, no password) only
+checked `password_hash` to decide whether an account had "moved on" from pilot mode. An account
+mid-conversion — instructor has issued an activation token, student hasn't set a password yet —
+has `credential_token_hash` set but `password_hash` still `NULL`, and was reachable through the
+old insecure path for that whole window. Found via testing, fixed by checking
+`student.password_hash || student.credential_token_hash` instead (`server.js`).
+
+## 5. Pilot migration
+
+No destructive migration. `017_student_credentials.sql` only adds nullable columns — every
+existing pilot row, its progress, attempts, achievements, and cohort membership are completely
+untouched at migration time. `POST /api/admin/students/:id/convert` assigns email/login_
+identifier and issues an activation token without touching `student_id` (the FK every other
+table hangs off of) or anything downstream of it. Verified directly, not just asserted: the
+Phase 5A rehearsal drill (`infra/scripts/drills/test-phase5a-rehearsal.js`) seeds real pre-
+existing progress/attempt/achievement rows for a pilot student, converts them, activates them,
+logs in the new way, and confirms `/api/progress` shows the exact same completed scenario —
+nothing orphaned, nothing re-created.
+
+## 6. Remote classroom — a fourth session concept
+
+Distinct from cohort membership, assessment sessions, and Lab environments: a scheduled,
+bounded teaching event. `018_classroom_sessions.sql` adds `classroom_sessions` (lifecycle
+`scheduled → live → ended`, or `cancelled`), `classroom_participants`, `classroom_events`
+(append-only audit), `classroom_announcements`, and `help_requests`. A partial unique index
+(`WHERE status = 'live'`) enforces at most one live classroom per cohort at the database level —
+the app layer catches the resulting `23505` and returns a clean `ALREADY_LIVE` (409), not a
+raw constraint error (verified in `e2e-phase5a.js`).
+
+## 7. Presence — derived, not stored
+
+`classroom.derivePresence(lastSeenAt, leftAt)` is a pure function computing `online` /
+`recently_active` / `offline` from a timestamp at read time — there's no status column that can
+go stale or need a background job to sweep. Heartbeats (`POST /api/classroom/:id/heartbeat`,
+client fires every 20-30s while the Classroom tab is open and joined) are throttled server-side
+(`WHERE last_seen_at IS NULL OR last_seen_at < now() - interval`), never depend on Lab terminal
+activity, and stop the moment the tab is closed or the student leaves — no invasive tracking.
+
+## 8. The classroom dashboard — real data, not a second state system
+
+`GET /api/admin/classroom-sessions/:id` is the one place that reaches beyond `classroom.js`: it
+joins participant/presence data with the Provisioner's actual `environments` state (same enum
+every other Lab-status view uses — `none`/`requested`/`provisioning`/`running`/`resetting`/
+`error`/`destroying`/`destroyed`) and a lightweight academic snapshot from the existing
+`progress`/`scenario_attempts` tables (current stage, most recent scenario, validation-fail
+count, hints used). Never inspects terminal command history. Nothing here is a second Lab-state
+or academic-state system — it's the existing ones, read the same way every other admin view
+already reads them.
+
+## 9. Help requests — a queue, not a chat
+
+`POST /api/classroom/:id/help-request { category, message }` → `open` → (instructor)
+`acknowledge` → `resolve`. That's the entire surface — explicitly no chat, no video, no remote
+shell takeover (§37). The instructor dashboard's help queue polls the same dashboard endpoint
+everything else does.
+
+## 10. Guidance, never control
+
+`setCurrentActivity` (current scenario) and announcements are exactly that — a link the student
+can choose to open, a message they can read. Nothing server-side redirects a student's browser
+or marks work complete on their behalf. The external meeting URL (`classroom_sessions.
+meeting_url`) is a generic field the student sees as a link — RootNode never proxies or embeds
+Meet/Zoom/Teams/anything else, so it isn't coupled to a single vendor.
+
+## 11. CSV roster import — whole-file, transactional
+
+`student-csv.js` hand-parses (no CSV dependency — the file format here is small and simple
+enough that pulling in a library would just be one more thing to audit) and validates the
+**entire** file before any database write. `POST /api/admin/students/import` then does every
+insert inside one Postgres transaction — one bad row rolls back the whole import rather than
+leaving a half-imported roster, which is the more dangerous failure mode of the two. Never
+accepts a `password`/`password_hash`/`credential_token_hash` column — activation tokens are
+always generated server-side, never taken from input.
+
+## 12. Observability
+
+`GET /metrics` is a hand-rolled Prometheus text-exposition endpoint (no `prom-client`
+dependency — a handful of counters/gauges don't need one) with real in-process counters for
+login success/failure and on-demand gauges for live-classroom/help-request/Lab-state counts.
+No student or instructor ID ever appears as a label value — every label is a bounded enum
+(status, presence, result), per the explicit no-PII/no-high-cardinality-labels instruction. The
+Prometheus scrape job for the Platform API (`infra/monitoring/prometheus/prometheus.yml.j2`),
+previously commented out, is now active.
+
+## 13. Frontend
+
+**Student side** (`frontend/src/platform/`): `LoginScreen` (credentialed, now the default entry
+point) with links to the legacy pilot entry and forgot-password; `SetPasswordScreen` (shared
+activate/reset UI, driven by `?activate=`/`?reset=` query params — no router library, matching
+this app's existing state-machine-per-shell convention); `ForgotPasswordScreen`; a `Classroom`
+tab (live-class banner, join, guidance-only current-activity link, own Lab status/launch reusing
+the My Learning tab's exact API, announcements, Need Help form); a `Profile` tab (identity,
+cohort, progress, achievements, active-session count, change-password).
+
+**Admin side** (`frontend/src/admin/`): `StudentsView` gained credential status in the roster
+table, a create-student form (email/login-ID/cohort), convert/reset-password/revoke-sessions
+controls per student, and a bulk CSV import form. A new `ClassroomView` is the control center:
+cohort picker → schedule/list classes → a live dashboard (participants with presence/Lab-status/
+current-work, help queue with acknowledge/resolve, current-activity setter, announcement
+poster, start/end/cancel, Prepare Labs).
+
+## 14. Testing — real, not asserted
+
+- `platform/test/e2e-phase5a.js` (21 checks): activation single-use, password security (§32 —
+  correct/wrong/unknown-identifier/deactivated/immediate-deactivation/rate-limit/rate-limit-
+  survives-restart/change-password/session-revocation/forgot-password anti-enumeration/admin
+  reset/CSRF), and the two-student RBAC matrix (§31 — student can't reach `/api/admin/*`,
+  assigned/unassigned/viewer instructor access), plus a classroom lifecycle smoke pass.
+- `infra/scripts/drills/test-phase5a-rehearsal.js` (15 checks): 5 pilot students, real seeded
+  progress/attempt/achievement history, a live classroom, help requests, announcements, **a real
+  Platform API restart mid-rehearsal** proving classroom/session/presence recovery, then
+  converting two students mid-rehearsal and confirming every bit of their prior history survived
+  under the new login.
+- Both run against a live `docker-compose.dev.yml` stack over real HTTP, not mocks.
+- The full pre-existing regression suite (Phase 1/2A/2B/3A/3B/4.1) was re-run unmodified given
+  how much shared code (`server.js`, `admin-routes.js`, `sessions.js`, `rbac.js`) this phase
+  touched — see the Phase 5A completion report for results.
+
+## 15. What was deliberately not built
+
+Per §37: video/voice conferencing, student-to-student chat, remote instructor shell takeover,
+screen recording or proctoring, public registration or course catalog, payments/Stripe, a Parent
+Portal, school/SIS integrations, real email delivery infrastructure, certificates, an AI tutor,
+a mobile app, a multi-Lab-host scheduler, and production deployment itself. Each is a plausible
+"while we're in here" addition and each was left alone on purpose — the schema and API surface
+built this phase don't block any of them later.

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

@@ -54,5 +54,53 @@ can prove in advance.
       full" message, not a 500 — confirms the real host's admission control matches the local test
 - [ ] `docs/RUNBOOK_LAB_HOST_RESOURCE_PRESSURE.md`'s steps still make sense once capacity numbers are real
 
+## Student identity & remote classroom (Phase 5A — see docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md)
+- [ ] `COOKIE_SECURE=1` in the real production environment — confirms `/api/student/
+      request-password-reset` never returns `dev_reset_token` outside of dev/CI
+- [ ] A real activation/reset link (`?activate=`/`?reset=`) round-trips against the production
+      domain, not just `localhost` — query-param parsing, no router library in play
+- [ ] Student login rate limiting still 429s after a restart against the real production
+      Postgres, same as the local `e2e-phase5a.js` check
+- [ ] `GET /metrics` is reachable by the real Prometheus instance (`infra/monitoring/
+      prometheus/prometheus.yml.j2`'s `rootnode-platform-api` job) and no student/instructor ID
+      appears in any label value
+- [ ] `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,41 +45,63 @@ 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.** A student session is created from a bare `student_id`
-   (`POST /api/login`, no password) — deliberately, since today every `student_id` is issued and
-   controlled by an instructor via the roster, not chosen or known by the public. A genuinely
-   remote/self-paced product where students access their account without an instructor in the
-   loop needs real credentials (email+password, or a magic link) — reusing the same
-   `password_hash`/`scrypt` machinery `instructors` already has (`src/auth/password.js`) would
-   be the natural extension, not a new auth system. **This is the one item on this list that
-   would actually block self-paced delivery today** — everything else already works or is a
-   product decision, not an infrastructure one.
+2. ~~**No real student authentication.**~~ **Closed in Phase 5A.** Students now have real
+   credentials (email+password or login-identifier+password, `password_hash`/`scrypt` reusing
+   `instructors`' exact `src/auth/password.js`), a first-login/reset token flow, and Postgres-
+   backed rate-limited/CSRF-protected sessions on the same `sessions` table instructors use — see
+   `docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md`. The old bare-`student_id` `POST
+   /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. This document exists so Phase 5 planning
-starts from an accurate picture of the gap (one real item: student authentication) instead of a
-guess.
+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_REMOTE_CLASSROOM.md

@@ -0,0 +1,53 @@
+# Runbook: Running a Remote Classroom
+
+Covers scheduling, running, and recovering a live class through `/admin` → Classroom. See
+`docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md` for the underlying design. RootNode does
+**not** provide video/voice — the meeting URL field just links out to Meet/Zoom/Teams/whatever
+you already use for that.
+
+**Before class: schedule it**
+
+`/admin` → Classroom → pick the cohort → Schedule a class. Title is required; scheduled start,
+description, and a meeting URL are optional. Only one class can be `live` per cohort at a time —
+scheduling a second one is fine, starting it while another is live is rejected.
+
+**Right before class: Prepare Labs**
+
+Open the classroom → Prepare Labs. This provisions/warms every enrolled student's Lab ahead of
+time (same underlying flow as the cohort-level Prepare Labs button) so nobody is waiting on a
+cold start once class begins. If a Lab host is at capacity, that student shows as
+`capacity_waiting` in the results rather than failing silently — check back or ease off other
+concurrent load.
+
+**Start class**
+
+Open the classroom → Start class. Status moves to `live`; students now see a "LIVE NOW" banner
+on their Classroom tab and can join.
+
+**During class**
+
+- **Participants table**: presence (`online`/`recently_active`/`offline`, derived from each
+  student's last heartbeat — not a hard real-time signal, allow ~30s of lag), Lab status, and a
+  one-line current-work snapshot (stage, scenario, validation failures, hints used).
+- **Set current activity**: enter a scenario ID and Set. This only shows students a link — it
+  never redirects their browser or marks anything complete. Use it to say "everyone open this
+  next," not to force navigation.
+- **Post an announcement**: short messages, shown newest-first on the student side.
+- **Help queue**: students flag `lab_problem` / `dont_understand` / `validation_failing` /
+  `other` with an optional note. Acknowledge when you've seen it, Resolve when it's handled.
+  There is no chat here — if it needs back-and-forth, use your actual video call.
+
+**End of class**
+
+Open the classroom → End class. Status moves to `ended`; this does not touch Labs or student
+progress — destroy Labs separately from the cohort view if you're done with them for the day.
+
+**If you need to cancel a scheduled (not yet started) class:** Cancel, from the classroom
+detail view. A `live` class can only be ended, not cancelled.
+
+**If the Platform API restarts mid-class** (deploy, crash, host reboot): nothing to do. Sessions,
+the live classroom row, and participant presence all live in Postgres, not in the API process's
+memory — students' browsers keep their existing session and heartbeat right through it, and the
+dashboard shows the same state a few seconds after the API comes back. This is exercised for
+real in `infra/scripts/drills/test-phase5a-rehearsal.js`, which restarts the API mid-rehearsal
+and asserts on exactly this.

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

@@ -0,0 +1,52 @@
+# Runbook: Student Account Lifecycle
+
+Covers creating, converting, resetting, and revoking student accounts. See
+`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>`. 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):
+
+Same as creation, but for a student who already exists with progress/attempts/achievements —
+none of that is touched. Give an email or login ID, get a one-time activation link the same way.
+
+**Bulk import via CSV** (Students → Bulk import):
+
+Columns: `display_name, email, login_identifier, cohort_id` (only `display_name` is required per
+row). The whole file is validated before anything is written — one bad row rejects the entire
+file with a list of row errors, rather than importing some rows and skipping others. Never
+include a password column; it will always be rejected if present. Activation links for every
+created row are shown once after a successful import.
+
+**Reset a student's password** (Students → \[student\] → Reset password):
+
+Only for already-credentialed accounts. Issues a fresh reset link (`?reset=<token>`, valid 1
+hour) and immediately revokes every existing session for that student — the instructor still
+never sees or sets the actual password.
+
+**Revoke a student's sessions** (Students → \[student\] → Revoke all sessions):
+
+Immediately invalidates every active login for that student without touching their password.
+Use this if a device is lost/shared or a session looks compromised.
+
+**Deactivate a student** (Students → \[student\] → PATCH status: inactive, via the existing
+students list — deactivation takes effect on their very next request, not just their next
+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). 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

@@ -8,6 +8,10 @@ import AuditView from './AuditView'
 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,
@@ -20,8 +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'] },
 ]
@@ -59,8 +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/ClassroomView.jsx

@@ -0,0 +1,216 @@
+import { useState, useEffect, useCallback } from 'react'
+import { adminApi } from './api'
+import styles from './Admin.module.css'
+
+const DASHBOARD_POLL_MS = 5000
+
+// Phase 5A §14/§21 — remote classroom control center. Cohort picker -> that cohort's
+// classroom sessions -> a live dashboard once one is open. No video/chat/shell-takeover here
+// by design (§37) — this is identity/presence/Lab-status/help-queue/announcements only.
+export default function ClassroomView() {
+  const [cohorts, setCohorts] = useState(null)
+  const [cohortId, setCohortId] = useState('')
+  const [classrooms, setClassrooms] = useState(null)
+  const [selected, setSelected] = useState(null)
+  const [error, setError] = useState(null)
+
+  useEffect(() => { adminApi.cohorts().then((rows) => { setCohorts(rows); if (rows.length) setCohortId(rows[0].cohort_id) }).catch((e) => setError(e.message)) }, [])
+
+  const reload = useCallback(() => {
+    if (!cohortId) return
+    adminApi.classrooms(cohortId).then(setClassrooms).catch((e) => setError(e.message))
+  }, [cohortId])
+  useEffect(reload, [reload])
+
+  if (selected) return <ClassroomDashboard classroomId={selected} onBack={() => { setSelected(null); reload() }} />
+
+  return (
+    <>
+      {error && <div className={styles.errorBox}>{error}</div>}
+      <div className={styles.card}>
+        <h2>Classroom</h2>
+        <div className={styles.formRow}>
+          <div><label className={styles.label}>Cohort</label>
+            <select className={styles.select} value={cohortId} onChange={(e) => setCohortId(e.target.value)}>
+              {cohorts?.map((c) => <option key={c.cohort_id} value={c.cohort_id}>{c.name}</option>)}
+            </select></div>
+        </div>
+      </div>
+
+      {cohortId && (
+        <div className={styles.card}>
+          <h3>Schedule a class</h3>
+          <CreateClassroomForm cohortId={cohortId} onCreated={reload} />
+        </div>
+      )}
+
+      <div className={styles.card}>
+        <h3>Classes</h3>
+        {!classrooms ? <p className={styles.muted}>Loading…</p> : classrooms.length === 0 ? <p className={styles.muted}>None yet.</p> : (
+          <table>
+            <thead><tr><th>Title</th><th>Status</th><th>Scheduled</th><th /></tr></thead>
+            <tbody>
+              {classrooms.map((c) => (
+                <tr key={c.classroom_session_id}>
+                  <td>{c.title}</td>
+                  <td><span className={`${styles.pill} ${c.status === 'live' ? styles.pillOk : c.status === 'cancelled' ? styles.pillErr : styles.pillMuted}`}>{c.status}</span></td>
+                  <td>{c.scheduled_start ? new Date(c.scheduled_start).toLocaleString() : '—'}</td>
+                  <td><button className={styles.linkBtn} onClick={() => setSelected(c.classroom_session_id)}>Open</button></td>
+                </tr>
+              ))}
+            </tbody>
+          </table>
+        )}
+      </div>
+    </>
+  )
+}
+
+function CreateClassroomForm({ cohortId, onCreated }) {
+  const [title, setTitle] = useState('')
+  const [description, setDescription] = useState('')
+  const [scheduledStart, setScheduledStart] = useState('')
+  const [meetingUrl, setMeetingUrl] = useState('')
+  const [busy, setBusy] = useState(false)
+  const [error, setError] = useState(null)
+
+  const submit = async (e) => {
+    e.preventDefault()
+    setBusy(true); setError(null)
+    try {
+      await adminApi.createClassroom(cohortId, {
+        title: title.trim(), description: description.trim() || undefined,
+        scheduled_start: scheduledStart || undefined, meeting_url: meetingUrl.trim() || undefined,
+      })
+      setTitle(''); setDescription(''); setScheduledStart(''); setMeetingUrl('')
+      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}>Title</label>
+          <input className={styles.input} value={title} onChange={(e) => setTitle(e.target.value)} required /></div>
+        <div><label className={styles.label}>Scheduled start</label>
+          <input className={styles.input} type="datetime-local" value={scheduledStart} onChange={(e) => setScheduledStart(e.target.value)} /></div>
+        <div><label className={styles.label}>Meeting URL (Meet/Zoom/Teams — optional)</label>
+          <input className={styles.input} value={meetingUrl} onChange={(e) => setMeetingUrl(e.target.value)} /></div>
+      </div>
+      <label className={styles.label}>Description (optional)</label>
+      <input className={styles.input} value={description} onChange={(e) => setDescription(e.target.value)} />
+      <button className={styles.btn} style={{ marginTop: '0.75rem' }} disabled={busy || !title.trim()}>{busy ? 'Scheduling…' : 'Schedule'}</button>
+    </form>
+  )
+}
+
+function ClassroomDashboard({ classroomId, onBack }) {
+  const [data, setData] = useState(null)
+  const [error, setError] = useState(null)
+  const [notice, setNotice] = useState(null)
+  const [busy, setBusy] = useState(false)
+  const [announcement, setAnnouncement] = useState('')
+  const [activityScenario, setActivityScenario] = useState('')
+
+  const reload = useCallback(() => {
+    adminApi.classroomDashboard(classroomId).then(setData).catch((e) => setError(e.message))
+  }, [classroomId])
+  useEffect(() => {
+    reload()
+    const t = setInterval(reload, DASHBOARD_POLL_MS) // presence/help-queue/Lab-status all move live — poll rather than a second push channel
+    return () => clearInterval(t)
+  }, [reload])
+
+  const withBusy = (fn) => async () => {
+    setBusy(true); setError(null); setNotice(null)
+    try { await fn(); reload() } catch (e) { setError(e.message) } finally { setBusy(false) }
+  }
+
+  if (!data) return <>{error ? <div className={styles.errorBox}>{error}</div> : <p className={styles.muted}>Loading…</p>}</>
+  const { classroom, students, announcements, help_requests: helpRequests } = data
+  const openHelp = helpRequests.filter((h) => h.status !== 'resolved')
+
+  return (
+    <>
+      <button className={styles.linkBtn} onClick={onBack}>&larr; Back to classes</button>
+      <div className={styles.card} style={{ marginTop: '1rem' }}>
+        <h2>{classroom.title} <span className={`${styles.pill} ${classroom.status === 'live' ? styles.pillOk : styles.pillMuted}`}>{classroom.status}</span></h2>
+        {error && <div className={styles.errorBox}>{error}</div>}
+        {notice && <p className={styles.muted}>{notice}</p>}
+        <div className={styles.formRow}>
+          {classroom.status === 'scheduled' && <button className={styles.btn} disabled={busy} onClick={withBusy(() => adminApi.startClassroom(classroomId))}>Start class</button>}
+          {classroom.status === 'live' && <button className={styles.btnSecondary} disabled={busy} onClick={withBusy(() => adminApi.endClassroom(classroomId))}>End class</button>}
+          {classroom.status === 'scheduled' && <button className={styles.btnDanger} disabled={busy} onClick={withBusy(() => adminApi.cancelClassroom(classroomId))}>Cancel</button>}
+          <button className={styles.btnSecondary} disabled={busy} onClick={withBusy(async () => {
+            const { results } = await adminApi.prepareClassroomLabs(classroomId)
+            setNotice(`Labs prepared: ${results.length} student(s).`)
+          })}>Prepare Labs</button>
+        </div>
+      </div>
+
+      <div className={styles.card}>
+        <h3>Participants ({students.length})</h3>
+        {students.length === 0 ? <p className={styles.muted}>No one enrolled in this cohort yet.</p> : (
+          <table>
+            <thead><tr><th>Student</th><th>Presence</th><th>Lab</th><th>Current work</th><th>Hints</th></tr></thead>
+            <tbody>
+              {students.map((s) => (
+                <tr key={s.student_id}>
+                  <td>{s.display_name}</td>
+                  <td><span className={`${styles.pill} ${s.presence === 'online' ? styles.pillOk : s.presence === 'recently_active' ? styles.pillWarn : styles.pillMuted}`}>{s.presence}</span></td>
+                  <td><span className={`${styles.pill} ${s.lab_status === 'running' ? styles.pillOk : s.lab_status === 'error' ? styles.pillErr : styles.pillMuted}`}>{s.lab_status}</span></td>
+                  <td className={styles.muted}>{s.current_scenario || '—'} {s.attempt_status ? `(${s.attempt_status}, ${s.validation_failures} fails)` : ''}</td>
+                  <td className={styles.muted}>{s.hints_used}</td>
+                </tr>
+              ))}
+            </tbody>
+          </table>
+        )}
+      </div>
+
+      <div className={styles.card}>
+        <h3>Help queue {openHelp.length > 0 && <span className={`${styles.pill} ${styles.pillWarn}`}>{openHelp.length} open</span>}</h3>
+        {helpRequests.length === 0 ? <p className={styles.muted}>No help requests.</p> : (
+          <table>
+            <thead><tr><th>Student</th><th>Category</th><th>Message</th><th>Status</th><th /></tr></thead>
+            <tbody>
+              {helpRequests.map((h) => (
+                <tr key={h.help_request_id}>
+                  <td>{h.display_name || h.student_id}</td>
+                  <td className={styles.muted}>{h.category}</td>
+                  <td className={styles.muted}>{h.message || '—'}</td>
+                  <td><span className={`${styles.pill} ${h.status === 'resolved' ? styles.pillOk : h.status === 'acknowledged' ? styles.pillWarn : styles.pillErr}`}>{h.status}</span></td>
+                  <td>
+                    {h.status === 'open' && <button className={styles.linkBtn} onClick={withBusy(() => adminApi.acknowledgeHelpRequest(h.help_request_id))}>Acknowledge</button>}
+                    {h.status !== 'resolved' && <button className={styles.linkBtn} onClick={withBusy(() => adminApi.resolveHelpRequest(h.help_request_id))}>Resolve</button>}
+                  </td>
+                </tr>
+              ))}
+            </tbody>
+          </table>
+        )}
+      </div>
+
+      <div className={styles.card}>
+        <h3>Current activity</h3>
+        <p className={styles.muted}>Guidance only — students see this as a link, nothing auto-redirects them (§20).</p>
+        <div className={styles.formRow}>
+          <div><input className={styles.input} placeholder="scenario id" value={activityScenario} onChange={(e) => setActivityScenario(e.target.value)} /></div>
+          <div><button className={styles.btn} disabled={busy || !activityScenario.trim()} onClick={withBusy(async () => { await adminApi.setClassroomActivity(classroomId, activityScenario.trim()); setActivityScenario('') })}>Set</button></div>
+        </div>
+      </div>
+
+      <div className={styles.card}>
+        <h3>Announcements</h3>
+        {announcements.length === 0 ? <p className={styles.muted}>None yet.</p> : (
+          <ul>{announcements.map((a) => <li key={a.announcement_id} className={styles.muted}>{a.message}</li>)}</ul>
+        )}
+        <div className={styles.formRow} style={{ marginTop: '0.5rem' }}>
+          <div><input className={styles.input} placeholder="Post an announcement" value={announcement} onChange={(e) => setAnnouncement(e.target.value)} /></div>
+          <div><button className={styles.btn} disabled={busy || !announcement.trim()} onClick={withBusy(async () => { await adminApi.postClassroomAnnouncement(classroomId, announcement.trim()); setAnnouncement('') })}>Post</button></div>
+        </div>
+      </div>
+    </>
+  )
+}

frontend/src/admin/CohortsView.jsx

@@ -101,7 +101,7 @@ function CohortDetail({ cohortId, canManage, onBack }) {
     if (!newStudentName.trim()) return
     setBusy(true); setError(null)
     try {
-      await adminApi.createStudent(newStudentName.trim(), cohortId)
+      await adminApi.createStudent({ display_name: newStudentName.trim(), cohort_id: cohortId })
       setNewStudentName('')
       reload()
     } catch (e) { setError(e.message) } finally { setBusy(false) }

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

@@ -3,57 +3,190 @@ import { adminApi } from './api'
 import { StatusPill } from './CohortsView'
 import styles from './Admin.module.css'
 
-export default function StudentsView() {
+// Phase 5A §4-7: student roster now shows credential status alongside the pilot fields that
+// were already here. canManage gates create/convert/reset/revoke/import the same way
+// CohortsView gates cohort management — the server (requireAdminOrOwner) is the real boundary,
+// this just avoids showing controls a plain instructor would get a 403 from.
+export default function StudentsView({ role }) {
   const [students, setStudents] = useState(null)
   const [selected, setSelected] = useState(null)
   const [error, setError] = useState(null)
+  const canManage = role !== 'instructor'
 
   const reload = useCallback(() => {
     adminApi.students().then(setStudents).catch((e) => setError(e.message))
   }, [])
   useEffect(reload, [reload])
 
-  if (selected) return <StudentDetail studentId={selected} onBack={() => { setSelected(null); reload() }} />
+  if (selected) return <StudentDetail studentId={selected} canManage={canManage} onBack={() => { setSelected(null); reload() }} />
 
   return (
-    <div className={styles.card}>
-      <h2>Students ({students?.length ?? '…'})</h2>
+    <>
       {error && <div className={styles.errorBox}>{error}</div>}
-      {students && (
-        <table>
-          <thead><tr><th>Name</th><th>ID</th><th>Status</th><th>Last active</th><th /></tr></thead>
-          <tbody>
-            {students.map((s) => (
-              <tr key={s.student_id}>
-                <td>{s.display_name}</td>
-                <td className={styles.muted}>{s.student_id}</td>
-                <td><span className={`${styles.pill} ${s.status === 'active' ? styles.pillOk : styles.pillMuted}`}>{s.status}</span></td>
-                <td>{s.last_active_at ? new Date(s.last_active_at).toLocaleString() : 'never'}</td>
-                <td><button className={styles.linkBtn} onClick={() => setSelected(s.student_id)}>Open</button></td>
-              </tr>
-            ))}
-          </tbody>
-        </table>
+      {canManage && (
+        <div className={styles.card}>
+          <h2>Add student</h2>
+          <CreateStudentForm onCreated={reload} />
+        </div>
       )}
-    </div>
+      {canManage && (
+        <div className={styles.card}>
+          <h2>Bulk import (CSV)</h2>
+          <ImportForm onImported={reload} />
+        </div>
+      )}
+      <div className={styles.card}>
+        <h2>Students ({students?.length ?? '…'})</h2>
+        {students && (
+          <table>
+            <thead><tr><th>Name</th><th>ID</th><th>Login</th><th>Status</th><th>Last active</th><th /></tr></thead>
+            <tbody>
+              {students.map((s) => (
+                <tr key={s.student_id}>
+                  <td>{s.display_name}</td>
+                  <td className={styles.muted}>{s.student_id}</td>
+                  <td>
+                    {s.has_credentials
+                      ? <span className={`${styles.pill} ${styles.pillOk}`}>{s.email || s.login_identifier}</span>
+                      : <span className={`${styles.pill} ${styles.pillMuted}`}>pilot (no login)</span>}
+                  </td>
+                  <td><span className={`${styles.pill} ${s.status === 'active' ? styles.pillOk : styles.pillMuted}`}>{s.status}</span></td>
+                  <td>{s.last_active_at ? new Date(s.last_active_at).toLocaleString() : 'never'}</td>
+                  <td><button className={styles.linkBtn} onClick={() => setSelected(s.student_id)}>Open</button></td>
+                </tr>
+              ))}
+            </tbody>
+          </table>
+        )}
+      </div>
+    </>
   )
 }
 
-function StudentDetail({ studentId, onBack }) {
+function CreateStudentForm({ onCreated }) {
+  const [displayName, setDisplayName] = useState('')
+  const [email, setEmail] = useState('')
+  const [loginIdentifier, setLoginIdentifier] = useState('')
+  const [cohortId, setCohortId] = useState('')
+  const [cohorts, setCohorts] = useState(null)
+  const [busy, setBusy] = useState(false)
+  const [error, setError] = useState(null)
+  const [created, setCreated] = useState(null) // { student_id, activation_token } — token shown exactly once
+
+  useEffect(() => { adminApi.cohorts().then(setCohorts).catch(() => {}) }, [])
+
+  const submit = async (e) => {
+    e.preventDefault()
+    setBusy(true); setError(null); setCreated(null)
+    try {
+      const result = await adminApi.createStudent({
+        display_name: displayName.trim(), cohort_id: cohortId || undefined,
+        email: email.trim() || undefined, login_identifier: loginIdentifier.trim() || undefined,
+      })
+      setCreated(result)
+      setDisplayName(''); setEmail(''); setLoginIdentifier('')
+      onCreated()
+    } catch (e) { setError(e.message) } finally { setBusy(false) }
+  }
+
+  return (
+    <form onSubmit={submit}>
+      {error && <div className={styles.errorBox}>{error}</div>}
+      {created?.activation_token && (
+        <div className={styles.errorBox} style={{ background: 'var(--green-dim)', color: 'var(--green)', borderColor: 'var(--green)' }}>
+          Account created ({created.student_id}). Activation link (share it out of band, shown once):<br />
+          <code>{`${window.location.origin}/?activate=${created.activation_token}`}</code>
+        </div>
+      )}
+      <div className={styles.formRow}>
+        <div><label className={styles.label}>Display name</label>
+          <input className={styles.input} value={displayName} onChange={(e) => setDisplayName(e.target.value)} required /></div>
+        <div><label className={styles.label}>Email (older/self-paced)</label>
+          <input className={styles.input} type="email" value={email} onChange={(e) => setEmail(e.target.value)} /></div>
+        <div><label className={styles.label}>Login ID (younger/managed)</label>
+          <input className={styles.input} value={loginIdentifier} onChange={(e) => setLoginIdentifier(e.target.value)} /></div>
+        <div><label className={styles.label}>Cohort (optional)</label>
+          <select className={styles.select} value={cohortId} onChange={(e) => setCohortId(e.target.value)}>
+            <option value="">— none —</option>
+            {cohorts?.map((c) => <option key={c.cohort_id} value={c.cohort_id}>{c.name}</option>)}
+          </select></div>
+      </div>
+      <p className={styles.muted}>Leave email and login ID both blank to add a pilot (no-login) student.</p>
+      <button className={styles.btn} disabled={busy || !displayName.trim()}>{busy ? 'Adding…' : 'Add student'}</button>
+    </form>
+  )
+}
+
+function ImportForm({ onImported }) {
+  const [csv, setCsv] = useState('')
+  const [busy, setBusy] = useState(false)
+  const [error, setError] = useState(null)
+  const [rowErrors, setRowErrors] = useState(null)
+  const [created, setCreated] = useState(null)
+
+  const submit = async (e) => {
+    e.preventDefault()
+    setBusy(true); setError(null); setRowErrors(null); setCreated(null)
+    try {
+      const { created: rows } = await adminApi.importStudents(csv)
+      setCreated(rows); setCsv('')
+      onImported()
+    } catch (e) {
+      if (e.row_errors) setRowErrors(e.row_errors) // not thrown this way by the json() helper today; message covers it below
+      setError(e.message)
+    } finally { setBusy(false) }
+  }
+
+  return (
+    <form onSubmit={submit}>
+      <p className={styles.muted}>Columns: <code>display_name, email, login_identifier, cohort_id</code> (email/login_identifier/cohort_id optional per row). Never include a password column — the whole file is validated before anything is imported.</p>
+      {error && <div className={styles.errorBox}>{error}</div>}
+      {rowErrors && (
+        <div className={styles.errorBox}>{rowErrors.map((re, i) => <div key={i}>{re}</div>)}</div>
+      )}
+      {created && (
+        <div className={styles.errorBox} style={{ background: 'var(--green-dim)', color: 'var(--green)', borderColor: 'var(--green)' }}>
+          Imported {created.length} student(s). Activation links (shown once — copy before navigating away):
+          {created.filter((c) => c.activation_token).map((c) => (
+            <div key={c.student_id}><code>{c.display_name}: {window.location.origin}/?activate={c.activation_token}</code></div>
+          ))}
+        </div>
+      )}
+      <textarea className={styles.input} style={{ width: '100%', fontFamily: 'var(--mono)', minHeight: '6rem' }}
+        placeholder={'display_name,email,login_identifier,cohort_id\nJane Doe,[email protected],,'}
+        value={csv} onChange={(e) => setCsv(e.target.value)} required />
+      <button className={styles.btn} style={{ marginTop: '0.5rem' }} disabled={busy || !csv.trim()}>{busy ? 'Importing…' : 'Import'}</button>
+    </form>
+  )
+}
+
+function StudentDetail({ studentId, canManage, onBack }) {
+  const [student, setStudent] = useState(null)
   const [progress, setProgress] = useState(null)
   const [attempts, setAttempts] = useState(null)
   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)
 
   const reload = useCallback(() => {
+    adminApi.students().then((rows) => setStudent(rows.find((s) => s.student_id === studentId) || null)).catch(() => {})
     adminApi.studentProgress(studentId).then(setProgress).catch(() => {})
     // Phase 4.1 §16 — studentAttempts is now paginated; this panel only ever shows the most
     // recent page (labeled "Recent attempts," not a full history browser — see
     // /api/admin/students/:id/attempts's own pagination for the underlying capability).
     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])
 
@@ -72,6 +205,53 @@ function StudentDetail({ studentId, onBack }) {
       <button className={styles.linkBtn} onClick={onBack}>&larr; Back to students</button>
       <h2 style={{ margin: '1rem 0' }}>{studentId}</h2>
       {error && <div className={styles.errorBox}>{error}</div>}
+      {notice && <p className={styles.muted}>{notice}</p>}
+
+      {canManage && (
+        <div className={styles.card}>
+          <h3>Credentials</h3>
+          {student?.has_credentials ? (
+            <>
+              <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, 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>
@@ -101,6 +281,26 @@ function StudentDetail({ studentId, 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) => (
@@ -134,3 +334,35 @@ function StudentDetail({ studentId, onBack }) {
     </>
   )
 }
+
+function ConvertForm({ studentId, onDone }) {
+  const [email, setEmail] = useState('')
+  const [loginIdentifier, setLoginIdentifier] = useState('')
+  const [busy, setBusy] = useState(false)
+  const [error, setError] = useState(null)
+
+  const submit = async (e) => {
+    e.preventDefault()
+    setBusy(true); setError(null)
+    try {
+      const { activation_token } = await adminApi.convertStudent(studentId, {
+        email: email.trim() || undefined, login_identifier: loginIdentifier.trim() || undefined,
+      })
+      onDone(`Converted. Activation link (shown once): ${window.location.origin}/?activate=${activation_token}`)
+    } catch (e) { setError(e.message) } finally { setBusy(false) }
+  }
+
+  return (
+    <form onSubmit={submit}>
+      <p className={styles.muted}>Still a pilot account (no login). Give it an email or login ID to convert it to a real, password-protected account.</p>
+      {error && <div className={styles.errorBox}>{error}</div>}
+      <div className={styles.formRow}>
+        <div><label className={styles.label}>Email</label>
+          <input className={styles.input} type="email" value={email} onChange={(e) => setEmail(e.target.value)} /></div>
+        <div><label className={styles.label}>Login ID</label>
+          <input className={styles.input} value={loginIdentifier} onChange={(e) => setLoginIdentifier(e.target.value)} /></div>
+        <div><button className={styles.btn} disabled={busy || (!email.trim() && !loginIdentifier.trim())}>{busy ? 'Converting…' : 'Convert'}</button></div>
+      </div>
+    </form>
+  )
+}

frontend/src/admin/api.js

@@ -16,7 +16,9 @@ function getCookie(name) {
 async function json(res) {
   if (!res.ok) {
     const body = await res.json().catch(() => ({}))
-    throw new Error(body.message || body.error || `Request failed (${res.status})`)
+    const err = new Error(body.message || body.error || `Request failed (${res.status})`)
+    if (body.row_errors) err.row_errors = body.row_errors // Phase 5A §29 — CSV import row-level errors
+    throw err
   }
   return res.json()
 }
@@ -49,8 +51,14 @@ export const adminApi = {
   dashboard: () => get('/api/admin/dashboard'),
 
   students: () => get('/api/admin/students'),
-  createStudent: (display_name, cohort_id) => post('/api/admin/students', { display_name, cohort_id }),
+  createStudent: (fields) => post('/api/admin/students', fields),
   updateStudent: (id, fields) => patch(`/api/admin/students/${id}`, fields),
+  // ── Phase 5A §4-7/§29: credential lifecycle + CSV import ────────────────────────────────
+  convertStudent: (id, fields) => post(`/api/admin/students/${id}/convert`, fields),
+  resetStudentPassword: (id) => post(`/api/admin/students/${id}/reset-password`),
+  revokeStudentSessions: (id) => post(`/api/admin/students/${id}/revoke-sessions`),
+  studentSessions: (id) => get(`/api/admin/students/${id}/sessions`),
+  importStudents: (csv) => post('/api/admin/students/import', { csv }),
   studentProgress: (id) => get(`/api/admin/students/${id}/progress`),
   studentAttempts: (id, page = 1) => get(`/api/admin/students/${id}/attempts?page=${page}`), // Phase 4.1 §16 — paginated, see pagination.js
   studentEnvironment: (id) => get(`/api/admin/students/${id}/environment`),
@@ -95,4 +103,39 @@ export const adminApi = {
   assignAssessment: (id, cohort_id) => post(`/api/admin/assessments/${id}/assign`, { cohort_id }),
   assessmentSessions: (id, page = 1) => get(`/api/admin/assessments/${id}/sessions?page=${page}`), // Phase 4.1 §16 — paginated, see pagination.js
   cancelAssessmentSession: (sessionId) => post(`/api/admin/assessment-sessions/${sessionId}/cancel`),
+
+  // ── Phase 5A §14/§21: remote classroom control center ───────────────────────────────────
+  classrooms: (cohortId) => get(`/api/admin/cohorts/${cohortId}/classroom-sessions`),
+  createClassroom: (cohortId, fields) => post(`/api/admin/cohorts/${cohortId}/classroom-sessions`, fields),
+  classroomDashboard: (id) => get(`/api/admin/classroom-sessions/${id}`),
+  startClassroom: (id) => post(`/api/admin/classroom-sessions/${id}/start`),
+  endClassroom: (id) => post(`/api/admin/classroom-sessions/${id}/end`),
+  cancelClassroom: (id) => post(`/api/admin/classroom-sessions/${id}/cancel`),
+  prepareClassroomLabs: (id) => post(`/api/admin/classroom-sessions/${id}/prepare-labs`),
+  setClassroomActivity: (id, scenario_id) => post(`/api/admin/classroom-sessions/${id}/activity`, { scenario_id }),
+  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/ClassroomTab.jsx

@@ -0,0 +1,146 @@
+import { useState, useEffect, useCallback, useRef } from 'react'
+import { api } from './api'
+import styles from './Platform.module.css'
+
+const HEARTBEAT_MS = 25000  // §15 — "browser heartbeat every 20-30 seconds"
+const POLL_MS = 5000
+
+const HELP_CATEGORIES = [
+  { value: 'lab_problem', label: 'Lab problem' },
+  { value: 'dont_understand', label: "Don't understand the task" },
+  { value: 'validation_failing', label: 'Validation failing' },
+  { value: 'other', label: 'Other' },
+]
+
+// Phase 5A §22 — the live classroom experience. No live classroom -> a quiet "nothing live
+// right now" state. Live -> title, current activity (guidance only — a link into the student's
+// own Lab, never an auto-redirect), announcements, Need Help, and the student's own Lab status
+// (reusing the exact same /api/environment/* the My Learning tab uses — no second Lab-status
+// system). Heartbeats fire only while this tab is mounted and a classroom is actually joined.
+export default function ClassroomTab() {
+  const [live, setLive] = useState(null)
+  const [detail, setDetail] = useState(null)
+  const [envStatus, setEnvStatus] = useState(null)
+  const [joined, setJoined] = useState(false)
+  const [helpCategory, setHelpCategory] = useState('lab_problem')
+  const [helpMessage, setHelpMessage] = useState('')
+  const [helpSent, setHelpSent] = useState(false)
+  const [error, setError] = useState(null)
+  const heartbeatRef = useRef(null)
+  const pollRef = useRef(null)
+
+  const loadLive = useCallback(() => {
+    api.liveClassroom().then((r) => setLive(r.classroom)).catch((e) => setError(e.message))
+  }, [])
+  useEffect(() => { loadLive() }, [loadLive])
+
+  const loadDetail = useCallback((id) => {
+    api.classroom(id).then(setDetail).catch((e) => setError(e.message))
+    api.environmentStatus().then(setEnvStatus).catch(() => {})
+  }, [])
+
+  useEffect(() => {
+    if (!live) return
+    loadDetail(live.classroom_session_id)
+    pollRef.current = setInterval(() => loadDetail(live.classroom_session_id), POLL_MS)
+    return () => clearInterval(pollRef.current)
+  }, [live, loadDetail])
+
+  useEffect(() => {
+    if (!joined || !live) return
+    heartbeatRef.current = setInterval(() => api.classroomHeartbeat(live.classroom_session_id).catch(() => {}), HEARTBEAT_MS)
+    api.classroomHeartbeat(live.classroom_session_id).catch(() => {}) // one immediately on join, not just after the first interval
+    return () => clearInterval(heartbeatRef.current)
+  }, [joined, live])
+
+  const join = async () => {
+    try { await api.joinClassroom(live.classroom_session_id); setJoined(true) }
+    catch (e) { setError(e.message) }
+  }
+
+  const sendHelp = async (e) => {
+    e.preventDefault()
+    try {
+      await api.requestHelp(live.classroom_session_id, helpCategory, helpMessage)
+      setHelpSent(true); setHelpMessage('')
+    } catch (e) { setError(e.message) }
+  }
+
+  const launchLab = async () => {
+    try { setEnvStatus(await api.launchEnvironment()) } catch (e) { setError(e.message) }
+  }
+
+  if (!live) {
+    return (
+      <div className={styles.card}>
+        <h2>Classroom</h2>
+        <p className={styles.muted}>No live class right now. Check back at your scheduled class time.</p>
+      </div>
+    )
+  }
+
+  return (
+    <div>
+      <div className={styles.card}>
+        <p className={styles.livePill}>LIVE NOW</p>
+        <h2 style={{ margin: '0.4rem 0' }}>{live.title}</h2>
+        {live.description && <p className={styles.muted}>{live.description}</p>}
+        {live.meeting_url && (
+          <p><a className={styles.primaryBtn} href={live.meeting_url} target="_blank" rel="noreferrer">Join Video Class</a></p>
+        )}
+        {!joined ? (
+          <button className={styles.primaryBtn} onClick={join}>Join Classroom</button>
+        ) : (
+          <p className={styles.muted}>You're in this classroom.</p>
+        )}
+      </div>
+
+      {joined && detail && (
+        <>
+          {detail.classroom.current_scenario_id && (
+            <div className={styles.card}>
+              <h3>Current class activity</h3>
+              <p>{detail.classroom.current_scenario_id}</p>
+              <p className={styles.muted}>Open it from the My Learning tab when you're ready — nothing here jumps you there automatically.</p>
+            </div>
+          )}
+
+          <div className={styles.card}>
+            <h3>Your Lab</h3>
+            {envStatus?.status === 'running'
+              ? <p><a className={styles.primaryBtn} href={envStatus.launch_path}>Open Lab</a></p>
+              : <button className={styles.primaryBtn} onClick={launchLab} disabled={envStatus?.status === 'provisioning'}>
+                  {envStatus?.status === 'provisioning' ? 'Starting…' : 'Launch Lab'}
+                </button>}
+          </div>
+
+          <div className={styles.card}>
+            <h3>Announcements</h3>
+            {!detail.announcements.length ? <p className={styles.muted}>None yet.</p> : (
+              <ul>
+                {detail.announcements.map((a) => <li key={a.announcement_id}>{a.message}</li>)}
+              </ul>
+            )}
+          </div>
+
+          <div className={styles.card}>
+            <h3>Need help?</h3>
+            {helpSent ? <p className={styles.muted}>Help requested — your instructor has been notified.</p> : (
+              <form onSubmit={sendHelp}>
+                <label className={styles.label}>What's going on?</label>
+                <select className={styles.select} value={helpCategory} onChange={(e) => setHelpCategory(e.target.value)}>
+                  {HELP_CATEGORIES.map((c) => <option key={c.value} value={c.value}>{c.label}</option>)}
+                </select>
+                <label className={styles.label}>Details (optional)</label>
+                <input className={styles.input} value={helpMessage} onChange={(e) => setHelpMessage(e.target.value)} />
+                <button className={styles.primaryBtn} type="submit">Need Help</button>
+              </form>
+            )}
+          </div>
+        </>
+      )}
+
+      {error && <div className={styles.errorBox}>{error}</div>}
+    </div>
+  )
+}

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/ForgotPasswordScreen.jsx

@@ -0,0 +1,59 @@
+import { useState } from 'react'
+import { api } from './api'
+import styles from './Platform.module.css'
+
+// Phase 5A §6/§9 — self-service reset REQUEST. No email delivery exists yet
+// (docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md §5) — this always shows the same generic
+// message regardless of whether the identifier exists (anti-enumeration, matches the server's
+// own response shape exactly). In dev/test, the server includes dev_reset_token in its
+// response so this screen can offer a direct link — a real deployment omits it, and completing
+// the flow needs an instructor to run the admin-side reset instead (see
+// docs/RUNBOOK_RESET_STUDENT_PASSWORD.md).
+export default function ForgotPasswordScreen({ onCancel, onHaveToken }) {
+  const [identifier, setIdentifier] = useState('')
+  const [sent, setSent] = useState(null)
+  const [loading, setLoading] = useState(false)
+
+  const submit = async (e) => {
+    e.preventDefault()
+    setLoading(true)
+    try {
+      const result = await api.requestPasswordReset(identifier)
+      setSent(result)
+    } finally {
+      setLoading(false)
+    }
+  }
+
+  return (
+    <div className={styles.entryWrap}>
+      <div className={styles.entryCard}>
+        <div className={styles.brand}>
+          <span className={styles.brandIcon}>⎈</span> RootNode Academy
+        </div>
+        <p className={styles.tagline}>Reset your password</p>
+
+        {!sent ? (
+          <form onSubmit={submit}>
+            <label className={styles.label}>Email or login</label>
+            <input className={styles.input} type="text" value={identifier} onChange={(e) => setIdentifier(e.target.value)} required />
+            <button className={styles.primaryBtn} type="submit" disabled={loading}>{loading ? 'Sending…' : 'Send reset link'}</button>
+          </form>
+        ) : (
+          <>
+            <p style={{ color: 'var(--text-2)', fontSize: '0.9rem' }}>{sent.message}</p>
+            {sent.dev_reset_token && (
+              <p style={{ fontSize: '0.8rem', color: 'var(--text-3)' }}>
+                Dev/test only (never shown in production):{' '}
+                <button className={styles.linkBtn} onClick={() => onHaveToken(sent.dev_reset_token)}>use this reset token</button>
+              </p>
+            )}
+          </>
+        )}
+        <p style={{ marginTop: '1rem', textAlign: 'center' }}>
+          <button className={styles.linkBtn} onClick={onCancel}>Back to sign in</button>
+        </p>
+      </div>
+    </div>
+  )
+}

frontend/src/platform/LoginScreen.jsx

@@ -0,0 +1,63 @@
+import { useState } from 'react'
+import { api } from './api'
+import styles from './Platform.module.css'
+
+// Phase 5A §6 — the real, credentialed student login. This is now the default entry point
+// (see PlatformShell.jsx); EntryScreen (pilot, no password) is still reachable for
+// not-yet-converted accounts via the link at the bottom, not removed — see
+// docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md §7.
+export default function LoginScreen({ onLogin, onShowPilotEntry, onShowForgotPassword }) {
+  const [identifier, setIdentifier] = useState('')
+  const [password, setPassword] = useState('')
+  const [loading, setLoading] = useState(false)
+  const [error, setError] = useState(null)
+
+  const handleLogin = async (e) => {
+    e.preventDefault()
+    if (!identifier || !password) return
+    setLoading(true)
+    setError(null)
+    try {
+      const student = await api.studentLogin(identifier, password)
+      onLogin(student)
+    } catch (err) {
+      setError(err.message)
+    } finally {
+      setLoading(false)
+    }
+  }
+
+  return (
+    <div className={styles.entryWrap}>
+      <div className={styles.entryCard}>
+        <div className={styles.brand}>
+          <span className={styles.brandIcon}>⎈</span> RootNode Academy
+        </div>
+        <p className={styles.tagline}>Sign in to continue your learning.</p>
+
+        {error && <div className={styles.errorBox}>{error}</div>}
+
+        <form onSubmit={handleLogin}>
+          <label className={styles.label}>Email or login</label>
+          <input className={styles.input} type="text" autoComplete="username" value={identifier}
+            onChange={(e) => setIdentifier(e.target.value)} required />
+
+          <label className={styles.label}>Password</label>
+          <input className={styles.input} type="password" autoComplete="current-password" value={password}
+            onChange={(e) => setPassword(e.target.value)} required />
+
+          <button className={styles.primaryBtn} type="submit" disabled={loading}>
+            {loading ? 'Signing in…' : 'Sign in'}
+          </button>
+        </form>
+
+        <p style={{ marginTop: '1rem', textAlign: 'center' }}>
+          <button className={styles.linkBtn} onClick={onShowForgotPassword}>Forgot password?</button>
+        </p>
+        <p style={{ marginTop: '0.5rem', textAlign: 'center' }}>
+          <button className={styles.linkBtn} onClick={onShowPilotEntry}>Pick your name instead (pilot cohorts)</button>
+        </p>
+      </div>
+    </div>
+  )
+}

frontend/src/platform/Platform.module.css

@@ -36,7 +36,7 @@
 
 .label { display: block; font-size: 0.8rem; color: var(--text-2); margin: 0.9rem 0 0.3rem; }
 
-.select {
+.select, .input {
   width: 100%;
   padding: 0.55rem 0.6rem;
   background: var(--surface2);
@@ -45,6 +45,7 @@
   color: var(--text);
   font-family: var(--sans);
   font-size: 0.9rem;
+  box-sizing: border-box;
 }
 
 .primaryBtn {
@@ -179,5 +180,12 @@ table.dataTable { width: 100%; border-collapse: collapse; font-size: 0.85rem; }
 .pillErr { background: var(--red-dim); color: var(--red); }
 .pillMuted { background: var(--surface3); color: var(--text-2); }
 
+/* Phase 5A — classroom/profile screens */
+.livePill {
+  display: inline-block; background: var(--red-dim); color: var(--red); font-family: var(--mono);
+  font-size: 0.72rem; font-weight: 700; letter-spacing: 0.05em; padding: 0.2rem 0.6rem; border-radius: 999px;
+}
+.pager { display: flex; align-items: center; gap: 0.75rem; margin-top: 0.75rem; }
+
 .lockedBox { text-align: center; padding: 2rem 1rem; color: var(--text-2); }
 .checklistItem { display: flex; align-items: center; gap: 0.5rem; padding: 0.35rem 0; font-size: 0.88rem; }

frontend/src/platform/PlatformShell.jsx

@@ -1,17 +1,28 @@
 import { useState, useEffect } from 'react'
 import { api, getCachedDisplay } from './api'
+import LoginScreen from './LoginScreen'
 import EntryScreen from './EntryScreen'
+import SetPasswordScreen from './SetPasswordScreen'
+import ForgotPasswordScreen from './ForgotPasswordScreen'
 import StudentDashboard from './StudentDashboard'
 
-// Top-level Platform Shell: entry screen if no valid session, dashboard otherwise. Session
-// validity is decided by the server (GET /api/session/whoami against the rn_session cookie),
-// not by anything read from localStorage/sessionStorage — those only cache the display name
-// for a snappier first paint, per api.js.
+// Top-level Platform Shell. Phase 5A: the credentialed LoginScreen is now the default entry
+// point (was EntryScreen's pilot name-picker); an activation/reset link
+// (?activate=<token> or ?reset=<token>) short-circuits straight to SetPasswordScreen before
+// any session check, since neither flow requires an existing session. Session validity is
+// still decided by the server (GET /api/session/whoami against the rn_session cookie), not by
+// anything read from localStorage/sessionStorage.
 export default function PlatformShell() {
   const [student, setStudent] = useState(null)
   const [checking, setChecking] = useState(true)
+  const params = new URLSearchParams(window.location.search)
+  const [view, setView] = useState(
+    params.get('activate') ? 'activate' : params.get('reset') ? 'reset' : 'login'
+  )
+  const [resetToken, setResetToken] = useState(params.get('reset') || null)
 
   useEffect(() => {
+    if (view === 'activate' || view === 'reset') { setChecking(false); return }
     const cached = getCachedDisplay()
     if (cached) setStudent(cached) // optimistic paint while we confirm with the server
     api.whoami()
@@ -20,9 +31,29 @@ export default function PlatformShell() {
       })
       .catch(() => setStudent(null))
       .finally(() => setChecking(false))
-  }, [])
+  }, [view])
 
   if (checking) return null
-  if (!student) return <EntryScreen onLogin={setStudent} />
-  return <StudentDashboard student={student} onLogout={() => setStudent(null)} />
+
+  if (view === 'activate') {
+    return <SetPasswordScreen token={params.get('activate')} purpose="activation"
+      onDone={(s) => { setStudent(s); setView('dashboard'); window.history.replaceState({}, '', '/') }}
+      onCancel={() => { setView('login'); window.history.replaceState({}, '', '/') }} />
+  }
+  if (view === 'reset') {
+    return <SetPasswordScreen token={resetToken} purpose="reset"
+      onDone={() => { setView('login'); window.history.replaceState({}, '', '/') }}
+      onCancel={() => { setView('login'); window.history.replaceState({}, '', '/') }} />
+  }
+  if (view === 'forgot') {
+    return <ForgotPasswordScreen onCancel={() => setView('login')} onHaveToken={(t) => { setResetToken(t); setView('reset') }} />
+  }
+  if (view === 'pilot') {
+    return <EntryScreen onLogin={(s) => { setStudent(s); setView('dashboard') }} />
+  }
+  if (!student) {
+    return <LoginScreen onLogin={(s) => { setStudent(s); setView('dashboard') }}
+      onShowPilotEntry={() => setView('pilot')} onShowForgotPassword={() => setView('forgot')} />
+  }
+  return <StudentDashboard student={student} onLogout={() => { setStudent(null); setView('login') }} />
 }

frontend/src/platform/ProfileTab.jsx

@@ -0,0 +1,91 @@
+import { useState, useEffect } from 'react'
+import { api } from './api'
+import styles from './Platform.module.css'
+
+// Phase 5A §10 — minimal account/profile page. Deliberately narrow: identity, cohort, progress
+// summary, achievements, active session count, and change-password. No social/profile features.
+export default function ProfileTab() {
+  const [profile, setProfile] = useState(null)
+  const [error, setError] = useState(null)
+
+  useEffect(() => { api.profile().then(setProfile).catch((e) => setError(e.message)) }, [])
+
+  if (error) return <div className={styles.errorBox}>{error}</div>
+  if (!profile) return <p className={styles.muted}>Loading…</p>
+
+  return (
+    <div>
+      <div className={styles.card}>
+        <h2>Account</h2>
+        <p><strong>{profile.student.display_name}</strong></p>
+        <p className={styles.muted}>{profile.student.email || profile.student.login_identifier || 'No login identifier set'}</p>
+        <p className={styles.muted}>
+          {profile.cohorts.length ? profile.cohorts.map((c) => c.name).join(', ') : 'Not enrolled in a cohort yet'}
+        </p>
+        <p className={styles.muted}>{profile.active_sessions} active session{profile.active_sessions === 1 ? '' : 's'}</p>
+      </div>
+
+      <div className={styles.card}>
+        <h2>Progress</h2>
+        <p>{profile.progress_summary.completed} / {profile.progress_summary.total} scenarios completed</p>
+        <div className={styles.progressBarTrack}>
+          <div className={styles.progressBarFill} style={{ width: `${profile.progress_summary.total ? Math.round(100 * profile.progress_summary.completed / profile.progress_summary.total) : 0}%` }} />
+        </div>
+      </div>
+
+      <div className={styles.card}>
+        <h2>Achievements</h2>
+        {!profile.achievements.length ? <p className={styles.muted}>None yet — keep going!</p> : (
+          <ul>
+            {profile.achievements.map((a, i) => (
+              <li key={i}>{a.achievement_type.replace(/_/g, ' ')}{a.stage_id ? ` — ${a.stage_id}` : ''}</li>
+            ))}
+          </ul>
+        )}
+      </div>
+
+      <ChangePasswordCard hasCredentials={profile.student.has_credentials} />
+    </div>
+  )
+}
+
+function ChangePasswordCard({ hasCredentials }) {
+  const [oldPassword, setOldPassword] = useState('')
+  const [newPassword, setNewPassword] = useState('')
+  const [busy, setBusy] = useState(false)
+  const [notice, setNotice] = useState(null)
+  const [error, setError] = useState(null)
+
+  if (!hasCredentials) {
+    return (
+      <div className={styles.card}>
+        <h2>Change password</h2>
+        <p className={styles.muted}>This is still a pilot account with no password set. Ask your instructor to convert it to a real account first.</p>
+      </div>
+    )
+  }
+
+  const submit = async (e) => {
+    e.preventDefault()
+    setBusy(true); setError(null); setNotice(null)
+    try {
+      await api.changePassword(oldPassword, newPassword)
+      setNotice('Password updated.'); setOldPassword(''); setNewPassword('')
+    } catch (err) { setError(err.message) } finally { setBusy(false) }
+  }
+
+  return (
+    <div className={styles.card}>
+      <h2>Change password</h2>
+      {error && <div className={styles.errorBox}>{error}</div>}
+      {notice && <p className={styles.muted}>{notice}</p>}
+      <form onSubmit={submit}>
+        <label className={styles.label}>Current password</label>
+        <input className={styles.input} type="password" autoComplete="current-password" value={oldPassword} onChange={(e) => setOldPassword(e.target.value)} required />
+        <label className={styles.label}>New password</label>
+        <input className={styles.input} type="password" autoComplete="new-password" value={newPassword} onChange={(e) => setNewPassword(e.target.value)} required minLength={10} />
+        <button className={styles.primaryBtn} type="submit" disabled={busy}>{busy ? 'Saving…' : 'Update password'}</button>
+      </form>
+    </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/SetPasswordScreen.jsx

@@ -0,0 +1,76 @@
+import { useState, useEffect } from 'react'
+import { api } from './api'
+import styles from './Platform.module.css'
+
+// Phase 5A §5/§6 — one screen for both flows the credential token mechanism serves:
+// activation (first login, purpose='activation') and forgot-password (purpose='reset'). Same
+// UI, different API call and success copy.
+export default function SetPasswordScreen({ token, purpose, onDone, onCancel }) {
+  const [preview, setPreview] = useState(null)
+  const [previewError, setPreviewError] = useState(null)
+  const [password, setPassword] = useState('')
+  const [confirm, setConfirm] = useState('')
+  const [loading, setLoading] = useState(false)
+  const [error, setError] = useState(null)
+
+  useEffect(() => {
+    api.credentialTokenPreview(purpose, token).then(setPreview).catch((e) => setPreviewError(e.message))
+  }, [token, purpose])
+
+  const submit = async (e) => {
+    e.preventDefault()
+    if (password.length < 10) { setError('Password must be at least 10 characters.'); return }
+    if (password !== confirm) { setError('Passwords do not match.'); return }
+    setLoading(true)
+    setError(null)
+    try {
+      if (purpose === 'activation') {
+        const student = await api.activate(token, password)
+        onDone(student)
+      } else {
+        await api.resetPassword(token, password)
+        onDone(null) // reset doesn't log the browser in — every existing session was revoked, sign in fresh
+      }
+    } catch (err) {
+      setError(err.message)
+    } finally {
+      setLoading(false)
+    }
+  }
+
+  return (
+    <div className={styles.entryWrap}>
+      <div className={styles.entryCard}>
+        <div className={styles.brand}>
+          <span className={styles.brandIcon}>⎈</span> RootNode Academy
+        </div>
+        <p className={styles.tagline}>{purpose === 'activation' ? 'Set up your account' : 'Choose a new password'}</p>
+
+        {previewError && (
+          <div className={styles.errorBox}>
+            This link is invalid or has expired. Ask your instructor for a new one.
+          </div>
+        )}
+        {preview && <p style={{ color: 'var(--text-2)', fontSize: '0.9rem' }}>Hi, {preview.display_name}.</p>}
+        {error && <div className={styles.errorBox}>{error}</div>}
+
+        {!previewError && (
+          <form onSubmit={submit}>
+            <label className={styles.label}>New password</label>
+            <input className={styles.input} type="password" autoComplete="new-password" value={password}
+              onChange={(e) => setPassword(e.target.value)} required minLength={10} />
+            <label className={styles.label}>Confirm password</label>
+            <input className={styles.input} type="password" autoComplete="new-password" value={confirm}
+              onChange={(e) => setConfirm(e.target.value)} required minLength={10} />
+            <button className={styles.primaryBtn} type="submit" disabled={loading}>
+              {loading ? 'Saving…' : purpose === 'activation' ? 'Activate my account' : 'Set new password'}
+            </button>
+          </form>
+        )}
+        <p style={{ marginTop: '1rem', textAlign: 'center' }}>
+          <button className={styles.linkBtn} onClick={onCancel}>Back to sign in</button>
+        </p>
+      </div>
+    </div>
+  )
+}

frontend/src/platform/StudentDashboard.jsx

@@ -6,13 +6,19 @@ import PracticeTab from './PracticeTab'
 import AssessmentsTab from './AssessmentsTab'
 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' },
   { key: 'capstone', label: 'Capstone' },
   { key: 'achievements', label: 'Achievements' },
+  { key: 'profile', label: 'Profile' },
 ]
 
 // Student home — tabbed as of Phase 3B (docs/PHASE3B_LEARNING_AND_ASSESSMENT.md §10): My
@@ -41,10 +47,13 @@ export default function StudentDashboard({ student, onLogout }) {
       </nav>
 
       {tab === 'learning' && <MyLearningTab />}
+      {tab === 'programs' && <ProgramsTab />}
+      {tab === 'classroom' && <ClassroomTab />}
       {tab === 'practice' && <PracticeTab />}
       {tab === 'assessments' && <AssessmentsTab />}
       {tab === 'capstone' && <CapstoneTab />}
       {tab === 'achievements' && <AchievementsTab />}
+      {tab === 'profile' && <ProfileTab />}
     </div>
   )
 }

frontend/src/platform/api.js

@@ -83,4 +83,49 @@ export const api = {
   capstone: () => fetch('/api/capstone').then(json),
 
   achievements: () => fetch('/api/achievements').then(json),
+
+  // ── Phase 5A: real student accounts ─────────────────────────────────────────────────────
+  // No CSRF token for login/activate/reset-request/reset — same reasoning as the pilot login
+  // above: nothing authenticated exists yet to forge into.
+  studentLogin: async (identifier, password) => {
+    const { student } = await fetch('/api/student/login', {
+      method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ identifier, password }),
+    }).then(json)
+    cacheDisplay(student)
+    return student
+  },
+  activate: async (token, password) => {
+    const { student } = await fetch('/api/student/activate', {
+      method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ token, password }),
+    }).then(json)
+    cacheDisplay(student)
+    return student
+  },
+  credentialTokenPreview: (purpose, token) => fetch(`/api/student/credential-token/${purpose}?token=${encodeURIComponent(token)}`).then(json),
+  requestPasswordReset: (identifier) => fetch('/api/student/request-password-reset', {
+    method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ identifier }),
+  }).then(json),
+  resetPassword: (token, password) => fetch('/api/student/reset-password', {
+    method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ token, password }),
+  }).then(json),
+  changePassword: (old_password, new_password) => mutate('/api/student/change-password', { old_password, new_password }),
+  profile: () => fetch('/api/student/profile').then(json),
+
+  // ── Phase 5A: remote classroom ───────────────────────────────────────────────────────────
+  liveClassroom: () => fetch('/api/classroom/live').then(json),
+  classroom: (id) => fetch(`/api/classroom/${id}`).then(json),
+  classroomAnnouncements: (id) => fetch(`/api/classroom/${id}/announcements`).then(json),
+  joinClassroom: (id) => mutate(`/api/classroom/${id}/join`),
+  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/monitoring/prometheus/prometheus.yml.j2

@@ -83,11 +83,10 @@ scrape_configs:
       - target_label: __address__
         replacement: localhost:9115
 
-  # RootNode application metrics — see docs/OBSERVABILITY.md §"exposing /metrics" for the
-  # documented, NOT-YET-BUILT follow-up (Platform API/Gateway/Provisioner don't currently
-  # expose a Prometheus /metrics endpoint; this job is ready for when that lands, disabled
-  # until then rather than scraping a 404 forever).
-  # - job_name: rootnode-platform-api
-  #   static_configs:
-  #     - targets: ["api:4300"]
-  #   metrics_path: /metrics
+  # RootNode application metrics — Phase 5A §34 (platform/api/src/metrics.js): classroom/help-
+  # request/Lab-state gauges and student login counters. No student/instructor id or other
+  # high-cardinality value is ever a label here — see that file's header comment.
+  - job_name: rootnode-platform-api
+    static_configs:
+      - targets: ["api:4300"]
+    metrics_path: /metrics

infra/scripts/drills/run-phase5a-rehearsal.sh

@@ -0,0 +1,31 @@
+#!/usr/bin/env bash
+# Orchestrates the Phase 5A §30/§33 dress rehearsal: brings up the real dev stack, bootstraps
+# an owner, runs test-phase5a-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}"
+
+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] "P5A Rehearsal Owner" 'RehearsalPass!2026' )
+
+echo "==> Running the rehearsal"
+OWNER_EMAIL=[email protected] OWNER_PASSWORD='RehearsalPass!2026' \
+  node ../infra/scripts/drills/test-phase5a-rehearsal.js

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-phase5a-rehearsal.js

@@ -0,0 +1,178 @@
+#!/usr/bin/env node
+// Phase 5A §30/§33 — the student identity + remote classroom dress rehearsal. One continuous
+// narrative: an instructor rosters 5 PILOT students (no email/login_identifier — simulating the
+// real pre-Phase-5A population), each logs in the OLD bare-student_id way, picks up real
+// progress/attempt/achievement history, joins a live classroom, sends a help request, and the
+// Platform API is restarted MID-REHEARSAL to prove classroom/session/presence survive it. Two
+// of the five are then converted to real credentialed accounts and their entire prior history
+// (progress/attempts/achievements/cohort membership) is verified intact afterward — the actual
+// migration-safety check §33 asks for, run against a live stack rather than asserted in the
+// abstract. No framework, matching project convention (see test-fake-cohort-rehearsal.js).
+//
+// Run via run-phase5a-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 COHORT_ID = `p5a-rehearsal-${RUN_ID}`;
+
+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++; }
+}
+
+// Seeds one realistic progress/attempt/achievement record for a pilot student directly in
+// Postgres — standing in for months of real pre-Phase-5A usage without re-driving the full
+// Lab-exec/validation pipeline, which is already covered end-to-end by e2e-phase2a/2b.js.
+function seedHistory(studentId) {
+  const sql = `
+    INSERT INTO progress (student_id, scenario_id, status, attempts, completed_at, started_at)
+      VALUES ('${studentId}', 'intro-shell-basics', 'completed', 1, now() - interval '3 days', now() - interval '3 days');
+    INSERT INTO scenario_attempts (student_id, scenario_id, started_at, completed_at, result, validation_count)
+      VALUES ('${studentId}', 'intro-shell-basics', now() - interval '3 days', now() - interval '3 days', 'passed', 4);
+    INSERT INTO achievements (student_id, achievement_type, curriculum_path_id, stage_id)
+      VALUES ('${studentId}', 'stage_completed', 'rootnode-path', 'foundations');
+  `;
+  execSync(`docker compose -f docker-compose.dev.yml exec -T postgres psql -U postgres -d rootnode_platform -c "${sql.replace(/"/g, '\\"')}"`,
+    { cwd: `${__dirname}/../../../platform`, stdio: 'pipe' });
+}
+
+async function main() {
+  console.log('Phase 5A student identity / remote classroom dress rehearsal\n');
+
+  const instructor = makeSession(GW);
+  await instructor.request('POST', '/api/auth/instructor/login', { email: OWNER_EMAIL, password: OWNER_PASSWORD });
+
+  const names = ['Reh-Ada', 'Reh-Bo', 'Reh-Cy', 'Reh-Di', 'Reh-Ez'];
+  const students = {}; // name -> student_id
+  const sessions = {}; // name -> pilot login session
+
+  await step('instructor: create a cohort and roster 5 PILOT students (no email/login_identifier)', async () => {
+    await instructor.request('POST', '/api/admin/cohorts', { cohort_id: COHORT_ID, name: 'P5A Rehearsal Cohort' });
+    for (const name of names) {
+      const { body } = await instructor.request('POST', '/api/admin/students', { display_name: name, cohort_id: COHORT_ID });
+      assert.equal(body.activation_token, null, `${name} must be a plain pilot row — no email/login_identifier was given`);
+      students[name] = body.student_id;
+    }
+  });
+
+  await step('every pilot student logs in the OLD bare-student_id way, exactly as before Phase 5A', async () => {
+    for (const name of names) {
+      sessions[name] = makeSession(GW);
+      const { status } = await sessions[name].request('POST', '/api/login', { student_id: students[name] });
+      assert.equal(status, 200);
+    }
+  });
+
+  await step('seed realistic pre-existing progress/attempt/achievement history for two students', () => {
+    seedHistory(students['Reh-Ada']);
+    seedHistory(students['Reh-Bo']);
+  });
+
+  let classroomId;
+  await step('instructor: create and start a live classroom for the cohort', async () => {
+    const { body } = await instructor.request('POST', `/api/admin/cohorts/${COHORT_ID}/classroom-sessions`, { title: 'Rehearsal Live Class' });
+    classroomId = body.classroom_session_id;
+    const { status } = await instructor.request('POST', `/api/admin/classroom-sessions/${classroomId}/start`);
+    assert.equal(status, 200);
+  });
+
+  await step('all 5 students join the classroom and heartbeat', async () => {
+    for (const name of names) {
+      const { status } = await sessions[name].request('POST', `/api/classroom/${classroomId}/join`);
+      assert.equal(status, 200);
+      await sessions[name].request('POST', `/api/classroom/${classroomId}/heartbeat`);
+    }
+  });
+
+  await step('Reh-Cy sends a help request; instructor acknowledges it', async () => {
+    const { status } = await sessions['Reh-Cy'].request('POST', `/api/classroom/${classroomId}/help-request`, { category: 'lab_problem', message: 'stuck on validation' });
+    assert.equal(status, 201);
+    const { body: dash } = await instructor.request('GET', `/api/admin/classroom-sessions/${classroomId}`);
+    const req = dash.help_requests.find((h) => h.status === 'open');
+    assert.ok(req);
+    await instructor.request('POST', `/api/admin/help-requests/${req.help_request_id}/acknowledge`);
+  });
+
+  await step('instructor posts an announcement and sets current activity', async () => {
+    await instructor.request('POST', `/api/admin/classroom-sessions/${classroomId}/announcements`, { message: 'Welcome — start with the intro exercise.' });
+    await instructor.request('POST', `/api/admin/classroom-sessions/${classroomId}/activity`, { scenario_id: 'intro-shell-basics' });
+  });
+
+  // ── The restart: the whole point of §30's "prove recovery" requirement. ─────────────────
+  await step('Platform API restarts mid-rehearsal', () => {
+    execSync('docker compose -f docker-compose.dev.yml restart api', { cwd: `${__dirname}/../../../platform`, stdio: 'pipe' });
+  });
+  await new Promise((r) => setTimeout(r, 4000));
+
+  await step('after restart: the classroom is still live and every session still works, with no re-login', async () => {
+    for (const name of names) {
+      const { status } = await sessions[name].request('GET', `/api/classroom/live`);
+      assert.equal(status, 200);
+    }
+    const { body: dash } = await instructor.request('GET', `/api/admin/classroom-sessions/${classroomId}`);
+    assert.equal(dash.classroom.status, 'live');
+    assert.equal(dash.students.length, 5);
+    assert.equal(dash.announcements.length, 1);
+  });
+
+  await step('after restart: heartbeats and help requests still work normally', async () => {
+    const { status } = await sessions['Reh-Di'].request('POST', `/api/classroom/${classroomId}/heartbeat`);
+    assert.equal(status, 200);
+  });
+
+  // ── §33: convert two students mid-rehearsal, verify nothing was orphaned. ───────────────
+  let adaActivation, boActivation;
+  await step('instructor converts Reh-Ada and Reh-Bo to real credentialed accounts', async () => {
+    const a = await instructor.request('POST', `/api/admin/students/${students['Reh-Ada']}/convert`, { login_identifier: `p5a-reh-ada-${RUN_ID}` });
+    const b = await instructor.request('POST', `/api/admin/students/${students['Reh-Bo']}/convert`, { login_identifier: `p5a-reh-bo-${RUN_ID}` });
+    assert.equal(a.status, 200); assert.equal(b.status, 200);
+    adaActivation = a.body.activation_token; boActivation = b.body.activation_token;
+  });
+
+  await step('old bare-id pilot login is now refused for the converted two, still works for the other three', async () => {
+    const adaRetry = await makeSession(GW).request('POST', '/api/login', { student_id: students['Reh-Ada'] });
+    assert.equal(adaRetry.status, 409);
+    const cyStillWorks = await makeSession(GW).request('POST', '/api/login', { student_id: students['Reh-Cy'] });
+    assert.equal(cyStillWorks.status, 200);
+  });
+
+  let adaNewSession, boNewSession;
+  await step('Reh-Ada and Reh-Bo activate their new accounts and log in the NEW way', async () => {
+    adaNewSession = makeSession(GW);
+    boNewSession = makeSession(GW);
+    const a = await adaNewSession.request('POST', '/api/student/activate', { token: adaActivation, password: 'RehAdaPass123!' });
+    const b = await boNewSession.request('POST', '/api/student/activate', { token: boActivation, password: 'RehBoPass123!' });
+    assert.equal(a.status, 200); assert.equal(b.status, 200);
+  });
+
+  await step('every bit of prior history survived the conversion — nothing orphaned', async () => {
+    const adaProgress = await adaNewSession.request('GET', '/api/progress');
+    assert.equal(adaProgress.status, 200);
+    assert.ok(adaProgress.body.details['intro-shell-basics'], 'the seeded pre-conversion progress must still be visible under the new login');
+    assert.equal(adaProgress.body.details['intro-shell-basics'].status, 'completed');
+
+    const { body: dashAfter } = await instructor.request('GET', `/api/admin/classroom-sessions/${classroomId}`);
+    const adaRow = dashAfter.students.find((s) => s.student_id === students['Reh-Ada']);
+    assert.ok(adaRow, 'converted student must still be a classroom participant — same student_id throughout, nothing re-created');
+
+    const stillEnrolled = await instructor.request('GET', `/api/admin/cohorts/${COHORT_ID}/students`);
+    assert.ok(stillEnrolled.body.some((s) => s.student_id === students['Reh-Ada']), 'cohort membership must survive conversion');
+  });
+
+  await step('cleanup: end the classroom', async () => {
+    await instructor.request('POST', `/api/admin/classroom-sessions/${classroomId}/end`);
+  });
+
+  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-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); });