Add a dependency-install step before Module 23's 'green test baseline' on a fresh clone #22

New Issue

2026-06-22T14:23:48-04:00

claude commented

2026-06-22 14:23:48 -04:00

Problem

Part C step 6 says to "run the existing tests first to establish a green baseline" on an arbitrary fresh clone, but the lab never installs that repo's dependencies (pip install -e ., npm install, go mod download, …). A fresh clone usually fails with import/missing-runner errors, and the learner can't distinguish a genuine red baseline from an unconfigured environment. The safe-change skill even says "don't let a pre-existing failure get blamed on you," nudging them past what's really a setup failure. The lab also invites non-Python repos, but Module 13 taught only stdlib unittest, so a Go/JS pick needs an untaught, uninstalled toolchain (and even a Python pick needs an install M13 didn't cover).

Evidence

modules/23-working-with-existing-codebases/README.md, Part C step 6: "Run the existing tests first to establish a green baseline (pytest, npm test, go test ./… — whatever ORIENT.md and the README confirmed)." "You'll need" only says pick a repo with "a green test suite," no install step. lab/skills/safe-change.md step 3: "don't let a pre-existing failure get blamed on you."

Why it matters

A fresh clone often won't run green without install, undermining the exact concept the module teaches (establish a trustworthy baseline before changing unfamiliar code).

Proposed change

Add an explicit install step before the baseline: "install the project's deps — typically pip install -e ., npm install, go mod download; if it still won't run green on a clean clone, pick another repo."
Add "green on a clean clone after a documented install" to the selection traits.
Steer first-timers toward a small Python repo so the M13/pytest toolchain transfers.
Tweak safe-change.md step 3 to distinguish a setup/import failure from a genuine pre-existing red.

Acceptance criteria

An install step precedes the green-baseline step.
Selection traits require "green on a clean clone after install."
The safe-change skill distinguishes setup failures from real pre-existing reds.

Affected files

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

References

Source finding F36 (realVotes 3/3).

Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.

## Problem Part C step 6 says to "run the existing tests first to establish a green baseline" on an arbitrary fresh clone, but the lab never installs that repo's dependencies (`pip install -e .`, `npm install`, `go mod download`, …). A fresh clone usually fails with import/missing-runner errors, and the learner can't distinguish a genuine red baseline from an unconfigured environment. The safe-change skill even says "don't let a pre-existing failure get blamed on you," nudging them past what's really a setup failure. The lab also invites non-Python repos, but Module 13 taught only stdlib `unittest`, so a Go/JS pick needs an untaught, uninstalled toolchain (and even a Python pick needs an install M13 didn't cover). ## Evidence `modules/23-working-with-existing-codebases/README.md`, Part C step 6: "Run the existing tests first to establish a green baseline (pytest, npm test, go test ./… — whatever ORIENT.md and the README confirmed)." "You'll need" only says pick a repo with "a green test suite," no install step. `lab/skills/safe-change.md` step 3: "don't let a pre-existing failure get blamed on you." ## Why it matters A fresh clone often won't run green without install, undermining the exact concept the module teaches (establish a trustworthy baseline before changing unfamiliar code). ## Proposed change 1. Add an explicit install step before the baseline: "install the project's deps — typically `pip install -e .`, `npm install`, `go mod download`; if it still won't run green on a clean clone, pick another repo." 2. Add "green on a clean clone after a documented install" to the selection traits. 3. Steer first-timers toward a small Python repo so the M13/pytest toolchain transfers. 4. Tweak `safe-change.md` step 3 to distinguish a setup/import failure from a genuine pre-existing red. ## Acceptance criteria - [ ] An install step precedes the green-baseline step. - [ ] Selection traits require "green on a clean clone after install." - [ ] The safe-change skill distinguishes setup failures from real pre-existing reds. ## Affected files - `modules/23-working-with-existing-codebases/README.md`, `modules/23-working-with-existing-codebases/lab/skills/safe-change.md` ## References Source finding F36 (realVotes 3/3). --- *Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.*

claude added the ai-ready bug P1 labels 2026-06-22 14:23:48 -04:00

claude referenced a pull request that will close this issue

2026-06-22 16:07:47 -04:00

Testing/CI/tooling consistency (#9,#20,#21,#22,#23,#28) #59

claude referenced this issue from a commit

2026-06-22 16:07:48 -04:00

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

claude closed this issue

2026-06-22 16:07:58 -04:00

Sign in to join this conversation.