📝 Require a changelog note before finishing a branch

A merged branch must carry a final commit adding a short summary of the
work under [Unreleased] in CHANGELOG.md. create:release derives the bump
heuristic from that body, so notes have to exist before release day;
rationale in development/workflow.md.

development/workflow.md

@@ -49,6 +49,36 @@ plus hand-written `git`.
   merge and the next push. `create:branch` requires `main` to match its upstream
   and refuses until it is pushed; push `main` before starting the next branch.
 
+## Changelog notes
+
+The rule is in
+[CONTRIBUTING.md § Rules the tools don't enforce](../CONTRIBUTING.md#rules-the-tools-dont-enforce).
+
+#### Decision (2026-09)
+
+A merged branch carries its own summary under `[Unreleased]` in
+[CHANGELOG.md](../CHANGELOG.md), added before `create:finish`;
+`create:release` graduates it into the tagged section (see
+[publishing.md](./publishing.md)).
+
+#### Why
+
+- `create:release` derives the bump heuristic from the `[Unreleased]` body, so
+  the notes must exist before release day.
+- The contributor has fresh context; at release day the intent of a branch is
+  only its diff.
+- Gitmoji subjects are signposts, not semantic keys, so notes cannot be derived
+  from the history.
+
+#### Rejected
+
+- Generating notes from subjects at release time: subjects carry no parseable
+  type/scope (see § Commit messages).
+- The maintainer writing one summary during `create:release`: reconstruction
+  after the fact.
+- Enforcing it in `create:finish`: the front doors assert git state, not
+  content — and _notable_ is exactly the judgment a tool cannot make.
+
 ## Script prefix convention
 
 The prefix taxonomy is the rule, and it lives in