@renoxar/koolie 1.25.0

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

@@ -0,0 +1,383 @@
+# Client Pack `claude-code`
+
+| Attribut | Wert |
+|---|---|
+| Modul-ID | `CP-CC` |
+| Ebene | keine – Abbildungsschicht |
+| Version | 0.26.4 |
+| 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.
+>
+> **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).
+
+## 1. Pfadabbildung
+
+Maschinenlesbar in `manifest.json`; diese Tabelle ist die menschenlesbare Fassung.
+
+| Rolle des Artefakts | Pfad bei diesem Client | Belegstatus |
+|---|---|---|
+| Wurzel-Anweisungsdatei | `CLAUDE.md` | `[DOK]` |
+| Regeldateien | `.claude/rules/*.md`; der Client findet sie selbst, auch in Unterverzeichnissen. Ohne `paths`-Frontmatter unbedingt geladen, mit `paths` bei passenden Dateien – **kein Import nötig**, siehe Abschnitt 1b | [DOK] `docs/en/memory` (AP2, Clientversion 2.1.267, `tests/protocols/2026-09-10-AP2-claude-code.md`) |
+| Skills | `.claude/skills/<name>/SKILL.md` | `[DOK]` |
+| 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) |
+| 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.
+
+| 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 |
+| `fetch` | `WebFetch`, `WebSearch` | zwei Werkzeuge, beide ohne Muster |
+| `mcp` | `mcp__*` | ohne Muster |
+
+| Weitere Eigenschaft | Wert |
+|---|---|
+| Name ohne Verzeichnisanteil | mit Wurzelangabe (`./.env`) |
+| Zusätzliche Schlüssel | `defaultMode: default` |
+| 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.
+
+## 1b. Semantikabbildung der Ladebedingungen
+
+Die Regeltexte liegen werkzeugneutral im Kern (`.koolie/core/framework/runtime/rules/`, dazu die Regelvorlagen und die Laufzeitfassungen aktivierter Packs) und tragen dort einen **Ladetrigger**. Dieser Client kennt für Regeldateien genau eine Bedingung: die Bindung an Dateimuster über das Frontmatter-Feld `paths`. Die Abbildung steht maschinenlesbar im `manifest.json` unter `rule_triggers`; diese Tabelle ist die menschenlesbare Fassung.
+
+| Ladetrigger der Kernquelle | Fassung bei diesem Client | Ladeverhalten | Bewertung |
+|---|---|---|---|
+| `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 |
+
+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.
+
+`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.
+
+## 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.
+
+**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).
+
+### 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`) |
+| 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 |
+
+### 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`) |
+
+### 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.
+>
+> **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.
+
+| 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) |
+
+### 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 |
+| 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 |
+
+### 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`** |
+
+### 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`) |
+| 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) |
+
+### 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) |
+| 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).
+
+| 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.
+
+**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).
+
+**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.
+
+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.
+
+**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“).
+
+## 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).
+
+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).
+
+| 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`) |
+
+## 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.
+
+- **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.
+
+- **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.
+
+- **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.
+
+  **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.
+
+  **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.
+
+- **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.
+
+- **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**.
+
+## 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.
+
+Das ist keine Belegprüfung im Sinne des Testkatalogs und ersetzt Roadmap-AP2 nicht.
+
+## 7. Installation und Prüfung
+
+Aus dem entpackten Archiv – über den Starter `install.cmd` (Windows) beziehungsweise `install.command` (macOS) oder direkt:
+
+```text
+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:
+
+```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.
+
+### 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).
+
+Für eine Regel **ohne** Pfad gilt die Trennung weiterhin: Eine Verweigerung des bloßen
+Werkzeugnamens `Write` wirkt überall.
+
+## 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).
+
+**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).
+
+### 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) |
+| `~\.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) |
+
+### 8.2 Konfigurationsquellen
+
+Berechtigungen, Hooks und Einstellungen außerhalb des Repositoriums betreffen genau die Linien, auf denen B1 bis B6 stehen.
+
+| Quelle | Wirkung | Belegstatus |
+|---|---|---|
+| `~\.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) |
+| 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.
+
+**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.
+
+**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.
+
+**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.
+
+### 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`).
+
+### 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.
+
+## 9. Änderungsverlauf
+
+| Version | Datum | Änderung | Autor (Rolle) |
+|---|---|---|---|
+| 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.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>` |
+| 0.15.0 | 2026-09-13 | **Der Unteragent ist erhoben – drei Zeilen bekommen Belege, und zwei davon standen acht Releases auf reiner Dokumentation (`CR-2026-058`, D-67 bis D-70).** **A1** ist gemessen: Ein Profil mit `tools: Read, Grep, Glob` hatte kein Schreibwerkzeug, und `permission_denials` blieb leer – es ist eine **Entfernung aus dem Werkzeugvorrat**, keine Verweigerung. Der Teilsatz zum Startabbruch bleibt ausdrücklich `[DOK]`. **S3** trägt jetzt seine **Reichweite**: Die Sperre gilt auch für einen Unteragenten, den der Skill startet – gemessen mit Kontrolllauf –, und Grenze 2 reicht mit: Mit gesperrtem `Write, Edit` schrieb der Unteragent über `Bash`. **H2** trägt die Reichweite des Hooks: Er erfasst und **blockiert** die Aufrufe eines Unteragenten, auch mit dem benannten Matcher, den `clientmap.py` erzeugt. Neu im Manifest: `agent_start_tools` – das Startwerkzeug stand in keiner Werkzeugliste, obwohl beide Schreibweisen (`Agent`, `Task`) in der Sperre wirken. **Zwei überholte Angaben im Belegstand berichtigt** (`CR-2026-058`, Befund 6) | `<FRAMEWORK_OWNER>` |
+| 0.16.0 | 2026-09-13 | **Die drei Lücken aus 0.36.0 sind geschlossen (`CR-2026-059`, D-72 und D-73).** **S3:** Die Sperre gilt auch für einen Unteragenten mit `run_in_background: true` und reicht **mindestens zwei Ebenen tief**; **bei Widerspruch gewinnt die restriktivere Liste** – ein Profil, das `Write` ausdrücklich nennt, bekam es unter einem sperrenden Skill nicht. Dazu eine **Beobachtung zum Wortlaut des Clients**, der seine eigene Reichweite überzeichnet („for this session", gemessen ist der Turn). **A1:** Ein Profil mit `tools`-Liste hat **kein Startwerkzeug** und kann sich nicht über eine zweite Ebene erweitern – ohne diesen Befund wäre die Zusage „rein lesend" aushebelbar; **Prüfung 35** hält fest, dass das so bleibt | `<FRAMEWORK_OWNER>` |
+| 0.17.0 | 2026-09-14 | **S2 bekommt ihre drei gemessenen Grenzen** (`CR-2026-063`, D-81 bis D-83). Die Zeile stand seit dem ersten Release unverändert auf `[TECHNISCH]` `[DOK]` und nannte keine einzige – während die Nachbarzeile S3 seit 0.14.0 drei trägt. **Der Skillaufruf ist ein eigener Werkzeugaufruf und war in der ausgelieferten Berechtigungsdatei in keinem Korb vertreten**; er lief in die Rückfrage und im rückfragefreien Betrieb in die Abweisung. Neu im Manifest: `permission_tools.skill` und `permission_name_tools`. Die Datei führt jetzt zwölf `allow`-Regeln, eine je Skill des Kerns – **wörtlich, weil ein Präfixmuster gemessen nichts freigibt** | `<FRAMEWORK_OWNER>` |
+| 0.1.0 | 2026-09-10 | angelegt (`CR-2026-004`) | `<FRAMEWORK_OWNER>` |
+| 0.2.0 | 2026-09-10 | Berechtigungen und Hooks aus dem Pack in den Kern; Semantikabbildung ergänzt (`CR-2026-008`) | `<FRAMEWORK_OWNER>` |
+| 0.3.0 | 2026-09-10 | Overlay-Laufzeitregel und die beiden Vorlagen in den Kern; Pack umfasst vier Dateien (`CR-2026-010`) | `<FRAMEWORK_OWNER>` |
+| 0.4.0 | 2026-09-10 | **Erste Validierung gegen eine reale Installation und die Herstellerdokumentation (AP2, Clientversion 2.1.267).** Alle zehn Pruefmarker abgearbeitet: sechs belegt, zwei als ueberholt gekennzeichnet (R2/R3, S4), einer als Abwesenheitsbeleg, einer um die dokumentierte Grenze der Praefixmuster ergaenzt. Abschnitt 7 nennt die 17 wirkungslosen Regeln der erzeugten Berechtigungsdatei. Protokoll: `tests/protocols/2026-09-10-AP2-claude-code.md` | `<FRAMEWORK_OWNER>` |
+| 0.5.0 | 2026-09-10 | **Drei Befunde aus AP2 behoben (`CR-2026-016`, D-26).** `triggers` wird nicht mehr ersatzlos verworfen, sondern auf `disable-model-invocation` abgebildet - die Zusage S4 gilt damit auch in der Installation. Pfadregeln werden nur noch fuer `Read` und `Edit` erzeugt: 18 wirkungslose Regeln entfallen, die Berechtigungsdatei schrumpft von 83 auf 65 Regeln. `install.py --client claude-code` gefolgt von `validate-framework.py` laeuft erstmals fehlerfrei | `<FRAMEWORK_OWNER>` |
+| 0.6.0 | 2026-09-10 | **R2 und R3 abgebildet (`CR-2026-017`, D-27).** Die Regelablage liegt in `.claude/rules/`; der Client laedt sie von sich aus, die `@`-Importe der Wurzel-Anweisung entfallen. Die Ladetrigger der Kernquelle werden abgebildet statt zu Kommentar zu werden: `glob` auf `paths`, `always_on` und `model_decision` auf unbedingtes Laden. Erstmals gerendert werden auch die Regelvorlagen und die Laufzeitfassungen aktivierter Role und Technology Packs - eine aktivierte Role-Pack-Regel war bei diesem Client bisher wirkungslos. Keine Einstufung steht mehr auf `[NICHT ABBILDBAR]`; die mit `CR-2026-016` bereits behobene Zeile S4 und die Restangaben zu AP2-CC-02 in den Abschnitten 1a, 4, 5 und 7 sind nachgezogen | `<FRAMEWORK_OWNER>` |
+| 0.7.0 | 2026-09-10 | **Belegspalte nennt die Quelle (`CR-2026-018`, `FW-AK-01`).** Jede mit AP2 belegte Zeile nennt die Seite der Herstellerdokumentation, auf die sie sich stuetzt; die vollstaendige Belegzuordnung steht im Hauptdokument in Anhang 31.4.2, der bis dahin ausschliesslich Devin-Quellen fuehrte. Neu aufgenommen: AP2-CC-12 (`permissionMode` im Subagentenprofil, offene Teilfrage zu M2). Genauer belegt: H2 (ein blockierender Hook geht auch einer `allow`-Regel vor), A1 (`disallowedTools` zuerst; ein Profil ohne aufloesbares Werkzeug startet nicht), S4 (die Sperre haelt die Skill-Beschreibung aus dem Kontext) | `<FRAMEWORK_OWNER>` |
+| 0.8.0 | 2026-09-11 | **Der Schutz-Hook läuft fail-closed (`CR-2026-026`, D-31).** Das Eingabeschema dieses Clients ist gegen eine Installation bestätigt (AP2, WN-5); 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 durchgelassen. Der Schalter steht im Kommando, nicht in `env` – die bis 0.23.0 hier empfohlene Umgebungsvariable hätte die Sperre an eine zweite, unbelegte Clientzusage gehängt. Prüfung 17 belegt die Wirkung; weil die Hooks hier in der Saat liegen, ist das Argument in einer bestehenden Installation von Hand nachzuziehen | `<FRAMEWORK_OWNER>` |
+| 0.8.1 | 2026-09-11 | **Der Matcher deckt das Lesewerkzeug ab (`CR-2026-030`, D-33).** D-30 hatte entschieden, dass Secret-Pfade auch gegen lesende Werkzeuge durchgesetzt werden; eingelöst war das nie – die Hook-Quelle nannte kein Leseverb, und `hook_tools` bildete keines ab. Aufgefallen ist es bei AP2 des anderen Packs, gilt aber hier genauso: `Read` steht jetzt in der Abbildung, Prüfung 16 sondiert es | `<FRAMEWORK_OWNER>` |
+| 0.9.0 | 2026-09-11 | **Drei Zusagen mehr, zwei davon mit offenem Marker – und das ist der Punkt.** Neu: **R5** (Aufzählbarkeit der Regelquellen – dieser Client kennt kein Aufzählungskommando; was es gibt, ist die Selbstauskunft der Sitzung, beobachtet, aber Modellverhalten), **S5** (Aufzählbarkeit der Skills – für diesen Client **nicht erhoben**, VERIFY) und **R6** (keine Importe fremder Werkzeugformate: Der Mechanismus `claudeMdExcludes` ist gemessen, eine Vorgabe wird bewusst **nicht** ausgeliefert, `CR-2026-038` E2). Neuer Abschnitt 8 mit den Anweisungs- und Konfigurationsquellen außerhalb des Projekts – gemessen ist dort, dass eine `CLAUDE.md` aus einem **Elternverzeichnis** mitlädt (K-22) und dass die nutzerglobale Einstellungsdatei **Berechtigungen und Hooks** führt (ERH-07). Der B-Block trägt die Vorbemerkung zur Betriebsmodus-Abhängigkeit (D-35); die README der Regelablage ist in die Laufzeit-README aufgegangen (D-36). Nach zwei Releases ohne VERIFY-Marker stehen wieder zwei – sie sind kein Rückschritt, sondern zwei Fragen, die vorher nicht gestellt waren | `<FRAMEWORK_OWNER>` |
+| 0.18.0 | 2026-09-16 | **Die verbindliche Zielversion ist festgelegt, und sie ist eine Spanne (`CR-2026-075`, D-112, D-113).** Der Steckbrief trug seit 0.6.0 den Satz, die verbindliche Zielversion stehe aus – **dieselbe offene Festlegung, die das Schwesterpack als Ausfüllschlitz trug und die es acht Releases lang auf `entwurf` hielt.** Der Schlitz sperrte den Übergang, der Satz nicht; gefunden hat den Fall nicht eine Suche nach der Marke, sondern die Frage, wo dieselbe Aussage sonst noch steht. Seit diesem Release führt der Steckbrief zwei Zeilen: die Zielspanne `2.1.x` als Geltungsbereich und den gemessenen Punktwert `2.1.267` daneben. **Der Punktwert war zum Zeitpunkt der Festlegung sechs Patchstände alt** (installiert: 2.1.273) – genau der Grund, aus dem die Zielversion eine Spanne ist | `<FRAMEWORK_OWNER>` |
+| 0.21.0 | 2026-09-18 | **Produktbeobachtung `FW-AK-01` gegen 2.1.275** (`CR-2026-087`). Fünf Quellen und acht Patchstände abgeglichen. 🟢 **Der VERIFY-Marker auf `R5` ist aufgelöst** – die Dokumentation nennt seit diesem Stand zwei technische Aufzählungswege (`/context`, Hook `InstructionsLoaded`); der Satz *„Kein Kommando dieses Clients führt die wirksamen Regelquellen auf"* war nicht mehr wahr (D-158). 🔴 **Zwei neue Quellen außerhalb des Repositoriums, beide standardmäßig an:** die selbstgeschriebene Anweisungsquelle – **abgeschaltet**, `autoMemoryEnabled: false` (D-154, Abschnitt 8a) – und die Kontoquelle der Skills, die sich aus der ausgelieferten Datei **nicht** abschalten lässt und deshalb als benannte Grenze in `X1` steht (`K-63`). Ergänzt: `QC-6` für die Hook-Seite, die drei Zusagen dieses Packs tragen und die die Quellenliste nicht führte (D-159) | `<FRAMEWORK_OWNER>` |
+| 0.20.0 | 2026-09-18 | **Zeile B2 ist zur Hälfte aus der Dokumentation heraus** (`CR-2026-082`, D-134). Die Kette *Verweigern vor Rückfragen vor Erlauben* hat drei Paare; **zwei sind jetzt gemessen**: `deny` über `allow` seit 0.55.0 (D-121) und **`ask` über `allow` mit diesem Release** – an einem Paar, das sich in genau einer Zeile der Berechtigungsdatei unterscheidet. **Die praktische Folge steht in der Zeile:** Solange `Edit(**)` im `ask`-Korb steht, bleibt eine ausdrückliche `allow`-Regel auf eine **einzelne Datei** wirkungslos – ein Projekt kann sie nicht vorab freigeben. **`deny` über `ask` bleibt unbelegt und sagt es.** Der Messwert ist beim dritten Sitzungstest **zugefallen**: Er war ein Zuschnitt zu `FW-PI-04`, kein eigener Versuch | `<FRAMEWORK_OWNER>` |
+| 0.19.0 | 2026-09-18 | **Zeile B6 traegt ihre Grenze selbst, und sie ist gemessen (`CR-2026-077`, D-123).** Das Praefixmuster eines `deny`-Eintrags erfasst nur Kommandos, die mit der **Zeichenfolge** beginnen: `git push origin main` wird abgewiesen, `git -C <pfad> push origin main` laeuft durch und erreicht das Remote – gemessen am 2026-09-17 mit Wirkung am Remote. **In der ausgelieferten Fassung haelt die Sperre trotzdem**, aber ueber den `allow`-Korb und nicht ueber den `deny`-Eintrag. **Der Satz war seit 0.15.0 da und stand am falschen Ort:** Der Vorbehalt in Abschnitt 4 nannte die Grenze und verwies fuer sie auf B6 – **zweiundvierzig Releases lang auf eine Zeile, die sie nicht trug** (`K-48`). Der Vorbehalt fuehrt jetzt beide Richtungen; die Einleitung des Abschnitts sagt nicht mehr, die Abweichung sei eine Verschaerfung. Die Einstufung `[TECHNISCH]` bleibt | `<FRAMEWORK_OWNER>` |
+| 0.13.0 | 2026-09-13 | **Der Hook blockierte hier jeden Schreibzugriff – gemessen und behoben (`CR-2026-056`, D-61 bis D-63, Befund B06).** Weil dieser Client in jedem Ereignis `transcript_path` unter `~/.claude/projects/` führt und der Hook bis 0.33.0 **alle** Zeichenketten des Ereignisses durchsuchte, traf das Strukturmuster der Laufzeitschicht bei jedem `Edit`, `Write` und `NotebookEdit` – unabhängig vom Ziel. Am Client nachgemessen, mit Kontrolllauf. Geprüft wird jetzt die Operation statt des Umschlags. Neue Zeile **H4** mit Eingabeschema, Pfadidentität und der benannten Zeitlücke; Abschnitt 5 berichtigt eine Aussage über das andere Pack, die neun Releases lang falsch war | `<FRAMEWORK_OWNER>` |
+| 0.25.0 | 2026-09-28 | **Die MCP-Anbindung ist gemessen** (`CR-2026-157`, D-456, D-459). Zeile MCP-Konfiguration: Server vom Typ `http` mit Kopfzeile aus einer Umgebungsvariablen, auch im Druckmodus. Zeile X1: Die Freigabe je Werkzeug trägt, aber die pauschale Rückfrage `mcp__*` schlägt sie – eine Freigabe zum Lesen ersetzt sie durch Einzelregeln. Das Manifest führt dafür `mcp_permission_rule` (Prüfung 101) | `<FRAMEWORK_OWNER>` |
+| 0.25.1 | 2026-09-29 | **Das PowerShell-Werkzeug ist den Befehlsregeln gleichgestellt** (`CR-2026-159`, D-469, `K-70`). Manifest: `PowerShell` in `permission_tools.exec` und `hook_tools.exec` – jede Befehlsregel entsteht als `Bash(…)` und `PowerShell(…)`, der Hook-Matcher nennt das Werkzeug. Zeilen `exec`, B3 und B6 mit den Messwerten; dazu der Befund, dass der Client das Werkzeug ohne `PowerShell(…)`-Regel bei bestehenden Bash-Sperren ausblendet | `<FRAMEWORK_OWNER>` |
+| 0.26.0 | 2026-09-29 | **MCP-Aufrufe erreichen den Schutz-Hook, und die Connectoren des Kontos stehen in Abschnitt 8** (`CR-2026-162`, D-486 bis D-489, `K-184`, `K-191`, `K-192`). Manifest: `hook_tools.mcp` mit `mcp__.*` und `hook_mcp_prefixes`. Zeile H1: MCP-Werkzeuge, gemessen mit einem Köderserver, und das Entscheidungsprotokoll. Abschnitt 8.2: die Connectoren des Kontos mit gemessenem Abschaltweg aus dem Projekt; 8.3: die Grenze des Protokolls (`K-200`) | `<FRAMEWORK_OWNER>` |
+| 0.26.2 | 2026-09-30 | **Die Modusbindung ist gemessen** (`CR-2026-164`, D-501, `K-179`). Zeile M4: M2 an den Schutz-Hook gebunden, `Write` außerhalb der Plan-Ablage abgewiesen, in ihr durchgelassen | `<FRAMEWORK_OWNER>` |
+| 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>` |