Skip to content

t27b ledger steward: the rules and the job card, so spec PRs stop editing the ledger (Closes #8654) - #8656

Merged
gHashTag merged 1 commit into
masterfrom
feat/t27b-ledger-steward-8654
Oct 10, 2026
Merged

gHashTag merged 1 commit into
masterfrom
feat/t27b-ledger-steward-8654

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

Closes #8654

Why

Spec PRs land without a row in docs/reports/t27b_expectations.json. Master's t27b-native-ratchet then goes red (UNLISTED) on every PR, and parallel lanes conflict on the file. It was fixed by hand three times in two days: see #8289, #8548 and #8646. This is item 1 of the efficiency plan (see #8637) and option 3 of #8321.

The rules: specs/tri/t27b/ledger_steward.t27

The rules use steward.t27's codes and functions: is_pass, bless_reason, cap_rise_is_new, and entry_code in an invariant.

finding on a master run steward
UNLISTED, t27b pass / pass_vacuous add the row as the run states it
UNLISTED, blocked / frontend / codegen add it, reason unimplemented
UNEXPECTED PASS set the row to the run's pass
STALE drop the row
VACUITY MEASURED, UNJUDGED keep the row (information)
cap rise <= new non-pass rows max_not_pass = the recounted non-pass
UNEXPECTED FAILURE, MOVED, BAD REASON, OVER CAP refuse
UNLISTED where t27b fails / mismatches / crashes / times out refuse (a defect is never unimplemented)
a cap rise larger than the new rows, or more than 16 STALE rows refuse

One refused finding refuses the whole run: the run gets one issue and no PR. A run that is not a master run, did not count asserts, or was compared against a ledger master no longer has is skipped.

The tests use the hand batches as vectors:

The job card: specs/jobs/t27b_ledger_steward.t27

The card has the shape of release_t27c.t27 and follows jobs.t27:

  • 0 CHECK steward-run
  • 1 EFFECT steward-refusals-issue
  • 2 CHECK steward-appliable
  • 3 EFFECT steward-ledger-issue
  • 4 EFFECT steward-compose
  • 5 EFFECT steward-pull-request
  • 6 EFFECT steward-auto-merge
  • 7 WAIT steward-merged

The trigger is a master run of t27b-lab (latest.json) whose ratchet is red. Master's native ratchet is the second trigger once t27b-native.yml uploads its run.json and ratchet.json. Every effect goes through the effects journal, keyed by the run's commit.

Runtime

The Queen's job runner (gHashTag/trios queen-jobs.ts, branch queen-runners) runs only the release card. Its loader, trigger, executors, journal kinds (issue, auto-merge) and credential are missing; the details are in gHashTag/trios#1751. Until it runs, spec PRs keep adding their own rows. The t27b-loop skill says so.

Measured on the t27c lab

  • t27c test-report: 10 of 10 tests, 0 vacuous (ledger_steward); 2 of 2, 0 vacuous (card).
  • t27b corpus --blockers --reference <t27c> --json, under qemu-aarch64: both specs pass on both sides, with 108 and 26 runtime asserts and 0 reference disagreements. All 117 files under specs/tri/t27b still pass the reference.
  • Both specs are sealed with t27c seal --save, and each has its ledger row (pass). max_not_pass is unchanged.

Only .t27, .json and .md files change.

🤖 Generated with Claude Code

…ting the ledger (Closes #8654)

specs/tri/t27b/ledger_steward.t27 decides which ratchet findings on a master run
the steward applies (UNLISTED, UNEXPECTED PASS, STALE, a cap rise covered by
new rows) and which it refuses and reports in one issue per run (UNEXPECTED
FAILURE, MOVED, BAD REASON, OVER CAP, a defect, a larger cap rise, a STALE
flood). The hand batches #8289, #8548 and #8646 are its test vectors.

specs/jobs/t27b_ledger_steward.t27 is the jobs.t27 card: CHECK the run, EFFECT
the refusal issue, CHECK appliable, EFFECT ledger issue, compose, PR,
auto-merge, WAIT merged. The Queen runtime gaps are in gHashTag/trios#1751.

Both specs pass t27c test-report and t27b corpus --reference on the t27c lab
with runtime asserts; seals and ledger rows included.

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

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-10 14:46:06 UTC

Summary

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

These columns do not partition: 0 + 49 + 0 + 0 = 49, and there are 50 open PRs. A PR is being counted twice or not at all.

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=998387bced4a != 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).

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: rules and job card, so spec PRs stop editing the ledger

2 participants