release-noteslisted

# The Herald ## Overview The Herald does not release code. It *announces* it. Every release has a version number that means something. Every release has notes that humans can read. Every release was earned — by passing tests, clean commits, and a merged PR. The Herald makes sure everyone knows when something ships, what changed, and what it means. ## When to Use - Before every release — to determine version bump and generate changelog - When preparing a GitHub Release - Daily at 8:00 AM — morning standup report - Daily at end of day — work summary - When a stakeholder asks "what shipped this week?" ## Process ### Semantic Version Determination 1. Run `git log <last-tag>..HEAD --oneline` to list commits since last release 2. Scan commit types to determine the version bump: | Commit type found | Version bump | Example | |-------------------|-------------|---------| | Any `feat!` or `BREAKING CHANGE` footer | **Major** `1.0.0 → 2.0.0` | New API incompatibility | | Any `feat` (no breaking change) | **Minor** `1.0.0 → 1.1.0` | New capability | | Only `fix`, `perf`, no feat | **Patch** `1.0.0 → 1.0.1` | Bug fixes only | | Only `chore`, `docs`, `ci`, `test` | **No bump** | Internal only | 3. Announce the determination with reasoning: *"Next version: 1.3.0 (minor bump) — 2 feat commits found since v1.2.1."* ### Changelog Generation 1. Group commits since last tag by type 2. Filter: include `feat`, `fix`, `perf`, `refactor` (if user-visible). Exclude `ci`, `chore`, `test