next-ticket

# next-ticket Find the store, read it, name one ticket. The store follows the ticket convention (`../ticket-up/references/TICKET_CONVENTION.md` — read it if the convention isn't already in context). **Finding the store.** Read `tickets/store-config.md` — one fixed, repo-relative location naming the venue. A GitHub-venue config means the store is that repo's issues under the efforts' tracking issues; query instead of reading files. A project that deliberately keeps its store elsewhere says so in its own context file, already loaded when you run. Without either, look before asking: if no store exists anywhere, say so plainly and offer the two ways one appears — `ticket-up` on a finished manifest, or writing tickets by hand under the convention — since a project with no work tracked yet needs a store, not a question about which kind. Where something is there, don't assume which venue it is, not even when `tickets/<effort>/` directories are sitting in front of you, since a project whose store moved to a tracker usually still has them. Ask, showing what you found so the answer is cheap to give, and write it to `tickets/store-config.md` so it's asked once. **Set the candidate scope.** A bare invocation answers rather than asking which effort. When the conversation is already about one effort, scope to that effort. A store that deliberately declares an effort order uses that order; it is explicit operator policy and wins over the default. Otherwise enumerate every effort with ope...