A real work item, start to ship
A beginner asks for a feature in plain English. Six specialist agents carry it through one shared file, and when it isn’t right, it goes back around. This is the actual record, condensed.
> Add a way to delete a task.
Turned one sentence into a work item: what’s in, what’s out, and 10 numbered acceptance criteria someone can check by running the app. Kept the data stage in the plan because this is the app’s first command that destroys data.
Asked the person two questions, each with a safe default: no undo, and a deleted top number gets reused by the next task.
Wrote every line the person will see: Deleted #2: finish the report, two error messages, the README example, and a 12-step worked example.
One line of that example could never happen as typed. Nobody knew yet.
No database change was needed, but before any code existed it found the trap that would have broken every delete:
Number('3') binds as REAL 3.0 and matches nothing, so every delete would report “no task”.
Set the rule the builder followed (pass the id as text) and left 6 data checks for the tester.
Built the command on the DBA’s rule. 11 new tests, 18 of 18 passing.
Reported that the designer’s whole example “reproduced line for line” in a real shell.
Re-ran everything in PowerShell, the way the person would: all 10 criteria, about 15 extra edge inputs, and the DBA’s 6 data checks. Ended with three “Try it yourself” steps for the person.
Also noted that delete #3 can’t work as the example shows, because the shell treats #3 as a comment, and that the builder’s “line for line” claim “can only hold if #3 was quoted.”
The person tries it, and it goes back to the designer. “list shows my tasks as #1, #3, so I typed delete #3 and it told me delete needs a task id — but I gave it one!”
The person’s experience says the design is what failed.
Owned the wrong example line and rewrote both error messages to teach the fix: (number only, no #: most shells treat #1 as a comment and never pass it on)
Rebuilt to the new wording. 19 of 19 tests passing.
Ran the README’s commands exactly as written. The last one did nothing: it read delete #1, so the task stayed on the list. All 19 tests still passed; only a real run could see it.
This defect was planted on purpose during the test run, to prove the tester catches what tests can’t.
Back to the builder. The tester named the owner and set the item’s status to rework — builder, round 3.
Restored delete 1, re-ran the README block in PowerShell, 19 of 19 passing.
Every criterion, every data check, and the designer’s new example: 22 of 22 lines identical, with delete #3 typed the way a person would type it.
Version 0.1.1 and a changelog line, a smoke run of the README block, and a support note for the next “it didn’t delete” report: the shell ate the #, type the number alone. Status: shipped.
The DBA found the number-versus-text trap before a line was written. The builder never hit it.
The tester caught a claim the builder couldn’t have verified, and a defect 19 passing tests couldn’t see.
Lap 1 passed every test. The person’s own try still sent it back, and the error messages came out better for it.
.claude/pipeline/WI-002-delete-task.md.