@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-048-modusgrenze-ohne-durchsetzung.md

@@ -0,0 +1,137 @@
+# Änderungsantrag `CR-2026-048`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Betriebsmodi nennen eine technische Durchsetzung, die es nicht gibt – drei von fünf Modi |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `framework/core/05-working-model.md` (Zeile „Durchsetzung" in M1, M2, M4, M5; M3 hat keine), `framework/skills/fw-docs-update/SKILL.md` (Erläuterung zur Pfadprüfung), gegebenenfalls die übrigen Skills mit `permissions`-Frontmatter |
+| Ebene laut Entscheidungsbaum 6 | Kern – Arbeitsmodell; die Mechanismusnennung gehört ohnehin nicht dorthin |
+| Art | Befund **B05** des unabhängigen Reviews vom 2026-09-12, P1; **gegengeprüft und gemessen** |
+| Dringlichkeit | **vor der weiteren Nutzung im Pilotprojekt** – M5 ist der Modus, in dem dort gearbeitet wird |
+
+## 1. Anlass und Problem
+
+Das Arbeitsmodell führt je Betriebsmodus eine Zeile **Durchsetzung**. Sie beantwortet die Frage,
+was einen Modus von einer Absichtserklärung unterscheidet. Bei M4 und M5 lautet sie:
+
+| Modus | Zeile „Durchsetzung" heute |
+|---|---|
+| M4 Test and Validation | Skill-`permissions` mit `Write(<TEST_PATHS>/**)` und `Exec(<TEST_COMMAND>)`; Hook `PreToolUse` zur Blockierung von Schreibzugriffen außerhalb der Testpfade |
+| M5 Documentation Support | Skill-`permissions` mit `Write(<DOC_PATHS>/**)`, `deny: exec` |
+
+**Beide genannten Mechanismen tragen nicht.**
+
+### Der Hook kennt die Grenze nicht – gemessen
+
+`tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`, vier Läufe mit drei Positivkontrollen im
+selben Lauf:
+
+| Lauf | Eingabe | Ergebnis |
+|---|---|---|
+| B05-1 | `Write` auf einen Quellcodepfad – **außerhalb** des M5-Scopes | **passiert** |
+| B05-2 | `Write` auf einen Dokumentationspfad – **innerhalb** des M5-Scopes | **passiert** |
+| B05-3 | `Edit` auf Produktivcode – **außerhalb** des M4-Scopes | **passiert** |
+| B05-4 | derselbe Zugriff mit `"mode": "M5"` in der Eingabe | **passiert** |
+
+**Auf B05-1 und B05-2 kommt es an.** Sie unterscheiden sich genau im zugesagten Merkmal, und der
+Hook entscheidet gleich. Der Befund ist nicht, dass er zu wenig blockiert – er ist, dass er die
+zugesagte Grenze **nicht kennt**: Weder ein Betriebsmodus noch eine Liste erlaubter Schreibpfade
+erreicht ihn. B05-4 schließt die naheliegende Ausrede aus; ein mitgeführter Modus ändert nichts,
+das Feld wird nicht gelesen. Die drei Positivkontrollen desselben Laufs blockieren
+erwartungsgemäß – der Hook läuft, er kennt diese Grenze nur nicht.
+
+### Die Skill-`permissions` tragen sie doppelt nicht
+
+Erstens sagt der Skill `fw-docs-update` es selbst: Eine Beschränkung auf `<DOC_PATHS>` unter
+Ausschluss aller übrigen Pfade sei über Skill-`permissions` **nicht ausdrückbar**, weil
+`<DOC_PATHS>` eine Teilmenge von `<ALLOWED_PATHS>` ist und `deny` gegen `allow` gewinnt. Der
+Skill verweist deshalb auf den Hook – und dort endet der Verweis, siehe oben.
+
+Zweitens verwirft `install.py` beim Rendern des Frontmatters jedes Feld, das das Manifest nicht
+kennt, und `permissions` ist eines davon (**B01**, gemessen am 2026-09-12). Zwölf Quellskills
+tragen das Feld; keine installierte Fassung trägt es.
+
+### Derselbe Satz steht bei M1 und M2
+
+| Modus | Zeile „Durchsetzung" heute | Lage |
+|---|---|---|
+| M1 Read-only Analysis | Werkzeugbeschränkung des Skills auf lesende Verben und `deny: edit, exec` über dessen `permissions` | **trägt nicht** – dasselbe verworfene Feld (B01) |
+| M2 Guided Planning | Schreibrecht allein auf die Plan-Datei | **kein benannter Mechanismus**, nur eine Wirkung |
+| M3 Controlled Modification | keine Zeile `Durchsetzung`, wohl aber `Umsetzung im Werkzeug` – mit Belegklasse je Mechanismus | **trägt, und zwar als einziger richtig.** Bei der Umsetzung hat sich gezeigt: Das ist die Form, die die anderen vier haben sollten |
+
+Drei von fünf Modi nennen einen Mechanismus, und alle drei nennen einen, der nicht trägt. **Zwei
+Zeilen zu berichtigen und zwei stehen zu lassen wäre genau der Fehler, den dieses Projekt
+wiederholt bei sich selbst gefunden hat** (76 statt 248, fünf statt zehn, sechs statt zwölf).
+
+> **Berichtigt bei der Umsetzung:** Der Antrag führte M3 zunächst als Ausreißer, weil ihm die
+> Zeile `Durchsetzung` fehlt. Er hat stattdessen `Umsetzung im Werkzeug` – und nennt dort je
+> Mechanismus eine Belegklasse (`[DOK]`, `[KONZ]`, `[EMPF]`). Das ist die ehrlichere Form.
+> **Die vier übrigen Modi sind deshalb auf M3 nachgezogen worden, nicht umgekehrt.**
+
+## 2. Vorgeschlagene Änderung
+
+1. **Die Zeile „Durchsetzung" nennt künftig die Klasse, nicht einen Mechanismus.** Für M1, M4 und
+   M5 lautet sie: die Scope-Grenze gilt **normativ** (`[TEXTUELL]`), getragen von der Regelschicht
+   und der menschlichen Prüfpflicht des Modus; eine technische Durchsetzung besteht **nicht**.
+   Die zusätzlich wirkenden technischen Sperren (Secret-Pfade, Kernverzeichnis beim direkten
+   Schreibwerkzeug) bleiben genannt – sie wirken, sie sind nur nicht die Modusgrenze.
+2. **M2 und M3 bekommen dieselbe Zeile**, damit jeder Modus dieselbe Frage beantwortet. Bei M3
+   ist die Antwort ausdrücklich zu geben, nicht wegzulassen.
+3. **Der Verweis in `fw-docs-update/SKILL.md` wird berichtigt.** Der Satz „die technische
+   Absicherung erfolgt über den `PreToolUse`-Hook mit Pfadprüfung" entfällt; an seine Stelle
+   tritt der gemessene Stand samt Protokollverweis.
+4. **Der Mechanismus, wo er genannt bleibt, gehört in die Packs**, nicht in den Kern. Der Kern
+   ist werkzeugneutral (D-15, D-28); `Write(...)`, `Exec(...)` und `PreToolUse` sind Namen aus
+   der Welt eines Clients.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Er baut kein Sitzungsobjekt.** Das Review schlägt eines vor (`mode`, `writable_roots`,
+  `allowed_commands`, gebunden an eine bestätigte Konfigurationsversion). Es ist der richtige
+  Weg und braucht zwei Voraussetzungen, die beide fehlen: die Pfadauswertung aus **B06** und
+  eine Quelle, die der Agent nicht selbst schreiben kann. Siehe E1.
+- **Er ändert an den Modi selbst nichts** – nicht an den zulässigen Aktionen, nicht an den
+  Verbotslisten, nicht an den Prüfpflichten. Nur die Aussage darüber, was sie erzwingt.
+- **Er behebt B01 nicht.** Dass `install.py` das Feld `permissions` still verwirft, ist ein
+  eigener Befund mit eigenem Antrag; er ist hier nur die halbe Begründung.
+- **Er berührt B3/B4/B5/B8 der Packs nicht** – das ist `CR-2026-047`.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern. Die Modusdefinition ist Kern; die **Mechanismusnennung** darin war
+      schon vorher eine Client-Bindung im werkzeugneutralen Kern (D-15, D-28) und fällt damit.
+- [x] Verschärfungsprinzip: Keine Lockerung. Die Regel bleibt wortgleich verbindlich; allein die
+      Behauptung über ihre Erzwingung entfällt. **K3 nicht berührt.**
+- [x] Widerspruchsfreiheit: D-15, D-28 (werkzeugneutraler Kern), D-23 (Wirkungsnachweis), D-41
+      (Kernzusage – M4/M5 sind keine), B01-Protokoll gelesen.
+- [x] Laufzeitfassungen: Das Arbeitsmodell ist Kernquelle; die Kurzform in der Regelablage ist
+      auf denselben Stand zu bringen (D-24 – geladene Kurzform und kanonische Langform dürfen
+      nicht auseinanderlaufen). **Zu prüfen, bevor der Antrag umgesetzt wird.**
+- [x] Belegstatus: **gemessen**, vier Läufe mit drei Positivkontrollen.
+- [ ] Test- und Validierungsbedarf: Textkorrektur ohne neue Prüfung. **Aber:** Prüfung 25
+      verlangt bei `[NICHT ABBILDBAR]` den benannten Ersatz – bei E2 zu beachten.
+- [x] Overlays: nicht betroffen; kein Projekt fällt durch diese Änderung durch. Der **Pilot**
+      arbeitet in M5 und ist über den geänderten Stand zu informieren.
+- [ ] Dokumentation: CHANGELOG, Decision Log, `docs/ROADMAP.md` (Paket 3).
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Jetzt ausweisen – oder gleich das Sitzungsobjekt bauen? | **Jetzt ausweisen.** Das Sitzungsobjekt setzt B06 voraus (Pfadidentität und Eingabeschema) und eine Quelle außerhalb der Reichweite des Agenten. Beides fehlt. Ein zweiter Mechanismus auf unbelegter Grundlage ist genau die Konstruktion, die `AP2-DD-10` acht Releases lang trug | **Die Modusgrenze bleibt Modellverhalten.** Wer M5 einsetzt, verlässt sich auf Regeltext und menschliche Prüfung – das ist ab dann wenigstens zutreffend beschrieben, aber es ist weniger, als heute dasteht |
+| E2 | Welche Klasse trägt die Modusgrenze künftig? | **`[TEXTUELL]`.** Die Regel existiert, ist verbindlich formuliert und wirkt über die Regelschicht. `[NICHT ABBILDBAR]` wäre falsch und würde nach Prüfung 25 einen Ersatz verlangen, den die Regelschicht gerade darstellt | Ein Leser, der `[TEXTUELL]` überliest, hält die Lage für unverändert. Deshalb gehört die Änderung in den CHANGELOG und an den Piloten kommuniziert, nicht nur in die Tabelle |
+| E3 | **Nur M4/M5 berichtigen – oder alle fünf Modi?** | **Alle fünf.** M1 trägt denselben verworfenen Mechanismus, M2 nennt eine Wirkung statt eines Mechanismus, und M3 – der Modus, der Produktivcode ändert – nennt gar nichts. Zwei von fünf zu berichtigen hieße, den Befund zu kennen und liegen zu lassen | Der Antrag wird größer als der Befund des Reviews. **Die Gegenposition ist vertretbar:** B05 nennt M4 und M5; wer den Befundumfang strikt hält, behandelt M1 im Antrag zu B01 und M2/M3 gesondert. Dann sind es drei Anträge statt einem, und die Tabelle bleibt bis dahin uneinheitlich |
+| E4 | Bleibt der Mechanismus überhaupt irgendwo genannt? | **Ja – im Client Pack, nicht im Kern.** Was ein Client erzwingen kann, steht in seiner Fähigkeitsmatrix; dort steht es bereits (B-Block). Der Kern verweist darauf, statt Werkzeugnamen zu führen | Wer die Modusdefinition liest, muss für den Mechanismus eine zweite Datei aufschlagen. Das ist der Preis der Werkzeugneutralität und in diesem Projekt bereits 61-mal bezahlt (D-15) |
+| E5 | Muss die Kurzform in der Regelablage mitgezogen werden? | **Ja, im selben Antrag.** D-24 ist genau deshalb entstanden: Sieben Abweichungen zwischen geladener Kurzform und kanonischer Langform. Eine Korrektur, die nur die Langform erreicht, stellt den Zustand wieder her, den D-24 beendet hat | Zwei Dateien statt einer, und die Kurzform ist die, die tatsächlich in jede Sitzung lädt. Der Abgleich ist vor der Umsetzung zu prüfen – er ist im Antrag als offene Prüffrage markiert |
+| E6 | Wie wird die Wirkung nachgewiesen? | **Gar nicht durch eine neue Prüfung** – der Antrag entfernt eine unzutreffende Behauptung, er stellt keine auf. Der Beleg ist das Protokoll vom 2026-09-12. **Wohl aber eine Validatorprüfung:** Die Zeile „Durchsetzung" darf künftig keinen Client-Werkzeugnamen mehr enthalten; Prüfung 14 erfasst Clientnamen, nicht Werkzeugnamen | Eine solche Prüfung ist neu und braucht nach D-23 Sonde und Gegenprobe. **Sie ist optional** – ohne sie wandert derselbe Satz beim nächsten Mal wieder in den Kern, und gefunden hat ihn diesmal ein externes Review |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle sechs Fragen wie vorgelegt.** E1 jetzt ausweisen statt das Sitzungsobjekt bauen; E2 die Modusgrenze trägt `[TEXTUELL]`; E3 **alle fünf Modi**, nicht nur M4 und M5; E4 der Mechanismus bleibt im Client Pack genannt, nicht im Kern; E5 die Kurzform der Regelablage wird mitgezogen; E6 kein neuer Sondenblock, aber der Beleg im Protokoll |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **E3 hat den Befund bei der Umsetzung berichtigt, und zwar zugunsten des Bestands:** M3 nennt seine Durchsetzung nicht gar nicht, sondern unter der Überschrift `Umsetzung im Werkzeug` – mit Belegklassen je Mechanismus. **Das ist die richtige Form, und die vier übrigen Modi sind darauf nachgezogen worden**, statt M3 auf die schlechtere zu bringen. Der Antragstext hatte M3 als Ausreißer geführt; das ist im Protokoll und in der Roadmap berichtigt. **E5 ist eingelöst:** `framework/runtime/rules/00-framework-core.md` trägt den Satz, dass die Schreibrechte der Modustabelle normativ gelten – das ist die Fassung, die in jede Sitzung lädt (D-24). **Offen bleibt E1:** Das Sitzungsobjekt mit `mode` und `writable_roots` setzt B06 voraus und bleibt Paket 6 |
+| Umsetzung | umgesetzt mit `0.30.0` |

