fix(testing/ci/tooling): consistent unittest, venv guidance, runnable lab commands

- #9: standardize the test chain on stdlib unittest (nothing-to-install, which
  keeps M13's claims true and its planted bug intact). Aligned M5/M14/M16 prose,
  M14 lab/test_tasks.py, and ci/gitlab starters; ruff stays the only pip install.
- #20: add venv / PEP 668 / which-python guidance to M20 (+ M14/M15 local
  installs); point MCP config at the venv's absolute python.
- #21: replace M21 Part D's empty `git diff HEAD~1` with `git log -p` (no
  .gitignore added — device preserved).
- #22: add a dependency-install step before M23's green baseline on a fresh clone.
- #23: M24 reviewer/triage now tolerate code-fence-wrapped JSON (stdlib only);
  feature.patch trap untouched.
- #28: fix M27 Part D CI snippet path (working-directory) and require the gate to
  target a varying candidate; swapped_model regression kept as the fixture.

Closes #9
Closes #20
Closes #21
Closes #22
Closes #23
Closes #28

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/README.md

@@ -170,8 +170,12 @@ This lab does **not** use `tasks-app` — the entire point is a codebase you *di
 - Git, Python 3.10+, and your agentic AI tool from Module 4.
 - A real, small-to-medium open-source repo to clone. Pick something with **tests** and a clear
   build/test command, in a language you can at least read. Good traits: a few thousand lines, an
-  obvious entry point, a green test suite. (Avoid giant frameworks for a first run — you want a
+  obvious entry point, a documented install (`pip install -e .`, `npm install`, `go mod download`,
+  …), and a test suite that **goes green on a clean clone after that documented install** — confirm
+  that before you rely on it as a baseline. (Avoid giant frameworks for a first run — you want a
   system you can't fully hold in your head, but whose test suite finishes in under a minute.)
+  **First time? Pick a small Python repo**, so the Module 13 testing toolchain you already have
+  transfers with the least friction.
 - The starter files from this module's `lab/` folder: `orient.py` and `skills/`.
 
 ### Part A — Clone and orient
@@ -205,9 +209,14 @@ This lab does **not** use `tasks-app` — the entire point is a codebase you *di
 ### Part C — One small, scoped, tested change
 
 6. Pick a genuinely small change — a clearer error message, a fixed edge case, a tiny missing
-   validation, a documented-but-unhandled input. Something a single function owns. Run the existing
-   tests first to establish a green baseline (`pytest`, `npm test`, `go test ./...` — whatever
-   `ORIENT.md` and the README confirmed).
+   validation, a documented-but-unhandled input. Something a single function owns. First **install
+   the project's dependencies** the way its README says — typically `pip install -e .` (Python),
+   `npm install` (JS/TS), `go mod download` (Go), or the equivalent — *then* run the existing tests
+   to establish a green baseline (`python -m unittest`, `pytest`, `npm test`, `go test ./...` —
+   whatever `ORIENT.md` and the README confirmed). A fresh clone usually won't run green until its
+   deps are installed; if it still won't go green on a clean clone *after* a documented install,
+   that's a setup problem, not your baseline — pick another repo rather than change code on top of an
+   environment you can't trust.
 
 7. Branch, then load the `safe-change` skill (`lab/skills/safe-change.md`) and work the change with
    the AI:

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

@@ -22,8 +22,12 @@ When making a concrete change to an unfamiliar repo.
 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.
+3. **Install the project's dependencies, then run the existing tests before touching anything** —
+   establish a green baseline. Tell two failures apart: if the suite errors with missing imports,
+   "no module named …", or "no tests ran," that's an **unconfigured environment**, not a baseline —
+   finish the documented install (and pick a different repo if it still won't go green on a clean
+   clone). A genuine **pre-existing failure** (install succeeded, but a real test fails) is the other
+   case — note it so it doesn't get blamed on you, and don't build on top of it.
 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.