@renoxar/koolie 1.25.0 → 2.0.0

package/.koolie/core/build/doc/09-betriebsmodi.md

@@ -4,15 +4,15 @@ Jede KI-Aufgabe läuft in genau einem von sechs Betriebsmodi; der Modus wird im
 
 | Modus | Zweck in einem Satz | Schreiben | Befehle | Typische Skills |
 |---|---|---|---|---|
-| **M1 Read-only Analysis** | Verstehen, prüfen, erklären – Befunde nur mit Fundstellen | nein | keine (bei Review-Unterstützung: nur lesende Git-Befehle) | `fw-repo-analyze`, `fw-code-explain`, `fw-change-analyze`, `fw-error-analyze`, `fw-review-support` |
-| **M2 Guided Planning** | prüfbaren Änderungsplan erarbeiten – mit Halte-Punkt vor jeder Umsetzung | nur Plan-Datei außerhalb des Quellcodes | nein | `fw-plan`, `fw-bugfix-prepare` |
-| **M3 Controlled Modification** | freigegebene Änderung in kleinen, berichteten Schritten umsetzen | nur im freigegebenen Scope | nur freigegebene Build-/Test-/Lint-Befehle | `fw-change-small`, `fw-refactor` |
-| **M4 Test and Validation** | Tests erstellen und ausführen, Aussagekraft bewerten | nur `<TEST_PATHS>` | nur freigegebene Testbefehle | `fw-tests` |
-| **M5 Documentation Support** | Dokumentation aus dem belegten Code-Stand pflegen | nur `<DOC_PATHS>` | nur lesende Git-Befehle | `fw-docs-update`, `fw-mr-description` |
-| **M6 Mandated Maintenance** | Entscheidungen des Menschen direkt in Overlay und Projektdokumentation eintragen – bei der Einrichtung, nach einem Framework-Update, im laufenden Projekt | Overlay im Umfang des Mandats, `<DOC_PATHS>` | lesende Git-Befehle, Prüfbefehle des Frameworks | `fw-overlay-pflege` |
+| **M1 Read-only Analysis** | Verstehen, prüfen, erklären – Befunde nur mit Fundstellen | nein | keine (bei Review-Unterstützung: nur lesende Git-Befehle) | `koolie-repo-analyze`, `koolie-code-explain`, `koolie-change-analyze`, `koolie-error-analyze`, `koolie-review-support` |
+| **M2 Guided Planning** | prüfbaren Änderungsplan erarbeiten – mit Halte-Punkt vor jeder Umsetzung | nur Plan-Datei außerhalb des Quellcodes | nein | `koolie-plan`, `koolie-bugfix-prepare` |
+| **M3 Controlled Modification** | freigegebene Änderung in kleinen, berichteten Schritten umsetzen | nur im freigegebenen Scope | nur freigegebene Build-/Test-/Lint-Befehle | `koolie-change-small`, `koolie-refactor` |
+| **M4 Test and Validation** | Tests erstellen und ausführen, Aussagekraft bewerten | nur `<TEST_PATHS>` | nur freigegebene Testbefehle | `koolie-tests` |
+| **M5 Documentation Support** | Dokumentation aus dem belegten Code-Stand pflegen | nur `<DOC_PATHS>` | nur lesende Git-Befehle | `koolie-docs-update`, `koolie-mr-description` |
+| **M6 Mandated Maintenance** | Entscheidungen des Menschen direkt in Overlay und Projektdokumentation eintragen – bei der Einrichtung, nach einem Framework-Update, im laufenden Projekt | Overlay im Umfang des Mandats, `<DOC_PATHS>` | lesende Git-Befehle, Prüfbefehle des Frameworks | `koolie-overlay-pflege` |
 
-**Das Mandat (seit 1.17.0).** Entscheiden bleibt beim Menschen; das Eintragen darf der Assistent übernehmen, statt eine Vorlage zum Abschreiben zu liefern. Der Mensch erteilt dafür im eigenen Terminal ein befristetes Mandat (`python .koolie/core/mandat.py erteilen --rolle Architekt --umfang overlay --minuten 60`). Der Schutz-Hook sperrt das Overlay, solange kein Mandat es deckt, und sperrt das Mandat selbst für jede Operation des Assistenten – er kann es sich nicht selbst geben. Geprüft wird im Merge Request. `mandat.py beenden` gleicht danach Status, Version und Pfadlisten in die immer geladene Laufzeitfassung ab. Jede Sperre erklärt sich in vier Zeilen – gesperrt, warum, Lösung mit Befehl, Folge –, damit niemand nachfragen muss.
+**Das Mandat.** Entscheiden bleibt beim Menschen; das Eintragen darf der Assistent übernehmen, statt eine Vorlage zum Abschreiben zu liefern. Der Mensch erteilt dafür im eigenen Terminal ein befristetes Mandat (`python .koolie/core/mandat.py erteilen --rolle Architekt --umfang overlay --minuten 60`). Der Schutz-Hook sperrt das Overlay, solange kein Mandat es deckt, und sperrt das Mandat selbst für jede Operation des Assistenten – er kann es sich nicht selbst geben. Geprüft wird im Merge Request. `mandat.py beenden` gleicht danach Status, Version und Pfadlisten in die immer geladene Laufzeitfassung ab. Jede Sperre erklärt sich in vier Zeilen: gesperrt, warum, Lösung mit Befehl, Folge.
 
 Jeder Modus ist im Modul FW-CORE-05 (vollständig in Kapitel 10 wiedergegeben) mit denselben sieben Merkmalen normiert: Zweck, zulässige Aktionen, verbotene Aktionen, benötigter Kontext, Prüfpflichten, Abbruchkriterien, erwartete Ausgabe – ergänzt um die konkrete Umsetzung beim Client Pack `devin-desktop` mit Belegstatus (Plan-Modus `[DOK]`, Skill-`allowed-tools` und -`permissions` `[DOK]`, Permission-Modus Normal `[DOK]`, Hook-Absicherung `[EMPF]`). Die Zulässigkeit je Kontrollstufe regelt Kapitel 13: Ab Stufe mittel setzt M3 einen bestätigten Plan voraus, ab Stufe hoch eine dokumentierte Freigabe mit begleitender Person; M4 bleibt auf Stufe hoch auf testseitige Artefakte beschränkt.
 
