chemenu/kb/concepts/decisions/Issue Label Scheme.md

type, concept_type, tags, created, modified, related, sources, provenance, summary

type	concept_type	tags	created	modified	related	sources	provenance	summary
types/concept.md	decision	issues gitea triage labels backlog	2026-08-31	2026-09-04	operates-on Chemenu mechanism Gitea MCP Server see-also KB Stack Versioning see-also Detect-Repair Asymmetry	Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31 Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02 Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04	sourced	Pflicht-Labelschema fuer das Gitea-Board: vier Achsen (area/kind/prio/size) plus seit 2026-09-04 drei optionale status/-Flags, darunter status/incoming fuer unausgearbeitete Stubs, die die Vier-Achsen-Pflicht aussetzen statt sie zu ergaenzen; die Regel liegt in instructions/dev/, weil sie keine ausgelieferte Instanz erreichen darf

Issue Label Scheme

Typ: Decision

Definition

Issue Label Scheme ist die Entscheidung, offene Arbeit an diesem Stack ausschließlich als Gitea-Issues zu führen und jedes offene Issue mit vier Pflicht-Labels zu versehen: einem Bereich area/, einer Art kind/, einer Priorität prio/ und einer Größe size/. Dazu kommen drei optionale status/-Flags. Getroffen wurde die Entscheidung in dieser Form am 2026-09-02¹ ; sie ersetzt das zweiachsige Schema vom 2026-08-31 (siehe Historie). Am 2026-09-04 kam das dritte status/-Flag, status/incoming, dazu² .

area/	Bedeutung
area/kb	kb/-Schema, Contract, Confidence, Lint - die Wissensbasis als System.
area/distribution	Auslieferung, Upgrade und Versionierung einer Instanz.
area/corpus	Inhalt und Umfang von kb/ in dieser Instanz, samt Demo-/Testbett-Frage.
area/workflow	Git, Merge, Branching, Publish, PRs.
area/process	Der Entwicklungsprozess selbst, nicht der Stack als Artefakt.

kind/	Bedeutung
kind/decision	Wartet auf eine Betreiberentscheidung.
kind/build	Spezifiziert, wartet nur noch auf Umsetzungszeit.
kind/defect	Befund: Doku und Realität, oder zwei Dokus, widersprechen sich.

prio/	Bedeutung
prio/blocking	Blockiert oder beschädigt laufende Arbeit. Als Nächstes.
prio/planned	Sammelt Zinsen. Eingeplant.
prio/waiting	Lohnend, wartet auf einen benannten Auslöser.

size/	Bedeutung
size/S	Eine Sitzung, ein Publish, ein klarer Schnitt.
size/M	Mehrere Dateien; eine Contract- oder Instruction-Änderung; eigener Testaufwand.
size/L	Mehrere Sitzungen, oder offene Entwurfsfragen vor dem ersten Commit.

status/ (optional)	Bedeutung
status/blocked	Wartet auf ein anderes, noch offenes Issue - unabhängig vom prio-Wert nicht eigenständig bearbeitbar.
status/unconfirmed	Gemeldeter Verdacht, noch nicht gegen tatsächliches Verhalten geprüft; size und prio sind solange vorläufig.
status/incoming	Vom Menschen angelegter Stub - unvollständig, ohne Abnahmekriterien, ohne die vier Pflichtachsen. Wird nie so umgesetzt, wie er dasteht: erst Ausarbeitung und Triage gegen den Baum, dann Umsetzung2 .

Siebzehn Labels stehen in Gitea; prio/1, prio/2, prio/3 und size/XS existieren nicht mehr¹ .

Kernpunkte

