vitrinka.docs

Intake

Proposals before tasks — drafts with a source and a dedupe verdict, accepted, declined or merged.

Propose work for review

Intake lets you review proposed work before adding it to normal task lists. A proposal becomes a draft with its source and a duplicate check, then waits for acceptance, rejection or merging. Explicit task creation can bypass this queue. Approving a recorder report creates accepted work; a GitHub pull request links to tasks it mentions rather than creating a draft.

What a draft carries

FieldWhat it says
SourceWhere the proposal came from — a session, an annotation, a report, a pull request, Eve, a script — with a link back.
OriginWho requested it: human, agent, system or Unknown. This is distinct from the credential that filed the draft.
CategoryAn independent classification chosen during filing or review; Intake itself is not a category.
Dedupe verdictA similarity score over the project's open tasks says whether the draft is new or a likely-duplicate of a named task.
EnrichmentOptional: the AI backend can fill in type, priority and labels; it fails open, so a draft is never blocked on it.

The verdict

A workspace admin, or an agent credential, gives each draft one of three verdicts:

  • Accept — it becomes a normal task, in the state the project starts new work in.
  • Decline — it leaves the queue with a reason; vitrinka intake list --status declined still shows it.
  • Merge — it is folded into the task it duplicates; the draft is soft-deleted with a pointer to that task, so the source stays traceable.

The one exception: whoever filed a pending draft may decline it themselves, which withdraws it.

Work accepts a draft, too. Starting a session run on a pending draft (vitrinka task start <id>, or the session hook binding it), or a pull request that claims it (its branch or title names vt-<id>, or its body says Closes vt-<id>), accepts it: someone working it is the verdict, and the ledger event says so (by: work). Eve's own runs and plan changes never count, and a pull request that only mentions a draft leaves it in the queue.

Every verdict is a ledger event on the task, with the actor recorded. Accepting, declining or merging does not rewrite origin. Category and admission remain separate filters, so human-requested work filed by an agent stays findable as human-requested.

The Intake screen

Intake is the first row of the Work sidebar, with the number of drafts waiting across every project of the workspace. It opens /intake: the queue on the left, the focused draft on the right.

  • Groups — stale plan changes first, then plan changes, then one group per source (QA plans, pull requests, runs, sessions, …), each with its count and Accept all / Decline all (the stale group offers Decline all only).
  • Stale — a plan change whose task is already done, deleted or merged, or whose change already holds (the estimate is already set). Stale is only a flag; nothing is declined for you.
  • The detail — the reason the filer gave, what accepting changes on which task, the draft's body and source, and the tasks it probably duplicates with a one-click merge.
  • Keys — j / k move, a accepts, d declines, m merges, x selects, Enter opens the task, u undoes. A verdict moves to the next draft.
  • Undo — every verdict, single or bulk, waits 5 seconds behind an Undo before it is sent.
  • The project filter narrows the screen to one project (/intake?project=<name>); the project page's old Plan › Intake address lands there.

Every member sees the queue; the verdict keys answer for admins and agent tokens, and for the person who filed a draft only to decline it.

Cleaning the backlog

Tasks pile up faster than anyone grooms them. /vitrinka-experimental:cleanup [project], run from the project's repository, makes one unattended pass over its open tasks — a workflow of the experimental plugin, Claude Code only. It inventories every open task, groups duplicates, contradicted statuses, orphans outside their epic, epics nobody closed and stale work, verifies each suspect against the code, the pull requests and the QA record, applies what is proven and proposes the rest, then writes one report page.

  • You set the trust before the run — evidence (the default) applies only proven corrections, such as a merged pull request, a passing run or a commit trailer, and turns likely closes and merges into plan proposals; all applies the likely ones too; none applies nothing, a dry run.
  • Nothing is deleted — a duplicate is linked with duplicates and cancelled, so the survivor keeps the history, and every applied change leaves one comment on the task naming its evidence.
  • Your calls wait here — its proposals join Plan changes on the Intake screen, and new work it found arrives as Cleanup drafts, each for your verdict.
  • It stays in its lane — only task, bug, story and epic; todos, QA plans, journeys and meetings are never touched.

Where it happens

  • The Intake screen — the whole workspace's queue, grouped, one key per verdict.
  • The board — “make this a task” on an annotation files a draft. Approving a recorder report files an accepted bug task; an external ticket is requested automatically only when the project's auto-ticket setting is enabled.
  • The recorder — a ⌖ snap sent with the task destination also files a draft for triage; drafts are never accepted automatically.
  • Agents — propose_tasks files drafts, list {kind: "intake"} reads the queue, intake_verdict decides.
  • The terminal — vitrinka intake list, vitrinka intake propose, vitrinka intake accept, vitrinka intake decline and vitrinka intake merge.
vitrinka intake list
vitrinka intake propose "Cart total ignores the second coupon" --body "Seen in session 418, second coupon is dropped at checkout"

The GitHub integration attaches pull requests to the tasks they mention as refs; it does not file drafts by itself.

On this page