feat(course): build out all 27 modules, capstone, scaffold, and conventions

Scaffold the course repo and author the full curriculum in dependency-chain
order, following the settled build decisions in handoff.md.

- Scaffold: course README, vendor-neutral AGENTS.md (dogfoods Module 5),
  _TEMPLATE.md (the fixed 9-section module shape), root .gitignore, ship config.
- Modules 1-2: reference exemplars (locked for tone/depth/lab style).
- Modules 3-27: full lessons + runnable labs, each following the template,
  respecting the chain, vendor/model-agnostic, with "feel the pain" labs.
- Module 8 hosting comparison web-researched and date-stamped (as of 2026-06-22),
  not written from memory; expansion-zone modules carry Verify-before-publish.
- Capstone: the full loop end to end on the running tasks-app example.

Lab code syntax-checked (Python/shell/YAML); every module has the 7 core
template sections.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT

modules/23-working-with-existing-codebases/lab/skills/map-this-repo.md

@@ -0,0 +1,32 @@
+# Skill: Map this repo
+
+A navigation playbook (a Module 21 skill) for orienting in a codebase you didn't write.
+Point your agentic tool at this file as a skill, or paste it in as instructions. The goal is a
+**read-only** mental model — no edits happen here.
+
+## When to use
+At the start of any session on an unfamiliar repo, before any change is discussed.
+
+## Rules
+- **Read only.** Do not edit, create, or delete files while mapping. No exceptions.
+- **Cite real paths.** Every claim about the code must point to a file and, ideally, a line range.
+  If you can't cite it, say "unverified" instead of guessing.
+- **Breadth before depth.** Establish the whole shape before diving into any one area.
+- **No conclusions from file names alone.** A file called `auth.py` may not be where auth lives.
+
+## Steps
+1. Read the orientation pack (from `orient.py`), the README, and any `CONTRIBUTING`,
+   `ARCHITECTURE`, or committed AI-instructions file. Treat these as claims to verify, not truth.
+2. Identify the **entry points**: how does this thing start? (CLI `main`, web server, library
+   exports.) Name the exact file(s).
+3. Trace **one representative request/command end to end** — from entry point to where it does its
+   real work and back. List the files it passes through, in order.
+4. Produce an **architecture summary** (max ~1 page):
+   - One paragraph: what this project does and how it's structured.
+   - A "where things live" table: concern -> directory/file.
+   - The build/test/run commands, confirmed against the README or CI config.
+   - 3-5 things that surprised you or look risky to touch.
+5. List **open questions** you could not resolve from the code. Do not paper over them.
+
+## Output
+A single Markdown summary. End with: "Verified against: <list of files actually read>."

modules/23-working-with-existing-codebases/lab/skills/safe-change.md

@@ -0,0 +1,39 @@
+# Skill: Safe scoped change
+
+A safe-change playbook (a Module 21 skill) for modifying a codebase you don't fully understand.
+Use it only **after** `map-this-repo` has produced an architecture summary. The whole bet of this
+skill is: small, scoped, tested, reviewable — never a sweeping rewrite.
+
+## When to use
+When making a concrete change to an unfamiliar repo.
+
+## Rules
+- **One change, one branch.** Create a branch first (Module 6). Never work on the default branch.
+- **Smallest diff that solves it.** Touch the fewest files possible. If the change wants to sprawl,
+  stop and re-scope — sprawl in code you don't understand is how you break things invisibly.
+- **No drive-by edits.** Do not reformat, rename, or "clean up" unrelated code. Those bury the real
+  change and make the diff unreviewable (Module 10).
+- **Match local conventions.** Mirror the surrounding code's style, naming, and patterns — not your
+  own defaults.
+- **Tests are the contract.** A change isn't done until it's covered (Module 13) and the existing
+  suite still passes.
+
+## Steps
+1. **State the change in one sentence** and the acceptance criterion ("done when X").
+2. **Find the blast radius first:** search for every caller/usage of what you're about to touch.
+   List them. If you can't enumerate them, you're not ready to change it.
+3. **Run the existing tests before touching anything** — establish a green baseline. If they were
+   already red, note it; don't let a pre-existing failure get blamed on you.
+4. **Make the minimal edit.** Keep it to the files identified in step 2.
+5. **Add or extend a test** that fails without your change and passes with it.
+6. **Run the full suite.** All green, including the baseline tests.
+7. **Self-review the diff** as if reviewing someone else's PR (Module 10): is every changed line
+   necessary and explained? Revert anything that isn't.
+8. **Write the PR description:** what changed, why, blast radius, how it was tested, what you did
+   NOT touch and why.
+
+## Stop conditions (escalate to a human instead of pushing on)
+- The change requires touching more than ~3 files or a "core" file from the architecture summary.
+- You can't enumerate the callers of what you're changing.
+- A test you don't understand starts failing.
+- The fix needs a design decision the existing code doesn't settle.