@renoxar/koolie 1.25.0

package/.koolie/core/clients/openai-codex/CLIENT_PACK.md

@@ -0,0 +1,257 @@
+# Client Pack `openai-codex`
+
+| Attribut | Wert |
+|---|---|
+| Modul-ID | `CP-OC` |
+| Ebene | keine – Abbildungsschicht |
+| Version | 0.1.9 |
+| Status | pilot |
+| Owner (Rolle) | `<FRAMEWORK_OWNER>` |
+| Client | OpenAI Codex CLI |
+| Verbindliche Zielversion | `0.156.x` (D-112). Die Spanne ist der Geltungsbereich dieses Packs; der gemessene Punktwert steht in der Zeile darunter (D-113). Für dieses Pack ist die Spanne festgelegt, nicht erhoben – erhoben ist der Punktwert |
+| Geprüfte Clientversion | `0.156.1` – vor dem Erheben festgeschrieben (D-117, D-202). Konto: `plus` |
+| Stand der Produktbeobachtung | **keine**, Stand 2026-09-23. `FW-AK-01` ist für dieses Pack nicht gefahren; es gibt für diesen Client noch keine Quellenliste in Anhang 31.4. Deshalb trägt das Pack keine `[DOK]`-Zeile: Alle Belege stammen aus Messungen am Client selbst, nicht aus seiner Dokumentation |
+| Datum der Prüfung | **2026-09-23** – der Bau (`CR-2026-133`, `tests/protocols/2026-09-23-bau-openai-codex.md`): 30 Messungen am Prompt-Eingang, am Konfigurationsschema, am Regelauswerter und an einer realen Installation, dazu 25 Sitzungsläufe. Zuvor 2026-09-23 – die Erhebung (`CR-2026-132`, `tests/protocols/2026-09-23-erhebung-openai-codex.md`) |
+
+> **Belegt, soweit gemessen (Stand 1.4.0).** Die Spalte „Einstufung" nennt die **vorgesehene** Durchsetzungstiefe, die Spalte „Beleg" ihren Nachweisstand: `gemessen` = an diesem Client beobachtet, `[EMPF]` = Vorgabe des Frameworks, `BELEG OFFEN` = noch nicht belegt, mit Grund und Datum in der Zelle – ohne Frist (D-291).
+>
+> **Keine `[DOK]`-Zeile.** Grundlage dieses Packs ist kein Dokumentenabgleich, sondern ein Messmittel: `codex debug prompt-input` gibt die Nachrichten aus, die der Client der nächsten Anfrage voranstellt, ohne eine Anfrage zu stellen (D-344), und `codex execpolicy check` wertet eine Befehlsregel mit dem Auswerter der Engine selbst aus – beides kostenfrei. Eine Messung sagt, was dieser Stand tut; was der Hersteller zusagt, sagt sie nicht. `FW-AK-01` bleibt für dieses Pack offen.
+>
+> 🔴 **Zwei Kernzusagen sind `[NICHT ABBILDBAR]`: `B3` und `B5`.** Damit greift `clients/README.md` Abschnitt 4 vollständig: Begründung hier in Abschnitt 4, dokumentierte Ausnahme im Overlay des aufnehmenden Projekts – und **keine Inbetriebnahme ohne Freigabe durch `<SECURITY_CONTACT>`.**
+>
+> **Wer das Pack einsetzt,** liest zuerst Abschnitt 6 (Installation und die zwei Schritte danach), Abschnitt 1b (die Vertrauensbedingung, ohne die die projektlokale Schicht nicht lädt) und Abschnitt 4 (die Freigabe).
+
+## 1. Pfadabbildung
+
+| Rolle des Artefakts | Pfad bei diesem Client | Belegstatus |
+|---|---|---|
+| Wurzel-Anweisungsdatei | `AGENTS.md` | **gemessen** (2026-09-23): Der Prompt-Eingang führt sie als eigene Nachricht `agents_md.instructions`, mit dem vollständigen Text. **Sie ist verdrängbar** – siehe die nächste Zeile |
+| Nutzerlokale Überschreibung | `AGENTS.override.md` | **gemessen, mit Gegenprobe:** Liegt sie im Projekt, steht die Wurzel-Anweisung in **keiner** Nachricht der Sitzung; ohne sie steht sie darin. Sie **ersetzt**, sie ergänzt nicht. `AGENTS.local.md` ist bei diesem Client kein Mechanismus – dieselbe Sonde, kein Treffer. Drei Maßnahmen: Der `deny`-Korb stellt die Datei schreibgeschützt, der Schutz-Hook führt sie in seinen Mustern, **Prüfung 88** meldet sie, wenn sie im Projekt liegt. Das Pack liefert **keine** Beispieldatei dafür aus |
+| Regeldateien | `.codex/rules/*.md` – **ohne Ladebedingung** | **gemessen:** Dieser Client lädt von sich aus **keine** Regeldatei; eine Anweisungsdatei in einem Unterverzeichnis steht nicht vorab im Kontext, und eine Einbindung mit `@` bleibt wirkungslos (drei Sonden, alle negativ). Die Dateien wirken über ihre **Nennung** in der Wurzel-Anweisung (`root_instruction_imports`) – siehe R2 |
+| Befehlsregeln | `.codex/rules/koolie.rules` (erzeugt aus `framework/runtime/permissions.json`) | **gemessen an einer realen Installation:** Der Client lädt `*.rules` aus `.codex/rules/` des Projekts und aus dem Benutzerverzeichnis; ein Befehl, den diese Datei verbietet, wird abgewiesen – und der Client nennt die Begründung dieser Datei wörtlich |
+| Skills | `.codex/skills/<name>/SKILL.md` **und** `.agents/skills/<name>/SKILL.md` | **gemessen mit drei Sonden an drei Orten, eine davon negativ:** Beide Ablagen laden; ein `skills/` an der Projektwurzel lädt **nicht**. Der Prompt-Eingang führt eine Herkunftstabelle der Skillwurzeln. ⚠️ **Skills laden auch ohne Vertrauenseintrag** – der Client sagt es selbst: *„Project-local config, hooks, and exec policies are disabled … but skills still load"* |
+| Subagentenprofile | `.codex/agents/<name>.toml` | **Gestalt gemessen, Abbildung nicht gebaut:** Pflichtfelder `name`, `description`, `developer_instructions`; `permissions` und `tools` werden angenommen, `allowed_tools` verworfen – erhoben über die Meldungen, die ein fehlendes oder unbekanntes Feld erzeugt. Das Framework legt sein Profil weiter als Markdown unter `.codex/agents/` ab; die Wirkung einer Rollendatei ist **unerhoben**, und A1 sagt es |
+| Berechtigungskonfiguration (Pfadseite) | `.codex/config.toml` (erzeugt aus `framework/runtime/permissions.json`) | **gemessen:** Ein Rechteprofil unter `[permissions.<name>]` mit `default_permissions`; die Tabelle `filesystem` bindet **Pfad → Zugriffsart**. Ihre Schlüssel nehmen **kein Muster** (siehe B3), und die Datei lädt nur bei eingetragenem Vertrauen |
+| Hook-Konfiguration | `.codex/hooks.json`, Ereignisse unter dem Schlüssel `hooks` | **gemessen:** `.codex/hooks/hooks.json` wird **nicht** gelesen; eine Datei ohne den Schlüssel `hooks` meldet der Client als *unknown field* und **lädt sie nicht**, startet aber. Ereignisse: `PreToolUse`, `PermissionRequest`, `PostToolUse`, `PreCompact`, `PostCompact`, `SessionStart`, `SessionEnd`, `UserPromptSubmit`, `SubagentStart`, `SubagentStop`, `Stop`, `Interrupt`. ⚠️ **Jeder Eintrag braucht `"enabled": true`** – ohne das läuft er nicht, und der Client meldet es nicht |
+| MCP-Konfiguration | `.codex/config.toml` unter `[mcp_servers.<name>]` | **gemessen:** Der Client zählt einen projektlokal eingetragenen Server; eine Datei `.mcp.json` bleibt **unbeachtet**. Das Framework liefert **keinen** Server aus |
+| Projektverzeichnis im Hook-Befehl | **keine Variable – das Arbeitsverzeichnis** | **gemessen am Hook-Prozess:** Seine Umgebung führt außer dem Verweis auf das eigene Benutzerverzeichnis des Clients **nichts**; sein **Arbeitsverzeichnis ist das Projektverzeichnis**. Die Abbildung bindet deshalb den relativen Punkt (`hook_project_dir_expr`). Eine Variable, die es nicht gibt, hätte ein Kommando erzeugt, das startet und nichts findet |
+
+## 1a. Semantikabbildung der Berechtigungen
+
+Die Regelmenge liegt werkzeugneutral im Kern (`.koolie/core/framework/runtime/permissions.json`) und wird bei der Installation übersetzt (D-18). Was dabei abgebildet wird, steht maschinenlesbar im `manifest.json`; diese Tabelle ist die menschenlesbare Fassung.
+
+**Bei diesem Pack zerfällt die Regelmenge in zwei Erzeugnisse** (D-346). Dieser Client kennt keine Regel der Gestalt `Werkzeug(Muster)`. Er bindet **Pfade an eine Zugriffsart** (`.codex/config.toml`) und **Befehle an Präfixmuster** (`.codex/rules/koolie.rules`).
+
+| Neutrales Werkzeugverb | Form bei diesem Client | Anmerkung |
+|---|---|---|
+| `read` | – | **Kein Werkzeugname, und kein abbildbares Muster.** Der Lesekorb des Kerns fällt aus; die Begründung steht in B3 und in Abschnitt 4 |
+| `search` | – | Dieser Client führt **kein eigenes Suchwerkzeug**; Suchen läuft über die Shell und damit unter `exec`. Gemessen: Ein Hook-Matcher `Grep` löst in keinem Lauf aus |
+| `write` | Eintrag `"<pfad>" = "read"` in der Tabelle `":workspace_roots"` | Ein Schreibverbot auf einem Teilbaum heißt hier: lesbar, nicht schreibbar. **Nur ohne Muster** – `**/*.lock` fällt aus (B5) |
+| `exec` | `prefix_rule(pattern = [...], decision = "forbidden"\|"prompt"\|"allow")` | Präfixbasiert, **mit dem Auswerter des Clients gemessen**. Grenze wie bei `claude-code`: `git -C . push` trifft `["git","push"]` nicht |
+| `fetch` | – | Kein Mechanismus; der Kern sagt keine Domainbeschränkung zu (B11, D-59). Siehe B10 |
+| `mcp` | – | Keine Rückfrageregel je Server; wirksam ist, dass **kein** Server ausgeliefert wird (X1) |
+| `skill` | – | Kein Mechanismus erhoben |
+
+| Weitere Eigenschaft | Wert |
+|---|---|
+| Grundstock des Rechteprofils | `":root" = "read"`; in der Tabelle `":workspace_roots"` `"." = "write"` (seit `1.12.1`, D-412) |
+| Schlüsselform der Pfadseite | absoluter Pfad, `~/`-Pfad oder Sonderziel (`:root`, `:workspace_roots`); die Unterpfade des Arbeitsbereichs als eigene Tabelle `[permissions.<profil>.filesystem.":workspace_roots"]`, relativ, `"."` für den Arbeitsbereich selbst. **Die Form `:workspace/<pfad>` ignoriert Clientversion 0.157** (`K-157`, D-412) |
+| Hook-Werkzeugnamen | `Bash` (Ausführen und damit Lesen und Suchen), `apply_patch` (Schreiben) |
+| Projektverzeichnis im Hook-Befehl | keine Variable – das Arbeitsverzeichnis |
+| Sperrform des Schutz-Hooks | `hookSpecificOutput.permissionDecision = "deny"`, Exit 0 |
+
+Die Abbildung ist kein freies Feld: Die Präfixform eines Befehlsverbots muss ein Präfix seiner wörtlichen Form sein, und bei `allow` müssen beide Formen übereinstimmen – sonst scheitert die Installation. Was sich **gar nicht** abbilden lässt, steht in Abschnitt 4 und nicht in einer Ausnahme im Code.
+
+## 1b. Der Vertrauenseintrag – die Bedingung über der ganzen projektlokalen Schicht
+
+🔴 **Konfiguration, Hooks und Befehlsregeln laden nur, wenn das Projekt in der Benutzerkonfiguration des Clients als vertraut eingetragen ist.** A/B gemessen mit zwei Benutzerverzeichnissen und identischem Projekt; der Client sagt es selbst: *„Project-local config, hooks, and exec policies are disabled in the following folders until the project is trusted, but skills still load."*
+
+Ein versionierter Träger, der nicht lädt, trägt nichts. Der Eintrag liegt **außerhalb des Repositoriums**, ist je Arbeitsplatz zu setzen und kann vom Framework nicht ausgeliefert werden. Die erzeugte `.codex/config.toml` nennt die Bedingung in ihrem Kopfkommentar; **B1**, **H1** und **H2** tragen sie in ihrer Belegzelle.
+
+Der Eintrag wird üblicherweise einmal und beiläufig erteilt: Im Vorbedingungsdurchgang von `1.3.0` lag auf dem Arbeitsplatz des Frameworks ein Eintrag auf das **Benutzerprofil**, der jeden Pfad darunter einschließt – und einer auf den alten Projektnamen.
+
+**Die Hooks tragen eine zweite, schärfere Bedingung:** Ein Hook läuft erst, wenn ihm **einzeln vertraut** wurde; das Vertrauen hängt an einem **Hash**. Gemessen am 2026-09-23: Ohne dieses Vertrauen läuft der Schutz-Hook **gar nicht**, der Köderinhalt kommt heraus – und `codex doctor --all` meldet es nicht. **Jede Hebung des Frameworks ändert den Hook und damit den Hash:** Ein Projekt, das nach `install.py --update` nicht erneut vertraut, läuft ab dann ohne Schutz-Hook.
+
+## 2. Fähigkeitsmatrix
+
+Einstufung je Zusage: `[TECHNISCH]` erzwungen · `[TEXTUELL]` nur Anweisung · `[NICHT ABBILDBAR]` kein Mechanismus. Regeln in `../README.md` Abschnitt 4.
+
+**Zur Belegspalte.** Dieses Pack trägt keine `[DOK]`-Zeile (siehe Vorbemerkung); wo andere Packs eine Quellenkennung führen, steht hier das Wort **gemessen** mit dem Messmittel. Prüfung 73 verlangt eine Quellenkennung nur von `[DOK]`-Zeilen.
+
+### R – Regelladung
+
+| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
+|---|---|---|---|---|
+| R1 | Wurzel-Anweisungsdatei wird ungefragt geladen | `AGENTS.md` steht als eigene Nachricht im Prompt jeder Sitzung | `[TECHNISCH]`, **mit benannter Bedingung** | **gemessen** (2026-09-23, `codex debug prompt-input`): Der vollständige Text steht im Prompt. **Die Bedingung ist die Verdrängung:** Liegt `AGENTS.override.md` daneben, steht die Wurzel-Anweisung in **keiner** Nachricht – gemessen mit Gegenprobe. Eine Wurzel-Anweisung, die eine ungeprüfte Datei im selben Verzeichnis ersetzen kann, ist keine Ebene 1, sondern ein Standard. **Prüfung 88** meldet die Datei, der `deny`-Korb stellt sie schreibgeschützt, und der Schutz-Hook führt sie in seinen Mustern |
+| R2 | Regeldateien mit Ladebedingungen | **Kein Mechanismus.** **Ersatz, geliefert:** Die Wurzel-Anweisung **nennt** die Regeldateien mit der Auflage, sie zu Beginn der Sitzung zu lesen (`root_instruction_imports`) | `[NICHT ABBILDBAR]` | **gemessen mit drei Sonden:** Eine Anweisungsdatei in einem Unterverzeichnis steht nicht vorab im Kontext; eine Einbindung mit `@<pfad>` bleibt wirkungslos; nur `AGENTS.md` des Projekts und die gleichnamige Datei im Benutzerverzeichnis des Clients laden ungefragt. Die Mechanik des Ersatzes hat mit diesem Pack ihren ersten Gegenstand (D-348). ⚠️ **Der Ersatz ist schwächer:** Was eine Nennung bewirkt, hängt am Modell und nicht an der Engine |
+| R3 | Regeln an Dateimuster bindbar | **Kein Mechanismus.** **Ersatz:** dieselbe Nennung – ein Technology Pack lädt damit **immer** statt nur bei seinen Dateien | `[NICHT ABBILDBAR]` | wie R2. Die Verschärfung ist benannt: Unbedingtes Laden ist mehr Kontext, keine Lockerung – dieselbe Richtung wie die Abbildung von `model_decision` beim Pack `claude-code`. Ein später hinzugefügtes Technology Pack braucht dafür **kein** erneutes `install.py --update`: Die Nennung führt `<RULES_DIR>/40-*.md` als Muster, *„soweit vorhanden“* (`root_instruction_imports`, D-397) |
+| R4 | Bekanntes Zeichenlimit | **Vorgabe des Frameworks, keine Produkteigenschaft** – Wurzel-Anweisung und die dort genannten Regeln zusammen höchstens 40.000 (verbindlich, D-387); 12.000 je Regeldatei und 6.000 für die Overlay-Laufzeitregel als SOLL-Grenzen, die bei diesem Pack nicht geprüft werden, weil die Regeln über die Wurzel-Anweisung eingebunden sind | `[TEXTUELL]` | `[EMPF]`. **Für diesen Client ist kein Limit erhoben**; der Prompt-Eingang zeigt den vollständigen Text der Wurzel-Anweisung, eine Obergrenze sagt er nicht. `K-19` gilt hier ebenso |
+| R5 | Die geladenen Regelquellen sind vollständig aufzählbar | `codex debug prompt-input` gibt **jede** Nachricht aus, die der Client der nächsten Anfrage voranstellt – ohne eine Anfrage zu stellen | `[TEXTUELL]` | **gemessen, und schärfer als bei beiden Schwesterpacks:** Die Auskunft ist nicht ein Register des Clients über seine Konfiguration, sondern **der Kontext selbst**. Damit ist auch eine **Abwesenheit** ablesbar – die Verdrängung aus R1 ist genau so gefallen. **Trotzdem `[TEXTUELL]`:** Eine Auskunft ist keine Schranke, und sie entsteht nur, wenn ein Mensch das Kommando ausführt |
+| R6 | Keine Importe fremder Werkzeugformate | **Kein Schalter erhoben.** Gemessen ist die Lage: Dieser Client liest `.codex/skills/` und `.agents/skills/` – **nicht** die Skillablage eines fremden Werkzeugs | `[NICHT ABBILDBAR]` | **gemessen** (drei Sonden): Eine dritte, naheliegende Ablage an der Projektwurzel lädt nicht; eine fremde Ablage ist in der Herkunftstabelle des Prompts nicht aufgetaucht. **Ersatz: die Auskunft in Abschnitt 7** – und der gemessene Befund, dass es hier nichts abzuschalten gibt. ⚠️ Das ist eine Aussage über diesen Stand, keine Zusage des Herstellers |
+
+### S – Skills
+
+| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
+|---|---|---|---|---|
+| S1 | Versionierte Skills im Repository | `.codex/skills/<name>/SKILL.md` mit Frontmatter | `[TECHNISCH]` | **gemessen:** Ein Skill aus dieser Ablage steht mit Name und Beschreibung im Prompt jeder Sitzung, samt Herkunftswurzel |
+| S2 | Gezielter Aufruf | Der Prompt führt die Skills als Liste mit Beschreibung und Pfad; das Modell liest die `SKILL.md` | `[TEXTUELL]` | **`BELEG OFFEN` für den Aufruf als Werkzeugaufruf** (2026-09-23): Gemessen ist, dass die Skills **im Kontext stehen**; ob dieser Client einen eigenen Werkzeugaufruf oder eine Schrägstrich-Form dafür führt, ist unerhoben. Ohne das ist der Aufruf Modellverhalten |
+| S3 | Werkzeugbeschränkung je Skill | **Unerhoben.** Die Frontmatter-Felder `permissions` und `triggers` erreichen die installierte Fassung **unverändert** – dieses Pack führt sie nicht in `drop_fields` | `[TEXTUELL]` | **`BELEG OFFEN`** (2026-09-23): Ob ein Frontmatter-Feld den Werkzeugbestand eines Skills begrenzt, ist bei diesem Client nicht gemessen, und **ein unbekanntes Frontmatter-Feld meldet er nicht**. Ein geratenes Feld sähe aus wie eine Schranke. **Was trägt, ist die globale Schicht:** die Befehlsregeln und der Schutz-Hook, beide unabhängig vom Skill – weniger als eine Beschränkung je Skill, und das ist die Aussage (Bauform von B01, D-50) |
+| S4 | Schreibende Skills nur benutzergetriggert | Framework-Konvention, statisch geprüft durch `validate-framework.py` | `[TEXTUELL]` | `[EMPF]`. **Ein Feld, mit dem sich ein Skill vom Modellzugriff ausnehmen ließe, ist bei diesem Client unerhoben** – `model_invocation_field` bleibt deshalb leer, und das ist eine Aussage über den Belegstand. **Reichweite:** Die Zusage gilt für die Skill-Ablage, die das Framework schreibt |
+| S5 | Die geladenen Skills sind vollständig aufzählbar, samt Herkunft | Der Prompt-Eingang führt eine **Tabelle der Skillwurzeln** (`r0`, `r1`, …) und je Skill Name, Beschreibung und Pfad relativ zu seiner Wurzel | `[TEXTUELL]` | **gemessen erfüllt, und vollständiger als bei beiden Schwesterpacks:** Die Aufzählung ist nicht ein Kommando, das mehr zeigt als lädt (`devin-desktop`, D-288), sondern **der Sitzungskontext selbst**. Drei Sonden an drei Orten, eine negativ. Zwei eingebaute Skillwurzeln des Clients stehen mit darin – die Auskunft ist damit auch die Stelle, an der man sie sieht |
+
+### B – Berechtigungen
+
+> **`[TECHNISCH]` heißt in diesem Block:** Die Engine setzt die Regel durch, **solange der Betriebsmodus die Berechtigungsprüfung nicht abschaltet** (D-35). Für dieses Pack kommen **zwei weitere, gemessene Bedingungen** hinzu:
+>
+> **(1) Der Vertrauenseintrag.** Konfiguration, Hooks und Befehlsregeln laden nur bei eingetragenem Vertrauen (Abschnitt 1b). Ohne ihn trägt von diesem Block **nichts**.
+>
+> **(2) Die Rechtestufe des Betriebssystems.** Auf einem unerhöhten Windows-Arbeitsplatz kann der Sandkasten dieses Clients ein `deny`-Leserecht nicht durchsetzen – und der Client läuft dann gar nicht: *„windows unelevated restricted-token sandbox cannot enforce deny-read restrictions directly; refusing to run unsandboxed"*. Das Verhalten ist fail-closed und damit richtig. Für das Pack heißt es: Die Pfadseite trägt **Schreibverbote**, aber **kein Leseverbot** – der zweite Fall für die Vorbemerkung nach D-35, diesmal abhängig nicht vom **Modus**, sondern vom **Betriebssystem und der Rechtestufe**.
+>
+> **Dort trägt die zweite Linie:** Im Betriebsmodus, der Rückfragen **und** Sandkasten abschaltet, hat der Schutz-Hook denselben Lesezugriff blockiert, den die Berechtigungsschicht durchließ – gemessen mit Gegenlauf, in einem Baum **ohne** Regeltexte. Erste und zweite Linie fallen unter verschiedenen Bedingungen; das ist die empirische Rechtfertigung des Hooks.
+>
+> **(3) Der Startort der Sitzung** (D-408, gemessen am 2026-09-26 mit Clientversion 0.157.0, **ohne Modellaufruf** mit `codex doctor --all` und `codex debug prompt-input`, `tests/protocols/2026-09-26-mehrprojekt-tokenlast.md`). Der Client setzt die Projektwurzel auf die **git-Wurzel** des Startverzeichnisses. Startet die Sitzung in einem Repositorium unterhalb der Installation, lädt er **weder deren Konfigurationsdatei noch deren Wurzel-Anweisung**: Die Konfigurationsschicht meldet dort keinen der Einträge, die sie in der Wurzel meldet, und der Prompteingang trägt keine `AGENTS.md`. Eine eigene Installation im Repositorium lädt. Gemessen ist das **Laden**, nicht die Durchsetzung – die Aufgabenläufe dieses Tages scheiterten an der Anmeldung (D-410). **Nichts meldet einen falschen Startort** (`K-159`).
+
+Die mit **Kern** markierten Zeilen sind die Kernzusagen; die Berechtigungsdatei dieses Packs ist TOML und führt keinen Block `_core_rules_integrity` (D-395). Eine Abweichung von `[TECHNISCH]` ist begründungspflichtig.
+
+| ID | Zusage des Frameworks | Kern | Mechanismus beim Client | Einstufung | Beleg |
+|---|---|---|---|---|---|
+| B1 | Berechtigungen versioniert im Repository | ja | `.codex/config.toml` (Pfadseite) **und** `.codex/rules/koolie.rules` (Befehlsseite) – beide im Projekt, beide versioniert | `[TECHNISCH]`, **bedingt** | **gemessen:** Beide Träger liegen im Repositorium und werden aus derselben Kernquelle erzeugt. **Die Bedingung steht außerhalb:** Ohne Vertrauenseintrag lädt **keiner von beiden** (Abschnitt 1b, A/B gemessen) |
+| B2 | Verweigern vor Rückfragen vor Erlauben | ja | Die Regelsprache kennt `forbidden`, `prompt` und `allow`; bei mehreren Treffern gilt die **strengste** | `[TECHNISCH]` | **gemessen mit dem Auswerter der Engine selbst** (`codex execpolicy check`, 2026-09-23): Zwei Regeln auf denselben Befehl, `allow` und `forbidden` → `forbidden`; `prompt` und `allow` → `prompt`. **Unabhängig von der Reihenfolge in der Datei** – beide Fälle einmal in jeder Reihenfolge gefahren |
+| B3 | Secret-Dateien per Pfadmuster lesegeschützt | ja | **Kein abbildbarer Mechanismus.** **Ersatz: der Schutz-Hook**, gemessen – siehe Abschnitt 4 | `[NICHT ABBILDBAR]` | **gemessen, und die beiden Gründe verstärken einander.** **(1) Musterform und Versionierbarkeit schließen einander aus:** Ein Musterausdruck ist als Schlüssel nur mit **absolutem** oder `~/`-Vorsatz zulässig – und ein absoluter Pfad in einem versionierten Träger wäre ein Wert dieser Arbeitsstation; ein projektrelativer Schlüssel (`:workspace/…`) nimmt **kein** Muster (*„must be absolute, use `~/…`, or start with `:`"*) – gemessen mit 0.156.1. 🟢 **Nachgemessen am 2026-09-30 mit 0.157.1 (`K-160`, D-495):** Ein projektrelativer Glob unter `:workspace_roots` (`"**/*.env" = "deny"`) wird jetzt **angenommen** – Grund (1) gilt für diese Version nicht mehr. Grund (2) trägt allein: Unerhöht startet `codex sandbox` mit jeder `deny`-Leseregel gar nicht, auch nicht für eine harmlose Datei (*„Restricted read-only access requires the elevated Windows sandbox backend“*); die Kontrolle ohne Regel liest den Köder. **(2) Ein `deny`-Leserecht verlangt den erhöhten Windows-Sandkasten**, und ohne ihn läuft der Client gar nicht. **Ersatz, gemessen:** Der Schutz-Hook blockiert den Lesezugriff auf `.env` – in einem Baum ohne Regeltexte und im Modus ohne Rückfragen und ohne Sandkasten, mit Gegenlauf, in dem der Köderinhalt wörtlich herauskam. **Kernzusage: Abschnitt 4 und Freigabe durch `<SECURITY_CONTACT>`** |
+| B4 | Framework- und Overlay-Artefakte schreibgeschützt | ja | In der Tabelle `":workspace_roots"`: `".koolie/core" = "read"`, `".codex" = "read"`, `"AGENTS.md" = "read"` **und** der Schutz-Hook. **Das Overlay sperrt seit `1.17.0` allein der Schutz-Hook** (D-448); die Berechtigungsdatei führt es nicht mehr – nachgezählt an einer Installation am 2026-09-29 (D-468) – für das Overlay wirkt der Sandkasten damit nicht mehr, Shell-Befehle hält dort nur die Regelschicht | `[TECHNISCH]` für das direkte Schreiben (über den Hook) **und für Shell-Befehle im Sandkasten** (seit `1.12.1` gemessen); **`[TEXTUELL]`, wo der Sandkasten abgeschaltet ist** (M6, B9) | **Der Hook ist gemessen** (2026-09-23, Baum ohne Regeltexte): Ein `apply_patch` auf `.koolie/core/notiz.txt` wurde blockiert; **im Lauf davor, mit der alten Musterform, wurde die Datei angelegt.** Der Befund dahinter: Das Schreibwerkzeug dieses Clients führt **keinen Pfad in einem Feld** – der Pfad steht im **Patchtext**, hinter einem Leerzeichen, und die Pfadmuster des Hooks kannten als Grenze nur den Schrägstrich (D-347). 🟢 **Die Pfadseite ist seit `1.12.1` an ihrer Wirkung gemessen** (D-412, `K-157`), mit Clientversion 0.157.1 und Sandkasten `restricted`: **Ohne Modellaufruf** (`codex sandbox`) sind mit der Tabelle `:workspace_roots` `.koolie/core`, `.koolie/project-overlay` (damals noch in der Tabelle), `.codex` und `AGENTS.md` schreibgeschützt und der übrige Arbeitsbereich schreibbar; **in zwei Sitzungen** (Baum ohne Regeltexte, Hook ohne Vertrauen, also nicht beteiligt) scheitert ein Shell-Befehl auf `.koolie/core` mit *„Zugriff verweigert“*, der Kontrolllauf auf eine freie Datei schreibt. 🔴 **Mit der bis `1.12.0` ausgelieferten Form `:workspace/<pfad>` meldet 0.157 jeden Eintrag als unbekannt und ignoriert ihn – und der GANZE Arbeitsbereich ist schreibgeschützt**, auch die freie Datei. `install.py --update` fasst `config.toml` nicht an; bestehende Installationen ziehen die Tabelle von Hand nach |
+| B5 | CI-, Quality-Gate- und Lockdateien schreibgeschützt | ja | **Kein abbildbarer Mechanismus, und Ersatz: keiner** – der Schutz-Hook deckt diese Pfade nicht; siehe Abschnitt 4 | `[NICHT ABBILDBAR]` | **gemessen:** Die Regeln des Kerns sind hier **Namensmuster** (`**/*.lock`, `**/package-lock.json`, …) und **Platzhalterlisten** (`<CI_CONFIG_PATHS>`, `<QUALITY_GATE_CONFIG_PATHS>`). Für beide gilt dieselbe Schlüsselsyntax wie bei B3: kein Muster ohne absoluten Vorsatz, kein Schlitz auf der Schlüsselseite einer TOML-Tabelle. **Und der Schutz-Hook trägt sie nicht** – seine Muster decken Secrets, die Laufzeitschicht und das Kernverzeichnis, nicht die Lockdateien eines Projekts. **Kernzusage: Abschnitt 4 und Freigabe durch `<SECURITY_CONTACT>`** |
+| B6 | Befehle per Muster verweigerbar | ja | `prefix_rule(pattern = [...], decision = "forbidden")` in `.codex/rules/koolie.rules` | `[TECHNISCH]` | **an einer realen Installation gemessen** (2026-09-23): Der Befehl wurde abgewiesen, **und der Client nannte die Begründung dieser Datei wörtlich** – dieselbe Zurechenbarkeit wie beim `deny`-Korb von `devin-desktop`. Zusätzlich mit dem Auswerter der Engine gegengeprüft: `git push origin main` → `forbidden`, `git status` → `allow`. ⚠️ **Grenze, gemessen und benannt:** `git -C . push` trifft `["git","push"]` **nicht** – dieselbe Grenze wie bei `claude-code`. 🟢 **Über die Ablagen hinweg gemessen am 2026-09-30 (`K-119`, D-496):** Eine Regeldatei im Benutzerverzeichnis des Clients hebt eine des Projekts **nicht** auf – `allow` dort gegen `forbidden` hier und umgekehrt: beide Male abgewiesen, mit der Begründung der verbietenden Datei, das Remote blieb leer; `codex execpolicy check` über beide Dateien liefert in jeder Reihenfolge `forbidden`. Die strengste Entscheidung gewinnt, die Zeile braucht keine Bedingung |
+| B7 | Schreiboperationen fragen zurück | – | `approval_policy = "on-request"` als Standard des Clients | `[TECHNISCH]` für den Modus; **`[TEXTUELL]` für die Regel je Pfad** | **gemessen** (`codex doctor`): Der Standard ist `OnRequest`. **Die `ask`-Regel des Kerns auf alle Schreiboperationen ist hier nicht abbildbar** – dieser Client kennt keine Rückfrageregel je Pfad, nur eine Politik je Sitzung. ⚠️ **Und die projektlokale Schicht kann sie lockern** (B9) |
+| B8 | Netzwerkzugriff standardmäßig unterbunden | – | Netzsandkasten des Clients (`restricted`) **und** die Befehlsregeln auf `curl`, `wget`, `ssh`, `scp` | `[TECHNISCH]` für den Sandkasten und für diese vier Programme; **`[TEXTUELL]` darüber hinaus** | **gemessen** (`codex doctor`: *network sandbox restricted*; die vier Programme stehen im `forbidden`-Korb der erzeugten Regeldatei). ⚠️ **Jedes andere netzfähige Programm ist nicht erfasst**, und die Liste wird bewusst nicht verlängert |
+| B9 | Nutzerlokale Konfiguration kann nur verschärfen | – | **Widerlegt, und zwar im Spiegelbild** | `[TEXTUELL]` | **gemessen mit Gegenprobe** (A/B, zwei Benutzerverzeichnisse): Nicht die nutzerlokale Konfiguration lockert die projektseitige – **die projektlokale lockert den Benutzerstandard.** Mit Vertrauenseintrag schlagen `approval_policy = "never"` und ein Sandkastenmodus ohne Schranken **aus dem Projekt heraus** den Standard des Arbeitsplatzes. Dieselbe Frage, drei Clients, drei Antworten: `claude-code` hält die Richtung, `devin-desktop` kehrt sie um, und hier ist die **lockernde Seite die versionierte**. ⚠️ **Für ein aufnehmendes Projekt heißt das:** Wer die Berechtigungsdatei liest, liest auch, was sie am Arbeitsplatz **aufhebt** |
+| B10 | Externer Abruf auf freigegebene Domains beschränkbar | – | **Kein Mechanismus.** Der Kern sagt die Beschränkung nicht zu (B11, D-59) | `[NICHT ABBILDBAR]` | **Kein Ersatz durch das Framework, und das ist eine Aussage und kein Rest.** Was den Kanal steuert, ist der **Netzsandkasten** des Clients (B8) und die Befehlsregel auf die vier Programme; eine Domainangabe kennt keine der beiden Schichten. **Der organisatorische Ersatz** ist die Freigabezeile des Overlays, und sie hat nach D-65 keine technische Seite |
+
+### H – Hooks
+
+| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
+|---|---|---|---|---|
+| H1 | Prüfung vor Werkzeugausführung | `PreToolUse` in `.codex/hooks.json`, Matcher `Bash\|apply_patch` | `[TECHNISCH]`, **doppelt bedingt** | **gemessen an einer realen Installation** (2026-09-23): Der Hook läuft bei jedem Shell- und jedem Schreibaufruf; der Umschlag führt `session_id`, `turn_id`, `transcript_path`, `cwd`, `hook_event_name`, `model`, `permission_mode`, `tool_name`, `tool_input` und `tool_use_id`. **Bedingung 1: `"enabled": true` je Eintrag** – ohne das läuft er nicht, und der Client meldet es nicht. **Bedingung 2: Hook-Vertrauen** – ohne persistiertes Vertrauen läuft er **gar nicht**, der Köderinhalt kommt heraus, und `codex doctor --all` sagt nichts dazu. **Jede Hebung des Frameworks ändert den Hash** (Abschnitt 1b) |
+| H2 | Prüfung kann **blockieren** | `hookSpecificOutput.permissionDecision = "deny"` und **Exit 0** | `[TECHNISCH]` | 🔴 **Gemessen, und der schwerste Befund dieses Packs** (D-347): Die Standardsperrform des Schutz-Hooks – `{"decision": "block"}` und **Exit 2** – bewirkt bei diesem Client **nichts**. Der Client meldet *PreToolUse Failed* und **führt die Operation aus**; im Gegenlauf kam der Köderinhalt wörtlich heraus. **Dieselbe Sperre in der Form, die er liest, blockiert** – gemessen in einem Baum **ohne** Regeltexte und im Modus, der Rückfragen **und** Sandkasten abschaltet, mit Positivkontrolle im selben Baum. Ein Hook, der läuft und dessen Sperrform der Client nicht liest, ist eine Zusage ohne Mechanismus. **Prüfung 86** hält die Kette aus Manifest, Skript und erzeugtem Kommando zusammen |
+| H3 | Statusmeldung beim Sitzungsstart | `SessionStart` mit `hook-overlay-status.py` | `[TECHNISCH]` | **beobachtet** (2026-09-23): Der Hook läuft, und **seine Ausgabe steht im Sitzungskontext** – ein Lauf im Baum ohne Regeltexte hat den Overlay-Status daraus zitiert. Das ist mehr als bei beiden Schwesterpacks, wo die Meldung selbst unbeobachtet blieb |
+| H4 | Eingabeschema und Pfadidentität des Schutz-Hooks | Ereignisprüfung, Pfadidentität über den aufgelösten Pfad, alle Pfadmuster ohne Rücksicht auf Groß-/Kleinschreibung. **`hook_fail_closed` steht auf `false`**. **Grenze:** Ein Hook prüft **vor** dem Zugriff; eine zwischenzeitlich umgebogene Verknüpfung kann er nicht ausschließen (`CR-2026-047` E5, D-397) | `[TECHNISCH]` für die Musterprüfung, **mit zwei benannten Grenzen und der Zeitlücke** | **Das Schema von `PreToolUse` ist aufgezeichnet** (zehn Felder, siehe H1) – **der vollständige Bestand der zwölf Ereignisse ist es nicht**, und deshalb bleibt `hook_fail_closed` auf `false`: Fail-closed bei teilweise erhobenem Schema wäre keine Härtung, sondern eine Sitzung, die bei der ersten unbekannten Eingabeform blockiert (D-31). **Zweite Grenze, gemessen und behoben:** Das Schreibwerkzeug führt **keinen Pfad in einem Feld**; er steht im Patchtext hinter einem Leerzeichen. Die Pfadmuster des Hooks erkennen deshalb auch das Leerzeichen als Grenze – eine **Verschärfung für alle drei Packs** (D-347) |
+
+### A – Agentenprofile
+
+| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
+|---|---|---|---|---|
+| A1 | Rein lesendes Reviewprofil | **Nicht abgebildet.** Der Client liest Rollendateien als `.codex/agents/<name>.toml`; das Framework legt sein Profil als Markdown ab | `[NICHT ABBILDBAR]` | **Die Gestalt ist gemessen, die Wirkung nicht** (2026-09-23): Pflichtfelder `name`, `description`, `developer_instructions`; `permissions` wird als Tabelle angenommen, `allowed_tools` verworfen. **Nicht gemessen ist, ob und wie ein Feld den Werkzeugbestand eines Unteragenten begrenzt** – und dieser Client startet Unteragenten (der Prompt führt sechs Werkzeuge dafür). **Ersatz, benannt:** Der Schutz-Hook und die Befehlsregeln wirken unabhängig vom Profil; ob sie einen Unteragenten **erfassen**, ist ebenfalls unerhoben. Eine Abbildung ohne Messung wäre dieselbe Lage, aus der `AP2-CC-13` kam |
+| A2 | Rein lesendes Analyseprofil für Modus M1 | **Kein eingebautes Profil erhoben** | `[NICHT ABBILDBAR]` | **Ersatz, benannt:** der Standardmodus des Clients (`approval_policy = "on-request"`, Sandkasten lesend) – er ist gemessen und wirkt ohne Profil. ⚠️ **Das ist ein Modus und kein Profil**, und der Unterschied ist, dass er für die ganze Sitzung gilt |
+
+### M – Modi und Sitzungsfreigaben
+
+| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
+|---|---|---|---|---|
+| M1 | Standardmodus fragt bei Schreiben und Befehlen zurück | `approval_policy = "on-request"`, Sandkasten `read-only` | `[TECHNISCH]` | **gemessen** (`codex doctor`): *approval OnRequest · restricted fs + restricted network*. ⚠️ **Der nicht-interaktive Lauf kennt keine Rückfrage** – dort wird abgewiesen statt gefragt; das ist eine Verschärfung und kein Messwert über den interaktiven Betrieb |
+| M2 | Modus ohne Rückfragen ausschließbar | **Eine Sperre des Modus ist nicht erhoben.** Der Modus selbst heißt `--dangerously-bypass-approvals-and-sandbox` und bezeichnet sich als gefährlich | `[TEXTUELL]` | **Was gemessen ist, ist die Wirkung der zweiten Linie:** In genau diesem Modus hat der Schutz-Hook den Zugriff blockiert, den die Berechtigungsschicht durchließ. ⚠️ **Die Sperre des Modus bleibt unerhoben** – eine Organisationsebene, die ihn ausschlösse, ist für diesen Client nicht gemessen |
+| M3 | Freigabe auf die Sitzung begrenzbar | Der Client kennt eine Freigabe „für die Sitzung" und eine über ein Befehlspräfix | `[TEXTUELL]` | **`BELEG OFFEN`** (2026-09-23): Die Stufen sind in der Bedienoberfläche des Clients benannt; **im nicht-interaktiven Betrieb ist keine davon messbar** – eine Rückfrage an einen Menschen lässt sich so nicht messen. Dieselbe Enthaltung wie bei `devin-desktop` für `ask` und `allow` (D-280) |
+| M4 | Eigener Planungsmodus für Modus M2 | **Unerhoben:** ob der Client einen Planungsmodus mit eigener Plan-Ablage außerhalb des Repositorys führt. Bis dahin ist die Ablage von `fw-plan` und `fw-bugfix-prepare` die Sitzungsausgabe | `[TEXTUELL]` | **`BELEG OFFEN`** (2026-09-25, `K-149`): nicht gemessen; eine Quellenliste gibt es für diesen Client nicht |
+| M6 | Modus mit selbsttätiger Übernahme von Dateiänderungen begrenzbar | Sandkastenmodus `workspace-write` – nach D-05 nur über dokumentierte Ausnahme bei Kontrollstufe niedrig zulässig | `[TEXTUELL]` | `[EMPF]` für die Beschränkung; **eine Abschaltung des Modus ist nicht erhoben**. ⚠️ **Und die projektlokale Schicht kann ihn setzen** (B9) – das ist der Unterschied zu beiden Schwesterpacks |
+| M7 | Modus, der selbst beurteilt, was sicher ist, begrenzbar | **Ein solcher Modus ist für diesen Client nicht erhoben** | `[TEXTUELL]` | **Ersatz, benannt:** Es gibt keinen – die Zusage hat hier keinen Gegenstand, solange kein selbst beurteilender Modus erhoben ist. Eine Zusage ohne Gegenstand ist keine erfüllte Zusage; sie steht hier, damit sie nicht als eine gelesen wird |
+
+### X – Externe Anbindung
+
+| ID | Zusage des Frameworks | Mechanismus beim Client | Einstufung | Beleg |
+|---|---|---|---|---|
+| X1 | Keine externe Anbindung ohne Einzelfreigabe | Das Framework liefert **keinen** MCP-Server aus; ein Server wäre eine Tabelle `[mcp_servers.<name>]` in der Berechtigungsdatei | `[TEXTUELL]`, **mit einer benannten Grenze** | **gemessen:** Ohne Eintrag zählt der Client **null** Server; ein projektlokal eingetragener wird gezählt. **Die Grenze:** Eine Rückfrageregel je MCP-Werkzeug – die `ask`-Regel des Kerns – ist bei diesem Client **nicht abbildbar**. Was trägt, ist die Abwesenheit des Eintrags, und die ist eine Framework-Entscheidung, keine Schranke des Clients. ⚠️ **Die Benutzerkonfiguration kann Server führen**, und sie liegt außerhalb des Repositoriums (Abschnitt 7.2) |
+| X2 | Art und Ort der Codebasis-Indexierung bekannt | Kein Mechanismus zur Steuerung bekannt | `[NICHT ABBILDBAR]` | `BELEG OFFEN (dauerhaft)` – von außen nicht zu beobachten, Stand 2026-09-23 (`K-20`, D-292). **Kein Ersatz durch das Framework:** Was ein Client indexiert und wohin er es gibt, sieht weder die Installation noch der Validator. Nach D-41 eine **Fähigkeitszusage**, keine Kernzusage |
+
+## 3. Zusammenfassung der Durchsetzungstiefe
+
+> **Zählregel (normativ für diese Tabelle):** Eine Zeile zählt bei ihrer **schwächsten** Einstufung. Trägt sie zwei Angaben je Zugriffskanal, zählt sie als die schwächere (D-47). Prüfung 31 rechnet die Summen aus der Matrix nach.
+
+| Klasse | Anzahl | davon Kernzusagen |
+|---|---|---|
+| `[TECHNISCH]` | **10 von 35** | 3 von 6 (B1, B2, B6) |
+| `[TEXTUELL]` | **16 von 35** | 1 von 6 (B4 – Shell und Unterprozess) |
+| `[NICHT ABBILDBAR]` | **9 von 35** | 2 von 6 (B3, B5) |
+
+**Belegstand:** `BELEG OFFEN` sagen **S2**, **S3**, **M3** und **M4**, dazu **X2** dauerhaft. Das ist der schwächste Belegstand der drei Packs, weil dieses Pack am Tag seines Baus entstanden ist: Die Zeilen, die eine reale Installation brauchen, sind gefahren (B2, B4, B6, H1 bis H3, R1, R5, S1, S5), die übrigen nicht. ⚠️ **Die Produktbeobachtung fehlt ganz** – `FW-AK-01` ist für diesen Client nicht gefahren, und es gibt keine Quellenliste.
+
+## 4. Kernzusagen ohne technische Durchsetzung
+
+**Zwei der sechs Kernzusagen sind `[NICHT ABBILDBAR]`.** Damit greift `clients/README.md` Abschnitt 4 vollständig: Begründung hier, dokumentierte Ausnahme im Overlay des aufnehmenden Projekts (`.koolie/project-overlay/exceptions/EXCEPTIONS.md`) – und **keine Inbetriebnahme ohne Freigabe durch `<SECURITY_CONTACT>`.**
+
+| ID | Einstufung | Warum der Client das nicht durchsetzt | Ersatzmaßnahme | Freigabe |
+|---|---|---|---|---|
+| B3 | `[NICHT ABBILDBAR]` | **Zwei gemessene Gründe, die einander verstärken.** (1) Die Schlüssel der Pfadrechteschicht nehmen ein Muster nur mit **absolutem** oder `~/`-Vorsatz an; ein projektrelativer Schlüssel nimmt keines. **Musterform und Versionierbarkeit schließen einander aus** – und B1 verlangt die Versionierbarkeit. (2) Ein `deny`-Leserecht verlangt den **erhöhten Windows-Sandkasten**; ohne ihn weist der Client den Start ab (fail-closed). Mit 0.157.1 entfällt (1) – der projektrelative Glob wird angenommen –, (2) trägt allein (`K-160`, D-495) | **Ersatz: der Schutz-Hook, und er ist gemessen.** Er blockiert den Lesezugriff auf `.env` in einem Baum ohne Regeltexte und im Modus ohne Rückfragen und ohne Sandkasten, mit Positivkontrolle. ⚠️ **Er trägt die Bedingungen aus H1** – `enabled` und Hook-Vertrauen | `<SECURITY_CONTACT>` |
+| B5 | `[NICHT ABBILDBAR]` | Die Regeln des Kerns sind hier **Namensmuster** (`**/*.lock`) und **Platzhalterlisten** (`<CI_CONFIG_PATHS>`, `<QUALITY_GATE_CONFIG_PATHS>`). Für die Muster gilt derselbe Grund wie bei B3; für die Listen kommt hinzu, dass die Schlüsselseite einer TOML-Tabelle keinen Ausfüllschlitz kennt | 🔴 **Kein vollständiger Ersatz, und das ist die Aussage.** Der Schutz-Hook deckt Secrets, die Laufzeitschicht und das Kernverzeichnis – **nicht** die Lockdateien eines Projekts. Was bleibt, ist die Regelschicht: Die Regeltexte verbieten es, und ein Verstoß ist Modellverhalten. **Ein Projekt mit hoher Kontrollstufe sollte diesen Client dafür nicht einsetzen** | `<SECURITY_CONTACT>` |
+
+**B1, B2 und B6 sind `[TECHNISCH]`** – B2 und B6 an der Engine selbst gemessen, B1 über die Lage der Träger, mit der Bedingung des Vertrauenseintrags. **B4** ist es im Kanal *direktes Schreiben* (über den Schutz-Hook); Shell und Unterprozess bleiben `[TEXTUELL]` wie bei beiden Schwesterpacks.
+
+## 5. Bekannte Abweichungen im Verhalten
+
+- **Die Berechtigungsschicht zerfällt in zwei Träger; sechs Prüfungen erreichen dieses Pack deshalb nicht, zwei weitere nur zum Teil** (D-346). Die Ausgabeform dieses Packs ist `toml` (`permissions_format`), nicht `json`: Es gibt hier keine Körbe aus `Werkzeug(Muster)`-Zeilen und keinen Block `_core_rules_integrity` – ein unbekannter Schlüssel in der Konfigurationsdatei wird von diesem Client gemeldet und mit `--strict-config` zum Fehler, eine Integritätsliste darin wäre also ein Fremdkörper. Nicht erreicht: **Prüfung 2**, **Prüfung 37**, **Prüfung 42**, **Prüfung 43**, **Prüfung 54** und **Prüfung 72**. 🔴 **Bis `1.12.1` stand hier „76“** – die Menge des Prüfapparats führte die Nummer falsch; die Prüfung der Kernlage erreicht dieses Pack, die Prüfung „jeder Skill in der Berechtigungsdatei“ nicht, und sie enthielt sich still, weil die TOML-Datei nicht als JSON lesbar ist (D-416). Nur zum Teil: **Prüfung 59** und **Prüfung 89** – ihr Gegenstand (c), der Abgleich der ausgeschlossenen und der Nur-Lese-Pfade des Overlays mit dem `deny`-Korb, entfällt; ihre Gegenstände (a) und (b), der Abgleich mit der Laufzeitfassung, laufen auch hier (D-358). Ein Globwert erreicht `.codex/config.toml` ohnehin nur als Teilbaum (`verz/**`) oder als einzelner Dateiname; ein Namensmuster wie `**/*.tfstate` bleibt `[NICHT ABBILDBAR]` wie `B3`. Der Prüfapparat hält diese Liste gegen seine eigene Liste der formatgebundenen Prüfungen – sie wächst und schrumpft mit ihm, nicht mit diesem Absatz.
+- **Die nutzerlokale Wurzel-Anweisung ersetzt, sie ergänzt nicht.** Deshalb liefert dieses Pack für sie **keine** Beispieldatei aus, während beide Schwesterpacks eine mitgeben; eine Vorlage, die zum Anlegen dieser Datei auffordert, wäre eine Anleitung zum lautlosen Abschalten der Ebene 1.
+- **Die projektlokale Schicht kann lockern** (B9). Bei `claude-code` kann eine nutzerlokale Konfiguration nur verschärfen, bei `devin-desktop` setzt sich die Benutzerkonfiguration in beide Richtungen durch – hier ist die **lockernde Seite die versionierte**. Wer die Berechtigungsdatei liest, liest auch, was sie am Arbeitsplatz aufhebt.
+- 🔴 **Ohne Vertrauenseintrag trägt die gesamte projektlokale Schicht nichts** – Konfiguration, Hooks und Befehlsregeln zusammen. Skills laden trotzdem. Das ist die schärfste Bedingung aller drei Packs, und sie liegt außerhalb des Repositoriums.
+- **Der Hook braucht sein eigenes Vertrauen, und es hängt an einem Hash.** Jede Hebung des Frameworks ändert den Hook und damit den Hash; ein Projekt, das danach nicht erneut vertraut, läuft ohne Schutz-Hook, und nichts meldet es. Das gehört in die Übernahme- und in die Hebungsanleitung des aufnehmenden Projekts.
+- **Der Hook-Prozess bekommt kein Projektverzeichnis in der Umgebung**, sondern steht darin. Die Abbildung bindet deshalb den relativen Punkt. Ein Kommando mit einer Variable hätte gestartet und nichts gefunden.
+- **Ein falsch geschriebenes Sonderziel der Pfadseite fällt lautlos durch.** Gemessen: `:quatsch/x` wird angenommen und steht danach im wirksamen Rechteprofil. Das ist das Gegenstück zur guten Nachricht über unbekannte **Schlüssel** – die werden benannt; ein unbekannter **Wert** eines bekannten Schlüssels nicht.
+- **Zwei Mechaniken des Kerns haben mit diesem Pack ihren ersten Gegenstand:** `rule_frontmatter: "comment"` und `root_instruction_imports` (D-348).
+
+## 6. Installation und Prüfung
+
+Die Starter `install.cmd` (Windows) und `install.command` (macOS) in der Wurzel des Archivs fragen Projekt, Client und Overlay-Muster im Dialog ab und rufen `install.py --target` auf. Ohne Dialog, aus dem entpackten Archiv:
+
+```text
+python .koolie/core/install.py --target /pfad/zum/projekt --client openai-codex
+```
+
+Danach im Projekt:
+
+```text
+python .koolie/core/tests/scripts/validate-framework.py
+```
+
+Ein Projekt, das den Kern schon trägt, wird mit `--update` gehoben; `install.py --client openai-codex` ohne `--target` installiert im aktuellen Verzeichnis.
+
+🔴 **Danach, und ohne das trägt nichts von Abschnitt B:** das Projekt in der Benutzerkonfiguration des Clients als **vertraut** eintragen und dem Schutz-Hook **einzeln vertrauen** – nach jeder Hebung erneut. Beides liegt außerhalb des Repositoriums und kann vom Framework nicht ausgeliefert werden (Abschnitt 1b); `install.py` nennt beide Schritte nach der Installation und das erneute Hook-Vertrauen nach jeder Hebung (D-395).
+
+Vor der ersten produktiven Nutzung sind die Basistests des Testkatalogs (`.koolie/core/tests/TEST_CATALOG.md`, Kennzeichnung „Basis") gegen diesen Client zu fahren und zu protokollieren.
+
+## 7. Anweisungs- und Konfigurationsquellen außerhalb des Projekts
+
+**Pflichtabschnitt.** Er führt, was dieser Client aus Ablagen **außerhalb des Repositoriums** lädt. Solche Quellen haben nach Regel 2.6 der Prioritätshierarchie **keine Ebene**: Sie dürfen einschränken, nie über die Ebenen 1 bis 4 hinaus erweitern und keine Governance-, Datenschutz- oder Sicherheitsregeln setzen (D-34).
+
+**Erhebungsstand: 2026-09-23**, Clientversion `0.156.1`, erhoben mit `codex debug prompt-input`, `codex doctor --all`, `codex execpolicy check` und Sitzungsläufen gegen ein **eigenes Benutzerverzeichnis im Ablagebereich** (`tests/protocols/2026-09-23-bau-openai-codex.md`).
+
+### 7.1 Anweisungsquellen
+
+| Quelle | Ladebedingung | Belegstatus | Maßnahme des Frameworks |
+|---|---|---|---|
+| `<Benutzerverzeichnis des Clients>/AGENTS.md` | in **jeder** Sitzung, zusätzlich zur Wurzel-Anweisung des Projekts | **Gemessen** (2026-09-23): Eine Sonde darin stand im Prompt einer Sitzung, die im Projekt nur ihre eigene `AGENTS.md` hatte | **keine** – sie bleibt Auskunft. Das Framework kann eine Datei außerhalb des Repositoriums nicht abschalten, und ein Schalter dafür ist nicht erhoben |
+| `<Benutzerverzeichnis des Clients>/skills/**` | in jeder Sitzung; die Herkunftstabelle des Prompts führt sie | **Gemessen** (2026-09-23): Die Wurzeltabelle des Prompts nennt sie neben den beiden projektlokalen Ablagen | **keine** – Auskunft. Sie ist aber sichtbar: Die Tabelle nennt je Skill seine Wurzel, und damit ist die Herkunft jeder Sitzung ablesbar (S5) |
+| `<Benutzerverzeichnis des Clients>/rules/*.rules` | Befehlsregeln des Arbeitsplatzes | **Gemessen** (2026-09-23): Eine ungültige Datei dort bricht den Sitzungsstart mit einer Meldung ab, die sie nennt | **keine** – Auskunft. ⚠️ **Sie steht neben den projektlokalen Regeln**, und welche Seite bei einem Treffer gewinnt, ist **unerhoben** |
+| `.agents/skills/**` im Projekt | zweite projektlokale Skillablage | **Gemessen** (2026-09-23) | **keine** – das Framework schreibt nur `.codex/skills/`. Die zweite Ablage ist Gegenstand dieser Auskunft (D-34) |
+
+### 7.2 Konfigurationsquellen
+
+Berechtigungen, Hooks und Einstellungen außerhalb des Repositoriums betreffen genau die Linien, auf denen B1 bis B6 stehen (`CR-2026-038`).
+
+| Quelle | Wirkung | Belegstatus |
+|---|---|---|
+| `<Benutzerverzeichnis des Clients>/config.toml` | **Trägt den Vertrauenseintrag, ohne den die gesamte projektlokale Schicht nicht lädt** – und führt daneben dieselben Schlüssel wie die Projektdatei: Rechteprofile, MCP-Server, Modellwahl | **Gemessen in beiden Richtungen** (A/B mit zwei Benutzerverzeichnissen). ⚠️ **Der Vertrauenseintrag kann auf ein ganzes Elternverzeichnis lauten** und schließt dann jeden Pfad darunter ein – auf dem Arbeitsplatz des Frameworks ist genau das vorgefunden worden |
+| Das Hook-Vertrauen (Hash je Hook) | **Ohne es läuft der Schutz-Hook nicht**, und nichts meldet es | **Gemessen mit Gegenlauf** (2026-09-23): ohne Vertrauen kam der Köderinhalt heraus, mit Vertrauen wurde blockiert |
+
+### 7.3 Was dieser Abschnitt nicht leistet
+
+**Eine Auskunft ist keine Schranke** – und bei diesem Client ist sie die **einzige** Maßnahme: Für keine der vier Anweisungsquellen ist ein Schalter erhoben, mit dem das Framework sie abstellen könnte. Das ist der Unterschied zu beiden Schwesterpacks, die eine Importsteuerung ausliefern (R6).
+
+**Ein Abwesenheitsbeleg altert.** Der Erhebungsstand oben ist am Tag der nächsten Clientversion eine Aussage über die Vergangenheit. Prüfung 19 sieht den Unterschied nicht: Sie prüft die **Anwesenheit** dieser Auskunft, nicht ihre Richtigkeit.
+
+## 8. Änderungsverlauf
+
+| Version | Datum | Änderung | Autor (Rolle) |
+|---|---|---|---|
+| 0.1.0 | 2026-09-23 | **Angelegt (`CR-2026-133`, D-346 bis D-349).** Das dritte Client Pack, und das erste, dessen Belege sämtlich aus Messungen am Client stammen statt aus seiner Dokumentation. **Zwei Kernzusagen sind `[NICHT ABBILDBAR]`** – `B3`, weil Musterform und Versionierbarkeit einander ausschließen und ein `deny`-Leserecht den erhöhten Windows-Sandkasten verlangt; `B5` aus demselben Grund und ohne Ersatz im Schutz-Hook. **Die Sperrform des Schutz-Hooks war bei diesem Client wirkungslos** und ist berichtigt; die Pfadmuster des Hooks kannten als Grenze nur den Schrägstrich und trafen den Patchtext des Schreibwerkzeugs nicht. **Drei neue Prüfungen** (86, 87, 88) | `<FRAMEWORK_OWNER>` |
+| 0.1.4 | 2026-09-25 | Der Satz über die mit **Kern** markierten Zeilen nennt, dass diese Berechtigungsdatei keinen Block `_core_rules_integrity` führt (`CR-2026-147`, D-402; seit D-395 verlangt ihn nur eine JSON-Datei). ⚠️ Die Fassungen `0.1.1` bis `0.1.3` haben hier keine Zeile; sie stehen im Änderungsverlauf des Frameworks zu `1.9.1` bis `1.10.0`. Zeile M4 (Planungsmodus) ergänzt, auf die `fw-plan` und `fw-bugfix-prepare` für die Planablage verweisen: `[TEXTUELL]`, `BELEG OFFEN`; Summen und Belegstand nachgezogen (K-149) | `<FRAMEWORK_OWNER>` |
+| 0.1.5 | 2026-09-26 | Vorbemerkung des B-Blocks, Bedingung (3): **der Startort**, gemessen mit Clientversion 0.157.0 ohne Modellaufruf – im Repositorium unterhalb der Installation laden weder Konfiguration noch Wurzel-Anweisung (D-408). 🔴 **`B4`: Befund `K-157`** – 0.157.0 ignoriert die `:workspace`-Pfadeinträge (`CR-2026-148`) | `<FRAMEWORK_OWNER>` |
+| 0.1.6 | 2026-09-26 | 🟢 **`K-157` beantwortet: das Sonderziel heißt `:workspace_roots`** (D-412, `CR-2026-149`) – Unterpfade als eigene Tabelle; keine Startwarnung mehr. `B4`: die Pfadseite gemessen (Sandkasten, ohne Modell und in zwei Sitzungen), `[TECHNISCH]` auch für Shell-Befehle im Sandkasten. Mit der alten Form war unter 0.157 der ganze Arbeitsbereich schreibgeschützt. `B3`: Vorbehalt `K-160` (dokumentierte `deny`-Globs, nicht nachgemessen). Gemessen mit 0.157.1 – außerhalb der Zielspanne `0.156.x`, die unverändert bleibt | `<FRAMEWORK_OWNER>` |
+| 0.1.7 | 2026-09-26 | Abschnitt 5: **Prüfung 72 statt 76** unter den nicht erreichten Prüfungen – die Menge des Prüfapparats führte die Nummer falsch, und Prüfung 72 enthielt sich bei diesem Pack still (`CR-2026-150`, D-416) | `<FRAMEWORK_OWNER>` |
+| 0.1.8 | 2026-09-29 | Zeile B4 folgt dem Erzeugnis: Die Tabelle `:workspace_roots` führt das Overlay seit `1.17.0` nicht mehr, es sperrt allein der Schutz-Hook (D-448) – für Shell-Befehle im Sandkasten ist das Overlay damit nur noch normativ geschützt (`CR-2026-158`, D-468) | `<FRAMEWORK_OWNER>` |
+| 0.1.9 | 2026-09-30 | **Zwei Messungen an 0.157.1** (`CR-2026-163`, D-495, D-496, `K-119`, `K-160`). Zeile B3: Der projektrelative Glob wird angenommen, das `deny`-Leserecht verlangt weiter den erhöhten Sandkasten – die Einstufung bleibt. Zeile B6: Über die Ablagen hinweg gewinnt die strengste Entscheidung | `<FRAMEWORK_OWNER>` |

package/.koolie/core/clients/openai-codex/manifest.json

@@ -0,0 +1,208 @@
+{
+  "_comment": "Maschinenlesbare Pfad- und Semantikabbildung dieses Client Packs. Die menschenlesbare Fassung mit Faehigkeitsmatrix steht in CLIENT_PACK.md. DREI DINGE SIND HIER ANDERS ALS BEI DEN BEIDEN AELTEREN PACKS, und alle drei sind gemessen (CR-2026-133, D-346 bis D-348): (1) Die Berechtigungsschicht zerfaellt in ZWEI Traeger - Pfade in der Konfigurationsdatei (TOML, permissions_format), Befehle in einer eigenen Regeldatei (exec_policy_file). Es gibt hier keine Koerbe aus Werkzeug(Muster)-Zeilen, und deshalb auch kein permission_tools. (2) Die gesamte projektlokale Schicht - Konfiguration, Hooks und Befehlsregeln - laedt NUR, wenn das Projekt in der Benutzerkonfiguration des Clients als vertraut eingetragen ist; Skills laden auch ohne. (3) Die Sperrform des Schutz-Hooks ist eine andere: Die bisherige Form blockiert bei diesem Client NICHTS, gemessen mit Gegenlauf. hook_block_form sagt die Form, die er liest.",
+  "client": "openai-codex",
+  "runtime_dir": ".codex",
+  "root_instruction_file": "AGENTS.md",
+  "permissions_file": ".codex/config.toml",
+  "permissions_format": "toml",
+  "_permissions_format_note": "Die Ausgabeform der Berechtigungsdatei. Der Standard ist 'json'; ein Pack, das eine andere Form braucht, SAGT sie und erbt sie nicht durch Schweigen. Pruefung 87 fuehrt die Pruefungen auf, die an die Form 'json' gebunden sind und dieses Pack deshalb nicht erreichen - eine erklaerte Luecke statt einer stillen.",
+  "exec_policy_file": ".codex/rules/koolie.rules",
+  "_exec_policy_file_note": "Die zweite Haelfte der Berechtigungsschicht. Gemessen am 2026-09-23: Der Client laedt Regeldateien mit der Endung .rules aus <Projekt>/.codex/rules/ und aus dem Benutzerverzeichnis des Clients; ein Befehl, den diese Datei verbietet, wird abgewiesen, und der Client nennt die Begruendung dieser Datei woertlich. Sie liegt projektlokal und ist damit versioniert - das ist die Haelfte von B1, die dieser Client traegt.",
+  "skills_dir": ".codex/skills",
+  "agents_dir": ".codex/agents",
+  "pack_runtime_dir": ".codex/rules",
+  "has_rule_triggers": false,
+  "core_skill_prefix": "fw-",
+  "core_paths": [
+    ".codex/README.md"
+  ],
+  "seed_paths": [],
+  "project_owned_hint": [
+    ".codex/rules/2N-overlay-<name>.md        (Overlay-Regelerweiterungen)",
+    ".codex/rules/40-tech-<name>.md           (Packs ohne Quelle im Kern)",
+    ".codex/config.toml                       (Projektwerte, MCP-Server, eigene Schluessel)",
+    ".codex/skills/prj-*/                     (projektspezifische Skills)",
+    ".koolie/project-overlay/tech-packs/**            (projekteigene Packs)",
+    ".koolie/project-overlay/**                       (das gesamte Overlay)"
+  ],
+  "_post_steps_note": "Schritte, die install.py nach einer Installation (post_install_steps) und nach einer Hebung (post_update_steps) zusaetzlich nennt, weil ohne sie ein Teil des Packs nicht traegt - hier die Vertrauensbedingung aus CLIENT_PACK.md Abschnitt 1b. Beides liegt ausserhalb des Repositoriums; das Werkzeug kann es nennen, nicht setzen (K-123, D-395).",
+  "post_install_steps": [
+    "Das Projekt in der Benutzerkonfiguration des Clients als vertraut eintragen - ohne den Eintrag laden Konfiguration, Hooks und Befehlsregeln nicht (CLIENT_PACK.md Abschnitt 1b).",
+    "Dem Schutz-Hook einzeln vertrauen - ohne dieses Vertrauen laeuft er nicht, und nichts meldet es (CLIENT_PACK.md Abschnitt 1b)."
+  ],
+  "post_update_steps": [
+    "Dem Schutz-Hook ERNEUT vertrauen: Das Vertrauen haengt an einem Hash, und eine Hebung aendert den Hook. Ohne neues Vertrauen laeuft das Projekt ab jetzt ohne Schutz-Hook, und nichts meldet es (CLIENT_PACK.md Abschnitt 1b)."
+  ],
+  "runtime_placeholders": {
+    "<RUNTIME_DIR>": ".codex",
+    "<ROOT_INSTRUCTION_FILE>": "AGENTS.md",
+    "<ROOT_INSTRUCTION_LOCAL>": "AGENTS.override.md",
+    "<PERMISSIONS_FILE>": ".codex/config.toml",
+    "<SKILLS_DIR>": ".codex/skills",
+    "<RULES_DIR>": ".codex/rules",
+    "<AGENTS_DIR>": ".codex/agents",
+    "<HOOKS_FILE>": ".codex/hooks.json",
+    "<MCP_FILE>": ".codex/config.toml",
+    "<CLIENT_NAME>": "OpenAI Codex CLI"
+  },
+  "_runtime_placeholders_note": "<ROOT_INSTRUCTION_LOCAL> ist bei diesem Client KEINE Ergaenzung, sondern eine VERDRAENGUNG: Liegt AGENTS.override.md im Projekt, steht die Wurzel-Anweisung des Frameworks in KEINER Nachricht der Sitzung - gemessen mit Gegenprobe am 2026-09-23. Deshalb liefert dieses Pack fuer sie KEINE Beispieldatei aus (shared_core fuehrt sie nicht), waehrend der deny-Korb des Kerns sie schreibgeschuetzt stellt, und deshalb meldet Pruefung 88 ihr Vorhandensein im Projektbaum (bis 1.4.1 stand hier 86 - die Pruefung auf die Sperrform des Hooks). <MCP_FILE> zeigt auf dieselbe Datei wie <PERMISSIONS_FILE>: Dieser Client fuehrt MCP-Server als Tabelle seiner Konfiguration und liest keine eigene MCP-Datei (gemessen: .mcp.json bleibt unbeachtet).",
+  "root_instruction_override": true,
+  "_root_instruction_override_note": "Dieser Client kennt eine Datei, die die Wurzel-Anweisung nicht ergaenzt, sondern ERSETZT - gemessen mit Gegenprobe am 2026-09-23. Das Feld sagt es ausdruecklich, und Pruefung 88 meldet die Datei, wenn sie im Projekt liegt.",
+  "permission_profile_name": "koolie",
+  "permission_profile_description": "Rechteprofil des Koolie-Frameworks: Lesen ueberall, Schreiben nur im Arbeitsbereich, und die Traeger des Frameworks und des Overlays nur lesend.",
+  "permission_path_special": ":workspace_roots",
+  "_permission_path_special_note": "Seit Clientversion 0.157 heisst das Sonderziel des Arbeitsbereichs :workspace_roots und fuehrt seine Unterpfade als eigene Tabelle (\".\" = der Arbeitsbereich selbst). Die bis 1.12.0 ausgelieferte Form :workspace/<pfad> meldet 0.157 als unbekannt und ignoriert sie; gemessen am 2026-09-26 mit codex sandbox ohne Modellaufruf: mit der alten Form ist der GANZE Arbeitsbereich schreibgeschuetzt, mit der neuen ist er schreibbar, und .koolie/core, .codex und AGENTS.md bleiben schreibgeschuetzt (K-157, D-412).",
+  "permission_path_base": {
+    ":root": "read",
+    ":workspace_roots": "write"
+  },
+  "_permission_path_base_note": "Der Grundstock jedes Profils, und er ist nicht Kosmetik. Gemessen am 2026-09-23: Ein aktives Rechteprofil OHNE ':root = read' erzeugt eine geteilte Leseeinschraenkung, und der unerhoehte Windows-Sandkasten kann sie nicht durchsetzen - der Client BRICHT DANN AB, statt ungesandboxt zu laufen (fail-closed, und damit richtig). Mit dieser Grundlage laeuft er, und ein Schreibverbot auf einem Teilbaum ist ausdrueckbar: Der Teilbaum bekommt 'read'.",
+  "permission_tools": {
+    "read": [],
+    "search": [],
+    "write": [],
+    "exec": [],
+    "fetch": [],
+    "mcp": [],
+    "skill": []
+  },
+  "_permission_tools_note": "ALLE LEER, UND DAS IST DIE AUSSAGE ueber den Mechanismus, nicht ueber den Belegstand (D-155, D-238). Die Berechtigungsschicht dieses Clients kennt KEINE Werkzeugnamen: Sie bindet Pfade an eine Zugriffsart und Befehle an Praefixmuster - gemessen am 2026-09-23, samt der Fehlermeldung, mit der sie einen Schluessel abweist, der kein Pfad ist. Eine Regel der Gestalt Werkzeug(Muster) hat hier keinen Ort. Was die Koerbe des Kerns traegt, steht in permission_path_base und permission_profile_name (Pfadseite) und in exec_policy_file (Befehlsseite). Weil damit zwoelf Pruefungen ins Leere liefen, fuehrt der Validator seit 1.4.0 FORMATGEBUNDENE_PRUEFUNGEN, und Pruefung 87 haelt die Liste gegen Abschnitt 5 dieses Packs.",
+  "permission_tools_bare": [],
+  "permission_path_prefix": "",
+  "permission_exec_match": "prefix",
+  "permission_exec_suffix": "",
+  "_permission_exec_note": "Die Befehlsseite wirkt praefixbasiert - gemessen am 2026-09-23 mit dem Auswerter des Clients selbst: prefix_rule(pattern = [\"git\", \"push\"]) trifft 'git push origin main' und trifft 'git -C . push' NICHT. Das ist dieselbe Breite und dieselbe benannte Grenze wie beim Pack claude-code. Ein Praefixzeichen gibt es hier nicht; die Regelsprache zaehlt Tokens.",
+  "hook_handler_extra": {
+    "enabled": true
+  },
+  "_hook_handler_extra_note": "Gemessen am 2026-09-23: Ein Hook-Eintrag ohne 'enabled': true laeuft nicht, und der Client meldet es nicht. Das Feld ist damit die Bedingung dafuer, dass der Schutz-Hook ueberhaupt aufgerufen wird.",
+  "hooks_file_wrapper": "hooks",
+  "_hooks_file_wrapper_note": "Die Hook-Datei dieses Clients fuehrt die Ereignisse unter einem Schluessel der obersten Ebene. Gemessen am 2026-09-23: Ohne ihn meldet der Client 'unknown field `PreToolUse`' und LAEDT DIE DATEI NICHT - er startet trotzdem. Ein ausgelieferter Schutz-Hook, der nie laeuft, ist genau die Lage von AP2-DD-10.",
+  "hook_block_form": "hook-specific-output",
+  "_hook_block_form_note": "DER SCHWERSTE BEFUND DIESES PACKS (D-347). Die bisherige Sperrform des Schutz-Hooks - {\"decision\": \"block\"} und Exit 2 - blockiert bei diesem Client NICHTS: Gemessen am 2026-09-23 mit Gegenlauf, der Client meldet 'PreToolUse Failed' und FUEHRT DIE OPERATION AUS; der Koederinhalt kam woertlich heraus. Dieselbe Sperre als hookSpecificOutput.permissionDecision = 'deny' blockiert - und zwar AUCH in dem Modus, der Rueckfragen und Sandkasten abschaltet. Die Abbildung haengt die Form als --sperrform an das Hook-Kommando, aus demselben Grund wie --fail-closed (D-31). Pruefung 86 haelt fest, dass das Skript die genannte Form kennt.",
+  "hook_tools": {
+    "read": [],
+    "search": [],
+    "exec": [
+      "Bash"
+    ],
+    "write": [
+      "apply_patch"
+    ]
+  },
+  "hook_tools_unerhoben": ["mcp"],
+  "_hook_tools_unerhoben_note": "Das Verb mcp der Kernquelle (seit 1.20.0, K-184, D-486) ist fuer diesen Client NICHT gemessen: Weder der Werkzeugname eines MCP-Aufrufs in der Hook-Eingabe noch das Ereignis, das ihn traegt, sind an einer Installation aufgezeichnet. Ein Matcher auf eine ungemessene Form waere eine Zusage ohne Mechanismus (D-78); das Verb steht deshalb hier und nicht unter hook_tools_absent. Bis zu einer Messung fragt jeder MCP-Aufruf den Menschen, wo die Berechtigungsschicht es verlangt (D-459); der Inhalt wird vom Schutz-Hook nicht geprueft.",
+  "hook_tools_absent": [
+    "read",
+    "search"
+  ],
+  "_hook_tools_absent_note": "Dieser Client fuehrt KEIN eigenes Lese- und kein eigenes Suchwerkzeug - Lesen und Suchen laufen ueber die Shell und damit unter dem Werkzeugnamen des Ausfuehrungsverbs. Gemessen am 2026-09-23 an einer realen Installation: Ein Matcher 'Read' und ein Matcher 'Grep' loesen in keinem Lauf aus, waehrend 'Bash' bei jedem Lesezugriff ausloest, den das Modell ueber die Shell faehrt. Die Abwesenheit ist damit erhoben und nicht angenommen; der Kanal ist ueber 'exec' gedeckt und nicht offen. GEMESSEN IST AUSSERDEM EINE ALIASBILDUNG: Die Matcher 'Edit' und 'Write' treffen dasselbe Werkzeug wie 'apply_patch'. Sie stehen hier trotzdem NICHT, weil der Hook sonst je Schreibaufruf dreimal liefe - dieselbe Sperre dreimal ist keine dreifache Sperre. Erhebungsstand 2026-09-23, tests/protocols/2026-09-23-bau-openai-codex.md; was hier fehlt, ist unerhoben.",
+  "hook_project_dir_expr": ".",
+  "_hook_project_dir_expr_note": "DIESER CLIENT SAGT SEIN PROJEKTVERZEICHNIS NICHT, ER STEHT DARIN. Gemessen am 2026-09-23 an einer realen Installation: Die Umgebung des Hook-Prozesses fuehrt ausser dem Verweis auf ihr eigenes Benutzerverzeichnis keine Variable des Clients - kein Projektverzeichnis, keine Sitzungsangabe -, und sein ARBEITSVERZEICHNIS ist das Projektverzeichnis. Das Kommando bindet deshalb den relativen Punkt und keine Variable. Eine Variable, die es nicht gibt, haette hier ein Kommando erzeugt, das startet und nichts findet - der Befundtyp, der bei AP2-DD-10 acht Releases lang wirkungslose Hooks getragen hat.",
+  "hook_fail_closed": false,
+  "_hook_fail_closed_note": "Das Eingabeschema dieses Clients ist am 2026-09-23 an einer realen Installation AUFGEZEICHNET - PreToolUse fuehrt session_id, turn_id, transcript_path, cwd, hook_event_name, model, permission_mode, tool_name, tool_input und tool_use_id -, aber der VOLLSTAENDIGE Bestand der Ereignisse und ihrer Umschlaege ist es nicht. Fail-closed bei einem nur teilweise erhobenen Schema waere keine Haertung, sondern eine Sitzung, die bei der ersten unbekannten Eingabeform blockiert (D-31). Der Wert geht auf true, sobald der Bestand erhoben ist; die Zeile H4 des Packs fuehrt die Bedingung.",
+  "skill_frontmatter": {
+    "tools_format": "list",
+    "tool_names": {},
+    "_tool_names_note": "LEER, UND DAS IST DIE AUSSAGE: Kein Verb ist abgebildet, alle fuenf stehen in tool_names_unmapped. Die Abbildung waere geraten - der Bestand der Frontmatter-Felder dieses Clients ist unerhoben (2026-09-23, tests/protocols/2026-09-23-bau-openai-codex.md).",
+    "tool_names_unmapped": [
+      "read",
+      "grep",
+      "glob",
+      "edit",
+      "exec"
+    ],
+    "_tool_names_unmapped_note": "Dieses Pack bildet die Werkzeugverben des Frontmatters NICHT ab, und das ist eine Aussage ueber den Belegstand (Bauform wie hook_tools_absent nach D-47, D-78). Gemessen am 2026-09-23 ist, dass dieser Client Skills aus zwei projektlokalen Ablagen laedt und sie samt Herkunft in den Sitzungskontext stellt. NICHT gemessen ist, ob und wie ein Frontmatter-Feld den Werkzeugbestand eines Skills oder eines Unteragenten begrenzt, und unbekannte Frontmatter-Felder meldet dieser Client nicht. Eine Abbildung ohne Messung waere eine Zusage ohne Mechanismus; die Quellform bleibt deshalb unveraendert stehen, und die Zeilen S3 und A1 des Packs sagen, was das wert ist. Erhebungsstand 2026-09-23, tests/protocols/2026-09-23-bau-openai-codex.md; was hier fehlt, ist unerhoben.",
+    "drop_fields": [],
+    "_drop_fields_note": "LEER, UND DAS IST DIE ENTSCHEIDUNG (Bauform wie devin-desktop). Die zusagentragenden Felder 'permissions' und 'triggers' erreichen die installierte Fassung unveraendert. Sie zu verwerfen haette nach D-50 einen benannten Ersatz verlangt - und einen Ersatz zu benennen, dessen Feld bei diesem Client unerhoben ist, waere eine geratene Zusage. Ein Feld, das der Client nicht kennt, bleibt wirkungslos; ein Feld, das er kennt und das wir verworfen haetten, waere ein Verlust."
+  },
+  "shared_core": [
+    {
+      "src": "framework/runtime/root-instruction.md",
+      "dst": "<ROOT_INSTRUCTION_FILE>"
+    },
+    {
+      "src": "framework/runtime/rules/00-framework-core.md",
+      "dst": "<RULES_DIR>/00-framework-core.md"
+    },
+    {
+      "src": "framework/runtime/rules/10-privacy-security.md",
+      "dst": "<RULES_DIR>/10-privacy-security.md"
+    },
+    {
+      "src": "framework/runtime/rules/15-development-rules.md",
+      "dst": "<RULES_DIR>/15-development-rules.md"
+    },
+    {
+      "src": "framework/runtime/agents/fw-reviewer.md",
+      "dst": "<AGENTS_DIR>/fw-reviewer.md"
+    },
+    {
+      "src": "templates/rules/21-overlay-TEMPLATE.md.template",
+      "dst": "<RULES_DIR>/21-overlay-TEMPLATE.md.template"
+    },
+    {
+      "src": "templates/rules/40-tech-TEMPLATE.md.template",
+      "dst": "<RULES_DIR>/40-tech-TEMPLATE.md.template"
+    },
+    {
+      "src": "framework/runtime/hooks.json",
+      "dst": "<HOOKS_FILE>"
+    },
+    {
+      "src": "framework/runtime/permissions.json",
+      "dst": ".codex/rules/koolie.rules"
+    }
+  ],
+  "_shared_core_note": "ZWEI ABWEICHUNGEN GEGENUEBER DEN AELTEREN PACKS, beide mit gemessenem Grund. (1) Die Beispieldatei zur nutzerlokalen Wurzel-Anweisung wird NICHT ausgeliefert: Bei diesem Client verdraengt AGENTS.override.md die Wurzel-Anweisung vollstaendig, und eine Vorlage, die zum Anlegen dieser Datei auffordert, waere eine Anleitung zum lautlosen Abschalten der Ebene 1. (2) Die MCP-Beispieldatei wird nicht ausgeliefert: Dieser Client liest keine eigene MCP-Datei, sondern eine Tabelle seiner Konfiguration (gemessen). Dafuer steht hier die Befehlsregeldatei - dieselbe Kernquelle wie die Berechtigungsdatei, ein anderes Ziel; sie traegt keine Projektwerte und wird deshalb bei jedem --update neu geschrieben.",
+  "shared_seed": [
+    {
+      "src": "framework/runtime/permissions.json",
+      "dst": "<PERMISSIONS_FILE>"
+    },
+    {
+      "src": "framework/runtime/rules/20-project-overlay.md",
+      "dst": "<RULES_DIR>/20-project-overlay.md"
+    },
+    {
+      "src": "templates/project-overlay",
+      "dst": ".koolie/project-overlay"
+    }
+  ],
+  "rule_frontmatter": "comment",
+  "_rule_triggers_note": "KEIN rule_triggers, UND DAS IST EINE AUSSAGE (D-348). Gemessen am 2026-09-23 mit drei Sonden: Dieser Client kennt keine Regeldateien mit Ladebedingungen. Was ungefragt laedt, ist genau die Wurzel-Anweisungsdatei des Projekts (und eine gleichnamige im Benutzerverzeichnis des Clients); eine Anweisungsdatei in einem Unterverzeichnis steht NICHT vorab im Kontext, und eine Einbindung mit '@' bleibt wirkungslos. Der Geltungsbereich ist der Verzeichnisbaum, nicht ein Muster. Der Ersatz ist benannt und wird geliefert: root_instruction_imports nennt die Regeldateien in der Wurzel-Anweisung, mit der Auflage, sie zu Beginn der Sitzung zu lesen. Damit sind R2 und R3 bei diesem Pack [NICHT ABBILDBAR], mit benanntem Ersatz - kein Ladetrigger wird ersatzlos verworfen (D-26, D-27), aber der Ersatz ist schwaecher, und die Zeilen R2 und R3 sagen es.",
+  "root_instruction_imports": [
+    "- `<RULES_DIR>/00-framework-core.md` (Ebene 3, Rahmenregeln)",
+    "- `<RULES_DIR>/10-privacy-security.md` (Ebene 3, Datenschutz und Sicherheit)",
+    "- `<RULES_DIR>/15-development-rules.md` (Ebene 3, Entwicklungsregeln)",
+    "- `<RULES_DIR>/20-project-overlay.md` (Ebene 4, Project Overlay)",
+    "- `<RULES_DIR>/30-*.md` (Ebene 6, Role Packs) und `<RULES_DIR>/40-*.md` (Ebene 5, Technology Packs), soweit vorhanden"
+  ],
+  "root_instruction_imports_intro": "Dein Client laedt von sich aus nur diese Datei. Die folgenden Regeldateien sind Bestandteil dieser Anweisung und **zu Beginn der Sitzung zu lesen**, bevor du die erste Aufgabe bearbeitest; sie gelten wie der Text dieser Datei:",
+  "agent_frontmatter": {
+    "tools_field": "allowed-tools",
+    "tools_format": "list",
+    "tool_names": {},
+    "_tool_names_note": "LEER, UND DAS IST DIE AUSSAGE: Kein Verb ist abgebildet, alle fuenf stehen in tool_names_unmapped. Die Abbildung waere geraten - der Bestand der Frontmatter-Felder dieses Clients ist unerhoben (2026-09-23, tests/protocols/2026-09-23-bau-openai-codex.md).",
+    "tool_names_unmapped": [
+      "read",
+      "grep",
+      "glob",
+      "edit",
+      "exec"
+    ],
+    "_tool_names_unmapped_note": "Dieses Pack bildet die Werkzeugverben des Frontmatters NICHT ab, und das ist eine Aussage ueber den Belegstand (Bauform wie hook_tools_absent nach D-47, D-78). Gemessen am 2026-09-23 ist, dass dieser Client Skills aus zwei projektlokalen Ablagen laedt und sie samt Herkunft in den Sitzungskontext stellt. NICHT gemessen ist, ob und wie ein Frontmatter-Feld den Werkzeugbestand eines Skills oder eines Unteragenten begrenzt, und unbekannte Frontmatter-Felder meldet dieser Client nicht. Eine Abbildung ohne Messung waere eine Zusage ohne Mechanismus; die Quellform bleibt deshalb unveraendert stehen, und die Zeilen S3 und A1 des Packs sagen, was das wert ist. Erhebungsstand 2026-09-23, tests/protocols/2026-09-23-bau-openai-codex.md; was hier fehlt, ist unerhoben.",
+    "_agent_role_note": "Das Agentenprofil des Frameworks wird als Markdown unter <AGENTS_DIR> abgelegt. Die Rollendatei, die dieser Client liest, ist eine TOML-Datei mit den Pflichtfeldern name, description und developer_instructions - gemessen am 2026-09-23, samt der Meldung, die ein fehlendes Pflichtfeld erzeugt. Die Abbildung darauf ist NICHT gebaut, weil die Wirkung unerhoben ist; Zeile A1 des Packs fuehrt sie als [NICHT ABBILDBAR] mit benanntem Ersatz."
+  },
+  "agent_start_tools": [],
+  "agent_start_tools_absent": [
+    "unerhoben"
+  ],
+  "_agent_start_tools_absent_note": "Dieser Client startet Unteragenten - der Prompt-Eingang fuehrt am 2026-09-23 die Werkzeuge spawn_agent, followup_task, send_message, wait_agent, interrupt_agent und list_agents in einer eigenen Nachricht auf. NICHT gemessen ist, unter welchem Namen ein solcher Start durch den Schutz-Hook laeuft und ob die Werkzeugaufrufe des Unteragenten den Hook erreichen. Die Namen stehen deshalb NICHT in agent_start_tools: Eine Abbildung ohne Messung waere dieselbe Lage, aus der AP2-CC-13 kam. Pruefung 34 laesst ein Pack mit dieser Erklaerung nur durch, solange Zeile A1 nicht [TECHNISCH] sagt - sie sagt es nicht. Erhebungsstand 2026-09-23, tests/protocols/2026-09-23-bau-openai-codex.md; was hier fehlt, ist unerhoben.",
+  "hook_path_fields": [
+    "file_path",
+    "path",
+    "command"
+  ],
+  "_hook_path_fields_note": "Die Felder von tool_input, die bei diesem Client einen Pfad tragen koennen. Gemessen am 2026-09-23: Das Ausfuehrungswerkzeug fuehrt 'command' mit der vollstaendigen Befehlszeile; das Schreibwerkzeug fuehrt EBENFALLS 'command', und der Pfad steht INNERHALB des Patchtextes ('*** Add File: neu.txt'), nicht in einem eigenen Feld. ➡️ Ein Pfadfeld, das keinen Pfad fuehrt, ist der Grund, warum die Zeile B4 dieses Packs die Musterpruefung ueber den Text und nicht ueber den Feldwert fuehrt. file_path und path stehen vorsorglich; fuer sie ist kein Beleg erhoben."
+}

