feat(tri): the tenth ledger -- the one refusal that work could lift - #2962
Merged
Conversation
Of the six ledgers the audit excused last pass, five are excused by cost or by
shape: two are gated by the corpus suite and take minutes, one is keyed by the
sha1 of the line it excuses, one is a generated observation that the next
regeneration would erase. Exactly one was excused by MISSING WORK.
`docs/reports/type_conflicts_classified.json` was measured as catching a planted
row, and left out because the plant had to clone an entry's field shape and
`Plant` could express only an appended line and one ghost key.
It can now. `ClassifiedName` deserialises `name` and `verdict` and nothing else,
so a two-field object is complete for the reader and false for the claim -- no
type name in this corpus is called `PlantedByLedgersAudit`. The row is inserted
into `names` textually rather than by re-serialising, so the document's
formatting survives the restore.
caught docs/reports/type_conflicts_classified.json by tri types classified
ledger-shaped files on disk 15 planted into 10, excused 5, unclassified 0
VERIFIED FOR THE RIGHT REASON, which is the whole risk with a JSON plant. The
planted file parses, and the gate fails on the claim:
STALE PlantedByLedgersAudit: classified, but no longer conflicting -- drop the row
Error: 1 stale row(s) and 0 unjudged conflict(s).
A shape error wearing a catch would have left this ledger reported as protected
while its staleness check was never exercised.
Mutation-checked: make the plant emit invalid JSON and
`substitution_keeps_what_makes_it_false` fails on "planted ledger must parse".
The same test asserts the planted row is one MORE row rather than a replacement,
because an insertion that overwrites would test a different file.
And the coverage test earned itself. Adding the ledger while leaving its
exclusion in place put one path in both lists, and
`no_ledger_is_both_planted_into_and_excused` failed before I noticed -- the
check written two passes ago catching the change that landed today.
cargo test -p tri 392 passed, 0 failed
cargo clippy 120 warnings, same as master
tri ledgers audit 10 caught, 0 missed, exit 0; the ledger restored unchanged
Refs #2864
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-30 16:22:55 UTC
Summary
Seal Status
|
Contributor
PR DashboardGenerated at: 2026-08-30 16:23:21 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-30 16:39:42 UTC
Summary
Seal Status
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The one refusal that work could lift
Of the six ledgers the audit excused last pass, five are excused by cost or
by shape — two gated by the corpus suite (minutes per run), one keyed by the
sha1 of the line it excuses, one a generated observation the next regeneration
would erase. Exactly one was excused by missing work:
It can now.
The plant
ClassifiedNamedeserialisesnameandverdictand nothing else, so atwo-field object is complete for the reader and false for the claim — no
type name in this corpus is called
PlantedByLedgersAudit:{ "name": "PlantedByLedgersAudit", "verdict": "DRIFT" }Inserted into
namestextually rather than by re-serialising, so the document'sformatting survives the restore.
Verified for the right reason
That is the whole risk with a JSON plant, and #2950
is the pass where it bit. The planted file parses, and the gate fails on the
claim:
A shape error wearing a catch would have left this ledger reported as protected
while its staleness check was never exercised once.
Mutation-checked
substitution_keeps_what_makes_it_falsefails on "planted ledger must parse"no_ledger_is_both_planted_into_and_excusedfailed before I noticedThat last one is the check written two passes ago catching the change that
landed today.
Checks
cargo test -p tri— 392 passed, 0 failedcargo clippy --all-targets— 120 warnings, identical to mastertri ledgers audit— 10 caught, 0 missed, exit 0; the ledger restored unchangedRefs #2864