Repository navigation
fix(t27b): regenerate steward.c so is_pass knows pass_ct; the ledger test asks is_pass (Refs #12751) - #13097
Merged
Conversation
…test asks is_pass (Refs #12751) Two parts, both needed. 1. gen/c/tri/t27b/steward.c was not regenerated when #12792 (37ca933) added `if (v == 12) { return true; }` (pass_ct) to is_pass in specs/tri/t27b/steward.t27. scripts/tri_loop/t27b_rules.py compiles and calls this C, so every consumer read is_pass(pass_ct) = false. Regenerated with: t27c gen-c specs/tri/t27b/steward.t27 > gen/c/tri/t27b/steward.c The output hashes d1941f3b..., the gen_hash_c already recorded in .trinity/seals/t27b_T27bSteward.json (spec_hash 8fa40d90... unchanged), so the seal is not re-saved. No hand edit of the generated file. 2. scripts/ci/test_a_t27b_spec_cannot_move_silently.py kept its own success list ("pass", "pass_vacuous") for the blocker-and-reason check, so the five pass_ct rows of the committed ledger (blocker "", as bless writes them) failed it. The check now skips the rows the spec's is_pass counts as a pass, read through t27b_rules. The cap check is unchanged: it still counts by the tuple, as bless (ledger_counts) does, 140 == 140. Foreign lines: +3 / -3 (net zero; the text/real lines are merged to pay for the import line). Controls (python3 3.14.6, one test file): regen C + patched test, real ledger all ok, rc 0 neg: blocked row with blocker "" FAIL blocker line, rc 1 neg: pass_ct row -> blocked, blocker "" FAIL blocker line, rc 1 stale C + patched test FAIL blocker line, rc 1 regen C + original test FAIL blocker line, rc 1 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gHashTag
added
the
no-auto-merge
Contributor
gHashTag
added a commit
that referenced
this pull request
Nov 2, 2026
…d elsewhere (Refs #12877) Head 59a386a leaves one red of four: loop-tools-tracked (run 41415969492, job 125179777508). Three checks say it is not this branch's, and section 12c records each with the command that reads it: the branch touches neither docs/reports/t27b_expectations.json nor scripts/tri_loop/ -- the diff against the merge-base prints nothing; loop-tools-gate is `failure` on master's last four runs, back to 2026-10-27; it runs on master only when its own paths move, so 10-31 is the newest; the repair is green in its own lane: on PR #13097 the same check PASSES, run 41403967388, job 125141715680. So the case is diagnosed and fixed where it belongs, and a copy of that fix here would be a second home for one truth. One number corrected while it is cheap: the dashboard bot's comment reads "30 failing / 37 total" for this PR. Counted at that same head, the check-runs API gives 4 failure, 29 success, 4 cancelled, 4 skipped -- 41 runs, 4 red. The bot sampled a run that had barely started; the direct count is what 12b uses. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Nov 2, 2026
…r's (Refs #12877) Section 12c was written while two checks were still running and reported one red where the finished set is four. Section 12d corrects it, and the correction runs one way only: with everything finished, none of the four belongs to this branch. Each is quoted from master's own words rather than asserted: type names ledger 141, observed 142, + ParsedCommand NEW conflict -- the same two lines master's own run prints; coverage one stale seal, policy_PolicyOwnLanguage.json, named in master's failure too; spec-guards the same seal, all four gen_hashes with sealed vs current; loop-tools unchanged from 12c, and green in #13097. Two facts close it. The Cell rename held: the ratchet observed 143 names with Cell in the tree and observes 142 now, listing only ParsedCommand, which is #13059/#13087's -- the arithmetic matches master. And the seal is out of reach from here: the diff against the merge-base over specs/policy/ and .trinity/seals/ prints nothing, so this branch changed neither the spec nor any seal, and its repair already exists as PR #13096. The two review comments in the same event are the dashboard bot's PR-level comments, with no inline thread and nothing asked of this branch, so nothing was replied to. Their counts (30 of 34, then 28 of 33, four minutes apart) are two more mid-run snapshots of the kind 12c already corrected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Nov 2, 2026
This was referenced Nov 9, 2026
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 0d9ae29. Configure here.
| } | ||
| if ((v == 12)) { | ||
| return true; | ||
| } |
Contributor
There was a problem hiding this comment.
Stable pass_ct rows flag unexpected pass
High Severity
Making is_pass true for pass_ct (code 12) causes entry_code to mark a still-pass_ct ledger row as an unexpected pass. entry_code only treats want == 0 or want == 1 as a pass expectation, so want 12 falls through to is_pass(got) and returns unexpected pass. The ratchet would go red on the five existing pass_ct rows even when the run is unchanged, and re-blessing still stores t27b: pass_ct, so it cannot clear the finding.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 0d9ae29. Configure here.
Co-authored-by: Dmitrii Vasilev <gHashTag@users.noreply.github.com>
This was referenced Nov 9, 2026
Contributor
PR DashboardGenerated at: 2026-11-09 21:18:34 UTC
Summary
Seal Status
|
This was referenced Nov 9, 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
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.
Two parts, both needed. The commit message carries the same text.
What was wrong
specs/tri/t27b/steward.t27already countspass_ctas a pass (is_pass:v == 12, added by hosting: pass_ct joins the verdict vocabulary -- the words, the steward, the rules mirror (Refs #5980) #12792).gen/c/tri/t27b/steward.cwas not regenerated after that edit. The spec and the seal agree; only the committed file lagged.scripts/tri_loop/t27b_rules.pycompiles and calls that C, so every consumer readis_pass(pass_ct) = false.scripts/ci/test_a_t27b_spec_cannot_move_silently.pyalso kept its own success list ("pass","pass_vacuous") for the blocker-and-reason check. The fivepass_ctrows of the ledger (blocker"", as bless writes them) failed it.The change
gen/c/tri/t27b/steward.c, regenerated from the spec witht27c gen-c specs/tri/t27b/steward.t27, no hand edit.d1941f3b..., thegen_hash_calready recorded in.trinity/seals/t27b_T27bSteward.json.t27c seal specs/tri/t27b/steward.t27 --verify: all hashes MATCH. The seal is not re-saved.is_passcounts as a pass, read throught27b_rules.ledger_countsin bless does, 140 == 140.Controls (one test file, run by hand)
""""Local hooks: pre-commit and pre-push passed (foreign-budget, own-language, secret-gate).
The cap, unchanged
tri t27b ratchet --blessboth count every row outside("pass", "pass_vacuous"): 133 blocked + 1 codegen + 1 mismatch + 5 pass_ct.tri t27b ratchetshould count on this tree, because it asks the regeneratedis_pass.t27b-nativeCI job runs it.ledger_countsand bless inscripts/tri_loop/t27b.pystill use the tuple. Aligning them withis_passis a separate decision and is not in this PR.Not in this PR
no-auto-merge: merging waits for the owner's decision.Refs #12751
Refs #12867
🤖 Generated with Claude Code
Note
Low Risk
CI/test alignment plus regenerated steward C from an already-sealed spec; no auth, data, or ratchet cap logic changes in this diff.
Overview
Regenerates
gen/c/tri/t27b/steward.cfromspecs/tri/t27b/steward.t27so generatedis_passtreatspass_ctas a pass again, matching the seal and unblockingt27b_rules.is_pass.The committed-ledger section of
scripts/ci/test_a_t27b_spec_cannot_move_silently.pynow callst27b_rules.is_passwhen enforcing blocker/reason on non-pass rows, sopass_ctledger entries no longer fail that check. The cap assertion still uses the existing("pass", "pass_vacuous")tuple.Reviewed by Cursor Bugbot for commit 6d563c8. Bugbot is set up for automated code reviews on this repo. Configure here.