• Vier Achsen sind Pflicht, weil ihre Pflege maschinell läuft. Der ursprüngliche Einwand gegen eine dritte Achse war der Aufwand für einen einzelnen menschlichen Betreuer. Da Body-Rewrites und Labelpflege über eine LLM-Sitzung laufen und ein Mensch in der Regel nur Metadaten anfasst, trägt dieser Einwand nicht mehr¹ .
• Der Issue-Body ist die aktuelle Wahrheit, nicht der Ursprungstext. Die Umsetzung eines Issues zieht sich über mehrere, zeitlich getrennte Sitzungen, und der Body ist das einzige, was sie verbindet: eine Sitzung muss allein aus ihm rekonstruieren können, was entschieden und was offen ist. Er wird deshalb umgeschrieben statt ergänzt¹ .
• Ein Kommentar ist ein Changelog, keine Kopie. Ein Volltext-Snapshot des alten Bodys pro Revision zwingt einen Menschen zum Diffen zweier Fließtexte und ist damit keine lesbare Historie, sondern nur eine weitere Kopie¹ .
• area/ folgt der Systemgrenze, nicht dem Codeort. Die Werte folgen der Stufenteilung aus AGENTS.md. Ein area/tools gibt es bewusst nicht - Tooling wird nach der Domäne einsortiert, die es bedient¹ .
• kind/ darf sich im Lauf eines Issues ändern. Der Wechsel von decision zu build, sobald entschieden ist, ist erwünschtes Session-Memory-Verhalten und kein Makel¹ .
• Eine Priorität ohne Kosten ist eine halbe Entscheidung. Größe ist Aufwand und nicht Wichtigkeit, deshalb ist prio/blocking size/S das Beste, was auf einem Board stehen kann, und prio/waiting size/L etwas, worüber gesprochen wird, bevor jemand anfängt.
• prio/waiting ist kein Friedhof. Der Auslöser muss im Issue benannt sein, sonst ist das Label ein höfliches Nein³ .
• Kein unbelegter Verdacht bleibt offen liegen. Die Triage eines status/unconfirmed endet entweder mit entferntem Flag und verbindlichen size/prio-Werten oder mit einem geschlossenen Issue samt Begründung - die Prozessentsprechung zu Invariante 3 des Stacks¹ .
• Priorisiert wird nach Schaden, nicht nach Aufwand. Das Kriterium der ersten Triage lautete: was blockiert oder beschädigt laufende Arbeit. Ein Werkzeugfehler, der seinen Benutzer gegen eine Invariante des Stacks drückt, rangiert deshalb vor einer fehlenden Fähigkeit, so gut das Issue dazu auch geschrieben ist.
• Ein Issue ohne Abnahmekriterium ist kein Arbeitspaket. Beim Portieren der Recherche-Notiz nach Issue #15 wurden Abnahmekriterien ergänzt, weil die Prosa-Notiz keine hatte³ .
• TODO.md wurde gelöscht statt gepflegt. Ihr erster Abschnitt war ohnehin nur noch eine Linkliste auf Issues; der zweite, die Recherche-Notiz, ging vollständig nach #15. Danach gab es nichts mehr in der Datei, was nicht auf Gitea stand.
• status/incoming setzt die Vier-Achsen-Pflicht aus, statt sie zu qualifizieren. Bei den beiden älteren status/-Flags gelten area/, kind/, prio/ und size/ weiterhin zusätzlich; unter status/incoming sind sie nicht fällig, solange der Stub nicht ausgearbeitet ist. Ein Stub auf Sicht durchzulabeln wäre der Fehler, nicht das Weglassen² .

Historie

Das ursprüngliche Schema vom 2026-08-31 hatte genau zwei Pflicht-Labels, prio/1..3 und size/XS..L, und verzichtete ausdrücklich auf eine dritte Achse: Art, Bereich oder Status wurden verworfen als der Punkt, ab dem eine Taxonomie eigene Pflege braucht, und das Board habe einen einzigen Betreuer. Sieben Labels wurden angelegt und auf alle zehn zu dem Zeitpunkt offenen Issues angewandt³ .

Was sich am 2026-09-02 geändert hat:

Achse	Vorher	Jetzt
prio/	1, 2, 3	blocking, planned, waiting - reine Umbenennung, Bedeutung unverändert
size/	XS, S, M, L	S, M, L - XS entfällt, die übrigen unverändert
area/	-	fünf Werte, neu
kind/	-	drei Werte, neu
status/	-	zwei optionale Flags, neu

