@renoxar/koolie 1.25.0 → 2.0.0

package/.koolie/core/checklists/10-project-adoption.md

@@ -3,7 +3,7 @@
 | Attribut | Wert |
 |---|---|
 | ID | `FW-CL-10` |
-| Version | `0.1.5` |
+| Version | `0.1.6` |
 | Status | `pilot` |
 | Owner (Rolle) | `<FRAMEWORK_OWNER>` |
 | Wann | bei Übernahme des Frameworks in ein neues Projekt, vor dem Setzen des Overlay-Status auf `aktiv` |
@@ -20,28 +20,28 @@ Stellt sicher, dass ein neues Projekt das Framework vollständig, unverändert i
 ### Voraussetzungen der Organisation
 
 - [ ] **MUSS** Freigabe der KI-Nutzung durch die Organisation liegt vor (Referenz im Overlay Abschnitt 1).
-- [ ] **MUSS** Ergebnis der Datenschutz- und Vertragsprüfung liegt vor und ist im Overlay referenziert (K-06; ohne Ergebnis bleibt die restriktivste Auslegung nach `.koolie/core/framework/core/02-privacy.md` Abschnitt 1.3).
-- [ ] **MUSS** Planstufe und administrativ erzwungene Team-Einstellungen sind dokumentiert (`.koolie/core/framework/org-policies/`, K-05); Training-Opt-out beziehungsweise vertragliche Regelung nachgewiesen (`<TBD: Nachweis der Einstellung>`).
+- [ ] **MUSS** Ergebnis der Datenschutz- und Vertragsprüfung liegt vor und ist im Overlay referenziert (ohne Ergebnis bleibt die restriktivste Auslegung nach `.koolie/core/framework/core/02-privacy.md` Abschnitt 1.3).
+- [ ] **MUSS** Planstufe und administrativ erzwungene Team-Einstellungen sind dokumentiert (`.koolie/core/framework/org-policies/`); Training-Opt-out beziehungsweise vertragliche Regelung nachgewiesen (`<TBD: Nachweis der Einstellung>`).
 - [ ] **SOLL** Abbildung des Klassifizierungsschemas der Organisation auf K0–K3 liegt vor (`.koolie/core/framework/org-policies/MAPPING_CLASSIFICATION.md`).
 
 ### Technische Integration
 
-- [ ] **MUSS** Framework-Release in das Projekt-Repository integriert: Kernverzeichnis `.koolie/core/` übernommen (D-354) und mit `install.py` Wurzel-Anweisungsdatei und Laufzeitschicht des gewählten Client Packs angelegt; Framework-Version **und gewähltes Client Pack** im Overlay notiert.
+- [ ] **MUSS** Framework-Release in das Projekt-Repository integriert: Kernverzeichnis `.koolie/core/` übernommen und mit `install.py` Wurzel-Anweisungsdatei und Laufzeitschicht des gewählten Client Packs angelegt; Framework-Version **und gewähltes Client Pack** im Overlay notiert.
 - [ ] **MUSS** Belegte Pfade vor der Erstinstallation geklärt: Bricht `install.py` ab, ist der
       vorhandene Inhalt nach `ADOPTION_GUIDE.md` Schritt 3a übernommen – nicht gelöscht und
       nicht überschrieben. Führt das Projekt ein anderes Agenten-Framework, ist die
-      Zuständigkeit für die Wurzel-Anweisungsdatei ausdrücklich entschieden (K-31).
+      Zuständigkeit für die Wurzel-Anweisungsdatei ausdrücklich entschieden.
 - [ ] **MUSS** Core-Dateien unverändert (Abgleich gegen das Release-Archiv; Änderungsbedarf läuft als Änderungsantrag an den Framework Owner, nie als lokale Änderung).
 - [ ] **MUSS** `.koolie/project-overlay/OVERLAY.md` vollständig ausgefüllt; sicherheitsrelevante Abschnitte 4, 5, 6, 13, 14, 15 ohne offene `<TBD>`.
 - [ ] **MUSS** `20-project-overlay.md` in der Regelablage synchron zur Overlay-Datei befüllt (bei Clients mit Zeichenlimit unter 6.000 Zeichen).
-- [ ] **MUSS** Berechtigungsdatei mit den Overlay-Werten befüllt (`<ALLOWED_PATHS>`, `<EXCLUDED_PATHS>`, Befehle, CI-/Gate-Pfade); bei einer Berechtigungsdatei im JSON-Format alle Kernregeln aus `_core_rules_integrity` unverändert enthalten (`openai-codex` führt den Block nicht, D-395).
+- [ ] **MUSS** Berechtigungsdatei mit den Overlay-Werten befüllt (`<ALLOWED_PATHS>`, `<EXCLUDED_PATHS>`, Befehle, CI-/Gate-Pfade); bei einer Berechtigungsdatei im JSON-Format alle Kernregeln aus `_core_rules_integrity` unverändert enthalten (`openai-codex` führt den Block nicht).
 - [ ] **MUSS** `.koolie/project-overlay/overlay-manifest.yaml` gepflegt; eingebundene Dokumente bereinigt und freigegeben; nicht registrierte Dokumente gelten als K3.
 - [ ] **MUSS** Benötigte Role Packs und Technology Packs aktiviert (Laufzeitfassungen `30-*`, `40-*` erstellt); nicht benötigte nicht geladen.
 - [ ] **MUSS** `.koolie/project-overlay/forbidden-terms.txt` projektlokal mit den realen Namen des Projekts befüllt (Datei verbleibt projektlokal).
 - [ ] **MUSS** `python3 .koolie/core/tests/scripts/validate-framework.py
       --check-overlay-ready` läuft ohne Fehler. **Das ist die Kandidatenprüfung**: Sie
       erwartet einen Overlay-Status, der noch **nicht** `aktiv` ist, und prüft alles
-      übrige auf Vollständigkeit (B08, D-57).
+      übrige auf Vollständigkeit.
 - [ ] **MUSS** Nach dem Setzen des Status auf `aktiv`:
       `python3 .koolie/core/tests/scripts/validate-framework.py --strict-overlay`
       läuft ohne Fehler. Erst danach beginnt der erste Agentenlauf mit
@@ -49,7 +49,7 @@ Stellt sicher, dass ein neues Projekt das Framework vollständig, unverändert i
 - [ ] **MUSS** `python3 .koolie/core/install.py --probe` endet ohne fehlende
       Muss-Kontrolle: Der Schutz-Hook sperrt im Projekt, die Konfiguration lädt, und
       der Client vertraut dem Projekt, wo das Pack es verlangt. Die Probe braucht kein
-      Modell (D-488). Warnungen und „unerhoben“ werden gelesen und, wo nötig, im Overlay
+      Modell. Warnungen und „unerhoben“ werden gelesen und, wo nötig, im Overlay
       begründet.
 
 ### Organisation im Projekt

package/.koolie/core/checklists/11-framework-release.md

@@ -3,7 +3,7 @@
 | Attribut | Wert |
 |---|---|
 | ID | `FW-CL-11` |
-| Version | `0.4.3` |
+| Version | `0.5.0` |
 | Status | `pilot` |
 | Owner (Rolle) | `<FRAMEWORK_OWNER>` |
 | Wann | vor jedem Framework-Release (auch Patch-Releases) |
@@ -15,7 +15,7 @@
 
 Sichert, dass ein Release konsistent, projektneutral, getestet und für übernehmende Projekte nachvollziehbar ist (`.koolie/core/governance/RELEASE_PROCESS.md`).
 
-Die mit **(ab 1.0.0, D-11)** gekennzeichneten Prüfpunkte gelten erst für das Release 1.0.0 und darüber; sie bilden die Kriterien aus Decision Record D-11 ab (`CR-2026-001`). Pilot, Onboarding und organisatorische Freigabe sind **keine** Prüfpunkte dieser Checkliste – sie liegen projektseitig (`.koolie/core/checklists/10-project-adoption.md`).
+Die mit **(ab 1.0.0)** gekennzeichneten Prüfpunkte gelten für jedes Release ab 1.0.0. Pilot, Onboarding und organisatorische Freigabe sind keine Prüfpunkte dieser Checkliste; sie liegen projektseitig (`.koolie/core/checklists/10-project-adoption.md`).
 
 ## Prüfpunkte
 
@@ -24,11 +24,11 @@ Die mit **(ab 1.0.0, D-11)** gekennzeichneten Prüfpunkte gelten erst für das R
 - [ ] **MUSS** Alle für das Release vorgesehenen Änderungsanträge sind abgeschlossen oder ausdrücklich verschoben (`.koolie/core/governance/DECISION_LOG.md` aktualisiert).
 - [ ] **MUSS** Konsistenz Core ↔ Laufzeitfassung geprüft: `.koolie/core/framework/core/*` gegen die Wurzel-Anweisungsdatei und die Regelablage `00-*, 10-*, 15-*` **jedes Client Packs** (Stichproben je geändertem Modul; keine widersprüchlichen Anweisungen).
 - [ ] **MUSS** Skills konsistent zum Skill-Standard (`.koolie/core/framework/core/08-skill-conventions.md`); Versionen, Status und CHANGELOG je geändertem Skill gepflegt; Deprecations mit Nachfolger dokumentiert.
