---
type: types/source.md
source_type: notes
author: Torben Nehmer
raw_files: [raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md]
source_language: de
date: 2026-09-02
tags: [issues, gitea, labels, triage, process]
entities: [Chemenu, Gitea MCP Server]
concepts: [Issue Label Scheme]
summary: 'Threadkopie zu Gitea-Issue #41: vier Pflicht-Label-Achsen statt zwei, zwei optionale status/-Flags, und der Issue-Body als aktuelle Wahrheit statt als Ursprungstext'
---
# Source: Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02

**Autor:** Torben Nehmer  
**Datum:** 2026-09-02  
**Raw-Dateien:** raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md  
**Typ:** Notes

## Zusammenfassung

Wörtliche Kopie des Threads zu Gitea-Issue #41, gezogen am 2026-09-02: Issue-Body im Stand
nach der Umsetzung, die drei Changelog-Kommentare und das zu diesem Zeitpunkt in Gitea
angelegte Label-Set. Das Issue hält eine Diskussion vom selben Tag fest, die aus der
Aufarbeitung von fünf als "Fallouts" des Entwicklungsprozesses eingestuften Issues (#38, #30,
#28, #7, #27) hervorging und den Rahmen für deren Bearbeitung setzen sollte.

Verhandelt wurden drei Dinge. Erstens bleibt ein eingehender Wunsch ein Issue und wird keine
`kb/`-Seite, weil Issues ephemer sind und Wünsche abbilden - neu ist daran nur, wie ein Issue
gepflegt wird: der Body ist aktuelle Wahrheit und wird umgeschrieben, Kommentare tragen einen
Changelog statt einer Vollkopie, und beides macht in der Regel eine LLM-Sitzung. Zweitens
werden aus zwei Pflicht-Label-Achsen vier: `area/`, `kind/`, `prio/` und `size/`. Drittens
kommen zwei optionale Flags dazu, `status/blocked` und `status/unconfirmed`.

Die Quelle ist zugleich der Beleg für die Umsetzung: das Issue verzeichnet, dass das
Label-Set in Gitea steht und dass das Schema seit Stack-Version `4.0.1` kanonisch in
`instructions/dev/issue-tracking.md` liegt.

## Kernaussagen

- **Der Issue-Body ist die Lifeline für das Agent-Memory.** Die Umsetzung eines Issues zieht
  sich über mehrere, zeitlich getrennte LLM-Sitzungen, und der Body ist der einzige Ort, der
  sie verbindet: eine Sitzung muss allein aus ihm rekonstruieren können, was entschieden und
  was offen ist. Ein additiv wachsendes Log zwingt dagegen zum Lesen der ganzen Geschichte,
  um den aktuellen Stand herauszufiltern.
- **Kommentare sind Changelog, nicht 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. Der Kommentar nennt nur, was neu, entfallen oder
  korrigiert ist.
- **Vier Pflichtachsen sind bezahlbar geworden, weil die Pflege maschinell läuft.** Der
  ursprüngliche Einwand gegen eine dritte Achse war der Pflegeaufwand für einen einzelnen
  menschlichen Betreuer; da Body-Rewrites und Labelpflege über eine LLM-Sitzung laufen, trägt
  er nicht mehr.
- **`area/` folgt der Systemgrenze, nicht dem Codeort.** Die Werte `kb`, `distribution`,
  `corpus`, `workflow`, `process` 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.
- **`prio/` wurde nur umbenannt.** `1`/`2`/`3` heißen jetzt `blocking`/`planned`/`waiting`,
  die Bedeutung ist unverändert. Bei `size/` entfällt `XS`; `S`/`M`/`L` bleiben, wie sie
  waren.
- **Ein unbelegter Verdacht bleibt nicht offen liegen.** Solange `status/unconfirmed` gesetzt
  ist, sind `size` und `prio` vorläufig. Die Triage endet mit entferntem Flag und
  verbindlichen Werten oder mit einem geschlossenen Issue samt Begründung - vom Issue selbst
  als Prozessentsprechung zu Invariante 3 des Stacks bezeichnet.
- **Sechzehn Label stehen in Gitea**, gelesen am 2026-09-02: fünf `area/`, drei `kind/`, drei
  `prio/`, drei `size/`, zwei `status/`. `size/XS`, `prio/1`, `prio/2` und `prio/3`
  existieren nicht mehr.
- **Der Release war ein PATCH.** `4.0.1`, weil `dist export` `instructions/dev/` vollständig
  ausschließt und sich für eine ausgelieferte Instanz nichts ändert - dieselbe Begründung wie
  bei `1.2.1`, das das Zweiachsen-Schema eingeführt hatte.

## Aufgaben

- [ ] Bestehende Sachissues nach und nach auf die vier Pflicht-Label umstellen (laut Issue
      bereits umgestellt: #38, #27 geschlossen, #7, #42)

## Nicht übernommen

- **Die Diskussion, aus der das Issue hervorging.** Das Issue nennt sie ("Diskussion vom
  2026-09-02"), aber ihr Transkript liegt nicht in `raw/`. Die Quelle ist damit das Ergebnis
  der Debatte, nicht ihr Verlauf; die verworfenen Alternativen sind nicht rekonstruierbar.
- **Die Sachinhalte der referenzierten Issues #38, #30, #28, #27, #7, #42, #39, #40.** Sie
  kommen im Thread nur als Nummern vor. Was in ihnen steht, gehört in die Seiten zu den
  jeweiligen Gegenständen, nicht hierher.
- **Der Volltext von `instructions/dev/issue-tracking.md`.** Das Issue beschreibt, was dort
  hineingeschrieben wurde; die Instruction selbst ist Teil des Stacks und kein Rohmaterial.

## Verwandte Entities

- [[Chemenu]]
- [[Gitea MCP Server]]

## Verwandte Concepts

- [[Issue Label Scheme]]