# Boards as the status report (https://docs.vitrinka.ai/pm/status-boards)



## Proof, not prose [#proof]

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 [#decisions]

* **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](/pm/questions).

## Review passes [#reviews]

**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](/qa/review-toolkit#brief), 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](/qa/review-toolkit#judge).

## Keeping hundreds of boards findable [#organization]

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

| Subgroup        | What folds there                            |
| --------------- | ------------------------------------------- |
| `reviews`       | PR-review boards                            |
| `testing`       | QA and set boards                           |
| `sessions`      | Recorded user-testing sessions              |
| `brainstorming` | Decision-led design sessions                |
| `design`        | Mockups and design directions               |
| `journeys`      | Testing-journey suites                      |
| `releases`      | Release pages, rolling and cut              |
| `docs`          | Living-docs boards                          |
| `bugs`          | The 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.