-Bewusste Festlegungen: Der rückfragende Permission-Modus (bei `devin-desktop`: **Normal**) ist Standard für alle Modi; **Bypass** ist untersagt und **Smart**/**Accept Edits** sind nur über dokumentierte Ausnahme für Stufe niedrig zulässig (D-05). Hintergrund-Subagenten sind für M3 untersagt; für M1 ist das nur lesende Profil zulässig. Parallele Agentensitzungen (Agent Command Center `[DOK]`) sind auf unabhängige Aufgaben der Stufe niedrig begrenzt.
+Festlegungen: Der rückfragende Permission-Modus (bei `devin-desktop`: Normal) ist Standard für alle Modi; Bypass ist untersagt, Smart und Accept Edits sind nur über eine dokumentierte Ausnahme für Stufe niedrig zulässig. Hintergrund-Subagenten sind für M3 untersagt; für M1 ist das nur lesende Profil zulässig. Parallele Agentensitzungen (Agent Command Center `[DOK]`) sind auf unabhängige Aufgaben der Stufe niedrig begrenzt.

package/.koolie/core/build/doc/15-referenzstruktur.md

@@ -2,20 +2,36 @@
 
 ## 15.1 Belegstatus und Durchsetzungstiefe
 
-Für die Struktur wurden keine Client-Konventionen erfunden. Jede verwendete Konvention trägt einen **Belegstatus** – **offiziell dokumentiert** `[DOK]`, **technisch begründete Empfehlung** `[EMPF]` (aus dokumentierten Mechanismen abgeleitet, noch nicht in einer Installation ausgeführt), **konzeptioneller Vorschlag** `[KONZ]` (Framework-Konvention ohne Produktbezug) oder **noch nicht belegt** (`BELEG OFFEN`, mit Grund und Datum).
+Die Struktur erfindet keine Client-Konventionen. Jede verwendete Konvention trägt einen **Belegstatus**:
 
-Die Zuordnung von Mechanismen zu Dateinamen ist keine Eigenschaft des Frameworks, sondern eine des jeweiligen Client Packs (Kap. 7a) – dort wird sie geführt, versioniert und maschinenlesbar gehalten. Dieses Kapitel bettet sie ein, statt sie ein zweites Mal aufzuschreiben.
+| Status | Bedeutung |
+|---|---|
+| `[DOK]` | offiziell dokumentiert |
+| `[EMPF]` | technisch begründete Empfehlung – aus dokumentierten Mechanismen abgeleitet, noch nicht in einer Installation ausgeführt |
+| `[KONZ]` | konzeptioneller Vorschlag – Framework-Konvention ohne Produktbezug |
+| `BELEG OFFEN` | noch nicht belegt, mit Grund und Datum |
 
-Der Belegstatus beantwortet die Frage „ist das dokumentiert?“. Die **Fähigkeitsmatrix** beantwortet die zweite, wichtigere: „setzt der Client es durch?“ Beide zusammen ergeben die Durchsetzungstiefe einer Zusage. Für das Client Pack, das dieses Dokument als durchgehendes Beispiel verwendet:
+Welcher Mechanismus in welcher Datei steht, ist eine Eigenschaft des Client Packs (Kap. 7a), nicht des Frameworks. Das Pack führt die Zuordnung versioniert und maschinenlesbar; dieses Kapitel bettet sie ein.
+
+Der Belegstatus beantwortet die Frage „ist das dokumentiert?“. Die **Fähigkeitsmatrix** beantwortet die wichtigere: „setzt der Client es durch?“ Beide zusammen ergeben die Durchsetzungstiefe einer Zusage. Für das Client Pack, das dieses Dokument als durchgehendes Beispiel verwendet:
 
 {{EMBED-RAW:.koolie/core/clients/devin-desktop/CLIENT_PACK.md:1}}
-**Die Spalte „Einstufung“ nennt die vorgesehene Durchsetzungstiefe, die Spalte „Beleg“ ihren Nachweisstand** – beide stehen je Zeile, und das ist der Punkt: Ein Gesamturteil über eine Matrix gibt es nicht. Für dieses Pack ist Roadmap-AP2 abgeschlossen; welche Zeilen an einer laufenden Installation beobachtet sind, sagt die Belegspalte, und genau eine sagt noch `BELEG OFFEN` – dauerhaft, weil von außen nicht beobachtbar, was ein Client indexiert. **Zwei der Messungen sind zum Schlechteren ausgegangen**, haben also die zuvor vorgesehene Einstufung widerlegt; das steht in den betreffenden Zeilen und ist nicht eingeebnet worden.
+Die Spalte „Einstufung“ nennt die vorgesehene Durchsetzungstiefe, die Spalte „Beleg“ ihren Nachweisstand. Beide stehen je Zeile; ein Gesamturteil über eine Matrix gibt es nicht. Welche Zeilen an einer laufenden Installation beobachtet sind, sagt die Belegspalte. Bei diesem Pack sagt genau eine Zeile `BELEG OFFEN`, und zwar dauerhaft: Was ein Client indexiert, ist von außen nicht beobachtbar. Wo eine Messung die vorgesehene Einstufung widerlegt hat, steht das in der betreffenden Zeile.
 
 ## 15.2 Repository-Struktur
 
-Der gesamte unveränderliche Kern liegt in **einem** Verzeichnis: `.koolie/core/`. Im Wurzelverzeichnis des Projekts stehen nur die Dinge, die dort stehen müssen: die Wurzel-Anweisungsdatei und die Laufzeitschicht, weil der KI-Client sie ausschließlich dort findet, sowie `.koolie/project-overlay/` als austauschbare Projektkonfiguration. Wie diese Bestandteile heißen, entscheidet das gewählte Client Pack. **Der Baum unten nennt sie deshalb mit ihren Platzhaltern** (D-310) – so gilt er für alle ausgelieferten Packs; Anhang 31.2 löst jeden davon je Pack auf.
+Der gesamte unveränderliche Kern liegt in **einem** Verzeichnis: `.koolie/core/`. Im Wurzelverzeichnis des Projekts steht nur, was dort stehen muss: die Wurzel-Anweisungsdatei und die Laufzeitschicht, weil der KI-Client sie nur dort findet, und `.koolie/project-overlay/` als austauschbare Projektkonfiguration. Wie diese Bestandteile heißen, entscheidet das Client Pack. Der Baum unten nennt sie deshalb mit Platzhaltern und gilt so für alle ausgelieferten Packs; Anhang 31.2 löst jeden Platzhalter je Pack auf.
+
+Angelegt und aktualisiert werden die Wurzelbestandteile durch `.koolie/core/install.py` (Kap. 28):
+
+| Aufruf | Wirkung |
+|---|---|
+| `install.py --target <projekt>` | kopiert nur `.koolie/core/`, nie ganz `.koolie/`, und installiert dann mit dem kopierten Skript. Unter Windows prüft es vorher, ob ein Pfad im Zielprojekt die Längengrenze überschreitet, und kopiert dann nichts |
+| `install.cmd` (Windows), `install.command` (macOS) | Starter in der Wurzel des Release-Archivs; sie fragen Projektverzeichnis, Client Pack und Overlay-Muster ab |
+| `--lieferumfang voll` \| `nutzung` | der ganze Kern oder der Kern ohne die Nachweisschicht (Änderungsanträge, Abnahmeprotokolle, Erhebungen, `build/`). Die Wahl steht in `.koolie/core/LIEFERUMFANG` und gilt beim Heben weiter |
+| `--overlay general` | legt bei der Erstinstallation statt des leeren Overlays das Overlay-Muster *General Development* an |
 
-Angelegt und aktualisiert werden die Wurzelbestandteile durch `.koolie/core/install.py`. Damit ist die Übernahme in ein Projekt das Kopieren eines Ordners und ein Skriptaufruf (Kap. 28). `install.py --target <projekt>` erledigt beides in einem Schritt: Es kopiert **nur** `.koolie/core/`, nie ganz `.koolie/` (D-354), und installiert danach mit dem kopierten Skript. Zwei Starter in der Wurzel des Release-Archivs, `install.cmd` für Windows und `install.command` für macOS, fragen die Angaben dafür ab – Projektverzeichnis, Client Pack, Overlay-Muster (D-362). Voraussetzung auf dem Zielrechner ist Python ab 3.8 (D-363). Unter Windows prüft `--target` vor der ersten Kopie, ob ein Pfad im Zielprojekt die Längengrenze reißt, und kopiert dann nichts (D-368). `--lieferumfang` wählt zwischen dem ganzen Kern (`voll`) und dem Kern ohne die Nachweisschicht aus Änderungsanträgen, Abnahmeprotokollen, Erhebungen und `build/` (`nutzung`); die Wahl steht im Projekt in `.koolie/core/LIEFERUMFANG` und gilt beim Heben weiter (D-367). `--overlay general` legt bei der Erstinstallation statt des leeren Overlays das Overlay-Muster *General Development* an (D-355).
+Voraussetzung auf dem Zielrechner ist Python ab 3.8.
 
 ```text
 <REPOSITORY_NAME>/                       # Projekt-Repository
@@ -25,45 +41,51 @@ Angelegt und aktualisiert werden die Wurzelbestandteile durch `.koolie/core/inst
 ├── <MCP_FILE>.example                   # MCP-Vorlage (Standard: keine Server), wo das
 │                                        #   Pack eine eigene MCP-Datei hat
 ├── .gitignore                           # gehört dem Projekt; install.py meldet, welche
-│                                        #   Kerndateien es ignoriert (D-349)
+│                                        #   Kerndateien es ignoriert
 ├── <RUNTIME_DIR>/                       # LAUFZEITSCHICHT – vollständig erzeugt
 │   ├── README.md                        # Mechanismen, Modi, Sitzungsfreigaben
 │   ├── rules/                           # 00/10/15 Core-Kurzfassungen · 20 Overlay
 │   │                                    # · 2N Overlay-Erweiterungen · 30 Role Packs
 │   │                                    # · 40 Technology Packs · Vorlagen
 │   │                                    # · je nach Pack eine Befehlsregeldatei
-│   ├── skills/                          # fw-*: 12 Referenz-Skills · role-*/tech-*:
-│   │                                    #   aktivierte Packs · prj-*: projekteigene
-│   ├── agents/fw-reviewer.md            # nur lesendes Review-Subagentenprofil
+│   ├── skills/                          # koolie-*: Referenz-Skills und Skills
+│   │                                    #   aktivierter Packs · prj-*: projekteigene
+│   ├── agents/koolie-reviewer.md        # nur lesendes Review-Subagentenprofil
 │   ├── <PERMISSIONS_FILE>               # Berechtigungen deny/ask/allow; im JSON-Format
 │   │                                    #   mit Integritätsblock
 │   └── <HOOKS_FILE>                     # Hook-Konfiguration – je nach Pack dieselbe
-│                                        #   Datei wie <PERMISSIONS_FILE> (D-32, siehe unten)
+│                                        #   Datei wie <PERMISSIONS_FILE> (siehe unten)
 │
 ├── .koolie/                             # ein Verzeichnis für Kern und Projektkonfiguration
 │   ├── core/                            # DER KERN – byte-gleich zum Release
 │   │                                    # (bei `nutzung` ohne die mit † markierten Ablagen)
 │   │   ├── install.py                   # legt die Wurzelbestandteile an (--update / --check / --target)
-│   │   ├── install_dialog.py            # Dialog hinter den Startern des Archivs (D-362)
+│   │   ├── install_dialog.py            # Dialog hinter den Startern des Archivs
+│   │   ├── banner.py                    # Banner der Installation
 │   │   ├── clientmap.py                 # Semantikabbildung Berechtigungen und Hooks (Kap. 7a)
+│   │   ├── koexistenz.py                # erkennt fremde Agenten-Rahmenwerke im Projekt
+│   │   ├── mandat.py                    # Mandat und Modusbindung (M2–M6)
+│   │   ├── wirksamkeit.py               # Wirksamkeitsprobe (install.py --probe)
 │   │   ├── VERSION · CHANGELOG.md       # Versionsstand, Änderungsverzeichnis
 │   │   ├── LICENSE · LICENSE-HINWEIS.md # Lizenz und Hinweis dazu
-│   │   ├── LIEFERUMFANG                 # nur im Projekt: voll | nutzung (D-367)
+│   │   ├── LIEFERUMFANG                 # nur im Projekt: voll | nutzung
 │   │   ├── OWNERS.md                    # Ownership je Bereich (Governance)
-│   │   ├── clients/                     # ABBILDUNGSSCHICHT – je Client drei Dateien
+│   │   ├── clients/                     # ABBILDUNGSSCHICHT – je Client drei Bestandteile
 │   │   │   ├── README.md · _template/   # Regeln der Schicht, Vorlage für neue Packs
 │   │   │   ├── claude-code/             # CLIENT_PACK.md · manifest.json · root-template/
+│   │   │   ├── cursor/                  # dito
 │   │   │   ├── devin-desktop/           # dito
+│   │   │   ├── kiro/                    # dito
 │   │   │   └── openai-codex/            # dito
 │   │   ├── framework/                   # KANONISCHE, WERKZEUGNEUTRALE EBENE
 │   │   │   ├── core/00…10-*.md          # Framework Core, elf Module (Kap. 6, 10–14, 18, 25)
 │   │   │   ├── runtime/                 # Laufzeitfassung, einmal für alle Clients:
 │   │   │   │                            # Wurzel-Anweisung · Regeltexte · Agentenprofil
 │   │   │   │                            # · permissions.json · hooks.json · Vorlagen
-│   │   │   ├── skills/                  # fw-* Referenz-Skills, eine Quelle je Skill
+│   │   │   ├── skills/                  # koolie-* Referenz-Skills, eine Quelle je Skill
 │   │   │   ├── role-packs/              # Ebene 6 – RP-DEV und RP-RE ausgeliefert
 │   │   │   ├── tech-packs/              # Ebene 5 – Vorlage, kein konkretes Pack
-│   │   │   ├── overlay-patterns/        # Overlay-Muster general (--overlay general, D-355)
+│   │   │   ├── overlay-patterns/        # Overlay-Muster general (--overlay general)
 │   │   │   └── org-policies/            # Ebene B: Einbindungspunkt + Klassifizierungs-Mapping
 │   │   ├── templates/                   # Project-Overlay-Saat · Regelvorlagen · SKILL_TEMPLATE
 │   │   ├── prompts/                     # Prompt-Bibliothek FW-PR-001…012 + README (Kap. 21)
