fix: Testisolation - kb_dir repointet config.ROOT, lint loest Kollektionen gegen den uebergebenen Baum auf (4.1.1, #44 )

Files changed: - CHANGES.md - VERSION - instructions/dev/testing-conventions.md - tools/chemenu/lint_core.py - tools/chemenu/tests/conftest.py - tools/chemenu/tests/test_hermetic_env.py - tools/chemenu/tests/test_lint.py
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 )
2026-09-03 06:33:38 +02:00 · 2026-09-03 06:19:56 +02:00 · 2026-09-02 23:20:39 +02:00 · 2026-09-02 23:11:48 +02:00 · 2026-09-02 23:06:08 +02:00 · 2026-09-02 23:00:32 +02:00
223 changed files with 5546 additions and 1606 deletions
@@ -228,7 +228,7 @@ jobs:
          # contracts are adopted verbatim - the shipped text is a working
          # default, unlike a personalization file.
          grep -v 'wikitool:template-unfilled' kb/CONVENTIONS.md.template > kb/CONVENTIONS.md
-          for template in kb/*/COLLECTION.md.template; do
+          for template in kb/*/COLLECTION.md.template types/*.template; do
            cp "$template" "${template%.template}"
          done
          python3 -m venv tools/.venv
@@ -1,11 +1,16 @@
 {
  "schema": 1,
-  "kb_version": "3.0.0",
+  "kb_version": "4.0.0",
  "applied": [
    {
      "migration": "3.0.0-authoring-conventions",
      "at": "2026-09-02",
      "pages": 0
    },
    {
      "migration": "4.0.0-link-taxonomy",
      "at": "2026-09-02",
      "pages": 153
    }
  ]
 }
@@ -81,7 +81,7 @@ What a file is called says who it is for and how it is loaded. This is a rule, n
 | `kb/<collection>/COLLECTION.md` | Agents | When writing in that collection. Instance-owned in the same way, and declares in frontmatter which profile it adopted |
 | `instructions/<name>.md` | Agents | By link, or on explicit request |
 | `instructions/<name>/SKILL.md` | Agents | By the harness, once published |
-| `types/<name>.md` | Agents + validator | Via `tools/wikitool types describe` |
+| `types/<name>.md` | Agents + validator | Via `tools/wikitool types describe`. Split by `root:`: a page type-spec (`root: kb`) belongs to the instance and ships as `.template`; one describing a stack artifact ships verbatim |
 | `INDEX.md` | Both | Generated - never hand-edited |
 A stage may carry both a `README.md` and a `CONTRACT.md`: different readers, different
@@ -18,6 +18,228 @@ heading, and `wikitool docs verify` refuses a tree whose `VERSION` and newest
 versioned entry disagree. Entries below `0.1.0` predate versioning and keep
 their date-only headings.
 ---
 ## 4.1.1 - 2026-09-03 - Testisolation: kb_dir repointet config.ROOT, lint löst Kollektionen gegen den übergebenen Baum auf
 **Author:** Torben Nehmer
 Issue #44, gefunden beim Bau der Migrations-Gate-Tests für 4.1.0: die `kb_dir`-Fixture baute
 ihren Baum unter `tmp_path`, ließ `config.ROOT` aber auf dem echten Checkout stehen. Jeder
 Codepfad, der eine Datei über `config.ROOT`/`config.KB_DIR` auflöst statt über das übergebene
 Verzeichnis, traf damit das echte Repository.
 **Der laute Fall** war ein Test, der `kb_state.write_kb_state()` rief und dabei das
 `.wikitool-kb.json` des Repos überschrieb — Applied-Ledger leer statt zwei Einträgen. In
 `git status` sofort sichtbar und reversibel; bei einer gitignorierten Datei wäre es das nicht
 gewesen.
 **Der stillere Fall** ist der teurere. `lint`s Kollektions-Lookup löste eine Seite gegen
 `config.KB_DIR` auf. Für eine Seite unter `tmp_path/kb/` warf das `ValueError`, die Funktion
 antwortete „keine Kollektion", und die Label-Autorisierung übersprang die Kante wortlos.
 `unauthorised_labels` war damit faktisch ungetestet — jeder Test, der das Finding hätte
 auslösen können, bekam eine leere Liste und behauptete nichts. Ein grüner Lauf, der wie eine
 Zusicherung aussah.
 **Der Fix ist der Codepfad, nicht die Fixture.** `run_lint()` bekommt ein Verzeichnis
 übergeben und löst jetzt auch intern dagegen auf; `authorised_labels()` bekommt denselben Baum
 gereicht, statt auf `config.KB_DIR` zurückzufallen. Der Regressionstest lintet einen Baum, von
 dem `ROOT` bewusst wegzeigt — genau der Fall, den die alte Auflösung verschluckte. Eine Funktion,
 die ein Verzeichnis entgegennimmt, löst dagegen auf: keine Fixture kann diese Form von außen
 reparieren.
 **Beide Korpus-Fixturen repointen jetzt.** `kb_dir` tut, was `raw_dir` längst tat — `ROOT` auf
 das eigene `tmp_path`, plus `use_shipped_type_specs()`. Der Suite-Lauf kippte dadurch keinen
 einzigen Test. Die lokale `rooted_kb`-Umgehung aus 4.1.0 entfällt damit; die Auswahl zwischen
 zwei fast gleichen Fixturen war Wissen, das nirgends stand.
 **Und ein Wächter für die ganze Klasse.** `repository_tree_guard` (session-scoped, autouse)
 vergleicht `git status --porcelain` vor und nach dem Lauf und lässt die Suite scheitern, wenn
 sich im Checkout etwas bewegt hat — zwei `git status`-Aufrufe pro Lauf, deshalb per Default an.
 Er vergleicht vorher gegen nachher statt einen sauberen Baum zu verlangen, sagt also nichts über
 die unveröffentlichte Arbeit des Entwicklers. Den Verursacher benennt er nicht;
 `CHEMENU_TREE_GUARD=each` prüft nach jedem Test und tut es. Ohne git oder außerhalb eines
 Repositorys sind beide still.
 Was der Wächter nicht sieht: eine Prüfung, die unter Test nichts tut, schreibt keine Datei.
 Dagegen hilft nur ein Test, der das Finding tatsächlich auslöst — der neue tut das.
 `instructions/dev/testing-conventions.md` hat dafür einen eigenen Abschnitt („Which tree a test
 writes into"), einen Schritt in der Checkliste und die Regel für neue Fixturen.
 ---
 ## 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
 Das Issue-Schema aus 1.2.1 hatte zwei Pflichtachsen und einen ausdrücklich begründeten Verzicht
 auf eine dritte: eine Taxonomie mit mehr Achsen brauche eigene Pflege, und das Board habe einen
 einzigen Betreuer. Diese Begründung ist entfallen, weil die Pflege inzwischen maschinell
 passiert - Body-Rewrites und Kommentare laufen über eine LLM-Sitzung, Menschen fassen in der
 Regel nur Labels an. Damit sind vier Achsen bezahlbar (Issue #41).
 **Pflicht auf jedem offenen Issue sind jetzt vier Label:** `area/` (`kb`, `distribution`,
 `corpus`, `workflow`, `process` - kein `area/tools`, Tooling wird nach der bedienten Domäne
 einsortiert, nicht nach Codeort), `kind/` (`decision`, `build`, `defect`), `prio/`
 (`blocking`, `planned`, `waiting` - reine Umbenennung von `1`/`2`/`3`) und `size/` (`S`, `M`,
 `L`; `XS` entfällt). Dazu zwei optionale Flags: `status/blocked` für Abhängigkeit von einem
 anderen offenen Issue, `status/unconfirmed` für einen ungeprüften Verdacht, unter dem `size`
 und `prio` vorläufig sind. Ein `unconfirmed`-Issue endet in der Triage entweder ohne Flag und
 mit verbindlichen Werten oder geschlossen mit Begründung - die Prozessentsprechung zu
 Invariante 3.
 **Der Issue-Body ist ab jetzt aktuelle Wahrheit, nicht Ursprungstext.** Die Umsetzung eines
 Issues zieht sich über mehrere, zeitlich getrennte Sitzungen, und der Body ist das einzige, was
 sie verbindet: eine Sitzung muss aus ihm allein rekonstruieren können, was entschieden und was
 offen ist. Er wird deshalb umgeschrieben statt ergänzt. Jeder Rewrite bekommt einen Kommentar,
 der ausschließlich benennt, was sich geändert hat - keine Vollkopie des alten Stands, weil ein
 Mensch zwei Fließtexte nicht diffen kann und eine Kopie pro Revision damit keine Historie ist,
 sondern nur eine weitere Kopie.
 Geändert: [instructions/dev/issue-tracking.md](instructions/dev/issue-tracking.md) (Schritte 2,
 3, 5 neu; Schritt 4 um `area/` und `kind/` erweitert; der Entscheidungspunkt „Two labels feel
 too coarse?" entfällt) und die Beschreibungszeile in `instructions/dev/stack-dev/SKILL.md`. Für
 eine ausgelieferte Instanz ändert sich nichts: `dist export` schließt `instructions/dev/`
 vollständig aus, weshalb dies ein PATCH ist und kein MINOR - dieselbe Begründung wie bei
 `1.2.1`. Noch offen aus #41: `kb/concepts/Issue Label Scheme.md` beschreibt weiterhin das
 zweiachsige Schema und braucht eine eigene `wiki-manage`-Sitzung.
 ---
 ## 4.0.0 - 2026-09-02 - Prosa ist kein Identifier: Link-Taxonomie als Enum, generierte Regionen mit Markern
 **Author:** Torben Nehmer
 **Breaking Change:** Beziehungslabel sind Enum-Werte in related: statt Freitext im Body-Bullet, toolgefuehrte Abschnitte liegen zwischen Marker-Paaren statt hinter ihrer Ueberschrift, und xref add schreibt nur noch eine Kante statt beider Richtungen. tools/chemenu/sections.py ist geloescht. Eine bestehende Instanz muss sections: in kb/CONVENTIONS.md auf links/footnotes umstellen, outbound: in jede COLLECTION.md eintragen, die {section.*}-Variablen aus ihren Page-Type-Templates entfernen und den Korpus umstellen - sonst scaffoldet new die Variablen woertlich in neue Seiten. Ablauf: instructions/migrations/4.0.0-link-taxonomy.md
 Der Stack benutzte an drei Stellen **Prosa als Identifier**, und jede hat messbar etwas
 gekostet. Die Überschrift eines Abschnitts war seine Adresse (`^## Beziehungen$`), was die
 KB-Sprache zu einer Compiler-Konstante machte *und* das Ende der Region zur Schätzung - sie lief
 bis zur nächsten Überschrift, davor bis zum Dateiende, und hat auf acht Seiten still Inhalt
 gelöscht. Das Beziehungslabel stand nur im Body-Bullet, also konnte nichts das Vokabular prüfen:
 gemessen am Korpus **152 distinkte Label in 337 Bullets** gegen dreizehn dokumentierte, 102 davon
 genau einmal vorkommend. Und `xref add` spiegelte jede Kante, was `## Siehe auch` mit 555
 Bullets ohne Label füllte - 353 davon beweisbar redundant.
 **Was jetzt Identifier ist.** Eine Region liegt zwischen `<!-- wikitool:links -->` bzw.
 `<!-- wikitool:footnotes -->` und wird vollständig aus dem Frontmatter gerendert, Überschrift
 eingeschlossen. Ein Label ist ein Maschinenwert in `related:` (`- depends-on: Hermes`), gezogen
 aus `instructions/link-taxonomy.md` und **pro Ziel autorisiert von der Quell-Collection**
 (`outbound:` im `COLLECTION.md`, Commonplaces ADR-019). Der Body-Bullet ist eine Darstellung
 dieser Daten, nicht ihr zweiter Aufbewahrungsort.
 **Gelöscht, ersatzlos:** `tools/chemenu/sections.py` komplett, `heading_re`, der
 Alias-Mechanismus, `PRE_CONVENTIONS_NAMES`, `cite_block_heading`, `provenance.__getattr__`, die
 `{section.*}`-Template-Variablen, `xref`s Abschnittssuche. Kein Überschriftentext liegt mehr in
 Python - bis auf zwei kosmetische Fallbacks, und die sind harmlos geworden: der Marker trägt die
 Identität, also rendert ein falscher Default falsche Wörter statt Struktur zu zerlegen, und der
 nächste Write repariert es.
 **Kanten sind direktional, und das war keine Geschmacksfrage.** Die per-Collection-Autorisierung
 ist mit einer automatisch gespiegelten Gegenkante logisch unverträglich: die Spiegelhälfte
 entsteht in einer Collection, deren Regeln der Autor nie gelesen hat. Entweder schriebe das
 Werkzeug unautorisierte Kanten, oder die Regel "die Quellcollection entscheidet" löst sich auf.
 Der Navigationseinwand wird dabei *besser* beantwortet als vorher: `wikitool links show --page`
 berechnet die Eingangssicht über den Korpus, vollständig und ohne Pflege, und das gerenderte
 Bullet ist ein gewöhnlicher `[[wikilink]]` - ein Backlink-Panel zeigt es ohnehin. Die erzwungene
 Gegenkante garantierte nie Vollständigkeit, nur dass jemand daran gedacht hat.
 **Der Orphan-Check meldet dadurch mehr,** und das ist die Prüfung bei der Arbeit: sie misst jetzt
 Erreichbarkeit statt "ist `xref` gelaufen".
 **`obligation:` trennt zwei Achsen, die vorher eine waren.** `migration_kind:` sagt *wie*
 gearbeitet wird, neu `obligation: required|offered` *ob* überhaupt. Eine `offered`-Migration ist
 ein Angebot für eine Datei, die der Instanz gehört - sie blockiert nie, steht nicht in der Kette,
 und `migrate done` verbucht sie im Ledger, **ohne** `kb_version` zu bewegen. Genau daran hing ein
 Entwurfsfehler, den erst der Test gezeigt hat: Offers gegen `kb_version` zu filtern hätte jede
 Offer verschwinden lassen, sobald irgendein unbeteiligter Pflichtschritt lief. Dazu ist die
 Erkennungshälfte aktiviert, die seit ihrer Einführung ungelesen dalag - die sha256 pro Datei in
 `.wikitool-release.json` beantwortet jetzt "editiert oder nur empfangen", also ob eine Offer
 kopiert werden darf oder von Hand abgeglichen werden muss.
 **`types/` teilt sich entlang `root:`.** `root: kb` heißt Wissensseite heißt Instanz: die vier
 Page-Type-Specs samt Schemas gehen als `.template`, `instruction`/`lint-report`/`type-spec`
 verbatim. Damit ist die deutsche Prosa in jenen vier Dateien **korrekt statt Migrationsschuld** -
 es war die richtige Sprache an einem Ort mit falsch deklariertem Eigentümer. Was der Stack von
 der Type-Schicht noch verlangt, ist eine Zeile: ein Type-Spec `name: source`, dessen Schema
 `raw_files` fordert. `STACK_REQUIRED_COLLECTIONS` entfällt als separate Liste - die pflichtige
 Collection wird aus dem `base_dir` dieses Typs abgeleitet.
 **Warum das MAJOR ist.** Vorwärts: `sections:` hat eine andere Form, `outbound:` fehlt, und die
 in 3.0.0 übernommenen Page-Type-Templates enthalten `{section.*}`-Variablen, die es nicht mehr
 gibt - `new` schriebe sie wörtlich in neue Seiten. Rückwärts: 4.0.0 schreibt gelabelte Kanten,
 die 3.0.0s Schema als `type: string` ablehnt. Beide Hälften des Drop-in-Tests fallen.
 **Der Korpus dieser Instanz ist noch nicht umgestellt.** Diese Version liefert die Maschinerie;
 `lint` meldet die 480 noch ungelabelten Kanten als Findings, nicht als Fehler, weil das genau das
 Fenster ist, für das `.wikitool-kb.json` existiert. `malformed_edges` und `unbalanced_markers`
 sind dagegen sofort hart - keines beschreibt eine unkonvertierte Seite, nur eine kaputte. Die
 Beförderung der beiden anderen kommt, wenn der Korpus sie bestehen kann.
 ---
 ## 3.0.0 - 2026-09-02 - Autorenkonventionen nach Eigentum geschnitten: kb/CONVENTIONS.md, deklarierte Collections
@@ -1 +1 @@
-3.0.0
+4.1.1
@@ -65,11 +65,31 @@ catalogue of authoring profiles an instance may adopt into its own `kb/CONVENTIO
 ## `instructions/migrations/`
-A content migration is a Manual instruction with two extra frontmatter fields
+A content migration is a Manual instruction with three extra frontmatter fields
 (`types/instruction.schema.yaml`): `migrates_to:`, the stack version whose content shape it
-produces, and `migration_kind:` (`mechanical` | `assisted`). It lives at
+produces; `migration_kind:` (`mechanical` | `assisted`); and `obligation:`
 (`required` | `offered`, default `required`). It lives at
 `instructions/migrations/<version>-<slug>.md`.
 `migration_kind:` and `obligation:` are **two axes, not one**. The first says how the work is
 carried out, the second whether it has to happen at all:
 | `obligation:` | Means | `migrate status` |
 |---|---|---|
 | `required` | The content must reach the new shape or it no longer fits the machinery | Counted as outstanding; `migrate done` advances `kb_version` through it, in chain order |
 | `offered` | A file the instance owns still works as it is, and the stack proposes a better default | Listed separately, never blocks, no ordering rule. `migrate done` records it in the applied ledger and leaves `kb_version` where it is |
 Keeping them apart is what stops `migrate status` crying wolf: an instance nagged about an
 improvement it declined stops reading the nag that means its content no longer fits its
 machinery. And because taking an offer deliberately does not move the version, the **applied
 ledger** - not `kb_version` - is what makes an offer stop being offered; without that record
 there is no way to tell a taken offer from an ignored one.
 An `offered` migration is what makes an instance-owned file upgradeable at all. `dist export`
 records a sha256 per shipped file in `.wikitool-release.json`, so `migrate status` can say which
 of those files the instance edited and which it merely received - the first have to be
 reconciled by a person, the second can simply be copied over.
 The tier fits exactly: a migration must never be picked up implicitly - it rewrites the corpus -
 and it is referenced by nothing, because `tools/wikitool migrate status` finds it by reading the
 directory and comparing `migrates_to:` against this instance's `kb_version`. That is also why
@@ -1,7 +1,7 @@
 ---
 type: types/instruction.md
 name: issue-tracking
-description: Where open work on this stack is tracked, and what the prio/ and size/ labels on a Gitea issue mean.
+description: Where open work on this stack is tracked, what the four mandatory area/kind/prio/size labels and the two status flags on a Gitea issue mean, and how to keep an issue body current across sessions.
 ---
 # Track open work as Gitea issues, not as prose in the repo
@@ -26,6 +26,8 @@ issues at that URL, which is exactly why `dist export` excludes
  the repo.
 - A session's findings outgrow the change it was making - a gap in the tooling,
  an assumption nobody has checked, a decision that needs the user.
 - Picking an issue up: before doing anything else, read the body as the current
  spec, and re-label it if the ground has moved since.
 - Prioritising: deciding what to pick up next, or re-labelling after the ground
  moved.
@@ -36,35 +38,96 @@ issues at that URL, which is exactly why `dist export` excludes
   specific files or commands involved. An issue that only makes sense to
   whoever wrote it is a note, and notes were the problem.
-2. **Give it exactly two labels: one `prio/`, one `size/`.** Both, always -
+2. **Treat the body as the current truth, not as a historical first post.**
-   a priority without a cost is half a decision. Neither is a promise about
+   Work on one issue spans several sessions, often weeks apart, and the body is
-   *when*; together they answer "what should I pick up in the time I have".
+   the only thing that connects them: a session opening the issue must be able
   to reconstruct what is decided and what is still open from the body alone,
   without a human re-explaining it. So when the state changes, **rewrite the
   body** - do not append to a text that has become wrong. An additively grown
   log forces every later reader to reconstruct the current state by filtering
   the whole history.
-   | Priority | Means |
+   Body rewrites and comments are an LLM session's job. A human normally
   touches only labels and metadata directly.
 3. **Comment a changelog, never a copy.** Every body rewrite gets one short
   comment naming only what changed against the previous state - what is new,
   what is gone, what was corrected. Do not snapshot the old body into a
   comment: a full copy per revision forces a human to diff two prose texts,
   which is not a readable history, only another copy.
   ```
   **Changelog:** Decision 2 tightened - `kind/` may now change over an
   issue's life. Old acceptance criterion 3 dropped (covered by #42).
   ```
 4. **Give it all four mandatory labels: one `area/`, one `kind/`, one `prio/`,
   one `size/`.** All four, always. Machine maintenance by an LLM session is
   what makes four axes affordable - the original objection to a third and
   fourth axis was the upkeep cost for a single human maintainer, and that
   objection no longer holds.
   | `area/` | Means |
   |---|---|
-   | `prio/1` | Blocks or damages work in progress. Next. |
+   | `area/kb` | The `kb/` schema, contract, confidence machinery, lint - the knowledge base as a system. |
-   | `prio/2` | Accrues interest. Planned. |
+   | `area/distribution` | Shipping, upgrading and versioning an instance. |
-   | `prio/3` | Worth doing, waiting on a trigger. |
+   | `area/corpus` | The content and scope of `kb/` in this instance, and the demo/testbed question. |
   | `area/workflow` | Git, merging, branching, publish, PRs. |
   | `area/process` | The development process itself, rather than the stack as an artefact. |
-   `prio/3` is not a graveyard. It means the issue's value is real but gated on
+   There is deliberately no `area/tools`: tooling is filed under the domain it
-   something outside it - a decision, another issue, a second instance
+   serves, not under where its code sits. The axis follows the stage split in
   [AGENTS.md](../../AGENTS.md).
   | `kind/` | Means |
   |---|---|
   | `kind/decision` | Waiting on an operator decision. |
   | `kind/build` | Specified; waiting only on implementation time. |
   | `kind/defect` | A finding: documentation and reality, or two documents, contradict each other. |
   `kind/` is expected to change over an issue's life - `decision` becomes
   `build` once the decision is made. That is session memory working, not a
   labelling failure.
   | `prio/` | Means |
   |---|---|
   | `prio/blocking` | Blocks or damages work in progress. Next. |
   | `prio/planned` | Accrues interest. Planned. |
   | `prio/waiting` | Worth doing, waiting on a trigger. |
   `prio/waiting` is not a graveyard. It means the issue's value is real but
   gated on something outside it - a decision, another issue, a second instance
   existing. Name that trigger in the issue, or the label is a polite no.
-   | Size | Means |
+   | `size/` | Means |
   |---|---|
   | `size/XS` | Minutes. Often just a decision or an observation to record. |
   | `size/S` | One session, one publish, a clear cut. |
   | `size/M` | Several files; a contract or instruction change; its own test effort. |
   | `size/L` | Several sessions, or open design questions before the first commit. |
-   Size is effort, not importance. A `prio/1 size/XS` is the best thing on the
+   Size is effort, not importance. A `prio/blocking size/S` is the best thing
-   board; a `prio/3 size/L` is a thing to talk about before anyone starts.
+   on the board; a `prio/waiting size/L` is a thing to talk about before anyone
   starts.
-3. **Re-label when the ground moves, and say why in a comment.** A trigger that
+5. **Add a `status/` flag only when it applies.** Both are optional, because
-   fired turns `prio/3` into `prio/2`. A design question that got answered can
+   each describes a temporary condition rather than a property every issue has.
   drop a size. Silent re-labelling is how a board stops meaning anything.
-4. **Close with what actually happened**, not with a commit hash alone: which
+   | `status/` | Means |
   |---|---|
   | `status/blocked` | Waiting on another, still-open issue - not workable on its own, whatever its `prio/` says. Name the blocking issue in the body. |
   | `status/unconfirmed` | A reported suspicion, not yet checked against actual behaviour. Applies to any `kind/`, not just `kind/defect`. |
   While `status/unconfirmed` is set, `size/` and `prio/` are provisional. Triage
   ends it one of two ways: the flag comes off and `size`/`prio` are set for
   real, or the issue is closed with the reason. An unverified suspicion does not
   stay open indefinitely - the process-level analogue of AGENTS.md invariant 3.
 6. **Re-label when the ground moves, and say why in a comment.** A trigger that
   fired turns `prio/waiting` into `prio/planned`. A design question that got
   answered can drop a size and move `kind/decision` to `kind/build`. Silent
   re-labelling is how a board stops meaning anything.
 7. **Close with what actually happened**, not with a commit hash alone: which
   proposals were implemented, which were deliberately left out and why, and
   what was verified. The issue is the only place that record survives - a
   changelog entry says what changed, not what was decided against.
@@ -75,8 +138,13 @@ issues at that URL, which is exactly why `dist export` excludes
  what shipped. A finished change needs both: the entry, and the issue closed
  with the reasoning.
 - **Issue or `kb/` page?** An issue is about *this stack* and is ephemeral - it
-  closes. A `kb/` page is compiled knowledge that stays true. Never put wiki
+  closes, and it records a wish. A `kb/` page is verified knowledge that stays
-  content findings in an issue, and never file a work item as a page.
+  true. Never put wiki content findings in an issue, and never file a work item
- **Two labels feel too coarse?** They are meant to. A third axis - kind, area,
+  as a page.
-  status - is the point at which a taxonomy starts needing maintenance of its
+- **Rewrite the body, or add a comment?** Rewrite whenever a reader of the body
-  own, and this board has one maintainer.
+  alone would otherwise be misled - a changed decision, a dropped criterion, a
  new constraint. A comment carries the changelog line for that rewrite, and
  nothing else that a future session needs in order to act.
 - **An old issue carries only `prio/` and `size/`?** Complete it to all four
  when you touch it, rather than in a sweep. The board reaches the new scheme
  issue by issue, as each is picked up.
@@ -43,8 +43,9 @@ stack development happens in the origin repo instead (see AGENTS.md's routing li
   engineering, memory and deploy-time learning; consult before a design decision in those
   areas.
   [issue-tracking.md](../issue-tracking.md) - open work lives in Gitea issues, one per work
-   package, labelled `prio/1..3` and `size/XS..L`. There is no `TODO.md`. Read it before
+   package, labelled `area/`, `kind/`, `prio/` and `size/`, with the body kept as the current
-   filing something for later, or before deciding what to pick up next.
+   truth rather than as a first post. There is no `TODO.md`. Read it before filing something
   for later, before editing an issue, or before deciding what to pick up next.
   [testing-conventions.md](../testing-conventions.md) - the suite runs against a deliberately
   empty machine; what the autouse fixture already neutralizes, and what a test still has to
   establish itself. Read it before adding or changing a test.
@@ -40,6 +40,48 @@ resolved paths and `conventions`' parsed `kb/CONVENTIONS.md`. A test that *rewri
 conventions file mid-test calls `conventions.reset_cache()` itself - the fixture answers for the
 boundary between tests, not for one inside a test.
 ## Which tree a test writes into
 The environment is one half of the isolation; `config.ROOT` is the other. With `CHEMENU_ROOT`
 cleared, `ROOT` falls back to the checkout pytest is running from - deliberately, because most
 tests want the shipped `types/`. It also means that any code path resolving a file through
 `config.ROOT` or `config.KB_DIR` reaches **the real repository**, no matter which tree the
 fixture built.
 Both corpus fixtures therefore repoint it: `raw_dir` and `kb_dir` each set
 `config.ROOT` to their `tmp_path` and re-declare the shipped `types/` through
 `use_shipped_type_specs()`. `config`'s module `__getattr__` resolves the derived paths on
 access, so repointing `ROOT` carries `KB_DIR`, `RAW_DIR` and the rest with it. A new fixture
 that builds a tree does the same thing - that is the rule here, not a per-test judgment.
 `kb_dir` did not, until Gitea #44. Two things came of that. A test calling
 `kb_state.write_kb_state()` overwrote the real `.wikitool-kb.json`, which `git status` made
 visible within the minute. Quieter and worse: `lint`'s collection lookup resolved a page
 against `config.KB_DIR`, so every fixture page read back as "no collection" and the
 `unauthorised_labels` check skipped every edge in silence - the finding had no working test at
 all, and its green run read like an assurance.
 Two guards came out of it, both in `conftest.py`:
 | Guard | Default | Cost |
 |---|---|---|
 | `repository_tree_guard` (session) | on | two `git status --porcelain` calls per run |
 | `per_test_tree_guard` | off, `CHEMENU_TREE_GUARD=each` turns it on | one `git status` per test |
 The session guard compares the working tree before against after and fails the run if anything
 moved, so it says nothing about uncommitted work a developer already had. It cannot name the
 test that did it; `CHEMENU_TREE_GUARD=each` can, and is the way to bisect once it fires. Where
 git is unavailable or the checkout is not a repository, both are silently inert.
 Neither guard sees the second, quieter half: a check that silently *does nothing* under test
 writes no file. That one is only caught by a test that asserts the finding actually fires -
 which is why `test_unauthorised_label_is_judged_in_a_tree_that_is_not_the_configured_kb`
 lints a tree `ROOT` deliberately points away from.
 **A function that takes a directory resolves against that directory.** `run_lint(kb_dir)`
 reading `config.KB_DIR` for one of its own lookups was the defect behind the quiet half, and
 no fixture can fix that shape from the outside.
 ## When to run
 Whenever you add or change a test under `tools/chemenu/tests/`.
@@ -80,7 +122,12 @@ Whenever you add or change a test under `tools/chemenu/tests/`.
   `conftest.py` in the same change. A variable the tool reads and the fixture does not clear
   is the exact hole this whole file is about, reopened.
-5. **Verify against an empty machine before publishing**, not only in your own shell:
+5. **Writing a fixture that builds a tree?** Repoint `config.ROOT` at it and call
   `use_shipped_type_specs(monkeypatch)`, as `raw_dir` and `kb_dir` do - see
   [Which tree a test writes into](#which-tree-a-test-writes-into). A fixture that returns a
   path without repointing hands the code under test the real repository.
 6. **Verify against an empty machine before publishing**, not only in your own shell:
   ```bash
   cd tools && env -i PATH="$PATH" HOME="$(mktemp -d)" \
@@ -92,7 +139,7 @@ Whenever you add or change a test under `tools/chemenu/tests/`.
   `.venv/bin/python -m pytest -q`. A difference between the two is a leak, and the leaking
   variable belongs in step 4's list.
-6. **Check the coverage report when adding tests to close a gap**, rather than guessing which
+7. **Check the coverage report when adding tests to close a gap**, rather than guessing which
   lines were uncovered:
   ```bash
@@ -0,0 +1,215 @@
 ---
 type: types/instruction.md
 name: link-taxonomy
 description: The link-label catalogue - every relationship label a page may declare in related:, grouped by register, with the reader need each one names. A palette to authorise from in a COLLECTION.md, never binding on its own.
 manual: true
 ---
 # Pick a link label
 **This page is a palette, not an enum.** It lists every label this stack ships with and what
 each one asserts. What a page may actually *use* is decided by its own collection: each
 `kb/<name>/COLLECTION.md` authorises a subset per destination, and `wikitool lint` checks
 `related:` against that authorisation rather than against this file. A collection that
 authorises six labels has six, however long this list gets.
 A label is an **identifier, not prose**. It is written into `related:` as a machine value and
 rendered verbatim into the page body, so it is never translated - not in a German wiki, not in
 any other. Which words a page is *written* in stays [kb/CONVENTIONS.md](../kb/CONVENTIONS.md)'s;
 this is not one of them.
 ## The invariant every label obeys
 Every label completes, with the page carrying the link as the grammatical subject:
 > `[source] <label> [target]`
 The page containing the link asserts something **about** the target. `Hermes depends-on
 PostgreSQL` reads correctly on Hermes' page; the same fact written on PostgreSQL's page is a
 different label (`required-by`), not the same one pointing back. Omitted helper verbs ("is",
 "a") are fine where they do not reverse the endpoints.
 This is Commonplace's ADR-058, adopted wholesale, and it is what makes a label checkable rather
 than a matter of taste: read the sentence out loud, and if it says the opposite of what you
 meant, the label is wrong.
 ## Direction is authored, never mirrored
 Each direction is a separate decision. A link back from the target is welcome when it
 independently helps a reader *there* - and unnecessary when it does not. **Do not add a reverse
 edge merely to mirror the first one.** The inbound view is rendered from the graph by
 `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 three pairs do, because in each the reverse
 direction is a genuine primary statement someone would write on its own: `depends-on` /
 `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
 Adding or changing a `related:` entry, authorising labels in a `COLLECTION.md`, or judging
 whether a relationship is worth naming as a formal edge at all.
 ## Steps
 1. **Decide whether this is an edge.** Not every mention is one. An edge is a reader aid: it
   says *follow this if you need X*. A subject mentioned once in passing is prose with a
   `[[wikilink]]`, not a declared relationship. Over-declaring is how a graph becomes a list of
   everything adjacent to everything.
 2. **Say the sentence.** `[this page] <label> [that page]`. If it reads backwards, you want the
   other page to carry the edge, or a different label.
 3. **Pick from the register that fits the pair**, below. Prefer the most specific label that is
   true; fall back outward only when nothing fits.
 4. **Check the collection authorises it** for that destination -
   `kb/<name>/COLLECTION.md`'s `outbound:` block. If the label you want is not authorised and
   should be, that is a collection-contract change, made deliberately, not a lint error to
   route around.
 5. **Write it with the tool**, never by hand:
   ```bash
   tools/wikitool xref add --a "<This Page>" --b "<That Page>" --rel <label>
   ```
 ## The catalogue
 ### Operational
 Concrete things and how they stand to one another - the register this instance runs on. Mostly
 entity to entity.
 | label | inverse | asserts |
 |---|---|---|
 | `depends-on` | `required-by` | cannot function without the target |
 | `required-by` | `depends-on` | the target cannot function without this |
 | `runs-on` | `hosts` | executes on the target as its substrate |
 | `hosts` | `runs-on` | provides the substrate the target executes on |
 | `uses` | — | employs the target at runtime, but survives without it |
 | `produces` | — | emits the target as an artifact or data |
 | `consumes` | — | reads the target as an artifact or data |
 | `maintains` | — | carries the upkeep of the target |
 | `owns` | — | is accountable for the target's existence and decisions |
 `uses` versus `depends-on` is the distinction worth keeping sharp: if removing the target breaks
 this thing, it is `depends-on`. `owns` versus `maintains`: accountability versus labour, and
 they are often different people.
 ### Realization
 How an idea becomes a running thing. Usually concept to entity or the reverse.
 | label | asserts |
 |---|---|
 | `implements` | is a concrete realization of the target |
 | `operationalized-from` | is the prescriptive form of the target's theory |
 | `mechanism` | is the mechanism by which the target works |
 | `procedure` | is the procedure for carrying out the target |
 | `applies-when` | applies under the condition the target describes |
 | `operates-on` | acts upon the target as its subject matter |
 | `invokes` | calls the target as a step within itself |
 ### Conceptual
 Inference and comparison between ideas.
 | label | asserts |
 |---|---|
 | `extends` | develops the target's argument further |
 | `grounds` | provides the basis the target rests on |
 | `rests-on` | takes the target as its premise |
 | `enables` | is the operational prerequisite that makes the target possible |
 | `precondition` | must hold before the target applies |
 | `exemplifies` | is an instance of the general claim the target makes |
 | `abstracted-from` | generalizes from the target |
 | `contrasts` | differs from the target in a way worth reading both for |
 | `compares-with` | is weighed against the target on shared dimensions |
 | `contradicts` | asserts something the target denies |
 | `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.
 ### Lineage
 Where something came from, and what replaced it.
 | label | asserts |
 |---|---|
 | `supersedes` | replaces the target, which is now historical |
 | `derived-from` | was produced from the target |
 | `adapted-from` | was reworked from the target for a different purpose |
 | `defined-in` | takes its definition from the target |
 A superseded page is never deleted or rewritten - see the collection contract for
 `kb/concepts/`.
 ### Evidence
 The provenance register. Distinct from `sources:` and `[^cite-id]`, which are the *mechanical*
 provenance path: these two are authored claims about how strongly something is backed.
 | label | asserts |
 |---|---|
 | `evidenced-by` | is supported by the target as evidence |
 | `is-evidence-for` | serves as evidence for the target's claim |
 ### Universal
 | label | asserts |
 |---|---|
 | `see-also` | nothing more specific applies, and a reader here would still want the target |
 **`see-also` is the last resort and should stay rare.** A collection where it is the commonest
 label has a vocabulary problem, not a lot of loosely related pages. The previous vocabulary's
 `verwandt mit` was exactly that, and it is the reason this catalogue exists.
 ## Extending it
 Adding a label is a line of data, never a code change:
 1. Add a row here, in the register it belongs to, with the sentence it completes.
 2. Authorise it in the `COLLECTION.md` of every collection that may use it.
 The registers are advisory groupings for readers, not a schema - nothing checks that a label is
 used only within its register. Invent an intra-collection label the work needs and propose it
 here afterwards; the architecture is deliberately loose, because the link theory is still
 developing.
 ## Decision points
 - **Two labels both fit?** Take the more specific one. If they are equally specific and mean
  different things, the relationship is probably two edges.
 - **The relationship reads better from the other page?** Write it there. Nothing is lost - the
  inbound view renders it here.
 - **You want a reverse edge for navigation?** You do not need one. That is what the rendered
  inbound view is for, and it is complete in a way an authored mirror never was.
 - **Nothing fits at all?** Use `see-also` and say so in the commit, or propose a label. Do not
  stretch a label whose sentence reads false - a wrong edge is worse than a weak one, because
  it is machine-readable and will be believed.
 ## Scope
 Covers labels on `related:` edges between pages. Says nothing about `sources:` (the provenance
 field, unlabelled by construction), `[^cite-id]` footnotes
 ([kb/CONTRACT.md](../kb/CONTRACT.md#provenance-and-citation)), or `tags:` (search keys, not
 relationships).
@@ -0,0 +1,153 @@
 ---
 type: types/instruction.md
 name: 4.0.0-link-taxonomy
 description: Move every relationship from free-text prose in a body bullet to a labelled edge in related:, and every tool-owned body region from heading-matching to a marker pair.
 manual: true
 migrates_to: 4.0.0
 migration_kind: assisted
 obligation: required
 ---
 # Move relationships into the data, and generated regions behind markers (4.0.0)
 Until 4.0.0 the stack used **prose as an identifier** in three places, and each one cost
 something measurable:
 | Was the identifier | Cost |
 |---|---|
 | A section's heading text (`## Beziehungen`) | The KB language was a compiler constant, and the region's *end* was a guess. Content sitting after it was silently deleted on eight pages |
 | A relationship label in a body bullet (`- **hängt ab von:**`) | Nothing could check the vocabulary, so it drifted to **152 distinct labels** across 337 bullets against thirteen that were documented |
 | The reciprocal half of every edge | `xref add` mirrored every link, which made per-collection label authorisation impossible and filled `## Siehe auch` with 555 unlabelled bullets, 353 of them provably redundant |
 4.0.0 replaces all three. A region is delimited by a marker pair and rendered from frontmatter;
 a label is a machine value in `related:`, drawn from a catalogue and authorised per destination
 by the source collection; an edge is authored in one direction and the inbound view is computed.
 **This one touches pages.** Unlike 3.0.0 it is not a contract reshuffle: every `related:` entry
 and every tool-owned body region changes. It is `assisted` because there is no mapping table -
 mapping free-text German onto a 35-label catalogue is a judgment call per edge, and a large
 minority of the old labels are reverse directions that under the new model are not stored at all.
 ## When to run
 After installing 4.0.0 over an instance on 3.x. `tools/wikitool migrate status` names it, and
 `lint` reports `unlabelled_edges` for every unconverted edge - that count reaching zero is how
 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 stay
 advisory for as long as `kb_version` is below 4.0.0, which is exactly as long as this document
 is outstanding.
 ## Steps
 1. **Rewrite `kb/CONVENTIONS.md`'s `sections:` block.** Three slots become two, because the
   See Also region is gone:
   ```yaml
   sections:
     links: <your heading for declared relationships>
     footnotes: <your heading for citation definitions>
   ```
   Delete `section_aliases:` if you have one - nothing matches on heading text any more, so
   there is nothing to alias. The heading is now a *rendering* value: changing it re-renders
   the words above each region on the next write and can no longer split a page.
 2. **Add an `outbound:` block to every `kb/<name>/COLLECTION.md`.** Which labels a page may use,
   per destination collection, with `any` as a wildcard:
   ```yaml
   outbound:
     entities: [depends-on, runs-on, uses, see-also]
     concepts: [implements, see-also]
   ```
   The catalogue to draw from is [link-taxonomy.md](../link-taxonomy.md); the four contracts in
   the origin repo are worked examples. **The source collection decides** - that is what makes a
   35-label palette usable, and it is why the reverse edge can no longer be written
   automatically. A destination you do not list authorises nothing, which is a real answer.
 3. **Fix your page type-spec templates.** If you adopted the 3.0.0 templates, they contain
   `## {section.relationships}` and `## {section.see_also}`. Those variables no longer exist and
   would be written into new pages literally. **Delete both sections from the `## Template`
   block** - a template must not scaffold a tool-owned region at all: it is generated between
   markers on the first `xref add` / `cite add` and re-rendered on every write.
 4. **Convert the corpus**, following [migrate-corpus.md](../migrate-corpus.md). Cut it into
   units sized against the iteration budget; the origin repo used four, ~45 pages each. Per page:
   - For each labelled bullet under the old relationships heading: say the sentence
     `[this page] <label> [target]` and pick the catalogue label that makes it true. If it only
     reads true **backwards**, the edge belongs on the other page - move it there rather than
     inventing an inverse label the catalogue does not have.
   - For each bare `- [[X]]` bullet under the old See Also heading: drop it if a labelled edge
     already connects the pair. Otherwise decide - a real label, or dropped with the reason
     recorded. **Do not convert them to `see-also` in bulk.** That is the one shortcut this
     migration explicitly refuses: it would start the new taxonomy with most of its edges on its
     weakest label, which is the sediment the change exists to remove.
   - Write edges with `tools/wikitool xref add --a "<A>" --b "<B>" --rel <label>`, never by
     hand. The body region is rendered from `related:`; editing inside a marker pair is
     overwritten without warning.
   - `cite sync` converts a page's old footnote block into a marked region in passing.
 5. **Check each unit mechanically before anything else:**
   ```bash
   tools/wikitool migrate verify --from <pre-migration rev> --path kb/<area> --fail-on-error
   ```
   It compares wikilink and citation **counts**, footnote definitions, H1, structural
   frontmatter, and - new in 4.0.0 - the **count of marker pairs per region**. A dropped marker
   is otherwise silent: the region becomes ordinary prose and the next write appends a second
   one beside it.
 6. **Record it. The checks tighten themselves:**
   ```bash
   tools/wikitool lint          # unlabelled_edges and unauthorised_labels must be 0
   tools/wikitool migrate done 4.0.0 --pages <N>
   ```
   Only once `lint` reports zero of both is the run finished. The two findings are advisory
   while `kb_version` is below 4.0.0 and hard from the moment `migrate done` records it -
   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
 Its `related:` entries are `- <label>: <title>` rather than bare titles, and its relationship
 and footnote sections sit between `<!-- wikitool:links -->` / `<!-- wikitool:footnotes -->`
 marker pairs. `tools/wikitool links show --page "<Title>"` prints `unlabelled` for every edge
 still waiting, and `lint`'s `unlabelled_edges` count is the corpus-wide version of the same
 question.
 ## Decision points
 - **A label you want is not in the catalogue?** Add it - a row in `link-taxonomy.md` and an
  entry in the authorising `COLLECTION.md`. No code change is involved, and the registers are
  advisory groupings rather than a schema. Do not stretch a label whose sentence reads false: a
  wrong edge is worse than a weak one, because it is machine-readable and will be believed.
 - **`related:` holds an entry with no body bullet to derive a label from?** Expected - the
  origin repo found 480 edges against 337 bullets, because frontmatter and body had already
  drifted apart while the label lived only in prose. Read the page and decide; that drift is
  itself part of what this migration repairs.
 - **A page loses its last inbound edge?** The orphan check will now report it, and that is the
  check working: directional edges mean a page nothing points at is genuinely unreachable, where
  the old mirrored model always manufactured a back-link. Either something should point at it,
  or it is reached through the catalog and that is fine.
 - **Tempted to keep writing reverse edges for navigation?** Do not. `links show` computes the
  inbound view, and the rendered bullet on the asserting page is an ordinary `[[wikilink]]`, so
  a backlink panel in an editor already shows it.
 ## Scope
 The corpus under `kb/`, plus the three instance-owned declarations in steps 1-3. It does not
 touch `raw/`, and it learns nothing new: the same knowledge is restated in a form that can be
 checked. Installing the 4.0.0 machinery itself is `INSTALL.md`'s and must have happened first.
@@ -68,17 +68,23 @@ bereit für den ersten `Ingest`.
   Ablauf:
-   1. Die Collection-Contracts übernehmen - vier Kopien, keine Frage an den Nutzer, denn was
+   1. Die Collection-Contracts **und die Page-Type-Specs** übernehmen - Kopien, keine Frage an
-      dort steht ist unabhängig von der Sprache brauchbar:
+      den Nutzer, denn was dort steht ist als Ausgangspunkt unabhängig von der Sprache brauchbar:
      ```bash
-      for template in kb/*/COLLECTION.md.template; do
+      for template in kb/*/COLLECTION.md.template types/*.template; do
        cp "$template" "${template%.template}"
      done
      ```
      Die `.template`-Dateien bleiben liegen; sie sind die Vorlage für den nächsten Export.
      Unter `types/` betrifft das genau die Type-Specs mit `root: kb` - `entity`, `concept`,
      `source`, `comparison` - samt ihrer `.schema.yaml`. Sie beschreiben Seiten, die *diese*
      Instanz schreibt, also gehören sie ihr: Prosa, Template und Sprache dürfen umgeschrieben
      werden. `instruction`, `lint-report` und `type-spec` beschreiben Stack-Artefakte und
      kommen unverändert.
   2. Den Nutzer nach der KB-Sprache fragen. `kb/CONVENTIONS.md.template` ist auf **Englisch**
      voreingestellt; [kb-profiles.md](kb-profiles.md) hält daneben ein vollständiges
      deutsches Profil bereit, und dessen Volltext ist die `kb/CONVENTIONS.md` des Quell-Repos.
@@ -99,9 +105,16 @@ bereit für den ersten `Ingest`.
   Migration jeder vorhandenen Seite (`section_aliases:` trägt die alten Namen, siehe
   [migrate-corpus.md](migrate-corpus.md)).
-   **Nichts davon liegt unter `tools/` oder `types/`.** Der Compiler liest die Abschnittsnamen
+   **Nichts davon liegt in einer Stack-Datei.** Der Compiler liest die Abschnittsnamen aus
-   aus `kb/CONVENTIONS.md`, und die vier Page-Type-Templates setzen sie über
+   `kb/CONVENTIONS.md`; die vier Page-Type-Specs gehören ab Schritt 1 dieser Instanz. Eine
-   `{section.…}`-Variablen ein - eine anderssprachige Instanz ändert dort keine Datei.
+   anderssprachige Instanz übersetzt sie einfach - das ist kein lokaler Patch an etwas
   Ausgeliefertem mehr, sondern Arbeit an den eigenen Dateien, und ein Upgrade nimmt sie ihr
   nicht wieder weg.
   Was der Stack von `types/` überhaupt noch verlangt, ist eine Zeile: es muss einen Type-Spec
   mit `name: source` geben, dessen Schema `raw_files` fordert. Daran hängt der gesamte
   `raw/`→`kb/`-Provenance-Pfad (`sources coverage`, `[^cite-id]`-Auflösung, `kb/provenance.md`),
   und `docs verify` prüft genau das - nicht mehr.
   Unverändert bleibt in jedem Fall die Regel, die dem Stack gehört: **jede Zeile einer Seite
   ist Prosa oder Identifier, und nur Prosa wird übersetzt** ([kb/CONTRACT.md § Language and
@@ -12,9 +12,8 @@ second half is the cut: what is written here is enforced by `tools/wikitool` or
 how it works, so it is identical everywhere and `dist export` ships it verbatim.
 **What an instance decides for itself is next door, in
-[kb/CONVENTIONS.md](CONVENTIONS.md)** - the language pages are written in and its three
+[kb/CONVENTIONS.md](CONVENTIONS.md)** - the language pages are written in, the headings its two
-tool-owned section headings, the naming forms, the tone, the relationship-label vocabulary, the
+generated regions render under, the naming forms, the tone, the confidence rubric. That file binds exactly as this one does; it is simply owned by the instance
 confidence rubric. That file binds exactly as this one does; it is simply owned by the instance
 rather than by the stack, so the distribution ships only its `.template` and the instance writes
 the real one. Read both, plus the target collection's `kb/<name>/COLLECTION.md` (also
 instance-owned), before writing or editing a page.
@@ -99,7 +98,8 @@ decision record - is the instance's, in
 - [ ] Carry a clear, descriptive title and a summary near the top
 - [ ] Use consistent terminology with the rest of the wiki
- [ ] Link to every entity and concept it mentions, and be linked to in return
+- [ ] Link to the entities and concepts it mentions, and declare an edge where the relationship
      is worth naming - in the direction this page asserts it, not in both
 - [ ] Cite its hard facts (see [Provenance and citation](#provenance-and-citation))
 - [ ] Duplicate no existing page
 - [ ] Appear in the catalog (guaranteed by `wikitool index rebuild`)
@@ -141,36 +141,62 @@ instance records - see [kb/CONVENTIONS.md § Language](CONVENTIONS.md#language).
 evidence *about* a source, not a substitute for it. Quote verbatim in the original language and
 record the raw file's language in `source_language:`.
-### Section headings
+### Generated regions
-Three headings are a vocabulary the tool owns rather than prose an author picks: `xref add`
+Two regions of a page body are **generated**, not authored: the links region `xref` owns and the
-writes into Relationships and See Also, and `cite add` owns the trailing Footnotes block. They
+footnotes region `cite` owns. Each sits between a marker pair:
 follow the KB language like everything else, so **the instance names them**, in
 `kb/CONVENTIONS.md`'s `sections:` frontmatter. `tools/chemenu/conventions.py` reads that
 declaration and `tools/chemenu/sections.py` is what the rest of the compiler asks - there is no
 heading text in the compiler itself.
-Each has aliases the tool still *recognizes* but no longer writes, which is what lets the corpus
+```markdown
-be translated page by page: a page still carrying `## Relationships` is found and appended to
+<!-- wikitool:links -->
-correctly, and `cite sync` leaves an untranslated `## Footnotes` heading alone rather than
+## Beziehungen
-retitling it. The recognized set is the canonical name, any `section_aliases:` the instance
+
-declared, and the names this stack wrote before the declaration existed. Renaming a heading is
+- **depends-on:** [[Hermes]]
-the translation pass's job, never a side effect of another command. Any *other* heading an
+<!-- /wikitool:links -->
-author adds is ordinary prose and is translated with the rest.
+```
 The marker is what the tool locates the region by, and everything between the markers -
 **heading included** - is replaced wholesale on the next write. An author never edits inside
 them; anything left there is overwritten without warning, exactly as in `kb/index.md`. A region
 with nothing to show is absent rather than empty.
 The heading is therefore a *rendering* value, taken from `kb/CONVENTIONS.md`'s `sections:`. No
 heading text exists in the compiler, and nothing matches on it: changing the declaration
 re-renders the words on the next write and cannot split a page.
 That is not how it used to work. The tool located these regions by matching their heading text,
 which made a translated heading a structural fact - and made the region's *end* a guess. It ran
 to the next heading, and before that to the end of the file, which silently deleted whatever sat
 after it on eight pages. Any *other* heading a page carries is ordinary prose.
 ## Linking
-Every page links to what it mentions, in both directions. Cross-references are created with
+**An edge is authored in one direction**, on the page that asserts it, and carries a label that
-`tools/wikitool xref add --a "<A>" --b "<B>" --rel-a "<label>" --rel-b "<label>"`, never by
+is a machine value rather than prose:
 hand-editing the `related:` array or the Relationships/See Also bullets.
-Use a typed relationship label rather than a generic one. The label is free text as far as the
+```yaml
-tool is concerned - it is written into a `- **label:** [[Title]]` bullet and no code matches on
+related:
-it - so which vocabulary this instance uses is
+  - depends-on: Hermes
-[kb/CONVENTIONS.md § Relationship labels](CONVENTIONS.md#relationship-labels)'s to list.
+```
-A page is expected to have at least one inbound link; `wikitool lint` reports orphans.
+Created with `tools/wikitool xref add --a "<A>" --b "<B>" --rel <label>`, never by hand-editing
-Comparison pages are exempt - they are reached through the catalog.
+`related:` or the rendered bullet. Say the sentence before choosing the label - `[A] <label>
 [B]` - and if it only reads true backwards, the edge belongs on the other page.
 **A reverse edge is a separate decision, not a mirror.** Write one when it independently helps a
 reader at the other end; do not write one to make the graph symmetric. Navigation does not
 depend on it either way: `index rebuild` renders the inbound view from the graph, completely and
 without maintenance.
 Which labels exist is [instructions/link-taxonomy.md](../instructions/link-taxonomy.md), a
 palette that binds nothing. Which of them a page may *use* is its own collection's `outbound:`
 block, per destination - the **source** collection decides, because the rules that govern an
 edge are the rules of the collection asserting it. `xref add` refuses an unauthorised label and
 `lint` reports one.
 A page is expected to have at least one inbound edge; `wikitool lint` reports orphans.
 Comparison pages are exempt - they are reached through the catalog. Directional edges mean more
 pages qualify than under the old mirrored model, and that is the check measuring reachability
 rather than measuring whether `xref` ran.
 Renaming a page, deleting one, or dropping a single reference are tool operations with their
 own procedure: see [instructions/page-lifecycle.md](../instructions/page-lifecycle.md).
@@ -2,8 +2,7 @@
 language: de
 profile: german
 sections:
-  relationships: Beziehungen
+  links: Beziehungen
  see_also: Siehe auch
  footnotes: Fußnoten
 ---
@@ -21,13 +20,11 @@ Adopted from the `german` profile in
 [instructions/kb-profiles.md](../instructions/kb-profiles.md). That catalogue is a palette, not
 an enum - what is written here is what holds, whether or not a profile says the same thing.
-The frontmatter above is the one machine-read part. `sections:` names the three headings
+The frontmatter above is the one machine-read part. `sections:` names the headings the two
-`wikitool xref` and `wikitool cite` write into; `tools/chemenu/conventions.py` reads them and
+**generated regions** render under - the links region `wikitool xref` owns and the footnotes
-`tools/chemenu/sections.py` is what the rest of the compiler asks. Renaming one here changes
+region `wikitool cite` owns. Each sits between a marker pair, and the marker is what the tool
-what the tool *writes*; what it still *recognizes* is the union of that name, any
+locates it by, so the heading here is a display value: changing it re-renders the words above
-`section_aliases:` declared beside it, and the names this stack wrote before this file existed.
+those regions and nothing else. Nothing matches on this text.
 That asymmetry is the translation path: a page keeps working under its old heading until it is
 itself translated.
 ## Language
@@ -52,12 +49,13 @@ material, not a second rule - every entry in it is a decision that was made wron
 ### Section headings
-The canonical names are the frontmatter's: `## Beziehungen`, `## Siehe auch`, `## Fußnoten`.
+The two generated regions render under `## Beziehungen` and `## Fußnoten`. An author never
-The English forms this stack wrote before the corpus was translated are still recognized, so a
+writes inside them - they are rebuilt from frontmatter on every write, exactly like
-page carrying `## Relationships` is found and appended to correctly and `cite sync` leaves an
+`kb/index.md` - and never has to write the heading either. Any *other* heading on a page is
-untranslated `## Footnotes` alone. Renaming such a heading is the translation pass's job, never
+ordinary prose and is translated with the rest.
-a side effect of another command. Any *other* heading an author adds is ordinary prose and is
+
-translated with the rest.
+There is no `## Siehe auch` region any more. It was the reciprocal half of a bidirectional
 `xref add`; under authored directional edges, `see-also` is a *label* inside the links region.
 ## Naming
@@ -92,15 +90,11 @@ The blockquote cap is not here: `wikitool lint` reports it, so it is the contrac
 ## Relationship labels
-`tools/wikitool xref add --rel-a/--rel-b` takes a free-text label. This instance uses a typed
+**Not this file's to list, and not localized.** A label is a machine value in `related:`, drawn
-one rather than a generic one:
+from [instructions/link-taxonomy.md](../instructions/link-taxonomy.md) and authorised per
-
+destination in each `kb/<name>/COLLECTION.md`'s `outbound:` block. `- **depends-on:** [[Hermes]]`
-`hängt ab von` · `verwendet` · `implementiert` · `erweitert` · `ersetzt` · `steht in Konflikt mit`
+is what a German page carries, and that is deliberate: the label is an identifier, so translating
-· `benötigt` · `erzeugt` · `konsumiert` · `besitzt` · `pflegt` · `läuft auf` · `verwandt mit`
+it would make the graph's semantics depend on the prose again.
 (last resort)
 The labels are prose written into a `- **label:** [[Title]]` bullet; no code matches on them, so
 an untranslated page's English label is stale wording, not a broken reference.
 ## Confidence rubric
@@ -119,8 +113,7 @@ write "unsicher"/"unbestätigt".
 ## Keeping this file honest
-Change it when a convention actually changes, and treat a change to `sections:` as a corpus
+Change it when a convention actually changes. `sections:` is safe to change at any time - the
-migration rather than an edit: existing pages keep their old headings until something translates
+regions are located by their markers and re-rendered under the new words on the next write.
-them, and the alias list is what carries them in the meantime. `wikitool doctor` FAILs on a
+`wikitool doctor` FAILs on a missing or unfilled file, and `wikitool docs verify` refuses a
-missing or unfilled file, and `wikitool docs verify` refuses a `sections:` block that does not
+`sections:` block that does not name both regions.
 name all three slots.
@@ -3,16 +3,8 @@
 language: en
 profile: none
 sections:
-  relationships: Relationships
+  links: Relationships
  see_also: See Also
  footnotes: Footnotes
 # Headings this instance no longer writes but still recognizes, so a corpus can
 # be translated page by page instead of all at once. Optional; the names this
 # stack wrote before this file existed are always recognized anyway.
 # section_aliases:
 #   relationships: [Beziehungen]
 #   see_also: [Siehe auch]
 #   footnotes: [Fußnoten]
 ---
 # kb/ - Authoring Conventions of This Instance
@@ -29,9 +21,9 @@ Ready-made answers to every section below - including a complete German profile
 [instructions/kb-profiles.md](../instructions/kb-profiles.md). That catalogue is a palette, not
 an enum: adopt an entry, adapt it, or write your own. What is written *here* is what holds.
-The frontmatter above is the one machine-read part. `sections:` names the three headings
+The frontmatter above is the one machine-read part. `sections:` names the headings the two
-`wikitool xref` and `wikitool cite` write into. Set them before the first page is written:
+generated regions render under. Safe to change at any time - each region is located by its
-afterwards, changing one is a corpus migration rather than an edit.
+marker pair, so a rename re-renders words and nothing else.
 ## Language
@@ -52,10 +44,8 @@ is the one those terms are already in.}
 ### Section headings
-The canonical names are the frontmatter's. Any name this instance previously wrote stays
+The two generated regions render under the frontmatter's headings. An author never writes inside
-recognized through `section_aliases:`, which is what lets a corpus be translated page by page.
+them - they are rebuilt from frontmatter on every write. Any *other* heading is ordinary prose.
 Renaming such a heading is the translation pass's job, never a side effect of another command.
 Any *other* heading an author adds is ordinary prose.
 ## Naming
@@ -80,13 +70,9 @@ Bad: {the same sentence written the way it must not be.}
 ## Relationship labels
-`tools/wikitool xref add --rel-a/--rel-b` takes a free-text label. Listing the ones this
+**Not this file's to list, and not localized.** A label is a machine value in `related:`, drawn
-instance uses is what keeps a graph typed rather than a wiki full of "related to":
+from [instructions/link-taxonomy.md](../instructions/link-taxonomy.md) and authorised per
-
+destination in each `kb/<name>/COLLECTION.md`'s `outbound:` block.
 {the label vocabulary, in the KB language}
 No code matches on these, so an old label on an untranslated page is stale wording, not a
 broken reference.
 ## Confidence rubric
@@ -99,6 +85,5 @@ contract's. What the number *means* is this instance's:
 ## Keeping this file honest
-Change it when a convention actually changes, and treat a change to `sections:` as a corpus
+Change it when a convention actually changes. `wikitool doctor` FAILs on a missing or unfilled
-migration rather than an edit. `wikitool doctor` FAILs on a missing or unfilled file, and
+file, and `wikitool docs verify` refuses a `sections:` block that does not name both regions.
 `wikitool docs verify` refuses a `sections:` block that does not name all three slots.
@@ -1,5 +1,7 @@
 ---
 profile: comparisons
 outbound:
  any: [compares-with, contrasts, see-also]
 required_by_stack: false
 ---
@@ -37,11 +39,22 @@ alphabetically.
 - State the trade-off, not a winner. Where a recommendation is genuinely warranted, scope it:
  "for X workload", not "better".
 ## Authorised labels
 The `outbound:` block above is what `wikitool lint` and `xref add` check: which labels a page in
 this collection may use, per destination. The catalogue they are drawn from - and what each one
 asserts - is [instructions/link-taxonomy.md](../../instructions/link-taxonomy.md), which binds
 nothing on its own.
 Narrow for the opposite reason: a comparison's substance is its table, and its links to the compared subjects are the one relationship it asserts.
 Adding a label here is a deliberate contract change, not a way around a refusal.
 ## Outbound linking
-A comparison links to every subject with `related to`, and each subject links back. Comparison
+A comparison links to every subject with `compares-with`. The subjects do not have to link back:
-pages are **exempt from the orphan check** - they are reached through `index.md` rather than
+a comparison is reached through the catalog, and each subject's inbound view renders the edge
-through inbound prose links.
+anyway. Comparison pages are **exempt from the orphan check** for the same reason.
 ## What does not belong here
@@ -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,13 +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:** [[amd-pstate]]
+- **compares-with:** [[amd-pstate]]
- **compares:** [[acpi-cpufreq]]
+- **compares-with:** [[acpi-cpufreq]]
-
+<!-- /wikitool:links -->
 ## Siehe auch
 - [[amd-pstate]]
 - [[acpi-cpufreq]]
@@ -4,7 +4,11 @@ concept_type: problem
 tags: [tests, ci, tooling, quality]
 created: 2026-08-31
 modified: 2026-08-31
-related: [Structural Enforcement over Documented Rule, Green Suite Blind Spot, wikitool, Gitea Actions]
+related:
  - exemplifies: Structural Enforcement over Documented Rule
  - contrasts: Green Suite Blind Spot
  - exemplifies: wikitool
  - exemplifies: Gitea Actions
 sources: [Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]
 confidence: 0.50
 confidence_base: 0.50
@@ -101,26 +105,21 @@ wird sie erst auf einer fremden Maschine - und wenn niemand die Suite je woander
 - Als Argument gegen Integrationstests gegen echte Systeme. Die stützen sich bewusst auf eine
  Umgebung, und das ist deklariert - nicht still.
 ## Verwandte Concepts
 - [[Green Suite Blind Spot]]
 - [[Structural Enforcement over Documented Rule]]
 ## Beziehungen
 - **abzugrenzen von:** [[Green Suite Blind Spot]]
 - **behoben durch:** [[Structural Enforcement over Documented Rule]]
 - **trat auf in:** [[wikitool]]
 - **beobachtet an:** [[Gitea Actions]]
 ## Siehe auch
 - [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
 - [[Structural Enforcement over Documented Rule]]
 - [[Green Suite Blind Spot]]
 - [[wikitool]]
 - [[Gitea Actions]]
 ## Fußnoten
 [^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]: [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[Structural Enforcement over Documented Rule]]
 - **contrasts:** [[Green Suite Blind Spot]]
 - **exemplifies:** [[wikitool]]
 - **exemplifies:** [[Gitea Actions]]
 <!-- /wikitool:links -->
@@ -4,7 +4,9 @@ concept_type: workflow
 tags: [cramming, heuristic, pages, creation]
 created: 2026-08-03
 modified: 2026-08-29
-related: [Content Quality Control, Iteration and Cost Limits]
+related:
  - part-of: Content Quality Control
  - see-also: Iteration and Cost Limits
 sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Improvements Production Agent Gaps 2026]
 confidence: 0.80
 confidence_base: 0.80
@@ -46,21 +48,20 @@ Die Anti-Cramming-Heuristik ist eine Entscheidungsregel, die hilft zu bestimmen,
 - Wenn das Unterthema inhärent Teil des Hauptthemas ist und eine Aufteilung künstlich wäre
 - Wenn der Inhalt kurz ist und die Seite gut organisiert bleibt
 ## Verwandte Concepts
 - [[Content Quality Control]] - Breitere Qualitätsrichtlinie
 - [[Split Threshold]] - Größenbasierte Aufteilungsregel
 ## Beziehungen
 - **protected by:** [[Iteration and Cost Limits]]
 ## Siehe auch
 - [[Source - LLM Improvements Sonnet Analysis]]
 - [[Iteration and Cost Limits]]
 - [[Source - LLM Improvements Production Agent Gaps 2026]]
 ## Fußnoten
 [^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Content Quality Control]]
 - **see-also:** [[Iteration and Cost Limits]]
 <!-- /wikitool:links -->
@@ -4,7 +4,13 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Implementation Spectrum, Multi-Agent Collaboration, Privacy and Governance, Quality and Self-Correction, Source - LLM Wiki v2, Supersession]
+related:
  - exemplifies: Implementation Spectrum
  - enables: Multi-Agent Collaboration
  - part-of: Privacy and Governance
  - enables: Quality and Self-Correction
  - evidenced-by: Source - LLM Wiki v2
  - enables: Supersession
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +44,14 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[Implementation Spectrum]]
 - **enables:** [[Multi-Agent Collaboration]]
 - **part-of:** [[Privacy and Governance]]
 - **enables:** [[Quality and Self-Correction]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 - **enables:** [[Supersession]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Hybrid Search, LLM Wiki Pattern, Source - LLM Wiki v2]
+related:
  - part-of: Hybrid Search
  - see-also: LLM Wiki Pattern
  - evidenced-by: Source - LLM Wiki v2
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +41,11 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Hybrid Search]]
 - **see-also:** [[LLM Wiki Pattern]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: workflow
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Privacy and Governance, Implementation Spectrum, Mass-Update Gate]
+related:
  - part-of: Privacy and Governance
  - exemplifies: Implementation Spectrum
  - see-also: Mass-Update Gate
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -41,9 +44,12 @@ TODO
 ## Beziehungen
 - **ergaenzt:** [[Mass-Update Gate]]
 ## Siehe auch
- [[Mass-Update Gate]]
+<!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Privacy and Governance]]
 - **exemplifies:** [[Implementation Spectrum]]
 - **see-also:** [[Mass-Update Gate]]
 <!-- /wikitool:links -->
@@ -4,7 +4,9 @@ concept_type: workflow
 tags: [pre-commit, hooks, automation, quality-control]
 created: 2026-08-03
 modified: 2026-09-01
-related: [wikitool, Gitea Actions]
+related:
  - invokes: wikitool
  - operates-on: Gitea Actions
 sources: [Source - LLM Improvements Codex Analysis, Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31]
 confidence: 0.80
 confidence_base: 0.80
@@ -82,24 +84,23 @@ Bootstrap-Anspruch an eine Instanz statt an einen bloßen Checkout).
 ## Verwandte Concepts
 - [[wikitool]] (stellt Lint- und andere Befehle für CI bereit)
 (die Reihenfolge hinter dem Coverage-Reporting)
 (CI-Gates ergänzen Runtime-Gates)
 - [[Lint Workflow]] (Lint ist eine Schlüssel-CI-Prüfung)
 - [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
 ## Beziehungen
 - **verwendet:** [[wikitool]]
 - **implementiert über:** [[Gitea Actions]]
 ## Siehe auch
 - [[Source - LLM Improvements Codex Analysis]]
 - [[wikitool]]
 - [[Gitea Actions]]
 ## Fußnoten
 [^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31]: [[Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31]]
 [^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **invokes:** [[wikitool]]
 - **operates-on:** [[Gitea Actions]]
 <!-- /wikitool:links -->
@@ -1,5 +1,10 @@
 ---
 profile: concepts
 outbound:
  concepts: [extends, grounds, rests-on, enables, precondition, exemplifies, abstracted-from, contrasts, compares-with, contradicts, composition, part-of, supersedes, derived-from, adapted-from, see-also]
  entities: [operationalized-from, mechanism, procedure, applies-when, operates-on, invokes, exemplifies, see-also]
  sources: [evidenced-by, derived-from, adapted-from, defined-in, see-also]
  comparisons: [compares-with, see-also]
 required_by_stack: false
 ---
@@ -33,8 +38,19 @@ An architectural decision is a concept page, prefixed as
 - **Status** - proposed / accepted / deprecated / superseded.
 - Links to every entity the decision affects.
-A superseded ADR is never deleted or rewritten; a new one supersedes it and both link to the
+A superseded ADR is never deleted or rewritten. The new one declares `supersedes` pointing at
-other with `replaces` / `replaced by`.
+it; the old one needs no edge back, because its inbound view renders the replacement.
 ## Authorised labels
 The `outbound:` block above is what `wikitool lint` and `xref add` check: which labels a page in
 this collection may use, per destination. The catalogue they are drawn from - and what each one
 asserts - is [instructions/link-taxonomy.md](../../instructions/link-taxonomy.md), which binds
 nothing on its own.
 The widest authorisation in this instance, because argumentation is what concept pages do. Note that the operational labels are absent: a concept does not `depend-on` anything - the entity implementing it does.
 Adding a label here is a deliberate contract change, not a way around a refusal.
 ## Outbound linking
@@ -4,7 +4,10 @@ concept_type: protocol
 tags: [power-management, cpu, amd, hardware]
 created: 2026-07-31
 modified: 2026-08-29
-related: [Linux Kernel, amd-pstate, Kernel PM Governors]
+related:
  - see-also: Linux Kernel
  - mechanism: amd-pstate
  - see-also: Kernel PM Governors
 sources: [Source - AMD Powermanagement CPU]
 confidence: 0.95
 confidence_base: 0.95
@@ -75,7 +78,10 @@ CPPC bietet mehrere Schlüsselmöglichkeiten:
 ## Siehe auch
- [[amd-pstate]]
+<!-- wikitool:links -->
- [[acpi-cpufreq]]
+## Beziehungen
- [[Kernel PM Governors]]
+
- [[Linux Kernel]]
+- **see-also:** [[Linux Kernel]]
 - **mechanism:** [[amd-pstate]]
 - **see-also:** [[Kernel PM Governors]]
 <!-- /wikitool:links -->
@@ -4,7 +4,9 @@ concept_type: workflow
 tags: [audit, checkpoint, rhythm, quality]
 created: 2026-08-03
 modified: 2026-08-29
-related: [Semantic Lint Automation, Content Quality Control]
+related:
  - see-also: Semantic Lint Automation
  - part-of: Content Quality Control
 sources: [Source - LLM Improvements Sonnet Analysis]
 confidence: 0.80
 confidence_base: 0.80
@@ -64,3 +66,10 @@ Das Checkpoint Audit definiert einen regelmäßigen Rhythmus für Qualitätssich
 ## Fußnoten
 [^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Semantic Lint Automation]]
 - **part-of:** [[Content Quality Control]]
 <!-- /wikitool:links -->
@@ -4,7 +4,9 @@ concept_type: workflow
 tags: [claude-code, permissions, auto-mode, harness, classifier]
 created: 2026-08-31
 modified: 2026-08-31
-related: [Claude Code, Diff-Reviewable Agent Edits]
+related:
  - mechanism: Claude Code
  - contradicts: Diff-Reviewable Agent Edits
 sources: [Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]
 confidence: 0.50
 confidence_base: 0.50
@@ -96,15 +98,17 @@ ist hier also die eingebaute Voreinstellung, keine getroffene Wahl.
 ## Beziehungen
 - **wird umgesetzt von:** [[Claude Code]]
 - **steht in Konflikt mit:** [[Diff-Reviewable Agent Edits]]
 ## Siehe auch
 - [[Claude Code]]
 - [[Diff-Reviewable Agent Edits]]
 - [[Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]]
 ## Fußnoten
 [^s-conversation-auto-mode-and-tool-choice-session-2026-08-31]: [[Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **mechanism:** [[Claude Code]]
 - **contradicts:** [[Diff-Reviewable Agent Edits]]
 <!-- /wikitool:links -->
@@ -4,7 +4,12 @@ concept_type: pattern
 tags: [wikitool, cli, idempotenz, tooling, datenintegritaet]
 created: 2026-08-31
 modified: 2026-08-31
-related: [wikitool, Self-Healing, Detect-Repair Asymmetry, Green Suite Blind Spot, Write-Once Frontmatter Fields]
+related:
  - exemplifies: wikitool
  - enables: Self-Healing
  - contrasts: Detect-Repair Asymmetry
  - see-also: Green Suite Blind Spot
  - contrasts: Write-Once Frontmatter Fields
 sources: [Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]
 confidence: 0.70
 confidence_base: 0.70
@@ -93,29 +98,24 @@ Seite, die kein Befehl mehr reparieren kann, ist eine Sackgasse.
 - Als Argument gegen anhängende Schreibvorgänge überhaupt. Das Problem war nicht das Anhängen
  am Dateiende, sondern ein Leser, der alles dahinter als seinen Bereich betrachtete.
 ## Verwandte Concepts
 - [[Detect-Repair Asymmetry]]
 - [[Self-Healing]]
 - [[Green Suite Blind Spot]]
 ## Beziehungen
 - **tritt auf in:** [[wikitool]]
 - **erzeugt:** [[Self-Healing]]
 - **abgegrenzt gegen:** [[Detect-Repair Asymmetry]]
 - **wird begünstigt durch:** [[Green Suite Blind Spot]]
 - **abgegrenzt gegen:** [[Write-Once Frontmatter Fields]]
 ## Siehe auch
 - [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
 - [[wikitool]]
 - [[Self-Healing]]
 - [[Detect-Repair Asymmetry]]
 - [[Green Suite Blind Spot]]
 - [[Write-Once Frontmatter Fields]]
 ## Fußnoten
 [^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[wikitool]]
 - **enables:** [[Self-Healing]]
 - **contrasts:** [[Detect-Repair Asymmetry]]
 - **see-also:** [[Green Suite Blind Spot]]
 - **contrasts:** [[Write-Once Frontmatter Fields]]
 <!-- /wikitool:links -->
@@ -4,7 +4,9 @@ concept_type: pattern
 tags: [confidence, scoring, reliability, knowledge-management]
 created: 2026-07-26
 modified: 2026-08-29
-related: [Memory Lifecycle, LLM Wiki Pattern]
+related:
  - part-of: Memory Lifecycle
  - exemplifies: LLM Wiki Pattern
 sources: [Source - LLM Wiki v2]
 confidence: 0.95
 confidence_base: 0.95
@@ -128,3 +130,10 @@ Aussage: „Das CI-System verwendet BuildKit auf Port 1234." (als Tatsache angeg
 - [[Event-Driven Automation]] (für automatisierte Konfidenz-Updates)
 - [[Contradiction Resolution]] (für Konfliktbehandlung)
 - [[Self-Healing]] (für automatisierte Konfidenz-Reparatur)
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Memory Lifecycle]]
 - **exemplifies:** [[LLM Wiki Pattern]]
 <!-- /wikitool:links -->
@@ -4,7 +4,13 @@ concept_type: architecture
 tags: [memory, tiers, consolidation, knowledge-management]
 created: 2026-07-26
 modified: 2026-08-29
-related: [Memory Lifecycle, Working Memory, Episodic Memory, Semantic Memory, Procedural Memory, LLM Wiki Pattern]
+related:
  - part-of: Memory Lifecycle
  - composition: Working Memory
  - composition: Episodic Memory
  - composition: Semantic Memory
  - composition: Procedural Memory
  - exemplifies: LLM Wiki Pattern
 sources: [Source - LLM Wiki v2]
 confidence: 0.95
 confidence_base: 0.95
@@ -189,12 +195,6 @@ Basierend auf [[Agent Memory]]-Erfahrung:
 ## Verwandte Konzepte
 - [[Memory Lifecycle]] - Übergeordnetes Konzept
 - [[Working Memory]] - Ebene 1
 - [[Episodic Memory]] - Ebene 2
 - [[Semantic Memory]] - Ebene 3
 - [[Procedural Memory]] - Ebene 4
 - [[LLM Wiki Pattern]] - Gesamtmuster
 - [[Agent Memory]] - Produktive Implementierung
 - [[Forgetting]] - Ergänzender Aufbewahrungsmechanismus
@@ -203,3 +203,14 @@ Basierend auf [[Agent Memory]]-Erfahrung:
 - [[Confidence Scoring]] (für ebenenspezifische Konfidenz)
 - [[Event-Driven Automation]] (für Förderungstrigger)
 - [[Knowledge Graph]] (für ebenenübergreifende Beziehungen)
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Memory Lifecycle]]
 - **composition:** [[Working Memory]]
 - **composition:** [[Episodic Memory]]
 - **composition:** [[Semantic Memory]]
 - **composition:** [[Procedural Memory]]
 - **exemplifies:** [[LLM Wiki Pattern]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: workflow
 tags: [quality, lint, thresholds, pages]
 created: 2026-08-03
 modified: 2026-08-29
-related: [Semantic Lint Automation, Stub Threshold, Split Threshold]
+related:
  - composition: Semantic Lint Automation
  - composition: Stub Threshold
  - composition: Split Threshold
 sources: [Source - LLM Improvements Sonnet Analysis]
 confidence: 0.80
 confidence_base: 0.80
@@ -45,9 +48,6 @@ Content Quality Control bezieht sich auf die Menge der Regeln, Schwellwerte und
 ## Verwandte Konzepte
 - [[Semantic Lint Automation]] - Automatisierte semantische Überprüfungen, die Qualitätsschwellwerte beinhalten könnten
 - [[Stub Threshold]] - Spezifische Mindestanforderung an Inhalte
 - [[Split Threshold]] - Spezifische maximale Größe vor dem Aufteilen
 - [[Index Scaling]] - Verwandte Skalierungsüberlegungen für die Index-Seite
 ## Siehe auch
@@ -57,3 +57,11 @@ Content Quality Control bezieht sich auf die Menge der Regeln, Schwellwerte und
 ## Fußnoten
 [^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **composition:** [[Semantic Lint Automation]]
 - **composition:** [[Stub Threshold]]
 - **composition:** [[Split Threshold]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: architecture
 tags: [context, isolation, efficiency]
 created: 2026-08-04
 modified: 2026-08-29
-related: []
+related:
  - see-also: Token Economics
  - see-also: Scale Ceiling
  - see-also: Workflow Extraction
 sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
 confidence: 0.80
 confidence_base: 0.80
@@ -50,9 +53,6 @@ Context Isolation ist weniger wirksam, wenn:
 ## Verwandte Konzepte
 - [[Cross-platform Agent Skills]]
 - [[Token Economics]]
 - [[Scale Ceiling]]
 - [[Workflow Extraction]]
 ## Siehe auch
@@ -61,3 +61,11 @@ Context Isolation ist weniger wirksam, wenn:
 ## Fußnoten
 [^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Token Economics]]
 - **see-also:** [[Scale Ceiling]]
 - **see-also:** [[Workflow Extraction]]
 <!-- /wikitool:links -->
@@ -4,7 +4,13 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Confidence Scoring, Event-Driven Automation, Multi-Agent Collaboration, Quality and Self-Correction, Source - LLM Wiki v2, Supersession]
+related:
  - rests-on: Confidence Scoring
  - see-also: Event-Driven Automation
  - see-also: Multi-Agent Collaboration
  - part-of: Quality and Self-Correction
  - evidenced-by: Source - LLM Wiki v2
  - enables: Supersession
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +44,14 @@ TODO
 ## Verwandte Konzepte
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **rests-on:** [[Confidence Scoring]]
 - **see-also:** [[Event-Driven Automation]]
 - **see-also:** [[Multi-Agent Collaboration]]
 - **part-of:** [[Quality and Self-Correction]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 - **enables:** [[Supersession]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: architecture
 tags: [skills, agents, cross-platform]
 created: 2026-08-04
 modified: 2026-09-01
-related: []
+related:
  - rests-on: Context Isolation
  - rests-on: Token Economics
  - see-also: Scale Ceiling
  - see-also: Workflow Extraction
 sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
 confidence: 0.90
 confidence_base: 0.90
@@ -66,13 +70,6 @@ Dieses Muster vermeiden, wenn:
 - Workflows so eng gekoppelt sind, dass sie nicht sauber unterteilt werden können
 - der Overhead für die Verwaltung der Skill-Struktur die Vorteile überwiegt
 ## Verwandte Konzepte
 - [[Token Economics]]
 - [[Scale Ceiling]]
 - [[Context Isolation]]
 - [[Workflow Extraction]]
 ## Siehe auch
 - [[Source - Copilot Skill Restructure Instructions]]
@@ -82,3 +79,12 @@ Dieses Muster vermeiden, wenn:
 [^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
 [^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **rests-on:** [[Context Isolation]]
 - **rests-on:** [[Token Economics]]
 - **see-also:** [[Scale Ceiling]]
 - **see-also:** [[Workflow Extraction]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: workflow
 tags: [crystallization, knowledge, distillation, workflow]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, Memory Lifecycle, Event-Driven Automation]
+related:
  - exemplifies: LLM Wiki Pattern
  - part-of: Memory Lifecycle
  - rests-on: Event-Driven Automation
 sources: [Source - LLM Wiki v2]
 confidence: 0.85
 confidence_base: 0.85
@@ -138,9 +141,6 @@ Mit [[Event-Driven Automation]] integrieren:
 ## Verwandte Konzepte
 - [[LLM Wiki Pattern]] - Gesamtmuster
 - [[Memory Lifecycle]] - Wie kristallisiertes Wissen verwaltet wird
 - [[Event-Driven Automation]] - Für automatische Crystallization
 - [[Consolidation Tiers]] - Wo kristallisiertes Wissen befördert wird
 - [[Knowledge Compounding]] - Der Gesamteffekt
@@ -148,3 +148,11 @@ Mit [[Event-Driven Automation]] integrieren:
 - [[Implementation Spectrum]] (Crystallization als erweiterte Funktion)
 - [[Quality and Self-Correction]] (Sicherung der Qualität kristallisierten Inhalts)
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **part-of:** [[Memory Lifecycle]]
 - **rests-on:** [[Event-Driven Automation]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: decision
 tags: []
 created: 2026-09-01
 modified: 2026-09-01
-related: [Chemenu]
+related:
  - operates-on: Chemenu
 sources: ['Source - Public Release, Corpus Purge and History Squash Session 2026-09-01', Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]
 confidence: 0.70
 confidence_base: 0.70
@@ -63,11 +64,13 @@ sonst unverändertem Inhalt) vorzuziehen - wenn ein unterstütztes Löschkommand
 ## Beziehungen
 - **gilt fuer:** [[Chemenu]]
 ## Siehe auch
 - [[Source - Public Release, Corpus Purge and History Squash Session 2026-09-01]]
 - [[Chemenu]]
 - [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **operates-on:** [[Chemenu]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: decision
 tags: [schema, tooling, cli, design-rule]
 created: 2026-08-31
 modified: 2026-08-31
-related: [wikitool, Write-Once Frontmatter Fields, AGENTS.md, Green Suite Blind Spot]
+related:
  - mechanism: wikitool
  - grounds: Write-Once Frontmatter Fields
  - see-also: Green Suite Blind Spot
 sources: [Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31, Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]
 confidence: 0.70
 confidence_base: 0.70
@@ -83,21 +86,20 @@ Angenommen (2026-08-31) mit Stack-Version `1.4.0`, Commit
 ## Beziehungen
 - **umgesetzt in:** [[wikitool]]
 - **begründet die Lösung von:** [[Write-Once Frontmatter Fields]]
 - **beruft sich auf:** [[AGENTS.md]]
 - **verwandt mit:** [[Green Suite Blind Spot]]
 ## Siehe auch
 - [[wikitool]]
 - [[Write-Once Frontmatter Fields]]
 - [[AGENTS.md]]
 - [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
 - [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
 - [[Green Suite Blind Spot]]
 ## Fußnoten
 [^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]: [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
 [^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **mechanism:** [[wikitool]]
 - **grounds:** [[Write-Once Frontmatter Fields]]
 - **see-also:** [[Green Suite Blind Spot]]
 <!-- /wikitool:links -->
@@ -4,7 +4,13 @@ concept_type: problem
 tags: [tooling, lint, provenance, hand-edit, gap]
 created: 2026-08-31
 modified: 2026-08-31
-related: [wikitool, Lint Workflow, Self-Healing, Issue Label Scheme, Write-Once Frontmatter Fields, Command Round-Trip Integrity]
+related:
  - exemplifies: wikitool
  - rests-on: Lint Workflow
  - contrasts: Self-Healing
  - see-also: Issue Label Scheme
  - contrasts: Write-Once Frontmatter Fields
  - contrasts: Command Round-Trip Integrity
 sources: [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 - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]
 confidence: 0.50
 confidence_base: 0.50
@@ -102,34 +108,27 @@ auftritt.
 - Als Begründung, einen Check wegzulassen, bis die Reparatur fertig ist. Ein gemeldeter Defekt
  ohne Reparatur ist immer noch besser als ein unbemerkter.
 ## Verwandte Concepts
 - [[Self-Healing]]
 - [[Lint Workflow]]
 ## Beziehungen
 - **abgegrenzt gegen:** [[Write-Once Frontmatter Fields]]
 - **tritt auf in:** [[wikitool]]
 - **wird sichtbar durch:** [[Lint Workflow]]
 - **abgegrenzt gegen:** [[Self-Healing]]
 - **verwandt mit:** [[Issue Label Scheme]]
 - **abgegrenzt gegen:** [[Command Round-Trip Integrity]]
 ## Siehe auch
 - [[Write-Once Frontmatter Fields]]
 - [[wikitool]]
 - [[Lint Workflow]]
 - [[Self-Healing]]
 - [[Issue Label Scheme]]
 - [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
 - [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
 - [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
 - [[Command Round-Trip Integrity]]
 ## Fußnoten
 [^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]: [[Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]]
 [^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]: [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
 [^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[wikitool]]
 - **rests-on:** [[Lint Workflow]]
 - **contrasts:** [[Self-Healing]]
 - **see-also:** [[Issue Label Scheme]]
 - **contrasts:** [[Write-Once Frontmatter Fields]]
 - **contrasts:** [[Command Round-Trip Integrity]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: decision
 tags: [agent-workflow, context-engineering, tooling]
 created: 2026-08-31
 modified: 2026-08-31
-related: [Claude Code Auto Mode, Claude Code, Write-Once Frontmatter Fields]
+related:
  - see-also: Claude Code Auto Mode
  - operates-on: Claude Code
  - derived-from: Write-Once Frontmatter Fields
 sources: [Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]
 confidence: 0.70
 confidence_base: 0.70
@@ -75,17 +78,18 @@ Angenommen (2026-08-31), auf Anweisung des Nutzers, für Sitzungen an diesem Rep
 ## Beziehungen
 - **korrigiert:** [[Claude Code Auto Mode]]
 - **gilt für:** [[Claude Code]]
 - **war betroffen von:** [[Write-Once Frontmatter Fields]]
 ## Siehe auch
 - [[Claude Code Auto Mode]]
 - [[Claude Code]]
 - [[Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]]
 - [[Write-Once Frontmatter Fields]]
 ## Fußnoten
 [^s-conversation-auto-mode-and-tool-choice-session-2026-08-31]: [[Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Claude Code Auto Mode]]
 - **operates-on:** [[Claude Code]]
 - **derived-from:** [[Write-Once Frontmatter Fields]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: decision
 tags: []
 created: 2026-09-01
 modified: 2026-09-01
-related: [Chemenu]
+related:
  - operates-on: Chemenu
 sources: ['Source - Public Release, Corpus Purge and History Squash Session 2026-09-01']
 confidence: 0.70
 confidence_base: 0.70
@@ -56,16 +57,14 @@ Distributions-/Build-Werkzeug ohnehin pflegt.
  separate, maschinell nachvollziehbare Grenze existiert - dort wäre die Lizenz-Zuordnung selbst
  wieder eine unabhängige, drift-anfällige Liste.
 ## Verwandte Concepts
 - [[Chemenu]]
 ## Beziehungen
 - **gilt fuer:** [[Chemenu]]
 ## Siehe auch
 - [[Source - Public Release, Corpus Purge and History Squash Session 2026-09-01]]
 - [[Chemenu]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **operates-on:** [[Chemenu]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Implementation Spectrum, Knowledge Graph, Source - LLM Wiki v2]
+related:
  - exemplifies: Implementation Spectrum
  - enables: Knowledge Graph
  - evidenced-by: Source - LLM Wiki v2
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -37,4 +40,10 @@ TODO
 ## Verwandte Concepts
- TODO
+<!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[Implementation Spectrum]]
 - **enables:** [[Knowledge Graph]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: architecture
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Consolidation Tiers]
+related:
  - part-of: Consolidation Tiers
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -37,4 +38,8 @@ TODO
 ## Verwandte Concepts
- TODO
+<!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Consolidation Tiers]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: workflow
 tags: [automation, hooks, events, workflow]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, Memory Lifecycle, Hooks]
+related:
  - exemplifies: LLM Wiki Pattern
  - enables: Memory Lifecycle
  - rests-on: Hooks
 sources: [Source - LLM Wiki v2]
 confidence: 0.95
 confidence_base: 0.95
@@ -169,9 +172,6 @@ Mit **Stufe 2 (Basis)** beginnen und Ereignisse nach Bedarf hinzufügen:
 ## Verwandte Concepts
 - [[LLM Wiki Pattern]] - Gesamtmuster
 - [[Memory Lifecycle]] - Was Automatisierung verwaltet
 - [[Hooks]] - Der Implementierungsmechanismus
 - [[Agent Memory]] - Produktionsimplementierung
 - [[Quality and Self-Correction]] - Ergänzende Qualitätsmechanismen
@@ -183,3 +183,11 @@ Mit **Stufe 2 (Basis)** beginnen und Ereignisse nach Bedarf hinzufügen:
 - [[Forgetting]] (angewandt durch Automatisierung)
 - [[Hybrid Search]] (verwendet in Query-Automatisierung)
 - [[Contradiction Resolution]] (ausgelöst durch Automatisierung)
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **enables:** [[Memory Lifecycle]]
 - **rests-on:** [[Hooks]]
 <!-- /wikitool:links -->
@@ -4,7 +4,9 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Implementation Spectrum, Privacy and Governance]
+related:
  - exemplifies: Implementation Spectrum
  - part-of: Privacy and Governance
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -37,4 +39,9 @@ TODO
 ## Verwandte Concepts
- TODO
+<!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[Implementation Spectrum]]
 - **part-of:** [[Privacy and Governance]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: pattern
 tags: [memory, retention, decay, ebbinghaus]
 created: 2026-07-26
 modified: 2026-08-29
-related: [Memory Lifecycle, Confidence Scoring, Consolidation Tiers]
+related:
  - part-of: Memory Lifecycle
  - see-also: Confidence Scoring
  - rests-on: Consolidation Tiers
 sources: [Source - LLM Wiki v2]
 confidence: 0.90
 confidence_base: 0.90
@@ -149,9 +152,6 @@ Fakten mit niedrigerer Priorität:
 ## Verwandte Concepts
 - [[Memory Lifecycle]] - Übergeordnetes Concept
 - [[Confidence Scoring]] - Ergänzender Zuverlässigkeitsmechanismus
 - [[Consolidation Tiers]] - Tier-spezifische Verfallsraten
 - [[Supersession]] - Umgang mit veralteten Informationen
 - [[LLM Wiki Pattern]] - Gesamtmuster
@@ -159,3 +159,11 @@ Fakten mit niedrigerer Priorität:
 - [[Event-Driven Automation]] (für automatisiertes Verstärkungstracking)
 - [[Quality and Self-Correction]] (für verwandte Qualitätsmechanismen)
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Memory Lifecycle]]
 - **see-also:** [[Confidence Scoring]]
 - **rests-on:** [[Consolidation Tiers]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Hybrid Search, Knowledge Graph, LLM Wiki Pattern, Source - LLM Wiki v2]
+related:
  - part-of: Hybrid Search
  - rests-on: Knowledge Graph
  - exemplifies: LLM Wiki Pattern
  - evidenced-by: Source - LLM Wiki v2
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -37,4 +41,11 @@ TODO
 ## Verwandte Concepts
- TODO
+<!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Hybrid Search]]
 - **rests-on:** [[Knowledge Graph]]
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -4,7 +4,12 @@ concept_type: problem
 tags: [tests, regression, tooling, quality]
 created: 2026-08-31
 modified: 2026-08-31
-related: [Command Round-Trip Integrity, wikitool, Denylist over Allowlist, Ambient Environment Dependency, Lint Workflow]
+related:
  - see-also: Command Round-Trip Integrity
  - exemplifies: wikitool
  - see-also: Denylist over Allowlist
  - see-also: Ambient Environment Dependency
  - rests-on: Lint Workflow
 sources: [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]
 confidence: 0.70
 confidence_base: 0.70
@@ -110,30 +115,26 @@ widersprechen: jede für sich ist getestet, das Zusammenspiel hat nie jemand auf
 ## Verwandte Concepts
 - [[Command Round-Trip Integrity]]
 - [[Denylist over Allowlist]]
 - [[Ambient Environment Dependency]]
 - [[Structural Enforcement over Documented Rule]]
 ## Beziehungen
 - **begünstigt:** [[Command Round-Trip Integrity]]
 - **trat auf in:** [[wikitool]]
 - **belegt an:** [[Denylist over Allowlist]]
 - **abzugrenzen von:** [[Ambient Environment Dependency]]
 - **belegt an:** [[Lint Workflow]]
 ## Siehe auch
 - [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
 - [[Command Round-Trip Integrity]]
 - [[wikitool]]
 - [[Denylist over Allowlist]]
 - [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
 - [[Ambient Environment Dependency]]
 - [[Lint Workflow]]
 ## Fußnoten
 [^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
 [^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]: [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Command Round-Trip Integrity]]
 - **exemplifies:** [[wikitool]]
 - **see-also:** [[Denylist over Allowlist]]
 - **see-also:** [[Ambient Environment Dependency]]
 - **rests-on:** [[Lint Workflow]]
 <!-- /wikitool:links -->
@@ -4,7 +4,9 @@ concept_type: workflow
 tags: [automation, events, triggers, workflow]
 created: 2026-07-26
 modified: 2026-08-29
-related: [Event-Driven Automation, LLM Wiki Pattern]
+related:
  - grounds: Event-Driven Automation
  - exemplifies: LLM Wiki Pattern
 sources: [Source - LLM Wiki v2]
 confidence: 0.85
 confidence_base: 0.85
@@ -129,8 +131,6 @@ Hooks sollten **robust** sein:
 ## Verwandte Concepts
 - [[Event-Driven Automation]] - Das Gesamtautomatisierungs-Framework
 - [[LLM Wiki Pattern]] - Das übergeordnete Muster
 - [[Memory Lifecycle]] - Was Hooks helfen zu verwalten
 - [[Quality and Self-Correction]] - Qualitätsbezogene Hooks
@@ -140,3 +140,10 @@ Hooks sollten **robust** sein:
 - [[Consolidation Tiers]] (hochgestuft durch Hooks)
 - [[Forgetting]] (angewandt durch Hooks)
 - [[Confidence Scoring]] (aktualisiert durch Hooks)
 <!-- wikitool:links -->
 ## Beziehungen
 - **grounds:** [[Event-Driven Automation]]
 - **exemplifies:** [[LLM Wiki Pattern]]
 <!-- /wikitool:links -->
@@ -4,7 +4,13 @@ concept_type: architecture
 tags: [search, bm25, vector, graph, scalability]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, BM25, Vector Search, Reciprocal Rank Fusion, Knowledge Graph, Graph Traversal]
+related:
  - exemplifies: LLM Wiki Pattern
  - see-also: BM25
  - composition: Vector Search
  - composition: Reciprocal Rank Fusion
  - rests-on: Knowledge Graph
  - see-also: Graph Traversal
 sources: [Source - LLM Wiki v2]
 confidence: 0.90
 confidence_base: 0.90
@@ -115,15 +121,20 @@ Abfrage: "Wie funktioniert das Auth-System?"
 ## Verwandte Concepts
 - [[LLM Wiki Pattern]] - Gesamtmuster
 - [[BM25]] - Schlüsselwortabgleich-Komponente
 - [[Vector Search]] - Semantische Ähnlichkeits-Komponente
 - [[Reciprocal Rank Fusion]] - Fusionsalgorithmus
 - [[Knowledge Graph]] - Graph-Traversal-Komponente
 - [[Graph Traversal]] - Der Graph-Suchmechanismus
 - [[Agent Memory]] - Produktionsimplementierung
 ## Siehe auch
 - [[Event-Driven Automation]] (für automatisierte Indizierung)
 - Scalable Search (verwandtes Concept)
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **see-also:** [[BM25]]
 - **composition:** [[Vector Search]]
 - **composition:** [[Reciprocal Rank Fusion]]
 - **rests-on:** [[Knowledge Graph]]
 - **see-also:** [[Graph Traversal]]
 <!-- /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 |
@@ -4,7 +4,14 @@ concept_type: architecture
 tags: [implementation, modular, levels, adoption]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, Memory Lifecycle, Knowledge Graph, Event-Driven Automation, Multi-Agent Collaboration, Privacy and Governance, Crystallization]
+related:
  - rests-on: LLM Wiki Pattern
  - composition: Memory Lifecycle
  - composition: Knowledge Graph
  - composition: Event-Driven Automation
  - composition: Multi-Agent Collaboration
  - composition: Privacy and Governance
  - composition: Crystallization
 sources: [Source - LLM Wiki v2]
 confidence: 0.90
 confidence_base: 0.90
@@ -224,16 +231,21 @@ Level 0 → Level 1 → Level 2 → Level 3 → Level 4 → Level 5 → Level 6
 ## Verwandte Concepts
 - [[LLM Wiki Pattern]] - Gesamtmuster
 - [[Memory Lifecycle]] - Level-1-Erweiterung
 - [[Knowledge Graph]] - Level-2-Erweiterung
 - [[Event-Driven Automation]] - Level-3-Erweiterung
 - [[Hybrid Search]] - Level-4-Erweiterung
 - [[Multi-Agent Collaboration]] - Level-5-Erweiterung
 - [[Privacy and Governance]] - Level-6-Erweiterung
 - [[Crystallization]] - Level-7-Erweiterung
 ## Siehe auch
 - [[Three-Layer Architecture]] (Grundlage für alle Ebenen)
 - [[Agent Memory]] (Implementierung höherer Ebenen)
 <!-- wikitool:links -->
 ## Beziehungen
 - **rests-on:** [[LLM Wiki Pattern]]
 - **composition:** [[Memory Lifecycle]]
 - **composition:** [[Knowledge Graph]]
 - **composition:** [[Event-Driven Automation]]
 - **composition:** [[Multi-Agent Collaboration]]
 - **composition:** [[Privacy and Governance]]
 - **composition:** [[Crystallization]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: workflow
 tags: [index, scaling, thresholds, pages]
 created: 2026-08-03
 modified: 2026-08-29
-related: [Content Quality Control, Split Threshold, pascalandy schema, Iteration and Cost Limits]
+related:
  - part-of: Content Quality Control
  - see-also: Split Threshold
  - operationalized-from: pascalandy schema
  - see-also: Iteration and Cost Limits
 sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Improvements Production Agent Gaps 2026]
 confidence: 0.80
 confidence_base: 0.80
@@ -56,21 +60,24 @@ Index Scaling definiert Regeln und Schwellenwerte für den Zeitpunkt und die Art
 ## Verwandte Concepts
 - [[Content Quality Control]] - Umfassenderes Qualitätssystem
 - [[Split Threshold]] - Ähnliches Konzept für einzelne Seiten
 - [[pascalandy schema]] - Quelle der Skalierungsempfehlungen
 - [[Three-Layer Architecture]] - Index ist Teil der Wiki-Ebene
 ## Beziehungen
 - **geschützt durch:** [[Iteration and Cost Limits]]
 ## Siehe auch
 - [[Source - LLM Improvements Sonnet Analysis]]
 - [[Iteration and Cost Limits]]
 - [[Source - LLM Improvements Production Agent Gaps 2026]]
 ## Fußnoten
 [^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Content Quality Control]]
 - **see-also:** [[Split Threshold]]
 - **operationalized-from:** [[pascalandy schema]]
 - **see-also:** [[Iteration and Cost Limits]]
 <!-- /wikitool:links -->
@@ -3,13 +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: [Chemenu, Gitea MCP Server, KB Stack Versioning, Detect-Repair Asymmetry]
+related:
-sources: [Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]
+  - 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]
 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
@@ -18,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
@@ -59,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
@@ -76,51 +144,53 @@ 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.
-## Verwandte Concepts
+<!-- wikitool:links -->
 - [[KB Stack Versioning]]
 - [[Detect-Repair Asymmetry]]
 ## Beziehungen
- **gilt für:** [[Chemenu]]
+- **operates-on:** [[Chemenu]]
- **umgesetzt über:** [[Gitea MCP Server]]
+- **mechanism:** [[Gitea MCP Server]]
- **verwandt mit:** [[KB Stack Versioning]]
+- **see-also:** [[KB Stack Versioning]]
- **verwandt mit:** [[Detect-Repair Asymmetry]]
+- **see-also:** [[Detect-Repair Asymmetry]]
-
+<!-- /wikitool:links -->
 ## Siehe auch
 - [[Chemenu]]
 - [[Gitea MCP Server]]
 - [[KB Stack Versioning]]
 - [[Detect-Repair Asymmetry]]
 - [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
 <!-- 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 -->
@@ -4,7 +4,13 @@ concept_type: workflow
 tags: [gate, safety, iteration-budget, loop-breaker]
 created: 2026-08-07
 modified: 2026-09-02
-related: [Mass-Update Gate, Anti-Cramming Heuristic, Index Scaling, wikitool, Structural Enforcement over Documented Rule, MCP-Leseserver]
+related:
  - compares-with: Mass-Update Gate
  - see-also: Anti-Cramming Heuristic
  - see-also: Index Scaling
  - mechanism: wikitool
  - exemplifies: Structural Enforcement over Documented Rule
  - see-also: MCP-Leseserver
 sources: [Source - LLM Improvements Production Agent Gaps 2026, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31, Source - MCP Read Server Implementation Session 2026-09-02]
 confidence: 0.88
 confidence_base: 0.88
@@ -54,32 +60,12 @@ Eine hart in Code durchgesetzte Obergrenze für die Anzahl der Tool-Aufrufe, die
  den Serverprozess gehört (Rate Limiting), nicht in dieses Gate - beide zu vermischen würde es
  zu einem Rate Limiter verwässern.[^s-mcp-read-server-implementation-session-2026-09-02]
 ## Verwandte Concepts
 - [[Mass-Update Gate]] - das verwandte Sicherheitsgate, das dieses Muster spiegelt, begrenzt auf Veröffentlichungsgröße statt Sitzungsiterationsvolumen
 - [[Anti-Cramming Heuristic]] - eines der Wiki-Qualitätsprobleme, die ein unbegrenzter Ingest-Lauf sonst verletzen könnte
 - [[Index Scaling]] - das andere Wiki-Qualitätsproblem, das durch unkontrolliertes Seitenwachstum gefährdet ist
 - [[wikitool]] - die CLI, die dieses Gate implementiert
 ## Beziehungen
 - **spiegelt das gleiche Muster wie:** [[Mass-Update Gate]]
 - **schützt:** [[Anti-Cramming Heuristic]]
 - **schützt:** [[Index Scaling]]
 - **implementiert durch:** [[wikitool]]
 - **wendet an:** [[Structural Enforcement over Documented Rule]]
 - **nimmt aus:** [[MCP-Leseserver]]
 ## Siehe auch
 - [[Mass-Update Gate]]
 - [[Anti-Cramming Heuristic]]
 - [[Index Scaling]]
 - [[wikitool]]
 - [[Source - LLM Improvements Production Agent Gaps 2026]]
 - [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
 - [[Structural Enforcement over Documented Rule]]
 - [[MCP-Leseserver]]
 ## Fußnoten
@@ -87,3 +73,14 @@ Eine hart in Code durchgesetzte Obergrenze für die Anzahl der Tool-Aufrufe, die
 [^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]: [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
 [^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]: [[Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]]
 [^s-mcp-read-server-implementation-session-2026-09-02]: [[Source - MCP Read Server Implementation Session 2026-09-02]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **compares-with:** [[Mass-Update Gate]]
 - **see-also:** [[Anti-Cramming Heuristic]]
 - **see-also:** [[Index Scaling]]
 - **mechanism:** [[wikitool]]
 - **exemplifies:** [[Structural Enforcement over Documented Rule]]
 - **see-also:** [[MCP-Leseserver]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: workflow
 tags: [migration, versioning, corpus-diff, workflow]
 created: 2026-08-30
 modified: 2026-08-31
-related: [wikitool]
+related:
  - mechanism: wikitool
  - rests-on: KB Stack Versioning
  - see-also: Mass-Update Gate
  - see-also: Iteration and Cost Limits
 sources: [Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]
 confidence: 0.70
 confidence_base: 0.70
@@ -116,12 +120,15 @@ verweigert[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-0
  Werkzeug, weil er selbstprüfend ist: er meldet `FAIL`, bis die Sache erledigt ist, während
  `migrate done` eine Behauptung ist, die man ohne die Arbeit aufstellen kann.
 ## Verwandte Concepts
 - [[KB Stack Versioning]]
 - [[Mass-Update Gate]]
 - [[Iteration and Cost Limits]]
 ## Fußnoten
 [^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]: [[Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **mechanism:** [[wikitool]]
 - **rests-on:** [[KB Stack Versioning]]
 - **see-also:** [[Mass-Update Gate]]
 - **see-also:** [[Iteration and Cost Limits]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: decision
 tags: [versioning, semver, release, stack]
 created: 2026-08-30
 modified: 2026-09-02
-related: [wikitool, Issue Label Scheme]
+related:
  - mechanism: wikitool
  - see-also: Issue Label Scheme
  - see-also: CI Integration
 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 - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02]
 confidence: 0.70
 confidence_base: 0.70
@@ -103,20 +106,10 @@ kann.
 - Nicht als automatischer Bump aus Commit-Nachrichten, solange Content-Commits und
  Stack-Commits im selben Repository liegen.
 ## Verwandte Concepts
 - [[KB Migration]]
 - [[CI Integration]]
 ## Beziehungen
 - **umgesetzt von:** [[wikitool]]
 - **verwandt mit:** [[Issue Label Scheme]]
 ## Siehe auch
 - [[wikitool]]
 - [[Issue Label Scheme]]
 - [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
 - [[Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02]]
@@ -124,3 +117,11 @@ kann.
 [^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]: [[Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]]
 [^s-version-part-nomenclature-and-breaking-change-gate-session-2026-09-02]: [[Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **mechanism:** [[wikitool]]
 - **see-also:** [[Issue Label Scheme]]
 - **see-also:** [[CI Integration]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: workflow
 tags: [knowledge-management, growth, learning]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, Memex, Tolkien Gateway]
+related:
  - part-of: LLM Wiki Pattern
  - see-also: Memex
  - see-also: Tolkien Gateway
 sources: [Source - LLM Wiki Pattern]
 confidence: 0.90
 confidence_base: 0.90
@@ -118,7 +121,12 @@ Mit LLM Wiki Pattern:
 ## Siehe auch
 - [[LLM Wiki Pattern]]
 - [[Memex]]
 - [[Tolkien Gateway]]
 - [[Three-Layer Architecture]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[LLM Wiki Pattern]]
 - **see-also:** [[Memex]]
 - **see-also:** [[Tolkien Gateway]]
 <!-- /wikitool:links -->
@@ -4,7 +4,12 @@ concept_type: architecture
 tags: [graph, entities, relationships, knowledge-management]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, Memory Lifecycle, Entity Extraction, Typed Relationships, Graph Traversal]
+related:
  - exemplifies: LLM Wiki Pattern
  - see-also: Memory Lifecycle
  - see-also: Entity Extraction
  - composition: Typed Relationships
  - see-also: Graph Traversal
 sources: [Source - LLM Wiki v2]
 confidence: 0.90
 confidence_base: 0.90
@@ -130,11 +135,6 @@ Basierend auf [[Agent Memory]] und [[iii Engine]]:
 ## Verwandte Concepts
 - [[LLM Wiki Pattern]] - Gesamtes Muster
 - [[Entity Extraction]] - Füllung des Graphen
 - [[Typed Relationships]] - Die Beziehungstypen
 - [[Graph Traversal]] - Abfragemechanismus
 - [[Memory Lifecycle]] - Komplementäres Wissensmanagement
 - [[Agent Memory]] - Produktionsimplementierung
 ## Siehe auch
@@ -142,3 +142,13 @@ Basierend auf [[Agent Memory]] und [[iii Engine]]:
 - [[Hybrid Search]] (nutzt Graph-Traversal als einen Stream)
 - [[Event-Driven Automation]] (für automatische Graph-Updates)
 - [[Supersession]] (als Graph-Beziehung verfolgt)
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **see-also:** [[Memory Lifecycle]]
 - **see-also:** [[Entity Extraction]]
 - **composition:** [[Typed Relationships]]
 - **see-also:** [[Graph Traversal]]
 <!-- /wikitool:links -->
@@ -4,7 +4,13 @@ concept_type: architecture
 tags: [knowledge-management, llm, wiki, pattern]
 created: 2026-07-26
 modified: 2026-08-29
-related: [Three-Layer Architecture, Knowledge Compounding, RAG, Memex, Vannevar Bush, Memory Lifecycle]
+related:
  - rests-on: Three-Layer Architecture
  - see-also: Knowledge Compounding
  - contrasts: RAG
  - see-also: Vannevar Bush
  - composition: Memory Lifecycle
  - see-also: Memex
 sources: [Source - LLM Wiki Pattern, Source - LLM Wiki v2]
 confidence: 0.95
 confidence_base: 0.95
@@ -201,11 +207,6 @@ Periodische Gesundheitsprüfung zu:
 ## Verwandte Concepts
 - [[RAG]]: Der traditionelle Ansatz, den dieses Muster verbessert
 - [[Knowledge Compounding]]: Die Auswirkung des Aufbaus von Wissen auf sich selbst
 - [[Three-Layer Architecture]]: Die architektonische Grundlage
 - [[Memex]]: Vannevar Bushs 1945er Vision, die dieses Muster inspirierte
 ## Beispiele
 - **Persönlich**: Ziele, Gesundheit, Psychologie, Selbstverbesserung verfolgen
@@ -230,10 +231,15 @@ Periodische Gesundheitsprüfung zu:
 ## Siehe auch
 - [[Three-Layer Architecture]]
 - [[Knowledge Compounding]]
 - [[RAG]]
 - [[Memex]]
 - [[Vannevar Bush]]
 - [[Obsidian]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **rests-on:** [[Three-Layer Architecture]]
 - **see-also:** [[Knowledge Compounding]]
 - **contrasts:** [[RAG]]
 - **see-also:** [[Vannevar Bush]]
 - **composition:** [[Memory Lifecycle]]
 - **see-also:** [[Memex]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: workflow
 tags: []
 created: 2026-08-02
 modified: 2026-09-01
-related: [Event-Driven Automation, Quality and Self-Correction, Detect-Repair Asymmetry, Green Suite Blind Spot]
+related:
  - see-also: Event-Driven Automation
  - part-of: Quality and Self-Correction
  - grounds: Detect-Repair Asymmetry
  - grounds: Green Suite Blind Spot
 sources: [Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]
 confidence: 0.50
 confidence_base: 0.50
@@ -48,21 +52,22 @@ Läuft nach Zeitplan (täglich/wöchentlich) ab und kann durch Memory-Write-Erei
 ## Verwandte Concepts
 - [[Quality and Self-Correction]]
 - [[Confidence Scoring]]
 - [[Event-Driven Automation]]
 - [[LLM Wiki Pattern]]
 ## Beziehungen
 - **macht sichtbar:** [[Detect-Repair Asymmetry]]
 - **abgesichert von:** [[Green Suite Blind Spot]]
 ## Siehe auch
 - [[Detect-Repair Asymmetry]]
 - [[Green Suite Blind Spot]]
 ## Fußnoten
 [^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]: [[Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Event-Driven Automation]]
 - **part-of:** [[Quality and Self-Correction]]
 - **grounds:** [[Detect-Repair Asymmetry]]
 - **grounds:** [[Green Suite Blind Spot]]
 <!-- /wikitool:links -->
@@ -4,7 +4,12 @@ concept_type: architecture
 tags: [mcp, library-boundary, search, server]
 created: 2026-09-02
 modified: 2026-09-02
-related: [wikitool, Publish-Remote Gate, Mass-Update Gate, Iteration and Cost Limits, Chemenu]
+related:
  - operates-on: wikitool
  - see-also: Publish-Remote Gate
  - see-also: Mass-Update Gate
  - see-also: Iteration and Cost Limits
  - see-also: Chemenu
 sources: [Source - MCP Read Server Implementation Session 2026-09-02]
 confidence: 0.50
 confidence_base: 0.50
@@ -79,30 +84,22 @@ vertrauen, dass sie übereinstimmen.
 - Als Ersatz für den Iteration Budget Gate oder das Traefik-Rate-Limiting - beide bleiben
  notwendig und leben an anderer Stelle.
 ## Verwandte Concepts
 - [[Publish-Remote Gate]]
 - [[Mass-Update Gate]]
 - [[Iteration and Cost Limits]]
 ## Fußnoten
 [^s-mcp-read-server-implementation-session-2026-09-02]: [[Source - MCP Read Server Implementation Session 2026-09-02]]
 ## Beziehungen
 - **implementiert:** [[wikitool]]
 - **verwandt mit:** [[Publish-Remote Gate]]
 - **verwandt mit:** [[Mass-Update Gate]]
 - **ausgenommen von:** [[Iteration and Cost Limits]]
 - **Teil von:** [[Chemenu]]
 ## Siehe auch
 - [[wikitool]]
 - [[Publish-Remote Gate]]
 - [[Mass-Update Gate]]
 - [[Iteration and Cost Limits]]
 - [[Chemenu]]
 - [[Source - MCP Read Server Implementation Session 2026-09-02]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **operates-on:** [[wikitool]]
 - **see-also:** [[Publish-Remote Gate]]
 - **see-also:** [[Mass-Update Gate]]
 - **see-also:** [[Iteration and Cost Limits]]
 - **see-also:** [[Chemenu]]
 <!-- /wikitool:links -->
@@ -4,7 +4,14 @@ concept_type: workflow
 tags: [gate, safety, mass-update, confirmation]
 created: 2026-08-03
 modified: 2026-09-01
-related: [Content Quality Control, wikitool, Iteration and Cost Limits, Structural Enforcement over Documented Rule, Bulk Operations, Publish-Remote Gate, MCP-Leseserver]
+related:
  - enables: Content Quality Control
  - mechanism: wikitool
  - see-also: Iteration and Cost Limits
  - exemplifies: Structural Enforcement over Documented Rule
  - contrasts: Bulk Operations
  - see-also: Publish-Remote Gate
  - see-also: MCP-Leseserver
 sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Improvements Production Agent Gaps 2026, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31, Source - LLM Improvements Codex Analysis]
 confidence: 0.88
 confidence_base: 0.88
@@ -68,28 +75,15 @@ Das Mass-Update Gate ist ein Sicherheitsmechanismus, der die Ausführung pausier
 ## Verwandte Concepts
 - [[Content Quality Control]] - Qualitätsrahmen, den Massenaktualisierungen bewahren sollten
 - [[wikitool]] - Das CLI-Tool, das dieses Gate implementieren könnte
 - [[Workflow Orchestration]] - Koordinierte Vorgänge, die Gates benötigen könnten
 ## Beziehungen
 - **wird gespiegelt durch:** [[Iteration and Cost Limits]]
 - **wendet an:** [[Structural Enforcement over Documented Rule]]
 - **grenzt ab gegen:** [[Bulk Operations]]
 - **verwandtes Gate:** [[Publish-Remote Gate]]
 - **verwandt mit:** [[MCP-Leseserver]]
 ## Siehe auch
 - [[Source - LLM Improvements Sonnet Analysis]]
 - [[Iteration and Cost Limits]]
 - [[Source - LLM Improvements Production Agent Gaps 2026]]
 - [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
 - [[Structural Enforcement over Documented Rule]]
 - [[Bulk Operations]]
 - [[Publish-Remote Gate]]
 - [[MCP-Leseserver]]
 ## Fußnoten
@@ -97,3 +91,15 @@ Das Mass-Update Gate ist ein Sicherheitsmechanismus, der die Ausführung pausier
 [^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]: [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
 [^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
 [^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]: [[Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **enables:** [[Content Quality Control]]
 - **mechanism:** [[wikitool]]
 - **see-also:** [[Iteration and Cost Limits]]
 - **exemplifies:** [[Structural Enforcement over Documented Rule]]
 - **contrasts:** [[Bulk Operations]]
 - **see-also:** [[Publish-Remote Gate]]
 - **see-also:** [[MCP-Leseserver]]
 <!-- /wikitool:links -->
@@ -4,7 +4,13 @@ concept_type: architecture
 tags: [memory, lifecycle, confidence, knowledge-management]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, Confidence Scoring, Supersession, Consolidation Tiers, Forgetting, Knowledge Compounding]
+related:
  - part-of: LLM Wiki Pattern
  - see-also: Confidence Scoring
  - composition: Supersession
  - see-also: Consolidation Tiers
  - see-also: Forgetting
  - enables: Knowledge Compounding
 sources: [Source - LLM Wiki v2]
 confidence: 0.95
 confidence_base: 0.95
@@ -109,12 +115,6 @@ Basierend auf [[Agent Memory]]-Erfahrung:
 ## Verwandte Concepts
 - [[Confidence Scoring]] - Der Scoring-Mechanismus
 - [[Supersession]] - Der Versionskontroll-Mechanismus
 - [[Forgetting]] - Der Retention-Curve-Mechanismus
 - [[Consolidation Tiers]] - Die Promotions-Pipeline
 - [[Knowledge Compounding]] - Die Gesamtauswirkung
 - [[LLM Wiki Pattern]] - Das übergeordnete Muster
 - [[Agent Memory]] - Produktionsimplementierung
 ## Siehe auch
@@ -122,3 +122,14 @@ Basierend auf [[Agent Memory]]-Erfahrung:
 - [[Event-Driven Automation]] (Trigger für Lebenszyklus-Management)
 - [[Quality Scoring]] (komplementäre Qualitätsmetriken)
 - [[Knowledge Graph]] (Struktur zur Verfolgung von Beziehungen)
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[LLM Wiki Pattern]]
 - **see-also:** [[Confidence Scoring]]
 - **composition:** [[Supersession]]
 - **see-also:** [[Consolidation Tiers]]
 - **see-also:** [[Forgetting]]
 - **enables:** [[Knowledge Compounding]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Implementation Spectrum, Multi-Agent Collaboration, Source - LLM Wiki v2]
+related:
  - exemplifies: Implementation Spectrum
  - part-of: Multi-Agent Collaboration
  - evidenced-by: Source - LLM Wiki v2
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +41,11 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[Implementation Spectrum]]
 - **part-of:** [[Multi-Agent Collaboration]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: protocol
 tags: [industrial, automation, communication, serial]
 created: 2026-07-25
 modified: 2026-08-29
-related: [E3DC, ha-core, Home Assistant]
+related:
  - see-also: E3DC
  - see-also: ha-core
  - see-also: Home Assistant
 sources: []
 confidence: 0.90
 confidence_base: 0.90
@@ -243,7 +246,6 @@ func main() {
 - [[MQTT]] - Alternatives Protokoll für IoT/Industrie
 - [[OPC UA]] - Modernes Industrieprotokoll mit Sicherheit
 - Industrial-Automation-Konzept
 - [[E3DC]] - Verwendet Modbus zur Kommunikation
 ## Historie
@@ -257,5 +259,11 @@ func main() {
 - [Modbus Organization](https://modbus.org/)
 - [Modbus Specifications](https://modbus.org/specifications/)
- [[E3DC]] - Verwendet Modbus TCP
+
- [[ha-core]] - Kann Modbus verwenden
+<!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[E3DC]]
 - **see-also:** [[ha-core]]
 - **see-also:** [[Home Assistant]]
 <!-- /wikitool:links -->
@@ -4,7 +4,12 @@ concept_type: workflow
 tags: [multi-agent, collaboration, sync, coordination]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, Memory Lifecycle, Mesh Sync, Shared vs Private, Work Coordination]
+related:
  - exemplifies: LLM Wiki Pattern
  - see-also: Memory Lifecycle
  - composition: Mesh Sync
  - composition: Shared vs Private
  - composition: Work Coordination
 sources: [Source - LLM Wiki v2]
 confidence: 0.85
 confidence_base: 0.85
@@ -116,10 +121,6 @@ Basierend auf [[Agent Memory]]-Erfahrung:
 ## Verwandte Concepts
 - [[LLM Wiki Pattern]] - Gesamtmuster
 - [[Mesh Sync]] - Der Synchronisationsmechanismus
 - [[Shared vs Private]] - Der Scoping-Mechanismus
 - [[Work Coordination]] - Der Koordinationsmechanismus
 - [[Event-Driven Automation]] - Für Sync-Trigger
 - [[Audit Trail]] - Zur Verfolgung von Multi-Agent-Operationen
@@ -127,3 +128,13 @@ Basierend auf [[Agent Memory]]-Erfahrung:
 - [[Privacy and Governance]] (für Zugriffskontrolle)
 - [[Quality and Self-Correction]] (zur Aufrechterhaltung der Qualität in kollaborativen Einstellungen)
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **see-also:** [[Memory Lifecycle]]
 - **composition:** [[Mesh Sync]]
 - **composition:** [[Shared vs Private]]
 - **composition:** [[Work Coordination]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: problem
 tags: [bug, drifts, kebab-case, human-readable]
 created: 2026-08-03
 modified: 2026-08-29
-related: [AGENTS.md]
+related:
  - operates-on: AGENTS.md
 sources: [Source - LLM Improvements Codex Analysis]
 confidence: 0.80
 confidence_base: 0.80
@@ -45,19 +46,21 @@ Naming Convention Conflict ist ein spezifischer Drift/Bug, bei dem README.md und
 ## Verwandte Concepts
 - [[AGENTS.md]] (gibt benutzerfreundliche Titel mit Leerzeichen an)
 - README.md (gibt kebab-case an)
 - [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
 ## Beziehungen
 - **beeinflusst:** [[AGENTS.md]]
 ## Siehe auch
 - [[Source - LLM Improvements Codex Analysis]]
 - [[AGENTS.md]]
 ## Fußnoten
 [^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **operates-on:** [[AGENTS.md]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: architecture
 tags: [interoperability, export, validate, okf-profile]
 created: 2026-08-03
 modified: 2026-08-29
-related: [awesome-llm-wiki]
+related:
  - see-also: awesome-llm-wiki
 sources: [Source - LLM Improvements Codex Analysis]
 confidence: 0.80
 confidence_base: 0.80
@@ -45,19 +46,21 @@ OKF (Open Knowledge Framework) Compatibility ist das Konzept, einen Export-/Vali
 ## Verwandte Concepts
 - [[awesome-llm-wiki]] (OKF ist ein großes Thema in diesem Repository)
 - [[Three-Layer Architecture]] (OKF-Export würde eine zusätzliche Ebene oder einen Modus darstellen)
 - [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
 ## Beziehungen
 - **vorgestellt in:** [[awesome-llm-wiki]]
 ## Siehe auch
 - [[Source - LLM Improvements Codex Analysis]]
 - [[awesome-llm-wiki]]
 ## Fußnoten
 [^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[awesome-llm-wiki]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: architecture
 tags: []
 created: 2026-08-31
 modified: 2026-08-31
-related: [ENVIRONMENT.md, Personalization Plane, wikitool, Chemenu]
+related:
  - mechanism: ENVIRONMENT.md
  - contrasts: Personalization Plane
  - mechanism: wikitool
  - operates-on: Chemenu
 sources: [Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
 confidence: 0.50
 confidence_base: 0.50
@@ -92,25 +96,23 @@ in das Repo aller anderen.
 ## Verwandte Concepts
 - [[Personalization Plane]] — dasselbe Muster als Pflicht: dort `FAIL` bei fehlender Datei, hier
  nie
 - [[KB Stack Versioning]] — das Muster kam mit `1.8.0`, ohne Kompatibilitätsbruch
 ## Beziehungen
 - **umgesetzt von:** [[wikitool]]
 - **verwendet von:** [[Chemenu]]
 - **umgesetzt von:** [[ENVIRONMENT.md]]
 - **verwandt mit:** [[Personalization Plane]]
 ## Siehe auch
 - [[ENVIRONMENT.md]]
 - [[Personalization Plane]]
 - [[wikitool]]
 - [[Chemenu]]
 - [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
 ## Fußnoten
 [^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]: [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **mechanism:** [[ENVIRONMENT.md]]
 - **contrasts:** [[Personalization Plane]]
 - **mechanism:** [[wikitool]]
 - **operates-on:** [[Chemenu]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: architecture
 tags: []
 created: 2026-08-31
 modified: 2026-08-31
-related: [wikitool, Chemenu, Optional Instance Context File]
+related:
  - mechanism: wikitool
  - operates-on: Chemenu
  - see-also: Optional Instance Context File
 sources: [Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
 confidence: 0.50
 confidence_base: 0.50
@@ -85,23 +88,24 @@ sondern in den Health-Check.
 ## Verwandte Concepts
 - [[KB Migration]] - Abgrenzung: dort Korpus-Form, hier Instanz-Zustand
- [[Optional Instance Context File]] - dasselbe Muster ohne Pflicht: dort meldet der
+- Optional Instance Context File - dasselbe Muster ohne Pflicht: dort meldet der
  Health-Check nur, hier scheitert er[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]
 - [[KB Stack Versioning]] - die Plane kam mit `1.1.0`, ohne Kompatibilitätsbruch
 ## Beziehungen
 - **umgesetzt von:** [[wikitool]]
 - **verwendet von:** [[Chemenu]]
 - **verwandt mit:** [[Optional Instance Context File]]
 ## Siehe auch
 - [[wikitool]]
 - [[Chemenu]]
 - [[Optional Instance Context File]]
 - [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
 ## Fußnoten
 [^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]: [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **mechanism:** [[wikitool]]
 - **operates-on:** [[Chemenu]]
 - **see-also:** [[Optional Instance Context File]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: workflow
 tags: [privacy, security, governance, audit]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, Filter on Ingest, Audit Trail, Bulk Operations]
+related:
  - exemplifies: LLM Wiki Pattern
  - see-also: Filter on Ingest
  - see-also: Audit Trail
  - see-also: Bulk Operations
 sources: [Source - LLM Wiki v2]
 confidence: 0.90
 confidence_base: 0.90
@@ -132,10 +136,6 @@ Basierend auf [[Agent Memory]] und Produktionserfahrung:
 ## Verwandte Concepts
 - [[LLM Wiki Pattern]] - Gesamtmuster
 - [[Filter on Ingest]] - Der Filtermechanismus
 - [[Audit Trail]] - Der Protokollierungsmechanismus
 - [[Bulk Operations]] - Gouvernanzoperationen
 - [[Event-Driven Automation]] - Für automatisierte Governance
 ## Siehe auch
@@ -143,3 +143,12 @@ Basierend auf [[Agent Memory]] und Produktionserfahrung:
 - [[Privacy and Governance]] (diese Seite)
 - [[Multi-Agent Collaboration]] (für Multi-Agent-Sicherheit)
 - [[Quality and Self-Correction]] (für Qualitätsaspekte)
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **see-also:** [[Filter on Ingest]]
 - **see-also:** [[Audit Trail]]
 - **see-also:** [[Bulk Operations]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: architecture
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Consolidation Tiers]
+related:
  - part-of: Consolidation Tiers
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +39,9 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Consolidation Tiers]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: workflow
 tags: []
 created: 2026-09-01
 modified: 2026-09-02
-related: [Mass-Update Gate, Chemenu, MCP-Leseserver]
+related:
  - see-also: Mass-Update Gate
  - operates-on: Chemenu
  - see-also: MCP-Leseserver
 sources: [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]
 confidence: 0.70
 confidence_base: 0.70
@@ -91,26 +94,22 @@ getestetes Skript und zwei Architekturvorschläge (das Verfahren als `wikitool`-
 oder den Demo-Korpus grundsätzlich von dem Branch fernhalten, von dem private Instanzen ihre
 Maschinerie ziehen) stehen in Gitea-Issue #30.
 ## Verwandte Concepts
 - [[Mass-Update Gate]]
 - [[MCP-Leseserver]]
 ## Beziehungen
 - **gilt fuer:** [[Chemenu]]
 - **verwandtes Gate:** [[Mass-Update Gate]]
 - **verwandt mit:** [[MCP-Leseserver]]
 ## Siehe auch
 - [[Source - Publish-Remote Gate and Issue Triage Session 2026-09-01]]
 - [[Chemenu]]
 - [[Mass-Update Gate]]
 - [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]
 - [[MCP-Leseserver]]
 ## Fußnoten
 [^s-private-instance-merge-correction-and-issue-30-session-2026-09-01]: [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]
 [^s-mcp-read-server-implementation-session-2026-09-02]: [[Source - MCP Read Server Implementation Session 2026-09-02]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Mass-Update Gate]]
 - **operates-on:** [[Chemenu]]
 - **see-also:** [[MCP-Leseserver]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Confidence Scoring, Implementation Spectrum, Memory Lifecycle, Source - LLM Wiki v2]
+related:
  - see-also: Confidence Scoring
  - exemplifies: Implementation Spectrum
  - see-also: Memory Lifecycle
  - evidenced-by: Source - LLM Wiki v2
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +42,12 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Confidence Scoring]]
 - **exemplifies:** [[Implementation Spectrum]]
 - **see-also:** [[Memory Lifecycle]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: workflow
 tags: [quality, scoring, self-healing, contradiction, knowledge-management]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, Memory Lifecycle, Event-Driven Automation, Confidence Scoring]
+related:
  - exemplifies: LLM Wiki Pattern
  - see-also: Memory Lifecycle
  - rests-on: Event-Driven Automation
  - rests-on: Confidence Scoring
 sources: [Source - LLM Wiki v2]
 confidence: 0.90
 confidence_base: 0.90
@@ -111,10 +115,6 @@ Basierend auf [[Agent Memory]] und [[Event-Driven Automation]]:
 ## Verwandte Concepts
 - [[LLM Wiki Pattern]] - Gesamtmuster
 - [[Memory Lifecycle]] - Ergänzende Knowledge Management
 - [[Confidence Scoring]] - Für Aussage-Level-Konfidenz
 - [[Event-Driven Automation]] - Für Auslösen von Qualitätsprüfungen
 - [[Lint Workflow]] - Die Gesundheitsprüfungsoperation
 - [[Agent Memory]] - Produktionsimplementierung
@@ -125,3 +125,11 @@ Basierend auf [[Agent Memory]] und [[Event-Driven Automation]]:
 - [[Self-Healing]] (der automatische Reparaturmechanismus)
 - [[Contradiction Resolution]] (der Entscheidungsprozess)
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **see-also:** [[Memory Lifecycle]]
 - **rests-on:** [[Event-Driven Automation]]
 - **rests-on:** [[Confidence Scoring]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: architecture
 tags: [ai, retrieval, generation, knowledge-management]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, NotebookLM, ChatGPT]
+related:
  - see-also: LLM Wiki Pattern
  - see-also: NotebookLM
  - see-also: ChatGPT
 sources: [Source - LLM Wiki Pattern]
 confidence: 0.90
 confidence_base: 0.90
@@ -107,7 +110,12 @@ Das [[LLM Wiki Pattern]] kann als eine Verbesserung zu RAG angesehen werden, die
 ## Siehe auch
 - [[LLM Wiki Pattern]]
 - [[Knowledge Compounding]]
- [[NotebookLM]]
+
- [[ChatGPT]]
+<!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[LLM Wiki Pattern]]
 - **see-also:** [[NotebookLM]]
 - **see-also:** [[ChatGPT]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Hybrid Search, LLM Wiki Pattern, Source - LLM Wiki v2]
+related:
  - part-of: Hybrid Search
  - exemplifies: LLM Wiki Pattern
  - evidenced-by: Source - LLM Wiki v2
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +41,11 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Hybrid Search]]
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -4,7 +4,9 @@ concept_type: protocol
 tags: [storage, ssd, performance, optimization, linux]
 created: 2026-07-31
 modified: 2026-08-29
-related: [Disk Encryption, LVM, Arch Linux]
+related:
  - see-also: LVM
  - see-also: Arch Linux
 sources: [Source - Arch Linux Cheat Sheet]
 confidence: 0.90
 confidence_base: 0.90
@@ -175,16 +177,18 @@ lsblk -o NAME,FSTYPE,DISC-GRAN,DISC-MAX
 ## Beziehungen
- **Verwendet mit:** [[Disk Encryption]] (dm-crypt/LUKS)
+(dm-crypt/LUKS)
 - **Ergänzt:** [[LVM]] (Logical Volume Manager)
 - **Läuft auf:** [[Arch Linux]] und anderen Distributionen
 - **Wirkt sich aus auf:** Speicherleistung SSD-gestützter Systeme
 ## Siehe auch
 - [[Disk Encryption]]
 - [[LVM]]
 - [[Arch Linux]]
 - [[Source - Arch Linux Cheat Sheet]]
 - https://wiki.archlinux.org/title/Solid_State_Drives
 - https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[LVM]]
 - **see-also:** [[Arch Linux]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: architecture
 tags: [scale, limitations]
 created: 2026-08-04
 modified: 2026-09-01
-related: []
+related:
  - see-also: Token Economics
  - see-also: Cross-platform Agent Skills
  - see-also: Context Isolation
 sources: [Source - Copilot Skill Restructure Instructions]
 confidence: 0.80
 confidence_base: 0.80
@@ -46,12 +49,14 @@ Scale Ceiling ist kein Problem wenn:
 - Retrieval-Augmented-Ansätze genutzt werden, die alles in den Kontext laden vermeiden
 - Die Workflows kein Verständnis von Verbindungen über das gesamte Wiki erfordern
 ## Verwandte Concepts
 - [[Token Economics]]
 - [[Cross-platform Agent Skills]]
 - [[Context Isolation]]
 ## Fußnoten
 [^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Token Economics]]
 - **see-also:** [[Cross-platform Agent Skills]]
 - **see-also:** [[Context Isolation]]
 <!-- /wikitool:links -->
@@ -4,7 +4,13 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Confidence Scoring, Quality and Self-Correction, Source - LLM Wiki v2, Supersession, Detect-Repair Asymmetry, Command Round-Trip Integrity]
+related:
  - see-also: Confidence Scoring
  - part-of: Quality and Self-Correction
  - evidenced-by: Source - LLM Wiki v2
  - see-also: Supersession
  - see-also: Detect-Repair Asymmetry
  - see-also: Command Round-Trip Integrity
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -41,11 +47,15 @@ TODO
 ## Beziehungen
 - **abgegrenzt gegen:** [[Detect-Repair Asymmetry]]
 - **folgt aus:** [[Command Round-Trip Integrity]]
 ## Siehe auch
- [[Detect-Repair Asymmetry]]
+<!-- wikitool:links -->
- [[Command Round-Trip Integrity]]
+## Beziehungen
 - **see-also:** [[Confidence Scoring]]
 - **part-of:** [[Quality and Self-Correction]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 - **see-also:** [[Supersession]]
 - **see-also:** [[Detect-Repair Asymmetry]]
 - **see-also:** [[Command Round-Trip Integrity]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: workflow
 tags: [heuristics, stale-claims, change-density, weak-linking]
 created: 2026-08-03
 modified: 2026-08-29
-related: [wikitool]
+related:
  - mechanism: wikitool
 sources: [Source - LLM Improvements Codex Analysis, Source - LLM Improvements Sonnet Analysis]
 confidence: 0.80
 confidence_base: 0.80
@@ -55,20 +56,22 @@ Semantic Lint Automation bezieht sich auf Maschinen-Heuristiken, die potenzielle
 - [[Lint Workflow]] (vorhandenes Konzept für strukturelles Linting)
 - [[Confidence Scoring]] (wird verwendet, um Aussagen mit niedrigem Vertrauen zu identifizieren)
 - [[wikitool]] (implementiert strukturelles Linting, könnte semantische Heuristiken hinzufügen)
 - [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
 ## Beziehungen
 - **implementiert von:** [[wikitool]]
 ## Siehe auch
 - [[Source - LLM Improvements Codex Analysis]]
 - [[wikitool]]
 - [[Source - LLM Improvements Sonnet Analysis]]
 ## Fußnoten
 [^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
 [^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **mechanism:** [[wikitool]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: architecture
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Consolidation Tiers]
+related:
  - part-of: Consolidation Tiers
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +39,9 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Consolidation Tiers]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: workflow
 tags: [preflight, context, query, update]
 created: 2026-08-03
 modified: 2026-08-29
-related: [wikitool]
+related:
  - mechanism: wikitool
 sources: [Source - LLM Improvements Codex Analysis, Source - LLM Improvements Sonnet Analysis]
 confidence: 0.80
 confidence_base: 0.80
@@ -55,15 +56,18 @@ Session Orientation ist eine obligatorische Preflight-Prüfung, die einen Kontex
 ## Beziehungen
 - **würde implementiert von:** [[wikitool]]
 ## Siehe auch
 - [[Source - LLM Improvements Codex Analysis]]
 - [[wikitool]]
 - [[Source - LLM Improvements Sonnet Analysis]]
 ## Fußnoten
 [^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
 [^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **mechanism:** [[wikitool]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Multi-Agent Collaboration]
+related:
  - part-of: Multi-Agent Collaboration
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +39,9 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Multi-Agent Collaboration]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: workflow
 tags: [page-management, refactoring, link-correction, frontmatter]
 created: 2026-08-03
 modified: 2026-08-29
-related: [wikitool]
+related:
  - mechanism: wikitool
 sources: [Source - LLM Improvements Codex Analysis]
 confidence: 0.80
 confidence_base: 0.80
@@ -46,20 +47,22 @@ Split Merge Reclassify bezieht sich auf dedizierte Befehle für strukturelle Sei
 ## Verwandte Concepts
 - [[wikitool]] (Werkzeug, das diese Befehle implementieren würde)
 - [[Bulk Operations]] (vorhandenes Concept für geprüfte Massenvorgänge)
 - [[Entity Extraction]] (bezüglich Umklassifizierungsentscheidungen)
 - [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
 ## Beziehungen
 - **würde implementiert durch:** [[wikitool]]
 ## Siehe auch
 - [[Source - LLM Improvements Codex Analysis]]
 - [[wikitool]]
 ## Fußnoten
 [^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **mechanism:** [[wikitool]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: workflow
 tags: [split, threshold, lines, pages]
 created: 2026-08-03
 modified: 2026-08-29
-related: [Content Quality Control, Stub Threshold, Index Scaling]
+related:
  - part-of: Content Quality Control
  - see-also: Stub Threshold
  - see-also: Index Scaling
 sources: [Source - LLM Improvements Sonnet Analysis]
 confidence: 0.80
 confidence_base: 0.80
@@ -53,9 +56,6 @@ Split Threshold definiert die maximale Größe, die eine Wiki-Seite erreichen so
 ## Verwandte Concepts
 - [[Content Quality Control]] - Breiteres Framework
 - [[Stub Threshold]] - Mindestgröße-Ergänzung
 - [[Index Scaling]] - Verwandte Skalierung für Index-Seiten
 - [[Anti-Cramming Heuristic]] - Regel für wann neue Seiten zu erstellen sind
 ## Siehe auch
@@ -65,3 +65,11 @@ Split Threshold definiert die maximale Größe, die eine Wiki-Seite erreichen so
 ## Fußnoten
 [^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Content Quality Control]]
 - **see-also:** [[Stub Threshold]]
 - **see-also:** [[Index Scaling]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: decision
 tags: [quality, tooling, tests, governance]
 created: 2026-08-31
 modified: 2026-08-31
-related: [Ambient Environment Dependency, wikitool, Iteration and Cost Limits, Mass-Update Gate]
+related:
  - see-also: Ambient Environment Dependency
  - mechanism: wikitool
  - see-also: Iteration and Cost Limits
  - see-also: Mass-Update Gate
 sources: [Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]
 confidence: 0.50
 confidence_base: 0.50
@@ -92,26 +96,23 @@ Dokumentation erklärt die Regel und ihre Ausnahmen; sie trägt aber nicht die D
 ## Verwandte Concepts
 - [[Ambient Environment Dependency]]
 - [[Iteration and Cost Limits]]
 - [[Mass-Update Gate]]
 - [[Green Suite Blind Spot]]
 ## Beziehungen
 - **Gegenmittel zu:** [[Ambient Environment Dependency]]
 - **angewandt in:** [[Iteration and Cost Limits]]
 - **angewandt in:** [[Mass-Update Gate]]
 - **umgesetzt in:** [[wikitool]]
 ## Siehe auch
 - [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
 - [[Ambient Environment Dependency]]
 - [[wikitool]]
 - [[Iteration and Cost Limits]]
 - [[Mass-Update Gate]]
 ## Fußnoten
 [^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]: [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Ambient Environment Dependency]]
 - **mechanism:** [[wikitool]]
 - **see-also:** [[Iteration and Cost Limits]]
 - **see-also:** [[Mass-Update Gate]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: workflow
 tags: [stub, minimum, quality, lines]
 created: 2026-08-03
 modified: 2026-08-29
-related: [Content Quality Control, Split Threshold, Semantic Lint Automation]
+related:
  - part-of: Content Quality Control
  - see-also: Split Threshold
  - see-also: Semantic Lint Automation
 sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Wiki v2]
 confidence: 0.80
 confidence_base: 0.80
@@ -64,12 +67,6 @@ It provides comprehensive information about the topic. It clearly exceeds the st
 - Für Seiten, die absichtlich minimal sind (z. B. Redirect-Seiten)
 - Wenn der Inhalt natürlicherweise kurz aber vollständig ist
 ## Verwandte Concepts
 - [[Content Quality Control]] - Das breitere Framework, das Stub-Schwellenwerte enthält
 - [[Split Threshold]] - Die obere Grenze-Ergänzung zu Stub-Schwellenwert
 - [[Semantic Lint Automation]] - Könnte Stub-Erkennung einbinden
 ## Siehe auch
 - [[Source - LLM Improvements Sonnet Analysis]]
@@ -79,3 +76,11 @@ It provides comprehensive information about the topic. It clearly exceeds the st
 [^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
 [^s-llm-wiki-v2]: [[Source - LLM Wiki v2]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Content Quality Control]]
 - **see-also:** [[Split Threshold]]
 - **see-also:** [[Semantic Lint Automation]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: workflow
 tags: [versioning, knowledge, updates, lifecycle]
 created: 2026-07-26
 modified: 2026-08-29
-related: [Memory Lifecycle, Confidence Scoring, Knowledge Graph, LLM Wiki Pattern]
+related:
  - part-of: Memory Lifecycle
  - rests-on: Confidence Scoring
  - see-also: Knowledge Graph
  - exemplifies: LLM Wiki Pattern
 sources: [Source - LLM Wiki v2]
 confidence: 0.95
 confidence_base: 0.95
@@ -122,11 +126,7 @@ Wenn Aussage B Aussage A ersetzt:
 ## Verwandte Concepts
 - [[Memory Lifecycle]] - Übergeordnetes Concept
 - [[Confidence Scoring]] - Bestimmt welche Aussage in Widerspruch gewinnt
 - [[Contradiction Resolution]] - Der Entscheidungsprozess für Supersession
 - [[Knowledge Graph]] - Struktur zur Verfolgung von Supersession-Beziehungen
 - [[LLM Wiki Pattern]] - Gesamtes Pattern
 ## Siehe auch
@@ -134,3 +134,12 @@ Wenn Aussage B Aussage A ersetzt:
 - [[Forgetting]] (komplementärer Mechanismus)
 - [[Self-Healing]] (für automatisierte Supersession-Erkennung)
 - [[Audit Trail]] (zum Nachverfolgen von Supersession-Historie)
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Memory Lifecycle]]
 - **rests-on:** [[Confidence Scoring]]
 - **see-also:** [[Knowledge Graph]]
 - **exemplifies:** [[LLM Wiki Pattern]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: architecture
 tags: [llm-wiki, layers, structure]
 created: 2026-07-26
 modified: 2026-08-29
-related: [LLM Wiki Pattern, RAG, Memory Lifecycle, Knowledge Graph]
+related:
  - see-also: LLM Wiki Pattern
  - contrasts: RAG
  - composition: Memory Lifecycle
  - composition: Knowledge Graph
 sources: [Source - LLM Wiki Pattern, Source - LLM Wiki v2]
 confidence: 0.95
 confidence_base: 0.95
@@ -256,11 +260,15 @@ Die Three-Layer Architecture bleibt gültig und ausreichend für viele Anwendung
 ## Siehe auch
 - [[LLM Wiki Pattern]]
 - AGENTS.md
 - [[RAG]]
 - [[Knowledge Compounding]]
 - [[Memory Lifecycle]]
 - [[Knowledge Graph]]
 - [[Implementation Spectrum]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[LLM Wiki Pattern]]
 - **contrasts:** [[RAG]]
 - **composition:** [[Memory Lifecycle]]
 - **composition:** [[Knowledge Graph]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: architecture
 tags: [tokens, cost, efficiency]
 created: 2026-08-04
 modified: 2026-09-01
-related: []
+related:
  - see-also: Cross-platform Agent Skills
  - see-also: Scale Ceiling
  - see-also: Context Isolation
 sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
 confidence: 0.60
 confidence_base: 0.60
@@ -50,12 +53,6 @@ Token Economics ist weniger entscheidend, wenn:
 - Die Workflows inhärent gekoppelt sind und nicht getrennt werden können
 - Der Entwicklungsaufwand der Kontextoptimierung die Vorteile übersteigt
 ## Verwandte Concepts
 - [[Cross-platform Agent Skills]]
 - [[Scale Ceiling]]
 - [[Context Isolation]]
 ## Siehe auch
 - [[Source - Copilot Skill Restructure Instructions]]
@@ -65,3 +62,11 @@ Token Economics ist weniger entscheidend, wenn:
 [^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
 [^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Cross-platform Agent Skills]]
 - **see-also:** [[Scale Ceiling]]
 - **see-also:** [[Context Isolation]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Implementation Spectrum, Knowledge Graph, Source - LLM Wiki v2]
+related:
  - exemplifies: Implementation Spectrum
  - part-of: Knowledge Graph
  - evidenced-by: Source - LLM Wiki v2
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +41,11 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[Implementation Spectrum]]
 - **part-of:** [[Knowledge Graph]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -4,7 +4,11 @@ concept_type: workflow
 tags: [linux, administration, security, users, groups]
 created: 2026-07-31
 modified: 2026-08-29
-related: [Arch Linux, AUR, Aura, makepkg]
+related:
  - see-also: Arch Linux
  - see-also: AUR
  - see-also: Aura
  - see-also: makepkg
 sources: [Source - Arch Linux Cheat Sheet]
 confidence: 0.95
 confidence_base: 0.95
@@ -323,17 +327,17 @@ sudo -u username test -r /path/to/file
 ## Beziehungen
 - **Verwendet in:** [[Arch Linux]]-Paketentwicklung (Non-Root-Builder-Benutzer)
 - **Verwendet von:** [[AUR]] und [[Aura]] für Paketverwaltung
 - **Verwendet mit:** [[makepkg]] in CI/CD-Workflows
 und andere Systeme
 ## Siehe auch
 - [[Arch Linux]]
 - [[AUR]]
 - [[Aura]]
 - [[makepkg]]
 - [[Source - Arch Linux Cheat Sheet]]
 - https://wiki.archlinux.org/title/Users_and_groups
 - https://www.thegeekdiary.com/unix-linux-how-to-lock-or-disable-an-user-account/
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Arch Linux]]
 - **see-also:** [[AUR]]
 - **see-also:** [[Aura]]
 - **see-also:** [[makepkg]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Hybrid Search, LLM Wiki Pattern, Source - LLM Wiki v2]
+related:
  - part-of: Hybrid Search
  - exemplifies: LLM Wiki Pattern
  - evidenced-by: Source - LLM Wiki v2
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +41,11 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Hybrid Search]]
 - **exemplifies:** [[LLM Wiki Pattern]]
 - **evidenced-by:** [[Source - LLM Wiki v2]]
 <!-- /wikitool:links -->
@@ -4,7 +4,9 @@ concept_type: pattern
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Implementation Spectrum, Multi-Agent Collaboration]
+related:
  - exemplifies: Implementation Spectrum
  - part-of: Multi-Agent Collaboration
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +40,10 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[Implementation Spectrum]]
 - **part-of:** [[Multi-Agent Collaboration]]
 <!-- /wikitool:links -->
@@ -4,7 +4,10 @@ concept_type: workflow
 tags: [workflow, extraction, refactoring]
 created: 2026-08-04
 modified: 2026-09-01
-related: []
+related:
  - see-also: Cross-platform Agent Skills
  - see-also: Context Isolation
  - see-also: Token Economics
 sources: [Source - Copilot Skill Restructure Instructions]
 confidence: 0.80
 confidence_base: 0.80
@@ -47,12 +50,14 @@ Workflow-Extraktion vermeiden, wenn:
 - Der Overhead der Verwaltung separater Skill-Dateien die Vorteile übersteigt
 - Keine klaren Grenzen zwischen verschiedenen Workflows vorhanden sind
 ## Verwandte Concepts
 - [[Cross-platform Agent Skills]]
 - [[Context Isolation]]
 - [[Token Economics]]
 ## Fußnoten
 [^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **see-also:** [[Cross-platform Agent Skills]]
 - **see-also:** [[Context Isolation]]
 - **see-also:** [[Token Economics]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: workflow
 tags: [automation, end-to-end, ingest, lint, update]
 created: 2026-08-03
 modified: 2026-08-29
-related: [wikitool]
+related:
  - mechanism: wikitool
 sources: [Source - LLM Improvements Codex Analysis]
 confidence: 0.80
 confidence_base: 0.80
@@ -46,20 +47,22 @@ Workflow-Orchestrierung ist das Konzept der Bereitstellung einzelner, orchestrie
 ## Verwandte Concepts
 - [[AGENTS.md]] (definiert die Workflows, die orchestriert werden könnten)
 - [[wikitool]] (das Tool, das die Orchestrierung implementieren würde)
 (sollte mit orchestrierten Workflows integriert werden)
 - [[Session Orientation]] (Preflight-Kontext für orchestrierte Operationen)
 - [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
 ## Beziehungen
 - **implementiert durch:** [[wikitool]]
 ## Siehe auch
 - [[Source - LLM Improvements Codex Analysis]]
 - [[wikitool]]
 ## Fußnoten
 [^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **mechanism:** [[wikitool]]
 <!-- /wikitool:links -->
@@ -4,7 +4,8 @@ concept_type: architecture
 tags: []
 created: 2026-08-02
 modified: 2026-08-29
-related: [Consolidation Tiers]
+related:
  - part-of: Consolidation Tiers
 sources: []
 confidence: 0.50
 confidence_base: 0.50
@@ -38,3 +39,9 @@ TODO
 ## Verwandte Concepts
 - TODO
 <!-- wikitool:links -->
 ## Beziehungen
 - **part-of:** [[Consolidation Tiers]]
 <!-- /wikitool:links -->
@@ -4,7 +4,12 @@ concept_type: problem
 tags: [wikitool, frontmatter, tooling, idempotenz, repair]
 created: 2026-08-31
 modified: 2026-08-31
-related: [wikitool, Denylist over Allowlist, Detect-Repair Asymmetry, Diff-Reviewable Agent Edits, Command Round-Trip Integrity]
+related:
  - exemplifies: wikitool
  - see-also: Denylist over Allowlist
  - see-also: Detect-Repair Asymmetry
  - see-also: Diff-Reviewable Agent Edits
  - see-also: Command Round-Trip Integrity
 sources: [Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31, Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]
 confidence: 0.70
 confidence_base: 0.70
@@ -95,30 +100,24 @@ breit[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-0
 - Für generierte Dateien. Dass `kb/index.md` nicht von Hand geschrieben wird, ist Invariante 1
  und kein Defekt.
 ## Verwandte Concepts
 - [[Detect-Repair Asymmetry]]
 - [[Denylist over Allowlist]]
 ## Beziehungen
 - **trat auf in:** [[wikitool]]
 - **gelöst mit:** [[Denylist over Allowlist]]
 - **abgegrenzt gegen:** [[Detect-Repair Asymmetry]]
 - **belegt durch:** [[Diff-Reviewable Agent Edits]]
 - **abgegrenzt gegen:** [[Command Round-Trip Integrity]]
 ## Siehe auch
 - [[wikitool]]
 - [[Denylist over Allowlist]]
 - [[Detect-Repair Asymmetry]]
 - [[Diff-Reviewable Agent Edits]]
 - [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
 - [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
 - [[Command Round-Trip Integrity]]
 ## Fußnoten
 [^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]: [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
 [^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
 <!-- wikitool:links -->
 ## Beziehungen
 - **exemplifies:** [[wikitool]]
 - **see-also:** [[Denylist over Allowlist]]
 - **see-also:** [[Detect-Repair Asymmetry]]
 - **see-also:** [[Diff-Reviewable Agent Edits]]
 - **see-also:** [[Command Round-Trip Integrity]]
 <!-- /wikitool:links -->
@@ -1,5 +1,10 @@
 ---
 profile: entities
 outbound:
  entities: [depends-on, required-by, runs-on, hosts, uses, produces, consumes, maintains, owns, part-of, composition, supersedes, see-also]
  concepts: [implements, exemplifies, rests-on, applies-when, operates-on, invokes, see-also]
  sources: [evidenced-by, defined-in, see-also]
  comparisons: [compares-with, see-also]
 required_by_stack: false
 ---
@@ -43,6 +48,17 @@ These are areas, not collections: they inherit this contract and carry no `COLLE
 - **People** - role, affiliation, and the projects or decisions they are connected to. Nothing
  personal beyond what the source states.
 ## Authorised labels
 The `outbound:` block above is what `wikitool lint` and `xref add` check: which labels a page in
 this collection may use, per destination. The catalogue they are drawn from - and what each one
 asserts - is [instructions/link-taxonomy.md](../../instructions/link-taxonomy.md), which binds
 nothing on its own.
 Operational labels dominate here because an entity's relationships are mostly to other concrete things. `implements` points *out* to a concept; the concept does not point back unless that direction is a statement of its own.
 Adding a label here is a deliberate contract change, not a way around a refusal.
 ## Outbound linking
 An entity links to the technologies it uses, the systems it runs on, the projects that depend
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
torben	23307c3c5f	fix: Testisolation - kb_dir repointet config.ROOT, lint loest Kollektionen gegen den uebergebenen Baum auf (4.1.1, #44 ) CI / verify (push) Successful in 55s Details Release / release (push) Successful in 38s Details Files changed: - CHANGES.md - VERSION - instructions/dev/testing-conventions.md - tools/chemenu/lint_core.py - tools/chemenu/tests/conftest.py - tools/chemenu/tests/test_hermetic_env.py - tools/chemenu/tests/test_lint.py	2026-09-03 06:33:38 +02:00
torben	cfe925a76c	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 ) CI / verify (push) Successful in 53s Details Release / release (push) Successful in 36s Details 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	2026-09-03 06:19:56 +02:00
torben	23e34a940c	feat(kb): Issue Label Scheme auf Vierachsen-Schema und Body-als-Wahrheit nachgezogen (#41 ) Files changed: - kb/concepts/INDEX.md - kb/concepts/Issue Label Scheme.md - kb/entities/projects/Chemenu.md - kb/entities/tools/Gitea MCP Server.md - kb/index.md - kb/log.md - kb/provenance.md - kb/sources/INDEX.md - kb/sources/Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md - raw/notes/Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02.md	2026-09-02 23:20:39 +02:00
torben	c8c238523a	feat: Issue-Board auf vier Pflicht-Label-Familien und Body-als-Wahrheit (#41 ) CI / verify (push) Successful in 53s Details Release / release (push) Successful in 39s Details Files changed: - CHANGES.md - VERSION - instructions/dev/issue-tracking.md - instructions/dev/stack-dev/SKILL.md	2026-09-02 23:11:48 +02:00
torben	3f99d6715f	feat: Link-Taxonomie u5 - Restkanten gelabelt, migrate done 4.0.0, Workshop geschlossen CI / verify (push) Successful in 51s Details Files changed: - .wikitool-kb.json - kb/entities/technologies/Arch Linux.md - kb/entities/technologies/Disk Encryption.md - kb/entities/technologies/Wine-Staging.md - kb/entities/tools/AUR.md - kb/entities/tools/GPG.md - kb/entities/tools/Lutris.md - kb/entities/tools/NotebookLM.md - kb/entities/tools/Obsidian.md - kb/entities/tools/OpenAI Codex.md - kb/entities/tools/OpenCode.md - kb/entities/tools/Pi.md - kb/entities/tools/Proton.md - kb/entities/tools/Steam.md - kb/entities/tools/Wine.md - kb/entities/tools/gdeploy.md - kb/entities/tools/makepkg.md - kb/entities/tools/pascalandy schema.md - kb/log.md - work/link-taxonomy-migration/README.md - work/link-taxonomy-migration/glossary.md - work/link-taxonomy-migration/plan.md	2026-09-02 23:06:08 +02:00
torben	807094deae	update: u4 (kb/sources) als abgeschlossen dokumentiert - keine Aenderungen noetig Files changed: - work/link-taxonomy-migration/README.md - work/link-taxonomy-migration/glossary.md	2026-09-02 23:00:32 +02:00
torben	8b711f4860	update: u3-Checkliste im link-taxonomy-migration-Workshop abgehakt Files changed: - work/link-taxonomy-migration/README.md	2026-09-02 22:56:23 +02:00
torben	a35c94e2d9	feat: Link-Taxonomie u3 - kb/concepts/ vollstaendig gelabelt Files changed: - kb/concepts/Ambient Environment Dependency.md - kb/concepts/Anti-Cramming Heuristic.md - kb/concepts/Audit Trail.md - kb/concepts/BM25.md - kb/concepts/Bulk Operations.md - kb/concepts/CI Integration.md - kb/concepts/CPPC.md - kb/concepts/Checkpoint Audit.md - kb/concepts/Claude Code Auto Mode.md - kb/concepts/Command Round-Trip Integrity.md - kb/concepts/Confidence Scoring.md - kb/concepts/Consolidation Tiers.md - kb/concepts/Content Quality Control.md - kb/concepts/Context Isolation.md - kb/concepts/Contradiction Resolution.md - kb/concepts/Cross-platform Agent Skills.md - kb/concepts/Crystallization.md - kb/concepts/Delete Rather Than Anonymize.md - kb/concepts/Denylist over Allowlist.md - kb/concepts/Detect-Repair Asymmetry.md - kb/concepts/Diff-Reviewable Agent Edits.md - kb/concepts/Dual Licensing by File Plan.md - kb/concepts/Entity Extraction.md - kb/concepts/Episodic Memory.md - kb/concepts/Event-Driven Automation.md - kb/concepts/Filter on Ingest.md - kb/concepts/Forgetting.md - kb/concepts/Graph Traversal.md - kb/concepts/Green Suite Blind Spot.md - kb/concepts/Hooks.md - kb/concepts/Hybrid Search.md - kb/concepts/Implementation Spectrum.md - kb/concepts/Index Scaling.md - kb/concepts/Issue Label Scheme.md - kb/concepts/Iteration and Cost Limits.md - kb/concepts/KB Migration.md - kb/concepts/KB Stack Versioning.md - kb/concepts/Knowledge Compounding.md - kb/concepts/Knowledge Graph.md - kb/concepts/LLM Wiki Pattern.md - kb/concepts/Lint Workflow.md - kb/concepts/MCP-Leseserver.md - kb/concepts/Mass-Update Gate.md - kb/concepts/Memory Lifecycle.md - kb/concepts/Mesh Sync.md - kb/concepts/Modbus.md - kb/concepts/Multi-Agent Collaboration.md - kb/concepts/Naming Convention Conflict.md - kb/concepts/OKF Compatibility.md - kb/concepts/Optional Instance Context File.md - kb/concepts/Personalization Plane.md - kb/concepts/Privacy and Governance.md - kb/concepts/Procedural Memory.md - kb/concepts/Publish-Remote Gate.md - kb/concepts/Quality Scoring.md - kb/concepts/Quality and Self-Correction.md - kb/concepts/RAG.md - kb/concepts/Reciprocal Rank Fusion.md - kb/concepts/SSD TRIM.md - kb/concepts/Scale Ceiling.md - kb/concepts/Self-Healing.md - kb/concepts/Semantic Lint Automation.md - kb/concepts/Semantic Memory.md - kb/concepts/Session Orientation.md - kb/concepts/Shared vs Private.md - kb/concepts/Split Merge Reclassify.md - kb/concepts/Split Threshold.md - kb/concepts/Structural Enforcement over Documented Rule.md - kb/concepts/Stub Threshold.md - kb/concepts/Supersession.md - kb/concepts/Three-Layer Architecture.md - kb/concepts/Token Economics.md - kb/concepts/Typed Relationships.md - kb/concepts/User Management.md - kb/concepts/Vector Search.md - kb/concepts/Work Coordination.md - kb/concepts/Workflow Extraction.md - kb/concepts/Workflow Orchestration.md - kb/concepts/Working Memory.md - kb/concepts/Write-Once Frontmatter Fields.md - kb/log.md - work/link-taxonomy-migration/glossary.md	2026-09-02 22:56:04 +02:00
torben	9e2f9bf98d	feat: Link-Taxonomie u2 - kb/entities/people, projects, kb/comparisons gelabelt Files changed: - kb/comparisons/amd-pstate vs acpi-cpufreq.md - kb/concepts/RAG.md - kb/entities/people/Andrej Karpathy.md - kb/entities/people/E3DC GmbH.md - kb/entities/people/Rohit Gupta.md - kb/entities/people/Vannevar Bush.md - kb/entities/projects/BCDModule.md - kb/entities/projects/Chemenu.md - kb/entities/projects/andybalholm-edl.md - kb/entities/projects/goresponsiveness.md - kb/entities/projects/ha-core.md - kb/entities/projects/hacs-e3dc.md - kb/entities/projects/hacs-integration-blueprint.md - kb/entities/projects/kfchou/wiki-skills.md - kb/entities/projects/plugnburn-edl.md - kb/entities/projects/vanillaflava/wiki-skills-vanillaflava.md - kb/entities/projects/yugasun/llm-wiki-skills.md - kb/entities/tools/Agent Memory.md - kb/log.md - work/link-taxonomy-migration/README.md - work/link-taxonomy-migration/glossary.md	2026-09-02 19:58:07 +02:00
torben	7e15035001	update: u1-Checkliste im link-taxonomy-migration-Workshop abgehakt Files changed: - work/link-taxonomy-migration/README.md	2026-09-02 19:36:24 +02:00
torben	b137359b90	feat: Link-Taxonomie u1 - kb/entities/systems, tools, technologies gelabelt Files changed: - kb/concepts/Denylist over Allowlist.md - kb/concepts/LLM Wiki Pattern.md - kb/concepts/SSD TRIM.md - kb/entities/people/E3DC GmbH.md - kb/entities/people/Vannevar Bush.md - kb/entities/projects/ha-core.md - kb/entities/projects/hacs-integration-blueprint.md - kb/entities/systems/AGENTS.md.md - kb/entities/systems/CLAUDE.md.md - kb/entities/systems/E3DC.md - kb/entities/systems/ENVIRONMENT.md.md - kb/entities/systems/Memex.md - kb/entities/systems/Tolkien Gateway.md - kb/entities/technologies/Arch Linux.md - kb/entities/technologies/Disk Encryption.md - kb/entities/technologies/Docker.md - kb/entities/technologies/Gitea Actions.md - kb/entities/technologies/Gitea.md - kb/entities/technologies/Go.md - kb/entities/technologies/Home Assistant.md - kb/entities/technologies/Kernel PM Governors.md - kb/entities/technologies/LVM.md - kb/entities/technologies/Linux Kernel.md - kb/entities/technologies/MQTT.md - kb/entities/technologies/OPC UA.md - kb/entities/technologies/Python.md - kb/entities/technologies/Rust.md - kb/entities/technologies/Wine GE.md - kb/entities/technologies/Wine-Staging.md - kb/entities/technologies/acpi-cpufreq.md - kb/entities/technologies/amd-pstate.md - kb/entities/technologies/iii Engine.md - kb/entities/tools/AUR.md - kb/entities/tools/Act Runner.md - kb/entities/tools/Agent Memory.md - kb/entities/tools/Aura.md - kb/entities/tools/Bottles.md - kb/entities/tools/ChatGPT.md - kb/entities/tools/Claude Code.md - kb/entities/tools/Codex CLI.md - kb/entities/tools/Dataview.md - kb/entities/tools/GPG.md - kb/entities/tools/GitHub Copilot.md - kb/entities/tools/Gitea MCP Server.md - kb/entities/tools/Lutris.md - kb/entities/tools/Marp.md - kb/entities/tools/Mistral Vibe.md - kb/entities/tools/NotebookLM.md - kb/entities/tools/Obsidian Web Clipper.md - kb/entities/tools/Obsidian.md - kb/entities/tools/OpenAI Codex.md - kb/entities/tools/OpenCode.md - kb/entities/tools/Pi.md - kb/entities/tools/Proton.md - kb/entities/tools/Wine.md - kb/entities/tools/awesome-llm-wiki.md - kb/entities/tools/farzaa gist.md - kb/entities/tools/gdeploy.md - kb/entities/tools/makepkg.md - kb/entities/tools/pascalandy schema.md - kb/entities/tools/qmd.md - kb/entities/tools/wikitool.md - kb/log.md - work/link-taxonomy-migration/glossary.md	2026-09-02 19:36:04 +02:00
torben	177c7e9ce8	feat: Prosa ist kein Identifier - Link-Taxonomie als Enum, generierte Regionen mit Markern (4.0.0) CI / verify (push) Successful in 55s Details Release / release (push) Successful in 38s Details Files changed: - .gitea/workflows/ci.yml - AGENTS.md - CHANGES.md - VERSION - instructions/CONTRACT.md - instructions/link-taxonomy.md - instructions/migrations/4.0.0-link-taxonomy.md - instructions/setup-instance.md - kb/CONTRACT.md - kb/CONVENTIONS.md - kb/CONVENTIONS.md.template - kb/comparisons/COLLECTION.md - kb/concepts/COLLECTION.md - kb/entities/COLLECTION.md - kb/sources/COLLECTION.md - tools/CONTRACT.md - tools/README.md - tools/chemenu/blocks.py - tools/chemenu/cli.py - tools/chemenu/commands/cite_cmd.py - tools/chemenu/commands/dist_cmd.py - tools/chemenu/commands/docs_verify.py - tools/chemenu/commands/doctor.py - tools/chemenu/commands/links_cmd.py - tools/chemenu/commands/migrate_cmd.py - tools/chemenu/commands/new_page.py - tools/chemenu/commands/page_ops.py - tools/chemenu/commands/run_budget.py - tools/chemenu/commands/xref.py - tools/chemenu/conventions.py - tools/chemenu/corpus_diff.py - tools/chemenu/frontmatter_io.py - tools/chemenu/kb_collections.py - tools/chemenu/kb_state.py - tools/chemenu/links.py - tools/chemenu/lint_core.py - tools/chemenu/provenance.py - tools/chemenu/sections.py - tools/chemenu/tests/conftest.py - tools/chemenu/tests/test_blocks.py - tools/chemenu/tests/test_cite_cmd.py - tools/chemenu/tests/test_conventions.py - tools/chemenu/tests/test_dist_cmd.py - tools/chemenu/tests/test_doctor.py - tools/chemenu/tests/test_migrate_cmd.py - tools/chemenu/tests/test_new_page.py - tools/chemenu/tests/test_pipeline_l0.py - tools/chemenu/tests/test_types_cmd.py - tools/chemenu/tests/test_xref.py - types/concept.schema.yaml - types/entity.md - types/entity.schema.yaml - types/instruction.schema.yaml - types/type-spec.md - work/link-taxonomy-migration/README.md - work/link-taxonomy-migration/plan.md	2026-09-02 18:39:22 +02:00