feat(ci): status-needs-fix label clears on the author's push — unaddressed findings become queue-visible (#2815)

[dolho]

Summary

A /review, /validate-pr or merge-train finding is posted as a comment, and a comment never moves reviewDecision — so a PR with an unaddressed CRITICAL was byte-identical, in every field the queue reads, to one nobody had looked at. Three such PRs sat under ✅ Ready and the next train re-validated each at full lane depth to rediscover what was already written on them.

The issue's "cheapest fix that would have worked", built in two halves:

• Label status-needs-fix — created on this repo (D93F0B).
• Skills (trinity-dev#28): the skills that post findings set it; /open-pull-requests sorts it out of Ready; /merge-train Phase 0 shows it as NFIX and Phase 1 drops it without spending Phase 2.
• This PR — the clearing half: the author's next push removes the label, so "a finding is outstanding" needs no human bookkeeping in either direction (AC#3).

needs-fix-clear-on-push.yml

• pull_request: types: [synchronize] — a push to the PR branch. Job-gated on contains(labels.*.name, 'status-needs-fix'), so an unlabelled push spends no runner.
• pull_request, not pull_request_target, for two reasons that are both load-bearing: a _target workflow is registered from the default branch and would be inert on dev until the next release (bug(ci): issue promotion has not run since #2769 — the pull_request_target trigger is inert until it reaches main #2814 — this one has to work the day it lands); and on a same-repo PR the plain token can already write labels.
• The cost is fork PRs: read-only token (ci: issue-status-on-merge cannot relabel issues when the merged PR came from a fork #2767) → core.warning, never a red run; the reviewer clears the label by hand at re-review. Any other refusal is setFailed. A 404 (raced with a manual removal) is not a failure.
• No checkout, no run:, no PR text read — it deletes one label from the PR that emitted the event and nothing else.

tests/unit/test_2815_needs_fix_label_workflow.py

10 static guards in the test_2767 shape: the trigger is synchronize only; it removes exactly this label and never adds one; the job is gated on the label; 403 → warning, 404 → info, else → failed; trigger is pull_request and not _target; no checkout; no run:; no pr.title/pr.body; permissions == {pull-requests: write} only. Also confirmed the #2814 trigger-parity guard accepts this workflow (a pull_request-only on: is out of its scope by design).

Not in this PR

The trinity-enterprise repo has no such label or workflow. /open-pull-requests reads both repos, and an absent label is simply never Blocked-by-label there — the train is public-repo-only. Add both there if enterprise PRs start getting /review-ed at volume.

Test Plan

• cd tests && pytest unit/test_2815_needs_fix_label_workflow.py unit/test_2625_workflow_expression_cap.py unit/test_1891_python_version_parity.py -v — 56 passed
• Label API add/remove verified live on fix(execution): SUB-003 post-switch retry gets the turn's remaining budget, not the 300s reader-race ceiling (#2789) #2817
• After merge: label a PR, push to its branch, confirm the Needs-Fix Label Clears on Push run appears and the label is gone (the pull_request trigger reads the PR ref, so this is verifiable on the first push after merge — unlike bug(ci): issue promotion has not run since #2769 — the pull_request_target trigger is inert until it reaches main #2814's class)

Fixes #2815

🤖 Generated with Claude Code

https://claude.ai/code/session_01VpvcfgWkmQPD7DrDLmATTf

[dolho]

/review — head 025b6703 vs origin/dev (a7acc3dd) — second pass

Files: 2 (+~300) · Scope: CLEAN — one workflow, one guard; the skill half is trinity-dev#28 and the label was created out-of-band.

Critical

None.

Informational

[I1] Any push clears the label — including a reviewer's "Update branch" and the train's own Phase 4 conflict push (Confidence 7/10)
on: pull_request: types: [synchronize] fires for every head change: the author's fix, a reviewer clicking Update branch (a merge commit on the head), and /merge-train Phase 4 pushing a conflict resolution to a member branch. Only the first addresses a finding. The issue's AC#3 says "a push by the author clears the state", and the synchronize payload carries the pusher as sender — so the job can gate on github.event.sender.login == github.event.pull_request.user.login and leave the label alone when someone else touched the branch. Within a train this cannot bite (a NFIX=YES member is dropped in Phase 1 before Phase 4 runs), but the Update branch click is one anyone can make. One expression, one test; pushing it.

[I2] branches: [dev, main] (Confidence 3/10)
Included so a release PR (dev → main) can carry and clear the label too. Harmless; noting that the merge train and both queue views are --base dev only, so on main the label is set by hand or not at all.

Clean

• pull_request, not _target, for two stated reasons (registered-from-main inertness bug(ci): issue promotion has not run since #2769 — the pull_request_target trigger is inert until it reaches main #2814; same-repo token already writes labels) — and the bug(ci): issue promotion has not run since #2769 — the pull_request_target trigger is inert until it reaches main #2814 guard accepts this file (a pull_request-only on: is out of its scope by design; 31/31 with the guard copied in).
• Job-gated on the label (contains(labels.*.name, …)) so an unlabelled push spends no runner.
• Fork PR → core.warning, never red (ci: issue-status-on-merge cannot relabel issues when the merged PR came from a fork #2767's read-only token); 404 → info; anything else → setFailed.
• No checkout, no run:, no pr.title/pr.body; permissions == {pull-requests: write} — each pinned by test_2815_needs_fix_label_workflow.py on the code, comments stripped.
• Label API calls verified live (add + remove on fix(execution): SUB-003 post-switch retry gets the turn's remaining budget, not the 300s reader-race ceiling (#2789) #2817).

Verdict: READY after I1.

[vybe]

merge-train 2026-09-15: validated at lane depth; all checks green on the merged head.