@@ -92,33 +114,40 @@ Angelegt und aktualisiert werden die Wurzelbestandteile durch `.koolie/core/inst
 └── <Produktivcode des Projekts>         # backend/, frontend/, src/, test/ …
 ```
 
-**Warum diese Aufteilung.** Lägen die Verzeichnisse und Dateien des Kerns direkt im Wurzelverzeichnis neben dem Produktivcode, wäre bei jeder Übernahme und Aktualisierung zu klären, was zum Framework gehört und was zum Projekt. Die Bündelung ändert nichts an der inhaltlichen Ebenenhierarchie (Kap. 7); sie trennt lediglich physisch, was ohnehin logisch getrennt ist: Der Kern ist ein Ordner, den man ersetzt; das Projekt ist alles daneben.
+**Warum diese Aufteilung.** Lägen die Dateien des Kerns direkt neben dem Produktivcode, wäre bei jeder Übernahme und Aktualisierung zu klären, was zum Framework gehört. Die Bündelung ändert nichts an der Ebenenhierarchie (Kap. 7); sie trennt physisch, was logisch getrennt ist: Der Kern ist ein Ordner, den man ersetzt, das Projekt ist alles daneben.
+
+**Die Laufzeitschicht ist Erzeugnis, nicht Quelle.** Nichts darin wird von Hand geschrieben. Regeltexte, Skills, Agentenprofil, Berechtigungen und Hooks liegen einmal unter `.koolie/core/framework/runtime/` und `framework/skills/` und werden bei der Installation in die Form des Client Packs gebracht (Kap. 7a). Ein Client Pack besteht aus drei Bestandteilen: der Pfad- und Semantikabbildung (`manifest.json`), der Fähigkeitsmatrix (`CLIENT_PACK.md`) und der Vorlage der Wurzelbestandteile (`root-template/`) mit einer erklärenden README der Laufzeitschicht.
+
+**Die Hook-Konfiguration steht dort, wo der Client sie nachweislich liest.** Bei `devin-desktop` und `claude-code` ist das die Berechtigungsdatei; eine eigene Hook-Datei führten diese Clients in der Messung nicht aus. `openai-codex`, `kiro` und `cursor` lesen eine eigene Hook-Datei (Block H der jeweiligen Matrix).
 
-**Die Laufzeitschicht ist Erzeugnis, nicht Quelle.** Kein Bestandteil von ihr wird von Hand geschrieben. Regeltexte, Skills, Agentenprofil, Berechtigungen und Hooks liegen einmal unter `.koolie/core/framework/runtime/` beziehungsweise `framework/skills/` und werden bei der Installation in die Form des gewählten Client Packs gebracht (Kap. 7a). Ein Client Pack selbst enthält **drei Dateien**: die Pfad- und Semantikabbildung (`manifest.json`), die Fähigkeitsmatrix (`CLIENT_PACK.md`) und eine erklärende README der Laufzeitschicht (D-36).
+**Grenze der Bündelung.** Wurzel-Anweisungsdatei und Laufzeitschicht lassen sich nicht mitverschieben; beide Ladeorte sind Werkzeugkonvention und nicht konfigurierbar `[DOK]`. Die Laufzeitschicht enthält deshalb Kern- und Projektbestandteile gemischt, und `install.py` trennt sie:
 
-**Die Hook-Konfiguration steht dort, wo der Client sie nachweislich liest, nicht dort, wo seine Dokumentation sie nennt** (D-32). Bei `devin-desktop` und `claude-code` ist das die **Berechtigungsdatei**; eine eigene Hook-Datei wird für sie nicht erzeugt, weil gemessen ist, dass ein Client aus ihr **keinen** Hook ausführte, während dieselbe Konfiguration in der Berechtigungsdatei sofort auslöste (`AP2-DD-10`). `openai-codex` führt die Hook-Konfiguration in einer eigenen Hook-Datei, die dieser Client nachweislich liest (sein Pack, Zeilen H1 bis H3).
+| Bestandteil | Behandlung |
+|---|---|
+| **Core** | wird bei `--update` überschrieben |
+| **Saat** (Berechtigungsdatei, Overlay, Overlay-Regel) | wird nur bei der Erstinstallation angelegt und danach nicht mehr angefasst |
 
-**Grenze der Bündelung.** Die Wurzel-Anweisungsdatei und die Laufzeitschicht lassen sich nicht mitverschieben – beide Ladeorte sind Werkzeugkonvention und nicht konfigurierbar `[DOK]`. Die Laufzeitschicht enthält deshalb Kern- und Projektbestandteile gemischt. Genau diese Mischung löst `install.py` auf: **Core** wird bei `--update` überschrieben, **Saat** (Berechtigungsdatei, Overlay, Overlay-Regel) nur bei der Erstinstallation angelegt und danach nie wieder angefasst. `--check` meldet, wenn eine Core-Datei im Wurzelverzeichnis lokal verändert wurde – also an der falschen Stelle bearbeitet.
+`--check` meldet, wenn eine Core-Datei im Wurzelverzeichnis lokal verändert wurde, also an der falschen Stelle bearbeitet.
 
-Damit sind alle geforderten Inhalte logisch abgebildet: zentrale Agentenanweisungen, Framework Core, Datenschutz- und Sicherheitsregeln (Core 02/03 plus Laufzeitregel 10), allgemeine Entwicklungsregeln (Core 04/06/07 plus Laufzeitregel 15), projektspezifisches Overlay, Rollenmodule, Technologiepakete, Skills, Skill-Vorlagen, Prompt-Vorlagen, Checklisten, Onboarding, Beispiele, Tests und Validierungen der Agentenanweisungen, Änderungsverzeichnis sowie Governance und Ownership.
+Damit sind alle geforderten Inhalte abgebildet: zentrale Agentenanweisungen, Framework Core, Datenschutz- und Sicherheitsregeln (Core 02/03 und Laufzeitregel 10), allgemeine Entwicklungsregeln (Core 04/06/07 und Laufzeitregel 15), Projekt-Overlay, Rollenmodule, Technologiepakete, Skills und Skill-Vorlagen, Prompt-Vorlagen, Checklisten, Onboarding, Beispiele, Tests und Validierung der Agentenanweisungen, Änderungsverzeichnis sowie Governance und Ownership.
 
 ## 15.3 Laufzeitschicht im Detail
 
-Die folgende Dokumentationsdatei der Laufzeitschicht beschreibt verbindlich, was der KI-Client aus dem Repository liest, welche Mechanismen bewusst nicht verwendet werden, welche Sitzungsfreigaben zulässig sind – und, in einem eigenen Abschnitt, die Systematik der Regelablage:
+Die Dokumentationsdatei der Laufzeitschicht beschreibt verbindlich, was der KI-Client aus dem Repository liest, welche Mechanismen bewusst nicht verwendet werden, welche Sitzungsfreigaben zulässig sind und, in einem eigenen Abschnitt, die Systematik der Regelablage:
 
 {{EMBED-RAW:<RUNTIME_DIR>/README.md:1}}
-Diese Systematik steht **hier** und nicht in der Regelablage selbst, weil der KI-Client jede Datei der Regelablage als Regel führt und damit ladbar macht – bei einem Pack sogar unbedingt. **Ein Verzeichnis, das als Regelmenge gelesen wird, enthält nur Regeln** (D-36); erklärender Text steht eine Ebene höher.
+Diese Systematik steht hier und nicht in der Regelablage selbst, weil der KI-Client jede Datei der Regelablage als Regel führt – bei einem Pack sogar unbedingt geladen. Ein Verzeichnis, das als Regelmenge gelesen wird, enthält nur Regeln; erklärender Text steht eine Ebene höher.
 
 ## 15.4 Zentrale Konfigurationsdateien
 
-Die folgenden Dateien sind **erzeugt**. Sie stammen aus einer Referenzinstallation, die beim Bau dieses Dokuments angelegt wird – bei einem anderen Client Pack sehen sie anders aus, ohne dass sich eine Regel ändert. Die Quellen liegen unter `.koolie/core/framework/runtime/`. **Bei `devin-desktop` und `claude-code` zeigen Berechtigungsdatei und Hook-Konfiguration auf dieselbe Datei**; sie wird dann einmal abgedruckt, und die zweite Stelle verweist darauf – zweimal dieselbe Datei abzudrucken ließe den Leser einen Unterschied suchen, den es nicht gibt.
+Die folgenden Dateien sind **erzeugt**. Sie stammen aus einer Referenzinstallation, die beim Bau dieses Dokuments angelegt wird; bei einem anderen Client Pack sehen sie anders aus, ohne dass sich eine Regel ändert. Die Quellen liegen unter `.koolie/core/framework/runtime/`. Wo Berechtigungsdatei und Hook-Konfiguration dieselbe Datei sind (`devin-desktop`, `claude-code`), wird sie einmal abgedruckt, und die zweite Stelle verweist darauf.
 
-**Berechtigungen** – restriktiver Standard; bei einer Berechtigungsdatei im JSON-Format mit Kernregel-Integritätsblock. Die Regelmenge ist werkzeugneutral; Werkzeugnamen, Musterform und der Integritätsblock entstehen aus der Semantikabbildung des Client Packs (Kap. 7a, `clientmap.py`):
+**Berechtigungen** – restriktiver Standard, bei einer Berechtigungsdatei im JSON-Format mit Kernregel-Integritätsblock. Die Regelmenge ist werkzeugneutral; Werkzeugnamen, Musterform und Integritätsblock entstehen aus der Semantikabbildung des Client Packs (Kap. 7a, `clientmap.py`):
 
 {{EMBED:<PERMISSIONS_FILE>:permissions_format}}
-**Hooks** – technische Prüfung vor Werkzeugaufrufen sowie Statusmeldung beim Sitzungsstart (Einstufung des Mechanismus: Block H der Fähigkeitsmatrix des Packs, D-396; Skripte `[EMPF]`; die Skripte selbst tragen den Status `entwurf` – sie sind Werkzeuge und keine Modulträger und zählen für Kriterium 3 der 1.0.0-Definition nicht mit):
+**Hooks** – technische Prüfung vor Werkzeugaufrufen und Statusmeldung beim Sitzungsstart. Die Einstufung des Mechanismus steht in Block H der Fähigkeitsmatrix; die Skripte sind `[EMPF]` und tragen als Werkzeuge den Status `entwurf`:
 
 {{EMBED:<HOOKS_FILE>:json}}
 **Subagentenprofil** – nur lesende Review-Zulieferung:
 
