# What vitrinka offers (https://docs.vitrinka.ai/start) ## The loop [#loop] One sentence from a tester becomes a work item with the screen, the region and the branch already attached. A listening agent takes it off the queue, fixes it, and hangs the after-shot beside the original. * **Capture** — a recorder, an agent or a CI job publishes what it made: screenshots, a session, a document, a diagram, any files. * **Annotate** — someone with access to the board marks a problem or answers a question from the agent. * **Fix** — an attached agent reads the item, changes the code, and publishes the proof back to the same board. The work is the record: a task pickup and hand-back, a commit trailer, a published test run or a pushed board writes the ledger, and nobody files a status report. The server organizes uploaded content and provides searchable summaries, so an agent can read the relevant evidence without loading every file. ## Who it is for [#personas] | You | What the board is for you | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Developer | Your day tracked without reporting: pickups, hand-backs, runs, PRs, commits and todos that ripen on their own trigger build the task's timeline, and every screen an agent produced lands on a board to circle and fix. | | QA | Recording instead of reporting: turn on the recorder, annotate as you test, and the server distils the session, files and merges tickets, and hands developers the full reconstruction. Runner results (Playwright, JUnit, allure…) publish into the same QA record without changing your tests. | | Product | The native home for tasks, epics, sprints, milestones, releases, custom fields and automation rules. The board is the status report; Jira is an optional per-project mirror. | | Everyone | The diary and meetings: one personal board per day for snaps, voice notes and recorded meetings, rolled up into weekly, monthly and yearly views. | Each has its tab: [Using vitrinka](/use) for what everyone does in the app, [QA & Testing](/qa), [Developer](/dev) and [Product](/pm). Whoever runs or reviews a deployment reads [Operator](/operator) and [Security](/security). ## What a board holds [#surfaces] A board is a canvas of cards: images, notes, pages, tasks and other content. Use the browser to inspect and edit supported card types, or let an agent compose content through MCP. | Card | What it is | | -------------------- | ---------------------------------------------------------------------------------------------------------- | | Screens and sessions | Screenshots with regions and notes; replayable recordings with DOM, network and console on one timeline. | | Journeys | Screens wired in the order somebody walked them, branches rendered as signposts. | | Documents and pages | Written content, tables, charts, findings and code, with documents linked through `ref` elements. | | Diagrams | Architecture generated from docker-compose, OpenAPI, a SQL schema or a live database, editable afterwards. | | Tasks and questions | Projections of the task engine, and structured questions with staged answers. | | Artifacts | Self-contained interactive pages, live on the canvas, updated in place at the same URL. | The full vocabulary — every element kind, every board card kind, with its payload contract — is the generated [elements reference](/reference/elements). ## The four pieces [#pieces] | Piece | What it is | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Server | One static Go binary: HTTP API, web UI, MCP server at `/mcp` and SQLite, with blobs on disk or S3. | | Clients | The `vitrinka` CLI and the Claude Code / Codex plugin with its skills. `vitrinka setup` registers each agent harness against the deployment's own `/mcp` over HTTP. | | Boards engine | The board canvas, shipped as part of the server's browser assets. | | Public web | The marketing site and this documentation — separate services, never in the binary. | ## The apps [#apps] Beside the browser there is a desktop app, Snap (the menu-bar helper for the diary and meetings), a browser extension that records journeys, in-app recorders for React web apps and Expo apps, and an embeddable bug-report widget. Each is described on [the apps](/start/apps). ## The npm packages [#packages] The CLI and the recorders are distributed under the `@vitrinka` scope. | Package | What it is | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | `@vitrinka/cli` | The `vitrinka` CLI in one global install for macOS, Linux and Windows. | | `@vitrinka/web` | The in-app journey recorder for React web apps: testers record from a dev or preview build without an extension ([the web recorder](/qa/recorder/web)). | | `@vitrinka/expo` | The Expo / React Native toolkit — today it carries the journey recorder. | `@vitrinka/cli` automatically installs the binary for your platform (`@vitrinka/cli--`). You do not need to install the platform packages separately. ## Where your data goes [#where] Your configured server stores metadata in SQLite and files on disk or in S3-compatible storage. Sensitive content fields and blobs are encrypted with workspace keys. For networks without internet access, use the air-gapped deployment settings. See [Security](/security) for the scope of each control. * **Capture destination** — recorders send captured application data to the server you configure. Installation and update tools may also contact the configured release services. * **Access control** — workspace access uses browser sessions or bearer tokens; share links have their own access rules. * **Audited** — sign-ins, role changes, connector consents and break-glass use are recorded in an append-only log.