@renoxar/koolie 1.25.0

package/.koolie/core/tests/protocols/2026-09-13-wirkungsnachweise-0.33.0.md

@@ -0,0 +1,169 @@
+# Wirkungsnachweise zu Release 0.33.0
+
+| Feld | Wert |
+|---|---|
+| Gegenstand | Die Umsetzungen zu `CR-2026-054` (D-57, D-58, Befund **B08**) und `CR-2026-055` (D-59, D-60, Befund **B11**) |
+| Datum | 2026-09-13 |
+| Framework-Version | 0.33.0 (gegen 0.32.0 = `a950c35`) |
+| Prüfmethode | `probe-pruefungen.py` gegen beide Stände und in **beiden** Kodierungsumgebungen; dazu ein Validatorlauf des neuen Prüfsatzes gegen den unveränderten Vorstand und zwei erzeugte Installationen je Pack |
+| Umgebung | Windows 11, Python 3.14.4 |
+| Ergebnis | **97 Sonden und Gegenproben bestehen gegen 0.33.0 in beiden Umgebungen.** Der neue Prüfsatz meldet gegen 0.32.0 **sechs** Fundstellen – fünf davon Prüfung 31 in den unveränderten Client Packs |
+
+## 1. Was hier nachgewiesen wird
+
+| Gegenstand | Art | Nachweis |
+|---|---|---|
+| Kandidatenprüfung `--check-overlay-ready` | neuer Prüfpfad | drei Sonden, eine Gegenprobe – **je Pack** |
+| Status-Hook nach dem Umbau | geändertes Skript | drei Sonden, eine Gegenprobe – **je Pack** |
+| Fetch-Allow-Verbot aus dem Manifest | geänderte Prüfung | eine Sonde, eine Gegenprobe – **je Pack** |
+| Prüfung 31 (Summen der Fachmatrix) | neue Prüfung | vier Sonden, eine Gegenprobe |
+| Rückzug der Domain-Zusage | Textkorrektur an fünf Stellen | **keine Sonde** – siehe Abschnitt 5 |
+| Zählregel und berichtigte Summen | Textkorrektur | über Prüfung 31 mitgeprüft |
+
+**Je Pack, nicht einmal.** B02 war nicht, dass eine Prüfung falsch prüft, sondern dass sie einen
+Client **gar nicht sieht**. Das fällt nur auf, wenn derselbe Fall in jeder Installation läuft – die
+Kandidatenprüfung, der Hook und das Fetch-Allow-Verbot laufen deshalb gegen zwei frische
+Installationen.
+
+## 2. Die Sonden
+
+### 2.1 Kandidatenprüfung (je Pack)
+
+| Sonde | Präparation | Erwartete Meldung |
+|---|---|---|
+| CR-1 | Status an allen Stellen `aktiv` | „ist bereits 'aktiv'“ – mit Verweis auf `--strict-overlay` |
+| CR-2 | Laufzeitregel `aktiv`, Quell-Overlay `inaktiv` | „widersprechen sich“ |
+| CR-3 | Status als offener Platzhalter | „nicht ausgefuellt“ |
+
+**Gegenprobe CR:** Ein vollständig ausgefüllter Kandidat mit Status `inaktiv` an allen Stellen und
+platzhalterfreier Berechtigungsdatei **läuft durch**. Das ist hier die wichtigere Hälfte: Ohne sie
+stünde nur fest, dass irgendetwas gemeldet wird – und eine Prüfung, die alles meldet, besteht jede
+Sonde.
+
+### 2.2 Status-Hook (je Pack)
+
+| Sonde | Präparation | Erwartete Meldung |
+|---|---|---|
+| HS-1 | Laufzeitregel `aktivierung-ausstehend`, Overlay `aktiv` | `widerspruechlich` – **nicht** `aktiv` |
+| HS-2 | Laufzeitregel `inaktiv`, Overlay `aktiv` | `widerspruechlich` – nicht die erste gelesene Datei |
+| HS-3 | Nur die Steckbriefzeile, Laufzeitregel entfernt | `inaktiv` – die Tabellenform wird gelesen |
+
+**Gegenprobe HS:** Alle Angaben `aktiv` → Meldung `aktiv` **ohne** M1-Hinweis. Sie schließt aus,
+dass der Hook nach dem Umbau pauschal warnt.
+
+Jede der drei Sonden trifft genau einen der drei Defekte aus der Gegenprüfung. Vor 0.33.0 hätte
+HS-1 die Meldung `aktiv` erzeugt (Präfixvergleich), HS-2 ebenfalls (`break`), und HS-3 hätte
+`unbekannt` gemeldet (fehlende Tabellenform).
+
+### 2.3 Fetch-Allow aus dem Manifest (je Pack)
+
+| Sonde | Präparation | Erwartete Meldung |
+|---|---|---|
+| FA | `allow`-Regel `<Abrufwerkzeug des Packs>(domain:docs.example.invalid)` | „allow-Regel auf ein Abrufwerkzeug“ |
+
+Das Werkzeug kommt aus `permission_tools.fetch` des jeweiligen Manifests – bei `claude-code`
+`WebFetch`, bei `devin-desktop` `Fetch`. **Die zweite ist der eigentliche Nachweis:** Sie lief bis
+0.32.0 durch, weil die Namensliste nur `Fetch(*` kannte.
+
+**Gegenprobe FA:** Die ausgelieferte Regelmenge bleibt unbeanstandet – die Prüfung greift nur an
+`allow`, nicht an `deny`.
+
+### 2.4 Prüfung 31
+
+| Sonde | Präparation | Erwartete Meldung |
+|---|---|---|
+| 31a | Anzahl je Einstufung in der Zusammenfassung verfälscht | „Zeile(n) als [TECHNISCH]; gezaehlt sind“ |
+| 31b | Gesamtzahl der Matrixzeilen verfälscht | „Matrixzeilen; gezaehlt sind“ |
+| 31c | Überschrift der Zusammenfassung umbenannt | „kein Abschnitt '## 3. Zusammenfassung“ |
+| 31d | Matrixzeile ohne Einstufung eingefügt | „ohne Einstufung: Z9“ |
+
+**Gegenprobe 31:** Eine **zusätzliche** Matrixzeile samt nachgezogenen Summen bleibt unbeanstandet.
+Ohne sie wäre die Prüfung eine Bremse für jede neue Zeile statt einer Prüfung.
+
+31c ist die Sonde auf den **verlorenen Anker** – dieselbe Bauform wie 28c und 29c aus 0.32.0: Eine
+Konsistenzprüfung, die ihren Prüfgegenstand nicht mehr findet, besteht sonst leise.
+
+## 3. Der Gegenbeweis gegen den Vorstand
+
+Vorgehen wie bei 0.32.0: `git archive a950c35` in ein leeres Verzeichnis, dort mit **dem eigenen**
+`install.py` des Vorstands installiert, dann nur `validate-framework.py` und
+`overlay_status.py` aus 0.33.0 hineinkopiert.
+
+```
+FEHLER  …/tests/EDGE_CASES.md: Keine Grenzfallzeile verweist auf D-59
+FEHLER  …/clients/claude-code/CLIENT_PACK.md: nennt 25 Zeile(n) als [TECHNISCH]; gezaehlt sind 20
+FEHLER  …/clients/claude-code/CLIENT_PACK.md: nennt 3 Zeile(n) als [TEXTUELL]; gezaehlt sind 7
+FEHLER  …/clients/claude-code/CLIENT_PACK.md: nennt 1 Zeile(n) als [NICHT ABBILDBAR]; gezaehlt sind 2
+FEHLER  …/clients/devin-desktop/CLIENT_PACK.md: nennt 24 Zeile(n) als [TECHNISCH]; gezaehlt sind 19
+FEHLER  …/clients/devin-desktop/CLIENT_PACK.md: nennt 9 Zeile(n) als [TEXTUELL]; gezaehlt sind 14
+Ergebnis: 6 Fehler, 0 Warnungen
+```
+
+**Die erste Meldung stammt von Prüfung 30, nicht von 31**, und sie gehört dazu: Die
+Grenzfalltabelle des Vorstands kennt D-59 nicht, weil es die Entscheidung dort nicht gibt. Prüfung
+30 hält damit auch die **neue** Entscheidung an ihre Grenzfalltabelle gebunden – sie war dafür
+gebaut (0.32.0) und bewährt sich beim ersten Anwendungsfall.
+
+Gegen 0.33.0 im selben Prüfsatz: **0 Fehler, 0 Warnungen.**
+
+**Prüfung 31 findet den Nebenbefund im unveränderten Vorstand von selbst** – einschließlich der
+Angabe „1 von 29“ für `[NICHT ABBILDBAR]`, wo seit 0.31.0 zwei Zeilen dort stehen. Der Drift war
+zwei Releases alt und hat den Wirkungsnachweis beider Releases überlebt.
+
+**Für die Kandidatenprüfung, den Hook und das Fetch-Allow-Verbot gibt es keinen solchen
+Gegenbeweis**, und das hat einen Grund: Alle drei sind **Verhaltensänderungen**, nicht Prüfungen auf
+den Bestand. Ihr Gegenbeweis steckt in den Sonden selbst – jede beschreibt einen Fall, der vor
+0.33.0 anders ausgegangen wäre, und Abschnitt 2.2 nennt je Sonde, wie.
+
+## 4. Eine Sonde hat die eigene Umsetzung gefangen
+
+Beim Umbau von `check_strict_overlay` auf die gemeinsame Auswertung meldete die Funktion nur noch
+den **ausgewerteten** Status:
+
+```
+Overlay-Status ist nicht 'aktiv', sondern 'unbekannt' (…)
+```
+
+Der Rohwert fiel weg. Die Sonde zu D-44 – sie sucht wörtlich nach `sondern
+'aktivierung-ausstehend'`, dem Wert, der den Befund 2026-09-12 ausgelöst hat – **fiel bei beiden
+Packs sofort**. Die Meldung nennt jetzt zuerst die Rohwerte, dann die Auswertung.
+
+**Das ist der Zweck dieser Sonden, an einem Fall, der nicht geplant war.** Ohne sie wäre die
+Meldung stiller geworden, und der Sondenlauf wäre grün geblieben – der Wert, den zu nennen der
+ganze Punkt von D-44 war, hätte in keiner Ausgabe mehr gestanden.
+
+## 5. Was dieses Release nicht nachweist
+
+- **Der Rückzug der Domain-Zusage hat keine Sonde**, und zwar bewusst: Es ist eine Textkorrektur an
+  fünf Stellen, und eine Prüfung, die eine Formulierung bewacht, meldet jede Umformulierung und
+  sonst nichts. Belegt ist der Befund – in der Gegenprüfung, an zwei erzeugten Installationen.
+- **Kein Lauf gegen einen Client.** Dass ein Client eine Domain-Angabe auswertet oder nicht, ist
+  für `devin-desktop` **unerhoben**; Zeile B10 trägt dort `[TEXTUELL]` mit VERIFY-Marker. Widerlegt
+  ist nur, dass sie gegen ein bestehendes `deny` wirken könnte – Mechanik, nicht Messung.
+- **Kein vollständiger Übernahmelauf.** Dass der berichtigte Ablauf – Kandidatenprüfung,
+  Aktivierung durch den Menschen, Nachprüfung – in einem fremden Projekt ohne Regelbruch durchläuft,
+  ist an Installationen geprüft, nicht an einer echten Übernahme. Der Pilot steht auf 0.29.0 und
+  hat seinen Ablauf hinter sich.
+- **Der Hook bleibt eine Meldung.** Ob ein KI-Client den M1-Hinweis befolgt, ist nicht gemessen und
+  durch diesen Mechanismus auch nicht messbar; der Hook blockiert nie.
+- **Prüfung 31 prüft die Arithmetik, nicht die Einstufung.** Eine Matrix, in der jede Zeile falsch
+  eingestuft ist, besteht sie. Die Einstufung selbst belegt nur eine Erhebung an einer Installation.
+- **Die Zählregel ist eine Entscheidung, kein Messwert** (D-60). Sie steht an drei Stellen gleich:
+  in beiden Packs und in Prüfung 31.
+
+## 6. Der Lauf in beiden Kodierungsumgebungen
+
+| Umgebung | Sonden und Gegenproben | Ergebnis |
+|---|---|---|
+| ohne `PYTHONIOENCODING` | 97 | alle bestanden |
+| mit `PYTHONIOENCODING=utf-8` | 97 | alle bestanden |
+
+97 = 72 aus 0.32.0 plus 25 neue, und zwar **18 Sonden und 7 Gegenproben**: Kandidatenprüfung,
+Status-Hook und Fetch-Allow je Pack (je 3+1, 3+1 und 1+1 – zusammen zwanzig), dazu 4+1 für
+Prüfung 31. Ausgezählt aus dem Lauf: 65 Sonden, 32 Gegenproben. Der Validator meldet in beiden Umgebungen 0 Fehler und 0 Warnungen.
+
+## 7. Gegenzeichnung
+
+| Rolle | Name/Kennung | Datum | Ergebnis bestätigt |
+|---|---|---|---|
+| `<FRAMEWORK_OWNER>` | `<TBD>` | `<TBD>` | `<TBD>` |

