@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-002-client-packs.md

@@ -0,0 +1,63 @@
+# Änderungsantrag `CR-2026-002`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Client Packs: Abbildungsschicht für KI-Clients mit Fähigkeitsmatrix |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | neu: `leitwerk-core/clients/`; geändert: `leitwerk-core/docs/PLACEHOLDER_REGISTRY.md`, `leitwerk-core/OWNERS.md`, `README.md`, `leitwerk-core/CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Struktur) |
+| Art | neu |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+Das Framework ist an einen einzigen KI-Client gebunden, obwohl seine Substanz clientneutral ist. D-02 trennt bereits die kanonische, werkzeugneutrale Langform in `leitwerk-core/framework/` von der Laufzeitform in der Projektwurzel – die Naht für eine Ablösung existiert also, ist aber nirgends benannt. `root-template/` ist faktisch der Adapter für einen Client, ohne als solcher deklariert zu sein.
+
+Der schwerwiegendere Punkt betrifft nicht die Pfade, sondern die **Durchsetzungstiefe**. Zusagen wie „Secret-Dateien werden nicht gelesen" sind beim heutigen Client Verweigerungsregeln, die die Engine erzwingt. Bei einem Client ohne pfadbasierte Berechtigungen wäre dieselbe Zusage nur noch ein Satz im Kontext, dem ein Modell folgen kann oder auch nicht. Ohne eine Stelle, an der dieser Unterschied ausgewiesen wird, würde eine Portierung falsche Sicherheit erzeugen – und zwar im Datenschutz- und Sicherheitskern, also dort, wo der Schaden am größten ist.
+
+Zeitlich ist der Eingriff jetzt am günstigsten: Die Strukturänderung ist ein Breaking Change und in einem 0.x-Stand nach Semantic Versioning kostenlos. Nach 1.0.0 kostet sie ein 2.0.0 samt Migrationspaket für jedes aufnehmende Projekt. Derzeit existiert genau ein aufnehmendes Repository (das Übungsrepository).
+
+## 2. Vorgeschlagene Änderung
+
+Einführung von **Client Packs** unter `leitwerk-core/clients/`:
+
+1. `README.md` – Zweck, Abgrenzung, Regeln der Fähigkeitsmatrix, Erstellungsanleitung.
+2. `_template/CLIENT_PACK.md` – Vorlage mit Pfadabbildung und einer Fähigkeitsmatrix aus 26 Zusagen in sieben Gruppen (R Regelladung, S Skills, B Berechtigungen, H Hooks, A Agentenprofile, M Modi, X externe Anbindung).
+3. `devin-desktop/CLIENT_PACK.md` – der heutige Client als erstes Pack, ausgefüllt aus dem Ist-Zustand.
+
+**Kern der Vorlage** ist die dreiwertige Einstufung je Zusage: `[TECHNISCH]` (Engine erzwingt), `[TEXTUELL]` (nur Anweisung), `[NICHT ABBILDBAR]` (kein Mechanismus). Sechs Zusagen sind als **Kernzusagen** markiert; sie entsprechen `_core_rules_integrity` in der Berechtigungsdatei. Weicht eine davon von `[TECHNISCH]` ab, ist sie einzeln zu begründen, im Overlay als Ausnahme zu führen und durch `<SECURITY_CONTACT>` freizugeben.
+
+Neu registrierte Platzhalter: `<CLIENT_PACK_NAME>`, `<CLIENT_PACK_CODE>` sowie der clientneutrale Marker `<VERIFY AGAINST CURRENT CLIENT DOCUMENTATION>`.
+
+**Nicht Bestandteil dieses Antrags** (Folgearbeit für Release 0.5.0): Verschiebung von `root-template/` unter das jeweilige Pack, Schalter `--client` in `install.py`, Umbenennung der devin-spezifischen Verzeichnis- und Markernamen, ein zweites Client Pack.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. Die Schicht ist Struktur des Kerns; sie enthält keine Projektwerte.
+- [x] Verschärfungsprinzip eingehalten? — **Ja, und das ist hier die entscheidende Frage.** Ein Client Pack führt keine Verhaltensregel ein, lockert keine bestehende und steht in keiner Konfliktbeziehung zu Core, Overlay oder Packs. Die achtstufige Prioritätshierarchie (D-06) bleibt unberührt; ein Client Pack ist bewusst **keine** Regelebene, sondern eine Abbildungsschicht. Bei Widerspruch zur Langform gilt die Langform. Das ist in `clients/README.md` Abschnitt 2 normativ festgehalten.
+- [x] Widerspruchsfreiheit geprüft? — Gelesen: `PRIORITY_HIERARCHY.md`, `09-risk-model.md` (V1–V12), `08-skill-conventions.md`, `role-packs/README.md`, `tech-packs/README.md`, `.devin/README.md`, `.devin/rules/README.md`, `.devin/config.json`. Die Delegationsverbote V1–V12 sind ausdrücklich von der Matrix ausgenommen: Sie sind organisatorischer Natur und bei jedem Client `[TEXTUELL]`.
+- [x] Laufzeitfassungen betroffen? — Nein. `AGENTS.md`, `.devin/rules/*` und `.devin/config.json` bleiben unverändert; das Devin-Pack beschreibt sie nur.
+- [x] Belegstatus korrekt? — Ja, und der Befund ist unbequem: 13 der 26 Zeilen des Devin-Packs tragen einen VERIFY-Marker, keine einzige Einstufung ist gegen eine Installation geprüft. Das Pack weist sich deshalb im Kopf ausdrücklich als **unbelegt** aus.
+- [x] Test- und Validierungsbedarf? — `validate-framework.py` ohne Fehler und Warnungen. Ein Testfall für die Vollständigkeit einer Fähigkeitsmatrix (jede Zeile eingestuft, jede Kernabweichung begründet) ist als Folgearbeit vorzusehen.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Keine. Rein additive Änderung.
+- [x] Dokumentation? — CHANGELOG, Platzhalterregister, OWNERS, Verzeichnisbaum in `README.md`.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Die Schicht macht eine bereits vorhandene Naht (D-02) explizit und ist rein additiv. Ihr eigentlicher Wert liegt in der Fähigkeitsmatrix: Sie zwingt jede Portierung dazu, offenzulegen, welche Zusage der Zielclient technisch erzwingt und welche nur noch Prosa ist. Ohne diesen Zwang wäre Clientneutralität ein Sicherheitsrisiko statt einer Verbesserung. Der Zeitpunkt ist der günstigste mögliche: ein 0.x-Stand mit einem einzigen aufnehmenden Repository. |
+| Ziel-Release | 0.5.0 |
+| Decision-Log-Eintrag | D-12 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] `clients/README.md`, `_template/CLIENT_PACK.md`, `devin-desktop/CLIENT_PACK.md` angelegt
+- [x] Platzhalter registriert; `OWNERS.md` und Verzeichnisbaum ergänzt
+- [x] Validator ohne Fehler und Warnungen
+- [x] CHANGELOG und Decision Log ergänzt
+- [ ] Folgearbeit 0.5.0: `root-template/` je Pack, `install.py --client`, Umbenennung, zweites Client Pack
+- [ ] Kommunikation an Projekte — entfällt (nur das Übungsrepository hat aufgenommen)

