Reconcile tasks.json gitignore: keep it ignored, fix M20/M22 verification, and exempt M21 #10

New Issue

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

claude commented

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

Problem

Module 2's gitignore-starter ignores tasks.json. Downstream labs contradict this. M20 Part D verifies an AI task-add with git diff, claiming it "shows up exactly like any other edit" — but tasks.json is gitignored, so git diff/git status -s are empty. M22's cleanup git restore tasks.json errors with "pathspec did not match" on the gitignored/untracked file. (M10 git add . and M13's count flow are minor.)

CRITICAL constraint: Module 21 deliberately ships no .gitignore so tasks.json is stageable — its whole lesson is teaching the AI not to commit tasks.json ("A skill is not a security boundary — 'Don't stage tasks.json' is a convention, not a permission"), verified by git show --stat showing tasks.json absent from the commit. So the naive fix "ship the M2 .gitignore in every snapshot" would gut Module 21 and must NOT be applied there.

Evidence

modules/02-.../lab/gitignore-starter ignores tasks.json.
M20 Part D (~line 337): "git diff # the change shows up in your repo, exactly like any other edit (Module 2)".
M22 Part B (~line 300): git restore tasks.json.
M21 (~lines 54, 214, 223, 263): "don't stage tasks.json" lesson + git show --stat HEAD verification.
Reproduced: with M2 .gitignore, after a task add git diff and git status -s are empty; git restore tasks.json errors.

Why it matters

tasks.json is the course's load-bearing carry-forward artifact. M20's "the whole point" verification step is false for any learner who applied M2's .gitignore, and M22's cleanup errors. The honest, correct default is that runtime state is gitignored.

Proposed change

Keep tasks.json gitignored as the pedagogically correct default.
M20: verify the AI's add via python cli.py list / cat tasks.json (not git diff), and reframe step as a teaching moment that runtime state is deliberately gitignored.
M22: replace git restore tasks.json with rm tasks.json (M22 already offers the delete alternative).
M21: leave untouched — it is correct as-is and must keep shipping no .gitignore. Explicitly exempt it from any "ship the .gitignore" rule.
M10/M13: make git add . / count flow consistent with whichever convention each snapshot adopts (minor).

Acceptance criteria

M20's verification no longer depends on git seeing tasks.json.
M22 cleanup works on a gitignored/untracked tasks.json.
M21 still ships no .gitignore and its guardrail lesson is intact.

Affected files

modules/20-mcp-servers-giving-the-ai-hands/README.md, modules/22-securing-third-party-mcp-and-skills/README.md, (minor) modules/10-.../README.md, modules/13-.../README.md

References

Source finding F9 (realVotes 3/3). Touches locked exemplar Module 2's .gitignore policy — keep it. Do NOT modify Module 21.

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 2's `gitignore-starter` ignores `tasks.json`. Downstream labs contradict this. M20 Part D verifies an AI task-add with `git diff`, claiming it "shows up exactly like any other edit" — but `tasks.json` is gitignored, so `git diff`/`git status -s` are empty. M22's cleanup `git restore tasks.json` errors with "pathspec did not match" on the gitignored/untracked file. (M10 `git add .` and M13's count flow are minor.) CRITICAL constraint: Module 21 deliberately ships **no** `.gitignore` so `tasks.json` is stageable — its whole lesson is teaching the AI not to commit `tasks.json` ("A skill is not a security boundary — 'Don't stage tasks.json' is a convention, not a permission"), verified by `git show --stat` showing `tasks.json` absent from the commit. So the naive fix "ship the M2 `.gitignore` in every snapshot" would gut Module 21 and must NOT be applied there. ## Evidence `modules/02-.../lab/gitignore-starter` ignores `tasks.json`. M20 Part D (~line 337): "git diff # the change shows up in your repo, exactly like any other edit (Module 2)". M22 Part B (~line 300): `git restore tasks.json`. M21 (~lines 54, 214, 223, 263): "don't stage tasks.json" lesson + `git show --stat HEAD` verification. Reproduced: with M2 `.gitignore`, after a task add `git diff` and `git status -s` are empty; `git restore tasks.json` errors. ## Why it matters `tasks.json` is the course's load-bearing carry-forward artifact. M20's "the whole point" verification step is false for any learner who applied M2's `.gitignore`, and M22's cleanup errors. The honest, correct default is that runtime state is gitignored. ## Proposed change 1. Keep `tasks.json` gitignored as the pedagogically correct default. 2. M20: verify the AI's add via `python cli.py list` / `cat tasks.json` (not `git diff`), and reframe step as a teaching moment that runtime state is deliberately gitignored. 3. M22: replace `git restore tasks.json` with `rm tasks.json` (M22 already offers the delete alternative). 4. M21: leave untouched — it is correct as-is and must keep shipping no `.gitignore`. Explicitly exempt it from any "ship the `.gitignore`" rule. 5. M10/M13: make `git add .` / count flow consistent with whichever convention each snapshot adopts (minor). ## Acceptance criteria - [ ] M20's verification no longer depends on git seeing `tasks.json`. - [ ] M22 cleanup works on a gitignored/untracked `tasks.json`. - [ ] M21 still ships no `.gitignore` and its guardrail lesson is intact. ## Affected files - `modules/20-mcp-servers-giving-the-ai-hands/README.md`, `modules/22-securing-third-party-mcp-and-skills/README.md`, (minor) `modules/10-.../README.md`, `modules/13-.../README.md` ## References Source finding F9 (realVotes 3/3). Touches locked exemplar Module 2's `.gitignore` policy — keep it. Do NOT modify Module 21. --- *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 P1 bug ai-ready labels 2026-06-22 14:23:41 -04:00

claude referenced a pull request that will close this issue

2026-06-22 15:35:40 -04:00

Running-example consistency: paths, tasks.json, command collisions (#7,#10,#11) #57

claude referenced this issue from a commit

2026-06-22 15:35:42 -04:00

fix(running-example): consistent lab-script paths, tasks.json policy, no command collisions

claude closed this issue

2026-06-22 15:35:52 -04:00

Sign in to join this conversation.