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,41 @@
+<!--
+  ADR template — Architecture Decision Record (lightweight).
+
+  An ADR captures ONE decision so the reasoning survives the meeting. Copy this file into your repo
+  (e.g. docs/adr/0001-some-decision.md), number it, and fill in the sections. Keep it short — an ADR
+  that nobody reads because it's long has failed at its only job.
+
+  In the Module 3 lab you hand this template to the AI and ask it to fill it out for a real decision,
+  then review its draft as a diff before merging. Write one sentence per line where you can: it keeps
+  future git diffs surgical instead of reflowing whole paragraphs.
+
+  Delete these HTML comments when you write the real ADR.
+-->
+
+# ADR NNNN — <short decision title>
+
+- **Status:** proposed | accepted | superseded by ADR-XXXX
+- **Date:** YYYY-MM-DD
+- **Deciders:** <who made the call>
+
+## Context
+
+<!-- What's the situation that forces a decision? The problem, the constraints, what's at stake.
+     One short paragraph. State facts, not the conclusion. -->
+
+## Decision
+
+<!-- The choice, stated plainly in one or two sentences. "We will ___." -->
+
+## Alternatives considered
+
+<!-- The options you did NOT pick, and the one-line reason each lost. This is the part that saves a
+     future reader from re-litigating the decision. -->
+
+- **<option>** — <why not>
+- **<option>** — <why not>
+
+## Consequences
+
+<!-- What this decision makes easier, harder, or impossible later. Include the downsides you accepted
+     with open eyes — an ADR with no negative consequences is hiding something. -->
@@ -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>