Der Verzicht auf die dritte Achse fiel damit weg, nicht weil die Begründung falsch war, sondern weil ihre Voraussetzung entfallen ist: gepflegt wird das Board nicht mehr von Hand.

Was sich am 2026-09-04 zusätzlich geändert hat² :

Achse	Vorher	Jetzt
status/	zwei optionale Flags	drittes Flag status/incoming dazu - setzt, anders als die anderen beiden, die Vier-Achsen-Pflicht aus statt sie zu ergänzen

Wo die Regel liegt

Die Platzierung war die tragende Entscheidung, nicht das Schema selbst. README.md und AGENTS.md gehen in jede über wikitool dist export ausgelieferte Instanz, und eine solche Instanz hat kein Issue-Board auf gitea.nehmer.net. Eine dort mitgelieferte Label-Regel wäre eine Anweisung ins Leere.

instructions/dev/ ist der einzige Ort, der beides ist: von Agenten lesbar und nie ausgeliefert, weil dist export das Verzeichnis vollständig ausschließt. Das Schema steht deshalb in instructions/dev/issue-tracking.md und ist aus Schritt 2 des stack-dev-Skills verlinkt³ .

Aus demselben Grund war der Release ein PATCH (1.2.1) und kein MINOR: für eine bestehende Instanz ändert sich nichts. Das CI-Versions-Gate verlangte den Bump trotzdem, weil sein Muster auf instructions/ passt und instructions/dev/ darunter liegt³ . Siehe KB Stack Versioning.

Für die Erweiterung auf vier Achsen galt dieselbe Rechnung noch einmal: sie ging als 4.0.1 und damit ebenfalls als PATCH hinaus¹ . Für das dritte status/-Flag ein drittes Mal: 4.7.5-beta.1, ebenfalls PATCH² .

Beispiele

• Chemenu - das Repository, dessen Board nach dem Schema geführt wird; siebzehn Labels stehen dort, verteilt auf vier Pflicht- und eine optionale Familie
• Gitea MCP Server - der Weg, auf dem Issues und Labels gelesen und geschrieben werden
• Detect-Repair Asymmetry - Issue #14 ist der Fall, den dieses Concept beschreibt, und trug in der ersten Triage prio/2 size/S, nach der Umbenennung also prio/planned size/S

Wann zu verwenden

• Auf einem Board mit einem einzigen menschlichen Betreuer, dessen Labelpflege maschinell läuft. Erst das macht mehr als zwei Achsen bezahlbar.
• Sobald offene Arbeit sonst in Prosa-Dateien wandert, die niemand als Board liest und die gegen den Tracker driften.
• Sobald die Bearbeitung eines Issues sich über mehrere, zeitlich getrennte Sitzungen zieht - dann trägt die Body-als-Wahrheit-Konvention den Kontext, den sonst ein Mensch jedes Mal neu erzählen müsste.

Wann NICHT zu verwenden

• Nicht dort, wo Labels von Hand gepflegt werden. Dann ist die ursprüngliche Zweiachsigkeit die tragfähigere Wahl, und die Begründung von 2026-08-31 gilt unverändert.
• Nicht als Ersatz für die Abnahmekriterien im Issue-Text. Die Labels ordnen ein Issue ein; ob es fertig ist, sagen sie nicht.
• Nicht mit umgeschriebenen Bodys dort, wo mehrere Menschen denselben Thread lesen und den Verlauf brauchen. Die Konvention tauscht Historie gegen Aktualität und setzt voraus, dass der Changelog-Kommentar als Historie genügt.
• Nicht in einer ausgelieferten Instanz. Das Schema beschreibt das Entwicklungs-Repository und hat außerhalb davon keinen Gegenstand.

Beziehungen

• operates-on: Chemenu
• mechanism: Gitea MCP Server
• see-also: KB Stack Versioning
• see-also: Detect-Repair Asymmetry

Fußnoten

---

1. Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02 ↩︎

2. Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04 ↩︎

3. Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31 ↩︎