@renoxar/koolie 1.25.0

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

@@ -0,0 +1,113 @@
+# Client Packs – Abbildung des Frameworks auf einen KI-Client
+
+| Attribut | Wert |
+|---|---|
+| Modul-ID | `FW-CLIENT-PACKS` |
+| Ebene | keine – Querschnittsschicht (siehe Abschnitt 2) |
+| Version | 0.9.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.
+
+Ein **Client Pack** macht diese Bindung explizit und austauschbar. Es beantwortet für genau einen Client zwei Fragen:
+
+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.
+
+## 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.
+
+## 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) |
+
+**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.
+
+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:
+
+| Zusicherung | Warum |
+|---|---|
+| 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 |
+
+## 4. Die Fähigkeitsmatrix
+
+Kern jedes Client Packs. Sie stuft jede technische Zusage des Frameworks 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.
+
+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).
+
+**Verbindliche Folgen:**
+
+- 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**).
+
+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]`.
+
+## 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.
+
+## 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.
+
+| 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 |
+| `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`) |
+| `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
+
+| Version | Datum | Änderung | Autor (Rolle) |
+|---|---|---|---|
+| 0.1.0 | 2026-09-10 | angelegt (`CR-2026-002`) | `<FRAMEWORK_OWNER>` |
+| 0.2.0 | 2026-09-10 | Semantikabbildung der Berechtigungen und Hooks ergänzt (`CR-2026-008`) | `<FRAMEWORK_OWNER>` |
+| 0.3.0 | 2026-09-10 | Restduplikation zusammengeführt; ein Pack umfasst vier Dateien (`CR-2026-010`) | `<FRAMEWORK_OWNER>` |
+| 0.4.0 | 2026-09-11 | **Auskunftspflicht über Quellen außerhalb des Projekts** als Schritt beim Anlegen eines Packs (`CR-2026-031`, `CR-2026-038`; D-34, D-37); die Definition von `[TECHNISCH]` nennt die Abhängigkeit vom **Betriebsmodus** (`CR-2026-033`, D-35), der B-Block jedes Packs trägt sie als Pflicht-Vorbemerkung; ein Pack umfasst noch **eine** erklärende README, die der Regelablage ist in die Laufzeit-README aufgegangen (`CR-2026-035`, D-36) | `<FRAMEWORK_OWNER>` |
+| 0.5.0 | 2026-09-13 | **Die Übersicht führte zwei Zahlen, die niemand nachrechnete – beide falsch (`CR-2026-058` E7, D-71).** `claude-code` stand auf „25 von 29", während das Pack selbst einen Absatz darüber trägt, dass diese Zahl mit 0.33.0 auf **22 von 31** berichtigt wurde; `devin-desktop` auf „24 von 34" statt **20 von 36**. Prüfung 31 rechnet die Spalte künftig aus der Fähigkeitsmatrix nach. Die Zahl der offenen VERIFY-Marker entfällt hier und verweist auf das Pack: Ihre Grenze ist zur Hälfte Ermessen, und eine gezählte Zahl wäre dort eine Genauigkeit, die es nicht gibt. Neu in Schritt 6: `agent_start_tools` und seine erklärte Abwesenheit (D-70) | `<FRAMEWORK_OWNER>` |
+| 0.6.0 | 2026-09-22 | 🟢 **Die Markerform ist abgeschafft; eine Zeile ohne Beleg sagt `BELEG OFFEN` mit Grund und Datum** (`CR-2026-121`, D-291). 🔴 **Der Unterschied ist keine Schreibweise, sondern die Frist:** Das Platzhalterregister schrieb der Markerform *„vor Version 1.0.0"* vor; ein Belegstand trägt keine Frist. *Eine Frage, die dauerhaft nicht beobachtbar ist, kann keine Frist einhalten* – und `X2` des Packs `devin-desktop` hat sie achtundneunzig Releases lang als Rückstand geführt (D-292) | `<FRAMEWORK_OWNER>` |
+| 0.7.0 | 2026-09-23 | 🟢 **Das dritte Client Pack ist da, und mit ihm die zweite Ausgabeform der Berechtigungsdatei** (`CR-2026-133`, D-346 bis D-349). Die Regelmenge des Kerns zerfällt bei `openai-codex` in **zwei** Erzeugnisse: Pfade in einer TOML-Tabelle, Befehle in einer eigenen Regelsprache. 🔴 **Sechs Prüfungen lesen die Form `json` und erreichen dieses Pack deshalb nicht** – sie stehen seit `1.4.0` in `FORMATGEBUNDENE_PRUEFUNGEN`, und **Prüfung 87** verlangt ihre Nennung in Abschnitt 5 des Packs. *Eine Lücke, die erklärt ist, ist eine Aussage; eine, die nur besteht, ist ein blinder Fleck.* 🔴 **Und der Schutz-Hook hat bei diesem Client zunächst nichts gesperrt:** Seine Sperrform war clientgebunden, ohne dass es irgendwo stand (**Prüfung 86**, D-347) | `<FRAMEWORK_OWNER>` |
+| 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>` |

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

@@ -0,0 +1,197 @@
+# Client Pack `<CLIENT_PACK_NAME>` – Vorlage
+
+<!-- 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).
+     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). -->
+
+| Attribut | Wert |
+|---|---|
+| Modul-ID | `CP-<CLIENT_PACK_CODE>` |
+| Ebene | keine – Abbildungsschicht |
+| Version | 0.3.3 |
+| Status | `<TBD: Status; ein neues Pack beginnt auf entwurf>` |
+| Owner (Rolle) | `<TBD: Rolle>` |
+| Client | `<TBD: Produktname>` |
+| Verbindliche Zielversion | `<TBD: Versionsspanne, für die dieses Pack gilt, z. B. 4.2.x>` |
+| Geprüfte Clientversion | `<TBD: Punktversion, an der gemessen wurde; ohne diese Angabe ist keine Einstufung [TECHNISCH] zulässig>` |
+| Datum der Prüfung | `<TBD: JJJJ-MM-TT>` |
+
+## 1. Pfadabbildung
+
+Wohin dieser Client die Laufzeitartefakte erwartet. Die linke Spalte ist die framework-interne Rolle des Artefakts und bleibt über alle Client Packs gleich.
+
+| Rolle des Artefakts | Pfad bei diesem Client | Belegstatus |
+|---|---|---|
+| Wurzel-Anweisungsdatei | `<TBD>` | `<TBD>` |
+| Regeldateien (Core-Kurzfassungen, Overlay, Packs) | `<TBD: Pfad oder „kein Äquivalent">` | `<TBD>` |
+| Skills | `<TBD>` | `<TBD>` |
+| Subagentenprofile | `<TBD: Pfad oder „kein Äquivalent">` | `<TBD>` |
+| Berechtigungskonfiguration | `<TBD>` (erzeugt aus `framework/runtime/permissions.json`) | `<TBD>` |
+| Hook-Konfiguration | `<TBD: eigene Datei, derselbe Pfad wie die Berechtigungsdatei, oder „kein Äquivalent">` | `<TBD>` |
+| MCP-Konfiguration | `<TBD>` | `<TBD>` |
+| Projektverzeichnis-Variable in Hooks | `<TBD: z. B. Name der Umgebungsvariable>` | `<TBD>` |
+| Nutzerlokale Überschreibung | `<TBD>` | `<TBD>` |
+
+## 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`.
+
+| Neutrales Werkzeugverb | Werkzeug bei diesem Client | Anmerkung |
+|---|---|---|
+| `read` | `<TBD>` | |
+| `search` | `<TBD: Werkzeug oder „kein Äquivalent">` | ohne Äquivalent entfällt nur die `allow`-Regel |
+| `write` | `<TBD: ein Werkzeug oder getrennte für Ändern und Anlegen>` | |
+| `exec` | `<TBD>` | wörtlich oder präfixbasiert? |
+| `fetch` | `<TBD>` | |
+| `mcp` | `<TBD>` | |
+
+| Weitere Eigenschaft | Wert |
+|---|---|
+| Name ohne Verzeichnisanteil | `<TBD: mit oder ohne Wurzelangabe>` |
+| Zusätzliche Schlüssel | `<TBD: z. B. ein Standardmodus>` |
+| Hook-Werkzeugnamen | `<TBD>` |
+| Projektverzeichnis im Hook-Befehl | `<TBD: Name der Umgebungsvariable>` |
+
+Drei Zusicherungen werden erzwungen und sind nicht verhandelbar: Eine `deny`- oder `ask`-Regel ohne Zielwerkzeug lässt die Installation scheitern (Weglassen wäre eine Lockerung); die Präfixform eines Befehlsverbots muss ein Präfix seiner wörtlichen Form sein; bei `allow` müssen beide Formen übereinstimmen. Lässt sich eine Kernzusage danach nicht abbilden, gehört sie in Abschnitt 4 und nicht in eine Ausnahme im Code.
+
+## 2. Fähigkeitsmatrix
+
+Einstufung je Zusage: `[TECHNISCH]` erzwungen · `[TEXTUELL]` nur Anweisung · `[NICHT ABBILDBAR]` kein Mechanismus. Regeln in `../README.md` Abschnitt 4.
+
+### R – Regelladung
+
+| ID | Zusage des Frameworks | Quelle | Mechanismus beim Client | Einstufung | Beleg |
+|---|---|---|---|---|---|
+| R1 | Die Wurzel-Anweisungsdatei wird zu Beginn jeder Sitzung ungefragt geladen | `.koolie/core/framework/runtime/root-instruction.md` | `<TBD>` | `<TBD>` | `<TBD>` |
+| 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>` |
+
+### S – Skills
+
+| ID | Zusage des Frameworks | Quelle | Mechanismus beim Client | Einstufung | Beleg |
+|---|---|---|---|---|---|
+| S1 | Standardaufgaben liegen als versionierte Skills im Repository | `.koolie/core/framework/core/08-skill-conventions.md` | `<TBD>` | `<TBD>` | `<TBD>` |
+| 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>` |
+
+### 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.
+
+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.
+
+| ID | Zusage des Frameworks | Kern | Mechanismus beim Client | Einstufung | Beleg |
+|---|---|---|---|---|---|
+| B1 | Berechtigungen liegen versioniert im Repository, nicht nur je Arbeitsplatz | ja | `<TBD>` | `<TBD>` | `<TBD>` |
+| B2 | Dreistufige Semantik: verweigern vor rückfragen vor erlauben | ja | `<TBD>` | `<TBD>` | `<TBD>` |
+| B3 | Lesezugriff auf Secret-Dateien ist per Pfadmuster verweigerbar (`.env`, `*.pem`, `*.key`, `secrets/**`) | ja | `<TBD>` | `<TBD>` | `<TBD>` |
+| B4 | Schreibzugriff auf Framework- und Overlay-Artefakte ist verweigerbar, einschließlich des Kernverzeichnisses als Ganzes | ja | `<TBD>` | `<TBD>` | `<TBD>` |
+| B5 | Schreibzugriff auf CI-, Quality-Gate- und Lockdateien ist verweigerbar | ja | `<TBD>` | `<TBD>` | `<TBD>` |
+| B6 | Befehle sind per Muster verweigerbar (`git push`, `git merge`, `rm -rf`, `sudo`) | ja | `<TBD>` | `<TBD>` | `<TBD>` |
+| B7 | Schreiboperationen lösen standardmäßig eine Rückfrage aus | – | `<TBD>` | `<TBD>` | `<TBD>` |
+| B8 | Netzwerkzugriff ist standardmäßig unterbunden | – | `<TBD>` | `<TBD>` | `<TBD>` |
+| B9 | Eine nutzerlokale Konfiguration kann nur verschärfen, nicht lockern | – | `<TBD>` | `<TBD>` | `<TBD>` |
+| B10 | Externer Abruf ist auf freigegebene Domains beschränkbar | – | `<TBD>` | `<TBD>` | `<TBD>` |
+
+### H – Hooks
+
+| ID | Zusage des Frameworks | Quelle | Mechanismus beim Client | Einstufung | Beleg |
+|---|---|---|---|---|---|
+| 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>` |
+
+### 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>` |
+
+### 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>` |
+| 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>` |
+
+### 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>` |
+
+## 3. Zusammenfassung der Durchsetzungstiefe
+
+| Klasse | Anzahl | davon Kernzusagen |
+|---|---|---|
+| `[TECHNISCH]` | `<TBD>` | `<TBD>` |
+| `[TEXTUELL]` | `<TBD>` | `<TBD>` |
+| `[NICHT ABBILDBAR]` | `<TBD>` | `<TBD>` |
+
+## 4. Kernzusagen ohne technische Durchsetzung
+
+Jede Kernzusage (Spalte **Kern** = ja) mit einer anderen Einstufung als `[TECHNISCH]` wird hier einzeln geführt. Ohne Eintrag in dieser Tabelle darf das Pack nicht in Betrieb gehen.
+
+| ID | Einstufung | Warum der Client das nicht durchsetzt | Ersatzmaßnahme | Freigabe |
+|---|---|---|---|---|
+| `<TBD>` | `<TBD>` | `<TBD>` | `<TBD: z. B. Hook, externe Prüfung, verschärfter Prozessschritt>` | `<SECURITY_CONTACT>` |
+
+## 5. Bekannte Abweichungen im Verhalten
+
+`<TBD: Was sich gegenüber anderen Client Packs unterscheidet, ohne eine Zusage zu verletzen – etwa fehlende Ladetrigger, andere Skill-Auffindung, abweichende Frontmatter-Felder>`
+
+## 6. Installation und Prüfung
+
+```text
+python .koolie/core/install.py --client <TBD: Kurzname>
+python .koolie/core/tests/scripts/validate-framework.py
+```
+
+Vor der ersten produktiven Nutzung sind die Basistests des Testkatalogs (`.koolie/core/tests/TEST_CATALOG.md`, Kennzeichnung „Basis") gegen diesen Client zu fahren und zu protokollieren.
+
+## 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.
+
+**Erhebungsstand: `<TBD: JJJJ-MM-TT>`**, Clientversion `<TBD>`, erhoben mit `<TBD: Kommandos oder Messweg>`.
+
+### 7.1 Anweisungsquellen
+
+Regeltexte, Skills, Agentenprofile. Je bekannter Quelle eine Zeile – **oder** die ausdrückliche Angabe „keine bekannt" mit Datum und Erhebungsweg. Ein Abwesenheitsbeleg ist ein Ergebnis; ein leerer Abschnitt ist keines.
+
+| Quelle | Ladebedingung | Belegstatus | Maßnahme des Frameworks |
+|---|---|---|---|
+| `<TBD: Pfad>` | `<TBD>` | `<TBD>` | `<TBD>` |
+
+### 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`).
+
+| Quelle | Wirkung | Belegstatus |
+|---|---|---|
+| `<TBD: Pfad>` | `<TBD>` | `<TBD>` |
+
+### 7.3 Was dieser Abschnitt nicht leistet
+
+**Eine Auskunft ist keine Schranke**, und ein **Abwesenheitsbeleg altert**: Am Tag der nächsten Clientversion ist er eine Aussage über die Vergangenheit. Prüfung 19 prüft die **Anwesenheit** dieser Auskunft, nicht ihre Richtigkeit – die hängt an einer Erhebung, nicht an einem Skript.
+
+## 8. Änderungsverlauf
+
+| Version | Datum | Änderung | Autor (Rolle) |
+|---|---|---|---|
+| 0.1.0 | `<TBD>` | angelegt | `<TBD>` |