instructions/dev/issue-tracking.md: destructive-step invariants, comment-vs-body authority, rename sweep (#47 Block 1, #29)

Files changed:
- CHANGES.md
- VERSION
- instructions/dev/issue-tracking.md

.gitea/workflows/release.yml

@@ -66,6 +66,26 @@ jobs:
         run: |
           set -eu
           version="$(cat VERSION | tr -d '[:space:]')"
+
+          # A running candidate (`X.Y.Z-beta.N`) is never released - betas are
+          # a dev-checkout state, not a distributed one (see
+          # instructions/dev/version-parts.md). This guard sits *before* the
+          # API query below: without it, every `version bump` on a candidate
+          # would push VERSION and trigger a wasted round-trip against the
+          # releases API for a tag that was never going to be created. Ending
+          # the job cleanly here (not `exit 1`) is what keeps a beta bump a
+          # normal, unremarkable push rather than a failing CI run - skipping
+          # every later step is what "cleanly" means in Actions: mark this one
+          # skip and gate the rest on it.
+          case "$version" in
+            *-beta.*)
+              echo "VERSION is a running candidate (${version}) - nothing to release. Skipping."
+              echo "skip=true" >> "$GITHUB_OUTPUT"
+              exit 0
+              ;;
+          esac
+          echo "skip=false" >> "$GITHUB_OUTPUT"
+
           tag="v${version}"
           echo "version=${version}" >> "$GITHUB_OUTPUT"
           echo "tag=${tag}" >> "$GITHUB_OUTPUT"
@@ -82,6 +102,7 @@ jobs:
       - name: Release notes from CHANGES.md
         # `version notes` fails when the changelog has no entry for this
         # version, which is the last place that mistake can still be caught.
+        if: steps.version.outputs.skip != 'true'
         run: |
           set -eu
           tools/wikitool docs verify
@@ -90,6 +111,7 @@ jobs:
 
       - name: Build the distribution tarball
         id: build
+        if: steps.version.outputs.skip != 'true'
         env:
           VERSION: ${{ steps.version.outputs.version }}
           TAG: ${{ steps.version.outputs.tag }}
@@ -109,6 +131,7 @@ jobs:
           echo "name=${name}" >> "$GITHUB_OUTPUT"
 
       - name: Publish the release
+        if: steps.version.outputs.skip != 'true'
         env:
           API: ${{ github.server_url }}/api/v1/repos/${{ github.repository }}
           TOKEN: ${{ gitea.token }}

.wikitool-kb.json

@@ -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
     }
   ]
 }

AGENTS.md

@@ -71,6 +71,7 @@ What a file is called says who it is for and how it is loaded. This is a rule, n
 |------|-----|--------|
 | `README.md` | Humans - technical documentation and how to develop the thing in that directory | Never by an agent as instruction |
 | `EVALS.md` | Humans - how telemetry and evaluation work; routes to the contracts that bind | Never by an agent as instruction |
+| `DEVELOPMENT.md` | Humans - the release workflow (`version bump`/`version release`/`publish`/CI), for whoever develops this stack rather than an instance built on it | Never by an agent as instruction. Not shipped: `dist_cmd.ROOT_FILES` excludes it deliberately, the same way `instructions/dev/` (which it may link to, unlike the documents `instructions verify` holds to that rule) is excluded - a distributed instance has no release workflow to document |
 | `AGENTS.md` | Agents | Always, every session |
 | `CLAUDE.md` | Agents on Claude Code | Automatically by that harness, which does not load `AGENTS.md` - so it imports this file and the two below, and carries no rules itself. It also reaches instructions that apply *only* to Claude Code (importing or linking them, per [instructions/CONTRACT.md](instructions/CONTRACT.md)), which is the one thing this file cannot do for them: from here they would load into every other harness too |
 | `USER.md` | Agents | Always, every session |
@@ -82,6 +83,7 @@ What a file is called says who it is for and how it is loaded. This is a rule, n
 | `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`. Split by `root:`: a page type-spec (`root: kb`) belongs to the instance and ships as `.template`; one describing a stack artifact ships verbatim |
+| `docs/<name>.md` | Agents and humans | By link, or on explicit request - never automatically, and never as instruction |
 | `INDEX.md` | Both | Generated - never hand-edited |
 
 A stage may carry both a `README.md` and a `CONTRACT.md`: different readers, different
@@ -89,6 +91,16 @@ documents. What it may not carry is the same content twice - a README that resta
 contract is a second copy that drifts. `docs verify` enforces the specific case that already
 happened once: no README may hold a copy of the `wikitool` command table.
 
