chemenu/raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md

Gitea Issue #41 — Issue-Management: Label-Schema und Body-als-Wahrheit-Konvention

Wörtliche Kopie des Issue-Threads von https://gitea.nehmer.net/torben/chemenu/issues/41, gezogen am 2026-09-02 nach dem Body-Rewrite, der die Umsetzung in 4.0.1 festhält. Autor aller Beiträge: torben. Erstellt 2026-09-02T20:48:56Z, zuletzt geändert 2026-09-02T21:13:11Z.

Labels zum Zeitpunkt der Kopie: area/process, kind/build, prio/blocking, size/M. Status: offen.

---

Issue-Body (Stand 2026-09-02T21:13:11Z)

Kontext

Bündelt die Ergebnisse einer Diskussion am 2026-09-02 über den Entwicklungsprozess dieses Repos, ausgehend von den Fallouts in #38, #30, #28, #7, #27. Bewusst das erste Issue, das umgesetzt wird - es setzt den Rahmen für die Bearbeitung aller anderen.

Stand: Label-Set steht in Gitea, das Schema ist seit 4.0.1 kanonisch in instructions/dev/issue-tracking.md (Commit c8c2385). Offen ist nur noch die Relabelung der verbliebenen Sachissues und eine kb/-Seite, die noch das alte Schema beschreibt.

Entscheidung 1: Issues bleiben Storage für eingehende Specs, mit schärferer Pflege

Ein eingehender Wunsch/Requirement bleibt Issue, nicht kb/-Seite - Issues sind ephemer und bilden Wünsche ab, kb/ bildet verifiziertes, dauerhaftes Wissen ab (unverändert gegenüber instructions/dev/issue-tracking.md).

Motivation für die verschärfte Pflege: Die Umsetzung der hier verhandelten Issues zieht sich über mehrere, oft zeitlich getrennte LLM-Sitzungen. Der Issue-Body ist der einzige Ort, der diese Sitzungen verbindet - er ist die Lifeline für das Agent-Memory. Eine Sitzung, die ein Issue neu öffnet, muss allein aus dem Body rekonstruieren können, was entschieden ist und was noch offen ist, ohne dass ein Mensch den Kontext erneut vorkaut. Ein additiv wachsendes Log zwingt zum Lesen der ganzen Geschichte, um den aktuellen Stand herauszufiltern - ein aktuell gehaltener Body liefert ihn direkt. Das ist der eigentliche Grund für die folgenden drei Regeln, nicht Ordnung um der Ordnung willen.

• Body = aktuelle Wahrheit. Der Body wird aktiv umgeschrieben, wenn sich der Stand ändert - kein additives Anhängen an einen veralteten Ursprungstext.
• Kommentare = Changelog, nicht Kopie. Beim Body-Rewrite wird kein Volltext-Snapshot des alten Stands als Kommentar gesichert, sondern ein kurzer Changelog-Eintrag, der nur benennt, was sich gegenüber dem vorherigen Stand geändert hat - neu, entfallen, korrigiert. Eine Vollkopie pro Revision zwingt einen Menschen zum Diffen zweier Fließtexte und ist damit keine lesbare Historie, sondern nur eine weitere Kopie.
• Bearbeitung primär durch LLM. Menschen fassen in der Regel nur Labels/Metadaten direkt an; Body-Rewrites und Kommentare laufen über eine LLM-Sitzung.

Entscheidung 2: Vier Pflicht-Label-Familien statt zwei

Familie	Werte	Bedeutung
area/	kb, distribution, corpus, workflow, process	Welche Systemgrenze betroffen ist, entlang der bestehenden Stufenteilung aus AGENTS.md (kein area/tools - Tooling wird nach der Domäne eingeordnet, die es bedient, nicht nach Codeort)
size/	S, M, L (verdichtet von vier auf drei Stufen, XS entfällt)	Aufwand, unverändert in der Bedeutung von S/M/L
prio/	blocking, planned, waiting (Umbenennung von 1/2/3, Bedeutung unverändert)	Dringlichkeit, weiterhin fließend zu handhaben
kind/	decision, build, defect	Art der Offenheit: wartet auf eine Betreiberentscheidung, ist spezifiziert und wartet auf Umsetzungszeit, oder ist ein Befund über einen Widerspruch. Darf sich im Lauf eines Issues ändern (z.B. decision → build, sobald entschieden) - das ist erwünschtes Session-Memory-Verhalten, kein Makel

Alle vier sind Pflicht auf jedem offenen Issue, weil maschinelle Pflege durch das LLM den ursprünglichen Einwand gegen eine dritte/vierte Achse (Pflegeaufwand für einen einzelnen Menschen) entkräftet.

Entscheidung 3: Zwei optionale Status-Flags

• status/blocked - wartet auf ein anderes, noch offenes Issue; unabhängig vom prio-Wert nicht eigenständig bearbeitbar. Nicht mandatory, weil es eine Beziehung zwischen Issues abbildet, keine Eigenschaft eines einzelnen.
• status/unconfirmed - gemeldeter Verdacht, noch nicht gegen tatsächliches Verhalten geprüft. Gilt für jeden kind-Wert, nicht nur defect. Solange gesetzt, sind size und prio vorläufig. Nach Triage: Flag entfernt und size/prio verbindlich gesetzt, oder Issue mit Begründung geschlossen (kein unbelegter Verdacht bleibt offen liegen - Analogie zu Invariante 3 des Stacks, nur auf Prozessebene).

Migration der bestehenden Labels

