feat(content): author the ROOT_ V1 orientation module and three practice-bank intro lessons

- root-01-m00-welcome-to-root: program overview + Lab-lifecycle orientation (disposable Labs, permanent progress, hints, reset/recreate, help-requests). - One short intro-lesson activity for each of the three bare practice-bank modules (root-06-m01, root-07-m01, root-10-m02), explaining what the bank is and why it has no per-scenario teaching of its own — the minimum real authoring needed for genuine self-paced readiness without reclassifying them optional (see the curriculum migrations). Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-26 18:33:09 -05:00
parent e48710a0be
commit f695b7c95d
6 changed files with 250 additions and 0 deletions
@@ -0,0 +1,66 @@
 # Welcome to ROOT_
 ROOT_ is RootNode Academy's path from "I can use a computer" to "I can run and repair real
 infrastructure." It's built for anyone roughly high-school age and up — including college
 students, career changers, help-desk technicians, junior sysadmins, and working developers who
 want to move into DevOps, cloud, or platform engineering. There's no strict age cutoff: what
 matters is whether you're ready for the material, not how old you are.
 ## Where ROOT_ goes
 ```
 ROOT 01  Computing & Linux Foundations
 ROOT 02  Linux Administration & Networking
 ROOT 03  Git & Collaborative Development
 ROOT 04  Containers & Docker
 ROOT 05  Kubernetes Foundations
 ROOT 06  Kubernetes Application Workloads
 ROOT 07  Kubernetes Networking & Configuration
 ROOT 09  Kubernetes Security
 ROOT 10  Kubernetes Troubleshooting & Observability
 ROOT 12  RootNode Real Ops
 CAPSTONE Operate and Recover a Production-Like Environment
 ```
 Each course builds on real skill from the one before it — you won't be asked to use a tool or
 concept that a previous course didn't already teach you. By the end, you'll have operated a real
 Kubernetes cluster, diagnosed and fixed real incidents, and demonstrated it in a hands-on
 capstone — not answered multiple-choice questions about it.
 ## How you'll actually learn
 Every module follows the same rhythm:
 **Learn → Practice → Lab → Troubleshoot → Validate**
 - **Learn** — a short lesson introduces one real concept, plainly, with no unexplained jargon.
 - **Practice** — a demonstration or guided exercise lets you see the concept applied before
  you're on your own with it.
 - **Lab** — you do the real thing yourself, in your own disposable Lab environment: a real
  Linux shell, real Git, real Docker, and (from ROOT 05 onward) a real Kubernetes cluster.
 - **Troubleshoot** — Labs are built to sometimes not go as planned on the first try, on purpose.
  Figuring out why something didn't work is as much the skill as doing it right the first time.
 - **Validate** — your Lab checks its own result. You'll know immediately whether you actually
  solved it, not just whether you think you did.
 ## Self-paced or instructor-led
 ROOT_ is built to work either way. If you're going through it on your own, every module gives you
 everything you need without a teacher in the room. If you're in an instructor-led class or camp,
 your instructor can see your progress, help when you're stuck, and add their own pacing and
 discussion on top of the same real curriculum — nothing about the platform changes between the
 two, only who else is watching your progress.
 ## Assessments and the Capstone
 A few courses end in a short formal assessment — a handful of real, timed Lab tasks (not a
 multiple-choice quiz) that check you can actually do what the course taught, not just recognize
 the right answer. The program ends with the **Capstone**: no more new teaching, just a
 production-like environment with real incidents to find and fix, the same way you would on the
 job.
 ## Your progress is permanent — your Lab is not
 One thing to know before you start: the Lab environment you work in is disposable and can be
 recreated at any time. Your academic progress is not. The next module covers exactly what that
 means and why it's nothing to worry about.
