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,55 @@
+# Navigating the Filesystem
+
+## Everything is one tree, starting at `/`
+
+Linux has exactly one filesystem tree, rooted at `/` (pronounced "root," unrelated to your
+username). Every file and directory, no matter what physical disk it's actually on, appears
+somewhere under this one tree — there's no separate "C:\" and "D:\" the way Windows shows
+multiple drives.
+
+## Absolute vs. relative paths
+
+An **absolute path** starts with `/` and always means the same location no matter where you
+currently are: `/home/student/notes.txt`. A **relative path** is interpreted relative to your
+CURRENT directory: `notes.txt` means something different depending on where you're standing
+when you type it. `.` means "this directory," `..` means "one directory up" — `cd ..` moves up
+one level, `cd ../..` moves up two.
+
+## Key commands
+
+- `pwd` — print your current directory (where am I?)
+- `ls` — list what's in a directory (`ls -la` shows hidden files and details)
+- `cd <path>` — change directory (absolute or relative)
+
+## Hidden files
+
+A file or directory starting with `.` (like `.bashrc` or `.config`) is "hidden" — `ls` skips it
+by default, `ls -a` shows it. This isn't a security feature, just a convention to keep
+configuration/metadata files out of the way of normal directory listings.
+
+## The important top-level directories (conceptually, not memorized)
+
+You don't need to memorize the entire Filesystem Hierarchy Standard, but recognizing these by
+purpose will save you real confusion later:
+
+- **`/etc`** — system-wide configuration files (nginx's config lives at `/etc/nginx/nginx.conf`)
+- **`/var`** — variable data that changes while the system runs: logs (`/var/log`), among others
+- **`/home`** — personal directories for regular users
+- **`/tmp`** — temporary files, safe to assume anything here can disappear on reboot
+- **`/usr`** — most installed programs and their supporting files live somewhere under here
+- **`/proc`** — not real files on disk at all — a live, kernel-generated view into running
+  processes and system state (you'll use this again in Module 5)
+
+## Instructor Notes
+
+**Lesson goal:** Give students a working mental model of "one tree, absolute vs. relative
+paths" plus just enough top-level-directory recognition to not be lost later — not FHS
+memorization.
+
+**Approximate timing:** 15 minutes read; 10 minutes live.
+
+**Common misconception to watch for:** students coming from Windows sometimes expect separate
+drives/roots — emphasize the single unified tree explicitly.
+
+**Demo idea:** `cd /` then `ls`, narrating what each top-level directory is for as you see it,
+rather than listing them in the abstract.
@@ -0,0 +1,43 @@
+# Demonstration: The Same Word, Two Different Destinations
+
+## OBSERVE
+
+Starting from `/home/student`, run `cd project` — you land at `/home/student/project`.
+
+## HYPOTHESIS
+
+Now, from `/home/student/project`, what do you predict `cd project` will do this time?
+
+## INSPECT
+
+```
+$ pwd
+/home/student/project
+$ cd project
+bash: cd: project: No such file or directory
+```
+
+It fails — there's no `project` directory INSIDE `project` (unless you happened to create one).
+The exact same relative path meant something completely different depending on where you stood.
+
+## CHANGE
+
+From `/home/student/project`, run `cd ../project` instead — this correctly goes back up one
+level, then into `project` again, landing you right back where you started.
+
+## VERIFY
+
+`pwd` after each `cd` to confirm exactly where you ended up — this habit (verify your location
+before assuming it) prevents a huge share of "why did my command run somewhere unexpected"
+confusion later.
+
+## Instructor Notes
+
+**Demo goal:** Make "relative paths depend on where you are" concrete and slightly surprising,
+rather than an abstract rule to memorize.
+
+**Approximate timing:** 8 minutes live.
+
+**Common mistake to watch for:** students assume a relative path always means the SAME thing
+once they've used it once — reinforce that it's re-evaluated fresh every time, from wherever
+they currently are.
@@ -0,0 +1,36 @@
+# Knowledge Check: Navigating the Filesystem
+
+---
+
+**1. What does `..` mean in a path?**
+
+*Answer:* One directory up from your current location.
+
+---
+
+**2. You're at `/home/student/project`. Does `cd project` do the same thing here as it did at
+`/home/student`?**
+
+*Answer:* No — a relative path is re-evaluated from your CURRENT location every time. At
+`/home/student`, `project` refers to `/home/student/project`; from inside that same directory,
+`project` would refer to `/home/student/project/project`, which likely doesn't exist.
+
+---
+
+**3. A file is "hidden" from a normal `ls`. What actually makes it hidden?**
+
+*Answer:* Its name starts with a `.` — it's purely a naming convention `ls` respects by
+default, not a real permission or security feature. `ls -a` shows it.
+
+---
+
+**4. Where would you expect to find a running system's log files?**
+
+*Answer:* `/var/log` — `/var` holds data that changes while the system runs.
+
+## Instructor Notes
+
+**Facilitation:** Question 2 is the one worth confirming out loud — it's the core "gotcha" of
+relative paths.
+
+**Approximate timing:** 5 minutes.
@@ -0,0 +1,39 @@
+# Guided Exercise: Plan a Directory Structure on Paper First
+
+Before you build anything in the Lab, plan it — this is the same discipline you'll use later
+when planning a Kubernetes namespace layout or a Git repository structure.
+
+## Your task
+
+You're setting up a small project called `weather-app`. On paper, sketch a directory tree
+containing:
+
+- A place for source code
+- A place for documentation
+- A place for tests
+- A single hidden configuration file at the project's root
+
+Write out the exact `mkdir` and file-creation commands you'd use, including whether each path
+you write is absolute or relative.
+
+## A worked shape to check yourself against
+
+```
+mkdir -p weather-app/src weather-app/docs weather-app/tests
+echo "ready" > weather-app/.config
+```
+
+(Or with an absolute path: `mkdir -p /srv/weather-app/src ...`.) The `-p` flag matters here —
+without it, `mkdir` refuses to create `weather-app/src` if `weather-app` doesn't already exist.
+
+## Instructor Notes
+
+**Facilitation:** Have students commit to their command in writing before revealing the worked
+answer — the value is in noticing what `-p` actually buys them, not just copying a correct
+command.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced.
+
+**Common mistake to watch for:** forgetting `mkdir -p` and getting a "No such file or
+directory" error when creating a nested path in one command — a good moment to connect back to
+Module 2's exit-code lesson (that error IS a non-zero exit code).
@@ -0,0 +1,27 @@
+# Reflection: Structure Isn't Bureaucracy, It's Communication
+
+## Reflection questions
+
+1. Why might a real engineering team insist on a consistent directory structure across every
+   project, instead of everyone organizing files however they like?
+2. Which of `/etc`, `/var`, `/home`, `/tmp`, `/usr`, `/proc` do you feel most confident you could
+   explain to someone else right now? Which one still feels fuzzy?
+
+## Real Ops takeaway
+
+**A predictable filesystem layout is what lets tools (and other engineers) reason about a
+system without asking you first.** `/etc` always means configuration, `/var/log` always means
+logs — this convention is exactly why a monitoring tool can be pointed at "check `/var/log`" on
+any Linux machine and just work. Container images later inherit this same convention (an
+nginx container still keeps its config at `/etc/nginx/nginx.conf`) — you're not learning a
+one-off Linux fact, you're learning a convention that outlives this specific module.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 1 connects directly to why Kubernetes
+namespaces and Git repository conventions matter later — a good moment to name that connection
+without going deep yet.
+
+**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.