-{{EMBED:<AGENTS_DIR>/fw-reviewer.md}}
+{{EMBED:<AGENTS_DIR>/koolie-reviewer.md}}

package/.koolie/core/build/doc/16-agentenanweisung.md

@@ -1,8 +1,8 @@
 # 16 Zentrale Agentenanweisung
 
-Die zentrale Agentenanweisung ist die produktionsnahe Vorlage der Wurzel-Anweisungsdatei im Workspace-Wurzelverzeichnis. Sie wird vom KI-Client zu Beginn jeder Sitzung als always-on-Regel geladen `[DOK]`, bleibt bewusst unter der konservativ angesetzten 12.000-Zeichen-Grenze und regelt alle im Auftrag geforderten Punkte: Rolle des Agenten (1), Priorität und Hierarchie der Anweisungen (2), zulässigen Arbeitsbereich (3), Umgang mit fehlendem Kontext und Rückfragen statt Annahmen (4), Analyse vor Änderung (5), zulässige Dateioperationen (6), Befehlsausführung (7), Umgang mit Tests (8) und Fehlern (9), Änderungsumfang und Nachvollziehbarkeit (10), Datenschutz, Secrets und personenbezogene Daten (11), Sicherheit einschließlich Prompt-Injection-Abwehr (12), Abhängigkeiten und Architekturentscheidungen (13), Dokumentationspflicht sowie Commit- und Merge-Request-Unterstützung (14), menschliche Prüfung und Freigabe (15), Abbruch- und Eskalationsbedingungen (16) und die Skill-/Modusbindung (17). Projektwerte erscheinen ausschließlich als Platzhalter; die Datei wird nur über den Framework-Änderungsprozess geändert und ist für den KI-Client selbst schreibgesperrt (Berechtigungen und Hook).
+Die zentrale Agentenanweisung ist die produktionsnahe Vorlage der Wurzel-Anweisungsdatei im Workspace-Wurzelverzeichnis. Sie wird vom KI-Client zu Beginn jeder Sitzung als always-on-Regel geladen `[DOK]`, bleibt unter der Grenze von 12.000 Zeichen je Datei und regelt alle im Auftrag geforderten Punkte: Rolle des Agenten (1), Priorität und Hierarchie der Anweisungen (2), zulässigen Arbeitsbereich (3), Umgang mit fehlendem Kontext und Rückfragen statt Annahmen (4), Analyse vor Änderung (5), zulässige Dateioperationen (6), Befehlsausführung (7), Umgang mit Tests (8) und Fehlern (9), Änderungsumfang und Nachvollziehbarkeit (10), Datenschutz, Secrets und personenbezogene Daten (11), Sicherheit einschließlich Prompt-Injection-Abwehr (12), Abhängigkeiten und Architekturentscheidungen (13), Dokumentationspflicht sowie Commit- und Merge-Request-Unterstützung (14), menschliche Prüfung und Freigabe (15), Abbruch- und Eskalationsbedingungen (16) und die Skill-/Modusbindung (17). Projektwerte erscheinen ausschließlich als Platzhalter; die Datei wird nur über den Framework-Änderungsprozess geändert und ist für den KI-Client selbst schreibgesperrt (Berechtigungen und Hook).
 
-**Der Abstand zur Grenze ist klein und wird gemessen, nicht geschätzt.** Gemessen wird an der erzeugten Datei und nicht an der Quelle, weil die Platzhalter beim Erzeugen aufgelöst werden und die Länge sich dabei ändert. Gezählt am 2026-09-22: 11.887 Zeichen beim Pack `devin-desktop` und 11.894 bei `claude-code` – 113 beziehungsweise 106 Zeichen unter der Grenze; die Quelle allein war 11.924 Zeichen lang. Die Grenze ist eine Vorgabe des Frameworks und keine Produkteigenschaft: Ein Abgleich gegen die Herstellerdokumentation hat für Regeldateien keine Zeichengrenze gefunden (Anhang 31.5, V1). Seit `1.9.2` ist sie eine Warnung; verbindlich ist die Summe, die jede Sitzung lädt – Wurzel-Anweisung und unbedingt geladene Regeln zusammen höchstens 40.000 Zeichen (D-387).
+**Grenzen der Länge.** Gemessen wird an der erzeugten Datei, nicht an der Quelle, weil die Platzhalter beim Erzeugen aufgelöst werden und die Länge sich dabei ändert. Die 12.000 Zeichen je Datei sind eine Vorgabe des Frameworks, keine Produkteigenschaft – die Herstellerdokumentation nennt für Regeldateien keine Zeichengrenze (Anhang 31.5, V1) –, und der Validator meldet eine Überschreitung als Warnung. Verbindlich ist die Summe, die jede Sitzung lädt: Wurzel-Anweisung und unbedingt geladene Regeln zusammen höchstens 40.000 Zeichen.
 
 {{EMBED:<ROOT_INSTRUCTION_FILE>}}
 {{LOKALE-ERGAENZUNG}}

package/.koolie/core/build/doc/20-referenz-skills.md

@@ -1,70 +1,70 @@
 # 20 Referenz-Skills
 
-Die dreizehn Referenz-Skills decken die geforderten Aufgaben ab und bilden zusammen den Standardweg jeder Änderung (verstehen → bewerten → planen → umsetzen → testen → prüfen → beschreiben). Jeder Skill ist projektneutral, verlangt Rückfragen bei Unklarheiten, macht Annahmen sichtbar, begrenzt den Scope, definiert Prüfungen, besitzt ein festes Ausgabeformat und bringt Positiv- wie Negativtestfälle mit (mindestens zwei beziehungsweise drei je Skill; gezählt am 2026-09-22: je zwei Positiv- und drei bis fünf Negativtestfälle, zusammen 72 Zellen).
+Die dreizehn Referenz-Skills decken die geforderten Aufgaben ab und bilden zusammen den Standardweg jeder Änderung (verstehen → bewerten → planen → umsetzen → testen → prüfen → beschreiben). Jeder Skill ist projektneutral, verlangt Rückfragen bei Unklarheiten, macht Annahmen sichtbar, begrenzt den Scope, definiert Prüfungen, besitzt ein festes Ausgabeformat und bringt Positiv- wie Negativtestfälle mit: mindestens zwei Positiv- und drei Negativtestfälle je Skill.
 
-Alle dreizehn stehen im Status `pilot`, Owner `<FRAMEWORK_OWNER>`; sie durchlaufen den Lebenszyklus aus Kapitel 18, und ihre Versionen stehen in der Metadatentabelle jeder SKILL.md. Ihre Testzellen sind an einer laufenden Sitzung abgenommen, nicht abgezeichnet – der Ergebnisstatus jeder Zelle nennt sein Protokoll und das gemessene Client Pack mit Produktstand.
+Alle dreizehn stehen im Status `pilot`, Owner `<FRAMEWORK_OWNER>`; sie durchlaufen den Lebenszyklus aus Kapitel 18, und ihre Versionen stehen in der Metadatentabelle jeder SKILL.md. Ihre Testzellen werden in einer laufenden Sitzung abgenommen; der Ergebnisstatus jeder Zelle nennt Protokoll, Client Pack und Produktstand.
 
-**Ein vierzehnter Skill liegt außerhalb dieses Kapitels:** `role-re-ticket` gehört zum Role Pack Requirements Engineering (Ebene 6, Kap. 7.3) und wird nicht mit dem Kern installiert, sondern mit dem Pack aktiviert. Er bringt fünf Positiv- und zehn Negativtestfälle mit.
+Ein vierzehnter Skill liegt außerhalb dieses Kapitels: `koolie-ticket` gehört zum Role Pack Requirements Engineering (Ebene 6, Kap. 7.3) und wird nicht mit dem Kern installiert, sondern mit dem Pack aktiviert. Er bringt fünf Positiv- und zehn Negativtestfälle mit.
 
 | ID | Skill (`/aufruf`) | Auftragspunkt | Modus | Werkzeuge | Trigger |
 |---|---|---|---|---|---|
-| FW-SK-001 | `fw-repo-analyze` | Repository analysieren | M1 | read, grep, glob | user, model |
-| FW-SK-002 | `fw-code-explain` | Bestehenden Code erklären | M1 | read, grep, glob | user, model |
-| FW-SK-003 | `fw-change-analyze` | Änderung fachlich und technisch analysieren | M1 | read, grep, glob | user, model |
-| FW-SK-004 | `fw-plan` | Implementierungsplan erzeugen | M2 | read, grep, glob | user, model |
-| FW-SK-005 | `fw-change-small` | Kleine Codeänderung umsetzen | M3 | read, grep, glob, edit, exec | user |
-| FW-SK-006 | `fw-tests` | Unit Tests erstellen oder erweitern | M4 | read, grep, glob, edit, exec | user |
-| FW-SK-007 | `fw-refactor` | Code refaktorieren | M3 | read, grep, glob, edit, exec | user |
-| FW-SK-008 | `fw-error-analyze` | Fehler analysieren | M1 | read, grep, glob | user, model |
-| FW-SK-009 | `fw-bugfix-prepare` | Bugfix vorbereiten | M2 | read, grep, glob | user, model |
-| FW-SK-010 | `fw-review-support` | Code Review unterstützen | M1 | read, grep, glob, exec (nur lesende Git-Befehle) | user |
-| FW-SK-011 | `fw-docs-update` | Dokumentation aktualisieren | M5 | read, grep, glob, edit | user |
-| FW-SK-012 | `fw-mr-description` | Merge-Request-Beschreibung erstellen | M5 | read, grep, glob, exec (nur lesende Git-Befehle) | user |
-| FW-SK-013 | `fw-overlay-pflege` | Entscheidungen in das Overlay eintragen (Einrichtung, Framework-Update, Eintrag) | M6 | read, grep, glob, edit, exec (Prüfbefehle, lesende Git-Befehle) | user |
+| FW-SK-001 | `koolie-repo-analyze` | Repository analysieren | M1 | read, grep, glob | user, model |
+| FW-SK-002 | `koolie-code-explain` | Bestehenden Code erklären | M1 | read, grep, glob | user, model |
+| FW-SK-003 | `koolie-change-analyze` | Änderung fachlich und technisch analysieren | M1 | read, grep, glob | user, model |
+| FW-SK-004 | `koolie-plan` | Implementierungsplan erzeugen | M2 | read, grep, glob | user, model |
+| FW-SK-005 | `koolie-change-small` | Kleine Codeänderung umsetzen | M3 | read, grep, glob, edit, exec | user |
+| FW-SK-006 | `koolie-tests` | Unit Tests erstellen oder erweitern | M4 | read, grep, glob, edit, exec | user |
+| FW-SK-007 | `koolie-refactor` | Code refaktorieren | M3 | read, grep, glob, edit, exec | user |
+| FW-SK-008 | `koolie-error-analyze` | Fehler analysieren | M1 | read, grep, glob | user, model |
+| FW-SK-009 | `koolie-bugfix-prepare` | Bugfix vorbereiten | M2 | read, grep, glob | user, model |
+| FW-SK-010 | `koolie-review-support` | Code Review unterstützen | M1 | read, grep, glob, exec (nur lesende Git-Befehle) | user |
+| FW-SK-011 | `koolie-docs-update` | Dokumentation aktualisieren | M5 | read, grep, glob, edit | user |
+| FW-SK-012 | `koolie-mr-description` | Merge-Request-Beschreibung erstellen | M5 | read, grep, glob, exec (nur lesende Git-Befehle) | user |
+| FW-SK-013 | `koolie-overlay-pflege` | Entscheidungen in das Overlay eintragen (Einrichtung, Framework-Update, Eintrag) | M6 | read, grep, glob, edit, exec (Prüfbefehle, lesende Git-Befehle) | user |
 
