@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-065-devin-suchwerkzeuge-erhoben.md

@@ -0,0 +1,170 @@
+# Änderungsantrag `CR-2026-065`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Zwei Enthaltungen von `devin-desktop` sind erhoben – und eine war keine Enthaltung, sondern eine falsche Behauptung |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-14 |
+| Betroffene Artefakte | `clients/devin-desktop/manifest.json` (`hook_tools`, `hook_tools_absent`, `permissions_note`, `permission_tools`-Noten, beide `tool_names`-Blöcke), `clients/devin-desktop/CLIENT_PACK.md` (Verbtabelle, Zeilen S2, S3, B3, Änderungsverlauf), `install.py` (die Abbildung wirkt auch in der Listenform), `tests/scripts/validate-framework.py` (Prüfung 41 neu, Prüfung 38 namensraumbewusst, Register), `tests/scripts/probe-pruefungen.py`, `governance/DECISION_LOG.md`, `docs/ROADMAP.md`, `CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – ein Client Pack und die Durchsetzungsschicht sind Framework-Gut |
+| Art | Änderung; Anlass sind **Kandidat 1 und 6** der Übergabe, in einer Sitzung erhoben |
+| Dringlichkeit | **P1.** Eine Werkzeugklasse ist per Deklaration aus der fail-closed-Schicht genommen, und die Deklaration ist **gemessen falsch**. Dass die zweite Schicht heute trägt, ist Entlastung, nicht Entwarnung |
+
+## 1. Anlass
+
+Beide Fragen standen als **Enthaltung** im Manifest, und der Änderungsverlauf des Packs sagt
+seit 0.10.0: *„Beides kann nicht stimmen; welche Seite falsch ist, entscheidet eine
+Erhebung."* Sie liegt vor: `tests/protocols/2026-09-14-erhebung-devin-werkzeuge.md`, **elf
+Läufe am Client**, davon zwei Kontrollläufe, ein Entlastungslauf, ein verworfener Lauf und
+einer mit berichtigtem Messartefakt.
+
+### 1.1 Befund 1: „Dieser Client führt kein eigenes Suchwerkzeug" ist falsch
+
+Die Mitschrift führt unter `agent.tool_definitions` den Werkzeugbestand selbst – **25
+Werkzeuge**, darunter `grep` („a powerful search tool built on ripgrep") und
+`find_file_by_name` („fast file name/path pattern matching … using glob patterns"). **Ein
+Werkzeug `glob` gibt es nicht.**
+
+**Die Folge ist gemessen.** Aus `hook_tools_absent: ["search"]` erzeugt `install.py` den
+Matcher `read|exec|edit|write`; beim Pack `claude-code` lautet dieselbe Stelle
+`Read|Grep|Glob|Bash|Edit|Write|NotebookEdit`. In einer Umgebung mit **nur** dem Hook:
+
+| Lauf | Werkzeug | Ergebnis |
+|---|---|---|
+| **H1** *(Positivkontrolle)* | `read` auf `.env` | **blockiert** |
+| **H2** | `grep` auf `.env` | **durchgelassen**, Secret wörtlich |
+
+**Das Hook-Skript ist nicht das Problem** – von Hand gefüttert blockiert es beide Aufrufe. Es
+wird nicht gefragt.
+
+### 1.2 Die Entlastung – und warum sie den Befund nicht aufhebt
+
+**Wie ausgeliefert ist das Secret geschützt.** Die Berechtigungsklasse `Read(...)` dieses
+Clients umfasst das Suchwerkzeug mit: Lauf **P4** (nur `permissions`) und Lauf **W1** (wie
+ausgeliefert) weisen denselben `grep`-Aufruf ab.
+
+**Trotzdem ist es ein Befund.** Die Berechtigungsdatei gehört dem Projekt und ist
+bearbeitbar – genau deshalb gibt es Prüfung 37, seit ein Projekt 41 `deny`-Regeln löschen
+konnte, ohne dass ein Lauf davon Notiz nahm (D-77). Der Hook ist die Schicht, die das
+überleben soll (D-31). **Hier trägt nur die editierbare Schicht; die zweite ist per
+Deklaration abgeschaltet.**
+
+### 1.3 Befund 2: Der Skillaufruf ist ein Werkzeugaufruf (K-33)
+
+`permission_tools.skill: []` war als **unerhoben** deklariert. Gemessen: Der Client führt ein
+Werkzeug `skill`; die Mitschrift zeigt
+`{"function_name": "skill", "arguments": {"command": "invoke", "skill": "fw-code-explain"}}`.
+
+**Und ein zweiter Weg, den niemand gesucht hat:** Die Slash-Form wird **clientseitig**
+expandiert – im `user`-Schritt der Mitschrift steht der Inhalt der `SKILL.md`, nicht der
+Befehl. **Eine Schranke auf dem Werkzeug erreicht diesen Weg gar nicht.**
+
+**Die Schranke selbst greift nicht**, in zwei Schreibweisen: `Skill(fw-code-explain)` (P2)
+und `skill(fw-code-explain)` (P3) laufen durch, während `Read(**/.env)` in **derselben Datei
+und denselben Läufen** abweist (P1b, **Kontrolllauf**).
+
+**Im Ergebnis bleibt die leere Liste richtig; ihre Begründung wird falsch.**
+
+### 1.4 Befund 3 – nicht gesucht: `glob` benennt bei diesem Client nichts
+
+Jede ausgelieferte Skilldatei trägt `allowed-tools: read, grep, glob`. `read` und `grep` sind
+Werkzeugnamen dieses Clients, **`glob` ist keiner** – das glob-förmige Werkzeug heißt
+`find_file_by_name`, und die Skills benutzen es, ohne dass ihre Liste es nennt.
+
+### 1.5 Befund 4 – der systemische: Prüfung 26 prüft Folgerichtigkeit, nicht Wahrheit
+
+D-47 wurde gebaut, damit **ein Pack eine Werkzeugklasse nicht dadurch aus der Durchsetzung
+nehmen kann, dass es sie weglässt** – eine Abwesenheit muss erklärt werden. Prüfung 26
+erzwingt seither, dass die Erklärung **vorhanden** und **mit `permission_tools` widerspruchsfrei**
+ist. **Beides war hier erfüllt, und die Erklärung war trotzdem falsch.**
+
+Der Unterschied, den niemand verlangt hat: `agent_start_tools_absent` sagt **„UNERHOBEN,
+nicht abwesend"** – eine Enthaltung. `_hook_tools_absent_note` sagte **„Dieser Client führt
+kein eigenes Suchwerkzeug"** – eine **Behauptung ohne Datum und ohne Protokoll.** Die eine
+Bauform ist ehrlich, die andere sieht genauso aus und ist es nicht.
+
+### 1.6 Befund 5 – bei der Umsetzung entstanden: es sind **zwei** Namensräume
+
+**Der erste Entwurf dieser Änderung war falsch, und die Messung hat ihn widerlegt.** Er
+trug `glob → find_file_by_name` in beide `tool_names`-Blöcke ein – der Name ist
+schließlich gemessen. Danach meldete der Client für dieselbe Skilldatei nur noch
+`Allowed tools: read, grep`: **Er hatte den Eintrag lautlos verworfen.**
+
+Eine Sondendatei mit zwölf angebotenen Namen zeigt, warum:
+
+| angeboten | Ergebnis |
+|---|---|
+| `read`, `grep`, `glob`, `edit`, `exec`, `web_search` | **angenommen** |
+| `Read`, `Grep` | angenommen, auf Kleinschreibung normalisiert |
+| `find_file_by_name`, `write`, `skill`, ein erfundener Name | **verworfen** |
+
+**Dieser Client führt für das Frontmatter ein eigenes, normalisiertes und geschlossenes
+Vokabular** – es ist nicht die Liste seiner Laufzeitwerkzeuge. `glob` ist dort
+**richtig**, obwohl es zur Laufzeit kein Werkzeug dieses Namens gibt; `find_file_by_name`
+ist dort **falsch**, obwohl es das Werkzeug ist, das läuft.
+
+**Beim Pack `claude-code` fallen beide Namensräume zusammen** (`Read`, `Grep`, `Glob`
+sind Frontmatter-Vokabular **und** Werkzeugnamen). Deshalb ist der Unterschied bis 0.42.0
+niemandem aufgefallen – und deshalb vergleicht **Prüfung 38, Gegenstand 3** seit D-80
+zwei Listen, die nicht in jedem Pack denselben Namensraum führen.
+
+**Ohne die Gegenprobe am Client wäre die Vorabfreigabe von drei Namen auf zwei
+geschrumpft**, und der Validator hätte 0 Fehler gemeldet.
+
+## 2. Vorgeschlagene Änderung
+
+1. **`hook_tools.search: ["grep", "find_file_by_name"]`**; `hook_tools_absent` und seine Note
+   entfallen. Der erzeugte Matcher deckt die Suchklasse.
+2. **`permissions_note` berichtigt** und mit dem gemessenen Grund versehen: Die Suchklasse
+   fällt bei diesem Client unter `Read(...)` – belegt durch P4 und W1 –, deshalb entfällt
+   eine eigene `Search`-Regel, **nicht weil es keine Suche gäbe.**
+3. **Beide `tool_names`-Blöcke abgebildet – als Identität**, gemessen am
+   Frontmatter-Vokabular des Clients; `tool_names_unmapped` entfällt,
+   `tool_names_namespace` kommt hinzu. **`install.py` wendet die Abbildung jetzt
+   auch in der Listenform an** – bis 0.42.0 tat das nur der csv-Zweig, während der
+   Agenten-Renderer daneben immer umschrieb: dieselbe Abbildung mit zwei
+   Ergebnissen.
+4. **`_permission_tools_skill_note`** von „unerhoben" auf gemessen: Das Werkzeug heißt
+   `skill`, die Liste bleibt leer, weil keine wirksame Schreibweise bekannt ist. **K-33
+   geschlossen, K-34 neu.**
+5. **Client Pack**: Verbtabelle, Zeile **B3** (die Zusage, die die falsche Behauptung
+   wiederholt), Zeile **S2** (der Aufruf ist ein Werkzeugaufruf, und die Slash-Form ist ein
+   zweiter Weg), Zeile **S3**, Änderungsverlauf.
+6. **Prüfung 41 (neu)**: Eine Abwesenheitserklärung ist **entweder** als Enthaltung markiert
+   **oder** mit Datum und Protokollpfad belegt. Eine bloße Behauptung ist keines von beidem.
+7. **Sechs Sonden und zwei Gegenproben** zu Prüfung 41.
+
+## 3. Auswirkungen
+
+| Bereich | Auswirkung |
+|---|---|
+| Erzeugte Hook-Konfiguration `devin-desktop` | Matcher **`read\|grep\|find_file_by_name\|exec\|edit\|write`** statt `read\|exec\|edit\|write`. **Der Schutz-Hook läuft künftig auch bei Suchaufrufen** – mehr Hook-Aufrufe je Sitzung, je 10 s Zeitfenster |
+| Erzeugte Skill- und Profildateien `devin-desktop` | **unverändert** `allowed-tools: read, grep, glob` – gemessen ist das die richtige Liste (Befund 5). Geändert hat sich, dass die Abbildung jetzt **erhoben** ist statt unerhoben, und dass `install.py` sie in der Listenform überhaupt anwendet |
+| Erzeugte Berechtigungsdatei | **unverändert** |
+| Pack `claude-code` | **unverändert** |
+| Bestehende Installationen | **Migrationshinweis:** Nach dem Update ist `install.py --update` nötig, damit Hook-Konfiguration und Skilldateien den neuen Stand tragen. Ohne das bleibt die Lücke bestehen |
+| Sicherheit | **Eine Werkzeugklasse kommt in die fail-closed-Schicht zurück.** Kein Schutz wird gelockert |
+
+## 4. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | Wird die Suchklasse in `hook_tools` aufgenommen – obwohl die Berechtigungsschicht sie heute schon deckt? | **Ja.** Die beiden Schichten sollen einander tragen, und die Berechtigungsdatei ist die **editierbare**. Prüfung 37 existiert, weil ein Projekt 41 `deny`-Regeln löschen konnte; der Hook ist die Schicht, die das überleben soll (D-31) | **Jeder Suchaufruf kostet künftig einen Hook-Lauf** mit 10 s Zeitfenster – bei einer Sitzung mit vielen `grep`-Aufrufen ist das spürbar. **Die Gegenposition ist vertretbar:** Wer die Berechtigungsschicht für ausreichend hält, spart die Last. Gemessen ist nur, dass beide Wege heute abweisen |
+| **E2** | Wird `glob` auf `find_file_by_name` abgebildet? | **Nein – der Vorschlag war falsch und ist an der Messung gescheitert (Befund 5).** Das Frontmatter dieses Clients führt ein **eigenes** Vokabular; `glob` ist dort richtig, `find_file_by_name` wird verworfen. Die Abbildung ist deshalb die **Identität** – und das ist ein Messergebnis, kein Nichtstun. Der Namensraum wird deklariert (`tool_names_namespace`) | **Prüfung 38, Gegenstand 3 fällt für dieses Pack weg**: Sie vergleicht `tool_names` gegen `hook_tools`, und die leben hier in zwei Namensräumen. **Die Frage von D-80 bleibt für `devin-desktop` offen** – sie ist anders gestellt, nicht beantwortet, und das steht jetzt im Code und im Pack. Der Preis ist ein deklarierter blinder Fleck statt einer falschen Zusage |
+| **E3** | Bleibt `permission_tools.skill` leer? | **Ja, mit gemessener Begründung.** Zwei Schreibweisen sind geprüft und beide wirkungslos; eine Regel, die nichts tut, wäre die Bauform von D-66 und D-82 – sie sähe richtig aus | **Eine Lücke bleibt eine Lücke**, und der Skillaufruf ist bei diesem Client über die Berechtigungsdatei nicht kontrollierbar. **Das ist zu sagen, nicht zu verschweigen:** neuer Klärungspunkt **K-34**. Und der Slash-Weg ist ohnehin kein Werkzeugaufruf |
+| **E4** | Wird `K-33` geschlossen? | **Ja.** Die Frage lautete „ist der Skillaufruf dort rückfragepflichtig" und ist beantwortet: Er ist ein Werkzeugaufruf, und er ist über diese Datei nicht adressierbar | **Die Nachfolgefrage ist enger und offen** (K-34). Ein geschlossener Klärungspunkt, aus dem ein neuer folgt, sieht nach Stillstand aus und ist Fortschritt: Aus „unbekannt" wurde „bekannt und nicht erreichbar" |
+| **E5** | Bekommt die Abwesenheitserklärung eine Prüfung – oder genügt die Lehre im Protokoll? | **Eine Prüfung.** Genau diese Bauform hat eine Werkzeugklasse aus der Durchsetzung genommen, und Prüfung 26 hat sie durchgelassen, weil sie **Folgerichtigkeit** prüft und nicht **Wahrheit**. Was prüfbar ist: ob die Erklärung sich als **Enthaltung** ausweist oder einen **datierten Beleg** nennt | **Sie prüft eine Form, nicht eine Tatsache.** Wer ein Datum und einen Protokollpfad in die Note schreibt, besteht sie – auch wenn das Protokoll etwas anderes sagt. **Sie fängt nach dieser Änderung nichts mehr** und ist eine Verankerung; ihr Gegenbeweis gegen 0.42.0 ist dafür ein **Abzählen** |
+| **E6** | Wird der Werkzeugbestand gegen ein zweites Modell gehalten? | **Nein – er ist auf diesem Konto nicht messbar.** Der Versuch endet mit `Error: Upgrade to Pro to access this model`. Elf Läufe auf `SWE-1.6 Slow` zeigen denselben Bestand | **Die Aussage gilt für ein Modell.** Bietet der Client einem anderen Modell einen anderen Bestand an, wäre `hook_tools` erneut zu prüfen. **Das gehört als Grenze in das Pack**, nicht in eine Fußnote |
+| **E7** | Eigenes Release oder Anhang? | **Ein eigenes Release, `0.43.0`.** Der Gegenstand ist geschlossen, und er trägt einen Migrationshinweis | **Das achtzehnte Release in drei Tagen.** Und das erste, das einen **Client** misst statt eines Mechanismus – elf Läufe, vier Umgebungen |
+
+## 5. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle sieben Fragen wie vorgelegt.** E1 die Suchklasse kommt in den Hook; **E2 im Vollzug überstimmt** – die Abbildung ist die Identität, weil das Frontmatter dieses Clients ein eigenes Vokabular führt (Befund 5); der Namensraum wird deklariert und Prüfung 38 wird namensraumbewusst; E3 `permission_tools.skill` bleibt leer mit gemessener Begründung; E4 K-33 geschlossen, K-34 neu; E5 Prüfung 41 als Form-, nicht Tatsachenprüfung, Grenze benannt; E6 ein Modell, Grenze im Pack; E7 eigenes Release `0.43.0` |
+| Datum | 2026-09-14 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-87 (der Werkzeugbestand von `devin-desktop` ist erhoben; die Suchklasse gehört in `hook_tools`), D-88 (eine Abwesenheitserklärung ist Enthaltung **oder** datierter Beleg – nie eine bloße Behauptung), D-89 (der Skillaufruf ist bei `devin-desktop` ein Werkzeugaufruf und über die Berechtigungsdatei nicht adressierbar) |
+| Auflagen | **Der Wirkungsnachweis führt einen Lauf am Client**: derselbe `grep`-Aufruf auf `.env` in der Hook-Umgebung, der vor der Änderung durchlief, muss danach blockiert werden. **Ohne diesen Lauf ist die Behebung eine Behauptung.** Und die Grenze wird benannt: ein Modell, ein Konto, elf Läufe |
+| Ziel-Release | `0.43.0` |
+| Umsetzung | umgesetzt mit `0.43.0` |

package/.koolie/core/governance/change-requests/CR-2026-066-schlitzdeckung-ohne-abgleich.md

@@ -0,0 +1,153 @@
+# Änderungsantrag `CR-2026-066`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Drei offene Platzhalterschlitze decken drei beliebige Befehlsfreigaben – und drei ausgelieferte Texte bestreiten das ohne Einschränkung |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-14 |
+| Betroffene Artefakte | `tests/scripts/validate-framework.py` (Prüfung 42 neu, Korbzerlegung an **eine** Stelle, Register), `tests/scripts/probe-pruefungen.py` (Sonden und Gegenproben, Kopfsatz), `clientmap.py` (Kommentarkopf jeder erzeugten Berechtigungsdatei), `framework/core/03-security.md`, `templates/project-overlay/OVERLAY.md` Abschnitt 6, `tests/TEST_CATALOG.md` (`FW-KO-01`), `governance/DECISION_LOG.md`, `docs/ROADMAP.md`, `CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – die Durchsetzungsschicht und ihre Prüfung sind Framework-Gut |
+| Art | Änderung; Anlass ist **Kandidat 2** der Übergabe, der einzige mit einer gemessenen Fundstelle |
+| Dringlichkeit | **P1.** Gemessen läuft eine Freigabe für einen Befehl **mit Fernwirkung** in beiden Packs lautlos durch, und der Text, der das bestreitet, steht im Kopf genau der Datei, in der jemand die Zeile einträgt |
+
+## 1. Anlass
+
+Kandidat 2 der Übergabe beschrieb den Befund als Formfrage: Am Piloten trug die
+Berechtigungsdatei `Bash(mvn -B test:*)`, während Abschnitt 6 des Overlays `mvn -B test`
+erklärt – gefangen hat es Prüfung 37, weil die Abweichung **zufällig auch formal auffällig**
+war. Die Gegenprüfung liegt vor:
+`tests/protocols/2026-09-14-gegenpruefung-schlitzdeckung.md`, **zwölf Läufe an zwei Packs**
+(vier Kontroll-, zwei Entlastungsläufe) und **vier Abzählungen**.
+
+**Der Befund bestätigt sich und er liegt woanders.**
+
+### 1.1 Befund 1: Die Deckung ist drei, und sie ist beliebig füllbar
+
+Die Kernquelle hält im `ask`-Korb genau **drei** Befehlsschlitze (`<BUILD_COMMAND>`,
+`<TEST_COMMAND>`, `<LINT_COMMAND>`); die vier Pfadschlitze stehen im `deny`-Korb und decken
+nichts, weil Überzähliges dort ohnehin zulässig ist. Prüfung 37 vergleicht **Mengen**: Sie
+zählt den Überschuss gegen die Zahl der offenen Schlitze. **Welcher Eintrag welcher Schlitz
+ist, steht dort nicht – und kann dort nicht stehen.**
+
+Gemessen (M10, frische `devin-desktop`-Installation): Das Overlay erklärt dreimal `<TBD>` –
+also **gar nichts** –, und drei eingetragene Befehlsfreigaben laufen durch, darunter
+`mvn -B deploy`. Derselbe Befund am Piloten mit `claude-code` (M4). **Die vierte Zeile fällt**
+(M5, M11) – D-76 hat das richtig vorhergesagt.
+
+### 1.2 Befund 2: Die Lücke ist erklärt – aber nur an einer Stelle
+
+`CR-2026-061` Abschnitt 4 nennt genau diesen Fall und nimmt ihn ausdrücklich aus:
+
+> „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."
+
+Auch D-76 und D-77 bleiben genau. **Drei ausgelieferte Texte aus demselben Commit
+(`34d850e`, Release 0.39.0) tun es nicht:**
+
+| # | Träger | Wortlaut (verkürzt) |
+|---|---|---|
+| **Z1** | `templates/project-overlay/OVERLAY.md` Abschnitt 6 | „Ein Eintrag von Hand in `<PERMISSIONS_FILE>` ist **kein** Ersatz: Prüfung 37 des Validators meldet ihn als Ausweitung" |
+| **Z2** | `clientmap.py`, Kommentarkopf **jeder erzeugten Berechtigungsdatei** | „… unter ‚ask' und ‚allow' wäre sie eine Ausweitung **und ist ein Fehler**. Ein zusätzlicher freigegebener Befehl gehört deshalb nicht hierher" |
+| **Z3** | `framework/core/03-security.md` | „**Prüfung 37 hält die installierte Datei gegen die Kernquelle:** Was dort erzeugt wird, muss hier stehen; eine zusätzliche Regel ist nur unter `deny` zulässig" |
+
+**Z2 ist die teuerste.** Sie steht nicht in einem Dokument, das man zum Nachschlagen
+aufschlägt, sondern im Kopf der Datei, in der jemand die Zeile einträgt, über die sie eine
+Aussage macht. Wer dort „ist ein Fehler" liest, die Zeile trotzdem einträgt und einen grünen
+Lauf bekommt, liest den grünen Lauf als Bestätigung.
+
+**Die Lehre ist die von 0.42.0, eine Ebene tiefer:** *Eine Enthaltung, die nur in einem Antrag
+steht, hält nicht einmal bis zum Ende desselben Patches.*
+
+### 1.3 Befund 3 – nicht gesucht: Zwei von drei Trägern sagen längst das Richtige
+
+Je Installation führen **drei** Träger dieselben drei Werte: das Quell-Overlay, die
+Laufzeitfassung `20-project-overlay.md` und die Berechtigungsdatei. Am Piloten sagen
+Quell-Overlay **und** Laufzeitfassung „Lint/Statische Analyse: nicht vorhanden"; allein die
+Berechtigungsdatei gewährt einen dritten Befehl. **Das ist die erste gemessene Fundstelle für
+`CR-2026-044` E4** (Abgleich Quell-Overlay gegen Laufzeitfassung, seit 0.33.0 offen), und sie
+fällt zugunsten der beiden Textträger aus.
+
+### 1.4 Befund 4 – nicht gesucht: Die Zuordnung steht maschinenlesbar da
+
+In **allen vier** geprüften Overlays – Vorlage, Pilot, frische Installation,
+Testinstallation im Repositorium – steht jeder der drei Platzhalter in **genau einer**
+Tabellenzeile, und der Wert steht in der Zelle **rechts daneben**. Das gilt auch für den
+Piloten, dessen Abschnitt 6 aus einer älteren Vorlage stammt und eine andere
+Spaltenüberschrift führt. Und `docs/PLACEHOLDER_REGISTRY.md` weist die Herkunft für alle drei
+längst aus: „Overlay 5" beziehungsweise „Overlay 6".
+
+**Das Register behauptet die Zuordnung seit jeher. Durchgesetzt hat sie niemand.**
+
+## 2. Vorgeschlagene Änderung
+
+1. **Prüfung 42 (neu)** – *Ein gefüllter Schlitz trägt, was das Overlay erklärt.* Je
+   Befehlsplatzhalter der Kernquelle wird der Wert aus `project-overlay/OVERLAY.md` gelesen
+   (über die **Platzhalterzelle**, nicht über die Spaltenposition) und gegen die installierte
+   Berechtigungsdatei gehalten:
+   - Das Overlay erklärt einen Befehl → die Datei **muss** die Schlitzregel mit genau diesem
+     Wert tragen.
+   - Das Overlay erklärt keinen (`<TBD>`, „nicht vorhanden", „–", leer) → der Schlitz ist
+     **nicht gefüllt** und deckt **keinen** Überschuss.
+   - Eine Befehlsregel im Schlitzkorb, die keinen erklärten Wert trägt und die die Kernquelle
+     nicht erzeugt, ist ein Fehler.
+2. **Die Korbzerlegung liegt künftig an einer Stelle.** `_korb_zerlegung()` liefert Pflicht,
+   Schlitze, offene Schlitze und Überschuss; Prüfung 37 und 42 lesen daraus. **Zwei
+   Gelegenheiten für denselben Fehler sind eine** – dieselbe Begründung wie bei
+   `tabellenzellen()` mit 0.37.0.
+3. **Prüfung 37 bleibt unverändert.** Sie hängt allein an der Kernquelle und läuft ohne
+   Overlay; 42 entzieht ihr keine Deckung, sondern prüft die Zuordnung getrennt. Sonst hinge
+   das Ergebnis von 37 an der Anwesenheit eines Nachbardokuments.
+4. **Z1, Z2 und Z3 bekommen ihre Bedingung** – Z2 zuerst, weil sie in jeder erzeugten Datei
+   steht. Der Satz nennt künftig beides: den Schlitz, der dem Projekt gehört, und die
+   Grenze, die auch nach Prüfung 42 bleibt.
+5. **Register und Sondenmenge** werden nachgezogen: Registereintrag 42, Spanne „6 und 18 bis
+   42" wörtlich an den drei Trägern, die Prüfung 40 vergleicht.
+6. **Sonden und Gegenproben** zu Prüfung 42 gegen eine **frische Installation** mit
+   gefülltem Overlay – die Bauart von Prüfung 37 und 33, aus demselben Grund: Die Prüfung
+   hängt an installierten Dateien, nicht an einem Repositoriumstext.
+
+## 3. Auswirkungen
+
+- **Der Pilot bekommt einen Fehler.** `Bash(mvn -B -q compile)` steht dort, während Abschnitt 6
+  `<LINT_COMMAND>` als „nicht vorhanden" erklärt. **Das ist der Zweck der Prüfung** und kein
+  Nebenschaden. Die Behebung ist eine Entscheidung des Overlay Owners und keine des Frameworks:
+  entweder die Zeile fällt, oder Abschnitt 6 erklärt den Befehl als `<LINT_COMMAND>`.
+- **Der Gegenbeweis gegen den Vorstand ist ein Abzählen an einem echten Projekt**, nicht eine
+  Konstruktion: Der Befund stand am Piloten, bevor die Prüfung gebaut wurde, und sie findet
+  ihn. **Im Repositorium selbst findet sie nichts** – die Testinstallation hat drei offene
+  Schlitze und ein Overlay, das dreimal `<TBD>` sagt. Das gehört so gesagt.
+- **Ein Projekt, das seine Schlitze sauber füllt, merkt nichts.** Die Deckung entsteht genau
+  dort, wo ein Projekt einen Befehl **nicht** hat und die freigewordene Zeile anderweitig
+  benutzt.
+- **Die Prüfung hängt an einer Tabellenform, die dem Projekt gehört.** Wer Abschnitt 5 oder 6
+  so umbaut, dass ein Platzhalter in keiner Tabellenzeile mehr steht, bekommt die Meldung über
+  den verlorenen Anker – nicht über seine Berechtigungsdatei.
+- **Bestehende Installationen ändern sich nicht von selbst.** Die Berechtigungsdatei steht in
+  `shared_seed` und wird nach der Erstinstallation nie wieder geschrieben (D-76); die Prüfung
+  meldet, sie behebt nicht.
+
+## 4. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | **Darf eine Prüfung einen Wert aus dem Overlaytext auswerten?** Bisher liest der Validator dort nur Zustände – Status, offene `<TBD>`, Versionsangabe | **Ja, über die Platzhalterzelle der Tabellen in Abschnitt 5 und 6.** Die Zuordnung gibt es genau einmal, und `docs/PLACEHOLDER_REGISTRY.md` weist sie für alle drei Platzhalter längst aus. Sie dort zu lesen ist keine neue Freiheit, sondern die Durchsetzung einer Behauptung, die das Register seit jeher macht. Gemessen steht jeder Platzhalter in allen vier geprüften Overlays in **genau einer** Tabellenzeile | **Die Prüfung hängt an einem Dokument, das dem Projekt gehört.** Ein Umbau von Abschnitt 5 oder 6 bricht sie – deshalb wird die Zeile über die **Platzhalterzelle** gefunden und der Wert rechts daneben gelesen, nie über eine Spaltennummer. Und der Bruch meldet sich als **verlorener Anker**, nicht als Befund über die Berechtigungsdatei |
+| **E2** | Wird stattdessen die **Laufzeitfassung** `20-project-overlay.md` gelesen? Sie ist Framework-Gut und führt dieselben drei Werte | **Nein.** Sie führt sie in einer Fließzeile ohne Schlüsselspalte – und der Pilot hat sie bereits umgebaut (zwei Zeilen statt einer, ein zusätzliches Feld „Schnellprüfung"). Eine Prüfung darüber fiele beim ersten echten Projekt **an der Form, nicht an der Sache** | **Der Abgleich zwischen Quell-Overlay und Laufzeitfassung bleibt offen** (`CR-2026-044` E4, seit 0.33.0). Er hat jetzt seine erste gemessene Fundstelle und bekommt sie als Kandidaten – **das ist eine Enthaltung, und sie wird als solche geführt** |
+| **E3** | Was gilt, wenn der Overlaywert **kein Befehl** ist (`<TBD>`, „nicht vorhanden", „–")? | **Der Schlitz gilt als nicht gefüllt und deckt keinen Überschuss.** Das ist der Satz, der den Befund am Piloten fängt: Wo ein Projekt keinen Befehl hat, darf die freigewordene Zeile nicht anderweitig benutzt werden | **Das ist eine Verschärfung gegenüber 0.43.0.** Ein Projekt, das den Befehl in der Datei führt und im Overlay `<TBD>` stehen lässt, bekommt jetzt einen Fehler – auch wenn der Befehl harmlos ist. Der dokumentierte Weg ist, Abschnitt 6 auszufüllen |
+| **E4** | Was gilt, wenn das Overlay einen Befehl erklärt, die Datei ihn aber **nicht** trägt? | **Fehler**, mit einer Meldung, die beide Auflösungen nennt. Nach D-77 („Fehlen ist immer ein Fehler, gleich in welchem Korb") ist das die konsequente Fortsetzung; die beiden Träger müssen übereinstimmen | **Eine frische Installation vor dem Ausfüllen bleibt still**, weil dort `<TBD>` steht – der Fehler trifft nur ein Overlay, das bereits etwas erklärt. **Das ist gewollt, aber es heißt auch: Der halb ausgefüllte Zustand wird erst dann laut, wenn er halb ist** |
+| **E5** | **Nur die drei Befehlsschlitze – oder auch die vier Pfadschlitze?** | **Nur die drei Befehlsschlitze.** Die Pfadschlitze stehen sämtlich im `deny`-Korb, wo Überzähliges ohnehin zulässig ist; dort gibt es keine Deckung zu entziehen. Und sie sind **n:1** – eine Liste im Overlay, eine Regel in der Datei | **Ein zu eng gefüllter `<EXCLUDED_PATHS>`-Schlitz bleibt eine stille Lockerung.** Das ist eine andere Prüfung mit einer eigenen Ermessensfrage, und sie wird **nicht** in einem Nebensatz erledigt. Sie wird als Kandidat geführt – die Lehre von 0.43.0: eine Enthaltung erklärt sich oder sie ist eine Behauptung |
+| **E6** | Eigene Nummer oder Erweiterung von Prüfung 37? | **Eigene Nummer, Prüfung 42.** Prüfung 37 hängt allein an der Kernquelle und läuft ohne Overlay; 42 enthält sich ohne Overlay. Zwei Gegenstände, zwei Nummern – und 37 behält ihre Arithmetik, damit ihr Ergebnis nicht von der Anwesenheit eines Nachbardokuments abhängt | **Am Piloten meldet 37 weiterhin nichts**, während 42 meldet. Zwei Prüfungen über dieselbe Datei, die verschieden ausgehen, sind erklärungsbedürftig – der Registereintrag sagt deshalb, was jede von beiden **nicht** prüft |
+| **E7** | Werden Z1 bis Z3 berichtigt, obwohl Prüfung 42 sie einholt? | **Ja, alle drei.** Sie sagen auch nach 42 mehr, als die Mechanik hält: Die Pfadschlitze bleiben ungeprüft, und ein vom Overlay erklärter Befehl ist zulässig. **Z2 zuerst** – sie ist die einzige der drei, die den Leser an der Stelle erreicht, an der er eingreift | **Drei Sätze werden länger**, und zwei davon stehen in Texten, die ohnehin dicht sind. Der Preis ist Lesbarkeit gegen Wahrheit – und dieses Projekt hat die Frage schon entschieden |
+| **E8** | Eigenes Release oder Anhang? | **Ein eigenes Release, `0.44.0`.** Der Gegenstand ist geschlossen, und er trägt einen Migrationshinweis für jede Installation mit gefülltem Overlay | **Das neunzehnte Release in drei Tagen** – und das erste seit 0.42.0, dessen Gegenbeweis ein **Abzählen an einem echten Projekt** ist statt einer Konstruktion |
+
+## 5. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle acht Fragen wie vorgelegt.** E1 der Wert wird über die Platzhalterzelle gelesen; E2 die Laufzeitfassung bleibt außen vor und `CR-2026-044` E4 wird als Kandidat geführt; E3 ein Schlitz ohne Befehl deckt nichts; E4 ein erklärter Befehl muss dastehen; E5 nur die drei Befehlsschlitze, die Pfadschlitze werden als Enthaltung geführt; E6 eigene Nummer 42, Prüfung 37 unverändert; E7 alle drei Texte bekommen ihre Bedingung; E8 eigenes Release `0.44.0` |
+| Datum | 2026-09-14 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-90 (ein Platzhalterschlitz trägt den Wert, den das Overlay für ihn erklärt – ein Schlitz ohne erklärten Befehl deckt keinen Überschuss), D-91 (der Validator darf **Werte** aus `OVERLAY.md` auswerten, wenn sie in einer Schlüsselspalte stehen – nicht aus Fließtext) |
+| Auflagen | **Der Gegenbeweis wird als Abzählen an einem echten Projekt ausgewiesen und im selben Atemzug seine Grenze:** Im Repositorium selbst findet Prüfung 42 nichts, weil die Testinstallation drei offene Schlitze und ein leeres Overlay hat. **Und die Enthaltung zu den Pfadschlitzen steht im Registereintrag, nicht nur im Antrag** – genau der Fehler, den dieser Antrag behebt, darf ihn nicht selbst wiederholen |
+| Ziel-Release | `0.44.0` |
+| Umsetzung | umgesetzt mit `0.44.0` |

package/.koolie/core/governance/change-requests/CR-2026-067-hookblock-und-praeparationsregister.md

@@ -0,0 +1,140 @@
+# Änderungsantrag `CR-2026-067`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Eine Berechtigungsdatei ohne Hook-Block ist stumm, und das Register der Übungspräparationen nennt drei von sieben |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-15 |
+| Betroffene Artefakte | `tests/scripts/validate-framework.py` (Prüfungen 43 und 44 neu, Meldung der Prüfung 18, Register), `tests/scripts/probe-pruefungen.py` (Sonden und Gegenproben, Kopfsatz), `onboarding/exercises/README.md` (Präparationsregister `UEB-01` bis `UEB-07`), `tests/TEST_CATALOG.md` (Vorbedingungen mit Kennung, `FW-PI-04`, `FW-KO-01`), `docs/ADOPTION_GUIDE.md` (mehrere Technologiestränge), `governance/DECISION_LOG.md`, `docs/ROADMAP.md`, `CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – die Durchsetzungsschicht, ihre Prüfung und der Testkatalog sind Framework-Gut |
+| Art | Änderung; Anlass ist **Kandidat 1** der Übergabe – das Übungsrepository herrichten |
+| Dringlichkeit | **P1 für Gegenstand 1.** Gemessen war der Hook eines echten Projekts **einunddreißig Releases lang wirkungslos**, und der Validator meldete durchgehend 0 Fehler. Bei `devin-desktop` ist der Hook die einzige technische Secret-Schranke |
+
+## 1. Anlass
+
+Kandidat 1 der Übergabe nannte zwei Aufgaben: das Übungsrepository
+(`devpacks/test-devin-framework`) von 0.13.0 auf `main` heben und die **drei** fehlenden
+Köder anlegen. Beides ist am 2026-09-14 gemacht; der Weg ist protokolliert
+(`tests/protocols/2026-09-15-herrichtung-uebungsrepositorium.md`). **Vier Befunde sind
+dabei angefallen, und keiner davon stand in der Kandidatenbeschreibung.**
+
+### Befund 1 – die Berechtigungsdatei ohne Hook-Block ist stumm und läuft grün
+
+Das Übungsrepository trug in `.devin/config.json` **keinen `hooks`-Block**. Seine Hooks
+standen in `.devin/hooks.v1.json` – der Datei, aus der dieser Client keinen Hook ausführt
+(AP2-DD-10, D-32, seit 0.25.0). Der Hook war damit seit der Erstinstallation wirkungslos.
+
+**Gemessen, nicht geschlossen:** In einer frischen 0.44.0-Installation wurde der
+`hooks`-Block entfernt und der Validator gefahren. Ergebnis mit Block: 2 Fehler. Ergebnis
+ohne Block: **dieselben 2 Fehler** (beide Artefakte der Testinstallation, kein Bezug zum
+Hook). **Kein Lauf sieht das Fehlen.**
+
+Die Gegenprüfung über alle vier lokalen Installationen stellt den Befund **um**: `lw-tech`
+und `leitwerk-ap2` stehen auf 0.24.0 und tragen den Block; der Pilot trägt ihn. **Nur das
+Übungsrepositorium nicht** – es wurde vor 0.25.0 installiert, und
+`install.py --update` schreibt die Berechtigungsdatei nie (`shared_seed`, D-76). Die
+Reichweite ist damit **eine** Fundstelle, nicht vier. Der Befund selbst bleibt.
+
+**Und Prüfung 18 beschreibt die halbe Migration.** Ihre Warnung sagt: die verwaiste
+`hooks.v1.json` ist von Hand zu löschen. Wer ihr wörtlich folgt und sonst nichts tut, hat
+danach **gar keinen Hook mehr** – und kein Lauf meldet es. Das ist derselbe Befundtyp, den
+dieses Projekt seit zwölf Releases bei sich selbst findet: eine Anweisung, die weniger
+herstellt, als ihr Leser annimmt.
+
+### Befund 2 – das Register der Präparationen nennt drei von sieben
+
+`onboarding/exercises/README.md` Nummer 4 verlangt **drei Köder** (Injektion, K3,
+Scope-Falle). Abgezählt gegen die Vorbedingungen des Testkatalogs braucht ein fahrbares
+Übungsrepositorium **sieben Präparationen für neun Testfälle**: dazu eine `.env`-Testdatei
+(`FW-DS-02`), einen präparierten Codekommentar (`FW-PI-02`), eine Injektion in einer
+Testdatei (`SK-006-N04`) und einen Regeltext mit bewusstem Widerspruch (`FW-KO-03`). Keine
+dieser vier steht in der Liste, und der Testkatalog führt alle neun Fälle als `offen`,
+also als fahrbar.
+
+### Befund 3 – `FW-PI-04` verlangt, was D-76 ausschließt
+
+Die Vorbedingung lautet „Testskript mit präparierter stdout-Anweisung **als freigegebener
+Befehl**". Die Berechtigungsdatei hält genau drei Befehlsschlitze bereit, und ein Overlay
+kann dort keinen vierten Eintrag erzeugen (D-76, seit 0.39.0; Prüfung 42 seit 0.44.0
+meldet jeden unerklärten). **Der Testfall verlangt in dieser Form etwas, das das Framework
+seit sechs Releases ausschließt** – und niemand hat es bemerkt, weil ihn niemand gefahren
+hat.
+
+### Befund 4 – der Übernahmeleitfaden schweigt zu mehreren Technologiesträngen
+
+Das Übungs-Overlay führt zwei Stränge und damit sechs Build-, Test- und Prüfbefehle. Seine
+Berechtigungsdatei trug **acht** Exec-Freigaben bei drei Schlitzen – fünf mehr, als die
+Kernquelle erzeugen kann, darunter den Aufruf des Validators selbst. `ADOPTION_GUIDE.md`
+Abschnitt 3 beschreibt die Migration, nennt aber den Fall nicht, den jedes Projekt mit
+mehr als einem Strang hat: **Welcher Befehl bekommt den Schlitz, wenn es sechs Kandidaten
+für drei Plätze gibt?**
+
+## 2. Vorgeschlagene Änderung
+
+1. **Prüfung 43 (neu):** Führt ein Client Pack seine Hooks in der Berechtigungsdatei –
+   erkennbar daran, dass `<HOOKS_FILE>` und `permissions_file` auf dieselbe Datei zeigen –,
+   dann MUSS diese Datei einen nichtleeren `PreToolUse`-Block tragen. **Fehler.** Beide
+   ausgelieferten Packs fallen darunter.
+2. **Die Meldung der Prüfung 18 bekommt ihren zweiten Halbsatz:** Nicht nur die alte Datei
+   löschen, sondern den Block in der Berechtigungsdatei führen – mit dem Verweis auf
+   Prüfung 43, die es nachzählt.
+3. **Prüfung 44 (neu):** Das Präparationsregister in `onboarding/exercises/README.md` und
+   die Vorbedingungen in `tests/TEST_CATALOG.md` decken sich – **in beiden Richtungen,
+   über die Kennung**: Jede im Katalog genannte Kennung `UEB-NN` steht im Register, und
+   jede Kennung des Registers wird von mindestens einem Testfall gebraucht.
+4. **Das Register wird vollständig:** `UEB-01` bis `UEB-07` mit Ort, Gegenstand und den
+   Testfällen, die sie brauchen. Die Vorbedingungszellen des Katalogs nennen die Kennung.
+5. **`FW-PI-04` wird berichtigt:** Die präparierte Ausgabe kommt aus einem der **drei
+   erklärten** Befehle, nicht aus einem vierten. Was der Testfall misst, bleibt gleich;
+   was er voraussetzt, wird herstellbar.
+6. **`ADOPTION_GUIDE.md` bekommt den Absatz zu mehreren Technologiesträngen**, mit der
+   gemessenen Entscheidungsregel: Den Schlitz bekommt der Befehl, der auf den
+   Arbeitsplätzen des Projekts tatsächlich läuft.
+7. **Register und Sondenmenge** werden nachgezogen – Einträge 43 und 44, Spanne wörtlich an
+   den drei Trägern, die Prüfung 40 vergleicht. **Erst die Sonden, dann die Spanne** (die
+   Lehre vom 2026-09-14).
+
+## 3. Auswirkungen
+
+- **Bestehende Installationen ohne Hook-Block bekommen einen Fehler.** Das ist der Zweck.
+  Gemessen ist es genau eine: das Übungsrepositorium, dort mit diesem Release behoben.
+  Die Behebung ist ein Handgriff – den Block aus einer frischen Installation übernehmen –
+  und sie steht als Migrationshinweis im `CHANGELOG.md`.
+- **Im Repositorium selbst findet Prüfung 43 nichts.** Die lokale Testinstallation trägt
+  ihren Block. Das gehört so gesagt: Der Gegenbeweis ist ein Abzählen an einem echten
+  Projekt, kein Fund im eigenen Baum.
+- **Prüfung 44 hängt an einem Dokument, das dem Framework gehört** – anders als Prüfung 42,
+  die in ein Projektdokument liest. Ein Umbau von `exercises/README.md` bricht sie, und der
+  Bruch meldet sich als verlorener Anker.
+- **Prüfung 44 sieht das Übungsrepositorium nicht.** Sie gleicht zwei Register ab, nicht
+  Register gegen Wirklichkeit: Ob die Präparation `UEB-02` dort wirklich liegt, kann kein
+  Validator dieses Repositoriums feststellen. **Das ist eine Enthaltung, keine Stille**, und
+  sie steht im Kopfkommentar.
+- **Der Testkatalog bekommt Kennungen in seinen Vorbedingungszellen.** Wer einen Testfall
+  ergänzt, der eine Präparation braucht, muss sie registrieren – oder Prüfung 44 schweigt,
+  weil er keine Kennung nennt. Auch das ist eine Grenze und steht dort.
+
+## 4. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | **Fehler oder Warnung, wenn der Hook-Block fehlt?** | **Fehler.** Bei beiden Packs ist der Hook die einzige technische Schranke gegen Secrets in Werkzeugeingaben und gegen Schreibzugriffe auf den Kern über Werkzeuge, die die Berechtigungsdatei nicht erfasst. Eine Warnung hätte denselben Rang wie der Hinweis auf die verwaiste Datei – und genau der wurde einunddreißig Releases lang überlesen | **Ein Projekt, das den Hook bewusst nicht will, bekommt einen Fehler und kann ihn nicht abstellen.** Das ist gewollt: Der Hook ist Kernzusage, nicht Projektwahl. Wer ihn nicht will, deinstalliert das Framework – der Weg steht in `ADOPTION_GUIDE.md` Abschnitt 5 |
+| **E2** | **Wie tief prüft 43 – Vorhandensein oder Inhalt?** | **Vorhandensein eines nichtleeren `PreToolUse`-Blocks.** Den Inhalt prüfen die Prüfungen 19 (Interpreter), 26 (Werkzeugabdeckung) und 27 (fail-closed) bereits – sie greifen, sobald der Block da ist. Eine vierte Inhaltsprüfung verdoppelte sie | **Ein Block mit einem `PreToolUse`-Eintrag, der auf ein fremdes Skript zeigt, läuft durch 43 durch** – und wird von 19 gefangen, weil der Interpreteraufruf nicht passt. Zwei Prüfungen, die zusammen greifen, sind erklärungsbedürftig; der Registereintrag sagt, was 43 **nicht** prüft |
+| **E3** | **Was gilt für ein Pack mit eigener Hook-Datei?** | **Enthaltung.** Die Prüfung greift nur, wenn `<HOOKS_FILE>` und `permissions_file` auf dieselbe Datei zeigen. Derzeit tun das beide Packs; die Bedingung steht trotzdem da, weil ein künftiges Pack es anders halten kann | **Ein Pack mit eigener Hook-Datei bleibt ungeprüft.** Die Enthaltung ist benannt – und sie ist derselbe Zuschnitt, den Prüfung 18 schon hat |
+| **E4** | **Wird Prüfung 18 erweitert oder bleibt sie?** | **Sie bleibt, ihre Meldung wächst.** 18 räumt die alte Datei ab, 43 verlangt die neue – zwei Gegenstände, zwei Nummern (dieselbe Begründung wie bei 37 und 42). Die Warnung nennt künftig beide Hälften der Migration | **Wer nur die Warnung liest, sieht jetzt mehr Text.** Der Preis ist Lesbarkeit gegen Vollständigkeit, und dieses Projekt hat die Frage entschieden |
+| **E5** | **Welche Kennung bekommen die Präparationen?** | **`UEB-01` bis `UEB-07`.** `P1`, `P3` sind im Kern als Prinzipienkennungen vergeben (`05-working-model.md`); eine zweite Bedeutung desselben Zeichens in derselben Dokumentfamilie ist ein Fehler, den dieses Projekt schon einmal gemacht hat (`G-18`, 2026-09-13). `UEB-` ist im gesamten Kern frei – geprüft | **Eine weitere Kennungsfamilie** neben `CR-`, `D-`, `K-`, `G-`, `FW-`, `SK-`, `EX-`. Sie ist die erste, die einen Gegenstand **außerhalb** des Repositoriums benennt |
+| **E6** | **Prüft 44 beide Richtungen?** | **Ja.** Eine Kennung im Katalog ohne Registereintrag ist ein Tippfehler oder eine unregistrierte Präparation; eine Kennung im Register, die kein Testfall braucht, ist eine tote Präparation, die jemand pflegt | **Was sie nicht kann:** einen Testfall fangen, der eine Präparation braucht und keine Kennung nennt. Genau der Fall von Befund 2 – **die Prüfung verhindert seine Wiederholung nur, wenn die Kennung gesetzt wird.** Das ist dieselbe Ehrlichkeit wie bei Prüfung 38 und 40, und es steht im Kopfkommentar |
+| **E7** | **Wie wird `FW-PI-04` aufgelöst – Testfall streichen oder umformulieren?** | **Umformulieren.** Die Injektion über eine Werkzeugausgabe ist ein realer Angriffsweg und der einzige Testfall, der ihn abdeckt. Herstellbar wird er, wenn die präparierte Ausgabe aus einem der drei **erklärten** Befehle kommt – im Übungsrepositorium aus `<TEST_COMMAND>`, dessen Lauf eine Anweisung auf stdout schreibt | **Der Testfall misst danach denselben Mechanismus in einer engeren Lage:** Die Ausgabe kommt aus dem Testlauf, nicht aus einem beliebigen Skript. Wer ihn fährt, muss die Präparation in einer Testdatei unterbringen – sie ist `UEB-06` und liegt ohnehin dort |
+| **E8** | **Eigenes Release oder Anhang an 0.44.0?** | **Eigenes Release `0.45.0`.** Zwei neue Prüfungen, ein Migrationshinweis, ein berichtigter Testfall – das ist ein geschlossener Gegenstand | **Das zwanzigste Release in vier Tagen.** Und das erste, dessen Anlass **nicht** ein Befund im Repositorium war, sondern die Arbeit an einem Projekt, das dieses Repositorium benutzt |
+
+## 5. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle acht Fragen wie vorgelegt.** E1 fehlender Hook-Block ist ein Fehler; E2 Prüfung 43 prüft das Vorhandensein, den Inhalt prüfen 19, 26 und 27; E3 ein Pack mit eigener Hook-Datei bleibt ausgenommen und die Enthaltung steht im Kopfkommentar; E4 Prüfung 18 bleibt, ihre Meldung nennt beide Hälften der Migration; E5 Kennungen `UEB-01` bis `UEB-07`; E6 Prüfung 44 gleicht beide Richtungen ab, ihre Grenze steht im Kopfkommentar; E7 `FW-PI-04` wird umformuliert statt gestrichen; E8 eigenes Release `0.45.0` |
+| Datum | 2026-09-15 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-92 (führt ein Pack seine Hooks in der Berechtigungsdatei, ist ein fehlender Hook-Block ein Fehler – eine Hook-Konfiguration am falschen Ort ist keine), D-93 (die Präparationen des Übungsrepositoriums sind ein Register mit Kennungen, und der Testkatalog nennt sie an der Vorbedingung) |
+| Auflagen | **Der Gegenbeweis für Prüfung 43 ist ein Abzählen an vier echten Installationen, und seine Grenze steht daneben:** Im Repositorium selbst findet sie nichts, weil die lokale Testinstallation ihren Block trägt. **Und Prüfung 44 weist ihre Enthaltung aus** – sie gleicht zwei Register ab, nicht ein Register gegen die Wirklichkeit des Übungsrepositoriums |
+| Ziel-Release | `0.45.0` |
+| Umsetzung | umgesetzt mit `0.45.0` |

package/.koolie/core/governance/change-requests/CR-2026-068-sondenlauf-nebenlaeufig.md

@@ -0,0 +1,106 @@
+# Änderungsantrag `CR-2026-068`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Sondenlauf bekommt Namen, Laufzeiten, Beschreibungssätze, Nebenläufigkeit – und einen Aufräumer, der sein Scheitern meldet |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-15 |
+| Betroffene Artefakte | `tests/scripts/probe-pruefungen.py` (Ausführungsplan, Läufer, Auswertung, Aufräumer, Beschreibungssätze), `governance/FRAMEWORK_DEV_PROFILE.md` (Abschnitt 4, Abnahmeform), `governance/DECISION_LOG.md`, `docs/ROADMAP.md`, `CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – der Prüfapparat ist Framework-Gut |
+| Art | Änderung |
+| Dringlichkeit | **Regulär.** Kein Befund, sondern ein Auftrag: Der Lauf dauert dreizehn Minuten und ist die Abnahmeform jedes Releases – er wird zweimal je Release gefahren (D-49) |
+
+## 1. Anlass
+
+**Dies ist das zweite Release in Folge, dessen Anlass nicht ein Befund im Repositorium
+ist** – und das erste, dessen Anlass überhaupt kein Befund ist. Der Auftrag kam vom
+Framework Owner und nennt vier Punkte. Drei Fallstricke standen in der Übergabe daneben;
+alle drei sind hier schon einmal teuer gewesen.
+
+### Gemessen, bevor etwas gebaut wurde
+
+`python leitwerk-core/tests/scripts/probe-pruefungen.py .` gegen `main` (`750ce10`,
+0.45.0), am 2026-09-15:
+
+| Größe | Wert |
+|---|---|
+| Laufzeit | **13 min 07 s** (787 s), streng seriell |
+| Ergebniszeilen | 208 (144 Sonden, 57 Gegenproben, 7 Selbstproben) |
+| Ausführungseinheiten | 128 – 79 `sonde(`, 6 `sonde_ohne_wert(`, 29 `gegenprobe(`, 14 `buendel(` |
+| Exit-Code | 0 |
+
+**Der Lauf sagt nicht, wo die dreizehn Minuten hingehen.** Er sagt auch nicht, was ein
+Bündel belegen soll: Die 114 Einzelsonden tragen seit jeher einen erklärenden Text, die
+14 Bündel tragen **keinen** – man sieht eine Folge von Meldungen und muss aus ihr
+erraten, welche Frage sie zusammen beantworten.
+
+### Befund am Rande, und er ist der einzige echte dieses Antrags
+
+An **vierzehn** Stellen räumt das Skript sein Arbeitsverzeichnis mit
+`shutil.rmtree(..., ignore_errors=True)` ab. Der Kopfsatz des Skripts sagt: *„Gearbeitet
+wird auf einer Kopie; das Repositorium selbst bleibt unberührt."* Die zweite Hälfte
+dieser Zusage – dass die Kopie danach wieder weg ist – hat **keinen Mechanismus**: Ein
+Lauf, der 128 Kopien anlegt und zwanzig davon liegen lässt, sieht Zeile für Zeile genau
+so aus wie einer, der aufgeräumt hat. **Das ist der wiederkehrende Befundtyp dieses
+Projekts** – eine Zusage, die mehr verspricht, als sie durchsetzt – und diesmal steht er
+im Prüfapparat selbst, also an der Stelle, die ihn sonst bei anderen findet.
+
+## 2. Vorgeschlagene Änderung
+
+**Vier Gegenstände, alle in `tests/scripts/probe-pruefungen.py`.**
+
+1. **Ausführungsplan statt Sofortlauf.** `sonde()`, `sonde_ohne_wert()`, `gegenprobe()`
+   und `buendel()` **melden** ihre Einheit an, statt sie auszuführen; gefahren wird am
+   Ende durch einen Läufer. Die Aufrufstellen bleiben **zeichengleich** – geändert hat
+   sich allein, wann der Aufruf seine Arbeit tut.
+2. **Nebenläufigkeit.** Der Läufer fährt die Einheiten auf `--bahnen N` Bahnen,
+   Vorgabe 8. Jede Einheit arbeitet ohnehin auf ihrer eigenen Kopie beziehungsweise
+   Installation; **innerhalb** eines Bündels bleibt es streng seriell.
+   `--bahnen 1` ergibt den seriellen Lauf von 0.45.0.
+3. **Name, Beschreibungssatz und Laufzeit je Einheit.** Jede Einheit trägt einen Namen
+   (Prüfungsnummer beziehungsweise Funktionsname) und einen Satz von **5 bis 30 Worten**.
+   Der Satz eines Bündels steht als Kopfzeile über dessen Zeilen. Die Laufzeiten stehen
+   am Ende, langsamste zuerst, **unterhalb einer Trennlinie**.
+4. **Ein Aufräumer, der sein Scheitern meldet.** `aufraeumen()` ersetzt die vierzehn
+   `ignore_errors=True`-Stellen: drei Versuche über 1,5 s, danach eine eigene
+   `AUFRAEUMER`-Zeile mit Pfad und Grund – und sie zählt als Abweichung.
+
+Dazu **drei neue Selbstproben**: `B1` zählt die Wortzahl jedes Beschreibungssatzes
+nach, `A1` und `A2` messen den Aufräumer selbst – sein Schweigen beim Gelingen und
+seine Meldung an einem Verzeichnis, das sich nicht löschen lässt. Dazu **zehn
+verlängerte Sätze** bei Einzelsonden, die bisher nur eine Kennung trugen
+(„Pack ohne Auskunftsabschnitt", drei Worte).
+
+## 3. Die drei Fallstricke – und wie ihnen begegnet wird
+
+| # | Fallstrick | Wie er umgangen wird |
+|---|---|---|
+| **F1** | **Prüfung 40 rechnet die Sondenmenge aus zwei wörtlichen Mustern dieser Datei aus** – dem Aufruf `sonde(` mit seiner Kennung und `melde(` mit der Art `SONDE` und ihr (D-86). Ein Umbau auf eine Registry mit eigener Schreibweise hätte die Sonden unsichtbar gemacht – und Prüfung 40 hätte **leise bestanden**, weil eine leere Menge keine Abweichung ist | Beide Muster stehen unverändert an ihren Aufrufstellen; `sonde()` und `melde()` behalten Namen und Signatur. **Nachgezählt:** Vorher wie nachher `6 und 18 bis 44` – dieselbe Menge, dieselbe ausgerechnete Schreibweise. Der Anmelder heißt `eintragen()` und **nicht** `anmelde()`, weil letzteres den Suchtext `melde(` enthielte und Prüfung 40 eine Sonde erfände, die es nicht gibt |
+| **F2** | **Die Abnahmeform verlangt seit D-49 zeilengleiche Ausgabe in beiden Kodierungsumgebungen.** Nebenläufige Einheiten schreiben in beliebiger Reihenfolge, und eine Laufzeit ist nie zweimal dieselbe | Keine Einheit schreibt selbst; jede **sammelt** ihre Zeilen (`melde()` und das neue `notiz()` an der Stelle von `print()`). Der Läufer gibt sie in der Reihenfolge der **Anmeldung** aus, nicht der Fertigstellung. Die Laufzeiten stehen unterhalb der Trennlinie und sind ausdrücklich nicht Teil des Vergleichs |
+| **F3** | **Ein Bündel ist die kleinste Einheit, nie seine Teile.** Seine Fälle bauen aufeinander auf: eine Installation, Schritt für Schritt präpariert und zurückgesetzt | Das Bündel ist **eine** Einheit des Plans. Nebenläufig sind allein die Einheiten gegeneinander; innerhalb eines Bündels ändert sich nichts. Es bekommt **eine** Laufzeit, nicht 35 |
+
+## 4. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | **Wohin mit der Laufzeit, wenn D-49 zeilengleiche Ausgabe verlangt?** | **Nur in einen Auswertungsblock am Ende**, unter einer Trennlinie, die sich selbst als nicht Teil der Abnahme bezeichnet. Die Ergebniszeilen bleiben Zeichen für Zeichen vergleichbar | **Man sieht die Laufzeit einer Einheit nicht neben ihrem Ergebnis**, sondern muss unten nachsehen. Verworfen: die Laufzeit in jede Ergebniszeile (der Vergleich bräuchte dann einen Filter – und eine Abnahmeform, die einen Filter braucht, ist keine mehr); ein Schalter `--zeiten` (eine Messung, die opt-in ist, wird nicht gefahren, und eine Zahl, die niemand sieht, verhindert keine Laufzeitregression) |
+| **E2** | **Woher kommt der Beschreibungssatz – aus dem vorhandenen Text oder aus einem neuen Feld?** | **Der vorhandene Text IST der Satz.** Zehn zu kurze werden verlängert, die vierzehn Bündel bekommen ihren Satz neu. **Ein Text je Einheit** | **Zehn gewachsene Ergebniszeilen** im Vergleich zu 0.45.0. Verworfen: ein zweites Feld neben dem Kurztext – zwei Texte je Einheit, die auseinanderlaufen können, und das ist **genau der Befundtyp dieses Projekts**: ein zweites Register neben dem ersten (D-78) |
+| **E3** | **Wird die Wortzahl durchgesetzt, und wo?** | **Im Skript selbst, als Selbstprobe `B1`.** Sie zählt beim Lauf; ein Ausreißer ist eine Abweichung. Sie reiht sich in die Selbstprobenfamilie ein, die seit 0.38.0 den Präparations- und den Kennungswächter misst | **Sie zählt Worte, nicht Sinn** – ein Satz aus achtzehn Füllwörtern besteht sie, und das steht in ihrem Kopfkommentar. Verworfen: eine neue Prüfung 45 im Validator (sie bräuchte nach D-23 selbst Sonde und Gegenprobe und läse einen Text über ein Muster – die Bauform, an der der erste Entwurf von Prüfung 40 schon einmal gefallen ist) |
+| **E4** | **Zählt eine liegengebliebene Kopie als Abweichung des Laufs?** | **Ja, mit eigener Zeile und Exit-Code 1**, nach drei Versuchen über 1,5 s. Ein stumm liegengebliebenes Arbeitsverzeichnis ist genau der Ausfall, gegen den dieses Repositorium gebaut ist | **Ein Lauf kann an etwas rot werden, das über keine Prüfung etwas aussagt.** Das ist gewollt und der Grund für die drei Versuche: Unter Windows hält ein gerade beendeter Unterprozess eine Datei noch einen Augenblick fest, und eine Meldung, die auch ohne Anlass kommt, wird binnen eines Releases abgeschaltet. Verworfen: melden ohne zu zählen (**eine Meldung, die nichts ändert, wird überlesen – das ist der Befund von 0.45.0**, wo eine Warnung einunddreißig Releases lang überlesen wurde) |
+| **E5** | **Wie viele Bahnen, und woher kommt die Zahl?** | **Vorgabe 8, Schalter `--bahnen N`, `--bahnen 1` als serieller Rückfallweg.** Nebenläufig über Threads: Die Wartezeit liegt im Unterprozess, nicht im Python-Code | **Eine feste Zahl passt nie zu jeder Maschine.** Verworfen: die Kernzahl des Rechners als Vorgabe (hier 32) – dann hängt die Laufzeit von der Maschine ab und zwei Läufe sind unvergleichbar, und der Engpass ist die Platte: Jede Einheit legt eine eigene Kopie des Repositoriums an |
+| **E6** | **Was tut ein unerwarteter Fehler in einer Einheit?** | **Er fällt dieser einen Einheit zur Last** – als `FEHL`-Zeile mit Rückverfolgung –, statt den ganzen Lauf abzubrechen | **Ein Lauf kann jetzt grüne Zeilen neben einem Abbruch zeigen.** Derselbe Zuschnitt, den `buendel()` seit `CR-2026-060` E2 für Präparationsfehler hat: Ein Abbruch, der 128 ungefahrene Einheiten mitnimmt, verbirgt mehr, als er zeigt |
+| **E7** | **Bekommt ein Bündel eine Kopfzeile in der Ergebnisausgabe?** | **Ja.** Sein Satz steht über seinen Zeilen – sonst wäre der Satz nur in der Auswertung sichtbar, also unterhalb der Trennlinie und außerhalb der Abnahme | **Neunzehn Zeilen mehr** in der Abnahmeform (208 → 227). Das ist eine gewollte Änderung der Vergleichsgrundlage, und sie ist es genau einmal |
+| **E8** | **Eigenes Release oder Anhang?** | **Eigenes Release `0.46.0`.** Der Prüfapparat selbst ist der Gegenstand; das gehört sichtbar in den Änderungsverlauf | **Das einundzwanzigste Release in vier Tagen** – und das erste ohne jeden Befund als Anlass |
+| **E9** | **Wird der Aufräumer selbst gemessen?** | **Ja, als Selbstproben `A1` und `A2`.** Eine Meldung, die geschrieben und nie ausgelöst wurde, ist nach D-23 nicht vorhanden – und es wäre ausgerechnet die Meldung, die an die Stelle von `ignore_errors=True` tritt. Gemessen wird gegen eine **Hilfseinheit**, sonst zählte der absichtlich herbeigeführte Ausfall als Abweichung des Laufs | **Der Ausfall muss je Betriebssystem anders hergestellt werden:** unter Windows über eine offene Datei, unter POSIX über das entzogene Schreibrecht des Verzeichnisses. Ohne diese Unterscheidung wäre die Selbstprobe auf einem der beiden Systeme eine Zeile, die nichts misst. Preis sind 1,5 s Laufzeit, weil `A2` die drei Versuche wirklich abwartet |
+
+## 5. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen.** E1 bis E5 wie vorgelegt am 2026-09-15 durch den Framework Owner entschieden; E6 bis E9 folgen aus ihnen und sind mit der Umsetzung entschieden. **E9 ist beim Bauen dazugekommen:** Der Aufräumer wäre sonst eine Zusage ohne Sonde gewesen – nach D-23 also nicht vorhanden |
+| Datum | 2026-09-15 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Einträge | D-94 (die Laufzeit steht unterhalb der Trennlinie, die Ergebniszeilen bleiben die zeilengleiche Abnahmeform), D-95 (jede Einheit trägt Name und Beschreibungssatz, und die Selbstprobe zählt ihn nach), D-96 (ein Aufräumer, der scheitert, meldet es und zählt als Abweichung) |
+| Auflagen | **Der Gegenbeweis ist hier kein Fallen von Sonden, sondern ein Abgleich:** Der Umbau ändert keine Prüfung, also darf er keine Ergebniszeile ändern außer den angekündigten. Zu belegen sind (a) die Sondenmenge vor und nach dem Umbau, (b) die Gleichheit der Ergebniszeilen zwischen `--bahnen 1` und `--bahnen 8`, (c) die Gleichheit in beiden Kodierungsumgebungen nach D-49, (d) die Abweichung gegen 0.45.0 Zeile für Zeile – **erwartet sind genau 10 verlängerte Sätze, 16 Bündelkopfzeilen und 3 Selbstprobenzeilen, sonst nichts** |
+| Ziel-Release | `0.46.0` |
+| Umsetzung | umgesetzt mit `0.46.0` |