feat: Versionskandidat statt Bump-pro-Release - VERSION traegt -beta.N, version release fixiert (4.4.0, #42)

Files changed:
- .gitea/workflows/release.yml
- AGENTS.md
- CHANGES.md
- DEVELOPMENT.md
- README.md
- VERSION
- docs/version-model.md
- instructions/dev/version-parts.md
- tools/CONTRACT.md
- tools/chemenu/commands/dist_cmd.py
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/doctor.py
- tools/chemenu/commands/migrate_cmd.py
- tools/chemenu/commands/version_cmd.py
- tools/chemenu/kb_state.py
- tools/chemenu/tests/test_dist_cmd.py
- tools/chemenu/tests/test_docs_verify.py
- tools/chemenu/tests/test_doctor.py
- tools/chemenu/tests/test_migrate_cmd.py
- tools/chemenu/tests/test_version_cmd.py
- tools/chemenu/version.py

.gitea/workflows/ci.yml

@@ -101,6 +101,10 @@ jobs:
           # instance does not measure this suite. Installed beside pytest for
           # the same reason pytest itself is.
           tools/.venv/bin/pip install --quiet pytest pytest-cov
+          # The MCP server's dependency is optional for an instance but not for
+          # CI: its tests skip without it, and a skipped golden test is exactly
+          # how the server's output and the CLI's would drift apart unnoticed.
+          tools/.venv/bin/pip install --quiet -r tools/requirements-mcp.txt
 
       - name: Tests
         # Not run with WIKI_TRACE=0: two telemetry tests assert that a trace is
@@ -217,6 +221,16 @@ jobs:
           for personal in USER SOUL; do
             grep -v 'wikitool:template-unfilled' "$personal.md.template" > "$personal.md"
           done
+          # The authoring conventions ride the same split one directory down,
+          # and are stubbed the same way: what is under test is that the export
+          # carries the templates and that `doctor`/`docs verify` accept an
+          # adopted one, not what a person would write into them. The collection
+          # contracts are adopted verbatim - the shipped text is a working
+          # default, unlike a personalization file.
+          grep -v 'wikitool:template-unfilled' kb/CONVENTIONS.md.template > kb/CONVENTIONS.md
+          for template in kb/*/COLLECTION.md.template types/*.template; do
+            cp "$template" "${template%.template}"
+          done
           python3 -m venv tools/.venv
           tools/.venv/bin/pip install --quiet -r tools/requirements.txt
           tools/wikitool instructions sync

.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 }}

.gitignore

@@ -110,6 +110,13 @@ npm-debug.log*
 # `dist export`; this anchored pattern deliberately does not match it.
 /ENVIRONMENT.md
 
+# Publish-Remote Gate allowlist (see instructions/gates.md). Names the push
+# URLs *this* checkout may publish to, so it is per-checkout for exactly the
+# reason ENVIRONMENT.md above is: a committed copy would tell a private clone
+# that the public upstream is a legitimate target for its own content. Absent
+# means unrestricted; `doctor` reports which.
+/.wikitool-remotes.json
+
 # Coverage output from `pytest --cov` (see .gitea/workflows/ci.yml). Derived,
 # like reports/: recomputable from any commit, and `publish` runs `git add -A`,
 # so an unignored htmlcov/ would commit itself on the next content publish.

.wikitool-kb.json

@@ -1,5 +1,16 @@
 {
   "schema": 1,
-  "kb_version": "1.0.0",
+  "kb_version": "4.0.0",
-  "applied": []
+  "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

@@ -20,7 +20,9 @@ tools/wikitool instructions sync
 Full procedure, including the tool environment: [instructions/bootstrap.md](instructions/bootstrap.md).
 Setting up a brand-new, empty instance instead of cloning this one: `tools/wikitool dist export`
 and [instructions/setup-instance.md](instructions/setup-instance.md) - see
-[INSTALL.md](INSTALL.md).
+[INSTALL.md](INSTALL.md). A *private* instance that keeps taking stack updates from a public
+upstream is a third shape, with a safeguard the other two do not need:
+[instructions/private-instance.md](instructions/private-instance.md).
 
 ## Invariants
 
@@ -69,16 +71,19 @@ 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 |
 | `SOUL.md` | Agents | Always, every session |
 | `ENVIRONMENT.md` | Agents | Every session, **if it exists** - the one optional file in this table. Not committed: it describes one checkout, not the repo |
 | `<stage>/CONTRACT.md` | Agents | When writing in that stage |
-| `kb/<collection>/COLLECTION.md` | Agents | When writing in that collection |
+| `kb/CONVENTIONS.md` | Agents | When writing any page - it holds what *this* instance decided about authoring (language, section headings, naming, tone, relationship labels, confidence rubric), where `kb/CONTRACT.md` holds what the stack enforces. Instance-owned: a distribution ships only the `.template` |
+| `kb/<collection>/COLLECTION.md` | Agents | When writing in that collection. Instance-owned in the same way, and declares in frontmatter which profile it adopted |
 | `instructions/<name>.md` | Agents | By link, or on explicit request |
 | `instructions/<name>/SKILL.md` | Agents | By the harness, once published |
-| `types/<name>.md` | Agents + validator | Via `tools/wikitool types describe` |
+| `types/<name>.md` | Agents + validator | Via `tools/wikitool types describe`. Split by `root:`: a page type-spec (`root: kb`) belongs to the instance and ships as `.template`; one describing a stack artifact ships verbatim |
+| `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
@@ -86,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
@@ -102,6 +117,16 @@ and `SOUL.md.template`; the Personalization step of
 writes the real files. `tools/wikitool doctor` FAILs on a missing one, and on one still
 carrying the template's sentinel.
 
+The same `.template` split runs one directory down, for authoring rather than for voice.
+`kb/CONVENTIONS.md` and each `kb/<name>/COLLECTION.md` bind every page and belong to the
+instance, so a distribution ships them as templates and the KB-language step of
+[instructions/setup-instance.md](instructions/setup-instance.md) fills them in, out of a
+catalogue of ready-made profiles it routes to; `doctor` FAILs on a missing or unfilled
+`kb/CONVENTIONS.md` the same way.
+
+Unlike `USER.md`, these two *are* a source of rules: they are as binding as `kb/CONTRACT.md`.
+What differs is ownership, not authority.
+
 ## Environment
 
 `ENVIRONMENT.md` records what *this checkout* works through - harness, published skills,
@@ -132,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:
 
@@ -140,15 +166,17 @@ Alongside it, not part of it: `instructions/` (what agents are told to do) and t
 |-------|----------|--------|
 | `raw/` | [raw/CONTRACT.md](raw/CONTRACT.md) | Immutability, directory routing, untrusted-content rule |
 | `types/` | [types/type-spec.md](types/type-spec.md) | Type-spec anatomy, placement, adding a type, template variables |
-| `kb/` | [kb/CONTRACT.md](kb/CONTRACT.md) | Collections, naming, tone, linking, provenance, confidence |
+| `kb/` | [kb/CONTRACT.md](kb/CONTRACT.md) + `kb/CONVENTIONS.md` | What the stack enforces about a page (collections, linking, provenance, confidence machinery), and beside it what this instance decided (language, naming, tone, labels, rubric) |
 | `reports/` | [reports/CONTRACT.md](reports/CONTRACT.md) | Why reports and traces are generated, gitignored, and carried into `kb/log.md` |
 | `work/` | [work/CONTRACT.md](work/CONTRACT.md) | Workshop runs: run keys, required files, why they are tracked, how a run closes |
 | `tools/` | [tools/CONTRACT.md](tools/CONTRACT.md) | Full command reference, per-command error contracts, maintenance schedule |
 | `instructions/` | [instructions/CONTRACT.md](instructions/CONTRACT.md) | Instruction vs. skill, publishing, writing standard |
 
 **By collection** - then read the contract for the collection you are writing in.
-[kb/CONTRACT.md](kb/CONTRACT.md) routes between `kb/entities/`, `kb/concepts/`, `kb/sources/`
+[kb/CONTRACT.md](kb/CONTRACT.md) routes between this instance's collections and holds the rules
-and `kb/comparisons/`, and holds the rules they share.
+the stack enforces across all of them; `kb/CONVENTIONS.md` holds the ones this instance chose.
+Both bind. The difference is who may change the sentence - which is also why a distribution
+ships the first verbatim and the second only as a `.template`.
 
 **By task** - skills hold the step-by-step procedures. Sources live in `instructions/<name>/`:
 
@@ -177,16 +205,19 @@ tools/wikitool search --field entity_type=system --field 'confidence<0.6'
 
 ## Gates
 
-Two limits are enforced in code rather than by instruction, because a prompt-level limit is
+Three limits are enforced in code rather than by instruction, because a prompt-level limit is
 one an agent can talk itself past.
 
 - **Mass-Update Gate.** `publish` exits **42** on a change touching too many files, printing
   the file list and the `--confirm <token>` line that publishes it once the user approves. The
   threshold and the rule live in [instructions/gates.md](instructions/gates.md).
+- **Publish-Remote Gate.** `publish` exits **42** on a push to a URL this checkout has not
+  declared in `.wikitool-remotes.json`. It has no token and no flag: the way past it is a
+  deliberate edit by the user, never by an agent.
 - **Iteration Budget Gate / Loop-Breaker.** Past 60 `wikitool` calls in a session, or after 3
   identical calls in a row, further calls are refused.
 
-Both refuse with exit 1. **Do not retry, and do not open the gate.** Stop, summarize the
+The last refuses with exit 1. **Do not retry, and do not open a gate.** Stop, summarize the
 situation to the user, and get explicit approval. The full procedure - including why
 `budget reset` is not the escape hatch - is [instructions/gates.md](instructions/gates.md).
 
@@ -245,3 +276,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.

DEVELOPMENT.md

@@ -0,0 +1,99 @@
+# 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.
+
+## Verify-Befehle im Überblick
+
+| Befehl | Prüft |
+|---|---|
+| `cd tools && .venv/bin/python -m pytest -q` | Die gesamte Testsuite, hermetisch gegen eine leere Maschine (siehe `instructions/dev/testing-conventions.md`) |
+| `tools/wikitool docs verify` | CLI-Kommandotabelle, Contract-Präsenz, Type-Drift, `.gitignore`-Kanarienvögel, `VERSION`/`CHANGES.md`-Übereinstimmung, Grenzübertritts-Dokumentation |
+| `tools/wikitool instructions verify` | Jede Instruction und jeder Skill unter `instructions/`, verwaiste Dateien, `instructions/dev/`-Referenzen von außerhalb |
+
+Die volle Kommandoreferenz inklusive Fehlerkontrakt: [tools/CONTRACT.md](tools/CONTRACT.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-MCP.md

@@ -0,0 +1,239 @@
+# MCP-Leseserver installieren
+
+Dieses Dokument richtet sich an Menschen. Es beschreibt, wie der MCP-Leseserver eines Chemenu-
+Wikis lokal läuft, wie ein Client ihn einbindet, und wie er hinter einer Authentifizierung
+erreichbar wird. Der agent-seitige Betriebsablauf steht in
+[instructions/mcp-read-server.md](instructions/mcp-read-server.md); die vollständige
+Kommandoreferenz in [tools/CONTRACT.md](tools/CONTRACT.md).
+
+**Was der Server ist.** Ein zweiter Konsument desselben Kerns, nicht ein zweites Programm. CLI
+und Server rufen dieselben Funktionen auf; ein Golden-Test hält ihre Ausgaben gegeneinander.
+Was `tools/wikitool search --json` liefert, liefert das MCP-Tool `search` auch — plus den
+Commit, aus dem die Antwort berechnet wurde.
+
+**Was er nicht ist.** Kein Schreibpfad. Es gibt kein Tool, das eine Seite anlegt, ändert oder
+publiziert — nicht weil eine Liste gefiltert wird, sondern weil der Server nichts unter
+`tools/chemenu/commands/` importiert. Die Funktionen sind aus diesem Prozess heraus nicht
+erreichbar.
+
+## Voraussetzungen
+
+- Eine funktionierende Instanz nach [INSTALL.md](INSTALL.md) — inklusive `tools/.venv` und
+  `ripgrep`
+- Python 3.11 oder neuer (wie die CLI)
+
+## Schritt 1: Abhängigkeit installieren
+
+Sie liegt bewusst nicht in `tools/requirements.txt`. Eine Instanz, die nur die CLI benutzt, soll
+dafür nicht pydantic, starlette, uvicorn und cryptography mitinstallieren müssen.
+
+```bash
+tools/.venv/bin/pip install -r tools/requirements-mcp.txt
+```
+
+## Schritt 2: Lokal starten (stdio)
+
+`stdio` ist der Weg zum Ausprobieren und für einen Client auf derselben Maschine: ein Prozess
+pro Konsument, lokal gestartet, kein Netzwerk.
+
+```bash
+WIKI_TRACE=0 tools/.venv/bin/python -m chemenu.mcp
+```
+
+Der Prozess spricht MCP über stdin/stdout und gibt für sich genommen nichts aus — das ist
+richtig so. Gestartet wird er normalerweise nicht von Hand, sondern vom Client (Schritt 3).
+
+**`WIKI_TRACE=0` ist nicht optional.** Telemetrie ist per Default an und schreibt nach
+`reports/telemetry/` im Repo. Der Server **verweigert den Start**, solange das so ist, statt
+still umzuleiten:
+
+```
+ERROR Telemetry is on and would write into the served checkout (...). Set WIKI_TRACE=0,
+or point WIKI_TRACE_DIR outside the corpus.
+```
+
+Beide Auswege sind gleichwertig: `WIKI_TRACE=0` schaltet ab, `WIKI_TRACE_DIR=/var/log/chemenu`
+lenkt um. Der Grund steht in Schritt 6 — der Sync darf `reports/` wegräumen.
+
+## Schritt 3: Einen Client einbinden
+
+Die Konfiguration folgt der üblichen MCP-Client-Form. Absolute Pfade, weil der Client kein
+Arbeitsverzeichnis erbt:
+
+```json
+{
+  "mcpServers": {
+    "chemenu": {
+      "command": "/pfad/zur/instanz/tools/.venv/bin/python",
+      "args": ["-m", "chemenu.mcp"],
+      "cwd": "/pfad/zur/instanz/tools",
+      "env": {
+        "WIKI_TRACE": "0",
+        "CHEMENU_ROOT": "/pfad/zur/instanz"
+      }
+    }
+  }
+}
+```
+
+`CHEMENU_ROOT` sagt, **welches** Wiki bedient wird. Ohne die Variable nimmt der Server den
+Checkout, in dem das Paket selbst liegt — für eine einzelne Instanz reicht das, aber wer mehrere
+Korpora hat, setzt sie besser immer.
+
+Danach kennt der Client fünf Werkzeuge:
+
+| Tool | Was es beantwortet |
+|---|---|
+| `search` | Seiten in `kb/` nach Text, nach Frontmatter (`confidence<0.6`, `tags~k8s`) oder beidem |
+| `types` | Welche Seitentypen dieses Wiki kennt |
+| `describe_type` | Der vollständige Vertrag eines Typs: Felder, Pflichtangaben, Enums |
+| `lint` | Strukturelle Befunde: kaputte Wikilinks, Waisen, Index-Drift, Schema-Lücken |
+| `status` | Momentaufnahme: Seitenzahl, Verteilung auf Collections, Befundzahlen |
+
+## Schritt 4: Ausgeliefert starten (streamable HTTP)
+
+Der Transport für den Betrieb, und der einzige, vor den sich ein Reverse Proxy setzen kann.
+
+```bash
+WIKI_TRACE=0 CHEMENU_ROOT=/srv/chemenu \
+  tools/.venv/bin/python -m chemenu.mcp \
+    --transport streamable-http --host 0.0.0.0 --port 8000
+```
+
+Der Endpunkt ist dann `http://<host>:8000/mcp`.
+
+`--host 0.0.0.0` ist bewusst nicht der Default. Ohne die Angabe bindet der Server auf Loopback,
+was lokal richtig und im Container falsch ist — dort muss der Proxy ihn erreichen können. Wer
+`0.0.0.0` setzt, muss also auch dafür sorgen, dass davor etwas steht (Schritt 5).
+
+`sse` wird nicht angeboten. Es ist der abgelöste Remote-Transport; jetzt darauf zu bauen
+verschiebt den Wechsel nur.
+
+## Schritt 5: Authentifizierung davor
+
+**Der Server authentifiziert nicht selbst, und das ist Absicht.** Nicht sauber
+authentifizierte Zugriffe sollen den Python-Prozess gar nicht erst erreichen. Die
+Authentifizierung ist eine Traefik-ForwardAuth-Middleware:
+
+> **<https://gitea.nehmer.net/torben/gitea-mcp-forward-auth>**
+
+Kurz, was sie tut: sie prüft `Authorization: Bearer <token>` gegen SHA-256-Hashes erlaubter
+Tokens, antwortet `200` bei gültigem und `401` bei fehlendem oder falschem Token, und hält
+`GET /healthz` immer offen. Klartext-Tokens liegen weder in der Konfiguration noch im Log — nur
+Hashes und ein kurzer Fingerprint. Konfiguriert wird sie über
+`AUTH_PROXY_TOKEN_HASHES_DIR` (ein Verzeichnis, eine Datei je Token-Hash — passend für ein
+Kubernetes-Secret-Volume) oder `AUTH_PROXY_TOKEN_HASHES` (kommagetrennte Liste). Einzelheiten,
+Referenzmanifeste und ein Testskript stehen im README dort.
+
+Einen Token-Hash erzeugen:
+
+```bash
+echo -n "mein-token" | sha256sum | awk '{print $1}'
+```
+
+**Rate Limiting gehört an dieselbe Stelle** — vor den Prozess, neben die Authentifizierung.
+Nicht in den Iteration Budget Gate: der begrenzt eine *Agenten-Session* am unbemerkten Iterieren
+über den Wiki-Zustand, weshalb Retrieval von ihm ausgenommen ist. Ihn als Rate Limiter zu
+benutzen würde ihn dazu verwässern.
+
+## Schritt 6: Den Korpus aktuell halten
+
+Der Server liest den Arbeitsbaum. Ein veralteter Checkout antwortet selbstbewusst falsch —
+deshalb trägt **jede Antwort den Commit**, aus dem sie berechnet wurde:
+
+```json
+{ "commit": "<40-stelliger SHA>", "as_of": "<ISO-8601, UTC>", "count": 3, "...": "..." }
+```
+
+Aktuell gehalten wird der Baum durch Polling, aus einem Timer neben dem Server:
+
+```bash
+git -C "$CHEMENU_ROOT" fetch --quiet origin && \
+  git -C "$CHEMENU_ROOT" reset --hard --quiet origin/main
+```
+
+Polling statt Webhook, weil es keinen eingehenden Endpunkt und keine Signaturprüfung braucht —
+eine kleinere Angriffsfläche als das, was es optimieren würde.
+
+`reset --hard` ist dabei tragend und keine Bequemlichkeit: der Korpus-Cache verwendet einen
+Parse wieder, solange der Commit gleich bleibt, und cacht einen **schmutzigen Baum überhaupt
+nicht**. Ein abgedrifteter Checkout antwortet also zwar richtig, parst aber bei jeder Anfrage
+neu — und stempelt jede Antwort mit `"commit": null`, weil sie keiner Revision entspricht.
+
+## Verifikation
+
+Läuft es? Der schnellste Test ohne Client — startet den Server über stdio, listet die Tools und
+stellt eine Frage:
+
+```bash
+cd tools && WIKI_TRACE=0 .venv/bin/python - <<'EOF'
+import asyncio, os
+from mcp import ClientSession, StdioServerParameters
+from mcp.client.stdio import stdio_client
+
+async def main():
+    params = StdioServerParameters(
+        command=".venv/bin/python", args=["-m", "chemenu.mcp"],
+        env={"WIKI_TRACE": "0", "PATH": os.environ["PATH"]},
+    )
+    async with stdio_client(params) as (r, w):
+        async with ClientSession(r, w) as s:
+            await s.initialize()
+            print("Tools:", [t.name for t in (await s.list_tools()).tools])
+            out = await s.call_tool("status", {})
+            d = getattr(out, "structuredContent", None) or out.structured_content
+            print("Seiten:", d["pages"], "| Commit:", d["commit"])
+
+asyncio.run(main())
+EOF
+```
+
+Erwartete Ausgabe, sinngemäß:
+
+```
+Tools: ['search', 'types', 'describe_type', 'lint', 'status']
+Seiten: 176 | Commit: 576df2cdddc96614a7e6641e562022d52112d411
+```
+
+Gegen die CLI gegenprüfen — beide müssen dieselbe Antwort geben:
+
+```bash
+tools/wikitool search "<begriff>" --json
+```
+
+## Troubleshooting
+
+**`ERROR Telemetry is on and would write into the served checkout`** — erwartetes Verhalten,
+kein Fehler in der Installation. `WIKI_TRACE=0` setzen oder `WIKI_TRACE_DIR` aus dem Korpus
+heraus zeigen lassen (Schritt 2).
+
+**`ModuleNotFoundError: No module named 'mcp'`** — Schritt 1 fehlt, oder der Client startet ein
+anderes Python als das der Instanz. Im Client den absoluten Pfad auf `tools/.venv/bin/python`
+setzen.
+
+**`"commit": null` in jeder Antwort** — der bediente Baum hat uncommittete Änderungen. Entweder
+läuft der Sync nicht, oder etwas schreibt in den Korpus, das dort nichts zu suchen hat. Der
+Server selbst schreibt nie; ein Test prüft das, indem er alle fünf Tools aufruft und Dateibaum,
+`HEAD` und `git status --porcelain` vorher/nachher vergleicht.
+
+**`commit` nennt eine alte Revision** — der Sync aus Schritt 6 läuft nicht.
+
+**Der Server antwortet anders als `wikitool`** — das ist ein Defekt, keine
+Konfigurationsdifferenz: beide gehen durch dieselben Funktionen, und ein Golden-Test hält sie
+zusammen. Zuerst prüfen, ob beide auf denselben Root zeigen; `CHEMENU_ROOT` ist leicht für einen
+von beiden gesetzt und für den anderen nicht.
+
+**Von außen nicht erreichbar** — ohne `--host 0.0.0.0` bindet der Server auf Loopback
+(Schritt 4). Wenn er dann erreichbar ist, aber jeder Aufruf `401` bekommt, arbeitet die
+Middleware aus Schritt 5 korrekt und das Token stimmt nicht.
+
+## Was hier bewusst nicht steht
+
+Deployment — Cluster, Ingress-Hosts, Secret-Store, FluxCD-Quelle. Das ist private Infrastruktur
+und dieses Repo ist öffentlich.
+
+Ein **Container-Image** für den Betrieb gibt es noch nicht; es ist als eigenes Vorhaben erfasst,
+mitsamt den Entscheidungen, die dafür noch offen sind (Korpus im Image oder als Volume, wer den
+Sync ausführt, Basis-Image, Healthcheck):
+<https://gitea.nehmer.net/torben/chemenu/issues/37>. Bis dahin ist der Weg oben — venv,
+`python -m chemenu.mcp`, Proxy davor — der vollständige.

INSTALL.md

@@ -1,10 +1,15 @@
 # Installation
 
-Dieses Dokument richtet sich an Menschen. Es gibt drei Wege: ein **Release herunterladen**
+Dieses Dokument richtet sich an Menschen. Es gibt vier Wege: ein **Release herunterladen**
-(der normale Weg zu einer neuen Instanz), eine Distribution **selbst exportieren**, oder
+(der normale Weg zu einer neuen Instanz), eine Distribution **selbst exportieren**, **dieses
-**dieses Repo klonen** (Torbens persönliche Wiki, samt Inhalt). Der agent-seitige Ablauf steckt
+Repo klonen** (Testbett und Demo, samt Beispielkorpus), oder eine **private Instanz mit diesem
-in `instructions/`; hier stehen nur die menschlichen Teile - für die vollständige
+Repo als Upstream** aufsetzen. Der agent-seitige Ablauf steckt in `instructions/`; hier stehen
-Kommandoreferenz siehe [tools/CONTRACT.md](tools/CONTRACT.md).
+nur die menschlichen Teile - für die vollständige Kommandoreferenz siehe
+[tools/CONTRACT.md](tools/CONTRACT.md).
+
+Den optionalen **MCP-Leseserver** installiert und betreibt
+[INSTALL-MCP.md](INSTALL-MCP.md): derselbe Korpus, lesend, für einen Konsumenten, der kein
+Terminal auf dieser Maschine ist.
 
 ## Voraussetzungen
 
@@ -16,19 +21,22 @@ Kommandoreferenz siehe [tools/CONTRACT.md](tools/CONTRACT.md).
 ## Weg A: Release herunterladen
 
 Der kürzeste Weg zu einer eigenen Instanz - kein Checkout dieses Repos nötig. Jedes Release
-trägt genau einen `dist export`-Baum plus eine Prüfsumme. Das Repo ist derzeit privat, der
+trägt genau einen `dist export`-Baum plus eine Prüfsumme. Das Repo ist öffentlich, der Download
-Download braucht also ein Gitea-Token mit Lesezugriff (siehe
+braucht also weder Konto noch Token:
-[Konfiguration](#konfiguration)):
 
 ```bash
 BASE=https://gitea.nehmer.net/torben/chemenu/releases/download/v<version>
-curl -LO -H "Authorization: token $WIKITOOL_UPDATE_TOKEN" $BASE/chemenu-stack-<version>.tar.gz
+curl -LO $BASE/chemenu-stack-<version>.tar.gz
-curl -LO -H "Authorization: token $WIKITOOL_UPDATE_TOKEN" $BASE/chemenu-stack-<version>.tar.gz.sha256
+curl -LO $BASE/chemenu-stack-<version>.tar.gz.sha256
 sha256sum -c chemenu-stack-<version>.tar.gz.sha256
 tar xzf chemenu-stack-<version>.tar.gz
 cd chemenu-stack-<version>
 ```
 
+Die Prüfsumme ist nicht Zierde: Sie ist das Einzige, was einen unterbrochenen Download von
+einem vollständigen unterscheidet, und `sha256sum -c` muss `OK` sagen, bevor irgendetwas
+entpackt wird.
+
 Danach weiter mit Schritt 2 aus Weg B: den Agenten
 [instructions/setup-instance.md](instructions/setup-instance.md) ausführen lassen. Der
 entpackte Baum ist bereits eine Distribution - Schritt 1 (`dist export`) entfällt.
@@ -60,11 +68,14 @@ Zwei Schritte, von denen nur der erste rein menschlich ist:
      Wiki-Seite (`$WIKI_AUTHOR` überschreibt dies bei Bedarf).
    - **Remote** (optional) - eine URL, wenn du das Repo auf einen Server pushen willst; sonst
      bleibt die Instanz lokal, und jedes `publish` läuft mit `--no-push`.
-   - **KB-Sprache** - die exportierte Distribution bringt **Deutsch** mit: die Regel in
+   - **Autorenkonventionen** - Sprache, Abschnittsnamen, Namensformen, Ton, Beziehungslabels
-     `kb/CONTRACT.md`, das Vokabular in `instructions/german-terminology.md` und deutsche
+     und Confidence-Rubrik stehen in `kb/CONVENTIONS.md`, dazu je Collection die Regeln in
-     Abschnittsnamen in den Seitenvorlagen. Das ist eine Entscheidung dieser Ursprungsinstanz,
+     `kb/<name>/COLLECTION.md`. Die Distribution bringt davon nur die `.template`-Dateien mit:
-     keine Eigenschaft des Musters. Willst du eine andere Sprache, sag es **vor dem ersten
+     das sind Entscheidungen *dieser* Instanz, keine Eigenschaft des Musters, und nichts davon
-     Ingest** - danach ist es eine Migration jeder bereits angelegten Seite.
+     liegt unter `tools/` oder `types/`. Fertige Profile - darunter ein vollständiges deutsches -
+     hält `instructions/kb-profiles.md` bereit; es ist eine Palette, kein Enum. Sag die Sprache
+     **vor dem ersten Ingest** - danach ist ein Wechsel der Abschnittsnamen eine Migration jeder
+     bereits angelegten Seite.
    - **Personalization** - wer diese Instanz bedient (`USER.md`) und wie sie klingt
      (`SOUL.md`). Die Distribution bringt nur `USER.md.template` und `SOUL.md.template` mit:
      persönlicher Inhalt gehört nicht in jede exportierte Kopie, aber beide Dateien werden in
@@ -82,10 +93,14 @@ Zwei Schritte, von denen nur der erste rein menschlich ist:
 
 ## Weg C: Dieses Repo klonen
 
-Für Torbens Instanz selbst, oder einen Fork davon samt Inhalt:
+Für die Arbeit am Stack selbst, oder um sich den mitgelieferten Korpus als begehbares Beispiel
+anzusehen. Was hier liegt, ist ein **Testbett und eine Demo**, keine produktive Wissensbasis:
+rund 170 Seiten, die den Stack selbst dokumentieren - Gates, Lint, Versionierung, Suche, das
+Wiki-Muster. Wer eigenes Wissen sammeln will, nimmt Weg A oder B und fängt mit einem leeren
+`kb/` an.
 
 ```bash
-git clone <repo-url>
+git clone https://gitea.nehmer.net/torben/chemenu.git
 cd chemenu
 ```
 
@@ -102,6 +117,21 @@ Checkout* beschreibt und nicht das Repo. Sie ist optional; wer sie anlegt, spart
 folgenden Session die Fragen nach Harness, MCP-Servern und Remote. Vorlage:
 `ENVIRONMENT.md.template`, Ablauf: Schritt 5 in `instructions/bootstrap.md`.
 
+## Weg D: Private Instanz mit diesem Repo als Upstream
+
+Die Kombination aus A und C: eine eigene, nicht öffentliche Instanz, die weiterhin
+Stack-Updates von hier zieht - per `git merge` statt per Tarball, also mit echtem
+Drei-Wege-Merge statt `cp -r`.
+
+Das ist der Weg mit dem höchsten Einsatz, weil ein Checkout dann zwei Remotes hat und git beim
+Push nicht unterscheidet, welcher welcher ist. Ein falsches `--remote` legt privaten Inhalt auf
+ein öffentliches Repo, und ein Force-Push holt das nicht zurück - die Objekte bleiben per SHA
+abrufbar, bis auf dem Server die Reflogs verfallen.
+
+Dagegen gibt es das **Publish-Remote-Gate**, und die Anleitung setzt es an die Stelle, an der
+es wirkt: *vor* dem ersten `publish`. Vollständiges Vorgehen:
+[instructions/private-instance.md](instructions/private-instance.md).
+
 ## Version und Updates
 
 Jede Instanz trägt die Version des **Stacks** (Werkzeuge, Typen, Instruktionen, Contracts) -
@@ -119,8 +149,21 @@ nicht erreichbarer Feed wird als Fehler gemeldet - **nie** als „aktuell".
 
 **Was die Versionsnummer aussagt:** kompatibel ist, was in der *linkesten von Null
 verschiedenen Stelle* übereinstimmt. `0.1.3 → 0.1.4` ist ein sicheres Update, `0.1.3 → 0.2.0`
-verlangt eine Migration, und ab `1.0.0` liest sich dieselbe Regel als das gewohnte „MAJOR heißt
+nicht, und ab `1.0.0` liest sich dieselbe Regel als das gewohnte „MAJOR bricht". `version check`
-Migration". `version check` sagt das direkt (`state: update` vs. `state: migration`).
+sagt das direkt (`state: update` vs. `state: migration`).
+
+Was diese Stelle beantwortet, ist **ob die neue Version ein Drop-in-Ersatz ist** - ob sich die
+Maschinerie einfach darüberkopieren lässt und ob die alte danach noch zurückkann. Ob *Inhalt*
+migriert werden muss, ist eine **zweite, unabhängige Frage**. Ein MAJOR-Sprung kann eine leere
+Migrationskette haben und trotzdem Handarbeit verlangen: umbenannter Release-Feed, umbenanntes
+Artefakt, umbenannter Import- oder Kommandoname, geänderte Envvar - `kb/` bleibt dabei
+unangetastet, das Update ist trotzdem keins zum Drüberkopieren. Der Abschnitt „Sonderfall:
+Update von 1.x auf 2.0.0" unten ist genau dieser Fall.
+
+Deshalb stehen in den Release-Notes eines MAJOR zwei getrennte Zeilen, und beide sind vor dem
+Update zu lesen: **Breaking Change:** sagt, was aufhört zu funktionieren und was diese Instanz
+dagegen tun muss; **Migration:** sagt, ob und wie der Korpus umgeschrieben wird (`none required`,
+wenn nicht). `tools/wikitool version notes` druckt den Eintrag.
 
 ### Eine Instanz aktualisieren
 
@@ -137,13 +180,17 @@ dieser Unterschied ist der Zustand, in dem sich jede Instanz mitten im Upgrade b
 
 2. Release-Tarball herunterladen und entpacken (Weg A), die Release-Notes lesen.
 3. Die **Maschinerie** aus dem Tarball über die Instanz kopieren: `tools/`, `types/`,
-   `instructions/`, `AGENTS.md`, `VERSION`, `.wikitool-release.json`. Nicht anfassen: `kb/`,
+   `instructions/`, `AGENTS.md`, `VERSION`, `.wikitool-release.json` - **und `kb/CONTRACT.md`**.
-   `raw/`, `work/`, `.wikitool-kb.json` und `.git/` - das ist die Instanz selbst.
+   Die letzte Datei liegt unter einem Content-Verzeichnis, ist aber Stack-Eigentum: sie hält,
-4. Achtung bei lokal angepassten Contract-Dateien: wer z. B. die KB-Sprache umgestellt hat
+   was `wikitool` erzwingt, und ist in jeder Instanz gleich. Nicht anfassen: alles andere unter
-   (Schritt 5 in `setup-instance.md`), hat `kb/CONTRACT.md` und die Templates unter `types/`
+   `kb/` und `raw/`, `work/`, `.wikitool-kb.json` und `.git/` - das ist die Instanz selbst,
-   verändert. Diese Änderungen vorher sichern und danach wieder einspielen. Welche Dateien das
+   `kb/CONVENTIONS.md` und die `kb/*/COLLECTION.md` eingeschlossen.
-   sind, verrät ein Vergleich gegen die sha256-Summen im `files`-Block der alten
+4. Achtung bei lokal angepassten Stack-Dateien. Die Autorenkonventionen gehören **nicht** dazu:
-   `.wikitool-release.json`.
+   `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
+   es danach wieder ein. Welche Dateien das sind, verrät ein Vergleich gegen die sha256-Summen
+   im `files`-Block der alten `.wikitool-release.json`.
 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
@@ -199,22 +246,25 @@ behält Schema und Shape.
 | `WIKI_AUTHOR` | Override für den Autornamen neuer Source-Seiten | `git config user.name` - fehlt beides, bricht `new` mit `ERROR` ab |
 | `WIKITOOL_SESSION_ID` | Scopt das Iteration-Budget-Gate auf eine Aufgabe statt auf ein Terminal | Parent-Process-ID (siehe [instructions/session-setup.md](instructions/session-setup.md)) |
 | `WIKITOOL_UPDATE_URL` | Release-Feed, den `version check` abfragt | Wert aus `.wikitool-release.json`, sonst der Feed der Ursprungs-Instanz |
-| `WIKITOOL_UPDATE_TOKEN` | Gitea-Token für den Release-Feed | keiner - **aber das Ursprungs-Repo ist derzeit privat, also wird ein Token gebraucht** (siehe unten) |
+| `WIKITOOL_UPDATE_TOKEN` | Gitea-Token für den Release-Feed | keiner - gegen `torben/chemenu` nicht nötig, nur für einen privaten Fork (siehe unten) |
+| `CHEMENU_ROOT` | Auf welchen Korpus das Paket zeigt - für einen Aufrufer, der nicht im Checkout selbst liegt | der Checkout, in dem das Paket liegt (`tools/wikitool` verhält sich ohne die Variable unverändert) |
+| `WIKI_TRACE` / `WIKI_TRACE_DIR` | Telemetrie abschalten bzw. aus dem Arbeitsbaum heraus umlenken | an, nach `reports/telemetry/` - der MCP-Server verweigert damit den Start, siehe [INSTALL-MCP.md](INSTALL-MCP.md) |
 
-**Privates Ursprungs-Repo.** `torben/chemenu` ist nicht öffentlich lesbar. Gitea
+**Gegen das Ursprungs-Repo braucht es kein Token.** `torben/chemenu` ist öffentlich lesbar;
-antwortet anonymen Aufrufern für ein unsichtbares Repo mit demselben `404` wie für ein gar
+`version check` und der Download in Weg A funktionieren ohne Konfiguration.
-nicht existierendes - ein fehlendes Release und ein fehlender Zugriff sehen also identisch aus.
+
-Für `version check` (und für den Download in Weg A) braucht es deshalb ein Gitea-Token mit
+**Für einen privaten Fork schon.** Wer den Stack in ein eigenes, nicht öffentliches Repo legt
-Lesezugriff:
+und `WIKITOOL_UPDATE_URL` auf dessen Feed zeigen lässt, stößt auf eine Eigenheit, die man
+kennen sollte: Gitea antwortet anonymen Aufrufern für ein unsichtbares Repo mit demselben
+`404` wie für ein gar nicht existierendes. Ein fehlendes Release und ein fehlender Zugriff
+sehen dann identisch aus - „kein Update gefunden" wäre in dem Fall schlicht gelogen. Dagegen
+hilft ein Gitea-Token mit Lesezugriff:
 
 ```bash
 export WIKITOOL_UPDATE_TOKEN="<gitea-token>"
 tools/wikitool version check
 ```
 
-Wird das Repo öffentlich geschaltet, entfällt das Token ersatzlos - der Feed ist dann anonym
-lesbar und `version check` funktioniert ohne Konfiguration.
-
 ## Verifikation
 
 ```bash
@@ -259,6 +309,12 @@ tools/wikitool instructions verify
   sondern die Aufforderung, die Ausgabe einem Menschen zu zeigen: sie enthält die vollständige
   Dateiliste und die exakte `--confirm <token>`-Zeile, die nach Freigabe veröffentlicht.
   Details: [instructions/gates.md](instructions/gates.md).
+- **`publish` endet mit Exit-Code 42 (Publish-Remote-Gate)** - dieser Checkout hat eine
+  `.wikitool-remotes.json`, und das angesteuerte Remote steht nicht darin. Ebenfalls kein
+  Fehler: Die Ausgabe nennt die Push-URL, an die geschrieben würde, und die erlaubten. Anders
+  als beim Mass-Update-Gate gibt es hier **keinen Token und keine Flagge** - stimmt das Ziel
+  wirklich, trägt der Mensch dessen URL selbst in die Datei ein. Ein Agent, der die Datei
+  anfasst, um an der Verweigerung vorbeizukommen, öffnet ein Gate aus eigenem Antrieb.
 - **Ich will am Tool-Stack selbst weiterarbeiten (nicht nur Wiki-Inhalt betreiben)** - eine neue
   Instanz hat dafür keinen Weg: `dist export` lässt `instructions/dev/` (Stack-Entwicklung,
   inkl. der vendorten `commonplace/`-Wissensbasis) bewusst und dauerhaft weg, ohne

README.md

@@ -14,12 +14,15 @@ and maintains a persistent wiki** that compounds over time.
 English; the compiled pages under `kb/` are not. What stays English inside them is everything that
 is an *identifier* rather than prose - page titles, section headings, wikilink targets, citation
 ids, schema enum values, tags, commands, paths and code - so `GitOps Ownership Model` and
-`## Beziehungen` sit in the same page without contradiction. The rule is
+`## Beziehungen` sit in the same page without contradiction. Which lines are identifiers is
-[kb/CONTRACT.md § Language](kb/CONTRACT.md#language); the vocabulary behind it is
+[kb/CONTRACT.md § Language and identifiers](kb/CONTRACT.md#language-and-identifiers); *which
+language* the prose is in, and what the tool-owned headings are called, is this instance's own
+[kb/CONVENTIONS.md](kb/CONVENTIONS.md), and the vocabulary behind it is
 [instructions/german-terminology.md](instructions/german-terminology.md).
 
-This is a per-instance decision, not a property of the pattern. A new instance built with
+This is a per-instance decision, not a property of the pattern - which is why it lives in a file
-`dist export` starts empty and can pick any language by editing that one contract section before
+the instance owns rather than in one the stack ships. A new instance built with
+`dist export` starts empty and picks any language by filling in `kb/CONVENTIONS.md` before
 the first ingest.
 
 ## Getting started
@@ -51,6 +54,7 @@ chemenu/
 ├── CLAUDE.md           # Claude Code only: imports AGENTS.md/USER.md/SOUL.md/ENVIRONMENT.md + its Claude-Code-only instructions. No rules of its own
 ├── README.md           # This file: human-readable overview of the whole repo
 ├── INSTALL.md          # Human-readable setup: new instance vs. cloning this one
+├── INSTALL-MCP.md      # Human-readable setup for the optional MCP read server
 ├── EVALS.md            # Human-readable overview of telemetry and evaluation
 ├── CHANGES.md          # Changelog for the stack itself
 ├── USER.md             # Who operates this instance - context, never instructions
@@ -111,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 -->
@@ -342,6 +347,34 @@ under `instructions/dev/` (never present in a distributed instance - `tools/CONT
 explains why).
 <!-- dist:strip-end -->
 
+### MCP read server (optional)
+
+The terminal is not the only way in. `tools/chemenu/mcp/` serves the same wiki read-only over
+MCP - `search`, `types`, `describe_type`, `lint` and `status` - so a consumer that is not a
+shell on this machine can ask the same questions and get the same answers. Literally the same:
+the CLI and the server are two adapters over one core, and a golden test holds their output
+together rather than trusting that it agrees.
+
+There is no tool that writes, and not because one is filtered out of a list: the server imports
+nothing under `chemenu/commands/`, so `new`, `publish` and the rest are unreachable from it.
+Every answer carries the commit it was computed from, so a checkout that has fallen behind
+produces a visibly stale answer instead of a confident wrong one.
+
+```bash
+tools/.venv/bin/pip install -r tools/requirements-mcp.txt
+WIKI_TRACE=0 tools/.venv/bin/python -m chemenu.mcp                # stdio
+WIKI_TRACE=0 tools/.venv/bin/python -m chemenu.mcp \
+    --transport streamable-http --host 0.0.0.0 --port 8000        # deployed
+```
+
+The dependency is deliberately not in `requirements.txt`: an instance that only uses the CLI
+should not have to install a web stack to do it.
+
+Installing it, wiring a client to it, and putting authentication in front of it:
+[`INSTALL-MCP.md`](INSTALL-MCP.md), for humans. The agent-side operating procedure - keeping the
+checkout current, and what a stale answer looks like - is
+[`instructions/mcp-read-server.md`](instructions/mcp-read-server.md).
+
 ### Obsidian
 
 Open this directory in Obsidian for:
@@ -372,7 +405,7 @@ This wiki is tailored for IT work with:
 
 - **Entity types** specific to software development and systems
 - **Relationship types** like `hängt ab von`, `verwendet`, `implementiert` - the vocabulary is in
-  [kb/CONTRACT.md § Linking](kb/CONTRACT.md#linking)
+  [kb/CONVENTIONS.md](kb/CONVENTIONS.md), because it is this instance's rather than the stack's
 - **Templates** for projects, systems, tools, technologies, ADRs
 - **Guidelines** for documenting technical decisions
 - **Cross-reference patterns** for code and architecture

VERSION

@@ -1 +1 @@
-2.1.1
+4.4.0

docs/ownership-and-templates.md

@@ -0,0 +1,71 @@
+# 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 can simply be overwritten by the next release. 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 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
+
+Running a stack upgrade against an existing instance boils down to: overwrite the verbatim
+files, leave the `.template`-sourced files alone. The verbatim files are safe to replace
+wholesale because they were never instance-specific to begin with - identical content going
+back in changes nothing an instance actually decided. 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,114 @@
+# 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.
+
+The two things that actually consume a version number are a release and CI's version gate - and
+they disagree about granularity. The gate wants `VERSION` to move on every push that touches
+stack-shaped paths, which is a *commit*-level question: has this tree changed since the last
+push. A release wants to know something else: has *this specific number* been published, ever.
+Handing out a fresh number per bump answers the gate's question by accident and the release's
+question wrongly - it treats every bump as if it were about to ship, when most of them are steps
+toward a release that hasn't happened yet. Four bumps in one session, on the same day, for the
+same eventual release, produced four numbers that a version-check feed would have reported as
+four different available upgrades, three of which were never real.
+
+The fix is not to slow the gate down - it still wants `VERSION` to move every time, and it still
+gets that. It's to stop treating every movement as a new number. 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 consumed 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/CONTRACT.md

@@ -58,16 +58,38 @@ whether an instruction is still reachable, which is exactly why the answer means
 `instructions/dev/` boundary check below asks the opposite question - what would *dangle* in a
 distributed instance - and does scan README.md, because `dist export` ships it verbatim.
 
-Two kinds of file use the Manual tier today: [german-terminology.md](german-terminology.md), a
+Three kinds of file use the Manual tier today: [german-terminology.md](german-terminology.md), a
-vocabulary consulted on demand rather than a procedure, and every migration document (below).
+vocabulary consulted on demand rather than a procedure; [kb-profiles.md](kb-profiles.md), the
+catalogue of authoring profiles an instance may adopt into its own `kb/CONVENTIONS.md` and
+`COLLECTION.md` files; and every migration document (below).
 
 ## `instructions/migrations/`
 
-A content migration is a Manual instruction with two extra frontmatter fields
+A content migration is a Manual instruction with three extra frontmatter fields
 (`types/instruction.schema.yaml`): `migrates_to:`, the stack version whose content shape it
-produces, and `migration_kind:` (`mechanical` | `assisted`). It lives at
+produces; `migration_kind:` (`mechanical` | `assisted`); and `obligation:`
+(`required` | `offered`, default `required`). It lives at
 `instructions/migrations/<version>-<slug>.md`.
 
+`migration_kind:` and `obligation:` are **two axes, not one**. The first says how the work is
+carried out, the second whether it has to happen at all:
+
+| `obligation:` | Means | `migrate status` |
+|---|---|---|
+| `required` | The content must reach the new shape or it no longer fits the machinery | Counted as outstanding; `migrate done` advances `kb_version` through it, in chain order |
+| `offered` | A file the instance owns still works as it is, and the stack proposes a better default | Listed separately, never blocks, no ordering rule. `migrate done` records it in the applied ledger and leaves `kb_version` where it is |
+
+Keeping them apart is what stops `migrate status` crying wolf: an instance nagged about an
+improvement it declined stops reading the nag that means its content no longer fits its
+machinery. And because taking an offer deliberately does not move the version, the **applied
+ledger** - not `kb_version` - is what makes an offer stop being offered; without that record
+there is no way to tell a taken offer from an ignored one.
+
+An `offered` migration is what makes an instance-owned file upgradeable at all. `dist export`
+records a sha256 per shipped file in `.wikitool-release.json`, so `migrate status` can say which
+of those files the instance edited and which it merely received - the first have to be
+reconciled by a person, the second can simply be copied over.
+
 The tier fits exactly: a migration must never be picked up implicitly - it rewrites the corpus -
 and it is referenced by nothing, because `tools/wikitool migrate status` finds it by reading the
 directory and comparing `migrates_to:` against this instance's `kb_version`. That is also why
@@ -153,7 +175,8 @@ What lives where:
 |-------|------|
 | [AGENTS.md](../AGENTS.md) | Invariants and routing - what must always hold |
 | `instructions/` | How the tooling is *operated* |
-| [kb/CONTRACT.md](../kb/CONTRACT.md) + each `COLLECTION.md` | How a page is *authored* |
+| [kb/CONTRACT.md](../kb/CONTRACT.md) | What the stack enforces about a page, in every instance |
+| `kb/CONVENTIONS.md` + each `COLLECTION.md` | What *this* instance decided about authoring - owned by the instance, shipped only as a `.template` |
 | [types/](../types/type-spec.md) | What a page structurally *is* |
 | [tools/CONTRACT.md](../tools/CONTRACT.md) | What each command does and how it fails |
 

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,14 @@ 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).
 
 ## Steps
 
@@ -36,38 +42,159 @@ issues at that URL, which is exactly why `dist export` excludes
    specific files or commands involved. An issue that only makes sense to
    whoever wrote it is a note, and notes were the problem.
 
-2. **Give it exactly two labels: one `prio/`, one `size/`.** Both, always -
+2. **The body is the working state, not a historical first post - keep it
-   a priority without a cost is half a decision. Neither is a promise about
+   current as you go.** It is this stack's plan file: the same thing a harness's
-   *when*; together they answer "what should I pick up in the time I have".
+   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.
 
-   | Priority | Means |
+   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.
+
+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.
+
+## 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 +202,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,14 +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 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:
 
@@ -59,18 +91,27 @@ stack development happens in the origin repo instead (see AGENTS.md's routing li
    ```
 
    Never edit `VERSION` or the entry's heading by hand - `bump` writes both, and `docs verify`
-   fails a tree where they disagree. Pick the part by what an existing instance would have to do:
+   fails a tree where they disagree. Pick the part by whether the new version is a **drop-in
+   replacement** for the old one - not by whether content has to be migrated:
 
    | Change | Part |
    |--------|------|
    | Fix, no interface change | `--patch` |
-   | New capability, backwards compatible | `--minor` |
+   | New capability, still drop-in in both directions | `--minor` |
-   | **Existing content must be migrated** | `--major` |
+   | **Not a drop-in replacement** - any hand-work by the user or a migration script, or a downgrade that no longer works | `--major` |
 
-   A `--major` bump additionally needs a migration document for the new version - written per
+   Content migration is one way to land in the last row, not the definition of it: a rename of
-   [migrate-corpus.md](../../migrate-corpus.md) - or `--no-migration "<reason>"` when no content
+   the update path, the artefact, an import name, a flag or an envvar breaks a swap with `kb/`
-   actually has to change. `bump` refuses otherwise, and so does `docs verify`: an instance
+   entirely untouched. The full test, the catalogue of such breaks, and what to put in front of
-   learning that it must migrate, with nothing telling it how, is a dead end.
+   the user first are in [version-parts.md](../version-parts.md) - **read it before choosing
+   `--major`.**
+
+   A `--major` bump therefore needs two things recorded. `--breaking "<what stops working>"`
+   is required on every boundary-crossing bump; on top of it, a migration document for the new
+   version - written per [migrate-corpus.md](../../migrate-corpus.md) - or
+   `--no-migration "<reason>"` when no content actually has to change. `bump` refuses without
+   either, and so does `docs verify`: an instance learning that it must migrate, with nothing
+   telling it how, is a dead end.
 
    Then write the entry's body - `bump` deliberately leaves it empty, the same way `new` leaves
    the prose.
@@ -78,18 +119,62 @@ 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
   code changes and the normal content skills' rules to the content changes - they are not
   mutually exclusive within a session, only per change.
+- **The change turns out not to be a drop-in replacement?** Do not bump across the boundary on
+  your own initiative. Every existing instance pays for a breaking change once, by hand, so the
+  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. 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

@@ -35,6 +35,53 @@ Do not re-do any of this per test; it is done for you, per test, via `monkeypatc
 fixture redirects it into `tmp_path`. Tracing is never disabled suite-wide, because two
 telemetry tests assert that a trace gets written.
 
+Two in-process caches are cleared alongside the environment, for the same reason: `config`'s
+resolved paths and `conventions`' parsed `kb/CONVENTIONS.md`. A test that *rewrites* the
+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/`.
@@ -75,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)" \
@@ -87,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

@@ -0,0 +1,193 @@
+---
+type: types/instruction.md
+name: version-parts
+description: Which part of the stack version a change bumps - the compatibility question (is the new version a drop-in replacement?) separated from the migration question (must existing content change?), plus what to do before a breaking bump.
+---
+# Pick the version part for a stack change
+
+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
+   *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
+   may not have. `kb/` staying untouched does not make a change compatible, and
+   `version bump --no-migration` exists precisely because boundary-crossing bumps with an
+   untouched corpus are a real case.
+
+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`. Five bumps with no release in between used to mean five numbers, four of which nothing
+ever consumed - the release-granularity CI's version gate wants (`VERSION` must move on every
+stack-touching push) was being paid at bump granularity instead. 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.
+
+- **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 section
+  below describes - `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.
+Read it in full the first time a change looks like it might be boundary-crossing; afterwards
+the three-line test below is usually enough.
+
+## Steps
+
+1. **Apply the drop-in test.** The bump is boundary-crossing if **either** half fails:
+
+   - **Forward:** an existing instance can install the new machinery by copying `tools/`,
+     `types/`, `instructions/`, `AGENTS.md`, `VERSION` and `.wikitool-release.json` over itself,
+     and everything that worked before still works - with **no** hand-work by the user and **no**
+     migration script. Any step beyond the copy, however small, fails this half.
+   - **Backward:** having installed the new version, the user can put the old one back and be
+     where they started. A state file the old version cannot read, a rewritten corpus, a
+     renamed stamp - anything that makes the downgrade fail or leave a broken instance - fails
+     this half.
+
+   Content migration is one way to fail the forward half, not the definition of it.
+
+2. **Check the catalogue** when the answer still feels like a judgment call. Each of these
+   crosses the boundary with `kb/` entirely untouched:
+
+   | What changed | Why the swap is not drop-in |
+   |---|---|
+   | The update path - `update_url`, the release feed, the repo it points at | The instance cannot repair its own `.wikitool-release.json`: it is machine-written, and invariant 1 forbids the hand-edit. The channel that would have told it to update is the channel that broke |
+   | The release artefact's name | Every download script and every pin against it breaks |
+   | The Python package's import name | `from <old> import ...` outside the shipped tree breaks |
+   | A command, subcommand, or flag that was removed or renamed | Scripts, CI workflows and instruction files calling the old spelling break |
+   | An environment variable's name | An instance configured through it silently loses the configuration |
+   | The shape of a machine-read file - `.wikitool-kb.json`, `.wikitool-release.json`, a generated index | The old version cannot read what the new one wrote, so the downgrade half fails even if the upgrade half passed |
+   | A type-spec's required fields | Existing pages stop validating - this one crosses *and* needs a content migration |
+
+   The catalogue is illustrative, not exhaustive. When something is not on it, go back to step 1.
+
+3. **Otherwise pick the compatible part:**
+
+   | Change | Part |
+   |---|---|
+   | Fix, no interface change | `--patch` |
+   | New capability, drop-in in both directions | `--minor` |
+
+4. **Stop and talk to the user before the bump that first escalates a candidate past the
+   boundary.** It is expensive in a way the other two parts are not: every existing instance pays
+   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.
+   - **The alternatives**, so the break is a choice and not a side effect:
+     - *Avoid it* - keep the old name as an alias, read both file shapes, accept both flag
+       spellings. A compatibility shim carried for one release is usually cheaper than a
+       migration everyone runs.
+     - *Defer and batch it* - hold the break until the next boundary crossing, so instances pay
+       once instead of twice.
+     - *Split it* - ship the compatible half now, the breaking half later behind a deprecation
+       window that the changelog announces in advance.
+   - **Your recommendation**, with the trade-off named.
+
+   Then wait for an explicit go-ahead. Do not bump across the boundary on your own initiative.
+
+5. **Record the break in the escalation bump itself.** The bump that first crosses the boundary
+   requires `--breaking "<what breaks>"`, which writes a `**Breaking Change:**` line into the
+   entry:
+
+   ```bash
+   tools/wikitool version bump --major \
+     --title "<what changed>" \
+     --breaking "<what stops working, and what an instance must do about it>" \
+     --no-migration "<why no page has to change>"     # only if that is true
+   ```
+
+   The line, once written, stays in the entry across every later bump of the same candidate -
+   a follow-up `--major` does not need to repeat `--breaking`, because the entry it would repeat
+   it into is the same one. `--breaking` is refused on a bump that crosses nothing, and required
+   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). 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. Like `--breaking`, both persist across
+   later bumps of the same candidate without being repeated.
+
+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.
+
+## Decision points
+
+- **The change ships no code - only `README.md`, `INSTALL.md`, `EVALS.md`, or `.gitea/`?** No
+  bump at all; CI's version gate is scoped to what changes behaviour.
+- **A break you can see coming but are not making yet?** File it as an issue and let it
+  accumulate. Boundary crossings are cheaper in batches, and step 4's "defer" alternative is
+  only real if someone wrote the break down.
+- **Unsure between MINOR and boundary-crossing?** It is boundary-crossing. The cost of an
+  unnecessary MAJOR is one extra release note; the cost of a MINOR that actually breaks is an
+  instance whose update path fails while its version number promised it would not.
+- **The break only affects this repository, not a distributed instance** - something under
+  `instructions/dev/`, say? Then it is not a stack break at all: `dist export` never shipped it.
+  Judge by what an *exported* instance sees.
+
+## Scope
+
+Applies to the stack version in `VERSION` - `tools/`, `types/`, `instructions/`, `AGENTS.md`
+and the contracts. It says nothing about the content shape in `.wikitool-kb.json`, which is
+advanced by `wikitool migrate done` and described by [migrate-corpus.md](../migrate-corpus.md),
+and nothing about wiki content operations, which are logged in `kb/log.md` and carry no version
+at all.
+
+Choosing the part remains a judgment call, deliberately: `docs verify` checks that a
+boundary-crossing entry *documents* its break and its migration, never that the part was chosen
+correctly. No validator can tell a renamed flag from a new one.
+
+## Case study: 2.0.0
+
+The Chemenu rebranding renamed the repo, the release artefact and the Python package. No page
+in `kb/` changed, so the first attempt was `1.9.0` - the migration question, answered correctly,
+substituted for the compatibility question, which was never asked. Three things broke: every
+existing instance's `update_url` pointed at a repo path that no longer existed and could not be
+hand-repaired; the artefact name changed; the import name changed. The correct bump was
+`--major --no-migration`, and the `CHANGES.md` entry for `2.0.0` carries the reasoning in full
+under "Warum das trotzdem MAJOR ist". The error was caught by the user, not by the
+documentation - which is what step 4 is for.

instructions/gates.md

@@ -22,10 +22,11 @@ Read the exit code first - it says which of these applies:
 ## Exit 42: user clearance required
 
 A `wikitool` command that exits **42** is not reporting an error. It is refusing to act until a
-human has *read its output*. Two gates use it today - the Mass-Update Gate (`publish`, on a
+human has *read its output*. Three gates use it today - the Mass-Update Gate (`publish`, on a
-change touching 10 or more counted files) and the rebase-review gate (`sync` and `publish`, on
+change touching 10 or more counted files), the rebase-review gate (`sync` and `publish`, on
-a rebase whose incoming commits touch a file this session is also changing) - but the rule is
+a rebase whose incoming commits touch a file this session is also changing), and the
-about the exit code, not the command:
+Publish-Remote Gate (`publish`, on a push to a target this checkout has not declared) - but the
+rule is about the exit code, not the command:
 
 > **Copy the command's output into your reply - the substance of it, not a description of it -
 > and stop.** Run no further commands in that turn.
@@ -62,6 +63,46 @@ clearance.
 
 Background: [[Mass-Update Gate]] (`kb/concepts/Mass-Update Gate.md`).
 
+### Publish-Remote Gate
+
+The Mass-Update Gate asks whether a change is too large to publish. This one asks the question
+underneath it: **whether this is the right repository to publish to at all.**
+
+A checkout that holds private content usually has two remotes - its own, and the public upstream
+it takes stack updates from. Git does not distinguish them at push time, so one wrong `--remote`
+puts a private corpus on a public repository. That is not cheaply reversible: a force-push moves
+the branch, but the objects stay fetchable by SHA until someone expires the server's reflogs and
+runs `git gc --prune=now` on the bare repo.
+
+`.wikitool-remotes.json` names the push URLs a checkout permits:
+
+```json
+{ "schema": 1, "allowed_push_urls": ["ssh://git@example.net:22/you/your-wiki.git"] }
+```
+
+It pins **URLs, not remote names** - a name-based list would wave through a `publish` whose
+`origin` had been repointed, which is the failure it exists to catch. It reads the remote's
+`pushurl` when one is set, because that is where `git push` actually writes.
+
+The file is per-checkout and gitignored, for the same reason `ENVIRONMENT.md` is: two clones push
+to two different places, so a committed copy would tell a private clone that the public upstream
+is a legitimate target for its own content. **Absent means unrestricted** - a single-remote
+checkout with nothing private in it has nothing to protect, and `doctor` reports which state a
+checkout is in, WARNing only when there is more than one remote and no allowlist. A malformed
+file is an error rather than "no restriction": a corrupted safeguard must not read as a disabled
+one.
+
+**This gate has no `--confirm` token, on purpose.** The other two clear with a token because the
+question they ask ("is this change right?") is one the agent can put to the user and the user can
+answer for that one changeset. This one asks "does this content belong to that repository?", which
+is a standing property of the checkout, not a per-push judgment. The way past it is for the user
+to add the URL to the file. **An agent must never edit `.wikitool-remotes.json` to get past a
+refusal** - that is opening a gate on your own initiative, which AGENTS.md invariant 6 forbids.
+
+The setup this gate exists for - a private instance that takes stack updates from a public
+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.
+
 ## Iteration Budget Gate and loop-breaker
 
 Every `wikitool` call is counted per session. Calls are refused past **60 in a session**, or

instructions/german-terminology.md

@@ -7,9 +7,13 @@ manual: true
 
 # German terminology for `kb/`
 
-Reference vocabulary for [kb/CONTRACT.md](../kb/CONTRACT.md#language)'s rule that pages are
+Reference vocabulary for [kb/CONVENTIONS.md](../kb/CONVENTIONS.md#language)'s rule that this
-written in German. The rule lives there; the word list lives here, because it is lookup material
+instance's pages are written in German. The rule lives there; the word list lives here, because
-rather than a norm and would otherwise be loaded on every write.
+it is lookup material rather than a norm and would otherwise be loaded on every write.
+
+**This file belongs to the `german` language profile, not to the stack.** An instance writing in
+another language deletes or replaces it - see
+[kb-profiles.md](kb-profiles.md).
 
 Derived from translating all 248 pages on 2026-08-29. Every entry below is a decision that was
 made wrong at least once first - each cost a correction pass across published pages, which is why
@@ -98,8 +102,8 @@ none of them structural, so no check found them. It is the one thing to watch fo
 instructional prose.
 
 - **Quotations are never reworded**, neither translated nor moved into the impersonal register.
-- Buzzwords and AI filler are banned by [kb/CONTRACT.md](../kb/CONTRACT.md#tone); the German list
+- Buzzwords and AI filler are banned by [kb/CONVENTIONS.md](../kb/CONVENTIONS.md#tone); the
-  is there.
+  German list is there.
 - Dash as ` - `, not `—`.
 - German number formatting only in prose („10.000 Punkte"). Never inside code, version numbers or
   measurements (`75-85 px`, `10m`, `0.90`).
@@ -108,4 +112,4 @@ instructional prose.
 
 This is about prose in `kb/`. What is prose and what is an identifier - titles, headings, wikilink
 targets, cite-ids, enum values, tags, code - is decided by
-[kb/CONTRACT.md](../kb/CONTRACT.md#language), not here.
+[kb/CONTRACT.md](../kb/CONTRACT.md#language-and-identifiers), not here.

instructions/kb-profiles.md

@@ -0,0 +1,191 @@
+---
+type: types/instruction.md
+name: kb-profiles
+description: Ready-made answers for kb/CONVENTIONS.md and each COLLECTION.md - the proven collection contracts and language profiles this stack has shipped, offered as a palette to adopt or adapt, never as a binding source.
+manual: true
+---
+# Pick a profile for a collection or for this instance's conventions
+
+**This page is a palette, not an enum.** Each `kb/<name>/COLLECTION.md` stays authoritative for
+its own collection and `kb/CONVENTIONS.md` for the instance as a whole; an entry here is a
+proven starting point, nothing more. Adopting one means *copying its text into* that file - not
+pointing at this page and inheriting whatever it says later. Nothing in the stack reads this
+document, and `profile:` in a contract's frontmatter records where the text came from, not where
+it lives.
+
+That direction is deliberate and it is the opposite of how this repo used to work. Language,
+tone, naming and the relationship vocabulary sat in `kb/CONTRACT.md`, a file `dist export` ships
+verbatim - so every instance that wanted something else edited a stack file, and an upstream
+merge handed the stack's answer back. What binds is now the instance's; what ships is this
+catalogue, and it binds nothing.
+
+## When to run
+
+- Setting up a new instance: the KB-language step of
+  [setup-instance.md](setup-instance.md) sends you here to fill `kb/CONVENTIONS.md`.
+- Adding a collection to an existing instance, and wanting a contract that already works rather
+  than a blank one.
+- Rewriting an existing `COLLECTION.md` or `kb/CONVENTIONS.md` and wanting to see what the
+  alternatives were.
+
+Not for changing what the *stack* enforces. That is [kb/CONTRACT.md](../kb/CONTRACT.md), and it
+is not a profile.
+
+## Steps
+
+1. **Decide what you are filling.** Two different files, and they are not interchangeable:
+
+   | File | Holds | Profiles below |
+   |---|---|---|
+   | `kb/CONVENTIONS.md` | Language, section headings, naming forms, tone, relationship labels, confidence rubric - once per instance | [Language profiles](#language-profiles) |
+   | `kb/<name>/COLLECTION.md` | What one collection holds, its quality goal, its local linking and naming rules | [Collection profiles](#collection-profiles) |
+
+2. **Copy the entry's text into the file**, then edit it until it is true of this instance.
+   A profile you adopted and then changed is still that profile's `profile:` value - the field
+   records the starting point, not a promise of fidelity.
+
+3. **Record it.** `profile: <name>` in the file's frontmatter, or `profile: none` for a
+   collection written from scratch. `wikitool docs verify` checks the field is there; it does
+   not check the value against this page, because a collection an instance invented has no
+   entry here to name.
+
+4. **Set `required_by_stack:` on a collection - and set it correctly.** This one is *not* a
+   choice: it says whether `wikitool` resolves against the collection by name, and
+   `docs verify` checks it against the stack's own list. `sources` is `true`, everything else
+   is `false`. See [kb/CONTRACT.md § Collections](../kb/CONTRACT.md#collections).
+
+## Language profiles
+
+A language profile answers all of `kb/CONVENTIONS.md` at once. There is one today, because one
+is what this repo has actually run.
+
+### `german`
+
+The profile this repo's own instance uses, and the reason this catalogue exists: it was the
+stack's hardcoded behaviour until the conventions file existed.
+
+| Decides | Value |
+|---|---|
+| `language:` | `de` |
+| `sections:` | `Beziehungen` / `Siehe auch` / `Fußnoten` |
+| 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 |
+| Terminology | [german-terminology.md](german-terminology.md) - which English terms stay English, and which have a settled German form |
+
+**The full text to copy** is this repo's own [kb/CONVENTIONS.md](../kb/CONVENTIONS.md). An
+instance adopting it takes that file, not this table; the table is what the profile *decides*,
+so you can tell at a glance whether it is the one you want.
+
+Adopting it also means keeping `german-terminology.md`. An instance on any other language
+deletes or replaces that file - it is the profile's lookup material, not the stack's.
+
+### `english`
+
+What `kb/CONVENTIONS.md.template` ships as its default, so "adopt `english`" means "fill in the
+template and change nothing structural". `sections:` are `Relationships` / `See Also` /
+`Footnotes`, which are also the names this stack wrote before it had a conventions file - so a
+corpus that predates the split needs no translation pass to adopt this profile.
+
+There is no worked text for the rest of it. The template's placeholders are the questions;
+`german` above is what a filled answer looks like.
+
+### Writing a third one
+
+A language profile is not a translation of `german`. Two of its sections are judgment about a
+language rather than vocabulary in it - which foreign technical terms stay untranslated, and how
+to hedge a low-confidence claim - and those are exactly the two that read as awkward when
+translated mechanically. Write them, do not convert them.
+
+The one part that is mechanical: `section_aliases:`. Whatever the corpus used before goes in
+that list, and the pages then migrate one at a time instead of all at once.
+
+## Collection profiles
+
+The four collections this repo runs. Each is a whole `COLLECTION.md`, and **the text to copy is
+the file itself** - `dist export` ships each one as `kb/<name>/COLLECTION.md.template`, which a
+new instance adopts by renaming. What follows is what each decides, so you can tell whether you
+want it.
+
+### `entities`
+
+Concrete, pointable things: projects, deployed systems, tools, technologies, people.
+
+- **Quality goal:** pointability plus currency - what the thing is, where it actually is, and
+  whether that is still true.
+- **Areas** driven by the `entity_type:` field: `projects/`, `systems/`, `tools/`,
+  `technologies/`, `people/`. Areas, not collections - they inherit the contract and carry no
+  `COLLECTION.md`.
+- **Per-area emphasis** spelled out, so a system page is not written like a technology page.
+- `required_by_stack: false`.
+
+Take it when the wiki is about things that exist. Adapt the area list first: it is the part most
+likely to be wrong for another domain.
+
+### `concepts`
+
+Ideas rather than things: architectures, patterns, protocols, workflows, recurring problems,
+and the decisions taken about them.
+
+- **Quality goal:** explanatory sufficiency - the page answers *why it is done this way* without
+  the reader opening the entity pages that use it.
+- Carries the **ADR shape**: context, decision, consequences, status, and the rule that a
+  superseded decision is never rewritten.
+- Routes head-to-head arguments out to `comparisons/` rather than hosting them.
+- `required_by_stack: false`.
+
+Take it whenever `entities` is taken - the split between the two is what keeps either from
+becoming an essay.
+
+### `sources`
+
+One page per ingested source, carrying the `raw_files:` provenance every citation resolves
+against.
+
+- **Quality goal:** faithful compression - what *this source* said, not what was concluded from
+  it. A source page improved beyond its source is no longer evidence.
+- Titles carry the `Source - ` prefix, applied by `wikitool new source`.
+- `required_by_stack: **true**`. `sources coverage`, `[^cite-id]` resolution and
+  `kb/provenance.md` resolve against the name `sources`.
+
+Not optional in the way the others are. An instance may rewrite its authoring rules and may not
+rename or drop it.
+
+### `comparisons`
+
+Structured head-to-head evaluations of two or more things that already have pages.
+
+- **Quality goal:** decidability - named, checkable dimensions and a stated trade-off, so a
+  reader with a concrete situation can choose.
+- Every subject must already have a page; a comparison is a view over existing knowledge.
+- **Exempt from the orphan check** - comparisons are reached through the catalog, not through
+  inbound prose links.
+- `required_by_stack: false`.
+
+Skip it in a wiki that records rather than decides. It is the one of the four that is genuinely
+optional.
+
+## Decision points
+
+- **A profile is almost right?** Copy and edit. There is no partial adoption and no override
+  file - the copy *is* the mechanism, and `profile:` still records where it started.
+- **Two collections want the same profile?** Fine. `profile:` is not unique, and two
+  collections holding different subject matter under the same authoring rules is an ordinary
+  outcome.
+- **Changing `sections:` after pages exist?** That is a corpus migration, not an edit. Put the
+  old names in `section_aliases:` first, then translate page by page - the tool keeps finding
+  the old headings for as long as the alias stands. See
+  [migrate-corpus.md](migrate-corpus.md).
+- **Tempted to make this page binding** - to have `COLLECTION.md` say `profile: entities` and
+  nothing else? Do not. That is the arrangement this split was written to end: the instance
+  would be bound by a file the stack ships and upgrades, which is how an upstream merge changes
+  an instance's authoring rules without anyone deciding to.
+
+## Scope
+
+Covers what an instance authors under `kb/`. It says nothing about what the stack enforces
+([kb/CONTRACT.md](../kb/CONTRACT.md)), what a page structurally is
+([types/type-spec.md](../types/type-spec.md)), or how a command behaves
+([tools/CONTRACT.md](../tools/CONTRACT.md)). None of those are profiles, and none of them are
+the instance's to change.

instructions/link-taxonomy.md

@@ -0,0 +1,215 @@
+---
+type: types/instruction.md
+name: link-taxonomy
+description: The link-label catalogue - every relationship label a page may declare in related:, grouped by register, with the reader need each one names. A palette to authorise from in a COLLECTION.md, never binding on its own.
+manual: true
+---
+# Pick a link label
+
+**This page is a palette, not an enum.** It lists every label this stack ships with and what
+each one asserts. What a page may actually *use* is decided by its own collection: each
+`kb/<name>/COLLECTION.md` authorises a subset per destination, and `wikitool lint` checks
+`related:` against that authorisation rather than against this file. A collection that
+authorises six labels has six, however long this list gets.
+
+A label is an **identifier, not prose**. It is written into `related:` as a machine value and
+rendered verbatim into the page body, so it is never translated - not in a German wiki, not in
+any other. Which words a page is *written* in stays [kb/CONVENTIONS.md](../kb/CONVENTIONS.md)'s;
+this is not one of them.
+
+## The invariant every label obeys
+
+Every label completes, with the page carrying the link as the grammatical subject:
+
+> `[source] <label> [target]`
+
+The page containing the link asserts something **about** the target. `Hermes depends-on
+PostgreSQL` reads correctly on Hermes' page; the same fact written on PostgreSQL's page is a
+different label (`required-by`), not the same one pointing back. Omitted helper verbs ("is",
+"a") are fine where they do not reverse the endpoints.
+
+This is Commonplace's ADR-058, adopted wholesale, and it is what makes a label checkable rather
+than a matter of taste: read the sentence out loud, and if it says the opposite of what you
+meant, the label is wrong.
+
+## Direction is authored, never mirrored
+
+Each direction is a separate decision. A link back from the target is welcome when it
+independently helps a reader *there* - and unnecessary when it does not. **Do not add a reverse
+edge merely to mirror the first one.** The inbound view is rendered from the graph by
+`index rebuild` and `search`, so a reader landing on the target sees what points at it whether
+or not anyone wrote a second edge.
+
+That is why most labels below have no inverse. Only three pairs do, because in each the reverse
+direction is a genuine primary statement someone would write on its own: `depends-on` /
+`required-by`, `runs-on` / `hosts`, and `composition` / `part-of`.
+
+The third was added after the 4.0.0 migration, from measurement rather than from the desk. A
+parent-child structure - a tier list and its tiers, a spectrum and its levels - produces the
+question on nearly every page: the parent writes `composition`, and the child then reaches for
+either `part-of` or `see-also`. The migration run answered `see-also`, on the reading that
+`part-of` would be a mirror, and left sixteen edges saying "these two are related" about a
+relationship the catalogue already had a word for. It is not a mirror: the parent's sentence
+lists its parts, the child's names the whole it belongs to, and a reader landing on the child
+needs the second one.
+
+## When to run
+
+Adding or changing a `related:` entry, authorising labels in a `COLLECTION.md`, or judging
+whether a relationship is worth naming as a formal edge at all.
+
+## Steps
+
+1. **Decide whether this is an edge.** Not every mention is one. An edge is a reader aid: it
+   says *follow this if you need X*. A subject mentioned once in passing is prose with a
+   `[[wikilink]]`, not a declared relationship. Over-declaring is how a graph becomes a list of
+   everything adjacent to everything.
+
+2. **Say the sentence.** `[this page] <label> [that page]`. If it reads backwards, you want the
+   other page to carry the edge, or a different label.
+
+3. **Pick from the register that fits the pair**, below. Prefer the most specific label that is
+   true; fall back outward only when nothing fits.
+
+4. **Check the collection authorises it** for that destination -
+   `kb/<name>/COLLECTION.md`'s `outbound:` block. If the label you want is not authorised and
+   should be, that is a collection-contract change, made deliberately, not a lint error to
+   route around.
+
+5. **Write it with the tool**, never by hand:
+
+   ```bash
+   tools/wikitool xref add --a "<This Page>" --b "<That Page>" --rel <label>
+   ```
+
+## The catalogue
+
+### Operational
+
+Concrete things and how they stand to one another - the register this instance runs on. Mostly
+entity to entity.
+
+| label | inverse | asserts |
+|---|---|---|
+| `depends-on` | `required-by` | cannot function without the target |
+| `required-by` | `depends-on` | the target cannot function without this |
+| `runs-on` | `hosts` | executes on the target as its substrate |
+| `hosts` | `runs-on` | provides the substrate the target executes on |
+| `uses` | — | employs the target at runtime, but survives without it |
+| `produces` | — | emits the target as an artifact or data |
+| `consumes` | — | reads the target as an artifact or data |
+| `maintains` | — | carries the upkeep of the target |
+| `owns` | — | is accountable for the target's existence and decisions |
+
+`uses` versus `depends-on` is the distinction worth keeping sharp: if removing the target breaks
+this thing, it is `depends-on`. `owns` versus `maintains`: accountability versus labour, and
+they are often different people.
+
+### Realization
+
+How an idea becomes a running thing. Usually concept to entity or the reverse.
+
+| label | asserts |
+|---|---|
+| `implements` | is a concrete realization of the target |
+| `operationalized-from` | is the prescriptive form of the target's theory |
+| `mechanism` | is the mechanism by which the target works |
+| `procedure` | is the procedure for carrying out the target |
+| `applies-when` | applies under the condition the target describes |
+| `operates-on` | acts upon the target as its subject matter |
+| `invokes` | calls the target as a step within itself |
+
+### Conceptual
+
+Inference and comparison between ideas.
+
+| label | asserts |
+|---|---|
+| `extends` | develops the target's argument further |
+| `grounds` | provides the basis the target rests on |
+| `rests-on` | takes the target as its premise |
+| `enables` | is the operational prerequisite that makes the target possible |
+| `precondition` | must hold before the target applies |
+| `exemplifies` | is an instance of the general claim the target makes |
+| `abstracted-from` | generalizes from the target |
+| `contrasts` | differs from the target in a way worth reading both for |
+| `compares-with` | is weighed against the target on shared dimensions |
+| `contradicts` | asserts something the target denies |
+| `composition` | is composed of the target |
+| `part-of` | is a component of the target |
+
+`composition` / `part-of` is the third **inverse pair**, alongside `depends-on` / `required-by`
+and `runs-on` / `hosts` in the operational register. Being a pair does not make the second edge
+obligatory - direction is still authored - it settles *which label* the second edge takes when
+someone does write it. The child of a `composition` writes `part-of`, not `see-also`: what it
+is a component of is a primary statement about the child, and `see-also` says strictly less
+about the same fact.
+
+`grounds` / `rests-on` is a genuine pair and both directions are primary statements; they are
+listed separately rather than as inverses because either page may legitimately carry only its
+own side.
+
+### Lineage
+
+Where something came from, and what replaced it.
+
+| label | asserts |
+|---|---|
+| `supersedes` | replaces the target, which is now historical |
+| `derived-from` | was produced from the target |
+| `adapted-from` | was reworked from the target for a different purpose |
+| `defined-in` | takes its definition from the target |
+
+A superseded page is never deleted or rewritten - see the collection contract for
+`kb/concepts/`.
+
+### Evidence
+
+The provenance register. Distinct from `sources:` and `[^cite-id]`, which are the *mechanical*
+provenance path: these two are authored claims about how strongly something is backed.
+
+| label | asserts |
+|---|---|
+| `evidenced-by` | is supported by the target as evidence |
+| `is-evidence-for` | serves as evidence for the target's claim |
+
+### Universal
+
+| label | asserts |
+|---|---|
+| `see-also` | nothing more specific applies, and a reader here would still want the target |
+
+**`see-also` is the last resort and should stay rare.** A collection where it is the commonest
+label has a vocabulary problem, not a lot of loosely related pages. The previous vocabulary's
+`verwandt mit` was exactly that, and it is the reason this catalogue exists.
+
+## Extending it
+
+Adding a label is a line of data, never a code change:
+
+1. Add a row here, in the register it belongs to, with the sentence it completes.
+2. Authorise it in the `COLLECTION.md` of every collection that may use it.
+
+The registers are advisory groupings for readers, not a schema - nothing checks that a label is
+used only within its register. Invent an intra-collection label the work needs and propose it
+here afterwards; the architecture is deliberately loose, because the link theory is still
+developing.
+
+## Decision points
+
+- **Two labels both fit?** Take the more specific one. If they are equally specific and mean
+  different things, the relationship is probably two edges.
+- **The relationship reads better from the other page?** Write it there. Nothing is lost - the
+  inbound view renders it here.
+- **You want a reverse edge for navigation?** You do not need one. That is what the rendered
+  inbound view is for, and it is complete in a way an authored mirror never was.
+- **Nothing fits at all?** Use `see-also` and say so in the commit, or propose a label. Do not
+  stretch a label whose sentence reads false - a wrong edge is worse than a weak one, because
+  it is machine-readable and will be believed.
+
+## Scope
+
+Covers labels on `related:` edges between pages. Says nothing about `sources:` (the provenance
+field, unlabelled by construction), `[^cite-id]` footnotes
+([kb/CONTRACT.md](../kb/CONTRACT.md#provenance-and-citation)), or `tags:` (search keys, not
+relationships).

instructions/mcp-read-server.md

@@ -0,0 +1,108 @@
+---
+type: types/instruction.md
+name: mcp-read-server
+description: Run and keep current the MCP read server that serves this wiki to a second consumer
+---
+
+# Running the MCP read server
+
+Chemenu has a second consumer. `search`, `types`, `describe_type`, `lint` and `status` are
+served over MCP to callers that are not this terminal - the CLI and the server are two adapters
+over one core (`chemenu.api.Corpus`), not a CLI with a network interface bolted on.
+
+This document is about *operating* it: how to start it, what has to be true of the checkout it
+serves, and how that checkout stays current. What it exposes and why is in
+[tools/CONTRACT.md](../tools/CONTRACT.md) and in the module's own docstring
+(`tools/chemenu/mcp/server.py`).
+
+**Deployment is deliberately not here.** Which cluster, which ingress host, where the credential
+lives - that is private infrastructure and this is a public repository. What is here is
+everything an operator needs that is *true of the software* rather than of one installation.
+
+## When to run
+
+- Standing something up for a consumer that is not a terminal on this machine.
+- Diagnosing an answer that looks stale, or one that disagrees with the CLI.
+- Before pointing a new consumer at an existing server.
+
+## Steps
+
+1. **Install the server's dependency.** It is deliberately not in `requirements.txt`: an
+   instance that only uses the CLI should not be made to install pydantic, starlette, uvicorn
+   and cryptography to do it.
+
+   ```bash
+   tools/.venv/bin/pip install -r tools/requirements-mcp.txt
+   ```
+
+2. **Decide which checkout it serves.** The root resolves by precedence - an explicit `--root`,
+   then `$CHEMENU_ROOT`, then the checkout the package lives in. A deployment points at its
+   corpus with one variable and no code:
+
+   ```bash
+   export CHEMENU_ROOT=/srv/chemenu
+   ```
+
+3. **Take tracing out of the served tree.** The server refuses to start otherwise, and the
+   refusal is the point: telemetry defaults to on and writes under `reports/telemetry/` inside
+   the repo, which step 5's sync is entitled to wipe. Either is fine:
+
+   ```bash
+   export WIKI_TRACE=0                      # off
+   export WIKI_TRACE_DIR=/var/log/chemenu   # or elsewhere, outside the corpus
+   ```
+
+4. **Start it on the transport that matches what is in front of it.**
+
+   ```bash
+   tools/.venv/bin/python -m chemenu.mcp                                # stdio
+   tools/.venv/bin/python -m chemenu.mcp --transport streamable-http    # deployed
+   ```
+
+   `stdio` is for developing and testing without a network - one process per consumer, started
+   locally. `streamable-http` is what a deployed instance speaks, and the only one the
+   authentication middleware can sit in front of, because that middleware is an HTTP reverse
+   proxy. `sse` is reachable through the SDK and deliberately not offered: it is the superseded
+   remote transport, and building on it now only moves the migration later.
+
+5. **Keep the checkout current by polling, and keep it clean.**
+
+   ```bash
+   git -C "$CHEMENU_ROOT" fetch --quiet origin && \
+     git -C "$CHEMENU_ROOT" reset --hard --quiet origin/main
+   ```
+
+   Every few minutes, from a timer beside the server. Polling rather than a webhook on purpose:
+   it needs no inbound endpoint and no signature checking, which is a smaller surface than the
+   thing it would optimize. A webhook is a later optimization, not a starting point.
+
+   `reset --hard` is load-bearing, not a convenience. The corpus cache reuses a parse while the
+   commit is unchanged and **refuses to cache a dirty tree at all**, so a checkout that has
+   drifted answers correctly but reparses on every request - and every answer it gives is
+   stamped `"commit": null`, because a dirty tree corresponds to no revision.
+
+## Decision points
+
+- **An answer looks stale?** Read `commit` in the response. If it names an old revision, the
+  sync is not running. If it is `null`, the served tree has uncommitted changes - something is
+  writing into the corpus that should not be.
+- **The server disagrees with `wikitool` on the same query?** That is a defect, not a
+  configuration difference: the two go through the same functions and a golden test holds their
+  output together (`tools/chemenu/tests/test_mcp_server.py`). Check first that both are pointed
+  at the same root - `CHEMENU_ROOT` is easy to set for one and not the other.
+- **Asked to expose a write tool?** There is none, and the way to add one is not a flag. The
+  server imports nothing under `chemenu.commands`, so `new`, `touch`, `xref`, `cite`, `publish`
+  and `migrate` are unreachable from it rather than filtered out of a list. Submitting documents
+  from outside is a different design with a quarantine in it - Gitea #32 - not a tool added
+  here.
+- **Asked to rate-limit inside the server?** Rate limiting belongs in the middleware in front of
+  the process, next to authentication. Not the Iteration Budget Gate: that exists to stop an
+  agent *session* from iterating unnoticed over the wiki's state, which is why retrieval is
+  exempt from it, and using it as a rate limiter would dilute it into one.
+
+## Scope
+
+Not for setting up an instance ([setup-instance.md](setup-instance.md)) or a fresh clone
+([bootstrap.md](bootstrap.md)). Not for the authentication or rate-limiting middleware, which is
+infrastructure configuration rather than part of this repository. Not a write path: see the
+decision point above.

instructions/migrations/3.0.0-authoring-conventions.md

@@ -0,0 +1,150 @@
+---
+type: types/instruction.md
+name: 3.0.0-authoring-conventions
+description: 'Adopt the instance-owned authoring conventions introduced in 3.0.0 - write kb/CONVENTIONS.md, declare profile:/required_by_stack: on every COLLECTION.md, and replace kb/CONTRACT.md with the shipped one.'
+manual: true
+migrates_to: 3.0.0
+migration_kind: mechanical
+---
+# Adopt this instance's own authoring conventions (3.0.0)
+
+Until 3.0.0, the rules for writing a page were split by *location*: everything about `kb/` sat
+in `kb/CONTRACT.md`, a file every distribution ships verbatim. Half of it was never the stack's
+to decide - the language pages are written in, the three tool-owned section headings, the naming
+forms, the tone, the relationship labels, the confidence rubric - so an instance that wanted
+something else edited a file the stack also ships, and an upstream merge handed the stack's
+answer back.
+
+3.0.0 splits it by *ownership* instead. `kb/CONTRACT.md` keeps only what `wikitool` enforces;
+everything else moves into a new `kb/CONVENTIONS.md` that belongs to this instance, and each
+`kb/<name>/COLLECTION.md` now declares what it is. The compiler reads its section headings from
+that file rather than from `tools/chemenu/sections.py`.
+
+**No page changes.** Not one line under `kb/entities/`, `kb/concepts/`, `kb/sources/` or
+`kb/comparisons/` is touched. What changes are the contracts beside them, which is why this is
+`mechanical` and takes minutes rather than a workshop.
+
+## When to run
+
+After installing 3.0.0 machinery over an instance that was on 2.x, when `tools/wikitool doctor`
+reports `FAIL conventions` or `tools/wikitool docs verify` reports a `COLLECTION.md` with no
+frontmatter. `tools/wikitool migrate status` names this document.
+
+**Until it has run, the compiler answers out of a fallback.** `xref add` and `cite add` write
+`## Beziehungen` / `## Siehe auch` / `## Fußnoten` - what this stack hardcoded before the
+conventions file existed. That is correct for a corpus written under them and wrong for any
+other, so run this before the next `wiki-ingest` or `wiki-manage`, not afterwards.
+
+## Steps
+
+1. **Replace `kb/CONTRACT.md` from the release.** It is machinery that happens to live under a
+   content directory, and the tarball update path used to skip it (see `INSTALL.md`, which now
+   names it explicitly). The 3.0.0 version is roughly half the length of the 2.x one - the
+   removed half is what step 2 is about to write into a file of yours.
+
+   ```bash
+   cp <unpacked-release>/kb/CONTRACT.md kb/CONTRACT.md
+   ```
+
+   A private instance cloned from an upstream takes it with the merge instead - see
+   [private-instance.md](../private-instance.md), whose update procedure now re-takes the
+   upstream side for exactly this path.
+
+2. **Write `kb/CONVENTIONS.md`.** Two ways in, and the first is almost always right:
+
+   - **This instance writes German pages** (it did, unless you changed it): copy the release's
+     `kb/CONVENTIONS.md.template` and fill it from the `german` profile in
+     [kb-profiles.md](../kb-profiles.md) - whose worked full text is the origin repo's own
+     `kb/CONVENTIONS.md`. Everything in it was already true of your corpus; it was simply
+     written down somewhere you did not own.
+   - **You had changed the language**, and therefore hold local edits to `kb/CONTRACT.md`,
+     `types/*.md` and `tools/chemenu/sections.py`: those edits are what this file replaces. Copy
+     the canonical heading names out of your old `sections.py` into `sections:`, the labels and
+     tone rules out of your old `kb/CONTRACT.md`, then **discard the local edits under `tools/`
+     and `types/`** and take the shipped versions. That is the whole point of the change: there
+     is nothing left to patch there.
+
+   The minimum the tool needs is the frontmatter:
+
+   ```yaml
+   ---
+   language: de
+   profile: german
+   sections:
+     relationships: Beziehungen
+     see_also: Siehe auch
+     footnotes: Fußnoten
+   ---
+   ```
+
+   Set `sections:` to the names **your existing pages already carry**, not to what you would
+   prefer. Changing them is a separate, real corpus migration; `section_aliases:` is how it is
+   done page by page ([migrate-corpus.md](../migrate-corpus.md)).
+
+   Drop the `wikitool:template-unfilled` sentinel line while filling it in - `doctor` FAILs on a
+   renamed-but-unanswered template exactly as it does for `USER.md`.
+
+3. **Declare each collection.** Two frontmatter lines at the top of every
+   `kb/<name>/COLLECTION.md`:
+
+   ```yaml
+   ---
+   profile: <the entry in instructions/kb-profiles.md this contract came from, or none>
+   required_by_stack: false
+   ---
+   ```
+
+   `required_by_stack: true` on `kb/sources/` and **nowhere else**. It is not a preference:
+   `sources coverage`, `[^cite-id]` resolution and `kb/provenance.md` resolve against that name,
+   and `docs verify` checks the field against the stack's own list in both directions.
+
+   For the four default collections, the shipped `kb/<name>/COLLECTION.md.template` files carry
+   the right values already.
+
+4. **Verify.** All three must pass:
+
+   ```bash
+   tools/wikitool doctor          # `conventions` must be OK
+   tools/wikitool docs verify
+   tools/wikitool lint
+   ```
+
+   `migrate verify` is deliberately not in that list: it compares pages, and no page changed.
+   Running it would report nothing and prove nothing.
+
+5. **Record it.**
+
+   ```bash
+   tools/wikitool migrate done 3.0.0 --pages 0
+   ```
+
+   `--pages 0` is honest, not a placeholder - see the note under step 1.
+
+## How to tell a migrated instance from an unmigrated one
+
+`kb/CONVENTIONS.md` exists, carries no `wikitool:template-unfilled` line, and names all three
+slots under `sections:`; every `kb/*/COLLECTION.md` opens with a frontmatter block; and
+`kb/CONTRACT.md` has a `## Language and identifiers` heading rather than a `## Language` one.
+`doctor` answers all of that in one call.
+
+## Decision points
+
+- **`doctor` says `conventions: FAIL` after step 2?** It prints which slot is missing. The three
+  keys are `relationships`, `see_also` and `footnotes` - the *slot* names are fixed, only their
+  values are yours.
+- **A collection this instance invented, with no profile behind it?** `profile: none`. The field
+  records where the text came from; it is free text and `docs verify` does not check it against
+  the catalogue, because an invented collection has no entry there to name.
+- **Tempted to point `profile:` at the catalogue instead of copying the text?** Do not. An
+  adopted profile is a copy; a reference would put your binding authoring rules in a file the
+  stack ships and upgrades, which is the arrangement 3.0.0 exists to end.
+- **Your old `kb/CONTRACT.md` had local edits you still want?** They belong in
+  `kb/CONVENTIONS.md` now. If something you edited has no home there, it was a stack rule you
+  overrode - file it as an issue against the origin repo rather than re-applying it.
+
+## Scope
+
+One instance's contracts, once. It changes no page, no frontmatter on a page, and nothing under
+`raw/`. The machinery half of the 3.0.0 upgrade - copying `tools/`, `types/`, `instructions/`,
+`AGENTS.md`, `VERSION` and `.wikitool-release.json` - is `INSTALL.md`'s, and has to have
+happened before step 1.

instructions/migrations/4.0.0-link-taxonomy.md

@@ -0,0 +1,153 @@
+---
+type: types/instruction.md
+name: 4.0.0-link-taxonomy
+description: Move every relationship from free-text prose in a body bullet to a labelled edge in related:, and every tool-owned body region from heading-matching to a marker pair.
+manual: true
+migrates_to: 4.0.0
+migration_kind: assisted
+obligation: required
+---
+# Move relationships into the data, and generated regions behind markers (4.0.0)
+
+Until 4.0.0 the stack used **prose as an identifier** in three places, and each one cost
+something measurable:
+
+| Was the identifier | Cost |
+|---|---|
+| A section's heading text (`## Beziehungen`) | The KB language was a compiler constant, and the region's *end* was a guess. Content sitting after it was silently deleted on eight pages |
+| A relationship label in a body bullet (`- **hängt ab von:**`) | Nothing could check the vocabulary, so it drifted to **152 distinct labels** across 337 bullets against thirteen that were documented |
+| The reciprocal half of every edge | `xref add` mirrored every link, which made per-collection label authorisation impossible and filled `## Siehe auch` with 555 unlabelled bullets, 353 of them provably redundant |
+
+4.0.0 replaces all three. A region is delimited by a marker pair and rendered from frontmatter;
+a label is a machine value in `related:`, drawn from a catalogue and authorised per destination
+by the source collection; an edge is authored in one direction and the inbound view is computed.
+
+**This one touches pages.** Unlike 3.0.0 it is not a contract reshuffle: every `related:` entry
+and every tool-owned body region changes. It is `assisted` because there is no mapping table -
+mapping free-text German onto a 35-label catalogue is a judgment call per edge, and a large
+minority of the old labels are reverse directions that under the new model are not stored at all.
+
+## When to run
+
+After installing 4.0.0 over an instance on 3.x. `tools/wikitool migrate status` names it, and
+`lint` reports `unlabelled_edges` for every unconverted edge - that count reaching zero is how
+you know the run is finished.
+
+**Nothing breaks while it is outstanding.** Unlabelled edges and undelimited regions are read,
+not rejected: `links.py` treats a bare title as an edge whose label is not declared yet, and
+`provenance.split_cite_block` falls back to the pre-marker layout. That is deliberate - a corpus
+has to stay readable while it is being converted - and it is why the two lint findings stay
+advisory for as long as `kb_version` is below 4.0.0, which is exactly as long as this document
+is outstanding.
+
+## Steps
+
+1. **Rewrite `kb/CONVENTIONS.md`'s `sections:` block.** Three slots become two, because the
+   See Also region is gone:
+
+   ```yaml
+   sections:
+     links: <your heading for declared relationships>
+     footnotes: <your heading for citation definitions>
+   ```
+
+   Delete `section_aliases:` if you have one - nothing matches on heading text any more, so
+   there is nothing to alias. The heading is now a *rendering* value: changing it re-renders
+   the words above each region on the next write and can no longer split a page.
+
+2. **Add an `outbound:` block to every `kb/<name>/COLLECTION.md`.** Which labels a page may use,
+   per destination collection, with `any` as a wildcard:
+
+   ```yaml
+   outbound:
+     entities: [depends-on, runs-on, uses, see-also]
+     concepts: [implements, see-also]
+   ```
+
+   The catalogue to draw from is [link-taxonomy.md](../link-taxonomy.md); the four contracts in
+   the origin repo are worked examples. **The source collection decides** - that is what makes a
+   35-label palette usable, and it is why the reverse edge can no longer be written
+   automatically. A destination you do not list authorises nothing, which is a real answer.
+
+3. **Fix your page type-spec templates.** If you adopted the 3.0.0 templates, they contain
+   `## {section.relationships}` and `## {section.see_also}`. Those variables no longer exist and
+   would be written into new pages literally. **Delete both sections from the `## Template`
+   block** - a template must not scaffold a tool-owned region at all: it is generated between
+   markers on the first `xref add` / `cite add` and re-rendered on every write.
+
+4. **Convert the corpus**, following [migrate-corpus.md](../migrate-corpus.md). Cut it into
+   units sized against the iteration budget; the origin repo used four, ~45 pages each. Per page:
+
+   - For each labelled bullet under the old relationships heading: say the sentence
+     `[this page] <label> [target]` and pick the catalogue label that makes it true. If it only
+     reads true **backwards**, the edge belongs on the other page - move it there rather than
+     inventing an inverse label the catalogue does not have.
+   - For each bare `- [[X]]` bullet under the old See Also heading: drop it if a labelled edge
+     already connects the pair. Otherwise decide - a real label, or dropped with the reason
+     recorded. **Do not convert them to `see-also` in bulk.** That is the one shortcut this
+     migration explicitly refuses: it would start the new taxonomy with most of its edges on its
+     weakest label, which is the sediment the change exists to remove.
+   - Write edges with `tools/wikitool xref add --a "<A>" --b "<B>" --rel <label>`, never by
+     hand. The body region is rendered from `related:`; editing inside a marker pair is
+     overwritten without warning.
+   - `cite sync` converts a page's old footnote block into a marked region in passing.
+
+5. **Check each unit mechanically before anything else:**
+
+   ```bash
+   tools/wikitool migrate verify --from <pre-migration rev> --path kb/<area> --fail-on-error
+   ```
+
+   It compares wikilink and citation **counts**, footnote definitions, H1, structural
+   frontmatter, and - new in 4.0.0 - the **count of marker pairs per region**. A dropped marker
+   is otherwise silent: the region becomes ordinary prose and the next write appends a second
+   one beside it.
+
+6. **Record it. The checks tighten themselves:**
+
+   ```bash
+   tools/wikitool lint          # unlabelled_edges and unauthorised_labels must be 0
+   tools/wikitool migrate done 4.0.0 --pages <N>
+   ```
+
+   Only once `lint` reports zero of both is the run finished. The two findings are advisory
+   while `kb_version` is below 4.0.0 and hard from the moment `migrate done` records it -
+   nothing to flip by hand, and no window in which a half-converted corpus is refused by the
+   check that is measuring its progress.
+
+   Do not record the migration to silence the findings. The promotion is what makes the run
+   stick: after it, a bare title in `related:` is a hard error rather than a page still
+   waiting, so a corpus recorded early fails its next lint instead of quietly keeping the old
+   shape.
+
+## How to tell a migrated page from an unmigrated one
+
+Its `related:` entries are `- <label>: <title>` rather than bare titles, and its relationship
+and footnote sections sit between `<!-- wikitool:links -->` / `<!-- wikitool:footnotes -->`
+marker pairs. `tools/wikitool links show --page "<Title>"` prints `unlabelled` for every edge
+still waiting, and `lint`'s `unlabelled_edges` count is the corpus-wide version of the same
+question.
+
+## Decision points
+
+- **A label you want is not in the catalogue?** Add it - a row in `link-taxonomy.md` and an
+  entry in the authorising `COLLECTION.md`. No code change is involved, and the registers are
+  advisory groupings rather than a schema. Do not stretch a label whose sentence reads false: a
+  wrong edge is worse than a weak one, because it is machine-readable and will be believed.
+- **`related:` holds an entry with no body bullet to derive a label from?** Expected - the
+  origin repo found 480 edges against 337 bullets, because frontmatter and body had already
+  drifted apart while the label lived only in prose. Read the page and decide; that drift is
+  itself part of what this migration repairs.
+- **A page loses its last inbound edge?** The orphan check will now report it, and that is the
+  check working: directional edges mean a page nothing points at is genuinely unreachable, where
+  the old mirrored model always manufactured a back-link. Either something should point at it,
+  or it is reached through the catalog and that is fine.
+- **Tempted to keep writing reverse edges for navigation?** Do not. `links show` computes the
+  inbound view, and the rendered bullet on the asserting page is an ordinary `[[wikilink]]`, so
+  a backlink panel in an editor already shows it.
+
+## Scope
+
+The corpus under `kb/`, plus the three instance-owned declarations in steps 1-3. It does not
+touch `raw/`, and it learns nothing new: the same knowledge is restated in a form that can be
+checked. Installing the 4.0.0 machinery itself is `INSTALL.md`'s and must have happened first.

instructions/private-instance.md

@@ -0,0 +1,213 @@
+---
+type: types/instruction.md
+name: private-instance
+description: Set up a private working instance as a clone of a public upstream, so stack updates arrive by merge instead of by copying a tarball over the tree.
+---
+
+# Set up a private instance against a public upstream
+
+The distribution path in [setup-instance.md](setup-instance.md) builds an instance from a
+`dist export` tarball, with no git ancestry in common with the repo it came from. That is the
+right shape for someone who only ever *consumes* the stack.
+
+This is the other shape: a private instance that keeps taking stack changes from a public
+upstream, and whose own content must never travel back. It costs one safeguard to set up and
+saves the whole update procedure afterwards.
+
+**Read this before, not after, the first `publish`.** The gate in step 4 is the thing that makes
+the arrangement safe, and adding it later means the window it closes was open in between.
+
+## Why a clone rather than a tarball
+
+`INSTALL.md`'s "Eine Instanz aktualisieren" is `cp -r` as an upgrade strategy: copy `tools/`,
+`types/`, `instructions/`, `AGENTS.md`, `VERSION` over the existing tree. It has no three-way
+merge, so it cannot notice that the receiving instance changed a file, and it has no conflict
+surface, so nobody learns when upstream and local both touched the same one. It overwrites
+silently.
+
+A clone gets all of that from git. Stack changes land as real merges, with real conflicts where
+they conflict.
+
+**What a plain `git merge` does *not* give you is protection from the upstream's content.** The
+private `main` deletes the demo corpus once, but that deletion does not make later upstream
+changes to those paths go away. Measured, not assumed:
+
+| Upstream does | `git merge upstream/main` does |
+|---|---|
+| modifies a page you deleted | `CONFLICT (modify/delete)` - and **leaves the upstream version in your working tree**. Resolve it with `git add -A` and the demo page is back. |
+| adds a new page | stages it **silently**. No conflict, no prompt, no mention. |
+| deletes a page you also deleted | nothing. The only harmless case. |
+
+The middle row is the one that matters, because nothing announces it. An upstream that ships a
+demo corpus *and* uses it as a test bed will add pages, and each one arrives in your instance
+and starts showing up in your `lint`, your `index`, your `search` and your `confidence decay`.
+
+So the merge has to be scoped. That is the procedure below, and it is not optional.
+
+## Steps
+
+1. **Clone, and name the two remotes for what they are.**
+
+   ```bash
+   git clone <private-repo-url> my-wiki
+   cd my-wiki
+   git remote add upstream <public-repo-url>
+   ```
+
+   `origin` is yours and is the only thing you ever push to. `upstream` is where stack updates
+   come from and is fetch-only.
+
+2. **Make the fetch-only half fetch-only in git, too.**
+
+   ```bash
+   git remote set-url --push upstream no_push
+   ```
+
+   git refuses to push to a URL it cannot resolve. This is a convenience, not the safeguard -
+   step 4 is the safeguard.
+
+3. **Delete the upstream's demo corpus once, on your own `main`.**
+
+   Everything under `kb/` and `raw/` that came with the clone is the upstream's content, not
+   yours. Remove it with `wikitool rm --page` (never `rm -rf`: `rm` de-links each page from the
+   rest of the wiki, and a plain delete leaves dead wikilinks and broken citations behind), then
+   `index rebuild`, `sources rebuild-index`, `lint`.
+
+   This is a one-time cut. Afterwards the upstream corpus is frozen from your side, which is
+   what makes later merges content-free.
+
+4. **Arm the Publish-Remote Gate — before the first `publish`.**
+
+   ```bash
+   cat > .wikitool-remotes.json <<'EOF'
+   { "schema": 1, "allowed_push_urls": ["<your-private-push-url>"] }
+   EOF
+   ```
+
+   Use the URL `git remote get-url --push origin` prints, exactly. `publish` refuses with exit
+   42 for anything else, and there is no flag that opens it - see [gates.md](gates.md).
+
+   The file is gitignored, so it stays with this checkout and never travels to the upstream.
+   `wikitool doctor` reports whether the gate is armed, and WARNs at more than one remote
+   without it.
+
+5. **Take away the write credential, if you can.** A token or deploy key for `origin` only,
+   with no write access to the upstream, is the one control that holds even if everything above
+   is misconfigured. Belt and braces.
+
+6. **Personalize and bootstrap.** `USER.md`, `SOUL.md` and optionally `ENVIRONMENT.md` are
+   yours and unrelated to the upstream's - see the Personalization step of
+   [setup-instance.md](setup-instance.md), then [bootstrap.md](bootstrap.md) for the venv and
+   the skills.
+
+   A clone inherits the upstream's `kb/CONVENTIONS.md` and `kb/*/COLLECTION.md` rather than
+   templates, because it inherits the upstream's whole tree. They are yours from this point on:
+   rewrite them if this instance writes its pages differently - the update procedure below
+   restores them on every merge, so the change sticks. [kb-profiles.md](kb-profiles.md) has the
+   alternatives.
+
+## Taking a stack update
+
+Take the machinery, never the content. The merge is held open, the content stages are forced
+back to your own state, and only then does it close.
+
+**Three files under those stages are machinery, not content**, and forcing them back is how an
+upstream contract change gets silently discarded:
+
+| Path | Why it must take 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 |
+| `kb/CONVENTIONS.md.template` | The template your `kb/CONVENTIONS.md` was filled 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
+`kb/<name>/COLLECTION.md` included - they bind your corpus, and they are exactly what the
+restore below is protecting.
+
+```bash
+BEFORE=$(git rev-parse HEAD)
+git fetch upstream
+
+# --no-commit holds the merge open; it may report conflicts under kb/ or raw/,
+# which the next four lines are about to make irrelevant.
+git merge --no-commit --no-ff upstream/main || true
+
+# Whatever the merge did to the content stages, undo it. HEAD is still your
+# 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
+*adds* arrives with no conflict and no message. You would find out when `lint` starts reporting
+pages you never wrote - if you noticed at all.
+
+## Where stack development happens
+
+**In the public repo, not here.** That is not a preference; the stack is built that way. The
+development-only half of the instruction layer is pruned from a distribution one-way, with no
+command that reconstructs it, so an instance built this way has no tool-development mode to
+switch into in the first place.
+
+When a tool bug blocks real content work here - and it will - file the issue against the public
+repo (an MCP server or the web UI reaches it from any session; no shared history needed), fix it
+there where the tests, `docs verify` and CI's version gate live, and take the fix back with the
+merge above. Nothing is lost by the detour: the fix has to pass that CI either way.
+
+## Decision points
+
+- **Merge conflict in `kb/` or `raw/`?** Expected, and already handled: the update procedure
+  above overwrites those stages with your own afterwards, so the conflict resolves itself.
+  Never resolve one by hand with `git add -A` - that is exactly how the upstream version, which
+  git left sitting in your working tree, gets committed into your instance.
+- **`git diff` after the merge shows something under `kb/` or `raw/`?** Stop - unless it is one
+  of the three machinery paths the check excludes, which is the update working as intended. For
+  anything else the scoping step did not take: do not publish; find out which path came through
+  and where from.
+- **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
+  change as an issue there.
+- **...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
+  rules in `kb/<name>/COLLECTION.md` - all under `kb/`, all yours, all restored by the merge
+  procedure rather than overwritten by it. If you find yourself editing `tools/` or `types/` to
+  change an authoring convention, that is a stack bug: file it, because the split exists
+  precisely so you do not have to.
+
+## Scope
+
+Not for a first instance with no upstream - that is [setup-instance.md](setup-instance.md). Not
+for a fresh clone of a repo you already own and develop in - that is
+[bootstrap.md](bootstrap.md). This is specifically the two-remote case, where the cost of a
+mistaken push is disclosure rather than inconvenience.

instructions/setup-instance.md

@@ -60,24 +60,71 @@ bereit für den ersten `Ingest`.
    - Nicht genannt: lokal bleiben - dann braucht **jeder** spätere `tools/wikitool publish`
      ein `--no-push` (dessen Branch-Prüfung dabei ohnehin entfällt, siehe Schritt 2).
 
-5. **Entscheidungspunkt - KB-Sprache.** Frage den Nutzer, in welcher Sprache die Seiten unter
+5. **Entscheidungspunkt - Autorenkonventionen.** Die Distribution bringt keine ausgefüllten
-   `kb/` geschrieben werden sollen. Diese Instanz erbt aus dem Quell-Repo **Deutsch** - sowohl die
+   Konventionen mit, sondern `kb/CONVENTIONS.md.template` und je Collection ein
-   Regel in [kb/CONTRACT.md](../kb/CONTRACT.md#language) als auch das Vokabular in
+   `kb/<name>/COLLECTION.md.template`. Beide **binden**, sobald sie übernommen sind, und beide
-   [german-terminology.md](german-terminology.md) und die deutschen Abschnittsnamen in
+   gehören dieser Instanz - deshalb liefert der Stack nur die Vorlage. Die eine Entscheidung
-   `tools/chemenu/sections.py`. Das ist eine Entscheidung der Ursprungsinstanz, keine
+   dahinter ist: **in welcher Sprache und in welchem Ton schreibt diese Instanz ihre Seiten?**
-   Eigenschaft des Musters, und sie wird hier nicht stillschweigend weitergereicht.
 
-   - **Deutsch bestätigt:** nichts zu tun.
+   Ablauf:
-   - **Andere Sprache:** *vor dem ersten Ingest* umstellen, denn danach ist es eine Migration
-     jeder vorhandenen Seite. Zu ändern sind der Abschnitt "Language" in `kb/CONTRACT.md`, die
-     Tonfall-Beispiele und Hedge-Wörter darunter, die vier Page-Type-Templates in `types/`, die
-     kanonischen Namen in `sections.py` (die bisherigen als Alias behalten) und die
-     Beziehungslabels in `kb/CONTRACT.md` § Linking. `german-terminology.md` wird dann ersetzt
-     oder gelöscht.
 
-   Unverändert bleibt in jedem Fall die eigentliche Regel: **jede Zeile einer Seite ist Prosa
+   1. Die Collection-Contracts **und die Page-Type-Specs** übernehmen - Kopien, keine Frage an
-   oder Identifier, und nur Prosa wird übersetzt.** Titel, Wikilink-Ziele, Cite-IDs, Enum-Werte,
+      den Nutzer, denn was dort steht ist als Ausgangspunkt unabhängig von der Sprache brauchbar:
-   Tags, Befehle und Pfade folgen keiner KB-Sprache.
+
+      ```bash
+      for template in kb/*/COLLECTION.md.template types/*.template; do
+        cp "$template" "${template%.template}"
+      done
+      ```
+
+      Die `.template`-Dateien bleiben liegen; sie sind die Vorlage für den nächsten Export.
+
+      Unter `types/` betrifft das genau die Type-Specs mit `root: kb` - `entity`, `concept`,
+      `source`, `comparison` - samt ihrer `.schema.yaml`. Sie beschreiben Seiten, die *diese*
+      Instanz schreibt, also gehören sie ihr: Prosa, Template und Sprache dürfen umgeschrieben
+      werden. `instruction`, `lint-report` und `type-spec` beschreiben Stack-Artefakte und
+      kommen unverändert.
+
+   2. Den Nutzer nach der KB-Sprache fragen. `kb/CONVENTIONS.md.template` ist auf **Englisch**
+      voreingestellt; [kb-profiles.md](kb-profiles.md) hält daneben ein vollständiges
+      deutsches Profil bereit, und dessen Volltext ist die `kb/CONVENTIONS.md` des Quell-Repos.
+      Der Profilkatalog ist eine **Palette, kein Enum**: übernommen wird der Text *in* die
+      Instanzdatei, nicht ein Verweis auf den Katalog.
+
+   3. `kb/CONVENTIONS.md.template` nach `kb/CONVENTIONS.md` kopieren, entlang des gewählten
+      Profils ausfüllen - Sprache, Abschnittsnamen, Namensformen, Ton, Beziehungslabels,
+      Confidence-Rubrik - und dabei die Sentinel-Zeile (`wikitool:template-unfilled`) entfernen.
+      Die Platzhalter in geschweiften Klammern **sind** der Fragenkatalog.
+
+   4. Bei einer anderen Sprache als der des Quell-Repos: `german-terminology.md` löschen oder
+      durch das eigene Vokabular ersetzen - sie ist Material des deutschen Profils, nicht des
+      Stacks.
+
+   **Vor dem ersten Ingest entscheiden.** Die `sections:`-Namen in `kb/CONVENTIONS.md` sind die
+   Überschriften, die `xref` und `cite` in jede Seite schreiben; sie danach zu ändern ist eine
+   Migration jeder vorhandenen Seite (`section_aliases:` trägt die alten Namen, siehe
+   [migrate-corpus.md](migrate-corpus.md)).
+
+   **Nichts davon liegt in einer Stack-Datei.** Der Compiler liest die Abschnittsnamen aus
+   `kb/CONVENTIONS.md`; die vier Page-Type-Specs gehören ab Schritt 1 dieser Instanz. Eine
+   anderssprachige Instanz übersetzt sie einfach - das ist kein lokaler Patch an etwas
+   Ausgeliefertem mehr, sondern Arbeit an den eigenen Dateien, und ein Upgrade nimmt sie ihr
+   nicht wieder weg.
+
+   Was der Stack von `types/` überhaupt noch verlangt, ist eine Zeile: es muss einen Type-Spec
+   mit `name: source` geben, dessen Schema `raw_files` fordert. Daran hängt der gesamte
+   `raw/`→`kb/`-Provenance-Pfad (`sources coverage`, `[^cite-id]`-Auflösung, `kb/provenance.md`),
+   und `docs verify` prüft genau das - nicht mehr.
+
+   Unverändert bleibt in jedem Fall die Regel, die dem Stack gehört: **jede Zeile einer Seite
+   ist Prosa oder Identifier, und nur Prosa wird übersetzt** ([kb/CONTRACT.md § Language and
+   identifiers](../kb/CONTRACT.md#language-and-identifiers)). Titel, Wikilink-Ziele, Cite-IDs,
+   Enum-Werte, Tags, Befehle und Pfade folgen keiner KB-Sprache.
+
+   `tools/wikitool doctor` prüft das Ergebnis in Schritt 12 (`conventions`): eine fehlende
+   Datei ist ein `FAIL`, eine mit Sentinel oder ohne vollständigen `sections:`-Block ebenso.
+   `docs verify` prüft zusätzlich `profile:` und `required_by_stack:` auf jedem
+   `COLLECTION.md`.
 
 6. **Entscheidungspunkt - Personalization.** Die Distribution bringt
    `USER.md.template` und `SOUL.md.template` mit, aber keine ausgefüllten Fassungen: wer diese

instructions/wiki-ingest/SKILL.md

@@ -61,8 +61,9 @@ pages should never have cost the concept contract. Field-level requirements alwa
    article also pass `--set source_url=<upstream URL>`; `raw_files:` must still point at the
    local copy. Then write the Summary / Key Takeaways / Action Items prose from step 4 - in the
    KB language, whatever the source's own language is, quoting verbatim passages in the
-   original. The rule and what is exempt from it:
+   original. Which language that is: [kb/CONVENTIONS.md](../../kb/CONVENTIONS.md#language).
-   [kb/CONTRACT.md](../../kb/CONTRACT.md#language).
+   What is exempt from it, in any language:
+   [kb/CONTRACT.md](../../kb/CONTRACT.md#language-and-identifiers).
 
    Fill `## Not Extracted` in the same pass: what you read and deliberately did not promote,
    with the reason. Nothing in the repository can re-derive that judgment, and without it the
@@ -70,8 +71,9 @@ pages should never have cost the concept contract. Field-level requirements alwa
 
 6. **Create or update entity pages.** Read
    [kb/entities/COLLECTION.md](../../kb/entities/COLLECTION.md) and
-   [kb/CONTRACT.md](../../kb/CONTRACT.md) first - the second is where tone, naming, provenance
+   [kb/CONTRACT.md](../../kb/CONTRACT.md) plus
-   and citation are defined.
+   [kb/CONVENTIONS.md](../../kb/CONVENTIONS.md) first - the second is where provenance and
+   citation are defined, the third where this instance's tone and naming forms are.
 
    New:
 

instructions/wiki-manage/SKILL.md

@@ -13,10 +13,12 @@ integrating into an existing one.
 
 **Before the first `wikitool` call:** [session-setup.md](../session-setup.md).
 
-**Read before drafting:** [kb/CONTRACT.md](../../kb/CONTRACT.md) - naming, tone, linking,
+**Read before drafting:** [kb/CONTRACT.md](../../kb/CONTRACT.md) - linking, provenance and the
-provenance and confidence - together with the target collection's own `COLLECTION.md`, which
+confidence machinery, all of which the tool enforces - and
-carries its quality goal and what is local to that subtree. Field-level requirements come from
+[kb/CONVENTIONS.md](../../kb/CONVENTIONS.md), which is where this instance's language, naming
-`tools/wikitool types describe <type>`.
+forms, tone and relationship labels are, together with the target collection's own
+`COLLECTION.md`, which carries its quality goal and what is local to that subtree. Field-level
+requirements come from `tools/wikitool types describe <type>`.
 
 ## Creating a page
 
@@ -46,7 +48,7 @@ carries its quality goal and what is local to that subtree. Field-level requirem
    subjects - so the prose connects to existing pages instead of restating them.
 
 5. **Draft.** Fill in the generated skeleton's TODO sections, following the tone rules in
-   [kb/CONTRACT.md](../../kb/CONTRACT.md#tone). If `provenance:` is `sourced` or `mixed`, cite
+   [kb/CONVENTIONS.md](../../kb/CONVENTIONS.md#tone). If `provenance:` is `sourced` or `mixed`, cite
    hard facts as you write them with `tools/wikitool cite add --page "<Title>" --source
    "Source - X"`, which also adds `X` to `sources:` - paste the `[^cite-id]` marker it prints.
 

kb/CONTRACT.md

@@ -7,12 +7,24 @@ material in `raw/`, and is expected to stay correct without being re-derived.
 **Quality goal:** a page should answer a future question *without* re-reading the source it
 came from. If answering still requires the raw file, the page is incomplete.
 
-This file holds the rules that apply in **every** collection. Each `kb/<name>/COLLECTION.md`
+This file holds the rules that apply in **every** collection **and in every instance**. That
-declares that it inherits them and adds only what is local to its own subtree - read this file
+second half is the cut: what is written here is enforced by `tools/wikitool` or follows from
-together with the target collection's contract before writing or editing a page.
+how it works, so it is identical everywhere and `dist export` ships it verbatim.
+
+**What an instance decides for itself is next door, in
+[kb/CONVENTIONS.md](CONVENTIONS.md)** - the language pages are written in, the headings its two
+generated regions render under, the naming forms, the tone, the confidence rubric. That file binds exactly as this one does; it is simply owned by the instance
+rather than by the stack, so the distribution ships only its `.template` and the instance writes
+the real one. Read both, plus the target collection's `kb/<name>/COLLECTION.md` (also
+instance-owned), before writing or editing a page.
+
+The split is by **who may change the sentence**, not by what it is about. Language, tone and
+naming used to sit here, which meant every instance that answered "not German" to
+`setup-instance.md` was locally editing a file the stack also ships - and a merge from upstream
+would quietly hand it back.
 
 Structural facts (which frontmatter fields exist, which are required, what the body skeleton
-looks like) are *not* here - they belong to the type-specs and are printed by
+looks like) are in neither - they belong to the type-specs and are printed by
 `tools/wikitool types describe <type>`. Never hand-write frontmatter; scaffold with
 `tools/wikitool new <type> --name "<Name>" --set field=value ...`.
 
@@ -21,7 +33,15 @@ looks like) are *not* here - they belong to the type-specs and are printed by
 `kb/` is a **namespace, not a collection**. It carries no `COLLECTION.md` of its own.
 
 A directory under `kb/` is a **collection** exactly when it contains a `COLLECTION.md`. That
-file is the local authoring contract for every page in the subtree.
+file is the local authoring contract for every page in the subtree, and it belongs to the
+instance: it declares in its frontmatter which profile from
+[instructions/kb-profiles.md](../instructions/kb-profiles.md) it adopted, and whether the stack
+resolves against it by name.
+
+| Field | Means |
+|---|---|
+| `profile:` | Which catalogue entry this contract started from, or `none`. Free text - the catalogue is a palette, not an enum, and a collection an instance invented has no entry to name |
+| `required_by_stack:` | Whether `wikitool` itself depends on this collection *by name*. Not the instance's to choose: `docs verify` checks it against the stack's own list. `kb/sources/` is `true` - `sources coverage`, `[^cite-id]` resolution and `kb/provenance.md` all resolve against that name - and everything else is `false` |
 
 - A subdirectory *inside* a collection is an **area**. It inherits the enclosing contract and
   must not carry a `COLLECTION.md` of its own - `kb/entities/systems/` is an area of
@@ -40,9 +60,11 @@ file is the local authoring contract for every page in the subtree.
 | `kb/sources/` | One summary page per ingested source, carrying its `raw_files:` provenance | [sources/COLLECTION.md](sources/COLLECTION.md) |
 | `kb/comparisons/` | Structured comparisons of two or more existing pages | [comparisons/COLLECTION.md](comparisons/COLLECTION.md) |
 
-**Adding a collection:** `mkdir kb/<name>` and write a `kb/<name>/COLLECTION.md`. Collections
+The four rows above are this instance's collections, not a fixed set. **Adding one:**
+`mkdir kb/<name>` and write a `kb/<name>/COLLECTION.md` with the two fields above. Collections
 are discovered by contract presence, so no code change is needed. A collection only becomes
-*writable* once some type-spec declares a matching `base_dir:`.
+*writable* once some type-spec declares a matching `base_dir:`. Renaming or dropping one is the
+instance's call too - except where `required_by_stack: true` says otherwise.
 
 **Where a page goes** is decided by its type-spec, never by hand - see
 [types/type-spec.md](../types/type-spec.md).
@@ -61,53 +83,41 @@ Never hand-edit these; they are produced by `tools/wikitool`:
 To *find* a page, search rather than read the catalog: `tools/wikitool search "<text>"`, or
 `tools/wikitool search --field <predicate>` for a structured query over frontmatter.
 
-## Naming
+## Titles are identifiers
 
-- Human-readable titles with spaces: `Hybrid Search.md`, `Gitea Actions.md` - not kebab-case.
+**The filename stem *is* the page title, and `[[wikilinks]]` must match it exactly.** That is
-- Singular for entities: `ha-core.md`, not `ha-cores.md`.
+not a naming preference; it is the wiki's only way to address a page. `wikitool lint` reports an
-- Comparison pages read as a comparison: `Go vs Rust.md`.
+H1 that stops matching its title, `rename`/`rm` rewrite every reference to a stem, and a
-- ADRs are prefixed: `adr-001-use-go-modules.md`.
+`[^cite-id]` resolves through one.
-- The filename stem *is* the page title, and `[[wikilinks]]` must match it exactly.
-- Prefer readability over convention when the two conflict.
 
-What to name a thing: projects use their repository or common name; systems a descriptive
+Which *form* those titles take - spaces or kebab-case, singular or plural, what prefixes a
-name; tools the tool's own name; technologies their standard spelling and capitalization;
+decision record - is the instance's, in
-people a full name or common handle.
+[kb/CONVENTIONS.md § Naming](CONVENTIONS.md#naming).
 
 ## Every page should
 
 - [ ] Carry a clear, descriptive title and a summary near the top
 - [ ] Use consistent terminology with the rest of the wiki
-- [ ] Link to every entity and concept it mentions, and be linked to in return
+- [ ] Link to the entities and concepts it mentions, and declare an edge where the relationship
+      is worth naming - in the direction this page asserts it, not in both
 - [ ] Cite its hard facts (see [Provenance and citation](#provenance-and-citation))
 - [ ] Duplicate no existing page
 - [ ] Appear in the catalog (guaranteed by `wikitool index rebuild`)
 
-## Tone
+## Quotation cap
 
-Wikipedia style: factual, neutral, specific.
+At most 2 blockquoted lines per page. `wikitool lint` reports overages as advisory, since
+exceeding the cap can be a legitimate judgment call - but the page should carry the knowledge
+itself, not delegate it to quotations. The cap is about how much of the page you let quotes
+carry; it does not apply to text you are citing verbatim from a source.
 
-- No buzzwords ("bahnbrechend", "hochmodern", "leistungsstark", "revolutioniert").
+The register those lines are written in - what counts as a buzzword, what filler is refused -
-- No AI filler ("es sei angemerkt", "es ist wichtig zu betonen", "in der heutigen Zeit").
+is the instance's, in [kb/CONVENTIONS.md § Tone](CONVENTIONS.md#tone).
-- No em-dash asides carrying parenthetical reasoning.
-- At most 2 blockquoted lines per page. `wikitool lint` reports overages as advisory, since
-  exceeding the cap can be a legitimate judgment call - but the page should carry the
-  knowledge itself, not delegate it to quotations. The cap is about how much of the page you
-  let quotes carry; it does not apply to text you are citing verbatim from a source.
 
-Good: "MQTT ist ein leichtgewichtiges Publish-Subscribe-Protokoll für Geräte mit knappen
+## Language and identifiers
-Ressourcen."
 
-Bad: "MQTT ist ein bahnbrechendes, hochmodernes Protokoll, das die IoT-Kommunikation
+*Which* language pages are written in is [kb/CONVENTIONS.md](CONVENTIONS.md)'s to say. What
-revolutioniert - und es sei angemerkt, dass es ein Publish-Subscribe-Muster verwendet."
+follows here is the part that is not a choice, because the tool resolves against it.
-
-## Language
-
-Pages are written in **German**. This binds `kb/` and the authoring surface that shapes it -
-the page type-specs `types/entity.md`, `types/concept.md`, `types/source.md` and
-`types/comparison.md`. `raw/` is untouched ([raw/CONTRACT.md](../raw/CONTRACT.md)), and the
-control plane stays English: AGENTS.md, the stage contracts including this one, `instructions/`,
-and the type-specs for non-page artifacts.
 
 Every line of a page is either **prose** or an **identifier**. Only prose is translated.
 
@@ -118,55 +128,75 @@ source page's Summary / Key Takeaways / Action Items / Not Extracted, and `summa
 
 | Identifier | Why |
 |---|---|
-| Page titles, and the H1 that repeats one | A title is the wiki's only identifier for a page and follows the subject's own established name - see [Naming](#naming). `wikitool lint` reports an H1 that stops matching its title |
+| Page titles, and the H1 that repeats one | A title is the wiki's only identifier for a page and follows the subject's own established name - see [Titles are identifiers](#titles-are-identifiers). `wikitool lint` reports an H1 that stops matching its title |
 | The subtype value on the generated `**Typ:**` line | It renders a schema enum value (`technology`, `workflow`), which `search --field` filters on. The label is prose; the value is not |
 | `tags:` | Search keys, not prose |
 | Commands, paths, config keys, hostnames, code | They are what they are |
 | Quotations | Quoted verbatim in the source's own language |
 
-Established English technical terms stay English inside German prose - "GitOps", "Ownership
+Which foreign technical terms stay untranslated inside that prose is a judgment call the
-Model", "Reverse Proxy", "Pull Request". Translate a term only where the German one is genuinely
+instance records - see [kb/CONVENTIONS.md § Language](CONVENTIONS.md#language).
-the more common usage. A coined German equivalent nobody else writes makes the page harder to
-find, not more idiomatic.
-
-Which terms those are, which have a settled German form, and the register the prose is written in:
-[instructions/german-terminology.md](../instructions/german-terminology.md). It is lookup material,
-not a second rule - every entry in it is a decision that was made wrong once first.
 
 **A source in another language** is still summarized in the KB language: a source page is
 evidence *about* a source, not a substitute for it. Quote verbatim in the original language and
 record the raw file's language in `source_language:`.
 
-### Section headings
+### Generated regions
 
-Three headings are a vocabulary the tool owns rather than prose an author picks: `xref add`
+Two regions of a page body are **generated**, not authored: the links region `xref` owns and the
-writes into Relationships and See Also, and `cite add` owns the trailing Footnotes block. They
+footnotes region `cite` owns. Each sits between a marker pair:
-follow the KB language like everything else - `## Beziehungen`, `## Siehe auch`, `## Fußnoten` -
-and `tools/chemenu/sections.py` is the single place naming them.
 
-Each has aliases the tool still *recognizes* but no longer writes, which is what lets the corpus
+```markdown
-be translated page by page: a page still carrying `## Relationships` is found and appended to
+<!-- wikitool:links -->
-correctly, and `cite sync` leaves an untranslated `## Footnotes` heading alone rather than
+## Beziehungen
-retitling it. Renaming a heading is the translation pass's job, never a side effect of another
+
-command. Any *other* heading an author adds is ordinary prose and is translated with the rest.
+- **depends-on:** [[Hermes]]
+<!-- /wikitool:links -->
+```
+
+The marker is what the tool locates the region by, and everything between the markers -
+**heading included** - is replaced wholesale on the next write. An author never edits inside
+them; anything left there is overwritten without warning, exactly as in `kb/index.md`. A region
+with nothing to show is absent rather than empty.
+
+The heading is therefore a *rendering* value, taken from `kb/CONVENTIONS.md`'s `sections:`. No
+heading text exists in the compiler, and nothing matches on it: changing the declaration
+re-renders the words on the next write and cannot split a page.
+
+That is not how it used to work. The tool located these regions by matching their heading text,
+which made a translated heading a structural fact - and made the region's *end* a guess. It ran
+to the next heading, and before that to the end of the file, which silently deleted whatever sat
+after it on eight pages. Any *other* heading a page carries is ordinary prose.
 
 ## Linking
 
-Every page links to what it mentions, in both directions. Cross-references are created with
+**An edge is authored in one direction**, on the page that asserts it, and carries a label that
-`tools/wikitool xref add --a "<A>" --b "<B>" --rel-a "<label>" --rel-b "<label>"`, never by
+is a machine value rather than prose:
-hand-editing the `related:` array or the Relationships/See Also bullets.
 
-Use a typed relationship label rather than a generic one:
+```yaml
+related:
+  - depends-on: Hermes
+```
 
-`hängt ab von` · `verwendet` · `implementiert` · `erweitert` · `ersetzt` · `steht in Konflikt mit`
+Created with `tools/wikitool xref add --a "<A>" --b "<B>" --rel <label>`, never by hand-editing
-· `benötigt` · `erzeugt` · `konsumiert` · `besitzt` · `pflegt` · `läuft auf` · `verwandt mit`
+`related:` or the rendered bullet. Say the sentence before choosing the label - `[A] <label>
-(last resort)
+[B]` - and if it only reads true backwards, the edge belongs on the other page.
 
-The labels are prose written into a `- **label:** [[Title]]` bullet; no code matches on them, so
+**A reverse edge is a separate decision, not a mirror.** Write one when it independently helps a
-an untranslated page's English label is stale wording, not a broken reference.
+reader at the other end; do not write one to make the graph symmetric. Navigation does not
+depend on it either way: `index rebuild` renders the inbound view from the graph, completely and
+without maintenance.
 
-A page is expected to have at least one inbound link; `wikitool lint` reports orphans.
+Which labels exist is [instructions/link-taxonomy.md](../instructions/link-taxonomy.md), a
-Comparison pages are exempt - they are reached through the catalog.
+palette that binds nothing. Which of them a page may *use* is its own collection's `outbound:`
+block, per destination - the **source** collection decides, because the rules that govern an
+edge are the rules of the collection asserting it. `xref add` refuses an unauthorised label and
+`lint` reports one.
+
+A page is expected to have at least one inbound edge; `wikitool lint` reports orphans.
+Comparison pages are exempt - they are reached through the catalog. Directional edges mean more
+pages qualify than under the old mirrored model, and that is the check measuring reachability
+rather than measuring whether `xref` ran.
 
 Renaming a page, deleting one, or dropping a single reference are tool operations with their
 own procedure: see [instructions/page-lifecycle.md](../instructions/page-lifecycle.md).
@@ -187,15 +217,16 @@ Every claim is either traceable to a raw file or explicitly marked as not.
   command, or config value. `tools/wikitool cite add --page "<Title>" --source "Source - X"
   [--file <qualifier>]` mints the id, upserts its `[[Source - X]]` (or
   `[[Source - X|storage-model.md]]` for a multi-file source) definition in the page's trailing
-  `## Footnotes` block, and adds `Source - X` to `sources:` - it prints the marker to paste at
+  Footnotes block (named per [Section headings](#section-headings)), and adds `Source - X` to
+  `sources:` - it prints the marker to paste at
   the fact; placing it is still manual. Never hand-type a cite-id (AGENTS.md invariant 1). This
   differs from a plain `[[Source - X]]` link, which only means "related to".
 - **Notation inside code is notation, not a reference.** A `[^cite-id]` or a `[[wikilink]]`
   written in backticks or a fenced block is read as an example: the citation does not count and
   the link does not exist. That is what lets a page document this stack's own syntax. It also
-  means a marker appended to a line *inside* a fence cites nothing - put it on a
+  means a marker appended to a line *inside* a fence cites nothing - put it on a source line
-  `Quelle: [^cite-id]` line under the block, where it renders as a footnote instead of
+  under the block (`<source-word>: [^cite-id]`, in the KB language), where it renders as a
-  travelling with the command when someone copies it.
+  footnote instead of travelling with the command when someone copies it.
 - A source cited inline must also appear in the page's frontmatter `sources:` list;
   `wikitool lint` checks this in both directions, and hard-errors on a leftover pre-migration
   `^[[...]]` marker, an undefined `[^cite-id]` reference, or an orphaned Footnotes definition.
@@ -215,23 +246,20 @@ one - and never file the synthesized version back into the wiki.
 `confidence` is *derived* from it by `tools/wikitool confidence decay` and must never be
 edited directly.
 
-Base score for a single source is 0.5, adjusted by:
-
-- **+0.2 per supporting source** (max +0.6)
-- **+0.2** if confirmed <30 days ago, **+0.1** if <90 days
-- **+0.1** for official documentation, **+0.05** for a reputable secondary source
-- **+0.1** if multiple independent sources agree
-
 Re-assess a page with `tools/wikitool touch --page "<Title>" --confidence-base <value>`.
 
-In prose, hedge according to the score: below 0.6 write "möglicherweise"/"kann"; below 0.4
+What the number *means* - the base score, what raises it and by how much, and how to hedge in
-write "unsicher"/"unbestätigt".
+prose below a threshold - is a rubric rather than a mechanism, so it is
+[kb/CONVENTIONS.md § Confidence rubric](CONVENTIONS.md#confidence-rubric)'s.
 
 ## What does not belong here
 
 - Raw source material - it stays immutable under `raw/`.
 - Type definitions, frontmatter contracts, or templates - those live in `types/`.
 - Procedures for operating the tooling - those live in `instructions/`.
+- **Anything an instance would have to rewrite for itself** - language, naming forms, tone,
+  relationship labels, the confidence rubric. Those are `kb/CONVENTIONS.md`'s, and a sentence
+  of that kind here is a sentence the stack ships over the instance's own answer.
 - Rules that apply to only one collection - those belong in that collection's
   `COLLECTION.md`.
 - Hand-edited generated files - see [Generated files](#generated-files).

kb/CONVENTIONS.md

@@ -0,0 +1,120 @@
+---
+language: de
+profile: german
+sections:
+  links: Beziehungen
+  footnotes: Fußnoten
+---
+
+# kb/ - Authoring Conventions of This Instance
+
+The decisions [kb/CONTRACT.md](CONTRACT.md) deliberately does not make. The contract holds what
+the code enforces and is identical in every instance; this file holds what *this* instance
+chose, and no other instance has to agree with a word of it.
+
+**It binds all the same.** Everything below applies to every page under `kb/`, exactly as the
+contract does. The difference is ownership, not authority: a rule here is changed by editing
+this file, a rule there by changing the stack.
+
+Adopted from the `german` profile in
+[instructions/kb-profiles.md](../instructions/kb-profiles.md). That catalogue is a palette, not
+an enum - what is written here is what holds, whether or not a profile says the same thing.
+
+The frontmatter above is the one machine-read part. `sections:` names the headings the two
+**generated regions** render under - the links region `wikitool xref` owns and the footnotes
+region `wikitool cite` owns. Each sits between a marker pair, and the marker is what the tool
+locates it by, so the heading here is a display value: changing it re-renders the words above
+those regions and nothing else. Nothing matches on this text.
+
+## Language
+
+Pages are written in **German**. This binds `kb/` and the authoring surface that shapes it -
+the page type-specs `types/entity.md`, `types/concept.md`, `types/source.md` and
+`types/comparison.md`. `raw/` is untouched ([raw/CONTRACT.md](../raw/CONTRACT.md)), and the
+control plane stays English: `AGENTS.md`, the stage contracts, this file, `instructions/`, and
+the type-specs for non-page artifacts.
+
+Which line is prose and which is an identifier - and therefore what is translated at all - is
+the contract's rule, not this file's: see
+[kb/CONTRACT.md § Language and identifiers](CONTRACT.md#language-and-identifiers).
+
+Established English technical terms stay English inside German prose - "GitOps", "Ownership
+Model", "Reverse Proxy", "Pull Request". Translate a term only where the German one is genuinely
+the more common usage. A coined German equivalent nobody else writes makes the page harder to
+find, not more idiomatic.
+
+Which terms those are, which have a settled German form, and the register the prose is written
+in: [instructions/german-terminology.md](../instructions/german-terminology.md). It is lookup
+material, not a second rule - every entry in it is a decision that was made wrong once first.
+
+### Section headings
+
+The two generated regions render under `## Beziehungen` and `## Fußnoten`. An author never
+writes inside them - they are rebuilt from frontmatter on every write, exactly like
+`kb/index.md` - and never has to write the heading either. Any *other* heading on a page is
+ordinary prose and is translated with the rest.
+
+There is no `## Siehe auch` region any more. It was the reciprocal half of a bidirectional
+`xref add`; under authored directional edges, `see-also` is a *label* inside the links region.
+
+## Naming
+
+- 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`.
+- 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
+name; tools the tool's own name; technologies their standard spelling and capitalization;
+people a full name or common handle.
+
+The one naming fact that is *not* a choice, and therefore lives in the contract: the filename
+stem is the page title, and `[[wikilinks]]` must match it exactly.
+
+## Tone
+
+Wikipedia style: factual, neutral, specific.
+
+- No buzzwords ("bahnbrechend", "hochmodern", "leistungsstark", "revolutioniert").
+- No AI filler ("es sei angemerkt", "es ist wichtig zu betonen", "in der heutigen Zeit").
+- No em-dash asides carrying parenthetical reasoning.
+
+Good: "MQTT ist ein leichtgewichtiges Publish-Subscribe-Protokoll für Geräte mit knappen
+Ressourcen."
+
+Bad: "MQTT ist ein bahnbrechendes, hochmodernes Protokoll, das die IoT-Kommunikation
+revolutioniert - und es sei angemerkt, dass es ein Publish-Subscribe-Muster verwendet."
+
+The blockquote cap is not here: `wikitool lint` reports it, so it is the contract's.
+
+## Relationship labels
+
+**Not this file's to list, and not localized.** A label is a machine value in `related:`, drawn
+from [instructions/link-taxonomy.md](../instructions/link-taxonomy.md) and authorised per
+destination in each `kb/<name>/COLLECTION.md`'s `outbound:` block. `- **depends-on:** [[Hermes]]`
+is what a German page carries, and that is deliberate: the label is an identifier, so translating
+it would make the graph's semantics depend on the prose again.
+
+## Confidence rubric
+
+`confidence_base` is set by hand and `confidence` is derived from it - that mechanism is the
+contract's. What the number *means* is this instance's:
+
+Base score for a single source is 0.5, adjusted by:
+
+- **+0.2 per supporting source** (max +0.6)
+- **+0.2** if confirmed <30 days ago, **+0.1** if <90 days
+- **+0.1** for official documentation, **+0.05** for a reputable secondary source
+- **+0.1** if multiple independent sources agree
+
+In prose, hedge according to the score: below 0.6 write "möglicherweise"/"kann"; below 0.4
+write "unsicher"/"unbestätigt".
+
+## Keeping this file honest
+
+Change it when a convention actually changes. `sections:` is safe to change at any time - the
+regions are located by their markers and re-rendered under the new words on the next write.
+`wikitool doctor` FAILs on a missing or unfilled file, and `wikitool docs verify` refuses a
+`sections:` block that does not name both regions.

kb/CONVENTIONS.md.template

@@ -0,0 +1,89 @@
+---
+# wikitool:template-unfilled - delete this line once the file is answered.
+language: en
+profile: none
+sections:
+  links: Relationships
+  footnotes: Footnotes
+---
+
+# kb/ - Authoring Conventions of This Instance
+
+The decisions [kb/CONTRACT.md](CONTRACT.md) deliberately does not make. The contract holds what
+the code enforces and is identical in every instance; this file holds what *this* instance
+chooses, and no other instance has to agree with a word of it.
+
+**It binds all the same.** Everything below applies to every page under `kb/`, exactly as the
+contract does. The difference is ownership, not authority: a rule here is changed by editing
+this file, a rule there by changing the stack.
+
+Ready-made answers to every section below - including a complete German profile - are in
+[instructions/kb-profiles.md](../instructions/kb-profiles.md). That catalogue is a palette, not
+an enum: adopt an entry, adapt it, or write your own. What is written *here* is what holds.
+
+The frontmatter above is the one machine-read part. `sections:` names the headings the two
+generated regions render under. Safe to change at any time - each region is located by its
+marker pair, so a rename re-renders words and nothing else.
+
+## Language
+
+Pages are written in **{language}**. This binds `kb/` and the authoring surface that shapes it -
+the page type-specs `types/entity.md`, `types/concept.md`, `types/source.md` and
+`types/comparison.md`, whose `## Template` blocks are the body skeleton every new page starts
+from. `raw/` is untouched ([raw/CONTRACT.md](../raw/CONTRACT.md)), and the control plane stays
+English: `AGENTS.md`, the stage contracts, this file, `instructions/`, and the type-specs for
+non-page artifacts.
+
+Which line is prose and which is an identifier - and therefore what is translated at all - is
+the contract's rule, not this file's: see
+[kb/CONTRACT.md § Language and identifiers](CONTRACT.md#language-and-identifiers).
+
+{Which established foreign-language technical terms stay untranslated inside this instance's
+prose, and where the vocabulary for that is looked up. Delete this paragraph if the KB language
+is the one those terms are already in.}
+
+### Section headings
+
+The two generated regions render under the frontmatter's headings. An author never writes inside
+them - they are rebuilt from frontmatter on every write. Any *other* heading is ordinary prose.
+
+## Naming
+
+- {Title form - words and spaces, or kebab-case, or the subject's own spelling.}
+- {Singular or plural for entities.}
+- {How a comparison page's title reads.}
+- {The ADR prefix, if this instance files decisions as pages.}
+- {What to name a thing: projects, systems, tools, technologies, people.}
+
+The one naming fact that is *not* a choice, and therefore lives in the contract: the filename
+stem is the page title, and `[[wikilinks]]` must match it exactly.
+
+## Tone
+
+{The register pages are written in, in one line.}
+
+- {Words and constructions this instance refuses, with examples in the KB language.}
+
+Good: {one sentence that is what this instance wants.}
+
+Bad: {the same sentence written the way it must not be.}
+
+## Relationship labels
+
+**Not this file's to list, and not localized.** A label is a machine value in `related:`, drawn
+from [instructions/link-taxonomy.md](../instructions/link-taxonomy.md) and authorised per
+destination in each `kb/<name>/COLLECTION.md`'s `outbound:` block.
+
+## Confidence rubric
+
+`confidence_base` is set by hand and `confidence` is derived from it - that mechanism is the
+contract's. What the number *means* is this instance's:
+
+{the base score, what raises it, and by how much}
+
+{How to hedge in prose at a low score, in the KB language.}
+
+## Keeping this file honest
+
+Change it when a convention actually changes. `wikitool doctor` FAILs on a missing or unfilled
+file, and `wikitool docs verify` refuses a `sections:` block that does not name both regions.

kb/comparisons/COLLECTION.md

@@ -1,3 +1,10 @@
+---
+profile: comparisons
+outbound:
+  any: [compares-with, contrasts, see-also]
+required_by_stack: false
+---
+
 # kb/comparisons/ - Collection Contract
 
 Structured head-to-head evaluations of two or more things that already have pages here. A
@@ -7,8 +14,10 @@ comparison exists so that neither subject's own page has to argue against the ot
 That needs named, checkable dimensions and a stated trade-off; a page that lists differences
 without saying what they cost has described, not compared.
 
-Inherits [kb/CONTRACT.md](../CONTRACT.md) - naming, tone, linking, provenance and confidence
+Inherits [kb/CONTRACT.md](../CONTRACT.md) for the rules the stack enforces - linking mechanics,
-are defined there and are not restated here.
+provenance, citation, the confidence machinery - and
+[kb/CONVENTIONS.md](../CONVENTIONS.md) for what this instance decided: language, naming forms,
+tone, relationship labels, the confidence rubric. Neither is restated here.
 
 ## Types offered
 
@@ -16,8 +25,9 @@ are defined there and are not restated here.
 
 ## Naming
 
-The title reads as a comparison: `Go vs Rust.md`, `Traefik vs nginx.md`. Order the subjects as
+The title form is [kb/CONVENTIONS.md § Naming](../CONVENTIONS.md#naming)'s. What is local here
-they are most commonly spoken, not alphabetically.
+is the ordering: name the subjects as they are most commonly spoken together, not
+alphabetically.
 
 ## Requirements
 
@@ -29,11 +39,22 @@ they are most commonly spoken, not alphabetically.
 - State the trade-off, not a winner. Where a recommendation is genuinely warranted, scope it:
   "for X workload", not "better".
 
+## Authorised labels
+
+The `outbound:` block above is what `wikitool lint` and `xref add` check: which labels a page in
+this collection may use, per destination. The catalogue they are drawn from - and what each one
+asserts - is [instructions/link-taxonomy.md](../../instructions/link-taxonomy.md), which binds
+nothing on its own.
+
+Narrow for the opposite reason: a comparison's substance is its table, and its links to the compared subjects are the one relationship it asserts.
+
+Adding a label here is a deliberate contract change, not a way around a refusal.
+
 ## Outbound linking
 
-A comparison links to every subject with `related to`, and each subject links back. Comparison
+A comparison links to every subject with `compares-with`. The subjects do not have to link back:
-pages are **exempt from the orphan check** - they are reached through `index.md` rather than
+a comparison is reached through the catalog, and each subject's inbound view renders the edge
-through inbound prose links.
+anyway. Comparison pages are **exempt from the orphan check** for the same reason.
 
 ## What does not belong here
 

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

@@ -1,3 +1,13 @@
+---
+profile: concepts
+outbound:
+  concepts: [extends, grounds, rests-on, enables, precondition, exemplifies, abstracted-from, contrasts, compares-with, contradicts, composition, part-of, supersedes, derived-from, adapted-from, see-also]
+  entities: [operationalized-from, mechanism, procedure, applies-when, operates-on, invokes, exemplifies, see-also]
+  sources: [evidenced-by, derived-from, adapted-from, defined-in, see-also]
+  comparisons: [compares-with, see-also]
+required_by_stack: false
+---
+
 # kb/concepts/ - Collection Contract
 
 Ideas rather than things: architectures, patterns, protocols, workflows, recurring problems,
@@ -8,26 +18,47 @@ records *what*.
 without the reader having to open the entity pages that use it. If the explanation only makes
 sense once you already know the system, it is on the wrong page.
 
-Inherits [kb/CONTRACT.md](../CONTRACT.md) - naming, tone, linking, provenance and confidence
+Inherits [kb/CONTRACT.md](../CONTRACT.md) for the rules the stack enforces - linking mechanics,
-are defined there and are not restated here.
+provenance, citation, the confidence machinery - and
+[kb/CONVENTIONS.md](../CONVENTIONS.md) for what this instance decided: language, naming forms,
+tone, relationship labels, the confidence rubric. Neither is restated here.
 
 ## Types offered
 
 `concept` (`tools/wikitool types describe concept`).
 
-## Decisions and ADRs
+## Decisions
 
-An architectural decision is a concept page prefixed `adr-NNN-`, e.g.
+An architectural decision is an ordinary concept page with `concept_type: decision`
-`adr-001-use-go-modules.md`. 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; a new one supersedes it and both link to the
+A decision superseded by a later one is never deleted or rewritten. The new page declares
-other with `replaces` / `replaced by`.
+`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
+
+The `outbound:` block above is what `wikitool lint` and `xref add` check: which labels a page in
+this collection may use, per destination. The catalogue they are drawn from - and what each one
+asserts - is [instructions/link-taxonomy.md](../../instructions/link-taxonomy.md), which binds
+nothing on its own.
+
+The widest authorisation in this instance, because argumentation is what concept pages do. Note that the operational labels are absent: a concept does not `depend-on` anything - the entity implementing it does.
+
+Adding a label here is a deliberate contract change, not a way around a refusal.
 
 ## Outbound linking
 

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

@@ -0,0 +1,76 @@
+---
+type: types/concept.md
+concept_type: decision
+tags: []
+created: 2026-09-01
+modified: 2026-09-01
+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
+provenance: sourced
+summary: 'Private Korpusinhalte per Loeschung entfernen statt zu anonymisieren: ein Seitentitel ist der einzige Identifier eines Wikis, Umbenennen ist die volle page-lifecycle-Prozedur je Seite, Loeschen ist ein unterstuetztes Kommando.'
+---
+# Delete Rather Than Anonymize
+
+**Typ:** Decision
+
+## Definition
+
+Wenn private oder sensible Inhalte aus einem Wiki entfernt werden müssen, ist Löschen einer
+zugehörigen Seite in der Regel dem Anonymisieren (Umbenennen, Ersetzen sensibler Details bei
+sonst unverändertem Inhalt) vorzuziehen - wenn ein unterstütztes Löschkommando existiert.
+
+## Kernpunkte
+
+- Ein Seitentitel ist in einem verlinkten Wiki oft der **einzige Identifier** einer Seite: Er
+  lebt in Wikilinks, Zitatmarkern und Frontmatter-Arrays jeder referenzierenden Seite. Ihn zu
+  ändern (Anonymisieren durch Umbenennen) verlangt deshalb eine vollständige Rename-Prozedur pro
+  betroffener Seite - bei mehreren zusammenhängenden Seiten multipliziert sich der Aufwand.
+- Löschen dagegen ist ein einzelner, unterstützter Vorgang, der eine Seite mechanisch aus dem
+  Rest des Wikis de-linkt (bekannte Referenzarten: Frontmatter-Felder, ganzzeilige
+  Verweis-Aufzählungen). Er ist damit für strukturelle Bereinigung **schneller und weniger
+  fehleranfällig** als Anonymisierung.
+- Bei Inhalten, die eine reale Topologie beschreiben (z. B. eine Infrastrukturdokumentation),
+  entschärft Anonymisieren einzelner Bezeichner (Hostnamen, IP-Adressen) die eigentliche
+  Preisgabe nicht: Die Struktur - welche Systeme wie zusammenhängen - bleibt erhalten, auch wenn
+  die Namen ausgetauscht sind.
+- **Grenze der Methode:** Ein mechanisches Löschkommando entfernt typischerweise nur
+  strukturelle Referenzen (Frontmatter, Aufzählungen), nicht zwingend Erwähnungen im Fließtext
+  einer anderen Seite. Nach der Löschung ist eine gezielte Nachkontrolle nötig, ob der entfernte
+  Name noch im Klartext irgendwo im Wiki steht.
+
+## Wann zu verwenden
+
+- Der zu entfernende Inhalt ist als eigenständige Seite oder eigenständige Seitengruppe
+  abgrenzbar.
+- Ein Löschkommando existiert, das Referenzen mechanisch bereinigt (nicht ein bloßes Entfernen
+  der Datei, das tote Links hinterlässt).
+- Der Inhalt beschreibt eine reale, zusammenhängende Struktur (Infrastruktur, ein Netzwerk, eine
+  Organisation), bei der einzelne Bezeichner austauschen die eigentliche Preisgabe nicht behebt.
+
+## Wann NICHT zu verwenden
+
+- Wenn nur ein einzelner sensibler Wert innerhalb einer sonst wertvollen, generischen Seite
+  steht (z. B. ein Firmenname als Beispiel in einer sonst allgemeingültigen Anleitung) - dort ist
+  gezieltes Redigieren der Seite treffender als sie komplett zu verwerfen.
+- Wenn die Seite Beziehungen trägt, die für sich genommen wertvoll und nicht sensibel sind - dann
+  kann eine Neufassung mit generischem Beispiel sinnvoller sein als Löschung.
+
+## Verwandte Concepts
+
+- [[Mass-Update Gate]]
+
+## Beziehungen
+
+## Siehe auch
+
+- [[Source - Public Release, Corpus Purge and History Squash Session 2026-09-01]]
+- [[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

@@ -0,0 +1,70 @@
+---
+type: types/concept.md
+concept_type: decision
+tags: []
+created: 2026-09-01
+modified: 2026-09-01
+related:
+  - operates-on: Chemenu
+sources: ['Source - Public Release, Corpus Purge and History Squash Session 2026-09-01']
+confidence: 0.70
+confidence_base: 0.70
+provenance: sourced
+summary: Ein Repo mit Code- und Inhaltsanteil erhaelt zwei Lizenzen; die Grenze zwischen ihnen ist kein zweiter, gepflegter Pfadkatalog, sondern der ohnehin vorhandene Dateiplan des Distributionswerkzeugs.
+---
+# Dual Licensing by File Plan
+
+**Typ:** Decision
+
+## Definition
+
+Ein Repository, das sowohl Werkzeug-Code als auch inhaltliches Material (Dokumentation, Daten,
+kompiliertes Wissen) enthält, bekommt zwei Lizenzdateien statt einer - eine für den Code, eine
+für den Inhalt. Welche Datei zu welcher Lizenz gehört, wird nicht in einer eigenen, zweiten
+Liste festgehalten, sondern aus dem Dateiplan abgeleitet, den ein vorhandenes
+Distributions-/Build-Werkzeug ohnehin pflegt.
+
+## Kernpunkte
+
+- Der naheliegende Fehler ist, die Grenze zwischen „Code" und „Inhalt" als eigene, gepflegte
+  Aufzählung von Pfaden in der Lizenzdatei selbst festzuschreiben. Das ist eine zweite Kopie
+  einer Regel, die bereits an anderer Stelle existiert (dem Dateiplan des Build-/
+  Distributionswerkzeugs) - und die Kopie, die driftet, wenn sich Verzeichnisse verschieben.
+- Stattdessen verweist die Lizenz-Notiz auf den bestehenden Plan (z. B. eine Funktion, die
+  berechnet, was in eine Distribution exportiert wird und was nicht) als **einzige** Quelle der
+  Wahrheit für die Grenze.
+- Welche der beiden Lizenzen den generischen Dateinamen `LICENSE` trägt, ist keine
+  Nebensächlichkeit: Es sollte die Lizenz sein, die ein Code-Hosting-Dienst (Forge) für das
+  Repository insgesamt meldet - typischerweise die restriktivere/Copyleft-Lizenz. Ein Leser, der
+  eine Copyleft-Pflicht übersieht, wird dadurch geschädigt; wer eine Pflicht zu viel annimmt,
+  nicht.
+- Ein Distributions-Export, der Code unter einer Copyleft-Lizenz ausliefert, muss die
+  zugehörige Lizenzdatei zwingend mitliefern (nicht optional, nicht still übersprungen, wenn sie
+  fehlt) - sonst ist die exportierte Instanz eine Lizenzverletzung, sobald sie veröffentlicht
+  wird.
+
+## Wann zu verwenden
+
+- Ein Repository trägt sowohl Software-/Werkzeugcode als auch Inhalt mit eigenem
+  Urheberrechtscharakter (Dokumentation, Wissensbasis, Daten), für die unterschiedliche Lizenzen
+  angemessen sind.
+- Es existiert bereits ein Werkzeug, das programmatisch entscheidet, welche Dateien zu welcher
+  Kategorie gehören (z. B. für einen Export- oder Build-Schritt).
+
+## Wann NICHT zu verwenden
+
+- Bei einem Repository, dessen Inhalt untrennbar mit dem Code verwoben ist und für das keine
+  separate, maschinell nachvollziehbare Grenze existiert - dort wäre die Lizenz-Zuordnung selbst
+  wieder eine unabhängige, drift-anfällige Liste.
+
+## Beziehungen
+
+## Siehe auch
+
+- [[Source - Public Release, Corpus Purge and History Squash Session 2026-09-01]]
+
+<!-- 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

@@ -2,7 +2,7 @@
 
 # kb/concepts/ - Index
 
-76 page(s). Regenerated by `wikitool index rebuild`.
+80 page(s). Regenerated by `wikitool index rebuild`.
 
 ## All
 
@@ -25,9 +25,11 @@
 | [[CPPC]] | protocol | Hardwareschnittstelle Collaborative Processor Performance Control für feingranulares CPU-Power-Management zwischen Betriebssystem und AMD-Prozessor. | 2026-08-29 |
 | [[Cross-platform Agent Skills]] | architecture | Architektur fuer Agent-Skills, die ueber mehrere LLM-Werkzeuge hinweg funktionieren; in Chemenu selbst am 2026-08-04 umgesetzt und ueberprueft | 2026-09-01 |
 | [[Crystallization]] | workflow | Verdichten abgeschlossener Erkundungen, Debugging-Sitzungen und Recherchen zu strukturierten Wiki-Auszügen als eigenständige Wissensquellen. | 2026-08-29 |
+| [[Delete Rather Than Anonymize]] | decision | Private Korpusinhalte per Loeschung entfernen statt zu anonymisieren: ein Seitentitel ist der einzige Identifier eines Wikis, Umbenennen ist die volle page-lifecycle-Prozedur je Seite, Loeschen ist ein unterstuetztes Kommando. | 2026-09-01 |
 | [[Denylist over Allowlist]] | decision | Entscheidung, schreibbare Felder als Schema minus kurzer Sperrliste zu bestimmen statt als gepflegte Positivliste, weil die Positivliste eine zweite Kopie des Schemas waere | 2026-08-31 |
 | [[Detect-Repair Asymmetry]] | problem | Werkzeugluecke, in der ein Check einen Defekt zuverlaessig meldet, aber kein Befehl ihn behebt - womit die Handeditierung der einzige verbleibende Ausweg ist | 2026-08-31 |
 | [[Diff-Reviewable Agent Edits]] | decision | Entscheidung, Dateiaenderungen ueber Edit/Write statt ueber Shell-Heredocs zu fahren, weil nur das erste eine pruefbare Diff hinterlaesst | 2026-08-31 |
+| [[Dual Licensing by File Plan]] | decision | Ein Repo mit Code- und Inhaltsanteil erhaelt zwei Lizenzen; die Grenze zwischen ihnen ist kein zweiter, gepflegter Pfadkatalog, sondern der ohnehin vorhandene Dateiplan des Distributionswerkzeugs. | 2026-09-01 |
 | [[Entity Extraction]] | pattern | Erkennen und Strukturieren von Entities (Personen, Projekte, Bibliotheken, Concepts, Dateien, Entscheidungen, Systeme, Werkzeuge) samt typspezifischer Attribute aus Rohquellen. | 2026-08-29 |
 | [[Episodic Memory]] | architecture | Speicherschicht für verdichtete Sitzungszusammenfassungen und Befunde; Brücke zwischen rohem Working Memory und langlebigem Semantic Memory. | 2026-08-29 |
 | [[Event-Driven Automation]] | workflow | Muster, das automatische Auslöser an Wiki-Lebenszyklusereignisse hängt, um manuellen Pflegeaufwand und das Risiko der Verwahrlosung zu senken. | 2026-08-29 |
@@ -39,15 +41,16 @@
 | [[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 bei abgelehntem Aufruf und ein seit 1.5.0 gemessenes Kalibrierungsband von 5-15 (einfach) bzw. 20-35 (komplex) Aufrufen | 2026-08-31 |
+| [[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 ist die linkeste Nicht-Null-Komponente, und drei getrennte Dateien trennen Maschinerie, Herkunft und Content-Form | 2026-08-30 |
+| [[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 |
 | [[Knowledge Compounding]] | workflow | Effekt, bei dem Wissen im Wiki an Wert gewinnt, weil jede neue Quelle an bestehende, untereinander verwiesene Seiten anknüpft und sie ergänzt. | 2026-08-29 |
 | [[Knowledge Graph]] | architecture | Typisierte Schicht aus Entities und Beziehungen über den Wiki-Seiten, die eine reichere Wissensdarstellung und graphbasierte Abfragen ermöglicht. | 2026-08-29 |
 | [[Lint Workflow]] | workflow | Deterministischer Health-Check rund um wikitool lint; seit 1.7.2 maskiert es Code vor dem Notation-Match und zaehlt Zitat-Bloecke statt Zeilen | 2026-09-01 |
 | [[LLM Wiki Pattern]] | architecture | Methodik für persönliches Wissensmanagement, bei der ein LLM aus Rohquellen ein dauerhaftes Wiki aufbaut - Wissen wird kompiliert statt per RAG neu hergeleitet. | 2026-08-29 |
 | [[Mass-Update Gate]] | workflow | Mass-Update Gate: publish endet mit 42 (Freigabe durch den Menschen noetig) ab 10 gezaehlten Dateien; generierte Dateien und work/ werden committet\, aber seit 1.5.0 nicht gezaehlt; freigegeben per --confirm <token> | 2026-09-01 |
+| [[MCP-Leseserver]] | architecture | Zweiter Konsument von chemenu ueber MCP: search/types/describe_type/lint/status auf chemenu.api.Corpus, strukturell ohne Schreibpfad, jede Antwort trage einen Commit-Stempel. | 2026-09-02 |
 | [[Memory Lifecycle]] | architecture | Architektur des Wissenslebenszyklus mit Confidence Scoring, Supersession, Forgetting und Consolidation Tiers zur Pflege von Fakten über die Zeit. | 2026-08-29 |
 | [[Mesh Sync]] | pattern | Abgleichsmechanismus, der Beobachtungen paralleler Agenten in ein gemeinsames Wiki überführt; Last-Write-Wins mit Konflikterkennung und manuellem Eingriff. | 2026-08-29 |
 | [[Modbus]] | protocol | Industrielles Kommunikationsprotokoll von 1979 zur Anbindung speicherprogrammierbarer Steuerungen und Geräte über serielle oder TCP-Netze. | 2026-08-29 |
@@ -58,6 +61,7 @@
 | [[Personalization Plane]] | architecture | Schicht fuer Instanz-Identitaet: USER.md/SOUL.md werden als Template ausgeliefert, im Setup-Interview woertlich befuellt und vom doctor-Check auf fehlend wie unbefuellt geprueft | 2026-08-31 |
 | [[Privacy and Governance]] | workflow | Rahmenwerk zur Absicherung von Wiki-Inhalten über Datenfilterung beim Ingest, Audit-Trail-Protokollierung und umkehrbare Massenoperationen. | 2026-08-29 |
 | [[Procedural Memory]] | architecture | Langlebigste Speicherschicht für Abläufe, Muster, bewährte Vorgehensweisen und Rezepte, gewonnen aus wiederholten semantischen Beobachtungen. | 2026-08-29 |
+| [[Publish-Remote Gate]] | workflow | Drittes, im Code durchgesetztes Gate: publish bricht mit Exit 42 ab, wenn die aufgeloeste Push-URL nicht in einer optionalen, gitignoreten Allowlist steht; doctor benennt seit 2026-09-02 den Gate-Zustand statt nur die Dateiexistenz | 2026-09-02 |
 | [[Quality and Self-Correction]] | workflow | Automatische Qualitätssicherung für Wikis mit Inhaltsbewertung, Selbstheilung und Widerspruchserkennung. | 2026-08-29 |
 | [[Quality Scoring]] | pattern | Quantitative Bewertung aller vom LLM geschriebenen Inhalte nach struktureller Qualität, Vollständigkeit der Quellenangaben, Konsistenz mit dem Wiki und Themenabdeckung. | 2026-08-29 |
 | [[RAG]] | architecture | Architekturmuster, bei dem LLMs die Generierung um Dokumente aus einer Wissensbasis anreichern. | 2026-08-29 |

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

@@ -3,13 +3,19 @@ type: types/concept.md
 concept_type: workflow
 tags: [gate, safety, iteration-budget, loop-breaker]
 created: 2026-08-07
-modified: 2026-08-31
+modified: 2026-09-02
-related: [Mass-Update Gate, Anti-Cramming Heuristic, Index Scaling, wikitool, Structural Enforcement over Documented Rule]
+related:
-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]
+  - 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
 provenance: sourced
-summary: Im Code durchgesetzte Obergrenze von 60 wikitool-Aufrufen je Session\, Loop-Breaker bei 3 identischen Wiederholungen\, Slot-Erstattung bei abgelehntem Aufruf und ein seit 1.5.0 gemessenes Kalibrierungsband von 5-15 (einfach) bzw. 20-35 (komplex) Aufrufen
+summary: 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
 ---
 # Iteration and Cost Limits
 
@@ -48,34 +54,33 @@ Eine hart in Code durchgesetzte Obergrenze für die Anzahl der Tool-Aufrufe, die
 
 - Einzelne, begrenzte Einmalvorgänge, bei denen die Aufrufen-Anzahl inhärent festgelegt ist (z. B. ein einzelner `new entity`-Aufruf) - das Gate wird dort immer noch gleichmäßig angewendet, wird aber im Wesentlichen nie ausgelöst.
 - Als Ersatz für das [[Mass-Update Gate]], das auf den *Schadensradius* eines `publish` (Dateien, die von einem einzelnen Push betroffen sind) begrenzt ist, nicht auf die *Iterationsmenge* über eine Sitzung - die beiden Gates beheben unterschiedliche Ausfallmodi und beide bleiben notwendig.
-
+- Im [[MCP-Leseserver]]. Das Gate begrenzt eine Agenten-Session am unbemerkten Iterieren über den
-## Verwandte Concepts
+  Wiki-Zustand - deshalb ist Retrieval bereits generell ausgenommen (`SKIP_COMMANDS`) -, nicht
-
+  einen Nutzer, der oft sucht. Ein zu häufig suchender Nutzer ist ein Ressourcenproblem, das vor
-- [[Mass-Update Gate]] - das verwandte Sicherheitsgate, das dieses Muster spiegelt, begrenzt auf Veröffentlichungsgröße statt Sitzungsiterationsvolumen
+  den Serverprozess gehört (Rate Limiting), nicht in dieses Gate - beide zu vermischen würde es
-- [[Anti-Cramming Heuristic]] - eines der Wiki-Qualitätsprobleme, die ein unbegrenzter Ingest-Lauf sonst verletzen könnte
+  zu einem Rate Limiter verwässern.[^s-mcp-read-server-implementation-session-2026-09-02]
-- [[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]]
-
 ## 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]]
 
 ## Fußnoten
 
 [^s-llm-improvements-production-agent-gaps-2026]: [[Source - LLM Improvements Production Agent Gaps 2026]]
 [^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

@@ -3,13 +3,16 @@ type: types/concept.md
 concept_type: decision
 tags: [versioning, semver, release, stack]
 created: 2026-08-30
-modified: 2026-08-30
+modified: 2026-09-02
-related: [wikitool, Issue Label Scheme]
+related:
-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]
+  - 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
 provenance: sourced
-summary: 'Semantische Versionierung des Wiki-Stacks: VERSION beschreibt die Maschinerie, Kompatibilitaet ist die linkeste Nicht-Null-Komponente, und drei getrennte Dateien trennen Maschinerie, Herkunft und Content-Form'
+summary: 'Semantische Versionierung des Wiki-Stacks: VERSION beschreibt die Maschinerie, Kompatibilitaet (Drop-in-Ersatz) und Inhaltsmigration sind seit 2.5.0 getrennte, unabhaengig geprueft Fragen'
 ---
 # KB Stack Versioning
 
@@ -42,9 +45,18 @@ deshalb eine ausdrückliche Handlung.
   Caret-Ranges
   verwenden[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Sie gilt
   einheitlich für `0.x` und `1.x`, sodass unter `0.x` der Schritt `0.1.x` -> `0.2.0` dasselbe
-  Migrationssignal trägt wie `MAJOR` ab `1.0.0`. Der Code für den `compat_key` ist deshalb
+  Signal trägt wie `MAJOR` ab `1.0.0`. Der Code für den `compat_key` ist deshalb einheitlich
-  einheitlich formuliert und musste beim Wechsel auf `1.0.0` nicht angefasst
+  formuliert und musste beim Wechsel auf `1.0.0` nicht angefasst
   werden[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
+- **Kompatibilität und Inhaltsmigration sind zwei unabhängige Fragen, seit `2.5.0` auch zwei
+  getrennte Marker.** Kompatibilität fragt, ob die neue Version ein Drop-in-Ersatz ist -
+  vorwärts ohne Handarbeit, rückwärts noch downgradebar; Inhaltsmigration fragt, ob `kb/` sich
+  bewegen muss. Ein Grenzübertritt kann `kb/` unangetastet lassen und trotzdem MAJOR sein - der
+  `2.0.0`-Rebranding-Bump ist das Beispiel: Update-Pfad, Release-Artefaktname und
+  Paket-Import-Name brachen, keine Seite tat es. `version bump` verlangt deshalb bei jedem
+  Grenzübertritt `--breaking "<was aufhört zu funktionieren>"`, unabhängig von
+  `--no-migration`/einem Migrationsdokument; beide Zeilen landen getrennt im
+  `CHANGES.md`-Eintrag[^s-version-part-nomenclature-and-breaking-change-gate-session-2026-09-02].
 - **`x.y.z` ist die maximale Granularität. Keine Pre-Release-Suffixe.** Eine zweite
   Ordnungsregel müsste vom Release-Feed, von der Migrationskette und von der
   Kompatibilitätsprüfung gleichermaßen befolgt
@@ -64,7 +76,11 @@ deshalb eine ausdrückliche Handlung.
   Instanz[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
 - **Die Grenze wird an zwei Stellen erzwungen:** in `version bump` und in `docs verify`, ergänzt
   um einen `kb-version`-Check in
-  `doctor`[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
+  `doctor`[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Seit
+  `2.5.0` prüft `docs verify` dort zwei unabhängige Dinge - `check_migration_for_boundary` (hat
+  der Korpus sich bewegt) und `check_breaking_change_for_boundary` (wurde der Bruch benannt) -,
+  weil ein Grenzübertritt die eine Prüfung bestehen und an der anderen scheitern
+  kann[^s-version-part-nomenclature-and-breaking-change-gate-session-2026-09-02].
 
 ## Beispiele
 
@@ -90,22 +106,22 @@ 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]]
 
 ## 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]]
+[^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

@@ -0,0 +1,105 @@
+---
+type: types/concept.md
+concept_type: architecture
+tags: [mcp, library-boundary, search, server]
+created: 2026-09-02
+modified: 2026-09-02
+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
+provenance: sourced
+summary: 'Zweiter Konsument von chemenu ueber MCP: search/types/describe_type/lint/status auf chemenu.api.Corpus, strukturell ohne Schreibpfad, jede Antwort trage einen Commit-Stempel.'
+---
+# MCP-Leseserver
+
+**Typ:** Architecture
+
+## Definition
+
+Ein zweiter Konsument desselben Kerns, nicht ein zweites Programm: `tools/chemenu/mcp/` exponiert
+`search`, `types`, `describe_type`, `lint` und `status` über MCP, indem es dieselben Funktionen
+aufruft, die `wikitool` auch aufruft - vermittelt durch `chemenu.api.Corpus`, den In-Process-
+Einstiegspunkt. Ein Golden-Test hält die Ausgaben beider Wege gegeneinander, statt darauf zu
+vertrauen, dass sie übereinstimmen.
+
+## Kernpunkte
+
+- **Kein Schreibpfad, strukturell.** Weder der Server noch `chemenu.api` importiert etwas unter
+  `chemenu.commands` - `new`, `touch`, `xref`, `publish`, `migrate` sind aus diesem Prozess
+  heraus nicht erreichbar, statt aus einer Liste gefiltert zu werden. Ein Test importiert das
+  Servermodul in einem frischen Interpreter und prüft
+  `sys.modules`.[^s-mcp-read-server-implementation-session-2026-09-02]
+- **Zwei Transports.** `stdio` zum Entwickeln und Testen ohne Netz; `streamable-http` für die
+  Auslieferung, der einzige, vor den sich ein HTTP-Reverse-Proxy setzen kann. `sse` ist über das
+  SDK erreichbar und wird bewusst nicht angeboten - der abgelöste Remote-Transport, jetzt darauf
+  zu bauen verschiebt den Wechsel nur.
+- **Jede Antwort trägt den Commit, aus dem sie berechnet wurde** (`commit`, `as_of`). Ein
+  veralteter Checkout antwortet sonst selbstbewusst falsch. `null` heißt: der bediente Baum hat
+  uncommittete Änderungen, die Antwort entspricht keiner Revision. Der Stempel ist die Revision,
+  aus der die Seiten *tatsächlich* gelesen wurden, nicht die zum Zeitpunkt des Stempelns aktuelle
+  - ein Bug, der genau diesen Unterschied überging, wurde beim Schreiben des Golden-Tests selbst
+  gefunden und behoben.[^s-mcp-read-server-implementation-session-2026-09-02]
+- **Telemetrie in den bedienten Baum wird beim Start verweigert**, nicht still umgeleitet. Der
+  Sync, der den Checkout aktuell hält (`git fetch && git reset --hard`), darf `reports/telemetry/`
+  wegräumen; ein Trace, der dort landet, wäre ein Verlust und eine stille Möglichkeit, den Baum
+  zu beschmutzen, dessen Sauberkeit der Korpus-Cache prüft.
+- **Kein Iteration Budget Gate im Server.** Das Gate begrenzt eine Agenten-Session am unbemerkten
+  Iterieren über den Wiki-Zustand, nicht einen Nutzer, der oft sucht - Retrieval ist deshalb
+  bereits generell davon ausgenommen (siehe [[Iteration and Cost Limits]]). Rate Limiting gehört
+  stattdessen vor den Prozess, neben die Authentifizierung.
+- **Authentifizierung ist Middleware, nicht Servercode.** Eine Traefik-ForwardAuth-Instanz
+  (Bearer-Token gegen SHA-256-Hashes) sitzt vor dem Prozess; nicht sauber authentifizierte
+  Zugriffe erreichen Python gar nicht erst.
+- **Gemessen:** Korpus-Parse für 176 Seiten 265 ms → 54 ms (`CSafeLoader`),
+  `wikitool search` end-to-end 593 ms → 347 ms; die verbleibenden ~262 ms sind Modulimport und
+  entfallen im residenten Serverprozess, weil er ihn einmal pro Start statt pro Aufruf
+  zahlt.[^s-mcp-read-server-implementation-session-2026-09-02]
+
+## Beispiele
+
+- `search`/`types`/`describe_type`/`lint`/`status` als die fünf Tools - siehe
+  `tools/chemenu/mcp/server.py`.
+- Der Korpus-Cache (`chemenu/corpus_cache.py`) hält einen Parse pro Commit und cacht nie einen
+  schmutzigen Arbeitsbaum - dieselbe Eigenschaft, die den Antwort-Stempel korrekt hält.
+- `chemenu.api.Corpus`: nimmt einen Root, liefert exakt die `--json`-Formen der CLI, raised statt
+  zu exitieren.
+
+## Wann zu verwenden
+
+- Ein Konsument, der keine Shell auf der bedienenden Maschine ist, soll dieselben Fragen stellen
+  können wie ein Agent, der `wikitool` direkt aufruft.
+- Mehrere gleichzeitige Leser eines Korpus, für die ein Prozess pro CLI-Aufruf (Modulimport,
+  Korpus-Parse) unnötigen Overhead bedeutet.
+
+## Wann NICHT zu verwenden
+
+- Als Ort für einen Schreibpfad - die Ingest-Queue (geplant, Issue #32) ist ein anderes Design
+  mit einer Quarantäne davor, nicht eine Erweiterung dieses Servers.
+- Als Ersatz für den Iteration Budget Gate oder das Traefik-Rate-Limiting - beide bleiben
+  notwendig und leben an anderer Stelle.
+
+## Fußnoten
+
+[^s-mcp-read-server-implementation-session-2026-09-02]: [[Source - MCP Read Server Implementation Session 2026-09-02]]
+
+## Beziehungen
+
+## Siehe auch
+
+- [[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]
+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,24 +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]]
-
 ## 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]]
 
 ## Fußnoten
 
@@ -93,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

@@ -0,0 +1,115 @@
+---
+type: types/concept.md
+concept_type: workflow
+tags: []
+created: 2026-09-01
+modified: 2026-09-02
+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
+provenance: sourced
+summary: 'Drittes, im Code durchgesetztes Gate: publish bricht mit Exit 42 ab, wenn die aufgeloeste Push-URL nicht in einer optionalen, gitignoreten Allowlist steht; doctor benennt seit 2026-09-02 den Gate-Zustand statt nur die Dateiexistenz'
+---
+# Publish-Remote Gate
+
+**Typ:** Workflow
+
+## Definition
+
+Ein im Code durchgesetztes Gate, das einen Schreibvorgang (hier: `publish`) auf ein
+deklariertes, per Datei zugelassenes Ziel beschränkt. Der Vorgang bricht ab, wenn das
+aufgelöste Push-Ziel nicht in der Allowlist steht - unabhängig davon, unter welchem Namen der
+Remote lokal konfiguriert ist.
+
+## Kernpunkte
+
+- **Geprüft wird die aufgelöste URL, nicht der Remote-Name.** Ein namensbasiertes Gate würde
+  ein `publish` durchlassen, dessen `origin` zwischenzeitlich auf ein anderes Ziel umgebogen
+  wurde - genau der Fall, den das Gate abfangen soll.
+- **Kein Freigabe-Token, anders als vergleichbare Gates.** Ein Gate, dessen Frage per
+  Änderungssatz beantwortbar ist ("ist diese konkrete Änderung richtig?"), kann sich mit einem
+  Token lösen, den ein Mensch einmalig ausstellt. Ein Gate, dessen Frage eine stehende
+  Eigenschaft des Checkouts ist ("gehört dieser Inhalt grundsätzlich in dieses Ziel?"), sollte
+  keinen Token haben - der einzige Weg daran vorbei ist ein bewusster Edit der Konfigurationsdatei
+  durch den Menschen, nie ein automatisierter Bypass.
+- **Die Allowlist-Datei ist per Checkout, nicht Teil des versionierten Inhalts.** Sie
+  beschreibt, wohin *dieser* Checkout schreiben darf - eine committete Kopie würde jedem Klon
+  dieselbe Erlaubnis unterschieben, unabhängig davon, ob sie für ihn zutrifft.
+- **Fehlende Datei bedeutet unbeschränkt, kaputte Datei bedeutet Fehler.** Diese Unterscheidung
+  ist wichtig: Ein Checkout ohne Beschränkungsbedarf soll nicht gezwungen sein, eine leere
+  Konfigurationsdatei zu pflegen; eine beschädigte Datei darf aber nicht wie eine abwesende
+  behandelt werden, sonst wird eine defekte Sicherung zu einer stillschweigend abgeschalteten.
+- **`doctor` benennt seit 2026-09-02 den Gate-*Zustand*, nicht nur, ob die Datei existiert.**
+  Vorher meldete der Check nur die Anwesenheit von `.wikitool-remotes.json`; ob das
+  gleichbedeutend mit "scharf" ist, musste der Leser selbst schließen. Alle drei Ausgaben
+  beginnen jetzt mit `Gate armed:` bzw. `Gate not armed:` - der Ein-Remote-Fall ohne Allowlist
+  bleibt `OK` (er hat nichts zu schützen), sagt aber ausdrücklich, dass jedes Push-Ziel
+  durchkommt.[^s-mcp-read-server-implementation-session-2026-09-02]
+
+## Wann zu verwenden
+
+- Ein Checkout kann an mehr als ein Remote-Ziel schreiben, und ein Schreibvorgang an das
+  falsche Ziel ist teuer oder nicht rückgängig zu machen (z. B. weil das Ziel öffentlich ist).
+- Die Menge der zulässigen Ziele ist eine stabile Eigenschaft des Checkouts, keine
+  Einzelfallentscheidung pro Vorgang.
+
+## Wann NICHT zu verwenden
+
+- Wenn nur ein Remote existiert und kein Risiko einer Zielverwechslung besteht - dort ist die
+  Allowlist reine Formalität ohne Schutzwirkung.
+- Für Entscheidungen, die tatsächlich pro Änderungssatz getroffen werden sollen (dafür ist ein
+  Token-basiertes Gate wie das Mass-Update-Gate das richtige Muster).
+
+## Was das Gate nicht abdeckt: Inhalt, der über einen Merge hereinkommt
+
+Das Gate schützt den **Push**, nicht den **Merge**. Ein Setup, bei dem eine private Instanz
+Maschinerie von einem öffentlichen Upstream per `git merge upstream/main` zieht, hat ein
+eigenes, empirisch geprüftes Problem: Ein einfacher Merge übernimmt Upstream-Änderungen an
+bereits gelöschten Inhaltsseiten nicht sauber.
+
+Gemessen an einem Wegwerf-Repo-Paar, bei dem der Upstream nach der einmaligen Löschung des
+Demo-Korpus eine Seite ändert, eine neue anlegt und eine dritte löscht:
+
+- Eine **geänderte** Seite erzeugt einen `modify/delete`-Konflikt und lässt die
+  Upstream-Fassung im Arbeitsbaum liegen - ein naives Auflösen mit `git add -A` holt sie zurück.
+- Eine **neu angelegte** Seite wird **stillschweigend** übernommen, ohne Konflikt und ohne
+  Meldung.
+- Eine beidseitig gelöschte Seite verursacht nichts - der einzige Fall, der ohne Weiteres
+  funktioniert.
+
+Ein naheliegender Fix (`.gitattributes` mit `merge=ours` für die betroffenen Verzeichnisse)
+wurde ebenfalls gemessen und verworfen: Der Treiber wirkt nur bei Inhaltskonflikten auf
+beidseitig vorhandenen Dateien, nicht bei modify/delete-Paaren oder Neuanlagen.
+
+Die funktionierende Prozedur hält den Merge mit `--no-commit` offen, erzwingt die
+Inhaltsverzeichnisse zurück auf den Stand vor dem Merge, solange `HEAD` noch dorthin zeigt, und
+prüft danach explizit (`git diff --name-only $BEFORE HEAD -- kb raw` muss leer sein) - eine
+Kontrolle, die nicht stillschweigend übersprungen werden kann, anders als eine bloße Behauptung
+im Text[^s-private-instance-merge-correction-and-issue-30-session-2026-09-01]. Details, ein
+getestetes Skript und zwei Architekturvorschläge (das Verfahren als `wikitool`-Kommando bauen,
+oder den Demo-Korpus grundsätzlich von dem Branch fernhalten, von dem private Instanzen ihre
+Maschinerie ziehen) stehen in Gitea-Issue #30.
+
+## Beziehungen
+
+## Siehe auch
+
+- [[Source - Publish-Remote Gate and Issue Triage Session 2026-09-01]]
+- [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]
+
+## 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 -->