Eighteen active workflows across three repositories have never succeeded
once. Between them they have consumed 8182 runs and produced zero green
results.
| repo |
workflow |
runs |
successes |
| trinity |
S³AI Brain CI — "Functional MRI" Gate |
1705 |
0 |
| trinity-fpga |
queen-bot · PR auto-merger |
1541 |
0 |
| t27 |
auto-merge-ready-prs.yml |
1224 |
0 |
| trinity |
Agent Complete — Destroy + Drain |
565 |
0 |
| trinity |
KOSCHEI Production Deploy |
475 |
0 |
| trinity |
docs-check |
454 |
0 |
| trinity-fpga |
FPGA CI |
330 |
0 |
| trinity-fpga |
🧠 FPGA Consciousness Regression |
328 |
0 |
| trinity |
CI Runner |
251 |
0 |
| trinity |
Spec Audit |
247 |
0 |
| trinity |
Claude Code |
238 |
0 |
| trinity |
Trinity Agent Decompose |
207 |
0 |
| t27 |
Coq kernel |
166 |
0 |
| trinity |
Terminal Demo GIFs |
163 |
0 |
| t27 |
OpenSSF Scorecard |
125 |
0 |
| trinity |
🧠 FPGA Consciousness Regression |
57 |
0 |
| trinity |
Trinity Nexus Build |
56 |
0 |
| t27 |
Coq Proofs Validation |
50 |
0 |
Measured with, for each active workflow:
gh api "repos/OWNER/REPO/actions/workflows/<id>/runs?per_page=1" --jq .total_count
gh api "repos/OWNER/REPO/actions/workflows/<id>/runs?status=success&per_page=1" --jq .total_count
Only workflows with at least 50 lifetime runs are listed, so none of these is
new or rarely triggered.
Why this matters more than any one of them
A gate that has never been green carries no information: it is red before your
change and red after it, so nobody reads it, and after a while nobody reads the
others either. That is not a hypothesis here — it is the measured cause of
the nine defects found in verify-request.yml this week, in a path that had
run once in its life and produced a report telling a stranger their clean
design had a silicon bug.
Eight thousand red runs is also the training set for ignoring red runs.
What to decide, per workflow
Three outcomes, and each is fine:
- Fix it — it guards something real and is simply broken.
workflow_dispatch only — it is useful occasionally and should not run
on every push.
- Delete it — it guards nothing anybody acts on.
What is not fine is the current state, where the answer is "leave it red" and
the cost is paid by every other gate in the repository.
I am not making that call unilaterally across eighteen workflows in three
repositories; it needs the owner. This issue is the measurement.
Eighteen active workflows across three repositories have never succeeded
once. Between them they have consumed 8182 runs and produced zero green
results.
Measured with, for each active workflow:
Only workflows with at least 50 lifetime runs are listed, so none of these is
new or rarely triggered.
Why this matters more than any one of them
A gate that has never been green carries no information: it is red before your
change and red after it, so nobody reads it, and after a while nobody reads the
others either. That is not a hypothesis here — it is the measured cause of
the nine defects found in
verify-request.ymlthis week, in a path that hadrun once in its life and produced a report telling a stranger their clean
design had a silicon bug.
Eight thousand red runs is also the training set for ignoring red runs.
What to decide, per workflow
Three outcomes, and each is fine:
workflow_dispatchonly — it is useful occasionally and should not runon every push.
What is not fine is the current state, where the answer is "leave it red" and
the cost is paid by every other gate in the repository.
I am not making that call unilaterally across eighteen workflows in three
repositories; it needs the owner. This issue is the measurement.