@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-009-umbenennung-leitwerk.md

@@ -0,0 +1,77 @@
+# Änderungsantrag `CR-2026-009`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Das Framework heißt Leitwerk; das Kernverzeichnis heißt `leitwerk-core/` |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | Verzeichnis `devin-core-framework/` → `leitwerk-core/`; 182 Dateien mit Pfad- oder Namensnennungen; `README.md`, `build/doc/00-kopf.md`, `build/build-docx.py`, `install.py`, `.gitignore`, `governance/RELEASE_PROCESS.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Struktur) |
+| Art | Änderung |
+| Dringlichkeit | regulär (Review-Zyklus); vor 1.0.0 durchzuführen |
+
+## 1. Anlass und Problem
+
+Seit `CR-2026-005` ist der Kern inhaltlich werkzeugneutral: Er bezeichnet die Bestandteile der Laufzeitschicht mit Begriffen statt mit Pfaden, und die Abbildung auf einen konkreten Client leistet ein Client Pack. Seit `CR-2026-008` gilt das auch für die Berechtigungs- und Hook-Regeln.
+
+Der **Name** ist dieser Entwicklung nicht gefolgt. Er trug den Produktnamen eines einzelnen Clients an drei Stellen:
+
+| Stelle | Bisher | Vorkommen |
+|---|---|---|
+| Kernverzeichnis | `devin-core-framework/` | 994 |
+| Repository und Projektverzeichnis | `devin-desktop-framework` | – |
+| Eigenname in Prosa und Erzeugnissen | „Devin Desktop Framework" | 6 |
+
+Das ist mehr als eine Schönheitsfrage. Ein Projekt, das `claude-code` installiert, liest durchgehend einen Pfad, der den Namen eines Werkzeugs nennt, das dort nicht im Einsatz ist – und dieselbe Beobachtung hatte bereits `CR-2026-005` ausgelöst. Die Roadmap führte die Umbenennung deshalb seit 0.5.0 als P3.
+
+## 2. Vorgeschlagene Änderung
+
+**Der Name ist `Leitwerk`.** Ein Leitwerk fliegt das Flugzeug nicht – es hält es stabil und auf Kurs. Das trifft die Selbstbeschreibung des Frameworks genauer als ein Regelbegriff: Es schreibt nicht vor, wie Software entsteht, sondern hält den Prozess in einer Spur, die prüfbar, nachvollziehbar und übertragbar bleibt. Der Name ist zudem herstellerneutral, kurz und im Repository eindeutig.
+
+| Ebene | Neu |
+|---|---|
+| Kernverzeichnis | `leitwerk-core/` |
+| Repository und Projektverzeichnis | `leitwerk` |
+| Eigenname | Leitwerk |
+| Titel des Hauptdokuments | „Leitwerk – Framework für den professionellen Einsatz von KI-Codierassistenten in Softwareentwicklungsteams" |
+
+**Nicht betroffen** und ausdrücklich unverändert: das Client Pack `devin-desktop` (59 Nennungen), die Laufzeitschicht `.devin/` (250 Nennungen) und alle Produktnennungen „Devin Desktop", „Devin Local", „Devin Cloud" dort, wo tatsächlich der Client gemeint ist. Sie benennen einen realen Client korrekt.
+
+**Ein Nebeneffekt, der zur Sache gehört:** Der längste relative Pfad sinkt von 110 auf 103 Zeichen. Unter `MAX_PATH` (260) bleiben damit rund 156 statt 149 Zeichen für den Projektpfad – die Einschränkung, die `CR-2026-003` bei einer Testinstallation unter Windows zum Scheitern gebracht hatte.
+
+**Klarstellung im Release-Prozess.** Die Umbenennung ist eine brechende Änderung; `RELEASE_PROCESS.md` Punkt 1 verlangt dafür ein MAJOR-Release. Das ist hier nicht möglich, ohne Schaden anzurichten: `1.0.0` ist durch D-11 an fünf prüfbare Kriterien gebunden, von denen keines erfüllt ist. Eine Hauptversion für eine Verzeichnisumbenennung zu verbrauchen, würde diese Kriterien behaupten und das Release-Gate `FW-CL-11` entwerten. Semantic Versioning stellt `0.y.z` ausdrücklich für die Entwicklungsphase frei; der Punkt wird entsprechend ergänzt, damit die Regel nicht künftig erneut kollidiert. Ziel-Release ist **0.7.0** mit Migrationsabschnitt.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja, Core (Struktur). Keine Regel ändert sich inhaltlich.
+- [x] Verschärfungsprinzip eingehalten? — Nicht berührt. Die Regelmenge ist identisch; **nachgewiesen**: Die aus dem Kern erzeugten Kernregeln unterscheiden sich ausschließlich in dem einen Pfadbestandteil, der umbenannt wurde (`Write(leitwerk-core/framework/**)` statt `Write(devin-core-framework/framework/**)`), und dieser Wert stammt aus dem Platzhalter `<CORE_DIR>`, nicht aus einer bearbeiteten Zeile.
+- [x] Widerspruchsfreiheit geprüft? — `FW-KO-04` ist die dafür gebaute Prüfung und meldet gegen beide Installationen **0 Fehler**. Genau diese Absicherung war der Grund, die Umbenennung nicht vor 0.5.0 zu versuchen.
+- [x] Laufzeitfassungen betroffen? — Nur über den Pfad. Installationsumfang unverändert: 80 / 79 Dateien. Die erzeugten Berechtigungs- und Hookdateien tragen den neuen Kernpfad, **ohne dass ein Manifest angefasst wurde** – `<CORE_DIR>` aus `CR-2026-008` hat sich hier zum ersten Mal bewährt.
+- [x] Belegstatus korrekt? — Unverändert. Kein VERIFY-Marker wird berührt.
+- [x] Test- und Validierungsbedarf? — Siehe Abschnitt 5.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — **Ja, hier liegt der Aufwand.** Ein bestehendes Projekt muss das Verzeichnis umbenennen und die Nennungen in seiner Berechtigungsdatei und seinen Overlay-Dokumenten nachziehen. Der Weg ist durchgespielt und im Änderungsverzeichnis als Migrationsabschnitt dokumentiert.
+- [x] Dokumentation? — CHANGELOG, Decision Log, `README.md`, Titelblatt des Hauptdokuments, `RELEASE_PROCESS.md`.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Der Kern ist seit 0.5.0 werkzeugneutral, sein Name war es nicht. Die Umbenennung ist ein Breaking Change und gehört deshalb vor 1.0.0 – abgesichert durch `FW-KO-04`, das eine solche Änderung nachweislich vollständig erfasst. |
+| Ziel-Release | 0.7.0 |
+| Decision-Log-Eintrag | D-19 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] Verzeichnis umbenannt; 994 Pfadnennungen und 6 Namensnennungen in 182 Dateien ersetzt
+- [x] `README.md` und Titelblatt des Hauptdokuments auf den neuen Namen und die Mehrclient-Sicht gebracht
+- [x] `.gitignore`: veralteten Verweis auf `root-template/` im Wurzelverzeichnis korrigiert (liegt seit 0.5.0 je Client Pack)
+- [x] `RELEASE_PROCESS.md` Punkt 1 um die `0.y.z`-Klarstellung ergänzt
+- [x] **`FW-KO-04` gegen beide Installationen: 0 Fehler.** Kein toter Verweis, keine übersehene Nennung; `git grep` nach den drei alten Namensformen ist leer
+- [x] Erstinstallation beider Packs: 80 / 79 Dateien wie zuvor; `--check` fehlerfrei; Dateiliste gegen eine Referenzinstallation abgeglichen und deckungsgleich
+- [x] Erzeugte Artefakte tragen den neuen Kernpfad automatisch: `Write(leitwerk-core/framework/**)` in den Kernregeln beider Packs, `$DEVIN_PROJECT_DIR/leitwerk-core/...` im Hook-Befehl
+- [x] Dokumentbau intakt: alle Einbettungspfade auflösbar, 8.559 Zeilen erzeugt
+- [x] **Migration durchgespielt** an einem Projekt auf Stand 0.6.0 mit eigenen Werten in der Berechtigungsdatei: Nach Umbenennung und `--update` meldet der Validator genau zwei Fehler und benennt die betroffene Kernregel; nach dem Ersetzen der fünf Nennungen 0 Fehler, die Projektwerte unverändert erhalten
+- [ ] **Außerhalb des Repositorys, durch den Owner:** Git-Repository umbenennen, Remote-URL der Arbeitskopien nachziehen, lokales Projektverzeichnis umbenennen
+- [ ] **Folgearbeit:** Der Fließtext des Hauptdokuments (`build/doc/`, Kapitel 1 bis 32) steht weiterhin auf 0.1.0 und ist aus der Sicht eines einzelnen Clients geschrieben. Das Titelblatt weist diesen Stand jetzt ausdrücklich aus; die Einarbeitung ist eigene Arbeit