+**`docs/` carries no normative sentence.** It holds why the stack is built the way it is -
+background a session consults in passing, not a rule it must follow. Anything that would bind
+belongs in a `CONTRACT.md` instead, which is what keeps invariant 8 intact here: `docs/` is
+never a second place a rule could live, only prose about rules that live elsewhere. That is also
+why nothing verifies its content - there is no rule in it to check. It has no frontmatter, no type, no index, no lint, no decay, no provenance, and no
+`COLLECTION.md` - which [kb/CONTRACT.md § Collections](kb/CONTRACT.md#collections) forbids
+outside `kb/` anyway, but the point holds independently: `docs/` stays a plain directory of
+prose, invisible to everything `tools/wikitool` does except `dist export`, which copies it
+verbatim. A fresh instance needs the reasoning as much as this one does.
+
 ## Personalization
 
 `USER.md` and `SOUL.md` are read at session start, if the runtime has not already injected
@@ -145,7 +157,8 @@ input       schema + compiler     output   derived (gitignored)
                   work/   tracked scratch, deleted when the run closes
 ```
 
-Alongside it, not part of it: `instructions/` (what agents are told to do) and this file.
+Alongside it, not part of it: `instructions/` (what agents are told to do), `docs/` (why the
+stack is built the way it is - see [File naming](#file-naming)), and this file.
 
 **By stage** - read the contract for the stage you are writing in:
 
@@ -225,7 +238,8 @@ Every `tools/wikitool` call has exactly four outcomes:
    produced.
 
 After the single allowed retry - or immediately, for the non-idempotent commands `new`,
-`log append`, and `publish` - stop and report the exact command and error text to the user.
+`log append`, `publish`, and `upstream merge` - stop and report the exact command and error
+text to the user.
 
 Per-command detail (what exit 1 means, whether the command is atomic, whether a retry is
 safe) is in [tools/CONTRACT.md](tools/CONTRACT.md). A gate refusal is not a validation error -
@@ -263,3 +277,10 @@ and `tools/README.md` are part of the change that introduced a stage, a command
 not follow-up work: nobody comes back for them, and a document that describes a repo which no
 longer exists is worse than none. The mechanical half - command tables, contracts, ignore
 canaries - is checked by `tools/wikitool docs verify`; the prose half is yours.
+
+`docs/` pages are held to a different clock than those three. A README goes stale on every new
+flag; a `docs/` page goes stale only when the reasoning it wrote down stops holding - a gate
+that stops living in code, an ownership line that moves, a boundary redrawn - which is rarer
+and not tied to any one commit. Nothing checks this by construction: a page there carries no
+normative sentence (see [File naming](#file-naming)), so there is no rule for `docs verify` to
+check, only a rationale for a session to notice has gone stale and to update or retire.

CHANGES.md

@@ -18,6 +18,725 @@ 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.
 
+Since `4.4.0` the stack carries **one running candidate** between two
+releases rather than a fresh version per bump - see
+`instructions/dev/version-parts.md`. While a candidate is open its heading
+names it with a `-beta.N` suffix (`## 4.4.0-beta.2 - <date> - <title>`), and
+every bump of that same candidate updates this one entry in place rather than
+opening another: the heading's version/date/title move, and the bump's
+`--title` joins a machine-managed `<!-- wikitool:bumps -->` list right under
+the entry's `**Author:**` line - written and read by `wikitool version bump`,
+never by hand. `wikitool version release` is what closes a candidate: it
+strips the suffix and turns the entry into an ordinary, suffix-free one,
+leaving the bump-title list as the record of what happened. A distributed
+instance never sees a `-beta.` version at all (`release.yml` only ever
+releases a fixed one), so this suffix and the list beneath it are a
+dev-checkout concern - readable here, never shipped as something to parse.
+
+---
+
+## 4.5.1 - 2026-09-04 - issue-tracking - destructive-step invariants, comment-vs-body authority, rename sweep
+
+**Author:** Torben Nehmer
+
+<!-- wikitool:bumps -->
+- issue-tracking - destructive-step invariants, comment-vs-body authority, rename sweep
+<!-- /wikitool:bumps -->
+
+Block 1 aus #47 (gemeinsam mit #29): drei Ergänzungen an
+`instructions/dev/issue-tracking.md`, ausgelöst durch zwei Fehlerklassen, die
+in derselben Sitzung am Stack aufgetreten waren.
+
+- **Schritt 1** trägt jetzt, dass destruktive Schritte im Body die Invariante
+  nennen müssen, die sie nicht verletzen dürfen, und dass ein
+  Akzeptanzkriterium eine prüfbare Eigenschaft ist, keine Tätigkeit. Auslöser
+  war #30: der Body schrieb wörtlich "Arbeitsverzeichnis entfernen" für den
+  `upstream merge`-Ablauf, und genau das wurde zum datenvernichtenden Bug -
+  ein `shutil.rmtree` auf eine Stage mit gitignorierten, nicht
+  rekonstruierbaren Daten.
+- **Schritt 2** trägt jetzt die Lesesicht auf Body und Kommentare, die es
+  bisher nur aus Autorensicht gab: der Body ist der Stand, Kommentare sind
+  Historie; ein erkennbar veralteter Body wird richtiggestellt statt
+  umgangen; widersprüchliche Kommentare werden nach Beleg aufgelöst, nicht
+  nach Datum. Auslöser war ebenfalls #30 (ein Kommentar empfahl das Gegenteil
+  dessen, was der Body später festlegte) und #10 (ein seit Tagen veralteter
+  Body gegen drei widersprechende Kommentare, zwei davon sich selbst
+  widersprechend).
+- Neuer Abschnitt **"Renames and other decay in the tracker"** nach Schritt 7:
+  ein Rename ist erst fertig, wenn auch die offenen Issues nachgezogen sind,
+  weil `wikitool` diesen Tracker nicht kennt und nicht kennenlernen soll. Mit
+  der Wegweiser-vs-Beleg-Unterscheidung aus #29 und dem Hinweis, dass auch
+  verschwundene `kb/`-Seiten und private Infrastrukturangaben Issue-Texte
+  altern lassen. Ein neuer Trigger in "When to run" verweist darauf.
+
+Keine der drei Ergänzungen verschiebt die bestehende Nummerierung der
+Schritte 1-7 - die Querverweise darauf (u. a. aus
+`instructions/dev/stack-dev/SKILL.md` auf Schritt 7, aus
+`kb/concepts/Issue Label Scheme.md` auf Schritt 2) bleiben also gültig, ohne
+angefasst zu werden.
+
+Verifiziert: `tools/wikitool instructions verify`, `tools/wikitool docs
+verify`, beide grün (Prosa-only, kein Interface geändert, PATCH).
+
+#47 bleibt offen (Block 2: der Skill-Schnitt aus Vorschlag E; Block 3: die
+beiden Nebenbefunde). #29 bleibt ebenfalls offen: dieser Block deckte nur den
+Regelabsatz, nicht den noch ausstehenden Pfad-Durchgang durch #4, #5, #15,
+#21, #16, #26 - der war nicht Teil des Auftrags für diesen Block.
+
+---
+
+## 4.5.0 - 2026-09-04 - Beide Update-Wege in Code: upstream merge fuer Clones, dist upgrade fuer Tarball-Instanzen
+
+**Author:** Torben Nehmer
+
+<!-- wikitool:bumps -->
+- Faktenkorrekturen in der 4.4.0-Prosa; DEVELOPMENT.md ohne zweite Kommandobeschreibung
+- wikitool upstream merge/verify: code procedure for taking a stack update, ownership.py as the shared stack/instance boundary
+- upstream merge: combined-commit regression test (edit+add+delete+contract+template+contract-delete in one commit)
+- upstream merge: keep gitignored local data under a content stage, refuse a merge git never opened, report what actually changed
+- dist upgrade: apply a stack update, not just detect one (#7)
+- dist upgrade: Stamp-Semantik nach --keep-local benannt, docs/ownership-and-templates.md auf drei Eigentumsklassen nachgezogen
+<!-- /wikitool:bumps -->
+
+Die Prosa zu 4.4.0 - Changelog-Eintrag, `docs/version-model.md`, `instructions/dev/version-parts.md`,
+`DEVELOPMENT.md` - entstand ungeprüft: kein maschineller Check liest sie, und die Sitzung, die sie
+schrieb, hat den dafür vorgesehenen Modellwechsel aus `stack-dev` Schritt 6 übersprungen. Ein
+nachgeholter Durchgang hat drei Fehler gefunden, von denen der erste der teuerste war.
+
+**Der Befund war an einer Stelle schlicht falsch.** Changelog und `docs/version-model.md`
+behaupteten, unter dem alten Modell seien Nummern vergeben worden, die „nie ausgeliefert" wurden -
+im Changelog sogar mit einer erfundenen Zahl („fünf Minor-Bumps ... vier nie ausgeliefert"). Das
+Gegenteil stimmt: weil `release.yml` auf jede `VERSION`-Bewegung feuerte, wurde **jeder** Bump zu
+einem echten, getaggten Release. Der 2026-09-03 hat vier davon in sechs Stunden erzeugt (`4.3.0`
+bis `4.3.3`), zwei für reine Prosa-Änderungen. Der Schaden war nie ein Phantom-Release, sondern
+dass „Release" aufhörte, etwas zu bedeuten - vier Upgrades an einem Nachmittag sind für einen
+Konsumenten kein kleineres Versprechen, sondern ein unleserliches. Beide Stellen tragen jetzt den
+tatsächlichen Vorgang samt Beleg.
+
+Dazu zwei kleinere Korrekturen: `version-parts.md` nannte den Stack weiterhin `2.x` (er steht bei
+`4.x`), und `DEVELOPMENT.md` trug eine Tabelle, die für jeden Verify-Befehl ein zweites Mal
+beschrieb, was er prüft - eine Kopie dessen, was `tools/CONTRACT.md` hält und `docs verify` dort
+gegen die CLI prüft. Die Tabelle ist raus; dass die Datei selbst außerhalb der von diesem Check
+abgedeckten Dokumente liegt, steht jetzt an ihrer Stelle. Der Code-seitige Teil davon - ob
+`DEVELOPMENT.md` in `docs_verify.STAGE_READMES` gehört - hängt an #47, zusammen mit der Lücke im
+Skill, die den übersprungenen Modellwechsel überhaupt erst unauffällig gemacht hat.
+
+Kein Verhalten geändert, nur Prosa - und bewusst als laufender Kandidat gelassen statt fixiert:
+CIs Version-Gate verlangt die `VERSION`-Bewegung, ein Release verlangt sie nicht. Genau dafür gibt
+es das Modell aus 4.4.0.
+
+**Zweiter Bump auf demselben Kandidaten (#30):** `git merge upstream/main` behandelt einen
+bewegten Korpus asymmetrisch - eine gelöschte, upstream-geänderte Seite meldet sich als Konflikt,
+eine neu angelegte Seite wird still gestaged, nur eine beidseitig gelöschte Seite ist harmlos. Die
+Prosa-Prozedur in `private-instance.md` § "Taking a stack update" hat das geschlossen, aber mit
+vier eigenen Fehlern: der Pfadsatz stand dreifach (im Skript, im Kontroll-Grep, implizit in
+`dist_cmd.py`); eine vom Upstream **gelöschte** Maschinerie-Datei wurde von `git checkout
+MERGE_HEAD -- <pfad>` still ignoriert, weil das Skript kein `set -e` hatte; ein echter Konflikt in
+`tools/`/`types/`/`instructions/` endete in einem von der Prosa nirgends erwähnten offenen Merge;
+und ein *neuer* Maschinerie-Pfad unter einer Content-Stage hätte die Literal-Liste nie erreicht.
+
+Die Eigentumsgrenze ist jetzt ein Prädikat statt einer Liste: `chemenu/ownership.py`,
+`is_stack_owned(relative)`, wahr für `<stage>/CONTRACT.md` direkt unter einer Content-Stage
+(`kb`, `raw`, `work`, `reports`) und für jeden Pfad, der dort auf `.template` endet - nicht
+rekursiv, `kb/<collection>/COLLECTION.md` bleibt seit #39 instanzeigen. `dist_cmd.py` liest das
+Modul jetzt statt einer eigenen `_CONTENT_ALLOWED_NAMES`-Liste zu pflegen, und
+`CONTRACT_ONLY_STAGES` leitet sich aus `ownership.CONTENT_STAGES` ab statt die drei Stage-Pfade
+ein zweites Mal aufzuschreiben - ein Test hält fest, dass beide Sichten nicht auseinanderlaufen
+können.
+
+Neu: `wikitool upstream merge [--remote upstream] [--branch main] [--no-fetch]` und `wikitool
+upstream verify --since <rev> [--until HEAD]`. `merge` prüft Vorbedingungen (sauberer Baum, kein
+laufendes Merge, Remote löst auf), warnt statt zu blockieren, wenn `.wikitool-remotes.json` fehlt,
+hält den Merge offen (`--no-commit --no-ff`), zwingt jede Content-Stage auf die lokale Seite
+zurück, holt dann über die Vereinigungsmenge der Bäume von `MERGE_HEAD` und `HEAD` genau die
+stack-eigenen Pfade zurück - inklusive einer Löschung, falls der Upstream einen Maschinerie-Pfad
+entfernt hat -, verweigert bei verbliebenen unaufgelösten Pfaden ohne zu committen, committet
+sonst und verifiziert den entstandenen Commit mit derselben Logik wie `verify` - ein Fund dort
+wird laut gemeldet und **nicht** automatisch zurückgerollt. Nicht idempotent (AGENTS.md § Tool
+error contract), nicht budget-exempt; `verify` liest nur und ist wie `migrate verify` von der
+Budget-Gate ausgenommen. Die Mass-Update-Gate greift bei einem Merge-Commit strukturell nicht -
+das steht jetzt als eigener Absatz in `instructions/gates.md`, mit `upstream merge`s eigener
+Nachkontrolle als der Sicherung, die hier tatsächlich trägt.
+
+`private-instance.md` § "Taking a stack update" verweist jetzt auf den Befehl statt das Skript
+auszuschreiben; die Pfadtabelle bleibt als Erklärung stehen, ist aber nicht mehr die operative
+Liste. Vorschlag B (eigenes Demo-Repo) bleibt zurückgestellt, siehe #30.
+
+23 neue Tests unter `test_upstream_cmd.py` (35 Fälle mit der parametrisierten
+`is_stack_owned`-Tabelle) decken die Fälle aus der Spezifikation ab:
+gelöschte vs. geänderte vs. neu angelegte Seiten, `kb/CONTRACT.md`- und Template-Änderungen,
+`kb/entities/COLLECTION.md` bleibt lokal, eine gelöschte `raw/CONTRACT.md` landet, ein neuer
+Template-Pfad landet, ein offener `work/`-Lauf landet nicht, ein echter `tools/`-Konflikt lässt
+den Merge offen, ein schmutziger Baum wird unberührt abgewiesen, "bereits aktuell" ist ein No-op,
+die Publish-Remote-Gate-Warnung, `verify` gegen einen von Hand verpfuschten Merge, und die
+`dist_cmd`/`ownership`-Konsistenz.
+
+**Dritter Bump auf demselben Kandidaten:** die im Akzeptanzkriterium geforderte Kombinationsprobe
+fehlte noch - ein einzelner Upstream-Commit, der Editieren, Anlegen, Löschen einer Seite, eine
+Contract-Änderung, eine Template-Änderung und eine Contract-Löschung gleichzeitig bewegt. Jetzt
+als `test_one_upstream_commit_mixing_every_case_at_once` nachgetragen; alle sechs Erwartungen in
+einem `upstream merge`-Aufruf verifiziert.
+
+**Vierter Bump: zwei Fehler, die ein Review-Durchgang nach dem Publish gefunden hat.** Beide
+waren in der ersten Fassung enthalten, beide hätten Daten vernichtet, und keiner der bestehenden
+Tests hat sie berührt.
+
+*Erstens: die Content-Stage wurde als Ganzes gelöscht.* `_restore_stage_to_local` hieß in der
+ersten Fassung `shutil.rmtree(stage_dir)` — die wörtliche Übersetzung des `rm -rf kb raw` aus der
+Prosa-Prozedur. Für `kb/` und `raw/` ist das harmlos, weil dort nichts Ignoriertes liegt. Für die
+beiden Stages, die dieses Issue *neu* in den Satz aufgenommen hat, ist es das nicht: `reports/`
+ist bis auf seinen Contract komplett gitignored und trägt genau die Daten, die nirgends sonst
+existieren — die Telemetrie-Traces, aus denen `eval score` liest, gespeicherte Eval-Berichte,
+alte Lint-Reports. In dieser Instanz standen zum Zeitpunkt des Fundes 497 Trace-Verzeichnisse
+unter `reports/telemetry/`; ein einziger `upstream merge` hätte sie alle gelöscht, und zwar
+stillschweigend, weil git von ignorierten Dateien nichts meldet. Die Stage wird jetzt über die
+**getrackten** Pfade beider Bäume zurückgesetzt statt über das Verzeichnis; ignorierte lokale
+Daten bleiben unberührt. Leergewordene Verzeichnisse werden aufgeräumt, aber nur wirklich leere.
+
+*Zweitens: ein Merge, den git nie eröffnet hat, hätte die Maschinerie gelöscht.* Der Exit-Code
+von `git merge --no-commit --no-ff` wird bewusst ignoriert (Konflikte unter den Content-Stages
+sind erwartet). Nur: wenn git das Merge gar nicht erst eröffnet — unverwandte Historien, eine
+ignorierte Datei im Weg —, gibt es kein `MERGE_HEAD`, `_tree_paths("MERGE_HEAD")` liefert die
+leere Menge, und **jeder** stack-eigene Pfad in `HEAD` fällt damit in den Zweig „der Upstream hat
+ihn gelöscht": `kb/CONTRACT.md`, `raw/CONTRACT.md` und sämtliche Templates werden entfernt. Der
+Kommando-Ablauf prüft jetzt nach dem Merge-Aufruf, dass tatsächlich ein Merge offen ist, und
+bricht sonst ab, ohne den Baum angefasst zu haben. Beide Fehler haben je einen Regressionstest,
+und beide Tests wurden gegen die alte Fassung laufen gelassen, um zu zeigen, dass sie sie
+tatsächlich fangen.
+
+Dazu eine Ehrlichkeitskorrektur an der Erfolgsmeldung: sie zählte die *wiederhergestellten*
+Pfade, nicht die geänderten — ein Merge, der eine Datei bewegt, meldete vier oder fünf. Sie fragt
+jetzt `git diff` zwischen Vor- und Nach-Commit, kennzeichnet Löschungen, und stimmt damit mit dem
+überein, was ein Leser nachprüfen würde. `docs/ownership-and-templates.md` hat einen Abschnitt
+bekommen, warum die Grenze ein Prädikat und keine Liste ist — die Begründung, die dieses Issue
+erarbeitet hat, gehörte in die Hintergrunddoku und nicht nur in einen Changelog-Eintrag.
+
+**Fünfter Bump: `wikitool dist upgrade` (#7), der zweite der beiden Update-Wege.** `upstream
+merge` oben bedient eine Instanz mit gemeinsamer Git-History; `dist upgrade` bedient eine
+Instanz aus einem Tarball, ohne History, die bislang eine rein manuelle Prozedur in
+`INSTALL.md` durchlaufen musste - Schritt 4 verlangte einen sha256-Vergleich von Hand gegen den
+`files`-Block der alten `.wikitool-release.json`.
+
+Die tragende Regel: die Schreibmenge ist genau der `files`-Block der *neuen*
+`.wikitool-release.json`, minus was ein Export aus einer leeren Vorlage neu sät
+(`chemenu.ownership.is_export_stub`, wie bisher schon für `kb/log.md`/`.gitkeep`) oder einmalig
+sät und danach der Instanz gehört (`chemenu.ownership.is_upgrade_preserved`, neu für
+`.wikitool-kb.json` und `CHANGES.md`), plus der Stamp selbst. Jeder Kandidatpfad wird gegen die
+*alte* Instanz-Summe klassifiziert: unverändert wird geräuschlos überschrieben, neu im Release
+wird angelegt, lokal verändert oder gelöscht wird **nie** still überschrieben - der Lauf bricht
+mit der vollständigen Liste ab, außer `--keep-local` sagt ausdrücklich, dass die Dateien liegen
+bleiben sollen. `--prune` entfernt zusätzlich aus dem Release entfallene Dateien, aber nur
+solche, die seit der Installation unverändert sind.
+
+Die Migrationskette nach dem Tausch wird aus den `instructions/migrations/` des *neuen* Baums
+ermittelt (`kb_state.load_migrations` bekam dafür einen `directory`-Parameter) und nur
+gemeldet, nie ausgeführt - es gibt bewusst kein `migrate run`. Eine bereits gegen die
+*installierte* Maschinerie offene Kette lässt den Befehl abbrechen, bevor er die Quelle
+überhaupt öffnet. `kb_state.divergent_files()` (bisher nur von `migrate status` gelesen) ist
+jetzt eine dünne Hülle um das neue, zwei-Baum-fähige `compare_against_stamp()` - gleiches
+Verhalten für den bestehenden Aufrufer, wiederverwendbar für `dist upgrade`s eigenen Vergleich.
+
+Quelle ist immer ein bereits vorhandenes Verzeichnis oder `.tar.gz` - kein Download, das bleibt
+allein `version check`s Sache. Ein Tarball muss genau ein Top-Level-Verzeichnis enthalten (die
+Form, in der `release.yml` es baut) und wird gegen eine `.sha256`-Beidatei geprüft, falls eine
+danebenliegt (fehlt sie: WARN, kein Abbruch). Weitere Abbruchgründe vor jedem Schreiben: fehlende
+lokale `VERSION`/`.wikitool-kb.json`/Stamp mit `files`-Block, ein schmutziger Arbeitsbaum (kein
+Git-Repo ist ein WARN, keine Sperre), eine Vorab-Version (`-beta.N`) ohne `--pre`, sowie ein
+Downgrade; Gleichstand ist ein No-op. Ein Grenzübertritt der Kompatibilität wird laut gemeldet,
+blockiert aber nicht. Committet und pusht nichts (Invariante 5).
+
+Gegenüber dem ersten Entwurf des Issues zwei Korrekturen, die dort auch nachgetragen sind: der
+`files`-Block wurde entgegen der ursprünglichen Annahme bereits vor diesem Bump gelesen
+(`divergent_files`/`migrate status`), und die Migrationskette war ursprünglich falsch begründet
+- sie kann nur aus dem *neuen* Baum kommen, nicht durch eine andere Abfragereihenfolge aus der
+alten Instanz. 24 neue Tests unter `test_dist_upgrade.py` decken die Klassifikation, alle
+Abbruchgründe, `--keep-local`, `--prune` und beide Quellformen (Verzeichnis und Tarball,
+inklusive der sha256- und Top-Level-Prüfung) ab.
+
+Bewusst nicht angetastet: `instructions/private-instance.md` (der Clone-Weg ändert sich nicht,
+`INSTALL.md` benennt jetzt beide Wege nebeneinander) und die Frage, wie `dist upgrade` mit
+Collection-Templates umgeht, deren Namen eine fremde Instanz gar nicht hat - es verhält sich wie
+`upstream merge` und schreibt sie, was ein eigenes Issue gegen den Export wäre, keins gegen das
+Upgrade.
+
+**Sechster Bump: die ungeprüfte Phase nachgeholt.** Der Abschluss des vorigen Bumps lief auf
+Sonnet, und `stack-dev` Schritt 6 verlangt dort genau zwei Dinge, die kein Check erzwingt:
+Issue-Body und `docs/`-Veralterung. Der Body war gemacht, die `docs/`-Prüfung nicht - sie wurde
+benannt statt durchgeführt. Nachgeholt auf Opus, mit einem Fund.
+
+`docs/ownership-and-templates.md` § „The consequence in practice" beschrieb ein Upgrade als
+Zweiteilung: verbatim überschreiben, `.template`-gestützte Dateien liegen lassen - und begründete
+den ersten Teil damit, dass verbatim ausgelieferte Dateien „safe to replace wholesale" seien,
+weil sie „never instance-specific to begin with" waren. Genau diese Annahme trifft `dist upgrade`
+nicht: eine Instanz *kann* eine verbatim ausgelieferte Datei angefasst haben, und die sha256 je
+Datei existiert, um das zu erkennen, statt es vorauszusetzen. Dazu fehlte die dritte Klasse ganz -
+die einmalig gesäten, danach instanzeigenen Pfade (`.wikitool-kb.json`, `CHANGES.md`,
+`kb/log.md`, `raw/*/.gitkeep`), die im Stamp stehen wie jede andere Datei und deshalb aktiv
+ausgeschlossen werden müssen. Die Seite nennt jetzt drei Klassen und die engere praktische Regel:
+überschreibe die verbatim ausgelieferten Dateien, *die diese Instanz nicht angefasst hat*.
+
+Dazu eine Präzisierung in `tools/CONTRACT.md`, die vorher nirgends stand: nach `--keep-local`
+wird der neue Stamp trotzdem vollständig geschrieben, trägt also die Release-Summe auch für
+Dateien, die bewusst *nicht* geschrieben wurden. Der Stamp ist die Vergleichsbasis für den
+nächsten Lauf, kein wörtliches Inventar der Platte - und genau das hält eine übersprungene Datei
+bei jedem weiteren Lauf als abweichend gemeldet, statt sie nach einmaligem Überspringen still als
+aktuell zu führen.
+
+---
+
+## 4.4.0 - 2026-09-03 - Versionskandidat statt Bump-pro-Release: VERSION traegt -beta.N, version release fixiert
+
+**Author:** Torben Nehmer
+
+<!-- wikitool:bumps -->
+- Versionskandidat statt Bump-pro-Release: VERSION traegt -beta.N, version release fixiert
+<!-- /wikitool:bumps -->
+
+Bisher bekam jeder `version bump` sofort eine fixierte Nummer, und weil `release.yml` auf jede
+`VERSION`-Bewegung feuert, wurde daraus sofort ein Release: Nummern entstanden in
+Commit-Granularität statt in Release-Granularität. Der 2026-09-03 hat so vier Releases in sechs
+Stunden erzeugt (`4.3.0` bis `4.3.3`), zwei davon für reine Prosa-Änderungen - alle vier echt,
+keines davon eine Einheit, an der ein Konsument sich hätte orientieren können. `VERSION` trägt
+jetzt zwischen zwei Releases **einen** laufenden Kandidaten (`X.Y.Z-beta.N`):
+`--major/--minor/--patch` eskaliert diesen Kandidaten max-wins gegen den letzten Release, statt
+eine neue Nummer danebenzustellen, und geht dabei nie zurück.
+
+`Version` versteht den Suffix, mit einer expliziten Ordnung
+(`4.4.0-beta.1 < 4.4.0-beta.2 < 4.4.0`, numerisch nach `N`, nicht lexikografisch). `CHANGES.md`
+trägt genau einen offenen Eintrag pro Kandidat: der erste Bump eröffnet ihn, jeder weitere
+aktualisiert Heading und die maschinenverwaltete Bump-Titel-Liste in
+`<!-- wikitool:bumps -->` (Marker-Konvention aus `blocks.py`, aber bewusst nicht in
+`blocks.BLOCKS` - diese Region gehört zu `CHANGES.md`, nicht zu einer Seite). `version release`
+ist neu und fixiert einen Kandidaten: Suffix weg, Eintrag geschlossen, committet und pusht nichts.
+
+Vier Stellen am Bestand angepasst, die das Kandidatenmodell sonst still beschädigt hätten:
+`release.yml` überspringt einen suffixbehafteten `VERSION`-Push sauber, bevor die Releases-API
+gefragt wird, statt jeden Beta-Bump zu veröffentlichen; die Grenzübertritts-Checks in
+`docs verify` (`check_migration_for_boundary`, `check_breaking_change_for_boundary`) messen jetzt
+gegen den **letzten Release** (`version_mod.last_release`) statt gegen den zweitobersten Eintrag,
+der zwischen zwei Betas keine Grenze mehr hergibt; `kb_state.chain()`/`next_link()` vergleichen
+gegen die **Kandidatenbasis**, weil eine Migration mit Ziel `4.4.0` sonst bei installiertem
+`4.4.0-beta.1` aus dem Intervall fällt (`4.4.0-beta.1 < 4.4.0`); `read_kb_version()` verweigert
+einen Prerelease, weil eine Inhaltsform kein Beta kennt. `dist export` schreibt `VERSION` und den
+Stamp weiterhin ehrlich mit Suffix, aber `.wikitool-kb.json` bekommt die Basis.
+
+Menschendoku für die Erzeuger-Seite: `DEVELOPMENT.md` im Repo-Root, bewusst nicht in
+`dist_cmd.ROOT_FILES` (Begründung als Kommentar dort), mit Zeile in `AGENTS.md` § File naming und
+Zeiger aus `README.md`. `docs/version-model.md` hat einen neuen Abschnitt, warum eine Nummer erst
+durch ein Release verbraucht wird.
+
+---
+
+## 4.3.3 - 2026-09-03 - Modellwahl nach Pruefbarkeit statt nach Aufgabenname; stack-dev bricht an den Phasenwechseln fuer den Model-Switch
+
+**Author:** Torben Nehmer
+
+`instructions/claude-code-model-selection.md` routete bisher nach Skill: eine Zeile "Stack
+development -> Opus/high" fuer alles, was `tools/`, `types/` oder `instructions/` anfasst. Das ist
+zu grob in beide Richtungen - es verteuert die lange, mechanische Mitte einer Stack-Sitzung, und es
+sagt nichts darueber, dass Anfang und Ende derselben Sitzung anders zu behandeln sind.
+
+**Die neue Achse ist "was faengt hier einen Fehler ab".** Wo ein Check in Code steht - `pytest`,
+`docs verify`, `instructions verify`, CI, die Gates - kostet der Fehler eines schwaecheren Modells
+eine Runde und faellt auf. Wo die einzige Durchsetzung eine Sitzung ist, die Prosa liest, faellt
+derselbe Fehler gar nicht auf: er wird ausgeliefert und bleibt stehen. Das ist dasselbe Argument,
+das `docs/why-gates-are-code.md` fuer Gates fuehrt, angewandt auf die Modellwahl.
+
+Stack-Entwicklung ist damit **nicht mehr eine Zeile, sondern drei**:
+
+| Phase | Was einen Fehler faengt | Modell |
+|---|---|---|
+| Design, Versionsstelle, Grenzuebertritts-Urteil | nichts | Opus/high |
+| Code, Tests, mechanische Doku-Synchronisation | pytest, CI, `docs verify` | Sonnet/high |
+| Issue-Abschluss, `docs/`-Veralterung, Changelog-Prosa | nichts, per Konstruktion | Opus/high |
+
+Die Mitte ist die lange Phase und die mit den Checks - dort liegt die Ersparnis. Die beiden
+Raender sind kurz (Minuten, nicht Stunden), haben aber keinen maschinellen Waechter: `wikitool`
+kennt den Issue-Tracker bewusst nicht, und eine `docs/`-Seite traegt keinen normativen Satz, also
+gibt es dort nichts zu verifizieren. Sie oben zu lassen ist billig und schuetzt genau die Arbeit,
+die still scheitert.
+
+Zwei Praezisierungen dazu: **Effort ist der billigere Hebel als das Modell** - `medium` steht fuer
+Stack-Arbeit bewusst in keiner Zeile, weil Mehrdatei-Konsistenz das ist, was ein reduzierter
+Effort zuerst aufgibt; `high` ist die Untergrenze, sobald mehr als eine Datei oder ein Contract
+betroffen ist. Und die Asymmetrie ist benannt: eine unnoetige Opus-Phase kostet einmal Geld, eine
+ungepruefte Sonnet-Phase kann etwas ausliefern, das nie wieder jemand ansieht.
+
+**Damit die Tabelle ueberhaupt wirksam wird, braucht sie Haltepunkte.** Eine Sitzung kann ihr
+eigenes Modell nicht wechseln - das ist `/model` und gehoert dem Nutzer. Eine Empfehlung, die
+niemand zum richtigen Zeitpunkt ausspricht, aendert nichts. `instructions/dev/stack-dev/SKILL.md`
+bekommt deshalb zwei ausdrueckliche Breaks:
+
+- **Neuer Schritt 3** - "Settle the design before building", mit dem Angebot zum Wechsel nach
+  unten, sobald der Plan steht und die Arbeit mechanisch wird. Einmal aussprechen, dann so oder
+  so weiterarbeiten.
+- **Schritt 6 (Abschluss) bricht in die Gegenrichtung** - ab dort greift wieder kein Check. Mit
+  der ausdruecklichen Auflage, die Arbeit **unabhaengig von der Antwort** zu tun: nach dem Publish
+  auf einen Modellwechsel zu blockieren wuerde genau den Zustand hinterlassen, den Schritt 6
+  verhindern soll. Lief die Phase auf dem billigeren Modell, gehoert das in die Uebergabe statt
+  ins Schweigen.
+
+Ein auftauchender Grenzuebertritt ist unter den Decision points ebenfalls als Anlass zum Wechsel
+nach oben benannt: `docs verify` prueft, dass ein Uebertritt sich dokumentiert, nie dass die
+Stelle richtig gewaehlt war.
+
+Die uebrigen Schritte sind unveraendert und nur umnummeriert (alt 3-5 -> neu 4-6).
+
+---
+
+## 4.3.2 - 2026-09-03 - stack-dev: Issue-Abschluss ist ein nummerierter Schritt, kein Zeiger in einer Routing-Liste
+
+**Author:** Torben Nehmer
+
+Nachfassen zu 4.1.2 (#44), das die Regel geschaerft, aber den Weg zu ihr nicht geaendert hat.
+`instructions/dev/issue-tracking.md` bekam damals Schritt 7 ("Closing is the last body update,
+not a comment"); `instructions/dev/stack-dev/SKILL.md` bekam nur eine umformulierte Zeile in
+seiner Routing-Liste. Eine Stunde spaeter schloss #45 auf exakt dieselbe Weise: gruendlicher
+Abschlusskommentar ueber einem Body mit unangehakten Kriterien.
+
+**Die Ursache lag nicht am Text der Regel, sondern an ihrer Erreichbarkeit.** Die nummerierten
+Schritte des Skills endeten bei "Verify before publishing". Ein Issue zu schliessen war ueberhaupt
+kein Schritt - es hing an einem Zeiger *innerhalb* von Schritt 2, und Schritt 2 ist eine
+Routing-Tabelle aus fuenf "read X before Y"-Eintraegen, keine Checkliste. Eine Sitzung folgt dem
+Spine, den sie im Kontext hat; was nur hinter einem Link steht, wird genau in dem Moment nicht
+aufgeschlagen, in dem es greift - am Ende einer langen Sitzung, wenn der Kontext am vollsten und
+die verbleibende Instruktionsflaeche am duennsten ist.
+
+Verschaerfend arbeitete der Blurb gegen seine eigene Regel: fett gesetzt war "keep it current as
+the state moves, **not at the end**". Wer den Body unterwegs ungefaehr gepflegt hatte, las daraus
+Konformitaet - der eigentliche Abschlusstest stand nur in der verlinkten Datei.
+
+Geaendert:
+
+- **Neuer Schritt 5 in `stack-dev/SKILL.md`** - "Close the issue with a body rewrite, not a
+  comment", mit dem Test inline (Kriterien abgehakt oder mit Begruendung gestrichen,
+  Entscheidungen als entschieden formuliert, kein Praesens ueber einen behobenen Defekt,
+  Verifikation benannt) und dem Verweis auf Schritt 7 fuer die volle Form. Damit steht der
+  Abschluss auf dem Spine.
+- **Schritt-2-Blurb rebalanciert** - beide Haelften binden jetzt sichtbar: fortlaufende Pflege
+  *und* der Rewrite vor dem Schliessen, mit Verweis auf Schritt 5.
+
+Nichts davon ist maschinell pruefbar, und das bleibt richtig so: `wikitool` kennt den Tracker
+nicht und darf ihn nicht lernen, weil es an Instanzen ausliefert, die kein Board haben
+(`issue-tracking.md` § "What no tool checks"). Der Skill-Spine ist die einzige Durchsetzung, die
+es geben kann - was der Grund ist, den Schritt zu nummerieren statt ihn zu verlinken.
+
+Verallgemeinerbar: eine Regel, die in eine verlinkte Instruction geschrieben wird, erreicht
+Sitzungen nur, wenn die nummerierten Schritte des zustaendigen Skills sie in dem Moment
+ansteuern, in dem sie greift.
+
+---
+
+## 4.3.1 - 2026-09-03 - docs/ befuellt - Stack-Hintergrund fuer vier Themen, Pflegeklausel in AGENTS.md ergaenzt
+
+**Author:** Torben Nehmer
+
+Gitea #45: die von #38 angelegte, bis dahin leere `docs/` bekommt ihre ersten vier Seiten - frisch
+geschrieben, nicht durch Umzug aus `kb/` befuellt, jede ohne normativen Satz und mit Verweis auf
+das bindende Dokument statt einer Wiederholung seiner Regeln:
+
+- `docs/pipeline-rationale.md` - warum `raw -> types/tools -> kb -> reports` vier getrennte Stufen
+  sind und was "never re-derive, always compile" praktisch bedeutet
+- `docs/why-gates-are-code.md` - warum Mass-Update-, Publish-Remote- und Iteration-Budget-Gate in
+  `tools/wikitool` statt in einer Instruktion stehen
+- `docs/ownership-and-templates.md` - der Unterschied zwischen stack-eigenen, verbatim
+  ausgelieferten Dateien und instanz-eigenen `.template`-Dateien
+- `docs/version-model.md` - warum Drop-in-Kompatibilitaet und Migrationsbedarf zwei unabhaengige
+  Fragen sind, illustriert an der 2.0.0-Fallstudie
+
+**AGENTS.md § Changelog:** neue Klausel zur Pflege von `docs/`, ergaenzt neben der bestehenden
+Regel zu `README.md`/`EVALS.md`/`tools/README.md`. Eine `docs/`-Seite veraltet nicht wie ein
+README bei jedem neuen Flag, sondern nur, wenn die aufgeschriebene Begruendung selbst nicht mehr
+traegt - per Konstruktion ungeprueft, da die Seite keinen normativen Satz enthaelt, den
+`docs verify` pruefen koennte.
+
+---
+
+## 4.3.0 - 2026-09-03 - docs/ als ausgelieferter Hintergrund-Ort; Decision-Seiten bleiben in kb/, Decay-Skip fuer concept_type: decision
+
+**Author:** Torben Nehmer
+
+Gitea #38: `dist export` lieferte bislang keine einzige `kb/`-Seite aus - eine frische Instanz
+bekam den Stack, aber keinen Grund für seine Form. Die dokumentierte `adr-NNN-`-Konvention in
+`kb/concepts/COLLECTION.md` existierte zudem nur auf Papier: keine der sieben
+`concept_type: decision`-Seiten folgte ihr, und `confidence_decay()` lief bedingungslos über sie
+- ein Kategorienfehler, weil Zeitablauf eine Entscheidung nicht falscher macht, nur Supersession
+tut das.
+
+**Neu:** `docs/` - ein inertes Verzeichnis für Stack-Hintergrund (warum der Stack so gebaut ist,
+nicht was diese Instanz entschieden hat). Keine Frontmatter, kein Typ, kein Index, kein Lint,
+keine Decay, keine Provenance, keine `COLLECTION.md`. `dist export` liefert es verbatim aus, wie
+`instructions/` und `types/`. Befüllung folgt in Gitea #45.
+
+**Verworfen, nach Prüfung:** ein Umzug der sieben Decision-Seiten nach `decisions/`. Der
+Subtyp-Floor aus #28 verlangt mindestens eine Seite je deklariertem `concept_type`, und ein
+Umzug hätte `decision` auf null gebracht; dazu zeigen 89 Wikilinks aus `kb/` sowie
+tool-eigene Frontmatter-Arrays auf die sieben, und `links.py`/`xref add` kennen kein Ziel
+außerhalb `kb/`. Die sieben bleiben in `kb/concepts/`, ebenso ein zweiter, separat erwogener
+Rename (`docs verify` → `parity verify`) - der wäre nur nötig gewesen, wenn ein Befehl auf das
+Verzeichnis `docs/` wirkt, und keiner tut das.
+
+**Geändert:**
+- `confidence_decay()` überspringt `concept_type: decision` strukturell (kategorische Ausnahme,
+  nicht als Brücke gebaut - Begründung im Docstring).
+- `kb/concepts/COLLECTION.md` § Decisions ersetzt die tote ADR-Vorlage durch die real gelebte
+  Form: eine Entscheidung ist eine gewöhnliche Concept-Seite, organische Prosa, kein
+  `adr-NNN-`-Präfix, `**Status:**` optional, Supersession per `supersedes`-Link.
+- `kb/CONVENTIONS.md` § Naming und `instructions/kb-profiles.md` (Profil `german`) korrigiert -
+  beide dokumentierten noch die verworfene `adr-NNN-`-Namensregel.
+- `AGENTS.md` § File naming und § Routing: `docs/`-Zeile, plus die Regel, dass `docs/` keinen
+  normativen Satz trägt (das hält Invariante 8 heil - was binden würde, gehört in einen
+  Contract).
+- `tools/CONTRACT.md`: Klarstellung, dass `docs verify` Dokumentations-Parität prüft, nicht das
+  `docs/`-Verzeichnis, sowie `docs/` in der `dist export`-Zeile ergänzt.
+
+Additiv und in beide Richtungen drop-in: eine bestehende Instanz ohne `docs/` exportiert
+weiterhin identisch (leerer `_copy_tree`-Treffer), eine Instanz mit `docs/` bekommt es ab jetzt
+mitgeliefert. Kein Feld, kein Kommando ändert sein Verhalten für bestehenden Inhalt.
+
+**Migration:** none required.
+
+Berührt: `tools/chemenu/commands/confidence_decay.py`, `tools/chemenu/commands/dist_cmd.py`,
+`tools/chemenu/tests/test_confidence_decay.py`, `tools/chemenu/tests/test_dist_cmd.py`,
+`kb/concepts/COLLECTION.md`, `kb/CONVENTIONS.md`, `instructions/kb-profiles.md`, `AGENTS.md`,
+`tools/CONTRACT.md`.
+
+---
+
+## 4.2.0 - 2026-09-03 - Korpus-Kuratierungsrichtlinie: Untergrenzen und Leitplanke für reaktive Fixes
+
+**Author:** Torben Nehmer
+
+Ein Demo-Korpus will klein und stabil sein, ein Testbett groß, unordentlich und in Bewegung -
+dieses Repo verlangt seit der Veröffentlichung beides vom selben `kb/` (Gitea #28). Die Sitzung
+vom 2026-09-02 hatte Fixture, `--with-demo` und ein zweites Repo bereits verworfen; offen blieb
+nur, wie kuratiert "kuratiert genug" heißt und welche Leitplanke reaktive Fixes bekommen.
+
+**Neu:** `instructions/dev/corpus-policy.md`. Fünf Untergrenzen, jede mit einer bestehenden
+`wikitool`-Prüfung messbar, keine davon durch neuen Tool-Code: jeder Seitentyp und jeder
+deklarierte Subtyp mit mindestens einer Seite, mindestens fünf Seiten mit mindestens drei
+Quellen, ein bis zehn Orphan-Seiten, im Schnitt mindestens vier ausgehende Wikilinks pro Seite.
+Gemessen am 2026-09-03: 181 Seiten, alle Typ-/Subtyp-Floors erfüllt, 12 Seiten mit ≥3 Quellen, 3
+Orphans, Ø 6,2 ausgehende Links - der Korpus war bereits groß genug, ohne dass eine einzige
+Seite eigens dafür angelegt werden musste. Eine Untergrenze wird nie durch eine erfundene Seite
+gefüllt, sondern durch eine echte Quelle beim nächsten passenden Ingest - Invariante 3 gilt
+unverändert.
+
+**Die Leitplanke für reaktive Fixes** unterscheidet drei Stufen: punktuelle Änderungen (immer
+erlaubt, gewöhnliche Arbeit), korpusweite Änderungen (nur geplant, mit eigenem Issue und
+`work/`-Run - trifft eine Session das Mass-Update-Gate während sie etwas anderes tat, holt sie
+sich nicht den `--confirm`-Token, sondern stoppt und legt ein Issue an) und reaktive Eingriffe
+in Korpusinhalt, um einen Test grün zu machen oder einen Tool-Bug zu umgehen (nie erlaubt,
+Invariante 7). Das Verhältnis zu `kb_dir`/`raw_dir` und `test_pipeline_l0.py` bleibt wie im
+ursprünglichen Befund: kleiner, isolierter Fall in der Fixture, großer, vernetzter Fall in
+`kb/` - keine Fixture-Extraktion aus dem Korpus.
+
+Dev-only und rein additiv - kein Feld, kein Kommando, keine Datei außerhalb von
+`instructions/dev/` ändert sich, daher `--minor` ohne `--breaking`.
+
+**Migration:** none required.
+
+Berührt: `instructions/dev/corpus-policy.md` (neu),
+`instructions/dev/stack-dev/SKILL.md` (Schritt 2, Routing-Zeile).
+
+---
+
+## 4.1.2 - 2026-09-03 - Issue-Abschluss ist ein Body-Rewrite, nicht nur ein Kommentar
+
+**Author:** Torben Nehmer
+
+Aufgefallen beim Schließen von #44: der Abschlussbericht stand als Kommentar da, der Body
+darunter weiterhin als offene Arbeit — Abschnitt „Zu entscheiden" über eine längst getroffene
+Entscheidung, ungehakte Checkliste, Präsens über einen Defekt, den es nicht mehr gab.
+
+Die Regel gab es dafür schon: Schritt 2 von `instructions/dev/issue-tracking.md` sagt, der Body
+ist die aktuelle Wahrheit und wird umgeschrieben, wenn sich der Stand ändert. Nur ließ die
+Formulierung offen, *wann* — und Schritt 7 („Close with what actually happened") war vollständig
+erfüllbar, ohne den Body anzufassen. Ein Abschlussbericht im Kommentar fühlt sich beim Schreiben
+vollständig an; dass der Body dabei zurückbleibt, merkt erst der nächste Leser.
+
+**Schritt 2 ist deshalb schärfer geworden: der Body ist das Plan-File dieses Stacks.** Dasselbe,
+was das Plan-Dokument eines Harness ist, und genauso gepflegt — fortlaufend, sobald etwas darin
+nicht mehr stimmt, nicht am Ende. Der Maßstab ist der Abbruch, nicht der Meilenstein: eine
+Session kann jederzeit enden, und was der Body in diesem Moment sagt, ist die vollständige
+Übergabe. Eine frische Session muss zu **jedem** Zeitpunkt allein aus dem Body weiterarbeiten
+können, ohne Kommentare rückwärts zu lesen und ohne einen Menschen, der es neu erklärt. Entschieden
+ersetzt die Frage, erledigt hakt das Kriterium ab, verworfen steht mit Begründung dort, wo das
+Kriterium stand.
+
+Schritt 7 ist damit kein Sonderakt mehr, sondern die letzte dieser Aktualisierungen: erst Body
+auf den Endstand, dann schließen, dann die Changelog-Zeile aus Schritt 3. Wer Schritt 2 befolgt
+hat, ist fast fertig; wer nicht, zahlt die ganze Schuld im schlechtesten Moment — der
+geschlossene Body ist die Fassung, die danach alle lesen und niemand mehr aufsucht. #44 steht
+als Beispiel drin.
+
+Schritt 3 zieht die Konsequenz: **ein Kommentar pro Session-Umfang, nicht pro Edit.** Ein
+fortlaufend gepflegter Body mit einem Changelog-Kommentar je Änderung wäre Lärm; triviale Pflege
+braucht gar keinen. Der `stack-dev`-Skill sagt es beim Aufgreifen mit, weil dort die Entscheidung
+fällt, ob eine Session den Body überhaupt anfasst.
+
+**Und die ehrliche Antwort auf die Frage nach dem Tooling: es gibt keins, und es soll keins
+geben.** `wikitool` kennt diesen Tracker nicht. Es wird an Instanzen ausgeliefert, die unter
+dieser URL keine Issues haben, während `instructions/dev/` von `dist export` gepruned wird —
+ein Gitea-Client im ausgelieferten Tool wäre eine Dev-Abhängigkeit, die jede Instanz mitträgt,
+um ein Board zu prüfen, das keine von ihnen hat. Der Tracker ist ausschließlich über
+`gitea-mcp` erreichbar, also in einer Session, durch einen Agenten.
+
+Kein `docs verify` fängt also einen geschlossenen Issue, dessen Body offen klingt, einen Body,
+der seinen eigenen Kommentaren widerspricht, oder ein fehlendes Pflichtlabel. Das steht jetzt
+als eigener Abschnitt „What no tool checks" in der Instruktion — nicht als Bedauern, sondern als
+Begründung dafür, warum die Reihenfolge in Schritt 7 ausgeschrieben ist statt aus Schritt 2
+erschlossen zu werden.
+
+---
+
+## 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

DEVELOPMENT.md

@@ -0,0 +1,97 @@
+# Entwicklung dieses Stacks
+
+Dieses Dokument richtet sich an Menschen, die an `tools/wikitool`, dem Type-Schema oder der
+Instruction-/Skill-Schicht selbst arbeiten - nicht an den Konsumenten einer Instanz. Für die
+Gegenseite (eine Instanz installieren, aktualisieren, betreiben) siehe [INSTALL.md](INSTALL.md).
+
+**Diese Datei wird nicht ausgeliefert.** Sie ist das menschliche Gegenstück zu
+`instructions/dev/`, das `tools/wikitool dist export` vollständig ausschließt: eine
+ausgelieferte Instanz hat keinen Release-Workflow, keine CI und kein Issue-Board, also braucht
+sie auch keine Anleitung dafür. `dist_cmd.ROOT_FILES` listet sie deshalb bewusst nicht - der
+Grund steht dort als Kommentar, damit eine spätere Sitzung die vermeintliche Lücke nicht
+"repariert". Und weil sie nicht ausgeliefert wird, darf sie - anders als `README.md`,
+`INSTALL.md` oder `EVALS.md`, die `instructions verify` auf genau diesen Punkt prüft - nach
+`instructions/dev/` verlinken.
+
+## Der Release-Ablauf
+
+Zwischen zwei Releases führt der Stack **einen** laufenden Versionskandidaten statt einer neuen
+Nummer pro Bump. Das volle Modell - Zustandsort, Eskalationslogik, warum eine Nummer erst durch
+ein Release verbraucht wird - steht in
+[instructions/dev/version-parts.md](instructions/dev/version-parts.md) und
+[docs/version-model.md](docs/version-model.md). Hier nur der Ablauf, in der Reihenfolge, in der
+eine Sitzung ihn tatsächlich durchläuft:
+
+1. **Bump eröffnet oder eskaliert den Kandidaten.**
+
+   ```bash
+   tools/wikitool version bump --minor --title "Was sich geändert hat"
+   ```
+
+   Schreibt `VERSION` als `X.Y.Z-beta.N` und öffnet (oder aktualisiert) den passenden
+   `CHANGES.md`-Eintrag. Mehrere Bumps für dieselbe Änderung sind normal - jeder aktualisiert
+   denselben Eintrag, statt einen neuen zu eröffnen.
+
+2. **Der Eintrag bekommt seine Prosa.** `bump` schreibt nur das Skelett (Heading, Datum, Autor,
+   die maschinenverwaltete Bump-Titel-Liste, ggf. Breaking-/Migration-Zeile). Der Fließtext
+   darunter ist Autorenarbeit, wie bei `new` und der Seiten-Prosa.
+
+3. **Verify laufen lassen, bevor irgendetwas gepublished wird:**
+
+   ```bash
+   cd tools && .venv/bin/python -m pytest -q
+   tools/wikitool docs verify
+   tools/wikitool instructions verify
+   ```
+
+4. **`version release` fixiert den Kandidaten**, sobald er ausgeliefert werden soll:
+
+   ```bash
+   tools/wikitool version release --title "Zusammenfassender Titel"
+   ```
+
+   Streicht den `-beta.N`-Suffix aus `VERSION` und schließt den Changelog-Eintrag. `--title` ist
+   optional - ohne ihn bleibt der Titel des letzten Bumps stehen; mit ihm bekommt ein Kandidat,
+   der mehrere Bump-Titel gesammelt hat, eine zusammenfassende Überschrift. Committet und pusht
+   nichts (Invariante 5 in [AGENTS.md](AGENTS.md)).
+
+5. **Publish bewegt `VERSION` auf `main`.**
+
+   ```bash
+   tools/wikitool publish --message "..."
+   ```
+
+   Das Mass-Update-Gate und das Publish-Remote-Gate gelten wie bei jedem anderen Publish -
+   siehe [instructions/gates.md](instructions/gates.md).
+
+6. **CI übernimmt den Rest.** `.gitea/workflows/release.yml` reagiert auf jeden Push, der
+   `VERSION` bewegt: Eine suffixbehaftete `VERSION` (ein Kandidat) lässt den Job sauber
+   überspringen, bevor er die Releases-API überhaupt anfragt - Betas werden nie veröffentlicht.
+   Eine suffixfreie `VERSION` baut die Distribution (`dist export`), erzeugt Tag und Release und
+   lädt Tarball plus Prüfsumme hoch. **CI setzt den Tag, nie eine Sitzung** - das hält
+   Invariante 5 intakt.
+
+Die drei Verify-Befehle stehen oben in Schritt 3; was jeder von ihnen prüft, steht in
+[tools/CONTRACT.md](tools/CONTRACT.md) und wird dort von `docs verify` gegen die tatsächliche
+CLI gehalten. Hier steht es bewusst **nicht** noch einmal: eine zweite Beschreibung derselben
+Befehle ist genau die Kopie, die driftet (AGENTS.md Invariante 8), und dieses Dokument liegt
+außerhalb der Dateien, die der Kommandotabellen-Check von `docs verify` abdeckt - hier fällt eine
+Drift also niemandem auf. Was `pytest` an dieser Stelle vom Entwickler erwartet, steht in
+[instructions/dev/testing-conventions.md](instructions/dev/testing-conventions.md).
+
+## Die CI-Hälfte
+
+`.gitea/workflows/ci.yml` läuft auf jeden Push/PR gegen `main` (Content-Pfade ausgenommen) und
+führt Testsuite, `docs verify`, `instructions verify` sowie einen vollständigen
+`setup-instance.md`-Replay gegen einen frischen `dist export` aus - derselbe Pfad, den ein neuer
+Nutzer tatsächlich geht. `.gitea/workflows/nightly.yml` ist der Drift-Check gegen die Zeit statt
+gegen einen Commit. `.gitea/workflows/release.yml` ist Schritt 6 oben.
+
+## Stack-Entwicklung als eigener Sitzungstyp
+
+Der `stack-dev`-Skill (`instructions/dev/`, nur in diesem Ursprungs-Repo vorhanden) fasst die
+Regeln für eine Sitzung, die den Stack selbst statt Wiki-Inhalt bearbeitet: wann
+Quellenbindung nicht gilt, wo Design endet und die mechanische Phase beginnt (mit dem
+Modellwechsel-Hinweis), und dass Issue-Abschluss ein Body-Rewrite ist, kein Kommentar. Siehe
+[instructions/dev/issue-tracking.md](instructions/dev/issue-tracking.md) für den
+Issue-Tracker selbst.

INSTALL.md

@@ -167,10 +167,17 @@ wenn nicht). `tools/wikitool version notes` druckt den Eintrag.
 
 ### Eine Instanz aktualisieren
 
-Das Anwenden eines Updates ist ein bewusst manueller Vorgang - es schreibt in eine Instanz, die
+Zwei Wege, je nachdem, wie diese Instanz entstanden ist. Ein **Clone mit gemeinsamer
-bereits Inhalt hat. Der Inhalt hat dabei eine **eigene Version**: `.wikitool-kb.json` sagt, in
+Git-History** (`upstream`-Remote auf das Ursprungs-Repo, siehe
-welcher Form die Seiten vorliegen, unabhängig davon, welche Maschinerie danebensteht. Genau
+[instructions/private-instance.md](instructions/private-instance.md)) nimmt Stack-Updates per
-dieser Unterschied ist der Zustand, in dem sich jede Instanz mitten im Upgrade befindet.
+echtem Drei-Wege-Merge: `tools/wikitool upstream merge`. Alles Folgende gilt für eine **Instanz
+aus einem Tarball**, ohne gemeinsame History - der Weg unten unter „Eine Instanz aktualisieren"
+nutzt sie.
+
+Das Anwenden eines Updates schreibt in eine Instanz, die bereits Inhalt hat. Der Inhalt hat dabei
+eine **eigene Version**: `.wikitool-kb.json` sagt, in welcher Form die Seiten vorliegen,
+unabhängig davon, welche Maschinerie danebensteht. Genau dieser Unterschied ist der Zustand, in
+dem sich jede Instanz mitten im Upgrade befindet.
 
 1. **Vor dem Tausch** prüfen, was ansteht - solange `VERSION` noch die alte ist:
 
@@ -178,19 +185,49 @@ dieser Unterschied ist der Zustand, in dem sich jede Instanz mitten im Upgrade b
    tools/wikitool migrate status
    ```
 
-2. Release-Tarball herunterladen und entpacken (Weg A), die Release-Notes lesen.
+   Steht hier etwas aus, erst diese Migrationskette abschließen (Schritt 5 unten) - `dist upgrade`
-3. Die **Maschinerie** aus dem Tarball über die Instanz kopieren: `tools/`, `types/`,
+   verweigert den Tausch sonst von selbst.
-   `instructions/`, `AGENTS.md`, `VERSION`, `.wikitool-release.json` - **und `kb/CONTRACT.md`**.
+
-   Die letzte Datei liegt unter einem Content-Verzeichnis, ist aber Stack-Eigentum: sie hält,
+2. Release-Tarball herunterladen und die Release-Notes lesen (Weg A oben).
-   was `wikitool` erzwingt, und ist in jeder Instanz gleich. Nicht anfassen: alles andere unter
+3. **Maschinerie tauschen:**
-   `kb/` und `raw/`, `work/`, `.wikitool-kb.json` und `.git/` - das ist die Instanz selbst,
+
-   `kb/CONVENTIONS.md` und die `kb/*/COLLECTION.md` eingeschlossen.
+   ```bash
-4. Achtung bei lokal angepassten Stack-Dateien. Die Autorenkonventionen gehören **nicht** dazu:
+   tools/wikitool dist upgrade <tarball-oder-verzeichnis> --dry-run
-   `kb/CONVENTIONS.md` und die `kb/*/COLLECTION.md` liegen unter `kb/`, werden in Schritt 3
+   ```
-   also ohnehin nicht angefasst - genau dafür ist der Schnitt da. Wer darüber hinaus etwas
+
-   unter `tools/`, `types/` oder `instructions/` verändert hat, sichert das vorher und spielt
+   **Beim ersten Sprung auf `4.5.0` oder höher gibt es dieses Kommando in der Instanz noch
-   es danach wieder ein. Welche Dateien das sind, verrät ein Vergleich gegen die sha256-Summen
+   nicht** - es kam erst mit `4.5.0`. Dann das Werkzeug aus dem entpackten *neuen* Tarball
-   im `files`-Block der alten `.wikitool-release.json`.
+   verwenden, gegen die alte Instanz gerichtet:
+
+   ```bash
+   tar -xzf chemenu-stack-<version>.tar.gz
+   CHEMENU_ROOT="$PWD" chemenu-stack-<version>/tools/wikitool \
+     dist upgrade chemenu-stack-<version>.tar.gz --dry-run
+   ```
+
+   `CHEMENU_ROOT` sagt dem Paket, auf welchen Korpus es zeigen soll (siehe § Konfiguration);
+   ohne die Variable würde es den entpackten Tarball selbst für die Instanz halten. Ab dem
+   zweiten Upgrade trägt die Instanz das Kommando selbst und die kurze Form oben genügt.
+
+   Klassifiziert jede Datei aus dem `files`-Block der neuen `.wikitool-release.json`:
+   unverändert seit der Installation, lokal verändert oder gelöscht, neu im Release, oder aus dem
+   Release entfallen - und druckt die Migrationskette, die nach dem Tausch aussteht, ohne sie
+   auszuführen. Ohne `--dry-run` schreibt der Befehl; eine lokal veränderte oder gelöschte Datei
+   wird dabei **nie** stillschweigend überschrieben - der Lauf bricht mit der vollständigen Liste
+   ab, es sei denn `--keep-local` ist gesetzt (dann bleibt jede davon unangetastet, erneut
+   gemeldet). `--prune` entfernt zusätzlich Dateien, die der neue Release nicht mehr ausliefert
+   und die seit der Installation unverändert sind. Voraussetzungen: ein sauberer Arbeitsbaum
+   (kein Git-Repo ist ein WARN, keine Sperre), eine lokale `.wikitool-release.json` mit
+   `files`-Block (fehlt sie, siehe „Fallstricke" unten), und `.wikitool-kb.json` vorhanden.
+   Committet und pusht nichts (Invariante 5). Vollständiger Fehlerkontrakt:
+   [tools/CONTRACT.md](tools/CONTRACT.md).
+
+   Eine lokal veränderte Stack-Datei ist damit sichtbar, statt von Hand gegen die sha256-Summen
+   im `files`-Block geprüft werden zu müssen - genau der Schritt, der vor `4.5.0` hier stand.
+4. Bei einer Kompatibilitätsgrenze (`dist upgrade` meldet sie laut) die Release-Notes vor dem
+   nächsten Schritt lesen: **Breaking Change:** und **Migration:** im Eintrag von
+   `tools/wikitool version notes` sagen, was aufhört zu funktionieren und ob der Korpus
+   umgeschrieben werden muss.
 5. **Die Migrationskette abarbeiten.** `tools/wikitool migrate status` listet jetzt alle
    offenen Migrationen in der Reihenfolge, in der sie laufen müssen - bei einem Sprung über
    mehrere Versionen sind das mehrere. Für jede: das genannte Dokument unter
@@ -204,15 +241,30 @@ dieser Unterschied ist der Zustand, in dem sich jede Instanz mitten im Upgrade b
    `done` verweigert jede Version, die nicht das nächste Glied ist - eine übersprungene
    Migration hinterlässt einen Korpus in einer Form, die keine Version beschreibt. Ein
    abgebrochenes Upgrade wird durch erneutes `migrate status` fortgesetzt.
-6. Prüfen: `tools/wikitool migrate verify --from <commit vor der Migration>`, dann `doctor`,
+6. Prüfen: `tools/wikitool migrate verify --from <commit vor dem Tausch>`, dann `doctor`,
    `docs verify`, `instructions verify` und `lint`. Zum Schluss
    `tools/wikitool instructions sync` (die Skills sind Kopien) und die Agent-Session neu
-   starten.
+   starten. `dist upgrade` nennt diese Reihenfolge im eigenen Abschlussbericht, führt aber keinen
+   der Schritte selbst aus.
 
 `doctor` warnt, solange `kb_version` hinter `VERSION` zurückliegt und noch Migrationen offen
 sind. Einer Instanz, die älter ist als `.wikitool-kb.json`, fehlt die Datei ganz - dann einmalig
 `tools/wikitool migrate baseline <version>` aufrufen; geraten wird nichts.
 
+**Fallstricke.** Eine Instanz ohne lokale `.wikitool-release.json` (oder eine ohne `files`-Block,
+aus der Zeit vor `4.5.0`) hat für `dist upgrade` keine Basis, gegen die es eine lokale Änderung
+erkennen könnte, und verweigert den Tausch - dafür gibt es heute keine Reparatur (siehe Gitea #7).
+Der Befehl lädt selbst nichts herunter: `<tarball-oder-verzeichnis>` muss vorher aus Weg A
+geholt werden, und ein Tarball muss genau ein Top-Level-Verzeichnis enthalten - die Form, in der
+`.gitea/workflows/release.yml` es baut.
+
+Vor `4.5.0` stand hier ein rein manueller Ablauf (Maschinerie von Hand kopieren, `kb/CONTRACT.md`
+eingeschlossen, sha256-Vergleich von Hand). `dist upgrade` ersetzt genau diesen Teil; wer ihn
+dennoch von Hand nachvollziehen will oder muss (ein Werkzeug, das `wikitool` selbst nicht
+ausführen kann), findet die Dateiliste im `files`-Block der `.wikitool-release.json` und die
+Ausnahmen (`kb/CONVENTIONS.md`, `kb/*/COLLECTION.md`, `.wikitool-kb.json`) in
+[tools/CONTRACT.md](tools/CONTRACT.md)s `dist upgrade`-Zeile.
+
 ### Sonderfall: Update von 1.x auf 2.0.0
 
 Mit `2.0.0` wurde das Ursprungs-Repo von `torben/llm-wiki-test1` auf `torben/chemenu`

README.md

@@ -115,6 +115,7 @@ chemenu/
 Dev-instance-only (see `tools/CONTRACT.md` for how it got here):
 
 ```
+├── DEVELOPMENT.md      # Human-readable: the release workflow (version bump/release/publish/CI)
 └── commonplace/        # Vendored, read-only knowledge base
 ```
 <!-- dist:strip-end -->

VERSION

@@ -1 +1 @@
-4.0.0
+4.5.1

docs/ownership-and-templates.md

@@ -0,0 +1,115 @@
+# Ownership and Templates
+
+Chemenu ships two kinds of files side by side, and at a glance they look the same: both are
+plain markdown, both sit in the repo root or under `kb/`, both get read at session start. But a
+stack upgrade treats them completely differently. Some - [AGENTS.md](../AGENTS.md),
+[kb/CONTRACT.md](../kb/CONTRACT.md), the per-stage contracts - are identical in every instance
+that runs this stack and are the next release's to replace (with one caveat about local edits,
+below). Others - `USER.md`,
+`SOUL.md`, `kb/CONVENTIONS.md`, `ENVIRONMENT.md` - describe one particular instance, and
+overwriting them would silently erase a choice someone made on purpose.
+
+## Two different kinds of truth
+
+The stack-owned files describe how the tool works. `kb/CONTRACT.md` opens by saying it holds
+what `tools/wikitool` enforces or what follows mechanically from how it operates - see
+[kb/CONTRACT.md](../kb/CONTRACT.md), lines 10-13. That kind of statement doesn't vary by
+instance: the compiler behaves the same way regardless of who is running it, so the sentence
+describing that behavior can be copied byte-for-byte into every checkout without becoming
+wrong anywhere.
+
+The instance-owned files describe a choice: which language pages are written in, what tone the
+agent takes, who the operator is, which git remote is authoritative, which MCP servers are
+reachable. None of that follows from the tool's mechanics - two instances of the identical
+stack can answer all of these differently and both be correct. [AGENTS.md § Personalization](../AGENTS.md#personalization)
+frames the split the same way for `kb/CONTRACT.md` versus `kb/CONVENTIONS.md`: "the split is by
+who may change the sentence, not by what it is about." A rule about page structure could in
+principle have been written per-instance too, but then every instance answering "not German" to
+setup would be hand-editing a file the stack also ships, and the next `dist export` merge would
+hand the instance's own file back to it, discarding the customization.
+
+## Why silent overwrite is the failure being designed against
+
+A stack update is meant to be a routine, low-risk operation: pull the latest release, get
+whatever fixes and features shipped since the last one. That only stays low-risk if the update
+knows which files it's allowed to touch. If `USER.md` or `kb/CONVENTIONS.md` were treated the
+same as `AGENTS.md` - shipped and periodically re-copied - an upgrade would quietly replace a
+description of *this* operator, in *this* language, with whatever placeholder or default the
+stack maintainers wrote. The damage wouldn't be loud: nothing crashes, the files still parse,
+the agent just starts acting on the wrong premises until someone notices the voice or the
+language changed.
+
+Keeping the boundary at the file level, rather than trying to merge changes within a shared
+file, means an upgrade never has to guess which lines are "stack" and which are "instance" -
+the file itself already answers that.
+
+## Why the boundary is a predicate rather than a list
+
+For a while the boundary was written down as a list of paths - once in `dist_cmd.py`, once in
+the merge procedure a private instance was told to run by hand, and once in the check that
+procedure ended with. Three copies of one fact, which is the shape [AGENTS.md](../AGENTS.md)
+invariant 8 exists to forbid, and they drifted exactly as predicted: the hand-run procedure was
+still naming three paths after the collection contracts had moved to the instance's side of the
+line, so it discarded upstream changes to files it had never heard of, while its own final check
+excluded the same three paths and therefore reported success.
+
+`chemenu/ownership.py` replaced the lists with one question - is this path, under a content
+stage, the stack's or the instance's? - answered by shape rather than by enumeration:
+`<stage>/CONTRACT.md`, and anything ending `.template`. Both consumers ask it, so `dist export`
+and `wikitool upstream merge` cannot disagree, and a machinery file added under a content stage
+tomorrow is recognised by both without either being edited. The deeper point is not the
+deduplication: a list has to be maintained by whoever remembers it exists, and the failure mode
+when nobody does is silence, because a path the list has never heard of simply looks like
+content.
+
+## Why a `.template`, not just an absent file
+
+The mechanism for instance-owned content is a `.template` file the distribution ships instead
+of the real one - `USER.md.template`, `SOUL.md.template`, `kb/CONVENTIONS.md.template`,
+`ENVIRONMENT.md.template`. An alternative would have been to ship nothing at all and let a
+brand-new instance start from a blank page. The template exists because a blank page doesn't
+tell [instructions/setup-instance.md](../instructions/setup-instance.md) what shape the answer
+should take, and it gives nothing for a validator to check afterward.
+
+A template carries a placeholder value - a sentinel - in the fields that need a real answer.
+Setup interviews the operator and replaces the sentinel with what they actually said. That
+gives `doctor` a mechanical way to tell "personalized" from "not yet": a file that still
+contains the sentinel hasn't been through setup, regardless of whether the file exists. That's
+also why `ENVIRONMENT.md` only warrants a WARN rather than a FAIL when absent - see
+[AGENTS.md § Environment](../AGENTS.md#environment) - while a missing or unfilled
+`USER.md`/`SOUL.md`/`kb/CONVENTIONS.md` is a harder failure: `ENVIRONMENT.md` describes one
+checkout among possibly several and is gitignored for that reason, so its absence is a normal
+state rather than a sign setup was skipped.
+
+## The consequence in practice
+
+An upgrade sorts every shipped path into three categories, not two - and the third one only
+becomes visible once an upgrade is a command rather than a hand-run copy:
+
+- **Verbatim files** - `AGENTS.md`, `kb/CONTRACT.md`, the per-stage contracts, everything under
+  `tools/`, `types/` and `instructions/` - are the release's to replace.
+- **`.template`-sourced files** - `USER.md`, `SOUL.md`, `kb/CONVENTIONS.md`, each
+  `kb/<name>/COLLECTION.md`, `ENVIRONMENT.md`, the `root: kb` type-specs - are never written by
+  an upgrade at all. The distribution ships only the `.template` beside them, so the filled file
+  is out of reach by construction rather than by a rule someone has to remember.
+- **Seeded-once files** - `.wikitool-kb.json`, `CHANGES.md`, `kb/log.md`, `raw/*/.gitkeep` - are
+  written into a *new* instance by `dist export` and belong to the instance from then on. They
+  are the awkward category: they sit in the release stamp's file list like any other shipped
+  file, so an upgrade has to exclude them deliberately (`chemenu.ownership.is_export_stub` and
+  `is_upgrade_preserved`). An upgrade that re-seeded them would reset the record of which
+  migrations ran, or erase the changelog the instance wrote for itself.
+
+The first category carries a caveat that the word "verbatim" hides. It says who *decides* the
+content, not that overwriting is always safe: an instance can still have edited a verbatim file
+- a patched `tools/`, a locally adjusted instruction - and an upgrade assuming otherwise would
+destroy that silently. Avoiding that assumption is the whole reason `dist export` records a
+sha256 per shipped file in `.wikitool-release.json`. `wikitool dist upgrade` compares every
+candidate path against the digest recorded when it was installed, overwrites only what still
+matches, and refuses rather than overwrite what does not.
+
+So the practical rule is narrower than "overwrite the verbatim files, leave the rest alone":
+overwrite the verbatim files *this instance has not touched*, never write the other two
+categories, and make a locally changed file a decision someone takes deliberately instead of
+one an upgrade takes for them. The template-sourced files were filled in once, by a person, for
+a reason, and nothing about a newer release of the stack's mechanics gives it standing to
+override that.

docs/pipeline-rationale.md

@@ -0,0 +1,64 @@
+# Why the pipeline has four stages
+
+Chemenu could, in principle, be one directory: drop a file in, ask a question, get an answer
+computed fresh each time. It isn't built that way. The pipeline in
+[AGENTS.md](../AGENTS.md#routing) - `raw/` -> `[types/ + tools/]` -> `kb/` -> `reports/`, with
+`work/` alongside rather than inside it - separates *material* from *meaning* from
+*byproduct*, and each seam exists because collapsing it costs something specific.
+
+## Why raw material stays untouched
+
+[raw/CONTRACT.md](../raw/CONTRACT.md) keeps a source exactly as it arrived. The reasoning is
+simple once stated: the moment someone "cleans up" or reformats a source on the way in, the
+thing later claims get checked against is no longer the thing that was actually said. An
+immutable `raw/` means a citation always resolves to the original, not to somebody's tidied
+memory of it. It also draws a trust boundary in one place instead of scattering it - everything
+past `raw/` can be treated as reviewed, because nothing upstream of it silently already was.
+
+## Why extraction happens once, through a schema
+
+[types/type-spec.md](../types/type-spec.md) is what stands between a raw file and a `kb/` page:
+a type-spec defines what a conforming instance of a page looks like, and the compiler
+(`tools/wikitool`) applies it. The alternative - every query re-reading and re-interpreting the
+source on demand - would mean paying the cost of understanding the material every single time,
+and getting a slightly different answer each time depending on how the question was phrased.
+Extracting once, against a fixed schema, turns "re-read and re-guess" into "look up what was
+already compiled." That is the "never re-derive, always compile" principle from
+[AGENTS.md](../AGENTS.md): understanding a source is expensive and worth doing exactly once,
+after which it becomes a cheap, stable lookup.
+
+## Why a `kb/` page has to stand on its own
+
+[kb/CONTRACT.md](../kb/CONTRACT.md) sets the bar for the compiled layer: a page should answer a
+future question without sending the reader back to the source it came from. That's the payoff
+of compiling in the first place - if every answer still bottomed out in "go re-read the raw
+file," the `kb/` layer would just be a pointer with extra steps, and the cost of extraction
+would have bought nothing. A page that stands alone is what makes the corpus fast and
+consistent to query: the work of understanding is already sitting there, done.
+
+## Why `reports/` doesn't need to be maintained
+
+[reports/CONTRACT.md](../reports/CONTRACT.md) treats most of what lands in `reports/` -
+lint output, telemetry traces - as disposable. The structural content of a lint report can be
+recomputed from the tree at any commit, so keeping an old copy around would just be a second
+version of something the tool can already answer on demand, and a second copy is exactly the
+kind of thing that quietly goes stale. Treating it as derived output rather than a fourth thing
+to maintain means there is nothing there to fall out of sync - regenerating it is cheaper than
+reconciling it. The one part that genuinely can't be recomputed - the judgment a pass produced -
+is carried out into `kb/` or `kb/log.md` before the report itself is discarded, which is the
+distinction between what's recomputable and what isn't.
+
+## Where `work/` fits
+
+[work/CONTRACT.md](../work/CONTRACT.md) describes a workshop, not a fifth pipeline stage: a
+place for the notes, extracts and open decisions of a task that spans more than one session, on
+its way toward becoming a `kb/` page. It sits beside the raw -> kb -> reports flow rather than
+inside it - closer in spirit to a desk than to a conveyor belt.
+
+## The shape this produces
+
+Four stages, each answering a different question: `raw/` - what was actually said; `types/` +
+`tools/` - how to turn that into structured understanding; `kb/` - what is now known;
+`reports/` - what a pass over the corpus noticed in passing. Keeping them separate is what lets
+each one be trusted for what it is, instead of every layer having to double as all four at
+once.

docs/version-model.md

@@ -0,0 +1,119 @@
+# Why the stack version splits compatibility from migration
+
+A stack version number looks like it answers one question. It actually answers two, and the two
+are independent of each other.
+
+## Two questions, not one
+
+The first question is whether the new version is a drop-in replacement for the old one - whether
+an existing instance can install it, and can also go back, without anyone doing hand-work. That
+is what a version number *is*: a promise. The second question is whether the existing corpus in
+`kb/` needs to change shape to keep working under the new version. These sound like the same
+question, because most of the time a change that breaks compatibility also happens to touch
+content, and most of the time a change that leaves content untouched also happens to be
+compatible. The correlation is real; it just is not a law. `instructions/dev/version-parts.md`
+carries the actual test for telling them apart and the steps that follow from it - this page is
+about why the split exists at all.
+
+## Why "kb/ untouched" is not proof of anything
+
+The tempting shortcut is: if no page in `kb/` had to change, the bump can't be that serious. This
+is exactly backwards for a class of changes that live entirely outside the corpus - a renamed
+release artefact, a Python import path, an environment variable, the URL an instance's own
+updater points at. None of those touch a single page. All of them can strand an existing
+instance just as thoroughly as a rewritten type-spec would. The corpus is the part of the stack
+that looks at itself; the compatibility question is about everything an instance depends on to
+keep functioning, most of which the corpus never sees.
+
+## Reading compatibility off the leftmost non-zero component
+
+Semantic versioning gives every component a job, but only one of them is where an existing
+instance's tooling actually looks to decide "is this safe." On a `2.x` stack that is MAJOR; on a
+still-pre-1.0 `0.x` stack, by the same convention, it's MINOR - the leftmost slot that isn't
+pinned to zero is the one an automated updater treats as the compatibility boundary. Bump
+anything to its left, or bump that slot itself, and the promise changes. Everything to the right
+of it can move as freely as the project likes without touching that promise. This is why the
+question "is it boundary-crossing" always resolves to one specific digit, not to a feeling about
+how big the change is.
+
+## Downgrade is half the promise
+
+It's natural to test compatibility by only asking "does the upgrade work." The other half -
+"can an instance that upgraded put the old version back and land where it started" - carries
+equal weight, and it's the half that's easy to forget because forward motion is what everyone is
+testing for anyway. A state file the old version can no longer parse, a generated index in a new
+shape, a stamp file that got renamed: none of these have to break the upgrade to break the
+downgrade. An instance that can go forward but not back has already lost the property a
+compatible version number is supposed to guarantee.
+
+## A promise made to a machine, not only to a person
+
+A human reading a changelog can absorb "this technically isn't compatible but it's fine, just
+update those two things by hand." An instance's own update mechanism cannot. It reads a version
+number, decides whether to pull the new release, and has no channel for nuance - which is exactly
+why the update path itself is one of the sharpest ways to cross the boundary invisibly: if the
+new version moves where updates come from, the very channel that would have told an instance to
+adjust is the channel that just broke. The version number isn't documentation aimed at a reader;
+it's an input consumed by code that has no other way to ask.
+
+## The 2.0.0 story
+
+This isn't hypothetical for this stack. The rebranding that produced Chemenu renamed the repo,
+the release artefact, and the Python package - and left every page in `kb/` untouched. The first
+instinct was a MINOR bump, on the reasoning that nothing in the corpus needed migrating. That
+reasoning was correct on its own terms and answered the wrong question. Three things broke
+underneath it: every existing instance's `update_url` pointed at a repo path that no longer
+existed and, because it's a machine-written file, couldn't be hand-repaired; the release artefact
+name changed, breaking every download script and pin against it; and the import name changed,
+breaking anything importing the package from outside the shipped tree. The corpus had nothing to
+say about any of this, because none of it lived in the corpus.
+
+What caught the mistake was a person looking at the diff and asking whether it really was a
+drop-in replacement, not a validator. No check in `docs verify` or anywhere else confirms that a
+version part was chosen correctly - it only confirms that a boundary-crossing bump documents
+what it breaks. The 2.0.0 entry in `CHANGES.md` carries the corrected reasoning in full, and the
+version bump that shipped it was `--major --no-migration`: boundary-crossing and untouched
+corpus, at the same time, which is precisely the combination the two-question split exists to
+make visible.
+
+## Why a number is only spent by a release
+
+Everything above is about what a version number *promises*. A separate question turned out to
+matter just as much in practice: how many numbers get handed out along the way to making one
+release. For a while the answer was "one per bump," and that turned out to be the wrong grain
+entirely.
+
+Two mechanisms decide when a number gets minted, and they answer different questions. CI's
+version gate asks a *commit*-level one: has this tree changed since the last push, and if so
+has `VERSION` moved with it. A release asks something else entirely: is this a state worth
+handing to someone, under a number they will pin against. Tying the second to the first - every
+`VERSION` move firing the release workflow - answers the gate correctly and the release question
+by accident, because it treats every bump as if it were about to ship when most bumps are steps
+toward a release that has not happened yet.
+
+The failure mode is not phantom numbers; every one of those releases was real, tagged and
+downloadable. It is that "real" stopped meaning anything. On 2026-09-03 this repository cut four
+releases in six hours - `4.3.0` through `4.3.3` - for one continuous arc of work, two of them for
+prose changes alone. Someone tracking the feed saw four upgrades and had no way to tell which, if
+any, was a moment worth stopping for. A release is a promise addressed to a consumer, and a
+promise made four times an afternoon is not a smaller promise, it is a less legible one.
+
+The fix is not to slow the gate down - it still wants `VERSION` to move every time, and it still
+gets that. It is to stop treating every movement as a number worth publishing. Between two
+releases the stack now carries one running candidate, escalating through `-beta.N` as bumps
+accumulate, and only `version release` spends the number for real by fixing it and closing its
+changelog entry. A number is proposed by a bump and spent by a release; conflating the two was
+the actual defect, not the arithmetic of any single bump.
+
+This is also why a candidate never gets to a distributed instance. The promise a released version
+makes - "install this, and it is exactly what its number says" - has no equivalent for something
+still being decided during a single dev checkout's session. `release.yml`'s only job with respect
+to this is refusing to act on a suffixed `VERSION` at all: not because a beta is unsafe, but
+because there is nothing yet to promise.
+
+## Where the procedure lives
+
+The drop-in test, the catalogue of changes that cross the boundary with no page touched, and the
+steps for a boundary-crossing bump - the `--breaking` line, the migration document or
+`--no-migration` reason, talking to the user before bumping - are one procedure, kept at one
+place: [instructions/dev/version-parts.md](../instructions/dev/version-parts.md).

docs/why-gates-are-code.md

@@ -0,0 +1,57 @@
+# Why gates are code
+
+Chemenu has three hard limits - the Mass-Update Gate, the Publish-Remote Gate, and the
+Iteration Budget Gate - and all three live inside `tools/wikitool`, not in a paragraph of
+instructions an agent reads and follows. The rules themselves, and what to do when one trips,
+are in [AGENTS.md § Gates](../AGENTS.md#gates) and [instructions/gates.md](../instructions/gates.md).
+This page is only about the design choice underneath them: why code, and why these three
+mechanisms in particular.
+
+## A suggestion an agent can talk itself past
+
+An instruction like "don't publish too much at once" or "don't loop forever" lives in the same
+place as every other piece of guidance a session is holding - alongside the task, the user's
+last message, and whatever context made the moment feel urgent. Under pressure, or with a
+plausible-sounding reason ("this batch is different, it's mechanical"), that guidance can be
+reasoned around without anyone deciding to break a rule. Nothing enforces it; it just competes
+for attention with everything else in the context window, and sometimes loses.
+
+A check compiled into the tool doesn't have that problem, because it isn't part of the
+conversation at all. It runs before the command dispatches, regardless of how convincing the
+case for skipping it seemed a moment earlier. The difference isn't that code is smarter than a
+well-written instruction - it's that code doesn't get talked into anything.
+
+## Why three different mechanisms, not one
+
+The three gates ask three different questions, and each one's shape follows from what kind of
+question it is.
+
+The Mass-Update Gate asks *is this change too large to publish unreviewed* - a judgment that
+varies changeset by changeset, so it clears with a `--confirm` token tied to the specific
+output the user just read. Approval is scoped to that one publish.
+
+The Publish-Remote Gate asks something underneath that: *is this even the right repository*.
+That's not a per-push judgment, it's a standing property of the checkout - true or false for
+every publish that checkout will ever attempt, not just this one. A confirm token would let an
+agent clear it once and then treat the answer as settled, which is exactly backwards for a
+question whose answer shouldn't move at all mid-session. The only way past it is the user
+editing `.wikitool-remotes.json` directly, outside the gate's own flow.
+
+The Iteration Budget Gate asks a third kind of question - not "is this instance correct" but
+"has this session stopped making progress." That's read from the shape of the call history
+itself (call count, repeated identical calls), not from anything about the content of any one
+call.
+
+## Numbers that come from measurement, not intuition
+
+The iteration ceiling didn't start where it sits now. It used to run 15-25, borrowed from a
+general rule of thumb, until four real ingest runs measured 24, 26, 29 and 30 calls apiece -
+every one of them an ordinary workflow doing nothing wrong, and every one of them at or past
+where the old ceiling would have refused it. A limit that the normal case keeps tripping stops
+functioning as a limit; it becomes background noise a session learns to route `--override-budget`
+around as a matter of course, and the whole point of a hard-coded check is that it isn't supposed
+to feel routine.
+
+That's the deeper reason these numbers live in a tool rather than in prose: prose is read once
+and remembered loosely, but a threshold enforced every call is tested by every call, and a
+threshold that fails its own test gets noticed and re-measured rather than quietly ignored.

instructions/claude-code-model-selection.md

@@ -6,10 +6,24 @@ description: Which Claude model and effort level to run a Claude Code session, a
 
 # Pick the Claude model and effort level for the task at hand
 
-Scale the model and effort to how much judgment the task actually needs. Running everything at
+Scale the model and effort to **what catches a mistake in this part of the work** - not to how
-the most capable model and highest effort is safe but wasteful: the gates in [gates.md](gates.md)
+important the task feels, and not to its name. Running everything at the most capable model and
-are enforced in code, not by model judgment, so a weaker model cannot bypass them - it can only
+highest effort is safe but wasteful: the gates in [gates.md](gates.md) are enforced in code, not
-do a worse job of the calls the gates don't cover.
+by model judgment, so a weaker model cannot bypass them - it can only do a worse job of the calls
+the gates don't cover.
+
+That last clause is the whole rule, turned into a test. Where a check lives in code - `pytest`,
+`docs verify`, `instructions verify`, CI, the gates - a weaker model's mistake surfaces and costs
+one more round. Where the only enforcement is a session reading prose, the same mistake does not
+surface at all: it ships, and it stays until someone happens to notice. The two are not the same
+risk, and they should not get the same model. This is the argument
+[docs/why-gates-are-code.md](../docs/why-gates-are-code.md) makes about gates, applied to who is
+holding the keyboard.
+
+Both directions cost something, which is why the axis matters rather than a blanket answer:
+over-provisioning is a standing cost paid every session, while under-provisioning in an unchecked
+phase is a silent error with a long tail. A corrective session, its bump, its CI runs and its
+release together cost more compute than the model difference they were saving.
 
 Claude-Code-only, and imported by CLAUDE.md rather than linked from AGENTS.md: the model names,
 the `/code-review` effort dial and the `Agent` tool's `model:` override have no equivalent in the
@@ -28,17 +42,41 @@ to *make*, not a setting to apply.
 
 ## Steps
 
-1. **Recommend the session's model and effort by the skill in use**, when asked or when the
+1. **Recommend the session's model and effort by what catches a mistake in the phase it is in**,
-   mismatch is worth one sentence. Say it once and continue working either way - a session that
+   when asked or when the mismatch is worth one sentence. Say it once and continue working either
-   argues about its own model instead of doing the task has already cost more than the model
+   way - a session that argues about its own model instead of doing the task has already cost
-   difference:
+   more than the model difference:
 
-   | Skill / task | Model | Effort |
+   | Phase / task | What catches a mistake here | Model | Effort |
-   |---|---|---|
+   |---|---|---|---|
-   | `wiki-status`, simple `wiki-query` lookups | Sonnet | default |
+   | `wiki-status`, simple `wiki-query` lookups | the answer is re-checkable against the corpus | Sonnet | default |
-   | `wiki-lint` | Sonnet | default |
+   | `wiki-lint` | `lint` itself is the check | Sonnet | default |
-   | `wiki-ingest`, `wiki-manage`, judgment-heavy `wiki-query` | Sonnet | high |
+   | `wiki-ingest`, `wiki-manage`, judgment-heavy `wiki-query` | `lint` and `docs verify`, partly - the judgment about a claim is not covered | Sonnet | high |
-   | Stack development: `tools/`, `types/`, `instructions/` as code | Opus | high |
+   | Stack dev: design, the version part, a boundary-crossing judgment | nothing - `docs verify` checks that a crossing documents itself, never that the part was right | Opus | high |
+   | Stack dev: code, tests, mechanical doc sync (command tables, contract rows) | `pytest`, `docs verify`, `instructions verify`, CI | Sonnet | high |
+   | Stack dev: closing an issue, `docs/` staleness, changelog prose | nothing, by construction - see below | Opus | high |
+
+   **Stack development is not one row**, which is the point of splitting it. The middle phase is
+   where the tokens are and where the checks are, so it is the phase worth running cheaper. The
+   two around it have no mechanical guard at all - a `docs/` page carries no normative sentence,
+   so there is nothing for `docs verify` to check ([AGENTS.md](../AGENTS.md) § File naming), and
+   the same holds for whatever tracker an instance keeps its open work in, which `wikitool`
+   deliberately knows nothing about. Those two phases are short - minutes, not hours - so keeping
+   them on the stronger model is cheap, and it protects the only work in the session that fails
+   silently.
+
+   **Effort is the cheaper lever than the model.** Reach for it first: `medium` deliberately does
+   not appear in this table for stack work, because multi-file consistency is exactly what a
+   reduced effort level gives up. Sonnet at `high` is the floor for anything touching more than
+   one file or a contract; `default` is for a single-file mechanical edit with a test behind it.
+
+   **A session cannot switch its own model**, so these rows only become real if someone offers the
+   switch at the moment the phase changes - once, without arguing about it, and never as a reason
+   to stop work that is already underway.
+<!-- dist:strip-start -->
+   In this repo those moments are named: the `stack-dev` skill breaks for them at its steps 3
+   (design settled, work turns mechanical) and 6 (publish done, the unchecked tail begins).
+<!-- dist:strip-end -->
 
 2. **Pick a spawned subagent's model by what it does**, via the `Agent` tool's `model:`
    parameter - the values are `haiku`, `sonnet`, `opus`, `fable`:
@@ -66,8 +104,14 @@ to *make*, not a setting to apply.
   mechanical one - `wikitool` carries the mechanical part regardless of which model is
   supervising it.
 - **Unsure which row applies?** Default to Sonnet at high effort, not the most capable model at
-  the highest effort. Under-provisioning costs one worse answer in one session; reflexively
+  the highest effort. Under-provisioning *where a check exists* costs one worse answer in one
-  over-provisioning is a standing cost paid every session.
+  session; reflexively over-provisioning is a standing cost paid every session.
+- **Unsure whether the phase is checked?** Treat it as unchecked. The asymmetry is not symmetric:
+  a needless Opus phase costs money once, an unchecked Sonnet phase can ship something nobody
+  looks at again.
+- **Mid-session and the phase changed, but nobody switched?** Do the work anyway - never block a
+  publish or an issue close on a model the session cannot change itself. Say which phase ran on
+  which model in the handover, so the gap is visible rather than silent.
 
 ## Scope
 

instructions/dev/corpus-policy.md

@@ -0,0 +1,94 @@
+---
+type: types/instruction.md
+name: corpus-policy
+description: What "curated enough" means for kb/ when it is demo and testbed at once, the measurable floors that define it, and what a reactive fix to the corpus may and may not do.
+---
+# Keep kb/ curated enough to develop against, without a second corpus
+
+This instance runs one `kb/` for two purposes at once: a public demo and the testbed this stack
+is developed against. There is deliberately no fixture corpus, no `--with-demo` export, and no
+second repository - see Gitea #28. The corpus's size and shape are set by what targeted
+development needs, not by a synthetic fixture size or a demo aesthetic.
+
+## When to run
+
+- Before judging whether the corpus can exercise a change under development - ranking, index
+  scaling, orphan detection, a new label, a new type-spec.
+- Before a reactive fix touches `kb/` content rather than the failing code - the floors below
+  are what decides whether the fix may proceed as-is.
+- Picking up Gitea #28 or #30, or any issue that references this file.
+
+## The floors
+
+Each is mechanically checkable with an existing `wikitool` command; none needs new tool code.
+A floor exists to keep some class of bug observable, not to describe an aesthetic target - so
+when a session is about to make one of these numbers *worse*, that is the signal to stop and
+think, not a number to defend for its own sake.
+
+| Floor | Check | Why this number |
+|---|---|---|
+| Every page type has ≥1 page | `wikitool search --field type=types/<t>.md` | A type with zero pages means its schema, its collection contract and its lint rules are unexercised |
+| Every declared subtype has ≥1 page | `wikitool search --field <x>_type=<v>` | Same reasoning, one level down - `entity_type`, `concept_type`, `source_type` |
+| ≥5 pages corpus-wide with ≥3 `sources:` entries | one-off script, see below | Provenance fan-in - multiple sources backing one claim - is a real case only a handful of pages exercise; fewer than 5 and a provenance-index bug can hide |
+| Orphan pages (no inbound link) between 1 and 10 | `wikitool lint` | Zero orphans makes orphan detection itself unobservable; more than 10 means the corpus stopped being curated |
+| Average outbound wikilinks per page ≥4 | one-off script, see below | Below this, ranking and graph-traversal work has too little structure to exercise |
+
+A floor is a lower bound only. There is no upper bound on page count or on any of these numbers
+except the orphan ceiling above - a corpus that outgrows these floors through real ingests is
+not a problem this file cares about.
+
+**Measured 2026-09-03** (see Gitea #28): 181 pages, 14/14 types and subtypes covered, 12 pages
+with ≥3 sources, 3 orphans, 6.2 average outbound links. All floors held without any manufactured
+content - the corpus was already big enough when the question was asked.
+
+A type or subtype sitting at exactly the floor - one page - shows no set-level bugs, only that
+the type is *reachable*. That is a soft target for the next `wiki-ingest` that happens to
+produce a matching page, never a reason to write one: filing an unsourced page to clear a floor
+is exactly what AGENTS.md invariant 3 forbids, floor or no floor. The same holds for an
+authorised link label with zero live uses (`wikitool xref` reports these) - fill it when a real
+edge calls for it, never manufacture one to exercise the label.
+
+To check the two floors without a dedicated command, walk `kb/**/*.md` (excluding
+`INDEX.md`/`COLLECTION.md`/`CONTRACT.md`/`CONVENTIONS.md`), parse frontmatter, and: count pages
+whose `related:` array (resolved against page titles) has ≥3 entries for outbound density; count
+`sources:` array length ≥3 for the provenance floor. `wikitool search` and `wikitool lint`
+cover everything else in the table.
+
+## What a reactive fix may do to kb/ content
+
+Three tiers, by how much of the corpus a change touches:
+
+1. **Pointwise - always allowed.** Creating, updating, renaming or deleting a single page
+   through the normal tools (`new`, `touch`, the page-lifecycle procedure), below the
+   Mass-Update Gate's threshold. This is ordinary work and needs no special permission.
+2. **Corpus-wide - planned only, never reactive.** A migration, a vocabulary sweep, a bulk
+   `touch` across many pages. This needs its own issue and, per `work/CONTRACT.md`, a `work/`
+   run - never a same-session reaction to whatever the session was originally doing. If a
+   session hits the Mass-Update Gate (exit 42, see `instructions/gates.md`) while working on
+   something else, it does not fetch the `--confirm` token to push through: it stops, opens an
+   issue for the corpus-wide change, and finishes the original task without it.
+3. **Reactive - never allowed.** Deleting or reshaping a page to make a failing test pass;
+   restructuring corpus content to route around a tool bug (AGENTS.md invariant 7); using
+   `kb/` as a scratch surface for a tool experiment. If a stack change under development needs a
+   corpus shape that does not exist, build it as a pytest fixture (see the next section) -
+   never manufacture it in `kb/`.
+
+## Relationship to the test fixtures
+
+`tools/chemenu/tests/conftest.py`'s `kb_dir`/`raw_dir` fixtures and `test_pipeline_l0.py` cover
+the **small, isolated** case: a handful of pages, built fresh per test, hermetic. `kb/` covers
+the **large, connected** case: 181+ pages, grown link density, real provenance history that no
+per-test fixture reconstructs economically. The cut: if a `tmp_path` tree can reproduce what the
+test needs, it belongs in a fixture; if the test needs density or scale that only a grown corpus
+has, it belongs against `kb/`. Neither absorbs the other's job - see
+[testing-conventions.md](testing-conventions.md).
+
+## Decision points
+
+- **A floor would be violated by an in-progress change - is that a blocker?** Only for the
+  orphan ceiling and the type/subtype floors, since those two can go to zero. The density and
+  provenance floors move gradually with ordinary ingests and are not gating on any single
+  session.
+- **Corpus is "too small" for a feature under development?** That is not this file's problem to
+  solve by adding pages - see tier 3 above. Either the feature waits for a real ingest to supply
+  the shape, or it gets a pytest fixture.

instructions/dev/issue-tracking.md

@@ -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,8 +26,16 @@ 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.
+- **While working on one:** the body is updated as the state moves, not at the
+  end (step 2). A session that is interrupted leaves the body as its handover.
 - Prioritising: deciding what to pick up next, or re-labelling after the ground
   moved.
+- Closing one: the body is rewritten to its final state first, and only then
+  closed (step 7).
+- A rename or move ships: sweep the open issues for text that assumed the old
+  name or path (§ Renames and other decay in the tracker).
 
 ## Steps
 
@@ -36,38 +44,226 @@ 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 -
+   **Destructive steps carry the invariant they must not violate.** A body
-   a priority without a cost is half a decision. Neither is a promise about
+   that prescribes a mechanism gets built as prescribed - including its
-   *when*; together they answer "what should I pick up in the time I have".
+   bugs. Where a step deletes, overwrites, resets or moves, name the
+   property that must still hold afterwards, not only the command that gets
+   there. "Remove the working directory, then `git checkout HEAD --
+   <stage>`" is a mechanism; "the content stages must afterwards match
+   `HEAD` exactly, without any untracked or ignored file being touched" is
+   the same instruction plus its test - a build instruction and an
+   acceptance criterion at once, so the defect surfaces while the test is
+   written rather than in review afterwards. #30's `upstream merge` body
+   wrote the mechanism and got exactly that bug: a working-directory removal
+   that took a stage's gitignored, unrecoverable data with it.
 
-   | Priority | Means |
+   **An acceptance criterion states a checkable property, not an activity.**
+   "Implement X" is done when someone says so; "after `upstream merge`,
+   `reports/` still holds every file it held before" is done when it is
+   true. This is not a ban on imperative steps - a numbered procedure can
+   still produce a correct control flow, and that is its merit - it binds
+   the destructive steps, and every box in the criteria list.
+
+2. **The body is the working state, not a historical first post - keep it
+   current as you go.** It is this stack's plan file: the same thing a harness's
+   own plan document is, and it is maintained the same way. Not written once,
+   not brought up to date at the end, but **updated whenever something in it
+   stops being true** - a decision made, a criterion met, an approach ruled out,
+   a new constraint found.
+
+   The test is an abort, not a milestone. A session can end at any moment - an
+   interrupt, a context limit, a crash, a human walking away - and whatever the
+   body says at that instant is the entire handover. So the standard is: **at
+   every point, a fresh session must be able to open the body and pick the work
+   up from there**, without a human re-explaining it and without reading back
+   through the comments. If the body would mislead someone who read it right
+   now, it is already out of date, whether or not the work is finished.
+
+   That means updating *during* the work, not only at its end:
+
+   - a decision gets made → the decision and its reasoning replace the question
+   - an acceptance criterion is done → tick it, in the same session that did it
+   - something turns out differently than the issue assumed → the assumption is
+     corrected where it stands, not contradicted three paragraphs later
+   - work is deferred or dropped → say so, with the reason, where the criterion is
+
+   **Rewrite, never append.** Do not add 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, which is the exact cost the body exists
+   to remove. Comments carry the history (step 3); the body carries the state.
+
+   Body rewrites and comments are an LLM session's job. A human normally
+   touches only labels and metadata directly.
+
+   **Reading an issue, the body is the state and comments are history.** A
+   session picking an issue up reads the body as the spec; comments are read
+   for provenance - why something was decided, what was tried - never as
+   the current instruction. A recommendation in a comment can be older than
+   the body's decision and read just as convincingly: on #30 an earlier
+   comment recommended a smaller, `verify`-only command, while the body had
+   since settled on building the full `merge` command. A session trusting
+   the comment would have built the wrong thing, with a plausible
+   justification out of this repo's own tracker.
+
+   **A body that is demonstrably wrong is corrected first, not worked
+   around.** "Body beats comment" is a rule of precedence, not a licence to
+   execute a stale spec. Where a comment or the tree proves a claim in the
+   body false, the body is rewritten before the work starts - the rewrite
+   above is the fix; leaning on the comments as the "real" state is not.
+   #10 is the case: its body claimed coverage had never been measured while
+   three comments carried a percentage, a statement count and a CI run
+   number.
+
+   **Where two comments contradict each other, evidence decides, not
+   recency.** On #10, one comment showed a retrieved artifact with zero
+   items on a finished run - the report was not actually retrievable - and
+   a later comment declared the same criterion met without re-checking. The
+   later comment is not the newer truth, only the unchecked one. Resolve it
+   into the body with the evidence named, or mark the point open.
+
+3. **Comment a changelog, never a copy.** A 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.
+
+   One comment per *session's worth* of change, not per edit. Step 2 asks the
+   body to be kept current continuously, and a comment for every tick would bury
+   the board in noise; the changelog line summarises what that session moved.
+   Trivial upkeep - a typo, a tightened sentence - needs no comment at all.
+
+   ```
+   **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 |
-   proposals were implemented, which were deliberately left out and why, and
+   |---|---|
-   what was verified. The issue is the only place that record survives - a
+   | `status/blocked` | Waiting on another, still-open issue - not workable on its own, whatever its `prio/` says. Name the blocking issue in the body. |
-   changelog entry says what changed, not what was decided against.
+   | `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. **Closing is the last body update, not a comment.** If step 2 was followed
+   the body is already nearly there, and closing only settles what the final
+   run established. If it was not, closing is where the whole debt comes due -
+   and it comes due at the worst moment, because a closed body is the version
+   everyone reads afterwards and nobody revisits.
+
+   Either way the body reaches its final state *before* the issue closes:
+   proposals that were decided read as decided, a "to decide" section has become
+   the decision with its reasoning, acceptance criteria are ticked or struck with
+   a reason, and what was verified is named. Then close, with the one-line
+   changelog comment step 3 asks for.
+
+   Record what actually happened, not 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.
+
+   **A closing report in a comment does not satisfy this.** It reads as
+   complete to whoever writes it and leaves a body still phrased as open work:
+   unticked boxes, an undecided decision section, present tense about a defect
+   that no longer exists. #44 closed exactly that way, with a thorough comment
+   above a body that still asked for a decision that had already been made and
+   shipped. Nothing mechanical catches it (see below), which is why it is a step
+   rather than a habit.
+
+## Renames and other decay in the tracker
+
+A rename is not finished when the tree is green. Renaming a package, a path,
+a command, a flag or the repository itself moves text that lives outside the
+working tree, and the open issues are the largest such text. Nothing catches
+them - `wikitool` does not know this tracker exists and must not learn (see
+"What no tool checks" below) - so a pass over the open issues is part of the
+rename, in the session that did it, not a follow-up someone remembers.
+
+Distinguish a wayfinder from a piece of evidence: a path meant to point at
+where something *is* gets pulled through; a path quoted for what was true at
+a time is left standing and dated. Note per corrected body what was pulled
+through and when, so the next pass can tell a checked body from one that
+merely looks right. Closed issues are out of scope - they guide nobody.
+
+Renames are not the only thing that ages an issue text. A page a body cites
+can vanish from `kb/` (`wikitool search` against the cited titles is the
+second pass), and an old body can carry private infrastructure detail into
+what is now a public tracker - both found in the same issue, both worth the
+same look.
+
+## What no tool checks
+
+`wikitool` does not know this tracker exists, and should not learn. It ships to
+instances that have no issues at that URL, while this file and the workflow it
+describes are pruned by `dist export` - a Gitea client inside the shipped tool
+would be a dev-only dependency carried by every instance, to check a board none
+of them have. The tracker is reachable only through the `gitea-mcp` server, in a
+session, by an agent.
+
+So there is no `docs verify` for the board. Nothing reports a closed issue whose
+body still reads as open, a body that contradicts its own comments, or an issue
+missing one of the four mandatory labels. Every one of those is caught by a
+session following this file, or not at all - which is the argument for the
+sequence in step 7 being explicit about the order (body first, then close),
+rather than leaving it to be inferred from step 2.
 
 ## Decision points
 
@@ -75,8 +271,14 @@ 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. Closing an issue is
+  always a rewrite - see step 7.
+- **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.

instructions/dev/stack-dev/SKILL.md

@@ -43,17 +43,46 @@ 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/`. There is no `TODO.md`. **The body
-   filing something for later, or before deciding what to pick up next.
+   of the issue you are working on is this session's plan file:** keep it current as the state
+   moves, so an interrupted session leaves a body the next one can resume from, *and* rewrite it
+   to its final state before closing. Both halves bind; the second is step 6 below. Read it
+   before filing something for later, before editing or closing 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.
    [version-parts.md](../version-parts.md) - which part a change bumps: the drop-in test, the
    catalogue of breaks that cross the compatibility boundary with `kb/` untouched, and what to
-   put in front of the user before a breaking bump. Read it before step 3.
+   put in front of the user before a breaking bump. Read it before step 4.
+   [corpus-policy.md](../corpus-policy.md) - what "curated enough" means for the shared
+   demo/testbed `kb/`, the measurable floors that define it, and what a reactive fix may and may
+   not do to corpus content. Read it before judging whether the corpus can exercise a change, or
+   before any fix that would touch `kb/` content.
    More instructions are added here incrementally as stack-development needs come up - this
    list grows without needing this skill file to change shape.
-3. **Raise the version, if the change ships.** A change under `tools/`, `types/`,
+3. **Settle the design before building - and break there for the model switch.** These are two
+   different kinds of work, and the split is not stylistic: design, the version part and any
+   boundary judgment have **no** mechanical guard, while the code and tests that follow have
+   `pytest`, `docs verify`, `instructions verify` and CI behind them.
+
+   So when the design is settled - the issue body says what will be built, the open questions are
+   answered - stop and say so, in one sentence:
+
+   > Der Plan steht, ab hier ist die Arbeit mechanisch und durch Tests/CI abgedeckt. Wenn du auf
+   > Opus bist, ist jetzt der Moment für `/model sonnet` bei Effort `high`.
+
+   **You cannot make this switch yourself** - the session's model is the user's `/model`, not a
+   setting an agent applies. Offer it once and keep working either way; a session that argues
+   about its own model has already cost more than the difference. If the design turns out not to
+   be settled after all - a boundary crossing surfaces, an assumption breaks - that is a reason to
+   offer the switch back up, not to decide it alone.
+
+   Effort is the cheaper lever than the model, and `high` is the floor for anything touching more
+   than one file or a contract. Full table and reasoning:
+   [claude-code-model-selection.md](../../claude-code-model-selection.md).
+
+4. **Raise the version, if the change ships.** A change under `tools/`, `types/`,
    `instructions/`, `AGENTS.md` or a `CONTRACT.md` reaches every future instance, so it needs a
    version and a changelog entry:
 
@@ -90,13 +119,48 @@ stack development happens in the origin repo instead (see AGENTS.md's routing li
    Prose-only changes (`README.md`, `INSTALL.md`, `EVALS.md`) and the workflows under `.gitea/`
    do not need a bump - CI's version gate is scoped to what changes behaviour.
 
-4. **Verify before publishing.** `tools/wikitool docs verify`, `tools/wikitool instructions
+5. **Verify before publishing.** `tools/wikitool docs verify`, `tools/wikitool instructions
    verify`, and the relevant `pytest` run in `tools/` - the same checks any stack change must
    pass, run explicitly rather than assumed. CI (`.gitea/workflows/ci.yml`) runs these plus a
    full `setup-instance.md` replay against a fresh `dist export`; a push to `main` that moves
    `VERSION` additionally triggers a tagged release. **CI does the tagging** - a session never
    creates a tag, which is what keeps AGENTS.md invariant 5 intact.
 
+6. **Close the issue with a body rewrite, not a comment.** The last act of a session that
+   finished a work package, and the one most easily skipped: by here the change is published and
+   the issue feels done. It is not. The body is the version everyone reads afterwards and nobody
+   revisits, so it is the one place the debt comes due at the worst moment.
+
+   **Break here too, in the other direction.** Everything left in the session - this rewrite,
+   whether a `docs/` page's reasoning went stale, the changelog prose - is the unchecked kind of
+   work again, the mirror of step 3. If the session dropped to Sonnet there, say so now:
+
+   > Ab hier greift kein maschineller Check mehr - Issue-Body, `docs/`-Veralterung und
+   > Changelog-Prosa prüft nichts. Wenn du zurück auf Opus willst, ist jetzt der Moment.
+
+   Then **do the work regardless of the answer.** Never block a close on a model switch: the
+   change is already published, and a session that stops here leaves exactly the state this step
+   exists to prevent. If it ran on the cheaper model, name that in the handover rather than
+   leaving it silent.
+
+   Rewrite it to its final state *first*, then close. The test is what a reader who opens the
+   closed issue tomorrow would conclude:
+
+   - every acceptance criterion ticked, or struck with the reason it was dropped
+   - proposals that were decided read as decided; a "to decide" section has become the decision
+     and its reasoning
+   - nothing left in the present tense about a defect that no longer exists
+   - what was verified is named - which checks ran, which CI run - not a commit hash alone
+
+   Then one short comment naming what changed against the previous state, and nothing else.
+
+   **A closing report in a comment does not satisfy this**, however thorough: it reads as
+   complete to whoever writes it and leaves a body still phrased as open work. Nothing
+   mechanical catches it - `wikitool` does not know this tracker exists and must not learn it,
+   since it ships to instances that have no board - so this step is the only enforcement there
+   is. #44 and #45 both closed exactly this way, the second an hour after the rule was written.
+   [issue-tracking.md](../issue-tracking.md) step 7 has the full shape.
+
 ## Decision points
 
 - **Touches both stack code and wiki content in one session?** Apply this skill's rules to the
@@ -107,7 +171,10 @@ stack development happens in the origin repo instead (see AGENTS.md's routing li
   user decides whether it is worth that: show them what breaks, what an instance has to do about
   it, and the alternatives (avoid the break with a shim, defer and batch it with the next one,
   or split it behind a deprecation window), then recommend one and wait for a go-ahead.
-  [version-parts.md](../version-parts.md) step 4 has the full shape.
+  [version-parts.md](../version-parts.md) step 4 has the full shape. A surfacing boundary crossing
+  is also a reason to offer the model switch back up (step 3): the judgment it needs has no
+  mechanical guard, and `docs verify` only checks that a crossing documents itself, never that the
+  part was chosen correctly.
 
 ## Scope
 

instructions/dev/testing-conventions.md

@@ -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

instructions/dev/version-parts.md

@@ -9,7 +9,7 @@ Two questions decide a version bump, and they are **not the same question**:
 
 1. **Is the new version a drop-in replacement for the old one?** This is what the version
    number itself says. Compatibility is read off the **leftmost non-zero component** - on this
-   stack (`2.x`) that is MAJOR, on a `0.x` stack it is MINOR. A bump that changes it is called
+   stack (`4.x`) that is MAJOR, on a `0.x` stack it is MINOR. A bump that changes it is called
    *boundary-crossing* below, because that is the term `version bump` and `docs verify` use in
    their own messages.
 2. **Must existing content be migrated?** This is a *consequence* a boundary crossing may or
@@ -20,6 +20,38 @@ Two questions decide a version bump, and they are **not the same question**:
 Getting these backwards is how a genuinely breaking change ships as a MINOR. It happened once
 already (see the case study at the end), which is why this file exists.
 
+## The candidate model
+
+Between two releases the stack carries **one running candidate**, not a fresh version per
+`bump`. Before that, every bump minted a number *and* a release: CI's version gate requires
+`VERSION` to move on every stack-touching push, and `release.yml` fires on every `VERSION`
+move, so releases were being cut at commit granularity. 2026-09-03 produced four of them in
+six hours (`4.3.0` through `4.3.3`) for one arc of work - all four real, none of them a
+meaningful unit to anyone downstream. A candidate closes that gap without touching the gate:
+`VERSION` still moves on every bump, it just escalates the *same* number instead of handing out
+a new one, and only `version release` turns it into something the release workflow acts on.
+
+- **State lives in `VERSION` itself**, as an optional `-beta.N` suffix (`4.4.0-beta.3`). No
+  second state file: the last release is read back out of `CHANGES.md` (the newest entry with no
+  suffix), and the escalation stage is the difference between the candidate's base and that
+  release - derived, not stored.
+- **`--major`/`--minor`/`--patch` is max-wins escalation**, not a step you can undo. A `--patch`
+  bump on a candidate already at MINOR only advances its bump count (`N`); nothing ever steps a
+  candidate back down. Declaring the part is still your judgment call, made the same way the
+  steps below describe - `escalate()` only ever raises it further.
+- **A candidate is never released.** Pre-release is a dev-checkout state; `release.yml` only acts
+  on a suffix-free `VERSION`, so a distributed instance never sees a `-beta.` version at all, and
+  its parser never has to know the suffix exists.
+- **One `CHANGES.md` entry per candidate**, not per bump. The first bump of a candidate opens it
+  (heading, date, author, and a machine-managed `<!-- wikitool:bumps -->` list seeded with that
+  bump's `--title`); every later bump of the *same* candidate updates that entry in place -
+  heading, date and the bumps list all move, but the entry's own prose (written below the
+  skeleton, by hand) is left alone. `version notes` therefore still prints exactly one entry per
+  release, whatever a candidate's history of bumps looked like.
+- **`version bump` opens or continues a candidate; `version release` fixes one.** Only `release`
+  strips the suffix and turns the entry into a real, closed release - see its own row in
+  `tools/CONTRACT.md`. Nothing else does, and nothing auto-fixes a candidate on its own.
+
 ## When to run
 
 Before every `tools/wikitool version bump` - the `stack-dev` skill's step 3 sends you here.
@@ -63,9 +95,11 @@ the three-line test below is usually enough.
    | Fix, no interface change | `--patch` |
    | New capability, drop-in in both directions | `--minor` |
 
-4. **Stop and talk to the user before a boundary-crossing bump.** It is expensive in a way the
+4. **Stop and talk to the user before the bump that first escalates a candidate past the
-   other two parts are not: every existing instance pays for it, once, by hand. Put in front of
+   boundary.** It is expensive in a way the other two parts are not: every existing instance pays
-   them, in this order:
+   for it, once, by hand. That escalation happens exactly once per candidate - a later bump that
+   keeps the candidate at the same stage (another `--major` on one already there, say) does not
+   re-cross anything and needs no second conversation. Put in front of the user, in this order:
 
    - **What breaks**, concretely - which file, which name, which call site.
    - **What each existing instance must do**, as the steps they would actually run.
@@ -81,8 +115,9 @@ the three-line test below is usually enough.
 
    Then wait for an explicit go-ahead. Do not bump across the boundary on your own initiative.
 
-5. **Record the break in the bump itself.** A boundary-crossing bump requires
+5. **Record the break in the escalation bump itself.** The bump that first crosses the boundary
-   `--breaking "<what breaks>"`, which writes a `**Breaking Change:**` line into the entry:
+   requires `--breaking "<what breaks>"`, which writes a `**Breaking Change:**` line into the
+   entry:
 
    ```bash
    tools/wikitool version bump --major \
@@ -91,22 +126,33 @@ the three-line test below is usually enough.
      --no-migration "<why no page has to change>"     # only if that is true
    ```
 
-   `--breaking` is refused on a bump that crosses nothing, and required on one that does;
+   The line, once written, stays in the entry across every later bump of the same candidate -
-   `docs verify` checks the newest boundary-crossing entry still carries the line. Write it for
+   a follow-up `--major` does not need to repeat `--breaking`, because the entry it would repeat
-   the operator of an instance that has not read this repository: what stops working, and what
+   it into is the same one. `--breaking` is refused on a bump that crosses nothing, and required
-   they do about it.
+   on the one that does. `docs verify` checks the newest boundary-crossing entry still carries
+   the line. Write it for the operator of an instance that has not read this repository: what
+   stops working, and what they do about it.
 
 6. **Then answer the migration question separately.** Boundary-crossing and
    content-migrating are independent:
 
    - Content must change → write the migration document under `instructions/migrations/` per
-     [migrate-corpus.md](../migrate-corpus.md). `bump` finds it by its `migrates_to:` field.
+     [migrate-corpus.md](../migrate-corpus.md). The escalation bump finds it by the document's
+     `migrates_to:` field, matched against the candidate's **base** - a document targets the
+     release the candidate will become, never a `-beta.N` form of it.
    - Content need not change → `--no-migration "<reason>"`, which records that in the entry.
 
    Both are also needed by `docs verify`, for the same reason: an instance that learns it must
-   migrate, with nothing telling it how, is a dead end.
+   migrate, with nothing telling it how, is a dead end. Like `--breaking`, both persist across
+   later bumps of the same candidate without being repeated.
 
-7. **Write the entry's body.** `bump` leaves it empty on purpose. A boundary-crossing entry
+7. **Fix the candidate once it is ready to ship.** `version bump` only ever opens or escalates
+   one; nothing turns it into a release except `tools/wikitool version release`, which strips the
+   `-beta.N` suffix and closes the entry - see its row in `tools/CONTRACT.md`. That is also the
+   point to pass a summarising `--title` if the candidate collected several bump titles along the
+   way; without one, the heading simply keeps whichever bump last set it.
+
+8. **Write the entry's body.** `bump` leaves it empty on purpose. A boundary-crossing entry
    earns a paragraph that says *why this is breaking* - it is the one thing a future reader
    cannot reconstruct from the diff, and it is what the next session in this position will read
    instead of guessing.

instructions/gates.md

@@ -103,6 +103,26 @@ The setup this gate exists for - a private instance that takes stack updates fro
 upstream - is [private-instance.md](private-instance.md). Step 4 there arms it, deliberately
 *before* the first `publish`: added afterwards it leaves open exactly the window it closes.
 
+### Mass-Update Gate blind spot: `upstream merge`
+
+`upstream merge` (a private instance taking a stack update - see
+[private-instance.md](private-instance.md)) can update or delete dozens of stack-owned paths in
+one commit, and the Mass-Update Gate does not see any of it. The gate counts *working-tree*
+changes before `publish` stages them; by the time `upstream merge` commits, the change is
+already history, and the commit it made is not what a later `publish` would be staging - that
+publish sees only whatever this session adds on top. A merge touching 200 files therefore goes
+out ungated the moment it is pushed.
+
+This is not a hole to patch by making `upstream merge` route through the gate: the gate's
+question ("is this too much to publish?") does not apply to a change that only ever touches
+stack-owned paths that are, by definition, not this instance's own content. The check that
+actually matters here is `upstream merge`'s own postcheck - it re-verifies the merge commit
+against `upstream verify`'s logic immediately after committing, and exits 1 with the offending
+paths if anything landed outside a stack-owned one. **The merge commit is deliberately left in
+place** rather than reverted: it exists, a human has to look at it, and a command that quietly
+repaired its own mistake would hide the one event worth seeing. That postcheck is the safeguard
+for this command, not the Mass-Update Gate.
+
 ## Iteration Budget Gate and loop-breaker
 
 Every `wikitool` call is counted per session. Calls are refused past **60 in a session**, or

instructions/kb-profiles.md

@@ -68,7 +68,7 @@ stack's hardcoded behaviour until the conventions file existed.
 |---|---|
 | `language:` | `de` |
 | `sections:` | `Beziehungen` / `Siehe auch` / `Fußnoten` |
-| Naming | Human-readable titles with spaces; singular for entities; `adr-NNN-` for decisions; `X vs Y` for comparisons |
+| Naming | Human-readable titles with spaces; singular for entities; a decision named like any other concept, no `adr-NNN-` prefix; `X vs Y` for comparisons |
 | Tone | Wikipedia register, with a German buzzword and filler list |
 | Relationship labels | `hängt ab von` · `verwendet` · `implementiert` · `erweitert` · `ersetzt` · `steht in Konflikt mit` · `benötigt` · `erzeugt` · `konsumiert` · `besitzt` · `pflegt` · `läuft auf` · `verwandt mit` |
 | Confidence rubric | 0.5 base, +0.2 per supporting source (max +0.6), recency and source-quality bonuses; hedge with "möglicherweise"/"kann" below 0.6, "unsicher"/"unbestätigt" below 0.4 |

instructions/link-taxonomy.md

@@ -40,9 +40,18 @@ edge merely to mirror the first one.** The inbound view is rendered from the gra
 `index rebuild` and `search`, so a reader landing on the target sees what points at it whether
 or not anyone wrote a second edge.
 
-That is why most labels below have no inverse. Only two pairs do, because in each the reverse
+That is why most labels below have no inverse. Only three pairs do, because in each the reverse
 direction is a genuine primary statement someone would write on its own: `depends-on` /
-`required-by` and `runs-on` / `hosts`.
+`required-by`, `runs-on` / `hosts`, and `composition` / `part-of`.
+
+The third was added after the 4.0.0 migration, from measurement rather than from the desk. A
+parent-child structure - a tier list and its tiers, a spectrum and its levels - produces the
+question on nearly every page: the parent writes `composition`, and the child then reaches for
+either `part-of` or `see-also`. The migration run answered `see-also`, on the reading that
+`part-of` would be a mirror, and left sixteen edges saying "these two are related" about a
+relationship the catalogue already had a word for. It is not a mirror: the parent's sentence
+lists its parts, the child's names the whole it belongs to, and a reader landing on the child
+needs the second one.
 
 ## When to run
 
@@ -129,6 +138,13 @@ Inference and comparison between ideas.
 | `composition` | is composed of the target |
 | `part-of` | is a component of the target |
 
+`composition` / `part-of` is the third **inverse pair**, alongside `depends-on` / `required-by`
+and `runs-on` / `hosts` in the operational register. Being a pair does not make the second edge
+obligatory - direction is still authored - it settles *which label* the second edge takes when
+someone does write it. The child of a `composition` writes `part-of`, not `see-also`: what it
+is a component of is a primary statement about the child, and `see-also` says strictly less
+about the same fact.
+
 `grounds` / `rests-on` is a genuine pair and both directions are primary statements; they are
 listed separately rather than as inverses because either page may legitimately carry only its
 own side.

instructions/migrations/4.0.0-link-taxonomy.md

@@ -36,8 +36,9 @@ you know the run is finished.
 **Nothing breaks while it is outstanding.** Unlabelled edges and undelimited regions are read,
 not rejected: `links.py` treats a bare title as an edge whose label is not declared yet, and
 `provenance.split_cite_block` falls back to the pre-marker layout. That is deliberate - a corpus
-has to stay readable while it is being converted - and it is why the two lint findings are
+has to stay readable while it is being converted - and it is why the two lint findings stay
-advisory until step 6 promotes them.
+advisory for as long as `kb_version` is below 4.0.0, which is exactly as long as this document
+is outstanding.
 
 ## Steps
 
@@ -102,7 +103,7 @@ advisory until step 6 promotes them.
    is otherwise silent: the region becomes ordinary prose and the next write appends a second
    one beside it.
 
-6. **Record it, then tighten the checks:**
+6. **Record it. The checks tighten themselves:**
 
    ```bash
    tools/wikitool lint          # unlabelled_edges and unauthorised_labels must be 0
@@ -110,8 +111,14 @@ advisory until step 6 promotes them.
    ```
 
    Only once `lint` reports zero of both is the run finished. The two findings are advisory
-   during the window and become hard errors afterwards - the same path
+   while `kb_version` is below 4.0.0 and hard from the moment `migrate done` records it -
-   `legacy_citation_markers` took after the citation migration.
+   nothing to flip by hand, and no window in which a half-converted corpus is refused by the
+   check that is measuring its progress.
+
+   Do not record the migration to silence the findings. The promotion is what makes the run
+   stick: after it, a bare title in `related:` is a hard error rather than a page still
+   waiting, so a corpus recorded early fails its next lint instead of quietly keeping the old
+   shape.
 
 ## How to tell a migrated page from an unmigrated one
 

instructions/private-instance.md

@@ -108,69 +108,53 @@ So the merge has to be scoped. That is the procedure below, and it is not option
 
 ## Taking a stack update
 
-Take the machinery, never the content. The merge is held open, the content stages are forced
+```bash
-back to your own state, and only then does it close.
+tools/wikitool upstream merge --remote upstream --branch main
+```
 
-**Three files under those stages are machinery, not content**, and forcing them back is how an
+Take the machinery, never the content. This is the command form of the same idea a hand-rolled
-upstream contract change gets silently discarded:
+merge would need: hold the merge open, force the content stages back to your own state, restore
+only the paths that are machinery, and only then let it close. Which paths those are is not a
+short literal list any more (see below) - it is `chemenu.ownership.is_stack_owned`, the same
+predicate `dist_cmd.py`'s export reads, so a stack change that adds a new machinery path under a
+content stage is recognised automatically rather than needing this document edited first.
 
-| Path | Why it must take the upstream side |
+**What counts as machinery under a content stage**, for readers who want the shape rather than
+the code:
+
+| Path | Why it takes the upstream side |
 |---|---|
-| `kb/CONTRACT.md` | The stack's own knowledge-layer contract. Every rule in it is enforced by `wikitool`; an instance never edits it |
+| `<stage>/CONTRACT.md` (`kb/CONTRACT.md`, `raw/CONTRACT.md`, `work/CONTRACT.md`, `reports/CONTRACT.md`) | The stack's own stage contract. Every rule in it is enforced by `wikitool`; an instance never edits it |
-| `kb/CONVENTIONS.md.template` | The template your `kb/CONVENTIONS.md` was filled from. The filled file is yours; the template is the stack's |
+| any `*.template` under a content stage (`kb/CONVENTIONS.md.template`, each `kb/<name>/COLLECTION.md.template`, and any later one) | The template your filled file was adopted from. The filled file is yours; the template is the stack's |
-| `raw/CONTRACT.md` | The raw stage's contract, for the same reason as the first row |
 
-Everything else under `kb/` and `raw/` is yours, `kb/CONVENTIONS.md` and each
+Everything else under `kb/`, `raw/`, `work/` and `reports/` is yours, `kb/CONVENTIONS.md` and
-`kb/<name>/COLLECTION.md` included - they bind your corpus, and they are exactly what the
+each `kb/<name>/COLLECTION.md` included - they bind your corpus, and they are exactly what
-restore below is protecting.
+`upstream merge` protects.
 
-```bash
+**Your local, uncommitted-by-design files under those stages survive.** Forcing a content stage
-BEFORE=$(git rev-parse HEAD)
+back to your own state removes only what git tracks, never the directory wholesale - which
-git fetch upstream
+matters because `reports/` is gitignored apart from its contract, so it holds data that is in no
+commit and cannot be recomputed: the telemetry traces `eval score` reads, saved eval reports,
+past lint reports. A merge has no business touching any of it, and does not.
 
-# --no-commit holds the merge open; it may report conflicts under kb/ or raw/,
+The command itself checks its own result the same way `upstream verify` would, immediately
-# which the next four lines are about to make irrelevant.
+after committing, and refuses loudly - without rolling the commit back - if anything landed
-git merge --no-commit --no-ff upstream/main || true
+outside a stack-owned path. A refusal there is a bug report, not something to work around by
-
+hand; see [tools/CONTRACT.md](../tools/CONTRACT.md) for the full error contract, including what
-# Whatever the merge did to the content stages, undo it. HEAD is still your
+a real conflict in `tools/`/`types/`/`instructions/` leaves behind.
-# pre-merge commit while the merge is open, so this restores exactly your side.
-git rm -rq --cached --ignore-unmatch kb raw
-rm -rf kb raw
-git checkout HEAD -- kb raw
-
-# ...then take the upstream side back for the machinery that lives among it.
-# MERGE_HEAD is still resolvable while the merge is open.
-git checkout MERGE_HEAD -- kb/CONTRACT.md kb/CONVENTIONS.md.template raw/CONTRACT.md
-
-git commit --no-edit
-```
-
-Then **check that it worked**, rather than trusting that it did. The same three paths are
-excluded here, spelled out rather than held in a variable so that the check can be read on its
-own and copied on its own:
-
-```bash
-git diff --name-only "$BEFORE" HEAD -- kb raw \
-  | grep -vE '^(kb/CONTRACT\.md|kb/CONVENTIONS\.md\.template|raw/CONTRACT\.md)$'
-```
-
-Must print nothing.
-
-An empty result is the proof that the update touched machinery only. A non-empty one means a
-path slipped through - inspect it before going further.
-
-**The exclusion is not cosmetic.** Without it the check reports *empty* for an update that just
-ate a `kb/CONTRACT.md` change - it would be confirming the failure it exists to catch. If one of
-the three paths does not appear in the diff at all, that is fine: it means upstream did not
-touch it.
 
 Then, as after any stack change: `doctor`, `docs verify`, `instructions verify`, `migrate status`,
 `lint`. A `migrate status` with outstanding links means the update crossed a compatibility
 boundary - follow [migrate-corpus.md](migrate-corpus.md) before doing anything else.
 
-**Why not just `git merge upstream/main`?** Because of the table above: a page the upstream
+**Why not just `git merge upstream/main`?** A page the upstream *adds* arrives with no conflict
-*adds* arrives with no conflict and no message. You would find out when `lint` starts reporting
+and no message under a plain merge - measured in the table further up this document. You would
-pages you never wrote - if you noticed at all.
+find out when `lint` starts reporting pages you never wrote, if you noticed at all. `upstream
+merge` closes exactly that gap: the content stages never see the upstream's version at all.
+
+**Checking a merge you resolved by hand instead** (or auditing a past one): `tools/wikitool
+upstream verify --since <rev-before> --until <rev-after>` runs the same check `upstream merge`
+runs on itself, without doing the merge.
 
 ## Where stack development happens
 
@@ -186,17 +170,21 @@ merge above. Nothing is lost by the detour: the fix has to pass that CI either w
 
 ## Decision points
 
-- **Merge conflict in `kb/` or `raw/`?** Expected, and already handled: the update procedure
+- **Merge conflict in `kb/`, `raw/`, `work/` or `reports/`?** Expected, and already handled:
-  above overwrites those stages with your own afterwards, so the conflict resolves itself.
+  `upstream merge` overwrites those stages with your own afterwards, so the conflict resolves
-  Never resolve one by hand with `git add -A` - that is exactly how the upstream version, which
+  itself. Never resolve one by hand with `git add -A` in a merge you are running yourself
-  git left sitting in your working tree, gets committed into your instance.
+  instead - that is exactly how the upstream version, which git left sitting in your working
-- **`git diff` after the merge shows something under `kb/` or `raw/`?** Stop - unless it is one
+  tree, gets committed into your instance.
-  of the three machinery paths the check excludes, which is the update working as intended. For
+- **`upstream merge` exits 1 after committing?** Read the message: its own postcheck found
-  anything else the scoping step did not take: do not publish; find out which path came through
+  content outside a stack-owned path in the commit it just made. The commit is **not** rolled
-  and where from.
+  back - inspect it (`git show`, or `tools/wikitool upstream verify --since <before> --until
+  HEAD`) and decide by hand whether to revert it, fix forward, or report it as a stack bug. This
+  should not happen; if it does, `chemenu.ownership.is_stack_owned` disagreed with itself between
+  the restore and the check, which is exactly what the shared predicate is meant to prevent.
 - **Conflict in `tools/`, `types/` or `instructions/`?** You changed the stack locally, which
-  step "Where stack development happens" says not to do. Take the upstream side and re-file the
+  step "Where stack development happens" says not to do. `upstream merge` leaves the merge open
-  change as an issue there.
+  rather than guessing - take the upstream side for the named paths and re-file the change as an
+  issue there, or resolve deliberately and finish the commit yourself.
 - **...but you changed how *your pages* are written?** That is not a stack change and the rule
   above does not apply to it. Language, section headings, naming forms, tone, relationship
   labels and the confidence rubric live in `kb/CONVENTIONS.md`, and each collection's authoring

kb/CONVENTIONS.md

@@ -62,7 +62,8 @@ There is no `## Siehe auch` region any more. It was the reciprocal half of a bid
 - Human-readable titles with spaces: `Hybrid Search.md`, `Gitea Actions.md` - not kebab-case.
 - Singular for entities: `ha-core.md`, not `ha-cores.md`.
 - Comparison pages read as a comparison: `Go vs Rust.md`.
-- ADRs are prefixed: `adr-001-use-go-modules.md`.
+- A decision (`concept_type: decision`) is named like any other concept - no `adr-NNN-` prefix.
+  See [kb/concepts/COLLECTION.md § Decisions](concepts/COLLECTION.md#decisions).
 - Prefer readability over convention when the two conflict.
 
 What to name a thing: projects use their repository or common name; systems a descriptive

kb/comparisons/amd-pstate vs acpi-cpufreq.md

@@ -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]]
-

kb/concepts/Ambient Environment Dependency.md

@@ -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 -->

kb/concepts/Anti-Cramming Heuristic.md

@@ -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 -->

kb/concepts/Audit Trail.md

@@ -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 -->

kb/concepts/BM25.md

@@ -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 -->

kb/concepts/Bulk Operations.md

@@ -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 -->

kb/concepts/CI Integration.md

@@ -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 -->

kb/concepts/COLLECTION.md

@@ -27,19 +27,27 @@ tone, relationship labels, the confidence rubric. Neither is restated here.
 
 `concept` (`tools/wikitool types describe concept`).
 
-## Decisions and ADRs
+## Decisions
 
-An architectural decision is a concept page, prefixed as
+An architectural decision is an ordinary concept page with `concept_type: decision`
-[kb/CONVENTIONS.md § Naming](../CONVENTIONS.md#naming) says. It records:
+(`tools/wikitool types describe concept`) - not a separate format, and not a separate location.
+There is no `adr-NNN-`-prefixed filename and no dedicated directory: naming follows
+[kb/CONVENTIONS.md § Naming](../CONVENTIONS.md#naming) like every other concept, and the page
+lives in `kb/concepts/` like every other concept.
 
-- **Context** - what forced a decision.
+The body is organic prose under this collection's usual sections, not a fixed template. What it
-- **Decision** - what was chosen.
+still has to carry: what was decided, what forced the decision, what it costs (not only what it
-- **Consequences** - what this costs, not only what it buys.
+buys), and a link to every entity the decision affects. A `**Status:**` line is optional - most
-- **Status** - proposed / accepted / deprecated / superseded.
+decision pages in this instance carry none, because the page's own prose already says whether the
-- Links to every entity the decision affects.
+decision stands.
 
-A superseded ADR is never deleted or rewritten. The new one declares `supersedes` pointing at
+A decision superseded by a later one is never deleted or rewritten. The new page declares
-it; the old one needs no edge back, because its inbound view renders the replacement.
+`supersedes` pointing at it; the old one needs no edge back, because its inbound view renders the
+replacement.
+
+`concept_type: decision` is also the one subtype [kb/CONTRACT.md](../CONTRACT.md)'s confidence
+machinery treats differently: `confidence decay` skips it structurally, because elapsed time does
+not falsify a decision - only a later decision superseding it does.
 
 ## Authorised labels
 

kb/concepts/CPPC.md

@@ -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 -->

kb/concepts/Checkpoint Audit.md

@@ -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 -->

kb/concepts/Claude Code Auto Mode.md

@@ -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 -->

kb/concepts/Command Round-Trip Integrity.md

@@ -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 -->

kb/concepts/Confidence Scoring.md

@@ -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 -->

kb/concepts/Consolidation Tiers.md

@@ -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 -->

kb/concepts/Content Quality Control.md

@@ -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 -->

kb/concepts/Context Isolation.md

@@ -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 -->

kb/concepts/Contradiction Resolution.md

@@ -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 -->

kb/concepts/Cross-platform Agent Skills.md

@@ -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 -->

kb/concepts/Crystallization.md

@@ -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 -->

kb/concepts/Delete Rather Than Anonymize.md

@@ -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 -->

kb/concepts/Denylist over Allowlist.md

@@ -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 -->

kb/concepts/Detect-Repair Asymmetry.md

@@ -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 -->

kb/concepts/Diff-Reviewable Agent Edits.md

@@ -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 -->

kb/concepts/Dual Licensing by File Plan.md

@@ -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 -->

kb/concepts/Entity Extraction.md

@@ -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 -->

kb/concepts/Episodic Memory.md

@@ -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 -->

kb/concepts/Event-Driven Automation.md

@@ -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 -->

kb/concepts/Filter on Ingest.md

@@ -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 -->

kb/concepts/Forgetting.md

@@ -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 -->

kb/concepts/Graph Traversal.md

@@ -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 -->

kb/concepts/Green Suite Blind Spot.md

@@ -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 -->

kb/concepts/Hooks.md

@@ -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 -->

kb/concepts/Hybrid Search.md

@@ -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 -->

kb/concepts/INDEX.md

@@ -41,7 +41,7 @@
 | [[Hybrid Search]] | architecture | Multimodale Suche, die BM25-Schlüsselwortabgleich, Vektor-Embeddings und Graph Traversal verbindet, um Wissensabruf im Wiki skalierbar zu machen. | 2026-08-29 |
 | [[Implementation Spectrum]] | architecture | Modularer Einführungspfad für die Funktionen von LLM Wiki v2, vom minimal tragfähigen Wiki bis zur vollen Umsetzung mit Automatisierung und Governance. | 2026-08-29 |
 | [[Index Scaling]] | workflow | Skalierungsregeln für Indexseiten: Tabellenabschnitte ab 50 Einträgen teilen, ab 200 Seiten _meta/topic-map.md anlegen | 2026-08-29 |
-| [[Issue Label Scheme]] | decision | 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 |

kb/concepts/Implementation Spectrum.md

@@ -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 -->

kb/concepts/Index Scaling.md

@@ -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 -->

kb/concepts/Issue Label Scheme.md

@@ -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 -->

kb/concepts/Iteration and Cost Limits.md

@@ -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 -->

kb/concepts/KB Migration.md

@@ -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 -->

kb/concepts/KB Stack Versioning.md

@@ -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 -->

kb/concepts/Knowledge Compounding.md

@@ -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 -->

kb/concepts/Knowledge Graph.md

@@ -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 -->

kb/concepts/LLM Wiki Pattern.md

@@ -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 -->

kb/concepts/Lint Workflow.md

@@ -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 -->

kb/concepts/MCP-Leseserver.md

@@ -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 -->

kb/concepts/Mass-Update Gate.md

@@ -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 -->

kb/concepts/Memory Lifecycle.md

@@ -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 -->

kb/concepts/Mesh Sync.md

@@ -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 -->

kb/concepts/Modbus.md

@@ -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 -->

kb/concepts/Multi-Agent Collaboration.md

@@ -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 -->

kb/concepts/Naming Convention Conflict.md

@@ -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 -->

kb/concepts/OKF Compatibility.md

@@ -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 -->

kb/concepts/Optional Instance Context File.md

@@ -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 -->

kb/concepts/Personalization Plane.md

@@ -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 -->

kb/concepts/Privacy and Governance.md

@@ -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 -->

kb/concepts/Procedural Memory.md

@@ -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 -->

kb/concepts/Publish-Remote Gate.md

@@ -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 -->

kb/concepts/Quality Scoring.md

@@ -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 -->

kb/concepts/Quality and Self-Correction.md

@@ -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 -->

kb/concepts/RAG.md

@@ -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 -->

kb/concepts/Reciprocal Rank Fusion.md

@@ -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 -->

kb/concepts/SSD TRIM.md

@@ -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 -->

kb/concepts/Scale Ceiling.md

@@ -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 -->

kb/concepts/Self-Healing.md

@@ -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 -->

kb/concepts/Semantic Lint Automation.md

@@ -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 -->

kb/concepts/Semantic Memory.md

@@ -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 -->

kb/concepts/Session Orientation.md

@@ -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 -->

kb/concepts/Shared vs Private.md

@@ -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 -->

kb/concepts/Split Merge Reclassify.md

@@ -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 -->

kb/concepts/Split Threshold.md

@@ -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 -->

kb/concepts/Structural Enforcement over Documented Rule.md

@@ -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 -->

kb/concepts/Stub Threshold.md

@@ -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 -->

kb/concepts/Supersession.md

@@ -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 -->

kb/concepts/Three-Layer Architecture.md

@@ -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 -->

kb/concepts/Token Economics.md

@@ -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 -->

kb/concepts/Typed Relationships.md

@@ -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 -->