@renoxar/koolie 1.25.0 → 2.0.0

package/.koolie/core/framework/core/05-working-model.md

@@ -6,7 +6,7 @@
 | Ebene | 1 – Framework Core |
 | Verbindlichkeit | normativ (Abschnitte 1–3), Erläuterung (Abschnitt 4) |
 | Owner | `<FRAMEWORK_OWNER>` |
-| Version | 0.1.13 |
+| Version | 0.1.14 |
 | Status | `pilot` |
 
 ## 1. Standardarbeitsablauf (normativ)
@@ -19,22 +19,22 @@ Jede KI-Aufgabe folgt den vierzehn Schritten. Schritte DÜRFEN NICHT übersprung
 | 2 | Scope und Grenzen bestimmen | Mensch | Erlaubte Pfade, ausgeschlossene Pfade, Betriebsmodus, Kontrollstufe (`09-risk-model.md`) | `.koolie/core/decision-trees/02-may-ai-do-task.md`, `03-analyze-or-modify.md` |
 | 3 | Datenschutz und Kontextfreigabe prüfen | Mensch | Kontextklassen aller vorgesehenen Quellen prüfen (`02-privacy.md`); K3-Inhalte ausschließen | `.koolie/core/checklists/02-privacy-context.md`, `.koolie/core/decision-trees/01-context-allowed.md` |
 | 4 | Rückfragen und offene Punkte erfassen | KI-Client | Liste der Unklarheiten mit Auswirkung; keine Bearbeitung ungeklärter Punkte (P3) | – |
-| 5 | Relevanten Ist-Zustand analysieren | KI-Client | Nur die für die Aufgabe relevanten Dateien lesen; keine Änderungen (P4) | Skill `fw-repo-analyze` |
+| 5 | Relevanten Ist-Zustand analysieren | KI-Client | Nur die für die Aufgabe relevanten Dateien lesen; keine Änderungen (P4) | Skill `koolie-repo-analyze` |
 | 6 | Befunde mit Fundstellen darstellen | KI-Client | Jede Aussage mit `pfad/datei:zeile` oder Suchmuster belegen | – |
-| 7 | Lösungsoptionen bewerten | KI-Client, Entscheidung Mensch | Mindestens zwei Optionen bei Stufe mittel/hoch; Kriterien: Risiko, Aufwand, Reversibilität, Konsistenz mit Architektur | Skill `fw-change-analyze` |
-| 8 | Vorgehen oder Änderungsplan vorschlagen | KI-Client | Schrittfolge, betroffene Dateien, Tests, Abbruchkriterien | Skill `fw-plan` |
+| 7 | Lösungsoptionen bewerten | KI-Client, Entscheidung Mensch | Mindestens zwei Optionen bei Stufe mittel/hoch; Kriterien: Risiko, Aufwand, Reversibilität, Konsistenz mit Architektur | Skill `koolie-change-analyze` |
+| 8 | Vorgehen oder Änderungsplan vorschlagen | KI-Client | Schrittfolge, betroffene Dateien, Tests, Abbruchkriterien | Skill `koolie-plan` |
 | 9 | Freigabepunkt vor Änderungen am Produktivcode (Schritt 10, M3) | Mensch | Bestätigung des Plans (Stufe mittel) oder dokumentierte Freigabe `<APPROVAL_ROLE>` (Stufe hoch) | `09-risk-model.md` |
-| 10 | Änderung in kleinen, nachvollziehbaren Schritten umsetzen | KI-Client unter Beobachtung | Ein logischer Schritt je Änderung; nach jedem Schritt Zwischenstand berichten (P7) | Skill `fw-change-small`, `.koolie/core/checklists/03-before-code-change.md` |
+| 10 | Änderung in kleinen, nachvollziehbaren Schritten umsetzen | KI-Client unter Beobachtung | Ein logischer Schritt je Änderung; nach jedem Schritt Zwischenstand berichten (P7) | Skill `koolie-change-small`, `.koolie/core/checklists/03-before-code-change.md` |
 | 11 | Tests und Qualitätsprüfungen ausführen | KI-Client, Bewertung Mensch | Nur im Overlay freigegebene Befehle (`<BUILD_COMMAND>`, `<TEST_COMMAND>`, `<LINT_COMMAND>`); Ergebnisse unverändert berichten | `.koolie/core/checklists/05-testing.md` |
 | 12 | Ergebnis, Abweichungen und Restrisiken dokumentieren | KI-Client | Ergebnisbericht nach Standardformat (Abschnitt 3.6) | – |
-| 13 | Menschliche Prüfung ermöglichen | KI-Client, dann Mensch | Diff, Fundstellen, Testprotokoll, offene Punkte bereitstellen; Review anhand `.koolie/core/checklists/04-review-ai-code.md` | Skill `fw-review-support` |
-| 14 | Übernahme über den bestehenden Review- und Freigabeprozess | Mensch | Merge Request mit KI-Nutzungsvermerk; reguläre Quality Gates und Review (P5, P6) | `.koolie/core/checklists/08-merge-request.md`, Skill `fw-mr-description` |
+| 13 | Menschliche Prüfung ermöglichen | KI-Client, dann Mensch | Diff, Fundstellen, Testprotokoll, offene Punkte bereitstellen; Review anhand `.koolie/core/checklists/04-review-ai-code.md` | Skill `koolie-review-support` |
+| 14 | Übernahme über den bestehenden Review- und Freigabeprozess | Mensch | Merge Request mit KI-Nutzungsvermerk; reguläre Quality Gates und Review (P5, P6) | `.koolie/core/checklists/08-merge-request.md`, Skill `koolie-mr-description` |
 
-**Die Spalte „Referenz“ nennt bei sechs Schritten einen Skill (5, 7, 8, 10, 13, 14). Wo sie einen nennt, ist er der vorgesehene Weg des Schrittes** – keine Leseempfehlung. Ein anderer Weg ist zulässig, MUSS aber im Ergebnisbericht benannt und begründet werden (Abschnitt 3.6). **Ein abgewiesener Skill-Aufruf ist keine Verwendung:** Wer die `SKILL.md` ersatzweise liest und ihren Ablauf von Hand nacharbeitet, arbeitet ohne die Werkzeugbeschränkung des Skills. Gemessen am 2026-09-14 `[MESS]` (`.koolie/core/tests/protocols/2026-09-14-erhebung-skillaufruf.md`, D-83): In zwei von zwei nachgearbeiteten Läufen wies die Sitzung den Skill im Bericht als verwendet oder aufgerufen aus, und in einem davon verwendete sie ein Werkzeug, das der Skill sperrt.
+Die Spalte „Referenz“ nennt bei sechs Schritten einen Skill (5, 7, 8, 10, 13, 14). Wo sie einen nennt, ist er der vorgesehene Weg des Schrittes – keine Leseempfehlung. Ein anderer Weg ist zulässig, MUSS aber im Ergebnisbericht benannt und begründet werden (Abschnitt 3.6). Ein abgewiesener Skill-Aufruf ist keine Verwendung: Wer die `SKILL.md` ersatzweise liest und ihren Ablauf von Hand nacharbeitet, arbeitet ohne die Werkzeugbeschränkung des Skills. Gemessen am 2026-09-14 `[MESS]` (`.koolie/core/tests/protocols/2026-09-14-erhebung-skillaufruf.md`): In zwei von zwei nachgearbeiteten Läufen wies die Sitzung den Skill im Bericht als verwendet oder aufgerufen aus, und in einem davon verwendete sie ein Werkzeug, das der Skill sperrt.
 
 ## 2. Betriebsmodi (normativ)
 
-Jede Aufgabe wird genau einem Betriebsmodus zugeordnet. Den Modus gibt der Mensch vor; ohne Angabe gilt M1 (D-390). Ein Moduswechsel innerhalb einer Sitzung ist zulässig, MUSS aber ausdrücklich durch den Menschen angewiesen werden und wird vom KI-Client im Ergebnisbericht vermerkt.
+Jede Aufgabe wird genau einem Betriebsmodus zugeordnet. Den Modus gibt der Mensch vor; ohne Angabe gilt M1. Ein Moduswechsel innerhalb einer Sitzung ist zulässig, MUSS aber ausdrücklich durch den Menschen angewiesen werden und wird vom KI-Client im Ergebnisbericht vermerkt.
 
 ### 2.1 Übersicht
 
@@ -60,7 +60,7 @@ Jede Aufgabe wird genau einem Betriebsmodus zugeordnet. Den Modus gibt der Mensc
 | Prüfpflichten | Mensch prüft Befunde stichprobenartig an den angegebenen Fundstellen; unbelegte Aussagen gelten als unbestätigt |
 | Abbruchkriterien | Zugriff auf K3-Inhalte erforderlich; Fundstellen nicht auffindbar; Frage erfordert Informationen außerhalb des Repositorys, die nicht freigegeben sind |
 | Erwartete Ausgabe | Strukturierter Analysebericht: Fragestellung, untersuchte Bereiche, Befunde mit Fundstellen, offene Punkte, ausdrückliche Kennzeichnung von Vermutungen |
