The memory
A memory, not a tracker.
Every task with its history, its evidence and its decisions, kept in one place, distilled by Eve and read by your coding agents in as few tokens as the answer needs. Secure, reliable, and shaped for agents as much as for people.
01
Built for the speed agents work at
Jira and Plane were designed when a ticket was written once, by a person, and read a few times. Agents now write and read hundreds of times a day. The task engine here was designed with that reader in mind from the first table.
- A different reader — the reader is a coding agent as often as a person, so every read is shaped to cost the price of the answer, not the price of the project.
- Nothing is replaced — a file uploaded again is the next version of the one before it, with its lineage kept. History, artifacts, conversations and decisions stay on the task.
- Out of your way — built by a developer with one intention: vitrinka will not stay in your way. Keep Jira; mirror a project when the team wants it, and never depend on it.
02
What a task keeps
Every change to a task appends one row to a ledger, in the same transaction as the change. Evidence hangs off the task by kind, and a task can be any of eight types.
- The ledger — created, updated, deleted, linked, unlinked, commented, labelled, ranked, intake, mirrored, run: one row per mutation, written with the change itself.
- Typed references — session, shot, board, file, pull request, run, transcript, conversation, brainstorm, plan, handoff, decision, distillation, commit, final, brief and meeting notes. Attached by kind, so a reader can ask for one kind only.
- Eight types, one tree — task, bug, story, epic, todo, qa, journey and meeting, nested through a parent. Links of kind blocks, relates, duplicates, supersedes or your own, and a link may cross projects.
03
The engine
States, fields, rules and intake are ordinary parts of the engine, not add-ons. A value is checked inside the task's own write, a rule fires from the ledger, and a proposal stays invisible until somebody accepts it.
- States, priorities, fields — five state groups with per-project states, four priorities, labels, sprints that carry over, milestones, and eleven kinds of custom field, each validated in the same transaction as the task it belongs to.
- Rules — a trigger on a ledger event or a schedule, conditions on status, priority, type, assignee, label, dates and a merged pull request, actions from a status change to a comment to an Eve flow. A dry run replays the rule over the ledger before it is saved; eleven ship built in.
- Intake — one door for proposals from sessions, annotations, reports, pull requests, runs, Eve and the API. A draft is checked against what already exists and stays out of every view until it is accepted, declined or merged — on one Intake screen for the whole workspace, grouped by source, one key per verdict.
04
One filter, six views
Six task views read one filter document. It is the same shape on the server and in the browser, byte for byte, and it travels in the URL, so a saved view, a shared link and an agent's query are the same thing.
- Four hubs — the Brief; Work — list, board, table and timeline; Plan — backlog and calendar; Record — QA, activity, time, boards and artifacts. Intake has its own screen across the workspace, and the workspace's home gathers your own work from every project. The task views sort by rank, priority, due or created, and group and subgroup.
- Keyset, never offset — a page of up to 200 rows continues from a cursor that carries its own order. Full-text search over FTS5, live updates over server-sent events, and the keyboard first: c, ., j and k, e, a, m, x.
- Measured at scale — the repository carries a 500,000-task benchmark corpus, and the store answers the first page of the list in about 0.75 ms, measured at the store layer on a laptop. Partial indexes carry the live predicate, so every page is a seek.
05
How an agent reads it
An agent does not page through tasks to count them. It asks the server, which aggregates in SQLite and answers with the numbers. The tools carry the same semantics as the human surface.
- One report, not a stack of pages — summarize_tasks groups and counts server-side. One report over 94 tasks in 5 groups comes out at roughly 61 tokens; listing them page by page for the same counts would cost about 10,900.
- No hidden truncation — a report with more than 100 groups fails and says so instead of guessing. read_task_ref reads a reference against a budget, ask_task answers about one task, and query is one read-only SELECT over the ledger, audited.
- Every call on record — the agent_calls ledger records every agent call with its sizes and never its bodies. None of these reads needs a server-side model; only ask_task answers through Eve, and it says so when no backend is connected.
06
Eve distils
Eve is the layer on top, not the floor. It distils tasks and their references, writes the morning brief and proposes changes. Each proposal is an intake draft, and nothing applies without a verdict.
- Distilled, kept beside the original — a long transcript or conversation becomes a distillation attached to the task; the original stays where it was.
- The brief — one bounded read of now, next, blocked, since you last looked and people, with its prose on top when a backend is connected.
- Plans as proposals — a reorder, a reassignment, a merge: each lands as a draft with its reason, and a person accepts or declines it. It also narrates QA plans and the final feature board. With no AI backend at all, the engine keeps working.
07
Beside Jira and GitHub
A project that lives in Jira mirrors into vitrinka; a project that does not simply runs here. The commit link is a trailer in the message, written by the CLI, and a merged pull request can complete the task.
- The Jira mirror — per project, with a chosen truth side and a state map. Title, body, labels and state are pushed; title, status and assignee are pulled; priority and comments stay local. Plane is not a mirror yet — today it takes one link-back comment per published set on an issue you name — and Confluence is met by page parity, without a connector.
- Commits and pull requests — the CLI's prepare-commit-msg hook writes a Vitrinka-Task trailer; the GitHub App's push and pull request events attach the commit and the PR to the task, and a built-in rule can complete it on merge.
- Agents as visible workers — a task run starts and stops from the CLI and shows on the task, and picking a task up and handing it back writes its timeline, so a person can see which agent is on what and what it left behind.
08
Where it lives
What backs the promise of a reliable memory, and only that. Hosted or self-hosted, it is one binary.
- One store per workspace — one SQLite store per workspace, nothing pooled between tenants. Evidence uploads are ciphertext before they reach disk, and so are backup files.
- Sealed and appended — connector credentials and keys are sealed; the audit log is append-only, enforced by database triggers.
- The air-gap survives — AIR_GAP keeps the engine and every flow working with AI optional, on your network, with no call leaving it that you did not configure yourself.