# Gitea Issues #62 und #63 — Einführung `status/incoming` und die dadurch veraltete kb-Seite Wörtliche Kopie zweier zusammenhängender Issue-Threads von und , 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`.