Adds all 6 ROOT 02 modules (Linux system administration, storage & filesystems, the Networking Mental Model, Linux network inspection, DNS & HTTP, Linux troubleshooting) — 37 activities, each with a real lesson, demonstration/guided exercise, knowledge check, hands-on Lab, and reflection. The Networking Mental Model module (M3) gets deliberately extra depth per its "critical module" designation, with no lab by design — conceptual mastery via knowledge check and guided exercise, matching root-05-m00's own precedent. Adds 6 new hands-on Linux/networking scenarios plus 2 MCQs: linux-service-inspection (inspects the platform's own real nginx without touching it — a genuinely safe, real service-inspection target that avoids ever risking the Lab's own connectivity), linux-service-lifecycle (start/ verify/stop a fully controllable service), linux-storage-inspection, linux-network-inspection (ip/ss/getent/curl, each framed as answering one specific diagnostic question), linux-dns-http-diagnosis (a genuine DNS-resolves-but-wrong-port failure, diagnosed and fixed), and linux-troubleshooting-framework (a real missing-config-file failure, resolved via the RootNode Observe/Evidence/Hypothesis/Test/Repair/Validate/Prevent framework). All tested end-to-end via the real scenario-validation API, including negative tests confirming they fail when unsolved. Wires rootnode-linux-networking-assessment (2 required + 4 random-draw scenarios) using the existing Phase 3B assessment engine. Co-Authored-By: Claude Sonnet 5 <[email protected]>
1.4 KiB
1.4 KiB
Guided Exercise: Write Your Hypothesis Before You Look at the Answer
This is a paper exercise — commit to a full framework pass before touching the Lab.
Your task
You're told: "A script that's supposed to write a ready marker file isn't creating it, and
exits with a non-zero code." Before running anything, write out, specifically:
- What's your OBSERVE statement (the precise symptom, not "it's broken")?
- What EVIDENCE would you gather first, and with what command?
- What's ONE specific, testable hypothesis (not "something's wrong with it")?
A worked shape to check yourself against
- Observe: "Script X exits non-zero and does not create file Y."
- Evidence: redirect both stdout and stderr to a file and read it —
script.sh > log 2>&1; cat log— the script's own error output is almost always the fastest evidence source for a startup failure. - Hypothesis (once you've actually read the error): something SPECIFIC the error names — e.g. "the script requires a file at path X that doesn't currently exist" — not a vague restatement of the symptom.
Instructor Notes
Facilitation: The value here is entirely in getting students to write a hypothesis SPECIFIC and FALSIFIABLE enough that they could be proven wrong — "something's misconfigured" fails that bar; "the config file at this exact path is missing" passes it.
Approximate timing: 8-10 minutes live discussion; 5 minutes self-paced.