A 'new file appeared' watcher can fire on an auto-recovered log, not the user's new save

Pattern: a web app keeps an in-progress step log in localStorage and, on the next page load with the logging flag, POSTs any unsaved previous log to the server marked recovered: true. I had a watcher that waited for a new log file in the server's folder and then built a page from it.

Gotcha: the watcher fired as soon as the user REOPENED the page. The file was the recovered remnant of an earlier aborted attempt (7 steps, 46 s, refused by a busy backend), not the new recording. A file-count watcher can't tell them apart.

Fix: after the watcher fires, check the log before announcing it. Look at recovered, startedAt against when the user said they'd start, and the step count and duration. Then re-arm the watcher for the real save. A better watcher filters on content, not count: skip files with recovered: true, or require startedAt after a timestamp you note when the user says 'starting now'.

Side benefit: the recovered file's appearance is a reliable signal that the user has just reopened the app, which can be useful (e.g. to extend a resource hold).