Errata: #4984's per-wave "charges" figure counts the ratchet's non-authoritative TELEMETRY rows (wave 10a frozen at 132; the charged population was 90)

[phasetr]

Measured while implementing wave 10a of #4984 (PR #5009).

What the freeze says vs what the ratchet charges

The wave 10a freeze comment
(#4984 (comment)) reports, for
its 74-file set:

metric	freeze	measured on the same commit
files	74	74
declarations	168	168
charges	132	90

The 168 matches exactly. The 132 does not: on main 7ea1cbdd the ratchet's
--findings output for those 74 files has 132 rows, but only 90 of them sit in the
authoritative ledger (32 NARROW_CHILD + 58 RELOCATION). The other 42 are rows printed
under the report's own banner

# TELEMETRY (NON-AUTHORITATIVE): ... These rows are NOT part of the population, are never
# pinned, and no verdict is computed from them.

i.e. purpose-only Narrow child module for <no placeable quantity> headers. Reproduce with

python3 scripts/header_inventory_claim_ratchet.py --findings > f.tsv
TEL=$(grep -n '^# TELEMETRY' f.tsv | cut -d: -f1)
head -n $((TEL-1)) f.tsv | grep -F -f <frozen file list> | wc -l   # 90
tail -n +$TEL      f.tsv | grep -F -f <frozen file list> | wc -l   # 42

The pin movement confirms the 90: the baseline went 453 charges / 362 keys ->
363 / 277 across wave 10a, i.e. -90 charges and -85 keys, with 0 rows of either kind
left on the 74 files.

Why it matters

The two numbers answer different questions and the freeze uses the larger one to size a
wave and to state its result. A wave whose files are mostly purpose-only headers will
report a charge figure well above what the ratchet can actually charge, and the PR body
that quotes it then states a number the --check output contradicts. Wave 9's PR body has
the mirror-image slip in the other direction: it says "68 rows cleared" where 68 is the
key delta (430 -> 362) and the charge delta was 70 (523 -> 453).

None of this affects any merged Lean content or any gate: --check,
--check-baseline-drift and the pin itself are all computed from the ledger alone and are
correct. What is wrong is the freeze/PR-body accounting layer.

Suggested resolution

State three separate figures per wave -- charged rows, telemetry rows, declarations -- and
derive the charged figure the way the ratchet does (rows above the # TELEMETRY banner),
rather than from a whole-file grep of --findings. Waves 10b-16 are not yet frozen with
new numbers, so the correction can be applied going forward; waves 1-9 are merged and their
bodies would need re-derivation from each freeze commit if the record is to be made exact.

[phasetr]

Recorded on the issue rather than only in the wave report: this is a recurrence of a
standing checklist item, not a newly discovered failure mode.

PR #5009's own "Accumulated lessons carried forward from waves 1-9" section already reads:

Wave 7/8: … freeze-time charge counts can conflate --findings rows with charges
— recount and correct in-body if the two diverge.

The wave 10a freeze
(#4984 (comment)) was written
after that lesson was recorded, and conflated them anyway — in the 74-file total (132 vs 90)
and in both per-family subtotals:

family	freeze "charges"	charged	telemetry	rows
HighTemperature* (50 files)	94	69	25	94
Mayer* (24 files)	38	21	17	38
total	132	90	42	132

So the prescribed remedy — "recount and correct in-body" — is a manual step that has now
been required at least twice, which is the signal that the fix belongs in the freeze
procedure rather than in each wave's PR body. The wave 10a body carries the corrected
numbers; this issue is about not needing to do that again in 10b and 11-16.

Incidental datum from the same recount, in case it is useful for sizing later waves: each
of the 74 files carried exactly one NARROW_CHILD anchor (32 charged + 42 telemetry = 74).
The telemetry share is therefore a direct measure of how many headers were purpose-only
(Narrow child module for <no placeable quantity>), which is a property of a family's
writing style — 50 % of the HighTemperature* NARROW_CHILD anchors here, 71 % of the
Mayer* ones. A family written in that style will always show a rows/charges gap, so the
gap is predictable at freeze time rather than something that has to be discovered at
implementation time.

[phasetr]

Disposition: closed as a record correction (post-campaign triage of #4984)

Authority: the user-authorized post-campaign disposition pass for #4984, decided by dual review
(dev-review + independent codex exec), Codex final per the user's standing instruction for
that pass. Reports: .self-local/reports/dev-review-4984-post-campaign-decision.md and
.self-local/reports/codex-4984-post-campaign-decision.log. Codex's ruling for this issue,
verbatim: "Correct the issue record and close administratively: #5012 and #5015. No repository PR
is warranted."

No repository file is changed by this closure, and none is needed: this issue never described a
defect in Lean content, in the ratchet ledger, or in any gate. Its subject is the freeze/PR-body
accounting layer.

The remedy this issue asked for was adopted, and is visible in the artefacts

The issue's suggested resolution was: state charged rows, telemetry rows, files and declarations as
separate figures, and derive the charged figure the way the ratchet does (rows above the
# TELEMETRY banner), not by a whole-file grep of --findings. That was applied from wave 11
onward:

• Wave 11 freeze (comment 5234929628): carries a section headed "Charged vs telemetry (per the
  Errata: #4984's per-wave "charges" figure counts the ratchet's non-authoritative TELEMETRY rows (wave 10a frozen at 132; the charged population was 90) #5012 recurring freeze-accounting bug — do not report raw ...)", and its live measurement line
  says "--findings, charged rows only; 3 telemetry NARROW_CHILD rows repo-wide are excluded
  from all counts below". It states explicitly that its figure "is the charged-row subtotal for
  the 14 files, not a raw grep line count on --findings' output (which would double-count
  header/comment lines and blur the charged/telemetry boundary)".
• Wave 12 freeze (comment 5235993986): same section, with a repo-wide per-class breakdown
  written as charged-vs-telemetry, and the same "not a raw grep" statement for its 37-charge figure.
• Waves 13, 14, 15 freezes (comments 5237904191, 5240159308, 5242298263): all report the charged
  population, not raw --findings rows.
• Wave 16 scope determination (comment 5248337884): the governance pass caught a recurrence of
  this issue's defect class in a new shape — a "95 files" figure that was actually the key
  count — and named it as such: "it is Errata: #4984's per-wave "charges" figure counts the ratchet's non-authoritative TELEMETRY rows (wave 10a frozen at 132; the charged population was 90) #5012's defect class recurring in a new shape ... which is
  exactly Errata: #4984's per-wave "charges" figure counts the ratchet's non-authoritative TELEMETRY rows (wave 10a frozen at 132; the charged population was 90) #5012's own suggested remedy".
• Wave 16 (final) freeze (comment 5248362466): section heading is literally "Four separate
  figures (per Errata: #4984's per-wave "charges" figure counts the ratchet's non-authoritative TELEMETRY rows (wave 10a frozen at 132; the charged population was 90) #5012's accounting-bug correction — charges/keys/files/declarations are NOT
  interchangeable)", giving charges 16 / keys 16 / files 16 / declarations 84, a charge-class
  breakdown, and an explicit disposition of the 3 telemetry rows.

So the correction is not merely acknowledged, it is embedded in every remaining freeze artefact of
the campaign, including the terminal one; and the campaign is now closed, so no further freeze
comment can reintroduce the defect.

What is deliberately NOT done, and will not be reopened by default

The issue's optional second half — re-deriving waves 1–9's merged PR and freeze bodies from each
freeze commit so that the historical per-wave record is exact — is declined. Those bodies are
historical prose about merged work; they feed no gate, no ledger, and no future wave. Re-deriving
them is exactly the class of large historical-prose cleanup that this post-campaign pass parked
elsewhere (#5014, #5028).

Reopen condition: only if the exact per-wave charged/telemetry split for waves 1–9 is ever
actually needed (e.g. an audit that must reconstruct the campaign's per-wave arithmetic from the
issue record alone), and then only under an explicitly authorized window.

Refs #4984