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

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

• status/incoming in Schritt 5s Tabelle, mit ausdrücklichem Absatz, dass die vier Pflichtlabel unter diesem Flag noch nicht fällig sind
• Eigener Abschnitt mit der Prozedur, Verbot als erste Aussage
• § When to run und § Decision points nennen den Fall je einmal
• Schrittnummerierung 1-7 unverändert
• Frontmatter description: nennt drei status/-Flags
• tools/wikitool instructions verify und docs verify grün
• tools/.venv/bin/python -m pytest -q: 976 passed
• 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.