vitrinka.docs

Boards as the status report

How boards carry decisions and proof while the work happens.

Proof, not prose

A board fills up while the team works: screenshots as agents build, whole journeys walked in order, recorded test sessions, release pages. Each card is the thing itself — the screen, not a description of the screen — so "is it done?" is answered by looking, not by asking.

When something is wrong, anyone draws a region on the card and writes one sentence. That annotation becomes a work item with the screen, the region and the branch already attached; a listening agent fixes it and hangs the after-shot beside the original as a before/after deck. You accept or reject the fix on the board — an agent can never mark its own work resolved.

Decisions live where the work is

  • Annotation threads — each annotation carries a conversation. The agent reports what it did, asks clarifying questions, or pushes back, and the exchange stays attached to the exact region it is about.
  • Statuses — an annotation moves through its lifecycle visibly: picked up, in review with the after-shot attached, then resolved by your accept in the board UI.
  • Questions — agents ask you multiple-choice questions in the board's Questions panel, answered with one-click pills, and the answers stay there as a durable record. That flow has its own page.

Review passes

run review (the board's ⋯ menu, or the review view of the board's Annotations panel; vitrinka review judge <board> from a terminal) queues the server-side judge over the board's screens, optionally with a focus ("check the empty states"). Each screen is judged against the team's review rules, and every proposed finding — plus a sample of passes when you ask for calibration — is audited independently. Results appear in the Annotations panel's review view, grouped by rule — pass, finding, needs evidence — each with its evidence crop. File finding files it on the board as a staged annotation, Dismiss drops it, and a usefulness rating tells the rubric what was worth it. After a fix, Verify a fix audits a fresh capture. Passes only start when someone asks, and earlier findings stay readable under Historical board findings. How the judge works: the review toolkit.

Keeping hundreds of boards findable

Every board belongs to a project, and within it a subgroup:

SubgroupWhat folds there
reviewsPR-review boards
testingQA and set boards
sessionsRecorded user-testing sessions
brainstormingDecision-led design sessions
designMockups and design directions
journeysTesting-journey suites
releasesRelease pages, rolling and cut
docsLiving-docs boards
bugsThe project's bug board of approved reports

In the project's Record › Boards display, boards group under their epic first, then by subgroup.

Boards also carry free-form tags on top of that — a shared vocabulary with per-tag usage counts, so "all boards about onboarding" is one filter, and the sidebar order itself is yours to drag.

On this page