@renoxar/koolie 1.25.0

package/.koolie/core/tests/protocols/2026-09-10-FW-KO-01.md

@@ -0,0 +1,105 @@
+# Testprotokoll FW-KO-01 – Struktur- und Formatkonsistenz
+
+| Feld | Inhalt |
+|---|---|
+| Test-ID | `FW-KO-01` (Basis) |
+| Framework-Version | 0.11.0 (`CR-2026-013`) |
+| Datum | 2026-09-10 |
+| Prüfmethode | skript |
+| Prüfgegenstand | Framework-Repository; Übungsrepository (Testprojekt BIV) in einer Kopie mit dem Validator aus 0.11.0 |
+| PyYAML | 6.0.3 vorhanden – erforderlich, siehe Abschnitt „Bekannte Grenzen" |
+
+## Ausgeführte Befehle und Ergebnis
+
+```text
+python leitwerk-core/tests/scripts/validate-framework.py
+→ Ergebnis: 0 Fehler, 0 Warnungen
+
+python leitwerk-core/tests/scripts/validate-framework.py --strict-overlay   (Übungsrepository)
+→ Ergebnis: 0 Fehler, 0 Warnungen
+```
+
+Das Übungsrepository trägt den Kern aus 0.10.0 und wurde für diesen Lauf in einer Kopie mit
+dem Validator aus 0.11.0 geprüft. Es zieht mit dem nächsten `install.py --update` nach; sein
+Ergebnis ändert sich dadurch nicht.
+
+## Wirksamkeitsnachweis
+
+Ein grüner Lauf belegt, dass das Skript durchläuft – nicht, dass es prüft. Deshalb wurde je
+Prüfung des Validators mindestens ein bekannter Defekt in eine Kopie des jeweiligen
+Repositorys eingebracht und geprüft, ob er gemeldet wird. Nach jedem Eingriff wurde die
+Kopie neu erzeugt; gezählt wurden nur Meldungen, die im Ausgangszustand nicht auftraten.
+
+| Prüfung | Eingebrachter Defekt | Ergebnis |
+|---|---|---|
+| 1 | Wurzel-Anweisungsdatei entfernt | FEHLER `Pflichtpfad fehlt: AGENTS.md` |
+| 1 | `VERSION` des Kerns entfernt | FEHLER `Pflichtpfad fehlt` |
+| 2 | Kernregel aus `deny` **und** Integritätsliste entfernt | FEHLER (Abgleich gegen die Kernquelle) |
+| 2 | Kernverbot zusätzlich in `allow` eingetragen | FEHLER `Kernverbot steht in allow` |
+| 2 | Berechtigungsdatei als JSON zerstört | FEHLER `kein gültiges JSON` |
+| 3 | Hook-Datei als JSON zerstört | FEHLER `kein gültiges JSON` |
+| 4 | Frontmatter-Feld `description` einer Regeldatei entfernt | FEHLER `Frontmatter-Feld description fehlt` |
+| 4 | Regeldatei über das Zeichenlimit verlängert | FEHLER `12196 Zeichen (> 12.000)` |
+| 5 | `TESTS.md` eines Skills entfernt | FEHLER `TESTS.md fehlt` |
+| 5 | Frontmatter eines Skills zerstört | FEHLER `Frontmatter fehlt oder ungültig` |
+| 6 | E-Mail-Adresse eingefügt | FEHLER `E-Mail-Adresse gefunden` |
+| 6 | Interne IP-Adresse eingefügt | FEHLER `IP-Adresse gefunden` |
+| 6 | Cloud-Zugangsschlüssel eingefügt | FEHLER `Secret-Muster (Cloud-Zugangsschlüssel)` |
+| 6 | Zugangsdaten-Zuweisung eingefügt (`api_key = …`) | FEHLER `Secret-Muster (Zugangsdaten-Zuweisung)` |
+| 7 | Unregistrierter Platzhalter eingefügt | WARNUNG `nicht in PLACEHOLDER_REGISTRY.md` |
+| 8 | Manifest: unbekannter Dokumenttyp | FEHLER `type 'unbekannt' unbekannt` |
+| 8 | Manifest: Kopfschlüssel umbenannt | FEHLER `Kopfschlüssel overlay_version fehlt` |
+| 9 | Overlay-Status im Aktivierungsabschnitt auf `<TBD>` | FEHLER `Overlay-Status ist nicht 'aktiv'` |
+| 9 | Overlay-Status im Steckbrief auf `inaktiv` | FEHLER `Overlay-Status ist nicht 'aktiv', sondern 'inaktiv'` |
+| 11 | Vier Backticks unter `framework/` | FEHLER `Codeblock mit vier oder mehr Backticks` |
+| 11 | Vier Backticks unter `build/doc/` (Quelle der Assemblierung) | FEHLER wie vor |
+| 12 | Toter Querverweis eingefügt | FEHLER `Markdown-Link zeigt ins Leere` |
+
+**22 von 22 Defekten gemeldet.** Prüfung 10 (Mermaid) ist nicht anwendbar: `mmdc` steht in
+dieser Umgebung nicht zur Verfügung.
+
+## Was der erste Lauf ergab
+
+Der Nachweis ist der eigentliche Ertrag dieses Testfalls: **Beim ersten Durchgang blieben
+sechs der 22 Defekte unbemerkt.** Vier davon waren echte Befunde, zwei gingen auf falsch
+gesetzte Sonden zurück (ein Anker im Kommentarblock des Manifests statt in einem
+Dokumenteintrag). Die vier Befunde sind mit `CR-2026-013` behoben; die Tabelle oben zeigt den
+Stand danach.
+
+| Befund | Wirkung vor der Behebung |
+|---|---|
+| Pfadvergleiche der Inhaltsprüfung verglichen Backslash-Pfade mit Schrägstrich-Präfixen | **Prüfung 11 hat unter Windows nie ausgelöst** – und das Framework wird unter Windows entwickelt. Ebenso griff die Ausnahme für `project-overlay/forbidden-terms.txt` nicht: In einem echten Projekt stehen dort die realen Kunden- und Produktnamen, die dadurch gegen sich selbst geprüft worden wären, ein Fehler je Begriff |
+| `build/` war von der Inhaltsprüfung vollständig ausgenommen | Die handgeschriebenen Quellen des Hauptdokuments waren ungeprüft – genau die Stelle, an der vier Backticks die Assemblierung brechen und an der ein Secret in den Lieferbestandteil geriete |
+| Die Statusprüfung kannte nur eine der beiden Schreibweisen | Der Steckbrief eines Overlays konnte `inaktiv` sagen, während `--strict-overlay` grün meldete |
+| Die Secret-Muster des Validators waren enger als die des Schutz-Hooks | Was der Hook in einer Werkzeugeingabe blockiert (`api_key = …`, Bearer-Token, Verbindungszeichenfolge mit Anmeldedaten), durfte in einer versionierten Datei stehen bleiben |
+
+Die Vermutung, die engeren Muster seien Absicht gewesen (Falschalarme in Dokumenten, die
+Zugangsdaten-Muster *beschreiben*), wurde geprüft und widerlegt: Die breiteren Muster ergeben
+über beide Repositorys **einen** Treffer, und der ist ein als synthetisch gekennzeichneter
+Platzhalter in spitzen Klammern. Genau diese Form ist jetzt ausgenommen.
+
+## Bekannte Grenzen
+
+- **Ohne PyYAML ist dieser Testfall nicht aussagekräftig.** Die Prüfungen 4, 5 und 8 prüfen
+  dann nur, ob ein Frontmatter vorhanden ist, nicht was darin steht – im ersten Durchgang
+  blieb die entfernte `description` deshalb unbemerkt. Der Validator sagt das seit 0.11.0
+  als Warnung; vorher schwieg er dazu.
+- Geprüft wird Struktur, nicht Semantik. Ob zwei Regeln einander widersprechen, prüft
+  `FW-KO-02` (review), ob Devin sich daran hält, die Sitzungstests.
+- Prüfung 10 (Mermaid) blieb ungeprüft, weil `mmdc` fehlt. Sie ist optional und nicht Teil
+  des Standardlaufs.
+- Die Sonden wurden von Hand gesetzt und sind nicht Bestandteil des Repositorys. Für einen
+  Wiederholungslauf ist die Tabelle oben die Anleitung: je Zeile ein Eingriff in eine Kopie,
+  danach der Validatorlauf.
+
+## Gegenzeichnung
+
+Rollen statt Personen (`framework/runtime/rules/20-project-overlay.md`).
+
+| Rolle | Datum | Umfang |
+|---|---|---|
+| Durchführung (KI-gestützt, Sitzung) | siehe Kopf des Protokolls | der oben berichtete Lauf |
+| Gegenzeichnung: `<FRAMEWORK_OWNER>` | 2026-09-23 | Protokoll vollständig gelesen |
+
+🔴 **Selbstgegenzeichnung: keine zweite Rolle vorhanden** (D-319, `CR-2026-127` E1, Weg C und B). Verfasser und Gegenzeichner sind dieselbe Person; die Zusage *„Handlung einer zweiten Rolle“* ist damit **zurückgenommen, nicht erfüllt**.
+➡️ *Die Zeile sagt, WAS gegengezeichnet wurde; der Commit sagt, WER.* Die Unterschrift ist der Release-Commit unter der Identität des Owners – ein Werkzeug kann diese Zeile schreiben, den Commit nicht.

