Repository navigation
t27b-native ratchet is red on every master run since it landed: ledger 099ac2224 predates 16 improvements and 40+ new specs #7023
Description
Problem
t27b-native-ratchet (.github/workflows/t27b-native.yml, landed in #6846 at 31ad9df) has been red on master on every run since it landed, and so it is red on every PR. The ledger docs/reports/t27b_expectations.json was last blessed at 099ac22 (#6646), before the workflow existed.
| master run | head | verdict |
|---|---|---|
| 37499689149 | 31ad9df (#6846 itself) | UNEXPECTED PASS 16, UNLISTED 40 |
| 37500597107 | 6540a67 | UNEXPECTED PASS 16, UNLISTED 41 |
| 37505149120 | 92d7024 (#6966) | UNEXPECTED PASS 16, UNLISTED 42 |
UNEXPECTED FAILURE is 0 on all three: nothing regressed. The red is two kinds of good news nobody recorded:
- 16 UNEXPECTED PASS:
pass_vacuousin the ledger, a real pass now (14specs/crons/*,specs/isa/ternary_encoding.t27,specs/tools/trinity/tri/wallet.t27). - 40-42 UNLISTED: specs the reference passes and the ledger does not name (
specs/verified/*,specs/isa/t27a*.t27,specs/port/*,specs/queen/actors.t27,specs/queen/control.t27,specs/tri/t27b/{fuzz,fuzz_oracle,reduce}.t27, ...).
The UNLISTED count grows by one with every merged PR that adds a spec (40 -> 41 -> 42 above). PR #7001's run 37506279886 at dbf97e9 has exactly master's 58 findings (set difference empty both ways), so it adds nothing. The check is not a required context, so it blocks no merge, but a check that is red on every head reads as noise and stops being looked at.
Proposal
- Bless the ledger on master from a master run (
tri t27b ratchet --run <master run.json> --bless), in its own PR under this epic's lane, with the run ID in the body. - Decide how a spec-adding PR stays green, so UNLISTED does not grow again. Either the PR adds its own ledger row (and the check says so in its failure text), or an UNLISTED path that the head itself adds is reported as a notice instead of red.
Acceptance criteria
t27b-native-ratchetis green on a master run after the bless.- A PR that adds one new reference-passing spec and nothing else gets a defined result (green, or red with the exact ledger line to add), written down in the ratchet's help text.
Refs #6063
Boundary
specs/isa/ternary_encoding.t27specs/queen/actors.t27specs/queen/control.t27specs/tools/trinity/tri/wallet.t27.github/workflows/t27b-native.yml
User Scenarios
- Given the
t27b-native-ratchetworkflow has been red on every master run since landing, When the ledgerdocs/reports/t27b_expectations.jsonis blessed from a clean master run, Then the workflow reports green on the subsequent master run. - Given a contributor opens a PR that adds exactly one new spec under
specs/which passes the reference implementation, When the ratchet runs on that PR, Then the check result is defined: either green, or red with the exact ledger line the PR must add to become green.
Requirements
FR-001: The ledger docs/reports/t27b_expectations.json MUST be updated via tri t27b ratchet --run <master-run.json> --bless from a passing master run so that all 16 UNEXPECTED PASS entries become expected passes and all 40-42 UNLISTED entries become listed.
FR-002: The ratchet tool MUST classify a newly added spec that passes the reference implementation as a notice (not a failure) when the spec path is introduced by the same PR, or MUST emit the exact ledger line the PR must add to make the check green.
FR-003: The workflow .github/workflows/t27b-native.yml MUST run the updated ratchet logic and exit 0 on master after the bless PR merges.
FR-004: The ratchet's help text (or failure output) MUST document the defined result for a spec-adding PR so contributors know whether to add a ledger row or expect green.
Activity
gHashTag commentedon Oct 7, 2026
Reopened 2026-10-07: the bulk close of issues without a
## Boundarysection was reverted by the owner. Nothing to do here; this comment replaces the earlier close notice.spec(policy): drop a redundant @intcast in added_lines so t27b compil…
t27b: the Mach-O object layout and bytes are a t27 spec (Closes #7526) (
github-actions commentedon Oct 15, 2026
Re-filed as #9600.
An attempt claimed this issue on 2026-10-09 and left an empty branch. A dispatch row that has spent its retry ceiling is released once and then keeps its issue for good, which is the right rule for a third identical failure and the wrong outcome for an issue nobody ever attempted twice. The new issue carries the same work, the same boundary, and today's brief.
Closing this one so the swarm can take the work again.