@renoxar/koolie 1.25.0

package/.koolie/core/build/doc/21-prompts.md

@@ -0,0 +1,53 @@
+# 21 Prompt-Bibliothek
+
+Die Prompt-Bibliothek liefert wiederverwendbare Vorlagen für die zwölf geforderten Aufgabentypen. Wo ein Skill existiert, hat der Skill Vorrang (technische Absicherung über `allowed-tools`/`permissions`); die Vorlagen dienen für Umgebungen ohne Skill oder als strukturierte Anweisung mit Zusatzkontext. Jede Vorlage folgt derselben Struktur: Zweck, einzusetzender und nicht einzusetzender Kontext, Eingabeparameter, wörtliche Prompt-Vorlage (mit den Pflichtelementen Ziel, Modus, Kontrollstufe, Scope, Kontext, Akzeptanzkriterien, Ausgabeformat, Rückfrageregel), erwartetes Ergebnis, Prüfschritte und typische Fehlanwendungen.
+
+{{EMBED-RAW:.koolie/core/prompts/README.md:1}}
+
+## 21.1 FW-PR-001 Codebasis verstehen
+
+{{EMBED:.koolie/core/prompts/01-understand-codebase.md}}
+
+## 21.2 FW-PR-002 Impact-Analyse
+
+{{EMBED:.koolie/core/prompts/02-impact-analysis.md}}
+
+## 21.3 FW-PR-003 Implementierungsplanung
+
+{{EMBED:.koolie/core/prompts/03-implementation-planning.md}}
+
+## 21.4 FW-PR-004 Codegenerierung
+
+{{EMBED:.koolie/core/prompts/04-code-generation.md}}
+
+## 21.5 FW-PR-005 Testgenerierung
+
+{{EMBED:.koolie/core/prompts/05-test-generation.md}}
+
+## 21.6 FW-PR-006 Refactoring
+
+{{EMBED:.koolie/core/prompts/06-refactoring.md}}
+
+## 21.7 FW-PR-007 Debugging
+
+{{EMBED:.koolie/core/prompts/07-debugging.md}}
+
+## 21.8 FW-PR-008 Security Review
+
+{{EMBED:.koolie/core/prompts/08-security-review.md}}
+
+## 21.9 FW-PR-009 Performance-Analyse
+
+{{EMBED:.koolie/core/prompts/09-performance-analysis.md}}
+
+## 21.10 FW-PR-010 Dokumentation
+
+{{EMBED:.koolie/core/prompts/10-documentation.md}}
+
+## 21.11 FW-PR-011 Review eines Merge Requests
+
+{{EMBED:.koolie/core/prompts/11-merge-request-review.md}}
+
+## 21.12 FW-PR-012 Technische Schulung eines neuen Entwicklers
+
+{{EMBED:.koolie/core/prompts/12-developer-training.md}}

package/.koolie/core/build/doc/22-checklisten.md

@@ -0,0 +1,49 @@
+# 22 Checklisten
+
+Elf Checklisten operationalisieren die Kernmodule für konkrete Momente im Arbeitsablauf – vom Preflight vor jeder Aufgabe bis zum Framework-Release. Prüfpunkte tragen die Verbindlichkeit MUSS oder SOLL; unerfüllte MUSS-Punkte stoppen den jeweiligen Schritt. Nachweise entstehen an den je Liste benannten Orten (Ergebnisbericht, Merge Request, Protokolle), nicht als Kopien im Repository.
+
+{{EMBED-RAW:.koolie/core/checklists/README.md:1}}
+
+## 22.1 FW-CL-01 Preflight-Check vor jeder KI-Aufgabe
+
+{{EMBED-RAW:.koolie/core/checklists/01-preflight.md:2}}
+
+## 22.2 FW-CL-02 Datenschutz- und Kontextcheck
+
+{{EMBED-RAW:.koolie/core/checklists/02-privacy-context.md:2}}
+
+## 22.3 FW-CL-03 Vor Codeänderungen
+
+{{EMBED-RAW:.koolie/core/checklists/03-before-code-change.md:2}}
+
+## 22.4 FW-CL-04 Review KI-generierten Codes
+
+{{EMBED-RAW:.koolie/core/checklists/04-review-ai-code.md:2}}
+
+## 22.5 FW-CL-05 Tests
+
+{{EMBED-RAW:.koolie/core/checklists/05-testing.md:2}}
+
+## 22.6 FW-CL-06 Security
+
+{{EMBED-RAW:.koolie/core/checklists/06-security.md:2}}
+
+## 22.7 FW-CL-07 Neue Abhängigkeiten
+
+{{EMBED-RAW:.koolie/core/checklists/07-new-dependency.md:2}}
+
+## 22.8 FW-CL-08 Merge Request
+
+{{EMBED-RAW:.koolie/core/checklists/08-merge-request.md:2}}
+
+## 22.9 FW-CL-09 Onboarding
+
+{{EMBED-RAW:.koolie/core/checklists/09-onboarding.md:2}}
+
+## 22.10 FW-CL-10 Projektübernahme
+
+{{EMBED-RAW:.koolie/core/checklists/10-project-adoption.md:2}}
+
+## 22.11 FW-CL-11 Framework-Release
+
+{{EMBED-RAW:.koolie/core/checklists/11-framework-release.md:2}}

package/.koolie/core/build/doc/23-entscheidungsbaeume.md

@@ -0,0 +1,29 @@
+# 23 Entscheidungsbäume
+
+Sechs Entscheidungsbäume beantworten die wiederkehrenden Weichenfragen des Alltags. Maßgeblich ist jeweils die normative Textbeschreibung; die Mermaid-Diagramme veranschaulichen sie und sind syntaktisch validiert (Prüflauf mit dem Mermaid-Kommandozeilenwerkzeug; Teil der Framework-Validierung).
+
+{{EMBED-RAW:.koolie/core/decision-trees/README.md:1}}
+
+## 23.1 Baum 1 – Darf dieser Inhalt als Kontext verwendet werden?
+
+{{EMBED-RAW:.koolie/core/decision-trees/01-context-allowed.md:2}}
+
+## 23.2 Baum 2 – Darf der KI-Client diese Aufgabe bearbeiten?
+
+{{EMBED-RAW:.koolie/core/decision-trees/02-may-ai-do-task.md:2}}
+
+## 23.3 Baum 3 – Darf der Assistent nur analysieren oder auch ändern?
+
+{{EMBED-RAW:.koolie/core/decision-trees/03-analyze-or-modify.md:2}}
+
+## 23.4 Baum 4 – Welche menschliche Prüfung ist erforderlich?
+
+{{EMBED-RAW:.koolie/core/decision-trees/04-required-review.md:2}}
+
+## 23.5 Baum 5 – Wann muss abgebrochen oder eskaliert werden?
+
+{{EMBED-RAW:.koolie/core/decision-trees/05-stop-or-escalate.md:2}}
+
+## 23.6 Baum 6 – Wohin gehört eine Regel?
+
+{{EMBED-RAW:.koolie/core/decision-trees/06-rule-placement.md:2}}

package/.koolie/core/build/doc/24-onboarding.md

