A guided track · Product owner

I was told six things shipped. Which of them has anything behind it, and what is waiting on me?

You do not need a burndown chart. You need to know which of the things you were told were finished have evidence behind them, which questions are sitting on your desk holding up work that nobody has mentioned again, and which of your goals is moving in the wrong direction.

All four are one command each, and none of them are a report somebody assembled for you. They are queries over the same records the people and agents doing the work write to as they work — so there is no version of this that is up to date for them and stale for you.

Every step is one move, on three surfaces: the shell, a chat client over MCP, and the browser console vrek-api serves. Pick whichever you would actually touch — the choice holds for the rest of the track. Where a surface genuinely cannot do a step, it says so rather than pretending.

Read the whole state in one command

report is the stakeholder surface. It separates shipped-and-verified from claimed-with-no-evidence, and it puts what is blocked on a human at the top where it belongs, because that is the only category you can personally clear. Nobody assembles it; it is the workspace, sorted.

On the command line

vrek report

$ vrek report
shipped, verified (194)
in progress (2)
blocked on a human (7)
○ que-7fj2r9y  Is the email in the log's history rewritten out?
holds up ○ Share the repository beyond its maintainer (iss-dpea1gn)
claimed done, no evidence (2)
deferred (3)
ready to pick up (62)

In Claude, or any client that speaks MCP

asking for it in a sentence vrek over MCP

you

Where is this project, honestly?

vrek_report tool call

{ "verified": { "total": 194 }, "in_progress": { "total": 2 },
  "pending": { "total": 7 }, "unverified": { "total": 2 },
  "deferred": { "total": 3 }, "ready": { "total": 62 } }

claude

194 done with evidence behind them, 2 done on somebody's word alone, 2 in progress. Seven questions are waiting on a human — those are the only ones you can clear yourself, and they are holding up nine items. Shall I read you the seven?

In the console

the same seven sections, as a page vrek-api

vrek console #/ live

Waiting on a human

7 of 7

Is the email in the log's history rewritten out? holds up: Share the repository beyond its maintainer
Where does an idea live before it is work? holds up 2 · raised 6 days ago

see all 7

Clear what is blocked on you

A question here is an object with options, and each option carries what it costs — written down by whoever raised it, at the moment they had the context. You are not being asked to remember why it matters. Answering releases the work that was waiting, in the same event.

On the command line

the desk, oldest first

$ vrek inbox --owner mike
○ que-v9wcr5t  Where does an idea live before it is work?
a question · an issue with a stage:idea tag · a new idea kind
holds up 2 items · raised 6 days ago

$ vrek answer que-v9wcr5t "A question, until it has a shape worth scheduling"
answered; 2 items return to the ready set

In Claude, or any client that speaks MCP

answering out loud, and having it recorded vrek over MCP

you

What is waiting on me?

vrek_inbox tool call

owner: "mike"

{ "questions": { "items": [
    { "id": "que-v9wcr5t", "title": "Where does an idea live before it is work?",
      "options": [{ "option": "a question", "consequence": "…" },
                  { "option": "an issue with a stage:idea tag", "consequence": "…" }],
      "blocks": 2, "age_days": 6 } ] } }

you

A question, until it has a shape worth scheduling.

vrek_answer tool call

id: "que-v9wcr5t"
answer: "A question, until it has a shape worth scheduling"

{ "id": "que-v9wcr5t", "status": "answered", "released": 2 }

claude

Recorded as yours, not mine, and the two items it was holding up are back in the ready set. The next agent that calls vrek_ready sees them without anyone forwarding this conversation.

In the console

the one write the console is built for vrek-api

vrek console #/node/que-v9wcr5t live

Options, and what changes under each

a question stays in the inbox until it has a shape worth scheduling
an issue with a stage:idea tag enters the ready set, and competes with real work
a new idea kind a tenth node kind, and every surface learns it

Answer it

See what is being taken on trust

This is the list the product is built around. Done means somebody said so. Verified means somebody checked, and recorded how you would check it again. The gap between the two is not a failure — it is the normal state of in-flight work — but it should be visible to you without asking anybody how confident they are.

On the command line

claimed done, no evidence

$ vrek unverified
● iss-x3m5kc7  Drift from event seq, and acknowledgement as one action
failing ✗ drift over a path footprint is evaluable at all
● iss-txyswdj  The console's node page has no section for what a node blocks
pending … a node's page shows a 'Holds up' section

In Claude, or any client that speaks MCP

the question an agent cannot flatter vrek over MCP

you

You told me six things shipped. Which of them is actually checked?

vrek_unverified tool call

{ "items": [
    { "id": "iss-x3m5kc7", "title": "Drift from event seq, and acknowledgement as one action" },
    { "id": "iss-txyswdj", "title": "The console has no section for what a node blocks" }
  ], "total": 2 }

vrek_show tool call

id: "iss-x3m5kc7"

{ "status": "done",
  "evidence": { "verified": false,
    "failing": ["drift over a path footprint is evaluable at all"] } }

claude

