Repository navigation
Eighteen workflows have never succeeded — 8182 runs, zero green #810
Description
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_dispatchonly — 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.
Activity
gHashTag commentedon Sep 11, 2026
Refreshed Trinity-only audit — 2026-09-12
All eleven Trinity workflows from the original list remain active. Current API totals (all outcomes / successful runs):
These totals include skipped runs; they must not be described as an equal number of failures or as a measured amount of wasted compute. In particular, the original zero-success claim no longer holds for
claude.Observed current problems include failing brain health/report jobs, failing KOSCHEI tests, queue-drain JSON parsing (https://github.com/gHashTag/trinity/actions/runs/34626917493), and invalid
dev-enforcementworkflow syntax. Existing PR #786 already addresses the last item and should be reviewed rather than duplicated.The main
ci.ymlalso hides a failingzig build testbehindtee; this is being repaired under #616. Do not use a green summary alone to certify the repository.The nine manual disables recorded in #824 remain in place. Its remaining
fpga-docker.ymldecision is retained here: that workflow is active, has 13 total runs / 4 successes, and its last recorded run is the April 3 failure. Its purpose and current inputs need verification before any disable or re-enable decision.No workflows were changed by this audit. Next acceptance: identify an owner and real artifact for each active workflow, distinguish failure/skipped/unused, land an appropriate fix or deliberate scheduling change, and verify a meaningful run. Cross-repository figures from the original issue have not been refreshed by this Trinity-only audit.