package/.koolie/core/governance/change-requests/CR-2026-049-sondenlauf-kodierungsabhaengig.md

@@ -0,0 +1,126 @@
+# Änderungsantrag `CR-2026-049`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Wirkungsnachweis hängt von der Kodierung der aufrufenden Umgebung ab – und wird rot, wenn man es richtig macht |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `tests/scripts/probe-pruefungen.py` (`lauf()`, Zeile 74) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Prüfwerkzeug |
+| Art | Eigener Befund dieser Sitzung, aufgefallen beim Sondenlauf zur Gegenprüfung von B04/B05 |
+| Dringlichkeit | **vor dem nächsten Release** – das Skript ist das Abnahmetor nach D-23 |
+
+## 1. Anlass und Problem
+
+Der Sondenlauf dieser Sitzung meldete **eine Abweichung**: `SONDE 19` – „Pack ohne
+Auskunftsabschnitt" – schlug fehl. Der Arbeitsbaum war sauber, der Validator meldete 0 Fehler
+und 0 Warnungen, und derselbe Lauf in derselben Sitzung bestand anschließend vollständig.
+
+**Der Unterschied war eine einzige Umgebungsvariable.**
+
+| Lauf | Ergebnis |
+|---|---|
+| `PYTHONIOENCODING=utf-8 python …/probe-pruefungen.py .` | **1 Abweichung** (Sonde 19) |
+| `python …/probe-pruefungen.py .` | alle 48 Sonden und Gegenproben bestanden |
+
+Die Fehlerausgabe verriet den Grund selbst: Sie enthielt `außerhalb` statt `außerhalb`.
+
+### Die Messung
+
+Vier Läufe, ein Kindprozess, der genau einen Satz mit Umlaut ausgibt:
+
+| Aufrufform | Elternumgebung | Umlaut heil |
+|---|---|---|
+| `lauf()` wie heute (`text=True`, ohne `encoding`, ohne `env`) | **mit** `PYTHONIOENCODING=utf-8` | **nein** – `außerhalb` |
+| `lauf()` wie heute | ohne | ja |
+| mit `encoding="utf-8"` und gepinnter `env` | mit | ja |
+| mit `encoding="utf-8"` und gepinnter `env` | ohne | ja |
+
+**Die einzige rote Zelle ist genau die Konfiguration, die das Arbeitswissen dieses Projekts
+empfiehlt.** Nach der Sitzung vom 2026-09-12 gilt dort: „Unterprozesse laufen seither mit
+`PYTHONIOENCODING=utf-8`." Wer sich daran hält, bekommt einen roten Sondenlauf.
+
+### Die Lehre war gezogen – in der Nachbarfunktion
+
+`strict_ausgabe()` (Zeile 503) macht es richtig: gepinnte `env` **und** `encoding="utf-8"`. Ihr
+Docstring beschreibt die Falle vollständig, einschließlich des Satzes „Eine Gegenprobe auf
+‚nicht enthalten' besteht das klaglos – sie ist dann wertlos, ohne es zu zeigen."
+
+`lauf()` steht 429 Zeilen darüber und hat die Korrektur nie bekommen. **Sie ist die Funktion,
+auf der die generischen Runner sitzen:** `sonde()`, `gegenprobe()` und `sonde_ohne_wert()`,
+zusammen **28 Aufrufe**.
+
+### Wie weit es heute reicht – und warum das der schlechtere Teil ist
+
+Von den 28 Aufrufen trägt **genau einer** einen Suchtext mit Umlaut: Sonde 19. Der Schaden
+heute ist also ein falsches Rot an einer Stelle.
+
+**Die Richtung des Fehlers ist bei einer Sonde harmlos und bei einer Gegenprobe nicht.** Eine
+Sonde sucht einen Text und fällt sichtbar, wenn er zerschossen ankommt. Eine Gegenprobe sucht
+denselben Text und prüft auf **Abwesenheit** – ein zerschossener Text ist abwesend, die
+Gegenprobe besteht, und niemand erfährt etwas. Es gibt heute keine solche Gegenprobe. Es gibt
+sie beim nächsten deutschen Suchtext, und dann meldet nichts.
+
+Das ist derselbe Befundtyp wie `CR-2026-042` und wie die Präparationsprüfung aus 0.27.0: **eine
+Prüfung, die unter bestimmten Bedingungen nichts mehr prüft und es nicht zeigt.**
+
+## 2. Vorgeschlagene Änderung
+
+`lauf()` bekommt dieselbe Behandlung wie `strict_ausgabe()`:
+
+```python
+def lauf(root: str) -> str:
+    umgebung = dict(os.environ, PYTHONIOENCODING="utf-8")
+    p = subprocess.run([sys.executable, os.path.join(root, *VALIDATOR.split("/")),
+                        "--root", root],
+                       capture_output=True, text=True, encoding="utf-8",
+                       errors="replace", env=umgebung)
+    return (p.stdout or "") + (p.stderr or "")
+```
+
+Dazu ein Kommentar, der auf `strict_ausgabe()` verweist, damit die Begründung nicht ein zweites
+Mal verloren geht.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Er ändert keine Prüfung und kein Prüfergebnis.** Nach der Korrektur bestehen dieselben 48
+  Sonden und Gegenproben – in beiden Umgebungen.
+- **Er berührt den Validator nicht.** Dessen Ausgabe ist korrekt; falsch ist, wie das
+  Sondenskript sie liest.
+- **Er löst die allgemeine Frage nicht**, ob Suchtexte in Sonden überhaupt Umlaute enthalten
+  sollten. Siehe E2.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern – Prüfwerkzeug.
+- [x] Verschärfungsprinzip: reine Verschärfung; eine Prüfung, die bisher unter bestimmten
+      Bedingungen ausfiel, fällt nicht mehr aus.
+- [x] Widerspruchsfreiheit: D-23 (Wirkungsnachweis), `CR-2026-042` (Abwesenheitsnachweis über
+      ein Suchwerkzeug) gelesen; die Korrektur ist wortgleich zu `strict_ausgabe()`.
+- [x] Laufzeitfassungen: nicht betroffen.
+- [x] Belegstatus: **gemessen**, vier Läufe als Wahrheitstabelle, plus zwei vollständige
+      Sondenläufe mit und ohne die Variable.
+- [x] Test- und Validierungsbedarf: Der Nachweis ist der Lauf selbst – nach der Korrektur muss
+      der Sondenlauf **in beiden Umgebungen** vollständig bestehen. Das ist die Abnahme.
+- [x] Overlays: nicht betroffen.
+- [ ] Dokumentation: CHANGELOG; Arbeitswissen um den Satz ergänzen, dass der Sondenlauf in
+      beiden Umgebungen zu fahren ist.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Nur `lauf()` korrigieren – oder jeden Unterprozessaufruf des Skripts durchgehen? | **Jeden durchgehen.** Zwei Aufrufe tragen die Korrektur, einer nicht; das ist kein Muster, sondern ein Zufall der Entstehungsreihenfolge. Ein Skript, das an drei Stellen dasselbe unterschiedlich macht, erzeugt den nächsten Befund selbst | Der Antrag berührt mehr Zeilen als der Befund verlangt. Dafür ist die Eigenschaft danach eine des Skripts und nicht die einzelner Funktionen |
+| E2 | Suchtexte mit Umlaut künftig verbieten? | **Nein.** Das behebt das Symptom und verlagert die Gefahr: Der Validator meldet auf Deutsch, und ein Suchtext, der den Umlaut umgeht, misst am Gegenstand vorbei. Die Kodierung gehört dort in Ordnung gebracht, wo sie gelesen wird | Suchtexte bleiben so anfällig, wie die Leseseite es zulässt. Nach der Korrektur ist das keine Anfälligkeit mehr |
+| E3 | Soll der Sondenlauf **beide** Umgebungen selbst prüfen? | **Vorschlag: nein, aber als Auflage in die Abnahme.** Ein Skript, das sich selbst zweimal startet, wird unübersichtlich; die Zweifachprüfung ist ein Schritt der Release-Abnahme, kein Sondenblock | Die Eigenschaft ist danach nicht maschinell gesichert. **Die Gegenposition ist vertretbar:** Genau solche Zusagen hat dieses Projekt wiederholt verfallen sehen, weil sie nur in einer Checkliste standen |
+| E4 | Zählt das als Release? | **Nein.** Es ist eine Korrektur am Nachweiswerkzeug, kein Framework-Verhalten. Sie geht mit der Gegenprüfung von B04/B05 als Erhebungs-PR nach `main` und wird im nächsten Release eingearbeitet | Zwischen Korrektur und Release steht ein Zustand, in dem `CHANGELOG.md` sie noch nicht führt |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle vier Fragen wie vorgelegt.** E1 jeder Unterprozessaufruf des Skripts wird angeglichen, nicht nur `lauf()`; E2 Suchtexte mit Umlaut bleiben erlaubt; E3 die Zweifachprüfung ist eine Auflage der Abnahme, kein Sondenblock; E4 kein eigenes Release |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **E1 ist als Bauform umgesetzt, nicht als Reparatur an sieben Stellen:** Alle Aufrufe laufen über die neue Funktion `unterprozess()`, die Umgebung und Dekodierung festlegt; `subprocess.run` steht nur noch dort. Damit ist die Eigenschaft eine des Skripts und nicht die einzelner Funktionen. **Abnahme erfüllt:** Der Sondenlauf besteht vollständig **in beiden Umgebungen** – mit und ohne `PYTHONIOENCODING=utf-8`. Vorher war er mit der Variablen rot. **E4 ist durch den weiteren Sitzungsverlauf überholt:** Die Korrektur geht nicht als reine Erhebung nach `main`, sondern mit `0.30.0`, weil im selben Zug zwei Anträge mit Codeänderung entschieden wurden |
+| Umsetzung | umgesetzt mit `0.30.0` |