package/.koolie/core/governance/change-requests/CR-2026-003-install-client-schalter.md

@@ -0,0 +1,70 @@
+# Änderungsantrag `CR-2026-003`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Wurzelartefakte je Client Pack; Schalter `--client` in `install.py` |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | verschoben: `leitwerk-core/root-template/` → `leitwerk-core/clients/devin-desktop/root-template/`; verschoben: `leitwerk-core/framework/client-packs/` → `leitwerk-core/clients/`; geändert: `leitwerk-core/install.py`, `README.md`, `leitwerk-core/docs/ADOPTION_GUIDE.md`, `leitwerk-core/OWNERS.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Struktur) |
+| Art | Änderung |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+`CR-2026-002` hat die Client Packs als Abbildungsschicht eingeführt, die Wurzelartefakte aber dort belassen, wo sie lagen: in `leitwerk-core/root-template/`. Damit blieb die Schicht Dokumentation ohne Wirkung – `install.py` kannte weiterhin genau eine, fest verdrahtete Vorlage. Ein zweites Client Pack hätte seine Artefakte nirgends unterbringen können.
+
+## 2. Vorgeschlagene Änderung
+
+1. **`root-template/` wandert unter das Client Pack**, dem es gehört: `leitwerk-core/clients/devin-desktop/root-template/`. Ein Client Pack besteht damit aus `CLIENT_PACK.md` (was der Client durchsetzt) und `root-template/` (was installiert wird).
+
+2. **`install.py` erhält `--client`** (Standard `devin-desktop`) und `--list-clients`. Die Vorlage wird nicht mehr aus einer Konstanten abgeleitet, sondern aus dem gewählten Pack; `core_relpaths`, `seed_relpaths` und `run` nehmen sie als Parameter entgegen. Ein unbekannter Client bricht mit Exit-Code 1 ab und nennt die verfügbaren. Als installierbar gilt nur ein Pack mit vorhandenem `root-template/`.
+
+3. **Die Schicht wandert von `framework/client-packs/` nach `clients/`.** Zwei Gründe, siehe Abschnitt 2a.
+
+### 2a. Warum `clients/` und nicht `framework/client-packs/`
+
+**Inhaltlich:** Unter `framework/` liegen die Regelebenen – `core/` (Ebene 3), `tech-packs/` (5), `role-packs/` (6), `org-policies/` (2). `CR-2026-002` hat aber normativ festgehalten, dass ein Client Pack **keine** Regelebene ist. Es dort einzuordnen war eine Analogie zu den anderen Packs und widersprach der eigenen Festlegung.
+
+**Technisch, und hier lag ein realer Fehlschlag:** Die erste Testinstallation nach der Verschiebung brach unter Windows mit `FileNotFoundError` ab. Ursache war nicht die Logik, sondern die Pfadlänge. `MAX_PATH` beträgt 260 Zeichen; der längste relative Pfad des Frameworks wuchs durch die Verschiebung von 89 auf 126 Zeichen:
+
+| Ablage | Längster relativer Pfad |
+|---|---|
+| vorher (`root-template/`) | 89 Zeichen |
+| `framework/client-packs/<client>/root-template/` | 126 Zeichen |
+| `clients/<client>/root-template/` | 111 Zeichen |
+
+Bei einem Projektbasispfad von 135 Zeichen ergab die mittlere Variante 261 Zeichen und damit den Abbruch. Die Kürzung um 15 Zeichen löst den konkreten Fall; sie beseitigt das Problem nicht grundsätzlich. Ein Client Pack bleibt eine Verschachtelungsebene mehr als zuvor.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja, Struktur des Kerns.
+- [x] Verschärfungsprinzip eingehalten? — Ja. Kein Regeltext geändert; die installierten Artefakte sind byteweise dieselben.
+- [x] Widerspruchsfreiheit geprüft? — `clients/README.md` Abschnitt 2 hält fest, dass ein Client Pack keine Regelebene ist; die Ablage außerhalb von `framework/` zieht das nun nach.
+- [x] Laufzeitfassungen betroffen? — Inhaltlich nein, nur ihr Quellort. Nachgewiesen durch eine Erstinstallation mit unveränderter Dateizahl (80).
+- [x] Belegstatus korrekt? — Keine produktbezogene Aussage betroffen.
+- [x] Test- und Validierungsbedarf? — Siehe Abschnitt 5. `FW-KO-04` hat die beiden gebrochenen Querverweise unmittelbar nach der Verschiebung gemeldet, ohne die historischen Nennungen in `CHANGELOG.md` fälschlich mitzumelden.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Für aufnehmende Projekte keine: `install.py` wird ohne Schalter aufgerufen und verhält sich unverändert. Betroffen ist nur, wer den Kern selbst bearbeitet.
+- [x] Dokumentation? — `README.md` (Verzeichnisbaum, Abschnitt „Arbeiten an diesem Repository"), `ADOPTION_GUIDE.md` (Abschnitt „Werkzeugwechsel" von Zukunftsplan auf Ist-Zustand umgeschrieben), CHANGELOG, Decision Log.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Ohne diesen Schritt bliebe `CR-2026-002` folgenlos. Die Ablage unter `clients/` ist zugleich inhaltlich konsistenter und technisch robuster als die zunächst gewählte unter `framework/`. |
+| Ziel-Release | 0.5.0 |
+| Decision-Log-Eintrag | D-13 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] Verschiebung beider Verzeichnisse; alle Verweise nachgezogen
+- [x] `install.py`: `--client`, `--list-clients`, parametrisierte Vorlage
+- [x] Validator ohne Fehler und Warnungen
+- [x] Erstinstallation in leerem Verzeichnis: **80 Dateien**, kein Pack aktiv, `.devin/skills/` nur `fw-*` – identisch zum Stand vor der Verschiebung
+- [x] `--check` gegen die frische Installation: keine Abweichung
+- [x] Drift-Erkennung: manipulierte Core-Datei → Exit 1 mit Nennung des Client-Pack-Pfades; `--update` stellt her → Exit 0
+- [x] Unbekannter Client: Exit 1, verfügbare Packs genannt
+- [x] CHANGELOG und Decision Log ergänzt
+- [ ] Folgearbeit: zweites Client Pack; Umbenennung der devin-spezifischen Verzeichnis- und Markernamen

package/.koolie/core/governance/change-requests/CR-2026-004-client-pack-claude-code.md

