Tasks
The relational engine behind the boards — what a task carries, how work enters, moves and mirrors.
One relational engine
Tasks live in a relational task engine — the source of truth the boards, the browser and the agents share. A board never owns a task; it can carry a projection card of one, kept in sync by the server, so the same task shows the same state everywhere it appears.
Every task records who filed it. Attribution is derived from the credential that made the write — system, eve, agent or human — and is immutable. Origin separately records who requested the work: an agent filing a human request keeps a human origin. Historical work without a known origin stays Unknown. Every change appends to the durable ledger (task_events), which also feeds live project views.
What a task carries
| Field | Values |
|---|---|
| State | One of the project's configurable states; each state belongs to a fixed group: backlog · unstarted · started · completed · cancelled. A project starts with backlog · todo · in_progress · in_review · done · cancelled. |
| Type | task · bug · story · epic for planned work; qa (a feature's test plan) and journey (one user journey under it); meeting (a recorded meeting promoted from the diary); todo (a personal reminder that ripens on a condition). A parent rolls its children up. |
| Category | Permanent workspace classification, such as Bugs, Features or Maintenance. An admin can rename or deactivate it; its identity remains. |
| Origin | human · agent · system · unknown — who requested the work, independent of its filer, category and admission. |
| Priority, estimate | urgent · high · medium · low; a numeric estimate |
| Dates | Start, end, due |
| Assignees | One primary plus any number of others — people or agents |
| Labels | Free per-project labels, created on first use, nestable |
| Rank | A manual order, independent of priority — drag to rank in the List, the Backlog and the Board; the List and the Backlog read in it unless you sort by something else |
| Subtasks and links | Any task can parent others; typed links: blocks · relates · duplicates · custom |
| Custom fields | Per-project typed fields for one task type or all, defined by an admin (Settings → Projects → Fields, vitrinka project fields) and set in the task's properties or with vitrinka task field set; select fields filter like any facet |
| Steps and gates | A checklist on the task itself — steps, human gates waiting on a named person, date gates that tick when their day comes, action items; a when condition ticks an item by itself |
| Comments | Markdown with threaded replies; an @mention puts the task in that person's Waiting on you on the brief and the workspace home, and @eve gets an answer in the thread |
| Attachments | Typed, versioned refs — a recorder session, a screenshot, a board, a file, a pull request or commit, an AI run, a transcript, a hand-back, a decision log, a brief, a final page — each marking whether an agent reads it first, on demand or never |
| Sprint, milestone | Optional membership in one of each |
An epic describes a finite outcome; use a category for an ongoing classification. Sprints have optional dates and can run concurrently. Completing a sprint previews an explicit selection and destination before moving any unfinished work. Names are unique per project; sprints and milestones can be renamed and re-dated, but not deleted.
Organize existing work
Select existing tasks and preview category or parent changes before applying them. The preview shows exactly which identities will change; a concurrent edit requires a fresh review. Applying it preserves task IDs, links, status and history. It does not guess missing origins or bulk-admit Intake proposals.
Meeting tasks
A meeting recorded in your diary stays private until you promote it into a project — Promote to project… on the meeting card, from Snap, or with vitrinka me diary promote <card> --project <project>. It becomes a meeting task carrying the audio and the transcript as attachments, with attendees, the date and a decisions checklist. With an AI backend, vitrinka task meeting-notes <id> has Eve write the notes and decisions and propose the action items as intake drafts; --board also composes a meeting board. Recording one is part of your day.
Intake: proposals before tasks
Intake collects proposed tasks from sources such as annotations, recorded sessions and agents. A proposal stays out of normal task lists until it is accepted, declined or merged. You can also create a task directly. Report approval files accepted work, while GitHub attaches pull-request references to existing tasks — intake.
Finding work
The project page opens on the Overview, led by its sprint timeline, and groups its task displays under Work, Plan and Record, all sharing one filter. Your own desk across projects sits on the Work home under the project table — Waiting on you and In flight. See views and filters for the scope of each display and the supported language shortcuts.
Category, origin and admission are independent filters; Product history retains original evidence.
Automation
Rules are typed documents — a trigger, conditions over the task, actions — with a dry-run against the recent ledger before they are switched on. Eleven ship enabled: seven run with no AI backend, and four hand work to Eve and stay inert without one. Writing or enabling one is an admin action; reading and dry-running is for every member — rules.
Mirroring a tracker
A project can mirror its tasks into Jira. The project picks which side is the truth, the mirror keeps the other side a copy, and a conflict is settled in the truth side's favour with a ledger event saying what was overwritten. Binding and syncing are admin actions — mirroring Jira.
Where you watch it
The project page shows task status, assignees, sprints and upcoming deadlines using data from the task engine. The Timeline draws dated tasks as bars on a window of up to a year — month marks, a today line and dependency elbows between blocker and blocked; drag a bar to reschedule. A task card on a board shows its title, state, assignee and due date; clicking the state changes the underlying task.
Browser and agent access
Use the browser for task views, task details, intake decisions and a project's settings. Configure automation rules and project task mirrors through the HTTP API; the MCP reference lists the tools available to agents. From a terminal, vitrinka task, vitrinka sprint and vitrinka intake manage tasks, sprints and proposals.