package/.koolie/core/governance/change-requests/CR-2026-050-allowed-tools-und-verworfene-permissions.md

@@ -0,0 +1,110 @@
+# Änderungsantrag `CR-2026-050`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | `allowed-tools` ist keine Werkzeugbeschränkung – und das Feld, das eine war, fiel beim Rendern weg |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `clients/claude-code/CLIENT_PACK.md` (S3) und `manifest.json` (`skill_permissions_ersatz`), `clients/devin-desktop/CLIENT_PACK.md` (S3), `install.py` (`render_skill_frontmatter`, neue Prüfhilfe), `tests/scripts/validate-framework.py` (Prüfung 26a → 27), `tests/scripts/probe-pruefungen.py`, `framework/core/05-working-model.md` (M1, M4, M5), `clients/README.md` |
+| Ebene laut Entscheidungsbaum 6 | Client Pack und Abbildung; der normative Kern wird nur nachgezogen |
+| Art | Befund **B01** des unabhängigen Reviews vom 2026-09-12, P1; **gegengeprüft und gemessen** |
+| Dringlichkeit | **mit Paket 3** – B01 war der einzige gemessene Befund des Pakets, der noch offen stand |
+
+## 1. Anlass und Problem
+
+Die Zeile **S3** beider Packs sagt eine „Werkzeugbeschränkung je Skill" zu, bei `claude-code`
+eingestuft `[TECHNISCH]` mit Beleg `[DOK]`. **Beides ist widerlegt.**
+
+### Gemessen, nicht nur gelesen
+
+`tests/protocols/2026-09-12-B01-allowed-tools.md`: Ein Skill mit
+`allowed-tools: Read, Grep, Glob` **konnte schreiben**. `allowed-tools` ist eine
+**Vorabfreigabe** für den aufrufenden Turn, keine abschließende Werkzeugliste. Der
+Dokumentationsbeleg `[DOK]` trug damit eine Aussage, die die Dokumentation so nicht macht.
+
+### Das Feld, das die Beschränkung wirklich trug, fiel beim Rendern weg
+
+Zwölf Quellskills tragen `permissions: {deny: [edit, exec]}` – darunter jeder Analyseskill, auf
+den sich der Betriebsmodus M1 beruft. Das Manifest von `claude-code` führt `permissions` unter
+`skill_frontmatter.drop_fields`; die installierte Fassung trägt nichts davon.
+
+**Das ist nicht „still" im Wortsinn – und gerade das macht es interessant.** Das Verwerfen steht
+im Manifest, für sich genommen korrekt: Der Client kennt das Feld für Skills nicht, und K-18
+verlangt ein Frontmatter nur mit dokumentierten Feldern. Was fehlte, ist die **Folge**: dass
+damit eine Zusage verschwindet und nirgends steht, was an ihre Stelle tritt.
+
+**Genau dieses Muster hatte das Projekt schon einmal.** `triggers` verfiel auf dieselbe Weise,
+bis `AP2-CC-01` es fand – und bekam daraufhin eine Abbildung (`model_invocation_field`).
+`permissions` bekam keine. Zwei Felder, dasselbe Verfahren, ein Unterschied, den niemand
+entschieden hat.
+
+### Gegenprobe beim anderen Pack
+
+Bei `devin-desktop` **überleben** beide Felder das Rendern (`drop_fields` ist dort leer,
+Listenform). Das ist am Rendern nachgeprüft. **Ob der Client sie auswertet, ist es nicht** – die
+Zeile trägt seit jeher einen VERIFY-Marker und war trotzdem `[TECHNISCH]` eingestuft.
+
+## 2. Vorgeschlagene Änderung
+
+1. **S3 bei `claude-code` auf `[NICHT ABBILDBAR]`**, mit benanntem Ersatz nach Prüfung 25: die
+   **globale** Berechtigungsschicht samt Schutz-Hook. Sie wirkt unabhängig vom Skill und hielt
+   am 2026-09-12 auch im untersagten Betriebsmodus – ist aber **weniger** als eine Beschränkung
+   je Skill, und das gehört in dieselbe Zeile.
+2. **S3 bei `devin-desktop` von `[TECHNISCH]` auf `[TEXTUELL]`.** Das Durchreichen der Felder ist
+   belegt, ihre Wirkung nicht. Eine Erhebung an einer Installation steht aus.
+3. **Ein zusagentragendes Frontmatter-Feld darf nicht ersatzlos entfallen.** `install.py` bricht
+   ab, wenn ein Pack `permissions` oder `triggers` verwirft, ohne den Ersatz zu benennen –
+   `skill_permissions_ersatz` beziehungsweise `model_invocation_field`.
+4. **Prüfung 27** findet denselben Fehler **ohne** Installation, im Repositorium, wo ein neues
+   Pack entsteht.
+5. **Die Umsetzungszeilen von M1, M4 und M5** nennen künftig den Ersatz statt nur den Ausfall.
+6. `clients/README.md` Schritt 6 nennt die neuen Manifestfelder.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Er beschafft keine Werkzeugbeschränkung je Skill.** Die Herstellerdokumentation nennt
+  `disallowed-tools` als gesonderten Mechanismus – **nicht erhoben**, und deshalb hier nicht
+  zugesagt. Er trägt einen VERIFY-Marker.
+- **Er ändert die zwölf Quellskills nicht.** Das Feld `permissions` bleibt in der Quelle: Beim
+  zweiten Pack erreicht es die Installation, und es ist die richtige Stelle, sobald ein Client
+  es auswertet.
+- **Er entscheidet nicht, ob M1 anders gebaut werden muss.** M1 stützt sich jetzt sichtbar auf
+  die globale Schicht; ob das genügt, ist eine Frage an das Arbeitsmodell, nicht an dieses Pack.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Client Pack und gemeinsame Abbildung.
+- [x] Verschärfungsprinzip: **verschärft dreifach** – der Abbruch, die Prüfung und die
+      berichtigten Einstufungen. Gelockert wird nichts; eine Einstufung auf den gemessenen
+      Stand zu senken, ist keine Lockerung des Schutzes, sondern das Ende einer Behauptung.
+- [x] Widerspruchsfreiheit: D-18 (keine stille Lockerung in der Abbildung), D-26 (`AP2-CC-01`),
+      D-41 (Kernzusage – S3 ist keine), D-47 (deklarierte Abwesenheit) gelesen. **Die Bauform
+      ist dieselbe wie bei `hook_tools_absent`.**
+- [x] Laufzeitfassungen: Die installierten Skills ändern sich nicht – das Feld entfiel vorher
+      und entfällt weiterhin. Neu ist nur, dass der Ersatz benannt sein muss.
+- [x] Belegstatus: **gemessen** (Protokoll vom 2026-09-12), dazu das Rendern beider Packs
+      nachgeprüft.
+- [x] Test- und Validierungsbedarf: **drei Sonden und zwei Gegenproben** – zwei für Prüfung 27,
+      eine für den Installationsabbruch, je eine Gegenprobe dazu.
+- [x] Overlays: nicht betroffen.
+- [ ] Dokumentation: CHANGELOG, Decision Log, Roadmap, `clients/README.md`.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Welche Einstufung trägt S3 bei `claude-code`? | **`[NICHT ABBILDBAR]` mit benanntem Ersatz.** `[TEXTUELL]` wäre falsch: Es gibt keinen Regeltext, der eine Werkzeugbeschränkung je Skill aussprechen würde – es gibt sie schlicht nicht. Nach D-41 ist S3 eine **Fähigkeitszusage**; der Ausfall sperrt die Inbetriebnahme nicht | Die zweite Zeile auf `[NICHT ABBILDBAR]` in diesem Pack, nach S5. Das ist unangenehm zu lesen und zutreffend |
+| E2 | Wie verhindert man den nächsten Fall? | **Absenz deklarieren, nicht erraten** – wie bei `hook_tools_absent` (D-47). Ein zusagentragendes Feld in `drop_fields` verlangt den benannten Ersatz, sonst bricht die Installation ab | Ein neues Manifestfeld und eine neue Prüfung. **Die Alternative wäre, `permissions` einfach nicht mehr zu verwerfen** – das erzeugte ein Frontmatter mit einem Feld, das der Client nicht kennt, gegen K-18, und änderte an der Wirkung nichts |
+| E3 | Welche Felder gelten als zusagentragend? | **`permissions` und `triggers`** – die beiden, die im Frontmatter eine Schutzaussage machen. Die Liste steht an einer Stelle im Code und ist erweiterbar | Eine Liste, die jemand pflegen muss. Ohne sie müsste **jedes** verworfene Feld erklärt werden, auch `argument-hint` – das wäre Bürokratie ohne Schutzgewinn |
+| E4 | S3 bei `devin-desktop` mit anfassen, obwohl der Befund den anderen Client nennt? | **Ja, auf `[TEXTUELL]`.** Dort ist gemessen, dass die Felder durchgereicht werden – nicht, dass sie wirken. Eine Zeile mit VERIFY-Marker auf `[TECHNISCH]` zu belassen, nachdem dieselbe Frage beim Nachbarpack die Zusage widerlegt hat, wäre genau die Zählung, die dieses Projekt sich abgewöhnt | Die Erhebung an einer Installation bleibt offen und ist in der Zeile ausgewiesen |
+| E5 | Wie wird die Wirkung nachgewiesen? | **Zwei Schichten, zwei Sonden:** Prüfung 27 im Repositorium, der Abbruch bei der Installation. Dazu eine Gegenprobe je Schicht | Die Installationssonde braucht eine vollständige Kopie des Repositoriums und macht den Lauf länger. Sie ist die wichtigere – sie steht zwischen dem Befund und einer ausgelieferten Installation |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle fünf Fragen wie vorgelegt.** E1 S3 bei `claude-code` auf `[NICHT ABBILDBAR]` mit benanntem Ersatz; E2 die Absenz wird deklariert, sonst bricht die Installation ab; E3 zusagentragend sind `permissions` und `triggers`; E4 S3 bei `devin-desktop` auf `[TEXTUELL]`; E5 Nachweis auf beiden Schichten |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **Der Ersatzsatz muss sagen, dass der Ersatz schwächer ist.** Die globale Berechtigungsschicht ist keine Beschränkung je Skill – ein Analyseskill kann schreiben, soweit die globalen Regeln es zulassen. Ein Ersatzsatz, der das verschweigt, wäre derselbe Befundtyp eine Ebene höher. **Nachgewiesen:** drei Sonden, zwei Gegenproben; die Installationssonde belegt den Abbruch, ihre Gegenprobe belegt, dass eine Installation mit benanntem Ersatz weiterhin durchläuft. **Offen bleibt:** `disallowed-tools` ist nicht erhoben und trägt einen VERIFY-Marker; die Wirkung der Skill-`permissions` bei `devin-desktop` ebenfalls |
+| Umsetzung | umgesetzt mit `0.31.0` |

