Fix Module 14 Part C recovery: git restore is a no-op on the committed bad change, so CI never goes green #4

Closed
opened 2026-06-22 14:23:38 -04:00 by claude · 0 comments
Contributor

Problem

Module 14 Part C's recovery is broken. Step 7 commits and pushes the bad pending() change (the push is required to make CI red in step 8). Step 9 then tells the learner git restore tasks.py "throws away the bad change (Module 2's safety net)" and "CI goes green again." But git restore only discards uncommitted edits and resets the file to HEAD — which is now the bad commit. The file keeps the bug, the follow-up git commit -am has nothing to commit (exits non-zero, "nothing to commit, working tree clean"), the push is empty, and CI stays red. The "(Module 2's safety net)" attribution is also wrong — Module 2 teaches restore for uncommitted edits only.

Evidence

modules/14-continuous-integration/README.md, Part C step 9 (~lines 267-283):

git restore tasks.py   # throw away the bad change (Module 2's safety net)
git commit -am ...
git push               # CI goes green again

Reproduced: after git restore, the file still contains return self.tasks; git commit -am commits nothing; push is empty; CI stays red.

Why it matters

This is the module's climactic recovery — "the whole point" — and it leaves any follower stuck at the payoff. It also misteaches restore vs committed/pushed undo, which Module 12 explicitly distinguishes.

Proposed change

Recover by actually fixing the committed code, then commit and push:

  1. Re-apply the correct filter: return [t for t in self.tasks if not t.done].
  2. git commit -am "Fix pending() to exclude done tasks" then git push → CI goes green.
  3. Remove the "(Module 2's safety net)" note, since plain restore cannot undo a committed+pushed change.

Acceptable alternative (course-coherent, since Module 12 precedes Module 14 and teaches revert as the team-safe undo for pushed changes): git revert HEAD then push. Step 9's commit message already says "Revert:…", so this variant fits — but pick one and make the prose consistent.

Acceptance criteria

  • The recovery step results in pending() no longer containing the bug, with a real commit and push.
  • CI legitimately turns green after the recovery step.
  • No claim that plain git restore undoes a committed/pushed change; the "(Module 2's safety net)" note is removed or corrected.

Affected files

  • modules/14-continuous-integration/README.md

References

Source finding F3 (realVotes 3/3, blocker). Module 12 (revert vs restore) precedes this module.


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 Module 14 Part C's recovery is broken. Step 7 commits **and pushes** the bad `pending()` change (the push is required to make CI red in step 8). Step 9 then tells the learner `git restore tasks.py` "throws away the bad change (Module 2's safety net)" and "CI goes green again." But `git restore` only discards uncommitted edits and resets the file to HEAD — which is now the bad commit. The file keeps the bug, the follow-up `git commit -am` has nothing to commit (exits non-zero, "nothing to commit, working tree clean"), the push is empty, and CI stays red. The "(Module 2's safety net)" attribution is also wrong — Module 2 teaches `restore` for uncommitted edits only. ## Evidence `modules/14-continuous-integration/README.md`, Part C step 9 (~lines 267-283): ``` git restore tasks.py # throw away the bad change (Module 2's safety net) git commit -am ... git push # CI goes green again ``` Reproduced: after `git restore`, the file still contains `return self.tasks`; `git commit -am` commits nothing; push is empty; CI stays red. ## Why it matters This is the module's climactic recovery — "the whole point" — and it leaves any follower stuck at the payoff. It also misteaches `restore` vs committed/pushed undo, which Module 12 explicitly distinguishes. ## Proposed change Recover by actually fixing the committed code, then commit and push: 1. Re-apply the correct filter: `return [t for t in self.tasks if not t.done]`. 2. `git commit -am "Fix pending() to exclude done tasks"` then `git push` → CI goes green. 3. Remove the "(Module 2's safety net)" note, since plain `restore` cannot undo a committed+pushed change. Acceptable alternative (course-coherent, since Module 12 precedes Module 14 and teaches revert as the team-safe undo for pushed changes): `git revert HEAD` then push. Step 9's commit message already says "Revert:…", so this variant fits — but pick one and make the prose consistent. ## Acceptance criteria - [ ] The recovery step results in `pending()` no longer containing the bug, with a real commit and push. - [ ] CI legitimately turns green after the recovery step. - [ ] No claim that plain `git restore` undoes a committed/pushed change; the "(Module 2's safety net)" note is removed or corrected. ## Affected files - `modules/14-continuous-integration/README.md` ## References Source finding F3 (realVotes 3/3, blocker). Module 12 (revert vs restore) precedes this module. --- *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-readybugP1 labels 2026-06-22 14:23:38 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: justin/ai-workflow-course#4