Fix Module 4 lab so git restore . doesn't wipe the uncommitted delete feature #2

New Issue

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

claude commented

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

Problem

The Module 4 lab cannot be completed as written. Part B commits a clean checkpoint that does not contain the delete command. Part C has the AI add delete across tasks.py/cli.py but never commits it. Part D then makes a throwaway change and runs git restore ., which resets all tracked files to the Part B commit — wiping the uncommitted Part C delete feature along with the throwaway. So Part D's annotated bash lab/verify.sh # still passes is false (verify.sh hard-requires delete, so it FAILS), and Part E's "commit the delete feature you kept in Part C" is impossible. The lab also self-contradicts the module's own "one rule" (commit before you turn the AI loose; never work on a dirty tree) — Part D runs the throwaway on top of uncommitted Part C work.

Evidence

modules/04-getting-the-ai-out-of-the-browser/README.md, Part D step 8:

git restore .
git diff           # empty — the AI's mess is gone, byte for byte
bash lab/verify.sh # still passes — you're back at your good state

Part E step 9: "Now commit the delete feature you kept in Part C (Part D's mess is already gone)".
modules/04-getting-the-ai-out-of-the-browser/lab/verify.sh runs "$PY" cli.py delete 1 and FAILs if delete is missing.
Reproduced: after git restore ., the delete method/branch is gone and verify.sh fails.

Why it matters

This is the climax lab of a load-bearing Unit 1 module. Followed literally it breaks and, ironically, enacts the exact "restore wipes uncommitted work" failure the module warns against (Where it breaks: "If you let the AI loose on a dirty tree, restore can't tell your work from its work and throws away both"). The lab's final committed state is unchanged, so Module 5 is unaffected.

Proposed change

At the end of Part C (after step 7's successful verify), add a commit block that checkpoints the good change:
```
git add .
git commit -m "Add delete command (made via editor/CLI agent)"
git log --oneline
```
This makes the delete-containing state the clean checkpoint.
Leave Part D as-is: the throwaway change + git restore . now correctly returns to the delete-containing checkpoint, so bash lab/verify.sh legitimately passes.
Repurpose Part E step 9 (the commit now lives in Part C). Replace the duplicate commit with a confirmation/closing step, e.g. git log --oneline to confirm the reviewed multi-file commit is the latest, plus the existing closing narrative. Do not commit delete twice.

Acceptance criteria

delete is committed at the end of Part C.
Part D's git restore . returns to a state where verify.sh passes (delete present).
Part E no longer instructs committing an already-committed change.
The lab runs end-to-end with delete present in the final state.
No dirty-tree throwaway contradiction remains.

Affected files

modules/04-getting-the-ai-out-of-the-browser/README.md

References

Source finding F1 (realVotes 3/3, blocker). Related: the bash lab/verify.sh invocation also needs the path fix in the Module 4/6/7/26 script-path issue (F6) to resolve at all.

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 The Module 4 lab cannot be completed as written. Part B commits a clean checkpoint that does **not** contain the `delete` command. Part C has the AI add `delete` across `tasks.py`/`cli.py` but never commits it. Part D then makes a throwaway change and runs `git restore .`, which resets all tracked files to the Part B commit — wiping the uncommitted Part C `delete` feature along with the throwaway. So Part D's annotated `bash lab/verify.sh # still passes` is false (verify.sh hard-requires `delete`, so it FAILS), and Part E's "commit the delete feature you kept in Part C" is impossible. The lab also self-contradicts the module's own "one rule" (commit before you turn the AI loose; never work on a dirty tree) — Part D runs the throwaway on top of uncommitted Part C work. ## Evidence `modules/04-getting-the-ai-out-of-the-browser/README.md`, Part D step 8: ``` git restore . git diff # empty — the AI's mess is gone, byte for byte bash lab/verify.sh # still passes — you're back at your good state ``` Part E step 9: "Now commit the `delete` feature you kept in Part C (Part D's mess is already gone)". `modules/04-getting-the-ai-out-of-the-browser/lab/verify.sh` runs `"$PY" cli.py delete 1` and FAILs if delete is missing. Reproduced: after `git restore .`, the `delete` method/branch is gone and verify.sh fails. ## Why it matters This is the climax lab of a load-bearing Unit 1 module. Followed literally it breaks and, ironically, enacts the exact "restore wipes uncommitted work" failure the module warns against (`Where it breaks`: "If you let the AI loose on a dirty tree, restore can't tell your work from its work and throws away both"). The lab's final committed state is unchanged, so Module 5 is unaffected. ## Proposed change 1. At the end of Part C (after step 7's successful verify), add a commit block that checkpoints the good change: ```bash git add . git commit -m "Add delete command (made via editor/CLI agent)" git log --oneline ``` This makes the delete-containing state the clean checkpoint. 2. Leave Part D as-is: the throwaway change + `git restore .` now correctly returns to the delete-containing checkpoint, so `bash lab/verify.sh` legitimately passes. 3. Repurpose Part E step 9 (the commit now lives in Part C). Replace the duplicate commit with a confirmation/closing step, e.g. `git log --oneline` to confirm the reviewed multi-file commit is the latest, plus the existing closing narrative. Do not commit `delete` twice. ## Acceptance criteria - [ ] `delete` is committed at the end of Part C. - [ ] Part D's `git restore .` returns to a state where `verify.sh` passes (delete present). - [ ] Part E no longer instructs committing an already-committed change. - [ ] The lab runs end-to-end with `delete` present in the final state. - [ ] No dirty-tree throwaway contradiction remains. ## Affected files - `modules/04-getting-the-ai-out-of-the-browser/README.md` ## References Source finding F1 (realVotes 3/3, blocker). Related: the `bash lab/verify.sh` invocation also needs the path fix in the Module 4/6/7/26 script-path issue (F6) to resolve at all. --- *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:37 -04:00

claude referenced this issue

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

Stop presenting `git rebase` / `git pull --rebase` as a casual fix before any module introduces it #34

claude referenced a pull request that will close this issue

2026-06-22 14:52:21 -04:00

Fix broken git demos/labs in Modules 4, 7, 14 (#2,#3,#4,#12) #55

claude referenced this issue from a commit

2026-06-22 14:52:22 -04:00

fix(modules-4,7,14): make the git demos/labs actually do what the prose claims

claude closed this issue

2026-06-22 14:52:31 -04:00