-- [ ] **MUSS** Version je geänderter Checkliste und je geändertem Prompt gepflegt (Metadatentabelle, Semantic Versioning wie in `.koolie/core/governance/RELEASE_PROCESS.md` Abschnitt 1; Testfall `FW-VN-01`). **Ein reiner Statuswechsel ist keine Änderung im Sinne dieses Prüfpunkts** (`.koolie/core/framework/core/01-governance.md` Abschnitt 5 Punkt 5, D-106), weil er keine Anweisung ändert.
+- [ ] **MUSS** Version je geänderter Checkliste und je geändertem Prompt gepflegt (Metadatentabelle, Semantic Versioning wie in `.koolie/core/governance/RELEASE_PROCESS.md` Abschnitt 1; Testfall `FW-VN-01`). Ein reiner Statuswechsel ist keine Änderung im Sinne dieses Prüfpunkts (`.koolie/core/framework/core/01-governance.md` Abschnitt 5 Punkt 5).
 - [ ] **MUSS** Prioritätshierarchie unverändert oder Änderung begründet und in `.koolie/core/governance/PRIORITY_HIERARCHY.md` nachgezogen.
 - [ ] **SOLL** Templates, Checklisten und Entscheidungsbäume gegen geänderte Module abgeglichen (Querverweise, Begriffe).
-- [ ] **MUSS** Jedes geänderte Dokument gegen die Kriterien seiner Klasse gehalten (`.koolie/core/docs/DOCUMENTATION_STANDARD.md`, D-371); die Prüfungen 91 bis 94 laufen mit dem Validator.
-- [ ] **SOLL** Bei einem wesentlich geänderten Dokument der Klasse A (Einstieg) die Kaltleser-Probe gefahren und im Protokoll festgehalten (D-379).
+- [ ] **MUSS** Jedes geänderte Dokument gegen die Kriterien seiner Klasse gehalten (`.koolie/core/docs/DOCUMENTATION_STANDARD.md`); die Prüfungen 91 bis 94 laufen mit dem Validator.
+- [ ] **SOLL** Bei einem wesentlich geänderten Dokument der Klasse A (Einstieg) die Kaltleser-Probe gefahren und im Protokoll festgehalten.
 
 ### Projektneutralität
 
@@ -45,22 +45,22 @@ Die mit **(ab 1.0.0, D-11)** gekennzeichneten Prüfpunkte gelten erst für das R
 ### Tests
 
 - [ ] **MUSS** Testkatalog vollständig ausgeführt (`.koolie/core/tests/TEST_CATALOG.md`): Konsistenz-, Positiv-, Negativ-, Datenschutz-, Prompt-Injection-, Scope-, Fehlende-Informationen-, Zugriffs-, Regressions-, Versions- und Aktualitätstests; Ergebnisse je Test-ID dokumentiert.
-- [ ] **MUSS** (ab 1.0.0, D-11) Kein Testfall des Katalogs steht auf Ergebnisstatus `offen`; jeder trägt `bestanden`, `fehlgeschlagen (Referenz)` oder `nicht anwendbar (Begründung)`.
+- [ ] **MUSS** (ab 1.0.0) Kein Testfall des Katalogs steht auf Ergebnisstatus `offen`; jeder trägt `bestanden`, `fehlgeschlagen (Referenz)` oder `nicht anwendbar (Begründung)`.
 - [ ] **MUSS** Skill-Testfälle (`TESTS.md` je Skill) für alle geänderten Skills erneut ausgeführt.
 - [ ] **MUSS** Hook- und Validierungsskripte laufen fehlerfrei (Selbsttest der Skripte).
-- [ ] **MUSS** Jedes **Abnahmeprotokoll des Testkatalogs** trägt einen Abschnitt *Gegenzeichnung* ohne offenes `<TBD>` (Prüfung 80). **Die Pflicht gilt ausschließlich für diese Protokolle** – Dateiname `JJJJ-MM-TT-FW-<Klasse>-<NN>.md` –, nicht für Arbeits- und Messprotokolle, weil eine Gegenzeichnung eine Abnahme bestätigt und ein Messprotokoll seinen Beleg in sich trägt (D-319, `CR-2026-127` E1). **Ist keine zweite Rolle vorhanden, wird selbst gegengezeichnet und der Abschnitt weist das ausdrücklich als „Selbstgegenzeichnung“ aus** – die Zusage der zweiten Rolle ist damit zurückgenommen, nicht erfüllt.
+- [ ] **MUSS** Jedes Abnahmeprotokoll des Testkatalogs (Dateiname `JJJJ-MM-TT-FW-<Klasse>-<NN>.md`) trägt einen Abschnitt *Gegenzeichnung* ohne offenes `<TBD>` (Prüfung 80). Arbeits- und Messprotokolle brauchen keinen: Sie tragen ihren Beleg in sich. Ist keine zweite Rolle vorhanden, wird selbst gegengezeichnet, und der Abschnitt weist das ausdrücklich als „Selbstgegenzeichnung“ aus.
 - [ ] **SOLL** Mindestens ein vollständiger Durchlauf des Standardarbeitsablaufs auf dem Übungsrepository (M1 → M2 → M3 → M4) ohne Regelverstoß.
 
 ### Abschluss
 
 - [ ] **MUSS** `.koolie/core/VERSION` nach Semantic Versioning erhöht; `.koolie/core/CHANGELOG.md` mit Änderungen, Migrationshinweisen für Overlays und bekannten Einschränkungen ergänzt.
-- [ ] **MUSS** **Als letzter Eingriff in den Kern, vor dem Release-Commit:** Übernehmende Projekte gehoben – Kern aus dem **Arbeitsbaum** kopiert, beschränkt auf das Verfolgte (D-333), dann `install.py --update` (beides in einem Aufruf mit `--target`, D-362), Overlay-Wert in **drei** Trägern nachgezogen, `validate-framework.py --strict-overlay` dort gefahren **und im übernehmenden Projekt committet** (D-343) – und die Bestandsliste `.koolie/core/governance/ADOPTION_REGISTRY.md` **vorher** auf den Zielstand fortgeschrieben (Prüfung 82). **Ausnahmslos, auch bei einem Patch-Release, das kein ausgeliefertes Artefakt berührt** (D-330), weil das Heben ein Lauf gegen eine fremde Installation ist und findet, was kein Validatorlauf im Framework findet.
-- [ ] **MUSS** **Vor dem Release-Commit:** Erzeugnisse der Lieferung gebaut – Hauptdokument und Word-Fassung **je Client Pack** – und **im Erzeugnis nachgezählt** (D-332). Keine Prüfung erreicht sie, weil sie unter `build/out/` liegen und in der `.gitignore` stehen (`K-110`).
-- [ ] **MUSS** Freigabe des Releases durch den Framework Owner dokumentiert – **in der Nachricht der signierten Marke** (`RELEASE_PROCESS.md` Abschnitt 4.1 Schritt 4). **Die Marke trägt die Unterschrift, der Release-Commit nicht** (D-334); deshalb setzt sie der Mensch und nicht ein Werkzeug. Keine Prüfung erreicht den Markentext – er liegt im Tag-Objekt, nicht im Arbeitsbaum (`K-111`).
-- [ ] **MUSS** **Nach dem Release-Commit:** Release-Archiv aus der signierten Marke erzeugt, **im Erzeugnis nachgezählt** und samt Prüfsumme außerhalb des Repositoriums abgelegt; Mitteilung mit Migrationshinweisen und betroffenen Overlay-Feldern an die übernehmenden Projekte. **Das Archiv kann vor dem Commit nicht erzeugt werden** – es entsteht aus der Marke, und die sitzt auf dem Release-Commit (D-329). Ablauf: `.koolie/core/governance/RELEASE_PROCESS.md` Abschnitt 4.1 Schritte 5 bis 7.
-- [ ] **MUSS** (ab 1.0.0, D-11) Alle Core-Module, Skills und Packs tragen einen Status oberhalb von `entwurf`; die Statuszeile jedes Modulträgers setzt Prüfung 47 durch (D-105).
-- [ ] **MUSS** (ab 1.0.0, D-11) Kein Decision Record in `.koolie/core/governance/DECISION_LOG.md` trägt den Status `entschieden (Vorschlag)`.
-- [ ] **MUSS** (ab 1.0.0, D-11) Übernahme in mindestens ein zweites Projekt nach `.koolie/core/checklists/10-project-adoption.md` nachgewiesen.
+- [ ] **MUSS** Als letzter Eingriff in den Kern, vor dem Release-Commit: Bestandsliste `.koolie/core/governance/ADOPTION_REGISTRY.md` auf den Zielstand fortgeschrieben (Prüfung 82), dann übernehmende Projekte gehoben – `install.py --target <projekt> --update` aus dem Arbeitsbaum, Overlay-Wert in den drei Trägern nachgezogen, `validate-framework.py --strict-overlay` dort gefahren und die Hebung im übernehmenden Projekt committet. Ausnahmslos, auch bei einem Patch-Release ohne berührtes Artefakt (`RELEASE_PROCESS.md` Abschnitt 4.1 Schritte 1 und 2).
+- [ ] **MUSS** Vor dem Release-Commit: Hauptdokument und Word-Fassung je Client Pack gebaut und im Erzeugnis nachgezählt. Keine Prüfung erreicht sie, weil sie unter `build/out/` liegen.
+- [ ] **MUSS** Freigabe des Releases durch den Framework Owner in der Nachricht der signierten Marke dokumentiert (`RELEASE_PROCESS.md` Abschnitt 4.1 Schritt 4). Die Marke trägt die Unterschrift, deshalb setzt sie der Mensch. Keine Prüfung erreicht den Markentext.
+- [ ] **MUSS** Nach dem Release-Commit: Release-Archiv aus der signierten Marke erzeugt, im Erzeugnis nachgezählt und samt Prüfsumme außerhalb des Repositoriums abgelegt; Mitteilung mit Migrationshinweisen und betroffenen Overlay-Feldern an die übernehmenden Projekte (`.koolie/core/governance/RELEASE_PROCESS.md` Abschnitt 4.1 Schritte 5 bis 7).
+- [ ] **MUSS** (ab 1.0.0) Alle Core-Module, Skills und Packs tragen einen Status oberhalb von `entwurf`; die Statuszeile jedes Modulträgers setzt Prüfung 47 durch.
+- [ ] **MUSS** (ab 1.0.0) Kein Decision Record in `.koolie/core/governance/DECISION_LOG.md` trägt den Status `entschieden (Vorschlag)`.
+- [ ] **MUSS** (ab 1.0.0) Übernahme in mindestens ein zweites Projekt nach `.koolie/core/checklists/10-project-adoption.md` nachgewiesen.
 
 ## Abbruch- und Eskalationskriterien
 

