ci: decide whether drafts may request hosted heavy proof instead of local suites #2939

Part of #2934 (Phase A, task 3). All questions were ruled on 2026-10-25 (see the decision comment); what remains is recording the ruling and filing its implementation tasks. It amends the 2026-10-14 ruling in #1849/#1854.

Context

Changes in the current release are mostly low-level: of 177 squashes since 2026-10-18, 88 touched packages/ui-server and 57 packages/ui-sdk, and changes there need system-wide runtime, native and browser proof. Today an agent has two ways to run that proof:

• Locally. Several agents on one host run long suites concurrently. The host chokes, suites hit their timeouts, and agents skip the checks to proceed. Individual native fixtures take 130–150 s per file on hosted runners (for example scripts/native-proof/hosted-app.test.ts). Overlapping runs in one workspace also serialize on exclusive workspace output access.
• Hosted, through ready-candidate confirmation. Drafts run cheap gates only, and complete affected proof runs only when a PR is marked ready (docs/decisions/ci-utility.md:472-479). Under policy, that requires holding the repository-wide reservation (docs/decisions/ci-utility.md:1237-1246), so it is a final confirmation, not an iteration tool.

Neither scales with agent count. Standard runner minutes are free (docs/decisions/ci-utility.md:3-10), but account runner concurrency is not unlimited (docs/decisions/ci-utility.md:1192).

Questions for the ruling

1. May an agent request the PR's affected heavy categories on a draft head, without the reservation, as feedback that never counts as proof?
2. How is it requested: a workflow_dispatch with the PR number and head SHA, a label event, or a comment? It must bind to one exact head, like the existing request (docs/decisions/ci-utility.md:480).
3. Does local preflight then formally stop running long suites, keeping only check:pr and focused failing-first or mutation receipts?
4. What protects account runner concurrency: a per-PR cap on draft heavy runs, cancellation of a PR's earlier draft heavy run on a new push, or both?
5. Is runner-slot wait recorded as a first-class metric in scripts/ci-timings.ts, so the next ceiling is visible?

A documented "no" closes this issue, with the reason recorded and an alternative for local contention (Phase A task 5) chosen instead.

Out of scope

• Changing what counts as merge evidence: exact-head ready confirmation remains the only proof.
• Implementing the request path; it becomes its own task once ruled.

Acceptance criteria

• docs/decisions/ci-utility.md is amended with the 2026-10-25 decision, naming the Epic: tests give faster feedback with less redundant work #1849/ci: separate fast feedback, final confirmation and parallel endurance suites #1854 text it changes and keeping exact-head ready confirmation as the only proof.
• Implementation tasks are filed and attached to Epic: independent changes land on main concurrently, with only overlapping work serialized #2934 for: the dispatch workflow and request script with the live-head check and the one-per-PR cap, cancellation and red-main refusal; the check:pr, work-issue and testing-guidance changes that limit local long suites to debugging; and runner-slot wait, which is already filed as ci: keep job creation time and report runner-slot wait #2952 under Epic: CI and integration evidence is collected, archived beyond GitHub retention and reported automatically #2948. Each carries complete acceptance criteria.

Verification

The amendment states the runner-concurrency protection and how it is measured.

Contract impact

None.

2026-10-25: all questions ruled by the maintainer; acceptance criteria now cover recording the ruling and filing its implementation tasks.