Skip to content

spec(ci): suite ledger steward -- what the corpus ledger bot applies and refuses (Closes #10204) - #10208

Merged
gHashTag merged 1 commit into
masterfrom
claude/suite-ledger-steward
Oct 18, 2026
Merged

spec(ci): suite ledger steward -- what the corpus ledger bot applies and refuses (Closes #10204)#10208
gHashTag merged 1 commit into
masterfrom
claude/suite-ledger-steward

Conversation

@gHashTag

@gHashTag gHashTag commented Oct 18, 2026

Copy link
Copy Markdown
Owner

Closes #10204

Corpus ratchet is red for a fall as well as a rise. An UNEXPECTED PASS or a DISCARD IMPROVED on master fails the check until docs/reports/suite_expectations.json records it, and every PR inherits that red until someone writes a hand PR. #10172 is the latest example. specs/ci/derived_data.t27 says one bot re-derives lag on master. The t27b ledger has such a bot (specs/tri/t27b/ledger_steward.t27); the corpus ledger did not. This PR is that bot's decision and its job card, in t27 only.

What changes

specs/ci/suite_ledger_steward.t27 (module SuiteLedgerSteward) decides per ledger row and per master run.

Applied by the steward:

  • DROP: remove a row whose spec fails no phase.
  • REPIN: re-pin a parse-no-discard total that fell, when no channel rose.
  • Lower the gate-failure pin to the run's count.
  • Write max_entries as the composed row count (cap_after), only when derived_data.bot_may_bless allows it.

Refused, left to a person:

  • a new failure
  • a moved row (a new non-pass reason is needed, which derived_data rule 4 keeps from the bot)
  • an expired row
  • a discard rise
  • a channel rise while the total held or fell
  • a pinned row with no reading
  • an unpinned or self-inconsistent row
  • a gate-failure rise or a missing gate pin

Whole run refused:

  • a cap rise, meaning the ledger would still be over max_entries after the drops
  • more than DROP_LIMIT = 16 drops, because a broken run looks like a corpus where everything passes

A refused row stays as master has it, and the rest of the run is applied, following #10192's rule.

Runs the steward reads (run_stewardable): master runs only, built with a t27c from that same commit, whose ratchet reached a verdict, and that compared against master's current ledger. #10172's lab binary was older than master and reported a false failure on verilog_odd_cast.

Tests are pinned on real cases:

Invariants:

  • The cap never rises, and cap_fits agrees with bot_may_bless.
  • A rise or a new failure is never applied.
  • The codes never move.

specs/jobs/suite_ledger_steward.t27 (module JobSuiteLedgerSteward) is the job card, modelled on specs/jobs/t27b_ledger_steward.t27. It has the same 8 steps, step kinds and effect codes.

  • Trigger: a red master run of corpus-ratchet.yml. The steward reads suite_summary.json and ratchet.log from the run's corpus-ratchet-log artifact.
  • Compose step: it does not run --bless-expectations, because bless drops the _why_entries_* notes and would write a rise. The step edits rows in place, keeps the notes, and appends one line to _why_entries_fell.

One deliberate difference from #10172

#10172 raised benchmark 315 -> 319 (bdd-block-fallback +4) by hand. The steward refuses that row as RR_DISCARD_ROSE. suite.rs says a worsened pin is raised only by a human running bless and reviewing the diff, and derived_data.t27 rule 4 agrees. On #10172's run the steward applies the other ten changes and lists benchmark as refused in its PR. A person then decides on it.

Follow-up (not in this PR)

Nothing runs this card yet. Running it needs these pieces:

  • the supervisor (lab.py) watching master runs of corpus-ratchet.yml, reading the artifact, and composing the ledger;
  • possibly corpus-ratchet.yml uploading a per-row discard summary if suite_summary.json lacks one.

Both are foreign code and need the owner's owner-approved-foreign label, so they are left for a separate PR.

Evidence (Railway lab, t27c 0.5.2+c0f6076, zig 0.16.0)

  • test-report specs/ci/suite_ledger_steward.t27: 11/11 pass, 0 vacuous; 3 invariants proved at compile time.
  • test-report specs/jobs/suite_ledger_steward.t27: 2/2 pass, 0 vacuous; 1 invariant proved.
  • seal --save on both specs, then seal --verify: all hashes MATCH. The seals were brought back by base64 and checked by sha256.
  • t27c suite --repo-root . --ratchet --corpus-only on the branch: RATCHET CLEAN. That means 0 unexpected failures, 0 unexpected passes and no discard drift, so the two new specs do not need ledger rows.

Only .t27 files and t27c-written seals. No YAML, Python or Rust.

🤖 Generated with Claude Code

@gHashTag @claude
spec(ci): suite ledger steward -- what the corpus ledger bot applies …
5ee66a9 
…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
gHashTag enabled auto-merge (squash) October 18, 2026 04:21
@github-actions

github-actions Bot commented Oct 18, 2026

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-18 04:25:17 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).

@github-actions github-actions Bot mentioned this pull request Oct 18, 2026
Merged
@gHashTag
gHashTag merged commit 27efeba into master Oct 18, 2026
25 of 29 checks passed
This was referenced Oct 18, 2026
Closed
Merged
gHashTag added a commit that referenced this pull request Oct 18, 2026
@gHashTag @claude
ledger(dupe): record the four bodies suite_ledger_steward copies from…
6850419 
… the t27b steward (Closes #10216) (#10217)

#10208 added specs/ci/suite_ledger_steward.t27 and
specs/jobs/suite_ledger_steward.t27. They repeat effect_wanted,
run_starts_job, step_ef and writes_the_repo from the t27b ledger
steward specs, so the Duplicate Body Ratchet has been red on master
since 27efeba and on every open PR.

tools/duplicate_bodies_baseline.txt is rewritten by
`python3 tools/dupe_scan.py --bless` on the Railway lab at master
d9e0c6c: four lines added, none removed, no other count moves.
Afterwards dupe_scan.py exits 0 ("ok: no new duplicate body"). Reusing
the t27b functions with a `use` instead is left to #10208's owner.

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

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

spec(ci): suite ledger steward -- the corpus ledger bot's decision and job card

1 participant

@gHashTag