package/.koolie/core/clients/openai-codex/root-template/.codex/README.md

@@ -0,0 +1,35 @@
+# Laufzeitschicht `.codex/` – was hier liegt und wem es gehört
+
+Diese Ablage ist die **Laufzeitform** des Frameworks für den Client `openai-codex`. Die kanonische, werkzeugneutrale Langform steht in `.koolie/core/framework/`; was hier liegt, ist daraus erzeugt (D-02). **Inhaltliche Änderungen gehören in den Kern und laufen als Änderungsantrag** (`.koolie/core/governance/CHANGE_REQUEST_TEMPLATE.md`).
+
+## Was hier liegt
+
+| Pfad | Inhalt | Wem es gehört |
+|---|---|---|
+| `../AGENTS.md` | Wurzel-Anweisung (Ebene 1). **Sie nennt die Regeldateien unten** – dieser Client lädt sie nicht von sich aus | Framework |
+| `rules/00-*.md`, `rules/10-*.md`, `rules/15-*.md` | Regeltexte des Frameworks (Ebene 3) | Framework |
+| `rules/20-project-overlay.md` | Laufzeitfassung des Project Overlays (Ebene 4) | Projekt |
+| `rules/40-tech-*.md`, `rules/30-*.md` | Technology und Role Packs (Ebenen 5 und 6) | Projekt |
+| `rules/koolie.rules` | **Befehlsregeln** – die Befehlsseite der Berechtigungsschicht | Framework |
+| `config.toml` | **Rechteprofil** – die Pfadseite der Berechtigungsschicht, dazu die Projektwerte | Projekt (aus dem Kern erzeugt) |
+| `hooks.json` | Schutz-Hook und Statusmeldung | Framework |
+| `skills/fw-*/` | Skills des Frameworks | Framework |
+| `agents/` | Agentenprofile | Framework |
+
+## Drei Dinge, die bei diesem Client anders sind
+
+**1. Die Regeldateien wirken über ihre Nennung, nicht über einen Ladetrigger.** Dieser Client lädt von sich aus **nur** `AGENTS.md`. Eine Regeldatei in diesem Verzeichnis wirkt, weil die Wurzel-Anweisung sie nennt und zu lesen aufgibt – nicht, weil die Engine sie einspeist. *Was eine Nennung bewirkt, hängt am Modell.*
+
+**2. Ohne Vertrauenseintrag trägt diese Ablage nichts.** `config.toml`, `hooks.json` und `rules/*.rules` laden erst, wenn das Projekt in der **Benutzerkonfiguration des Clients** als vertraut eingetragen ist; der Schutz-Hook braucht darüber hinaus sein **eigenes** Vertrauen. Beides liegt außerhalb dieses Repositoriums und ist je Arbeitsplatz zu setzen. **Jede Hebung des Frameworks ändert den Hook – und damit sein Vertrauen.**
+
+**3. Eine Datei namens `AGENTS.override.md` würde die Wurzel-Anweisung vollständig ersetzen.** Nicht ergänzen: ersetzen. Das Framework legt sie nicht an und liefert auch keine Vorlage dafür; `validate-framework.py` meldet sie, wenn sie da ist.
+
+## Was hier **nicht** liegt
+
+Keine Geheimnisse, keine Zugangsdaten, keine Kunden- oder Personennamen. Die Regeln dazu stehen in `rules/10-privacy-security.md`; der Validator prüft es, und der Schutz-Hook blockiert eine Werkzeugeingabe, die ein Muster dieser Kategorien trägt.
+
+## Prüfen
+
+```text
+python .koolie/core/tests/scripts/validate-framework.py --strict-overlay
+```