@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-133-bau-openai-codex.md

@@ -0,0 +1,97 @@
+# Änderungsantrag `CR-2026-133`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Bau des Client Packs `openai-codex` – und der Schutz-Hook, der lief und nichts verhinderte |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-23 |
+| Betroffene Artefakte | `.koolie/core/clients/openai-codex/**` (neu); `.koolie/core/clientmap.py`; `.koolie/core/install.py`; `.koolie/core/tests/scripts/hook-check-secrets.py`; `.koolie/core/tests/scripts/validate-framework.py` (**Prüfungen 86, 87, 88**); `.koolie/core/tests/scripts/probe-pruefungen.py`; `.koolie/core/clients/README.md`; `.koolie/core/OWNERS.md`; `.koolie/core/docs/ROADMAP.md`; `.koolie/core/governance/DECISION_LOG.md` (**D-346** bis **D-349**, `K-117` beantwortet, `K-118`, `K-119`); `.koolie/core/tests/TEST_CATALOG.md`; `.koolie/core/build/doc/00-kopf.md`, `.koolie/core/build/doc/26-qs-test.md`; `.koolie/core/VERSION`; `.koolie/core/CHANGELOG.md`; `.koolie/core/governance/ADOPTION_REGISTRY.md`; `UEBERGABE.md` |
+| Ebene laut Entscheidungsbaum 6 | Abbildungsschicht und Prüfapparat |
+| Art | **Änderung.** MINOR-Release nach `RELEASE_PROCESS.md` Abschnitt 1 – ein neues Modul und drei neue Prüfungen, **ohne Overlay-Bruch**: Kein Träger des Overlays ändert seine Gestalt |
+| Dringlichkeit | regulär – der Posten steht seit dem 2026-09-12 im Plan und ist mit `1.3.0` auf diese Nummer gerückt (D-341) |
+| Status | 🟢 **entschieden am 2026-09-23** (E1 bis E5) |
+
+---
+
+## 1. Anlass
+
+**Der Bau des dritten Client Packs.** Die Erhebung ist mit `1.3.0` gefahren (`CR-2026-132`), und sie hat fünf Fragen hinterlassen, die vor dem ersten geschriebenen Trägerbyte stehen (Abschnitt 7 des dortigen Protokolls). Dieses Release beantwortet sie – **und hat dabei drei Befunde erzeugt, die in keiner der fünf standen.**
+
+🔴 **Der schwerste davon ist keiner des Packs, sondern des Kerns:** Der ausgelieferte Schutz-Hook lief bei diesem Client, gab seine Sperre aus und **verhinderte nichts.**
+
+## 2. Der Vorbedingungsdurchgang
+
+| # | Befund | gemessen an |
+|---|---|---|
+| **V1** | 🟢 Die Tabelle *Nächste freie Kennungen* stimmt – **zum dritten Mal in Folge** | 345 `D`-Registerzeilen bis `D-345`, 115 `K`-Zeilen bis `K-117` (Lücken 95 und 99), 132 Anträge bis `CR-2026-132`, 20 `G`-Zeilen bis `G-20`, `UEB-31`; alle fünf Gattungen nachgezählt, nicht gelistet (D-345) |
+| **V2** | 🟢 Die geprüfte Clientversion ist **vor** dem Bauen festgeschrieben: `0.156.1`, unverändert seit der Erhebung | `codex --version`, `codex doctor` |
+| **V3** | 🟢 **Die Word-Fassung steht auf `v1.3.0`** – Schritt 3 von Abschnitt 4.1 hat bei `1.3.0` gehalten. **Gezählt, nicht gelistet** (D-345): 16 Einträge in `build/out/`, beide Fassungen darunter | `ls … \| wc -l`, dann vollständig gelesen |
+| **V4** | 🟢 Bestandsliste in allen drei Trägern byte-gleich auf `1.3.0`; **beide** Projekte tragen die Hebung als Commit (`e35b8fc`, `5d7de8d`) | `cmp`, `git log` |
+| **V5** | 🟢 Validator `0 Fehler, 0 Warnungen` über **85** Prüfungen; Arbeitsbaum sauber, kein offener Antrag, kein Restbranch | `validate-framework.py`, `git` |
+| **V6** | 🔴 **`K-117` besteht fort und ist erneut gemessen: 38 von 525 Kerndateien in `devpacks/otp-generator` sind nicht versioniert** (zuvor 42) | `find` gegen `git ls-files` |
+| **V7** | ⚠️ Die Benutzerkonfiguration des Clients führt weiter den Vertrauenseintrag auf den **alten** Projektnamen – **und einen auf das Benutzerprofil selbst** | gelesen; unverändert seit `1.3.0` |
+
+🔴 **Keine Prüfung erreicht V7**, und sie kann es auch nicht: Der Träger liegt außerhalb des Repositoriums (`K-118`).
+
+## 3. Die Erhebung des Baus – dreißig Messungen, davon sechsundzwanzig kostenfrei
+
+**Vier Meßmittel, drei davon ohne Kontingent:** `codex debug prompt-input` (der Kontext, ohne eine Anfrage zu stellen), `codex doctor --all` (das wirksame Profil und jeder unbekannte Konfigurationsschlüssel **mit Namen**), `codex execpolicy check` (der Regelauswerter der Engine selbst) – und **25 Sitzungsläufe** an einer realen Installation für das, was nur ein Lauf zeigt.
+
+🔴 **Die Isolation war wieder Bedingung, nicht Vorsicht:** Alle Messungen liefen gegen ein eigenes Benutzerverzeichnis im Ablagebereich; die Konfiguration des Arbeitsplatzes ist nicht angefaßt worden.
+
+Die dreißig Befunde stehen im Protokoll (`tests/protocols/2026-09-23-bau-openai-codex.md`). **Drei davon haben den Bau geändert:**
+
+| # | Befund | Folge |
+|---|---|---|
+| **M22** | 🔴 **Die Sperrform des Schutz-Hooks ist clientgebunden – und die ausgelieferte wirkt hier nicht.** `{"decision": "block"}` und Exit 2: Der Client meldet *PreToolUse Failed* und **führt die Operation aus**; Gegenlauf mit Köderinhalt. `hookSpecificOutput.permissionDecision = "deny"` blockiert, auch im Modus ohne Rückfragen und ohne Sandkasten | **D-347**, `--sperrform`, **Prüfung 86** |
+| **M21/B4** | 🔴 **Das Schreibwerkzeug führt keinen Pfad in einem Feld**, sondern einen **Patchtext** – der Pfad steht darin hinter einem Leerzeichen, und die Pfadmuster des Hooks kannten als Grenze nur den Schrägstrich. Die Datei im Kernverzeichnis wurde angelegt | **D-347**, erweiterte Grenze, **Verschärfung für alle drei Packs** |
+| **M9/M11** | 🔴 **`B3` fällt an zwei Enden zugleich:** Ein Muster verlangt einen absoluten Vorsatz (nicht versionierbar), ein projektrelativer Schlüssel nimmt kein Muster – **und** ein `deny`-Leserecht verlangt den erhöhten Windows-Sandkasten, ohne den der Client gar nicht läuft | **D-346**, `[NICHT ABBILDBAR]`, Abschnitt 4 des Packs |
+
+## 4. Die fünf Fragen aus `1.3.0` – beantwortet
+
+| # | Frage (Protokoll `1.3.0`, Abschnitt 7) | Antwort |
+|---|---|---|
+| **1** | Zweite Ausgabeform für `clientmap.py`? | 🟢 **Ja, und es sind zwei Erzeugnisse:** `render_permissions_toml()` für die Pfadseite, `render_exec_policy()` für die Befehlsseite. **Das Ziel entscheidet über die Abbildung**, nicht mehr die Quelle allein (D-346) |
+| **2** | Wie steht das Vertrauensmodell im B-Block? | 🟢 **Als zweite Vorbemerkung des Blocks** – es betrifft die ganze projektlokale Schicht, nicht einzelne Zeilen – **und als Bedingung in `B1`, `H1` und `H2`.** Dazu ein eigener Abschnitt 1b des Packs und ein Schritt in `install.py` |
+| **3** | Wie steht die verdrängbare Wurzel-Anweisung in `R1`? | 🟢 **`[TECHNISCH]` mit benannter Bedingung**, dazu **drei** Maßnahmen: Schreibschutz im `deny`-Korb, Aufnahme in die Muster des Schutz-Hooks und **Prüfung 88**, die die Datei meldet |
+| **4** | Abbildung der Ladetrigger, wenn es keine gibt? | 🟢 **`rule_frontmatter: "comment"` und `root_instruction_imports`** – zwei Mechaniken aus 0.15.0 bekommen ihren ersten Gegenstand. Kein Trigger wird ersatzlos verworfen (D-26, D-27); der Ersatz ist die **Nennung**, und er ist schwächer (D-348) |
+| **5** | Eine oder beide Skillablagen? | 🟢 **Beide werden genannt, eine wird geschrieben.** Das Framework schreibt `.codex/skills/`; `.agents/skills/` steht in der Pfadabbildung und in Abschnitt 7 als Auskunft nach D-34 |
+
+## 5. Vorlage zur Entscheidung
+
+| # | Frage | Auflösung | Preis |
+|---|---|---|---|
+| **E1** | Bekommt `clientmap.py` eine zweite Ausgabeform – und was geschieht mit den Prüfungen, die nur die erste lesen? | 🟢 **Ja, zwei Erzeugnisse aus einer Quelle** – und die betroffenen Prüfungen stehen **benannt** in `FORMATGEBUNDENE_PRUEFUNGEN`; **Prüfung 87** verlangt ihre Nennung in Abschnitt 5 des Packs, in beide Richtungen. Sie still zu überspringen wäre die Bauform von `0.57.0` | ⚠️ **Sechs Prüfungen erreichen dieses Pack nicht** (2, 37, 42, 43, 54, 76). Die Lücke ist erklärt und gezählt, aber sie ist da. ⚠️ **Zweiter Preis:** `install.py` rendert dieselbe Quelle zweimal; wer eine dritte Form baut, faßt `render_for_client` erneut an |
+| **E2** | Was folgt aus der wirkungslosen Sperrform des Schutz-Hooks? | 🔴 **Das Skript kennt zwei Formen, das Pack sagt seine, die Abbildung hängt sie ans Kommando** – dieselbe Begründung wie bei `--fail-closed` (D-31). **Prüfung 86** mißt die **Kette** und nicht das Manifestfeld. **Und die Pfadgrenze des Hooks wird erweitert** – für alle drei Packs, weil es eine Verschärfung ist | ⚠️ **Der Standard bleibt die alte Form.** Ein Pack, das eine neue braucht, muß sie sagen – wer es vergißt, bekommt einen Hook, der nichts sperrt. **Genau das fängt Prüfung 86 nur, wenn das Pack die Form nennt**; ein Pack, das schweigt, läuft durch. ➡️ *Die Grenze ist benannt und sie bleibt* |
+| **E3** | Wie werden Regeldateien abgebildet, wenn der Client keine Ladebedingung kennt? | 🟢 **Über die Nennung in der Wurzel-Anweisung** (`root_instruction_imports`), und die Prüfung darauf verlangt die **Nennung** statt der geratenen `@`-Form | 🔴 **Der Ersatz ist schwächer, und das ist der Preis:** `R2` und `R3` stehen auf `[NICHT ABBILDBAR]` statt auf `[TECHNISCH]`. ⚠️ **Verworfen: die Regeltexte einbetten** – das erzeugte eine zweite Schrift derselben Regel und hätte die Overlay-Laufzeitregel in eine Datei geschrieben, die `--update` überschreibt |
+| **E4** | `K-117` – die drei Fragen | 🟢 **(1) ja, (2) ja, (3) nein.** `install.py` meldet am Ende, welche der geschriebenen Kerndateien das Projekt ignoriert; der Übernahmeleitfaden nennt die Negativregel. Bauform von D-34 | ⚠️ **Eine Auskunft, keine Schranke** – das `.gitignore` gehört dem Projekt. ⚠️ **Ohne Git gibt sie eine leere Liste**; eine Auskunft, die nicht erhoben werden kann, wird nicht behauptet |
+| **E5** | Einstufung | **MINOR.** Ein neues Modul und drei neue Regeln, **kein Overlay-Bruch** – kein Träger des Overlays ändert seine Gestalt | – |
+
+## 6. Umsetzung
+
+1. `clients/openai-codex/`: `CLIENT_PACK.md` (34 Matrixzeilen), `manifest.json`, `root-template/.codex/README.md`.
+2. `clientmap.py`: die zweite Ausgabeform, `hook_block_form`, `hook_handler_extra`, `hook_project_dir_expr`, `hooks_file_wrapper`.
+3. `install.py`: zielabhängige Abbildung; die Schlußmeldung über ignorierte Kerndateien.
+4. `hook-check-secrets.py`: `--sperrform`, erweiterte Pfadgrenze, `.codex/` und `AGENTS.override.md` in den Mustern.
+5. `validate-framework.py`: `FORMATGEBUNDENE_PRUEFUNGEN`, `formatgebunden()`, **Prüfungen 86, 87, 88**; Prüfung 21 mißt die Nennung statt der `@`-Form.
+6. `probe-pruefungen.py`: sechs neue Einheiten, je Prüfung eine Sonde und **zwei** Gegenproben.
+7. `clients/README.md` (0.7.0), `OWNERS.md`, `docs/ROADMAP.md`, `DECISION_LOG.md`, `TEST_CATALOG.md`, `build/doc/00-kopf.md`, `build/doc/26-qs-test.md`, `CHANGELOG.md`, `VERSION`, `ADOPTION_REGISTRY.md`.
+8. Protokoll mit allen dreißig Messungen und ihren Gegenproben.
+9. 🔴 **Der Bau faßt die Konfiguration des Arbeitsplatzes nicht an** – alle Messungen gegen ein eigenes Benutzerverzeichnis im Ablagebereich.
+10. 🔴 **Die Übergabe wird VOR dem Abnahmelauf gehoben** (Falle 1 aus `1.2.0`); nur die Laufzeiten stehen unterhalb der Trennlinie (D-94).
+11. Validator und Sondenlauf in **beiden** Kodierungsumgebungen (D-49).
+12. 🔴 **Nicht gefahren, und ausdrücklich entschieden:** Das Heben der übernehmenden Projekte (Schritt 2) und der Bau der Erzeugnisse (Schritt 3) sind am 2026-09-23 auf Entscheidung des Framework Owners **verschoben** worden. ⚠️ **Der Preis ist benannt:** Die Bestandsliste steht damit für einen Tag auf einer Zahl, die im Projekt noch nicht angekommen ist – die Grenze von D-331. **Beides steht als erster Punkt des Wiederaufnahmepunkts.**
+
+## 7. Entscheidung
+
+🟢 **Angenommen am 2026-09-23, E1 bis E5 wie vorgelegt.**
+
+| # | Entscheidung | Decision Record |
+|---|---|---|
+| E1 | Zwei Ausgabeformen, und die formatgebundenen Prüfungen stehen benannt | **D-346** |
+| E2 | Die Sperrform des Schutz-Hooks ist clientgebunden und wird gesagt | **D-347** |
+| E3 | Regeln über die Nennung; die Prüfung mißt die Nennung statt der `@`-Form | **D-348** |
+| E4 | `install.py` meldet die ignorierten Kerndateien – Auskunft, keine Schranke | **D-349** |
+| E5 | MINOR | – |
+
+Beantwortet: `K-117`. Neue Klärungspunkte: **`K-118`** (kann eine Prüfung den Vertrauenseintrag erreichen?) und **`K-119`** (welche Seite gewinnt zwischen Arbeitsplatz- und Projektregel?).

