Seit 4.4.0 sammelte ein laufender Versionskandidat alle Bumps in einemCHANGES.md-Eintrag,
chronologisch und ungewichtet: version bump hängte den --title an die maschinenverwaltete <!-- wikitool:bumps -->-Liste, die Prosa wuchs darunter, und version release schloss den
Eintrag nur, kürzte ihn nicht. Bei 5.0.0 war das Ergebnis ein Eintrag über 20 Bumps und ~1440
Zeilen. Weil version notes genau diesen Eintrag ausgibt und .gitea/workflows/release.yml ihn
1:1 als Body der öffentlichen Release-Seite schreibt, war die Release-Notiz dieselbe Wand Text.
Ergebnis
Der Eintrag ist jetzt geschichtet statt eine Wand. Von oben nach unten:
Heading, **Author:**, **Breaking Change:**/**Migration:** - Letztere wandern über die
Bump-Liste, damit die für einen Operator wichtigste Zeile nicht unter einer langen Liste
verschwindet.
Die Bump-Liste, gruppiert nach **High/Medium/Low impact**, leere Gruppen entfallen.
Eine kurze Zusammenfassung, einmal zum Release geschrieben.
Je Bump ein ### <Bump-Titel>-Changeset, chronologisch - die Liste ist der Index dorthinein,
deshalb sind Listeneintrag und ###-Überschrift derselbe String.
version notes und release.yml blieben unangetastet: die Schichtung steckt im Text, nicht in
einem Ausgabefilter, also wurde die Release-Seite ohne Workflow-Änderung lesbar - nachprüfbar an
der v5.1.0-Seite, die dieser Umbau selbst erzeugt hat.
Entscheidungen (alle getroffen)
Ein Dokument, geschichtet - keine zweite kuratierte Datei, kein Ausgabefilter.
Geschlossene Einträge blieben unangetastet. Die Release-Seiten sind laut eigenem Footer
unveränderliche Snapshots, und instructions/dev/version-parts.md § Case study sowie docs/version-model.md zitieren den 2.0.0-Eintrag mit Abschnittsnamen. "Kürzer werden" gilt
für künftige Changeset-Prosa (Längennorm in version-parts.md Schritt 8), nicht rückwirkend.
Die Impact-Einstufung ist das Urteil der Sitzung, im Gespräch mit dem Nutzer - daher zwei
Zugriffe: --impact beim Bump (frisches Urteil) und version regrade für die Korrektur in
Hindsight. Ohne regrade wäre die Reihenfolge nach Invariante 1 unkorrigierbar, weil die Liste
maschinenverwaltet ist - dieselbe Begründung, aus der xref remove existiert. version-parts.md Schritt 7 verlangt jetzt, die gruppierte Liste dem Nutzer vor version release vorzulegen.
Die Zusammenfassung wird erzwungen, nicht erinnert - version release verweigert. Nicht in docs verify: das ist ein hartes Orakel ohne WARN, und eine bestehende Instanz mit eigenem
Changelog sähe es nach dem Update neu fehlschlagen - genau der Bruch, der bei der TOC-Pflicht 5.0.0 zu MAJOR gemacht hat.
Versionsteil: --minor, entschieden
5.0.1 -> 5.1.0. Neue Fähigkeit (--impact, version regrade), vorwärts wie rückwärts drop-in:
ein alter Tool-Stand parst die gruppierte Region weiter, weil die Titel-Extraktion auf - -Zeilen filtert und Gruppenüberschriften ignoriert - er verliert beim nächsten Rendern nur die
Noten, nicht die Titel.
Der Grenzfall war die neue Verweigerung in version release: ein Kommando bricht ab, das vorher
durchlief. Als MINOR entschieden, weil eine ausgelieferte Instanz keinen Release-Workflow hat
(.gitea/, DEVELOPMENT.md und instructions/dev/ werden nicht exportiert), das Heilmittel zwei
Sätze Prosa statt einer Migration sind, und die Ein-Bump-Ausnahme den häufigsten Fall ausschneidet.
Das Gegenargument stand wörtlich in tools/README.md Schritt 5 ("eine strengere Prüfung, die auf
Inhalt einer bestehenden Instanz neu fehlschlägt" als MAJOR-Kriterium) - deshalb ist diese
Formulierung mitgezogen worden: sie unterscheidet jetzt zwischen einer Prüfung, die auf ausgeliefertem, bereits vorhandenem Inhalt neu fehlschlägt (TOC-Fall, MAJOR), und einem Kommando,
das beim Aufruf mehr vom Aufrufer verlangt (MINOR). Ohne diese Präzisierung hätte sich der Baum
selbst widersprochen.
Akzeptanzkriterien
Ein mit version bump --impact aufgebauter Eintrag trägt seine Bump-Titel nach
High/Medium/Low gruppiert, und die Region liest sich nach einem weiteren Bump unverändert
zurück (Tests: test_bump_with_impact_grades_the_bump_and_a_follow_up_regroups_the_list, test_bump_entries_round_trips_through_bumps_block).
Tragen alle Bumps medium, bleibt die Region flach und ohne Gruppenüberschriften - wie der
vorige Stand sie schreiben würde (test_bumps_block_with_all_medium_renders_flat_like_before, test_bump_entries_reads_a_pre_impact_flat_region_as_all_medium). Das ist auch der Grund,
warum keine bestehende Region angefasst werden musste.
version regrade ändert jeden Grad des obersten Eintrags, ohne VERSION oder einen anderen
Teil von CHANGES.md zu berühren; ohne Argumente listet es Index und Grad
(test_regrade_writes_the_new_impact_and_leaves_version_untouched, test_regrade_lists_the_running_candidates_bumps).
version release bricht mit Exit 1 ab, wenn der Eintrag >= 2 Bump-Titel und keine
Zusammenfassung trägt, und schreibt dann weder VERSION noch CHANGES.md
(test_release_refuses_two_bumps_with_no_summary, test_release_dry_run_also_refuses_without_a_summary); ein Ein-Bump-Kandidat läuft durch
(test_release_passes_with_a_single_bump_and_no_summary).
**Breaking Change:**/**Migration:** stehen in einem neu geschriebenen Eintrag oberhalb der
Bump-Liste (test_breaking_line_sits_above_the_bumps_region), und ihre Reihenfolge
zueinander bleibt Breaking-vor-Migration.
version notes gibt den geschichteten Eintrag vollständig aus - ### -Überschriften brechen
die Extraktion nicht ab, weil deren Terminator ^## ist; release.yml ist unverändert und
hat die v5.1.0-Seite korrekt aus dem geschichteten Eintrag gebaut.
docs verify, instructions verify und pytest (1227 Tests) laufen grün; version regrade steht in beiden Tabellen von tools/CONTRACT.md (vom
Kommandotabellen-Check in beide Richtungen erzwungen).
instructions/dev/version-parts.md (§ The candidate model plus Schritte 5, 7, 8), DEVELOPMENT.md (Schritte 1, 2, 4), der CHANGES.md-Kopftext, stack-dev/SKILL.md
Schritt 4 und tools/README.md Schritt 5 beschreiben die neue Anatomie und den neuen
Ablauf; keine dieser Dateien nennt eine Issue-Nummer (docs verify prüft das für alles, was
ausgeliefert wird).
Der 5.1.0-Eintrag ist selbst in der neuen Anatomie geschrieben - erster Anwendungsfall und
Abnahme des Konzepts. Als Ein-Bump-Kandidat trägt er Liste plus Changeset-Prosa ohne separate
Zusammenfassung, also genau die Form, die die Ausnahme beschreibt.
Bewusst nicht gemacht
Kein Umbau geschlossener Einträge, insbesondere nicht des 5.0.0-Eintrags (Entscheidung 2).
Der bleibt ~1440 Zeilen lang; der Nutzen des Umbaus liegt bei künftigen Releases.
Keine Archiv-Aufteilung von CHANGES.md. Als Option erwogen und verworfen: sie hätte ownership.py, dist upgrade, version notes und docs verify die Zweiteilung beibringen
müssen, für einen Nutzen, den die Schichtung eines Eintrags schon liefert.
Keine neue docs/-Seite. Die Begründung der Schichtung sitzt in version-parts.md
§ The candidate model; eine fünfte docs/-Seite hätte zusätzlich in AGENTS.md § File naming
aufgezählt werden müssen. docs/version-model.md wurde in der Schlussphase geprüft und ist nicht veraltet: seine Begründung ist das Kandidatenmodell und was eine Nummer verspricht -
beides unberührt - und es delegiert die Prozedur ausdrücklich an version-parts.md.
Kein --summary-Flag und keine Änderung an version notes/release.yml/ dist_templates/CHANGES.md/docs_verify.py (Entscheidung 1; eine ausgelieferte Instanz hat
keinen Release-Workflow).
Nachzug aus der Schlussphase
instructions/gates.md und instructions/session-setup.md beschrieben die Budget-Ausnahme als
feste Liste pro Kommandoname. version regrade ist die erste Ausnahme, die nur in einer
Aufrufform liest - bar listet sie, mit Positionen schreibt sie -, weshalb sie nicht in SKIP_COMMAND_PATHS passt, sondern einen eigenen Zweig in is_exempt hat. Beide Stellen benennen
das jetzt; die Liste selbst bleibt an ihrem einen Ort (tools/CONTRACT.md). Eigener Patch-Bump,
weil instructions/ im Version-Gate der CI liegt: 5.1.1-beta.1, Commit dc688e5. Damit ist ein
Kandidat offen - der nächste Bump eskaliert ihn weiter, version release schließt ihn.
End-to-End im Scratch-Tree gegen eine Kopie von VERSION/CHANGES.md: drei Bumps mit
verschiedenen Graden, regrade-Listing, regrade einer Position, Verweigerung ohne
Zusammenfassung, Verweigerung bei zu kurzer Zusammenfassung (121 < 200 Zeichen), Durchlauf nach
dem Nachschreiben, version notes auf dem Ergebnis.
Release-Seite v5.1.0 geprüft: sie trägt den geschichteten Eintrag (gruppierte Liste, Prosa,
Snapshot-Footer) - das eigentliche Abnahmekriterium dieses Issues.
Zu dc688e5 liefen die Runs 263/264 beim Schließen noch. VERSION ist dort 5.1.1-beta.1, also
überspringt release.yml den Release-Job bewusst sauber; kein zweites Release.
Vom Nutzer im Anschluss an den 5.0.0-Release benannt: das Announcement sei "viel zu umfangreich
und zu groß", "das überblickt kein Mensch", das brauche "insgesamt ein besseres Konzept". Die
Richtung kam am 2026-09-12 nach: "changes.md darf auch kürzer werden, das changelog soll die punkte
nach impact/größe sortieren, plus etwas prosa und die vollständigen changesets hinten anhängen".
Die Einstufung selbst darf das LLM vornehmen und mit dem Nutzer diskutieren - daraus folgte die
Zweiteilung aus Entscheidung 3.
Modell-Handover
Design, Versionsteil und Grenzfall-Urteil (stack-dev Schritt 3): Opus 5.
Mechanische Mitte (Code, Tests, Doku-Nachzug, Version-Bump): Opus 5 - der Wechsel auf Sonnet
wurde angeboten und nicht gezogen.
Schlussphase (stack-close: Issue-Body, docs/-Prüfung, Nachzug-Bump): Opus 5.
**Status:** Umgesetzt und veröffentlicht am 2026-09-12 als `5.1.0` (Commit `1b0158f`, Release
<https://gitea.nehmer.net/torben/chemenu/releases/tag/v5.1.0>), plus ein Doku-Nachzug aus der
Schlussphase in `5.1.1-beta.1` (Commit `dc688e5`).
## Problem (behoben)
Seit `4.4.0` sammelte ein laufender Versionskandidat alle Bumps in *einem* `CHANGES.md`-Eintrag,
chronologisch und ungewichtet: `version bump` hängte den `--title` an die maschinenverwaltete
`<!-- wikitool:bumps -->`-Liste, die Prosa wuchs darunter, und `version release` schloss den
Eintrag nur, kürzte ihn nicht. Bei `5.0.0` war das Ergebnis ein Eintrag über 20 Bumps und ~1440
Zeilen. Weil `version notes` genau diesen Eintrag ausgibt und `.gitea/workflows/release.yml` ihn
1:1 als Body der öffentlichen Release-Seite schreibt, war die Release-Notiz dieselbe Wand Text.
## Ergebnis
Der Eintrag ist jetzt geschichtet statt eine Wand. Von oben nach unten:
1. Heading, `**Author:**`, `**Breaking Change:**`/`**Migration:**` - Letztere wandern **über** die
Bump-Liste, damit die für einen Operator wichtigste Zeile nicht unter einer langen Liste
verschwindet.
2. Die Bump-Liste, gruppiert nach `**High/Medium/Low impact**`, leere Gruppen entfallen.
3. Eine kurze Zusammenfassung, einmal zum Release geschrieben.
4. Je Bump ein `### <Bump-Titel>`-Changeset, chronologisch - die Liste ist der Index dorthinein,
deshalb sind Listeneintrag und `###`-Überschrift derselbe String.
`version notes` und `release.yml` blieben unangetastet: die Schichtung steckt im Text, nicht in
einem Ausgabefilter, also wurde die Release-Seite ohne Workflow-Änderung lesbar - nachprüfbar an
der `v5.1.0`-Seite, die dieser Umbau selbst erzeugt hat.
## Entscheidungen (alle getroffen)
1. **Ein Dokument, geschichtet** - keine zweite kuratierte Datei, kein Ausgabefilter.
2. **Geschlossene Einträge blieben unangetastet.** Die Release-Seiten sind laut eigenem Footer
unveränderliche Snapshots, und `instructions/dev/version-parts.md` § Case study sowie
`docs/version-model.md` zitieren den `2.0.0`-Eintrag mit Abschnittsnamen. "Kürzer werden" gilt
für künftige Changeset-Prosa (Längennorm in `version-parts.md` Schritt 8), nicht rückwirkend.
3. **Die Impact-Einstufung ist das Urteil der Sitzung, im Gespräch mit dem Nutzer** - daher zwei
Zugriffe: `--impact` beim Bump (frisches Urteil) und `version regrade` für die Korrektur in
Hindsight. Ohne `regrade` wäre die Reihenfolge nach Invariante 1 unkorrigierbar, weil die Liste
maschinenverwaltet ist - dieselbe Begründung, aus der `xref remove` existiert.
`version-parts.md` Schritt 7 verlangt jetzt, die gruppierte Liste dem Nutzer vor
`version release` vorzulegen.
4. **Die Zusammenfassung wird erzwungen, nicht erinnert** - `version release` verweigert. Nicht in
`docs verify`: das ist ein hartes Orakel ohne WARN, und eine bestehende Instanz mit eigenem
Changelog sähe es nach dem Update neu fehlschlagen - genau der Bruch, der bei der TOC-Pflicht
`5.0.0` zu MAJOR gemacht hat.
## Versionsteil: `--minor`, entschieden
`5.0.1 -> 5.1.0`. Neue Fähigkeit (`--impact`, `version regrade`), vorwärts wie rückwärts drop-in:
ein alter Tool-Stand parst die gruppierte Region weiter, weil die Titel-Extraktion auf
`- `-Zeilen filtert und Gruppenüberschriften ignoriert - er verliert beim nächsten Rendern nur die
Noten, nicht die Titel.
Der Grenzfall war die neue Verweigerung in `version release`: ein Kommando bricht ab, das vorher
durchlief. Als MINOR entschieden, weil eine ausgelieferte Instanz keinen Release-Workflow hat
(`.gitea/`, `DEVELOPMENT.md` und `instructions/dev/` werden nicht exportiert), das Heilmittel zwei
Sätze Prosa statt einer Migration sind, und die Ein-Bump-Ausnahme den häufigsten Fall ausschneidet.
Das Gegenargument stand wörtlich in `tools/README.md` Schritt 5 ("eine strengere Prüfung, die auf
Inhalt einer bestehenden Instanz neu fehlschlägt" als MAJOR-Kriterium) - deshalb ist diese
Formulierung mitgezogen worden: sie unterscheidet jetzt zwischen einer Prüfung, die auf
*ausgeliefertem, bereits vorhandenem* Inhalt neu fehlschlägt (TOC-Fall, MAJOR), und einem Kommando,
das beim Aufruf mehr vom Aufrufer verlangt (MINOR). Ohne diese Präzisierung hätte sich der Baum
selbst widersprochen.
## Akzeptanzkriterien
- [x] Ein mit `version bump --impact` aufgebauter Eintrag trägt seine Bump-Titel nach
High/Medium/Low gruppiert, und die Region liest sich nach einem weiteren Bump unverändert
zurück (Tests: `test_bump_with_impact_grades_the_bump_and_a_follow_up_regroups_the_list`,
`test_bump_entries_round_trips_through_bumps_block`).
- [x] Tragen alle Bumps `medium`, bleibt die Region flach und ohne Gruppenüberschriften - wie der
vorige Stand sie schreiben würde (`test_bumps_block_with_all_medium_renders_flat_like_before`,
`test_bump_entries_reads_a_pre_impact_flat_region_as_all_medium`). Das ist auch der Grund,
warum keine bestehende Region angefasst werden musste.
- [x] `version regrade` ändert jeden Grad des obersten Eintrags, ohne `VERSION` oder einen anderen
Teil von `CHANGES.md` zu berühren; ohne Argumente listet es Index und Grad
(`test_regrade_writes_the_new_impact_and_leaves_version_untouched`,
`test_regrade_lists_the_running_candidates_bumps`).
- [x] `version release` bricht mit Exit 1 ab, wenn der Eintrag >= 2 Bump-Titel und keine
Zusammenfassung trägt, und schreibt dann weder `VERSION` noch `CHANGES.md`
(`test_release_refuses_two_bumps_with_no_summary`,
`test_release_dry_run_also_refuses_without_a_summary`); ein Ein-Bump-Kandidat läuft durch
(`test_release_passes_with_a_single_bump_and_no_summary`).
- [x] `**Breaking Change:**`/`**Migration:**` stehen in einem neu geschriebenen Eintrag oberhalb der
Bump-Liste (`test_breaking_line_sits_above_the_bumps_region`), und ihre Reihenfolge
zueinander bleibt Breaking-vor-Migration.
- [x] `version notes` gibt den geschichteten Eintrag vollständig aus - `### `-Überschriften brechen
die Extraktion nicht ab, weil deren Terminator `^## ` ist; `release.yml` ist unverändert und
hat die `v5.1.0`-Seite korrekt aus dem geschichteten Eintrag gebaut.
- [x] `docs verify`, `instructions verify` und `pytest` (1227 Tests) laufen grün;
`version regrade` steht in **beiden** Tabellen von `tools/CONTRACT.md` (vom
Kommandotabellen-Check in beide Richtungen erzwungen).
- [x] `instructions/dev/version-parts.md` (§ The candidate model plus Schritte 5, 7, 8),
`DEVELOPMENT.md` (Schritte 1, 2, 4), der `CHANGES.md`-Kopftext, `stack-dev/SKILL.md`
Schritt 4 und `tools/README.md` Schritt 5 beschreiben die neue Anatomie und den neuen
Ablauf; keine dieser Dateien nennt eine Issue-Nummer (`docs verify` prüft das für alles, was
ausgeliefert wird).
- [x] Der `5.1.0`-Eintrag ist selbst in der neuen Anatomie geschrieben - erster Anwendungsfall und
Abnahme des Konzepts. Als Ein-Bump-Kandidat trägt er Liste plus Changeset-Prosa ohne separate
Zusammenfassung, also genau die Form, die die Ausnahme beschreibt.
## Bewusst nicht gemacht
- **Kein Umbau geschlossener Einträge**, insbesondere nicht des `5.0.0`-Eintrags (Entscheidung 2).
Der bleibt ~1440 Zeilen lang; der Nutzen des Umbaus liegt bei künftigen Releases.
- **Keine Archiv-Aufteilung von `CHANGES.md`.** Als Option erwogen und verworfen: sie hätte
`ownership.py`, `dist upgrade`, `version notes` und `docs verify` die Zweiteilung beibringen
müssen, für einen Nutzen, den die Schichtung eines Eintrags schon liefert.
- **Keine neue `docs/`-Seite.** Die Begründung der Schichtung sitzt in `version-parts.md`
§ The candidate model; eine fünfte `docs/`-Seite hätte zusätzlich in `AGENTS.md` § File naming
aufgezählt werden müssen. `docs/version-model.md` wurde in der Schlussphase geprüft und ist
*nicht* veraltet: seine Begründung ist das Kandidatenmodell und was eine Nummer verspricht -
beides unberührt - und es delegiert die Prozedur ausdrücklich an `version-parts.md`.
- **Kein `--summary`-Flag und keine Änderung an `version notes`/`release.yml`/
`dist_templates/CHANGES.md`/`docs_verify.py`** (Entscheidung 1; eine ausgelieferte Instanz hat
keinen Release-Workflow).
## Nachzug aus der Schlussphase
`instructions/gates.md` und `instructions/session-setup.md` beschrieben die Budget-Ausnahme als
feste Liste *pro Kommandoname*. `version regrade` ist die erste Ausnahme, die nur in einer
Aufrufform liest - bar listet sie, mit Positionen schreibt sie -, weshalb sie nicht in
`SKIP_COMMAND_PATHS` passt, sondern einen eigenen Zweig in `is_exempt` hat. Beide Stellen benennen
das jetzt; die Liste selbst bleibt an ihrem einen Ort (`tools/CONTRACT.md`). Eigener Patch-Bump,
weil `instructions/` im Version-Gate der CI liegt: `5.1.1-beta.1`, Commit `dc688e5`. Damit ist ein
Kandidat offen - der nächste Bump eskaliert ihn weiter, `version release` schließt ihn.
## Verifiziert
- Lokal: `pytest` (1227 grün), `tools/wikitool docs verify`, `tools/wikitool instructions verify`.
- End-to-End im Scratch-Tree gegen eine Kopie von `VERSION`/`CHANGES.md`: drei Bumps mit
verschiedenen Graden, `regrade`-Listing, `regrade` einer Position, Verweigerung ohne
Zusammenfassung, Verweigerung bei zu kurzer Zusammenfassung (121 < 200 Zeichen), Durchlauf nach
dem Nachschreiben, `version notes` auf dem Ergebnis.
- CI auf `1b0158f`: Runs 261 und 262 beide `success`
(<https://gitea.nehmer.net/torben/chemenu/actions/runs/261>,
<https://gitea.nehmer.net/torben/chemenu/actions/runs/262>) - also Testsuite, `docs verify`,
`instructions verify` und der `setup-instance.md`-Replay gegen einen frischen `dist export`, plus
der Release-Job, der Tag `v5.1.0`, Tarball und Prüfsumme erzeugt hat.
- Release-Seite `v5.1.0` geprüft: sie trägt den geschichteten Eintrag (gruppierte Liste, Prosa,
Snapshot-Footer) - das eigentliche Abnahmekriterium dieses Issues.
- Zu `dc688e5` liefen die Runs 263/264 beim Schließen noch. `VERSION` ist dort `5.1.1-beta.1`, also
überspringt `release.yml` den Release-Job bewusst sauber; kein zweites Release.
- Commits: `1b0158f` (12 Dateien, Mass-Update-Gate vom Nutzer freigegeben), `dc688e5` (4 Dateien).
## Herkunft
Vom Nutzer im Anschluss an den `5.0.0`-Release benannt: das Announcement sei "viel zu umfangreich
und zu groß", "das überblickt kein Mensch", das brauche "insgesamt ein besseres Konzept". Die
Richtung kam am 2026-09-12 nach: "changes.md darf auch kürzer werden, das changelog soll die punkte
nach impact/größe sortieren, plus etwas prosa und die vollständigen changesets hinten anhängen".
Die Einstufung selbst darf das LLM vornehmen und mit dem Nutzer diskutieren - daraus folgte die
Zweiteilung aus Entscheidung 3.
## Modell-Handover
- Design, Versionsteil und Grenzfall-Urteil (`stack-dev` Schritt 3): Opus 5.
- Mechanische Mitte (Code, Tests, Doku-Nachzug, Version-Bump): Opus 5 - der Wechsel auf Sonnet
wurde angeboten und nicht gezogen.
- Schlussphase (`stack-close`: Issue-Body, `docs/`-Prüfung, Nachzug-Bump): Opus 5.
Changelog: Body von Problembeschreibung mit vier offenen Fragen auf einen entschiedenen Umsetzungsplan umgeschrieben. Alle vier Fragen beantwortet (Nutzerentscheidung 2026-09-12): ein geschichteter Eintrag statt einer zweiten kuratierten Datei, geschlossene Einträge bleiben unangetastet, Impact-Note beim Bump plus version regrade für die Korrektur, Zusammenfassung wird von version release erzwungen. Neu im Body: Zielanatomie, sieben Tool-Änderungen inkl. des neuen Kommandos version regrade, Doku-Nachzug nach doc-pull-through.md, Testliste, Versionsteil-Empfehlung (--minor) mit dem Gegenargument aus tools/README.md Schritt 5. Die zwei grob formulierten Akzeptanzkriterien sind durch neun prüfbare ersetzt. kind/decision → kind/build, size/L → size/M (Designfragen sind beantwortet).
Nicht entschieden und als Kästchen offen: der Versionsteil. Punkt 6 des Plans (version release verweigert ohne Zusammenfassung) macht ein Kommando strenger, das vorher durchlief - version-parts.md Schritt 4 verlangt dafür das Gespräch, bevor der Bump läuft.
**Changelog:** Body von Problembeschreibung mit vier offenen Fragen auf einen entschiedenen Umsetzungsplan umgeschrieben. Alle vier Fragen beantwortet (Nutzerentscheidung 2026-09-12): ein geschichteter Eintrag statt einer zweiten kuratierten Datei, geschlossene Einträge bleiben unangetastet, Impact-Note beim Bump plus `version regrade` für die Korrektur, Zusammenfassung wird von `version release` erzwungen. Neu im Body: Zielanatomie, sieben Tool-Änderungen inkl. des neuen Kommandos `version regrade`, Doku-Nachzug nach `doc-pull-through.md`, Testliste, Versionsteil-Empfehlung (`--minor`) mit dem Gegenargument aus `tools/README.md` Schritt 5. Die zwei grob formulierten Akzeptanzkriterien sind durch neun prüfbare ersetzt. `kind/decision` → `kind/build`, `size/L` → `size/M` (Designfragen sind beantwortet).
Nicht entschieden und als Kästchen offen: der Versionsteil. Punkt 6 des Plans (`version release` verweigert ohne Zusammenfassung) macht ein Kommando strenger, das vorher durchlief - `version-parts.md` Schritt 4 verlangt dafür das Gespräch, bevor der Bump läuft.
Changelog: Body vom Umsetzungsplan auf den Abschlussstand umgeschrieben und geschlossen. Alle neun Akzeptanzkriterien abgehakt, jedes mit dem Test bzw. der Prüfung benannt, die es belegt. Das offene Kästchen "Versionsteil bestätigen" ist zur Entscheidung geworden: --minor (5.0.1 -> 5.1.0), mit der Begründung und dem mitgezogenen tools/README.md-Kriterium, das sonst dem Baum widersprochen hätte. Neu: § Ergebnis (die vier Schichten wie gebaut), § Bewusst nicht gemacht (geschlossene Einträge, Archiv-Aufteilung, neue docs/-Seite, --summary-Flag - je mit Grund), § Nachzug aus der Schlussphase (gates.md/session-setup.md: die Budget-Ausnahme von version regrade hängt an der Aufrufform, eigener Patch-Bump 5.1.1-beta.1), § Verifiziert (lokale Checks, End-to-End-Durchlauf, CI-Runs 261/262 grün, geprüfte v5.1.0-Release-Seite) und § Modell-Handover für alle drei Phasen.
docs/version-model.md wurde auf Veralterung geprüft und ist unverändert richtig - seine Begründung ist das Kandidatenmodell, nicht die Anatomie eines Eintrags.
**Changelog:** Body vom Umsetzungsplan auf den Abschlussstand umgeschrieben und geschlossen. Alle neun Akzeptanzkriterien abgehakt, jedes mit dem Test bzw. der Prüfung benannt, die es belegt. Das offene Kästchen "Versionsteil bestätigen" ist zur Entscheidung geworden: `--minor` (`5.0.1 -> 5.1.0`), mit der Begründung und dem mitgezogenen `tools/README.md`-Kriterium, das sonst dem Baum widersprochen hätte. Neu: § Ergebnis (die vier Schichten wie gebaut), § Bewusst nicht gemacht (geschlossene Einträge, Archiv-Aufteilung, neue `docs/`-Seite, `--summary`-Flag - je mit Grund), § Nachzug aus der Schlussphase (`gates.md`/`session-setup.md`: die Budget-Ausnahme von `version regrade` hängt an der Aufrufform, eigener Patch-Bump `5.1.1-beta.1`), § Verifiziert (lokale Checks, End-to-End-Durchlauf, CI-Runs 261/262 grün, geprüfte `v5.1.0`-Release-Seite) und § Modell-Handover für alle drei Phasen.
`docs/version-model.md` wurde auf Veralterung geprüft und ist unverändert richtig - seine Begründung ist das Kandidatenmodell, nicht die Anatomie eines Eintrags.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Status: Umgesetzt und veröffentlicht am 2026-09-12 als
5.1.0(Commit1b0158f, Releasehttps://gitea.nehmer.net/torben/chemenu/releases/tag/v5.1.0), plus ein Doku-Nachzug aus der
Schlussphase in
5.1.1-beta.1(Commitdc688e5).Problem (behoben)
Seit
4.4.0sammelte ein laufender Versionskandidat alle Bumps in einemCHANGES.md-Eintrag,chronologisch und ungewichtet:
version bumphängte den--titlean die maschinenverwaltete<!-- wikitool:bumps -->-Liste, die Prosa wuchs darunter, undversion releaseschloss denEintrag nur, kürzte ihn nicht. Bei
5.0.0war das Ergebnis ein Eintrag über 20 Bumps und ~1440Zeilen. Weil
version notesgenau diesen Eintrag ausgibt und.gitea/workflows/release.ymlihn1:1 als Body der öffentlichen Release-Seite schreibt, war die Release-Notiz dieselbe Wand Text.
Ergebnis
Der Eintrag ist jetzt geschichtet statt eine Wand. Von oben nach unten:
**Author:**,**Breaking Change:**/**Migration:**- Letztere wandern über dieBump-Liste, damit die für einen Operator wichtigste Zeile nicht unter einer langen Liste
verschwindet.
**High/Medium/Low impact**, leere Gruppen entfallen.### <Bump-Titel>-Changeset, chronologisch - die Liste ist der Index dorthinein,deshalb sind Listeneintrag und
###-Überschrift derselbe String.version notesundrelease.ymlblieben unangetastet: die Schichtung steckt im Text, nicht ineinem Ausgabefilter, also wurde die Release-Seite ohne Workflow-Änderung lesbar - nachprüfbar an
der
v5.1.0-Seite, die dieser Umbau selbst erzeugt hat.Entscheidungen (alle getroffen)
unveränderliche Snapshots, und
instructions/dev/version-parts.md§ Case study sowiedocs/version-model.mdzitieren den2.0.0-Eintrag mit Abschnittsnamen. "Kürzer werden" giltfür künftige Changeset-Prosa (Längennorm in
version-parts.mdSchritt 8), nicht rückwirkend.Zugriffe:
--impactbeim Bump (frisches Urteil) undversion regradefür die Korrektur inHindsight. Ohne
regradewäre die Reihenfolge nach Invariante 1 unkorrigierbar, weil die Listemaschinenverwaltet ist - dieselbe Begründung, aus der
xref removeexistiert.version-parts.mdSchritt 7 verlangt jetzt, die gruppierte Liste dem Nutzer vorversion releasevorzulegen.version releaseverweigert. Nicht indocs verify: das ist ein hartes Orakel ohne WARN, und eine bestehende Instanz mit eigenemChangelog sähe es nach dem Update neu fehlschlagen - genau der Bruch, der bei der TOC-Pflicht
5.0.0zu MAJOR gemacht hat.Versionsteil:
--minor, entschieden5.0.1 -> 5.1.0. Neue Fähigkeit (--impact,version regrade), vorwärts wie rückwärts drop-in:ein alter Tool-Stand parst die gruppierte Region weiter, weil die Titel-Extraktion auf
--Zeilen filtert und Gruppenüberschriften ignoriert - er verliert beim nächsten Rendern nur dieNoten, nicht die Titel.
Der Grenzfall war die neue Verweigerung in
version release: ein Kommando bricht ab, das vorherdurchlief. Als MINOR entschieden, weil eine ausgelieferte Instanz keinen Release-Workflow hat
(
.gitea/,DEVELOPMENT.mdundinstructions/dev/werden nicht exportiert), das Heilmittel zweiSätze Prosa statt einer Migration sind, und die Ein-Bump-Ausnahme den häufigsten Fall ausschneidet.
Das Gegenargument stand wörtlich in
tools/README.mdSchritt 5 ("eine strengere Prüfung, die aufInhalt einer bestehenden Instanz neu fehlschlägt" als MAJOR-Kriterium) - deshalb ist diese
Formulierung mitgezogen worden: sie unterscheidet jetzt zwischen einer Prüfung, die auf
ausgeliefertem, bereits vorhandenem Inhalt neu fehlschlägt (TOC-Fall, MAJOR), und einem Kommando,
das beim Aufruf mehr vom Aufrufer verlangt (MINOR). Ohne diese Präzisierung hätte sich der Baum
selbst widersprochen.
Akzeptanzkriterien
version bump --impactaufgebauter Eintrag trägt seine Bump-Titel nachHigh/Medium/Low gruppiert, und die Region liest sich nach einem weiteren Bump unverändert
zurück (Tests:
test_bump_with_impact_grades_the_bump_and_a_follow_up_regroups_the_list,test_bump_entries_round_trips_through_bumps_block).medium, bleibt die Region flach und ohne Gruppenüberschriften - wie dervorige Stand sie schreiben würde (
test_bumps_block_with_all_medium_renders_flat_like_before,test_bump_entries_reads_a_pre_impact_flat_region_as_all_medium). Das ist auch der Grund,warum keine bestehende Region angefasst werden musste.
version regradeändert jeden Grad des obersten Eintrags, ohneVERSIONoder einen anderenTeil von
CHANGES.mdzu berühren; ohne Argumente listet es Index und Grad(
test_regrade_writes_the_new_impact_and_leaves_version_untouched,test_regrade_lists_the_running_candidates_bumps).version releasebricht mit Exit 1 ab, wenn der Eintrag >= 2 Bump-Titel und keineZusammenfassung trägt, und schreibt dann weder
VERSIONnochCHANGES.md(
test_release_refuses_two_bumps_with_no_summary,test_release_dry_run_also_refuses_without_a_summary); ein Ein-Bump-Kandidat läuft durch(
test_release_passes_with_a_single_bump_and_no_summary).**Breaking Change:**/**Migration:**stehen in einem neu geschriebenen Eintrag oberhalb derBump-Liste (
test_breaking_line_sits_above_the_bumps_region), und ihre Reihenfolgezueinander bleibt Breaking-vor-Migration.
version notesgibt den geschichteten Eintrag vollständig aus -###-Überschriften brechendie Extraktion nicht ab, weil deren Terminator
^##ist;release.ymlist unverändert undhat die
v5.1.0-Seite korrekt aus dem geschichteten Eintrag gebaut.docs verify,instructions verifyundpytest(1227 Tests) laufen grün;version regradesteht in beiden Tabellen vontools/CONTRACT.md(vomKommandotabellen-Check in beide Richtungen erzwungen).
instructions/dev/version-parts.md(§ The candidate model plus Schritte 5, 7, 8),DEVELOPMENT.md(Schritte 1, 2, 4), derCHANGES.md-Kopftext,stack-dev/SKILL.mdSchritt 4 und
tools/README.mdSchritt 5 beschreiben die neue Anatomie und den neuenAblauf; keine dieser Dateien nennt eine Issue-Nummer (
docs verifyprüft das für alles, wasausgeliefert wird).
5.1.0-Eintrag ist selbst in der neuen Anatomie geschrieben - erster Anwendungsfall undAbnahme des Konzepts. Als Ein-Bump-Kandidat trägt er Liste plus Changeset-Prosa ohne separate
Zusammenfassung, also genau die Form, die die Ausnahme beschreibt.
Bewusst nicht gemacht
5.0.0-Eintrags (Entscheidung 2).Der bleibt ~1440 Zeilen lang; der Nutzen des Umbaus liegt bei künftigen Releases.
CHANGES.md. Als Option erwogen und verworfen: sie hätteownership.py,dist upgrade,version notesunddocs verifydie Zweiteilung beibringenmüssen, für einen Nutzen, den die Schichtung eines Eintrags schon liefert.
docs/-Seite. Die Begründung der Schichtung sitzt inversion-parts.md§ The candidate model; eine fünfte
docs/-Seite hätte zusätzlich inAGENTS.md§ File namingaufgezählt werden müssen.
docs/version-model.mdwurde in der Schlussphase geprüft und istnicht veraltet: seine Begründung ist das Kandidatenmodell und was eine Nummer verspricht -
beides unberührt - und es delegiert die Prozedur ausdrücklich an
version-parts.md.--summary-Flag und keine Änderung anversion notes/release.yml/dist_templates/CHANGES.md/docs_verify.py(Entscheidung 1; eine ausgelieferte Instanz hatkeinen Release-Workflow).
Nachzug aus der Schlussphase
instructions/gates.mdundinstructions/session-setup.mdbeschrieben die Budget-Ausnahme alsfeste Liste pro Kommandoname.
version regradeist die erste Ausnahme, die nur in einerAufrufform liest - bar listet sie, mit Positionen schreibt sie -, weshalb sie nicht in
SKIP_COMMAND_PATHSpasst, sondern einen eigenen Zweig inis_exempthat. Beide Stellen benennendas jetzt; die Liste selbst bleibt an ihrem einen Ort (
tools/CONTRACT.md). Eigener Patch-Bump,weil
instructions/im Version-Gate der CI liegt:5.1.1-beta.1, Commitdc688e5. Damit ist einKandidat offen - der nächste Bump eskaliert ihn weiter,
version releaseschließt ihn.Verifiziert
pytest(1227 grün),tools/wikitool docs verify,tools/wikitool instructions verify.VERSION/CHANGES.md: drei Bumps mitverschiedenen Graden,
regrade-Listing,regradeeiner Position, Verweigerung ohneZusammenfassung, Verweigerung bei zu kurzer Zusammenfassung (121 < 200 Zeichen), Durchlauf nach
dem Nachschreiben,
version notesauf dem Ergebnis.1b0158f: Runs 261 und 262 beidesuccess(https://gitea.nehmer.net/torben/chemenu/actions/runs/261,
https://gitea.nehmer.net/torben/chemenu/actions/runs/262) - also Testsuite,
docs verify,instructions verifyund dersetup-instance.md-Replay gegen einen frischendist export, plusder Release-Job, der Tag
v5.1.0, Tarball und Prüfsumme erzeugt hat.v5.1.0geprüft: sie trägt den geschichteten Eintrag (gruppierte Liste, Prosa,Snapshot-Footer) - das eigentliche Abnahmekriterium dieses Issues.
dc688e5liefen die Runs 263/264 beim Schließen noch.VERSIONist dort5.1.1-beta.1, alsoüberspringt
release.ymlden Release-Job bewusst sauber; kein zweites Release.1b0158f(12 Dateien, Mass-Update-Gate vom Nutzer freigegeben),dc688e5(4 Dateien).Herkunft
Vom Nutzer im Anschluss an den
5.0.0-Release benannt: das Announcement sei "viel zu umfangreichund zu groß", "das überblickt kein Mensch", das brauche "insgesamt ein besseres Konzept". Die
Richtung kam am 2026-09-12 nach: "changes.md darf auch kürzer werden, das changelog soll die punkte
nach impact/größe sortieren, plus etwas prosa und die vollständigen changesets hinten anhängen".
Die Einstufung selbst darf das LLM vornehmen und mit dem Nutzer diskutieren - daraus folgte die
Zweiteilung aus Entscheidung 3.
Modell-Handover
stack-devSchritt 3): Opus 5.wurde angeboten und nicht gezogen.
stack-close: Issue-Body,docs/-Prüfung, Nachzug-Bump): Opus 5.Changelog: Body von Problembeschreibung mit vier offenen Fragen auf einen entschiedenen Umsetzungsplan umgeschrieben. Alle vier Fragen beantwortet (Nutzerentscheidung 2026-09-12): ein geschichteter Eintrag statt einer zweiten kuratierten Datei, geschlossene Einträge bleiben unangetastet, Impact-Note beim Bump plus
version regradefür die Korrektur, Zusammenfassung wird vonversion releaseerzwungen. Neu im Body: Zielanatomie, sieben Tool-Änderungen inkl. des neuen Kommandosversion regrade, Doku-Nachzug nachdoc-pull-through.md, Testliste, Versionsteil-Empfehlung (--minor) mit dem Gegenargument austools/README.mdSchritt 5. Die zwei grob formulierten Akzeptanzkriterien sind durch neun prüfbare ersetzt.kind/decision→kind/build,size/L→size/M(Designfragen sind beantwortet).Nicht entschieden und als Kästchen offen: der Versionsteil. Punkt 6 des Plans (
version releaseverweigert ohne Zusammenfassung) macht ein Kommando strenger, das vorher durchlief -version-parts.mdSchritt 4 verlangt dafür das Gespräch, bevor der Bump läuft.Changelog: Body vom Umsetzungsplan auf den Abschlussstand umgeschrieben und geschlossen. Alle neun Akzeptanzkriterien abgehakt, jedes mit dem Test bzw. der Prüfung benannt, die es belegt. Das offene Kästchen "Versionsteil bestätigen" ist zur Entscheidung geworden:
--minor(5.0.1 -> 5.1.0), mit der Begründung und dem mitgezogenentools/README.md-Kriterium, das sonst dem Baum widersprochen hätte. Neu: § Ergebnis (die vier Schichten wie gebaut), § Bewusst nicht gemacht (geschlossene Einträge, Archiv-Aufteilung, neuedocs/-Seite,--summary-Flag - je mit Grund), § Nachzug aus der Schlussphase (gates.md/session-setup.md: die Budget-Ausnahme vonversion regradehängt an der Aufrufform, eigener Patch-Bump5.1.1-beta.1), § Verifiziert (lokale Checks, End-to-End-Durchlauf, CI-Runs 261/262 grün, geprüftev5.1.0-Release-Seite) und § Modell-Handover für alle drei Phasen.docs/version-model.mdwurde auf Veralterung geprüft und ist unverändert richtig - seine Begründung ist das Kandidatenmodell, nicht die Anatomie eines Eintrags.torben referenced this issue2026-09-15 07:37:53 +00:00