@@ -0,0 +1,82 @@
+# Änderungsantrag `CR-2026-004`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Zweites Client Pack `claude-code`; Manifeste; clientneutraler Validator |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | neu: `leitwerk-core/clients/claude-code/`, `leitwerk-core/clients/*/manifest.json`; geändert: `leitwerk-core/install.py`, `leitwerk-core/tests/scripts/validate-framework.py`, `leitwerk-core/tests/scripts/hook-check-secrets.py`, `leitwerk-core/clients/README.md`, `leitwerk-core/OWNERS.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Struktur) |
+| Art | neu |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+`CR-2026-002` und `CR-2026-003` haben die Client Packs eingeführt und installierbar gemacht – aber mit genau einem Pack. Ob die Abstraktion trägt oder nur eine Umbenennung war, konnte damit niemand feststellen. Ein zweites Pack ist der einzige belastbare Nachweis.
+
+`claude-code` eignet sich als Gegenprobe besonders, weil der Client in einem zentralen Punkt anders gebaut ist: Er kennt **keine Regeldateien mit Ladetriggern**. Damit prüft das Pack nicht nur die Pfadabbildung, sondern die Annahme, dass die Framework-Regeln überhaupt von diesem Mechanismus lösbar sind.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Client Pack `claude-code`** mit `CLIENT_PACK.md`, `manifest.json` und vollständigem `root-template/` (79 Dateien).
+
+2. **Manifeste für beide Packs.** `install.py` hatte `CORE_PATHS`, `SEED_PATHS` und die Projektpfad-Hinweise fest verdrahtet – auf `.devin/`. Diese Listen stehen jetzt je Pack in `manifest.json`. Ohne Manifest gilt ein Pack als nicht installierbar.
+
+3. **Clientneutraler Validator.** `check_required`, `check_config`, `check_rules` und `skill_dirs` liefen fest gegen `.devin/`. Sie ermitteln die Laufzeitschicht jetzt über `detect_client()` aus dem Manifest des Packs, dessen `runtime_dir` im Zielverzeichnis liegt. Sind mehrere Laufzeitschichten vorhanden, ist das ein Fehler – ein Projekt nutzt genau ein Pack.
+
+4. **`check_rules` unterscheidet zwei Bauarten.** Mit Ladetriggern wird das Frontmatter geprüft. Ohne Ladetrigger wird geprüft, dass jede Kernregel in der Wurzel-Anweisung **eingebunden** ist – dort ist eine nicht eingebundene Regeldatei stillschweigend wirkungslos, ein Fehlerfall, den es bei Clients mit Ladetriggern nicht gibt. Zusätzlich wird der ständig geladene Kontext gemessen und ab 40.000 Zeichen gewarnt.
+
+5. **Der Schutz-Hook wurde clientneutral.** `hook-check-secrets.py` schützte `AGENTS.md` und `.devin/`; es schützt jetzt beide Namensformen. Das Skript war ohnehin schema-agnostisch und funktioniert damit bei beiden Clients unverändert.
+
+6. **Der Querverweis-Check unterscheidet drei Fälle** (siehe Abschnitt 2a).
+
+### 2a. Der wichtigste Befund: 63 Client-Bindungen im „werkzeugneutralen" Kern
+
+Der Validator gegen die erste `claude-code`-Installation meldete **104 Fehler**. Keiner davon war ein Programmfehler. Die Ursache: D-02 nennt `leitwerk-core/framework/` „kanonisch und werkzeugneutral" – tatsächlich nennt der Kern an vielen Stellen `AGENTS.md` und `.devin/`, also die Laufzeitpfade genau eines Clients.
+
+Nach Abzug der berechtigten Fälle bleiben **63 echte Client-Bindungen**, verteilt über `framework/core/`, `governance/`, `docs/`, `checklists/`, `onboarding/`, `prompts/` und `tests/`. Häufigste Nennungen: `AGENTS.md` (37), `.devin/config.json` (17), `.devin/` (16).
+
+Der Querverweis-Check unterscheidet deshalb jetzt:
+
+| Fall | Behandlung |
+|---|---|
+| Pfad existiert nicht und gehört zu keinem Client Pack | **Fehler** – tote Referenz |
+| Pfad gehört zur Laufzeitschicht eines nicht installierten Client Packs | **Warnung** mit Anzahl und Fundstellen – Client-Bindung im Kern |
+| Datei liegt im `root-template/` eines Packs, Pfad dort auflösbar | kein Befund – das Pack beschreibt seine eigene Laufzeitschicht |
+| Datei ist eine `CLIENT_PACK.md` oder liegt unter `clients/_template/` | kein Befund – sie beschreibt fremde Pfade |
+
+Damit ist die Neutralisierung des Kerns keine Schätzung mehr, sondern eine messbare Restgröße. Sie ist **nicht** Bestandteil dieses Antrags.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja, Struktur des Kerns.
+- [x] Verschärfungsprinzip eingehalten? — Ja. Die Regeltexte sind inhaltlich identisch übernommen. Drei Abweichungen des neuen Packs sind sämtlich Verschärfungen: Regeln ohne Ladetrigger sind immer statt bedingt geladen; Befehlsverbote wirken präfixbasiert und damit breiter; der Schutz-Hook deckt jetzt beide Namensformen ab.
+- [x] Widerspruchsfreiheit geprüft? — `clients/README.md` Abschnitt 2 (keine Regelebene) gilt unverändert. Die Fähigkeitsmatrix des neuen Packs weist vier Zusagen als `[NICHT ABBILDBAR]` aus; alle vier betreffen Least Context und Ergonomie, keine Schutzzusage.
+- [x] Laufzeitfassungen betroffen? — Für `devin-desktop` nicht: `install.py --check` unverändert, Erstinstallation weiterhin 80 Dateien.
+- [x] Belegstatus korrekt? — 9 der 26 Matrixzeilen tragen einen VERIFY-Marker. Das Pack weist sich im Kopf als unbelegt aus. Eine Beobachtung während der Erstellung (Abschnitt 6 des Packs) ist ausdrücklich als solche gekennzeichnet und ersetzt AP2 nicht.
+- [x] Test- und Validierungsbedarf? — Siehe Abschnitt 5. Offen: ein Testfall, der die Vollständigkeit einer Fähigkeitsmatrix prüft.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Für bestehende Projekte keine. Das Übungsrepository wurde mit dem neuen Kern gegengeprüft (simulierte Übernahme): fehlerfrei, aktivierte Packs weiterhin erkannt.
+- [x] Dokumentation? — `clients/README.md` (Pack-Liste mit Durchsetzungstiefe, Manifest-Pflicht, Erstellungsschritte), `OWNERS.md`, CHANGELOG, Decision Log.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Das zweite Pack belegt, dass die Abstraktion trägt: Alle sechs Kernzusagen sind auch bei einem Client mit grundlegend anderem Regelmechanismus technisch abgebildet. Zugleich hat der Versuch zwei Schwächen aufgedeckt, die ohne ihn unentdeckt geblieben wären – die harte Verdrahtung in `install.py` und im Validator sowie die 63 Client-Bindungen im angeblich werkzeugneutralen Kern. Beide sind jetzt behoben beziehungsweise messbar. |
+| Ziel-Release | 0.5.0 |
+| Decision-Log-Eintrag | D-14 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] Client Pack `claude-code`: `CLIENT_PACK.md`, `manifest.json`, `root-template/` (79 Dateien)
+- [x] Manifeste für beide Packs; `install.py` liest sie statt fester Listen
+- [x] Validator clientneutral: `detect_client`, `check_required`, `check_config`, `check_rules`, `skill_dirs`
+- [x] `hook-check-secrets.py` clientneutral; Selbsttest: beide Namensformen blockieren (Exit 2), Quellcodepfad nicht (Exit 0)
+- [x] Erstinstallation `--client claude-code` in leeres Verzeichnis: 79 Dateien (eine weniger als `devin-desktop`, weil Hooks in der Berechtigungsdatei aufgehen); `--check` dagegen fehlerfrei
+- [x] Validator gegen beide Installationen: je 0 Fehler
+- [x] Regression `devin-desktop`: Erstinstallation weiterhin 80 Dateien, `--check` fehlerfrei
+- [x] Übungsrepository mit Kern 0.5.0 gegengeprüft: 0 Fehler, aktivierte Packs erkannt
+- [x] CHANGELOG und Decision Log ergänzt
+- [ ] Folgearbeit: Neutralisierung der 63 Client-Bindungen im Kern; gemeinsame Skill-Quelle statt Duplikat je Pack; Testfall für die Vollständigkeit einer Fähigkeitsmatrix

