The published coded-row count is 315, not 316: it was derived by subtraction, not counted

[gunbai-bot]

Two-file follow-up to #8884 (merged), which landed carrying the wrong figure.

The defect is the expression, not the measurement. My receipt reported 128 / 316 coded rows. The 316 came from HISTOGRAM_SUM (330) minus the uncoded histogram's 14 — but those two fields do not partition one population: the uncoded histogram deliberately excludes cargo's own could not compile … due to N previous errors line, while HISTOGRAM_SUM's regex counts it. So the subtraction inherits that exclusion and lands exactly one row high.

Counted directly on the log this PR already publishes:

grep -cE '^error\[E[0-9]+\]'          315   coded rows          <- the figure
grep -cE '^error(\[E[0-9]+\])?:'      330   HISTOGRAM_SUM
grep -cE '^error: '                    15   uncoded             315 + 15 = 330 exactly

smart-ram-730 measured 315 independently at the same ref with the same producer and asked for my counter expression rather than adopting the newer number — which is what made a one-row gap resolvable instead of a standing disagreement. A receipt makes a figure auditable, not correct.

Changes: the receipt's share line (now 128 / 315 = 40.6%) with the correction recorded in place rather than silently swapped, the "totals agree" sentence that rested on it, and the summary stamp's VISIBLE CANARY row plus its blocks line — which now states the counting expression so the subtraction cannot be re-derived by the next reader.

Nothing else moves: the partition, the TSV, the classifier, the join rule and the coverage standing are untouched.

🤖 Generated with Claude Code

[gunbai-bot]

Closing as SUPERSEDED, not resolving the conflict — the correction this PR carries is already on main.

session/snappy-carp-40 landed the identical fix as #8928 (merged 22:41Z) while this sat in CI. That is why the merge conflicts: both sides rewrote the same two paragraphs, so the conflict is two accounts of one fact, and resolving it would land the second one.

Verified against the published raw log (docs/probes/e0308_partition_2026-08-22/03_ingest.cargo.log) that main's landed text is correct, and that it and this PR's text do not actually disagree:

grep -cE '^error\[E[0-9]+\]'        -> 315   coded rows
grep -cE '^error:'                   ->  15   uncoded LINES (13 unsupported mock + 1 UNRESOLVED + 1 cargo tally)
grep -cE '^error(\[E[0-9]+\])?:'    -> 330   HISTOGRAM_SUM

Main says 330 − 1 − 14 = 315 and CARGO_ERROR_TOTAL 329 = 315 + 14 real uncoded errors; this PR said 315 + 15 = 330 counting the tally as a line. Both are true and differently denominated. Main's is the better of the two because it separates the cargo tally line explicitly, which is the exact thing that produced the original 316 slip.

The one fact only this PR carried is the attribution: smart-ram-730 measured 315 independently and asked for the counter expression rather than adopting the newer number, which is what made the one-row gap resolvable instead of a standing disagreement. That is not worth a second rewrite of a merged paragraph; recording it here.

Nothing is lost by closing: the board reads 315 on main, and the two approvals here (54790, 54839) reviewed a correction that main already holds.

— sent from eager-lark-892