stack: Changelog-Eintrag geschichtet - Impact-Gruppierung, version regrade, Zusammenfassungspflicht (schliesst #95)

Files changed:
- CHANGES.md
- DEVELOPMENT.md
- VERSION
- instructions/dev/stack-dev/SKILL.md
- instructions/dev/version-parts.md
- tools/CONTRACT.md
- tools/README.md
- tools/chemenu/commands/run_budget.py
- tools/chemenu/commands/version_cmd.py
- tools/chemenu/tests/test_run_budget.py
- tools/chemenu/tests/test_version_cmd.py
- tools/chemenu/version.py

CHANGES.md

@@ -25,13 +25,60 @@ names it with a `-beta.N` suffix (`## 4.4.0-beta.2 - <date> - <title>`), and
 every bump of that same candidate updates this one entry in place rather than
 opening another: the heading's version/date/title move, and the bump's
 `--title` joins a machine-managed `<!-- wikitool:bumps -->` list right under
-the entry's `**Author:**` line - written and read by `wikitool version bump`,
-never by hand. `wikitool version release` is what closes a candidate: it
-strips the suffix and turns the entry into an ordinary, suffix-free one,
-leaving the bump-title list as the record of what happened. A distributed
-instance never sees a `-beta.` version at all (`release.yml` only ever
-releases a fixed one), so this suffix and the list beneath it are a
-dev-checkout concern - readable here, never shipped as something to parse.
+the entry's `**Author:**`/`**Breaking Change:**`/`**Migration:**` lines -
+written and read by `wikitool version bump`, never by hand.
+
+That list is graded, not a flat chronological dump: each bump carries an
+impact (`--impact high|medium|low`, default `medium`), and the list renders
+grouped under `**High/Medium/Low impact**` headings - except when every bump
+so far is `medium`, where it stays flat with no headings at all, exactly as
+it always did before grading existed. `wikitool version regrade` corrects a
+grade after the fact, against a single read of the whole list. Below the
+list comes a short summary paragraph, written once at release time, and below
+that one `### <bump title>` changeset per bump, in chronological order -
+`wikitool version release` refuses to close a candidate that collected two or
+more bumps and has no summary there (a one-bump candidate is exempt, since its
+single changeset already reads as one). This layering exists because a
+long-running candidate's bump list, left flat and ungraded, grows unreadable
+as a release announcement - the concrete case that forced it was `5.0.0`, one
+entry across roughly 1440 lines.
+
+`wikitool version release` is what closes a candidate: it strips the suffix
+and turns the entry into an ordinary, suffix-free one, leaving the bump list,
+summary and changesets as the record of what happened. A distributed instance
+never sees a `-beta.` version at all (`release.yml` only ever releases a fixed
+one), so the suffix and everything below the heading are a dev-checkout
+concern - readable here, never shipped as something to parse.
+
+---
+
+## 5.1.0 - 2026-09-12 - changelog: Kandidaten-Eintrag nach Impact gruppiert, version regrade zur Nachkorrektur, version release verlangt eine Zusammenfassung
+
+**Author:** Torben Nehmer
+
+<!-- wikitool:bumps -->
+**High impact**
+- changelog: Kandidaten-Eintrag nach Impact gruppiert, version regrade zur Nachkorrektur, version release verlangt eine Zusammenfassung
+<!-- /wikitool:bumps -->
+
+Seit `4.4.0` sammelt ein laufender Kandidat alle Bumps in einem Eintrag; bei `5.0.0` wurde das
+mit 20 Bumps und ~1440 Zeilen unlesbar, weil die Liste chronologisch und ungewichtet war und die
+Release-Seite genau diesen Eintrag 1:1 uebernimmt (`version notes`, `release.yml`). Der Eintrag
+ist jetzt geschichtet statt einer einzigen Wand Text: `version bump --impact high|medium|low`
+(Default `medium`) graduiert jeden Bump, die Liste rendert nach High/Medium/Low gruppiert - ausser
+wenn alles `medium` ist, dann bleibt sie flach wie bisher, damit jeder alte Eintrag und jeder
+einfache Patch unveraendert bleibt. `version regrade` korrigiert eine Note im Nachhinein, gegen
+einen einzelnen Lesevorgang der ganzen Liste, bevor der Kandidat geschlossen wird. Direkt unter
+der Liste steht jetzt eine kurze Zusammenfassung, darunter je Bump ein eigener
+`### <Bump-Titel>`-Changeset-Absatz; `version release` verweigert das Schliessen eines Kandidaten
+mit zwei oder mehr Bumps, solange diese Zusammenfassung fehlt (ein Kandidat mit genau einem Bump
+ist ausgenommen - sein Changeset ist bereits die Zusammenfassung, wie hier). Geschlossene
+Eintraege wie der zu `5.0.0` bleiben in der alten Form stehen: die Release-Seiten sind laut
+eigenem Footer unveraenderliche Snapshots, und `instructions/dev/version-parts.md` sowie
+`docs/version-model.md` zitieren den `2.0.0`-Eintrag mit Abschnittsnamen.
+
+`--breaking`/`**Migration:**` sitzen jetzt oberhalb der Bump-Liste statt darunter, damit die fuer
+einen Operator wichtigste Zeile nicht unter einer moeglicherweise langen Liste verschwindet.
 
 ---