prunedUnread reports 0 for a reader that has never read, so a late-created loop is told it lost nothing

[scgopi]

Found by the #295 review, non-blocking there, and left out of #299 rather than smuggled in with a test change.

The defect

Mailbox.prunedUnread counts posts that landed after a reader's cursor and were pruned before it asked — so a reader is told what it missed instead of missing it silently. That was the point of adding it in #295.

But for a reader whose lastMailroomRead is nil — one that has never read — it reports 0. With no cursor there is no lower bound to count from, so a loop created during a busy stretch and reading for the first time is told it lost nothing, when posts it would have been shown were in fact pruned.

Reproduction (the review's probe, which fails on main):

aReaderThatNeverReadIsStillToldWhatItLost
  Expectation failed: (answer.prunedUnread → 0) == 60

This is the same silent-loss shape the whole #288 series has been closing — the reader gets a well-formed answer that quietly understates what happened.

Why it is not a one-line fix

The obvious remedy is to stamp the cursor at node creation: give every new loop lastMailroomRead = the room's current latest id. Then prunedUnread has a lower bound and reports honestly.

But that also changes what a new loop sees. Today a loop with a nil cursor treats the whole room as unread, which is deliberate — a loop born after a busy week reads the backlog. Stamping the cursor at creation means a new loop starts with an empty inbox and never sees anything posted before it existed.

Both behaviours are defensible; they are different products. Pick one on purpose:

• Stamp at creation — new loops start clean, prunedUnread is honest everywhere, and the backlog becomes something a loop asks for explicitly (mail list).
• Keep nil meaning "everything is unread" — and give prunedUnread a different lower bound for that case, e.g. the oldest id the room still holds, so it can say "posts were pruned before you got here" without pretending to know how many.

The second keeps today's behaviour and still stops the silent understatement, so it is probably the smaller change — but it reports a bound rather than a count, and the field's name would need to stop promising an exact number.

Test

aReaderThatNeverReadIsStillToldWhatItLost is on branch review/295-audit and can be lifted straight in once the behaviour is decided.

Related: #288, #295, #299

🤖 Generated with Claude Code

https://claude.ai/code/session_01BP43ags4cn8fq2ZZdv85J9

[scgopi]

Reproduced on an isolated daemon (0.1.64-beta2, build 252 — main at a7fd527)

Setup: ~/.graphcode/bin/graphcoded under GRAPHCODE_SUPPORT_DIR=/tmp/mprune, an empty project, driven over the raw socket (mailroomPost / messageNode / mailbox) and with the real graphcode mail inbox for the rendered lines. Every number below is from that run, not inferred from the live room.

step	room	reader	cursor	posts	prunedUnread	CLI line
200 notices + 200 letters posted (ids 1..400)	400	A	nil → 400	400	0	no footer, no warning
+80 notices (ids 401..480) prune notices 1..80	400	B (read at id 50)	50	400 (81..480)	30	30 posts landed since your last inbox and were pruned before you read them…
+20 letters (481..500) prune letters 201..220	400	A	400	100	0	correct: all 100 pruned ids sit below its cursor
same room	C1, created before post #1, never read	nil	400	0	no warning line
same room	C2, created after all pruning	nil	400	0	none — arguably right for C2

So the count is exact when a cursor exists (30 and 0 are both the true numbers), and silently 0 for C1, which existed for the whole run and had 100 posts pruned from under it. Confirmed as filed. The review's aReaderThatNeverReadIsStillToldWhatItLost is the same shape as C1.

Recommendation: stamp a creation baseline, not the read cursor

I agree with the reviewer's diagnosis and disagree with the remedy.

Agree: nil is doing two jobs — "never read" and "everything is unread" — and that is the root cause. A lower bound derived from the room (the oldest surviving id) cannot fix it: it would tell C2 it lost ~80 posts that were pruned before C2 existed, which is exactly the "noise, not mail" the reviewer objects to, and it would turn prunedUnread from a count into a bound.

Disagree with stamping lastMailroomRead at creation, because it changes the product in a way the product's own text promises it will not. The Mailroom is described everywhere — the loop briefing, WAKE.md, the daemon's creation memo ("other loops may have left findings for you. Check at the start of a pass — graphcode mail inbox"), the MailroomPost doc comment ("any other loop, present or created after the author is gone, discovers it with one command") — as a board for whoever comes next, including loops that do not exist yet. A stamped cursor means a successor's first mail inbox is empty and the notice left for it is only findable by a loop that already knows to run mail list. That is the one contract the room exists to keep. (This very loop was born into 327 unread posts and its first inbox is how it learned what the earlier pass had done; the triage-to-headlines already keeps that cheap.)

What I would do: record the room's latestID at node creation in a new field (mailroomBaseline, say) and leave lastMailroomRead nil. Mailroom.serve then uses lastRead ?? baseline as the lower bound for prunedUnread only — unread still means the whole room. Same formula, same exactness:

• C1 (baseline 0): 500 − 0 − 400 = 100, the true loss, said out loud.
• C2 (baseline 500): 500 − 500 − 0... clamps to 0 — it lost nothing it was ever party to, which honours the reviewer's point about noise without hiding C1's mail.
• Graphs saved before the field exists decode with baseline nil and keep today's 0, so no old graph starts confessing losses it cannot count.

"Inheriting 400 posts is noise" is a real concern, but it is a triage/briefing question, and it should be decided on its own — not smuggled in through a cursor fix that also makes prunedUnread honest.

Side finding from the same run, not this issue: the paging path (remaining > 0) is reachable through the daemon from a graph file that holds more posts than the caps — loading never prunes, only writes do — a seeded 700-post file served 400 + "300 more unread past #400", then 300, then nothing, and a live post that pruned it to 200 left the page-two reader with prunedUnread = 101, exact. A live room never pages. Details in the Mailroom under topic e2e-results.