-Nachfolgend die normativen Skill-Dateien (SKILL.md) aller dreizehn Skills. Die Begleitdateien (EXAMPLES.md mit synthetischen Positiv- und Negativbeispielen, TESTS.md mit den Testfällen, CHANGELOG.md) liegen je Skill im Repository; stellvertretend ist für FW-SK-001 der vollständige Satz wiedergegeben (Abschnitt 20.13).
+Nachfolgend die normativen Skill-Dateien (SKILL.md) aller dreizehn Skills. Die Begleitdateien (EXAMPLES.md mit synthetischen Positiv- und Negativbeispielen, TESTS.md mit den Testfällen, CHANGELOG.md) liegen je Skill im Repository; stellvertretend ist für FW-SK-001 der vollständige Satz wiedergegeben (Abschnitt 20.14).
 
-## 20.1 FW-SK-001 `fw-repo-analyze`
+## 20.1 FW-SK-001 `koolie-repo-analyze`
 
-{{EMBED:<SKILLS_DIR>/fw-repo-analyze/SKILL.md}}
-## 20.2 FW-SK-002 `fw-code-explain`
+{{EMBED:<SKILLS_DIR>/koolie-repo-analyze/SKILL.md}}
+## 20.2 FW-SK-002 `koolie-code-explain`
 
-{{EMBED:<SKILLS_DIR>/fw-code-explain/SKILL.md}}
-## 20.3 FW-SK-003 `fw-change-analyze`
+{{EMBED:<SKILLS_DIR>/koolie-code-explain/SKILL.md}}
+## 20.3 FW-SK-003 `koolie-change-analyze`
 
-{{EMBED:<SKILLS_DIR>/fw-change-analyze/SKILL.md}}
-## 20.4 FW-SK-004 `fw-plan`
+{{EMBED:<SKILLS_DIR>/koolie-change-analyze/SKILL.md}}
+## 20.4 FW-SK-004 `koolie-plan`
 
-{{EMBED:<SKILLS_DIR>/fw-plan/SKILL.md}}
-## 20.5 FW-SK-005 `fw-change-small`
+{{EMBED:<SKILLS_DIR>/koolie-plan/SKILL.md}}
+## 20.5 FW-SK-005 `koolie-change-small`
 
-{{EMBED:<SKILLS_DIR>/fw-change-small/SKILL.md}}
-## 20.6 FW-SK-006 `fw-tests`
+{{EMBED:<SKILLS_DIR>/koolie-change-small/SKILL.md}}
+## 20.6 FW-SK-006 `koolie-tests`
 
-{{EMBED:<SKILLS_DIR>/fw-tests/SKILL.md}}
-## 20.7 FW-SK-007 `fw-refactor`
+{{EMBED:<SKILLS_DIR>/koolie-tests/SKILL.md}}
+## 20.7 FW-SK-007 `koolie-refactor`
 
-{{EMBED:<SKILLS_DIR>/fw-refactor/SKILL.md}}
-## 20.8 FW-SK-008 `fw-error-analyze`
+{{EMBED:<SKILLS_DIR>/koolie-refactor/SKILL.md}}
+## 20.8 FW-SK-008 `koolie-error-analyze`
 
-{{EMBED:<SKILLS_DIR>/fw-error-analyze/SKILL.md}}
-## 20.9 FW-SK-009 `fw-bugfix-prepare`
+{{EMBED:<SKILLS_DIR>/koolie-error-analyze/SKILL.md}}
+## 20.9 FW-SK-009 `koolie-bugfix-prepare`
 
-{{EMBED:<SKILLS_DIR>/fw-bugfix-prepare/SKILL.md}}
-## 20.10 FW-SK-010 `fw-review-support`
+{{EMBED:<SKILLS_DIR>/koolie-bugfix-prepare/SKILL.md}}
+## 20.10 FW-SK-010 `koolie-review-support`
 
-{{EMBED:<SKILLS_DIR>/fw-review-support/SKILL.md}}
-## 20.11 FW-SK-011 `fw-docs-update`
+{{EMBED:<SKILLS_DIR>/koolie-review-support/SKILL.md}}
+## 20.11 FW-SK-011 `koolie-docs-update`
 
-{{EMBED:<SKILLS_DIR>/fw-docs-update/SKILL.md}}
-## 20.12 FW-SK-012 `fw-mr-description`
+{{EMBED:<SKILLS_DIR>/koolie-docs-update/SKILL.md}}
+## 20.12 FW-SK-012 `koolie-mr-description`
 
-{{EMBED:<SKILLS_DIR>/fw-mr-description/SKILL.md}}
-## 20.13 FW-SK-013 `fw-overlay-pflege`
+{{EMBED:<SKILLS_DIR>/koolie-mr-description/SKILL.md}}
+## 20.13 FW-SK-013 `koolie-overlay-pflege`
 
-{{EMBED:<SKILLS_DIR>/fw-overlay-pflege/SKILL.md}}
+{{EMBED:<SKILLS_DIR>/koolie-overlay-pflege/SKILL.md}}
 ## 20.14 Begleitdateien am Beispiel FW-SK-001 (vollständiger Satz)
 
-{{EMBED:<SKILLS_DIR>/fw-repo-analyze/EXAMPLES.md}}
-{{EMBED:<SKILLS_DIR>/fw-repo-analyze/TESTS.md}}
-{{EMBED:<SKILLS_DIR>/fw-repo-analyze/CHANGELOG.md}}
+{{EMBED:<SKILLS_DIR>/koolie-repo-analyze/EXAMPLES.md}}
+{{EMBED:<SKILLS_DIR>/koolie-repo-analyze/TESTS.md}}
+{{EMBED:<SKILLS_DIR>/koolie-repo-analyze/CHANGELOG.md}}

package/.koolie/core/build/doc/25-governance.md

@@ -1,6 +1,14 @@
 # 25 Governance und Lifecycle Management
 
-Das Betriebsmodell macht das Framework selbst zu einem gepflegten Produkt: mit Framework Owner und Modul-Ownern, fachlicher und technischer Verantwortung je Bereich, Review-Zyklus, Semantic Versioning und Release-Prozess samt Release-Archiv, Änderungsanträgen, Freigabe und Deprecation von Skills, definiertem Umgang mit Produktänderungen des KI-Clients, Vorfallbehandlung, Lessons Learned, Feedback- und Ausnahmeprozess, durchgängiger Auditierbarkeit und dem Verfahren zur Übernahme in weitere Projekte (Kap. 28). Die Prioritätshierarchie – einschließlich der im Auftrag geforderten kritischen Widerspruchsprüfung und der begründeten Anpassungen – ist Bestandteil dieses Kapitels.
+Das Betriebsmodell pflegt das Framework als Produkt:
+
+- Framework Owner und Modul-Owner, fachliche und technische Verantwortung je Bereich;
+- Review-Zyklus, Semantic Versioning und Release-Prozess mit Release-Archiv;
+- Änderungsanträge, Freigabe und Deprecation von Skills, Umgang mit Produktänderungen des KI-Clients;
+- Vorfallbehandlung, Lessons Learned, Feedback- und Ausnahmeprozess;
+- durchgängige Auditierbarkeit und die Übernahme in weitere Projekte (Kap. 28).
+
+Dazu gehört die Prioritätshierarchie mit ihrer Widerspruchsprüfung.
 
 ## 25.1 Prioritätshierarchie mit Widerspruchsprüfung
 

package/.koolie/core/build/doc/26-qs-test.md

@@ -1,9 +1,38 @@
 # 26 Qualitätssicherung und Testkonzept des Frameworks
 
-Nicht nur KI-Ergebnisse, auch das Framework selbst wird geprüft – auf zwei Wegen. **Statisch** prüft `.koolie/core/tests/scripts/validate-framework.py` Struktur und Inhalte: Pflichtdateien, Frontmatter und Trigger der Regeln, Zeichenlimits, Skill-Konformität (Pflichtdateien, Metadaten, Pflichtabschnitte, Trigger-Regel für schreibende Skills, Beispiel- und Testpflichten), JSON-Gültigkeit und Kernregel-Integrität der Berechtigungen, Manifest-Schema, Platzhalterregister, verbotene Inhalte (Secret-Muster, E-Mail-Adressen, IP-Adressen, interne Hostnamen, URLs außerhalb der Quellen-Allowlist, projektlokale Sperrbegriffe aus `.koolie/project-overlay/forbidden-terms.txt`) sowie – mit `--mermaid` – die Syntax aller Diagramme und – mit `--strict-overlay` – die Aktivierungsreife eines Overlays. Ergänzend prüft `.koolie/core/tests/scripts/validate-output.py` konkrete Assistenz-Ausgaben gegen das Ausgabeformat des jeweiligen Skills, und die Hook-Skripte besitzen Selbsttests. **Der Lauf zum Stand dieser Dokumentfassung: 0 Fehler, 0 Warnungen.** Der Validator führt **112 Prüfungen** über 676 versionierte Dateien des Kerns, davon 569 Markdown-Dateien; das Register der Prüfungen steht im Kopfkommentar des Skripts und wird von Prüfung 40 gegen den Bestand nachgezählt, und diese drei Zahlen hält Prüfung 78 gegen den Bestand (D-315). **Jede Prüfung hat einen eigenen Wirkungsnachweis:** `.koolie/core/tests/scripts/probe-pruefungen.py` legt je Prüfung einen Fehlerfall an und verlangt die Meldung, dazu eine Gegenprobe, die den korrekten Träger durchlaufen lässt – *eine Prüfung ohne Sonde gilt als nicht vorhanden.* Acht Mermaid-Blöcke (sechs Entscheidungsbäume, das Architekturdiagramm aus Kap. 7 und das Roadmap-Diagramm) prüft der Schalter `--mermaid`; er setzt das Mermaid-Kommandozeilenwerkzeug voraus.
+Das Framework selbst wird auf zwei Wegen geprüft: statisch und in Testsitzungen.
 
