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

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

New Issue
Closed
opened 2026-09-02 20:48:56 +00:00 by torben · 6 comments
torben commented 2026-09-02 20:48:56 +00:00
Owner
Copy Link
Copy Source

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: vollständig umgesetzt. Label-Set steht in Gitea, das Schema ist seit 4.0.1 kanonisch in instructions/dev/issue-tracking.md (Commit c8c2385), kb/concepts/Issue Label Scheme.md ist nachgezogen (Commit 23e34a9), und alle offenen Issues tragen die vier Pflicht-Label. Offen ist nur noch die Entscheidung, ob dieses Issue geschlossen wird oder als Referenz stehen bleibt.

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.

Nachgezogen in kb/ (Commit 23e34a9)

kb/concepts/Issue Label Scheme.md beschreibt jetzt das Vierachsen-Schema, die beiden status/-Flags und die Body-als-Wahrheit-Konvention; das abgelöste Zweiachsen-Schema steht als Abschnitt „Historie" mit Diff-Tabelle daneben statt gelöscht zu werden. confidence_base von 0.70 auf 0.85.

Als Quelle dient dieser Thread selbst: Body und Changelog-Kommentare im Stand vom 2026-09-02T21:13Z, plus das gelesene Label-Set, liegen wörtlich als raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md und als kb/sources/Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md. Das Transkript der zugrundeliegenden Diskussion existiert nicht in raw/, was auf der Source-Seite unter „Nicht übernommen" vermerkt ist - die Quelle belegt das Ergebnis der Debatte, nicht ihren Verlauf.

Board vollständig umgestellt (2026-09-02)

Alle 21 offenen Issues tragen die vier Pflicht-Label. Die 15, die noch auf dem Zweiachsen-Stand waren, wurden nach Lektüre des jeweiligen Bodys eingeordnet, nicht nach Titel:

Issue area/ kind/
#40, #39, #36, #32, #16, #6, #5, #4 kb build
#35, #15 kb decision
#37 distribution decision
#23, #10 process build
#21 process decision
#29 process defect

#29 trug bis dahin als einziges Issue überhaupt kein size/ und hat size/S bekommen.

Zwei Einordnungen sind nicht selbsterklärend und deshalb hier festgehalten: #23 (Test erzwingt _WIKITOOL_ENV-Vollständigkeit) und #10 (Coverage-Reporting) sind area/process, obwohl sie Code unter tools/ anfassen - sie bedienen den Entwicklungsprozess, und die Regel lautet Einordnung nach bedienter Domäne, nicht nach Codeort. #36 und #32 sind area/kb, weil der MCP-Leseserver und die Ingest-Queue Zugangswege zur Wissensbasis sind, nicht Auslieferung einer Instanz; #37 ist dagegen area/distribution, weil dort ein lauffähiges Artefakt gebaut und in eine Registry geschoben wird.

Nicht in diesem Issue

Nichts mehr.

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 auf die vier Pflicht-Label umgestellt - alle 21 offenen Issues, 2026-09-02
  • kb/concepts/Issue Label Scheme.md in einer wiki-manage-Sitzung nachgezogen (Commit 23e34a9)
  • Entscheidung des Betreibers: schließen, oder als Referenz offen lassen? Das Schema steht kanonisch in instructions/dev/issue-tracking.md und dauerhaft in kb/concepts/Issue Label Scheme.md - eine Referenzfunktion dieses Issues ist damit nicht mehr nötig.

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.

