wiki-manage: Issue Label Scheme um status/incoming ergaenzt, Quelle fuer #62/#63 angelegt (schliesst #63)

Files changed:
- kb/concepts/INDEX.md
- kb/concepts/Issue Label Scheme.md
- kb/index.md
- kb/log.md
- kb/provenance.md
- kb/sources/INDEX.md
- kb/sources/Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md
- raw/notes/Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md

kb/sources/Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md

@@ -0,0 +1,87 @@
+---
+type: types/source.md
+source_type: notes
+author: Torben Nehmer
+raw_files: [raw/notes/Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md]
+source_language: de
+date: 2026-09-04
+tags: [issues, gitea, labels, triage, process]
+entities: [Chemenu, Gitea MCP Server]
+concepts: [Issue Label Scheme]
+summary: '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)'
+---
+# Source: Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04
+
+**Autor:** Torben Nehmer  
+**Datum:** 2026-09-04  
+**Raw-Dateien:** raw/notes/Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md  
+**Typ:** Notes
+
+## Zusammenfassung
+
+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 export` `instructions/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.
+
+## Verwandte Entities
+
+- [[Chemenu]]
+- [[Gitea MCP Server]]
+
+## Verwandte Concepts
+
+- [[Issue Label Scheme]]