-**Dynamisch** prüft der Testkatalog das Verhalten in Testsitzungen auf dem synthetischen Übungsrepository – in elf Klassen: Konsistenz und Widerspruchserkennung (KO), Positivtests (PO), Negativtests (NE), Datenschutz (DS), Prompt Injection (PI), Scope-Einhaltung (SC), Verhalten bei fehlenden Informationen (FI), unerlaubte Datei- und Befehlszugriffe (ZA), Regression bei Framework-Änderungen (RE), Versionsnachvollziehbarkeit (VN) und Aktualität gegenüber Produktänderungen des Clients (AK). Die skill-spezifischen Testfälle in den TESTS.md-Dateien (je Skill mindestens zwei Positiv- und drei Negativtests) sind Teil des Katalogs. **Sechs dynamische Tests stehen auf `offen`** – Kriterium 2 der 1.0.0-Definition (D-11) ist damit nicht erfüllt, und Prüfung 46 zählt es bei jedem Lauf nach: Im Nachlauf von Release 1.14.0 tragen sechs Zellen der Testblätter mit Opus 5.5 nicht, keine wegen einer Änderung an ihrem Skill (D-424, `K-167`, eingeplant als 1.14.1); `SK-002-N03` trägt seither. Alle 38 Ergebniszellen des zentralen Katalogs und 81 der 87 Zellen der dreizehn dezentralen Testblätter tragen `bestanden`.
+**Statisch** prüft `.koolie/core/tests/scripts/validate-framework.py` Struktur und Inhalte:
 
-**Was ein `bestanden` sagt und was nicht.** Es sagt, dass das erwartete Verhalten eingetreten ist – nicht, dass das Framework es bewirkt hat (D-115). Die Zurechnung trägt ein eigener Kontrollauf gegen einen Baum ohne die geprüfte Schranke; wo er fehlt, sagt die Zelle es. Jede Zelle nennt außerdem das gemessene Client Pack mit Produktstand: Ein Ergebnis gilt für den Client, an dem es erhoben wurde, und für keinen anderen (D-117). Ausführungsdisziplin und Protokollpflicht sind im Katalog normiert.
+- Pflichtdateien, Frontmatter und Trigger der Regeln, Zeichenlimits;
+- Skill-Konformität: Pflichtdateien, Metadaten, Pflichtabschnitte, Trigger-Regel für schreibende Skills, Beispiel- und Testpflichten;
+- JSON-Gültigkeit und Kernregel-Integrität der Berechtigungen, Manifest-Schema, Platzhalterregister;
+- verbotene Inhalte: Secret-Muster, E-Mail-Adressen, IP-Adressen, interne Hostnamen, URLs außerhalb der Quellen-Allowlist und die projektlokalen Sperrbegriffe aus `.koolie/project-overlay/forbidden-terms.txt`;
+- mit `--mermaid` die Syntax aller Diagramme, mit `--strict-overlay` die Aktivierungsreife eines Overlays.
+
+`.koolie/core/tests/scripts/validate-output.py` prüft konkrete Ausgaben gegen das Ausgabeformat des jeweiligen Skills; die Hook-Skripte haben Selbsttests. Der Lauf zum Stand dieser Dokumentfassung: 0 Fehler, 0 Warnungen. Der Validator führt **113 Prüfungen** über 680 versionierte Dateien des Kerns, davon 571 Markdown-Dateien. Das Register der Prüfungen steht im Kopfkommentar des Skripts; Prüfung 40 zählt es gegen den Bestand nach, Prüfung 78 diese drei Zahlen.
+
+Jede Prüfung hat einen eigenen Wirkungsnachweis: `.koolie/core/tests/scripts/probe-pruefungen.py` legt je Prüfung einen Fehlerfall an und verlangt die Meldung, dazu eine Gegenprobe, die den korrekten Träger durchlaufen lässt. Eine Prüfung ohne Sonde gilt als nicht vorhanden. Die acht Mermaid-Blöcke (sechs Entscheidungsbäume, das Architekturdiagramm aus Kap. 7 und das Roadmap-Diagramm) prüft `--mermaid`; der Schalter setzt das Mermaid-Kommandozeilenwerkzeug voraus.
+
+**In Testsitzungen** prüft der Testkatalog das Verhalten auf dem synthetischen Übungsrepository, in zwölf Klassen:
+
+| Kürzel | Klasse |
+|---|---|
+| KO | Konsistenz und Widerspruchserkennung |
+| PO | Positivtests |
+| NE | Negativtests |
+| DS | Datenschutz |
+| PI | Prompt Injection |
+| SC | Scope-Einhaltung |
+| FI | Verhalten bei fehlenden Informationen |
+| ZA | unerlaubte Datei- und Befehlszugriffe |
+| RE | Regression bei Framework-Änderungen |
+| VN | Versionsnachvollziehbarkeit |
+| AK | Aktualität gegenüber Produktänderungen des Clients |
+| EX | externe Systeme über MCP |
+
+Die Testfälle der Skills in den `TESTS.md`-Dateien (je Skill mindestens zwei Positiv- und drei Negativtests) gehören zum Katalog. Den Stand der Ergebniszellen rechnet Prüfung 46 bei jedem Lauf aus; er steht in der Roadmap (Kap. 30).
+
+**Was ein `bestanden` sagt.** Es sagt, dass das erwartete Verhalten eingetreten ist – nicht, dass das Framework es bewirkt hat. Die Zurechnung trägt ein eigener Kontrolllauf gegen einen Baum ohne die geprüfte Schranke; wo er fehlt, sagt die Zelle es. Jede Zelle nennt das gemessene Client Pack mit Produktstand: Ein Ergebnis gilt für den Client, an dem es erhoben wurde. Ausführungsdisziplin und Protokollpflicht sind im Katalog geregelt.
 
 {{EMBED-RAW:.koolie/core/tests/TEST_CATALOG.md:1}}

package/.koolie/core/build/doc/27-pilot.md

@@ -1,8 +1,8 @@
 # 27 Pilotierung und Metriken
 
-Das generische Pilotkonzept macht die Einführung zu einem Experiment mit Abbruchrecht: Referenzbasis vor der Einführung, definierte Pilotgruppe, konfigurierbarer Zeitraum (`<PILOT_DURATION>`), ausgewählte Anwendungsfälle, Vergleichbarkeit über Aufgaben-Etiketten, regelmäßige Review-Punkte, klare Abbruchkriterien und am Ende eine dokumentierte Entscheidung über Fortführung, Anpassung oder Beendigung. Befragungen sind freiwillig und werden nicht personenbeziehbar ausgewertet; keine Metrik dient der Bewertung von Personen.
+Das Pilotkonzept macht die Einführung zu einem Experiment mit Abbruchrecht: Referenzbasis vor der Einführung, definierte Pilotgruppe, konfigurierbarer Zeitraum (`<PILOT_DURATION>`), ausgewählte Anwendungsfälle, Vergleichbarkeit über Aufgaben-Etiketten, regelmäßige Review-Punkte, klare Abbruchkriterien und am Ende eine dokumentierte Entscheidung über Fortführung, Anpassung oder Beendigung. Befragungen sind freiwillig und werden nicht personenbeziehbar ausgewertet; keine Metrik dient der Bewertung von Personen.
 
-Die Metriken decken die geforderten Größen ab (Bearbeitungszeit, Nachbearbeitungs- und Review-Aufwand, Fehlerquote, Wiedereröffnungen, Testabdeckung, Build- und Pipelinefehler, Rückfragen, Akzeptanz, wahrgenommene Entlastung, Verständlichkeit der Änderungen, Anteil verworfener Vorschläge) – ausdrücklich **als Vorschläge, ohne Zielwerte**: Zielwerte sind projektspezifisch festzulegen, und einzelne Metriken erlauben keine belastbare Aussage über den Gesamtnutzen; Produktivität, Ergebnisqualität, Sicherheit und Nutzerakzeptanz werden gemeinsam betrachtet.
+Die Metriken decken Bearbeitungszeit, Nachbearbeitungs- und Review-Aufwand, Fehlerquote, Wiedereröffnungen, Testabdeckung, Build- und Pipelinefehler, Rückfragen, Akzeptanz, wahrgenommene Entlastung, Verständlichkeit der Änderungen und den Anteil verworfener Vorschläge ab. Sie sind **Vorschläge ohne Zielwerte**: Zielwerte legt das Projekt fest. Eine einzelne Metrik sagt nichts Belastbares über den Gesamtnutzen; Produktivität, Ergebnisqualität, Sicherheit und Nutzerakzeptanz werden gemeinsam betrachtet.
 
 ## 27.1 Pilotkonzept
 

package/.koolie/core/build/doc/28-uebernahme.md

@@ -1,5 +1,13 @@
 # 28 Vorgehen zur Übernahme in weitere Projekte
 
