Reading a verdict

The run page exists for one moment: you are about to put your name on something. It is ordered the way a careful judge weighs things.

In one breath

At the top, what Constat observed, in a sentence. Four criteria passed every rung Constat could observe. Or no criterion passed every rung, with what is still arriving said plainly, because evidence still coming is not a failure.

The criteria

Each criterion, and how far its evidence actually goes. A criterion can be:

• held — a check was named, it ran, it passed, and it was seen failing first
• passed, but unproven — it passed, but nothing observed makes it load-bearing
• in conflict — something observed contradicts its check proving anything
• yours to confirm — no check was named, so it is a judgement, not a measurement
• nothing observed — Constat could not see anything about it

No column ever says proven. That word belongs to your verdict, not to a measurement.

Beyond the criteria

If the run at the attempt's own commit is red for something no criterion claims, the page names it: the failing check's full name, its first line of error, its file and line. This is the case that used to fool people — every criterion green, and the run red for a reason nobody mentioned.

Whose fault a red run is

Every check run says one of three things, so you never have to open GitHub:

• the code's — a named check failed
• the machine's — the job was killed, ran out of memory, or a runner lost a worker after the tests had passed
• superseded — cancelled while queued because a newer run replaced it

The same check red at the same commit in two runs reads as the code's, and the page says so twice. Once is the machine; twice is the code.

This door

If the door was opened by a look at an earlier attempt, the page says so, names that attempt, and dates when this attempt's own evidence arrived. You should never be judging one attempt with another's evidence in front of you.

The agent's claims

In a column of their own, in the agent's words, never merged with the evidence. An agent that says a criterion is met when CI says otherwise is showing you something useful — about the agent.

Which attempt you are judging

The door you are reading belongs to one attempt, and the verdict you give is sealed against that attempt — not against whichever is newest by the time you press. If a newer attempt appears while the door is open, the page says so before it will take a verdict, so you are never asked about one attempt and recorded as having judged another. An attempt that produced nothing — no branch, no commit — never becomes the attempt a door opens on, because there is nothing there to read.

The reason

The box opens with a draft from what Constat observed: the criteria that held, what is red beyond them, whose fault the red run was. Edit it, replace it, or write your own. Nothing is sealed until you press.

And the buttons follow the facts: Reject first when something is red beyond your criteria, Accept first otherwise, with a sentence saying which and why. Both keep their words. The choice is yours.

What accepting does

Seals the record: the ask, the evidence as it stood, the agent's claim, your decision and your name, for ever. And queues the release.

Refusing seals it too, with your reason, and opens the next attempt.

This run is red. Is it this change's fault?

Not always. Every red check says whose it is: this change, already broken on main, or Constat's machinery. A check that also fails on main was broken before the attempt began. A job that was killed or ran out of memory is the machine's, and running CI again fixes it. Only red that belongs to this change is grounds to refuse.

What does "in conflict" mean for this criterion?

Its check passed, but something Constat saw says the pass does not show the criterion holds. Usually the check also passes on the code as it was before the change, never runs the new lines, or kept passing while CI broke one of those lines on purpose. The criterion may still be met: read which, then judge it yourself.