@renoxar/koolie 1.25.0 → 2.0.0

package/.koolie/core/clients/claude-code/CLIENT_PACK.md

@@ -4,24 +4,22 @@
 |---|---|
 | Modul-ID | `CP-CC` |
 | Ebene | keine – Abbildungsschicht |
-| Version | 0.26.4 |
+| Version | 0.27.0 |
 | Status | pilot |
 | Owner (Rolle) | `<FRAMEWORK_OWNER>` |
 | Client | Claude Code |
-| Verbindliche Zielversion | `2.1.x` (D-112). Die Spanne ist der Geltungsbereich dieses Packs; der gemessene Punktwert steht in der Zeile darunter (D-113). **Für dieses Pack ist die Spanne festgelegt, nicht erhoben** – erhoben ist der Punktwert |
-| Geprüfte Clientversion | 2.1.267 (AP2-Dokumentenabgleich, `tests/protocols/2026-09-10-AP2-claude-code.md`). **Am 2026-09-16 war auf dem Arbeitsplatz des Frameworks 2.1.273 installiert** – sechs Patchstände weiter, in derselben Zielspanne |
-| Stand der Produktbeobachtung | **2026-09-18, gegen 2.1.275** (`FW-AK-01`, `tests/protocols/2026-09-18-FW-AK-01.md`). Der Dokumentenabgleich der fünf Quellen `QC-1` bis `QC-5` und der Changelog der Stände 2.1.268 bis 2.1.275 sind gefahren; die Zielspanne `2.1.x` trägt weiter. **Zwei Befunde blieben, beide neue Anweisungs- beziehungsweise Skillquellen außerhalb des Repositoriums** – siehe `S4`, `S5`, `X1` und `K-63` |
-| Datum der Prüfung | 2026-09-10 – Dokumentenabgleich und Prüfung der erzeugten Artefakte; Wirkungsnachweise in laufenden Sitzungen folgten ab 2026-09-12 für einzelne Zeilen (Abschnitt 3, Belegstand) |
-
-> **Teilweise belegt.** Die Zeilen mit `[DOK]` sind gegen die Herstellerdokumentation
-> abgeglichen – zuerst gegen Clientversion 2.1.267 und eine reale Erstinstallation
-> (AP2, `tests/protocols/2026-09-10-AP2-claude-code.md`), zuletzt in der Produktbeobachtung
-> `FW-AK-01` gegen 2.1.275; die Zielspanne `2.1.x` ist festgelegt (D-112). **Zwei Einstufungen stehen auf `[NICHT ABBILDBAR]`: S5 und B10** – beide keine
-> Kernzusage (D-41), je mit benanntem Ersatz in der Zeile. Wirkungsnachweise aus laufenden
-> Sitzungen liegen für einen Teil der Zeilen vor; welche, steht in Abschnitt 3. Für die übrigen
-> gilt: Ein Dokumentenabgleich belegt `[DOK]`, nicht beobachtete Durchsetzung.
+| Verbindliche Zielversion | `2.1.x`. Die Spanne ist der Geltungsbereich dieses Packs und festgelegt; gemessen ist der Punktwert in der Zeile darunter |
+| Geprüfte Clientversion | 2.1.267 (Dokumentenabgleich, `tests/protocols/2026-09-10-AP2-claude-code.md`); einzelne Zeilen sind gegen spätere Stände derselben Spanne gemessen, ihre Belegspalte nennt den Stand |
+| Stand der Produktbeobachtung | 2026-09-18, gegen 2.1.275 (`FW-AK-01`, `tests/protocols/2026-09-18-FW-AK-01.md`): Dokumentenabgleich der Quellen `QC-1` bis `QC-5` und Changelog 2.1.268 bis 2.1.275; die Zielspanne trägt. Zwei neue Quellen außerhalb des Repositoriums – siehe `S4`, `S5` und `X1` |
+| Datum der Prüfung | 2026-09-10 (Dokumentenabgleich und erzeugte Artefakte); Messungen in laufenden Sitzungen ab 2026-09-12, siehe Abschnitt 3 |
+
+> **Teilweise belegt.** Zeilen mit `[DOK]` sind gegen die Herstellerdokumentation abgeglichen,
+> zuerst gegen 2.1.267 und eine reale Erstinstallation, zuletzt in der Produktbeobachtung gegen
+> 2.1.275. Zwei Zeilen stehen auf `[NICHT ABBILDBAR]`, S5 und B10; beide sind keine Kernzusage und
+> nennen ihren Ersatz. Welche Zeilen in laufenden Sitzungen gemessen sind, steht in Abschnitt 3;
+> für die übrigen belegt der Abgleich `[DOK]`, nicht beobachtete Durchsetzung.
 >
-> **Zur Lesart der Spalten.** Die Spalte „Einstufung" nennt die **vorgesehene** Durchsetzungstiefe, die Spalte „Beleg" ihren Nachweisstand: `[DOK]` = in der Herstellerdokumentation beschrieben, `[EMPF]` = Empfehlung des Frameworks, `BELEG OFFEN` = noch nicht belegt, mit Grund und Datum in der Zelle – ohne Frist (D-291).
+> **Lesart der Spalten.** „Einstufung" nennt die vorgesehene Durchsetzungstiefe, „Beleg" ihren Nachweisstand: `[DOK]` = in der Herstellerdokumentation beschrieben, `[EMPF]` = Empfehlung des Frameworks, `BELEG OFFEN` = noch nicht belegt, mit Grund und Datum in der Zelle.
 
 ## 1. Pfadabbildung
 
@@ -35,20 +33,20 @@ Maschinenlesbar in `manifest.json`; diese Tabelle ist die menschenlesbare Fassun
 | Subagentenprofile | `.claude/agents/<name>.md`, Frontmatter-Feld `tools` | [DOK] `docs/en/sub-agents` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) |
 | Berechtigungskonfiguration | `.claude/settings.json` (erzeugt aus `framework/runtime/permissions.json`) | `[DOK]` Mechanismus `docs/en/settings`; Mustersemantik [DOK] `docs/en/permissions` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) – gitignore-Syntax, Einzelheiten bei B3. **Pfadregeln werden nur für `Read` und `Edit` ausgewertet**, siehe Abschnitt 7 |
 | Hook-Konfiguration | `.claude/settings.json` (**keine eigene Datei**; erzeugt aus `framework/runtime/hooks.json` und in dieselbe Datei eingebettet) | `[DOK]` |
-| MCP-Konfiguration | `.mcp.json` (Vorlage: `.mcp.json.example`) | `[DOK]`; **gemessen am 2026-09-28** (2.1.283, Vorprüfung zu `1.18.0`): Ein Server `"type": "http"` mit `"headers"` lädt auch im Druckmodus, und eine Kopfzeile `"Authorization": "Basic ${VARIABLE}"` wird aus der Umgebung gefüllt – die versionierte Datei trägt keinen Zugang (D-456). Ein Server der Projektdatei lädt erst nach Zustimmung (`enabledMcpjsonServers` im Projekteintrag des Benutzers) |
+| MCP-Konfiguration | `.mcp.json` (Vorlage: `.mcp.json.example`) | `[DOK]`; **gemessen am 2026-09-28** (2.1.283, Vorprüfung zu `1.18.0`): Ein Server `"type": "http"` mit `"headers"` lädt auch im Druckmodus, und eine Kopfzeile `"Authorization": "Basic ${VARIABLE}"` wird aus der Umgebung gefüllt – die versionierte Datei trägt keinen Zugang. Ein Server der Projektdatei lädt erst nach Zustimmung (`enabledMcpjsonServers` im Projekteintrag des Benutzers) |
 | Projektverzeichnis-Variable in Hooks | `CLAUDE_PROJECT_DIR` | `[DOK]` |
 | Nutzerlokale Überschreibung | `CLAUDE.local.md`, `.claude/settings.local.json` | `[DOK]` |
 
 ## 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 in die Werkzeuge dieses Clients übersetzt (D-18). Was dabei abgebildet wird, steht maschinenlesbar im `manifest.json`; diese Tabelle ist die menschenlesbare Fassung. Dieser Client ist der Grund, weshalb es die Abbildungsschicht überhaupt braucht: Vier der sechs Zeilen sind keine Umbenennung, sondern eine andere Mengenlehre.
+Die Regelmenge liegt werkzeugneutral im Kern (`.koolie/core/framework/runtime/permissions.json`, `hooks.json`) und wird bei der Installation in die Werkzeuge dieses Clients übersetzt. Was dabei abgebildet wird, steht maschinenlesbar im `manifest.json`; diese Tabelle ist die menschenlesbare Fassung. Vier der sechs Zeilen sind keine Umbenennung, sondern bilden eine andere Semantik ab.
 
 | Neutrales Werkzeugverb | Werkzeug bei diesem Client | Anmerkung |
 |---|---|---|
 | `read` | `Read(muster)` | |
-| `search` | – | Die eigenen Suchwerkzeuge (`Grep`, `Glob`) werten **keine** Pfadregeln aus; für dieses Verb wird keine Regel erzeugt (`CR-2026-016`). **Eine `Read(**)`-Regel deckt sie nicht mit ab** (gemessen, B04, Lauf B04-5). Den Kanal trägt der Schutz-Hook über `hook_tools.search`, nicht die Berechtigungsdatei (`CR-2026-047`, D-47) |
-| `write` | `Edit(muster)` | Ändern und Anlegen sind zwar getrennte Werkzeuge, eine **Pfadregel** wertet der Client aber nur für `Read` und `Edit` aus; eine `Write(muster)`-Regel wäre wirkungslos und wird nicht erzeugt (AP2-CC-02, Abschnitt 7) |
-| `exec` | `Bash(präfix:*)` | präfixbasiert statt wörtlich – die Sperre ist damit breiter. **Seit `1.18.2` je Regel zweimal: `Bash(…)` und `PowerShell(…)`** (D-469) – das zweite Befehlswerkzeug des Clients unter Windows, gleiche Regelform, gemessen |
+| `search` | – | Die Suchwerkzeuge (`Grep`, `Glob`) werten keine Pfadregeln aus, auch eine `Read(**)`-Regel deckt sie nicht (gemessen, Lauf B04-5); für dieses Verb wird keine Regel erzeugt. Den Kanal trägt der Schutz-Hook über `hook_tools.search` |
+| `write` | `Edit(muster)` | Der Client wertet Pfadregeln nur für `Read` und `Edit` aus; eine `Write(muster)`-Regel wäre wirkungslos und wird nicht erzeugt (Abschnitt 7) |
+| `exec` | `Bash(präfix:*)` | präfixbasiert statt wörtlich, die Sperre ist damit breiter. Je Regel zweimal, `Bash(…)` und `PowerShell(…)`: das zweite Befehlswerkzeug des Clients unter Windows, gleiche Regelform, gemessen |
 | `fetch` | `WebFetch`, `WebSearch` | zwei Werkzeuge, beide ohne Muster |
 | `mcp` | `mcp__*` | ohne Muster |
 
@@ -59,7 +57,7 @@ Die Regelmenge liegt werkzeugneutral im Kern (`.koolie/core/framework/runtime/pe
 | Hook-Werkzeugnamen | `Read`; `Grep`, `Glob`; `Bash`; `Edit`, `Write`, `NotebookEdit` (`hook_tools` im Manifest) |
 | Projektverzeichnis im Hook-Befehl | `$CLAUDE_PROJECT_DIR` |
 
-Zwei Zusicherungen sichern die Abbildung ab, statt sich auf Sorgfalt zu verlassen: Eine `deny`- oder `ask`-Regel ohne Zielwerkzeug lässt die Installation scheitern, und die Präfixform eines Befehlsverbots muss ein Präfix seiner wörtlichen Form sein – damit ist sie nachweislich mindestens so breit. Bei `allow` ist jede Verbreiterung unzulässig.
+Zwei Zusicherungen sichern die Abbildung ab: Eine `deny`- oder `ask`-Regel ohne Zielwerkzeug lässt die Installation scheitern, und die Präfixform eines Befehlsverbots muss ein Präfix seiner wörtlichen Form sein, also mindestens so breit. Bei `allow` ist jede Verbreiterung unzulässig.
 
 ## 1b. Semantikabbildung der Ladebedingungen
 
@@ -70,149 +68,141 @@ Die Regeltexte liegen werkzeugneutral im Kern (`.koolie/core/framework/runtime/r
 | `always_on` | kein `paths`-Feld | bei jedem Sitzungsstart | wörtliche Entsprechung |
 | `model_decision` | kein `paths`-Feld | bei jedem Sitzungsstart | **Verschärfung** – mehr Regeln aktiv, nicht weniger; sie kostet Kontext, kein Schutzniveau |
 | `glob` mit `globs` | `paths:` mit denselben Mustern | sobald der Client eine passende Datei liest | wörtliche Entsprechung |
-| `manual`, `agent` | **keine Abbildung** | – | Die Installation scheitert. Kein Kernartefakt nutzt sie; eine künftige Regel, die es täte, erzwingt damit eine Entscheidung, statt ihre Ladebedingung stillschweigend zu verlieren |
+| `manual`, `agent` | **keine Abbildung** | – | Die Installation scheitert. Kein Kernartefakt nutzt sie; eine Regel, die es täte, verlöre ihre Ladebedingung sonst stillschweigend |
 
-Zwei Zusicherungen sichern auch diese Abbildung ab: Ein Ladetrigger ohne Eintrag lässt die Installation scheitern (D-27), und ein Ladetrigger, der auf `paths` abbildet, muss Dateimuster mitbringen – eine leere Ladebedingung wäre keine. Der Validator prüft die **installierte** Fassung gegen die Felder, die dieser Client auswertet: Ein stehen gebliebenes `trigger:` oder `globs:` ist ein Fehler, und eine Kernregel (`00-`, `10-`, `15-`, `20-`) darf kein `paths` tragen – sie gilt für jede Aufgabe, eine Ladebedingung wäre dort eine Lockerung.
+Zwei Zusicherungen sichern auch diese Abbildung ab: Ein Ladetrigger ohne Eintrag lässt die Installation scheitern, und ein Ladetrigger, der auf `paths` abbildet, muss Dateimuster mitbringen. Der Validator prüft die installierte Fassung gegen die Felder, die dieser Client auswertet: Ein stehen gebliebenes `trigger:` oder `globs:` ist ein Fehler, und eine Kernregel (`00-`, `10-`, `15-`, `20-`) darf kein `paths` tragen – sie gilt für jede Aufgabe.
 
-`description` ist für Regeldateien dieses Clients **nicht** dokumentiert und entfällt deshalb im Frontmatter (K-18). Zweck, Ladeverhalten und der Ladetrigger der Kernquelle stehen stattdessen in einem HTML-Kommentar oberhalb des Regeltextes. Für `CLAUDE.md`-Dateien ist dokumentiert, dass Block-Kommentare vor dem Einspeisen entfernt werden; für Regeldateien ist das **nicht** dokumentiert. Der Kommentar ist deshalb knapp gehalten und zählt hier vorsorglich zum ständigen Kontext.
+`description` ist für Regeldateien dieses Clients nicht dokumentiert und entfällt im Frontmatter. Zweck, Ladeverhalten und Ladetrigger der Kernquelle stehen in einem HTML-Kommentar über dem Regeltext. Dass der Client solche Kommentare vor dem Einspeisen entfernt, ist nur für `CLAUDE.md` dokumentiert; der Kommentar ist deshalb knapp und zählt hier zum ständigen Kontext.
 
 ## 2. Fähigkeitsmatrix
 
-**Zur Belegspalte.** Jede `[DOK]`-Zeile nennt die **Quellenkennung** der Liste in Anhang 31.4.2 (`QC-1` bis `QC-6`). Die Kennung ist die verbindliche Form, weil allein sie gegen die Liste gehalten werden kann; ein Seitenpfad darf danebenstehen. **Prüfung 73 setzt es durch.** Eine Zelle, die auf eine andere Zeile verweist (*„wie B3"*), erbt deren Kennung – die Prüfung löst den Verweis auf, und eine Zeile, deren Ziel keine Kennung trägt, nimmt die Nachbarzeilen mit.
+**Zur Belegspalte.** Jede `[DOK]`-Zeile nennt die Quellenkennung der Liste in Anhang 31.4.2 (`QC-1` bis `QC-6`); nur sie lässt sich gegen die Liste halten, ein Seitenpfad darf danebenstehen. Prüfung 73 setzt das durch. Eine Zelle, die auf eine andere Zeile verweist (*„wie B3"*), erbt deren Kennung.
 
-**Was der Zusatz `(Zuordnung K-62)` sagt – und was nicht.** Die Zuordnung ist am 2026-09-22 aus dem Bestand gewonnen – aus der Quellenliste und den Protokollen zu AP2 und `FW-AK-01` –, nicht aus einem eigenen Abruf. Der Recherchestand der Seiten bleibt deshalb der von `FW-AK-01` (2026-09-18); eine Zuordnung ist keine Aktualitätsaussage. Wofür der Bestand keine Seite hergibt, sagt die Zeile das, statt zu raten: `M3` tut es (D-156, D-263).
+**Was die Zuordnung sagt.** Die Quellen der `[DOK]`-Zeilen sind am 2026-09-22 aus Quellenliste und Protokollen zugeordnet, nicht neu abgerufen. Der Recherchestand der Seiten bleibt der von `FW-AK-01` (2026-09-18); eine Zuordnung ist keine Aktualitätsaussage. Wo keine Seite passt, sagt die Zeile das (`M3`).
 
 ### R – Regelladung
 
 | ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
 |---|---|---|---|---|
 | R1 | Wurzel-Anweisungsdatei wird ungefragt geladen | `CLAUDE.md` wird zu Beginn jeder Sitzung geladen | `[TECHNISCH]` | `[DOK]` **`QC-1`** (Zuordnung `K-62`) |
-| R2 | Regeldateien mit Ladebedingungen | `.claude/rules/*.md`: ohne `paths`-Frontmatter unbedingt geladen, mit `paths` nur bei passenden Dateien. Der Client kennt **eine** Bedingung, die Kernquelle drei Ladetrigger; `model_decision` bildet deshalb auf unbedingtes Laden ab – eine Verschärfung, siehe Abschnitt 1b | `[TECHNISCH]` | [DOK] **`QC-1`** `docs/en/memory` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) |
+| R2 | Regeldateien mit Ladebedingungen | `.claude/rules/*.md`: ohne `paths`-Frontmatter unbedingt geladen, mit `paths` nur bei passenden Dateien. Der Client kennt eine Bedingung, die Kernquelle drei Ladetrigger; `model_decision` bildet deshalb auf unbedingtes Laden ab – eine Verschärfung, siehe Abschnitt 1b | `[TECHNISCH]` | [DOK] **`QC-1`** `docs/en/memory` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) |
 | R3 | Regeln an Dateimuster bindbar (Grundlage der Technology Packs) | `paths:` im Frontmatter bindet eine Regel an Glob-Muster; mehrere Muster und Klammer-Expansion sind zulässig. Ein Technology Pack liegt damit als `.claude/rules/40-tech-<name>.md` und lädt bei den Dateien seiner Technologie. Grenzen: Abschnitt 5 | `[TECHNISCH]` | [DOK] **`QC-1`** `docs/en/memory` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) |
