feat(root04): author Containers & Docker

Adds all 8 ROOT 04 modules (why containers exist, images & containers, Docker CLI, container
networking, container storage, Dockerfile & image build, Docker Compose, containers →
Kubernetes) — 43 activities, using the nested Docker Engine Phase 6D built and tested. Modules
1, 2, and 8 are conceptual (no lab by design) — the honest bridge module (M8) explicitly names
what Kubernetes adds beyond what this course already taught, without re-teaching Kubernetes
itself.

Adds 5 new hands-on Docker scenarios plus 2 MCQs, all against the real nested Docker Engine:
docker-cli-basics (run/exec/inspect a real container), docker-container-networking (a genuine
"works internally, unreachable from host" port-publishing failure, diagnosed and fixed by
recreating the container with the correct `-p` flag), docker-container-storage (a real
destroy/recreate cycle proving named-volume persistence, not just described), docker-build-image
(a real Dockerfile, a real build, a real custom image run), and docker-compose-multiservice (a
real two-service Compose application with a real published port). All tested end-to-end via the
real scenario-validation API, including negative tests.

Wires rootnode-containers-assessment (2 required + 4 random-draw scenarios) using the existing
Phase 3B assessment engine.

This completes the entire ROOT_ Foundations sequence (ROOT 01-04) — see
docs/PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md.

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

content/root/root-04-containers-and-docker/m08-containers-to-kubernetes/01-lesson-containers-to-kubernetes.md

@@ -0,0 +1,64 @@
+# Containers → Kubernetes
+
+## What you've actually built, across this entire course
+
+You can now package an application (Dockerfile), run it in isolation (containers), connect
+multiple containers together (networking, Compose), and persist their data reliably (volumes).
+That's a complete, real skill set for running an application on ONE machine. Kubernetes exists
+to answer the question this course deliberately never had to ask: **what happens when "one
+machine" isn't enough?**
+
+## What Docker already solves
+
+- **Application packaging** — a Dockerfile makes an environment reproducible anywhere.
+- **Process isolation** — a container is isolated from other processes on the same machine.
+- **Basic networking** — containers can reach each other and be reached from outside, on one
+  host.
+- **Basic multi-container orchestration** — Compose runs a small set of related containers
+  together, on one host.
+
+## What Kubernetes adds on top
+
+- **Scheduling** — deciding WHICH machine, out of potentially hundreds, a container should run
+  on — a question that doesn't exist when you only have one machine.
+- **Desired state and reconciliation** — you declare what SHOULD be running; Kubernetes
+  continuously works to make reality match that declaration, even after a machine fails.
+- **Controllers** — automated processes that watch and correct drift from desired state (the
+  generalized version of "restart it if it crashes," running constantly, across the whole
+  cluster).
+- **Service discovery at scale** — reaching "the right instance of a service" when there might
+  be dozens of them, spread across many machines, changing constantly.
+- **Health management** — automatically detecting an unhealthy container and replacing it,
+  without a human first noticing something's wrong.
+- **Scaling** — running more or fewer copies of something based on real demand, automatically.
+- **Rollout strategies** — deploying a new version across many running instances safely, with a
+  defined strategy for how to do it without an outage.
+- **Distributed orchestration** — coordinating ALL of the above across a fleet of machines as if
+  it were one system.
+
+## The honest bridge
+
+None of this makes Docker/containers obsolete — Kubernetes runs containers, using the exact
+container runtime concepts this course just taught. Kubernetes is the layer ABOVE containers
+that exists specifically because real production systems eventually need more than one machine,
+more reliability than manual restarts, and more automation than a human watching dashboards. You
+are not about to learn a replacement for what you just built — you're about to learn what
+happens when you need to run it at a scale one machine can't handle.
+
+## Instructor Notes
+
+**Lesson goal:** Deliver the explicit "why Kubernetes" answer this entire foundational half of
+ROOT_ has been building toward — students should be able to state, in their own words, what
+specifically Kubernetes adds that Docker alone doesn't.
+
+**Approximate timing:** 15 minutes read; 10 minutes live.
+
+**Common misconception to watch for:** treating Kubernetes as "a replacement for Docker" rather
+than "an orchestration layer that runs containers across many machines" — the container
+concepts from this entire course remain fully applicable inside Kubernetes.
+
+**Discussion question:** "Name one thing from this list (scheduling, desired state, controllers,
+service discovery, health management, scaling, rollout, distributed orchestration) that would be
+genuinely hard to do by hand with just `docker run` commands across many machines." (Almost any
+honest answer works — the point is feeling the real gap Kubernetes fills, not memorizing the
+list.)

