USR369 feedback: (1) numbers were backwards -- my earlier backfill assigned #1 to the physically-first line in the file, which is the newest entry (file is newest-first). Reversed the whole scheme: new_id = (max_id+1) - old_id, so oldest=1 counting up to newest=158. Verified live: min=1, max=158, all 158 unique. Future new entries via nextAutoNumber() (max+1 across all lines) continue correctly past 158 regardless of file position. (2) Added the entry number to the edit-banner text at the top of the form itself ('Editing entry #N'), set dynamically in loadEntry()/reset in cancelEdit(), not just visible in the list row. (3) USR369 reported still hitting a save error after the v3.4 fix -- re-simulated the EXACT deployed doUpdate()/locateFreshLine logic against a genuinely fresh fetch of the live file and it succeeded cleanly; most likely explanation is a browser tab that was still running pre-v3.4 JS from before that fix landed (a file edit on the server doesn't retroactively update JS already loaded in an open tab) -- told USR369 directly to reload the page rather than asserting this without saying so.