package/.koolie/core/governance/change-requests/CR-2026-005-kern-neutralisierung.md

@@ -0,0 +1,75 @@
+# Änderungsantrag `CR-2026-005`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Neutralisierung des Kerns: Begriffe statt clientspezifischer Pfade |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | neu: `leitwerk-core/docs/RUNTIME_GLOSSARY.md`; geändert: `framework/core/*`, `framework/role-packs/`, `framework/tech-packs/`, `governance/`, `checklists/`, `onboarding/`, `prompts/`, `examples/`, `decision-trees/`, `docs/`, `tests/TEST_CATALOG.md`, `OWNERS.md`, `README.md`, `tests/scripts/validate-framework.py` |
+| Ebene laut Entscheidungsbaum 6 | Core (Redaktion) |
+| Art | Änderung |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+`CR-2026-004` hat gemessen, was D-02 bislang nur behauptete: Der als „kanonisch und werkzeugneutral" bezeichnete Kern nannte an **63 Stellen** die Laufzeitpfade genau eines KI-Clients – `AGENTS.md` (37-mal), `.devin/config.json` (17-mal), `.devin/` (16-mal) und weitere.
+
+Die Folge war nicht theoretisch. Wer das Framework mit einem anderen Client Pack installierte, las in den Core-Modulen, Checklisten und Onboarding-Texten durchgehend Pfade, die in seiner Installation nicht existieren. Ein Kern, der so formuliert ist, ist nicht neutral – er ist nur so benannt.
+
+## 2. Vorgeschlagene Änderung
+
+**Ein Glossar legt die Begriffe fest** (`leitwerk-core/docs/RUNTIME_GLOSSARY.md`) und bildet sie auf die Pfade je Client Pack ab. Es ist das Gegenstück zum Platzhalterregister: dort projektspezifische Werte, hier clientspezifische Pfade.
+
+| Begriff im Kern | `devin-desktop` | `claude-code` |
+|---|---|---|
+| Wurzel-Anweisungsdatei | `AGENTS.md` | `CLAUDE.md` |
+| Laufzeitschicht | `.devin/` | `.claude/` |
+| Berechtigungsdatei | `.devin/config.json` | `.claude/settings.json` |
+| Regelablage | `.devin/rules/` | `.claude/framework/` |
+| Skill-Ablage | `.devin/skills/` | `.claude/skills/` |
+| Agentenprofile | `.devin/agents/` | `.claude/agents/` |
+| Hook-Konfiguration | `.devin/hooks.v1.json` | in der Berechtigungsdatei |
+| MCP-Konfiguration | `.devin/mcp_config.json` | `.mcp.json` |
+| Nutzerlokale Überschreibung | `AGENTS.local.md`, `.devin/config.local.json` | `CLAUDE.local.md`, `.claude/settings.local.json` |
+
+**Die Regel:** Im Kern steht der Begriff, im Client Pack der Pfad, in historischen Dokumenten bleibt beides unverändert.
+
+**Umsetzung:** 61 der 63 Stellen redaktionell ersetzt, in sieben Durchgängen, jeweils mit anschließender Messung. Nicht ersetzt wurden zwei Stellen in Roadmap-AP2 – das Arbeitspaket validiert bewusst die Mechanismen *eines* Clients; dort steht jetzt ein Hinweis, dass es je Client Pack zu wiederholen ist.
+
+**Nebeneffekt:** Auch die Prosa wurde vom Produktnamen gelöst, wo sie eine Eigenschaft beschreibt und keinen Beleg – „Devin passt Tests an" wurde zu „Das Werkzeug passt Tests an", „Devin-Nutzungsvermerk" zu „KI-Nutzungsvermerk".
+
+**Decision Record D-02** wurde nicht umgeschrieben – Decision Records beschreiben eine Entscheidung zu ihrem Zeitpunkt. Er trägt jetzt einen Fortschreibungsvermerk auf D-12 bis D-14.
+
+**Validator:** Vier Dateiklassen sind von der Fremdpfad-Warnung ausgenommen, jede mit Begründung im Code: das Glossar (dort sind die Pfade der Inhalt), Dateien im `root-template/` eines Packs (sie beschreiben ihre eigene Laufzeitschicht), `CLIENT_PACK.md` (beschreibt fremde Pfade) und historische Dokumente.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja, Redaktion des Kerns.
+- [x] Verschärfungsprinzip eingehalten? — Ja. **Keine Regel wurde inhaltlich geändert**, nur ihre Bezugnahme auf Artefakte. Jede Ersetzung war ein Eins-zu-eins-Austausch von Pfad gegen Begriff.
+- [x] Widerspruchsfreiheit geprüft? — Das Glossar ist die einzige Stelle, an der Begriff und Pfad zusammenstehen; alle anderen Kerntexte verweisen darauf. Die Begriffe waren bereits in den Client Packs eingeführt und sind damit nicht neu erfunden.
+- [x] Laufzeitfassungen betroffen? — Nein. Die installierten Artefakte sind byteweise unverändert: Erstinstallation weiterhin 80 Dateien (`devin-desktop`) beziehungsweise 79 (`claude-code`), `--check` fehlerfrei.
+- [x] Belegstatus korrekt? — Unverändert. Wo ein `[DOK]` an einem Pfad hing, hängt es jetzt am Begriff; die Belegkette läuft über das Client Pack.
+- [x] Test- und Validierungsbedarf? — `FW-KO-04` hat den Fortschritt in jedem Durchgang gemessen (63 → 57 → 33 → 23 → 8 → 2).
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Keine funktionale. Redaktionell: Onboarding-Texte nennen jetzt Begriffe; die Zuordnung zum eigenen Client steht im Glossar. Das Übungsrepository wurde mit dem neuen Kern gegengeprüft: 0 Fehler.
+- [x] Dokumentation? — Glossar neu, CHANGELOG, Decision Log.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Ohne diesen Schritt wäre die Clientneutralität eine Behauptung geblieben, die jeder Leser eines Core-Moduls widerlegt hätte. Die Änderung ist rein redaktionell und lässt jede Regel inhaltlich unberührt – nachgewiesen durch byteweise identische Installationen. |
+| Ziel-Release | 0.5.0 |
+| Decision-Log-Eintrag | D-15 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] `RUNTIME_GLOSSARY.md` mit Begriffen, Abbildungstabelle und Geltungsregel
+- [x] 61 von 63 Stellen neutralisiert; die zwei verbleibenden in AP2 begründet
+- [x] D-02 mit Fortschreibungsvermerk versehen, Eintrag selbst unverändert
+- [x] Validator: vier begründete Ausnahmeklassen
+- [x] Messung nach jedem Durchgang: 63 → 57 → 33 → 23 → 8 → 2
+- [x] Regression: beide Erstinstallationen unverändert (80 / 79 Dateien), `--check` fehlerfrei, Validator gegen beide Installationen 0 Fehler, Übungsrepository mit neuem Kern 0 Fehler
+- [x] CHANGELOG und Decision Log ergänzt
+- [ ] Folgearbeit: gemeinsame Skill-Quelle (siehe Messung im CHANGELOG)