## 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: vollständig umgesetzt.** Label-Set steht in Gitea, das Schema ist seit `4.0.1` kanonisch in `instructions/dev/issue-tracking.md` (Commit `c8c2385`), `kb/concepts/Issue Label Scheme.md` ist nachgezogen (Commit `23e34a9`), und alle offenen Issues tragen die vier Pflicht-Label. Offen ist nur noch die Entscheidung, ob dieses Issue geschlossen wird oder als Referenz stehen bleibt. ## 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. ## Nachgezogen in `kb/` (Commit `23e34a9`) `kb/concepts/Issue Label Scheme.md` beschreibt jetzt das Vierachsen-Schema, die beiden `status/`-Flags und die Body-als-Wahrheit-Konvention; das abgelöste Zweiachsen-Schema steht als Abschnitt „Historie" mit Diff-Tabelle daneben statt gelöscht zu werden. `confidence_base` von 0.70 auf 0.85. Als Quelle dient dieser Thread selbst: Body und Changelog-Kommentare im Stand vom 2026-09-02T21:13Z, plus das gelesene Label-Set, liegen wörtlich als `raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md` und als `kb/sources/Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md`. Das Transkript der zugrundeliegenden Diskussion existiert nicht in `raw/`, was auf der Source-Seite unter „Nicht übernommen" vermerkt ist - die Quelle belegt das Ergebnis der Debatte, nicht ihren Verlauf. ## Board vollständig umgestellt (2026-09-02) Alle 21 offenen Issues tragen die vier Pflicht-Label. Die 15, die noch auf dem Zweiachsen-Stand waren, wurden nach Lektüre des jeweiligen Bodys eingeordnet, nicht nach Titel: | Issue | `area/` | `kind/` | |---|---|---| | #40, #39, #36, #32, #16, #6, #5, #4 | `kb` | `build` | | #35, #15 | `kb` | `decision` | | #37 | `distribution` | `decision` | | #23, #10 | `process` | `build` | | #21 | `process` | `decision` | | #29 | `process` | `defect` | #29 trug bis dahin als einziges Issue überhaupt kein `size/` und hat `size/S` bekommen. Zwei Einordnungen sind nicht selbsterklärend und deshalb hier festgehalten: **#23** (Test erzwingt `_WIKITOOL_ENV`-Vollständigkeit) und **#10** (Coverage-Reporting) sind `area/process`, obwohl sie Code unter `tools/` anfassen - sie bedienen den Entwicklungsprozess, und die Regel lautet Einordnung nach bedienter Domäne, nicht nach Codeort. **#36** und **#32** sind `area/kb`, weil der MCP-Leseserver und die Ingest-Queue Zugangswege zur Wissensbasis sind, nicht Auslieferung einer Instanz; **#37** ist dagegen `area/distribution`, weil dort ein lauffähiges Artefakt gebaut und in eine Registry geschoben wird. ## Nicht in diesem Issue Nichts mehr. ## Akzeptanzkriterien - [x] Label-Set in Gitea angelegt/umbenannt (dieses Issue) - [x] `instructions/dev/issue-tracking.md` in einer stack-dev-Sitzung um dieses Schema ergänzt (`4.0.1`, Commit `c8c2385`) - [x] Bestehende Sachissues auf die vier Pflicht-Label umgestellt - alle 21 offenen Issues, 2026-09-02 - [x] `kb/concepts/Issue Label Scheme.md` in einer `wiki-manage`-Sitzung nachgezogen (Commit `23e34a9`) - [ ] Entscheidung des Betreibers: schließen, oder als Referenz offen lassen? Das Schema steht kanonisch in `instructions/dev/issue-tracking.md` und dauerhaft in `kb/concepts/Issue Label Scheme.md` - eine Referenzfunktion dieses Issues ist damit nicht mehr nötig. ## 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.
torben added the area/processkind/buildprio/blockingsize/M labels 2026-09-02 20:50:40 +00:00
torben commented 2026-09-02 20:57:51 +00:00
Author
Owner
Copy Link
Copy Source

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.

**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.
torben commented 2026-09-02 21:07:47 +00:00
Author
Owner
Copy Link
Copy Source

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.

**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.
torben commented 2026-09-02 21:13:19 +00:00
Author
Owner
Copy Link
Copy Source

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.

**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.
torben commented 2026-09-02 21:21:31 +00:00
Author
Owner
Copy Link
Copy Source

Changelog: Akzeptanzkriterium 4 abgehakt - kb/concepts/Issue Label Scheme.md ist nachgezogen (Commit 23e34a9). Der Absatz „Nicht in diesem Issue" verliert damit seinen zweiten Punkt; die kb/-Seite beschreibt jetzt das Vierachsen-Schema, die beiden status/-Flags und die Body-als-Wahrheit-Konvention, das abgelöste Zweiachsen-Schema steht als Abschnitt „Historie" mit Diff-Tabelle daneben. Quelle dafür ist dieser Thread selbst: Body und Changelog-Kommentare liegen wörtlich als raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md und als Source-Seite im Korpus. Offen bleibt nur noch Kriterium 3, die Relabelung der verbliebenen Sachissues.

**Changelog:** Akzeptanzkriterium 4 abgehakt - `kb/concepts/Issue Label Scheme.md` ist nachgezogen (Commit `23e34a9`). Der Absatz „Nicht in diesem Issue" verliert damit seinen zweiten Punkt; die `kb/`-Seite beschreibt jetzt das Vierachsen-Schema, die beiden `status/`-Flags und die Body-als-Wahrheit-Konvention, das abgelöste Zweiachsen-Schema steht als Abschnitt „Historie" mit Diff-Tabelle daneben. Quelle dafür ist dieser Thread selbst: Body und Changelog-Kommentare liegen wörtlich als `raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md` und als Source-Seite im Korpus. Offen bleibt nur noch Kriterium 3, die Relabelung der verbliebenen Sachissues.
torben commented 2026-09-02 21:26:19 +00:00
Author
Owner
Copy Link
Copy Source

