@renoxar/koolie 1.25.0

package/.koolie/core/tests/protocols/2026-09-13-gegenpruefung-stumme-brueche.md

@@ -0,0 +1,202 @@
+# Gegenprüfung: der stumme Bruch – eine halb greifende Präparation, eine ungezählte Tabelle, und eine Prüfung, die den richtigen Text beanstandet
+
+| Feld | Wert |
+|---|---|
+| Gegenstand | Zwei seit mehreren Releases benannte, nicht umgesetzte Punkte: (1) die **Ermessensfrage**, ob eine Gegenprobe ihre Summen ableiten soll – viermal in Folge aufgetreten; (2) der **Prüfvorschlag** aus dem 0.35.0-Protokoll, Abschnitt 7: die Zellen der Decision-Log-Tabellen zählt nichts |
+| Anlass | Beide stehen in der Roadmap und in der Übergabe als offen. Nach D-23 gehört ein Befund vor der Umsetzung gegengeprüft, auch wenn er aus dem eigenen Haus stammt |
+| Datum | 2026-09-13 |
+| Framework-Version | 0.37.0 (Auscheckstand `a8132fd`, Arbeitsbaum sauber, Validator 0/0) |
+| Prüfmethode | **Drei Messungen an Kopien des Repositoriums, keine Codelektüre allein.** (1) Die heutige Präparation der Gegenprobe 30 auf einen Baum angewandt, der einen zwanzigsten Grenzfall trägt – der Zustand, den ein Release hinterlässt; (2) die Zellenzahlen des Decision Logs über sechs Auscheckstände hinweg gezählt, mit und ohne Rücksicht auf maskierte Striche; (3) ein maskierter Strich in eine Grenzfallzeile gesetzt und der Validator dagegen gefahren |
+| Umgebung | Windows 11, Python 3.14.4, NTFS |
+| Ergebnis | **Beide Befunde bestätigen sich. Die Gegenprüfung findet einen dritten, den keiner der beiden nennt** – und er ist der einzige, der heute einen falschen Fehler erzeugen kann |
+
+## 0. Der Zusammenhang in einem Satz
+
+**Alle drei Punkte sind dieselbe Bauform: eine Prüfung oder eine Sonde, deren Bruch nicht als
+Bruch erscheint.** Die halbe Präparation sieht aus wie ein Prüfungsfehler, die ungezählte
+Tabelle sieht aus wie eine geprüfte, und die naive Spaltenzählung sieht aus wie ein Befund.
+Der wiederkehrende Befundtyp des Projekts lautet *eine Zusage, die mehr verspricht, als sie
+leistet*; hier steht er dreimal in derselben Woche.
+
+## 1. Befund 1: Die halb greifende Präparation meldet sich nicht als solche
+
+### 1.1 Was behauptet wird
+
+Aus dem 0.34.0-Protokoll, seither dreimal wiederholt: Die Gegenproben 30 und 31 verankern
+Summen **wörtlich**, die die jeweilige Prüfung ausrechnet. Ändert ein Release die Summe,
+greift der Suchtext ins Leere. Die Übergabe fügt hinzu: *„Zwei melden sich selbst als
+`[nichts praepariert]` – die anderen präparieren halb und fallen an der Zahl."*
+
+### 1.2 Was gemessen dabei herauskommt
+
+Eine Kopie bekam einen **echten** zwanzigsten Grenzfall samt nachgezogener Anzahl – der
+Zustand, den ein Release hinterlässt. Der Validator meldet darauf `0 Fehler, 0 Warnungen`.
+Danach lief die Präparation der Gegenprobe 30 wörtlich so, wie sie heute im Skript steht.
+
+| Schritt | Ergebnis |
+|---|---|
+| Anzahl im Steckbrief von 19 auf 20 (erste Ersetzung) | **trifft nicht** – dort steht bereits 20 |
+| Zeile `G-99` vor Abschnitt 3 einfügen (zweite Ersetzung) | **trifft** |
+| `baumhash` vorher gegen nachher | **verschieden** – der Wächter meldet nichts |
+| Validatorlauf | `FEHLER … 21 Grenzfallzeilen, der Steckbrief nennt 20. Eine Zahl, die nicht stimmt, ist kein Nachweis` |
+| Gegenprobe 30 | **FEHL**, mit genau dieser Meldung |
+
+**Der Befund bestätigt sich, und er ist schärfer als seine Beschreibung.** Die Gegenprobe fällt
+nicht nur – sie fällt mit einer Meldung, die den Eindruck erweckt, sie habe einen **echten
+Fehler im Repositorium** gefunden. Wer die Ausgabe liest, sucht den Fehler in `EDGE_CASES.md`.
+Dort ist keiner: Die Sonde hat ihren eigenen Suchtext verloren.
+
+> **`baumhash` ist ein Alles-oder-nichts-Wächter.** Bei einer Präparation aus *n* Ersetzungen
+> belegt er „mindestens eine hat gegriffen", nie „alle". Genau deshalb melden sich die
+> einteiligen Präparationen selbst und die mehrteiligen nicht. **Das ist keine Nachlässigkeit
+> beim Schreiben der Sonden, sondern eine Lücke im Runner** – und sie schließt sich nicht
+> dadurch, dass man die Suchtexte sorgfältiger pflegt.
+
+### 1.3 Wie weit die Lücke reicht – und wo `baumhash` deckt
+
+Ausgezählt über den Syntaxbaum von `probe-pruefungen.py`. **Drei Lagen, und nur zwei davon
+sind Befund:**
+
+| Lage | Anzahl | Deckt `baumhash`? |
+|---|---|---|
+| **a** Präparation über einen Runner mit `baumhash`, **eine** Ersetzung | der Regelfall | **ja** – und die Meldung sagt sogar, was zu tun ist: „vermutlich passt der Suchtext der Sonde nicht mehr" |
+| **b** Präparation über einen solchen Runner, **mehrere** Ersetzungen | **3** Stellen: `_grenzfall_ergaenzen` (2), `_zeile_mit_summe` (5 plus eine Einfügung, in 2 Dateien), `_zusaetzliches_pfadfeld` (dieselbe Ersetzung in 2 Manifesten) | **nein** – eine gegriffene Ersetzung genügt ihm |
+| **c** Bündelfunktionen, die `melde()` direkt rufen | **9** Funktionen mit zusammen **35** Meldestellen, darin **3** mit Textpräparation (7 Ersetzungen) | **nein, gar nicht** – diese Runner haben keinen Wächter |
+
+**Lage a ist kein Befund.** Der Runner meldet dort genau das Richtige, und das ist der Grund,
+warum die Übergabe von „zwei melden sich selbst" spricht. **Runner mit `baumhash` gibt es
+drei:** `sonde()`, `gegenprobe()` und `sonde_ohne_wert()`.
+
+**Lage b und c sind der Befund.** Die neun Bündelfunktionen haben **gar keinen** Wächter; ihre
+35 Meldestellen sind damit die größere Fläche, auch wenn heute nur drei von ihnen einen
+Suchtext führen, der ins Leere gehen könnte. Die übrigen präparieren über Installationsläufe,
+Dateilöschungen und Umgebungsvariablen.
+
+**Zu ändern sind damit sechs Präparationen** mit zusammen **14 Ersetzungsstellen und zwei
+Zeileneinfügungen**. Das ist ein kleiner Gegenstand; viermal von Hand nachgezogen ist er
+trotzdem.
+
+> **Die erste Auszählung war zu grob, und das gehört hierher.** Über den Syntaxbaum gezählt
+> ergaben sich zunächst „zehn Bündelfunktionen, neun Ersetzungen" – der Zähler hielt eine
+> Ersetzung in einer **Diagnosemeldung** (`ausgabe.replace(marker, "<Marker entfernt>")`) für
+> eine Präparation und `sonde_ohne_wert()` für wächterlos, obwohl die Funktion einen
+> `baumhash` trägt. **Ein Zähler unterscheidet Präparation und Diagnose nicht**; das musste
+> ein Blick in die sechs Stellen tun. Wie schon 76 statt 248 und 25 statt 20: **Wer hier eine
+> Zahl liest, zählt sie besser nach – auch die eigene.**
+
+## 2. Befund 2: Die Zellen der Decision-Log-Tabellen zählt nichts
+
+### 2.1 Was behauptet wird
+
+0.35.0-Protokoll Abschnitt 7: Vier zerrissene Zeilen wurden von Hand berichtigt, drei davon
+aus dem Vorgängerrelease, eine seit 0.10.x. **Gezählt hat das nichts.** Prüfung 30 tut
+dasselbe längst für `EDGE_CASES.md`.
+
+### 2.2 Was gemessen dabei herauskommt
+
+Die Zellenzahlen wurden über sechs Auscheckstände gezählt – je Tabelle des Decision Logs die
+Zellenzahl ihrer Kopfzeile als Sollwert, maskierte Striche als Inhalt behandelt:
+
+| Stand | Abweichende Zeilen |
+|---|---|
+| 0.32.0 (`a76778e`) | **1** – D-29 |
+| 0.33.0 (`47fa382`) | **1** – D-29 |
+| 0.34.0 (`2c1351b`) | **4** – D-29, D-61, D-62, D-63 |
+| 0.35.0 (`7082ef3`) | 0 |
+| 0.36.0 (`4444c83`) | 0 |
+| 0.37.0 (`74e087b`, heute) | 0 |
+
+**Der Befund bestätigt sich – und er ist heute behoben.** Eine Prüfung, die jetzt entsteht,
+fängt **nichts**. Das ist dieselbe Lage wie bei Prüfung 35 und bei dem fünften Gegenstand der
+Prüfung 32, und sie gehört mit derselben Ehrlichkeit begründet: **eine Verankerung, keine
+Behebung.**
+
+> **Der Unterschied zu Prüfung 35 ist allerdings erheblich und spricht für diese Prüfung:**
+> Prüfung 35 fand auch im Vorstand nichts, weil ihr Gegenstand dort nicht existiert. Diese
+> Prüfung hätte gegen 0.34.0 **vier** Fundstellen gemeldet und gegen 0.32.0 und 0.33.0 je
+> eine. Ihr Gegenbeweis ist damit keine Konstruktion, sondern ein Abzählen.
+
+### 2.3 Und D-29 stand fünfundzwanzig Releases lang zerrissen
+
+D-29 entstand mit 0.10.x. Die Zeile wurde zwischen 0.10.x und 0.35.0 von jedem Validatorlauf
+und von jedem Wirkungsnachweis gesehen und von keinem gezählt. **Gefunden hat sie ein Mensch
+beim Eintragen einer anderen Zeile.**
+
+## 3. Befund 3, nicht gesucht: Prüfung 30 zählt einen maskierten Strich als Spaltentrenner
+
+### 3.1 Der Fund
+
+Prüfung 30 zerlegt eine Grenzfallzeile mit `zeile.strip().strip("|").split("|")`. GFM verlangt
+für einen Strich **innerhalb** einer Tabellenzelle die Maskierung `\|`; gerendert bleibt die
+Zeile dann vollständig. `.split("|")` sieht die Maskierung nicht.
+
+Gemessen an einer Kopie: In Grenzfall **G-14** wurde in der Prosa ein Codespan mit maskiertem
+Strich ergänzt – dieselbe Schreibweise, die **D-69 des Decision Logs seit 0.36.0 trägt**:
+
+```text
+FEHLER   leitwerk-core/tests/EDGE_CASES.md: Grenzfall G-14 hat 9 Spalten statt 7
+         (Nr., Grenzfall, Entscheidung, Betriebsmodus, Kontrollstufe, Rollen, Fundstelle)
+```
+
+**Prüfung 30 beanstandet einen GFM-korrekten Text.** Das ist genau die Bauform, vor der der
+Wirkungsnachweis zu Prüfung 28 warnt: *eine Prüfung ohne die nötige Unterscheidung hätte den
+richtigen Text beanstandet.*
+
+### 3.2 Warum das heute niemand sieht – und warum es trotzdem zählt
+
+Keine Grenzfallzeile trägt heute einen maskierten Strich. **Der Fehlalarm ist latent, nicht
+aktuell.** Er zählt trotzdem aus zwei Gründen:
+
+1. **Er verbietet es, die neue Prüfung naiv zu bauen.** Nach der naiven Zählweise trügen D-29
+   und D-69 heute **acht** Zellen statt sechs – die neue Prüfung meldete an ihrem ersten Lauf
+   **zwei Fehlalarme auf korrektem Text.** Ohne diese Messung wäre das erst nach dem Bau
+   aufgefallen, wie bei Prüfung 34 beim ersten Lauf.
+2. **Die Zählweise liegt viermal im Validator**, jedes Mal eigenhändig: `check_hook_ablageort`
+   (`:1686`, erste Zelle), `_tabellenzeilen` (`:1838`, Prüfungen 20/27), `check_grenzfaelle`
+   (`:2528`, Prüfung 30), `_uebersicht_pruefen` (`:3033`, Prüfung 31). Eine fünfte Stelle wäre
+   die fünfte Gelegenheit für denselben Fehler.
+
+**Betroffen ist heute nur Prüfung 30** – die anderen drei nehmen entweder nur die erste Zelle
+oder suchen in der ganzen Zeile. Das mindert den Fund nicht: Eine Prüfung, die den richtigen
+Text beanstandet, wiegt schwerer als eine, die einen falschen durchlässt, denn sie kostet
+Vertrauen in alle anderen.
+
+## 4. Die Ermessensfrage, um die es eigentlich geht
+
+Sie steht seit dem 0.34.0-Protokoll und ist nie entschieden worden:
+
+> 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?
+
+**Die Gegenfrage ist echt, und die Messung entscheidet sie nicht.** Was die Messung beiträgt,
+ist die Trennung zweier Dinge, die bisher als eines behandelt wurden:
+
+| | Frage | Art |
+|---|---|---|
+| **a** | Woher nimmt die Gegenprobe ihre Zielsumme? | **Ermessen** – eine abgeleitete Summe ist bequemer und belegt weniger |
+| **b** | Was passiert, wenn ein Suchtext der Präparation nicht mehr trifft? | **kein Ermessen** – heute erscheint es als Prüfungsfehler, und das ist schlicht falsch |
+
+**Punkt b ist unabhängig von Punkt a zu beheben.** Wird er behoben, verliert Punkt a den
+größten Teil seines Drucks: Der wörtlich verankerte Wert bleibt der teurere Weg, aber sein
+Bruch kostet dann eine Zeile Diagnose statt einer Fehlersuche im Repositorium.
+
+## 5. Was diese Gegenprüfung nicht leistet
+
+- **Sie misst keine Clientsitzung.** Alle drei Messungen laufen gegen den Validator und gegen
+  Kopien des Repositoriums. Das ist hier der richtige Gegenstand – es geht um Prüfungen, nicht
+  um Durchsetzung –, aber es ist zu benennen.
+- **Sie sagt nichts darüber, ob die Einstufungen richtig sind**, die in den gezählten Tabellen
+  stehen. Die Zellenzahl ist Arithmetik, nicht Inhalt; dieselbe Grenze, die Prüfung 31 für
+  sich selbst benennt.
+- **Sie hat die anderen drei Zählstellen nicht durchgemessen**, sondern gelesen. Dass
+  `check_hook_ablageort` nur die erste Zelle nimmt und `_uebersicht_pruefen` eine Zelle über
+  ein Muster sucht, steht im Code; ein maskierter Strich an der jeweils entscheidenden Stelle
+  ist nicht eingesetzt worden.
+- **Sie prüft nicht, ob GFM in jeder Renderumgebung gleich maskiert.** Zugrunde gelegt ist die
+  GFM-Spezifikation und das Verhalten, das D-69 und `CR-2026-055` bereits voraussetzen.
+
+## 6. Gegenzeichnung
+
+| Rolle | Name/Kennung | Datum | Ergebnis bestätigt |
+|---|---|---|---|
+| `<FRAMEWORK_OWNER>` | `<TBD>` | `<TBD>` | `<TBD>` |

