@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-024-clientbindungen.md

@@ -0,0 +1,78 @@
+# Änderungsantrag `CR-2026-024`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die letzten Client-Bindungen des Kerns – und die Prüfung, die sie nicht sehen konnte |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | 14 Kerndateien, ein Dateiname, `tests/scripts/validate-framework.py` (Prüfung 14 erweitert) |
+| Ebene laut Entscheidungsbaum 6 | Kerndokumentation und Prüfung; keine Regeländerung |
+| Art | Abarbeitung der mit `CR-2026-020` ausgewiesenen Restpunkte |
+| Dringlichkeit | regulär |
+
+## 1. Anlass und Problem
+
+`CR-2026-020` hat 248 Akteursnennungen aus dem Kern gelöst und mit Prüfung 14 durchgesetzt. Drei
+Punkte blieben ausdrücklich ausgewiesen und offen:
+
+- der Dateiname `decision-trees/02-may-devin-do-task.md`,
+- der Marker `VERIFY AGAINST CURRENT <name> DOCUMENTATION` „an fünf Kernstellen",
+- die clientspezifischen Inhalte der Zeile „Umsetzung beim KI-Client" in `05-working-model.md`.
+
+**Die Zählung war wieder zu niedrig.** Statt fünf Markerstellen waren es **acht** in
+Markdown-Dateien und **zwei weitere in den Kernskripten** – letztere hatte die manuelle Zählung
+übersehen, weil sie nur `*.md` durchsucht hatte. Gefunden hat sie erst die neue Prüfung.
+
+Das ist derselbe Vorgang wie bei `CR-2026-020` selbst, wo die Roadmap 76 Nennungen führte und es
+248 waren. **Eine von Hand erhobene Zahl über den eigenen Zustand ist im Mittel zu klein** – und
+zwar systematisch, weil man dort zählt, wo man den Fehler vermutet.
+
+### Warum Prüfung 14 den Marker nicht fand
+
+Sie sucht den **kapitalisierten** Clientnamen (`Devin`, `Claude`). Ein Platzhalter schreibt ihn
+**groß**: `<VERIFY AGAINST CURRENT DEVIN DOCUMENTATION>`. Die Großform pauschal zu verbieten wäre
+falsch gewesen – `CLAUDE.md` ist ein Dateiname, `DEVIN_PROJECT_DIR` eine Umgebungsvariable des
+Clients, und beide stehen zu Recht in Abbildungstabellen und im Client Pack.
+
+Die präzise Regel lautet deshalb: **Ein Platzhalter, der einen Clientnamen trägt, gehört nicht in
+den Kern.** Er bindet ihn genauso an ein Produkt wie eine Akteursnennung.
+
+## 2. Vorgeschlagene Änderung
+
+- **Der Entscheidungsbaum heißt `02-may-ai-do-task.md`.** Fünf Verweise nachgezogen; historische
+  Dokumente behalten den alten Namen, weil sie einen vergangenen Zustand beschreiben.
+- **Zehn Markerstellen tragen die neutrale Form** `<VERIFY AGAINST CURRENT CLIENT DOCUMENTATION>`,
+  die `docs/PLACEHOLDER_REGISTRY.md` bereits führte. Im Client Pack `devin-desktop` bleibt die
+  clientgebundene Form – dort ist sie richtig.
+- **Das Register sagt jetzt, welche Form wohin gehört:** die clientgebundene als Altform „nur in
+  einem Client Pack zulässig", die neutrale als „die im Kern zu verwendende Form".
+- **Prüfung 14 erfasst zusätzlich Platzhalter mit Clientnamen.** Getrennt wird an Leerzeichen
+  **und Unterstrichen** – sonst entginge ihr ein Platzhalter, der den Namen als Namensteil führt.
+  Das Register ist ausgenommen: Es nennt Platzhalter, es verwendet sie nicht.
+- **Neun Artefakte sind um eine PATCH-Stelle gehoben**, zwei Skills mit Eintrag im eigenen
+  Änderungsverlauf – konsequent zu E3 aus `CR-2026-020`.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Keine Regel, keine Zusage.** Der Marker bedeutet unverändert „noch zu verifizieren".
+- **Die dritte Restpunkt-Position bleibt offen.** Die Zeile „Umsetzung beim KI-Client" in
+  `05-working-model.md` nennt weiterhin `~/.devin/plans/` und `subagent_explore`. Das ist keine
+  Bezeichnungsfrage: Der Kern beschreibt dort, **was ein bestimmter Client kann** – das gehört in
+  dessen Fähigkeitsmatrix und ist ein eigener Vorgang mit eigenem Umfang.
+
+## 4. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Dateiname umbenennen? | **Ja**, zu `02-may-ai-do-task.md` – die Nachbardateien sind ebenfalls englisch benannt (`01-context-allowed`, `03-analyze-or-modify`) | Fünf Verweise; historische Dokumente nennen weiter den alten Namen, was beim Nachlesen einen Schritt kostet |
+| E2 | Großform des Clientnamens pauschal verbieten? | **Nein** – `CLAUDE.md` ist ein Dateiname, `DEVIN_PROJECT_DIR` eine Umgebungsvariable. Nur **Platzhalter** werden erfasst | Eine Client-Bindung außerhalb eines Platzhalters und außerhalb der kapitalisierten Form bleibt unerkannt |
+| E3 | Die Altform des Markers aus dem Register entfernen? | **Nein**, sie bleibt – mit dem Vermerk, dass sie nur im Client Pack zulässig ist. Das Register dokumentiert, was es gibt | Ein Leser könnte die Altform für gleichwertig halten; der Vermerk muss das tragen |
+
+## 5. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | `<TBD: angenommen / abgelehnt / mit Auflagen>` |
+| Datum | `<TBD>` |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | `<TBD: E1, E2 und E3 einzeln entscheiden>` |

