@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-059-unteragent-tiefe-und-widerspruch.md

@@ -0,0 +1,125 @@
+# Änderungsantrag `CR-2026-059`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die drei Lücken aus `CR-2026-058` sind geschlossen – die restriktivere Liste gewinnt, die Sperre gilt im Hintergrund und zwei Ebenen tief |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-13 |
+| Betroffene Artefakte | `clients/claude-code/CLIENT_PACK.md` (Zeilen **S3**, **A1**), `framework/core/05-working-model.md` (M1 und die Regel zu Hintergrund-Subagenten), `tests/scripts/validate-framework.py` (Prüfung 35 neu), `tests/scripts/probe-pruefungen.py`, `tests/EDGE_CASES.md` |
+| Ebene laut Entscheidungsbaum 6 | **Client Pack** (Matrix) und **Core** (Arbeitsmodell) |
+| Art | Nachtrag zu `CR-2026-058`: die drei dort ausdrücklich als **nicht gemessen** ausgewiesenen Punkte; **erhoben am 2026-09-13**, sieben Läufe, davon drei Kontrollläufe |
+| Dringlichkeit | **Paket 6.** Kein P1: Alle vier Befunde fallen **zugunsten** der Durchsetzung aus. Der Antrag schließt Belegzusagen ab, die bis hierher als Erwartung dastanden |
+
+## 1. Anlass
+
+`CR-2026-058` hat drei Punkte ausdrücklich offen ausgewiesen, und die Roadmap nennt den ersten
+davon „die billigste Anschlussmessung". Sie sind gemessen:
+`tests/protocols/2026-09-13-erhebung-unteragent-tiefe.md`.
+
+**Alle drei Aufbauten haben je einen eigenen Kontrolllauf**, und die Sonden schreiben diesmal
+das Werkzeug vor – die Lehre aus Lauf V-M des Vortags, wo der Gegenstand sich sein Werkzeug
+selbst gesucht hat.
+
+### 1.1 Befund 1: Die restriktivere Liste gewinnt
+
+| Lauf | Aufbau | Ergebnis |
+|---|---|---|
+| **ZS** | Skill sperrt `Write, Edit`; Profil nennt `tools: Read, Grep, Glob, **Write**` | **`Write` fehlte im Vorrat** |
+| **ZS-K** | **Kontrolllauf:** derselbe Skill ohne das Feld | Unteragent zählte vier Werkzeuge auf und schrieb |
+
+**Die Skill-Sperre schneidet aus dem Profilvorrat heraus.** Dieselbe Semantik, die D-64
+gegenüber der `allow`-Liste gemessen hat: **Eine Erlaubnis holt ein entferntes Werkzeug nicht
+zurück** – gleich, ob sie in der Berechtigungsdatei steht oder im Agentenprofil. Praktisch:
+**Man kann die Liste nur enger machen, nie weiter.**
+
+### 1.2 Befund 2: Die Sperre gilt im Hintergrund
+
+`run_in_background: True` ist im Rekorder beider Läufe belegt. Messlauf: `Write` fehlte.
+Kontrolllauf: derselbe Hintergrund-Unteragent schrieb.
+
+**Das war die plausibelste Vermutung für eine Lücke** – ein Hintergrundlauf ist vom aufrufenden
+Turn entkoppelt, und die Sperre gilt für den Turn. Sie besteht nicht.
+
+### 1.3 Befund 3: Sie reicht mindestens zwei Ebenen tief
+
+Der Start der zweiten Ebene **gelang** (zwei `Agent`-Aufrufe im Rekorder, der zweite mit
+eigener `agent_id`), und `Write` fehlte auch dort. Der Kontrolllauf zeigt im selben Aufbau, wie
+die zweite Ebene schreibt.
+
+**„Mindestens zwei" ist wörtlich gemeint** – drei Ebenen sind nicht gemessen.
+
+### 1.4 Befund 4, nicht gesucht: Ein beschränktes Profil kann keine Ebene öffnen
+
+Das Profil `tools: Read, Grep, Glob` – **genau die Form, die `fw-reviewer` nach der Abbildung
+trägt** – hat **kein Startwerkzeug**. Der Rekorder zeigt einen einzigen `Agent`-Aufruf, den des
+Hauptagenten.
+
+> **Das trägt die Zusage A1 an einer Stelle, an der sie sonst offen wäre:** Ein „rein lesendes"
+> Reviewprofil könnte sich sonst über eine zweite Ebene erweitern, deren Profil weniger
+> beschränkt ist. Es kann nicht – die Erweiterung bräuchte ein Werkzeug, das ihm fehlt.
+
+**Und genau daran hängt eine stille Annahme.** Sie hält heute, weil
+`agent_frontmatter.tool_names` kein Startwerkzeug abbildet. Erweitert jemand diese Abbildung,
+fällt die Zusage **lautlos** – niemand prüft es. Das ist der Anlass für E1.
+
+### 1.5 Beobachtung: Der Wortlaut des Clients überzeichnet seine eigene Reichweite
+
+```text
+Error: No such tool available: Write. Write is disabled for this session, in subagents
+as well as here.
+```
+
+**Die zweite Hälfte bestätigt diese Erhebung. Die erste überzeichnet:** „for this session" ist
+nicht gemessen – D-64 hat belegt, dass Turn 2 derselben Sitzung wieder schreiben konnte.
+
+Das ist eine Aussage des Clients, **kein Messwert**. Es ändert an der Turngrenze nichts. Es
+gehört trotzdem benannt: **Jede Nutzerin bekommt diese Zeile zu sehen, das Protokoll nicht.**
+
+## 2. Was heute im Repositorium steht
+
+| Stelle | Heutiger Stand | Warum das nicht bleiben kann |
+|---|---|---|
+| Zeile **S3** | „Nicht gemessen: Hintergrund-Unteragenten und zwei Ebenen tief" | Beides ist gemessen; der Satz beschreibt einen Stand von gestern |
+| Zeile **A1** | keine Aussage zur zweiten Ebene | Die Zusage „rein lesend" ließe sich sonst durch eine untergeordnete Ebene aushebeln – gemessen geht das nicht, und das gehört dazugesagt |
+| `05-working-model.md`, M1 | das Profil ist „der belastbarere Weg" | Richtig, und jetzt stärker belegbar: Es kann sich nicht selbst erweitern |
+| `05-working-model.md`, Hintergrund-Subagenten | „technisch nicht abbildbar" | Bleibt richtig für „nur Hintergrund". **Neu ist:** Sperrt man ein Werkzeug, gilt das auch im Hintergrund – die Regel ist damit nicht so schutzlos, wie der Satz allein klingt |
+| nichts | die stille Annahme aus 1.4 | Sie hält an einer Abbildung, die niemand gegen sie prüft |
+
+## 3. Vorgeschlagene Änderung
+
+1. **Zeile S3**: Die beiden „nicht gemessen"-Punkte werden durch die Messung ersetzt, und die
+   Widerspruchsregel kommt dazu (die restriktivere Liste gewinnt).
+2. **Zeile A1**: Befund 4 und die Beobachtung aus 1.5.
+3. **`05-working-model.md`**: M1 und die Regel zu Hintergrund-Subagenten werden nachgezogen.
+4. **Prüfung 35 (neu)**: Die erzeugte `tools`-Liste eines Agentenprofils darf keinen Namen aus
+   `agent_start_tools` des Packs führen, und `agent_frontmatter.tool_names` darf keinen
+   abbilden.
+5. **`EDGE_CASES.md`**: ein Grenzfall zum Widerspruch zwischen Profil und Skill.
+
+## 4. Auswirkungen
+
+- **Keine Einstufung ändert sich.** S3 und A1 bleiben `[TECHNISCH]`; die Summen bleiben.
+- **Vier Punkte wandern von „nicht gemessen" auf gemessen.**
+- **Prüfung 35 fängt heute nichts** – siehe E1, und das steht so im Nachweis.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | Soll eine Prüfung durchsetzen, dass ein Agentenprofil kein Startwerkzeug bekommt? | **Ja, Prüfung 35.** Die Zusage aus Befund 4 hängt heute allein daran, dass `agent_frontmatter.tool_names` kein Startwerkzeug abbildet – eine Erweiterung dieser Abbildung ließe sie **lautlos** fallen | **Sie fängt heute nichts**, weil die Abbildung das Werkzeug gar nicht kennt. Das ist dieselbe Bauart wie der fünfte Gegenstand der Prüfung 32 und **mit derselben Ehrlichkeit zu begründen: eine Verankerung, keine Behebung.** Wer sie als Risikoabwehr verkauft, überzeichnet |
+| **E2** | Wird der irreführende Wortlaut des Clients ins Pack aufgenommen? | **Ja, als Beobachtung bei S3.** „for this session" ist nicht, was gemessen ist | Die Zeile wird noch länger, und sie zitiert eine fremde Fehlermeldung. **Dafür steht die Abweichung dort, wo jemand sie sucht** – wer die Meldung sieht und ihr glaubt, nimmt mehr Reichweite an, als belegt ist |
+| **E3** | Wird der umgekehrte Widerspruch (Profil sperrt, Skill erlaubt) mitgemessen? | **Nein, und er wird als Erwartung ausgewiesen.** Nach Befund 1 ist er vorhersagbar; eine Vorhersage ist aber keine Messung, und das muss dastehen | Eine Lücke bleibt offen. **Die Alternative wäre, sie mit einer Erwartung zu schließen** – genau das, was sich dieses Projekt abgewöhnt hat |
+| **E4** | Wird „mindestens zwei Ebenen" so formuliert, oder allgemein? | **Wörtlich „mindestens zwei".** Drei sind nicht gemessen | Die Formulierung wirkt kleinlich. Sie ist genau: Der Mechanismus legt mehr nahe, gemessen sind zwei |
+| **E5** | Ein Release oder an 0.36.0 anhängen? | **Ein eigenes Release, `0.37.0`.** 0.36.0 ist gemergt; ein Nachtrag in dessen Protokoll würde verwischen, was wann gemessen wurde | Ein elftes Release am selben Tag. Der Preis ist Buchhaltung, der Gewinn ist eine saubere Belegkette |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle fünf Fragen wie vorgelegt.** E1 Prüfung 35, begründet als Verankerung und nicht als Risikoabwehr; E2 der Wortlaut des Clients kommt als Beobachtung in S3; E3 der umgekehrte Widerspruch bleibt ungemessen und wird als Erwartung ausgewiesen; E4 „mindestens zwei Ebenen" wörtlich; E5 eigenes Release `0.37.0` |
+| Datum | 2026-09-13 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-72 (die restriktivere Liste gewinnt; Hintergrund und zweite Ebene sind mitgemessen), D-73 (ein Agentenprofil bekommt kein Startwerkzeug, und Prüfung 35 hält es fest) |
+| Auflagen | **Die Grenzen der Messung bleiben in jeder Nennung stehen:** „mindestens zwei Ebenen", der ungemessene umgekehrte Widerspruch, und dass der Schutz-Hook nur für die **erste** Ebene als blockierend gemessen ist. **Die Begründung für Prüfung 35 wird nicht zur Risikobehauptung aufgewertet** – sie fängt heute nichts, und der Wirkungsnachweis sagt das. **Und die Clientmeldung wird als Zitat kenntlich gemacht**, nicht als Belegsatz des Frameworks |
+| Ziel-Release | `0.37.0` |
+| Umsetzung | umgesetzt mit `0.37.0` |