package/.koolie/core/governance/change-requests/CR-2026-134-uebergabe-lokal.md

@@ -0,0 +1,117 @@
+# Änderungsantrag `CR-2026-134`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Übergabe wird ein lokales Arbeitsdokument – und vier Prüfungen verlieren den Anker, an dem sie das Quellrepositorium erkannten |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-24 |
+| Betroffene Artefakte | `.gitignore`; `UEBERGABE.md` und `UEBERGABE.local.md.example` (aus dem Versionierten genommen); `.koolie/QUELLREPOSITORIUM.md` (**neu**); `tests/scripts/validate-framework.py` (Prüfung 67 entfällt, 78 verliert einen Gegenstand, 75/78/79/81 am Kennzeichen); `tests/scripts/probe-pruefungen.py` (67a–d, 78d/78e entfallen; **81d** und **Gegenprobe 81b** neu; 82b umgestellt); `tests/TEST_CATALOG.md`; `governance/DECISION_LOG.md` (**D-350**, **D-351**; D-214 und D-216 aufgehoben); `governance/FRAMEWORK_DEV_PROFILE.md` (Schritt 7, `0.1.3`); `governance/RELEASE_PROCESS.md` (Abschnitt 4.1, `0.3.1`); `governance/ADOPTION_REGISTRY.md` (`0.2.1`); `docs/ADOPTION_GUIDE.md` (`0.4.5`); `README.md`; `build/doc/00-kopf.md`, `26-qs-test.md`; `VERSION`, `CHANGELOG.md`, `docs/ROADMAP.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Prüfapparat und Änderungsprozess des Quellrepositoriums; dazu eine Korrektur an zwei Übernahmetexten |
+| Art | **Korrektur.** Patch-Release nach `RELEASE_PROCESS.md` Abschnitt 1: kein Overlay-Feld berührt, keine neue Regel, **keine neue Prüfung** – zwei neue Sondeneinheiten an einer bestehenden |
+| Dringlichkeit | Regulär; Anlaß ist eine Entscheidung des Owners, nicht ein Vorfall |
+| Status | 🟢 **entschieden am 2026-09-24** (E1 bis E4), umgesetzt mit `1.4.1` |
+
+---
+
+## 1. Anlaß
+
+**Der Framework Owner hat am 2026-09-24 entschieden, daß die Übergabe nicht mehr
+eingecheckt wird** – sie und ihre Vorlage sollen nur noch lokal vorliegen. Die Begründung
+ist inhaltlich: Die Übergabe ist Arbeitswissen eines Arbeitsplatzes, **kein Bestandteil
+des Frameworks.** Dass Prüfungen an ihr hingen, stand in keinem Träger, den man vor dieser
+Frage liest.
+
+Dazu kommt ein Auftrag, der mit derselben Sitzung kam: **Die Wurzel-README an den Stand
+von `1.4.0` angleichen.**
+
+## 2. Die Gegenprüfung – was am Austragen hängt
+
+**Gemessen, bevor eine Zeile geändert wurde** (`grep` über Validator und Sondenapparat):
+
+| Stelle | Wie sie die Übergabe nutzt | Folge des bloßen Austragens |
+|---|---|---|
+| **Prüfung 67** | prüft Titelzeile, Lagezeilen und Antragsnummern der Übergabe | ihr Gegenstand fehlt in jeder frischen Auscheckung |
+| **Prüfung 78**, Gegenstand 4 | hält die Abnahmezeile der Übergabe gegen das Register | ebenso |
+| **Prüfung 78**, Enthaltung | enthält sich ganz, wenn die Übergabe fehlt | im Klon: enthält sich **leise** |
+| **Prüfung 79** | prüft die Wurzel-Lizenz nur, wenn die Übergabe da ist | im Klon: prüft **leise** nur die Kernfassung |
+| 🔴 **Prüfung 75** | zählt alle verfolgten Träger, wenn die Übergabe **verfolgt** ist, sonst nur das Ausgelieferte | **sofort**, auch hier: prüft **leise** nur noch das Ausgelieferte |
+| 🔴 **Prüfung 81** | ebenso | ebenso |
+
+🔴 **Die letzten beiden Zeilen sind der Befund.** Die Prüfungen 75 und 81 lesen
+`git ls-files`. Nach dem Austragen hätten sie das Quellrepositorium **auf dem
+Arbeitsplatz, der die Datei noch führt**, für ein übernehmendes Projekt gehalten. Keine
+Meldung, keine Warnung: Der Validator wäre grün gelaufen und hätte weniger geprüft.
+➡️ ***Ein Anker, der nur an einem Arbeitsplatz liegt, ist keiner.***
+
+**Gegenbeweis, gemessen:** Eine Kopie des Bestands mit ausgetragener Übergabe (lokal
+vorhanden), `README.md` auf LF gestellt. **Der Validator aus `1.4.0` meldet sie nicht (0
+Treffer), der neue meldet sie (1 Treffer).**
+
+### 2.1 Der zweite Auftrag: drei Aussagen der Wurzel-README, die `1.4.0` überholt hat
+
+| Stelle | Aussage | Stand |
+|---|---|---|
+| Einleitung | *„derzeit `devin-desktop` und `claude-code`"* | 🔴 drei Packs seit `1.4.0` |
+| Hinweis unter dem Baum | *„Eine eigene Hook-Datei gibt es nicht. Bei beiden ausgelieferten Packs …"* | 🔴 `openai-codex` liest Hooks **nur** aus `.codex/hooks.json` |
+| `install.py`-Tabelle und Hinweis | Hook-Konfiguration gehört dem Projekt und wird von `--update` nicht erneuert | 🔴 bei `openai-codex` gehört die Hook-Datei zum **Kern** und wird erneuert – mit Folge für das Hook-Vertrauen |
+| Absatz zu `root-template/` | *„`seed_paths` ist in beiden Manifesten leer"* | ⚠️ in allen **drei** |
+
+🔴 **Und ein Nachbarfund, der schwerer wiegt als alle vier:** Der Kopierbefehl in der
+README und zweimal im Übernahmeleitfaden lautete `cp -r .koolie/core/ /pfad/zum/projekt/`.
+Mit dem Schrägstrich am Quellpfad legt `cp` den **Inhalt** ab: Der Kern landet unter
+`<projekt>/core`, nicht unter `<projekt>/.koolie/core`, und `install.py` findet sich
+danach nicht dort, wo die nächste Zeile es aufruft. **Der erste Befehl der Anleitung
+funktionierte nicht.** Gefunden beim Lesen, nicht durch eine Prüfung.
+
+⚠️ **Zweiter Nachbarfund:** Der Kopf des Hauptdokuments (`build/doc/00-kopf.md`) sagte
+*„Ausgeliefert werden zwei: `devin-desktop` und `claude-code`."* Prüfung 77 hält dort die
+**Version**, nicht den Inhalt – die Grenze, die sie selbst benennt.
+
+⚠️ **Dritter Nachbarfund:** `governance/ADOPTION_REGISTRY.md` führte die
+**Overlay-Versionen** `0.3.3` und `1.1.0`; die Projekte tragen seit `1.3.0` `0.3.5` und
+`1.3.0`. Prüfung 82 hält nur die Spalte `Framework-Version` – *eine Spalte, die niemand
+zählt, ist eine, die niemand veralten sieht.*
+
+---
+
+## 3. Vorlage zur Entscheidung
+
+| # | Frage | Wege und ihre Preise |
+|---|---|---|
+| **E1** | **Wird die Übergabe aus dem Versionierten genommen?** | **Ja, samt Vorlage `UEBERGABE.local.md.example`**, per `git rm --cached`; beide stehen in der `.gitignore`. Beilage und Übergabe bleiben **getrennte** Dateien. ⚠️ **Preis:** Ein zweiter Arbeitsplatz bekommt die Übergabe nicht mehr über `git clone` – genau der Anlaß von D-214. Die Git-Historie trägt die Fassungen bis `1.4.0` |
+| **E2** | **Was wird aus den Prüfungen 67 und 78 (zweiter Gegenstand)?** | **Ersatzlos streichen** (Entscheidung des Owners). Die Nummer 67 bleibt im Register als *entfallen*, weil Prüfung 40 ein lückenloses Register verlangt und eine neu vergebene Nummer jeden alten Verweis falsch machte. **Verworfen: lokal weiterlaufen lassen** – eine Prüfung, deren Gegenstand eine frische Auscheckung nicht führt, läuft nur an einem Arbeitsplatz. ⚠️ **Preis:** Stand und Zahlen der Übergabe prüft niemand mehr |
+| **E3** | **Woran erkennt der Validator künftig das Quellrepositorium?** | **An einer eigenen, versionierten Datei neben dem Kern: `.koolie/QUELLREPOSITORIUM.md`.** Das Heben kopiert nur `.koolie/core/`, `install.py` legt sie nicht an. **Verworfen:** am lokalen Vorhandensein der Übergabe (im Klon prüfte der Validator leise weniger); unter `.koolie/core/` (wanderte in jedes Projekt); eine vorhandene Wurzeldatei wie `README.md` (ein Projekt führt sie auch). **Wirkungsnachweis:** Sonde 81d und Gegenprobe 81b, dazu 82b auf das Kennzeichen umgestellt |
+| **E4** | **Die README-Befunde und die Nachbarfunde** | **Berichtigen, alle.** Kein Befund ändert eine Zusage des Frameworks – sie ändern Beschreibungen, die hinter dem Bestand zurückblieben, und einen Befehl, der nicht lief. **Keine neue Prüfung:** Eine Prüfung auf die Aussagen der README ist `K-104`, und dessen Frage bleibt, wo sie steht |
+
+> **Empfehlung der Vorbereitung:** E1 bis E4 wie vorgelegt. Die Entscheidungen E1 bis E3
+> hat der Owner am 2026-09-24 im Gespräch getroffen, bevor dieser Antrag geschrieben
+> wurde; der Antrag hält sie mit ihren Preisen fest.
+
+---
+
+## 4. Umsetzung
+
+1. `git rm --cached UEBERGABE.md UEBERGABE.local.md.example`; beide in die `.gitignore`.
+2. `.koolie/QUELLREPOSITORIUM.md` angelegt; im Validator `QUELLREPO_KENNZEICHEN` und
+   `ist_quellrepositorium()`, gelesen von 75 und 81 (versionierter Bestand) sowie 78 und
+   79 (Arbeitsbaum).
+3. Prüfung 67 und Gegenstand 4 von Prüfung 78 entfernt; Registereintrag 67 als
+   *entfallen*; im Sondenapparat 67a–67d, Gegenproben 67a/67b sowie 78d/78e entfernt,
+   81d und Gegenprobe 81b neu, 82b auf das Kennzeichen umgestellt. Die Sondenmenge an
+   drei Stellen: *„6, 14, 18 bis 66 und 68 bis 88"*.
+4. Entwicklungsprofil Schritt 7 und `RELEASE_PROCESS.md` Abschnitt 4.1 auf die lokale
+   Übergabe umgeschrieben.
+5. README, Übernahmeleitfaden (zwei Kopierbefehle), Dokumentkopf und Bestandsliste
+   berichtigt.
+6. `VERSION` `1.4.1`, Changelog, Roadmap; beide übernehmenden Projekte auf `1.4.1`
+   gehoben – **zugleich der für `1.4.0` verschobene Schritt 2.**
+
+## 5. Abnahme
+
+Steht im Protokoll `tests/protocols/2026-09-24-uebergabe-lokal.md`.
+
+## 6. Entscheidung
+
+**E1 bis E4 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-24). Decision
+Records **D-350** und **D-351**; D-214 und D-216 sind aufgehoben. Alle vier zählbaren
+Kriterien von D-11 bleiben **0**; kein Overlay-Feld berührt.

package/.koolie/core/governance/change-requests/CR-2026-135-pfadlisten-nul-getrennt.md

@@ -0,0 +1,139 @@
+# Änderungsantrag `CR-2026-135`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Auskunft, die unter Windows nur Verzeichnisse sah – und drei Prüfungen, denen ein Umlaut den Pfad nahm |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-24 |
+| Betroffene Artefakte | `install.py` (`ignorierte_kerndateien()`); `tests/scripts/validate-framework.py` (`_verfolgte_dateien()`, `_p75_verfolgt()`, neu `_git_pfade()`); `tests/scripts/probe-pruefungen.py` (Bündel `sonden_ignorierte_kerndateien` **neu**: Sonde `D349`, Gegenproben `D349a`/`D349b`; **Sonde 81e** neu); `governance/DECISION_LOG.md` (**D-352**, **K-120**, **K-121**); `governance/ADOPTION_REGISTRY.md`; `build/assemble.py` (Direktive `{{LOKALE-ERGAENZUNG}}`, Erzeugnisse des vorigen Baus werden entfernt); `build/doc/16-agentenanweisung.md`; `clients/openai-codex/manifest.json` (Notiz: Prüfung 88 statt 86); `build/doc/00-kopf.md`, `26-qs-test.md`; `VERSION`, `CHANGELOG.md`, `docs/ROADMAP.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Installationswerkzeug und Prüfapparat |
+| Art | **Korrektur.** Patch-Release nach `RELEASE_PROCESS.md` Abschnitt 1: kein Overlay-Feld berührt, keine neue Regel, **keine neue Prüfung** – vier neue Sondeneinheiten, davon drei an einer Auskunft, die bis dahin keine hatte |
+| Dringlichkeit | Regulär; gefunden beim Heben auf `1.4.1` |
+| Status | 🟢 **entschieden am 2026-09-24** (E1 bis E4), umgesetzt mit `1.4.2` |
+
+---
+
+## 1. Anlaß
+
+Beim Heben der beiden übernehmenden Projekte auf `1.4.1` gab die Auskunft aus D-349 im
+Pilotprojekt Pfade der Form `".koolie/core/build/doc/03-ziele-nichtziele.md/r"` aus –
+mit Anführungszeichen und einem `/r` am Ende. Der Befund ist in `1.4.1` benannt und
+**nicht** behoben worden.
+
+## 2. Die Gegenprüfung
+
+### 2.1 Der Befund selbst – gemessen, nicht erschlossen
+
+`ignorierte_kerndateien()` übergab die Pfade mit `text=True` an
+`git check-ignore --stdin`. Unter Windows schreibt Python dabei `\r\n`; git bekommt jeden
+Pfad mit angehängtem `\r`, vergleicht ihn **so** gegen die Muster und gibt ihn gequotet
+zurück (`"…md\r"`); `replace("\\", "/")` macht aus dem Escape das `/r`.
+
+**Wegwerf-Repositorium, drei Dateien unter `.koolie/core/`, `.gitignore` mit `*.md`:**
+
+| Messung | Ergebnis |
+|---|---|
+| `git check-ignore` direkt | **2** ignorierte Dateien |
+| `ignorierte_kerndateien()` aus `1.4.1` | 🔴 **0** |
+| dieselbe, dazu eine dritte `.md`-Datei mit U-Umlaut im Namen | 🔴 **1 von 3, verfälscht** – der letzte Pfad der Eingabe, dem kein Zeilenende folgt; `text=True` schrieb ihn in `cp1252`, und zurück kam `".koolie/core/docs//334bersicht.md"` |
+
+➡️ Ein Verzeichnismuster (`build/`) trifft trotzdem, weil es am Elternverzeichnis greift –
+**das war der Anlaßfall von `K-117`, und deshalb fiel es niemandem auf.** Ein Dateimuster
+trifft nie. 🔴 **Die Auskunft hatte keine Sonde**: Sie ist keine Prüfung, und die
+Sondenpflicht aus D-23 hat sie deshalb nicht erreicht.
+
+### 2.2 🔴 Die zweite Stelle in derselben Richtung
+
+Gesucht nach der Lehre aus `0.57.0` (*zwei Stellen, die einander decken*): Wo liest der
+Kern sonst eine Pfadliste von git als Text? **Zwei Hilfsfunktionen des Validators**,
+`_verfolgte_dateien()` (Prüfungen 45 und 78) und `_p75_verfolgt()` (Prüfungen 75 und 81),
+lesen `git ls-files` zeilenweise. Ohne `-z` quotet git jeden Pfad mit Nicht-ASCII-Zeichen
+(`core.quotePath`, Vorgabe an): aus einem U-Umlaut wird `"docs/\303\234bersicht.md"`.
+
+| Prüfung | Was sie mit dem gequoteten Pfad tat |
+|---|---|
+| 81 | fand unter dem Namen keine Datei – `if not os.path.isfile(pfad): continue`, **leise** |
+| 75 | sah die Endung `.md"` statt `.md` und übersprang die Datei als Nicht-Text, **leise** |
+| 78 | zählte die Datei, aber **nicht als Markdown** |
+| 45 | unberührt – sie sucht `__pycache__` im Pfad, und das Quoting läßt ihn stehen |
+
+**Gegenbeweis, gemessen:** Arbeitsbaumkopie, `git init`, ein Träger
+`Übersicht-probe.md` mit einer eingeschleppten LF-Zeile. **Validator aus `1.4.1`: 0
+Treffer auf `mischt CRLF- und LF-Zeilen`; neuer Validator: 1.**
+
+Heute trägt keiner der drei gezählten Bestände einen solchen Pfad (Quellrepositorium 535
+verfolgte Dateien, Pilot 622, Übungsrepositorium 719 – je **0** mit Nicht-ASCII-Zeichen).
+⚠️ **Das ist kein Entlastungsgrund:** Ein übernehmendes Projekt in deutscher Sprache legt
+den ersten solchen Namen an, ohne daß es jemand merkt – und genau dann schweigt die
+Prüfung.
+
+### 2.3 🔴 Ein Befund des Verfahrens: Das Hauptdokument war für `openai-codex` nicht baubar
+
+Gefunden beim Schritt 3 aus `RELEASE_PROCESS.md` Abschnitt 4.1 (Hauptdokument und
+Word-Fassung **je Client Pack**), der in `1.4.1` ausgelassen war – **und für das mit
+`1.4.0` gekommene dritte Pack nie gelaufen ist:**
+
+```
+FEHLER: eingebettete Datei fehlt (Referenzinstallation openai-codex): AGENTS.override.md.example
+```
+
+Kapitel 16 bettet `<ROOT_INSTRUCTION_LOCAL>.example` für jedes Pack ein. `openai-codex`
+liefert die Vorlage **bewusst nicht** aus: Die Datei an dieser Stelle verdrängt die
+Wurzel-Anweisung (D-341). Die Entscheidung stand im Pack – das Kapitel kannte sie nicht.
+
+🔴 **Und der abgebrochene Bau hat ein falsches Erzeugnis hinterlassen.** `assemble.py`
+brach ab, ohne `hauptdokument.md` und `referenzclient.txt` des vorigen Laufs zu entfernen;
+`build-docx.py` setzte daraus die Word-Fassung **des vorigen Packs** ein zweites Mal
+zusammen und meldete Erfolg. ➡️ *Ein Werkzeug, das nach einem Abbruch das Erzeugnis von
+vorhin stehen läßt, liefert eine Erfolgsmeldung für den falschen Gegenstand.*
+
+⚠️ **Nachbarfund:** Die Notiz zu den Laufzeit-Platzhaltern im Manifest von `openai-codex`
+nannte **Prüfung 86** als die, die `AGENTS.override.md` im Projekt meldet. Es ist
+**Prüfung 88**; 86 prüft die Sperrform des Hooks.
+
+---
+
+## 3. Vorlage zur Entscheidung
+
+| # | Frage | Wege und ihre Preise |
+|---|---|---|
+| **E1** | **Wie wird die Auskunft berichtigt?** | **`git check-ignore -z --stdin`, Eingabe als UTF-8-Bytes, NUL-getrennt; die Ausgabe ebenso gelesen.** Hebt das `\r` **und** das Quoting auf. **Verworfen:** nur das `\r` abschneiden – das Quoting bliebe, und es trifft jeden Arbeitsplatz. **Verworfen:** `core.quotePath=false` für den Aufruf – Pfade mit Zeilenumbruch oder Anführungszeichen blieben mehrdeutig. ⚠️ **Preis:** keiner, den ein Projekt merkt; die Auskunft meldet nur mehr, wo sie bisher zu wenig meldete |
+| **E2** | **Werden die Prüfungen 45, 75, 78 und 81 im selben Release berichtigt?** | **Ja** – dieselbe Ursache, dieselbe Abhilfe (`git ls-files -z`), eine gemeinsame Hilfsfunktion `_git_pfade()`. **Verworfen: ein eigener Posten.** Ein bekannter leiser Fehler in einer Prüfung wiegt schwerer als eine Sondeneinheit mehr. ⚠️ **Preis:** Eine Prüfung kann nach dem Heben in einem Projekt **neu melden** – dann, wenn dort ein Träger mit Nicht-ASCII-Namen schon abweicht. Das ist der Befund, nicht der Preis |
+| **E3** | **Wirkungsnachweis** | **Bündel `sonden_ignorierte_kerndateien`** an einer echten Installation mit `git init`, drei Einheiten, **jede gegen einen `os.walk` über den Kern gezählt, nicht gegen eine gepflegte Zahl:** Sonde `D349` (`*.md`), Gegenprobe `D349a` (`build/`, der Anlaßfall), Gegenprobe `D349b` (ein Muster, das nichts trifft: kein Hinweis). Dazu **Sonde 81e** im Bündel zu Prüfung 81. **Gegen den Vorstand fallen `D349` und `81e`** |
+| **E4** | **Wie wird Kapitel 16 für ein Pack ohne Ergänzungsdatei gebaut?** | **Eine Direktive `{{LOKALE-ERGAENZUNG}}`, deren Weiche das Manifestfeld `root_instruction_override` ist:** ohne das Feld der bisherige Satz samt Einbettung – und eine fehlende Datei bricht den Bau **weiter** ab –, mit dem Feld eine Erklärung, weshalb es die Datei nicht gibt. Dazu entfernt `assemble.py` vor dem Bau die Erzeugnisse des vorigen Laufs. **Verworfen:** eine Einbettung, die bei jedem Fehlen still eine Erklärung einsetzt – die Ausnahme, die alles ausnimmt. **Wirkungsnachweis:** Alle drei Fassungen gebaut; `claude-code` und `devin-desktop` **zeichengleich** zum Bau vor dem Eingriff (2.085.504 und 2.081.833 Zeichen), `openai-codex` 2.073.255 Zeichen mit der Erklärung genau einmal. ⚠️ **Keine Sonde:** Der Bau braucht `pandoc` und `mmdc`, und keine Prüfung fährt ihn – die Grenze, die Schritt 3 von Hand schließt |
+
+> **Empfehlung der Vorbereitung:** E1 bis E4 wie vorgelegt. Keine neue Prüfung – die
+> Auskunft bleibt eine Auskunft (D-349), die Prüfungen behalten ihren Gegenstand.
+
+**Mit aufgenommen, ohne Änderung am Bestand:** Zwei Fragen des Owners vom 2026-09-24
+stehen seither als Klärungspunkte im Decision Log – **`K-120`** (Overlay-Werte an einem
+Ort, `--update` rendert Laufzeitfassung und Berechtigungsdatei; vor `1.5.0` einzuordnen)
+und **`K-121`** (die Schreibrückfrage bei `devin-desktop` als Overlay-Wert).
+
+---
+
+## 4. Umsetzung
+
+1. `install.py`: `ignorierte_kerndateien()` mit `-z`, Ein- und Ausgabe als Bytes.
+2. `validate-framework.py`: `_verfolgte_dateien()` und `_p75_verfolgt()` rufen
+   `git ls-files -z`; beide geben ihre Ausgabe an die neue `_git_pfade()`.
+3. `probe-pruefungen.py`: Bündel `sonden_ignorierte_kerndateien` hinter dem Bündel zu
+   D-46; Sonde 81e zwischen 81b und 81d; die Einheitenzahl im Kopf des Bündels zu
+   Prüfung 81 berichtigt (*„VIER"* – es waren seit `1.4.1` sechs, jetzt sieben).
+4. `DECISION_LOG.md`: **D-352**, **K-120**, **K-121**.
+5. `build/assemble.py`: Direktive `{{LOKALE-ERGAENZUNG}}` und das Entfernen der
+   Erzeugnisse des vorigen Baus; Kapitel 16 auf die Direktive umgestellt; die Notiz im
+   Manifest von `openai-codex` nennt Prüfung 88. Hauptdokument und Word-Fassung für alle
+   **drei** Packs gebaut.
+6. `VERSION` `1.4.2`, Changelog, Roadmap, Dokumentkopf; beide übernehmenden Projekte auf
+   `1.4.2` gehoben und dort committet.
+
+## 5. Abnahme
+
+Steht im Protokoll `tests/protocols/2026-09-24-pfadlisten-nul-getrennt.md`.
+
+## 6. Entscheidung
+
+**E1 bis E4 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-24; der Owner hat
+vorab erklärt, den Empfehlungen der Vorbereitung zu folgen). Decision Record **D-352**.
+Alle vier zählbaren Kriterien von D-11 bleiben **0**; kein Overlay-Feld berührt.

