@renoxar/koolie 1.25.0

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

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

package/.koolie/core/framework/role-packs/README.md

@@ -0,0 +1,63 @@
+# Role Packs (Ebene 6 der Prioritätshierarchie)
+
+Role Packs sind optionale, rollenbezogene Module. Sie konkretisieren die Arbeitsweise für eine Rolle (Softwareentwicklung, Softwarearchitektur, Requirements Engineering, Testing und QA, DevOps, Dokumentation, Code Review) und liefern rollenspezifische Skills.
+
+## Verbindliche Regeln für Role Packs
+
+1. Ein Role Pack enthält **keine** Governance-, Datenschutz- oder Sicherheitsregeln und **keine** Projektwerte. Solche Inhalte gehören in den Core (Ebene 3) beziehungsweise das Overlay (Ebene 4). Bei Zweifeln: `.koolie/core/decision-trees/06-rule-placement.md`.
+2. Ein Role Pack darf Core- und Overlay-Regeln nur konkretisieren oder verschärfen, nie lockern.
+3. Aufbau je Pack: `ROLE_PACK.md` (Langform), optional `skills/` (Quellablage rollenspezifischer Skills, Präfix `role-<pack>-`, werden zur Aktivierung in die Skill-Ablage kopiert) und eine Laufzeitfassung `30-role-<pack>.md` in der Regelablage. Sie trägt den Ladetrigger `model_decision` und lädt bei Relevanz; kennt ein Client keine modellentschiedene Ladebedingung, lädt sie dort unbedingt – eine Verschärfung, die sein Client Pack ausweist (`.koolie/core/docs/RUNTIME_GLOSSARY.md`).
+4. Ein Pack wird im Overlay aktiviert (Abschnitt 1, Zeile „Aktivierte Role Packs", und Laufzeitfassung vorhanden; Prüfung 110 hält beides gegeneinander). Nicht aktivierte Packs liegen nur im Verzeichnis `.koolie/core/framework/role-packs/` und werden vom KI-Client nicht als Regel geladen.
+5. Jedes Pack hat einen Modul-Owner (`.koolie/core/OWNERS.md`), eine Version und einen Änderungsverlauf.
+
+## Verfügbare Packs
+
+| Pack | Status | Laufzeitfassung | Owner |
+|---|---|---|---|
+| `software-development` | entwurf (Referenz) | `30-role-software-development.md` in der Regelablage | `<FRAMEWORK_OWNER>` |
+| `software-architecture` | vorgesehen | – | `<TBD>` |
+| `requirements-engineering` | entwurf | `30-role-requirements-engineering.md` in der Regelablage | `<FRAMEWORK_OWNER>` |
+| `testing-qa` | vorgesehen | – | `<TBD>` |
+| `devops` | vorgesehen | – | `<TBD>` |
+| `documentation` | vorgesehen | – | `<TBD>` |
+| `code-review` | vorgesehen | – | `<TBD>` |
+
+Neue Packs entstehen aus `_template/ROLE_PACK.md`.
+
+## Quellablage der Laufzeitfassung
+
+Jedes Pack legt seine Laufzeitfassung unter `<pack>/runtime/30-role-<pack>.md` ab und seine Skills – falls vorhanden – unter `<pack>/skills/`. Zur Aktivierung werden beide in die Laufzeitschicht kopiert:
+
+```bash
+# <Regelablage> und <Skill-Ablage> sind die Pfade des installierten Client Packs;
+# ihre Entsprechung je Pack steht in .koolie/core/docs/RUNTIME_GLOSSARY.md.
+cp .koolie/core/framework/role-packs/<pack>/runtime/30-role-<pack>.md <Regelablage>/
+cp -r .koolie/core/framework/role-packs/<pack>/skills/* <Skill-Ablage>/    # falls vorhanden
+python .koolie/core/install.py --update    # bringt die Laufzeitfassung in die Form des Client Packs
+```
+
+🔴 **Der dritte Befehl ist kein Nachklapp, und das ist gemessen** (2026-09-21, D-244). `cp` legt die **Quellform** ab – YAML-Frontmatter mit `description` und `trigger`. Ein Client, der für Regeldateien eine **eigene Bedingungssprache** führt, wertet diese Felder nicht aus (`claude-code`: nur `paths`, `K-18`); der Validator meldete am Messbaum von Bündel 5 **zwei Fehler** an genau dieser Datei, und die Ladebedingung `model_decision` war nirgends abgebildet. `install.py` kann die Abbildung seit `0.14.0` – `ist_regelquelle()` führt die Laufzeitfassungen aktivierter Packs ausdrücklich auf –, **aber nur, wenn man ihn danach laufen lässt.** Für `devin-desktop` ist Quellform gleich Zielform; dort war der fehlende Befehl folgenlos, und deshalb ist er acht Releases lang niemandem aufgefallen.
+
+> *Ein Werkzeug, das eine Abbildung kann, und eine Anleitung, die „kopieren“ sagt: Die Anleitung gewinnt, weil sie gelesen wird.*
+
+🔴 **Und ein weiterer Schritt, den diese Anleitung bis `0.81.0` nicht nannte: der
+Skill gehört in die Berechtigungsdatei.** Je kopiertem Skill kommt ein Eintrag der
+Form `<Werkzeug>(<skillname>)` hinzu – welches Werkzeug, sagt `permission_tools.skill`
+im Manifest des Client Packs (bei `claude-code` `Skill`, bei `devin-desktop` ist das
+Feld leer, weil dort keine Schreibweise bekannt ist, D-89).
+
+**Warum das nicht in `framework/runtime/permissions.json` steht:** Eine Regel dort
+trägt **jede** Installation, auch die, die das Pack nicht aktiviert hat – und eine
+Vorabfreigabe für einen Skill, den es nicht gibt, ist eine Zusage ohne Gegenstand
+(Prüfung 39, D-81). Die Aktivierung ist eine Projektentscheidung (Punkt 4), also
+gehört der Eintrag zu ihr.
+
+**Was ohne ihn geschieht, ist gemessen** (2026-09-21, D-238): Der Aufruf fällt in den
+Rückfragekorb und im rückfragefreien Betrieb in die Abweisung; die Sitzung liest die
+`SKILL.md` dann ersatzweise als Datei – **ohne die Werkzeugbeschränkung des Skills.**
+🟢 **Prüfung 72 setzt es seither durch**, in beide Richtungen: ein Skill ohne Eintrag
+und ein Eintrag ohne Skill werden beide gemeldet.
+
+`.koolie/core/install.py` nimmt diesen Schritt bewusst nicht vorweg: **Die Aktivierung eines Packs ist eine Projektentscheidung** (Punkt 4), kein Installationsschritt. Kein Pack ist nach einer Erstinstallation aktiv – auch nicht das Referenzpack `software-development`.
+
+Einmal aktiviert, gehören die kopierten Bestandteile aber zum Aktualisierungsumfang: `install.py --update` bringt sie auf den Stand des Releases, `--check` meldet lokale Abweichungen. Die Unterscheidung ist also: *ob* ein Pack aktiv ist, entscheidet das Projekt – *was* darin steht, ist Framework-Inhalt.

package/.koolie/core/framework/role-packs/_template/ROLE_PACK.md

@@ -0,0 +1,58 @@
+# Role Pack `<ROLE_PACK_NAME>` – Vorlage
+
+<!-- AUSFÜLLHINWEIS: Kopiere dieses Verzeichnis nach ../<role-pack-name>/, ersetze alle Platzhalter,
+     erstelle die Laufzeitfassung unter ../<role-pack-name>/runtime/30-role-<role-pack-name>.md
+     (unter 12.000 Zeichen, trigger: model_decision) und trage das Pack in ../README.md und
+     .koolie/core/OWNERS.md ein. Erst die Aktivierung kopiert sie in die Regelablage.
+     Keine Governance-Regeln, keine Projektwerte.
+     Die Statuszelle ist ein Ausfüllschlitz: Ein neues Pack beginnt auf entwurf; der Lebenszyklus
+     steht in .koolie/core/framework/core/01-governance.md Abschnitt 5 (D-104). -->
+
+| Attribut | Wert |
+|---|---|
+| Modul-ID | `RP-<ROLE_PACK_CODE>` |
+| Ebene | 6 – Role Pack |
+| Version | 0.1.2 |
+| Status | `<TBD: Status; ein neues Pack beginnt auf entwurf>` |
+| Owner | `<TBD: Rolle>` |
+| Zielrolle | `<TBD: z. B. Requirements Engineer>` |
+
+## 1. Zweck und Abgrenzung
+
+`<TBD: Welche Aufgaben dieser Rolle unterstützt der KI-Client, welche ausdrücklich nicht (Verweis auf Delegationsverbotsliste)>`
+
+## 2. Typische Aufgaben mit Betriebsmodus und Kontrollstufe
+
+| Aufgabe | Modus | Typische Kontrollstufe | Skill |
+|---|---|---|---|
+| `<TBD>` | `<M1–M6>` | `<niedrig/mittel/hoch>` | `<fw-... / role-<pack>-...>` |
+
+## 3. Arbeitsweise (Konkretisierung des Standardarbeitsablaufs)
+
+`<TBD: nummerierte Regeln, jeweils als MUSS/SOLL/KANN gekennzeichnet>`
+
+## 4. Rollenspezifische Kontextquellen
+
+| Quelle | Typische Kontextklasse | Hinweis |
+|---|---|---|
+| `<TBD>` | `<K1/K2>` | `<TBD>` |
+
+## 5. Rollenspezifische Prüfpunkte
+
+`<TBD: Ergänzungen zu .koolie/core/checklists/04-review-ai-code.md>`
+
+## 6. Rollenspezifische Skills
+
+| Skill | ID | Status | Zweck |
+|---|---|---|---|
+| `role-<pack>-<TBD>` | `RP-<ROLE_PACK_CODE>-SK-001` | entwurf | `<TBD>` |
+
+## 7. Typische Fehlanwendungen in dieser Rolle
+
+`<TBD>`
+
+## 8. Änderungsverlauf
+
+| Version | Datum | Änderung | Autor (Rolle) |
+|---|---|---|---|
+| 0.1.0 | `<TBD>` | angelegt | `<TBD>` |

package/.koolie/core/framework/role-packs/requirements-engineering/ROLE_PACK.md

@@ -0,0 +1,158 @@
+# Role Pack Requirements Engineering
+
+| Attribut | Wert |
+|---|---|
+| Modul-ID | RP-RE |
+| Ebene | 6 – Role Pack |
+| Version | 0.1.4 |
+| Status | pilot |
+| Owner | `<FRAMEWORK_OWNER>` (bis zur Benennung eines Modul-Owners) |
+| Zielrolle | Requirements Engineering, Product Owner, fachlich zuarbeitende Entwicklung |
+| Laufzeitfassung | `30-role-requirements-engineering.md` in der Regelablage |
+| Skills | `role-re-ticket` (`RP-RE-SK-001`) |
+
+## 1. Zweck und Abgrenzung
+
+Dieses Pack konkretisiert das Arbeitsmodell für die **Formulierung von Anforderungen**: aus einer Absicht, einem Gesprächsergebnis oder einer Fehlermeldung eine prüfbare, umsetzungsreife Aufgabenbeschreibung machen — mit Anforderungen in EARS-Syntax, abgeleiteten Arbeitspaketen, überprüfbaren Abnahmekriterien und einer verständlichen Änderungsmitteilung.
+
+Der Unterschied zu einer reinen Textarbeit ist der **Einbezug der Codebasis**: Bevor eine Anforderung formuliert wird, wird geprüft, was es schon gibt, welche Begriffe der Code verwendet und welche Randbedingungen sich aus Datenmodell und Schnittstellenvertrag ergeben. Eine Anforderung, die eine bereits vorhandene Funktion beschreibt oder gegen ein Schema arbeitet, kostet im Verlauf mehr als die Recherche vorher.
+
+**Nicht Gegenstand dieses Packs:**
+
+| Nicht enthalten | Zuständig |
+|---|---|
+| Entscheidung, **ob** und **wann** etwas gebaut wird | `<PRODUCT_OWNER_ROLE>` |
+| Priorisierung, Aufwandsschätzung, Terminzusagen | `<PRODUCT_OWNER_ROLE>`, Projektleitung |
+| Architektur- und Technologieentscheidungen | `<ARCHITECT_ROLE>`, V3 der Delegationsverbotsliste |
+| Risikobewertung und Kontrollstufenvorschlag einer Änderung | `fw-change-analyze` |
+| Änderungsplan für die Umsetzung | `fw-plan` |
+| Eintragen oder Ändern von Vorgängen im Ticketsystem | Mensch (V11: keine Außenkommunikation im Namen des Projekts) |
+
+## 2. Der zentrale Grundsatz dieses Packs
+
+> **Der Ist-Zustand ist keine Anforderung.**
+
+Wer Code liest, während er Anforderungen formuliert, gerät in eine Falle: Aus „der Code antwortet mit 409" wird schnell „das System soll mit 409 antworten". Das ist keine Anforderung, sondern eine Beschreibung — und ob 409 fachlich richtig ist, hat niemand entschieden. Sobald so etwas als Anforderung in ein Ticket gerät, ist die Implementierung ihre eigene Spezifikation geworden und jede Prüfung zirkulär.
+
+Dieses Pack trennt deshalb verbindlich drei Kategorien:
+
+| Kategorie | Herkunft | Kennzeichnung | Formulierung |
+|---|---|---|---|
+| **Anforderung** | ausschließlich vom Menschen | EARS-Liste | `shall` |
+| **Befund** | aus dem Code, mit Fundstelle | „Ist-Zustand: …" | Indikativ, nie `shall` |
+| **Randbedingung** | aus Schema, Vertrag, Migration, durch Tests zugesichertem Verhalten, mit Fundstelle | „Randbedingung (belegt): …" | Indikativ, nie `shall` |
+
+Ein Befund kann eine Anforderung **auslösen** — aber erst, nachdem ein Mensch entschieden hat, dass das Verhalten so bleiben oder sich ändern soll. Der Skill legt diese Entscheidung offen, statt sie stillschweigend zu treffen.
+
+## 3. Typische Aufgaben mit Betriebsmodus und Kontrollstufe
+
+| Aufgabe | Modus | Typische Kontrollstufe | Skill |
+|---|---|---|---|
+| Neue Anforderung aus einer Absicht formulieren | M1 | niedrig | `role-re-ticket` |
+| Bestehende Aufgabenbeschreibung überarbeiten | M1 | niedrig | `role-re-ticket` |
+| Fehlermeldung in eine Aufgabenbeschreibung überführen | M1 | niedrig–mittel | `role-re-ticket`, davor `fw-error-analyze` |
+| Prüfen, was eine Anforderung technisch berührt | M1 | niedrig–mittel | `fw-change-analyze` |
+| Codebasis für die Recherche kennenlernen | M1 | niedrig | `fw-repo-analyze` |
+| Umsetzung planen | M2 | mittel | `fw-plan` |
+
+Alle Aufgaben dieses Packs sind **M1 Read-only Analysis**: Der Skill liest und gibt Text aus. Er schreibt keine Datei und trägt nichts in ein Ticketsystem ein. Soll der Entwurf im Repository abgelegt werden, ist das ein eigener Schritt in M5 durch den Menschen.
+
+## 4. Zusammenspiel mit den Framework-Skills
+
+```text
+Absicht, Gespräch, Fehlermeldung
+        │
+        ▼
+  role-re-ticket ──── enge Recherche: Gibt es das schon? Welche Begriffe
+        │             nutzt der Code? Welche Randbedingungen gelten?
+        │             Ergebnis: Aufgabenbeschreibung mit EARS-Anforderungen
+        ▼
+  fw-change-analyze ── Vollanalyse: betroffene Komponenten, Verwender,
+        │             Testlücken, Risiken R1–R13, Kontrollstufenvorschlag
+        ▼
+  fw-plan ─────────── Änderungsplan (M2)
+        ▼
+  fw-change-small / fw-tests / fw-refactor (M3/M4)
+```
+
+**Bewusste Aufgabenteilung:** `role-re-ticket` bewertet **kein** Risiko und schlägt **keine** Kontrollstufe vor. Das leistet `fw-change-analyze` mit ausgearbeiteter Faktorenliste. Zwei Skills, die dieselbe Codeanalyse mit unterschiedlicher Tiefe machen, liefern über die Zeit widersprüchliche Ergebnisse — deshalb recherchiert `role-re-ticket` nur so weit, wie es zum Formulieren nötig ist, und empfiehlt den Folge-Skill.
+
+## 5. Werkzeug- und Sprachneutralität
+
+Das Pack verdrahtet kein Ticketsystem und keine Sprache. Beides kommt aus dem Overlay:
+
+| Wert | Quelle im Overlay | Wirkung |
+|---|---|---|
+| `<ISSUE_TRACKER>` | Abschnitt 13 | bestimmt die Auszeichnungssyntax der Ausgabe |
+| Sprache von Bezeichnern, Kommentaren, Prosa | Abschnitt 9 | bestimmt, was in welcher Sprache formuliert wird |
+| `<PROJECT_RULES_PATH>` | Abschnitt 9 | Fachbegriffe und Namenskonventionen |
+| Glossar (Manifest-Typ `glossary`) | Abschnitt 19 | verbindliche Fachbegriffe |
+
+Unterstützte Auszeichnungsformen: **JIRA-Wiki** (`h2.`, `||…||`, `#`-Listen), **Markdown** (`##`, Pipe-Tabellen) und **neutral** (Klartext mit Überschriftenzeilen). Ist `<ISSUE_TRACKER>` im Overlay nicht gesetzt oder unbekannt, fragt der Skill nach, statt eine Syntax zu unterstellen.
+
+## 6. Anforderungssyntax: EARS
+
+Funktionale Anforderungen werden nach **EARS** (Easy Approach to Requirements Syntax) formuliert. Die Muster:
+
+| Muster | Form | Anwendung |
+|---|---|---|
+| Ubiquitär | `Das <System> shall <Verhalten>.` | dauerhaft geltendes Verhalten |
+| Ereignisgetrieben | `When <Auslöser>, das <System> shall <Verhalten>.` | Reaktion auf ein Ereignis |
+| Zustandsgetrieben | `While <Zustand>, das <System> shall <Verhalten>.` | Verhalten in einem Zustand |
+| Unerwünschtes Verhalten | `If <Bedingung>, then das <System> shall <Verhalten>.` | Fehler- und Ausnahmefälle |
+| Optionales Merkmal | `Where <Merkmal zutrifft>, das <System> shall <Verhalten>.` | konfigurierbare Funktionen |
+
+**Regeln:**
+
+1. Ein Hauptverhalten je Anforderung. Unabhängig prüfbare Verhalten werden getrennt.
+2. Keine unbestimmten Wörter: *angemessen*, *geeignet*, *schnell*, *benutzerfreundlich*, *bei Bedarf*, *möglichst*, *gegebenenfalls* — es sei denn, das Overlay oder das Glossar definiert sie messbar.
+3. EARS wird nicht auf rein technische Arbeitspakete gezwungen. Ein Arbeitspaket ist keine Anforderung.
+4. Erfordert die EARS-Form eine Annahme, die die Anforderung inhaltlich verändert (ein erfundener Auslöser, ein erfundener Fehlerfall), wird **nachgefragt** statt formuliert.
+
+## 7. Nachvollziehbarkeit
+
+```text
+Anforderung (was das System soll)
+      │
+      ▼
+Arbeitspaket (was zu tun ist)
+      │
+      ▼
+Abnahmekriterium (woran Fertigstellung erkennbar ist)
+```
+
+Jede Anforderung hat mindestens ein Arbeitspaket und mindestens ein Abnahmekriterium. Ein Abnahmekriterium ist keine wörtliche Kopie der Anforderung, sondern deren Umformulierung als **beobachtbares, abgeschlossenes Ergebnis**. Drei unterschiedlich formulierte Fassungen desselben Satzes sind ein Mangel, keine Nachvollziehbarkeit.
+
+## 8. Umgang mit Kontext und Datenschutz
+
+Aufgabenbeschreibungen und Ticketinhalte sind in der Regel **K2** (`.koolie/core/framework/core/02-privacy.md`): Sie werden je Aufgabe freigegeben und bereinigt übergeben. Für dieses Pack gilt zusätzlich:
+
+1. In den Entwurf gelangen **keine** Personennamen, Kundennamen, Behördennamen, Kennungen, Adressen oder Zugangsdaten — auch nicht, wenn sie in der Eingabe stehen. Rollen statt Personen.
+2. Beispieldaten im Entwurf sind synthetisch und als solche gekennzeichnet.
+3. Findet der Skill in der Eingabe oder im Code K3-Inhalte, gibt er sie nicht wieder, nennt die Fundstelle und hält an.
+4. Die projektlokale Sperrbegriffsliste (`.koolie/project-overlay/forbidden-terms.txt`) gilt auch für Entwürfe.
+
+## 9. Aktivierung im Projekt
+
+1. Rolle im Overlay Abschnitt 1 („Rollen im Team") aufführen.
+2. Laufzeitfassung kopieren:
+   `.koolie/core/framework/role-packs/requirements-engineering/runtime/30-role-requirements-engineering.md`
+   → `30-role-requirements-engineering.md` in der Regelablage
+3. Skill kopieren:
+   `.koolie/core/framework/role-packs/requirements-engineering/skills/role-re-ticket/`
+   → `role-re-ticket/` in der Skill-Ablage
+3a. `python .koolie/core/install.py --update` ausführen – er bringt die kopierte Laufzeitfassung in die Form des installierten Client Packs. 🔴 **Ohne diesen Schritt steht dort die Quellform**, und ein Client mit eigener Bedingungssprache wertet Felder aus, die er für Regeldateien nicht kennt (`K-18`, gemessen 2026-09-21: zwei Validatorfehler).
+3b. Den Skill in die **Berechtigungsdatei** eintragen – `<Werkzeug>(role-re-ticket)` nach `permission_tools.skill` des Client Packs. 🔴 **Ohne den Eintrag fällt der Aufruf in den Rückfragekorb und im rückfragefreien Betrieb in die Abweisung**; die Sitzung liest die `SKILL.md` dann ersatzweise als Datei, ohne die Werkzeugbeschränkung des Skills (D-81, D-238). **Prüfung 72** setzt es in beide Richtungen durch.
+4. `<ISSUE_TRACKER>` im Overlay Abschnitt 13 setzen und die Sprachregeln in Abschnitt 9 prüfen.
+5. Ein Glossar als Manifest-Typ `glossary` registrieren, falls vorhanden — der Skill nutzt es für verbindliche Fachbegriffe.
+6. Validieren: `python .koolie/core/tests/scripts/validate-framework.py --strict-overlay`
+
+Nicht aktivierte Packs liegen nur im Verzeichnis und werden vom KI-Client nicht als Regel geladen.
+
+## 10. Änderungsverlauf
+
+| Version | Datum | Änderung | Autor (Rolle) |
+|---|---|---|---|
+| 0.1.0 | 2026-09-09 | angelegt: Pack, Skill `role-re-ticket`, Laufzeitfassung | `<FRAMEWORK_OWNER>` |
+| 0.1.2 | 2026-09-21 | Abschnitt 9: Die Aktivierung hat vier Schritte statt zwei – die kopierte Laufzeitfassung wird über `install.py --update` in die Form des Client Packs gebracht (3a), und der Skill gehört in die Berechtigungsdatei (3b). Beides gemessen am Messbaum von Bündel 5 (`CR-2026-115`, D-244; D-238) | `<FRAMEWORK_OWNER>` |
+| 0.1.4 | 2026-09-25 | Abschnitt 2: Als Herkunft einer Randbedingung gilt auch durch Tests zugesichertes Verhalten, wie in `role-re-ticket` und der Laufzeitfassung (`CR-2026-147`, D-402, K-149) | `<FRAMEWORK_OWNER>` |

package/.koolie/core/framework/role-packs/requirements-engineering/runtime/30-role-requirements-engineering.md

@@ -0,0 +1,88 @@
+---
+description: Role Pack Requirements Engineering (Ebene 6). Anwenden bei der Formulierung oder Überarbeitung von Anforderungen und Aufgabenbeschreibungen, auch wenn dafür die Codebasis herangezogen wird.
+trigger: model_decision
+---
+
+# Role Pack Requirements Engineering (Laufzeitfassung)
+
+Quelle und Detailfassung: `.koolie/core/framework/role-packs/requirements-engineering/ROLE_PACK.md`.
+Skill: `/role-re-ticket`. Enthält ausschließlich rollenbezogene Arbeitsweise — keine
+Governance-Regeln (Core) und keine Projektwerte (Overlay).
+
+## Der zentrale Grundsatz
+
+**Der Ist-Zustand ist keine Anforderung.** Wer Code liest, während er Anforderungen
+formuliert, macht aus „der Code antwortet mit 409" schnell „das System soll mit 409
+antworten". Damit wird die Implementierung ihre eigene Spezifikation und jede Prüfung
+zirkulär. Deshalb sind drei Kategorien strikt zu trennen:
+
+| Kategorie | Herkunft | Kennzeichnung | Formulierung |
+|---|---|---|---|
+| **Anforderung** | ausschließlich vom Menschen | EARS-Liste | `shall` |
+| **Befund** | aus dem Code, mit Fundstelle | „Ist-Zustand: …" | Indikativ, nie `shall` |
+| **Randbedingung** | aus Schema, Vertrag, Migration, Test, mit Fundstelle | „Randbedingung (belegt): …" | Indikativ, nie `shall` |
+
+Ein Befund kann eine Anforderung auslösen — aber erst, nachdem ein Mensch entschieden hat.
+Diese Entscheidung wird offengelegt, nicht getroffen.
+
+## Anforderungen: EARS
+
+| Muster | Form |
+|---|---|
+| Ubiquitär | `Das <System> shall <Verhalten>.` |
+| Ereignisgetrieben | `When <Auslöser>, das <System> shall <Verhalten>.` |
+| Zustandsgetrieben | `While <Zustand>, das <System> shall <Verhalten>.` |
+| Unerwünschtes Verhalten | `If <Bedingung>, then das <System> shall <Verhalten>.` |
+| Optionales Merkmal | `Where <Merkmal zutrifft>, das <System> shall <Verhalten>.` |
+
+- Ein Hauptverhalten je Anforderung; unabhängig prüfbare Verhalten werden getrennt.
+- Keine unbestimmten Wörter: *angemessen*, *geeignet*, *schnell*, *benutzerfreundlich*, *bei Bedarf*, *möglichst*, *gegebenenfalls* — es sei denn, Overlay oder Glossar definiert sie messbar.
+- EARS wird nicht auf technische Arbeitspakete gezwungen. Ein Arbeitspaket ist keine Anforderung.
+- Erfordert die EARS-Form eine Annahme, die die Anforderung inhaltlich verändert: **nachfragen**, nicht formulieren.
+
+## Nachvollziehbarkeit
+
+Anforderung (was das System soll) → Arbeitspaket (was zu tun ist) → Abnahmekriterium (woran
+Fertigstellung erkennbar ist). Jede Anforderung hat mindestens ein Arbeitspaket und mindestens
+ein Abnahmekriterium. Ein Abnahmekriterium ist die Umformulierung als **beobachtbares,
+abgeschlossenes Ergebnis**, keine wörtliche Kopie. Drei unterschiedlich formulierte Fassungen
+desselben Satzes sind ein Mangel.
+
+## Werkzeug und Sprache kommen aus dem Overlay
+
+- Auszeichnungssyntax richtet sich nach `<ISSUE_TRACKER>` (Overlay Abschnitt 13): JIRA-Wiki, Markdown oder neutral. Ist der Wert nicht gesetzt: **nachfragen**, keine Syntax unterstellen.
+- Sprache von Bezeichnern, Prosa und Änderungsmitteilung nach Overlay Abschnitt 9.
+- Fachbegriffe aus dem registrierten Glossar und `<PROJECT_RULES_PATH>`. Fehlt ein Begriff: als offenen Punkt führen, keinen Begriff neu definieren.
+
+## Grenzen dieser Rolle
+
+Nicht Gegenstand — jeweils mit Zuständigkeit:
+
+| Nicht enthalten | Zuständig |
+|---|---|
+| Entscheidung, ob und wann etwas gebaut wird | `<PRODUCT_OWNER_ROLE>` |
+| Priorität, Aufwand, Termin, Zuständigkeit | `<PRODUCT_OWNER_ROLE>`, Projektleitung |
+| Architektur-, Technologie- und Abhängigkeitsentscheidungen | `<ARCHITECT_ROLE>` (V3) |
+| Risikobewertung und Kontrollstufenvorschlag | `fw-change-analyze` |
+| Änderungsplan | `fw-plan` |
+| Eintragen oder Ändern von Vorgängen im Ticketsystem | Mensch (V11) |
+
+Alle Aufgaben dieser Rolle sind **M1**: lesen und Text ausgeben. Keine Datei wird geschrieben,
+kein Vorgang angelegt. Soll der Entwurf im Repository liegen, ist das ein eigener Schritt in
+M5 durch den Menschen.
+
+## Reihenfolge im Ablauf
+
+`role-re-ticket` (Anforderung formulieren) → `fw-change-analyze` (Risiken, Kontrollstufe) →
+`fw-plan` (Plan) → Umsetzung. `role-re-ticket` recherchiert nur so weit, wie es zum
+Formulieren nötig ist, und bewertet **kein** Risiko — zwei Skills mit derselben Analyse in
+unterschiedlicher Tiefe liefern über die Zeit widersprüchliche Ergebnisse.
+
+## Kontext und Datenschutz
+
+Aufgabenbeschreibungen sind in der Regel **K2**: je Aufgabe freigegeben, bereinigt übergeben.
+In einen Entwurf gelangen **keine** Personen-, Kunden- oder Behördennamen, Kennungen, Adressen
+oder Zugangsdaten — auch nicht, wenn sie in der Eingabe stehen. Rollen statt Personen.
+Beispieldaten sind synthetisch und gekennzeichnet. Die projektlokale Sperrbegriffsliste
+(`.koolie/project-overlay/forbidden-terms.txt`) gilt auch für Entwürfe. Bei einem K3-Fund: nicht
+wiedergeben, Fundstelle nennen, anhalten.

package/.koolie/core/framework/role-packs/requirements-engineering/skills/role-re-ticket/CHANGELOG.md

@@ -0,0 +1,10 @@
+# role-re-ticket – Änderungsverlauf
+
+| Version | Datum | Änderung | Autor (Rolle) |
+|---|---|---|---|
+| 0.1.0 | 2026-09-09 | Erstfassung (Status entwurf): Aufgabenbeschreibung mit EARS-Anforderungen, Arbeitspaketen, Abnahmekriterien und Änderungsmitteilung; enge Codebasis-Recherche mit Belegpflicht; verbindliche Trennung von Anforderung, Befund und Randbedingung; werkzeug- und sprachneutral über Overlay-Werte | `<FRAMEWORK_OWNER>` |
+| 0.1.1 | 2026-09-10 | Pfadnennungen dem umbenannten Kernverzeichnis angepasst (`CR-2026-009`); Versionsanhebung nachgeholt (`CR-2026-015`) | `<FRAMEWORK_OWNER>` |
+| 0.1.2 | 2026-09-10 | „Devin“ als Akteursbezeichnung durch den werkzeugneutralen Begriff „KI-Client“ ersetzt (`CR-2026-020`) | `<FRAMEWORK_OWNER>` |
+| 0.1.3 | 2026-09-19 | Version der Ausgabevorlage wird aus dem Steckbrief abgeleitet statt gepflegt (`CR-2026-094`, D-185) | `<FRAMEWORK_OWNER>` |
+| 0.1.4 | 2026-09-22 | Abschnitt 5 vereinbart eine **Schreibweise für das Aussetzen**: Ein Abschnitt, dessen Inhalt nicht bestimmbar ist, bleibt mit seiner Überschrift stehen und trägt `<TBD: ausgesetzt, weil …>`; nur ein sachlich nicht einschlägiger Abschnitt wird weggelassen. Bis `0.1.3` stand dort allein *„Abschnitte ohne Inhalt werden weggelassen“*, und zwei gemessene Läufe haben sich je eine eigene Form ausgedacht – deshalb konnte kein Prüfmittel sie kennen (`CR-2026-117`, `K-90`, D-258) | `<FRAMEWORK_OWNER>` |
+| 0.1.5 | 2026-09-22 | Pfadnennungen der Umbenennung auf `Koolie` angepasst; Kernverzeichnis `.koolie/core/`, Overlay `.koolie/project-overlay/` (`CR-2026-122`, D-299). **Keine Anweisung beruehrt** - die Zellen des Testblatts bleiben abgenommen (D-303) | `<FRAMEWORK_OWNER>` |