@renoxar/koolie 1.25.0

package/.koolie/core/build/doc/32-abschluss.md

@@ -0,0 +1,92 @@
+# Abschluss der Ausarbeitung
+
+## Stand dieser Dokumentfassung
+
+Die Erstfassung 0.1.0 beschrieb ein Framework für genau einen KI-Client. Seither ist der Kern in mehreren Schritten von dieser Bindung gelöst worden; die folgenden Abschnitte sind entsprechend fortgeschrieben.
+
+| Release | Was sich geändert hat |
+|---|---|
+| 0.2.0 | Der Kern liegt in einem einzigen Verzeichnis; `install.py` trennt Core von Projektbestand |
+| 0.5.0 | **Client Packs** als Abbildungsschicht mit Fähigkeitsmatrix (Kap. 7a); 61 von 63 Client-Bindungen im Kern durch Begriffe ersetzt; Querverweisprüfung `FW-KO-04` |
+| 0.6.0 | Berechtigungen und Hooks als **Semantikabbildung** aus einer Kernquelle; drei Zusicherungen werden erzwungen statt zugesagt |
+| 0.7.0 | Das Framework heißt **Leitwerk**; der Name folgt dem Inhalt (mit `0.88.0` umbenannt in **Koolie**) |
+| 0.8.0 | Ein Client Pack besteht aus vier Dateien; die gesamte Saat kommt aus dem Kern |
+| 0.9.0 | Dieses Dokument baut aus einem frischen Auscheckstand und weist bei jeder Laufzeitdatei aus, aus welchem Client Pack sie stammt |
+| 0.26.0 | Der Schutz-Hook läuft **fail-closed**, und die Hook-Konfiguration steht dort, wo der Client sie nachweislich liest – nicht dort, wo seine Dokumentation sie nennt (D-31, D-32). Ein Client Pack umfasst seither drei Dateien (D-36) |
+| 0.49.0 | **Kriterium 4 der 1.0.0-Definition erfüllt:** kein Decision Record mehr im Status `entschieden (Vorschlag)` |
+| 0.53.0 | **Kriterium 3 erfüllt:** kein Modulträger mehr im Status `entwurf` |
+| 0.57.0 | Der Validator setzt die **Werkzeugneutralität des Kerns selbst** durch (Prüfung 14 und 48). Bis dahin galt sie als Regel und wurde von nichts gemessen – siebzehn Fundstellen in vierzehn Trägern fielen im ersten Lauf |
+| 0.84.0 | **Kriterium 2 erfüllt:** keine Ergebniszelle mehr auf `offen`. 111 Zellen über sechs Messtage, ein Schritt aufwärts darunter, und er war Absicht |
+| 0.85.0 | Jede mit `[DOK]` belegte Zeile einer Fähigkeitsmatrix nennt die **Quellenkennung** ihrer Belegliste; Prüfung 73 setzt es durch. Eine Zeile bleibt ausdrücklich ohne Zuordnung – *geraten wird nicht* |
+| 0.86.0 | **Roadmap-AP2 ist zu Ende gefahren:** 70 Sitzungsläufe an einer Installation, vier Zusagen gemessen – zwei zum Besseren, zwei zum Schlechteren |
+| 0.87.0 | **Kriterium 1 erfüllt**, indem die Markerform selbst abgeschafft wurde: *Ein Belegstand sagt, was heute belegt ist, nicht, bis wann es belegt sein muss* (D-291). Die Zahl bleibt als Rückfallsperre stehen |
+| 0.88.0 | **Das Framework heißt Koolie.** Der Kern liegt unter `.koolie/core/`, das Project Overlay unter `.koolie/project-overlay/`; 498 Dateien mit einem `git mv`, 1.645 Ersetzungen in 197 Trägern |
+| 0.89.0 | Dieses Dokument ist gegen den geltenden Stand gesetzt. 🔴 **Es war seit 0.88.0 nicht baubar** – das Assemblierungsskript zählte den Weg zur Projektwurzel im Quelltext, und der Kern liegt seit der Umbenennung eine Ebene tiefer |
+
+**Was an der Ehrlichkeitsgrenze geblieben ist, und was nicht.** Der Satz „kein Mechanismus wurde in einer Zielinstallation ausgeführt" gilt **nicht mehr**: Für das Client Pack `devin-desktop` ist AP2 gefahren und mit Release 0.86.0 abgeschlossen, neun Matrixzeilen sind an einer laufenden Installation beobachtet. **Geblieben ist die Grenze in ihrer genaueren Form:** Ein Beleg gilt je Zeile, je Client und je Produktstand – nicht als Gesamturteil über eine Matrix. Für `claude-code` sind die Wirkungsnachweise überwiegend offen; ein Dokumentenabgleich belegt `[DOK]`, nicht `[TECHNISCH]` im Sinne einer beobachteten Wirkung. 🔴 **Und zwei der gemessenen Zusagen sind zum Schlechteren ausgegangen** – die Messung hat widerlegt, was das Pack vorgesehen hatte. Das steht in den betreffenden Zeilen und ist nicht eingeebnet worden; *eine Matrix, in der jede Messung die Erwartung bestätigt, misst nicht.*
+
+## Kritische Selbstprüfung
+
+Die Selbstprüfung bezieht sich auf die Erstfassung 0.1.0 und wurde für diese Dokumentfassung auf den Stand 0.89.0 fortgeschrieben. Sie wurde automatisiert durchgeführt (Strukturvalidator über das gesamte Repository: 0 Fehler, 0 Warnungen; zusätzlich Querverweisprüfung `FW-KO-04`; Inhaltsprüfungen auf Secret-Muster, E-Mail-Adressen, IP-Adressen, interne Hostnamen, nicht gelistete URLs; Mermaid-Syntaxprüfung aller Diagramme: valide) und im Durchsichtsverfahren. Ergebnis je Prüffrage:
+
+| Nr. | Prüffrage | Ergebnis |
+|---|---|---|
+| 1 | Identifizierende Projektinformationen enthalten? | Nein. Variable Inhalte ausschließlich als registrierte Platzhalter; automatische und manuelle Prüfung ohne Befund. |
+| 2 | Reale Organisationen, Personen, Kunden, Behörden, Infrastrukturen genannt? | Nein – mit zwei bewussten, zulässigen Ausnahmen laut Auftrag: generische Werkzeugklassen (Jira, Git, GitLab, GitHub, CI/CD, IDE, Wiki) und der Hersteller-/Produktbezug zu Devin Desktop (ehemals Windsurf) samt offizieller Dokumentation, der für Phase 3 erforderlich ist. Rollen statt Personen durchgängig. |
+| 3 | Unbelegte Client-Funktionen als Tatsache behauptet? | Nein. Jede Produktaussage trägt `[DOK]` mit Quellenzuordnung (Anhang 31.4), `[EMPF]` oder `[KONZ]`; Offenes trägt den Belegstand `BELEG OFFEN` und ist in Anhang 31.5 konsolidiert. Einschränkung transparent: `[DOK]` heißt dokumentationsbelegt, nicht installationsgeprüft (AP2). |
+| 4 | Framework Core und Project Overlay sauber getrennt? | Ja. Platzhalter-Schnittstellen, getrennte Ownership, technische Schreibsperren, Integritätsblock in der Berechtigungsdatei (seit 0.6.0 erzeugt und gegen die Kernquelle geprüft), Integritätsblock in `config.json`, strikte Overlay-Validierung; Grenzfälle über Entscheidungsbaum 6 (Kap. 8). |
+| 5 | Referenzartefakte tatsächlich wiederverwendbar? | Ja. Alle Artefakte sind projektneutral, versioniert, mit Owner-Feld und Ausfüllhinweisen; Skills/Prompts/Checklisten arbeiten ausschließlich mit Overlay-Platzhaltern; Übernahmeweg inklusive Aktualisierung ist definiert (Kap. 28). |
+| 6 | Widersprüchliche Anweisungen? | Keine bekannten. Prioritätshierarchie mit Widerspruchsprüfung und Zusatzregeln (Kap. 25.1); die zwei im Auftrag angelegten Spannungen (zwei Hierarchiefassungen; M5 ohne Befehle vs. lesende Git-Befehle für MR-Texte) wurden erkannt, entschieden und dokumentiert (K-08; FW-CORE-05). Restsicherung über Konsistenztests KO und Review-Zyklus. |
+| 7 | Annahmen als Annahmen gekennzeichnet? | Ja. A-01 bis A-05 im Decision Log und im Abschlussabschnitt; in Artefakten sind Vermutungen und Vorschläge als solche markiert (P3-Konvention durchgängig). |
+| 8 | Rückfragen bei relevanten Unklarheiten verlangt? | Ja. No Assumption Policy in der Wurzel-Anweisungsdatei, jedem Skill (Rückfragenregeln, [RÜCKFRAGE]-Punkte), jeder Prompt-Vorlage und im Arbeitsablauf Schritt 4; Testklasse FI prüft es. |
+| 9 | Datenschutz und Informationssicherheit operativ umsetzbar? | Ja. Vier Kontextklassen mit Entscheidungsbaum und Checkliste, Freigabeverfahren, Vorfallablauf, technische Sperren (deny-Regeln, Hook), Team-Einstellungs-Anschlüsse; offene organisationsspezifische Voraussetzungen sind als K-05/K-06 ausgewiesen statt wegdefiniert. |
+| 10 | Menschliche Prüfung an allen relevanten Stellen verankert? | Ja. P1/P5, Delegationsverbote V1/V2, Freigabepunkt Schritt 9, Review-Regeln mit Stufen-Tiefe, MR-Checkliste, „keine Stufe ersetzt menschliche Prüfung" (FW-CORE-09), der Assistent erklärt nie etwas für freigegeben. |
+| 11 | Übernahme ohne Core-Änderung möglich? | Ja. Adoption Guide + CL-10; Projektwechsel = Overlay-Tausch; byte-gleiche Core-Übernahme aus Releases; nachgewiesen durch Trennmechanik (Kap. 8). |
+| 12 | Skills versionierbar, testbar, wartbar? | Ja. Semantic Versioning je Skill, Lebenszyklus mit Kriterien, Pflicht-Testfälle (2 Positiv/3 Negativ je Skill), CHANGELOG je Skill, Strukturvalidierung und Ausgabeprüfung per Skript, Owner-Feld. |
+| 13 | Beispiele ausschließlich synthetisch und gekennzeichnet? | Ja. Kennzeichnungspflicht ist Konvention und Validator-Prüfung („synthetisch" in jeder EXAMPLES.md); Beispiele nutzen offensichtlich fiktive Bezeichner und Beispiel-Domänen. |
+| 14 | Offene Entscheidungen im Decision Log? | Ja, und das Register ist seither erheblich gewachsen: **312 Decision Records von D-01 bis D-312, lückenlos; 102 Klärungspunkte von K-01 bis K-104 – zwei Nummern fehlen: `K-99`, eine belegte synthetische Kennung des Prüfapparats, und die zusammengesetzte Kennung der Sonde zu Prüfung 50 – die gerade **nicht** belegt ist und im Kern nicht ausgeschrieben stehen darf, weil sie gemeldet werden soll; dazu fünf Annahmen A-01 bis A-05** – zentral geführt (Kap. 29.2), **gezählt am 2026-09-22 und als datierte Angabe stehengeblieben** (D-318). Die Vollständigkeit beider Register setzen Prüfung 50 und 58 durch: Jede im Kern genannte Kennung steht als Zeile im Log. Entscheidungsreife Kurzliste unten. |
+| 15 | Technische Empfehlungen nach Verbindlichkeit und Belegstatus gekennzeichnet? | Ja. MUSS/SOLL/KANN/DARF NICHT plus `[DOK]`/`[EMPF]`/`[KONZ]`/`BELEG OFFEN` durchgängig; Legende in Kap. 6 (FW-CORE-00). |
+
+Im Zuge der Selbstprüfung behobene Mängel (Auszug): Vereinheitlichung der M5-Befehlsregel (lesende Git-Befehle) über Modul, Laufzeitregel und Skills; Registrierung nachträglich aufgefallener Schema-Platzhalter; Entfernung eines Kodierungsartefakts; Korrektur eines Abschnittsverweises in der MCP-Vorlage; Ergänzung fehlender Kernregeln-Prüfungen im Validator während der Erstellung.
+
+## Offene Entscheidungen
+
+Punkte, die tatsächlich eine projektspezifische oder organisatorische Entscheidung erfordern (Details und Wege im Decision Log):
+
+1. **Organisationsfreigabe und Vertragslage (K-05, K-06):** Planstufe/Admin-Kontrollen erheben; Datenschutz- und Vertragsprüfung (Auftragsverarbeitung, Training-Opt-out, Zero Data Retention, Verarbeitungsorte, Löschverfahren) durchführen und im Overlay referenzieren. Vorher keine Aktivierung.
+2. **Nutzungsumfang (K-04):** Nur lokale, beobachtete Nutzung (Framework-Standard) oder Freigabe von Cloud-Sitzungen und Läufen ohne beobachtende Person mit erweitertem Sicherheitsmodell.
+3. **Rollenbesetzung:** `<FRAMEWORK_OWNER>`, Overlay Owner, `<SECURITY_CONTACT>`, `<DATA_PROTECTION_CONTACT>`, Mentorinnen/Mentoren, Modul-Owner (Zuordnung außerhalb des Repositorys).
+4. **Bestätigung der Strukturentscheidungen D-01 bis D-10** durch den künftigen Framework Owner – insbesondere D-05 (Modus ohne Rückfragen untersagt), D-06/K-08 (8-stufige Hierarchie mit Verschärfungsprinzip), D-10 (Cloud-Sitzungen und Läufe ohne beobachtende Person deaktiviert, D-386). Die übrigen 302 der am 2026-09-22 gezählten 312 Records sind Framework-Entscheidungen und betreffen ein aufnehmendes Projekt nur über ihre Wirkung.
+5. **Erstprojekt-Parameter:** Overlay-Werte (Pfade, Befehle, kritische Komponenten, `<CHANGE_SIZE_THRESHOLD>`), Ablageorte für Ergebnisberichte/Pläne/Testprotokolle, Feedbackkanal, Review-Zyklus-Frequenz.
+6. **Wahl des Client Packs und dessen verbindliche Zielversion** für AP2 und den Pilot. Ohne geprüfte Zielversion ist in der Fähigkeitsmatrix keine Einstufung `[TECHNISCH]` zulässig.
+7. **Pilotparameter:** Pilotgruppe, `<PILOT_DURATION>`, Fallliste, Zielwerte der Metriken (erst nach Referenzbasis).
+
+## Annahmen
+
+Unvermeidbare Annahmen dieser Erstfassung – alle gekennzeichnet, keine stillschweigenden (vollständig mit Auswirkungsanalyse im Decision Log):
+
+1. **A-01:** Das Projekt-Repository kann im Wurzelverzeichnis um die Wurzel-Anweisungsdatei und die Laufzeitschicht des gewählten Client Packs ergänzt werden (sonst eigener Workspace-Zuschnitt nötig).
+2. **A-02:** Entwickler arbeiten auf Feature-Branches ohne Direktschreibrechte auf geschützte Branches.
+3. **A-03:** Ein dokumentierter Review-/Freigabeprozess (Merge Request, CI) existiert und bleibt bestehen.
+4. **A-04:** Verarbeitung der Anfragen erfolgt über Anbieter-/Modellanbieter-Infrastruktur (kein lokales Modell) – Grundlage der restriktiven Kontextklassen.
+5. **A-05 (gilt für das Client Pack `devin-desktop`):** Die in der CLI-Dokumentation beschriebenen Mechanismen gelten für Devin Local in Devin Desktop (die Desktop-Dokumentation verweist auf geteilte Modi/Mechanismen); Absicherung über die Belegspalte der Fähigkeitsmatrix und AP2.
+
+## Verifikationsbedarf
+
+Gegen die Dokumentation des gewählten Clients beziehungsweise in einer Zielinstallation zu prüfen: die Fähigkeitsmatrix des Client Packs (**1 von 36 Zeilen bei `devin-desktop` sagt `BELEG OFFEN` – dauerhaft –, bei `claude-code` 1 von 32 (`M4`); dort stehen dafür die Wirkungsnachweise überwiegend aus**) sowie die konsolidierten Punkte V2–V10 aus Anhang 31.5 – V1 ist mit 0.26.0 geschlossen, Ergebnis „nicht dokumentiert"; exakte `config.json`-Schemadetails; Hook-Eingabeschema (danach fail-closed als Standard); Skill-Discovery `.agents/skills/` und `@skills:`-Verhalten; Frontmatter-Toleranz; MCP-Dateistruktur; Codebasis-Indexierung; Spaces-Kontextreichweite; Wirkung additiver Skill-Permissions; reales Ladeverhalten der always-on-Summe. Prüfweg: Roadmap-AP2 mit Protokollpflicht; laufend: Testklasse AK im Release-Zyklus.
+
+## Datenschutzprüfung
+
+Das Ergebnis ist nach automatisierter Prüfung (Sperrbegriffe, E-Mail-/IP-/Hostnamen-/URL-Muster, Secret-Muster über alle Dateien) und manueller Durchsicht **frei von identifizierenden Projekt-, Personen-, Kunden-, Behörden- und Infrastrukturinformationen**: keine realen oder plausibel wirkenden Namen, Organisationseinheiten, Standorte, internen URLs, Repository-, Server-, Mandanten- oder Umgebungsbezeichnungen; keine Geheimnisse oder personenbezogenen Daten; Platzhalter sind nicht mit realistisch wirkenden Werten befüllt; alle Beispiele sind synthetisch und als solche gekennzeichnet. Genannt werden ausschließlich – auftragsgemäß zulässig – generische Werkzeugklassen sowie Hersteller, Produkt und offizielle Dokumentations-Fundstellen von Devin Desktop (ehemals Windsurf). Die Eingaben des Auftrags enthielten keine schutzbedürftigen Informationen, die zu übernehmen oder zu abstrahieren gewesen wären.
+
+## Empfohlene nächste Schritte
+
+Priorisiert und unmittelbar umsetzbar auf dem Weg zur ersten produktiven Framework-Version:
+
+1. **Rollen besetzen und Prüfungen beauftragen (AP1):** Framework Owner und Projektrollen benennen; Datenschutz-/Vertragsprüfung (K-06) und Erhebung der Planstufe/Admin-Kontrollen (K-05) starten – der kritische Pfad.
+2. **Mechanismen validieren (AP2):** Testinstallation mit fixierter Zielversion; die offenen Belege der Fähigkeitsmatrix und die konsolidierten Prüfpunkte protokolliert abarbeiten; Hook auf fail-closed stellen; Belegstatus-Tabellen aktualisieren.
+3. **Core-Review durchführen (AP3):** FW-CORE-Module und Prioritätshierarchie durch die benannten Rollen abnehmen; D-01…D-10 bestätigen; Organisations-Mapping (Klassifizierung → K0–K3) füllen.
+4. **Erstprojekt konfigurieren (AP4):** Client Pack wählen, Overlay vollständig ausfüllen, die Platzhalter der Berechtigungsdatei befüllen, erstes Technology Pack für `<TECH_STACK>` erstellen, Übungsrepository erzeugen; strikte Validierung.
+5. **Sicherheits-/Datenschutzfreigabe einholen (AP6)** und **Basistests des Testkatalogs ausführen (AP7-Teilmenge)** – erst danach Overlay aktivieren (CL-10).
+6. **Erste Nutzergruppe onboarden (AP8):** Mentoren briefen, Köder scharf schalten, Freigaben dokumentieren.
+7. **Pilot starten (AP9):** Referenzbasis erheben, Etikettierung einrichten, Review-Punkte terminieren – und die Auswertung (AP10) als echte Entscheidung über Fortführung, Anpassung oder Beendigung behandeln.

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

@@ -0,0 +1,54 @@
+# Checkliste FW-CL-01 – Preflight-Check vor jeder KI-Aufgabe
+
+| Attribut | Wert |
+|---|---|
+| ID | `FW-CL-01` |
+| Version | `0.1.8` |
+| Status | `pilot` |
+| Owner (Rolle) | `<FRAMEWORK_OWNER>` |
+| Wann | vor jeder KI-Sitzung, nach Zuschnitt der Aufgabe |
+| Wer | Bearbeiterin oder Bearbeiter |
+| Dauer (Richtwert, Erläuterung) | wenige Minuten – keine verbindlichen Aufwände |
+| Nachweis | Kontrollstufe, Faktor und Modus in der Aufgabenanweisung; ab Stufe mittel im Ergebnisbericht |
+
+## Zweck
+
+Stellt vor dem ersten Prompt sicher, dass die Aufgabe delegierbar, richtig eingestuft, sauber abgegrenzt und der Kontext zulässig ist. Ohne abgeschlossenen Preflight-Check beginnt keine KI-Aufgabe (`.koolie/core/framework/core/05-working-model.md`, Schritt 1–4).
+
+## Prüfpunkte
+
+### Aufgabe und Delegierbarkeit
+
+- [ ] **MUSS** Ziel und Akzeptanzkriterien der Aufgabe liegen schriftlich vor (ein Ziel je Aufgabe).
+- [ ] **MUSS** Die Aufgabe steht nicht auf der Delegationsverbotsliste V1–V12 (`.koolie/core/framework/core/09-risk-model.md` Abschnitt 4); andernfalls Abbruch (nur menschliche Bearbeitung, der KI-Client höchstens vorbereitende Analyse, sofern zulässig).
+- [ ] **MUSS** Der Entscheidungsbaum `.koolie/core/decision-trees/02-may-ai-do-task.md` wurde bei Unsicherheit durchlaufen.
+- [ ] **SOLL** Die Aufgabe ist klein genug für eine Sitzung; sonst zerlegen (Analyse → Plan → Umsetzung).
+
+### Einstufung
+
+- [ ] **MUSS** Kontrollstufe nach `.koolie/core/framework/core/09-risk-model.md` bestimmt (alle Faktoren R1–R13 durchgegangen, Maximumprinzip) und der auslösende Faktor notiert (zum Beispiel „mittel wegen R8").
+- [ ] **MUSS** Betriebsmodus M1–M6 festgelegt (`.koolie/core/decision-trees/03-analyze-or-modify.md`).
+- [ ] **MUSS** Bei Stufe mittel: Planbestätigung vor Umsetzung eingeplant. Bei Stufe hoch: dokumentierte Freigabe `<APPROVAL_ROLE>` liegt vor und eine begleitende Person ist benannt.
+- [ ] **MUSS** Im Zweifel zwischen zwei Stufen wurde die höhere gewählt.
+
+### Scope und Kontext
+
+- [ ] **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.
+
+### 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** 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.
+
+## Abbruch- und Eskalationskriterien
+
+Aufgabe nicht beginnen und gemäß `.koolie/core/framework/core/10-error-escalation.md` behandeln, wenn: die Aufgabe unter ein Delegationsverbot fällt (E0/E2), die Einstufung unklar bleibt (E1), erforderliche Freigaben fehlen (E2), benötigter Kontext nur als K3 verfügbar wäre (E0, gegebenenfalls E3) oder das Overlay nicht aktiv ist (E1 an Overlay Owner).
+
+## Ergebnis und Nachweis
+
+Kontrollstufe (mit Faktor), Modus, Scope und verwendete Kontextquellen werden in die Aufgabenanweisung übernommen (Pflichtelemente nach `.koolie/core/framework/core/06-prompting-rules.md`) und erscheinen im Ergebnisbericht sowie ab Stufe mittel im KI-Nutzungsvermerk des Merge Requests.

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

@@ -0,0 +1,51 @@
+# Checkliste FW-CL-02 – Datenschutz- und Kontextcheck
+
+| Attribut | Wert |
+|---|---|
+| ID | `FW-CL-02` |
+| Version | `0.1.4` |
+| Status | `pilot` |
+| Owner (Rolle) | `<FRAMEWORK_OWNER>` in Abstimmung mit `<DATA_PROTECTION_CONTACT>` |
+| Wann | im Preflight-Check und erneut vor jeder zusätzlichen Kontextbereitstellung in der Sitzung |
+| Wer | Bearbeiterin oder Bearbeiter; bei K2-Freigaben `<APPROVAL_ROLE>` beziehungsweise `<DATA_PROTECTION_CONTACT>` |
+| Dauer (Richtwert, Erläuterung) | wenige Minuten je Quelle – keine verbindlichen Aufwände |
+| Nachweis | Kontextliste mit Klassen im Ergebnisbericht; K2-Freigaben mit Rolle und Datum |
+
+## Zweck
+
+Verhindert, dass unzulässige Inhalte (K3) oder nicht freigegebene Inhalte (K2) an den KI-Client gelangen (`.koolie/core/framework/core/02-privacy.md`, `.koolie/core/decision-trees/01-context-allowed.md`).
+
+## Prüfpunkte
+
+### Je Kontextquelle
+
+- [ ] **MUSS** Kontextklasse bestimmt (K0/K1/K2/K3); ohne Einstufung gilt K3 und die Quelle wird nicht verwendet.
+- [ ] **MUSS** K3-Kategorien geprüft: Secrets und Schlüsselmaterial; personenbezogene Echtdaten; Produktionsdaten; nicht freigegebene Kunden- oder Behördendokumente; Sicherheitskonfigurationen; interne Adressen, Hostnamen, Mandanten- und Umgebungskennungen; Inhalte anderer Projekte; als vertraulich eingestufte Inhalte.
+- [ ] **MUSS** Mischinhalte tragen die höchste enthaltene Klasse, bis die höher eingestuften Bestandteile entfernt sind.
+- [ ] **MUSS** Aufgabenbezug vorhanden: Die Quelle ist für genau diese Aufgabe erforderlich (Least Context, keine Pauschalfreigaben ganzer Ablagen).
+- [ ] **MUSS** Im Manifest als `veraltet` markierte Dokumente werden nicht verwendet; sonstige veraltete Dokumente SOLLEN nicht bereitgestellt werden (`02-privacy.md` Abschnitt 3.2).
+
+### K2-Inhalte (nur mit Freigabe)
+
+- [ ] **MUSS** Freigabe vorhanden: Kategoriefreigabe im Overlay-Manifest oder Einzelfreigabe durch `<APPROVAL_ROLE>` (bei Personenbezug zusätzlich `<DATA_PROTECTION_CONTACT>`), mit Datum dokumentiert.
+- [ ] **MUSS** Bereinigung durchgeführt: Personen → Rollen; Organisationen, Adressen, Kennungen → Platzhalter; Fallbeschreibungen abstrahiert.
+- [ ] **MUSS** Tickets: nur Titel, technische Beschreibung, Akzeptanzkriterien; Kommentarverläufe, Anhänge, Screenshots und Kundenkommunikation SOLLEN nicht übernommen werden (`02-privacy.md` Abschnitt 3.4).
+- [ ] **MUSS** Logs und Stacktraces: personenbezogene Daten, Secrets, Hostnamen und Kennungen entfernt.
+- [ ] **MUSS** Die bereinigte Fassung wird nicht in das Repository übernommen (Ebene E).
+
+### Testdaten, Werkzeuge, geteilter Kontext
+
+- [ ] **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.
+- [ ] **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).
+
+## Abbruch- und Eskalationskriterien
+
+Sind K3-Inhalte bereits an den KI-Client gelangt: sofort nach `.koolie/core/framework/core/02-privacy.md` Abschnitt 5 verfahren (Sitzung beenden, Secrets rotieren lassen, Meldung an `<SECURITY_CONTACT>` und bei Personenbezug `<DATA_PROTECTION_CONTACT>`, Erfassung nach `.koolie/core/governance/INCIDENT_HANDLING.md`) – Eskalationsstufe E3 (`.koolie/core/framework/core/10-error-escalation.md`). Fehlende K2-Freigabe: Quelle nicht verwenden, gegebenenfalls Freigabe anfordern (E1).
+
+## Ergebnis und Nachweis
+
+Liste der verwendeten Quellen mit Klasse und – bei K2 – Freigabe (Rolle, Datum, Bereinigung) im Ergebnisbericht; Reviewer prüfen die Liste stichprobenartig (RV-Stichprobe nach `.koolie/core/framework/core/02-privacy.md` Abschnitt 4 Schritt 5).

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

@@ -0,0 +1,51 @@
+# Checkliste FW-CL-03 – Vor Codeänderungen (Modi M3, M4, M5)
+
+| Attribut | Wert |
+|---|---|
+| ID | `FW-CL-03` |
+| Version | `0.1.3` |
+| Status | `pilot` |
+| Owner (Rolle) | `<FRAMEWORK_OWNER>` |
+| Wann | nach Preflight und Analyse, unmittelbar bevor der KI-Client erstmals schreiben oder Befehle ausführen soll |
+| Wer | Bearbeiterin oder Bearbeiter |
+| Dauer (Richtwert, Erläuterung) | wenige Minuten – keine verbindlichen Aufwände |
+| Nachweis | bestätigter Plan (ab mittel), Schrittprotokoll im Ergebnisbericht |
+
+## Zweck
+
+Sichert die Voraussetzungen aus Schritt 9–10 des Standardarbeitsablaufs, bevor die erste Änderung entsteht: Freigaben, belegter Ist-Zustand, sauberer Ausgangspunkt, klare Grenzen.
+
+## Prüfpunkte
+
+### Freigaben und Plan
+
+- [ ] **MUSS** Stufe niedrig: Aufgabe klar abgegrenzt (Ziel, Scope, Akzeptanzkriterien). Stufe mittel: Plan nach `.koolie/core/templates/PLAN_TEMPLATE.md` liegt vor und ist schriftlich bestätigt. Stufe hoch: dokumentierte Freigabe `<APPROVAL_ROLE>` (bei R3/R10 zusätzlich `<SECURITY_CONTACT>`) und begleitende Person vorhanden.
+- [ ] **MUSS** Der Plan beziehungsweise die Aufgabe berührt keine Delegationsverbote (V1–V12).
+
+### Ist-Zustand und Auswirkungen
+
+- [ ] **MUSS** Relevanter Ist-Zustand ist analysiert; Befunde mit Fundstellen liegen vor (P4; Skills `fw-repo-analyze`, `fw-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`).
+
+### Arbeitsumgebung
+
+- [ ] **MUSS** Eigener Arbeitsbranch nach `<BRANCHING_MODEL>`/`<BRANCH_PREFIX>`; niemals ein geschützter Branch.
+- [ ] **MUSS** Arbeitsstand sauber (kein fremder Diff); die Änderungen des KI-Clients bleiben dadurch einzeln zurechenbar (P7).
+- [ ] **MUSS** Nur freigegebene Befehle vorgesehen (`<BUILD_COMMAND>`, `<TEST_COMMAND>`, `<LINT_COMMAND>`, Overlay Abschnitt 6).
+- [ ] **MUSS** Schreibgrenzen benannt: M3 nur `<ALLOWED_PATHS>` abzüglich `<READ_ONLY_PATHS>`; M4 nur `<TEST_PATHS>`; M5 nur `<DOC_PATHS>`.
+
+### Grenzen der Änderung
+
+- [ ] **MUSS** Keine Änderungen an Abhängigkeiten, Lockfiles, Paketquellen, CI/CD- oder Quality-Gate-Konfiguration vorgesehen; sonst Abbruch und regulärer Prozess (`.koolie/core/checklists/07-new-dependency.md`, Änderungsantrag).
+- [ ] **MUSS** Abbruchkriterien der Sitzung sind vereinbart (Planabweichung, Scope-Verlassen, steigende Stufe, rote Tests außerhalb des Scopes).
+- [ ] **SOLL** Erwarteter Umfang unter `<CHANGE_SIZE_THRESHOLD>` Dateien; sonst Aufteilung (Q8).
+- [ ] **SOLL** Zeitpunkt so gewählt, dass die Sitzung beobachtet zu Ende geführt werden kann (M3 wird nicht unbeaufsichtigt fortgesetzt).
+
+## Abbruch- und Eskalationskriterien
+
+Nicht beginnen bei fehlender Bestätigung oder Freigabe (E1/E2), rotem Ausgangsstand (E0, erst Ursache klären), unklaren Verwendern kritischer Elemente (E1 an `<ARCHITECT_ROLE>`) oder wenn die Änderung nur außerhalb der Schreibgrenzen möglich wäre (E1, Scope-Entscheidung durch Menschen; `.koolie/core/framework/core/10-error-escalation.md`).
+
+## Ergebnis und Nachweis
+
+Bestätigter Plan (Referenz), Ausgangs-Testergebnis und vereinbarte Grenzen werden im Ergebnisbericht und ab Stufe mittel im KI-Nutzungsvermerk dokumentiert.

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

@@ -0,0 +1,58 @@
+# Checkliste FW-CL-04 – Review KI-generierten Codes
+
+| Attribut | Wert |
+|---|---|
+| ID | `FW-CL-04` |
+| Version | `0.1.3` |
+| Status | `pilot` |
+| Owner (Rolle) | `<FRAMEWORK_OWNER>` |
+| Wann | Selbstreview vor jedem Commit mit KI-Beteiligung; unabhängiges Review im Merge Request |
+| Wer | Bearbeiterin oder Bearbeiter (Selbstreview); unabhängige Reviewerin oder Reviewer (ab Stufe mittel verpflichtend) |
+| Dauer (Richtwert, Erläuterung) | abhängig vom Diff – keine verbindlichen Aufwände |
+| Nachweis | Selbstreview im KI-Nutzungsvermerk; Review-Befunde im Merge Request |
+
+## 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.
+
+## Prüfpunkte
+
+### Scope und Belege
+
+- [ ] **MUSS** (RV1) Nur freigegebene Dateien und Bereiche geändert; keine beiläufigen Umformatierungen, Umbenennungen oder Import-Umsortierungen.
+- [ ] **MUSS** (RV2) Stichprobe der Fundstellen aus dem Ergebnisbericht geprüft (mindestens drei); Aussagen decken sich mit dem Code.
+- [ ] **MUSS** (RV12) Annahmen und offene Fragen aus dem Ergebnisbericht sind adressiert oder im Merge Request sichtbar.
+
+### Fachlichkeit und Korrektheit
+
+- [ ] **MUSS** (RV10) Jede geänderte Zeile ist der Bearbeiterin oder dem Bearbeiter erklärbar (Q3); Unerklärliches wird nicht übernommen.
+- [ ] **MUSS** (RV5) Verwendete Methoden, Klassen und Bibliotheksfunktionen existieren in der eingesetzten Version (Import- oder Manifest-Fundstelle; bei Zweifel Suche im Repository beziehungsweise in der lokalen Abhängigkeit).
+- [ ] **MUSS** (RV3) Bei Refaktorisierungen: fachliches Verhalten nachweislich unverändert (Vorher/Nachher-Testlauf, unveränderte Randbedingungen `<`/`<=`, Fehlerbehandlung, Rundung, Reihenfolge).
+- [ ] **MUSS** Randbedingungen geprüft: Null/leer, Grenzwerte, Zeitzonen/Locale, Nebenläufigkeit, Ressourcenfreigabe – soweit für die Änderung relevant.
+
+### Tests und Quality Gates
+
+- [ ] **MUSS** (RV4) Tests prüfen fachliches Verhalten, nicht die Implementierung; keine entfernten oder abgeschwächten Assertions; keine Tests, die nur Mocks verifizieren.
+- [ ] **MUSS** (RV9) Keine Änderungen an Linter-, Coverage-, Pipeline- oder Quality-Gate-Konfiguration; keine ignorierten oder übersprungenen Tests ohne dokumentierte Begründung.
+- [ ] **MUSS** Lokale Prüfungen ausgeführt (`<LINT_COMMAND>`, `<TEST_COMMAND>`); Ergebnisse liegen unverändert vor.
+
+### Sicherheit, Datenschutz, Abhängigkeiten
+
+- [ ] **MUSS** (RV7) Eingabevalidierung und Autorisierungsprüfung in neuen Pfaden; Fehlermeldungen ohne Interna; kein Logging sensibler Daten; keine hartcodierten Geheimnisse; bei Treffern `.koolie/core/checklists/06-security.md` anwenden.
+- [ ] **MUSS** (RV8) Keine neue oder erweiterte Verarbeitung personenbezogener Daten; sonst Stufe hoch und `<DATA_PROTECTION_CONTACT>`.
+- [ ] **MUSS** (RV6) Abhängigkeiten, Versionen, Lockfiles, Paketquellen unverändert; sonst `.koolie/core/checklists/07-new-dependency.md` und regulärer Prozess.
+- [ ] **MUSS** Keine K3-Inhalte im Diff, in Kommentaren, Testdaten oder Commit-Nachrichten.
+
+### Konsistenz
+
+- [ ] **MUSS** (RV11) Dokumentation, Kommentare und Commit-Nachricht sind konsistent mit der Änderung; Konventionen (`<PROJECT_RULES_PATH>`, `<COMMIT_CONVENTION>`) eingehalten.
+- [ ] **MUSS** Generierte Reste entfernt (ungenutzte Importe, tote Pfade, auskommentierter Code, Platzhalterkommentare) (Q6, `.koolie/core/framework/core/04-quality.md` Abschnitt 2).
+- [ ] **MUSS** Review-Tiefe entspricht der Kontrollstufe (`.koolie/core/framework/core/07-review-rules.md` Abschnitt 3); ab Stufe mittel führt die Reviewerin oder der Reviewer die Tests selbst aus.
+
+## Abbruch- und Eskalationskriterien
+
+Befunde, die auf Scope-Verlassen, erfundene Fundstellen oder umgangene Quality Gates hindeuten, stoppen die Übernahme (E0/E1). Systematische Befunde über mehrere der KI-Client-Änderungen werden an den Framework Owner gemeldet (`.koolie/core/governance/FEEDBACK_PROCESS.md`, E4). Sicherheits- oder Datenschutzbefunde: Prozess der Organisation, Erfassung nach `.koolie/core/governance/INCIDENT_HANDLING.md` (E3).
+
+## Ergebnis und Nachweis
+
+Selbstreview wird im KI-Nutzungsvermerk bestätigt; unabhängige Review-Befunde und ihre Auflösung stehen im Merge Request. Verworfene Vorschläge werden mit Grund gezählt (Pilotmetrik).

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

@@ -0,0 +1,48 @@
+# Checkliste FW-CL-05 – Tests
+
+| Attribut | Wert |
+|---|---|
+| ID | `FW-CL-05` |
+| Version | `0.1.4` |
+| Status | `pilot` |
+| Owner (Rolle) | `<FRAMEWORK_OWNER>` |
+| Wann | nach Testerstellung oder -änderung (M4) und vor jedem Merge Request mit Logikänderung |
+| Wer | Bearbeiterin oder Bearbeiter; Reviewerin oder Reviewer prüft RV4 |
+| Dauer (Richtwert, Erläuterung) | abhängig vom Testumfang – keine verbindlichen Aufwände |
+| Nachweis | Testprotokoll im Ergebnisbericht (Befehl, Ergebnis, Dauer) |
+
+## Zweck
+
+Sichert, dass Tests aus KI-Sitzungen aussagekräftig sind und geänderte Logik tatsächlich absichern (Q2, M4-Regeln, RV4).
+
+## Prüfpunkte
+
+### Inhalt der Tests
+
+- [ ] **MUSS** Jeder Test prüft fachliches Verhalten mit klarer Erwartung; der Testname beschreibt das erwartete Verhalten.
+- [ ] **MUSS** Abgedeckt sind Normalfall, relevante Randbedingungen (leer/Null, Grenzwerte, ungültige Eingaben) und Fehlerfälle der geänderten Logik.
+- [ ] **MUSS** Tests sind deterministisch (keine Abhängigkeit von Uhrzeit, Zufall, Reihenfolge, Netz, externen Systemen); Ausnahmen sind begründet und markiert.
+- [ ] **MUSS** Testdaten sind synthetisch und als solche gekennzeichnet oder nachweislich anonymisiert (`.koolie/core/framework/core/02-privacy.md` Abschnitt 3.6).
+- [ ] **SOLL** Tests folgen den bestehenden Konventionen (Ablage in `<TEST_PATHS>`, Benennung, Fixtures, `<TEST_FRAMEWORK>`).
+- [ ] **SOLL** Assertions prüfen Ergebnisse und beobachtbares Verhalten, nicht Implementierungsdetails oder reine Mock-Interaktionen.
+
+### 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** Übersprungene oder als erwartet fehlschlagend markierte Tests sind gezählt und begründet.
+
+### Ausführung und Lücken
+
+- [ ] **MUSS** `<TEST_COMMAND>` wurde lokal ausgeführt; das vollständige, unveränderte Ergebnis liegt im Ergebnisbericht (auch Anzahl übersprungener Tests).
+- [ ] **MUSS** Nicht automatisiert prüfbare Anteile sind benannt und mit einem manuellen Prüfschritt versehen.
+- [ ] **SOLL** Verbleibende Abdeckungslücken der geänderten Logik sind gelistet (Grundlage für Folgeaufgaben); Coverage-Schwellen des Projekts (`<QUALITY_GATE>`) bleiben unberührt.
+- [ ] **KANN** Mutationsartige Gegenprobe: ein bewusst eingebauter Fehler in einer Arbeitskopie lässt mindestens einen neuen Test fehlschlagen (Aussagekraftsprobe; Änderung danach verwerfen).
+
+## Abbruch- und Eskalationskriterien
+
+Rote Tests mit Ursache außerhalb des Scopes: anhalten und melden (S7/E0). Testinfrastruktur nicht verfügbar oder Testdaten nur aus Echtdaten ableitbar: anhalten (Abbruchkriterien von M4, `.koolie/core/framework/core/05-working-model.md` Abschnitt 2.2); Echtdaten sind S2 (E0, nach erfolgter Bereitstellung E3, `.koolie/core/framework/core/10-error-escalation.md`). Aufforderungen, Tests „passend zu machen", sind unzulässige Prompt-Muster (`.koolie/core/framework/core/06-prompting-rules.md` Abschnitt 3) und werden zurückgewiesen.
+
+## Ergebnis und Nachweis
+
+Testprotokoll (Befehl, unverändertes Ergebnis, Dauer), Lückenliste und Begründungen für Ausnahmen im Ergebnisbericht; Reviewerin oder Reviewer bestätigt RV4 im Merge Request.

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

@@ -0,0 +1,50 @@
+# Checkliste FW-CL-06 – Security
+
+| Attribut | Wert |
+|---|---|
+| ID | `FW-CL-06` |
+| Version | `0.1.2` |
+| Status | `pilot` |
+| Owner (Rolle) | `<FRAMEWORK_OWNER>` in Abstimmung mit `<SECURITY_CONTACT>` |
+| Wann | bei jeder Änderung mit R3-, R10- oder R11-Bezug; ergänzend zum Review bei Stufe hoch; stichprobenartig bei Stufe mittel |
+| Wer | Bearbeiterin oder Bearbeiter; bei Stufe hoch zusätzlich `<SECURITY_CONTACT>` |
+| Dauer (Richtwert, Erläuterung) | abhängig vom Umfang – keine verbindlichen Aufwände |
+| Nachweis | Security-Abschnitt im Ergebnisbericht und im KI-Nutzungsvermerk (Langform) |
+
+## Zweck
+
+Operationalisiert das Sicherheitsmodell (`.koolie/core/framework/core/03-security.md`) für Änderungen mit Sicherheitsbezug und für die Prüfung KI-typischer Schwächen (T2, T4, T5, T6).
+
+## Prüfpunkte
+
+### 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** 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)
+
+- [ ] **MUSS** Eingaben an Systemgrenzen werden validiert (Länge, Typ, Wertebereich, Kodierung); Validierung liegt auf der Serverseite beziehungsweise der vertrauenswürdigen Seite.
+- [ ] **MUSS** Autorisierung wird in jedem neuen oder geänderten Pfad geprüft (nicht nur in der Oberfläche); keine unbeabsichtigte Rechteausweitung.
+- [ ] **MUSS** Keine Injection-Vektoren: parametrisierte Abfragen, kein String-Zusammenbau für Interpreter (SQL, Shell, Pfade, Ausdrücke), sichere Deserialisierung, kein ungeprüftes Laden von Ressourcen über Nutzereingaben.
+- [ ] **MUSS** Keine hartcodierten Geheimnisse, Schlüssel oder Zugangsdaten; Konfiguration über die vorgesehenen Mechanismen des Projekts.
+- [ ] **MUSS** Logging ohne personenbezogene Daten, Geheimnisse oder Sitzungsartefakte; Fehlermeldungen nach außen ohne Stacktraces, Pfade oder Versionsinterna.
+- [ ] **MUSS** Kryptografie nur über die im Projekt freigegebenen Bibliotheken und Verfahren; keine Eigenbauten, keine veralteten Algorithmen; Zufall aus kryptografisch geeigneten Quellen.
+- [ ] **SOLL** Ressourcen- und Fehlerpfade geschlossen (Timeouts, Freigabe von Handles, kein „fail open" bei Sicherheitsprüfungen).
+- [ ] **SOLL** Sichere Standardwerte: neue Konfigurationsschalter sind restriktiv voreingestellt (P9).
+
+### KI-spezifische Prüfpunkte
+
+- [ ] **MUSS** Ergebnisbericht auf gemeldete Injektionsversuche geprüft (T2); Meldungen sind an `<SECURITY_CONTACT>` weitergegeben.
+- [ ] **MUSS** Abhängigkeiten unverändert; vorgeschlagene neue Abhängigkeiten laufen über `.koolie/core/checklists/07-new-dependency.md` (T4); Paketnamen exakt gegen die Quelle geprüft (halluzinierte Namen, Typosquatting).
+- [ ] **MUSS** Sicherheitsrelevante Aussagen des Vorschlags („validiert", „escaped", „konstant-zeitlich") sind belegt (Fundstelle, Test) und nicht nur behauptet (Q7).
+- [ ] **SOLL** Diff auf entfernte oder umgangene bestehende Sicherheitsprüfungen durchgesehen (auch „vereinfachte" Varianten).
+
+## Abbruch- und Eskalationskriterien
+
+Fund von Secrets oder personenbezogenen Echtdaten: S3/E3 (`.koolie/core/framework/core/10-error-escalation.md`, `.koolie/core/framework/core/02-privacy.md` Abschnitt 5). Verdacht auf ausgenutzte Schwachstelle oder Datenabfluss: V9 – keine eigenständige Weiterarbeit, Meldeweg der Organisation. Unaufgelöste MUSS-Punkte blockieren den Merge.
+
+## Ergebnis und Nachweis
+
+Beantwortete Prüfpunkte mit Fundstellen im Security-Abschnitt des Ergebnisberichts; bei Stufe hoch Gegenzeichnung durch `<SECURITY_CONTACT>` im Merge Request.

package/.koolie/core/checklists/07-new-dependency.md

@@ -0,0 +1,57 @@
+# Checkliste FW-CL-07 – Neue Abhängigkeiten
+
+| Attribut | Wert |
+|---|---|
+| ID | `FW-CL-07` |
+| Version | `0.1.2` |
+| Status | `pilot` |
+| Owner (Rolle) | `<FRAMEWORK_OWNER>` in Abstimmung mit `<SECURITY_CONTACT>` |
+| Wann | bevor eine neue Abhängigkeit oder ein Major-Update eingeführt wird (auch nach einem KI-Vorschlag) |
+| Wer | Bearbeiterin oder Bearbeiter; Freigabe `<APPROVAL_ROLE>`, bei Sicherheitsrelevanz `<SECURITY_CONTACT>` |
+| Dauer (Richtwert, Erläuterung) | abhängig von der Bibliothek – keine verbindlichen Aufwände |
+| Nachweis | ausgefüllte Prüfpunkte im Ticket oder Merge Request; Eintrag der Freigabe |
+
+## Zweck
+
+Abhängigkeiten sind Kontrollstufe hoch (R9) und ihre Einführung ist nicht delegierbar (V3). Diese Liste strukturiert die menschliche Entscheidung nach einem KI-Vorschlag (T4: halluzinierte Pakete, Typosquatting, Lizenzrisiken).
+
+## Prüfpunkte
+
+### Bedarf
+
+- [ ] **MUSS** Der Bedarf ist fachlich begründet; eine Umsetzung mit Bordmitteln des Projekts oder vorhandenen Abhängigkeiten wurde geprüft und verworfen (Begründung dokumentiert).
+- [ ] **MUSS** Der KI-Vorschlag enthält Name, Quelle, Version, Lizenzangabe aus der Manifestdatei, Begründung und Alternativen – und wurde nicht ungeprüft übernommen.
+- [ ] **SOLL** Der Funktionsumfang passt zum Bedarf (keine große Bibliothek für eine Kleinigkeit).
+
+### Identität und Herkunft
+
+- [ ] **MUSS** Das Paket existiert unter exakt diesem Namen im Artefakt-Repository der Organisation; Schreibweise Zeichen für Zeichen geprüft (Typosquatting, halluzinierte Namen).
+- [ ] **MUSS** Bezugsquelle ist ausschließlich das Artefakt-Repository der Organisation; keine zusätzlichen Registries, keine direkten Downloads.
+- [ ] **MUSS** Herausgeber beziehungsweise Projekt sind identifizierbar; das Paket ist keine kürzlich umbenannte oder übernommene Hülle.
+
+### Zustand und Sicherheit
+
+- [ ] **MUSS** Bekannte Schwachstellen der Zielversion geprüft (Werkzeugklasse Dependency-/Security-Scan); keine offenen kritischen Findings ohne dokumentierte Bewertung.
+- [ ] **MUSS** Pflegezustand bewertet: letzte Releases, offene sicherheitsrelevante Issues, Aktivität der Betreuung.
+- [ ] **MUSS** Transitive Abhängigkeiten gesichtet; keine unerwarteten zusätzlichen Quellen oder auffällig große Bäume ohne Bewertung.
+- [ ] **SOLL** Verhalten zur Laufzeit betrachtet: keine ungeklärten Netzwerkzugriffe, Telemetrie oder Codenachladung.
+
+### Lizenz und Recht
+
+- [ ] **MUSS** Lizenzangabe aus der Manifest- oder Lizenzdatei erhoben (Faktensammlung); die rechtliche Bewertung der Lizenzkompatibilität trifft die zuständige Rolle der Organisation (V8), nicht der KI-Client und nicht diese Checkliste.
+- [ ] **MUSS** Lizenz- oder Herkunftsauffälligkeiten (fehlende Lizenz, Copyleft-Fragen, unklare Urheberschaft) sind an die zuständige Rolle gemeldet.
+
+### Einführung
+
+- [ ] **MUSS** Version exakt fixiert; Lockfile wird durch den Menschen mit dem vorgesehenen Werkzeug aktualisiert (nie manuell editiert, nie durch den KI-Client).
+- [ ] **MUSS** Freigabe durch `<APPROVAL_ROLE>` (bei Sicherheitsrelevanz zusätzlich `<SECURITY_CONTACT>`) liegt dokumentiert vor.
+- [ ] **MUSS** Die Einführung ist ein eigener, klar benannter Commit oder Merge Request (Reversibilität, P7).
+- [ ] **SOLL** Das Technology Pack der betroffenen Technologie wird um Hinweise zur neuen Abhängigkeit ergänzt, wenn sie projektprägend ist.
+
+## Abbruch- und Eskalationskriterien
+
+Paket nicht im Artefakt-Repository, Identität unklar, offene kritische Schwachstellen oder Lizenzfragen ungeklärt → keine Einführung; Klärung über E1/E2, bei Sicherheitsverdacht E3 (`.koolie/core/framework/core/10-error-escalation.md`).
+
+## Ergebnis und Nachweis
+
+Ausgefüllte Prüfpunkte, Bewertungsergebnisse und Freigabe (Rolle, Datum) im Ticket oder Merge Request; der KI-Ursprungsvorschlag bleibt als Anlage nachvollziehbar.

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

@@ -0,0 +1,47 @@
+# Checkliste FW-CL-08 – Merge Request
+
+| Attribut | Wert |
+|---|---|
+| ID | `FW-CL-08` |
+| Version | `0.1.3` |
+| Status | `pilot` |
+| Owner (Rolle) | `<FRAMEWORK_OWNER>` |
+| Wann | vor dem Erstellen und vor dem Mergen eines Merge Requests mit KI-Beteiligung |
+| Wer | Bearbeiterin oder Bearbeiter (Erstellen); Reviewerinnen, Reviewer und freigebende Rollen (Mergen) |
+| Dauer (Richtwert, Erläuterung) | wenige Minuten zusätzlich zum Review – keine verbindlichen Aufwände |
+| Nachweis | Merge Request selbst (Beschreibung, Vermerk, Befunde, Freigaben) |
+
+## Zweck
+
+Sichert Schritt 14 des Standardarbeitsablaufs: Übernahme ausschließlich über den bestehenden Review- und Freigabeprozess, mit vollständiger Nachvollziehbarkeit der KI-Beteiligung.
+
+## Prüfpunkte
+
+### 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** 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`).
+- [ ] **MUSS** Keine K3-Inhalte und keine Personennamen in Beschreibung, Commits, Kommentaren oder Anhängen; Rollen statt Personen.
+- [ ] **MUSS** Abhängigkeiten, Lockfiles, CI/CD- und Quality-Gate-Konfiguration unverändert oder über den regulären Prozess begründet (RV6, RV9, `.koolie/core/checklists/07-new-dependency.md`).
+- [ ] **MUSS** Push und Erstellung des Merge Requests erfolgen durch den Menschen (V2).
+- [ ] **SOLL** Commit-Nachrichten folgen `<COMMIT_CONVENTION>`; Änderungsschritte sind einzeln nachvollziehbar (P7).
+- [ ] **MUSS** Offene Punkte und Annahmen aus dem Ergebnisbericht sind adressiert oder im Merge Request sichtbar gemacht (RV12, `.koolie/core/framework/core/07-review-rules.md` Abschnitt 2).
+
+### Vor dem Mergen (Review und Freigabe)
+
+- [ ] **MUSS** Alle Quality Gates der Pipeline sind erfolgreich (`<QUALITY_GATE>`, P6); keine deaktivierten Prüfungen.
+- [ ] **MUSS** Review-Tiefe entspricht der Kontrollstufe: niedrig – vollständiges Lesen des Diffs; mittel – unabhängiges Review aller RV-Punkte und Planabgleich; hoch – zusätzlich Architektur-/Security-Review und Prüfung des Sitzungsprotokolls (`.koolie/core/framework/core/07-review-rules.md` Abschnitt 3).
+- [ ] **MUSS** Erforderliche Freigaben liegen vor (Stufe hoch: `<APPROVAL_ROLE>`, bei R3/R10 `<SECURITY_CONTACT>`); der KI-Client hat keine Freigabe erteilt (V1).
+- [ ] **MUSS** Alle Review-Befunde sind aufgelöst oder mit Begründung zurückgestellt.
+- [ ] **MUSS** Metrikdaten für den Pilot erfasst (`.koolie/core/framework/core/04-quality.md` Abschnitt 4, `.koolie/core/pilot/METRICS.md`).
+
+## Abbruch- und Eskalationskriterien
+
+Fehlender Nutzungsvermerk, rote Gates, unaufgelöste MUSS-Befunde oder fehlende Freigaben blockieren den Merge (E1/E2). Nachträglich entdeckte K3-Inhalte: E3 (`.koolie/core/framework/core/02-privacy.md` Abschnitt 5) und Bereinigung vor jeder weiteren Verarbeitung.
+
+## Ergebnis und Nachweis
+
+Der Merge Request dokumentiert Beschreibung, Vermerk, Befunde, Freigaben und Pipeline-Ergebnisse; er ist damit der zentrale Audit-Nachweis je Änderung (`.koolie/core/framework/core/01-governance.md` Abschnitt 4).

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

@@ -0,0 +1,52 @@
+# Checkliste FW-CL-09 – Onboarding
+
+| Attribut | Wert |
+|---|---|
+| ID | `FW-CL-09` |
+| Version | `0.1.5` |
+| Status | `pilot` |
+| Owner (Rolle) | `<FRAMEWORK_OWNER>` |
+| Wann | während des Onboardings einer neuen Entwicklerin oder eines neuen Entwicklers; Abschluss vor der Freigabe zur selbstständigen Nutzung |
+| Wer | Mentorin oder Mentor gemeinsam mit der oder dem Neuen |
+| Dauer (Richtwert, Erläuterung) | verteilt über die Onboarding-Phase – keine verbindlichen Aufwände |
+| Nachweis | Onboarding-Protokoll (Ablage gemäß Projekt, ohne Bewertungsdetails zur Person) |
+
+## Zweck
+
+Führt durch das Onboarding-Programm (`.koolie/core/onboarding/GUIDE.md`) bis zur dokumentierten Freigabe für die selbstständige KI-Nutzung. Maßstab ist souveräne Nutzung: Aufgaben angemessen abgrenzen, Kontext kontrolliert bereitstellen, Ergebnisse belastbar prüfen – nicht möglichst viel delegieren.
+
+## Prüfpunkte
+
+### Voraussetzungen
+
+- [ ] **MUSS** Zugang zum Projekt-Repository und zum eingesetzten KI-Client vorhanden; Overlay-Status und Rollen des Projekts bekannt.
+- [ ] **MUSS** Datenschutz- und Vertraulichkeitsunterweisung der Organisation absolviert (`<TBD: Referenz auf Unterweisung>`).
+- [ ] **MUSS** `.koolie/core/onboarding/QUICKSTART.md` gelesen; Übungsrepository (`.koolie/core/onboarding/exercises/`) eingerichtet.
+
+### Module (Reihenfolge gemäß `.koolie/core/onboarding/GUIDE.md`)
+
+- [ ] **MUSS** Modul 1 – Möglichkeiten und Grenzen: Leitprinzipien P1–P10, Delegationsverbote V1–V12 erklärt bekommen und an Beispielen eingeordnet.
+- [ ] **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 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 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.
+
+### Abschluss (Modul 10)
+
+- [ ] **MUSS** Wissenstest (`.koolie/core/onboarding/KNOWLEDGE_CHECK.md`) im Selbsttest bestanden (Kriterien in `.koolie/core/onboarding/COMPLETION_CRITERIA.md`); der Test dient der Selbstkontrolle, nicht der Personalbeurteilung.
+- [ ] **MUSS** Erfolgskriterien aus `.koolie/core/onboarding/COMPLETION_CRITERIA.md` gemeinsam durchgegangen; offene Punkte mit Folgeplan notiert.
+- [ ] **MUSS** Freigabe zur selbstständigen Nutzung durch Mentorin oder Mentor dokumentiert (Datum, Rolle); bis dahin arbeitet die oder der Neue nur begleitet mit dem KI-Client.
+- [ ] **SOLL** Nachschlagewerk (`.koolie/core/onboarding/REFERENCE.md`) und Feedbackweg (`.koolie/core/governance/FEEDBACK_PROCESS.md`) bekannt.
+
+## Abbruch- und Eskalationskriterien
+
+Wiederholte Regelverstöße in Übungen (zum Beispiel Übernahme ungeprüfter Ergebnisse, K3-Weitergabe) verlängern das begleitete Arbeiten; die Mentorin oder der Mentor entscheidet über zusätzliche Module (E0/E1). Das Onboarding-Protokoll enthält Sachstände, keine Leistungsbewertungen (V7).
+
+## Ergebnis und Nachweis
+
+Abgehakte Module, bestandener Selbsttest und dokumentierte Freigabe im Onboarding-Protokoll; die Freigabe wird im Projekt vermerkt (Rolle, Datum).