-| R4 | Bekanntes Zeichenlimit, das das Framework einhalten kann | **4 MiB** je Anweisungsdatei; eine größere Datei wird übersprungen. Zusätzlich als Empfehlung 200 Zeilen | `[TECHNISCH]` | [DOK] **`QC-1`** `docs/en/memory` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) |
-| R5 | Die geladenen Regelquellen sind vollständig aufzählbar | **Zwei dokumentierte Wege** (`QC-1`): `/context` führt die geladenen Anweisungsdateien unter *Memory files* auf, und der Hook `InstructionsLoaded` feuert, wenn eine Anweisungs- oder Regeldatei in den Kontext geladen wird – sein Matcher ist der **Ladegrund** (`session_start`, `nested_traversal`, `path_glob_match`, `include`, `compact`). Die vollständige Auskunft des Frameworks steht in Abschnitt 8 dieses Packs | `[TEXTUELL]` | **`[DOK]` `QC-1` `docs/en/memory`, Stand 2.1.275 (`FW-AK-01`, 2026-09-18, `tests/protocols/2026-09-18-FW-AK-01.md`).** 🟢 **Der VERIFY-Marker ist damit aufgelöst** (D-158): Er verlangte wörtlich einen Abgleich gegen die aktuelle Client-Dokumentation, und die nennt seit diesem Stand einen technischen Weg. Bis 0.61.0 stand hier *„Kein Kommando dieses Clients führt die wirksamen Regelquellen auf"* – **das ist nicht mehr wahr**, und der alte Belegstand war eine Aussage über sich selbst, die veraltet ist (D-114). **Zwei benannte Grenzen:** (1) Was die **Nutzlast** des Hooks trägt – Pfad, Herkunft, Reihenfolge –, ist nicht dokumentiert; belegt ist das Ereignis samt Ladegrund, nicht der Inhalt. (2) Keiner der beiden Wege ist in einer Sitzung dieses Frameworks **gemessen**; ein Dokumentenabgleich belegt `[DOK]`, nicht `[TECHNISCH]` (D-12). Die frühere Selbstauskunft der Sitzung ist am 2026-09-11 gegen 2.1.268 beobachtet (K-22, K-26) und traf zu – sie bleibt Modellverhalten und ist nicht der hier belegte Weg |
-| R6 | Keine Importe fremder Werkzeugformate | Der Client kennt `claudeMdExcludes`, das Anweisungs- und Regeldateien über Glob-Muster vom Laden ausnimmt. **Das Framework liefert keine Vorgabe aus** (D-37): Eine `CLAUDE.md` im Elternverzeichnis ist in einem Mehrprojekt-Verzeichnis oft gewollt, ein pauschaler Ausschluss bräche legitime Anordnungen. Es bleibt bei Auskunft (Abschnitt 8) und Empfehlung | `[TEXTUELL]` | Der Mechanismus ist am 2026-09-11 gegen 2.1.268 gemessen: Drei Muster gleichzeitig nahmen die fremde Datei vom Laden aus, zwei geladene `CLAUDE.md` wurden eine (K-21). **Welches der drei Muster greift, ist nicht getrennt gemessen.** Dass hier keine Vorgabe steht, ist eine Entscheidung, kein fehlender Beleg |
+| R4 | Bekanntes Zeichenlimit, das das Framework einhalten kann | 4 MiB je Anweisungsdatei; eine größere Datei wird übersprungen. Zusätzlich als Empfehlung 200 Zeilen | `[TECHNISCH]` | [DOK] **`QC-1`** `docs/en/memory` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) |
+| R5 | Die geladenen Regelquellen sind vollständig aufzählbar | Zwei dokumentierte Wege (`QC-1`): `/context` führt die geladenen Anweisungsdateien unter *Memory files* auf, und der Hook `InstructionsLoaded` feuert, wenn eine Anweisungs- oder Regeldatei in den Kontext geladen wird – sein Matcher ist der Ladegrund (`session_start`, `nested_traversal`, `path_glob_match`, `include`, `compact`). Die vollständige Auskunft des Frameworks steht in Abschnitt 8 dieses Packs | `[TEXTUELL]` | **`[DOK]` `QC-1` `docs/en/memory`, Stand 2.1.275 (`FW-AK-01`, 2026-09-18, `tests/protocols/2026-09-18-FW-AK-01.md`).** 🟢 **Der VERIFY-Marker ist damit aufgelöst** (D-158): Er verlangte wörtlich einen Abgleich gegen die aktuelle Client-Dokumentation, und die nennt seit diesem Stand einen technischen Weg. Bis 0.61.0 stand hier *„Kein Kommando dieses Clients führt die wirksamen Regelquellen auf"* – **das ist nicht mehr wahr**, und der alte Belegstand war eine Aussage über sich selbst, die veraltet ist (D-114). **Zwei benannte Grenzen:** (1) Was die **Nutzlast** des Hooks trägt – Pfad, Herkunft, Reihenfolge –, ist nicht dokumentiert; belegt ist das Ereignis samt Ladegrund, nicht der Inhalt. (2) Keiner der beiden Wege ist in einer Sitzung dieses Frameworks **gemessen**; ein Dokumentenabgleich belegt `[DOK]`, nicht `[TECHNISCH]` (D-12). Die frühere Selbstauskunft der Sitzung ist am 2026-09-11 gegen 2.1.268 beobachtet (K-22, K-26) und traf zu – sie bleibt Modellverhalten und ist nicht der hier belegte Weg |
+| R6 | Keine Importe fremder Werkzeugformate | Der Client kennt `claudeMdExcludes`, das Anweisungs- und Regeldateien über Glob-Muster vom Laden ausnimmt. Das Framework liefert keine Vorgabe aus: Eine `CLAUDE.md` im Elternverzeichnis ist in einem Mehrprojekt-Verzeichnis oft gewollt, ein pauschaler Ausschluss bräche legitime Anordnungen. Es bleibt bei Auskunft (Abschnitt 8) und Empfehlung | `[TEXTUELL]` | Der Mechanismus ist am 2026-09-11 gegen 2.1.268 gemessen: Drei Muster gleichzeitig nahmen die fremde Datei vom Laden aus, zwei geladene `CLAUDE.md` wurden eine (K-21). **Welches der drei Muster greift, ist nicht getrennt gemessen.** Dass hier keine Vorgabe steht, ist eine Entscheidung, kein fehlender Beleg |
 
 ### S – Skills
 
 | ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
 |---|---|---|---|---|
 | S1 | Versionierte Skills im Repository | `.claude/skills/<name>/SKILL.md` mit Frontmatter | `[TECHNISCH]` | `[DOK]` **`QC-3`** (Zuordnung `K-62`); zusätzlich **beobachtet** (siehe Abschnitt 6) |
