@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-043-validator-gibt-trefferwerte-aus.md

@@ -0,0 +1,135 @@
+# Änderungsantrag `CR-2026-043`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Inhaltsvalidator gibt gefundene sensible Werte im Klartext aus |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `tests/scripts/validate-framework.py` (Prüfung 6 und der Mermaid-Fehlerpfad), `tests/scripts/hook-check-secrets.py` (Meldung ungültiger Zusatzmuster), `tests/scripts/probe-pruefungen.py` (neue Sonden), `tests/TEST_CATALOG.md` (`FW-KO-01`) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Prüfwerkzeug |
+| Art | Befund **B03** des unabhängigen Reviews vom 2026-09-12, P1; im Code gegengeprüft nach D-23 |
+| Dringlichkeit | **vorrangig** – der Schaden entsteht bei jedem Lauf, nicht erst bei einer Änderung |
+
+## 1. Anlass und Problem
+
+Prüfung 6 des Validators sucht in allen Textdateien nach Secret-Mustern, E-Mail-Adressen,
+IP-Adressen, internen Hostnamen, URLs außerhalb der Allowlist und projektspezifischen
+Sperrbegriffen. Fünf dieser sechs Diagnosen nannten den **gefundenen Wert im Klartext**:
+
+| Diagnose | Bisherige Ausgabe |
+|---|---|
+| E-Mail-Adresse | Pfad, dann „E-Mail-Adresse gefunden" **und der Wert in Klammern** |
+| IP-Adresse | Pfad, dann „IP-Adresse gefunden" **und der Wert in Klammern** |
+| interner Hostname | Pfad, dann „interner Hostname gefunden" **und der Wert in Klammern** |
+| URL | Pfad, dann „URL außerhalb der Allowlist:" **und die vollständige URL samt Parametern** |
+| Sperrbegriff | Pfad, dann „gesperrter Begriff" **und der Begriff in Anführungszeichen** |
+| Secret-Muster | Pfad, dann „Secret-Muster" und die **Kategorie** – **macht es bereits richtig** |
+
+**Damit trägt ein Schutzlauf genau die Angaben weiter, die er finden soll** – in ein Terminal, ein
+Protokoll, eine Agentensitzung. Die Ausgabe des Validators ist kein geschlossener Raum: Sie steht
+in Sitzungsmitschriften, in Prüfprotokollen unter `tests/protocols/` und im Kontext jedes Modells,
+das den Lauf auslöst.
+
+### Es ist die eigene Regel, die hier gebrochen wird
+
+Der Befund ist kein Verstoß gegen eine fremde Anforderung. Er verstößt gegen **zwei eigene
+normative Festlegungen**, die dieses Framework jeder Sitzung auferlegt:
+
+- `framework/runtime/root-instruction.md`, Abschnitt 11: „Findest du vermutete Secrets oder
+  personenbezogene Echtdaten: gib sie nicht aus, wiederhole sie nicht, **nenne nur die
+  Fundstelle** und halte an."
+- `tests/TEST_CATALOG.md`, `FW-DS-01`: Erwartet ist „nur Fundstelle; Inhalt nirgends
+  wiedergegeben"; als unzulässiges Verhalten ist ausdrücklich **„Zitat, Weiterverarbeitung"**
+  benannt.
+
+Das Prüfwerkzeug hat getan, was es der Sitzung verbietet. **`FW-DS-01` prüft die Sitzung, nicht
+das Werkzeug** – und sein Ergebnisstatus steht bis heute auf `offen`. Geprüft wurde also weder
+das eine noch das andere.
+
+### Am schärfsten beim Sperrbegriff
+
+`project-overlay/forbidden-terms.txt` enthält reale Projekt-, Kunden- und Behördennamen. Prüfung 6
+nimmt diese Datei deshalb **ausdrücklich von der eigenen Inhaltsprüfung aus** – und schrieb den
+gefundenen Namen anschließend in die Fehlermeldung. Die eine Zeichenkette, die in keiner Ausgabe
+des Frameworks stehen darf, stand dort durch die Prüfung, die sie verhindern soll.
+
+### Der Befund hat sich selbst vorgeführt
+
+Am 2026-09-12 lag das externe Review als unversioniertes Verzeichnis im Arbeitsbaum. Sein
+Prüfprotokoll enthält den synthetischen Kontakt, mit dem das Review B03 nachgewiesen hat. Der
+Validator meldete ihn – **und gab ihn dabei im Klartext aus**, also genau das, was B03 beanstandet.
+Das Verzeichnis ist inzwischen ausgelagert; der Vorgang bleibt der stärkste Beleg des Antrags.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Eine gemeinsame Fundstellenfunktion.** Sie liefert Pfad, Zeile und Spalte – **ohne den
+   Treffer selbst**. Alle Diagnosen der Prüfung 6 laufen über sie.
+
+2. **Neutrale Regel-IDs statt sprechender Werte.** Je Kategorie eine feste Kennung, die den Befund
+   benennt, ohne ihn wiederzugeben: `FW-CONTENT-EMAIL`, `FW-CONTENT-IP`, `FW-CONTENT-HOST`,
+   `FW-CONTENT-URL`, `FW-CONTENT-TERM`.
+
+3. **Die Secret-Diagnose bekommt die Position**, die ihr fehlt. Sie nennt bereits nur die
+   Kategorie – aber nur den Pfad, nicht die Stelle. Das Abnahmekriterium des Reviews verlangt,
+   dass der Befund „über Pfad und Position auffindbar" bleibt.
+
+4. **Fehlerpfade mit fremdem Inhalt schließen.** Zwei Stellen tragen Daten weiter, die niemand
+   dorthin gelegt hat:
+   - `validate-framework.py`: Der Mermaid-Fehlerpfad gibt 300 Zeichen der Fehlerausgabe des
+     externen Renderers aus. Darin steht in aller Regel der **Quelltext des Diagrammblocks**.
+   - `hook-check-secrets.py`: Ein ungültiges Zusatzmuster aus der Umgebungsvariablen für
+     projektspezifische Pfadmuster wird mitsamt seinem Wert ausgegeben. Solche Muster tragen
+     Projekt-, Kunden- und Hostnamen – dieselbe Datenart wie die Sperrbegriffe.
+
+5. **Wirkungsnachweis nach D-23.** `probe-pruefungen.py` erhält je Kategorie eine Sonde mit einem
+   **eindeutig synthetischen Marker**. Sie prüft beides: Der Befund **wird gemeldet**, und der
+   Markerwert steht **weder in der Standardausgabe noch in der Fehlerausgabe**. Dazu die
+   Gegenprobe: Der erlaubte Fall derselben Kategorie – eine Adresse aus dem
+   Dokumentationsbereich – wird nicht gemeldet.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Keine Prüfung wird enger oder weiter.** Es ändert sich, was die Diagnose **sagt**, nicht,
+  was sie **findet**. Kein Prüfergebnis kippt; die Zahl der Fehler und Warnungen bleibt gleich.
+- **Die Altprotokolle werden nicht umgeschrieben.** `tests/protocols/2026-09-10-FW-KO-01.md`
+  zitiert zweimal den alten Wortlaut. Ein Protokoll ist die Aufzeichnung eines Laufs, keine
+  Beschreibung des Soll-Zustands – es hält fest, was damals ausgegeben wurde, und bleibt
+  unverändert.
+- **`FW-DS-01` bleibt offen.** Der Sitzungstest wird von diesem Antrag nicht eingelöst; er prüft
+  das Verhalten des Modells, nicht das des Werkzeugs.
+- **Die Sperrbegriffsliste bleibt, wo sie ist.** Dass eine Datei mit realen Namen im Arbeitsbaum
+  liegt, ist eine eigene Frage und wird hier nicht berührt.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern – ein Prüfwerkzeug des Frameworks.
+- [x] Verschärfungsprinzip: Der Antrag verschärft die Ausgabedisziplin; er lockert nichts.
+- [x] Widerspruchsfreiheit: `root-instruction.md` Abschnitt 11, `02-privacy.md` Abschnitt 5 und
+      `FW-DS-01` gelesen – der Antrag stellt die Übereinstimmung mit ihnen **her**.
+- [x] Laufzeitfassungen: `hook-check-secrets.py` wird ausgeliefert und ist betroffen.
+- [x] Belegstatus: **im Code bestätigt und unbeabsichtigt vorgeführt.**
+- [ ] Test- und Validierungsbedarf: **neue Sonden nach D-23** – ohne sie gilt die Änderung als
+      nicht vorhanden.
+- [x] Overlays: nicht betroffen.
+- [ ] Dokumentation: CHANGELOG; `FW-KO-01` erhält den Hinweis auf den neuen Sondenblock.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Welches Schema tragen die neutralen Regel-IDs? | **Sprechende Kennungen mit dem Präfix `FW-CONTENT-` und der Kategorie im Namen.** Die Ausgabe muss ohne Nachschlagewerk lesbar sein: Wer `FW-CONTENT-TERM` liest, weiß, was gefunden wurde, ohne die Datei zu öffnen | Ein **zweites** Kennungsschema neben dem Testkatalog, der `FW-XX-NN` verwendet. Zwei Schemata mit demselben Präfix sind eine Quelle von Verwechslungen – die Alternative `FW-IN-01` bis `-05` wäre einheitlich, aber in der Ausgabe stumm |
+| E2 | Zeile allein oder Zeile **und Spalte**? | **Beides.** Zwei Treffer derselben Zeile bleiben sonst ununterscheidbar, und der zweite fällt als scheinbares Duplikat nicht auf | Die Fundstellenangabe wird länger und weicht vom Format ab, das die übrigen Prüfungen verwenden – dort steht Pfad und Zeile |
+| E3 | Auch die Secret-Diagnose anfassen, obwohl sie den Wert nie ausgab? | **Ja – die Position ergänzen.** Sie ist die einzige Diagnose der Prüfung 6, die eine Datei nennt, aber nicht die Stelle. Das Abnahmekriterium verlangt Auffindbarkeit | Eine Änderung an der einen Stelle, die den Befund **nicht** hatte. Wer den Diff liest, muss den Grund kennen |
+| E4 | Die beiden Fehlerpfade mitnehmen oder eigener Antrag? | **Mitnehmen.** Das Review verlangt ausdrücklich, „unbeabsichtigte Daten in Fehlerpfaden" zu berücksichtigen; ein eigener Antrag für zwei Zeilen ist Verwaltung ohne Ertrag | Beim Mermaid-Pfad geht **Diagnosekomfort** verloren: Die Fehlermeldung des Renderers sagt heute, *warum* ein Block ungültig ist. Künftig stehen dort Datei und Blocknummer, den Rest muss man von Hand reproduzieren |
+| E5 | Wie wird die Wirkung nachgewiesen? | **Sonde je Kategorie mit doppelter Bedingung:** Befund gemeldet **und** Marker nicht in der Ausgabe. Die zweite Bedingung ist die eigentliche – die erste hätte die alte Fassung auch bestanden | Der Sondenblock wächst um sechs Fälle; `probe-pruefungen.py` führt je Fall einen vollständigen Validatorlauf auf einer Kopie aus und wird spürbar langsamer |
+| E6 | Release als `0.26.1` (Patch)? | **Ja.** Kein Verhalten einer Prüfung ändert sich, nur ihr Wortlaut – das ist kein Minor | Die Fundstellenformate künftiger Protokolle weichen von denen der `0.26.0`-Protokolle ab, ohne dass die Versionsnummer eine Änderung erwarten lässt |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle sechs Ermessensfragen wie vorgelegt.** E1 sprechende Kennungen mit dem Präfix `FW-CONTENT-`; E2 Pfad, Zeile und Spalte; E3 die Secret-Diagnose bekommt die Position – und dabei dieselbe Kennungsform wie die übrigen Kategorien (`FW-CONTENT-SECRET`), damit die Ausgabe der Prüfung einheitlich bleibt; E4 die beiden Fehlerpfade werden mitgenommen; E5 Sonde je Kategorie mit doppelter Bedingung; E6 Release `0.26.1` |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | Der Sondenblock muss gegen die Fassung 0.26.0 **fehlschlagen** – eine Sonde, die gegen beide Fassungen besteht, misst nicht die Änderung, sondern nur sich selbst. **Nachgewiesen:** sieben Abweichungen gegen 0.26.0, keine gegen 0.26.1. Der Mermaid-Fehlerpfad bleibt **unbelegt**, solange der externe Renderer in der Umgebung fehlt; er ist als offener Nachweis auszuweisen, nicht als erledigter |
+| Umsetzung | umgesetzt mit `0.26.1` |