package/.koolie/core/clientmap.py

@@ -161,7 +161,7 @@ def lieferumfang(kern: str) -> str:
 #   * allowed-tools: ein Verb ohne Abbildung wurde WOERTLICH durchgereicht. Aus
 #     'allowed-tools: banane' wurde in der installierten Fassung der Werkzeugname
 #     'banane'; aus einer geleerten Abbildung wurde 'tools: read, grep, glob' im
-#     Agentenprofil fw-reviewer - drei Namen, die dieser Client nicht kennt (M16).
+#     Agentenprofil koolie-reviewer - drei Namen, die dieser Client nicht kennt (M16).
 #   * permissions.deny: dasselbe Verb fiel lautlos ganz aus. 'deny: glob' erzeugte
 #     keine Werkzeugsperre, und der Validator meldete 0 Fehler (M6).
 # Die drei uebrigen Werkzeugabbildungen desselben Manifests - hook_tools,
@@ -293,7 +293,7 @@ def _regel_rendern(regel: dict, man: dict, korb: str) -> list[str]:
     elif verb == "skill":
         # Ein Aufrufname, kein Pfad: weder Wurzelpraefix noch Praefixzeichen, und
         # keine Musterausweitung. Gemessen am 2026-09-14 (D-82): Das Argument wird
-        # woertlich verglichen - Skill(fw-*) laesst den Aufruf von fw-code-explain
+        # woertlich verglichen - Skill(koolie-*) laesst den Aufruf von koolie-code-explain
         # NICHT durch. Wer hier ein Muster erzeugte, erzeugte eine Freigabe, die
         # lautlos nichts freigibt - der Befundtyp von D-66, mit umgekehrtem
         # Vorzeichen.

package/.koolie/core/clients/README.md

@@ -4,97 +4,98 @@
 |---|---|
 | Modul-ID | `FW-CLIENT-PACKS` |
 | Ebene | keine – Querschnittsschicht (siehe Abschnitt 2) |
-| Version | 0.9.0 |
+| Version | 0.10.0 |
 | Status | pilot |
 | Owner (Rolle) | `<FRAMEWORK_OWNER>` |
 
 ## 1. Zweck
 
-Das Framework trennt seit D-02 zwei Formen derselben Regeln: die kanonische, **werkzeugneutrale** Langform in `.koolie/core/framework/` und die kompakte **Laufzeitform** in der Wurzel des Projekts. Die Laufzeitform ist an den KI-Client gebunden, der sie lädt.
+Koolie führt jede Regel in zwei Formen: als werkzeugneutrale Langform unter `.koolie/core/framework/` und als kompakte Laufzeitform in der Wurzel des Projekts. Die Laufzeitform gehört zu dem KI-Client, der sie lädt. Ein **Client Pack** beschreibt diese Bindung für genau einen Client und beantwortet zwei Fragen:
 
-Ein **Client Pack** macht diese Bindung explizit und austauschbar. Es beantwortet für genau einen Client zwei Fragen:
+1. **Wohin** gehören Anweisungsdatei, Regeln, Skills, Berechtigungen, Hooks und Agentenprofile?
+2. **Welche Zusagen setzt dieser Client technisch durch** – und welche bleiben eine Anweisung, der das Modell folgen kann oder nicht?
 
-1. **Wohin** gehören die Laufzeitartefakte – Wurzel-Anweisungsdatei, Regeldateien, Skills, Berechtigungen, Hooks, Subagentenprofile?
-2. **Welche Zusagen des Frameworks setzt dieser Client technisch durch** – und welche bleiben eine Anweisung, der das Modell folgen kann oder auch nicht?
-
-Die zweite Frage ist der eigentliche Grund für diese Schicht. Ein Framework, dessen Datenschutz- und Sicherheitszusagen bei einem Client von der Engine erzwungen werden und bei einem anderen nur als Prosa im Prompt stehen, muss diesen Unterschied sichtbar machen. Sonst erzeugt es falsche Sicherheit – genau dort, wo es am meisten schadet.
+Die zweite Frage ist der Kern. Dieselbe Datenschutzregel kann bei einem Client von der Engine erzwungen werden und beim anderen nur als Text im Prompt stehen. Das Pack macht diesen Unterschied sichtbar, damit keine falsche Sicherheit entsteht.
 
 ## 2. Ein Client Pack ist keine Regelebene
 
-Die Prioritätshierarchie (`.koolie/core/governance/PRIORITY_HIERARCHY.md`, D-06) bleibt achtstufig und **unverändert**. Ein Client Pack
-
-- führt **keine** neuen Verhaltensregeln ein,
-- **lockert** keine bestehende Regel,
-- und steht in keiner Konfliktbeziehung zu Core, Overlay oder Packs.
-
-Es ist eine **Abbildungsschicht**: Es übersetzt die Ebenen 3 bis 7 in die Artefakte eines konkreten Clients und dokumentiert die Durchsetzungstiefe. Entsteht ein Widerspruch zwischen einem Client Pack und der Langform, gilt die Langform; das Client Pack wird korrigiert.
+Die Prioritätshierarchie (`.koolie/core/governance/PRIORITY_HIERARCHY.md`) bleibt unverändert. Ein Client Pack führt keine neue Regel ein, lockert keine bestehende und steht in keinem Konflikt mit Core, Overlay oder Packs. Es übersetzt die Ebenen 3 bis 7 in die Dateien eines Clients und dokumentiert, wie tief sie durchgesetzt werden. Widerspricht ein Pack der Langform, gilt die Langform, und das Pack wird korrigiert.
 
 ## 3. Bestandteile
 
 | Bestandteil | Inhalt |
 |---|---|
-| `CLIENT_PACK.md` | Pfadabbildung, **Semantikabbildung**, **Fähigkeitsmatrix**, Abweichungen, Belegstatus – die menschenlesbare Fassung |
-| `manifest.json` | Dieselben Abbildungen maschinenlesbar; `install.py` und `validate-framework.py` lesen sie. **Ohne Manifest ist ein Pack nicht installierbar** |
-| `root-template/` | Nur die Artefakte, die tatsächlich clientspezifisch sind: **eine** erklärende README der Laufzeitschicht je Pack (D-36) |
+| `CLIENT_PACK.md` | Pfadabbildung, Semantikabbildung, **Fähigkeitsmatrix**, Abweichungen, Belegstand – für Menschen |
+| `manifest.json` | dieselben Abbildungen maschinenlesbar für `install.py` und den Validator. Ohne Manifest ist ein Pack nicht installierbar |
+| `root-template/` | nur die erklärende README der Laufzeitschicht |
 
-**Die Vorlage `_template/` trägt von diesen drei Bestandteilen genau einen: `CLIENT_PACK.md`.** Sie ist damit kein Pack, und die Packmenge der Prüfungen nimmt sie ausdrücklich nicht auf (D-336). **Prüfung 84** hält fest, dass die Vorlage eine Vorlage bleibt.
+Die Vorlage `_template/` enthält nur `CLIENT_PACK.md` und ist damit kein Pack; Prüfung 84 hält das fest.
 