-| S2 | Gezielter Aufruf | **Zwei Wege, verschieden gebaut** (D-187, gemessen 2026-09-19). **(a) Der modellseitige Aufruf** – die Sitzung zieht den Skill selbst – **ist ein eigener Werkzeugaufruf mit dem Namen `Skill` und damit einzeln kontrollierbar**; das ist die Voraussetzung der drei Grenzen unten, und die Erhebung vom 2026-09-14 hat genau ihn gemessen: Ihre Prompts nannten keinen Skill. **(b) Der Aufruf mit vorangestelltem Schrägstrich** – der Weg, den der Testkatalog verlangt (D-146) – ist eine **Slash-Befehls-Erweiterung des Clients**: Die Mitschrift führt `<command-name>` samt Argumenten und fügt die ganze `SKILL.md` als Nutzernachricht ein; **kein Werkzeugaufruf, keine `Skill(...)`-Regel im Spiel, kein stummer Fehlschlag.** Gemessen an zwölf von zwölf Läufen. **Die drei Grenzen gelten für Weg (a):** (1) **Rückfragepflichtig ohne Freigabe** – ohne `allow`-Regel fällt der Aufruf auf `defaultMode: default`; im rückfragefreien Betrieb ist das eine Abweisung. Die Berechtigungsdatei führt je eine Regel für die zwölf Skills des Kerns; **ein Skill außerhalb dieser zwölf bleibt rückfragepflichtig** – gewollt, weil die Sitzung auch Skills aus einer nutzerglobalen Ablage führt, die nach Regel 2.6 der Prioritätshierarchie ebenenlos sind. (2) **Wörtliches Argument** – der Vergleich ist zeichengenau: `Skill(fw-code-explain)` lässt den Aufruf durch, `Skill(fw-*)` weist ihn ab. **Ein Präfixmuster gäbe lautlos nichts frei** – die Bauform von D-66, mit umgekehrtem Vorzeichen. Deshalb zwölf Regeln statt einer. (3) **Der Fehlschlag ist stumm** – nach der Abweisung liest die Sitzung die `SKILL.md` als gewöhnliche Datei und arbeitet ihren Ablauf von Hand nach; die Ausgabe trägt Überschrift und Standardformat des Skills und ist von einem gelungenen Lauf **nicht zu unterscheiden**. **Die nachgearbeitete Fassung trägt die Werkzeugbeschränkung des Skills nicht** – in einem Lauf rief sie ein Werkzeug auf, das der Skill in `disallowed-tools` sperrt. Der stumme Rückfall kostet damit die Zusage der Nachbarzeile. Was dagegen steht, ist eine Anweisung (Wurzel-Anweisungsdatei Abschnitt 17, Grenzfall G-20), kein Mechanismus | `[TECHNISCH]`, mit drei benannten Grenzen | **Gemessen am 2026-09-14** (`tests/protocols/2026-09-14-erhebung-skillaufruf.md`), elf Läufe an einer vollständigen Installation, davon vier Kontroll- und Entlastungsläufe: Ohne `allow`-Regel wurde der Aufruf abgewiesen (`toolDenialKind: user-rejected`, `permission_denials` führt `Skill`), mit Regel lief er durch (Gegenprobe). Die Argumentform ist mit Positivlauf und **Kontrolllauf** belegt: `Skill(fw-plan)` weist `fw-code-explain` ab, das Muster engt also wirklich ein. Zuvor war die Zeile mit `[DOK]` belegt und nannte **keine Grenze** – der Aufruf funktionierte, und was ihn aufhielt, stand in der eigenen Berechtigungsdatei |
-| S3 | Werkzeugbeschränkung je Skill | **`disallowed-tools` im Skill-Frontmatter.** Die Installation bildet `permissions.deny` der Quelle darauf ab: die groben Verben `edit` und `exec` über `hook_tools` auf `Edit, Write, NotebookEdit` und `Bash` (D-65). `allowed-tools` trägt die Zusage **nicht** – es ist eine Vorabfreigabe für den aufrufenden Turn, keine Beschränkung (B01), und wird deshalb bewusst nicht dafür verwendet. **Was davon in der Mitschrift steht, ist gemessen** (D-188): Beim Aufruf mit Schrägstrich führt sie `command_permissions` mit genau den Werkzeugen aus `allowed-tools`; ein Baum ohne die beiden Frontmatter-Schlüssel führt dort eine **leere** Liste. **Wirkungslos wird damit jede Freigabe der Berechtigungsdatei, die während des Befehls nicht in dieser Liste steht** – wer ein Unterlassen misst, weist es je Schicht aus (D-122). **Die Sperre weist ab, sie entfernt nicht** (D-195). Gemessen sind fünf Aufrufe in vier Läufen, die **erschienen und abgewiesen wurden**, wörtlich *„Permission to use Bash has been denied“* – **ein entferntes Werkzeug kann man nicht aufrufen, ein abgewiesenes schon.** An der Wirkung ändert das nichts, an der Beschreibung schon. **Die Abweisung trägt kein `toolDenialKind`** – sie steht in `permission_denials` des Ergebnisses; wer nur die Mitschrift danach durchsucht, zählt null. **Welche Schicht abweist, ist wahrscheinlich, nicht isoliert** (`K-73` bleibt insoweit offen): Bei identischer Berechtigungsdatei wurde ein schlichtes `ls` **mit** Skill abgewiesen und **ohne** Skill ausgeführt; die eigens gebauten Zuschnitte mit `Bash` im `allow`-Korb haben **gar keinen Aufruf abgesetzt**. **Drei Grenzen:** (1) **Turnbereich** – die Sperre gilt nur für den aufrufenden Turn; Turn 2 derselben Sitzung konnte wieder schreiben. Ein „nur lesender" Skill ist nur *während seines Turns* nur lesend, das ist **keine Betriebsart**. (2) **Aufzählend** – was nicht in der Liste steht, ist offen; mit gesperrtem `Write, Edit` schrieb der Skill über `Bash`. (3) **Keine Argumentmuster** – befehlsgenaue Verbote sind nicht ausdrückbar, und ein Eintrag mit Klammer wirkt **lautlos gar nicht**. Betroffen sind fünf der zwölf Skills, ungleich: **`fw-change-small`, `fw-refactor`, `fw-tests` bekommen gar keine Schranke je Skill**, **`fw-mr-description` und `fw-review-support` eine teilweise** – ihre Editierwerkzeuge sind gesperrt, ihre `git`-Verbote nicht. Für sie trägt weiter die **globale** Berechtigungsschicht samt Schutz-Hook, die unabhängig vom Skill wirkt. **Reichweite, gemessen am 2026-09-13** (`tests/protocols/2026-09-13-erhebung-unteragent.md`, D-67): Die Sperre gilt auch für einen **Unteragenten**, den der Skill startet. Ein Unteragent mit einem Profil **ohne** eigenes `tools`-Feld hatte `Write` und `Edit` nicht im Vorrat; der Kontrolllauf mit demselben Skill ohne das Feld schrieb. **Der Unteragent ist kein Umgehungsweg.** Grenze 2 reicht allerdings mit: Mit gesperrtem `Write, Edit` schrieb der Unteragent über `Bash`. **Ergänzt am 2026-09-13** (`tests/protocols/2026-09-13-erhebung-unteragent-tiefe.md`, D-72), je mit Kontrolllauf: Die Sperre gilt auch für einen Unteragenten mit `run_in_background: true` und reicht **mindestens zwei Ebenen tief** – der Start der zweiten Ebene gelang, das Werkzeug fehlte auch dort. **Bei Widerspruch gewinnt die restriktivere Liste:** Ein Profil, das `Write` ausdrücklich in `tools` nennt, bekam es unter einem Skill mit `disallowed-tools: Write, Edit` **nicht** – eine Erlaubnis holt ein entferntes Werkzeug nicht zurück, gleich ob sie in der Berechtigungsdatei steht oder im Agentenprofil. **Man kann die Liste nur enger machen, nie weiter.** **Beobachtung zum Wortlaut des Clients, keine Messung:** Er meldet die Sperre als „Write is disabled for this *session*, in subagents as well as here" – die zweite Hälfte trifft zu, die erste **überzeichnet**: Gemessen ist der **Turn**, und Turn 2 derselben Sitzung konnte wieder schreiben (D-64). Wer der Meldung glaubt, nimmt mehr Reichweite an, als belegt ist. **Weiterhin nicht gemessen:** drei Ebenen und tiefer; der umgekehrte Widerspruch (Profil sperrt, Skill erlaubt) – nach dem Ergebnis vorhersagbar, aber eine Vorhersage ist keine Messung; und ob ein **blockierender** Hook auch auf der zweiten Ebene stoppt (für die erste ist es gemessen, D-69) | `[TECHNISCH]`, mit drei benannten Grenzen | **Gemessen am 2026-09-13** (`tests/protocols/2026-09-13-erhebung-disallowed-tools.md`), neun Läufe mit Kontrolllauf, Positivkontrolle und Rekorder-Hook: Ein Skill mit `disallowed-tools: Write, Edit` **konnte nicht schreiben – obwohl `Write` in der `allow`-Liste stand**; derselbe Skill ohne das Feld konnte es. `disallowed-tools` schlägt also eine ausdrückliche Freigabe und ist genau das, was `allowed-tools` nach **B01** nicht ist. Bis 0.34.0 galt diese Zeile als nicht abbildbar, mit dem Satz „nicht erhoben, deshalb hier nicht zugesagt" (`CR-2026-050`, D-50) – **das war nach dem damaligen Belegstand richtig und ist mit der Erhebung überholt** (`CR-2026-057`, D-64). Nach D-41 ist S3 eine **Fähigkeitszusage**; ihr Ausfall sperrt die Inbetriebnahme nicht. **Benannte Grenze, gemessen mit `1.23.0`** (D-525): Die Sperre gilt nur in dem Turn, in dem der Skill läuft – im Folgeturn (`--resume`) meldete der Lauf „Skill: keiner“, und ein Befehl lief, sobald die Regelschicht ihn zuließ; dort tragen Berechtigungsdatei und Schutz-Hook |
-| S4 | Schreibende Skills nur benutzergetriggert | `disable-model-invocation: true` verhindert, dass das Modell den Skill selbst lädt, und hält zusätzlich seine Beschreibung aus dem Kontext; die Installation setzt das Feld für jeden Skill, dessen Quelle `triggers` ohne `model` nennt (9 von 12). Ergänzend wirkt `ask` auf `Edit(**)`: jede Schreiboperation löst eine Rückfrage aus | `[TECHNISCH]` | [DOK] **`QC-3`** `docs/en/skills` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`); **beobachtet am 2026-09-12** (`tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`): Von zwölf Skills führte die Sitzung genau die drei **ohne** das Feld; die neun mit dem Feld standen nicht in ihrem Kontext, waren als Aufruf mit vorangestelltem Schrägstrich aber vorhanden. Der Wirkungsnachweis steht damit nicht mehr aus. **Reichweite:** Die Zusage gilt für die Skill-Ablage, die das Framework schreibt. Skills aus Ablagen außerhalb des Repositoriums unterliegen diesen Konventionen nicht; sie sind nach Regel 2.6 der Prioritätshierarchie ebenenlos und dürfen den Handlungsspielraum nur einschränken (`CR-2026-032`). 🔴 **Seit 2.1.275 gibt es eine solche Ablage, die das Framework nicht erreicht, und sie ist standardmäßig an** (`FW-AK-01`, 2026-09-18, `K-63`): Der Client lädt die im Konto des Anwenders eingeschalteten Skills nach `~/.claude/skills/synced/` und gleicht sie **während** der Sitzung etwa alle zehn Minuten ab. Für diese Skills gilt das Feld dieser Zeile nur, soweit ihre Quelle es selbst setzt – das Framework schreibt sie nicht. **Die Zusage dieser Zeile bleibt richtig und ihr Geltungsbereich ist kleiner geworden.** **Und eine zweite Reichweitenangabe, gegenläufig:** Ein Unteragentenprofil kann Skills über das Frontmatter-Feld `skills` **vorladen**; `disable-model-invocation: true` verhindert auch das (`QC-3`, `QC-4`). Das Framework nutzt das Feld nicht |
-| S5 | Die geladenen Skills sind vollständig aufzählbar, samt Herkunft und Aufrufbarkeit | **Keiner.** `claude --help` kennt keinen Unterbefehl für Skills, `claude doctor` nennt keine Skill-Pfade; die Sitzung erhält Skills als Name und Kurzbeschreibung **ohne Pfad** | `[NICHT ABBILDBAR]` | **Erhoben am 2026-09-12** (`tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`). Zwei Teilantworten. **Fremde Skill-Ablagen führt dieser Client nicht mit:** Vier gleich gebaute Sonden in `.devin/skills/`, `.windsurf/skills/`, `.cursor/skills/` und `~/.devin/skills/` blieben sämtlich ungeführt, die fünfte in der eigenen Ablage wurde geführt (Positivkontrolle im selben Lauf). Die Gegenrichtung zu `AP2-DD-16` fällt damit entgegengesetzt aus; ein Import ist hier ein ausdrücklicher Befehl (`claude import`), kein stilles Mitführen. **Die Aufzählbarkeit selbst ist nicht eingelöst:** Die Sitzung antwortete auf die Frage nach der Herkunft wörtlich „Herkunft unbekannt — für alle 84", und ihre Liste ist zudem konstruktionsbedingt unvollständig (S4). Die nutzerglobale **eigene** Ablage `~\.claude\skills\` lädt in jedes Projekt mit – 67 Skills in einer Sitzung, deren Projekt keinen davon enthält; sie fällt unter den Auskunftsabschnitt nach D-34. **Ersatz: `python .koolie/core/install.py --client claude-code --root <projekt> --list-skills`** – Name, Herkunft, Aufrufbarkeit und Pfad je Skill dieser Installation (`CR-2026-041` E3, D-42). **Kein vollständiger Ersatz, und die Ausgabe sagt das selbst:** Skills aus Ablagen außerhalb des Projektverzeichnisses sieht auch das Framework nicht – also genau die 67, um die es hier geht. Nach D-41 ist S5 eine **Fähigkeitszusage**; ihr Ausfall sperrt die Inbetriebnahme nicht. 🔴 **Nachtrag 2026-09-18 (`FW-AK-01`): Der Abstand ist seit 2.1.275 größer, nicht kleiner.** Zu den nutzerglobalen Skills tritt eine **Kontoquelle**: `~/.claude/skills/synced/`, standardmäßig eingeschaltet, im Hintergrund geladen und **während** der Sitzung etwa alle zehn Minuten nachgezogen (`QC-3`). Damit kann sich der Skillbestand **innerhalb** einer Sitzung ändern – eine Aufzählung ist dann nicht nur unvollständig, sondern hat einen Zeitpunkt. Der Ersatz über `--list-skills` sieht sie so wenig wie die 67 nutzerglobalen (`K-63`) |
+| S2 | Gezielter Aufruf | Zwei Wege, verschieden gebaut (gemessen 2026-09-19). (a) Der modellseitige Aufruf – die Sitzung zieht den Skill selbst – ist ein eigener Werkzeugaufruf mit dem Namen `Skill` und damit einzeln kontrollierbar; das ist die Voraussetzung der drei Grenzen unten, und die Erhebung vom 2026-09-14 hat genau ihn gemessen: Ihre Prompts nannten keinen Skill. (b) Der Aufruf mit vorangestelltem Schrägstrich – der Weg, den der Testkatalog verlangt – ist eine Slash-Befehls-Erweiterung des Clients: Die Mitschrift führt `<command-name>` samt Argumenten und fügt die ganze `SKILL.md` als Nutzernachricht ein; kein Werkzeugaufruf, keine `Skill(...)`-Regel im Spiel, kein stummer Fehlschlag. Gemessen an zwölf von zwölf Läufen. Die drei Grenzen gelten für Weg (a): (1) Rückfragepflichtig ohne Freigabe – ohne `allow`-Regel fällt der Aufruf auf `defaultMode: default`; im rückfragefreien Betrieb ist das eine Abweisung. Die Berechtigungsdatei führt je eine Regel für die zwölf Skills des Kerns; ein Skill außerhalb dieser zwölf bleibt rückfragepflichtig – gewollt, weil die Sitzung auch Skills aus einer nutzerglobalen Ablage führt, die nach Regel 2.6 der Prioritätshierarchie ebenenlos sind. (2) Wörtliches Argument – der Vergleich ist zeichengenau: `Skill(koolie-code-explain)` lässt den Aufruf durch, `Skill(koolie-*)` weist ihn ab. Ein Präfixmuster gäbe lautlos nichts frei. Deshalb zwölf Regeln statt einer. (3) Der Fehlschlag ist stumm – nach der Abweisung liest die Sitzung die `SKILL.md` als gewöhnliche Datei und arbeitet ihren Ablauf von Hand nach; die Ausgabe trägt Überschrift und Standardformat des Skills und ist von einem gelungenen Lauf nicht zu unterscheiden. Die nachgearbeitete Fassung trägt die Werkzeugbeschränkung des Skills nicht – in einem Lauf rief sie ein Werkzeug auf, das der Skill in `disallowed-tools` sperrt. Der stumme Rückfall kostet damit die Zusage der Nachbarzeile. Was dagegen steht, ist eine Anweisung (Wurzel-Anweisungsdatei Abschnitt 17, Grenzfall G-20), kein Mechanismus | `[TECHNISCH]`, mit drei benannten Grenzen | **Gemessen am 2026-09-14** (`tests/protocols/2026-09-14-erhebung-skillaufruf.md`), elf Läufe an einer vollständigen Installation, davon vier Kontroll- und Entlastungsläufe: Ohne `allow`-Regel wurde der Aufruf abgewiesen (`toolDenialKind: user-rejected`, `permission_denials` führt `Skill`), mit Regel lief er durch (Gegenprobe). Die Argumentform ist mit Positivlauf und **Kontrolllauf** belegt: `Skill(koolie-plan)` weist `koolie-code-explain` ab, das Muster engt also wirklich ein. Zuvor war die Zeile mit `[DOK]` belegt und nannte **keine Grenze** – der Aufruf funktionierte, und was ihn aufhielt, stand in der eigenen Berechtigungsdatei |
+| S3 | Werkzeugbeschränkung je Skill | `disallowed-tools` im Skill-Frontmatter. Die Installation bildet `permissions.deny` der Quelle darauf ab: die groben Verben `edit` und `exec` über `hook_tools` auf `Edit, Write, NotebookEdit` und `Bash`. `allowed-tools` trägt die Zusage nicht – es ist eine Vorabfreigabe für den aufrufenden Turn, keine Beschränkung (B01), und wird deshalb bewusst nicht dafür verwendet. Was davon in der Mitschrift steht, ist gemessen: Beim Aufruf mit Schrägstrich führt sie `command_permissions` mit genau den Werkzeugen aus `allowed-tools`; ein Baum ohne die beiden Frontmatter-Schlüssel führt dort eine leere Liste. Wirkungslos wird damit jede Freigabe der Berechtigungsdatei, die während des Befehls nicht in dieser Liste steht – wer ein Unterlassen misst, weist es je Schicht aus. Die Sperre weist ab, sie entfernt nicht. Gemessen sind fünf Aufrufe in vier Läufen, die erschienen und abgewiesen wurden, wörtlich *„Permission to use Bash has been denied“* – ein entferntes Werkzeug kann man nicht aufrufen, ein abgewiesenes schon. An der Wirkung ändert das nichts, an der Beschreibung schon. Die Abweisung trägt kein `toolDenialKind` – sie steht in `permission_denials` des Ergebnisses; wer nur die Mitschrift danach durchsucht, zählt null. Welche Schicht abweist, ist wahrscheinlich, nicht isoliert: Bei identischer Berechtigungsdatei wurde ein schlichtes `ls` mit Skill abgewiesen und ohne Skill ausgeführt; die eigens gebauten Zuschnitte mit `Bash` im `allow`-Korb haben gar keinen Aufruf abgesetzt. Drei Grenzen: (1) Turnbereich – die Sperre gilt nur für den aufrufenden Turn; Turn 2 derselben Sitzung konnte wieder schreiben. Ein „nur lesender" Skill ist nur *während seines Turns* nur lesend, das ist keine Betriebsart. (2) Aufzählend – was nicht in der Liste steht, ist offen; mit gesperrtem `Write, Edit` schrieb der Skill über `Bash`. (3) Keine Argumentmuster – befehlsgenaue Verbote sind nicht ausdrückbar, und ein Eintrag mit Klammer wirkt lautlos gar nicht. Betroffen sind fünf der zwölf Skills, ungleich: `koolie-change-small`, `koolie-refactor`, `koolie-tests` bekommen gar keine Schranke je Skill, `koolie-mr-description` und `koolie-review-support` eine teilweise – ihre Editierwerkzeuge sind gesperrt, ihre `git`-Verbote nicht. Für sie trägt weiter die globale Berechtigungsschicht samt Schutz-Hook, die unabhängig vom Skill wirkt. Reichweite, gemessen am 2026-09-13 (`tests/protocols/2026-09-13-erhebung-unteragent.md`): Die Sperre gilt auch für einen Unteragenten, den der Skill startet. Ein Unteragent mit einem Profil ohne eigenes `tools`-Feld hatte `Write` und `Edit` nicht im Vorrat; der Kontrolllauf mit demselben Skill ohne das Feld schrieb. Der Unteragent ist kein Umgehungsweg. Grenze 2 reicht allerdings mit: Mit gesperrtem `Write, Edit` schrieb der Unteragent über `Bash`. Ergänzt am 2026-09-13 (`tests/protocols/2026-09-13-erhebung-unteragent-tiefe.md`), je mit Kontrolllauf: Die Sperre gilt auch für einen Unteragenten mit `run_in_background: true` und reicht mindestens zwei Ebenen tief – der Start der zweiten Ebene gelang, das Werkzeug fehlte auch dort. Bei Widerspruch gewinnt die restriktivere Liste: Ein Profil, das `Write` ausdrücklich in `tools` nennt, bekam es unter einem Skill mit `disallowed-tools: Write, Edit` nicht – eine Erlaubnis holt ein entferntes Werkzeug nicht zurück, gleich ob sie in der Berechtigungsdatei steht oder im Agentenprofil. Man kann die Liste nur enger machen, nie weiter. Beobachtung zum Wortlaut des Clients, keine Messung: Er meldet die Sperre als „Write is disabled for this *session*, in subagents as well as here" – die zweite Hälfte trifft zu, die erste überzeichnet: Gemessen ist der Turn, und Turn 2 derselben Sitzung konnte wieder schreiben. Wer der Meldung glaubt, nimmt mehr Reichweite an, als belegt ist. Weiterhin nicht gemessen: drei Ebenen und tiefer; der umgekehrte Widerspruch (Profil sperrt, Skill erlaubt) – nach dem Ergebnis vorhersagbar, aber eine Vorhersage ist keine Messung; und ob ein blockierender Hook auch auf der zweiten Ebene stoppt (für die erste ist es gemessen) | `[TECHNISCH]`, mit drei benannten Grenzen | **Gemessen am 2026-09-13** (`tests/protocols/2026-09-13-erhebung-disallowed-tools.md`), neun Läufe mit Kontrolllauf, Positivkontrolle und Rekorder-Hook: Ein Skill mit `disallowed-tools: Write, Edit` **konnte nicht schreiben – obwohl `Write` in der `allow`-Liste stand**; derselbe Skill ohne das Feld konnte es. `disallowed-tools` schlägt also eine ausdrückliche Freigabe und ist genau das, was `allowed-tools` nach **B01** nicht ist. Bis 0.34.0 galt diese Zeile als nicht abbildbar, mit dem Satz „nicht erhoben, deshalb hier nicht zugesagt" (`CR-2026-050`, D-50) – **das war nach dem damaligen Belegstand richtig und ist mit der Erhebung überholt** (`CR-2026-057`, D-64). Nach D-41 ist S3 eine **Fähigkeitszusage**; ihr Ausfall sperrt die Inbetriebnahme nicht. **Benannte Grenze, gemessen mit `1.23.0`** (D-525): Die Sperre gilt nur in dem Turn, in dem der Skill läuft – im Folgeturn (`--resume`) meldete der Lauf „Skill: keiner“, und ein Befehl lief, sobald die Regelschicht ihn zuließ; dort tragen Berechtigungsdatei und Schutz-Hook |
+| S4 | Schreibende Skills nur benutzergetriggert | `disable-model-invocation: true` verhindert, dass das Modell den Skill selbst lädt, und hält zusätzlich seine Beschreibung aus dem Kontext; die Installation setzt das Feld für jeden Skill, dessen Quelle `triggers` ohne `model` nennt (9 von 12). Ergänzend wirkt `ask` auf `Edit()`: jede Schreiboperation löst eine Rückfrage aus | `[TECHNISCH]` | [DOK] **`QC-3`** `docs/en/skills` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`); **beobachtet am 2026-09-12** (`tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`): Von zwölf Skills führte die Sitzung genau die drei **ohne** das Feld; die neun mit dem Feld standen nicht in ihrem Kontext, waren als Aufruf mit vorangestelltem Schrägstrich aber vorhanden. Der Wirkungsnachweis steht damit nicht mehr aus. **Reichweite:** Die Zusage gilt für die Skill-Ablage, die das Framework schreibt. Skills aus Ablagen außerhalb des Repositoriums unterliegen diesen Konventionen nicht; sie sind nach Regel 2.6 der Prioritätshierarchie ebenenlos und dürfen den Handlungsspielraum nur einschränken (`CR-2026-032`). 🔴 **Seit 2.1.275 gibt es eine solche Ablage, die das Framework nicht erreicht, und sie ist standardmäßig an** (`FW-AK-01`, 2026-09-18, `K-63`): Der Client lädt die im Konto des Anwenders eingeschalteten Skills nach `~/.claude/skills/synced/` und gleicht sie **während** der Sitzung etwa alle zehn Minuten ab. Für diese Skills gilt das Feld dieser Zeile nur, soweit ihre Quelle es selbst setzt – das Framework schreibt sie nicht. **Die Zusage dieser Zeile bleibt richtig und ihr Geltungsbereich ist kleiner geworden.** **Und eine zweite Reichweitenangabe, gegenläufig:** Ein Unteragentenprofil kann Skills über das Frontmatter-Feld `skills` **vorladen**; `disable-model-invocation: true` verhindert auch das (`QC-3`, `QC-4`). Das Framework nutzt das Feld nicht |
+| S5 | Die geladenen Skills sind vollständig aufzählbar, samt Herkunft und Aufrufbarkeit | Keiner. `claude --help` kennt keinen Unterbefehl für Skills, `claude doctor` nennt keine Skill-Pfade; die Sitzung erhält Skills als Name und Kurzbeschreibung ohne Pfad | `[NICHT ABBILDBAR]` | **Erhoben am 2026-09-12** (`tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`). Zwei Teilantworten. **Fremde Skill-Ablagen führt dieser Client nicht mit:** Vier gleich gebaute Sonden in `.devin/skills/`, `.windsurf/skills/`, `.cursor/skills/` und `~/.devin/skills/` blieben sämtlich ungeführt, die fünfte in der eigenen Ablage wurde geführt (Positivkontrolle im selben Lauf). Die Gegenrichtung zu `AP2-DD-16` fällt damit entgegengesetzt aus; ein Import ist hier ein ausdrücklicher Befehl (`claude import`), kein stilles Mitführen. **Die Aufzählbarkeit selbst ist nicht eingelöst:** Die Sitzung antwortete auf die Frage nach der Herkunft wörtlich „Herkunft unbekannt — für alle 84", und ihre Liste ist zudem konstruktionsbedingt unvollständig (S4). Die nutzerglobale **eigene** Ablage `~\.claude\skills\` lädt in jedes Projekt mit – 67 Skills in einer Sitzung, deren Projekt keinen davon enthält; sie fällt unter den Auskunftsabschnitt nach D-34. **Ersatz: `python .koolie/core/install.py --client claude-code --root <projekt> --list-skills`** – Name, Herkunft, Aufrufbarkeit und Pfad je Skill dieser Installation (`CR-2026-041` E3, D-42). **Kein vollständiger Ersatz, und die Ausgabe sagt das selbst:** Skills aus Ablagen außerhalb des Projektverzeichnisses sieht auch das Framework nicht – also genau die 67, um die es hier geht. Nach D-41 ist S5 eine **Fähigkeitszusage**; ihr Ausfall sperrt die Inbetriebnahme nicht. 🔴 **Nachtrag 2026-09-18 (`FW-AK-01`): Der Abstand ist seit 2.1.275 größer, nicht kleiner.** Zu den nutzerglobalen Skills tritt eine **Kontoquelle**: `~/.claude/skills/synced/`, standardmäßig eingeschaltet, im Hintergrund geladen und **während** der Sitzung etwa alle zehn Minuten nachgezogen (`QC-3`). Damit kann sich der Skillbestand **innerhalb** einer Sitzung ändern – eine Aufzählung ist dann nicht nur unvollständig, sondern hat einen Zeitpunkt. Der Ersatz über `--list-skills` sieht sie so wenig wie die 67 nutzerglobalen (`K-63`) |
 
 ### B – Berechtigungen
 
-> **`[TECHNISCH]` heißt in diesem Block:** Die Engine setzt die Regel durch, **solange der Betriebsmodus die Berechtigungsprüfung nicht abschaltet.** Im Modus ohne Rückfragen, den D-05 untersagt, ist diese Linie aus; dann trägt allein der Schutz-Hook (D-35). **Für diesen Client trifft das nicht zu – erhoben am 2026-09-12** (`tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`, Auflage E5 zu `CR-2026-033`). Drei Läufe mit dem Bypass-Schalter der Befehlszeile, der Modus in der Hook-Aufzeichnung als `bypassPermissions` belegt: Die Verweigerungsregeln griffen **auch dort** – für das Lesewerkzeug und für den Shell-Befehl (E1). Nimmt man sie ganz weg, trägt der Schutz-Hook allein, ebenfalls für beide Werkzeuge (E2). Ein Kontrolllauf ohne beide Schranken las die Datei anstandslos (E0) und macht die anderen zwei erst zu Messungen. **Beide Linien halten hier also gemeinsam, wo sie beim Pack `devin-desktop` nacheinander fallen.** Hinzu kommt, dass der Modus bei diesem Client sperrbar ist (`permissions.disableBypassPermissionsMode`, `AP2-CC-05`) und in verwalteten Einstellungen unüberschreibbar. D-05 bleibt unberührt: Der Lauf war Testnachweis, kein Betriebszustand.
+> **`[TECHNISCH]` heißt in diesem Block:** Die Engine setzt die Regel durch, solange der Betriebsmodus die Berechtigungsprüfung nicht abschaltet. Bei diesem Client gilt das auch im Modus ohne Rückfragen, den `03-security.md` Abschnitt 4 untersagt (erhoben am 2026-09-12, `tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`): Mit dem Bypass-Schalter griffen die Verweigerungsregeln weiter, für Lesewerkzeug und Shell-Befehl; ohne sie trug der Schutz-Hook allein; ein Kontrolllauf ohne beide las die Datei. Beide Linien halten hier gemeinsam, anders als bei `devin-desktop`. Der Modus ist zudem sperrbar (`permissions.disableBypassPermissionsMode`), in verwalteten Einstellungen unüberschreibbar. Das Verbot des Modus bleibt; der Lauf war Testnachweis, kein Betriebszustand.
 >
-> **Und nur für eine Sitzung, die im Verzeichnis der Installation startet** (D-408, gemessen am 2026-09-26 mit Clientversion 2.1.283, `tests/protocols/2026-09-26-mehrprojekt-tokenlast.md`). Startet die Sitzung in einem Unterverzeichnis mit eigenem git-Repositorium, lädt der Client die Wurzel-Anweisung der Elternebene mit – die Sitzung kennt ihre Regeln –, aber **weder die Berechtigungsdatei noch die Hooks**: Die `.env` des Unterverzeichnisses wurde gelesen, ein aufzeichnender Hook lief nicht; in der Wurzel wurde derselbe Zugriff abgewiesen, und der Hook lief. **Eine eigene Installation im Unterverzeichnis trägt** (Zugriff abgewiesen, Hook lief), und dann laden beide Wurzel-Anweisungen. Alle Einstufungen `[TECHNISCH]` dieses Blocks und des H-Blocks stehen unter dieser Bedingung; **nichts meldet einen falschen Startort** (`K-159`). Die Einsatzszenarien stehen im Übernahmeleitfaden, Abschnitt 4.
+> **Nur für eine Sitzung, die im Verzeichnis der Installation startet** (gemessen am 2026-09-26 mit 2.1.283, `tests/protocols/2026-09-26-mehrprojekt-tokenlast.md`). Startet sie in einem Unterverzeichnis mit eigenem git-Repositorium, lädt der Client die Wurzel-Anweisung der Elternebene mit, aber weder Berechtigungsdatei noch Hooks: Die `.env` des Unterverzeichnisses wurde gelesen, ein aufzeichnender Hook lief nicht. Eine eigene Installation im Unterverzeichnis trägt; dann laden beide Wurzel-Anweisungen. Alle Einstufungen `[TECHNISCH]` dieses Blocks und des H-Blocks stehen unter dieser Bedingung, und nichts meldet einen falschen Startort. Die Einsatzszenarien stehen im Übernahmeleitfaden, Abschnitt 4.
 
 | ID | Zusage des Frameworks | Kern | Mechanismus beim Client | Einstufung | Beleg |
 |---|---|---|---|---|---|
 | B1 | Berechtigungen versioniert im Repository | ja | `.claude/settings.json` | `[TECHNISCH]` | `[DOK]` **`QC-5`** (Zuordnung `K-62`) |
