Module 3: Git Fundamentals: Mistake Clinic

This clinic turns wrong moves into reusable judgment. Use it after each practice page and again before the quiz or checkpoint.

---

Module-Specific Mistake Radar

Start with these traps. Replace or extend them with real mistakes from your own work.

Mistake to look for	Where it shows up	Symptom	Repair evidence
Finishing Repository State Diagnostics with only a final answer	Repository State Diagnostics	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing Branching and Integration Lab with only a final answer	Branching and Integration Lab	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing Collaboration and Review Lab with only a final answer	Collaboration and Review Lab	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing Code Katas with only a final answer	Code Katas	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Treating Git Mental Model: Snapshots, HEAD, and References as vocabulary instead of a tool	Git Mental Model: Snapshots, HEAD, and References	The explanation names the concept but cannot decide between two cases.	Write one example, one non-example, and the rule that separates them.
Treating The Staging Area and the Commit Cycle as vocabulary instead of a tool	The Staging Area and the Commit Cycle	The explanation names the concept but cannot decide between two cases.	Write one example, one non-example, and the rule that separates them.

---

Practice Mistake Checks

Pull any miss from these checks into your mistake log.

Repository State Diagnostics

Source: practice/01-repository-state-diagnostics.md

For each mistake:

1. say what is wrong
2. write the safer move
3. explain why Mistakes:
4. Committing without checking what is staged.
5. Using git pull before reading current local state.
6. Assuming a clean git diff means nothing is staged.
7. Thinking origin/main updates by itself without communication.

Branching and Integration Lab

Source: practice/02-branching-and-integration-lab.md

Explain why each move is risky:

1. Rebasing a branch that teammates already pulled.
2. Deleting a branch before confirming the work is integrated.
3. Resolving a merge conflict by choosing a side without reading the actual code.

Collaboration and Review Lab

Source: practice/03-collaboration-and-review-lab.md

For each mistake, explain the better move:

1. Using pull without checking whether your branch has local commits.
2. Pushing directly to the shared main branch for every experiment.
3. Opening one pull request that mixes refactor, bug fix, and docs cleanup.

---

Repair Protocol

For each real mistake:

1. Reproduce the failure on the smallest example, trace, proof, query, command, or design sketch.
2. Name the hidden assumption.
3. Repair the artifact.
4. Save evidence that changed: failing then passing test, corrected proof step, revised diagram, safer command, benchmark, or review note.
5. Add one retrieval card beginning with Check... before... or Do not use... when....

---

Mistake Log

Date	Mistake	Symptom	Root cause	Repair evidence	Retrieval card
Starter	Pick one radar row above	Explain how it would fail in this module	Name the assumption	Add a counterexample or corrected artifact	Write the card before closing the page

---

Completion Standard

• One actual mistake or explicitly labeled seeded failure is investigated using existing lab evidence.
• The investigation includes a prediction, observed counterexample and explained repair.
• A fresh case confirms the repaired model; no previous semester is assumed.
• At least one correction changes code, a proof, a diagram, a command transcript, a query, or a design decision.