Repository navigation
A streak counts; it does not date — and I reported a repaired outage as live - #3190
Merged
Merged
Conversation
… instant (#3176) tri red now listed `Auto Merge Ready PRs` at 260+ in a row and I put that on the dashboard as a live finding one pass ago. It was settled. Its whole history: 1541 runs, every one a failure, never a success. The cause was not the gate's logic -- the workflow file had not parsed since 2026-07-07, so GitHub could not read its `on:` block and made a failed run on every push. #2256 repaired the parse on 2026-08-20; of the 96 runs after that date, 95 came from one stale branch and 1 from another, and ZERO from master. Dormant since 2026-08-28. The tell was in the data all along: 1541 runs recorded as event=push, from a file whose `on:` block has never in five commits contained push. The command could not have known, and that is the defect: it reports the LATEST run, which is the newest that exists rather than a recent one. Every row now carries the instant of its latest run, from the same single request that already asked for the verdict. Only one of eleven rows was failing NOW; Issue Gate's newest run is five months old. Mutation: dropping created_at from the request turns the structural test red. Also the sweep that produced this. 45 lines read a commit message, branch or PR title; 3 compare against a literal; 1 was a defect. gates.rs reads prose because the GATE reads prose and labels the row PROXY -- not a defect, and it says so. rule_observance's `w699-` prefix matches 0 of 40 merged PRs, but the command already prints that zero and names the clause as enforced by nothing: the rule is dead, not the practice, and resolving it owns to LOOP-RULES.md. Census moved and is re-blessed here. 671 crate tests pass. SKILL.md 532-533. Refs #3176 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
gHashTag
added a commit
that referenced
this pull request
Sep 4, 2026
… are 11, and 3 are live (#3192) * fix(tri): red now counts incidents, not workflow files Six loop passes carried "50 red workflows in gHashTag/trinity-fpga" as outstanding work. #3190 gave every row a date; re-running against that repository answers the item, and the answer is not 50. 405 active workflows, 50 red on the default branch, 11 distinct latest-run instants, 3 of them inside a week. 39 of the 50 are four batches from one afternoon of 2026-07-09/10: files generated together, run once on the commit that added them, failed, never triggered since. FPGA HSLM Bitstream has one run in its entire history, 139 days old. The count was right and its unit was wrong. 50 counts FILES; a reader of "50 red" takes away 50 PROBLEMS. The tell was in the next column all along -- 47 of the 50 rows read `1 in a row`, and a one-long streak is a single event, not an outage. - sort by latest-run instant, not streak length. The old order put a July fossil with 30+ failures ABOVE a live 3. - headline states the split: "50 ... -- 3 of them in the last 7 days". - a divider names the fossils' batch structure, not their file count. - STALE_AFTER_DAYS = 7 is printed. Nagios freshness_threshold and the Prometheus staleness delta both make the threshold a stated number; a policy that is not stated is a policy that is not reviewable. Grouping to the printed minute can split one push across a minute boundary and so over-count batches. That direction never merges two events into one, so the incident count is never understated. Census re-blessed in this commit: fetches red.rs:159 -> 160, a line shift from the added chrono import. No fetch was added or removed. SKILL 534 (the unit of the count) and 535 (pass 86 fixed pagination in the tool; on 2026-09-05 I asked the same question in a raw shell probe and reproduced the defect inside 24 hours, as a false NOT REGISTERED). Refs #3191 * docs: the streak count was 43, not 47 -- two populations, one number The previous commit's message, this PR's body, issue #3191 and the dashboard all said "47 of the 50 rows read `1 in a row`". Counted: 43. 47 is how many rows are DORMANT (last run over seven days ago). 43 is how many read `1 in a row`. The sets are nested, not equal: all 43 one-streak rows are dormant, and the other four dormant rows carry real streaks of 2, 3, 5 and 13 -- Decode RTL exhaustive verification among them, the one genuine regression in the list (66 runs, 49 successes, then 13 consecutive failures ending 2026-08-01). 43 + 4 = 47 dormant, plus 3 live = 50. I reached for a number already on the page instead of counting the thing I had just named, in the section whose whole subject is a count answering a different question than the one it is put to. The earlier commit message cannot be corrected without a force-push, which is forbidden, so this commit is the correction of record. Refs #3191 * docs: 44 of the 50 never succeeded once; "one genuine regression" was six The previous commit called Decode RTL exhaustive verification "the one genuine regression in the list". That rested on looking up exactly one workflow. Looking up all fifty: 1 run ever, never a success ................ 42 2-5 runs, never a success .................. 2 succeeded, then regressed, now dormant ..... 3 succeeded, then regressed, LIVE ............ 3 44 of the 50 have never had a single successful run in their whole recorded history. A check that never once passed is not a broken check; it is an unfinished file. The regressions number six, three of them live: S3AI Brain CI (2654 runs / 1570 successes), Orphaned artefacts (1241/264), Withdrawn numbers (1256/682); dormant Decode RTL (66/49), TRI-NET Baud Ladder (3/2), TRI-NET Node v2 (8/4). Also now measured rather than inferred: all 39 of the July batch have exactly one run in their entire history and none has ever succeeded. That sentence was in the previous commit as a generalisation from one sample; it happens to hold, and now it is counted. Two wrong claims in one change, both from generalising a single lookup, and the second was found only because the first prompted me to check its neighbours. Neither was reachable by a test. Refs #3191 * docs(now): 2026-09-05 entry for the tri red incident-count change The check-now-freshness gate refused this PR because it added no docs/now/ entry. It was right: I had not written one. Refs #3191
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I put a settled outage on the dashboard as the pass's largest live finding
tri red nowlistedAuto Merge Ready PRsat 260+ in a row, no pass on record. It was settled.Its whole history: 1541 runs, every one a failure, never a success. The cause was not the gate's logic —
.github/workflows/auto-merge-ready-prs.ymlhad not parsed since 2026-07-07 (yaml.safe_loadfails at line 62), so GitHub could not read itson:block and created a failed run on every push. #2256 repaired the parse on 2026-08-20. Of the 96 runs after that date, 95 came from one stale branch and 1 from another; zero came from master. Dormant since 2026-08-28.The tell was in the data the whole time: 1541 runs recorded as
event: push, from a file whoseon:block has never in five commits containedpush. A workflow firing on an event it does not declare is not a puzzle to reason about — it is a file the parser could not read.The command could not have known, and that is the defect
It reports the LATEST run — the newest that exists, not a recent one. Every row now carries the instant of its latest run, from the same single request that already asked for the verdict. It cost nothing and reclassifies the list on sight:
Only one of eleven rows was failing now. The other ten are history that reads like news, in a command whose closing line asks you to read it before merging.
This is the "repaired defect reported as live" shape already in
SKILL.md— committed by me, one pass later, from this command's own output, because the output had a count and no date and I did not ask for one. When a number says HOW MANY, ask what it says about WHEN.The sweep that produced it: 3 candidates, 1 defect
#3189 left "sweep for other matchers reading human-written strings". Run: 45 lines read a commit message, branch name or PR title; 3 compare one against a literal. The class is not "reads prose" — it is "reads prose where a structural property decides the same question":
gates.rs:4630reads commit messages against a pattern extracted fromissue-gate.ymlitself, and labels the rowPROXYsaying the gate does not read them. It reads prose because the gate reads prose. Not a defect — and it already says so.rule_observance.py:125matchesheadRefName.startswith("w699-"): 0 of 40 merged PRs comply; live prefixes arew(24) andloop(19). But the command already prints that zero and names the clause as enforced by nothing. The rule is dead, not the practice, and resolving it belongs to whoever ownsLOOP-RULES.md.auto-merge-ready-prs.ymlreads a PR title — and turned out to be the finding above.A sweep finding one defect in three has still earned itself: the two non-defects are recorded as non-defects with the reason, so the next pass will not re-open them.
Mutation: dropping
created_atfrom the request turns the structural test red. Census moved and is re-blessed in the same commit. 671 crate tests pass.SKILL.md532–533.Refs #3176