-| B2 | Verweigern vor Rückfragen vor Erlauben | ja | `permissions.deny` / `.ask` / `.allow`. **Die Kette hat drei Paare, und zwei davon sind gemessen.** **`deny` über `allow`:** gemessen am 2026-09-17 – derselbe Befehl in beiden Körben, der Lauf ruft ihn auf und wird abgewiesen (D-121). **`ask` über `allow`:** gemessen am 2026-09-18 – bei `ask` = `Edit(**)` bleibt eine ausdrückliche `allow`-Regel auf einen **einzelnen Pfad** wirkungslos; der Schreibzugriff wird abgewiesen. **Die praktische Folge steht in der Zeile, weil sie sonst niemand sieht:** Ein Projekt kann eine einzelne Datei **nicht** vorab zum Schreiben freigeben, solange `Edit(**)` im `ask`-Korb steht – der Korb schluckt die engere Regel. **`deny` über `ask`:** unbelegt **Ein Befehl in keinem Korb** (`K-208`, D-537, gemessen 2026-10-01 mit 2.1.285 im Druckmodus): `git ls-files` lief ohne Eintrag und ohne Rückfrage – der Client gibt lesende Befehle selbst frei; mit `Bash(git ls-files:*)` in `deny` wurde er abgewiesen. Der `allow`-Korb ist damit für lesende Befehle keine Grenze, `deny` ist es | `[TECHNISCH]` | **Gemessen am 2026-09-18** (`tests/protocols/2026-09-18-sitzungstest-pi-ds-2.md` Abschnitt 5.2) für `ask` über `allow`: ein Paar, das sich in **genau einer Zeile** der Berechtigungsdatei unterscheidet – mit `Edit(**)` im `ask`-Korb ein `permission_denial` auf `Edit`, ohne ihn keines und die Datei geschrieben. **Gemessen am 2026-09-17** (D-121, `tests/protocols/2026-09-17-sitzungstest-schranken.md`) für `deny` über `allow`. Zuvor vollständig `[DOK]`; **`deny` über `ask` bleibt `[DOK]` `QC-2` (Zuordnung `K-62`) – der Fall ist nicht gemessen** |
-| B3 | Secret-Dateien per Pfadmuster lesegeschützt | ja | Verweigerungsregeln auf `./.env`, `**/*.pem`, `**/secrets/**` und weitere. Mustersemantik: gitignore-Syntax; ein bloßer Dateiname trifft in jeder Tiefe (`Read(.env)` ist gleichbedeutend mit `Read(**/.env)`); ein einsegmentiges Verzeichnismuster trifft in `deny` und `ask` in jeder Tiefe, in `allow` nur am verankerten Ort. Unter Windows werden Pfade vor dem Vergleich auf POSIX-Form normalisiert, und der Vergleich unterscheidet **nicht** zwischen Groß- und Kleinschreibung: `Read(**/*.secret)` weist `UNTEN/NOTIZ.SECRET` ab wie `klein/notiz.secret` (gemessen am 2026-09-30, 2.1.285, `K-92`, D-492) – anders als bei `devin-desktop` (D-277). **Je Kanal:** direktes Lesen **wirkt** (Regel und Hook); Shell **wirkt** (der Schutz-Hook zerlegt den Befehl in Tokens); **Suche wirkt allein über den Hook**, weil dieser Client für `Grep` und `Glob` keine Pfadregeln auswertet (`AP2-CC-02`); Unterprozess **nicht nachgewiesen** | `[TECHNISCH]` für Lesen, Shell und Suche; `[TEXTUELL]` für den Unterprozess | [DOK] **`QC-2`** `docs/en/permissions` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`). **Reichweite je Kanal gemessen am 2026-09-12** (`tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`, B04): Vor 0.30.0 passierte eine Suche über einen Secret-Pfad beide Schichten (Lauf B04-5); der Hook-Eintrag schließt den Kanal, nachgewiesen mit zwei Sonden und zwei Gegenproben **PowerShell** (seit `1.18.2`, D-469): `Get-Content .env` weist der Schutz-Hook ab (`PreToolUse:PowerShell`), gemessen; der Matcher nennt das Werkzeug |
-| B4 | Framework- und Overlay-Artefakte schreibgeschützt | ja | Je Pfad **eine** `Edit(...)`-Regel; das Kernverzeichnis ist seit `CR-2026-012` als Ganzes erfasst (`Edit(.koolie/core/**)`). Eine zusätzliche `Write(...)`-Pfadregel wäre wirkungslos und wird seit `CR-2026-016` nicht mehr erzeugt. **Je Kanal:** direktes Schreiben **wirkt** (Regel und Hook); **Shell und Unterprozess wirken nicht** – die Berechtigungsdatei führt für `exec` ausschließlich Befehlsverbote und keine einzige Pfadregel, und der Schutz-Hook prüft das Kernverzeichnis nur bei schreibenden Werkzeugen. Was den Shell-Schreibweg aufhält, ist die Regelschicht | `[TECHNISCH]` für das direkte Schreiben; **`[TEXTUELL]` für Shell und Unterprozess** | wie B3. **Reichweite je Kanal gemessen am 2026-09-12** (`tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`, B04): `sed -i … <kern>/VERSION`, ein Änderungsskript mit Kernpfad und eine Umleitung in die Wurzel-Anweisungsdatei passieren den Hook sämtlich (B04-1 bis B04-3). **Eine technische Durchsetzung bräuchte eine Isolationsschicht des Betriebssystems; deren Reichweite ist auf dieser Plattform unerhoben** |
-| B5 | CI-, Quality-Gate- und Lockdateien schreibgeschützt | ja | dito, je Pfad eine `Edit(...)`-Regel. **Je Kanal wie B4:** direktes Schreiben wirkt, Shell und Unterprozess nicht | `[TECHNISCH]` für das direkte Schreiben; **`[TEXTUELL]` für Shell und Unterprozess** | wie B4 |
-| B6 | Befehle per Muster verweigerbar | ja | Präfixmuster, z. B. `Bash(git push:*)`. Wirkt **breiter** als eine Verweigerung des vollständigen Befehls – und **schmaler als der Befehl**: Das Muster trifft jedes Kommando, das mit der **Zeichenfolge** beginnt, und eine andere Schreibweise desselben Befehls beginnt nicht damit. **Gemessen am 2026-09-17** (D-123): Bei `deny` = `Bash(git push:*)` und `allow` = `Bash(git:*)` wird `git push origin main` abgewiesen, `git -C <pfad> push origin main` läuft durch und erreicht das Remote. **In der ausgelieferten Fassung hält die Sperre trotzdem** – der `allow`-Korb führt nur fünf lesende `git`-Kommandos, und was dort nicht steht, fällt im nicht-interaktiven Betrieb ohnehin auf eine Abweisung (gemessen im Zuschnitt `W`). **Der Gurt hat ein Loch, die Hosenträger halten:** Ein Projekt, das seinen `allow`-Korb auf `Bash(git:*)` verbreitert, verliert den Schutz auf Fernwirkung **ohne jede Meldung** (`K-47`) | `[TECHNISCH]` | wie B3 für den Mechanismus; **die Grenze gemessen am 2026-09-17** (`tests/protocols/2026-09-17-sitzungstest-schranken.md` Abschnitt 6, Läufe `PX1` und `PX2`, Wirkung am Remote nachgeprüft). Der Satz stand seit 0.15.0 als unbelegte Notiz in Abschnitt 4 und verwies für seinen Inhalt auf **diese** Zeile, die ihn nicht trug (`K-48`) 🟢 **PowerShell seit `1.18.2` gleichgestellt** (D-469, gemessen am 2026-09-29 mit 2.1.284, Modus `bypassPermissions`, Baum ohne Regeltexte): `PowerShell(git push:*)` weist `git push origin main` ab, auch verkettet (`git status; git push origin main`) und in Großschreibung (`GIT PUSH origin main`); `Remove-Item -Recurse -Force` und `curl` wurden ebenfalls abgewiesen, ohne dass eine eigene Regel für das Cmdlet besteht – die Zuordnung zu `PowerShell(rm:*)` und `PowerShell(curl:*)` (Aliase) ist gefolgert, nicht getrennt gemessen. `PowerShell(git status:*)` in `allow` lässt `git status` durch. 🔴 **Und ohne diese Regeln fehlt das Werkzeug:** Steht in `deny` eine `Bash(…)`-Regel und keine `PowerShell(…)`-Regel, bietet der Client das Werkzeug gar nicht an (Startmeldung, ohne Modellaufruf); jede `PowerShell(…)`-Regel in `allow` oder `deny` schaltet es ein, der Hook-Matcher allein nicht. Undokumentiert – deshalb trägt die Sperre die Regel, nicht die Ausblendung (D-470) |
-| B7 | Schreiboperationen fragen zurück | – | `ask` auf `Edit(**)` | `[TECHNISCH]` | `[DOK]` **`QC-2`** (Zuordnung `K-62`) |
-| B8 | Netzwerkzugriff standardmäßig unterbunden | – | Verweigerung der Abrufwerkzeuge sowie der Befehle `curl`, `wget`, `ssh` und `scp`. **Je Kanal:** die Abrufwerkzeuge **wirken** (`deny` auf das Abrufverb); der Shell-Kanal **nur für diese vier Programme** – jedes andere netzfähige Programm (`python`, `node`, `git`, Bordmittel der Shell, ein eigenes Skript) ist nicht erfasst. **Die Liste wird bewusst nicht verlängert:** Jedes ergänzte Programm suggeriert eine Vollständigkeit, die ein Befehlsmuster nicht herstellen kann | `[TECHNISCH]` für die Abrufwerkzeuge; **`[TEXTUELL]` für den Shell-Kanal** | `[DOK]` **`QC-2`** (Zuordnung `K-62`). **Reichweite je Kanal gemessen am 2026-09-12** (`tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`, B04) (Lauf B04-6). Wer eine vollständige Netzsperre braucht, betreibt den Agenten ohne automatische Befehlsausführung |
-| B9 | Nutzerlokale Konfiguration kann nur verschärfen | – | `.claude/settings.local.json` rangiert **über** der Projektdatei, kann eine dort gesetzte Verweigerung aber nicht aufheben: „If a tool is denied at any level, no other level can allow it." Ergänzend greifen `deny`- und `ask`-Regeln sofort, `allow`-Regeln erst nach dem Vertrauen in den Ordner | `[TECHNISCH]` für die Verweigerungen; `[TEXTUELL]` für den Rest | [DOK] **`QC-2`, `QC-5`** (`docs/en/permissions`, `docs/en/settings`) (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`); **beobachtet am 2026-09-12** (`tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`), fünf Läufe gegen die **nutzerglobale** Datei `~/.claude/settings.json`, jeder mit Positivkontrolle: Projekt `deny` gegen Benutzer `allow` – nicht gelesen; Projekt `allow` gegen Benutzer `deny` – nicht gelesen; **ohne jede Verweigerung gelesen** (Kontrolllauf, ohne den die anderen nichts bedeuten). Ebenso wirkungslos blieb ein nutzerglobales `defaultMode: bypassPermissions`, mit und ohne projektseitiges `defaultMode`. **Die Zusage bestätigt sich – und das ist bemerkenswert, weil dieselbe Frage beim anderen Pack das Gegenteil ergab** (`ERH-11`, K-27: dort setzt sich die Benutzerkonfiguration in beide Richtungen durch). Gemessen sind die Mechaniken `deny` und `defaultMode`; für Verschärfungen anderer Art gilt die Aussage nicht |
-| B10 | Externer Abruf auf freigegebene Domains beschränkbar | – | **Keiner.** Die Abbildung führt die Abrufwerkzeuge in `permission_tools_bare`: Ein Muster wird verworfen, die erzeugte Regel lautet `WebFetch` und `WebSearch` **ohne Argument** – das ganze Werkzeug, nicht ein Ziel. Eine Domain-Angabe ist damit nicht ausdrückbar. **Ersatz:** das vollständige Verbot, das dadurch entsteht und als Verbot `[TECHNISCH]` wirkt (B8) – es ist **strenger** als die Zusage, nicht schwächer, und deshalb kein Schutzverlust. Für eine Websuche gibt es überhaupt kein Domain-Ziel; auch ein künftiger Mechanismus könnte sie nicht abdecken (Paket 6) | `[NICHT ABBILDBAR]` | `[DOK]` **`QC-2`** (Zuordnung `K-62`) für die Produktseite: Pfadregeln werden nur für `Read` und `Edit` ausgewertet, für andere Werkzeuge angenommen und **nie konsultiert** – ein Domänenmuster am Abrufwerkzeug hat deshalb keinen Ort. 🔴 **Bis 0.84.0 belegte diese Zelle gegen den eigenen Bestand** (`K-62`, 2026-09-22): Der Zusatz „für die Abbildung" nannte `permission_tools_bare` im Manifest und die erzeugte Datei (nachgeprüft am 2026-09-13) – beides Nachweise **des Frameworks über sich selbst**, während die Marke `[DOK]` „in der Herstellerdokumentation beschrieben" heißt. Die Abbildung ist damit nicht weniger belegt, sondern **anders**. Seit 0.33.0 sagt der Kern diese Beschränkung nicht mehr zu (B11, D-59) |
+| B2 | Verweigern vor Rückfragen vor Erlauben | ja | `permissions.deny` / `.ask` / `.allow`. Die Kette hat drei Paare, und zwei davon sind gemessen. `deny` über `allow`: gemessen am 2026-09-17 – derselbe Befehl in beiden Körben, der Lauf ruft ihn auf und wird abgewiesen. `ask` über `allow`: gemessen am 2026-09-18 – bei `ask` = `Edit()` bleibt eine ausdrückliche `allow`-Regel auf einen einzelnen Pfad wirkungslos; der Schreibzugriff wird abgewiesen. Die praktische Folge steht in der Zeile, weil sie sonst niemand sieht: Ein Projekt kann eine einzelne Datei nicht vorab zum Schreiben freigeben, solange `Edit()` im `ask`-Korb steht – der Korb schluckt die engere Regel. `deny` über `ask`: unbelegt Ein Befehl in keinem Korb (gemessen 2026-10-01 mit 2.1.285 im Druckmodus): `git ls-files` lief ohne Eintrag und ohne Rückfrage – der Client gibt lesende Befehle selbst frei; mit `Bash(git ls-files:*)` in `deny` wurde er abgewiesen. Der `allow`-Korb ist damit für lesende Befehle keine Grenze, `deny` ist es | `[TECHNISCH]` | **Gemessen am 2026-09-18** (`tests/protocols/2026-09-18-sitzungstest-pi-ds-2.md` Abschnitt 5.2) für `ask` über `allow`: ein Paar, das sich in **genau einer Zeile** der Berechtigungsdatei unterscheidet – mit `Edit(**)` im `ask`-Korb ein `permission_denial` auf `Edit`, ohne ihn keines und die Datei geschrieben. **Gemessen am 2026-09-17** (D-121, `tests/protocols/2026-09-17-sitzungstest-schranken.md`) für `deny` über `allow`. Zuvor vollständig `[DOK]`; **`deny` über `ask` bleibt `[DOK]` `QC-2` (Zuordnung `K-62`) – der Fall ist nicht gemessen** |
+| B3 | Secret-Dateien per Pfadmuster lesegeschützt | ja | Verweigerungsregeln auf `./.env`, `/*.pem`, `/secrets/` und weitere. Mustersemantik: gitignore-Syntax; ein bloßer Dateiname trifft in jeder Tiefe (`Read(.env)` ist gleichbedeutend mit `Read(/.env)`); ein einsegmentiges Verzeichnismuster trifft in `deny` und `ask` in jeder Tiefe, in `allow` nur am verankerten Ort. Unter Windows werden Pfade vor dem Vergleich auf POSIX-Form normalisiert, und der Vergleich unterscheidet nicht zwischen Groß- und Kleinschreibung: `Read(/*.secret)` weist `UNTEN/NOTIZ.SECRET` ab wie `klein/notiz.secret` (gemessen am 2026-09-30, 2.1.285) – anders als bei `devin-desktop`. Je Kanal: direktes Lesen wirkt (Regel und Hook); Shell wirkt (der Schutz-Hook zerlegt den Befehl in Tokens); Suche wirkt allein über den Hook, weil dieser Client für `Grep` und `Glob` keine Pfadregeln auswertet (`AP2-CC-02`); Unterprozess nicht nachgewiesen | `[TECHNISCH]` für Lesen, Shell und Suche; `[TEXTUELL]` für den Unterprozess | [DOK] **`QC-2`** `docs/en/permissions` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`). **Reichweite je Kanal gemessen am 2026-09-12** (`tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`, B04): Vor 0.30.0 passierte eine Suche über einen Secret-Pfad beide Schichten (Lauf B04-5); der Hook-Eintrag schließt den Kanal, nachgewiesen mit zwei Sonden und zwei Gegenproben **PowerShell** (seit `1.18.2`, D-469): `Get-Content .env` weist der Schutz-Hook ab (`PreToolUse:PowerShell`), gemessen; der Matcher nennt das Werkzeug |
+| B4 | Framework- und Overlay-Artefakte schreibgeschützt | ja | Je Pfad eine `Edit(...)`-Regel; das Kernverzeichnis ist als Ganzes erfasst (`Edit(.koolie/core/)`). Eine zusätzliche `Write(...)`-Pfadregel wäre wirkungslos und wird nicht erzeugt. Je Kanal: direktes Schreiben wirkt (Regel und Hook); Shell und Unterprozess wirken nicht – die Berechtigungsdatei führt für `exec` ausschließlich Befehlsverbote und keine einzige Pfadregel, und der Schutz-Hook prüft das Kernverzeichnis nur bei schreibenden Werkzeugen. Was den Shell-Schreibweg aufhält, ist die Regelschicht | `[TECHNISCH]` für das direkte Schreiben; `[TEXTUELL]` für Shell und Unterprozess | wie B3. **Reichweite je Kanal gemessen am 2026-09-12** (`tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`, B04): `sed -i … <kern>/VERSION`, ein Änderungsskript mit Kernpfad und eine Umleitung in die Wurzel-Anweisungsdatei passieren den Hook sämtlich (B04-1 bis B04-3). **Eine technische Durchsetzung bräuchte eine Isolationsschicht des Betriebssystems; deren Reichweite ist auf dieser Plattform unerhoben** |
+| B5 | CI-, Quality-Gate- und Lockdateien schreibgeschützt | ja | dito, je Pfad eine `Edit(...)`-Regel. Je Kanal wie B4: direktes Schreiben wirkt, Shell und Unterprozess nicht | `[TECHNISCH]` für das direkte Schreiben; `[TEXTUELL]` für Shell und Unterprozess | wie B4 |
+| B6 | Befehle per Muster verweigerbar | ja | Präfixmuster, z. B. `Bash(git push:*)`. Wirkt breiter als eine Verweigerung des vollständigen Befehls – und schmaler als der Befehl: Das Muster trifft jedes Kommando, das mit der Zeichenfolge beginnt, und eine andere Schreibweise desselben Befehls beginnt nicht damit. Gemessen am 2026-09-17: Bei `deny` = `Bash(git push:*)` und `allow` = `Bash(git:*)` wird `git push origin main` abgewiesen, `git -C <pfad> push origin main` läuft durch und erreicht das Remote. In der ausgelieferten Fassung hält die Sperre trotzdem – der `allow`-Korb führt nur fünf lesende `git`-Kommandos, und was dort nicht steht, fällt im nicht-interaktiven Betrieb ohnehin auf eine Abweisung (gemessen im Zuschnitt `W`). Aber: Ein Projekt, das seinen `allow`-Korb auf `Bash(git:*)` verbreitert, verliert den Schutz auf Fernwirkung ohne jede Meldung | `[TECHNISCH]` | wie B3 für den Mechanismus; **die Grenze gemessen am 2026-09-17** (`tests/protocols/2026-09-17-sitzungstest-schranken.md` Abschnitt 6, Läufe `PX1` und `PX2`, Wirkung am Remote nachgeprüft). Der Satz stand seit 0.15.0 als unbelegte Notiz in Abschnitt 4 und verwies für seinen Inhalt auf **diese** Zeile, die ihn nicht trug (`K-48`) 🟢 **PowerShell seit `1.18.2` gleichgestellt** (D-469, gemessen am 2026-09-29 mit 2.1.284, Modus `bypassPermissions`, Baum ohne Regeltexte): `PowerShell(git push:*)` weist `git push origin main` ab, auch verkettet (`git status; git push origin main`) und in Großschreibung (`GIT PUSH origin main`); `Remove-Item -Recurse -Force` und `curl` wurden ebenfalls abgewiesen, ohne dass eine eigene Regel für das Cmdlet besteht – die Zuordnung zu `PowerShell(rm:*)` und `PowerShell(curl:*)` (Aliase) ist gefolgert, nicht getrennt gemessen. `PowerShell(git status:*)` in `allow` lässt `git status` durch. 🔴 **Und ohne diese Regeln fehlt das Werkzeug:** Steht in `deny` eine `Bash(…)`-Regel und keine `PowerShell(…)`-Regel, bietet der Client das Werkzeug gar nicht an (Startmeldung, ohne Modellaufruf); jede `PowerShell(…)`-Regel in `allow` oder `deny` schaltet es ein, der Hook-Matcher allein nicht. Undokumentiert – deshalb trägt die Sperre die Regel, nicht die Ausblendung (D-470) |
+| B7 | Schreiboperationen fragen zurück | – | `ask` auf `Edit()` | `[TECHNISCH]` | `[DOK]` **`QC-2`** (Zuordnung `K-62`) |
+| B8 | Netzwerkzugriff standardmäßig unterbunden | – | Verweigerung der Abrufwerkzeuge sowie der Befehle `curl`, `wget`, `ssh` und `scp`. Je Kanal: die Abrufwerkzeuge wirken (`deny` auf das Abrufverb); der Shell-Kanal nur für diese vier Programme – jedes andere netzfähige Programm (`python`, `node`, `git`, Bordmittel der Shell, ein eigenes Skript) ist nicht erfasst. Die Liste wird bewusst nicht verlängert: Jedes ergänzte Programm suggeriert eine Vollständigkeit, die ein Befehlsmuster nicht herstellen kann | `[TECHNISCH]` für die Abrufwerkzeuge; `[TEXTUELL]` für den Shell-Kanal | `[DOK]` **`QC-2`** (Zuordnung `K-62`). **Reichweite je Kanal gemessen am 2026-09-12** (`tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`, B04) (Lauf B04-6). Wer eine vollständige Netzsperre braucht, betreibt den Agenten ohne automatische Befehlsausführung |
+| B9 | Nutzerlokale Konfiguration kann nur verschärfen | – | `.claude/settings.local.json` rangiert über der Projektdatei, kann eine dort gesetzte Verweigerung aber nicht aufheben: „If a tool is denied at any level, no other level can allow it." Ergänzend greifen `deny`- und `ask`-Regeln sofort, `allow`-Regeln erst nach dem Vertrauen in den Ordner | `[TECHNISCH]` für die Verweigerungen; `[TEXTUELL]` für den Rest | [DOK] **`QC-2`, `QC-5`** (`docs/en/permissions`, `docs/en/settings`) (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`); **beobachtet am 2026-09-12** (`tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`), fünf Läufe gegen die **nutzerglobale** Datei `~/.claude/settings.json`, jeder mit Positivkontrolle: Projekt `deny` gegen Benutzer `allow` – nicht gelesen; Projekt `allow` gegen Benutzer `deny` – nicht gelesen; **ohne jede Verweigerung gelesen** (Kontrolllauf, ohne den die anderen nichts bedeuten). Ebenso wirkungslos blieb ein nutzerglobales `defaultMode: bypassPermissions`, mit und ohne projektseitiges `defaultMode`. **Die Zusage bestätigt sich – und das ist bemerkenswert, weil dieselbe Frage beim anderen Pack das Gegenteil ergab** (`ERH-11`, K-27: dort setzt sich die Benutzerkonfiguration in beide Richtungen durch). Gemessen sind die Mechaniken `deny` und `defaultMode`; für Verschärfungen anderer Art gilt die Aussage nicht |
+| B10 | Externer Abruf auf freigegebene Domains beschränkbar | – | Keiner. Die Abbildung führt die Abrufwerkzeuge in `permission_tools_bare`: Ein Muster wird verworfen, die erzeugte Regel lautet `WebFetch` und `WebSearch` ohne Argument – das ganze Werkzeug, nicht ein Ziel. Eine Domain-Angabe ist damit nicht ausdrückbar. Ersatz: das vollständige Verbot, das dadurch entsteht und als Verbot `[TECHNISCH]` wirkt (B8) – es ist strenger als die Zusage, nicht schwächer, und deshalb kein Schutzverlust. Für eine Websuche gibt es überhaupt kein Domain-Ziel; auch ein künftiger Mechanismus könnte sie nicht abdecken | `[NICHT ABBILDBAR]` | `[DOK]` **`QC-2`** (Zuordnung `K-62`) für die Produktseite: Pfadregeln werden nur für `Read` und `Edit` ausgewertet, für andere Werkzeuge angenommen und **nie konsultiert** – ein Domänenmuster am Abrufwerkzeug hat deshalb keinen Ort. 🔴 **Bis 0.84.0 belegte diese Zelle gegen den eigenen Bestand** (`K-62`, 2026-09-22): Der Zusatz „für die Abbildung" nannte `permission_tools_bare` im Manifest und die erzeugte Datei (nachgeprüft am 2026-09-13) – beides Nachweise **des Frameworks über sich selbst**, während die Marke `[DOK]` „in der Herstellerdokumentation beschrieben" heißt. Die Abbildung ist damit nicht weniger belegt, sondern **anders**. Seit 0.33.0 sagt der Kern diese Beschränkung nicht mehr zu (B11, D-59) |
 
 ### H – Hooks
 
 | ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
 |---|---|---|---|---|
-| H1 | Prüfung vor Werkzeugausführung | `hooks.PreToolUse` in `settings.json`, Matcher auf **lesende**, schreibende und ausführende Werkzeuge und seit `1.20.0` auf **MCP-Werkzeuge** (`mcp__.*`). Bei einem MCP-Werkzeug prüft der Hook den Inhalt gegen die Secret-Muster und die Pfadfelder gegen die Secret-Pfade, nicht die Strukturpfade (D-486). Jede Entscheidung steht im Entscheidungsprotokoll `.git/koolie-hook.jsonl`, ohne Inhalt und Pfad (D-487) | `[TECHNISCH]` | `[DOK]` **`QC-6`** (Zuordnung `K-62`, D-159); das Lesewerkzeug seit 0.25.0 (`CR-2026-030`, D-33) – bis dahin erreichte ein Lesezugriff den Hook nicht. **MCP gemessen am 2026-09-29** (2.1.284, Messreihe `1200`, `tests/protocols/2026-09-29-schutzschicht.md`): Ohne den Matcher erreichte ein Köderwert einen lokalen MCP-Server, und ein Dateisystem-Werkzeug las `.env`; mit ihm sperrte der Hook beides, und eine Notiz, die `.env` nur nennt, kam an. Die Wirkung im Projekt prüft `install.py --probe` (D-488) |
-| H2 | Prüfung kann **blockieren** | Exit-Code 2 des Hook-Befehls blockiert die Ausführung, und zwar **bevor** die Berechtigungsregeln ausgewertet werden – ein blockierender Hook geht damit auch einer `allow`-Regel vor. Umgekehrt hebt eine Hook-Entscheidung keine `deny`- oder `ask`-Regel auf. **Fail-closed**: Das erzeugte Hook-Kommando trägt `--fail-closed`, eine Werkzeugeingabe, die der Hook nicht lesen kann, wird blockiert statt durchgelassen (D-31). **Reichweite, gemessen am 2026-09-13** (D-69): Der Hook erfasst auch die Werkzeugaufrufe eines **Unteragenten** und blockiert sie – nicht nur mit dem Matcher `*`, sondern auch mit der benannten Form `Edit\|Write\|NotebookEdit`, die `clientmap.py` aus `hook_tools` erzeugt. **Der Unteragent ist kein Weg am Schutz-Hook vorbei.** Ein Aufruf aus einem Unteragenten ist am Umschlag erkennbar: Er führt zusätzlich `agent_id` und `agent_type`. **Nicht gemessen:** derselbe Lauf mit dem Schutz-Hook des Frameworks in einer vollständigen Installation – gemessen ist ein synthetischer Sperr-Hook in der erzeugten Form | `[TECHNISCH]` | **Reichweite gemessen am 2026-09-13** (`tests/protocols/2026-09-13-erhebung-unteragent.md`, Läufe H1 bis H3 mit Gegenprobe); im Übrigen [DOK] **`QC-2`** `docs/en/permissions` (AP2, Clientversion 2.1.267) – **stärker belegt als beim Client Pack `devin-desktop`**, siehe Abschnitt 5 |
+| H1 | Prüfung vor Werkzeugausführung | `hooks.PreToolUse` in `settings.json`, Matcher auf lesende, schreibende und ausführende Werkzeuge und auf MCP-Werkzeuge (`mcp__.*`). Bei einem MCP-Werkzeug prüft der Hook den Inhalt gegen die Secret-Muster und die Pfadfelder gegen die Secret-Pfade, nicht die Strukturpfade. Jede Entscheidung steht im Entscheidungsprotokoll `.git/koolie-hook.jsonl`, ohne Inhalt und Pfad | `[TECHNISCH]` | `[DOK]` **`QC-6`** (Zuordnung `K-62`, D-159); das Lesewerkzeug seit 0.25.0 (`CR-2026-030`, D-33) – bis dahin erreichte ein Lesezugriff den Hook nicht. **MCP gemessen am 2026-09-29** (2.1.284, Messreihe `1200`, `tests/protocols/2026-09-29-schutzschicht.md`): Ohne den Matcher erreichte ein Köderwert einen lokalen MCP-Server, und ein Dateisystem-Werkzeug las `.env`; mit ihm sperrte der Hook beides, und eine Notiz, die `.env` nur nennt, kam an. Die Wirkung im Projekt prüft `install.py --probe` (D-488) |
+| H2 | Prüfung kann blockieren | Exit-Code 2 des Hook-Befehls blockiert die Ausführung, und zwar bevor die Berechtigungsregeln ausgewertet werden – ein blockierender Hook geht damit auch einer `allow`-Regel vor. Umgekehrt hebt eine Hook-Entscheidung keine `deny`- oder `ask`-Regel auf. Fail-closed: Das erzeugte Hook-Kommando trägt `--fail-closed`, eine Werkzeugeingabe, die der Hook nicht lesen kann, wird blockiert statt durchgelassen. Reichweite, gemessen am 2026-09-13: Der Hook erfasst auch die Werkzeugaufrufe eines Unteragenten und blockiert sie – nicht nur mit dem Matcher `*`, sondern auch mit der benannten Form `Edit\|Write\|NotebookEdit`, die `clientmap.py` aus `hook_tools` erzeugt. Der Unteragent ist kein Weg am Schutz-Hook vorbei. Ein Aufruf aus einem Unteragenten ist am Umschlag erkennbar: Er führt zusätzlich `agent_id` und `agent_type`. Nicht gemessen: derselbe Lauf mit dem Schutz-Hook des Frameworks in einer vollständigen Installation – gemessen ist ein synthetischer Sperr-Hook in der erzeugten Form | `[TECHNISCH]` | **Reichweite gemessen am 2026-09-13** (`tests/protocols/2026-09-13-erhebung-unteragent.md`, Läufe H1 bis H3 mit Gegenprobe); im Übrigen [DOK] **`QC-2`** `docs/en/permissions` (AP2, Clientversion 2.1.267) – **stärker belegt als beim Client Pack `devin-desktop`**, siehe Abschnitt 5 |
 | H3 | Statusmeldung beim Sitzungsstart | `hooks.SessionStart`; das Kommando gibt `hookSpecificOutput.additionalContext` aus | `[TECHNISCH]` | **Gemessen am 2026-09-18** (`.koolie/core/tests/protocols/2026-09-18-sitzungstest-5.md` Abschnitt 4, D-176), an drei Bäumen, die sich in genau einem Schlüssel der Berechtigungsdatei unterscheiden. **Zustellung:** Die `additionalContext`-Zeichenkette des Hooks steht **wörtlich in der Sitzungsmitschrift** der beiden Läufe mit Hook und fehlt in dem ohne. **Wirkung:** Mit geschnittenem Regeltext blieb der Lauf **mit** Hook nur lesend und änderte **ohne** ihn `bestand.ts:15` – obwohl zwanzig Fundstellen derselben Regel im Baum blieben. **Grenze, und sie gehört in diese Zeile:** Das ist eine **Verhaltensdifferenz eines Paares**, keine Zusage – der Hook sperrt nichts, er liefert Text. Bis 0.65.0 war die Zeile mit `[DOK]` belegt; die Übergabe führte H3 unter *Ungemessenes*. **Zweite Messung desselben Tages, von der anderen Seite:** In einem Baum ohne Overlay hat genau dieser Hook (*„Status unbekannt → nur lesend"*) den Schreibversuch verhindert, den `FW-AK-02` messen sollte – **wer die Regelschicht für einen Zuschnitt entfernt, entfernt ihn mit** |
-| H4 | Eingabeschema und Pfadidentität des Schutz-Hooks | Der Hook prüft ein **Ereignis**: JSON-Objekt, nicht leerer `tool_name`, `tool_input` als Objekt; alles andere gilt als **unprüfbar** und blockiert hier, weil dieses Pack `hook_fail_closed: true` führt. Geprüft wird die **Operation**, nicht der Umschlag – `transcript_path`, `cwd` und `session_id` sind kein Ziel. Pfadangaben werden gegen `cwd` aufgelöst und in aufgelöster Form noch einmal gegen die Muster gehalten; alle Pfadmuster sind groß-/kleinschreibungsunempfindlich. Eine Angabe in POSIX-Schreibweise (`/c/…`) löst der Hook unter Windows in **beiden** Lesarten auf, `C:\…` und `C:\c\…`, und die strengere gewinnt: Das Werkzeug `Write` dieses Clients legt `/c/lw-1201/msys-ziel/probe.txt` unter `C:\lw-1201\…` an (gemessen am 2026-09-30, `K-96`, D-491); bis `1.20.0` löste der Hook sie als `C:\c\…` auf, und mit einem Punktsegment oder einem 8.3-Kurznamen erreichte ein Schreibvorgang den Kern. **Grenze, und sie gehört in diese Zeile:** Ein Hook prüft **vor** dem Zugriff. Eine Verknüpfung, die zwischen Prüfung und Zugriff umgebogen wird, kann er nicht ausschließen – das kann nur die ausführende Dateischicht oder eine Isolation (`CR-2026-047` E5) | `[TECHNISCH]`, mit benannter Zeitlücke | **Gemessen am 2026-09-13** (`tests/protocols/2026-09-13-B06-gegenpruefung.md`, Befund **B06**): Das Eingabeschema dieses Clients ist an 15 Hook-Aufzeichnungen belegt. Bis 0.33.0 blockierte der Hook hier **jeden** Schreibzugriff, weil `transcript_path` unter `~/.claude/projects/` liegt – am Client nachgemessen, mit Kontrolllauf. Prüfung 32 ruft den Hook seit 0.34.0 mit dem vollständigen Umschlag auf |
+| H4 | Eingabeschema und Pfadidentität des Schutz-Hooks | Der Hook prüft ein Ereignis: JSON-Objekt, nicht leerer `tool_name`, `tool_input` als Objekt; alles andere gilt als unprüfbar und blockiert hier, weil dieses Pack `hook_fail_closed: true` führt. Geprüft wird die Operation, nicht der Umschlag – `transcript_path`, `cwd` und `session_id` sind kein Ziel. Pfadangaben werden gegen `cwd` aufgelöst und in aufgelöster Form noch einmal gegen die Muster gehalten; alle Pfadmuster sind groß-/kleinschreibungsunempfindlich. Eine Angabe in POSIX-Schreibweise (`/c/…`) löst der Hook unter Windows in beiden Lesarten auf, `C:\…` und `C:\c\…`, und die strengere gewinnt: Das Werkzeug `Write` dieses Clients legt `/c/lw-1201/msys-ziel/probe.txt` unter `C:\lw-1201\…` an (gemessen am 2026-09-30). Grenze, und sie gehört in diese Zeile: Ein Hook prüft vor dem Zugriff. Eine Verknüpfung, die zwischen Prüfung und Zugriff umgebogen wird, kann er nicht ausschließen – das kann nur die ausführende Dateischicht oder eine Isolation | `[TECHNISCH]`, mit benannter Zeitlücke | **Gemessen am 2026-09-13** (`tests/protocols/2026-09-13-B06-gegenpruefung.md`, Befund **B06**): Das Eingabeschema dieses Clients ist an 15 Hook-Aufzeichnungen belegt. Bis 0.33.0 blockierte der Hook hier **jeden** Schreibzugriff, weil `transcript_path` unter `~/.claude/projects/` liegt – am Client nachgemessen, mit Kontrolllauf. Prüfung 32 ruft den Hook seit 0.34.0 mit dem vollständigen Umschlag auf |
 
 ### A – Agentenprofile
 
 | ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
 |---|---|---|---|---|
-| A1 | Rein lesendes Reviewprofil | `.claude/agents/fw-reviewer.md`, Frontmatter-Feld `tools` (ergänzend `disallowedTools`, das zuerst angewandt wird). **Die Beschränkung wirkt technisch, und sie wirkt als Entfernung:** Ein Profil mit `tools: Read, Grep, Glob` hatte kein Schreibwerkzeug im Vorrat, und `permission_denials` blieb **leer** – es ist keine Verweigerung, die man gegen eine Freigabe abwägt, sondern derselbe Mechanismus wie bei S3 (D-68). Eine `allow`-Regel holt das Werkzeug nicht zurück. **Und es kann sich nicht selbst erweitern** (D-73, gemessen am 2026-09-13): Ein Profil mit `tools: Read, Grep, Glob` – genau die Form, die `fw-reviewer` nach der Abbildung trägt – hat **kein Startwerkzeug** und konnte deshalb keinen weiteren Unteragenten starten, dessen Profil weniger beschränkt wäre. Ohne diesen Befund wäre die Zusage „rein lesend" über eine zweite Ebene aushebelbar. **Die Zusage hängt allerdings daran, dass `agent_frontmatter.tool_names` kein Startwerkzeug abbildet** – Prüfung 35 hält das fest, weil es sonst lautlos fallen könnte. **Weiterhin nur dokumentiert und nicht gemessen:** dass ein Profil, dessen `tools`-Liste sich zu keinem Werkzeug auflöst, gar nicht erst gestartet wird | `[TECHNISCH]` | **Gemessen am 2026-09-13** (`tests/protocols/2026-09-13-erhebung-unteragent.md`), Lauf A1-M gegen den Kontrolllauf A1-K: dasselbe Profil ohne das Feld schrieb. Zuvor `[DOK]` **`QC-4`** `docs/en/sub-agents` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) – der Teilsatz zum Startabbruch bleibt `[DOK]` **`QC-4`** |
+| A1 | Rein lesendes Reviewprofil | `.claude/agents/koolie-reviewer.md`, Frontmatter-Feld `tools` (ergänzend `disallowedTools`, das zuerst angewandt wird). Die Beschränkung wirkt technisch, und sie wirkt als Entfernung: Ein Profil mit `tools: Read, Grep, Glob` hatte kein Schreibwerkzeug im Vorrat, und `permission_denials` blieb leer – es ist keine Verweigerung, die man gegen eine Freigabe abwägt, sondern derselbe Mechanismus wie bei S3. Eine `allow`-Regel holt das Werkzeug nicht zurück. Und es kann sich nicht selbst erweitern (gemessen am 2026-09-13): Ein Profil mit `tools: Read, Grep, Glob` – genau die Form, die `koolie-reviewer` nach der Abbildung trägt – hat kein Startwerkzeug und konnte deshalb keinen weiteren Unteragenten starten, dessen Profil weniger beschränkt wäre. Ohne diesen Befund wäre die Zusage „rein lesend" über eine zweite Ebene aushebelbar. Die Zusage hängt allerdings daran, dass `agent_frontmatter.tool_names` kein Startwerkzeug abbildet – Prüfung 35 hält das fest, weil es sonst lautlos fallen könnte. Weiterhin nur dokumentiert und nicht gemessen: dass ein Profil, dessen `tools`-Liste sich zu keinem Werkzeug auflöst, gar nicht erst gestartet wird | `[TECHNISCH]` | **Gemessen am 2026-09-13** (`tests/protocols/2026-09-13-erhebung-unteragent.md`), Lauf A1-M gegen den Kontrolllauf A1-K: dasselbe Profil ohne das Feld schrieb. Zuvor `[DOK]` **`QC-4`** `docs/en/sub-agents` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) – der Teilsatz zum Startabbruch bleibt `[DOK]` **`QC-4`** |
 
 ### M – Modi und Sitzungsfreigaben
 
 | ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
 |---|---|---|---|---|
 | M1 | Standardmodus fragt bei Schreiben und Befehlen zurück | `permissions.defaultMode` auf `default` | `[TECHNISCH]` | `[DOK]` **`QC-5`** (Zuordnung `K-62`) – `defaultMode` steht dort als Schlüssel der Einstellungsdatei |
-| M2 | Modus ohne Rückfragen ausschließbar | Per D-05 untersagt **und** technisch sperrbar: `permissions.disableBypassPermissionsMode` auf `"disable"`, in verwalteten Einstellungen nicht überschreibbar, wirkt aber aus jeder Ebene. Zusätzlich wirken `bypassPermissions` und `auto` seit Clientversion 2.1.257 nicht mehr aus Projekt- oder nutzerlokalen Einstellungen. **Offen:** Ein Subagentenprofil kennt ein eigenes Feld `permissionMode`, das den Wert `bypassPermissions` annimmt; ob die Sperre auch dort greift, ist nicht dokumentiert (AP2-CC-12) | `[TECHNISCH]` (Sperre in verwalteten Einstellungen setzt eine Enterprise-Verwaltung voraus) | [DOK] **`QC-2`** `docs/en/permissions` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) |
+| M2 | Modus ohne Rückfragen ausschließbar | Untersagt (`03-security.md` Abschnitt 4) und technisch sperrbar: `permissions.disableBypassPermissionsMode` auf `"disable"`, in verwalteten Einstellungen nicht überschreibbar, wirkt aber aus jeder Ebene. Ab Clientversion 2.1.257 wirken `bypassPermissions` und `auto` nicht aus Projekt- oder nutzerlokalen Einstellungen. Offen: Ein Subagentenprofil kennt ein eigenes Feld `permissionMode`, das den Wert `bypassPermissions` annimmt; ob die Sperre auch dort greift, ist nicht dokumentiert (AP2-CC-12) | `[TECHNISCH]` (Sperre in verwalteten Einstellungen setzt eine Enterprise-Verwaltung voraus) | [DOK] **`QC-2`** `docs/en/permissions` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) |
 | M3 | Freigabe auf die Sitzung begrenzbar | Rückfragen bieten eine einmalige und eine sitzungsweite Bestätigung an | `[TECHNISCH]` | `[DOK]` – 🔴 **QUELLE NICHT ZUGEORDNET** (`K-62`, 2026-09-22): Keine der sechs Seiten der Quellenliste führt die **Sitzungs-Grant-Stufen**; beim Schwesterpack trägt sie `QD-11`. Eine Zuordnung wäre hier **geraten, und eine geratene sähe wie ein Beleg aus** (D-156). ➡️ **Damit hat der nächste Durchgang von `FW-AK-01` seinen ersten gezielten Auftrag:** eine Zeile gegen eine Seite statt 44 gegen 22 |
-| M4 | Eigener Planungsmodus für Modus M2 | **Unerhoben:** ob der Client einen Planungsmodus mit eigener Plan-Ablage außerhalb des Repositorys führt. Bis dahin ist die Ablage von `fw-plan` und `fw-bugfix-prepare` die Sitzungsausgabe | `[TEXTUELL]` | **`BELEG OFFEN`** (2026-09-25, `K-149`): weder gemessen noch einer Quelle `QC-1` bis `QC-6` zugeordnet. **Unabhängig davon lässt sich M2 seit `1.20.2` an den Schutz-Hook binden** (`mandat.py modus M2 --ablage <pfad>`, D-501), **gemessen am 2026-09-30:** Der Hook wies `Write` auf `src/Neu.java` ab und ließ `docs/plaene/plan.md` durch (Entscheidungsprotokoll); danach fragte die Berechtigungsschicht zurück (`ask Edit(**)`). **Seit `1.23.0` lassen sich auch M3 bis M5 binden** (`mandat.py modus M3\|M4\|M5`, D-523), **gemessen am 2026-10-01** mit `haiku`: Gebunden ließ der Hook je Modus das Ziel in der Pfadliste durch und wies `Write` außerhalb ab – M3 mit `--umfang src/ui/**` auch einen Nur-Lese-Pfad und ein Ziel außerhalb des Umfangs, M4 den Produktivcode neben einer Testdatei aus `src/**/*.test.ts`; ohne Bindung ließ er beide Ziele durch (Entscheidungsprotokoll) |
+| M4 | Eigener Planungsmodus für Modus M2 | Unerhoben: ob der Client einen Planungsmodus mit eigener Plan-Ablage außerhalb des Repositorys führt. Bis dahin ist die Ablage von `koolie-plan` und `koolie-bugfix-prepare` die Sitzungsausgabe | `[TEXTUELL]` | **`BELEG OFFEN`** (2026-09-25, `K-149`): weder gemessen noch einer Quelle `QC-1` bis `QC-6` zugeordnet. **Unabhängig davon lässt sich M2 seit `1.20.2` an den Schutz-Hook binden** (`mandat.py modus M2 --ablage <pfad>`, D-501), **gemessen am 2026-09-30:** Der Hook wies `Write` auf `src/Neu.java` ab und ließ `docs/plaene/plan.md` durch (Entscheidungsprotokoll); danach fragte die Berechtigungsschicht zurück (`ask Edit(**)`). **Seit `1.23.0` lassen sich auch M3 bis M5 binden** (`mandat.py modus M3\|M4\|M5`, D-523), **gemessen am 2026-10-01** mit `haiku`: Gebunden ließ der Hook je Modus das Ziel in der Pfadliste durch und wies `Write` außerhalb ab – M3 mit `--umfang src/ui/**` auch einen Nur-Lese-Pfad und ein Ziel außerhalb des Umfangs, M4 den Produktivcode neben einer Testdatei aus `src/**/*.test.ts`; ohne Bindung ließ er beide Ziele durch (Entscheidungsprotokoll) |
 
 ### X – Externe Anbindung
 
 | ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
 |---|---|---|---|---|
-| X1 | Keine externe Anbindung ohne Einzelfreigabe | Keine `.mcp.json` ausgeliefert, nur die `.example`-Vorlage; Rückfrageregel auf alle MCP-Werkzeuge | `[TECHNISCH]`, **mit einer benannten Grenze** | `[DOK]` **`QC-3`, `QC-5`** (`docs/en/skills`, `docs/en/settings`), Stand 2.1.275 (`FW-AK-01`, 2026-09-18). **Die Grenze:** Der Mechanismus deckt die Werkzeuganbindung. Seit 2.1.275 gibt es einen **zweiten** Kanal nach außen, den er nicht deckt – der Client lädt die im Konto des Anwenders eingeschalteten Skills und Erweiterungen in die Sitzung, *„This is enabled by default"*, mit Abgleich etwa alle zehn Minuten. **Und das Framework kann ihn nicht abschalten:** Der Schalter `syncClaudeAiSkills: false` wirkt aus verwalteten Einstellungen, aus `--settings`, aus der Benutzerdatei und aus der unversionierten Projektdatei – *„a `false` in `.claude/settings.json` is ignored"*, und genau diese Datei liefert dieses Pack aus. **Die Zusage gilt damit für die Werkzeuganbindung und nicht für die Kontoquelle**; wer sie schließen will, setzt den Schalter außerhalb des Repositoriums (`K-63`). Das Gegenstück, das das Framework **sehr wohl** liefern kann, steht in Abschnitt 8: `autoMemoryEnabled: false` (D-154). **Freigabe je Werkzeug, gemessen am 2026-09-28** (2.1.283, D-459): `mcp__<server>__<werkzeug>` in `allow` lässt ein Lesewerkzeug ohne Rückfrage laufen, ein Schreibwerkzeug in `ask` wird im Druckmodus abgewiesen – aber die Rückfrage `mcp__*`, die die Kernquelle erzeugt, **schlägt** die Einzelfreigabe. Gibt ein Projekt einen Server zum Lesen frei (Overlay Abschnitt 13.2), ersetzt der Mensch die Pauschale durch die Einzelregeln; Prüfung 101 gleicht ab (`mcp_permission_rule` im Manifest) |
+| X1 | Keine externe Anbindung ohne Einzelfreigabe | Keine `.mcp.json` ausgeliefert, nur die `.example`-Vorlage; Rückfrageregel auf alle MCP-Werkzeuge | `[TECHNISCH]`, mit einer benannten Grenze | `[DOK]` **`QC-3`, `QC-5`** (`docs/en/skills`, `docs/en/settings`), Stand 2.1.275 (`FW-AK-01`, 2026-09-18). **Die Grenze:** Der Mechanismus deckt die Werkzeuganbindung. Seit 2.1.275 gibt es einen **zweiten** Kanal nach außen, den er nicht deckt – der Client lädt die im Konto des Anwenders eingeschalteten Skills und Erweiterungen in die Sitzung, *„This is enabled by default"*, mit Abgleich etwa alle zehn Minuten. **Und das Framework kann ihn nicht abschalten:** Der Schalter `syncClaudeAiSkills: false` wirkt aus verwalteten Einstellungen, aus `--settings`, aus der Benutzerdatei und aus der unversionierten Projektdatei – *„a `false` in `.claude/settings.json` is ignored"*, und genau diese Datei liefert dieses Pack aus. **Die Zusage gilt damit für die Werkzeuganbindung und nicht für die Kontoquelle**; wer sie schließen will, setzt den Schalter außerhalb des Repositoriums (`K-63`). Das Gegenstück, das das Framework **sehr wohl** liefern kann, steht in Abschnitt 8: `autoMemoryEnabled: false` (D-154). **Freigabe je Werkzeug, gemessen am 2026-09-28** (2.1.283, D-459): `mcp__<server>__<werkzeug>` in `allow` lässt ein Lesewerkzeug ohne Rückfrage laufen, ein Schreibwerkzeug in `ask` wird im Druckmodus abgewiesen – aber die Rückfrage `mcp__*`, die die Kernquelle erzeugt, **schlägt** die Einzelfreigabe. Gibt ein Projekt einen Server zum Lesen frei (Overlay Abschnitt 13.2), ersetzt der Mensch die Pauschale durch die Einzelregeln; Prüfung 101 gleicht ab (`mcp_permission_rule` im Manifest) |
 | X2 | Art und Ort der Codebasis-Indexierung bekannt | Kein Indexierungsmechanismus dokumentiert; Dateien werden bei Bedarf gelesen | `[TECHNISCH]` | `[DOK]` **`QC-1` bis `QC-5`** – **Abwesenheit** belegt über `docs/en/memory`, `permissions`, `skills`, `sub-agents`, `settings`, Stand 2.1.267 (AP2), **erneut geprüft am 2026-09-18 gegen 2.1.275** (`FW-AK-01`): unverändert kein Indexierungsmechanismus dokumentiert. Ein Beleg durch Abwesenheit bleibt schwächer als ein Beleg |
 
 ## 3. Zusammenfassung der Durchsetzungstiefe
 
-> **Zählregel (normativ für diese Tabelle):** Eine Zeile zählt bei ihrer **schwächsten** Einstufung. Trägt sie zwei Angaben je Zugriffskanal – `[TECHNISCH]` für direktes Lesen und Schreiben, `[TEXTUELL]` für Shell und Unterprozess –, zählt sie als `[TEXTUELL]`. Das folgt D-47: Zugesagt wird je Kanal, was gemessen ist; eine Zeile, deren Zusage in einem Kanal nur als Anweisung trägt, ist nicht technisch durchgesetzt. Prüfung 31 rechnet die Summen aus der Matrix nach (D-60).
+> **Zählregel (normativ für diese Tabelle):** Eine Zeile zählt bei ihrer schwächsten Einstufung. Trägt sie je Zugriffskanal zwei Angaben – `[TECHNISCH]` für direktes Lesen und Schreiben, `[TEXTUELL]` für Shell und Unterprozess –, zählt sie als `[TEXTUELL]`. Zugesagt wird je Kanal, was gemessen ist. Prüfung 31 rechnet die Summen aus der Matrix nach.
 
-| Klasse | Anzahl | davon Kernzusagen | Stand vor AP2 |
-|---|---|---|---|
-| `[TECHNISCH]` | 22 von 32 | 3 von 6 (B1, B2, B6) | 20 |
-| `[TEXTUELL]` | 8 von 32 (R5, R6, B9, M4; dazu B3, B4, B5, B8 – je Kanal teils technisch) | 3 von 6 (B3, B4, B5 – Shell und Unterprozess) | 2 |
-| `[NICHT ABBILDBAR]` | **2 von 32** (S5, B10) | 0 | 4 |
-| ohne Einstufung | 0 von 32 | 0 | – |
-
-Die Spalte „Stand vor AP2“ bezieht sich auf den kleineren Zeilensatz vor dem ersten Abgleich und wird nicht fortgeschrieben.
+| Klasse | Anzahl | davon Kernzusagen |
+|---|---|---|
+| `[TECHNISCH]` | 22 von 32 | 3 von 6 (B1, B2, B6) |
+| `[TEXTUELL]` | 8 von 32 (R5, R6, B9, M4; dazu B3, B4, B5, B8 – je Kanal teils technisch) | 3 von 6 (B3, B4, B5 – Shell und Unterprozess) |
+| `[NICHT ABBILDBAR]` | 2 von 32 (S5, B10) | 0 |
+| ohne Einstufung | 0 von 32 | 0 |
 
-**Der entscheidende Befund:** Alle sechs Kernzusagen sind abgebildet – **drei davon technisch in jedem Kanal** (B1, B2, B6), drei nur für den direkten Zugriff (B3, B4, B5); für Shell und Unterprozess tragen sie die Regelschicht (D-47).
+Alle sechs Kernzusagen sind abgebildet: B1, B2 und B6 technisch in jedem Kanal, B3, B4 und B5 nur für den direkten Zugriff; für Shell und Unterprozess trägt dort die Regelschicht.
 
-**Zwei Zeilen stehen auf `[NICHT ABBILDBAR]`.** S5 ist gemessen, keine Unterschätzung: Es gibt kein Aufzählungskommando (Erhebung vom 2026-09-12). B10 ist nicht ausdrückbar, weil die Abrufwerkzeuge kein Domainmuster tragen; der Kern sagt diese Beschränkung nicht mehr zu (D-59). Beide sind **keine Kernzusage** (D-41); der Ersatz steht jeweils in der Zeile.
+S5 und B10 stehen auf `[NICHT ABBILDBAR]`. Für S5 gibt es kein Aufzählungskommando (erhoben am 2026-09-12), für B10 tragen die Abrufwerkzeuge kein Domainmuster. Beide sind keine Kernzusage; der Ersatz steht in der Zeile.
 
-Ein Vergleich mit dem Client Pack `devin-desktop` trägt nur eingeschränkt: Beide Packs führen verschiedene Zeilensätze, und ihre Belege sind auf verschiedenen Wegen gewonnen. Die Zahlen jenes Packs stehen in dessen Abschnitt 3.
+Mit `devin-desktop` lassen sich die Zahlen nur eingeschränkt vergleichen: Die Packs führen verschiedene Zeilensätze, und ihre Belege sind verschieden gewonnen.
 
-**Belegstand:** Eine Zeile sagt `BELEG OFFEN` – M4 (`K-149`); der frühere VERIFY-Marker auf R5 ist aufgelöst (D-158). Offen ist eine **Teilfrage** innerhalb von M2: ob die Sperre gegen den Modus ohne Rückfragen auch für das Feld `permissionMode` eines Subagentenprofils gilt (AP2-CC-12). Welche Zeilen in einer laufenden Sitzung gemessen oder beobachtet sind, sagt ihre Belegspalte (*„Gemessen am …“*, *„beobachtet am …“*) – darunter S2, S3, S4, A1, B2 (zwei der drei Vorrangpaare, D-134), B6 (D-123), B9, H2, H3 und H4. Für die übrigen Zeilen stehen die Wirkungsnachweise aus; sie sind gegen die Herstellerdokumentation und die erzeugten Artefakte belegt (`tests/protocols/2026-09-10-AP2-claude-code.md`, Abschnitt „Offen“).
+**Belegstand:** `BELEG OFFEN` steht bei M4. Offen ist außerdem eine Teilfrage in M2: ob die Sperre des Modus ohne Rückfragen auch für das Feld `permissionMode` eines Subagentenprofils gilt. In laufenden Sitzungen gemessen oder beobachtet sind S2, S3, S4, A1, B2 (zwei der drei Vorrangpaare), B6, B9, H2, H3 und H4; ihre Belegspalte nennt Datum und Protokoll. Die übrigen Zeilen sind gegen die Herstellerdokumentation und die erzeugten Artefakte belegt (`tests/protocols/2026-09-10-AP2-claude-code.md`, Abschnitt „Offen").
 
 ## 4. Kernzusagen ohne technische Durchsetzung
 
-**Keine.** Alle sechs Kernzusagen (B1 bis B6) sind für den direkten Zugriff als `[TECHNISCH]` abgebildet, B1, B2 und B6 in jedem Kanal. Für B3, B4 und B5 tragen Shell und Unterprozess nur die Regelschicht; das steht je Kanal in der Matrix und in der Zählung von Abschnitt 3 (D-47).
+**Keine.** Alle sechs Kernzusagen (B1 bis B6) sind für den direkten Zugriff als `[TECHNISCH]` abgebildet, B1, B2 und B6 in jedem Kanal. Für B3, B4 und B5 tragen Shell und Unterprozess nur die Regelschicht (Matrix und Abschnitt 3).
 
-Eine der sechs weicht in der **Form** ab, nicht in der Tiefe – und die Abweichung wirkt in **beide** Richtungen (gemessen am 2026-09-17, D-123). **Die Tiefe bleibt `[TECHNISCH]`:** Was das Muster trifft, setzt die Engine durch, und es schlägt sogar ein ausdrückliches `allow` (D-121).
+B6 weicht in der Form ab, nicht in der Tiefe: Was das Muster trifft, setzt die Engine durch, auch gegen ein ausdrückliches `allow` (gemessen am 2026-09-17).
 
 | ID | Abweichung | Wirkung |
 |---|---|---|
-| B6 | Befehlsverbote wirken präfixbasiert: `Bash(git reset:*)` sperrt **jedes Kommando, das mit der Zeichenfolge `git reset` beginnt** – also auch unkritische Varianten, nicht nur `--hard` | **Verschärfung und Lockerung zugleich, und seit dem 2026-09-17 sind beide gemessen** (D-123). *Verschärfung* (`CR-2026-008`): Die Abbildung verlangt, dass die Präfixform ein Präfix der wörtlichen Form ist, und weist sie sonst zurück. *Lockerung:* Eine andere Schreibweise desselben Befehls beginnt nicht mit der Zeichenfolge – `git -C <pfad> reset` ist nicht erfasst. Die Grenze steht in Matrixzeile B6 selbst, wo die Einstufung steht (`K-48`) |
+| B6 | Befehlsverbote wirken präfixbasiert: `Bash(git reset:*)` sperrt jedes Kommando, das mit der Zeichenfolge `git reset` beginnt, nicht nur `--hard` | Verschärfung und Lockerung zugleich, beide gemessen. *Verschärfung:* Die Abbildung verlangt, dass die Präfixform ein Präfix der wörtlichen Form ist, und weist sie sonst zurück. *Lockerung:* Eine andere Schreibweise desselben Befehls beginnt nicht mit der Zeichenfolge – `git -C <pfad> reset` ist nicht erfasst. Die Grenze steht in Matrixzeile B6 |
 
 ## 5. Bekannte Abweichungen im Verhalten
 
-- **`model_decision` lädt hier unbedingt.** Bei `devin-desktop` laden `10-privacy-security` und `15-development-rules` nur bei Relevanz. Dieser Client kennt für Regeldateien keine modellentschiedene Bedingung, nur die Bindung an Dateimuster; beide Texte sind deshalb stets geladen. Für die Regelwirkung ist das eine **Verschärfung**; für den Kontext bedeutet es eine ständige Belegung durch `CLAUDE.md` und die vier unbedingten Regeltexte einer frischen Installation. Least Context ist ein Prinzip zur Ergebnisqualität, keine Sicherheitszusage – die Abweichung ist deshalb vertretbar, wächst aber mit jedem unbedingt geladenen Pack. Der Validator warnt ab 40.000 Zeichen.
-
-- **Eine pfadgebundene Regel lädt beim Lesen einer passenden Datei, nicht bei jedem Werkzeugaufruf.** Ein Technology Pack steht damit nicht schon zu Beginn der Aufgabe im Kontext, sondern erst nach der ersten Berührung einer Datei seiner Technologie. Für Regeln, die vorher gelten müssen, ist `paths` ungeeignet; sie bleiben unbedingt. Nach einer Verdichtung des Kontexts lädt eine pfadgebundene Regel erst wieder, wenn erneut eine passende Datei gelesen wird.
+- **`model_decision` lädt hier unbedingt.** Dieser Client kennt für Regeldateien nur die Bindung an Dateimuster. `10-privacy-security` und `15-development-rules`, die bei `devin-desktop` nur bei Relevanz laden, stehen hier deshalb stets im Kontext. Für die Regelwirkung ist das eine Verschärfung, für den Kontext eine ständige Belegung, die mit jedem unbedingt geladenen Pack wächst. Der Validator warnt ab 40.000 Zeichen.
 
-- **Ein Glob-Muster kann still ins Leere greifen.** Ein `[`, das sich nicht als Klammerausdruck lesen lässt (`photos [2024/**`), macht das Muster ungültig: Es trifft keine Datei, während die übrigen Muster derselben Regel weiterwirken. Die `paths`-Liste einer Regel teilt sich außerdem ein Budget von 1.000 expandierten Mustern und 4 MiB; ein Muster darüber wird unexpandiert verwendet und trifft dann ebenfalls nichts. Beides ist beim Schreiben eines Technology Packs zu beachten – die Regel meldet ihr eigenes Nichtgreifen nicht.
+- **Eine pfadgebundene Regel lädt erst, wenn eine passende Datei gelesen wird** – nicht zu Beginn der Aufgabe und nach einer Verdichtung des Kontexts erst beim nächsten Lesen. Regeln, die vorher gelten müssen, bleiben unbedingt.
 
-- **Regeldateien sind nutzerlokal ausschließbar – eine Lücke in B9.** `claudeMdExcludes` in `.claude/settings.local.json` nimmt Anweisungs- und Regeldateien über ein Glob-Muster vom Laden aus; die Listen aller Ebenen werden zusammengeführt. **Gemessen am 2026-09-25 mit Gegenlauf** (D-397): Derselbe Eintrag wirkt aus der nutzerlokalen Datei wie aus der Berechtigungsdatei – ohne Eintrag lud die Sitzung die `CLAUDE.md` des Projekts und die eines Elternverzeichnisses, mit ihm in beiden Dateien nur die des Projekts. Das ist eine **Lockerung** und damit nach der Prioritätshierarchie unzulässig, technisch aber nicht verhindert. Der KI-Client selbst kann die Datei nicht schreiben – `Edit(.claude/**)` steht in `deny` –, ein Mensch schon. Nur verwaltete Einstellungen sind gegen Ausschluss geschützt.
+- **Ein Glob-Muster kann still ins Leere greifen.** Ein `[`, das kein Klammerausdruck ist (`photos [2024/**`), macht das Muster ungültig; die übrigen Muster der Regel wirken weiter. Die `paths`-Liste einer Regel teilt sich ein Budget von 1.000 expandierten Mustern und 4 MiB; ein Muster darüber trifft ebenfalls nichts. Die Regel meldet ihr Nichtgreifen nicht – beim Schreiben eines Technology Packs beachten.
 
-- **Der Schutz-Hook läuft hier fail-closed** (bei `devin-desktop` ebenfalls). Für diesen Client ist das Blockierverhalten über den Exit-Code dokumentiert und in einer Installation beobachtet (WN-5), das Eingabeschema damit bestätigt. Das Manifest führt deshalb `hook_fail_closed: true`, und die Abbildung hängt dem Kommando des durchsetzenden Hooks `--fail-closed` an: Eine Werkzeugeingabe, die der Hook nicht als JSON lesen kann, wird blockiert, statt ungeprüft durchzulaufen.
+- **Regeldateien sind nutzerlokal ausschließbar – eine Lücke in B9.** `claudeMdExcludes` in `.claude/settings.local.json` nimmt Anweisungs- und Regeldateien per Glob-Muster vom Laden aus; die Listen aller Ebenen werden zusammengeführt. Gemessen am 2026-09-25 mit Gegenlauf: Der Eintrag wirkt aus der nutzerlokalen Datei wie aus der Berechtigungsdatei. Das ist eine Lockerung, nach der Prioritätshierarchie unzulässig, technisch aber nicht verhindert. Der KI-Client kann die Datei nicht schreiben (`Edit(.claude/**)` steht in `deny`), ein Mensch schon. Nur verwaltete Einstellungen schützen davor.
 
-  **Der Schalter steht im Kommando, nicht in `env`** (D-31). Eine Umgebungsvariable hinge die Sperre an eine zweite, für kein Pack belegte Clientzusage – dass der Client die Variable an den Hook-Prozess weiterreicht. Das Argument steht in derselben Konfiguration, die der Client ohnehin ausführt: Läuft der Hook, kommt es an. Die Umgebungsvariable `FW_HOOK_FAIL_CLOSED` wirkt zusätzlich und ist der Weg, fail-closed ohne Neuinstallation zu erproben.
+- **Der Schutz-Hook läuft fail-closed.** Das Blockierverhalten über den Exit-Code ist dokumentiert und in einer Installation beobachtet. Das Manifest führt `hook_fail_closed: true`, und die Abbildung hängt dem Kommando des durchsetzenden Hooks `--fail-closed` an: Eine Werkzeugeingabe, die der Hook nicht als JSON lesen kann, wird blockiert.
 
-  **Beim Release-Wechsel von Hand nachzuziehen.** Weil die Hooks hier in der Berechtigungsdatei und damit in der Saat liegen, erreicht das Argument eine bestehende Installation nicht über `install.py --update`. Prüfung 17 meldet das als Fehler und nennt den Weg – die Pflicht ist damit sichtbar, nicht stillschweigend.
+  Der Schalter steht im Kommando, nicht in `env`, weil nicht belegt ist, dass der Client Umgebungsvariablen an den Hook-Prozess weiterreicht. `FW_HOOK_FAIL_CLOSED` wirkt zusätzlich und erprobt fail-closed ohne Neuinstallation.
 
-- **Die Berechtigungsdatei trägt hier auch die Hooks.** Weil dieser Client keine eigene Hook-Datei kennt, stehen die Hooks in derselben Datei – und die ist Saat, gehört nach der Erstinstallation also dem Projekt und wird von `install.py --update` nie überschrieben. Eine Änderung an den Hooks des Kerns erreicht ein bestehendes Projekt dieses Packs deshalb nicht von selbst; bei `devin-desktop` mit eigener Hook-Datei tut sie es. Beim Release-Wechsel ist das hier ausdrücklich zu prüfen.
+- **Die Berechtigungsdatei trägt hier auch die Hooks.** Dieser Client kennt keine eigene Hook-Datei. Die Berechtigungsdatei ist Saat: Sie gehört nach der Erstinstallation dem Projekt, und `install.py --update` überschreibt sie nie. Eine Änderung an den Hooks des Kerns – auch das Argument `--fail-closed` – erreicht ein bestehendes Projekt deshalb nicht von selbst; Prüfung 17 meldet sie als Fehler und nennt den Weg. Beim Release-Wechsel von Hand prüfen.
 
-- **Das Suchwerkzeug führt Punktdateien nicht auf.** Gemessen am 2026-09-12 (ERH-12, `.koolie/core/tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`): Zwei Muster – eines ohne und eines mit Verzeichnisdurchlauf – meldeten `No files found` für eine Datei, die im Verzeichnis lag und im selben Lauf über einen anderen Weg lesbar war; ihr Inhalt steht in drei späteren Läufen desselben Protokolls. **Das ist kein stiller Abbruch:** Das Werkzeug hat gearbeitet und ein falsches Ergebnis geliefert.
-
-  **Folge für Nachweise.** Ein Abwesenheitsnachweis über dieses Werkzeug ist für Punktdateien keiner. Nummer 7 des Testkatalogs verlangt dafür eine Anwesenheitsprobe desselben Gegenstandstyps – eine zweite Punktdatei, die gefunden werden **muss**.
+- **Das Suchwerkzeug führt Punktdateien nicht auf.** Gemessen am 2026-09-12 (`.koolie/core/tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`): Zwei Muster meldeten `No files found` für eine Datei, die im Verzeichnis lag und im selben Lauf anders lesbar war. Ein Abwesenheitsnachweis über dieses Werkzeug ist für Punktdateien deshalb keiner; Nummer 7 des Testkatalogs verlangt eine Anwesenheitsprobe desselben Gegenstandstyps.
 
 ## 6. Beobachtung während der Erstellung
 
-Beim Anlegen der Skills unter `.claude/skills/` hat die Sitzung, in der dieses Pack entstand, die zwölf Skills **selbsttätig erkannt und zur Verfügung gestellt**. Das belegt S1 über die Dokumentationslage hinaus.
-
-Dieselbe Beobachtung deckte einen Konvertierungsfehler auf: Die Skills erschienen zunächst mit einer Beschreibung, die aus dem Dateikörper statt aus dem Frontmatter stammte. Ursache war ein Rest der Devin-Frontmatter-Felder, der beim Umschreiben stehen geblieben war. Der Fehler wäre bei einer rein statischen Prüfung nicht aufgefallen – die Konvertierung prüft seitdem nach dem Umschreiben, dass nur dokumentierte Felder übrig sind.
+Beim Anlegen der Skills unter `.claude/skills/` hat die Sitzung, in der dieses Pack entstand, die Skills selbsttätig erkannt und angeboten. Das stützt S1 über die Dokumentation hinaus, ist aber keine Belegprüfung im Sinne des Testkatalogs.
 
-Das ist keine Belegprüfung im Sinne des Testkatalogs und ersetzt Roadmap-AP2 nicht.
+Die Konvertierung prüft nach dem Umschreiben, dass im Frontmatter nur Felder stehen, die dieser Client dokumentiert. Ein fremdes Feld lässt die Beschreibung sonst aus dem Dateikörper statt aus dem Frontmatter erscheinen.
 
 ## 7. Installation und Prüfung
 
@@ -222,39 +212,34 @@ Aus dem entpackten Archiv – über den Starter `install.cmd` (Windows) beziehun
 python .koolie/core/install.py --target <projekt> --client claude-code
 ```
 
-Ohne `--client` gilt bei einer Erstinstallation das Standardpack `devin-desktop`; die Angabe ist für dieses Pack also nötig. Ein vorhandenes Projekt hebt `--update`. Liegt der Kern bereits unter `.koolie/core/` im Projekt, installiert der klassische Weg aus der Projektwurzel; danach prüft der Validator die Installation:
+Ohne `--client` gilt bei einer Erstinstallation das Standardpack `devin-desktop`; für dieses Pack ist die Angabe also nötig. `--update` hebt ein vorhandenes Projekt. Liegt der Kern schon unter `.koolie/core/` im Projekt, installiert der Aufruf aus der Projektwurzel; danach prüft der Validator:
 
 ```text
 python .koolie/core/install.py --client claude-code
 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.
+Vor der ersten produktiven Nutzung die Basistests des Testkatalogs (`.koolie/core/tests/TEST_CATALOG.md`, Kennzeichnung „Basis") gegen diesen Client fahren und protokollieren.
 
 ### Pfadregeln nur für `Read` und `Edit` (AP2-CC-02)
 
-Der Client wertet Pfadregeln ausschließlich für `Read` und `Edit` aus: Eine Pfadregel für
-`Write`, `NotebookEdit`, `Glob` oder `MultiEdit` wird angenommen, nie konsultiert und beim
-Sitzungsstart als Warnung gemeldet. Die Abbildung bildet deshalb `write` auf `Edit` ab und
-`search` auf nichts (`CR-2026-016`, D-26). Der Validator meldet eine Pfadregel für ein Werkzeug
-ohne Pfadauswertung als Fehler (`permission_path_tools` im Manifest).
+Der Client wertet Pfadregeln nur für `Read` und `Edit` aus. Eine Pfadregel für `Write`, `NotebookEdit`, `Glob` oder `MultiEdit` wird angenommen, nie konsultiert und beim Sitzungsstart als Warnung gemeldet. Die Abbildung bildet deshalb `write` auf `Edit` ab und `search` auf nichts; der Validator meldet eine Pfadregel für ein Werkzeug ohne Pfadauswertung als Fehler (`permission_path_tools` im Manifest).
 
-Für eine Regel **ohne** Pfad gilt die Trennung weiterhin: Eine Verweigerung des bloßen
-Werkzeugnamens `Write` wirkt überall.
+Eine Regel ohne Pfad wirkt dagegen überall: Eine Verweigerung des bloßen Werkzeugnamens `Write` sperrt das Werkzeug.
 
 ## 8. Anweisungs- und Konfigurationsquellen außerhalb des Projekts
 
-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).
+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.
 
-**Erhebungsstand: 2026-09-11**, Clientversion 2.1.268, erhoben in einer frischen Installation in einem Temporärverzeichnis und durch Auslesen der Schlüssel der nutzerglobalen Einstellungsdatei (ohne Werte); `tests/protocols/2026-09-11-erhebungen-K21-K26.md`. Ergänzt am 2026-09-12 (Skill-Ablage, `tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`), am 2026-09-18 gegen 2.1.275 (`FW-AK-01`, Abschnitt 8a und Zeilen S4, S5, X1) und am 2026-09-29 gegen 2.1.284 (Connectoren des Kontos, `tests/protocols/2026-09-29-schutzschicht.md`, D-489).
+**Erhebungsstand:** 2026-09-11 mit 2.1.268 in einer frischen Installation, dazu die Schlüssel (ohne Werte) der nutzerglobalen Einstellungsdatei (`tests/protocols/2026-09-11-erhebungen-K21-K26.md`). Ergänzt am 2026-09-12 (Skill-Ablage, `tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`), am 2026-09-18 gegen 2.1.275 (`FW-AK-01`; Abschnitt 8a, Zeilen S4, S5, X1) und am 2026-09-29 gegen 2.1.284 (Connectoren des Kontos, `tests/protocols/2026-09-29-schutzschicht.md`).
 
 ### 8.1 Anweisungsquellen
 
 | Quelle | Ladebedingung | Belegstatus | Maßnahme des Frameworks |
 |---|---|---|---|
-| `<Elternverzeichnis>\CLAUDE.md` | lädt zusätzlich zur Anweisungsdatei des Projekts, in jedes darunterliegende Projekt | **Gemessen** (K-22): Ohne Einstellung lud die Sitzung **zwei** `CLAUDE.md` – die des Projekts und eine aus einem Elternverzeichnis, die mit dem Projekt nichts zu tun hat. Die Quelle ist nicht an das Benutzerprofil gebunden; ein Elternverzeichnis genügt | keine Vorgabe (R6). `claudeMdExcludes` in der Berechtigungsdatei nimmt sie aus, wenn ein Projekt das will – **empfohlen, nicht ausgeliefert**; derselbe Eintrag wirkt auch nutzerlokal (Abschnitt 5, gemessen, D-397) |
+| `<Elternverzeichnis>\CLAUDE.md` | lädt zusätzlich zur Anweisungsdatei des Projekts, in jedes darunterliegende Projekt | **Gemessen**: Ohne Einstellung lud die Sitzung **zwei** `CLAUDE.md` – die des Projekts und eine aus einem Elternverzeichnis, die mit dem Projekt nichts zu tun hat. Die Quelle ist nicht an das Benutzerprofil gebunden; ein Elternverzeichnis genügt | keine Vorgabe (R6). `claudeMdExcludes` in der Berechtigungsdatei nimmt sie aus, wenn ein Projekt das will – **empfohlen, nicht ausgeliefert**; derselbe Eintrag wirkt auch nutzerlokal (Abschnitt 5, gemessen) |
 | `~\.claude\CLAUDE.md` | laut Herstellerdokumentation nutzerglobale Anweisungsdatei | **Nicht belegt.** Die Datei existiert auf der Messstation nicht; ob diese Ablage zusätzlich lädt, ist damit unbekannt – nicht verneint | keine |
-| `~\.claude\skills\` | Skill-Ablage im Benutzerprofil, lädt in jedes Projekt mit | **Gemessen am 2026-09-12** (S5): 67 Skills standen in einer Sitzung, deren Projekt keinen davon enthält. Seit 2.1.275 tritt die Kontoquelle `~/.claude/skills/synced/` hinzu, standardmäßig an (`FW-AK-01`, `K-63`) | keine; `--list-skills` sieht diese Ablagen nicht (S5). Die Kontoquelle lässt sich aus der ausgelieferten Datei nicht abschalten (X1, Abschnitt 8a) |
+| `~\.claude\skills\` | Skill-Ablage im Benutzerprofil, lädt in jedes Projekt mit | **Gemessen am 2026-09-12** (S5): 67 Skills standen in einer Sitzung, deren Projekt keinen davon enthält. Seit 2.1.275 tritt die Kontoquelle `~/.claude/skills/synced/` hinzu, standardmäßig an (`FW-AK-01`) | keine; `--list-skills` sieht diese Ablagen nicht (S5). Die Kontoquelle lässt sich aus der ausgelieferten Datei nicht abschalten (X1, Abschnitt 8a) |
 
 ### 8.2 Konfigurationsquellen
 
@@ -264,86 +249,44 @@ Berechtigungen, Hooks und Einstellungen außerhalb des Repositoriums betreffen g
 |---|---|---|
 | `~\.claude\settings.json` (nutzerglobal) | führt **Berechtigungen und Hooks**: am 2026-09-11 sechs `allow`-Regeln sowie `SessionStart`-, `PreToolUse`- und `PostToolUse`-Hooks | **Gemessen** (ERH-07), Schlüssel ausgelesen, Werte nicht. Ein Hook von dort läuft vor jedem Werkzeugaufruf – dieselbe Stelle, an der die zweite Linie des Frameworks steht |
 | `<Elternverzeichnis>\.claude\settings.local.json` | nutzerlokale Einstellungsdatei **über** dem Projekt | **Gemessen** (ERH-07) |
-| Connectoren des claude.ai-Kontos | MCP-Server, die im Konto des Anwenders verbunden sind, stehen mit ihren Werkzeugen – darunter schreibende – in **jeder** Sitzung, auch im Messbaum; sie verbinden sich nebenläufig nach dem Start | **Gemessen am 2026-09-29** (2.1.284, ohne Modellaufruf, `K-191`, D-489): In der Startmeldung stehen die Server mit der Quelle `claudeai`. **Abschalten aus dem Projekt:** `mcp__claude_ai_*` in `permissions.deny` nimmt alle ihre Werkzeuge aus der Sitzung, ein projekteigener Server bleibt – **empfohlen, nicht ausgeliefert**, weil `deny` auch eine Freigabe nach Overlay 13.2 schlüge. `env` in der Projektdatei schaltet sie **nicht** ab, mit und ohne Vertrauen; die Umgebungsvariable `ENABLE_CLAUDEAI_MCP_SERVERS=false` beim Start tut es. Die Rückfrage `mcp__*` fängt ihre Aufrufe auch im Modus `bypassPermissions` (Druckmodus, gemessen). `install.py --probe` warnt, solange sie in der Sitzung stehen (M1) |
+| Connectoren des claude.ai-Kontos | MCP-Server, die im Konto des Anwenders verbunden sind, stehen mit ihren Werkzeugen – darunter schreibende – in **jeder** Sitzung, auch im Messbaum; sie verbinden sich nebenläufig nach dem Start | **Gemessen am 2026-09-29** (2.1.284, ohne Modellaufruf): In der Startmeldung stehen die Server mit der Quelle `claudeai`. **Abschalten aus dem Projekt:** `mcp__claude_ai_*` in `permissions.deny` nimmt alle ihre Werkzeuge aus der Sitzung, ein projekteigener Server bleibt – **empfohlen, nicht ausgeliefert**, weil `deny` auch eine Freigabe nach Overlay 13.2 schlüge. `env` in der Projektdatei schaltet sie **nicht** ab, mit und ohne Vertrauen; die Umgebungsvariable `ENABLE_CLAUDEAI_MCP_SERVERS=false` beim Start tut es. Die Rückfrage `mcp__*` fängt ihre Aufrufe auch im Modus `bypassPermissions` (Druckmodus, gemessen). `install.py --probe` warnt, solange sie in der Sitzung stehen (M1) |
 | Vertrauen in das Verzeichnis (`~\.claude.json`) | Ohne Vertrauen werden die `allow`-Regeln des Projekts ignoriert – der Client meldet es beim Sitzungsstart | **Gemessen** (`AP2-CC-14`, ERH-06): „Ignoring 6 permissions.allow entries from .claude/settings.json: this workspace has not been trusted." `deny`- und `ask`-Regeln sowie die Regeltexte bleiben davon unberührt |
 
 ### 8.3 Was dieser Abschnitt nicht leistet
 
-**Eine Auskunft ist keine Schranke.** Dieser Abschnitt macht die Quellen sichtbar; er verhindert sie nicht. Das Framework liest das Benutzerprofil nicht und sperrt dort nichts.
+**Eine Auskunft ist keine Schranke.** Dieser Abschnitt macht die Quellen sichtbar, verhindert sie aber nicht; das Framework liest das Benutzerprofil nicht und sperrt dort nichts.
 
-**Ein Abwesenheitsbeleg altert.** Der Erhebungsstand oben ist am Tag der nächsten Clientversion eine Aussage über die Vergangenheit. Prüfung 19 prüft die **Anwesenheit** dieser Auskunft, nicht ihre Richtigkeit.
+**Ein Abwesenheitsbeleg altert.** Der Erhebungsstand gilt bis zur nächsten Clientversion. Prüfung 19 prüft, dass diese Auskunft da ist, nicht, dass sie stimmt.
 
-**Die Liste ist nicht vollständig, sie ist belegt.** Eine der drei Anweisungsquellen oben trägt ausdrücklich „nicht belegt". Das ist ein Ergebnis, kein fehlendes Ergebnis – und es ist der Unterschied zu einem Pack, das schweigt.
+**Die Liste ist belegt, nicht vollständig.** Eine Anweisungsquelle steht ausdrücklich auf „nicht belegt" – ein Ergebnis, keine Lücke.
 
-**Das Entscheidungsprotokoll des Schutz-Hooks ist kein Nachweis gegen den Agenten** (`K-200`, D-487). Es liegt unter `.git/`, der Agent kann es über die Shell ändern, und eine Eingabe, die der Hook nicht lesen kann, hinterlässt keine Zeile. Es zeigt, was der Hook entschieden hat, nicht, was er nicht gesehen hat.
+**Das Entscheidungsprotokoll des Schutz-Hooks ist kein Nachweis gegen den Agenten.** Es liegt unter `.git/`, der Agent kann es über die Shell ändern, und eine Eingabe, die der Hook nicht lesen kann, hinterlässt keine Zeile.
 
 ### 8a. Die selbstgeschriebene Anweisungsquelle des Clients – abgeschaltet
 
-**Gefunden von `FW-AK-01` am 2026-09-18.** Dieser Client führt neben der
-Wurzel-Anweisungsdatei und der Regelablage eine **dritte** Anweisungsquelle, die er
-sich selbst schreibt: Er legt Notizen unter `~/.claude/projects/<projekt>/memory/`
-ab, und deren Index `MEMORY.md` wird mit den ersten 200 Zeilen beziehungsweise 25 KB
-**in jede Sitzung** geladen. Die Quelle sagt wörtlich *„Auto memory is on by
-default."* (`QC-1`).
-
-**Das Framework schaltet sie ab.** Die erzeugte Berechtigungsdatei trägt
-`autoMemoryEnabled: false` auf ihrer **obersten** Ebene (D-154, deklariert im
-Manifest unter `settings_extra`, geprüft von Prüfung 54). Der Grund ist kein
-Geschmack: Ein Anweisungstext, der in jeder Sitzung steht, gehört in die
-Prioritätshierarchie – er ist sonst weder versioniert noch gegengezeichnet, der
-Validator sieht ihn nicht, und kein Review erreicht ihn.
-
-**Es ist ein Standard, keine Schranke.** `.claude/settings.local.json` hat höheren
-Vorrang; ein Projekt, das die Quelle braucht, holt sie dort zurück und weist die
-Abweichung aus – dieselbe Bauform wie bei D-10.
-
-**Reichweite, gemessen:** `install.py --update` führt
-`.claude/settings.json` unter *Projektdateien unberührt gelassen* – die Datei trägt
-Projektwerte und wird von einem Update nie überschrieben. **Der Schlüssel erreicht jede
-Erstinstallation und kein bestehendes Projekt.** Wer ein Projekt hebt, trägt die Zeile
-von Hand nach.
-
-**Der Gegenfall, der nicht geht:** Für die Kontoquelle der Skills
-(`syncClaudeAiSkills`) gibt es diesen Weg nicht. Die Herstellerdokumentation nimmt
-für diesen Schlüssel die versionierte Projektdatei ausdrücklich aus – *„a `false` in
-`.claude/settings.json` is ignored"*. **Damit hat das Framework für diesen einen
-Kanal keinen Ort, an dem seine Entscheidung ankommt**; es bleibt beim Benennen in
-`X1` und `S5` (`K-63`).
+Neben Wurzel-Anweisungsdatei und Regelablage führt dieser Client eine dritte Anweisungsquelle, die er selbst schreibt: Notizen unter `~/.claude/projects/<projekt>/memory/`, deren Index `MEMORY.md` mit den ersten 200 Zeilen beziehungsweise 25 KB in jede Sitzung geladen wird. *„Auto memory is on by default."* (`QC-1`, erhoben in `FW-AK-01` am 2026-09-18).
+
+**Das Framework schaltet sie ab:** Die erzeugte Berechtigungsdatei trägt auf oberster Ebene `autoMemoryEnabled: false` (im Manifest unter `settings_extra`, geprüft von Prüfung 54). Ein Anweisungstext, der in jeder Sitzung steht, gehört in die Prioritätshierarchie; diese Notizen sind weder versioniert noch geprüft.
+
+Es ist ein Standard, keine Schranke: `.claude/settings.local.json` hat Vorrang. Ein Projekt, das die Quelle braucht, schaltet sie dort ein und weist die Abweichung aus.
+
+**Reichweite:** `install.py --update` lässt `.claude/settings.json` unberührt, weil sie Projektwerte trägt. Der Schlüssel erreicht jede Erstinstallation, aber kein bestehendes Projekt; wer hebt, trägt ihn von Hand nach.
+
+Für die Kontoquelle der Skills (`syncClaudeAiSkills`) gibt es diesen Weg nicht: Die Herstellerdokumentation nimmt die versionierte Projektdatei für diesen Schlüssel aus – *„a `false` in `.claude/settings.json` is ignored"*. Das Framework kann diesen Kanal nur benennen (`X1`, `S5`).
 
 ### 8b. Die Attributionsvorgabe des Clients für Commits – abgeschaltet
 
-**Gefunden im Nachlauf von `1.14.1`** (`K-171`). Der Client gibt dem
-Modell von sich aus eine Vorgabe für Commits mit: einen Trailer `Co-Authored-By` mit
-einer Adresse des Herstellers, in Cloud- und Remote-Control-Sitzungen zusätzlich einen
-Trailer `Claude-Session` (`QC-7`). Das Modell übernahm sie in den Commit-Vorschlag des
-Skills `fw-change-small`, obwohl der Skill Q5 nennt – nicht in jedem Lauf. Q5 verlangt
-eine Nachricht, die das Warum beschreibt; der Vermerk der KI-Nutzung gehört in den
-Merge Request.
-
-**Das Framework schaltet sie ab.** Die erzeugte Berechtigungsdatei trägt auf ihrer
-obersten Ebene `"attribution": {"commit": "", "sessionUrl": false}` (D-433, deklariert
-im Manifest unter `settings_extra`, geprüft von Prüfung 54). `pr` bleibt unberührt: Die
-Zeile in der Beschreibung eines Merge Requests ist ein Vermerk an der Stelle, die Q5
-dafür vorsieht.
-
-🔴 **Die Objektform ist Absicht, nicht Umständlichkeit.** Die Kurzform
-`"attribution": false` kennt der Client erst ab 2.1.281, und ältere Stände **verwerfen
-die ganze Einstellungsdatei**, die sie enthält (`QC-7`) – mit allen Berechtigungen und
-Hooks. Die Zielspanne dieses Packs ist `2.1.x`.
-
-**Beobachtbar ohne Modellurteil:** Das Sitzungstranskript trägt eine Anlage vom Typ
-`remote_session_change` mit dem Feld `commit` – der Text, den der Client dem Modell als
-Attribution vorgibt. In allen 51 Läufen von `1.14.1` stand dort der Trailer; mit der
-Einstellung steht dort die leere Zeichenkette (D-433, gemessen im Nachlauf von
-`1.14.2`).
-
-**Es ist ein Standard, keine Schranke** – wie in 8a: `.claude/settings.local.json` und
-verwaltete Einstellungen haben Vorrang. Die Einstellung ist eine Anweisung an das
-Modell, keine Nachbearbeitung von `git commit`.
-
-**Reichweite:** wie in 8a – jede Erstinstallation, kein bestehendes Projekt. Seit
-`1.14.2` meldet `install.py --update` einen deklarierten Zusatzschlüssel, der in der
-vorhandenen Einstellungsdatei fehlt (D-434); nachtragen muss ihn weiter der Mensch.
+Der Client gibt dem Modell eine Vorgabe für Commits mit: einen Trailer `Co-Authored-By` mit einer Adresse des Herstellers, in Cloud- und Remote-Control-Sitzungen zusätzlich `Claude-Session` (`QC-7`). Das Modell übernahm sie in Commit-Vorschläge von `koolie-change-small`, obwohl der Skill Q5 nennt. Q5 verlangt eine Nachricht, die das Warum beschreibt; der Vermerk der KI-Nutzung gehört in den Merge Request.
+
+**Das Framework schaltet sie ab:** Die erzeugte Berechtigungsdatei trägt auf oberster Ebene `"attribution": {"commit": "", "sessionUrl": false}` (im Manifest unter `settings_extra`, geprüft von Prüfung 54). `pr` bleibt unberührt – die Zeile in der Beschreibung eines Merge Requests ist der Ort, den Q5 vorsieht.
+
+⚠️ Die Kurzform `"attribution": false` kennt der Client erst ab 2.1.281; ältere Stände verwerfen die ganze Einstellungsdatei mit allen Berechtigungen und Hooks (`QC-7`). Deshalb steht hier die Objektform – die Zielspanne ist `2.1.x`.
+
+Beobachtbar ohne Modellurteil: Das Sitzungstranskript trägt eine Anlage `remote_session_change` mit dem Feld `commit`, dem Text, den der Client als Attribution vorgibt. Mit der Einstellung steht dort die leere Zeichenkette.
+
+Es ist ein Standard, keine Schranke: `.claude/settings.local.json` und verwaltete Einstellungen haben Vorrang. Die Einstellung ist eine Anweisung an das Modell, keine Nachbearbeitung von `git commit`.
+
+**Reichweite:** wie in 8a. `install.py --update` meldet einen deklarierten Zusatzschlüssel, der in der vorhandenen Einstellungsdatei fehlt; nachtragen muss ihn der Mensch.
 
 ## 9. Änderungsverlauf
 
@@ -352,7 +295,7 @@ vorhandenen Einstellungsdatei fehlt (D-434); nachtragen muss ihn weiter der Mens
 | 0.22.0 | 2026-09-18 | **H3 ist gemessen – von `[DOK]` auf eine Messung mit benannter Grenze** (`CR-2026-091`, D-176). Die Statusmeldung des `SessionStart`-Hooks erreicht die Sitzung – ihre `additionalContext`-Zeichenkette steht wörtlich in der Mitschrift –, **und sie steuert**: Mit geschnittenem Regeltext blieb der Lauf mit Hook nur lesend und änderte ohne ihn eine Produktivzeile. Die Grenze steht in der Zeile: eine Verhaltensdifferenz, keine Zusage | `<FRAMEWORK_OWNER>` |
 | 0.23.0 | 2026-09-19 | 🔴 **Zeile S2 führte zwei Wege als einen, und für einen davon war sie falsch (`CR-2026-094`, D-187).** Der Aufruf mit Schrägstrich ist eine Slash-Befehls-Erweiterung ohne Werkzeugmeldung; die drei Grenzen gelten für den modellseitigen Aufruf, den die Erhebung vom 2026-09-14 gemessen hat. **Zeile S3 nennt seither, was in der Mitschrift steht** (D-188): `command_permissions` trägt genau die Werkzeuge aus `allowed-tools`, und zwei Läufe haben `Bash` aufgerufen, obwohl der Skill es sperrt (`K-73`) | `<FRAMEWORK_OWNER>` |
 | 0.24.0 | 2026-09-22 | 🟢 **Die Markerform ist abgeschafft; die Vorbemerkung nennt `BELEG OFFEN`** (`CR-2026-121`, D-291). 🔴 **Und der Belegstand dieses Packs war seit `0.62.0` falsch** (D-297): Er sagte *„Eine Zeile trägt einen VERIFY-Marker – R5"*, während **der Änderungsverlauf desselben Packs** die Auflösung dieses Markers seit Pack-Version `0.21.0` führt (D-158) und **keine Fundstelle die Form trug** – *die Zusage, deren Widerlegung im eigenen Dokument steht.* **Richtig ist: keine.** Zwei weitere Zahlen desselben Absatzes waren überholt: *„9 von 36"* für das Schwesterpack (richtig: 1) und der Satz, dort sei *„keine einzige Einstufung gegen eine Installation geprüft"* – seit `0.53.0` überholt, seit `0.86.0` grob falsch | `<FRAMEWORK_OWNER>` |
-| 0.24.3 | 2026-09-25 | Zeile M4 (Planungsmodus) ergänzt, auf die `fw-plan` und `fw-bugfix-prepare` für die Planablage verweisen: `[TEXTUELL]`, `BELEG OFFEN`; Summen und Belegstand nachgezogen (`CR-2026-147`, D-402, K-149) | `<FRAMEWORK_OWNER>` |
+| 0.24.3 | 2026-09-25 | Zeile M4 (Planungsmodus) ergänzt, auf die `koolie-plan` und `koolie-bugfix-prepare` für die Planablage verweisen: `[TEXTUELL]`, `BELEG OFFEN`; Summen und Belegstand nachgezogen (`CR-2026-147`, D-402, K-149) | `<FRAMEWORK_OWNER>` |
 | 0.24.4 | 2026-09-26 | Vorbemerkung des B-Blocks: **die Startort-Bedingung**, gemessen mit Clientversion 2.1.283 – im Unterverzeichnis mit eigenem Repositorium lädt die Wurzel-Anweisung, Berechtigungen und Hooks nicht; eine eigene Installation dort trägt (`CR-2026-148`, D-408) | `<FRAMEWORK_OWNER>` |
 | 0.24.5 | 2026-09-26 | Abschnitt 8b: **die Attributionsvorgabe des Clients für Commits abgeschaltet** – `attribution` in Objektform auf der obersten Ebene der Einstellungsdatei, weil die Kurzform `false` ältere Stände der Zielspanne die ganze Datei verwerfen lässt; Quelle `QC-7` (`CR-2026-153`, D-433, K-171) | `<FRAMEWORK_OWNER>` |
 | 0.14.0 | 2026-09-13 | **S3 ist zurückgewonnen – von `[NICHT ABBILDBAR]` auf `[TECHNISCH]` mit drei benannten Grenzen** (`CR-2026-057`, D-64 bis D-66). `disallowed-tools` ist **gemessen** eine echte Werkzeugsperre je Skill und schlägt sogar eine ausdrückliche `allow`-Regel; `permissions.deny` der Quelle wird darauf abgebildet, die Werkzeugnamen kommen aus `hook_tools`. Die drei Grenzen – Turnbereich, Aufzählung, keine Argumentmuster – stehen in der Zeile, im Arbeitsmodell und in der Grenzfalltabelle. **Ein Argumentmuster wirkt lautlos gar nicht**; Prüfung 33 weist es ab | `<FRAMEWORK_OWNER>` |
@@ -381,3 +324,4 @@ vorhandenen Einstellungsdatei fehlt (D-434); nachtragen muss ihn weiter der Mens
 | 0.26.3 | 2026-10-01 | **Die Modusbindung M3 bis M5 ist gemessen** (`CR-2026-169`, D-523, `K-201`). Zeile M4: je ein Lauf M3, M4, M5 und ein Kontrolllauf ohne Bindung; Zeile S3: die Sperre eines Skills gilt nur in seinem Turn (D-525) | `<FRAMEWORK_OWNER>` |
 | 0.26.4 | 2026-10-01 | **Ein lesender Befehl in keinem Korb ist gemessen** (`CR-2026-172`, D-537, `K-208`). Zeile B2: ohne Eintrag lief `git ls-files` im Druckmodus ohne Rückfrage, mit `deny` wurde er abgewiesen – der Client gibt lesende Befehle selbst frei | `<FRAMEWORK_OWNER>` |
 | 0.26.1 | 2026-09-30 | **Die POSIX-Schreibweise und die Schreibweise der Muster sind gemessen** (`CR-2026-163`, D-491, D-492, `K-92`, `K-96`). Zeile B3: Die Berechtigungsschicht dieses Clients unterscheidet unter Windows nicht zwischen Groß- und Kleinschreibung. Zeile H4: Der Hook löst `/c/…` in beiden Lesarten auf; der Client liest sie als `C:\…` | `<FRAMEWORK_OWNER>` |
+| 0.27.0 | 2026-10-02 | Sprachlich überarbeitet; Zusagen, Einstufungen und Belege unverändert | `<FRAMEWORK_OWNER>` |