-Die Übernahme ist als wiederholbarer, geprüfter Vorgang gestaltet: Ein Projekt übernimmt ein Framework-**Release**, und zwar nur den Kern `.koolie/core/`, nie ganz `.koolie/` (D-354) – über den Starter `install.cmd` (Windows) beziehungsweise `install.command` (macOS) aus dem Release-Archiv oder direkt mit `install.py --target` (D-362); das Skript legt dabei die Wurzelbestandteile des gewählten Client Packs an und kopiert auf Wunsch den Kern ohne Nachweisschicht (`--lieferumfang nutzung`, D-367). Danach füllt es ausschließlich die Overlay-Bestandteile, härtet projektlokal (Sperrbegriffe, zusätzliche Pfadsperren), validiert strikt, besteht die Basistests des Testkatalogs, organisiert Rollen und Onboarding – und setzt erst dann den Overlay-Status auf `aktiv` (verbindlicher Nachweis: Checkliste FW-CL-10, Kap. 22.10). Aktualisierungen auf neue Releases ersetzen `.koolie/core/` als Ganzes durch das neue Release (`install.py --target … --update` oder Kopie plus `install.py --update`), ziehen die Wurzelbestandteile nach und prüfen die Overlay-Kompatibilität anhand der Migrationshinweise; Mehr-Repository-Projekte und der spätere Werkzeugwechsel sind geregelt. Abschnitt 8 nennt, was die Umgebung neben Koolie tragen muss – verwaltete Einstellungen, Branch-Schutz und CI, Isolation (D-513) –, regelt das Nebeneinander mit einem anderen Agenten-Rahmenwerk (D-514, D-515) und berichtet die Vergleichsmessung gegen eine gute Standardkonfiguration (D-516).
+Die Übernahme ist ein wiederholbarer, geprüfter Vorgang. Ein Projekt übernimmt ein Framework-**Release**, und zwar nur den Kern `.koolie/core/`, nie ganz `.koolie/`:
+
+1. **Installieren** – über eine Paketquelle (`uvx koolie`, `pipx run koolie` oder `npx @renoxar/koolie` im Projektverzeichnis), über den Starter `install.cmd` (Windows) beziehungsweise `install.command` (macOS) aus dem Release-Archiv oder direkt mit `install.py --target`. Dabei entstehen die Wurzelbestandteile des gewählten Client Packs; `--lieferumfang nutzung` kopiert den Kern ohne Nachweisschicht.
+2. **Overlay füllen** – nur die Overlay-Bestandteile; dazu projektlokal härten (Sperrbegriffe, zusätzliche Pfadsperren).
+3. **Prüfen** – strikt validieren und die Basistests des Testkatalogs bestehen.
+4. **Organisieren** – Rollen besetzen, Onboarding durchführen.
+5. **Aktivieren** – erst dann den Overlay-Status auf `aktiv` setzen. Verbindlicher Nachweis ist die Checkliste FW-CL-10 (Kap. 22.10).
+
+Ein neues Release ersetzt `.koolie/core/` als Ganzes (`install.py --target … --update` oder Kopie plus `install.py --update`), zieht die Wurzelbestandteile nach und prüft die Overlay-Kompatibilität anhand der Migrationshinweise. Mehr-Repository-Projekte und der spätere Werkzeugwechsel sind geregelt. Abschnitt 8 nennt, was die Umgebung neben Koolie tragen muss (verwaltete Einstellungen, Branch-Schutz und CI, Isolation), regelt das Nebeneinander mit einem anderen Agenten-Rahmenwerk und berichtet die Vergleichsmessung gegen eine gute Standardkonfiguration.
 
 {{EMBED-RAW:.koolie/core/docs/ADOPTION_GUIDE.md:1}}

package/.koolie/core/build/doc/30-roadmap.md

@@ -1,5 +1,7 @@
 # 30 Implementierungs-Roadmap
 
-Die Roadmap strukturiert die Einführung in dreizehn Arbeitspakete – Initialisierung und Scope, Validierung der Client-Mechanismen, Framework Core, technische Referenzimplementierung, erste Skills, Datenschutz- und Security-Review, Testkatalog, Onboarding, Pilot, Auswertung, Stabilisierung, Version 1.0 und Übernahme in weitere Projekte. Je Arbeitspaket sind Ziel, Aktivitäten, Eingaben, Ergebnisse, Abhängigkeiten, verantwortliche generische Rolle, Abnahmekriterien, Risiken und offene Entscheidungen definiert; gesteuert wird über Prioritäten und logische Abhängigkeiten, ohne Termine oder Aufwandsschätzungen. Die Erstfassung 0.1.0 deckte die inhaltlichen Ergebnisse von AP3 bis AP5 bereits in Entwurfsqualität ab; die Pakete bestätigen, validieren und härten sie. Release 1.0.0 ist erschienen, die fünf Kriterien von D-11 sind erfüllt. AP1 (Rollenbesetzung, Datenschutz- und Vertragsprüfung), AP6 (Sicherheits- und Datenschutzfreigabe) sowie AP8 bis AP10 (Onboarding, Pilot, Auswertung) sind **projektseitig** und ausdrücklich keine Vorbedingung für 1.0.0 – *ein Release 1.0.0 erklärt nicht, dass das Framework im Realbetrieb erprobt wurde.* Den aktuellen Stand und die geplanten Releases führt die eingebettete Roadmap im Abschnitt „Stand nach Release …".
+Die Roadmap gliedert die Einführung in dreizehn Arbeitspakete: Initialisierung und Scope, Validierung der Client-Mechanismen, Framework Core, technische Referenzimplementierung, erste Skills, Datenschutz- und Security-Review, Testkatalog, Onboarding, Pilot, Auswertung, Stabilisierung, Version 1.0 und Übernahme in weitere Projekte. Je Arbeitspaket sind Ziel, Aktivitäten, Eingaben, Ergebnisse, Abhängigkeiten, verantwortliche generische Rolle, Abnahmekriterien, Risiken und offene Entscheidungen festgelegt. Gesteuert wird über Prioritäten und logische Abhängigkeiten, ohne Termine oder Aufwandsschätzungen.
+
+Release 1.0.0 ist erschienen; die fünf Kriterien dafür sind erfüllt. AP1 (Rollenbesetzung, Datenschutz- und Vertragsprüfung), AP6 (Sicherheits- und Datenschutzfreigabe) sowie AP8 bis AP10 (Onboarding, Pilot, Auswertung) sind **projektseitig** und keine Vorbedingung für 1.0.0. Ein Release 1.0.0 sagt also nicht, dass das Framework im Realbetrieb erprobt wurde. Den aktuellen Stand und die geplanten Releases nennt die eingebettete Roadmap im Abschnitt „Stand nach Release …".
 
 {{EMBED-RAW:.koolie/core/docs/ROADMAP.md:1}}

package/.koolie/core/build/doc/31-anhaenge.md

@@ -143,7 +143,7 @@ Die folgende Liste ergänzt sie um Punkte, die keiner einzelnen Zusage der Matri
 | V6 | Struktur von `.devin/mcp_config.json` im Desktop und Status des Legacy-Pfads `~/.codeium/mcp_config.json` | `.devin/mcp_config.json.example` |
 | V7 | Codebasis-Indexierung: Art, Speicherort, Abschaltbarkeit (Datenschutzmodell Abschnitt 1) | FW-CORE-02, K-20 |
 | V8 | Reichweite geteilten Kontexts in Spaces | FW-CORE-02 Abschnitt 3.9 |
-| V9 | Wirkung additiver Skill-`permissions` gegenüber Sitzungs- und Projektregeln in Devin Local | Skills mit `permissions`, u. a. `fw-mr-description` |
+| V9 | Wirkung additiver Skill-`permissions` gegenüber Sitzungs- und Projektregeln in Devin Local | Skills mit `permissions`, u. a. `koolie-mr-description` |
 | V10 | Zeichen-/Größenbudget und Ladeverhalten der always-on-Summe (AGENTS.md + `00-*` + `20-*`) im realen Systemprompt | Laufzeitschicht gesamt |
 
 ## 31.6 Beispielartefakte (synthetisch)

package/.koolie/core/checklists/01-preflight.md

@@ -35,12 +35,12 @@ Stellt vor dem ersten Prompt sicher, dass die Aufgabe delegierbar, richtig einge
 
 - [ ] **MUSS** Erlaubte Pfade für diese Aufgabe benannt; `<EXCLUDED_PATHS>` und `<READ_ONLY_PATHS>` bekannt.
 - [ ] **MUSS** Kontextquellen gelistet und je Quelle die Kontextklasse bestimmt (`.koolie/core/checklists/02-privacy-context.md`); K2 nur mit Freigabe, K3 nie.
-- [ ] **MUSS** Overlay-Status ist `aktiv` (Ausnahme: Onboarding-Übung auf dem Übungsrepository; am Quellrepositorium des Frameworks gilt stattdessen `.koolie/core/governance/FRAMEWORK_DEV_PROFILE.md`, das **keine** technische Berechtigung erteilt und dessen Geltung der KI-Client nicht selbst feststellt – D-253).
-- [ ] **SOLL** Passender Skill als vorgesehener Weg gewählt (`/fw-…`); ein anderer Weg MUSS im Ergebnisbericht benannt und begründet werden (`.koolie/core/framework/core/05-working-model.md` Abschnitt 1; `.koolie/core/prompts/README.md` Abschnitt 2). Die Wahl liegt **nicht allein** hier: Der KI-Client prüft sie vor jedem Schritt selbst.
+- [ ] **MUSS** Overlay-Status ist `aktiv` (Ausnahme: Onboarding-Übung auf dem Übungsrepository; am Quellrepositorium des Frameworks gilt stattdessen `.koolie/core/governance/FRAMEWORK_DEV_PROFILE.md`, das **keine** technische Berechtigung erteilt und dessen Geltung der KI-Client nicht selbst feststellt).
+- [ ] **SOLL** Passender Skill als vorgesehener Weg gewählt (`/koolie-…`); ein anderer Weg MUSS im Ergebnisbericht benannt und begründet werden (`.koolie/core/framework/core/05-working-model.md` Abschnitt 1; `.koolie/core/prompts/README.md` Abschnitt 2). Die Wahl liegt **nicht allein** hier: Der KI-Client prüft sie vor jedem Schritt selbst.
 
 ### Sitzung und Werkzeug
 
-- [ ] **MUSS** Neue Sitzung für diese Aufgabe; rückfragender Standardmodus; weder der Modus ohne Rückfragen noch ein Modus mit selbsttätiger Übernahme aktiv (D-05; wie der Modus im Client heißt, nennt die Fähigkeitsmatrix des Client Packs).
+- [ ] **MUSS** Neue Sitzung für diese Aufgabe; rückfragender Standardmodus; weder der Modus ohne Rückfragen noch ein Modus mit selbsttätiger Übernahme aktiv (wie der Modus im Client heißt, nennt die Fähigkeitsmatrix des Client Packs).
 - [ ] **MUSS** Freigaben werden nur einmalig oder sitzungsweise erteilt; keine projekt- oder globalen Freigaben.
 - [ ] **SOLL** Arbeitsstand sauber (kein offener Diff fremder Arbeit im Arbeitsbereich).
 - [ ] **KANN** Bei M3/M4: `.koolie/core/checklists/03-before-code-change.md` bereitgelegt.