package/.koolie/core/governance/change-requests/CR-2026-051-quellenkarte-und-ueberholter-stand.md

@@ -0,0 +1,110 @@
+# Änderungsantrag `CR-2026-051`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Quellenkarte führt an einen leeren Ordner, und das Hauptdokument beschreibt einen Stand von vor zwanzig Releases |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `README.md` (Verzeichnisbaum, Abschnitt „Arbeiten an diesem Repository", Update-Tabelle), `docs/ADOPTION_GUIDE.md`, `clients/README.md` (Schritte 4 und 6), `build/doc/29-grenzen.md` |
+| Ebene laut Entscheidungsbaum 6 | Kern – Dokumentation |
+| Art | Befund **B12** des unabhängigen Reviews vom 2026-09-12, P3; **gegengeprüft** |
+| Dringlichkeit | mit Paket 3 – der Befund kostet jeden neuen Mitwirkenden Zeit und ist billig zu beheben |
+
+## 1. Anlass und Problem
+
+Drei Aussagen beschreiben einen überholten Stand. **Alle drei sind nachgeprüft:**
+
+### Die Quellenkarte führt an einen Ordner mit einer README darin
+
+`README.md` nennt das `root-template/` des Client Packs als „Quelle der Wahrheit" für Änderungen
+am Kern; `docs/ADOPTION_GUIDE.md` sagt, der Kern bringe die Bestandteile dort mit.
+
+**Nachgezählt:** `git ls-files` findet unter `clients/*/root-template/` **genau zwei Dateien** –
+je eine README der Laufzeitschicht. `seed_paths` ist in **beiden** Manifesten leer. Die
+gemeinsamen Quellen liegen seit `CR-2026-010` unter `framework/runtime/`, `framework/skills/`
+und `templates/`.
+
+**Ein neuer Mitwirkender, der der README folgt, öffnet ein leeres Verzeichnis** und sucht dann
+selbst. Das Abnahmekriterium des Reviews ist genau dieser Fall.
+
+### Die Update-Tabelle verspricht eine Aktualisierung, die nicht stattfindet
+
+`README.md` führt die Hook-Konfiguration unter „wird bei `--update` überschrieben".
+
+**Nachgeprüft:** Bei **beiden** Packs zeigt `<HOOKS_FILE>` auf dieselbe Datei wie
+`<PERMISSIONS_FILE>`, und diese steht unter `shared_seed` – sie wird **nur bei der
+Erstinstallation** angelegt und bleibt danach unberührt. Das ist eine bewusste
+Eigentumsentscheidung und richtig; die Tabelle sagt trotzdem das Gegenteil.
+
+**Der Fall ist nicht theoretisch:** Release 0.30.0 hat die Suchwerkzeuge in die
+Hook-Konfiguration aufgenommen. Ein Projekt, das der Tabelle glaubt, hält sie nach `--update`
+für aktuell – und der Suchkanal bleibt unbewacht.
+
+### Kapitel 29 beschreibt den Stand der Erstfassung als gegenwärtig
+
+`build/doc/29-grenzen.md` sagt weiterhin, **kein** Mechanismus sei je in einer Zielinstallation
+ausgeführt worden, der Schutz-Hook laufe **fail-open** und alle dynamischen Tests stünden auf
+`offen`.
+
+Der Abschnitt ist mit „Grenzen dieser Erstfassung" überschrieben – und wird unverändert in das
+**aktuelle** Hauptdokument eingebettet. Wer das Dokument liest, liest es als Gegenwart.
+Tatsächlich ist AP2 für beide Packs gefahren, und beide Manifeste führen
+`hook_fail_closed: true` seit 0.24.0.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Eine Tabelle „Wo eine Änderung hingehört"** in der `README.md` – je Artefaktart die Quelle.
+   Das `root-template/` wird als das beschrieben, was es ist: die README der Laufzeitschicht.
+2. **Die Update-Tabelle nennt die Hook-Konfiguration beim Projekt**, mit einem ausdrücklichen
+   Hinweis, dass eine Hook-Änderung eines Releases **von Hand nachzutragen** ist – und dass der
+   `CHANGELOG.md`-Eintrag solche Fälle unter „Migrationshinweise" führt.
+3. **`ADOPTION_GUIDE.md` und `clients/README.md`** nennen dieselbe Quellenkarte; Schritt 4 der
+   Pack-Erstellung sagt, dass das `root-template/` nur die README enthält.
+4. **Kapitel 29 bekommt einen datierten Vorspann**, der es als Zeitdokument kennzeichnet und die
+   drei überholten Aussagen ausdrücklich benennt, mit Verweis auf die aktuelle Quelle. Der
+   Bestandstext bleibt unverändert – er ist die Erstfassung und soll es bleiben.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Er schafft `root-template/` nicht ab.** Die README dort ist Teil der Laufzeitschicht, die
+  ein Projekt bekommt; und `install.py` erkennt ein Pack an diesem Verzeichnis.
+- **Er ändert das Updateverhalten nicht.** Dass die Berechtigungsdatei dem Projekt gehört, ist
+  richtig und bleibt. Berichtigt wird die Beschreibung, nicht das Verhalten.
+- **Er schreibt Kapitel 29 nicht um.** Ein Zeitdokument, das man nachträglich glättet, ist keines
+  mehr.
+- **Er baut keine gemeinsame Statusquelle.** Das Review schlägt vor, veränderliche Statusangaben
+  aus einer versionsgebundenen Quelle einzubetten. Das ist richtig und ein eigener Gegenstand –
+  siehe E3.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern – Dokumentation.
+- [x] Verschärfungsprinzip: keine Regel berührt.
+- [x] Widerspruchsfreiheit: D-16, D-17, D-20 (`CR-2026-010`, die Saat kommt aus dem Kern), D-31
+      (`hook_fail_closed`) gelesen; die Korrekturen ziehen nach, was dort entschieden ist.
+- [x] Laufzeitfassungen: nicht betroffen.
+- [x] Belegstatus: **nachgeprüft** – `git ls-files` für das `root-template/`, beide Manifeste für
+      `<HOOKS_FILE>` und `shared_seed`, beide für `hook_fail_closed`.
+- [x] Test- und Validierungsbedarf: **keiner.** Reine Textkorrektur; sie stellt keine Prüfung
+      auf. Eine Prüfung auf Wortlaut wäre eine, die jede Umformulierung meldet.
+- [x] Overlays: nicht betroffen.
+- [ ] Dokumentation: CHANGELOG, Roadmap.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Quellenkarte als Tabelle oder als Fließtext? | **Als Tabelle.** Die Frage lautet „wo ändere ich X" und hat je X genau eine Antwort. Fließtext hat den Befund gerade erst erzeugt | Die `README.md` wird länger. Sie ist der Einstieg, und der Einstieg darf länger sein als der Rest |
+| E2 | Kapitel 29 berichtigen oder kennzeichnen? | **Kennzeichnen, datiert, mit Nennung der überholten Aussagen.** Der Text ist die Erstfassung; ihn stillschweigend nachzuziehen nähme dem Dokument seine Zeitaussage – und niemand sähe, wie weit das Projekt gekommen ist | Ein Vorspann, den man lesen muss, bevor man den Abschnitt liest. Wer nur den Abschnitt liest, liest weiterhin Überholtes |
+| E3 | Veränderliche Statusangaben aus einer gemeinsamen Quelle einbetten? | **Nein, nicht in diesem Antrag.** Das Review schlägt es vor und es ist richtig – aber es ist ein Bauvorhaben am Dokumentenbau, kein Redaktionsschritt. Ein Antrag, der einen Befund behebt und dabei ein Werkzeug erfindet, wird nicht fertig (dieselbe Begründung wie `CR-2026-044` E4) | Beim nächsten Release veraltet die nächste Statusangabe. Der Vorspann aus E2 nennt deshalb die **Quelle** des aktuellen Stands, statt ihn zu wiederholen |
+| E4 | Den Migrationsfall „Hooks von Hand nachtragen" nur beschreiben oder prüfen? | **Nur beschreiben.** Eine Prüfung müsste die installierte Hook-Konfiguration mit der Kernquelle vergleichen – das ist der offene Gegenstand aus `CR-2026-044` E4 (Abgleich Quelle/Laufzeitfassung) und gehört dorthin | Ein Projekt, das den `CHANGELOG.md` nicht liest, merkt den Rückstand nicht. **Der Pilot ist der erste Fall** und steht auf 0.29.0 |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle vier Fragen wie vorgelegt.** E1 Quellenkarte als Tabelle; E2 Kapitel 29 wird datiert gekennzeichnet, nicht umgeschrieben; E3 die gemeinsame Statusquelle bleibt einem eigenen Gegenstand; E4 der Migrationsfall wird beschrieben, nicht geprüft |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **Der Hinweis zur Hook-Konfiguration muss den konkreten Fall nennen, nicht nur die Regel.** 0.30.0 hat die Suchwerkzeuge aufgenommen; ein Projekt, das nur `--update` fährt, hat sie nicht. **Der Pilot ist der erste Betroffene** und steht auf 0.29.0. **Offen bleibt E3** – veränderliche Statusangaben stehen weiterhin an mehreren Stellen; und **E4** hängt am Abgleich zwischen Quell-Overlay und Laufzeitfassung (`CR-2026-044` E4), der seit 0.28.0 offen ist |
+| Umsetzung | umgesetzt mit `0.31.0` |