package/.koolie/core/governance/change-requests/CR-2026-010-restduplikation.md

@@ -0,0 +1,73 @@
+# Änderungsantrag `CR-2026-010`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Restduplikation: Overlay-Laufzeitregel, nutzerlokale Ergänzung und MCP-Vorlage in den Kern |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | neu: `framework/runtime/rules/20-project-overlay.md`, `framework/runtime/root-instruction-local.example.md`, `framework/runtime/mcp-config.example.json`; entfallen: die sechs entsprechenden Dateien in den beiden Client Packs; geändert: `clients/*/manifest.json`, `install.py`, `clients/README.md`, beide `CLIENT_PACK.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Struktur) |
+| Art | Änderung |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+Nach `CR-2026-008` bestand ein Client Pack aus sieben Dateien. Eine Messung der verbliebenen Ähnlichkeit – nach Normalisierung der Client- und Pfadnamen – ergab:
+
+| Dateipaar | Zeilen | abweichend | Befund |
+|---|---|---|---|
+| `20-project-overlay.md` | 119 | 11 | 91 Prozent identisch |
+| `*.local.md.example` | 38 | 8 | 79 Prozent identisch |
+| MCP-Vorlage | 8 | 2 | bis auf zwei Zeilen identisch |
+| Laufzeit-`README.md` | 86 | 64 | **zu Recht getrennt** |
+
+Die ersten drei sind derselbe Fall wie in `CR-2026-007`: Der Inhalt gehört dem Framework, nur Pfad- und Namensnennungen hängen vom Client ab. Die vierte Zeile ist die Gegenprobe – die beiden Laufzeit-READMEs beschreiben tatsächlich verschiedene Mechanismen und bleiben, wo sie sind.
+
+Bemerkenswert an der Untersuchung: **Jede der elf abweichenden Zeilen der Overlay-Regel und jede der acht der nutzerlokalen Ergänzung enthielt ausschließlich Werte, für die bereits ein Laufzeit-Platzhalter registriert ist** (`<RUNTIME_DIR>`, `<ROOT_INSTRUCTION_FILE>`, `<ROOT_INSTRUCTION_LOCAL>`, `<MCP_FILE>`). Es war also keine Abbildung zu erfinden, sondern nur eine bereits vorhandene anzuwenden.
+
+## 2. Vorgeschlagene Änderung
+
+**Drei Quellen im Kern**, alle über die vorhandenen Mechanismen aus `CR-2026-007` installiert:
+
+| Quelle | Ziel | Art | Transformation |
+|---|---|---|---|
+| `framework/runtime/rules/20-project-overlay.md` | `<RULES_DIR>/20-project-overlay.md` | Saat | `render_rule` + Platzhalter |
+| `framework/runtime/root-instruction-local.example.md` | `<ROOT_INSTRUCTION_LOCAL>.example` | Core | nur Platzhalter |
+| `framework/runtime/mcp-config.example.json` | `<MCP_FILE>.example` | Core | nur Platzhalter |
+
+Kein neuer Mechanismus, kein neues Manifestfeld. Die Overlay-Regel liegt unter `framework/runtime/rules/` und wird dadurch von der Regeltransformation aus `CR-2026-007` erfasst, ohne dass `install.py` eine weitere Fallunterscheidung braucht. Dass sie – anders als ihre drei Nachbarn dort – **Saat** und nicht Core ist, entscheidet allein der Eintrag im Manifest (`shared_seed` statt `shared_core`); die Ablage trifft darüber keine Aussage.
+
+**Ergebnis:** Ein Client Pack besteht aus vier Dateien: `CLIENT_PACK.md`, `manifest.json` und zwei Laufzeit-READMEs. `seed_paths` ist in beiden Manifesten leer – die gesamte Saat kommt jetzt aus dem Kern.
+
+**Zwei Korrekturen an der MCP-Vorlage**, die durch die Zusammenführung nötig wurden und beide eine Ungenauigkeit beseitigen: „laut Devin-Dokumentation" wird zu „laut Dokumentation dieses Clients", und der Marker `<VERIFY AGAINST CURRENT DEVIN DOCUMENTATION>` zu seiner clientneutralen Form. In der Fassung des Packs `claude-code` standen beide bislang falsch – ein Rest aus der Konvertierung, der dort nie zutraf.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. Die Overlay-Laufzeitregel ist die Kurzfassung von Ebene 4 und damit Framework-Gut in der Form, Projekt-Gut im Inhalt – genau deshalb Saat. Die beiden Vorlagen sind Core.
+- [x] Verschärfungsprinzip eingehalten? — Ja, und **nachgewiesen**: Fünf der sechs erzeugten Dateien sind gegenüber 0.7.0 zeichengleich. Die sechste – die Overlay-Regel des Packs `claude-code` – unterscheidet sich in drei Zeilen ihres erzeugten Kommentars; siehe Abschnitt 5.
+- [x] Widerspruchsfreiheit geprüft? — `FW-KO-04` gegen beide Installationen: 0 Fehler.
+- [x] Laufzeitfassungen betroffen? — Nur ihr Ursprung. Installationsumfang unverändert: 80 / 79 Dateien.
+- [x] Belegstatus korrekt? — Der Belegstatus der MCP-Vorlage wird von einem client­spezifischen auf den clientneutralen Marker gehoben. Inhaltlich ist das keine Änderung des Nachweisstands, sondern die Korrektur einer falschen Zuordnung im Pack `claude-code`.
+- [x] Test- und Validierungsbedarf? — Siehe Abschnitt 5.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Keine. Die beiden Vorlagen sind Core und werden von `--update` erneuert; die Overlay-Regel ist Saat und wird nie überschrieben. Ein bestehendes Projekt behält seine ausgefüllte Fassung unverändert.
+- [x] Dokumentation? — CHANGELOG, Decision Log, `clients/README.md`, beide `CLIENT_PACK.md`.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Die Zusammenführung braucht keinen neuen Mechanismus – die Abbildung lag bereits vollständig als Laufzeit-Platzhalter vor. Ein Client Pack enthält damit ausschließlich, was zwei Clients tatsächlich unterscheidet: die Pfadabbildung, die Semantikabbildung, die Fähigkeitsmatrix und zwei erklärende READMEs. |
+| Ziel-Release | 0.8.0 |
+| Decision-Log-Eintrag | D-20 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] Drei Quellen unter `framework/runtime/` angelegt, Client-Bindungen durch registrierte Platzhalter ersetzt
+- [x] Manifeste: Einträge aus `core_paths` und `seed_paths` in `shared_core` beziehungsweise `shared_seed` überführt; `seed_paths` ist jetzt in beiden Packs leer
+- [x] Sechs Dateien aus den Client Packs entfernt; ein Pack umfasst noch vier Dateien statt sieben
+- [x] **Zeichenweiser Vergleich gegen 0.7.0:** `20-project-overlay.md` (`devin-desktop`), beide `*.local.md.example` und beide MCP-Vorlagen bis auf die zwei gewollten Wortkorrekturen identisch
+- [x] Erstinstallation beider Packs: 80 / 79 Dateien wie zuvor; `--check` gegen beide fehlerfrei; Validator gegen beide Installationen und die Wurzelinstallation: 0 Fehler
+- [x] **Befund und Korrektur an `render_rule`:** Die Formulierung des Ladeverhaltens war invertiert – ausgerechnet eine Regel mit `trigger: always_on` erhielt den Satz *ohne* das Wort „immer", während eine Regel mit `model_decision` ihn *mit* erhielt. Der Fehler war ohne Wirkung auf das Verhalten, aber irreführend: Er behauptete den schwächeren Ladezustand für die Regel, die tatsächlich ausnahmslos lädt. Beide Fälle sagen jetzt „immer geladen"; nur die Verschärfungsnotiz unterscheidet sie. Dadurch weicht die Overlay-Regel des Packs `claude-code` in drei Kommentarzeilen von ihrer 0.7.0-Fassung ab – sie liest sich jetzt wie ihre drei Nachbarregeln
+- [ ] **Beobachtung ohne Handlungsbedarf:** `root-template/` enthält je Pack nur noch zwei READMEs. Die Ablage bleibt, weil ein künftiges Pack wieder eigene Wurzelartefakte mitbringen kann; `seed_paths` bleibt aus demselben Grund im Manifest, obwohl es derzeit überall leer ist

