@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-033-modusabhaengige-durchsetzung.md

@@ -0,0 +1,131 @@
+# Änderungsantrag `CR-2026-033`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Im untersagten Modus ist die erste Linie aus – die Matrix stuft B2 bis B8 unbedingt als `[TECHNISCH]` ein |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-11 |
+| Betroffene Artefakte | `clients/README.md` (Abschnitt 4, Definition `[TECHNISCH]`), beide `CLIENT_PACK.md` (B-Block), `clients/_template/CLIENT_PACK.md`, `framework/core/03-security.md` (T7) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Bedeutung einer Einstufungsklasse; betrifft **beide** Client Packs |
+| Art | Behebung von `AP2-DD-12` (Schwere: mittel); Präzisierung der Klasse `[TECHNISCH]` |
+| Dringlichkeit | regulär |
+
+## 1. Anlass und Problem
+
+In der AP2-Sitzung las der Agent `.env` mit dem Lesewerkzeug, **obwohl die Berechtigungsdatei
+eine Verweigerungsregel für Secret-Pfade führt**. Der Lauf stand im Modus `Bypass`. Die
+Team-Dokumentation des Clients sagt, dass allein Regeln der Organisationsebene „cannot be
+overridden" – projektweite offenbar schon.
+
+### Was die Matrix zusagt
+
+`clients/README.md` Abschnitt 4 definiert die Klasse:
+
+> `[TECHNISCH]` – Der Client erzwingt die Zusage. **Ein Verstoß ist nicht möglich, unabhängig vom
+> Modellverhalten.**
+
+Beide Packs führen B2 bis B8 in dieser Klasse. Der Satz ist **wörtlich nicht widerlegt**: Der
+Zugriff geschah nicht am Modell vorbei, sondern weil die Engine in diesem Modus nicht prüft. Aber
+er sagt das, was ein Leser mitnimmt, nicht: **`[TECHNISCH]` beschreibt die Unabhängigkeit vom
+Modellverhalten, nicht die Unabhängigkeit vom Betriebsmodus.** Die Bedingung steht in keiner
+Zeile, in keiner Vorbemerkung und in keinem der beiden Packs.
+
+Damit steht in der Matrix eine Zusage, die in einem bestimmten Betriebszustand nicht gilt – und
+der Betriebszustand ist genau der, den D-05 untersagt und den `M2` bei diesem Pack **nicht
+technisch sperren kann**.
+
+### Der Befund belegt D-05 und K-05 empirisch
+
+Bis zu dieser Sitzung war „der Modus ohne Rückfragen ist untersagt" eine Anordnung mit
+plausibler Begründung. Jetzt ist es eine Messung: **Ohne Admin-Kontrollen gibt es gegen ihn keine
+technische Schranke, und mit ihm fällt die gesamte erste Linie.** K-05 ist damit nicht mehr nur
+eine Beschaffungsfrage, sondern die Bedingung, unter der sechs Kernzusagen technisch gelten.
+
+Den richtigen Hebel benennt `CR-2026-028` bereits: Nicht der Modus wird gesperrt, seine Wirkung
+wird durch Berechtigungen der Organisationsebene begrenzt. Dieser Antrag zieht die Folge für die
+**Einstufung** nach; die beiden überschneiden sich nicht.
+
+### Die zweite Linie hat gehalten – und das ist der eigentliche Beleg
+
+Im selben Modus **blockierte der Schutz-Hook `cat .env`** (Zusage H2, Abschnitt 3 des Protokolls).
+Erste und zweite Linie fallen also nicht gemeinsam, sondern unter verschiedenen Bedingungen:
+
+| Linie | fällt aus, wenn | hielt in der Sitzung |
+|---|---|---|
+| Berechtigungsregeln | der Betriebsmodus die Prüfung abschaltet | nein |
+| Schutz-Hook | die Hook-Konfiguration nicht gelesen wird (`AP2-DD-10`) oder das Werkzeugverb fehlt (`AP2-DD-11`) | ja, für `exec` |
+
+**Das ist die empirische Rechtfertigung des Hooks überhaupt** – und der Grund, warum
+`CR-2026-030` die Lücke beim Leseverb schließen musste: Ohne sie blieb im Bypass-Modus **keine**
+Linie stehen, und genau dieser Fall ist beobachtet worden.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Vorbemerkung im B-Block jeder Fähigkeitsmatrix**, Formulierungsvorschlag:
+
+   > `[TECHNISCH]` heißt in diesem Block: Die Engine setzt die Regel durch, **solange der
+   > Betriebsmodus die Berechtigungsprüfung nicht abschaltet.** Im Modus ohne Rückfragen, den
+   > D-05 untersagt, ist diese Linie aus; dann trägt allein der Schutz-Hook. Beobachtet am
+   > 2026-09-11 (`devin-desktop`, Modus `Bypass`): Eine `deny`-Regel auf einen Secret-Pfad griff
+   > nicht, der Schutz-Hook griff.
+
+2. **Die Definition in `clients/README.md` Abschnitt 4 wird präzisiert:** „…unabhängig vom
+   Modellverhalten. Die Abhängigkeit vom Betriebsmodus weist der B-Block des jeweiligen Packs
+   aus."
+
+3. **`framework/core/03-security.md`, T7 („Übermäßige Berechtigungen"):** Die Gegenmaßnahme nennt
+   bisher D-05 und Regel 3.1 – beides organisatorisch. Ergänzt wird, was **technisch** trägt,
+   wenn T7 eintritt: der Schutz-Hook, seit 0.25.0 auch für lesende Werkzeuge (D-33). Ohne diesen
+   Satz nennt der Kern für seine dritte Bedrohung keine technische Gegenmaßnahme, obwohl es eine
+   gibt.
+
+4. **Keine neue Prüfung.** Ein Validator sieht den Betriebsmodus einer künftigen Sitzung nicht.
+   Prüfbar wäre allein die Anwesenheit der Vorbemerkung – eine Prüfung, die belegt, dass ein Satz
+   dasteht. Das ist zu wenig für eine eigene Nummer und wird hier ausdrücklich nicht beantragt
+   (siehe E4).
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Die Einstufungen selbst.** B2 bis B8 bleiben `[TECHNISCH]`. In den Modi, die das Framework
+  erlaubt, setzt die Engine durch – daran ändert der Befund nichts.
+- **D-05.** Die Anordnung gilt unverändert; sie ist durch den Befund gestützt, nicht berührt.
+- **M2 und den Mechanismus der Modus-Sperre.** Das ist Gegenstand von `CR-2026-028`.
+- **Die Regelmenge.** `permissions.json`, die Secret-Pfade und die Abbildung bleiben unverändert.
+
+## 4. Grenze der Zusage
+
+**Der Hook ist die zweite Linie, nicht die erste – und nur dort, wo er läuft.** Bei
+`devin-desktop` tut er das seit 0.25.0; H3 ist weiterhin unbeobachtet, H1 und H2 sind beobachtet.
+Fällt die Hook-Konfiguration aus, steht im Bypass-Modus nichts mehr.
+
+**Nicht erhoben ist, ob im Bypass-Modus auch die `ask`-Regeln entfallen.** Nach der
+Modusbeschreibung („All tool calls are auto-approved without prompting") ist es zu erwarten,
+gemessen ist es nicht.
+
+**Für `claude-code` ist der Fall unerhoben.** Dort ist der Modus technisch sperrbar
+(`permissions.disableBypassPermissionsMode`, AP2-CC-05) und in verwalteten Einstellungen
+unüberschreibbar – die Lage ist also nicht dieselbe, aber sie ist auch nicht gemessen.
+
+**Ein Nachweis aus einem untersagten Modus belegt keinen erlaubten Betrieb.** Abschnitt 4 des
+Protokolls sagt das bereits; dieser Antrag stützt sich ausdrücklich auf einen Lauf, der so nicht
+stattfinden dürfte – als Testnachweis zulässig, als Betriebszustand nicht.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Einstufung ändern oder Bedingung ausweisen? | **Ausweisen.** `[TECHNISCH]` ist richtig für den erlaubten Betrieb; eine Herabstufung würde eine Durchsetzung verschweigen, die es gibt | Wer nur die Spalte liest, liest weiterhin „erzwungen". Die Bedingung steht über der Tabelle, nicht in der Zeile |
+| E2 | Eigene Matrixspalte „gilt im Modus"? | **Nein.** Sie beträfe acht Zeilen in jedem Pack und trüge in sieben davon denselben Wert | Die Information ist Fließtext und damit leichter zu überlesen als eine Spalte |
+| E3 | Definition in `clients/README.md` schärfen? | **Ja.** Sie ist die Stelle, an der die Klasse definiert wird | Alle bestehenden Matrizen erben die Präzisierung, ohne dass jemand sie einzeln geprüft hat: Die Aussage wird richtig, der Belegstand ändert sich nicht |
+| E4 | Prüfung aufnehmen? | **Nein**, mit Begründung im Antrag | Die Vorbemerkung kann bei einem neuen Pack fehlen, und nichts meldet es. `clients/README.md` Abschnitt 5 nennt sie als Pflicht – das ist eine Anweisung, keine Prüfung |
+| E5 | Den Fall für `claude-code` erheben? | **Ja, als Folgearbeit in AP2** – ein Lauf im Bypass-Modus gegen die isolierte Umgebung, wie WN-5 ihn geführt hat | Ein weiterer Nachweis in einem untersagten Modus. Zulässig nur als Test, und im Protokoll als solcher auszuweisen |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** |
+| Datum | 2026-09-11 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | E1 bis E5 wie vorgelegt: Die Einstufungen bleiben `[TECHNISCH]`, die Bedingung kommt als **Vorbemerkung** in den B-Block; keine eigene Matrixspalte; die Klassendefinition in `clients/README.md` wird präzisiert; T7 nennt künftig die technische Gegenmaßnahme; keine neue Prüfung; der Bypass-Lauf für `claude-code` wird als Folgearbeit in AP2 geführt und im Protokoll als Testnachweis ausgewiesen. Ziel-Release 0.26.0 |
+| Umsetzung | **mit Release 0.26.0** – Einzelheiten und Nachweise in `leitwerk-core/CHANGELOG.md` |

package/.koolie/core/governance/change-requests/CR-2026-034-nachweisbedingungen.md

@@ -0,0 +1,116 @@
+# Änderungsantrag `CR-2026-034`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Was ein Nachweis aus dem nicht-interaktiven Betrieb belegt – und was nicht |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-11 |
+| Betroffene Artefakte | `tests/TEST_CATALOG.md` (Abschnitt 1, Verfahren), `clients/devin-desktop/CLIENT_PACK.md` (Abschnitt 5), `governance/DECISION_LOG.md` (Fortschreibung D-23) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Testverfahren; Client Pack nur nachrichtlich |
+| Art | Behebung von `AP2-DD-13` (Schwere: niedrig) und `AP2-DD-14` gemeinsam |
+| Dringlichkeit | regulär |
+
+## 1. Anlass und Problem
+
+Zwei Befunde der AP2-Sitzung betreffen nicht das Framework, sondern die **Bedingungen, unter
+denen seine Nachweise entstehen**:
+
+| Befund | Beobachtung |
+|---|---|
+| `AP2-DD-13` | Ein Shell-Befehl im Standardmodus verlangt eine Bestätigung. Nicht-interaktiv kann sie nicht gestellt werden; der Lauf endet **ohne jede Ausgabe mit Exit 0** |
+| `AP2-DD-14` | `Error: Refusing to run in an untrusted workspace`. Erst `--respect-workspace-trust false` oder eine interaktive Bestätigung lassen den Lauf überhaupt zu |
+
+Beide führen zur selben Falle: **Ein Lauf, der gar nicht stattgefunden hat, sieht aus wie ein Lauf
+mit leerem Ergebnis.** Beim ersten stimmt sogar der Exit-Code.
+
+### Warum das die Beweisführung dieses Protokolls trifft
+
+Der schwerste Befund des Protokolls – `AP2-DD-10`, die nie gelesene Hook-Datei – beruht auf einer
+**Abwesenheitsmessung**: null Hook-Aufrufe in vier Konfigurationen. Das ist genau die Form von
+Beleg, die ein stiller Abbruch erzeugen kann, ohne dass es auffällt.
+
+Der Befund hält trotzdem – aber nicht wegen der Messung, sondern wegen der Gegenprobe: **G-2 hat
+denselben Fall interaktiv in der Agent-Sidebar wiederholt**, mit einem echten `exec`-Aufruf, der
+sichtbar lief und trotzdem keine Aufzeichnung erzeugte. Dazu kommt der Positivbeleg aus derselben
+Messreihe: Dieselben Hooks in der Berechtigungsdatei lösten **sofort** aus.
+
+**Der stärkste Befund des Protokolls hing damit an einer Gegenprobe, nicht am Messwert.** Dass es
+gut ausging, ist kein Verfahren.
+
+### Was das Verfahren heute sagt
+
+`TEST_CATALOG.md` Abschnitt 1 regelt Prüfmethoden, Voraussetzungen (PyYAML), Ergebnisstatus und
+die Angaben dynamischer Tests. D-23 verlangt für **Prüfungen** einen Wirksamkeitsnachweis: eine
+Sonde mit bekanntem Defekt, die gemeldet wird.
+
+Für **Sitzungsnachweise** gibt es die Entsprechung nicht. Ein ausbleibendes Ereignis zählt als
+Beleg, ohne dass belegt sein müsste, dass überhaupt gemessen wurde. Das ist dieselbe Lücke, die
+D-23 für Prüfungen geschlossen hat – eine Ebene höher.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Neue Nummer 7 in `TEST_CATALOG.md` Abschnitt 1 (normativ)**, Formulierungsvorschlag:
+
+   > **Nachweise aus dem nicht-interaktiven Betrieb.** Ein Nachweis, der aus dem **Ausbleiben**
+   > einer Wirkung besteht, ist nur gültig, wenn der Lauf selbst belegt ist – durch eine Ausgabe,
+   > eine Aufzeichnung oder einen zweiten, positiv wirkenden Vorgang im selben Lauf. **Ein
+   > Exit-Code allein genügt nicht**; ein nicht-interaktiver Lauf kann bei nötiger Rückfrage ohne
+   > Ausgabe mit Erfolgscode enden. Ein Lauf unter aufgehobenen Schutzvorkehrungen des Clients
+   > (abgeschaltete Vertrauensprüfung, Modus ohne Rückfragen) belegt **nicht** den Normalbetrieb;
+   > das Protokoll weist die Bedingung aus und benennt, was dadurch offen bleibt.
+
+2. **D-23 wird fortgeschrieben**, nicht ersetzt: Der Wirksamkeitsnachweis gilt für Prüfungen;
+   für Sitzungsnachweise gilt Nummer 7 des Testkatalogs. Beide sagen dasselbe – **ein Nachweis
+   zählt, wenn belegt ist, dass gemessen wurde.**
+
+3. **Zwei Zeilen in Abschnitt 5 des Packs `devin-desktop`** („Bekannte Abweichungen im
+   Verhalten"): der stille Abbruch bei nötiger Rückfrage und die Vertrauensschranke im
+   nicht-interaktiven Betrieb, jeweils mit der Folge für die in Abschnitt 6 vorgeschriebene
+   Prüfung.
+
+4. **Keine Änderung an Skripten.** Der Befund liegt im Verfahren, nicht im Code.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Die Vertrauensschranke.** Sie ist eine **Verschärfung** des Clients und willkommen. Das
+  Framework verlangt nicht, sie im Normalbetrieb abzuschalten; es regelt nur, was ein Nachweis
+  wert ist, der sie abgeschaltet hat.
+- **Die bestehenden Protokolle.** Sie bleiben, wie sie sind. Abschnitt 4 des AP2-Protokolls weist
+  die Bedingungen bereits aus – dieser Antrag macht daraus eine Pflicht statt einer guten
+  Gewohnheit (zur Nachschau siehe E4).
+- **`AP2-DD-10` und `AP2-DD-11`.** Beide sind behoben und in 0.25.0 positiv nachgewiesen; an
+  ihrer Geltung ändert sich nichts.
+
+## 4. Grenze der Zusage
+
+**Die Regel verhindert keinen stillen Abbruch.** Sie entwertet nur den Schluss, den man daraus
+zöge. Der Abbruch bleibt eine Eigenschaft des Clients.
+
+**Sie ist `review`-prüfbar, nicht skriptprüfbar.** Wer ein Protokoll schreibt, muss sie anwenden;
+kein Werkzeug erzwingt sie. Ein Validator kann nicht sehen, ob eine Zeile „0 Aufrufe" aus einer
+Messung oder aus einem Abbruch stammt.
+
+**Der Positivbeleg im selben Lauf ist nicht immer herstellbar.** Ein Lauf, der vor dem ersten
+Werkzeugaufruf abbricht, erzeugt gar nichts – dann bleibt nur die Wiederholung in einer
+interaktiven Sitzung, so wie G-2 sie geführt hat. Die Regel macht diesen Mehraufwand
+verbindlich; billiger wird die Beweisführung dadurch nicht.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Zwei Anträge oder einer für `AP2-DD-13` und `AP2-DD-14`? | **Einer.** Beide Befunde beantworten dieselbe Frage – unter welchen Bedingungen ein Nachweis entstanden ist –, und die Abhilfe ist in beiden Fällen derselbe Absatz | `AP2-DD-14` hat damit keinen eigenen Antrag. Wer die Vertrauensschranke sucht, findet sie unter einem Titel über Nachweise |
+| E2 | Regel in den Testkatalog oder in D-23? | **Testkatalog**, D-23 nur fortschreiben | Die Forderung steht an zwei Stellen und muss bei Änderungen an beiden gepflegt werden |
+| E3 | Nachweise mit abgeschalteter Vertrauensprüfung weiterhin zulassen? | **Ja**, mit Ausweis im Protokoll. Ohne sie wäre für dieses Pack **kein** technischer Nachweis zu führen gewesen | Die Nachweise gelten dann für eine Umgebung, die vom Normalbetrieb abweicht – und der Normalbetrieb bleibt unbelegt, bis ihn jemand interaktiv prüft |
+| E4 | Bestehende Protokolle einmalig auf Abwesenheitsnachweise durchsehen? | **Ja**, einmalig und als Review, nicht als Testfall | Ein Reviewgang durch die bisherigen Protokolle. Findet er einen ungedeckten Abwesenheitsnachweis, wird daraus ein eigener Befund |
+| E5 | Den stillen Abbruch dem Hersteller melden? | **Zurückgestellt.** Das Framework führt keinen Herstellerkanal; `FEEDBACK_PROCESS.md` regelt den Weg nach innen | Ein Verhalten, das jede Automatisierung trifft, bleibt unadressiert – es steht in einem Protokoll, das der Hersteller nicht liest |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** |
+| Datum | 2026-09-11 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | E1 bis E5 wie vorgelegt: **ein** Antrag für beide Befunde; die Regel steht als Nummer 7 im Testkatalog, D-23 wird nur fortgeschrieben; Nachweise mit abgeschalteter Vertrauensprüfung bleiben zulässig, mit Ausweis im Protokoll; die **einmalige Durchsicht** der bestehenden Protokolle auf ungedeckte Abwesenheitsnachweise wird als Review durchgeführt; die Meldung an den Hersteller bleibt zurückgestellt. Ziel-Release 0.26.0 |
+| Umsetzung | **mit Release 0.26.0** – Einzelheiten und Nachweise in `leitwerk-core/CHANGELOG.md` |

package/.koolie/core/governance/change-requests/CR-2026-035-readme-in-der-regelablage.md

@@ -0,0 +1,115 @@
+# Änderungsantrag `CR-2026-035`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die erklärende README der Regelablage steht im Regelregister des Clients |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-11 |
+| Betroffene Artefakte | `clients/devin-desktop/root-template/.devin/rules/README.md`, `clients/claude-code/root-template/.claude/rules/README.md`, beide `manifest.json` (`core_paths`), `clients/README.md` (Abschnitt 5), `tests/scripts/validate-framework.py` (optional, siehe E3) |
+| Ebene laut Entscheidungsbaum 6 | Abbildungsschicht – Inhalt der Regelablage; betrifft **beide** Client Packs |
+| Art | Behebung von `AP2-DD-17` (Schwere: niedrig) |
+| Dringlichkeit | regulär |
+
+## 1. Anlass und Problem
+
+`devin rules list` führt die Regelablage als Regelmenge auf – und darin:
+
+```text
+README [Devin] manual
+```
+
+Die Datei lädt **nicht** automatisch. Sie steht aber im Register und ist mit dem Trigger `manual`
+**auf ausdrückliche Erwähnung hin ladbar**. Eine erklärende Datei in einem Verzeichnis, dessen
+Inhalt der Client als Regelmenge liest.
+
+### Warum das trotz niedriger Schwere zählt
+
+**Was in ihr steht, ist keine Regel, sondern Belegstand.** Die Datei führt `[DOK]`-Tabellen,
+VERIFY-Marker, ein Nummernschema und – bemerkenswert – die Zeichenlimits „12.000 je
+Workspace-Regeldatei, 6.000 für globale Regeln", also genau die Angabe, deren Einstufung
+`CR-2026-027` als für Devin Local unbelegt beanstandet.
+
+Wird die Datei geladen, tragen damit Aussagen **mit ausgewiesenem Belegvorbehalt** den Rang eines
+Regeltexts der Ebene 3. Das Verzeichnis ist die Regelablage; alles darin ist möglicher Kontext.
+Ein Belegstand gehört in ein Dokument, das erklärt – nicht in eines, das anweist.
+
+### Was das Register über die Ablage sagt
+
+Gegenprobe G-1 zählt in der Oberfläche **sechs** geladene beziehungsweise geführte Regeln: die
+vier Framework-Regeln, `global_rules` aus dem Benutzerprofil (`AP2-DD-15`) und diese README. Die
+**zweite** README des Packs – `.devin/README.md`, eine Ebene über der Regelablage – erscheint
+nicht.
+
+Daraus folgt, was die Abhilfe trägt: **Der Client registriert, was in der Regelablage liegt, und
+nicht, was daneben liegt.** Erschlossen aus der Zählung der Gegenprobe, nicht eigens gemessen.
+
+### Offen: das Frontmatter
+
+Die Datei trägt **kein Frontmatter**, der Client führt sie dennoch mit Trigger `manual`. Ob
+`manual` die dokumentierte Vorgabe für Regeldateien ohne `trigger` ist, ist nicht belegt – neue
+Klärungsfrage **K-25**. Für die Abhilfe ist das gleichgültig: Eine Datei, die nicht angewiesen
+werden soll, gehört nicht in die Ablage, unabhängig davon, mit welchem Trigger der Client sie
+führt.
+
+## 2. Vorgeschlagene Änderung
+
+**Empfohlen – die erklärende Datei verlässt die Regelablage.** Ihr Inhalt geht in die bestehende
+Laufzeit-README eine Ebene höher (`<RUNTIME_DIR>/README.md`) auf, als eigener Abschnitt
+„Regelablage". In der Regelablage bleibt damit nur, was Regel ist.
+
+Beide Packs sind betroffen; für `claude-code` ist die Wirkung unerhoben (**K-26**: Führt dieser
+Client eine README der Regelablage ebenfalls im Register?). Die Änderung ist dort trotzdem
+richtig – sie folgt aus der Zuständigkeit des Verzeichnisses, nicht aus dem Verhalten eines
+Clients.
+
+Beide Dateien stehen in `core_paths` der Manifeste. **`install.py --update` erneuert sie**; die
+Änderung erreicht bestehende Installationen ohne Handgriff, die alte Datei ist bei der Migration
+jedoch zu entfernen – sie wird durch das Update nicht gelöscht (Migrationshinweis erforderlich).
+
+Zwei Alternativen, mit ihren Kosten, damit die Entscheidung nicht ohne sie fällt:
+
+| Weg | Wirkung | Kosten |
+|---|---|---|
+| **A – verschieben (empfohlen)** | Die Regelablage enthält nur Regeln | Ein Migrationshinweis; ein Ort mehr, an dem der Belegstand zu suchen ist |
+| **B – Frontmatter `trigger: manual` und erster Satz „Dies ist keine Regel"** | Der Trigger ist ausdrücklich statt implizit | Sie bleibt im Register. Eine Datei, die sagt, sie sei keine Regel, ist eine Regel, die das sagt |
+| **C – unverändert lassen, in Abschnitt 5 des Packs ausweisen** | Nichts zu migrieren | Der Belegvorbehalt bleibt ladbar; der Befund wird beschrieben statt behoben |
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Den Inhalt der README.** Der Belegstand der Regelmechanismen ist wertvoll und bleibt
+  vollständig erhalten – er wechselt nur den Ort.
+- **Die Regeltexte, das Nummernschema und die Ladetrigger.** Unverändert.
+- **Die Aussage über die Zeichenlimits.** Sie steht und fällt mit `CR-2026-027`; dieser Antrag
+  nimmt ihr nur den Rang eines ladbaren Regeltexts.
+
+## 4. Grenze der Zusage
+
+**Die Ablage wird sauber, der Kanal bleibt.** Wer eine beliebige Datei in die Regelablage legt,
+erzeugt weiterhin einen Registereintrag. Das Framework kann das für seine eigenen Dateien
+entscheiden, nicht für fremde – und für Quellen außerhalb des Projekts schon gar nicht
+(`CR-2026-031`).
+
+**Für `claude-code` ist die Wirkung nicht gemessen** (K-26). Die Änderung ist dort begründet,
+aber nicht belegt veranlasst.
+
+**Der Befund ist niedrig und bleibt es.** Die Datei lädt nicht von selbst; es braucht eine
+ausdrückliche Erwähnung. Gemeldet wird hier eine Möglichkeit, kein beobachteter Schaden.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Welcher der drei Wege? | **A – verschieben.** Ein Verzeichnis, das als Regelmenge gelesen wird, enthält nur Regeln | Migrationshinweis nötig; `install.py --update` legt die neue Fassung an, entfernt die alte aber nicht |
+| E2 | Auch bei `claude-code` ändern, obwohl dort unerhoben? | **Ja.** Die Begründung ist die Zuständigkeit des Verzeichnisses, nicht das Verhalten eines Clients | Eine Änderung ohne Befund am betroffenen Pack – vertretbar, aber nicht durch eine Messung veranlasst |
+| E3 | Prüfung aufnehmen, die Nicht-Regeltexte in der Regelablage meldet? | **Ja.** In `clients/*/root-template/<Regelablage>/` darf nur liegen, was dem Nummernschema folgt. Sonde nach D-23: eine Fremddatei in einer Kopie – die Prüfung meldet | Sie prüft die **Vorlage**, nicht die installierte Ablage: Was ein Projekt dort selbst ablegt, sieht sie nicht |
+| E4 | K-25 (Trigger-Vorgabe ohne Frontmatter) jetzt klären? | **Nein, nur erfassen.** Für die Abhilfe ist die Antwort gleichgültig | Eine unbeantwortete Frage mehr in der Klärungstabelle; sie wird erst wichtig, wenn ein Pack sich auf den Standardtrigger verlassen will |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** |
+| Datum | 2026-09-11 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | E1 bis E4 wie vorgelegt: **Weg A** – der erklärende Text verlässt die Regelablage und geht in die Laufzeit-README eine Ebene höher auf; die Änderung gilt für **beide** Packs, auch wenn die Wirkung bei `claude-code` unerhoben ist (K-26); die Prüfung auf Nicht-Regeltexte in der Vorlage der Regelablage wird aufgenommen; K-25 wird nur erfasst. Migrationshinweis erforderlich – `install.py --update` löscht die alte Datei nicht. Ziel-Release 0.26.0 |
+| Umsetzung | **mit Release 0.26.0** – Einzelheiten und Nachweise in `leitwerk-core/CHANGELOG.md` |

package/.koolie/core/governance/change-requests/CR-2026-036-ortsangaben-hook-konfiguration.md

@@ -0,0 +1,108 @@
+# Änderungsantrag `CR-2026-036`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Drei Dokumentstellen nennen weiter den Ort der Hook-Konfiguration, den D-32 abgelöst hat – und nichts vergleicht sie mit dem Manifest |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-11 |
+| Betroffene Artefakte | `clients/devin-desktop/root-template/.devin/README.md` (Zeile 12), `docs/PLACEHOLDER_REGISTRY.md` (Zeile 38), `docs/RUNTIME_GLOSSARY.md` (Zeile 34), `tests/scripts/validate-framework.py` (neue Prüfung 20) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Dokumentation der Abbildung und Validator |
+| Art | Behebung eines Befundes aus der Antragsarbeit zu `AP2-DD-15`/`-16` (Sitzung 2026-09-11); **keine AP2-Kennung** |
+| Dringlichkeit | regulär; die erste Stelle wird jedoch in jede Installation ausgeliefert |
+
+## 1. Anlass und Problem
+
+D-32 hat mit 0.25.0 entschieden: Die Hook-Konfiguration des Packs `devin-desktop` steht in der
+Berechtigungsdatei unter `hooks`; **eine eigene Hook-Datei wird nicht mehr erzeugt.** Prüfung 18
+meldet eine zurückgebliebene `hooks.v1.json` aus einer früheren Installation als Warnung.
+
+Drei Stellen im Kern sagen weiterhin das Gegenteil:
+
+| Stelle | Aussage |
+|---|---|
+| `clients/devin-desktop/root-template/.devin/README.md:12` | listet `hooks.v1.json` unter den ausgelieferten Dateien: „Lebenszyklus-Hooks … Erzeugt aus `leitwerk-core/framework/runtime/hooks.json`" |
+| `docs/PLACEHOLDER_REGISTRY.md:38` | `<HOOKS_FILE>` = `.devin/hooks.v1.json` |
+| `docs/RUNTIME_GLOSSARY.md:34` | Hook-Konfiguration = `.devin/hooks.v1.json` |
+
+**Das Manifest ist richtig:** `runtime_placeholders["<HOOKS_FILE>"]` steht auf `.devin/config.json`,
+und `clientmap.py` wie `validate-framework.py` lesen es von dort. Die Abweichung liegt also
+nicht zwischen Dokument und Wirklichkeit, sondern **zwischen der maschinenlesbaren Quelle und
+ihrer menschenlesbaren Fassung** – und nichts vergleicht die beiden.
+
+### Die erste Stelle wird ausgeliefert
+
+`.devin/README.md` steht in `core_paths` des Manifests. Sie landet bei jeder Installation im
+Projekt und wird von `install.py --update` erneuert. Dort beschreibt sie seit 0.25.0 eine Datei,
+die die Installation **nicht anlegt** – und deren Vorhandensein Prüfung 18 als Rest einer
+früheren Installation meldet.
+
+**Ein ausgeliefertes Dokument beschreibt damit genau den Zustand, den eine Prüfung desselben
+Releases als Altlast anzeigt.**
+
+### Der Befundtyp ist bekannt
+
+Eine Aussage, die ihren Gegenstand überlebt hat. Dasselbe Muster wie in 0.23.0, als der
+Steuerungsabschnitt der Roadmap zwei Releases lang einen Befund als offen führte, den das
+Protokoll als behoben auswies. Gefunden hat es beide Male das Lesen, nicht eine Prüfung – hier
+beim Zusammentragen der Belegstellen für `CR-2026-031`.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Die drei Stellen nachziehen.** In der Laufzeit-README tritt an die Stelle der Zeile zu
+   `hooks.v1.json` ein Zusatz in der Zeile zu `config.json`: Die Datei trägt Berechtigungen
+   **und** Hooks; der Ort folgt D-32. Registrierungstabelle und Glossar nennen
+   `.devin/config.json`.
+
+2. **Prüfung 20 vergleicht Tabelle und Manifest.** Die Client-Spalten von
+   `PLACEHOLDER_REGISTRY.md` und `RUNTIME_GLOSSARY.md` werden je Pack gegen dessen
+   `manifest.json` geprüft – Wert für Wert, für jeden Begriff mit Manifestentsprechung
+   (Laufzeitschicht, Berechtigungsdatei, Regelablage, Skill-Ablage, Agentenprofile,
+   Wurzel-Anweisungsdatei, Hook-Konfiguration, MCP-Konfiguration).
+
+   Sonde nach D-23: Ein Wert wird in einer Kopie verfälscht – die Prüfung meldet ihn.
+   Gegenprobe: Ein Begriff **ohne** Manifestfeld („Nutzerlokale Überschreibung") bleibt
+   unbeanstandet, und ein Pack ohne eigene Hook-Datei (`<HOOKS_FILE>` gleich
+   `<PERMISSIONS_FILE>`) gilt als übereinstimmend, nicht als Fehler.
+
+3. **Migrationshinweis.** Eine bestehende Installation behält ihre `hooks.v1.json`, bis jemand
+   sie löscht. Prüfung 18 meldet sie; der Hinweis nennt den Handgriff ausdrücklich.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **D-32 und die Abbildung.** Beide sind richtig und bleiben unverändert; korrigiert wird, was
+  über sie geschrieben steht.
+- **Die Manifeste.** Sie führen den richtigen Wert. Dieser Antrag macht die Dokumentation an sie
+  anschlussfähig, nicht umgekehrt.
+- **Prüfung 18.** Sie bleibt, wie sie ist – zur möglichen Erweiterung siehe E3.
+
+## 4. Grenze der Zusage
+
+**Prüfung 20 prüft Übereinstimmung, nicht Richtigkeit.** Steht im Manifest ein falscher Pfad,
+sind Tabelle und Manifest danach einig – und beide falsch. Was den Manifestwert prüft, ist die
+Installation selbst und der Nachweis an ihr (D-23, AP2).
+
+**Sie deckt nur Zeilen mit Manifestentsprechung ab.** Begriffe ohne Feld – nutzerlokale
+Überschreibung, künftige Ergänzungen – bleiben ungeprüft und altern weiter still.
+
+**Sie hätte diesen Befund gefunden, nicht aber die README.** Die Laufzeit-README nennt Dateinamen
+in Fließtext, kein Platzhalterfeld; dafür braucht es E3 oder weiterhin das Lesen.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Die drei Stellen nachziehen? | **Ja**, ohne Vorbehalt. Eine davon wird ausgeliefert | Keiner, außer der Migration einer zurückgebliebenen Datei |
+| E2 | Prüfung 20 aufnehmen? | **Ja.** Sie schließt die Naht zwischen Manifest und Dokumenttabellen – die Naht, an der dieser Befund entstanden ist | Sie bindet zwei Dokumenttabellen an das Manifestformat: Ändert sich das Format, ist die Prüfung mitzuändern |
+| E3 | Prüfung 18 um die Vorlagen erweitern (kein verwaister Hook-Dateiname in einem `root-template`)? | **Ja.** Die Liste der verwaisten Dateinamen steht bereits im Validator; sie auch gegen die ausgelieferten READMEs zu halten, kostet wenige Zeilen | Eine Prüfung auf Dateinamen im Fließtext meldet auch eine Nennung, die den Ort erklärt statt ihn zu behaupten. Ein Fehlalarm ist möglich |
+| E4 | Eigener Antrag oder Nachtrag zu `CR-2026-029`? | **Eigener Antrag.** `CR-2026-029` ist entschieden und umgesetzt; ein umgesetzter Antrag wird nicht nachträglich erweitert | Die Ursache steht in einem Antrag, ihre Folgen in einem zweiten. Der Verweis muss die Verbindung tragen |
+| E5 | Den Befund als AP2-Befund führen? | **Nein.** Er stammt nicht aus einem AP2-Lauf, sondern aus der Antragsarbeit dieser Sitzung. Der Antrag selbst ist der Nachweis | Die Befundzählung des AP2-Protokolls bleibt bei 17 und erfasst damit nicht alles, was in seinem Umfeld gefunden wurde |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** |
+| Datum | 2026-09-11 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | E1 bis E5 wie vorgelegt: Die drei Stellen werden nachgezogen; Prüfung 20 hält die Client-Spalten von `PLACEHOLDER_REGISTRY.md` und `RUNTIME_GLOSSARY.md` je Pack gegen das Manifest; Prüfung 18 wird auf die `root-template`-Vorlagen ausgedehnt; eigener Antrag statt Nachtrag zu `CR-2026-029`; **keine** AP2-Kennung. Ziel-Release 0.26.0 |
+| Umsetzung | **mit Release 0.26.0** – Einzelheiten und Nachweise in `leitwerk-core/CHANGELOG.md` |

package/.koolie/core/governance/change-requests/CR-2026-037-meldender-hook-clientgebunden.md

@@ -0,0 +1,133 @@
+# Änderungsantrag `CR-2026-037`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Das meldende Hook-Skript des Kerns nennt die Laufzeitschicht eines Clients – die Semantikabbildung erreicht nur den durchsetzenden Hook |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-11 |
+| Betroffene Artefakte | `tests/scripts/hook-overlay-status.py` (Zeilen 8, 19, 21), `clientmap.py` (Hook-Kommando), `tests/scripts/validate-framework.py` (neue Prüfung 21), `governance/DECISION_LOG.md` (Fortschreibung D-30) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Laufzeitskript und Semantikabbildung; betrifft **beide** Client Packs |
+| Art | Behebung eines Befundes aus der Antragsarbeit zu `AP2-DD-15`/`-16` (Sitzung 2026-09-11); **keine AP2-Kennung** |
+| Dringlichkeit | regulär – H3 ist ohnehin unbeobachtet (siehe Abschnitt 4) |
+
+## 1. Anlass und Problem
+
+`hook-overlay-status.py` meldet beim Sitzungsstart den Overlay-Status (Zusage **H3**). Das Skript
+liegt im Kern, der seit D-15 werkzeugneutral ist. Es nennt an drei Stellen einen Client:
+
+```python
+# Zeile 8 (Docstring): Liest project-overlay/OVERLAY.md und .devin/rules/20-project-overlay.md
+root = os.environ.get("DEVIN_PROJECT_DIR", os.getcwd())          # Zeile 19
+candidates = [os.path.join(root, ".devin", "rules", "20-project-overlay.md"), …]   # Zeile 21
+```
+
+Das Manifest von `claude-code` führt für dieselbe Rolle `CLAUDE_PROJECT_DIR`
+(`hook_project_dir_var`). Das Kommando wird korrekt gerendert – der Pfad zum Skript steht in der
+Variablen dieses Clients –, **aber im Skript ist sie unbekannt**. Dort greift der Rückfall auf
+`os.getcwd()`, und der erste Kandidat (`.devin/rules/…`) kann bei diesem Client nie zutreffen.
+
+**Folge bei `claude-code`:** Der Status wird allein aus `project-overlay/OVERLAY.md` hergeleitet,
+und das nur, wenn das Arbeitsverzeichnis beim Sitzungsstart das Projektverzeichnis ist – **für
+keinen der beiden Clients belegt**. Trifft es nicht zu, meldet das Skript `unbekannt`; nach
+Abschnitt 3 der Wurzel-Anweisungsdatei soll der KI-Client dann nur lesend arbeiten. Die Meldung
+wäre also nicht bloß ungenau, sie hätte eine Wirkung.
+
+### Warum das den Kern betrifft
+
+D-30 hat entschieden:
+
+> Eine Semantikabbildung gilt **auch für die Skripte, die die Zusage durchsetzen** – nicht nur
+> für die erzeugte Konfiguration.
+
+`hook-check-secrets.py` löst das ein: Es liest die Werkzeugnamen aus `hook_tools` **aller** Packs.
+Das zweite Hook-Skript ist bei dieser Entscheidung nie betrachtet worden – **weil es nichts
+durchsetzt, sondern meldet.** Die Begründung von D-30 trägt aber genauso weit: Ein Skript, das in
+einer Sitzung läuft, darf die Laufzeitschicht nicht raten.
+
+### Warum keine Prüfung es sieht
+
+| Prüfung | Warum sie schweigt |
+|---|---|
+| 14 (kein Client als Akteur) | Ihr Muster ist `\bDevin\b`, **zeichengetreu**. `DEVIN_PROJECT_DIR` trifft es nicht |
+| 12 (Nennung einer nicht installierten Laufzeitschicht) | Sie warnt nur, wenn die Laufzeitschicht **fehlt**. In diesem Repositorium liegt eine `devin-desktop`-Testinstallation – der Pfad existiert |
+
+Beide Blindstellen sind strukturell, nicht zufällig: Die eine unterscheidet Produktname von
+Akteursnennung und muss dafür Groß- und Kleinschreibung ernst nehmen; die andere prüft
+Verweisziele, nicht Neutralität. Eine Ausweitung von Prüfung 14 auf Kleinschreibung wäre teuer
+und falsch – `.devin/` steht in Glossar, Registrierungstabelle und der Rückfallabbildung des
+Validators an Stellen, an denen es **hingehört**.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Projektverzeichnis und Regelablage kommen als Argumente**, nicht aus der Umgebung. Die
+   Abbildung setzt sie aus `hook_project_dir_var` und `runtime_placeholders["<RULES_DIR>"]`:
+
+   ```text
+   python "$PROJEKTVERZEICHNIS/<CORE_DIR>/tests/scripts/hook-overlay-status.py" "$PROJEKTVERZEICHNIS" "<RULES_DIR>"
+   ```
+
+   `PROJEKTVERZEICHNIS` steht dabei für die Variable, die das Manifest des Packs unter
+   `hook_project_dir_var` führt – der Kern nennt sie nicht.
+
+   Das ist die Begründung aus **D-31**, angewandt auf einen zweiten Fall: Der Wert steht im
+   Kommando, das der Client ohnehin ausführt, statt in einer Umgebung, von der für kein Pack
+   belegt ist, dass sie den Hook-Prozess erreicht.
+
+2. **Rückfall ohne Argumente:** Arbeitsverzeichnis und ausschließlich `project-overlay/OVERLAY.md`
+   – werkzeugneutral, mit Kommentar, dass dies der Notweg ist und nicht der vorgesehene Pfad.
+
+3. **Prüfung 21:** Ein Hook-Skript des Frameworks nennt **keine** clientgebundene
+   Umgebungsvariable und keinen Laufzeitpfad eines Packs. Geltungsbereich ausdrücklich die
+   Hook-Skripte – nicht der Validator, der eine dokumentierte Rückfallabbildung führt
+   (`validate-framework.py`, Kommentar bei Zeile 235).
+
+   Sonde nach D-23: In einer Kopie wird eine solche Variable eingesetzt – die Prüfung meldet sie.
+   Gegenprobe: `hook-check-secrets.py`, das seine Namen aus den Manifesten liest, bleibt
+   unbeanstandet.
+
+4. **D-30 wird fortgeschrieben:** Die Semantikabbildung gilt für **jedes** Skript, das in einer
+   Sitzung läuft – auch für das meldende. Ein neuer Record ist nicht nötig; die Entscheidung ist
+   dieselbe, nur ihr Geltungsbereich war zu eng beschrieben.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Was gemeldet wird.** Der Overlay-Status und seine drei Werte (`aktiv`, `inaktiv`,
+  `unbekannt`) bleiben unverändert; nur die Herkunft der Pfade ändert sich.
+- **Der durchsetzende Hook.** `hook-check-secrets.py` ist seit D-30 in Ordnung und wird nicht
+  angefasst.
+- **Die Rückfallabbildung des Validators.** Sie bleibt zulässig und ausdrücklich außerhalb von
+  Prüfung 21 (siehe E3).
+
+## 4. Grenze der Zusage
+
+**Die Änderung macht die Meldung richtig, nicht beobachtet.** H3 ist bei `devin-desktop`
+unbeobachtet – das Protokoll führt die Zeile so, und der Hook lief bis 0.24.0 ohnehin nicht.
+**Dieser Befund hat sich im Betrieb nie gezeigt, weil die Zusage, an der er hängt, selbst nie
+gezeigt wurde.** Er ist durch Lesen gefunden, nicht durch Messen.
+
+**Ob `os.getcwd()` beim Sitzungsstart das Projektverzeichnis ist, bleibt unbelegt.** Nach dieser
+Änderung nur noch als Notweg – vorher war es der Normalfall für eines von zwei Packs.
+
+**Prüfung 21 prüft Skripte, nicht Wirkung.** Ein Hook-Skript, das seine Pfade sauber übergeben
+bekommt und trotzdem den falschen Status meldet, fällt ihr nicht auf. Dafür braucht es einen
+Nachweis an einer Installation – denselben, der für H3 aussteht.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Argumente oder Umgebungsvariable? | **Argumente**, mit der Begründung aus D-31 | Das Hook-Kommando wird länger und trägt zwei Werte mehr, die bei jeder Abbildungsänderung mitzupflegen sind |
+| E2 | Regelablage als zweites Argument oder Kandidat streichen? | **Als Argument.** Streichen würde ändern, *was* gemessen wird: Die gerenderte Regeldatei trägt den Status ebenso wie das Overlay | Ein Argument mehr. Wer die Regelablage umbenennt, muss an die Abbildung denken – der Validator meldet es nicht |
+| E3 | Geltungsbereich von Prüfung 21: Hook-Skripte oder alle Skripte des Kerns? | **Hook-Skripte.** Der Validator führt eine dokumentierte Rückfallabbildung auf `.devin/`, die er braucht, wenn kein Pack gefunden wird | Die Rückfallabbildung bleibt ungeprüft. Sie ist begründet, aber sie ist auch eine Client-Bindung im Kern |
+| E4 | D-30 fortschreiben oder neuer Decision Record? | **Fortschreiben**, mit Datum und Verweis auf diesen Antrag | Ein Record, der zwei Sachverhalte trägt; die Historie steht im Änderungsverlauf, nicht in zwei Records |
+| E5 | H3 im selben Zug nachweisen? | **Nein, getrennt.** Der Nachweis gehört zu AP2 und braucht eine Sitzung mit Aufzeichnung, nicht diesen Antrag | Die Zusage bleibt bis dahin unbeobachtet – jetzt mit richtigen Pfaden, aber weiterhin ohne Beleg |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** |
+| Datum | 2026-09-11 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | E1 bis E5 wie vorgelegt: Projektverzeichnis und Regelablage kommen als **Argumente** aus der Abbildung; der Regelablage-Kandidat bleibt erhalten; Prüfung 21 gilt eng für die Hook-Skripte, die Rückfallabbildung des Validators bleibt ausgenommen; D-30 wird fortgeschrieben statt ersetzt; der Nachweis für H3 bleibt getrennt und Teil von AP2. Ziel-Release 0.26.0 |
+| Umsetzung | **mit Release 0.26.0** – Einzelheiten und Nachweise in `leitwerk-core/CHANGELOG.md` |