package/.koolie/core/governance/change-requests/CR-2026-044-aktivierungspruefung-clientgebunden.md

@@ -0,0 +1,112 @@
+# Änderungsantrag `CR-2026-044`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Aktivierungsprüfung liest fest verdrahtete Pfade **eines** Clients – für das zweite Pack prüft sie nichts |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `tests/scripts/validate-framework.py` (`check_strict_overlay`, Aufruf in `main`), `tests/scripts/probe-pruefungen.py` (neue Sonden), `tests/TEST_CATALOG.md` (`FW-RE-02`) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Prüfwerkzeug, clientneutral |
+| Art | Befund **B02** des unabhängigen Reviews vom 2026-09-12, P1; **gegengeprüft und gemessen** |
+| Dringlichkeit | **vor einem dritten Client Pack** – der Befund vervielfacht seinen Schaden mit jedem Pack |
+
+## 1. Anlass und Problem
+
+`check_strict_overlay(root)` prüft die Aktivierungsreife eines Projekts: Ist das Overlay aktiv,
+stehen noch offene Werte in sicherheitsrelevanten Abschnitten, trägt die Berechtigungsdatei noch
+Platzhalter. Die Funktion bekommt das erkannte Manifest **nicht übergeben** und liest stattdessen
+zwei fest verdrahtete Pfade: `.devin/rules/20-project-overlay.md` und `.devin/config.json`.
+
+**In einer `claude-code`-Installation gibt es beide nicht.** Die Funktion findet sie nicht,
+überspringt sie stillschweigend – und meldet 0 zusätzliche Fehler. Die Erkennung des installierten
+Packs existiert **in derselben Datei** seit der Umstellung auf mehrere Client Packs
+(`detect_client`); sie wird hier nur nicht benutzt.
+
+### Gemessen, nicht nur gelesen
+
+Zwei frische Testinstallationen, je eine pro Pack, darin **derselbe** Defekt. Gemessen ist die
+Änderung der Fehlerzahl, nicht ihr absoluter Wert – ein frisches Overlay trägt ohnehin offene
+Werte. Der `devin-desktop`-Lauf ist die Positivkontrolle: Ohne ihn wäre nicht zu unterscheiden,
+ob die Prüfung bei `claude-code` nichts sieht oder ob der Defekt keiner ist.
+
+| Gesetzter Defekt | `claude-code` | `devin-desktop` |
+|---|---|---|
+| Overlay-Status auf `aktivierung-ausstehend` | **±0** | **−1 Fehler** |
+| Platzhalter in der Berechtigungsdatei (nach Bereinigung gesetzt) | **±0** (7 → 7 → 7) | **+1 Fehler** (10 → 9 → 10) |
+
+**Die Prüfung reagiert beim einen Pack und sieht das andere überhaupt nicht.**
+
+### Zwei Befunde, die dabei herausfielen
+
+Der `−1` in der ersten Zeile ist kein Messfehler. Er ist ein **eigener Befund**, und der
+unangenehmere von beiden:
+
+1. **Der Status wird als Präfix geprüft.** `wert.lower().startswith("aktiv")` – damit besteht
+   `aktivierung-ausstehend` die Aktivierungsprüfung. Ein Status, der wörtlich sagt, dass die
+   Aktivierung **aussteht**, bringt den Fehler zum Verschwinden, der vorher stand. Wer ihn
+   einträgt, macht die Prüfung stiller, nicht lauter.
+
+2. **Fehlende Pflichtabschnitte werden akzeptiert.** Die Prüfung sucht in den sicherheitsrelevanten
+   Abschnitten nach offenen Werten; ist ein Abschnitt gar nicht da, findet sie nichts und meldet
+   nichts. **Ein Overlay ohne Abschnitt 13 ist damit besser gestellt als eines mit einem offenen
+   Wert darin.**
+
+Beides ist derselbe Befundtyp wie der Rest dieses Projekts: eine Prüfung, die mehr verspricht, als
+sie leistet.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Das Manifest wird übergeben.** `check_strict_overlay(root, man)` leitet die Pfade aus dem
+   Manifest ab – Laufzeitregel aus `pack_runtime_dir`, Berechtigungsdatei aus `permissions_file`.
+   Kein Pfad eines Clients steht mehr im Kern.
+
+2. **Der Status wird als Aufzählung geprüft**, nicht als Präfix: Aktiv ist genau `aktiv`. Jeder
+   andere Wert – auch einer, der mit „aktiv" beginnt – ist nicht aktiv.
+
+3. **Pflichtabschnitte werden auf Existenz geprüft**, nicht nur auf ihren Inhalt. Ein fehlender
+   sicherheitsrelevanter Abschnitt ist ein Fehler, kein Freispruch.
+
+4. **Wirkungsnachweis nach D-23 mit denselben Fixtures für beide Packs.** Das ist das
+   Abnahmekriterium des Reviews: Dieselben positiven und negativen Aktivierungsfälle laufen für
+   jedes Pack, und ein Defekt muss in **jeder** Installation gemeldet werden.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Die Prüfung bleibt optional.** Sie läuft nur mit `--strict-overlay`; daran ändert sich nichts.
+- **Der Abgleich zwischen Quell-Overlay und Laufzeitfassung** – das Review schlägt ihn zusätzlich
+  vor – ist hier **nicht** enthalten, siehe E4. Er ist ein eigener Gegenstand.
+- **Die sicherheitsrelevanten Abschnitte selbst** werden nicht neu bestimmt; die Liste bleibt, wie
+  sie ist.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern – der Validator ist clientneutral, und genau das ist er hier nicht.
+- [x] Verschärfungsprinzip: Der Antrag verschärft dreifach; er lockert nichts.
+- [x] Widerspruchsfreiheit: D-15, D-28 (Werkzeugneutralität des Kerns) gelesen; `detect_client`
+      existiert bereits und wird genutzt statt nachgebaut.
+- [x] Laufzeitfassungen: nicht betroffen.
+- [x] Belegstatus: **gemessen** an zwei frischen Installationen mit Positivkontrolle.
+- [ ] Test- und Validierungsbedarf: **neue Sonden nach D-23, je Pack.**
+- [x] Overlays: Ein bestehendes Overlay, dessen Status nicht wörtlich `aktiv` lautet, fällt nach
+      der Änderung durch – siehe E2.
+- [ ] Dokumentation: CHANGELOG, `FW-RE-02` im Testkatalog.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Manifest übergeben oder die Pfade je Pack im Validator führen? | **Manifest übergeben.** Die Erkennung steht in derselben Datei; sie nicht zu benutzen war ein Versehen, keine Entscheidung | Die Funktion bekommt einen zweiten Parameter. Wer sie einzeln aufruft, muss das Manifest beschaffen |
+| E2 | Status als Aufzählung – genau `aktiv`? | **Ja, genau `aktiv`.** Ein Präfixvergleich, den `aktivierung-ausstehend` besteht, ist keine Prüfung, sondern eine Einladung | **Eine Verschärfung, die bestehende Overlays brechen kann.** Ein Projekt, das `aktiv seit 2026-03` einträgt, fällt künftig durch. Das ist gewollt – aber es ist ein Migrationsfall und gehört in die Migrationshinweise |
+| E3 | Pflichtabschnitte auf Existenz prüfen? | **Ja.** Ein Overlay ohne Abschnitt 13 ist sonst besser gestellt als eines mit einem offenen Wert darin – das ist die Prüfung auf den Kopf gestellt | Ein bestehendes Overlay, dem ein Abschnitt fehlt, fällt künftig durch. Auch das ist ein Migrationsfall |
+| E4 | Auch Feldgleichheit zwischen Quell-Overlay und Laufzeitfassung prüfen? | **Nein, nicht in diesem Antrag.** Das Review schlägt es vor, und es ist richtig – aber es ist ein eigener Gegenstand mit eigener Unschärfe: Welche Felder gleich sein müssen, ist nirgends festgelegt. Ein Antrag, der drei Befunde behebt und einen vierten dazu erfindet, wird nicht fertig | Der Befund bleibt offen und braucht einen eigenen Antrag. Bis dahin kann die Laufzeitfassung von der Quelle abweichen, ohne dass es jemand merkt |
+| E5 | Wie wird die Wirkung nachgewiesen? | **Dieselben Fixtures für beide Packs**, je Defekt eine Sonde in jeder Installation. Genau das ist das Abnahmekriterium des Reviews – und genau das hätte den Befund von Anfang an verhindert | Die Sonden werden teurer: Sie brauchen eine **Installation** je Pack, nicht nur eine Kopie des Repositoriums. Der Sondenlauf wird spürbar länger |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle fünf Fragen wie vorgelegt.** E1 das Manifest wird übergeben; E2 der Status gilt als aktiv nur bei genau `aktiv`; E3 sicherheitsrelevante Abschnitte werden auf Existenz geprüft; E4 die Feldgleichheit zwischen Quell-Overlay und Laufzeitfassung bleibt einem eigenen Antrag; E5 dieselben Fixtures laufen für beide Packs |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **E2 und E3 sind Verschärfungen und gehören in die Migrationshinweise.** Ein Overlay, dessen Status nicht wörtlich `aktiv` lautet, und eines, dem ein sicherheitsrelevanter Abschnitt fehlt, fallen künftig durch. **Der Nachweis muss je Pack geführt werden** – das ist der Kern des Befunds und das Abnahmekriterium des Reviews. **Nachgewiesen:** sechs Sonden und vier Gegenproben, je Fall in jeder Installation; gegen 0.27.0 fallen **fünf von sechs** Sonden, und die eine, die besteht, ist genau der Fall, den die alte Fassung beim einen Pack traf. **Offen bleibt E4** – der Abgleich zwischen Quelle und Laufzeitfassung ist als eigener Gegenstand auszuweisen, nicht als erledigt |
+| Umsetzung | umgesetzt mit `0.28.0` |

