Live pairing

Pairing turns a testing session into a loop: the tester records with the vitrinka recorder and marks bugs as they go, each mark reaches your session as work within seconds, and you fix it in the app they are still using. vitrinka qa pair is the supervisor that makes the last step real — it owns the app under test, so a fix reaches the running app the moment it lands.

Supervise the app

vitrinka qa pair run            # all stacks
vitrinka qa pair run web api    # named stacks

Starts each stack from the run section of the committed repo-root vitrinka.config.json — the same stacks the sessions autopilot boots, never a second manifest. Each runs detached with its output tee'd to .vitrinka/logs/pair-<stack>.log, truncated per run, and blocks until its readiness probe answers. Re-running is safe: a stack that is alive and ready is reused, not restarted. Hand the tester each stack's URL and let them start.

Ship a fix into the running app

vitrinka qa pair restart web

Stops and re-starts the named stacks (all when none named) and waits for ready. Stacks marked "hot": true in the project map — HMR and Metro, where the file save already reached the app — are a deliberate no-op. State on disk survives every restart: pair never wipes a database, a login or a board.

Watch and read

vitrinka qa pair status         # supervision, liveness, readiness per stack
vitrinka qa pair logs web       # log path + tail of the current run
vitrinka qa pair stop           # stop supervised stacks
vitrinka qa pair relay          # opt-in: stream your session's reply text to the tester's pair panel

Each stack's log is one small file answering "what did this run print" — agents read it directly. relay tails this repo's newest Claude Code transcript and forwards only the assistant's visible text — never thinking, tool calls or your own turns — starting from now; the server stores nothing. It is still your session's raw prose on the tester's screen, so it stays off unless you run it.

The ⌖ snap flow

While you supervise, the tester works in the browser extension. The ⌖ button snaps the exact screen with a note; the snap is born as dispatched work and lands in your session's queue seconds later. The recorder HUD shows the tester your presence and your progress the whole way — you set a status, fix on a rolling pair branch, restart the stack, and reply on the thread; they verify by reloading the screen they were already on and accept or bounce the fix from the panel.

The status the tester reads in the app is board_working, a rare-module MCP tool: it is listed only when the registration names that module. vitrinka setup composes the registration from the plugins you installed (?modules=core,pm,me,qa), and naming modules lists only those, so add rare by hand and keep every one you have — for example https://app.vitrinka.ai/mcp?modules=core,pm,me,qa,rare — the catalogue.

Arm the loop

The /vitrinka:pair skill arms all of it — the project map, the pair worktree, the supervisor, the work listener, and the per-snap fix protocol:

claude "/vitrinka:pair"

Run it from the app's repo before the tester starts. One pairing run lands as one branch and one PR, and the app stays running when the session ends.