Threadkopie zu Gitea-Issues #62/#63: das dritte status/-Flag status/incoming (Stubs werden nie so umgesetzt wie sie dastehen, es setzt die vier Pflichtachsen aus statt sie zu qualifizieren), plus die dadurch veraltete kb-Seite (17 statt 16 Labels)
Wörtliche Kopie zweier zusammenhängender Gitea-Issue-Threads, gezogen am 2026-09-04: #62 im
Endstand nach Body-Rewrite und Close, #63 im Erstzustand (offen, unkommentiert), dazu das zu
diesem Zeitpunkt in Gitea angelegte Label-Set. Beide Issues gehören zusammen: #62 führt das
dritte status/-Flag ein, #63 ist der Folgebefund, den #62 im eigenen Body selbst benennt.
status/incoming markiert einen vom Menschen angelegten Stub - eine kurze Anforderung oder
einen Verdacht, ohne Akzeptanzkriterium und ohne die vier Pflichtachsen. Die Regel, die #62 in
instructions/dev/issue-tracking.md verankert: ein solcher Stub wird nie so umgesetzt, wie er
dasteht, sondern erst in einer eigenen Sitzung ausgearbeitet und trianiert. Das Flag setzt dabei
die Vier-Pflichtachsen-Regel aus Issue Label Scheme nicht außer Kraft, sondern verschiebt ihre
Fälligkeit: die Achsen fehlen einem Stub nicht, sie sind noch nicht dran.
Die Quelle ist zugleich der Beleg für die Umsetzung: #62 verzeichnet Commit 4ab358f und Stack-
Version 4.7.5-beta.1, mit allen sieben Akzeptanzkriterien abgehakt. #63 hält im Gegenzug fest,
dass kb/concepts/Issue Label Scheme.md dadurch veraltet ist - der Stand von 2026-09-02 kennt
das neue Flag nicht und zählt sechzehn statt siebzehn Labels.
Kernaussagen
status/incoming ist das einzige Flag, das die Vier-Achsen-Pflicht aussetzt statt sie zu
qualifizieren.status/blocked und status/unconfirmed gelten zusätzlich zu den vier
Pflichtlabeln; status/incoming gilt anstelle von ihnen, solange der Stub nicht ausgearbeitet
ist. Ein Stub auf Sicht durchzulabeln ist der Fehler, nicht das Weglassen - es lässt
Ungeprüftes triagiert aussehen.
Ein Stub ist die Absichtserklärung des Menschen, nicht die Spezifikation. Sein Wortlaut ist
der einzige Beleg dessen, was gewünscht war. Die Ausarbeitung liest ihn, statt ihn
umzudeuten, prüft ihn gegen den Baum, rettet den Originaltext wörtlich in einen Kommentar
bevor der Body-Rewrite ihn überschreibt, und benennt offene Fragen statt sie zu beantworten
(kind/decision).
status/incoming ist das einzige Flag, das eine Sitzung nie selbst vergibt. Ein Issue, das
eine Sitzung anlegt, erfüllt Schritt 1 (Body als überlebensfähige Spec) oder wird gar nicht
angelegt.
Zwei Ausgänge, wie bei status/unconfirmed. Ein Stub wird ausgearbeitet - Flag entfernt,
alle vier Pflichtlabel gesetzt für real - oder mit Begründung geschlossen. Er bleibt nicht
unbegrenzt im Eingang liegen.
Der Anlass war akut, nicht hypothetisch. Zwei Issues (#60, #61) trugen status/incoming
bereits, bevor die Regel geschrieben war - beide zwei bis drei Sätze Prosa, ohne
Akzeptanzkriterium, teils Vermutung statt Feststellung.
PATCH, nicht MINOR.4.7.5-beta.1, weil dist exportinstructions/dev/ vollständig
ausschließt - dieselbe Begründung wie bei 4.0.1, das die vier Pflichtachsen eingeführt hatte.
Siebzehn Labels stehen in Gitea, gelesen am 2026-09-04: gegenüber dem Stand vom
2026-09-02 (sechzehn) ist genau status/incoming neu dazugekommen.
Aufgaben
kb/concepts/Issue Label Scheme.md um das dritte status/-Flag und die korrekte
Labelzahl ergänzen (Gitea #63 - wird im selben Zug wie diese Source erledigt)
#60 und #61 ausarbeiten und triagieren - die erste tatsächliche Anwendung der neuen Regel,
eigene stack-dev-Sitzung
Nicht übernommen
Der volle Prosa-Abschnitt "§ Incoming stubs" aus instructions/dev/issue-tracking.md
selbst. #62 beschreibt, was dort hineingeschrieben wurde; die Instruction ist Teil des
Stacks und kein Rohmaterial - dieselbe Abgrenzung, die schon die Vorgängerquelle zu #41 zieht.
Die Sachinhalte von #60 und #61. Sie kommen in #62 nur als Nummern vor. Was in ihnen
steht, ist eigenes Rohmaterial für die Sitzung, die sie ausarbeitet, nicht Teil dieser Quelle.