prio/1 → prio/blocking, prio/2 → prio/planned, prio/3 → prio/waiting (reine Umbenennung). size/XS entfällt, size/S/M/L bleiben unverändert. area/*, kind/*, status/* sind neu. Erledigt - alle 16 Label stehen in Gitea.

Umgesetzt in 4.0.1

instructions/dev/issue-tracking.md ist auf das Schema umgeschrieben: Schritt 2 (Body als aktuelle Wahrheit inkl. Mehrsitzungs-Begründung), Schritt 3 (Changelog-Kommentar statt Vollkopie, mit Beispiel), Schritt 4 (alle vier Pflichtachsen als vier Tabellen), Schritt 5 (die beiden status/-Flags und der Triage-Ausgang), Schritt 6 (Re-Labeling schließt kind/-Wechsel ein). Der Entscheidungspunkt „Two labels feel too coarse?" ist entfallen, an seine Stelle treten zwei neue („Rewrite the body, or add a comment?" und der Umgang mit Altissues, die nur zwei Label tragen). Die Beschreibungszeile in instructions/dev/stack-dev/SKILL.md nennt jetzt die vier Achsen und die Body-Konvention.

PATCH und nicht MINOR, weil dist export instructions/dev/ vollständig ausschließt - für eine ausgelieferte Instanz ändert sich nichts. Gleiche Begründung wie bei 1.2.1, das das ursprüngliche Zweiachsen-Schema eingeführt hat.

Nicht in diesem Issue

Die Relabelung der bestehenden Sachissues erfolgt in deren jeweiligen Einzel-Sitzungen. Bereits umgestellt: #38, #27 (geschlossen), #7, #42.

kb/concepts/Issue Label Scheme.md beschreibt weiterhin das zweiachsige Schema von 2026-08-31 (prio/1..3, size/XS..L, „keine dritte Achse") und ist damit veraltet. Die Aktualisierung ist ein kb/-Schreibzugriff und braucht eine wiki-manage-Sitzung mit ordentlicher Quelle - nicht Teil dieses Issues.

Akzeptanzkriterien

• Label-Set in Gitea angelegt/umbenannt (dieses Issue)
• instructions/dev/issue-tracking.md in einer stack-dev-Sitzung um dieses Schema ergänzt (4.0.1, Commit c8c2385)
• Bestehende Sachissues nach und nach auf die vier Pflicht-Label umgestellt
• kb/concepts/Issue Label Scheme.md in einer wiki-manage-Sitzung nachgezogen
• Dieses Issue dient bis dahin als Referenz für das Schema

Vorgeschichte

Entschieden in der Diskussion vom 2026-09-02, im Rahmen einer Aufarbeitung von #38, #30, #28, #7, #27 als "Fallouts" des Entwicklungsprozesses. #39 und #40 liefen parallel und unabhängig, nicht Teil dieser Debatte.

---

Kommentar 1 (2026-09-02T20:57:51Z, issuecomment-512)

Changelog: Entscheidung 1, dritter Punkt korrigiert. Vorher: "Kommentare = Historie", der bisherige Body-Stand wird beim Umschreiben vollständig als Kommentar gesichert. Jetzt: "Kommentare = Changelog, nicht Kopie" - ein Kommentar nennt nur, was sich geändert hat, keine Volltextkopie des alten Bodys. Grund: eine Vollkopie pro Revision ist für einen Menschen nicht diffbar und damit keine brauchbare Historie.

Kommentar 2 (2026-09-02T21:07:47Z, issuecomment-539)

Changelog: Entscheidung 1 um Motivationsabsatz ergänzt (Body als Lifeline für Agent-Memory über mehrere Sitzungen hinweg, nicht Ordnung um der Ordnung willen). Akzeptanzkriterium 1 abgehakt, Referenzliste der bereits umgestellten Issues (#38, #27, #7, #42) ergänzt.

Kommentar 3 (2026-09-02T21:13:19Z, issuecomment-545)

Changelog: Akzeptanzkriterium 2 abgehakt - das Schema ist mit 4.0.1 (Commit c8c2385) kanonisch in instructions/dev/issue-tracking.md. Neu: Stand-Zeile im Kontext, Abschnitt „Umgesetzt in 4.0.1" (was genau in der Instruction steht, und warum PATCH), Vermerk „Erledigt" an der Label-Migration. Neu als offener Punkt und als fünftes Akzeptanzkriterium: kb/concepts/Issue Label Scheme.md beschreibt noch das Zweiachsen-Schema und braucht eine eigene wiki-manage-Sitzung. Entfallen: der Absatz „Die eigentliche Textänderung ... braucht eine separate stack-dev-Sitzung" - genau die ist jetzt gelaufen.

---

Label-Set in Gitea (gelesen 2026-09-02, label_read list_repo_labels)

Label	Beschreibung
area/kb	Betrifft kb/-Schema, Contract, Confidence, Lint, Wissensbasis
area/distribution	Betrifft Auslieferung, Upgrade, Versionierung einer Instanz
area/corpus	Betrifft Demo-/Testbett-Frage, Inhalt und Umfang von kb/
area/workflow	Betrifft Git, Merge, Branching, Publish, PRs
area/process	Betrifft den Entwicklungsprozess selbst, nicht den Stack als Artefakt
kind/decision	Wartet auf eine Betreiberentscheidung
kind/build	Spezifiziert, wartet nur noch auf Umsetzungszeit
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/S	Eine Sitzung, ein Publish, klar umrissener Schnitt
size/M	Mehrere Dateien, Contract- oder Instruction-Aenderung, eigener Testaufwand
size/L	Mehrere Sitzungen oder offene Designfragen vor dem ersten Commit
status/blocked	Wartet auf ein anderes, noch offenes Issue - nicht eigenstaendig bearbeitbar
status/unconfirmed	Gemeldeter Verdacht, noch nicht gegen tatsaechliches Verhalten geprueft - size/prio vorlaeufig

Sechzehn Label. size/XS, prio/1, prio/2 und prio/3 existieren nicht mehr.