Working the queue

#/vitrinka:listen

Tunes a session into a board and works its queue continuously. The session is the worker half of an audit loop: someone annotates screens, you fix each one in this repository, attach visual proof, and go back to listening.

• Armed by a native monitor — vitrinka watch long-polls the queue and prints one line per new annotation; each line re-invokes the session.
• Idle costs nothing — while the queue is quiet it prints nothing and burns no context. Silence means healthy and idle, indefinitely.
• Auto-scoped — with no board argument it listens for exactly this repo and branch.

This replaced an in-model loop that had two fatal flaws: a finished turn cannot re-invoke itself over MCP, so the session that published the board never heard new work — and a looping session burned a context entry per idle heartbeat until it died by compaction.

#/vitrinka:resolve

For an accumulated backlog rather than a live queue: someone swept the app, dropped dozens of annotations, and handed over the whole set.

• Groups before it fixes — a 65-item board is usually 8–12 real workstreams; five items asking for the same component are one rollout, not five fixes.
• One call for the whole picture — fetching each annotation individually burns tens of thousands of tokens on briefs you mostly do not need.
• Every item ends with proof and a status — a fixed annotation the board still shows as open is unfinished work.

#/vitrinka:review

Drives an AI review pass over a board — the whole board, one journey section, or a chain of passes — then fixes the findings that are real in the repository.

#When dispatch does not arrive

Board interactions are staged and released as a batch. If that release never reaches the session — the monitor was not armed, the lease went to another session, the wake line was lost — two skills read the durable record directly.