@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-015-versionskette.md

@@ -0,0 +1,150 @@
+# Änderungsantrag `CR-2026-015`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Neun Lücken der Versionskette, gefunden beim Ausführen von `FW-VN-01` |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | `governance/RELEASE_PROCESS.md`; `checklists/11-framework-release.md` und die übrigen zehn Checklisten; `prompts/*` (13 Dateien); `templates/MR_AI_DISCLOSURE.md`; alle 13 Skills (`SKILL.md`, `CHANGELOG.md`, `EXAMPLES.md`); `tests/scripts/validate-framework.py`; `examples/example-mr-description.md`, `example-ergebnisbericht.md`; 30 Kerndateien mit der Bezeichnung des Nutzungsvermerks; `tests/TEST_CATALOG.md`; neu: `tests/protocols/2026-09-10-FW-VN-01.md` und `-wiederholung.md` |
+| Ebene laut Entscheidungsbaum 6 | Core (Governance-Regeltext, Ebene 3) und Prüfwerkzeug |
+| Art | Fehlerbehebung, Verschärfung und eine Regeleinschränkung |
+| Dringlichkeit | regulär (Review-Zyklus) |
+
+## 1. Anlass und Problem
+
+`FW-VN-01` prüft die Nachweiskette aus `RELEASE_PROCESS.md` Abschnitt 8: Framework-Version →
+Overlay-Version → Skill-Versionen → Berechtigungsstand → KI-Nutzungsvermerk im Merge Request →
+Vorfall- und Ausnahmeregister. Der Testfall ist der zweite Review-Testfall des Katalogs
+überhaupt. Ergebnis: **`fehlgeschlagen`, neun Befunde in drei der sechs Glieder.**
+
+**Die Kette ist nirgends gebrochen.** In der Referenzinstallation stimmt jede Angabe mit jeder
+anderen überein. Sie hält aber ausschließlich durch Sorgfalt – und an einer Stelle hat die
+Sorgfalt über zwölf Releases nachgelassen, ohne dass es jemand bemerkt hat.
+
+**Der tragende Befund: Eine Versionsangabe, die sich nie ändert, unterscheidet keine zwei
+Zeitpunkte.** Alle 13 Skills stehen unverändert auf `0.1.0`, obwohl alle 13 `SKILL.md`
+geändert wurden – 126 Zeilen in den Releases 0.5.0 und 0.7.0. Kein Skill-Änderungsverlauf hat
+dafür einen Eintrag bekommen. Das ist kein Ermessen: `08-skill-conventions.md` Abschnitt 7
+stuft solche Änderungen als PATCH ein, und die Release-Checkliste verlangt die Pflege je
+geändertem Skill als **MUSS**. Dieselbe Lücke, ohne jede Pflicht dahinter, tragen elf
+Checklisten und dreizehn Prompts.
+
+**Wirksam wird das im Nutzungsvermerk.** Die Kurzform für Kontrollstufe niedrig – den Regelfall
+– nannte weder Framework- noch Overlay-Version; ihre einzige Versionsangabe waren die Skills.
+Das synthetische Beispiel des Frameworks zeigte es unfreiwillig:
+
+    - Verwendete Skills: fw-change-analyze v0.1.0, fw-change-small v0.1.0
+
+Beide Werte waren für jedes Release von 0.1.0 bis 0.12.0 identisch. Bei Kontrollstufe niedrig
+enthielt ein Merge Request damit keine einzige Versionsangabe, die sich je geändert hat – die
+Kette war dort formal vollständig und inhaltlich leer.
+
+**Der Validator prüft, ob Versionsfelder da sind, nie ob sie stimmen.** Fünf Sonden mit
+bekanntem Defekt blieben sämtlich unbemerkt: Steckbriefangabe gegen `VERSION`, Manifestwert
+gegen Steckbrief, Laufzeitfassung gegen Steckbrief, Skill-Version gegen den eigenen
+Änderungsverlauf, und `banane` als Versionswert. Drei Gegenproben wurden jede gemeldet. Das ist
+exakt die Blindstellenform, die D-23 an vier anderen Prüfungen gefunden hat, hier auf das
+Merkmal angewandt, um das es in diesem Testfall geht.
+
+**Die Overlay-Version steht an drei Stellen** – Steckbrief, Manifest, Laufzeitfassung – und
+keine wurde gegen eine andere geprüft. Für den Overlay-*Status* hat D-23 genau diese Lücke
+geschlossen; für die Version blieb sie offen.
+
+**Das Kettenglied heißt anders als sein Artefakt.** Abschnitt 8 nennt den
+„**KI**-Nutzungsvermerk"; die Vorlage, auf die überall verwiesen wird, hieß
+„**Devin**-Nutzungsvermerk". Im Kern standen 39 Nennungen der alten Form in 29 Dateien. Das ist
+die unerledigte Hälfte von Befund B1 aus `FW-KO-02` – dort wurde nur die Laufzeitschicht
+umgestellt – und `CR-2026-005` hatte dieselbe Umbenennung bereits für 0.5.0 als Nebeneffekt
+verzeichnet. Zweimal angekündigt, zweimal nicht zu Ende geführt.
+
+**Eine Kernvorlage nannte einen Client.** Beide Textblöcke der Vermerkvorlage trugen die
+Überschrift `### KI-Unterstützung (Devin Desktop)`. Die Vorlage wird in **jedes** Client Pack
+installiert; ein Projekt mit dem Pack `claude-code` hätte den Produktnamen eines Werkzeugs in
+seinen Merge Request geschrieben, das bei ihm nicht im Einsatz ist. Derselbe Befundtyp wie B2
+aus `FW-KO-02`.
+
+**Die Zusage aus Abschnitt 1.2 stand seit 0.1.0 unerfüllt im Regeltext.** Sie verlangt von fünf
+Artefaktklassen eine Referenz auf die kompatible Framework-Version. Erfüllt hat sie genau eine:
+das Overlay – ausgerechnet die Klasse, die nicht im Kern liegt.
+
+## 2. Vorgeschlagene Änderung
+
+Sieben der neun Befunde lassen nur eine Auflösungsrichtung zu. Zwei ändern eine Regel und nicht
+nur ihre Durchsetzung; sie wurden der zweiten Rolle einzeln vorgelegt (Protokoll, E1 und E2).
+
+**Der Validator bekommt Prüfung 13 (Versionskette).** Sie vergleicht die drei Ablageorte der
+Overlay-Version miteinander, die Steckbriefangabe zur kompatiblen Framework-Version gegen
+`leitwerk-core/VERSION` und jedes Versionsfeld gegen die Form `MAJOR.MINOR.PATCH`; zusätzlich
+muss eine Skill-Version einen Eintrag im eigenen Änderungsverlauf haben. Damit hält die Kette
+durch einen Mechanismus statt durch Disziplin – die Konsequenz aus D-23.
+
+**Die Skill-Versionen werden auf `0.1.1` angehoben**, mit einem Eintrag je Änderungsverlauf
+(E2, bestätigt). Verworfen wurde eine Ausnahmeregel für reine Pfad- und Namensanpassungen: Die
+Grenze wäre nicht prüfbar, weil `CR-2026-009` 994 Pfadnennungen geändert hat, darunter Verweise
+auf Vorlagen und Checklisten, die ein Skill anwendet – „nur ein Pfad" ist eine Aussage über die
+Absicht, nicht über die Datei. Ebenfalls verworfen wurde das Streichen der Skill-Version: Sie
+löst zwei Befunde auf einmal, nimmt dem Nutzungsvermerk aber die Angabe, welcher Skill in
+welchem Stand gelaufen ist – und die wertet `pilot/METRICS.md` je Vermerk aus.
+
+Der Preis ist benannt: `08-skill-conventions.md` Abschnitt 7 verlangt bei jeder Versionsänderung
+die erneute Ausführung der Testfälle in `TESTS.md`. Diese sind sämtlich `sitzung` und hängen an
+AP2, bleiben also bis dahin offen. Eine offene Testpflicht ist ehrlicher als eine
+Versionsangabe, die nichts aussagt: Die erste ist in AP2 sichtbar, die zweite nicht.
+
+**Checklisten und Prompts werden gleich behandelt** und bekommen erstmals eine Pflicht: Die
+Release-Checkliste fordert die Versionspflege künftig auch für sie. Ohne diesen Punkt hätte das
+Release eine Regel ausgeliefert, die im selben Stand schon verletzt ist.
+
+**Abschnitt 1.2 wird eingeschränkt statt eingelöst** (E1, bestätigt). Eine kompatible
+Framework-Version nennen nur die Artefakte, die vom Kern **abweichen können**: das Overlay
+(gehört dem Projekt) und das Client Pack (bildet einen fremden Client ab). Skills, Checklisten
+und Prompts werden byte-gleich im Release ausgeliefert; ihre kompatible Framework-Version ist
+`leitwerk-core/VERSION` im selben Verzeichnis. Verworfen wurde das Einlösen der Zusage: Es
+entstünde in 35 Dateien ein Wert, der bei jedem Release nachzuziehen wäre – genau die
+Doppelpflege, die D-16, D-17 und D-20 beseitigt haben – und der veraltet, ohne dass es auffällt.
+
+**Die Umbenennung des Nutzungsvermerks wird zu Ende geführt**, im Kern und nicht nur in der
+Laufzeitschicht: 39 Nennungen in 29 Dateien. Die Überschrift der Vorlage wird clientneutral,
+und ihr Ausfüllhinweis spricht nicht mehr von einem einzelnen Produkt.
+
+**Die Kurzform des Vermerks nennt Framework- und Overlay-Version.** Zwei Zeilen. Ohne sie hat
+die Kette bei Kontrollstufe niedrig keinen Anker.
+
+Änderungsverzeichnis, Änderungsanträge und Testprotokolle bleiben unangetastet – sie sind
+historische Belege und dürfen nicht rückwirkend geglättet werden.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. `RELEASE_PROCESS.md` ist Governance-Regeltext der Ebene 3; die Prüfung im Validator ist Werkzeug, kein Regeltext.
+- [x] Verschärfungsprinzip eingehalten? — Acht der neun Befunde werden durch Verschärfung oder Klarstellung aufgelöst. Eine Auflösung schränkt eine Regel **ein** (E1) und ist deshalb einzeln begründet und vorgelegt worden: Die Zusage aus Abschnitt 1.2 war für drei der fünf Klassen nie erfüllbar, ohne eine Doppelpflege zu erzeugen, die drei Decision Records zuvor beseitigt haben. Der Nachweis wird dadurch nicht schwächer – der Wert steht im selben Verzeichnis.
+- [x] Widerspruchsfreiheit geprüft? — `FW-KO-04` und der Validator melden 0 Fehler. Die Umbenennung des Nutzungsvermerks beseitigt eine Abweichung zwischen Abschnitt 8 und dem Artefakt, auf das er zeigt.
+- [x] Laufzeitfassungen betroffen? — Nein. Die vier Regeltexte der Laufzeitschicht sagten seit 0.12.0 bereits „KI-Nutzungsvermerk". Betroffen ist die **Saat**: `templates/MR_AI_DISCLOSURE.md` behält in einem bestehenden Projekt seine Fassung. Migrationshinweis im CHANGELOG.
+- [x] Belegstatus korrekt? — Unverändert. Dieser Antrag berührt keine Aussage über Produktfunktionen eines Clients.
+- [x] Test- und Validierungsbedarf? — `FW-VN-01` ist durchgeführt, die Befunde sind behoben, der Wiederholungslauf meldet alle fünf Sonden. Die Gegenzeichnung durch eine zweite Rolle steht aus, siehe Abschnitt 5.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Prüfung 13 kann in einem bestehenden Projekt Fehler melden, deren Ursache älter ist als dieses Release: eine nicht nachgezogene Steckbriefangabe oder auseinandergelaufene Overlay-Versionen. Das ist der Zweck der Prüfung; die Behebung sind zwei Zeilen und steht im CHANGELOG.
+- [x] Dokumentation? — CHANGELOG, Decision Log, Roadmap, Testkatalog, zwei Testprotokolle.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Eine Nachweiskette ist kein Formular. Sie taugt genau so weit, wie ihre Glieder zwei Zeitpunkte unterscheiden können – und eine Versionsangabe, die sich über zwölf Releases nicht bewegt, kann das nicht. Dass niemand es bemerkt hat, ist der eigentliche Befund: Der Validator prüfte die Anwesenheit der Felder und niemals ihren Inhalt. Mit Prüfung 13 hält die Kette durch einen Mechanismus; mit den angehobenen Versionen sagt sie wieder etwas aus. |
+| Ziel-Release | 0.13.0 |
+| Decision-Log-Eintrag | D-25 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] V1: Prüfung 13 vergleicht Steckbrief, Manifest und Laufzeitfassung; abweichende Overlay-Versionen sind ein Fehler
+- [x] V2: Prüfung 13 vergleicht die Steckbriefangabe zur kompatiblen Framework-Version gegen `leitwerk-core/VERSION` (`0.N.x` oder exakt)
+- [x] V6: Versionsfelder werden gegen `MAJOR.MINOR.PATCH` geprüft; eine Skill-Version ohne Eintrag im eigenen Änderungsverlauf ist ein Fehler
+- [x] V3/V4 (E2): 13 Skills auf `0.1.1` mit Eintrag je Änderungsverlauf; 10 Checklisten und 13 Prompts auf `0.1.1`; `11-framework-release.md` auf `0.2.0` wegen der neuen Pflicht
+- [x] V5 (E1): `RELEASE_PROCESS.md` Abschnitt 1.2 auf Overlays und Client Packs eingeschränkt, mit Begründung im Regeltext
+- [x] V7: „Devin-Nutzungsvermerk" → „KI-Nutzungsvermerk" in 29 Kerndateien (39 Nennungen). **Nennungen im Kern: 39 → 0**
+- [x] V8: Überschrift und Ausfüllhinweis der Vermerkvorlage clientneutral; dieselbe Überschrift in drei weiteren Dateien nachgezogen
+- [x] V9: Kurzform des Vermerks nennt Framework- und Overlay-Version; beide Beispiele nachgezogen
+- [x] Wiederholungslauf `FW-VN-01`: alle fünf Sonden gemeldet, Ausgangs- und Schlusslauf 0 Fehler
+- [x] Validator, `FW-KO-04` und `install.py --check`: 0 Fehler, 0 Warnungen
+- [x] **Gegenzeichnung** durch `<FRAMEWORK_OWNER>` am 2026-09-10 erfolgt; die beiden Auflösungen mit Ermessensspielraum wurden einzeln vorgelegt und entschieden (E1: Abschnitt 1.2 einschränken statt einlösen; E2: Skill-Versionen anheben). `FW-VN-01` steht damit auf `bestanden`. Nachgetragen nach dem Merge des Releases
+- [ ] **Folgearbeit:** Die Testfälle in `TESTS.md` je Skill sind wegen der Versionsanhebung erneut auszuführen (`08-skill-conventions.md` Abschnitt 7). Sie sind sämtlich `sitzung` und hängen an AP2; in der Roadmap vermerkt