package/.koolie/core/tests/protocols/2026-09-13-wirkungsnachweise-0.34.0.md

@@ -0,0 +1,187 @@
+# Wirkungsnachweise zu Release 0.34.0
+
+| Feld | Wert |
+|---|---|
+| Gegenstand | Die Umsetzung zu `CR-2026-056` (D-61, D-62, D-63, Befund **B06**) – Eingabeschema, Prüfmaterial und Pfadidentität des Schutz-Hooks |
+| Datum | 2026-09-13 |
+| Framework-Version | 0.34.0 (gegen 0.33.0 = `22d0fcb`) |
+| Prüfmethode | `probe-pruefungen.py` in **beiden** Kodierungsumgebungen; dazu der Validatorlauf des neuen Prüfsatzes gegen den unveränderten Vorstand, zweimal – einmal wie ausgeliefert und einmal mit neutralisiertem Ankertest |
+| Umgebung | Windows 11, Python 3.14.4, NTFS |
+| Ergebnis | **104 Sonden und Gegenproben bestehen gegen 0.34.0 in beiden Umgebungen** (71 Sonden, 33 Gegenproben). Validator: 0 Fehler, 0 Warnungen. Gegen den Vorstand meldet Prüfung 32 **zuerst ihren eigenen Anker**; erst mit neutralisiertem Ankertest misst sie durch und nennt **17 Fundstellen** |
+
+## 1. Was hier nachgewiesen wird
+
+| Gegenstand | Art | Nachweis |
+|---|---|---|
+| Ereignisschema mit `unprüfbar` als drittem Ausgang (D-61) | neuer Mechanismus | Sonde 32b; in Prüfung 32 zehn Eingabeformen |
+| Prüfung der Operation statt des Umschlags (D-62) | **Verhaltensänderung** | Sonde 32c; in Prüfung 32 der Vergleich „mit und ohne Umschlag" je Pack |
+| Unbekannte Operation wird streng gemessen (`CR-2026-056` E2) | geänderter Rückfall | Sonde 32d |
+| Pfadidentität über den aufgelösten Pfad (D-63) | neuer Mechanismus | Sonde 32a; in Prüfung 32 vier Pfadvarianten je Pack |
+| Schreibungsunempfindlichkeit aller Pfadmuster (D-63) | geänderte Muster | Sonde 32e |
+| `hook_path_fields` aus den Manifesten (E6) | neues Manifestfeld | Gegenprobe 32 |
+| Prüfung 32 selbst | neue Prüfung | Sonde 32f (verlorener Anker) |
+| Berichtigung von Abschnitt 5 beider Packs (E9) | Textkorrektur | **keine Sonde** – siehe Abschnitt 5 |
+| Zeile H4 und die nachgezogenen Summen | Matrixzeile | über Prüfung 31 mitgeprüft |
+
+**Sechs Sonden für sechs Mechanismen, und keine über den naheliegenden Fall.** Bei
+`LEITWERK-CORE/VERSION` decken die Auflösung und `re.I` einander gegenseitig zu: Fällt einer von
+beiden aus, bestünde die Prüfung trotzdem. 32a und 32e treffen deshalb je einen Fall, den nur
+**ein** Mechanismus fängt – ein relativer Pfad, der den Kern gar nicht nennt, und eine
+Secret-Datei, die es nicht gibt und die `realpath` darum nicht kanonisieren kann.
+
+## 2. Die Sonden
+
+| Sonde | Präparation | Erwartete Meldung |
+|---|---|---|
+| 32a | Die Pfadauflösung liefert nichts – die Muster sehen nur den Rohtext | „ohne es zu nennen" |
+| 32b | Eine leere Eingabe gilt wieder als harmloses Ereignis – der Stand bis 0.33.0 | „ist kein Werkzeugereignis" |
+| 32c | Der Umschlag wandert zurück ins Prüfmaterial – der Stand bis 0.33.0 | „je nachdem ob der Umschlag" |
+| 32d | Eine unbekannte Operation gilt wieder als lesend statt als die strengste | „unbekanntes Werkzeug in das Kernverzeichnis" |
+| 32e | Das Secret-Muster für `.env` wird wieder schreibungssensitiv | „wenn die Datei nicht existiert" |
+| 32f | Der Suchtext, über den Prüfung 32 ihren Gegenstand findet, geht verloren | „'def ereignis_lesen(' fehlt" |
+
+**Gegenprobe 32:** Ein **zusätzliches** Pfadfeld in beiden Manifesten bleibt unbeanstandet. Sie ist
+hier die wichtigere Hälfte: `hook_path_fields` ist über alle Packs vereinigt, und ein zusätzlich
+erkanntes Feld ist eine Verschärfung (D-28). Ohne diese Gegenprobe stünde nur fest, dass Prüfung 32
+etwas meldet – und eine Prüfung, die jede Manifestergänzung beanstandet, wäre eine Bremse statt
+einer Schranke.
+
+32f ist die **Sonde auf den verlorenen Anker**, dieselbe Bauform wie 28c, 29c und 31c. Sie wiegt in
+diesem Release schwerer als sonst, denn im Gegenbeweis ist genau dieser Fall eingetreten – siehe
+Abschnitt 3.
+
+## 3. Der Gegenbeweis gegen den Vorstand
+
+Vorgehen wie bei 0.32.0 und 0.33.0: `git archive 22d0fcb` in ein leeres Verzeichnis, dort mit
+**dem eigenen** `install.py` des Vorstands installiert (nach `--dry-run`), dann nur
+`validate-framework.py` aus 0.34.0 hineinkopiert.
+
+### 3.1 Wie ausgeliefert – drei Fehler, und Prüfung 32 misst ihre Sache gar nicht
+
+```
+FEHLER  …/tests/EDGE_CASES.md: Keine Grenzfallzeile verweist auf D-61
+FEHLER  …/tests/EDGE_CASES.md: Keine Grenzfallzeile verweist auf D-63
+FEHLER  …/tests/scripts/hook-check-secrets.py: 'def ereignis_lesen(' fehlt. Pruefung 32
+        misst Eingabeschema und Pfadidentitaet des Hooks; ohne diese Stufen prueft sie
+        einen Aufbau, den es nicht mehr gibt, und bestuende leise (D-23, CR-2026-056)
+Ergebnis: 3 Fehler, 1 Warnungen
+```
+
+Die ersten beiden stammen von **Prüfung 30** und gehören dazu: Die Grenzfalltabelle des Vorstands
+kennt D-61 und D-63 nicht, weil es die Entscheidungen dort nicht gibt. Dasselbe hat 0.33.0 mit D-59
+gezeigt.
+
+Die dritte ist **Prüfung 32, die sich selbst anhält.** Der Hook des Vorstands kennt die drei Stufen
+nicht; die Prüfung stellt das fest und **bricht ab, statt leise zu bestehen**. Das ist die Wirkung,
+für die die Ankersonde gebaut ist, und sie tritt beim ersten Anwendungsfall ein. Es ist aber
+**keine Messung der zwölf Fälle** – und dieser Unterschied ist der Grund für den zweiten Lauf.
+
+### 3.2 Mit neutralisiertem Ankertest – siebzehn Fundstellen
+
+Nur für die Messung, und nur in der Kopie im Arbeitsverzeichnis, wurde der Ankerblock entfernt.
+Dann misst Prüfung 32 durch:
+
+| Gruppe | Anzahl | Was |
+|---|---|---|
+| Eingabeformen | **10** | leer, nur Weißraum, `[]`, `null`, `"x"`, `42`, ohne `tool_name`, leerer `tool_name`, ohne `tool_input`, `tool_input` als Zeichenkette – sämtlich mit **Exit 0** trotz `--fail-closed` |
+| `claude-code` | **4** | der Umschlag entscheidet mit (Exit 0 ohne, **Exit 2 mit**); unbekanntes Werkzeug schreibt in den Kern; Secret-Pfad in abweichender Schreibweise; ein Nachbarverzeichnis wird blockiert |
+| `devin-desktop` | **3** | unbekanntes Werkzeug schreibt in den Kern; `LEITWERK-CORE/VERSION` wird anders entschieden als die Standardschreibweise; Secret-Pfad in abweichender Schreibweise |
+
+**Zusammen 17**, dazu die beiden aus Prüfung 30 – der Lauf meldet 19 Fehler.
+
+**Die vierte Zeile bei `claude-code` ist der P1-Befund selbst, von der Prüfung ausgesprochen:** Das
+Nachbarverzeichnis `leitwerk-core-notizen/x.txt` ist harmlos und wird trotzdem blockiert – nicht
+wegen seines Namens, sondern weil im Umschlag dieses Clients `transcript_path` steht. Beim Pack
+`devin-desktop` fehlt diese Zeile, und das ist kein Verdienst des Hooks: Dessen Schema führt
+schlicht kein `transcript_path`.
+
+**Ebenso aussagekräftig ist, was der Vorstand *nicht* meldet.** Der Fall „relativer Pfad aus dem
+Kern heraus" (`../VERSION` mit `cwd` im Kernverzeichnis) besteht dort – weil `cwd` damals
+Prüfmaterial war und deshalb aus dem falschen Grund blockierte. Genau diesen Grund stellt D-62 ab,
+und seither trägt den Fall allein die Auflösung. **Eine Sonde, die nur „blockiert ja/nein" fragt,
+hätte hier keinen Unterschied gesehen.**
+
+### 3.3 Die Zahl war behauptet, nicht gezählt
+
+Der Entwurf von CHANGELOG und Roadmap nannte **„15 Fundstellen gegen 0.33.0"**. Nachgemessen sind
+es 17, und der Weg dorthin ist ein anderer als der Text nahelegte: Wie ausgeliefert meldet der
+Validator **drei** Fehler, weil die Ankersonde vorher greift. Beide Stellen sind berichtigt.
+
+**Das ist der wiederkehrende Fall dieses Projekts, hier in eigener Sache:** 76 statt 248, fünf statt
+zehn, sechs statt zwölf, 25 statt 20 – und jetzt 15 statt 17, in einem Text, der die Lehre daraus
+selbst aufschreibt. **Wer hier eine Zahl liest, zählt sie nach, auch die eigene.**
+
+## 4. Vier bestehende Sonden haben die eigene Umsetzung gefangen
+
+Der erste Sondenlauf dieses Releases fiel mit **vier Abweichungen**, in beiden Kodierungsumgebungen
+gleich. Keine betraf Prüfung 32; alle vier betrafen **Sonden zu 30 und 31, die an Zahlen verankert
+sind, die dieses Release geändert hat**:
+
+| Abweichung | Ursache |
+|---|---|
+| Sonde 31a `[nichts präpariert]` | suchte `\| \`[TECHNISCH]\` \| 20 von 30 \|`; die Matrix trägt seit H4 `21 von 31` |
+| Sonde 31b `[nichts präpariert]` | dasselbe für die Gesamtzahl |
+| Gegenprobe 31 fiel | zog die Summen auf 21/31 nach – gezählt sind seit H4 22/32 |
+| Gegenprobe 30 fiel | suchte `\| Anzahl der Grenzfälle \| 13 \|`; es sind seit G-14/G-15 **15**. Dazu kollidierte ihre synthetische Kennung `G-14` mit dem **echten** neuen G-14 |
+
+Zwei davon meldeten sich als `[nichts präpariert]` – die Sonde stellt selbst fest, dass ihr
+Suchtext nicht mehr greift, und sagt es, statt die Prüfung zu messen. Die anderen beiden
+präparierten halb und fielen an der Zahl. **Berichtigt sind die Suchtexte, nicht die Prüfungen**;
+die synthetische Kennung heißt jetzt `G-16`.
+
+**Zwei Beobachtungen, und die zweite ist ein offener Punkt:**
+
+- Der Fall ist der erwartete Nutzen dieser Sondenbauart, nicht ihr Versagen: Die Meldung
+  `[nichts präpariert]` existiert genau dafür, und ohne sie hätten die Sonden 31a und 31b nach
+  diesem Release **grün und wirkungslos** dagestanden – der stillste aller Fehlschläge.
+- **Die Sonden zu 31 pflegen dieselben Zahlen von Hand, die Prüfung 31 gerade deshalb ausrechnet**
+  (D-60). Jede künftige Matrixzeile bricht sie erneut. Ob die Gegenprobe ihre Summen aus der
+  Tabelle ableiten sollte – und ob sie dann noch beweist, was sie beweisen soll, oder nur die
+  Rechenweise der Prüfung verdoppelt –, ist eine **Ermessensfrage und kein Messwert**. Sie gehört
+  in einen Änderungsantrag und ist in diesem Release **nicht** entschieden.
+
+## 5. Was dieses Release nicht nachweist
+
+- **Die Berichtigung von Abschnitt 5 beider Packs hat keine Sonde**, bewusst: Es ist eine
+  Textkorrektur an drei Aussagen, und eine Prüfung, die eine Formulierung bewacht, meldet jede
+  Umformulierung und sonst nichts. Belegt ist der Widerspruch – Zeile H2 derselben Dokumente und
+  der Manifestwert `hook_fail_closed: true` sagen seit 0.25.0 das Gegenteil.
+- **Prüfung 32 misst am Hook, nicht am Client.** Die Messung am Client steht in der Gegenprüfung
+  (`2026-09-13-B06-gegenpruefung.md`, Abschnitt 5.3), nicht im Validator. **Eine Messung am Hook
+  ist keine Messung am Client** – das ist die Lehre, an der dieser Befund neun Releases lang
+  vorbeikam.
+- **Kein Lauf gegen einen Client mit 0.34.0.** Dass der Schreibzugriff bei `claude-code` *nach* der
+  Berichtigung durchläuft, ist am Hook gemessen und im Validator geprüft, **nicht in einer
+  Clientsitzung**. Der Kontrolllauf der Gegenprüfung belegt die Sperre, nicht ihre Aufhebung.
+- **Symbolische Verknüpfungen unter Linux und macOS sind nicht gemessen.** Junctions unter NTFS
+  sind es. Die Auflösung sollte dort gleich wirken – Erwartung, nicht Messung.
+- **Die Zeitlücke ist benannt, nicht geschlossen** (E7). Ein Hook prüft vor dem Zugriff; eine
+  zwischenzeitlich umgebogene Verknüpfung kann er nicht ausschließen. Zeile H4 und
+  `framework/core/03-security.md` Abschnitt 4 sagen es.
+- **Der Shell-Schreibweg bleibt offen** (D-30, D-47), und damit bleibt **K-32 offen**.
+- **Die Lockerung aus E3 ist nachgerechnet** (Auflage des Antrags): Neu blockieren die zehn
+  Eingabeformen, das unbekannte Werkzeug im Kern und die Pfadvarianten; neu durchläuft
+  ausschließlich der Fall, in dem ein Pfad **außerhalb** von `tool_input` steht. In beiden
+  aufgezeichneten Schemata trägt der Umschlag keine Operationsdaten – Sitzungs- und
+  Ablaufkennungen, `cwd` und `transcript_path`. **Für ein künftiges Schema ist das eine offene
+  Flanke**, und E1 ist die Kompensation: Was die Form nicht einhält, gilt als unprüfbar.
+
+## 6. Der Lauf in beiden Kodierungsumgebungen
+
+| Umgebung | Sonden und Gegenproben | Ergebnis |
+|---|---|---|
+| ohne `PYTHONIOENCODING` | 104 | alle bestanden |
+| mit `PYTHONIOENCODING=utf-8` | 104 | alle bestanden |
+
+104 = 97 aus 0.33.0 plus **6 Sonden und 1 Gegenprobe**. Ausgezählt aus dem Lauf: **71 Sonden, 33
+Gegenproben** – 65 + 6 und 32 + 1. Der Validator meldet in beiden Umgebungen 0 Fehler und 0
+Warnungen.
+
+Der **erste** Lauf dieses Releases meldete in beiden Umgebungen 4 Abweichungen (Abschnitt 4); der
+hier ausgewiesene ist der Lauf nach deren Berichtigung.
+
+## 7. Gegenzeichnung
+
+| Rolle | Name/Kennung | Datum | Ergebnis bestätigt |
+|---|---|---|---|
+| `<FRAMEWORK_OWNER>` | `<TBD>` | `<TBD>` | `<TBD>` |