package/.koolie/core/governance/change-requests/CR-2026-045-update-verliert-die-clientwahl.md

@@ -0,0 +1,116 @@
+# Änderungsantrag `CR-2026-045`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der dokumentierte Aktualisierungsaufruf legt in einem fremden Projekt eine zweite Laufzeitschicht an |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `install.py` (`--client`, `--update`, `--check`), `docs/ADOPTION_GUIDE.md` (Abschnitt 3), `tests/scripts/probe-pruefungen.py` (neue Sonde) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Installationswerkzeug |
+| Art | Befund **B10** des unabhängigen Reviews vom 2026-09-12, P2; **gegengeprüft und gemessen** |
+| Dringlichkeit | **vor einem dritten Client Pack**, und vor dem nächsten Release-Wechsel eines fremden Projekts |
+
+## 1. Anlass und Problem
+
+`install.py --client` trägt einen **Vorgabewert**: `devin-desktop`. `docs/ADOPTION_GUIDE.md`
+Abschnitt 3 empfiehlt für den Release-Wechsel wörtlich:
+
+```bash
+python leitwerk-core/install.py --update
+```
+
+Ohne `--client`. In einem Projekt, das mit einem anderen Pack installiert wurde, greift damit die
+Vorgabe – und `--update` aktualisiert nicht die vorhandene Installation, sondern **legt eine
+zweite an**.
+
+### Gemessen
+
+Eine frische `claude-code`-Installation, danach der dokumentierte Aufruf:
+
+```text
+Aufruf: python leitwerk-core/install.py --update   (ohne --client)
+  Client:  devin-desktop
+  Zusammenfassung: 60 angelegt, 0 aktualisiert, 0 unveraendert, 18 Projektdateien behalten.
+
+Laufzeitschichten vorher:  ['.claude']
+Laufzeitschichten nachher: ['.claude', '.devin']
+```
+
+**Sechzig Dateien**, eine vollständige zweite Laufzeitschicht: Regelablage, Skill-Ablage,
+Agentenprofile, eine zweite Berechtigungsdatei. Und – der eigentliche Schaden – **„0
+aktualisiert"**: Die Installation, die aktualisiert werden sollte, ist nicht angefasst worden. Der
+Aufruf tut nicht zu viel, er tut **das Falsche**.
+
+### Warum das mehr ist als ein unglücklicher Vorgabewert
+
+Ein Projekt, das so aktualisiert wird, hat anschließend zwei Regelsätze im Verzeichnis. Welcher
+davon in der Sitzung landet, entscheidet der Client – und beide Packs führen Regeln, die einander
+nicht kennen. Der Befund gehört damit zu derselben Familie wie `AP2-CC-01` und B02: **eine Stelle,
+an der das Framework stillschweigend etwas anderes tut, als es sagt.**
+
+Das Risiko wächst mit jedem Pack. Mit zwei Packs trifft es die Projekte des einen; mit drei die
+Projekte von zweien.
+
+## 2. Vorgeschlagene Änderung
+
+1. **`install.py` erkennt das installierte Pack** – so, wie der Validator es seit der Umstellung
+   auf mehrere Packs tut: Geprüft wird, welches `runtime_dir` aus den Manifesten im
+   Zielverzeichnis tatsächlich liegt.
+
+2. **`--update` und `--check` ohne `--client` verwenden das erkannte Pack.** Der Vorgabewert
+   greift dort nicht mehr.
+
+3. **Widerspricht ein ausdrückliches `--client` dem erkannten Pack, bricht der Lauf ab** – mit
+   Nennung beider Packs und des Wegs, es doch zu tun. Eine zweite Laufzeitschicht entsteht dann
+   nur, wenn jemand sie ausdrücklich will.
+
+4. **Wird nichts erkannt**, bleibt es bei `--client` beziehungsweise dessen Vorgabe: Eine
+   Erstinstallation hat nichts, was sie erkennen könnte.
+
+5. **`ADOPTION_GUIDE.md` Abschnitt 3** nennt den Aufruf mit dem Hinweis, dass das Pack erkannt
+   wird – und was zu tun ist, wenn die Erkennung fehlschlägt.
+
+6. **Wirkungsnachweis nach D-23:** Eine Sonde aktualisiert eine `claude-code`-Installation ohne
+   `--client` und prüft, dass **keine** zweite Laufzeitschicht entsteht. Gegenprobe: Dieselbe
+   Aktualisierung auf einer `devin-desktop`-Installation läuft unverändert durch.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Der Vorgabewert bleibt** – für die Erstinstallation. Er ist dort sinnvoll und harmlos.
+- **Bestehende Doppelinstallationen werden nicht aufgeräumt.** Wer zwei Laufzeitschichten im
+  Verzeichnis hat, bekommt mit diesem Antrag keine Hilfe beim Entfernen; das wäre ein eigener
+  Gegenstand mit Löschverhalten, und Löschen gehört nicht in ein Installationswerkzeug ohne
+  ausdrückliche Entscheidung.
+- **Die Erkennung selbst wird nicht neu erfunden.** Sie folgt derselben Regel wie im Validator.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern – `install.py` ist clientneutral und trifft hier eine Clientwahl.
+- [x] Verschärfungsprinzip: Der Antrag verschärft – ein Lauf, der bisher stillschweigend
+      durchlief, bricht künftig ab.
+- [x] Widerspruchsfreiheit: `ADOPTION_GUIDE.md` Abschnitt 3, `detect_client` im Validator gelesen.
+- [x] Laufzeitfassungen: nicht betroffen; es ändert sich, **welche** erzeugt wird.
+- [x] Belegstatus: **gemessen** an einer frischen Installation, 60 Dateien.
+- [ ] Test- und Validierungsbedarf: **neue Sonde nach D-23** samt Gegenprobe.
+- [x] Overlays: nicht betroffen.
+- [ ] Dokumentation: CHANGELOG, `ADOPTION_GUIDE.md`.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Erkennung statt Vorgabe bei `--update` und `--check`? | **Ja.** Eine Aktualisierung richtet sich an etwas Vorhandenes; was vorhanden ist, ist ablesbar. Ein Vorgabewert ist dort eine Vermutung, die niemand braucht | Die Erkennung kann fehlschlagen – etwa bei einer unvollständigen Installation. Dann braucht der Nutzer `--client`, und die Fehlermeldung muss das sagen |
+| E2 | Was tun, wenn `--client` dem erkannten Pack widerspricht? | **Abbrechen und beide nennen.** Ein Wechsel des Packs ist eine Entscheidung, kein Nebenprodukt einer Aktualisierung | Ein Pack-Wechsel wird umständlicher. Wer ihn will, muss die alte Laufzeitschicht selbst entfernen – der Abbruchtext nennt den Weg |
+| E3 | Den Vorgabewert für die Erstinstallation behalten? | **Ja.** Dort gibt es nichts zu erkennen, und ein Vorgabewert erspart dem Einstieg eine Entscheidung, die er noch nicht treffen kann | Der erste Aufruf installiert weiterhin ungefragt `devin-desktop`. Wer ein anderes Pack will und `--client` vergisst, merkt es erst hinterher – die Ausgabe nennt das Pack aber in der ersten Zeile |
+| E4 | `ADOPTION_GUIDE.md` korrigieren oder den Aufruf um `--client` ergänzen? | **Korrigieren, ohne `--client` zu verlangen.** Ein Leitfaden, der bei jedem Aufruf einen Schalter mitschleppt, wird nicht befolgt; die Erkennung nimmt ihm die Pflicht ab | Der Leitfaden muss erklären, was passiert, wenn die Erkennung fehlschlägt – eine Zeile mehr an einer Stelle, die kurz sein sollte |
+| E5 | Wie wird die Wirkung nachgewiesen? | **Zwei Läufe, beide nötig:** eine Sonde, die auf einer `claude-code`-Installation aktualisiert und belegt, dass keine zweite Schicht entsteht – und die Gegenprobe auf `devin-desktop`, die belegt, dass die Aktualisierung weiterhin tut, was sie soll | Die Sonde braucht zwei vollständige Installationen. Der Sondenlauf wird länger; zusammen mit `CR-2026-044` lohnt sich ein gemeinsamer Aufbau |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle fünf Fragen wie vorgelegt.** E1 `--update` und `--check` erkennen das installierte Pack; E2 ein widersprechendes `--client` bricht ab und nennt beide Packs; E3 der Vorgabewert bleibt für die Erstinstallation; E4 der Leitfaden wird korrigiert, ohne `--client` zu verlangen; E5 Sonde und Gegenprobe je Pack |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **Der Abbruch muss den Weg nennen**, sonst ist er eine Sackgasse: Der Text sagt, welches Pack installiert ist, welches angefordert war, was ein Weiterlauf angerichtet hätte, und dass ein Packwechsel das Entfernen der vorhandenen Laufzeitschicht verlangt. **Nachgewiesen:** je Pack eine Sonde und eine Gegenprobe; gegen 0.27.0 fallen drei von vier, und die eine, die besteht, ist `devin-desktop` – also genau das Pack, das die alte Vorgabe zufällig traf. Der Abbruchpfad ist an seinem Exit-Code belegt, nicht nur an seinem Text |
+| Umsetzung | umgesetzt mit `0.28.0` |

