--- title: Verdict results in the transcript (readable result cards) --- # 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](verdict-panel.md). 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](agent-message-display.md).