red: tri red why -- which step each failure died at, and where that changed - #3271
Merged
Conversation
… changed
`tri red now` answers whether a workflow is red. Nothing answered why, or
whether the why had CHANGED.
cli-tri.yml was red on master for nine consecutive runs. I read the failing
step once -- "No two skill sections share a number" -- fixed the collisions,
and expected green. It stayed red: the cause had moved to "No census moved
without saying so", a ratchet that had been correct since my own L8 fix three
passes earlier took a step out of the quiet-shape class without re-blessing.
Reading only the oldest failure hid that the numbering was repaired; reading
only the newest would have hidden that numbering was ever the cause.
`tri red why <workflow>` prints the failing step of each run, oldest first, and
marks the point where it changes. On the real repository it shows eight runs at
the numbering step and then the shift, in one command.
Three details that are not decoration:
- the window is NAMED (`read 10 run(s) of 217 available`), because a page is
not a history and this command exists because I mistook one for the state;
- a green run RESETS the comparison, since two failures separated by a
success are two incidents whatever their steps say;
- a run that fails with no failing step -- a cancelled job, a start-up
failure, a matrix leg that never ran -- says so rather than printing an
empty cell that reads as "nothing failed".
Four mutants killed, two of which needed the CONTROL fixed first.
`failure(x), success, failure(x)` cannot test the reset: with identical steps
either side, resetting and not resetting give the same answer. And the shift
array only feeds a printed marker, so nothing read it until a call-site test
was added -- replacing the call with `vec![false; rows.len()]` had left all 781
tests green.
Refs #3270
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
enabled auto-merge (squash)
September 5, 2026 10:23
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
This was referenced Sep 5, 2026
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-05 10:45:36 UTC
Summary
Seal Status
|
This was referenced Sep 5, 2026
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.
tri red nowanswers whether a workflow is red. Nothing answered why,or whether the why had changed.
The incident this comes from
cli-tri.ymlwas red on master for nine consecutive runs. I read the failingstep once — "No two skill sections share a number" — fixed the collisions in
#3266, and expected green.
It stayed red. The cause had moved to "No census moved without saying so", a
ratchet that had been correct since #3256 three passes earlier, when my own L8
fix took a step out of the quiet-shape class without re-blessing.
Reading only the oldest failure hid that the numbering was repaired. Reading
only the newest would have hidden that numbering was ever the cause.
What it prints
Three details that are not decoration
read 10 run(s) of 217 available. A page is not ahistory, and this command exists precisely because I mistook one reading for
the state.
are two incidents whatever their steps say.
failure, a matrix leg that never ran — prints
(no step reported failure)rather than an empty cell that reads as "nothing failed".
Mutation
Four killed: a success not resetting · the first failure counted as a shift ·
shifts never detected · the call site ignoring the helper.
Two needed the control fixed before they could kill anything.
failure(x), success, failure(x)cannot test the reset — with identical stepseither side, resetting and not resetting give the same answer. It had to become
failure(x), success, failure(y). And the shift array only feeds a printedmarker, so nothing read it until a call-site test was added; replacing the call
with
vec![false; rows.len()]had left all 781 tests green.cargo test -p tri --bin tri: 782 passed, 0 failed.Refs #3270