package/.koolie/core/tests/protocols/2026-09-13-gegenpruefung-werkzeugabbildung.md

@@ -0,0 +1,219 @@
+# Gegenprüfung: zwei Listen für dieselbe Sache – es sind vier, und eine davon ist unbewacht
+
+| Feld | Wert |
+|---|---|
+| Gegenstand | **Kandidat 1 der Übergabe:** „`skill_frontmatter.tool_names` und `hook_tools` vereinheitlichen – zwei Listen für dieselbe Sache, auseinandergelaufen: `tool_names.edit` führt kein `NotebookEdit`." Seit 0.35.0 vertagt, mit Grund: Die Vereinheitlichung ändere `allowed-tools` still mit |
+| Anlass | Der Kandidat steht seit fünf Releases und ist nach der Übergabe „der größte offene Posten, der ohne Messinstrument auskommt". Nach D-23 gehört ein Befund vor der Umsetzung gegengeprüft, auch wenn er aus dem eigenen Haus stammt |
+| Datum | 2026-09-13 |
+| Framework-Version | 0.39.0 (Auscheckstand `7701db2`, Arbeitsbaum sauber, Validator 0/0) |
+| Prüfmethode | **Zwanzig Messungen an den Abbildungsfunktionen und an echten Installationen, keine Codelektüre allein.** M1 bis M5 rufen die Abbildung je Verb und je Pack auf; M6 bis M12 greifen in eine Kopie des Repositoriums ein und lassen den ausgelieferten Validator laufen; M13 bis M20 präparieren das Manifest und installieren wirklich. **Sieben der zwanzig sind Kontrollläufe** – dieselbe Lücke in den *anderen* Abbildungen desselben Manifests. Ohne sie wäre „läuft durch" kein Messwert, sondern womöglich ein nicht gestarteter Lauf |
+| Umgebung | Windows 11, Python 3.14.4, NTFS; Kopien und Testinstallationen im Scratchpad |
+| Ergebnis | **Der Befund bestätigt sich – und er ist ein anderer, als der Kandidat sagt.** Es sind **vier** Werkzeugabbildungen, nicht zwei. Der inhaltliche Unterschied, den der Kandidat nennt, ist **richtungsrichtig und harmlos**; die vorgeschlagene Behebung wäre eine **Ausweitung**. Der eigentliche Befund liegt daneben: **Drei der vier Abbildungen brechen ab, wenn ihnen ein Verb fehlt. Die vierte reicht es wörtlich durch – und sie kommt zweimal vor** |
+
+## 0. Der Zusammenhang in einem Satz
+
+**Ein Frontmatter des Kerns schreibt fünf Verben, und drei verschiedene Stellen bilden sie
+ab – jede mit ihrem eigenen Vokabular, und genau die, die eine echte Sperre trägt, kennt
+zwei der fünf Verben nicht.**
+
+## 1. Wie viele Listen es wirklich sind
+
+| Stelle | Vokabular | Wofür | Bewacht? |
+|---|---|---|---|
+| `skill_frontmatter.tool_names` | `read, grep, glob, edit, exec` | `allowed-tools` des Skills – eine **Vorabfreigabe** (B01) | **nein** |
+| `agent_frontmatter.tool_names` | dieselben fünf, zeichengleicher Block | `tools` des Agentenprofils – eine **Entfernung aus dem Vorrat** (A1, D-68) | **nein** |
+| `hook_tools` | `read, search, exec, write` | Hook-Matcher **und** `disallowed-tools` je Skill – eine echte **Sperre** (S3, D-64) | ja |
+| `permission_tools` | `read, search, write, exec, fetch, mcp` | Berechtigungsdatei – die Kernzusagen B1 bis B6 | ja |
+| *daneben:* `agent_start_tools` | – | Startwerkzeug für Unteragenten (D-70) | ja (Prüfungen 34, 35) |
+
+**Die Übergabe zählt zwei. Es sind vier, und die Zählung war damit wieder zu klein** – zum
+sechsten Mal an diesem Tag.
+
+Dazu ein drittes Vokabular, das keine Liste ist: `DENY_VERB_EIMER` in `install.py` – die
+Brücke, über die `permissions.deny` der Quelle auf `hook_tools` abgebildet wird. Sie führt
+`edit`, `write`, `exec`, `read` und `search`: **drei Verben der Quelle und zwei der
+Durchsetzungsschicht**, und sie kennt `grep` und `glob` nicht.
+
+## 2. Was die vierzehn ausgelieferten Quellen wirklich schreiben (M5)
+
+Dreizehn `SKILL.md` und ein Agentenprofil:
+
+| Feld | Verb | Fundstellen |
+|---|---|---|
+| `allowed-tools` | `read` | **14** |
+| | `grep` | **14** |
+| | `glob` | **14** |
+| | `edit` | 4 |
+| | `exec` | 5 |
+| `permissions.deny` | `edit` | 9 |
+| | `exec` | 8 |
+| | befehlsgenau (`Exec(git push)` …) | 26 |
+
+**`grep` und `glob` sind die meistgenannten Verben des Vokabulars – und genau die beiden,
+die die Sperrabbildung nicht kennt.**
+
+## 3. Befund 1: Dasselbe Wort, zwei Felder, zwei Verhalten (M1)
+
+Je Verb ein Skill mit `allowed-tools: [<verb>]` **und** `permissions.deny: [<verb>]`,
+durch `render_skill_frontmatter` des Vorstands, Pack `claude-code`:
+
+| Verb | `allowed-tools` wird zu | `disallowed-tools` wird zu |
+|---|---|---|
+| `read` | `Read` | `Read` |
+| **`grep`** | `Grep` | **nichts** |
+| **`glob`** | `Glob` | **nichts** |
+| **`search`** | **`search`** | `Grep, Glob` |
+| `edit` | `Edit, Write` | `Edit, Write, NotebookEdit` |
+| **`write`** | **`write`** | `Edit, Write, NotebookEdit` |
+| `exec` | `Bash` | `Bash` |
+| **`fetch`** | **`fetch`** | **nichts** |
+| **`mcp`** | **`mcp`** | **nichts** |
+| **`banane`** | **`banane`** | **nichts** |
+
+**Zwei von zehn Verben verhalten sich in beiden Feldern gleich.** Die Lage ist genau
+invertiert: `grep` wirkt in der Vorabfreigabe und nicht in der Sperre, `search` in der
+Sperre und nicht in der Vorabfreigabe. Und ein Schreibfehler – `banane` – wird in der
+Vorabfreigabe **zum Werkzeugnamen** und in der Sperre **zu nichts**.
+
+Für das Agentenprofil (M2) gilt dasselbe: Aus `allowed-tools: [banane]` wird
+`tools: banane`.
+
+## 4. Befund 2: Drei Abbildungen brechen ab, eine reicht durch (M3, M13 bis M20)
+
+### 4.1 Am Funktionsaufruf (M3)
+
+Dieselbe Frage – „was heißt dieses Verb bei diesem Client?" – an alle drei Abbildungen:
+
+| Verb | `skill_frontmatter.tool_names` | `hook_tools` | `permission_tools` |
+|---|---|---|---|
+| `grep` | `Grep` | **AbbildungsFehler** | **AbbildungsFehler** |
+| `edit` | `Edit, Write` | **AbbildungsFehler** | **AbbildungsFehler** |
+| `banane` | **`banane`** | **AbbildungsFehler** | **AbbildungsFehler** |
+
+### 4.2 An einer echten Installation (M13 bis M20)
+
+Je Zeile: Manifest präparieren, `install.py --client claude-code --root <leer>`, das
+erzeugte Frontmatter ablesen, Manifest zurücksetzen und gegen den Ausgangstext prüfen.
+
+| Nr. | Eingriff | Ergebnis |
+|---|---|---|
+| M13 | *Ausgangslage* | `fw-plan: allowed-tools: Read, Grep, Glob` / `fw-reviewer: tools: Read, Grep, Glob` |
+| **M14** | `skill_frontmatter.tool_names` verliert `grep` | **durchgelaufen** → `allowed-tools: Read, grep, Glob` |
+| **M15** | `agent_frontmatter.tool_names` verliert `read` | **durchgelaufen** → `tools: read, Grep, Glob` |
+| **M16** | **beide `tool_names`-Blöcke ganz geleert** | **durchgelaufen** → `tools: read, grep, glob` |
+| M17 | *Kontrolle:* `hook_tools` verliert `search` | **ABBRUCH:** „hook_tools kennt das Werkzeugverb 'search' nicht" |
+| M18 | *Kontrolle:* `hook_tools.search` auf die leere Liste | **ABBRUCH:** „kein Hook-Werkzeug für 'search' …" |
+| M19 | *Kontrolle:* `permission_tools` verliert `exec` | **ABBRUCH:** „permission_tools kennt das Werkzeugverb 'exec' nicht" |
+| M20 | *Kontrolle nach Rücknahme* | wie M13 |
+
+**M16 ist die Messung, auf die es ankommt.** Eine Installation, deren Abbildung gar nichts
+mehr kann, läuft durch und liefert das Reviewprofil `fw-reviewer` mit
+`tools: read, grep, glob` aus – **drei Namen, die dieser Client nicht führt.** Zeile A1
+des Packs nennt genau diesen Fall als nicht gemessen: *„dass ein Profil, dessen
+`tools`-Liste sich zu keinem Werkzeug auflöst, gar nicht erst gestartet wird"*. **Die
+Abbildung stellt ihn stillschweigend her.**
+
+Die Richtung ist dabei nicht die schlimmstmögliche: Ein Werkzeugname, den es nicht gibt,
+ist kein Werkzeug, und sowohl die Vorabfreigabe als auch das Profil werden dadurch
+**enger**. Aber die Zusage A1 hinge dann an einem Zufall, und niemand meldete es.
+
+## 5. Befund 3: `permissions.deny: glob` erzeugt lautlos keine Sperre (M6 bis M8)
+
+Je Zeile: Eingriff in eine Kopie des Repositoriums, ausgelieferter Validator, Rücknahme.
+Ausgangslauf 0 Fehler, 0 Warnungen.
+
+| Nr. | Eingriff in `fw-plan/SKILL.md` | Validator |
+|---|---|---|
+| **M6** | `permissions.deny: edit, exec` → `glob, grep` | **0 Fehler, 0 Warnungen** |
+| **M7** | `allowed-tools` um ein Verb `banane` ergänzt | **0 Fehler, 0 Warnungen** |
+| **M8** | `allowed-tools: read` → `search` | **0 Fehler, 0 Warnungen** |
+
+**M6 ist der Kern.** Ein Skillautor, der `deny: glob` schreibt, bekommt keine Sperre,
+keine Verweigerung und keine Meldung – **genau die Bauform, die D-66 für Argumentmuster
+gemessen hat:** *„Wer ein Argumentmuster schreibt, hat deshalb gar keine Schranke, nicht
+bloß eine gröbere."*
+
+**Und diese Nicht-Abbildung ist nicht deklariert.** Der Docstring von `deny_abbilden`
+führt die *andere* Nicht-Abbildung – die befehlsgenauen Einträge – ausdrücklich mit
+Verweis auf D-47 („Bauart wie `hook_tools_absent`") und im Manifest unter
+`skill_deny_unmapped`. **Die Verben `grep` und `glob` stehen nirgends.** Ein Kanal ohne
+Deklaration, in derselben Funktion, die D-47 zitiert.
+
+**Ausgeliefert wird davon heute nichts:** Keine der vierzehn Quellen schreibt
+`deny: grep` oder `deny: glob` (M5). Der Befund ist deshalb **eine Vorsorge, keine offene
+Lücke** – für die Skills des Kerns. Für ein Projekt, das einen eigenen `prj-*`-Skill
+schreibt, ist er heute wirksam.
+
+## 6. Befund 4 – die Entlastung: Der Kandidat schlägt die falsche Behebung vor (M4)
+
+Der inhaltliche Unterschied, den die Übergabe nennt, ist echt. **Seine Richtung ist die
+zulässige:**
+
+| Verb der Quelle | Vorabfreigabe `tool_names` | Sperre `hook_tools` | Lage |
+|---|---|---|---|
+| `read` | `Read` | `Read` | Sperre ⊇ Vorabfreigabe |
+| `grep` | `Grep` | `Grep, Glob` | Sperre ⊇ Vorabfreigabe |
+| `glob` | `Glob` | `Grep, Glob` | Sperre ⊇ Vorabfreigabe |
+| **`edit`** | `Edit, Write` | `Edit, Write, NotebookEdit` | Sperre ⊇ Vorabfreigabe |
+| `exec` | `Bash` | `Bash` | Sperre ⊇ Vorabfreigabe |
+
+**Bei allen fünf ist die Sperrliste mindestens so weit wie die Vorabfreigabe** – und das
+ist die Richtung, die man will: Ein Skill, der `edit` freigibt und `edit` sperrt, bekommt
+keine Freigabe auf ein Werkzeug, das die Sperre nicht erfasst.
+
+**Der Kandidat wollte `tool_names` auf `hook_tools` heben.** Das hieße, aus
+`allowed-tools: Edit, Write` ein `Edit, Write, NotebookEdit` zu machen – **eine
+Ausweitung der Vorabfreigabe**, und nach dem Verschärfungsprinzip genau das, was ein
+Änderungsantrag begründen müsste. Die Gegenrichtung – `hook_tools.write` um
+`NotebookEdit` kürzen – wäre eine Lücke in einer Sperre.
+
+**Zu vereinheitlichen ist deshalb nicht der Inhalt der Listen, sondern die Brücke
+zwischen den Vokabularen und die Disziplin, mit der sie bewacht werden.** Und dass die
+Vertagung seit 0.35.0 mit „das ändert `allowed-tools` still mit" begründet war, ist damit
+**bestätigt und zugleich überholt**: Der Grund stimmte, die Behebung war eine andere.
+
+## 7. Befund 5 – nicht gesucht: Ein Manifest widerspricht sich selbst
+
+`devin-desktop` führt `tool_names: {}` in beiden Blöcken; die Verben gehen unverändert
+durch, und jede installierte Skilldatei dieses Packs trägt `allowed-tools: read, grep,
+glob` (M1, M2).
+
+Dasselbe Manifest erklärt drei Felder weiter:
+
+> `"hook_tools_absent": ["search"]` – *„Dieser Client führt kein eigenes Suchwerkzeug"*
+
+**Beides kann nicht stimmen.** Entweder hat der Client Suchwerkzeuge, dann ist die
+erklärte Abwesenheit falsch; oder er hat keine, dann nennen dreizehn installierte Skills
+zwei Werkzeuge, die es nicht gibt.
+
+**Welche Seite falsch ist, ist unerhoben** – Zeile S3 dieses Packs sagt es selbst: *„Das
+Durchreichen ist belegt, die Wirkung nicht."* Der **Widerspruch** ist gemessen, seine
+Auflösung nicht. Er gehört festgehalten, nicht geraten.
+
+## 8. Befund 6 – nebenbei: Der Kopfkommentar des Validators endet bei Prüfung 31
+
+Kandidat 4 der Übergabe, hier bestätigt: Die Prüfungen **32 bis 37** stehen nicht im
+Kopfkommentar von `validate-framework.py`, seit fünf Releases. Wer eine achtunddreißigste
+hinzufügt, ohne die sechs nachzutragen, schreibt die Lücke fort.
+
+## 9. Was diese Gegenprüfung nicht leistet
+
+- **Keine Messung an einem Client.** Gemessen sind die Abbildungsfunktionen, der
+  Validator und zwei echte Installationen – nicht, wie ein KI-Client auf
+  `allowed-tools: banane` reagiert. Dass ein nicht existierender Werkzeugname keine
+  Wirkung hat, ist **Erwartung**.
+- **Die Werkzeugnamen von `devin-desktop` bleiben unerhoben.** Befund 5 weist einen
+  Widerspruch nach, keine Wahrheit.
+- **Ob `grep`/`glob` in `disallowed-tools` wirken würden, ist nicht gemessen.** Belegt
+  ist, dass heute **nichts** erzeugt wird. Ob `Grep, Glob` dort die Suche sperrten, wäre
+  eine eigene Erhebung – dieselbe Frage, die D-64 für `Write, Edit` beantwortet hat.
+- **Die Zahl 14 der Quellen ist gezählt, nicht ausgerechnet.** Sie umfasst dreizehn
+  `SKILL.md` (zwölf `fw-*`, einer aus dem Rollenpack) und ein Agentenprofil.
+
+## 10. Gegenzeichnung
+
+| Feld | Inhalt |
+|---|---|
+| Durchgeführt von | `<FRAMEWORK_OWNER>` |
+| Gegengezeichnet | *offen* |
+| Folge | `CR-2026-062`, Ziel-Release `0.40.0` |

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

@@ -0,0 +1,133 @@
+# Wirkungsnachweise zu Release 0.32.0
+
+| Feld | Wert |
+|---|---|
+| Gegenstand | Die Umsetzungen zu `CR-2026-052` (D-52 bis D-54, Befund **B09**) und `CR-2026-053` (D-55, D-56, Befund **B07**) |
+| Datum | 2026-09-13 |
+| Framework-Version | 0.32.0 (gegen 0.31.0 = `97052c1`) |
+| 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 |
+| Umgebung | Windows 11, Python 3.14.4 |
+| Ergebnis | **72 Sonden und Gegenproben bestehen gegen 0.32.0 in beiden Umgebungen.** Die drei neuen Prüfungen melden gegen 0.31.0 **acht** Fundstellen – und das sind genau die Befunde dieses Releases |
+
+## 1. Was hier nachgewiesen wird – und was nicht
+
+Beide Anträge sind in ihrem Kern **Textentscheidungen**. Ein Skript kann nicht prüfen, ob eine
+Einstufung richtig ist; es kann prüfen, ob alle Fassungen dieselbe Einstufung tragen und ob eine
+Entscheidung überhaupt getroffen wurde. Genau dort setzen die drei neuen Prüfungen an.
+
+| Gegenstand | Art | Nachweis |
+|---|---|---|
+| Prüfung 28 – Strukturpfad in der `<EXCLUDED_PATHS>`-Deklaration | neue Prüfung | drei Sonden, eine Gegenprobe |
+| Prüfung 29 – K3-Kategorien in fünf Fassungen, ohne Bedingung | neue Prüfung | drei Sonden, eine Gegenprobe |
+| Prüfung 30 – Vollständigkeit der Grenzfalltabelle | neue Prüfung | drei Sonden, eine Gegenprobe |
+| Abgrenzung zu V6 (D-53) | Textentscheidung | **keine Sonde** – siehe Abschnitt 6 |
+| R12 nach Schreibziel und Aufsicht (D-54) | Textentscheidung | **keine Sonde** – siehe Abschnitt 6 |
+| Entwicklungsprofil (D-56) | Dokument, kein Mechanismus | **keine Sonde** – siehe Abschnitt 6 |
+
+**Für drei der fünf Entscheidungen gibt es bewusst keine Sonde.** Eine Prüfung, die eine
+Formulierung bewacht, meldet jede Umformulierung und sonst nichts. Was sie tragen, ist die
+Grenzfalltabelle – und die ist maschinell auf Vollständigkeit geprüft, nicht auf Richtigkeit.
+
+## 2. Die neun neuen Sonden
+
+Jede Sonde präpariert eine Kopie des Repositoriums und erwartet eine bestimmte Meldung. Bleibt der
+Baum unverändert, meldet das Skript `[nichts praepariert]` – der Suchtext der Sonde passt dann
+nicht mehr, und gemessen würde die Sonde statt der Prüfung.
+
+| Sonde | Präparation | Erwartete Meldung | 0.32.0 | 0.31.0 |
+|---|---|---|---|---|
+| 28a | Strukturpfad in die `<EXCLUDED_PATHS>`-Zeile der Overlay-Vorlage | „Die Deklaration von `<EXCLUDED_PATHS>` nennt“ | gemeldet | Befund steht dort **von sich aus** |
+| 28b | dasselbe in der Laufzeitregel `20-*` | ebenda | gemeldet | ebenso |
+| 28c | Beschriftung der Deklaration umbenannt | „keine Zeile ist als Deklaration erkennbar“ | gemeldet | – |
+| 29a | Kategorie „Sicherheitskonfigurationen“ aus der Kurzform entfernt | „nennt die Kategorie … nicht“ | gemeldet | Befund steht dort **von sich aus** |
+| 29b | Bedingung an die Kategorie „interne Adressen“ angehängt | „traegt eine Bedingung“ | gemeldet | Befund steht dort **von sich aus** |
+| 29c | Anker „- Immer K3“ umbenannt | „ist nicht mehr auffindbar“ | gemeldet | – |
+| 30a | Grenzfallzeile G-07 gelöscht | „Grenzfallzeilen, der Steckbrief nennt“ | gemeldet | Datei fehlt dort ganz |
+| 30b | Spalte „Kontrollstufe“ in G-05 geleert | „ist leer“ | gemeldet | – |
+| 30c | Verweis auf D-53 aus allen Zeilen entfernt | „Keine Grenzfallzeile verweist auf D-53“ | gemeldet | – |
+
+**Zwei Sonden prüfen nicht die Sache, sondern die Prüfung selbst.** 28c und 29c verlieren den
+Anker, an dem die jeweilige Prüfung ihren Prüfgegenstand findet. Ohne diese Sonden hätte das
+Projekt zwei Konsistenzprüfungen, die beim ersten Umformulieren **leise bestehen** – der
+Befundtyp, den ERH-12 und die Lehre aus 0.27.0 beschreiben. Die Prüfungen melden das Fehlen
+deshalb selbst als Fehler.
+
+## 3. Die drei Gegenproben – und warum sie hier mehr wert sind als üblich
+
+| Gegenprobe | Präparation | Was sie ausschließt |
+|---|---|---|
+| 28 | Dieselben Strukturpfade **im Fließtext**, in einem Satz, der sie ausdrücklich ausschließt | Dass Prüfung 28 jede Nennung meldet statt der Deklaration. **Beide Träger enthalten genau so einen Satz** – eine Prüfung ohne diese Unterscheidung hätte den richtigen Text beanstandet |
+| 29 | Kurzform kürzer formuliert („Sicherheitskonfigurationen“ statt „… mit Schutzwirkung“), keine Kategorie weniger | Dass Prüfung 29 auf Wortgleichheit prüft statt auf Kategorien. Eine Kurzform **darf** kürzer sein |
+| 30 | Ein dreizehnter Grenzfall samt mitgezählter Anzahl im Steckbrief | Dass Prüfung 30 eine feste Zahl erwartet statt der mitgeführten |
+
+**Zur Ehrlichkeit der Gegenproben:** Die Gegenprobe zu 28 bestünde gegen 0.31.0 **aus dem falschen
+Grund** – dort gibt es die Prüfung nicht. Dasselbe gilt für 29 und 30. Der Wert dieser
+Gegenproben liegt allein gegen 0.32.0, und dort tragen sie: Sie belegen, dass die neuen Prüfungen
+unterscheiden und nicht pauschal melden. Dieselbe Einschränkung stand am 2026-09-12 viermal in den
+Protokollen und gehört auch hier hin.
+
+## 4. Der Gegenbeweis gegen den Vorstand
+
+Vorgehen: `git archive 97052c1` in ein leeres Verzeichnis, dort mit **dem eigenen** `install.py`
+des Vorstands installiert, dann **nur** `validate-framework.py` aus 0.32.0 hineinkopiert. Damit
+misst der neue Prüfsatz den alten Inhalt.
+
+```
+FEHLER  leitwerk-core/templates/project-overlay/OVERLAY.md:71       Prüfung 28
+FEHLER  leitwerk-core/framework/runtime/rules/20-project-overlay.md:23  Prüfung 28
+FEHLER  project-overlay/OVERLAY.md:71                                Prüfung 28 (Installation)
+FEHLER  .devin/rules/20-project-overlay.md:23                        Prüfung 28 (Installation)
+FEHLER  leitwerk-core/framework/core/02-privacy.md                   Prüfung 29 – Bedingung
+FEHLER  leitwerk-core/framework/runtime/root-instruction.md           Prüfung 29 – Sicherheitskonfigurationen fehlt
+FEHLER  leitwerk-core/framework/runtime/root-instruction.md           Prüfung 29 – Inhalte anderer Projekte fehlt
+FEHLER  leitwerk-core/tests/EDGE_CASES.md                             Prüfung 30 – fehlt
+Ergebnis: 8 Fehler, 0 Warnungen
+```
+
+Gegen 0.32.0 im selben Prüfsatz: **0 Fehler, 0 Warnungen.**
+
+**Das ist der stärkste Teil dieses Nachweises.** Die drei Prüfungen sind nicht auf einen
+präparierten Defekt zugeschnitten – sie finden die vier Befunde dieses Releases **im
+unveränderten Vorstand von selbst**: die fehlerhafte Ausschlussliste in Quelle und Installation,
+die Bedingung an einer unbedingten Kategorie und die zwei Kategorien, die der Kurzform fehlten.
+Zwei davon hat das externe Review nicht genannt; Prüfung 29 hätte sie gefunden, bevor jemand
+hinsah.
+
+## 5. Der Lauf in beiden Kodierungsumgebungen
+
+Auflage aus D-49: Der Sondenlauf gilt nur, wenn er in beiden Umgebungen läuft.
+
+| Umgebung | Sonden und Gegenproben | Ergebnis |
+|---|---|---|
+| ohne `PYTHONIOENCODING` | 72 | alle bestanden |
+| mit `PYTHONIOENCODING=utf-8` | 72 | alle bestanden |
+
+72 = 60 aus 0.31.0 plus zwölf neue (neun Sonden, drei Gegenproben). Der Validator meldet in beiden
+Umgebungen 0 Fehler und 0 Warnungen.
+
+## 6. Was dieses Release nicht nachweist
+
+- **Die Abgrenzung zu V6 (D-53) ist nicht maschinell geprüft.** Ob eine konkrete Änderung
+  Anwendungslogik oder Betrieb betrifft, entscheidet ein Mensch am Kriterium aus
+  `framework/core/09-risk-model.md`. Was geprüft ist: dass die Grenzfälle G-04 bis G-06 die
+  Entscheidung tragen und auf eine Fundstelle verweisen.
+- **R12 (D-54) ist nicht maschinell geprüft.** Die leere Schnittmenge ist im Text aufgelöst; dass
+  sie leer **war**, ist im Gegenprüfungsprotokoll belegt, nicht durch einen Lauf.
+- **Das Entwicklungsprofil (D-56) hat keinen Mechanismus und deshalb keine Sonde.** Es beschreibt
+  einen Kontext und hebt ausdrücklich keinen Schutz auf. Was es über den Shell-Kanal sagt, ist am
+  2026-09-12 gemessen (B04) und hier nicht erneut belegt.
+- **Prüfung 29 prüft Kategorien, nicht Semantik.** Sie erkennt eine fehlende Kategorie und eine
+  Bedingung aus einer festen Liste von Bedingungswörtern. Eine Bedingung, die anders formuliert
+  ist – „gilt nicht, wenn“ –, entgeht ihr. Die Liste ist erweiterbar und steht an einer Stelle.
+- **Kein Lauf gegen ein Projekt mit ausgefüllter `<EXCLUDED_PATHS>`-Liste.** Dass die fehlerhafte
+  Lesesperre tatsächlich in einer Berechtigungsdatei entsteht, ist **nicht** gemessen; belegt ist
+  der Weg dorthin. Kein ausgeliefertes Overlay füllt die Liste aus, weil die Vorlage `<TBD>`
+  liefert. Das gehört in einen AP2-Lauf mit einem ausgefüllten Overlay.
+- **`FW-KO-05` steht auf `offen`.** Ob ein KI-Client die zwölf Grenzfälle so einstuft, wie die
+  Tabelle es vorgibt, ist eine Sitzung und nicht gefahren.
+
+## 7. Gegenzeichnung
+
+| Rolle | Name/Kennung | Datum | Ergebnis bestätigt |
+|---|---|---|---|
+| `<FRAMEWORK_OWNER>` | `<TBD>` | `<TBD>` | `<TBD>` |