<!--
  Well-formed issue skeleton for 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, i.e. 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, plus one sentence on WHY (in terms of the issue's clarity/scope)
