The results
Your runner, untouched.
Keep Playwright, Appium, Selenium, Cypress, Maestro or your own harness exactly as it is. vitrinka reads what a run leaves behind and folds it into the feature's QA record; it never starts a browser or drives a device.
01
Wrap the command you already run
Put vitrinka qa run -- in front of your test command and the command runs exactly as it is. When it exits, the CLI finds what the run left behind, folds it into one run manifest and publishes it. Nothing in your suite changes.
- What it reads — JUnit XML — the reporter of Playwright, Jest, wdio, Go and most others, which alone covers Selenium, Cypress, Maestro, Detox and a home-grown harness — a Playwright JSON report, an allure-results directory or wdio's JSON reports.
- Your exit code, untouched — the test command's exit code is the CLI's exit code, so a failed publish never hides a failing test, and the other way round.
- Or write the manifest yourself — a runner that writes the v1 run manifest publishes it with vitrinka qa run publish; --dry-run runs and folds, prints the manifest and publishes nothing.
02
Folded into the feature's QA record
One door turns the manifest into the record — no publisher agent, no hand-written comments. The run lands on the task you name, else on the feature of the checkout's vt-<id> branch, else on the project's rolling Unplanned runs epic.
- Verdicts per journey — every case passed is pass, any failure is fail, passes with skips are partial, and a plan's coverage rolls up from its journeys.
- Evidence on the QA board — each journey's section carries the run, its cases as a checklist and a card per screenshot. The same run published again replaces its own cards; a new run appends beneath.
- A bug draft per failing case — each failure files a bug draft through intake that blocks its journey and waits for a verdict — or, if you choose, a live bug, or nothing at all.
03
A plan you can walk
A feature's test plan is a qa task, each user path under it a journey, and each journey a flow of steps. When a run arrives before any plan does, the plan is created for it, with a journey per spec.
- Steps that branch — a step is act, verify or wait and can say what proves it; its next can point into another journey, which is how a flow branches or loops back. The checklist a tester ticks is derived from the flow.
- Drawn as it is — the server draws the plan as one diagram — a lane per role, each journey's steps left to right, and only the edges that next and blocks links make. Click a step and the journey opens with that step in the flow editor.
- By hand, the same record — an exploratory session — a person's, or an agent's through /vitrinka:usertest — opens a case per thing tried, snaps screens into it and publishes through the same door.