package/.koolie/core/governance/change-requests/CR-2026-006-gemeinsame-skill-quelle.md

@@ -0,0 +1,77 @@
+# Änderungsantrag `CR-2026-006`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Gemeinsame Skill-Quelle mit Rendering je Client Pack |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | neu: `leitwerk-core/framework/skills/`; entfernt: `clients/*/root-template/**/skills/`; geändert: `install.py`, `tests/scripts/validate-framework.py`, `clients/*/manifest.json`, `docs/PLACEHOLDER_REGISTRY.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Struktur) |
+| Art | Änderung |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+Mit dem zweiten Client Pack lagen die zwölf `fw-*`-Skills doppelt im Kern – einmal je Pack, 48 Dateien jeweils. `CR-2026-004` hat das als bekannte Einschränkung festgehalten, `CR-2026-005` die Datengrundlage geliefert:
+
+| Größe | Wert |
+|---|---|
+| Zeilen gesamt | 3.003 |
+| Abweichende Zeilen | 215 (7,2 %) |
+| davon Frontmatter | 147 |
+| davon Pfadnennungen im Rumpf | 68 |
+
+**92,8 Prozent identisch.** Ein neuer Skill hätte zweimal geschrieben, jede Korrektur zweimal nachgezogen werden müssen – mit der üblichen Folge, dass die Fassungen auseinanderlaufen, ohne dass es jemand bemerkt.
+
+Der Ort war zudem falsch gewählt: **Ein Skill ist Framework-Inhalt – Ebene 7 der Prioritätshierarchie.** Nur seine Frontmatter-*Form* ist clientspezifisch. Dass die Skills im Client Pack lagen, war ein Erbe daraus, dass `root-template/` ursprünglich alles enthielt.
+
+## 2. Vorgeschlagene Änderung
+
+**Die Skills liegen einmal** unter `leitwerk-core/framework/skills/` (48 Dateien) und werden bei der Installation in die Form des gewählten Clients gebracht.
+
+**Quellformat ist die reichere Listenform** (`allowed-tools` als Liste, dazu `permissions` und `triggers`). Sie trägt mehr Information als die kommagetrennte Form und lässt sich verlustfrei in diese überführen – umgekehrt nicht.
+
+**Zwei Transformationen beim Rendern:**
+
+1. **Frontmatter** nach `skill_frontmatter` im Manifest: `tools_format` (`list` oder `csv`), `tool_names` (Werkzeugabbildung, etwa `edit` → `Edit, Write`), `drop_fields` (Felder, die dieser Client nicht kennt – K-18).
+2. **Laufzeit-Platzhalter** nach `runtime_placeholders` im Manifest. Neun neue registrierte Platzhalter (`<RUNTIME_DIR>`, `<ROOT_INSTRUCTION_FILE>`, `<PERMISSIONS_FILE>`, `<SKILLS_DIR>`, `<RULES_DIR>`, `<AGENTS_DIR>`, `<HOOKS_FILE>`, `<MCP_FILE>`, `<ROOT_INSTRUCTION_LOCAL>`) ersetzen die 17 Pfadnennungen in den Skill-Rümpfen.
+
+Sie unterscheiden sich von allen bisherigen Platzhaltern: **Nicht der Mensch füllt sie, sondern `install.py`.** Das ist die gerenderte Entsprechung zu den Begriffen aus D-15 – Fließtext nennt den Begriff, ein Quelltext, der gerendert wird, den Platzhalter.
+
+**Der Validator prüft beide Enden:** die Quelle unter `framework/skills/` streng nach Skill-Standard, und die installierte Laufzeitschicht darauf, dass kein Laufzeit-Platzhalter unaufgelöst geblieben ist. Letzteres deckt ein Client Pack auf, dessen Manifest einen Platzhalter nicht belegt.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja, und die Änderung korrigiert eine falsche Zuordnung: Ein Skill ist Ebene 7 (Framework), kein Bestandteil der Client-Abbildung.
+- [x] Verschärfungsprinzip eingehalten? — Ja. Kein Skill-Inhalt wurde geändert. Nachgewiesen durch unveränderte Installationsumfänge und einen Vergleich der gerenderten Fassungen mit den bisherigen.
+- [x] Widerspruchsfreiheit geprüft? — `framework/core/08-skill-conventions.md` nennt seit `CR-2026-005` die Skill-Ablage als Begriff; die Quelle liegt nun folgerichtig im werkzeugneutralen Kern. Das Nummern- und Präfixschema (`fw-`, `role-`, `tech-`, `prj-`) bleibt unverändert.
+- [x] Laufzeitfassungen betroffen? — Nur ihr Ursprung. Installationsumfang unverändert: 80 Dateien (`devin-desktop`), 79 (`claude-code`).
+- [x] Belegstatus korrekt? — Unverändert.
+- [x] Test- und Validierungsbedarf? — Siehe Abschnitt 5. Neu: Prüfung auf unaufgelöste Laufzeit-Platzhalter, mit Wirksamkeitsnachweis.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Keine. Projektspezifische `prj-*`-Skills bleiben unberührt; sie liegen weiterhin allein in der Laufzeitschicht des Projekts und werden von `install.py` nie angefasst.
+- [x] Dokumentation? — Platzhalterregister (neuer Abschnitt für Laufzeit-Platzhalter), CHANGELOG, Decision Log.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Die doppelte Pflege war die einzige Stelle, an der ein weiteres Client Pack echten Zusatzaufwand erzeugt hätte. Sie ist beseitigt, ohne dass ein Skill-Inhalt sich ändert. Die dafür gebaute Infrastruktur – Renderer und Laufzeit-Platzhalter – trägt auch die übrigen Artefakte, deren Inhalt Framework und deren Form Client ist. |
+| Ziel-Release | 0.5.0 |
+| Decision-Log-Eintrag | D-16 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] 48 Dateien nach `framework/skills/` verschoben; 17 Pfadnennungen durch Laufzeit-Platzhalter ersetzt (Restprüfung: 0 verbliebene Client-Pfade)
+- [x] Manifeste um `runtime_placeholders` und `skill_frontmatter` erweitert
+- [x] `install.py`: `resolve_placeholders`, `render_skill_frontmatter`, `framework_skill_files`, `write_rendered`, `rendered_matches`
+- [x] Skill-Verzeichnisse aus beiden `root-template/` entfernt
+- [x] Validator: Quelle als Skill-Ablage geprüft; neue Prüfung `check_runtime_placeholders`
+- [x] Platzhalterregister um den Abschnitt „Laufzeit-Platzhalter" erweitert
+- [x] Erstinstallation unverändert: 80 / 79 Dateien; `--check` gegen beide fehlerfrei
+- [x] Drift-Erkennung an einem gerenderten Skill: Exit 1 mit Nennung der gemeinsamen Quelle; `--update` stellt her
+- [x] Wirksamkeitsnachweis: `<HOOKS_FILE>` testweise aus einem Manifest entfernt → drei gemeldete Fehler wegen unaufgelöster Platzhalter; Manifest wiederhergestellt
+- [x] Validator gegen beide Installationen und gegen das Übungsrepository mit neuem Kern: je 0 Fehler
+- [x] CHANGELOG und Decision Log ergänzt
+- [ ] Folgearbeit: `project-overlay/` und die beiden Pack-Vorlagen aus den Client Packs herauslösen (18 byteweise identische Dateien); Regeltexte, Wurzel-Anweisung, Agentenprofil und Berechtigungsdatei über denselben Renderer führen

