--- name: a-release-note-baseline-is-the-last-release-not-the-lanes-previous-commit description: "Diff a release note against the LAST RELEASE, never against the previous commit in the lane — a defect a lane introduces and fixes within itself never reached a user, and a 'Previously' claim about it publishes a phantom regression the product never had" metadata: node_type: memory type: feedback --- 2026-09-09, v0.69.0 #287. I verified a respun member the right way and then reasoned from the wrong baseline. The respin 53f63c3a changed `clear_shell_pid` from a hard `?` error into a logged best-effort continue. I diffed it against fb18e94b — THE PREVIOUS COMMIT IN THE SAME LANE — found a real user-visible behaviour change (a close that aborted could leave a shell recorded ONLINE, tagged `[unit->REQ-HAZARD-SHELL-STALE-ONLINE]`), and proposed a third release bullet reading "Previously the close could fail and leave the shell still listed as online." todlando refused it: **fb18e94b introduced that abort within the UNRELEASED lane and 53f63c3a corrected it before release.** MEASURED after he said so: `clear_shell_pid` does not exist ANYWHERE in the shipped base de5a44bc — zero hits tree-wide. The strict-clear behaviour never shipped. My bullet would have told users the product used to do something it had never done. hertz had proposed a narrower version and withdrew that too on the same provenance. **Why it is seductive:** every OTHER check in this arc is correctly done against the lane's previous object — static half, tag locations, tree identity, "did the entry go stale when the sha moved". Those all compare sha to sha, and comparing sha to sha is exactly the habit that produces the wrong answer here. The release note is the one artifact whose baseline is not the previous commit but the last thing a user actually ran. **How to apply:** before writing any "Previously, X" clause, ask WHICH SHA the user is on and diff against THAT — the last published tag, not the branch's parent. A lane that breaks something and fixes it before release nets to zero in the notes; the correction belongs in the gate record and the commit history, never in a Fixed bullet. ⚠ **CORRECTED BY HERTZ WITHIN MINUTES OF BANKING THIS, and the original wording was a bad proof rule I would have trusted later.** I first wrote: "`git grep ` returning nothing is proof the behaviour never shipped, and it is one command." TWO FAULTS. 1. **Symbol absence is not behaviour absence.** The same behaviour can live under a different name or inline at the call site. A grep miss raises a question; it never settles one. Compare the BEHAVIOUR at the released sha — read the path — not the presence of an identifier. 2. **I used the wrong sha for my own rule.** I grepped `de5a44bc`, which is the MILESTONE'S LANE BASE (main's tip at intake), not the last released object. The last release was v0.68.0 = `a2f335f8`, and de5a44bc carries post-release commits on top of it. So the entry that exists to say "use the right baseline" demonstrated the error in its own evidence. **What actually settled #287** was neither: it was the BUILDER identifying the prior best-effort path plus the two commits that introduced and removed the abort inside the lane. Provenance from someone who can read the path beats a grep from someone who cannot. **Second correction in the same exchange, the familiar family:** my sentence also said the close now leaves the shell "stopped and marked offline", which asserts TERMINATION. The fix only stops an identity-clear error from aborting the remaining close steps; it does not guarantee the process died or that token retirement and offline publication cannot themselves fail. I had read a unit cell's assertions — which prove those outcomes FOR ITS FIXTURE — as a general guarantee. A cell proves its own case, never the universal. Kin: [[two-checks-corroborate-only-if-they-test-one-proposition]] (same root: leaning on evidence without checking what it actually reaches). ## THE SYMBOL-GREP HALF RECURRED WITHIN THE HOUR, IN A DIFFERENT CONTEXT — AND THAT IS THE REAL LESSON Twenty minutes after banking "symbol absence is not behaviour absence" above, I did it again. Asked to verify why two sibling e2e binaries were EXCLUDED from a fix census, I ran `grep -c 'bind('`, got zero on both, and reported "the shape genuinely does not apply, it was not an oversight." hertz: **both files call an `online_by_token` helper that invokes `api bind-shell`.** They bind. Zero literal matches excluded nothing. The real reasons are PATH FACTS and neither is greppable by name: gateway records the keeper BEFORE its only bind and never rebinds after relink; tunnel's in-process seed/broker/tunnel rig has no keeper and no reconciliation loop at all. Different reasons per file, both requiring a read. **Why the banked rule did not fire: I FILED IT UNDER "RELEASE NOTES".** The paragraph above is framed entirely as a release-note baseline problem, so when I was doing a TEST-CENSUS the rule was not in the room. This is the second time this session a rule of mine failed by being filed too narrowly — the backtick hazard was filed under "message bodies" and so did not fire for a `python -c` argument, and it corrupted a memory index. A rule scoped to the context where it was LEARNED does not fire in the context where it RECURS. **So state it by mechanism, context-free, and let it live here as the general form:** A GREP FOR A LITERAL TOKEN MEASURES SPELLING, NEVER BEHAVIOUR. Indirection defeats it every time — a helper, a wrapper, a re-export, a macro, a differently-named call site. Absence of the token is never evidence of absence of the behaviour; it is evidence you have not looked yet. When the claim is about what code DOES, read the path or ask whoever wrote it. Reserve the grep for locating candidates to read, never for closing a question. Three instances in one night: an unbounded `fn +read_event` matching `read_event_until`, `clear_shell_pid` absent read as never-shipped, and `bind(` absent read as never-binds.