test(cliffs): the grid-4 channel HAS an oracle now, and it moves the defect (#84) - #106
Merged
Conversation
…defect (#84) The blocker was "the grid-4 cliff-elevation channel has no per-corner oracle at all". It needed no mod: the cliff generator is the readout, driven through `cliff_settings`. With `cliff_smoothing = 0` and `cliff_elevation_interval = 1e6`, `crossesCliff` collapses to `min(a,b) < e0 <= max(a,b)`, so one run is a 1-bit comparator on all 4,225 corners of a region at once and the entity's orientation says which side is high. The levels are the REAL bands (70 + 120k) rather than a uniform sweep, because that is the entire placement-relevant content of the channel - `crossesCliff` never compares the field against anything else. **`richness = 4` was never opening the gate.** `cliffiness_basic` is `clamp(0.5*log2(richness) + qmn, 0, 1) + 0.5`, so at richness 4 the clamp is `clamp(1 + qmn, 0, 1)` - still 0, gate still shut, wherever `qmn <= -1`. Routing the `cliffiness` property at the literal 1 places strictly more cliffs at 13 of 15 levels. Worse, richness 4 shifts the clamp by exactly +1, so the corners deciding that gate are the 8,409-of-12,675 the default field clamps flat - the population no fixture validates. Both arms are captured. What it says: - `[0,0]` and `[-1200,800]` are **EXACT at every band, both arms** - same cells, same orientations, nothing spare, with nothing between the field and the placement. - `[1500,1500]` is exact at 310/430/550 and wrong at the HIGH bands (L790 36 wrong / 42 surplus, L910 22/41). Every cheap explanation is eliminated with a control: not the smoothing (off), not the gate (constant by construction, and the disagreement is LARGER there), not `fixImpossibleCells` (0 of 73 disputed cells have a code our repair changed), not the rejections (they cannot alter a neighbour's orientation), not the query window (centre-filtered), not a boundary tie (median 18.8, max 69.0 units from the level). The paradox that replaces it: at **72 of 73** disputed edges the game's OWN TILE channel straddles the level and agrees with our value. `multisample` cannot be the difference - at those corners our grid-4 and grid-1 variants are identical, and the two natural widenings of the min-filter score 791 and 735 wrong against 73. So it lives in the mountains branch of `vulcanus_elev` and the port does not model it at all. Vacuity: perturbing the field by 0.5 fails 6 of the spec's 8 tests. Item of #84; the issue stays open. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011DckiyMmb4zDPBV8NSyxTg
This was referenced Aug 3, 2026
wormeyman
added a commit
that referenced
this pull request
Aug 3, 2026
…lusion (#84) (#107) #106 concluded, from the band oracle, that the port's grid-4 cliff-elevation field is wrong at [1500,1500]'s high bands, and handed over "it lives in the mountains branch of vulcanus_elev". This sweep was run to quantify that. It refutes it. Sweeping `cliff_elevation_0` across [700,900] step 5 under the same collapsed rule turns each placed cell's orientation into one-sided constraints on its corners - a crossing at L says "this corner > L, that one < L" - so 41 levels bracket a corner to the step. Only POSITIVE observations are used, which is what makes it sound: an absent cliff is ambiguous (the lava/ore rejections drop whole cells) but a present crossing is not, because `fixImpossibleCellsSweep` only ever writes 0 and the rejections never touch the edge registers. - **996 of 998** two-sided brackets contain the port's value, mean bracket width **5.72**, in the worst region. - The other two miss by **6.7e-4** - the port sits ON a swept level, where the strict test yields no observation. The open endpoint, not an error. - At the disputed-edge corners: **26 of 26** bracketed ones contain it. So the field is exonerated by direct measurement, and the lattice is re-confirmed on the way: a wrong sampling site could not put 996 of 998 values inside 5-unit brackets. **Where #106 went wrong.** It established what the residual is NOT (not smoothing, not the gate, not the repair, not the rejections, not a boundary tie) and treated the field as the last man standing - but it never measured the game's field, only that OUR value sits a median 18.8 from the level. "Everything else is excluded, so it must be X" is only as good as the list, and the list was not closed. The lower bound was real; the attribution was not. Same shape as #88. What is left: across all 41 levels the game's code is the port's **minus edges** in **1231 of 1235** disputed cells. The lead is the coverage number - only 26 of 72 disputed corner slots get a bracket, and 661 of 1,659 corners in range get none, because the game emits nothing beside them. One chunk at L=790 shows it directly: cell 1634,1706.5 keeps its TIGHT edge (margin 5.9) and loses its WIDE one (margin 69), and the cell sharing that wide edge is absent from the game entirely. That points at the emission/rejection path - stated as a hypothesis, with the control named. Determinism check: the two fixtures overlap at L=790 and agree 494/494. Vacuity: shifting the field by 10 fails 3 of the spec's 5 tests. Item of #84; the issue stays open. Claude-Session: https://claude.ai/code/session_011DckiyMmb4zDPBV8NSyxTg Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
wormeyman
added a commit
that referenced
this pull request
Aug 3, 2026
…ot worth capturing (#84) (#109) #108's handoff proposed ~40 more headless captures - "a sweep well outside [700,900] is the measurement that would close the gap". Don't capture it. `oracle-vulcanus-cliff-bands`'s constant1 arm already covers the SAME region under the SAME collapsed rule at 70..1150, so its observations fold straight into the fine sweep's and answer the question for free. **The field's exoneration is much wider than #107 stated.** That PR checked 998 two-sided brackets and left the ONE-SIDED bounds unused - but those falsify just as well, since "this corner is above 910" is refuted by a port value of 800. **1,711 one-sided bounds, 0 contradicting the port.** **The silence is not the field running out of range.** Widening the window 5x rescues exactly **1** of the 681 corners the fine sweep left unbracketed. 294 corners whose port value sits in [700,900] get no constraint of any kind across all 50 levels, while the port asserts **8,906** crossings on their edges over the same levels - and there is not one of the 294 where the port is silent too. A field error would have to move those corners outside [70,1150] entirely AND leave all 1,711 one-sided bounds satisfied. **Two suppressor candidates refuted, each against a base rate:** | population | n | rock in box | default gate shut | | --- | --- | --- | --- | | matched (base) | 18654 | 7.03% | 46.0% | | surplus | 1200 | 10.58% | 51.4% | | wrong orientation | 693 | 5.05% | 44.9% | Rocks - `wouldCollide`'s unported ENTITY half, the obvious candidate - do not survive: 1.5x on the surplus is weak and the wrong-orientation cells are ANTI-correlated at 5.05% against 7.03%. A suppressor cannot be anti-correlated with half the defect it is supposed to cause. **The gate row is worth more than the refutation it came from.** It was a confound check, not a candidate: if routing `cliffiness` at a literal 1 had silently not taken, the whole residual would just be the gate. The game emits **8,588** cells the default gate would have blocked outright, so the routing genuinely opened it - the collapsed-rule oracle that #106, #107 and #108 all rest on is not confounded on this axis, which had never been checked. Excluded for the suppression now: the field (twice over), rocks, the cliffiness gate, the smoothing, the repair, and since #108 the STAGE. What remains is WHICH cells the game refuses, and the list is stated as open - #106's trap is available here, so the next candidate needs a positive measurement rather than promotion by elimination. Item of #84; the issue stays open. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ExK3ASs5i2KMm9NwWqnZuj
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.
Closes the blocker #84 named: the grid-4 cliff-elevation channel had no per-corner oracle. It needed no mod - the cliff generator is itself the readout.
With
cliff_smoothing = 0andcliff_elevation_interval = 1e6,crossesCliffcollapses tomin(a,b) < e0 <= max(a,b), so one run is a 1-bit comparator on all 4,225 corners of a region at once, andcliff_orientationsays which side is high. The levels are the real bands (70 + 120k), which is the entire placement-relevant content of the channel:crossesCliffnever compares the field against anything else.richness = 4was never opening the gateEvery collapsed arm since 2026-08-01 held the gate open that way.
cliffiness_basicisclamp(0.5*log2(richness) + qmn, 0, 1) + 0.5, so at richness 4 the clamp isclamp(1 + qmn, 0, 1)- still 0, gate still shut, whereverqmn <= -1. Routing thecliffinessproperty at the literal1places strictly more cliffs at 13 of 15 levels, by up to 135 at one.The second-order problem is worse: richness 4 shifts the clamp by exactly +1, so the corners that decide that gate are the ones the default field clamps flat - the 8,409-of-12,675 population no fixture validates. Both arms are captured for that reason.
What the oracle says
[0,0][-1200,800][1500,1500][1500,1500]constant-1 arm as wrong/surplus: L70 1/3, L190 2/2, L310 0/0, L430 0/0, L550 0/0, L670 8/5, L790 36/42, L910 22/41, L1030 2/2, L1150 2/2.Two of three regions reproduce the game's cliffs exactly with nothing between the field and the placement.
Every cheap explanation eliminated, each with a control
fixImpossibleCells- 0 of the 73 disputed cells have a code our repair changed. (It is also working: turning it off makes agreement worse, 44 wrong vs 33 at L790.)The paradox that replaces it
At 72 of 73 disputed edges the game's own tile channel straddles the level and agrees with our value (worst 18.9, almost all 0). So the game's cliff generator reads a field differing from the game's own
calculate_tile_propertieselevation there, while the port has the two equal.multisamplecannot be it: at those corners our grid-4 and grid-1 variants are identical, and the two natural widenings of the min-filter score 791 and 735 wrong against 73. It lives in the mountains branch ofvulcanus_elev(the only branch reaching 670+) and is region-local.Next: a fine level sweep (700..900 step 5 at
[1500,1500]) brackets the game's cliff-channel value per corner and turns "differs by at least 69" into the actual field. ~40 runs, no new machinery.Vacuity: perturbing the field by 0.5 fails 6 of the spec's 8 tests.
Item of #84; the issue stays open.
🤖 Generated with Claude Code
https://claude.ai/code/session_011DckiyMmb4zDPBV8NSyxTg