-Alles andere liegt einmal im Kern und wird bei der Installation in die Form dieses Clients gebracht: Regeltexte, Wurzel-Anweisung, Agentenprofil, Skills, Overlay-Laufzeitregel und die beiden Vorlagen als **Formtransformation** (D-16, D-17, D-20), Berechtigungen und Hooks als **Semantikabbildung** (D-18). `seed_paths` ist in allen Packs leer – die gesamte Saat kommt aus dem Kern. Der Unterschied ist wesentlich: Bei einer Formtransformation ist der Inhalt derselbe und nur die Schreibweise anders. Bei der Semantikabbildung unterscheiden sich die Werkzeuge selbst – ein Client trennt Ändern und Anlegen, ein anderer nicht; ein Befehlsverbot greift hier wörtlich und dort über ein Präfix. Weil an genau diesen Regeln die Kernzusagen hängen, prüft die Abbildung drei Eigenschaften und bricht ab, wenn eine verletzt ist:
+Alles andere liegt einmal im Kern und wird bei der Installation in die Form des Clients gebracht:
 
-| Zusicherung | Warum |
+- **Formtransformation** – gleicher Inhalt, andere Schreibweise: Regeltexte, Wurzel-Anweisung, Agentenprofil, Skills, Overlay-Laufzeitregel, Vorlagen.
+- **Semantikabbildung** – andere Werkzeuge: Berechtigungen und Hooks. Ein Client trennt Ändern und Anlegen, ein anderer nicht; ein Befehlsverbot greift hier wörtlich, dort über ein Präfix.
+
+Weil an der Semantikabbildung die Kernzusagen hängen, bricht die Installation ab, wenn eine dieser Bedingungen verletzt ist:
+
+| Bedingung | Grund |
 |---|---|
-| Keine `deny`- oder `ask`-Regel ohne Zielwerkzeug | Sie wegzulassen 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 der wörtlichen Form sein | Damit ist sie nachweislich mindestens so breit; die Abweichung ist belegbar eine Verschärfung |
-| Bei `allow` müssen beide Formen übereinstimmen | Dort wäre jede Verbreiterung eine Lockerung |
+| Jede `deny`- und `ask`-Regel hat ein Zielwerkzeug | Eine weggelassene Sperre wäre eine Lockerung. Bei `allow` ist Weglassen erlaubt, es gilt dann der strengere Standard |
+| Die Präfixform eines Befehlsverbots ist ein Präfix der wörtlichen Form | So ist sie mindestens so breit wie das Original |
+| Bei `allow` stimmen beide Formen überein | Jede Verbreiterung wäre eine Lockerung |
 
 ## 4. Die Fähigkeitsmatrix
 
-Kern jedes Client Packs. Sie stuft jede technische Zusage des Frameworks in eine von drei Klassen ein:
+Jedes Pack stuft jede technische Zusage von Koolie in eine von drei Klassen ein:
 
 | Klasse | Bedeutung |
 |---|---|
-| `[TECHNISCH]` | Der Client erzwingt die Zusage. Ein Verstoß ist nicht möglich, **unabhängig vom Modellverhalten** – nicht notwendig unabhängig vom **Betriebsmodus**. Die Abhängigkeit vom Betriebsmodus weist der B-Block des jeweiligen Packs in einer Vorbemerkung aus; sie ist dort Pflicht (D-35). |
-| `[TEXTUELL]` | Die Zusage steht als Anweisung im Kontext. Ein Modell kann ihr folgen; erzwungen ist sie nicht. |
-| `[NICHT ABBILDBAR]` | Der Client bietet keinen Mechanismus. Die Zusage entfällt für diesen Client. |
-
-**Kernzusage** im Sinne dieses Abschnitts ist **jede Zeile des B-Blocks mit `Kern = ja`** sowie **jede Regel aus `_core_rules_integrity`** der Berechtigungsdatei. Zusagen der übrigen Blöcke sind **Fähigkeitszusagen**: Ihr Ausfall wird im Pack begründet und im Overlay des aufnehmenden Projekts als bekannte Einschränkung geführt, sperrt die Inbetriebnahme aber nicht.
+| `[TECHNISCH]` | Der Client erzwingt die Zusage, unabhängig vom Verhalten des Modells – nicht unbedingt unabhängig vom Betriebsmodus. Wovon sie im Betriebsmodus abhängt, sagt die Vorbemerkung des B-Blocks; sie ist Pflicht. |
+| `[TEXTUELL]` | Die Zusage steht als Anweisung im Kontext. Das Modell kann ihr folgen; erzwungen ist sie nicht. |
+| `[NICHT ABBILDBAR]` | Der Client bietet keinen Mechanismus; die Zusage entfällt für ihn. |
 
-Die Unterscheidung ist nicht redaktionell. **Eine Kernzusage sagt zu, dass etwas verhindert wird; eine Fähigkeitszusage sagt zu, dass etwas möglich ist** – zum Beispiel, dass man nachsehen kann. Fällt das Erste aus, fehlt eine Schranke. Fällt das Zweite aus, fehlt Sicht. Beides ist ernst, nur das Erste sperrt (`CR-2026-041`, D-41).
+**Kernzusagen** sind die Zeilen des B-Blocks mit `Kern = ja` und jede Regel aus `_core_rules_integrity` der Berechtigungsdatei. Sie sagen zu, dass etwas **verhindert** wird. Alle übrigen Zeilen sind **Fähigkeitszusagen**: Sie sagen zu, dass etwas **möglich** ist, etwa nachzusehen. Fällt eine Kernzusage aus, fehlt eine Schranke; fällt eine Fähigkeitszusage aus, fehlt Sicht. Nur das Erste sperrt die Inbetriebnahme.
 
-**Verbindliche Folgen:**
+Daraus folgt:
 
