torben/chemenu
1
1
Fork 0
Code Issues 26 Pull Requests Actions Packages Releases 32 Activity

Changelog-Kandidat-Eintrag wird bei langen Kandidaten unlesbar gross (v5.0.0: ~1440 Zeilen, ein Eintrag) #95

New Issue
Closed
opened 2026-09-11 18:12:05 +00:00 by torben · 2 comments
torben commented 2026-09-11 18:12:05 +00:00
Owner
Copy Link
Copy Source

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

  • 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.

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.
**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.
torben added the area/processkind/decisionprio/plannedsize/L labels 2026-09-11 18:12:08 +00:00
torben added size/Mkind/build and removed size/Lkind/decision labels 2026-09-12 15:55:09 +00:00
torben commented 2026-09-12 15:55:23 +00:00
Author
Owner
Copy Link
Copy Source

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.
torben commented 2026-09-12 16:30:30 +00:00
Author
Owner
Copy Link
Copy Source

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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/corpus
Betrifft Demo-/Testbett-Frage, Inhalt und Umfang von kb/
 area/distribution
Betrifft Auslieferung, Upgrade, Versionierung einer Instanz
 area/kb
Betrifft kb/-Schema, Contract, Confidence, Lint, Wissensbasis
 area/process
Betrifft den Entwicklungsprozess selbst, nicht den Stack als Artefakt
 area/workflow
Betrifft Git, Merge, Branching, Publish, PRs
 kind/build
Spezifiziert, wartet nur noch auf Umsetzungszeit
 kind/decision
Wartet auf eine Betreiberentscheidung
 kind/defect
Befund: Doku und Realitaet, oder zwei Dokus, widersprechen sich
 prio/blocking
Blockiert oder beschaedigt laufende Arbeit - als naechstes
 prio/planned
Traegt bald Zinsen - eingeplant
 prio/waiting
Sinnvoll, wartet auf einen Ausloeser
 size/L
Mehrere Sitzungen oder offene Designfragen vor dem ersten Commit
 size/M
Mehrere Dateien, Contract- oder Instruction-Aenderung, eigener Testaufwand
 size/S
Eine Sitzung, ein Publish, klar umrissener Schnitt
 status/blocked
Wartet auf ein anderes, noch offenes Issue - nicht eigenstaendig bearbeitbar
 status/incoming
Vom Menschen angelegte Anforderung, unvollständig, muss durch den Stack komplettiert werden.
 status/unconfirmed
Gemeldeter Verdacht, noch nicht gegen tatsaechliches Verhalten geprueft - size/prio vorlaeufig
No Label area/process kind/build prio/planned size/M
Milestone
No items
No Milestone
Assignees
Clear assignees
torben
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: torben/chemenu#95
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?