package/.koolie/core/governance/change-requests/CR-2026-060-stumme-brueche.md

@@ -0,0 +1,170 @@
+# Änderungsantrag `CR-2026-060`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der stumme Bruch wird laut – Präparationswächter, Zellenzählung des Decision Logs, und eine Prüfung, die den richtigen Text beanstandet |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-13 |
+| Betroffene Artefakte | `tests/scripts/probe-pruefungen.py` (Runner und elf Präparationen), `tests/scripts/validate-framework.py` (Prüfung 36 neu, gemeinsame Zellenzerlegung an vier Stellen), `governance/DECISION_LOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** (Prüfwerkzeuge des Frameworks) |
+| Art | Änderung; erledigt zwei seit mehreren Releases benannte, nicht umgesetzte Punkte und einen dritten, den die Gegenprüfung gefunden hat |
+| Dringlichkeit | regulär. **Kein P1:** Keiner der drei Punkte betrifft eine Zusage gegenüber einem Projekt. Sie betreffen die Werkzeuge, mit denen dieses Projekt seine Zusagen prüft – und deren Ausfall ist deshalb still |
+
+## 1. Anlass
+
+Zwei Punkte stehen seit mehreren Releases im Repositorium und sind nicht umgesetzt:
+
+| Punkt | Seit | Wie oft aufgetreten |
+|---|---|---|
+| **Soll eine Gegenprobe ihre Summen ableiten?** Ermessensfrage, ausdrücklich als solche benannt | 0.34.0-Protokoll Abschnitt 4.x | **viermal in Folge** (0.34.0, 0.35.0, 0.36.0, 0.37.0), jedes Mal von Hand nachgezogen; mit 0.36.0 kam eine Kennungskollision dazu (`G-18`) |
+| **Die Zellen der Decision-Log-Tabellen zählt nichts.** Prüfvorschlag, ausdrücklich nicht Teil seines Releases | 0.35.0-Protokoll Abschnitt 7 | **zweimal bestätigt** – beim Eintragen von D-64 und beim Eintragen von D-69 |
+
+**Beide sind gegengeprüft** (`tests/protocols/2026-09-13-gegenpruefung-stumme-brueche.md`,
+drei Messungen an Kopien des Repositoriums). Beide bestätigen sich, **und die Gegenprüfung
+findet einen dritten Punkt, den keiner von beiden nennt.**
+
+### 1.1 Befund 1: Die halb greifende Präparation sieht aus wie ein Prüfungsfehler
+
+Eine Kopie mit einem **echten** zwanzigsten Grenzfall – der Zustand, den ein Release
+hinterlässt – bekam die heutige Präparation der Gegenprobe 30. Die erste ihrer beiden
+Ersetzungen traf nicht, die zweite schon.
+
+```text
+Baum veraendert: True            <- der baumhash-Waechter meldet nichts
+FEHLER  leitwerk-core/tests/EDGE_CASES.md: 21 Grenzfallzeilen, der Steckbrief nennt 20.
+        Eine Zahl, die nicht stimmt, ist kein Nachweis
+Gegenprobe bestanden: False
+```
+
+**Die Gegenprobe fällt mit einer Meldung, die aussieht, als habe sie einen echten Fehler im
+Repositorium gefunden.** Dort ist keiner – die Sonde hat ihren eigenen Suchtext verloren.
+
+> **`baumhash` ist ein Alles-oder-nichts-Wächter.** Bei *n* Ersetzungen belegt er „mindestens
+> eine hat gegriffen", nie „alle". Deshalb melden sich die einteiligen Präparationen selbst
+> und die mehrteiligen nicht. **Das ist eine Lücke im Runner, keine Nachlässigkeit beim
+> Schreiben der Sonden** – und sie schließt sich nicht dadurch, dass man Suchtexte
+> sorgfältiger pflegt.
+
+**Die Lücke ist größer als die Frage, die sie ausgelöst hat.** Ausgezählt:
+
+| Lage | Anzahl | Deckt `baumhash`? |
+|---|---|---|
+| **a** über einen Runner mit `baumhash`, **eine** Ersetzung | Regelfall | **ja**, mit erklärender Meldung – **kein Befund** |
+| **b** über einen solchen Runner, **mehrere** Ersetzungen | 3 Stellen, zusammen 9 Ersetzungen in 5 Dateien | **nein** |
+| **c** Bündelfunktionen mit direktem `melde()` | 9 Funktionen, 35 Meldestellen, darin 3 mit Textpräparation (7 Ersetzungen) | **nein, gar nicht** |
+
+**Neun Bündelfunktionen mit 35 Meldestellen laufen ohne jeden Präparationswächter.** Runner
+**mit** Wächter gibt es drei: `sonde()`, `gegenprobe()`, `sonde_ohne_wert()`.
+
+### 1.2 Befund 2: Die Zellen der Decision-Log-Tabellen zählt nichts
+
+Gezählt über sechs Auscheckstände, maskierte Striche als Inhalt behandelt:
+
+| Stand | Abweichende Zeilen |
+|---|---|
+| 0.32.0, 0.33.0 | **je 1** – D-29 |
+| 0.34.0 | **4** – D-29, D-61, D-62, D-63 |
+| 0.35.0 bis 0.37.0 | 0 |
+
+**Der Befund bestätigt sich und ist heute behoben.** Eine Prüfung, die jetzt entsteht, fängt
+**nichts** – dieselbe Lage wie bei Prüfung 35. **Der Unterschied ist erheblich:** Prüfung 35
+fand auch im Vorstand nichts, weil ihr Gegenstand dort nicht existiert. Diese Prüfung hätte
+gegen 0.34.0 vier Fundstellen gemeldet. **Ihr Gegenbeweis ist kein Kunstgriff, sondern ein
+Abzählen.**
+
+**D-29 stand fünfundzwanzig Releases lang zerrissen** und wurde von jedem Validatorlauf
+gesehen. Gefunden hat sie ein Mensch beim Eintragen einer anderen Zeile.
+
+### 1.3 Befund 3, nicht gesucht: Prüfung 30 beanstandet einen GFM-korrekten Text
+
+Prüfung 30 zerlegt eine Grenzfallzeile mit `.split("|")`. GFM verlangt für einen Strich
+**innerhalb** einer Zelle die Maskierung `\|`; `.split("|")` sieht sie nicht. Gemessen an
+einer Kopie, mit demselben Codespan, den **D-69 seit 0.36.0 trägt**:
+
+```text
+FEHLER   leitwerk-core/tests/EDGE_CASES.md: Grenzfall G-14 hat 9 Spalten statt 7
+```
+
+**Das ist die Bauform, vor der der Wirkungsnachweis zu Prüfung 28 warnt:** eine Prüfung ohne
+die nötige Unterscheidung beanstandet den richtigen Text. Heute ist der Fehlalarm latent –
+keine Grenzfallzeile trägt einen maskierten Strich. **Er zählt trotzdem, aus zwei Gründen:**
+
+1. **Er verbietet es, Prüfung 36 naiv zu bauen.** Naiv gezählt trügen D-29 und D-69 heute
+   **acht** Zellen statt sechs; die neue Prüfung meldete an ihrem ersten Lauf **zwei
+   Fehlalarme auf korrektem Text.**
+2. **Die Zellenzerlegung liegt viermal im Validator, jedes Mal eigenhändig** – `:1686`,
+   `:1838`, `:2528`, `:3033`. Eine fünfte Stelle wäre die fünfte Gelegenheit für denselben
+   Fehler.
+
+## 2. Die Ermessensfrage, um die es eigentlich geht
+
+> Soll die Gegenprobe ihre Summen aus der Tabelle **ableiten** – und beweist sie dann noch,
+> was sie beweisen soll, oder verdoppelt sie nur die Rechenweise der Prüfung?
+
+**Die Gegenfrage ist echt, und keine Messung entscheidet sie.** Was die Gegenprüfung beiträgt,
+ist die Trennung zweier Dinge, die vier Releases lang als eines behandelt wurden:
+
+| | Frage | Art |
+|---|---|---|
+| **a** | Woher nimmt die Gegenprobe ihre Zielsumme? | **Ermessen** – abgeleitet ist bequemer und belegt weniger |
+| **b** | Was passiert, wenn ein Suchtext der Präparation nicht mehr trifft? | **kein Ermessen** – heute erscheint es als Prüfungsfehler, und das ist schlicht falsch |
+
+**b ist unabhängig von a zu beheben.** Ist b behoben, verliert a den größten Teil seines
+Drucks: Der wörtliche Wert bleibt der teurere Weg, aber sein Bruch kostet dann eine Zeile
+Diagnose statt einer Fehlersuche im Repositorium.
+
+## 3. Vorgeschlagene Änderung
+
+1. **Präparationswächter** in `probe-pruefungen.py`: ein Helfer `ersetze(pfad, *paare)`, der
+   jede Ersetzung einzeln auf die erwartete Trefferzahl prüft und bei Abweichung eine
+   `Praeparationsfehler`-Ausnahme wirft. `sonde()` und `gegenprobe()` fangen sie und melden
+   `[Suchtext trifft nicht: '…']`; die Bündelfunktionen laufen über einen Wrapper, der sie
+   ebenso meldet und das Bündel abbricht.
+2. **Kennungswächter** `frei(pfad, kennung)`: Eine synthetische Kennung, die eine Präparation
+   einführt (`G-99`, `Z9`), darf im Zieldokument nicht bereits vorkommen. Bricht sie laut ab,
+   sobald ein Release die Kennung wirklich vergibt.
+3. **Sechs Präparationen** auf den Helfer umgestellt – die drei mehrteiligen und die drei mit
+   Suchtext in den Bündeln; zusammen 14 Ersetzungsstellen und zwei Zeileneinfügungen. **Alle
+   drei Runner mit `baumhash` fangen den Abbruch**, die neun Bündelfunktionen laufen über den
+   Wrapper.
+4. **Die Summen bleiben wörtlich verankert** (siehe E1) – mit dem Wächter davor.
+5. **Prüfung 36 (neu)**: Jede Tabellenzeile in `DECISION_LOG.md` führt so viele Zellen wie die
+   Kopfzeile ihrer Tabelle, maskierte Striche als Inhalt.
+6. **Eine gemeinsame Zellenzerlegung** im Validator, verwendet an allen vier Stellen; damit
+   ist auch der Fehlalarm aus 1.3 behoben.
+
+## 4. Auswirkungen
+
+- **Keine Einstufung ändert sich, keine Summe, keine Zusage.** Der Antrag berührt
+  ausschließlich Prüfwerkzeuge.
+- **Prüfung 36 fängt heute nichts** – das steht so im Wirkungsnachweis, und ihr Gegenbeweis
+  läuft gegen 0.34.0.
+- **Prüfung 30 wird toleranter** gegenüber einer Schreibweise, die sie heute zu Unrecht
+  beanstandet. Sie wird an keiner Stelle schwächer: Ein unmaskierter Strich zerreißt die Zeile
+  weiterhin, und genau das meldet sie.
+- **Der Sondenlauf bekommt eine neue Meldeform.** Ein `[Suchtext trifft nicht]` ist ein
+  **Fehlschlag**, wie `[nichts praepariert]` – es zählt in `fehler` und lässt den Lauf rot
+  werden. Das ist gewollt: Eine Sonde, die nicht präpariert, hat nichts gemessen.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | Soll eine Gegenprobe ihre Summen aus der Tabelle **ableiten**? | **Nein – sie bleiben wörtlich verankert.** Eine abgeleitete Summe rechnet nach derselben Regel wie die Prüfung; rechnet die Prüfung falsch, rechnet die Gegenprobe genauso falsch und besteht. **Der wörtlich gesetzte Wert ist ein unabhängiger Erwartungswert von Hand** – das ist der Beleg, den eine Gegenprobe schuldet | **Der Bruch bleibt.** Jede neue Matrixzeile und jeder neue Grenzfall bricht die Verankerung weiterhin, und jemand muss sie nachziehen. **Der Antrag beseitigt den Preis nicht, er macht ihn bezahlbar:** Statt einer Fehlersuche im Repositorium kostet er eine Zeile, die den nicht mehr passenden Suchtext nennt. **Wer das für zu wenig hält, hat recht in der Sache und muss dann die Zielsumme woanders herholen als aus der Rechenweise der Prüfung** – eine dritte Quelle gibt es nicht |
+| **E2** | Bekommt `probe-pruefungen.py` einen Präparationswächter? | **Ja, und zwar genau dort, wo `baumhash` blind ist** – bei mehrteiligen Präparationen und in den Bündelfunktionen. **Nicht** bei den einteiligen: Dort meldet der Runner heute schon das Richtige, und eine zweite Prüfung derselben Sache wäre Ballast | **Sechs Präparationen zu ändern**, in der Datei, die alle Nachweise trägt. Ein Fehler dabei fällt im selben Lauf auf – das ist der Vorteil, den dieses Skript vor allen anderen hat. **Und: Der Wächter deckt nur den Suchtext, nicht die Absicht.** Eine Ersetzung, die trifft und das Falsche tut, findet er nicht |
+| **E3** | Bekommt eine synthetische Kennung einen Wächter gegen Kollision? | **Ja.** Am 13.09. trug die Gegenprobe 30 ausgerechnet `G-18` – dieselbe Kennung, die 0.36.0 wirklich vergeben hat. **Beide Fallen waren in der Übergabe benannt, und beide sind trotzdem zugeschnappt**; eine benannte Falle, in die man zweimal tritt, gehört in den Code, nicht in eine Datei außerhalb des Repositoriums | Drei Zeilen mehr je betroffener Präparation. **Der Wächter ist genau so klug wie die Kennung, die man ihm gibt** – er prüft Abwesenheit, nicht Eignung |
+| **E4** | Entsteht Prüfung 36 für die Zellen des Decision Logs? | **Ja.** Vier zerrissene Zeilen in 0.34.0, eine davon seit fünfundzwanzig Releases; gefunden hat sie jedes Mal ein Mensch. Prüfung 30 tut dasselbe für `EDGE_CASES.md`, die Bauform liegt vor | **Sie fängt heute nichts** – das ist mit derselben Ehrlichkeit zu sagen wie bei Prüfung 35. **Anders als dort ist ihr Gegenbeweis aber ein Abzählen und keine Konstruktion:** vier Fundstellen gegen 0.34.0. Wer sie dennoch als Risikoabwehr verkauft, überzeichnet |
+| **E5** | Wird der Fehlalarm aus 1.3 mitbehoben, und wie weit? | **Ja, über eine gemeinsame Zellenzerlegung an allen vier Stellen** – nicht nur bei Prüfung 30. Die Zählweise liegt viermal im Validator; eine gemeinsame Funktion macht aus vier Gelegenheiten für denselben Fehler eine | **Drei der vier Stellen ändern ihr Verhalten heute nicht** – sie nehmen die erste Zelle oder suchen über ein Muster. Der Umbau ist dort reine Vorsorge, und Vorsorge in fremdem Code ist ein Risiko. **Die Alternative – nur Prüfung 30 berichtigen – lässt drei Stellen mit der falschen Zählweise stehen**, und die nächste Prüfung kopiert eine davon |
+| **E6** | Ein eigenes Release oder Anhang an das nächste inhaltliche? | **Ein eigenes Release, `0.38.0`.** Der Gegenstand ist geschlossen und hat mit dem nächsten inhaltlichen nichts zu tun; angehängt würde er in dessen Protokoll verschwinden – wie viermal zuvor, als er als Nebensatz beim Aufräumen behandelt wurde | **Das dreizehnte Release in zwei Tagen**, und keines seiner Ergebnisse ist eine Messung am Client. Der Preis ist Buchhaltung. **Der Gewinn ist, dass diese Frage aufhört, in Nebensätzen zu wandern** |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle sechs Fragen wie vorgelegt.** E1 die Summen bleiben wörtlich, der Bruch wird laut statt beseitigt; E2 Präparationswächter genau dort, wo `baumhash` blind ist; E3 Kennungswächter; E4 Prüfung 36, begründet als Verankerung mit abzählbarem Gegenbeweis; E5 gemeinsame Zellenzerlegung an allen vier Stellen; E6 eigenes Release `0.38.0` |
+| Datum | 2026-09-13 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-74 (eine Präparation, die nicht greift, meldet sich als solche – und eine Gegenprobe leitet ihre Zielsumme nicht aus der Rechenweise der Prüfung ab), D-75 (eine Tabellenzelle endet am unmaskierten Strich, und diese Zählung liegt einmal) |
+| Auflagen | **Die Begründung für Prüfung 36 wird nicht zur Risikobehauptung aufgewertet** – sie fängt heute nichts, und der Wirkungsnachweis sagt es. **Der Gegenbeweis läuft gegen 0.34.0**, nicht gegen den unmittelbaren Vorstand: Gegen 0.37.0 fände sie nichts, und eine Null ohne diese Erklärung wäre irreführend. **Und E1 wird als das ausgewiesen, was sie ist:** eine Entscheidung gegen die bequemere Lösung mit einem Preis, der bleibt |
+| Ziel-Release | `0.38.0` |
+| Umsetzung | umgesetzt mit `0.38.0` |

package/.koolie/core/governance/change-requests/CR-2026-061-berechtigungsdatei-ohne-pruefung.md

@@ -0,0 +1,169 @@
+# Änderungsantrag `CR-2026-061`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Berechtigungsdatei nach der Installation – eine Erweiterung, die es nicht gibt, und fünfzig Regeln, die niemand nachzählt |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-13 |
+| Betroffene Artefakte | `tests/scripts/validate-framework.py` (Prüfung 37 neu), `clientmap.py` (neue öffentliche Funktion `basket_rules`, berichtigter Kommentarkopf), `tests/scripts/probe-pruefungen.py` (Sonden und Gegenprobe zu 37), `framework/core/03-security.md` (Abschnitt 4), `templates/project-overlay/OVERLAY.md` (Abschnitt 6), `governance/DECISION_LOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – die Berechtigungspolitik ist normativ (`03-security.md` Abschnitt 4), die Prüfung ist Framework-Gut |
+| Art | Änderung; erledigt die beiden Framework-Lücken, die der Pilot sichtbar gemacht hat, und den dritten Ablehnungsgrund von `CR-OTP-G-001` |
+| Dringlichkeit | **P1.** Anders als die letzten vier Releases betrifft dieser Antrag eine Zusage **gegenüber einem Projekt**: Die Berechtigungsdatei ist der Träger der Kernzusagen B1 bis B6, und außerhalb ihrer dreizehn Kernregeln prüft sie nichts |
+
+## 1. Anlass
+
+Zwei Punkte stehen als **Kandidat 1 und 2** in der Übergabe. Sie sind beide am Piloten
+aufgefallen, und sie sind zusammen der **dritte Ablehnungsgrund** von `CR-OTP-G-001`
+(„Es gibt keine geprüfte Änderungsschicht für diese Datei").
+
+**Beide sind gegengeprüft** (`tests/protocols/2026-09-13-gegenpruefung-berechtigungsdatei.md`,
+zwölf Messungen an einer frischen `claude-code`-Installation, davon zwei Gegenproben).
+**Beide bestätigen sich, und beide sind erheblich größer als die Übergabe sagt.**
+
+### 1.1 Befund 1: Geprüft werden dreizehn von fünfundsechzig Regeln
+
+Die erzeugte Datei trägt 54 `deny`-, 5 `ask`- und 6 `allow`-Regeln. Der Validator kennt davon
+die **dreizehn** Kernregeln aus `_core_rules_integrity.deny_must_contain`. Gemessen:
+
+| Eingriff | Validator |
+|---|---|
+| `ask` um `Bash(docker run --rm --network none:*)` ergänzt | **0 Fehler** |
+| `allow` um `Bash(docker run:*)` ergänzt | **0 Fehler** |
+| `Bash(curl:*)` aus `deny` gelöscht | **0 Fehler** |
+| **alle 41** Nicht-Kernregeln aus `deny` gelöscht | **0 Fehler** |
+| `Bash(kubectl:*)` → `Bash(kubectl delete:*)` verengt | **0 Fehler** |
+| `Bash(<TEST_COMMAND>)` → `Bash(mvn -B test:*)` (der Fall des Piloten) | **0 Fehler** |
+| `ask`-Korb geleert, `Edit(**)` und `mcp__*` verschwinden mit | **0 Fehler** |
+| *Gegenprobe:* Kernregel gelöscht | **1 Fehler** |
+| *Gegenprobe:* Kernregel in `allow` | **2 Fehler** |
+
+**Die Übergabe nennt den `ask`-Korb. Gemessen ist es der ganze Rest der Datei.** Ein Projekt
+kann `curl`, `wget`, `ssh`, `scp`, `kubectl`, `helm`, `terraform`, `npm publish`, `docker push`,
+`git rebase`, `git tag`, `git clean`, `git remote`, `chmod`, sämtliche Lockfile-Sperren und zehn
+der fünfzehn Secret-Lesesperren streichen, und der Lauf bleibt grün.
+
+**`install.py` greift es ebenfalls nicht auf:** `--update` rührt die Datei nicht an (sie steht in
+`shared_seed`, mit Hinweis in der Ausgabe), und `--check` **nennt sie nicht einmal**.
+
+### 1.2 Befund 2: Es gibt keine Overlay-Erweiterung – und drei Texte sagen etwas anderes
+
+`render_permissions` überschreibt die drei Körbe vollständig aus der Kernquelle;
+`permissions_extra` ist eine **Manifest**-Angabe, also Ebene 3. **Eine Quelle des Projekts liest
+diese Funktion nicht.** Der einzige Weg eines Projekts in die Datei ist der Platzhalter, und für
+Befehle gibt es drei.
+
+Drei Texte behaupten mehr:
+
+| | Stelle | Wortlaut |
+|---|---|---|
+| **T1** | `clientmap.py` Zeile 182, Kommentarkopf **jeder** erzeugten Datei | „Berechtigungsvorlage des Frameworks (**Ebene 3 + Overlay-Erweiterungen**)" – die Wendung bezeichnet im Repositorium sonst die Regeldateien `2N-*`, nicht gefüllte Platzhalter |
+| **T2** | `templates/project-overlay/OVERLAY.md` Abschnitt 6 | Eine Tabelle mit **sechs** Zeilen unter der Spaltenüberschrift „Freigabestufe in `<PERMISSIONS_FILE>`". **Zwei** Zeilen tragen einen Platzhalter, **vier** nicht – und für die vier gibt es keinen Weg in die Datei |
+| **T3** | `framework/core/03-security.md` Zeile 52, Abschnitt 4 (**normativ**) | „ask (**KANN im Overlay für Stufe niedrig auf allow gesetzt werden**)" – **drei Zeilen unter derselben Tabelle** steht: „Änderungen an der Regelmenge erfolgen ausschließlich über Änderungsantrag (V10)" |
+
+**T3 ist die Bauform, die dieses Projekt zum dritten Mal findet:** *die Zusage, deren Widerlegung
+im eigenen Dokument steht.* Bei B11 war es „Ausnahmen je Domain" und fünf Zeilen darunter „`deny`
+gewinnt immer"; das wurde mit 0.32.0 berichtigt. **Die Zeile darüber blieb stehen** und macht
+dieselbe Aussage über dieselbe Datei.
+
+### 1.3 Zwei Entlastungen – sie gehören dazu, weil die Ähnlichkeit trügt
+
+**Die MCP-Zeile ist *nicht* derselbe Fehler.** `03-security.md` führt „`mcp__*` | ask; Freigaben
+je Server im Overlay". Das sieht aus wie T3 und ist in Ordnung: Die Freigabe läuft über
+`<MCP_FILE>`, nicht über die Berechtigungsdatei, und `OVERLAY.md` Zeile 173 sagt es ausdrücklich
+(„Eintrag in `<MCP_FILE>` erst nach Freigabe; **Standard ask**"). **Wer T3 behebt, darf diese
+Zeile nicht mitnehmen.**
+
+**Der Regelweg für weitere Befehle trägt bereits.** `05-working-model.md` Abschnitt 3.2 und
+`root-instruction.md` Abschnitt 7 sagen: „Führe nur Befehle aus, die im Overlay freigegeben sind
+(… **weitere gemäß Overlay Abschnitt 6**)." **Diese beiden Sätze sind richtig** – sie sind eine
+Anweisung an den KI-Client, kein Versprechen über eine Datei, genau wie die M3-Regel zu
+Hintergrund-Subagenten (D-66). **Der Kanal existiert also; er ist die Regelschicht.** Falsch ist
+allein die Behauptung, der Befehl stehe danach in der Berechtigungsdatei.
+
+## 2. Warum eine `ask`-Zeile eine Ausweitung ist
+
+Gegen die Behandlung einer ergänzten `ask`-Zeile als Ausweitung lässt sich einwenden: `ask` heißt
+Rückfrage, und ein nicht gelisteter Befehl führt beim ausgelieferten `defaultMode` ebenfalls zu
+einer Rückfrage; mechanisch ändere die Zeile also nichts.
+
+**Der Einwand trägt nicht, und zwar unabhängig davon, ob er stimmt.** Was die Zeile ändert, ist
+nicht der Mechanismus, sondern die **Erklärung**: Nach `05-working-model.md` Abschnitt 3.2 führt
+der KI-Client *nur* Befehle aus, die im Overlay als freigegeben gelistet sind. Eine Zeile im
+`ask`-Korb erklärt einen Befehl für freigegeben. **Genau daran ist `CR-OTP-G-001` gescheitert** –
+nicht daran, dass `docker run` ohne Rückfrage liefe.
+
+Dieser Antrag stützt sich deshalb auf **keine** gemessene Clientwirkung des `ask`-Korbs und
+behauptet keine.
+
+## 3. Vorgeschlagene Änderung
+
+1. **Prüfung 37 (neu)** in `check_config`: Die drei Körbe der installierten Datei werden gegen
+   die aus `framework/runtime/permissions.json` und dem Manifest **erzeugte** Regelmenge gehalten.
+   Zwei Sätze, keine Ausnahmen:
+   - **Fehlt eine erzeugte Regel, ist es ein Fehler** – in jedem Korb.
+   - **Steht eine Regel zu viel, entscheidet der Korb:** in `deny` zulässig (Verschärfung), in
+     `ask` und `allow` ein Fehler (Ausweitung) – **abzüglich der Platzhalterschlitze**, die das
+     Projekt gefüllt hat.
+2. **Der gefüllte Befehlsschlitz darf das Präfixzeichen des Clients nicht tragen.**
+   `clientmap._befehl` hängt es bei einem offenen Projektplatzhalter ausdrücklich **nicht** an,
+   mit Begründung im Code. Wer es von Hand nachträgt, macht aus der Freigabe eines Befehls die
+   Freigabe einer Befehlsfamilie. Gilt nur bei `permission_exec_match: prefix`.
+3. **`clientmap.basket_rules(quelle, man, korb)`** wird öffentlich – dieselbe Bauart wie
+   `core_rules`, damit die Prüfung nicht auf eine private Funktion greift.
+4. **T1 berichtigt:** Der Kommentarkopf sagt „Ebene 3"; was dem Projekt gehört, steht zwei Sätze
+   weiter unten ohnehin schon („Platzhalter in spitzen Klammern trägt der Overlay Owner hier
+   ein – das ist der einzige Teil dieser Datei, der dem Projekt gehört").
+5. **T2 berichtigt:** Die Spalte in `OVERLAY.md` Abschnitt 6 sagt je Zeile die Wahrheit – die
+   vier Zeilen ohne Platzhalter tragen „nur Regelschicht (Abschnitt 6), kein Eintrag in
+   `<PERMISSIONS_FILE>`". Ein Satz unter der Tabelle erklärt den Unterschied.
+6. **T3 berichtigt:** Der Zusatz „KANN im Overlay für Stufe niedrig auf allow gesetzt werden"
+   entfällt in `03-security.md` **und** in `OVERLAY.md` Abschnitt 6 Zeile 1.
+7. **Sonden und Gegenprobe** zu Prüfung 37 gegen eine **frische Installation** – die Bauart von
+   Prüfung 33, aus demselben Grund: Die Prüfung hängt an einer installierten Datei, nicht an
+   einem Repositoriumstext.
+
+## 4. Auswirkungen
+
+- **Der Pilot bekommt einen Fehler.** `Bash(mvn -B test:*)` steht dort seit dem Heben auf 0.37.0.
+  **Das ist der Zweck der Prüfung** und kein Nebenschaden: Die Zeile ist genau die stille
+  Ausweitung, die Kandidat 2 beschreibt. Der zweite dort benannte Posten – ein belegter
+  `<LINT_COMMAND>`, obwohl das Overlay „Lint: nicht vorhanden" sagt – bleibt **unbeanstandet**;
+  ein gefüllter Schlitz ist ein gefüllter Schlitz, und den Abgleich mit dem Overlaytext leistet
+  diese Prüfung nicht.
+- **Ein Projekt, das eine `allow`-Regel absichtlich streicht, bekommt jetzt einen Fehler.** Das
+  Streichen ist eine Verschärfung und damit sachlich zulässig – aber `03-security.md` Abschnitt 4
+  sagt normativ zu, dass die Regel dasteht. Der Weg dahin ist der Ausnahmeprozess, nicht die
+  stille Kürzung.
+- **Bei `devin-desktop` wirkt Punkt 2 nicht** (`permission_exec_match: literal`). Die Prüfung
+  läuft dort, der Präfixteil greift nicht – und das ist keine Lücke, sondern die Abwesenheit
+  ihres Gegenstands.
+- **Prüfung 37 fängt gegen den unmittelbaren Vorstand nichts**, weil die erzeugte Datei per
+  Konstruktion zu sich selbst passt. **Ihr Gegenbeweis ist deshalb eine Konstruktion und kein
+  Abzählen** – die neun Eingriffe aus 1.1, gegen 0.38.0 sämtlich stumm. Das gehört so in den
+  Wirkungsnachweis, mit derselben Ehrlichkeit wie bei Prüfung 35 und 36.
+- **`CR-OTP-G-001` bleibt abgelehnt.** Dieser Antrag beseitigt seinen dritten Ablehnungsgrund
+  nicht, sondern **bestätigt ihn**: Es gibt keine Änderungsschicht, und es soll keine geben. Die
+  Ersatzwege (A) und (B) seines Abschnitts 6.3 bleiben die einzigen.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | Bekommt ein Overlay eine ausgewiesene Erweiterungsschicht für die Berechtigungsdatei – oder wird die Grenze bestätigt? | **Grenze bestätigen.** Drei Gründe, jeder für sich tragend: (1) **Der Kanal existiert bereits** – „weitere gemäß Overlay Abschnitt 6" ist eine Anweisung an den Client, und sie ist richtig formuliert (1.3). (2) **Eine Erweiterung wäre nicht haltbar:** Die Datei steht in `shared_seed`, `--update` fasst sie nie an; eine nur bei der Installation gelesene Erweiterungsquelle wäre eine Zusage, die beim ersten Releasewechsel bricht. (3) **Das Verschärfungsprinzip verbietet sie:** Jede zusätzliche `ask`-Zeile für einen Befehl ist eine Ausweitung der Erklärung (Abschnitt 2) | **Ein Projekt mit mehr als drei Befehlen behält sie nur in der Regelschicht.** Wer die Berechtigungsdatei liest, sieht sie dort nicht – und das ist eine Unvollständigkeit, die man aushalten muss. **Die Gegenposition ist ernst zu nehmen:** Eine geprüfte Erweiterung, die *ausschließlich* `ask` befüllen und `deny` nie anfassen dürfte, wäre mechanisch möglich. Sie scheitert an (2), nicht an (3) – und an (2) scheitert sie vollständig |
+| **E2** | Entsteht Prüfung 37, und wie scharf? | **Ja, in zwei Sätzen: Fehlen ist immer ein Fehler; Überzähliges ist in `deny` zulässig und in `ask`/`allow` ein Fehler.** Das ist das Verschärfungsprinzip, mechanisch angewandt – nicht eine dritte Regel neben ihm. **Die Alternative, `deny_must_contain` einfach auf alle 54 Regeln zu erweitern, wäre zu wenig:** Sie fängt M3 bis M5, aber weder die ergänzte `allow`-Zeile noch den geleerten `ask`-Korb | **Ein Projekt, das eine `allow`-Regel streicht, bekommt einen Fehler für eine Verschärfung.** Das ist gewollt (Abschnitt 4), aber es ist ein Preis: Die Prüfung ist an dieser Stelle strenger als das Prinzip, auf das sie sich beruft. **Und sie prüft die Form, nicht den Sinn** – ein Schlitz, der mit einem unsinnigen Befehl gefüllt ist, besteht sie |
+| **E3** | Wird ein gefüllter Befehlsschlitz auf das Präfixzeichen geprüft? | **Ja.** Die Abbildung lässt es bewusst weg und schreibt den Grund daneben; ein von Hand nachgetragenes `:*` hebelt genau diese Entscheidung aus. **Am Piloten steht es bereits** – das ist kein hypothetischer Fall | **Ein Projekt, das wirklich eine Befehlsfamilie freigeben will, kann es nicht mehr still tun** und braucht einen Änderungsantrag. Das ist der Zweck. **Bei `devin-desktop` greift der Teil nicht**, weil der Client Befehle wörtlich sperrt – die Prüfung ist dort um diesen Gegenstand ärmer, und das gehört gesagt statt verschwiegen |
+| **E4** | Was geschieht mit T1, T2 und T3? | **Alle drei berichtigen, T3 durch Streichung.** Die Freigabestufe je Kontrollstufe im Overlay zu verankern, wäre die Alternative – sie scheitert daran, dass die Fußnote derselben Tabelle sie bereits verbietet (V10). **Eine Zusage, die im eigenen Dokument widerlegt wird, wird nicht durch Mechanik gerettet, sondern gestrichen** – so ist B11 entschieden worden | **Eine dokumentierte Freiheit entfällt.** Wer sie gebraucht hat, merkt es erst jetzt – aber sie war nie ausführbar: Eine so gesetzte `allow`-Zeile wäre nach E2 ab sofort ein Fehler. **Der Preis ist also nicht der Verlust, sondern das Eingeständnis**, dass sie zwölf Releases lang unausführbar dastand |
+| **E5** | Läuft Prüfung 37 im Normallauf oder nur unter `--strict-overlay`? | **Im Normallauf.** Sie trägt die Kernzusagen B1 bis B6, wie `deny_must_contain` daneben. Der Auslieferungszustand mit offenen Platzhaltern besteht sie – ein noch nicht gefüllter Schlitz ist ein Schlitz | **Jeder Lauf jedes Projekts fährt sie mit.** Kostet Laufzeit (einmal rendern) und macht den Normallauf strenger, ohne dass jemand es bestellt hat. **Das ist bei einer Kernzusage die richtige Seite des Irrtums** |
+| **E6** | Ein eigenes Release oder Anhang an das nächste? | **Ein eigenes Release, `0.39.0`.** Der Gegenstand ist geschlossen, er ist P1, und er ist der erste seit vier Releases, der eine Zusage gegenüber einem **Projekt** betrifft statt eines Prüfwerkzeugs | **Das vierzehnte Release in zwei Tagen.** Und wieder ist kein Ergebnis eine Messung am Client – gemessen ist der Validator, nicht die Wirkung der Datei |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle sechs Fragen wie vorgelegt.** E1 die Grenze wird bestätigt, es entsteht keine Erweiterungsschicht; E2 Prüfung 37 in zwei Sätzen; E3 der Präfixteil, mit benannter Lücke bei `devin-desktop`; E4 T1 bis T3 berichtigt, T3 durch Streichung, die MCP-Zeile ausdrücklich nicht; E5 Normallauf; E6 eigenes Release `0.39.0` |
+| Datum | 2026-09-13 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-76 (ein Overlay erweitert die Berechtigungsdatei nicht – der Kanal für weitere Befehle ist die Regelschicht), D-77 (die Körbe werden gegen die Kernquelle geprüft: Fehlen ist immer ein Fehler, Überzähliges nur in `ask` und `allow`) |
+| Auflagen | **Der Gegenbeweis wird als Konstruktion ausgewiesen, nicht als Abzählen** – Prüfung 37 findet gegen 0.38.0 nichts, weil die erzeugte Datei zu sich selbst passt; ihr Wert hängt allein an den Sonden. **Der Befund am Piloten wird gemeldet, nicht behoben** – die Datei dort ist untracked und gehört dem Piloten. **Und die MCP-Zeile bleibt unberührt**; sie ist der Entlastungsbefund dieser Gegenprüfung, und wer sie mitstreicht, zerstört einen stimmigen Mechanismus |
+| Ziel-Release | `0.39.0` |
+| Umsetzung | umgesetzt mit `0.39.0` |