-- Eine Kernzusage aus `_core_rules_integrity` in der Berechtigungsdatei, die ein Client nicht `[TECHNISCH]` abbildet, MUSS im Client Pack begründet und im Overlay des aufnehmenden Projekts als dokumentierte Ausnahme geführt werden (`.koolie/project-overlay/exceptions/EXCEPTIONS.md`).
-- Ein Client Pack, das eine Kernzusage auf `[NICHT ABBILDBAR]` setzt, DARF nicht ohne Freigabe durch `<SECURITY_CONTACT>` in Betrieb genommen werden.
-- Eine **Fähigkeitszusage** auf `[NICHT ABBILDBAR]` MUSS in derselben Zeile den Ersatz benennen – oder ausdrücklich festhalten, dass es keinen gibt. Ein Ausfall, der nur eingetragen und nicht ersetzt wird, ist eine stillschweigende Verschlechterung. Prüfung 25 meldet eine Zeile, die das unterlässt.
-- Die Einstufung `[TECHNISCH]` MUSS gegen eine reale Installation belegt sein. Bis dahin sagt die Belegzelle `BELEG OFFEN` **mit Grund und Datum** – und, wenn die Frage länger offen bleibt, mit ihrem Klärungspunkt. **Ein Belegstand trägt keine Frist:** Er sagt, was heute belegt ist, nicht, bis wann es belegt sein muss (`CR-2026-121`, D-291).
-- **Eine mit `[DOK]` belegte Matrixzeile MUSS im Belegkopf die Quellenkennung der Liste in Anhang 31.4 nennen** (`QC-n`/`QD-n`). Belegkopf ist die Zelle bis zum ersten Satzbruch; was danach steht, ist Erläuterung, und eine Marke dort ist eine **Nennung** und kein Beleg (D-265). Ein Seitenpfad darf danebenstehen, trägt aber nicht – allein die Kennung lässt sich gegen die Liste halten (D-266). Ein Verweisbeleg (*„wie B3"*) erbt die Kennung seines Ziels. **Gibt der Bestand für eine Zeile keine Seite her, sagt sie `QUELLE NICHT ZUGEORDNET` mit Grund und Datum** – geraten wird nicht, *eine geratene Zuordnung sähe wie ein Beleg aus* (D-156, D-263). **Prüfung 73 setzt es durch.**
-- **Die Marke `[DOK]` belegt gegen die Herstellerdokumentation.** Ein Nachweis des Frameworks über sich selbst – ein Manifestfeld, eine erzeugte Datei – trägt sie nicht und wird als das benannt, was er ist (D-267).
-- **Eine Matrixzeile steht in ihrer Tabelle.** Zwischen ihr und der Trennzeile liegt keine Leerzeile und kein Fremdtext; sonst rendert Markdown sie als Absatz, während die Zusammenfassung des Packs sie weiterzählt (D-264, **Prüfung 74**).
+- Eine Kernzusage, die ein Client nicht `[TECHNISCH]` abbildet, MUSS im Pack begründet und im Overlay des Projekts als Ausnahme geführt werden (`.koolie/project-overlay/exceptions/EXCEPTIONS.md`).
+- Ein Pack mit einer Kernzusage auf `[NICHT ABBILDBAR]` DARF nur mit Freigabe durch `<SECURITY_CONTACT>` in Betrieb gehen.
+- Eine Fähigkeitszusage auf `[NICHT ABBILDBAR]` MUSS in ihrer Zeile den Ersatz nennen oder festhalten, dass es keinen gibt (Prüfung 25).
+- `[TECHNISCH]` MUSS an einer realen Installation belegt sein. Bis dahin sagt die Belegzelle `BELEG OFFEN` mit Grund und Datum. Ein Belegstand hat keine Frist: Er sagt, was heute belegt ist.
+- Eine Zeile mit `[DOK]` nennt im Belegkopf – der Zelle bis zum ersten Satzbruch – die Kennung ihrer Quelle aus Anhang 31.4 (`QC-n`, `QD-n` …). Ein Verweis wie *„wie B3"* erbt die Kennung seines Ziels. Gibt es keine Quelle, steht `QUELLE NICHT ZUGEORDNET` mit Grund und Datum; geraten wird nicht (Prüfung 73).
+- `[DOK]` belegt gegen die Dokumentation des Herstellers. Ein Nachweis von Koolie über sich selbst – ein Manifestfeld, eine erzeugte Datei – trägt die Marke nicht.
+- Eine Matrixzeile steht in ihrer Tabelle, ohne Leerzeile oder Fremdtext davor (Prüfung 74).
 
-Die Delegationsverbote V1 bis V12 (`.koolie/core/framework/core/09-risk-model.md`) sind davon ausgenommen: Sie beschreiben Aufgaben, die nicht delegiert werden dürfen, und sind ihrer Natur nach organisatorisch. Kein Client setzt sie technisch durch; sie sind bei jedem Client `[TEXTUELL]`.
+Die Delegationsverbote V1 bis V12 (`.koolie/core/framework/core/09-risk-model.md`) sind ausgenommen. Sie betreffen Aufgaben, nicht Werkzeuge, und sind bei jedem Client `[TEXTUELL]`.
 
 ## 5. Ein Client Pack erstellen
 
-1. `_template/CLIENT_PACK.md` nach `<client-name>/` kopieren und alle Platzhalter ersetzen. **Die Vorlage trägt nur diesen einen Bestandteil, und das ist eine Entscheidung, keine Lücke (D-336):** `manifest.json` (Schritt 5) und `root-template/` (Schritt 4) entstehen in ihren eigenen Schritten – eine vollständige Vorlage wäre ein Pack ohne Client, und jede Prüfung müsste sie einzeln ausnehmen. `_client_packs()` nimmt die Vorlage nicht in die Packmenge auf, und Prüfung 84 hält fest, dass sie keine Packbestandteile trägt.
-2. Pfadabbildung eintragen: Wo erwartet dieser Client Anweisungsdatei, Regeln, Skills, Berechtigungen, Hooks?
-3. Fähigkeitsmatrix ausfüllen. Jede Zeile ohne Beleg sagt `BELEG OFFEN` mit Grund und Datum. Der B-Block trägt die **Vorbemerkung zur Betriebsmodus-Abhängigkeit** von `[TECHNISCH]`, ergänzt um den eigenen Belegstand (D-35). Keine Prüfung meldet ihr Fehlen – sie ist eine Anweisung, und das ist hier bewusst so entschieden (`CR-2026-033` E4).
-4. `root-template/` anlegen: **nur die erklärende README der Laufzeitschicht**. Die Wurzelartefakte selbst kommen aus dem Kern und werden bei der Installation in die Form dieses Clients gebracht – `seed_paths` bleibt leer (D-20, `CR-2026-010`).
-5. `manifest.json` anlegen: Pflichtfelder `client`, `skills_dir`, `pack_runtime_dir`, `core_skill_prefix`, `core_paths`, `seed_paths`; zusätzlich `runtime_dir`, `root_instruction_file`, `permissions_file`, `agents_dir`, `has_rule_triggers`. Kennt der Client eine **eigene** Bedingungssprache für Regeldateien, kommt `rule_triggers` dazu: Es bildet jeden Ladetrigger der Kernquelle auf sie ab. Ein Ladetrigger ohne Eintrag lässt die Installation scheitern – ersatzloses Verwerfen wäre ein Verlust der Zusage (D-26, D-27).
-6. Semantikabbildung eintragen: `permission_tools`, `permission_tools_bare`, `permission_path_prefix`, `permission_exec_match` und gegebenenfalls `permission_exec_suffix`, `permissions_extra`, `permissions_note`; für die Hooks `hook_tools` und `hook_project_dir_var`. **`hook_tools` führt jedes Werkzeugverb, das die Hook-Quelle nennt**, auch `search`. Kennt der Client kein Werkzeug einer Klasse, wird die Abwesenheit in `hook_tools_absent` **ausdrücklich erklärt**, samt `_hook_tools_absent_note`; eine leere Liste allein bricht die Abbildung ab, und Prüfung 26 verlangt, dass ein so erklärtes Verb auch in `permission_tools` leer ist. **Verwirft das Pack ein zusagentragendes Frontmatter-Feld eines Skills** (`permissions`, `triggers`) über `skill_frontmatter.drop_fields`, muss es den Ersatz benennen – `skill_permissions_ersatz` beziehungsweise `model_invocation_field`; sonst bricht die Installation ab und Prüfung 27 meldet es (D-47, D-50). **Kennt der Client ein Werkzeug, mit dem ein Unteragent gestartet wird, führt `agent_start_tools` seine Namen** – alle Schreibweisen, die der Client annimmt, und gemessen, nicht angenommen. Kennt er keines oder ist es unerhoben, wird die Abwesenheit in `agent_start_tools_absent` **ausdrücklich erklärt**, samt `_agent_start_tools_absent_note`; Prüfung 34 verlangt eines von beidem und lässt ein Pack, das Zeile **A1** auf `[TECHNISCH]` stellt, nicht mit einer Erklärung davonkommen (D-70). **Und `skill_frontmatter.tool_names` wie `agent_frontmatter.tool_names` führen jedes Verb des Frontmatter-Vokabulars** (`read`, `grep`, `glob`, `edit`, `exec`; die Liste steht in `clientmap.FRONTMATTER_VERBEN`). **Führt der Client für das Frontmatter ein eigenes Vokabular, das mit seinen Laufzeit-Werkzeugnamen nicht übereinstimmt, sagt das Pack es in `tool_names_namespace` samt `_tool_names_note`** – Prüfung 38 setzt ihre Richtungsregel dann aus, weil sie sonst zwei Namensräume vergliche (D-88, gemessen bei `devin-desktop`: `glob` wird im Frontmatter angenommen, `find_file_by_name` verworfen, und zur Laufzeit ist es umgekehrt). Bildet der Client ein Verb nicht ab – weil er die Verben selbst als Werkzeugnamen führt oder weil es unerhoben ist –, gehört es in `tool_names_unmapped` samt `_tool_names_unmapped_note`; eine Lücke allein ist keine Aussage (D-78). Prüfung 38 verlangt eines von beidem und hält zugleich die **Richtung** fest: `hook_tools` darf für kein Verbpaar enger sein als `tool_names` – sonst bekäme ein Skill ein Werkzeug vorab freigegeben, das seine eigene Sperre nicht erfasst (D-80). Kennt der Client keine eigene Hook-Datei, zeigt `<HOOKS_FILE>` auf dieselbe Datei wie `<PERMISSIONS_FILE>` – daran wird die Einbettung erkannt. `<CORE_DIR>` wird **nicht** belegt; den setzt die Installation.
-7. **Anweisungs- und Konfigurationsquellen außerhalb des Projekts erheben und eintragen.** Der gleichnamige Abschnitt des Packs führt je bekannter Quelle eine Zeile – Pfad, Ladebedingung, Belegstatus, Maßnahme – **oder** einen datierten Abwesenheitsbeleg samt Erhebungsweg („keine bekannt, Stand `<JJJJ-MM-TT>`, erhoben mit `<Kommando>`"). Er umfasst Regeltexte, Skills und Agentenprofile ebenso wie Berechtigungen, Hooks und Einstellungen (D-34, D-37). Prüfung 19 meldet ein Pack ohne diesen Abschnitt; sie prüft seine **Anwesenheit**, nicht seine Richtigkeit. Kennt der Client eine Importsteuerung für fremde Werkzeugformate, wird sie gesetzt und in Zeile R6 ausgewiesen – abschalten statt nur ausweisen.
-8. Pack in dieser Datei und in `.koolie/core/OWNERS.md` eintragen.
-9. Probeinstallation in ein leeres Verzeichnis; Validator dagegen ausführen; Testkatalog-Basistests gegen eine Installation des Clients fahren.
+1. `_template/CLIENT_PACK.md` nach `<client-name>/` kopieren und alle Platzhalter ersetzen. `manifest.json` und `root-template/` entstehen in eigenen Schritten.
+2. **Pfadabbildung** eintragen: Wo erwartet der Client Anweisungsdatei, Regeln, Skills, Berechtigungen und Hooks?
+3. **Fähigkeitsmatrix** ausfüllen. Jede Zeile ohne Beleg sagt `BELEG OFFEN` mit Grund und Datum. Der B-Block bekommt die Vorbemerkung zur Abhängigkeit vom Betriebsmodus, mit eigenem Belegstand. Keine Prüfung meldet, wenn sie fehlt.
+4. **`root-template/`** anlegen, mit nichts als der erklärenden README der Laufzeitschicht. Alles andere kommt aus dem Kern; `seed_paths` bleibt leer.
+5. **`manifest.json`** anlegen. Pflicht sind `client`, `skills_dir`, `pack_runtime_dir`, `core_skill_prefix` (`koolie-`), `core_paths` und `seed_paths`; dazu kommen `runtime_dir`, `root_instruction_file`, `permissions_file`, `agents_dir` und `has_rule_triggers`. Kennt der Client eine eigene Bedingungssprache für Regeldateien, bildet `rule_triggers` jeden Ladetrigger des Kerns darauf ab – ein Trigger ohne Eintrag lässt die Installation scheitern.
+6. **Semantikabbildung** eintragen:
+   - **Berechtigungen:** `permission_tools`, `permission_tools_bare`, `permission_path_prefix`, `permission_exec_match`, bei Bedarf `permission_exec_suffix`, `permissions_extra` und `permissions_note`.
+   - **Hooks:** `hook_tools` mit jedem Werkzeugverb der Hook-Quelle, auch `search`, und `hook_project_dir_var`. Hat der Client für ein Verb kein Werkzeug, steht das in `hook_tools_absent` samt `_hook_tools_absent_note`; dann ist das Verb auch in `permission_tools` leer (Prüfung 26). Hat der Client keine eigene Hook-Datei, zeigt `<HOOKS_FILE>` auf dieselbe Datei wie `<PERMISSIONS_FILE>`.
+   - **Skill-Frontmatter:** Verwirft das Pack ein zusagentragendes Feld (`permissions`, `triggers`) über `skill_frontmatter.drop_fields`, nennt es den Ersatz in `skill_permissions_ersatz` beziehungsweise `model_invocation_field` (Prüfung 27).
+   - **Unteragenten:** `agent_start_tools` führt jede Schreibweise des Werkzeugs, das einen Unteragenten startet – gemessen, nicht angenommen. Gibt es keines oder ist es unerhoben, steht das in `agent_start_tools_absent` samt Notiz. Eine Zeile **A1** auf `[TECHNISCH]` braucht das Werkzeug (Prüfung 34).
+   - **Werkzeugnamen im Frontmatter:** `skill_frontmatter.tool_names` und `agent_frontmatter.tool_names` führen jedes Verb aus `clientmap.FRONTMATTER_VERBEN` (`read`, `grep`, `glob`, `edit`, `exec`). Ein Verb, das der Client nicht abbildet, steht in `tool_names_unmapped` samt Notiz. Hat der Client für das Frontmatter einen eigenen Namensraum, sagt das `tool_names_namespace` samt `_tool_names_note`. `hook_tools` darf für kein Verb enger sein als `tool_names` – sonst wäre ein Werkzeug vorab freigegeben, das die Sperre nicht erfasst (Prüfung 38).
+   - `<CORE_DIR>` bleibt unbelegt; den setzt die Installation.
+7. **Quellen außerhalb des Projekts** eintragen: je bekannter Quelle eine Zeile mit Pfad, Ladebedingung, Belegstand und Maßnahme – oder ein datierter Abwesenheitsbeleg mit Erhebungsweg (*„keine bekannt, Stand `<JJJJ-MM-TT>`, erhoben mit `<Kommando>`"*). Gemeint sind Regeltexte, Skills und Agentenprofile ebenso wie Berechtigungen, Hooks und Einstellungen; Prüfung 19 verlangt den Abschnitt. Kennt der Client eine Importsteuerung für fremde Formate, wird sie abgeschaltet und in Zeile R6 ausgewiesen.
+8. Das Pack in dieser Datei und in `.koolie/core/OWNERS.md` eintragen.
+9. In ein leeres Verzeichnis installieren, den Validator laufen lassen und die Basistests des Testkatalogs gegen eine Installation des Clients fahren.
 
 ## 6. Verfügbare Client Packs
 
-> **Die Spalte `[TECHNISCH]` wird von Prüfung 31 aus der Fähigkeitsmatrix des jeweiligen Packs nachgerechnet** (D-71): Eine Zahl mit eindeutiger Grenze gehört ausgerechnet, nicht an zweiter Stelle gepflegt.
+> Die Spalte `[TECHNISCH]` rechnet Prüfung 31 aus der Fähigkeitsmatrix des Packs nach.
 
 | Pack | Code | Status | `[TECHNISCH]` | Kernzusagen | Fähigkeitsmatrix belegt |
 |---|---|---|---|---|---|
-| `devin-desktop` | `CP-DD` | pilot | 21 von 36 | 6 von 6 | An einer Installation gemessen sind unter anderem `S3`, `B3`, `B10`, `A1` (`CR-2026-120`), `H1`, `H2`, `R5`, `R6` und `S5`. Genau eine Zeile sagt `BELEG OFFEN`, und dauerhaft: `X2` (`K-20`). ⚠️ **Die Einstufungen `[TECHNISCH]` des B-Blocks gelten nicht im Betriebsmodus `dangerous`** – dort trägt der Schutz-Hook (D-281); die Vorbemerkung des Blocks sagt es |
+| `devin-desktop` | `CP-DD` | pilot | 21 von 36 | 6 von 6 | An einer Installation gemessen sind unter anderem `S3`, `B3`, `B10`, `A1`, `H1`, `H2`, `R5`, `R6` und `S5`. Genau eine Zeile sagt `BELEG OFFEN`, und dauerhaft: `X2`. ⚠️ **Die Einstufungen `[TECHNISCH]` des B-Blocks gelten nicht im Betriebsmodus `dangerous`** – dort trägt der Schutz-Hook; die Vorbemerkung des Blocks sagt es |
 | `openai-codex` | `CP-OC` | pilot | 10 von 35 | **4 von 6** | Alle Belege stammen aus Messungen am Client, keiner aus seiner Dokumentation – das Pack trägt keine `[DOK]`-Zeile, und `FW-AK-01` ist für diesen Client nicht gefahren. Gemessen an einer realen Installation sind `B2`, `B4`, `B6`, `H1` bis `H3`, `R1`, `R5`, `S1` und `S5`; vier Zeilen sagen `BELEG OFFEN` (`S2`, `S3`, `M3`, `M4`), dazu `X2` dauerhaft. 🔴 **Zwei Kernzusagen sind `[NICHT ABBILDBAR]`** – `B3` und `B5` –, und damit greift Abschnitt 4 dieser Datei vollständig: **keine Inbetriebnahme ohne Freigabe durch `<SECURITY_CONTACT>`** |
-| `kiro` | `CP-KI` | pilot | 21 von 35 | 6 von 6 | Gebaut **mit Zugang zum Client** (Kommandozeile 2.24.1, Engine V3): Gemessen an realen Installationen sind unter anderem `R1` bis `R3`, `S1`, `S2`, `S5`, `B1` bis `B8`, `H1` bis `H4` und `M4`; die Zeilen der IDE stehen auf der Dokumentation (`QK-1` bis `QK-9`, `K-162`). Fünf Zeilen sagen `BELEG OFFEN` (`A1`, `A2`, `M3`, `M7`, `X1`), dazu `X2` dauerhaft. 🔴 **Alle Zeilen des B-Blocks stehen unter der Bedingung des aktiven Agenten** – fehlt das Agentenprofil oder ist es kaputt, fällt der Client still auf seinen eingebauten Agenten zurück (Prüfung 96); die Hooks laufen nur in der interaktiven Sitzung |
-| `cursor` | `CP-CU` | pilot | 20 von 35 | 6 von 6 | Gebaut **mit Zugang zum Client** (Kommandozeile 2026.09.26, unter Windows): Gemessen an realen Installationen sind unter anderem `R1` bis `R3`, `S1`, `S3`, `B1` bis `B4`, `B6` bis `B9`, `H1` bis `H4` und `M4`; die Zeilen der IDE stehen auf der Dokumentation (`QU-1` bis `QU-8`, `K-175`). Sieben Zeilen sagen `BELEG OFFEN` (`S4`, `S5`, `A1`, `A2`, `M3`, `M7`, `X1`), dazu `X2` dauerhaft. 🔴 **Die Pfadmuster treffen nur in der Schreibweise mit führendem `*`**, weil der Client sie mit dem absoluten Pfad vergleicht; die Schreibweise für macOS und Linux ist nicht gemessen (`K-176`). **Schreiben im Arbeitsbereich fragt nicht zurück** (`B7`) |
+| `kiro` | `CP-KI` | pilot | 21 von 35 | 6 von 6 | Gebaut **mit Zugang zum Client** (Kommandozeile 2.24.1, Engine V3): Gemessen an realen Installationen sind unter anderem `R1` bis `R3`, `S1`, `S2`, `S5`, `B1` bis `B8`, `H1` bis `H4` und `M4`; die Zeilen der IDE stehen auf der Dokumentation (`QK-1` bis `QK-9`). Fünf Zeilen sagen `BELEG OFFEN` (`A1`, `A2`, `M3`, `M7`, `X1`), dazu `X2` dauerhaft. 🔴 **Alle Zeilen des B-Blocks stehen unter der Bedingung des aktiven Agenten** – fehlt das Agentenprofil oder ist es kaputt, fällt der Client still auf seinen eingebauten Agenten zurück (Prüfung 96); die Hooks laufen nur in der interaktiven Sitzung |
+| `cursor` | `CP-CU` | pilot | 20 von 35 | 6 von 6 | Gebaut **mit Zugang zum Client** (Kommandozeile 2026.09.26, unter Windows): Gemessen an realen Installationen sind unter anderem `R1` bis `R3`, `S1`, `S3`, `B1` bis `B4`, `B6` bis `B9`, `H1` bis `H4` und `M4`; die Zeilen der IDE stehen auf der Dokumentation (`QU-1` bis `QU-8`). Sieben Zeilen sagen `BELEG OFFEN` (`S4`, `S5`, `A1`, `A2`, `M3`, `M7`, `X1`), dazu `X2` dauerhaft. 🔴 **Die Pfadmuster treffen nur in der Schreibweise mit führendem `*`**, weil der Client sie mit dem absoluten Pfad vergleicht; die Schreibweise für macOS und Linux ist nicht gemessen. **Schreiben im Arbeitsbereich fragt nicht zurück** (`B7`) |
 | `claude-code` | `CP-CC` | pilot | 22 von 32 | 6 von 6 | teilweise – Dokumentenabgleich gegen 2.1.267 (AP2), Belegspalte nennt je Zeile die Quelle; **für sechs Zeilen liegen Messungen vor** – S3, S4, A1, die Reichweite von H2, B6 und, zur Hälfte, B2 –, für die übrigen stehen die Wirkungsnachweise aus. **Eine Zeile sagt `BELEG OFFEN`** (`M4`, die Planablage) |
 
 ## 7. Änderungsverlauf
@@ -111,3 +112,4 @@ Die Delegationsverbote V1 bis V12 (`.koolie/core/framework/core/09-risk-model.md
 | 0.7.2 | 2026-09-25 | Die Planablage (Zeile `M4`) steht jetzt in allen drei Matrizen; bei `claude-code` und `openai-codex` als `BELEG OFFEN`. Die Zählungen der Übersicht sind nachgezogen (`CR-2026-147`, D-402, `K-149`) | `<FRAMEWORK_OWNER>` |
 | 0.8.0 | 2026-09-26 | 🟢 **Das vierte Client Pack `kiro`, und mit ihm die dritte Ausgabeform der Berechtigungsdatei: ein Agentenprofil mit Fähigkeitsregeln** (`CR-2026-150`, D-414 bis D-417). Die Menge der formatgebundenen Prüfungen nennt je Eintrag die Formen, die er erreicht; sie führte 76 statt 72 (D-416) | `<FRAMEWORK_OWNER>` |
 | 0.9.0 | 2026-09-26 | 🟢 **Das fünfte Client Pack `cursor`, und mit ihm die vierte Ausgabeform der Berechtigungsdatei: nur `allow` und `deny`, ohne jeden weiteren Schlüssel** (`CR-2026-155`, D-440 bis D-443). Mit einem Kommentarschlüssel startet der Client nicht; die Kernregeln hält **Prüfung 97** gegen die Kernquelle. Die Regelablage trägt eine eigene Endung (`rule_file_ext`) | `<FRAMEWORK_OWNER>` |
+| 0.10.0 | 2026-10-02 | Abschnitte 1 bis 5 neu gefasst, knapper und ohne Entscheidungsgeschichte; Schritt 6 nach Gegenständen gegliedert; `core_skill_prefix` ist `koolie-` (`CR-2026-173`) | `<FRAMEWORK_OWNER>` |

package/.koolie/core/clients/_template/CLIENT_PACK.md

@@ -2,11 +2,11 @@
 
 <!-- AUSFÜLLHINWEIS: Kopiere dieses Verzeichnis nach ../<client-name>/, ersetze alle Platzhalter
      und lege ../<client-name>/root-template/ mit der erklärenden README der Laufzeitschicht sowie
-     ../<client-name>/manifest.json an; die Wurzelartefakte kommen aus dem Kern (../README.md Abschnitt 5, D-20).
+     ../<client-name>/manifest.json an; die Wurzelartefakte kommen aus dem Kern (../README.md Abschnitt 5).
      Trage das Pack in ../README.md Abschnitt 6 und in .koolie/core/OWNERS.md ein.
      Ein Client Pack führt keine Verhaltensregeln ein (../README.md Abschnitt 2).
      Die Statuszelle ist ein Ausfüllschlitz: Ein neues Pack beginnt auf entwurf; der Lebenszyklus
-     steht in .koolie/core/framework/core/01-governance.md Abschnitt 5 (D-104). -->
+     steht in .koolie/core/framework/core/01-governance.md Abschnitt 5. -->
 
 | Attribut | Wert |
 |---|---|
@@ -38,7 +38,7 @@ Wohin dieser Client die Laufzeitartefakte erwartet. Die linke Spalte ist die fra
 
 ## 1a. Semantikabbildung der Berechtigungen und Hooks
 
-Die Regelmenge liegt werkzeugneutral im Kern (`.koolie/core/framework/runtime/permissions.json`, `hooks.json`) und wird bei der Installation übersetzt (D-18). Diese Tabelle ist die menschenlesbare Fassung der Abbildungsfelder im `manifest.json`.
+Die Regelmenge liegt werkzeugneutral im Kern (`.koolie/core/framework/runtime/permissions.json`, `hooks.json`) und wird bei der Installation übersetzt. Diese Tabelle ist die menschenlesbare Fassung der Abbildungsfelder im `manifest.json`.
 
 | Neutrales Werkzeugverb | Werkzeug bei diesem Client | Anmerkung |
 |---|---|---|
@@ -70,8 +70,8 @@ Einstufung je Zusage: `[TECHNISCH]` erzwungen · `[TEXTUELL]` nur Anweisung · `
 | R2 | Weitere Regeldateien lassen sich mit Ladebedingungen versehen (immer, bei Relevanz, manuell) | Laufzeit-README, Abschnitt „Regelablage" | `<TBD>` | `<TBD>` | `<TBD>` |
 | R3 | Regeln lassen sich an Dateimuster binden, damit ein Technology Pack nur bei passenden Dateien lädt | Ebene 5 | `<TBD>` | `<TBD>` | `<TBD>` |
 | R4 | Regelinhalte unterliegen einem bekannten Zeichenlimit, das das Framework einhalten kann | Laufzeit-README der Regelablage | `<TBD>` | `<TBD>` | `<TBD>` |
-| R5 | Die geladenen Regelquellen sind vollständig aufzählbar | D-34, `CR-2026-031` | `<TBD>` | `<TBD>` | `<TBD>` |
-| R6 | Das Framework importiert keine Regel- und Skillquellen fremder Werkzeugformate | D-37, `CR-2026-038` | `<TBD>` – kennt der Client keine Importsteuerung, ist die Zeile `[NICHT ABBILDBAR]`, und es bleibt bei der Auskunft in Abschnitt 7 | `<TBD>` | `<TBD>` |
+| R5 | Die geladenen Regelquellen sind vollständig aufzählbar | `governance/PRIORITY_HIERARCHY.md` | `<TBD>` | `<TBD>` | `<TBD>` |
+| R6 | Das Framework importiert keine Regel- und Skillquellen fremder Werkzeugformate | `clients/README.md` | `<TBD>` – kennt der Client keine Importsteuerung, ist die Zeile `[NICHT ABBILDBAR]`, und es bleibt bei der Auskunft in Abschnitt 7 | `<TBD>` | `<TBD>` |
 
 ### S – Skills
 
@@ -81,13 +81,13 @@ Einstufung je Zusage: `[TECHNISCH]` erzwungen · `[TEXTUELL]` nur Anweisung · `
 | S2 | Ein Skill ist gezielt aufrufbar | dito | `<TBD>` | `<TBD>` | `<TBD>` |
 | S3 | Ein Skill kann die ihm erlaubten Werkzeuge einschränken (lesende Skills schreiben nicht) | dito | `<TBD>` | `<TBD>` | `<TBD>` |
 | S4 | Schreibende Skills sind nur benutzergetriggert, nicht modellgetriggert – die Zusage gilt für die Skill-Ablage, die das Framework schreibt | dito | `<TBD>` | `<TBD>` | `<TBD>` |
-| S5 | Die geladenen Skills sind vollständig aufzählbar, samt Herkunft und Aufrufbarkeit | `CR-2026-032` | `<TBD>` | `<TBD>` | `<TBD>` |
+| S5 | Die geladenen Skills sind vollständig aufzählbar, samt Herkunft und Aufrufbarkeit | `install.py --list-skills` | `<TBD>` | `<TBD>` | `<TBD>` |
 
 ### B – Berechtigungen
 
-> **`[TECHNISCH]` heißt in diesem Block:** Die Engine setzt die Regel durch, **solange der Betriebsmodus die Berechtigungsprüfung nicht abschaltet** (D-35). Schaltet sie der Modus ohne Rückfragen ab, den D-05 untersagt, trägt allein der Schutz-Hook. Diese Vorbemerkung ist **Pflicht** in jedem Pack; sie ist je Client um den eigenen Belegstand zu ergänzen – erhoben oder ausdrücklich nicht erhoben.
+> **`[TECHNISCH]` heißt in diesem Block:** Die Engine setzt die Regel durch, **solange der Betriebsmodus die Berechtigungsprüfung nicht abschaltet**. Schaltet sie der Modus ohne Rückfragen ab, den `03-security.md` Abschnitt 4 untersagt, trägt allein der Schutz-Hook. Diese Vorbemerkung ist **Pflicht** in jedem Pack; sie ist je Client um den eigenen Belegstand zu ergänzen – erhoben oder ausdrücklich nicht erhoben.
 
-Die mit **Kern** markierten Zeilen entsprechen `_core_rules_integrity` in der Berechtigungsdatei, sofern sie JSON ist (D-395). Eine Abweichung von `[TECHNISCH]` ist dort begründungspflichtig.
+Die mit **Kern** markierten Zeilen entsprechen `_core_rules_integrity` in der Berechtigungsdatei, sofern sie JSON ist. Eine Abweichung von `[TECHNISCH]` ist dort begründungspflichtig.
 
 | ID | Zusage des Frameworks | Kern | Mechanismus beim Client | Einstufung | Beleg |
 |---|---|---|---|---|---|
@@ -109,31 +109,31 @@ Die mit **Kern** markierten Zeilen entsprechen `_core_rules_integrity` in der Be
 | H1 | Vor einer Werkzeugausführung kann eine eigene Prüfung laufen | Hook-Konfiguration | `<TBD>` | `<TBD>` | `<TBD>` |
 | H2 | Diese Prüfung kann die Ausführung **blockieren** (nicht nur protokollieren) | dito | `<TBD>` | `<TBD>` | `<TBD>` |
 | H3 | Beim Sitzungsstart kann eine Statusmeldung erzeugt werden (Overlay aktiv, Version) | dito | `<TBD>` | `<TBD>` | `<TBD>` |
-| H4 | Der Schutz-Hook prüft das Eingabeschema und die Pfadidentität; die Zeile nennt die Zeitlücke zwischen Prüfung und Zugriff | D-63 | `<TBD>` | `<TBD>` | `<TBD>` |
+| H4 | Der Schutz-Hook prüft das Eingabeschema und die Pfadidentität; die Zeile nennt die Zeitlücke zwischen Prüfung und Zugriff | `03-security.md` Abschnitt 4 | `<TBD>` | `<TBD>` | `<TBD>` |
 
 ### A – Agentenprofile
 
 | ID | Zusage des Frameworks | Quelle | Mechanismus beim Client | Einstufung | Beleg |
 |---|---|---|---|---|---|
-| A1 | Ein rein lesendes Reviewprofil ist definierbar | `.koolie/core/framework/runtime/agents/fw-reviewer.md` | `<TBD>` | `<TBD>` | `<TBD>` |
-| A2 | Ein rein lesendes Analyseprofil für Modus M1 ist verfügbar | D-05 | `<TBD>` | `<TBD>` | `<TBD>` |
+| A1 | Ein rein lesendes Reviewprofil ist definierbar | `.koolie/core/framework/runtime/agents/koolie-reviewer.md` | `<TBD>` | `<TBD>` | `<TBD>` |
+| A2 | Ein rein lesendes Analyseprofil für Modus M1 ist verfügbar | `05-working-model.md` M1 | `<TBD>` | `<TBD>` | `<TBD>` |
 
 ### M – Modi und Sitzungsfreigaben
 
 | ID | Zusage des Frameworks | Quelle | Mechanismus beim Client | Einstufung | Beleg |
 |---|---|---|---|---|---|
-| M1 | Es gibt einen Standardmodus, der bei Schreiben und Befehlen rückfragt | D-05 | `<TBD>` | `<TBD>` | `<TBD>` |
-| M2 | Ein Modus, der alle Rückfragen übergeht, lässt sich organisatorisch oder technisch ausschließen | D-05 | `<TBD>` | `<TBD>` | `<TBD>` |
+| M1 | Es gibt einen Standardmodus, der bei Schreiben und Befehlen rückfragt | `03-security.md` Abschnitt 4 | `<TBD>` | `<TBD>` | `<TBD>` |
+| M2 | Ein Modus, der alle Rückfragen übergeht, lässt sich organisatorisch oder technisch ausschließen | `03-security.md` Abschnitt 4 | `<TBD>` | `<TBD>` | `<TBD>` |
 | M3 | Eine erteilte Freigabe lässt sich auf die Sitzung begrenzen, statt sie dauerhaft zu speichern | Laufzeit-README | `<TBD>` | `<TBD>` | `<TBD>` |
-| M6 | Ein Modus mit selbsttätiger Übernahme von Dateiänderungen lässt sich begrenzen | D-05 | `<TBD>` | `<TBD>` | `<TBD>` |
-| M7 | Ein Modus, der selbst beurteilt, was sicher ist, lässt sich begrenzen | D-05 | `<TBD>` | `<TBD>` | `<TBD>` |
+| M6 | Ein Modus mit selbsttätiger Übernahme von Dateiänderungen lässt sich begrenzen | `03-security.md` Abschnitt 4 | `<TBD>` | `<TBD>` | `<TBD>` |
+| M7 | Ein Modus, der selbst beurteilt, was sicher ist, lässt sich begrenzen | `03-security.md` Abschnitt 4 | `<TBD>` | `<TBD>` | `<TBD>` |
 
 ### X – Externe Anbindung
 
 | ID | Zusage des Frameworks | Quelle | Mechanismus beim Client | Einstufung | Beleg |
 |---|---|---|---|---|---|
-| X1 | Externe Systeme sind standardmäßig nicht angebunden; jede Anbindung ist eine Einzelfreigabe | K-10, D-10 | `<TBD>` | `<TBD>` | `<TBD>` |
-| X2 | Ob und wohin Quellcode zur Indexierung abfließt, ist bekannt und dokumentiert | K-20 | `<TBD>` | `<TBD>` | `<TBD>` |
+| X1 | Externe Systeme sind standardmäßig nicht angebunden; jede Anbindung ist eine Einzelfreigabe | `03-security.md` Abschnitt 2 (T8) | `<TBD>` | `<TBD>` | `<TBD>` |
+| X2 | Ob und wohin Quellcode zur Indexierung abfließt, ist bekannt und dokumentiert | `02-privacy.md` | `<TBD>` | `<TBD>` | `<TBD>` |
 
 ## 3. Zusammenfassung der Durchsetzungstiefe
 
@@ -166,7 +166,7 @@ Vor der ersten produktiven Nutzung sind die Basistests des Testkatalogs (`.kooli
 
 ## 7. Anweisungs- und Konfigurationsquellen außerhalb des Projekts
 
-**Pflichtabschnitt.** Er führt, was dieser Client aus Ablagen **außerhalb des Repositoriums** lädt. Solche Quellen haben nach Regel 2.6 der Prioritätshierarchie **keine Ebene**: Sie dürfen einschränken, nie über die Ebenen 1 bis 4 hinaus erweitern und keine Governance-, Datenschutz- oder Sicherheitsregeln setzen (D-34). Prüfung 19 meldet ein Pack ohne diesen Abschnitt.
+**Pflichtabschnitt.** Er führt, was dieser Client aus Ablagen **außerhalb des Repositoriums** lädt. Solche Quellen haben nach Regel 2.6 der Prioritätshierarchie **keine Ebene**: Sie dürfen einschränken, nie über die Ebenen 1 bis 4 hinaus erweitern und keine Governance-, Datenschutz- oder Sicherheitsregeln setzen. Prüfung 19 meldet ein Pack ohne diesen Abschnitt.
 
 **Erhebungsstand: `<TBD: JJJJ-MM-TT>`**, Clientversion `<TBD>`, erhoben mit `<TBD: Kommandos oder Messweg>`.
 
@@ -180,7 +180,7 @@ Regeltexte, Skills, Agentenprofile. Je bekannter Quelle eine Zeile – **oder**
 
 ### 7.2 Konfigurationsquellen
 
-Berechtigungen, Hooks und Einstellungen außerhalb des Repositoriums – sie betreffen genau die Linien, auf denen B1 bis B6 stehen (`CR-2026-038`).
+Berechtigungen, Hooks und Einstellungen außerhalb des Repositoriums – sie betreffen genau die Linien, auf denen B1 bis B6 stehen.
 
 | Quelle | Wirkung | Belegstatus |
 |---|---|---|