@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-052-drei-regelkonflikte.md

@@ -0,0 +1,166 @@
+# Änderungsantrag `CR-2026-052`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Drei normative Regeln widersprechen sich – K3-Einstufung, Sicherheitskonfiguration, Parallelität |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-13 |
+| Betroffene Artefakte | `framework/core/02-privacy.md`, `framework/core/09-risk-model.md`, `framework/core/05-working-model.md`, `framework/runtime/root-instruction.md`, `governance/PRIORITY_HIERARCHY.md`, `framework/org-policies/MAPPING_CLASSIFICATION.md`, `tests/EDGE_CASES.md` (neu), `tests/scripts/validate-framework.py` (Prüfungen 29, 30), `tests/scripts/probe-pruefungen.py` |
+| Ebene laut Entscheidungsbaum 6 | **Core und Governance** – es sind Datenschutz-, Sicherheits- und Risikoregeln der Ebene 3 |
+| Art | Befund **B09** des unabhängigen Reviews vom 2026-09-12, P2; **gegengeprüft, im Text bestätigt und in einem Punkt verschärft** |
+| Dringlichkeit | **Paket 4** – das Review entscheidet diese Konflikte ausdrücklich nicht; ohne Entscheidung des `<FRAMEWORK_OWNER>` ist nichts umsetzbar |
+
+## 1. Anlass und Problem
+
+Drei Regelbereiche geben auf dieselbe Frage verschiedene Antworten. **Alle drei sind
+gegengeprüft**, jede Fundstelle im Text nachgelesen
+(`tests/protocols/2026-09-13-B07-B09-gegenpruefung.md`).
+
+### 1.1 K3 – drei Texte, drei Antworten
+
+| Stelle | Aussage |
+|---|---|
+| `framework/runtime/root-instruction.md:84` | „Immer K3: … interne Adressen und Umgebungskennungen“ – **ohne Bedingung** |
+| `framework/core/02-privacy.md:33` | dieselbe Kategorie, **„sofern nicht im Overlay ausdrücklich als K1 eingestuft“** |
+| `framework/core/02-privacy.md:42` | das Overlay darf lockern, wenn die Datenschutz- und Vertragsprüfung es erlaubt |
+| `governance/PRIORITY_HIERARCHY.md:31` | „Delegationsverbote und K3 sind ebenenfest“ – **von keiner tieferen Ebene aufhebbar** |
+
+**Die Zeilennummern des Reviews stimmen für die Wurzel-Anweisungsdatei nicht** (dort steht 83
+statt 84 und 90 statt 91). Inhaltlich ist der Befund vollständig bestätigt.
+
+**Die Gegenprüfung hat zwei eigene Feststellungen ergeben, die das Bild verschieben:**
+
+1. **Es ist keine Pattsituation, sondern eine Minderheitsmeinung.** Acht weitere Stellen führen
+   dieselbe Liste **ohne Bedingung**: die Laufzeitregel `framework/runtime/rules/10-privacy-security.md`,
+   Entscheidungsbaum `decision-trees/01-context-allowed.md`, die Checkliste
+   `checklists/02-privacy-context.md`, `onboarding/REFERENCE.md`, `onboarding/QUICKSTART.md`,
+   `onboarding/KNOWLEDGE_CHECK.md` sowie `prompts/01-understand-codebase.md` und `prompts/10-documentation.md`. Die Bedingung steht an
+   **einer** Stelle – und diese eine Stelle ist die kanonische Langform.
+2. **Die Kurzform ist zwei Kategorien zu kurz.** Abschnitt 2.1 führt acht Kategorien; die
+   Wurzel-Anweisungsdatei nannte sechs. Es fehlten **Sicherheitskonfigurationen mit
+   Schutzwirkung** und **Inhalte anderer Projekte oder Mandanten** – und die Kurzform ist die
+   Fassung, die in jede Sitzung lädt. Die Laufzeitregel `10-*` und die Checkliste führen alle
+   acht; der Ausreißer ist die Kurzform. **Das hat das Review nicht gefunden.**
+
+Ein zusätzlicher Träger kam dazu: `framework/org-policies/MAPPING_CLASSIFICATION.md:12` bot für
+die Organisationsstufe „vertraulich“ eine Lockerung auf K2 an. Diese Stufe ist Kategorie 7 aus
+Abschnitt 2.1 – die Lockerungszusage widersprach damit derselben Regel.
+
+### 1.2 Sicherheitskonfiguration – Freigabe gegen Delegationsverbot
+
+`framework/runtime/root-instruction.md:91` lässt die Umsetzung nach dokumentierter Freigabe zu.
+**V6** (`framework/core/09-risk-model.md:64`) nennt „Änderungen an Produktionssystemen,
+Infrastruktur, Berechtigungen, Sicherheitskonfigurationen“ **nicht delegierbar** und lässt nur
+Analyse und Planvorschlag zu. Nach `governance/PRIORITY_HIERARCHY.md` Regel 2.4 ist die V-Liste
+ebenenfest – die Wurzel-Anweisungsdatei kann sie nicht lockern.
+
+**Eigene Feststellung:** Der Widerspruch ist nicht vollständig, sondern **teilweise**. Die
+Kontrollstufentabelle desselben Moduls sieht Controlled Modification bei Kontrollstufe hoch
+ausdrücklich vor – „nur nach dokumentierter Freigabe durch `<APPROVAL_ROLE>` und mit begleitender
+Person“ –, und R3 und R10 stufen genau solche Änderungen dorthin ein. Das Framework **will** also,
+dass Authentifizierungslogik im Code bearbeitbar ist. Was V6 meint, ist der Betrieb. Die beiden
+Sätze reden über zwei verschiedene Gegenstände, und keiner sagt das.
+
+### 1.3 Parallelität – die Schnittmenge ist leer
+
+**R12** (`framework/core/09-risk-model.md:38`) stuft „Hintergrund-Subagenten, Parallelsitzungen
+oder erweiterte Permission-Modi“ als **hoch** ein. Das Arbeitsmodell
+(`framework/core/05-working-model.md:119`) erlaubt Parallelsitzungen „nur für voneinander
+unabhängige Aufgaben der Kontrollstufe **niedrig**“.
+
+**Eigene Feststellung, und sie ist die schärfste des Antrags:** Das ist nicht bloß uneinheitlich,
+sondern **zirkulär**. Die Kontrollstufe ist der höchste Treffer über alle dreizehn Faktoren
+(Abschnitt 5 desselben Moduls). Wer parallel arbeitet, trifft R12 hoch – die Aufgabe ist damit
+Kontrollstufe hoch und kann nie „niedrig“ sein. **Die Regel des Arbeitsmodells war nie
+erfüllbar.** Derselbe Befundtyp wie B08, wo die Aktivierung eine Prüfung verlangt, die bereits
+Aktivität voraussetzt.
+
+Der Vorschlag des Reviews – Parallelität nur im für Kontrollstufe hoch zulässigen Modus – löst den
+Widerspruch **nicht**, weil er R12 unangetastet lässt: Schon ein rein lesender Subagent machte
+damit jede Analyse zu einer Aufgabe der Kontrollstufe hoch, mit Architektur- und Security-Review
+und vollständigem Sitzungsprotokoll. Das widerspricht Abschnitt 3.1 desselben Arbeitsmodells, der
+ein rein lesendes Agentenprofil für M1 ausdrücklich erlaubt.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Die acht Kategorien aus Abschnitt 2.1 sind unbedingt.** Die Bedingung an der sechsten
+   Kategorie entfällt; Abschnitt 2.2 Regel 4 hält fest, dass keine Kategorie aus 2.1 auf irgendeinem
+   Weg gelockert werden kann – nicht durch das Overlay, nicht durch die Datenschutz- und
+   Vertragsprüfung, nicht durch den Ausnahmeprozess. Änderbar bleibt die Liste über den
+   Änderungsprozess des Frameworks, also auf ihrer eigenen Ebene.
+2. **Die Kurzform führt alle acht Kategorien** und nennt die bereinigte Ableitung als den Weg, der
+   offen bleibt. Die Abbildung des Organisationsschemas verliert ihre Lockerungszusage.
+   `governance/PRIORITY_HIERARCHY.md` bekommt die Fundstellen beider ebenenfester Listen und
+   Befund 7 in der Widerspruchsprüfung.
+3. **V6 erfasst den Betrieb, nicht die Anwendungslogik.** Ein normativer Abgrenzungsabschnitt hinter
+   der V-Liste sagt, was auf welche Seite gehört, und nennt das Kriterium: Wirkt die Änderung über
+   Build, Review und Quality Gates des Projekts, oder ist die geänderte Datei selbst die
+   Berechtigung eines laufenden Systems? **Sicherheitskonfiguration als Code gehört zum Betrieb** –
+   Infrastrukturbeschreibungen, Richtlinien- und Berechtigungsdateien, die Berechtigungsdatei
+   dieses Frameworks. Die Wurzel-Anweisungsdatei trägt beide Sätze.
+4. **R12 unterscheidet nach Schreibziel und Aufsicht, nicht nach der Zahl der Sitzungen:** rein
+   lesende Parallelarbeit unter Aufsicht niedrig, schreibende auf disjunkten Zielen mittel,
+   gemeinsame Schreibziele hoch. Erweiterte Permission-Modi bleiben hoch. Das Arbeitsmodell nennt
+   statt einer Kontrollstufe die **Voraussetzungen** und verweist für die Einstufung auf R12.
+5. **Zwölf Grenzfälle** in `tests/EDGE_CASES.md`, je mit Entscheidung, Betriebsmodus,
+   Kontrollstufe, Rollen und Fundstelle – das Abnahmekriterium des Reviews, prüfbar gemacht.
+6. **Prüfung 29** vergleicht die K3-Liste in fünf Fassungen und weist eine Bedingung zurück.
+   **Prüfung 30** prüft die Grenzfalltabelle auf Vollständigkeit.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Er ändert das Schutzmodell nicht.** Die Kategorien bleiben, wie sie sind; entfernt wird eine
+  Ausnahme, nicht eine Kategorie. Die Alternative – technische Metadaten aus der absoluten Liste
+  ausgliedern – hätte das Modell geändert und eine Entscheidung des
+  `<DATA_PROTECTION_CONTACT>` gebraucht.
+- **Er erlaubt keine neue Umsetzung.** Die Abgrenzung zu V6 beschreibt, was nach der bestehenden
+  Kontrollstufentabelle ohnehin gilt. Was heute nicht delegierbar ist, bleibt es.
+- **Er belegt keine technische Durchsetzung.** Ob ein Client eine Einstufung erzwingt, steht in
+  seiner Fähigkeitsmatrix. Die Grenzfälle nennen Einstufungen, keine Mechanismen.
+- **Er prüft nicht, ob ein KI-Client die Grenzfälle richtig einstuft.** Das ist eine Sitzung, kein
+  Skript – `FW-KO-05` im Testkatalog.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Core (Ebene 3) und Governance. Datenschutz- und Sicherheitsregeln stehen dort
+      und nur dort (P10).
+- [x] Verschärfungsprinzip: **verschärft dreifach.** Eine Ausnahme entfällt, zwei fehlende
+      Kategorien kommen in die Kurzform, die Sicherheitsgrenze wird für den Betrieb absolut. Die
+      R12-Neufassung ist **keine Lockerung**, sondern die Auflösung einer leeren Schnittmenge: Was
+      vorher galt, war nicht erfüllbar. Erweiterte Permission-Modi bleiben hoch.
+- [x] Widerspruchsfreiheit: gelesen wurden `governance/PRIORITY_HIERARCHY.md` (Regeln 2.1, 2.4),
+      `framework/core/02-privacy.md`, `framework/core/09-risk-model.md` (R3, R10, R12, V4, V6, V10,
+      Kontrollstufen), `framework/core/05-working-model.md` (3.1), `decision-trees/01-context-allowed.md`,
+      `decision-trees/06-rule-placement.md`, `checklists/02-privacy-context.md`, D-23, D-35, D-47.
+- [x] Laufzeitfassungen: Wurzel-Anweisungsdatei und Regelablage `10-*` betroffen; beide entstehen
+      aus dem Kern und werden mit der Installation erneuert. Kein Pack-Eingriff nötig.
+- [x] Belegstatus: Textbefund, **im Text gegengeprüft** – jede Fundstelle nachgelesen, die
+      Zeilennummern des Reviews berichtigt. Keine Messung nötig und keine behauptet.
+- [x] Test- und Validierungsbedarf: **sechs Sonden und zwei Gegenproben** (Prüfungen 29 und 30), je
+      mit einer Sonde auf den verlorenen Anker. Gegenbeweis gegen 0.31.0.
+- [x] Overlays: betroffen ist ein Overlay, das interne Kennungen als K1 führt – es wird damit
+      ungültig. Migrationshinweis im `CHANGELOG.md`.
+- [ ] Dokumentation: `CHANGELOG.md`, Decision Log (D-52 bis D-54), Roadmap, Testkatalog.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Welche K3-Kategorien sind unbedingt, welche einstufbar? | **Alle acht aus Abschnitt 2.1 sind unbedingt**, die Overlay-Ausnahme entfällt. Praktikabel bleibt die Lage über die bereinigte Ableitung: Platzhalter statt Hostname, das Original bleibt ausgeschlossen – das verlangt die Wurzel-Anweisungsdatei ohnehin. Sieben von acht Texten standen bereits so | Eine Konfigurationsdatei mit internen Hostnamen darf nicht unbereinigt bereitgestellt werden, und die Organisationsstufe „vertraulich“ verliert den K2-Pfad. Gewinn: **Die Kurzform, die tatsächlich in jede Sitzung lädt, ist erstmals wahr** |
+| E2 | Bleibt die Möglichkeit, interne Adressen einzustufen, auf Ebene 1–3 erhalten? | **Nein.** Sie wäre der kleinere Eingriff, aber die Kurzform müsste den Vorbehalt mittragen – ein Bedingungssatz in genau dem Text, der ohne Nachlesen gelten soll. Dieses Projekt kennt den Befundtyp: eine Zusage, die mehr verspricht, als sie leistet. Eine unbedingte Regel, die stimmt, ist mehr wert als eine bedingte, die niemand nachliest | Weniger fachlicher Spielraum. Wer ihn braucht, ändert die Liste über den Änderungsprozess – sichtbar und mit Begründung, statt still im Overlay |
+| E3 | Welche sicherheitsrelevanten Codeänderungen sind mit Freigabe bearbeitbar? | **Lokale Anwendungslogik** – Authentifizierungs- und Autorisierungsprüfungen im Quellcode, Kryptonutzung, Sitzungsverwaltung – bei Kontrollstufe hoch, mit Freigabe von `<APPROVAL_ROLE>` **und** `<SECURITY_CONTACT>` und mit begleitender Person. **Betrieb, Infrastruktur und tatsächliche Berechtigungen bleiben V6**, absolut | Die Grenze braucht ein entscheidbares Kriterium. Es lautet: Wirkt die Änderung über Build, Review und Quality Gates, oder **ist** die Datei die Berechtigung? Die Alternative – jede sicherheitsrelevante Umsetzung auszuschließen – wäre einfacher und widerspräche R3, R10 und der Kontrollstufentabelle |
+| E4 | Auf welche Seite gehört Sicherheitskonfiguration als Code? | **Zum Betrieb, also V6** – trotz Ablage im Repositorium und trotz Review-Weg. Der Inhalt der Datei **ist** die Berechtigung; ein Fehler wirkt beim nächsten Deployment, nicht erst nach einer menschlichen Konfiguration. Das ist der Grenzfall, an dem die Regel entschieden wird, und er steht in der Tabelle (G-06) | Infrastrukturbeschreibungen sind damit nicht bearbeitbar, auch nicht mit Freigabe. Das trifft Projekte, die alles als Code führen – und ist der Preis dafür, dass die Grenze überhaupt eine ist |
+| E5 | Wird das Aufgabenrisiko vom Koordinationsrisiko getrennt? | **Nein – R12 wird neu geschnitten**, nach Schreibziel und Aufsicht statt nach der Zahl der Sitzungen. Ein Faktor, drei neue Spalten, kein neuer Risikofaktor. Das löst die leere Schnittmenge auf und erhält die Einstufung, die gemessen ist: erweiterte Permission-Modi bleiben hoch (D-35) | Ein Faktor trägt weiterhin zwei Gedanken. Die Alternative – ein vierzehnter Faktor für das Koordinationsrisiko – wäre saubere Dimensionentrennung, verlangte aber eine zweidimensionale Einstufung und eine neue Regel für den „höchsten Treffer“. Für einen Widerspruch, der sich mit drei Spalten auflösen lässt, ist das zu viel Modell |
+| E6 | Wie wird die Wirkung nachgewiesen, wo es nichts zu messen gibt? | **Zwei maschinelle Prüfungen und eine Grenzfalltabelle.** Prüfung 29 vergleicht die K3-Liste über fünf Fassungen und weist Bedingungen zurück – sie hätte beide Befunde dieses Antrags gefunden. Prüfung 30 hält die Grenzfalltabelle vollständig. Je Prüfung eine Sonde auf den **verlorenen Anker**: Eine Konsistenzprüfung, die ihren Suchtext verliert, besteht leise | Für die Abgrenzung zu V6 und für R12 gibt es keine maschinelle Prüfung – ein Skript kann eine Einstufung nicht beurteilen. Dort trägt die Grenzfalltabelle, geprüft in einer Sitzung (`FW-KO-05`). Das ist ausgewiesen, nicht überspielt |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle sechs Fragen wie vorgelegt.** E1 alle acht Kategorien unbedingt, Overlay-Ausnahme entfällt; E2 keine Einstufungsmöglichkeit auf Ebene 1–3; E3 Trennung nach Wirkungsweg, Anwendungslogik bei Kontrollstufe hoch bearbeitbar; E4 Sicherheitskonfiguration als Code gehört zu V6; E5 R12 wird neu geschnitten, kein neuer Risikofaktor; E6 Nachweis über Prüfungen 29 und 30 plus Grenzfalltabelle |
+| Datum | 2026-09-13 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-52 (K3 unbedingt), D-53 (Betrieb gegen Anwendungslogik), D-54 (R12 nach Schreibziel und Aufsicht) |
+| Auflagen | **Der Preis gehört in den Migrationshinweis, nicht nur in diesen Antrag.** Ein Overlay, das interne Kennungen als K1 führt, wird mit 0.32.0 ungültig, und die Organisationsstufe „vertraulich“ verliert ihren K2-Pfad – beides betrifft ein übernehmendes Projekt unmittelbar und steht im `CHANGELOG.md`. **Die zwei fehlenden Kategorien der Kurzform sind mitzuberichtigen**, obwohl der Befund sie nicht nennt: Eine Fassung, die sechs von acht führt, ist der eigentliche Schaden der Inkonsistenz. **Nachgewiesen:** sechs Sonden, zwei Gegenproben, Gegenbeweis gegen 0.31.0 – dort melden die neuen Prüfungen die drei Befunde dieses Antrags von selbst. **Offen bleibt:** Für die V6-Abgrenzung und für R12 gibt es keine maschinelle Prüfung; sie tragen über die Grenzfalltabelle und `FW-KO-05`, und dieser Test ist eine Sitzung und steht auf `offen` |
+| Ziel-Release | `0.32.0` |
+| Umsetzung | umgesetzt mit `0.32.0` |

