Stop the running-example commands (count, clear, delete) from colliding across modules #11

New Issue

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

claude commented

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

Problem

Following the labs literally, tasks-app accretes commands: M1 adds clear, M2 adds+commits count, M4 adds delete, M5 adds clear again. Then M6 Part C asks to add count AND clear again — and its engineered conflict assumes a baseline usage string without count. M7 has two agents add clear and count as "commands neither ever saw." A learner carrying cumulative state already has these on main, so the AI may report they exist, the conventions check no-ops, and the shown conflict markers won't match reality. The course never states per-module starting state or resets it.

Evidence

M2 Part B "add a count command" → commit "Add count command" (~line 190).
M6 Part C step 1 "Add a count command…" (~line 326); conflict markers (~lines 376-378) assume baseline usage [add <title> | list | done <index> | clear] implying count absent.
M7 lab/agent-a-prompt.md / agent-b-prompt.md add clear/count.
Modules all anchor to "the tasks-app repo from Module 1/2" with no reset.

Why it matters

M6 Part C is the marquee merge-conflict lab; if count/clear already exist, the engineered same-line conflict may not materialize and the printed markers won't match — defeating a load-bearing lab. The course markets carry-forward integrity.

Proposed change

Prefer distinct, never-before-used example commands per module so they never collide:

In M6's conflict lab, have the two branches each add a different brand-new command (any two commands editing the same usage line produces the same conflict), so it works regardless of cumulative state.
State the assumed starting state at the top of M6/M7 ("the usage line at this point is …").
If reusing count/clear is unavoidable, add explicit guidance: "you may already have count/clear — create them fresh on a throwaway branch" — but note the cleaner fix is distinct command names.

Acceptance criteria

M6 Part C's conflict reproduces for a learner carrying cumulative state.
No module re-adds a command the carried-forward app already has without acknowledging it.
Each module that depends on starting state states it.

Affected files

modules/06-.../README.md, modules/07-.../README.md, modules/07-.../lab/agent-a-prompt.md, modules/07-.../lab/agent-b-prompt.md (and starting-state notes in M1/M2/M5 as needed)

References

Source finding F15 (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 Following the labs literally, `tasks-app` accretes commands: M1 adds `clear`, M2 adds+commits `count`, M4 adds `delete`, M5 adds `clear` again. Then M6 Part C asks to add `count` AND `clear` again — and its engineered conflict assumes a baseline usage string without `count`. M7 has two agents add `clear` and `count` as "commands neither ever saw." A learner carrying cumulative state already has these on `main`, so the AI may report they exist, the conventions check no-ops, and the shown conflict markers won't match reality. The course never states per-module starting state or resets it. ## Evidence M2 Part B "add a `count` command" → commit "Add count command" (~line 190). M6 Part C step 1 "Add a `count` command…" (~line 326); conflict markers (~lines 376-378) assume baseline usage `[add <title> | list | done <index> | clear]` implying `count` absent. M7 `lab/agent-a-prompt.md` / `agent-b-prompt.md` add clear/count. Modules all anchor to "the tasks-app repo from Module 1/2" with no reset. ## Why it matters M6 Part C is the marquee merge-conflict lab; if `count`/`clear` already exist, the engineered same-line conflict may not materialize and the printed markers won't match — defeating a load-bearing lab. The course markets carry-forward integrity. ## Proposed change Prefer distinct, never-before-used example commands per module so they never collide: 1. In M6's conflict lab, have the two branches each add a *different brand-new* command (any two commands editing the same usage line produces the same conflict), so it works regardless of cumulative state. 2. State the assumed starting state at the top of M6/M7 ("the usage line at this point is …"). 3. If reusing `count`/`clear` is unavoidable, add explicit guidance: "you may already have `count`/`clear` — create them fresh on a throwaway branch" — but note the cleaner fix is distinct command names. ## Acceptance criteria - [ ] M6 Part C's conflict reproduces for a learner carrying cumulative state. - [ ] No module re-adds a command the carried-forward app already has without acknowledging it. - [ ] Each module that depends on starting state states it. ## Affected files - `modules/06-.../README.md`, `modules/07-.../README.md`, `modules/07-.../lab/agent-a-prompt.md`, `modules/07-.../lab/agent-b-prompt.md` (and starting-state notes in M1/M2/M5 as needed) ## References Source finding F15 (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.*