@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-130-reihenfolge-des-hebens.md

@@ -0,0 +1,204 @@
+# Änderungsantrag `CR-2026-130`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Reihenfolge des Hebens – ein Prüfpunkt, den sein eigenes Verfahren hinter seinen Zeitpunkt legt |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-23 |
+| Betroffene Artefakte | `.koolie/core/governance/RELEASE_PROCESS.md` (Abschnitt 4.1); `.koolie/core/checklists/11-framework-release.md` (Prüfpunkt 20); `.koolie/core/governance/ADOPTION_REGISTRY.md`; `.koolie/core/tests/scripts/validate-framework.py` (**Prüfung 82**); `.koolie/core/tests/scripts/probe-pruefungen.py`; `.koolie/core/governance/DECISION_LOG.md` (**D-329** bis **D-332**, `K-110`); `.koolie/core/VERSION`; `.koolie/core/CHANGELOG.md`; `.koolie/core/docs/ROADMAP.md`; `.koolie/core/build/doc/00-kopf.md`, `26-qs-test.md`; `UEBERGABE.md` |
+| Ebene laut Entscheidungsbaum 6 | Governance |
+| Art | **Änderung.** MINOR-Release nach `RELEASE_PROCESS.md` Abschnitt 1 – Prüfung 82 ist eine neue Regel, keine Formulierung |
+| Dringlichkeit | regulär – der Schuldposten ist aus `1.0.1` übernommen und steht seit zwei Releases |
+| Status | 🟢 **entschieden am 2026-09-23** (E1 bis E5) |
+
+---
+
+## 1. Anlass
+
+**Die Bestandsliste der übernehmenden Projekte war in zwei aufeinanderfolgenden Releases
+falsch, und beide Male aus demselben Grund.**
+
+`1.0.0` hat sie angelegt (D-322), und ihr erster Eintrag war zugleich ihr erster Befund:
+Beide übernehmenden Projekte standen **drei Releases** hinter `main`, während Kriterium 5
+von D-11 als erfüllt geführt wurde. `1.0.1` hat es wiederholt – die Liste stand einen
+halben Tag auf `1.0.0`, während die Projekte `1.0.1` trugen.
+
+Die Übergabe zu `1.0.1` hat die Ursache richtig benannt:
+
+> *„Sie wurden NACH dem Merge gehoben statt davor, und damit war `FW-CL-11` Prüfpunkt 20
+> zum Merge-Zeitpunkt nicht erfüllt."*
+
+**Und sie hat die Frage ausdrücklich offen gelassen:** *„Zu prüfen: Gehört das Heben vor
+den Release-Commit, und muß Abschnitt 4.1 die Reihenfolge nennen?"*
+
+## 2. Der gemessene Bestand – der Befund ist größer als der Schuldposten
+
+Prüfpunkt 20 von `FW-CL-11` lautet:
+
+> *„**MUSS** Release-Archiv erzeugt und abgelegt; übernehmende Projekte informiert
+> (Migrationshinweise, betroffene Overlay-Felder)."*
+
+**Das ist EIN Haken über ZWEI Gegenständen** – und ihre frühesten möglichen Zeitpunkte
+liegen auf **entgegengesetzten Seiten** des Release-Commits:
+
+| Hälfte von Prüfpunkt 20 | frühestens möglich | warum |
+|---|---|---|
+| *„Release-Archiv erzeugt und abgelegt"* | **nach** dem Commit | Abschnitt 4.1 Schritt 2 baut das Archiv **aus der Marke**, und Schritt 1 setzt die Marke **auf** den Release-Commit |
+| *„übernehmende Projekte informiert"* | **vor** dem Commit | `install.py --update` läuft gegen den Arbeitsbaum, und der trägt die neue `VERSION` bereits |
+
+➡️ ***Ein Prüfpunkt, dessen eigenes Verfahren seine Erfüllung hinter den Zeitpunkt legt,
+an dem er abgehakt wird, ist nicht unerfüllt – er ist falsch geschnitten.***
+
+🔴 **Die Checkliste wird VOR dem Release durchgegangen.** Ihre eigene Kopfzeile sagt es:
+*„Wann: vor jedem Framework-Release (auch Patch-Releases)."* Die erste Hälfte von
+Prüfpunkt 20 konnte zu diesem Zeitpunkt **noch nie** erfüllt sein – auch nicht in `1.0.0`,
+dem Release, das das Archivverfahren eingeführt hat.
+
+## 3. Das Heben ist ein Prüfmittel, nicht eine Fortschreibung
+
+**Die Empirie der beiden Releases zeigt in eine Richtung, und sie zeigt mehr als die
+Reihenfolge.**
+
+| Release | wann gehoben | was dabei herauskam |
+|---|---|---|
+| `1.0.0` | **vor** dem Abschluß | 🔴 **B13 und B14** – Prüfung 78 und 79 aus `0.90.0` waren in **jeder** Installation rot. **Gefunden hat sie kein Validatorlauf, sondern das Heben** |
+| `1.0.1` | **nach** dem Merge | 🔴 Die Bestandsliste stand einen halben Tag falsch |
+
+➡️ ***Das Heben ist nicht die Fortschreibung einer Liste, es ist ein Lauf gegen eine
+fremde Installation*** – und D-326 sagt es bereits, nur an der Prüfung und nicht am
+Release:
+
+> *„Jede neue Prüfung läuft einmal gegen ein übernehmendes Projekt, bevor sie als fertig
+> gilt – `--strict-overlay` ist billiger als der nächste Meßtag."*
+
+🔴 **Genau diese Lehre stand in der Übergabe und nicht im Ablauf, und ihre Halbwertszeit
+war ein Release** (D-326). Dasselbe würde einem Satz in Abschnitt 4.1 widerfahren, der
+ohne Prüfung dasteht.
+
+## 4. Und die Liste war an ZWEI Stellen falsch, nicht an einer
+
+🔴 **Gemessen am 2026-09-23, im Vorbedingungsdurchgang dieses Releases, vor dem ersten
+Handgriff:**
+
+| Ort | `VERSION` | Spalte `Framework-Version` der Bestandsliste |
+|---|---|---|
+| Framework-Repositorium | `1.0.1` | `1.0.1` ✅ – mit `1.0.1` nachgezogen |
+| `devpacks/test-devin-framework` | `1.0.1` | 🔴 **`1.0.0`** |
+| `devpacks/otp-generator` | `1.0.1` | 🔴 **`1.0.0`** |
+
+**`1.0.1` hat die Liste an einer Stelle berichtigt und sie an zwei ausgeliefert.** Die
+Berichtigung fiel **nach** dem Heben, und damit erreichte sie die Kopien nicht mehr.
+
+➡️ ***Wer eine Liste nach dem Heben fortschreibt, schreibt sie an einer Stelle fort und
+liefert sie an zwei.***
+
+🟢 **Das ist zugleich der gemessene Beleg dafür, daß ein Verfahrensschritt allein hier
+nicht getragen hätte** – er stünde im Framework und wäre in beiden Installationen
+unbelegt.
+
+---
+
+## 5. Vorlage zur Entscheidung
+
+### E1 – Gehört das Heben der übernehmenden Projekte vor den Release-Commit?
+
+| | |
+|---|---|
+| **Auflösung** | 🟢 **Ja.** Abschnitt 4.1 bekommt das Heben als **Schritt 1**, ausdrücklich vor dem Freigabe-Commit; die bisherigen Schritte rücken nach |
+| **Preis, benannt** | ⚠️ Wer vor dem Commit hebt, hebt aus einem **unveröffentlichten** Stand. Ändert sich der Baum danach noch – und in `1.0.0` hat er sich **genau deswegen** geändert –, muß **erneut** gehoben werden. ➡️ ***Heben und Commit gehören als Paar***, wie Commit und Marke (D-321, Falle 4 aus `1.0.0`) |
+| **Verworfen** | **Nach dem Merge heben** – der Stand von heute. Zweimal in zwei Releases gemessen, zweimal mit derselben Folge |
+| **Verworfen** | **Die Liste ohne Versionsangabe führen.** Dann veraltet sie nicht – und beantwortet die Frage nicht mehr, für die sie angelegt wurde (D-322) |
+
+### E2 – Wird Prüfpunkt 20 geteilt?
+
+| | |
+|---|---|
+| **Auflösung** | 🟢 **Ja, in zwei Prüfpunkte.** Einer vor dem Commit (*Projekte gehoben, Bestandsliste fortgeschrieben*), einer danach (*Archiv erzeugt, nachgezählt und abgelegt*) |
+| **Preis, benannt** | ⚠️ Ein Haken mehr in einer Checkliste, die bereits 24 führt |
+| **Verworfen** | **Den Haken lassen und die Reihenfolge nur in 4.1 nennen.** Dann bleibt ein Prüfpunkt, der zum Zeitpunkt des Abhakens nicht erfüllbar ist – und das ist die Bauform *die Regel mit leerer Schnittmenge* (D-189, `K-72`), hier an einem Prüfpunkt |
+
+### E3 – Bekommt die Reihenfolge eine Prüfung, oder bleibt sie ein Verfahrensschritt?
+
+| | |
+|---|---|
+| **Auflösung** | 🟢 **Prüfung 82.** Jede Zeile der Bestandsliste nennt in der Spalte `Framework-Version` den Inhalt von `.koolie/core/VERSION`; Abweichung ist ein **Fehler** |
+| **D-299-Probe** | 🟢 **Geführt und bestanden.** In einem übernehmenden Projekt sind Liste und `VERSION` **byte-gleich aus demselben Release** ausgeliefert und tragen deshalb denselben Wert – auch dann, wenn das Projekt mehrere Releases zurückliegt. Die Prüfung ist dort grün, **und sie braucht dafür keine Ausnahme** |
+| **Grenze, benannt** | 🔴 **Sie mißt die Behauptung, nicht die Tatsache.** Wer die Zeile ändert, ohne zu heben, kommt durch. Dieselbe Bauform wie Prüfung 77, die die **Version** des Hauptdokuments mißt und nicht seinen **Inhalt** (D-312) |
+| **Preis, benannt** | ⚠️ **Jedes Release faßt diese Tabelle an** – derselbe Preis wie bei Prüfung 67 und 77 |
+| **Verworfen** | **Die Liste gegen die Projekte halten.** Sie liegen außerhalb des Repositoriums; eine Prüfung, die sie sucht, wäre auf jedem anderen Arbeitsplatz rot (D-299) |
+| **Verworfen** | **Nur ein Verfahrensschritt.** D-326 hat gemessen, was eine Lehre ohne Prüfung wert ist: ein Release |
+
+### E4 – Gilt das Heben auch bei einem Release, das kein ausgeliefertes Artefakt berührt?
+
+| | |
+|---|---|
+| **Auflösung** | 🟢 **Ja, ausnahmslos** |
+| **Begründung** | Eine Ausnahme *„nur wenn ein ausgeliefertes Artefakt berührt ist"* verlangt eine **Einstufung**, und keine Prüfung kann sie nachrechnen. 🔴 **`1.0.1` wäre genau der Fall gewesen, in dem sie falsch entschieden hätte:** Es galt als Patch-Release *„ohne neue Prüfung"* – und es änderte `RELEASE_PROCESS.md`, einen Träger, der ausgeliefert **und** in das Hauptdokument eingebettet ist |
+| **Preis, benannt** | ⚠️ `install.py --update` je Projekt bei jedem Release, auch bei reiner Prosa. Gemessen ist das ein Zehn-Minuten-Vorgang je Projekt |
+| **Verworfen** | **Eine Ausnahme für reine Chronikreleases.** Sie wäre billig und ungeprüft – die Bauform *die Ausnahme mit leerem Geltungsbereich* (0.57.1) mit umgekehrtem Vorzeichen |
+
+### E5 – Was wird aus der Word-Fassung, die auf `v1.0.0` stehengeblieben ist?
+
+| | |
+|---|---|
+| **Anlaß** | 🔴 Gemessen im Vorbedingungsdurchgang: `build/out/` führt `Koolie_v1.0.0_claude-code.docx` und `Koolie_v1.0.0_devin-desktop.docx` – **keine Fassung `v1.0.1`**. `1.0.1` hat den Dokumentkopf auf `1.0.1` gehoben und `RELEASE_PROCESS.md` geändert, einen Träger, den `25-governance.md` einbettet |
+| **Auflösung** | 🟢 Abschnitt 4.1 nennt den **Bau der Erzeugnisse** als eigenen Schritt. Er steht dort bereits als Ablage-Hinweis (*„wer sie mitliefern will, legt sie neben das Archiv"*) – **nicht aber, daß sie gebaut werden** |
+| **Grenze, benannt** | ⚠️ **Wieder ein Verfahrensschritt statt einer Prüfung, und damit schwächer.** Die Erzeugnisse liegen unter `build/out/` und stehen in der `.gitignore`; **keine der 82 Prüfungen erreicht sie.** Dieselbe benannte Lage wie beim Archiv (D-328) und beim Foliensatz (`K-105`) |
+| **Fortführung** | 🆕 **`K-110`** – ob eine Prüfung die Erzeugnisse der Lieferung überhaupt erreichen kann |
+| **Verworfen** | **Die Erzeugnisse versionieren.** Zwei Träger von je 2 MB je Release; die `.gitignore` steht seit `0.97`-Zeiten aus gutem Grund |
+
+### E6 – Welcher Commit ist nicht delegierbar, und woran erkennt man ihn?
+
+| | |
+|---|---|
+| **Anlaß** | 🔴 **Eine Rückfrage des Owners, und sie hat einen Befund ausgelöst.** Die Übergabe zu `1.0.0` führt *„Nicht delegierbar, ab jetzt bei JEDEM Release: der Freigabe-Commit und die signierte Marke (D-319, D-321)"*, und `RELEASE_PROCESS.md` 4.1 sagt *„Dieselbe Trennung gilt für den Freigabe-Commit"*. **Gemessen an den beiden Entscheidungen, die sie zitieren, geht die Auflage über beide hinaus** |
+| **Der Bestand** | **D-319:** *„Die Gegenzeichnungspflicht gilt nur für die **Abnahmeprotokolle des Testkatalogs** … Die Zeile sagt, WAS gegengezeichnet wurde – die Unterschrift ist der Commit."* Gegenstand ist eine **Gegenzeichnung**, kein Release-Commit. **D-321:** *„…und das **Tag** setzt der Mensch."* Der Commit steht dort nicht. ➡️ *Der Satz in 4.1 ist eine Folgerung ohne eigenen gemessenen Gegenstand* |
+| **Und er hatte keinen Anwendungsfall** | 🔴 Eine **dokumentierte Freigabe** gibt es in diesem Repositorium **genau einmal** – im Freigabeprotokoll zu `1.0.0`, Abschnitt 7.1. **`1.0.1` hat keine**, und sein Release-Commit ist ein gewöhnlicher. Bis `0.91.0` hat das Werkzeug alle Release-Commits gesetzt, und D-319 hält das selbst fest |
+| **Auflösung** | 🟢 **Ein Commit ist genau dann nicht delegierbar, wenn er eine Unterschrift TRÄGT** – eine Gegenzeichnung nach D-319 oder eine Freigabezeile nach `FW-CL-11`. **Ein Release-Commit ohne solchen Inhalt trägt keine**, und ein Werkzeug, das ihn setzt, fälscht nichts. 🔴 **Die signierte Marke bleibt beim Menschen** – D-321 sagt es wörtlich und ohne Folgerung |
+| **Warum das die schärfere Regel ist** | ⚠️ Die pauschale Fassung ist **nicht prüfbar**: *„Freigabe-Commit"* hat keinen erkennbaren Gegenstand, und ein Prüfmittel kann nicht nachsehen, wer eine Tastatur bedient hat. **Die neue Fassung hat einen: den INHALT des Commits.** ➡️ *Eine Auflage, deren Gegenstand niemand benennen kann, wird entweder übererfüllt oder vergessen – beides ist hier eingetreten* |
+| **Verworfen** | **Die pauschale Fassung beibehalten.** Sie hätte jeden Release-Commit an eine Handlung gebunden, die bei `1.0.1` gemessen niemand für nötig hielt – *eine Regel, die im Bestand keine Spur hinterläßt, ist keine* |
+| **Verworfen** | **Die Trennung ganz aufgeben.** D-319 ist gemessen richtig: Ein Werkzeug, das eine Gegenzeichnung setzt, fälscht sie, und die Fälschung wanderte nur aus der Zeile in die Metadaten |
+
+### E7 – Wo steht die Freigabe eines Releases? (berichtigt)
+
+| | |
+|---|---|
+| **Erster Befund, und er war am falschen Gegenstand gemessen** | 🔴 Vorgelegt war: *„`FW-CL-11` verlangt die dokumentierte Freigabe als MUSS bei jedem Release; gemessen existiert sie **einmal**, für `1.0.0`. `1.0.1` hat keine."* **Gesucht worden war in den Protokollen.** |
+| **Nachgemessen** | 🟢 **Beide vorhandenen Marken tragen sie:** *„Freigegeben durch den Framework Owner am 2026-09-23."* – und zwar **signiert**. ➡️ ***Die Marke ist die Freigabe.*** Das bestätigt D-334 an seinem eigenen Gegenstand: Der Commit trägt keine Unterschrift, die **Marke** trägt sie |
+| **Was bleibt** | 🔴 **Kein Träger des Repositoriums schreibt das vor.** Abschnitt 4.1 verlangt von der Markennachricht *„Release, Antrag und die Entscheidungen"* – die Freigabe steht dort nicht, und `FW-CL-11` nennt keinen Ort. **Die beiden vorhandenen Marken tragen sie aus Gewohnheit** |
+| **Und die Gewohnheit war beinahe gebrochen** | ⚠️ Die für `1.1.0` vorbereitete Markennachricht war **mehrzeilig** und nannte die Freigabe **nicht** – das Werkzeug hatte die beiden vorhandenen Marken nicht gelesen, bevor es die dritte vorbereitete. *Erst den Kopf des Trägers lesen, dann messen.* 🟢 **Gefangen, bevor die Marke stand** |
+| **Auflösung** | 🟢 **Abschnitt 4.1 Schritt 4 nennt die Freigabezeile jetzt als Pflichtbestandteil der Markennachricht**, und `FW-CL-11` nennt die Marke als ihren Ort. 🆕 **`K-111`** führt die Frage weiter, ob das der richtige Ort ist |
+| **Grenze, benannt** | ⚠️ **Keine Prüfung kann den Markentext erreichen.** Er liegt im Tag-Objekt, nicht im Arbeitsbaum, und in einer Installation gibt es ihn nicht (D-299) – dieselbe Lage wie beim Archiv und bei den Erzeugnissen (`K-110`) |
+
+---
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** – E1 bis E7 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Der Schuldposten ist zweimal in zwei Releases aufgetreten, und der Vorbedingungsdurchgang hat ihn an einer **dritten** Stelle gemessen: in den ausgelieferten Kopien. Ein Verfahrensschritt allein hat in diesem Projekt gemessen eine Halbwertszeit von einem Release (D-326) |
+| Ziel-Release | `1.1.0` |
+| Decision-Log-Eintrag | **D-329** bis **D-334**, `K-110` und `K-111` neu |
+
+⚠️ **Zur Einstufung, und sie ist im Durchgang gefallen.** Der Posten wurde als **PATCH**
+vorgelegt – *Korrektur am Verfahren*. Gemessen an Abschnitt 1 trägt das nur ohne E3:
+**Prüfung 82 ist eine neue Regel**, keine Formulierung, und ein übernehmendes Projekt
+bekommt mit ihr eine neue Fehlermöglichkeit im Validator. ➡️ ***Eine Einstufung gilt so
+weit wie ihr Gegenstand*** – der Gegenstand der Vorlage war die Checkliste, nicht der
+Prüfapparat. **Das ist D-328 an der eigenen Vorlage**, und es ist die erste Anwendung des
+Versionierungsregimes, das `1.0.0` wieder in Kraft gesetzt hat.
+
+## 7. Umsetzung
+
+- [x] `RELEASE_PROCESS.md` Abschnitt 4.1: Heben als Schritt 1, Bau der Erzeugnisse als eigener Schritt, Reihenfolge ausdrücklich (Version `0.2.1` → `0.3.0`)
+- [x] `checklists/11-framework-release.md`: Prüfpunkt 20 geteilt (Version `0.3.0` → `0.4.0`)
+- [x] `governance/ADOPTION_REGISTRY.md`: offene Frage geschlossen, Verfahren benannt (Version `0.1.1` → `0.2.0`)
+- [x] **Prüfung 82** im Validator, mit Registereintrag im Kopfkommentar
+- [x] **Sonden 82a bis 82c und Gegenprobe 82a** in `probe-pruefungen.py`
+- [x] Decision Log: **D-329** bis **D-332**, `K-110`
+- [x] **Beide übernehmenden Projekte gehoben – VOR dem Release-Commit**, als erste Anwendung von D-330
+- [x] Validator ohne Fehler; Sondenlauf in **beiden** Kodierungsumgebungen
+- [x] Hauptdokument und Word-Fassung für **beide** Client Packs gebaut und im Erzeugnis nachgezählt
+- [x] `CHANGELOG.md`, `docs/ROADMAP.md`, `build/doc/00-kopf.md`, `UEBERGABE.md`

package/.koolie/core/governance/change-requests/CR-2026-131-chronik-und-vorlage.md

@@ -0,0 +1,194 @@
+# Änderungsantrag `CR-2026-131`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Chronik, die ihr eigenes Release nicht zu Ende zählt – und eine Vorlage, die nur durch ihre Unvollständigkeit ungeprüft bleibt |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-23 |
+| Betroffene Artefakte | `.koolie/core/tests/scripts/validate-framework.py` (**Prüfung 83**, **Prüfung 84**); `.koolie/core/tests/scripts/probe-pruefungen.py`; `.koolie/core/docs/ROADMAP.md`; `.koolie/core/clients/README.md` (Abschnitt 5); `.koolie/core/clients/_template/`; `.koolie/core/governance/DECISION_LOG.md` (**D-335** bis **D-340**, `K-112`, `K-113`); `.koolie/core/tests/TEST_CATALOG.md`; `.koolie/core/VERSION`; `.koolie/core/CHANGELOG.md`; `UEBERGABE.md` |
+| Ebene laut Entscheidungsbaum 6 | Governance |
+| Art | **Änderung.** MINOR-Release nach `RELEASE_PROCESS.md` Abschnitt 1 – zwei neue Prüfungen sind zwei neue Regeln, keine Formulierung |
+| Dringlichkeit | regulär – **E2 ist Vorbedingung des nächsten Postens** und schnappt sonst mitten im Lauf zu |
+| Status | 🟢 **entschieden am 2026-09-23** (E1 bis E5) |
+
+---
+
+## 1. Anlass
+
+**Der Vorbedingungsdurchgang vor dem Posten `openai-codex`** – zum zwanzigsten Mal in
+Folge der billigste Befund eines Releases. Elf Punkte gemessen, fünf grün, drei rot, drei
+mit Vermerk. Die drei roten hängen an zwei Gegenständen, und beide liegen **vor** dem
+eigentlichen Posten:
+
+1. Die Chronik des Repositoriums zählt das eigene Release nicht zu Ende.
+2. Die Vorlage, aus der das nächste Client Pack entstehen soll, ist vor dem Prüfapparat
+   allein durch ihre Unvollständigkeit geschützt.
+
+🟢 **Ein Befund ist dabei ausgeblieben, und das ist berichtenswert:** Die Tabelle
+*Nächste freie Kennungen* stimmt – zum ersten Mal seit vier Releases, nachgezählt über
+alle fünf Gattungen. Sie stand in `1.1.0`, `1.0.0` und `0.80.0` falsch.
+
+## 2. Der erste Befund – gemessen, nicht gelesen
+
+`docs/ROADMAP.md` führt je Release eine Zeile mit der **Spanne** der Entscheidungen, die
+es vergeben hat. Über vierzehn Releases mit Spannenschreibweise ist sie lückenlos:
+
+| Release | Spanne laut ROADMAP | vergeben laut Register |
+|---|---|---|
+| `0.90.0` | `D-313` bis `D-318` | sechs ✅ |
+| `1.0.0` | `D-320` bis `D-327` | acht ✅ |
+| `1.0.1` | `D-328` | eine ✅ |
+| **`1.1.0`** | 🔴 **`D-329` bis `D-332`** | 🔴 **`D-329` bis `D-334` – sechs** |
+
+**Das Register ist lückenlos:** 334 Zeilen bis `D-334`, keine Lücke. Die
+Obergrenze der letzten Spanne ist um **zwei** zu niedrig.
+
+### 2.1 Die Ursache ist gemessen und steht im eigenen Release
+
+`D-333` und `D-334` sind **beim Umsetzen** gefallen – die Übergabe zu `1.1.0` sagt es
+wörtlich: *„Zwei Befunde fielen erst beim Umsetzen, und der erste ist der schwerste des
+Releases."* `K-111` fiel noch später, **beim Setzen der Marke**. Die ROADMAP-Zeile war zu
+diesem Zeitpunkt längst geschrieben.
+
+➡️ ***Eine Zahl, die vor ihrem Gegenstand geschrieben wird, ist zum Zeitpunkt ihrer
+Niederschrift richtig und danach nicht mehr.*** Das ist die Bauform von Prüfung 40 – hier
+**innerhalb eines einzigen Releases** statt über zweiundvierzig.
+
+### 2.2 Der schwerere Teil: kein beschreibender Träger nennt alle sechs
+
+Vier Träger beschreiben `1.1.0`. Gemessen über die wörtlichen Nennungen:
+
+| Träger | genannte Entscheidungen | fehlt |
+|---|---|---|
+| `docs/ROADMAP.md` | 4 (als Spanne `D-329`–`D-332`) | `D-333`, `D-334` |
+| `CHANGELOG.md` | 5 | 🔴 **`D-333`** |
+| `CR-2026-130` | 4 | `D-331`, `D-333` |
+| Protokoll | 4 | `D-329`, `D-332` |
+| 🟢 **Marke `v1.1.0`** | 🟢 **alle sechs** (*„D-329 bis D-334"*) | – |
+
+🔴 **`D-333` steht in keinem der vier.** Es steht im Register, im Protokoll und in den
+**beiden normativen Trägern, die es geändert hat** (`RELEASE_PROCESS.md`,
+`checklists/11-framework-release.md`) – also dort, wo es **wirkt**, und nirgends dort, wo
+das Release **erklärt** wird. Wer die Chronik liest, findet die Regel nicht, die sein
+eigenes Release eingeführt hat. Und `D-333` ist die Entscheidung, die den **schwersten**
+Befund von `1.1.0` behoben hat.
+
+➡️ ***Der einzige Träger, der die Menge vollständig nennt, ist der, den keine Prüfung
+erreichen kann.*** Der Markentext liegt im Tag-Objekt, nicht im Arbeitsbaum, und in einer
+Installation gibt es ihn nicht – das ist genau die Grenze, die `K-111` benennt.
+
+### 2.3 Warum Prüfung 58 es nicht fängt
+
+Prüfung 58 (D-169) hält die Vollständigkeit des Registers: **jede genannte Kennung steht
+im Register.** Der Befund hier ist die **Gegenrichtung**: eine vergebene Kennung wird
+nirgends genannt.
+
+➡️ ***Prüfung 58 fängt die verwaiste Nennung, nicht die verwaiste Kennung.*** Die
+Richtung ist einseitig, und die fehlende Richtung ist die, die die Chronik unvollständig
+läßt. Das ist keine Lücke in Prüfung 58 – sie hat einen anderen Gegenstand –, sondern
+eine Prüfung, die es nicht gibt.
+
+## 3. Der zweite Befund – teurer, und er lag auf dem Weg des nächsten Postens
+
+`clients/README.md` Abschnitt 5 beschreibt in neun Schritten, wie ein Client Pack
+entsteht. **Schritt 1:** *„`_template/` nach `<client-name>/` kopieren und alle
+Platzhalter ersetzen."* **Schritt 5:** *„`manifest.json` anlegen"* – und Abschnitt 3
+sagt: *„Ohne Manifest ist ein Pack nicht installierbar."*
+
+### 3.1 Die Vorlage trägt ein Drittel
+
+| Bestandteil laut Abschnitt 3 | `_template/` | `claude-code/` | `devin-desktop/` |
+|---|---|---|---|
+| `CLIENT_PACK.md` | 🟢 ja (31 Matrixzeilen) | 🟢 ja | 🟢 ja |
+| `manifest.json` | 🔴 **fehlt** | 🟢 ja | 🟢 ja |
+| `root-template/` | 🔴 **fehlt** | 🟢 ja | 🟢 ja |
+
+Schritt 1 sagt *„kopieren"* und liefert **eines von drei** Bestandteilen. Das allein wäre
+ein Mangel der Anleitung. Der Befund ist der nächste Schritt.
+
+### 3.2 Die Vorlage steht in der Packmenge des Prüfapparats – gemessen
+
+`_client_packs()` in `validate-framework.py` nimmt jedes Verzeichnis unter `clients/` auf,
+das eine `CLIENT_PACK.md` trägt. **`_template` erfüllt das.** Der Docstring der Funktion
+hält die Annahme fest, die sie trägt:
+
+> *„(Kennung, Verzeichnis, Manifest) je Client Pack; **`_template` ohne Manifest**."*
+
+**Gemessen am 2026-09-23** – ein Probemanifest angelegt (eine Kopie des Manifests von
+`claude-code`, also ein Manifest, das einen **fremden** Client beschreibt), Validator
+gefahren, Probemanifest wieder entfernt:
+
+| Messung | vorher | mit Probemanifest |
+|---|---|---|
+| `_client_packs()` | `_template`, `claude-code`, `devin-desktop` | unverändert **drei** |
+| davon **mit Manifest** | `claude-code`, `devin-desktop` | 🔴 **`_template`, `claude-code`, `devin-desktop`** |
+| `_p65_packkennungen()` | 🔴 **führt `_template` bereits heute** | unverändert |
+| Validator | 0 Fehler, 0 Warnungen | 🔴 **0 Fehler, 0 Warnungen** |
+
+🔴 **Der Validator meldet null.** Ein Verzeichnis namens `_template` mit einem Manifest,
+das `claude-code` beschreibt, läuft als drittes Client Pack durch alle 82 Prüfungen.
+
+### 3.3 Was der Befund wirklich ist
+
+➡️ ***Eine Vorlage, die nur deshalb keine Prüfung auslöst, weil ihr ein Bestandteil
+fehlt, ist nicht ausgenommen – sie ist unvollständig.*** Und der Tag, an dem jemand sie
+nach der eigenen Anleitung vervollständigt, ist der Tag, an dem sie geprüft wird, ohne
+daß es jemand entschieden hat.
+
+🔴 **Das ist die Bauform *„Zwei Stellen, die einander decken"*** (`0.57.0`): Die
+unvollständige Vorlage verhindert, daß die fehlende Ausnahme je auffällt. **Einzeln wäre
+jede aufgefallen; zusammen sehen sie aus wie ein Lauf ohne Befund** – und genau so hat
+der Validator 82 Prüfungen lang ausgesehen.
+
+⚠️ **Und die Ausnahme existiert bereits – an zwei anderen Stellen.** Prüfung 73 schließt
+`_template` ausdrücklich aus (`if n != "_template"`), und die Pfadausnahmen führen
+`.koolie/core/clients/_template/` mit Begründung. **Der zentrale Iterator tut es nicht.**
+➡️ *Wer eine Ausnahme an zwei Stellen führt und an der dritten vergißt, hat sie nicht
+vergessen – er hat keine Stelle, an der sie steht.*
+
+## 4. Vorlage zur Entscheidung
+
+| # | Frage | Auflösung | Preis |
+|---|---|---|---|
+| **E1** | Bekommt die Chronik eine Prüfung – und welche Form? | **Prüfung 83:** Die Obergrenze der letzten Release-Spanne in `docs/ROADMAP.md` ist die höchste vergebene `D`-Kennung des Registers. Abweichung ist ein **Fehler** | ⚠️ **Jedes Release faßt diese Zeile an** – derselbe Preis wie bei Prüfung 67, 77 und 82. ⚠️ **Grenze, benannt: sie mißt die OBERGRENZE, nicht die Vollständigkeit der Nennungen.** Ein Träger, der die Spanne richtig führt und `D-333` im Fließtext nicht nennt, kommt durch |
+| **E2** | Wird die Vorlage vervollständigt oder ausgenommen? | **Ausgenommen, und zwar dort, wo die Packmenge entsteht.** `_client_packs()` nimmt `_template` nicht mehr auf; **Prüfung 84** hält die Ausnahme fest und meldet, wenn die Vorlage Bestandteile eines vollständigen Packs trägt | ⚠️ Die Vorlage bleibt bei einem Bestandteil – **Schritt 1 der Anleitung wird deshalb umformuliert**, statt ein Drittel als Ganzes auszugeben. 🔴 **Der Gegenvorschlag (vervollständigen) ist abgelehnt:** Eine vollständige Vorlage wäre ein Pack ohne Client, und jede Prüfung müßte sie einzeln ausnehmen – die Ausnahme wanderte von einer Stelle auf achtzig |
+| **E3** | Werden die beiden Chronikbefunde berichtigt? | **Ja.** ROADMAP-Zeile `1.1.0` auf `D-329` bis **`D-334`**, `K-110` **und** `K-111`; `1.0.1` und `1.0.0` in die richtige Reihenfolge | 🟢 **Kein Verstoß gegen D-273:** Berichtigt wird eine **Zahl**, die ihren Gegenstand falsch benennt, nicht ein Stand, der historisch gilt |
+| **E4** | Wird `D-333` in einem beschreibenden Träger nachgetragen? | **Ja, im `CHANGELOG.md` von `1.1.0`.** Nachgetragen wird, was Register und Protokoll bereits festhalten; der Eintrag sagt in einem eigenen Satz, daß er ein Nachtrag ist | ⚠️ **Prüfung 83 erreicht es nicht** (siehe E1). Der Nachtrag ist eine Handlung, keine Regel – `K-112` führt die Frage weiter |
+| **E5** | Einstufung und Lage im Releaseplan | **MINOR.** Zwei neue Prüfungen sind zwei neue Regeln. 🔴 **Der Releaseplan rückt um eins:** `openai-codex` von `1.2.0` auf `1.3.0`, Overlay *„General Development"* auf `1.4.0`, Installationsbibliothek auf `1.5.0` | ⚠️ **Eine Planzahl wird verschoben, und das wird ausgewiesen statt stillschweigend getan.** 🟢 Das Muster ist erprobt: `0.81.0` Vorbedingungen → `0.82.0` Herrichtung → `0.83.0` Meßtag – drei Nummern für einen Posten |
+
+## 5. Umsetzung
+
+1. **Prüfung 83** in `validate-framework.py`, mit drei Sonden und **zwei** Gegenproben in
+   `probe-pruefungen.py`. Die zweite Gegenprobe: ein Release **ohne** Spannenschreibweise
+   (ein einzelner Decision Record, wie `1.0.1`) muß **grün** sein.
+2. **Prüfung 84** ebenso. `_client_packs()` schließt `_template` aus; die Ausnahme steht
+   **an einer Stelle** und trägt ihre Begründung im Quelltext.
+3. `docs/ROADMAP.md`: Zeile `1.1.0` berichtigt, `1.0.0`/`1.0.1` in Reihenfolge, Planzeilen
+   gerückt, Standüberschrift auf `1.2.0`.
+4. `clients/README.md` Abschnitt 5 Schritt 1 umformuliert; Abschnitt 3 nennt den Umfang
+   der Vorlage ausdrücklich.
+5. `CHANGELOG.md`: Nachtrag `D-333` bei `1.1.0`, neuer Abschnitt `1.2.0`.
+6. `DECISION_LOG.md`: **D-335** bis **D-340**, `K-112` und `K-113`.
+7. `TEST_CATALOG.md`: Prüfung 83 und 84 eingetragen.
+8. 🔴 **Beide neuen Prüfungen laufen gegen BEIDE übernehmenden Projekte, bevor sie als
+   fertig gelten** (D-326, D-299) – die Lehre, die `0.90.0` notiert und nicht angewandt
+   hat.
+9. Validator und Sondenlauf in **beiden** Kodierungsumgebungen (D-49).
+10. Heben der übernehmenden Projekte **vor** dem Release-Commit (D-330), als **letzter**
+    Eingriff in den Kern (D-333).
+
+## 6. Entscheidung
+
+🟢 **Angenommen am 2026-09-23, E1 bis E5 wie vorgelegt.**
+
+| # | Entscheidung | Decision Record |
+|---|---|---|
+| E1 | Prüfung 83 – die Spanne der Chronik gegen das Register | **D-335** |
+| E2 | Die Vorlage wird ausgenommen, nicht vervollständigt – Prüfung 84 | **D-336** |
+| E3 | Die beiden Chronikbefunde werden berichtigt | **D-337** |
+| E4 | `D-333` wird im `CHANGELOG.md` nachgetragen | **D-338** |
+| E5 | MINOR; der Releaseplan rückt um eins | **D-339** |
+
+Neue Klärungspunkte: `K-112` (erreicht eine Prüfung die **Nennungen**, nicht nur die
+Spanne?), `K-113` (die Marke ist der vollständigste Träger und der einzige ungeprüfte –
+gehört ihr Text in den Arbeitsbaum?).

package/.koolie/core/governance/change-requests/CR-2026-132-erhebung-openai-codex.md

@@ -0,0 +1,185 @@
+# Änderungsantrag `CR-2026-132`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Erhebung zu `openai-codex` – der Client, dessen Wurzelanweisung eine Datei daneben ersetzt |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-23 |
+| Betroffene Artefakte | `.koolie/core/tests/scripts/validate-framework.py` (**Prüfung 85**); `.koolie/core/tests/scripts/probe-pruefungen.py`; `.koolie/core/docs/ROADMAP.md`; `.koolie/core/governance/RELEASE_PROCESS.md` (Abschnitt 4.1 Schritt 2); `.koolie/core/checklists/11-framework-release.md`; `.koolie/core/governance/DECISION_LOG.md` (**D-341** bis **D-345**, `K-115`, `K-116`); `.koolie/core/tests/TEST_CATALOG.md`; `.koolie/core/VERSION`; `.koolie/core/CHANGELOG.md`; `.koolie/core/governance/ADOPTION_REGISTRY.md`; `UEBERGABE.md` |
+| Ebene laut Entscheidungsbaum 6 | Governance |
+| Art | **Änderung.** MINOR-Release nach `RELEASE_PROCESS.md` Abschnitt 1 – eine neue Prüfung ist eine neue Regel, und Abschnitt 4.1 bekommt einen Handgriff |
+| Dringlichkeit | regulär – **die Erhebung ist Vorbedingung des Packbaus**, und drei ihrer Befunde ändern dessen Bauform |
+| Status | 🟢 **entschieden am 2026-09-23** (E1 bis E5) |
+
+---
+
+## 1. Anlass
+
+**Der Vorbedingungsdurchgang vor dem Posten `openai-codex`** – zum **einundzwanzigsten**
+Mal in Folge der billigste Befund eines Releases. Und danach die **Erhebung** selbst:
+die Schritte 2, 6 und 7 aus `clients/README.md` Abschnitt 5, die drei Erhebungen sind
+und vor dem ersten geschriebenen Trägerbyte stehen.
+
+🔴 **Sie hat den Posten umgeworfen.** Drei der zehn Befunde ändern die **Bauform** des
+Packs, nicht seinen Inhalt – und ein Pack, das vor dieser Entscheidung gebaut wird, wird
+zweimal gebaut.
+
+🟢 **Und sie hat ihn zugleich billiger gemacht:** `codex debug prompt-input` rendert
+genau das, was das Modell zu sehen bekommt, **ohne eine Sitzung zu eröffnen**. Die
+gesamte Erhebung dieses Releases – zehn Messungen, sechs davon mit Gegenprobe – hat
+**null Kontingent** gekostet.
+
+## 2. Der Vorbedingungsdurchgang
+
+| # | Befund | gemessen an |
+|---|---|---|
+| **V1** | 🟢 Die Tabelle *Nächste freie Kennungen* stimmt – **zum zweiten Mal in Folge** | `CR-2026-132`, `D-341`, `K-115`, `G-21`, `UEB-32` über alle fünf Gattungen nachgezählt: 340 `D`-Zeilen bis `D-340`, 112 `K`-Zeilen bis `K-114` |
+| **V2** | 🟢 Das Codex-Konto ist `plus` – die Berichtigung aus `1.1.0` hält | `id_token`, Feld `chatgpt_plan_type` |
+| **V3** | 🟢 **Die geprüfte Clientversion ist VOR dem Erheben festgeschrieben: `0.156.1`** (D-117, D-202). Der Owner hat während der Sitzung von `1.2.0` von `0.155.1` gehoben | `codex --version`, `codex doctor` |
+| **V4** | 🔴 **Die Word-Fassung steht auf `v1.1.0`, `VERSION` auf `1.2.0`** – Schritt 3 von Abschnitt 4.1 ist bei `1.2.0` **nicht ausgeführt** worden. **Dritter Preis von `K-110` in vier Releases** | `build/out/` führt `Koolie_v1.1.0_*.docx` und keine Fassung `v1.2.0` |
+| **V5** | 🟢 Die Bestandsliste steht in **allen drei** Trägern byte-gleich auf `1.2.0`, und **beide** übernehmenden Projekte tragen die Hebung als Commit | `cmp` über drei Kopien; `git log` in beiden Projekten |
+| **V6** | 🟢 **Die Nennungen von `1.2.0` sind vollständig – und zwar in ZWEI beschreibenden Trägern**, `CHANGELOG.md` und dem Antrag. `K-112` hat seinen ersten Fall **nicht** gebracht | `D-335` bis `D-340` je Träger gezählt |
+| **V7** | ⚠️ `~/.codex/config.toml` führt weiter einen Vertrauenseintrag auf den **alten** Projektnamen – **und einen auf das Benutzerprofil selbst**, der jeden Pfad darunter einschließt. Rest der Umbenennung, und ein Befund dazu | gelesen |
+| **V8** | 🔴 **Drei `Geplant`-Abschnitte in `docs/ROADMAP.md` nennen ein Ziel-Release, das die Gegenwart überholt hat** – `~0.68.0` (erledigt mit `0.88.0`), `1.1.0` (steht in der Releasetabelle derselben Datei auf `1.3.0`) und `1.2.0` (ausgeliefert, Posten nicht gefahren) | gezählt; Abschnitt 4 |
+| **V9** | 🟢 Validator `0 Fehler, 0 Warnungen` über **84** Prüfungen; Arbeitsbaum sauber, kein offener Antrag, kein Restbranch | `validate-framework.py`, `git` |
+
+🔴 **Keine Prüfung erreichte V7 oder V8.** 🔴 **Und V4 war ein Meßfehler des Durchgangs selbst** – siehe Abschnitt 5.
+
+## 3. Die Erhebung – zehn Messungen am Prompt-Eingang
+
+**Das Meßmittel ist neu und kostet nichts.** `codex debug prompt-input` gibt die
+Entwickler- und Nutzernachrichten aus, die der Client der nächsten Anfrage voranstellt –
+ohne eine Anfrage zu stellen. Das ist bei diesem Client die Entsprechung der Mitschrift,
+mit der `0.86.0` das Pack `devin-desktop` gemessen hat, **und sie ist billiger:** die
+Mitschrift entsteht aus einem Lauf, dieser Ausdruck aus keinem.
+
+🔴 **Für die Isolation trägt ein eigenes `CODEX_HOME` im Ablagebereich.** Keine Messung
+dieses Abschnitts hat die Konfiguration des Arbeitsplatzes angefaßt – die
+Vertrauenseinträge, an denen die Hälfte der Befunde hängt, sind in einem zweiten,
+wegwerfbaren Benutzerverzeichnis gesetzt und wieder gefallen.
+
+| # | Befund | Beleg |
+|---|---|---|
+| **E1** | 🔴 **`AGENTS.override.md` verdrängt `AGENTS.md` VOLLSTÄNDIG.** Liegt die Datei im Projekt, steht die Wurzel-Anweisung des Frameworks in **keiner** Nachricht der Sitzung | Sonde und **Gegenprobe**: mit Overlaydatei trägt der Prompt `SONDE-OVERRIDE` und nicht `SONDE-AGENTS-ROOT`; ohne sie genau umgekehrt |
+| **E2** | 🔴 **Die gesamte projektlokale Schicht lädt nur bei eingetragenem Vertrauen.** `.codex/config.toml`, Hooks und Exec-Policies bleiben ohne einen `trust_level`-Eintrag in der **Benutzer**konfiguration wirkungslos | A/B mit zwei Benutzerverzeichnissen, identisches Projekt: mit Eintrag greift das Projektmodell, ohne Eintrag der Benutzerstandard |
+| **E3** | 🔴 **Und sie kann LOCKERN.** `approval_policy = "never"` und `sandbox_mode = "danger-full-access"` im Projekt schlagen den Benutzerstandard – gemessen: `approval policy Never`, `filesystem sandbox unrestricted` | derselbe A/B-Lauf, `codex doctor` |
+| **E4** | 🔴 **Die Pfadrechteschicht kennt KEINE Muster.** Die Schlüssel sind Pfade und müssen absolut sein, mit `~/` beginnen oder ein Sonderziel sein (Projektwurzel, Arbeitsbereich, Temporärverzeichnis) | Abweisung: *filesystem path … must be absolute, use `~/…`, or start with `:`* |
+| **E5** | 🔴 **Auf diesem Arbeitsplatz kann der Sandkasten `deny`-Leserechte GAR NICHT durchsetzen – und der Client läuft dann nicht** | Abweisung: *windows unelevated restricted-token sandbox cannot enforce deny-read restrictions directly; refusing to run unsandboxed* |
+| **E6** | 🔴 **Hooks tragen ein Vertrauensmodell über einen HASH**, und es gibt einen Schalter, der es übergeht (`--dangerously-bypass-hook-trust`) | Konfigurationsschema aus dem Binär; Befehlszeilenhilfe |
+| **E7** | ⚠️ **Das Benutzerverzeichnis des Clients führt eine eigene `AGENTS.md`** – eine Anweisungsquelle außerhalb des Projekts, die in jede Sitzung lädt | Sonde `SONDE-GLOBAL-AGENTS-MD` im Prompt |
+| **E8** | 🟢 **Skills laden projektlokal aus zwei Ablagen** (`.codex/skills/` und `.agents/skills/`); eine dritte, naheliegende (`skills/` an der Projektwurzel) **nicht**. Die Menge ist **mit Herkunft vollständig aufzählbar** – der Prompt führt eine Tabelle der Skillwurzeln | drei Sonden an drei Orten, eine davon negativ |
+| **E9** | ⚠️ **Regeldateien mit Ladebedingungen gibt es nicht.** Der Client kennt eine Anweisungsdatei je Verzeichnisbaum; eine Datei im Unterverzeichnis steht **nicht** vorab im Kontext | Sonde `SONDE-NESTED-AGENTS` fehlt im Prompt |
+| **E10** | 🟢 **Ein projektlokal nicht unterstützter Schlüssel wird BENANNT**, nicht verschwiegen | Startmeldung: *Ignored unsupported project-local config keys … : notify* |
+
+### 3.1 Was daraus für die Fähigkeitsmatrix folgt
+
+| Zeile | Lage nach der Erhebung |
+|---|---|
+| **R1** (Wurzel-Anweisung wird ungefragt geladen) | 🔴 **Bedingt.** Eine Datei daneben hebt sie auf (E1). ➡️ *Eine Wurzel-Anweisung, die eine ungeprüfte Datei im selben Verzeichnis ersetzen kann, ist keine Ebene 1 – sie ist ein Standard.* |
+| **B1** (Berechtigungen liegen versioniert im Repositorium) | 🔴 **Bedingt.** Die Datei liegt versioniert im Projekt und **lädt nur, wenn der Arbeitsplatz das Projekt vertraut** (E2) |
+| **B3** (Lesezugriff auf Secret-Dateien per **Pfadmuster** verweigerbar) | 🔴 **In seiner Musterform nicht abbildbar** (E4) – und auf diesem Betriebssystem im gegebenen Sandkastenmodus **gar nicht** (E5). **B3 ist eine Kernzusage**, damit greift `clients/README.md` Abschnitt 4: Begründung im Pack, Ausnahme im Overlay, Freigabe durch `<SECURITY_CONTACT>` |
+| **B9** (nutzerlokale Konfiguration kann nur verschärfen) | 🔴 **Spiegelbild gemessen:** Hier lockert die **projektlokale** Konfiguration den **Benutzer**standard (E3) |
+| **H1/H2** (Prüfung vor dem Werkzeugaufruf, blockierend) | ⚠️ **Vorhanden und bedingt.** Der Mechanismus blockiert, **aber ein nicht vertrauter Hook läuft nicht** (E6) – und jede Hebung des Frameworks ändert den Hash. *Ein Schutz-Hook, der nicht läuft, blockiert nichts* (AP2-CC-13) |
+| **R2/R3** (Ladebedingungen, Bindung an Dateimuster) | ⚠️ **Andere Gestalt** (E9): Geltungsbereich ist der Verzeichnisbaum, nicht ein Muster |
+| **S5** (Skills vollständig aufzählbar samt Herkunft) | 🟢 **Gemessen erfüllt** (E8) |
+
+## 4. Der Befund am eigenen Plan (V8)
+
+`docs/ROADMAP.md` führt drei Abschnitte der Form
+`### Geplant: <Posten> – Ziel-Release <Version>`. **Alle drei nennen eine Version, die
+`VERSION` erreicht oder überschritten hat:**
+
+| Abschnitt | Ziel-Release laut Überschrift | Wirklichkeit |
+|---|---|---|
+| Die Umbenennung auf `Koolie` | `~0.68.0` | 🔴 **erledigt mit `0.88.0`** – der Abschnitt heißt seit **fünfzehn** Releases *„Geplant"* |
+| Client Pack `openai-codex` | `1.1.0` | 🔴 **Die Releasetabelle derselben Datei führt ihn auf `1.3.0`** – zwei Stellen, rund 1.280 Zeilen auseinander, mit verschiedenen Zahlen |
+| Projekt-Overlays als Installationsparameter | `1.2.0` | 🔴 **`1.2.0` ist ausgeliefert, der Posten nicht gefahren** |
+
+➡️ ***Eine Zielangabe ist eine Zahl, die vor ihrem Gegenstand geschrieben wird*** – die
+Bauform von Prüfung 83, hier an der **Planseite** derselben Datei statt an der
+Chronikseite. 🔴 **Und die Verschiebungen sind je einzeln ausgewiesen worden** (D-127,
+D-339); **keine von ihnen hat die Überschrift angefaßt**, weil die Releasetabelle als
+der eine Ort galt. *Wer eine Zahl an zwei Stellen führt, pflegt eine.*
+
+## 5. Der Befund, den es nicht gab – und warum er trotzdem hier steht (V4)
+
+🔴 **Der erste Anlauf dieses Durchgangs hat gemeldet, die Word-Fassung stehe auf
+`v1.1.0`, während `VERSION` auf `1.2.0` stand.** Daraus wurde ein dritter Preis für
+`K-110` abgeleitet, und daraus ein Decision Record.
+
+🟢 **Es war falsch.** `build/out/` führt `Koolie_v1.2.0_claude-code.docx` und
+`Koolie_v1.2.0_devin-desktop.docx`; Schritt 3 von Abschnitt 4.1 ist bei `1.2.0`
+**ausgeführt worden**.
+
+🔴 **Die Ursache ist gemessen: Die Verzeichnisliste war auf zehn Zeilen beschnitten**,
+und die beiden Träger standen auf Zeile elf und zwölf. Die Liste war nicht falsch – sie
+war **kürzer als ihr Gegenstand**, und die Abwesenheit einer Zeile wurde als Abwesenheit
+einer Datei gelesen.
+
+➡️ ***Eine Messung, die ihre Ausgabe beschneidet, mißt die Beschneidung.***
+➡️ ***Ein Vorhandensein belegt sich selbst, ein Fehlen nicht*** – derselbe Satz, den
+dieser Antrag in Abschnitt 3 als **Stärke** des neuen Meßmittels führt, hat hier gegen
+die eigene Messung gearbeitet.
+
+🟢 **Gefunden hat es der Bau selbst.** Erst als Schritt 3 dieses Releases die
+Erzeugnisse schrieb, stand die vollständige Liste da. ➡️ ***Der Vorgang findet, was
+seine Beschreibung übersieht.***
+
+🔴 **Der Befund bleibt gebucht, statt gestrichen zu werden.** D-305 hat denselben Fall
+schon einmal aufgenommen – dort hatte D-301 *„einen Verlust gebucht, den es nicht
+gab"* –, und genau diese Buchungen sind der Grund, warum dieses Repositorium seine
+Fehlerarten kennt. 🟢 **Was sachlich bleibt:** `K-110` ist **nicht** ein drittes Mal
+angefallen; der Verfahrensschritt aus D-332 hat mit `1.2.0` gehalten.
+
+## 6. Vorlage zur Entscheidung
+
+| # | Frage | Auflösung | Preis |
+|---|---|---|---|
+| **E1** | Wird das Pack in diesem Release gebaut – oder erst die Erhebung gebucht? | 🔴 **Erst die Erhebung.** `1.3.0` ist der **Erhebungsdurchgang**, der Bau rückt auf `1.4.0`. **Drei der zehn Befunde ändern die Bauform des Packs** – die musterlose Pfadrechteschicht (E4), das Vertrauensmodell über der ganzen projektlokalen Schicht (E2/E6) und die verdrängbare Wurzel-Anweisung (E1). Ein Pack, das davor entsteht, entsteht zweimal | ⚠️ **Der Releaseplan rückt zum ZWEITEN Mal in Folge um eins** – Overlay auf `1.5.0`, Installationsbibliothek auf `1.6.0`. **Ausgewiesen statt stillschweigend**, wie D-339. 🟢 **Das Muster ist erprobt:** `0.81.0` Vorbedingungen → `0.82.0` Herrichtung → `0.83.0` Meßtag – drei Nummern für einen Posten |
+| **E2** | Bekommt der Befund am eigenen Plan (V8) eine Prüfung? | **Prüfung 85:** Jede Überschrift eines `Geplant`-Abschnitts in `docs/ROADMAP.md`, die ein Ziel-Release nennt, wird gegen `VERSION` gehalten. Nennt sie eine Version, die erreicht oder überschritten ist, ist das ein **Fehler**. Und die drei vorgefundenen Abschnitte werden berichtigt | ⚠️ **Grenze, benannt: sie mißt die ZIELANGABE, nicht den Stand des Postens.** Ein Abschnitt, dessen Ziel in der Zukunft liegt, kann längst erledigt sein und kommt durch – dieselbe Bauform wie Prüfung 77 (*Version, nicht Inhalt*) und 82 (*Behauptung, nicht Tatsache*); `K-116` führt die Frage weiter. ⚠️ **Preis:** Wer einen Posten verschiebt, faßt die Überschrift an – und genau das ist der Zweck |
+| **E3** | `K-115` ins Register – und die Antwort auf seine drei Fragen? | **Ja, und Abschnitt 4.1 Schritt 2 bekommt den fünften Handgriff: im übernehmenden Projekt committen.** Frage (1) *ja*; Frage (2) *nein* – der Git-Stand eines Projekts außerhalb des Repositoriums ist für keine Prüfung erreichbar (dieselbe Grenze wie D-331 und D-299); Frage (3) *nein*, die Bestandsliste führt weiter die Version und nicht den Commit: ein Commit-Verweis in einem Träger, den beide Projekte als Kopie tragen, wäre in jeder Kopie ein anderer | ⚠️ **Wieder ein Verfahrensschritt statt einer Prüfung** – und V4 desselben Durchgangs mißt gerade, was das wert ist. 🟢 **Der Unterschied zu V4: dieser Schritt hat seinen Gegenstand IM Repositorium des übernehmenden Projekts und ist dort sichtbar**, während ein nicht gebautes Erzeugnis nirgends fehlt |
+| **E4** | Was folgt aus V4, nachdem er sich als Meßfehler erwiesen hat – streichen oder buchen? | 🔴 **Buchen.** D-345 hält fest, daß die Meldung aus einer **beschnittenen Verzeichnisliste** kam: *Eine Messung, die ihre Ausgabe beschneidet, mißt die Beschneidung.* D-305 hat denselben Fall schon einmal aufgenommen – dort hatte D-301 *„einen Verlust gebucht, den es nicht gab"*. 🟢 **Sachlich bleibt:** `K-110` ist **nicht** ein drittes Mal angefallen, und die Erzeugnisse dieses Releases werden gebaut und im Erzeugnis nachgezählt | ⚠️ **Keine neue Prüfung, und die erste Frage von `K-110` ist trotzdem beantwortet – mit nein:** Eine Prüfung gegen ein Erzeugnis unter `build/out/` wäre im Framework nach dem Bau grün und in jeder Installation rot (D-299). ⚠️ **Die Lehre hat Reichweite über diesen Fall hinaus:** Der Prüfapparat schneidet an vielen Stellen Ausgaben ab – **eine Zählung gehört gezählt, nicht gelistet** |
+| **E5** | Einstufung | **MINOR.** Eine neue Prüfung ist eine neue Regel, und Abschnitt 4.1 bekommt einen Handgriff. **Kein Overlay-Bruch** – kein Träger des Overlays ändert seine Gestalt | – |
+
+## 7. Umsetzung
+
+1. **Prüfung 85** in `validate-framework.py`, mit zwei Sonden und **zwei** Gegenproben in
+   `probe-pruefungen.py`. Die zweite Gegenprobe ist die, die man weglassen würde: eine
+   Zielangabe **in der Zukunft** muß durchlaufen – sonst mißt die Prüfung die
+   Schreibweise und nicht die Sache.
+2. `docs/ROADMAP.md`: die drei `Geplant`-Abschnitte berichtigt, Releasetabelle um `1.3.0`
+   ergänzt und `1.4.0` bis `1.6.0` gerückt, Standüberschrift auf `1.3.0`.
+3. `RELEASE_PROCESS.md` Abschnitt 4.1 Schritt 2: fünfter Handgriff; `checklists/11`
+   ebenso.
+4. `DECISION_LOG.md`: **D-341** bis **D-345**, `K-115` und `K-116`; `K-110` im Zuschnitt
+   verengt.
+5. `TEST_CATALOG.md`: Prüfung 85 eingetragen.
+6. `CHANGELOG.md`, `VERSION`, `ADOPTION_REGISTRY.md`.
+7. Protokoll mit allen zehn Messungen und ihren Gegenproben.
+8. 🔴 **Die Erhebung faßt die Konfiguration des Arbeitsplatzes nicht an** – alle Messungen
+   laufen gegen ein eigenes `CODEX_HOME` im Ablagebereich, und der Ablagebereich wird
+   danach geräumt.
+9. 🔴 **Die Übergabe wird VOR dem Abnahmelauf gehoben** (Falle 1 aus `1.2.0`); nur die
+   Laufzeiten stehen unterhalb der Trennlinie (D-94).
+10. Validator und Sondenlauf in **beiden** Kodierungsumgebungen (D-49); Heben der
+    übernehmenden Projekte **vor** dem Release-Commit (D-330) und als **letzter** Eingriff
+    in den Kern (D-333), **mit Commit dort** (E3).
+
+## 8. Entscheidung
+
+🟢 **Angenommen am 2026-09-23, E1 bis E5 wie vorgelegt.**
+
+| # | Entscheidung | Decision Record |
+|---|---|---|
+| E1 | `1.3.0` ist der Erhebungsdurchgang; der Packbau rückt auf `1.4.0` | **D-341** |
+| E2 | Prüfung 85 – die Zielangabe eines Planabschnitts gegen `VERSION` | **D-342** |
+| E3 | `K-115` beantwortet; Abschnitt 4.1 Schritt 2 bekommt den fünften Handgriff | **D-343** |
+| E4 | Die Erhebung eines Client Packs ist kontingentfrei, solange sie am Prompt-Eingang mißt | **D-344** |
+| E5 | V4 war ein Meßfehler des Durchgangs selbst und wird als solcher gebucht | **D-345** |
+
+Neue Klärungspunkte: `K-115` (im Register, mit Antwort), `K-116` (erreicht eine Prüfung
+den **Stand** eines Planpostens, nicht nur seine Zielangabe?)
+🔴 **Und ein dritter, gefallen beim Heben selbst:** `K-117` – das `.gitignore` von
+`devpacks/otp-generator` verschluckt **42** der 525 ausgelieferten Kerndateien,
+darunter die gesamte Quelle des Hauptdokuments. Gemessen in Schritt 2 dieses
+Releases, drei Fragen vorgelegt, hier nicht entschieden.