package/.koolie/core/governance/change-requests/CR-2026-011-hauptdokument.md

@@ -0,0 +1,72 @@
+# Änderungsantrag `CR-2026-011`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Hauptdokument: reproduzierbarer Bau aus einer Referenzinstallation, Abbildungsschicht eingearbeitet |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | `build/assemble.py`; neu: `build/doc/07a-abbildungsschicht.md`; geändert: 20 Kapitelquellen, insbesondere `00`, `01`, `04`, `05`, `07`, `15`, `31`, `32` |
+| Ebene laut Entscheidungsbaum 6 | Core (Dokumentation und Werkzeug) |
+| Art | Änderung |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+Das Hauptdokument stand auf Framework-Release 0.1.0 und beschrieb ein Framework für genau einen KI-Client. Eine Auszählung der Kapitelquellen ergab drei Befunde, von denen nur der zweite erwartet war.
+
+**Der Bau war nicht reproduzierbar.** 28 der 91 Einbettungen zeigten nicht auf den Kern, sondern auf die **installierte Laufzeitschicht dieses Repositorys** – Pfade, die in der `.gitignore` stehen. Der Bau gelang nur, weil zufällig eine `devin-desktop`-Installation im Arbeitsverzeichnis lag; in einem frischen Auscheckstand brach `assemble.py` ab. Das Dokument zeigte damit die Darstellung *eines* Clients, ohne das zu sagen, und niemand außerhalb dieses Arbeitsplatzes konnte es erzeugen.
+
+**Die Prosa war ungleich veraltet.** 25 von 33 Kapiteln nannten einen einzelnen Client, aber fünf Kapitel trugen 110 der 173 Fundstellen. Die übrigen zwanzig hatten ein bis drei – meist „Devin“ als Synonym für „der Assistent“.
+
+**Zwei Kapitel waren durch Repository-Artefakte überholt.** Kapitel 15 führte von Hand eine Tabelle der Client-Mechanismen mit Belegstatus – genau das, was seit 0.5.0 Pfadabbildung und Fähigkeitsmatrix eines Client Packs leisten. Kapitel 31 pflegte ein Inventar auf dem Stand von 0.2.0, das beschrieb, was das Dateisystem ohnehin weiß.
+
+Nur rund ein Zehntel des Dokuments ist handgeschriebene Prosa: 843 Zeilen erzeugen 8.573 Zeilen Ergebnis. Der Umbau war deshalb kleiner als „32 Kapitel“ – und an anderer Stelle unangenehmer.
+
+## 2. Vorgeschlagene Änderung
+
+**Eine Referenzinstallation als zweite Quelle.** `assemble.py` legt beim Bau eine frische Installation des gewählten Client Packs in einem temporären Verzeichnis an und liest die Laufzeitartefakte von dort. Ein Einbettungspfad mit **Laufzeit-Platzhalter** (`<RUNTIME_DIR>`, `<SKILLS_DIR>`, `<PERMISSIONS_FILE>`, …) meint die Laufzeitschicht; jeder andere Pfad meint das Repository. Die Regel ist am Pfad ablesbar und braucht keine zweite Angabe.
+
+Die Alternative – die werkzeugneutralen Kernquellen einzubetten – wurde verworfen: Sie hätte gezeigt, was im Kern steht, nicht was ein Projekt vorfindet. Gerade bei der Berechtigungsdatei ist die gerenderte Form die Aussage.
+
+**Herkunft an der Datei.** Jede aus der Installation gelesene Einbettung trägt die Angabe, aus welchem Client Pack sie stammt. Das gehört an die Datei und nicht in eine Fußnote, weil sie bei einem anderen Pack anders aussieht.
+
+**`--client` als Schalter.** Das Dokument lässt sich für jedes Pack bauen. Zeigen zwei Platzhalter auf dieselbe Datei – bei einem Client ohne eigene Hook-Datei etwa `<HOOKS_FILE>` und `<PERMISSIONS_FILE>` –, bekommt die zweite Stelle einen Verweis statt eines zweiten Abdrucks.
+
+**Ein neues Kapitel 7a „Client Packs: die Abbildungsschicht".** Der inhaltliche Kern der Releases 0.5.0 bis 0.8.0 kam im Dokument nicht vor. Das Kapitel bettet die Regeln der Schicht und die Fähigkeitsmatrix des zweiten Packs ein, statt sie abzuschreiben. Die Nummerierung bleibt stabil: `07a` sortiert zwischen `07` und `08`, kein bestehender Verweis bricht.
+
+**Ein Pack als durchgehendes Beispiel.** `devin-desktop`, ausdrücklich als solches benannt. Beide Packs überall zu zeigen würde Umfang und Pflege verdoppeln; die Fähigkeitsmatrix beider steht im neuen Kapitel nebeneinander – das ist die Stelle, an der der Unterschied hingehört.
+
+**Kapitel 15 und 31 verlieren ihre handgepflegten Tabellen** an die Artefakte, die dieselbe Aussage versioniert führen. Kapitel 31 gewinnt dafür das Laufzeitglossar als neuen Anhang 31.2.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. Keine Regel ändert sich; betroffen sind Dokumentation und das Assemblierungswerkzeug.
+- [x] Verschärfungsprinzip eingehalten? — Nicht berührt. Die eingebetteten Artefakte sind unverändert; sie kommen nur aus einer anderen, nachvollziehbaren Quelle.
+- [x] Widerspruchsfreiheit geprüft? — Die Kapitel 4, 5, 7, 15 und 31 nannten Mechanismen, die seit 0.5.0 anders geregelt sind; genau diese Widersprüche werden hier aufgelöst. `FW-KO-04` und der Validator: 0 Fehler.
+- [x] Laufzeitfassungen betroffen? — Nein. Installationsumfang unverändert: 80 / 79 Dateien.
+- [x] Belegstatus korrekt? — Der Verifikationsbedarf verweist jetzt auf die Fähigkeitsmatrizen, die ihn versioniert führen, statt ihn im Anhang zu duplizieren. Belegstand unverändert: 13 von 26 Zeilen bei `devin-desktop`, 9 von 26 bei `claude-code` tragen einen VERIFY-Marker.
+- [x] Test- und Validierungsbedarf? — Siehe Abschnitt 5.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Keine. Kein installiertes Artefakt ändert sich.
+- [x] Dokumentation? — CHANGELOG, Decision Log, Roadmap.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Ein Dokument, das nur auf einem einzelnen Arbeitsplatz baut, ist kein Lieferbestandteil, sondern ein Zufall. Die Referenzinstallation macht den Bau reproduzierbar und zeigt zugleich die Fassung, die ein Projekt tatsächlich vorfindet – benannt nach dem Client Pack, aus dem sie stammt. |
+| Ziel-Release | 0.9.0 |
+| Decision-Log-Eintrag | D-21 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] `assemble.py`: Referenzinstallation, Platzhalterauflösung über das Manifest, Herkunftsangabe je Einbettung, `--client`, Verweis statt Doppelabdruck bei gleichem Zielpfad
+- [x] 23 Direktiven auf Laufzeit-Platzhalter umgestellt, 5 auf Kernquellen (Overlay-Saat und Regelvorlage liegen versioniert unter `templates/`)
+- [x] **Bau aus einem frischen Auscheckstand ohne jede Installation: gelingt** – vorher Abbruch mit „eingebettete Datei fehlt“. Geprüft für beide Client Packs
+- [x] Neues Kapitel 7a; Kapitel 15 und 31 auf Einbettungen umgestellt; Kapitel 00, 01, 04, 05, 07, 32 neu geschrieben
+- [x] Begriffsablösung im Langlauf: 28 Ersetzungen in 19 Kapiteln
+- [x] **Messung:** Einclient-Nennungen in der Prosa von 173 auf 50 gesunken, betroffene Kapitel von 25 auf 14. Die verbleibenden benennen einen realen Client, wo einer gemeint ist – Quellenliste der Produktdokumentation (19), clientspezifische Annahme A-05 und Herstellernennungen (7), Glossareinträge, die den Client *definieren* (6), sowie das durchgehende Beispiel
+- [x] Validator und `install.py --check` gegen die Wurzelinstallation: 0 Fehler; Installationsumfang unverändert
+- [ ] **Folgearbeit:** Die Word-Fassung (`build-docx.py`) ist nicht Teil dieser Änderung. Sie folgt dem Markdown, wurde aber seit dem Umbau nicht erzeugt – `pandoc` und `mmdc` sind hier nicht installiert
+- [ ] **Beobachtung:** Kapitel 32 ist eine Selbstprüfung der Erstfassung. Sie ist fortgeschrieben, bleibt aber ihrer Anlage nach ein Rückblick auf 0.1.0. Ob sie als Abschlussteil erhalten bleibt oder in einen Release-Bericht überführt wird, ist eigene Arbeit

