snapshot: task-state snapshots

Iron rule: the reader is a new session that knows nothing. There's exactly one bar to clear: reading only this snapshot, they can carry on without re-asking, re-checking, or re-litigating decisions that are already settled. A memo written for yourself doesn't clear it.

Writing a snapshot (wrapping up)

Save it to the workspace draft directory at .issues/<YYYY-MM-DD-topic>/snapshot.md. If the task already has a directory, write into it. When the same task wraps up again later, update that same file (it's a living document, not a log). Before writing to disk, make sure the draft directory is ignored: if git check-ignore .issues fails, append .issues/ to .git/info/exclude (a local ignore, leaving the shared .gitignore untouched) and let the user know. In a non-git environment there's no commit risk, so write directly.

Where the handoff lands decides what must travel. .issues/ is machine-local (gitignored), and uncommitted changes exist only here, which is exactly right when the reader is this machine's next session. When the work moves to another machine or someone else's agent, a local snapshot hands over nothing: push the work to a WIP branch, carry the snapshot's content in something that travels with the repo (the commit message, the PR description, or a file the user chooses to commit), and say out loud which parts stay machine-local.

Five sections, ordered by what the new session needs, not by chronology:

Goal and current state: one line on what the task is and how far along it is overall.
Decisions already made (questions not to reopen): each one with its reasoning. The biggest waste in a new session is re-litigating something already settled: write the reasoning in full, this section never gets to summarize.
Verified state: which files changed, and the actual results of tests and lint (pass or fail, and what command ran them). Anything unverified gets written as "unverified," never "should be fine."
Next steps and blockers: an ordered to-do list, each item with enough context to act on. Blockers get their own list: questions waiting on the user's call stay exactly as open questions, don't decide for them.
State pointers: branch, uncommitted changes, commands that need rerunning, key file paths, rollback point, and what has to be running for the work to continue (dev server, containers, required environment variables).

Content discipline: