claude
2684095e2f
Co-authored-by: claude <claude@jpaul.io> Co-committed-by: claude <claude@jpaul.io>
115 lines
3.9 KiB
Markdown
115 lines
3.9 KiB
Markdown
<!--
|
||
Worked example issues for the tasks-app — Module 9 of "The Workflow".
|
||
|
||
These are a reference / answer key. Write your OWN three issues from issue-template.md FIRST, then
|
||
compare. Yours don't need to match word for word — check that each has a specific title, real
|
||
context (with repro for the bug), concrete acceptance criteria, and a stated scope.
|
||
|
||
Note how the routing call is a property of the ISSUE (clear vs. ambiguous), not the model.
|
||
-->
|
||
|
||
# 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 a `delete <index>` command to remove a task
|
||
|
||
## Context / problem
|
||
|
||
There's no way to remove a task once added — only `add`, `list`, and `done`. Users accumulate stale
|
||
tasks with no way to clear them. The command should mirror the existing `done <index>` command,
|
||
which already takes an index and mutates the list.
|
||
|
||
## Acceptance criteria
|
||
|
||
- [ ] `python cli.py delete <index>` removes the task at that index and saves.
|
||
- [ ] `delete` with an out-of-range or non-integer index prints a clear error and exits non-zero
|
||
(same behavior as the fixed `done`, see Issue 1).
|
||
- [ ] `list` after a delete shows the remaining tasks, re-indexed.
|
||
- [ ] Usage text mentions the new `delete` command.
|
||
|
||
## Out of scope
|
||
|
||
Bulk delete / `clear all` (separate issue if wanted). Changing the storage format.
|
||
|
||
## Proposed approach (optional)
|
||
|
||
Add a `remove(index)` method on `TaskList` in `tasks.py` and wire a `delete` 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; low ambiguity, easy to
|
||
verify.
|
||
|
||
|
||
# Issue 3 — feature — route to HUMAN
|
||
|
||
# Title: Support task priorities
|
||
|
||
## Context / problem
|
||
|
||
Users want to mark some tasks as more important so the list reflects what to do first. Today every
|
||
task is equal. This is desirable but underspecified — several product decisions have to be made
|
||
before any code is written.
|
||
|
||
Open questions (resolve before this is `ready`):
|
||
- How many priority levels? (high/med/low, or a numeric scale?)
|
||
- Does `list` re-sort by priority, or just display it inline?
|
||
- How is a priority set — at `add` time (a flag?) or with a separate command?
|
||
- How is it stored, and what's the default for existing tasks?
|
||
|
||
## 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).
|