package/.koolie/core/governance/change-requests/CR-2026-012-schreibschutz-kernverzeichnis.md

@@ -0,0 +1,106 @@
+# Änderungsantrag `CR-2026-012`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Schreibschutz auf das gesamte Kernverzeichnis statt nur auf `framework/**` |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | `framework/runtime/permissions.json`; `tests/scripts/hook-check-secrets.py`; `framework/core/03-security.md`; `clients/devin-desktop/CLIENT_PACK.md`, `clients/claude-code/CLIENT_PACK.md`, `clients/_template/CLIENT_PACK.md`; `tests/TEST_CATALOG.md`; `build/doc/08-trennung.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Kernregelmenge, Ebene 3) |
+| Art | Verschärfung |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+Befund aus `CR-2026-008`, dort ausdrücklich für einen eigenen Antrag zurückgestellt: Das
+Schreibverbot der Kernregelmenge lautete `<CORE_DIR>/framework/**`. Es schützte damit die
+Regeltexte – und ließ ungeschützt, was unmittelbar daneben liegt:
+
+| Datei | Rolle |
+|---|---|
+| `install.py` | legt die Laufzeitschicht an und aktualisiert sie |
+| `clientmap.py` | bildet die Kernregelmenge auf den Client ab und erzwingt die drei Zusicherungen aus D-18 |
+| `tests/scripts/validate-framework.py` | gleicht die installierte Berechtigungsdatei gegen die Kernquelle ab |
+| `tests/scripts/hook-check-secrets.py` | blockiert Secrets und geschützte Pfade vor der Werkzeugausführung |
+| `tests/scripts/hook-overlay-status.py` | meldet den Overlay-Status beim Sitzungsstart |
+
+Das ist die unangenehme Form einer Lücke: Ungeschützt war nicht irgendein Randbereich,
+sondern **genau die fünf Skripte, die die Schutzzusagen durchsetzen**. Wer `clientmap.py`
+ändern kann, ändert die Kernregeln jeder künftigen Installation; wer
+`validate-framework.py` ändern kann, schaltet die Prüfung ab, die das bemerken würde. Die
+Lücke war älter als `CR-2026-008` – dieser Antrag hatte sie nur sichtbar gemacht, weil er
+`clientmap.py` hinzufügte.
+
+Der Hook trug dieselbe Enge in zweiter Fassung: Seine Musterliste schützte
+`framework/core/`, also noch weniger als die Berechtigungsdatei.
+
+## 2. Vorgeschlagene Änderung
+
+**Die Kernregel lautet `<CORE_DIR>/**` statt `<CORE_DIR>/framework/**`.** Eine Regel wird
+durch eine breitere ersetzt, keine kommt hinzu: Die Zahl der Kernregeln bleibt bei 13
+(`devin-desktop`) beziehungsweise 17 (`claude-code`, dort trägt jeder Schreibschutz zwei
+Regeln).
+
+**Kein Ausnahmemuster für einzelne Unterverzeichnisse.** Das ist keine Härte um der Härte
+willen, sondern Mechanik: In der Berechtigungsdatei gewinnt `deny` immer, und keine der
+beiden abgebildeten Clientformen kennt ein Ausnahmemuster innerhalb eines Verbots. „Der
+Kern bis auf ein Verzeichnis" ist schlicht nicht ausdrückbar – ausdrückbar ist nur ein
+engeres Verbot, und genau das war der Zustand, der die Skripte ungeschützt ließ.
+
+Die Frage stellt sich für zwei Verzeichnisse, die wie Arbeitsbereiche aussehen:
+`tests/protocols/` und `governance/change-requests/`. Beide sind Framework-Gut und werden
+über ein Release ausgetauscht. Ein aufnehmendes Projekt legt seine Testergebnisse nach
+`CL-10` ohnehin als Anlage der Overlay-Aktivierung ab, nicht im Kern. Wo ein Projekt
+dennoch im Kernverzeichnis schreiben müsste, ist entweder der Ablageort falsch gewählt
+oder es liegt ein Fall für den Ausnahmeprozess vor – beides bessere Antworten als eine
+Lücke in der Regel.
+
+**Der Hook schützt das Kernverzeichnis, aber nur gegen schreibende Werkzeuge.** Die
+bestehende Musterliste gilt auch für `exec`. Hätte das Kernmuster dort gestanden, wäre
+jeder Befehl blockiert, der einen Kernpfad nennt – der Aufruf des Validators,
+`install.py --check`, ein `git diff leitwerk-core/`. Das Framework hätte sich seine eigene
+Prüfung verboten. Das Muster steht deshalb in einer zweiten Liste, die nur für `edit`,
+`write` und `notebookedit` ausgewertet wird. Die Ergänzung ist rein additiv: Sie
+verschärft, ohne eine bisher blockierte Operation freizugeben.
+
+**Den Namen des Kernverzeichnisses leitet der Hook aus seinem eigenen Ort ab**
+(`<CORE_DIR>/tests/scripts/`), statt ihn festzuschreiben. Damit erreicht ihn eine
+Umbenennung des Kerns von selbst – dieselbe Überlegung, die `<CORE_DIR>` in `CR-2026-008`
+eingeführt hatte.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. Die Kernregelmenge (Ebene 3) ändert sich; deshalb dieser Antrag und nicht ein Nebenbefund in `CR-2026-008`.
+- [x] Verschärfungsprinzip eingehalten? — Ja, in beide Richtungen geprüft: `<CORE_DIR>/framework/**` ist eine echte Teilmenge von `<CORE_DIR>/**`, und die zweite Hook-Musterliste ergänzt Blockaden, ohne eine bestehende aufzuheben. Kein Overlay kann die Regel lockern; sie steht als Kernzusage in `_core_rules_integrity`.
+- [x] Widerspruchsfreiheit geprüft? — Drei Stellen beschrieben den Schutz enger oder anders, als er nun ist, und wurden nachgezogen: die Berechtigungspolitik in `03-security.md` Abschnitt 4, die Zeile B4 beider Fähigkeitsmatrizen und die Mechaniktabelle in Kapitel 8 des Hauptdokuments. Validator und `FW-KO-04`: 0 Fehler.
+- [x] Laufzeitfassungen betroffen? — Ja, die Berechtigungsdatei. Sie ist **Saat** und wird bei `--update` nie überschrieben; bestehende Installationen migrieren von Hand (Abschnitt 5 und Migrationshinweis im CHANGELOG). Der Installationsumfang bleibt unverändert.
+- [x] Belegstatus korrekt? — Der Hook-Anteil ist geprüft (`FW-ZA-05`, skript). Dass ein Client die `deny`-Regel durchsetzt, bleibt unbelegt wie alle Einstufungen der Fähigkeitsmatrizen – dafür steht `FW-ZA-06` neu im Katalog (sitzung, Roadmap AP2). Belegstand der Matrizen unverändert: 13 von 26 Zeilen bei `devin-desktop`, 9 von 26 bei `claude-code`.
+- [x] Test- und Validierungsbedarf? — Zwei neue Testfälle, siehe Abschnitt 5.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Ein Overlay ändert sich nicht. Ein Projekt, das die Migration unterlässt, fällt beim nächsten Validatorlauf auf (nachgewiesen, Abschnitt 5).
+- [x] Dokumentation? — CHANGELOG, Decision Log, Roadmap, Testkatalog, Testprotokoll.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Ein Schutz, der die Regeltexte umfasst, aber nicht die Skripte, die sie durchsetzen, schützt die Aussage und nicht ihre Grundlage. Die Verschärfung kostet nichts, was das Framework braucht: Der Kern gehört dem Framework Owner und wird ausschließlich über ein Release ausgetauscht – das war seit D-17 die Ablageregel, ohne dass die Berechtigungsdatei sie abbildete. |
+| Ziel-Release | 0.10.0 |
+| Decision-Log-Eintrag | D-22 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] `framework/runtime/permissions.json`: `<CORE_DIR>/framework/**` → `<CORE_DIR>/**`, weiterhin `"core": true`
+- [x] Erzeugte Kernregeln geprüft: `Write(leitwerk-core/**)` bei `devin-desktop`, `Edit(leitwerk-core/**)` **und** `Write(leitwerk-core/**)` bei `claude-code`. Anzahl der Kernregeln unverändert (13 / 17)
+- [x] `hook-check-secrets.py`: zweite Musterliste für das Kernverzeichnis, nur für schreibende Werkzeuge; Verzeichnisname aus dem eigenen Ort abgeleitet
+- [x] **Zweiter Nebenbefund:** `NotebookEdit` stand in keiner der geprüften Werkzeugklassen und lief an der **gesamten** Musterliste vorbei – auch an den Mustern für Secrets-Pfade, Laufzeitschicht und Overlay. Die Werkzeugklassen stehen jetzt einmal in `WRITE_TOOLS` und werden von beiden Listen verwendet
+- [x] **Nebenbefund im selben Zug behoben:** Fünf Vorkommen der Zeichenklasse `[\/]` trafen nur den Schrägstrich, nicht den umgekehrten. Die Muster für Wurzel-Anweisungsdatei und Laufzeitschicht griffen unter Windows nicht. Alle fünf lauten jetzt `[\\/]`
+- [x] `FW-ZA-05` (skript) **bestanden**: vierzehn synthetische Werkzeugeingaben, vierzehnmal wie erwartet. Protokoll: `leitwerk-core/tests/protocols/2026-09-10-FW-ZA-05.md`. Sieben der acht Blockadefälle liefen vor der Änderung durch – darunter der Schreibzugriff auf das Hook-Skript selbst
+- [x] `FW-ZA-06` (sitzung) neu im Katalog, Status `offen`: Ob ein Client die `deny`-Regel durchsetzt, ist Gegenstand von AP2
+- [x] **Migration erzwungen, nicht angekündigt:** Gegen eine nicht migrierte Installation meldet der Validator zwei Fehler (`Kernregel fehlt in deny` und `… in _core_rules_integrity.deny_must_contain`). Nachgewiesen durch Rückbau der Referenzinstallation dieses Repositorys und erneuten Lauf
+- [x] Frische Installation beider Client Packs in leeren Verzeichnissen: erzeugt die neue Regel; Validator und `install.py --check` ohne Befund aus dieser Änderung
+- [x] Referenzinstallation dieses Repositorys migriert; Validator: 0 Fehler, 0 Warnungen
+- [x] Dokumentation nachgezogen: `03-security.md` Abschnitt 4 (dort zugleich zwei Client-Bindungen aus dem Kern entfernt, D-15), B4 in beiden Packs und in der Vorlage, Kapitel 8 des Hauptdokuments
+- [ ] **Bewusst offen:** Ein Shell-Befehl, der in den Kern schreibt, wird vom Hook nicht erfasst – dort trägt allein die `deny`-Liste der Berechtigungsdatei. Das gilt für jedes Pfadverbot des Frameworks gleichermaßen und ist keine Eigenschaft dieser Änderung
+- [ ] **Bewusst offen:** Im Framework-Repository selbst schützt die Regel den Kern auch vor dem KI-Client, der am Framework arbeitet. Das ist beabsichtigt – V10 verlangt für Änderungen an Framework-Regeln ohnehin den Änderungsantrag. Wer den Client dort schreiben lassen will, führt das über den Ausnahmeprozess (`leitwerk-core/governance/EXCEPTION_PROCESS.md`), nicht über eine Lücke in der Regel

