CodeEraser 1.3.2

CodeEraser 1.3.2

The closeout release. The roadmap is gone — not deleted, ruled on — and what
took its place is a list of positions this product holds permanently.

The project is finished

The plan's K–L row named three deferred bundles: M (scoring and evaluation
items, plus product small items), N (distribution) and the four evidence
gates that would decide which guard classes may be promoted — 45 items in all.
All 45 are ruled not done. Not forgotten, not deferred indefinitely: the
1.3 shape is the finished shape, and everything after this is maintenance —
defect fixes, dependency and measured-figure updates, and the documentation that
follows them. Reviving any one of them takes a fresh plan, not an inherited one.

Clearing a deferred bundle in this repository could not mean deleting the
sentence that named it. Every deferral here was a named disposition with a
reason, so its end had to be one too.

What that means for a reader

Both READMEs' Roadmap and known limits is now Known limits, and the
reader-facing half of those 45 items is stated as permanent positions rather
than plans. Each one was re-derived from the tree the day it was written, not
copied from the frontier ledger — which is already wrong in at least one place:
the ledger says there is no in-app update channel, and ce update shipped in
1.3.0.

• Symbol-level liveness is an advisory and never a verdict — ce deadcode says
  so on its own last line.
• A guard class stays observe until it carries its own false-positive record.
• ce structure has no score floor, so that family reports and gates nothing.
• A release builds three targets — x86_64-windows, x86_64-linux,
  aarch64-macos. The plugin starter can resolve five: x86_64-macos and
  aarch64-linux have no pinned asset and fall back to a PATH ce or a source
  install. The site's install line used to say "Windows · Linux · macOS", which
  is true about operating systems and misleading about architectures; it now
  names the three keys that actually have assets.
• The Claude Code marketplace entry tracks main, not a release.

One gate that could not have caught what it was watching

After 1.3.1 published, four surfaces — both READMEs and both homepages — still
called 1.3.0 the latest version, and every byte gate over them was green. The
sentence is generated: it reads the newest version in the benchmark series, and
1.3.1 never joined that series because it changed no measured code. The gate
compares each file against its own generator, so a generator stating something
false is invisible to it.

The fix is not a corrected number. The heading now says only what was measured,
a derived sentence adds "the current release, vX, has no row of its own", and a
new assertion reads CARGO_PKG_VERSION — the only check in the repository that
consults the crate rather than the contract, so the two can disagree out loud.
docs/BENCH.md now also states the rule that was never written down: when a
release joins the series, and what the page owes a reader when it does not.

The demo leads with the finding

The in-repo demo runs one task twice, differing only by the hook. Its result was
twelve rows of prose labels; the five numbers that carry the point now open the
page — writes refused before the file existed 0 → 2, clone blocks left behind
4 → 0, duplicated doc segments 1 → 0, removals still owed 1 → 0, check score
952 → 979 — with the table kept below as detail. The homepage had never shown a
before/after at all. Both surfaces render from one row list through the existing
generator, so the site cannot quote a figure the README's table does not have.

ce deadcode judged the two new files dead the moment they existed, and it was
right: nothing linked them. The fix was to write the paragraph in
demo/README.md that explains them, not to add a link that would quiet the gate.

A performance proposal, measured and struck

A mention-universe fast path — an (mtime,size) prefilter with the content hash
as fallback — was ruled in, then measured before being built. A prefilter does
not turn the read into nothing; it turns the read into a stat. On this
repository's universe of 832 files and 10.29 MiB that is 155 ms of reading
against 32 ms of stat-ing, so the whole ceiling is 123 ms — roughly a tenth
of one warm command, and smaller than the two git ls-files questions that
precede it. It also lands on almost nothing: Advisory::Yes occurs exactly once
in the tree, so the gate, ce scan and the write-time hook never pay for the
pass at all. Against an ADR amendment, a per-file (mtime,size) column, and a
class of correctness risk the content hash does not have, it is struck.

Score comparability

Fully comparable with 1.3.0 and 1.3.1, and checkably so: git diff v1.3.1..v1.3.2 -- cli/src core/app is empty. The measurement side and the
judgment core did not move a line, the wire is untouched (proto 6.4.0, graph/1
6.4.0, index schema 15), and no default guard tier changed, so the FPR figures
stand where 1.2.0 left them. That is also why this is a patch and not a minor —
the version number describes the artifact, not the occasion.

Latency

No row was added, for the same reason as 1.3.1: the measured program is the same
program. A row per unchanged binary would publish machine drift under a version
number. The dashboard and
docs/BENCH.md
now also say when a release joins the series and what the page owes a reader when
it does not.

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, so it needs nothing published beyond this
release.