-| Umsetzung im Werkzeug | **Die Modusgrenze gilt normativ; technisch durchsetzen lässt sie sich seit `1.20.2` mit einer Modusbindung** (`mandat.py modus M1`, D-501): Dann sperrt der Schutz-Hook jedes Schreibwerkzeug `[MESS]`; ein Shell-Befehl, der schreibt, entgeht ihr (D-30). Kennt der KI-Client einen eigenen Nur-Lese-Modus oder ein rein lesendes Agentenprofil, ist dieser Weg vorzuziehen – welcher das ist, steht in der Fähigkeitsmatrix seines Client Packs (Zeilen S3 und A1) `[DOK]` je Pack. Die Skill-`permissions` tragen die Modusgrenze teilweise, ersetzen sie aber nicht `[MESS]`: Bei `claude-code` ist die Quelle `permissions.deny` auf `disallowed-tools` abgebildet, und das entfernt die Schreibwerkzeuge wirklich – gemessen am 2026-09-13 (`tests/protocols/2026-09-13-erhebung-disallowed-tools.md`, D-64). **Die Sperre gilt aber nur für den aufrufenden Turn;** mit der nächsten Nachricht der Person ist das Werkzeug zurück – gemessen. Ein „nur lesender" Skill ist damit nur während seines Turns nur lesend und trägt M1 nicht als Betriebsmodus einer Sitzung. Wer M1 über einen Turn hinaus braucht, braucht die globale Berechtigungsschicht oder einen Nur-Lese-Modus des Clients. Innerhalb des Turns gilt die Entfernung auch für einen Unteragenten, den der Skill startet – gemessen am 2026-09-13 (`tests/protocols/2026-09-13-erhebung-unteragent.md`, D-67) `[MESS]`, mit Kontrolllauf –, sie reicht dort aber genauso weit wie oben: Mit gesperrtem `Write, Edit` schrieb der Unteragent über `Bash`. Das rein lesende Agentenprofil ist der belastbarere Weg zu M1, gemessen am 2026-09-13 (D-68) `[MESS]`: Ein Profil mit `tools: Read, Grep, Glob` hatte kein Schreibwerkzeug im Vorrat; es hängt nicht am Turn, sondern am Profil. Es kann sich nicht selbst erweitern (D-73) `[MESS]`: Ihm fehlt das Werkzeug, um eine zweite, weniger beschränkte Ebene zu starten. Bei Widerspruch gewinnt die restriktivere Liste (D-72) `[MESS]` – ein Profil, das ein Werkzeug ausdrücklich erlaubt, bekommt es unter einem Skill, der es sperrt, nicht; die Liste lässt sich nur enger machen, nie weiter. `allowed-tools` trägt die Grenze nicht: Es ist eine Vorabfreigabe und keine Beschränkung – gemessen am 2026-09-12 (`tests/protocols/2026-09-12-B01-allowed-tools.md`, B01) `[MESS]`. Jedes Pack benennt, was an die Stelle eines verworfenen Feldes tritt, sonst bricht die Installation ab (`CR-2026-050`, D-50); der Ersatz steht in Zeile S3 der Fähigkeitsmatrix. Unabhängig vom Modus wirken die Sperren auf Secret- und Kernpfade `[DOK]` |
+| Umsetzung im Werkzeug | Die Modusgrenze gilt normativ; technisch durchsetzen lässt sie sich mit einer Modusbindung (`mandat.py modus M1`): Dann sperrt der Schutz-Hook jedes Schreibwerkzeug `[MESS]`; ein Shell-Befehl, der schreibt, entgeht ihr. Kennt der KI-Client einen eigenen Nur-Lese-Modus oder ein rein lesendes Agentenprofil, ist dieser Weg vorzuziehen – welcher das ist, steht in der Fähigkeitsmatrix seines Client Packs (Zeilen S3 und A1) `[DOK]` je Pack. Die Skill-`permissions` tragen die Modusgrenze teilweise, ersetzen sie aber nicht `[MESS]`: Bei `claude-code` ist die Quelle `permissions.deny` auf `disallowed-tools` abgebildet, und das entfernt die Schreibwerkzeuge wirklich – gemessen am 2026-09-13 (`tests/protocols/2026-09-13-erhebung-disallowed-tools.md`). **Die Sperre gilt aber nur für den aufrufenden Turn;** mit der nächsten Nachricht der Person ist das Werkzeug zurück – gemessen. Ein „nur lesender" Skill ist damit nur während seines Turns nur lesend und trägt M1 nicht als Betriebsmodus einer Sitzung. Wer M1 über einen Turn hinaus braucht, braucht die globale Berechtigungsschicht oder einen Nur-Lese-Modus des Clients. Innerhalb des Turns gilt die Entfernung auch für einen Unteragenten, den der Skill startet – gemessen am 2026-09-13 (`tests/protocols/2026-09-13-erhebung-unteragent.md`) `[MESS]`, mit Kontrolllauf –, sie reicht dort aber genauso weit wie oben: Mit gesperrtem `Write, Edit` schrieb der Unteragent über `Bash`. Das rein lesende Agentenprofil ist der belastbarere Weg zu M1, gemessen am 2026-09-13 `[MESS]`: Ein Profil mit `tools: Read, Grep, Glob` hatte kein Schreibwerkzeug im Vorrat; es hängt nicht am Turn, sondern am Profil. Es kann sich nicht selbst erweitern `[MESS]`: Ihm fehlt das Werkzeug, um eine zweite, weniger beschränkte Ebene zu starten. Bei Widerspruch gewinnt die restriktivere Liste `[MESS]` – ein Profil, das ein Werkzeug ausdrücklich erlaubt, bekommt es unter einem Skill, der es sperrt, nicht; die Liste lässt sich nur enger machen, nie weiter. `allowed-tools` trägt die Grenze nicht: Es ist eine Vorabfreigabe und keine Beschränkung – gemessen am 2026-09-12 (`tests/protocols/2026-09-12-B01-allowed-tools.md`, B01) `[MESS]`. Jedes Pack benennt, was an die Stelle eines verworfenen Feldes tritt, sonst bricht die Installation ab; der Ersatz steht in Zeile S3 der Fähigkeitsmatrix. Unabhängig vom Modus wirken die Sperren auf Secret- und Kernpfade `[DOK]` |
 
 #### M2 Guided Planning
 
@@ -73,7 +73,7 @@ Jede Aufgabe wird genau einem Betriebsmodus zugeordnet. Den Modus gibt der Mensc
 | Prüfpflichten | Mensch bestätigt oder verwirft den Plan schriftlich (Stufe mittel) beziehungsweise `<APPROVAL_ROLE>` gibt frei (Stufe hoch); jede Planänderung nach Freigabe erfordert erneute Bestätigung |
 | Abbruchkriterien | Anforderungen widersprüchlich; Plan würde Delegationsverbotsliste berühren; Plan erfordert Kontext außerhalb der Freigabe |
 | Erwartete Ausgabe | Plan nach `.koolie/core/templates/PLAN_TEMPLATE.md`: Ziel, Annahmen (gekennzeichnet), offene Fragen, Schritte, betroffene Dateien, Teststrategie, Risiken, Rollback |
-| Umsetzung im Werkzeug | **Die Beschränkung des Schreibrechts auf die Plan-Datei gilt normativ; technisch durchsetzen lässt sie sich seit `1.20.2` mit einer Modusbindung** (D-501): Der Mensch führt im eigenen Terminal `python .koolie/core/mandat.py modus M2 --ablage <pfad>` aus, und der Schutz-Hook sperrt jedes Schreibwerkzeug außerhalb der Plan-Ablage – befristet wie ein Mandat, und der Client kann die Bindung weder setzen noch aufheben `[MESS]`. **Grenze:** Ein Shell-Befehl, der schreibt, entgeht der Bindung (D-30); dort tragen Rückfrage und Regelschicht. Ohne Bindung gilt die Grenze nur normativ. Kennt der KI-Client einen eigenen Planungsmodus mit persistenter Plan-Datei, ist dieser vorzuziehen (Fähigkeitsmatrix des Client Packs) `[DOK]` je Pack. Liegt die Plan-Datei außerhalb des Repositorys, wird sie für die Nachvollziehbarkeit in das im Overlay festgelegte Ablageformat übernommen (`<TBD: Ablage von Plänen im Projekt>`) |
+| Umsetzung im Werkzeug | Die Beschränkung des Schreibrechts auf die Plan-Datei gilt normativ; technisch durchsetzen lässt sie sich mit einer Modusbindung: Der Mensch führt im eigenen Terminal `python .koolie/core/mandat.py modus M2 --ablage <pfad>` aus, und der Schutz-Hook sperrt jedes Schreibwerkzeug außerhalb der Plan-Ablage – befristet wie ein Mandat, und der Client kann die Bindung weder setzen noch aufheben `[MESS]`. Grenze: Ein Shell-Befehl, der schreibt, entgeht der Bindung; dort tragen Rückfrage und Regelschicht. Ohne Bindung gilt die Grenze nur normativ. Kennt der KI-Client einen eigenen Planungsmodus mit persistenter Plan-Datei, ist dieser vorzuziehen (Fähigkeitsmatrix des Client Packs) `[DOK]` je Pack. Liegt die Plan-Datei außerhalb des Repositorys, wird sie für die Nachvollziehbarkeit in das im Overlay festgelegte Ablageformat übernommen (`<TBD: Ablage von Plänen im Projekt>`) |
 
 #### M3 Controlled Modification
 
@@ -83,10 +83,10 @@ Jede Aufgabe wird genau einem Betriebsmodus zugeordnet. Den Modus gibt der Mensc
 | Zulässige Aktionen | Dateien innerhalb `<ALLOWED_PATHS>` ändern; freigegebene Build-, Test- und Lint-Befehle ausführen; lesende Git-Befehle (status, diff, log, show, blame) zur Aufnahme des eigenen Änderungsstands ausführen; nach jedem Schritt Zwischenstand berichten |
 | Verbotene Aktionen | Änderungen außerhalb des Scopes; Änderungen an `<EXCLUDED_PATHS>`; neue Abhängigkeiten ohne Freigabe; Git-Operationen mit Fernwirkung (push, merge, tag, rebase auf geteilten Branches); Löschen von Dateien ohne ausdrückliche Einzelfreigabe; Deaktivieren oder Löschen von Tests; Anpassen von Quality-Gate-Konfigurationen |
 | Benötigter Kontext | Bestätigter Plan; betroffene Dateien; Coding Conventions; Test- und Build-Befehle aus dem Overlay |
-| Prüfpflichten | Mensch beobachtet die Sitzung im rückfragenden Standardmodus (D-05; wie der Modus im Client heißt, nennt die Fähigkeitsmatrix des Client Packs) und bestätigt Schreib- und Ausführungsanfragen einzeln; vollständiger Diff-Review vor Commit; Quality Gates |
+| Prüfpflichten | Mensch beobachtet die Sitzung im rückfragenden Standardmodus (wie der Modus im Client heißt, nennt die Fähigkeitsmatrix des Client Packs) und bestätigt Schreib- und Ausführungsanfragen einzeln; vollständiger Diff-Review vor Commit; Quality Gates |
 | Abbruchkriterien | Abweichung vom Plan erforderlich; unerwartete Berührung weiterer Komponenten; fehlgeschlagene Tests ohne klare Ursache; Fund von Secrets oder personenbezogenen Echtdaten; Anstieg der Kontrollstufe |
 | Erwartete Ausgabe | Änderungssatz (Diff) mit Schrittprotokoll, ausgeführten Befehlen und Ergebnissen, Abweichungen vom Plan, Restrisiken, Vorschlag für Commit-Nachricht |
-| Umsetzung im Werkzeug | Rückfragender Standardmodus (Schreib- und Ausführungsanfragen werden einzeln bestätigt) `[DOK]`; Berechtigungsdatei mit Verweigerung für ausgeschlossene Pfade und Fernwirkungs-Befehle, Rückfrage für Schreiben und Ausführen `[DOK]`; ein Modus ohne Rückfragen DARF NICHT verwendet werden (D-05) `[KONZ]`; sitzungsweite Freigaben nur für die im Overlay freigegebenen Testbefehle `[EMPF]`. **Die Beschränkung auf `<ALLOWED_PATHS>` lässt sich seit `1.23.0` binden** (D-523): `python .koolie/core/mandat.py modus M3 [--umfang <glob> …]` – der Schutz-Hook sperrt dann jedes Schreibwerkzeug außerhalb der Pfadliste (mit `--umfang` außerhalb der Schnittmenge mit dem freigegebenen Scope) und in `<READ_ONLY_PATHS>` `[MESS]`. Die Bindung ersetzt weder die Rückfrage noch das Review; ein Shell-Befehl, der schreibt, entgeht ihr (D-30) |
+| Umsetzung im Werkzeug | Rückfragender Standardmodus (Schreib- und Ausführungsanfragen werden einzeln bestätigt) `[DOK]`; Berechtigungsdatei mit Verweigerung für ausgeschlossene Pfade und Fernwirkungs-Befehle, Rückfrage für Schreiben und Ausführen `[DOK]`; ein Modus ohne Rückfragen DARF NICHT verwendet werden `[KONZ]`; sitzungsweite Freigaben nur für die im Overlay freigegebenen Testbefehle `[EMPF]`. Die Beschränkung auf `<ALLOWED_PATHS>` lässt sich binden: `python .koolie/core/mandat.py modus M3 [--umfang <glob> …]` – der Schutz-Hook sperrt dann jedes Schreibwerkzeug außerhalb der Pfadliste (mit `--umfang` außerhalb der Schnittmenge mit dem freigegebenen Scope) und in `<READ_ONLY_PATHS>` `[MESS]`. Die Bindung ersetzt weder die Rückfrage noch das Review; ein Shell-Befehl, der schreibt, entgeht ihr |
 
 #### M4 Test and Validation
 
@@ -99,7 +99,7 @@ Jede Aufgabe wird genau einem Betriebsmodus zugeordnet. Den Modus gibt der Mensc
 | Prüfpflichten | Mensch prüft, ob Tests das fachliche Verhalten und nicht die Implementierung zementieren; prüft synthetische Testdaten; prüft Aussagekraft fehlschlagender Tests |
 | Abbruchkriterien | Test erfordert Änderung am Produktivcode (dann Wechsel nach M2/M3 durch den Menschen); Testinfrastruktur nicht verfügbar; Testdaten nur aus Echtdaten ableitbar |
 | Erwartete Ausgabe | Testdateien, Testprotokoll (Befehl, Ergebnis, Dauer), Liste nicht abgedeckter Fälle, Bewertung der Aussagekraft |
