Skip to content

spec(t27b): ledger steward applies the safe rows when one finding is refused (Closes #10189) - #10192

Merged
gHashTag merged 2 commits into
masterfrom
fix/steward-partial-apply
Oct 18, 2026
Merged

gHashTag merged 2 commits into
masterfrom
fix/steward-partial-apply

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

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-ratchet therefore 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.
    • A refused row stays as master has it: lab.py leaves REFUSE rows untouched when composing.
    • queen-publish lists every finding with its action in the PR table, so the refused rows are visible in the bot PR.
    • The cap is counted on the composed ledger, so a refused row cannot raise it.
  • REFUSE is unchanged for a run with nothing else to apply, a cap rise or a stale flood. The t27b ledger: master's native run at c9d36f314, row by row (Closes #8322) #8548 test still refuses, because its cap does not fit.
  • A new test is pinned on run 18c98cc's counts.
  • The job card (step 2) and the t27b-loop skill now say the same.

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 --save on both specs, then seal --verify: all hashes MATCH. The seals were brought back by base64 and checked by sha256.

🤖 Generated with Claude Code

gHashTag and others added 2 commits October 18, 2026 10:52
…refused (Closes #10189)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@gHashTag
gHashTag enabled auto-merge (squash) October 18, 2026 03:56
@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-18 03:57:07 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 50
PRs with All Checks Green 0
READY 0
FAILING 50
PENDING 0
NO CHECKS YET 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=0f8c66b9ed0e != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@gHashTag
gHashTag merged commit 6d60995 into master Oct 18, 2026
30 of 32 checks passed
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

t27b ledger steward: apply the safe rows when one finding is refused

1 participant