package/.koolie/core/governance/change-requests/CR-2026-007-geteilte-kernbestandteile.md

@@ -0,0 +1,80 @@
+# Änderungsantrag `CR-2026-007`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Geteilte Kernbestandteile: Overlay-Vorlage, Regelvorlagen, Wurzel-Anweisung, Core-Regeltexte, Agentenprofil |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | neu: `leitwerk-core/framework/runtime/`, `leitwerk-core/templates/project-overlay/`, `leitwerk-core/templates/rules/`; geändert: `install.py`, `tests/scripts/validate-framework.py`, `clients/*/manifest.json`, `docs/PLACEHOLDER_REGISTRY.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Struktur) |
+| Art | Änderung |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+`CR-2026-006` hat die Skills auf eine gemeinsame Quelle gebracht und dabei gemessen, was sonst noch doppelt lag: **18 der 32 Dateien** eines Client Packs waren byteweise identisch mit ihrer Entsprechung im anderen Pack. Weitere sieben unterschieden sich nur in der Form, nicht im Inhalt.
+
+Zwei Klassen waren betroffen:
+
+**Clientneutral, nur historisch im Pack.** `project-overlay/` ist **Ebene 4 – Projekt** und hat mit dem Client nichts zu tun; die beiden Regelvorlagen sind Framework-Gut. Sie lagen nur deshalb im Pack, weil `root-template/` ursprünglich alles enthielt.
+
+**Inhalt Framework, Form Client.** Wurzel-Anweisung, die drei Core-Regeltexte und das Agentenprofil – derselbe Fall wie bei den Skills.
+
+## 2. Vorgeschlagene Änderung
+
+**Ein generischer Mechanismus für geteilte Bestandteile.** Das Manifest führt sie unter `shared_core` (wird bei `--update` überschrieben) und `shared_seed` (nur bei der Erstinstallation angelegt); ein Eintrag ist `{"src": …, "dst": …}`, der Zielpfad darf Laufzeit-Platzhalter enthalten, und ein Verzeichnis wird rekursiv abgebildet. Der Mechanismus trägt jede weitere Datei, die aus dem Kern installiert werden soll.
+
+**Neue Ablagen:**
+
+| Ablage | Inhalt |
+|---|---|
+| `templates/project-overlay/` | Saat für Ebene 4, 18 Dateien |
+| `templates/rules/` | die beiden Regelvorlagen |
+| `framework/runtime/` | Wurzel-Anweisung, Core-Regeltexte `00-`, `10-`, `15-`, Agentenprofil |
+
+`framework/runtime/` ist die werkzeugneutrale Laufzeitfassung – genau das, was D-02 seit jeher meint, aber bisher nirgends lag.
+
+**Drei neue Formtransformationen**, alle aus dem Manifest gesteuert:
+
+| Transformation | Steuerung | Wirkung |
+|---|---|---|
+| Regeltext | `rule_frontmatter`: `yaml` oder `comment` | Ein Client ohne Ladetrigger bekommt statt des YAML-Frontmatters einen Kommentar, der Zweck und Ladeverhalten festhält |
+| Wurzel-Anweisung | `root_instruction_imports` | An der Marke `<!-- RUNTIME_IMPORTS -->` werden die Einbindungen dieses Clients eingesetzt; ohne Einträge verschwindet die Marke rückstandsfrei |
+| Agentenprofil | `agent_frontmatter` | Feldname und Werkzeugformat (`allowed-tools` als Liste gegenüber `tools` kommagetrennt) |
+
+**Ein neuer Laufzeit-Platzhalter `<CLIENT_NAME>`.** Die Wurzel-Anweisung trug im Titel den Produktnamen – in einer Installation des anderen Packs schlicht falsch. Er wird jetzt aus dem Manifest gesetzt.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja, und die Änderung korrigiert zwei Fehlzuordnungen: Das Project Overlay ist Ebene 4 und gehörte nie in ein Client Pack; die Core-Regeltexte sind Ebene 3.
+- [x] Verschärfungsprinzip eingehalten? — Ja. **Nachgewiesen, nicht behauptet:** Alle fünf verschobenen Laufzeitartefakte sind nach dem Rendern byteweise identisch mit dem Stand 0.4.0 (Vergleich gegen `git HEAD`). Einzige gewollte Abweichung ist der Titel der Wurzel-Anweisung, der jetzt den Namen des tatsächlich verwendeten Clients trägt.
+- [x] Widerspruchsfreiheit geprüft? — `framework/runtime/` ergänzt `framework/core/` (Langform) um die Kurzfassung; das Verhältnis beider ist in D-02 geregelt und unverändert.
+- [x] Laufzeitfassungen betroffen? — Nur ihr Ursprung. Installationsumfang unverändert: 80 / 79 Dateien.
+- [x] Belegstatus korrekt? — Unverändert.
+- [x] Test- und Validierungsbedarf? — Siehe Abschnitt 5.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Für ein bestehendes Projekt keine: Das Overlay ist Saat und wird nie überschrieben. Beim Release-Wechsel meldet `--check` die Core-Dateien als abweichend, sofern das Projekt noch den 0.4.0-Stand trägt; `--update` stellt her.
+- [x] Dokumentation? — Platzhalterregister (`<CLIENT_NAME>`), CHANGELOG, Decision Log.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Ein Client Pack enthält jetzt nur noch, was tatsächlich clientspezifisch ist – sieben beziehungsweise sechs Dateien statt achtzig. Jede Doppelpflege ist beseitigt, ohne dass ein Inhalt sich ändert. |
+| Ziel-Release | 0.5.0 |
+| Decision-Log-Eintrag | D-17 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] `shared_core` / `shared_seed` in `install.py`; Verzeichnisse werden rekursiv abgebildet
+- [x] `project-overlay/` und die beiden Regelvorlagen nach `templates/` verschoben, mit Laufzeit-Platzhaltern versehen
+- [x] Wurzel-Anweisung, Core-Regeltexte und Agentenprofil nach `framework/runtime/` verschoben und neutralisiert
+- [x] Renderer `render_rule`, `render_root_instruction`, `render_agent`; Auswahl anhand des Quellpfads
+- [x] `<CLIENT_NAME>` als Laufzeit-Platzhalter registriert und in die Validatorprüfung aufgenommen
+- [x] **Byteweiser Vergleich gegen 0.4.0**: alle fünf Laufzeitartefakte identisch
+- [x] Erstinstallation unverändert: 80 / 79 Dateien; `--check` gegen beide fehlerfrei
+- [x] Drift an einer gerenderten Regel: Exit 1 mit Nennung der gemeinsamen Quelle; `--update` stellt her
+- [x] Validator gegen beide Installationen und das Übungsrepository: je 0 Fehler
+- [x] Zwischenbefund behoben: Beim Entfernen der Import-Marke blieb eine Leerzeile stehen; sie hätte in jedem bestehenden Projekt eine Scheindrift ausgelöst
+- [ ] Folgearbeit: Berechtigungsdatei und Hook-Konfiguration. Beide sind mehr als eine Formfrage – sie erfordern eine Semantikabbildung der Regeln (Werkzeugnamen, Präfixmuster, getrennte Werkzeuge für Ändern und Anlegen) und gehören in einen eigenen Änderungsantrag.