@@ -0,0 +1,33 @@
+# 24 Entwickler-Onboarding
+
+Das Onboarding-Konzept führt neue Entwicklerinnen und Entwickler in zehn Modulen von den Grundlagen (Möglichkeiten und Grenzen, Datenschutz und Kontextauswahl, sichere Arbeitsweise, Framework-Struktur) über Skills, Prompting und die Analyse bestehender Komponenten bis zur begleiteten Übungsaufgabe, Test und Review, typischen Fehlanwendungen und dem dokumentierten Abschluss. Es umfasst alle geforderten Bestandteile: kompakter Quick-Start, ausführlicher Leitfaden mit Lernzielen und Voraussetzungen, Checkliste für Mentorinnen, Mentoren und Reviewer, synthetische Übungsaufgaben einschließlich Negativübungen (Köder), Wissenstest als Selbstkontrollformat, Kriterien für die erfolgreiche Einarbeitung und ein einseitiges Nachschlagewerk. Leitgedanke, ausdrücklich vermittelt: Souveräne KI-Nutzung bemisst sich an angemessener Aufgabenabgrenzung, kontrollierter Kontextbereitstellung und belastbarer Prüfung – nicht an der Menge delegierter Aufgaben. Bis zur dokumentierten Freigabe wird nur begleitet gearbeitet; der Wissenstest dient der Selbstkontrolle und keiner Personalbeurteilung.
+
+## 24.1 Quick-Start
+
+{{EMBED-RAW:.koolie/core/onboarding/QUICKSTART.md:2}}
+
+## 24.2 Onboarding-Leitfaden
+
+{{EMBED-RAW:.koolie/core/onboarding/GUIDE.md:2}}
+
+## 24.3 Checkliste für Mentorinnen, Mentoren und Reviewer
+
+{{EMBED-RAW:.koolie/core/onboarding/MENTOR_CHECKLIST.md:2}}
+
+## 24.4 Übungsrepository und Übungsaufgaben (synthetisch)
+
+{{EMBED-RAW:.koolie/core/onboarding/exercises/README.md:2}}
+
+{{EMBED-RAW:.koolie/core/onboarding/exercises/EXERCISES.md:2}}
+
+## 24.5 Wissenstest zur Selbstkontrolle
+
+{{EMBED-RAW:.koolie/core/onboarding/KNOWLEDGE_CHECK.md:2}}
+
+## 24.6 Kriterien für die erfolgreiche Einarbeitung
+
+{{EMBED-RAW:.koolie/core/onboarding/COMPLETION_CRITERIA.md:2}}
+
+## 24.7 Nachschlagewerk
+
+{{EMBED-RAW:.koolie/core/onboarding/REFERENCE.md:2}}

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

@@ -0,0 +1,35 @@
+# 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.
+
+## 25.1 Prioritätshierarchie mit Widerspruchsprüfung
+
+{{EMBED-RAW:.koolie/core/governance/PRIORITY_HIERARCHY.md:2}}
+
+## 25.2 RACI-Vorlage
+
+{{EMBED-RAW:.koolie/core/governance/RACI.md:2}}
+
+## 25.3 Review-Zyklus, Versionierung, Release und Produktbeobachtung
+
+{{EMBED-RAW:.koolie/core/governance/RELEASE_PROCESS.md:2}}
+
+## 25.4 Änderungsanträge
+
+{{EMBED:.koolie/core/governance/CHANGE_REQUEST_TEMPLATE.md}}
+
+## 25.5 Ausnahmeprozess
+
+{{EMBED-RAW:.koolie/core/governance/EXCEPTION_PROCESS.md:2}}
+
+## 25.6 Feedbackprozess
+
+{{EMBED-RAW:.koolie/core/governance/FEEDBACK_PROCESS.md:2}}
+
+## 25.7 Behandlung von Sicherheits- und Datenschutzvorfällen
+
+{{EMBED-RAW:.koolie/core/governance/INCIDENT_HANDLING.md:2}}
+
+## 25.8 Ownership
+
+{{EMBED-RAW:.koolie/core/OWNERS.md:2}}

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