@@ -0,0 +1,55 @@
 # Your Disposable Lab
 Every hands-on Lab in ROOT_ gives you a real, isolated environment — a real Linux shell from
 ROOT 01 onward, real Git and Docker from ROOT 03-04, and a real Kubernetes cluster from ROOT 05
 onward. It's yours alone while you're working in it. Here's what you need to know before your
 first one.
 ## Disposable means disposable
 Your Lab environment can be recreated at any time — when you start a new Lab, when an
 instructor resets a classroom session, or if the environment needs to be refreshed. When that
 happens, **anything that only exists inside the Lab disappears**: files you created in the
 terminal, a local Git repository you initialized, a Docker container or image you built, a
 Kubernetes object you deployed. None of that is backed up, and none of it needs to be — it was
 never the point.
 ## Your academic progress is not disposable
 What IS permanent, stored on RootNode's servers the moment you earn it: which lessons you've
 read, which Labs you've completed, your assessment results, and your position in the course
 sequence. Recreating your Lab never erases any of that. You can lose a Lab entirely and pick up
 exactly where you left off in the course.
 ## How you know you actually solved it
 Every Lab task validates itself — when you think you're done, you run the check and get a real
 pass/fail answer immediately, based on the real state of your environment, not on your own
 guess. If it fails, that's useful information, not a penalty: it's telling you specifically what
 isn't right yet.
 ## If you get stuck
 Most Labs have hints available, revealed one at a time so you can try the next step yourself
 before seeing more. Using a hint doesn't cost you anything or affect your result — it's there to
 keep you moving, not to be avoided on principle. A formal, timed assessment may disable hints;
 if so, the assessment will tell you plainly before you start.
 If a Lab's environment itself seems broken rather than the task being hard (a command that
 should work doesn't, the environment won't start), use **Reset Scenario & Environment** to tear
 down and rebuild it cleanly rather than fighting a broken environment.
 ## If you're in an instructor-led session
 Your instructor can see your progress in real time and gets notified the moment you use **Need
 Help** — no need to wait to be noticed. Use it for anything: a Lab that seems broken, a concept
 that didn't click, or just wanting a second pair of eyes before you second-guess a working
 solution.
 ## Returning to the course
 When you're done with a Lab — pass or still stuck — you can always return to the course view and
 come back to it later. Nothing about leaving a Lab mid-task loses your place.
 You're ready. Let's start with how a computer actually runs the software you're about to spend
 this program controlling.
@@ -0,0 +1,31 @@
 # Knowledge Check: Welcome to ROOT_
 ---
 **1. If your Lab environment is recreated, what happens to a file you saved inside it, and
 what happens to your completed Labs so far?**
 *Answer:* The file disappears — nothing inside the Lab persists across a recreation. Your
 completed Labs and course progress are unaffected — those are stored on RootNode's servers, not
 in the Lab, and survive regardless of what happens to any Lab environment.
 **2. A Lab task fails your validation check. What should that tell you?**
 *Answer:* Specifically what isn't correct yet, based on the real current state of your
 environment — it's diagnostic information to act on, not a penalty.
 **3. Name one thing to try before assuming a Lab is "just broken."**
 *Answer:* Check the available hints (revealed one at a time), and if the environment itself
 genuinely seems broken rather than the task being hard, use Reset Scenario & Environment to
 rebuild it cleanly.
 ---
 ## Instructor Notes
 **Facilitation:** This is a good moment to actually demonstrate a Lab reset live if you have
 time — students remember "I saw it happen and nothing bad occurred" far better than being told
 it's safe.
 **Approximate timing:** 3 minutes.
@@ -0,0 +1,39 @@
 # Practice Bank: Deployments & Workloads
 This module is different from the ones before it. There's no new lesson here — you already got
 the real teaching in **Deployments, Scaling & Updates** and **Jobs, CronJobs & DaemonSets**. This
 is eight short, focused Labs that drill the exact same skills at speed: deploy, scale, roll
 forward, add a liveness probe, edit a live object, and reason about Jobs/CronJobs/DaemonSets
 without a guided walkthrough alongside you.
 ## Why this exists
 Real fluency with `kubectl` comes from repetition, not from reading about it a second time. Each
 Lab here is a small, self-contained task — no long setup, no new concepts — so you can move
 quickly and build the kind of muscle memory that matters when you're troubleshooting a real
 cluster under time pressure later in this program.
 ## How to use it
 Work through the eight Labs in order. If one takes you more than a few minutes, that's useful
 information — it usually means the earlier module's concept hasn't fully clicked yet, and it's
 worth a quick re-read of that lesson before continuing rather than pushing through by trial and
 error.
 ## Instructor Notes
 **Delivery:** This module has no lesson/demonstration/knowledge-check scaffolding by design — it
 is the original Phase 1-5 "workloads" scenario bank, reused here as a self-paced speed-practice
 set once the real teaching (root-06-m02/m03) has already landed. In an instructor-led cohort,
 this is a good candidate for a timed "workloads sprint" between the teaching modules and Jobs.
 **Capstone note:** These eight scenarios are also the exact set the pre-existing
 `rootnode-path.json` "workloads" stage requires to unlock the Capstone assessment (a separate,
 older mechanism from this course's own prerequisite chain — see
 docs/ROOT_V1_CURRICULUM_MANIFEST.md). Do not mark this module optional/is_required=false without
 re-checking that gate; a student can only be told to skip it if the Capstone gate itself is
 intentionally changed too.
 **Common mistake to watch for:** students treating the MCQ-style activities
 (jobs-cronjobs-mcq, daemonset-mcq, deployment-strategy-mcq) as throwaway trivia — they're
 checking the same conceptual judgment calls the reflection in root-06-m03 raised, just faster.