package/.koolie/core/tests/protocols/2026-09-13-wirkungsnachweise-0.35.0.md

@@ -0,0 +1,187 @@
+# Wirkungsnachweise zu Release 0.35.0
+
+| Feld | Wert |
+|---|---|
+| Gegenstand | Die Umsetzung zu `CR-2026-057` (D-64, D-65, D-66) – die Abbildung von `permissions.deny` auf die Werkzeugsperre je Skill, und die drei Grenzen dieser Zusage |
+| Datum | 2026-09-13 |
+| Framework-Version | 0.35.0 (gegen 0.34.0 = `cf45a01`) |
+| Prüfmethode | `probe-pruefungen.py` in **beiden** Kodierungsumgebungen; dazu drei Validatorläufe gegen den Vorstand mit unterschiedlichem Zuschnitt (Abschnitt 3) und eine frische `claude-code`-Installation |
+| Umgebung | Windows 11, Python 3.14.4 |
+| Ergebnis | **110 Sonden und Gegenproben bestehen gegen 0.35.0 in beiden Umgebungen** (76 Sonden, 34 Gegenproben). Validator: 0 Fehler, 0 Warnungen. Prüfung 33 meldet gegen die alt gerenderte Installation **9 Fundstellen** – genau die neun Skills, die eine Abbildung bekommen |
+
+> **Die Messung selbst steht nicht hier.** Dass `disallowed-tools` wirklich sperrt, belegt
+> `tests/protocols/2026-09-13-erhebung-disallowed-tools.md` – neun Läufe am Client. Dieses
+> Protokoll weist nach, dass die **Umsetzung** im Framework tut, was die Erhebung erlaubt.
+
+## 1. Was hier nachgewiesen wird
+
+| Gegenstand | Art | Nachweis |
+|---|---|---|
+| Abbildung `permissions.deny` → `disallowed-tools` (D-65) | neuer Mechanismus in `install.py` | Sonde 33a, dazu der Gegenbeweis mit 9 Fundstellen |
+| Vollständigkeit der Werkzeugliste aus `hook_tools` (D-65) | geänderte Herkunft | Sonde 33b |
+| Argumentmuster werden abgewiesen (D-66) | neue Prüfung | Sonde 33c |
+| Widerspruch zwischen Freigabe und Sperre | neue Prüfung | Sonde 33d |
+| Prüfung 33 selbst | neue Prüfung | Sonde 33e (verlorener Anker) |
+| `skill_deny_unmapped` als Deklaration (E3) | neues Manifestfeld | in Prüfung 33 erzwungen |
+| Zeile S3, Summen, M1, Grenzfälle G-16/G-17 | Textkorrekturen | über Prüfung 30 und 31 mitgeprüft |
+
+**Gegen eine frische `claude-code`-Installation, nicht gegen das Repositorium** – und das ist
+hier keine Förmlichkeit: Prüfung 33 läuft nur für ein Pack, dessen Manifest `skill_deny_field`
+führt. Die Testinstallation im Repositorium ist `devin-desktop` und führt es nicht; **im
+Repo-Lauf wird die Prüfung gar nicht ausgeführt.** Das war Befund **B02** – nicht, dass eine
+Prüfung falsch prüft, sondern dass sie einen Client nicht sieht.
+
+## 2. Die Sonden
+
+| Sonde | Präparation | Erwartete Meldung |
+|---|---|---|
+| 33a | Die Sperre fehlt ganz – der Stand bis 0.34.0 | „aus permissions.deny der Quelle ergibt sich" |
+| 33b | Die Sperre ist unvollständig (`Edit, Write` statt aller vier) | ebenda |
+| 33c | Ein Argumentmuster `Bash(git push:*)` in der Sperre | „Argumentmuster" |
+| 33d | `Bash` steht zugleich in `allowed-tools` und in der Sperre | „steht zugleich in allowed-tools" |
+| 33e | Der Anker `def deny_abbilden(` geht verloren | „'def deny_abbilden(' fehlt" |
+
+**Gegenprobe 33:** Die unveränderte `claude-code`-Installation bleibt unbeanstandet. Sie ist
+hier die wichtigere Hälfte: Ohne sie stünde nur fest, dass Prüfung 33 etwas meldet – und eine
+Prüfung, die jede Installation beanstandet, bestünde jede Sonde.
+
+**33b ist die Sonde auf die zweite Liste.** Die Werkzeugnamen kommen aus `hook_tools`, nicht aus
+`skill_frontmatter.tool_names`. Der Unterschied ist keine Förmlichkeit: `tool_names.edit` führt
+`Edit, Write`, `hook_tools.write` zusätzlich `NotebookEdit`. Für eine Vorabfreigabe ist das
+harmlos, **für eine Sperre ist es eine Lücke** – und eine Lücke ist gemessen ausnutzbar (Lauf E
+der Erhebung: mit gesperrtem `Write, Edit` schrieb der Skill über `Bash`). 33b hält genau diesen
+Fall fest.
+
+## 3. Der Gegenbeweis gegen den Vorstand – in drei Zuschnitten, und der erste ist lehrreich
+
+`git archive cf45a01` in ein leeres Verzeichnis, dort mit **dem eigenen** `install.py` des
+Vorstands installiert.
+
+| Zuschnitt | Ergebnis |
+|---|---|
+| **A** – nur der neue Validator, altes Manifest | **2 Fehler**, beide aus Prüfung 30 (D-64 und D-66 haben dort keinen Grenzfall). **Prüfung 33 ist stumm** |
+| **B** – zusätzlich das neue Manifest | **3 Fehler**; Prüfung 33 meldet ihren **eigenen Anker**: der alte `install.py` kennt `deny_abbilden` nicht |
+| **C** – wie B, Ankertest neutralisiert | **11 Fehler**, davon **9 aus Prüfung 33** |
+
+**Zuschnitt A ist der eigentliche Befund dieses Abschnitts.** Prüfung 33 hängt an
+`skill_deny_field`, und das Feld ist Teil dieses Releases. **Gegen den unveränderten Vorstand ist
+die Prüfung deshalb konstruktionsbedingt stumm** – nicht, weil dort nichts zu finden wäre,
+sondern weil das Pack die Abbildung noch gar nicht behauptet. Ein Gegenbeweis, der nur A fährt,
+würde „0 Fundstellen" melden und daraus das Falsche schließen.
+
+**Zuschnitt B ist der zweite Anwendungsfall der Ankersonde**, nach Prüfung 32 in 0.34.0: Die
+Prüfung stellt fest, dass ihr Gegenstand fehlt, und **bricht ab, statt leise zu bestehen**.
+
+**Zuschnitt C misst die Sache.** Die neun Fundstellen sind namentlich:
+
+```
+fw-bugfix-prepare, fw-change-analyze, fw-code-explain, fw-error-analyze,
+fw-plan, fw-repo-analyze          -> erwartet Edit, Write, NotebookEdit, Bash
+fw-docs-update                    -> erwartet Bash
+fw-mr-description, fw-review-support -> erwartet Edit, Write, NotebookEdit
+```
+
+**Diese Liste ist der unabhängige Beleg für die Aufteilung 7 / 2 / 3:** sieben vollständig
+abgebildet, zwei teilweise (ihr `edit` wird gesperrt, ihre `Exec(git push)`-Verbote nicht), drei
+gar nicht – `fw-change-small`, `fw-refactor`, `fw-tests` tauchen nicht auf, weil ihre Quelle
+ausschließlich befehlsgenaue Verbote führt. Die Zahl ist **ausgezählt, nicht gepflegt**.
+
+## 4. Was die eigene Arbeit gefangen hat
+
+### 4.1 Meine eigene Zahl war zu grob – und die Auflage hat sie gefangen
+
+Der Antrag schrieb in E3 „**fünf von zwölf Skills bekommen keine Schranke je Skill**". Die
+Entscheidung verlangte als Auflage, die Skills **namentlich** zu nennen statt als Zahl. Beim
+Nachzählen an der **erzeugten** Fassung waren es **drei ohne und zwei mit einer teilweisen**
+Schranke. Die Entscheidung E3 ändert das nicht; der Text ist berichtigt, im Antrag, im Manifest
+und im Client Pack.
+
+**Das ist der wiederkehrende Zählfehler dieses Projekts, diesmal im eigenen Antrag** – und zum
+ersten Mal von einer Auflage abgefangen, bevor er in eine Zusage geriet.
+
+### 4.2 Die Prosa hat die eigene Zeile heruntergestuft
+
+Die neue Zeile S3 nannte im Belegtext wörtlich `[NICHT ABBILDBAR]`, um ihre Vorgeschichte zu
+erklären. **Prüfung 31 zählt eine Zeile bei ihrer schwächsten Einstufung und liest dafür die
+ganze Zeile** – die Zeile stufte sich damit selbst herab, und die Summen fielen. Der Satz heißt
+jetzt „galt als nicht abbildbar", ohne die Marke.
+
+**Kein Fehler der Prüfung, sondern ihre Zählregel, angewandt.** Er gehört hierher, weil er beim
+nächsten Mal wieder auftritt: *Eine Einstufungsmarke in der Prosa einer Matrixzeile ist eine
+Einstufung.*
+
+### 4.3 Drei Sonden zu Prüfung 31 fielen – zum zweiten Mal in Folge
+
+0.34.0 hatte die Matrix um H4 erweitert, 0.35.0 verschiebt S3. Beide Male brachen dieselben
+drei Sonden, weil sie die Summen **wörtlich** verankern – dieselben Summen, die Prüfung 31
+gerade deshalb ausrechnet (D-60).
+
+**Die offene Frage aus dem 0.34.0-Protokoll hat sich damit ein zweites Mal gestellt**, und sie
+ist weiterhin nicht entschieden: Soll die Gegenprobe ihre Summen aus der Tabelle ableiten – und
+beweist sie dann noch, was sie beweisen soll, oder verdoppelt sie nur die Rechenweise der
+Prüfung? **Das ist eine Ermessensfrage und gehört in einen Änderungsantrag**, nicht in eine
+stille Umstellung während eines anderen Releases.
+
+### 4.4 Vier Zeilen des Decision Logs waren zerrissen
+
+Beim Eintragen von D-64 aufgefallen: **D-61 bis D-63 trugen fünf Zellen statt sechs** (mit
+0.34.0 entstanden), **D-29 acht** – dort teilt ein unmaskiertes `||` in einem Codespan die
+Zeile. In der gerenderten Tabelle stand dadurch die Herkunft unter „Begründung", das Datum unter
+„Alternativen" und die Rolle unter „Status"; bei D-29 war die Spalte „Alternativen" zerlegt.
+
+Alle vier sind berichtigt, D-61 bis D-63 mit Begründung und verworfenen Alternativen aus ihren
+Anträgen. **Gezählt hat das bisher nichts** – ein Prüfvorschlag dazu steht in Abschnitt 6.
+
+### 4.5 Ein neues Frontmatter-Feld war nicht als dokumentiert bekannt
+
+Der erste Lauf gegen eine frische Installation meldete **neun Warnungen** „Frontmatter-Feld
+`disallowed-tools` ist nicht dokumentiert". Wie bei der Modellwahl-Sperre kommt der Feldname
+jetzt aus dem Manifest statt aus einer festen Liste – **abgebildete Felder heißen je Client
+anders und gehören nicht in eine Namensliste im Validator.**
+
+## 5. Was dieses Release nicht nachweist
+
+- **`devin-desktop` ist unerhoben.** Das Pack verwirft `permissions` gar nicht erst
+  (`drop_fields: []`) und braucht deshalb keine Abbildung; die **Wirkung** seiner
+  Skill-`permissions` ist weiterhin nicht gemessen. S3 steht dort unverändert.
+- **Prüfung 33 misst am erzeugten Text, nicht am Client.** Dass `disallowed-tools` wirklich
+  sperrt, belegt die Erhebung. **Eine Messung am Validator ist keine Messung am Client.**
+- **Kein Lauf einer vollständigen Installation gegen einen Client mit 0.35.0.** Dass ein
+  Framework-Skill in einer echten Sitzung nicht mehr schreiben kann, ist am Mechanismus gemessen
+  (mit einer synthetischen Sonde), **nicht mit einem Framework-Skill in einer Installation**.
+- **Die Turngrenze ist im Druckmodus gemessen.** Eine interaktive Sitzung sollte sich gleich
+  verhalten – dieselbe Mechanik, aber nicht derselbe Lauf.
+- **Verschachtelte Aufrufe sind nicht gemessen.** Ob die Sperre auch für einen Unteragenten
+  gilt, den ein Skill startet, ist offen. **Für M1 wäre das die nächste Frage.**
+- **`tool_names` und `hook_tools` bleiben zwei Listen** für dieselbe Sache. Die Vereinheitlichung
+  ist **vertagt und benannt**, nicht vergessen: Sie änderte `allowed-tools` still mit, und das
+  gehört in einen eigenen Antrag.
+
+## 6. Der Lauf in beiden Kodierungsumgebungen
+
+| Umgebung | Sonden und Gegenproben | Ergebnis |
+|---|---|---|
+| ohne `PYTHONIOENCODING` | 110 | alle bestanden |
+| mit `PYTHONIOENCODING=utf-8` | 110 | alle bestanden |
+
+110 = 104 aus 0.34.0 plus **5 Sonden und 1 Gegenprobe**. Ausgezählt aus dem Lauf: **76 Sonden,
+34 Gegenproben** – 71 + 5 und 33 + 1. Der Validator meldet in beiden Umgebungen 0 Fehler und
+0 Warnungen.
+
+Der **erste** Lauf dieses Releases meldete in beiden Umgebungen 3 Abweichungen (Abschnitt 4.3);
+der hier ausgewiesene ist der Lauf nach deren Berichtigung.
+
+## 7. Ein Prüfvorschlag, der nicht Teil dieses Releases ist
+
+**Die Zellen der Tabellen im Decision Log werden von nichts gezählt.** Abschnitt 4.4 zeigt vier
+zerrissene Zeilen, davon drei aus dem Vorgängerrelease und eine seit 0.10.x. Prüfung 30 tut
+genau das für `EDGE_CASES.md` (`GRENZFALL_SPALTEN = 7`) – die Bauform liegt also vor.
+
+**Das ist ein Vorschlag und keine Umsetzung.** Eine neue Prüfung ist ein neuer Mechanismus und
+braucht eine Entscheidung; sie gehört in einen Änderungsantrag, nicht in dieses Release.
+
+## 8. Gegenzeichnung
+
+| Rolle | Name/Kennung | Datum | Ergebnis bestätigt |
+|---|---|---|---|
+| `<FRAMEWORK_OWNER>` | `<TBD>` | `<TBD>` | `<TBD>` |