package/.koolie/core/governance/change-requests/CR-2026-053-lesesperre-und-entwicklungsprofil.md

@@ -0,0 +1,144 @@
+# Änderungsantrag `CR-2026-053`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Schreibschutz der Regelquellen war als Leseverbot ausgeschrieben – und der Einstieg in das eigene Repositorium war nirgends geregelt |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-13 |
+| Betroffene Artefakte | `templates/project-overlay/OVERLAY.md` (Abschnitt 4), `framework/runtime/rules/20-project-overlay.md`, `framework/runtime/root-instruction.md` (Abschnitte 3 und 6), fünf Skills (`fw-repo-analyze`, `fw-code-explain`, `fw-change-analyze`, `fw-error-analyze`, `fw-review-support`), `governance/FRAMEWORK_DEV_PROFILE.md` (neu), `README.md`, `tests/scripts/validate-framework.py` (Prüfung 28), `tests/scripts/probe-pruefungen.py`, `tests/EDGE_CASES.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core und Governance**; die Overlay-Vorlage ist Kern-Artefakt, das ausgefüllte Overlay bleibt Ebene 4 |
+| Art | Befund **B07** des unabhängigen Reviews vom 2026-09-12, P2; **gegengeprüft, bestätigt und erheblich verschärft** |
+| Dringlichkeit | **Paket 4**, gemeinsam mit `CR-2026-052`; B07 hing an der K3-Entscheidung |
+
+## 1. Anlass und Problem
+
+### 1.1 Der Befund ist schlimmer als beschrieben
+
+Das Review nennt es eine Vermischung von Integritäts- und Vertraulichkeitsschutz: Die
+Overlay-Vorlage führt unter „weder lesen noch ändern“ auch Regelablage, Wurzel-Anweisungsdatei,
+Overlay und Framework auf – die der Agent laden **soll**.
+
+**Die Gegenprüfung zeigt eine Wirkungskette, die der Bericht nicht nennt.** Beide technischen
+Schichten trennen die beiden Schutzziele längst korrekt:
+
+| Schicht | Vertraulichkeit | Integrität |
+|---|---|---|
+| `framework/runtime/permissions.json` | `read deny <EXCLUDED_PATHS>` und die Secret-Muster | `write deny <ROOT_INSTRUCTION_FILE>`, `<RUNTIME_DIR>/**`, `<CORE_DIR>/**`, `project-overlay/**` – bei `read allow **` |
+| `tests/scripts/hook-check-secrets.py` | `SECRET_PATH_PATTERNS`: lesend **und** schreibend blockiert | `STRUKTURPFAD`-Liste: nur schreibend; `PROTECTED_WRITE_PATH_PATTERNS` für das Kernverzeichnis |
+
+Die Trennung ist seit D-30 gebaut und im Skript kommentiert. Falsch ist allein der **Text** – und
+zwar an einer Stelle, die in die Technik zurückwirkt: `<EXCLUDED_PATHS>` ist der Platzhalter, der
+in die **`read`-Verweigerung** eingesetzt wird. Ein Projekt, das die Vorlage wörtlich ausfüllt,
+erzeugt damit eine **Lesesperre auf seine eigenen Regeldateien** – auf genau die Anweisungen, die
+der KI-Client befolgen soll. Das ist kein Dokumentenwiderspruch mehr, sondern ein Fehler, der die
+erzeugte Berechtigungsdatei erreicht.
+
+**Fundstellen, gegengeprüft:** `templates/project-overlay/OVERLAY.md:71` und
+`framework/runtime/rules/20-project-overlay.md:23`. Die Wurzel-Anweisungsdatei macht es in
+Abschnitt 3 (Lesen) und Abschnitt 6 (Ändern) **richtig** – sie bekommt die Lesesperre nur
+zugeliefert. Der Befund sitzt also nicht dort, wo das Review ihn vermutet; die Zeilenangaben
+`:37` und `:60` treffen einmal (37) und einmal nicht (die Verbotsliste steht auf 57).
+
+**Nebenbefund, eigene Feststellung:** `<CORE_DIR>/**` steht in der Berechtigungsdatei als
+`write`-Verweigerung, **aber nicht** in der Verbotsliste der Wurzel-Anweisungsdatei. Der
+Mechanismus schützt mehr, als der Text sagt – der wiederkehrende Befundtyp dieses Projekts mit
+umgekehrtem Vorzeichen. Ein Agent bekäme eine Blockierung, die ihm niemand angekündigt hat.
+
+### 1.2 Der Einstieg in das eigene Repositorium war nirgends geregelt
+
+Im Quellrepositorium bleibt das Overlay absichtlich Vorlage. Der Overlay-Status steht auf
+`<TBD: aktiv | inaktiv>`, und die Wurzel-Anweisungsdatei sagt für diesen Fall: „arbeitest du nur
+lesend“. Die fünf Analyseskills verlangten `<ALLOWED_PATHS>` oder erlaubten ohne Overlay
+ausdrücklich nur Übungsrepositorys. Für die Entwicklung und Prüfung von Leitwerk **selbst** gab es
+keinen benannten Weg – auch nicht für das Ablegen eines Ergebnisdokuments.
+
+**Das ist nicht theoretisch, sondern die Arbeitsbedingung jeder Sitzung dieses Projekts** – die
+dieser hier eingeschlossen. Das externe Review musste dafür den Auftrag als Berechtigung behandeln
+und hat es ausgewiesen.
+
+## 2. Vorgeschlagene Änderung
+
+1. **`<EXCLUDED_PATHS>` wird zur reinen Vertraulichkeitskategorie.** In der Overlay-Vorlage und in
+   der Laufzeitregel stehen dort nur noch die Secret-Dateien; die Strukturpfade des Frameworks
+   wandern in `<READ_ONLY_PATHS>` – die Kategorie „Lesen erlaubt, Ändern nie“, die es bereits gibt
+   und die die Skills als Lesebereich schon anerkennen. **Keine neue Kategorie, keine neue
+   Semantik:** Damit sagt der Text dasselbe wie beide Mechanismen.
+2. **Die Overlay-Vorlage erklärt den Unterschied an der Stelle, an der er gebraucht wird** – mit
+   dem Satz, dass `<EXCLUDED_PATHS>` zu einer `read`- **und** `write`-Verweigerung wird und wer die
+   Strukturpfade dort einträgt, den Lesezugriff auf die eigenen Regeln sperrt.
+3. **Die Wurzel-Anweisungsdatei sagt beides ausdrücklich:** in Abschnitt 3, dass der Schreibschutz
+   kein Leseverbot ist und die Regelquellen gelesen werden sollen; in Abschnitt 6 tritt
+   `<CORE_DIR>/` in die Verbotsliste ein – der Text zieht dem Mechanismus nach.
+4. **Ein Entwicklungsprofil für das Quellrepositorium** (`governance/FRAMEWORK_DEV_PROFILE.md`):
+   zwei Einsatzkontexte, Geltungsbereich aus dem Inhalt des Repositoriums statt aus einem
+   Verzeichnisnamen, Inhalt ist K0 und damit lesbar, Berichtspfad `tests/protocols/`, Änderungen
+   nur über den Änderungsprozess (V10 bleibt), freigegebene Prüfkommandos – und ein Abschnitt
+   „Was dieses Profil nicht leistet“.
+5. **Die fünf Analyseskills** nennen neben dem Übungsrepositorium das Quellrepositorium des
+   Frameworks. Fünf, nicht einer: Dieselbe Vorbedingung stand in allen fünf, und eine Ausnahme in
+   einem Skill wäre die nächste Inkonsistenz.
+6. **Prüfung 28** findet einen Strukturpfad in der Deklaration von `<EXCLUDED_PATHS>` – in der
+   Vorlage, in der Laufzeitregel, im ausgefüllten Overlay und in der installierten Regelablage.
+   Sie meldet zusätzlich, wenn die **Beschriftung** der Deklaration verloren geht, weil sie sonst
+   leise bestünde.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Er hebt keinen Schreibschutz auf.** `<CORE_DIR>/**`, `<RUNTIME_DIR>/**`,
+  `<ROOT_INSTRUCTION_FILE>` und `project-overlay/**` bleiben schreibgesperrt – auch im
+  Quellrepositorium. Das Entwicklungsprofil ist ein Dokument, kein Schalter.
+- **Er macht keine Projektdatei lesbar, die es nicht war.** Ausgeschlossen bleibt, was Abschnitt 2.1
+  des Datenschutzmodells ausschließt. Eine Datei wird nicht dadurch lesbar, dass sie neben einer
+  Regeldatei liegt.
+- **Er löst B08 nicht.** Die Zirkularität der Aktivierung – `--strict-overlay` verlangt, was es
+  herstellen soll – ist Paket 5 und bleibt offen.
+- **Er beseitigt die Lücke im Shell-Kanal nicht.** Sie ist gemessen (B04), sie ist der Weg, über
+  den Änderungen an diesem Framework heute entstehen, und sie steht als solche im Profil.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern-Artefakte und Governance. Das ausgefüllte Overlay bleibt Ebene 4; die
+      Vorlage gehört dem Kern.
+- [x] Verschärfungsprinzip: **verschärft zweimal, lockert einmal – und die Lockerung ist die
+      Berichtigung einer falschen Zusage.** Verschärft: `<CORE_DIR>/` in der Verbotsliste, Prüfung
+      28. Gelockert: Die Regelquellen sind lesbar – sie waren es technisch immer, nur der Text
+      behauptete etwas anderes. **Eine Lesesperre, die kein Mechanismus erhebt und die ihren
+      eigenen Regelträger sperrt, ist keine Schutzwirkung, die man verteidigt.**
+- [x] Widerspruchsfreiheit: gelesen wurden D-22 (das gesamte Kernverzeichnis ist geschützt), D-30
+      (zwei Schutzziele, zwei Listen), D-47 (Zusagen je Zugriffskanal), V10, `framework/core/02-privacy.md`
+      Abschnitt 2 (K0-Definition), `framework/runtime/permissions.json`,
+      `tests/scripts/hook-check-secrets.py`, die fünf Skill-Vorbedingungen.
+- [x] Laufzeitfassungen: Wurzel-Anweisungsdatei und Regelablage `20-*` betroffen, beide erzeugt aus
+      dem Kern. **Migrationshinweis nötig:** Ein bestehendes Projekt muss seine
+      `<EXCLUDED_PATHS>`-Liste durchsehen – `--update` erneuert die Berechtigungsdatei nicht.
+- [x] Belegstatus: **im Code und im Text gegengeprüft.** Die Trennung beider Mechanismen ist an
+      `permissions.json` und am Hook-Skript nachgelesen, nicht abgeleitet.
+- [x] Test- und Validierungsbedarf: **drei Sonden und eine Gegenprobe** für Prüfung 28. Die
+      Gegenprobe ist die wichtigere: Beide Träger erklären im Fließtext, dass die Strukturpfade
+      gerade **nicht** hierher gehören, und nennen dabei beides in einer Zeile.
+- [x] Overlays: Jedes bestehende Overlay, das der Vorlage gefolgt ist, trägt den Fehler. Prüfung 28
+      findet ihn beim nächsten Lauf.
+- [ ] Dokumentation: `CHANGELOG.md` mit Migrationshinweis, Decision Log (D-55, D-56), Roadmap,
+      `README.md`, Grenzfälle G-10 bis G-12.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Wohin gehören die Strukturpfade des Frameworks? | **In `<READ_ONLY_PATHS>`.** Die Kategorie existiert, heißt „Lesen erlaubt, Ändern nie“ und wird von den Skills bereits als zulässiger Lesebereich geführt. Beide Mechanismen machen genau diese Unterscheidung. Es gibt hier keine Ermessensfrage – nur einen Text, der seiner Technik nachzieht | `<READ_ONLY_PATHS>` trug bisher nur Projektwerte (Schnittstellenverträge, Migrationen) und bekommt feste Framework-Einträge. Und: Die Kategorie wird **nicht** in die Berechtigungsdatei abgebildet – der Schreibschutz dieser Pfade kommt weiterhin aus den festen `write`-deny-Regeln, nicht aus dem Overlay. Das ist ausgewiesen |
+| E2 | Bekommt das Quellrepositorium eine technische Ausnahme? | **Nein. Ein Dokument, kein Schalter.** Das Profil benennt den Kontext, leitet die Lesefreigabe aus der Kontextklasse K0 ab und lässt die Schranke, wo sie ist: beim Änderungsprozess und bei der menschlichen Freigabe | **Die Selbstanwendung bleibt unvollständig, und zwar über eine gemessene Lücke:** Änderungen an diesem Framework entstehen über den Shell-Kanal, den der Hook nicht erfasst. Das steht im Profil, statt verschwiegen zu werden. Ein abschwächender Schalter wäre in jeder Installation ausgeliefert – genau die Bauform, aus der in diesem Projekt die Befunde entstehen |
+| E3 | Was passiert, wenn Paket 6 den Shell-Weg schließt? | **Offen, als Klärungspunkt K-32 aufgenommen.** Dann braucht die Entwicklung dieses Frameworks einen ausdrücklich entschiedenen Weg – und die Entscheidung fällt dort, wo die Durchsetzung gebaut wird, nicht hier | Eine bewusste Schuld. Sie jetzt zu entscheiden hieße, einen Schalter für einen Mechanismus zu bauen, den es noch nicht gibt |
+| E4 | Alle fünf Skills anfassen, obwohl der Befund einen nennt? | **Ja.** Dieselbe Vorbedingung steht wörtlich in fünf Skills. Vier davon stehenzulassen wäre dieselbe Inkonsistenz, nur kleiner – und das Abnahmekriterium des Reviews verlangt ausdrücklich, dass Skills dieselbe Einstufung tragen | Fünf Versionsanhebungen und fünf Einträge in den Skill-Änderungsverläufen; der Validator erzwingt beides |
+| E5 | Wie verhindert Prüfung 28, dass sie den richtigen Text beanstandet? | **Sie prüft die Deklarationszeile, nicht jede Nennung** – erkannt an der Beschriftung „Ausgeschlossene Pfade“. Beide Träger erklären im Fließtext das Gegenteil und nennen dabei beides in einer Zeile; eine Prüfung, die jede Nennung meldet, wäre unbrauchbar. **Und weil eine verlorene Beschriftung eine Prüfung erzeugt, die leise besteht, ist deren Fehlen selbst ein Fehler** | Wer die Zeile umbenennt und die Beschriftung mit umschreibt, entgeht der Prüfung nicht – aber die Prüfung meldet dann einen fehlenden Anker statt der Sache. Das ist der bessere Fehlerfall: sichtbar statt still |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle fünf Fragen wie vorgelegt.** E1 Strukturpfade nach `<READ_ONLY_PATHS>`; E2 dokumentiertes Entwicklungsprofil ohne technische Ausnahme; E3 die Folgefrage wird als K-32 aufgenommen; E4 alle fünf Skills; E5 Prüfung 28 prüft die Deklaration und meldet den verlorenen Anker |
+| Datum | 2026-09-13 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-55 (ein Schreibschutz ist kein Leseverbot), D-56 (Entwicklungsprofil des Quellrepositoriums) |
+| Auflagen | **Das Profil muss die Lücke benennen, an der es hängt.** Ein Entwicklungsprofil, das die Selbstanwendung behauptet, ohne zu sagen, dass ihr wirksamer Teil auf einem gemessenen Loch im Shell-Kanal beruht, wäre derselbe Befundtyp eine Ebene höher. Der Abschnitt „Was dieses Profil nicht leistet“ ist deshalb Pflichtbestandteil, nicht Beigabe. **Der Migrationshinweis gehört in das `CHANGELOG.md`:** Ein bestehendes Projekt muss seine `<EXCLUDED_PATHS>`-Liste durchsehen, und `--update` erneuert die Berechtigungsdatei nicht. **Nachgewiesen:** drei Sonden, eine Gegenprobe, Gegenbeweis gegen 0.31.0 – dort meldet Prüfung 28 vier Fundstellen, zwei in der Quelle und zwei in der Installation. **Offen bleibt:** K-32, und die Abbildung von `<READ_ONLY_PATHS>` in die Berechtigungsdatei – die Kategorie ist heute rein textuell |
+| Ziel-Release | `0.32.0` |
+| Umsetzung | umgesetzt mit `0.32.0` |

package/.koolie/core/governance/change-requests/CR-2026-054-aktivierung-verlangt-aktivitaet.md

@@ -0,0 +1,124 @@
+# Änderungsantrag `CR-2026-054`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Aktivierung verlangte einen Lauf, der Aktivität voraussetzt – und der Status-Hook entschied sie nach der ersten Datei |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-13 |
+| Betroffene Artefakte | `tests/scripts/validate-framework.py` (neuer Schalter `--check-overlay-ready`, Prüfung 9a), `tests/scripts/overlay_status.py` (neu), `tests/scripts/hook-overlay-status.py`, `templates/project-overlay/OVERLAY.md` (Abschnitt 21), `checklists/10-project-adoption.md`, `docs/ADOPTION_GUIDE.md` (Schritte 7 und 9), `tests/scripts/probe-pruefungen.py` |
+| Ebene laut Entscheidungsbaum 6 | **Kern** – Prüfwerkzeug, Hook und Übernahmeablauf; das ausgefüllte Overlay bleibt Ebene 4 |
+| Art | Befund **B08** des unabhängigen Reviews vom 2026-09-12, P2; **gegengeprüft, bestätigt und um einen Defekt erweitert** |
+| Dringlichkeit | **Paket 5**; Voraussetzung B02 ist seit 0.28.0 erfüllt |
+
+## 1. Anlass und Problem
+
+### 1.1 Die Zirkularität ist im Ablauf dreifach verankert
+
+| Stelle | Aussage |
+|---|---|
+| `docs/ADOPTION_GUIDE.md` Schritt 7 | fährt `validate-framework.py --strict-overlay` |
+| `docs/ADOPTION_GUIDE.md` Schritt 9 | setzt den Overlay-Status **danach** auf `aktiv` |
+| `checklists/10-project-adoption.md`, Kopfzeile „Wann“ | gilt „**vor** dem Setzen des Overlay-Status auf `aktiv`“ |
+| ebenda, MUSS-Punkt | verlangt denselben Lauf ohne Fehler |
+| `templates/project-overlay/OVERLAY.md` Abschnitt 21 | Status wird `aktiv`, **wenn** Checkliste **und** Lauf durch sind |
+
+`check_strict_overlay` verlangt den Status **genau** `aktiv`, und zwar in beiden Trägern – seit
+0.28.0 als Aufzählung statt als Präfix, weil `aktivierung-ausstehend` vorher bestand (D-44). Der
+dokumentierte Ablauf ist damit **nicht ohne Regelbruch begehbar**: Wer ihn befolgt, setzt `aktiv`,
+bevor die Übernahmecheckliste fertig ist – und ein Agent arbeitet dann regelkonform in M3 auf
+einem unfertigen Overlay.
+
+### 1.2 Eigene Feststellung: Der Name der gesuchten Prüfung steht längst da
+
+`docs/ADOPTION_GUIDE.md` Zeile 145 nennt den Lauf „prüft Struktur, Inhalte und
+**Aktivierungsreife** des Overlays“. Der Docstring von `check_strict_overlay` nannte ihn ebenso
+„Aktivierungsreife des Projekts“. **Beide beschreiben eine Kandidatenprüfung; die Umsetzung
+verlangt den fertigen Zustand.** Es fehlt kein Begriff – es fehlt die Prüfung dazu. Das verschiebt
+den Zuschnitt des Antrags: Nicht ein neues Konzept wird eingeführt, sondern eine Prüfung gebaut,
+die zwei Dokumente seit je beschreiben.
+
+### 1.3 Eigene Feststellung: Der Status-Hook trägt drei Defekte, nicht zwei
+
+Das Review nennt zwei (nur die erste Angabe, kein Tabellenformat). Am Skript nachgelesen sind es
+drei:
+
+| Nr. | Defekt | Fundstelle | Folge |
+|---|---|---|---|
+| 1 | `value.startswith("aktiv")` – **Präfixvergleich** | `hook-overlay-status.py:54` (0.32.0) | `aktivierung-ausstehend` wird als `aktiv` gemeldet. **Genau der Defekt, den D-44 im Validator behoben hat** – die Lehre wurde in einer Funktion gezogen und nicht zur Nachbarin getragen, wie bei D-49 |
+| 2 | Suchmuster verlangt einen Doppelpunkt | `:51` | Die Steckbriefzeile `\| Overlay-Status \| … \|` wird **nie** getroffen |
+| 3 | `break` nach dem ersten Treffer | `:60` | Eine aktive Laufzeitregel gewinnt gegen ein inaktives Quell-Overlay |
+
+Die gemeinsame Auswertung existiert seit 0.28.0 im Validator (`_overlay_status_angaben`) – der
+Hook benutzt sie nicht.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Neuer Schalter `--check-overlay-ready`** (Prüfung 9a): prüft denselben Inhalt wie
+   `--strict-overlay` – offene Werte, sicherheitsrelevante Abschnitte, Berechtigungsdatei ohne
+   Platzhalter – und beim Status **das Gegenteil**: Er muss an allen Stellen übereinstimmen und
+   noch **nicht** `aktiv` sein. Ein bereits aktives Overlay wird als Fehler gemeldet, mit Verweis
+   auf `--strict-overlay`.
+2. **`--strict-overlay` bleibt unverändert** die Prüfung des aktiven Zustands. Nur sein Docstring
+   hört auf, sich Reifeprüfung zu nennen.
+3. **Der Ablauf wird begehbar:** Leitfaden Schritt 7 und die Checkliste fahren die
+   Kandidatenprüfung; nach dem Setzen auf `aktiv` folgt ein Nachlauf mit `--strict-overlay`. Die
+   Overlay-Vorlage führt die Reihenfolge in fünf Schritten.
+4. **Ein gemeinsames Modul `tests/scripts/overlay_status.py`** trägt die Auswertung. Validator und
+   Hook importieren es; **der Hook importiert nicht den Validator.**
+5. **Der Hook wertet alle Träger aus**, vergleicht exakt statt als Präfix, kennt beide
+   Schreibweisen und meldet einen Widerspruch als **`widerspruechlich`** – nicht als `inaktiv` und
+   nicht als `unbekannt`. Die Folge ist dieselbe (nur lesend), der Grund nicht.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Er erteilt keine fachliche Freigabe.** Die Kandidatenprüfung prüft Vollständigkeit; die
+  Übernahmecheckliste bleibt der Nachweis, und ein Skript kann sie nicht abschließen.
+- **Er prüft keine Richtigkeit.** Ein vollständig ausgefülltes Overlay mit falschen Werten besteht
+  die Prüfung.
+- **Er ändert den Hook nicht zu einer Schranke.** Er informiert weiterhin und blockiert nie; ohne
+  zusätzliche Werkzeugkontrolle bleibt es dabei.
+- **Er löst den Abgleich zwischen Quell-Overlay und Laufzeitfassung nicht** (`CR-2026-044` E4).
+  Geprüft wird jetzt der **Status** an allen Stellen, nicht der gesamte Inhalt.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern. Prüfwerkzeug, Hook, Übernahmeablauf.
+- [x] Verschärfungsprinzip: **verschärft.** Der Hook hört auf, `aktivierung-ausstehend` als aktiv
+      zu melden, und eine Drift führt nicht mehr zur günstigeren der beiden Aussagen.
+      `--strict-overlay` behält seine Strenge unverändert – **das war der Grund, ihn nicht
+      umzudeuten.**
+- [x] Widerspruchsfreiheit: D-23, D-44 (Aufzählung statt Präfix), D-49 (eine Lehre gilt auch für
+      die Nachbarfunktion), D-30 (Hook-Skripte ohne clientgebundene Ableitung – das neue Modul hat
+      keine), `framework/runtime/root-instruction.md` Abschnitt 3 gelesen.
+- [x] Laufzeitfassungen: Die Hook-Konfiguration ändert sich **nicht** – derselbe Aufruf, dieselben
+      Argumente. Das Skript liegt im Kern und kommt mit `--update`.
+- [x] Belegstatus: **im Code gegengeprüft**; die drei Hook-Defekte sind am Skript nachgelesen, die
+      Zirkularität an fünf Textstellen und an `check_strict_overlay`.
+- [x] Test- und Validierungsbedarf: **sechs Sonden und zwei Gegenproben je Pack** – drei und
+      eine für die Kandidatenprüfung, drei und eine für den Hook. Die Sonde zum Fetch-Verbot
+      gehört zu `CR-2026-055`.
+- [x] Overlays: Ein bestehendes, aktives Overlay ist **nicht** betroffen; `--strict-overlay` sagt
+      dort weiterhin dasselbe. Betroffen ist jede **künftige** Übernahme.
+- [ ] Dokumentation: `CHANGELOG.md`, Decision Log (D-57, D-58), Roadmap, Leitfaden, Checkliste.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Wie wird die Zirkularität aufgelöst? | **Neuer Schalter für den Kandidaten, `--strict-overlay` bleibt.** Er hat mit dem Aktualisierungsablauf einen zweiten, funktionierenden Aufrufer; ihn umzudeuten hieße, jeder bestehenden Projekt-CI stillschweigend eine andere Prüfung zu geben – der Befundtyp dieses Projekts | Eine neue CLI-Oberfläche und ein zweiter Prüfpfad, der mitgepflegt werden muss. Der Docstring muss aufhören, `--strict-overlay` Reifeprüfung zu nennen |
+| E2 | Was erwartet die Kandidatenprüfung beim Status? | **Übereinstimmung an allen Stellen und „noch nicht `aktiv`".** Ein bereits aktives Overlay ist ein Fehler mit Verweis auf `--strict-overlay` | Man kann die Prüfung nicht auf ein aktives Overlay anwenden, um dessen Vollständigkeit zu sehen. Das ist gewollt: Eine Prüfung, die zwei Zustände gleich behandelt, unterscheidet keine zwei Zustände – und wäre als schwächerer Ersatz für `--strict-overlay` benutzbar |
+| E3 | Wie weit wird der Hook nachgezogen? | **Ganz, über ein gemeinsames Modul.** Alle drei Defekte; der Präfixvergleich ist derselbe, den D-44 im Validator ausgeschlossen hat. Ein Modul statt eines Imports des Validators: Ein Hook, der bei jedem Sitzungsstart 2300 Zeilen lädt, wäre ein Leistungs- und ein Fehlerrisiko | Eine neue Datei im Kern. **Die Alternative – nur den Präfixvergleich berichtigen – hätte zwei von drei Defekten stehen gelassen**, und die Drift ist der, den das Review beschreibt |
+| E4 | Was meldet der Hook bei Widerspruch? | **`widerspruechlich`**, mit M1-Hinweis. `inaktiv` und `unbekannt` verschweigen beide, dass eine Erklärung da ist und nicht stimmt; wer die Meldung liest, suchte dann einen fehlenden Eintrag | Eine dritte Statusaussage im Hook-Text. Sie kostet nichts – der Hook gibt Fließtext aus, keinen Aufzählungswert |
+| E5 | Wie wird nachgewiesen, dass die Prüfung nicht alles meldet? | **Über die Gegenprobe, und sie ist hier die wichtigere Hälfte:** ein vollständig ausgefüllter Kandidat mit Status `inaktiv` muss **durchlaufen**. Ohne sie stünde nur fest, dass irgendetwas gemeldet wird | Der Kandidat muss in der Sonde erst hergestellt werden – Platzhalter ersetzen, Status setzen, Berechtigungsdatei bereinigen. Das macht den Sondenlauf länger |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle fünf Fragen wie vorgelegt.** E1 neuer Schalter `--check-overlay-ready`, `--strict-overlay` bleibt; E2 Übereinstimmung und „noch nicht aktiv"; E3 der Hook wird vollständig nachgezogen, über ein gemeinsames Modul; E4 ein Widerspruch wird als solcher gemeldet; E5 Nachweis über die Gegenprobe des vollständigen Kandidaten |
+| Datum | 2026-09-13 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-57 (Kandidatenprüfung und aktiver Zustand sind zwei Prüfungen), D-58 (eine Statusauswertung für beide Werkzeuge) |
+| Auflagen | **Der Präfixvergleich im Hook ist mitzuberichtigen, obwohl das Review ihn nicht nennt.** Er ist wörtlich derselbe Defekt, den D-44 im Validator behoben hat; ihn stehenzulassen hieße, dieselbe Lehre zum zweiten Mal nicht zu übertragen. **Die Sonden laufen je Pack** – B02 war nicht, dass eine Prüfung falsch prüft, sondern dass sie einen Client nicht sieht. **Nachgewiesen:** sechs Sonden und zwei Gegenproben je Pack, zusammen zwölf und vier; die Gegenprobe des vollständigen Kandidaten belegt, dass die Prüfung nicht pauschal meldet. **Offen bleibt:** Der Abgleich des gesamten Inhalts zwischen Quell-Overlay und Laufzeitfassung (`CR-2026-044` E4) – geprüft wird der Status, nicht jedes Feld |
+| Ziel-Release | `0.33.0` |
+| Umsetzung | umgesetzt mit `0.33.0` |

package/.koolie/core/governance/change-requests/CR-2026-055-domain-ausnahme-ohne-mechanismus.md

@@ -0,0 +1,173 @@
+# Änderungsantrag `CR-2026-055`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Domain-Ausnahme stand an fünf Stellen im Kern, hatte keinen Mechanismus und keine Matrixzeile |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-13 |
+| Betroffene Artefakte | `framework/core/03-security.md` (Abschnitt 4), `framework/core/02-privacy.md` (Regel 3.7), `framework/runtime/rules/10-privacy-security.md`, `checklists/02-privacy-context.md`, `templates/project-overlay/OVERLAY.md` (Abschnitt 11), beide `CLIENT_PACK.md` (neue Zeile **B10**, Zusammenfassung), `tests/scripts/validate-framework.py` (Fetch-Allow aus dem Manifest, Prüfung 31), `tests/scripts/probe-pruefungen.py` |
+| Ebene laut Entscheidungsbaum 6 | **Core** (Sicherheitsregel, Ebene 3) und Client Packs |
+| Art | Befund **B11** des unabhängigen Reviews vom 2026-09-12, P2; **gegengeprüft, bestätigt und um zwei eigene Befunde erweitert** |
+| Dringlichkeit | **Paket 5**, gemeinsam mit `CR-2026-054` |
+
+## 1. Anlass und Problem
+
+### 1.1 Die Widerlegung steht fünf Zeilen unter der Zusage
+
+`framework/core/03-security.md` Abschnitt 4, in einer Tabelle und ihrem Nachsatz:
+
+| Zeile | Text |
+|---|---|
+| 54 | `\| Netzwerkzugriff \| Fetch(*) \| deny; **Ausnahmen je Domain im Overlay** \|` |
+| 57 | „Regeln aus höheren Ebenen haben Vorrang, **`deny` gewinnt immer** `[DOK]`.“ |
+| 59 | „Der Grund ist mechanisch: In der Berechtigungsdatei gewinnt `deny` immer, und keine der abgebildeten Clientformen kennt ein Ausnahmemuster innerhalb eines deny.“ |
+
+**Zeile 59 buchstabiert das Argument aus, das Zeile 54 widerlegt** – für das Kernverzeichnis, zu
+einem anderen Zweck. Eine zusätzliche `allow`-Regel für eine Domain hebt ein bestehendes
+`Fetch(*)`-Verbot nicht auf. Der Befund ist damit nicht bloß bestätigt, sondern **im eigenen
+Dokument vorweggenommen**.
+
+### 1.2 Eigene Feststellung: Die Zusage steht an fünf Stellen und hat keine Zeile
+
+| Stelle | Wortlaut |
+|---|---|
+| `framework/core/03-security.md:54` | „deny; Ausnahmen je Domain im Overlay“ |
+| `framework/core/02-privacy.md` Regel 3.7 | „Freigaben erfolgen domainbezogen über das Overlay und die Berechtigungskonfiguration (`Fetch(domain:...)` **`[DOK]`**)“ |
+| `framework/runtime/rules/10-privacy-security.md:31` | „ohne domainbezogene Freigabe im Overlay“ |
+| `checklists/02-privacy-context.md:39` | MUSS-Punkt, dieselbe Formulierung |
+| `templates/project-overlay/OVERLAY.md` Abschnitt 11 | „`Fetch(domain:...)`-Regeln in `<PERMISSIONS_FILE>`“ |
+
+**Keine Fähigkeitsmatrix führt eine Zeile dazu.** B8 deckt das *Verbot* ab und steht für die
+Abrufwerkzeuge auf `[TECHNISCH]`; die zugesagte *Ausnahme* kommt in keinem Pack vor. Das ist
+dieselbe Bauform wie der Suchkanal aus 0.30.0: **eine Zusage, die keine Schicht kennt.** Und die
+Angabe `[DOK]` in `02-privacy.md` belegte eine Schreibweise, nicht ihre Wirkung gegen ein
+bestehendes `deny`.
+
+### 1.3 Eigene Feststellung: Bei einem Pack ist die Zusage nicht ausdrückbar
+
+`clients/claude-code/manifest.json` führt `WebFetch` und `WebSearch` in
+`permission_tools_bare`. Damit wird das Muster beim Rendern **verworfen**; die erzeugte Datei
+trägt – am 2026-09-13 nachgeprüft an einer frischen Installation:
+
+```
+"deny": [ …, "WebFetch", "WebSearch" ]
+```
+
+Das ganze Werkzeug, nicht ein Ziel. Eine Domain-Angabe ist dort **überhaupt nicht ausdrückbar**.
+Dazu führt `permission_tools.fetch` beide Werkzeuge zusammen – **für eine Websuche gibt es kein
+Domain-Ziel**, eine Domain-Liste wäre dort auch künftig sinnlos.
+
+Das Verwerfen ist im Manifest deklariert und für sich richtig. **Unbenannt blieb die Folge** – dass
+damit eine Kernaussage bei diesem Pack nicht einlösbar ist. Wörtlich dasselbe Muster wie B01 bei
+`permissions` in `drop_fields` (D-50), nur über einen anderen Mechanismus.
+
+### 1.4 Eigene Feststellung: Der Validator entschied dieselbe Absicht je Pack verschieden
+
+`check_config` führte eine feste Namensliste: `"Fetch(*"`, `"WebFetch"`, `"WebSearch"`. Nachgerechnet:
+
+| Regel in `allow` | Ergebnis bis 0.32.0 |
+|---|---|
+| `Fetch(*)` | abgelehnt |
+| `Fetch(domain:docs.example.invalid)` | **zulässig** |
+| `WebFetch(domain:docs.example.invalid)` | abgelehnt |
+
+**Dieselbe Absicht, zwei Packs, zwei Entscheidungen** – und niemand hat das entschieden. Es ist
+derselbe Fehlertyp wie B02 und B10: eine Prüfung, die Clientnamen festschreibt, statt sie aus dem
+Manifest zu nehmen.
+
+### 1.5 Beim Einfügen der Matrixzeile aufgefallen: die Zusammenfassung überzeichnet
+
+Die Zeile **B10** musste in die Fachmatrix – und damit in die Summen von Abschnitt 3. Dabei zeigte
+sich: **Die Zusammenfassung war zwei Releases hinterher und zählte nach einer Regel, die D-47
+widerspricht.**
+
+| Angabe bis 0.32.0 (`claude-code`) | Nachgerechnet |
+|---|---|
+| `[TECHNISCH]` 25 von 29 | **20** von 30 |
+| `[TEXTUELL]` 3 von 29 | **7** von 30 |
+| `[NICHT ABBILDBAR]` 1 von 29 (S5) | **3** von 30 (S3, S5, B10) |
+
+S3 steht seit 0.31.0 auf `[NICHT ABBILDBAR]` (`CR-2026-050`), ohne dass die Summen nachgezogen
+wurden. Und die vier Zeilen mit einer Kanalgrenze – B3, B4, B5, B8 – zählten als `[TECHNISCH]`,
+obwohl D-47 sie je Kanal ausweist und ihr Shell-Teil nur als Anweisung trägt. **Die Überschrift
+desselben Abschnitts sagte „Alle sechs Kernzusagen sind technisch abgebildet"** – seit 0.30.0 zu
+weit gefasst: Drei davon (B3, B4, B5) sind es nur für den direkten Zugriff.
+
+**Es ist der dritte Drift dieser Summen.** Das Pack `devin-desktop` dokumentiert selbst einen
+früheren: „Die Zeilenzahl ist mit 0.26.0 nachgezählt worden – sie stimmte vorher nicht.“ Eine Zahl,
+die dreimal von Hand stimmen musste, gehört ausgerechnet.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Die Zusage wird zurückgezogen.** Alle fünf Stellen sagen: Das generelle Verbot steht, eine
+   Ausnahme je Domain gibt es **nicht**. `03-security.md` bekommt einen normativen Absatz, der die
+   Mechanik nennt und den einzigen Weg beschreibt: **Ersatz statt Zusatz** – die Verbotsregel selbst
+   wird über einen Änderungsantrag (V10) durch eine nachgewiesen gleichwertige Beschränkung
+   ersetzt. Ein Overlay darf das nicht.
+2. **Zeile B10 in beiden Packs**, nach D-41 mit benanntem Ersatz: bei `claude-code`
+   `[NICHT ABBILDBAR]`, Ersatz ist das vollständige Verbot – **strenger** als die Zusage, deshalb
+   kein Schutzverlust; bei `devin-desktop` `[TEXTUELL]` mit VERIFY-Marker, weil die Form das
+   Rendern überlebt und ihre Wirkung unerhoben ist.
+3. **Das Fetch-Allow-Verbot des Validators kommt aus dem Manifest** (`permission_tools.fetch`)
+   statt aus einer Namensliste. Damit ist jede `allow`-Regel auf ein Abrufverb unzulässig, bei
+   jedem Pack gleich.
+4. **Die Summen der Fachmatrix werden ausgerechnet** – **Prüfung 31**, mit einer benannten
+   Zählregel: eine Zeile zählt bei ihrer **schwächsten** Einstufung. Beide Zusammenfassungen und
+   die Überschrift von `claude-code` werden berichtigt.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Er baut kein Domain-Profil.** Das Zwei-Profil-Modell des Reviews ist die größere Arbeit und
+  gehört dorthin, wo die Netz- und Isolationsarbeit liegt (Paket 6) – samt URL-Normalisierung,
+  Hostvergleich ohne Teilzeichenfolgen, Weiterleitungsprüfung und einem Nachweis, der ohne echte
+  Netzwerkisolation nichts belegt.
+- **Er trennt das Abrufverb nicht von der Websuche.** Solange keine Domain-Steuerung zugesagt
+  wird, richtet die Zusammenlegung keinen Schaden an: Beide Werkzeuge sind verweigert, und das ist
+  die Absicht. Die Matrixzeile hält fest, dass eine Websuche **keinen** Domain-Begriff kennt.
+- **Er prüft keine Einstufung.** Prüfung 31 prüft die Arithmetik. Eine Matrix, in der jede Zeile
+  falsch eingestuft ist, besteht sie.
+- **Er beseitigt die Shell-Lücke im Netzverbot nicht.** B8 weist sie je Kanal aus; jedes andere
+  netzfähige Programm als `curl`, `wget`, `ssh`, `scp` ist nicht erfasst (D-47).
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Sicherheitsregel im Core, Abbildung im Pack.
+- [x] Verschärfungsprinzip: **verschärft dreifach.** Eine Ausnahme, die nie wirkte, verschwindet;
+      das Fetch-Allow-Verbot wird symmetrisch und damit strenger für ein Pack; die Summen hören auf,
+      die Durchsetzungstiefe zu überzeichnen. **Gelockert wird nichts** – es gab nichts zu lockern.
+- [x] Widerspruchsfreiheit: gelesen wurden D-30, D-41 (Ausfall mit benanntem Ersatz), D-47 (Zusagen
+      je Zugriffskanal), D-50 (ein verworfenes Feld nennt seine Folge), D-59-Kandidat,
+      `governance/PRIORITY_HIERARCHY.md` Regel 2.1, `framework/runtime/permissions.json`.
+- [x] Laufzeitfassungen: Die erzeugten Regeln ändern sich **nicht** – `deny` auf die
+      Abrufwerkzeuge stand und steht. Geändert wird, was darüber behauptet wird.
+- [x] Belegstatus: **im Code und an einer frischen Installation nachgeprüft** – die erzeugte
+      Regelmenge beider Packs, die Namensliste des Validators durchgerechnet, die Summen der
+      Matrizen ausgezählt.
+- [x] Test- und Validierungsbedarf: **eine Sonde und eine Gegenprobe je Pack** für das
+      Fetch-Allow-Verbot; **vier Sonden und eine Gegenprobe** für Prüfung 31.
+- [x] Overlays: Ein Overlay, das freigegebene Domains führt, verliert seine Grundlage. Sie hat nie
+      gewirkt – der Migrationshinweis sagt das.
+- [ ] Dokumentation: `CHANGELOG.md`, Decision Log (D-59, D-60), Roadmap, beide Packs.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Wird eine Domain-Ausnahme zugesagt? | **Nein – die Zusage wird zurückgezogen.** Sie hat nie gewirkt, bei einem Pack ist sie nicht ausdrückbar, und keine Matrixzeile hat sie je getragen. Der einzige dokumentierte Weg ist der **Ersatz** der Verbotsregel per Änderungsantrag, nicht ihre Ergänzung | Ein Projekt, das öffentliche Dokumentation braucht, bekommt in 0.33.0 keinen Weg; freigegebene Auszüge werden lokal bereitgestellt. **Das ist der ehrliche Stand, nicht eine neue Einschränkung** – funktioniert hat es nie |
+| E2 | Was tritt an die Stelle der Zusage? | **Das vollständige Verbot**, und es ist **strenger** als die zurückgezogene Zusage. Deshalb ist der Ausfall kein Schutzverlust und die Inbetriebnahme nicht betroffen (D-41). Die Matrixzeile B10 sagt es je Pack | Der Ersatzsatz muss sagen, dass er strenger ist – ein Ersatzsatz, der seine Richtung verschweigt, wäre derselbe Befundtyp eine Ebene höher (Auflage aus `CR-2026-050`) |
+| E3 | Wann kommt das Domain-Profil? | **Mit Paket 6**, wo die Isolationsschicht und die Pfaddurchsetzung liegen. Vorher ist es nicht messbar, und ein Profil, das man nicht messen kann, ist genau die Zusage, die dieses Projekt sich abgewöhnt | Eine bewusste Schuld. Der Eintrag steht in der Roadmap, mit den drei Vorarbeiten: Trennung von Abruf und Websuche, Hostvergleich, Weiterleitungen |
+| E4 | Wird das Abrufverb jetzt von der Websuche getrennt? | **Nein.** Ohne zugesagte Domain-Steuerung ändert die Trennung an den erzeugten Regeln **nichts** – beide Werkzeuge bleiben verweigert. Ein neues Verb erzwänge Anpassungen in beiden Packs, im Validator und in jedem künftigen Pack, für einen Nutzen, der erst mit Paket 6 entsteht | Die Zusammenlegung bleibt stehen, und wer das Profil später baut, muss sie zuerst auflösen. Die Matrixzeile benennt es |
+| E5 | Bleibt das Fetch-Allow-Verbot eine Namensliste? | **Nein, es kommt aus dem Manifest.** Die Asymmetrie – `Fetch(domain:…)` zulässig, `WebFetch(domain:…)` abgelehnt – war keine Entscheidung, sondern eine Nebenwirkung fest verdrahteter Namen. Derselbe Fehlertyp wie B02 und B10 | Ein Pack, das `permission_tools.fetch` leer lässt, entgeht der Prüfung. Das ist bei `hook_tools_absent` entschieden (D-47, Prüfung 26): Eine erklärte Abwesenheit muss folgerichtig sein – die Prüfung dort gilt weiter |
+| E6 | Werden die Summen der Fachmatrix ausgerechnet? | **Ja, Prüfung 31, mit benannter Zählregel: schwächste Einstufung.** Das ist die einzige Regel, die D-47 nicht widerspricht – eine Zeile, deren Zusage in einem Kanal nur als Anweisung trägt, ist nicht technisch durchgesetzt. Die Summen sind **dreimal** gedriftet | Die ausgewiesene Durchsetzungstiefe **sinkt** – bei `claude-code` von 25 auf 20 technische Zeilen, und die Überschrift verliert den Satz, alle sechs Kernzusagen seien technisch abgebildet. **Das ist keine Verschlechterung, sondern das Ende einer Überzeichnung**; die Zeilen selbst sagten es seit 0.30.0 |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle sechs Fragen wie vorgelegt.** E1 die Zusage wird zurückgezogen; E2 Ersatz ist das vollständige Verbot, ausdrücklich als das strengere benannt; E3 das Domain-Profil kommt mit Paket 6; E4 keine Verbtrennung jetzt; E5 das Fetch-Allow-Verbot kommt aus dem Manifest; E6 Prüfung 31 rechnet die Summen nach, Zählregel schwächste Einstufung |
+| Datum | 2026-09-13 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-59 (keine Ausnahme je Domain; Ersatz statt Zusatz), D-60 (die Summen der Fachmatrix werden ausgerechnet) |
+| Auflagen | **Der Rückzug gehört in den Migrationshinweis**, und zwar mit dem Satz, dass die Freigabe nie gewirkt hat – sonst liest es sich wie eine neue Einschränkung. **Die Summen sind mitzuberichtigen, obwohl der Befund sie nicht nennt:** Sie sind beim Einfügen der Zeile B10 aufgefallen, sie waren zwei Releases hinterher, und die Überschrift behauptete eine Durchsetzungstiefe, die D-47 seit 0.30.0 widerlegt. **Nachgewiesen:** eine Sonde und eine Gegenprobe je Pack für das Fetch-Allow-Verbot, vier Sonden und eine Gegenprobe für Prüfung 31; gegen 0.32.0 meldet Prüfung 31 fünf Fundstellen in den unveränderten Packs, und Prüfung 30 eine sechste, weil die Grenzfalltabelle des Vorstands D-59 nicht kennt. **Offen bleibt:** das Domain-Profil (Paket 6), die Trennung von Abrufverb und Websuche, und die Shell-Lücke des Netzverbots (D-47) |
+| Ziel-Release | `0.33.0` |
+| Umsetzung | umgesetzt mit `0.33.0` |