feat: flag a required check that another workflow produces on push

[CameronBrooks11]

The DUPLICATE rule (#17) reads only a workflow's own push trigger. Suppose workflow A runs check on pull_request, and workflow B runs a job also named check on push with no branch filter. A pull request head then carries check from two suites, and the merge gate takes whichever run it finds (kindspec/rowspec#43). The audit passed that: the issue's reproduction snapshot exits 0 on main.

The rule

push_producers() walks every active workflow in a repository. It keeps the ones whose push admits some branch other than the default, decided by #17's push_duplicates(). For each of their jobs it records the context the job produces:

• name: if present, else the job id;
• for a job that calls a reusable workflow, one <caller> / <called> context per called job, through the same expand() the pull_request side uses.

A job's if: is ignored here: a skipped job still reports its context, which is why CONDITIONAL exists. A case pins this.

For every required context that a pull_request job produces in workflow W, each push producer in a workflow other than W is a finding.

Same kind, DUPLICATE. The hazard, its effect on the merge and the fix (restrict push to the default branch or to tags) are the same as #17's. AGENTS.md §3.2 treats them as one hazard, so a second finding name would split one hazard across two labels. The message names both workflows:

DUPLICATE    kindkit: .github/workflows/check.yml: job 'check' is required, and .github/workflows/push.yml: job 'check' also produces 'check' on push to other branches (push has no branch filter), so a pull request head can carry it from two suites and the merge takes either

No double reporting. W's own push is #17's finding, so the new rule skips producers in W. The existing case on: [push, pull_request] still expects exactly one DUPLICATE. The mutant that drops the self-exclusion is caught there. If W has its own push and another workflow also pushes check, that is two producers and gives two findings. A case pins this too.

Refusals (exit 2), only where they could change the answer:

• B's push filter cannot be settled (for example ['*', '!*'], or any of feat: flag a required check that push also produces on a pr branch #17's refusals, such as ! in branches-ignore or branches: []), and a job in B has the same context. If the job name differs, nothing is refused.
• B's push admits another branch or cannot be settled, and one of its jobs has a context that cannot be resolved: a matrix, an expression or block-scalar name, or a call that cannot be read. That could be any context, so every required pull_request context in another workflow is refused.

A workflow B that cannot be parsed is already refused by the main pass. An inactive B, or one whose push admits only the default branch or only tags, produces nothing.

Red first

The cases are in a new cross list. Five are positive: the same job id, a matching name:, a job with if:, branches-ignore: [main], and a called workflow under push. There is also the own-push-plus-elsewhere pair, and an unrequired context, which stays UNGATED only. The negative controls are:

• push filtered to the default branch only;
• a tags-only push;
• a different job id;
• the same id with a different name:;
• a disabled workflow;
• a called workflow with other job names;
• an undecided filter with a different name;
• an expression name under a default-only push.

The refusals are an expression name, a matrix job, an undecided filter with the same name, and a call that is not in the snapshot.

These were grafted onto main's logic, as #15 and #17 were: main's module up to # --- self-test, then this branch's self-test section.

FAIL push job of the same id in another workflow: got [] exit 0, want ['DUPLICATE'] exit 1
FAIL push job named by name: in another workflow: got [] exit 0, want ['DUPLICATE'] exit 1
FAIL push job with an if: still reports: got [] exit 0, want ['DUPLICATE'] exit 1
FAIL push with branches-ignore in another workflow: got [] exit 0, want ['DUPLICATE'] exit 1
FAIL called workflow under push in another workflow: got [] exit 0, want ['DUPLICATE'] exit 1
FAIL own push and another workflow's push are two findings: got ['DUPLICATE'] exit 1, want ['DUPLICATE', 'DUPLICATE'] exit 1
FAIL push job with an expression name is refused: got [] exit 0, want ['INCOMPLETE'] exit 2
FAIL push matrix job is refused: got [] exit 0, want ['INCOMPLETE'] exit 2
FAIL undecided push filter, same name, is refused: got [] exit 0, want ['INCOMPLETE'] exit 2
FAIL unreadable called workflow under push is refused: got [] exit 0, want ['INCOMPLETE'] exit 2
selftest: 163 of 173 as expected

