Port the tree catalog-vs-Lua reconstruction check to Rust (#227) - #354
Merged
Conversation
Port-first entry 3. `test/treeCatalogExpressions.spec.ts` rebuilds each species' Lua expression string from its catalog row and diffs it against the real 2.1.11 game data, character for character. `trees/catalog.rs` holds the crc32 claims and the tree_05/tree_07 exception set, but nothing on this side compared a reconstructed string against the game, so deleting that spec with `src/noise/trees/treeCatalog.ts` would leave the Rust catalog with no game-data validation at all. The value is that the check has no filter. The original uniformity claim was verified by filtering the terms common to every `tree_0*` block out and observing that nothing was left - and the filter dropped every line holding `control:trees:size`, which is the one line the per-species term lives on. Four tasks were built on that wrong premise before an oracle caught it. A filter-then-compare check can only find what its filter lets through. Planted rather than predicted: setting `tree_05`'s `size_offset` back to 0.5, which is the original defect exactly, fails with the term named - `- 0.5` against the game's `- 0.45`, everything else in the 400-character string identical. Three tests, matching the three claims the spec carried: | test | claim | | --- | --- | | `every_species_reconstructs_the_games_own_lua_expression` | all 15 rebuild exactly | | `accounts_for_every_tree_expression_in_the_game_data` | a 16th species lands in neither list and fails | | `the_size_offset_exception_set_comes_from_the_game_data` | the exception set read from game data, not the catalog | The third is belt and braces with `catalog.rs`'s own exception test, which would still pass if the catalog and its test were wrong together. One thing worth recording: Rust's `Display` for f64 and JavaScript's `String(n)` agree on every constant in the table, both being the shortest round-tripping form, so the reconstruction needed no number-formatting shim. That was the risk in this port and it did not materialise. The catalog's module doc pointed at the spec being deleted; it now points at the Rust test. Claude-Session: https://claude.ai/code/session_01UVcbv1pAhPUoCC6aBwZUtg Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
wormeyman
force-pushed
the
feat/227-tree-catalog-lua-check
branch
from
August 30, 2026 05:19
6add7a0 to
aa608b0
Compare
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
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.
Port-first entry 3.
test/treeCatalogExpressions.spec.tsrebuilds each species'Lua expression string from its catalog row and diffs it against the real 2.1.11
game data, character for character.
trees/catalog.rsholds the crc32 claimsand the tree_05/tree_07 exception set, but nothing on this side compared a
reconstructed string against the game, so deleting that spec with
src/noise/trees/treeCatalog.tswould leave the Rust catalog with no game-datavalidation at all.
The value is that the check has no filter. The original uniformity claim was
verified by filtering the terms common to every
tree_0*block out andobserving that nothing was left - and the filter dropped every line holding
control:trees:size, which is the one line the per-species term lives on. Fourtasks were built on that wrong premise before an oracle caught it. A
filter-then-compare check can only find what its filter lets through.
Planted rather than predicted: setting
tree_05'ssize_offsetback to 0.5,which is the original defect exactly, fails with the term named -
- 0.5against the game's- 0.45, everything else in the 400-character stringidentical.
Three tests, matching the three claims the spec carried:
every_species_reconstructs_the_games_own_lua_expressionaccounts_for_every_tree_expression_in_the_game_datathe_size_offset_exception_set_comes_from_the_game_dataThe third is belt and braces with
catalog.rs's own exception test, which wouldstill pass if the catalog and its test were wrong together.
One thing worth recording: Rust's
Displayfor f64 and JavaScript'sString(n)agree on every constant in the table, both being the shortest round-tripping
form, so the reconstruction needed no number-formatting shim. That was the risk
in this port and it did not materialise.
The catalog's module doc pointed at the spec being deleted; it now points at the
Rust test.
Claude-Session: https://claude.ai/code/session_01UVcbv1pAhPUoCC6aBwZUtg
Co-authored-by: Claude Opus 5 (1M context) noreply@anthropic.com