feat: Link-Taxonomie abgeschlossen - Lint hart ab kb_version 4.0.0, outbound: an Type-Spec gebunden, part-of/composition als Inversenpaar (4.1.0, #40 )

Files changed: - CHANGES.md - VERSION - instructions/link-taxonomy.md - instructions/migrations/4.0.0-link-taxonomy.md - kb/comparisons/amd-pstate vs acpi-cpufreq.md - kb/concepts/Episodic Memory.md - kb/concepts/Memory Lifecycle.md - kb/concepts/Mesh Sync.md - kb/concepts/Procedural Memory.md - kb/concepts/Reciprocal Rank Fusion.md - kb/concepts/Semantic Memory.md - kb/concepts/Shared vs Private.md - kb/concepts/Split Threshold.md - kb/concepts/Stub Threshold.md - kb/concepts/Supersession.md - kb/concepts/Typed Relationships.md - kb/concepts/Vector Search.md - kb/concepts/Work Coordination.md - kb/concepts/Working Memory.md - kb/entities/technologies/Wine-Staging.md - kb/entities/tools/pascalandy schema.md - kb/index.md - kb/log.md - kb/sources/COLLECTION.md - tools/CONTRACT.md - tools/chemenu/commands/lint.py - tools/chemenu/kb_collections.py - tools/chemenu/lint_core.py - tools/chemenu/tests/test_conventions.py - tools/chemenu/tests/test_lint.py - tools/chemenu/tests/test_type_resolver.py - types/comparison.md - types/comparison.schema.yaml
feat(kb): Issue Label Scheme auf Vierachsen-Schema und Body-als-Wahrheit nachgezogen (#41 )
2026-09-03 06:19:56 +02:00 · 2026-09-02 23:20:39 +02:00
41 changed files with 725 additions and 117 deletions
@@ -20,6 +20,68 @@ their date-only headings.
 ---
 ## 4.1.0 - 2026-09-03 - Link-Taxonomie: Lint-Findings hart ab kb_version 4.0.0, outbound: an das Type-Spec gebunden, part-of/composition als Inversenpaar
 **Author:** Torben Nehmer
 Der Rest von Issue #40, nachdem die Korpus-Migration durch ist: die beiden aufgeschobenen
 Lint-Findings werden hart, und die drei Befunde aus dem Abschlusskommentar des Migrationslaufs
 werden aufgelöst.
 **`unlabelled_edges` und `unauthorised_labels` sind harte Fehler — aber an `kb_version`
 gebunden, nicht an ein Datum.** Der Weg, den `legacy_citation_markers` genommen hat, war ein
 Umlegen in einer späteren Version: eine Instanz, die die Zitat-Migration noch schuldete, lebte
 danach mit rotem Lint. Das Ledger kann die Frage inzwischen beantworten, also tut es das.
 Unterhalb `kb_version` 4.0.0 bleiben beide beratend — genau das Fenster, in dem
 `instructions/migrations/4.0.0-link-taxonomy.md` der Instanz sagt, sie solle den halb
 konvertierten Korpus Einheit für Einheit publizieren; ein Check, der dabei fehlschlägt, würde
 den Korpus verweigern, dessen Fortschritt er misst. Ab 4.0.0 ist eine kahle Titelangabe in
 `related:` keine Seite mehr, die auf ihre Umstellung wartet, sondern eine Kante, deren Autor
 nicht gesagt hat, was sie behauptet. `hard_error_keys()` liefert die jeweils geltende Menge,
 `HARD_ERROR_KEYS` bleibt die vollständige.
 **`outbound:` ist an das Type-Spec gebunden.** `kb/sources/` und `kb/comparisons/`
 autorisierten Label, die dort strukturell nicht schreibbar waren: keiner der beiden Type-Specs
 führte ein `related:`. Folgenlos war das nicht — die einzige Comparison-Seite des Korpus trug
 `- **compares-with:** [[amd-pstate]]` als *handgeschriebene Prosa*, ohne Marker-Region, ohne
 Frontmatter, für `lint` unsichtbar. Also ein Identifier zurück im Fließtext, gut vier Stunden
 nachdem 4.0.0 genau das beendet hatte. Eine leere Autorisierung liest sich als Lizenz.
 Aufgelöst nach dem, was die beiden Contracts jeweils selbst sagen: `comparison` bekommt ein
 `related:` (die `compares-with`-Kante gegen jedes Subjekt ist die eine Aussage, für die die
 Seite existiert), `kb/sources/` verliert seinen `outbound:`-Block ersatzlos (dessen Contract
 sagt ausdrücklich, seine Verknüpfungen seien der mechanische Provenance-Pfad und keine
 Autorenkanten). Neu prüft `docs verify` die Kombination: ein `outbound:`-Block auf einer
 Collection, in die kein Typ mit `related:` schreibt, ist ein Befund und nennt beide Richtungen
 der Reparatur.
 **`composition` / `part-of` ist das dritte Inversenpaar**, neben `depends-on` / `required-by`
 und `runs-on` / `hosts`. Aus der Messung, nicht vom Schreibtisch: der u3-Lauf hatte entschieden,
 die Gegenseite eines `composition` bekomme `see-also`, weil `part-of` ein Spiegel wäre. Ist es
 nicht — der Satz des Elternteils zählt seine Teile auf, der des Kindes benennt das Ganze, zu
 dem es gehört, und ein Leser, der auf dem Kind landet, braucht den zweiten. Übrig blieben 16
 `see-also`-Kanten für eine Beziehung, für die der Katalog ein Wort hat; sie sind auf `part-of`
 umgestellt. Ein Inversenpaar macht die Gegenkante weiterhin **nicht** zur Pflicht — Richtung
 wird verfasst, nicht gespiegelt —, es legt nur fest, welches Label sie trägt, wenn jemand sie
 schreibt.
 **Stack- und Korpusänderung laufen hier in einem Zug**, entgegen der sonstigen Trennung. Der
 neue `docs verify`-Check würde eine bestehende 4.0.x-Instanz beim bloßen Kopieren der neuen
 Maschinerie fehlschlagen lassen, weil deren `kb/sources/COLLECTION.md` den `outbound:`-Block
 noch trägt — nach [instructions/dev/version-parts.md](instructions/dev/version-parts.md)
 Schritt 1 ein Grenzübertritt. Statt dafür eine `5.0.0` zu lösen, ist die Ursache mitbeseitigt:
 die Collection-Contracts dieser Instanz sind angepasst, und `dist export` leitet die
 `COLLECTION.md.template` daraus ab, also liefert jede neue Distribution die korrigierte Form
 aus. Für eine bereits bestehende 4.0.x-Instanz bleibt eine Handbewegung übrig, und sie wird
 hier benannt statt versteckt: die zwei `outbound:`-Zeilen aus `kb/sources/COLLECTION.md`
 löschen. Das neue `related:` im `comparison`-Type-Spec erreicht sie ohnehin nicht — die vier
 Page-Type-Specs gehören seit 4.0.0 der Instanz und werden nur als `.template` ausgeliefert.
 Offen aus #40 bleibt nichts mehr; Befund 2 des Migrationslaufs (dem Katalog fehlt ein Register
 für Urheberschaft) ist als eigenes Issue erfasst.
 ---
 ## 4.0.1 - 2026-09-02 - Issue-Board: vier Pflicht-Label-Familien und Body-als-Wahrheit
 **Author:** Torben Nehmer
@@ -1 +1 @@
-4.0.1
+4.1.0
@@ -40,9 +40,18 @@ edge merely to mirror the first one.** The inbound view is rendered from the gra
 `index rebuild` and `search`, so a reader landing on the target sees what points at it whether
 or not anyone wrote a second edge.
-That is why most labels below have no inverse. Only two pairs do, because in each the reverse
+That is why most labels below have no inverse. Only three pairs do, because in each the reverse
 direction is a genuine primary statement someone would write on its own: `depends-on` /
-`required-by` and `runs-on` / `hosts`.
+`required-by`, `runs-on` / `hosts`, and `composition` / `part-of`.
 The third was added after the 4.0.0 migration, from measurement rather than from the desk. A
 parent-child structure - a tier list and its tiers, a spectrum and its levels - produces the
 question on nearly every page: the parent writes `composition`, and the child then reaches for
 either `part-of` or `see-also`. The migration run answered `see-also`, on the reading that
 `part-of` would be a mirror, and left sixteen edges saying "these two are related" about a
 relationship the catalogue already had a word for. It is not a mirror: the parent's sentence
 lists its parts, the child's names the whole it belongs to, and a reader landing on the child
 needs the second one.
 ## When to run
@@ -129,6 +138,13 @@ Inference and comparison between ideas.
 | `composition` | is composed of the target |
 | `part-of` | is a component of the target |
 `composition` / `part-of` is the third **inverse pair**, alongside `depends-on` / `required-by`
 and `runs-on` / `hosts` in the operational register. Being a pair does not make the second edge
 obligatory - direction is still authored - it settles *which label* the second edge takes when
 someone does write it. The child of a `composition` writes `part-of`, not `see-also`: what it
 is a component of is a primary statement about the child, and `see-also` says strictly less
 about the same fact.
 `grounds` / `rests-on` is a genuine pair and both directions are primary statements; they are
 listed separately rather than as inverses because either page may legitimately carry only its
 own side.
@@ -36,8 +36,9 @@ you know the run is finished.
 **Nothing breaks while it is outstanding.** Unlabelled edges and undelimited regions are read,
 not rejected: `links.py` treats a bare title as an edge whose label is not declared yet, and
 `provenance.split_cite_block` falls back to the pre-marker layout. That is deliberate - a corpus
-has to stay readable while it is being converted - and it is why the two lint findings are
+has to stay readable while it is being converted - and it is why the two lint findings stay
-advisory until step 6 promotes them.
+advisory for as long as `kb_version` is below 4.0.0, which is exactly as long as this document
 is outstanding.
 ## Steps
@@ -102,7 +103,7 @@ advisory until step 6 promotes them.
   is otherwise silent: the region becomes ordinary prose and the next write appends a second
   one beside it.
-6. **Record it, then tighten the checks:**
+6. **Record it. The checks tighten themselves:**
   ```bash
   tools/wikitool lint          # unlabelled_edges and unauthorised_labels must be 0
@@ -110,8 +111,14 @@ advisory until step 6 promotes them.
   ```
   Only once `lint` reports zero of both is the run finished. The two findings are advisory
-   during the window and become hard errors afterwards - the same path
+   while `kb_version` is below 4.0.0 and hard from the moment `migrate done` records it -
-   `legacy_citation_markers` took after the citation migration.
+   nothing to flip by hand, and no window in which a half-converted corpus is refused by the
   check that is measuring its progress.
   Do not record the migration to silence the findings. The promotion is what makes the run
   stick: after it, a bare title in `related:` is a hard error rather than a page still
   waiting, so a corpus recorded early fails its next lint instead of quietly keeping the old
   shape.
 ## How to tell a migrated page from an unmigrated one
@@ -3,8 +3,10 @@ type: types/comparison.md
 tags: [kernel, power-management, amd, cpu, driver]
 created: 2026-07-31
 entities: [amd-pstate, acpi-cpufreq]
-summary: "Vergleich zweier AMD-CPU-Power-Management-Treiber: CPPC-basiertes amd-pstate gegen\xFC\
+summary: "Vergleich zweier AMD-CPU-Power-Management-Treiber: CPPC-basiertes amd-pstate gegen\xFCber ACPI-basiertem acpi-cpufreq."
-  ber ACPI-basiertem acpi-cpufreq."
+related:
  - compares-with: amd-pstate
  - compares-with: acpi-cpufreq
 ---
 # Comparison: amd-pstate vs acpi-cpufreq
@@ -131,8 +133,9 @@ ls /sys/devices/system/cpu/cpu0/cpufreq/cppc_*
 **amd-pstate** stellt einen bedeutenden Fortschritt in der CPU-Energieverwaltung für AMD-Prozessoren dar und bietet fein-körnige Steuerung, bessere Effizienz und verbessertes Batterielebensdauer. **acpi-cpufreq** bleibt ein zuverlässiger Fallback und dient weiterhin älterer Hardware. Die Wahl zwischen ihnen hängt hauptsächlich von Hardware-Unterstützung und Kernel-Version ab, wobei amd-pstate die klare Präferenz für moderne AMD-Systeme ist.
 <!-- wikitool:links -->
 ## Beziehungen
 - **compares-with:** [[amd-pstate]]
 - **compares-with:** [[acpi-cpufreq]]
-
+<!-- /wikitool:links -->
@@ -5,7 +5,7 @@ tags: []
 created: 2026-08-02
 modified: 2026-08-29
 related:
-  - see-also: Consolidation Tiers
+  - part-of: Consolidation Tiers
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -41,5 +41,5 @@ TODO
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[Consolidation Tiers]]
+- **part-of:** [[Consolidation Tiers]]
 <!-- /wikitool:links -->
