t27b ledger: counts are derived from entries, not stored -- every spec PR conflicted on the pass line #7859

docs/reports/t27b_expectations.json stores counts (pass, pass_vacuous, not_pass) in its header, next to the per-spec entries. The counts are a total over the entries, so every PR that adds a spec changes the same header line as every other such PR.

Measured on 2026-10-08: #7579, #7586 and #7626 went dirty three times in two hours. Each time the only conflicting line was "pass": N. The entries, one line per spec and sorted, always merged cleanly. The fpga jobs take about an hour, so a spec PR cannot outrun the t27b PRs that land on master several times an hour.

Rule (in specs/tri/t27b/steward.t27): a header field is stored only when it is not a total over entries. counts is derived from entries wherever it is needed. max_not_pass stays stored: it is the ratchet's promise (non-pass may only fall), not a total, and a PR that adds a pass entry does not move it.

Done when:

• the ledger has no counts, and tri t27b ratchet --bless does not write it, as the spec decides;
• two branches that each add one pass entry merge without conflict;
• the ratchet still catches a moved spec, and scripts/ci/test_a_t27b_spec_cannot_move_silently.py passes.

Generated by Claude Code

User Scenarios

• Given a t27b_expectations.json ledger with counts in its header, when two branches each add a different pass entry to entries, then the branches merge without conflict because the header no longer contains a derived total.
• Given the ratchet command tri t27b ratchet --bless, when it runs after the change, then it does not write a counts field to the ledger header.
• Given a spec that changes from pass to not_pass, when the ratchet runs, then it still detects the regression and the existing test scripts/ci/test_a_t27b_spec_cannot_move_silently.py passes.

Requirements

FR-001: The counts field (pass, pass_vacuous, not_pass) MUST be removed from the header of docs/reports/t27b_expectations.json.
FR-002: The tri t27b ratchet --bless command MUST NOT write a counts field to the ledger.
FR-003: The max_not_pass field MUST remain stored in the header as it is a ratchet promise, not a derived total.
FR-004: All code that reads counts from the ledger MUST derive it from entries instead.
FR-005: The ratchet logic MUST continue to enforce that not_pass count never increases (via max_not_pass).

Success Criteria

• docs/reports/t27b_expectations.json has no counts field in its header (verified by jq 'has("counts")' docs/reports/t27b_expectations.json exits 0 with output false)
• tri t27b ratchet --bless writes no counts field (verified by running it and checking the output JSON lacks counts)
• Two branches each adding one pass entry to entries merge cleanly with git merge (exit 0)
• python scripts/ci/test_a_t27b_spec_cannot_move_silently.py exits 0
• All existing t27b-related tests pass (5 tests minimum)

Boundary

• specs/tri/t27b/steward.t27
• docs/reports/t27b_expectations.json
• scripts/tri_loop/t27b.py
• scripts/ci/test_a_t27b_spec_cannot_move_silently.py