The other 9 new cases pass on main. They are the negative controls and the UNGATED case, which main gets right because it has no rule. The sweep pins them. At this head:

selftest: 173 of 173 as expected

Mutation sweep

Two changes to scripts/sweep_check_required_checks.py:

• A 30 s timeout per mutant. A mutant that runs past it is counted as hung, which is red but counted apart from caught and crashed. The self-test takes about 0.05 s.
• The target's sha256 is printed before and after. A pattern that matches nothing, or a replacement that leaves the text unchanged, is still BROKEN. I checked this by driving main() with one of each plus one real mutant. It printed BROKEN, BROKEN, caught, and exit 1.

#17 left out the end < 0 mutant on the unclosed-[ check because it loops forever. It is in now, and it comes out hung. The sweep counts it red. No CI here runs the self-test or the sweep; if that mutant shipped, the daily audit would hang on ma[in and fail on its 10-minute job timeout. The ma[in case covers the refusal itself. 13 mutants were added for the new rule:

target sha256 before: 7db249f493b73faf8bcb004c9a60b675a5c267803de6db92cc5245a9eb30ab71
...
hung     unclosed [ accepted
caught   cross-workflow duplicate never reported
caught   own push counted again as another workflow
caught   own undecided push refused again
caught   undecided push refused for any context
caught   unknown-name push job refused only by name
caught   push doubts never refused
caught   inactive workflow pushes
caught   push filter ignored elsewhere
caught   undecided push elsewhere passed
caught   undecided push elsewhere is a finding
caught   push calls not expanded
caught   unknown push job accepted
caught   push producers not collected
target sha256 after:  7db249f493b73faf8bcb004c9a60b675a5c267803de6db92cc5245a9eb30ab71
128 mutants: 127 caught, 0 crashed the self-test, 1 hung past 30s, 0 survived, 0 broken

All other lines are caught. Nothing survived.

ruff format --check and ruff check (kindkit's ruff 0.16.6, line length 100) are clean on scripts/.

Live

$ python3 -I scripts/check_required_checks.py --public-only
1 private repositories skipped (--public-only)
6 repositories, 7 workflows, 7 pull_request jobs, 7 required checks: 0 finding(s), 0 not evaluated
exit 0

The issue's reproduction. I took a --save snapshot from that run and added .github/workflows/push.yml to kindkit, with on: push, a job check with one run: "true" step, and workflow_state active:

$ python3 -I scripts/check_required_checks.py --load snap-push.json
DUPLICATE    kindkit: .github/workflows/check.yml: job 'check' is required, and .github/workflows/push.yml: job 'check' also produces 'check' on push to other branches (push has no branch filter), so a pull request head can carry it from two suites and the merge takes either
6 repositories, 8 workflows, 7 pull_request jobs, 7 required checks: 1 finding(s), 0 not evaluated
exit 1

Main's logic on the same snapshot gives 8 workflows, 7 pull_request jobs, 7 required checks: 0 finding(s), 0 not evaluated and exits 0, which matches the issue.

A called workflow, on the same snapshot. Here push.yml is instead on: push with kind: uses: ./.github/workflows/kind.yml:

DUPLICATE    kindkit: .github/workflows/check.yml: job 'kind' (called job 'conformance') is required, and .github/workflows/push.yml: job 'kind' (called job 'conformance') also produces 'kind / conformance' on push to other branches (push has no branch filter), so a pull request head can carry it from two suites and the merge takes either
6 repositories, 8 workflows, 7 pull_request jobs, 7 required checks: 1 finding(s), 0 not evaluated
exit 1

Docs

• AGENTS.md §3.2. The audit bullet no longer excepts a second producer in a different workflow. The two-producers bullet now says the second producer can be a push job elsewhere, and that a push job whose name the audit cannot resolve is refused.
• README adds "in the same workflow or another" to the audit's description.
• STATE.md:
  • the "still does not see" paragraph is replaced with what the audit now sees;
  • the live figure's heading now names both rules;
  • §6 gains this gap.

Not covered

Two pull_request producers. Two workflows that both run a job named check on pull_request also give a required context two suites. The audit reports nothing for that. I checked by calling evaluate on a two-workflow snapshot, which returned ([], [], ...). That is a separate rule with no issue yet. STATE.md now says so.

Refs #16, #17

Closes #18