@renoxar/koolie 1.25.0

package/.koolie/core/tests/protocols/2026-09-15-migrationslauf-pilot-0.46.0.md

@@ -0,0 +1,143 @@
+# Migrationslauf: der Pilot von 0.41.0 auf 0.46.0 – und was daneben lag
+
+| Feld | Wert |
+|---|---|
+| Gegenstand | **Kandidat 4 der Übergabe:** „Den Piloten heben und seinen Befund auflösen." Fünf Releases, 0.41.0 bis 0.46.0 |
+| Anlass | Der Pilot (`devpacks/otp-generator`) stand fünf Releases zurück. **Der zweite echte Migrationslauf dieses Projekts** – der erste war 0.37.0 auf 0.41.0 am 2026-09-14 |
+| Datum | 2026-09-15 |
+| Prüfmethode | Der dokumentierte Weg aus `docs/ADOPTION_GUIDE.md` Abschnitt 3, mit einem Validatorlauf **vor**, **zwischen** und **nach** den Nacharbeiten. Die beiden Vorhersagen der Migrationshinweise werden **geprüft**, nicht geglaubt |
+| Umgebung | Windows 11, Python 3.14.4; Pilot als Arbeitskopie, `core.autocrlf=true` |
+| Ergebnis | **Beide Vorhersagen treffen.** Daneben ein Befund, den niemand gesucht hat und der nicht dem Piloten gehört: **versionierter Bytecode des Kerns, in zwei von zwei Projekten** |
+
+## 0. Der Lauf in einem Satz
+
+**Der Migrationshinweis von 0.44.0 hat den Piloten namentlich angekündigt – und er hat
+recht; der Befund, der wirklich zählt, stand daneben und in keinem Hinweis.**
+
+## 1. Der Ausgangsstand
+
+| Messung | Wert |
+|---|---|
+| `leitwerk-core/VERSION` des Piloten | `0.41.0` |
+| Validator des Piloten, `--strict-overlay` | **1 Fehler, 3 Warnungen** |
+| `install.py --check` (aus dem Zielstand, gegen den Piloten) | **eine** abweichende Kerndatei: `.claude/skills/fw-tests/TESTS.md`; 57 unverändert, 20 Projektdateien |
+| `hooks`-Block in `.claude/settings.json` | vorhanden, ein `PreToolUse`-Kommando |
+
+Der eine Fehler und die drei Warnungen betreffen sämtlich Projektinhalte des Piloten (ein
+Sperrbegriff aus der eigenen Vorgeschichte, zwei Quellen-URLs) sowie die bekannte
+Pfadwarnung über die Laufzeitschicht des nicht installierten Packs. **Sie sind der
+Ausgangswert, gegen den am Ende gemessen wird.**
+
+## 2. Der Weg
+
+Nach `docs/ADOPTION_GUIDE.md` Abschnitt 3, in dieser Reihenfolge:
+
+1. `leitwerk-core/` des Piloten durch den Zielstand ersetzt.
+2. `python leitwerk-core/install.py --update` – **eine** Kerndatei aktualisiert, 57
+   unverändert, 20 Projektdateien unberührt.
+3. Validatorlauf **vor** den Nacharbeiten – die eigentliche Messung.
+
+**Ein Nebenbefund am Werkzeug, der keiner ist.** `install.py --dry-run` **ohne**
+`--update` bricht an einer bestehenden Installation mit einem Fehler ab: Er ist der
+Trockenlauf einer *Erst*installation, und D-46 schützt dort vorhandene Projektdateien.
+Die Meldung nennt den richtigen nächsten Schritt („Stammen sie aus einer früheren
+Installation: `--update` verwenden"), also führt sie niemanden in die Irre. **Der
+Trockenlauf einer Aktualisierung heißt `--update --dry-run`**, und er nannte dieselbe
+eine Datei wie der echte Lauf.
+
+## 3. Das Ergebnis der Messung
+
+Validatorlauf am Piloten, Framework `0.46.0`, **vor** den Nacharbeiten:
+
+| Meldung | Anzahl | Vorhergesagt von |
+|---|---|---|
+| `'Bash(mvn -B -q compile)' steht im ask-Korb, und kein Platzhalter des Overlays erklärt diesen Befehl` | **1** | Migrationshinweis 0.44.0 |
+| `Kompatible Framework-Version '0.41.0' passt nicht zu leitwerk-core/VERSION (0.46.0)` | 1 | Adoption Guide, Abschnitt 3 |
+| Projektinhalte des Piloten (Ausgangswert) | 1 Fehler, 3 Warnungen | – |
+| **Gesamt** | **3 Fehler, 3 Warnungen** | |
+
+### 3.1 Die erste Vorhersage: der Migrationshinweis von 0.44.0
+
+Er lautet: *„Ein Projekt, dessen Berechtigungsdatei einen Befehl führt, den Abschnitt 5
+oder 6 nicht für seinen Platzhalter erklärt, bekommt ab diesem Release einen Fehler. …
+**Der Pilot ist genau dieser Fall** – eine Fundstelle, abgezählt."*
+
+**Es ist genau eine.** Damit hat dieses Projekt zum zweiten Mal einen Hinweis über eine
+fremde Installation eingelöst nachgerechnet – und zum zweiten Mal stimmt er.
+
+### 3.2 Die zweite Vorhersage: Prüfung 43 schweigt
+
+Die Übergabe sagte: *„beim Heben bekommt er zusätzlich Prüfung 43 zu sehen. Sein
+`hooks`-Block ist vorhanden (geprüft), also sollte sie dort schweigen."* **Sie schweigt.**
+Das ist eine Vorhersage über ein *Ausbleiben*, und sie ist schwächer als eine über eine
+Meldung – belegt ist damit nur, dass Prüfung 43 hier nichts findet, nicht dass sie hier
+etwas fände, wenn es etwas gäbe. Der Beleg dafür steht in den Sonden zu 43.
+
+## 4. Die Auflösung – eine Entscheidung des Overlay Owners
+
+Der Migrationshinweis sagt ausdrücklich: *„Die Auflösung ist eine Entscheidung des
+Overlay Owners und keine des Frameworks: entweder die Zeile fällt, oder der Befehl wird
+im Overlay als Wert des passenden Platzhalters erklärt."* Beide Wege wurden vorgelegt.
+
+**Entschieden: Die Zeile fällt.** `Bash(mvn -B -q compile)` ist aus dem `ask`-Korb
+genommen; der Befehl bleibt in Abschnitt 5 des Overlays gelistet und wirkt über die
+Regelschicht.
+
+| | Was dafür spricht | Was es kostet |
+|---|---|---|
+| **Die Zeile fällt** (gewählt) | Der Befehl füllt keinen der drei Befehlsplatzhalter; ein Eintrag von Hand ist nach D-76 **kein Ersatz** für einen vierten Schlitz, und die Overlay-Vorlage sagt das seit 0.43.0 wörtlich | Eine Anweisung statt einer technischen Schranke. **Gemessen kostet das nichts:** Das Client Pack hat am 2026-09-14 belegt, dass ein Befehl in keinem Korb in die Rückfrage läuft – dasselbe, was `ask` bewirkt |
+| `<LINT_COMMAND>` füllen (verworfen) | Prüfung 42 wäre ebenso zufrieden, und der Schlitz ist frei | **Das Overlay behauptete dann, ein Kompilierlauf sei ein Lint-/Formatprüfbefehl.** Er ist keiner. Und Befund `Q-01` („es gibt keine erzwungene Formatprüfung") wäre verdeckt statt gelöst – **den Text an den Mechanismus biegen** ist der Befundtyp, den dieses Repositorium sonst bei anderen findet |
+
+## 5. Was daneben lag – und es gehört nicht dem Piloten
+
+Beim Ersetzen von `leitwerk-core/` standen zwei `.pyc`-Dateien als „modified" im
+Arbeitsbaum. Nachgezählt:
+
+| Projekt | Framework-Stand | Versionierte Bytecode-Dateien unter `leitwerk-core/` | `.gitignore` deckt `__pycache__` |
+|---|---|---|---|
+| `devpacks/otp-generator` (Pilot) | 0.41.0 | **6** | nein |
+| `devpacks/test-devin-framework` (Übungsrepo) | 0.45.0 | **2** | nein |
+| `devpacks/leitwerk` (Framework selbst) | 0.46.0 | 0 | **ja** |
+
+**Zwei von zwei.** Und das Framework-Repositorium hat die Zeile seit jeher – deshalb ist
+der Fehler dort nie aufgefallen.
+
+`docs/ADOPTION_GUIDE.md` Abschnitt 2 sagte zur `.gitignore` genau einen Satz: *„Übernimm
+die `.gitignore` des Framework-Repositorys **nicht** unverändert"*, und nennt dann die
+**vier Zeilen, die ein Projekt weglassen muss**. Welche es **braucht**, stand nirgends.
+
+> **Die Lehre, die über den Fall hinausgeht:** Ein Leitfaden, der sagt, was man
+> *weglassen* soll, ist nicht die Umkehrung eines Leitfadens, der sagt, was man
+> *braucht*. Beide Listen sind nötig, und nur eine stand da. Das ist die Bauform des
+> Befunds von 0.45.0, ein zweites Mal.
+
+Behandelt als eigener Antrag: `CR-2026-069`, D-97, Prüfung 45 – siehe
+`2026-09-15-wirkungsnachweise-0.47.0.md`.
+
+## 6. Die Nacharbeiten und der Abschlusswert
+
+| Nacharbeit | Grund |
+|---|---|
+| `Bash(mvn -B -q compile)` aus dem `ask`-Korb | Prüfung 42, D-76, D-90; Entscheidung des Overlay Owners |
+| Abschnitt 5 des Overlays: Freigabestufe auf „nur Regelschicht" | Der Text muss sagen, was gilt – sonst wäre die Zeile eine Zusage ohne Mechanismus |
+| Steckbrief auf `0.46.0`, Overlay-Version auf `0.2.2` an allen drei Ablageorten, Zeile im Änderungsverlauf | Adoption Guide Abschnitt 3, Schritte 3 und 5 |
+| Sechs `.pyc` aus der Versionierung, `__pycache__/` in die `.gitignore` | D-97 |
+
+| Messung danach | Wert |
+|---|---|
+| Validator, `--strict-overlay` | **1 Fehler, 3 Warnungen** – zeichengleich mit dem Ausgangsstand |
+| `install.py --check` | `Core ist auf dem Stand des Releases.` |
+
+**Der Abschlusswert ist der Ausgangswert.** Was die Aktualisierung an Meldungen erzeugt
+hat, ist vollständig abgearbeitet; was übrig bleibt, stand vorher da und gehört dem
+Projekt. Gemergt als `umdiecke/otp-generator` PR #4.
+
+## 7. Was dieser Lauf nicht belegt
+
+- **Er misst keine Sitzung.** Dass der Pilot mit der geänderten Berechtigungsdatei
+  arbeitet wie erwartet, ist nicht gemessen – hier ist eine Datei nachgezählt.
+- **Er sagt nichts darüber, ob `mvn -B -q compile` läuft.** Auf diesem Arbeitsplatz sind
+  weder JDK noch Maven installiert; das war am 2026-09-13 so und ist es geblieben.
+- **Die Zahl „sechs" ist eine Zählung des Zustands, keine der Ursache.** Wann und durch
+  welchen Commit die Dateien in die Versionierung kamen, ist nicht erhoben – für den
+  Befund ist es ohne Belang: Die fehlende Regel erklärt sie alle.

package/.koolie/core/tests/protocols/2026-09-15-wirkungsnachweise-0.45.0.md

@@ -0,0 +1,127 @@
+# Wirkungsnachweise 0.45.0 – Prüfungen 43 und 44
+
+| Feld | Wert |
+|---|---|
+| Datum | 2026-09-15 |
+| Gegenstand | Prüfung 43 (Hook-Block der Berechtigungsdatei, D-92) und Prüfung 44 (Register der Übungspräparationen, D-93) |
+| Antrag | `CR-2026-067` |
+| Grundlage | D-23: Eine Prüfung gilt erst als vorhanden, wenn sie eine bewusst gesetzte Sonde meldet |
+| Ergebnis | **144 Sonden, 57 Gegenproben, 7 Selbstproben – alle bestanden, in beiden Kodierungsumgebungen zeilengleich** (Exit 0). Validator gegen `main`: 0 Fehler, 0 Warnungen |
+
+## 1. Der Sondenlauf
+
+Abnahmeform seit D-49: zwei Läufe, einmal ohne und einmal mit `PYTHONIOENCODING=utf-8`.
+
+| Umgebung | Sonden | Gegenproben | Selbstproben | Exit |
+|---|---|---|---|---|
+| ohne `PYTHONIOENCODING` | 144 | 57 | 7 | 0 |
+| mit `PYTHONIOENCODING=utf-8` | 144 | 57 | 7 | 0 |
+
+Beide Ausgaben sind **zeilengleich** (`diff` über alle Meldezeilen: kein Unterschied). Vor
+diesem Release waren es 135 Sonden und 53 Gegenproben; die Zunahme ist genau die neue:
+**neun Sonden und vier Gegenproben.**
+
+| Kennung | Was sie herstellt | Erwartete Meldung |
+|---|---|---|
+| Sonde 43a (je Pack) | `hooks`-Block aus der Berechtigungsdatei entfernt | „trägt keinen 'hooks'-Block" |
+| Sonde 43b (je Pack) | derselbe Zustand **plus** verwaiste Hook-Datei daneben | dieselbe Meldung **und** der Dateiname darin |
+| Sonde 43c (je Pack) | Block vorhanden, `PreToolUse` leer | „ohne ein einziges PreToolUse-Kommando" |
+| Gegenprobe 43a (je Pack) | Auslieferungszustand | **keine** der beiden Meldungen |
+| Sonde 44a | eine Vorbedingung nennt `UEB-99`, das Register führt es nicht | „das Register in …" |
+| Sonde 44b | das Register führt `UEB-98`, kein Testfall nennt es | „die kein Testfall nennt" |
+| Sonde 44c | die Registerüberschrift ist umbenannt | „führt kein Register mehr" |
+| Gegenprobe 44a | Auslieferungszustand | keine Meldung der Prüfung 44 |
+| Gegenprobe 44b | eine **achte** Präparation, registriert **und** von einem Testfall gebraucht | keine Meldung der Prüfung 44 |
+
+**Gegenprobe 44b ist die wichtigere Hälfte.** Eine Prüfung, die jede neue Kennung meldet,
+bestünde jede Sonde. Sie belegt, dass der **zulässige** Weg – eine Präparation ergänzen und
+sie registrieren – nicht teurer ist als der unzulässige.
+
+## 2. Was der erste Lauf gefunden hat, und es war die Sonde
+
+Der erste Durchgang meldete **zwei Abweichungen, in beiden Umgebungen dieselben** – beide
+in den neuen Sonden, keine in den Prüfungen:
+
+| Abweichung | Ursache | Behebung |
+|---|---|---|
+| Sonde 43b fiel bei `claude-code` | Die Sonde legte eine Datei `hooks.json` an. Die kennt der Validator nicht: `VERWAISTE_HOOK_DATEIEN` führt **genau einen** Namen, `hooks.v1.json`, und den für beide Packs. **Geraten statt nachgesehen** | Beide Packs nutzen denselben Namen; die Herkunft steht als Kommentar an der Stelle |
+| Gegenprobe 44a brach mit `TypeError` ab | Der generischen `gegenprobe()` wurde ein Tupel übergeben; sie nimmt genau einen Suchtext | Statt drei Meldungen aufzuzählen, sucht die Gegenprobe jetzt `"(D-93)"` – der Decision Record steht in **jeder** Meldung der Prüfung 44 und fängt damit auch künftige |
+
+**Die zweite Behebung ist besser als der erste Entwurf**, und zwar aus einem Grund, der
+über diesen Fall hinausgeht: Eine Gegenprobe, die eine Liste bekannter Meldungen
+ausschließt, übersieht jede Meldung, die später dazukommt. Ein gemeinsamer Anker im Text
+jeder Meldung schließt sie alle ein.
+
+**Ein Nebenbefund, der nicht zu diesem Release gehört:** Prüfung 18 sucht bei **beiden**
+Packs nach `hooks.v1.json` – einem Namen aus der `devin-desktop`-Welt. Ob `claude-code` je
+eine eigene Hook-Datei angelegt hat und wie sie dort hieße, ist nicht erhoben. Die Prüfung
+ist damit für dieses Pack möglicherweise wirkungslos, ohne dass es auffällt. Als Kandidat
+geführt, nicht hier behoben.
+
+## 3. Gegenbeweis gegen den Vorstand
+
+### Prüfung 43 – an einem echten Projekt, nicht an einer Konstruktion
+
+Zuschnitt: der **alte Stand des Übungsrepositoriums** (`a2dab6b`, Framework 0.13.0, via
+`git archive`), sein `leitwerk-core/` durch das aus 0.45.0 ersetzt, **kein** `--update` –
+damit die Projektdateien den Auslieferungszustand behalten.
+
+```
+FEHLER  .devin/config.json: trägt keinen 'hooks'-Block. […] Daneben liegt
+        .devin/hooks.v1.json: Dort steht eine Regelmenge, die aussieht, als gälte sie —
+        der Client liest diese Datei nicht (D-32). […] (D-92)
+```
+
+**Die Prüfung findet den Befund, der sie ausgelöst hat**, und ihre Meldung nennt beide
+Hälften der Migration. Die Fehlerzahl ist dabei nachgezählt und nicht nur vorhanden:
+
+| Fehler | Herkunft |
+|---|---|
+| 14 | dieselben, die der 0.44.0-Validator meldete (8× Prüfung 42 unerklärt, 3× verlorener Anker, 1× Prüfung 37, 1× Steckbriefversion, 1× Importsteuerung) |
+| **+1** | **Prüfung 43** – der Gegenstand dieses Nachweises |
+| +1 | `AGENTS.md:3` – eine Prüfung, die zwischen 0.13.0 und heute dazugekommen ist. **Gehört zum Zuschnitt, nicht zum Befund:** Ohne `--update` ist die Wurzel-Anweisungsdatei noch die von 0.13.0 |
+| **16** | **gemessen** |
+
+### Prüfung 44 – der Gegenbeweis ist konstruktionsbedingt stumm, und das gehört gesagt
+
+Zuschnitt: der Vorstand `22b8949` (0.44.0) via `git archive`, geprüft mit dem Validator aus
+0.45.0 über `--root`.
+
+```
+FEHLER  leitwerk-core/onboarding/exercises/README.md: führt kein Register mehr
+        (gesucht: '### Register der Präparationen'). […] (D-93)
+```
+
+**Das ist ein Treffer, aber nicht der Gegenstand.** Die Prüfung meldet dort den verlorenen
+Anker, weil das Register mit **diesem** Release entsteht; über Präparationen sagt der
+Vorstand nichts, weil er keine kennt. Der Wirkungsnachweis für Prüfung 44 ruht deshalb
+allein auf ihren drei Sonden und zwei Gegenproben – **nicht** auf einem Fund im Vorstand.
+Das ist dieselbe Lage wie am 2026-09-13 bei Prüfung 33 und sie wird hier genauso
+ausgewiesen, statt eine Zahl zu nennen, die mehr verspricht.
+
+Die 46 Fehler, die derselbe Lauf insgesamt meldet, sind **kein Messwert über den Vorstand**:
+Ein neuer Validator gegen einen alten Baum fällt in die Ankertests der Prüfungen, deren
+Gegenstand dort noch fehlt. Das ist bekannt (Protokoll zu 0.33.0) und hier nur erwähnt,
+damit die Zahl niemanden in die Irre führt.
+
+## 4. Wo die Prüfungen im eigenen Repositorium stehen
+
+| Prüfung | Läuft im Repo-Lauf? | Findet sie dort etwas? |
+|---|---|---|
+| 43 | **ja** – die lokale Testinstallation ist `devin-desktop` und führt ihre Hooks in der Berechtigungsdatei | **nein**, sie trägt ihren Block. Das ist der erwartete Zustand und kein Beleg für Wirkung |
+| 44 | **ja** – beide Register liegen im Repositorium | **nein**, sieben registrierte und sieben gebrauchte Kennungen decken sich |
+
+**Prüfung 43 entgeht damit nicht dem Befund B02** (eine Prüfung, die im eigenen
+Repositorium gar nicht ausgeführt wird): Sie läuft. Sie meldet nur nichts, weil hier nichts
+zu melden ist.
+
+## 5. Was dieser Nachweis nicht leistet
+
+- **Er belegt, dass die Prüfungen wirken, nicht dass ihre Gegenstände richtig sind.** Ob der
+  Hook-Block, den eine Installation trägt, den richtigen Hook aufruft, prüfen 15, 16 und 17
+  – nicht 43.
+- **Prüfung 44 gleicht zwei Register ab, nicht ein Register gegen die Wirklichkeit.** Ob
+  `UEB-02` im Übungsrepository wirklich unter dem genannten Pfad liegt, sieht kein Validator
+  dieses Repositoriums.
+- **Kein Lauf gegen einen Client.** Dass ein wiederhergestellter Hook in einer Sitzung
+  tatsächlich auslöst, ist hier nicht gemessen – nur, dass die Konfiguration dasteht.

package/.koolie/core/tests/protocols/2026-09-15-wirkungsnachweise-0.46.0.md

@@ -0,0 +1,193 @@
+# Wirkungsnachweise 0.46.0 – der Umbau des Sondenskripts
+
+| Feld | Wert |
+|---|---|
+| Datum | 2026-09-15 |
+| Gegenstand | Ausführungsplan, Nebenläufigkeit, Name und Beschreibungssatz je Einheit, Laufzeitauswertung, Aufräumer (D-94 bis D-96) |
+| Antrag | `CR-2026-068` |
+| Grundlage | D-23 und D-49. **Hier ist der Gegenbeweis kein Fallen von Sonden, sondern ein Abgleich:** Der Umbau ändert keine Prüfung, also darf er keine Ergebniszeile ändern außer den angekündigten |
+| Ergebnis | **144 Sonden, 57 Gegenproben, 10 Selbstproben – alle bestanden, in beiden Kodierungsumgebungen zeilengleich und zwischen seriellem und nebenläufigem Lauf zeilengleich** (Exit 0). Validator: 0 Fehler, 0 Warnungen |
+
+## 1. Der Vorstand – gemessen, bevor etwas gebaut wurde
+
+`python leitwerk-core/tests/scripts/probe-pruefungen.py .` gegen `main` (`750ce10`, 0.45.0):
+
+| 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 sagte nicht, wo die dreizehn Minuten hingehen. Er wird **zweimal je Release**
+gefahren (D-49), also kostet ein Release allein hier über eine halbe Stunde.
+
+## 2. Die vier Abnahmeläufe
+
+| # | Lauf | Zeilen | Sonden | Gegenproben | Selbstproben | Exit | Wanduhr |
+|---|---|---|---|---|---|---|---|
+| **L1** | `--bahnen 8`, ohne `PYTHONIOENCODING` | 227 | 144 | 57 | 10 | 0 | **110,6 s** |
+| **L2** | `--bahnen 8`, mit `PYTHONIOENCODING=utf-8` | 227 | 144 | 57 | 10 | 0 | **110,8 s** |
+| **L3** | `--bahnen 1`, ohne `PYTHONIOENCODING` | 227 | 144 | 57 | 10 | 0 | **827,4 s** (13 min 47 s) |
+| **L4** | `--bahnen 16`, ohne `PYTHONIOENCODING` | 227 | 144 | 57 | 10 | 0 | **79,7 s** |
+
+**Drei Vergleiche, alle über die 227 Zeilen oberhalb der Trennlinie:**
+
+| Vergleich | Was er belegt | Ergebnis |
+|---|---|---|
+| L1 gegen L2 | die Abnahmeform nach D-49 – beide Kodierungsumgebungen | **kein Unterschied** |
+| L1 gegen L3 | dass die Nebenläufigkeit die Ausgabe nicht verändert – weder Reihenfolge noch Inhalt | **kein Unterschied** |
+| L1 gegen L4 | dass die Bahnenzahl die Ausgabe nicht verändert | **kein Unterschied** |
+
+**Der zweite Vergleich ist der eigentliche Nachweis dieses Releases.** Er belegt, dass die
+Sammlung der Zeilen und ihre Ausgabe in der Reihenfolge der **Anmeldung** genau das leisten,
+was sie versprechen: Der nebenläufige Lauf ist vom seriellen nicht zu unterscheiden.
+
+## 3. Der Abgleich gegen 0.45.0 – 29 Zeilen und keine weitere
+
+`diff` über die Ergebniszeilen, 208 gegen 227:
+
+| Art der Abweichung | Anzahl | Warum |
+|---|---|---|
+| verlängerte Beschreibungssätze | **10** | Einzelsonden, die statt eines Satzes nur eine Kennung trugen (D-95) |
+| neue Bündelkopfzeilen | **16** | jedes Bündel nennt jetzt seinen Namen und seinen Satz |
+| neue Selbstprobenzeilen | **3** | `B1` (Wortzahl), `A1` und `A2` (der Aufräumer) |
+| **sonst** | **0** | |
+
+**Die Zahl je Art ist unverändert: 144 Sonden, 57 Gegenproben – vorher wie nachher.** Keine
+Prüfung ist angefasst worden, und keine Sonde hat ihren Gegenstand gewechselt.
+
+## 4. Der erste Fallstrick: Prüfung 40 hätte den Umbau nicht überlebt
+
+Prüfung 40 rechnet die Sondenmenge aus **zwei wörtlichen Mustern** des Sondenskripts aus
+(D-86): dem Aufruf `sonde(` mit seiner Kennung und `melde(` mit der Art `SONDE` und ihr.
+Ein Umbau auf ein Register mit eigener Schreibweise hätte die Sonden unsichtbar gemacht –
+und Prüfung 40 hätte **leise bestanden**, denn eine leere Menge ist keine Abweichung.
+
+**Nachgezählt vor und nach dem Umbau, mit demselben Ausdruck, den der Validator verwendet:**
+
+| Stand | Prüfungsnummern mit Sonde | Ausgerechnete Schreibweise |
+|---|---|---|
+| 0.45.0 | 6, 18, 19, 20, …, 44 | `6 und 18 bis 44` |
+| 0.46.0 | 6, 18, 19, 20, …, 44 | `6 und 18 bis 44` |
+
+Deshalb ist die Aufrufstelle jeder Sonde **zeichengleich** geblieben; geändert hat sich
+allein, **wann** der Aufruf seine Arbeit tut. Und deshalb heißt der Anmelder `eintragen()`:
+
+> `anmelden("SONDE", "18b", …)` enthält die Zeichenfolge `melde(` **nicht** – dort folgt auf
+> `melde` ein `n`. `anmelde("SONDE", "18b", …)` hätte sie enthalten, und Prüfung 40 hätte
+> eine Sonde `18b` gezählt, die es nicht gibt. **Der Abstand zwischen beiden Namen ist ein
+> Buchstabe.** Statt ihn zu riskieren, heißt die Funktion `eintragen()`.
+
+## 5. Wo die Zeit liegt – und wo die Grenze der Nebenläufigkeit
+
+Aus dem Auswertungsblock von L1 (874,2 s Rechenzeit in 110,6 s Wanduhr, Faktor 7,9):
+
+| Einheit | Laufzeit | Anteil an der Rechenzeit |
+|---|---|---|
+| `sonden_schlitzinhalte` | **64,0 s** | 7,3 % |
+| `sonden_kandidatenpruefung` | 43,8 s | 5,0 % |
+| `sonden_aktivierungspruefung` | 37,2 s | 4,3 % |
+| `sonden_berechtigungskoerbe` | 31,2 s | 3,6 % |
+| `sonden_hookblock` | 30,4 s | 3,5 % |
+| `sonden_skill_deny` | 21,4 s | 2,4 % |
+| **sechs Bündel zusammen** | **228 s** | **26 %** |
+| **114 Einzeleinheiten, je rund 5,8 s** | **rund 645 s** | **74 %** |
+
+**Zwei Zahlen, die zusammen etwas sagen, das keine allein sagt.** Die Einzeleinheiten
+tragen drei Viertel der *Rechenzeit* und sind beliebig teilbar; die Bündel tragen ein
+Viertel und sind **gar nicht** teilbar. Damit ist die Wanduhr nach unten begrenzt:
+
+> **Kein noch so breiter Lauf kommt unter 64,0 s**, solange `sonden_schlitzinhalte` die
+> längste Einheit ist – denn ein Bündel ist die kleinste Einheit, nie seine Teile (F3). Die
+> Schranke ist keine Schwäche der Umsetzung, sondern die Entscheidung selbst, sichtbar
+> gemacht.
+
+**L4 misst das nach, und das Ergebnis ist zweischneidig:**
+
+| Lauf | Bahnen | Wanduhr | Rechenzeit | Faktor |
+|---|---|---|---|---|
+| L3 | 1 | 827,4 s | 827,4 s | – |
+| L1 | 8 | **110,6 s** | 874,2 s | 7,9 |
+| L4 | 16 | **79,7 s** | **1079,6 s** | 13,5 |
+
+Die doppelte Bahnenzahl bringt **28 % weniger Wanduhr** und kostet **23 % mehr
+Rechenzeit**. Das ist der Beleg dafür, dass nicht die Rechenzeit der Engpass ist,
+sondern die Platte: Jede Einheit legt eine eigene Kopie des Repositoriums an, und
+sechzehn gleichzeitige Kopiervorgänge machen jeden einzelnen langsamer. **Die 79,7 s
+liegen zudem schon nahe an der Schranke von 64,0 s** – mehr Bahnen können die
+längste Einheit nicht teilen.
+
+**Deshalb bleibt die Vorgabe bei 8 und ist eine feste Zahl:** Sie holt 7,9 von
+theoretisch 8 heraus, ohne Rechenzeit zu verbrennen. Was der beste Wert auf einer
+anderen Maschine ist, ist damit nicht gesagt – und soll es nicht sein.
+
+## 6. Der Aufräumer – und warum er eine eigene Selbstprobe bekommt
+
+An **vierzehn** Stellen stand `shutil.rmtree(..., ignore_errors=True)`, während der
+Kopfsatz des Skripts zusagt: *„Gearbeitet wird auf einer Kopie; das Repositorium selbst
+bleibt unberührt."* Die zweite Hälfte dieser Zusage – dass die Kopie danach wieder weg ist
+– hatte **keinen Mechanismus**.
+
+`aufraeumen()` versucht dreimal über 1,5 s und meldet danach mit Pfad und Grund. **Eine
+Meldung, die geschrieben und nie ausgelöst wurde, ist nach D-23 nicht vorhanden** – deshalb
+zwei Selbstproben:
+
+| Kennung | Was sie herstellt | Erwartung |
+|---|---|---|
+| `A1` | ein gewöhnliches Arbeitsverzeichnis mit einer Datei darin | gelöscht, **und keine Zeile im Lauf** |
+| `A2` | ein Verzeichnis, das sich nicht löschen lässt | `AUFRAEUMER … bleibt liegen` mit dem Pfad, und **eine** Abweichung |
+
+**Der Ausfall muss je Betriebssystem anders hergestellt werden, und das ist der Teil, an
+dem die Probe sonst nichts gemessen hätte:**
+
+| System | Mechanismus | Warum der andere nicht trägt |
+|---|---|---|
+| Windows | eine offene Datei im Verzeichnis | gemessen: `PermissionError [WinError 32]` |
+| POSIX | dem Verzeichnis das Schreibrecht entziehen (`0o500`) | eine offene Datei verhindert das Löschen dort **nicht** – die Probe wäre eine Zeile, die nichts misst |
+
+**Gemessen wird gegen eine Hilfseinheit**, nicht gegen die laufende: Der Aufräumer meldet in
+die Einheit, in der er gerufen wird. Täte er das hier, zählte der absichtlich
+herbeigeführte Ausfall als Abweichung des Laufs – die Selbstprobe erzeugte den Befund, den
+sie misst.
+
+**Gemessen ist damit, dass die Meldung kommt, wenn sie kommen muss.** Nicht gemessen ist,
+ob drei Versuche über 1,5 s für den echten Fall reichen: In keinem der vier Abnahmeläufe
+ist eine Kopie unbeabsichtigt liegen geblieben.
+
+## 7. Selbstprobe B1 – und was sie nicht leistet
+
+`B1` zählt die Worte jedes Beschreibungssatzes und meldet jeden Ausreißer. Vor dem Umbau
+hätte sie **24 Abweichungen** gemeldet: zehn zu kurze Einzelsätze und vierzehn Bündel ohne
+Satz.
+
+**Ihre Grenze steht in ihrem Kopfkommentar, weil sie sonst mehr verspräche, als sie
+leistet:** Sie zählt **Worte, nicht Sinn**. Ein Satz aus achtzehn Füllwörtern besteht sie.
+Die untere Grenze fängt die Kennung, die sich als Satz ausgibt („Pack ohne
+Auskunftsabschnitt", drei Worte), die obere den Absatz, der sich in eine Zeile verirrt hat.
+Dazwischen entscheidet der Mensch, und das ist Absicht.
+
+## 8. Was dieses Protokoll nicht belegt
+
+- **Nicht, dass acht Bahnen der beste Wert sind.** Gemessen sind drei Punkte auf **einer**
+  Maschine mit 32 Kernen und einer SSD. Auf einem Rechner mit anderer Platte kann die
+  Kurve anders liegen; die Vorgabe ist bewusst eine feste Zahl und keine Eigenschaft der
+  Maschine, sonst wären zwei Laufzeiten unvergleichbar.
+- **Nicht, dass die Laufzeiten reproduzierbar sind.** Sie sind es nicht, und genau deshalb
+  stehen sie unterhalb der Trennlinie. Was sie belegen, ist die **Verteilung**.
+- **Nicht, welcher Fall innerhalb eines Bündels teuer ist.** Ein Bündel bekommt eine Zahl,
+  nicht fünfunddreißig. Wer wissen will, welcher der sieben Eingriffe in
+  `sonden_berechtigungskoerbe` die Zeit kostet, erfährt es aus diesem Lauf nicht.
+- **Nicht, dass die Prüfungen richtig sind.** Dieses Release fasst keine Prüfung an; es
+  verändert das Werkzeug, mit dem sie gemessen werden. Die Grenze jeder einzelnen Prüfung
+  steht unverändert in ihrem Kopfkommentar.
+
+## 9. Anmerkung zur Reihenfolge
+
+Die vier Abnahmeläufe L1 bis L4 liefen gegen den Arbeitsbaum **ohne diese Datei**, die es
+zum Zeitpunkt der Läufe noch nicht gab – jedes Protokoll hat dieses Problem, weil es
+über Läufe berichtet, die vor ihm stattfanden.
+
+**Deshalb ein fünfter Lauf gegen den vollständigen Baum**, so wie er in den Commit geht:
+`--bahnen 8`, ohne `PYTHONIOENCODING`, 227 Zeilen, Exit 0, 111,7 s – und **zeilengleich
+zu L1**. Der Validatorlauf gegen denselben Baum meldet 0 Fehler und 0 Warnungen.

package/.koolie/core/tests/protocols/2026-09-15-wirkungsnachweise-0.47.0.md

@@ -0,0 +1,149 @@
+# Wirkungsnachweise 0.47.0 – Prüfung 45 und der erste Fall des Aufräumers
+
+| Feld | Wert |
+|---|---|
+| Datum | 2026-09-15 |
+| Gegenstand | Prüfung 45 (Bytecode des Kerns, D-97) und die Behebung am Aufräumer aus 0.46.0 |
+| Antrag | `CR-2026-069` |
+| Grundlage | D-23: Eine Prüfung gilt erst als vorhanden, wenn sie eine bewusst gesetzte Sonde meldet. Dazu der Gegenbeweis gegen den Vorstand |
+| Ergebnis | **148 Sonden, 59 Gegenproben, 11 Selbstproben – alle bestanden, in beiden Kodierungsumgebungen zeilengleich** (Exit 0). Validator: 0 Fehler, 0 Warnungen. **Gegenbeweis gegen 0.46.0: vier Fundstellen, und beide Gegenproben bestehen dort** |
+
+## 1. Der Befund, abgezählt
+
+| Projekt | Framework-Stand | Versionierte `.pyc` unter `leitwerk-core/` | `.gitignore` deckt `__pycache__` |
+|---|---|---|---|
+| `devpacks/otp-generator` (Pilot) | 0.41.0 | **6** | nein |
+| `devpacks/test-devin-framework` (Übungsrepo) | 0.45.0 | **2** | nein |
+| `devpacks/leitwerk` (Framework selbst) | 0.46.0 | 0 | **ja** |
+
+**Zwei von zwei Projekten.** Der Weg zum Befund steht in
+`2026-09-15-migrationslauf-pilot-0.46.0.md`, Abschnitt 5.
+
+## 2. Der Sondenlauf
+
+Abnahmeform seit D-49: zwei Läufe, einmal ohne und einmal mit `PYTHONIOENCODING=utf-8`.
+Seit 0.46.0 zusätzlich der Vergleich zwischen seriellem und nebenläufigem Lauf.
+
+| Lauf | Zeilen | Sonden | Gegenproben | Selbstproben | Exit | Wanduhr |
+|---|---|---|---|---|---|---|
+| `--bahnen 8`, ohne `PYTHONIOENCODING` | 235 | 148 | 59 | 11 | 0 | **118,2 s** |
+| `--bahnen 8`, mit `PYTHONIOENCODING=utf-8` | 235 | 148 | 59 | 11 | 0 | **120,6 s** |
+| `--bahnen 1`, ohne `PYTHONIOENCODING` | 235 | 148 | 59 | 11 | 0 | **911,0 s** |
+
+**Beide Ausgaben sind zeilengleich** – `diff` über die 235 Ergebniszeilen oberhalb der Trennlinie: kein Unterschied. Und der serielle Lauf ist **zeilengleich zum nebenläufigen** – die Zusage von 0.46.0 trägt auch die neuen Einheiten, einschließlich derer, die sich ein Repositorium anlegen.
+
+Vor diesem Release waren es 144 Sonden, 57 Gegenproben und 10 Selbstproben; die Zunahme
+ist genau die neue: **vier Sonden, zwei Gegenproben, eine Selbstprobe.**
+
+| Kennung | Was sie herstellt | Erwartete Meldung |
+|---|---|---|
+| Sonde 45a | Die Deckungszeile fällt aus der `.gitignore` | „deckt den Bytecode des Kerns nicht ab" |
+| Sonde 45b | Die `.gitignore` fehlt ganz | „.gitignore: nicht vorhanden" (**Warnung**, kein Fehler) |
+| Sonde 45c | Ein echtes Repositorium, eine `.pyc` unter `leitwerk-core/` verfolgt – **bei vorhandener Regel** | „sind versioniert", und der Pfad der Datei steht darin |
+| Sonde 45d | Dieselbe Installation **ohne** `git init` | „ist nicht gelaufen" |
+| Gegenprobe 45a | `*.pyc` statt `__pycache__/` – andere Schreibweise, gleiche Wirkung | **keine** Meldung der Prüfung 45 |
+| Gegenprobe 45b | Ein Repositorium ohne verfolgten Bytecode | weder „sind versioniert" **noch** „ist nicht gelaufen" |
+| Selbstprobe A3 | Ein Arbeitsverzeichnis mit einer schreibgeschützten Datei | **keine** Zeile – der Aufräumer räumt weg und schweigt |
+
+### 2.1 Die beiden Gegenproben sind hier die schärferen
+
+**Gegenprobe 45a** misst die Breite: Ein Projekt, das `*.pyc` schreibt, ist **richtig**.
+Eine Prüfung, die nur `__pycache__/` gelten ließe, meldete den richtigen Text – und das
+ist genau der Fehler, den Prüfung 37 einmal gemacht hat.
+
+**Gegenprobe 45b** misst zwei Dinge auf einmal, und das zweite ist das wichtigere: Sie
+verlangt, dass „sind versioniert" **fehlt** – und dass „ist nicht gelaufen" **ebenfalls
+fehlt**. Ohne die zweite Bedingung bestünde sie auch dann, wenn git gar nicht da wäre;
+sie bewiese dann nichts über Gegenstand 2, sondern nur, dass er schwieg. **Eine
+Gegenprobe, die eine abgeschaltete Prüfung nicht von einer schweigenden unterscheidet,
+misst ihren Fall nicht mehr.**
+
+### 2.2 Warum die Sonden zu Gegenstand 2 im Bündel stehen
+
+`kopie()` lässt `.git` bewusst weg – eine Kopie des Repositoriums ist keins. Gegenstand 2
+ist deshalb auf einer Kopie **nicht herstellbar**; seine Sonden legen sich ihr
+Repositorium selbst an (`installation()`, dann `git init`). Das ist dieselbe Begründung,
+aus der die Sonden zu den Prüfungen 33, 37, 42 und 43 im Bündel stehen: Der Gegenstand
+ist eine installierte Lage, nicht ein Text.
+
+**Sonde 45d steht vor dem `git init`** – und zwar bewusst: Genau dieser Zustand, ein Baum
+ohne `.git`, ist der Normalfall **jeder anderen Sonde dieses Skripts**. Sie belegt damit
+zugleich, dass die Warnung, die alle übrigen Sondenläufe jetzt tragen, die richtige ist.
+
+## 3. Der Gegenbeweis gegen den Vorstand
+
+Gemessen mit dem **neuen** Sondenskript gegen einen **vollständigen** Arbeitsbaum auf
+0.46.0 – Validator, Sondenskript und Testkatalog dort auf dem Stand von `main`, alles
+übrige identisch:
+
+| Einheit | Gegen 0.46.0 | Erwartet |
+|---|---|---|
+| Sonde 45a | **FEHL** | fällt |
+| Sonde 45b | **FEHL** | fällt |
+| Sonde 45c | **FEHL** | fällt |
+| Sonde 45d | **FEHL** | fällt |
+| Gegenprobe 45a | OK | **besteht** |
+| Gegenprobe 45b | OK | **besteht** |
+
+**Vier Fundstellen, und die beiden Gegenproben bestehen.** Das ist die richtige Form und
+nicht nur die erfreuliche: Eine Gegenprobe stellt einen **zulässigen** Zustand her, und
+ein zulässiger Zustand läuft auch dort durch, wo es die neue Prüfung noch gar nicht gibt.
+Fiele sie gegen den Vorstand, prüfte sie etwas anderes als ihren Fall.
+
+> **Ein Zwischenfall, der hier hingehört:** Der erste Versuch des Gegenbeweises lief gegen
+> einen frischen `git worktree` auf `main` – und **alle** Einheiten fielen, auch die
+> Gegenproben. Der Grund ist nicht das Release: Das Framework-Repositorium versioniert
+> seine Wurzelerzeugnisse bewusst **nicht** (sie entstehen aus `install.py`), und ein
+> frischer Worktree hat sie deshalb nicht. Sein eigener Validatorlauf meldete **46 Fehler**.
+> **Ein Vorstand ohne Wurzelerzeugnisse ist kein Vorstand**, und eine Gegenprobe, die
+> „0 Fehler" verlangt, fällt dort aus einem Grund, der mit ihrem Gegenstand nichts zu tun
+> hat. Der Vorstand ist deshalb ein vollständiger Arbeitsbaum mit drei zurückgesetzten
+> Dateien – und der meldet 0 Fehler, 0 Warnungen.
+
+## 4. Der Aufräumer aus 0.46.0 – sein erster echter Fall
+
+Die Sonde zu Gegenstand 2 legt ein Repositorium an. **Git schreibt seine Objektdateien
+schreibgeschützt.** Der Aufräumer versuchte dreimal über anderthalb Sekunden zu löschen
+und meldete:
+
+```
+AUFRAEUMER -    FEHL  sonden_bytecode: C:\…\lw-inst-p8auo49r bleibt liegen
+        [WinError 5] Zugriff verweigert: …\.git\objects\03\7c6087d4df…
+        3 Versuche ueber 1,5 s, danach aufgegeben.
+```
+
+**Er hatte recht und war trotzdem nutzlos.** Er meldete einen Zustand, den er selbst
+hätte auflösen können: *Warten hilft gegen eine gehaltene Datei und gar nichts gegen eine
+schreibgeschützte.* Die Roadmap führte genau diese Frage als offenen Punkt von 0.46.0
+(„unerhoben, ob drei Versuche über 1,5 s für den echten Fall reichen") – **der Fall ist
+da, und die Antwort ist nein.**
+
+Jeder Versuch ab dem zweiten nimmt jetzt zuerst den Schreibschutz im ganzen Baum weg.
+**Ohne `onerror`/`onexc` von `shutil.rmtree`:** Die beiden Namen haben sich zwischen den
+Python-Fassungen abgelöst, und ein Nachweiswerkzeug, das an der Fassung seines
+Interpreters hängt, ist genau das, was D-49 abgeschafft hat.
+
+**Die Selbstprobe `A3` misst es** – eine Behebung ohne Sonde ist nach D-23 keine. Sie
+gilt auf beiden Betriebssystemen, aus verschiedenen Gründen: Unter Windows belegt sie den
+Mechanismus, unter POSIX, dass er nichts kaputt macht (dort blockiert eine
+schreibgeschützte *Datei* das Löschen ohnehin nicht). **Wer den Mechanismus unter Windows
+entfernt, macht sie rot.**
+
+> **Das ist der Ertrag von 0.46.0, eingelöst binnen eines Releases:** Bis dahin stand an
+> dieser Stelle `ignore_errors=True`. Das Verzeichnis wäre liegen geblieben, der Lauf
+> wäre grün gewesen, und niemand hätte je erfahren, dass die Sonde zu Prüfung 45 bei
+> jedem Lauf ein Repositorium auf der Platte zurücklässt.
+
+## 5. Was dieses Protokoll nicht belegt
+
+- **Nicht, dass die Deckungsliste vollständig ist.** Fünf Schreibweisen gelten; eine
+  wirksame, aber exotische sechste meldet die Prüfung als fehlend. Die Grenze steht im
+  Kopfkommentar.
+- **Nicht, dass Gegenstand 1 die Wirkung prüft.** Eine Regel, die durch eine spätere
+  Ausnahmezeile (`!*.pyc`) wieder aufgehoben wird, fällt ihm nicht auf. Den Fall fängt
+  Gegenstand 2 – aber nur, wo git da ist.
+- **Nicht, dass drei Versuche jetzt reichen.** Sie reichen gegen den Schreibschutz, weil
+  er gelöst wird, und gegen eine kurz gehaltene Datei. Gegen eine dauerhaft geöffnete
+  reichen sie nicht – und genau das misst `A2`, indem sie sie herstellt.
+- **Nicht, dass das Übungsrepositorium hergerichtet ist.** Es führt weiterhin zwei
+  versionierte `.pyc` und steht auf 0.45.0. Das gehört zum nächsten Heben dorthin.