feat(course): build out all 27 modules, capstone, scaffold, and conventions
Scaffold the course repo and author the full curriculum in dependency-chain order, following the settled build decisions in handoff.md. - Scaffold: course README, vendor-neutral AGENTS.md (dogfoods Module 5), _TEMPLATE.md (the fixed 9-section module shape), root .gitignore, ship config. - Modules 1-2: reference exemplars (locked for tone/depth/lab style). - Modules 3-27: full lessons + runnable labs, each following the template, respecting the chain, vendor/model-agnostic, with "feel the pain" labs. - Module 8 hosting comparison web-researched and date-stamped (as of 2026-06-22), not written from memory; expansion-zone modules carry Verify-before-publish. - Capstone: the full loop end to end on the running tasks-app example. Lab code syntax-checked (Python/shell/YAML); every module has the 7 core template sections. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT
This commit is contained in:
@@ -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).
|
||||
@@ -0,0 +1,44 @@
|
||||
<!--
|
||||
Well-formed issue skeleton — Module 9 of "The Workflow".
|
||||
|
||||
Copy this for each issue you draft. Fill every section. Write it for a STRANGER: a teammate you've
|
||||
never met, future-you who's forgotten, or an agent with no memory. Delete these comments as you go.
|
||||
|
||||
Most forges also let you commit issue templates into the repo so the web "New issue" form is
|
||||
pre-filled with this shape. The conventional location varies by forge; check yours. The structure
|
||||
below is what matters and ports anywhere.
|
||||
-->
|
||||
|
||||
# Title: <specific, scannable — someone reading 40 titles should know what this is>
|
||||
|
||||
## Context / problem
|
||||
|
||||
<What is wrong or missing, and WHY it matters.
|
||||
- For a bug: the exact command you ran, what happened, and what you expected.
|
||||
- For a feature: the motivation — what the user can't do today.>
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
<The checklist that defines DONE. Concrete and verifiable. This is the most important section —
|
||||
it is the definition of done for a human AND the spec for an agent.>
|
||||
|
||||
- [ ] <verifiable statement, e.g. "`done 99` prints a clear error and exits non-zero">
|
||||
- [ ] <...>
|
||||
- [ ] <...>
|
||||
|
||||
## Out of scope
|
||||
|
||||
<What this issue does NOT cover, so the work doesn't sprawl into a refactor.>
|
||||
|
||||
## Proposed approach (optional)
|
||||
|
||||
<A suggestion, not a spec. The person or agent doing the work may know a better one. Leave blank
|
||||
if you don't have one.>
|
||||
|
||||
---
|
||||
|
||||
<!-- Metadata you set on the forge, noted here so the draft is self-contained -->
|
||||
- **Type:** bug | feature | chore
|
||||
- **Priority:** high | med | low
|
||||
- **Ready:** yes/no (acceptance criteria solid enough to start?)
|
||||
- **Route to:** human | agent — and one sentence on WHY (in terms of the issue's clarity/scope)
|
||||
Reference in New Issue
Block a user