An old same-date save can make an otherwise current day-page load perform one unnecessary database reread when four newer memories already fill the visible limit. The page remains correct, but avoiding that read would reduce wasted work in the narrow case where a writer edits a memory older than the four Postlude can show.
Evidence
PR #26’s repair-verification probe returned four anniversaries from 2025 through 2022, then recorded a confirmed save for 2000-08-25. The freshness tracker treated the omitted 2000 entry as relevant because it shared the month and day, and completed after two reads even though that entry could not displace any visible result.
Failure scenario
One such confirmation costs one redundant read and succeeds. Several older confirmations landing across the bounded retry window could exhaust the three-read budget and show the existing fresh-read failure even though the visible four-entry result was already accurate. This is below the merge-blocking threshold for the single-reader app because normal navigation follows one confirmed save and pays at most one extra read.
Suggested verification
Teach the missing-dependency check to account for the returned anniversary limit and rank. Add a tracker test with four newer returned anniversaries plus an omitted older checkpoint, proving it accepts in one read, and retain the test where a newly eligible member inside the visible window forces a retry.
Found during repair verification for #26.
An old same-date save can make an otherwise current day-page load perform one unnecessary database reread when four newer memories already fill the visible limit. The page remains correct, but avoiding that read would reduce wasted work in the narrow case where a writer edits a memory older than the four Postlude can show.
Evidence
PR #26’s repair-verification probe returned four anniversaries from 2025 through 2022, then recorded a confirmed save for 2000-08-25. The freshness tracker treated the omitted 2000 entry as relevant because it shared the month and day, and completed after two reads even though that entry could not displace any visible result.
Failure scenario
One such confirmation costs one redundant read and succeeds. Several older confirmations landing across the bounded retry window could exhaust the three-read budget and show the existing fresh-read failure even though the visible four-entry result was already accurate. This is below the merge-blocking threshold for the single-reader app because normal navigation follows one confirmed save and pays at most one extra read.
Suggested verification
Teach the missing-dependency check to account for the returned anniversary limit and rank. Add a tracker test with four newer returned anniversaries plus an omitted older checkpoint, proving it accepts in one read, and retain the test where a newly eligible member inside the visible window forces a retry.
Found during repair verification for #26.