torben/chemenu

Fork 0

Files

T

torben 63b4bb82d9

CI / verify (push) Successful in 56s

Details

Release / release (push) Successful in 34s

Details

fix: update entity naming conventions to use singular form for consistency

2026-09-05 11:40:08 +02:00

273 KiB

Raw Blame History

Changelog

This file tracks changes to the wiki stack itself - AGENTS.md, the instructions/ layer, tools/wikitool, and the contracts. It is distinct from kb/log.md, which is the audit trail of wiki content operations (ingests, queries, lints, page creates/updates) performed by the LLM against kb/.

Previously each of AGENTS.md and README.md carried its own "Version History" table. Those have been consolidated here so there is one place to look for "what changed in the tooling/schema, and when." From now on, document any change to the stack (schema, instructions, wikitool commands, contracts) as a new entry at the top of this file instead of editing inline version history tables.

Since 0.1.0 an entry's heading also carries the stack version it describes (## <version> - <date> - <title>). wikitool version bump writes that heading, and wikitool docs verify refuses a tree whose VERSION and newest versioned entry disagree. Entries below 0.1.0 predate versioning and keep their date-only headings.

Since 4.4.0 the stack carries one running candidate between two releases rather than a fresh version per bump - see instructions/dev/version-parts.md. While a candidate is open its heading names it with a -beta.N suffix (## 4.4.0-beta.2 - <date> - <title>), and every bump of that same candidate updates this one entry in place rather than opening another: the heading's version/date/title move, and the bump's --title joins a machine-managed  list right under the entry's **Author:** line - written and read by wikitool version bump, never by hand. wikitool version release is what closes a candidate: it strips the suffix and turns the entry into an ordinary, suffix-free one, leaving the bump-title list as the record of what happened. A distributed instance never sees a -beta. version at all (release.yml only ever releases a fixed one), so this suffix and the list beneath it are a dev-checkout concern - readable here, never shipped as something to parse.

4.8.0-beta.5 - 2026-09-05 - update entity naming conventions to use singular form for consistency

Author: Torben Nehmer

status/incoming: menschliche Stubs werden ausgearbeitet, nie so umgesetzt
page move: eine kb-Seite folgt ihrem Subtype ins Verzeichnis, das ihr Type-Spec berechnet
kb/CONTRACT.md: Tiefe 1 als Grenze - Katalog liest nur eine Area-Ebene
raw accept: incoming/ als abgeleiteter Rohablage-Eingang (schliesst #58)
raw accept: Stem-Eindeutigkeit im Typverzeichnis erzwingen, --replaces als einziger Weg daran vorbei (schliesst #64)
update entity naming conventions to use singular form for consistency

Das Label status/incoming gibt es seit heute in Gitea: der Mensch legt einen Stub an — zwei Sätze, ein Verdacht, ein „wäre interessant" — und der Stack komplettiert ihn. instructions/dev/issue-tracking.md beschrieb es nicht, und das ist die gefährlichere Hälfte: ein Stub sieht aus wie ein Body, und der Body ist genau das, was eine Sitzung nach Schritt 2 als Spec glaubt. Zwei solche Issues lagen bereits offen auf dem Board (#60, #61).

Neu in der Instruction ist deshalb ein eigener Abschnitt „Incoming stubs" mit dem Verbot als erstem Satz — ein status/incoming-Issue wird nie so umgesetzt, wie es dasteht — und der Ausarbeitung als sechsschrittigem Ablauf: den Wortlaut als Absichtserklärung lesen, gegen den Baum prüfen, den Originaltext wörtlich in den Kommentar retten, bevor der Rewrite ihn überschreibt, offene Fragen benennen statt beantworten (kind/decision), erst dann die vier Pflichtlabel, dann das Flag entfernen. Zwei Ausgänge wie bei status/unconfirmed: ausgearbeitet oder mit Begründung geschlossen.

Der interessante Punkt ist Schritt 4: status/incoming ist das einzige Flag, das Schritt 4 nicht qualifiziert, sondern aussetzt. Die vier Pflichtachsen fehlen einem Stub nicht, sie sind noch nicht fällig — kind/, prio/ und size/ sind Antworten auf Fragen, die niemand gegen den Baum geprüft hat. Ein Stub auf Sicht durchzulabeln ist der Fehler, nicht das Weglassen: es lässt Ungeprüftes triagiert aussehen.

Der Schaden, den das verhindert, ist derselbe wie bei #30, nur eine Stufe früher: dort schrieb ein Body einen Mechanismus vor und bekam dessen Bugs gebaut, hier schreibt ein Body gar nichts vor und bekommt die Lücke von demjenigen gefüllt, der ihn am schnellsten gelesen hat — inklusive Close, womit die Frage, für die der Stub stand, nie wieder gestellt wird.

Keine neue Schrittnummer, bewusst: stack-close/SKILL.md und ältere CHANGES.md-Einträge verweisen namentlich auf „Schritte 2-3 und 7". Eine Umnummerierung hätte diese Verweise still falsch gemacht — genau der Zerfall, den dieselbe Datei in § Renames beschreibt.

Geändert: instructions/dev/issue-tracking.md (Frontmatter, § When to run, Schritt 5, neuer § Incoming stubs, § What no tool checks, § Decision points) und die Routing-Zeile in instructions/dev/stack-dev/SKILL.md. Dev-only — dist export schließt instructions/dev/ aus, eine ausgelieferte Instanz sieht davon nichts, deshalb PATCH.

Nachgezogen in derselben Sitzung, aber als eigenes Paket (#63, Commit a0aecfc): kb/concepts/Issue Label Scheme.md beschrieb weiter nur die beiden alten status/-Flags und zählte sechzehn statt siebzehn Labels. Das ist kb/-Inhalt und brauchte nach Invariante 3 erst eine Quelle — die Threadkopie von #62/#63 in raw/notes/ — also eine wiki-manage-Sitzung statt dieser hier. Die Seite trägt jetzt die dritte status/-Zeile samt Verbot und einen Kernpunkt dazu, dass dieses Flag die Vier-Achsen-Pflicht aussetzt.

Offen bleibt die erste tatsächliche Anwendung der Regel: #60 und #61 sind weiterhin unausgearbeitete Stubs.

wikitool move (#56): Nichts im Stack bewegte bisher eine Seite über eine Verzeichnisgrenze — rename schreibt laut eigenem Docstring nie über target.path.parent hinaus, und new_page._target_dir rechnete die Platzierung nur beim Anlegen. Ändert sich entity_type später, blieb die Datei still am alten Ort liegen, und nichts prüfte das nach: weder lint_core.py noch doctor.py verglichen den Ist-Ort einer Seite mit dem, was ihr Type-Spec berechnen würde.

Die Platzierungslogik selbst gibt es jetzt genau einmal: TypeResolver.compute_target_dir (plus TypeResolver.subtype_dir für den layout:-Teil), new_page._target_dir delegiert nur noch dorthin. Darauf aufbauend zwei neue Stücke:

wikitool move --page "<Titel>" bewegt eine Seite an den berechneten Ort; --reconcile wendet dieselbe Regel auf den ganzen Bestand an und ist idempotent (ein zweiter Lauf meldet nichts mehr zu tun). Beide Modi fassen weder Body noch Frontmatter an, und der Titel — die einzige Identität einer Seite — ändert sich nie, also folgt kein Referenz-Update. Ein bereits belegtes Ziel (ein alter Stem-Kollisionsrest) wird verweigert statt still überschrieben. Top-level registriert, wie rename/rm, nicht unter einem page-Unterbefehl.
lint bekommt einen neuen Befund, Misplaced Pages, mit Ist- und Soll-Pfad. Bewusst nicht in HARD_ERROR_KEYS: ein von Hand platzierter Bestand ist keine kaputte Seite, nur eine, die move aufräumen könnte — auf dieser Instanz sind das aktuell die drei kb/entities/projects/*/-Seiten, die #57 separat behandelt.

Ein Fund unterwegs, der ohne #56 unsichtbar geblieben wäre: migrate verify schlüsselte Seiten über den repo-relativen Pfad. Ein reiner Move ergab „N removed, N added, 0 compared" und lief grün durch — der eine mechanische Check, für den instructions/migrate-corpus.md existiert, hätte bei genau der Operation nichts geprüft, die dieses Issue einführt. Behoben: PageShape trägt jetzt zusätzlich den Pfad, _shapes_at_revision/_shapes_now schlüsseln über den Titel (die einzige Identität einer Seite), und CorpusDiff.moved meldet einen reinen Ortswechsel separat — informativ, niemals als Finding. Regressionstest deckt drei verschobene Seiten mit compared == 3, added == 0, removed == 0 ab.

Bewusst nicht Teil dieses Pakets: die drei realen Seiten aus #57 bleiben liegen (kein Korpus-Publish hier, nur Stack), und raw rename (#16) — das git mv-mit-mv-Fallback aus #56s Entwurf war für Rohdateien gedacht; rename/rm/move bewegen kb-Seiten über ein einfaches Path.rename, weil publish ohnehin über git add -A staged.

Geändert: tools/chemenu/type_resolver.py (compute_target_dir, subtype_dir), tools/chemenu/commands/new_page.py (delegiert), tools/chemenu/commands/page_ops.py (move_command), tools/chemenu/lint_core.py (find_misplaced, misplaced_pages), tools/chemenu/corpus_diff.py und tools/chemenu/commands/migrate_cmd.py (Titel-Schlüsselung, moved), tools/chemenu/commands/log_append.py (--op move), tools/CONTRACT.md, instructions/page-lifecycle.md, instructions/publish-cycle.md. MINOR: rückwärts liest ein älterer Stack eine verschobene Seite unverändert (Identität ist der Titel, nicht der Ort), vorwärts reines Überkopieren.

Katalogtiefe (#57): index_build.group_pages las bislang genau zwei Pfadsegmente unter kb/ (parts[0] als Collection, parts[1] als Area) und faltete alles darunter still in die Level-1-Area. Real betroffen waren die drei Seiten aus #56s Befund, kb/entities/projects/{kfchou,vanillaflava, yugasun}/*.md — im generierten Katalog nicht als eigener Ort sichtbar, sondern als läge jede direkt in entities/projects/. kb/CONTRACT.md § Collections beschrieb bis heute nur eine Ebene, ohne eine zweite auszuschließen; der Baum hatte trotzdem eine, handplatziert, ohne unterstützten Weg dorthin.

Entscheidung war (b) aus dem Issue: die drei Verzeichnisse auflösen statt den Katalog rekursiv zu machen. Die Gruppierungsachse dahinter — Owner (kfchou/vanillaflava/yugasun) — kommt aus keinem Frontmatter-Feld und aus keinem Type-Spec, sondern aus einer Ad-hoc-Entscheidung beim Anlegen; sie verdient keine zweite Verzeichnisebene. Tiefe 1 ist jetzt geschriebene Regel in kb/CONTRACT.md § Collections, mit dieser Begründung.

Vier Stücke setzen das um:

kb_scan.find_nested_pages liefert (title, page, depth) für jede Seite mehr als ein Verzeichnis unterhalb ihrer Collection — reine Pfadtiefe, unabhängig davon, ob der Typ auflöst, damit auch eine Seite mit kaputtem type: nicht durchrutscht.
lint bekommt den Befund Nested Pages, und anders als misplaced_pages hart: eine fehlplatzierte Seite katalogisiert noch korrekt von der falschen Stelle aus, eine verschachtelte macht den generierten Katalog selbst falsch, und es gibt keine Version, ab der das toleriert würde.
index rebuild lehnt eine verschachtelte Seite nicht ab, sondern warnt (Entscheidung aus der Session: melden statt verweigern, damit ein Fremdinstanz-Upgrade mit handverschachtelten Seiten nicht hart bricht) — group_pages faltet weiterhin wie zuvor, die Warnung ist die neue Sichtbarkeit, nicht eine Verhaltensänderung der Faltung selbst.
TypeResolver.get_layout validiert layout: {dir: ...} jetzt auf einen einzelnen Pfadabschnitt (kein /, kein \, kein ./.., nicht leer) und schlägt fehl statt eine zweite Ebene über den einzigen unterstützten Weg — ein Type-Spec — entstehen zu lassen.

Ein fünftes Stück, das das Issue selbst nicht explizit forderte, aber die move-Mechanik aus #56 sonst mit toten Verzeichnissen zurückgelassen hätte: move (--page wie --reconcile) entfernt jetzt ein Verzeichnis, das es durch den Wegzug seiner letzten Seite geleert hat — symmetrisch zum mkdir(parents=True) auf der Zielseite. Ohne das hätten kfchou/, vanillaflava/, yugasun/ den eigenen Fix überlebt, leer und für git unsichtbar, aber für einen verzeichnisbasierten Test sichtbar.

Auf dieser Instanz angewendet: wikitool move --reconcile hat die drei Seiten nach kb/entities/projects/ gezogen und die drei leeren Owner-Verzeichnisse mitentfernt. migrate verify --from HEAD bestätigt compared == 182, added == 0, removed == 0, alle drei als moved markiert. Titelkollision trat wie im Issue erwartet keine auf.

Geändert: tools/chemenu/kb_scan.py (find_nested_pages), tools/chemenu/lint_core.py (nested_pages, HARD_ERROR_KEYS), tools/chemenu/commands/index_build.py (Rebuild-Warnung), tools/chemenu/type_resolver.py (get_layout-Validierung), tools/chemenu/commands/page_ops.py (_rmdir_if_emptied), tools/CONTRACT.md, kb/CONTRACT.md § Collections, plus die drei realen Seiten unter kb/entities/projects/. PATCH: reine Codeänderung ohne Schnittstellenwechsel, gefaltet in den offenen 4.8.0-Kandidaten (max-wins gegen die MINOR-Bewegung aus #56); die drei bewegten Seiten sind Korpus dieser Instanz, kein ausgelieferter Inhalt.

Schließt #57.

raw accept (#58): raw/CONTRACT.mds Routing-Tabelle war bislang eine Regel für Menschen — wer eine Datei ablegt, wählt articles//documents//notes//assets/ selbst, und mehrere Dateien einer logischen Quelle waren im Dateisystem nicht als zusammengehörig erkennbar. Neu ist ein gitignorierter Eingang incoming/, der dieselben vier Typverzeichnisse spiegelt: der Mensch klassifiziert nur, indem er dort ablegt, tools/wikitool raw accept <datei> [<datei> ...] [--page "<Titel>"] berechnet die Beförderung nach raw/.

Zwei Entscheidungen, gegen die ursprüngliche Skizze im Issue: ein Bundle-Verzeichnis (raw/<typ>/<stamm>/, benannt nach der ersten Datei) entsteht erst ab der zweiten Datei, nie einheitlich — damit sind die 29 heute flach liegenden Bestandsdateien keine Ausnahme, sondern bereits die Regelform, und die Frage „was passiert mit dem Bestand" beantwortet sich von selbst. Und der Typ wird über das Eingangs-Unterverzeichnis deklariert, nicht über ein --type-Flag: die Erklärung wird abgegeben, wenn der Mensch die Datei in der Hand hat, statt im Moment des accept-Aufrufs neu geraten werden zu müssen.

--page deckt den Wachstumsfall ab: erweitert raw_files: einer bestehenden Source-Seite und faltet deren schon abgelegte Einzeldatei ins neue Bundle, sobald das die Seite über eine Datei hinaus wachsen lässt — ohne ein Fenster, in dem raw_files: ins Leere zeigt. Die dafür nötige Rückwärtssuche und der Mehrfach-Owner-Schutz sind keine neue Mechanik, sondern provenance.source_pages_by_raw_file, das lint schon für duplicate_raw_file_owners benutzt — ein Owner-Konflikt lehnt die Beförderung ab, statt eine andere Seite unbemerkt zu brechen.

incoming/ ist für sources coverage und lint unsichtbar (beide laufen ausschließlich über config.iter_raw_files(config.RAW_DIR)), und dass keine Datei dort je committet werden kann, ist über docs_verify.REQUIRED_IGNORE_CANARIES bewiesen, nicht nur zugesichert. RAW_SUBDIRS (dist_cmd.py) bleibt die einzige Quelle der Vier-Verzeichnis-Liste: docs verify (check_raw_subdirs) hält raw/CONTRACT.mds Tabelle jetzt in beiden Richtungen dagegen, und dist export sät incoming/<typ>/.gitkeep neben raw/<typ>/.gitkeep; instructions/bootstrap.md legt den Eingang für einen bestehenden Klon nach, da er dort nie aus git kommt.

Geändert: tools/chemenu/commands/raw_cmd.py (neu, raw accept), tools/chemenu/cli.py, tools/chemenu/commands/dist_cmd.py (RAW_SUBDIRS-Kommentar, incoming/*/.gitkeep), tools/chemenu/commands/docs_verify.py (check_raw_subdirs, incoming/-Ignore-Kanarie), .gitignore, raw/CONTRACT.md, tools/CONTRACT.md, instructions/bootstrap.md, instructions/wiki-ingest/SKILL.md. MINOR: eine Umsortierung des Bestands wäre die Grenze gewesen, findet aber unter der Bundle-erst-ab-zwei-Regel nicht statt — der Bestand bleibt unangetastet, keine fremde Instanz muss migrieren, vorwärts wie rückwärts reines Überkopieren.

Schließt #58.

raw accept prüfte Kollisionen bisher nur auf einzelnen Dateipfaden (dst.exists()), nie auf dem Bundle-Verzeichnis selbst. Weil der Bundle-Name aus dem Stem der Primärdatei entsteht, konnte eine zweite, unabhängige Quelle wortlos in das Bundle einer ersten wandern, sobald die Dateinamen zufällig nicht kollidierten — verifiziert mit einem Wegwerf-Test: handbuch.txt + anhang.md ohne --page landeten unbemerkt in einem bestehenden raw/documents/handbuch/. lint meldete nichts, weil beide Quellen ihre Dateien korrekt abdeckten.

Die Menge der Namen auf raw/<typ>/-Ebene — Dateistämme plus Bundle-Verzeichnisnamen — ist jetzt eindeutig erzwungen (_occupied_stems in raw_cmd.py), unter Ausnahme dessen, was der Aufruf selbst schon besitzt: ein Bundle, das über --page wächst, oder ein bereits registriertes, sich fortsetzendes Bundle. Ein belegter Stem wird mit Exit 1 abgelehnt und nennt beide Auswege, ohne einen zu empfehlen — --replaces oder Umbenennen in incoming/.

--replaces <raw-pfad> ist der einzige sanktionierte Weg, eine Rohdatei wortwörtlich zu ersetzen: genau eine eingehende Datei, identischer Dateiname, gleiches Typverzeichnis, Ablehnung bei mehr als einem Owner. raw_files: bleibt unverändert, es wird keine kb/-Seite geschrieben, und die Altfassung lebt ausschließlich in git log --follow weiter — kein Archivverzeichnis, kein Hash im Dateinamen, kein neues Frontmatter-Feld. Nach einem Ersatz nennt das Kommando die Source-Seite und ihre zitierenden Seiten, damit deren Nachzug im selben Commit passiert wie die Ersetzung.

raw/CONTRACT.md § Rules trägt beide Regeln aus dieser Entscheidung (unveränderlich, aber ersetzbar als Ganzes); instructions/wiki-ingest/SKILL.md benennt den Kollisionsfall als Haltepunkt, an dem eine Sitzung die Meldung dem Menschen vorlegt statt selbst zu entscheiden — dieselbe Klasse wie AGENTS.md Invariante 6, auch ohne dass hier ein Exit-42-Gate greift.

Geändert: tools/chemenu/commands/raw_cmd.py (_occupied_stems, _stem_collision_message, --replaces/_replace), tools/chemenu/tests/test_raw_cmd.py (16 neue Tests), raw/CONTRACT.md, tools/CONTRACT.md, instructions/wiki-ingest/SKILL.md. MINOR: raw accept wurde nie released (letztes Release v4.7.4), die Verschärfung kostet also keine Kompatibilitätsfrage, solange sie vor 4.8.0 landet.

Schließt #64.

4.7.4 - 2026-09-04 - bootstrap.md nennt den session-id-WARN nach frischem Bootstrap explizit als erwartet

Author: Torben Nehmer

bootstrap.md nennt den session-id-WARN nach frischem Bootstrap explizit als erwartet

Nach einem frischen Clone plus instructions/bootstrap.md zeigte tools/wikitool doctor durchgehend OK, außer session-id: WARN - ohne Einordnung, ob das ein Bootstrap-Defekt ist. WIKITOOL_SESSION_ID wird laut instructions/session-setup.md bewusst pro Arbeitssitzung gesetzt, nicht pro Clone; ein Export in bootstrap.md selbst würde nur für den Bootstrap-Lauf gelten, nicht für die tatsächliche Arbeitssitzung danach (die nach dem Neustart in Schritt 6 in einer neuen Shell beginnt). bootstrap.md bekommt deshalb einen neuen Schritt 7, der den WARN als erwarteten Zustand benennt - analog zum bereits dokumentierten personalization: FAIL in Schritt 4 - und auf session-setup.md verweist, statt den Export in Bootstrap nachzubauen. Schließt #54.

4.7.3 - 2026-09-04 - eval: gate-not-self-opened prueft REMOVED_FLAGS gegen das eigene Kommando

Author: Torben Nehmer

Die Trajektorien-Regel gate-not-self-opened (tools/chemenu/evals/trajectory.py) hat jedes Argument jedes wikitool.call gegen REMOVED_FLAGS = {"--yes": "publish", "-y": "publish"} geprüft, ohne je das eigene command-Feld des Aufrufs gegenzulesen. --yes/-y sind nur auf publish entfernt worden - auf rm --page <Titel> --yes sind sie ein gültiger, dokumentierter Flag. Ergebnis: jeder rm --yes-Aufruf wurde als Invarianten-Verstoß gemeldet ("an agent inventing a flag the tool never accepts"), obwohl das Tool ihn akzeptiert hatte.

In den vorhandenen Telemetrie-Traces unter reports/telemetry/ betraf das 111 rm-Aufrufe über 8 Sessions, davon 27 allein in publish-cleanup/u3 - jede davon fälschlich FAILED gescort. Kein bestehender Test hätte das gefangen: tools/chemenu/tests/test_evals.py prüfte REMOVED_FLAGS ausschließlich über publish --yes, nie über ein anderes Kommando.

Fix: die Bedingung liest jetzt attrs.get("command") == REMOVED_FLAGS[arg] mit. Neuer Regressionstest test_yes_on_a_command_that_still_has_it_is_not_a_finding deckt genau den rm --yes-Fall ab und schlägt gegen den unfixed Code nachweislich fehl.

Keine Verhaltensänderung an wikitool selbst - ausschließlich an der Scoring-Logik unter tools/chemenu/evals/.

eval: gate-not-self-opened prueft REMOVED_FLAGS gegen das eigene Kommando

4.7.2 - 2026-09-04 - Coverage-Untergrenze bei 85 %, gegen beobachtete 87,0 %

Author: Torben Nehmer

Coverage-Untergrenze 85 % in tools/.coveragerc

Die Suite hat jetzt einen Boden: fail_under = 85 in tools/.coveragerc, gemessen gegen 87,0 % (CI-Lauf 163, 6498 Statements, 975 Tests). Damit ist Gitea #10 geschlossen — das Issue, das die Messung eingerichtet und die Schwelle danach absichtlich zurückgehalten hat, bis die Zahl beobachtet war.

Die Beobachtung ist der eigentliche Inhalt dieses Bumps. Zwischen der ersten Messung (86,9 % von 5105 Statements, 730 Tests, Lauf 87, Stack 1.8.1) und heute ist der gemessene Code um ein Viertel gewachsen und die Suite um ein Drittel, über 38 grüne Läufe — und die Quote hat sich um einen Zehntelpunkt bewegt. Eine Untergrenze, die auf dieser Beobachtung steht, ist etwas anderes als eine gegriffene Zahl.

85 und nicht 87, und das ist keine Bequemlichkeit. Der Coverage-Bericht unterscheidet drei Sorten ungedeckter Zeilen, und nur eine davon bedeutet Arbeit (EVALS.md § „How much of the stack the suite reaches"). Ein neuer dünner Typer-Wrapper senkt den Gesamtwert, ohne dass irgendetwas schlechter geworden wäre — seine Logik liegt daneben und ist dort getestet. Eine Schwelle auf dem gemessenen Wert würde genau an diesem Commit rot, und eine Schwelle, die aus einem Nicht-Grund rot wird, wird gesenkt statt verdient. Das ist die Fehlerweise, die #10 verhindern wollte, nur von der anderen Seite. Die zwei Punkte sind der Platz, den die Taxonomie verlangt.

fail_under steht in der Konfiguration und nicht als --cov-fail-under im CI-Schritt: so sitzt die Zahl neben der Begründung, die sie erzeugt hat, und gilt für jeden --cov-Lauf statt nur für den einen, den CI schreibt.

Was der Boden nicht tut: die drei echten Lücken schließen (provenance_cmd.py 44 %, migrate_cmd.py 65 %, type_resolver.py 79 %). Er friert den erreichten Stand ein. Diese Liste ist die einzige, die sich nicht bewegt hat, während alles um sie herum wuchs — migrate_cmd.py ist sogar von 71 % gefallen, weil das Modul gewachsen ist und die neuen Zeilen ungetestet ankamen. Das ist Gitea #51.

Mitgenommen, weil es dieselbe Frage beantwortet: der Coverage-Bericht ist als Artefakt abrufbar, über die Run-Seite. Die Actions-Artefakt-Endpunkte melden dafür total_count: 0, weil upload-artifact@v3 über die ältere Artifact-API ablegt, die diese Endpunkte nicht lesen. Eine leere Liste ist kein fehlgeschlagener Upload — steht jetzt in EVALS.md und im Kommentar an der Coverage report-Stufe, damit die naheliegende „Korrektur" auf v4 (hier eingeschränkt) niemandem mehr einfällt.

4.7.1 - 2026-09-04 - redundant_see_also in tools/CONTRACT.md und wiki-lint dokumentiert; xref-remove-Falle benannt

Author: Torben Nehmer

redundant_see_also in tools/CONTRACT.md und wiki-lint; xref-remove-Falle beim Aufräumen benannt

Die Doku-Hälfte von 4.7.0, beim Abschluss nachgezogen. Der Befund war ausgeliefert, aber tools/CONTRACT.mds lint-Zeile zählt die Befunde auf und kannte ihn nicht - eine Instanz hätte eine Sektion im Report gefunden, die ihr Contract nicht erklärt. docs verify prüft, dass die Kommandotabelle existiert, nie was in einer Zeile steht; genau die Lücke, für die AGENTS.md „a stack change is not finished until the human docs describe it" geschrieben ist.

Die eigentliche Änderung ist aber die Warnung in wiki-lint, und sie ist keine Prosa-Politur. Der neue Befund liest sich wie etwas, das Schritt 7 („repariere, was mechanisch ist") abräumt, und der naheliegende Griff wäre xref remove - das die Referenz beidseitig löscht. Angewandt auf Wine see-also Wine GE neben Wine GE depends-on Wine hätte das die schwache und die spezifische Kante entfernt, und das Paar sagte danach gar nichts mehr. Ein Befund, dessen offensichtliche Reparatur Daten zerstört, ist schlechter als kein Befund: Schritt 1 nennt die Falle jetzt beim Namen und verweist auf xref add (fasst nur die Quellseite an) oder aufs Berichten. Dieselbe Asymmetrie hat in #30 schon einmal Daten gekostet.

4.7.0 - 2026-09-04 - Link-Katalog: authored, alternative-to, addresses; entity→entity-Lineage; Lint-Befund gegen redundante see-also

Author: Torben Nehmer

Link-Katalog: authored, alternative-to, addresses; Lint-Befund gegen redundante see-also

Drei neue Label, zwei geschlossene Autorisierungslücken und ein Lint-Befund - ausgelöst von der anstehenden ersten produktiven Instanz. Katalog und COLLECTION.md gehen über dist export in jede neue Instanz; was hier fehlt, fehlt dort ab Tag eins, und nachträglich ist eine Katalogerweiterung eine Korpus-Migration statt einer Datenzeile. Gitea #43 und #49.

Die Messung, die den Zuschnitt bestimmt hat. Die 180 see-also-Kanten des Korpus zerfallen exakt in drei Klassen: 57 (32 %) sind Spiegel einer bereits typisierten Gegenkante, 70 (39 %) sind wechselseitige see-also-Paare, 53 (29 %) stehen einseitig. Die erste Klasse ist kein Vokabularproblem - Wine see-also Wine GE steht neben Wine GE depends-on Wine, RAG see-also NotebookLM neben NotebookLM implements RAG. Der Katalog war für ein Drittel der Fälle längst ausreichend; es hat sie nur nichts gemeldet. Genau dafür ist der Lint-Befund unten da, und er ist der Grund, warum diese Version mehr ist als zwei Katalogzeilen.

authored (operationales Register). „hat das Ziel als einmaligen Akt geschaffen." Der Katalog kannte fortlaufende Rechenschaft (owns) und fortlaufende Arbeit (maintains), aber nicht den historischen Ursprung - Urheberschaft stand im Korpus deshalb in vier unvereinbaren Formen nebeneinander: source.author als Freitext, owns, see-also und ein Prosa-Bullet. Eine davon war sachlich falsch: Vannevar Bush owns Memex behauptet laufende Rechenschaft für einen 1974 Verstorbenen, und eine falsche maschinenlesbare Kante ist schlechter als eine schwache, weil sie geglaubt wird. Geschrieben wird das Label auf der Entity-Seite (Andrej Karpathy authored LLM Wiki Pattern) - die Gegenrichtung authored-by auf der Concept-Seite hätte xref remove gebraucht, das beidseitig abräumt, statt xref add, das relabelt. Vier Kanten im Korpus umgestellt, keine verloren.

alternative-to (operationales Register, selbst-dual). „erfüllt denselben Zweck wie das Ziel, so dass ein Leser, der zwischen beiden wählt, beide will." Belegt durch rund 30 Paare, darunter die sieben Agent-CLIs, die untereinander ausschließlich see-also tragen - keine einzige typisierte Kante. Abgegrenzt gegen contrasts (behauptet einen lesenswerten Unterschied) und compares-with (wiegt auf benannten Dimensionen ab und führt in dieser Instanz auf eine kb/comparisons/-Seite): zwei Agent-CLIs sind austauschbar, zwei gegensätzliche Entwurfsprinzipien sind es nicht.

Der Katalog sagt jetzt ausdrücklich, dass ein selbst-duales Label einmal pro Paar geschrieben wird. Ohne diesen Satz wäre aus einer 22-Kanten-see-also-Clique eine 22-Kanten- alternative-to-Clique geworden und nichts gewonnen: sieben austauschbare Werkzeuge sind 21 Paare, beidseitig deklariert 42 Kanten, von denen die zweiten 21 nichts sagen.

addresses (konzeptionelles Register). „ist eine Antwort auf das Problem, das das Ziel beschreibt." types/concept.md deklariert problem und decision als eigene Subtypen, und der Katalog hatte kein Label, das eine Entscheidung mit dem Problem verbindet, das sie löst - eine Collection konnte ein Problem benennen und nie sagen, was dagegen unternommen wurde. Abgegrenzt gegen rests-on, das das Ziel als Prämisse nimmt statt als zu lösendes Problem. Im Korpus nur vier belegte Paare, also dünn nach dem sonst geltenden „erst der Anwendungsfall"-Maßstab; die Ausnahme ist bewusst und gilt dem Auslieferungszeitpunkt, der die Kosten umdreht.

Zwei Autorisierungslücken entity→entity. kb/entities/COLLECTION.md erlaubte bisher keine Lineage zwischen zwei Entities - ein Fork, eine Neuimplementierung, ein Nachbau war nicht ausdrückbar; derived-from und adapted-from sind jetzt freigegeben. Ebenso implements, für eine Entity, die eine als Entity geführte Konvention umsetzt. Ein autorisiertes Label ohne Live-Nutzung ist ausdrücklich in Ordnung (instructions/dev/corpus-policy.md).

Lint-Befund redundant_see_also. Meldet eine see-also-Kante, deren Gegenrichtung bereits ein typisiertes Label trägt. Gegen den Korpus dieser Instanz meldet er genau die gemessenen 57. Advisory, nicht hart, aus zwei Gründen zugleich: eine schwache Kante neben einer spezifischen ist redundant, nicht kaputt - und der Befund kommt lange nach den Korpora, die er beurteilt, also würde eine harte Einstufung jede bestehende Instanz mit dem Upgrade rot schalten, das ihn ausliefert. Anders als unlabelled_edges ist er auch nicht migrations-gegatet: es gibt keine Version, ab der die Redundanz zum Fehler wird, nur einen Sweep, zu dem jemand kommt oder nicht.

links.SEE_ALSO ist damit das einzige Katalog-Label, das das Werkzeug beim Namen kennt. Das ist eine begründete Ausnahme, keine Aufweichung: see-also ist der erklärte letzte Ausweg des Katalogs und behauptet nur, dass nichts Besseres passte - was der einzige Grund ist, warum lint eine Kante als schwächer als eine andere über demselben Paar beurteilen kann. Alles andere am Vokabular bleibt in instructions/link-taxonomy.md und den outbound:-Blöcken.

Nicht dabei, bewusst. Der Sweep der 180 bestehenden Kanten (#48) - diese Version ändert außer den vier Urheberschaftskanten keine Korpus-Kante. Verworfen wurden außerdem variant-of (die Wine-Forks tragen bereits depends-on Wine), implemented-by (Spiegel von implements, den die Inbound-View rendert), sibling-of für die Concept-Cliquen (Über-Verlinkung, kein fehlendes Wort) und builds-on (Vokabularkollision mit extends/derived-from/adapted-from).

4.6.1 - 2026-09-04 - DEVELOPMENT.md im Kommandotabellen-Check, selbstbeschriftete Release-Notes, Prosa-Korrekturen (#47 Block 3)

Author: Torben Nehmer

DEVELOPMENT.md im Kommandotabellen-Check, selbstbeschriftete Release-Notes, Prosa-Korrekturen (#47 Block 3)

Block 3 aus #47 - die beiden Nebenbefunde entschieden und umgesetzt - plus drei Prosa-Korrekturen an 4.6.0, die eine Bewertung des eigenen Ergebnisses gefunden hat.

DEVELOPMENT.md gehört in docs_verify.STAGE_READMES (entschieden: ja). Das Gegenargument bei der Aufnahme war, die Liste führe bisher nur ausgelieferte Dokumente, und DEVELOPMENT.md wird von dist_cmd.ROOT_FILES bewusst nicht ausgeliefert. Beim Hinsehen löst es sich auf: check_readmes_have_no_command_table überspringt eine Datei, die nicht existiert. In einer ausgelieferten Instanz ist der Eintrag damit schlicht wirkungslos, im Entwicklungs-Checkout - dem einzigen Ort, an dem die Datei existiert und also driften kann - greift er. Dafür spricht der Anlass: genau diese Datei trug einmal eine Tabelle, die für jeden Verify-Befehl ein zweites Mal beschrieb, was er prüft, und sie musste von Hand entfernt werden, weil nichts sie mit etwas verglich. Zwei Tests: einer, der die Tabelle in DEVELOPMENT.md meldet, und einer, der festhält, dass eine fehlende gelistete Datei übersprungen und nicht als Fund gemeldet wird - der Instanz-Fall, an dem die Entscheidung hing. Der Konstantenname ist jetzt enger als sein Inhalt; das steht als Kommentar daneben, statt eine Umbenennung durch zwei Aufrufstellen zu ziehen.

Veröffentlichte Release-Notes veralten weiter - sie sagen es jetzt selbst (entschieden: Schnappschuss akzeptieren, statt einen Korrekturweg zu bauen). Eine nach dem Tag korrigierte CHANGES.md erreicht die Release-Seite nicht: gitea-mcp kennt kein Release-Edit, und Löschen-und-neu-Anlegen würde die angehängten Tarball-Assets vernichten, auf die INSTALL.md und version check zeigen. Bei v4.4.0 ist das real eingetreten. Statt eines Korrekturwegs für einen Text, den niemand editieren kann, trägt der Schnappschuss jetzt eine Fußzeile, die sagt, dass er einer ist und wo die gepflegte Fassung liegt - eine veraltete Notiz kostet einen Leser damit einen Klick statt einer falschen Überzeugung. Angehängt in release.yml und nicht in version notes: das Kommando ist ein allgemeiner Extraktor, dessen andere Aufrufer (lokale Vorschau, eine Pipe) keine Release-Seiten-Fußzeile erben sollen. .gitea/-Änderung, also ohne eigenen Bump-Anspruch - sie fährt hier mit.

Drei Prosa-Korrekturen an 4.6.0. Der 4.6.0-Eintrag und der Docstring von touches_stack_machinery behaupteten, das Prädikat prüfe „denselben Pfad-Umfang, den der CI-Versions-Gate selbst verwendet". Das stimmt nicht: CI matcht [^/]+/CONTRACT\.md$, also genau eine Pfadebene, das Prädikat matcht CONTRACT.md in jeder Tiefe. Folgenlos im Verhalten - ein Über-Match druckt eine Zeile zu viel, nie eine zu wenig -, aber es war eine behauptete Äquivalenz, die keine ist, geschrieben in genau der ungeprüften Prosa-Phase, um die #47 sich dreht. Docstring und tools/CONTRACT.md benennen die Differenz jetzt und begründen sie (bei einer Erinnerung ist Über-Matchen die richtige Richtung). Drittens: stack-close beschrieb den eigenen Skill-Schnitt zu stark („es gibt keinen nächsten Schritt mehr, an dem vorbei zu rutschen wäre"). Wahr für die Prozedur, die nicht mehr im Kontext steht; nicht wahr für den Auslöser - stack-devs „invoke it now" ist weiterhin ein Satz, und die publish-Notiz nennt den Skill bewusst nicht beim Namen. Zwei der drei Kettenglieder bleiben Selbstdisziplin. Der Skill sagt das jetzt selbst, statt sich als Garantie zu verkaufen, die er nicht ist.

Verifiziert: tools/wikitool docs verify, tools/wikitool instructions verify, .venv/bin/python -m pytest -q (969 passed, 2 davon neu), release.yml gegen den YAML-Parser und das Heredoc als Trockenlauf gegen eine Beispiel-Notiz.

4.6.0 - 2026-09-04 - stack-dev/stack-close skill split, publish stack-machinery note, model-selection fix (#47 Block 2)

Author: Torben Nehmer

stack-dev/stack-close skill split, publish stack-machinery note, model-selection fix (#47 Block 2)

Block 2 aus #47 (Vorschlag E, am 2026-09-04 entschieden): die ungeprüfte Schlussphase einer Stack-Sitzung - Issue-Body-Rewrite, docs/-Veralterung, Changelog-Prosa - hatte bisher keinen eigenen Haltepunkt, sondern einen Prosa-Break in stack-dev Schritt 6. Der ist zweimal hintereinander verschluckt worden (#42, #30), beide Male mit echtem Fund im nachgeholten Durchgang. Ein dritter Prosa-Haltepunkt hätte dieselbe Wette verloren, die docs/why-gates-are-code.md für Gates schon verliert - also keine Prosa-Lösung mehr, sondern ein struktureller Schnitt.

Neuer Skill stack-close, dev-only wie stack-dev. stack-dev endet nach tools/wikitool publish mit einem Stop statt mit einem sechsten Schritt; die Schlussphase existiert nur noch als eigener Skill, den eine Sitzung aufrufen muss - es gibt keinen „nächsten Schritt" mehr, an dem vorbei sie rutschen könnte. stack-close trägt drei Dinge: den Modell-Rückwechsel-Hinweis (wie zuvor), die Body-Rewrite-Disziplin aus issue-tracking.md Schritte 2-3 und 7, und neu die Handover-Pflicht über die ganze Sitzung: benannt wird das Modell für Design/Versionsstelle (Schritt 3), für die mechanische Mitte, und für diese Schlussphase - alle drei, auch wenn sie identisch sind. Eine Handover-Zeile, die nur eine billige Schlussphase meldet, schweigt genau dann, wenn die ebenso ungeprüfte Design-Phase auch billig lief und niemand dort gewechselt hat.

Ein Agenten-Zuschnitt (Schlussphase als eigener Subagent mit eigenem Modell) wurde geprüft und verworfen: ein Fork erbt in Claude Code zwingend das Elternmodell, ein frischer Subagent den Sitzungskontext nicht - die Kombination, die der Zuschnitt bräuchte, gibt es nicht, und selbst wenn: der Input der Schlussphase ist das akkumulierte Sitzungswissen, das ein kalter Agent aus Diff und Issue neu ableiten müsste. Volle Begründung im Body von #47.

instructions/claude-code-model-selection.md korrigiert, im dist-strip-Block: die Übersicht „stack-dev Schritt 3 und 6" ist falsch geworden, seit Schritt 6 nicht mehr existiert. Sie benennt jetzt beide Haltepunkte an ihrem tatsächlichen Ort - Schritt 3 in stack-dev, der zweite am Anfang von stack-close.

stack-dev Schritt 3 ehrlicher formuliert (Vorschlag C): nicht mehr „ab hier alles mechanisch", sondern mit benannter Ausnahme - Changelog-Prosa (Schritt 4), eine berührte docs/-Seite, neue Menschendoku, der Prosa-Anteil einer Instruction. Dazu die Einschränkung aus #30: „durch Tests abgedeckt" gilt nur für das, was die Tests treffen - zwei datenvernichtende Bugs in upstream merge liefen an einem grünen pytest/docs verify/instructions verify/CI vorbei, weil kein Test den Fall traf, nicht weil ein schwächeres Modell schlechteren Code für den getesteten Fall geschrieben hätte.

Neu: tools/wikitool publish selbst erinnert an die Phasengrenze. Berührt das Changeset tools/, types/, instructions/, AGENTS.md oder ein <stage>/CONTRACT.md - derselbe Umfang, den ein Versions-Bump selbst abdeckt -, druckt publish nach der Erfolgsmeldung eine Zeile, dass die folgende Phase von keinem der drei Checks abgedeckt ist. Kein Gate, keine Änderung am Exit-Code, für eine gewöhnliche Content-Publish stumm; harness- und instanzneutral formuliert, ohne jede Erwähnung eines Trackers, weil publish von jedem Skill genutzt wird, nicht nur von stack-dev. git_publish.touches_stack_machinery() plus vier neue Tests (test_git_publish.py): zwei für die reine Klassifikationsfunktion (positiv/negativ), zwei Integrationstests gegen einen echten Publish - die Notiz erscheint genau einmal bei einer instructions/-Änderung und bleibt aus bei einer gewöhnlichen kb/-Änderung. tools/CONTRACT.mds publish-Zeile trägt die Kurzfassung, absichtlich ohne den Dateinamen version-parts.md zu nennen - die Datei liegt unter instructions/dev/ und würde in einer ausgelieferten Instanz ins Leere zeigen, während tools/CONTRACT.md selbst ausgeliefert wird.

Verifiziert: tools/wikitool instructions sync (7 Skills, stack-close neu), tools/wikitool docs verify, tools/wikitool instructions verify, .venv/bin/python -m pytest -q (967 passed, 4 davon neu).

#47 bleibt offen für Block 3 (DEVELOPMENT.md in STAGE_READMES, veraltete Release-Notes).

4.5.1 - 2026-09-04 - issue-tracking - destructive-step invariants, comment-vs-body authority, rename sweep

Author: Torben Nehmer

issue-tracking - destructive-step invariants, comment-vs-body authority, rename sweep

Block 1 aus #47 (gemeinsam mit #29): drei Ergänzungen an instructions/dev/issue-tracking.md, ausgelöst durch zwei Fehlerklassen, die in derselben Sitzung am Stack aufgetreten waren.

Schritt 1 trägt jetzt, dass destruktive Schritte im Body die Invariante nennen müssen, die sie nicht verletzen dürfen, und dass ein Akzeptanzkriterium eine prüfbare Eigenschaft ist, keine Tätigkeit. Auslöser war #30: der Body schrieb wörtlich "Arbeitsverzeichnis entfernen" für den upstream merge-Ablauf, und genau das wurde zum datenvernichtenden Bug - ein shutil.rmtree auf eine Stage mit gitignorierten, nicht rekonstruierbaren Daten.
Schritt 2 trägt jetzt die Lesesicht auf Body und Kommentare, die es bisher nur aus Autorensicht gab: der Body ist der Stand, Kommentare sind Historie; ein erkennbar veralteter Body wird richtiggestellt statt umgangen; widersprüchliche Kommentare werden nach Beleg aufgelöst, nicht nach Datum. Auslöser war ebenfalls #30 (ein Kommentar empfahl das Gegenteil dessen, was der Body später festlegte) und #10 (ein seit Tagen veralteter Body gegen drei widersprechende Kommentare, zwei davon sich selbst widersprechend).
Neuer Abschnitt "Renames and other decay in the tracker" nach Schritt 7: ein Rename ist erst fertig, wenn auch die offenen Issues nachgezogen sind, weil wikitool diesen Tracker nicht kennt und nicht kennenlernen soll. Mit der Wegweiser-vs-Beleg-Unterscheidung aus #29 und dem Hinweis, dass auch verschwundene kb/-Seiten und private Infrastrukturangaben Issue-Texte altern lassen. Ein neuer Trigger in "When to run" verweist darauf.

Keine der drei Ergänzungen verschiebt die bestehende Nummerierung der Schritte 1-7 - die Querverweise darauf (u. a. aus instructions/dev/stack-dev/SKILL.md auf Schritt 7, aus kb/concepts/Issue Label Scheme.md auf Schritt 2) bleiben also gültig, ohne angefasst zu werden.

Verifiziert: tools/wikitool instructions verify, tools/wikitool docs verify, beide grün (Prosa-only, kein Interface geändert, PATCH).

#47 bleibt offen (Block 2: der Skill-Schnitt aus Vorschlag E; Block 3: die beiden Nebenbefunde). #29 bleibt ebenfalls offen: dieser Block deckte nur den Regelabsatz, nicht den noch ausstehenden Pfad-Durchgang durch #4, #5, #15, #21, #16, #26 - der war nicht Teil des Auftrags für diesen Block.

4.5.0 - 2026-09-04 - Beide Update-Wege in Code: upstream merge fuer Clones, dist upgrade fuer Tarball-Instanzen

Author: Torben Nehmer

Faktenkorrekturen in der 4.4.0-Prosa; DEVELOPMENT.md ohne zweite Kommandobeschreibung
wikitool upstream merge/verify: code procedure for taking a stack update, ownership.py as the shared stack/instance boundary
upstream merge: combined-commit regression test (edit+add+delete+contract+template+contract-delete in one commit)
upstream merge: keep gitignored local data under a content stage, refuse a merge git never opened, report what actually changed
dist upgrade: apply a stack update, not just detect one (#7)
dist upgrade: Stamp-Semantik nach --keep-local benannt, docs/ownership-and-templates.md auf drei Eigentumsklassen nachgezogen

Die Prosa zu 4.4.0 - Changelog-Eintrag, docs/version-model.md, instructions/dev/version-parts.md, DEVELOPMENT.md - entstand ungeprüft: kein maschineller Check liest sie, und die Sitzung, die sie schrieb, hat den dafür vorgesehenen Modellwechsel aus stack-dev Schritt 6 übersprungen. Ein nachgeholter Durchgang hat drei Fehler gefunden, von denen der erste der teuerste war.

Der Befund war an einer Stelle schlicht falsch. Changelog und docs/version-model.md behaupteten, unter dem alten Modell seien Nummern vergeben worden, die „nie ausgeliefert" wurden - im Changelog sogar mit einer erfundenen Zahl („fünf Minor-Bumps ... vier nie ausgeliefert"). Das Gegenteil stimmt: weil release.yml auf jede VERSION-Bewegung feuerte, wurde jeder Bump zu einem echten, getaggten Release. Der 2026-09-03 hat vier davon in sechs Stunden erzeugt (4.3.0 bis 4.3.3), zwei für reine Prosa-Änderungen. Der Schaden war nie ein Phantom-Release, sondern dass „Release" aufhörte, etwas zu bedeuten - vier Upgrades an einem Nachmittag sind für einen Konsumenten kein kleineres Versprechen, sondern ein unleserliches. Beide Stellen tragen jetzt den tatsächlichen Vorgang samt Beleg.

Dazu zwei kleinere Korrekturen: version-parts.md nannte den Stack weiterhin 2.x (er steht bei 4.x), und DEVELOPMENT.md trug eine Tabelle, die für jeden Verify-Befehl ein zweites Mal beschrieb, was er prüft - eine Kopie dessen, was tools/CONTRACT.md hält und docs verify dort gegen die CLI prüft. Die Tabelle ist raus; dass die Datei selbst außerhalb der von diesem Check abgedeckten Dokumente liegt, steht jetzt an ihrer Stelle. Der Code-seitige Teil davon - ob DEVELOPMENT.md in docs_verify.STAGE_READMES gehört - hängt an #47, zusammen mit der Lücke im Skill, die den übersprungenen Modellwechsel überhaupt erst unauffällig gemacht hat.

Kein Verhalten geändert, nur Prosa - und bewusst als laufender Kandidat gelassen statt fixiert: CIs Version-Gate verlangt die VERSION-Bewegung, ein Release verlangt sie nicht. Genau dafür gibt es das Modell aus 4.4.0.

Zweiter Bump auf demselben Kandidaten (#30): git merge upstream/main behandelt einen bewegten Korpus asymmetrisch - eine gelöschte, upstream-geänderte Seite meldet sich als Konflikt, eine neu angelegte Seite wird still gestaged, nur eine beidseitig gelöschte Seite ist harmlos. Die Prosa-Prozedur in private-instance.md § "Taking a stack update" hat das geschlossen, aber mit vier eigenen Fehlern: der Pfadsatz stand dreifach (im Skript, im Kontroll-Grep, implizit in dist_cmd.py); eine vom Upstream gelöschte Maschinerie-Datei wurde von git checkout MERGE_HEAD -- <pfad> still ignoriert, weil das Skript kein set -e hatte; ein echter Konflikt in tools//types//instructions/ endete in einem von der Prosa nirgends erwähnten offenen Merge; und ein neuer Maschinerie-Pfad unter einer Content-Stage hätte die Literal-Liste nie erreicht.

Die Eigentumsgrenze ist jetzt ein Prädikat statt einer Liste: chemenu/ownership.py, is_stack_owned(relative), wahr für <stage>/CONTRACT.md direkt unter einer Content-Stage (kb, raw, work, reports) und für jeden Pfad, der dort auf .template endet - nicht rekursiv, kb/<collection>/COLLECTION.md bleibt seit #39 instanzeigen. dist_cmd.py liest das Modul jetzt statt einer eigenen _CONTENT_ALLOWED_NAMES-Liste zu pflegen, und CONTRACT_ONLY_STAGES leitet sich aus ownership.CONTENT_STAGES ab statt die drei Stage-Pfade ein zweites Mal aufzuschreiben - ein Test hält fest, dass beide Sichten nicht auseinanderlaufen können.

Neu: wikitool upstream merge [--remote upstream] [--branch main] [--no-fetch] und wikitool upstream verify --since <rev> [--until HEAD]. merge prüft Vorbedingungen (sauberer Baum, kein laufendes Merge, Remote löst auf), warnt statt zu blockieren, wenn .wikitool-remotes.json fehlt, hält den Merge offen (--no-commit --no-ff), zwingt jede Content-Stage auf die lokale Seite zurück, holt dann über die Vereinigungsmenge der Bäume von MERGE_HEAD und HEAD genau die stack-eigenen Pfade zurück - inklusive einer Löschung, falls der Upstream einen Maschinerie-Pfad entfernt hat -, verweigert bei verbliebenen unaufgelösten Pfaden ohne zu committen, committet sonst und verifiziert den entstandenen Commit mit derselben Logik wie verify - ein Fund dort wird laut gemeldet und nicht automatisch zurückgerollt. Nicht idempotent (AGENTS.md § Tool error contract), nicht budget-exempt; verify liest nur und ist wie migrate verify von der Budget-Gate ausgenommen. Die Mass-Update-Gate greift bei einem Merge-Commit strukturell nicht - das steht jetzt als eigener Absatz in instructions/gates.md, mit upstream merges eigener Nachkontrolle als der Sicherung, die hier tatsächlich trägt.

private-instance.md § "Taking a stack update" verweist jetzt auf den Befehl statt das Skript auszuschreiben; die Pfadtabelle bleibt als Erklärung stehen, ist aber nicht mehr die operative Liste. Vorschlag B (eigenes Demo-Repo) bleibt zurückgestellt, siehe #30.

23 neue Tests unter test_upstream_cmd.py (35 Fälle mit der parametrisierten is_stack_owned-Tabelle) decken die Fälle aus der Spezifikation ab: gelöschte vs. geänderte vs. neu angelegte Seiten, kb/CONTRACT.md- und Template-Änderungen, kb/entities/COLLECTION.md bleibt lokal, eine gelöschte raw/CONTRACT.md landet, ein neuer Template-Pfad landet, ein offener work/-Lauf landet nicht, ein echter tools/-Konflikt lässt den Merge offen, ein schmutziger Baum wird unberührt abgewiesen, "bereits aktuell" ist ein No-op, die Publish-Remote-Gate-Warnung, verify gegen einen von Hand verpfuschten Merge, und die dist_cmd/ownership-Konsistenz.

Dritter Bump auf demselben Kandidaten: die im Akzeptanzkriterium geforderte Kombinationsprobe fehlte noch - ein einzelner Upstream-Commit, der Editieren, Anlegen, Löschen einer Seite, eine Contract-Änderung, eine Template-Änderung und eine Contract-Löschung gleichzeitig bewegt. Jetzt als test_one_upstream_commit_mixing_every_case_at_once nachgetragen; alle sechs Erwartungen in einem upstream merge-Aufruf verifiziert.

Vierter Bump: zwei Fehler, die ein Review-Durchgang nach dem Publish gefunden hat. Beide waren in der ersten Fassung enthalten, beide hätten Daten vernichtet, und keiner der bestehenden Tests hat sie berührt.

Erstens: die Content-Stage wurde als Ganzes gelöscht. _restore_stage_to_local hieß in der ersten Fassung shutil.rmtree(stage_dir) — die wörtliche Übersetzung des rm -rf kb raw aus der Prosa-Prozedur. Für kb/ und raw/ ist das harmlos, weil dort nichts Ignoriertes liegt. Für die beiden Stages, die dieses Issue neu in den Satz aufgenommen hat, ist es das nicht: reports/ ist bis auf seinen Contract komplett gitignored und trägt genau die Daten, die nirgends sonst existieren — die Telemetrie-Traces, aus denen eval score liest, gespeicherte Eval-Berichte, alte Lint-Reports. In dieser Instanz standen zum Zeitpunkt des Fundes 497 Trace-Verzeichnisse unter reports/telemetry/; ein einziger upstream merge hätte sie alle gelöscht, und zwar stillschweigend, weil git von ignorierten Dateien nichts meldet. Die Stage wird jetzt über die getrackten Pfade beider Bäume zurückgesetzt statt über das Verzeichnis; ignorierte lokale Daten bleiben unberührt. Leergewordene Verzeichnisse werden aufgeräumt, aber nur wirklich leere.

Zweitens: ein Merge, den git nie eröffnet hat, hätte die Maschinerie gelöscht. Der Exit-Code von git merge --no-commit --no-ff wird bewusst ignoriert (Konflikte unter den Content-Stages sind erwartet). Nur: wenn git das Merge gar nicht erst eröffnet — unverwandte Historien, eine ignorierte Datei im Weg —, gibt es kein MERGE_HEAD, _tree_paths("MERGE_HEAD") liefert die leere Menge, und jeder stack-eigene Pfad in HEAD fällt damit in den Zweig „der Upstream hat ihn gelöscht": kb/CONTRACT.md, raw/CONTRACT.md und sämtliche Templates werden entfernt. Der Kommando-Ablauf prüft jetzt nach dem Merge-Aufruf, dass tatsächlich ein Merge offen ist, und bricht sonst ab, ohne den Baum angefasst zu haben. Beide Fehler haben je einen Regressionstest, und beide Tests wurden gegen die alte Fassung laufen gelassen, um zu zeigen, dass sie sie tatsächlich fangen.

Dazu eine Ehrlichkeitskorrektur an der Erfolgsmeldung: sie zählte die wiederhergestellten Pfade, nicht die geänderten — ein Merge, der eine Datei bewegt, meldete vier oder fünf. Sie fragt jetzt git diff zwischen Vor- und Nach-Commit, kennzeichnet Löschungen, und stimmt damit mit dem überein, was ein Leser nachprüfen würde. docs/ownership-and-templates.md hat einen Abschnitt bekommen, warum die Grenze ein Prädikat und keine Liste ist — die Begründung, die dieses Issue erarbeitet hat, gehörte in die Hintergrunddoku und nicht nur in einen Changelog-Eintrag.

Fünfter Bump: wikitool dist upgrade (#7), der zweite der beiden Update-Wege. upstream merge oben bedient eine Instanz mit gemeinsamer Git-History; dist upgrade bedient eine Instanz aus einem Tarball, ohne History, die bislang eine rein manuelle Prozedur in INSTALL.md durchlaufen musste - Schritt 4 verlangte einen sha256-Vergleich von Hand gegen den files-Block der alten .wikitool-release.json.

Die tragende Regel: die Schreibmenge ist genau der files-Block der neuen .wikitool-release.json, minus was ein Export aus einer leeren Vorlage neu sät (chemenu.ownership.is_export_stub, wie bisher schon für kb/log.md/.gitkeep) oder einmalig sät und danach der Instanz gehört (chemenu.ownership.is_upgrade_preserved, neu für .wikitool-kb.json und CHANGES.md), plus der Stamp selbst. Jeder Kandidatpfad wird gegen die alte Instanz-Summe klassifiziert: unverändert wird geräuschlos überschrieben, neu im Release wird angelegt, lokal verändert oder gelöscht wird nie still überschrieben - der Lauf bricht mit der vollständigen Liste ab, außer --keep-local sagt ausdrücklich, dass die Dateien liegen bleiben sollen. --prune entfernt zusätzlich aus dem Release entfallene Dateien, aber nur solche, die seit der Installation unverändert sind.

Die Migrationskette nach dem Tausch wird aus den instructions/migrations/ des neuen Baums ermittelt (kb_state.load_migrations bekam dafür einen directory-Parameter) und nur gemeldet, nie ausgeführt - es gibt bewusst kein migrate run. Eine bereits gegen die installierte Maschinerie offene Kette lässt den Befehl abbrechen, bevor er die Quelle überhaupt öffnet. kb_state.divergent_files() (bisher nur von migrate status gelesen) ist jetzt eine dünne Hülle um das neue, zwei-Baum-fähige compare_against_stamp() - gleiches Verhalten für den bestehenden Aufrufer, wiederverwendbar für dist upgrades eigenen Vergleich.

Quelle ist immer ein bereits vorhandenes Verzeichnis oder .tar.gz - kein Download, das bleibt allein version checks Sache. Ein Tarball muss genau ein Top-Level-Verzeichnis enthalten (die Form, in der release.yml es baut) und wird gegen eine .sha256-Beidatei geprüft, falls eine danebenliegt (fehlt sie: WARN, kein Abbruch). Weitere Abbruchgründe vor jedem Schreiben: fehlende lokale VERSION/.wikitool-kb.json/Stamp mit files-Block, ein schmutziger Arbeitsbaum (kein Git-Repo ist ein WARN, keine Sperre), eine Vorab-Version (-beta.N) ohne --pre, sowie ein Downgrade; Gleichstand ist ein No-op. Ein Grenzübertritt der Kompatibilität wird laut gemeldet, blockiert aber nicht. Committet und pusht nichts (Invariante 5).

Gegenüber dem ersten Entwurf des Issues zwei Korrekturen, die dort auch nachgetragen sind: der files-Block wurde entgegen der ursprünglichen Annahme bereits vor diesem Bump gelesen (divergent_files/migrate status), und die Migrationskette war ursprünglich falsch begründet

sie kann nur aus dem neuen Baum kommen, nicht durch eine andere Abfragereihenfolge aus der alten Instanz. 24 neue Tests unter test_dist_upgrade.py decken die Klassifikation, alle Abbruchgründe, --keep-local, --prune und beide Quellformen (Verzeichnis und Tarball, inklusive der sha256- und Top-Level-Prüfung) ab.

Bewusst nicht angetastet: instructions/private-instance.md (der Clone-Weg ändert sich nicht, INSTALL.md benennt jetzt beide Wege nebeneinander) und die Frage, wie dist upgrade mit Collection-Templates umgeht, deren Namen eine fremde Instanz gar nicht hat - es verhält sich wie upstream merge und schreibt sie, was ein eigenes Issue gegen den Export wäre, keins gegen das Upgrade.

Sechster Bump: die ungeprüfte Phase nachgeholt. Der Abschluss des vorigen Bumps lief auf Sonnet, und stack-dev Schritt 6 verlangt dort genau zwei Dinge, die kein Check erzwingt: Issue-Body und docs/-Veralterung. Der Body war gemacht, die docs/-Prüfung nicht - sie wurde benannt statt durchgeführt. Nachgeholt auf Opus, mit einem Fund.

docs/ownership-and-templates.md § „The consequence in practice" beschrieb ein Upgrade als Zweiteilung: verbatim überschreiben, .template-gestützte Dateien liegen lassen - und begründete den ersten Teil damit, dass verbatim ausgelieferte Dateien „safe to replace wholesale" seien, weil sie „never instance-specific to begin with" waren. Genau diese Annahme trifft dist upgrade nicht: eine Instanz kann eine verbatim ausgelieferte Datei angefasst haben, und die sha256 je Datei existiert, um das zu erkennen, statt es vorauszusetzen. Dazu fehlte die dritte Klasse ganz - die einmalig gesäten, danach instanzeigenen Pfade (.wikitool-kb.json, CHANGES.md, kb/log.md, raw/*/.gitkeep), die im Stamp stehen wie jede andere Datei und deshalb aktiv ausgeschlossen werden müssen. Die Seite nennt jetzt drei Klassen und die engere praktische Regel: überschreibe die verbatim ausgelieferten Dateien, die diese Instanz nicht angefasst hat.

Dazu eine Präzisierung in tools/CONTRACT.md, die vorher nirgends stand: nach --keep-local wird der neue Stamp trotzdem vollständig geschrieben, trägt also die Release-Summe auch für Dateien, die bewusst nicht geschrieben wurden. Der Stamp ist die Vergleichsbasis für den nächsten Lauf, kein wörtliches Inventar der Platte - und genau das hält eine übersprungene Datei bei jedem weiteren Lauf als abweichend gemeldet, statt sie nach einmaligem Überspringen still als aktuell zu führen.

4.4.0 - 2026-09-03 - Versionskandidat statt Bump-pro-Release: VERSION traegt -beta.N, version release fixiert

Author: Torben Nehmer

Versionskandidat statt Bump-pro-Release: VERSION traegt -beta.N, version release fixiert

Bisher bekam jeder version bump sofort eine fixierte Nummer, und weil release.yml auf jede VERSION-Bewegung feuert, wurde daraus sofort ein Release: Nummern entstanden in Commit-Granularität statt in Release-Granularität. Der 2026-09-03 hat so vier Releases in sechs Stunden erzeugt (4.3.0 bis 4.3.3), zwei davon für reine Prosa-Änderungen - alle vier echt, keines davon eine Einheit, an der ein Konsument sich hätte orientieren können. VERSION trägt jetzt zwischen zwei Releases einen laufenden Kandidaten (X.Y.Z-beta.N): --major/--minor/--patch eskaliert diesen Kandidaten max-wins gegen den letzten Release, statt eine neue Nummer danebenzustellen, und geht dabei nie zurück.

Version versteht den Suffix, mit einer expliziten Ordnung (4.4.0-beta.1 < 4.4.0-beta.2 < 4.4.0, numerisch nach N, nicht lexikografisch). CHANGES.md trägt genau einen offenen Eintrag pro Kandidat: der erste Bump eröffnet ihn, jeder weitere aktualisiert Heading und die maschinenverwaltete Bump-Titel-Liste in  (Marker-Konvention aus blocks.py, aber bewusst nicht in blocks.BLOCKS - diese Region gehört zu CHANGES.md, nicht zu einer Seite). version release ist neu und fixiert einen Kandidaten: Suffix weg, Eintrag geschlossen, committet und pusht nichts.

Vier Stellen am Bestand angepasst, die das Kandidatenmodell sonst still beschädigt hätten: release.yml überspringt einen suffixbehafteten VERSION-Push sauber, bevor die Releases-API gefragt wird, statt jeden Beta-Bump zu veröffentlichen; die Grenzübertritts-Checks in docs verify (check_migration_for_boundary, check_breaking_change_for_boundary) messen jetzt gegen den letzten Release (version_mod.last_release) statt gegen den zweitobersten Eintrag, der zwischen zwei Betas keine Grenze mehr hergibt; kb_state.chain()/next_link() vergleichen gegen die Kandidatenbasis, weil eine Migration mit Ziel 4.4.0 sonst bei installiertem 4.4.0-beta.1 aus dem Intervall fällt (4.4.0-beta.1 < 4.4.0); read_kb_version() verweigert einen Prerelease, weil eine Inhaltsform kein Beta kennt. dist export schreibt VERSION und den Stamp weiterhin ehrlich mit Suffix, aber .wikitool-kb.json bekommt die Basis.

Menschendoku für die Erzeuger-Seite: DEVELOPMENT.md im Repo-Root, bewusst nicht in dist_cmd.ROOT_FILES (Begründung als Kommentar dort), mit Zeile in AGENTS.md § File naming und Zeiger aus README.md. docs/version-model.md hat einen neuen Abschnitt, warum eine Nummer erst durch ein Release verbraucht wird.

4.3.3 - 2026-09-03 - Modellwahl nach Pruefbarkeit statt nach Aufgabenname; stack-dev bricht an den Phasenwechseln fuer den Model-Switch

Author: Torben Nehmer

instructions/claude-code-model-selection.md routete bisher nach Skill: eine Zeile "Stack development -> Opus/high" fuer alles, was tools/, types/ oder instructions/ anfasst. Das ist zu grob in beide Richtungen - es verteuert die lange, mechanische Mitte einer Stack-Sitzung, und es sagt nichts darueber, dass Anfang und Ende derselben Sitzung anders zu behandeln sind.

Die neue Achse ist "was faengt hier einen Fehler ab". Wo ein Check in Code steht - pytest, docs verify, instructions verify, CI, die Gates - kostet der Fehler eines schwaecheren Modells eine Runde und faellt auf. Wo die einzige Durchsetzung eine Sitzung ist, die Prosa liest, faellt derselbe Fehler gar nicht auf: er wird ausgeliefert und bleibt stehen. Das ist dasselbe Argument, das docs/why-gates-are-code.md fuer Gates fuehrt, angewandt auf die Modellwahl.

Stack-Entwicklung ist damit nicht mehr eine Zeile, sondern drei:

Phase	Was einen Fehler faengt	Modell
Design, Versionsstelle, Grenzuebertritts-Urteil	nichts	Opus/high
Code, Tests, mechanische Doku-Synchronisation	pytest, CI, `docs verify`	Sonnet/high
Issue-Abschluss, `docs/`-Veralterung, Changelog-Prosa	nichts, per Konstruktion	Opus/high

Die Mitte ist die lange Phase und die mit den Checks - dort liegt die Ersparnis. Die beiden Raender sind kurz (Minuten, nicht Stunden), haben aber keinen maschinellen Waechter: wikitool kennt den Issue-Tracker bewusst nicht, und eine docs/-Seite traegt keinen normativen Satz, also gibt es dort nichts zu verifizieren. Sie oben zu lassen ist billig und schuetzt genau die Arbeit, die still scheitert.

Zwei Praezisierungen dazu: Effort ist der billigere Hebel als das Modell - medium steht fuer Stack-Arbeit bewusst in keiner Zeile, weil Mehrdatei-Konsistenz das ist, was ein reduzierter Effort zuerst aufgibt; high ist die Untergrenze, sobald mehr als eine Datei oder ein Contract betroffen ist. Und die Asymmetrie ist benannt: eine unnoetige Opus-Phase kostet einmal Geld, eine ungepruefte Sonnet-Phase kann etwas ausliefern, das nie wieder jemand ansieht.

Damit die Tabelle ueberhaupt wirksam wird, braucht sie Haltepunkte. Eine Sitzung kann ihr eigenes Modell nicht wechseln - das ist /model und gehoert dem Nutzer. Eine Empfehlung, die niemand zum richtigen Zeitpunkt ausspricht, aendert nichts. instructions/dev/stack-dev/SKILL.md bekommt deshalb zwei ausdrueckliche Breaks:

Neuer Schritt 3 - "Settle the design before building", mit dem Angebot zum Wechsel nach unten, sobald der Plan steht und die Arbeit mechanisch wird. Einmal aussprechen, dann so oder so weiterarbeiten.
Schritt 6 (Abschluss) bricht in die Gegenrichtung - ab dort greift wieder kein Check. Mit der ausdruecklichen Auflage, die Arbeit unabhaengig von der Antwort zu tun: nach dem Publish auf einen Modellwechsel zu blockieren wuerde genau den Zustand hinterlassen, den Schritt 6 verhindern soll. Lief die Phase auf dem billigeren Modell, gehoert das in die Uebergabe statt ins Schweigen.

Ein auftauchender Grenzuebertritt ist unter den Decision points ebenfalls als Anlass zum Wechsel nach oben benannt: docs verify prueft, dass ein Uebertritt sich dokumentiert, nie dass die Stelle richtig gewaehlt war.

Die uebrigen Schritte sind unveraendert und nur umnummeriert (alt 3-5 -> neu 4-6).

4.3.2 - 2026-09-03 - stack-dev: Issue-Abschluss ist ein nummerierter Schritt, kein Zeiger in einer Routing-Liste

Author: Torben Nehmer

Nachfassen zu 4.1.2 (#44), das die Regel geschaerft, aber den Weg zu ihr nicht geaendert hat. instructions/dev/issue-tracking.md bekam damals Schritt 7 ("Closing is the last body update, not a comment"); instructions/dev/stack-dev/SKILL.md bekam nur eine umformulierte Zeile in seiner Routing-Liste. Eine Stunde spaeter schloss #45 auf exakt dieselbe Weise: gruendlicher Abschlusskommentar ueber einem Body mit unangehakten Kriterien.

Die Ursache lag nicht am Text der Regel, sondern an ihrer Erreichbarkeit. Die nummerierten Schritte des Skills endeten bei "Verify before publishing". Ein Issue zu schliessen war ueberhaupt kein Schritt - es hing an einem Zeiger innerhalb von Schritt 2, und Schritt 2 ist eine Routing-Tabelle aus fuenf "read X before Y"-Eintraegen, keine Checkliste. Eine Sitzung folgt dem Spine, den sie im Kontext hat; was nur hinter einem Link steht, wird genau in dem Moment nicht aufgeschlagen, in dem es greift - am Ende einer langen Sitzung, wenn der Kontext am vollsten und die verbleibende Instruktionsflaeche am duennsten ist.

Verschaerfend arbeitete der Blurb gegen seine eigene Regel: fett gesetzt war "keep it current as the state moves, not at the end". Wer den Body unterwegs ungefaehr gepflegt hatte, las daraus Konformitaet - der eigentliche Abschlusstest stand nur in der verlinkten Datei.

Geaendert:

Neuer Schritt 5 in stack-dev/SKILL.md - "Close the issue with a body rewrite, not a comment", mit dem Test inline (Kriterien abgehakt oder mit Begruendung gestrichen, Entscheidungen als entschieden formuliert, kein Praesens ueber einen behobenen Defekt, Verifikation benannt) und dem Verweis auf Schritt 7 fuer die volle Form. Damit steht der Abschluss auf dem Spine.
Schritt-2-Blurb rebalanciert - beide Haelften binden jetzt sichtbar: fortlaufende Pflege und der Rewrite vor dem Schliessen, mit Verweis auf Schritt 5.

Nichts davon ist maschinell pruefbar, und das bleibt richtig so: wikitool kennt den Tracker nicht und darf ihn nicht lernen, weil es an Instanzen ausliefert, die kein Board haben (issue-tracking.md § "What no tool checks"). Der Skill-Spine ist die einzige Durchsetzung, die es geben kann - was der Grund ist, den Schritt zu nummerieren statt ihn zu verlinken.

Verallgemeinerbar: eine Regel, die in eine verlinkte Instruction geschrieben wird, erreicht Sitzungen nur, wenn die nummerierten Schritte des zustaendigen Skills sie in dem Moment ansteuern, in dem sie greift.

4.3.1 - 2026-09-03 - docs/ befuellt - Stack-Hintergrund fuer vier Themen, Pflegeklausel in AGENTS.md ergaenzt

Author: Torben Nehmer

Gitea #45: die von #38 angelegte, bis dahin leere docs/ bekommt ihre ersten vier Seiten - frisch geschrieben, nicht durch Umzug aus kb/ befuellt, jede ohne normativen Satz und mit Verweis auf das bindende Dokument statt einer Wiederholung seiner Regeln:

docs/pipeline-rationale.md - warum raw -> types/tools -> kb -> reports vier getrennte Stufen sind und was "never re-derive, always compile" praktisch bedeutet
docs/why-gates-are-code.md - warum Mass-Update-, Publish-Remote- und Iteration-Budget-Gate in tools/wikitool statt in einer Instruktion stehen
docs/ownership-and-templates.md - der Unterschied zwischen stack-eigenen, verbatim ausgelieferten Dateien und instanz-eigenen .template-Dateien
docs/version-model.md - warum Drop-in-Kompatibilitaet und Migrationsbedarf zwei unabhaengige Fragen sind, illustriert an der 2.0.0-Fallstudie

AGENTS.md § Changelog: neue Klausel zur Pflege von docs/, ergaenzt neben der bestehenden Regel zu README.md/EVALS.md/tools/README.md. Eine docs/-Seite veraltet nicht wie ein README bei jedem neuen Flag, sondern nur, wenn die aufgeschriebene Begruendung selbst nicht mehr traegt - per Konstruktion ungeprueft, da die Seite keinen normativen Satz enthaelt, den docs verify pruefen koennte.

4.3.0 - 2026-09-03 - docs/ als ausgelieferter Hintergrund-Ort; Decision-Seiten bleiben in kb/, Decay-Skip fuer concept_type: decision

Author: Torben Nehmer

Gitea #38: dist export lieferte bislang keine einzige kb/-Seite aus - eine frische Instanz bekam den Stack, aber keinen Grund für seine Form. Die dokumentierte adr-NNN--Konvention in kb/concepts/COLLECTION.md existierte zudem nur auf Papier: keine der sieben concept_type: decision-Seiten folgte ihr, und confidence_decay() lief bedingungslos über sie

ein Kategorienfehler, weil Zeitablauf eine Entscheidung nicht falscher macht, nur Supersession tut das.

Neu: docs/ - ein inertes Verzeichnis für Stack-Hintergrund (warum der Stack so gebaut ist, nicht was diese Instanz entschieden hat). Keine Frontmatter, kein Typ, kein Index, kein Lint, keine Decay, keine Provenance, keine COLLECTION.md. dist export liefert es verbatim aus, wie instructions/ und types/. Befüllung folgt in Gitea #45.

Verworfen, nach Prüfung: ein Umzug der sieben Decision-Seiten nach decisions/. Der Subtyp-Floor aus #28 verlangt mindestens eine Seite je deklariertem concept_type, und ein Umzug hätte decision auf null gebracht; dazu zeigen 89 Wikilinks aus kb/ sowie tool-eigene Frontmatter-Arrays auf die sieben, und links.py/xref add kennen kein Ziel außerhalb kb/. Die sieben bleiben in kb/concepts/, ebenso ein zweiter, separat erwogener Rename (docs verify → parity verify) - der wäre nur nötig gewesen, wenn ein Befehl auf das Verzeichnis docs/ wirkt, und keiner tut das.

Geändert:

confidence_decay() überspringt concept_type: decision strukturell (kategorische Ausnahme, nicht als Brücke gebaut - Begründung im Docstring).
kb/concepts/COLLECTION.md § Decisions ersetzt die tote ADR-Vorlage durch die real gelebte Form: eine Entscheidung ist eine gewöhnliche Concept-Seite, organische Prosa, kein adr-NNN--Präfix, **Status:** optional, Supersession per supersedes-Link.
kb/CONVENTIONS.md § Naming und instructions/kb-profiles.md (Profil german) korrigiert - beide dokumentierten noch die verworfene adr-NNN--Namensregel.
AGENTS.md § File naming und § Routing: docs/-Zeile, plus die Regel, dass docs/ keinen normativen Satz trägt (das hält Invariante 8 heil - was binden würde, gehört in einen Contract).
tools/CONTRACT.md: Klarstellung, dass docs verify Dokumentations-Parität prüft, nicht das docs/-Verzeichnis, sowie docs/ in der dist export-Zeile ergänzt.

Additiv und in beide Richtungen drop-in: eine bestehende Instanz ohne docs/ exportiert weiterhin identisch (leerer _copy_tree-Treffer), eine Instanz mit docs/ bekommt es ab jetzt mitgeliefert. Kein Feld, kein Kommando ändert sein Verhalten für bestehenden Inhalt.

Migration: none required.

Berührt: tools/chemenu/commands/confidence_decay.py, tools/chemenu/commands/dist_cmd.py, tools/chemenu/tests/test_confidence_decay.py, tools/chemenu/tests/test_dist_cmd.py, kb/concepts/COLLECTION.md, kb/CONVENTIONS.md, instructions/kb-profiles.md, AGENTS.md, tools/CONTRACT.md.

4.2.0 - 2026-09-03 - Korpus-Kuratierungsrichtlinie: Untergrenzen und Leitplanke für reaktive Fixes

Author: Torben Nehmer

Ein Demo-Korpus will klein und stabil sein, ein Testbett groß, unordentlich und in Bewegung - dieses Repo verlangt seit der Veröffentlichung beides vom selben kb/ (Gitea #28). Die Sitzung vom 2026-09-02 hatte Fixture, --with-demo und ein zweites Repo bereits verworfen; offen blieb nur, wie kuratiert "kuratiert genug" heißt und welche Leitplanke reaktive Fixes bekommen.

Neu: instructions/dev/corpus-policy.md. Fünf Untergrenzen, jede mit einer bestehenden wikitool-Prüfung messbar, keine davon durch neuen Tool-Code: jeder Seitentyp und jeder deklarierte Subtyp mit mindestens einer Seite, mindestens fünf Seiten mit mindestens drei Quellen, ein bis zehn Orphan-Seiten, im Schnitt mindestens vier ausgehende Wikilinks pro Seite. Gemessen am 2026-09-03: 181 Seiten, alle Typ-/Subtyp-Floors erfüllt, 12 Seiten mit ≥3 Quellen, 3 Orphans, Ø 6,2 ausgehende Links - der Korpus war bereits groß genug, ohne dass eine einzige Seite eigens dafür angelegt werden musste. Eine Untergrenze wird nie durch eine erfundene Seite gefüllt, sondern durch eine echte Quelle beim nächsten passenden Ingest - Invariante 3 gilt unverändert.

Die Leitplanke für reaktive Fixes unterscheidet drei Stufen: punktuelle Änderungen (immer erlaubt, gewöhnliche Arbeit), korpusweite Änderungen (nur geplant, mit eigenem Issue und work/-Run - trifft eine Session das Mass-Update-Gate während sie etwas anderes tat, holt sie sich nicht den --confirm-Token, sondern stoppt und legt ein Issue an) und reaktive Eingriffe in Korpusinhalt, um einen Test grün zu machen oder einen Tool-Bug zu umgehen (nie erlaubt, Invariante 7). Das Verhältnis zu kb_dir/raw_dir und test_pipeline_l0.py bleibt wie im ursprünglichen Befund: kleiner, isolierter Fall in der Fixture, großer, vernetzter Fall in kb/ - keine Fixture-Extraktion aus dem Korpus.

Dev-only und rein additiv - kein Feld, kein Kommando, keine Datei außerhalb von instructions/dev/ ändert sich, daher --minor ohne --breaking.

Migration: none required.

Berührt: instructions/dev/corpus-policy.md (neu), instructions/dev/stack-dev/SKILL.md (Schritt 2, Routing-Zeile).

4.1.2 - 2026-09-03 - Issue-Abschluss ist ein Body-Rewrite, nicht nur ein Kommentar

Author: Torben Nehmer

Aufgefallen beim Schließen von #44: der Abschlussbericht stand als Kommentar da, der Body darunter weiterhin als offene Arbeit — Abschnitt „Zu entscheiden" über eine längst getroffene Entscheidung, ungehakte Checkliste, Präsens über einen Defekt, den es nicht mehr gab.

Die Regel gab es dafür schon: Schritt 2 von instructions/dev/issue-tracking.md sagt, der Body ist die aktuelle Wahrheit und wird umgeschrieben, wenn sich der Stand ändert. Nur ließ die Formulierung offen, wann — und Schritt 7 („Close with what actually happened") war vollständig erfüllbar, ohne den Body anzufassen. Ein Abschlussbericht im Kommentar fühlt sich beim Schreiben vollständig an; dass der Body dabei zurückbleibt, merkt erst der nächste Leser.

Schritt 2 ist deshalb schärfer geworden: der Body ist das Plan-File dieses Stacks. Dasselbe, was das Plan-Dokument eines Harness ist, und genauso gepflegt — fortlaufend, sobald etwas darin nicht mehr stimmt, nicht am Ende. Der Maßstab ist der Abbruch, nicht der Meilenstein: eine Session kann jederzeit enden, und was der Body in diesem Moment sagt, ist die vollständige Übergabe. Eine frische Session muss zu jedem Zeitpunkt allein aus dem Body weiterarbeiten können, ohne Kommentare rückwärts zu lesen und ohne einen Menschen, der es neu erklärt. Entschieden ersetzt die Frage, erledigt hakt das Kriterium ab, verworfen steht mit Begründung dort, wo das Kriterium stand.

Schritt 7 ist damit kein Sonderakt mehr, sondern die letzte dieser Aktualisierungen: erst Body auf den Endstand, dann schließen, dann die Changelog-Zeile aus Schritt 3. Wer Schritt 2 befolgt hat, ist fast fertig; wer nicht, zahlt die ganze Schuld im schlechtesten Moment — der geschlossene Body ist die Fassung, die danach alle lesen und niemand mehr aufsucht. #44 steht als Beispiel drin.

Schritt 3 zieht die Konsequenz: ein Kommentar pro Session-Umfang, nicht pro Edit. Ein fortlaufend gepflegter Body mit einem Changelog-Kommentar je Änderung wäre Lärm; triviale Pflege braucht gar keinen. Der stack-dev-Skill sagt es beim Aufgreifen mit, weil dort die Entscheidung fällt, ob eine Session den Body überhaupt anfasst.

Und die ehrliche Antwort auf die Frage nach dem Tooling: es gibt keins, und es soll keins geben. wikitool kennt diesen Tracker nicht. Es wird an Instanzen ausgeliefert, die unter dieser URL keine Issues haben, während instructions/dev/ von dist export gepruned wird — ein Gitea-Client im ausgelieferten Tool wäre eine Dev-Abhängigkeit, die jede Instanz mitträgt, um ein Board zu prüfen, das keine von ihnen hat. Der Tracker ist ausschließlich über gitea-mcp erreichbar, also in einer Session, durch einen Agenten.

Kein docs verify fängt also einen geschlossenen Issue, dessen Body offen klingt, einen Body, der seinen eigenen Kommentaren widerspricht, oder ein fehlendes Pflichtlabel. Das steht jetzt als eigener Abschnitt „What no tool checks" in der Instruktion — nicht als Bedauern, sondern als Begründung dafür, warum die Reihenfolge in Schritt 7 ausgeschrieben ist statt aus Schritt 2 erschlossen zu werden.

4.1.1 - 2026-09-03 - Testisolation: kb_dir repointet config.ROOT, lint löst Kollektionen gegen den übergebenen Baum auf

Author: Torben Nehmer

Issue #44, gefunden beim Bau der Migrations-Gate-Tests für 4.1.0: die kb_dir-Fixture baute ihren Baum unter tmp_path, ließ config.ROOT aber auf dem echten Checkout stehen. Jeder Codepfad, der eine Datei über config.ROOT/config.KB_DIR auflöst statt über das übergebene Verzeichnis, traf damit das echte Repository.

Der laute Fall war ein Test, der kb_state.write_kb_state() rief und dabei das .wikitool-kb.json des Repos überschrieb — Applied-Ledger leer statt zwei Einträgen. In git status sofort sichtbar und reversibel; bei einer gitignorierten Datei wäre es das nicht gewesen.

Der stillere Fall ist der teurere. lints Kollektions-Lookup löste eine Seite gegen config.KB_DIR auf. Für eine Seite unter tmp_path/kb/ warf das ValueError, die Funktion antwortete „keine Kollektion", und die Label-Autorisierung übersprang die Kante wortlos. unauthorised_labels war damit faktisch ungetestet — jeder Test, der das Finding hätte auslösen können, bekam eine leere Liste und behauptete nichts. Ein grüner Lauf, der wie eine Zusicherung aussah.

Der Fix ist der Codepfad, nicht die Fixture. run_lint() bekommt ein Verzeichnis übergeben und löst jetzt auch intern dagegen auf; authorised_labels() bekommt denselben Baum gereicht, statt auf config.KB_DIR zurückzufallen. Der Regressionstest lintet einen Baum, von dem ROOT bewusst wegzeigt — genau der Fall, den die alte Auflösung verschluckte. Eine Funktion, die ein Verzeichnis entgegennimmt, löst dagegen auf: keine Fixture kann diese Form von außen reparieren.

Beide Korpus-Fixturen repointen jetzt. kb_dir tut, was raw_dir längst tat — ROOT auf das eigene tmp_path, plus use_shipped_type_specs(). Der Suite-Lauf kippte dadurch keinen einzigen Test. Die lokale rooted_kb-Umgehung aus 4.1.0 entfällt damit; die Auswahl zwischen zwei fast gleichen Fixturen war Wissen, das nirgends stand.

Und ein Wächter für die ganze Klasse. repository_tree_guard (session-scoped, autouse) vergleicht git status --porcelain vor und nach dem Lauf und lässt die Suite scheitern, wenn sich im Checkout etwas bewegt hat — zwei git status-Aufrufe pro Lauf, deshalb per Default an. Er vergleicht vorher gegen nachher statt einen sauberen Baum zu verlangen, sagt also nichts über die unveröffentlichte Arbeit des Entwicklers. Den Verursacher benennt er nicht; CHEMENU_TREE_GUARD=each prüft nach jedem Test und tut es. Ohne git oder außerhalb eines Repositorys sind beide still.

Was der Wächter nicht sieht: eine Prüfung, die unter Test nichts tut, schreibt keine Datei. Dagegen hilft nur ein Test, der das Finding tatsächlich auslöst — der neue tut das.

instructions/dev/testing-conventions.md hat dafür einen eigenen Abschnitt („Which tree a test writes into"), einen Schritt in der Checkliste und die Regel für neue Fixturen.

4.1.0 - 2026-09-03 - Link-Taxonomie: Lint-Findings hart ab kb_version 4.0.0, outbound: an das Type-Spec gebunden, part-of/composition als Inversenpaar

Author: Torben Nehmer

Der Rest von Issue #40, nachdem die Korpus-Migration durch ist: die beiden aufgeschobenen Lint-Findings werden hart, und die drei Befunde aus dem Abschlusskommentar des Migrationslaufs werden aufgelöst.

unlabelled_edges und unauthorised_labels sind harte Fehler — aber an kb_version gebunden, nicht an ein Datum. Der Weg, den legacy_citation_markers genommen hat, war ein Umlegen in einer späteren Version: eine Instanz, die die Zitat-Migration noch schuldete, lebte danach mit rotem Lint. Das Ledger kann die Frage inzwischen beantworten, also tut es das. Unterhalb kb_version 4.0.0 bleiben beide beratend — genau das Fenster, in dem instructions/migrations/4.0.0-link-taxonomy.md der Instanz sagt, sie solle den halb konvertierten Korpus Einheit für Einheit publizieren; ein Check, der dabei fehlschlägt, würde den Korpus verweigern, dessen Fortschritt er misst. Ab 4.0.0 ist eine kahle Titelangabe in related: keine Seite mehr, die auf ihre Umstellung wartet, sondern eine Kante, deren Autor nicht gesagt hat, was sie behauptet. hard_error_keys() liefert die jeweils geltende Menge, HARD_ERROR_KEYS bleibt die vollständige.

outbound: ist an das Type-Spec gebunden. kb/sources/ und kb/comparisons/ autorisierten Label, die dort strukturell nicht schreibbar waren: keiner der beiden Type-Specs führte ein related:. Folgenlos war das nicht — die einzige Comparison-Seite des Korpus trug - **compares-with:** [[amd-pstate]] als handgeschriebene Prosa, ohne Marker-Region, ohne Frontmatter, für lint unsichtbar. Also ein Identifier zurück im Fließtext, gut vier Stunden nachdem 4.0.0 genau das beendet hatte. Eine leere Autorisierung liest sich als Lizenz.

Aufgelöst nach dem, was die beiden Contracts jeweils selbst sagen: comparison bekommt ein related: (die compares-with-Kante gegen jedes Subjekt ist die eine Aussage, für die die Seite existiert), kb/sources/ verliert seinen outbound:-Block ersatzlos (dessen Contract sagt ausdrücklich, seine Verknüpfungen seien der mechanische Provenance-Pfad und keine Autorenkanten). Neu prüft docs verify die Kombination: ein outbound:-Block auf einer Collection, in die kein Typ mit related: schreibt, ist ein Befund und nennt beide Richtungen der Reparatur.

composition / part-of ist das dritte Inversenpaar, neben depends-on / required-by und runs-on / hosts. Aus der Messung, nicht vom Schreibtisch: der u3-Lauf hatte entschieden, die Gegenseite eines composition bekomme see-also, weil part-of ein Spiegel wäre. Ist es nicht — der Satz des Elternteils zählt seine Teile auf, der des Kindes benennt das Ganze, zu dem es gehört, und ein Leser, der auf dem Kind landet, braucht den zweiten. Übrig blieben 16 see-also-Kanten für eine Beziehung, für die der Katalog ein Wort hat; sie sind auf part-of umgestellt. Ein Inversenpaar macht die Gegenkante weiterhin nicht zur Pflicht — Richtung wird verfasst, nicht gespiegelt —, es legt nur fest, welches Label sie trägt, wenn jemand sie schreibt.

Stack- und Korpusänderung laufen hier in einem Zug, entgegen der sonstigen Trennung. Der neue docs verify-Check würde eine bestehende 4.0.x-Instanz beim bloßen Kopieren der neuen Maschinerie fehlschlagen lassen, weil deren kb/sources/COLLECTION.md den outbound:-Block noch trägt — nach instructions/dev/version-parts.md Schritt 1 ein Grenzübertritt. Statt dafür eine 5.0.0 zu lösen, ist die Ursache mitbeseitigt: die Collection-Contracts dieser Instanz sind angepasst, und dist export leitet die COLLECTION.md.template daraus ab, also liefert jede neue Distribution die korrigierte Form aus. Für eine bereits bestehende 4.0.x-Instanz bleibt eine Handbewegung übrig, und sie wird hier benannt statt versteckt: die zwei outbound:-Zeilen aus kb/sources/COLLECTION.md löschen. Das neue related: im comparison-Type-Spec erreicht sie ohnehin nicht — die vier Page-Type-Specs gehören seit 4.0.0 der Instanz und werden nur als .template ausgeliefert.

Offen aus #40 bleibt nichts mehr; Befund 2 des Migrationslaufs (dem Katalog fehlt ein Register für Urheberschaft) ist als eigenes Issue erfasst.

4.0.1 - 2026-09-02 - Issue-Board: vier Pflicht-Label-Familien und Body-als-Wahrheit

Author: Torben Nehmer

Das Issue-Schema aus 1.2.1 hatte zwei Pflichtachsen und einen ausdrücklich begründeten Verzicht auf eine dritte: eine Taxonomie mit mehr Achsen brauche eigene Pflege, und das Board habe einen einzigen Betreuer. Diese Begründung ist entfallen, weil die Pflege inzwischen maschinell passiert - Body-Rewrites und Kommentare laufen über eine LLM-Sitzung, Menschen fassen in der Regel nur Labels an. Damit sind vier Achsen bezahlbar (Issue #41).

Pflicht auf jedem offenen Issue sind jetzt vier Label: area/ (kb, distribution, corpus, workflow, process - kein area/tools, Tooling wird nach der bedienten Domäne einsortiert, nicht nach Codeort), kind/ (decision, build, defect), prio/ (blocking, planned, waiting - reine Umbenennung von 1/2/3) und size/ (S, M, L; XS entfällt). Dazu zwei optionale Flags: status/blocked für Abhängigkeit von einem anderen offenen Issue, status/unconfirmed für einen ungeprüften Verdacht, unter dem size und prio vorläufig sind. Ein unconfirmed-Issue endet in der Triage entweder ohne Flag und mit verbindlichen Werten oder geschlossen mit Begründung - die Prozessentsprechung zu Invariante 3.

Der Issue-Body ist ab jetzt aktuelle Wahrheit, nicht Ursprungstext. Die Umsetzung eines Issues zieht sich über mehrere, zeitlich getrennte Sitzungen, und der Body ist das einzige, was sie verbindet: eine Sitzung muss aus ihm allein rekonstruieren können, was entschieden und was offen ist. Er wird deshalb umgeschrieben statt ergänzt. Jeder Rewrite bekommt einen Kommentar, der ausschließlich benennt, was sich geändert hat - keine Vollkopie des alten Stands, weil ein Mensch zwei Fließtexte nicht diffen kann und eine Kopie pro Revision damit keine Historie ist, sondern nur eine weitere Kopie.

Geändert: instructions/dev/issue-tracking.md (Schritte 2, 3, 5 neu; Schritt 4 um area/ und kind/ erweitert; der Entscheidungspunkt „Two labels feel too coarse?" entfällt) und die Beschreibungszeile in instructions/dev/stack-dev/SKILL.md. Für eine ausgelieferte Instanz ändert sich nichts: dist export schließt instructions/dev/ vollständig aus, weshalb dies ein PATCH ist und kein MINOR - dieselbe Begründung wie bei 1.2.1. Noch offen aus #41: kb/concepts/Issue Label Scheme.md beschreibt weiterhin das zweiachsige Schema und braucht eine eigene wiki-manage-Sitzung.

4.0.0 - 2026-09-02 - Prosa ist kein Identifier: Link-Taxonomie als Enum, generierte Regionen mit Markern

Author: Torben Nehmer

Breaking Change: Beziehungslabel sind Enum-Werte in related: statt Freitext im Body-Bullet, toolgefuehrte Abschnitte liegen zwischen Marker-Paaren statt hinter ihrer Ueberschrift, und xref add schreibt nur noch eine Kante statt beider Richtungen. tools/chemenu/sections.py ist geloescht. Eine bestehende Instanz muss sections: in kb/CONVENTIONS.md auf links/footnotes umstellen, outbound: in jede COLLECTION.md eintragen, die {section.*}-Variablen aus ihren Page-Type-Templates entfernen und den Korpus umstellen - sonst scaffoldet new die Variablen woertlich in neue Seiten. Ablauf: instructions/migrations/4.0.0-link-taxonomy.md

Der Stack benutzte an drei Stellen Prosa als Identifier, und jede hat messbar etwas gekostet. Die Überschrift eines Abschnitts war seine Adresse (^## Beziehungen$), was die KB-Sprache zu einer Compiler-Konstante machte und das Ende der Region zur Schätzung - sie lief bis zur nächsten Überschrift, davor bis zum Dateiende, und hat auf acht Seiten still Inhalt gelöscht. Das Beziehungslabel stand nur im Body-Bullet, also konnte nichts das Vokabular prüfen: gemessen am Korpus 152 distinkte Label in 337 Bullets gegen dreizehn dokumentierte, 102 davon genau einmal vorkommend. Und xref add spiegelte jede Kante, was ## Siehe auch mit 555 Bullets ohne Label füllte - 353 davon beweisbar redundant.

Was jetzt Identifier ist. Eine Region liegt zwischen  bzw.  und wird vollständig aus dem Frontmatter gerendert, Überschrift eingeschlossen. Ein Label ist ein Maschinenwert in related: (- depends-on: Hermes), gezogen aus instructions/link-taxonomy.md und pro Ziel autorisiert von der Quell-Collection (outbound: im COLLECTION.md, Commonplaces ADR-019). Der Body-Bullet ist eine Darstellung dieser Daten, nicht ihr zweiter Aufbewahrungsort.

Gelöscht, ersatzlos: tools/chemenu/sections.py komplett, heading_re, der Alias-Mechanismus, PRE_CONVENTIONS_NAMES, cite_block_heading, provenance.__getattr__, die {section.*}-Template-Variablen, xrefs Abschnittssuche. Kein Überschriftentext liegt mehr in Python - bis auf zwei kosmetische Fallbacks, und die sind harmlos geworden: der Marker trägt die Identität, also rendert ein falscher Default falsche Wörter statt Struktur zu zerlegen, und der nächste Write repariert es.

Kanten sind direktional, und das war keine Geschmacksfrage. Die per-Collection-Autorisierung ist mit einer automatisch gespiegelten Gegenkante logisch unverträglich: die Spiegelhälfte entsteht in einer Collection, deren Regeln der Autor nie gelesen hat. Entweder schriebe das Werkzeug unautorisierte Kanten, oder die Regel "die Quellcollection entscheidet" löst sich auf. Der Navigationseinwand wird dabei besser beantwortet als vorher: wikitool links show --page berechnet die Eingangssicht über den Korpus, vollständig und ohne Pflege, und das gerenderte Bullet ist ein gewöhnlicher [[wikilink]] - ein Backlink-Panel zeigt es ohnehin. Die erzwungene Gegenkante garantierte nie Vollständigkeit, nur dass jemand daran gedacht hat.

Der Orphan-Check meldet dadurch mehr, und das ist die Prüfung bei der Arbeit: sie misst jetzt Erreichbarkeit statt "ist xref gelaufen".

obligation: trennt zwei Achsen, die vorher eine waren. migration_kind: sagt wie gearbeitet wird, neu obligation: required|offered ob überhaupt. Eine offered-Migration ist ein Angebot für eine Datei, die der Instanz gehört - sie blockiert nie, steht nicht in der Kette, und migrate done verbucht sie im Ledger, ohne kb_version zu bewegen. Genau daran hing ein Entwurfsfehler, den erst der Test gezeigt hat: Offers gegen kb_version zu filtern hätte jede Offer verschwinden lassen, sobald irgendein unbeteiligter Pflichtschritt lief. Dazu ist die Erkennungshälfte aktiviert, die seit ihrer Einführung ungelesen dalag - die sha256 pro Datei in .wikitool-release.json beantwortet jetzt "editiert oder nur empfangen", also ob eine Offer kopiert werden darf oder von Hand abgeglichen werden muss.

types/ teilt sich entlang root:. root: kb heißt Wissensseite heißt Instanz: die vier Page-Type-Specs samt Schemas gehen als .template, instruction/lint-report/type-spec verbatim. Damit ist die deutsche Prosa in jenen vier Dateien korrekt statt Migrationsschuld - es war die richtige Sprache an einem Ort mit falsch deklariertem Eigentümer. Was der Stack von der Type-Schicht noch verlangt, ist eine Zeile: ein Type-Spec name: source, dessen Schema raw_files fordert. STACK_REQUIRED_COLLECTIONS entfällt als separate Liste - die pflichtige Collection wird aus dem base_dir dieses Typs abgeleitet.

Warum das MAJOR ist. Vorwärts: sections: hat eine andere Form, outbound: fehlt, und die in 3.0.0 übernommenen Page-Type-Templates enthalten {section.*}-Variablen, die es nicht mehr gibt - new schriebe sie wörtlich in neue Seiten. Rückwärts: 4.0.0 schreibt gelabelte Kanten, die 3.0.0s Schema als type: string ablehnt. Beide Hälften des Drop-in-Tests fallen.

Der Korpus dieser Instanz ist noch nicht umgestellt. Diese Version liefert die Maschinerie; lint meldet die 480 noch ungelabelten Kanten als Findings, nicht als Fehler, weil das genau das Fenster ist, für das .wikitool-kb.json existiert. malformed_edges und unbalanced_markers sind dagegen sofort hart - keines beschreibt eine unkonvertierte Seite, nur eine kaputte. Die Beförderung der beiden anderen kommt, wenn der Korpus sie bestehen kann.

3.0.0 - 2026-09-02 - Autorenkonventionen nach Eigentum geschnitten: kb/CONVENTIONS.md, deklarierte Collections

Author: Torben Nehmer

Breaking Change: kb/CONTRACT.md ist um alles gekuerzt, was eine Instanz selbst entscheidet; das steht jetzt in einer neuen, instanzeigenen kb/CONVENTIONS.md, aus der der Compiler die drei toolgefuehrten Abschnittsnamen liest. Eine bestehende Instanz muss diese Datei anlegen, auf jedem kb/*/COLLECTION.md profile: und required_by_stack: deklarieren und kb/CONTRACT.md aus dem Release nachziehen - sonst FAILt doctor und docs verify bricht. Ablauf: instructions/migrations/3.0.0-authoring-conventions.md

kb/CONTRACT.md war eine Datei mit zwei Autoritäten. Der eine Teil ist code-erzwungen und in jeder Instanz gleich; der andere - § Language komplett, das Beziehungslabel-Vokabular, die Tonfall-Beispiele samt deutscher Buzzword-Liste, die Confidence-Rubrik, das ADR-Präfix - ist Konvention, die jede Instanz für sich entscheidet, und wurde trotzdem als bindender Contract verbatim ausgeliefert. Wer bei Schritt 5 von setup-instance.md "Englisch" antwortete, hatte danach kb/CONTRACT.md, vier Type-Specs und tools/chemenu/sections.py lokal geändert - und private-instance.mds Decision Point sagt für so einen Merge-Konflikt: Upstream-Seite nehmen. Für diese Instanz hieß das: KB-Sprache zurück auf Deutsch.

Der Schnitt läuft jetzt danach, wer den Satz ändern darf. kb/CONTRACT.md behält, was wikitool erzwingt; neu daneben liegt kb/CONVENTIONS.md, die genauso bindet und der Instanz gehört. Unterschied ist Eigentum, nicht Autorität - deshalb liefert die Distribution nur kb/CONVENTIONS.md.template, exakt der USER.md/SOUL.md-Split ein Verzeichnis tiefer. Dazu instructions/kb-profiles.md: der Katalog erprobter Profile, ausdrücklich Palette und kein Enum. Übernommen wird der Text in die Instanzdatei, nie ein Verweis auf den Katalog - ein Verweis wäre wieder genau die Konstruktion, die dieser Release beendet.

sections.py hält keine Überschrift mehr. RELATIONSHIPS = "Beziehungen" war die Stelle, an der die Konvention in Code übergelaufen war: solange sie dort stand, konnte kein Template die Sprache umstellen. Neu ist tools/chemenu/conventions.py, das die drei Namen aus kb/CONVENTIONS.md liest; sections.py löst sie per PEP 562 bei jedem Zugriff auf, wie config seine Pfade - ein Modulkonstante hätte den Wert an den Baum gebunden, in dem der Prozess gestartet ist. Aus demselben Grund ist provenance.CITE_BLOCK_HEADING ein __getattr__ und render_cite_block(heading=None) löst innerhalb des Aufrufs auf. Der Alias-Mechanismus, den das Modul schon hatte, ist der Migrationspfad: erkannt wird die kanonische Form plus die deklarierten section_aliases: plus das, was dieser Stack vor der Konventionsdatei geschrieben hat. Ohne Datei antwortet dieser Fallback - richtig für jeden Korpus, der ihn erreichen kann, denn der wurde unter genau diesen Namen geschrieben; doctor ist die laute Hälfte davon.

Die vier Page-Type-Specs schreiben ## {section.relationships} statt einer Überschrift. Neue Template-Variablen {section.relationships} / {section.see_also} / {section.footnotes}, gefüllt aus der Instanzdeklaration. Damit ändert eine anderssprachige Instanz keine Datei unter tools/ oder types/ mehr - was Schritt 5 von setup-instance.md von fünf Editierstellen über drei Schichten auf eine Entscheidung reduziert.

COLLECTION.md bekommt Frontmatter. Bisher wurde eine Collection rein an der Dateipräsenz erkannt; die Deklaration brauchte einen Träger, sonst wäre der Ortsschnitt nur durch einen Prosaschnitt ersetzt worden. profile: nennt den übernommenen Katalogeintrag (Freitext - eine selbst angelegte Collection hat dort keinen), required_by_stack: sagt, ob wikitool die Collection namentlich auflöst. Das zweite ist nicht die Wahl der Instanz: docs verify prüft es beidseitig gegen kb_collections.STACK_REQUIRED_COLLECTIONS. Heute steht dort genau sources - sources coverage, die [^cite-id]-Auflösung und kb/provenance.md hängen an dem Namen, entities an keinem.

Das zweite Leck der Merge-Prozedur ist zu. git checkout HEAD -- kb raw holte alles unter beiden Stages auf den Vor-Merge-Stand - auch kb/CONTRACT.md und raw/CONTRACT.md. Änderte der Upstream einen davon, warf die Prozedur das Update still weg, und die Kontrollzeile meldete dabei leer, bestätigte den Fehler also, statt ihn zu fangen. private-instance.md nimmt die Upstream-Seite jetzt für die drei Maschinerie-Pfade unter den Content-Stages zurück (kb/CONTRACT.md, kb/CONVENTIONS.md.template, raw/CONTRACT.md) und schließt sie aus der Kontrollzeile aus. Dieselbe Altlast in der Tarball-Richtung: INSTALL.md Schritt 3 fasste kb/ gar nicht an und zog kb/CONTRACT.md damit nie nach - jetzt ausdrücklich benannt.

Verworfen, gemessen: sources/ aus kb/ herausziehen. Der Graph ist einwurzelig (kb_scan.iter_kb_pages macht ein rglob über kb/, darauf sitzen Link-Graph, Orphan-Check, index rebuild und search), und Source-Seiten sind darin der dichteste Knotentyp. Ein Hoist machte jede Graph-Operation dauerhaft zweiwurzelig, um ein Verzeichnis umzubenennen. Vor allem aber kann der Ort Eigentum ohnehin nicht kodieren, sobald Collections offen sind: eine selbst angelegte liegt im selben kb/ wie die Defaults. Eigentum ist eine deklarierte Eigenschaft - daher das Frontmatter oben. Gitea #39 trägt die Ablehnung im Volltext.

Warum das MAJOR ist. Die Rückwärtshälfte des Drop-in-Tests hält - 2.5.0 ignoriert beide neuen Deklarationen folgenlos. Die Vorwärtshälfte nicht: nach dem Kopieren der Maschinerie FAILt doctor auf der fehlenden kb/CONVENTIONS.md, docs verify bricht auf den undeklarierten Collections, und kb/CONTRACT.md muss aus dem Release nachgezogen werden. Ein Shim war die Alternative (doctor nur WARN, Pflichtfelder tolerant) und wurde verworfen: er hätte genau den Zustand normalisiert, in dem eine Instanz glaubt, sie habe entschieden, während in Wahrheit der Fallback antwortet - für eine englische Instanz hieße das ## Beziehungen in englischen Seiten. Die Handarbeit ist eine Datei und zwei Frontmatter-Zeilen je Collection; keine einzige kb/-Seite ändert sich, weshalb migrate done 3.0.0 --pages 0 ehrlich und kein Platzhalter ist.

2.5.0 - 2026-09-02 - Versionsstelle: Kompatibilitaet statt Inhaltsmigration, Breaking-Change-Vermerk erzwungen

Author: Torben Nehmer

Die Doku des Stacks führte für die Wahl der Versionsstelle zwei Fragen zusammen, die nicht dieselbe sind: muss der Korpus migriert werden? und ist die neue Version ein Drop-in-Ersatz? An allen drei Stellen, die einer Session vor dem Bump begegnen - die Tabelle in stack-dev, der Modul-Docstring in version.py, INSTALL.md § Version und Updates - stand nur die erste. Nur version bump --help formulierte es richtig, also ausgerechnet die Stelle, die man erst liest, wenn die Entscheidung gefallen ist. Bei 2.0.0 hat genau diese Lücke zu 1.9.0 geführt (Gitea #26; der Eintrag zu 2.0.0 trägt den Fall im Volltext).

Die Regel, jetzt an einer Stelle. Neu ist instructions/dev/version-parts.md: der Drop-in-Test in zwei Hälften - vorwärts (kopieren, fertig, keine Handarbeit durch Nutzer oder Migrationsskript) und rückwärts (die alte Version lässt sich noch zurückinstallieren) -, der Katalog der Brüche, die die Grenze bei völlig unangetastetem kb/ überschreiten (Update-Pfad, Artefaktname, Import-Name, Flags, Envvars, Shape maschinengelesener Dateien), und der Fall 2.0.0 als Fallbeispiel. instructions/dev/, also nicht in einer ausgelieferten Instanz - die Datei entscheidet, wer den Stack entwickelt. Die ausgelieferten Artefakte tragen deshalb die Kurzform der Regel, aber keinen Verweis auf sie: instructions verify meldet einen solchen Verweis, weil er nach dist export ins Leere zeigen würde.

Breaking Changes sind teuer, also genehmigungspflichtig. stack-dev hat einen Entscheidungspunkt bekommen: stellt sich eine Änderung als nicht drop-in heraus, wird nicht aus eigener Initiative über die Grenze gebumpt. Vorgelegt werden der konkrete Bruch, was jede bestehende Instanz von Hand tun muss, und die Alternativen - Bruch per Shim vermeiden, aufschieben und mit dem nächsten bündeln, oder in einen kompatiblen und einen brechenden Teil mit Deprecation-Fenster spalten -, dazu eine Empfehlung. Dann Freigabe abwarten.

--breaking ist neu und bei jedem Grenzübertritt Pflicht. Es schreibt eine **Breaking Change:**-Zeile in den Eintrag, vor die Migrationszeile: das ist, was der Operator einer bestehenden Instanz beim Lesen der Release-Notes zuerst braucht. docs verify prüft den neuesten grenzüberschreitenden Eintrag darauf, analog zu **Migration:** none required und aus demselben Grund - eine Prosa-Regel driftet, ein Marker nicht. Auf einem kompatiblen Bump wird --breaking verweigert, damit es keine Gewohnheit wird. Beide Prüfungen bleiben getrennt: check_migration_for_boundary fragt, ob der Inhalt sich bewegt, check_breaking_change_for_boundary, ob dem Operator gesagt wurde, dass der Tausch keiner zum Drüberkopieren ist. Ein Rebranding besteht die erste und fällt durch die zweite.

Was ausdrücklich nicht passiert: docs verify prüft weiterhin nicht, ob die Stelle richtig gewählt wurde. Kein Validator unterscheidet ein umbenanntes Flag von einem neuen; das bleibt Urteil, und dieser Eintrag existiert, weil das Urteil eine Anleitung braucht, keinen Automaten.

Berührt: instructions/dev/version-parts.md (neu), instructions/dev/stack-dev/SKILL.md, tools/chemenu/version.py, tools/chemenu/commands/version_cmd.py, tools/chemenu/commands/docs_verify.py, tools/CONTRACT.md, INSTALL.md. Sechs neue Tests.

2.4.1 - 2026-09-02 - INSTALL-MCP.md: Menschendoku fuer den Leseserver, und sie wird mit ausgeliefert

Author: Torben Nehmer

Nachtrag zu 2.4.0. Der Server war ausgeliefert und für Menschen nur über tools/CONTRACT.md und eine Instruktion beschrieben — beide für Agenten geschrieben. INSTALL-MCP.md schließt das, neben INSTALL.md und in derselben Form: Voraussetzungen, sechs Schritte, Verifikation, Troubleshooting.

Was drinsteht, das sonst nirgends zusammen stand: die Client-Konfiguration als JSON-Block; dass WIKI_TRACE=0 nicht optional ist und wie die Startverweigerung aussieht; dass --host 0.0.0.0 bewusst nicht der Default ist; und der Verweis auf die Traefik-ForwardAuth-Middleware unter https://gitea.nehmer.net/torben/gitea-mcp-forward-auth samt dem, was sie erwartet (Bearer-Token gegen SHA-256-Hashes, AUTH_PROXY_TOKEN_HASHES_DIR). Der Verifikationsabschnitt ist ein lauffähiges Skript — wörtlich so ausgeführt, bevor es hier landete.

dist export liefert die Datei mit. ROOT_FILES ist eine Allowlist, also hätte sie sonst keine Instanz erreicht: ein ausgelieferter Server, dessen Bedienungsanleitung im Ursprungs-Repo zurückbleibt, ist einer, den der Empfänger durch Quelltextlesen findet. INSTALL.md bekommt zusätzlich CHEMENU_ROOT und WIKI_TRACE/WIKI_TRACE_DIR in seine Konfigurationstabelle — beide waren seit 2.3.0 bzw. seit jeher wirksam und dort nicht aufgeführt.

Dateien: INSTALL-MCP.md (neu), INSTALL.md, README.md, tools/chemenu/commands/dist_cmd.py.

2.4.0 - 2026-09-02 - MCP-Leseserver: zweiter Konsument auf demselben Kern

Author: Torben Nehmer

Letzter Schritt der Sequenz aus #36, inhaltlich Issue #19. chemenu bekommt einen zweiten Konsumenten: search, types, describe_type, lint und status über MCP. Kein CLI mit angeschraubter Netzwerkschnittstelle — CLI und Server sind zwei Adapter auf dem Kern, den 2.3.0 freigelegt hat.

tools/chemenu/mcp/, im Repo statt als eigenes Artefakt. Der Golden-Test, der die Serverantworten gegen die --json-Formen der CLI hält, läuft nur mit beiden Seiten in einer Testsuite; getrennt würde aus einem Contract eine Versionsabsprache. Der Test ruft wikitool als Subprozess gegen denselben Baum auf, über CHEMENU_ROOT — womit er nebenbei die Root-Auflösung von außen mitprüft.

Zwei Transports. stdio zum Entwickeln und Testen ohne Netz, streamable-http für die Auslieferung — der einzige, vor den sich die Authentifizierungs-Middleware überhaupt setzen kann, weil sie ein HTTP-Reverse-Proxy ist. sse ist über das SDK erreichbar und wird bewusst nicht angeboten: der abgelöste Remote-Transport, jetzt darauf zu bauen verschiebt den Wechsel nur. --host/--port gibt es, weil der Default auf Loopback bindet und ein Container hinter einem Proxy eine Adresse braucht, die der Proxy erreicht — eine Eigenschaft der Software, nicht einer Installation. Beide Transports sind gegen den echten Korpus gegengeprüft.

Kein Schreibpfad, strukturell. Weder der Server noch chemenu.api importiert irgendetwas unter chemenu.commands, also existieren new, touch, xref, cite, publish, migrate und version bump in dieser Reichweite gar nicht, statt aus einer Liste gefiltert zu werden. Ein Test importiert das Servermodul in einem frischen Interpreter und sieht in sys.modules nach; ein zweiter ruft alle fünf Tools auf und vergleicht den Dateibaum, HEAD und git status --porcelain vorher/nachher.

Jede Antwort trägt ihren Commit. commit und as_of in jedem Payload; null heißt, der bediente Baum hat uncommittete Änderungen und die Antwort entspricht keiner Revision. Der Stempel ist die Revision, aus der die Seiten tatsächlich gelesen wurden — zwischen Laden und Stempeln kann der Baum sich bewegen, deshalb reicht der Ladepfad seine Revision durch, statt noch einmal zu fragen. Das war beim ersten Durchlauf falsch: types/lint/status lasen die zuletzt gecachte Revision und stempelten null, obwohl der Baum sauber war.

Telemetrie in den bedienten Baum wird beim Start verweigert, nicht stillschweigend umgeleitet. Tracing ist per Default an und schreibt nach reports/telemetry/ im Repo — genau das Verzeichnis, das der Sync per git reset --hard wegräumen darf. WIKI_TRACE=0 oder WIKI_TRACE_DIR außerhalb des Korpus. Heute schreibt auf diesem Pfad nichts (der Emitter hängt an cli.main() und den Gates), die Sperre ist gegen später.

Fehler an der Protokollgrenze. Ein ChemenuError wird zum ToolError des SDK — eine absichtliche Ablehnung, deren Text den Aufrufer erreicht. Alles andere bleibt ein Absturz, dessen Text auf dem Server bleibt. Ein kaputtes Prädikat ist das Argument des Aufrufers, also muss die Zeile mitreisen, die sagt, was stattdessen zu schreiben ist.

Bewusst nicht enthalten: Authentifizierung und Rate Limiting (Middleware vor dem Prozess), Deployment (private Infrastruktur), der Iteration Budget Gate — er begrenzt eine Agenten-Session und nicht einen Nutzer, weshalb Retrieval von ihm befreit ist; ihn hier als Rate Limiter zu benutzen würde ihn dazu verwässern.

Die Abhängigkeit ist optional (tools/requirements-mcp.txt): eine Instanz, die nur die CLI benutzt, soll dafür nicht pydantic, starlette, uvicorn und cryptography installieren müssen. CI installiert sie, denn ein übersprungener Golden-Test ist genau der Weg, auf dem Server und CLI unbemerkt auseinanderlaufen.

Betrieb und Sync-Mechanismus: instructions/mcp-read-server.md. Polling (git fetch && git reset --hard) statt Webhook — kein eingehender Endpunkt, keine Signaturprüfung. reset --hard ist dort tragend und keine Bequemlichkeit: ein abgedrifteter Baum antwortet zwar richtig, parst aber bei jeder Anfrage neu und stempelt jede Antwort mit null.

Dateien: chemenu/mcp/ (neu: server.py, __main__.py), chemenu/api.py, tools/requirements-mcp.txt (neu), instructions/mcp-read-server.md (neu), tools/CONTRACT.md, tools/README.md, .gitea/workflows/ci.yml, tests/test_mcp_server.py (neu).

2.3.0 - 2026-09-02 - Bibliotheksgrenze: chemenu laesst sich auf einen Korpus zeigen

Author: Torben Nehmer

Dritter Schritt der Sequenz aus #36, inhaltlich Issue #31. Der Schritt, der chemenu von einem Skript, das in seinem eigenen Verzeichnis lebt, zu einer Bibliothek macht, auf die man einen Korpus zeigen kann. Rückwärtskompatibel: ohne gesetzte Variable verhält sich tools/wikitool unverändert.

Root-Auflösung nach Präzedenz statt nach Dateilage. config.resolve_root(): expliziter Parameter → $CHEMENU_ROOT → Walk-up wie bisher. Der Walk-up bleibt Default. Wichtiger als die neue Fähigkeit ist die beseitigte Fehlerklasse: ROOT und alles darunter waren Modulkonstanten, also zur Importzeit gebunden, und monkeypatch.setattr(config, "ROOT", ziel) zeigte ROOT um, aber nicht KB_DIR/RAW_DIR. Wer sich darauf verließ, baute etwas, das scheinbar auf einem Zielbaum arbeitete und in Wahrheit aus dem Entwickler-Checkout antwortete. Die abgeleiteten Pfade werden jetzt bei jedem Zugriff aufgelöst (PEP 562 __getattr__) und folgen ROOT — der halb-umgezeigte Zustand ist nicht mehr konstruierbar. CHEMENU_ROOT ist in _WIKITOOL_ENV registriert, #23-konform.

config.reset() und config.rooted(). reset() nimmt Zuweisungen auf die verwalteten Pfadnamen zurück; die Testsuite ruft es zwischen Tests, und das ist dort nicht optional: monkeypatch merkt sich den alten Wert, indem es ihn liest — also auflöst — und schreibt ihn beim Aufräumen als echtes Attribut zurück. Genau die stale Bindung, die der Umbau unmöglich machen sollte, vom Cleanup wieder aufgebaut. rooted(root) setzt den Root für die Dauer eines Blocks, prozessweit und damit nicht thread-sicher — der Aufrufer hält das Lock, dieselbe Disziplin wie beim Korpus-Cache. Nötig, weil nicht alles einen Root als Argument nimmt: der modulglobale TypeResolver muss types/ finden, und ohne ihn läse ein fremder Korpus mit den Type-Specs dieses Checkouts.

Die Naht ist gezogen. run_search/run_lint/types lagen in Modulen, die typer auf Modulebene importieren und über _util auch rich — wer sie in-process aufrief, zog den kompletten CLI-Kopf mit. Der reine Kern liegt jetzt in search/service.py, lint_core.py und types_core.py; commands/ sind die Terminal-Adapter darüber und re-exportieren die Namen, damit kein bestehender Import bricht. Ein Test importiert chemenu.api in einem frischen Interpreter und prüft, dass weder chemenu.commands.* noch typer/rich/click geladen werden.

chemenu.api.Corpus als In-Process-Einstieg. Nimmt einen Root, liefert exakt die --json-Formen der CLI zurück — ein Wire-Contract statt zwei — und stempelt jede Antwort mit dem Commit-SHA und einem Zeitstempel (commit, as_of), so dass aus einer stillen veralteten Antwort eine sichtbare wird. search/lint/types/describe_type/status; status ist bewusst serverseitig komponiert und kein Wrapper, weil es kein wikitool status gibt. Lesend strukturell: nichts unter chemenu.commands wird importiert, die Schreibfunktionen existieren in dieser Oberfläche also gar nicht, statt gefiltert zu werden. Das ist die Grenze, auf der #19 aufsetzt.

Exceptions statt Exit-Codes an der Grenze. chemenu/errors.py: ChemenuError mit ValidationError (Eingabe abgelehnt) und BackendError (Abhängigkeit fehlt oder scheitert). PredicateError, FrontmatterError, UnknownBackend und die beiden Ripgrep* hängen jetzt darunter; ValidationError erbt zusätzlich von ValueError, weil PredicateError vorher eines war und Aufrufer es so fangen. Das CLI-Verhalten ist unverändert: fail() → ERROR-Zeile, Exit 1, Budget-Refund.

resolve() reicht den Root an das Backend durch. Vorher konnte ein Aufrufer run_search einen Korpus übergeben, während RipgrepBackend weiter config.KB_DIR durchlief — die Anfrage aus dem einen Baum beantwortet, die Seiten aus dem anderen gelesen, ohne dass irgendetwas das gesagt hätte.

Zwei Abhängigkeiten, die durch Zufall hielten, stehen jetzt da. TypeResolver.repo_root folgt ROOT, statt beim Import zu binden — womit Fixtures, die ROOT auf einen tmp-Baum zeigen, die mitgelieferten Type-Specs ausdrücklich benennen müssen (use_shipped_type_specs). Dieselbe Form wie das Loch, für das raw_dir geschrieben wurde, eine Ebene tiefer. Und types describe --json trug root: nicht im Payload, obwohl types list --json es tut: types/instruction.md deklariert root: repo, die Renderer-Zeile las es direkt aus dem Frontmatter. Jetzt im Payload, in derselben Form wie bei list.

Dateien: config.py, errors.py (neu), api.py (neu), search/service.py (neu), lint_core.py (neu), types_core.py (neu), search/registry.py, type_resolver.py, commands/search.py, commands/lint.py, commands/types_cmd.py, tools/CONTRACT.md, dazu tests/conftest.py, tests/test_api.py (neu), tests/test_new_page.py, tests/test_instructions_cmd.py.

2.2.4 - 2026-09-02 - Haertung des Lesepfads: ReDoS, Subprozess-Timeout, YAML-Alias-Budget, Korpus-Cache

Author: Torben Nehmer

Zweiter Schritt der Sequenz aus #36, inhaltlich Issue #33. Limits vor der Exposition: der Lesepfad bekommt mit dem MCP-Server (#19) einen Konsumenten, der nicht der Operator ist. Alle sechs Befunde waren reproduziert, nicht vermutet; jeder hat jetzt eine Regression.

ReDoS über --regex beseitigt. search/ripgrep.py:_contains gab nutzergesteuerten Regex an Pythons Backtracking-Engine: (\w+\s?)+$ gegen 114 Zeichen gewöhnlichen Seiteninhalts terminiert nicht in acht Sekunden, ein deterministisch scheiterndes Muster braucht 0,2 ms — der Unterschied ist das Muster, nicht der Heuhaufen. build_hit ruft die Funktion je Treffer zweimal auf, und \w matcht jede Seite: eine Anfrage kaufte zwei unbegrenzte Suchen pro Korpusseite. Der Zweig ist gelöscht, nicht begrenzt. rg hat das Muster mit einer linearen Engine längst angewendet, wenn die Funktion überhaupt läuft; verloren geht nur der zusätzliche Titel-/Summary-Bonus für nicht-literale Muster, und Summary wie H1 sind selbst Zeilen in der Datei, die rg zählt.

Subprozess-Timeout. rg wird nach 30 s abgeräumt und über den vorhandenen RipgrepFailed-Pfad gemeldet. Kein Performance-Budget — eine Fixed-String-Suche kostet hier 6 ms — sondern ein Hänger-Abbruch, damit ein Aufruf als Fehler endet statt den Aufrufer offenzuhalten, während seine Ausgabe in den Heap puffert.

YAML-Anchors und -Aliases im Frontmatter werden verweigert, nicht budgetiert. Gemessen: 267 Byte werden in 0,2 ms zu 672.603 Knoten beim Traversal, Wachstum 9ⁿ bei konstanter Parse-Zeit — ein Größenlimit fasst das nicht an, weil die Eingabe klein bleibt. Die Prüfung läuft auf dem Event-Strom (yaml.parse), der nichts auflöst, kostet also O(Text) und löst nie aus, wonach sie fragt; * ist in jedem Alias-Knoten notwendig, seine Abwesenheit beweist Abwesenheit ohne jeden Parse — der Weg, den jede echte Seite nimmt. Dazu ein Größenlimit von 64 KiB und ein Abfangen von RecursionError (PyYAML komponiert rekursiv, tiefe Verschachtelung ist kein YAMLError). Heute nicht erreichbar, weil kb/ der Operator committet; erreichbar mit der Ingest-Queue (#32).

CSafeLoader statt SafeLoader, mit Fallback. Gemessen über diesen Korpus (176 Seiten, best of 5): 265 ms → 54 ms. Kein Mikro-Tuning — der Korpus-Parse war der größte Einzelposten eines search-Aufrufs und skaliert linear mit der Korpusgröße. End-to-end fällt ein wikitool search damit von 593 ms auf 347 ms; die verbleibenden 262 ms sind Modulimport und entfallen erst im residenten Prozess (#19).

Stiller Frontmatter-Verlust wird gemeldet. Entschieden: der Lesepfad nennt die Seite, statt sie zu schlucken. Kaputtes YAML wird weiterhin zu {} — Massenoperationen dürfen an einer Seite nicht scheitern —, aber der Grund wird mitgeführt (Page.frontmatter_error) und ausgegeben: search --json trägt immer eine unreadable-Liste aus {path, reason}, die Tabellenform schreibt dieselben Zeilen nach stderr. Das war nötig, weil so eine Seite weder confidence noch kind hat und damit aus jedem positiven --field-Prädikat fällt — ausgerechnet aus der Low-Confidence-Suche, die Seiten in genau diesem Zustand finden soll — und dabei aussieht wie eine Seite, die nicht gematcht hat. Für Frontmatter, das diese Instanz nicht selbst geschrieben hat, steht read_page_strict() bereit: die Quarantäne aus #32 muss strikt lesen, wo ein unlesbares Dokument das Dokument stoppen und nicht leeren soll.

Ein Parser statt zwei. read_page() und frontmatter_error() liefen bisher getrennt durch safe_load — so konnte der permissive Weg zu {} degradieren aus einem Grund, den der strikte Weg anders beschrieb, und jeder Aufrufer, der beide Antworten wollte, las die Datei zweimal. Beide gehen jetzt durch _load_frontmatter(); ein Test hält sie gegeneinander.

Korpus-Cache am Commit-SHA (chemenu/corpus_cache.py), als Objekt, das ein Aufrufer hält — kein Modul-Dict, das sich hinter allen einschaltet. Die CLI hält keins und verhält sich unverändert (ein Aufruf pro Prozess, nichts wiederzuverwenden); der residente Prozess aus #19 hält eins. Entscheidend ist nicht die Geschwindigkeit, sondern dass nichts veraltet: ein schmutziger Arbeitsbaum wird nie gecacht, sonst bekäme eine Sitzung, die eine Seite schreibt und danach sucht, die Analyse von vor dem Schreiben — bei unverändertem SHA. Kann git nicht antworten, gilt der Baum als schmutzig. Derselbe SHA ist der Antwort-Stempel aus #19, per Konstruktion also die Revision, aus der die Antwort auch wirklich berechnet wurde.

Erhalten geblieben ist die Eigenschaft, die kein Befund war: kein shell=True, --fixed-strings als Default, ---Terminator. Der Modul-Docstring führt sie jetzt als drei tragende Zusagen statt zwei — die dritte ist, dass nutzergesteuerte Muster ausschließlich rg sieht.

Dateien: frontmatter_io.py, search/ripgrep.py, commands/search.py, page.py, corpus_cache.py (neu), tools/CONTRACT.md, dazu tests/test_frontmatter_io.py, tests/test_search.py, tests/test_corpus_cache.py (neu).

2.2.3 - 2026-09-02 - Publish-Remote-Gate in diesem Checkout scharf, doctor benennt den Zustand

Author: Torben Nehmer

Erster Schritt der Sequenz aus Issue #36 (Weg zum MCP-Leseserver), inhaltlich Issue #34. Das Gate war seit 2.2.0 implementiert und in diesem Checkout inert: .wikitool-remotes.json fehlte, und eine fehlende Datei heißt unbeschränkt. ENVIRONMENT.md beschrieb origin gleichzeitig als einziges Publish-Ziel, AGENTS.md führt das Gate unter den drei in Code erzwungenen Grenzen. Eine dokumentierte Sicherung, die nicht greift, ist schlechter als eine fehlende — sie erzeugt genau das Vertrauen, das sie nicht verdient.

Die Datei ist angelegt (gitignored, per Checkout, reist nicht mit) und gegengeprüft: ein publish --remote auf ein nicht gelistetes Ziel verweigert mit Exit 42, bevor irgendetwas gestaged wird, und der Arbeitsbaum bleibt unberührt. Damit steht die Sicherung vor dem Klonen der privaten Instanz (#30) — nachträglich gesetzt ließe sie genau das Fenster offen, das sie schließt.

doctor sagt jetzt, ob das Gate scharf ist, nicht nur ob die Datei da ist. Alle drei Zustände beginnen mit Gate armed: bzw. Gate not armed:; der einzelne Remote ohne Allowlist bleibt OK (er hat nichts zu schützen, und ein FAIL machte die Datei durch die Hintertür verpflichtend), sagt aber ausdrücklich, dass jedes Push-Ziel durchkommt. Der Fall, der wirklich beißt — mehrere Remotes ohne Allowlist — bleibt WARN. Der Check hatte bislang keine Tests; drei sind dazugekommen, einer je Zustand.

Dateien: .wikitool-remotes.json (neu, nicht committet), doctor.check_publish_remotes(), tools/chemenu/tests/test_doctor.py.

2.2.2 - 2026-09-01 - Doku-Verdrahtung: Publish-Remote Gate im Werkzeugvertrag, Projektseite auf oeffentlich

Author: Torben Nehmer

Nachziehen dessen, was 2.2.0 und die Veröffentlichung offen gelassen haben. Gefunden durch eine Durchsicht auf lose Enden, nicht durch einen Fehlschlag — docs verify deckt den Fall nicht ab, weil es Kommando-Namen gegeneinander prüft, nicht ob ein neuer Fehlerfall beschrieben ist.

tools/CONTRACT.md kannte das Publish-Remote-Gate nicht. Der Werkzeugvertrag ist die Stelle, an der pro Kommando steht, was ein Fehlschlag bedeutet und ob ein Retry sicher ist — und publish hatte seit 2.2.0 einen dritten Weg zu Exit 42, der dort nirgends stand. Ergänzt in beiden Richtungen: in der Kommandozeile (URL statt Remote-Name, pushurl wird gelesen, fehlende Datei heißt unbeschränkt, kaputte Datei ist ein Fehler) und im Fehlerkontrakt, wo der entscheidende Unterschied zu den anderen beiden Gates steht — es gibt keine --confirm-Zeile, die der Agent nachreichen könnte.

instructions/gates.md verwies nicht auf die Prozedur, für die das Gate gebaut wurde. Jetzt verlinkt, mit dem Hinweis auf Schritt 4: Das Gate gehört vor den ersten publish, später hinzugefügt schützt es das Fenster nicht, das es schließen soll.

Die Projektseite beschrieb sich selbst falsch. kb/entities/projects/Chemenu.md nannte Chemenu ein „persönliches IT-Wissens-Wiki" mit dem Zweck „Persönliche IT-Wissensbasis" — seit der Veröffentlichung schlicht unzutreffend, und es ist die Seite, die ein Fremder über das Projekt liest. Neu gefasst: deterministischer Wissenskompiler, diese Instanz seit 2026-09-01 öffentlich als Testbett und Demo, Lizenz benannt.

Die historische Aussage über die monolithische AGENTS.md (~30 KB) bleibt — sie war zu ihrer Zeit korrekt und ist belegt. Sie ist jetzt als Ausgangspunkt datiert statt als Gegenwart formuliert, dieselbe Unterscheidung, die #29 für die Issue-Texte trifft: ein Pfad als Wegweiser wird nachgezogen, ein Pfad als Beleg bleibt stehen und bekommt ein Datum.

Dateien: tools/CONTRACT.md, instructions/gates.md, kb/entities/projects/Chemenu.md, kb/entities/INDEX.md (generiert).

2.2.1 - 2026-09-01 - private-instance: der Demo-Korpus wandert beim Merge doch mit - Prozedur korrigiert

Author: Torben Nehmer

instructions/private-instance.md behauptete in 2.2.0, ein git merge upstream/main löse Änderungen am Demo-Korpus stillschweigend auf, weil die private Instanz ihn einmal gelöscht hat: deleted-in-ours, unmodified-in-theirs. Das war nicht gemessen, sondern angenommen — und es ist falsch. Ein Nachbau mit einem Upstream, der seinen Korpus bewegt, zeigt drei verschiedene Verhalten:

Upstream tut	`git merge upstream/main` tut
ändert eine Seite, die du gelöscht hast	`CONFLICT (modify/delete)` — und lässt die Upstream-Fassung im Arbeitsbaum liegen. Ein `git add -A` beim Auflösen holt die Demo-Seite zurück.
legt eine neue Seite an	staged sie stillschweigend. Kein Konflikt, keine Meldung.
löscht eine Seite, die du auch gelöscht hast	nichts. Der einzige harmlose Fall.

Die mittlere Zeile ist die gefährliche, weil nichts sie ankündigt. Ein Upstream, der einen Demo-Korpus ausliefert und ihn als Testbett benutzt, legt Seiten an — und jede einzelne landet in der privaten Instanz und taucht dort in lint, index, search und confidence decay auf. Genau diese Doppelnutzung beschreibt Issue #28.

Korrigiert: Die Update-Prozedur hält den Merge mit --no-commit offen, zwingt kb/ und raw/ danach auf den eigenen Stand zurück (git rm --cached, rm -rf, git checkout HEAD --) und schließt ihn erst dann. Solange der Merge offen ist, zeigt HEAD noch auf den Commit davor, und genau das macht den Schritt sauber. Anschließend eine Kontrolle, die man nicht überlesen kann:

git diff --name-only $BEFORE HEAD -- kb raw     # muss leer sein

Das Rezept ist wörtlich so nachgespielt worden, wie es jetzt in der Datei steht — mit einem Upstream, der gleichzeitig eine Seite ändert, eine anlegt, eine löscht und dasselbe unter raw/ tut. Ergebnis: Stack aktualisiert, nur eigener Inhalt übrig, Kontrolle leer, Arbeitsbaum sauber.

Auch die Decision Points korrigiert. „Konflikt in kb/ per Hand als keep deleted auflösen" stand vorher da und ist der Rat, der in die Falle führt: git add -A committet die Fassung, die git im Arbeitsbaum liegen gelassen hat.

Dateien: instructions/private-instance.md.

2.2.0 - 2026-09-01 - Publish-Remote Gate: publish schreibt nur an erklaerte Ziele

Author: Torben Nehmer

Der Stack bekommt sein drittes Gate. Die beiden bestehenden fragen, ob eine Änderung zu groß ist und ob ein Rebase gefährlich ist. Dieses fragt, was darunter liegt: ob das überhaupt das richtige Repository ist.

Das Problem entsteht erst durch die private Instanz. Ein Checkout mit eigenem Inhalt hat typischerweise zwei Remotes — sein eigenes und das öffentliche Upstream, von dem er Stack-Updates zieht. Git unterscheidet die beim Push nicht, also legt ein falsches --remote einen privaten Korpus auf ein öffentliches Repository. Das ist nicht billig rückholbar, und zwar nachweislich: Beim Veröffentlichen dieses Repos blieb die gesamte alte History nach dem Force-Push per SHA abrufbar, bis auf dem Server die Reflogs verfielen und git gc --prune=now lief. Ein Force-Push bewegt den Branch, nicht die Objekte.

.wikitool-remotes.json nennt die erlaubten Push-URLs. Nicht die Remote-Namen: Eine Namensliste ließe ein publish durch, dessen origin umgebogen wurde, und genau das ist der Fall, den das Gate fangen soll. Gelesen wird die pushurl, wenn der Remote eine setzt, denn dorthin schreibt git push tatsächlich.

Pro Checkout und gitignored, aus demselben Grund wie ENVIRONMENT.md: Zwei Klone pushen an zwei verschiedene Orte, eine committete Kopie würde einem privaten Klon also mitteilen, das öffentliche Upstream sei ein legitimes Ziel für seinen eigenen Inhalt. Fehlt die Datei, gilt keine Beschränkung — ein Checkout mit einem Remote und ohne Privates hat nichts zu schützen, und eine Pflichtdatei würde aus einer Sicherung Papierkram machen. Eine kaputte Datei ist dagegen ein Fehler und kein „keine Beschränkung": Eine beschädigte Sicherung darf sich nicht wie eine abgeschaltete verhalten.

Kein Token, keine Flagge. Die anderen beiden Gates lösen sich mit einem --confirm <token>, weil ihre Frage („ist diese Änderung richtig?") für genau ein Changeset beantwortbar ist. Dieses fragt „gehört dieser Inhalt in jenes Repository?", und das ist eine stehende Eigenschaft des Checkouts, kein Einzelfallurteil. Der Weg daran vorbei ist ein bewusster Edit des Nutzers. Ein Agent, der die Datei anfasst, um an einer Verweigerung vorbeizukommen, öffnet ein Gate aus eigenem Antrieb — Invariante 6.

doctor meldet den Zustand statt ihn zu erzwingen: OK mit Anzahl der Ziele, OK bei Abwesenheit mit einem Remote, und WARN bei mehr als einem Remote ohne Allowlist — also genau in der Form, die eine private Instanz annimmt, sobald sie das Upstream hinzufügt.

Und die Prozedur, für die das Gate gebaut wurde. instructions/private-instance.md (neu) beschreibt die dritte Instanz-Form neben „frisch aufsetzen" und „Repo klonen": eine private Arbeitsinstanz, die Stack-Updates von einem öffentlichen Upstream per git merge zieht und deren eigener Inhalt nie zurückwandert. Der Grund, warum das dem Tarball-Weg vorzuziehen ist, steht dort ausformuliert — cp -r hat keinen Drei-Wege-Merge und keine Konflikterkennung. Schritt 4 der Anleitung ist das Gate, und zwar ausdrücklich vor dem ersten publish: später hinzugefügt schützt es das Fenster nicht, das es schließen soll.

Dateien: config.PUBLISH_REMOTES_FILENAME, git_publish.read_allowed_push_urls(), push_url_for(), publish_remote_refusal() und die Prüfung vor dem Reconcile-Schritt, doctor.check_publish_remotes(), .gitignore, instructions/gates.md, instructions/private-instance.md (neu), AGENTS.md (Gate-Liste und Bootstrap-Routing), 12 neue Tests in test_git_publish.py.

2.1.1 - 2026-09-01 - raw_dir-Fixture kappt config.ROOT; letzte private Fixture-Namen ersetzt

Author: Torben Nehmer

Der erste CI-Lauf nach der Korpus-Bereinigung wurde rot, während dieselbe Suite lokal grün blieb: test_legacy_source_pages_flags_url_and_directory scheiterte mit KeyError: 'Source - DirBacked'.

Die Ursache ist keine Testschwäche, sondern eine Umgebungsabhängigkeit. Der Test legt eine Quellenseite mit source: raw/documents an und erwartet, dass legacy_source_pages() sie als „directory, not a file" meldet. Die Prüfung dort ist (config.ROOT / legacy).is_dir() — sie löst also gegen das echte Repo-Wurzelverzeichnis auf, während die raw_dir-Fixture ihren Baum unter tmp_path baut. Der Test war nie hermetisch; er bestand, weil dieser Checkout zufällig ein raw/documents/ besaß.

Die Korpus-Bereinigung hat dieses Verzeichnis geleert. Git verfolgt keine leeren Verzeichnisse, also verschwand es im CI-Checkout und blieb im lokalen Arbeitsbaum stehen — grün hier, rot dort, ohne dass sich am Test etwas geändert hätte.

Geschlossen in der Fixture, nicht im Test. raw_dir setzt jetzt config.ROOT auf tmp_path. Das ist dieselbe Bauart und dasselbe Argument wie bei hermetic_environment (Gitea #8): Wenn eine Umgebungsabhängigkeit lokal unsichtbar ist, gehört sie an der Stelle geschlossen, die alle Tests erreicht, statt bei dem einen, der zufällig darüber stolpert. Nachgewiesen, indem raw/documents/ lokal entfernt und die Suite erneut gefahren wurde — 38 Provenance-Tests grün ohne das Verzeichnis, vorher rot.

Fixture-Namen. Die Suite benutzte weiterhin reale Systemnamen der Ursprungsinstanz als Fixture-Bezeichner. In einem öffentlichen Repo beschreiben sie nichts, verraten aber die Namensgebung einer privaten Umgebung. Ersetzt durch aurora, almanac, Borealis, gateway, docstore. gdeploy bleibt: die Seite existiert im öffentlichen Korpus.

Dateien: tools/chemenu/tests/conftest.py (raw_dir), sämtliche Testdateien mit Fixture-Namen.

2.1.0 - 2026-09-01 - Dual-Lizenz AGPL-3.0/CC-BY-4.0, und ein Leak-Canary fuer dist export

Author: Torben Nehmer

Das Repo hatte keine Lizenz. Für ein Repo, das privat auf der eigenen Gitea liegt, ist das folgenlos; für eines, das veröffentlicht werden soll, hebt es den Zweck der Veröffentlichung auf — ohne Lizenz gilt „alle Rechte vorbehalten", und niemand darf eine Instanz aufsetzen.

Zwei Hälften, zwei Lizenzen. LICENSE trägt die AGPL-3.0 und gilt für den Stack (tools/, types/); LICENSE-CONTENT trägt CC-BY-4.0 und gilt für die Inhalte (kb/, raw/, instructions/, die CONTRACT.md-Ebene, die Prosa im Wurzelverzeichnis). Die Aufteilung folgt dem Vorbild der vendorten Commonplace-Basis, kehrt aber deren Dateinamen um: Die Copyleft-Hälfte heißt LICENSE, weil das die Lizenz ist, die eine Forge für das Repository meldet — und wer eine Copyleft-Pflicht übersieht, wird dadurch geschädigt, wer eine zu viel sieht, nicht.

Die Affero-Variante statt der einfachen GPL, weil Issue #19 den Stack als MCP-Frontend erreichbar machen will. Bei der GPL schuldet nichts, wer nur einen Dienst betreibt statt Software zu verteilen; genau dieser Weg ist der, den dieses Projekt einschlägt.

Die Grenze wird nicht aufgeschrieben. Welche Datei zu welcher Hälfte gehört, ist der Dateiplan, den dist export ohnehin berechnet. NOTICE verweist darauf, statt eine zweite Pfadliste anzulegen, die drifted (Invariante 8). NOTICE trägt außerdem die Attribution für commonplace (zby, CC-BY-4.0 Inhalte + MIT Code), die CC-BY verlangt.

dist export liefert die Lizenzen mit — und weigert sich sonst. Die drei Dateien stehen jetzt in ROOT_FILES, aber nicht nur dort: REQUIRED_ROOT_FILES macht sie zur Bedingung. Jeder andere ROOT_FILES-Eintrag wird if source.is_file() kopiert und sonst stillschweigend übersprungen — richtig für INSTALL.md, das es lange nicht gab, und falsch für eine Lizenz: Ein Export, der sie weglässt, übergibt einen AGPL-tools/-Baum ohne Lizenztext, und das ist eine Verletzung, sobald die empfangende Instanz irgendwo öffentlich landet.

Der Leak-Canary. find_leaks() prüft den fertigen Plan gegen das, was er nie enthalten darf: eine ausgefüllte USER.md/SOUL.md/ENVIRONMENT.md, etwas unter instructions/dev/, eine kb/-Seite oder eine raw/-Quelle. Drei getrennte Allowlists entscheiden bisher, was build_plan kopiert, und jede hält nur, solange sich beim Editieren jemand an die Regel erinnert hat — nichts prüfte das Ergebnis nach. export bricht jetzt ab, wenn der Plan etwas davon trägt, mit dem Hinweis, die Allowlist zu reparieren statt Dateien aus dem Ziel zu löschen.

Die Prüfung ist bewusst strukturell und nicht textbasiert. Ein Muster-Scan auf Hostnamen oder IP-Literale wurde erwogen und verworfen: Der eigene Host steht legitim in INSTALL.md und version.py, ein solcher Scan müsste also genau die Zeichenkette ausnehmen, nach der er sucht — oder bei jedem Export Fehlalarm geben.

Beispiele neutralisiert. Hilfetexte, Docstrings und Contract-Beispiele nannten reale Quellenseiten und Pfade der Ursprungsinstanz. In einer Distribution ist das nicht nur unpassend, sondern verrät den Inhalt der Instanz, die sie gebaut hat. Ersetzt durch Beispiele aus dem verbleibenden öffentlichen Korpus.

Dateien: LICENSE, LICENSE-CONTENT, NOTICE (neu), config.LICENSE_FILES, dist_cmd.REQUIRED_ROOT_FILES, dist_cmd.find_leaks(), Lizenzabschnitt in README.md, sechs neue Tests in test_dist_cmd.py; Beispiel-Neutralisierung in cite_cmd.py, page_ops.py, work_cmd.py, provenance.py, search/ripgrep.py, work/CONTRACT.md, instructions/session-setup.md und zwei Testdateien.

2.0.0 - 2026-09-01 - Rebranding zu Chemenu: Repo, Produktname und Python-Paket

Author: Torben Nehmer

Migration: none required - Der Bruch liegt im Update-Pfad und im Import-Namen, nicht im Korpus: kb/ behaelt Schema und Shape 1.0.0, keine Seite und kein Frontmatter-Feld aendert sich. Was eine bestehende Instanz tun muss, steht im Eintrag - Release-Feed umstellen, Paketimport nachziehen -, und beides ist Instanz-Konfiguration, keine Inhaltsmigration.

Der Stack hieß llm-wiki-test1, und das war nie ein Name, sondern ein Platzhalter mit einer Ordnungszahl darin. Gitea-Issue #3 setzt Chemenu an seine Stelle - der altägyptische Name von Hermopolis Magna, Hauptkultort des Thoth und „Stadt der Acht" der Ogdoade. Der Ort, nicht der Gott: die Persona heißt weiterhin Thoth, und der Stack ist das, worin sie schreibt.

Was den Namen trägt. Repo (torben/chemenu), Produktname in README.md, AGENTS.md, .gitignore, types/type-spec.md und tools/CONTRACT.md, das Release-Artefakt (chemenu-stack-<version>.tar.gz statt llm-wiki-stack-…), der Release-Feed in version.DEFAULT_UPDATE_URL, und die Download- und Issue-URLs in INSTALL.md und instructions/dev/issue-tracking.md. Die eine Nennung von „LLM Wiki", die stehen bleibt, ist die Attribution an Karpathys ursprüngliches Gist in README.md - das ist die Herkunft der Idee, nicht der Name dieses Stacks.

Das Python-Paket heißt jetzt chemenu, nicht mehr wiki_tools. Der Import-Name eines Pakets ist ein flacher globaler Namensraum ohne Kollisionsschutz, und wiki_tools ist genau die Sorte generischer Name, die dort nichts verloren hat - unabhängig davon, ob je etwas veröffentlicht wird, denn es reicht, dass ein zweites wiki_tools auf demselben sys.path liegt. Betroffen sind 93 Dateien unter tools/chemenu/ plus pytest.ini, .coveragerc, der tools/wikitool-Shim und die Pfadangaben in EVALS.md, instructions/dev/, types/*.md und kb/CONTRACT.md. dist_cmd.py brauchte nichts: es läuft tools/ als Baum ab und nennt das Paket nirgends beim Namen.

Das Kommando bleibt wikitool, und mit ihm .wikitool-release.json, .wikitool-kb.json und die WIKITOOL_*-Variablen. Distributionsname, Import-Name und Kommandoname sind drei unabhängige Dinge, und ein abweichender Kommandoname ist verbreitete Praxis (httpie → http). Was der Stack nach außen anbietet, heißt weiter so, wie es tut, was es tut.

Warum das trotzdem MAJOR ist. Der erste Anlauf stand auf 1.9.0, mit dem Argument, dass kein Inhalt migriert werden muss. Das beantwortet die falsche Frage. Drei Dinge brechen:

Die Update-Erkennung selbst. Jede bereits exportierte Instanz trägt in .wikitool-release.json ein update_url auf .../repos/torben/llm-wiki-test1/releases/latest. Nach dem Repo-Rename antwortet Gitea dort bestenfalls per Redirect, schlimmstenfalls mit 404 - und ein 404 ist von „kein Release vorhanden" nicht zu unterscheiden, wie INSTALL.md § Konfiguration für den Token-Fall bereits festhält. Die Instanz kann sich nicht selbst reparieren: der Stempel ist maschinengeschrieben, Invariante 1 verbietet den Hand-Edit. Es bricht also ausgerechnet der Kanal, über den eine Instanz erführe, dass sie etwas zu tun hat. Der Ausweg ist WIKITOOL_UPDATE_URL auf den neuen Feed zu setzen, oder ein frischer dist export.
Der Artefaktname. llm-wiki-stack-<version>.tar.gz heißt jetzt chemenu-stack-<version>.tar.gz - jedes Download-Skript und jeder Pin darauf bricht.
Der Import-Name. from wiki_tools import … außerhalb des ausgelieferten Baums bricht.

Keiner dieser drei Punkte verlangt, dass eine Seite in kb/ angefasst wird - deshalb --no-migration statt eines Migrationsdokuments. Aber rückwärtskompatibel ist das nicht, und 1.9.0 hätte genau das behauptet.

SOUL.md.template schlägt jetzt einen Persona-Namen vor. Bisher stand dort ausdrücklich, dass der Stack keinen vorschlägt; ab jetzt nennt er Thoth als Startpunkt, mit der Begründung, die der neue Repo-Name mitbringt. Die Regel dahinter ändert sich nicht: gefragt wird trotzdem, und ein anderer Name gewinnt. Weil das eine bestehende Regel verschiebt, steht sie gleichlautend an allen drei Stellen, die sie führen - SOUL.md.template, Schritt 6 in instructions/setup-instance.md, und SOUL.md dieser Instanz.

Was den alten Namen behält: CHANGES.md, kb/log.md, kb/provenance.md, die Prosa unter kb/sources/ und alles unter raw/. Das sind abgeschlossene Aufzeichnungen dessen, was einmal galt - sie umzuschreiben hieße, die eigene Historie zu fälschen, und raw/ ist ohnehin unveränderlich.

1.8.1 - 2026-08-31 - Coverage-Reporting in CI: messen und als Artefakt ausweisen, ohne Schwelle

Author: Torben Nehmer

729 Tests liefen in CI, und wie viel vom Stack sie erreichen, wusste niemand - Coverage war nie gemessen (Gitea #10). Der Verdacht war nicht theoretisch: Run 52 hatte zwei Tests gefunden, die grün waren, weil die Umgebung zufällig passte. Was gar nicht ausgeführt wird, fällt leichter durch.

Gemessen wird jetzt, entschieden wird später. Der CI-Schritt „Tests" läuft mit --cov --cov-report=term --cov-report=xml --cov-report=html, ein neuer Schritt lädt XML und HTML als Artefakt coverage-<run id> hoch (upload-artifact@v3, nicht v4 - v4 ist auf dieser Gitea-Instanz eingeschränkt). Der Upload steht unter if: always(): eine rote Suite ist genau der Moment, in dem die Zahlen pro Modul interessant sind.

Kein --cov-fail-under, bewusst. Eine Schwelle vor der Zahl hat zwei Ausgänge, beide schlecht: sie liegt zu tief und wirkt nicht, oder sie liegt zu hoch und der nächste ehrliche Commit wird rot - worauf jemand die Schwelle senkt statt Tests zu schreiben. Sie kommt in einem eigenen, späteren Commit, mit der gemessenen Zahl als Begründung, und friert den erreichten Stand ein, statt ihn schönzurechnen.

Erste Messung: 86.9 % von 5105 Statements, 730 Tests (2026-08-31, CI-Lauf 87). Festgehalten in EVALS.md § „How much of the stack the suite reaches", zusammen mit der Leseanleitung - denn der Gesamtwert ist die uninteressanteste Größe. Der Bericht trennt drei Fälle, die verschieden zu behandeln sind: dünne Typer-Wrapper (eval_cmd.py 36 %, types_cmd.py 52 %, cli.py 52 %), bei denen niedrige Zahlen ein guter Schnitt sind und kein fehlender Test; Code mit einer injizierbaren Außengrenze (version.py's fetch_latest()), wo die echte Netzzeile absichtlich ungetestet bleibt; und echte Lücken (provenance_cmd.py 44 %, migrate_cmd.py 71 %, type_resolver.py 79 %). Nur die dritte Liste ist Arbeit.

pytest-cov steht nicht in tools/requirements.txt: die Datei beschreibt die Laufzeitabhängigkeiten einer Instanz und wird von dist export mitgeliefert, und eine Instanz misst diese Suite nicht. CI installiert es neben pytest. Die Konfiguration liegt in tools/.coveragerc statt in pytest.ini - coverage.py liest .coveragerc, setup.cfg, tox.ini und pyproject.toml, aber kein pytest.ini, wo ein [coverage:*]-Abschnitt still ignoriert würde. Gemessen wird wiki_tools/ ohne wiki_tools/tests/. Die Messung hängt ausdrücklich nicht in addopts: das würde den nackten pytest -q überall dort brechen, wo pytest-cov fehlt.

.gitignore und die Kanarienvögel in docs verify decken die Ausgabe mit ab (tools/.coverage, tools/coverage.xml, tools/htmlcov/) - abgeleitet wie reports/, und publish läuft mit git add -A, also hätte ein unignorierter htmlcov/-Baum sich beim nächsten Content-Publish selbst mitcommittet.

Dabei gefunden und mitbehoben: dist export hat die Coverage-Ausgabe mit ausgeliefert. Der erste Export nach der Messung trug 227 statt 162 Dateien, darunter den kompletten htmlcov/-Baum - eine Messung dieses Repos, ausgeliefert in fremde Instanzen. Der Grund war struktureller Natur: TOOLS_EXCLUDE_DIRS prunet Verzeichnisse, aber zwei Drittel der Coverage-Ausgabe (.coverage, coverage.xml, unter Parallelläufen .coverage.<host>.<pid>) liegen als Dateien neben dem Code. _copy_tree nimmt jetzt zusätzlich ein Dateinamen-Prädikat; htmlcov/ kam in die Verzeichnisliste. .coveragerc geht weiter mit - Konfiguration ist Maschinerie, wie pytest.ini. Damit hat der Kopierplan drei Ausschlussmechanismen statt zwei, für drei verschiedene Gründe: dev-only Inhalt (Marker), dev-only Dateien (instructions/dev/), abgeleitete Ausgabe (Build-Artefakte).

1.8.0 - 2026-08-31 - ENVIRONMENT.md: optionale, checkout-spezifische Umgebungsnotiz

Author: Torben Nehmer

Welches Harness läuft hier, welche MCP-Server sind erreichbar, wohin veröffentlicht publish, wo läuft CI? Werte, die sich über Wochen nicht ändern und die trotzdem jede Session neu erfragt hat, weil nichts sie festhielt. USER.md beantwortet, wer die Instanz bedient, SOUL.md, wie sie klingt - womit sie arbeitet, beantwortete bisher niemand (Gitea #24).

ENVIRONMENT.md schließt die Lücke, als drittes Root-Dokument der Session-Ebene. Es hält Harness, publizierte Skills, MCP-Server, Connectoren, Git-Remotes und den CI-Ort fest; ENVIRONMENT.md.template gibt die Abschnitte vor. Claude Code importiert es über CLAUDE.md, AGENTS.md trägt es in der Namenstabelle und in einem eigenen Abschnitt für die übrigen Harnesses.

Drei Eigenschaften unterscheiden es von der Personalization Plane, und alle drei sind Absicht:

Optional. Fehlt die Datei, ist das ein gültiger Endzustand, kein Mangel - doctor meldet environment: absent (optional) und niemals FAIL. Ein FAIL hätte die Datei durch die Hintertür verpflichtend gemacht; der Preis ihres Fehlens sind ein paar Fragen, keine falsche Ausgabe. Gemeldet wird genau ein Fall, und zwar als WARN: ein umbenanntes, nie ausgefülltes Template, das in jeder Session mitgeladen wird und nichts beantwortet. Der Sentinel wikitool:template-unfilled ist derselbe wie bei USER.md/SOUL.md.

Gitignored statt committet. Zwei Clones desselben Repos sind zwei verschiedene Umgebungen. Eine committete Fassung würde dem zweiten Clone Antworten geben, die falsch sind statt zu fehlen - und falsch ist hier schlimmer, weil die Datei geglaubt wird. docs verify prüft beide Hälften des Musters: ENVIRONMENT.md muss ignoriert sein, ENVIRONMENT.md.template darf es nicht sein. Das nachlässige ENVIRONMENT.md* würde beide schlucken, und genau das fängt der Kanarienvogel ab.

Kontext, keine Autorität. Die Datei beschreibt, was da ist, nicht, was erlaubt ist. Ein dort gelisteter Remote autorisiert kein git push - Invariante 5 führt weiter über wikitool publish -, ein gelisteter MCP-Server öffnet kein Gate, und nichts darin ist eine Quelle im Sinne von Invariante 3. Geheimnisse gehören nicht hinein: die Datei liegt im Klartext im Arbeitsverzeichnis und in jedem Agenten-Kontext.

Warum ein Import in CLAUDE.md und kein Link: Was hier steht, wird nebenbei gebraucht - beim Griff zum richtigen MCP-Server, mitten in einer Aufgabe -, nicht an einer Stelle, an der jemand ein Dokument aufschlägt. Das ist derselbe Maßstab, den die Modellwahl-Instruktion erfüllt, und er ist zugleich der Test: Eine Session, die erst nachschlagen müsste, fragt stattdessen wieder den Nutzer - genau die Kosten, die die Datei beseitigt. Dass ein unaufgelöster Import folgenlos bleibt, war schon vor der Personalization-Einführung so; hier wird es zum Dauerzustand statt zum Übergang.

Angelegt wird die Datei in bootstrap.md (neuer Schritt 5, für einen Clone) und in setup-instance.md (neuer Schritt 9, für eine frische Instanz). Beide Male gilt: eintragen, was aus dem Checkout ablesbar ist, einmal nach dem Rest fragen, "weiß ich nicht" als Antwort akzeptieren - und einen leeren Abschnitt löschen statt ihn mit Plausiblem zu füllen. Eine geratene Zeile ist schlechter als eine fehlende.

1.7.2 - 2026-08-31 - lint liest Code nicht mehr als Wiki-Notation; Zitat-Limit zählt Zitate statt Zeilen

Author: Torben Nehmer

Two lint rules were measuring something other than what they claim to. Both are found the same way - by a page that describes the stack rather than using it - and both are hard enough to be worth a release of their own.

lint read wiki notation inside code as the real thing (Gitea #20). CITE_REF_RE, CITE_DEF_RE, LEGACY_CITE_RE and WIKILINK_RE are plain text matches with no idea what a Markdown code span is, so a page writing `[^cite-id]` in backticks, or showing a definition line in a fenced block, produced Undefined Footnote References - and that is a hard error, so lint --fail-on-error and CI went red. It happened at the 2026-08-31 ingest (c28f8ce), on concept pages about the citation mechanism itself. The way out that session was to write about the notation without writing it ("Zitatdefinitionszeile" instead of the marker), which is invisible to whoever reads the page later. A knowledge base about a stack has to be able to quote that stack's notation.

The new wiki_tools/markdown_code.py holds that rule once: strip_code_spans() replaces fenced blocks and inline code spans with spaces of the same length, so offsets survive and a caller may match the masked text and slice the original. Every scan now goes through it - provenance.iter_cite_refs() for references, split_cite_block() for definitions, legacy_citation_markers(), and kb_scan.extract_wikilinks()/count_wikilinks() for the link graph, where the identical blindness made a fenced example link a broken one. Teaching each regex its own context logic would have been six copies of one rule.

Two boundaries are drawn deliberately, and both are asserted in tests/test_markdown_code.py. Indented code blocks are not masked: in this corpus a four-space indent is a nested list continuation far more often than it is code, and masking by indentation would have silently deleted real links from the graph. Inline spans are matched within one line: an unclosed backtick is a common typo, and a matcher that crosses newlines turns one typo into a masked paragraph - a failure that hides findings rather than inventing them, which is the direction that goes unnoticed. For the same reason split_cite_block() still locates the Footnotes heading on the unmasked body: one unclosed fence would otherwise blank the heading and leave the page with no definitions at all.

The corpus had the mirror-image habit. 12 [^s-…] markers sat inside fenced blocks, appended to a command or a YAML line, across four pages. They never rendered as footnotes - GFM shows them literally, so copying the command copied the marker with it - and masking turned two of them into orphan definitions. They now sit on a Quelle: [^s-…] line under their block: vier Infrastruktur- und Konzeptseiten.

The quote limit counted > lines, not quotes (Gitea #22). The rule is about how much borrowed wording a page carries; the line count measured the wrap width instead, so one quotation counted 1 written long and 4 wrapped at the width the rest of the repo keeps. An author who took the finding seriously made the page harder to read to quiet it - and it fired on a page with exactly one quotation while verifying 1.7.1. count_quote_blocks() now counts runs of consecutive quoted lines, with code masked out first so a > in a shell transcript is a prompt rather than a quotation. QUOTE_LIMIT stays at 2 and finally means what its name already claimed.

Alongside the release, .gitea/workflows/nightly.yml runs doctor, docs verify, instructions verify, lint --fail-on-error, sources coverage and migrate status on a schedule (Gitea #9). It closes the gap ci.yml's content paths-ignore opened: since that landed, structural lint no longer runs when the corpus changes. Workflows are outside the version gate, so this needed no bump of its own.

1.7.1 - 2026-08-31 - Testsuite gegen stille Umgebungsabhängigkeiten gehärtet

Author: Claude Code

The suite was green for months on every developer machine while silently reading the machine it ran on. config.default_author() shells out to git config user.name with cwd=config.ROOT; the fixture root is not a repository, so the answer came from the global git configuration of whoever started pytest. The first CI run that ever reached pytest (run 52) had none, and two tests fell over with ERROR No author configured for this instance. Both were repaired in 1.0.1 - and in 1.2.0 two new tests reintroduced exactly the same dependency, written by someone who had read the issue first (Gitea #8). Patching cases one at a time loses to the rate at which the suite acquires them.

tools/wiki_tools/tests/conftest.py now carries an autouse hermetic_environment fixture next to isolated_trace_dir. Before every test it points HOME (and XDG_CONFIG_HOME) into that test's own tmp_path, sets GIT_CONFIG_GLOBAL and GIT_CONFIG_SYSTEM to /dev/null, and clears both git's identity/location variables (GIT_DIR, GIT_WORK_TREE, GIT_AUTHOR_*, GIT_COMMITTER_*, EMAIL) and the tool's own (WIKI_AUTHOR, WIKI_TRACE, WIKI_TRACE_CONTENT, WIKI_TRACE_MAX_CONTENT, WIKITOOL_SESSION_ID, WIKITOOL_UPDATE_URL, WIKITOOL_UPDATE_TOKEN). A test can no longer acquire the dependency at all: it either establishes an identity itself or the tool refuses, on the author's machine and in CI alike.

WIKI_TRACE_DIR is deliberately the one variable left set - isolated_trace_dir redirects it per test, and now declares hermetic_environment as a dependency so the ordering between the two autouse fixtures is stated rather than inherited from declaration order. Tracing is never disabled suite-wide; two telemetry tests assert that a trace is written.

No identity is set for everyone. A shared default in conftest.py would have been the cheaper fix and the wrong one: default_author()'s None branch only exists on a machine that knows nobody, so a suite-wide WIKI_AUTHOR would have made the fallback untestable while looking green. Instead the new test_hermetic_env.py asserts the fixture itself - the cleared variables, the empty HOME, that git config user.name answers nothing, that tracing stays on and redirected - and covers all three branches of default_author(), including the one the fixture makes writable for the first time. test_new_source_fails_hard_without_any_author keeps patching default_author directly, so it stays a test of the CLI's error path rather than of the environment.

Verified in three environments that now agree exactly - the developer shell, a deliberately poisoned one (WIKI_AUTHOR, WIKI_TRACE=0, WIKITOOL_* and GIT_* all set to junk), and env -i with an empty HOME and no git configuration: 702 passed in each. Before this change the third of those was the one that failed.

CI keeps running the suite once. A second hardened pytest step was the issue's fallback proposal; it is redundant now and would report the dependency only after a push. The Tests step in .gitea/workflows/ci.yml says so, so nobody adds it back for the reason it was once needed.

Added instructions/dev/testing-conventions.md - what the fixture neutralizes, how a test establishes an author when it needs one, and the env -i counter-check to run before publishing a test change. Linked from the stack-dev skill's step 2, which until now pointed at "the existing test files' own patterns" for exactly this. Also pins the fixture repo in test_new_source_author_falls_back_to_git_config to git init -q -b main: without a global configuration git emits an init.defaultBranch advisory that clutters unrelated failures.

No command changes behaviour, so this is a PATCH.

1.7.0 - 2026-08-31 - CLAUDE.md as a harness-scoped instruction reference; Claude-Code model-selection guidance

Author: Claude Code

tools/wikitool instructions verify only ever recognized AGENTS.md as an automatically-loaded reference source for instructions/*.md - accurate for every other harness (Codex CLI, GitHub Copilot CLI, Mistral Vibe read AGENTS.md natively), but not for Claude Code, which loads CLAUDE.md instead and does not read AGENTS.md on its own. A Claude-Code-only instruction therefore had no valid place to be linked from: linking it from AGENTS.md would load it into every other harness's session too.

CLAUDE.md is now a second recognized reference/auto-load source alongside AGENTS.md, scoped the same way: instructions_cmd.AGENT_ROOT_FILES and automatic_load_paths() both include it, manual: true instructions are forbidden from being linked there for the same reason they are forbidden from AGENTS.md, and instructions/CONTRACT.md's reference-tier table documents the split. AGENTS.md and CLAUDE.md are deliberately kept as two names, not folded into one "automatically loaded" concept, because they are automatic for disjoint sets of harnesses.

A mention in README.md or CHANGES.md no longer counts as a reference. Both were in the old REFERENCE_GLOBS, so an instruction whose only mention was in one of them passed verify's "nothing references it - it deploys to no one" check while being unreachable by any agent - AGENTS.md's own file-naming table defines README.md as "never by an agent as instruction", and CHANGES.md is not even shipped (dist export replaces it wholesale). The tuple is now split by what the two callers actually ask: AGENT_ROOT_FILES for "can an agent reach this", AGENT_ROOT_FILES + SHIPPED_DOC_ROOT_FILES for the instructions/dev/ boundary check, which still scans README.md because a dangling path in a shipped document is a defect regardless of who reads it. Nothing in the tree relied on the old behaviour - verify stays green - so this closes a latent false green rather than fixing a live break. It also means this entry's own mention of the new instruction below no longer masks a broken CLAUDE.md link.

Added instructions/claude-code-model-selection.md, @-imported by CLAUDE.md as its fourth import: which model (Sonnet vs. Opus) and effort level to run a session, a spawned subagent, or a /code-review pass at, keyed to the skill or task at hand rather than defaulting everything to the most capable model at the highest effort.

Imported, not linked - the choice matters enough that instructions/CONTRACT.md now documents both forms and when each applies. Model and effort are decided while spawning a subagent or starting a review, not at a point where anyone stops to open a document, so a link would be followed only when the user explicitly asked about models. The price is standing context in every Claude Code session: an import is the strongest load in this layer, stronger than a skill (which contributes only its description), and that is the bar each further Claude-Code-only import has to clear. verify accepts either form - both put the filename in CLAUDE.md.

Deliberately out of scope, tracked as a follow-up issue instead: equivalent model-selection guidance for the non-Claude-Code harnesses this repo supports. Those harnesses have no equivalent of Claude Code's model names, /code-review effort dial, or Agent tool model: override, so the question of whether and how they should decide this differently is a separate design decision, not answered here.

1.6.0 - 2026-08-31 - xref link-source schreibt beide Richtungen; xref add lehnt undeklarierte Ref-Felder ab

Author: Torben Nehmer

Schließt Gitea-Issue #18. Drei Defekte mit einer Ursache, und ein Loch in einer Entscheidung aus 1.4.0 desselben Tages: die Sperrliste in touch --set lehnt Page-Ref-Felder mit dem Verweis auf xref ab — für die entities:/concepts: einer Source-Seite konnte xref das aber nicht. Der Verweis zeigte ins Leere.

`xref link-source` schreibt jetzt beide Richtungen

Bisher schrieb es nur die Zielseiten (sources: + See-Also-Bullet) und rührte die Arrays der Source-Seite nie an — es prüfte nur, dass sie existiert. Ein Ingest legt die Source-Seite aber an, bevor die Concept-Seiten existieren, weil deren Titel erst beim Extrahieren feststehen. Also blieb concepts: [], und kein Kommando konnte es füllen.

Welches der beiden Felder ein Ziel bekommt, folgt seiner Collection: kb/entities/ → entities:, kb/concepts/ → concepts:. Das Verzeichnis ist der Feldname, also braucht eine neue Collection hier keine Code-Änderung — sie braucht einen Typ, der das passende Feld deklariert. Ein Ziel, dessen Collection zu keinem deklarierten Feld passt, wird einseitig verlinkt und in der Ausgabe benannt statt stillschweigend übergangen.

`xref add` lehnt ein nicht deklariertes `related:` ab

add_related() schrieb das Feld bedingungslos. Auf einer Source-Seite — page_ref_fields: [entities, concepts] — erzeugte das Frontmatter, das das Schema verwirft (additionalProperties: false). Genau so entstand der einzige Schema-Fehler, der heute auf main lag.

Die Prüfung läuft für beide Seiten, bevor eine davon geschrieben wird: eine Ablehnung darf keinen halben Link hinterlassen. Die Meldung nennt die Felder, die der Typ kennt, und das Kommando, das sie füllt.

`xref remove` räumt auch undeklarierte Reste

strip_frontmatter_ref() lief nur über die vom Typ deklarierten Felder. Ein related: auf einer Source-Seite war damit nicht entfernbar — ein Kommando erzeugte einen Zustand, den ein anderes nicht rückgängig machen konnte, obwohl sein Contract-Eintrag ausdrücklich verspricht, hinterlassene Referenzen ohne Handeditierung zu klären.

Gesweept wird jetzt zusätzlich jedes auf der Seite vorhandene Feld, das irgendein Typ als Ref-Feld deklariert — die Namen kommen aus den Type-Specs, nicht aus einer Konstante. Ein undeklariertes Feld, das dabei leer wird, fällt ganz weg statt als related: [] stehenzubleiben: der Schlüssel war für diesen Typ nie gültig, und ein leeres Array hielte die Seite weiter schemawidrig.

Das gilt damit auch für rename und rm, die denselben Helfer benutzen.

Bestandsfall repariert, mit dem Werkzeug

Die Seite auf main trug related: [Write-Once Frontmatter Fields] und ein leeres concepts:. xref remove hat den Rest geräumt, xref link-source hat beide Concepts in beide Richtungen eingetragen. lint meldet keinen Schema-Fehler mehr. Kein rm --yes, keine Handeditierung.

Sonst

Die Ablehnungsmeldungen der Sperrliste in touch --set nennen jetzt für entities:/concepts:/sources: konkret xref link-source statt pauschal xref add/xref remove — der bisherige Verweis war für genau diese Felder falsch.

Sechs neue Tests in test_xref.py, darunter der, dass eine Ablehnung keine Seite anfasst, und die Idempotenz der neuen Richtung.

1.5.1 - 2026-08-31 - cite add/sync und rename loeschen keinen Inhalt mehr hinter dem Fussnoten-Block

Author: Torben Nehmer

Schließt Gitea-Issue #17. Der bisher einzige bekannte Weg, auf dem dieser Stack Inhalt verliert statt ihn falsch zu schreiben.

split_cite_block() nahm alles ab der Überschrift ## Fußnoten bis zum Dateiende als Zitatblock, behielt daraus nur die [^id]:-Zeilen, und jeder Aufrufer setzt eine Seite als Kopf + neu gerenderter Block wieder zusammen. Stand hinter dem Block noch ein Abschnitt, war er nach dem nächsten Aufruf weg — ohne Warnung, mit Erfolgsmeldung. Betroffen waren cite add, cite sync und rename, die alle denselben Pfad benutzen.

Systematisch wurde es durch einen Widerspruch zwischen zwei Kommandos: xref add hängt ## Beziehungen und ## Siehe auch ans Dateiende, cite add hielt den Fußnoten-Block für das Dateiende. Wer cite add zuerst laufen ließ, war sicher; wer die Reihenfolge umdrehte, verlor beim nächsten Zitat alle Querverweise. Keiner der Skills schreibt die Reihenfolge vor, es war also Zufall.

Gefunden beim Ingest vom 2026-08-31 (8524bce), wo kb/concepts/Detect-Repair Asymmetry.md vier ## Beziehungen- und fünf ## Siehe auch-Einträge verlor. Dass es auffiel, war Glück: der ausführende Agent hatte nach cite add zurückgelesen.

Der Fix

Der Block endet jetzt an der nächsten Überschrift statt am Dateiende. Alles dahinter — und alles im Block, was keine Zitatdefinition ist — wird auf den Kopf zurückgefaltet statt verworfen. Der Rückgabetyp bleibt gleich, alle sechs Aufrufer profitieren ohne Änderung.

Zwei Eigenschaften, die dabei mehr wert sind als die reine Reparatur:

Die Seite heilt sich selbst. Weil der gerenderte Block immer zuletzt ausgegeben wird, bringt die erste Zitatoperation eine bereits verrutschte Seite wieder in die richtige Form. xref add darf weiterhin ans Dateiende anhängen, ohne Schaden anzurichten.
Loser Text im Block wird gerettet, nicht abgelehnt. Ein Abbruch wäre die naheliegende Härtung gewesen, ist hier aber falsch: derselbe Pfad läuft unter lint und corpus_diff, wo eine Exception das Lesen einer Seite verweigern würde, statt sie zu melden.

Nebenbei behoben: ein [^id], das nur in einem Abschnitt hinter dem Block referenziert wurde, galt für extract_inline_cites als nicht referenziert — und cite sync hätte seine Definition als verwaist entfernt.

Korpus repariert

Acht Seiten trugen zusammen 74 Zeilen in der gefährdeten Position. cite sync --all hat sie normalisiert (elf Seiten insgesamt; drei brauchten nur eine Neusortierung). Nachgemessen: 0 Seiten mit Inhalt hinter dem Block, und je Seite unveränderte Zahl an Zitatdefinitionen und Bullets.

Tests

Fünf neue in test_provenance.py, darunter der Fall, der zuerst rot sein muss (Abschnitt hinter dem Block überlebt den Rundlauf), die Stabilität wiederholter Rundläufe, und ein Zitat, das nur im geretteten Abschnitt referenziert wird.

Bemerkenswert: vor diesen Tests liefen alle 678 grün. Das alte, zerstörende Verhalten war von keinem Test festgehalten — so hat es überlebt.

1.5.0 - 2026-08-31 - Mass-Update Gate zaehlt generierte Dateien nicht mehr; Kalibrierungsband gemessen statt geerbt

Author: Torben Nehmer

Zwei Kalibrierungen, beide aus derselben Beobachtung: drei gewöhnliche Ingests hintereinander blieben am Mass-Update Gate stehen. Keiner war ein Massen-Update. Das Gate feuerte auf Rauschen, und die Budget-Richtwerte beschrieben eine Arbeit, die es so nicht gibt.

Generierte Dateien zählen nicht mehr gegen die Schwelle

kb/index.md, kb/log.md, kb/provenance.md und jede INDEX.md werden committet und gepusht wie bisher, aber vom Gate nicht mehr gezählt und nicht mehr zur Freigabe vorgelegt. Der Grund ist derselbe, aus dem work/ schon ausgenommen war: sie tragen keine Entscheidung. Jede davon ist per index rebuild / sources rebuild-index aus dem Baum reproduzierbar, also entscheidet ihre Freigabe nichts — sie erzeugt nur Review-Müdigkeit, gegen die die Schwelle eigentlich gerichtet ist.

Ein gewöhnlicher Ingest baut fünf bis sechs davon neu. Gemessen an den drei Changesets vom 2026-08-31:

Ingest	Dateien	vorher gezählt	jetzt gezählt
Comma Bug	14	14 → Gate	9 → läuft durch
Issue Triage	16	16 → Gate	9 → läuft durch
Auto Mode	11	11 → Gate	5 → läuft durch

Das Gate bleibt scharf: zehn echte Seiten lösen es weiterhin aus, egal wie viel Index-Rauschen mitfährt. Ein Test hält genau das fest.

Die Ablehnungszeile weist beide Ausnahmegründe getrennt aus („3 under work/ and 5 generated by wikitool committed but not counted"), weil ein Prüfer, der „9 counted" an einem 14-Datei-Commit sieht, sonst die Differenz für einen Fehler hält. Und weil Kratzzustand und abgeleitete Ausgabe nicht dasselbe sind.

Der --confirm-Token deckt jetzt genau das ab, was ein Mensch tatsächlich gelesen hat: eine neu gebaute INDEX.md macht eine erteilte Freigabe nicht mehr ungültig.

Kalibrierungsband: 15-25 → 20-35 für komplexe Workflows

Das obere Band stammte aus einer Branchen-Faustregel. Vier reale Ingests messen 24, 26, 29 und 30 Aufrufe — jeder einzelne am oberen Rand oder darüber, ohne dass etwas Ungewöhnliches passiert wäre. Ein Richtwert, den der Normalfall überschreitet, ist keiner; er bringt einem Agenten bei, dass die Zahlen Dekoration sind.

Neu: ~5-15 für eine einfache Aufgabe (gemessen 5-9), ~20-35 für einen komplexen Multi-Tool-Workflow. Nachgezogen in run_budget.py, instructions/gates.md und den Skills wiki-ingest und wiki-lint. Die Obergrenze von 60 bleibt unverändert — sie ist kein Ziel, sondern der Punkt, ab dem eine Sitzung als festgefahren gilt.

gates.md sagt jetzt auch, woher die Zahl kommt und wie man sie neu misst: tools/.wikitool_session/budget.json hält die Aufrufzahlen je Session. Ein Richtwert ohne Messverfahren veraltet lautlos.

Die zitierte Branchen-Faustregel in kb/concepts/Iteration and Cost Limits.md bleibt unangetastet — sie ist eine belegte Aussage über den Stand der Technik, nicht über diese Instanz. Was diese Instanz misst, ist eine andere Behauptung und gehört beim nächsten Ingest dieser Sitzung dort ergänzt.

1.4.0 - 2026-08-31 - touch --set/--add/--remove: Frontmatter-Felder nach dem Anlegen korrigierbar

Author: Torben Nehmer

Schließt Gitea-Issue #14. Ein Feld, das new einmal schrieb - tags:, raw_files:, source_url: - war danach unerreichbar: touch kannte es nicht, Frontmatter von Hand zu editieren ist das, was dieses Werkzeug verhindern soll, und die Seite zu löschen und neu anzulegen bricht jede Referenz, die schon auf sie zeigt. Da new nicht idempotent ist, war das Fenster, es richtig zu treffen, genau ein Kommando breit.

Drei Fehlschläge in drei aufeinanderfolgenden Ingests am 2026-08-31, an zwei Feldern, von drei verschiedenen Agenten - einer davon wegen eines Kommas am Ende eines --set tags=-Werts. Das ist keine Ausrutscherquote, sondern die Fehlerrate einer Schnittstelle, die einen Wert genau einmal entgegennimmt.

Neu an `touch`

--set field=value ersetzt den Wert auf der Platte. Wiederholtes --set für dasselbe Arrayfeld hängt innerhalb eines Aufrufs an, \, ist ein literales Komma - dieselben Regeln wie bei new --set (1.2.0).
--add / --remove ändern einzelne Elemente eines Arrayfelds, ohne dass man die bestehende Liste kennen muss. --add ist idempotent. --remove auf ein nicht vorhandenes Element gelingt und sagt es - wie xref remove idempotent, aber nie stillschweigend: ein stiller No-op sieht genauso aus wie eine erfolgreiche Entfernung, und genau so verschwindet ein Tippfehler.
--summary/--provenance/--confidence-base bleiben als Kurzformen.

Die Sperrliste, und warum es eine ist

Gesperrt sind type: (ändert Schema und Ablageort - das ist page-lifecycle.md), confidence: (abgeleitet; --confidence-base setzen und confidence decay --apply laufen lassen) und die Page-Ref-Arrays related:, sources:, entities:, concepts: (xref pflegt die Gegenrichtung und die Body-Bullets mit; ein nackter Frontmatter-Schreibvorgang ließe die andere Hälfte veralten). Jede Ablehnung nennt das Kommando, dem das Feld gehört.

Bewusst eine Deny- und keine Allowlist: eine Allowlist wäre eine zweite Kopie des Schemas, und die Kopie ist die, die driftet - ein neu in einen Type-Spec aufgenommenes Feld bliebe stumm unbeschreibbar, bis jemand daran denkt. So gilt: was das Schema kennt, ist schreibbar, sofern es keinen Grund gibt.

Ein unbekanntes Feld wird anders abgelehnt als ein gesperrtes: nicht mit einem Verweis auf ein anderes Kommando, sondern mit der Liste dessen, was die Seite tatsächlich hat. Bei --set tag=x ist der Nutzen zu erfahren, dass tags gemeint war.

Sonst

raw_files: bekommt beim Schreiben durch touch dieselbe Existenzprüfung wie bei new - eine Dateisystemprüfung, die kein Schema ausdrücken kann.
_coerce_set_value, _parse_set_fields und _check_raw_files_exist sind aus new_page.py nach commands/_util.py gewandert und heißen jetzt ohne Unterstrich. Zwei Kommandos, eine Implementierung - andernfalls hätte touch --set das Komma-Problem aus #12 gleich mit geerbt.
tests/test_touch.py ruft den Typer-Callback jetzt über einen Helfer mit Vollbelegung auf. Ein direkt aufgerufener Callback bekommt für ausgelassene Argumente OptionInfo-Objekte, und ohne den Helfer kostet jede neue Option eine Änderung an jeder Aufrufstelle.

Nicht enthalten

raw rename - der Fall, dass die Datei sich bewegt. Zweistufig ist er jetzt möglich (git mv, dann touch --set raw_files=…), aber zwischen den beiden Schritten zeigt die Referenz ins Leere, und bei mehreren referenzierenden Seiten wächst das Fenster. Als eigenes Issue geführt.

1.3.0 - 2026-08-31 - capture-session: eine Session als raw/-Transkripte sichern und ingesten

Author: Torben Nehmer

Neue Instruction instructions/capture-session.md: eine beendete Claude-Code- Session als raw/notes/-Transkripte sichern und einzeln ingesten. Das war inzwischen dreimal von Hand gemacht worden, jedes Mal etwas anders - und die Fehler, die dabei teuer sind, macht man genau einmal.

manual: true, also bewusst nicht aus AGENTS.md oder einem Skill verlinkt. Jede Session zu sichern würde raw/ mit Material füllen, das nie jemand zitiert; die Einschätzung „war diese Session es wert" gehört dem Nutzer, nicht dem Agenten. Aufruf nur namentlich auf Anforderung.

Was die Instruction festhält, statt es beim nächsten Mal wieder herzuleiten:

Drei Oberflächen, drei Aufgaben. raw/ hält die Evidenz, der Issue-Tracker den offenen Arbeitsstand, kb/ das Gelernte. Ein Transkript ist keine To-do-Liste: was offen bleibt, wird vor dem Ingest zum Issue, und das Transkript hält nur fest, dass es das wurde.
Ein Transkript je Thema. Eine Rohdatei bekommt eine Source-Seite, und deren summary:/entities:/concepts: beschreiben eine Sache. Später zu schneiden heißt, eine Datei umzubenennen, auf die schon Zitate zeigen.
Fidelity wird bei der Erfassung festgelegt und steigt danach nie wieder. Kein Zitatformat und keine spätere Prüfung befördert eine Paraphrase zum Zitat - nur ein erneuter Blick ins Original, den es bei einer beendeten Session nicht mehr gibt. Was tragend werden könnte, wird sofort wörtlich zitiert; Material aus zweiter Hand (etwa Subagent-Befunde) nennt seinen Vermittler.
Ingests laufen streng nacheinander. Parallele Ingests desselben Korpus kollidieren an geteilten Entity-Seiten, an den generierten Dateien und an publish - jedes Mal als stiller verlorener Schreibvorgang, nicht als Fehler. Je Transkript eine eigene WIKITOOL_SESSION_ID.
Verworfene Alternativen gehören ins Transkript. Was der Code tut, steht im Code; was er bewusst nicht tut, steht sonst nirgends.

Die Punkte zu Fidelity und zur Trennung von Evidenz und aktivem Arbeitsstand sind aus der vendorierten commonplace/-Wissensbasis übernommen (a-citation-cannot-assert-more-fidelity-than-its-capture-preserved, active-work-state-is-not-retrospective-memory-or-chat-history).

Mit diesem Commit landen zugleich die drei Transkripte dieser Session unter raw/notes/; ihre Source-Seiten entstehen in den nachfolgenden Ingests.

1.2.1 - 2026-08-31 - Arbeitsplanung: Gitea-Issues mit prio/size-Labels statt TODO.md

Author: Torben Nehmer

TODO.md ist entfernt. Nach der Verlagerung der CI/CD-Punkte nach Gitea (2026-08-30) und der Recherche-Notiz als Issue #15 stand dort nichts mehr, was nicht ohnehin ein Issue war - die Datei war eine zweite Liste über denselben Bestand, und die zweite Liste ist immer die, die driftet.

Offene Arbeit steht ab jetzt ausschließlich in den Gitea-Issues, ein Issue je Arbeitspaket, mit genau zwei Labels:

prio/1 blockiert oder beschädigt laufende Arbeit, prio/2 trägt bald Zinsen, prio/3 wartet auf einen benannten Auslöser.
size/XS bis size/L schätzt den Aufwand, nicht die Wichtigkeit.

Beide Achsen sind Pflicht: eine Priorität ohne Kosten ist eine halbe Entscheidung. Eine dritte Achse gibt es bewusst nicht - dort fängt eine Taxonomie an, eigene Pflege zu brauchen, und dieses Board hat einen Betreuer.

Die Regel steht in instructions/dev/issue-tracking.md und ist aus dem stack-dev-Skill verlinkt. Sie liegt unter instructions/dev/, weil sie nur hier gilt: eine verteilte Instanz hat keine Issues unter dieser URL, und dist export schließt das Verzeichnis vollständig aus. Aus demselben Grund ist das ein PATCH und kein MINOR - für eine bestehende Instanz ändert sich nichts.

1.2.0 - 2026-08-31 - --set-Arraywerte mit Komma, Lint-Reportpfad, Budget-Refund, Ceiling 60

Author: Torben Nehmer

Zwei Werkzeugdefekte aus dem Ingest vom 2026-08-30 (Issues #12 und #13). Beide haben den Nutzer gegen eine Regel des Stacks gedrückt: einmal gegen die Unveränderlichkeit von raw/, einmal gegen Invariante 6. Das ist der Grund, warum sie zusammen vor allem anderen kommen.

`--set` kann Kommas in Arraywerten ausdrücken (#12)

parse_list teilte hart an , ohne jedes Escape, und Shell-Quoting hilft nicht - die Quotes sind lange weg, bevor der Wert dort ankommt. Ein raw_files:-Pfad mit Komma im Dateinamen war damit nicht darstellbar. Im Ingest vom 2026-08-30 wurde deshalb die Rohdatei umbenannt, obwohl raw/CONTRACT.md die Rohschicht als unveränderlich führt.

\, ist jetzt ein literales Komma und überlebt den Split (parse_list, also auch xref add --entities).
--set hängt an, wenn es für dasselbe Arrayfeld wiederholt wird: --set raw_files=a --set raw_files=b. Das ist die Form ohne Trennzeichen und damit die richtige, wenn ein Element ein Komma enthält. Skalare Felder behalten "last one wins".
Die Fehlermeldung von _check_raw_files_exist benennt den Split als Ursache und den Ausweg - vorher nannte sie einen Pfad, den niemand getippt hatte.

Dazu die zweite Hälfte desselben Defekts, die beim Testen auffiel: dump_frontmatter schreibt Listen in Flow-Syntax ([a, b]), quotete aber nach Dokument-Kontext. Ein Element mit Komma kam deshalb als zwei Elemente zurück - --set hätte den Wert korrekt geparst, und die Datei hätte ihn trotzdem zerlegt. _round_trips_as_string prüft den Rundlauf jetzt im selben Kontext, in dem geschrieben wird, und _quote fragt für beide Kontexte die Bibliothek statt selbst zu quoten. Bestehende Ausgabe ändert sich dadurch nicht - nur Werte, die vorher stillschweigend kaputtgingen, werden jetzt gequotet.

Iteration Budget: Reibung statt Iteration wurde gezählt (#13)

Ceiling 30 → 60. Das Band aus der Kalibrierung (5-15 einfach, 15-25 komplex) bleibt, wie es ist: es beschreibt die Arbeit. Die Decke beschrieb bisher nichts - sie lag so dicht am Band, dass der Overhead eines echten Ingests (Bericht nachlesen, ein korrigierter Retry, Baum vor dem Publish prüfen) allein sie erreichte. Der Ingest vom 2026-08-30 lief inhaltlich im Band und kam trotzdem nur mit --override-budget durch.
Ein Aufruf, der abgelehnt hat, wird zurückerstattet. Wer über _util.fail() mit Exit 1 endet - abgewiesenes Argument oder ein lesender Check, der Befunde meldet - hat nichts getan; und der Tool-Error- Contract beantwortet ein abgewiesenes Argument mit "einmal korrigiert wiederholen", was sonst zwei Slots für eine Operation kostet. Der Aufruf bleibt in der Historie des Loop-Breakers: dreimal dasselbe kaputte Kommando bricht weiterhin ab. Ein Kommando, das seine Arbeit schon getan hat und dann ungleich null endet (lint --fail-on-error), wirft typer.Exit(1) direkt und bleibt gezählt.

`lint` nennt seinen Reportpfad (#13)

lint ohne Flags kippte den vollen Bericht nach stdout und schrieb nichts. Wer ihn abschnittsweise las, hatte keinen Weg zurück zum übersprungenen Teil außer einem zweiten lint - zwei Slots für einen Blick auf einen unveränderten Korpus.

Der volle Bericht wird jetzt immer geschrieben, standardmäßig nach reports/Lint Report <date>.md, und der Pfad wird ausgegeben. --markdown überschreibt das Ziel wie bisher.
Gedruckt werden nur die Abschnitte mit Befunden. Bei sauberem Korpus ist der Vollbericht zu über 90 % "None found."; --full druckt ihn trotzdem.
--json schreibt weiterhin nichts.
wiki-lint und wiki-status sagen jetzt beide, dass die Datei gelesen wird statt lint erneut aufgerufen. wiki-status Schritt 3 liest die Hub-Statistik aus dem Bericht, weil sie kein Befund ist und deshalb nicht mehr in der Zusammenfassung steht.

Nicht enthalten

lint vom Budget zu befreien (dritter Vorschlag aus #13) - das ist eine eigene Entscheidung über die Grenze zwischen lesend und schreibend, und lint schreibt jetzt eine Datei.

1.1.1 - 2026-08-30 - CLAUDE.md: AGENTS.md/USER.md/SOUL.md erreichen Claude Code

Author: Torben Nehmer

Defekt, aufgefallen durch Nachfragen des Nutzers: Claude Code hat AGENTS.md noch nie geladen. Das Repo hatte keine CLAUDE.md, und Claude Code liest genau diese Datei automatisch - AGENTS.md nicht. Die anderen Harnesses (Codex, Copilot, Vibe) lesen AGENTS.md nativ, weshalb es niemandem auffiel. Praktisch heißt das: jede Claude-Code-Session lief bisher ohne Invarianten, ohne Routing, ohne Gate-Regeln, sofern der Agent die Datei nicht zufällig selbst aufmachte.

Mit 1.1.0 wurde der Defekt eine Stufe schlimmer: die File-naming-Tabelle behauptet seitdem für USER.md und SOUL.md „Always, every session". Für Claude Code war das schlicht unwahr.

Behoben durch eine CLAUDE.md im Root, die keine eigenen Regeln trägt - nur drei Importe (@AGENTS.md, @USER.md, @SOUL.md) und die Begründung, warum sie existiert. Eine Regel dort wäre die zweite Kopie, die Invariante 8 verbietet, und zwar die am ehesten driftende: sie stünde in der Datei, die nur ein einziges Harness liest.

Sie wird von dist export mitgeliefert (ROOT_FILES), aus demselben Grund wie .claude/settings.json: eine ausgelieferte Instanz unter Claude Code hätte sonst exakt denselben Defekt. Ein Test hält fest, dass sie im Plan landet und @AGENTS.md enthält.

Bewusst kein doctor-Check dafür: CLAUDE.md ist harness-spezifisch, und eine Instanz, die nur unter Codex läuft, braucht sie nicht - ein FAIL wäre dort schlicht falsch. Anders als bei USER.md/SOUL.md, die jedes Harness liest.

Während des Setups löst nur @AGENTS.md auf; USER.md/SOUL.md entstehen erst in Schritt 6. Ab der ersten Session danach greifen alle drei.

1.1.0 - 2026-08-30 - Personalization Plane: USER.md/SOUL.md als Setup-Schritt

Author: Torben Nehmer

Zwei neue Dateien, die eine Instanz in jeder Session liest: USER.md (wer sie bedient) und SOUL.md (wie sie klingt). Beide sind reine Kontext- und Stildateien - sie bekommen keine neue Autorität, kein Gate und keinen Zugang nach kb/: SOUL.md verliert gegen AGENTS.md, und eine Nutzeraussage ist weiterhin keine Quelle im Sinne von Invariante 3.

Der eigentliche Entwurfspunkt liegt woanders. Beide Dateien sind Betriebsvoraussetzung und zugleich persönlicher Inhalt, gehören also nicht in jede exportierte Kopie. Sie entstehen deshalb während der Installation, nicht vorab befüllt in der Distribution:

USER.md.template und SOUL.md.template liegen im Root und werden von dist export mitgeliefert. Dass die ausgefüllten Fassungen es nicht werden, ist keine zusätzliche Regel, sondern Folge der bestehenden Root-Allowlist - ein Name, der dort nicht steht, wird nicht kopiert.
Beide Templates tragen eine Sentinel-Zeile (wikitool:template-unfilled), die beim Ausfüllen entfernt wird.
instructions/setup-instance.md hat einen neuen Entscheidungspunkt (Schritt 6, Personalization); die Folgeschritte verschieben sich um eins. Der Agent interviewt entlang der Template-Abschnitte und schreibt die Antworten wörtlich mit. Zwei Fragen darf er nicht raten: den Persona-Namen und die Themen, die bewusst draußen bleiben.
wikitool doctor bekommt den Check personalization: FAIL bei fehlender Datei und bei einer, die noch den Sentinel trägt - ein umbenanntes Template ist kein ausgefülltes.

Für bestehende Instanzen: doctor meldet ab hier personalization: FAIL, bis die beiden Dateien existieren. Das ist einmalig nachzuholen und keine Content-Migration - .wikitool-kb.json bleibt unberührt, keine Seite ändert sich. Nachzuholen ist ausschließlich Schritt 6 aus setup-instance.md, nicht der ganze Ablauf; instructions/bootstrap.md und INSTALL.md verweisen an der jeweils passenden Stelle darauf.

Der CI-Replay der Installation stubbt den neuen Entscheidungspunkt so wie die Identität: mit einer festen Antwort (Template minus Sentinel-Zeile). Geprüft wird damit, dass der Export die Templates trägt - nicht, was ein Mensch hineinschreibt.

Umgesetzt aus Issue #2.

1.0.1 - 2026-08-30 - Tests ohne globale git-Identität; CI-Fixes

Author: Torben Nehmer

Der erste CI-Lauf, der überhaupt bis zu pytest kam, hat zwei Tests umgeworfen, die auf jeder Entwicklermaschine grün sind: sie hingen an einer globalen git-Identität. default_author() ruft git config user.name mit cwd=config.ROOT auf, und die Fixture-Wurzel ist kein Repository - also antwortete bisher die globale Konfiguration dessen, der die Suite laufen ließ. Im Job-Container als root gibt es keine, und new source weigert sich zu Recht, einen Platzhalter-Autor zu stempeln.

test_new_source_author_falls_back_to_git_config macht die Fixture-Wurzel jetzt selbst zu einem Repository mit lokalem user.name. Damit prüft der Test den Fallback statt der Maschine - und prüft ihn schärfer: er behauptet jetzt den konkreten Namen, nicht nur, dass irgendeiner dasteht.
test_new_source_with_multiple_raw_files setzt WIKI_AUTHOR. Der Test geht über raw_files:, Autorschaft ist dort nur Vorbedingung.

Nachprüfbar mit GIT_CONFIG_GLOBAL=/dev/null GIT_CONFIG_SYSTEM=/dev/null pytest, was die CI-Bedingung lokal herstellt.

Dazu die Workflows unter .gitea/ (ohne eigenen Bump, sie stehen außerhalb des Version-Gates): nodejs wird jetzt vor dem Checkout installiert, weil act_runner JavaScript-Actions mit node im Job-Container ausführt und debian:trixie-slim keins mitbringt; actions/checkout auf @v7; und CI läuft nicht mehr auf reinen Inhaltsänderungen.

1.0.0 - 2026-08-30 - Content migrations get a version, a chain, and a mechanical check

Author: Torben Nehmer

Migration: none required - no distributed instance exists yet; 1.0.0 is the migration baseline

0.1.0 gave an instance a way to learn that it must migrate. This release gives it a way to know what shape its content is in, which migrations it still owes, in what order - and a mechanical check that a bulk rewrite did not quietly drop something.

Two versions, not one. VERSION describes the machinery. What shape the content is in is a different number, now in .wikitool-kb.json and written only by migrate done. Without it the state every upgrade passes through - machinery already replaced, content not yet migrated - cannot be represented at all, and migrate status would have to infer the answer from the stack version, which is wrong exactly when it matters. It is a separate file from .wikitool-release.json because the two have opposite rules: that one is generated and must never be hand-edited, this one is mutable instance state. dist export seeds it with the exported version, since a fresh instance's content is empty and therefore trivially current; only a tree predating the file has to answer by hand, via migrate baseline.

Migrations run as a chain. An instance rarely moves exactly one version. migrate status builds the interval (kb_version, VERSION] from the documents under instructions/migrations/ and orders it: 1.3.1 to 2.0.0 runs 1.4.0, then 1.7.0, then 2.0.0. That no migration targets 1.3.x is not a special case - it simply is not in the interval. migrate done refuses any version that is not the next link, so a step cannot be skipped and an interrupted multi-step upgrade resumes rather than has to be reconstructed.

migrate verify --from <rev> is the piece that was missing. It compares every page against a git revision on what a content migration must not change: wikilink and citation counts, footnote definitions, H1, structural frontmatter. lint cannot answer this and never could - it reads a single revision, so a reference that went missing leaves a corpus that is still perfectly consistent. Everything it compares is a Counter, never a set: three of the four defects found in the 248-page translation had unchanged link sets and only changed counts. Verified both ways on the real corpus - a clean run over 248 pages produced zero findings in 2.2 s, and dropping one of two [[Docker]] occurrences from one page was reported as 'Docker' 2->1 while lint passed all 21 checks in silence.

A migration is a manual: true instruction, at instructions/migrations/<version>-<slug>.md with migrates_to: and migration_kind:. No new stage and no new type: the Manual tier exists for procedures that must never run implicitly, and dist export already ships instructions/, so a migration reaches every distributed instance with no second export path. (The contract's claim that the tier had no example was already stale - german-terminology.md uses it too.)

The methodology is now written down. instructions/migrate-corpus.md holds what the translation run learned and then deleted with its workshop: units sized by the iteration budget (~21 pages against the 30-call ceiling), publishes sized by the Mass-Update Gate, the two being different boundaries; migrate verify before the summaries and before lint; read the whole lint report; carry the vocabulary between units. Preferring a backwards-compatible change over a flag day is a decision point of its own, with sections.py's canonical-plus-alias pattern as the worked example.

Enforcement, in two places. version bump --major refuses without either a migration document for the new version or --no-migration "<reason>", and docs verify checks the same thing about the newest changelog entry. An instance told to migrate with nothing telling it how is the dead end both close - this entry's own --no-migration line is the mechanism's first real use.

Starting at 1.0.0. compat_key is stated generally (leftmost non-zero component), so nothing in the code special-cases a range; but the guidance derived from it under 0.x was self-contradictory, assigning --minor to both "new capability" and "requires migration". From 1.0.0 the familiar reading holds throughout: PATCH fixes, MINOR adds compatibly, MAJOR migrates. Pre-release suffixes stay unsupported - x.y.z is the whole grammar, and a second ordering rule would have to be honoured by the release feed, the chain and the compatibility check alike.

One bug found by running it for real. The historical side of the diff listed every .md under kb/ while the working-tree side used iter_kb_pages, which skips COLLECTION.md, INDEX.md and the kb-root meta files - so a clean run reported 13 phantom removed "pages". Both sides now answer with one shared kb_scan.is_page_path, and the regression is pinned.

Deliberately not built: mechanical runner primitives (migration_kind: mechanical describes the work today, it does not perform it - a DSL for zero migrations is not worth having), and dist upgrade, still the manual procedure in INSTALL.md.

Verification: 630 tests pass (46 new), docs verify, instructions verify and lint --fail-on-error clean, plus the two real-corpus runs described above.

0.1.0 - 2026-08-29 - The stack gets a version, a pipeline, and release files

Author: Claude Code

The repo had no CI and no way to say which stack an instance was running. Both are now in place, and they are the same mechanism seen from two ends: a version that CI enforces, stamps into every export, and publishes as a release an instance can compare itself against.

VERSION versions the stack, never the content. tools/, types/, instructions/, AGENTS.md and the contracts - not the kb/ pages sitting in the same repo. That split is why the number is set explicitly instead of being derived from commit messages: publish --message "ingest: ..." writes content commits here too, so any conventional-commit reading would turn every ingest into a release.

Compatibility is read off the leftmost non-zero component, the rule Cargo's caret ranges use: 0.1.3 -> 0.1.4 is safe, 0.1.3 -> 0.2.0 is not, and from 1.0.0 on the same rule reads as the familiar "MAJOR means migration". Stating it this way is what lets the 0.x era carry the migration signal at all - under plain "MAJOR breaks" semantics every 0.x release is indistinguishable from every other, which is exactly the signal update detection needs. Nothing about the mechanism changes at 1.0.0.

New: wikitool version - show (offline: the version plus the release stamp it came from), bump --major|--minor|--patch --title (writes VERSION and opens this entry's heading, leaving the body to the author - the same structure-by-tool/prose-by-author split as new), notes (prints one entry, so the release workflow never parses markdown in shell), and check.

version check is the one networked command in wikitool. The research note in TODO.md argues that a network call breaks all four properties every other command has - offline, deterministic, free, testable - and it does. It is allowed here on narrow terms: its own command that nothing else calls implicitly, no API key, a timeout, the fetch behind an injectable function so the tests never touch a network, and a feed that cannot be reached is reported as an error rather than silently answered as "up to date". The argument that ruled out a Perplexity call was about a paid, keyed API; an unauthenticated GET on a release feed is a different thing.

dist export now ships VERSION and writes .wikitool-release.json. The stamp holds the version, the export date, the origin (repo, commit, release page, update feed - supplied by flags, because export still never calls git), and a sha256 per exported file. Nothing reads the digests today: they record what the machinery looked like when it was installed, which is the only thing a later dist upgrade could use to tell a file the instance edited from one it merely received. Writing them now is what keeps that upgrade from needing a format change.

CI: .gitea/workflows/ci.yml on push/PR to main, runs-on: linux-docker, one job that stops at the first failure - the four steps TODO.md specified (tests, lint/docs verify/instructions verify over the dev tree, dist export, then instructions verify against the export) plus two the versioning makes possible:

a version gate: if the pushed range touches stack paths, VERSION must have moved and CHANGES.md must say why. It cannot block a push that already landed, but a release can never contain a change nobody named.
the export smoke test now replays setup-instance.md end to end (git init, identity, venv, instructions sync, index rebuild, sources rebuild-index, doctor, docs verify, instructions verify, lint) instead of running one verify against it. What that tests is the artifact as an artifact: the documented path from tarball to working instance.

Release: .gitea/workflows/release.yml, triggered by a push to main in which VERSION changed. It tags v<version> (the CI tags, never an agent - AGENTS.md invariant 5 is untouched), exports with the origin flags filled in, and publishes llm-wiki-stack-<version>.tar.gz plus a .sha256 as Gitea release assets, with wikitool version notes as the release body. The tarball is exactly a dist export tree, so INSTALL.md's Weg A now starts from a download instead of requiring a checkout of this repo.

Both workflows were written against the wiki's own record of the runner (the Act Runner and Gitea Actions pages), which corrected two guesses. Authentication is ${{ gitea.token }}, the short-lived per-job token this instance issues - not secrets.GITEA_TOKEN, and not a 1Password secret: nothing in these two workflows leaves the instance, so the Zero-Trust secret path the container-build workflows use has nothing to carry. And the job image is named explicitly (container: image: debian:trixie-slim, the base Szenario B already proves works with actions/checkout@v4) rather than inherited from the linux-docker label, because the label-to-image mapping is the one thing the wiki does not record - and it decides whether python3 exists at all. Trixie's python3 is 3.13, past the 3.11 floor doctor enforces.

Deliberately not built yet: applying an update. Detection tells an instance a newer stack exists and whether it crosses a compatibility boundary; INSTALL.md documents the manual procedure. dist upgrade is a command that writes into an instance that already has content, which is a different risk class and wants the stamp's digests to exist first - they now do.

Also: doctor gained a stack-version check (missing VERSION is a WARN, since instances exported before this release are still perfectly functional; malformed is a FAIL). docs verify gained the VERSION/CHANGES.md agreement check. version show/check/notes are exempt from the Iteration Budget Gate as read-only; version bump is not.

Verification: 585 tests pass (61 new), and the CI job's own sequence was replayed locally end to end against a real export - instructions sync, index rebuild, sources rebuild-index, doctor, docs verify, instructions verify, lint --fail-on-error, version show - all clean in a tree with no git history and no content.

version check was also run against the live feed. It returned 404, which was first read as "no release published yet" - wrongly. This repository is private, and Gitea answers an anonymous caller with the same 404 for an invisible repository as for one that does not exist; the repo endpoint returns it for a made-up repository name too. So $WIKITOOL_UPDATE_TOKEN is not the exception here but the requirement, until the repository is made public. The mechanism was unaffected - the variable exists and the 401/403 message already names it - but the two documentation claims that said otherwise were wrong and are corrected.

That run also found a real bug, now fixed and regression-tested: version notes terminated an entry at the next versioned heading, and every entry below 0.1.0 is headed by a date - so the newest entry ran to the end of the file, and the first release would have shipped the entire changelog as its notes.

What no local run can prove is the runner itself: whether linux-docker accepts a job that names its own container image, and whether ${{ gitea.token }} carries the rights to create a release. The first run on the server answers both.

2026-08-29 - Human docs catch up, and a new instance is asked which language it wants

Author: Claude Code

Auditing README/INSTALL/EVALS/tools/README against the migration turned up one thing that was not a documentation gap at all.

A dist export instance inherited German silently. The exported distribution ships kb/CONTRACT.md § Language, instructions/german-terminology.md and the German section names in sections.py - verified by exporting one and grepping it. setup-instance.md has decision points for author identity and remote, both of which refuse to be guessed from the source repo on the grounds that it is "a different person, a different project". The KB language is the same kind of choice and was being passed along without being asked. It is now step 5, placed before the tool environment so the answer lands before the first ingest - after that, changing it is a migration of every existing page rather than an edit to one contract section.

The step names what actually has to change for another language (contract section, tone examples and hedge words, four page templates, sections.py canonical names with the old ones kept as aliases, relationship labels) and what does not: the prose/identifier split itself is not a German rule. Titles, wikilink targets, cite-ids, enum values, tags, commands and paths follow no KB language in any instance.

Documentation brought current: README gains the language paragraph it lacked entirely, the title rule under Tips → Naming, german-terminology.md in the layout tree, and German relationship labels where it still listed depends-on, uses, implements. INSTALL gains the language decision in Weg A. tools/README.md gains sections.py and a design note on why heading names are a vocabulary with aliases rather than literals.

One correction worth its own line. tools/README.md claimed tests "use tmp_path fixtures and monkeypatch config paths rather than touching the real kb/". Two do not: test_types_cmd.py and test_index_build.py resolve the real types/ on purpose, since what they assert is that behaviour comes from the type-specs. That sentence is why editing layout: title: failed six tests that looked unrelated - and why the first fix attempt in this session anchored a test on a literal heading that the next commit promptly translated. The README now says so, and says what such a test may pin: structure, never wording.

2026-08-29 - The corpus is German; the glossary outlives the run

Author: Claude Code

All 248 kb/ pages are translated, no English template heading remains anywhere, and source_language: is set on all 38 source pages. wikitool lint reports clean on all 21 checks. The translate-kb-de workshop is closed.

What survived the closure, and why. work/CONTRACT.md requires a run's durable conclusions to be out of work/ before the directory is deleted. Of the run's four files, three were bookkeeping - unit plan, checklist, subagent brief - and died with it. The glossary did not: it is not a migration artifact. Every future ingest of an English source produces German prose and meets the same questions, so it is now instructions/german-terminology.md, linked from kb/CONTRACT.md § Language. The rule stays in the contract, the vocabulary moved to the instruction layer - a word list is lookup material, and 80 lines of it do not belong in a file loaded on every write.

What the migration cost, and where. The mechanical checks - frontmatter, H1, wikilink and cite-id multisets compared against HEAD - found four defects in 248 pages: a dropped citation that silently unsourced a claim, a dropped wikilink, an invented one, and one translated H1. Three of those four would have passed a set-based comparison; only counting occurrences caught them. None would have been reported by lint, which checks whether references resolve, not whether one went missing.

The checks found nothing else, and that is the more useful result: every remaining error was a plausible, consistent, wrong word. „Geheimnis" for Secret (96 occurrences), „Fähigkeit" for Skill and Capabilities, „Anspruch" for claim, and 182 sentences in the polite „Sie" form the English imperative invites. Structural verification cannot see any of these - each page is internally perfect - and neither can a subagent that made the choice consistently.

Where the errors actually came from. Nine glossary revisions were needed, and the pattern held throughout: the agents followed the instructions, and the instructions were ambiguous. A counter-check for capabilities was written backwards and would have propagated through eleven units. "Separation of Concerns" was listed as a choice between two options rather than as a fixed phrase, and one agent took the other option and reported doing so. "Fehler melden, nicht korrigieren" meant errors in the source, and an agent applied it to its own bad German. Cheap parallel agents do not degrade an instruction gracefully - they execute both readings of it at once, in the same batch, which makes every ambiguity immediately visible and immediately expensive.

2026-08-29 - Two frontmatter fields no command can write

Author: Claude Code

Both surfaced while closing the translation run, and both are recorded rather than fixed - the right shape for either is a design question, not a patch.

source_language: has no writer. The field was added to types/source.schema.yaml this morning, and wikitool new source --set source_language=de sets it at creation. On the 37 source pages that predate it there is no path at all: touch writes exactly modified/date, summary, provenance and confidence_base, and nothing else offers a generic frontmatter setter. Backfilling meant editing the field directly. That is defensible for a plain data field - it is neither generated nor a page-reference array, so AGENTS.md invariant 1 does not reach it - but "add a schema field" and "be able to set it on the pages that already exist" should not be separate capabilities. Adding a field to a schema is currently a half-migration by construction.

comparison declares no modification date. touch --page "amd-pstate vs acpi-cpufreq" fails with "Type types/comparison.md declares no modified/date field - pass --no-date to skip it", because the schema has only created. So a comparison page can record when it was made but never that it was revised - and touch --summary on one requires --no-date every time. Either comparison should gain modified: like entity and concept, or the omission should be documented as deliberate; right now it reads as an oversight that the error message papers over.

Neither blocked the run. Both are the kind of gap that only shows up when something walks the whole corpus, which is exactly what a migration does and what routine per-page work never will.

2026-08-29 - Date fields hold dates, and the special case disappears

Author: Claude Code

Supersedes this morning's ISO-date exemption, which is now deleted. That fix worked by teaching _round_trips_as_string to recognize a date-shaped string and leave it bare - a second place that had to know what a date looks like, kept in sync by hand with the schemas and with validate_frontmatter's normalization.

The question that removed it: why is there a date-shaped string at all? _format_scalar has always rendered a datetime.date bare, and yaml.safe_load yields exactly that for every page on disk. Only two places ever put a string in a date field - touch and new, both via today_iso() - and the guard existed solely to paper over that mismatch. Both now write datetime.date, the exemption is gone, and no code outside _format_scalar needs an opinion about date syntax.

Three things fell out of it:

touch no longer reports a change on every run. It compared frontmatter.get(field) - a datetime.date read from disk - against a string, which is never equal, so an unchanged date was rewritten and logged as a change every time. With both sides dates, an unchanged page is now correctly a no-op.
--date and --set <date field>= validate their input. Previously any string was written through; 29.08.2026 would have landed in frontmatter and surfaced later as a schema error on a page nobody was looking at. Both now fail immediately, naming the expected shape.
normalize_dates moved to frontmatter_io and is shared. There were two validators and only one of them converted dates: TypeResolver.validate_frontmatter (behind lint) did, touch's validate_fields did not. Harmless while touch wrote strings, and a latent failure the moment it stopped - found by writing the change rather than by the tests.

On the question that prompted this ("can the quoting be schema-driven - we know what belongs there"): the instinct is right, but the schema does not distinguish the two cases. A tags[] entry and modified: are both declared type: string; keying on the declared type gives dates the same answer as "1945", which is the wrong one. Only format: date separates them, and reaching it from frontmatter_io would mean importing type_resolver, which already imports frontmatter_io. Making the value's own type honest answers the same question without a lookup - and _build_frontmatter was already schema-driven on format == "date", which is where that knowledge belongs.

2026-08-29 - The round-trip guard reached date fields it should not have

Author: Claude Code

Follow-up to the frontmatter fix earlier today, and a reminder that a correct-looking rule can still be wrong in context. _round_trips_as_string quotes anything that would read back as a different type - which is exactly right for a "1945" tag, and exactly wrong for modified:. PyYAML reads a bare 2026-08-29 as a datetime.date, so the guard started quoting it, and 53 pages came out of one batch carrying modified: '2026-08-29' while the other ~195 still had it bare.

Nothing broke: TypeResolver.validate_frontmatter already converts date objects to strings before validating, precisely because the schemas declare type: string while YAML hands back a date. That normalization is the corpus convention, and the guard had quietly voted against it. The result was not corruption but something more corrosive - a field with two spellings that alternate depending on whether touch happened to change the value, so every later diff carries noise nobody can attribute.

Full ISO dates (^\d{4}-\d{2}-\d{2}$) are now exempt from the guard, and the 53 pages are normalized back to bare. The exemption is deliberately narrow: 1945 is an int to YAML, not a date, so a tag by that name still gets quoted.

Found by reading the Mass-Update Gate's per-file churn: two of 32 translated pages had asymmetric line counts where every other page was symmetric. Chasing that asymmetry - it turned out to be harmless line rewrapping - surfaced the modified: line in the same diff.

2026-08-29 - Frontmatter round-trip turned string values into other YAML types

Author: Claude Code

_format_scalar decided quoting from a hardcoded list: empty, leading special character, surrounding whitespace, ": ", or one of true/false/null/~. A string that merely looks like a number was not on it, so the Python string "1945" was written bare and read back as int on the next load. wikitool touch rewrites the whole frontmatter block, so translating a page was enough to corrupt a tag it never mentioned: Vannevar Bush came out of a --summary update failing schema validation on Field 'tags[3]': 1945 is not of type 'string'.

The list was also short in a second direction. yaml.safe_load follows YAML 1.1, where yes, no, on and off are booleans, and it resolves 0x1F, 1_000, 1e5 and +3 as numbers - none of which the check knew about.

Rather than lengthening the list, _round_trips_as_string(text) now asks the loader whether yaml.safe_load(text) == text, and quotes when it does not. Reader and writer agree by construction, and a resolver rule this code has never heard of cannot drift out from under it.

Two pages in the corpus were one touch away from the same corruption - Memex (1945) and 10.000 Dice Game (10000) - which a translation run touching all 248 pages would have reached. Vannevar Bush is repaired.

How it was found is the reusable part. The wikitool lint run at the end of a unit reported a schema error on a field the unit had not edited. A page that changes in a way nobody asked for is worth chasing even when the visible diff looks right, and the check that caught it - lint after every unit, before publish - is now in the run's README rather than in anyone's memory.

2026-08-29 - `work new --key` for a run that is not an ingest

Author: Claude Code

The workshop layer assumed every task too big for one session was an ingest: work new required --input <raw path> and derived the run key from it. A translation pass over the 248 existing kb/ pages has no raw input at all, so it could open no workshop - and the alternative was worse than cosmetic. Without plan.md there are no written unit boundaries, and instructions/gates.md allows a fresh WIKITOOL_SESSION_ID only at a boundary recorded there; a run with no plan either exhausts one 30-call budget or takes new session ids on no authority but its own.

work new --key <run key> names the key outright. Exactly one of --input/--key is required, and a --key may not start with ingest-, which stays reserved for derived keys so a directory name keeps saying which kind of run made it. plan.md gets a second template for these runs - units sized by the iteration budget rather than by raw_files count, since there is no tree to cut.

Also worth recording, because it will happen again: adding a parameter broke seven tests that call new_command(...) directly. Bypassing Typer means an omitted argument keeps its typer.Option(...) sentinel rather than becoming None, so a mutual-exclusion check saw both options as supplied. test_git_publish.py already documents this trap in _publish; the fix is to pass every parameter explicitly, not to loosen the check.

2026-08-28 - Two bugs the translation sample run surfaced

Author: Claude Code

Both found by translating six pages by hand before turning subagents loose on 248. Neither is about language; both were latent and would have been amplified by the bulk run.

touch overwrote a source's publication date. DATE_FIELDS = ("modified", "date") picks whichever field the type declares, and a source declares date: - which the schema documents as "Publication or creation date". So touch --summary on a source page silently rewrote the raw material's own date to today, leaving the page contradicting the **Datum:** line printed in its own body. Rewriting a summary is a statement about the page; the source's date is a fact about the world, and today's date is simply wrong for it. modified: is still bumped automatically; date: now moves only on an explicit --date. Caught on one page during the sample, it would have hit all 38 source pages in the bulk pass.

The Mass-Update Gate misreported any file with a non-ASCII name. _changed_files reads git status --porcelain -z, which emits raw paths; _numstat read git diff --numstat without -z, and git renders such a path quoted ("kb/sources/Source - 10.000 ausw\303\274rfeln…"). The lookup missed, the file fell through to _untracked_stat, and a rewrite was reported as a pure insertion: +54/-0 for a change git counted as +28/-27. This is the same failure mode as the 718-line deletion reported as -174 on 2026-08-27, reached by a different route - the report understating removals in the one direction a reviewer most needs it not to. _numstat now passes -z and parses NUL-delimited records, including the empty-path-plus-two-records form git uses for a rename. Regression tests for both are in test_git_publish.py and test_touch.py.

Worth noting how this one was found: the gate printed the wrong number in a clearance report that was being read carefully because it was about to be approved. The numbers a gate prints are the gate.

2026-08-28 - Section headings become a named vocabulary instead of hardcoded English literals

Author: Claude Code

The language policy earlier today froze all section headings as English, on the grounds that xref add and cite add match three of them literally and a translated heading would silently append a second section. That reasoning was sound but the conclusion was too cheap: it left every page with an English skeleton around German prose, which is most of what "the wiki is in German" is supposed to mean. Tracing the literals showed the constraint was smaller than it looked - three constants in two files, with page_ops.py matching bullet shapes rather than headings and not involved at all.

wiki_tools/sections.py now owns the vocabulary. Each heading has one canonical name - what the tool writes - and aliases it still recognizes:

Canonical	Recognized alias
`## Beziehungen`	`## Relationships`
`## Siehe auch`	`## See Also`
`## Fußnoten`	`## Footnotes`

That asymmetry is the point: a 248-page corpus cannot be translated atomically, so a page still carrying the English heading has to keep working. xref add finds and appends to it rather than creating a duplicate, and only a page's own translation changes the name.

A regression the tests caught, worth recording. Making render_page_body write the canonical heading turned cite sync into a silent migrator: every page with an English Footnotes block came back changed, so one cite sync --all would have rewritten the whole wiki and buried the real diff. split_cite_block's counterpart cite_block_heading(body) now reports the heading the page actually carries, and the three call sites pass it back into render_page_body. Renaming a heading is the translation pass's job, never a side effect of another command. cite sync is a no-op on an untranslated page again, and a test pins that.

Also here: the four page-type templates now scaffold German sections; **Type:** becomes **Typ:** while the value stays the schema enum that search --field filters on; and kb/CONTRACT.md's typed relationship labels (depends on → hängt ab von, …) are German, which is safe because no code matches on them - an untranslated label is stale wording, not a broken reference.

Not covered here: the 248 existing pages still carry English headings and prose. They are recognized, not migrated.

2026-08-28 - Canonical KB language: German, with an identifier carve-out

Author: Claude Code

The wiki had no language rule anywhere - not in AGENTS.md, not in the contracts, not in the skills, not in the schema. The 248 existing pages were English purely by LLM habit, and a German raw file (raw/documents/wuerfelspiel.md) had already been summarized into English with its German terms preserved in quotes. That is a defensible outcome reached by accident, which means the next ingest could just as well have gone the other way.

The rule now lives in one place, kb/CONTRACT.md § Language: pages are written in German, and every line of a page is either prose or an identifier - only prose is translated. The carve-out is not a list of exceptions bolted onto a language rule; it is the rule's second half, and it is what makes the policy mechanically safe:

Page titles and the H1 that repeats one follow the subject's own established name, not the KB language. GitOps Ownership Model and Act Runner stay. This keeps titles - and with them [[wikilinks]], the [^cite-id] ids derived from them, and every frontmatter reference array - out of the language question entirely. lint already reports an H1 that stops matching its title.
Section headings stay English because xref add and cite add locate them by literal name (commands/xref.py:75,79, commands/cite_cmd.py). A translated ## Relationships does not error - it makes xref add append a second section, silently.
The generated **Type:** line renders a schema enum value that search --field filters on.
tags: are search keys; commands, paths, config keys and code are what they are; quotations stay verbatim in the source's own language.

Consequential edits in the same contract. § Confidence prescribed the literal hedge words "possibly"/"may"/"uncertain"/"unconfirmed", and § Tone's buzzword and AI-filler lists and its good/bad example pair were English. Those are words meant to appear in pages, so under a German policy the contract was instructing against itself. All now German.

Sources in another language are summarized in the KB language regardless of what the raw file is in - a source page is evidence about a source, not a substitute for it. New optional source_language: (ISO 639-1, types/source.schema.yaml) records what had to be translated, and makes "which pages are translations" answerable with search --field source_language=fr. Optional by design: the 38 existing source pages predate the rule and stay valid.

The four page type-specs (entity, concept, source, comparison) have German prose now - they are the authoring surface that shapes kb/, and types describe dumps their body verbatim to whoever is writing a page. Their ```markdown template fences are untouched, for the heading reason above. Note that extract_template (type_resolver.py:190) takes the first markdown fence in the body, not the one under ## Template, so a translated section must never introduce a markdown example block above it. The control plane - AGENTS.md, the stage contracts, instructions/, and the type-specs for non-page artifacts - stays English.

Not covered here: the 248 existing pages, which are migrated separately, and layout: title: in types/entity.md (the generated INDEX headings), which moves with that migration since it forces an index rebuild.

2026-08-28 - Mass-Update Gate: `--yes` retired for an exit-42 clearance code and `--confirm <token>`

Author: Claude Code

The 2026-08-23 procedural fix - "run publish without --yes first, let the gate refuse, then re-run with --yes" - failed a third time on 2026-08-27: an agent asked "want me to publish?", got "Ok", ran publish (refused), and ran publish --yes in the same turn. The documented order was followed - refusal before --yes - but no human turn happened in between, so the approval the trace showed was the agent waving itself through. A procedure written down in advance is a ritual an agent can perform without a human in the loop, and eval score's gate-not-self-opened could not see the difference because it only ever looked at single calls.

What shipped, and the false start that shaped it. The first attempt made the gate un-self-openable: a ticket bound to the changeset, redeemable only after a prompt.submitted trace event and a wikitool approve <id> typed in a second terminal. It worked and it was unusable - on a harness driving wikitool through a shell tool the agent cannot produce the turn signal at all, and the human is asked to leave the conversation to approve anything. It was built, tested, and then deleted; a gate nobody can pass is not a safe gate, it is an abandoned one. What replaced it splits the problem in two: cheap honest enforcement in-process, and the real check in the eval layer.

A distinct exit code. EXIT_NEEDS_CLEARANCE = 42 (commands/_util.py, via needs_clearance()) is now a third outcome beside success (0) and validation error (1), meaning "a human has to see this output before anything proceeds". An agent, a hook, a CI job and a trajectory scorer can each tell it apart from "your input was wrong, fix it and retry" - which exit 1 could never express. AGENTS.md's tool error contract lists four outcomes now, not three.
The procedure moved into the tool's output. A tripped gate prints what would change, the full counted file list, and the exact copy-pasteable --confirm <token> line that publishes it (git_publish.clearance_message / rerun_command, the latter reconstructing the command line rather than echoing argv so it is correct however the original was spelled, and shlex-quoted). instructions/gates.md now says only "exit 42 -> show the user the output, stop" and nothing about the mechanism - deliberately, since a recipe in the instruction layer is one an agent can complete alone.
--confirm <token> replaces --yes. The token is a 12-hex digest of the counted file list plus the publish target (changeset_token), so a clearance never carries to a changeset the user did not see - touch one more file and the token changes and the gate asks again. This closes a hole --yes always had: it published whatever was in the working tree when it ran. A wrong, invented or superseded token exits 42 again with the current list. --yes/-y stay registered only to fail with an explicit error instead of a Typer usage error.
Stateless. No ticket file, no TTL, no session bookkeeping, no approve/approval status commands, and nothing under tools/.wikitool_session/ to get out of sync - the token is a pure function of the working tree and can be recomputed at any time.
The real check is in the eval layer, where a whole trajectory is visible instead of one call (evals/trajectory.py): clearance-ended-the-turn (error) flags a wikitool.call between an exit-42 call and the next prompt.submitted - precisely the "refused, then confirmed in the same breath" shape all three incidents had; clearance-was-asked-for (error) flags a gate.cleared whose token no gate.refused ever issued, catching both an invented token and one reused from a different changeset. gate-not-self-opened still hard-flags --yes/-y. Rules can now report a third state, skipped (Rule.skipped/skip_reason, rendered skip), so clearance-ended-the-turn says "cannot say" on a harness with no prompt hook rather than fabricating a pass - the degradation rule, applied to a rule that genuinely needs an optional event.
Telemetry: gate.cleared (token, counted, threshold, files) is new; gate.refused gained reason: needs-clearance|stale-token, token and presented_token. The ticket-era gate.ticket_issued/gate.consent/gate.approved are gone.
Harness adapters. .claude/settings.json (new, tracked, and copied by dist export as a single file via dist_cmd.SINGLE_FILES so the generated .claude/skills/ is not swept in with it) wires UserPromptSubmit to trace_ingest.py, which is what makes clearance-ended-the-turn scorable here, and adds a permissions.ask rule on Bash(tools/wikitool publish --confirm:*) so the clearing call prompts in-chat while ordinary publishes do not. Verified live against this CLI: a PreToolUse hook returning permissionDecision: "ask" does not override a matching permissions.allow rule (permissions beat hooks), which is why the rule is a permissions.ask entry and not a hook - and it is a prefix match, so rerun_command always emits --confirm first. Copilot CLI already emits userPromptSubmitted, so it needed no change; its decision-document schema stays unverified and therefore unwritten, per the rule the Vibe adapter established.
Honest limits, recorded rather than papered over. None of this proves a human typed anything: the token sits in the agent's own context. prompt.submitted proves a turn boundary, not that the output was relayed or that the reply meant yes. Closing that needs the harness to report what the agent actually said, which no adapter here does.
The clearance report is grouped and sized, not a flat list of paths. A 30-line alphabetical list tells a reviewer nothing about what kind of change it is. The refusal now opens with a scale line (file count, +added/-removed, status breakdown), then only the attention notes that actually apply - deletions named individually, how many files touch the agent control plane or harness config, how many published pages change, the largest single file, any binary - and then every counted path grouped by area (FILE_GROUPS), each with its status letter and churn. Ordering is by consequence, not alphabet: published knowledge and the control plane first, mechanically-regenerated files (is_generated) split into their own group at the end and labelled as needing no review. Deliberately notes, not a risk score: every line is a checkable statement a reader can disagree with by looking, where a number would invite trusting it. Only applicable notes are emitted, since a wall of "0 deletions" reassurances is how a reviewer learns to skim. Churn comes from git diff --numstat HEAD for tracked files and a line count for untracked ones, with binaries marked rather than given a fabricated count; a repository with no HEAD yet (the first-commit case in setup-instance.md) degrades to counts instead of failing.
The token now covers file contents, not just file names. changeset_token digests each counted path with a hash of its bytes, closing the same "approved A, published B" hole one level down: previously a cleared list could be published after rewriting one of those files, so the user's approval would have covered text they never saw. Editing a file after clearance now invalidates the token exactly as adding one does.
Deletions report their size. collect_changes originally short-circuited a deleted file to 0/0 churn instead of asking git diff --numstat, which knows it. The first changeset to exercise this deleted a 718-line file and went out headlined -174 against git's own -891 - four fifths of the removals missing, in the one direction a reviewer least wants understated. A deletion now carries its real removed-line count and renders as -718 deleted, so a one-line stub and a long document stop reading identically.
The clearance message's wording, fixed after it failed on first contact. It originally read "SHOW THIS OUTPUT TO THE USER"; the first agent to receive it replied with a file count and a pointer to "the output above" - which the user could not see, because on a harness that runs wikitool through a shell tool a command's stdout lands in the agent's context, not on anyone's screen. Printing and showing are different acts there, and an instruction that conflates them reads as already satisfied the moment the text exists. The message now leads with "THE USER CANNOT SEE THIS OUTPUT", asks for the file paths to be copied into the reply, and names the near-misses that do not discharge it (a count, a summary, "the output above"). gates.md got the same treatment. Worth generalising: an instruction to an agent should name the act, not the intent.
Also updated: instructions/gates.md (rewritten around the exit code, with an exit-code table), instructions/publish-cycle.md, tools/CONTRACT.md (publish command + error-contract rows), AGENTS.md (invariants 5-6, tool error contract), README.md, INSTALL.md, instructions/setup-instance.md, the wiki-ingest/wiki-lint skills, tools/README.md, EVALS.md (L2 rule table, the worked example rewritten around where the check moved to and why), and - as wiki content - kb/concepts/Mass-Update Gate.md and kb/concepts/Iteration and Cost Limits.md.

2026-08-26 - One-way dev/dist split: `instructions/dev/`, `stack-dev` skill; `dist enable-dev` retired

Author: Claude Code

Replaced the "dev instance" concept from the previous entry with a one-way model: a distributed instance never becomes a dev instance again. Instead of restoring dev-only content into a distributed instance, stack development happens in the origin repo (or a new dev instance exported from it).

tools/wikitool dist enable-dev is gone, along with tools/wiki_tools/dist_templates/agents_dev_extras.md/readme_dev_extras.md and instructions/enable-dev-extras.md (the manual: true instruction it backed). There is no longer a command that reconstructs dev-only content in a distributed instance - docs verify's matching drift check (check_dev_extras_in_sync) is removed along with it.
New instructions/dev/ - a second, purpose-scoped location for material that is exclusively about developing the tool stack itself (compiler/schema/instruction-layer changes), as opposed to operating on wiki content. tools/wikitool dist export now prunes this directory wholesale and unconditionally (dist_cmd.INSTRUCTIONS_EXCLUDE_DIRS) - a second, independent exclusion mechanism alongside the existing  marker convention, which only ever removed content inside an otherwise-shipped file. The commonplace/ vendored-knowledge-base guidance that used to live inline in AGENTS.md's marker block moved into instructions/dev/commonplace-kb.md.
New stack-dev skill, nested at instructions/dev/stack-dev/SKILL.md - switches a session into tool-development mode: source-binding rules for wiki content do not apply to code, and the test/review conventions under instructions/dev/ apply instead. Nested rather than a top-level sibling of the five content skills specifically so the one export exclusion removes it together with the instructions it routes to, with no separate skill-exclusion list. Linked from AGENTS.md via a routing line inside its own dist:strip block - normal (not manual: true), since it is a recurring session type, not a rare explicit request.
tools/wikitool instructions verify gained a boundary check: nothing outside instructions/dev/ may reference something inside it (instructions_cmd.dev_only_forbidden_references), because such a reference would dangle the moment dist export prunes the directory. A mention inside a dist:strip block is exempt - dist_cmd.strip_markers() removes it from the scan before the check runs, since dist export removes the block and the directory together. instruction_files()/skill_dirs() were extended to discover instructions/dev/ as a second scan location (previously non-recursive by design).
Canonical rule: instructions/CONTRACT.md. Also updated: AGENTS.md, README.md, INSTALL.md, instructions/setup-instance.md, tools/CONTRACT.md.

2026-08-25 - Citation syntax migrated to real GFM footnotes; `wikitool cite`

Author: Claude Code

Replaced the inline ^[[Source - X]] (or ^[[Source - X|file.md]]) citation marker - a Pandoc-style parser reads it as an inline footnote wrapping a broken shortcut link, so it never rendered correctly outside this repo's own tooling - with real GFM footnotes: an inline [^cite-id] reference plus a [^cite-id]: [[Source - X]] definition in a tool-owned ## Footnotes block at the end of the page. The qualifier for a multi-file source now lives in the wikilink's alias slot ([[Source - X|storage-model.md]]).

tools/wikitool cite id/add/sync - new command group. cite id previews the deterministic id cite_id(title, qualifier) derives (strip the Source - prefix, transliterate to ASCII, slugify, ---join title and qualifier, -2/-3 suffix on a per-page collision); cite add upserts a page's Footnotes definition and its frontmatter sources: entry and prints the marker to paste; cite sync prunes definitions nothing references any more, re-renders the block in first-reference order, and reports any [^id] reference left undefined. cite id is read-only and exempt from the Iteration Budget Gate.
wikitool lint hard-errors on three new findings: legacy_citation_markers (a leftover pre-migration ^[[...]]), undefined_footnote_refs (a [^id] with no definition), and orphan_footnote_defs (a definition nothing references) - the same class as broken_links, not an advisory.
wikitool rename now also refreshes a citation id derived from the old title (in both its Footnotes definition and every reference to it) alongside the wikilink retargeting it already did; a hand-picked or otherwise-derived id is left untouched.
Migration: all 71 kb/ pages carrying the legacy marker were rewritten by a one-off script (not committed - scratch tooling for a single run) that imports cite_id() from wiki_tools.provenance so it can never mint an id the tool itself wouldn't, and refuses to write any page where the multiset of (source title, qualifier) pairs cited before and after migration doesn't match exactly. raw/ and the historical entries in CHANGES.md/kb/log.md were deliberately left untouched.
Canonical rule: kb/CONTRACT.md. Also updated: types/entity.md, types/concept.md, types/source.md, kb/sources/COLLECTION.md, instructions/page-lifecycle.md, instructions/wiki-ingest/SKILL.md, instructions/wiki-manage/SKILL.md, AGENTS.md invariants 1 and 2, README.md.

2026-08-25 - Distributable instances: `dist export`/`dist enable-dev`, `doctor`, per-instance author

Author: Claude Code

Added a reproducible way to turn this repo into a fresh, contentless wiki instance, instead of manual copy-and-strip:

tools/wikitool dist export <target> writes a contentless copy of the machinery (AGENTS.md/README.md/EVALS.md with dev-instance-only content removed, instructions/, types/, tools/ minus venv/caches, the .github/hooks/+.vibe/ session-tracing config, every kb/*/COLLECTION.md with no pages or areas, empty raw/{articles,documents,notes,assets}/) into an empty target. Never touches git.
A generic / marker convention replaces the one-off "strip the commonplace section" idea: dist export removes whatever sits in a marked region, and tools/wikitool dist enable-dev is the exact inverse - it adds the vendored commonplace/ knowledge base back into an existing instance from tools/wiki_tools/dist_templates/, on request. docs verify checks the templates never drift from what this repo (itself a dev instance) actually has.
tools/wikitool doctor [--json] is a single read-only health check (dependencies, author resolution, git identity/branch/remote, published skills, structure, generated files, session id) backing the new setup instruction instead of ten checks spelled out in prose.
Per-instance author. author: on a new source page now resolves from $WIKI_AUTHOR, else this instance's own git config user.name (config.default_author()) - never a hardcoded name. Neither resolving is a hard failure (ERROR, exit 1), not a silent placeholder.
A third instruction-reference tier. instructions/*.md frontmatter gained manual: true: exempt from instructions verify's "must be referenced" rule, and inverted - it must NOT be linked from AGENTS.md or a skill (though a CONTRACT.md mentioning it as documentation is fine). For a rare, deliberate procedure that must never run implicitly.
New instructions: instructions/setup-instance.md (the normal path for a new instance: git init, author/remote decision points, bootstrap, first commit) and instructions/enable-dev-extras.md (manual: true, adds commonplace/ back on explicit request only).
New INSTALL.md for humans: prerequisites, the two paths (new instance vs. cloning this repo), configuration, doctor as the verification step, troubleshooting.

2026-08-24 - README brought current; keeping the human docs current is now written down

Author: GitHub Copilot

README.md had drifted behind six stack changes. What was wrong:

The architecture tree was missing work/, EVALS.md, .github/hooks/ and .vibe/, and still described reports/ as holding only lint reports.
It claimed to be "the only README in the repo", which stopped being true when the naming rule changed to let a stage carry both a README.md and a CONTRACT.md.
Two links sent readers to tools/README.md for the command reference and the maintenance schedule. Both moved to tools/CONTRACT.md when the command table was consolidated - and docs verify now enforces that the README has no copy of it.
wikitool skills sync was renamed to instructions sync.
Lint reports were said to land in kb/reports/.
The Search section advised a third-party tool for wikis past 100 pages, written before wikitool search existed.

Added: a Telemetry and evaluation section pointing at EVALS.md.

AGENTS.md's Changelog section now says that a stack change is not finished until the human docs describe it. It went there rather than into the Invariants list on purpose: an invariant holds in every session regardless of task, and this one only applies when the stack changes - a wiki-ingest or wiki-query session never touches a README. The Changelog section is already the place where the "record what changed" rules live, so it is one sentence in an existing home rather than a new rule competing for the always-loaded budget.

2026-08-23 - L0: the pipeline against a wiki the tools built themselves

Author: GitHub Copilot

tools/wiki_tools/tests/test_pipeline_l0.py builds a wiki through the CLI - new → write → xref add → index rebuild - against an empty tree, then asserts that lint finds no hard errors, that the catalog covers exactly what was created, and that rebuilding it again changes nothing on disk.

It closes the last gap the eval ladder rested on. Nothing in the suite chained the commands before: test_lint.py runs lint over a hand-written fixture, and a hand-written fixture cannot show that new, xref, index and lint agree with one another.

L0 belongs in pytest, not in a separate harness. The plan had it as a case in an evals/ stage, but a fixture wiki has to be driven in-process - config.ROOT is derived from wiki_tools/config.py's own location, so wikitool cannot be aimed at another tree from outside - and driving commands in-process against a temporary tree is exactly what the test suite already does. A second mechanism for it would have duplicated the suite. The evals/ stage is therefore not created: it exists to hold agent cases and fixtures, and there are none yet.

Two findings came out of writing it:

A scaffolded page does not lint clean. new writes placeholder wikilinks for the author to replace, so a page that was created but not yet written reports broken links. That is the scaffold saying it is unfinished, and it is now pinned by a test so it cannot be mistaken for a defect later.
The shared kb_dir fixture no longer validates against the type schemas. Five of its pages are missing provenance, summary or raw_files, and one carries a source key the schema rejects. test_clean_wiki_has_no_hard_errors passes anyway because it asserts only broken_links and duplicate_titles rather than the whole hard-error set. Left as found: repairing the fixture touches every test that reads those pages, and that is its own change.

EVALS.md records what an agent runner needs - a repo copy rather than a fixture directory, an isolated HOME per run, a mandatory --agent so Vibe cannot fall back to auto-approve, and a run manifest - and why it was not built: no provider credentials are configured here, so a live run cannot be verified, and the Vibe adapter is the standing lesson about writing against unverified documentation.

2026-08-23 - Let the gate refuse first, even when approval already exists

Author: GitHub Copilot

instructions/gates.md gains one rule: run publish without --yes first, let the Mass-Update Gate refuse, then re-run. Approval that arrived earlier in the conversation is not a licence to pass --yes on the first attempt.

This is the first change made because a trace showed something. eval score flagged gate-not-self-opened on two consecutive sessions - the one that shipped the telemetry layer and the one that shipped the scorer. Both times the file list had been shown and approved; both times --yes went out on the first attempt, so the gate never spoke. A trace records tool calls, not conversations, which makes that indistinguishable from an agent waving a gate through on its own.

Two occurrences of one shape is a pattern, not an incident, so it warranted a decision rather than an explanation. The options were to soften the rule, to give the rule a way to see approval (an --approved-by flag - but a flag an agent can set itself is a weaker check than the one it replaces), or to change the procedure. The procedure changed: the outcome is identical, the record is not, and the cost is one refused call.

The check that found it stays exactly as it was.

2026-08-23 - `wikitool eval`: scoring a session against what it left behind

Author: GitHub Copilot

eval score turns a trace into a scorecard, and eval sessions lists what there is to score. Both are read-only and exempt from the Iteration Budget Gate, for the same reason search is: reading back what a session did is not iteration on the wiki, and charging for it would discourage checking one's own work.

Two levels, both hard-oracle:

L1, structure re-runs lint's checks in-process. The definition of a hard error moved out of lint_command into HARD_ERROR_KEYS, so the scorecard and lint --fail-on-error cannot drift apart - a run must never pass its score while lint refuses it.
L2, trajectory checks three rules over the trace. Each restates an invariant the code cannot enforce in-process: refusal-not-retried, gate-not-self-opened, content-change-logged. A gate can refuse a call, but nothing stops an agent from calling again with the gate's own flag - that gap is what a trajectory check closes.

The rules were not invented from the contract text. Each one corresponds to a refusal an agent can talk its way around, which is why the gates exist at all. Further rules wait for observed failures; a scorer built ahead of a failure taxonomy improves its own number rather than the behaviour, which is the failure mode commonplace/kb/notes/evaluation-automation-is-phase-gated-by-comprehension.md describes.

Scoring the session that shipped the telemetry layer immediately reported a violation of gate-not-self-opened: publish --yes went out on the first attempt, so the gate never got to refuse anything, even though the file list had been shown and approved in conversation. The finding is true and benign at once - the trace records tool calls, not conversations. It stays an error rather than being softened, because weakening a check to make a known case pass is how a scorecard stops meaning anything. EVALS.md carries the worked example.

Two supporting changes:

Every trace now opens with a session.start naming what its source can report. Mistral Vibe has no session hook, so its traces would otherwise carry no completeness at all and a scorer could not tell "never happened" from "not observable here". The header is written under x mode, which elects a single writer among the processes appending to one trace.
telemetry/reader.py owns reading a trace back - sort order, torn last line, the union of completeness across sources - because a consumer that re-derived those would drift from the writer.

2026-08-23 - Mistral Vibe hooks, verified against the installed CLI

Author: GitHub Copilot

.vibe/hooks.toml declares the three hooks Vibe has - pre_tool, post_tool, post_agent - and .vibe/config.toml puts the telemetry policy in the repository instead of in someone's shell profile.

Vibe is installed here, and it is open source, so neither file was written against the documentation: both were validated with the CLI's own loader (vibe.core.hooks.config._load_hooks_file, VibeConfigSchema), and the committed post_tool command was executed through Vibe's own HookExecutor with a real PostToolInvocation. Four things that changed as a result:

The config shape is an array of tables, [[hooks]] with a unique name, not a table per event type as the research summary suggested.
A failing hook cannot block anything. With strict = false - the default - a crash or timeout is a no-op warning. This is the mirror image of Copilot, where a preToolUse hook is fail-closed and a missing interpreter would deny every tool call. strict and match are rejected on post_agent.
post_agent carries no response text, only the session context, so it maps to turn.end rather than to assistant.message.
enable_telemetry defaults to true. Setting it false is a real change, not a restatement of the default. It also gates OTel: vibe/core/tracing.py exports only when enable_telemetry and enable_otel. Both are off here, because enable_otel ships prompts and tool arguments to Mistral Studio and Mistral documents no way to point it at a collector you run yourself.

Also confirmed from the source: Vibe already reads .agents/skills/ and AGENTS.md, so the directory wikitool instructions sync publishes is a project-scope skill source for it. This repository needs no adaptation to be worked on with Vibe beyond trusting the folder.

A new test parses every committed hook config - JSON for Copilot, TOML for Vibe - and asserts that each --event names an event that exists. A typo there would otherwise produce a silent gap in a trace that nothing else would notice.

2026-08-23 - Copilot CLI hooks and the chronicle importer

Author: GitHub Copilot

The trace layer now has two sources besides wikitool itself.

.github/hooks/wiki-trace.json wires eleven Copilot CLI hook events into tools/trace_ingest.py. It is committed, so a clone brings its own telemetry; disableAllHooks opts out without deleting anything. Two details in it are load-bearing:

Every command ends in || true. preToolUse hooks are fail-closed: a non-zero exit denies the tool call. Without the guard a missing interpreter would turn the observer into a blocker that refuses every tool call in the session. Verified by running the committed command with PATH=/nonexistent.
The event name is passed explicitly. Copilot serves two payload dialects - camelCase event names give camelCase fields, PascalCase names give the VS Code/Claude snake_case shape - so --event keeps the mapping independent of which one a config picked. Both spellings are mapped either way.

tools/import_chronicle.py reconstructs a trace from a chronicle store (session-store.db, shared schema between VS Code Chat and Copilot CLI) for the surface that has no hooks at all. The store is opened read-only, the import is idempotent unless --force, and the original timestamps are preserved rather than replaced by import time - write_event gained a ts parameter for that.

Reconstruction is honest about its limits: those events carry reconstructed: true, and the completeness list for vscode-chat names tool.post but not tool.pre, because the store records that a file was touched, not that a tool was about to run. Ordering follows the store's own timestamps, which puts a touched file after the reply of its turn; reordering it would invent a sequence nobody wrote down.

Two events joined the vocabulary. turn.end replaces the awkward use of assistant.message for Copilot's agentStop and Vibe's post_agent, which mark the end of a turn and do not always carry text. session.error covers Copilot's errorOccurred, which can fire for a model call or the system rather than for a tool.

2026-08-23 - Session traces: the telemetry layer under the eval harness

Author: GitHub Copilot

wikitool now records what a session did. Every command appends a wikitool.call event to reports/telemetry/<session>/trace.jsonl, and both gates record the moment they refuse. tools/trace_ingest.py accepts a hook payload from Claude Code, Copilot CLI or Mistral Vibe and normalises it into the same vocabulary.

The unit tests check the compiler; nothing checked the agent. Scoring a trajectory - did new precede the write, was a refused gate simply retried - needs a record of the trajectory, and that record has to survive a change of harness. So the design puts the truth in the layer nobody can swap out: the repo's own tool. Hooks enrich a trace, they do not constitute it.

Three design points worth knowing:

Hooks call tools/trace_ingest.py, never wikitool. A hook fires on every tool call, and every wikitool invocation is counted by the Iteration Budget Gate - routing telemetry through the CLI would let the act of observing a session end it. The script imports wiki_tools.telemetry as a library, which is stdlib-only for the same reason: a hook must run without the venv.
The trace records what the budget exempts. Read-only retrieval is not charged, but it is traced: what an agent looked at before acting is exactly what a trajectory scorer needs.
The core event set is what the weakest harness can produce. Claude Code has ~30 hooks, Mistral Vibe has three. Every session.start carries a completeness list, so a scorer says "not measurable here" instead of silently scoring zero.

Prompts and assistant replies are recorded in cleartext, locally, because a failure taxonomy cannot be read out of hashes. Guards: secret scrubbing, a 60 KiB cap, WIKI_TRACE_CONTENT=0, and the rule that raw/ file contents never enter a trace at all. reports/ stays gitignored and no exporter is configured.

Also added: /EVALS.md, the human-facing hub for the whole thing, registered in the AGENTS.md file-naming table. reports/CONTRACT.md gained a Traces section. wiki_tools/session.py now holds the single definition of session identity, which run_budget and the emitter share.

2026-08-23 - `lint` detects contested raw-file ownership

Author: GitHub Copilot

New hard check duplicate_raw_file_owners: a raw file named in more than one source page's raw_files:.

uncovered_raw_files only ever asked whether a raw file is claimed at all, so the opposite failure was invisible. It had already happened: one ingested manual 10-bootstrap-manual/ subtree carried two incompatible cuts at once, leaving eight raw files claimed by two pages each, undetected until someone counted by hand.

The rule it enforces is the one recorded in types/source.md: raw_files: is a maintenance claim, ^[[Source - X]] citation is free reuse. Any number of pages may cite a source; with two owners it is undefined which page must be refreshed when the raw file changes, so both rot silently and neither is identifiably the stale one.

Repeats inside a single page's own list are untidy, not contested - there is still exactly one owner - so they are not reported.

2026-08-23 - Workshop layer `work/`; tree ingests; `## Not Extracted`

Author: GitHub Copilot

A tree like raw/documents/handbook/ (71 files) does not fit in one ingest, and the wiki had no place to keep a run that spans sessions. Four changes.

`work/` - a tracked, transient workshop layer

New stage beside kb/, with work/CONTRACT.md. One directory per run, holding the plan and the intermediate extracts on the way to a kb/ page, deleted when the run closes.

It is the mirror image of reports/: a report is recomputable and therefore gitignored, a workshop is judgment in progress that nothing can re-derive and is therefore tracked. A gitignored workshop would be a reports/ directory with extra steps - the whole point is that a multi-day run survives.

work/ joins raw/ and kb/ in CONTENT_DIRS and in the .gitignore backstop: an ignore rule reaching it is a data-loss bug, and docs verify now carries a canary that says so.

Run keys are derived, and a collision is an error

wikitool work new --input raw/documents/handbook creates work/ingest-documents-handbook/. The key comes from the input path below raw/ with separators flattened - not the basename, because raw/documents/handbook and raw/articles/handbook would collide.

The directory name is the run key. No second identifier, for the same reason a page title is a page's only identifier (invariant 2). A collision is refused rather than suffixed: it means the tree is already being ingested, which is the condition the key exists to detect. A genuine re-ingest is --again, which dates the key.

wikitool work close --run-key <name> --yes deletes a finished run, listing what would be lost first.

The Mass-Update Gate stops counting `work/`

publish still commits and pushes workshop files, but they no longer count toward the threshold. The gate's justification is that a push publishes knowledge irreversibly; a directory that is deleted on closure is not that, and making a reviewer approve twelve scratch files is exactly the review fatigue the threshold exists to avoid.

GATE_EXEMPT_PREFIXES is a constant, deliberately not a flag - a --gate-exempt option would be a gate an agent could open on its own initiative. The refusal message now reports both counts.

Tree ingests, and recording what was not extracted

instructions/ingest-large-tree.md (a flat instruction, not a published skill - it runs rarely, so it earns a link rather than a permanent slot in every session's context) cuts a tree into units before anything is written, then reads, promotes and publishes one unit at a time through a workshop. Triggers: more than ~20 raw files, or a source page that would carry more than ~15 raw_files: entries. A third tier adds an audit pass for units covering secrets, RBAC, ingress or disaster recovery.

Each unit takes its own WIKITOOL_SESSION_ID, derived from the run key (<runkey>/u<N>), so the budget is scoped to the unit rather than to the whole run. instructions/gates.md now states the matching rule: a new session id may only be taken at a unit boundary written down in plan.md, never in response to a gate refusal. The plan is the human approval the gate would otherwise have to ask for.

types/source.md gains a ## Not Extracted section: what was read and deliberately not promoted, with the reason. sources coverage can only answer whether a raw file is named by some source page, never whether anyone decided what to do with it - so without this, every later pass re-litigates the same source.

`README.md` and `CONTRACT.md` are both allowed, and kept apart

The naming rule said README.md was repo-root only. It is now explicit that a stage may carry both: README.md is technical documentation for humans and for developing the thing in that directory, CONTRACT.md is the agent-facing contract for using it. What a stage may not carry is the same content twice.

tools/README.md returns under that rule, rewritten as developer documentation - layout, how to add a command, design notes, how to run the tests - with no command table. The untracked file previously sitting there was a leftover copy of the document that became tools/CONTRACT.md in 35d5df8, and had already drifted (no search, no work, old gate wording).

To stop that recurring, docs verify's command-table guard was generalized from the root README to every README (check_readmes_have_no_command_table). The guard existed because this exact drift happened once; allowing stage READMEs without widening it would have re-created the bug.

Found while verifying

Running the new procedure against an already-ingested tree reproduced 5 of 7 existing units exactly and surfaced one defect: 8 raw files under 10-bootstrap-manual/ are covered by two source pages each - an 18-file umbrella page and seven per-step pages, two incompatible cuts applied at different times. Recorded as a DECISION NEEDED in work/ingest-documents-handbook/; retiring either side is a page-lifecycle operation, not part of this change.

2026-08-22 - Retrieval instead of catalog reading; one instruction layer; `CONTRACT.md` naming

Author: GitHub Copilot

Four changes, all aimed at the same problem: the routing layer had grown redundant, and finding anything meant reading everything.

`wikitool search`

New command. Text search runs through a pluggable backend (rg today, behind a SearchBackend protocol with Reciprocal Rank Fusion already in place, so a vector backend is a new module rather than a rewrite). Frontmatter predicates - --field entity_type=system, --field 'confidence>=0.8', --field tags=k8s, --field '!source_url' - are evaluated in-process on the parsed YAML, and work with or without a text query.

The query is passed as an argv element and --fixed-strings is the default, so a search term is never a shell command and never an accidental regex. An unknown field name fails with the list of fields that do exist, rather than returning an empty result that reads as "no such pages".

search is exempt from the Iteration Budget Gate: retrieval is reading, not iterating, and charging for it would tax the one habit that lowers token cost.

The catalog is sharded

kb/index.md was one flat file listing all 243 pages with summaries - roughly 12-14k tokens to read, which wiki-query did on every question. It is now a map: statistics, one row per collection and per area, and a link to the shard that lists those pages (50 lines). The tables live in a generated kb/<collection>/INDEX.md, and an area past 50 rows gets its own - kb/entities/tools/INDEX.md split out immediately at 56. The threshold comes from the wiki's own Index Scaling page, so growth is handled by arithmetic rather than by a judgment call. Stale shards are swept on every rebuild.

`instructions/`, and skills published by copy

New top-level directory: the single source for everything an agent is told to do. Two forms, told apart structurally - a subdirectory with a SKILL.md is published into the harness directories, a flat .md never is. That split is what keeps a rarely-used procedure from occupying context for a whole session.

The five skills moved from .agents/skills/ into instructions/. Four shared fragments were extracted from the places that had been repeating them: gates.md (was restated in 7 places), page-lifecycle.md (6), session-setup.md (4), publish-cycle.md (4), plus bootstrap.md.

wikitool skills sync|verify became wikitool instructions sync|verify|list, and publication now copies instead of symlinking. This reverses the earlier decision recorded in that module: symlinks cannot go stale, but they are unreliable on Windows checkouts and do not survive being archived or copied. The price of a copy is drift, so verify compares every copy byte for byte against its source. Both .agents/skills/ and .claude/skills/ are now gitignored build output; a fresh clone publishes them once via instructions/bootstrap.md.

verify also reports an instruction that nothing references - an instruction nothing loads is inert, and nothing else in the stack would ever say so.

New instruction type-spec, with a new optional placement field root: on type-specs (kb by default, repo to opt out). Without it a type outside kb/ could only be contract-only; with it, wikitool new instruction scaffolds correctly.

`CONTRACT.md` for agents, `README.md` for humans

A file's name now says who it is for. raw/README.md, reports/README.md and tools/README.md became CONTRACT.md; kb/CONVENTIONS.md became kb/CONTRACT.md and absorbed kb/README.md, which is gone. README.md now exists only at the repo root, for humans.

Twelve rules that had been stated in two to seven places each were reduced to one canonical location apiece, with links elsewhere. This is now AGENTS.md invariant 8 ("one rule, one place"). It is deliberately not machine-checked: prose duplication is a judgment call, so wiki-lint gained a review step for it instead of docs verify gaining a validator.

Also fixed: docs verify said COLLECTION.md placement had two rules while kb/README.md said three; runs on was recommended by the entities contract but missing from the canonical label list; AGENTS.md implied budget reset was the way past the Iteration Budget Gate, when reset is itself counted and refused at the limit.

2026-08-21 - Collections under a single `kb/` root; the repo becomes a four-stage pipeline

Author: GitHub Copilot

The wiki layer was a single wiki/ directory with one contract covering five subdirectories. It is now kb/, a namespace whose children are first-class collections, each with its own COLLECTION.md. The structural rule is now enforced rather than described:

A directory under kb/ is a collection exactly when it contains a COLLECTION.md. A subdirectory inside one is an area and inherits it. COLLECTION.md appears nowhere outside kb/.

Layout. wiki/ -> kb/, with entities/, concepts/, sources/ and comparisons/ each gaining a contract. wiki/COLLECTION.md split into kb/CONVENTIONS.md (the cross-collection half: naming, tone, linking, provenance, confidence) and the four per-collection contracts (types offered, what belongs, outbound linking, per-area emphasis). Added kb/README.md for routing.

raw/ stayed at the repo root rather than moving to kb/raw/. It has no types, frontmatter, wikilinks, provenance or confidence, so none of kb/CONVENTIONS.md applies to it; keeping it a sibling makes the trust boundary structural instead of documented, and leaves every raw_files: reference in every source page valid. raw/COLLECTION.md -> raw/README.md.

types/ stayed at the repo root as the global type surface and lost its COLLECTION.md; the content folded into types/type-spec.md, which now also documents placement frontmatter, adding a type, and the template filters. A type-spec is not a collection contract, and docs verify now fails if one appears there.

Lint reports left the wiki. types/lint-report.md dropped its base_dir: and is now contract-only, so wikitool new lint-report refuses to scaffold one. lint --markdown writes to a new gitignored reports/. A report's structural half is recomputable from the tree at any commit, so committing it created a second copy that could drift; the semantic review, which is not recomputable, now has to be carried into kb/log.md via log append --op lint before a pass ends. index.md no longer has a Lint Reports section, and lint no longer carries per-type exemptions for reports.

Tooling. repo_scan.py -> kb_scan.py; iter_wiki_files/load_pages -> iter_kb_pages/load_kb_pages; config.WIKI_DIR -> config.KB_DIR, plus REPORTS_DIR and PROVENANCE_FILE. The scanner now excludes COLLECTION.md at any depth, since contracts sit one level below the kb root where the meta-file guard does not reach. New kb_collections.py discovers collections from the filesystem, so mkdir kb/<name> + a contract adds one with no code change. docs verify replaced its hardcoded ("raw","wiki","types") list with that discovery and gained three checks: an unclaimed directory under kb/, a nested contract, and a contract outside kb/. Its .gitignore canaries now run in both directions - nothing ignored under raw//kb/, everything ignored under reports/ except its README.

AGENTS.md routing was rewritten from a flat "by layer" table into the pipeline diagram plus the two collection rules, then by stage -> by collection -> by task -> by question, with an explicit statement that page placement follows base_dir: and is never an agent's choice, and a two-line "adding a collection" recipe.

Verification: 208 tests pass (13 new, covering collection discovery, scanner exclusions and contract-only types). lint is identical to the pre-move baseline: 243 pages, zero findings.

Fixed while publishing the above: wikitool publish pushed the ref named --branch (default main) rather than the commit it had just made. Run from a feature branch, git push origin main pushed an unrelated, unchanged ref, exited 0, and the command reported "Published changes to origin/main" while the new commit stayed local - the same class of silent non-publication that the .gitignore canaries exist to prevent. publish now refuses to push when the checked-out branch differs from --branch, naming both and suggesting --branch <current>, and it checks this before staging so a refusal leaves the working tree untouched. Covered by two regression tests.

Known gap, not fixed: at exactly the iteration limit, budget reset --yes is itself refused, because reset is deliberately excluded from the exemption list (SKIP_COMMAND_PATHS) so an agent cannot step around the gate by resetting first. The consequence is that the only way out is --override-budget, while AGENTS.md's "Gates" section reads as though reset were available at that point. The behaviour is intentional; the documentation is what misleads.

Entries

Date	Change	Author
2026-08-13	Review remediation: ignore-rule and reference-integrity holes closed, page mutations given commands. Two defects let the stack report itself healthier than it was. (1) `.gitignore` carried unanchored patterns (`temp`, `scratch`, `.log`, `go.mod`, `bin/`, `core`, `tags`) that silently excluded content: `raw/notes/temperature-sensors.md` was gitignored, so `sources coverage` would call it covered while `publish`'s `git add -A` never committed it and a fresh clone got a broken `raw_files:` reference. Every repo-local pattern is now anchored to the root, the content-swallowing ones are gone, and a `!raw/`/`!wiki/` backstop closes the rest; `docs verify` gained `check_ignored_content()`, which reports both actually-ignored files under `raw/`/`wiki/` and ten latent canary paths via `git check-ignore --no-index`. (2) `lint`'s broken-link scan only walked page bodies, so `related:`/`sources:`/`entities:`/`concepts:` entries naming a non-existent page passed every check - 40 of them existed while lint reported zero findings, including a URL pasted into `sources:` and four pages citing a source title with a stray `.md` suffix the page does not carry. New `dangling_frontmatter_refs` hard-error check; which fields hold page titles is declared by each type-spec's new `page_ref_fields:` frontmatter (read via `TypeResolver.get_page_ref_fields`) rather than hardcoded, so a new type needs no code change. Both defects were reachable because renaming and deleting a page had no command: added `wikitool rename` (repoints body wikilinks, `^[[Title]]` citation markers with aliases/anchors preserved, the page's own H1, and every declared ref array; a `--from` that is not a page repoints references onto an existing `--to` instead of moving anything), `wikitool rm` (refuses while inbound references exist unless `--yes`, strips mechanical links, deliberately leaves prose citations and reports them), and `wikitool xref remove` (inverse of both `xref add` and `xref link-source`; `--b` need not exist, which is what lets a stale reference be cleared without hand-editing frontmatter). `log append` accepts `--op rename`. All 40 dangling references were then cleaned up: 19 repointed onto existing pages, 21 removed as retired or never-created. Also: the `lint_report` pseudo-type - written by `lint --markdown`, special-cased in three places, documented nowhere - became a real `types/lint-report.md` + schema with `base_dir: reports`, so reports live under `wiki/reports/` and are schema-validated like any other page; `budget reset` is no longer exempt from the Iteration Budget Gate and now requires `--yes` of its own (exempting the command that clears the counter made the gate a formality, while `budget status` stays exempt so the situation remains reportable); `skills sync` refuses to `rmtree` a `.claude/skills/` entry that is a real directory unless `--force`; `index_build` no longer hardcodes `types/entity.md`; the root README's duplicate command table, maintenance schedule, and entity-type directory table were replaced with pointers, with a new `docs verify` check enforcing that the command table stays absent there; `wiki/COLLECTION.md` dropped the directory column the type-specs own; and `wiki-lint` now writes its report after* the fixes rather than before, so it records the wiki's final state. Test suite 139 -> 182.	GitHub Copilot
2026-08-13	Tooling correctness + control-plane restructure. Fixed `confidence decay` compounding on every run: `confidence` is now derived from a new undecayed `confidence_base` field (added to the entity/concept schemas, backfilled across 204 pages by the new `confidence init-base` command), so repeated runs are idempotent - the previous "never double-decays" claim in AGENTS.md/READMEs was false. Added `wikitool touch` (bump `modified:`/`summary:`/`provenance:`/`confidence_base` through the tool instead of by hand, schema-validating the fields it writes) and `wikitool docs verify` (checks every CLI command is documented in tools/README and vice versa, that each collection has a `COLLECTION.md`, and that no pre-migration `type: <enum>` block survives in the contracts). `lint` gained a hard-error check for unreadable/missing frontmatter - previously such pages silently read back as `{}` and escaped every other check - plus `most_linked`/`inbound_counts` output, which `wiki-status` had been documented to read but which the report never contained. `publish` now evaluates the Mass-Update Gate before staging, parses `git status --porcelain -z -uall` (fixing renames and paths with spaces), and takes `--remote`/`--branch`/`--path` (the last scoping gate count, staging and commit to a subtree, so a large change can be published in reviewable batches). Budget gate: refused calls are no longer counted, `--help` anywhere in argv is exempt, stale sessions are pruned from the state file, and `budget status` reports whether the session key came from `WIKITOOL_SESSION_ID` or the pid fallback. Restructured the 648-line AGENTS.md into a ~140-line control plane (invariants, routing, gates, error model) plus per-layer contracts `raw/COLLECTION.md`, `wiki/COLLECTION.md`, `types/COLLECTION.md`, moving the per-command error contracts and maintenance schedule into tools/README.md; deleted the stale `type: comparison` template, the schema-duplicating field tables, and the pseudo-command reference. All five skills now export `WIKITOOL_SESSION_ID`, call `touch` instead of hand-editing frontmatter, and treat `raw/` content as untrusted data. Added tests for decay idempotence, frontmatter errors, porcelain parsing, budget hardening, `touch`, `docs verify`, and `skills sync` (139 total).	GitHub Copilot
2026-08-08	Made `wikitool new`'s scaffolding fully schema-driven instead of hand-duplicating the type-specs: added `TypeResolver.get_enum()`/`get_schema()`, removed `config.py`'s hardcoded `ENTITY_TYPES`/`CONCEPT_TYPES`/`PROVENANCE_VALUES` (enum validity and CLI `--help` text now read from each type's `.schema.yaml`), replaced each `new_*` command's hand-built frontmatter dict with a generic schema-driven builder, and extended `_apply_template_variables` with `\|bullets`/`\|join`/`\|capitalize` filters so type-spec templates reference frontmatter fields directly instead of each command precomputing bespoke display variables. Also consolidated `lint`'s two overlapping missing-field checks into one: removed the hand-maintained `REQUIRED_FIELDS`/`schema_issues`, relying solely on the resolver-based `schema_validation_errors`. Directory placement (`ENTITY_SUBDIRS`) stays in `config.py` as wiki layout, not type structure.	GitHub Copilot
2026-08-08	Removed the now-unused legacy bare-enum `type:` compatibility shims left over from the type-system migration below (`Page.kind`'s `entity`/`concept`/`source`/`comparison` fallback entries, and `lint`'s duplicate `REQUIRED_FIELDS` keys) since all 238 wiki pages have used path-based `type: types/entity.md` references since that migration; only the current path-based form is recognized now.	GitHub Copilot
2026-08-08	Major: Transformed to Commonplace-style externalized type system. Created `/types/` directory with type-spec files (`entity.md`, `concept.md`, `source.md`, `comparison.md`, `type-spec.md`) and corresponding `.schema.yaml` files for structural validation. Rewrote `wikitool new` commands to use type-spec templates instead of hardcoded templates. Migrated all 238 wiki pages from enum-style type references (`type: entity`) to path-based references (`type: types/entity.md`). Created `type_resolver.py` module for path resolution, caching, and schema validation. Extended `lint` with type path validation and schema validation checks. Updated AGENTS.md Type System section, Architecture diagrams, and skill files.	Mistral Vibe
2026-08-07	Introduced this `CHANGES.md`. Removed the inline "Version History" sections from `AGENTS.md` and `README.md` (and confirmed no skill file under `.agents/skills/` had one); both now point here instead.	GitHub Copilot
2026-08-07	Added "Iteration and Cost Limits" section to `AGENTS.md` and a code-enforced `tools/wikitool` Iteration Budget Gate + Loop-Breaker (new `budget status`/`budget reset` commands, `--override-budget` flag): every `wikitool` call is checked against a 30-call/session ceiling and refuses 3x-identical repeats, mirroring the Mass-Update Gate pattern but scoped to iteration volume instead of publish size.	GitHub Copilot
2026-08-06	Added "Tool Error Contracts" section to `AGENTS.md`: a general 3-outcome model (success / expected validation error / unexpected error) plus a per-command table covering every `wikitool` command's exit-1 meaning, atomicity, retry policy, and escalation path. Added `--dry-run` to `xref add`/`xref link-source` and made `xref link-source` report partial failures instead of aborting silently mid-loop.	GitHub Copilot
2026-08-05	Documented the skills-based workflow split, the full `wikitool` command set, and a dedicated Maintenance section (schedule, confidence decay, provenance) in `README.md`.	GitHub Copilot
2026-08-04	Split the 5 step-by-step workflows into independently-discoverable skills under `.agents/skills/` (`wiki-ingest`, `wiki-query`, `wiki-lint`, `wiki-manage`, `wiki-status`), mirrored to `.claude/skills/` for Claude Code via new `tools/wikitool skills sync`/`skills verify` commands. Slimmed root `AGENTS.md` to schema/policy only.	GitHub Copilot
2026-08-02	Added "Provenance and Citation" section to `AGENTS.md`: `raw_files:` (replacing `source:`) on source pages, `provenance:` field on entity/concept pages, inline `^[[Source - X]]` citation markers, and the generated `wiki/provenance.md` reverse index. Added `tools/wikitool sources coverage\|trace\|rebuild-index` commands and 4 new `lint` checks. Updated all workflows and page templates accordingly, and added the "no confident answer without a source" rule.	GitHub Copilot
2026-08-02	Added `tools/wikitool` deterministic CLI and a new "Tooling" section to `AGENTS.md` mandating its use for scaffolding, cross-references, index rebuilds, log entries, confidence decay, and publishing. Rewrote INGEST/CREATE/UPDATE/LINT workflow steps and Git Automation to call it instead of describing manual edits. Added `summary:` frontmatter field to all page templates.	GitHub Copilot
2026-08-02	Added Git Automation: all workflows now automatically commit and push changes to `origin/main` without user confirmation. Added auto-commit/push step to INGEST and CREATE workflows.	Mistral Vibe
2026-07-26	Updated naming conventions: changed from kebab-case to human-readable titles with spaces (e.g., `Hybrid Search.md` instead of `hybrid-search.md`). Wikilinks now match file names exactly: `[[Hybrid Search]]` links to `Hybrid Search.md`. Updated all page templates to use spaced names in wikilinks.	Mistral Vibe
2026-07-25	Initial schema/scaffold created for the IT-focused LLM Wiki.	Mistral Vibe

273 KiB Raw Blame History

Changelog

4.8.0-beta.5 - 2026-09-05 - update entity naming conventions to use singular form for consistency

4.7.4 - 2026-09-04 - bootstrap.md nennt den session-id-WARN nach frischem Bootstrap explizit als erwartet

4.7.3 - 2026-09-04 - eval: gate-not-self-opened prueft REMOVED_FLAGS gegen das eigene Kommando

4.7.2 - 2026-09-04 - Coverage-Untergrenze bei 85 %, gegen beobachtete 87,0 %

4.7.1 - 2026-09-04 - redundant_see_also in tools/CONTRACT.md und wiki-lint dokumentiert; xref-remove-Falle benannt

4.7.0 - 2026-09-04 - Link-Katalog: authored, alternative-to, addresses; entity→entity-Lineage; Lint-Befund gegen redundante see-also

4.6.1 - 2026-09-04 - DEVELOPMENT.md im Kommandotabellen-Check, selbstbeschriftete Release-Notes, Prosa-Korrekturen (#47 Block 3)

4.6.0 - 2026-09-04 - stack-dev/stack-close skill split, publish stack-machinery note, model-selection fix (#47 Block 2)

4.5.1 - 2026-09-04 - issue-tracking - destructive-step invariants, comment-vs-body authority, rename sweep

4.5.0 - 2026-09-04 - Beide Update-Wege in Code: upstream merge fuer Clones, dist upgrade fuer Tarball-Instanzen

4.4.0 - 2026-09-03 - Versionskandidat statt Bump-pro-Release: VERSION traegt -beta.N, version release fixiert

4.3.3 - 2026-09-03 - Modellwahl nach Pruefbarkeit statt nach Aufgabenname; stack-dev bricht an den Phasenwechseln fuer den Model-Switch

4.3.2 - 2026-09-03 - stack-dev: Issue-Abschluss ist ein nummerierter Schritt, kein Zeiger in einer Routing-Liste

4.3.1 - 2026-09-03 - docs/ befuellt - Stack-Hintergrund fuer vier Themen, Pflegeklausel in AGENTS.md ergaenzt

4.3.0 - 2026-09-03 - docs/ als ausgelieferter Hintergrund-Ort; Decision-Seiten bleiben in kb/, Decay-Skip fuer concept_type: decision

4.2.0 - 2026-09-03 - Korpus-Kuratierungsrichtlinie: Untergrenzen und Leitplanke für reaktive Fixes

4.1.2 - 2026-09-03 - Issue-Abschluss ist ein Body-Rewrite, nicht nur ein Kommentar

4.1.1 - 2026-09-03 - Testisolation: kb_dir repointet config.ROOT, lint löst Kollektionen gegen den übergebenen Baum auf

4.1.0 - 2026-09-03 - Link-Taxonomie: Lint-Findings hart ab kb_version 4.0.0, outbound: an das Type-Spec gebunden, part-of/composition als Inversenpaar

4.0.1 - 2026-09-02 - Issue-Board: vier Pflicht-Label-Familien und Body-als-Wahrheit

4.0.0 - 2026-09-02 - Prosa ist kein Identifier: Link-Taxonomie als Enum, generierte Regionen mit Markern

3.0.0 - 2026-09-02 - Autorenkonventionen nach Eigentum geschnitten: kb/CONVENTIONS.md, deklarierte Collections

2.5.0 - 2026-09-02 - Versionsstelle: Kompatibilitaet statt Inhaltsmigration, Breaking-Change-Vermerk erzwungen

2.4.1 - 2026-09-02 - INSTALL-MCP.md: Menschendoku fuer den Leseserver, und sie wird mit ausgeliefert

2.4.0 - 2026-09-02 - MCP-Leseserver: zweiter Konsument auf demselben Kern

2.3.0 - 2026-09-02 - Bibliotheksgrenze: chemenu laesst sich auf einen Korpus zeigen

2.2.4 - 2026-09-02 - Haertung des Lesepfads: ReDoS, Subprozess-Timeout, YAML-Alias-Budget, Korpus-Cache

2.2.3 - 2026-09-02 - Publish-Remote-Gate in diesem Checkout scharf, doctor benennt den Zustand

2.2.2 - 2026-09-01 - Doku-Verdrahtung: Publish-Remote Gate im Werkzeugvertrag, Projektseite auf oeffentlich

2.2.1 - 2026-09-01 - private-instance: der Demo-Korpus wandert beim Merge doch mit - Prozedur korrigiert

2.2.0 - 2026-09-01 - Publish-Remote Gate: publish schreibt nur an erklaerte Ziele

2.1.1 - 2026-09-01 - raw_dir-Fixture kappt config.ROOT; letzte private Fixture-Namen ersetzt

2.1.0 - 2026-09-01 - Dual-Lizenz AGPL-3.0/CC-BY-4.0, und ein Leak-Canary fuer dist export

2.0.0 - 2026-09-01 - Rebranding zu Chemenu: Repo, Produktname und Python-Paket

1.8.1 - 2026-08-31 - Coverage-Reporting in CI: messen und als Artefakt ausweisen, ohne Schwelle

1.8.0 - 2026-08-31 - ENVIRONMENT.md: optionale, checkout-spezifische Umgebungsnotiz

1.7.2 - 2026-08-31 - lint liest Code nicht mehr als Wiki-Notation; Zitat-Limit zählt Zitate statt Zeilen

1.7.1 - 2026-08-31 - Testsuite gegen stille Umgebungsabhängigkeiten gehärtet

1.7.0 - 2026-08-31 - CLAUDE.md as a harness-scoped instruction reference; Claude-Code model-selection guidance

1.6.0 - 2026-08-31 - xref link-source schreibt beide Richtungen; xref add lehnt undeklarierte Ref-Felder ab

xref link-source schreibt jetzt beide Richtungen

xref add lehnt ein nicht deklariertes related: ab

xref remove räumt auch undeklarierte Reste

Bestandsfall repariert, mit dem Werkzeug

Sonst

1.5.1 - 2026-08-31 - cite add/sync und rename loeschen keinen Inhalt mehr hinter dem Fussnoten-Block

Der Fix

Korpus repariert

Tests

1.5.0 - 2026-08-31 - Mass-Update Gate zaehlt generierte Dateien nicht mehr; Kalibrierungsband gemessen statt geerbt

Generierte Dateien zählen nicht mehr gegen die Schwelle

Kalibrierungsband: 15-25 → 20-35 für komplexe Workflows

1.4.0 - 2026-08-31 - touch --set/--add/--remove: Frontmatter-Felder nach dem Anlegen korrigierbar

Neu an touch

Die Sperrliste, und warum es eine ist

Sonst

Nicht enthalten

1.3.0 - 2026-08-31 - capture-session: eine Session als raw/-Transkripte sichern und ingesten

1.2.1 - 2026-08-31 - Arbeitsplanung: Gitea-Issues mit prio/size-Labels statt TODO.md

1.2.0 - 2026-08-31 - --set-Arraywerte mit Komma, Lint-Reportpfad, Budget-Refund, Ceiling 60

--set kann Kommas in Arraywerten ausdrücken (#12)

Iteration Budget: Reibung statt Iteration wurde gezählt (#13)

lint nennt seinen Reportpfad (#13)

Nicht enthalten

1.1.1 - 2026-08-30 - CLAUDE.md: AGENTS.md/USER.md/SOUL.md erreichen Claude Code

1.1.0 - 2026-08-30 - Personalization Plane: USER.md/SOUL.md als Setup-Schritt

1.0.1 - 2026-08-30 - Tests ohne globale git-Identität; CI-Fixes

1.0.0 - 2026-08-30 - Content migrations get a version, a chain, and a mechanical check

0.1.0 - 2026-08-29 - The stack gets a version, a pipeline, and release files

2026-08-29 - Human docs catch up, and a new instance is asked which language it wants

2026-08-29 - The corpus is German; the glossary outlives the run

2026-08-29 - Two frontmatter fields no command can write

2026-08-29 - Date fields hold dates, and the special case disappears

2026-08-29 - The round-trip guard reached date fields it should not have

2026-08-29 - Frontmatter round-trip turned string values into other YAML types

2026-08-29 - work new --key for a run that is not an ingest

2026-08-28 - Two bugs the translation sample run surfaced

2026-08-28 - Section headings become a named vocabulary instead of hardcoded English literals

273 KiB

Raw Blame History

`xref link-source` schreibt jetzt beide Richtungen

`xref add` lehnt ein nicht deklariertes `related:` ab

`xref remove` räumt auch undeklarierte Reste

Neu an `touch`

`--set` kann Kommas in Arraywerten ausdrücken (#12)

`lint` nennt seinen Reportpfad (#13)

2026-08-29 - `work new --key` for a run that is not an ingest

2026-08-28 - Mass-Update Gate: `--yes` retired for an exit-42 clearance code and `--confirm <token>`

2026-08-26 - One-way dev/dist split: `instructions/dev/`, `stack-dev` skill; `dist enable-dev` retired

2026-08-25 - Citation syntax migrated to real GFM footnotes; `wikitool cite`

2026-08-25 - Distributable instances: `dist export`/`dist enable-dev`, `doctor`, per-instance author

2026-08-23 - `wikitool eval`: scoring a session against what it left behind

2026-08-23 - `lint` detects contested raw-file ownership

2026-08-23 - Workshop layer `work/`; tree ingests; `## Not Extracted`

`work/` - a tracked, transient workshop layer

The Mass-Update Gate stops counting `work/`

`README.md` and `CONTRACT.md` are both allowed, and kept apart

2026-08-22 - Retrieval instead of catalog reading; one instruction layer; `CONTRACT.md` naming

`wikitool search`

`instructions/`, and skills published by copy

`CONTRACT.md` for agents, `README.md` for humans

2026-08-21 - Collections under a single `kb/` root; the repo becomes a four-stage pipeline