Fix Module 11 Part C hard-coded task index 1, which breaks on a carried-forward tasks.json #14

New Issue

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

claude commented

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

Problem

Part C step 4 hard-codes python cli.py done 1 to mark "trash" done, then verifies "keeper remains, trash is gone." cli.py done is 0-indexed (tlist.complete(int(argv[1]))), so this only works on a fresh two-item list. The lab uses the carried-forward tasks-app, which has accumulated tasks since Module 1 (and tasks.json is local-only, not reset). With pre-existing tasks, done 1 marks an OLD task, leaving "trash" pending, so clear-done removes the wrong task and the inline verification silently fails with no explanation.

Evidence

modules/11-collaboration-humans-and-agents/README.md, Part C (~lines 323-325):

python cli.py add "keeper"
python cli.py add "trash"
python cli.py done 1
python cli.py list   # keeper remains, trash is gone

cli.py done is 0-indexed via int(argv[1]) → self.tasks[index].

Why it matters

A flagship synthesis lab asserts a fixed expected output against state that varies, making a correct implementation look broken.

Proposed change

Tell the reader to run python cli.py list first and use the index it shows for "trash" (do not assert a fixed index), OR
Note explicitly that the inline indices assume a fresh list and have the reader clear/ignore prior tasks first.
Prefer option 1 (list-then-use-shown-index) — it is robust to carried-forward state.

Acceptance criteria

The step no longer assumes a fixed task index against carried-forward state.
The "keeper remains, trash is gone" outcome holds regardless of pre-existing tasks.

Affected files

modules/11-collaboration-humans-and-agents/README.md

References

Source finding F25 (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 Part C step 4 hard-codes `python cli.py done 1` to mark "trash" done, then verifies "keeper remains, trash is gone." `cli.py done` is 0-indexed (`tlist.complete(int(argv[1]))`), so this only works on a fresh two-item list. The lab uses the carried-forward `tasks-app`, which has accumulated tasks since Module 1 (and `tasks.json` is local-only, not reset). With pre-existing tasks, `done 1` marks an OLD task, leaving "trash" pending, so clear-done removes the wrong task and the inline verification silently fails with no explanation. ## Evidence `modules/11-collaboration-humans-and-agents/README.md`, Part C (~lines 323-325): ``` python cli.py add "keeper" python cli.py add "trash" python cli.py done 1 python cli.py list # keeper remains, trash is gone ``` `cli.py` `done` is 0-indexed via `int(argv[1])` → `self.tasks[index]`. ## Why it matters A flagship synthesis lab asserts a fixed expected output against state that varies, making a correct implementation look broken. ## Proposed change 1. Tell the reader to run `python cli.py list` first and use the index it shows for "trash" (do not assert a fixed index), OR 2. Note explicitly that the inline indices assume a fresh list and have the reader clear/ignore prior tasks first. Prefer option 1 (list-then-use-shown-index) — it is robust to carried-forward state. ## Acceptance criteria - [ ] The step no longer assumes a fixed task index against carried-forward state. - [ ] The "keeper remains, trash is gone" outcome holds regardless of pre-existing tasks. ## Affected files - `modules/11-collaboration-humans-and-agents/README.md` ## References Source finding F25 (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.*