Verdict results in the transcript (readable result cards)

What it is

When an agent asks Omniscio's test service (Verdict) to run its tests, the answer comes back into that agent's transcript as an injected message tagged "injected by Verdict". That message is written for the agent, and it reads like it: a ticket, a 40-character tree id, a closure key, a job id, a line of raw JSON, and a [GATE-VERDICT] line. The one fact a person actually wants — did it pass? — has exactly the same visual weight as everything else.

Those arrivals now render as a result card: a headline, the handful of numbers that matter, and the failing files when there are any.

Where to find it

There is nothing to open: a card replaces the raw injected message in place, in the agent's transcript inside the session panel. It appears only when a real Verdict result arrives, so a session that never runs the test service never shows one.

How it behaves

What you see

A card opens with the outcome in plain words and the matching colour:

• Tests passed — green.
• Tests failed — red, followed by how many files failed and which ones, with the first error on each.
• Couldn't run — nothing was checked — orange. Something broke in the infrastructure before the code was ever examined. This deliberately does not look like a failure, because nothing was learned about the code either way.
• No answer — nothing was checked — grey, for the same reason.

Under the headline sits one muted line of context — "89 passed, 0 failed · 12 files · ran on cloud" — and, on a red, the failing files with their per-file detail plus how many of them were already failing on master versus new in this branch. A check that lists what it flagged is compared item by item: an item master never listed counts against the branch only when the branch changed that file; otherwise it is master's own recent problem, and the answer says so by name.

How long it took

A small chip at the right of the headline shows the total time — from the moment the agent asked until the answer was sent back into its session. Hover it for "Total time …".

A thin bar at the bottom of the card shows where that time went, with the exact number for each step underneath:

• queue — waiting for a free cloud machine, plus handing the code over and picking the answer up.
• setup — the cloud machine getting the code ready.
• install — installing the project's packages.
• run — the check itself (typecheck, lint or tests).
• delivery — from the answer being ready to the message being sent: collecting evidence on a red, comparing with master, and the service's own pacing.
• other — any part of the total that none of the steps above covers.

Grey segments are waiting (queue, delivery, and the lighter grey of other); violet segments are the machine working, and the darkest violet is the check itself — so a card that is mostly grey means the time went to waiting, not to your code. Hover any step's name for what it covers — and when a card draws an other step, that explanation is written under the steps as well, because a phone cannot hover and other is the one step whose name does not say what it timed.

Every time on the card is labelled: the run time appears once, as the run step, never as a bare number beside the total.

A step that was not measured is left out, never guessed — but its time is never hidden either:

• A reused result (nothing re-ran) shows only its total. The earlier run's time is not shown beside it, because it is not how long this answer took.
• A local run, a run that was retried, or one whose answer was picked up after the service restarted shows the steps that were measured, and puts the rest of its time under other — the time spent preparing a local copy, a failed attempt, or a wait that cannot be split honestly into a step.
• A run that another agent had already started can list steps that add up to more than its own total, because they began before it asked. That card lists its steps without a bar and says so.

Until 2026-09-27 no card showed a queue step at all: the test service dropped it from every answer, and a card missing any step hid the whole breakdown, leaving the total next to a bare run time. Older messages still carry no queue step; they now show that time under other.

The same numbers ride in the agent's copy as one line — timing: total 141.6s · queue 24.0s · setup 62.4s · install 0.2s · run 51.0s · delivery 4.0s — so an agent can report them too. Older messages already in a transcript have no such line and look exactly as they did.

Two things only appear when they change what the result means:

• A caveat row when the answer is about an older version of the code, or when a merge receipt was not written.
• Next: … when nothing was checked at all — there, the instruction is the whole content. It is not repeated on a pass (the green headline already said it) or on a red (the failing files are right above it).

Every card ends with "Show the original note", which reveals the delivered message byte for byte.

What it does not change

• The agent still reads the original. Nothing about the stored message is rewritten — this is presentation only, in your window. The agent's copy is identical to what it has always been.
• Only a real Verdict result becomes a card. Recognition is the parse itself: an ordinary message from another agent, one you typed, or a future version of the Verdict format renders exactly as it does today.
• Internal ids stay out of the card. The ticket, job id and tree id are one click away in the original rather than on the face of it — they mean nothing to a reader and crowd out what does. A pointer you can actually run (npm run cloud:trace …, an artifact path) is shown on a failure, where you would go looking.

Related

The panel that reports the state of the test service itself is on Verdict panel. How an agent's prose and its tool activity are laid out in the feed, of which these cards are one part, is on Agent message display.