[TheGreatAxios]

Closes CL-11520

Why
In a workspace on the new manager path, a pull request's verdict was posted but never recorded, so the portal showed nothing for it and the reconciler kept mailing the head again as "run never started". Approving a held action from such a verdict had nowhere to read it from.

What changed

• When a manager's pass is done, it tells the hub what it did: the verdict it actually posted (the machine verdict, or the judge's verdict as reported, stored on its head), a head it held for CI, and the outcomes of approved held actions. It sends only the facts and reasons the verdict keeps, never the diff.
• The hub records that verdict as the manager run's in the same database transaction as done, using the row-building code pr-triage's run logs use (moved to verdict-row.ts, which reads no run log). A run's newest verdict on a pull request replaces its earlier one and keeps the outcomes of actions already written on that head. The verdict's start is when the run first took that head, and its trigger is the newest mail for that head.
• A Bitbucket Data Center manager's verdict is shown as Bitbucket's: the host comes from the workflow id the deployment was launched as, read through the same expression the deployment lookup uses.
• The reconciler and Triage again read the managers of the pull requests they look at:
  • A head with a manager up counts as running, so it is not mailed again.
  • A manager that went away with a pass open counts as failed on that head, which is retried with backoff.
  • A head whose last pass waited for CI waits for its CI.
  • A recorded verdict settles its head.
  • Triage again can queue a head again as soon as its manager reported done, or went away, since it was queued.
• Approving a held action from a manager's verdict reads it from the recorded verdict and the mirror request the pass kept, and sends it to the listener. Only the newest pass of a run on a head keeps that request. An action the run's newer verdict no longer holds answers "A newer triage result exists."
• In the manager, the approvals step runs on every pass, and a posted verdict and a held head each report through their own done step.
• How a skipped step looks, from Interchange's runtime (vendor/interchange/packages/workflow/src/runtime/run.ts, used by live runs through workflow-host's run-child.ts and by runLocal alike):
  • Within a pass, selectors see a skipped step as missing. The runtime keeps in memory only the outputs of steps that ran, so a selector that names a skipped step fails.
  • The skip is still written to the log as a completed step whose output is { skipped: true, gateId, branch } (emitSkipClosure). The loop's while/carry read each pass's outputs back from that log (hydrateChildOutputs), so they see that marker for every done the pass skipped.
  • The old loop check read done first and so picked up its marker whenever the judge's or the code review's done ran, and never started another pass on their more. It now takes the first done that isn't marked skipped.
  • This comes from reading the code, not from reproducing it on a live run.
• docs/ARCHITECTURE.md describes this. The user manual needs no change: it already describes verdicts, approvals and Triage again as people see them on this path now.

Verified

• bun run check, bun run lint (no new warnings) and the policy check against origin/main, which is clean.
• New tests:
  • The hub records a done's verdict on both hosts, in done's transaction. The run's next verdict replaces it while keeping its start on the head, the head's newest mail and an action already written on that head. Approvals set their outcomes, and a held head records nothing.
  • The reconciler mails a head once while its manager runs for seven hours, then settles it when the verdict lands. A head the manager held for CI waits.
  • A manager that went away mid-pass fails its head.
  • Triage again counts a live manager as running, and lets the head be queued again after the manager reported done or went away.
  • An Inbox approval of a manager's verdict reaches the listener, and answers "superseded" once the run's newer verdict replaced it.
  • The manager's done carries the posted verdict (the machine verdict, the judge's as reported, and the stored judge verdict), a held head and the approvals, with only reasons and kept facts.
  • A pass that mailed its judge and answers more runs a second pass.
• Each new hub test fails against the code before this change.
• Test runs: the hub, triage-manager and triage-contracts suites after rebasing on main with fix(hub): log a code review request dropped because the head moved #632, fix(manager): exit a cancelled listener or manager promptly #633 and fix(manager): post the judge's verdict as the judge reported it #635, 786 pass, 0 fail.

[linear-code]

CL-11520

[corbits-triage]

Triage: Unsure

Waiting on:

• checks are still running: check

Some rules could not run this time. Triage will re-check this pull request.