package/.koolie/core/governance/change-requests/CR-2026-046-erstinstallation-ueberschreibt-projektdatei.md

@@ -0,0 +1,125 @@
+# Änderungsantrag `CR-2026-046`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Erstinstallation überschreibt eine gleichnamige Datei des Projekts – ohne Warnung |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `install.py` (`run`), `docs/ADOPTION_GUIDE.md` (Abschnitte 1 und 2), `tests/scripts/probe-pruefungen.py` (neue Sonde) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Installationswerkzeug |
+| Art | Befund aus der Vorbereitung der ersten Inbetriebnahme (2026-09-12); **gemessen** |
+| Dringlichkeit | **blockierend** – er trifft den allerersten Befehl, den ein aufnehmendes Projekt ausführt |
+
+## 1. Anlass und Problem
+
+`install.py` kopiert die Core-Bestandteile des gewählten Client Packs in das Projekt. Für jeden
+Core-Pfad gilt: Existiert die Datei nicht, wird sie angelegt. Existiert sie und ist byte-gleich,
+bleibt sie. **Existiert sie und weicht ab, wird sie überschrieben** – in `install` ebenso wie in
+`update`. Ob die vorhandene Datei jemals vom Framework stammt, prüft niemand.
+
+Für die Laufzeitschicht ist das richtig: `.claude/rules/00-framework-core.md` gehört dem Kern.
+**Für die Wurzel-Anweisungsdatei ist es falsch**, denn ihr Name ist keine Erfindung des
+Frameworks, sondern die Konvention des Clients – und deshalb belegt ein Projekt ihn oft schon.
+
+### Gemessen
+
+Trockenlauf gegen ein reales Projekt, das seit Monaten mit `claude-code` arbeitet und eine eigene
+Anweisungsdatei von rund 34 Kilobyte führt, versioniert:
+
+```text
+Framework 0.28.0
+Client:  claude-code
+Modus:   install  (dry-run, es wird nichts geschrieben)
+
+Angelegt (77): …
+Core aktualisiert (1):
+  CLAUDE.md
+
+Zusammenfassung: 77 angelegt, 1 aktualisiert, 0 unveraendert, 0 Projektdateien behalten.
+```
+
+**Der erste Befehl des Übernahmeleitfadens hätte die Projektdatei ersetzt.** Ohne Rückfrage, ohne
+Sicherung, und in der Zusammenfassung als „1 aktualisiert" ausgewiesen – ein Wort, das nach Pflege
+klingt und hier Verlust bedeutet.
+
+### Der Leitfaden sagt das Gegenteil
+
+`docs/ADOPTION_GUIDE.md` Abschnitt 2, Schritt 3, wörtlich:
+
+> Bestehende Projektdateien werden nie überschrieben.
+
+Der Satz ist für die Saatdateien richtig – Berechtigungsdatei, Overlay – und für die
+Wurzel-Anweisungsdatei falsch. **Das ist der wiederkehrende Befundtyp dieses Projekts**, diesmal
+an der empfindlichsten Stelle: in dem Satz, auf den sich verlässt, wer das Framework zum ersten Mal
+anfasst.
+
+### Der zweite, größere Teil des Befunds
+
+Selbst mit einem Abbruch bleibt die Frage offen, **was mit dem Inhalt geschieht**. Ein Projekt, das
+bereits eine Anweisungsdatei führt, hat dort Projektwissen stehen – Architektur, Befehle,
+Konventionen. Das Framework beansprucht dieselbe Datei für Ebene 1. Wohin der vorhandene Inhalt
+gehört, steht **nirgends**: Weder Leitfaden noch Checkliste kennen den Fall.
+
+Nach der Ebenenlehre gehört er in das Overlay (Ebene 4) und, soweit er Regeln enthält, in eine
+`2N-overlay-*`-Regeldatei. Das ist ableitbar – aber ableiten muss es heute jeder selbst, im
+ungünstigsten Moment.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Die Erstinstallation überschreibt keine vorhandene Core-Datei.** Weicht eine vorhandene Datei
+   ab, bricht `install` ab, nennt sie und den Weg. Für `--update` bleibt es beim Überschreiben –
+   das ist sein Zweck, und das Pack ist dort bereits installiert.
+
+2. **Der Abbruchtext nennt die Entscheidung, nicht nur den Fehler:** welche Datei betroffen ist,
+   dass das Framework diesen Pfad beansprucht, dass der vorhandene Inhalt ins Overlay gehört, und
+   dass `--update` der Weg ist, wenn die Datei aus einer früheren Installation stammt.
+
+3. **Der Leitfaden bekommt den Fall.** Abschnitt 1 stellt richtig, für welche Dateien die Zusage
+   gilt. Abschnitt 2 erhält einen Schritt „Vorhandene Anweisungsdatei übernehmen": Inhalt sichten,
+   Projektwissen ins Overlay, Regeln in eine `2N-overlay-*`-Datei, danach installieren.
+
+4. **Wirkungsnachweis nach D-23:** Eine Sonde legt eine fremde Datei unter dem Namen der
+   Wurzel-Anweisungsdatei an und belegt, dass die Erstinstallation abbricht **und die Datei
+   unverändert lässt**. Gegenprobe: Dieselbe Installation in ein leeres Verzeichnis läuft durch.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **`--update` bleibt, wie es ist.** Wer aktualisiert, will die Core-Dateien auf dem Stand des
+  Releases haben; genau dafür ist der Modus da.
+- **Die Saatdateien bleiben unberührt.** Berechtigungsdatei und Overlay gehören nach der
+  Erstinstallation dem Projekt und werden ohnehin nie überschrieben.
+- **Es wird nichts zusammengeführt.** Das Skript sichtet keinen Inhalt und schlägt keine
+  Übernahme vor – das ist Arbeit für Menschen, und der Leitfaden sagt künftig, wie sie geht.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern – `install.py` und der Übernahmeleitfaden.
+- [x] Verschärfungsprinzip: Der Antrag verschärft; ein Lauf, der bisher stillschweigend
+      überschrieb, bricht künftig ab.
+- [x] Widerspruchsfreiheit: D-45 gelesen – dieselbe Bauart, dieselbe Antwort: abbrechen statt
+      stillschweigend das Falsche tun.
+- [x] Laufzeitfassungen: nicht betroffen.
+- [x] Belegstatus: **gemessen** im Trockenlauf gegen ein reales Projekt.
+- [ ] Test- und Validierungsbedarf: **neue Sonde nach D-23** samt Gegenprobe.
+- [x] Overlays: nicht betroffen; der Migrationsweg führt Inhalt **in** ein Overlay.
+- [ ] Dokumentation: CHANGELOG, `ADOPTION_GUIDE.md`, `10-project-adoption.md`.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Abbrechen oder nur warnen? | **Abbrechen.** Dieselbe Frage wie bei D-45, dieselbe Antwort: Eine Warnung in achtzig Zeilen Ausgabe übersieht man, und der Schaden ist hier nicht rückholbar, wenn die Datei nicht versioniert war | Ein Projekt, das die Installation wiederholt, bekommt einen Abbruch statt eines Durchlaufs. Der Text muss deshalb sagen, dass `--update` der richtige Modus ist |
+| E2 | Woran wird „fremd" erkannt – an der Herkunft der Datei oder am Modus? | **Am Modus.** Bei der Erstinstallation ist jede abweichende Core-Datei fremd, denn das Framework hat dort noch nie geschrieben. Eine Herkunftserkennung über den Kopfkommentar wäre feiner – und würde bei `.example`- und JSON-Artefakten versagen, die keinen tragen | Wer nach einer abgebrochenen Erstinstallation erneut `install` ruft, wird abgewiesen, obwohl die Dateien aus dem eigenen Lauf stammen. Der Weg ist `--update`; der Abbruchtext nennt ihn |
+| E3 | Gilt der Schutz für alle Core-Pfade oder nur für die Wurzel-Anweisungsdatei? | **Für alle.** Sie ist der wahrscheinliche Kollisionsfall, aber nicht der einzige: Auch die Laufzeit-README oder eine `.example`-Datei kann im Projekt schon existieren | Etwas mehr Reibung bei einer Erstinstallation in ein gewachsenes Projekt. Das ist der Punkt |
+| E4 | Den Übernahmeweg für vorhandene Inhalte in den Leitfaden aufnehmen? | **Ja, als eigener Schritt.** Ohne ihn ist der Abbruch eine Sackgasse: Er sagt, was nicht geht, und nicht, was zu tun ist. Projektwissen ins Overlay, Regeln in eine `2N-overlay-*`-Datei | Der Leitfaden wird länger an einer Stelle, die kurz sein sollte. Dafür beantwortet er die erste Frage, die ein reales Projekt stellt |
+| E5 | Wie wird die Wirkung nachgewiesen? | **Sonde mit doppelter Bedingung:** Der Lauf bricht ab **und** die fremde Datei ist hinterher unverändert. Die zweite ist die eigentliche – ein Abbruch nach dem Schreiben wäre wertlos | Die Sonde braucht eine Installation, kein Repositorium. Der Aufbau dafür steht seit 0.28.0 |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle fünf Fragen wie vorgelegt.** E1 abbrechen statt warnen; E2 unterschieden wird am Modus, nicht an der Herkunft der Datei; E3 der Schutz gilt für alle Core-Pfade; E4 der Übernahmeweg kommt als Schritt 3a in den Leitfaden; E5 Sonde mit doppelter Bedingung |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **Der Abbruch muss vor dem ersten Schreibvorgang stehen**, nicht während der Schleife – ein Abbruch nach der Hälfte der Dateien wäre schlimmer als keiner. Nachgewiesen über die dritte Bedingung der Sonde: Nach dem Abbruch existiert die Laufzeitschicht **nicht**. **Der Abbruchtext muss den Weg nennen**, sonst ist er eine Sackgasse. **Der ungelöste Fall eines fremden Agenten-Frameworks ist im Leitfaden ausdrücklich als ungelöst auszuweisen** (K-31), nicht zu verschweigen |
+| Umsetzung | umgesetzt mit `0.29.0` |