@@ -0,0 +1,9 @@
+# 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.
+
+**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`.
+
+**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.
+
+{{EMBED-RAW:.koolie/core/tests/TEST_CATALOG.md:1}}

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

@@ -0,0 +1,13 @@
+# 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.
+
+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.
+
+## 27.1 Pilotkonzept
+
+{{EMBED-RAW:.koolie/core/pilot/PILOT_CONCEPT.md:2}}
+
+## 27.2 Metriken
+
+{{EMBED-RAW:.koolie/core/pilot/METRICS.md:2}}

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

@@ -0,0 +1,5 @@
+# 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).
+
+{{EMBED-RAW:.koolie/core/docs/ADOPTION_GUIDE.md:1}}

package/.koolie/core/build/doc/29-grenzen.md

@@ -0,0 +1,87 @@
+# 29 Bekannte Grenzen und offene Entscheidungen
+
+## 29.1 Bekannte Grenzen dieser Erstfassung
+
+> **Dieser Abschnitt beschreibt den Stand der Erstfassung vom 2026-09-01 und wird nicht
+> fortgeschrieben.** Er bleibt als Zeitdokument erhalten; mehrere Aussagen darin gelten
+> **nicht mehr**. Der aktuelle Stand steht in `.koolie/core/docs/ROADMAP.md`, Abschnitt
+> „Stand nach Release …", und im `CHANGELOG.md`. Die wichtigsten Änderungen, mit Release
+> und Beleg:
+>
+> - **Die Installationsvalidierung ist erfolgt und abgeschlossen.** AP2 ist für beide
+>   Client Packs gefahren (2026-09-10 und 2026-09-11) und für `devin-desktop` mit
+>   Release 0.86.0 **zu Ende geführt** – 70 Sitzungsläufe an einer Installation. Neun
+>   Matrixzeilen sind dort beobachtet, genau eine sagt noch `BELEG OFFEN`. Die Protokolle
+>   liegen unter `.koolie/core/tests/protocols/`.
+> - **Der Schutz-Hook läuft nicht mehr fail-open.** Seit 0.24.0 blockiert er eine Eingabe,
+>   die er nicht lesen kann, sofern das Client Pack das Eingabeschema als bestätigt führt
+>   (`hook_fail_closed`, D-31). Beide Manifeste führen es.
+> - **Kein dynamischer Test steht mehr auf `offen`** (seit Release 1.14.2): `SK-005-P01` trägt,
+>   seit das Client Pack `claude-code` die Attributionsvorgabe des Clients für Commits abschaltet
+>   (D-433, `K-171`). Die 38 Zellen des zentralen Katalogs und alle 87 Zellen der dreizehn
+>   Testblätter tragen `bestanden`, der Nachweis je Zelle mit Protokoll und Client Pack – gemessen
+>   ist jede Zelle nur mit dem Pack, das sie nennt.
+> - **Die Attributionsvorgabe ist ein Standard, keine Schranke, und erreicht kein bestehendes
+>   Projekt von selbst** (seit Release 1.14.2, D-433, D-434): `.claude/settings.local.json` holt sie
+>   zurück; `install.py --update` meldet den fehlenden Schlüssel, schreibt ihn aber nicht. Ob die
+>   übrigen Clients einen Vermerk vorgeben, ist nicht erhoben (`K-173`).
+> - **Englisch gibt es nur für den Einstieg** (seit Release 1.15.0, D-437): README und Quickstart des
+>   Framework-Repositoriums haben eine englische Fassung; die übrige Dokumentation, die Laufzeitregeln und
+>   die Meldungen der Werkzeuge sind deutsch. Die englischen Fassungen prüft eine Maschine nur in ihrer
+>   Form, nicht in ihrer Deckung mit dem deutschen Original.
+> - **Die Regelablage von `devin-desktop` lädt nur, weil das Pack Windsurf-Quellen zulässt**
+>   (seit Release 1.12.1, D-411): Mit `read_config_from.windsurf: false` lädt der Client die
+>   eigene Regelablage nicht – gegen seine Dokumentation (`K-156`). Mit `true` erreicht auch eine
+>   Regel aus dem Benutzerprofil jede Sitzung (D-290); `install.py` meldet sie, wenn sie belegt ist,
+>   und hält sie nicht fern. Eine Regel mit dem Auslöser `glob` lädt gemessen nicht (`K-161`).
+> - **Bestehende Installationen von `devin-desktop` und `openai-codex` heben ihre Berechtigungsdatei
+>   nicht selbst** (seit Release 1.12.1): `install.py --update` fasst sie nicht an. Die Werte
+>   `read_config_from` (devin) und die Tabelle `:workspace_roots` (codex, `K-157`, D-412) zieht der
+>   Overlay Owner nach; Prüfung 22 meldet eine abweichende Importsteuerung.
+> - **Die Schutzschicht wirkt nur für eine Sitzung, die im Verzeichnis der Installation startet**
+>   (seit Release 1.12.0 gemessen, D-408). Startet sie in einem Repository darunter, fallen
+>   Berechtigungen und Hooks bei allen drei Packs still aus (Kap. 28, Abschnitt 4).
+> - **Die Berechtigungsschicht vergleicht die Schreibweise, der Schutz-Hook die Pfadidentität**
+>   (seit Release 1.20.1, D-491, D-492). Wo beide Schichten verschieden entscheiden, gilt die
+>   Semantik des Hooks: Er löst jede Pfadangabe auf, vergleicht ohne Rücksicht auf Groß- und
+>   Kleinschreibung und liest `/c/…` unter Windows in beiden Lesarten. Die Berechtigungsschicht
+>   gehört dem Client – bei `devin-desktop` unterscheidet sie Groß- und Kleinschreibung (D-277),
+>   bei `claude-code` nicht. Eine Zusage, die nur die Regel trägt, gilt nur in der Schreibweise
+>   des Musters.
+> - **Die Modusgrenzen gelten normativ, M1 bis M5 lassen sich binden** (M1 und M2 seit Release
+>   1.20.2, D-501; M3 bis M5 seit Release 1.23.0, D-523). Bindet der Mensch einen Modus im
+>   eigenen Terminal (`mandat.py modus`), sperrt der Schutz-Hook jedes Schreibwerkzeug (M1), jedes
+>   außerhalb der Plan-Ablage (M2) oder jedes außerhalb der Pfadliste des Modus (M3
+>   `<ALLOWED_PATHS>`, M4 `<TEST_PATHS>`, M5 `<DOC_PATHS>`, nie in `<READ_ONLY_PATHS>`). Die
+>   Pfadliste kopiert `mandat.py` beim Binden aus dem Overlay; ändert es sich, gilt das erst nach
+>   neuem Binden. Ein Shell-Befehl, der schreibt, entgeht der Bindung wie dem Kernschutz (D-30),
+>   und Befehle bindet sie nicht – die freigegebenen Befehle von M3 und M4 trägt weiter die
+>   Regelschicht.
+> - **Wo der Schutz-Hook nicht läuft, trägt die Rückfrage – bis ein Modus sie abschaltet**
+>   (seit Release 1.20.2, D-502). Bei `kiro` laufen Hooks nur interaktiv; ohne Rückfragekanal
+>   weist die Rückfrageregel einen Schreibversuch ins Overlay ab, mit `--trust-all-tools` geht
+>   er durch. Der Modus ist nach D-05 untersagt, und das ist die ganze Sicherung.
+> - **Kein Modulträger steht mehr auf `entwurf`** (seit Release 0.53.0), und **kein
+>   Decision Record mehr auf `entschieden (Vorschlag)`** (seit Release 0.49.0).
+> - **Die verbindliche Zielversion beider Packs ist festgelegt** (D-112). Sie ist der
+>   *geprüfte* Geltungsbereich und nicht der aktuelle Produktstand; den Abstand zwischen
+>   beiden weist das jeweilige Pack aus.
+>
+> Berichtigt mit `CR-2026-051` (Befund **B12** des unabhängigen Reviews vom 2026-09-12),
+> fortgeschrieben mit `CR-2026-124` (Release 0.89.0).
+
+**Keine Installationsvalidierung.** Kein Mechanismus wurde bislang in einer Zielinstallation des KI-Clients ausgeführt. Die Referenzimplementierung beruht auf der offiziellen Dokumentation (Quellen in Anhang 31.4) und ist entsprechend gekennzeichnet; die Validierung ist als frühes Arbeitspaket AP2 mit Protokollpflicht eingeplant. Bis dahin gilt insbesondere: Der Schutz-Hook läuft fail-open (dokumentierte Entscheidung im Skript), die Berechtigungsvorlage ist gegen das dokumentierte, nicht gegen das real beobachtete Schema geschrieben, und alle dynamischen Tests des Testkatalogs stehen auf `offen`.
+
+**Produktdynamik.** Devin Desktop entwickelt sich schnell (Rebranding Juni 2026, seither mehrere Releases). Aussagen mit Belegstatus `[DOK]` sind Momentaufnahmen des recherchierten Stands; die Governance begegnet dem mit Produktbeobachtung, Aktualitätstests (Klasse AK) und Hotfix-Pfad – ersetzt aber nicht die Prüfung vor der Einführung.
+
+**Wirksamkeitsgrenzen der Kontrollen.** Regeln in der Wurzel-Anweisungsdatei und in der Regelablage wirken über das Befolgungsverhalten des Modells und sind keine harte Durchsetzung; harte Grenzen ziehen nur Berechtigungen (`deny`), Hooks und organisationsweite Einstellungen. Das Framework kombiniert deshalb immer Verhaltensregel und technische Sperre – wo eine technische Sperre fehlt (zum Beispiel „nur Testpfade" in M4 bei gleichzeitig nötigem `edit`-Werkzeug), ist das ausgewiesen und durch Hook plus Review kompensiert. Ebenso bleibt Prompt Injection ein Restrisiko, das durch Datenbehandlungsregel, Permission-Modus Normal, Verbotslisten und Tests begrenzt, aber nicht eliminiert wird.
+
+**Bewusste Auslassungen.** Kein konkretes Technology Pack (entsteht projektbezogen, AP4); nur ein Role Pack als Referenz; Cloud-Sitzungen, Läufe ohne beobachtende Person und Fremdagenten standardmäßig deaktiviert (D-10, D-386); keine rechtlichen Bewertungen (N3); das Übungsrepository wird je Projekt im eigenen `<TECH_STACK>` erzeugt, damit Befehle real laufen.
+
+**Methodische Grenzen.** Die Pilotmetriken messen Signale, keine Kausalitäten; die Selbsteinschätzungsanteile sind subjektiv; Vergleichbarkeit hängt an der Etikettierungsdisziplin. Das Framework erhöht zudem anfangs den Prozessaufwand (Preflight, Berichte, Vermerke) – der Pilot prüft ausdrücklich auch, ob dieser Aufwand im Verhältnis zum Nutzen steht.
+
+## 29.2 Offene Entscheidungen
+
+Alle offenen Punkte sind zentral im Decision Log geführt. **Gezählt am 2026-09-22: 312 Decision Records von D-01 bis D-312, lückenlos; 102 Klärungspunkte von K-01 bis K-104 – zwei Nummern fehlen und sind keine Lücke: die eine ist `K-99`, eine belegte synthetische Kennung des Prüfapparats, die andere die **zusammengesetzte** Kennung der Sonde zu Prüfung 50 – sie steht ausdrücklich **nicht** in der belegten Menge, weil sie gemeldet werden **soll**, und sie darf deshalb nirgends im Kern ausgeschrieben stehen, auch hier nicht; dazu fünf Annahmen A-01 bis A-05.** *(Diese Zeile ist eine **datierte** Angabe und wandert nicht mit – eine datierte Zahl veraltet nicht, eine Zahl in der Gegenwartsform schon, D-318. Bis 0.89.0 stand hier „308", „101" und „K-103", und alle drei waren für ihr eigenes Datum bereits falsch.)* Kein Record steht mehr auf `entschieden (Vorschlag)` – das ist Kriterium 4 der 1.0.0-Definition, erfüllt seit Release 0.49.0. **Die Vollständigkeit beider Register ist maschinell gedeckt:** Prüfung 50 und 58 verlangen, dass jede im Kern genannte Kennung `K-NN` beziehungsweise `D-NN` hier als Zeile steht – zweimal hat gefehlt, was anderswo längst zitiert wurde. Die entscheidungsreife Kurzliste für ein aufnehmendes Projekt steht im Abschlussteil dieses Dokuments („Offene Entscheidungen"). Das vollständige Register:
+
+{{EMBED-RAW:.koolie/core/governance/DECISION_LOG.md:1}}

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

@@ -0,0 +1,5 @@
+# 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 …".
+
+{{EMBED-RAW:.koolie/core/docs/ROADMAP.md:1}}

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

@@ -0,0 +1,151 @@
+# 31 Anhänge
+
+## 31.1 Inventar des Referenz-Repositorys
+
+Gezählt beim Bau dieses Dokuments aus dem Versionsbestand von Release {{VERSION}}: **{{ZAHL:*}} versionierte Dateien im Kern**. Die vollständige Struktur mit Erläuterung steht in Kap. 15.2; hier nur die Größenordnung je Bereich.
+
+| Bereich | Dateien | Inhalt |
+|---|---|---|
+| direkt im Kernverzeichnis | {{ZAHL:.}} | `install.py`, `install_dialog.py`, `clientmap.py`, `VERSION`, `CHANGELOG.md`, `OWNERS.md`, Lizenz und Lizenzhinweis |
+| `clients/` | {{ZAHL:clients/}} | Abbildungsschicht: {{ZAHL:clients/*/manifest.json}} Client Packs, Regeln der Schicht, Vorlage für ein weiteres Pack |
+| `framework/` | {{ZAHL:framework/}} | {{ZAHL:framework/core/*.md}} Core-Module, Laufzeitfassung, {{ZAHL:framework/skills/*/SKILL.md}} Referenz-Skills, Role Packs, Tech-Pack-Vorlage, Organisationsvorgaben, Overlay-Muster |
+| `templates/` | {{ZAHL:templates/}} | Project-Overlay-Saat, Regelvorlagen, Skill-Vorlage |
+| `build/` | {{ZAHL:build/}} | **{{ZAHL:build/doc/*.md}} Kapitelquellen**, Assemblierungs- und DOCX-Skript, Referenzdokument, README |
+| `prompts/` · `checklists/` · `decision-trees/` | {{ZAHL:prompts/,checklists/,decision-trees/}} | {{ZAHL:prompts/[0-9]*.md}} Prompt-Vorlagen, {{ZAHL:checklists/[0-9]*.md}} Checklisten, {{ZAHL:decision-trees/[0-9]*.md}} Entscheidungsbäume, je README |
+| `governance/` | {{ZAHL:governance/}} | Decision Log, RACI, Hierarchie, Prozesse – und **{{ZAHL:governance/change-requests/}} Änderungsanträge** |
+| `tests/` | {{ZAHL:tests/}} | Testkatalog, Prüf- und Hook-Skripte, **{{ZAHL:tests/protocols/}} Protokolle**, Erhebungsapparat |
+| `onboarding/` · `examples/` · `pilot/` · `docs/` | {{ZAHL:onboarding/,examples/,pilot/,docs/}} | Onboarding-Paket, synthetische Beispiele, Pilotkonzept, Leitfäden und Register |
+
+⚠️ **Die größten Posten sind Aufzeichnung, nicht Regelwerk.** {{ZAHL:governance/change-requests/,tests/protocols/,tests/erhebungen/,build/}} der {{ZAHL:*}} Dateien bilden die Nachweisschicht – Änderungsanträge, Protokolle, Erhebungen und `build/`. Sie werden mit dem Kern ausgeliefert, weil ein Beleg ohne seinen Träger keiner ist; für die **Nutzung** des Frameworks braucht sie niemand. Ein Projekt kann sie weglassen: `install.py --target <projekt> --lieferumfang nutzung` liefert den Kern ohne sie (D-367).
+
+**Was daraus in ein Projekt installiert wird:** **{{ZAHL:installiert}} Dateien** beim Client Pack dieses Baus (`{{CLIENT}}`) – Wurzel-Anweisungsdatei, Laufzeitschicht und Project Overlay, gezählt an derselben Referenzinstallation, aus der die eingebetteten Laufzeitdateien dieses Dokuments stammen. Der Kern selbst kommt hinzu.
+
+Die Zahlen dieses Abschnitts setzt `assemble.py` beim Bau ein (D-377); in der Kapitelquelle stehen Direktiven statt Zahlen.
+
+## 31.2 Laufzeitglossar
+
+Der Kern nennt die Bestandteile der Laufzeitschicht mit Begriffen, nicht mit Pfaden. Die Abbildung auf die Pfade eines konkreten Client Packs steht hier:
+
+{{EMBED-RAW:.koolie/core/docs/RUNTIME_GLOSSARY.md:2}}
+## 31.3 Platzhalterregister
+
+{{EMBED-RAW:.koolie/core/docs/PLACEHOLDER_REGISTRY.md:2}}
+
+## 31.4 Quellen der Produktdokumentation und Belegzuordnung
+
+Die Quellen belegen die als `[DOK]` gekennzeichneten Aussagen; der Framework Owner hält diese Liste im Rahmen der Produktbeobachtung aktuell (FW-AK-01).
+
+Sie ist **je Client Pack** geführt, weil eine Aussage über einen Client an dessen Dokumentation hängt und an keiner anderen und weil die Listen verschiedene Recherchestände haben. Die Kennungen tragen das Präfix des Packs (`QD-` für `devin-desktop`, `QC-` für `claude-code`, `QK-` für `kiro`, `QU-` für `cursor`), damit sie nicht mit den Qualitätsregeln des Frameworks (`Q1`, `Q8` …) verwechselt werden. Das dritte Pack, `openai-codex`, führt keine `[DOK]`-Zeile – seine Belegspalte nennt Messungen – und hat deshalb keine Liste in diesem Anhang; `FW-AK-01` ist für dieses Pack noch nicht gefahren (Kopf des Packs, Zeile „Stand der Produktbeobachtung").
+
+Die **maßgebliche Zuordnung** steht in der Fähigkeitsmatrix des jeweiligen Packs (Kap. 15.1 beziehungsweise Kap. 7a): Dort nennt der Belegkopf jeder mit `[DOK]` belegten Zeile die Quellenkennung dieser Liste, Verweisbelege (*„wie B3"*) aufgelöst; Prüfung 73 setzt das durch (D-263 bis D-266). Die Kennung ist die verbindliche Form, weil allein sie gegen diese Liste gehalten werden kann; ein Seitenpfad darf danebenstehen. Nachgetragene Zuordnungen tragen den Zusatz `(Zuordnung K-62)`: gewonnen aus dem Bestand am 22.09.2026, nicht aus einem zweiten Abruf – der Recherchestand der Seiten bleibt der vom 18.09.2026 (D-263). Diese Liste sagt, welche Seite wofür herangezogen wurde und **wann sie abgerufen worden ist** – die Angabe, die eine Wiederholungsprüfung braucht.
+
+⚠️ **Eine Zeile ist ausdrücklich ohne Zuordnung:** `M3` des Packs `claude-code` („Freigabe auf die Sitzung begrenzbar") – keine der sechs Seiten `QC-1` bis `QC-6` führt die Sitzungs-Grant-Stufen, während sie beim Schwesterpack in `QD-11` stehen. Die Zeile sagt `QUELLE NICHT ZUGEORDNET`, und Prüfung 73 führt die zugelassenen Lücken als deklarierte Menge; eine geratene Zuordnung sähe wie ein Beleg aus (D-156). Diese Zeile ist der erste gezielte Auftrag des nächsten Durchgangs von `FW-AK-01`.
+
+### 31.4.1 Client Pack `devin-desktop`
+
+Recherchestand: 01.–02.09.2026, gegen Devin Desktop 3.8.20 (QD-4). Ergänzt am 11.09.2026 gegen Devin Desktop 3.9.19 / CLI 3000.10.21 (Erhebungen zu K-21 bis K-27). Vollständig abgeglichen am 18.09.2026 gegen den Produktstand 3.10.31 (`FW-AK-01`, `.koolie/core/tests/protocols/2026-09-18-FW-AK-01.md`). Neun Zeilen der Fähigkeitsmatrix sind zusätzlich in einer Sitzung an einer laufenden Installation beobachtet (H1, H2, R5, R6, S5, S3, B3, B10 und A1); bei S3 und B10 hat die Messung die zuvor vorgesehene Einstufung widerlegt, und die Matrix führt das in den Zeilen. Eine Zeile sagt dauerhaft `BELEG OFFEN`: `X2` – was ein Client indexiert und wohin er es gibt, ist von außen nicht zu beobachten (D-292).
+
+⚠️ **Drei Quellen belegen einen Agenten, den der Hersteller entfernt hat.** Der Changelog sagt zu 3.9.19 (08.09.2026): *„Cascade has been removed. Devin Local is now the only agent available in Devin Desktop."* QD-5, QD-7 und QD-8 liegen unter `desktop/cascade/` und sprechen weiter im Präsens von diesem Agenten; QD-2 sagt noch, er bleibe *„through July"* verfügbar. Die Seiten sind erreichbar und inhaltlich unverändert – veraltet ist, wofür sie taugen. Deshalb stützt sich Zeile R1 des Packs auf QD-6 statt auf QD-5, und die Zeichenzahlen aus QD-7 gelten als Vorgabe des Frameworks und nicht als Produkteigenschaft (Zeile R4).
+
+⚠️ **Eine Aussage der Liste ist innerhalb der verbindlichen Zielspanne des Packs widerlegt.** QD-12 sagt *„Organization-level (enterprise) settings can never be overridden by project or user config"*; der Changelog weist zu 3.10.31 (16.09.2026) aus: *„Restricted Mode blocks restricted workspace settings written in nested object form, not just the dotted form (CVE-2026-81376)."* Bis einschließlich 3.10.27 hing die Durchsetzung also an der **Schreibweise**. Die Zielspanne `3.9.x` liegt vollständig davor; Zeile M2 des Packs trägt den Nachtrag.
+
+| Nr. | Quelle | Belegt im Framework insbesondere |
+|---|---|---|
+| QD-1 | devin.ai/blog/windsurf-is-now-devin-desktop | Rebranding zum 02.06.2026; Devin Local ersetzt Cascade; Übergangsfrist für Cascade; Agent Command Center, Spaces, ACP |
+| QD-2 | docs.devin.ai/desktop/devin-desktop-faq | `.devin/` als Primär-, `.windsurf/` als Legacy-Pfad; `.windsurfrules`; Systempfade für organisationsweite Regeln; Legacy-MCP-Pfad; Plankontinuität |
+| QD-3 | docs.devin.ai/desktop/devin-local | Modi Normal/Plan/Ask; Berechtigungsmodell deny/ask/allow mit Geltungsbereichen; MCP-Bestätigung als Standard; Subagenten (Preview) und Quick Review; keine Memories/Workflows in Devin Local; Migrationsassistent; Enterprise-Einstellungen (Sandbox-Erzwingung, Domain-Listen); Konfigurationspfade |
+| QD-4 | docs.devin.ai/desktop/changelog | Version 3.8.20 vom 21.08.2026; Komposition der Berechtigungsebenen mit deny-Vorrang; `sandbox.excluded`; persistente Plan-Dateien; Subagenten-Dateiformen; Skill-Berechtigungen bei Auto-Genehmigungen |
+| QD-5 | docs.devin.ai/desktop/cascade/agents-md | AGENTS.md im Root always-on; Unterverzeichnisse als automatische Glob-Regeln; Einspeisung in die Regel-Engine; Namensvarianten |
+| QD-6 | docs.devin.ai/cli/extensibility/rules | Regeldateien und -orte (AGENTS.md, AGENTS.local.md, `.devin/rules/*.md`, global), Frontmatter `description`/`trigger`/`globs` mit Werten, Präzedenzen, Kompatibilitätspfade |
+| QD-7 | docs.devin.ai/desktop/cascade/memories | Aktivierungsmodi der Regeln; Zeichenlimits 6.000/12.000 (Cascade-Kontext); Memories nur für Cascade |
+| QD-8 | docs.devin.ai/desktop/cascade/workflows | Workflows nur für Cascade; Migration zu Skills; Limits |
+| QD-9 | docs.devin.ai/product-guides/skills | SKILL.md-Format; Suchpfade einschließlich `.agents/skills/` (empfohlen) und `.devin/skills/`; `triggers`; `@skills:`-Erwähnung; Argument-Substitution; eine aktive Skill-Grenze |
+| QD-10 | docs.devin.ai/cli/extensibility/skills/creating-skills | Projekt- und globale Skill-Pfade; Frontmatter-Felder inkl. `allowed-tools`, `permissions` (additiv), `argument-hint`, `model`, `subagent`, `agent`; Aufruf `/skill-name` |
+| QD-11 | docs.devin.ai/cli/reference/permissions | Matcher `Read()`, `Write()`, `Exec()`, `Fetch()`, Tool- und MCP-Matcher; deny > ask > allow; Permission-Modi; Ebenen-Präzedenz; Sitzungs-Grant-Stufen |
+| QD-12 | docs.devin.ai/cli/extensibility/configuration | `config.json`-Scopes und -Schlüssel; `mcp_config.json`/`.local`; `read_config_from`; Enterprise unüberschreibbar |
+| QD-13 | docs.devin.ai/cli/extensibility/hooks/overview | `hooks.v1.json`; Ereignisse; Blockierung per Exit-Code 2/`decision: block`; `additionalContext`; `DEVIN_PROJECT_DIR` |
+| QD-14 | docs.devin.ai/de/cli/subagents | Subagent-Dateiformen und Frontmatter; eingebaute Profile; Vordergrund-/Hintergrundrechte |
+| QD-15 | docs.devin.ai/cli/sandbox | Sandbox-Ableitung aus Berechtigungen; Domainfilter und Modi; `sandbox.excluded`; Plattformgrenzen (kein Windows); Instabilität des Netzfilters |
+| QD-16 | docs.devin.ai/cli/enterprise/team-settings | Team-Kontrollen: Modell-Allowlist, Websuche standardmäßig aus, MCP-Kontrollen und Registry-Erzwingung, unüberschreibbare Terminal-Permissions, Sandbox-Erzwingung, Attribution-Filter |
+| QD-17 | docs.devin.ai/admin/security | Training-Opt-out auf kostenpflichtigen Plänen; Zero Data Retention nach Opt-out; Teams-Opt-out nur durch Admin; Enterprise nur mit schriftlicher Zustimmung; SOC 2 Type II; Verschlüsselung |
+
+### 31.4.2 Client Pack `claude-code`
+
+Recherchestand: 10.09.2026, gegen Clientversion 2.1.267. Erhoben im Rahmen von AP2 (`.koolie/core/tests/protocols/2026-09-10-AP2-claude-code.md`); die Seitenangaben sind gegenüber dem Protokoll um die genauen Pfade ergänzt. **Abgeglichen am 18.09.2026 gegen 2.1.275**, dazu der Changelog der Stände 2.1.268 bis 2.1.275 (`FW-AK-01`, `.koolie/core/tests/protocols/2026-09-18-FW-AK-01.md`).
+
+Die Liste führt auch die Hook-Seite `QC-6`, weil das Pack drei Hook-Zusagen trägt (H1, H2, H3) – so wie das Schwesterpack für denselben Gegenstand QD-13 führt (D-159).
+
+| Nr. | Quelle | Belegt im Framework insbesondere |
+|---|---|---|
+| QC-1 | code.claude.com/docs/en/memory | Regelablage `.claude/rules/*.md`, rekursiv gefunden; Frontmatter-Feld `paths` mit Glob-Mustern, mehreren Mustern und Klammer-Expansion samt Budget (1.000 expandierte Muster, 4 MiB); eine Regel **ohne** `paths` lädt unbedingt und ohne Import; Ladeordnung und `@pfad`-Importe der Wurzel-Anweisungsdatei; Grenze 4 MiB je Anweisungsdatei und Empfehlung 200 Zeilen; Entfernen von Block-Kommentaren vor dem Einspeisen (für `CLAUDE.md` dokumentiert); `claudeMdExcludes`. **Neu mit dem Abgleich vom 18.09.2026:** die **selbstgeschriebene** Anweisungsquelle des Clients (*„Auto memory is on by default"*) mit Ablage außerhalb des Projekts und Ladung des Index in jede Sitzung – das Framework schaltet sie ab (D-154); `/context` als Auskunft über die tatsächlich geladenen Anweisungsdateien |
+| QC-2 | code.claude.com/docs/en/permissions | Pfadregeln werden nur für `Read` und `Edit` ausgewertet, für andere Werkzeuge angenommen, nie konsultiert und beim Sitzungsstart als Warnung gemeldet; `deny` vor `ask` vor `allow` und die Unaufhebbarkeit einer Verweigerung über alle Ebenen; gitignore-Mustersemantik samt Normalisierung auf POSIX-Form unter Windows; Präfixsemantik der Befehlsregeln und ihre Grenze (`git -C . push` trifft nicht); `disableBypassPermissionsMode` und `disableAutoMode`; Vorrang eines mit Exit-Code 2 blockierenden Hooks **vor** den Berechtigungsregeln |
+| QC-3 | code.claude.com/docs/en/skills | `SKILL.md`-Frontmatter (`name`, `description`, `allowed-tools`, `disable-model-invocation`, `user-invocable`, `paths`, `model`); Wirkung von `disable-model-invocation: true` – das Modell kann den Skill nicht selbst laden, und seine Beschreibung kommt gar nicht erst in den Kontext; Suchpfade der Skill-Ablage; Aufruf über `/name`. **Neu mit dem Abgleich vom 18.09.2026:** die **Kontoquelle** – der Client lädt die im Konto eingeschalteten Skills nach `~/.claude/skills/synced/`, *„This is enabled by default"*, mit Abgleich etwa alle zehn Minuten **während** der Sitzung; dazu das Vorladen von Skills in ein Unteragentenprofil, das `disable-model-invocation: true` ebenfalls verhindert |
+| QC-4 | code.claude.com/docs/en/sub-agents | Subagentenprofile unter `.claude/agents/`; Frontmatter `tools` (Allowlist) und `disallowedTools` (Denylist) mit dokumentierter Verarbeitungsreihenfolge; die Beschränkung wirkt technisch; ein Profil, dessen `tools`-Liste sich zu keinem Werkzeug auflöst, wird gar nicht erst gestartet; weitere Felder, darunter `permissionMode` |
+| QC-5 | code.claude.com/docs/en/settings | Ablageorte und Rangfolge der Einstellungsdateien: verwaltet → Kommandozeile → `settings.local.json` → `settings.json` → Nutzer; `permissions`, `hooks`, `env` und `defaultMode` in derselben Datei; verwaltete Einstellungen sind bis auf wenige benannte Ausnahmen unüberschreibbar. **Neu mit dem Abgleich vom 18.09.2026:** die Tabelle der Vorrangausnahmen – für einige Schlüssel gilt der **strengere** Wert aus einer Ebene, die sonst nicht überschreiben dürfte, und für `syncClaudeAiSkills` beziehungsweise `syncClaudeAiPlugins` ausdrücklich *„a `false` in `.claude/settings.json` is ignored"*. Das ist die Datei, die das Client Pack ausliefert (`K-63`) |
+| QC-6 | code.claude.com/docs/en/hooks | Ereignisse der Hook-Schicht und ihre Matcher; `InstructionsLoaded` mit dem **Ladegrund** als Matcher (`session_start`, `nested_traversal`, `path_glob_match`, `include`, `compact`) – der dokumentierte technische Aufzählungsweg für Zeile R5 (D-158). Abgerufen am 18.09.2026 |
+| QC-7 | code.claude.com/docs/en/settings-reference | Abschnitt „Git and attribution“: `attribution` als Objekt mit `commit` und `pr` (Zeichenketten; leer blendet aus) und `sessionUrl` (Boolean); Standard ist ein Trailer `Co-Authored-By` mit einer Adresse des Herstellers; **die Kurzform `attribution: false` erst ab 2.1.281 – ältere Stände verwerfen die ganze Einstellungsdatei**; `includeCoAuthoredBy` veraltet seit 2.0.62; eigene Anweisungen zur Attribution haben Vorrang, außer in verwalteten Einstellungen (D-433). Abgerufen am 26.09.2026 |
+
+### 31.4.3 Was die Liste über sich selbst sagt
+
+Beide Teile sind am 18.09.2026 gegen eine benannte Produktversion und einen gesichteten Changelog abgeglichen worden (`FW-AK-01`, `CR-2026-087`). Von 22 abgerufenen Quellen trugen zwölf ihren zugeschriebenen Beleg unverändert, zehn nicht – geändert, im Gegenstand entfallen oder vom Produkt-Changelog widerlegt. Die Befunde daraus stehen im Protokoll `.koolie/core/tests/protocols/2026-09-18-FW-AK-01.md`.
+
+Zwei Regeln gelten für diese Liste: Eine Quelle ohne Abrufdatum ist kein Beleg, sondern eine Behauptung mit Fußnote – Produktdokumentation ändert sich, und ohne Datum lässt sich nicht sagen, ob eine Aussage noch trägt (dieselbe Überlegung wie D-25 für Versionsangaben). Und ein Abrufdatum nützt nichts, wenn nicht dabeisteht, *welche Zusage* die Seite trägt: Ohne Zuordnung je Zeile ist jede Wiederholungsprüfung so teuer wie die erste, weil jede Seite neu gelesen werden muss (D-156, Prüfung 73).
+
+
+### 31.4.4 Client Pack `kiro`
+
+Recherchestand: 26.09.2026, gegen Kiro CLI 2.24.1 (Engine V3) und Kiro IDE 1.1.70 (`CR-2026-150`, `.koolie/core/tests/protocols/2026-09-26-bau-kiro.md`). Anders als bei den beiden älteren Packs ist die Liste **nicht die Grundlage der meisten Zeilen**: Die Zeilen, die die Kommandozeile betreffen, sind am Client gemessen; die Liste belegt, was nur die IDE betrifft oder nicht gemessen ist. Abgerufen jeweils in der Markdown-Fassung der Seite (`<Seite>.md`).
+
+⚠️ **Die Dokumentation widerspricht sich an vier Stellen, und zwei davon hat die Messung entschieden:** Der Auslöser heißt `UserPromptSubmit`, nicht `PromptSubmit` (QK-3), und der Matcher eines Hooks ist ein regulärer Ausdruck, in dem `*` allein nicht kompiliert (QK-3). **Und eine Aussage ist durch Messung widerlegt:** Laut QK-3 sperrt ein Kommando-Hook mit Exit-Code 2; gemessen sperrt er **nur mit einem Grund auf stderr** (D-417).
+
+| Nr. | Quelle | Belegt im Framework insbesondere |
+|---|---|---|
+| QK-1 | kiro.dev/docs/permissions | Fähigkeitsregeln `{capability, match, exclude, effect}`, `deny` vor `ask` vor `allow` ohne Vorrang zwischen den Ebenen; die Datei des Arbeitsbereichs liegt **außerhalb** des Repositoriums (`~/.kiro/workspace-roots/<hash>/`); feste Regeln des Clients (Schreibverbot auf `.kiro/settings/`, Rückfrage für `.kiro/agents/**` und `.kiro/hooks/**`); im Betrieb ohne Rückfragen wird jede Rückfrage zur Abweisung; Einstellung `kiroAgent.agentAutonomy` der IDE |
+| QK-2 | kiro.dev/docs/steering | Ablage `.kiro/steering/*.md`, Lademodi `always`, `fileMatch` mit `fileMatchPattern`, `manual`, `auto`; globales Steering unter `~/.kiro/steering/`; `AGENTS.md` im Arbeitsbereich und in Unterverzeichnissen |
+| QK-3 | kiro.dev/docs/hooks, kiro.dev/docs/hooks/types, kiro.dev/docs/hooks/actions | Hook-Dateien `.kiro/hooks/*.json` mit `version: v1`; Auslöser je Oberfläche (Datei-Auslöser nur in der IDE); sperrende Auslöser; Exit-Code-Verhalten je Oberfläche |
+| QK-4 | kiro.dev/docs/skills | `SKILL.md` im offenen Format, Ablagen `.kiro/skills/` und `~/.kiro/skills/`, Felder `name`, `description`, `license`, `compatibility`, `metadata` |
+| QK-5 | kiro.dev/docs/specs | Spezifikationen unter `.kiro/specs/<name>/` (`requirements.md`, `design.md`, `tasks.md`), Freigabepunkte je Phase |
+| QK-6 | kiro.dev/docs/custom-agents/configuration-reference | Agentenprofil: Felder `tools`, `allowedTools`, `permissions`, `resources`, `hooks` (nur Kommandozeile), Markdown-Form mit Frontmatter; Unteragenten erben die Regeln der Sitzung |
+| QK-7 | kiro.dev/docs/mcp/configuration | `.kiro/settings/mcp.json` und `~/.kiro/settings/mcp.json`, `autoApprove`, `disabledTools` |
+| QK-8 | kiro.dev/docs/privacy-and-security/data-protection | Speicherung und Nutzung der Inhalte je Tarif, Abschaltung der Weitergabe, Verarbeitung in der Region |
+| QK-9 | kiro.dev/docs/kiroignore | `.kiroignore` – in der IDE für alle Werkzeuge, in der Kommandozeile nur für Suchergebnisse |
+
+### 31.4.5 Client Pack `cursor`
+
+Recherchestand: 26.09.2026, gegen die Kommandozeile `cursor-agent` 2026.09.26-dd393fe und die IDE 3.22.7 (`CR-2026-155`, `.koolie/core/tests/protocols/2026-09-26-bau-cursor.md`). Wie bei `kiro` ist die Liste **nicht die Grundlage der meisten Zeilen**: Was die Kommandozeile betrifft, ist unter Windows gemessen oder aus ihrem Programmcode gelesen; die Liste belegt, was nur die IDE betrifft oder nicht gemessen ist. Abgerufen jeweils in der Markdown-Fassung der Seite (`<Seite>.md`).
+
+⚠️ **Die Messung hat vier Aussagen der Dokumentation widerlegt oder ergänzt:** Die Beispielmuster `Read(.env*)` und `Read(src/**/*.ts)` treffen unter Windows nie, weil der Client mit dem absoluten Pfad vergleicht (QU-2); *„Without --force, changes are only proposed“* – geschrieben wurde trotzdem (QU-6); mit `failClosed` gilt ein Hook ohne Ausgabe als gescheitert, und die Eingabe beginnt unter Windows mit einem BOM (QU-3). Gemeldet werden sie vom Owner (`K-177`).
+
+| Nr. | Quelle | Belegt im Framework insbesondere |
+|---|---|---|
+| QU-1 | cursor.com/docs/rules | Ablage `.cursor/rules/*.mdc` mit Frontmatter `description`, `globs`, `alwaysApply`; eine `.md`-Datei dort wird ignoriert; `AGENTS.md` in der Wurzel und in Unterverzeichnissen; Nutzer- und Teamregeln; Empfehlung unter 500 Zeilen |
+| QU-2 | cursor.com/docs/cli/reference/permissions, cursor.com/docs/cli/reference/configuration | Regeltypen `Shell`, `Read`, `Write`, `WebFetch`, `Mcp`; `deny` vor `allow`; Projektdatei `.cursor/cli.json` nur mit `permissions`; globale Datei mit `approvalMode`, `sandbox` und `attribution`; MCP-Konfiguration |
+| QU-3 | cursor.com/docs/hooks, cursor.com/docs/reference/third-party-hooks | `.cursor/hooks.json` mit `version: 1`; Ereignisse und Eingabeschemata; Exit 2 sperrt, andere Fehler lassen durch außer mit `failClosed`; Umgebungsvariablen; Hooks laufen in einem vertrauten Arbeitsbereich; Import der Hooks von Claude Code mit Standard „an“ |
+| QU-4 | cursor.com/docs/skills | `SKILL.md` mit `name`, `description`, `paths`, `disable-model-invocation`, `metadata`; Ablagen `.cursor/skills/`, `.agents/skills/` und die Ablagen von Claude Code und Codex; eingebaute Skills |
+| QU-5 | cursor.com/docs/subagents | Subagenten unter `.cursor/agents/` mit `name`, `description`, `model`, `readonly`, `is_background`; Start über das Werkzeug `Task` |
+| QU-6 | cursor.com/docs/cli/headless, cursor.com/docs/cli/reference/parameters | Betrieb ohne Rückfragen (`-p`), `--force`, `--trust`, `--mode plan` und `ask`, `--sandbox`, `--approve-mcps` |
+| QU-7 | cursor.com/docs/enterprise/privacy-and-data-governance | Privacy Mode und Aufbewahrung je Modell |
+| QU-8 | cursor.com/docs/agent/security | Dateien im Arbeitsbereich ändert der Agent ohne Rückfrage; Befehle fragen zurück; jede MCP-Verbindung und jeder Aufruf braucht eine Freigabe; `.cursorignore`; die Ausführungsmodi sind *„best-effort guardrails“* |
+
+## 31.5 Konsolidierter Verifikationsbedarf
+
+Der **maßgebliche** Verifikationsbedarf steht in der Fähigkeitsmatrix des jeweiligen Client Packs: Jede Zeile ohne Beleg sagt dort `BELEG OFFEN` mit Grund und Datum, jede Matrix nennt ihren Belegstand selbst, und sie wird mit dem Pack gepflegt statt in diesem Anhang. Die Belegstände der Packs messen Verschiedenes: Bei `claude-code` ist der Beleg überwiegend ein Dokumentenabgleich gegen eine benannte Clientversion, und **ein Dokumentenabgleich belegt `[DOK]`, nicht `[TECHNISCH]` im Sinne einer beobachteten Wirkung**. Bei `devin-desktop` tritt zum Dokumentenabgleich eine laufende Sitzung hinzu; `openai-codex` belegt ohne `[DOK]`, allein über Messungen. Eingebettet sind die Matrizen von `devin-desktop` (Kap. 15.1) und `claude-code` (Kap. 7a).
+
+Die folgende Liste ergänzt sie um Punkte, die keiner einzelnen Zusage der Matrix zugeordnet sind, sondern das Zusammenspiel betreffen. Sie gilt für das Client Pack `devin-desktop`; Prüfweg ist Roadmap-AP2, Testklasse AK:
+
+| Nr. | Prüfpunkt | Betroffene Stellen |
+|---|---|---|
+| ~~V1~~ | **Geschlossen mit 0.26.0, Ergebnis „nicht dokumentiert".** Der Abgleich am 2026-09-11 gegen Devin Desktop 3.9.19 (`cli/extensibility/rules`) nennt für Regeldateien **keine** Zeichen- oder Größengrenze – weder für `AGENTS.md` noch für `.devin/rules/*.md` noch für globale Regeln; zweite unabhängige Bestätigung in derselben Sitzung (ERH-10). Die Zahlen 6.000/12.000 stammen aus der Cascade-Dokumentation (QD-7) und bleiben als **Vorgabe des Frameworks** in Kraft: Zeile R4 führt sie seit 0.26.0 als `[TEXTUELL]` (`CR-2026-027`). Wird die Grenze später doch dokumentiert, ist V1 erneut zu öffnen; K-19 bleibt offen | Laufzeit-README des Packs (Abschnitt „Regelablage"), AGENTS.md-Größenbudget, Validator-Grenzen |
+| V2 | Exakte Schemadetails von `.devin/config.json` (Schlüsselstruktur, Glob-/Präfix-Semantik, Wildcard `Fetch(*)`, Kommentarfelder-Toleranz) | `.devin/config.json`, FW-CORE-03 Abschnitt 4 |
+| ~~V3~~ | **Erledigt mit 0.25.0.** Das Hook-Eingabeschema ist in einer Sitzung erhoben: `hook_event_name`, `tool_name`, `tool_input`, `session_id`, `prompt_id` und ein in der Dokumentation nicht genanntes `tool_use_id`; Werkzeugnamen `read` und `exec`; Blockieren über Exit 2. Die Umstellung auf fail-closed ist mit `CR-2026-026` je Pack entschieden. **Dabei fiel auf, dass die Hook-Datei des Packs gar nicht gelesen wurde** (`AP2-DD-10`, `CR-2026-029`) | `.koolie/core/tests/protocols/2026-09-11-AP2-devin-desktop.md` |
+| V4 | Skill-Discovery über `.agents/skills/` durch Devin Local; Verhalten der `@skills:`-Erwähnung im Desktop; Grenze „ein Skill aktiv" | FW-CORE-08 Abschnitt 2, K-12 |
+| V5 | Toleranz unbekannter Frontmatter-Schlüssel in SKILL.md (D-08 bleibt unabhängig davon bestehen) | Skill-Standard, K-18 |
+| 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` |
+| V10 | Zeichen-/Größenbudget und Ladeverhalten der always-on-Summe (AGENTS.md + `00-*` + `20-*`) im realen Systemprompt | Laufzeitschicht gesamt |
+
+## 31.6 Beispielartefakte (synthetisch)
+
+Im Repository unter `.koolie/core/examples/`: ausgefüllte Overlay-Laufzeitfassung, vollständiger Ergebnisbericht und Merge-Request-Beschreibung mit Nutzungsvermerk – alle ausdrücklich synthetisch und mit erfundenen Bezeichnern (siehe `.koolie/core/examples/README.md`).