package/.koolie/core/governance/change-requests/CR-2026-008-berechtigungen-und-hooks.md

@@ -0,0 +1,85 @@
+# Änderungsantrag `CR-2026-008`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Berechtigungsdatei und Hook-Konfiguration: eine Kernquelle, Semantikabbildung je Client Pack |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | neu: `leitwerk-core/clientmap.py`, `framework/runtime/permissions.json`, `framework/runtime/hooks.json`; entfallen: `clients/devin-desktop/root-template/.devin/config.json`, `clients/devin-desktop/root-template/.devin/hooks.v1.json`, `clients/claude-code/root-template/.claude/settings.json`; geändert: `install.py`, `tests/scripts/validate-framework.py`, `clients/*/manifest.json`, `clients/*/CLIENT_PACK.md`, `clients/_template/CLIENT_PACK.md`, `clients/README.md`, `docs/PLACEHOLDER_REGISTRY.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Struktur) |
+| Art | Änderung |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+`CR-2026-007` hat die letzte Doppelpflege im Kern beseitigt – mit zwei ausdrücklich vertagten Ausnahmen: der Berechtigungsdatei und der Hook-Konfiguration. Sie blieben zurück, weil ihre Abbildung auf einen Client keine Formfrage ist.
+
+Alle bisher zusammengeführten Artefakte unterscheiden sich zwischen zwei Client Packs nur in der **Form**: ein Frontmatter-Feld heißt anders, eine Werkzeugliste ist kommagetrennt statt eingerückt. Der Rumpf ist identisch, die Transformation verlustfrei und offensichtlich.
+
+Bei Berechtigungen und Hooks unterscheiden sich die **Werkzeuge selbst**:
+
+| Unterschied | `devin-desktop` | `claude-code` |
+|---|---|---|
+| Schreibwerkzeug | eines (`Write`) | zwei getrennte (`Edit`, `Write`) |
+| Befehlsverbote | wörtlich (`Exec(git reset --hard)`) | präfixbasiert (`Bash(git reset:*)`) |
+| Netzzugriff | ein Werkzeug mit Muster (`Fetch(*)`) | zwei Werkzeuge ohne Muster (`WebFetch`, `WebSearch`) |
+| Suchwerkzeug | kein eigenes | `Grep`, `Glob` |
+| Name im Projektverzeichnis | ohne Wurzelangabe (`.env`) | mit Wurzelangabe (`./.env`) |
+| Hook-Ablage | eigene Datei | in der Berechtigungsdatei |
+
+Genau daran hängen die Kernzusagen **B1 bis B6**. Doppelte Pflege ist hier deshalb nicht nur unbequem, sondern gefährlich: Eine Regel, die beim Nachziehen in das zweite Pack vergessen wird, ist eine stille Lücke in einer Schutzzusage – und die Fähigkeitsmatrix behauptet weiterhin `[TECHNISCH]`.
+
+## 2. Vorgeschlagene Änderung
+
+**Die Regelmenge liegt einmal im Kern.** `framework/runtime/permissions.json` beschreibt sie werkzeugneutral: Ein Werkzeugverb (`read`, `search`, `write`, `exec`, `fetch`, `mcp`), dazu ein Pfadmuster oder ein Befehl. `framework/runtime/hooks.json` beschreibt die Hooks entsprechend: auf welche Werkzeugklassen ein Hook anspricht und welches Skript er ruft. Beide Dateien werden nicht installiert, sondern übersetzt.
+
+**Die Abbildung steht im Manifest des Client Packs.** Sechs neue Felder für Berechtigungen (`permission_tools`, `permission_tools_bare`, `permission_path_prefix`, `permission_exec_match`, `permission_exec_suffix`, `permissions_extra`), zwei für Hooks (`hook_tools`, `hook_project_dir_var`), dazu `permissions_note` für die Abweichung, die im erzeugten Kommentar stehen soll. Ob ein Client eine eigene Hook-Datei kennt, wird **nicht** eigens angegeben, sondern daran erkannt, dass `<HOOKS_FILE>` und `<PERMISSIONS_FILE>` auf denselben Pfad zeigen – zwei Angaben über dieselbe Tatsache wären eine Fehlerquelle.
+
+**Ein eigenes Modul `clientmap.py`**, weil die Abbildung von zwei Werkzeugen gebraucht wird: `install.py` erzeugt damit die Dateien, `validate-framework.py` prüft damit die installierte Datei gegen die Kernquelle.
+
+**Drei Zusicherungen werden erzwungen, nicht behauptet.** Das Verschärfungsprinzip ist bei einer Semantikabbildung keine Frage der Sorgfalt mehr, sondern eine Eigenschaft, die das Werkzeug prüfen kann:
+
+| Zusicherung | Wirkung bei Verletzung |
+|---|---|
+| Eine `deny`- oder `ask`-Regel, für die ein Client kein Werkzeug kennt, ist ein Fehler | Installation bricht ab. Stillschweigendes Weglassen wäre eine Lockerung. Bei `allow` ist Weglassen zulässig – es fällt auf den strengeren Standard zurück |
+| Die Präfixform eines Befehlsverbots muss ein Präfix seiner wörtlichen Form sein | Installation bricht ab. Die Zusicherung macht die Präfixform nachweislich mindestens so breit – die Abweichung ist damit belegbar eine Verschärfung |
+| Bei `allow` müssen wörtliche und Präfixform übereinstimmen | Installation bricht ab. Dort wäre jede Verbreiterung eine Lockerung |
+
+**Der Validator prüft die Kernregeln erstmals gegen die Kernquelle**, nicht nur gegen die Datei selbst. Bisher genügte es, eine Kernregel in `deny` **und** in `_core_rules_integrity.deny_must_contain` zu streichen: Die Datei blieb in sich stimmig, der Verlust unbemerkt. Weil die Berechtigungsdatei Saat ist und `install.py --check` sie deshalb nie anfasst, war das die einzige verbleibende Lücke in der Kette.
+
+**Ein neuer Platzhalter `<CORE_DIR>`.** Der Name des Kernverzeichnisses steht in den Schreibverboten und im Hook-Befehl. Er ist keine Eigenschaft eines Clients, sondern dieser Installation, und wird deshalb von `install.py` und dem Validator aus dem tatsächlichen Verzeichnisnamen gesetzt – nicht im Manifest belegt. Damit berührt die in der Roadmap vorgesehene Umbenennung des Kernverzeichnisses (P3) kein Client Pack.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. Die Regelmenge ist Ebene 3 (Framework Core); die Abbildung auf Werkzeugnamen ist die Abbildungsschicht aus D-12 und führt keine Regel ein.
+- [x] Verschärfungsprinzip eingehalten? — Ja, und **nachgewiesen statt behauptet**: Alle drei erzeugten Dateien sind gegen den Stand 0.5.0 verglichen. Jede einzelne Berechtigungsregel und beide `_core_rules_integrity`-Blöcke sind byteweise identisch (13 Kernregeln bei `devin-desktop`, 17 bei `claude-code`). Zwei gewollte Abweichungen, beide ohne Wirkung auf das Schutzniveau: der erzeugte `_comment` (siehe Abschnitt 5) und die Reihenfolge im Hook-Matcher von `claude-code` (`Bash|Edit|Write|NotebookEdit` statt `Edit|Write|Bash|NotebookEdit`) – dieselbe Menge, eine Alternation ist ungeordnet.
+- [x] Widerspruchsfreiheit geprüft? — Gelesen: `clients/README.md` Abschnitt 4 (Fähigkeitsmatrix, Kernzusagen), `PRIORITY_HIERARCHY.md`, D-04 (Berechtigungen versioniert mit restriktivem Standard), beide `CLIENT_PACK.md`. D-04 bleibt unberührt: Die Berechtigungen sind weiterhin versioniert und weiterhin Eigentum des Projekts, sobald sie angelegt sind.
+- [x] Laufzeitfassungen betroffen? — Nur ihr Ursprung. Installationsumfang unverändert: 80 Dateien bei `devin-desktop`, 79 bei `claude-code`. Ein Client Pack enthält jetzt fünf Dateien statt sieben beziehungsweise sechs.
+- [x] Belegstatus korrekt? — Unverändert. Keine Einstufung der Fähigkeitsmatrix wird durch diese Änderung belegt; die VERIFY-Marker bleiben stehen (Roadmap AP2).
+- [x] Test- und Validierungsbedarf? — Siehe Abschnitt 5.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Für ein bestehendes Projekt keine. Die Berechtigungsdatei ist Saat und wird nie überschrieben; die dort eingetragenen Projektwerte bleiben. Neu ist allein, dass der Validator die Kernregeln zusätzlich gegen die Kernquelle prüft – ein Projekt, das keine Kernregel entfernt hat, merkt davon nichts.
+- [x] Dokumentation? — Platzhalterregister (`<CORE_DIR>`), beide `CLIENT_PACK.md`, `clients/_template/CLIENT_PACK.md`, `clients/README.md`, die beiden Laufzeit-READMEs, CHANGELOG, Decision Log.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Die letzte und heikelste Doppelpflege ist beseitigt, ohne dass eine Regel sich ändert. Wichtiger als die Einsparung: Das Verschärfungsprinzip ist an der Stelle, an der die Kernzusagen B1 bis B6 hängen, jetzt eine geprüfte Eigenschaft und keine Zusage mehr. |
+| Ziel-Release | 0.6.0 |
+| Decision-Log-Eintrag | D-18 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] `framework/runtime/permissions.json` (53 `deny`-, 5 `ask`-, 7 `allow`-Regeln, 13 davon als Kernzusage gekennzeichnet) und `framework/runtime/hooks.json`
+- [x] `clientmap.py` mit den drei erzwungenen Zusicherungen; `resolve_placeholders` dorthin verschoben, weil beide Aufrufer sie brauchen
+- [x] Manifestfelder in beiden Packs; die drei Vorlagendateien aus den Client Packs entfernt
+- [x] `install.py`: Auswahl der Transformation über den Quellpfad, wie bei den übrigen geteilten Bestandteilen; `<CORE_DIR>` aus dem Verzeichnisnamen
+- [x] Validator: Abgleich der Kernregeln gegen die Kernquelle; fehlt `clientmap.py`, wird gewarnt statt zu scheitern, und die bisherigen Prüfungen greifen weiter
+- [x] **Byteweiser Vergleich gegen 0.5.0**: alle Berechtigungsregeln und beide Kernregellisten identisch; Hook-Datei von `devin-desktop` vollständig identisch
+- [x] Erstinstallation beider Packs in ein leeres Verzeichnis: 80 / 79 Dateien wie zuvor; `--check` gegen beide fehlerfrei
+- [x] Validator gegen beide Installationen und gegen die Wurzelinstallation dieses Repositorys: 0 Fehler
+- [x] **Negativtests der Zusicherungen**: Kernregel aus *beiden* Listen einer installierten Datei entfernt → Validator meldet sie (vor dieser Änderung unbemerkt). Abbildung ohne Schreibwerkzeug, `prefix` ohne Präfixeigenschaft, `allow`-Regel mit verkürzter Präfixform, Hook-Werkzeugklasse ohne Werkzeug → Installation bricht jeweils mit benannter Ursache ab
+- [x] Zwischenbefund behoben: Der Validator leitete `<CORE_DIR>` eine Verzeichnisebene zu tief ab und erzeugte dadurch Regeln wie `Write(clients/framework/**)`
+- [x] **Befund, eigener Änderungsantrag** – erledigt durch `CR-2026-012` (Release 0.10.0, D-22): Die Schreibverbote schützen `<CORE_DIR>/framework/**`, nicht das gesamte Kernverzeichnis. Damit sind `install.py`, `validate-framework.py`, die beiden Hook-Skripte und nun auch `clientmap.py` nicht schreibgeschützt – gerade die Skripte, die die Schutzzusagen durchsetzen. Der Befund ist älter als diese Änderung; `clientmap.py` tritt einer bestehenden Lücke bei, statt eine neue zu öffnen. Die naheliegende Verschärfung auf `<CORE_DIR>/**` ändert die Kernregelmenge und gehört deshalb nicht in diesen Antrag