issue-tracking: status/incoming - Stubs werden ausgearbeitet, nie so umgesetzt (4.7.5-beta.1, #62)

Files changed:
- CHANGES.md
- VERSION
- instructions/dev/issue-tracking.md
- instructions/dev/stack-dev/SKILL.md

CHANGES.md

@@ -35,6 +35,61 @@ dev-checkout concern - readable here, never shipped as something to parse.
 
 ---
 
+## 4.7.5-beta.1 - 2026-09-04 - status/incoming: menschliche Stubs werden ausgearbeitet, nie so umgesetzt
+
+**Author:** Torben Nehmer
+
+<!-- wikitool:bumps -->
+- status/incoming: menschliche Stubs werden ausgearbeitet, nie so umgesetzt
+<!-- /wikitool:bumps -->
+
+Das Label `status/incoming` gibt es seit heute in Gitea: der Mensch legt einen
+Stub an — zwei Sätze, ein Verdacht, ein „wäre interessant" — und der Stack
+komplettiert ihn. `instructions/dev/issue-tracking.md` beschrieb es nicht, und
+das ist die gefährlichere Hälfte: ein Stub *sieht aus wie* ein Body, und der
+Body ist genau das, was eine Sitzung nach Schritt 2 als Spec glaubt. Zwei
+solche Issues lagen bereits offen auf dem Board (#60, #61).
+
+Neu in der Instruction ist deshalb ein eigener Abschnitt „Incoming stubs" mit
+dem Verbot als erstem Satz — ein `status/incoming`-Issue wird nie so umgesetzt,
+wie es dasteht — und der Ausarbeitung als sechsschrittigem Ablauf: den Wortlaut
+als Absichtserklärung lesen, gegen den Baum prüfen, den Originaltext wörtlich in
+den Kommentar retten, bevor der Rewrite ihn überschreibt, offene Fragen benennen
+statt beantworten (`kind/decision`), erst dann die vier Pflichtlabel, dann das
+Flag entfernen. Zwei Ausgänge wie bei `status/unconfirmed`: ausgearbeitet oder
+mit Begründung geschlossen.
+
+Der interessante Punkt ist Schritt 4: `status/incoming` ist das einzige Flag,
+das Schritt 4 nicht qualifiziert, sondern **aussetzt**. Die vier Pflichtachsen
+fehlen einem Stub nicht, sie sind noch nicht fällig — `kind/`, `prio/` und
+`size/` sind Antworten auf Fragen, die niemand gegen den Baum geprüft hat. Ein
+Stub auf Sicht durchzulabeln ist der Fehler, nicht das Weglassen: es lässt
+Ungeprüftes triagiert aussehen.
+
+Der Schaden, den das verhindert, ist derselbe wie bei #30, nur eine Stufe
+früher: dort schrieb ein Body einen Mechanismus vor und bekam dessen Bugs
+gebaut, hier schreibt ein Body gar nichts vor und bekommt die Lücke von
+demjenigen gefüllt, der ihn am schnellsten gelesen hat — inklusive Close, womit
+die Frage, für die der Stub stand, nie wieder gestellt wird.
+
+Keine neue Schrittnummer, bewusst: `stack-close/SKILL.md` und ältere
+`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.
+
+Geändert: [instructions/dev/issue-tracking.md](instructions/dev/issue-tracking.md)
+(Frontmatter, § When to run, Schritt 5, neuer § Incoming stubs, § What no tool
+checks, § Decision points) und die Routing-Zeile in
+`instructions/dev/stack-dev/SKILL.md`. Dev-only — `dist export` schließt
+`instructions/dev/` aus, eine ausgelieferte Instanz sieht davon nichts, deshalb
+PATCH.
+
+Offen (#62): `kb/concepts/Issue Label Scheme.md` beschreibt weiter nur die
+beiden alten `status/`-Flags. Das ist `kb/`-Inhalt und braucht eine
+`wiki-manage`-Sitzung mit einer Quelle, nicht diese hier.
+
+---
+
 ## 4.7.4 - 2026-09-04 - bootstrap.md nennt den session-id-WARN nach frischem Bootstrap explizit als erwartet
 
 **Author:** Torben Nehmer