ticket-speclisted

# Specifying a ticket A ticket is dispatchable only when it carries all five sections (`docs/protocol.md` §5). Most of that is **derivable from the codebase, not from the human**: `Source File Pointers`, `Owned Paths`, and `Verification Command` are search-and-read problems. `Acceptance Criteria` is usually the problem restated observably. Only genuine product intent needs a person. So the job is not "spec everything" — it's **sorting tickets into three piles** and handling the first two yourself. ## The three outcomes **Auto-specifiable** — the problem is unambiguous and the answer is in the code. Explore read-only, write all five sections, promote to `Todo` + `ai:agent-ready` **plus a `tier:*` label**. ### Sizing the `tier:*` label Closed vocabulary, at most one per ticket: `tier:light`, `tier:standard`, `tier:strong`. - `tier:light` — one or two files in `Owned Paths`, no path under `escalate_paths` (`config/repos.yaml`), `type:docs` / copy / config-value changes, or a `type:bug` with a repro and a one-line expected fix. - `tier:strong` — any path under `escalate_paths` (auth, payments, migrations, prod infra), `type:security`, cross-package or architecture work (`area:architecture`), anything whose acceptance criteria say "design"/"decide" or list open questions, or a ticket that previously failed verification. - `tier:standard` — everything else (the default). If the ticket already carries a `tier:*` label, leave it — don't recompute or overwrite an existing tier