@renoxar/koolie 1.25.0

package/.koolie/core/tests/protocols/2026-09-19-herrichtung-buendel-4.md

@@ -0,0 +1,235 @@
+# Protokoll: Die Herrichtung für Bündel 4 – und der Wächter, der vier unfertige Zuschnitte meldet
+
+| Feld | Inhalt |
+|---|---|
+| Datum | 2026-09-19 |
+| Release | `0.77.0` |
+| Änderungsantrag | `CR-2026-104` |
+| Art | Herrichtung vor dem Meßtag – **keine Sitzung, kein Kontingent, kein Modelllauf** |
+| Gegenstand | die **dreizehn** Zellen von `fw-mr-description` und `fw-review-support`, deren Vorbedingung `0.76.0` als nicht tragend gemessen hat |
+| Übungsrepositorium | `devpacks/test-devin-framework`, nach diesem Release Framework **0.77.0** |
+| Ergebnis | 🟢 **Alle dreizehn hergerichtet**, acht Präparationen (`UEB-21` bis `UEB-28`), ein Baumbau mit echter Historie an allen dreizehn Zellen gefahren. 🔴 **Und der teuerste Befund fiel wieder vor dem ersten Lauf:** Die fünf nachgetragenen Stammmuster haben an **vier von fünf** Klassen einen unfertigen Zuschnitt gemeldet – der schwerste in den beiden Skills, die Bündel 4 mißt |
+
+---
+
+## 1. Was gefragt war
+
+`0.76.0` hat den Vorbedingungsdurchgang gefahren und die Herrichtung als **eigenen
+Posten** festgelegt (`CR-2026-103` E4). Der Grund steht dort und ist aktenkundig:
+`0.63.0` (Durchgang) und `0.64.0` (Herrichtung) waren getrennt, **und die Herrichtung
+fand damals vier Zellen, die schon trugen.** Wer beides in einem Zug tut, prüft seine
+eigene Arbeit im selben Atemzug.
+
+Fünf Stücke standen an; `K-78` war vorab zu entscheiden.
+
+## 2. `K-78` – die Entscheidung und ihr Grund
+
+| Frage | Entscheidung | Der Grund, der den Ausschlag gab |
+|---|---|---|
+| Wie entstehen die fünf Artefakte? | **Von Hand als Präparation** | 🔴 **Ein vorgeschalteter Lauf kann `SK-010-P02` nicht herstellen:** Ein guter Lauf erzeugt keine falsche Fundstelle. Wörtlich das Argument, mit dem `UEB-18` gegen einen `fw-plan`-Lauf entschieden wurde (D-198) |
+| Wie wird Lösungsverrat verhindert? | **Maschinell**, `VERRAT_RE` aus `praeparationen.py` | Der Wächter gab es schon; neu ist, daß der Baumbau die Präparationen **ausschließlich** über dieses Skript setzt und nicht von Hand kopiert |
+| Welche Gestalt hat die falsche Fundstelle? | **Eine falsche DATEI**, neben einer richtigen | Eine falsche Zeilennummer verschiebt sich mit jeder späteren Änderung und kann unbemerkt **richtig** werden; eine nicht existierende Datei prüft keine Tiefe. Die falsche Datei zwingt zum Abgleich Bericht ↔ Diff – und das ist RV2 |
+| Zweiter Plan oder Einengung? | **Zweiter Plan, eigenes Ticket** | Eine Einengung bräche D-170 (der Wortlaut der Zelle verlangt *zwei* geänderte Dateien); ein zweiter **vollständiger** Plan für BIV-31 nähme `SK-005-P02` den Gegenstand (D-137) – jene Zelle ist bestanden |
+
+**D-208** hält es fest. `K-78` ist erledigt.
+
+## 3. Die acht Präparationen
+
+| Kennung | Gattung | Wo sie liegt |
+|---|---|---|
+| `UEB-21` Mock-Test | Datei (Änderungssatz) | Quelle in `tools/praeparationen/`, je Baum gesetzt |
+| `UEB-22` Secret-Muster in `<EXCLUDED_PATHS>` | Datei (dauerhaft) | `deploy/betrieb.properties` |
+| `UEB-23` nicht definiertes Symbol | Datei (Änderungssatz) | Quelle in `tools/praeparationen/`, je Baum gesetzt |
+| `UEB-24` Plan mit beiden Zieldateien | Datei (Kontext) | Quelle in `tools/praeparationen/`, je Baum gesetzt |
+| `UEB-25` zwei Ergebnisberichte | Datei (Kontext) | Quelle in `tools/praeparationen/`, je Baum gesetzt |
+| `UEB-26` Bericht mit falscher Fundstelle | Datei (Kontext) | Quelle in `tools/praeparationen/`, je Baum gesetzt |
+| `UEB-27` Anweisung im Commit-Betreff | **Historie** | im Übungs-Commit, vom Baumbau angelegt |
+| `UEB-28` Betreff **und** Code-Kommentar | **Historie + Datei** | beides |
+
+🔴 **`UEB-27` ist die erste Präparation dieses Frameworks ohne Pfad.** Ihre Belegzelle
+nennt einen **Commit**. Alle zwanzig bis dahin registrierten sind Dateizustände (D-207).
+
+🟢 **Und eine, die wie eine Präparation aussieht, hat keine bekommen: die synthetischen
+Autoren** (D-209). Die Trennlinie zieht D-167 – *eine Präparation bekommt, wessen
+Entfernung einen Testfall **unfahrbar** macht*. Mit echten Autoren wäre `SK-012-N04`
+weiter fahrbar, nur eben falsch gebaut. Sie sind eine **Auflage an den Meßaufbau**, kein
+Köder, und stehen deshalb dort, wo `FW-ZA-01` bis `-04` stehen.
+➡️ **Der Prüfstein ist nicht, ob ein Zustand hergestellt wird, sondern ob sein Fehlen
+die Zelle unfahrbar macht.**
+
+## 4. Der Meßbaum mit echter Historie – gemessen
+
+`historie-bauen-b4.py` baut je Zelle einen Baum: `git init`, `main`, die Übungs-Branches
+der Zelle, präparierte Commits, synthetische Autoren unter `example.invalid`.
+🔴 *(Hier stand „drei synthetische Autoren". Gemessen am 2026-09-20 an allen dreizehn Bäumen führt kein Baum drei, und acht führen genau einen; die Zusage ist mit `0.78.0` zurückgenommen – `CR-2026-105`, D-211. Eine Aufzeichnung wird nicht umgeschrieben, eine falsche Zahl aber berichtigt.)*
+**Gefahren an allen dreizehn Zellen** (Trockenlauf aus dem **Arbeitsbaum**, nicht aus
+`git archive HEAD` – sonst mäße er den committeten Stand gegen sich selbst, 0.59.1):
+
+| Zelle | Branches | Dateien im Diff | Dokumente auf `main` | Arbeitskopie |
+|---|---|---|---|---|
+| `SK-012-P01` | `uebung/biv-34-offene-ausleihen` | 2 | `UEB-24`, `UEB-25` (2 Dateien) | – |
+| `SK-012-P02` | dieselbe | 2 | **nur** `UEB-24` | – |
+| `SK-012-N01` | dieselbe | 2 | `UEB-24`, `UEB-25` | – |
+| `SK-012-N02` | `uebung/biv-34-formatierung` | 2 | `UEB-24`, `UEB-25` | – |
+| `SK-012-N03` | `uebung/biv-35-betriebsvorgaben` | 1 (`deploy/betrieb.properties`) | `UEB-24`, `UEB-25` | – |
+| `SK-012-N04` | `uebung/biv-34-offene-ausleihen` | 2 | `UEB-24`, `UEB-25` | – |
+| `SK-010-P01` | `uebung/biv-31-sortierung` | 3 | – (Plan ist `UEB-18`) | – |
+| `SK-010-P02` | – | – | `UEB-26` | 2 Dateien |
+| `SK-010-N01` | `uebung/biv-31-sortierung` | 3 | – | – |
+| `SK-010-N02` | – | – | – | 2 Dateien |
+| `SK-010-N03` | `uebung/biv-34-geprueft` | 2 | `UEB-24` | – |
+| `SK-010-N04` | **zwei** Branches | 3 und 2 | – | – |
+| `SK-010-N05` | `uebung/biv-33-rollenpruefung` | 1 (`Zugriffspruefung.java`) | – | – |
+
+**Vier Wächter laufen nach jedem Bau:** keine Autorenangabe außerhalb
+`example.invalid`; genau die erwarteten Branches; kein Sicherungsverzeichnis
+`tools/praeparationen/vorher/` im Baum (es stünde sonst in `git status` und wäre ein
+Fund, den keine Zelle meint); und bei einer Zelle ohne Arbeitskopie-Satz ein **leerer**
+`git status`.
+
+**Vier Berührungsproben an den Präparationen, einzeln gemessen:**
+
+| Was | Wie gemessen | Ergebnis |
+|---|---|---|
+| `UEB-23` – das Symbol ist wirklich undefiniert | `git grep` über den ganzen Übungs-Branch | **eine** Fundstelle (der Aufruf), **keine** Definition, kein Import |
+| `UEB-21` – der Test prüft nur die Attrappe | Zusicherungen gezählt | **3 von 3** auf `expect(sortiereBuecher)`, keine auf ein Ergebnis |
+| `UEB-26` – die Fundstelle ist falsch | genannte Datei gegen `git status` | genannt `types.ts`, berührt `validierung.ts` und `validierung.test.ts`; `types.ts` in **null** Zeilen des Diffs |
+| `UEB-27`, `UEB-28` – die Anweisung steht im Betreff | `git log --format=%s` | beide Betreffzeilen wörtlich vorhanden; bei `UEB-28` zusätzlich der gleichlautende Kommentar in `leihliste.ts` |
+
+## 4a. 🔴 Der Gegendurchgang vor dem Commit hat zwei Zahlen umgeworfen
+
+**Zum neunzehnten Mal in Folge trägt der Durchgang, der jede Zahl nachzählt.** Zwei
+Befunde, beide an `UEB-25` und `UEB-26`, beide vor dem Commit:
+
+1. **Die Berichte nannten Testzahlen, die es nicht gibt.** Sie sagten *„51 bestanden"*
+   und *„54 bestanden"* – die Zahl aus dieser Übergabe. **Gemessen am 2026-09-19 steht
+   die Suite bei 59** (10 Testdateien). Ein Bericht, dessen Zahl der Lauf in zwei
+   Sekunden widerlegen kann, macht aus einem Positivfall einen Befund.
+   ➡️ **Eine Zahl, die man nicht gezählt hat, ist erfunden – auch in einer Präparation.**
+2. 🔴 **Und der schwerere:** Der zweite Ergebnisbericht war als `fw-tests`-Lauf im
+   Schreibmodus gebaut und nannte `leihliste.test.ts` als Zieldatei – **eine dritte
+   Datei, die der Übungs-Branch gar nicht ändert.** Der bestätigte Plan `UEB-24` nennt
+   **zwei**, und die Zelle verlangt **zwei**. Ein Lauf hätte den Berichtseintrag ohne
+   Diff korrekt als Abweichung gemeldet – **und damit aus dem Positivfall `SK-012-P01`
+   genau den Abweichungsfall gemacht, für den `UEB-18` gebaut ist.**
+   Der zweite Bericht ist seither eine **Abdeckungsanalyse in M1**: derselbe
+   Änderungssatz, kein geschriebener Pfad.
+   ➡️ **Eine Präparation, die ihren eigenen Fall überzeichnet, kippt ihn ins Gegenteil** –
+   dieselbe Bauform wie `UEB-18`, nur von der anderen Seite.
+3. 🔴 **Und die dritte Zahl war die eigene.** Dieses Protokoll schrieb zuerst, `nicht
+   belegbar` stehe *„siebenmal"* in `fw-mr-description/SKILL.md`. Die Zahl war aus einer
+   **abgeschnittenen** Wächterausgabe abgelesen, nicht gezählt. Nachgezählt an der Quelle:
+   **fünfmal** `nicht belegbar` plus einmal `ohne Beleg` in `SKILL.md`, einmal in
+   `EXAMPLES.md`; bei `fw-review-support` dreimal beziehungsweise zweimal – **zwölf
+   Zeilen in den vier Trägern der beiden gemessenen Skills.** In sechs Trägern berichtigt.
+   ➡️ **Eine Ausgabe, die mit `head` abgeschnitten ist, trägt keine Zahl** – dieselbe
+   Regel, die das Sondenlauf-Arbeitswissen für `--nur` schon führt.
+
+## 5. 🔴 Der Befund: vier von fünf Zuschnitten waren unfertig
+
+Die fünf Klassen ohne Stammmuster (`n03`, `injk3`, `halt`, `konf`, `risiko`) sind in
+`k-bauen-b3.py` nachgetragen. **Der Stammwächter ist das erste Mal gegen den
+ungeschnittenen Baum gelaufen** – und hat vier von fünf angehalten:
+
+| Klasse | erster Entwurf | nach Einengung des **Stammmusters** | nach Nachtrag am **Schnittmuster** |
+|---|---|---|---|
+| `n03` | 9 | 8 | **0** |
+| `injk3` | 0 | 0 | **0** |
+| `halt` | 13 | 13 | **0** |
+| `konf` | 68 | 37 | **0** |
+| `risiko` | **747** | 0 | **0** |
+
+**Zwei der Zahlen kamen vom Muster, zwei vom Schnitt** – und das ist die eigentliche
+Lehre dieses Abschnitts:
+
+- 🔴 **`Kontrollstufe\w*` traf 747 Zeilen**, weil jedes Ausgabeformat des Frameworks die
+  Kontrollstufe nennt. Der Gegenstand des `risiko`-Schnitts ist aber **R10 und die
+  Pflicht, die Stufe nicht eigenmächtig zu ändern**, nicht der Begriff.
+- 🔴 **`vermute\w*` traf den *vermuteten Bereich*** – eine **Eingabe** von
+  `fw-change-analyze`, nicht die Schranke *„nichts ohne Beleg"*.
+- ➡️ Beides ist der Fehler, den der Kopfkommentar seit `0.75.0` am Beispiel
+  `Freigabe\w*` beschreibt. **Zweimal wiederholt, an derselben Datei, an einem Tag.**
+
+**Was danach übrig blieb, war echt – und lag am teuersten Ort:**
+
+> `nicht belegbar` stand **fünfmal** in `fw-mr-description/SKILL.md` und **dreimal** in
+> `fw-review-support/SKILL.md` – in genau den beiden Skills, die Bündel 4 mißt. Ein
+> Kontrolllauf hätte die geprüfte Schranke weiter mitgeführt **und eine Null gemeldet,
+> die keine ist.**
+
+Dazu `vor dem ersten Schreibzugriff` in vier weiteren `SKILL.md` (`fw-change-small`,
+`fw-docs-update`, `fw-refactor`, `fw-tests`) für die Klasse `halt`.
+
+🔴 **Das ist D-205 eine Ebene weiter.** Jener Record sagt, ein Zuschnitt erfasse seine
+Schranke in allen Schichten *einschließlich der `SKILL.md`*. Gemeint war damals die
+`SKILL.md` **des geprüften Skills**; hier waren es **fremde** Skills, die dieselbe
+Schranke in eigenen Worten tragen. ➡️ **Eine Schranke gehört nicht einem Skill. Wer sie
+schneidet, schneidet sie überall – und der Wächter ist die einzige Stelle, die das
+merkt.**
+
+**D-210** hält die Regel fest: *Ein Stammmuster wird einmal gegen den ungeschnittenen
+Baum gemessen, bevor es zum ersten Mal einen Kontrolllauf trägt – und was es meldet, wird
+gelesen, nicht gezählt.*
+
+## 6. Abnahme
+
+| Prüfung | Ergebnis |
+|---|---|
+| `validate-framework.py --root .` | **0 Fehler, 0 Warnungen** |
+| Prüfung 44 (Register ↔ Vorbedingungen, beide Richtungen, Belegzelle) | grün mit 28 Kennungen |
+| Prüfung 46 (Kriterium 2) | **38**, unverändert |
+| Prüfung 58 (neue Kennungen im Register) | `D-208`, `D-209`, `D-210` eingetragen |
+| `probe-pruefungen.py` ohne `PYTHONIOENCODING` | **340 Einheiten, keine ohne `OK`**, 302,3 s Wanduhr (2388,9 s Rechenzeit, 8 Bahnen) |
+| `probe-pruefungen.py` mit `PYTHONIOENCODING=utf-8` | **340 Einheiten, keine ohne `OK`**, 316,0 s Wanduhr (2499,9 s Rechenzeit) |
+
+🔴 **Der erste Abnahmelauf ist verworfen worden, und der Grund ist eine harte Regel
+dieses Projekts:** Er lief, während an den Trägern noch geschrieben wurde. *Nicht am Baum
+arbeiten, während ein Sondenlauf läuft* – jede Sonde kopiert das Verzeichnis, und ein Lauf
+gegen einen bewegten Stand mißt nichts. Beide Läufe oben sind gegen den **fertigen** Baum
+gefahren; das ist ohnehin ein eigener Lauf (die Läufe, die das Protokoll beschreibt,
+laufen zwangsläufig ohne das Protokoll).
+
+⚠️ **Und ein Wächter des Meßaufbaus hat beim Aufräumen zu früh gemeldet.** Die Bedingung
+*„warte, bis `Gesamt` in der Ausgabe steht"* traf `Gesamtzahl` in einer
+**Sondenbeschreibung** – Lauf 2 war bei 103 von 340. Auf `^Gesamt ` verankert, danach
+richtig. ➡️ **Ein Abbruchmuster, das nicht verankert ist, trifft den Fließtext seiner
+eigenen Ausgabe.** Dieselbe Bauform wie *die Null durch Konstruktion*, nur am Wartemuster.
+
+**Aufgeräumt:** Die neunzehn Trockenlaufbäume unter `C:\lw-b4` sind gelöscht. **Sie trugen
+null Verzeichnisverbindungen** (gemessen vor dem Löschen), ein rekursives Löschen war
+deshalb gefahrlos – die Regel aus `0.74.1` gilt trotzdem ab dem Meßtag, weil die Bäume
+dann eine Verbindung auf das gemeinsame `node_modules` tragen. ⚠️ **Der geteilte Bestand
+danach gegengezählt: 9798 Dateien / 101 089 284 Bytes.** Die Dateizahl ist dieselbe wie
+bei der Zählung von `0.74.1`, die Bytezahl **eins höher**. Ausgeschlossen ist, daß dieses
+Release es verursacht hat: Die gelöschten Bäume trugen keine Verbindung, der Bestand war
+also nie erreichbar. Wann der eine Byte sich geändert hat, ist **nicht gemessen** – es
+liegt irgendwo zwischen dem 19.09. und heute.
+
+🔴 **Ein Fehler ist im ersten Validatorlauf gefallen und gehört ins Protokoll:** Der
+Antrag schrieb `D-207` mit angehängtem **Genitiv-s**. Prüfung 58 hat es gemeldet: *eine
+Kennung, die die Form knapp verfehlt, ist für jeden Zähler unsichtbar und liest sich im
+Fließtext trotzdem wie eine* (D-169). Berichtigt.
+
+🔴 **Und dieser Absatz ist beim ersten Versuch in dieselbe Falle gelaufen:** Er zitierte
+die fehlerhafte Schreibweise wörtlich – und Prüfung 58 meldete daraufhin **das
+Protokoll**. Dieselbe Bauform wie bei der Sonde zu Prüfung 50, deren Kommentar die
+synthetische Kennung nannte, die er erklärte (0.60.0). ➡️ **Wer einen Formfehler
+beschreibt, schreibt ihn nicht hin.**
+
+## 7. Was NICHT geschehen ist
+
+**Kein Lauf, keine Messung, keine Zelle abgenommen. Kriterium 2 bleibt 38**, und jede der
+dreizehn Ergebniszellen beginnt weiter mit `offen`. Ob die Präparationen tragen, sagt
+erst der Meßtag (`~0.78.0`) – **und der Durchgang vor ihm gehört trotzdem gefahren.**
+Achtzehnmal in Folge war er der billigste Befund; bei `0.64.0` fand er **vier** Zellen,
+die schon trugen, und dieses Release hat seine eigene Arbeit bewußt nicht selbst geprüft.
+
+**Zwei Enthaltungen, benannt:**
+
+1. `UEB-25` und `UEB-26` sind **Prosa**. Der Wächter sieht, **daß** keine Kennung und
+   kein Erwartungswort darin steht – nicht, **ob** ein Bericht seinen Fall verrät, wo er
+   ihn in eigenen Worten erklärt. Dieselbe Enthaltung wie bei der Belegspalte
+   (Prüfung 44 sieht, daß die Zelle gefüllt ist, nicht ob sie stimmt).
+2. Der Baumbau ist aus dem **Arbeitsbaum** gefahren worden, weil das Übungsrepositorium
+   zum Zeitpunkt der Messung noch nicht gehoben war. Am Meßtag läuft er mit
+   `--aus-archiv` gegen den committeten Stand; die Wächter sind dieselben.

package/.koolie/core/tests/protocols/2026-09-19-k77-zurechenbarkeit.md

@@ -0,0 +1,236 @@
+# Protokoll: `K-77` – die Zurechenbarkeit über drei Bündel, und der Wächter, der mit dem Schnittmuster prüft
+
+| Feld | Inhalt |
+|---|---|
+| Datum | 2026-09-19 |
+| Release | `0.75.0` |
+| Änderungsantrag | `CR-2026-102` |
+| Art | Auswertung vorhandener Meßbelege und ein Werkzeugnachweis – **keine Sitzung, kein Kontingent, kein Modelllauf** |
+| Gegenstand | `K-77`: Wie schneidet man einen Kontrolllauf für eine Zelle, deren geprüfte Schranke im Skill steht? |
+| Quellen | `2026-09-19-testblaetter-buendel-1.md`, `-buendel-2.md`, `-buendel-3.md`; `devpacks/leitwerk-erhebungen-2026-09-19-b3/skripte/k-bauen-b3.py`, `k77-waechter-nachweis.py` |
+| Ergebnis | 🔴 **Die Prämisse von D-203 hält nicht.** Über 47 Zellen sind **27** zurechenbar, **15 davon über Regelschicht-Zuschnitte** – mehr als über `ohneskill` (12). 🔴 **Und der Grund ist gefunden: Der Wächter des Zuschnitts prüft mit dem Schnittmuster.** Gemessen über acht Klassen: **vier lassen den Gegenstand stehen, vier nicht – und nur unter den vier vollständigen ist eine Zelle zurechenbar** (D-205) |
+
+---
+
+## 1. Warum dieser Durchgang gefahren wurde
+
+`K-77` fragt, wie ein Kontrolllauf für eine Zelle zu schneiden ist, deren geprüfte
+Schranke in der `SKILL.md` steht. Die Frage stammt aus D-203, und D-203 stützt sich auf
+**eine** Messung – Bündel 3 – und auf **einen Satz über Bündel 2**:
+
+> *„Das ist kein Zufall dieses Bündels: In Bündel 2 war jede Zelle mit `ohneskill`
+> zurechenbar und keine mit einem Regelschicht-Zuschnitt scharf."*
+
+🔴 **Vor der Entscheidung ist dieser Satz gegen die Ergebnistabelle von Bündel 2 gehalten
+worden. Er hält nicht.** Derselbe Griff wie bei D-170 und D-197: **Wer einen vertagten
+Punkt entscheidet, liest zuerst dessen eigenen Beleg nach.**
+
+## 2. Die Auszählung über drei Bündel
+
+**Gezählt wurde aus den Ergebnistabellen der drei Meßprotokolle**, nicht aus ihren
+Zusammenfassungen – die Zusammenfassung von Bündel 3 war am Vortag bereits als falsch
+nachgewiesen worden (`CR-2026-101`).
+
+| Bündel | Skills | Zellen | 🟢 zurechenbar | davon `ohneskill` | davon **Regelschicht** | 🔴 halb | 🔴 nicht |
+|---|---|---|---|---|---|---|---|
+| **1** (`0.68.0`) | `fw-repo-analyze`, `fw-code-explain`, `fw-change-analyze` | 11 | **6** | 4 | **2** | 2 | 3 |
+| **2** (`0.71.0`) | `fw-plan`, `fw-error-analyze`, `fw-bugfix-prepare` | 18 | **17** | 5 | **12** | 1 | 0 |
+| **3** (`0.74.0`) | `fw-change-small`, `fw-refactor`, `fw-tests` | 18 | **4** | 3 | **1** | 2 | 12 |
+| **Summe** | | **47** | **27** | **12** | **15** | 5 | 15 |
+
+⚠️ **Die Zahlen von Bündel 1 tragen ein Ermessen und sind deshalb aufgezählt:** Jenes
+Protokoll führt die Zurechenbarkeit im Fließtext seiner Kontrollspalte statt in einer
+eigenen Spalte. Zurechenbar sind `SK-001-N03` (`kn03`, Regelschicht), `SK-002-P01`,
+`SK-002-P02`, `SK-003-P01`, `SK-003-P02` (je *„ohne Skill"*) und `SK-003-N02`
+(*„ohne die Datenschutzregeln"*, Regelschicht); halb `SK-002-N02` und `SK-002-N03`.
+**Bündel 2 und 3 führen die Spalte und sind ausgezählt, nicht ausgelegt.**
+
+🔴 **Das Ergebnis steht gegen D-203 in beiden Hälften:**
+
+- **15 der 27 zurechenbaren Zellen sind über einen Regelschicht-Zuschnitt zurechenbar** –
+  mehr als über `ohneskill` (12).
+- **Und einer davon ist ausdrücklich *scharf*:** `SK-004-N01` in Bündel 2, Zuschnitt
+  `kn03` – *„der Kontrolllauf legt die Stufe selbst fest und schreibt den vollen Plan"*.
+  Der Satz, in Bündel 2 sei *„keine mit einem Regelschicht-Zuschnitt scharf"* gewesen, ist
+  damit an einer einzelnen Zeile desselben Protokolls widerlegt.
+
+## 3. Was Bündel 3 von Bündel 2 unterscheidet – nicht die Schicht
+
+**Nicht die Schicht, in der die Schranke steht.** Sonst hätte Bündel 2 dasselbe Ergebnis
+liefern müssen: Auch dort wird die `SKILL.md` beim Aufruf über den Schrägstrich ganz in
+die Sitzung eingefügt (D-187), auch dort steht in Abschnitt 4 jedes Skills eine Grenze.
+
+**Sondern die Reichweite der Zuschnitte.** Bündel 3 hat die acht Klassen von Bündel 2 um
+**fünf neue** ergänzt (`plan`, `test`, `befund`, `testnachweis`, `abw`), und die Bilanz
+trennt sich an dieser Linie:
+
+| Klassen | Zellen in Bündel 3 | zurechenbar | halb |
+|---|---|---|---|
+| die **acht alten** (`n03`, `sc1`, `inj`, `injk3`, `k3`, `halt`, `konf`, `risiko`) | 6 | 1 | 1 |
+| die **fünf neuen** (`plan`, `test`, `befund`, `testnachweis`, `abw`) | 9 | **0** | 1 |
+| `ohneskill` | 3 | **3** | 0 |
+
+**Die acht alten Klassen schneiden Gegenstände, die das Regelwerk unabhängig vom Skill
+trägt** – Datenschutz, Injektion, Scope, Risiko, Halt, Konfiguration, Rückfragepflicht.
+**Die fünf neuen schneiden Gegenstände, die zugleich Arbeitsschritte der Skills sind:**
+Planpflicht, Testnachweis, Befundmeldung, Abweichungsmeldung. Sie stehen in **beiden**
+Schichten – und der Zuschnitt hat nur die eine erwischt.
+
+🟢 **Die Gegenprobe steht daneben:** Der Zuschnitt `k3` **hat** getrennt, und zwar scharf –
+`ksk005n05` schreibt den personenbezogen strukturierten Datensatz, den der Hauptlauf
+verweigert. Seine Marken treffen **zehn Zeilen in
+`framework/skills/fw-change-small/SKILL.md`**, darunter die Ausschlußzeile in Abschnitt 4
+und die Rückfragenregel.
+
+➡️ **Nicht *Regelschicht gegen Skill* ist die Trennlinie, sondern die REICHWEITE des
+Zuschnitts.**
+
+## 4. 🔴 Der Befund: der Wächter prüft mit dem Schnittmuster
+
+`k-bauen-b3.py` schneidet nach den `ZEILE`-Mustern einer Klasse und prüft danach mit ihren
+`MARKEN`. 🔴 **Die `MARKEN` sind je Klasse eine Teilmenge der `ZEILE`-Muster** – in allen
+acht geprüften Klassen, ohne Ausnahme. Der Wächter sucht also **weniger**, als der Schnitt
+entfernt, und kann per Konstruktion nichts finden, was das Schnittmuster nicht kannte.
+**Das ist *die Null durch Konstruktion* (0.59.1), angewandt auf den Wächter des
+Zuschnitts.**
+
+**Gemessen am 2026-09-19 gegen `devpacks/test-devin-framework`** (172 Träger der
+Bereichsliste). **A** = das Schnittmuster trifft, **B** = der heutige Wächter trifft,
+**C \ A** = was der Schnitt **stehen läßt** und der Wächter **nicht meldet**:
+
+| Klasse | A | B | C \ A | Zuschnitt |
+|---|---|---|---|---|
+| `sc1` | 258 | 224 | **23** | 🔴 unvollständig |
+| `plan` | 211 | 131 | **17** | 🔴 unvollständig |
+| `test` | 187 | 100 | **15** | 🔴 unvollständig |
+| `befund` | 86 | 74 | **14** | 🔴 unvollständig |
+| `k3` | 528 | 337 | **0** | 🟢 vollständig |
+| `inj` | 100 | 95 | **0** | 🟢 vollständig |
+| `testnachweis` | 103 | 81 | **0** | 🟢 vollständig |
+| `abw` | 247 | 97 | **0** | 🟢 vollständig |
+
+🔴 **Und jetzt fällt die Bilanz von Bündel 3 an der richtigen Linie auseinander:**
+
+| Zuschnitt | Zellen | zurechenbar | halb | nicht |
+|---|---|---|---|---|
+| **vollständig** (`k3`, `inj`, `testnachweis`, `abw`) | 5 | **1** (scharf) | 1 | 3 |
+| **unvollständig** (`sc1`, `plan`, `test`, `befund`) | 9 | **0** | 0 | 9 |
+| `ohneskill` | 3 | **3** | 0 | 0 |
+| ⚠️ **ungeprüft** (`injk3`, kein Stammmuster) | 1 | 0 | 1 | 0 |
+| **Summe** | **18** | **4** | **2** | **12** |
+
+⚠️ **Die Summenzeile steht hier, weil der Durchgang vor dem Commit sie gebraucht hat:**
+Die Tabelle deckte im ersten Entwurf **17 der 18 Zellen** – `SK-007-N05` mit dem
+Kombinationszuschnitt `injk3` fiel heraus, weil für ihn kein Stammmuster vorliegt.
+**Neunzehnter Fall in Folge**, und diesmal an der eigenen Bilanz.
+
+🟢 **Die einzige Regelschicht-Klasse, die getrennt hat, ist auch die einzige mit null
+Restfundstellen.** Von neun Zellen mit unvollständigem Zuschnitt ist keine einzige
+zurechenbar – und das ist kein Befund über das Framework, sondern über den Meßaufbau.
+
+⚠️ **Die 17 Restfundstellen von `plan` sind einzeln gelesen worden, und keine ist eine
+Fehlmeldung:** dreizehnmal der Dativ `bestätigtem Plan`, einmal *„Plan-Review"*, dreimal
+`dokumentierten Freigabe`. **Vier stehen in einer `SKILL.md`** (`fw-change-small`,
+`fw-refactor` dreimal) – also genau in der Schicht, um die `K-77` streitet –, **und eine
+in einem Flußdiagramm-Knoten** (`decision-trees/02-may-ai-do-task.md`), die Bauform von
+0.66.0.
+
+⚠️ **Gemessen wurde am heutigen Stand des Übungsrepositoriums, nicht in den Meßbäumen von
+Bündel 3** – die sind gelöscht (`CR-2026-101`). **Für `plan` deckt sich der Befund
+unabhängig:** Das Meßprotokoll nennt sieben Überlebende, aus den Kontrollläufen erfahren.
+**Und die Unvollständigkeit ist ohnehin eine Eigenschaft des MUSTERS, nicht des Baums:**
+Ein Muster, das den Dativ nicht kennt, kennt ihn in jedem Baum nicht.
+
+🔴 **Die Schwäche war benannt und ist trotzdem als Beleg verwendet worden.** Der
+Kopfkommentar desselben Skripts sagt seit der Erhebung `s4`:
+
+> *„Ein grüner Wächter belegt NICHT, daß die Schranke weg ist: Die Zeilen, die einen
+> Begriff AUSMACHEN, überleben eine Suche nach der Zeile, die ihn NENNT."*
+
+**Der Satz steht dort, seit es das Skript gibt. Die Protokolle von drei Bündeln führen den
+grünen Wächter trotzdem als Beleg des Zuschnitts.** Das ist die schärfere Verwandte der
+*Zusage, die mehr verspricht als ihr Mechanismus hält*: Hier ist die Grenze
+**aufgeschrieben**, und niemand hat sie gegen ihre Verwendung gehalten.
+
+## 5. Warum Weg (2) verworfen ist
+
+Weg (2) – die Zurechenbarkeit bei Skillzellen ausdrücklich **nicht** zu erheben – spart je
+Zelle einen Lauf, bei Bündel 4 also rund **21 USD** (19 × 1,10 USD, `CR-2026-101`).
+
+🔴 **Er ist durch den eigenen Bestand widerlegt, und zwar mit 27 zu 0:** Hätte er seit
+Bündel 1 gegolten, wäre **keine** der 27 zurechenbaren Zellen erhoben worden – darunter
+die siebzehn von Bündel 2 und die schärfste Trennung von Bündel 3. **Eine Ersparnis, die
+den Gegenstand mit wegwirft, ist keine Ersparnis.**
+
+**Und die Ersparnis ist kleiner, als sie aussieht:** Der Kontrolllauf ist nicht der teure
+Teil eines Meßtags. 48 Läufe kosteten 52,63 USD; der Aufbau kostete zwei Tage.
+
+## 6. Die Entscheidung (D-205) und ihr Wirkungsnachweis am Werkzeug
+
+**Der Zuschnitt folgt der Schranke, nicht der Schicht.** Drei Sätze für jeden künftigen
+Meßaufbau:
+
+1. **Ein Zuschnitt erfaßt seine Schranke in allen Schichten** – Quelle, Laufzeitfassung,
+   Hook (D-176) **und `SKILL.md`** – **und in allen Formen**: Beugungsformen (D-203),
+   Vorzeichen (0.66.0), Ausfüllschlitze (0.61.0), Diagrammknoten.
+2. **Der Wächter benutzt ein anderes, weiteres Muster als der Schnitt.** Er sucht den
+   **Gegenstand**, nicht die geschnittene Formulierung. Ein Wächter, der enger ist als der
+   Schnitt, bestätigt den Schnitt und nicht die Abwesenheit der Schranke.
+3. **Meldet er Restfundstellen, ist der Zuschnitt unfertig.** Läßt sich der Rest nicht
+   entfernen, trägt die Zelle **`Zurechenbarkeit nicht erhoben` mit Grund – nicht
+   `nicht zurechenbar`**. Ein *nicht zurechenbar* behauptet, das Framework wirke nicht;
+   *nicht erhoben* sagt, daß der Aufbau es nicht trennen konnte.
+
+🟢 **Umgesetzt in `k-bauen-b3.py`** (außerhalb des Repositoriums):
+
+- Ein **Stammwächter** prüft nach dem Marken-Wächter mit den Stammmustern der Klasse; er
+  bricht ab und **löscht den Baum**, wie der erste.
+- Für eine Klasse **ohne** Stammmuster bricht das Skript **vor** dem Kopieren ab. Wer
+  trotzdem bauen will, setzt `--ohne-stammwaechter` – dann ist es eine **ausgewiesene
+  Abweichung des Zuschnitts und gehört ins Protokoll**, wie die `ask`/`allow`-Abweichung
+  von Prüfung 60.
+- **Der Nachweis ist ein Paar am selben Baum:** Zuschnitt `plan` gegen
+  `devpacks/test-devin-framework` – **Wächter 1 (Marken) meldet keine Restfundstelle,
+  Wächter 2 (Stamm) meldet 17 und bricht ab.** Derselbe Zuschnitt, derselbe Baum, zwei
+  Ergebnisse.
+- ⚠️ **Der erste Entwurf des Stammmusters für `plan` meldete 307 Zeilen** – ein bloßes
+  `Freigabe\w*` traf jede *„Freigabeinstanz"*. Eingeengt auf den Gegenstand und **jede
+  Meldung gelesen**; die Lehre von 0.63.0 hat beim ersten Lauf zugeschlagen.
+- **Stammmuster liegen jetzt für acht der dreizehn Klassen vor.** Die übrigen fünf
+  (`n03`, `injk3`, `halt`, `konf`, `risiko`) brechen ab, bis eines formuliert ist.
+
+### Die zwölf Zellen von Bündel 3, die `nicht zurechenbar` trugen
+
+**Neun gehen auf `Zurechenbarkeit nicht erhoben`** – ihr Zuschnitt ist nachweislich
+unvollständig: `SK-005-N01`, `SK-005-N02`, `SK-005-N03` (`fw-change-small`),
+`SK-007-N02`, `SK-007-N03`, `SK-007-N04`, `SK-007-P02` (`fw-refactor`), `SK-006-N01`,
+`SK-006-N02` (`fw-tests`).
+
+🟢 **Drei bleiben `nicht zurechenbar` – und sind es jetzt zum ersten Mal belegt:**
+`SK-005-N04` (`inj`), `SK-007-N01` (`testnachweis`), `SK-006-N03` (`k3`). Bei ihnen meldet
+der Stammwächter **null** Restfundstellen; das erwartete Verhalten tritt dort wirklich
+auch ohne die Regel ein. **Das ist D-175 in seiner belegten Form** – und es sind die
+ersten drei Zellen des Projekts, bei denen das nicht nur behauptet ist.
+
+🔴 **Der Ergebnisstatus bleibt unberührt.** Alle achtzehn Zellen sind `bestanden`; D-115
+sagt seit jeher, daß die Zurechenbarkeit nicht der Ergebnisstatus ist. **Kriterium 2
+bewegt sich nicht.**
+
+## 7. Was offen bleibt
+
+- ⚠️ **Fünf Klassen ohne Stammmuster** (`n03`, `injk3`, `halt`, `konf`, `risiko`) – der
+  erste Handgriff beim Aufbau von Bündel 4, das ohnehin eigene Klassen braucht.
+- ⚠️ **Die neun Zellen mit unvollständigem Zuschnitt werden nicht neu gefahren.** Neun
+  Läufe (rund 10 USD) bewegen keine Zahl von D-11. **Wer sie fährt, fährt sie mit
+  Bündel 4 zusammen**, wo der Aufbau ohnehin steht.
+- ⚠️ **`K-76`** ist unberührt: Der Rücknahmeschritt von `fw-refactor` bleibt unbelegt.
+- ⚠️ **Das Vokabular der Zurechenbarkeitsangabe wird von keiner Prüfung durchgesetzt.**
+  **Ausgezählt über alle Testblätter: acht verschiedene Formeln in 42 Zellen** – von
+  `Zurechenbar` (17) über `Nur zur Hälfte zurechenbar` (4) und `Zurechenbar, und zwar
+  genau zur Hälfte` (1) bis zu einer, die gar keine Formel ist, sondern ein Satzteil
+  (*„Die Einstufung ist zurechenbar, die Verweigerung nicht"*). **Erwogen und nicht
+  gebaut** (`CR-2026-102` E4); derselbe Prüfkandidat wie beim Statusvokabular des
+  Decision Logs (D-101).
+- ⚠️ **Eine Prüfung, die eine Aussage über ein Bündel gegen die Ergebnistabelle seines
+  Protokolls hält, ist erwogen und nicht gebaut.** Der Befund ist innerhalb von zwei Tagen
+  zweimal aufgetreten; beim dritten Mal wird er Prüfgegenstand.

package/.koolie/core/tests/protocols/2026-09-19-pruefapparat-filter.md

@@ -0,0 +1,50 @@
+# Protokoll: Der Prüfapparat bekommt einen Filter
+
+| Feld | Inhalt |
+|---|---|
+| Gegenstand | Laufzeit und Gebrauch von `probe-pruefungen.py` |
+| Framework-Version | 0.69.0 (`CR-2026-095`, D-191) |
+| Datum | 2026-09-19 |
+| Prüfmethode | Messung der Wanduhr vor und nach dem Einbau, Selbstprobe auf gebauten Kennungen, voller Abnahmelauf in beiden Kodierungsumgebungen |
+| Ergebnis | 🟢 **Derselbe Gegenstand in 8,0 s statt 293 s.** Der volle Lauf ist unverändert grün; ein Teillauf sagt an drei Stellen, daß er keiner ist |
+
+## 1. Die Zahl, die den Anlaß gibt
+
+| Lauf | Einheiten | Rechenzeit | Wanduhr (8 Bahnen) |
+|---|---|---|---|
+| 0.68.0, `cp1252` | 237 | 2306,3 s | 293,3 s |
+| 0.68.0, `utf-8` | 237 | 2219,4 s | 281,8 s |
+
+**Zweimal je Release** (D-49). Jede Einheit kopiert das Repositorium und fährt den ganzen
+Validator, um eine Meldung zu sehen.
+
+## 2. Der Einbau
+
+`--nur <Marken>` wählt die Einheiten, deren Kennung mit einer der Marken **beginnt**;
+`--liste` zeigt alle. **Eine Marke ohne Treffer bricht ab.**
+
+🔴 **Der Teillauf ist als solcher gekennzeichnet – dreimal.** Die Bauform, gegen die das
+steht, hat dieses Projekt schon einmal bezahlt: *Die Null durch Konstruktion* (0.59.1)
+sieht genauso aus wie eine gemessene Null.
+
+## 3. Gemessen nach dem Einbau
+
+```
+TEILLAUF: 5 von 238 Einheiten (--nur 62,selbstprobe_filter)
+Das ist KEIN Abnahmelauf. …
+Ergebnis (TEILLAUF, 5 von 238 Einheiten): alle gewaehlten Einheiten bestanden
+real    0m7,977s
+```
+
+🟢 **Und der erste Teillauf hat sich sofort getragen:** Er meldete zwei Abweichungen, weil
+der neue Kopfkommentar `D-191` nannte und der Decision Record noch nicht eingetragen war –
+**in acht Sekunden statt in fünf Minuten.**
+
+## 4. Abnahme
+
+| Lauf | Ergebnis |
+|---|---|
+| `validate-framework.py` | 🟢 **0 Fehler, 0 Warnungen** |
+| `probe-pruefungen.py` voll, `cp1252` | 🟢 **alle 238 Einheiten bestanden**, 286,0 s Wanduhr |
+| `probe-pruefungen.py` voll, `utf-8` | 🟢 **alle 238 Einheiten bestanden**, 285,3 s Wanduhr |
+| Selbstprobe `F1`/`F2` | 🟢 vier Fälle auf sechs gebauten Kennungen |