content/root/root-04-containers-and-docker/m08-containers-to-kubernetes/02-knowledge-check.md

@@ -0,0 +1,40 @@
+# Knowledge Check: Containers → Kubernetes
+
+---
+
+**1. Does Kubernetes replace Docker/containers?**
+
+*Answer:* No — Kubernetes orchestrates containers across many machines; it runs on top of the
+same container concepts this course taught, not instead of them.
+
+---
+
+**2. Name one thing Kubernetes adds that a single-machine `docker run`/Compose setup
+fundamentally can't do.**
+
+*Answer:* Any reasonable answer from: scheduling across multiple machines, automatic
+reconciliation to a desired state after a failure, service discovery across many changing
+instances, automated health-based replacement, demand-based scaling, or coordinated rollout
+across a fleet.
+
+---
+
+**3. What does "desired state" mean, in the sense this lesson introduced it?**
+
+*Answer:* You declare what SHOULD be running; the orchestrator continuously works to make actual
+reality match that declaration, including automatically after a failure — rather than a person
+having to manually notice and fix drift.
+
+---
+
+**4. Why doesn't this course teach Kubernetes directly, ending here instead?**
+
+*Answer:* This course's job was building the container/Linux/Git foundation Kubernetes assumes
+— ROOT 05 builds on exactly this foundation to teach Kubernetes itself.
+
+## Instructor Notes
+
+**Facilitation:** Question 2 is worth collecting several different answers from the group — the
+variety itself is evidence the "why Kubernetes" question actually landed.
+
+**Approximate timing:** 5 minutes.

content/root/root-04-containers-and-docker/m08-containers-to-kubernetes/03-reflection.md

@@ -0,0 +1,33 @@
+# Reflection: You're Ready, By Design, Not By Accident
+
+## Reflection questions
+
+1. Look back across ROOT 01 (Linux/processes), ROOT 02 (networking/troubleshooting), ROOT 03
+   (Git), and ROOT 04 (containers). Which single skill do you expect to use MOST once you start
+   ROOT 05?
+2. Can you explain, in your own words and without looking anything up, why Kubernetes exists?
+   If you can't yet, which part of this module's lesson would you reread?
+
+## Real Ops takeaway
+
+**Every module across all four foundational courses was chosen deliberately to make THIS moment
+make sense.** Processes (ROOT 01) become container processes become Pods. Filesystem/storage
+(ROOT 01-02) becomes container volumes becomes Kubernetes storage. Networking/DNS/troubleshooting
+(ROOT 02) becomes container networking becomes Services/Ingress/NetworkPolicy. Git (ROOT 03)
+becomes the foundation for GitOps later. None of ROOT 05's content will be starting from zero —
+you are walking in already equipped, on purpose.
+
+This module — and the entire ROOT_ Foundations sequence (ROOT 01-04) — is complete. Continue to
+ROOT 05: Kubernetes Foundations.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 2 is the single best readiness check for
+this entire foundational sequence — a confident, correct answer here is real evidence students
+are ready for ROOT 05, not just that they clicked through four courses.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
+
+**Milestone note:** this is the last module of the entire ROOT_ Foundations sequence (ROOT 01-04)
+— consider a genuine celebratory moment here for a live cohort; this represents a real, complete
+skill foundation, not just a checkpoint.