package/.koolie/core/tests/protocols/2026-09-10-FW-KO-02.md

@@ -0,0 +1,123 @@
+# Testprotokoll FW-KO-02 – Kurzform gegen Langform
+
+| Feld | Inhalt |
+|---|---|
+| Test-ID | `FW-KO-02` |
+| Framework-Version | 0.12.0 (`CR-2026-014`) |
+| Datum | 2026-09-10 |
+| Prüfmethode | review |
+| Prüfgegenstand | Wurzel-Anweisungsdatei und Regelablage `00-*`, `10-*`, `15-*`, `20-*` (Kurzform) gegen `leitwerk-core/framework/core/00` bis `10` (Langform) |
+| Umfang | 5 Kurzform-Dateien (23.376 Zeichen) gegen 11 Langform-Module (78.122 Zeichen) |
+
+## Verfahren
+
+Die Kurzfassungen tragen den Satz „Diese Fassung ist normativ; bei Abweichungen gilt die
+Langform." Damit ist jede Abweichung entweder harmlos (die Kurzform ist strenger und die
+Langform gilt trotzdem) oder gefährlich (die Kurzform sagt etwas, das die Langform anders
+regelt, und der Leser der immer geladenen Datei erfährt es nie). Geprüft wurde jede
+normative Aussage der Kurzform gegen ihre Entsprechung in der Langform – und umgekehrt jede
+normative Liste der Langform darauf, ob sie in der Laufzeitschicht überhaupt vorkommt.
+
+Der zweite Blick ist der wichtigere: Die Langform wird nicht in die Sitzung geladen. Was
+dort steht und in der Kurzform fehlt, erreicht das Werkzeug nicht.
+
+## Befunde
+
+### Widersprüche (drei)
+
+| # | Kurzform | Langform | Bewertung |
+|---|---|---|---|
+| W1 | `00-framework-core.md`: M1 „Befehle: **nein**" | `05-working-model.md` 2.1: M1 „nur lesende Analysebefehle, falls im Overlay freigegeben" | Der Testfall nennt Modusrechte ausdrücklich als Beispiel. Die Berechtigungsdatei erlaubt `git status`, `diff`, `log`, `show`, `blame` in jedem Modus – die Kurzform behauptete ein Verbot, das nirgends durchgesetzt wird |
+| W2 | `00-framework-core.md`: „Jede Berührung von … personenbezogener Datenverarbeitung … ist mindestens **hoch**" | `09-risk-model.md` R4: Code-Pfad verarbeitet personenbezogene Daten ohne Änderung der Verarbeitungslogik = **mittel**; das Rechenbeispiel in Abschnitt 5 stuft genau so ein | Direkter Widerspruch bei einer Kontrollstufe. Beide Fassungen sind in sich schlüssig, die Aussage ist gegensätzlich |
+| W3 | Wurzel-Anweisung §9: „Nach **zwei** erfolglosen Versuchen … hältst du an" | `10-error-escalation.md` S10: „mehr als zwei Versuche" – Abschnitt 3.1 desselben Moduls dagegen: „Nach zwei fehlgeschlagenen Korrekturschleifen" | Die Langform widerspricht sich selbst; die Kurzform folgt der einen, S10 der anderen Lesart |
+
+### Lücken: normative Langform-Inhalte ohne Entsprechung in der Laufzeitschicht (vier)
+
+| # | Fehlt in der Kurzform | Quelle | Warum es zählt |
+|---|---|---|---|
+| L1 | **Vier der zwölf Delegationsverbote**: V6 (Produktionssysteme, Infrastruktur, Berechtigungen, Sicherheitskonfigurationen), V9 (Entscheidung über die Fortsetzung bei einem Sicherheitsvorfall), V11 (Kommunikation nach außen), V12 (Löschen von Branches, Historie, Daten außerhalb des Arbeitsbereichs) | `09-risk-model.md` 4 | Die Delegationsverbotsliste ist die schärfste Regel des Frameworks – sie gilt unabhängig von der Kontrollstufe. Ein Drittel davon stand in keiner geladenen Datei. V9 und V12 sind sicherheitsrelevant |
+| L2 | K3-Auffangkategorie „Inhalte, die die Organisation als vertraulich oder höher eingestuft hat"; außerdem Keystores und Verbindungszeichenfolgen mit Anmeldedaten | `02-privacy.md` 2.1 | Die Aufzählung ohne Auffangkategorie lädt zum Umkehrschluss ein: Was nicht gelistet ist, ist erlaubt |
+| L3 | Q8: Änderungen über `<CHANGE_SIZE_THRESHOLD>` aufteilen oder als Stufe hoch behandeln | `04-quality.md` 2 | Der Platzhalter wird im Overlay gefüllt, kam aber in keiner geladenen Regel vor – das Werkzeug konnte die Grenze nicht kennen |
+| L4 | Zusammenfassung der Schritte 7 bis 9 bei Kontrollstufe niedrig | `05-working-model.md` 1 | Umgekehrter Fall: Die Kurzform war strenger als die Langform, ohne die Erleichterung zu nennen |
+
+### Begriffliche Abweichungen (zwei)
+
+| # | Befund |
+|---|---|
+| B1 | `15-development-rules.md` verlangte den „Devin-Nutzungsvermerk", die Wurzel-Anweisung den „KI-Nutzungsvermerk", die Vorlage heißt `MR_AI_DISCLOSURE.md`. Drei Bezeichnungen für dieselbe Sache, eine davon an einen Client gebunden |
+| B2 | `20-project-overlay.md` – eine Kernvorlage, die in **jedes** Client Pack installiert wird – nannte an vier Stellen „Devin" als Akteur. Ein Projekt mit dem Pack `claude-code` liest dort den Produktnamen eines Werkzeugs, das bei ihm nicht im Einsatz ist |
+
+### Kein Befund
+
+Übereinstimmend geprüft: Prioritätshierarchie (8 Stufen), Standardarbeitsablauf (14 Schritte),
+Modi M3/M4/M5, Kontextklassen K0 bis K2, Einstufungsregeln (höchste Klasse, fehlende
+Einstufung = K3, K2 nicht ins Repository), Abbruchbedingungen S1 bis S9, Pflichtfelder des
+Ergebnisberichts, Q1/Q4/Q6/Q7, Regeln zu Abhängigkeiten, Prompt Injection und externen
+Quellen.
+
+## Umsetzung
+
+Alle sieben Befunde sind mit `CR-2026-014` behoben. Die Richtung der Auflösung war jeweils
+zu begründen und nicht selbstverständlich:
+
+| Befund | Auflösung | Richtung |
+|---|---|---|
+| W1 | Kurzform auf „nur lesende Analysebefehle" gehoben; in der Langform zusätzlich M2 an die eigene Prosa angeglichen („Alles aus M1" bei gleichzeitig „Befehlsausführung: nein" war in sich widersprüchlich) | Kurzform folgt der Langform |
+| W2 | Kurzform übernimmt die Unterscheidung aus R4 | Kurzform folgt der Langform. Die Gegenrichtung hätte die Abstufung in R4 und das Rechenbeispiel entwertet |
+| W3 | S10 auf „zwei erfolglose Versuche" gesetzt | Langform folgt der Kurzform – sie ist die strengere und stimmt mit Abschnitt 3.1 desselben Moduls überein |
+| L1–L4 | In der Kurzform ergänzt | Verschärfung, außer L4 (dokumentierte Erleichterung, die ohnehin galt) |
+| B1 | „KI-Nutzungsvermerk" mit Verweis auf die Vorlage | – |
+| B2 | Direkte Anrede wie in der Wurzel-Anweisung | – |
+
+Keine widersprüchlichen Anweisungen mehr; die verbliebenen Abweichungen sind unten
+dokumentiert.
+
+**Ergebnisstatus: `bestanden`.** Der Abgleich ist durchgeführt, die Befunde sind behoben, und
+die Prüfmethode `review` ist erfüllt: `<FRAMEWORK_OWNER>` hat den Abgleich am 2026-09-10
+angesehen, die beiden Auflösungsrichtungen mit Ermessensspielraum ausdrücklich bestätigt und
+das Ergebnis abgezeichnet (siehe Gegenzeichnung).
+
+## Dokumentierte Abweichungen
+
+Der Testfall verlangt nicht Gleichheit, sondern Widerspruchsfreiheit mit dokumentierten
+Abweichungen. Diese bleiben bestehen:
+
+| Abweichung | Begründung |
+|---|---|
+| Die Kurzform nennt die Risikofaktoren R1 bis R13 nicht einzeln, sondern nur die Auslöser für Stufe hoch | Die Einstufung nimmt der Mensch im Preflight vor (`09-risk-model.md` 1.1). Die Kurzform muss die Stufe kennen, nicht die Herleitung |
+| Die Kurzform nennt die Review-Prüfpunkte RV1 bis RV12 nicht | Sie richten sich an die Reviewerin oder den Reviewer, nicht an das Werkzeug. Die Selbstprüfliste in `15-development-rules.md` deckt die Punkte ab, die das Werkzeug selbst prüfen kann |
+| Die Kurzform nennt das Freigabeverfahren für K2 nicht im Detail | Es ist ein menschlicher Prozess (`02-privacy.md` 4). Die Kurzform verweist seit dieser Änderung darauf, dass eine mündliche Zusicherung nicht genügt |
+| Die Langformen sprechen durchgehend von „Devin" als Akteur (74 Nennungen in 11 Modulen), die Laufzeitschicht ist client-neutral (jetzt 0 Nennungen in 5 Dateien) | Rest der Neutralisierung aus D-15: Dort wurden Pfade ersetzt, nicht die Akteursbezeichnung. Die Langform wird nicht in die Sitzung geladen, die Abweichung wirkt also nicht auf das Verhalten. Sie gehört in die Roadmap, nicht in diesen Testfall |
+
+## Bekannte Grenzen
+
+- Die zweite Rolle hat den Abgleich anhand dieses Protokolls geprüft, nicht durch einen
+  eigenen, unabhängigen Abgleich der 101.498 Zeichen. Das entspricht der Prüftiefe eines
+  Dokumentenreviews; ein zweiter vollständiger Abgleich wäre eine Wiederholung des Testfalls,
+  keine Prüfung seines Ergebnisses.
+- Geprüft wurde die Widerspruchsfreiheit der Texte, nicht das Verhalten des Werkzeugs. Ob
+  eine Regel in einer Sitzung greift, prüfen die Testfälle der Klassen KO (dynamisch), NE,
+  SC und ZA – alle `sitzung`, alle abhängig von AP2.
+- Nicht Gegenstand: die Regeltexte aktivierter Packs (`30-*`, `40-*`) und projekteigene
+  Overlay-Erweiterungen (`2N-*`). Sie sind Ebene 5/6 beziehungsweise 4 und werden gegen das
+  Verschärfungsprinzip geprüft, nicht gegen die Langform des Kerns.
+
+## Bestätigte Ermessensentscheidungen
+
+Fünf der sieben Befunde ließen sich nur in eine Richtung auflösen – eine Verschärfung oder
+eine Begriffskorrektur. Zwei ließen Ermessen und wurden der zweiten Rolle einzeln vorgelegt,
+weil sie eine Regel der Laufzeitschicht **weniger streng** machen:
+
+| Frage | Entscheidung | Verworfene Gegenrichtung |
+|---|---|---|
+| Darf das Werkzeug im Modus M1 lesende Analysebefehle ausführen? | **Ja.** Die Kurzform folgt der Langform | Verbot beibehalten und `git status`, `diff`, `log`, `show`, `blame` aus der `allow`-Liste der Berechtigungsdatei streichen – damit wäre in M1 keine Historie mehr lesbar |
+| Welche Kontrollstufe gilt für einen Code-Pfad, der personenbezogene Daten verarbeitet, ohne dass sich die Verarbeitungslogik ändert? | **mittel**, entsprechend R4 und dem Rechenbeispiel in `09-risk-model.md` Abschnitt 5 | Einstufung auf hoch, dann aber R4 und das Beispiel in der Langform mit ändern – jede Aufgabe an einem solchen Pfad hätte eine schriftliche Freigabe und eine begleitende Person erfordert |
+
+## Gegenzeichnung
+
+Rollen statt Personen (`framework/runtime/rules/20-project-overlay.md`).
+
+| Rolle | Datum | Ergebnis |
+|---|---|---|
+| Ersteller des Abgleichs (KI-gestützt, Sitzung) | 2026-09-10 | sieben Befunde, alle behoben |
+| Zweite Rolle: `<FRAMEWORK_OWNER>` | 2026-09-10 | Abgleich angesehen und akzeptiert; beide Ermessensentscheidungen bestätigt; keine Einwände |

