Files
ai-workflow-course/modules/09-issues-and-the-task-layer/lab/example-issues.md
T
justin 3221f7abe8
CI / check (pull_request) Successful in 7s
Use python3 as the canonical command name course-wide (#104)
Most current systems (default Debian/Ubuntu, recent macOS) install Python
only as `python3`, with no bare `python` on PATH, so learners who copied
`python cli.py ...` into their host shell hit "command not found".

Convert host-shell `python <cmd>` -> `python3 <cmd>` across module/lab
READMEs, lab `.py` docstrings & usage strings, blog posts, lab prompt and
instruction files, the M04 verify.sh message, and the M10/M24 lab patches.
Module 01's convention note (and its blog/02 mirror) is rewritten so
`python3` is canonical and `python` is the documented fallback.

Stop-lines respected: Docker image tags (`python:3.12-slim`), `.venv/.../python`
and `...\.venv\Scripts\python.exe` paths, the M20 `"command": "python"`
teaching example and surrounding venv prose, container-internal invocations
(M16/M18 Dockerfiles, M16 README `docker run` examples), and CI-workflow
`run:` steps fed by `actions/setup-python` / `image: python:3.12` are left
as `python` on purpose.

pip was left out of scope: most occurrences are prose or CI/container-internal,
and `pip3` does not fix the PEP 668 externally-managed-environment refusal that
the course already addresses with venvs. The M01 note is worded to stay
consistent with bare `pip` (use whichever pip pairs with your Python).

Build (tools/build_wiki.py) and tools/check.sh both pass.

Closes #104

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GAEzanEoGJT5o1VizQar47
2026-06-23 20:18:04 -04:00

4.6 KiB

Issue 1: bug, route to AGENT

Title: done command crashes on an out-of-range or non-integer index

Context / problem

python3 cli.py done 99 on a list with 3 tasks raises an uncaught IndexError and dumps a Python traceback. python3 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:

python3 cli.py add "first"
python3 cli.py done 99      # IndexError traceback
python3 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, with no traceback.
  • done <non-integer> prints a clear message and exits non-zero, with 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

  • python3 cli.py undone <index> clears the done flag on the task at that index and saves.
  • undone 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 undone shows that task as not done ([ ]).
  • Usage text mentions the new undone command.

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-30 only, or relative like tomorrow / friday?)
  • Does list re-sort by due date, group by it, or just display it inline?
  • How is a due date set: at add time (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).