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
This commit is contained in:
@@ -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`.
|
||||
Reference in New Issue
Block a user