Repository navigation
SUPERSEDED/BLOCKED PARENT — retip 61,642 cell-count control - #106
Closed
d6g8k5htny-coder wants to merge 4 commits into
Closed
d6g8k5htny-coder wants to merge 4 commits into
d6g8k5htny-coder wants to merge 4 commits into
Conversation
…cards
`Ledger.reject` validated the kind, the reason and the boundary-area bound and
never the residual. `total()` skips every OUTSIDE cell with `continue` before
it reaches the branch that sums one. So a caller could reject a cell OUTSIDE
while handing over a non-zero residual: the number was stored on the record,
dropped from every total, and the run still reported itself sound.
Reproduced on a two-cell unit cover, one cell accepted at exactly 1 and the
other rejected OUTSIDE carrying [10**6, 10**6]:
total.certified True
total.covers_region True
total.caveats ()
certified_enclosure Interval(1, 1)
A certified enclosure of [1, 1] while holding a discarded possible
contribution of a million. THIS WAS A LIVE PATH. Nothing had to be mutated to
produce those four lines, which is what separates it from the recorded
surviving mutants in the same README.
`reject` now refuses a non-zero residual on an OUTSIDE cell. The two
statements cannot both be true: OUTSIDE asserts the cell is proved disjoint
from the region and therefore contributes exactly zero, so a non-zero possible
contribution denies the very rejection the call is recording. Whichever of the
two is wrong, the caller must say which rather than have the ledger keep both
and silently believe one.
The guard is scoped so it closes the hole without removing the feature:
`None` and an exact [0, 0] are still accepted on OUTSIDE, and EXCLUDED and
UNRESOLVED_BOUNDARY -- the two kinds whose residuals ARE summed -- still take
a non-zero one.
Controls 33 and 34 in `tests/test_cover.py` (retip of 1796d28, whose controls
were 41 and 42; the tip suite ended at 32, so 33 and 34 were free). Control 33
asserts the refusal and was confirmed to FAIL against a copy of the package
under the scratchpad with the guard deleted, never by editing the library.
Control 34 rebuilds the pre-guard record by hand and asserts the old behaviour,
so the defect stays demonstrable after the fix instead of surviving only as
prose. Source-branch tests that already occupied numbers 33-40 were not part
of 1796d28 and were not taken.
`research/cover/README.md` records it with the four lines above, under a
heading naming the date it was found.
This establishes no mathematics and closes nothing. `D3-LEMMA-RN-UNIF` Piece 1
and Piece 2 remain OPEN, every integrand here is still a labelled reference,
and no cell of the program's actual cover is certified. A ledger that refuses
to discard a number it was handed is not a cover certificate.
Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cz7WZybv8znP64SpPj6sWY
Co-authored-by: Dylan Roy <d6g8k5htny@privaterelay.appleid.com>
… review The guard is unchanged; its justification was wrong for a case it refuses. I wrote that a non-zero residual on an OUTSIDE cell and the rejection itself "cannot both be true". That holds for the witness that motivated the guard -- [10**6, 10**6] excludes zero, so it does deny "proved disjoint". It is false for a non-singleton enclosure that CONTAINS zero, such as [-eps, eps]: that is a conservative statement of a zero contribution, not a denial of OUTSIDE. Reported by the ChatGPT agent reviewing PR #38, who also reproduced the original witness independently at hardening 6f0f061 -- stored [1000000, 1000000], returned certified [1,1]. The contract stays exactly None or exactly [0, 0], now resting on the reason that is actually true of every value it refuses: total() DISCARDS an OUTSIDE cell's residual before it reaches the summing branch, so a residual of non-zero WIDTH loses the uncertainty it expresses, silently, even when it contains zero. Requiring exact zero makes the discard lossless. A caller who means "zero, conservatively" writes [0, 0]; a caller who means "possibly non-zero" is describing a cell that is not OUTSIDE. Changed in the three places that carried the bad argument -- the guard comment in research/cover/ledger.py, the docstring of control 41, and the README section -- each naming the review rather than quietly rewording. The error message now separates the two cases and gives the remedy for each: reject it UNRESOLVED_BOUNDARY or EXCLUDED if it can contribute, or say [0, 0] and carry the uncertainty on a cell whose residual survives. Also recorded from the same review, and NOT acted on here: research/cover/ ledger.py is pinned twice by research/rn/candidates/inner_wedge_20260920_v1 .json at 37974 bytes / 58ebe18f…, and hardening's copy matches that pin exactly. This edit must not be transported there. The migration branch's copy was already 37269 bytes against that pin, so this branch does not change the binding's status either way -- the hazard is entirely in the transport. The source-compatible integration on that side is an additive checked-total boundary, which catches strictly more than an input guard can. 10/10 checkers pass; 1,927 passed, 1 skipped. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cz7WZybv8znP64SpPj6sWY
`PolarRegion.uniform_cost` is this package's answer to RN5's "Treat the
near-axis refinement cost explicitly", and `research/cover/README.md` stakes
its standing on the distinction: "a count, not an estimate -- exact rationals,
no fit, no sampling". Its output is quoted as exact arithmetic in three places:
`docs/OPEN_PROBLEMS.md` A5 ("98 x 629 = 61,642 polar cells"),
`docs/FINDINGS_2026-09-18.md`, and the package README.
Control 18 checked the types, that `cells` is the product of the two step
counts, that the anisotropy is 50, and that a finer target costs more. None of
that constrains the contract the docstring states -- that the grid bounds the
cell diameter by `dr + r_hi*2*pi*dt <= target`. The published number was
pinned by nothing, and this survived all 48 tests:
regions.py:323 half = target_diameter / 2 -> half = target_diameter
Under it the annulus reports 49 x 315 = 15,435 cells rather than 61,642, and
the grid it describes has diameter bound 0.1997 against a target of 0.1: it
does not cover at the resolution it claims, and every document quoting 61,642
becomes false. Nothing failed.
Control 43 asserts, in exact rationals and never in float: the headline bound
at targets 1/10, 1/20 and 1/3; the even split by which it is achieved; each
count minimal for its own half-budget; the published 98 / 629 / 61,642; and
that the three documents still quote the figure, so prose and arithmetic
cannot drift apart in either direction.
ON MINIMALITY, because the first draft of this control asserted the wrong one
and failed: `uniform_cost` splits the budget EVENLY and solves each axis
against `target/2`, so each count is minimal FOR ITS HALF. The pair is NOT
jointly minimal over all (n_r, n_t) meeting the combined bound -- at target
1/3 the annulus reports 30 x 189 while 30 x 188 also satisfies it. Spending
less on one axis to spend more on the other is a different algorithm from the
one the docstring describes, and a test may not quietly demand it. The control
says so in place rather than leaving the weaker property to look like an
oversight.
Verified against a copy under the scratchpad, never by editing the library:
the mutation FAILS control 43 while control 18 still PASSES, which is the
whole point -- 18 was blind to it.
This establishes no mathematics. A cell count is a count; it certifies no
cell, and `D3-LEMMA-RN-UNIF` Piece 1 and Piece 2 remain OPEN.
11/11 checkers pass; 1,928 passed, 1 skipped.
Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cz7WZybv8znP64SpPj6sWY
Source commit 0552c28 added control 43. On this stack controls 33 and 34 are the OUTSIDE residual guard, so the next free number is 35. The test body is unchanged. Co-authored-by: Dylan Roy <d6g8k5htny@privaterelay.appleid.com>
Owner
Author
|
Closing with its blocked parent #104. This branch is stacked on a ledger edit that violates the documented byte-pin ruling; its unique 61,642 cell-count control can be reintroduced later as an isolated test-only successor on a compliant base if still useful. Do not merge this stacked head. Scientific effect NONE. |
8 of 13 tasks
Owner
Author
|
EXECUTING the already-recorded disposition from comment5837176738: close unmerged. This branch is stacked on the blocked pinned-ledger parent and must not be merged. Its unique 61,642 cell-count intent now has a compliant test-only successor in PR110. Preserve history; scientific effect NONE. |
d6g8k5htny-coder
changed the title
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.
Parked with #104. Do not merge.
Owner ruling: do not modify
research/cover/ledger.py, and do not re-pin it. The file must stay byte-identical to hardening @388a22caff13c449f0e3264b0aff314d456d6659(37974 bytes /58ebe18fbc3fc44e1ba9566e19494fbf906b8579e5dca96b414fb0f309d866c9).This head does not obey that ruling. It is stacked on #104 (
ec3b4260b07ea31fb7ebc7c6c7bd554d58622d81), so the diff against the hardening tip still editsresearch/cover/ledger.py. The commit unique to this PR is only the control 35 cell-count pin intests/test_cover.py. No follow-up was pushed. Restacking onto a wrapper that leavesLedger.rejectopen would not install the guard, and restacking onto the current #104 head keeps the pin broken.Why #104 cannot be rebuilt as an unpinned wrapper
Ledger.rejectassignsrec.residualwith no hook.Ledger.totaldiscards anOUTSIDEresidual before summing and can still returncertified=True. The driver callsledger.rejectdirectly. A new module underresearch/cover/can wrap those calls only for callers who opt in. It cannot makeLedger.rejectrefuse unless the method itself changes, or another always-imported module monkeypatches it. That is the stop condition: the check has to run inside a ledger method that has no hook.research/cover/audit.pychecked_totalalready refuses a non-canonicalOUTSIDEresidual at the publication boundary without editingledger.py. It does not change whatLedger.rejectorLedger.totaldo.What this head still is
Control 35, the
98 × 629 = 61,642uniform-cost pin, from draft #46, plus #104's commits until that PR changes. Superseded source: #46. This PR does not close #46. Draft. Base ischatgpt/drive-github-hardening-20260919, notmain.Base:
388a22caff13c449f0e3264b0aff314d456d6659. Head:3f14638783e47188344bff0f6c03f5ef56cb2cef.