package/.koolie/core/tests/protocols/2026-09-10-FW-KO-04.md

@@ -0,0 +1,73 @@
+# Testprotokoll FW-KO-04 – Querverweise gültig
+
+| Feld | Inhalt |
+|---|---|
+| Test-ID | `FW-KO-04` (Basis) |
+| Framework-Version | 0.4.0 + Stand „Unveröffentlicht" (`CR-2026-001`) |
+| Datum | 2026-09-10 |
+| Prüfmethode | skript |
+| Prüfgegenstand | Framework-Repository und Übungsrepository (Testprojekt BIV) |
+
+## Ausgeführte Befehle und Ergebnis
+
+```text
+python leitwerk-core/tests/scripts/validate-framework.py
+→ Ergebnis: 0 Fehler, 0 Warnungen
+
+python leitwerk-core/tests/scripts/validate-framework.py --root <Übungsrepository>
+→ Ergebnis: 0 Fehler, 0 Warnungen
+```
+
+## Wirksamkeitsnachweis
+
+Ein Test ohne Negativnachweis belegt nur, dass das Skript durchläuft – nicht, dass es prüft. Deshalb zusätzlich:
+
+**1. Sondendatei mit bekannten Fehlern.** Eine temporäre Datei mit je einem defekten Markdown-Link und einer defekten Backtick-Pfadangabe sowie vier Angaben, die keine Pfade sind (Glob, Platzhalter, Befehlszeile, Fundstellenformat `pfad:zeile`):
+
+```text
+→ Ergebnis: 2 Fehler, 0 Warnungen
+```
+
+Beide defekten Verweise gemeldet, keine der vier Nicht-Pfad-Angaben fälschlich gemeldet.
+
+**2. Umbenennungssimulation.** Kopie des Repositorys, Verzeichnis `leitwerk-core/` nach `agent-core-framework/` umbenannt, Textinhalte unverändert:
+
+```text
+→ 685 gemeldete Querverweisfehler
+```
+
+Damit ist belegt, dass die für Release 0.5.0 vorgesehene Umbenennung nicht stillschweigend brechen kann.
+
+## Bewertung
+
+**Bestanden.** Beide Repositorys frei von toten Verweisen; der Prüfmechanismus greift nachweislich.
+
+## Bewusste Ausnahmen der Prüfung
+
+Die folgenden Verweisklassen werden nicht als Fehler gewertet; jede ist im Skript begründet:
+
+| Klasse | Begründung |
+|---|---|
+| Laufzeitfassungen aktivierter Packs (`.devin/rules/2N-`, `30-`, `40-`, `.devin/skills/role-`, `tech-`, `prj-`) | Beschreiben das Ziel einer Aktivierung, nicht eine vorhandene Datei (`framework/role-packs/README.md` Punkt 4) |
+| Nutzerlokale Dateien (Namensbestandteil `.local.`) | Per `.gitignore` bewusst nicht versioniert |
+| Pfade mit vorhandener `.example`- oder `.template`-Fassung | Die nutzende Person legt die Datei aus der Vorlage an |
+| Globs, Platzhalter in spitzen Klammern, Befehlszeilen | Keine Pfadangaben |
+| Backtick-Pfade in `PLACEHOLDER_REGISTRY.md`, `CHANGELOG.md`, Vorlagen und `examples/` | Enthalten absichtlich synthetische Beispielpfade; Markdown-Links werden auch dort geprüft |
+
+## Bekannte Grenzen
+
+- Geprüft wird die **Existenz** von Dateien und Verzeichnissen, nicht die Gültigkeit von Anker-Fragmenten (`datei.md#abschnitt`).
+- Backtick-Pfadangaben werden nur geprüft, wenn sie unter einer Framework-Wurzel beginnen (`leitwerk-core/`, `.devin/`, `project-overlay/`, `AGENTS.md`, `README.md`). Pfade in den Projektbereichen eines aufnehmenden Repositorys bleiben ungeprüft.
+- Pfadangaben mit Leerzeichen (etwa `validate-framework.py --strict-overlay`) werden verworfen, um Befehlszeilen nicht als Pfade zu behandeln.
+
+## Gegenzeichnung
+
+Rollen statt Personen (`framework/runtime/rules/20-project-overlay.md`).
+
+| Rolle | Datum | Umfang |
+|---|---|---|
+| Durchführung (KI-gestützt, Sitzung) | siehe Kopf des Protokolls | der oben berichtete Lauf |
+| Gegenzeichnung: `<FRAMEWORK_OWNER>` | 2026-09-23 | Protokoll vollständig gelesen |
+
+🔴 **Selbstgegenzeichnung: keine zweite Rolle vorhanden** (D-319, `CR-2026-127` E1, Weg C und B). Verfasser und Gegenzeichner sind dieselbe Person; die Zusage *„Handlung einer zweiten Rolle“* ist damit **zurückgenommen, nicht erfüllt**.
+➡️ *Die Zeile sagt, WAS gegengezeichnet wurde; der Commit sagt, WER.* Die Unterschrift ist der Release-Commit unter der Identität des Owners – ein Werkzeug kann diese Zeile schreiben, den Commit nicht.

