chemenu/kb/sources/trackers/Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md

type, source_type, author, raw_files, source_language, date, tags, entities, concepts, summary

type	source_type	author	raw_files	source_language	date	tags	entities	concepts	summary
types/source.md	tracker	Torben Nehmer	raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md	de	2026-09-02	issues gitea labels triage process	Chemenu Gitea MCP Server	Issue Label Scheme	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