spec(ar): import the type these four specs already use - #3417
Merged
Conversation
Refs #3408 `Trit` is declared by four specs as `pub const Trit = enum(i8)`. Four OTHER specs use it and carried zero `use` lines -- naming a type they never imported. One line each. Measured per file before writing anything, and the corpus figure matches the sum exactly: ar/coa_planning 69 -> 65 (-4) ar/explainability 34 -> 29 (-5) ar/proof_trace 25 -> 20 (-5) ar/restraint 30 -> 19 (-11) corpus coded diagnostics 2962 -> 2937 (-25) unknown-type warnings 478 -> 460 rustc acceptance 433 -> 433 Acceptance is unchanged and that is expected: each of these files still carries between 19 and 65 other errors. All four backends still generate for all four specs. The seal-currency checker added one pass ago reported 10 stale seals by name the moment these specs were edited, including every duplicate; all 10 are refreshed here and the checker reads 0 again. Ten seals for four specs -- Explainability and ar_Explainability, ProofTrace and ar_ProofTrace, coa_planning and ar_coa_planning -- which is why the refresh walks every seal rather than calling `t27c seal --save`, and why the duplicate-naming decision in #3415 stays open. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
enabled auto-merge (squash)
September 7, 2026 21:18
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
This was referenced Sep 7, 2026
gHashTag
added a commit
that referenced
this pull request
Sep 7, 2026
…ns by case (#3419) Closes #3418 Two defects in one place, both found by being bitten rather than by review. A spec can own more than one seal file and `--save` wrote one. Measured over .trinity/seals: 1313 seals name 728 distinct specs, and 547 specs carry more than one -- 501 of them the same module under two names, `<Module>.json` beside `<dir>_<Module>.json`, left by a naming scheme that changed. Refreshing 116 stale seals through this command in #3416 reached 58 and stopped for exactly that reason; editing four specs in #3417 produced ten stale seals where --save would have fixed four. The duplicates are not deletable: math_compare.rs opens .trinity/seals/PellisFormulas.json by its bare name and that file is one of a pair. So the tool maintains them. Only hashes and the timestamp are rewritten; each file keeps its own `module`, because the file is NAMED after that field and overwriting it would leave a seal whose name and contents disagree. Second defect, invisible on macOS: seal_file_path derives `ar_restraint.json` where `ar_Restraint.json` is tracked. 751 filenames match the derived name exactly, 4 differ only by case, 558 use the older scheme. A case-insensitive filesystem resolves the pair to one file; the case-sensitive one CI runs on would grow a SECOND seal for the same spec, and neither would look wrong. An existing file now wins the lookup. The test for that half CANNOT FAIL on this machine and says so. Mutation proved it -- making the lookup case-sensitive leaves the test green here, because creating `Aa` then `aA` yields one file. It probes the filesystem and skips loudly rather than reporting a pass it did not earn; it discriminates on Linux, where CI runs. The other test does kill its mutant here. The child runs with its own working directory rather than set_current_dir, which is per-process and would race every other test in this binary under the default parallel runner. Left alone and filed: 93 specs carry a seal whose name is not an identifier -- specs/tri/utils/logger.t27 has `"[]const u8".json`, a seal named after a type string. compiler.rs is untouched, so FROZEN_HASH is unchanged. Co-authored-by: lab <lab@example.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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.
Refs #3408
Tritis declared by four specs aspub const Trit = enum(i8). Four other specs use it and carried zerouselines — naming a type they never imported. One line each.Measured per file before writing anything
ar/coa_planningar/explainabilityar/proof_tracear/restraintAnd the corpus figure matches that sum exactly:
unknown typewarningsAcceptance is unchanged and that is expected — each of these files still carries between 19 and 65 other errors. All four backends still generate for all four specs, checked.
The guard from last pass caught this immediately
tools/check_seal_currency.py, added in #3416, reported 10 stale seals by name the moment these specs were edited:All 10 refreshed here; the checker reads 0 again. A guard built in one pass catching the very next change is the only evidence that building it was worth anything.
Ten seals for four specs
Explainability.jsonandar_Explainability.json.ProofTrace.jsonandar_ProofTrace.json.coa_planning.jsonandar_coa_planning.json.That is why the refresh walks every seal rather than calling
t27c seal --save, which writes one name and would have left half of them stale — the same trap as #3415. The duplicate-naming decision stays open there.One process note
for f in $SPECSran the loop once, with the whole list as a single filename: zsh does not word-split an unquoted variable. Caught bycprefusing the path, and the tree was clean afterwards. Fourth occurrence this session — the fix is a literal list or${=VAR}.