feat(root01): author Computing & Linux Foundations, and the real 01->05 prerequisite chain

Adds all 6 ROOT 01 modules (how computers run software, the shell, filesystem navigation, files & text, processes, users & permissions foundations), each with a real lesson, demonstration/guided exercise, knowledge check where warranted, a hands-on Lab, and a reflection — 35 activities, 29 new content files. Adds 6 new hands-on Linux scenarios (linux-inspect-hardware, linux-shell-basics, linux-filesystem-navigation, linux-files-and-text, linux-process-management, linux-permissions-foundations) plus 2 MCQ scenarios, using the existing generic scenario/ validation engine (docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md §1) — every one tested end-to-end via the real scenario setup/validate API, including negative tests confirming they correctly FAIL when not actually solved (e.g. the process-management scenario fails while the target process is still running; the permissions scenario is tested against a real `su - labuser` denial). Wires rootnode-linux-foundations-assessment (2 required + 4 random-draw scenarios) using the existing Phase 3B assessment engine. Adds a real, server-side ROOT 01->02->03->04->05 course prerequisite chain (courses.prerequisites) — verified live on two students: one who completed ROOT 01 sees ROOT 02 unlock; a fresh student sees ROOT 02 correctly locked while 03/04/05 stay vacuously satisfied (their own prerequisite courses are still empty). ROOT 06+ and the Capstone are unaffected. Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-26 12:59:52 -05:00
parent 87526bcf7f
commit 15b616274b
37 changed files with 1549 additions and 0 deletions
@@ -0,0 +1,58 @@
+# Linux and the Shell
+
+## What "Linux" actually means
+
+Linux is a **kernel** — the core piece of software from Module 1 that manages CPU, memory, and
+storage. What most people call "a Linux system" (Ubuntu, Debian, Fedora, Alpine...) is a
+**distribution**: the Linux kernel plus a chosen set of standard tools, package manager, and
+configuration conventions layered on top. Different distributions, same kernel underneath —
+which is why a command you learn on Ubuntu mostly still works on Alpine.
+
+## Shell vs. terminal
+
+These get used interchangeably but are different things:
+
+- The **terminal** is the window/program that displays text and sends your keystrokes somewhere.
+- The **shell** is the program actually interpreting what you type as commands — `bash` is the
+  shell this Lab uses. The terminal is just the display; the shell is the brain.
+
+## Command structure
+
+Every command follows roughly the same shape:
+
+```
+command [options] [arguments]
+```
+
+`ls -la /var/log` — `ls` is the command, `-la` are options (flags) that change its behavior,
+`/var/log` is the argument (what to act on). Options can usually be combined (`-l -a` = `-la`).
+
+## Exit codes: how a command reports success or failure
+
+Every command returns a number when it finishes: `0` means success, anything else (1-255) means
+some kind of failure. This isn't a Linux quirk — it's the exact mechanism scripts, CI pipelines,
+and (much later) Kubernetes health checks all rely on to know whether something worked. You can
+read the last command's exit code with the special variable `$?`.
+
+## Getting help without leaving the terminal
+
+- **Tab completion** — press Tab while typing a command or path; the shell completes it for you
+  or shows you the options. This is a genuine time-saver, not just a convenience.
+- **Command history** — press the Up arrow to recall previous commands; `history` lists them.
+- **`man <command>`** — the manual page for almost any command, with every option explained.
+  `man ls`, `man grep`, `man chmod` are all real, useful references — reaching for `man` before
+  a search engine is a habit worth building now.
+
+## Instructor Notes
+
+**Lesson goal:** Establish shell fluency vocabulary (shell vs. terminal, exit codes, options vs.
+arguments) that every later module assumes without re-explaining.
+
+**Approximate timing:** 15 minutes read; 10 minutes live with a short live demo of tab
+completion and `man`.
+
+**Common misconception to watch for:** students often think "Linux" and "the terminal" are the
+same thing — clarify the kernel/distribution/shell/terminal layering explicitly.
+
+**Demo idea:** live-type a command that fails (e.g. `ls /nonexistent`), then run `echo $?`
+immediately after to show the exit code in real time — more convincing than describing it.
@@ -0,0 +1,49 @@
+# Demonstration: Watching Exit Codes in Real Time
+
+## OBSERVE
+
+Run a command you know will succeed, then immediately check its exit code:
+
+```
+$ true
+$ echo $?
+0
+```
+
+## HYPOTHESIS
+
+Now predict: what will the exit code be if the command fails instead?
+
+## INSPECT
+
+Run a command that fails, and check immediately:
+
+```
+$ ls /this-does-not-exist
+ls: cannot access '/this-does-not-exist': No such file or directory
+$ echo $?
+2
+```
+
+## CHANGE
+
+Try a few other failing commands and note their codes: `grep nomatch /etc/hostname` (exit 1 —
+"no matches found," a different kind of failure than "file not found").
+
+## VERIFY
+
+Notice: exit codes aren't just "0 or 1" — different failures often get different non-zero
+codes. `0` always means success; the exact non-zero value's MEANING varies by command, but ANY
+non-zero value reliably means "something went wrong," which is the part every script actually
+relies on (`if command; then ... else ...`).
+
+## Instructor Notes
+
+**Demo goal:** Make the abstract "exit code" concept concrete by actually watching `$?` change
+in real time, immediately after each command — this is far more convincing live than described
+in prose.
+
+**Approximate timing:** 8 minutes live.
+
+**Common mistake to watch for:** running `echo $?` after ANY other command in between (even
+`ls`) silently checks the WRONG command's exit code — emphasize "check it immediately."
@@ -0,0 +1,37 @@
+# Knowledge Check: Linux and the Shell
+
+---
+
+**1. What's the difference between a shell and a terminal?**
+
+*Answer:* The terminal is the window/program that displays text and captures keystrokes; the
+shell (e.g. `bash`) is the program actually interpreting what you type as commands. The terminal
+is the display, the shell is the brain.
+
+---
+
+**2. A command exits with code `0`. What does that tell you?**
+
+*Answer:* It succeeded. `0` is the universal "success" convention every script and pipeline
+relies on; any non-zero value means some kind of failure occurred.
+
+---
+
+**3. You've typed half a long path and can't remember the rest. What should you press?**
+
+*Answer:* Tab — tab completion finishes the path (or shows the options) without you needing to
+type or remember it exactly.
+
+---
+
+**4. Where would you look to learn every option a command supports, without leaving the
+terminal?**
+
+*Answer:* Its manual page — `man <command>`.
+
+## Instructor Notes
+
+**Facilitation:** Question 1 is the one students most often blur together — worth confirming
+verbally before moving on.
+
+**Approximate timing:** 5 minutes.
@@ -0,0 +1,31 @@
+# Guided Exercise: Predict the Exit Code Before You Run It
+
+This is a paper exercise — commit to an answer before checking it in the Lab.
+
+## Your task
+
+For each command below, predict whether its exit code will be `0` (success) or non-zero
+(failure), and why:
+
+1. `cat /etc/hostname` (a file that exists)
+2. `cat /etc/does-not-exist-at-all` (a file that doesn't)
+3. `grep root /etc/passwd` (a pattern that's very likely present)
+4. `grep zzz-not-a-real-user /etc/passwd` (a pattern that's very likely absent)
+5. `mkdir /tmp/already-exists && mkdir /tmp/already-exists` (running the same `mkdir` twice)
+
+## A worked shape to check yourself against
+
+1. `0` — the file exists and is readable.
+2. Non-zero — the file doesn't exist, `cat` fails.
+3. `0` — `grep` succeeds (exit 0) when it finds at least one match.
+4. Non-zero (specifically `1`) — `grep` "fails" when it finds NO matches, even though nothing
+   went technically wrong. This is a common surprise: `grep`'s exit code means "did I find a
+   match," not "did an error occur."
+5. The SECOND `mkdir` fails (non-zero) — the directory already exists. The first one succeeds.
+
+## Instructor Notes
+
+**Facilitation:** Item 4 is the one worth pausing on — many students assume "no error message"
+means "exit code 0," and `grep`'s no-match convention is a good early counter-example.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced.
@@ -0,0 +1,25 @@
+# Reflection: Exit Codes Are Everywhere After This
+
+## Reflection questions
+
+1. Before this module, did you know commands returned a machine-readable success/failure
+   signal at all? What did you assume happened instead?
+2. Where do you think exit codes might matter later in ROOT_ — in a script, a CI pipeline, or
+   a container?
+
+## Real Ops takeaway
+
+**Every automated system you'll ever build or operate checks exit codes, not error messages.**
+A script deciding whether to continue, a CI pipeline deciding whether to deploy, and (much
+later) a container orchestrator deciding whether a process is healthy, all reduce to the exact
+same question this module taught you to answer by hand: did this exit `0` or not? Getting
+comfortable checking `$?` now means none of those later systems will feel like magic.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 2 previews Docker/Kubernetes health
+checks well before students get there — useful to name explicitly without going deep yet.
+
+**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.