Build out all 27 modules + capstone (#1)

Co-authored-by: claude <claude@jpaul.io> Co-committed-by: claude <claude@jpaul.io>
2026-06-22 12:19:01 -04:00
parent 4bd586bbd0
commit 2684095e2f
117 changed files with 15131 additions and 1 deletions
@@ -0,0 +1,114 @@
+<!--
+  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).