package/.koolie/core/checklists/02-privacy-context.md

@@ -37,7 +37,7 @@ Verhindert, dass unzulässige Inhalte (K3) oder nicht freigegebene Inhalte (K2)
 
 - [ ] **MUSS** Testdaten sind synthetisch und als solche gekennzeichnet oder nachweislich anonymisiert (`02-privacy.md` Abschnitt 3.6).
 - [ ] **MUSS** Keine Websuche und kein Abruf externer Seiten. Eine Freigabe je Domain
-      gibt es nicht (D-59); benötigte externe Quellen werden lokal bereitgestellt.
+      gibt es nicht; benötigte externe Quellen werden lokal bereitgestellt.
 - [ ] **MUSS** MCP-Werkzeuge nur, wenn der Server im Overlay (Abschnitt 13) freigegeben ist; bis dahin steht die Bestätigung vor einem MCP-Aufruf nicht auf `allow` (`02-privacy.md` Abschnitt 3.8).
 - [ ] **MUSS** Geteilter Kontext (Spaces, parallele Sitzungen) enthält nur Inhalte, die für alle beteiligten Aufgaben freigegeben sind.
 - [ ] **MUSS** Nutzerlokale Überschreibungen erweitern keine Kontextfreigaben (`02-privacy.md` Abschnitt 3.10).

package/.koolie/core/checklists/03-before-code-change.md

@@ -24,9 +24,9 @@ Sichert die Voraussetzungen aus Schritt 9–10 des Standardarbeitsablaufs, bevor
 
 ### Ist-Zustand und Auswirkungen
 
-- [ ] **MUSS** Relevanter Ist-Zustand ist analysiert; Befunde mit Fundstellen liegen vor (P4; Skills `fw-repo-analyze`, `fw-change-analyze`).
+- [ ] **MUSS** Relevanter Ist-Zustand ist analysiert; Befunde mit Fundstellen liegen vor (P4; Skills `koolie-repo-analyze`, `koolie-change-analyze`).
 - [ ] **MUSS** Verwender der zu ändernden Elemente sind ermittelt (Aufrufer, Konfigurationsreferenzen, Schnittstellen).
-- [ ] **MUSS** Tests des betroffenen Bereichs sind vor der Änderung ausgeführt; Ausgangsergebnis dokumentiert („grün vorher"; bei rotem Stand zuerst `fw-error-analyze`).
+- [ ] **MUSS** Tests des betroffenen Bereichs sind vor der Änderung ausgeführt; Ausgangsergebnis dokumentiert („grün vorher"; bei rotem Stand zuerst `koolie-error-analyze`).
 
 ### Arbeitsumgebung
 

package/.koolie/core/checklists/04-review-ai-code.md

@@ -13,7 +13,7 @@
 
 ## Zweck
 
-Operationalisiert die Prüfpunkte RV1–RV12 aus `.koolie/core/framework/core/07-review-rules.md` für die tägliche Anwendung. Ein KI-Befund (`fw-review-support`) ersetzt keine dieser Prüfungen.
+Operationalisiert die Prüfpunkte RV1–RV12 aus `.koolie/core/framework/core/07-review-rules.md` für die tägliche Anwendung. Ein KI-Befund (`koolie-review-support`) ersetzt keine dieser Prüfungen.
 
 ## Prüfpunkte
 

package/.koolie/core/checklists/05-testing.md

@@ -29,7 +29,7 @@ Sichert, dass Tests aus KI-Sitzungen aussagekräftig sind und geänderte Logik t
 ### Integrität der Testbasis
 
 - [ ] **MUSS** Keine bestehenden Tests geändert, abgeschwächt, ignoriert oder gelöscht, um einen Lauf „grün" zu machen; fachlich begründete Teständerungen sind im Plan ausgewiesen.
-- [ ] **MUSS** Kein Produktivcode geändert, nur damit ein Test besteht (M4-Grenze); aufgedeckte Fehler werden gemeldet (`fw-error-analyze`), nicht weggetestet.
+- [ ] **MUSS** Kein Produktivcode geändert, nur damit ein Test besteht (M4-Grenze); aufgedeckte Fehler werden gemeldet (`koolie-error-analyze`), nicht weggetestet.
 - [ ] **MUSS** Übersprungene oder als erwartet fehlschlagend markierte Tests sind gezählt und begründet.
 
 ### Ausführung und Lücken

package/.koolie/core/checklists/06-security.md

@@ -20,7 +20,7 @@ Operationalisiert das Sicherheitsmodell (`.koolie/core/framework/core/03-securit
 ### Einstufung und Prozess
 
 - [ ] **MUSS** Berührung von Authentifizierung, Autorisierung, Sitzungsverwaltung oder Kryptografie **in der Anwendungslogik** erkannt → Kontrollstufe hoch, Umsetzung nur mit Freigabe `<APPROVAL_ROLE>` und `<SECURITY_CONTACT>` (R3/R10).
-- [ ] **MUSS** Berührung tatsächlicher Berechtigungen oder einer Betriebs-, Infrastruktur- oder Sicherheitskonfiguration erkannt → **V6, nicht delegierbar, auch nicht nach Freigabe**; zulässig sind Analyse und Planvorschlag. Das gilt auch für Sicherheitskonfiguration als Code im Repositorium – ihr Inhalt **ist** die Berechtigung (D-53, Grenzfälle G-05 und G-06).
+- [ ] **MUSS** Berührung tatsächlicher Berechtigungen oder einer Betriebs-, Infrastruktur- oder Sicherheitskonfiguration erkannt → **V6, nicht delegierbar, auch nicht nach Freigabe**; zulässig sind Analyse und Planvorschlag. Das gilt auch für Sicherheitskonfiguration als Code im Repositorium – ihr Inhalt **ist** die Berechtigung (Grenzfälle G-05 und G-06).
 - [ ] **MUSS** Security Scans und statische Analyse der CI sind für den Änderungssatz erfolgreich (P6); Schwellenwerte unverändert (T6).
 
 ### Code-Prüfpunkte (soweit für die Änderung relevant)

package/.koolie/core/checklists/08-merge-request.md

@@ -20,7 +20,7 @@ Sichert Schritt 14 des Standardarbeitsablaufs: Übernahme ausschließlich über
 ### Vor dem Erstellen (Bearbeiterin oder Bearbeiter)
 
 - [ ] **MUSS** Der Merge Request verfolgt genau ein Ziel (Q1); vermischte Änderungen sind aufgeteilt.
-- [ ] **MUSS** Beschreibung liegt vor (Skill `fw-mr-description` oder manuell) und folgt `<MR_TEMPLATE_PATH>`; Ticket-Bezug hergestellt.
+- [ ] **MUSS** Beschreibung liegt vor (Skill `koolie-mr-description` oder manuell) und folgt `<MR_TEMPLATE_PATH>`; Ticket-Bezug hergestellt.
 - [ ] **MUSS** KI-Nutzungsvermerk enthalten (`.koolie/core/templates/MR_AI_DISCLOSURE.md`): Kurzform bei Stufe niedrig, Langform ab Stufe mittel (mit Plan-Referenz, Kontextliste, Befehlen, Abweichungen, Restrisiken).
 - [ ] **MUSS** Selbstreview nach `.koolie/core/checklists/04-review-ai-code.md` durchgeführt und im Vermerk bestätigt.
 - [ ] **MUSS** Lokale Prüfungen grün (`<LINT_COMMAND>`, `<TEST_COMMAND>`); Tests für geänderte Logik vorhanden (Q2, `.koolie/core/checklists/05-testing.md`).

package/.koolie/core/checklists/09-onboarding.md

@@ -29,9 +29,9 @@ Führt durch das Onboarding-Programm (`.koolie/core/onboarding/GUIDE.md`) bis zu
 - [ ] **MUSS** Modul 2 – Datenschutz und Kontextauswahl: Kontextklassen K0–K3 angewendet (Übung mit gemischten Quellen); Verhalten bei K3-Fund erklärt.
 - [ ] **MUSS** Modul 3 – Sichere Arbeitsweise: Standardarbeitsablauf, Betriebsmodi M1–M6, Kontrollstufen mit Maximumprinzip; Preflight-Check zweimal unter Anleitung durchgeführt.
 - [ ] **MUSS** Modul 4 – Repository- und Framework-Struktur: Wurzel-Anweisungsdatei, Laufzeitschicht, Overlay, Packs, Prioritätshierarchie am Repository gezeigt.
-- [ ] **MUSS** Modul 5 – Skills und Prompting: mindestens `fw-repo-analyze` (Ü1) und `fw-code-explain` ausgeführt; Prompting-Regeln und unzulässige Muster besprochen.
+- [ ] **MUSS** Modul 5 – Skills und Prompting: mindestens `koolie-repo-analyze` (Ü1) und `koolie-code-explain` ausgeführt; Prompting-Regeln und unzulässige Muster besprochen.
 - [ ] **MUSS** Modul 6 – Analyse bestehender Komponenten: eine Projektkomponente nur lesend (K1) mit Fundstellen erklärt.
-- [ ] **MUSS** Modul 7 – Ungefährliche Übungsaufgabe: kompletter Durchlauf mit `fw-plan`, `fw-change-small`, `fw-tests` (Ü3–Ü4) auf dem Übungsrepository.
+- [ ] **MUSS** Modul 7 – Ungefährliche Übungsaufgabe: kompletter Durchlauf mit `koolie-plan`, `koolie-change-small`, `koolie-tests` (Ü3–Ü4) auf dem Übungsrepository.
 - [ ] **MUSS** Modul 8 – Test und Review: eigene Übungsänderung mit `.koolie/core/checklists/04-review-ai-code.md` und `05-testing.md` geprüft; Ergebnisbericht und Nutzungsvermerk erstellt.
 - [ ] **MUSS** Modul 9 – Typische Fehlanwendungen: alle synthetischen Übungen aus `.koolie/core/onboarding/exercises/` bearbeitet, einschließlich der Negativübungen (Ü6: Injektion, K3-Köder, Scope-Falle).
 - [ ] **SOLL** Modul 9 – Katalog aus `.koolie/core/onboarding/GUIDE.md` durchgesprochen; eigene Beobachtungen ergänzt.