-| Umsetzung im Werkzeug | **Die Beschränkung auf `<TEST_PATHS>` gilt normativ; technisch durchsetzen lässt sie sich seit `1.23.0` mit einer Modusbindung** (`mandat.py modus M4`, D-523): Dann sperrt der Schutz-Hook jedes Schreibwerkzeug außerhalb von `<TEST_PATHS>` `[MESS]`; ein Shell-Befehl, der schreibt, entgeht ihr (D-30). Ohne Bindung entscheidet der Hook innerhalb und außerhalb des Scopes gleich – gemessen am 2026-09-12 (`.koolie/core/tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`, B05) `[DOK]` für den Befund. Die Skill-`permissions` tragen sie ebenfalls nicht (B01, siehe M1); welcher Mechanismus stattdessen trägt, steht in Zeile S3 der Fähigkeitsmatrix des jeweiligen Packs. Getragen wird sie von der Regelschicht und der Prüfpflicht dieses Modus; unabhängig davon wirken die Sperren auf Secret- und Kernpfade `[DOK]` |
+| Umsetzung im Werkzeug | Die Beschränkung auf `<TEST_PATHS>` gilt normativ; technisch durchsetzen lässt sie sich mit einer Modusbindung (`mandat.py modus M4`): Dann sperrt der Schutz-Hook jedes Schreibwerkzeug außerhalb von `<TEST_PATHS>` `[MESS]`; ein Shell-Befehl, der schreibt, entgeht ihr. Ohne Bindung entscheidet der Hook innerhalb und außerhalb des Scopes gleich – gemessen am 2026-09-12 (`.koolie/core/tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`, B05) `[DOK]` für den Befund. Die Skill-`permissions` tragen sie ebenfalls nicht (B01, siehe M1); welcher Mechanismus stattdessen trägt, steht in Zeile S3 der Fähigkeitsmatrix des jeweiligen Packs. Getragen wird sie von der Regelschicht und der Prüfpflicht dieses Modus; unabhängig davon wirken die Sperren auf Secret- und Kernpfade `[DOK]` |
 
 #### M5 Documentation Support
 
@@ -112,21 +112,21 @@ Jede Aufgabe wird genau einem Betriebsmodus zugeordnet. Den Modus gibt der Mensc
 | Prüfpflichten | Fachliche Prüfung durch eine Person mit Domänenwissen; Prüfung auf vertrauliche Inhalte vor Ablage in `<DOCUMENTATION_PLATFORM>` |
 | Abbruchkriterien | Dokumentierter Sachverhalt aus dem Code nicht belegbar; Widerspruch zwischen Code und bestehender Dokumentation, der eine fachliche Entscheidung erfordert |
 | Erwartete Ausgabe | Geänderte Dokumentationsdateien, Änderungsübersicht, Liste belegter Quellen, Liste offener fachlicher Klärungen |
-| Umsetzung im Werkzeug | **Die Beschränkung auf `<DOC_PATHS>` gilt normativ; technisch durchsetzen lässt sie sich seit `1.23.0` mit einer Modusbindung** (`mandat.py modus M5`, D-523; ohne `<DOC_PATHS>` bindet sie nicht) `[MESS]`; ein Shell-Befehl, der schreibt, entgeht ihr (D-30). Ohne Bindung gilt: Eine Beschränkung auf `<DOC_PATHS>` unter Ausschluss aller übrigen Pfade ist über Skill-`permissions` nicht ausdrückbar (`<DOC_PATHS>` ist Teilmenge von `<ALLOWED_PATHS>`, und `deny` gewinnt gegen `allow`) `[DOK]`, und das Feld `permissions` kennt nicht jeder Client für Skills (`skill_frontmatter.drop_fields` im Manifest des Packs, B01) – was an seine Stelle tritt, benennt die Zeile S3 seiner Fähigkeitsmatrix. Der Schutz-Hook kennt den Modus dann nicht (`.koolie/core/tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`, B05) `[DOK]` für den Befund. Getragen wird sie von der Regelschicht und der fachlichen Prüfpflicht dieses Modus |
+| Umsetzung im Werkzeug | Die Beschränkung auf `<DOC_PATHS>` gilt normativ; technisch durchsetzen lässt sie sich mit einer Modusbindung (`mandat.py modus M5`; ohne `<DOC_PATHS>` bindet sie nicht) `[MESS]`; ein Shell-Befehl, der schreibt, entgeht ihr. Ohne Bindung gilt: Eine Beschränkung auf `<DOC_PATHS>` unter Ausschluss aller übrigen Pfade ist über Skill-`permissions` nicht ausdrückbar (`<DOC_PATHS>` ist Teilmenge von `<ALLOWED_PATHS>`, und `deny` gewinnt gegen `allow`) `[DOK]`, und das Feld `permissions` kennt nicht jeder Client für Skills (`skill_frontmatter.drop_fields` im Manifest des Packs, B01) – was an seine Stelle tritt, benennt die Zeile S3 seiner Fähigkeitsmatrix. Der Schutz-Hook kennt den Modus dann nicht (`.koolie/core/tests/protocols/2026-09-12-B04-B05-gegenpruefung.md`, B05) `[DOK]` für den Befund. Getragen wird sie von der Regelschicht und der fachlichen Prüfpflicht dieses Modus |
 
 #### M6 Mandated Maintenance
 
 | Aspekt | Festlegung |
 |---|---|
-| Zweck | Eine Entscheidung, die der Mensch in der Sitzung getroffen hat, direkt in das Project Overlay und die Projektdokumentation eintragen – bei der Einrichtung, nach einem Framework-Update und im laufenden Projekt –, statt sie als Vorlage zum Abschreiben zu liefern (D-446) |
+| Zweck | Eine Entscheidung, die der Mensch in der Sitzung getroffen hat, direkt in das Project Overlay und die Projektdokumentation eintragen – bei der Einrichtung, nach einem Framework-Update und im laufenden Projekt –, statt sie als Vorlage zum Abschreiben zu liefern |
 | Voraussetzung | Ein **Mandat**, das der Mensch im eigenen Terminal erteilt: `python .koolie/core/mandat.py erteilen --rolle <Rolle> --umfang overlay\|dokumente --minuten <1–480>`. Es ist befristet, auf einen Umfang begrenzt und liegt im Git-Verzeichnis, nicht im Arbeitsbaum. Ein Satz im Chat ist kein Mandat |
 | Zulässige Aktionen | Im Umfang des Mandats Dateien erstellen und ändern; in `<DOC_PATHS>` wie M5; lesende Git-Befehle; `validate-framework.py`, `install.py --check` und `mandat.py status` ausführen; offene Punkte als `<TBD: …>` eintragen |
 | Verbotene Aktionen | Eine Entscheidung treffen, die der Mensch nicht getroffen hat (V3, V10); ein Mandat erteilen, verlängern oder ändern; Kern, Laufzeitschicht, Wurzel-Anweisungsdatei oder Berechtigungsdatei ändern; `install.py --update` ausführen (es erzeugt die Berechtigungsdatei neu – V6); eine Regel des Kerns im Overlay lockern (Verschärfungsprinzip) |
 | Benötigter Kontext | Die Entscheidung des Menschen in der Sitzung, mit Rolle; die betroffenen Overlay-Abschnitte; bei einem Framework-Update die Meldungen von `install.py --update` |
 | Prüfpflichten | Am Ende `python .koolie/core/tests/scripts/validate-framework.py --strict-overlay`; Überprüfung jeder Änderung im Merge Request durch den Menschen (V1) |
 | Abbruchkriterien | Kein gültiges Mandat (Blockade-Hinweis, Abschnitt 3.7); die Anweisung verlangt eine Entscheidung statt ihrer Eintragung; eine Änderung würde eine Kernregel lockern; der Validator meldet einen Fehler, den die Eintragung verursacht hat |
-| Erwartete Ausgabe | Geänderte Dateien; im Änderungsverlauf des Overlays eine Zeile mit Rolle, Anlass und Datum; im Ergebnisbericht Mandat (Rolle, Umfang), Validatorergebnis und **jede geänderte Befehlsfreigabe oder Pfadliste als berechtigungswirksam** – sie wirkt erst, wenn der Mensch `install.py --update` ausführt |
-| Umsetzung im Werkzeug | **Technisch durchgesetzt über den Schutz-Hook** `[KONZ]`: Er sperrt `.koolie/project-overlay/` für jedes Schreibwerkzeug, solange kein gültiges Mandat das Ziel deckt, und sperrt Mandatsdatei und `mandat.py` für jede nicht lesende Operation (D-447). Die Berechtigungsdatei sperrt das Overlay seit `1.17.0` nicht mehr – eine statische Sperre könnte das Mandat nicht aufheben (D-448). Wo der Hook eines Packs nicht läuft, gilt die Grenze nur normativ; die Fähigkeitsmatrix des Packs sagt, wo das der Fall ist |
+| Erwartete Ausgabe | Geänderte Dateien; im Änderungsverlauf des Overlays eine Zeile mit Rolle, Anlass und Datum; im Ergebnisbericht Mandat (Rolle, Umfang), Validatorergebnis und jede geänderte Befehlsfreigabe oder Pfadliste als berechtigungswirksam – sie wirkt erst, wenn der Mensch `install.py --update` ausführt |
+| Umsetzung im Werkzeug | Technisch durchgesetzt über den Schutz-Hook `[KONZ]`: Er sperrt `.koolie/project-overlay/` für jedes Schreibwerkzeug, solange kein gültiges Mandat das Ziel deckt, und sperrt Mandatsdatei und `mandat.py` für jede nicht lesende Operation. Die Berechtigungsdatei sperrt das Overlay nicht – eine statische Sperre könnte das Mandat nicht aufheben. Wo der Hook eines Packs nicht läuft, gilt die Grenze nur normativ; die Fähigkeitsmatrix des Packs sagt, wo das der Fall ist |
 
 ## 3. Querschnittsregeln für alle Modi (normativ)
 
