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/concepts/INDEX.md

@@ -41,7 +41,7 @@
 | [[Hybrid Search]] | architecture | Multimodale Suche, die BM25-Schlüsselwortabgleich, Vektor-Embeddings und Graph Traversal verbindet, um Wissensabruf im Wiki skalierbar zu machen. | 2026-08-29 |
 | [[Implementation Spectrum]] | architecture | Modularer Einführungspfad für die Funktionen von LLM Wiki v2, vom minimal tragfähigen Wiki bis zur vollen Umsetzung mit Automatisierung und Governance. | 2026-08-29 |
 | [[Index Scaling]] | workflow | Skalierungsregeln für Indexseiten: Tabellenabschnitte ab 50 Einträgen teilen, ab 200 Seiten _meta/topic-map.md anlegen | 2026-08-29 |
-| [[Issue Label Scheme]] | decision | Pflicht-Labelschema fuer das Gitea-Board: seit 2026-09-02 vier Achsen (area/kind/prio/size) plus zwei optionale status/-Flags, dazu der Issue-Body als aktuelle Wahrheit; die Regel liegt in instructions/dev/, weil sie keine ausgelieferte Instanz erreichen darf | 2026-09-02 |
+| [[Issue Label Scheme]] | decision | 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 | 2026-09-04 |
 | [[Iteration and Cost Limits]] | workflow | Im Code durchgesetzte Obergrenze von 60 wikitool-Aufrufen je Session, Loop-Breaker bei 3 identischen Wiederholungen, Slot-Erstattung, ein gemessenes Kalibrierungsband, und Retrieval sowie der MCP-Leseserver bleiben ausgenommen | 2026-09-02 |
 | [[KB Migration]] | workflow | Migration des KB-Inhalts entlang einer geordneten Versionskette; abgegrenzt gegen offene Instanz-Aktionen, die in den doctor-Check gehoeren statt in die Kette | 2026-08-31 |
 | [[KB Stack Versioning]] | decision | Semantische Versionierung des Wiki-Stacks: VERSION beschreibt die Maschinerie, Kompatibilitaet (Drop-in-Ersatz) und Inhaltsmigration sind seit 2.5.0 getrennte, unabhaengig geprueft Fragen | 2026-09-02 |

kb/concepts/Issue Label Scheme.md

@@ -3,17 +3,17 @@ type: types/concept.md
 concept_type: decision
 tags: [issues, gitea, triage, labels, backlog]
 created: 2026-08-31
-modified: 2026-09-02
+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]
+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: seit 2026-09-02 vier Achsen (area/kind/prio/size) plus zwei optionale status/-Flags, dazu der Issue-Body als aktuelle Wahrheit; die Regel liegt in instructions/dev/, weil sie keine ausgelieferte Instanz erreichen darf'
+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
 
@@ -24,9 +24,11 @@ summary: 'Pflicht-Labelschema fuer das Gitea-Board: seit 2026-09-02 vier Achsen
 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 zwei optionale `status/`-Flags. Getroffen wurde die Entscheidung in dieser Form am
+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)).
+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 |
 |---|---|
