change-log-release-notes

Append a timestamped entry to a dated log file after each change, recording the instruction, discovery, plan, files changed, and test results. Use one file per day and keep the log append-only so prior entries are never overwritten.

Read only the relevant daily log files for the release period, group changes into Features, Improvements, Bug Fixes, Security, and Known Issues, then rewrite each item in plain user-facing language. Never include items that do not appear in the logs.

Each entry should contain a timestamp, the user instruction, searches run and what was found, the plan, files changed with one-line summaries, test results, and any risks or TODOs. Keep entries factual and concise.

State that there are no recorded changes for that period rather than guessing or inventing items. Release notes must derive solely from the logs, so missing logs mean no notes can be produced.

Log internal refactors as usual, but in release notes summarize them as improvements without exposing internal details or file paths. Security and auth changes should always be called out explicitly in their own section.