The carry-forward tasks-app already has `delete` (M4) and priority handling (M6), so Module 9's example issues described built work. Reframed: - Issue 2 (agent-ready exemplar): delete -> `undone <index>` (genuinely unbuilt; mirrors `done`, stays crisp with acceptance criteria). - Issue 3 (route-to-human exemplar): priorities -> due dates, kept DELIBERATELY under-specified — open design questions intact, no acceptance criteria, Ready: no, Route to: human. The agent-ready-vs-human contrast is the point. - README routing prose + carry-forward note aligned. Closes #40 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT
4.6 KiB
Issue 1 — bug — route to AGENT
Title: done command crashes on an out-of-range or non-integer index
Context / problem
python cli.py done 99 on a list with 3 tasks raises an uncaught IndexError and dumps a Python
traceback. python cli.py done abc raises ValueError the same way. The user sees a stack trace
instead of a helpful message, and the process exits as if it crashed.
Reproduce:
python cli.py add "first"
python cli.py done 99 # IndexError traceback
python cli.py done abc # ValueError traceback
Acceptance criteria
done <index>with an out-of-range index prints a clear message (e.g.no task at index 99) and exits non-zero — no traceback.done <non-integer>prints a clear message and exits non-zero — no traceback.- A valid
done <index>still marks the task done exactly as before.
Out of scope
Changing how tasks are stored, numbered, or displayed.
- Type: bug
- Priority: high
- Ready: yes
- Route to: agent — contained, reproducible, and verifiable in seconds; clear acceptance criteria mean an agent's first pass is very likely correct.
Issue 2 — feature — route to AGENT
Title: Add an undone <index> command to mark a completed task as not done
Context / problem
You can mark a task done, but there's no way to undo it — flag the wrong index by mistake and the
only "fix" is to delete the task and re-add it. The command should mirror the existing done <index>
command, which already takes an index and flips a task's state; this is simply its inverse.
Acceptance criteria
python cli.py undone <index>clears the done flag on the task at that index and saves.undonewith an out-of-range or non-integer index prints a clear error and exits non-zero (same behavior as the fixeddone, see Issue 1).listafterundoneshows that task as not done ([ ]).- Usage text mentions the new
undonecommand.
Out of scope
A general multi-step undo / command history (separate concern). Changing the storage format.
Proposed approach (optional)
Add a reopen(index) method on TaskList in tasks.py — the inverse of the existing complete —
and wire an undone branch in cli.py, parallel to the existing done handling.
- Type: feature
- Priority: med
- Ready: yes
- Route to: agent — well-scoped and patterned directly on existing code (the inverse of
done); low ambiguity, easy to verify.
Issue 3 — feature — route to HUMAN
Title: Support due dates on tasks
Context / problem
Users want to attach a due date to a task so the list can reflect what's coming up, not just what exists. Today a task is only a title and a done flag. This is desirable but underspecified — several product decisions have to be made before any code is written.
Open questions (resolve before this is ready):
- What date format does the user type, and how forgiving is parsing? (ISO
2026-06-30only, or relative liketomorrow/friday?) - Does
listre-sort by due date, group by it, or just display it inline? - How is a due date set — at
addtime (a flag?) or with a separate command? Can it be cleared? - How are overdue tasks surfaced — highlighted, flagged, sorted to the top — and in whose timezone?
- How is it stored, and what's the default for the existing tasks that have none?
Acceptance criteria
- (Cannot be written yet — depends on the decisions above. Likely splits into 2–3 smaller, agent-ready issues once the design is settled.)
Out of scope
TBD until the design questions are answered.
- Type: feature
- Priority: low
- Ready: no
- Route to: human — genuine design ambiguity. An agent would answer these questions confidently and probably wrongly. A person decides the design, then splits this into clear sub-issues (which may then be agent-ready).