An agent worked on this branch overnight and everything says done. Is any of it checked?

Not the backlog, and not the repository's prose. ready is the work nothing is currently blocking, and it prints the paths each item touches. That footprint is what a ticket never tells you: two ready items over the same file is a collision you can see before you make it rather than at merge.

$ vrek ready
○ iss-3qhhg79  register writes an absolute VREK_DIR into .mcp.json
touches src/cli/main.ts, test/cli.setup.test.ts
○ iss-jpkfjf6  Relation lists come back sorted by target id
touches src/core/workspace.ts

limit: 5

{ "items": [
    { "node": { "id": "iss-3qhhg79", "title": "register writes an absolute VREK_DIR…" },
      "touches": ["src/cli/main.ts", "test/cli.setup.test.ts"] },
    { "node": { "id": "iss-jpkfjf6", "title": "Relation lists come back sorted by target id" },
      "touches": ["src/core/workspace.ts"], "tags": ["area:surfaces", "type:bug"] }
  ], "total": 62 }

You are not the only one with a shell on this workspace. in_progress lands in the same log the agent reads on its next ready, so it stops being something you mentioned in a chat window. Name yourself once and every event you append carries you.

# saved to .vrek/.actor; you are asked once, not per command
$ vrek whoami mike
$ vrek status iss-jpkfjf6 in_progress

# who touched this, in order, with nothing anonymous
$ vrek log --subject iss-jpkfjf6 --order oldest

id: "iss-jpkfjf6"
status: "in_progress"

{ "id": "iss-jpkfjf6", "status": "in_progress" }

subject: "iss-jpkfjf6"
order: "oldest"

issue.created    mike    2026-09-02
node.tagged      mike    2026-09-02  area:surfaces, type:bug
status.changed   claude  2026-09-17  open → in_progress

The expensive mistake is rarely the wrong answer. It is the quiet one — a lane picked at 2am, discovered in review three days later, by which time it is load-bearing. --blocks takes the work out of the ready set until a human answers, so neither you nor your agent can proceed on a guess without noticing that is what you are doing.

$ vrek ask "Sort relation lists by what?" \
$     --option "created_at|reads as the order things happened" \
$     --option "title|stable, but unrelated to the work" \
$     --blocks iss-jpkfjf6 --owner mike

# and it is gone from ready until somebody answers
$ vrek ready

question: "Sort relation lists by what?"
options: [{ option: "created_at", consequence: "reads as the order things happened" },
           { option: "title", consequence: "stable, but unrelated to the work" }]
blocks: ["iss-jpkfjf6"]
owner: "mike"

{ "id": "que-8k3m1qp", "status": "open", "blocks": ["iss-jpkfjf6"] }

status done records that somebody said so. It does not pretend to know. Until evidence is attached, the item sits in unverified, which is exactly the list of everything currently being taken on trust — usually shorter than you would like, and always shorter than the summary suggested.

$ vrek status iss-jpkfjf6 done
$ vrek unverified
● iss-jpkfjf6  Relation lists come back sorted by target id
claimed done by mike, no evidence

id: "iss-jpkfjf6"
status: "done"

{ "id": "iss-jpkfjf6", "status": "done" }

{ "items": [
    { "id": "iss-jpkfjf6", "title": "Relation lists come back sorted by target id",
      "status": "done", "updated_by": "prn-90pbht2" }
  ], "total": 2 }

A verification says who checked it, when, and how someone else would check it again. pending is the honest result for a test that is written but has never been run — never pass. Resolve it afterwards: correcting a result appends a new event naming who corrected it, and the original stays in the log.

$ vrek verify iss-jpkfjf6 "relations come back in created order" \
$     --result pass --evidence "npm test, 916 tests; workspace.test.ts"

# written but never executed is pending, and pending is honest
$ vrek verify iss-jpkfjf6 "the console renders them in that order" \
$     --result pending

issue: "iss-jpkfjf6"
criterion: "relations come back in created order"
result: "pass"
evidence: "npm test, 916 tests; workspace.test.ts"

{ "id": "ver-2k7p1rc", "result": "pass" }

issue: "iss-jpkfjf6"
criterion: "the console renders them in that order"
result: "pending"

{ "id": "ver-9d3xq0m", "result": "pending" }

register writes the .mcp.json that connects an agent over stdio. It gets the ready set, the ask and the verify as tools — the same objects you just used, not a summary of them. What it is told on connect is instructions, which lives in the workspace, so it is one fact for every agent rather than a file each repository drifts on its own.

$ vrek register --model claude-opus-5
wrote .mcp.json — vrek-mcp over stdio, actor claude, kind agent

$ vrek instructions "Start with ready. Ask rather than guess. Verify before you claim."

instructions: "Start with ready. Ask rather than guess. Verify before you claim."

{ "instructions": "Start with ready. Ask rather than guess. Verify…" }