@@ -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 | Zweiachsiges Pflicht-Labelschema fuer das Gitea-Board: prio/1..3 und size/XS..L, bewusst keine dritte Achse; die Regel liegt in instructions/dev/, weil sie keine ausgelieferte Instanz erreichen darf | 2026-08-31 |
+| [[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 |
 | [[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-08-31
+modified: 2026-09-02
 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]
+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]
 confidence: 0.70
-confidence_base: 0.70
+confidence_base: 0.85
 provenance: sourced
-summary: 'Zweiachsiges Pflicht-Labelschema fuer das Gitea-Board: prio/1..3 und size/XS..L, bewusst keine dritte Achse; die Regel liegt in instructions/dev/, weil sie keine ausgelieferte Instanz erreichen darf'
+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'
 ---
 # Issue Label Scheme
@@ -22,36 +22,78 @@ summary: 'Zweiachsiges Pflicht-Labelschema fuer das Gitea-Board: prio/1..3 und s
 ## Definition
 Issue Label Scheme ist die Entscheidung, offene Arbeit an diesem Stack ausschließlich als
-Gitea-Issues zu führen und jedes Issue mit genau zwei Pflicht-Labels zu versehen: einer
+Gitea-Issues zu führen und jedes offene Issue mit vier Pflicht-Labels zu versehen: einem
-Priorität `prio/1..3` und einer Größe `size/XS..L`. Eine dritte Achse gibt es bewusst nicht.
+Bereich `area/`, einer Art `kind/`, einer Priorität `prio/` und einer Größe `size/`. Dazu
-Getroffen wurde die Entscheidung am 2026-08-31, gemeinsam mit der Löschung von `TODO.md`[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
+kommen zwei 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)).
-| Priorität | Bedeutung |
+| `area/` | Bedeutung |
 |---|---|
-| `prio/1` | Blockiert oder beschädigt laufende Arbeit. Als Nächstes. |
+| `area/kb` | `kb/`-Schema, Contract, Confidence, Lint - die Wissensbasis als System. |
-| `prio/2` | Sammelt Zinsen. Eingeplant. |
+| `area/distribution` | Auslieferung, Upgrade und Versionierung einer Instanz. |
-| `prio/3` | Lohnend, wartet auf einen benannten Auslöser. |
+| `area/corpus` | Inhalt und Umfang von `kb/` in dieser Instanz, samt Demo-/Testbett-Frage. |
 | `area/workflow` | Git, Merge, Branching, Publish, PRs. |
 | `area/process` | Der Entwicklungsprozess selbst, nicht der Stack als Artefakt. |
-| Größe | Bedeutung |
+| `kind/` | Bedeutung |
 |---|---|
 | `kind/decision` | Wartet auf eine Betreiberentscheidung. |
 | `kind/build` | Spezifiziert, wartet nur noch auf Umsetzungszeit. |
 | `kind/defect` | Befund: Doku und Realität, oder zwei Dokus, widersprechen sich. |
 | `prio/` | Bedeutung |
 |---|---|
 | `prio/blocking` | Blockiert oder beschädigt laufende Arbeit. Als Nächstes. |
 | `prio/planned` | Sammelt Zinsen. Eingeplant. |
 | `prio/waiting` | Lohnend, wartet auf einen benannten Auslöser. |
 | `size/` | Bedeutung |
 |---|---|
 | `size/XS` | Minuten. Oft nur eine Entscheidung oder eine Beobachtung. |
 | `size/S` | Eine Sitzung, ein Publish, ein klarer Schnitt. |
 | `size/M` | Mehrere Dateien; eine Contract- oder Instruction-Änderung; eigener Testaufwand. |
 | `size/L` | Mehrere Sitzungen, oder offene Entwurfsfragen vor dem ersten Commit. |
-Die sieben Labels wurden angelegt und auf alle zehn zu dem Zeitpunkt offenen Issues
+| `status/` (optional) | Bedeutung |
-angewandt[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
+|---|---|
 | `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. |
 Sechzehn 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
- **Beide Achsen sind Pflicht, weil eine Priorität ohne Kosten eine halbe Entscheidung ist.**
+- **Vier Achsen sind Pflicht, weil ihre Pflege maschinell läuft.** Der ursprüngliche Einwand
-  Größe ist Aufwand und nicht Wichtigkeit, deshalb ist `prio/1 size/XS` das Beste, was auf
+  gegen eine dritte Achse war der Aufwand für einen einzelnen menschlichen Betreuer. Da
-  einem Board stehen kann, und `prio/3 size/L` etwas, worüber gesprochen wird, bevor jemand
+  Body-Rewrites und Labelpflege über eine LLM-Sitzung laufen und ein Mensch in der Regel nur
-  anfängt.
+  Metadaten anfasst, trägt dieser Einwand
- **`prio/3` ist kein Friedhof.** Der Auslöser muss im Issue benannt sein, sonst ist das Label
+  nicht mehr[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
-  ein höfliches Nein[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
+- **Der Issue-Body ist die aktuelle Wahrheit, nicht der Ursprungstext.** Die Umsetzung eines
- **Keine dritte Achse.** Art, Bereich oder Status wurden verworfen als der Punkt, ab dem eine
+  Issues zieht sich über mehrere, zeitlich getrennte Sitzungen, und der Body ist das einzige,
-  Taxonomie eigene Pflege braucht. Das Board hat einen einzigen Betreuer.
+  was sie verbindet: eine Sitzung muss allein aus ihm rekonstruieren können, was entschieden
  und was offen ist. Er wird deshalb umgeschrieben statt
  ergänzt[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
 - **Ein Kommentar ist ein Changelog, keine Kopie.** Ein Volltext-Snapshot des alten Bodys pro
  Revision zwingt einen Menschen zum Diffen zweier Fließtexte und ist damit keine lesbare
  Historie, sondern nur eine weitere
  Kopie[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
 - **`area/` folgt der Systemgrenze, nicht dem Codeort.** Die Werte folgen der Stufenteilung aus
  `AGENTS.md`. Ein `area/tools` gibt es bewusst nicht - Tooling wird nach der Domäne
  einsortiert, die es
  bedient[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
 - **`kind/` darf sich im Lauf eines Issues ändern.** Der Wechsel von `decision` zu `build`,
  sobald entschieden ist, ist erwünschtes Session-Memory-Verhalten und kein
  Makel[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
 - **Eine Priorität ohne Kosten ist eine halbe Entscheidung.** Größe ist Aufwand und nicht
  Wichtigkeit, deshalb ist `prio/blocking size/S` das Beste, was auf einem Board stehen kann,
  und `prio/waiting size/L` etwas, worüber gesprochen wird, bevor jemand anfängt.
 - **`prio/waiting` ist kein Friedhof.** Der Auslöser muss im Issue benannt sein, sonst ist das
  Label ein höfliches Nein[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
 - **Kein unbelegter Verdacht bleibt offen liegen.** Die Triage eines `status/unconfirmed`
  endet entweder mit entferntem Flag und verbindlichen `size`/`prio`-Werten oder mit einem
  geschlossenen Issue samt Begründung - die Prozessentsprechung zu Invariante 3 des
  Stacks[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
 - **Priorisiert wird nach Schaden, nicht nach Aufwand.** Das Kriterium der ersten Triage
  lautete: was blockiert oder beschädigt laufende Arbeit. Ein Werkzeugfehler, der seinen
  Benutzer gegen eine Invariante des Stacks drückt, rangiert deshalb vor einer fehlenden
@@ -63,6 +105,28 @@ angewandt[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-0
  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.
 ## Historie
 Das ursprüngliche Schema vom 2026-08-31 hatte ~~genau zwei Pflicht-Labels, `prio/1..3` und
 `size/XS..L`, und verzichtete ausdrücklich auf eine dritte Achse: Art, Bereich oder Status
 wurden verworfen als der Punkt, ab dem eine Taxonomie eigene Pflege braucht, und das Board
 habe einen einzigen Betreuer.~~ Sieben Labels wurden angelegt und auf alle zehn zu dem
 Zeitpunkt offenen Issues
 angewandt[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
 Was sich am 2026-09-02 geändert hat:
 | Achse | Vorher | Jetzt |
 |---|---|---|
 | `prio/` | `1`, `2`, `3` | `blocking`, `planned`, `waiting` - reine Umbenennung, Bedeutung unverändert |
 | `size/` | `XS`, `S`, `M`, `L` | `S`, `M`, `L` - `XS` entfällt, die übrigen unverändert |
 | `area/` | - | fünf Werte, neu |
 | `kind/` | - | drei Werte, neu |
 | `status/` | - | zwei optionale Flags, neu |
 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.
 ## Wo die Regel liegt
 Die Platzierung war die tragende Entscheidung, nicht das Schema selbst. `README.md` und
@@ -80,42 +144,42 @@ Instanz ändert sich nichts. Das CI-Versions-Gate verlangte den Bump trotzdem, w
 auf `instructions/` passt und `instructions/dev/` darunter liegt[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]. Siehe
 [[KB Stack Versioning]].
 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].
 ## Beispiele
- [[Chemenu]] - das Repository, dessen Board nach dem Schema geführt wird; sieben Labels
+- [[Chemenu]] - das Repository, dessen Board nach dem Schema geführt wird; sechzehn Labels
-  wurden angelegt und auf alle zehn offenen Issues angewandt
+  stehen dort, verteilt auf vier Pflicht- und eine optionale Familie
- [[Gitea MCP Server]] - der Weg, auf dem Issues und Labels gelesen und geschrieben werden, da
+- [[Gitea MCP Server]] - der Weg, auf dem Issues und Labels gelesen und geschrieben werden
  das Origin-Repository privat ist
 - [[Detect-Repair Asymmetry]] - Issue #14 ist der Fall, den dieses Concept beschreibt, und
-  trägt `prio/2 size/S`
+  trug in der ersten Triage `prio/2 size/S`, nach der Umbenennung also `prio/planned size/S`
 ## Wann zu verwenden
- Auf einem Board mit einem einzigen Betreuer, das eine erkennbare Reihenfolge braucht, aber
+- Auf einem Board mit einem einzigen menschlichen Betreuer, dessen Labelpflege maschinell
-  keinen Prozess.
+  läuft. Erst das macht mehr als zwei Achsen bezahlbar.
 - Sobald offene Arbeit sonst in Prosa-Dateien wandert, die niemand als Board liest und die
  gegen den Tracker driften.
 - Sobald die Bearbeitung eines Issues sich über mehrere, zeitlich getrennte Sitzungen zieht -
  dann trägt die Body-als-Wahrheit-Konvention den Kontext, den sonst ein Mensch jedes Mal neu
  erzählen müsste.
 ## Wann NICHT zu verwenden
- Nicht auf einem Board mit mehreren Teams, wo Zuständigkeit und Bereich echte Information
+- Nicht dort, wo Labels von Hand gepflegt werden. Dann ist die ursprüngliche Zweiachsigkeit
-  tragen. Dann ist die dritte Achse keine Taxonomie-Pflege, sondern Routing.
+  die tragfähigere Wahl, und die Begründung von 2026-08-31 gilt unverändert.
 - Nicht als Ersatz für die Abnahmekriterien im Issue-Text. Die Labels ordnen ein Issue ein; ob
  es fertig ist, sagen sie nicht.
 - Nicht mit umgeschriebenen Bodys dort, wo mehrere Menschen denselben Thread lesen und den
  Verlauf brauchen. Die Konvention tauscht Historie gegen Aktualität und setzt voraus, dass
  der Changelog-Kommentar als Historie genügt.
 - Nicht in einer ausgelieferten Instanz. Das Schema beschreibt das Entwicklungs-Repository und
  hat außerhalb davon keinen Gegenstand.
 ## Beziehungen
 ## Siehe auch
 - [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
 ## Fußnoten
 [^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]: [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **operates-on:** [[Chemenu]]
@@ -123,3 +187,10 @@ auf `instructions/` passt und `instructions/dev/` darunter liegt[^s-conversation
 - **see-also:** [[KB Stack Versioning]]
 - **see-also:** [[Detect-Repair Asymmetry]]
 <!-- /wikitool:links -->
 <!-- wikitool:footnotes -->
 ## Fußnoten
 [^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]]
 <!-- /wikitool:footnotes -->
@@ -5,7 +5,7 @@ tags: [memory, lifecycle, confidence, knowledge-management]
 created: 2026-07-26
 modified: 2026-08-29
 related:
-  - see-also: LLM Wiki Pattern
+  - part-of: LLM Wiki Pattern
  - see-also: Confidence Scoring
  - composition: Supersession
  - see-also: Consolidation Tiers
@@ -126,7 +126,7 @@ Basierend auf [[Agent Memory]]-Erfahrung:
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[LLM Wiki Pattern]]
+- **part-of:** [[LLM Wiki Pattern]]
 - **see-also:** [[Confidence Scoring]]
 - **composition:** [[Supersession]]
 - **see-also:** [[Consolidation Tiers]]
@@ -6,7 +6,7 @@ created: 2026-08-02
 modified: 2026-08-29
 related:
  - exemplifies: Implementation Spectrum
-  - see-also: Multi-Agent Collaboration
+  - part-of: Multi-Agent Collaboration
  - evidenced-by: Source - LLM Wiki v2
 sources: []
 confidence: 0.50
@@ -46,6 +46,6 @@ TODO
 ## Beziehungen
 - **exemplifies:** [[Implementation Spectrum]]
- **see-also:** [[Multi-Agent Collaboration]]
+- **part-of:** [[Multi-Agent Collaboration]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -5,7 +5,7 @@ tags: []
 created: 2026-08-02
 modified: 2026-08-29
 related:
-  - see-also: Consolidation Tiers
+  - part-of: Consolidation Tiers
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -43,5 +43,5 @@ TODO
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[Consolidation Tiers]]
+- **part-of:** [[Consolidation Tiers]]
 <!-- /wikitool:links -->
@@ -5,7 +5,7 @@ tags: []
 created: 2026-08-02
 modified: 2026-08-29
 related:
-  - see-also: Hybrid Search
+  - part-of: Hybrid Search
  - exemplifies: LLM Wiki Pattern
  - evidenced-by: Source - LLM Wiki v2
 sources: []
@@ -45,7 +45,7 @@ TODO
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[Hybrid Search]]
+- **part-of:** [[Hybrid Search]]
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -5,7 +5,7 @@ tags: []
 created: 2026-08-02
 modified: 2026-08-29
 related:
-  - see-also: Consolidation Tiers
+  - part-of: Consolidation Tiers
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -43,5 +43,5 @@ TODO
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[Consolidation Tiers]]
+- **part-of:** [[Consolidation Tiers]]
 <!-- /wikitool:links -->
@@ -5,7 +5,7 @@ tags: []
 created: 2026-08-02
 modified: 2026-08-29
 related:
-  - see-also: Multi-Agent Collaboration
+  - part-of: Multi-Agent Collaboration
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -43,5 +43,5 @@ TODO
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[Multi-Agent Collaboration]]
+- **part-of:** [[Multi-Agent Collaboration]]
 <!-- /wikitool:links -->
@@ -5,7 +5,7 @@ tags: [split, threshold, lines, pages]
 created: 2026-08-03
 modified: 2026-08-29
 related:
-  - see-also: Content Quality Control
+  - part-of: Content Quality Control
  - see-also: Stub Threshold
  - see-also: Index Scaling
 sources: [Source - LLM Improvements Sonnet Analysis]
@@ -69,7 +69,7 @@ Split Threshold definiert die maximale Größe, die eine Wiki-Seite erreichen so
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[Content Quality Control]]
+- **part-of:** [[Content Quality Control]]
 - **see-also:** [[Stub Threshold]]
 - **see-also:** [[Index Scaling]]
 <!-- /wikitool:links -->
@@ -5,7 +5,7 @@ tags: [stub, minimum, quality, lines]
 created: 2026-08-03
 modified: 2026-08-29
 related:
-  - see-also: Content Quality Control
+  - part-of: Content Quality Control
  - see-also: Split Threshold
  - see-also: Semantic Lint Automation
 sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Wiki v2]
@@ -80,7 +80,7 @@ It provides comprehensive information about the topic. It clearly exceeds the st
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[Content Quality Control]]
+- **part-of:** [[Content Quality Control]]
 - **see-also:** [[Split Threshold]]
 - **see-also:** [[Semantic Lint Automation]]
 <!-- /wikitool:links -->
@@ -5,7 +5,7 @@ tags: [versioning, knowledge, updates, lifecycle]
 created: 2026-07-26
 modified: 2026-08-29
 related:
-  - see-also: Memory Lifecycle
+  - part-of: Memory Lifecycle
  - rests-on: Confidence Scoring
  - see-also: Knowledge Graph
  - exemplifies: LLM Wiki Pattern
@@ -138,7 +138,7 @@ Wenn Aussage B Aussage A ersetzt:
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[Memory Lifecycle]]
+- **part-of:** [[Memory Lifecycle]]
 - **rests-on:** [[Confidence Scoring]]
 - **see-also:** [[Knowledge Graph]]
 - **exemplifies:** [[LLM Wiki Pattern]]
@@ -6,7 +6,7 @@ created: 2026-08-02
 modified: 2026-08-29
 related:
  - exemplifies: Implementation Spectrum
-  - see-also: Knowledge Graph
+  - part-of: Knowledge Graph
  - evidenced-by: Source - LLM Wiki v2
 sources: []
 confidence: 0.50
@@ -46,6 +46,6 @@ TODO
 ## Beziehungen
 - **exemplifies:** [[Implementation Spectrum]]
- **see-also:** [[Knowledge Graph]]
+- **part-of:** [[Knowledge Graph]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -5,7 +5,7 @@ tags: []
 created: 2026-08-02
 modified: 2026-08-29
 related:
-  - see-also: Hybrid Search
+  - part-of: Hybrid Search
  - exemplifies: LLM Wiki Pattern
  - evidenced-by: Source - LLM Wiki v2
 sources: []
@@ -45,7 +45,7 @@ TODO
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[Hybrid Search]]
+- **part-of:** [[Hybrid Search]]
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -6,7 +6,7 @@ created: 2026-08-02
 modified: 2026-08-29
 related:
  - exemplifies: Implementation Spectrum
-  - see-also: Multi-Agent Collaboration
+  - part-of: Multi-Agent Collaboration
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -45,5 +45,5 @@ TODO
 ## Beziehungen
 - **exemplifies:** [[Implementation Spectrum]]
- **see-also:** [[Multi-Agent Collaboration]]
+- **part-of:** [[Multi-Agent Collaboration]]
 <!-- /wikitool:links -->
@@ -5,7 +5,7 @@ tags: []
 created: 2026-08-02
 modified: 2026-08-29
 related:
-  - see-also: Consolidation Tiers
+  - part-of: Consolidation Tiers
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -43,5 +43,5 @@ TODO
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[Consolidation Tiers]]
+- **part-of:** [[Consolidation Tiers]]
 <!-- /wikitool:links -->
@@ -14,7 +14,7 @@ related:
  - implements: MCP-Leseserver
  - uses: wikitool
  - composition: AGENTS.md
-sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04, Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31, Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31, Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31, Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31, Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31, 'Source - Public Release, Corpus Purge and History Squash Session 2026-09-01', Source - Publish-Remote Gate and Issue Triage Session 2026-09-01, Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01, Source - MCP Read Server Implementation Session 2026-09-02, Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02]
+sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04, Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31, Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31, Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31, Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31, Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31, 'Source - Public Release, Corpus Purge and History Squash Session 2026-09-01', Source - Publish-Remote Gate and Issue Triage Session 2026-09-01, Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01, Source - MCP Read Server Implementation Session 2026-09-02, Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02, Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02]
 confidence: 0.90
 confidence_base: 0.90
 provenance: mixed
@@ -7,7 +7,7 @@ modified: 2026-08-29
 related:
  - depends-on: Wine
  - see-also: Proton
-  - see-also: Wine GE
+  - part-of: Wine GE
  - see-also: Arch Linux
 sources: [Source - Wine]
 confidence: 0.85
@@ -68,6 +68,6 @@ Wine-Staging-Patches enthalten typischerweise:
 - **depends-on:** [[Wine]]
 - **see-also:** [[Proton]]
- **see-also:** [[Wine GE]]
+- **part-of:** [[Wine GE]]
 - **see-also:** [[Arch Linux]]
 <!-- /wikitool:links -->
@@ -8,7 +8,7 @@ related:
  - implements: Issue Label Scheme
  - uses: Gitea
  - uses: Gitea Actions
-sources: [Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30, Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]
+sources: [Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30, Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31, Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02]
 confidence: 0.70
 confidence_base: 0.70
 provenance: sourced
@@ -5,7 +5,7 @@ tags: [schema, taxonomy, external, farzaa-gist]
 created: 2026-08-03
 modified: 2026-08-29
 related:
-  - see-also: farzaa gist
+  - part-of: farzaa gist
  - see-also: AGENTS.md
  - evidenced-by: Source - LLM Improvements Sonnet Analysis
 sources: [Source - LLM Improvements Sonnet Analysis]
@@ -79,7 +79,7 @@ Dies sind handlungsfähige Empfehlungen, die in der Sonnet-Analyse als wertvoll
 <!-- wikitool:links -->
 ## Beziehungen
- **see-also:** [[farzaa gist]]
+- **part-of:** [[farzaa gist]]
 - **see-also:** [[AGENTS.md]]
 - **evidenced-by:** [[Source - LLM Improvements Sonnet Analysis]]
 <!-- /wikitool:links -->
@@ -13,12 +13,12 @@ The page tables live in a generated `INDEX.md` inside each collection, linked be
 ## Statistics
- **Total Pages:** 180
+- **Total Pages:** 181
 - **Comparisons:** 1
 - **Concepts:** 80
 - **Entities:** 72
- **Sources:** 27
+- **Sources:** 28
- **Last Updated:** 2026-09-02
+- **Last Updated:** 2026-09-03
 ---
@@ -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/` | 27 | [sources/INDEX.md](sources/INDEX.md) |
+| `sources/` | 28 | [sources/INDEX.md](sources/INDEX.md) |
 ### entities/
@@ -121,3 +121,19 @@ Einheit u3 der Link-Taxonomie-Migration: alle 80 Seiten unter kb/concepts/ von P
 Abschluss der Korpus-Migration auf die Link-Taxonomie (Gitea #40, Abschnitte 2 und 3). Zuvor uebersehene Restmenge nachgeholt: 37 unlabelled edges in kb/entities/technologies und kb/entities/tools, die u1 nach dem damaligen 'protect, don't remove'-Muster bewusst unbelegt gelassen hatte - mit der u3-Erkenntnis, dass xref add nur die Quellseite anfasst, waren sie gefahrlos nachlabelbar (Wine-/Arch-/Agent-CLI-Cliquen ueberwiegend see-also, dazu echte Kanten: AUR part-of Arch Linux, Arch Linux uses GPG, Obsidian hosts Dataview/Marp, Obsidian required-by Obsidian Web Clipper, Wine required-by Proton, gdeploy uses Go). Erst damit erfuellt der Korpus das Abschlusskriterium des Migrationsdokuments (Schritt 6: unlabelled_edges und unauthorised_labels muessen 0 sein) - vorher waere migrate done eine unbelegte Behauptung gewesen. Endstand: lint meldet 0 unlabelled_edges, 0 unauthorised_labels, 0 malformed_edges, 0 unbalanced_markers, 0 broken_links, 0 dangling_frontmatter_refs, 0 schema_validation_errors; lint --fail-on-error und docs verify beide exit 0. migrate done 4.0.0 --pages 153 gesetzt, kb_version steht auf 4.0.0. VERSION stand bereits auf 4.0.0 (Bump erfolgte mit dem Mechanismus in u0, Commit 177c7e9), ein zweiter Bump entfaellt daher, und CHANGES.md dokumentiert 4.0.0 bereits vollstaendig. Workshop work/link-taxonomy-migration/ nach work/CONTRACT.md geschlossen und geloescht; die dauerhafte Ausgabe ist der gelabelte Korpus selbst. Eine Notiz aus glossary.md hat sich beim Abschluss als Rueckschritt erwiesen: die dort als Erkenntnis notierte Asymmetrie zwischen xref add (einseitig) und xref remove (bidirektional) steht seit jeher woertlich in tools/CONTRACT.md Zeilen 43-44 - sie war nachzulesen, nicht zu entdecken. Offen und an #40 gemeldet: im Katalog fehlt ein Label fuer Urheberschaft (Person erstellt Entity oder Concept); alle solchen Kanten stehen jetzt auf see-also.
 ---
 ## [2026-09-02] update | Issue Label Scheme - Vierachsen-Schema und Body-als-Wahrheit
 Gitea-Issue #41 als raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md aufgenommen und als Source-Seite erfasst. kb/concepts/Issue Label Scheme.md auf den Stand vom 2026-09-02 gebracht: vier Pflicht-Achsen (area/kind/prio/size), zwei optionale status/-Flags, Body-als-Wahrheit-Konvention. Das abgeloeste Zweiachsen-Schema steht als Abschnitt Historie mit Diff-Tabelle in der Seite, nicht geloescht. confidence_base 0.70 -> 0.85 (zweite unabhaengige Quelle, Bestaetigung juenger als 30 Tage).
 ---
 ## [2026-09-03] update | Link-Taxonomie 4.1.0: 16 see-also-Kanten auf part-of, Comparison-Seite auf gelabelte Kanten
 Befund 3 aus #40: composition/part-of ist jetzt das dritte Inversenpaar. Die 16 Gegenkanten eines composition, die im u3-Lauf auf see-also gesetzt wurden, sind per xref add auf part-of relabelt - betroffen sind Consolidation Tiers, Content Quality Control, Hybrid Search, Knowledge Graph, LLM Wiki Pattern, Memory Lifecycle, Multi-Agent Collaboration, Wine GE und farzaa gist samt ihrer Kinder.
 Befund 1 aus #40: die einzige Comparison-Seite (amd-pstate vs acpi-cpufreq) trug ihre compares-with-Bullets als handgeschriebene Prosa ohne Frontmatter-Deckung, weil types/comparison.md kein related: fuehrte. Der Type-Spec hat es jetzt; die beiden Kanten stehen als deklarierte Kanten in einer wikitool:links-Region. kb/sources/COLLECTION.md hat seinen inerten outbound:-Block verloren.
 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.
 ---
@@ -8,8 +8,8 @@ inline `[^cite-id]` footnote).
 ## Coverage Summary
- **Total raw files:** 26
+- **Total raw files:** 28
- **Covered:** 26
+- **Covered:** 28
 - **Uncovered:** 0
 ---
@@ -106,6 +106,11 @@ inline `[^cite-id]` footnote).
 - Covered by: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
  - Cited by: [[Chemenu]], [[Command Round-Trip Integrity]], [[Denylist over Allowlist]], [[Detect-Repair Asymmetry]], [[Gitea]], [[Green Suite Blind Spot]], [[Write-Once Frontmatter Fields]], [[wikitool]]
 ### `raw/notes/Conversation Transcript - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02.md`
 - Covered by: [[Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02]]
  - Cited by: [[Chemenu]], [[KB Stack Versioning]], [[wikitool]]
 ### `raw/notes/Conversation Transcript - Versioning, CI-CD and Content Migration Session 2026-08-30.md`
 - Covered by: [[Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]]
@@ -121,6 +126,11 @@ inline `[^cite-id]` footnote).
 - Covered by: [[Source - Docker Cheatsheet]]
  - Cited by: [[Docker]]
 ### `raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md`
 - 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/Wine.md`
 - Covered by: [[Source - Wine]]
@@ -1,7 +1,5 @@
 ---
 profile: sources
 outbound:
  any: [is-evidence-for, defined-in, see-also]
 required_by_stack: true
 ---
@@ -40,16 +38,17 @@ The `raw_files:`/`source_url:`/citation rules are shared and live in
 - `tools/wikitool sources trace --raw <path>` answers "what did we learn from this?";
  `tools/wikitool sources coverage` lists raw files no source page claims yet.
-## Authorised labels
+## No authorised labels
-The `outbound:` block above is what `wikitool lint` and `xref add` check: which labels a page in
+This collection has **no `outbound:` block**, and that is the declaration rather than an
-this collection may use, per destination. The catalogue they are drawn from - and what each one
+omission: the `source` type-spec offers no `related:` field, so a source page has nowhere to
-asserts - is [instructions/link-taxonomy.md](../../instructions/link-taxonomy.md), which binds
+put a labelled edge. Everything it would want to assert is already carried by `raw_files:`,
-nothing on its own.
+`entities:`, `concepts:` and `[^cite-id]` - the mechanical provenance path, not authored edges.
-Deliberately narrow. A source page is evidence *about* a source; almost everything it would want to say is already carried by `raw_files:`, `sources:` and `[^cite-id]`, which are the mechanical provenance path rather than authored edges.
+An `outbound:` block here would authorise labels that no page in this collection can write.
-
+`wikitool docs verify` refuses that combination, so the two cannot drift apart: giving source
-Adding a label here is a deliberate contract change, not a way around a refusal.
+pages labelled edges means giving the type-spec a `related:` field first, which is a deliberate
 contract change and not a way around a refusal.
 ## Outbound linking
@@ -2,7 +2,7 @@
 # kb/sources/ - Index
-27 page(s). Regenerated by `wikitool index rebuild`.
+28 page(s). Regenerated by `wikitool index rebuild`.
 ## All
@@ -23,6 +23,7 @@
 | [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]] | notes | Sitzung, die write-once-Frontmatterfelder reparierbar macht: touch bekommt --set/--add/--remove ueber eine Denylist statt einer Allowlist, ein idempotentes --remove und einen bewusst engen Scope (Stack 1.4.0, Gitea-Issue #14) | 2026-08-31 |
 | [[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 - 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 |
@@ -0,0 +1,96 @@
 ---
 type: types/source.md
 source_type: notes
 author: Torben Nehmer
 raw_files: [raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md]
 source_language: de
 date: 2026-09-02
 tags: [issues, gitea, labels, triage, process]
 entities: [Chemenu, Gitea MCP Server]
 concepts: [Issue Label Scheme]
 summary: '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'
 ---
 # Source: Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02
 **Autor:** Torben Nehmer  
 **Datum:** 2026-09-02  
 **Raw-Dateien:** raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md  
 **Typ:** Notes
 ## Zusammenfassung
 Wörtliche Kopie des Threads zu Gitea-Issue #41, gezogen am 2026-09-02: Issue-Body im Stand
 nach der Umsetzung, die drei Changelog-Kommentare und das zu diesem Zeitpunkt in Gitea
 angelegte Label-Set. Das Issue hält eine Diskussion vom selben Tag fest, die aus der
 Aufarbeitung von fünf als "Fallouts" des Entwicklungsprozesses eingestuften Issues (#38, #30,
 #28, #7, #27) hervorging und den Rahmen für deren Bearbeitung setzen sollte.
 Verhandelt wurden drei Dinge. Erstens bleibt ein eingehender Wunsch ein Issue und wird keine
 `kb/`-Seite, weil Issues ephemer sind und Wünsche abbilden - neu ist daran nur, wie ein Issue
 gepflegt wird: der Body ist aktuelle Wahrheit und wird umgeschrieben, Kommentare tragen einen
 Changelog statt einer Vollkopie, und beides macht in der Regel eine LLM-Sitzung. Zweitens
 werden aus zwei Pflicht-Label-Achsen vier: `area/`, `kind/`, `prio/` und `size/`. Drittens
 kommen zwei optionale Flags dazu, `status/blocked` und `status/unconfirmed`.
 Die Quelle ist zugleich der Beleg für die Umsetzung: das Issue verzeichnet, dass das
 Label-Set in Gitea steht und dass das Schema seit Stack-Version `4.0.1` kanonisch in
 `instructions/dev/issue-tracking.md` liegt.
 ## Kernaussagen
 - **Der Issue-Body ist die Lifeline für das Agent-Memory.** Die Umsetzung eines Issues zieht
  sich über mehrere, zeitlich getrennte LLM-Sitzungen, und der Body ist der einzige Ort, der
  sie verbindet: eine Sitzung muss allein aus ihm rekonstruieren können, was entschieden und
  was offen ist. Ein additiv wachsendes Log zwingt dagegen zum Lesen der ganzen Geschichte,
  um den aktuellen Stand herauszufiltern.
 - **Kommentare sind Changelog, nicht Kopie.** Ein Volltext-Snapshot des alten Bodys pro
  Revision zwingt einen Menschen zum Diffen zweier Fließtexte und ist damit keine lesbare
  Historie, sondern nur eine weitere Kopie. Der Kommentar nennt nur, was neu, entfallen oder
  korrigiert ist.
 - **Vier Pflichtachsen sind bezahlbar geworden, weil die Pflege maschinell läuft.** Der
  ursprüngliche Einwand gegen eine dritte Achse war der Pflegeaufwand für einen einzelnen
  menschlichen Betreuer; da Body-Rewrites und Labelpflege über eine LLM-Sitzung laufen, trägt
  er nicht mehr.
 - **`area/` folgt der Systemgrenze, nicht dem Codeort.** Die Werte `kb`, `distribution`,
  `corpus`, `workflow`, `process` folgen der Stufenteilung aus `AGENTS.md`. Ein `area/tools`
  gibt es bewusst nicht - Tooling wird nach der Domäne einsortiert, die es bedient.
 - **`kind/` darf sich im Lauf eines Issues ändern.** Der Wechsel von `decision` zu `build`,
  sobald entschieden ist, ist erwünschtes Session-Memory-Verhalten und kein Makel.
 - **`prio/` wurde nur umbenannt.** `1`/`2`/`3` heißen jetzt `blocking`/`planned`/`waiting`,
  die Bedeutung ist unverändert. Bei `size/` entfällt `XS`; `S`/`M`/`L` bleiben, wie sie
  waren.
 - **Ein unbelegter Verdacht bleibt nicht offen liegen.** Solange `status/unconfirmed` gesetzt
  ist, sind `size` und `prio` vorläufig. Die Triage endet mit entferntem Flag und
  verbindlichen Werten oder mit einem geschlossenen Issue samt Begründung - vom Issue selbst
  als Prozessentsprechung zu Invariante 3 des Stacks bezeichnet.
 - **Sechzehn Label stehen in Gitea**, gelesen am 2026-09-02: fünf `area/`, drei `kind/`, drei
  `prio/`, drei `size/`, zwei `status/`. `size/XS`, `prio/1`, `prio/2` und `prio/3`
  existieren nicht mehr.
 - **Der Release war ein PATCH.** `4.0.1`, weil `dist export` `instructions/dev/` vollständig
  ausschließt und sich für eine ausgelieferte Instanz nichts ändert - dieselbe Begründung wie
  bei `1.2.1`, das das Zweiachsen-Schema eingeführt hatte.
 ## Aufgaben
 - [ ] Bestehende Sachissues nach und nach auf die vier Pflicht-Label umstellen (laut Issue
      bereits umgestellt: #38, #27 geschlossen, #7, #42)
 ## Nicht übernommen
 - **Die Diskussion, aus der das Issue hervorging.** Das Issue nennt sie ("Diskussion vom
  2026-09-02"), aber ihr Transkript liegt nicht in `raw/`. Die Quelle ist damit das Ergebnis
  der Debatte, nicht ihr Verlauf; die verworfenen Alternativen sind nicht rekonstruierbar.
 - **Die Sachinhalte der referenzierten Issues #38, #30, #28, #27, #7, #42, #39, #40.** Sie
  kommen im Thread nur als Nummern vor. Was in ihnen steht, gehört in die Seiten zu den
  jeweiligen Gegenständen, nicht hierher.
 - **Der Volltext von `instructions/dev/issue-tracking.md`.** Das Issue beschreibt, was dort
  hineingeschrieben wurde; die Instruction selbst ist Teil des Stacks und kein Rohmaterial.
 ## Verwandte Entities
 - [[Chemenu]]
 - [[Gitea MCP Server]]
 ## Verwandte Concepts
 - [[Issue Label Scheme]]
@@ -0,0 +1,111 @@
 # Gitea Issue #41 — Issue-Management: Label-Schema und Body-als-Wahrheit-Konvention
 Wörtliche Kopie des Issue-Threads von <https://gitea.nehmer.net/torben/chemenu/issues/41>,
 gezogen am 2026-09-02 nach dem Body-Rewrite, der die Umsetzung in `4.0.1` festhält. Autor
 aller Beiträge: torben. Erstellt 2026-09-02T20:48:56Z, zuletzt geändert 2026-09-02T21:13:11Z.
 Labels zum Zeitpunkt der Kopie: `area/process`, `kind/build`, `prio/blocking`, `size/M`.
 Status: offen.
 ---
 ## Issue-Body (Stand 2026-09-02T21:13:11Z)
 ## Kontext
 Bündelt die Ergebnisse einer Diskussion am 2026-09-02 über den Entwicklungsprozess dieses Repos, ausgehend von den Fallouts in #38, #30, #28, #7, #27. Bewusst das erste Issue, das umgesetzt wird - es setzt den Rahmen für die Bearbeitung aller anderen.
 **Stand:** Label-Set steht in Gitea, das Schema ist seit `4.0.1` kanonisch in `instructions/dev/issue-tracking.md` (Commit `c8c2385`). Offen ist nur noch die Relabelung der verbliebenen Sachissues und eine `kb/`-Seite, die noch das alte Schema beschreibt.
 ## Entscheidung 1: Issues bleiben Storage für eingehende Specs, mit schärferer Pflege
 Ein eingehender Wunsch/Requirement bleibt Issue, nicht `kb/`-Seite - Issues sind ephemer und bilden Wünsche ab, `kb/` bildet verifiziertes, dauerhaftes Wissen ab (unverändert gegenüber `instructions/dev/issue-tracking.md`).
 **Motivation für die verschärfte Pflege:** Die Umsetzung der hier verhandelten Issues zieht sich über mehrere, oft zeitlich getrennte LLM-Sitzungen. Der Issue-Body ist der einzige Ort, der diese Sitzungen verbindet - er ist die Lifeline für das Agent-Memory. Eine Sitzung, die ein Issue neu öffnet, muss allein aus dem Body rekonstruieren können, was entschieden ist und was noch offen ist, ohne dass ein Mensch den Kontext erneut vorkaut. Ein additiv wachsendes Log zwingt zum Lesen der ganzen Geschichte, um den aktuellen Stand herauszufiltern - ein aktuell gehaltener Body liefert ihn direkt. Das ist der eigentliche Grund für die folgenden drei Regeln, nicht Ordnung um der Ordnung willen.
 - **Body = aktuelle Wahrheit.** Der Body wird aktiv umgeschrieben, wenn sich der Stand ändert - kein additives Anhängen an einen veralteten Ursprungstext.
 - **Kommentare = Changelog, nicht Kopie.** Beim Body-Rewrite wird kein Volltext-Snapshot des alten Stands als Kommentar gesichert, sondern ein kurzer Changelog-Eintrag, der nur benennt, was sich gegenüber dem vorherigen Stand geändert hat - neu, entfallen, korrigiert. Eine Vollkopie pro Revision zwingt einen Menschen zum Diffen zweier Fließtexte und ist damit keine lesbare Historie, sondern nur eine weitere Kopie.
 - **Bearbeitung primär durch LLM.** Menschen fassen in der Regel nur Labels/Metadaten direkt an; Body-Rewrites und Kommentare laufen über eine LLM-Sitzung.
 ## Entscheidung 2: Vier Pflicht-Label-Familien statt zwei
 | Familie | Werte | Bedeutung |
 |---|---|---|
 | `area/` | `kb`, `distribution`, `corpus`, `workflow`, `process` | Welche Systemgrenze betroffen ist, entlang der bestehenden Stufenteilung aus `AGENTS.md` (kein `area/tools` - Tooling wird nach der Domäne eingeordnet, die es bedient, nicht nach Codeort) |
 | `size/` | `S`, `M`, `L` (verdichtet von vier auf drei Stufen, `XS` entfällt) | Aufwand, unverändert in der Bedeutung von `S`/`M`/`L` |
 | `prio/` | `blocking`, `planned`, `waiting` (Umbenennung von `1`/`2`/`3`, Bedeutung unverändert) | Dringlichkeit, weiterhin fließend zu handhaben |
 | `kind/` | `decision`, `build`, `defect` | Art der Offenheit: wartet auf eine Betreiberentscheidung, ist spezifiziert und wartet auf Umsetzungszeit, oder ist ein Befund über einen Widerspruch. Darf sich im Lauf eines Issues ändern (z.B. `decision` → `build`, sobald entschieden) - das ist erwünschtes Session-Memory-Verhalten, kein Makel |
 Alle vier sind Pflicht auf jedem offenen Issue, weil maschinelle Pflege durch das LLM den ursprünglichen Einwand gegen eine dritte/vierte Achse (Pflegeaufwand für einen einzelnen Menschen) entkräftet.
 ## Entscheidung 3: Zwei optionale Status-Flags
 - `status/blocked` - wartet auf ein anderes, noch offenes Issue; unabhängig vom `prio`-Wert nicht eigenständig bearbeitbar. Nicht mandatory, weil es eine Beziehung zwischen Issues abbildet, keine Eigenschaft eines einzelnen.
 - `status/unconfirmed` - gemeldeter Verdacht, noch nicht gegen tatsächliches Verhalten geprüft. Gilt für jeden `kind`-Wert, nicht nur `defect`. Solange gesetzt, sind `size` und `prio` vorläufig. Nach Triage: Flag entfernt und `size`/`prio` verbindlich gesetzt, oder Issue mit Begründung geschlossen (kein unbelegter Verdacht bleibt offen liegen - Analogie zu Invariante 3 des Stacks, nur auf Prozessebene).
 ## Migration der bestehenden Labels
 `prio/1` → `prio/blocking`, `prio/2` → `prio/planned`, `prio/3` → `prio/waiting` (reine Umbenennung). `size/XS` entfällt, `size/S`/`M`/`L` bleiben unverändert. `area/*`, `kind/*`, `status/*` sind neu. **Erledigt** - alle 16 Label stehen in Gitea.
 ## Umgesetzt in `4.0.1`
 `instructions/dev/issue-tracking.md` ist auf das Schema umgeschrieben: Schritt 2 (Body als aktuelle Wahrheit inkl. Mehrsitzungs-Begründung), Schritt 3 (Changelog-Kommentar statt Vollkopie, mit Beispiel), Schritt 4 (alle vier Pflichtachsen als vier Tabellen), Schritt 5 (die beiden `status/`-Flags und der Triage-Ausgang), Schritt 6 (Re-Labeling schließt `kind/`-Wechsel ein). Der Entscheidungspunkt „Two labels feel too coarse?" ist entfallen, an seine Stelle treten zwei neue („Rewrite the body, or add a comment?" und der Umgang mit Altissues, die nur zwei Label tragen). Die Beschreibungszeile in `instructions/dev/stack-dev/SKILL.md` nennt jetzt die vier Achsen und die Body-Konvention.
 PATCH und nicht MINOR, weil `dist export` `instructions/dev/` vollständig ausschließt - für eine ausgelieferte Instanz ändert sich nichts. Gleiche Begründung wie bei `1.2.1`, das das ursprüngliche Zweiachsen-Schema eingeführt hat.
 ## Nicht in diesem Issue
 Die Relabelung der bestehenden Sachissues erfolgt in deren jeweiligen Einzel-Sitzungen. Bereits umgestellt: #38, #27 (geschlossen), #7, #42.
 `kb/concepts/Issue Label Scheme.md` beschreibt weiterhin das zweiachsige Schema von 2026-08-31 (`prio/1..3`, `size/XS..L`, „keine dritte Achse") und ist damit veraltet. Die Aktualisierung ist ein `kb/`-Schreibzugriff und braucht eine `wiki-manage`-Sitzung mit ordentlicher Quelle - nicht Teil dieses Issues.
 ## Akzeptanzkriterien
 - [x] Label-Set in Gitea angelegt/umbenannt (dieses Issue)
 - [x] `instructions/dev/issue-tracking.md` in einer stack-dev-Sitzung um dieses Schema ergänzt (`4.0.1`, Commit `c8c2385`)
 - [ ] Bestehende Sachissues nach und nach auf die vier Pflicht-Label umgestellt
 - [ ] `kb/concepts/Issue Label Scheme.md` in einer `wiki-manage`-Sitzung nachgezogen
 - [ ] Dieses Issue dient bis dahin als Referenz für das Schema
 ## Vorgeschichte
 Entschieden in der Diskussion vom 2026-09-02, im Rahmen einer Aufarbeitung von #38, #30, #28, #7, #27 als "Fallouts" des Entwicklungsprozesses. #39 und #40 liefen parallel und unabhängig, nicht Teil dieser Debatte.
 ---
 ## Kommentar 1 (2026-09-02T20:57:51Z, issuecomment-512)
 **Changelog:** Entscheidung 1, dritter Punkt korrigiert. Vorher: "Kommentare = Historie", der bisherige Body-Stand wird beim Umschreiben vollständig als Kommentar gesichert. Jetzt: "Kommentare = Changelog, nicht Kopie" - ein Kommentar nennt nur, was sich geändert hat, keine Volltextkopie des alten Bodys. Grund: eine Vollkopie pro Revision ist für einen Menschen nicht diffbar und damit keine brauchbare Historie.
 ## Kommentar 2 (2026-09-02T21:07:47Z, issuecomment-539)
 **Changelog:** Entscheidung 1 um Motivationsabsatz ergänzt (Body als Lifeline für Agent-Memory über mehrere Sitzungen hinweg, nicht Ordnung um der Ordnung willen). Akzeptanzkriterium 1 abgehakt, Referenzliste der bereits umgestellten Issues (#38, #27, #7, #42) ergänzt.
 ## Kommentar 3 (2026-09-02T21:13:19Z, issuecomment-545)
 **Changelog:** Akzeptanzkriterium 2 abgehakt - das Schema ist mit `4.0.1` (Commit `c8c2385`) kanonisch in `instructions/dev/issue-tracking.md`. Neu: Stand-Zeile im Kontext, Abschnitt „Umgesetzt in `4.0.1`" (was genau in der Instruction steht, und warum PATCH), Vermerk „Erledigt" an der Label-Migration. Neu als offener Punkt und als fünftes Akzeptanzkriterium: `kb/concepts/Issue Label Scheme.md` beschreibt noch das Zweiachsen-Schema und braucht eine eigene `wiki-manage`-Sitzung. Entfallen: der Absatz „Die eigentliche Textänderung ... braucht eine separate stack-dev-Sitzung" - genau die ist jetzt gelaufen.
 ---
 ## Label-Set in Gitea (gelesen 2026-09-02, `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/unconfirmed` | Gemeldeter Verdacht, noch nicht gegen tatsaechliches Verhalten geprueft - size/prio vorlaeufig |
 Sechzehn Label. `size/XS`, `prio/1`, `prio/2` und `prio/3` existieren nicht mehr.
@@ -50,7 +50,7 @@ tools/wikitool <command> --help
 | `index rebuild [--dry-run]` | Regenerate the catalog from every page's frontmatter: `kb/index.md` becomes a map (statistics, one row per collection and per area, links to the shards) and the page tables are written to a generated `INDEX.md` in each collection. An area past 50 rows gets its own shard. Stale shards from removed collections/areas are deleted in the same pass |
 | `log append --op ingest\|query\|lint\|create\|update\|delete\|rename --title "..." [--body "..."\|--body-file path]` | Append a formatted entry to `kb/log.md` |
 | `log status` | Read-only: count `ingest` entries logged since the last `lint` entry - the deterministic trigger behind the Maintenance Schedule's "every 10 sources" full-lint cadence |
-| `lint [--json] [--markdown out.md] [--full] [--fail-on-error]` | Structural + provenance checks: broken wikilinks, dangling frontmatter references, orphan pages, index drift, schema gaps, duplicate titles, title mismatches, uncovered raw files, broken `raw_files:` refs, raw files claimed by more than one source page, unmarked provenance, citation/frontmatter drift, quote-limit overages (>2 blockquoted lines/page, advisory only). Prints only the sections that found something and always writes the full report to `reports/Lint Report <date>.md` (or `--markdown`), naming the path - `--full` prints everything, `--json` prints the findings and writes nothing |
+| `lint [--json] [--markdown out.md] [--full] [--fail-on-error]` | Structural + provenance checks: broken wikilinks, dangling frontmatter references, orphan pages, index drift, schema gaps, duplicate titles, title mismatches, uncovered raw files, broken `raw_files:` refs, raw files claimed by more than one source page, unmarked provenance, citation/frontmatter drift, unbalanced generated-region markers, edges whose label is missing or not authorised by the source collection's `outbound:` (both hard once `kb_version` has reached the release that introduced labelled edges - advisory below it, so a corpus mid-migration is not refused by the check measuring it), quote-limit overages (>2 blockquoted lines/page, advisory only). Prints only the sections that found something and always writes the full report to `reports/Lint Report <date>.md` (or `--markdown`), naming the path - `--full` prints everything, `--json` prints the findings and writes nothing |
 | `search ["<text>"] [--field <predicate> ...] [--kind/--subtype/--collection/--tag <v>] [--regex] [--limit N] [--sort [-]<field>] [--backend <name>] [--matches] [--json]` | Find pages in `kb/` without reading the index. Text search runs through a pluggable backend (`rg` today); `--field` predicates are evaluated on frontmatter - `f=v`, `f~substring`, `'f>=v'`, `'f:*'` (present), `'!f'` (absent), repeatable and ANDed. With no text this is a pure structured query. Results carry kind/summary/confidence so a hit can be judged without opening the page. A page whose frontmatter does not parse can match no positive predicate, so it is **named** rather than dropped: `--json` always carries an `unreadable` list of `{path, reason}` (usually empty), and the table form writes the same lines to stderr. `--regex` is applied by `rg` alone, whose engine is linear; the ranking boosts for title and summary are literal-containment only, so a non-literal pattern is ranked by match count. `rg` is killed after 30 s and reported as a failure. Read-only, and **exempt from the Iteration Budget Gate** |
 | `confidence decay [--apply]` | Recompute every page's derived `confidence` as `confidence_base * (1 - 0.01/month)`, floored at 0.2; dry-run by default |
 | `confidence init-base [--apply]` | One-time backfill: set `confidence_base` from the current `confidence` on pages that predate the derived-confidence model |
@@ -16,10 +16,12 @@ from chemenu import config
 from chemenu.commands._util import rel_path, success
 from chemenu.lint_core import (
    HARD_ERROR_KEYS,
    MIGRATION_GATED_KEYS,
    MOST_LINKED_COUNT,
    QUOTE_LIMIT,
    count_quote_blocks,
    default_report_path,
    hard_error_keys,
    has_hard_errors,
    render_markdown,
    render_summary,
@@ -30,10 +32,12 @@ from chemenu.lint_core import (
 # so does every other name the tests and sibling commands already import.
 __all__ = [
    "HARD_ERROR_KEYS",
    "MIGRATION_GATED_KEYS",
    "MOST_LINKED_COUNT",
    "QUOTE_LIMIT",
    "count_quote_blocks",
    "default_report_path",
    "hard_error_keys",
    "has_hard_errors",
    "render_markdown",
    "render_summary",
@@ -183,6 +183,33 @@ def authorised_labels(source: str, destination: str, kb_dir: Path | None = None)
    return labels
 LABELLED_EDGE_FIELD = "related"
 def collections_that_can_carry_labelled_edges() -> set[str]:
    """Collection names whose offered page types actually have somewhere to put
    a labelled edge.
    Derived from `page_ref_fields:`, the same way `stack_required_collections()`
    is derived from `base_dir:`: a type that does not offer `related:` cannot
    carry a label, no matter what its collection's contract authorises.
    """
    from chemenu.type_resolver import resolver
    names: set[str] = set()
    for type_path, _frontmatter in resolver.list_type_specs():
        try:
            if resolver.get_root(type_path) != "kb":
                continue
            base_dir = resolver.get_base_dir(type_path)
            fields = resolver.get_page_ref_fields(type_path)
        except (ValueError, OSError):
            continue
        if base_dir and LABELLED_EDGE_FIELD in fields:
            names.add(str(base_dir).strip("/"))
    return names
 def declaration_issues(kb_dir: Path | None = None) -> list[str]:
    """What each `COLLECTION.md` fails to declare about itself.
@@ -200,6 +227,7 @@ def declaration_issues(kb_dir: Path | None = None) -> list[str]:
    issues: list[str] = []
    required = stack_required_collections()
    can_label = collections_that_can_carry_labelled_edges()
    present = {path.name for path in iter_kb_collections(root)}
    for name in required:
        if name not in present:
@@ -244,6 +272,20 @@ def declaration_issues(kb_dir: Path | None = None) -> list[str]:
                )
                + f" - it must be {str(expected).lower()}"
            )
        # An `outbound:` block on a collection whose types offer no `related:`
        # authorises labels that no page there can write. That is not a harmless
        # extra: it reads as a licence, so the label gets written into the prose
        # by hand instead - an identifier back in free text, which is the exact
        # thing the labelled-edge model exists to end. The two halves have to
        # move together, so the check names both directions of the fix.
        if declared.get(OUTBOUND_FIELD) and collection.name not in can_label:
            issues.append(
                f"{relative}: `{OUTBOUND_FIELD}:` authorises labels, but no page type writing "
                f"into kb/{collection.name}/ offers a `{LABELLED_EDGE_FIELD}:` field - so no "
                f"page here can carry a labelled edge. Either drop the block, or give the "
                f"type-spec a `{LABELLED_EDGE_FIELD}:` in its `page_ref_fields:` and schema"
            )
    return issues
@@ -27,6 +27,7 @@ from chemenu.provenance import legacy_source_pages as find_legacy_source_pages
 from chemenu.provenance import orphan_footnote_defs as find_orphan_footnote_defs
 from chemenu.provenance import uncovered_raw_files as find_uncovered_raw_files
 from chemenu.provenance import undefined_footnote_refs as find_undefined_footnote_refs
 from chemenu.version import Version
 from chemenu.kb_scan import (
    GENERATED_INDEX,
    WIKILINK_RE,
@@ -478,13 +479,6 @@ def default_report_path(report: dict) -> Path:
 # through the index or navigation only. `quote_limit_violations` is advisory
 # too - it flags a habit, not a broken tree.
 #
 # `unlabelled_edges` and `unauthorised_labels` are advisory **for now**, and
 # that is a dated decision rather than a judgment about severity: they describe
 # exactly the state a corpus is in between the 4.0.0 machinery landing and the
 # migration reaching each page, which is the window `.wikitool-kb.json` exists
 # to represent. They become hard errors once the migration is recorded - the
 # same path `legacy_citation_markers` took.
 #
 # `malformed_edges` and `unbalanced_markers` are hard from the start: neither
 # describes an unconverted page, only a broken one.
 #
@@ -505,11 +499,57 @@ HARD_ERROR_KEYS = (
    "dangling_frontmatter_refs",
    "malformed_edges",
    "unbalanced_markers",
    "unlabelled_edges",
    "unauthorised_labels",
    "invalid_type_paths",
    "type_resolution_errors",
    "schema_validation_errors",
 )
 # Findings that only become hard once the corpus has reached a given shape.
 #
 # `unlabelled_edges` and `unauthorised_labels` describe exactly the state a
 # corpus is in between the 4.0.0 machinery landing and the migration reaching
 # each page - the window `.wikitool-kb.json` exists to represent. Failing on
 # them during that window would refuse the very corpus that
 # `instructions/migrations/4.0.0-link-taxonomy.md` tells an instance to publish
 # unit by unit. So the promotion is tied to `kb_version` rather than to a
 # release date: below 4.0.0 they are advisory, at or above it an unlabelled
 # edge is no longer a page awaiting conversion but an edge whose author did not
 # say what it asserts.
 #
 # Gated rather than simply promoted, which is where this departs from
 # `legacy_citation_markers`: that one was flipped in a later version and any
 # instance still owing the citation migration had to live with a red lint. The
 # ledger can answer the question now, so it does.
 MIGRATION_GATED_KEYS: dict[str, Version] = {
    "unlabelled_edges": Version(4, 0, 0),
    "unauthorised_labels": Version(4, 0, 0),
 }
 _ALWAYS_HARD = Version(0, 0, 0)
 def hard_error_keys(kb_version: Version | None = None) -> tuple[str, ...]:
    """`HARD_ERROR_KEYS` minus the findings this corpus has not grown into yet.
    `kb_version` defaults to what `.wikitool-kb.json` records. A tree without
    one - a fresh instance, which starts at the current shape rather than
    migrating into it - keeps every key: there is no outstanding migration for
    a gated finding to be the noise of.
    """
    from chemenu import kb_state
    if kb_version is None:
        kb_version = kb_state.read_kb_version()
    if kb_version is None:
        return HARD_ERROR_KEYS
    return tuple(
        key
        for key in HARD_ERROR_KEYS
        if kb_version >= MIGRATION_GATED_KEYS.get(key, _ALWAYS_HARD)
    )
 def has_hard_errors(report: dict) -> bool:
-    return any(report.get(key) for key in HARD_ERROR_KEYS)
+    return any(report.get(key) for key in hard_error_keys())
@@ -192,3 +192,29 @@ def test_an_undeclared_destination_authorises_nothing(kb_root):
    missing declaration to be filled in with a permissive default."""
    _authorising(kb_root, "entities", "  concepts: [implements]")
    assert kb_collections.authorised_labels("entities", "sources") == set()
 def test_outbound_on_a_collection_that_cannot_carry_labels_is_a_finding(kb_root):
    """`kb/sources/` is the live case: the `source` type-spec offers no
    `related:`, so an `outbound:` block there authorises labels no page can
    write. Left unchecked it reads as a licence and the label gets written into
    the prose by hand instead - an identifier back in free text, which is what
    labelled edges exist to end."""
    _authorising(kb_root, "sources", "  any: [is-evidence-for]", required=True)
    issues = kb_collections.declaration_issues(kb_root)
    assert any(
        "kb/sources/COLLECTION.md" in issue and "no page type writing into kb/sources/" in issue
        for issue in issues
    )
 def test_outbound_is_fine_on_a_collection_whose_type_offers_related(kb_root):
    _collection(kb_root, "sources", profile="sources", required=True)
    _authorising(kb_root, "entities", "  any: [uses]")
    assert kb_collections.declaration_issues(kb_root) == []
 def test_a_collection_without_outbound_is_not_a_finding(kb_root):
    """Absence is the declaration `kb/sources/` makes: no authored edges here."""
    _collection(kb_root, "sources", profile="sources", required=True)
    assert kb_collections.declaration_issues(kb_root) == []
@@ -1,8 +1,12 @@
 import json
 from datetime import date
-from chemenu import config
+import pytest
 from chemenu import config, kb_state
 from chemenu.commands.lint import (
    HARD_ERROR_KEYS,
    hard_error_keys,
    has_hard_errors,
    lint_command,
    render_markdown,
@@ -11,6 +15,8 @@ from chemenu.commands.lint import (
 )
 from chemenu.frontmatter_io import write_page
 from chemenu.provenance import cite_id, render_cite_block
 from chemenu.tests.conftest import use_shipped_type_specs
 from chemenu.version import Version
 def test_lint_detects_unparsable_frontmatter(kb_dir):
@@ -472,3 +478,83 @@ def test_lint_does_not_count_a_shell_prompt_as_a_quote(kb_dir):
    )
    report = run_lint(kb_dir)
    assert [i for i in report["quote_limit_violations"] if i["page"] == "shelly"] == []
 # --- the migration gate on `unlabelled_edges` / `unauthorised_labels` -------
 #
 # These four repoint `config.ROOT` at the fixture tree, which the `kb_dir`
 # fixture alone does not do. Two things need it: `write_kb_state()` writes
 # `.wikitool-kb.json` relative to `ROOT`, and `lint`'s collection lookup
 # resolves a page against `config.KB_DIR` rather than against the directory it
 # was handed - so without the repoint the gate would be read off the real
 # repository's state file.
@pytest.fixture
 def rooted_kb(kb_dir, tmp_path, monkeypatch):
    monkeypatch.setattr(config, "ROOT", tmp_path)
    use_shipped_type_specs(monkeypatch)
    return kb_dir
 def _page_with_an_unlabelled_edge(rooted_kb):
    """A `related:` entry that is a bare title rather than a `label: title`
    mapping - the shape every page was in before the 4.0.0 migration."""
    write_page(
        rooted_kb / "entities/tools/bare-edge.md",
        {"type": "types/entity.md", "entity_type": "tool", "tags": [], "created": "2026-09-03",
         "modified": "2026-09-03", "related": ["Modbus"], "sources": [], "confidence": 0.8,
         "provenance": "general", "summary": "One edge whose label was never declared."},
        "\n# bare-edge\n\nAn edge without a label.\n",
    )
 def test_unlabelled_edge_is_advisory_below_kb_version_4(rooted_kb):
    """The window the migration document describes: the machinery has landed,
    the corpus has not been converted yet, and `lint --fail-on-error` must not
    refuse the very tree the migration tells the instance to publish unit by
    unit."""
    _page_with_an_unlabelled_edge(rooted_kb)
    kb_state.write_kb_state(Version(3, 0, 0), [])
    report = run_lint(rooted_kb)
    assert report["unlabelled_edges"] != []
    assert "unlabelled_edges" not in hard_error_keys()
    # Narrowed to the finding under test: the fixture corpus carries unrelated
    # hard errors of its own, so asserting on the whole report would prove
    # nothing about the gate.
    assert has_hard_errors({"unlabelled_edges": report["unlabelled_edges"]}) is False
 def test_unlabelled_edge_is_hard_at_kb_version_4(rooted_kb):
    """Once the migration is recorded, a bare title is no longer a page waiting
    its turn - it is an edge whose author did not say what it asserts."""
    _page_with_an_unlabelled_edge(rooted_kb)
    kb_state.write_kb_state(Version(4, 0, 0), [])
    report = run_lint(rooted_kb)
    assert report["unlabelled_edges"] != []
    assert "unlabelled_edges" in hard_error_keys()
    assert has_hard_errors({"unlabelled_edges": report["unlabelled_edges"]}) is True
 def test_unauthorised_label_is_hard_at_kb_version_4(rooted_kb):
    """The fixture contracts authorise `depends-on` but not `contradicts`."""
    write_page(
        rooted_kb / "entities/tools/off-menu.md",
        {"type": "types/entity.md", "entity_type": "tool", "tags": [], "created": "2026-09-03",
         "modified": "2026-09-03", "related": [{"contradicts": "Modbus"}], "sources": [],
         "confidence": 0.8, "provenance": "general", "summary": "A label off this menu."},
        "\n# off-menu\n\nA label the source collection never authorised.\n",
    )
    kb_state.write_kb_state(Version(4, 0, 0), [])
    report = run_lint(rooted_kb)
    assert report["unauthorised_labels"] != []
    assert "unauthorised_labels" in hard_error_keys()
    assert has_hard_errors({"unauthorised_labels": report["unauthorised_labels"]}) is True
 def test_a_tree_that_never_declared_a_kb_version_keeps_every_key(rooted_kb):
    """No `.wikitool-kb.json` means a fresh instance, which starts at the
    current shape rather than migrating into it - so there is no outstanding
    migration for a gated finding to be the noise of."""
    assert kb_state.read_kb_version() is None
    assert hard_error_keys() == HARD_ERROR_KEYS
@@ -45,7 +45,7 @@ def test_get_page_ref_fields_reads_the_type_spec():
    assert resolver.get_page_ref_fields("types/entity.md") == ["related", "sources"]
    assert resolver.get_page_ref_fields("types/concept.md") == ["related", "sources"]
    assert resolver.get_page_ref_fields("types/source.md") == ["entities", "concepts"]
-    assert resolver.get_page_ref_fields("types/comparison.md") == ["entities"]
+    assert resolver.get_page_ref_fields("types/comparison.md") == ["entities", "related"]
 def test_page_ref_fields_exist_in_the_type_schema():
@@ -4,7 +4,7 @@ name: comparison
 description: Strukturierter Typ für Vergleichsseiten, die mehrere Entities oder Ansätze gegenüberstellen
 schema: types/comparison.schema.yaml
 base_dir: comparisons
-page_ref_fields: [entities]
+page_ref_fields: [entities, related]
 ---
 # Comparison
@@ -32,6 +32,7 @@ page_ref_fields: [entities]
 | `tags` | Nein | Navigations-Tags zur Kategorisierung |
 | `created` | Ja | Erstellungsdatum (YYYY-MM-DD) |
 | `entities` | Ja | Titel der verglichenen Entities |
 | `related` | Nein | Deklarierte ausgehende Kanten - je Subjekt eine `compares-with`-Kante, geschrieben von `wikitool xref add` |
 | `summary` | Ja | Einzeiler für `kb/index.md` |
 ## Autorenanweisungen
@@ -21,6 +21,23 @@ properties:
      type: string
    description: Entity titles being compared
    minItems: 2
  related:
    type: array
    items:
      oneOf:
        - type: string
        - type: object
          minProperties: 1
          maxProperties: 1
          additionalProperties:
            type: string
    description: >-
      Declared outbound edges, in the same shape entity and concept pages use.
      A comparison's own assertion is `compares-with` against each subject: the
      titles are already in `entities:`, but that field is the untyped
      provenance-style list, so without this one the edge the page exists to
      make would live only in hand-written prose - which is the thing
      instructions/link-taxonomy.md was built to end.
  summary:
    type: string
    description: 1-line summary for index.md