ci: run nine workflows once per PR commit, on every path their push run watched

[gHashTag]

Closes #875. Part of #851.

What changes

Nine workflows, on: blocks only. No job changes.

workflow	push	pull_request paths added
conformance-frame-alignment	every branch → main	its workflow file
gates-can-fail	every branch → main	none (already identical)
reachability-ratchet	every branch → main	its workflow file
rtl-check	every branch → main	its workflow file
tri-build	every branch → main	its workflow file
trinet-portability	every branch → main	its workflow file, conformance/portability_check.py
fpga-regression	unchanged (main, develop)	its workflow file, src/tri/tri_sacred_fpga.zig
conformance-selftest	unchanged (main)	its workflow file
gf-adder-ref-tb	unchanged (main)	its workflow file

Each added path list carries the comment # every push path, so a PR that touches only one of them still runs this.

Why both halves

The first six ran on push to every branch and on pull_request, so a commit to a PR branch started them twice. Narrowing push to main fixes that, but on its own it opens a hole. Five of the six listed their workflow file under push paths only, so the push run on the PR branch was the only one that tested an edit to the workflow itself. The last three already had that hole on main.

Measured

speed doubles (a text classifier over on: blocks, 16 fixtures, in the build-speed loop's tooling) on .github/workflows:

	DOUBLE_ON_PR	PR_BLIND	OK
main 57de4a1	15	3	99/122
this branch	9	0	108/122
this branch + #867 (expected)	0	0	117/122

The nine left on this branch are exactly the nine document gates that #867 changes.

Other checks on this branch:

• Ruby YAML.load_file parses all nine files.
• research/audit_workflow_paths.py --verbose reports 122 workflow files and 0 dead paths entries.
• git merge-tree is clean against main, ci/gates-push-main (ci: run the nine document gates on push to main only #867) and ci/concurrency-groups (ci: give the 102 push workflows a dispatch-safe concurrency group #870).

Not measured

• Runner minutes saved. 351 of 374 non-main push runs in 24 h came from DOUBLE_ON_PR workflows, but that count includes ci: run the nine document gates on push to main only #867's nine, and minutes per run differ.
• The 117/122 figure for the combined tree. It is the sum of two measured branches, not a run on a merged tree.
• Whether anything outside this repo waits for a push-triggered run on a non-main branch.

Left alone

Four workflows push on globbed branches and also run on PRs, so a PR from a matching branch still runs them twice: brain-ci, codegen, fpga-formal and fpga-formal-comb. Whether those branch pushes are wanted without a PR is the owner's call. A repo-level gate for these classes waits for #870 (see #875).

🤖 Generated with Claude Code

[github-actions]

⚠️ FPGA Regression (CONSCIOUS)

• Success Rate: —
• φ⁻¹ Threshold: 61.8%
• Status: NO-METRIC

ℹ️ No FPGA-VERIFY-SUMMARY line — no metric, no percentage (#648)

[github-actions]

⚠️ FPGA Regression (AWARE)

• Success Rate: —
• φ⁻¹ Threshold: 61.8%
• Status: NO-METRIC

ℹ️ No FPGA-VERIFY-SUMMARY line — no metric, no percentage (#648)

[github-actions]

X Brain Health Check

Score: 100.0/100
Status: 🟢 HEALTHY
Threshold: 80/100

X Brain is above merge threshold

[github-actions]

⚠️ FPGA Regression (DORMANT)

• Success Rate: —
• φ⁻¹ Threshold: 61.8%
• Status: NO-METRIC

ℹ️ No FPGA-VERIFY-SUMMARY line — no metric, no percentage (#648)

[github-actions]

⚠️ FPGA Regression (TRANSCENDENT)

• Success Rate: —
• φ⁻¹ Threshold: 61.8%
• Status: NO-METRIC

ℹ️ No FPGA-VERIFY-SUMMARY line — no metric, no percentage (#648)

[github-actions]

🧪 Brain Stress Test Results

Score: not measured (no stress test prints a Score: line)
Status: 🟢 PASS
Threshold: 270/300

X Stress test passed

[tri-claw]

Summary by t27-bees

Worth a look

• .github/workflows/fpga-regression.yml (pull_request block): push triggers on branches: [main, develop] (unchanged), but pull_request only triggers on branches: [main]. A PR targeting develop will not run this workflow, while a direct push to develop will. This asymmetry may leave a coverage gap for develop-targeted PRs.

• .github/workflows/gates-can-fail.yml (push block, lines 38–42): The workflow file (.github/workflows/gates-can-fail.yml) is absent from push.paths (only tools/check_*.py and tools/materialise_siblings.sh are listed). The PR description states pull_request paths are "already identical" to push, so the workflow file is likely missing there too. Edits to this workflow file would not trigger a run on either push or pull request.

• .github/workflows/conformance-selftest.yml and .github/workflows/gf-adder-ref-tb.yml: Push is restricted to main (per description, unchanged), but pull_request has no branches filter (runs on PRs to any branch). A PR to a non-main branch runs the workflow, but a push to that branch does not. This pre-existing asymmetry is noted in the PR but not addressed here.

---

_{Read: 9 files, +27 -2, the whole diff. Head 6545316. Model: openai-compatible/nvidia/nemotron-3-ultra-550b-a55b. Commands: @t27-bees review | summary | help | pause | resume. Free for every repository.}