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:
@@ -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 |
|
||||
|
||||
@@ -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]]
|
||||
<!-- /wikitool:footnotes -->
|
||||
|
||||
+4
-4
@@ -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/
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
---
|
||||
|
||||
+7
-2
@@ -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]]
|
||||
|
||||
+2
-1
@@ -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 |
|
||||
|
||||
+87
@@ -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]]
|
||||
@@ -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