Four of the six have passing checks recorded against them. Of the other two, one has a check that is failing and one has a check nobody has run. I cannot answer this one out of my own memory of the session — the tool reads what is recorded, which is the point of it.

In the console

amber, and only ever amber vrek-api

vrek console #/ live

Claimed without evidence

2 of 2

Drift from event seq, and acknowledgement as one action ✗ failing: drift over a path footprint is evaluable at all
The console's node page has no section for what a node blocks … pending: a node's page shows a 'Holds up' section

Cut it by the thing you care about

Tags are free-form and faceted — client:acme, area:billing, horizon:now. report --by client regroups the same state by whichever facet you are being asked about this week, so a client meeting and a team standup read the same records without anyone maintaining two views of them.

On the command line

one workspace, the slice you need

$ vrek tag iss-jpkfjf6 client:acme area:ui
$ vrek tags --prefix client
client:acme 14 · client:borealis 9 · client:internal 41

$ vrek report --by client

In Claude, or any client that speaks MCP

the slice, without learning the flag vrek over MCP

you

Just Acme's, before the call at two.

vrek_report tool call

by: "client"

{ "facet": "client", "prefix": "client:", "groups": [
    { "tag": "client:acme", "counts": { "open": 14, "done": 32 }, "total": 46 },
    { "tag": "client:borealis", "counts": { "open": 9, "done": 18 }, "total": 27 } ] }

claude

Acme: 46 items, 32 of them done and 14 still open, and two questions waiting on a human — both yours. One of the 32 has no check recorded against it, the billing export; everything else in that group has evidence behind it.

In the console

the facets, as chips vrek-api

vrek console #/tags?by=client live

Issues by facet

client · area · horizon · type

client:acme 14 open · 31 verified · 1 claimed without evidence
client:borealis 9 open · 18 verified
client:internal 41 open

Put a number on a goal, then watch it

A goal is a node work can point at, with a target, a direction and a unit. A measurement is a number observed on a date. goals lists them worst-first — the one furthest from its target, not the one most recently discussed — and every issue can say which goal it serves, or which it sets back.

On the command line

goals, worst first

$ vrek goal "Time from clone to first useful command" \
$     --target 5 --direction down --unit minutes

$ vrek measure "clone to first ready" --value 11 --goal gol-9wbe2ch --at 2026-09-16
$ vrek goals
gol-9wbe2ch  11 minutes → target 5, down · 3 issues serving, 1 against

In Claude, or any client that speaks MCP

a reading, recorded where the target is vrek over MCP

you

I timed a fresh clone this morning: eleven minutes to a first useful command.

vrek_measure tool call

title: "clone to first ready"
value: 11
measures: ["gol-9wbe2ch"]
applies_at: "2026-09-16"

{ "id": "mea-1c8ptr4", "value": 11, "goal": "gol-9wbe2ch" }

vrek_goals tool call

{ "items": [
    { "goal": { "id": "gol-9wbe2ch", "title": "Time from clone to first useful command" },
      "state": "behind", "target": 5, "direction": "down", "value": 11 }
  ], "total": 4 }

claude

Behind: 11 against a target of 5, and it is meant to go down. Three open issues serve it and one works against it — the one that adds a build step. That trade is recorded, so it is a choice rather than a surprise.

In the console

worst first, and a reading you can add here vrek-api

vrek console #/goals live

behind

1 of 4

Time from clone to first useful command 11 minutes → target 5, down · 3 serving · 1 against

Record a reading

Or do none of this in a terminal

vrek-api serves a browser console from the same process as the API. It is the same records — the report, the inbox, a page per node with its evidence and everything it holds up — with a sign-in rather than a shell. Somebody on the team runs it once; the link is the deliverable.

On the command line

the same facts, in a browser

# run by whoever runs your infrastructure, once
$ vrek-api --workspace /srv/vrek
console at https://vrek.example.com — sign in with your token

In Claude, or any client that speaks MCP

or in the window you already have open vrek over MCP

you

I do not want a terminal or a tab. Just tell me what changed since Friday.

vrek_history tool call

order: "newest"
limit: 40

verification.recorded  claude  pass     iss-3qhhg79
question.answered      mike             que-v9wcr5t
status.changed         claude  done     iss-jpkfjf6

claude

Three things: one check passed, one question you answered released two items, and one issue went to done — that last one has no evidence against it yet, so I would not count it.

In the console

what somebody runs once vrek-api

vrek console #/ live

What the work is for

4 of 4

Time from clone to first useful command behind · 11 → 5 minutes
Share the repository beyond its maintainer unmeasured

Goals

Nobody writes you a status update

Every number on this page is a query over the records that people and agents append as they work. There is no weekly assembly step, so there is no version of the truth that is fresher in someone's head than in here.

Deferred work comes back on its own

Something put off carries a wake date and the reason, or the id of the decision that put it down. When the date arrives it returns to the ready set. Nothing is quietly dropped by being forgotten.

Install it What it is, in general

Developer Because the loop the other side of your team is running is four commands, and it is worth seeing once. /for/developer →