package/.koolie/core/governance/change-requests/CR-2026-136-overlay-werte-einordnung.md

@@ -0,0 +1,156 @@
+# Änderungsantrag `CR-2026-136`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Frage nach dem einen Ort der Overlay-Werte – und der Träger, den sie dafür vorschlug, trägt sie nicht |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-24 |
+| Betroffene Artefakte | `governance/DECISION_LOG.md` (**D-353**; `K-120` beantwortet; Vermerke an `K-67`, `K-69`, `K-121`); `docs/ROADMAP.md` (Posten `1.5.0`: Füllschritt bei der Erstinstallation, `K-69` und die Abbildung von `<READ_ONLY_PATHS>` in den Umfang genommen); `governance/ADOPTION_REGISTRY.md`; `build/doc/00-kopf.md`, `26-qs-test.md`; `VERSION`, `CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Eigentumsgrenze zwischen Kern und Projekt, Releaseplan |
+| Art | **Einordnung.** Patch-Release nach `RELEASE_PROCESS.md` Abschnitt 1: kein Overlay-Feld berührt, keine Regel, **keine Prüfung, kein Werkzeug geändert** – entschieden wird, **was `1.5.0` baut und was nicht** |
+| Dringlichkeit | Vor `1.5.0` (Frage (2) von `K-120`) |
+| Status | 🟢 **entschieden am 2026-09-24** (E1 bis E4), umgesetzt mit `1.4.3` |
+
+---
+
+## 1. Anlaß
+
+`K-120` fragt, ob die Projektwerte eines Overlays an **einem** Ort stehen sollen und
+`install.py --update` Laufzeitfassung und Berechtigungsdatei daraus **erzeugt**. Der Punkt
+ist *vor `1.5.0` einzuordnen*, weil das Overlay *General Development* (D-126) weitere Werte
+mitbringt. `K-121` hängt mit seiner Frage (3) daran.
+
+## 2. Die Gegenprüfung
+
+### 2.1 🔴 Der vorgeschlagene Träger trägt die Werte nicht
+
+`K-120` Frage (1) schlägt `overlay-manifest.yaml` als einzige Quelle vor. **Gelesen in der
+Vorlage und in beiden übernehmenden Projekten:** Die Datei ist das **Register der
+Projektdokumente** (Ebene 4, `OVERLAY.md` Abschnitt 19). Von den Projektwerten führt sie
+genau einen, die Overlay-Version (`overlay_version`), dazu `project_code`. **Die Pfad- und
+Befehlswerte stehen in keinem der drei Bestände darin.** Ihre Quelle ist die
+**Bindungstabelle in `OVERLAY.md`** (Abschnitte 4 bis 6), und das sagt die Vorlage selbst:
+*„Diese Werte MÜSSEN in `<PERMISSIONS_FILE>` und in `<RULES_DIR>/20-project-overlay.md`
+übernommen werden.“*
+
+🔴 **Und die „bis zu vier Träger“ sind zwei verschiedene Dreiergruppen.** Die Zahl stammt
+aus der Auflage von `CR-2026-090` (*„Quelle, Manifest, Laufzeitfassung,
+Berechtigungsdatei“*) und vereinigt zwei Gegenstände:
+
+| Wert | Träger | Zahl |
+|---|---|---|
+| Overlay-Version | `OVERLAY.md`, `overlay-manifest.yaml`, Laufzeitfassung | 3 |
+| ein Pfad- oder Befehlswert | `OVERLAY.md`, Laufzeitfassung, Berechtigungsdatei | 3 |
+
+➡️ **Kein Wert steht in vier Trägern.** Der Befund von `K-120` trägt trotzdem – drei Stellen
+Handpflege sind zwei zu viel –, aber **die Abhilfe, die er vorschlug, hätte am falschen Ort
+angesetzt:** Wer das Dokumentenregister zur Wertquelle macht, verschiebt jeden Pfadwert in
+eine **vierte** Datei.
+
+### 2.2 Was ein Erzeugen aus der Quelle überschreiben würde – gemessen an beiden Projekten
+
+Die Kernquelle `framework/runtime/permissions.json` mit `install.py` für das jeweilige Pack
+gerendert und gegen die Berechtigungsdatei des Projekts gehalten (Stand `1.4.2`):
+
+| | Pilot (`claude-code`) | Übungsrepositorium (`devin-desktop`) |
+|---|---|---|
+| Einträge nur im Projekt | **12** (2 `ask`, 10 `deny`) | **25** (3 `ask`, 22 `deny`) |
+| davon aus einem Platzhalter der Kernquelle ableitbar | 10 | 20 |
+| davon Umsetzung von `<READ_ONLY_PATHS>` – **ein Platzhalter, den die Kernquelle nicht abbildet** | 2 (`pom.xml`, `start.ps1`) | 2 (`api-contracts/**`, Migrationen) |
+| davon **echte Projektzusätze ohne jeden Platzhalter** | **0** | **3** (`Exec(mvn deploy)`, `Exec(npm install)`, `Exec(npm uninstall)`) |
+| Einträge der Kernquelle, die das Projekt **entfernt** hat, weil sein Wert „nicht vorhanden“ ist | 2 (`<QUALITY_GATE_CONFIG_PATHS>`, `<LINT_COMMAND>`) | 0 |
+
+Alle Zusätze sind **Verschärfungen** (`deny`) oder gefüllte Befehlsschlitze – D-76 verbietet
+dem Overlay **Freigaben** über die drei Schlitze hinaus, keine Sperren.
+
+**Die Laufzeitfassung ist überwiegend Projektprosa.** Ohne den Inhalt der Codespannen
+gezählt, weichen im Pilot **59 von 91** Zeilen von der Vorlage ab, im Übungsrepositorium
+**48 von 78**; einen gebundenen Platzhalter tragen 8 beziehungsweise 5 Zeilen.
+
+➡️ **Ein Erzeugen bei `--update` bräuchte also drei Dinge, die es heute nicht gibt:** eine
+zweite Quelle für die Projektzusätze – **ein zweites Register**, genau der Befundtyp, den
+die Roadmap für `1.5.0` ausdrücklich vermeiden will –, ein Vokabular für *„nicht
+vorhanden“*, und eine Abgrenzung der Laufzeitfassung zwischen erzeugtem und geschriebenem
+Text.
+
+### 2.3 🔴 Was ein vorbefülltes Overlay heute nach der Erstinstallation hinterläßt – gemessen
+
+Wegwerf-Installation aus dem Arbeitsbaum (`claude-code`), danach `<EXCLUDED_PATHS>` in
+`OVERLAY.md` und Laufzeitfassung auf `deploy/**` gesetzt – so, wie ein Muster mit
+vorgeschlagenen Werten es ausliefern würde:
+
+| Zustand | `--strict-overlay` |
+|---|---|
+| Berechtigungsdatei wie installiert | `.claude/settings.json: enthält noch Platzhalter` – `Read(<EXCLUDED_PATHS>)` steht **wörtlich** im `deny`-Korb. **Prüfung 59 enthält sich** (Code: *„Schlitz noch ungefüllt“*) |
+| Gegenprobe: `deny` auf `deploy/**` gefüllt | Meldung zu `EXCLUDED_PATHS` fällt weg; übrig bleiben die übrigen Schlitze |
+
+➡️ **Ein Muster, das Werte vorschlägt, erreicht die Schicht nicht, die sie durchsetzt.**
+Die Berechtigungsdatei entsteht aus der Kernquelle, nicht aus dem Overlay – und bis ein
+Mensch sie füllt, **sperrt der vorgeschlagene Wert nichts**, während `OVERLAY.md` ihn schon
+nennt. Das ist die Lage, die der Sitzungsaufbau des Übungsrepositoriums seit `0.65.0` mit
+einem eigenen Füllskript überbrückt (*„der Füllschritt gehört zum Aufbau“*).
+
+### 2.4 Die Grenze zu D-76
+
+D-76 hat 2026-09-13 eine Erweiterungsschicht verworfen, weil *„eine nur beim Installieren
+gelesene Quelle eine Zusage wäre, die beim ersten Releasewechsel bricht“*. **Ein
+Füllschritt bei der Erstinstallation ist dieselbe Lesestelle** – der Unterschied muß
+deshalb in der Zusage und in der Quelle liegen, nicht im Mechanismus: D-76 verwarf einen
+**fortlaufenden** Kanal für zusätzliche Freigaben aus dem **Projekt**; ein Füllschritt
+verspricht nur den **Anfangszustand**, füllt ausschließlich die Schlitze, die die
+Kernquelle ohnehin hat, und liest dafür **das mitgelieferte Muster – einen Träger des
+Kerns, nicht des Projekts.** Der Befund von D-76, *„`render_permissions` liest keine Quelle
+des Projekts“*, bleibt damit wahr. Danach gehört die Datei dem Projekt wie heute.
+
+### 2.5 🔴 Was eine verbindliche Bindungsform kosten würde
+
+`K-67` fragt, ob die Overlay-Vorlage **eine** Form verlangen soll, einen Platzhalter zu
+binden. Sein eigener Statusvermerk nennt den Preis: *„verlangte einen Umbau **jeder**
+bestehenden Overlay-Datei“*. **Nach `RELEASE_PROCESS.md` Abschnitt 1 ist das MAJOR** –
+eine Änderung, die Overlays anpassen müssen. ➡️ **Eine Voraussetzung, die ein
+MAJOR-Release verlangt, kann nicht Voraussetzung eines MINOR-Postens sein.** Sie ist es
+auch nicht: Der Füllschritt liest das Muster, dessen Form das Framework selbst festlegt
+(2.4), und Prüfung 59 liest `<EXCLUDED_PATHS>` schon heute aus der dreispaltigen Zeile von
+Abschnitt 4 – in **beiden** Projekten stehen alle fünf Pfadplatzhalter in genau dieser Form.
+
+---
+
+## 3. Vorlage zur Entscheidung
+
+| # | Frage | Wege und ihre Preise |
+|---|---|---|
+| **E1** | **Wird `overlay-manifest.yaml` die Quelle der Projektwerte?** (`K-120` (1)) | **Nein.** Quelle ist und bleibt die Bindungstabelle in `OVERLAY.md` (2.1). `K-120` wird in diesem Punkt **berichtigt**, nicht beantwortet: Das Register trägt einen einzigen Wert, und die „vier Träger“ sind zwei Dreiergruppen. **Verworfen:** das Register zur Wertquelle ausbauen – jeder Pfadwert bekäme eine vierte Ablage. ⚠️ **Preis:** keiner; die Auflage aus `CR-2026-090` bleibt richtig, sie zählt nur zusammen, was zwei Gegenstände sind |
+| **E2** | **Erzeugt `--update` Laufzeitfassung und Berechtigungsdatei aus der Quelle?** (`K-120` (1) und (3)) | **Nein, nicht in `1.x`.** Beide Dateien bleiben Saat (D-76). Gemessen (2.2): **3 von 37** Projekteinträgen sind aus keinem Platzhalter ableitbar, **4** setzen einen Platzhalter um, den die Kernquelle gar nicht abbildet, **2** Kerneinträge hat ein Projekt bewußt entfernt, und die Laufzeitfassung ist zu gut der Hälfte Projektprosa. Ein Erzeugen verschöbe die Eigentumsgrenze und zwänge jedes Overlay zur Anpassung – nach `RELEASE_PROCESS.md` Abschnitt 1 **MAJOR**. **Antwort auf Frage (3):** Die Projektzusätze bleiben, wo sie sind, weil nichts sie überschreibt. **Verworfen:** Erzeugen mit einer zweiten Quelle für Zusätze (ein zweites Register); Erzeugen mit Markerblöcken (JSON trägt keine Kommentare, zwei der drei Berechtigungsdateien sind JSON). ⚠️ **Preis, benannt: Die Handpflege an drei Stellen bleibt.** Gemildert wird sie durch E4 – geprüft statt erzeugt. **Ein Erzeugen bleibt ein möglicher MAJOR-Posten**, wenn die erweiterte Prüfung (E4) im Betrieb Abweichungen findet, die sie nur melden und nicht verhindern kann |
+| **E3** | **Was braucht `1.5.0` dann?** (`K-120` (2)) | **Einen Füllschritt bei der Erstinstallation:** Wer `--overlay general` wählt, bekommt Laufzeitfassung und Berechtigungsdatei **einmal** aus der Bindungstabelle des gewählten Musters gefüllt – dieselben Schlitze, die die Kernquelle hat, keiner mehr. Saat bleibt Saat, das Eigentum ändert sich nicht, **MINOR** wie geplant. Ohne ihn liefert das Muster einen Wert, der nichts sperrt (2.3). **Abgrenzung zu D-76 (2.4):** Die Zusage ist der Anfangszustand, kein Kanal, und die Quelle ist das Muster im Kern, nicht das Projekt. **Ohne `--overlay` bleibt alles wie heute** – das leere Overlay hat keine Werte, die zu füllen wären. **Verworfen:** den Füllschritt auch aus einem **projekteigenen** `OVERLAY.md` speisen – das wäre der Kanal, den D-76 verworfen hat, und bräuchte `K-67`. ⚠️ **Preis:** Ein Projekt, das nach der Installation einen vorgeschlagenen Wert ändert, zieht ihn wie heute von Hand nach – der Füllschritt wirkt genau einmal |
+| **E4** | **Wie werden `K-67` und `K-69` eingeordnet?** | **`K-69` wird Voraussetzung von `1.5.0`, `K-67` nicht.** `K-69` (der Wertabgleich für `<ALLOWED_PATHS>`, `<TEST_PATHS>`, `<DOC_PATHS>`, `<READ_ONLY_PATHS>`), weil E2 die Handpflege bestehen läßt und nur eine Prüfung sie auffängt – gelesen wird wie bei Prüfung 59 die dreispaltige Zeile von Abschnitt 4. **Dazu in den Umfang:** die Frage, ob die Kernquelle `<READ_ONLY_PATHS>` als Schreibsperre abbildet – **beide Projekte tun es von Hand, auf dieselbe Weise** (2.2). **`K-67` bleibt offen und bekommt seinen Preis dazugeschrieben:** Eine verbindliche Bindungsform ist MAJOR (2.5). **Verworfen:** `K-69` als eigenes Release vor `1.5.0` – der Releaseplan rückte zum **dritten** Mal um eins (nach D-339 und D-341), für eine Prüfung, deren erster neuer Gegenstand erst mit dem Muster entsteht. **Verworfen:** `K-67` in `1.5.0` – ein MAJOR-Eingriff als Voraussetzung eines MINOR-Postens. ⚠️ **Preis:** `1.5.0` wird größer; und die erweiterte Prüfung sieht wie Prüfung 59 nur die tabellarische Bindung – ein Overlay, das anders bindet, **entgeht ihr, und das muß die Prüfung dann melden, nicht verschweigen** |
+
+**Zu `K-121` Frage (3)** – *hängt die Schreibrückfrage an `K-120`?* – **ja, und E2 sagt
+wie:** Ein Overlay-Wert, der die Schreibrückfrage steuert, stünde als Hand-Eintrag in der
+Berechtigungsdatei, an einer der drei Stellen ohne Erzeugung. **Er ist erst dann ein
+tragbarer Ort für eine Sicherheitseinstellung, wenn eine Prüfung ihn gegen die Quelle hält**
+– also frühestens mit E4. `K-121` bleibt in (1) und (2) offen.
+
+> **Empfehlung der Vorbereitung:** E1 bis E4 wie vorgelegt. Keine neue Prüfung, kein
+> Werkzeug geändert – dieses Release ordnet ein, `1.5.0` baut.
+
+---
+
+## 4. Umsetzung
+
+1. `DECISION_LOG.md`: **D-353**; `K-120` auf *beantwortet*; Vermerke an `K-69`
+   (Voraussetzung von `1.5.0`), an `K-67` (keine Voraussetzung, Preis MAJOR) und an
+   `K-121` (Frage (3) beantwortet).
+2. `docs/ROADMAP.md`: im Abschnitt zum Posten `1.5.0` die entschiedenen Voraussetzungen
+   und der erweiterte Umfang; Zeile `1.5.0` der Releasetabelle; Zeile `1.4.3`.
+3. `VERSION` `1.4.3`, Changelog, Dokumentkopf, Bestandsliste; beide übernehmenden Projekte
+   auf `1.4.3` gehoben und dort committet; Hauptdokument und Word-Fassung je Pack.
+
+## 5. Abnahme
+
+Steht im Protokoll `tests/protocols/2026-09-24-overlay-werte-einordnung.md`.
+
+## 6. Entscheidung
+
+**E1 bis E4 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-24; der Owner hat
+vorab erklärt, den Empfehlungen der Vorbereitung zu folgen). Decision Record **D-353**.
+Alle vier zählbaren Kriterien von D-11 bleiben **0**; kein Overlay-Feld berührt.