feat: open a pull request's build gate runs from the pull request

[JacobAtchley]

Seeing whether a pull request's CI gate passed meant leaving boardwalk, or scrolling the project's build list for a run that may have aged off the end of it.

B on an opened pull request reads its policy evaluations, keeps the build validation policies that have produced a run, and opens the build list over those runs: enter reads the failing gate's logs, Q re-runs it, o opens it in the browser.

Policy evaluations rather than a branch search is what makes these the gates rather than whatever happened to build the branch. A gate with no run yet is left out — the whole point is opening the run — and a pull request nothing gates says so on the status line instead of opening an empty list. The policy's own verdict rides along on that status line, because it is not the build's: a rejected gate over a green run means the policy was evaluated against an earlier iteration.

PullRequest.ProjectID comes from repository.project.id, already in both pull request payloads, because the evaluations endpoint addresses a pull request by an artifact id built from the project GUID and will not take its name.

The endpoint is still a preview resource and refuses a plain api-version outright — "The requested version "7.1" of the resource is under preview. The -preview flag must be supplied" — so it gets APIVersion's preview twin, the same arrangement connectionData already needed. That is the second commit; it was caught running the first against a live pull request.

The second Builds instance

This is the first feature that can put two Builds views in one stack — menu, builds, p, then B on the pull request that opened. TestListViewsAreConstructedOnlyByRootBuild guards the invariant that makes the unowned ErrMsg broadcast safe, and rather than weaken it, the gate list stops depending on it:

• it fetches through gateRunsMsg, which names its pull request
• it ignores buildsMsg, the project listing, and the project list ignores gate runs
• it reports its own failures on that message rather than emitting an ErrMsg with no owner to route on

The guard test is narrowed to that one exemption, with the reason written into its doc comment. Cross-talk in both directions is covered by tests.

Verification

make vet test green. Run against a live pull request, four gates:

!11924 project="b01072b5-…"
  ct-platform-shared-ci         approved  build=41117 20260921.1 succeeded
  ct-platform-item-catalog-ci   approved  build=41118 20260921.1 succeeded
  ct-platform-wms-ci            approved  build=41119 20260921.1 succeeded
  ct-platform-core-ci           approved  build=41120 20260921.1 succeeded

Follow-up, not in this change

The evaluation context also carries buildIsNotCurrent, which marks a gate whose run predates the latest push. Surfacing it would stop a green gate on stale code from reading as passing.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EnkNZwrGWfCeQDsHVkvPuE