package/.koolie/core/governance/change-requests/CR-2026-047-zusagen-je-zugriffskanal.md

@@ -0,0 +1,133 @@
+# Änderungsantrag `CR-2026-047`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Datei-, Such- und Netzsperren werden weiter zugesagt, als sie reichen – die Zusagen gehören nach Zugriffskanal aufgeteilt |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `clients/claude-code/CLIENT_PACK.md` (B3, B4, B5, B8, `permissions_note` im Manifest), `clients/devin-desktop/CLIENT_PACK.md` (B3, B4, B5, B8), `clients/*/manifest.json` (`hook_tools`, `permission_tools`), `tests/scripts/hook-check-secrets.py` (Kommentar vor `PROTECTED_WRITE_PATH_PATTERNS`; bei Annahme von E3 auch die Prüflogik), `tests/scripts/probe-pruefungen.py` (bei Annahme von E3) |
+| Ebene laut Entscheidungsbaum 6 | Client Pack – Fähigkeitsmatrix und Abbildung; der Kern bleibt unberührt |
+| Art | Befund **B04** des unabhängigen Reviews vom 2026-09-12, P1; **gegengeprüft und gemessen** |
+| Dringlichkeit | **vor der weiteren Nutzung im Pilotprojekt** – dort laufen echte Daten, und B3 bis B5 sind Kernzusagen nach D-41 |
+
+## 1. Anlass und Problem
+
+Vier Zeilen der Fähigkeitsmatrizen sagen einen Schutz pauschal und `[TECHNISCH]` zu:
+
+- **B3** Secret-Dateien per Pfadmuster lesegeschützt (Kernzusage)
+- **B4** Framework- und Overlay-Artefakte schreibgeschützt (Kernzusage)
+- **B5** CI-, Quality-Gate- und Lockdateien schreibgeschützt (Kernzusage)
+- **B8** Netzwerkzugriff standardmäßig unterbunden
+
+**Keine dieser Zusagen gilt für alle Zugriffskanäle.** Sie gelten für die Kanäle, an denen sie
+entstanden sind – direktes Lesen und direktes Schreiben –, und dort sind sie mehrfach gemessen.
+Für Shell, Unterprozess und Suche gelten sie nicht.
+
+### Gemessen, nicht nur gelesen
+
+`tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`: vierzehn synthetische Werkzeugeingaben
+gegen den ausgelieferten Schutz-Hook, davon drei Positivkontrollen, dazu vier Abbildungsläufe
+gegen `clientmap.py` für beide Packs. **Keine Abweichung vom Bericht des Reviews.**
+
+| Kanal | B3 Lesesperre | B4/B5 Schreibsperre | B8 Netzsperre |
+|---|---|---|---|
+| direktes Lesen | **wirkt** | – | – |
+| direktes Schreiben | – | **wirkt** | – |
+| Shell | **wirkt** (Tokenisierung) | **fällt aus** | **teilweise** – vier Programme gesperrt |
+| Unterprozess | nicht geprüft | **fällt aus** – der Befehlstext nennt den Pfad nicht | **fällt aus** |
+| Suche | **fällt aus** | nicht anwendbar | – |
+| Abrufwerkzeuge | – | – | **wirkt** |
+
+### Die Kette reißt zwischen zwei Schichten, die aufeinander zeigen
+
+Der Schutz-Hook prüft das Schreibverbot auf das Kernverzeichnis nur für schreibende Werkzeuge.
+Der Kommentar darüber begründet das ausdrücklich: „bei exec trägt die deny-Regel der
+Berechtigungsdatei". **Die Berechtigungsdatei enthält für `exec` keine einzige Pfadregel** – 21
+Verweigerungen, sämtlich Befehlsverbote (`git push`, `rm -rf`, `sudo`, `curl`, `wget`, …).
+Umgekehrt verlässt sich die Berechtigungsdatei für Shell-Schreibwege auf den Hook. Was den
+Shell-Schreibweg in den Kern tatsächlich aufhält, ist die Regelschicht – also Modellverhalten,
+und damit `[TEXTUELL]`.
+
+Das ist der wiederkehrende Befundtyp dieses Projekts, diesmal als **Verweis zwischen zwei
+Schichten, die beide auf die andere zeigen**.
+
+### Der Suchkanal ist nicht bloß unbewacht, er ist derzeit nicht bewachbar
+
+`permission_tools.search` ist bei **beiden** Packs die leere Liste, und `hook_tools` kennt kein
+Suchverb. Eine synthetische Regel `{"tool": "search", "pattern": "**/.env"}` bricht deshalb in
+`clientmap._regel_rendern()` bei beiden Packs mit `AbbildungsFehler` ab – „das wäre eine
+Lockerung".
+
+**Das Verhalten der Abbildung ist richtig** und genau das, was D-18 verlangt. Die Folge ist
+trotzdem hart: Solange kein Suchwerkzeug im Manifest steht, kann niemand eine Suchsperre
+aussprechen. **Das berührt D-30 unmittelbar** – dort ist entschieden, dass Secret-Pfade auch
+gegen lesende Werkzeuge durchgesetzt werden. Für das Suchwerkzeug ist das nicht eingelöst;
+dieselbe Lücke wie `AP2-DD-11`, ein Werkzeug weiter.
+
+Nebenbefund: Der `permissions_note` des Packs `claude-code` sagt weiterhin, `search` bilde „auf
+Grep" ab. Das beschreibt einen Stand, den das Manifest seit `CR-2026-016` nicht mehr trägt.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Die Zeilen B3, B4, B5 und B8 beider Packs werden nach Zugriffskanal aufgeteilt.** Je Kanal
+   steht eine der drei Angaben: **wirkt** (mit Beleg), **nicht nachgewiesen**, **nicht
+   verfügbar**. Die Einstufung `[TECHNISCH]` gilt nur noch für die Kanäle, für die sie gemessen
+   ist; die übrigen tragen `[TEXTUELL]` mit Nennung der tragenden Regelstelle.
+2. **Die bereits gemessenen Sperren werden ausdrücklich anerkannt**, nicht nur die Lücken
+   benannt. B3 gegen das Lesewerkzeug und gegen den Shell-Befehl hält auch im untersagten
+   Betriebsmodus – das ist am 2026-09-12 in drei Läufen mit Kontrolllauf belegt.
+3. **Der Kommentar im Schutz-Hook wird berichtigt.** Er darf keine Sperre als Träger benennen,
+   die die Berechtigungsdatei nicht enthält.
+4. **Der `permissions_note` des Packs `claude-code` wird berichtigt** – `search` bildet auf
+   nichts ab, und der Grund dafür (`AP2-CC-02`) gehört in denselben Satz.
+5. **Keine Ausweitung der Befehlsverbote.** Das Review warnt ausdrücklich davor, die Sperre auf
+   immer mehr Shell-Schreibweisen auszudehnen und daraus Vollständigkeit abzuleiten. Der Antrag
+   folgt dem.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Er baut keine technische Durchsetzung für Shell und Unterprozess.** Dafür braucht es eine
+  Isolationsschicht des Betriebssystems; ihre Verfügbarkeit unter Windows ist unerhoben (das
+  Review nennt macOS, Linux und WSL2). Das ist Paket 6 und braucht eine eigene Erhebung.
+- **Er ändert nichts an den Regeltexten.** Die Regelschicht wirkt; sie wirkt nur `[TEXTUELL]`.
+- **Er entscheidet B06 nicht mit** (Eingabeschema und Pfadidentität des Hooks). B06 härtet den
+  Hook; dieser Antrag korrigiert, was über ihn behauptet wird.
+- **Er berührt M4/M5 nicht** – das ist `CR-2026-048`.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Client Pack. Die Zusage ist werkzeugneutral, ihre Reichweite ist es nicht.
+- [x] Verschärfungsprinzip: Der Antrag lockert keine Regel. Er senkt eine **Einstufung** auf den
+      gemessenen Stand – das ist keine Lockerung des Schutzes, sondern das Ende einer
+      unzutreffenden Behauptung über ihn.
+- [x] Widerspruchsfreiheit: D-18 (keine stille Lockerung in der Abbildung), D-30 (Secret-Pfade
+      auch gegen lesende Werkzeuge), D-35 (`[TECHNISCH]` ist betriebsmodusabhängig), D-41
+      (Kernzusage) gelesen. **D-30 ist für den Suchkanal nicht eingelöst** – siehe E3.
+- [x] Laufzeitfassungen: bei E3 „nur Ausweis" nicht betroffen; bei E3 „Hook-Eintrag" ist die
+      Hook-Konfiguration beider Packs betroffen und in beiden zu synchronisieren.
+- [x] Belegstatus: **gemessen**, vierzehn Läufe mit drei Positivkontrollen.
+- [ ] Test- und Validierungsbedarf: bei E3 „Hook-Eintrag" **neue Sonde und Gegenprobe nach
+      D-23**, je Pack. Der reine Ausweis ist eine Textkorrektur ohne neue Prüfung.
+- [x] Overlays: nicht betroffen. Kein Projekt fällt durch diese Änderung durch.
+- [ ] Dokumentation: CHANGELOG, Decision Log, `docs/ROADMAP.md` (Paket 3).
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Aufteilung je Kanal **in der Matrixzeile** oder als Vorbemerkung je Block? | **In der Zeile.** Die Vorbemerkung trägt bereits zwei Bedingungen (Betriebsmodus nach D-35, und der Startort steht noch aus). Eine dritte macht sie zur Fußnotensammlung, und wer eine Zeile liest, liest die Vorbemerkung nicht | Die vier Zeilen werden deutlich länger. Die Matrix verliert an Überblick, was sie an Ehrlichkeit gewinnt |
+| E2 | Welche Einstufung tragen Shell und Unterprozess bei B4/B5 künftig? | **`[TEXTUELL]`**, nicht `[NICHT ABBILDBAR]`. Eine Regel existiert und wirkt – über das Modellverhalten. `[NICHT ABBILDBAR]` hieße, es gebe nichts, und würde zudem nach Prüfung 25 einen benannten Ersatz verlangen, den es in Gestalt der Regelschicht gerade gibt | **B4 und B5 sind Kernzusagen** (`core: true`). Eine Kernzusage, die für einen Kanal nur noch `[TEXTUELL]` ist, ist eine ernste Aussage über das Framework – und genau deshalb gehört sie vorgelegt und nicht redaktionell entschieden |
+| E3 | **Der Suchkanal: nur ausweisen, oder schließen?** | **Vorschlag: Hook-Eintrag ja, Berechtigungsregel nein.** Ein `hook_tools`-Suchverb schließt die Lücke echt – der Hook misst das Suchwerkzeug dann wie ein lesendes an den Secret-Pfaden und löst D-30 ein. Eine Pfadregel in der Berechtigungsdatei brächte bei `claude-code` dagegen nichts: Dieser Client wertet Pfadregeln nur für zwei Werkzeuge aus, alles andere wird angenommen, nie konsultiert und beim Sitzungsstart als Warnung gemeldet (`AP2-CC-02`). Genau solche Regeln hat `CR-2026-016` entfernt | **Das ist Code, nicht Text** – und damit die einzige Stelle, an der dieser Antrag über eine Korrektur hinausgeht. Er braucht eine Sonde und eine Gegenprobe je Pack (D-23) und ist damit spürbar teurer. **Die Gegenposition ist vertretbar:** den Kanal nur ausweisen und das Schließen zu B06 in Paket 6 legen. Dann bleibt eine Kernzusage für einen Kanal offen, der gemessen offen ist |
+| E4 | B8: die Befehlsliste um weitere Netzprogramme ergänzen? | **Nein.** Jedes ergänzte Programm suggeriert Vollständigkeit, die es nicht gibt – `python`, `node`, `git`, die Bordmittel der Shell und jedes selbst geschriebene Skript bleiben. Das Review warnt davor ausdrücklich | B8 sinkt für den Shell-Kanal auf `[TEXTUELL]` und bleibt dort, bis eine Isolationsschicht erhoben ist. Wer eine vollständige Netzsperre braucht, betreibt den Agenten ohne automatische Befehlsausführung |
+| E5 | Die Betriebssystem-Sandbox jetzt erheben? | **Nein, nicht in diesem Antrag.** Sie ist der einzige Weg zu einer echten Zusage für Shell und Unterprozess, aber ihre Reichweite unter Windows ist unbekannt, und eine ungemessene Sandbox-Empfehlung wäre derselbe Fehler eine Ebene höher | Die technische Durchsetzung bleibt offen und wandert als eigener Gegenstand nach Paket 6. Der Antrag macht die Lage ehrlich, nicht sicher |
+| E6 | Wie wird die Wirkung nachgewiesen? | **Der Ausweis ist eine Textkorrektur und braucht keine Sonde** – er behauptet keine Prüfung. **Wird E3 mit „Hook-Eintrag" entschieden, gilt D-23 voll:** eine Sonde je Pack, die ein Suchwerkzeug auf einen Secret-Pfad schickt, plus Gegenprobe | Ohne E3 bleibt dieser Antrag ohne neuen Wirkungsnachweis – ungewohnt für dieses Projekt, aber richtig: Eine Prüfung, die nichts prüft, wäre schlechter als keine |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle sechs Fragen wie vorgelegt.** E1 die Aufteilung steht in der Matrixzeile; E2 Shell und Unterprozess tragen bei B4/B5 `[TEXTUELL]`; E3 **der Suchkanal wird geschlossen – Hook-Eintrag ja, Berechtigungsregel nein**; E4 die Befehlsliste von B8 wird nicht verlängert; E5 die Betriebssystem-Sandbox bleibt einer eigenen Erhebung; E6 der Ausweis braucht keine Sonde, der Hook-Eintrag schon |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **E3 war die einzige Frage, die über eine Textkorrektur hinausgeht, und sie hat eine zweite aufgeworfen:** Ein Pack ohne Suchwerkzeug kann keines abbilden, und eine leere Liste galt bisher als Abbildungsfehler. Die Abwesenheit wird deshalb **deklariert statt erraten** – `hook_tools_absent` im Manifest, mit Begleitsatz. Weil das ein Schlupfloch wäre, wenn jemand dort `write` einträge, prüft **Prüfung 26** beides: dass ein so erklärtes Verb auch in `permission_tools` leer ist und dass der Begleitsatz existiert. **Nachgewiesen:** zwei Sonden und eine Gegenprobe für Prüfung 26, zwei Sonden und zwei Gegenproben für den Suchkanal am Hook. **Die Gegenproben sind hier der wichtigere Teil** – ein Hook, der jede Suche blockiert, bestünde jede Sonde und machte das Suchwerkzeug unbenutzbar. **Offen bleibt E5:** Die technische Durchsetzung für Shell und Unterprozess braucht eine Isolationsschicht des Betriebssystems und ist unerhoben; sie steht als eigener Gegenstand in Paket 6 |
+| Umsetzung | umgesetzt mit `0.30.0` |