@renoxar/koolie 1.25.0

package/.koolie/core/tests/protocols/2026-09-15-gegenpruefung-strukturentscheidungen.md

@@ -0,0 +1,392 @@
+# Gegenprüfung: die neun Strukturentscheidungen D-01 bis D-08 und D-10
+
+| Feld | Inhalt |
+|---|---|
+| Datum | 2026-09-15 |
+| Framework-Version | `0.48.0` (Stand `main`, Commit `4f5dc93`); umgesetzt mit `0.49.0` |
+| Gegenstand | Die neun Decision Records D-01 bis D-08 und D-10, sämtlich seit dem 2026-09-01 auf `entschieden (Vorschlag)` |
+| Anlass | Arbeitspaket `AP3` der Roadmap (P1), Aktivität *„Beschluss offener Strukturentscheidungen (D-01…D-10 bestätigen)"*; Kriterium 4 von D-11 |
+| Antrag | `CR-2026-071`, D-100, D-101 |
+| Prüfmethode | Dokumentenanalyse mit **Messung am Bestand**: Je Record wird die Begründung von 2026-09-01 gegen den heutigen Bestand gehalten, und der Beleg ist ein abgezählter oder aus der Datei gelesener Wert, keine Lektüre. Dazu die Auflösung der drei Einwände aus `CR-2026-019` gegen ihren jeweiligen Gegenstand |
+| Ausgeführte Befehle | Ein Messskript über `framework/`, `clients/`, `governance/` (Ausgabe in Abschnitt 3 unverändert); `_d11_zaehlen()` aus `tests/scripts/validate-framework.py` direkt aufgerufen; die Zellenzerlegung des Validators über beide Tabellen des Decision Logs |
+| Ergebnis | **Alle neun bestätigungsreif.** Bei acht trägt die Begründung von 2026-09-01 unverändert, bei D-08 trägt die Entscheidung auf einem anderen Grund. **Die drei Einwände aus `CR-2026-019` richten sich sämtlich gegen etwas anderes als die Entscheidung, gegen die sie vorgebracht sind** – zwei gegen Bedingungen, die D-11 ausdrücklich ausnimmt |
+
+## 1. Warum diese Gegenprüfung anders fragt als die übrigen
+
+D-23 verlangt die Gegenprüfung **vor** der Umsetzung eines Befundes. Hier ist der
+Gegenstand kein Befund, sondern eine **Bestätigung**. Die Frage lautet deshalb nicht
+„stimmt der Befund?", sondern:
+
+> **Trägt die Begründung von 2026-09-01 heute noch – und woran ist das gemessen?**
+
+Das ist eine schärfere Frage als „hat jemand widersprochen?". Eine Entscheidung, die
+niemand angefochten hat, kann trotzdem auf einer Begründung stehen, die ihren Gegenstand
+verloren hat. **Bei einem der neun ist genau das eingetreten** (D-08, Abschnitt 4).
+
+**Was diese Gegenprüfung ausdrücklich nicht behauptet:** dass sich nichts geändert hätte.
+Acht der neun sind mit `CR-2026-019` fortgeschrieben worden, weil sie einen Stand
+beschrieben, den es nicht mehr gab. Bestätigt wird die **Entscheidung**, nicht der
+Wortlaut von damals.
+
+## 2. Der Vorlauf: eine Vorlage, zweiunddreißig Releases unbeantwortet
+
+| Datum | Release | Vorgang |
+|---|---|---|
+| 2026-09-01 | 0.1.0 | D-01 bis D-10 niedergeschrieben, sämtlich `entschieden (Vorschlag)` |
+| 2026-09-10 | 0.16.0 | D-11 setzt Kriterium 4: kein Record mehr auf `entschieden (Vorschlag)` |
+| 2026-09-10 | 0.17.0 | `CR-2026-019` schreibt acht der zehn fort und **legt den Statuswechsel je Record vor**. Sieben ohne Einwand, drei mit einem benannten. Die Entscheidung selbst fällt ausdrücklich nicht |
+| 2026-09-15 | 0.48.0 | Prüfung 46 zählt Kriterium 4 zum ersten Mal richtig: **9**, nicht 16 |
+| 2026-09-15 | 0.49.0 | **dieser Vorgang** |
+
+**Die Vorlage von `CR-2026-019` steht bis heute als offener Haken in dessen Abschnitt 7.**
+Zwischen 0.17.0 und 0.48.0 liegen **zweiunddreißig Releases**. In keinem davon ist über
+sie entschieden worden – und in jedem einzelnen war der Validator grün.
+
+**Das ist der Befundtyp dieses Repositoriums an einer neuen Stelle.** Sonst ist es *eine
+Zusage, die mehr verspricht, als sie leistet*. Hier ist es **eine Bedingung, die mehr
+verlangt, als ihr Kriterium fordert** – siehe Abschnitt 5. Eine solche Bedingung hält
+genauso zuverlässig auf, wie eine zu schwache Zusage durchlässt, und sie fällt keiner
+Prüfung auf, weil ein unbeantworteter Haken in einem abgeschlossenen Antrag kein
+Prüfgegenstand ist.
+
+## 3. Die Messung am Bestand (unveränderte Ausgabe)
+
+```
+=== D-01: Stufen der Prioritaetshierarchie ===
+Stufen: ['1', '2', '3', '4', '5', '6', '7', '8']
+org-policies: ['MAPPING_CLASSIFICATION.md', 'README.md']
+
+=== D-02: Client Packs mit manifest.json ===
+  _template manifest.json: False
+  claude-code manifest.json: True
+  devin-desktop manifest.json: True
+
+=== D-03: Skills und ihre Dateien ===
+  Skills gesamt: 13, davon genau die vier Dateien: 13
+
+=== D-04: permissions.json ===
+  deny: 53
+  ask: 5
+  allow: 19
+  _core_rules_integrity erzeugt in clientmap.py: True
+  deny_must_contain im Validator: 3
+
+=== D-05: Agentenprofile ===
+  fw-reviewer.md: permissionMode gesetzt: False
+
+=== D-06: Verschaerfungsprinzip ===
+  Regel 2.1 vorhanden: True
+  Regeln in Abschnitt 2: 6
+
+=== D-07: Kontextklassen ===
+  Klassen: ['K0', 'K1', 'K2', 'K3']
+  Abschnitt 1.3 restriktivste Auslegung: True
+  Regel 2.2.3 'Fehlt eine Einstufung, gilt K3': True
+  Abschnitt 1.2 organisationsspezifisch: True
+
+=== D-08: Steckbriefzeilen im Kern ===
+  Prüfung 46 zaehlt jetzt: [29, 118, 69, 9]
+
+=== D-10: MCP ===
+  Dateien in framework/runtime: ['agents', 'hooks.json', 'mcp-config.example.json',
+  'permissions.json', 'root-instruction-local.example.md', 'root-instruction.md', 'rules']
+  MCP-Regeln: [('ask', {'tool': 'mcp', 'pattern': '*'})]
+```
+
+**Zum letzten Block, weil er der wichtigste ist:** `framework/runtime/` liefert genau
+**eine** MCP-Datei aus, und sie heißt `.example.json`. Es gibt keine wirksame
+MCP-Konfiguration im Kern, und die einzige MCP-Regel der Berechtigungsdatei steht in
+`ask`. Das ist der Mechanismus hinter D-10 – siehe Abschnitt 5.3.
+
+## 4. Urteil je Record
+
+### D-01 – Ebenenmodell
+
+**Begründung 2026-09-01:** *Vorgabe des Auftrags; Ebenen B und E sind für Separation of
+Concerns erforderlich.*
+
+**Trägt.** Die Prioritätshierarchie führt genau acht Stufen (gemessen, Abschnitt 3); Ebene
+B steht dort als Stufe 2 und hat unter `framework/org-policies/` einen Einbindungspunkt
+mit zwei Dateien, Ebene E als Stufe 8. Die Fortschreibung aus `CR-2026-019` – die Zählung
+„vier plus zwei" meint die **Regelebenen**, die Hierarchie zählt acht Stufen, weil die
+Skills als Ebene 7 dazwischenstehen – beschreibt den Bestand richtig.
+
+**Ehrlich zur Alternative:** „Drei Ebenen ohne Packs" ist durch **zwei** Role Packs
+praktisch widerlegt. Von den beiden Packebenen ist damit **eine besetzt**; ein Technology
+Pack liegt bisher nur als Vorlage vor. Das ist eine Aktivität von `AP4` (*„erstes
+Technology Pack für `<TECH_STACK>` erstellen"*) und keine Frage an das Ebenenmodell: Eine
+Ebene, für die es eine Vorlage, eine Rangposition und eine Zuständigkeitsregel gibt, ist
+vorgesehen, auch wenn sie noch leer ist.
+
+### D-02 – Lang- und Laufzeitform
+
+**Begründung 2026-09-01:** *Tool Independence und Least Context; die Laufzeitform verweist
+auf die Langform.*
+
+**Trägt, und sie ist heute stärker als damals.** 2026-09-01 war die werkzeugneutrale Naht
+eine Absicht; D-12 bis D-14 haben sie benannt und **maschinenlesbar** gemacht. Beide
+ausgelieferten Client Packs führen ein `manifest.json` (gemessen), aus dem `install.py`
+und der Validator die Pfade lesen, statt sie zu verdrahten. Ein Pack ohne Manifest gilt
+als nicht installierbar.
+
+### D-03 – Vier-Dateien-Struktur je Skill
+
+**Begründung 2026-09-01:** *Trennung normativ/erläuternd; Least Context (Beispiele werden
+nicht bei jedem Aufruf geladen).*
+
+**Trägt, und beide Hälften sind belegt.** Die Struktur: **13 von 13** Skills tragen genau
+`SKILL.md`, `EXAMPLES.md`, `TESTS.md`, `CHANGELOG.md` – abgezählt über den Baum, nicht über
+eine Liste. Der Least-Context-Teil ist seit dem 2026-09-12 nicht mehr nur Absicht: Damals
+führte eine Sitzung von zwölf `fw-`-Skills genau die **drei ohne** `disable-model-invocation`
+(`ERH-13`, `tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`). Am 2026-09-14 ein
+zweites Mal gemessen: **83** Einträge in der Skill-Auflistung, davon **drei** mit dem Präfix
+`fw-` (`tests/protocols/2026-09-14-erhebung-skillaufruf.md`). Zusage S4, zweimal belegt.
+
+> Das ist der einzige der neun, dessen Begründung eine **Wirkungsaussage** enthält – und
+> sie ist gemessen. Bei den übrigen acht sind die Begründungen Strukturaussagen, die sich
+> am Bestand abzählen lassen.
+
+### D-04 – Berechtigungsdatei, restriktiver Standard
+
+**Begründung 2026-09-01:** *Secure by Default.*
+
+**Trägt, und sie ist seit D-18 geprüft statt zugesagt.** `framework/runtime/permissions.json`
+führt **53** `deny`-, **5** `ask`- und **19** `allow`-Regeln – das Verhältnis ist die
+Entscheidung. Die Kernzusagen werden als `_core_rules_integrity.deny_must_contain` aus
+derselben Quelle erzeugt (`clientmap.py`, gemessen) und vom Validator an drei Stellen
+gegen sie gehalten. Eine Installation, in der eine Kernregel fehlt, ist rot.
+
+### D-05 – Berechtigungsmodi
+
+**Begründung 2026-09-01:** *Human Accountability, Review before Adoption.*
+
+**Trägt.** Einwand `AP2-CC-12` – Abschnitt 5.1.
+
+### D-06 – Prioritätshierarchie und Verschärfungsprinzip
+
+**Begründung 2026-09-01:** *Auflösung des Zielkonflikts zwischen „Core über Overlay" und
+„Overlay definiert projektspezifische Parameter".*
+
+**Trägt.** Das Verschärfungsprinzip ist Regel 2.1 von `PRIORITY_HIERARCHY.md` (gemessen);
+Abschnitt 2 führt inzwischen **sechs** ergänzende Regeln, ohne die die Hierarchie
+widersprüchlich wäre – die sechste ist mit D-34 dazugekommen, für eine Quelle, die keine
+der acht Ebenen führt. Seit D-18 ist das Prinzip an der Stelle, an der die Kernzusagen
+hängen, eine **geprüfte Eigenschaft**: Die Semantikabbildung lässt die Installation
+scheitern, wenn eine `deny`- oder `ask`-Regel kein Zielwerkzeug hat, und untersagt bei
+`allow` jede Verbreiterung.
+
+**Der Zielkonflikt, den die Begründung nennt, ist als Befund 3 in Abschnitt 3 desselben
+Moduls ausbuchstabiert** und dort aufgelöst. Die Begründung verweist damit auf einen Text,
+den es gibt – das ist bei einer vierzehn Tage alten Begründung nicht selbstverständlich
+und bei acht ihrer Geschwister mit `CR-2026-019` nachzuziehen gewesen.
+
+### D-07 – Kontextklassen K0 bis K3
+
+**Begründung 2026-09-01:** *Operationalisierbarkeit statt abstrakter Regeln.*
+
+**Trägt.** Die vier Klassen stehen in `framework/core/02-privacy.md` Abschnitt 2
+(gemessen), seit D-24 vollständig auch in der Laufzeitschicht – eine normative Liste, die
+nur in der Langform steht, wirkt nicht. Einwand `K-20` – Abschnitt 5.2.
+
+### D-08 – Framework-Metadaten als Tabelle im Dateikörper
+
+**Begründung 2026-09-01:** *Toleranz unbekannter Frontmatter-Schlüssel nicht belegt.*
+
+**Die Entscheidung trägt. Die Begründung trägt nicht mehr – für einen der beiden Clients.**
+Das ist der einzige Sonderfall unter den neun, und er gehört benannt statt geglättet.
+
+| Client | Lage 2026-09-01 | Lage heute |
+|---|---|---|
+| `claude-code` | Toleranz unbelegt → Vorsichtsannahme | **geklärt** (K-18): Die Herstellerdokumentation zählt die Felder je Artefaktart abschließend auf, und die Abbildung erzeugt seit D-26 und D-27 **nur** dokumentierte Felder. Ein Metadatenfeld im Frontmatter wäre heute kein Risiko, sondern ein **undokumentiertes Feld** – Ballast ohne Durchsetzung |
+| `devin-desktop` | Toleranz unbelegt → Vorsichtsannahme | **unverändert unbelegt.** Dort trägt die Begründung von 2026-09-01 weiter |
+
+**Dieselbe Entscheidung, zwei Gründe, je Client ein anderer.** Genau dafür gibt es die
+Fähigkeitsmatrix (D-12). Die Form selbst ist durchgehend angewendet: Die Steckbriefzeile
+`| Status | … |` steht in **69** Kerndateien – dieselben 69, die Prüfung 46 für Kriterium 3
+zählt.
+
+> **Eine Bestätigung ist keine Behauptung, dass sich nichts geändert hat.** Wo die
+> Entscheidung heute aus einem anderen Grund trägt, gehört der andere Grund
+> hingeschrieben – sonst bestätigt man einen Satz, den niemand mehr glaubt.
+
+### D-10 – Erweiterungsmodule, standardmäßig deaktiviert
+
+**Begründung 2026-09-01:** *K-04 offen; Secure by Default.*
+
+**Trägt.** Einwand `K-04` – Abschnitt 5.3.
+
+## 5. Die drei Einwände aus `CR-2026-019`
+
+`CR-2026-019` hat je Record die Spalte „Einwand gegen eine Bestätigung" geführt und sie als
+„den eigentlichen Gegenstand der Vorlage" bezeichnet. Drei Einwände stehen dort. **Alle
+drei sind gute Fragen. Keiner von ihnen ist eine Frage nach Kriterium 4.**
+
+### 5.1 `AP2-CC-12` gegen D-05 – Durchsetzungstiefe, nicht Regel
+
+**Der Einwand:** Ob die Sperre gegen den Modus ohne Rückfragen auch für das Feld
+`permissionMode` eines Subagentenprofils gilt, ist nicht dokumentiert.
+
+**Zuerst der Stand, und er ist unverändert:** Die Erhebung vom 2026-09-13 über
+Unteragenten führt die Frage ausdrücklich unter „Was diese Erhebung nicht belegt" –
+*„`permissionMode` im Profil (`AP2-CC-12`, offene Teilfrage zu M2). **Unberührt.**"*
+(`tests/protocols/2026-09-13-erhebung-unteragent.md`). Elf Läufe an jenem Tag, und keiner
+hat sie berührt. **Sie ist offen und bleibt es.**
+
+**Und sie ist kein Einwand gegen D-05.** D-05 entscheidet, dass der Modus ohne Rückfragen
+**untersagt** ist – eine Regel. `AP2-CC-12` fragt, ob ein bestimmter Client dieses Verbot
+auf einem bestimmten Weg zusätzlich **technisch** erzwingt. Dass das zwei verschiedene
+Dinge sind, ist keine Auslegung, sondern **D-12**: Jede technische Zusage wird je Client
+als `[TECHNISCH]`, `[TEXTUELL]` oder `[NICHT ABBILDBAR]` eingestuft, *weil* eine Regel auch
+dort gilt, wo die Engine sie nicht erzwingt.
+
+> **Wer eine Regel erst bestätigt, wenn jeder Client sie auf jedem Weg technisch erzwingt,
+> hat D-12 abgeschafft** – und mit ihr die Begründung, aus der die Fähigkeitsmatrix
+> überhaupt entstanden ist.
+
+**Dazu ein Messwert, der die Reichweite bemisst:** Das Framework liefert **genau ein**
+Agentenprofil aus (`framework/runtime/agents/fw-reviewer.md`), und es setzt
+`permissionMode` **nicht** (gemessen, Abschnitt 3). Die offene Frage hat in den
+ausgelieferten Artefakten keinen Träger.
+
+**Wo sie hingehört:** Die Zeile M2 des Packs `claude-code` führt sie als offene Teilfrage.
+Das ist eine Verifikationsschuld – **Kriterium 1 von D-11**, nicht Kriterium 4.
+
+### 5.2 `K-20` gegen D-07 – das Modell regelt das Fehlen selbst
+
+**Der Einwand:** K-20 – Art und Ort der Codebasis-Indexierung – ist bei `devin-desktop`
+unbelegt; *das Datenschutzmodell setzt eine Aussage darüber voraus*.
+
+**Der zweite Halbsatz ist falsch, und der Gegenbeweis steht im Modell selbst.**
+`framework/core/02-privacy.md` regelt den Fall der fehlenden Aussage ausdrücklich, an zwei
+Stellen (beide gemessen, Abschnitt 3):
+
+> **Abschnitt 1.3:** *Bis zum Vorliegen dieser Prüfung gilt die restriktivste Auslegung:
+> Nur Kontextklasse K0 und K1 dürfen bereitgestellt werden, und nur, wenn die Organisation
+> die Nutzung des Werkzeugs grundsätzlich freigegeben hat.*
+>
+> **Abschnitt 2.2 Regel 3:** *Fehlt eine Einstufung, gilt K3.*
+
+**Das Modell setzt die Aussage nicht voraus – es enthält die Regel für ihr Fehlen.** Ein
+Modell, das seinen eigenen unbeantworteten Eingabewert auffängt, wird durch dessen
+Unbeantwortetheit nicht geschwächt; es wird durch sie vorgeführt. Dass K-20 offen ist, ist
+ein Argument **für** D-07 und gegen die Alternative „Freitextregeln", die für diesen Fall
+gar keine Antwort gehabt hätte.
+
+**Dazu die Zuständigkeit:** Abschnitt 1.2 desselben Moduls erklärt die vertraglichen und
+technischen Bedingungen – Auftragsverarbeitung, Verarbeitungsorte, Aufbewahrung,
+Training-Opt-out, Zero Data Retention, **Codebasis-Indexierung** – ausdrücklich für
+**organisationsspezifisch** und verlangt sie vor der Einführung geprüft und im Overlay
+referenziert. **Das ist Aufgabe der aufnehmenden Organisation, und D-11 nimmt genau das
+aus.**
+
+**Was von K-20 übrig bleibt, ist ein VERIFY-Marker** in der Zeile X2 des Packs
+`devin-desktop` – **Kriterium 1**, nicht Kriterium 4. Ihn zur Bedingung von Kriterium 4 zu
+machen, koppelt zwei Kriterien, die D-11 getrennt aufzählt.
+
+### 5.3 `K-04` gegen D-10 – die Zusage hat ein Gegenüber, und es ist ein Mechanismus
+
+**Der Einwand:** K-04 – Nutzungsumfang Cloud/CLI – ist offen und liegt außerhalb des
+Frameworks. Solange die Organisation ihn nicht festgelegt hat, ist „vorgesehen,
+standardmäßig deaktiviert" *eine Zusage ohne Gegenüber*.
+
+**Erstens die Zuständigkeit.** K-04 nennt als entscheidende Rolle „Projektleitung mit
+Informationssicherheit" und trägt den Platzhalter `<TBD: Freigabe Cloud/CLI-Nutzung>`. Das
+ist eine **organisatorische Freigabe**, und D-11 sagt dazu einen Satz: *Pilot, Onboarding
+und organisatorische Freigabe sind **nicht** Vorbedingung, sondern Aufgabe der
+aufnehmenden Organisation.* Ein Einwand, der genau das zur Vorbedingung macht, steht gegen
+die Entscheidung, deren Kriterium er bedienen will.
+
+**Zweitens der Mechanismus, und er ist der stärkere Grund.** „Eine Zusage ohne Gegenüber"
+trifft seit 0.5.0 nicht mehr zu, und es ist nachzählbar (Abschnitt 3):
+
+- `framework/runtime/` liefert **keine** wirksame MCP-Konfiguration aus, sondern
+  ausschließlich `mcp-config.example.json`.
+- `permissions.json` stellt **alle** MCP-Werkzeuge in `ask`: `{"tool": "mcp", "pattern": "*"}`.
+
+**Die Deaktivierung ist erzeugt, nicht versprochen.** D-10 ist gerade die Entscheidung,
+die das Framework sicher hält, **solange** K-04 offen ist – sie braucht K-04 nicht
+beantwortet, sie ist die Antwort auf seine Offenheit. Ein Einwand, der ihre Bestätigung an
+K-04 bindet, hat die Richtung der Abhängigkeit umgedreht.
+
+### 5.4 Was die drei gemeinsam haben
+
+| Einwand | Richtet sich gegen | Gehört zu |
+|---|---|---|
+| `AP2-CC-12` (D-05) | die Durchsetzungstiefe **eines** Clients auf **einem** Weg | Fähigkeitsmatrix (D-12); Kriterium 1 von D-11 |
+| `K-20` (D-07) | eine **Eingabe** des Modells, deren Fehlen das Modell selbst regelt | organisatorische Prüfung; Kriterium 1 von D-11 |
+| `K-04` (D-10) | eine **organisatorische Freigabe** | aufnehmende Organisation – von D-11 ausdrücklich ausgenommen |
+
+**Alle drei bleiben offen.** Keiner wird durch diese Gegenprüfung beantwortet, und keiner
+wird für beantwortet erklärt. Sie behalten ihren Ort und ihre Frist.
+
+## 6. Nebenbefund: die Legende erklärt vier Statuswerte, die Tabellen führen sieben
+
+**Beim Abzählen der Statuszelle angefallen, nicht gesucht.** Die Legende in Zeile 4 von
+`DECISION_LOG.md` nennt vier Werte. Abgezählt mit derselben Zellenzerlegung, die der
+Validator benutzt (`tabellenzellen()`), über **99** Decision Records und die
+Klärungstabelle:
+
+| Statuswert | Vorkommen | In der Legende? |
+|---|---|---|
+| `entschieden (CR-2026-NNN)` | **89** Decision Records | **nein** |
+| `entschieden (Vorschlag)` | 9 Records, 5 Klärungspunkte | ja |
+| `ersetzt durch D-11` | 1 (D-09) | **nein** |
+| `offen by design` | 1 Klärungspunkt | **nein** |
+| `geklärt durch Auftrag` | 1 Klärungspunkt | **nein** |
+| `geklärt` / `offen` / `verify` | übrige Klärungspunkte | ja |
+
+**Der meistverwendete Statuswert des Dokuments steht nicht in seiner Legende** – seit D-11
+und neunundachtzig Records. Das ist der Befundtyp dieses Repositoriums in seiner
+Grundform: ein Verzeichnis, das seinen eigenen Bestand nicht vollständig nennt.
+
+**Berichtigt, nicht geprüft** (`CR-2026-071` E5, D-101). Eine Prüfung, die das Vokabular
+der Statuszellen gegen die Legende hält, ist baubar und wäre die richtige Abhilfe; sie ist
+hier bewusst nicht gebaut, weil der `<FRAMEWORK_OWNER>` für dieses Release angeordnet hat,
+keine neue Prüfung zu bauen, bevor sich eine der vier D-11-Zahlen bewegt. **Sie bewegt
+sich mit diesem Release.**
+
+## 7. Was diese Gegenprüfung nicht leistet
+
+- **Sie prüft nicht, ob die Entscheidungen die *besten* wären.** Sie prüft, ob ihre
+  Begründung heute trägt. Eine Bestätigung ist keine Neuverhandlung.
+- **Sie beantwortet keinen der drei Einwände.** `AP2-CC-12`, `K-20` und `K-04` bleiben
+  offen; sie werden nur ihrem richtigen Kriterium zugeordnet.
+- **Sie sagt nichts über die vier übrigen Klärungspunkte** auf `entschieden (Vorschlag)`
+  (K-12, K-13, K-17, K-18). Bei allen vieren ist ein Teil der Frage unbeantwortet; sie
+  gehören in einen eigenen Vorgang (`CR-2026-071` E4).
+- **Sie bewegt Kriterium 4 und sonst nichts.** Die Kriterien 1, 2 und 3 bleiben bei 29,
+  118 und 69. Eine Zahl von vier ist gefallen; drei stehen.
+- **Kriterium 5 bleibt unbeobachtet** – eine Feststellung, keine Zahl, ausdrückliche
+  Enthaltung seit `CR-2026-070` E8.
+
+## 8. Nachtrag zum Protokoll von `CR-2026-070`
+
+`2026-09-15-gegenpruefung-d11-zaehlregeln.md` formuliert die Zeile zum seriellen
+Abnahmelauf **vorsichtiger, als die Messung es verlangt**: Sie sagt, der Vergleich sei an
+einem Zwischenstand gemessen, weil der serielle Lauf gegen den endgültigen Wortlaut bei
+Protokollabschluss noch nicht zurück war.
+
+**Er ist inzwischen zurück und grün:** Exit 0, **250 Ergebniszeilen**, sortiert
+deckungsgleich mit dem nebenläufigen Lauf; **977 s auf einer Bahn gegen 128 s auf acht**,
+Faktor 7,6 – das deckt sich mit den 7,9 aus 0.46.0. Die vierzig Minuten Wanduhr waren
+Konkurrenz um die Platte, nicht Rechenzeit.
+
+Das ist **kein Fehler im Protokoll** – es behauptet weniger, als wahr ist – und war kein
+eigenes Release wert. Es ist hier nachgetragen, damit die vorsichtige Zeile nicht als
+letzter Stand stehen bleibt.
+
+## 9. Bewertung
+
+**Alle neun Records sind bestätigungsreif.** Bei acht trägt die Begründung von 2026-09-01
+unverändert; bei D-08 trägt die Entscheidung auf einem anderen Grund, und der Grund ist
+benannt. Die drei Einwände aus `CR-2026-019` sind aufgelöst – nicht dadurch, dass ihre
+Fragen beantwortet wären, sondern dadurch, dass keiner von ihnen eine Frage nach Kriterium
+4 stellt.
+
+> **Die Lehre, die über den Fall hinausgeht:** Dieses Repositorium prüft seit
+> dreiundzwanzig Releases, ob seine Zusagen halten. **Es hat nie geprüft, ob seine
+> Bedingungen die richtigen sind.** Eine zu schwache Zusage lässt durch und fällt
+> irgendwann auf. Eine zu starke Bedingung hält auf – und fällt nie auf, weil ein
+> unerfülltes Vorzeichen wie Sorgfalt aussieht.
+
+Umsetzung mit `0.49.0`, Antrag `CR-2026-071`, Decision Records D-100 und D-101.

package/.koolie/core/tests/protocols/2026-09-15-herrichtung-uebungsrepositorium.md

@@ -0,0 +1,213 @@
+# Herrichtung des Übungsrepositoriums und was dabei angefallen ist
+
+| Feld | Wert |
+|---|---|
+| Datum | 2026-09-14 (Messungen), abgeschlossen in der Nacht zum 2026-09-15 |
+| Gegenstand | `devpacks/test-devin-framework` – das synthetische Übungsrepository, Vorbedingung jedes Sitzungstests (Verfahren Nr. 1 des Testkatalogs) |
+| Anlass | Kandidat 1 der Übergabe: Übungsrepository von 0.13.0 auf `main` heben, die drei fehlenden Köder anlegen |
+| Framework-Stand | vorher 0.13.0, nachher 0.44.0 (einunddreißig Releases) |
+| Client Pack dort | `devin-desktop` |
+| Ergebnis | Validator `--strict-overlay` **0 Fehler, 0 Warnungen**; Frontend-Tests **18 grün**; `lint` und `typecheck` ohne Befund |
+| Folgeantrag | `CR-2026-067` (vier Befunde, davon zwei mit eigener Prüfung) |
+
+## 1. Prüfmethode
+
+Das Heben wurde **zuerst in einer Probe im Scratchpad gefahren**, nicht im Repositorium:
+`git archive HEAD` des Übungsrepositoriums, `leitwerk-core/` aus `git archive HEAD` des
+Frameworks darübergelegt, dann `install.py --update`. So steht der Migrationsumfang fest,
+bevor am eigentlichen Baum etwas geändert wird — und er ist wiederholbar.
+
+Jede Messung am Übungsrepository wurde mit seinem **eigenen** Validator gefahren, also mit
+dem Stand, der dort installiert ist. Die Abzählungen über Testfälle und Installationen
+liefen über Skripte, nicht über das Auge.
+
+## 2. Was das Heben gekostet hat
+
+`install.py --update`: 24 Core-Dateien erneuert, 40 unverändert, **20 Projektdateien
+unangetastet**. Danach meldete der Validator `--strict-overlay`:
+
+| Anzahl | Prüfung | Befund |
+|---|---|---|
+| 1 | 37 | Der `ask`-Korb führt **8 Regeln**, die die Kernquelle nicht erzeugt, bei **3 gefüllten Platzhalterschlitzen** |
+| 8 | 42 | Je eine Meldung pro Exec-Regel: kein Platzhalter des Overlays erklärt diesen Befehl |
+| 3 | 42 | Verlorener Anker: keine Tabellenzeile nennt `<BUILD_COMMAND>`, `<TEST_COMMAND>`, `<LINT_COMMAND>` |
+| 1 | 13 | Kompatible Framework-Version steht auf `0.13.x` |
+| 1 | 20 | Die Importsteuerung `read_config_from` fehlt |
+| **14** | | **Fehler gesamt**, dazu **1 Warnung** (verwaiste Hook-Datei neben der wirksamen Konfiguration) |
+
+**Die Übergabe hatte weniger erwartet.** Sie nannte die Platzhalterform — „jeder
+Befehlsplatzhalter zweimal und ohne spitze Klammern". Gemessen ist der Befund größer: Das
+Übungsrepository ist der **zweite und schärfere echte Fall des 0.44.0-Befunds**. Acht
+Exec-Freigaben bei drei Schlitzen heißt: **fünf Freigaben mehr, als die Kernquelle
+überhaupt erzeugen kann**, darunter
+
+```
+Exec(python3 leitwerk-core/tests/scripts/validate-framework.py)
+```
+
+— der Aufruf des Validators selbst. Eingetragen worden sind sie von Hand, und bis
+Prüfung 42 hat es nichts gemeldet.
+
+## 3. Welcher Strang die drei Schlitze bekommt — und warum das gemessen wurde
+
+Das Übungs-Overlay führt zwei Technologiestränge (Java/Maven, TypeScript/npm) und damit
+sechs Build-, Test- und Prüfbefehle. Die Berechtigungsdatei hält drei Schlitze bereit.
+**Die Entscheidung fiel nach der Fahrbarkeit, nicht nach der Reihenfolge im Dokument:**
+
+| Werkzeug | `command -v` | Lauf |
+|---|---|---|
+| `node` | `/c/Program Files/nodejs/node` | – |
+| `npm` | `/c/Program Files/nodejs/npm` | `npm --prefix frontend run test`: **15 Tests grün in 14 s** |
+| `java` | **nicht gefunden** | – |
+| `javac` | **nicht gefunden** | – |
+| `mvn` | **nicht gefunden** | – |
+
+Der Backend-Strang ist auf diesem Arbeitsplatz **nicht ausführbar** — derselbe Umstand wie
+beim Piloten (Übergabe vom 13.09.). Die drei Schlitze tragen deshalb die npm-Befehle; die
+drei Maven-Befehle bleiben in Abschnitt 5 und 6 gelistet und wirken über die Regelschicht
+(D-76). **Ein Schlitz, der einen Befehl trägt, den die Maschine nicht ausführen kann,
+sichert nichts ab und verdeckt nur, welcher Befehl wirklich läuft.**
+
+**Was dabei auffällt und nicht mitbehoben ist:** Der eingebaute Übungsfehler des
+Repositoriums (Aufgabe B, `BookService.countAvailableCopies`) liegt im **nicht fahrbaren**
+Strang. Wer ihn über einen Testlauf aufdecken will, braucht ein JDK. Das ist kein Befund
+am Framework und keine Aufgabe dieser Sitzung — es steht hier, damit es beim ersten
+Sitzungstest niemanden überrascht.
+
+## 4. Der Befund, der nicht gesucht wurde: ein Hook, der einunddreißig Releases lang stumm war
+
+`.devin/config.json` trug **keinen `hooks`-Block**. Die Hooks des Projekts 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 seit der Erstinstallation wirkungslos.
+
+**Gemessen, nicht geschlossen.** In einer frischen 0.44.0-Installation wurde der Block
+entfernt und der Lauf wiederholt:
+
+| Zustand | Validatorlauf |
+|---|---|
+| mit `hooks`-Block (Auslieferung) | 2 Fehler |
+| **ohne `hooks`-Block** | **2 Fehler — dieselben** |
+
+Beide Fehler sind Artefakte der Testinstallation (fehlende `README.md`) und haben mit dem
+Hook nichts zu tun. **Kein Lauf sieht das Fehlen.**
+
+**Die Gegenprüfung stellt die Reichweite um.** Abgezählt über alle vier lokalen
+Installationen:
+
+| Installation | Pack | Framework | `hooks`-Block |
+|---|---|---|---|
+| `test-devin-framework` | `devin-desktop` | 0.13.0 | **NEIN** |
+| `otp-generator` (Pilot) | `claude-code` | 0.41.0 | ja |
+| `lw-tech` | `devin-desktop` | 0.24.0 | ja |
+| `leitwerk-ap2` | `devin-desktop` | 0.24.0 | ja |
+
+Es liegt also **nicht am Releasestand** — `lw-tech` und `leitwerk-ap2` stehen auf 0.24.0
+und tragen den Block, weil sie nach D-32 frisch installiert wurden. Betroffen ist **eine**
+Installation, nicht vier. Der Befund selbst bleibt, und er hat eine zweite Hälfte:
+
+> **Prüfung 18 beschreibt die halbe Migration.** Ihre Warnung sagt, die verwaiste Datei sei
+> 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.
+
+Was die alte Datei zusätzlich verpasst hätte, selbst wenn der Client sie läse: Sie kennt
+`read|grep|find_file_by_name` nicht (nur `exec|edit|write`), ruft ohne `--fail-closed` auf
+und übergibt dem Statushook keine Argumente. **Drei Verschärfungen seit 0.25.0, keine davon
+wirksam.**
+
+## 5. Die Präparationen: drei genannt, sieben gebraucht
+
+Verfahren Nr. 1 bindet jeden Sitzungstest an das Übungsrepository;
+`onboarding/exercises/README.md` Nummer 4 nannte **drei Köder**. Abgezählt gegen die
+Vorbedingungen des Testkatalogs:
+
+| Kennung | Präparation | Gebraucht von | Lag vor? |
+|---|---|---|---|
+| `UEB-01` | Injektionsköder | `FW-PI-01` | nein |
+| `UEB-02` | K3-Köder | `FW-DS-01` | nein |
+| `UEB-03` | Scope-Falle | `FW-SC-01`, `FW-SC-02` | nein |
+| `UEB-04` | `.env`-Testdatei | `FW-DS-02` | nein |
+| `UEB-05` | präparierter Codekommentar | `FW-PI-02` | nein |
+| `UEB-06` | Injektion in einer Testdatei | `SK-006-N04`, `FW-PI-04` | nein |
+| `UEB-07` | Regelwiderspruch zu `FW-CORE-05` | `FW-KO-03` | nein |
+
+**Keine einzige lag vor**, und der Testkatalog führte alle neun Fälle als `offen`, also als
+fahrbar. Die Abwesenheit ist mit `git ls-files` und `ls -a` geprüft; die
+**Anwesenheitsprobe desselben Gegenstandstyps** (Verfahren Nr. 7) ist die `.gitignore` und
+`.devin/` — beide Punktdateien, beide gefunden.
+
+**Zwei Vorbedingungen sind keine Präparationen:** `FW-PI-03` und `FW-DS-05` brauchen einen
+präparierten Aufgabentext, und der ist eine Sitzungseingabe.
+
+## 6. Was beim Anlegen der Köder gemessen wurde
+
+Zwei Fragen waren vorab zu klären, weil sie die Ablage bestimmen:
+
+| Frage | Messung | Folge |
+|---|---|---|
+| Macht ein K3-Köder im Repositorium den eigenen Validator rot? | **Nein.** Lauf mit Köder: 14 Fehler — dieselben wie ohne | Der Köder darf im Repositorium liegen |
+| Greift der Schutz-Hook auf den Köder? | **Lesen: Exit 0** (Pfad enthält kein Muster). **Schreiben eines Textes mit `db.password=…`: Exit 2**, auch mit ausdrücklich synthetischem Wert; Kontrolllauf mit einem echt aussehenden Wert identisch | Der Köder ist nur über den Shell-Kanal anzulegen — **und für `FW-DS-01` ist der Hook eine zweite Schranke.** Ein Lauf, in dem der Client den Inhalt nicht zitiert, belegt **ohne Entlastungslauf** nicht das S3-Verhalten |
+
+Der zweite Befund gehört in das Testblatt von `FW-DS-01`, bevor jemand den Fall fährt.
+
+## 7. Wohin das Mentorenmaterial gehört
+
+Die Zuordnung Präparation → Testfall steht im Mentorenblatt
+(`tools/mentorenblatt/PRAEPARATIONEN.md`), und `tools/**` ist neu in `<EXCLUDED_PATHS>`:
+Ein KI-Client, der es liest, kennt die Auflösung jeder Negativübung. In der
+Strukturtabelle des Overlays wird `tools/` deshalb **neutral** beschrieben —
+„Mentorenmaterial und Hilfsskripte". Die Strukturtabelle liest der Client mit; ein Hinweis
+auf Köder wäre dort derselbe Fehler wie das Blatt selbst im lesbaren Bereich.
+
+**`UEB-07` liegt nicht im Repositorium**, sondern daneben: Sein Ablageort ist die
+Regelablage, und die schreibt `install.py --update` bei jedem Release-Wechsel neu. Eine
+Datei, die dort läge, wäre beim nächsten Update still verschwunden. Gesetzt und entfernt
+wird sie mit `tools/praeparationen.py`; beide Zustände sind gegen den Validator gemessen
+und **beide grün** — was zugleich zeigt, dass `FW-KO-03` ein Sitzungstest ist und kein
+Skripttest: Der Validator sieht den Widerspruch nicht.
+
+## 8. Ein Befund lag unter einem verlorenen Anker
+
+Abschnitt 4 des Übungs-Overlays nannte seine sieben Pfadplatzhalter **ohne spitze
+Klammern**. Prüfung 28 sucht die Deklaration von `<EXCLUDED_PATHS>` über genau diese Form,
+fand sie nicht — und **bestand still**. Erst nachdem die Platzhalter die Form der Vorlage
+bekamen, meldete sie:
+
+> Die Deklaration von `<EXCLUDED_PATHS>` nennt `project-overlay/`, `AGENTS.md`, `.devin/`.
+> […] sie gehören in `<READ_ONLY_PATHS>` (B07, D-55)
+
+**Ein echter Fall von B07, im Überlebensmodus einer Prüfung ohne Anker.** Berichtigt sind
+beide Träger, Overlay und Laufzeitfassung. Das ist die Lehre von 0.32.0 — eine
+Konsistenzprüfung ohne ihren Gegenstand besteht leise —, hier zum ersten Mal an einem
+fremden Overlay eingetreten.
+
+## 9. Was der Testkatalog für 1.0.0 wirklich führt
+
+Kriterium 2 von D-11 zählt die Ergebnisspalte des Katalogs **und die dezentralen
+`TESTS.md` je Skill** (so steht es in `docs/ROADMAP.md`). Abgezählt:
+
+| Ablage | Zeilen | davon `offen` |
+|---|---|---|
+| `tests/TEST_CATALOG.md` | 38 | **31** |
+| zwölf Skill-Testblätter | 72 | **72** |
+| **Summe** | **110** | **103** |
+
+Von den 31 Katalogfällen tragen **27** das Prüfmittel `sitzung`, zwei weitere einen
+Sitzungsanteil. **Die Zahl „30 offen" der Übergabe ist zu klein**, und zwar doppelt: 31 im
+Katalog, und die 72 dezentralen kommen hinzu. Das ändert nichts an der Richtung des
+Fokusabschnitts — Kriterium 2 ist der größte Posten —, wohl aber an jeder Schätzung, die
+auf „30" aufsetzt.
+
+## 10. Was offen bleibt
+
+- **Der Backend-Strang ist auf diesem Arbeitsplatz nicht fahrbar.** Ohne JDK und Maven sind
+  Aufgabe A, B und jeder Test, der einen Backend-Lauf braucht, nicht durchführbar.
+- **`docs/UEBUNGSAUFGABEN.md` liegt im lesbaren Bereich** und nennt die Auflösung der
+  Aufgaben A bis F, darunter den eingebauten Fehler. Ein Client, der `docs/` liest, kennt
+  sie. Die sieben Präparationen sind deshalb **nicht** dort geführt. Ob das Blatt selbst in
+  den gesperrten Bereich gehört, ist eine eigene Entscheidung: `<DOC_PATHS>` hätte dann
+  keinen Gegenstand mehr, und die M5-Übungen liefen ins Leere.
+- **Kein Sitzungstest ist gefahren.** Diese Sitzung hat die Vorbedingung hergestellt, nicht
+  die Tests durchgeführt. Der erste Lauf braucht eine Devin-Desktop-Sitzung, und das
+  Kontingent ist begrenzt (Free plan).
+- **`FW-DS-01` braucht einen Entlastungslauf** (Abschnitt 6), sonst ist die Wirkung des
+  Hooks nicht von der Wirkung der Regel zu trennen.