package/.koolie/core/tests/protocols/2026-09-10-FW-RE-02.md

@@ -0,0 +1,99 @@
+# Testprotokoll FW-RE-02 – Overlay-Kompatibilität nach Release-Wechsel
+
+| Feld | Inhalt |
+|---|---|
+| Test-ID | `FW-RE-02` |
+| Framework-Version | 0.10.0 |
+| Datum | 2026-09-10 |
+| Prüfmethode | skript |
+| Prüfgegenstand | Übungsrepository (Testprojekt BIV), Übernahme von Framework 0.4.0 auf 0.10.0 |
+
+## Verfahren
+
+Der Testfall verlangt, dass ein bestehendes Overlay einen Release-Wechsel übersteht –
+`0 Fehler`, und **kein Bruch ohne Migrationshinweis**. Geprüft wurde nicht der kleine
+Schritt, sondern der große: sechs Releases auf einmal, als **Aktualisierung** nach
+Abschnitt 3 des Adoption Guide, nicht als Neuinstallation. Zwischen 0.4.0 und 0.10.0
+liegen die Abbildungsschicht mit Client Packs, die Zusammenführung von Berechtigungen und
+Hooks, die Umbenennung des Kernverzeichnisses und die Verschärfung des Schreibschutzes.
+
+Das Übungsrepository ist dafür der härtere Prüfgegenstand als ein frisch aufgesetztes
+Projekt: Es trägt ein ausgefülltes Overlay mit realen Pfadlisten und Befehlen, zwei
+aktivierte Role Packs, zwei projekteigene Technology Packs, einen `prj-*`-Skill, drei
+dokumentierte Ausnahmen und eine Berechtigungsdatei mit Projektwerten.
+
+## Ablauf und Ergebnis
+
+| Schritt | Ergebnis |
+|---|---|
+| 1. Kernverzeichnis ausgetauscht (`devin-core-framework/` entfernt, `leitwerk-core/` aus dem Release kopiert) | 189 Umbenennungen, 49 neue, 22 entfallene Kerndateien |
+| 2. `python leitwerk-core/install.py --update` | 49 Core-Dateien erneuert, 17 unverändert, **20 Projektdateien unberührt** |
+| 3. `validate-framework.py --strict-overlay` | **genau 2 Fehler**, beide in `.devin/config.json`, beide mit Nennung der fehlenden Kernregel |
+| 4. Berechtigungsdatei migriert (`Write(framework/**)` → `Write(leitwerk-core/**)` in `deny` und `_core_rules_integrity`) | – |
+| 5. `validate-framework.py --strict-overlay` | **0 Fehler, 0 Warnungen** |
+| 6. `install.py --check` | Core ist auf dem Stand des Releases |
+
+**Bestanden.** Der einzige Handgriff war der im CHANGELOG angekündigte.
+
+## Die beiden Fehler aus Schritt 3
+
+```text
+FEHLER   .devin/config.json: Kernregel fehlt in _core_rules_integrity.deny_must_contain
+         (laut Kernquelle vorgesehen): Write(leitwerk-core/**)
+FEHLER   .devin/config.json: Kernregel fehlt in deny: Write(leitwerk-core/**)
+```
+
+Das ist das erwartete Verhalten und der eigentliche Wert des Laufs: Die Berechtigungsdatei
+ist **Saat** und wird von `--update` nie überschrieben, weil sie Projektwerte enthält. Eine
+verschärfte Kernregel erreicht ein bestehendes Projekt deshalb nicht von selbst. Dass der
+Wechsel trotzdem nicht stillschweigend an der alten Regel vorbeiläuft, ist Verdienst der
+Kernquellenprüfung aus Release 0.6.0 – sie vergleicht die installierte Datei gegen die
+Kernquelle, nicht nur gegen sich selbst.
+
+Vor 0.6.0 wäre das Übungsrepository mit `Write(framework/**)` grün geblieben und hätte
+seinen Kern ungeschützt gelassen, ohne dass es jemandem aufgefallen wäre.
+
+## Was der Wechsel nebenbei sichtbar gemacht hat
+
+**Die Wahl des Client Packs fehlte im Overlay.** Seit Release 0.5.0 ist sie eine
+Projektentscheidung (Ebene 4) und gehört in den Projektsteckbrief; das Overlay stammte aus
+der Zeit davor und kannte den Punkt nicht. Der Validator kann das nicht melden – es gibt
+kein Pflichtfeld dafür. Nachgetragen als eigene Zeile in Abschnitt 1 mit Verweis auf die
+Fähigkeitsmatrix des Packs.
+
+**74 Verweise auf den alten Kernnamen in 19 Projektdateien.** Overlay, Overlay-Laufzeitregel,
+beide Technology Packs, der Projekt-Skill, `README.md`, die Übungsaufgaben, die
+MR-Vorlage und die `.gitignore`. Die Migrationsnotiz zu 0.7.0 nennt diesen Schritt
+(„ebenso in Overlay-Dokumenten, die ihn nennen"), beziffert ihn aber nicht. Für ein
+Projekt dieser Größe ist das eine Suchen-und-Ersetzen-Operation; die Notiz sollte den
+Umfang benennen, damit niemand ihn für eine Handvoll Stellen hält.
+
+## Zusätzlich geprüft
+
+Der Schutz-Hook wurde in der zweiten Installation gegen sieben synthetische
+Werkzeugeingaben geführt, null Fehlschläge – darunter der Schreibzugriff auf
+`leitwerk-core/clientmap.py`, der vor 0.10.0 durchgelaufen wäre. Damit ist zugleich belegt,
+dass der Hook den Namen des Kernverzeichnisses korrekt aus seinem eigenen Ort ableitet:
+Er wurde in ein anderes Repository kopiert, ohne dass eine Konfiguration mitgezogen wurde.
+
+## Bekannte Grenzen
+
+- Geprüft ist die Kompatibilität der **Dateien**, nicht das Verhalten einer Sitzung. Die
+  dynamischen Basistests (Klassen PI, DS, SC) stehen weiterhin aus und brauchen eine reale
+  Installation (Roadmap AP2).
+- Das Übungsrepository ist ein Erprobungsrepository ohne Organisationsbezug; zwei seiner
+  drei Ausnahmen (`EX-BIV-001`, `EX-BIV-002`) betreffen genau das. Als Nachweis für
+  Kriterium 5 von D-11 („Übernahme in ein zweites Projekt") trägt es die technische
+  Übertragbarkeit, nicht die organisatorische.
+
+## Gegenzeichnung
+
+Rollen statt Personen (`framework/runtime/rules/20-project-overlay.md`).
+
+| Rolle | Datum | Umfang |
+|---|---|---|
+| Durchführung (KI-gestützt, Sitzung) | siehe Kopf des Protokolls | der oben berichtete Lauf |
+| Gegenzeichnung: `<FRAMEWORK_OWNER>` | 2026-09-23 | Protokoll vollständig gelesen |
+
+🔴 **Selbstgegenzeichnung: keine zweite Rolle vorhanden** (D-319, `CR-2026-127` E1, Weg C und B). Verfasser und Gegenzeichner sind dieselbe Person; die Zusage *„Handlung einer zweiten Rolle“* ist damit **zurückgenommen, nicht erfüllt**.
+➡️ *Die Zeile sagt, WAS gegengezeichnet wurde; der Commit sagt, WER.* Die Unterschrift ist der Release-Commit unter der Identität des Owners – ein Werkzeug kann diese Zeile schreiben, den Commit nicht.

package/.koolie/core/tests/protocols/2026-09-10-FW-VN-01-wiederholung.md

@@ -0,0 +1,108 @@
+# Testprotokoll FW-VN-01 (Wiederholungslauf) – Versionskette vollständig
+
+| Feld | Inhalt |
+|---|---|
+| Test-ID | `FW-VN-01` |
+| Framework-Version | 0.13.0 (`CR-2026-015`) |
+| Datum | 2026-09-10 |
+| Prüfmethode | review |
+| Vorlauf | `2026-09-10-FW-VN-01.md` – neun Befunde, Ergebnisstatus `fehlgeschlagen` |
+| Anlass | Wiederholung nach Behebung der Befunde V1 bis V9 |
+| Referenzinstallation | Übungsrepository auf Stand 0.12.0 (`a4ff67d`), Kopie mit dem Validator aus 0.13.0 |
+| Voraussetzung | PyYAML 6.0.3 installiert; der Validator meldet keine Einschränkungswarnung |
+
+> Zur Dateibenennung: Die Regel des Ablageverzeichnisses (`JJJJ-MM-TT-<Test-ID>.md`) sieht
+> keinen zweiten Lauf am selben Tag vor. Der Wiederholungslauf trägt deshalb den Zusatz
+> `-wiederholung`; der Vorlauf bleibt unverändert stehen.
+
+## Prüfgegenstand nach der Behebung
+
+| Glied | Zustand vor 0.13.0 | Zustand jetzt |
+|---|---|---|
+| Framework-Version | kein Befund | unverändert kein Befund; `VERSION` 0.13.0, oberster Änderungsverzeichnisabschnitt `[0.13.0]`, `CR-2026-015` und D-25 vorhanden |
+| Overlay-Version | drei Ablageorte, kein Abgleich (V1, V2) | Prüfung 13 vergleicht Steckbrief, Manifest und Laufzeitfassung miteinander und die Steckbriefangabe gegen `VERSION` |
+| Skill-Versionen | 13 Skills seit 0.1.0 unverändert auf `0.1.0` (V3, V4); keine Formatprüfung (V6) | 13 Skills auf `0.1.1` mit Eintrag je Änderungsverlauf; Prüfung auf `MAJOR.MINOR.PATCH` und auf einen passenden Änderungsverlaufseintrag |
+| Berechtigungsstand | kein Befund | unverändert |
+| KI-Nutzungsvermerk | Vorlage anders benannt als das Kettenglied (V7), Client in einer Kernvorlage (V8), Kurzform ohne Versionsanker (V9) | 39 Nennungen in 29 Dateien umbenannt (Kern: 39 → 0); Überschrift und Ausfüllhinweis clientneutral; Kurzform nennt Framework- und Overlay-Version |
+| Register | kein Befund im Prüfumfang | unverändert |
+
+Zusätzlich außerhalb der Kette, aus derselben Ursache: 10 Checklisten und 13 Prompts auf
+`0.1.1`, `11-framework-release.md` auf `0.2.0`; die Release-Checkliste verlangt die
+Versionspflege künftig auch für Checklisten und Prompts.
+
+`RELEASE_PROCESS.md` Abschnitt 1.2 nennt die kompatible Framework-Version jetzt nur noch für
+Overlay und Client Pack – die beiden Artefakte, die vom Kern abweichen können (Entscheidung
+E1). Die Zusage ist damit für alle genannten Klassen erfüllt statt für eine von fünf.
+
+## Wirksamkeitsnachweis (D-23)
+
+Dieselben fünf Sonden wie im Vorlauf, dieselbe Kopie der Referenzinstallation, jetzt mit dem
+Validator aus 0.13.0. Ausgangs- und Schlusslauf `--strict-overlay`: 0 Fehler, 0 Warnungen.
+
+| Sonde | Eingebrachter Defekt | Vorlauf | Jetzt |
+|---|---|---|---|
+| S1 | Steckbrief „Kompatible Framework-Version" `0.12.x` → `0.4.x` | unbemerkt | **gemeldet:** „Kompatible Framework-Version '0.4.x' passt nicht zu leitwerk-core/VERSION (0.12.0). Erwartet '0.12.x' oder '0.12.0' – nach einer Aktualisierung ist der Steckbrief nachzuziehen" |
+| S2 | `overlay_version` im Manifest `0.12.0` → `0.9.0` | unbemerkt | **gemeldet:** „Overlay-Version widersprüchlich angegeben (OVERLAY.md: 0.12.0; 20-project-overlay.md: 0.12.0; overlay-manifest.yaml: 0.9.0)" |
+| S3 | Laufzeitfassung `Overlay-Version` `0.12.0` → `0.3.0` | unbemerkt | **gemeldet:** dieselbe Meldung mit dem abweichenden Wert an der Laufzeitfassung |
+| S4 | Skill-Version `0.1.0` → `0.9.9`, Änderungsverlauf bleibt `0.1.0` | unbemerkt | **gemeldet:** „Version 0.9.9 hat keinen Eintrag in CHANGELOG.md (08-skill-conventions.md Abschnitt 7)" |
+| S5 | Skill-Version → `banane` | unbemerkt | **gemeldet:** „Version 'banane' ist kein Semantic Versioning (MAJOR.MINOR.PATCH)" |
+
+Die Meldung zu S2 und S3 nennt **alle drei** Werte mit Fundstelle, nicht nur den abweichenden.
+Das ist Absicht: Welcher der drei der richtige ist, entscheidet das Projekt, nicht die Prüfung.
+
+Die drei Gegenproben des Vorlaufs wurden wiederholt und weiterhin jede gemeldet:
+Metadatenzeile `Version` entfernt, Kopfschlüssel `overlay_version` entfernt, Overlay-Status auf
+`inaktiv`. Keine der neuen Prüfungen hat eine bestehende verdrängt.
+
+## Weitere Läufe
+
+| Prüfung | Ergebnis |
+|---|---|
+| `validate-framework.py` gegen das Framework-Repository | 0 Fehler, 0 Warnungen |
+| `validate-framework.py --strict-overlay` gegen die Referenzinstallation | 0 Fehler, 0 Warnungen |
+| `FW-KO-04` (Querverweise, Prüfung 12) | 0 Fehler – die Umbenennung in 29 Dateien hat keinen Verweis gebrochen |
+| `install.py --check` | „Core ist auf dem Stand des Releases" (60 Dateien unverändert) nach `--update` der Laufzeitschicht |
+| Hauptdokument | baut für beide Client Packs: `devin-desktop` 9.309 Zeilen, `claude-code` 9.203 Zeilen |
+
+## Bewertung
+
+Alle neun Befunde sind behoben, und die fünf Sonden, die im Vorlauf unbemerkt blieben, werden
+gemeldet. Die Kette hält damit nicht mehr nur durch Sorgfalt: Vier ihrer Angaben kann der
+Validator gegeneinander prüfen, und die fünfte – der Nutzungsvermerk – nennt bei jeder
+Kontrollstufe eine Version, die sich bewegt.
+
+**Ergebnisstatus: `bestanden`.**
+
+Die Prüfmethode `review` verlangt ein Dokumentenreview durch eine **zweite Rolle**; ein grüner
+Lauf ersetzt sie nicht. `<FRAMEWORK_OWNER>` hat die Befunde des Vorlaufs und ihre Behebung am
+2026-09-10 angesehen, die beiden Auflösungen mit Ermessensspielraum einzeln entschieden – E1:
+Abschnitt 1.2 wird eingeschränkt; E2: die Skill-Versionen werden angehoben – und das Ergebnis
+abgezeichnet (siehe Gegenzeichnung).
+
+Damit sind alle drei Bedingungen aus D-23 erfüllt: grüner Lauf, Wirksamkeitsnachweis, und bei
+Prüfmethode `review` zusätzlich die zweite Rolle.
+
+## Bekannte Grenzen
+
+- Die Versionsanhebung löst nach `08-skill-conventions.md` Abschnitt 7 die erneute Ausführung
+  der Testfälle in `TESTS.md` je Skill aus. Sie sind sämtlich `sitzung` und hängen an AP2, also
+  heute nicht ausführbar. Diese Pflicht bleibt offen und ist in der Roadmap vermerkt – sie war
+  der ausdrücklich vorgelegte Preis der Entscheidung E2.
+- Prüfung 13 vergleicht Versionsangaben miteinander. Ob eine Version **inhaltlich** die
+  richtige ist – ob also eine Änderung MINOR statt PATCH verdient hätte –, prüft sie nicht und
+  kann sie nicht; das bleibt Sache des Release-Reviews.
+- Geprüft wurde weiterhin die Kette im Framework und in der Referenzinstallation, nicht an
+  realen Merge Requests.
+
+## Gegenzeichnung
+
+Rollen statt Personen (`framework/runtime/rules/20-project-overlay.md`).
+
+| Rolle | Datum | Ergebnis |
+|---|---|---|
+| Ersteller des Reviews (KI-gestützt, Sitzung) | 2026-09-10 | neun Befunde behoben; fünf Sonden gemeldet |
+| Zweite Rolle: `<FRAMEWORK_OWNER>` | 2026-09-10 | Review abgenommen, keine Einwände. **E1 entschieden:** Abschnitt 1.2 auf Overlay und Client Pack einschränken. **E2 entschieden:** Skill-Versionen anheben; die daraus folgende Testpflicht bleibt bis AP2 offen und ist in der Roadmap vermerkt. `FW-VN-01` steht damit auf `bestanden` |
+
+Nachgetragen nach dem Merge des Releases 0.13.0 – wie bei `FW-KO-02`. Der Wortlaut des
+Wiederholungslaufs oberhalb dieser Zeile ist unverändert; ergänzt sind allein die Abnahme und
+der daraus folgende Ergebnisstatus.