package/.koolie/core/governance/change-requests/CR-2026-013-validator-blindstellen.md

@@ -0,0 +1,128 @@
+# Änderungsantrag `CR-2026-013`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Vier Blindstellen des Validators, gefunden beim Ausführen von `FW-KO-01` |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | `tests/scripts/validate-framework.py`; `tests/TEST_CATALOG.md`; `docs/ROADMAP.md`; neu: `tests/protocols/2026-09-10-FW-KO-01.md`, `tests/protocols/2026-09-10-FW-DS-03.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Werkzeug) |
+| Art | Fehlerbehebung und Verschärfung |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+`FW-KO-01` („Struktur- und Formatkonsistenz", Basistest, Prüfmethode `skript`) verlangt
+`0 Fehler` aus `validate-framework.py`. Der Testfall war seit der Erstfassung `offen`. Beim
+Ausführen zeigte sich, was ein grüner Lauf allein nicht zeigt: **Von 22 gezielt eingebrachten
+Defekten blieben sechs unbemerkt.** Zwei gingen auf falsch gesetzte Sonden zurück. Vier waren
+echte Blindstellen.
+
+**Die Pfadvergleiche der Inhaltsprüfung liefen unter Windows ins Leere.**
+`os.path.relpath` liefert dort Backslashes; verglichen wurde gegen Präfixe mit Schrägstrich.
+Folge: Prüfung 11 (Codeblöcke mit vier oder mehr Backticks) hat unter Windows **nie**
+ausgelöst – auf dem Betriebssystem, auf dem das Framework entwickelt wird. Ebenso griff die
+Ausnahme für `project-overlay/forbidden-terms.txt` nicht. In diesem Repository fiel das nicht
+auf, weil die Sperrbegriffsliste des Übungsrepositorys leer ist; in einem echten Projekt
+stehen dort die realen Kunden-, Produkt- und Systemnamen, und der Validator hätte die Datei
+gegen sich selbst geprüft – ein Fehler je Begriff. `check_links` normalisiert den Pfad seit
+jeher, `check_content` nicht.
+
+**Die Quellen des Hauptdokuments waren von der Inhaltsprüfung ausgenommen.** `build` steht in
+der Überspringliste, weil dort die Erzeugnisse eines Projekts liegen. Unter dem Kern liegen
+darunter aber die 33 handgeschriebenen Kapitelquellen – ungeprüft auf Secrets, E-Mail-Adressen,
+IP-Adressen, Sperrbegriffe und vier Backticks. Das ist die unangenehmste Stelle für diese
+Lücke: Vier Backticks brechen genau dort die Assemblierung, und ein Secret erschiene im
+ausgelieferten Dokument.
+
+**Die Statusprüfung kannte nur eine von zwei Schreibweisen.** Ein Overlay erklärt seinen
+Status zweimal – als Zeile im Projektsteckbrief und als Aussage im Aktivierungsabschnitt.
+`--strict-overlay` suchte nur die zweite Form. Der Steckbrief konnte `inaktiv` sagen, während
+die Prüfung grün meldete.
+
+**Die Secret-Muster des Validators waren enger als die des Schutz-Hooks.** Der Hook blockiert
+sechs Kategorien in einer Werkzeugeingabe, der Validator suchte drei im Bestand. Was der Hook
+im Vorbeigehen verhindert – `api_key = …`, Bearer-Token, Verbindungszeichenfolge mit
+Anmeldedaten –, durfte versioniert im Repository stehen. Dieselbe Zusage war an zwei Stellen
+unterschiedlich streng, ohne dass irgendwo stand, warum.
+
+**Nebenbefund zur Aussagekraft.** Der erste Durchgang lief ohne PyYAML. Die Prüfungen 4, 5
+und 8 prüfen dann nur, ob ein Frontmatter vorhanden ist, nicht was darin steht – eine
+entfernte `description` blieb unbemerkt, das Overlay-Manifest wurde gar nicht geprüft. Der
+Validator schwieg dazu. Ein Release-Nachweis unter dieser Bedingung behauptet mehr, als er
+geprüft hat.
+
+## 2. Vorgeschlagene Änderung
+
+**Pfade normalisieren.** `check_content` normalisiert den relativen Pfad wie `check_links`
+seit jeher (`.replace(os.sep, "/")`). Eine Zeile.
+
+**Die Quellen des Hauptdokuments prüfen, das Erzeugnis nicht.** `build` bleibt in der
+Überspringliste – dort liegen die Build-Verzeichnisse eines Projekts. `<CORE_DIR>/build/doc`
+wird zusätzlich durchlaufen. Das Werkzeug daneben (`assemble.py`, `build/README.md`) bleibt
+außen vor: Es führt eigene Marker in spitzen Klammern, die keine Framework-Platzhalter sind
+und sonst als unregistriert gemeldet würden.
+
+**Jede Statuserklärung prüfen.** Beide Schreibweisen werden erfasst, aber nur am Zeilenanfang:
+eine Erwähnung im Fließtext oder in einem Ausnahmeregister ist keine Erklärung. Fehlt jede
+Angabe, ist auch das ein Fehler – bisher galt „nicht gefunden" wie „nicht `aktiv`", was
+zufällig dasselbe Ergebnis lieferte, aber nicht dasselbe meint.
+
+**Die Secret-Muster angleichen.** Der Validator übernimmt die drei fehlenden Kategorien des
+Hooks. Ein Wert in spitzen Klammern ist ausgenommen: Ein Platzhalter ist konstruktionsbedingt
+kein Secret, und das Framework schreibt seine Beispiele durchgehend so.
+
+Die naheliegende Gegenthese – die engeren Muster seien Absicht, weil das Repository
+Zugangsdaten-Muster *beschreibt* und sich sonst selbst melden würde – wurde geprüft und
+widerlegt: Über beide Repositorys ergeben die breiteren Muster **einen** Treffer, und der ist
+ein als synthetisch gekennzeichneter Platzhalter. Die Ausnahme für spitze Klammern deckt ihn
+ab; eine Ausnahmeliste braucht es nicht.
+
+Die umgekehrte Angleichung – dem Hook die Platzhalterausnahme zu geben – unterbleibt
+bewusst. Beim Hook ist die strengere Auslegung die sichere: Ein Falschalarm blockiert eine
+Operation, die der Mensch anders formuliert. Beim Validator hielte derselbe Falschalarm jeden
+Release-Lauf an. Der Unterschied ist begründet und im Protokoll zu `FW-DS-03` festgehalten.
+
+**Sagen, wenn eingeschränkt geprüft wird.** Fehlt PyYAML, meldet der Validator eine Warnung
+und benennt die drei betroffenen Prüfungen.
+
+**Zwei kleinere Ergänzungen im selben Zug:** Das Overlay-Manifest wird auch auf seine
+Kopfschlüssel geprüft (`manifest_version`, `project_code`, `overlay_version`) – bisher nur die
+Dokumenteinträge, während die Kurzbeschreibung „YAML-Schema" versprach. Und der Name des
+Kernverzeichnisses steht im Skript einmal statt an drei Stellen.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. Keine Regel ändert sich; betroffen ist das Prüfwerkzeug. Die Kernregelmenge, die Client Packs und die Laufzeitschicht bleiben unberührt.
+- [x] Verschärfungsprinzip eingehalten? — Ja. Jede Änderung erweitert, was gemeldet wird; keine hebt eine bestehende Meldung auf. Die einzige neue Ausnahme (Platzhalter in spitzen Klammern) betrifft ein Muster, das es vorher gar nicht gab.
+- [x] Widerspruchsfreiheit geprüft? — Die Kurzbeschreibung des Skripts nannte für die Prüfungen 6, 8, 9 und 11 einen größeren Umfang, als tatsächlich geprüft wurde; sie ist nachgezogen. Validator, `FW-KO-04` und `install.py --check`: 0 Fehler.
+- [x] Laufzeitfassungen betroffen? — Nein. Kein installiertes Artefakt ändert sich; der Validator liegt im Kern und wird von `--update` mitgeführt.
+- [x] Belegstatus korrekt? — `FW-KO-01` und `FW-DS-03` sind mit Protokoll belegt. Beide prüfen Skripte, nicht das Verhalten eines Clients; das bleibt AP2.
+- [x] Test- und Validierungsbedarf? — Zwei Testfälle ausgeführt, siehe Abschnitt 5.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Ein bestehendes Projekt kann nach dem Wechsel Fehler sehen, die es vorher nicht sah: vier Backticks in geschützten Ablagen, ein widersprüchlicher Overlay-Status, ein Secret-Muster im Bestand. Das sind keine neuen Regeln, sondern Regeln, die vorher nicht durchgesetzt wurden. Migrationshinweis im CHANGELOG.
+- [x] Dokumentation? — CHANGELOG, Decision Log, Roadmap, Testkatalog, zwei Testprotokolle.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Eine Prüfung, die nichts findet, weil sie nichts prüft, ist schlimmer als keine Prüfung: Sie erzeugt Vertrauen, das sie nicht deckt. Prüfung 11 hat auf dem Entwicklungsbetriebssystem nie ausgelöst, die Quellen des Hauptdokuments waren ausgenommen, ein Overlay konnte sich widersprechen, und derselbe Schutz war an zwei Stellen unterschiedlich streng. Alle vier Befunde stammen aus dem Wirksamkeitsnachweis eines Testfalls, der ohne ihn grün gewesen wäre. |
+| Ziel-Release | 0.11.0 |
+| Decision-Log-Eintrag | D-23 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] `check_content` normalisiert den relativen Pfad wie `check_links`
+- [x] `iter_text_files` durchläuft zusätzlich `<CORE_DIR>/build/doc`; `build/out` und das Werkzeug daneben bleiben außen vor
+- [x] `_overlay_status_angaben` erfasst beide Schreibweisen am Zeilenanfang; fehlende Angabe ist ein eigener Fehler
+- [x] `SECRET_PATTERNS` um Bearer-Token, Zugangsdaten-Zuweisung und Verbindungszeichenfolge erweitert, Platzhalter in spitzen Klammern ausgenommen
+- [x] Warnung, wenn PyYAML fehlt, mit Nennung der drei eingeschränkten Prüfungen
+- [x] Kopfschlüssel des Overlay-Manifests werden geprüft; `KERN` steht einmal statt dreimal
+- [x] Sammelnennungen mit Auslassungszeichen (`framework/core/…`) gelten nicht mehr als Pfadangabe – ein Falschalarm, den erst die neue Abdeckung von `build/doc` sichtbar gemacht hat
+- [x] **`FW-KO-01` (skript) bestanden**: 22 von 22 Sonden gemeldet, nachdem im ersten Durchgang sechs unbemerkt blieben. Protokoll: `leitwerk-core/tests/protocols/2026-09-10-FW-KO-01.md`
+- [x] **`FW-DS-03` (skript) bestanden**: zehn synthetische Werkzeugeingaben, alle sechs Musterkategorien abgedeckt. Protokoll: `leitwerk-core/tests/protocols/2026-09-10-FW-DS-03.md`
+- [x] Validator gegen beide Repositorys: 0 Fehler, 0 Warnungen. `install.py --check` ohne Abweichung; Hauptdokument baut für beide Client Packs
+- [ ] **Bewusst offen:** Die Sonden sind nicht Teil des Repositorys. Ein Wiederholungslauf folgt der Tabelle im Protokoll. Ein fester Sondenlauf wäre eine eigene Änderung – er erzeugt ein Werkzeug, das selbst gepflegt und selbst geprüft werden will
+- [ ] **Bewusst offen:** Prüfung 10 (Mermaid) bleibt ungeprüft, weil `mmdc` in dieser Umgebung fehlt. Sie ist optional und nicht Teil des Standardlaufs

