From a0aecfcf94aa3755a18a13de9125fe87b18e3b07 Mon Sep 17 00:00:00 2001 From: Torben Nehmer Date: Fri, 4 Sep 2026 22:08:02 +0200 Subject: [PATCH] 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 | 2 +- kb/concepts/Issue Label Scheme.md | 34 +++- kb/index.md | 8 +- kb/log.md | 12 ++ kb/provenance.md | 9 +- kb/sources/INDEX.md | 3 +- ...-incoming Label Introduction 2026-09-04.md | 87 ++++++++ ...-incoming Label Introduction 2026-09-04.md | 187 ++++++++++++++++++ 8 files changed, 326 insertions(+), 16 deletions(-) create mode 100644 kb/sources/Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md create mode 100644 raw/notes/Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md diff --git a/kb/concepts/INDEX.md b/kb/concepts/INDEX.md index d7d1e68..58e12e3 100644 --- a/kb/concepts/INDEX.md +++ b/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 | diff --git a/kb/concepts/Issue Label Scheme.md b/kb/concepts/Issue Label Scheme.md index e9f724d..d1ab830 100644 --- a/kb/concepts/Issue Label Scheme.md +++ b/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]] diff --git a/kb/index.md b/kb/index.md index 1bda4ad..0486354 100644 --- a/kb/index.md +++ b/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 -- **Last Updated:** 2026-09-03 +- **Sources:** 29 +- **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/ diff --git a/kb/log.md b/kb/log.md index f6a8515..6b5b4bd 100644 --- a/kb/log.md +++ b/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. + +--- diff --git a/kb/provenance.md b/kb/provenance.md index f165b3b..fc23403 100644 --- a/kb/provenance.md +++ b/kb/provenance.md @@ -8,8 +8,8 @@ inline `[^cite-id]` footnote). ## Coverage Summary -- **Total raw files:** 28 -- **Covered:** 28 +- **Total raw files:** 29 +- **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]] diff --git a/kb/sources/INDEX.md b/kb/sources/INDEX.md index c354b25..04fd8a6 100644 --- a/kb/sources/INDEX.md +++ b/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 | diff --git a/kb/sources/Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md b/kb/sources/Source - Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md new file mode 100644 index 0000000..652c13f --- /dev/null +++ b/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]] diff --git a/raw/notes/Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md b/raw/notes/Gitea Issues 62-63 - status-incoming Label Introduction 2026-09-04.md new file mode 100644 index 0000000..2953e4b --- /dev/null +++ b/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 + 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`.