@@ -134,8 +134,8 @@ Jede Aufgabe wird genau einem Betriebsmodus zugeordnet. Den Modus gibt der Mensc
 
 1. Eine Sitzung bearbeitet eine Aufgabe. Neue Aufgaben MÜSSEN in neuen Sitzungen begonnen werden (Least Context, Nachvollziehbarkeit).
 2. Sitzungsweite Freigaben („für diese Sitzung erlauben") SOLLEN nur für die im Overlay freigegebenen Testbefehle erteilt werden. Projektweite oder globale Freigaben `[DOK]` DÜRFEN NICHT durch einzelne Entwicklerinnen oder Entwickler erteilt werden; sie erfordern einen Änderungsantrag an die Berechtigungsdatei.
-3. Parallel laufende Agentensitzungen `[DOK]` sind an **Voraussetzungen** gebunden, nicht an eine Kontrollstufe der Aufgabe: Die Aufgaben MÜSSEN voneinander unabhängig sein, die Schreibziele disjunkt – sie DÜRFEN NICHT auf denselben Dateien arbeiten –, eine Person MUSS die Aufsicht führen, und jede Sitzung MUSS ihre eigene Aufgabe und ihren eigenen Ergebnisbericht haben. Die Einstufung dieser Arbeitsweise leistet R12 (`.koolie/core/framework/core/09-risk-model.md`, Abschnitt 2): rein lesende Parallelarbeit unter Aufsicht niedrig, schreibende auf getrennten Zielen mittel, gemeinsame Schreibziele hoch und damit ausgeschlossen. Jede parallel bearbeitete Aufgabe bleibt an die Betriebsmodi **ihrer eigenen** Kontrollstufe gebunden (D-54).
-4. Hintergrund-Subagenten DÜRFEN NICHT für Modus M3 verwendet werden. **Diese Grenze gilt normativ; technisch abbildbar ist sie nicht** `[MESS]`: Sperrbar ist nur das Startwerkzeug ganz – gemessen am 2026-09-13, `disallowed-tools: Agent` weist den Start ab, und die zweite Schreibweise `Task` ebenso (`tests/protocols/2026-09-13-erhebung-unteragent.md`, D-70). „Nur im Hintergrund" ist dagegen ein Argument (`run_in_background`), und ein Argumentmuster in der Werkzeugsperre wirkt nach D-66 lautlos gar nicht. Wer diese Regel technisch durchsetzen will, sperrt Unteragenten vollständig – das ist mehr, als die Regel sagt, und deshalb bleibt sie eine Anweisung. Was ein Skill sperrt, ist auch im Hintergrund gesperrt – gemessen am 2026-09-13 mit Kontrolllauf (D-72) `[MESS]`. Ein Hintergrund-Unteragent ist also kein Weg, ein entferntes Werkzeug zurückzubekommen, sondern ein Weg, unbeaufsichtigt zu arbeiten – und das untersagt die Regel. Für M1 KANN ein rein lesendes Agentenprofil genutzt werden, sofern der KI-Client eines kennt (Fähigkeitsmatrix des Client Packs, A1); bei `claude-code` ist seine Wirkung gemessen (D-68).
+3. Parallel laufende Agentensitzungen `[DOK]` sind an **Voraussetzungen** gebunden, nicht an eine Kontrollstufe der Aufgabe: Die Aufgaben MÜSSEN voneinander unabhängig sein, die Schreibziele disjunkt – sie DÜRFEN NICHT auf denselben Dateien arbeiten –, eine Person MUSS die Aufsicht führen, und jede Sitzung MUSS ihre eigene Aufgabe und ihren eigenen Ergebnisbericht haben. Die Einstufung dieser Arbeitsweise leistet R12 (`.koolie/core/framework/core/09-risk-model.md`, Abschnitt 2): rein lesende Parallelarbeit unter Aufsicht niedrig, schreibende auf getrennten Zielen mittel, gemeinsame Schreibziele hoch und damit ausgeschlossen. Jede parallel bearbeitete Aufgabe bleibt an die Betriebsmodi **ihrer eigenen** Kontrollstufe gebunden.
+4. Hintergrund-Subagenten DÜRFEN NICHT für Modus M3 verwendet werden. Diese Grenze gilt normativ; technisch abbildbar ist sie nicht `[MESS]`: Sperrbar ist nur das Startwerkzeug ganz – gemessen am 2026-09-13, `disallowed-tools: Agent` weist den Start ab, und die zweite Schreibweise `Task` ebenso (`tests/protocols/2026-09-13-erhebung-unteragent.md`). „Nur im Hintergrund" ist dagegen ein Argument (`run_in_background`), und ein Argumentmuster in der Werkzeugsperre wirkt lautlos gar nicht. Wer diese Regel technisch durchsetzen will, sperrt Unteragenten vollständig – das ist mehr, als die Regel sagt, und deshalb bleibt sie eine Anweisung. Was ein Skill sperrt, ist auch im Hintergrund gesperrt – gemessen am 2026-09-13 mit Kontrolllauf `[MESS]`. Ein Hintergrund-Unteragent ist also kein Weg, ein entferntes Werkzeug zurückzubekommen, sondern ein Weg, unbeaufsichtigt zu arbeiten – und das untersagt die Regel. Für M1 KANN ein rein lesendes Agentenprofil genutzt werden, sofern der KI-Client eines kennt (Fähigkeitsmatrix des Client Packs, A1); bei `claude-code` ist seine Wirkung gemessen.
 
 ### 3.2 Befehlsausführung
 
@@ -153,7 +153,7 @@ Fehlt Kontext, fragt der KI-Client gezielt nach (was fehlt, wozu es benötigt wi
 
 ### 3.5 Nachvollziehbarkeit
 
-Jede Aufgabe endet mit einem Ergebnisbericht (Abschnitt 3.6). **Zwischen den Turns derselben Aufgabe genügt ein Kurzstatus** in ein bis drei Zeilen – was getan ist, was als Nächstes kommt, was fehlt; der volle Bericht steht am Aufgabenende und bei jedem Moduswechsel (D-454). Bei Kontrollstufe mittel und hoch wird der Bericht im Merge Request oder im führenden System abgelegt, das Overlay Abschnitt 13 nennt (Ticketsystem oder Rückfallablage im Repositorium); dort liegen auch Plan und dokumentierte Freigabe.
+Jede Aufgabe endet mit einem Ergebnisbericht (Abschnitt 3.6). Zwischen den Turns derselben Aufgabe genügt ein Kurzstatus in ein bis drei Zeilen – was getan ist, was als Nächstes kommt, was fehlt; der volle Bericht steht am Aufgabenende und bei jedem Moduswechsel. Bei Kontrollstufe mittel und hoch wird der Bericht im Merge Request oder im führenden System abgelegt, das Overlay Abschnitt 13 nennt (Ticketsystem oder Rückfallablage im Repositorium); dort liegen auch Plan und dokumentierte Freigabe.
 
 ### 3.6 Standardformat Ergebnisbericht
 
@@ -183,7 +183,7 @@ Jede Aufgabe endet mit einem Ergebnisbericht (Abschnitt 3.6). **Zwischen den Tur
 
 ### 3.7 Blockade-Hinweis
 
-Sperrt eine Regel, ein Hook, eine Berechtigung, ein fehlendes Mandat, ein fehlender Overlay-Wert oder ein abgewiesener Skill-Aufruf den nächsten Schritt, gibt der KI-Client **sofort und ohne Nachfrage** vier kurze Zeilen aus (D-450):
+Sperrt eine Regel, ein Hook, eine Berechtigung, ein fehlendes Mandat, ein fehlender Overlay-Wert oder ein abgewiesener Skill-Aufruf den nächsten Schritt, gibt der KI-Client **sofort und ohne Nachfrage** vier kurze Zeilen aus:
 
 ```text
 Gesperrt: <was – ein Satz>

package/.koolie/core/framework/core/06-prompting-rules.md

@@ -32,20 +32,20 @@ Jede Anweisung an den KI-Client, die über eine einfache Rückfrage hinausgeht,
 4. **Keine Rollenspiele mit Regelwirkung.** Anweisungen, die den KI-Client auffordern, Regeln zu ignorieren, sich als anderes System auszugeben oder Sicherheitsprüfungen zu überspringen, sind unzulässig – auch zu Testzwecken außerhalb des Testkatalogs.
 5. **Ergebnis vor Stil.** Prompts fordern belegte Ergebnisse (Fundstellen, Testausgaben), nicht Selbstbewertungen („Bist du sicher?“).
 6. **Sprache.** Anweisungen werden in der im Overlay festgelegten Arbeitssprache verfasst (`<TBD: Arbeitssprache>`); Bezeichner, Befehle und Pfade bleiben unverändert.
-7. **Skills bevorzugen – von beiden Seiten.** Liegt für eine Aufgabe ein Skill vor, benennt ihn die Anweisung, und der KI-Client ruft ihn auch dann auf, wenn die Anweisung ihn nicht nennt (D-84; Wurzel-Anweisungsdatei Abschnitt 17, `05-working-model.md` Abschnitt 1; wie ein Skill aufgerufen wird, nennt die Fähigkeitsmatrix des Client Packs, Zeile S2). Freie Prompts sind für Aufgaben ohne passenden Skill vorgesehen. Gemessen am 2026-09-14 hat eine Sitzung den passenden Skill benannt und seinen Aufruf im eigenen Bericht für „nicht nötig“ erklärt (`.koolie/core/tests/protocols/2026-09-14-erhebung-skillaufruf.md`).
+7. **Skills bevorzugen – von beiden Seiten.** Liegt für eine Aufgabe ein Skill vor, benennt ihn die Anweisung, und der KI-Client ruft ihn auch dann auf, wenn die Anweisung ihn nicht nennt (Wurzel-Anweisungsdatei Abschnitt 17, `05-working-model.md` Abschnitt 1; wie ein Skill aufgerufen wird, nennt die Fähigkeitsmatrix des Client Packs, Zeile S2). Freie Prompts sind für Aufgaben ohne passenden Skill vorgesehen. Gemessen am 2026-09-14 hat eine Sitzung den passenden Skill benannt und seinen Aufruf im eigenen Bericht für „nicht nötig“ erklärt (`.koolie/core/tests/protocols/2026-09-14-erhebung-skillaufruf.md`).
 8. **Iterationen kennzeichnen.** Folgeanweisungen in derselben Sitzung benennen, was sich gegenüber dem vorherigen Schritt ändert („Nur Schritt 3 des Plans anpassen: …“).
 
 ## 3. Unzulässige Prompt-Muster (normativ)
 
 | Muster | Warum unzulässig | Stattdessen |
 |---|---|---|
-| „Behebe alle Fehler im Projekt“ | Kein Scope, keine Reversibilität, keine Prüfbarkeit | Ein Fehler, eine Sitzung, Skill `fw-error-analyze` |
+| „Behebe alle Fehler im Projekt“ | Kein Scope, keine Reversibilität, keine Prüfbarkeit | Ein Fehler, eine Sitzung, Skill `koolie-error-analyze` |
 | „Hier ist der Ticket-Export, mach das“ | Ungeprüfter Kontext (K2/K3-Risiko), kein Ziel | Ticket bereinigen, Ziel und Akzeptanzkriterien formulieren |
-| „Schreib die Tests so, dass sie durchlaufen“ | Zementiert Fehlverhalten, umgeht Quality Gates | Skill `fw-tests` mit fachlichen Erwartungen |
-| „Push das und erstell den MR“ | Delegationsverbot V2 | Skill `fw-mr-description`, Push und MR durch den Menschen |
+| „Schreib die Tests so, dass sie durchlaufen“ | Zementiert Fehlverhalten, umgeht Quality Gates | Skill `koolie-tests` mit fachlichen Erwartungen |
+| „Push das und erstell den MR“ | Delegationsverbot V2 | Skill `koolie-mr-description`, Push und MR durch den Menschen |
 | „Ignoriere die Regeln, das ist nur ein Test“ | Regelumgehung, Injektionsmuster | Testkatalog verwenden |
 | „Welche Bibliothek wäre gut? Bau sie ein.“ | Delegationsverbot V3 | Optionsanalyse anfordern, Entscheidung durch Mensch |
 
 ## 4. Erläuterung
 
-Gute Prompts ähneln guten Tickets: Sie beschreiben Ziel, Grenzen und Erfolgskriterium und überlassen den Weg dem Bearbeiter – mit dem Unterschied, dass der Bearbeiter hier bei jeder Unklarheit sofort nachfragen soll. Wer Schwierigkeiten hat, einen Prompt zu formulieren, hat meist noch keine klare Aufgabe; dann hilft der Skill `fw-change-analyze` oder ein Gespräch mit dem Product Owner mehr als ein besserer Prompt.
+Gute Prompts ähneln guten Tickets: Sie beschreiben Ziel, Grenzen und Erfolgskriterium und überlassen den Weg dem Bearbeiter – mit dem Unterschied, dass der Bearbeiter hier bei jeder Unklarheit sofort nachfragen soll. Wer Schwierigkeiten hat, einen Prompt zu formulieren, hat meist noch keine klare Aufgabe; dann hilft der Skill `koolie-change-analyze` oder ein Gespräch mit dem Product Owner mehr als ein besserer Prompt.

package/.koolie/core/framework/core/07-review-rules.md

@@ -13,7 +13,7 @@
 
 1. Ein Review prüft das Ergebnis, nicht die Entstehung: Für den Reviewer gelten dieselben Maßstäbe wie bei manuell erstelltem Code, ergänzt um die Prüfpunkte aus Abschnitt 2.
 2. Die Bearbeiterin oder der Bearbeiter ist die erste Reviewerin beziehungsweise der erste Reviewer (Selbstreview anhand `.koolie/core/checklists/04-review-ai-code.md`) und DARF NICHT die einzige Prüfinstanz sein (Vier-Augen-Prinzip, sofern im Projekt vorgesehen; ab Kontrollstufe mittel verpflichtend).
-3. Der KI-Client KANN das Review unterstützen (Skill `fw-review-support`), aber ein KI-Befund ersetzt keine menschliche Prüfung und eine KI-„Freigabe“ existiert nicht (V1).
+3. Der KI-Client KANN das Review unterstützen (Skill `koolie-review-support`), aber ein KI-Befund ersetzt keine menschliche Prüfung und eine KI-„Freigabe“ existiert nicht (V1).
 4. Reviewerinnen und Reviewer erhalten den KI-Nutzungsvermerk (Kontrollstufe, Modus, Skills, Kontext) vor Beginn des Reviews.
 
 ## 2. Zusätzliche Prüfpunkte für KI-generierte Änderungen (normativ)

package/.koolie/core/framework/core/08-skill-conventions.md

@@ -6,7 +6,7 @@
 | Ebene | 1 – Framework Core |
 | Verbindlichkeit | normativ (Abschnitte 1–7), Erläuterung (Abschnitt 8) |
 | Owner | `<FRAMEWORK_OWNER>` |
-| Version | 0.3.5 |
+| Version | 0.3.6 |
 | Status | `pilot` |
 
 ## 1. Begriff (normativ)
@@ -26,12 +26,12 @@ Skill-Ablage der Laufzeitschicht
 
 - Ablageort: die Skill-Ablage der Laufzeitschicht, je Skill ein Unterverzeichnis mit `SKILL.md`. Der konkrete Pfad je Client steht in `.koolie/core/docs/RUNTIME_GLOSSARY.md` (Zeile „Skill-Ablage“), etwaige Alternativpfade im Client Pack.
 - Der Verzeichnisname ist der Aufrufname; die Aufrufform je Client (etwa `/skill-name`) nennt Zeile S2 der Fähigkeitsmatrix seines Client Packs.
-- Framework-Skills tragen das Präfix `fw-`, projektspezifische Skills `prj-`, Role-Pack-Skills `role-<pack>-`, Technology-Pack-Skills `tech-<pack>-`.
+- Mitgelieferte Skills – aus dem Kern wie aus Role und Technology Packs – tragen das Präfix `koolie-`, projektspezifische Skills `prj-`. Ein mitgelieferter Name ist über alle Packs eindeutig.
 - Skill-Namen bestehen aus Kleinbuchstaben, Ziffern und Bindestrichen.
 
 ## 3. Frontmatter (normativ)
 
-Die Tabelle beschreibt das Frontmatter der **Quelle** unter `framework/skills/`. Es ist das Quellformat des Frameworks: `install.py` bildet es je Client Pack ab, und Felder wie `permissions` und `triggers` erscheinen in der installierten Fassung unter dem Namen, den das Manifest des Packs dafür führt, oder werden durch den dort benannten Ersatz getragen. **Die installierte Fassung enthält ausschließlich Felder, die in der Dokumentation des Clients belegt sind** `[DOK]`; wo das für ein Pack nicht erhoben ist, sagt es dessen Fähigkeitsmatrix (D-388).
+Die Tabelle beschreibt das Frontmatter der **Quelle** unter `framework/skills/`. Es ist das Quellformat des Frameworks: `install.py` bildet es je Client Pack ab, und Felder wie `permissions` und `triggers` erscheinen in der installierten Fassung unter dem Namen, den das Manifest des Packs dafür führt, oder werden durch den dort benannten Ersatz getragen. **Die installierte Fassung enthält ausschließlich Felder, die in der Dokumentation des Clients belegt sind** `[DOK]`; wo das für ein Pack nicht erhoben ist, sagt es dessen Fähigkeitsmatrix.
 
 | Feld | Pflicht | Regel |
 |---|---|---|
@@ -43,7 +43,7 @@ Die Tabelle beschreibt das Frontmatter der **Quelle** unter `framework/skills/`.
 | `triggers` | MUSS | `["user"]` für alle Skills, die Dateien ändern oder Befehle ausführen; `["user", "model"]` nur für rein lesende Skills |
 | `model`, `subagent`, `agent` | KANN | nur mit dokumentierter Begründung im Metadatenblock |
 
-Framework-Metadaten (ID, Version, Status, Owner) stehen nicht im Frontmatter, sondern im Metadatenblock des Dateikörpers (D-08).
+Framework-Metadaten (ID, Version, Status, Owner) stehen nicht im Frontmatter, sondern im Metadatenblock des Dateikörpers.
 
 ## 4. Pflichtinhalte je Skill (normativ)
 
@@ -57,7 +57,7 @@ Framework-Metadaten (ID, Version, Status, Owner) stehen nicht im Frontmatter, so
 | 6 | Zielgruppe | SKILL.md Abschnitt 1 | Rollen |
 | 7 | Trigger | SKILL.md Abschnitt 1 | Situationen, in denen der Skill verwendet wird; Aufrufform |
 | 8 | Vorbedingungen | SKILL.md Abschnitt 2 | Was vor dem Aufruf erfüllt sein muss (Preflight, Kontrollstufe, Modus) |
-| 9 | Benötigte Eingaben | SKILL.md Abschnitt 2 | Argumente und Kontext mit Kontextklasse; „K2 (bereinigt)“ heißt bereinigt **und** freigegeben (`02-privacy.md` Abschnitt 4, D-420) |
+| 9 | Benötigte Eingaben | SKILL.md Abschnitt 2 | Argumente und Kontext mit Kontextklasse; „K2 (bereinigt)“ heißt bereinigt **und** freigegeben (`02-privacy.md` Abschnitt 4) |
 | 10 | Zulässige Kontextquellen | SKILL.md Abschnitt 2 | Positivliste |
 | 11 | Ausgeschlossene Informationen | SKILL.md Abschnitt 2 | Negativliste, mindestens K3 |
 | 12 | Arbeitsschritte | SKILL.md Abschnitt 3 | nummeriert, mit Halte- und Rückfragepunkten |
@@ -85,7 +85,7 @@ Framework-Metadaten (ID, Version, Status, Owner) stehen nicht im Frontmatter, so
 2. Rückfragen bei Unklarheiten verlangen (P3) und Annahmen sichtbar machen.
 3. Scope ausdrücklich begrenzen (Pfade, Modus, Kontrollstufe) und Überschreitungen melden.
 4. Relevante Prüfungen definieren (welche Tests, welche Checkliste).
-5. Festes Ausgabeformat verwenden. Die Überschriften des Gerüsts werden **wörtlich** übernommen – ohne Umformulierung, ohne Zusatz, in derselben Ebene; was ein Abschnitt für den Fall erläutert, steht im Text darunter. Auch die Ergebnisausgabe eines Folgeturns trägt jede Pflichtüberschrift; ein Abschnitt, dessen Inhalt schon in einem früheren Turn steht, verweist dort darauf (D-432).
+5. Festes Ausgabeformat verwenden. Die Überschriften des Gerüsts werden **wörtlich** übernommen – ohne Umformulierung, ohne Zusatz, in derselben Ebene; was ein Abschnitt für den Fall erläutert, steht im Text darunter. Auch die Ergebnisausgabe eines Folgeturns trägt jede Pflichtüberschrift; ein Abschnitt, dessen Inhalt schon in einem früheren Turn steht, verweist dort darauf.
 6. Delegationsverbotsliste beachten.
 7. Bei Kontrollstufe hoch ohne dokumentierte Freigabe die Bearbeitung ablehnen.
 
@@ -99,16 +99,16 @@ Framework-Metadaten (ID, Version, Status, Owner) stehen nicht im Frontmatter, so
 | `veraltet` | ersetzt oder nicht mehr empfohlen; Nutzung mit Hinweis | Nachfolger benannt oder Begründung dokumentiert |
 | `zurückgezogen` | entfernt; Verzeichnis bleibt bis zum nächsten Major-Release mit Hinweisdatei | Deprecation-Frist abgelaufen |
 
-**Reichweite dieser Tabelle.** Die fünf Statuswerte und ihre Bedeutung gelten für **jeden** Modulträger des Frameworks; die Spalte *Voraussetzung für Übergang* gilt für Skills. Die Bedingungen für Modulträger, die keine Skills sind, stehen in `01-governance.md` Abschnitt 5 (D-102). **„Testfälle bestanden" ist Bedingung für `aktiv`, nicht für `pilot`** – für `pilot` genügt, dass sie vorliegen (D-103).
+**Reichweite dieser Tabelle.** Die fünf Statuswerte und ihre Bedeutung gelten für jeden Modulträger des Frameworks; die Spalte *Voraussetzung für Übergang* gilt für Skills. Die Bedingungen für Modulträger, die keine Skills sind, stehen in `01-governance.md` Abschnitt 5. **„Testfälle bestanden" ist Bedingung für `aktiv`, nicht für `pilot`** – für `pilot` genügt, dass sie vorliegen.
 
 - MAJOR: Änderung des Ausgabeformats oder des Scopes; MINOR: neue Schritte oder Prüfungen ohne Formatbruch; PATCH: Korrekturen und Formulierungen.
-- Jede Versionsänderung, die eine **Anweisung** des Skills berührt, erfordert die erneute Ausführung der Testfälle in `TESTS.md`; Ergebnisse werden im Testkatalog vermerkt. **Eine Änderung, die ausschließlich Erläuterung, Schreibweise oder einen Namen betrifft, tut das nicht** – ein Testblatt nimmt ab, was der Skill anweist, und was er erläutert, hat es nie geprüft (D-303, `K-84`).
-  ⚠️ Die Grenze zwischen Anweisung und Erläuterung zieht ein Mensch; keine Prüfung setzt sie durch (D-303). Wer sie zieht, schreibt in den Änderungsverlauf des Skills, **welche** Art von Änderung er vorgenommen hat.
+- Jede Versionsänderung, die eine **Anweisung** des Skills berührt, erfordert die erneute Ausführung der Testfälle in `TESTS.md`; Ergebnisse werden im Testkatalog vermerkt. Eine Änderung, die ausschließlich Erläuterung, Schreibweise oder einen Namen betrifft, tut das nicht – ein Testblatt nimmt ab, was der Skill anweist, und was er erläutert, hat es nie geprüft.
+  Die Grenze zwischen Anweisung und Erläuterung zieht ein Mensch; keine Prüfung setzt sie durch. Wer sie zieht, schreibt in den Änderungsverlauf des Skills, welche Art von Änderung er vorgenommen hat.
 - Die strukturelle Konformität prüft `.koolie/core/tests/scripts/validate-framework.py` (Pflichtabschnitte, Frontmatter, Platzhalter, verbotene Muster).
 
-**Reichweite dieser Konventionen.** Sie gelten für die **Skill-Ablage, die das Framework schreibt**. Skills aus Ablagen außerhalb des Repositoriums – etwa aus dem Benutzerprofil – unterliegen ihnen nicht; sie sind nach Regel 2.6 der Prioritätshierarchie ebenenlos und dürfen den Handlungsspielraum nur einschränken, nie erweitern. Der KI-Client kann sie dennoch aufrufen: Am 2026-09-11 führte eine Installation 81 Skills, 67 davon aus einer fremden Ablage und mit Aufrufbarkeit durch Mensch **und** Modell.
+**Reichweite dieser Konventionen.** Sie gelten für die Skill-Ablage, die das Framework schreibt. Skills aus Ablagen außerhalb des Repositoriums – etwa aus dem Benutzerprofil – unterliegen ihnen nicht; sie sind nach Regel 2.6 der Prioritätshierarchie ebenenlos und dürfen den Handlungsspielraum nur einschränken, nie erweitern. Der KI-Client kann sie dennoch aufrufen: Am 2026-09-11 führte eine Installation 81 Skills, 67 davon aus einer fremden Ablage und mit Aufrufbarkeit durch Mensch und Modell.
 
-Was ein solcher Skill tut, läuft durch die normalen Werkzeuge des Clients und erreicht damit Berechtigungsregeln und Schutz-Hook – gemessen im selben Lauf, einschließlich Positivkontrolle und einschließlich des Modus ohne Rückfragen. **Der Skill-Aufruf selbst ist kein Werkzeugaufruf** und damit nicht einzeln kontrollierbar; kontrolliert wird, was er auslöst. Welche fremden Ablagen ein Client führt und ob sie abschaltbar sind, steht im Abschnitt „Anweisungs- und Konfigurationsquellen außerhalb des Projekts" seines Client Packs (D-34, D-37).
+Was ein solcher Skill tut, läuft durch die normalen Werkzeuge des Clients und erreicht damit Berechtigungsregeln und Schutz-Hook – gemessen im selben Lauf, einschließlich Positivkontrolle und einschließlich des Modus ohne Rückfragen. **Der Skill-Aufruf selbst ist kein Werkzeugaufruf** und damit nicht einzeln kontrollierbar; kontrolliert wird, was er auslöst. Welche fremden Ablagen ein Client führt und ob sie abschaltbar sind, steht im Abschnitt „Anweisungs- und Konfigurationsquellen außerhalb des Projekts" seines Client Packs.
 
 ## 8. Erläuterung
 

package/.koolie/core/framework/core/09-risk-model.md

@@ -36,12 +36,12 @@
 | R9 | Einführung externer Abhängigkeiten | keine | Aktualisierung einer bestehenden Abhängigkeit (Patch/Minor) | neue Abhängigkeit oder Major-Update (Checkliste `.koolie/core/checklists/07-new-dependency.md`) |
 | R10 | Änderung von Authentifizierung oder Autorisierung | keine | keine (jede Berührung ist mindestens hoch) | jede Änderung |
 | R11 | Änderung von Datenmodellen oder Schnittstellen | keine | interne, abwärtskompatible Erweiterung | Schema-Änderung, Vertragsbruch einer Schnittstelle, Migration |
-| R12 | Automatisierungsgrad der KI-Nutzung | einzelne, überwachte Sitzung im rückfragenden Standardmodus (D-05; wie der Modus im Client heißt, nennt die Fähigkeitsmatrix des Client Packs); oder mehrere rein lesende Sitzungen beziehungsweise Subagenten (M1, M2) unter einer aufsichtführenden Person | mehrere Schritte in einer Sitzung mit sitzungsweiten Freigaben; oder parallele schreibende Sitzungen auf disjunkten Schreibzielen | Modus mit selbsttätiger Übernahme, soweit ihn eine dokumentierte Ausnahme zulässt (D-05); parallele Sitzungen auf gemeinsamen Schreibzielen; Hintergrund-Subagenten in M3 |
+| R12 | Automatisierungsgrad der KI-Nutzung | einzelne, überwachte Sitzung im rückfragenden Standardmodus (wie der Modus im Client heißt, nennt die Fähigkeitsmatrix des Client Packs); oder mehrere rein lesende Sitzungen beziehungsweise Subagenten (M1, M2) unter einer aufsichtführenden Person | mehrere Schritte in einer Sitzung mit sitzungsweiten Freigaben; oder parallele schreibende Sitzungen auf disjunkten Schreibzielen | Modus mit selbsttätiger Übernahme, soweit ihn eine dokumentierte Ausnahme zulässt; parallele Sitzungen auf gemeinsamen Schreibzielen; Hintergrund-Subagenten in M3 |
 | R13 | Mögliche Fehlerfolgen | lokal begrenzt, sofort erkennbar | Funktionsstörung in Test oder Produktion, erkennbar durch Monitoring | Datenverlust, Sicherheitsvorfall, Verstoß gegen rechtliche Vorgaben, Reputationsschaden |
 
 `<CHANGE_SIZE_THRESHOLD>` und die Liste kritischer Komponenten werden im Project Overlay festgelegt (`<TBD: Schwellenwert für Änderungsumfang>`).
 
-**Zu R12 (normativ).** Die Spalten unterscheiden nach **Schreibziel und Aufsicht**, nicht nach der Zahl der Sitzungen: rein lesende Parallelarbeit unter Aufsicht niedrig, schreibende Parallelarbeit auf getrennten Zielen mittel, gemeinsame Schreibziele hoch (D-54; die Voraussetzungen für Parallelarbeit nennt `.koolie/core/framework/core/05-working-model.md`, Abschnitt 3.1). Ein Modus mit selbsttätiger Übernahme bleibt **hoch**: Dass die erste Schutzlinie in einem erweiterten Modus ausfällt, ist gemessen (D-35), und diese Einstufung wird nicht gelockert. Der Modus ohne Rückfragen ist **keine Stufe von R12**, sondern untersagt (D-05, D-389).
+**Zu R12 (normativ).** Die Spalten unterscheiden nach **Schreibziel und Aufsicht**, nicht nach der Zahl der Sitzungen: rein lesende Parallelarbeit unter Aufsicht niedrig, schreibende Parallelarbeit auf getrennten Zielen mittel, gemeinsame Schreibziele hoch (die Voraussetzungen für Parallelarbeit nennt `.koolie/core/framework/core/05-working-model.md`, Abschnitt 3.1). Ein Modus mit selbsttätiger Übernahme bleibt **hoch**: Dass die erste Schutzlinie in einem erweiterten Modus ausfällt, ist gemessen, und diese Einstufung wird nicht gelockert. Der Modus ohne Rückfragen ist **keine Stufe von R12**, sondern untersagt.
 
 ## 3. Kontrollstufen (normativ)
 
@@ -53,7 +53,7 @@
 | Dokumentationsumfang | KI-Nutzungsvermerk im Merge Request (Kurzform, `.koolie/core/templates/MR_AI_DISCLOSURE.md`) | zusätzlich: Plan, Fundstellenliste, Ergebnisbericht mit Abweichungen und Restrisiken | zusätzlich: vollständiges Sitzungsprotokoll (Prompts, Freigaben, ausgeführte Befehle), Entscheidungsvermerk der Freigabe |
 | Eskalationskriterien | Scope-Überschreitung, unerwartete Berührung anderer Komponenten, fehlgeschlagene Quality Gates ohne klare Ursache | zusätzlich: Abweichung vom bestätigten Plan, neue Abhängigkeit, Testlücke | jede Unklarheit führt zum Stopp; Fortsetzung nur nach erneuter Freigabe |
 
-**M6 Mandated Maintenance steht außerhalb dieser Tabelle** (D-446). Er ändert keinen Code und trägt nur ein, was der Mensch entschieden hat; seine Voraussetzung ist das Mandat (`05-working-model.md`, M6), nicht die Kontrollstufe einer Aufgabe. Die Freigabe, die eine eingetragene Entscheidung braucht, richtet sich nach der Entscheidung selbst – etwa eine Architekturentscheidung der Stufe hoch nach dieser Tabelle.
+**M6 Mandated Maintenance steht außerhalb dieser Tabelle**. Er ändert keinen Code und trägt nur ein, was der Mensch entschieden hat; seine Voraussetzung ist das Mandat (`05-working-model.md`, M6), nicht die Kontrollstufe einer Aufgabe. Die Freigabe, die eine eingetragene Entscheidung braucht, richtet sich nach der Entscheidung selbst – etwa eine Architekturentscheidung der Stufe hoch nach dieser Tabelle.
 
 ## 4. Delegationsverbotsliste (normativ)
 
@@ -61,7 +61,7 @@ Folgende Aufgaben und Entscheidungen DÜRFEN NICHT an den KI-Client delegiert we
 
 | Nr. | Nicht delegierbar | Zulässige Unterstützung durch den KI-Client |
 |---|---|---|
-| V1 | Freigabe, Genehmigung oder Abnahme von Änderungen, Merge Requests, Releases | Review-Unterstützung mit Befunden (Skill `fw-review-support`) |
+| V1 | Freigabe, Genehmigung oder Abnahme von Änderungen, Merge Requests, Releases | Review-Unterstützung mit Befunden (Skill `koolie-review-support`) |
 | V2 | Merge in geschützte Branches, Tagging von Releases, Deployment in Produktion | Erstellung von Merge-Request-Beschreibungen |
 | V3 | Architekturentscheidungen, Technologieauswahl, Einführung neuer Abhängigkeiten | Optionsanalyse mit Vor- und Nachteilen, Vorschlag mit Kennzeichnung; im Modus M6 das Eintragen einer Architekturentscheidung, die der Mensch getroffen hat |
 | V4 | Umgang mit Secrets, Zugangsdaten, Zertifikaten, Schlüsselmaterial (Erzeugen, Rotieren, Eintragen, Lesen) | keine; Fundstellen vermuteter Secrets sind zu melden, nicht auszugeben |
@@ -74,9 +74,9 @@ Folgende Aufgaben und Entscheidungen DÜRFEN NICHT an den KI-Client delegiert we
 | V11 | Kommunikation nach außen (Kunden, Behörden, Öffentlichkeit) im Namen des Projekts | Entwürfe für interne Verwendung |
 | V12 | Löschen von Branches, Historie, Daten oder Artefakten außerhalb des Arbeitsbereichs | keine |
 
-**Abgrenzung zu V6 (normativ).** V6 erfasst den **Betrieb**: tatsächliche Berechtigungen sowie Betriebs-, Infrastruktur- und Sicherheitskonfigurationen – auch dann, wenn sie als Code im Repositorium liegen (Infrastrukturbeschreibungen, Berechtigungs- und Richtliniendateien, die Berechtigungsdatei dieses Frameworks), denn ihr Inhalt **ist** die Berechtigung. V6 erfasst **nicht** die lokale Anwendungslogik mit Sicherheitsbezug: Authentifizierungs- und Autorisierungsprüfungen im Quellcode, Verwendung kryptografischer Bibliotheken, Sitzungsverwaltung. Diese ist über R3 und R10 Kontrollstufe **hoch** und nach deren Freigaben umsetzbar – dokumentierte Freigabe durch `<APPROVAL_ROLE>` und `<SECURITY_CONTACT>`, Umsetzung mit begleitender Person. **Die Frage im Zweifel:** Wirkt die Änderung über Build, Review und Quality Gates des Projekts, oder ist die geänderte Datei selbst die Berechtigung eines laufenden Systems? Im zweiten Fall gilt V6. Greift daneben ein anderes Delegationsverbot – V4 für Schlüsselmaterial, V10 für die Framework-Regeln und die Berechtigungsdatei –, bleibt es unberührt (D-53).
+**Abgrenzung zu V6 (normativ).** V6 erfasst den **Betrieb**: tatsächliche Berechtigungen sowie Betriebs-, Infrastruktur- und Sicherheitskonfigurationen – auch dann, wenn sie als Code im Repositorium liegen (Infrastrukturbeschreibungen, Berechtigungs- und Richtliniendateien, die Berechtigungsdatei dieses Frameworks), denn ihr Inhalt **ist** die Berechtigung. V6 erfasst **nicht** die lokale Anwendungslogik mit Sicherheitsbezug: Authentifizierungs- und Autorisierungsprüfungen im Quellcode, Verwendung kryptografischer Bibliotheken, Sitzungsverwaltung. Diese ist über R3 und R10 Kontrollstufe **hoch** und nach deren Freigaben umsetzbar – dokumentierte Freigabe durch `<APPROVAL_ROLE>` und `<SECURITY_CONTACT>`, Umsetzung mit begleitender Person. **Die Frage im Zweifel:** Wirkt die Änderung über Build, Review und Quality Gates des Projekts, oder ist die geänderte Datei selbst die Berechtigung eines laufenden Systems? Im zweiten Fall gilt V6. Greift daneben ein anderes Delegationsverbot – V4 für Schlüsselmaterial, V10 für die Framework-Regeln und die Berechtigungsdatei –, bleibt es unberührt.
 
-**Entscheiden und Eintragen (normativ, D-446).** Nicht delegierbar ist bei V3 und V10 die **Entscheidung**. Das Eintragen einer Entscheidung, die der Mensch in der Sitzung getroffen und benannt hat, ist Ausführung: Es ist im Modus M6 mit Mandat zulässig (`05-working-model.md`, M6), und die Prüfung ist der Merge Request (V1). Was nicht entschieden ist, trägt der KI-Client nicht ein, sondern als `<TBD: …>`.
+**Entscheiden und Eintragen (normativ).** Nicht delegierbar ist bei V3 und V10 die **Entscheidung**. Das Eintragen einer Entscheidung, die der Mensch in der Sitzung getroffen und benannt hat, ist Ausführung: Es ist im Modus M6 mit Mandat zulässig (`05-working-model.md`, M6), und die Prüfung ist der Merge Request (V1). Was nicht entschieden ist, trägt der KI-Client nicht ein, sondern als `<TBD: …>`.
 
 Das Project Overlay KANN die Liste erweitern (`.koolie/project-overlay/OVERLAY.md`, Abschnitt „Ausgeschlossene Aufgaben"). Es DARF sie NICHT verkürzen.
 

package/.koolie/core/framework/core/10-error-escalation.md

@@ -11,7 +11,7 @@
 
 ## 1. Abbruchbedingungen für den KI-Client (normativ)
 
-Der KI-Client MUSS die Bearbeitung anhalten, den Zustand berichten und auf eine menschliche Entscheidung warten, wenn eine der folgenden Bedingungen eintritt. Die Kennungen S1 bis S10 bezeichnen in allen Regeldokumenten diese Abbruchbedingungen; die gleichlautenden Zeilen der Fähigkeitsmatrix eines Client Packs heißen dort stets *Zeile* S1 bis S5 (D-391).
+Der KI-Client MUSS die Bearbeitung anhalten, den Zustand berichten und auf eine menschliche Entscheidung warten, wenn eine der folgenden Bedingungen eintritt. Die Kennungen S1 bis S10 bezeichnen in allen Regeldokumenten diese Abbruchbedingungen; die gleichlautenden Zeilen der Fähigkeitsmatrix eines Client Packs heißen dort stets *Zeile* S1 bis S5.
 
 | ID | Bedingung | Meldung an |
 |---|---|---|

package/.koolie/core/framework/org-policies/MAPPING_CLASSIFICATION.md

@@ -9,7 +9,7 @@
 |---|---|---|
 | `<TBD: z. B. „öffentlich">` | K0 | `<TBD>` |
 | `<TBD: z. B. „intern">` | K1 oder K2 | `<TBD: Kriterien, wann intern eingestufte Inhalte als K1 gelten dürfen>` |
-| `<TBD: z. B. „vertraulich">` | K3 (unbedingt – Abschnitt 2.1 Nr. 7 von `.koolie/core/framework/core/02-privacy.md`; eine Lockerung ist auf keinem Weg vorgesehen, D-52) | `<TBD: welche bereinigten Ableitungen zulässig sind; sie werden als eigener Inhalt neu eingestuft>` |
+| `<TBD: z. B. „vertraulich">` | K3 (unbedingt – Abschnitt 2.1 Nr. 7 von `.koolie/core/framework/core/02-privacy.md`; eine Lockerung ist auf keinem Weg vorgesehen) | `<TBD: welche bereinigten Ableitungen zulässig sind; sie werden als eigener Inhalt neu eingestuft>` |
 | `<TBD: z. B. „streng vertraulich">` | K3 (keine Lockerung) | – |
 | personenbezogene Daten gemäß Richtlinie `<TBD: Referenz>` | K3 (Echtdaten); synthetische Testdaten K1 | `<TBD>` |
 

package/.koolie/core/framework/overlay-patterns/general.md

@@ -4,38 +4,33 @@
 |---|---|
 | ID | `FW-OVL-GENERAL` |
 | Name | `general` |
-| Version | `0.2.1` |
+| Version | `0.2.2` |
 | Status | `pilot` |
 | Owner (Rolle) | `<FRAMEWORK_OWNER>` |
-| Gewählt über | `python .koolie/core/install.py --overlay general` – **nur bei der Erstinstallation** (D-126) |
-| Wirkung | füllt drei Pfadplatzhalter einmal in Overlay, Laufzeitfassung und Berechtigungsdatei (D-355); legt sechs Musterdokumente allgemeiner Praktiken an und registriert sie im Manifest (D-359, D-360) |
+| Gewählt über | `python .koolie/core/install.py --overlay general` – **nur bei der Erstinstallation** |
+| Wirkung | füllt drei Pfadplatzhalter einmal in Overlay, Laufzeitfassung und Berechtigungsdatei; legt sechs Musterdokumente allgemeiner Praktiken an und registriert sie im Manifest |
 | Nachweis | Sonden `M355` bis `M355e` und `M359` bis `M359c` in `.koolie/core/tests/scripts/probe-pruefungen.py` |
 
 ## Zweck
 
-Ein Projekt, das das Framework übernimmt, beginnt ohne diesen Parameter mit einem
-**leeren** Overlay: Jeder Platzhalter ist ein Schlitz, und bis ein Mensch ihn füllt,
-sperrt die Berechtigungsdatei an seiner Stelle nichts. Dieses Muster füllt die Schlitze,
-deren Wert sich **ohne Kenntnis des Projekts** sicher angeben lässt – und nur diese.
+Ohne Muster beginnt ein Projekt mit einem leeren Overlay: Jeder Platzhalter ist ein Schlitz,
+und solange er offen ist, sperrt die Berechtigungsdatei an seiner Stelle nichts. Dieses Muster
+füllt die Schlitze, deren Wert sich ohne Kenntnis des Projekts sicher angeben lässt – und nur
+diese.
 
-Seit Version `0.2.0` liefert es außerdem **Dokumente**: allgemein anerkannte Praktiken
-der Softwareentwicklung für die Bereiche des Overlays, die auf **jedes** Projekt passen
-(Abschnitt *„Die Dokumente“*). Sie sind ein zweiter Gegenstand mit eigener Grenze.
+Außerdem liefert es Dokumente mit allgemein anerkannten Praktiken der Softwareentwicklung, die
+auf jedes Projekt passen (Abschnitt *„Die Dokumente“*).
 
 ## Der Grundsatz: Das Muster sperrt, es gibt nichts frei
 
-🔴 **Ein mitgeliefertes Muster schlägt Projektwerte vor, und der Kern darf keine
-enthalten** (Entscheidungsbaum 6, Prüfungen 6 und 14). Die Grenze ist deshalb keine
-Auswahl nach Geschmack, sondern eine Richtung: **Jeder Wert dieses Musters verschärft.**
-Er steht ausschließlich in einem `deny`-Eintrag; ein Wert, der auf ein Projekt nicht
-passt, sperrt eine Datei, die es dort nicht gibt, und kostet nichts.
+Der Kern darf keine Projektwerte enthalten (Entscheidungsbaum 6, Prüfungen 6 und 14). Deshalb
+**verschärft jeder Wert dieses Musters**: Er steht ausschließlich in einem `deny`-Eintrag. Passt
+ein Wert nicht, sperrt er eine Datei, die es im Projekt nicht gibt, und kostet nichts.
 
-➡️ **Nicht gefüllt wird deshalb alles, was etwas FREIGIBT oder das Projekt BESCHREIBT:**
-`<ALLOWED_PATHS>`, `<TEST_PATHS>`, `<DOC_PATHS>`, `<READ_ONLY_PATHS>`, die drei
-Befehlsschlitze, Rollen, Status, Freigaben und die Ergebnisse der Datenschutz- und
-Vertragsprüfung. `install.py` nimmt aus dieser Datei **nur** die drei Platzhalter der
-Tabelle unten an und bricht ab, wenn sie einen anderen führt – die Grenze steht im
-Werkzeug, nicht nur in diesem Satz.
+Nicht gefüllt wird alles, was etwas freigibt oder das Projekt beschreibt: `<ALLOWED_PATHS>`,
+`<TEST_PATHS>`, `<DOC_PATHS>`, `<READ_ONLY_PATHS>`, die drei Befehlsschlitze, Rollen, Status,
+Freigaben und die Ergebnisse der Datenschutz- und Vertragsprüfung. `install.py` nimmt aus dieser
+Datei nur die drei Platzhalter der Tabelle unten an und bricht bei jedem anderen ab.
 
 ## Die Werte
 
@@ -44,52 +39,47 @@ Jeder Wert steht in einer eigenen Codespanne.
 
 | Platzhalter | Werte | Warum ohne Kenntnis des Projekts sicher |
 |---|---|---|
-| `<CI_CONFIG_PATHS>` | `.github/workflows/**`, `.gitlab-ci.yml`, `.gitea/workflows/**`, `Jenkinsfile`, `azure-pipelines.yml`, `bitbucket-pipelines.yml`, `.circleci/**` | Die üblichen Ablagen der verbreiteten CI-Werkzeugklassen. Gesperrt wird nur das **Schreiben**; eine Merge-Request-Vorlage neben `.github/workflows/` bleibt lesbar (D-161) |
-| `<QUALITY_GATE_CONFIG_PATHS>` | `.editorconfig`, `.eslintrc*`, `eslint.config.*`, `.prettierrc*`, `.stylelintrc*`, `sonar-project.properties`, `codecov.yml`, `.codecov.yml`, `.coveragerc`, `.pylintrc`, `.flake8`, `ruff.toml`, `.golangci.yml`, `checkstyle.xml` | Eigenständige Konfigurationsdateien von Linter, Formatierer, Analyse und Abdeckung – Schwellenwerte ändert der KI-Client nie (`OVERLAY.md` Abschnitt 7). ⚠️ **Bewusst nicht:** Sammeldateien wie `pyproject.toml` oder `package.json`, die neben der Prüfkonfiguration auch Abhängigkeiten tragen – sie zu sperren, wäre eine Aussage über das Projekt |
-| `<EXCLUDED_PATHS>` | `**/*.tfstate`, `**/*.tfstate.*`, `**/*.dump` | Zustandsdateien einer Infrastrukturbeschreibung tragen Zugangsdaten im Klartext, Datenbankabzüge echte Daten (K3). ⚠️ **Bewusst nicht:** `deploy/**`, `infra/**` oder `config/prod/**` aus dem Beispiel der Vorlage – sie setzen ein Verzeichnislayout voraus, und eine Lesesperre auf ein Verzeichnis, in dem das Projekt arbeitet, ist keine Verschärfung, sondern ein Hindernis |
+| `<CI_CONFIG_PATHS>` | `.github/workflows/**`, `.gitlab-ci.yml`, `.gitea/workflows/**`, `Jenkinsfile`, `azure-pipelines.yml`, `bitbucket-pipelines.yml`, `.circleci/**` | Die üblichen Ablagen der verbreiteten CI-Werkzeugklassen. Gesperrt wird nur das Schreiben; eine Merge-Request-Vorlage neben `.github/workflows/` bleibt lesbar |
+| `<QUALITY_GATE_CONFIG_PATHS>` | `.editorconfig`, `.eslintrc*`, `eslint.config.*`, `.prettierrc*`, `.stylelintrc*`, `sonar-project.properties`, `codecov.yml`, `.codecov.yml`, `.coveragerc`, `.pylintrc`, `.flake8`, `ruff.toml`, `.golangci.yml`, `checkstyle.xml` | Eigenständige Konfigurationsdateien von Linter, Formatierer, Analyse und Abdeckung – Schwellenwerte ändert der KI-Client nie (`OVERLAY.md` Abschnitt 7). Nicht enthalten sind Sammeldateien wie `pyproject.toml` oder `package.json`, die auch Abhängigkeiten tragen; sie zu sperren, wäre eine Aussage über das Projekt |
+| `<EXCLUDED_PATHS>` | `**/*.tfstate`, `**/*.tfstate.*`, `**/*.dump` | Zustandsdateien einer Infrastrukturbeschreibung tragen Zugangsdaten im Klartext, Datenbankabzüge echte Daten (K3). Nicht enthalten sind `deploy/**`, `infra/**` oder `config/prod/**` aus dem Beispiel der Vorlage: Sie setzen ein Verzeichnislayout voraus, und eine Lesesperre auf ein Arbeitsverzeichnis wäre ein Hindernis, keine Verschärfung |
 
 ## Wie die Werte in das Projekt kommen
 
-`install.py --overlay general` schreibt bei der Erstinstallation **drei** Träger aus dieser
-Tabelle, und zwar genau einmal (D-353, D-355):
+`install.py --overlay general` schreibt bei der Erstinstallation drei Träger aus dieser
+Tabelle, und zwar genau einmal:
 
 | Träger | Was gefüllt wird |
 |---|---|
 | `.koolie/project-overlay/OVERLAY.md` | die Spalte **Wert** der drei Zeilen in Abschnitt 4; ein Eintrag im Änderungsverlauf nennt Muster und Version |
 | `<RULES_DIR>/20-project-overlay.md` | der Wert hinter `<EXCLUDED_PATHS>` – die beiden anderen Platzhalter führt die Laufzeitfassung nicht |
-| `<PERMISSIONS_FILE>` | jeder `deny`-Eintrag der Kernquelle, der einen der drei Platzhalter trägt, wird zu einem Eintrag je Wert – **dieselben Schlitze, keiner mehr** |
+| `<PERMISSIONS_FILE>` | jeder `deny`-Eintrag der Kernquelle, der einen der drei Platzhalter trägt, wird zu einem Eintrag je Wert – dieselben Schlitze, keiner mehr |
 
-⚠️ **Abgrenzung zu D-76.** Gelesen wird ein Träger des Kerns, nicht des Projekts, und
-zugesagt ist der **Anfangszustand**, kein Kanal. Danach gehören alle drei Dateien dem
-Projekt wie ohne Muster; `install.py --update` liest dieses Muster nie wieder. Ein
-Projekt, das einen Wert später ändert, zieht ihn wie jeden anderen Wert von Hand nach –
-**und Prüfung 59 findet die Abweichung für `<EXCLUDED_PATHS>`.**
+Das Muster liefert nur den Anfangszustand. Danach gehören alle drei Dateien dem Projekt;
+`install.py --update` liest das Muster nie wieder. Wer einen Wert später ändert, zieht ihn in
+allen Trägern von Hand nach; Prüfung 59 meldet eine Abweichung bei `<EXCLUDED_PATHS>`.
 
-⚠️ **Bei einem Client Pack, dessen Berechtigungsschicht keine Musterform kennt**
-(`openai-codex`, B3 und B5 `[NICHT ABBILDBAR]`), kommt nur ein Teil an – gemessen an
-einer Wegwerf-Installation: Ein Teilbaum (`.github/workflows/**`) und ein einzelner
-Dateiname (`Jenkinsfile`) werden zu einem Pfad mit Zugriffsart `read`, ein Namensmuster
-mit `*` (`**/*.tfstate`, `.eslintrc*`) erreicht die Datei nicht. Das Muster ändert daran
-nichts, und das Pack sagt es in Abschnitt 5 selbst.
+Bei `openai-codex` (B3 und B5 `[NICHT ABBILDBAR]`) kennt die Berechtigungsschicht keine
+Musterform, und nur ein Teil kommt an: Ein Teilbaum (`.github/workflows/**`) und ein einzelner
+Dateiname (`Jenkinsfile`) werden zu einem Pfad mit Zugriffsart `read`, ein Namensmuster mit `*`
+(`**/*.tfstate`, `.eslintrc*`) erreicht die Datei nicht. Das Pack nennt diese Grenze in
+Abschnitt 5.
 
 ## Die Dokumente
 
-🔴 **Die Regel „sperrt, gibt nichts frei“ gilt für Schlitzwerte, und Dokumente sind ein
-zweiter Gegenstand mit eigener Grenze** (D-359). Ein Dokument gibt nichts frei, aber es
-**beschreibt** – und darf deshalb nur beschreiben, was für jedes Projekt gilt:
+Ein Dokument gibt nichts frei, aber es beschreibt. Deshalb darf es nur beschreiben, was für
+jedes Projekt gilt:
 
-- **nur allgemein anerkannte, werkzeug- und sprachneutrale Praktiken;**
-- **keine Schwellenwerte** (Abdeckung, Methodenlänge, Anzahl Reviewer), **keine
-  Werkzeugnamen**, **keine Vorgaben, die Vorgehensmodell, Teamgröße oder Plattform
-  voraussetzen;**
-- **keine Wiederholung des Kerns.** Was der Kern für KI-unterstützte Arbeit schon regelt
-  – `04-quality.md` Abschnitte 2 und 3, `07-review-rules.md`, die Checklisten 03, 05, 06,
-  07 und 08 –, wird verwiesen, nicht abgeschrieben. Jedes Dokument sagt in einem Abschnitt
-  *„Verhältnis zum Framework“*, wo die Grenze liegt; bei Widerspruch gilt der Kern.
+- nur allgemein anerkannte, werkzeug- und sprachneutrale Praktiken;
+- keine Schwellenwerte (Abdeckung, Methodenlänge, Anzahl Reviewer), keine Werkzeugnamen, keine
+  Vorgaben, die Vorgehensmodell, Teamgröße oder Plattform voraussetzen;
+- keine Wiederholung des Kerns. Was der Kern für KI-unterstützte Arbeit regelt –
+  `04-quality.md` Abschnitte 2 und 3, `07-review-rules.md`, die Checklisten 03, 05, 06, 07 und
+  08 –, wird verwiesen. Jedes Dokument sagt im Abschnitt *„Verhältnis zum Framework“*, wo die
+  Grenze liegt; bei Widerspruch gilt der Kern.
 
-➡️ **Was davon nicht überall passt, kommt nicht hinein** – auch nicht als Beispiel. Die
-Stelle für Projektfestlegungen ist der Abschnitt *„Projektspezifische Ergänzungen“* am
-Ende jedes Dokuments und die zugehörige Zeile in `OVERLAY.md`.
+Was nicht überall passt, kommt nicht hinein, auch nicht als Beispiel. Projektfestlegungen
+gehören in den Abschnitt *„Projektspezifische Ergänzungen“* am Ende jedes Dokuments und in die
+zugehörige Zeile in `OVERLAY.md`.
 
 Diese Tabelle beschreibt die Ablage unter `overlay-patterns/general/documents/<typ>/`;
 `install.py` hält ihre erste Spalte gegen die Verzeichnisse und bricht ab, wenn beide
@@ -104,15 +94,15 @@ auseinanderlaufen.
 | `security` | Sicherheit als Anforderung, minimale Rechte, gestaffelte Abwehr, sicher scheitern, sichere Voreinstellungen, Geheimnisse, Pflege der Abhängigkeiten | Verfahren, Bibliotheken, Schutzkonfiguration (K3); die Prüfpunkte aus Checkliste 06 und 07 |
 | `branching-strategy` | Standard-Branch baubar, kurzlebige Branches, Integration über Merge Request, schlüssige Commits, gemeinsame Historie nicht umschreiben | ein Branching-Modell, Namensschema, Commit-Konvention (`OVERLAY.md` Abschnitt 10) |
 
-**Nicht mitgeliefert** werden `architecture`, `roadmap`, `deployment`, `roles` und
-`glossary` – sie beschreiben das Projekt – sowie `ai-governance` und `ai-process-model`,
-die der Kern selbst trägt.
+Nicht mitgeliefert werden `architecture`, `roadmap`, `deployment`, `roles` und `glossary` – sie
+beschreiben das Projekt – sowie `ai-governance` und `ai-process-model`, die der Kern selbst
+trägt.
 
 ### Wie die Dokumente in das Projekt kommen
 
 `install.py --overlay general` schreibt sie bei der Erstinstallation nach
-`.koolie/project-overlay/documents/<typ>/muster-general.md` und **ersetzt** die drei
-Beispieleinträge der Manifestvorlage durch einen Eintrag je Dokument (D-360):
+`.koolie/project-overlay/documents/<typ>/muster-general.md` und ersetzt die drei
+Beispieleinträge der Manifestvorlage durch einen Eintrag je Dokument:
 
 | Feld | Wert | Warum |
 |---|---|---|
@@ -121,30 +111,28 @@ Beispieleinträge der Manifestvorlage durch einen Eintrag je Dokument (D-360):
 | `load` | `on-demand` | kein weiterer Träger je Client Pack; `summary` und `rule` wählt der Overlay Owner |
 | `approved_by`, `approved_on` | Ausfüllschlitze | die Freigabe erteilt ein Mensch |
 
-🔴 **Die Dokumente wirken erst, wenn der Overlay Owner sie freigibt.** Die Liste der
-freigegebenen K1-Dokumente in der Laufzeitfassung bleibt ein Ausfüllschlitz, und einen
-offenen Wert behandelt der KI-Client als nicht freigegeben. ⚠️ **Preis, benannt:** Bis
-dahin haben sie keine Wirkung auf den Client – sie sind ein Anfang für Menschen. Das ist
-die Richtung von D-355 an einem Gegenstand, der beschreibt statt sperrt: Ein ungeprüfter
-Text wird nicht verbindlich, nur weil er mitgeliefert wurde.
+**Die Dokumente wirken erst, wenn der Overlay Owner sie freigibt.** Die Liste der freigegebenen
+K1-Dokumente in der Laufzeitfassung bleibt ein Ausfüllschlitz, und einen offenen Wert behandelt
+der KI-Client als nicht freigegeben. Bis dahin sind die Dokumente ein Anfang für Menschen; ein
+ungeprüfter Text wird nicht verbindlich, nur weil er mitgeliefert wurde.
 
-⚠️ **Kein weiterer Platzhalter wird gefüllt**, auch nicht `<PROJECT_RULES_PATH>` oder die
-Pfade der projektweiten DoR und DoD in `OVERLAY.md` Abschnitt 11 und 12 – sie zu setzen,
-hieße, die Dokumente für das Projekt zu erklären. **Bestandsprojekte** erreicht das Muster
-nicht (D-126); sie übernehmen einzelne Dokumente von Hand
-(`.koolie/core/docs/ADOPTION_GUIDE.md` Abschnitt 3).
+Kein weiterer Platzhalter wird gefüllt, auch nicht `<PROJECT_RULES_PATH>` oder die Pfade der
+projektweiten DoR und DoD in `OVERLAY.md` Abschnitt 11 und 12 – das hieße, die Dokumente für
+das Projekt zu erklären. Bestandsprojekte erreicht das Muster nicht; sie übernehmen einzelne
+Dokumente von Hand (`.koolie/core/docs/ADOPTION_GUIDE.md` Abschnitt 3).
 
 ## Die Grenze zur Aktivierungsreife
 
-🔴 **Ein Overlay aus diesem Muster ist nicht aktivierungsreif, und das ist gewollt**
-(D-57). Es lässt die Pflichtwerte der Abschnitte 1, 5, 6, 13, 14 und 15 offen; ein Overlay,
-das die Prüfung `--check-overlay-ready` von selbst bestünde, wäre ein aktivierungsreifer
-Zustand, den niemand geprüft hat. **Die Sonde `M355b` hält fest, dass eine frische
-Installation mit diesem Muster die Prüfung nicht besteht.**
+Ein Overlay aus diesem Muster ist nicht aktivierungsreif, und das ist gewollt. Es lässt die
+Pflichtwerte der Abschnitte 1, 5, 6, 13, 14 und 15 offen; ein Overlay, das
+`--check-overlay-ready` von selbst bestünde, wäre aktivierungsreif, ohne dass jemand es geprüft
+hat. Die Sonde `M355b` hält fest, dass eine frische Installation mit diesem Muster die Prüfung
+nicht besteht.
 
 ## Änderungsverlauf
 
 | Version | Datum | Änderung |
 |---|---|---|
-| `0.2.0` | 2026-09-25 | Sechs Musterdokumente allgemeiner Praktiken, im Manifest als `entwurf` registriert; Framework-Release `1.6.0` (`CR-2026-139`, D-359, D-360) |
-| `0.1.0` | 2026-09-25 | Erstfassung mit Framework-Release `1.5.0` (`CR-2026-138`, D-355) |
+| `0.2.2` | 2026-10-02 | Sprachlich überarbeitet; Werte und Dokumente unverändert |
+| `0.2.0` | 2026-09-25 | Sechs Musterdokumente allgemeiner Praktiken, im Manifest als `entwurf` registriert; Framework-Release `1.6.0` |
+| `0.1.0` | 2026-09-25 | Erstfassung mit Framework-Release `1.5.0` |