package/.koolie/core/governance/change-requests/CR-2026-014-kurzform-langform.md

@@ -0,0 +1,125 @@
+# Änderungsantrag `CR-2026-014`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Sieben Abweichungen zwischen Kurz- und Langform, gefunden beim Ausführen von `FW-KO-02` |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | `framework/runtime/root-instruction.md`; `framework/runtime/rules/00-framework-core.md`, `10-privacy-security.md`, `15-development-rules.md`, `20-project-overlay.md`; `framework/core/05-working-model.md`, `10-error-escalation.md`; `tests/TEST_CATALOG.md`; neu: `tests/protocols/2026-09-10-FW-KO-02.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Regeltexte, Ebene 3) |
+| Art | Fehlerbehebung und Verschärfung |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+Das Framework führt seine Regeln in zwei Fassungen (D-02): der kanonischen Langform unter
+`framework/core/` und der kompakten Laufzeitfassung, die in jeder Sitzung geladen wird. Die
+Kurzfassungen tragen den Satz „Diese Fassung ist normativ; bei Abweichungen gilt die
+Langform." `FW-KO-02` prüft, ob dieser Satz trägt.
+
+Er trug nicht durchgehend. Der Abgleich ergab **sieben Befunde** – drei Widersprüche, vier
+Lücken – dazu zwei begriffliche Abweichungen.
+
+**Der wichtigste Befund ist eine Lücke, kein Widerspruch.** Die Delegationsverbotsliste ist
+die schärfste Regel des Frameworks: Sie gilt unabhängig von der Kontrollstufe, und das
+Overlay darf sie erweitern, aber nicht verkürzen. **Vier ihrer zwölf Einträge kamen in
+keiner geladenen Datei vor** – V6 (Produktionssysteme, Infrastruktur, Berechtigungen,
+Sicherheitskonfigurationen), V9 (Entscheidung über die Fortsetzung bei einem
+Sicherheitsvorfall), V11 (Kommunikation nach außen) und V12 (Löschen von Branches, Historie,
+Daten außerhalb des Arbeitsbereichs). Die Langform steht nicht im Kontext einer Sitzung; was
+dort steht und in der Kurzform fehlt, erreicht das Werkzeug nicht.
+
+**Zwei Widersprüche betreffen Rechte und Einstufungen:**
+
+Die Kurzform verbot in M1 jede Befehlsausführung, die Langform erlaubt lesende
+Analysebefehle – und die ausgelieferte Berechtigungsdatei stellt `git status`, `diff`, `log`,
+`show` und `blame` in jedem Modus auf `allow`. Die Kurzform behauptete also ein Verbot, das
+an keiner Stelle durchgesetzt wird. Der Testfall nennt Modusrechte ausdrücklich als
+Beispiel für unzulässiges Verhalten.
+
+Die Kurzform stufte jede Berührung personenbezogener Datenverarbeitung als mindestens
+Kontrollstufe hoch ein. Die Langform unterscheidet: ein Code-Pfad, der personenbezogene
+Daten verarbeitet, ohne dass sich die Verarbeitungslogik ändert, ist **mittel** – das
+Rechenbeispiel in `09-risk-model.md` Abschnitt 5 stuft genau so ein. Zwei gegensätzliche
+Aussagen über dieselbe Kontrollstufe.
+
+**Ein Widerspruch liegt innerhalb der Langform selbst:** `10-error-escalation.md` lässt in
+S10 „mehr als zwei Versuche" zu, verlangt in Abschnitt 3.1 desselben Moduls aber den Abbruch
+„nach zwei fehlgeschlagenen Korrekturschleifen". Die Wurzel-Anweisung folgt der strengeren
+Lesart.
+
+**Zwei begriffliche Befunde:** Der Nutzungsvermerk im Merge Request hieß an drei Stellen
+verschieden, eine Bezeichnung davon an einen Client gebunden. Und `20-project-overlay.md` –
+eine Kernvorlage, die in **jedes** Client Pack installiert wird – nannte an vier Stellen
+„Devin" als Akteur; ein Projekt mit dem Pack `claude-code` liest dort den Produktnamen eines
+Werkzeugs, das bei ihm nicht im Einsatz ist.
+
+## 2. Vorgeschlagene Änderung
+
+Die Richtung der Auflösung ist bei jedem Widerspruch begründungspflichtig, weil beide
+Fassungen normativ sind.
+
+**M1-Befehlsrecht: Die Kurzform folgt der Langform.** Lesende Analysebefehle bleiben
+zulässig; sie sind in der Berechtigungsdatei ohnehin erlaubt, und ein Verbot, das nirgends
+greift, erzeugt nur ein falsches Bild der Durchsetzungstiefe. Im selben Zug wird die
+Langform mit sich selbst in Einklang gebracht: M2 führte „Alles aus M1" und
+„Befehlsausführung: nein" nebeneinander.
+
+**Kontrollstufe bei personenbezogenen Daten: Die Kurzform folgt der Langform.** Die
+Gegenrichtung – jede Berührung auf hoch – hätte die Abstufung in R4 und ihr Rechenbeispiel
+entwertet und die Stufe hoch inflationär gemacht. Die Kurzform übernimmt die Unterscheidung
+im Wortlaut.
+
+**Abbruchschwelle: Die Langform folgt der Kurzform.** S10 wird auf „zwei erfolglose
+Versuche" gesetzt – die strengere Lesart, die zugleich mit Abschnitt 3.1 desselben Moduls
+und mit der Wurzel-Anweisung übereinstimmt.
+
+**Die vier Lücken werden in der Kurzform geschlossen.** Die fehlenden Delegationsverbote,
+die K3-Auffangkategorie („alles, was die Organisation als vertraulich oder höher eingestuft
+hat" – eine Aufzählung ohne Auffangkategorie lädt zum Umkehrschluss ein), die
+Größenschwelle aus Q8 und die Erleichterung bei Kontrollstufe niedrig, die bisher nur in
+der Langform stand.
+
+**Die Laufzeitschicht wird client-neutral.** „KI-Nutzungsvermerk" mit Verweis auf die
+Vorlage; in `20-project-overlay.md` direkte Anrede statt Produktname. Damit enthalten alle
+fünf Dateien der Laufzeitschicht null Client-Bindungen.
+
+Die 74 Nennungen von „Devin" in den elf Langform-Modulen bleiben unangetastet. Sie sind der
+Rest der Neutralisierung aus D-15 – dort wurden Pfade ersetzt, nicht die Akteursbezeichnung
+– und wirken nicht auf das Verhalten, weil die Langform nicht in die Sitzung geladen wird.
+Das ist eine eigene Aufgabe und gehört in die Roadmap, nicht in diesen Antrag.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. Die Regeltexte der Ebene 3 ändern sich; deshalb ein Änderungsantrag und keine redaktionelle Korrektur.
+- [x] Verschärfungsprinzip eingehalten? — Sechs der sieben Befunde werden durch Verschärfung oder Klarstellung aufgelöst. Zwei Auflösungen erweitern den Spielraum und sind deshalb einzeln begründet: das M1-Befehlsrecht (die Kurzform behauptete ein Verbot, das die Berechtigungsdatei nicht kennt) und die Kontrollstufe bei personenbezogenen Daten (die Kurzform übersteuerte eine bewusste Abstufung der Langform). In beiden Fällen galt bereits die Langform – der Spielraum wird nicht erweitert, sondern richtig beschrieben.
+- [x] Widerspruchsfreiheit geprüft? — Das ist der Gegenstand dieses Antrags. Nach der Änderung: keine widersprüchlichen Anweisungen; die verbliebenen Abweichungen sind im Protokoll dokumentiert. Validator und `FW-KO-04`: 0 Fehler.
+- [x] Laufzeitfassungen betroffen? — Ja, alle fünf. Sie sind **Core** und werden von `install.py --update` überschrieben; einzige Ausnahme ist `20-project-overlay.md`, das als Saat in einem bestehenden Projekt seine ausgefüllte Fassung behält. Migrationshinweis im CHANGELOG.
+- [x] Belegstatus korrekt? — Unverändert. Dieser Antrag berührt keine Aussage über Produktfunktionen eines Clients.
+- [x] Test- und Validierungsbedarf? — `FW-KO-02` ist durchgeführt; die Gegenzeichnung durch eine zweite Rolle steht aus, siehe Abschnitt 5.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Die Kurzfassungen werden länger (00: 3.301 → 3.946 Zeichen, weit unter der Grenze von 12.000). Ein Projekt mit ausgefülltem `20-project-overlay.md` zieht die vier neutralisierten Stellen von Hand nach oder belässt sie – sie sind erläuternd, nicht normativ.
+- [x] Dokumentation? — CHANGELOG, Decision Log, Roadmap, Testkatalog, Testprotokoll.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Zwei Fassungen derselben Regel sind nur so lange ein Gewinn, wie sie dasselbe sagen. Die Kurzform ist die einzige, die das Werkzeug je zu sehen bekommt – eine Regel, die nur in der Langform steht, ist eine Regel, die nicht wirkt. Dass ein Drittel der Delegationsverbotsliste nirgends geladen wurde, ist der Befund, der diesen Antrag trägt; die drei Widersprüche sind der Anlass, aus dem er gefunden wurde. |
+| Ziel-Release | 0.12.0 |
+| Decision-Log-Eintrag | D-24 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] W1: M1 und M2 in Kurz- und Langform auf „nur lesende Analysebefehle" angeglichen
+- [x] W2: Kurzform übernimmt die Abstufung aus R4 (mittel bei unveränderter Verarbeitungslogik, hoch bei Änderung an Erhebung, Speicherung, Weitergabe oder Löschung)
+- [x] W3: S10 auf „zwei erfolglose Versuche" gesetzt, im Einklang mit Abschnitt 3.1 und der Wurzel-Anweisung
+- [x] L1: Alle zwölf Delegationsverbote stehen in der Kurzform; die Wurzel-Anweisung nennt zusätzlich Sicherheitsvorfall, Außenkommunikation und Löschen außerhalb des Arbeitsbereichs als Haltegründe
+- [x] L2: K3-Auffangkategorie, Keystores und Verbindungszeichenfolgen mit Anmeldedaten ergänzt; Hinweis, dass eine K2-Freigabe dokumentiert sein muss
+- [x] L3: Größenschwelle aus Q8 in `15-development-rules.md`
+- [x] L4: Erleichterung bei Kontrollstufe niedrig in der Kurzform benannt
+- [x] B1/B2: „KI-Nutzungsvermerk" mit Verweis auf die Vorlage; `20-project-overlay.md` neutralisiert. **Client-Bindungen in der Laufzeitschicht: 4 → 0**
+- [x] Validator, `FW-KO-04` und `install.py --check`: 0 Fehler. Hauptdokument baut für beide Client Packs
+- [x] Gegenzeichnung durch `<FRAMEWORK_OWNER>` am 2026-09-10 erfolgt; die beiden Auflösungen mit Ermessensspielraum wurden einzeln vorgelegt und bestätigt (M1-Befehlsrecht: erlaubt; Kontrollstufe bei unveränderter Verarbeitungslogik: mittel). `FW-KO-02` steht damit auf `bestanden`
+- [ ] **Folgearbeit:** 74 Nennungen von „Devin" als Akteur in den elf Langform-Modulen. Sie wirken nicht auf das Verhalten, widersprechen aber der Zusage eines werkzeugneutralen Kerns (D-15). Eigene Änderung, in der Roadmap vermerkt