@@ -0,0 +1,29 @@
 # Practice Bank: Services & Networking
 Like the workloads practice bank before it, this module has no new lesson. **Services & Service
 Discovery** and **Ingress & NetworkPolicy Foundations** already taught the concepts. This is four
 short Labs that drill exposing a Deployment, reasoning about a NodePort, and resolving a Service
 by DNS from inside the cluster — the everyday networking moves you'll use constantly from here on.
 ## How to use it
 Work through the four Labs in order. Two of them (`services-mcq`, `expose-service-basics`) will
 feel familiar — you did a close variant of `expose-service-basics` in the earlier teaching
 module. That's intentional: it's the same skill under slightly different conditions, checking
 that it generalizes rather than that you memorized one exact command.
 ## Instructor Notes
 **Delivery:** No lesson/demonstration/knowledge-check scaffolding by design — this is the
 original Phase 1-5 "networking" scenario bank plus two extra Labs (`nodeport-task`,
 `dns-resolution-mcq`) not part of that original set, reused here as self-paced speed practice.
 **Capstone note:** `services-mcq` and `expose-service-basics` are the exact pair the
 pre-existing `rootnode-path.json` "networking" stage requires to unlock the Capstone assessment
 — a separate, older mechanism from this course's own prerequisite chain (see
 docs/ROOT_V1_CURRICULUM_MANIFEST.md). Do not mark this module optional/is_required=false without
 re-checking that gate.
 **Common mistake to watch for:** confusing a NodePort's cluster-internal ClusterIP with the
 node-level port it also opens — the DNS-resolution Lab is a good moment to have a student narrate
 out loud which address they expect to work from where.
@@ -0,0 +1,30 @@
 # Practice Bank: General Troubleshooting Operations
 **Kubernetes Health Probes & Troubleshooting** and **The RootNode Troubleshooting Framework**
 already taught you how to *think* about a broken cluster. This module is six short Labs that
 drill the individual `kubectl` operations you'll reach for while doing that thinking: pulling
 logs, copying files in and out of a container, running a one-off exec, cordoning a node, and
 reasoning about pod-to-node placement and log output.
 ## How to use it
 Work through the six Labs in order. None of them require the full Observe/Evidence/Hypothesis/
 Test/Repair/Validate/Prevent framework from the previous module — they're deliberately narrower,
 so you can build raw command fluency without also holding the whole framework in your head at
 the same time.
 ## Instructor Notes
 **Delivery:** No lesson/demonstration/knowledge-check scaffolding by design — this is the
 original Phase 1-5 "troubleshooting" scenario bank plus one extra Lab (`container-logging-mcq`)
 not part of that original set, reused here as self-paced speed practice.
 **Capstone note:** The five original Labs (`extract-logs-basics`, `kubectl-cp-basics`,
 `exec-command-basics`, `node-cordon-basics`, `pod-node-assignment-mcq`) are the exact set the
 pre-existing `rootnode-path.json` "troubleshooting" stage requires to unlock the Capstone
 assessment — a separate, older mechanism from this course's own prerequisite chain (see
 docs/ROOT_V1_CURRICULUM_MANIFEST.md). Do not mark this module optional/is_required=false without
 re-checking that gate.
 **Common mistake to watch for:** running `kubectl cp` with the source/destination arguments
 reversed — a good moment to have a student read the command back out loud before running it.