Skip to content

Freeze the Vulcanus render parity to fixtures (#227) - #351

Merged
wormeyman merged 1 commit into
mainfrom
feat/227-freeze-vulcanus-render-parity
Aug 30, 2026
Merged

Freeze the Vulcanus render parity to fixtures (#227)#351
wormeyman merged 1 commit into
mainfrom
feat/227-freeze-vulcanus-render-parity

Conversation

@wormeyman

Copy link
Copy Markdown
Collaborator

The second of the three render parity specs, on the machinery #350 added. This
one is the conversion only - no new infrastructure.

What it adds

vulcanus:render, 26 rows in test/fixtures/tier3-render-checksums.json:

block rows
terrain windows 4
routed views (terrain, cliffs, rocks, resources, all) 5
rock overlay windows 4
resource overlay windows 5
composite windows 4
cliff windows 4

Each recorded only after the two arms were compared and agreed. The existing
expect(wasm).toEqual(ts) assertions stay, so a failure still gives a
pixel-level diff; the deletion PR drops those and the ts locals, and the
frozen rows are what survive.

nauvis:render came through the re-record byte-identical - checked, not
assumed, since flushRecording merging rather than truncating is the property
the whole two-section table depends on.

What is deliberately not frozen

The three renderTiled helpers. Every one of their runRenderRequest calls
passes the engine, so they compare tiled against whole rather than Rust against
TypeScript, and the deletion leaves them grading exactly what they grade now. I
checked the call sites rather than assuming from the helper name - the line-wise
grep flags them because the runRenderRequest( line itself carries no engine
argument, and the e sits several lines down after the request object.

The coverage guard, from the start this time

#350 shipped without one and review caught it. This spec has it from the first
commit.

Planted rather than reasoned - deleting the terrain freeze call site:

× consults every frozen row exactly once
AssertionError: distinct rows this run looked up: expected 22 to be 26
Tests  1 failed | 16 passed (17)

All 16 other tests stayed green. That is now the second spec where deleting
a freeze(...) call site was invisible to every pre-existing assertion, which is
the case the guard exists for and the one a frozenCount-against-a-literal
check would miss.

Verification

  • pnpm run verify green in 14m59s.
  • The record run and the planted run were separate; the planted run's 16 passing
    tests also confirm the other 22 frozen rows assert correctly.

After this, only wasmElevationRenderParity (333 lines) is left before entry 8
is done and the 43-file deletion is unblocked.

Refs #227.

🤖 Generated with Claude Code

https://claude.ai/code/session_015W4pLtEAk7Evo14mBkQ1HN

The second of the three render parity specs, using the machinery #350 added, so
this is the conversion only.

`vulcanus:render` holds 26 rows: 4 terrain windows, the 5 routed views, 4 rocks,
5 resources, 4 composite and 4 cliffs. Each was recorded only after the Rust and
TypeScript arms were compared and agreed. The Nauvis section came through the
re-record byte-identical, which is the merge behaviour `flushRecording` is meant
to have and is worth having seen rather than assumed.

The three `renderTiled` helpers are deliberately NOT frozen, checked rather than
assumed: every one of their `runRenderRequest` calls passes the engine, so they
compare tiled against whole rather than Rust against TypeScript. The deletion
leaves them grading exactly what they grade now.

The coverage guard is here from the start rather than added after review.
Planted: deleting the terrain `freeze` call site leaves **all 16 other tests
green** and is caught only by the guard, at "expected 22 to be 26". That is the
second spec where a deleted call site was invisible to every pre-existing
assertion.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015W4pLtEAk7Evo14mBkQ1HN
@wormeyman
wormeyman merged commit a14f5d8 into main Aug 30, 2026
9 checks passed
@wormeyman
wormeyman deleted the feat/227-freeze-vulcanus-render-parity branch August 30, 2026 01:07
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