Repository navigation
spec(t27b): ledger steward applies the safe rows when one finding is refused (Closes #10189) - #10192
Merged
Merged
Conversation
…refused (Closes #10189) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gHashTag
enabled auto-merge (squash)
October 18, 2026 03:56
Contributor
gHashTag
added a commit
that referenced
this pull request
Oct 18, 2026
…and refuses (Closes #10204) specs/ci/suite_ledger_steward.t27 decides, per corpus-ledger row and per master run, what a steward may write to docs/reports/suite_expectations.json: DROP a row whose spec passes, REPIN a discard pin that fell, lower the gate-failure pin and the cap to the count. It refuses a new failure, a moved or expired row, any rise, a missing reading, an unpinned or self-inconsistent row, a cap rise and a drop flood. A refused row stays as master has it and the rest is applied (#10192's rule). Tests pinned on #10172, #8345, #7804, #6437, #9281, #8823 and #5497. specs/jobs/suite_ledger_steward.t27 is the job card. Seals written by t27c on the Railway lab. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Oct 18, 2026
…and refuses (Closes #10204) (#10208) specs/ci/suite_ledger_steward.t27 decides, per corpus-ledger row and per master run, what a steward may write to docs/reports/suite_expectations.json: DROP a row whose spec passes, REPIN a discard pin that fell, lower the gate-failure pin and the cap to the count. It refuses a new failure, a moved or expired row, any rise, a missing reading, an unpinned or self-inconsistent row, a cap rise and a drop flood. A refused row stays as master has it and the rest is applied (#10192's rule). Tests pinned on #10172, #8345, #7804, #6437, #9281, #8823 and #5497. specs/jobs/suite_ledger_steward.t27 is the job card. Seals written by t27c on the Railway lab. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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.
Closes #10189
The t27b ledger steward refused a whole master run whenever one finding was a person's. From 2026-10-13 to 10-18 the lab judged 75 master commits: 63 REFUSE, 7 APPLY, 5 SKIP. Every REFUSE was held up by the same two or three rows: rust_convert, trios-mesh-node crypto, and sometimes emit_kit. Run 18c98cc had 248 safe UNLISTED passes waiting behind 2 refused findings. Master's
t27b-native-ratchettherefore stayed red (UNLISTED 263), every PR inherited it, and sessions wrote rows by hand. Those hand edits moved the ledger mid-run, which then turned the lab's verdict into SKIP.What changes
run_verdict: if some finding is the steward's, the cap fits and STALE is no flood, the verdict is APPLY even when other findings are refused.No workflow, Python or compiler change. The lab compiles this spec from the master clone and calls it through ctypes, so the rule takes effect on its next run.
Evidence (Railway lab, t27c 0.5.2+063da049b)
test-report specs/tri/t27b/ledger_steward.t27: 11/11 pass, 0 vacuous.test-report specs/jobs/t27b_ledger_steward.t27: 2/2 pass, 0 vacuous.seal --saveon both specs, thenseal --verify: all hashes MATCH. The seals were brought back by base64 and checked by sha256.🤖 Generated with Claude Code