<!--
=============================================================================
DO NOT EDIT THIS FILE.

It's the immutable template that every release's notes file is copied
from. The CI gate on develop → main PRs (check-release-notes.yml)
expects this template to keep its placeholders intact, so the next
release author has a clean source to copy from.

For each release: copy this file to `.github/release-notes-<yyyymmdd>.md`
where <yyyymmdd> is the date the release is being prepared (e.g.
`release-notes-20260512.md`). Edit the copy, not this template.

After release, the dated file stays in the repo as a historical record
of that release's user-facing notes.
=============================================================================

@claude / future-me, when preparing a new release:

  1. cp .github/release-notes-template.md \
        .github/release-notes-$(date +%Y%m%d).md
  2. Read every file under `.changeset/*.md` (these get consumed at
     release time). Also skim the bits of `ornn-api/CHANGELOG.md` and
     `ornn-web/CHANGELOG.md` that landed since the previous tag if you
     want extra context.
  3. In the new dated file (NOT this template), replace each
     `(write here)` block below with a brief, user-facing summary.
     Drop an entire section if there's nothing for it.

Style rules:

  - One bullet = one product-level fact a user / agent developer
    actually cares about. 6–12 words. Plain prose.
  - Cluster purely-technical items (refactors, dep bumps, infra / CI,
    type fixes, internal renames) into a single trailing bullet per
    section:
      Fixed       → "Few technical bugs fixed"
      New Feature → "Technical enhancement"
      Changed     → "Technical enhancement"
    Don't expand the technical bucket into individual bullets.
  - No PR / issue refs, no version numbers, no author thanks, no
    "see #N" links. The CHANGELOG link at the bottom of the
    auto-generated release body already covers all of that.
  - English only. Tight.
  - If a section ends up with only the technical-bucket bullet, that's
    fine — keep it. If a section ends up with zero bullets (genuinely
    nothing happened in that bucket), delete the whole section
    including its heading.

How the workflow uses the dated file:

  - `.github/workflows/changeset-release.yml` State B finds the most
    recent `.github/release-notes-<yyyymmdd>.md` (this template is
    excluded), strips its leading HTML comment block, and uses the
    remaining prose as the GitHub Release body, with a CHANGELOG-link
    footer appended.
  - `.github/workflows/check-release-notes.yml` gates PRs to `main` on
    a dated file being present with all three sections and no
    `(write here)` placeholder. The PR can't merge until the gate is
    green.
-->

## Fixed

- (write here)

## New Feature

- (write here)

## Changed

- (write here)
