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,52 @@
+# Files and Text
+
+## Basic file operations
+
+- `touch <file>` — create an empty file (or update its timestamp if it exists)
+- `mkdir <dir>` — create a directory (`-p` creates any missing parent directories too)
+- `cp <src> <dst>` — copy a file
+- `mv <src> <dst>` — move OR rename a file (Linux treats renaming as "moving to a new name in
+  the same place")
+- `rm <file>` — delete a file (`-r` for a directory, `-f` to skip confirmation — dangerous
+  combined: `rm -rf` deletes without asking, permanently)
+
+## Reading text
+
+- `cat <file>` — print the whole file at once
+- `less <file>` — page through a file interactively (press `q` to quit) — the right tool for
+  anything too long to read in one screen
+- `head <file>` / `tail <file>` — the first/last 10 lines by default (`-n 20` for a different
+  count); `tail -f` follows a file live as new lines are appended — exactly how you'd watch a
+  log file update in real time
+
+## Searching text: `grep`
+
+`grep PATTERN file` prints only the lines matching PATTERN. This is one of the most-used
+commands in real operations work — "find the lines that matter" beats "read everything."
+
+## Pipes and redirection: composing commands
+
+- **A pipe (`|`)** sends one command's output as the next command's input:
+  `cat app.log | grep ERROR` — read the file, then filter it.
+- **Redirection (`>`)** sends a command's output into a file instead of the screen (overwriting
+  it): `grep ERROR app.log > errors.txt`. `>>` appends instead of overwriting.
+
+## stdout vs. stderr
+
+A command actually has TWO separate output streams: **stdout** (normal output) and **stderr**
+(error messages), even though both print to your screen by default. This is why
+`command 2>/dev/null` (redirecting stream `2`, stderr, to nowhere) can suppress error noise
+while still showing normal output — you'll use exactly this pattern in later Labs.
+
+## Instructor Notes
+
+**Lesson goal:** Build real fluency composing small commands together — this is the single
+highest-leverage Linux skill for troubleshooting work later in ROOT_.
+
+**Approximate timing:** 15 minutes read; 10 minutes live.
+
+**Common misconception to watch for:** students often don't realize stdout/stderr are separate
+streams until they see `2>/dev/null` change what's suppressed — worth demonstrating live.
+
+**Demo idea:** run a command that produces both real output and an error in the same call
+(e.g. `ls /etc /nonexistent`) and show how `2>/dev/null` changes what appears.
@@ -0,0 +1,56 @@
+# Demonstration: Filtering a Log Down to What Matters
+
+## OBSERVE
+
+A raw log file has five lines mixing `INFO` and `ERROR`:
+
+```
+$ cat app.log
+INFO: boot ok
+ERROR: disk full
+INFO: retry
+ERROR: timeout
+INFO: done
+```
+
+## HYPOTHESIS
+
+Predict what `grep ERROR app.log` will print, before running it.
+
+## INSPECT
+
+```
+$ grep ERROR app.log
+ERROR: disk full
+ERROR: timeout
+```
+
+Only the matching lines — everything else is filtered out.
+
+## CHANGE
+
+Now redirect that filtered result into a new file instead of just viewing it:
+
+```
+$ grep ERROR app.log > errors.txt
+$ cat errors.txt
+ERROR: disk full
+ERROR: timeout
+```
+
+## VERIFY
+
+Count how many lines actually matched, without eyeballing them: `wc -l < errors.txt` (or
+`grep -c ERROR app.log` directly). This composition — filter, then count, then act — is the
+exact shape of a huge share of real troubleshooting work.
+
+## Instructor Notes
+
+**Demo goal:** Show the filter → redirect → verify chain as one continuous, composable
+workflow, not three unrelated commands.
+
+**Approximate timing:** 8 minutes live.
+
+**Common mistake to watch for:** using `>` when they meant `>>` and accidentally overwriting a
+file they wanted to append to — worth calling out explicitly since it's a real, common mistake
+with no undo.
@@ -0,0 +1,37 @@
+# Knowledge Check: Files and Text
+
+---
+
+**1. What's the difference between `>` and `>>`?**
+
+*Answer:* `>` overwrites the target file's contents entirely; `>>` appends to the end of it,
+preserving what was already there.
+
+---
+
+**2. A command prints both normal output and an error message. What are these two streams
+called?**
+
+*Answer:* stdout (normal output) and stderr (error messages) — two separate streams that both
+happen to print to your screen by default.
+
+---
+
+**3. You want to watch a log file update live, as new lines are appended, without re-running a
+command repeatedly.**
+
+*Answer:* `tail -f <file>` — follows the file and prints new lines as they're written.
+
+---
+
+**4. `cat app.log | grep ERROR`. What does the `|` actually do?**
+
+*Answer:* It pipes `cat`'s output directly into `grep`'s input, so `grep` filters the file's
+contents without needing a separate temporary file.
+
+## Instructor Notes
+
+**Facilitation:** Question 2 is worth a live show-of-hands check — many students haven't
+consciously registered that stdout/stderr are separate until this module.
+
+**Approximate timing:** 5 minutes.
@@ -0,0 +1,31 @@
+# Guided Exercise: Which Tool Actually Answers the Question?
+
+This is a paper exercise — commit to an answer before checking it in the Lab.
+
+## Your task
+
+For each situation, name the ONE command (or short pipeline) you'd reach for first:
+
+1. You want to see just the last 20 lines of a 50,000-line log file.
+2. You want to know how many lines in a file contain the word "timeout."
+3. You want to watch a log file update live while a process is running.
+4. You want to see a file's full contents but it's too long for one screen and you want to
+   scroll through it interactively.
+
+## A worked shape to check yourself against
+
+1. `tail -n 20 file.log`
+2. `grep -c timeout file.log`
+3. `tail -f file.log`
+4. `less file.log`
+
+Notice: `cat` would technically "work" for #4 too, but it dumps everything at once with no way
+to scroll back — `less` is the actual right tool once a file is longer than one screen.
+
+## Instructor Notes
+
+**Facilitation:** Item 4 is worth discussing explicitly — "it works" isn't the same bar as
+"it's the right tool for this situation," and that distinction matters more as commands compose
+into real troubleshooting workflows.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced.
@@ -0,0 +1,26 @@
+# Reflection: Filtering Is a Reasoning Skill, Not a Syntax Trick
+
+## Reflection questions
+
+1. Before this module, how would you have found "the important lines" in a huge log file?
+   How does that compare to `grep`?
+2. Which combination (pipe, redirect, or a specific command like `tail -f`) do you expect to
+   use the most once you're doing real troubleshooting work?
+
+## Real Ops takeaway
+
+**"Read everything and eyeball it" does not scale — filtering does.** Every troubleshooting
+framework you'll learn later in ROOT_ (starting with ROOT 02's own version, then again more
+formally in ROOT 10) depends on being able to quickly narrow a huge amount of system output down
+to the handful of lines that actually matter. `grep`, pipes, and redirection are the first real
+tools you have for that — not a syntax exercise, a reasoning skill.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 1 often produces good answers ("I'd
+just scroll and read") that make the value of filtering obvious by contrast — let students
+articulate this themselves rather than stating it for them.
+
+**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.