package/.koolie/core/governance/change-requests/CR-2026-025-betriebsmodi.md

@@ -0,0 +1,110 @@
+# Änderungsantrag `CR-2026-025`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Kern beschrieb bei den Betriebsmodi, was ein bestimmter Client kann |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-10 |
+| Betroffene Artefakte | `framework/core/05-working-model.md`, `clients/devin-desktop/CLIENT_PACK.md` |
+| Ebene laut Entscheidungsbaum 6 | Framework Core und Abbildungsschicht; keine Regeländerung |
+| Art | Dritter und letzter Restpunkt aus `CR-2026-020` |
+| Dringlichkeit | regulär |
+
+## 1. Anlass und Problem
+
+`CR-2026-020` hat die Akteursbezeichnung aus dem Kern gelöst und drei Restpunkte ausgewiesen.
+Zwei sind mit `CR-2026-024` abgearbeitet. Der dritte ist der schwierigste, weil er **keine
+Bezeichnungsfrage** ist.
+
+Vier Betriebsmodi-Tabellen in `05-working-model.md` führten eine Zeile „Umsetzung beim
+KI-Client". Ihr Inhalt:
+
+| Modus | Genannt wurde |
+|---|---|
+| M1 Read-only Analysis | Plan-Modus („read-only research"), Subagent-Profil `subagent_explore` |
+| M2 Guided Planning | Plan-Modus mit Plan-Datei unter `~/.devin/plans/plan-<session>.md` |
+| M4 Test and Validation | Skill-`permissions`, Hook `PreToolUse` |
+| M5 Documentation Support | Skill-`permissions` |
+
+**M4 und M5 waren bereits neutral** – `permissions`, `PreToolUse` und die Schreibweise `Write(…)`
+sind Kernbegriffe des Frameworks, keine Produktnamen. **M1 und M2 nicht:** Ein Modusname eines
+Produkts, ein Profilname und ein Pfad im Home-Verzeichnis eines Clients.
+
+Der Unterschied zur Akteursbezeichnung: Dort stand ein falscher Name für dieselbe Sache. Hier
+sagte der Kern **eine Sache aus, die nur für einen Client gilt** – und die Abbildungsschicht
+(D-12) ist genau der Ort, an dem so etwas hingehört.
+
+Dass die Zeile nach `CR-2026-020` „Umsetzung beim KI-Client" hieß, machte es eher schlimmer: Der
+Titel behauptete Neutralität, die der Inhalt nicht einlöste.
+
+## 2. Vorgeschlagene Änderung
+
+**Die Zeile heißt „Durchsetzung" und nennt, was durchzusetzen ist:**
+
+- **M1:** Werkzeugbeschränkung des Skills auf lesende Verben und `deny: edit, exec` über dessen
+  `permissions`. Kennt der KI-Client einen eigenen Nur-Lese-Modus oder ein rein lesendes
+  Agentenprofil, ist dieser Weg vorzuziehen – welcher das ist, steht in der Fähigkeitsmatrix
+  seines Client Packs (S3, A1).
+- **M2:** Schreibrecht allein auf die Plan-Datei. Kennt der KI-Client einen eigenen
+  Planungsmodus, ist dieser vorzuziehen. Liegt die Plan-Datei außerhalb des Repositorys, wird
+  sie in das im Overlay festgelegte Ablageformat übernommen.
+- **M4 und M5** bleiben inhaltlich unverändert; nur die Zeilenbezeichnung und die
+  `[DOK]`-Marken entfallen – ein Belegstatus gehört an eine Produktaussage, nicht an eine
+  Framework-Anordnung.
+
+**Die drei clientgebundenen Angaben stehen jetzt im Pack `devin-desktop`:**
+
+| Neu | Zusage | Mechanismus |
+|---|---|---|
+| A2 | Rein lesendes Analyseprofil für Modus M1 | Subagent-Profil `subagent_explore` |
+| M4 | Eigener Planungsmodus für Modus M2 | Plan-Modus mit Plan-Datei unter `~/.devin/plans/…` |
+| M5 | Eigener Nur-Lese-Modus für Modus M1 | Plan-Modus („read-only research") |
+
+Die Belegspalte weist aus, dass die Aussagen aus dem Kern übernommen wurden – sie sind nicht neu
+erhoben. **AP2 für `devin-desktop` steht weiterhin aus**; die Einstufungen sind damit so belastbar
+wie zuvor, nur am richtigen Ort.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Keine Regel und keine Zusage.** Was ein Modus erlaubt und verbietet, steht unverändert in den
+  Zeilen darüber.
+- **Keine neue Prüfung.** Prüfung 12 meldet Pfadnennungen der Laufzeitschicht bereits als Warnung;
+  `~/.devin/plans/` fiel nicht darunter, weil der Pfad im Home-Verzeichnis liegt und nicht unter
+  den geprüften Wurzeln. Eine Erweiterung wäre möglich, ist aber nicht Gegenstand.
+
+## 4. Nebenbefund – wieder eine zu kleine Zählung
+
+Die Roadmap führte unter „Bewusst offen gelassen": „**Zwei** Pfadnennungen in AP2 dieses
+Dokuments". Prüfung 12 meldet in einer `claude-code`-Installation **zehn**: zwei in der Roadmap,
+acht in den Quellen des Hauptdokuments (`build/doc/15-referenzstruktur.md`,
+`build/doc/31-anhaenge.md`).
+
+Die acht sind **nicht geprüft** worden: `assemble.py` löst Laufzeit-Platzhalter je Client auf,
+diese Stellen könnten also neutral sein. Ob sie es sein sollen, ist ein eigener Vorgang – die
+Anhänge beschreiben teilweise Prüfpunkte gegen die Dokumentation eines konkreten Clients, wo der
+Pfad richtig ist.
+
+**Das ist die dritte zu kleine Zählung in Folge:** `CR-2026-020` (76 statt 248), `CR-2026-024`
+(fünf statt zehn), hier (zwei statt zehn). Jedes Mal war die Zahl von Hand erhoben, jedes Mal an
+der Stelle gezählt, wo man den Fehler vermutete. Die Roadmap-Notiz nennt jetzt die geprüfte Zahl
+und ihre Aufschlüsselung.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Die Angaben löschen oder ins Pack übernehmen? | **Übernehmen.** Sie sind belegt und nützlich – nur am falschen Ort | Die Fähigkeitsmatrix wächst um drei Zeilen, die AP2 für `devin-desktop` noch bestätigen muss |
+| E2 | Die `[DOK]`-Marken in der Kernzeile behalten? | **Nein.** Ein Belegstatus kennzeichnet eine Produktaussage; was das Framework anordnet, ist keine | Wer die Zeile bisher als Produktaussage gelesen hat, muss umlernen |
+| E3 | Die acht Pfadnennungen in `build/doc/` mitlösen? | **Nein**, ausgewiesen. Die Anhänge beschreiben teils Prüfpunkte gegen die Dokumentation eines konkreten Clients | Die Warnung aus Prüfung 12 bleibt bei zehn statt bei zwei |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** |
+| Datum | 2026-09-10 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **E1 bis E3 wie in Abschnitt 5 vorgelegt**: Die drei clientgebundenen Angaben werden in das Pack `devin-desktop` übernommen (A2, M4, M5) statt gelöscht; die `[DOK]`-Marken der Kernzeilen entfallen; die Pfadnennungen in `build/doc/` werden **nicht** mitgelöst, sondern ausgewiesen. 🔴 **E3 ist die Wurzel einer Ausnahme, die danach zwanzig Releases lang als befristet geführt wurde:** Die Begründung – *„die Anhänge beschreiben teils Prüfpunkte gegen die Dokumentation eines konkreten Clients"* – beschreibt einen **dauerhaften** Gegenstand. Mit `AP11` (Release 0.89.0, D-311) ist die Frist gefallen und durch eine Dauerausnahme über drei benannte Träger ersetzt |
+| Umsetzung | **mit Release 0.23.0** – Einzelheiten und Nachweise in `.koolie/core/CHANGELOG.md` |
+
+Abschnitt 6 ist am 2026-09-22 mit `CR-2026-124` (`AP11`) **nachgetragen**, nicht neu entschieden: Die Entscheidung selbst steht seit 2026-09-10 in dem `CHANGELOG.md`-Eintrag zu Release 0.23.0, die Umsetzung im `CHANGELOG.md` zu Release 0.23.0. 🔴 **Der Releaseplan nannte für diesen Nachtrag zwei Anträge; gezählt am 2026-09-22 sind es sieben** – `CR-2026-020`, `-021`, `-023`, `-025`, `-026`, `-029` und `-030`.

package/.koolie/core/governance/change-requests/CR-2026-026-fail-closed.md

@@ -0,0 +1,134 @@
+# Änderungsantrag `CR-2026-026`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Schutz-Hook läuft fail-closed, wo das Eingabeschema belegt ist |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-11 |
+| Betroffene Artefakte | `framework/runtime/hooks.json`, `clientmap.py`, `clients/claude-code/manifest.json`, `clients/devin-desktop/manifest.json`, `tests/scripts/hook-check-secrets.py`, `tests/scripts/validate-framework.py` (Prüfung 17 neu), beide `CLIENT_PACK.md` |
+| Ebene laut Entscheidungsbaum 6 | Schutzmechanismus, Abbildung und Prüfung; keine Regeländerung |
+| Art | Härtung; Einlösung eines seit 0.1.0 ausgewiesenen Vorbehalts |
+| Dringlichkeit | regulär – die Lücke besteht nur bei einer Eingabe, die der Hook nicht lesen kann |
+
+## 1. Anlass und Problem
+
+Der Schutz-Hook lässt eine Werkzeugeingabe, die er nicht als JSON lesen kann, durch und meldet
+sie nur auf stderr. Der Kopfkommentar von `hook-check-secrets.py` nannte dafür seit 0.1.0 einen
+Grund und eine Bedingung:
+
+> Nicht parsebare Eingabe -> standardmäßig Exit-Code 0 mit Warnung auf stderr (fail-open),
+> weil das Eingabeschema noch nicht in einer Zielinstallation validiert wurde. […] Nach
+> erfolgreicher Validierung im Arbeitspaket „Validierung der Clientfunktionalitäten" SOLL
+> fail-closed zum Standard gemacht werden (Secure by Default).
+
+**Die Bedingung ist für einen der beiden Clients erfüllt.** `claude-code` ist mit 0.14.0 bis
+0.19.0 gegen eine reale Installation gefahren worden: Das Blockierverhalten ist über den
+Exit-Code dokumentiert, H2 ist seit `CR-2026-021` in einer Sitzung beobachtet, und WN-5 belegt
+die Lesesperre in einer Umgebung ohne Regeltexte. Für `devin-desktop` ist sie es nicht – V3
+führt Eingabeschema und Blockierverhalten weiterhin als unbestätigt, AP2 für dieses Pack steht
+aus.
+
+**Ein gemeinsamer Standard wäre in beide Richtungen falsch.** Fail-open für beide verschenkt
+eine Sperre, die bei einem Client belegt ist. Fail-closed für beide behauptet eine Sperre, die
+beim anderen nicht geprüft ist – und blockierte dort, wenn das Schema abweicht, jeden
+Werkzeugaufruf. Der Vorbehalt ist deshalb nicht aufzuheben, sondern **dorthin zu verlagern, wo
+er hingehört: in das Pack, dessen Client er beschreibt.**
+
+### Warum der Schalter nicht in die Umgebung gehört
+
+Der Mechanismus für fail-closed existierte bereits: die Umgebungsvariable
+`FW_HOOK_FAIL_CLOSED=1`. `clients/claude-code/CLIENT_PACK.md` empfahl bis 0.23.0 ausdrücklich,
+sie nach Bestätigung über `env` in der erzeugten Konfiguration zu setzen.
+
+Dieser Weg hängt die Sperre an eine **zweite Clientzusage**: dass der Client den Inhalt von `env`
+an den Hook-Prozess weiterreicht. Diese Zusage ist für **kein** Pack belegt. Sie wäre auch nicht
+vom Validator prüfbar – er sieht nicht, was der Client an einen Kindprozess weitergibt.
+
+Eine Sperre, die auf einer unbelegten Clientzusage steht, ist genau die Lage, aus der
+`AP2-CC-13` kam: Der Hook-Aufruf setzte acht Releases lang voraus, dass `python3` einen
+Interpreter startet. Geprüft worden war die Anwesenheit der Konfiguration, nie ihre Wirkung.
+
+## 2. Vorgeschlagene Änderung
+
+**Der Schalter steht im Aufrufkommando.** Das Argument ist Teil der Hook-Konfiguration, die der
+Client ohnehin ausführt. Läuft der Hook – was Prüfung 15 an seiner Wirkung belegt –, dann kommt
+das Argument an. Es braucht keine weitere Zusage.
+
+**Zwei Felder, zwei Zuständigkeiten:**
+
+| Feld | Ort | Sagt aus | Wer weiß es |
+|---|---|---|---|
+| `enforcing` | `framework/runtime/hooks.json` | Dieser Hook setzt eine Sperre durch, statt nur zu melden | der Kern – es ist eine Eigenschaft des Hooks |
+| `hook_fail_closed` | `clients/<pack>/manifest.json` | Das Eingabeschema **dieses** Clients ist gegen eine Installation bestätigt | das Pack – es ist eine Eigenschaft des Clients |
+
+Trifft beides zu, hängt `clientmap.py` dem Kommando `--fail-closed` an. Das Ergebnis:
+
+```text
+claude-code    PreToolUse    … hook-check-secrets.py" --fail-closed
+claude-code    SessionStart  … hook-overlay-status.py"
+devin-desktop  PreToolUse    … hook-check-secrets.py"
+```
+
+Der Statusmelder trägt es nicht – er setzt nichts durch. Das steuert `enforcing`, nicht eine
+Liste von Skriptnamen im Abbildungscode.
+
+**Prüfung 17 prüft die Wirkung auf zwei Ebenen.** Beide sind nötig:
+
+1. **Am Skript:** Mit `--fail-closed` muss eine unlesbare Eingabe Exit 2 liefern, ohne das
+   Argument Exit 0. Diese Ebene läuft auch dort, wo es keine Installation gibt. Ohne sie fiele
+   ein Schalter, der ins Leere greift, erst in einer Installation auf – die Lage, in der
+   `AP2-CC-16` acht Releases lang unbemerkt blieb.
+2. **An der erzeugten Konfiguration:** Das Kommando wird so aufgerufen, wie es dort steht, und
+   sein Verhalten gegen die Zusage des Packs gehalten. Diese Ebene prüft die ganze Kette –
+   Manifest, Abbildung, Konfiguration, Verhalten.
+
+Die Umgebungsvariable wird für den Prüfaufruf aus der Umgebung entfernt. Sonst bestünde der Test
+auch dann, wenn das Argument nichts bewirkt.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Das Kernverhalten des Hooks.** Secret-Muster, geschützte Pfade, die Trennung nach Schutzziel
+  aus D-30 und die Tokenisierung von Shell-Befehlen sind unberührt. Fünf Regressionsproben
+  belegen es.
+- **`devin-desktop`.** Das Pack läuft weiter fail-open – jetzt aber als **ausgewiesene** Angabe
+  im Manifest und in der Matrix, statt als Folge einer fehlenden Angabe.
+- **Die Umgebungsvariable.** `FW_HOOK_FAIL_CLOSED=1` wirkt weiterhin und bleibt der Weg, in einer
+  bestehenden Installation fail-closed zu erproben, ohne neu zu installieren.
+
+## 4. Grenze der Zusage
+
+**Fail-closed betrifft einen einzigen Zweig:** eine Eingabe, die sich nicht als JSON lesen lässt.
+Der Hook ist sonst schema-agnostisch – er durchsucht alle Zeichenketten der Struktur und findet
+ein Secret auch dann, wenn die Feldnamen anders heißen. Die Änderung härtet also den Fall, in
+dem der Hook **gar nichts** sehen kann, nicht den, in dem er etwas übersieht.
+
+**Der Preis ist benannt:** Ändert der Client sein Eingabeformat auf etwas, das kein JSON ist,
+blockiert bei `claude-code` jeder erfasste Werkzeugaufruf, bis das Schema nachgezogen ist. Das
+ist beabsichtigt – ein Schutz-Hook, der bei unklarer Lage durchwinkt, ist schlimmer als ein
+fehlender (D-29). Die Blockierbegründung nennt den Verdacht und den Weg.
+
+**Eine bestehende `claude-code`-Installation erhält das Argument nicht von selbst.** Die Hooks
+liegen dort in der Berechtigungsdatei und damit in der Saat; `install.py --update` fasst sie nie
+an. Prüfung 17 meldet das als Fehler und nennt den Behebungsweg clientabhängig. Die
+Migrationspflicht ist damit sichtbar statt stillschweigend.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Kommandoargument oder Umgebungsvariable? | **Argument.** Es steht in der Konfiguration, die der Client ausführt; `env` hätte die Sperre an eine für kein Pack belegte Clientzusage gehängt | Eine bestehende Installation, deren Hooks in der Saat liegen, zieht das Argument von Hand nach |
+| E2 | Für beide Packs oder je Pack? | **Je Pack.** Belegt ist das Schema nur bei `claude-code`; bei `devin-desktop` blockierte fail-closed bei abweichendem Schema jede Sitzung | Die beiden Packs verhalten sich an dieser Stelle unterschiedlich – ausgewiesen in beiden Matrizen |
+| E3 | Woran erkennt die Abbildung einen durchsetzenden Hook? | **Am Feld `enforcing` der Kernquelle.** Eine Liste von Skriptnamen im Abbildungscode veraltet beim nächsten Hook | Ein zusätzliches Feld in der neutralen Quelle, das beim Rendern entfernt wird |
+| E4 | Prüfung 17 auf einer oder zwei Ebenen? | **Zwei.** Die Ebene am Skript läuft auch ohne Installation; ohne sie fiele ein wirkungsloser Schalter erst dort auf, wo es nichts zu prüfen gibt | Vier zusätzliche Prozessstarts je Validatorlauf |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** |
+| Datum | 2026-09-11 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **E1 bis E4 wie in Abschnitt 5 vorgelegt**: Der Schutzschalter steht im Kommandoargument und nicht in der Umgebung; er wird **je Pack** gesetzt, weil das Eingabeschema nur bei einem belegt war; die Abbildung erkennt einen durchsetzenden Hook am Feld `enforcing` der Kernquelle; Prüfung 17 misst auf **zwei** Ebenen |
+| Umsetzung | **mit Release 0.24.0** – Einzelheiten und Nachweise in `.koolie/core/CHANGELOG.md` |
+
+Abschnitt 6 ist am 2026-09-22 mit `CR-2026-124` (`AP11`) **nachgetragen**, nicht neu entschieden: Die Entscheidung selbst steht seit 2026-09-11 in **D-31**, die Umsetzung im `CHANGELOG.md` zu Release 0.24.0. 🔴 **Der Releaseplan nannte für diesen Nachtrag zwei Anträge; gezählt am 2026-09-22 sind es sieben** – `CR-2026-020`, `-021`, `-023`, `-025`, `-026`, `-029` und `-030`.

package/.koolie/core/governance/change-requests/CR-2026-027-zeichenlimit-einstufung.md

@@ -0,0 +1,105 @@
+# Änderungsantrag `CR-2026-027`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | R4 stuft ein Zeichenlimit als technisch durchgesetzt ein, das für diesen Client nicht dokumentiert ist |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-11 |
+| Betroffene Artefakte | `clients/devin-desktop/CLIENT_PACK.md` (Zeile R4), `build/doc/31-anhaenge.md` (V1, QD-7), ggf. `docs/ROADMAP.md` |
+| Ebene laut Entscheidungsbaum 6 | Client Pack – Belegstatus einer Zusage; keine Regeländerung |
+| Art | Behebung von `AP2-DD-02` (Schwere: mittel) |
+| Dringlichkeit | regulär – die Einstufung behauptet eine Schranke, sie schafft keine |
+
+## 1. Anlass und Problem
+
+Die Fähigkeitsmatrix des Packs `devin-desktop` führt:
+
+```text
+| R4 | Bekanntes Zeichenlimit | 12.000 je Workspace-Regel, 6.000 global | [TECHNISCH]
+     | [DOK] für Cascade; für Devin Local <VERIFY AGAINST CURRENT DEVIN DOCUMENTATION> (K-19) |
+```
+
+**Die Belegspalte sagt, was fehlt – die Einstufungsspalte sagt es nicht.** `[TECHNISCH]`
+bedeutet nach der Legende des Packs, dass der Client die Zusage durchsetzt. Belegt ist
+die Zahl aber nur für **Cascade**, das seit dem Rebrand vom 02.06.2026 von Devin Local
+abgelöst wird (QD-1).
+
+**Der Abgleich vom 11.09.2026 gegen Devin Desktop 3.9.19** (`cli/extensibility/rules`)
+ergibt: Die aktuelle Regeldokumentation nennt **keinerlei Zeichen- oder Größengrenze**
+für Regeldateien – weder für `AGENTS.md` noch für `.devin/rules/*.md` noch für globale
+Regeln.
+
+Damit steht die Zeile auf einer Quelle zu einem Vorgängerprodukt, während die Einstufung
+eine Durchsetzung im aktuellen behauptet.
+
+### Warum das mehr ist als eine Formalie
+
+Die Zahl ist nicht folgenlos. Sie steht im Größenbudget der Wurzel-Anweisungsdatei, in
+`.devin/rules/README.md` und in den Grenzen des Validators. **Ein Projekt, das seine
+Regeltexte an 12.000 Zeichen ausrichtet, richtet sich an einer Grenze aus, die für
+seinen Client nicht dokumentiert ist** – und hält womöglich eine ein, die es nicht gibt,
+oder überschreitet eine, die anders liegt.
+
+Der Befundtyp ist derselbe wie bei `AP2-CC-13` und `FW-KO-01`: **Geprüft war die
+Herkunft der Angabe, nie ihre Geltung.** Bei `AP2-CC-13` war der Interpretername
+vorhanden und startete kein Python; hier ist die Quelle vorhanden und gilt für ein
+anderes Produkt.
+
+## 2. Vorgeschlagene Änderung
+
+**Einstufung auf `[TEXTUELL]`.** Die Zeile beschreibt dann, was sie ist: eine
+Budgetannahme des Frameworks, für die beim aktuellen Client keine Herstellerzusage
+vorliegt.
+
+**V1 auflösen statt offen tragen.** Der Verifikationsbedarf V1 lautet „Zeichenlimits für
+Regeldateien unter Devin Local (dokumentiert bislang für Cascade-Regeln: 6.000/12.000)".
+Er ist mit dieser Recherche **beantwortet** – die Antwort lautet „nicht dokumentiert".
+
+Ein Prüfpunkt, dessen Recherche ergeben hat, dass es nichts zu belegen gibt, bleibt
+nicht offen; er wird mit dem Ergebnis geschlossen. Sonst wird er beim nächsten Durchgang
+erneut recherchiert, und niemand weiß, dass die Antwort schon vorliegt. Dieselbe
+Überlegung wie beim Abwesenheitsbeleg X2 bei `claude-code`: **Dass etwas nicht
+dokumentiert ist, ist ein Ergebnis, kein fehlendes Ergebnis.**
+
+**Die Zahlen bleiben stehen, als das, was sie sind.** Das Framework braucht ein Budget –
+ohne Obergrenze wächst die always-on-Summe unbemerkt (V10). Der Vorschlag ist nicht, die
+Zahl zu streichen, sondern sie als **eigene Vorgabe** zu führen statt als
+Produkteigenschaft.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Das Budget selbst.** 12.000/6.000 bleiben als Framework-Vorgabe in Kraft, und der
+  Validator prüft weiter dagegen. Eine selbstgesetzte Grenze ist eine Grenze.
+- **K-19.** Die Klärungsfrage bleibt bestehen; beantwortet ist nur, dass der Hersteller
+  sie derzeit nicht beantwortet.
+- **Andere Packs.** Bei `claude-code` sind die dokumentierten Grenzen andere (4 MiB je
+  Anweisungsdatei, Empfehlung 200 Zeilen) und mit QC-1 belegt.
+
+## 4. Grenze der Zusage
+
+**Eine nicht dokumentierte Grenze ist keine nicht existierende Grenze.** Möglich bleibt,
+dass Devin Local intern kürzt oder verwirft, ohne es zu dokumentieren. Genau deshalb
+lautet der Vorschlag `[TEXTUELL]` und nicht „Zeile streichen": Das Framework hält sein
+Budget ein, verlässt sich aber nicht darauf, dass der Client es durchsetzt.
+
+Ob eine überlange Regeldatei in der Praxis noch vollständig geladen wird, ließe sich
+beobachten – das wäre ein eigener Sitzungsnachweis und ist **nicht** Gegenstand dieses
+Antrags.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Einstufung `[TECHNISCH]` oder `[TEXTUELL]`? | **`[TEXTUELL]`.** Für diesen Client liegt keine Herstellerzusage vor | Das Pack weist eine technische Zusage weniger aus – ehrlicher, aber die Matrix wird schwächer |
+| E2 | V1 schließen oder offen lassen? | **Schließen, mit dem Ergebnis „nicht dokumentiert"** samt Datum und Clientversion | Wird die Grenze später doch dokumentiert, ist V1 erneut zu öffnen |
+| E3 | Die Zahlen 12.000/6.000 behalten? | **Ja, als Vorgabe des Frameworks.** Ohne Obergrenze wächst die always-on-Summe unbemerkt | Eine selbstgesetzte Zahl ohne äußere Begründung – sie ist als solche zu kennzeichnen |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** |
+| Datum | 2026-09-11 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | E1 bis E3 wie vorgelegt: Einstufung R4 auf `[TEXTUELL]`; V1 wird mit dem Ergebnis „nicht dokumentiert“ samt Datum und Clientversion geschlossen; die Zahlen 12.000/6.000 bleiben als **ausgewiesene Vorgabe des Frameworks** erhalten. Ziel-Release 0.26.0 |
+| Umsetzung | **mit Release 0.26.0** – Einzelheiten und Nachweise in `leitwerk-core/CHANGELOG.md` |

package/.koolie/core/governance/change-requests/CR-2026-028-berechtigungsmodi.md

@@ -0,0 +1,130 @@
+# Änderungsantrag `CR-2026-028`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | D-05 verweist für die Modus-Zuordnung auf Matrixzeilen, die zwei der geregelten Modi nicht führen |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-11 |
+| Betroffene Artefakte | `clients/devin-desktop/CLIENT_PACK.md` (Zeilen M1–M5), `governance/DECISION_LOG.md` (D-05) |
+| Ebene laut Entscheidungsbaum 6 | Client Pack – Vollständigkeit der Abbildung; Fortschreibung eines Decision Records |
+| Art | Behebung von `AP2-DD-03` (Schwere: niedrig bis mittel) |
+| Dringlichkeit | regulär – die Regel gilt, nur ihre Zuordnung fehlt |
+
+## 1. Anlass und Problem
+
+D-05 regelt **vier** Berechtigungsmodi und sagt, wo ihre clientseitige Entsprechung
+steht:
+
+> Der Permission-Modus `Bypass` ist im Framework untersagt; `Smart` und `Accept Edits`
+> sind nur über dokumentierte Ausnahme für Kontrollstufe niedrig zulässig; Standard ist
+> `Normal`. […] **Die Zuordnung je Client steht in der Fähigkeitsmatrix (Zeilen M1 bis
+> M3).**
+
+Die Fähigkeitsmatrix des Packs `devin-desktop` führt in M1 bis M3:
+
+| Zeile | Gegenstand |
+|---|---|
+| M1 | Standardmodus fragt zurück → Modus `Normal` |
+| M2 | Modus ohne Rückfragen ausschließbar → Modus `Bypass` |
+| M3 | Freigabe auf die Sitzung begrenzbar → Sitzungsfreigaben – **kein Modus** |
+
+**`Smart` und `Accept Edits` haben keine Zeile.** Der Verweis in D-05 geht damit ins
+Leere: Er nennt eine Zuordnung, die es für zwei der vier geregelten Modi nicht gibt.
+
+Der Abgleich vom 11.09.2026 gegen Devin Desktop 3.9.19 (`cli/reference/permissions`)
+bestätigt alle vier als existierende Modi und nennt einen **fünften**:
+
+| Modus | Dokumentierte Wirkung | In D-05 | In der Matrix |
+|---|---|---|---|
+| `Normal` | fragt bei Schreiben und Shell-Befehlen zurück | Standard | M1 |
+| `Accept Edits` | genehmigt Dateiänderungen im Workspace automatisch | nur über Ausnahme | **fehlt** |
+| `Smart` | genehmigt Workspace-Änderungen automatisch, beurteilt übrige Aktionen nach Sicherheit | nur über Ausnahme | **fehlt** |
+| `Bypass` | „All tool calls are auto-approved without prompting" | untersagt | M2 |
+| `Autonomous` | mit `--sandbox`; genehmigt Shell-Befehle innerhalb der Sandbox | **fehlt** | nur in Abschnitt 5 erwähnt |
+
+### Warum das zählt
+
+Ein Modus, der **selbst beurteilt**, was sicher ist, ist für ein Framework einschlägig,
+dessen tragendes Prinzip lautet, dass der Mensch prüft und freigibt. D-05 hat ihn
+deshalb zu Recht geregelt. Was fehlt, ist die Brücke zur Installation: **Ohne Matrixzeile
+sagt das Pack nicht, wie der Modus beim Client heißt, wie er eingestellt wird und ob die
+Ausnahme überhaupt technisch begrenzbar ist.** Eine Regel ohne Zuordnung ist eine Regel,
+die man nicht anwenden kann, ohne sie selbst zu übersetzen – genau die Lage, die die
+Abbildungsschicht beseitigen soll (D-12).
+
+`Autonomous` fehlt in D-05 ganz. Das Pack erwähnt ihn in Abschnitt 5 („Sandbox nicht auf
+allen Betriebssystemen … der Modus `Autonomous` ist damit dort nicht absicherbar"), also
+als Randbemerkung zu einem anderen Thema – nicht als geregelter Modus.
+
+### Der Mechanismus in M2 ist falsch benannt
+
+M2 führt: „`Bypass` ist per D-05 untersagt; eine **technische Sperre** setzt
+Admin-Kontrollen der Planstufe voraus (K-05 offen)."
+
+Die Recherche ergibt: **Eine Einstellung, die den Bypass-Modus abschaltet, ist nicht
+dokumentiert.** Aufrufbar ist er über `--permission-mode bypass` und
+`DEVIN_PERMISSION_MODE=bypass`. Was es gibt, ist etwas anderes und Wirksameres: Die
+**Terminal Permissions der Organisationsebene** haben laut Team-Dokumentation „the
+highest precedence and cannot be overridden by individual users' local or project
+configurations" – sie greifen also **auch dann, wenn der Modus auf Bypass steht**.
+
+Im Ergebnis bleibt die Aussage des Packs richtig (ohne Admin-Kontrollen keine
+Durchsetzung), aber sie benennt den falschen Hebel: **Nicht der Modus wird gesperrt,
+seine Wirkung wird begrenzt.** Der Unterschied ist praktisch: Wer nach einer
+Modus-Sperre sucht, findet keine und schließt daraus, es gebe keine Durchsetzung.
+
+**Anders als bei `claude-code`:** Dort ist die Sperre des Modus selbst dokumentiert
+(`permissions.disableBypassPermissionsMode`, AP2-CC-05) und in verwalteten Einstellungen
+unüberschreibbar. D-05 führt diesen Beleg bereits. Die beiden Clients unterscheiden sich
+an dieser Stelle – und genau das soll eine Fähigkeitsmatrix zeigen.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Zwei Zeilen ergänzen** – für den Modus mit automatischer Übernahme von
+   Dateiänderungen und für den selbst beurteilenden Modus –, mit Clientnamen,
+   Einstufung und Beleg. Die Zusagenspalte bleibt werkzeugneutral formuliert (D-28).
+2. **`Autonomous` in D-05 aufnehmen**, mit Bezug auf die Sandbox-Voraussetzung und den
+   Umstand, dass die Sandbox unter Windows nicht verfügbar ist (K-11). Ein Modus, der
+   seine Absicherung aus einem Mechanismus bezieht, den es auf der Zielplattform nicht
+   gibt, ist dort kein abgesicherter Modus.
+3. **M2 im Mechanismus korrigieren:** nicht „technische Sperre des Modus", sondern
+   „Begrenzung seiner Wirkung durch unüberschreibbare Berechtigungsregeln der
+   Organisationsebene". Der VERIFY-Marker der Zeile wird damit aufgelöst.
+4. **Den Verweis in D-05 nachziehen:** nicht „Zeilen M1 bis M3", sondern die Zeilen, die
+   die Modi tatsächlich führen.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Die Regel selbst.** `Bypass` bleibt untersagt, die beiden mittleren Modi bleiben
+  ausnahmepflichtig, `Normal` bleibt Standard. Der Antrag ergänzt die Zuordnung, er
+  lockert nichts (Verschärfungsprinzip).
+- **K-05.** Ob die Planstufe die nötigen Admin-Kontrollen bietet, bleibt offen; belegt
+  ist jetzt, welcher Mechanismus zu suchen wäre.
+- **`claude-code`.** Dort ist die Lage belegt und unverändert.
+
+## 4. Grenze der Zusage
+
+Die Angaben stammen aus der Herstellerdokumentation, nicht aus einer Installation. Sie
+belegen `[DOK]`. **Ob die Organisationsregeln im Bypass-Modus tatsächlich greifen, ist
+nicht beobachtet** – und mit einer Einzelplatzinstallation ohne Team-Plan auch nicht
+beobachtbar. Die Zeile ist entsprechend als `[TEXTUELL]` zu führen, bis eine Umgebung
+mit Admin-Kontrollen zur Verfügung steht.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Zwei Modi als Matrixzeilen aufnehmen? | **Ja.** D-05 regelt sie, und die Matrix ist der Ort der Zuordnung | Die Matrix wächst um zwei Zeilen, die für keine Framework-Zusage stehen, sondern für eine Beschränkung |
+| E2 | `Autonomous` in D-05 aufnehmen? | **Ja**, mit Bezug auf K-11 – seine Absicherung fehlt auf der Zielplattform | Eine fünfte Modusregel in einer Entscheidung, die mit vier auskam |
+| E3 | M2: Sperre oder Wirkungsbegrenzung? | **Wirkungsbegrenzung.** Eine Modus-Sperre ist bei diesem Client nicht dokumentiert | Die Zusage „ausschließbar" wird schwächer: Der Modus bleibt wählbar, nur folgenlos |
+| E4 | Einstufung der neuen und der korrigierten Zeilen? | **`[TEXTUELL]`**, solange keine Umgebung mit Admin-Kontrollen beobachtet wurde | Das Pack weist erneut eine textuelle statt technischer Zusage aus |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** |
+| Datum | 2026-09-11 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | E1 bis E4 wie vorgelegt: zwei Matrixzeilen für den Modus mit automatischer Übernahme und den selbst beurteilenden Modus; `Autonomous` wird in D-05 aufgenommen, mit Bezug auf K-11; M2 nennt die **Wirkungsbegrenzung durch Berechtigungsregeln der Organisationsebene** statt einer Modus-Sperre; alle betroffenen Zeilen `[TEXTUELL]`. Ziel-Release 0.26.0 |
+| Umsetzung | **mit Release 0.26.0** – Einzelheiten und Nachweise in `leitwerk-core/CHANGELOG.md` |