@@ -58,8 +60,9 @@ zweiachsige Schema vom 2026-08-31 (siehe [Historie](#historie)).
 |---|---|
 | `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]. |
 
-Sechzehn Labels stehen in Gitea; `prio/1`, `prio/2`, `prio/3` und `size/XS` existieren nicht
+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
@@ -104,6 +107,11 @@ mehr[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
 - **`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
 
@@ -127,6 +135,13 @@ Was sich am 2026-09-02 geändert hat:
 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
@@ -146,11 +161,13 @@ auf `instructions/` passt und `instructions/dev/` darunter liegt[^s-conversation
 
 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].
+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; sechzehn Labels
+- [[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
@@ -193,4 +210,5 @@ hinaus[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
 
 [^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 -->

kb/index.md

@@ -13,12 +13,12 @@ The page tables live in a generated `INDEX.md` inside each collection, linked be
 
 ## Statistics
 
-- **Total Pages:** 181
+- **Total Pages:** 182
 - **Comparisons:** 1
 - **Concepts:** 80
 - **Entities:** 72
-- **Sources:** 28
+- **Sources:** 29
-- **Last Updated:** 2026-09-03
+- **Last Updated:** 2026-09-04
 
 ---
 
@@ -29,7 +29,7 @@ The page tables live in a generated `INDEX.md` inside each collection, linked be
 | `comparisons/` | 1 | [comparisons/INDEX.md](comparisons/INDEX.md) |
 | `concepts/` | 80 | [concepts/INDEX.md](concepts/INDEX.md) |
 | `entities/` | 72 | [entities/INDEX.md](entities/INDEX.md) |
-| `sources/` | 28 | [sources/INDEX.md](sources/INDEX.md) |
+| `sources/` | 29 | [sources/INDEX.md](sources/INDEX.md) |
 
 ### entities/
 

kb/log.md

@@ -137,3 +137,15 @@ Befund 1 aus #40: die einzige Comparison-Seite (amd-pstate vs acpi-cpufreq) trug
 migrate verify --from HEAD: 181 Seiten, 0 hinzugefuegt, 0 entfernt, 18 Befunde - alle Label-Wechsel im Frontmatter, keine Aenderung an Wikilink- oder Zitatzahlen. lint --fail-on-error gruen.
 
 ---
+
+## [2026-09-04] create | Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04
+
+Neue Source-Seite fuer Gitea-Issues #62/#63: Einfuehrung des dritten status/-Flags status/incoming in instructions/dev/issue-tracking.md (4.7.5-beta.1, Commit 4ab358f) und der dadurch veraltete Stand von kb/concepts/Issue Label Scheme.md. Raw-Datei: raw/notes/Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md
+
+---
+
+## [2026-09-04] update | Issue Label Scheme
+
+Drittes status/-Flag status/incoming ergaenzt (Gitea #63): status/-Tabelle auf drei Zeilen, Labelzahl 16 auf 17 korrigiert, neuer Kernpunkt zur Aussetzung der Vier-Achsen-Pflicht, Historie- und Beispiele-Abschnitt sowie Versions-/PATCH-Hinweis nachgezogen. Quelle: Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.
+
+---

kb/provenance.md

@@ -8,8 +8,8 @@ inline `[^cite-id]` footnote).
 
 ## Coverage Summary
 
-- **Total raw files:** 28
+- **Total raw files:** 29
-- **Covered:** 28
+- **Covered:** 29
 - **Uncovered:** 0
 
 ---
@@ -131,6 +131,11 @@ inline `[^cite-id]` footnote).
 - Covered by: [[Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02]]
   - Cited by: [[Chemenu]], [[Gitea MCP Server]], [[Issue Label Scheme]]
 
+### `raw/notes/Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md`
+
+- Covered by: [[Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04]]
+  - Cited by: [[Issue Label Scheme]]
+
 ### `raw/notes/Wine.md`
 
 - Covered by: [[Source - Wine]]

kb/sources/INDEX.md

@@ -2,7 +2,7 @@
 
 # kb/sources/ - Index
 
-28 page(s). Regenerated by `wikitool index rebuild`.
+29 page(s). Regenerated by `wikitool index rebuild`.
 
 ## All
 
@@ -24,6 +24,7 @@
 | [[Source - Copilot Skill Restructure Instructions]] | notes | Anweisungssatz zur Aufteilung der monolithischen AGENTS.md in einzelne plattformübergreifende Agent-Skills | 2026-08-03 |
 | [[Source - Docker Cheatsheet]] | notes | Praktisches Bash-Skript zur Fehlersuche bei Docker-Volumes und Overlay2, um den Container zu einem Verzeichnis im Dateisystem zu ermitteln. | 2026-07-31 |
 | [[Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02]] | notes | 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 | 2026-09-02 |
+| [[Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04]] | notes | 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) | 2026-09-04 |
 | [[Source - LLM Improvements Codex Analysis]] | notes | Codex-Analyse, die AGENTS.md und wikitool mit awesome-llm-wiki und Farzas Gist vergleicht und 7 aussichtsreiche Verbesserungen sowie zu vermeidende Anti-Muster benennt. Hinweis: eine Sonnet-Analyse zum Vergleich ist vorgesehen. | 2026-08-03 |
 | [[Source - LLM Improvements Production Agent Gaps 2026]] | notes | Externe Kritik (dzone, 2026) am Fehlen harter Iterations- und Kostengrenzen sowie eines Loop-Breakers; umgesetzt als Iteration Budget Gate in wikitool. | 2026-08-07 |
 | [[Source - LLM Improvements Sonnet Analysis]] | notes | Sonnet-Analyse, die AGENTS.md und wikitool mit Farzas Gist und awesome-llm-wiki vergleicht und die Codex-Analyse um konkrete Empfehlungen zu Qualitätsschwellen, Stilrichtlinie, Auditrhythmus und Skalierung ergänzt | 2026-08-03 |

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]]

raw/notes/Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md

@@ -0,0 +1,187 @@
+# Gitea Issues #62 und #63 — Einführung `status/incoming` und die dadurch veraltete kb-Seite
+
+Wörtliche Kopie zweier zusammenhängender Issue-Threads von
+<https://gitea.nehmer.net/torben/chemenu/issues/62> und
+<https://gitea.nehmer.net/torben/chemenu/issues/63>, gezogen am 2026-09-04 nach dem
+Body-Rewrite und Close von #62. Autor aller Beiträge: torben.
+
+#62 setzt `status/incoming` in `instructions/dev/issue-tracking.md` um; #63 ist der
+Folgebefund, den #62 selbst im Body benennt: `kb/concepts/Issue Label Scheme.md` kennt das neue
+Flag nicht und zählt die Labels falsch.
+
+---
+
+## Issue #62 — `status/incoming`: menschliche Stubs sind keine Work Packages und dürfen nicht so umgesetzt werden
+
+Erstellt 2026-09-04T19:53:23Z, geschlossen 2026-09-04T19:57:07Z. Labels:
+`area/process`, `kind/build`, `prio/blocking`, `size/S`. Status: geschlossen.
+
+### Issue-Body (Endstand nach Rewrite, Stand 2026-09-04T19:57:07Z)
+
+**Erledigt in `4.7.5-beta.1`, Commit `4ab358f`.**
+
+#### Was das Problem war
+
+Das Label `status/incoming` wurde am 2026-09-04 in Gitea angelegt ("Vom Menschen angelegte
+Anforderung, unvollständig, muss durch den Stack komplettiert werden"), und zwei Issues trugen
+es bereits: #60 und #61. Beide sind zwei bis drei Sätze Prosa, ohne Akzeptanzkriterium, ohne die
+vier Pflichtachsen, teils Vermutung statt Feststellung.
+
+`instructions/dev/issue-tracking.md` beschrieb das Label nicht. Eine Sitzung, die #60 aufnimmt,
+sieht ein offenes Issue mit einem Body — und der Body ist nach Schritt 2 genau das, was eine
+Sitzung als Spec glaubt. Zusätzlich verlangt Schritt 4 alle vier Pflichtlabel "always", was ein
+`status/incoming`-Issue legitim verletzt, ohne dass irgendwo stand, dass das in Ordnung ist.
+
+#### Was umgesetzt wurde
+
+Reine Instruction-Änderung, kein Tool-Code. `wikitool` kennt den Tracker weiterhin nicht und
+soll ihn nicht kennenlernen (§ "What no tool checks").
+
+In `instructions/dev/issue-tracking.md`:
+
+- **Neuer Abschnitt § Incoming stubs**, nach dem Muster von § Renames — ein Ablauf, der nicht
+  in den nummerierten Fluss gehört. Erster Satz ist das Verbot: *"A `status/incoming` issue is
+  never implemented as it stands."* Darunter die Begründung (der Tracker ist auch der Eingang
+  des Menschen; Stub und Schritt-1-Body haben unterschiedliche Eintrittskosten) und die
+  Ausarbeitung als sechs Schritte: Wortlaut als Absichtserklärung lesen, gegen den Baum prüfen,
+  Originaltext wörtlich in den Kommentar retten, bevor der Rewrite ihn überschreibt, offene
+  Fragen benennen statt beantworten (`kind/decision`), erst dann Schritt 4, dann Flag entfernen.
+  Zwei Ausgänge wie bei `status/unconfirmed`.
+- **Schritt 5** hat die dritte Tabellenzeile und den Absatz dazu: dieses Flag *setzt Schritt 4
+  aus*, statt ihn zu qualifizieren — die vier Achsen fehlen nicht, sie sind noch nicht fällig.
+  Außerdem das einzige Flag, das eine Sitzung nie selbst vergibt.
+- **§ When to run** und **§ Decision points** nennen den Fall je einmal; der Decision Point
+  adressiert den gefährlichen Fall "sieht trivial umsetzbar aus".
+- **§ What no tool checks** listet den implementierten Stub als vierten Fall, den nichts meldet.
+- **Frontmatter `description:`** nennt drei `status/`-Flags und das Verbot.
+
+In `instructions/dev/stack-dev/SKILL.md`: die Routing-Zeile zu `issue-tracking.md` nennt
+`status/incoming` als Ausnahme zu allem davor.
+
+#### Entscheidungen
+
+**Kein neuer nummerierter Schritt.** `stack-close/SKILL.md` (Zeile 69) und mehrere
+`CHANGES.md`-Einträge verweisen namentlich auf "Schritte 2-3 und 7". Eine Umnummerierung hätte
+diese Verweise still falsch gemacht — genau der Zerfall, den dieselbe Datei in § Renames
+beschreibt. Die Prozedur bekam stattdessen einen eigenen Abschnitt, was ohnehin die passendere
+Form ist: die Ausarbeitung eines Stubs ist kein Schritt im gewöhnlichen Ablauf, sondern ein
+davorliegender Vorgang.
+
+**PATCH, nicht MINOR.** `dist export` schließt `instructions/dev/` aus; eine ausgelieferte
+Instanz sieht von der Änderung nichts. Nach `version-parts.md` § Decision points ("The break
+only affects this repository") ist das kein Stack-Break, und der Drop-in-Test ist trivial
+erfüllt.
+
+#### Akzeptanzkriterien
+
+- [x] `status/incoming` in Schritt 5s Tabelle, mit ausdrücklichem Absatz, dass die vier
+      Pflichtlabel unter diesem Flag noch nicht fällig sind
+- [x] Eigener Abschnitt mit der Prozedur, Verbot als erste Aussage
+- [x] § When to run und § Decision points nennen den Fall je einmal
+- [x] Schrittnummerierung 1-7 unverändert
+- [x] Frontmatter `description:` nennt drei `status/`-Flags
+- [x] `tools/wikitool instructions verify` und `docs verify` grün
+- [x] `tools/.venv/bin/python -m pytest -q`: 976 passed
+- [x] `version bump --patch` auf `4.7.5-beta.1`, `CHANGES.md`-Eintrag mit Prosa
+
+#### Nachgelagert
+
+- **#63** — `kb/concepts/Issue Label Scheme.md` beschreibt weiter nur zwei `status/`-Flags und
+  behauptet 16 Labels statt 17. `kb/`-Inhalt, braucht eine Quelle nach Invariante 3, also eine
+  eigene `wiki-manage`-Sitzung.
+- **#60 und #61** bleiben unausgearbeitet offen. Das ist die erste Anwendung der Regel, nicht
+  ihre Einführung.
+
+#### Nicht verifiziert
+
+Der Nutzen der Regel selbst — dass eine Sitzung, die #60 aufnimmt, tatsächlich ausarbeitet statt
+zu bauen. Nichts Maschinelles prüft das (§ What no tool checks); der Beleg wäre die Ausarbeitung
+von #60/#61 und liegt außerhalb dieses Pakets. Der Kandidat `4.7.5-beta.1` ist noch offen und
+nicht per `version release` fixiert.
+
+### Kommentar 1 (2026-09-04T19:57:03Z, issuecomment-1002)
+
+**Changelog:** Body auf den Endstand umgeschrieben und geschlossen. Alle sieben
+Akzeptanzkriterien abgehakt, jeweils mit dem Kommando bzw. Ergebnis, das sie belegt. Neu:
+Abschnitt "Entscheidungen" (warum kein neuer Schritt, warum PATCH) und "Nicht verifiziert" (der
+Nutzen der Regel ist maschinell nicht prüfbar, der Beleg wäre die Ausarbeitung von #60/#61). Der
+Punkt "`kb/concepts/Issue Label Scheme.md`" ist aus "Nicht in diesem Paket" nach "Nachgelagert"
+gewandert und liegt jetzt als #63 auf dem Board.
+
+---
+
+## Issue #63 — `kb/concepts/Issue Label Scheme.md` kennt `status/incoming` nicht (16 Labels, tatsächlich 17)
+
+Erstellt 2026-09-04T19:56:24Z, zuletzt geändert 2026-09-04T19:57:03Z. Labels: `area/kb`,
+`kind/defect`, `prio/planned`, `size/S`. Status: offen.
+
+### Issue-Body (Stand 2026-09-04T19:56:24Z)
+
+#### Befund
+
+Mit `4.7.5-beta.1` (#62, Commit `4ab358f`) ist `status/incoming` in
+`instructions/dev/issue-tracking.md` beschrieben: das dritte `status/`-Flag, für vom Menschen
+angelegte Stubs, die nie so umgesetzt werden dürfen, wie sie dastehen.
+
+`kb/concepts/Issue Label Scheme.md` bildet weiter den Stand vom 2026-09-02 ab:
+
+- Die `status/`-Tabelle (Zeilen 56-59) listet nur `blocked` und `unconfirmed`.
+- Der Satz darunter behauptet „Sechzehn Labels stehen in Gitea" — es sind 17 (`label_read
+  list_repo_labels` gegen `torben/chemenu`, 2026-09-04).
+- `summary:` im Frontmatter sagt „plus zwei optionale status/-Flags".
+- Die Aussage, dass alle vier Achsen Pflicht sind, gilt unter `status/incoming` ausdrücklich
+  nicht — dieses Flag setzt die Pflicht aus, statt sie zu qualifizieren. Genau das ist der
+  interessante Teil und fehlt der Seite ganz.
+
+#### Warum das nicht in #62 mitlief
+
+`kb/`-Inhalt, nicht Stack. Invariante 3 verlangt eine Quelle: die Seite steht heute auf zwei
+Sources (`Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31`, `Gitea
+Issue 41 - Issue Management and Label Scheme 2026-09-02`), und für das dritte Flag gibt es noch
+keine. Eine `stack-dev`-Sitzung darf sie nicht ersatzweise erfinden.
+
+#### Akzeptanzkriterien
+
+- [ ] Eine Quelle für den Stand nach `4.7.5` liegt in `raw/` und ist als Source-Seite
+      ingestiert (das Muster der bestehenden Gitea-Issue-41-Source passt: dieses Issue bzw.
+      #62 als Rohnotiz).
+- [ ] Die `status/`-Tabelle der Seite hat drei Zeilen, mit dem Verbot ("nie so umgesetzt, wie
+      es dasteht") in der `incoming`-Zeile.
+- [ ] Die Labelzahl im Fließtext stimmt gegen `label_read` zum Zeitpunkt der Sitzung, oder die
+      Zahl entfällt zugunsten einer nicht-zählenden Formulierung.
+- [ ] Ein Kernpunkt hält fest, dass `status/incoming` die Vier-Achsen-Pflicht aussetzt statt
+      sie zu erfüllen.
+- [ ] `summary:`, `modified:` und `confidence` über `wikitool touch` gezogen, nicht von Hand.
+- [ ] `wikitool lint` grün.
+
+#### Nicht in diesem Paket
+
+Die Ausarbeitung von #60 und #61 — das ist die erste Anwendung der Regel und eine eigene
+`stack-dev`-Sitzung, unabhängig von dieser Seite.
+
+---
+
+## Label-Set in Gitea (gelesen 2026-09-04, `label_read list_repo_labels`)
+
+| Label | Beschreibung |
+|---|---|
+| `area/kb` | Betrifft kb/-Schema, Contract, Confidence, Lint, Wissensbasis |
+| `area/distribution` | Betrifft Auslieferung, Upgrade, Versionierung einer Instanz |
+| `area/corpus` | Betrifft Demo-/Testbett-Frage, Inhalt und Umfang von kb/ |
+| `area/workflow` | Betrifft Git, Merge, Branching, Publish, PRs |
+| `area/process` | Betrifft den Entwicklungsprozess selbst, nicht den Stack als Artefakt |
+| `kind/decision` | Wartet auf eine Betreiberentscheidung |
+| `kind/build` | Spezifiziert, wartet nur noch auf Umsetzungszeit |
+| `kind/defect` | Befund: Doku und Realitaet, oder zwei Dokus, widersprechen sich |
+| `prio/blocking` | Blockiert oder beschaedigt laufende Arbeit - als naechstes |
+| `prio/planned` | Traegt bald Zinsen - eingeplant |
+| `prio/waiting` | Sinnvoll, wartet auf einen Ausloeser |
+| `size/S` | Eine Sitzung, ein Publish, klar umrissener Schnitt |
+| `size/M` | Mehrere Dateien, Contract- oder Instruction-Aenderung, eigener Testaufwand |
+| `size/L` | Mehrere Sitzungen oder offene Designfragen vor dem ersten Commit |
+| `status/blocked` | Wartet auf ein anderes, noch offenes Issue - nicht eigenstaendig bearbeitbar |
+| `status/incoming` | Vom Menschen angelegte Anforderung, unvollständig, muss durch den Stack komplettiert werden. |
+| `status/unconfirmed` | Gemeldeter Verdacht, noch nicht gegen tatsaechliches Verhalten geprueft - size/prio vorlaeufig |
+
+Siebzehn Labels. Gegenüber dem Stand vom 2026-09-02 (Source "Gitea Issue 41 - Issue Management
+and Label Scheme 2026-09-02") ist genau eines neu: `status/incoming`.