chemenu/kb/concepts/Issue Label Scheme.md

---
type: types/concept.md
concept_type: decision
tags: [issues, gitea, triage, labels, backlog]
created: 2026-08-31
modified: 2026-09-04
related:
  - operates-on: Chemenu
  - mechanism: Gitea MCP Server
  - see-also: KB Stack Versioning
  - see-also: Detect-Repair Asymmetry
sources: [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]
confidence: 0.70
confidence_base: 0.85
provenance: sourced
summary: '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[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02]; sie ersetzt das
zweiachsige Schema vom 2026-08-31 (siehe [Historie](#historie)). Am 2026-09-04 kam das dritte
`status/`-Flag,
`status/incoming`, dazu[^s-gitea-issues-62-63-status-incoming-label-introduction-2026-09-04].

| `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 Umsetzung[^s-gitea-issues-62-63-status-incoming-label-introduction-2026-09-04]. |

Siebzehn Labels stehen in Gitea; `prio/1`, `prio/2`, `prio/3` und `size/XS` existieren nicht
mehr[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].

## 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[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
- **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[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
- **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[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
- **`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[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
- **`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[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
- **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[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
- **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[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
- **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[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
- **`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[^s-gitea-issues-62-63-status-incoming-label-introduction-2026-09-04].

## 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[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].

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[^s-gitea-issues-62-63-status-incoming-label-introduction-2026-09-04]:

| 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[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].

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[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]. 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[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02]. Für das dritte
`status/`-Flag ein drittes Mal: `4.7.5-beta.1`, ebenfalls
PATCH[^s-gitea-issues-62-63-status-incoming-label-introduction-2026-09-04].

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

<!-- wikitool:links -->

## Beziehungen

- **operates-on:** [[Chemenu]]
- **mechanism:** [[Gitea MCP Server]]
- **see-also:** [[KB Stack Versioning]]
- **see-also:** [[Detect-Repair Asymmetry]]
<!-- /wikitool:links -->

<!-- wikitool:footnotes -->
## Fußnoten

[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02]: [[Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02]]
[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]: [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
[^s-gitea-issues-62-63-status-incoming-label-introduction-2026-09-04]: [[Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04]]
<!-- /wikitool:footnotes -->