← board

DECIDED 2026-08-01 — option D (never auto-pin) for now

User's call. No auto-pin machinery yet — a human runs make pin, matching current practice. Reasoning: the fact that a naive "all green" rule would never fire (18/16 permanently red jobs, all ticketed/advisory) is itself a sign the baseline isn't stable enough to safely automate against yet. Building the allowlist-plus-guards machinery (option A) on top of an unstable baseline is complexity in the wrong order — clear the ground first (work down the known-red list, close the advisory-vs-real gap), then revisit whether A's criteria are worth automating once "stable enough to pin" is a much shorter, more tractable list. Not rejected, deferred until the baseline justifies the machinery.

decide: what lets Track T pin automatically?

Why this needs you and not a default

make pin moves pinned, which is the ground every other track builds on (B, C, D, E all build with $(PXX_STABLE)). A bad pin does not fail one job — it silently rebases everyone onto a broken compiler. So the cost of pinning too eagerly is asymmetric against pinning too late, and the threshold is a judgment call about that asymmetry, not a fact in the code.

The blocker: "all green" would never fire

The full tier is permanently RED today — 18 jobs on xeon, 16 on borg — and every one is either ticketed or advisory:

A naive "pin when the matrix is green" therefore never pins. Any workable rule needs a notion of known-baseline reds.

Options

A — Baseline allowlist (recommended). Pin when red_set ⊆ known_baseline AND self-host byte-identical AND K consecutive shas qualify. The allowlist is explicit, lives in the repo, and every entry must name its ticket — so it cannot quietly become a dumping ground. A new red blocks pinning; a known one does not. Cost: someone must curate the allowlist. That is the point — it makes "we are shipping with these known breaks" an explicit, reviewable statement.

B — Advisory-flag only. Pin when every non-advisory job is green. Cheaper (testmgr already carries the flag) but pressure lands in the wrong place: it invites marking jobs advisory to unblock a pin, which is exactly how a suite rots.

C — Native-only gate. Pin on native green + self-host byte-identical, ignore the matrix. Fast, and matches "dev does not wait for the gate" — but it pins binaries never validated cross-target, and cross-target reds are most of what Track T exists to catch.

D — Never auto-pin. Track T proposes (files a ticket "sha X qualifies"), a human runs make pin. Safest, keeps a human on the one irreversible-ish step, costs latency.

Recommendation

A, with two guards:

  1. K ≥ 2 consecutive qualifying shas before pinning — one clean matrix can be luck, and today proved the suite has phantom reds (5 unrelated jobs went NEW-RED then FIXED with no capable commit between).
  2. Auto-rollback: if the first matrix after a pin shows a new red, move pinned back and file urgent. Pinning must be as reversible as it is automatic.

Start in shadow mode — Track T logs "would have pinned sha X" for a week without moving anything. Compare against what a human would have blessed. That costs nothing and answers the question with evidence instead of argument.

Also to settle

Notes

Filed per the escalation rule in two-box-protocol.md: an agent that hits a fork it cannot settle files decide-* and moves on rather than guessing. Whichever agent has the user in front of it should surface this.