@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-056-eingabeschema-und-pfadidentitaet.md

@@ -0,0 +1,245 @@
+# Änderungsantrag `CR-2026-056`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Schutz-Hook kennt kein Ereignis – er nimmt jede JSON-Struktur an und prüft Felder, die nicht zur Operation gehören |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-13 |
+| Betroffene Artefakte | `tests/scripts/hook-check-secrets.py` (Umbau in drei Stufen), beide `clients/*/manifest.json` (neues Feld `hook_path_fields`), beide `CLIENT_PACK.md` (neue Zeile **H4**, Berichtigung Abschnitt 5, Summen), `tests/scripts/validate-framework.py` (**Prüfung 32**), `tests/scripts/probe-pruefungen.py`, `framework/core/03-security.md`, `tests/EDGE_CASES.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** (durchsetzender Mechanismus) und Client Packs |
+| Art | Befund **B06** des unabhängigen Reviews vom 2026-09-12, P2; **gegengeprüft, bestätigt, in jedem Teil größer als berichtet – und um einen Befund der Gegenrichtung erweitert, den der Bericht nicht nennt** |
+| Dringlichkeit | **Paket 6**, erster Eintrag. Der Teil aus Abschnitt 1.4 ist **P1**: Er sperrt das Pack `claude-code` für jeden Schreibzugriff und betrifft den laufenden Piloten |
+
+## 1. Anlass und Problem
+
+Die Gegenprüfung liegt vor: `tests/protocols/2026-09-13-B06-gegenpruefung.md`, vier Messreihen –
+41 synthetische Eingaben, die 20 **aufgezeichneten** Hook-Eingaben beider Packs, Pfadvarianten am
+echten Dateisystem mit `os.path.samefile` als Vorprüfung, und zwei Sitzungen eines realen Clients
+mit Kontrolllauf.
+
+### 1.0 Eine Ursache, zwei entgegengesetzte Symptome
+
+Der Kopfkommentar des Hooks nennt sie beim Namen und hält sie für eine Entscheidung:
+
+> „Das Skript ist bewusst schema-agnostisch: Es durchsucht alle Zeichenketten der über stdin
+> gelieferten JSON-Struktur.“ (`hook-check-secrets.py:6`)
+
+Weil er kein Ereignis prüft, nimmt er jede Struktur an, die JSON ist – **er lässt zu viel durch**.
+Weil er *alle* Zeichenketten durchsucht, prüft er auch Felder, die nicht zur Operation gehören –
+**er blockiert zu viel**. Das Review sieht nur die erste Hälfte.
+
+### 1.1 `--fail-closed` fängt genau einen Fall ab: den Syntaxfehler
+
+```python
+payload = json.loads(raw) if raw.strip() else {}      # :233
+```
+
+Eine leere Eingabe wird zu einem leeren Objekt **erklärt**; ein `json.loads`, das nicht wirft, gilt
+als gelesenes Ereignis. Gemessen, alle mit `--fail-closed`: leere Eingabe, nur Weißraum, `[]`,
+`null`, eine Zeichenkette und eine Zahl laufen sämtlich mit **Exit 0** durch. **Das Review nennt
+zwei Formen, es sind sechs.**
+
+### 1.2 Ein unbekannter Werkzeugname überspringt beide Pfadblöcke
+
+```python
+if tool_name in WRITE_TOOLS + EXEC_TOOLS + READ_TOOLS + SEARCH_TOOLS or not tool_name:   # :258
+```
+
+Gemessen: `MultiEdit`, `mcp__fs__write_file`, `ReadFileTool`, `Task` und der Wert `42` – jeweils mit
+einem Kernpfad oder `.env` in der Eingabe – laufen mit **Exit 0** durch. Die Secret-Muster greifen
+weiterhin; betroffen ist die **Pfad**prüfung. Der Wert `42` ist eine eigene Feststellung:
+`str(payload.get("tool_name", ""))` macht aus jedem Typ einen Werkzeugnamen.
+
+### 1.3 Eigene Feststellung: Der Rückfall für die unbekannte Operation ist die einzige Stelle ohne Kernschutz
+
+Der Kommentar nimmt für sich in Anspruch, was der Code nicht tut:
+
+```python
+# Ohne Werkzeugnamen ist die Art der Operation unbekannt; dann gilt die
+# strengere Liste. …
+schreibend = tool_name in WRITE_TOOLS or not tool_name          # :266
+…
+if tool_name in WRITE_TOOLS:                                    # :287  <- das Kernverzeichnis
+```
+
+`schreibend` wählt zwischen zwei Listen; die **strengste** – das Kernverzeichnis als Ganzes – hängt
+an einer dritten Bedingung, und die ist ohne Werkzeugnamen falsch. Gemessen: Ein Objekt ohne
+`tool_name` mit `file_path: leitwerk-core/VERSION` läuft mit **Exit 0** durch, dasselbe mit
+`tool_name: "Write"` blockiert. **Die Stelle, die sich ausdrücklich die strengere nennt, ist die
+einzige, an der der Kern ungeschützt ist.**
+
+### 1.4 Eigene Feststellung, P1: Der Hook blockiert bei `claude-code` **jeden** Schreibzugriff
+
+Das Review beschreibt B06 durchgehend als „lässt durch“. Gemessen ist die Gegenrichtung.
+
+Die 15 aufgezeichneten `claude-code`-Eingaben führen den Umschlag `cwd`, `effort`,
+`hook_event_name`, `permission_mode`, `prompt_id`, `session_id`, `tool_use_id`, **`transcript_path`**.
+Der Transkriptpfad liegt immer unter `~\.claude\projects\…` und trifft damit
+`(^|[\\/])\.(devin|claude)[\\/]` – ein **Strukturpfad**, und der gilt für schreibende Werkzeuge.
+
+Die einzige Schreiboperation im Bestand – auf eine harmlose Datei in einem Wegwerfverzeichnis –
+läuft unverändert durch den Hook mit **Exit 2**. Einvariabel isoliert:
+
+| Variante der aufgezeichneten Eingabe | Exit |
+|---|---|
+| unverändert | **2** |
+| ohne `transcript_path` | 0 |
+| `transcript_path` mit `\neutral\` statt `\.claude\` | 0 |
+| ohne `cwd` | **2** |
+| nur `tool_name` + `tool_input` | 0 |
+
+**Am Client nachgemessen**, drei Läufe, Aufgabe identisch: mit Regeltexten verweigert der Agent aus
+den Regeln (Modellverhalten); **ohne Regeltexte, nur mit der Hook-Konfiguration, blockiert der Hook
+und die Datei entsteht nicht**; im Kontrolllauf ohne Hook entsteht sie. Der Matcher der erzeugten
+`.claude/settings.json` führt `Edit|Write|NotebookEdit`, das Kommando trägt `--fail-closed`.
+
+**Für ein Projekt mit diesem Pack ist damit jedes direkte Schreiben gesperrt, unabhängig vom Ziel.**
+Das Muster steht seit 0.7.0. Unbemerkt blieb es, weil Prüfung 16 den Hook **ohne Umschlag** aufruft,
+der Aufzeichnungs-Hook ein anderer Hook ist, der nichts entscheidet, und auf dem Branch des Piloten
+nichts committet ist.
+
+### 1.5 Eigene Feststellung: `cwd` ist der zweite Kanal derselben Ursache
+
+Nur Pflichtfelder, Ziel `/tmp/x.txt`: Exit 0. Dieselbe Eingabe mit `cwd = …\leitwerk-core\tests`:
+**Exit 2**. **Eine Sitzung, die im Kernverzeichnis startet, kann nirgendwohin mehr schreiben.** Es
+ist kein Feld, es ist eine Gattung – eine Ausnahmeliste für `transcript_path` würde beim nächsten
+Client-Feld wieder brechen.
+
+### 1.6 Sieben von neun Musterfamilien sind schreibungssensitiv – und zwei sind es nicht
+
+Das Review nennt das Kernverzeichnis. Gezählt: `\.env`, `id_(rsa|ed25519|ecdsa)`,
+`(AGENTS|CLAUDE)\.md`, `\.(devin|claude)/`, `project-overlay/`, `framework/core/` und
+`<CORE_DIR>/` tragen **kein** `re.I`; die Endungsliste und `secrets?/` tragen es. **Das ist der
+Beleg, dass es keine Entscheidung für POSIX-Semantik war, sondern eine Ungleichbehandlung
+innerhalb derselben Datei.**
+
+### 1.7 Fünf bzw. sechs Pfadvarianten treffen dieselbe Datei und werden verschieden entschieden
+
+Jede Variante vorab mit `os.path.samefile` belegt. Auf `<CORE_DIR>/VERSION` passieren
+**Großbuchstaben, der 8.3-Kurzname `LEITWE~1`, eine Junction und ein Gerätepfad mit
+Großschreibung**; auf `CLAUDE.md` passieren **Kleinschreibung, ein Punkt am Ende, ein Leerzeichen
+am Ende und `::$DATA`**. **Kurzname, Punkt- und Leerzeichen-Anhang und der Datenstrom-Zusatz
+kommen im Review nicht vor.**
+
+Die Gegenprobe hält: `leitwerk-core-alt/x.txt` und `AGENTS.md.bak` werden **nicht** blockiert. Der
+vom Review vorsorglich genannte Präfixfehler liegt **nicht** vor – die Muster verlangen einen
+Trenner.
+
+**Nachgemessen, und es entscheidet den Zuschnitt:** `os.path.realpath` führt Großschreibung,
+Kurzname, Junction, Punktsegmente, Punkt- und Leerzeichen-Anhang und `::$DATA` auf die
+Standardschreibweise zurück – auch für ein nicht existierendes Ziel über den existierenden
+Elternpfad. **Nur der Gerätepfad-Präfix `\\?\` überlebt.** Es braucht also keinen Neubau der
+Musterlogik.
+
+### 1.8 Nebenbefund: Abschnitt 5 beider Packs behauptet seit neun Releases fail-open
+
+Beim Einfügen der Matrixzeile aufgefallen:
+
+| Stelle | Wortlaut | Stand |
+|---|---|---|
+| `devin-desktop/CLIENT_PACK.md` Abschnitt 5 | „**Der Schutz-Hook blockiert nicht.** … läuft bei diesem Pack fail-open … Bis dahin ist H2 eine Absichtserklärung, keine Schranke“ | **falsch seit 0.25.0** |
+| ebenda, Folgeabsatz | „Das Manifest führt `hook_fail_closed: false`“ | **falsch** – es führt `true` |
+| `claude-code/CLIENT_PACK.md` Abschnitt 5 | „Bei `devin-desktop` ist H2 als `[TEXTUELL]` eingestuft … dort läuft das Hook-Skript weiter fail-open“ | **falsch** – H2 steht dort auf `[TECHNISCH]` |
+
+Zeile H2 desselben Dokuments sagt seit 0.25.0 das Gegenteil: „Seit 0.25.0 **fail-closed**
+(`hook_fail_closed: true`)“. **Die Zusammenfassung widerspricht ihrer eigenen Tabelle** – dieselbe
+Bauform wie die überzeichneten Summen aus 0.33.0, nur mit umgekehrtem Vorzeichen: Hier
+**unter**zeichnet der Fließtext, was der Mechanismus leistet.
+
+## 2. Vorgeschlagene Änderung
+
+Der Hook wird in **drei Stufen** gegliedert, wie das Review es vorschlägt: Ereignis validieren,
+Operation samt Pfaden normalisieren, Regeln auswerten. Die Muster bleiben, was sie sind.
+
+1. **Ereignis.** Ein Ereignis ist ein JSON-**Objekt** mit einem nicht leeren `tool_name` vom Typ
+   Zeichenkette und einem `tool_input`, das vorhanden und ein Objekt ist. Alles andere gilt als
+   **unprüfbar**: mit `--fail-closed` blockiert es, sonst warnt es auf stderr und läuft durch –
+   derselbe Weg, den der Syntaxfehler heute nimmt. **Zusätzliche unbekannte Felder bleiben
+   zulässig**, damit eine additive Client-Erweiterung nicht zum Ausfall führt.
+2. **Operation.** Ein Werkzeugname, der in keiner Verbliste steht, gilt als **unbekannte
+   Operation** und wird nach der **strengsten** Liste gemessen – Secret-Pfade, Strukturpfade **und
+   das Kernverzeichnis**. Dasselbe gilt für den Fall ohne Werkzeugnamen; damit stimmt der Kommentar
+   aus 1.3 zum ersten Mal.
+3. **Prüfmaterial.** Geprüft wird **`tool_input`**, nicht der Umschlag. `cwd` wird ausschließlich
+   als **Auflösungsbasis** verwendet, nie als Prüfmaterial. Die Tokenzerlegung für ausführende
+   Werkzeuge bleibt.
+4. **Pfadidentität.** Die als Pfadfelder deklarierten Werte aus `tool_input` werden gegen `cwd`
+   (sonst die Projektwurzel) aufgelöst, `\\?\`-Präfixe zuvor entfernt, dann `os.path.realpath`.
+   Die vorhandenen Muster laufen zusätzlich über den aufgelösten Pfad – projektrelativ, wenn er
+   innerhalb der Projektwurzel liegt, sonst absolut und nur gegen die Secret-Muster. Ein Pfad, der
+   sich nicht auflösen lässt, und ein Gerätepfad im `\\.\`-Namensraum gelten als **unprüfbar**.
+5. **Groß-/Kleinschreibung.** Alle Pfadmuster laufen mit `re.I`.
+6. **Die Pfadfelder kommen aus den Manifesten** – neues Feld `hook_path_fields`, über alle Packs
+   vereinigt, über einer Basisliste. Dieselbe Bauart wie `hook_tools` (D-28).
+7. **Prüfung 32** misst die Wirkung: Eingabeschema, unbekannter Werkzeugname, Umschlagfeld,
+   Pfadidentität – je Pack, mit Gegenproben.
+8. **Zeile H4** in beiden Fachmatrizen; Abschnitt 5 beider Packs wird berichtigt; die Summen
+   rechnet Prüfung 31 nach.
+9. **Die Zeitlücke wird benannt**, im Docstring und in H4: Ein Hook prüft vor dem Zugriff; eine
+   zwischenzeitlich umgebogene Verknüpfung kann er nicht ausschließen.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Er schließt den Shell-Schreibweg nicht.** Ausführende Werkzeuge werden weiterhin nur an den
+  Secret-Pfaden gemessen (D-30); das Kernverzeichnis bleibt für `exec` offen (B04, D-47). **K-32
+  bleibt damit offen** – der Selbstanwendungsweg über die Shell wird hier nicht zugemacht. Das war
+  die Bedingung, unter der K-32 in Paket 6 steht, und sie ist mit diesem Antrag **nicht** erreicht.
+- **Er baut keine Isolationsschicht.** Ohne sie bleibt die Zeitlücke bestehen; der Antrag benennt
+  sie, er beseitigt sie nicht (`CR-2026-047` E5).
+- **Er baut kein Sitzungsobjekt für M4/M5.** Das setzt B06 voraus und **zusätzlich** eine Quelle
+  außerhalb der Reichweite des Agenten (`CR-2026-048` E1). Mit diesem Antrag ist die
+  Voraussetzung erfüllt, mehr nicht.
+- **Er misst keine POSIX-Plattform.** Junctions sind unter NTFS gemessen; symbolische
+  Verknüpfungen unter Linux und macOS sind Erwartung, nicht Messung.
+- **Er ändert die Musterlisten inhaltlich nicht.** Was geschützt ist, bleibt geschützt; geändert
+  wird, **woran** gemessen wird.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: durchsetzender Mechanismus im Kern, Deklaration im Pack.
+- [x] Verschärfungsprinzip: **verschärft an fünf Stellen, lockert an einer** – und die eine ist
+      benannt und kompensiert, siehe E3. Verschärft: sechs Eingabeformen, die durchliefen, blocken;
+      unbekannte Werkzeuge und der leere Name bekommen den Kernschutz; sieben Musterfamilien werden
+      schreibungsunempfindlich; fünf bzw. sechs Pfadvarianten werden erfasst; nicht auflösbare Pfade
+      gelten als unprüfbar. Gelockert: das Prüfmaterial schrumpft vom Umschlag auf `tool_input`.
+- [x] Widerspruchsfreiheit: gelesen wurden D-23 (jede Prüfung braucht eine Sonde), D-28
+      (Werkzeugnamen aus den Manifesten), D-30 (zwei Schutzziele, zwei Listen), D-31 (der Schalter
+      steht im Kommando, nicht in `env`), D-35, D-47 (Zusagen je Zugriffskanal), D-49 (beide
+      Kodierungsumgebungen), `governance/PRIORITY_HIERARCHY.md`.
+- [x] Laufzeitfassungen: Die erzeugten Regeln und die Hook-Konfiguration ändern sich **nicht**.
+      Der Matcher bleibt, das Kommando bleibt. Geändert wird ausschließlich das Skript, das der
+      Kern liefert – und das erreicht ein bestehendes Projekt über `install.py --update`.
+- [x] Belegstatus: **vier Messreihen, davon zwei mit echten Clientdaten und eine am Client selbst,
+      mit Kontrolllauf.** Kein Punkt dieses Antrags steht auf Codelektüre allein.
+- [x] Test- und Validierungsbedarf: **Prüfung 32** mit Sonden und Gegenproben je Pack; dazu Sonden
+      in `probe-pruefungen.py` für die Prüfung selbst und für ihren Anker.
+- [x] Overlays: unberührt. Kein Overlay-Feld ändert sich.
+- [ ] Dokumentation: `CHANGELOG.md`, Decision Log (D-61, D-62, D-63), Roadmap, beide Packs,
+      `tests/EDGE_CASES.md`, `framework/core/03-security.md`.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Was gilt als Ereignis, und was passiert mit allem anderen? | **Objekt, nicht leerer `tool_name` als Zeichenkette, `tool_input` als vorhandenes Objekt.** Alles andere ist **unprüfbar** und nimmt den Weg des Syntaxfehlers: mit `--fail-closed` blockieren, sonst warnen. Zusätzliche unbekannte Felder bleiben ausdrücklich zulässig | Ein Client, der ein anderes Schema sendet, blockiert bei jedem Werkzeugaufruf statt still durchzulaufen. **Das ist genau, was `--fail-closed` zusagt** – aber es macht aus einem stillen Loch einen sichtbaren Ausfall. Die Meldung muss die Ursache und den Weg nennen: Fundstelle melden, Schema gegen die Clientdokumentation prüfen, Änderungsantrag |
+| E2 | Wie wird ein unbekannter Werkzeugname behandelt: blockieren oder streng messen? | **Streng messen, nicht blockieren.** Er gilt als unbekannte Operation und bekommt die strengste Liste, einschließlich Kernverzeichnis. Blockieren würde den Hook darauf stützen, dass der Client den Matcher einhält – eine **Clientzusage**, und genau die Art unbelegter Annahme, an der AP2-CC-13 acht Releases lang hing (D-31) | Ein künftiges lesendes Werkzeug, das nicht im Manifest steht und einen Strukturpfad des Kerns anfasst, wird blockiert. Der Weg zurück ist ein Manifesteintrag, und die Meldung sagt das. **Der Preis ist gewollt:** Ein Werkzeug, das kein Pack kennt, soll auffallen |
+| E3 | Wird nur `tool_input` geprüft – und damit die Reichweite **verkleinert**? | **Ja, und das ist die einzige Lockerung dieses Antrags.** Ein Pfad, der außerhalb von `tool_input` steht, wird nicht mehr gesehen. Kompensiert durch E1 und E2: Die Form ist ab jetzt Pflicht, und was nicht passt, wird streng gemessen oder blockiert. Der Umschlag trägt in beiden aufgezeichneten Schemata **keine Operationsdaten** – nur Sitzungs- und Ablaufkennungen | **Sie muss im Wirkungsnachweis nachgerechnet werden, nicht behauptet.** Eine Ausnahmeliste für `transcript_path` wäre die kleinere Änderung gewesen und ist verworfen: Es ist kein Feld, es ist eine Gattung (1.5). Bleibt der Umschlag im Prüfmaterial, kommt der Fehler beim nächsten Clientfeld zurück |
+| E4 | Groß-/Kleinschreibung: plattformabhängig oder immer unempfindlich? | **Immer unempfindlich.** Der Hook liegt einmal im Kern und wird von allen Packs auf allen Plattformen geteilt; eine plattformabhängige Entscheidung machte das Ergebnis davon abhängig, wo er läuft, und wäre in einer Umgebung nicht prüfbar. Auf POSIX ist es eine **Verschärfung** – dieselbe Begründung, mit der die Muster schon heute `AGENTS` und `CLAUDE` gemeinsam führen | Ein Projekt auf Linux, das neben `AGENTS.md` eine eigene `agents.md` führt, kann sie nicht mehr schreiben. **Kein Schalter dafür** – ein Schalter wäre ein Hebel, den ein Agent umlegen kann. Der Weg ist der Änderungsantrag, und die Grenze steht in `EDGE_CASES.md` |
+| E5 | Pfadidentität: Musterlogik neu bauen oder die Muster auf den aufgelösten Pfad anwenden? | **Auf den aufgelösten Pfad anwenden.** Gemessen (1.7): `realpath` trägt Kurzname, Junction, Punktsegmente, Punkt- und Leerzeichen-Anhang und `::$DATA`, auch für nicht existierende Ziele über den Elternpfad. Ein Neubau mit `commonpath` gegen aufgelöste Wurzeln löste dasselbe Problem mit mehr Code und einer zweiten Wahrheit über das, was geschützt ist | Der Hook fasst jetzt das Dateisystem an. Begrenzt: nur deklarierte Pfadfelder, für `exec` höchstens die Tokens, die wie Pfade aussehen, gedeckelt. **Jeder Fehlschlag ist `unprüfbar`, kein stilles Durchlassen** – sonst wäre die Auflösung eine neue Lücke statt einer Schranke |
+| E6 | Woher weiß der Hook, welche Felder Pfade tragen? | **Aus den Manifesten**, neues Feld `hook_path_fields`, über alle Packs vereinigt, über einer Basisliste. Dieselbe Bauart und dieselbe Begründung wie `hook_tools` (D-28): Ein zusätzlich erkanntes Feld ist eine Verschärfung | Jedes künftige Pack braucht den Eintrag. Ein Pack, das ihn weglässt, fällt auf die Basisliste zurück – **die Basisliste muss deshalb gut sein**, und Prüfung 32 misst sie je Pack an einer Sonde, nicht am Vergleich zweier Listen |
+| E7 | Wird die Zeitlücke zwischen Prüfung und Zugriff geschlossen? | **Nein, sie wird benannt** – im Docstring und in Zeile H4. Ein Hook kann eine zwischenzeitlich umgebogene Verknüpfung nicht ausschließen; das kann nur die ausführende Dateischicht oder eine Isolation | Eine bewusste, benannte Schuld, verknüpft mit dem Paket-6-Eintrag zur Isolationsschicht (`CR-2026-047` E5). **Eine Zeile, die die Grenze nicht nennt, wäre der Befundtyp dieses Projekts, hier neu erzeugt** |
+| E8 | Bekommt die Fähigkeitsmatrix eine eigene Zeile? | **Ja, H4.** Die Lehre aus B11 und aus dem Suchkanal: Eine Zusage ohne Matrixzeile fällt niemandem auf. H4 trägt je Pack, was das Eingabeschema hergibt – bei `claude-code` gegen eine Installation bestätigt, bei `devin-desktop` gegen die Aufzeichnung | Die Summen ändern sich ein Release nach ihrer Berichtigung. Prüfung 31 rechnet sie nach; das ist kein Aufwand, sondern der Zweck der Prüfung |
+| E9 | Wird der Nebenbefund aus 1.8 mitberichtigt, obwohl er nicht zu B06 gehört? | **Ja.** Drei Aussagen in zwei Packs behaupten seit **neun Releases** fail-open, während dieselben Dokumente in Zeile H2 fail-closed führen. Sie stehen im selben Abschnitt, den dieser Antrag ohnehin anfasst | Der Antrag wächst um eine Sache, die B06 nicht nennt. **Ihn zu vertagen hieße, eine bekannte Falschaussage stehen zu lassen, während man daneben schreibt** – und die Lehre aus 0.33.0 war genau diese: Was beim Anfassen auffällt, wird mitberichtigt und im Protokoll benannt |
+| E10 | Was geschieht mit dem Piloten? | **Er braucht dieses Release, nicht nur `--update` auf 0.33.0.** Er steht auf 0.29.0 mit `claude-code`; das Schreiben ist dort gesperrt, seit die Installation steht. Der Migrationshinweis sagt es ausdrücklich | Die Übergabe an den Nutzer wird länger: `--update` auf 0.34.0, dann die beiden Handgriffe aus 0.30.0/0.32.0. **Dass der Pilot nie geschrieben hat, ist kein Zufall gewesen** – das gehört in den Hinweis, sonst liest es sich wie eine neue Einschränkung |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle zehn Fragen wie vorgelegt.** E1 Ereignisschema mit `unprüfbar` als drittem Ausgang; E2 unbekannter Werkzeugname wird streng gemessen, nicht blockiert; E3 nur `tool_input`, die Lockerung wird nachgerechnet; E4 immer schreibungsunempfindlich, ohne Schalter; E5 Muster auf den aufgelösten Pfad; E6 Pfadfelder aus den Manifesten; E7 Zeitlücke benannt, nicht geschlossen; E8 Zeile H4; E9 der Nebenbefund wird mitberichtigt; E10 der Pilot bekommt einen ausdrücklichen Hinweis |
+| Datum | 2026-09-13 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-61 (der Hook prüft ein Ereignis, und `unprüfbar` ist ein eigener Ausgang), D-62 (geprüft wird die Operation, nicht der Umschlag), D-63 (Pfadidentität über den aufgelösten Pfad, schreibungsunempfindlich, ohne Schalter) |
+| Auflagen | **Die Lockerung aus E3 ist nachzurechnen, nicht zu behaupten:** Der Wirkungsnachweis führt gegen den Vorstand, welche Fälle neu blocken und welcher Fall neu durchläuft. **Prüfung 32 ruft den Hook mit vollständigem Umschlag auf** – Prüfung 16 tut es nicht, und genau daran ist der P1-Befund vorbeigekommen; das ist die eigentliche Lehre und gehört in den Docstring der Prüfung. **Der Migrationshinweis nennt den Piloten.** **Offen bleiben ausdrücklich:** K-32 (der Shell-Weg wird nicht geschlossen), die Isolationsschicht, das Sitzungsobjekt für M4/M5, das Domain-Profil, und die POSIX-Messung der Verknüpfungen |
+| Ziel-Release | `0.34.0` |
+| Umsetzung | umgesetzt mit `0.34.0` |

package/.koolie/core/governance/change-requests/CR-2026-057-disallowed-tools-und-s3.md

@@ -0,0 +1,148 @@
+# Änderungsantrag `CR-2026-057`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | `disallowed-tools` ist gemessen – S3 ist zurückgewinnbar, aber nicht in der Form, in der das Framework die Beschränkung heute aufschreibt |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-13 |
+| Betroffene Artefakte | `clients/claude-code/manifest.json` (Abbildungsfeld, `drop_fields`), `clients/claude-code/CLIENT_PACK.md` (Zeile **S3**, Summen), die zwölf Quellskills unter `framework/skills/` (nur, falls E3 es verlangt), `framework/core/05-working-model.md` (M1), `tests/scripts/validate-framework.py` (neue Prüfung), `tests/scripts/probe-pruefungen.py`, `tests/EDGE_CASES.md` |
+| Ebene laut Entscheidungsbaum 6 | **Client Pack** (Abbildung) und **Core** (die Aussage zu M1) |
+| Art | Offener Punkt aus `CR-2026-050`/D-50 und Eintrag in **Paket 6**; **erhoben am 2026-09-13**, neun Läufe, zwei davon verworfen und als Befund festgehalten |
+| Dringlichkeit | **Paket 6.** Kein P1: Die heutige Zusage ist **zu schwach**, nicht zu stark – S3 steht auf `[NICHT ABBILDBAR]`, und das war nach dem damaligen Belegstand richtig |
+
+## 1. Anlass und Befundlage
+
+Die Erhebung liegt vor: `tests/protocols/2026-09-13-erhebung-disallowed-tools.md`.
+Aufbau bewusst **ohne Bypass**: Die Berechtigungsschicht blieb an, und `Write` stand in der
+`allow`-Liste – damit kann eine Verweigerung von `Write` nur aus `disallowed-tools` kommen.
+
+### 1.1 Der Befund: es beschränkt wirklich, und zwar stärker als eine Regel
+
+| Lauf | Aufbau | Ergebnis |
+|---|---|---|
+| B | `disallowed-tools: Write, Edit` | **`Write` abgewiesen**, Datei nicht entstanden – **obwohl `Write` in `allow` steht** |
+| C | **Kontrolllauf**, identisch ohne das Feld | **`Write` gelang**, Datei entstanden |
+
+Beide Läufe zeigen dieselbe Werkzeugfolge, beginnend mit `Skill | {"skill": "lw-probe-dt"}`;
+nur der Ausgang von `Write` unterscheidet sich. `permission_denials` bestätigt es als zweite,
+vom Antworttext unabhängige Quelle.
+
+**Das ist genau das, was `allowed-tools` nach B01 nicht ist.** `disallowed-tools` wägt nicht
+gegen Freigaben ab – es nimmt das Werkzeug aus dem Vorrat, und eine `allow`-Regel holt es nicht
+zurück. **S3 ist damit zurückgewinnbar.**
+
+### 1.2 Grenze 1: Die Schranke gilt nur für den aufrufenden Turn
+
+Turn 1 mit Skill: `Write` abgewiesen. Turn 2 derselben Sitzung, ohne erneuten Skill-Aufruf:
+**`Write` gelang.** Die Dokumentation sagt es vorher; gemessen ist es jetzt auch.
+
+**Das wirkt in den Kern zurück.** `framework/core/05-working-model.md` stützt den Betriebsmodus
+M1 („nur lesend") unter anderem auf die Skill-Beschränkung. Eine Schranke mit Verfallsdatum am
+Ende des Turns ist **keine Betriebsart**.
+
+### 1.3 Grenze 2: Die Liste ist aufzählend, eine Lücke ist ausnutzbar
+
+Mit `disallowed-tools: Write, Edit` schrieb der Skill **über `Bash`**. Mit `Write, Edit, Bash`
+wurde `Bash` abgewiesen. Der exec-Weg ist ausdrückbar – **aber nur, wenn er dasteht.**
+
+### 1.4 Grenze 3, und sie entscheidet den Zuschnitt: Argumentmuster wirken **lautlos gar nicht**
+
+`disallowed-tools: Bash(echo verboten:*)` ließ den verbotenen Befehl durchlaufen – **ohne
+Verweigerung, ohne Fehlermeldung**. Ebenso die Schreibweise mit Leerzeichen. Derselbe Skill mit
+`disallowed-tools: Bash` wies **beide** Befehle ab.
+
+> **Der wiederkehrende Befundtyp dieses Projekts, in seiner unangenehmsten Form:** Der Eintrag
+> sieht aus wie eine Regel, wird angenommen, meldet nichts – und beschränkt nichts. Wer
+> `Bash(git push:*)` schreibt, hat **gar keine** Schranke, nicht bloß eine gröbere.
+
+### 1.5 Was das Framework heute aufschreibt – in drei Bauformen, nachgezählt
+
+Die zwölf Quellskills tragen `permissions` **nicht** einheitlich:
+
+| Bauform | Anzahl | Beispiel |
+|---|---|---|
+| nur grobe Verben (`edit`, `exec`) | **7** | `deny: [edit, exec]`; `fw-docs-update` nur `exec` |
+| befehlsgenaue Einträge | **5** | `deny: [Exec(git push), Exec(git reset --hard)]` |
+| dazu ein `allow:`-Block | **5** (dieselben fünf) | `allow: [Exec(git status), Exec(git diff)]` |
+
+**Nur die sieben groben lassen sich treu abbilden** – und von den fünf übrigen tragen **zwei** daneben das grobe Verb `edit`, bekommen also eine **teilweise** Schranke; **drei** bekommen gar keine. Diese Aufteilung ist an der **erzeugten Fassung** nachgezählt, nicht an der Quelle (siehe Abschnitt 6, Auflagen). Die fünf befehlsgenauen nicht: Ihr
+Verbotsteil ist nicht ausdrückbar (1.4), und ihr `allow:`-Teil wäre nach B01 ohnehin nur eine
+Vorabfreigabe, keine Zusage. **Sperrt man bei ihnen das ganze Werkzeug, macht man die
+`allow:`-Einträge derselben Skills wirkungslos** – `fw-tests` dürfte dann seinen Testbefehl
+nicht mehr ausführen.
+
+### 1.6 Nebenbefund zur Messmethode, nicht zur Sache
+
+Zwei der neun Läufe sind verworfen, beide, weil der **`Skill`-Aufruf** scheiterte und die
+Sitzung die `SKILL.md` ersatzweise als Datei las. Einmal, weil `defaultMode: bypassPermissions`
+in der Projektdatei nicht greift; einmal durch **Eigenverschulden** – der Vertrauenseintrag war
+zu früh entfernt. **Beide Male hat die Sitzung es von sich aus gemeldet; verlassen kann man sich
+darauf nicht.** Der Rekorder-Hook ist der Beleg, und er gehört in jede Sonde dieser Bauart.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Zeile S3 wird `[TECHNISCH]` mit drei benannten Grenzen** – Turnbereich, Aufzählung,
+   keine Argumentmuster. Belegstatus `[MESS]` mit Verweis auf das Erhebungsprotokoll.
+2. **`permissions.deny` bekommt eine Abbildung**, wie `triggers` sie mit
+   `model_invocation_field` bekam (D-50): neues Manifestfeld, das die groben Verben auf die
+   Werkzeugnamen des Packs abbildet – **aus `hook_tools`**, nicht aus einer zweiten Liste
+   (D-28). `edit` → `Edit, Write, NotebookEdit`; `exec` → `Bash`.
+3. **`permissions` verlässt `drop_fields`**, soweit es abgebildet wird. Der Ersatzsatz aus D-50
+   wird berichtigt: Es gibt jetzt einen Ersatz, und er ist **benannt schwächer**, nicht
+   abwesend.
+4. **Befehlsgenaue Einträge werden nicht abgebildet** – siehe E3 – und ihre Nicht-Abbildung
+   wird **deklariert statt verschwiegen**, in derselben Bauart wie `hook_tools_absent` (D-47).
+5. **Eine Prüfung weist die lautlose Musterform ab.** Ein `disallowed-tools`-Eintrag mit
+   Klammer ist gemessen wirkungslos; er darf in keiner erzeugten Fassung stehen.
+6. **M1 wird im Arbeitsmodell an den Belegstand angeglichen** (Turnbereich).
+7. **Sonden und Gegenproben** für die neue Prüfung und die Abbildung, je Pack.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Er misst `devin-desktop` nicht.** Die Wirkung der Skill-`permissions` bleibt dort
+  unerhoben; die Zeile behält ihren VERIFY-Marker.
+- **Er erhebt das Agentenprofil nicht** (`tools`/`disallowedTools`). Weiterhin ungemessen.
+- **Er macht aus S3 keine Betriebsart.** Die Turngrenze bleibt; sie wird benannt, nicht
+  geschlossen.
+- **Er berührt den Schutz-Hook nicht.** Die globale Berechtigungsschicht bleibt, was sie ist –
+  jetzt allerdings nicht mehr als *Ersatz* für S3, sondern **neben** ihm.
+- **Er entscheidet K-32 nicht** und baut keine Isolationsschicht.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Abbildung im Pack, die Aussage zu M1 im Kern.
+- [x] Verschärfungsprinzip: **verschärft.** Zwölf Skills tragen heute *keine* wirksame
+      Beschränkung; sieben bekommen eine. Gelockert wird nichts.
+- [x] Widerspruchsfreiheit: gelesen wurden D-23 (jede Prüfung braucht eine Sonde), D-28
+      (Werkzeugnamen aus den Manifesten), D-41 (Fähigkeitszusage), D-47 (Absenz wird deklariert),
+      D-50 (ein zusagentragendes Feld verschwindet nicht beim Rendern), K-18.
+- [x] Belegstatus: **neun Läufe, davon zwei verworfen und als Befund festgehalten**, mit
+      Kontrolllauf, Positivkontrolle und Rekorder-Hook je Lauf.
+- [ ] Test- und Validierungsbedarf: neue Prüfung plus Sonden – Zuschnitt hängt an E3 und E5.
+- [x] Overlays: unberührt.
+- [ ] Dokumentation: `CHANGELOG.md`, Decision Log, Roadmap, Client Pack, `EDGE_CASES.md`.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | Wird S3 zurückgewonnen, und auf welche Einstufung? | **`[TECHNISCH]` mit drei benannten Grenzen.** Gemessen ist eine echte Entfernung aus dem Werkzeugvorrat, die sogar eine `allow`-Regel schlägt | Eine Zeile, die die drei Grenzen **nicht** nennt, wäre der Befundtyp dieses Projekts, neu erzeugt. Die Zeile wird lang – **das ist der Preis, und er ist billig** |
+| **E2** | Woher kommen die Werkzeugnamen für `edit` und `exec`? | **Aus `hook_tools` des Manifests** (D-28), nicht aus einer zweiten Liste. `edit` → `Edit, Write, NotebookEdit`; `exec` → `Bash` | Jedes künftige Pack braucht die Zuordnung. Eine zweite Liste wäre eine zweite Wahrheit über dasselbe |
+| **E3** | Was geschieht mit den **fünf** Skills mit befehlsgenauen Verboten? | **Nicht abbilden und es deklarieren.** Die Alternative – das ganze Werkzeug sperren – ist strenger als gemeint und macht die `allow:`-Einträge derselben Skills wirkungslos: `fw-tests` könnte seinen Testbefehl nicht mehr ausführen | **Drei von zwölf Skills bekommen gar keine Schranke je Skill, zwei nur eine teilweise**, und das muss dastehen. Der Gegenvorschlag („lieber zu streng als gar nicht") verwandelt Arbeitsskills in unbrauchbare – deshalb verworfen |
+| **E4** | Wird `permissions.allow` auf `allowed-tools` abgebildet? | **Nein.** Nach B01 ist `allowed-tools` eine Vorabfreigabe, keine Zusage. Eine Abbildung erzeugte ein Feld, das wie eine Zusage aussieht und keine ist | Bequemlichkeit geht verloren: Die fünf Skills fragen bei ihren Testbefehlen weiter nach. **Das ist die ehrliche Seite des Handels** |
+| **E5** | Soll eine Prüfung Argumentmuster in `disallowed-tools` **abweisen**? | **Ja.** Gemessen ist: ein Eintrag mit Klammer wirkt lautlos gar nicht. Eine Prüfung, die ihn durchlässt, lässt eine Schranke durch, die keine ist | Wenn der Hersteller die Form später unterstützt, ist die Prüfung eine Bremse. **Dafür gibt es den Änderungsantrag** – und bis dahin ist das Schweigen gefährlicher |
+| **E6** | Wird M1 im Arbeitsmodell an die Turngrenze angeglichen? | **Ja.** M1 stützt sich auf die Skill-Beschränkung; die gilt nur für den aufrufenden Turn | Der Kern wird angefasst, und M1 liest sich schwächer. **Es ist aber keine Schwächung, sondern eine Berichtigung** – schwächer war es schon vorher, nur stand es nicht da |
+| **E7** | Bleibt der Ersatzsatz aus D-50 stehen? | **Nein, er wird berichtigt.** Er sagt heute „Kein Ersatz je Skill – und das ist die Aussage". Ab jetzt gibt es einen, für sieben von zwölf Skills, mit drei Grenzen | D-50 wird in seinem Kern **bestätigt** (ein Feld verschwindet nicht unbenannt) und in seinem Befund überholt. Der Decision Record muss beides sagen |
+| **E8** | Wird das in **einem** Release umgesetzt oder getrennt? | **Ein Release.** Abbildung, Prüfung, Matrixzeile und M1 gehören zusammen; getrennt entstünde ein Zwischenstand, in dem die Zeile mehr verspricht als die Abbildung leistet | Das Release wird größer als 0.34.0 in der Dokumentation, aber kleiner im Code |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle acht Fragen wie vorgelegt.** E1 S3 wird `[TECHNISCH]` mit drei benannten Grenzen; E2 die Werkzeugnamen kommen aus `hook_tools`; E3 befehlsgenaue Verbote werden **nicht** abgebildet und ihre Nicht-Abbildung deklariert; E4 `permissions.allow` wird **nicht** auf `allowed-tools` abgebildet; E5 eine Prüfung weist Argumentmuster ab; E6 M1 wird an die Turngrenze angeglichen; E7 der Ersatzsatz aus D-50 wird berichtigt; E8 ein Release |
+| Datum | 2026-09-13 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-64 (S3 ist zurückgewonnen, mit drei Grenzen), D-65 (die Abbildung von `permissions.deny`, und was bewusst unabgebildet bleibt), D-66 (ein Argumentmuster in `disallowed-tools` wird abgewiesen) |
+| Auflagen | **Die Turngrenze gehört in jede der drei Stellen** – Matrixzeile, Arbeitsmodell, Grenzfalltabelle – und nicht nur in eine. **Die fünf nicht abgebildeten Skills werden im Client Pack namentlich genannt**, nicht als Zahl: Eine Zahl ohne Namen ist in diesem Projekt schon dreimal gedriftet. **Und die Auflage hat beim ersten Lauf gegriffen:** Beim Nachzählen an der erzeugten Fassung waren es nicht „fünf ohne Schranke", wie dieser Antrag ursprünglich schrieb, sondern **drei ohne und zwei mit einer teilweisen**. Die Entscheidung E3 ändert das nicht; der Text ist berichtigt. **Die Prüfung misst die erzeugte Fassung, nicht die Quelle** – B01 ist genau daran vorbeigekommen, dass die Quelle mehr sagte als die Installation trug. **Beim Anfassen aufgefallen und mitzuberichten:** `skill_frontmatter.tool_names` bildet `edit` auf `Edit, Write` ab, `hook_tools.write` auf `Edit, Write, NotebookEdit` – **zwei Listen für dieselbe Sache, auseinandergelaufen.** Die neue Abbildung nimmt `hook_tools` (E2); `allowed-tools` bleibt unverändert, und der Unterschied wird im Protokoll benannt statt still geheilt |
+| Ziel-Release | `0.35.0` |
+| Umsetzung | umgesetzt mit `0.35.0` |

package/.koolie/core/governance/change-requests/CR-2026-058-unteragent-reichweite.md

@@ -0,0 +1,203 @@
+# Änderungsantrag `CR-2026-058`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Unteragent ist erhoben – die Skill-Sperre reicht hinein, A1 steht nicht mehr auf reinem `[DOK]`, und das Startwerkzeug kennt kein Manifest |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-13 |
+| Betroffene Artefakte | `clients/claude-code/CLIENT_PACK.md` (Zeilen **S3**, **A1**, **H2**), `clients/claude-code/manifest.json` und `clients/devin-desktop/manifest.json` (neues Feld), `clients/_template/CLIENT_PACK.md` und `clients/README.md` (Vorlage), `framework/core/05-working-model.md` (M1 und die Regel zu Hintergrund-Subagenten), `tests/scripts/validate-framework.py` (Prüfung 32 erweitert, Prüfung 34 neu), `tests/scripts/probe-pruefungen.py`, `tests/EDGE_CASES.md`, `clients/README.md` (Befund 6) |
+| Ebene laut Entscheidungsbaum 6 | **Client Pack** (Matrix, Manifest) und **Core** (die Aussage zum Arbeitsmodell) |
+| Art | Offener Punkt aus `CR-2026-057` und Eintrag in **Paket 6**; **erhoben am 2026-09-13**, zwölf Läufe, davon sechs Kontroll- und Entlastungsläufe |
+| Dringlichkeit | **Paket 6.** Kein P1: Alle drei Befunde fallen **zugunsten** der Durchsetzung aus. Der Antrag holt Belege nach und schließt eine Deklarationslücke; er behebt keine Fehlfunktion |
+
+## 1. Anlass und Befundlage
+
+Die Erhebung liegt vor: `tests/protocols/2026-09-13-erhebung-unteragent.md`. Aufbau wie bei
+`CR-2026-057` – ohne Regeltexte, ohne Bypass, mit `allow`-Liste und Rekorder-Hook.
+
+Drei Fragen an denselben Gegenstand, jede seit Längerem benannt:
+
+| Frage | Seit wann offen |
+|---|---|
+| Gilt `disallowed-tools` eines Skills auch für einen Unteragenten, den der Skill startet? | **Dreimal benannt** – im Protokoll zu `CR-2026-057` („für M1 wäre genau das die nächste Frage"), in `docs/ROADMAP.md` und in der Übergabe |
+| Beschränkt das Profilfeld `tools` technisch? | Zeile **A1** sagt es seit **0.7.0** auf `[TECHNISCH]` zu – **auf reinem `[DOK]`-Beleg** |
+| Erfasst der Schutz-Hook die Werkzeugaufrufe eines Unteragenten, und blockiert er sie? | Nie gestellt |
+
+### 1.1 Der harte Marker – warum diese Erhebung überhaupt zuordnen kann
+
+Ein Werkzeugaufruf **aus einem Unteragenten** trägt im Umschlag zwei Felder, die der Aufruf
+des Hauptagenten nicht trägt: **`agent_id` und `agent_type`** (Profilname). Jede Zuordnung
+„dieser Aufruf kam aus dem Unteragenten" stützt sich darauf und nicht auf den Bericht des
+Agenten – dieselbe Rolle, die `permission_denials` bei `CR-2026-057` gespielt hat.
+
+### 1.2 Befund 1: Die Skill-Sperre reicht in den Unteragenten
+
+| Lauf | Aufbau | Ergebnis |
+|---|---|---|
+| **V-M** | Skill mit `disallowed-tools: Write, Edit` startet das Profil `lw-unter-offen` – **ohne eigenes `tools`-Feld** | `Write` und `Edit` fehlten im Vorrat des Unteragenten; `ToolSearch select:Write` ergab wörtlich „No matching deferred tools found" |
+| **V-K** | **Kontrolllauf:** derselbe Skill **ohne** das Feld | Unteragent rief `Write` auf, Datei entstand |
+
+**Der Unteragent ist kein Umgehungsweg.** Die Entfernung gilt für den ganzen Turn, und der
+Unteragent läuft innerhalb dieses Turns. Die Turngrenze aus D-64 bleibt unberührt.
+
+**Grenze 2 aus D-64 reicht allerdings mit:** Mit gesperrtem `Write, Edit` schrieb der
+Unteragent über `Bash` (Lauf **V-E**, Kontrolle **V-EK**). Wer `exec` nicht sperrt, hat den
+Unteragenten nicht schmaler gemacht als den Hauptagenten.
+
+### 1.3 Befund 2: Das Profilfeld beschränkt – durch Entfernung, nicht durch Verweigerung
+
+| Lauf | Aufbau | Ergebnis |
+|---|---|---|
+| **A1-M** | Profil mit `tools: Read, Grep, Glob` | kein Schreibwerkzeug im Vorrat; **`permission_denials` leer** |
+| **A1-K** | **Kontrolllauf:** dasselbe ohne `tools` | `Write` gelang |
+
+Derselbe Mechanismus wie `disallowed-tools`: **Entfernung aus dem Vorrat, keine
+Berechtigungsregel.** Eine `allow`-Regel holt das Werkzeug nicht zurück.
+
+**Was A1 zusätzlich behauptet, ist weiterhin nur dokumentiert:** dass ein Profil, dessen
+`tools`-Liste sich zu keinem Werkzeug auflöst, gar nicht erst startet. Nicht gemessen.
+
+### 1.4 Befund 3: Der Schutz-Hook erfasst und blockiert den Unteragenten
+
+Der Rekorder allein belegt nur, dass der Hook **aufgerufen** wird – nicht, dass er
+**entscheidet**. Dieselbe Unterscheidung, an der die Roadmap für 0.30.0 einen Nachweis
+vermisst. Deshalb ein Hook mit Exit 2:
+
+| Lauf | Aufbau | Ergebnis |
+|---|---|---|
+| **H1** | Sperr-Hook, Matcher `*` | **blockiert**, Datei nicht entstanden |
+| **H2** | **Gegenprobe im selben Aufbau**, anderes Ziel | Hook sieht denselben Aufruf, lässt durch, Datei entstand |
+| **H3** | derselbe Hook, Matcher `Edit\|Write\|NotebookEdit` – **die Form, die `clientmap.py` erzeugt** | **blockiert** |
+
+Ohne H3 wäre nur das Sternchen gemessen, und das erzeugt das Framework nirgends.
+
+**Die B06-Berichtigung trägt hier zum ersten Mal etwas.** `agent_id` und `agent_type` sind zwei
+Umschlagfelder, die kein aufgezeichnetes Schema kannte. Ein Hook, der wie bis 0.33.0 „alle
+Zeichenketten des Ereignisses" durchsucht, hätte sie mitgeprüft. Seit 0.34.0 wird
+ausschließlich `tool_input` geprüft (D-62) – **eine additive Erweiterung des Clients erreicht
+die Entscheidung nicht mehr.**
+
+### 1.5 Befund 4: Das Startwerkzeug kennt kein Manifest
+
+Gemessen ist, dass es **sperrbar** ist: `disallowed-tools: Agent` weist den Start ab (Lauf
+**V-S**), und `disallowed-tools: Task` ebenso (Lauf **V-S2**) – kein stiller Ausfall wie bei
+den Argumentmustern aus D-66.
+
+**Aber die Kanäle nennen es verschieden**, in derselben Sitzung, für denselben Aufruf:
+
+| Kanal | Name |
+|---|---|
+| Frontmatter `disallowed-tools` | akzeptiert **beide** |
+| Umschlag des Hooks (`tool_name`) | `Agent` |
+| `permission_denials` | **`Task`** |
+
+Und in **keiner** Werkzeugliste des Manifests steht es: nicht in `hook_tools`, nicht in
+`permission_tools`, nicht in `agent_frontmatter.tool_names`. **Ein Kanal ohne Deklaration** –
+und genau das hat sich dieses Projekt mit D-47 (`hook_tools_absent`) abgewöhnt.
+
+### 1.6 Befund 5: Prüfung 32 behauptet eine Vollständigkeit, die es nicht mehr gibt
+
+Der Kopfkommentar sagt, sie rufe den Hook „mit dem vollständigen Umschlag **beider**
+aufgezeichneter Schemata" auf. Es sind jetzt **drei** aufgezeichnete Formen: die zwei aus den
+AP2-Mitschriften und der Unteragenten-Umschlag mit zwei zusätzlichen Feldern.
+
+**Das ist keine Risikobehauptung.** Weder `agent_id` noch `agent_type` trägt heute einen Pfad.
+Der Grund ist ein anderer: Eine Prüfung, die ihre Grundlage benennt, darf sie nicht überholt
+tragen – sonst ist sie die nächste Aussage, die ihren Gegenstand überlebt hat.
+
+### 1.7 Befund 6: Sieben überholte Angaben in Übersichten, die nichts nachrechnet
+
+**Beim Nachzählen für Zeile A1 aufgefallen, nicht gesucht.** Prüfung 31 rechnet die
+Zusammenfassung **im Pack** nach – seit 0.33.0, und dort stimmt sie. Daneben stehen dieselben
+Zahlen ein zweites Mal, und **dort rechnet sie niemand**:
+
+| Stelle | Steht da | Gezählt |
+|---|---|---|
+| `clients/README.md`, `devin-desktop` | `[TECHNISCH]` **24 von 34** | **20 von 36** |
+| `clients/README.md`, `devin-desktop` | „**8** Zeilen tragen einen VERIFY-Marker" | **9** |
+| `clients/README.md`, `claude-code` | `[TECHNISCH]` **25 von 29** | **22 von 31** |
+| `clients/README.md`, `claude-code` | „die Wirkungsnachweise aus einer Sitzung stehen aus" | überholt – S4 beobachtet am 12.09., S3 gemessen am 13.09. |
+| `claude-code/CLIENT_PACK.md`, Belegstand | „(bei `devin-desktop`: **8 von 34**)" | **9 von 36** |
+| `claude-code/CLIENT_PACK.md`, Belegstand | „beobachtete Durchsetzung … ist für **keine** Zeile belegt" | überholt, dieselben zwei Zeilen |
+| `devin-desktop/CLIENT_PACK.md`, Belegstand | „**8 der 36** Zeilen tragen einen offenen VERIFY-Marker – S3, B3, A1 und X2 unmittelbar" | **9** – **B10 fehlt in der Aufzählung**, es trägt seit 0.33.0 einen Marker |
+
+**„25 von 29" ist besonders unangenehm:** Das Pack selbst schreibt einen Absatz darüber, dass
+diese Zahl bis 0.32.0 falsch war und berichtigt wurde. **Die Berichtigung hat die zweite Stelle
+nicht erreicht.**
+
+> **Und die Zählung war wieder zu klein.** Der erste Durchgang fand zwei Angaben, der zweite
+> vier, der dritte sieben. Das ist der Befund, den dieses Projekt am häufigsten an sich selbst
+> macht – hier zum sechsten Mal in Folge.
+
+### 1.8 Befund 7, methodisch: Der Gegenstand der Messung wählt seinen Weg selbst
+
+In Lauf **V-M** griff der Unteragent von sich aus zu `PowerShell` – einem Werkzeug, das in
+dieser Umgebung ohnehin nicht schreiben kann. Er meldete eine Verweigerung, und der Lauf sah
+aus wie „die Sperre schließt auch den Shell-Weg".
+
+**Lauf V-PK entlastet die Sperre:** dieselbe Verweigerung, wörtlich dieselbe Meldung, **ohne
+jeden Skill**. Und Lauf V-E zeigt den `Bash`-Weg offen.
+
+> Wer V-M allein ausgewertet hätte, hätte einen Positivbefund ins Protokoll geschrieben, den
+> zwei Läufe desselben Tages widerlegen. **Die Sonde muss das Werkzeug vorschreiben** – sonst
+> misst man die Wahl des Agenten mit, und die ist kein Mechanismus.
+
+## 2. Was heute im Repositorium steht
+
+| Stelle | Heutiger Stand | Warum das nicht bleiben kann |
+|---|---|---|
+| Zeile **S3** | drei Grenzen, keine Aussage zur Reichweite | Die naheliegende Frage – „gilt das auch eine Ebene tiefer?" – bleibt unbeantwortet, obwohl sie jetzt beantwortet ist |
+| Zeile **A1** | `[TECHNISCH]`, Beleg `[DOK] docs/en/sub-agents` | Die Bauform, an der `AP2-CC-13` acht Releases hing und B01 gescheitert ist |
+| Zeile **H2** | „Exit-Code 2 blockiert", ohne Reichweite | Dass das auch für einen Unteragenten gilt, war nie gesagt und nie gemessen |
+| `manifest.json` beider Packs | kein Feld für das Startwerkzeug | Ein Kanal, den keine Liste kennt und keine Prüfung erzwingt |
+| Prüfung 32, Kopfkommentar | „beider aufgezeichneter Schemata" | Überholt, siehe 1.6 |
+| `05-working-model.md` | „Hintergrund-Subagenten DÜRFEN NICHT für M3 verwendet werden" | Technisch ist nur das Startwerkzeug **ganz** sperrbar. `run_in_background` ist ein Argument, und Argumentmuster wirken nach D-66 lautlos gar nicht |
+
+## 3. Vorgeschlagene Änderung
+
+1. **Zeile S3** bekommt einen Abschnitt **Reichweite**: Die Sperre gilt auch für einen
+   Unteragenten, den der Skill startet – und Grenze 2 reicht mit.
+2. **Zeile A1** bekommt den Messbeleg; der nicht gemessene Teilsatz bleibt ausdrücklich `[DOK]`.
+3. **Zeile H2** bekommt die gemessene Reichweite, einschließlich des benannten Matchers.
+4. **Neues Manifestfeld `agent_start_tools`**, Bauart wie `hook_tools_absent` (D-47): Ein Pack
+   nennt die Werkzeugnamen oder erklärt in `agent_start_tools_absent`, warum es keine nennt.
+5. **Prüfung 34 (neu):** Jedes Pack tut eines von beidem. Ein Pack, das **A1** zusagt, muss
+   nennen statt erklären.
+6. **Prüfung 32** bekommt einen fünften Gegenstand: den Unteragenten-Umschlag.
+7. **`05-working-model.md`:** M1 nennt den gemessenen Stand; die Regel zu Hintergrund-Subagenten
+   sagt, dass sie normativ ist und warum sie es bleiben muss.
+8. **`EDGE_CASES.md`:** ein Grenzfall „Ein Skill startet einen Unteragenten".
+
+## 4. Auswirkungen
+
+- **Keine Einstufung ändert sich.** S3 und A1 bleiben `[TECHNISCH]`, H2 bleibt `[TECHNISCH]`.
+  Die Summen der Zusammenfassung bleiben unverändert – Prüfung 31 rechnet sie ohnehin nach.
+- **Zwei Belege wandern von `[DOK]` auf gemessen** (A1 ganz, H2 in der Reichweite).
+- **Jedes künftige Client Pack** muss `agent_start_tools` füllen oder seine Abwesenheit
+  erklären. Das ist der Preis von E2 und steht dort.
+- **`devin-desktop` erklärt die Abwesenheit mit dem Grund „unerhoben"** – nicht mit „gibt es
+  nicht". Das Pack führt Subagenten als Vorschaufunktion (`QD-14`); gemessen ist dort nichts.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | Wie wird die Reichweite in der Matrix untergebracht – als Abschnitt in **S3** oder als eigene Zeile **A2**? | **Als Reichweite in S3.** Es ist dieselbe Zusage, eine Ebene tiefer, und keine zweite | S3 ist schon die längste Zeile der Matrix und wird länger. Der Gegenvorschlag wäre lesbarer – und erzeugte **zwei Stellen für dieselbe Sache**, die auseinanderlaufen können. Genau der Befundtyp dieses Projekts, zuletzt bei `tool_names`/`hook_tools`. **Deshalb verworfen** |
+| **E2** | Was folgt daraus, dass das Startwerkzeug in keiner Werkzeugliste steht? | **Neues Manifestfeld plus Prüfung 34.** Ein Pack nennt es oder erklärt seine Abwesenheit, Bauart wie `hook_tools_absent` (D-47) | Ein weiteres Feld, das jedes künftige Pack füllen muss. Die billigere Alternative – nur eine `_note` – ließe einen Kanal ohne durchgesetzte Deklaration, und das Verschweigen von Abwesenheit ist das, was D-47 abgestellt hat |
+| **E3** | Wird Prüfung 32 um den dritten Umschlag erweitert? | **Ja.** Begründung ist **nicht** ein akuter Fund – beide Felder tragen keinen Pfad –, sondern dass die Prüfung eine Vollständigkeit benennt, die die Messung widerlegt hat | Die Prüfung wird länger für einen Fall, der heute nichts fängt. **Die Begründung gehört so ins Protokoll**, nicht als Risikobehauptung; sonst ist der Nachweis selbst eine Überzeichnung |
+| **E4** | Bleibt die Regel „keine Hintergrund-Subagenten für M3" bestehen, obwohl sie technisch nicht abbildbar ist? | **Ja, und sie sagt es.** Sperrbar ist nur das Startwerkzeug **ganz**; „nur Hintergrund" ist ein Argument, und Argumentmuster wirken nach D-66 lautlos gar nicht | Eine Kernregel bekommt einen Satz, der sie schwächer aussehen lässt. **Sie war es schon** – neu ist nur, dass es dasteht |
+| **E5** | Wird der Teilsatz in A1 („ein Profil ohne auflösbares Werkzeug startet nicht") mitgemessen oder bleibt er `[DOK]`? | **Bleibt `[DOK]`, ausdrücklich.** Er ist nicht gemessen | Die Zeile trägt zwei Belegarten und liest sich unruhiger. Das ist genauer als eine Zeile, die einen Messbeleg über eine nicht gemessene Aussage spannt |
+| **E7** | Was geschieht mit den Zahlen in `clients/README.md`? | **Die `[TECHNISCH]`-Zahl wird von Prüfung 31 mitgerechnet; die VERIFY-Zahl entfällt dort und verweist auf das Pack.** Die erste hat eine eindeutige Grenze und gehört ausgerechnet; die zweite hat sie nur zur Hälfte – die unmittelbaren Marker sind zählbar, die „über den Verweis" mitgezählten sind Ermessen | Die Übersicht verliert eine Angabe und wird an einer Stelle unschärfer. **Der Preis ist richtig herum:** Eine gepflegte Zahl, die niemand nachrechnet, ist in diesem Projekt fünfmal gedriftet. Die Alternative – auch die VERIFY-Zahl erzwingen – müsste eine Ermessensgrenze als Arithmetik ausgeben |
+| **E6** | Ein Release oder getrennt? | **Ein Release, `0.36.0`.** Matrix, Manifest, Prüfungen und Kern gehören zusammen | Getrennt entstünde ein Zwischenstand, in dem die Matrix eine Reichweite zusagt, die keine Prüfung deckt |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle sechs Fragen wie vorgelegt.** E1 Reichweite in S3, keine zweite Zeile; E2 neues Manifestfeld `agent_start_tools` plus Prüfung 34; E3 Prüfung 32 wird um den Unteragenten-Umschlag erweitert, mit der Begründung aus 1.6 und nicht mit einer Risikobehauptung; E4 die Regel zu Hintergrund-Subagenten bleibt und weist ihre Nichtabbildbarkeit aus; E5 der nicht gemessene Teilsatz in A1 bleibt `[DOK]`; E6 ein Release; E7 die `[TECHNISCH]`-Zahl in `clients/README.md` wird nachgerechnet, die VERIFY-Zahl entfällt dort |
+| Datum | 2026-09-13 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-67 (die Skill-Sperre reicht in den Unteragenten, und Grenze 2 reicht mit), D-68 (A1 ist gemessen; die Beschränkung ist eine Entfernung, keine Verweigerung), D-69 (der Schutz-Hook erfasst und blockiert den Unteragenten, auch mit dem erzeugten Matcher), D-70 (das Startwerkzeug wird deklariert oder seine Abwesenheit erklärt), D-71 (eine Zahl mit eindeutiger Grenze wird überall ausgerechnet, nicht an zweiter Stelle gepflegt) |
+| Auflagen | **Der nicht gemessene Teil bleibt in jeder der drei Zeilen als solcher kenntlich** – A1 (Startabbruch bei leerer Werkzeugliste), H2 (kein Lauf mit dem Schutz-Hook des Frameworks in einer vollständigen Installation), S3 (Hintergrund-Unteragenten und zwei Ebenen tief sind nicht gemessen). **Die Begründung für E3 wird nicht zur Risikobehauptung aufgewertet.** **`devin-desktop` erklärt die Abwesenheit mit „unerhoben", nicht mit „gibt es nicht"** – das Pack führt Subagenten als Vorschaufunktion. **Und der methodische Befund aus 1.7 gehört in die Sondenbeschreibung**, nicht nur ins Protokoll: Eine Sonde, die den Weg offenlässt, misst die Wahl des Agenten mit |
+| Ziel-Release | `0.36.0` |
+| Umsetzung | umgesetzt mit `0.36.0` |