package/.koolie/core/governance/change-requests/CR-2026-016-ap2-claude-code.md

@@ -0,0 +1,127 @@
+# Änderungsantrag `CR-2026-016`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Drei Befunde aus AP2: Eine Kernzusage verfiel beim Rendern, 18 Regeln waren wirkungslos, und die vorgeschriebene Prüfung war nie gelaufen |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | `clients/claude-code/manifest.json`; `install.py`; `tests/scripts/validate-framework.py`; `clients/claude-code/CLIENT_PACK.md`; `tests/protocols/2026-09-10-AP2-claude-code.md` |
+| Ebene laut Entscheidungsbaum 6 | Abbildungsschicht (Client Pack) und Prüfwerkzeug |
+| Art | Fehlerbehebung, sicherheitsrelevant |
+| Dringlichkeit | regulär – kein Projekt setzt das Pack produktiv ein |
+
+## 1. Anlass und Problem
+
+`AP2` für das Client Pack `claude-code` ergab acht Befunde
+(`tests/protocols/2026-09-10-AP2-claude-code.md`). Zwei davon sind schwer, ein dritter kam bei
+der Behebung dazu. Alle drei haben dieselbe Ursache: **Das Pack ist nie gegen eine reale
+Installation gefahren worden**, obwohl der Client die ganze Zeit erreichbar war.
+
+**AP2-CC-01 – die Zusage S4 verfiel beim Rendern.** Die Skill-Quellen tragen `triggers: [user]`;
+der Validator erzwingt das für jeden schreibenden Skill. Die Semantikabbildung verwarf das Feld
+(`skill_frontmatter.drop_fields`), weil der Client es nicht kennt – **ersatzlos**. In der
+installierten Fassung stand nichts mehr davon, und das Modell konnte `fw-change-small`, einen
+Skill mit `Edit`, `Write` und `Bash`, selbst wählen.
+
+Das Feld existiert beim Client: `disable-model-invocation: true`. Die Fähigkeitsmatrix führte S4
+als `[NICHT ABBILDBAR]` mit genau der Frage, ob es so ein Feld gibt.
+
+**AP2-CC-02 – 18 Regeln ohne Wirkung.** Der Client wertet Pfadregeln nur für `Read` und `Edit`
+aus; eine Pfadregel für `Write`, `NotebookEdit`, `Glob` oder `MultiEdit` wird angenommen, nie
+konsultiert und beim Sitzungsstart als Warnung gemeldet. Die Abbildung erzeugte je Pfad
+zusätzlich eine `Write(...)`-Regel und begründete das als Verschärfung: „Ändern und Anlegen sind
+getrennte Werkzeuge." Für Pfadregeln trifft das nicht zu.
+
+In einer frischen Installation waren das 15 `Write(...)` in `deny`, eine in `ask` und ein
+`Glob(**)` in `allow` – dazu ein `Grep(**)`, das nach derselben Regel nicht ausgewertet wird.
+**Vier** der wirkungslosen Regeln standen in `_core_rules_integrity.deny_must_contain`: Der
+Validator erzwang die Anwesenheit von Regeln, die der Client ignoriert.
+
+**AP2-CC-09 (neu, bei der Behebung gefunden) – die vorgeschriebene Prüfung ist nie gelaufen.**
+`CLIENT_PACK.md` Abschnitt 7 nennt zwei Befehle: `install.py --client claude-code`, dann
+`validate-framework.py`. Führt man sie nacheinander aus, meldet der Validator **zwölf Fehler**
+„triggers fehlt" – er verlangt das Feld unbedingt, während die Abbildung es für diesen Client
+verwirft. Die beiden Befehle widersprachen einander seit 0.5.0.
+
+Dieselbe Prüfung hatte einen zweiten Defekt: `allowed-tools` steht in der installierten Fassung
+als **kommagetrennte Zeichenkette**, nicht als Liste. Die Prüfung `any(t in ("edit","exec",
+"write") for t in tools)` lief damit über die *Zeichen* der Zeichenkette und meldete jeden
+installierten Skill als nicht schreibend. Auch ohne AP2-CC-01 hätte der Validator die Verletzung
+von S4 nicht sehen können.
+
+Dass AP2-CC-01 acht Releases unbemerkt blieb, erklärt sich damit vollständig: Die Prüfung, die
+es hätte finden müssen, war gegen diese Installation nie gelaufen – und hätte es auch nicht
+gefunden.
+
+## 2. Vorgeschlagene Änderung
+
+**`triggers` bekommt eine Abbildung statt ersatzlos zu entfallen.** Das Manifest nennt ein
+`model_invocation_field`; nennt die Quelle `triggers` ohne `model`, setzt die Installation dieses
+Feld auf `true`. Die Aussage der Quelle bleibt damit erhalten, in der Form des Zielclients. Für
+`devin-desktop` ändert sich nichts: Dort steht `triggers` im Frontmatter und wird nicht verworfen.
+
+Verworfen wurde, `triggers` einfach stehen zu lassen: K-18 verlangt, dass das Frontmatter nur
+dokumentierte Felder trägt, und ein unbekanntes Feld ist keine Durchsetzung, sondern Ballast.
+Ebenfalls verworfen: die Zusage S4 für diesen Client als „nicht abbildbar" hinzunehmen und beim
+`ask`-Ersatz zu belassen – der Client kann es, und eine Zusage aufzugeben, die der Zielclient
+erfüllt, wäre die schlechteste aller Auflösungen.
+
+**Pfadregeln nur für Werkzeuge, die der Client dafür auswertet.** `permission_tools.write` bildet
+auf `Edit` ab, `search` auf nichts – `Read(**)` deckt den Lesezugriff ab. Die Berechtigungsdatei
+schrumpft von 83 auf 65 Regeln, `_core_rules_integrity.deny_must_contain` von 17 auf 13.
+
+Verworfen wurde, die `Write(...)`-Regeln als Vorsorge für eine künftige Clientänderung zu
+behalten: Sie erzeugen heute Startwarnungen, die echte Warnungen übertönen, und täuschen einen
+Schutz vor, den sie nicht leisten. Ändert der Client sein Verhalten, ändert sich das Pack – dafür
+gibt es die Fähigkeitsmatrix und die Testfallklasse AK. Eine wirkungslose Regel vorzuhalten ist
+das Gegenteil einer ausgewiesenen Durchsetzungstiefe (D-12).
+
+**Der Validator prüft künftig beides.** Drei Änderungen:
+
+1. Ein Ablageort, der `triggers` abgebildet trägt, wird nicht mehr auf das Feld selbst geprüft,
+   sondern auf das abgebildete: Ein schreibender Skill **muss** die Sperre tragen.
+2. `allowed-tools` wird in beiden Formen gelesen – Liste und kommagetrennte Zeichenkette –, und
+   die Werkzeugnamen des Clients werden über `tool_names` auf die Verben zurückgeführt.
+3. Neue Prüfung: Jede Pfadregel der Berechtigungsdatei muss ein Werkzeug nennen, für das der
+   Client Pfadregeln auswertet (`permission_path_tools` im Manifest). Ohne diese Angabe
+   unterbleibt die Prüfung – für `devin-desktop` ist sie unbelegt und wird deshalb nicht
+   behauptet.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. Die Abbildungsschicht ist keine Regelebene; sie führt keine Regel ein und lockert keine. Geändert werden das Manifest eines Packs und die beiden Skripte, die es auswerten.
+- [x] Verschärfungsprinzip eingehalten? — Ja, in beide Richtungen. S4 gilt nach der Änderung technisch statt gar nicht. Die entfernten Regeln waren wirkungslos: Der Schutz von B4 und B5 trug schon vorher allein die `Edit(...)`-Hälfte, es entfällt keine wirksame Verweigerung.
+- [x] Widerspruchsfreiheit geprüft? — Der Widerspruch zwischen `install.py` und `validate-framework.py` (AP2-CC-09) ist der Anlass und mit Punkt 1 und 2 behoben. Beide Befehle laufen jetzt nacheinander fehlerfrei.
+- [x] Laufzeitfassungen betroffen? — Ja, bei `claude-code`: alle Skills und die Berechtigungsdatei werden neu erzeugt. Die Berechtigungsdatei ist **Saat** und wird von `--update` nicht angefasst; Migrationshinweis im CHANGELOG.
+- [x] Belegstatus korrekt? — Das ist der Kern dieses Antrags. Jede Aussage stützt sich auf die Herstellerdokumentation der Clientversion 2.1.267, im Protokoll mit Zitat.
+- [x] Test- und Validierungsbedarf? — Vier Sonden nach D-23, alle gemeldet (siehe Abschnitt 5). `FW-KO-01` bleibt davon unberührt; die Skill-Testfälle je `TESTS.md` sind ohnehin offen (AP2).
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Kein Projekt setzt `claude-code` produktiv ein; das Übungsrepository nutzt `devin-desktop` und ist nicht betroffen. Ein künftiges Projekt mit diesem Pack bekommt eine kleinere Berechtigungsdatei und Skills mit einem zusätzlichen Frontmatter-Feld.
+- [x] Dokumentation? — CHANGELOG, Decision Log, Roadmap, Client Pack, AP2-Protokoll.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Eine Abbildungsschicht, die eine Zusage beim Rendern verliert, ist schlimmer als keine: Sie erzeugt genau das falsche Vertrauen, gegen das D-12 sie eingeführt hat. Dass der Zielclient ein Feld dafür hat und das Pack es nicht kannte, macht den Befund nicht kleiner, sondern peinlicher. Und dass die vorgeschriebene Prüfung acht Releases lang nie gelaufen ist, erklärt beides. |
+| Ziel-Release | 0.14.0 |
+| Decision-Log-Eintrag | D-26 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] AP2-CC-01: `model_invocation_field` im Manifest; `install.py` übersetzt `triggers` ohne `model` in `disable-model-invocation: true`. **9 von 12 Skills** tragen die Sperre; die drei ohne sind die rein lesenden mit `model`-Trigger
+- [x] AP2-CC-02: `permission_tools.write` → `["Edit"]`, `search` → `[]`; `permission_path_tools` im Manifest. Berechtigungsdatei 83 → 65 Regeln, `deny_must_contain` 17 → 13
+- [x] AP2-CC-09: Validator liest `allowed-tools` in beiden Formen, führt Werkzeugnamen über `tool_names` zurück und prüft bei abgebildetem `triggers` das Zielfeld statt des Quellfelds
+- [x] Neue Prüfung: Pfadregel für ein Werkzeug ohne Pfadauswertung ist ein Fehler
+- [x] **Wirksamkeitsnachweis (D-23), vier Sonden, alle gemeldet:** Sperre entfernt → Fehler; Sperre auf `false` → Fehler; `Write(leitwerk-core/**)` von Hand eingefügt → Fehler; `NotebookEdit(project-overlay/**)` → Fehler. Ausgangs- und Schlusslauf je 0 Fehler
+- [x] `install.py --client claude-code` gefolgt von `validate-framework.py`: **0 Fehler** – erstmals seit 0.5.0
+- [x] Framework-Repository (`devin-desktop`): 0 Fehler, 0 Warnungen; `install.py --check` unverändert
+- [ ] **Folgearbeit:** Die Wirkungsnachweise aus einer Sitzung *in* der Installation stehen weiter aus (AP2-Protokoll, Abschnitt „Offen"). Sie sind der Beleg dafür, dass die Sperre auch greift – dieses Release belegt, dass sie gesetzt wird
+- [x] **Folgearbeit, erledigt mit `CR-2026-017` (Release 0.15.0):** R2 und R3 standen weiter auf `[NICHT ABBILDBAR]`, obwohl `.claude/rules/` mit `paths:`-Frontmatter sie abbildet (AP2-CC-03 des Protokolls). Eigener Antrag, weil er die Technology Packs betrifft
+
+## 6. Berichtigung (`CR-2026-017`, 2026-09-10)
+
+Der dritte Befund war an drei Stellen dieses Antrags als „AP2-CC-03" bezeichnet; im
+Protokoll trägt er die Nummer **AP2-CC-09**, und `AP2-CC-03` ist die Nummer eines anderen
+Befundes. Die drei Stellen sind berichtigt; der Sachverhalt ist unverändert.

package/.koolie/core/governance/change-requests/CR-2026-017-ladebedingungen-claude-code.md

@@ -0,0 +1,173 @@
+# Änderungsantrag `CR-2026-017`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | R2 und R3 abbilden: Der Client kennt Ladebedingungen, das Pack kannte sie nicht |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | `clients/claude-code/manifest.json`; `clients/claude-code/root-template/.claude/rules/README.md` (aus `.claude/framework/README.md`); `clients/claude-code/root-template/.claude/README.md`; `clients/claude-code/CLIENT_PACK.md`; `install.py`; `tests/scripts/validate-framework.py`; `templates/rules/*.template`; `docs/RUNTIME_GLOSSARY.md`; `docs/PLACEHOLDER_REGISTRY.md`; `clients/README.md`; `framework/role-packs/README.md`; `framework/tech-packs/README.md`; `build/doc/05-glossar.md`; `build/doc/07-architektur.md`; `build/doc/07a-abbildungsschicht.md`; `tests/protocols/2026-09-10-AP2-claude-code.md`; `governance/change-requests/CR-2026-016-ap2-claude-code.md` (Berichtigung, Abschnitt 6) |
+| Ebene laut Entscheidungsbaum 6 | Abbildungsschicht (Client Pack) und Prüfwerkzeug |
+| Art | Fehlerbehebung; betrifft die Grundlage der Technology Packs |
+| Dringlichkeit | regulär – kein Projekt setzt das Pack produktiv ein |
+
+## 1. Anlass und Problem
+
+`AP2-CC-03` aus dem Validierungsprotokoll (`tests/protocols/2026-09-10-AP2-claude-code.md`)
+hält fest, dass zwei Einstufungen der Fähigkeitsmatrix überholt sind. Die Berichtigung wurde
+mit `CR-2026-016` ausdrücklich zurückgestellt, weil sie die Technology Packs betrifft und einen
+eigenen Antrag braucht. Das ist dieser Antrag.
+
+**R2 („Regeldateien mit Ladebedingungen") und R3 („Regeln an Dateimuster bindbar – Grundlage
+der Technology Packs") standen auf `[NICHT ABBILDBAR]`**, begründet mit: „Regeltexte werden über
+`@pfad`-Importe eingebunden und sind damit immer geladen." Das ist für Importe richtig und für
+den Client falsch. `docs/en/memory`:
+
+> „Place markdown files in your project's `.claude/rules/` directory. […] All `.md` files are
+> discovered recursively […] Rules can be scoped to specific files using YAML frontmatter with
+> the `paths` field. These conditional rules only apply when Claude is working with files
+> matching the specified patterns. […] Rules without a `paths` field are loaded
+> **unconditionally**."
+
+Damit ist R3 wörtlich abgebildet und R2 mit einer benennbaren Einschränkung: Der Client kennt
+**eine** Ladebedingung – die Bindung an Dateimuster –, die Kernquelle kennt **drei**
+Ladetrigger.
+
+**Drei Folgen, die über die beiden Matrixzeilen hinausgehen:**
+
+1. **Die Importe waren nie nötig.** Eine Regeldatei ohne `paths` lädt von sich aus. Der ganze
+   Mechanismus „Regeldatei plus Eintrag in der Wurzel-Anweisung" – samt der eigens dafür
+   gebauten Validatorprüfung „nicht eingebunden, die Regel wäre wirkungslos" – beruhte auf einer
+   falschen Annahme über den Client.
+
+2. **Eine aktivierte Role-Pack-Regel war bei diesem Client wirkungslos.** `install.py` bindet
+   nur die vier Core-Regeln ein. Ein Projekt, das ein Role Pack aktiviert, legte
+   `30-role-<name>.md` in die Regelablage, wo sie mangels Import nie geladen wurde – der stille
+   Fehlerfall, den das Client Pack selbst beschrieben hat, eingetreten am Framework-eigenen
+   Mechanismus. Dieselbe Datei lief zudem nie durch `render_rule`: Die Formtransformation griff
+   ausschließlich für `framework/runtime/rules/`, nicht für die Regelvorlagen und nicht für die
+   Laufzeitfassungen der Packs.
+
+3. **Ein Technology Pack hatte hier kein Zuhause.** Das Client Pack nannte zwei Ersatzwege –
+   eine verschachtelte `CLAUDE.md` oder einen Import, der immer lädt. Der native Weg existierte
+   die ganze Zeit.
+
+**Ein vierter Befund kam bei der Umsetzung dazu.** Er ist nicht neu entstanden, sondern lag
+bisher unter der Wahrnehmungsschwelle: `claudeMdExcludes` – setzbar auch in
+`.claude/settings.local.json`, mit über alle Ebenen zusammengeführten Listen – nimmt Anweisungs-
+und Regeldateien über ein Glob-Muster vom Laden aus. Das ist eine **Lockerung** durch
+nutzerlokale Konfiguration und damit eine Lücke in B9. Vor dieser Änderung war sie größer, nicht
+kleiner: Ein Muster auf die Wurzel-Anweisungsdatei hätte sämtliche importierten Regeltexte auf
+einmal entfernt. Neu ist allein, dass wir sie kennen.
+
+## 2. Vorgeschlagene Änderung
+
+**Die Regelablage von `claude-code` liegt in `.claude/rules/`; der Client lädt sie selbst.**
+`pack_runtime_dir` und `<RULES_DIR>` zeigen dorthin, `root_instruction_imports` ist leer, die
+Marke `RUNTIME_IMPORTS` fällt in der erzeugten `CLAUDE.md` ersatzlos weg.
+
+**Die Ladetrigger werden abgebildet, statt zu Kommentar zu werden.** Das Manifest führt
+`rule_triggers` mit der Bedingungssprache des Clients und der Abbildung je Ladetrigger:
+
+| Ladetrigger der Kernquelle | Fassung bei `claude-code` | Bewertung |
+|---|---|---|
+| `always_on` | kein `paths`-Feld | wörtliche Entsprechung |
+| `model_decision` | kein `paths`-Feld | Verschärfung – mehr Regeln aktiv, nicht weniger |
+| `glob` mit `globs` | `paths:` mit denselben Mustern | wörtliche Entsprechung |
+| `manual`, `agent` | keine Abbildung | Die Installation scheitert |
+
+`description` entfällt im Frontmatter, weil der Client es für Regeldateien nicht dokumentiert
+(K-18); Zweck, Ladeverhalten und der Ladetrigger der Kernquelle stehen in einem HTML-Kommentar
+oberhalb des Regeltextes. Der Regeltext selbst ist unverändert – wie bisher unterscheidet sich
+zwischen den Packs nur die Form.
+
+**Die Abbildung greift für alle drei Herkünfte einer Regeldatei**, nicht mehr nur für die
+Core-Regeltexte: auch für die beiden Regelvorlagen unter `templates/rules/` und für die
+Laufzeitfassungen aktivierter Role- und Technology Packs. Eine Pack-Regel, deren Ladebedingung
+beim Rendern verfällt, wäre derselbe Befund, nur eine Ebene tiefer.
+
+**Der Validator prüft die installierte Fassung an ihrer eigenen Form.** Drei Prüfungen für einen
+Client mit eigener Bedingungssprache:
+
+1. Ein Frontmatter-Feld, das der Client für Regeldateien nicht auswertet, ist ein Fehler (K-18).
+   Ein stehen gebliebenes `trigger:` oder `globs:` heißt: Die Datei ist nicht durch die
+   Abbildung gelaufen, ihre Ladebedingung ist verfallen.
+2. Die Ladebedingung muss die Form haben, die der Client erwartet – bei `paths` eine nichtleere
+   Liste von Mustern.
+3. **Eine Kernregel (`00-`, `10-`, `15-`, `20-`) darf keine Ladebedingung tragen.** Sie gilt für
+   jede Aufgabe; sie an Dateimuster zu binden wäre eine Lockerung. Diese Prüfung ist der Preis
+   dafür, dass die Bindung an Dateimuster jetzt überhaupt möglich ist.
+
+**Die Installation scheitert vollständig, nicht zur Hälfte.** `install.py` rendert alle
+abzubildenden Quellen einmal, bevor es die erste Datei schreibt. Vorher brach eine nicht
+abbildbare Quelle die Installation mitten im Schreiben ab und hinterließ ein halb angelegtes
+Projekt. Das betrifft auch die Semantikabbildung der Berechtigungen aus D-18.
+
+**Was verworfen wurde:**
+
+- **Nur die Matrix berichtigen, die Mechanik lassen.** Genau die Lage, gegen die D-12 und D-26
+  gerichtet sind: eine ausgewiesene Durchsetzungstiefe, hinter der die Abbildung zurückbleibt.
+- **Nur Technology Packs nach `.claude/rules/`, die Core-Regeln über Importe lassen.** Ergäbe
+  zwei Regelablagen mit zwei Lademechanismen bei einem Client und ließe den stillen Fehlerfall
+  für die Role Packs bestehen.
+- **`model_decision` an eine `paths`-Liste hängen, die alles trifft (`**/*`).** Eine Bedingung,
+  die immer wahr ist, ist keine Bedingung – sie wäre nur schwerer zu lesen und würde zusätzlich
+  vom Ladeverhalten abhängen (pfadgebundene Regeln laden beim Lesen einer Datei, nicht beim
+  Sitzungsstart). Das wäre keine Verschärfung, sondern eine Lockerung.
+- **`manual` und `agent` vorsorglich auf unbedingtes Laden abbilden.** Beide Ladetrigger sind im
+  Kern von keinem Artefakt benutzt. Eine Abbildung zu erfinden, die nie geprüft wird, ist
+  dasselbe Muster wie die wirkungslosen `Write(...)`-Regeln aus `CR-2026-016`. Ohne Eintrag
+  scheitert die Installation und erzwingt die Entscheidung zu dem Zeitpunkt, an dem sie
+  ansteht.
+- **Die Importmechanik entfernen, weil sie kein Pack mehr nutzt.** Sie ist manifestgesteuert und
+  bleibt für ein künftiges Pack erhalten; dass sie von keinem ausgelieferten Pack mehr erprobt
+  ist, steht in der Roadmap unter „Bewusst offen gelassen". Ein Vorhalten mit ausgewiesenem
+  Belegstand ist etwas anderes als ein Vorhalten mit behaupteter Wirkung.
+
+**Mitgezogen, weil sonst falsch stehen bleibend:** Die Zeile S4 der Fähigkeitsmatrix stand noch
+auf `[NICHT ABBILDBAR] – überholt`, obwohl `CR-2026-016` die Abbildung bereits ausgeliefert hat;
+ebenso beschrieben die Abschnitte 1a, 4, 5 und 7 des Client Packs und die Laufzeit-README noch
+die zwei Regeln je Pfad, die es seit 0.14.0 nicht mehr gibt. Diese Angaben sind nachgezogen. Sie
+sind keine eigene Änderung, sondern die Berichtigung von Aussagen über bereits Geändertes.
+
+## 3. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. Die Abbildungsschicht ist keine Regelebene. Geändert werden das Manifest eines Packs, seine beiden Laufzeit-READMEs und die zwei Skripte, die das Manifest auswerten. Die Regeltexte selbst sind unverändert.
+- [x] Verschärfungsprinzip eingehalten? — Ja, und an einer Stelle ausdrücklich geprüft. `model_decision` bildet auf unbedingtes Laden ab: mehr Regeln aktiv, nicht weniger. Die einzige Stelle, an der die neue Fähigkeit eine Lockerung ermöglichen würde – eine Kernregel an Dateimuster zu binden –, ist als Validatorfehler ausgeschlossen und mit Sonde S2 belegt.
+- [x] Widerspruchsfreiheit geprüft? — Der Widerspruch zwischen der Fähigkeitsmatrix (`[NICHT ABBILDBAR]`) und dem Client ist der Anlass. Nach der Änderung trägt keine Zeile mehr diese Einstufung, und alle Aussagen über den Lademechanismus in Pack, READMEs, Glossar und Platzhalterregister nennen dieselbe Mechanik.
+- [x] Laufzeitfassungen betroffen? — Ja, bei `claude-code`: Die Regelablage wird umbenannt, alle Regeltexte werden neu erzeugt, `CLAUDE.md` verliert den Importblock. Migrationshinweis im CHANGELOG. `devin-desktop` ist unberührt – ohne `rule_triggers` ist die Abbildung die Identität, und `install.py --check` gegen das Framework-Repository meldet keine Abweichung.
+- [x] Belegstatus korrekt? — Jede Aussage über den Client stützt sich auf `docs/en/memory` der Clientversion 2.1.267, im Protokoll mit Zitat. Belegt ist `[DOK]`, nicht beobachtete Durchsetzung: Dass eine Regel ohne `paths` geladen **wird**, ist dokumentiert; dass sie in einer laufenden Sitzung tatsächlich im Kontext steht, ist ein Wirkungsnachweis und steht aus.
+- [x] Test- und Validierungsbedarf? — Sechs Sonden nach D-23, alle gemeldet, dazu vier Gegenproben (Abschnitt 5). `FW-KO-01`, `FW-KO-02` und `FW-VN-01` sind unberührt; die Skill-Testfälle je `TESTS.md` bleiben offen (AP2).
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Kein Projekt setzt `claude-code` produktiv ein; das Übungsrepository nutzt `devin-desktop`. Ein künftiges Projekt mit diesem Pack bekommt seine Regeln in `.claude/rules/` und kann Technology Packs erstmals an Dateimuster binden.
+- [x] Dokumentation? — CHANGELOG, Decision Log, Roadmap, Client Pack, beide Laufzeit-READMEs, Glossar, Platzhalterregister, AP2-Protokoll.
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Dasselbe Muster wie bei `CR-2026-016`, eine Ebene weiter: Das Pack hat den Client unterschätzt und einen Ersatz gebaut, wo eine native Kontrolle existiert. Der Unterschied ist, dass hier keine Schutzzusage verfiel, sondern eine Grundlage fehlte – Technology Packs galten bei diesem Client als nicht abbildbar, und eine aktivierte Role-Pack-Regel wurde stillschweigend nie geladen. Eine Fähigkeitsmatrix, die weniger behauptet, als der Client kann, ist weniger gefährlich als eine, die mehr behauptet, aber sie kostet genau die Mechanismen, für die es das Framework gibt. |
+| Ziel-Release | 0.15.0 |
+| Decision-Log-Eintrag | D-27 |
+
+## 5. Umsetzung (nach Annahme)
+
+- [x] `rule_triggers` im Manifest; `pack_runtime_dir` und `<RULES_DIR>` auf `.claude/rules`; `root_instruction_imports` leer; `has_rule_triggers` auf `true`
+- [x] `render_rule` bildet die Ladetrigger ab; `ist_regelquelle` erfasst zusätzlich `templates/rules/` und die Pack-Laufzeitfassungen
+- [x] `install.py` rendert alle Quellen vor der ersten Schreiboperation und bricht sauber ab (`pruefe_abbildung`)
+- [x] Validator: Feldprüfung nach K-18, Formprüfung der Ladebedingung, Verbot einer Ladebedingung an Kernregeln
+- [x] Client Pack auf 0.6.0: R2, R3 und S4 auf `[TECHNISCH]`; `[NICHT ABBILDBAR]` 4 → **0**; Abschnitt 1b neu; die Restangaben zu AP2-CC-02 in 1a, 4, 5 und 7 nachgezogen
+- [x] Beide Laufzeit-READMEs des Packs neu geschrieben; Glossar, Platzhalterregister und `clients/README.md` nachgezogen
+- [x] Regelvorlagen von der Akteursbezeichnung „Devin" und von client-gebundenen Feldnamen gelöst
+- [x] **Wirksamkeitsnachweis (D-23), sechs Sonden, alle gemeldet:** `trigger:` im Frontmatter stehen gelassen; `paths` an einer Kernregel; `paths` als Zeichenkette; `paths` als leere Liste; Ladetrigger `manual` ohne Abbildung (Installation scheitert); `trigger: glob` ohne `globs` (Installation scheitert). Vier Gegenproben: korrektes Technology Pack, Regeldatei ohne Frontmatter, und die beiden Prüfungen aus `CR-2026-016` melden weiterhin
+- [x] `install.py --client claude-code` gefolgt von `validate-framework.py`: 0 Fehler
+- [x] Framework-Repository (`devin-desktop`): Validator 0 Fehler, 0 Warnungen; `install.py --check` unverändert; `build/assemble.py` baut
+- [ ] **Folgearbeit:** Die Wirkungsnachweise aus einer Sitzung *in* der Installation stehen weiter aus. Dazu gehört seit diesem Release ein zweiter: dass eine Regel ohne `paths` tatsächlich im Kontext steht und eine Regel mit `paths` erst beim Lesen einer passenden Datei
+- [ ] **Folgearbeit:** Die Lücke in B9 durch `claudeMdExcludes` ist beschrieben, nicht geschlossen. Ob sie sich schließen lässt – etwa über verwaltete Einstellungen –, ist eine Frage an AP2 für die Enterprise-Marker
+- [ ] **Folgearbeit:** Die Importmechanik der Wurzel-Anweisung ist von keinem ausgelieferten Pack mehr erprobt
+
+## 6. Berichtigung an `CR-2026-016`
+
+Der dritte Befund jenes Antrags ist dort als „AP2-CC-03" bezeichnet; im Protokoll trägt er die
+Nummer **AP2-CC-09**. `AP2-CC-03` ist die Nummer des Befundes, um den es hier geht. Die
+Bezeichnung im Antrag ist entsprechend berichtigt; der Sachverhalt bleibt unverändert.

package/.koolie/core/governance/change-requests/CR-2026-018-quellenliste-claude-code.md

@@ -0,0 +1,121 @@
+# Änderungsantrag `CR-2026-018`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Quellenliste belegte die `[DOK]`-Aussagen nur eines Clients |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | `build/doc/31-anhaenge.md`; `clients/claude-code/CLIENT_PACK.md`; `clients/README.md`; `tests/protocols/2026-09-10-AP2-claude-code.md` |
+| Ebene laut Entscheidungsbaum 6 | Dokumentation und Abbildungsschicht; keine Regelebene |
+| Art | Fehlerbehebung (Belegkette), Vorarbeit zu `FW-AK-01` |
+| Dringlichkeit | regulär |
+
+## 1. Anlass und Problem
+
+Anhang 31.4 des Hauptdokuments sagt über sich selbst: „Die Quellen belegen die als `[DOK]`
+gekennzeichneten Aussagen; der Framework Owner hält diese Liste im Rahmen der Produktbeobachtung
+aktuell (`FW-AK-01`)." Die Liste führte **17 Quellen, sämtlich von `docs.devin.ai`.**
+
+Seit Release 0.14.0 trägt das Client Pack `claude-code` ein Dutzend `[DOK]`-Aussagen, die gegen
+`code.claude.com/docs/en/*` erhoben wurden. **Keine dieser Quellen stand in der Liste.** Für
+einen der beiden Clients löste der Anhang seine eigene Zusage nicht ein – und `FW-AK-01`, dessen
+Prüfgegenstand genau diese Liste ist, hätte den fehlenden Teil nicht prüfen können, weil er nicht
+da war.
+
+Zwei kleinere Befunde kamen beim Abgleich dazu:
+
+**Die Belegspalte der Fähigkeitsmatrix nannte keine Fundstelle.** Zwölf Zeilen trugen `[DOK]
+(AP2, Clientversion 2.1.267, tests/protocols/…)`. Das nennt den **Vorgang**, nicht die **Quelle**.
+Wer eine einzelne Einstufung nachprüfen wollte, musste erst das Protokoll lesen, um zu erfahren,
+auf welcher der fünf Seiten die Aussage steht. D-25 hatte für Versionsangaben denselben
+Unterschied herausgearbeitet: Eine Angabe, die man nicht gegen etwas halten kann, ist keine.
+
+**Die Kennungen `Q1` bis `Q17` waren doppelt belegt.** Dieselben Kürzel bezeichnen im Framework
+an rund zwanzig Stellen – in Checklisten, Entscheidungsbäumen und im Änderungsverzeichnis – die
+**Qualitätsregeln**: `Q8` ist dort die Größenschwelle einer Änderung, im Anhang dagegen
+`docs.devin.ai/desktop/cascade/workflows`.
+
+## 2. Vorgeschlagene Änderung
+
+**Anhang 31.4 wird je Client Pack geführt.** Das ist keine Gliederungsfrage: Eine Aussage über
+einen Client hängt an dessen Dokumentation und an keiner anderen, und die beiden Listen haben
+verschiedene Recherchestände – `devin-desktop` 01.–02.09.2026 gegen Produktversion 3.8.20,
+`claude-code` 10.09.2026 gegen Clientversion 2.1.267.
+
+**Fünf Quellen kommen dazu** (`QC-1` bis `QC-5`): `docs/en/memory`, `permissions`, `skills`,
+`sub-agents` und `settings`. Je Quelle steht, was sie belegt.
+
+**Die Kennungen tragen das Präfix des Packs** – `QD-` und `QC-`. Zwei Bedeutungen desselben
+Kürzels in einem Dokument sind eine Verwechslung ohne Nutzen. Die Quellenkennungen werden
+außerhalb des Anhangs nirgends referenziert; die Umbenennung bricht keinen Verweis.
+
+**Die Belegspalte der Fähigkeitsmatrix nennt die Seite**, etwa ``[DOK] `docs/en/memory` (AP2,
+Clientversion 2.1.267, …)``. Damit ist jede Zeile einzeln nachprüfbar, ohne den Umweg über das
+Protokoll. Die Seitennamen stehen im Pack, die vollständige Belegzuordnung im Anhang – das Pack
+bleibt für sich lesbar, ohne die Zuordnungstabelle zu verdoppeln.
+
+**Ein neuer Abschnitt 31.4.3 sagt, was die Liste über sich selbst weiß:** dass die beiden
+Recherchestände neun Tage auseinanderliegen, dass nur der jüngere gegen eine benannte
+Clientversion erhoben ist, und dass `FW-AK-01` deshalb `offen` bleibt.
+
+**Was verworfen wurde:**
+
+- **Die Quellenliste ganz in die Client Packs verlegen.** Naheliegend nach dem Muster von 31.5
+  („der maßgebliche Verifikationsbedarf steht in der Fähigkeitsmatrix"), aber die Liste ist mehr
+  als eine Zuordnung: Sie trägt Abrufdatum und Produktstand und ist damit das Artefakt, gegen das
+  `FW-AK-01` prüft. Ein Testfall braucht **einen** Prüfgegenstand, nicht je Pack einen.
+- **Die Seitennamen nur im Anhang führen und im Pack bei „AP2" belassen.** Ein Pack wird in ein
+  Projekt installiert, das Hauptdokument nicht. Eine Belegangabe, die erst in einem anderen
+  Dokument auflösbar ist, hilft dort niemandem.
+- **Die Quellenkennungen `QC-1` bis `QC-5` auch im Pack verwenden.** Dann müsste die Zuordnung
+  Kennung → Seite in beiden Dokumenten stehen – genau die Doppelpflege, die D-16, D-17 und D-20
+  beseitigt haben. Der Seitenname ist ohne Nachschlagen lesbar und dafür die bessere Angabe.
+
+## 3. Nebenbefunde aus dem Abgleich
+
+Der Abgleich hat drei Einstufungen genauer belegt und eine offene Frage aufgeworfen. Alle vier
+sind Nachträge zu bestehenden Zeilen, keine neuen Zusagen.
+
+| Zeile | Was dazukommt | Quelle |
+|---|---|---|
+| H2 | Ein mit Exit-Code 2 blockierender Hook greift **bevor** die Berechtigungsregeln ausgewertet werden – er geht damit auch einer `allow`-Regel vor. Umgekehrt hebt eine Hook-Entscheidung keine `deny`- oder `ask`-Regel auf | `QC-2` |
+| A1 | `disallowedTools` wird **zuerst** angewandt, dann `tools` gegen den Rest aufgelöst. Ein Profil, dessen `tools`-Liste sich zu keinem Werkzeug auflöst, wird gar nicht erst gestartet – ein Tippfehler führt zum Abbruch, nicht zu einem Subagenten ohne Beschränkung | `QC-4` |
+| S4 | `disable-model-invocation: true` hält zusätzlich die Beschreibung des Skills aus dem Kontext – ein Gewinn für Least Context, nicht nur für die Zusage | `QC-3` |
+| M2 | **AP2-CC-12 (offen):** Ein Subagentenprofil kennt ein eigenes Feld `permissionMode`, das den Wert `bypassPermissions` annimmt. Ob `disableBypassPermissionsMode` auch dort greift, sagt keine der fünf Seiten. M2 gilt damit für die Hauptsitzung als belegt und für den Weg über ein Subagentenprofil als ungeklärt | keine – Belegfrage |
+
+Die Einstufung von M2 bleibt `[TECHNISCH]`: Die Sperre ist dokumentiert und wirkt aus jeder
+Einstellungsebene. Offen ist eine **Teilfrage**, und sie steht als solche in der Zeile. Das
+Framework liefert genau ein Subagentenprofil aus (`fw-reviewer`), und es setzt das Feld nicht.
+
+## 4. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. Geändert werden ein Kapitel des Hauptdokuments und die Belegspalte eines Client Packs. Keine Regel wird eingeführt, keine gelockert; keine Einstufung ändert sich.
+- [x] Verschärfungsprinzip eingehalten? — Nicht berührt. Die Änderung fügt Belege hinzu und nimmt keinen weg.
+- [x] Widerspruchsfreiheit geprüft? — Der Widerspruch war der Anlass: Der Anhang behauptete, die `[DOK]`-Aussagen zu belegen, und tat es für einen Client nicht. Zusätzlich beseitigt: die Doppelbelegung der Kennungen `Q1` bis `Q17`.
+- [x] Laufzeitfassungen betroffen? — Nein. Weder Installation noch Validator ändern sich; `install.py --check` und der Validator laufen unverändert.
+- [x] Belegstatus korrekt? — Das ist der Gegenstand. Jede neue Zeile nennt Seite und Abrufdatum; die Nebenbefunde sind mit der Seite belegt, aus der sie stammen. AP2-CC-12 ist ausdrücklich als **ungeklärt** geführt und nicht als Befund.
+- [x] Test- und Validierungsbedarf? — Keine Sonde: Die Änderung fügt keine Prüfung hinzu und ändert keine. `FW-AK-01` bleibt `offen`; für `claude-code` ist der Abgleich mit diesem Release geführt, für `devin-desktop` steht er aus.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Keine.
+- [x] Dokumentation? — CHANGELOG, Roadmap, Client Pack, AP2-Protokoll, `clients/README.md`.
+
+## 5. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | angenommen |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Die Belegkette ist der Kern dessen, was das Framework über sich behauptet: `[DOK]` heißt „in der Herstellerdokumentation beschrieben", und wenn nicht auffindbar ist, **wo**, ist das eine Behauptung mit Fußnote. Dass die Liste über zwei Releases hinweg nur einen der beiden Clients kannte, ist derselbe Befundtyp wie `AP2-CC-09`: eine Zusage, die niemand gegen ihren eigenen Gegenstand gehalten hat. |
+| Ziel-Release | 0.16.0 |
+| Decision-Log-Eintrag | keiner – die Änderung führt keine neue Festlegung ein, sondern löst eine bestehende ein (D-12, D-14, D-25) |
+
+## 6. Umsetzung (nach Annahme)
+
+- [x] Anhang 31.4 je Client Pack gegliedert; `QC-1` bis `QC-5` aufgenommen; Kennungen auf `QD-`/`QC-` umgestellt
+- [x] Abschnitt 31.4.3: was die Liste über ihre eigenen Recherchestände weiß
+- [x] Belegstand in 31.5 nachgezogen (die Angabe „9 von 26 bei `claude-code`" war seit AP2 überholt)
+- [x] Belegspalte der Fähigkeitsmatrix nennt je Zeile die Seite; Hinweis dazu am Kopf von Abschnitt 2
+- [x] Nebenbefunde zu H2, A1 und S4 in die Matrix übernommen; AP2-CC-12 in Pack und Protokoll aufgenommen
+- [x] Quellenzeile des AP2-Protokolls berichtigt: die Seite heißt `sub-agents`, nicht `subagents`
+- [x] Validator 0 Fehler, 0 Warnungen; `install.py --check` unverändert; Hauptdokument baut für beide Packs
+- [ ] **Folgearbeit:** `FW-AK-01` bleibt `offen`. Die Hälfte `devin-desktop` verlangt einen Abgleich der Quellen `QD-1` bis `QD-17` und des Produkt-Changelogs; der Recherchestand ist der 02.09.2026
+- [ ] **Folgearbeit:** AP2-CC-12 klären. Ohne Sitzung nur über die Dokumentation zu Subagenten und verwalteten Einstellungen zu beantworten