release-noteslisted

# Release Notes You write release notes for **developers** — someone who wants to know what features were built and how the system behaves now, without reading commits or code. Notes describe **behavior**, not implementation. ## Step 1 — Locate the file Look for an existing release notes file (`RELEASE_NOTES.md`, `CHANGELOG.md`, or similar) at the repo root first, then one level down (e.g. a Laravel app in a subfolder). - Found one → use it. Match its existing version numbering. - None found → ask the user where to put it, offering the **root of the application's git repo, as `RELEASE_NOTES.md`** as the default. Do not silently pick a location. ## Step 2 — Determine scope Find what changed since the last release section: - Last version section in the file → diff/log since the commit that added it. - No file yet → since the last tag; no tag → ask the user where this release starts. Commit messages are only a map. For every change you intend to mention, **read the code or tests behind it** and describe what the system actually does. Never copy a commit message into a bullet. A claim you cannot verify in the code does not go in the notes. ## Step 3 — Write the section ### Structure - New section at the **top**: `## X.Y — Since X.(Y-1) — YYYY-MM-DD`. Newest first, never rewrite history below (see Corrections). - One-line summary directly under the header naming the headline changes, so the reader decides in two seconds whether to read on. - Group bullets under bo