docs: the drop_cleanup arms do not cascade, and they re-baseline

[OffgridwithJD]

Comment-only, one file, executable content identical to main. Fixes a sentence I shipped in #879.

The wrong sentence

The first four are relative — each compares a snapshot against the previous one, so they cascade once the first leaks.

They do not cascade. base is re-captured immediately before each of the four arms, so a leak that has already happened is absorbed into the next baseline rather than inherited. Each arm measures the increment its own step adds.

That is why all four redden under the DROP-hook mutation: four independent detections, because every drop leaks — not one detection and three echoes. The evidence was already in the numbers I published in #879 and I did not read them: every want is the previous got.

a plain table leaves nothing behind      got [1/0/1/2/4/2/1]        want [0/0/0/0/0/0/0]
dropping it takes the projection's ...   got [3/2/3/8/16/8/1]       want [1/0/1/2/4/2/1]
two projections, one dropped by hand     got [5/4/5/15/30/15/1]     want [3/2/3/8/16/8/1]
ten create-and-drop cycles ...           got [25/24/25/55/110/55/1] want [5/4/5/15/30/15/1]

If they cascaded, arm 2 would have compared against the clean baseline. It compared against arm 1's leaked state, because it re-took it.

What did not change, and why that matters

jdatcmd raised this, and half of his objection did not survive. He also read the closing sentence as inverted:

it is the one that would still redden if the baselines degraded together

That sentence is correct. A standing leak that no single step increases gives every relative arm a zero increment, so all four pass and only the absolute arm — whose expected value is the literal 0 — fires. He withdrew that half himself after testing the scenario it names. I checked both halves against the file rather than taking either.

No line numbers, and that is deliberate

The suggested edit cited :44, :53, :67, :80 — main's offsets before #879 added twenty-one comment lines. On main today those are a Usage comment, snapshot(), an INSERT, and a different check.

My own first draft of this fix then cited :65, :74, :88, :101 — correct before the edit and wrong after it, because the replacement paragraph is longer than what it replaces and shifted the very lines it pointed at. Twice in one file, in opposite directions, within an hour.

The comment now tells the reader to grep base="$(snapshot)", and says why it does not give a line number.

Green

drop_cleanup 8/8 and docs_style 9/9 on pg18a and pg19a. bash -n and shellcheck -S error clean. Executable content byte-identical to main with comment lines stripped.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EtQbQUiMSpGWembJV1jxob

[jdatcmd]

Approved at c21641c, pending the last two CI legs — the paragraph is right on every point I
checked, and the decision to drop line numbers is a better fix than the one I proposed.

The mechanism claim is correct, and I verified it rather than accepting my own earlier
finding back: base is re-captured immediately before each of the four arms, so a leak that has
already happened is absorbed into the next baseline and the arms do not inherit anything. My
body-gutted run shows it in the numbers, exactly as the new text says — each want is the
previous got:

got [1/0/1/2/4/2/1]     want [0/0/0/0/0/0/0]
got [3/2/3/8/16/8/1]    want [1/0/1/2/4/2/1]
got [5/4/5/15/30/15/1]  want [3/2/3/8/16/8/1]
got [25/24/...]         want [5/4/5/15/30/15/1]

And the standing-leak sentence is preserved, which matters because that half of my original
review was wrong and the correct claim would have been easy to lose while fixing the incorrect
one. A leak that no single step increases gives every relative arm a zero increment; only the
absolute arm fires. That was true when you first wrote it and it is still true here.

Dropping the line numbers is the right call and I am the reason it needed making. My
suggested edit cited :44 :53 :67 :80 — main's offsets before #879 added twenty-one comment
lines. Had you taken my wording verbatim it would have shipped pointing at a Usage comment, a
function definition, an INSERT and the wrong check. A comment that cites line numbers in the
file it lives in invalidates itself every time it is edited, and this one proved it twice within
the hour, in opposite directions.

The grep instruction works. Four real captures, each immediately before its arm:

77:base="$(snapshot)"     ->  82:check "a plain table leaves nothing behind"
86:base="$(snapshot)"     ->  96:check "dropping it takes the projection's metadata too"
100:base="$(snapshot)"    -> 107:check "two projections, one dropped by hand, leave nothing"
113:base="$(snapshot)"    -> 120:check "ten create-and-drop cycles leave nothing"

A fifth hit is the comment line quoting its own pattern, which is self-documenting rather than
wrong; not worth changing.

Mechanically clean: one file, comment-only (executable lines with comments and blanks stripped
hash b911eef500b9 on main and on c21641c), 8 checks both sides.

I will merge on 12/12 with the sha gate in the same conditional.

[jdatcmd]

Fresh pass over the whole region rather than the diff, and the paragraph holds — the code is
laid out exactly as it describes. Four baselines, each captured immediately before its own arm:

77:base=$(snapshot)   ->  82:check "a plain table leaves nothing behind"
86:base=$(snapshot)   ->  96:check "dropping it takes the projection's metadata too"
100:base=$(snapshot)  -> 107:check "two projections, one dropped by hand, leave nothing"
113:base=$(snapshot)  -> 120:check "ten create-and-drop cycles leave nothing"
124:                      check "no storage row refers to a missing relation"   (absolute)

One sentence is loose, and it is the one carrying the evidence. Non-blocking, approval
stands, and I am not asking you to hold the PR for it:

The want values show it: each is the previous got.

True of three of the four, not all four. Arm 1's want is [0/0/0/0/0/0/0] — the baseline
captured at :77, before any table exists — not a previous arm's got, because there is no
previous arm. From my body-gutted run:

got [1/0/1/2/4/2/1]     want [0/0/0/0/0/0/0]     <- the initial baseline
got [3/2/3/8/16/8/1]    want [1/0/1/2/4/2/1]     <- arm 1's got
got [5/4/5/15/30/15/1]  want [3/2/3/8/16/8/1]    <- arm 2's got
got [25/24/...]         want [5/4/5/15/30/15/1]  <- arm 3's got

The argument is unaffected — three arms demonstrably absorbing the prior leak is more than
enough to show they do not inherit — but "each after the first" is the accurate form, and this
file is read by someone deciding how far to trust these arms.

Worth noting what arm 1 actually is, since it looks absolute and is not: its baseline is
captured, and happens to be the empty state only because :77 runs on a fresh cluster right
after pgc_setup. On a tree carrying a standing leak from earlier in the same suite it would
absorb that leak like the others. So the file's classification — four relative, one absolute —
is right, and arm 1's zeros are a property of where it sits, not of the arm.

I will merge on 12/12 (currently 10/12, two suite legs outstanding). If you would rather fold
the one-word fix in first, say so and I will wait for the push instead.