Build out all 27 modules + capstone (#1)

Co-authored-by: claude <claude@jpaul.io> Co-committed-by: claude <claude@jpaul.io>
2026-06-22 12:19:01 -04:00
parent 4bd586bbd0
commit 2684095e2f
117 changed files with 15131 additions and 1 deletions
@@ -0,0 +1,52 @@
+<!--
+  Runbook template — the step-by-step for one operational task.
+
+  A runbook is read under pressure, often by someone who is not the person who wrote it and not at
+  their best (it's 3 a.m., something is on fire). Optimize for "follow it exactly, no thinking
+  required." Concrete commands, expected output, and what to do when a step fails.
+
+  In the Module 3 lab (optional variant) you hand this to the AI to draft a runbook, then review the
+  draft as a diff before merging. Write one command/step per line so git diffs stay clean.
+
+  Delete these HTML comments when you write the real runbook.
+-->
+
+# Runbook — <task name>
+
+- **Purpose:** <one sentence: what this runbook gets you out of>
+- **When to run:** <the trigger — the alert, the symptom, the request>
+- **Owner:** <team or role responsible>
+- **Last verified:** YYYY-MM-DD
+
+## Before you start
+
+<!-- Access, tools, or context the operator needs in hand before step 1. -->
+
+- <prerequisite>
+
+## Steps
+
+<!-- Numbered, concrete, copy-pasteable. After a command, say what success looks like so the operator
+     knows whether to continue. -->
+
+1. <action>
+
+   ```bash
+   <command>
+   ```
+
+   Expected: <what you should see>
+
+2. <action>
+
+## Verify
+
+<!-- How to confirm the task actually worked, not just that the commands ran without error. -->
+
+- <check>
+
+## If it goes wrong
+
+<!-- The two or three most likely failure modes and what to do about each. Where to escalate. -->
+
+- **<symptom>** → <what to do>