Changelog: Akzeptanzkriterium 3 abgehakt - alle 21 offenen Issues tragen jetzt die vier Pflicht-Label. Neu: Abschnitt „Board vollständig umgestellt" mit der Zuordnungstabelle und der Begründung der beiden nicht selbsterklärenden area/-Einordnungen (#23/#10 als process trotz Code unter tools/; #36/#32 als kb gegen #37 als distribution). Der Abschnitt „Nicht in diesem Issue" ist leer geworden. Das letzte Kriterium ist umformuliert: aus „dient bis dahin als Referenz" wird eine offene Betreiberentscheidung, ob das Issue geschlossen wird - eine Referenzfunktion braucht es nicht mehr, seit das Schema kanonisch in der Instruction und dauerhaft in kb/concepts/Issue Label Scheme.md steht.

Zwei Beobachtungen aus der Umstellung, die eine prio/-Entscheidung wären und deshalb nicht von mir gesetzt wurden:

  • #32 (Ingest-Queue) trägt prio/waiting mit dem im Body benannten Auslöser „#19 muss stehen". #19 ist geschlossen, der Auslöser ist also gefeuert - nach Schritt 6 der Instruction wäre das ein Wechsel auf prio/planned.
  • #40 und #39 tragen prio/blocking, beschreiben aber Arbeit, die in 4.0.0 ausgeliefert wurde. Entweder sind Restkriterien offen, oder beide sind schließbar.
**Changelog:** Akzeptanzkriterium 3 abgehakt - alle 21 offenen Issues tragen jetzt die vier Pflicht-Label. Neu: Abschnitt „Board vollständig umgestellt" mit der Zuordnungstabelle und der Begründung der beiden nicht selbsterklärenden `area/`-Einordnungen (#23/#10 als `process` trotz Code unter `tools/`; #36/#32 als `kb` gegen #37 als `distribution`). Der Abschnitt „Nicht in diesem Issue" ist leer geworden. Das letzte Kriterium ist umformuliert: aus „dient bis dahin als Referenz" wird eine offene Betreiberentscheidung, ob das Issue geschlossen wird - eine Referenzfunktion braucht es nicht mehr, seit das Schema kanonisch in der Instruction und dauerhaft in `kb/concepts/Issue Label Scheme.md` steht. Zwei Beobachtungen aus der Umstellung, die eine `prio/`-Entscheidung wären und deshalb nicht von mir gesetzt wurden: - **#32** (Ingest-Queue) trägt `prio/waiting` mit dem im Body benannten Auslöser „#19 muss stehen". #19 ist geschlossen, der Auslöser ist also gefeuert - nach Schritt 6 der Instruction wäre das ein Wechsel auf `prio/planned`. - **#40** und **#39** tragen `prio/blocking`, beschreiben aber Arbeit, die in `4.0.0` ausgeliefert wurde. Entweder sind Restkriterien offen, oder beide sind schließbar.
torben commented 2026-09-02 21:32:19 +00:00
Author
Owner
Copy Link
Copy Source

Geschlossen. Alle vier Akzeptanzkriterien sind umgesetzt: Label-Set in Gitea (16 Labels, vier Pflicht- plus eine optionale Familie), Schema kanonisch in instructions/dev/issue-tracking.md (4.0.1, Commit c8c2385), kb/concepts/Issue Label Scheme.md nachgezogen (Commit 23e34a9), alle 21 offenen Issues auf die vier Pflicht-Label umgestellt.

Nicht umgesetzt wurde nichts - kein Teil der drei Entscheidungen wurde bewusst weggelassen. Verifiziert: docs verify, instructions verify, pytest (856 passed) nach dem Instruction-Rewrite; sources coverage, lint und Index-Rebuild nach dem kb/-Nachzug.

Referenzfunktion für das Schema übernehmen ab jetzt instructions/dev/issue-tracking.md (für Sitzungen) und kb/concepts/Issue Label Scheme.md (für Nachschlagen) - beide dauerhaft, dieses Issue war nur der Weg dorthin.

**Geschlossen.** Alle vier Akzeptanzkriterien sind umgesetzt: Label-Set in Gitea (16 Labels, vier Pflicht- plus eine optionale Familie), Schema kanonisch in `instructions/dev/issue-tracking.md` (`4.0.1`, Commit `c8c2385`), `kb/concepts/Issue Label Scheme.md` nachgezogen (Commit `23e34a9`), alle 21 offenen Issues auf die vier Pflicht-Label umgestellt. Nicht umgesetzt wurde nichts - kein Teil der drei Entscheidungen wurde bewusst weggelassen. Verifiziert: `docs verify`, `instructions verify`, `pytest` (856 passed) nach dem Instruction-Rewrite; `sources coverage`, `lint` und Index-Rebuild nach dem `kb/`-Nachzug. Referenzfunktion für das Schema übernehmen ab jetzt `instructions/dev/issue-tracking.md` (für Sitzungen) und `kb/concepts/Issue Label Scheme.md` (für Nachschlagen) - beide dauerhaft, dieses Issue war nur der Weg dorthin.
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/blocking 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#41
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?