Skip to content

Port the tree catalog-vs-Lua reconstruction check to Rust (#227) - #354

Merged
wormeyman merged 1 commit into
mainfrom
feat/227-tree-catalog-lua-check
Aug 30, 2026
Merged

Port the tree catalog-vs-Lua reconstruction check to Rust (#227)#354
wormeyman merged 1 commit into
mainfrom
feat/227-tree-catalog-lua-check

Conversation

@wormeyman

Copy link
Copy Markdown
Collaborator

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

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
wormeyman force-pushed the feat/227-tree-catalog-lua-check branch from 6add7a0 to aa608b0 Compare August 30, 2026 05:19
@wormeyman
wormeyman merged commit 9ee2d2d into main Aug 30, 2026
9 checks passed
@wormeyman
wormeyman deleted the feat/227-tree-catalog-lua-check branch August 30, 2026 05:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant