CodeEraser 1.4.1
CodeEraser 1.4.1
Five defects, every one of them invisible to the gates that were supposed to see
it. Scores are fully comparable with 1.4.0 — no judged axis moved, no default
guard tier changed, the wire stays at 6.5.0 and the index schema at 15.
The shape they share
Most documentation in this repository is generated, and a byte gate compares each
file with its own generator. That catches a hand edit instantly and catches
nothing else. A generator that states a rule nobody executes, a form applied to
the wrong kind of value, a hand-written sentence with no chip on it — all of these
pass every gate in the repository while being wrong on the page. Four of the five
below were found by an adversarial audit reading for exactly that; the fifth the
benchmark replay found in itself.
The one that could break a run
CE.Scan.overCap sums six request dimensions against the scan row cap. The Rust
side priced five. The sixth, rowClasses, travels one entry per row and rides at
full chunk length, so it was sent and never charged.
The consequence is not a wrong number, it is a refusal: a large repository that
declares a [[rules.class]] gets its request answered degraded, and
scan/wire.rs turns that into cap mirror drift (scan/wire.rs vs Scan/Cost.hs) —
an error blaming a mismatch only we can fix. ce scan and ce check abort.
The module's own head comment claimed the caller paid for the class column by
reserving the override rows. That arithmetic never held: overrides is at most a
few rows per declared class, rowClasses is as long as the chunk. A row now costs
2 on a classed run and 1 otherwise, priced where the split is decided, with a leg
that pins both the halved capacity and the by-name refusal.
Three that a reader would have hit
edition 2,024. Both READMEs rendered the Rust edition through#digits, a
form built for the 4,096-row erase cap, which groups from 1,000. Editions are
named 2015 / 2018 / 2021 / 2024; with a comma it is not a valid value, and a
reader grepping the page for2024found nothing. There is now a#nameform —
an integer that names rather than counts — and the edition fact reads it. The
comma shipped in three releases.- The comparability sentence. 1.4.0's release notes, and two lines of the
CHANGELOG, all declared that scores are not comparable with 1.3.x. The sentence
in both READMEs that enumerates when scores stop being comparable listed only
a[[rules.class]]switch and the v1.2.0 → v1.3.0 submodule move. Someone
upgrading from 1.3.x and reading that page would have taken the recursion
increment for a regression in their own code. It is hand-written prose with no
chip on it, so no gate could have caught the omission. - Fourteen spaces. The refusal a file too large for a chunk receives lost its
line continuation when the block moved out ofwire.rs, so a deliberately named
refusal read like a broken build. The existing leg now asserts the text, not just
a keyphrase.
The benchmark series disobeyed its own page
docs/BENCH.md has said since 1.3.0 that a release joins the latency series only
when there is something new to measure — one that ships the same cli/src and
core/app as its predecessor gets no row, because replaying the whole series to
add a duplicate measurement publishes machine drift under a new version number.
Nothing executed that sentence. The backfill driver measured every tag.
So v0.7.1 and v1.0.1 had been in the published table all along, and the v1.4.0
replay was about to add v1.3.1 and v1.3.2. The rule now lives in the producer:
series_tags applies it before any subset filter and names every tag it turns
away. The series is 14 versions × 7 metrics = 98 rows, one sitting, one machine.
The same replay exposed a second defect in itself. Only recent tags were really
measured against their own core: v0.1.0's ce takes the core as a --core flag
defaulting to the bare name and reads CE_CORE_BIN only on its daemon path, so it
resolved whatever ce-core was installed on the machine. It now gets the tag's
core two ways, which is what makes the page's promise true for every row rather
than the recent ones.
Score comparability
Fully comparable with 1.4.0. git diff v1.4.0..v1.4.1 -- core/app is empty and
the only cli/src change is the chunk budget, which decides how a request is
split, not what it is worth. Comparability with 1.3.x and earlier is unchanged
from what 1.4.0 said: not comparable, on any repository that recurses.
Unsigned, on purpose
Code signing and notarisation stay out of scope (ADR-007/R1). The SHA-256 chain is
the permanent trust anchor: every asset is pinned in plugin/bin/manifest.env at
the release commit, the tag job verifies each pin before publishing, and
SHA256SUMS covers the set for offline checking. ce update reads the latest tag
and that tag's committed pins.