Spec first, implementation after

We are going to work in two phases. In this one you will not write code, not even an example.

PHASE 1 (now): interview and spec.

Interview me until you can write a spec that someone else could implement without talking to me. Ask one short question at a time and only the ones that materially change the result. Prioritize in this order:
1. What real problem this solves and for whom.
2. What has to be true to say it worked (an observable criterion, not a feeling).
3. What is out of scope, stated explicitly.
4. What already exists in the repo that should be reused instead of reinvented.
5. Non-negotiable constraints: data, permissions, performance, compatibility.
6. What happens in the odd cases: empty input, permission denied, service down.

When you have enough, write the spec in a `SPEC.md` file with these sections and nothing else:
- Problem (3 lines max)
- Scope and out of scope
- Expected behavior, case by case
- Verifiable acceptance criteria
- Decisions made and why the alternative was dropped
- Open questions that remain

PHASE 2 (new session, clean context): implement reading only the `SPEC.md`.

Hard rule for phase 1: if you catch yourself describing how it will be coded, you went off track. The spec says what and why; the how belongs to phase 2.