@renoxar/koolie 1.25.0

package/.koolie/core/tests/protocols/2026-09-23-chronik-und-vorlage.md

@@ -0,0 +1,224 @@
+# Protokoll: Die Chronik, die ihr eigenes Release nicht zu Ende zählt
+
+| Feld | Inhalt |
+|---|---|
+| Datum | 2026-09-23 |
+| Release | **`1.2.0`** |
+| Änderungsantrag | `CR-2026-131` |
+| Art | **Arbeitsprotokoll.** Gegenstand sind die Chronik des Repositoriums, die Packmenge des Prüfapparats und zwei neue Prüfungen |
+| Prüfmittel | `review` – Auszählung im Bestand; dazu ein **gemessener Eingriff** am Prüfapparat (Probemanifest), der Validator und der volle Sondenlauf in beiden Kodierungsumgebungen |
+| Ergebnis | 🟢 **Zwei Befunde, beide aus dem Vorbedingungsdurchgang, beide mit einer Prüfung beantwortet.** 🔴 **Und eine Lehre aus `0.86.0` ist zugeschnappt, die wörtlich in der Übergabe stand** |
+
+> 🔴 **Dies ist kein Abnahmeprotokoll des Testkatalogs** und trägt deshalb keinen
+> Abschnitt *Gegenzeichnung* (D-319, Zuschnitt von Prüfung 80). Es berichtet eine
+> Messung und trägt seinen Beleg in sich.
+
+---
+
+## 1. Der Anlaß
+
+Der Wiederaufnahmepunkt zu `1.1.0` nennt als nächsten Posten das **Client Pack
+`openai-codex`**. Vor dem ersten Handgriff stand der Vorbedingungsdurchgang – zum
+**zwanzigsten** Mal in Folge, und zum zwanzigsten Mal war er der billigste Befund.
+
+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.**
+
+## 2. Der Vorbedingungsdurchgang
+
+| # | Befund | gemessen an |
+|---|---|---|
+| **V1** | 🟢 Die Tabelle *Nächste freie Kennungen* stimmt – **zum ersten Mal seit vier Releases** | `CR-2026-131`, `D-335`, `K-112`, `G-21`, `UEB-32` über alle fünf Gattungen nachgezählt; sie stand in `1.1.0`, `1.0.0` und `0.80.0` falsch |
+| **V2** | 🟢 Das angemeldete Codex-Konto ist `plus` – die Berichtigung aus `1.1.0` hält | `id_token` des Kontos, Feld `chatgpt_plan_type` |
+| **V3** | 🔴 **Die Release-Spanne von `1.1.0` endete bei `D-332`, vergeben sind `D-329` bis `D-334`** | Register lückenlos, 334 Zeilen; Abschnitt 3 |
+| **V4** | 🔴 **Kein beschreibender Träger nennt alle sechs Entscheidungen** | vier Träger, vier Mengen; Abschnitt 3.2 |
+| **V5** | 🔴 **`_template` steht in der Packmenge des Prüfapparats** | mit Probemanifest gemessen; Abschnitt 4 |
+| **V6** | ⚠️ Codex unverändert `0.155.1`, verfügbar `0.156.1`. **Folgenlos für dieses Release** – der Meßtag ist auf `1.3.0` gerückt, und die geprüfte Clientversion wird nach D-117 und D-202 **vor** dem Erheben festgeschrieben | `codex doctor` |
+| **V7** | ⚠️ `~/.codex/config.toml` führt weiter einen Vertrauenseintrag auf den **alten** Projektnamen und keinen auf den neuen. Rest der Umbenennung, **außerhalb des Repositoriums** | gelesen |
+| **V8** | ⚠️ **`1.0.1` stand in `docs/ROADMAP.md` vor `1.0.0`** – die Tabelle ist über 133 Zeilen monoton aufsteigend und war an genau dieser einen Stelle nicht | gezählt |
+| **V9** | 🟢 Die Bestandsliste steht in **allen drei** Trägern byte-gleich auf `1.1.0` – Prüfung 82 ist überall grün | Framework und beide übernehmenden Projekte |
+| **V10** | 🟢 Die Word-Fassung steht auf `v1.1.0`; D-332 hält | `build/out/` |
+| **V11** | 🟢 Standüberschrift und der Vermerk *„dieses Release"* stehen je **einmal** | gezählt |
+
+🔴 **Keine Prüfung erreichte V3, V4, V5 oder V8.**
+
+## 3. Der erste Befund: die Chronik zählt ihr eigenes Release nicht zu Ende
+
+`docs/ROADMAP.md` führt je Release die **Spanne** seiner Entscheidungen. Über vierzehn
+Releases mit dieser Schreibweise ist sie lückenlos – und genau die letzte war um **zwei**
+zu niedrig.
+
+| 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`** |
+
+**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 –, `K-111` sogar
+erst 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.
+
+### 3.2 Der schwerere Teil
+
+Vier Träger beschreiben `1.1.0`. Gemessen über die wörtlichen Nennungen:
+
+| Träger | genannt | fehlt |
+|---|---|---|
+| `docs/ROADMAP.md` | 4 (als Spanne) | `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-333` steht in keinem der vier.** Es steht im Register, im Protokoll und in den
+**beiden normativen Trägern, die es geändert hat** – also dort, wo es **wirkt**, und
+nirgends dort, wo das Release **erklärt** wird. Und es 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 (`K-113`).
+**Das ist `K-111` an einem zweiten Gegenstand:** dort die Freigabe, hier die
+Entscheidungsmenge.
+
+### 3.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**.
+➡️ ***Prüfung 58 fängt die verwaiste Nennung, nicht die verwaiste Kennung.***
+
+## 4. Der zweite Befund: die Vorlage in der Packmenge – ein gemessener Eingriff
+
+`_client_packs()` nimmt jedes Verzeichnis unter `clients/` auf, das eine
+`CLIENT_PACK.md` trägt. **`_template` erfüllt das.** Der Docstring hielt die Annahme
+fest, die die Funktion trug: *„`_template` ohne Manifest"*.
+
+**Der Eingriff, gefahren am 2026-09-23 und wieder zurückgenommen:** ein Probemanifest in
+`clients/_template/` – eine Kopie des Manifests von `claude-code`, also eines, das einen
+**fremden** Client beschreibt.
+
+| Messung | vorher | mit Probemanifest |
+|---|---|---|
+| `_client_packs()` | `_template`, `claude-code`, `devin-desktop` | unverändert **drei** |
+| davon **mit Manifest** | zwei | 🔴 **drei** |
+| `_p65_packkennungen()` | 🔴 **führt `_template` bereits** | unverändert |
+| Validator | 0 Fehler, 0 Warnungen | 🔴 **0 Fehler, 0 Warnungen** |
+
+➡️ ***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 – `clients/README.md` Schritt 5 verlangt genau
+dieses Manifest –, ist der Tag, an dem sie geprüft wird, ohne daß es jemand entschieden
+hat.
+
+🔴 **Die Bauform *„zwei Stellen, die einander decken"*** (`0.57.0`): Die unvollständige
+Vorlage verhindert, daß die fehlende Ausnahme je auffällt.
+
+⚠️ **Und die Ausnahme existierte bereits an zwei anderen Stellen** – Prüfung 73 und die
+Pfadausnahmen – und nicht dort, wo die Packmenge **entsteht**.
+➡️ *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.*
+
+## 5. Die beiden neuen Prüfungen
+
+| Prüfung | Gegenstand | Einheiten | D-299-Probe |
+|---|---|---|---|
+| **83** | die höchste Release-Spanne gegen die höchste vergebene Kennung | 3 Sonden, 2 Gegenproben | 🟢 **bestanden** – beide Träger liegen im Kern und werden byte-gleich ausgeliefert |
+| **84** | die Vorlage trägt keine Packbestandteile | 3 Sonden, 2 Gegenproben | 🟢 **bestanden** – der Gegenstand liegt im Kern |
+
+🟢 **Prüfung 83 hat bei ihrem ersten Lauf ihren eigenen Anlaß gemeldet** – wie Prüfung 81
+in `1.0.0`.
+
+🔴 **Die zweite Gegenprobe von Prüfung 83 ist die, die man weglassen würde, und sie
+trägt den Zuschnitt.** Die Releasetabelle ist **nicht sortiert** – V8 hat es gemessen.
+Deshalb nimmt die Prüfung die **höchste** Obergrenze und nicht die zuletzt geschriebene;
+die Gegenprobe stellt eine niedrigere Spanne **hinter** die höchste und verlangt Grün.
+Ohne sie wäre die Reihenfolgefestigkeit eine Behauptung im Kopfkommentar statt eine
+gemessene Eigenschaft (D-299, D-326).
+
+🔴 **Die erste Gegenprobe von Prüfung 84 mißt die Ausnahme selbst, nicht die Meldung.**
+Sie legt das Probemanifest an und verlangt, daß **keine andere** Prüfung anspringt –
+damit ist der Eingriff aus Abschnitt 4 eine **dauerhafte Einheit** und nicht eine
+einmalige Messung.
+
+⚠️ **Beide Prüfungen sind gegen beide übernehmenden Projekte gelaufen, bevor sie als
+fertig galten** (D-326, D-299) – die Lehre, die `0.90.0` notiert und nicht angewandt hat.
+
+## 5.1 Der Befund, den der Abnahmelauf gebracht hat – und zwei gefallene Auflösungen
+
+🔴 **Prüfung 83 hat beim ersten Abnahmelauf einen Befund gemeldet, den keine der 82
+bisherigen Prüfungen sehen konnte** (D-340). Die Gegenprobe 58b legt eine Registerzeile
+mit ihrer Sondenkennung an; Prüfung 83 las sie als höchste vergebene Entscheidung und
+meldete **654 fehlende Entscheidungen**.
+
+**Die Auflösung ist zweimal gefallen, und beide Male im vollen Sondenlauf:**
+
+| Anlauf | Auflösung | Was sie widerlegt hat |
+|---|---|---|
+| **1** | Die Kennung in die Menge der **belegten synthetischen Kennungen** stellen | 🔴 **Sonde 58a verlor ihren Gegenstand.** Prüfung 58 nimmt genau jene Menge vom **Melden** aus – und die Sonde prüft, daß gemeldet wird. Das Decision Log sagt denselben Satz über die Sondenkennung von Prüfung 50: *„sie soll ja gemeldet werden"* |
+| **2** | Ein **eigener Absatz**, der die Kennung wörtlich nennt | 🔴 **Prüfung 58 meldete die Nennung**, weil die Kennung in keiner Registerzeile steht |
+| **3** | 🟢 **Ein reservierter BEREICH** – `D`-Kennungen ab 900 | trägt. Er nennt keine Kennung, und er trägt die nächste Sondenkennung ohne Nachtrag |
+
+➡️ ***Zwei Prüfungen, die dieselbe Kennung ansehen, stellen nicht dieselbe Frage.***
+Prüfung 50 und 58 fragen nach **Zugehörigkeit**, Prüfung 83 nach einer **Grenze**. Eine
+Liste beantwortet beide mit demselben Eintrag – und hebt dabei die eine Antwort auf.
+
+➡️ ***Eine Ausnahme, die ihren Gegenstand nennen muß, um zu wirken, erzeugt den Befund,
+den sie verhindern soll.*** Das ist der Grund, weshalb es ein Bereich geworden ist und
+keine Liste.
+
+🔴 **Das ist D-243 – *zwei Regeln, die einander die Voraussetzung entziehen* – an einem
+Paar von SONDEN statt an einem Paar von Regeltexten, und zweimal hintereinander
+zugeschnappt.** ⚠️ **Und es ist der Beleg dafür, daß der Abnahmelauf gegen den fertigen
+Baum kein Formalakt ist:** Beide Auflösungen sahen am Validator grün aus. **Gefunden hat
+sie allein der volle Sondenlauf.**
+
+⚠️ **Grenze, benannt:** Der Bereich ist eine Behauptung über künftige Vergaben. Wird je
+eine echte Entscheidung oberhalb der Grenze vergeben, ist die Regel verletzt, und **keine
+Prüfung meldet das** (`K-114`). Heute beträgt der Abstand 560 Kennungen.
+
+
+## 6. Die Fallen, die zugeschnappt sind
+
+| # | Falle | Wo sie zuschnappte |
+|---|---|---|
+| 1 | 🔴 **DIE TEUERSTE, UND SIE STAND WÖRTLICH IN DER ÜBERGABE.** *„Ein Sondenlauf mißt den Baum, in dem er startet; wer ihn nebenher fahren läßt, mißt den Baum von vorhin"* – der Fall aus `0.86.0`. **Der volle Lauf wurde gefahren, als `VERSION` schon auf `1.2.0` stand und die Übergabe noch auf `1.1.0`.** 112 von 325 Einheiten meldeten **dieselben zwei Fehler**, die nichts mit ihrem Gegenstand zu tun haben. **509 Sekunden verloren.** ➡️ *Die Lehre stand da, war gelesen, und ist trotzdem zugeschnappt* – **D-326 an einem dritten Gegenstand.** 🔴 **Keine Prüfung erreicht die Reihenfolge**, und das ist der eigentliche Befund |
+| 2 | 🔴 **Ein neu angelegter Träger trägt LF, der Kern trägt CRLF.** Der Änderungsantrag dieses Releases. **Prüfung 81 fängt es – aber erst im Sondenlauf**, weil sie den **Git-Bestand** mißt und ein nicht committeter Träger nicht darin steht. ➡️ *Eine Prüfung, die den Bestand mißt, erreicht eine Datei erst, wenn sie darin ist* – **der Validatorlauf davor war grün** |
+| 3 | ⚠️ **Die Zahl in `26-qs-test.md` bewegt sich mit jedem angelegten Träger.** Antrag und Protokoll heben sie um zwei. Sie gehört gesetzt, **nachdem** alle Träger stehen, und nicht davor |
+| 4 | ⚠️ **Die Heredoc-Form bricht an einem Anführungszeichen im Text.** Die Patchblöcke dieses Releases laufen deshalb über Dateien im Ablagebereich, nicht über die Eingabezeile – die Verschärfung von Falle 1 aus `1.1.0` |
+| 6 | 🔴 **Eine Ausnahme kann den Gegenstand einer FREMDEN Sonde aufheben.** Der erste Anlauf zu D-340 stellte eine Sondenkennung in die Ausnahmemenge von Prüfung 58 – und **Sonde 58a hatte danach nichts mehr zu messen.** ➡️ *Wer eine Ausnahme setzt, zählt zuerst, wer den Gegenstand noch braucht.* 🔴 **Der zweite Anlauf nannte die Kennung wörtlich, und Prüfung 58 meldete die Nennung** – *eine Ausnahme, die ihren Gegenstand nennen muß, um zu wirken, erzeugt den Befund, den sie verhindern soll.* 🟢 Beide gefunden **nur** vom vollen Sondenlauf; der Validator war beide Male grün |
+| 5 | 🟢 **Gefangen, bevor sie zuschnappte:** `printf` schreibt LF, und `VERSION` ist ein versionierter Träger. **Prüfung 81 hat es beim nächsten Lauf gemeldet** – derselbe Gegenstand wie Falle 2, zwei Stunden früher |
+
+## 7. Die Abnahme
+
+*(Die Zahlen unterhalb dieser Linie sind Laufzeiten und nicht Teil des zeilengleichen
+Vergleichs nach D-94.)*
+
+---
+
+| Lauf | Ergebnis |
+|---|---|
+| Validator, Framework | 🟢 **0 Fehler, 0 Warnungen** über **84 Prüfungen** |
+| Validator, `devpacks/otp-generator` `--strict-overlay` | 🟢 **1 Fehler, 2 Warnungen** – **identisch mit dem Stand vor dem Heben**; der Fehler ist Projektarbeit (gesperrter Begriff im Projekt-`CHANGELOG.md`) |
+| Validator, `devpacks/test-devin-framework` `--strict-overlay` | 🟢 **0 Fehler, 1 Warnung** (`K-88`, 6.023 von 6.000 Zeichen) |
+| Sondenlauf, beide Kodierungsumgebungen (D-49) | 🟢 **325 angemeldete Einheiten, 463 Ergebniszeilen, Exit 0** – *„alle Sonden und Gegenproben bestanden"* in **beiden** Umgebungen |
+| Zeilengleicher Vergleich der beiden Läufe (D-49) | 🟢 **0 Unterschiede in 499 Zeilen** |
+| Erzeugnisse der Lieferung (Abschnitt 4.1 Schritt 3) | 🟢 **Je Client Pack gebaut und im Erzeugnis nachgezählt:** `Koolie_v1.2.0_claude-code.docx` und `Koolie_v1.2.0_devin-desktop.docx`, je 2,01 MB, **8 von 8 Diagrammen eingebettet** – gezählt an `word/media/` und den Bildverweisen, nicht an der Meldung (D-328) |
+| Heben (Abschnitt 4.1 Schritt 2) | 🟢 **521 Träger aus dem Arbeitsbaum**, deckungsgleich mit `git ls-files`, **null Einträge aus `build/out/`**; beide Projekte **vor** dem Release-Commit gehoben (D-330, D-333) |
+
+⚠️ **Laufzeit des Sondenapparats:** 4.136 s Rechenzeit in 525 s Wanduhr (Umgebung 1),
+4.213 s in 534 s (Umgebung 2), je acht Bahnen.
+🔴 **Dazu kommen DREI verworfene Läufe von zusammen rund 1.590 s** – der verfrühte aus
+Falle 1 und die beiden, die die gefallenen Auflösungen von D-340 gemessen haben.
+➡️ *Zwei davon waren kein Verlust, sondern der Preis der Messung: Sie haben die beiden
+falschen Auflösungen widerlegt, und der Validator war beide Male grün.*
+
+🔴 **Der Overlay-Änderungsverlauf beider übernehmenden Projekte trägt die falsche Spanne
+`D-329 bis D-332`** – der Befund aus Abschnitt 3 an einer **vierten** Stelle, in beide
+Projekte ausgeliefert. **Er bleibt stehen:** Die Chronik berichtet ihren damaligen Stand
+(D-273), und **Prüfung 83 erreicht ein Overlay nicht** – sie mißt `docs/ROADMAP.md`
+gegen das Decision Log, und beide sind Kernträger. ➡️ *Eine Prüfung reicht so weit wie
+ihr Gegenstand, und die Auslieferung trägt weiter als er.*

package/.koolie/core/tests/protocols/2026-09-23-erhebung-openai-codex.md

@@ -0,0 +1,309 @@
+# Protokoll: Die Erhebung zu `openai-codex` – der Client, dessen Wurzelanweisung eine Datei daneben ersetzt
+
+| Feld | Inhalt |
+|---|---|
+| Datum | 2026-09-23 |
+| Release | **`1.3.0`** |
+| Änderungsantrag | `CR-2026-132` |
+| Art | **Arbeitsprotokoll.** Gegenstand sind die Erhebung zum Client Pack `openai-codex` (Schritte 2, 6 und 7 aus `clients/README.md` Abschnitt 5), der Vorbedingungsdurchgang davor und eine neue Prüfung |
+| Prüfmittel | `codex debug prompt-input` und `codex doctor` gegen ein **eigenes `CODEX_HOME` im Ablagebereich**; dazu das Konfigurationsschema aus dem Binär, der Validator und der volle Sondenlauf in beiden Kodierungsumgebungen |
+| Geprüfte Clientversion | **`0.156.1`** – **vor** dem Erheben festgeschrieben (D-117, D-202) |
+| Ergebnis | 🟢 **Zehn Befunde, sechs davon mit Gegenprobe, null Kontingent.** 🔴 **Drei ändern die Bauform des Packs, und deshalb rückt sein Bau auf `1.4.0`** |
+
+> 🔴 **Dies ist kein Abnahmeprotokoll des Testkatalogs** und trägt deshalb keinen
+> Abschnitt *Gegenzeichnung* (D-319, Zuschnitt von Prüfung 80). Es berichtet eine
+> Messung und trägt seinen Beleg in sich.
+
+---
+
+## 1. Der Anlaß
+
+Der Wiederaufnahmepunkt zu `1.2.0` nennt als nächsten Posten das **Client Pack
+`openai-codex`** – die neun Schritte aus `clients/README.md` Abschnitt 5. **Drei dieser
+neun Schritte sind Erhebungen**, und sie stehen vor dem ersten geschriebenen
+Trägerbyte: die Pfadabbildung (Schritt 2), die Semantikabbildung (Schritt 6) und die
+Auskunft über Quellen außerhalb des Projekts (Schritt 7).
+
+Vor dem ersten Handgriff stand der Vorbedingungsdurchgang – zum **einundzwanzigsten**
+Mal in Folge.
+
+## 2. Der Vorbedingungsdurchgang
+
+| # | Befund | gemessen an |
+|---|---|---|
+| **V1** | 🟢 Die Tabelle *Nächste freie Kennungen* stimmt – **zum zweiten Mal in Folge** | 340 `D`-Registerzeilen bis `D-340`, 112 `K`-Zeilen bis `K-114`, `CR-2026-131` vergeben, `G-20`, `UEB-31`; alle fünf Gattungen nachgezählt |
+| **V2** | 🟢 Das Codex-Konto ist `plus` | `id_token`, Feld `chatgpt_plan_type` |
+| **V3** | 🟢 Die geprüfte Clientversion ist **vor** dem Erheben festgeschrieben: `0.156.1` | `codex --version`; `codex doctor` meldet *latest version status: current version is not older* |
+| **V4** | 🟢 **Die Word-Fassung steht auf `v1.2.0`** – Schritt 3 von Abschnitt 4.1 hat bei `1.2.0` gehalten. 🔴 **Der erste Anlauf dieses Durchgangs hat das Gegenteil gemeldet, und das war ein Meßfehler** | `build/out/` führt `Koolie_v1.2.0_claude-code.docx` und `Koolie_v1.2.0_devin-desktop.docx`; Abschnitt 6 |
+| **V5** | 🟢 Bestandsliste in allen drei Trägern byte-gleich auf `1.2.0`; **beide** Projekte tragen die Hebung als Commit | `cmp` über drei Kopien, `git log` in beiden Projekten (`4f09d0a`, `49dc116`) |
+| **V6** | 🟢 **Die Nennungen von `1.2.0` sind vollständig, und zwar in ZWEI beschreibenden Trägern** | `D-335` bis `D-340` je Träger gezählt: `CHANGELOG.md` sechs, `CR-2026-131` sechs, ROADMAP als Spanne, Protokoll zwei. **`K-112` hat seinen ersten Fall nicht gebracht** |
+| **V7** | ⚠️ Die Benutzerkonfiguration des Clients führt weiter einen Vertrauenseintrag auf den **alten** Projektnamen – **und einen auf das Benutzerprofil selbst** | gelesen; der zweite schließt jeden Pfad darunter ein und macht die projektgenauen Einträge gegenstandslos |
+| **V8** | 🔴 **Drei `Geplant`-Abschnitte in `docs/ROADMAP.md` nennen ein Ziel-Release, das die Gegenwart überholt hat** | gezählt; Abschnitt 5 |
+| **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 – Abschnitt 6.**
+
+## 3. Das Meßmittel – und warum es nichts kostet
+
+`codex debug prompt-input` gibt die Entwickler- und Nutzernachrichten als JSON aus, die
+der Client der nächsten Anfrage voranstellt – **ohne eine Anfrage zu stellen.** Damit
+ist ablesbar, was das Modell zu Beginn einer Sitzung sieht: die Wurzel-Anweisung, die
+Skillmenge samt Herkunftstabelle, die Umgebungsangaben und das wirksame Rechteprofil.
+
+**Das ist bei diesem Client die Entsprechung der Mitschrift**, mit der `0.86.0` das Pack
+`devin-desktop` gemessen hat – **und es ist billiger:** die Mitschrift entsteht aus einem
+Lauf, dieser Ausdruck aus keinem.
+
+🔴 **An einer Stelle ist es auch schärfer.** Die Verdrängung der Wurzel-Anweisung (E1)
+ist an einer **Abwesenheit** im Prompt erkennbar. Ein Lauf hätte sie nur gezeigt, wenn
+das Modell zufällig auf die fehlende Regel gestoßen wäre. ➡️ ***Ein Vorhandensein belegt
+sich selbst, ein Fehlen nicht*** – hier läßt sich das Fehlen zum ersten Mal direkt
+ablesen.
+
+### 3.1 Die Isolation, und warum sie hier Bedingung war
+
+**Die Hälfte der Befunde hängt an Einträgen in der Benutzerkonfiguration des
+Arbeitsplatzes.** Sie dort zu setzen hieße, den Arbeitsplatz zu verändern, um ihn zu
+messen. Alle Messungen dieses Abschnitts laufen deshalb gegen ein **eigenes
+`CODEX_HOME`** im Ablagebereich, das nur die Anmeldedaten und die jeweils gemessene
+Einstellung trägt. **Die Konfiguration des Arbeitsplatzes ist nicht angefaßt worden** –
+und damit ist auch nichts über sie gemessen worden.
+
+## 4. Die zehn Befunde
+
+### 4.1 `E1` – eine Datei neben der Wurzel-Anweisung verdrängt sie vollständig
+
+Ein Projekt mit einer Wurzel-Anweisung und einer gleichnamigen Overlaydatei daneben
+(`AGENTS.override.md`). Gemessen wurde die **Anwesenheit einer Sondenmarke** im Prompt:
+
+| Lauf | Wurzel-Anweisung im Prompt | Overlaydatei im Prompt |
+|---|---|---|
+| **Sonde:** beide Dateien vorhanden | 🔴 **nein** | ja |
+| **Gegenprobe:** nur die Wurzel-Anweisung | 🟢 **ja** | – |
+
+➡️ ***Eine Wurzel-Anweisung, die eine ungeprüfte Datei im selben Verzeichnis ersetzen
+kann, ist keine Ebene 1 – sie ist ein Standard.***
+
+🔴 **Die Folge für `R1` ist nicht redaktionell.** Die Prioritätshierarchie stellt die
+Wurzel-Anweisung auf Ebene 1; hier genügt eine Datei im Arbeitsbaum, um sie
+**vollständig** zu ersetzen, und nichts meldet es. Ein aufnehmendes Projekt, das die
+Overlaydatei in seine `.gitignore` schreibt – der naheliegende Ort für eine persönliche
+Fassung –, hätte damit eine unversionierte Ebene 1 je Arbeitsplatz.
+
+### 4.2 `E2` und `E3` – das Vertrauensmodell über der gesamten projektlokalen Schicht
+
+Dieselbe Projektkonfiguration, zweimal gemessen, mit zwei Benutzerverzeichnissen:
+
+| Lauf | Vertrauenseintrag | Modell | Rückfragepolitik | Dateisystem-Sandkasten |
+|---|---|---|---|---|
+| **A** | 🟢 vorhanden | **aus dem Projekt** | **`Never`** | **ohne Schranken** |
+| **B** (Gegenprobe) | 🔴 fehlt | Benutzerstandard | `OnRequest` | eingeschränkt |
+
+🔴 **Zwei Befunde in einer Messung.**
+
+**(E2)** Ohne Vertrauenseintrag lädt die projektlokale Schicht **gar nicht** – und zwar
+nicht nur die Konfiguration, sondern nach der Meldung des Clients *„project-local config,
+hooks, and exec policies"* zusammen. ➡️ *Ein versionierter Träger, der nicht lädt, trägt
+nichts.* **`B1` ist damit bedingt:** Die Berechtigungen liegen versioniert im
+Repositorium **und** ihre Wirksamkeit hängt an einem Eintrag außerhalb.
+
+**(E3)** Mit Vertrauenseintrag **lockert** die projektlokale Schicht den Benutzerstandard:
+Rückfragen aus, Sandkasten offen. **Das ist das Spiegelbild von `B9`** – dort lautet die
+Zusage *„eine nutzerlokale Konfiguration kann nur verschärfen"*; hier verschärft nicht
+die nutzerlokale, sondern **lockert die projektlokale**.
+
+⚠️ **Und der Vertrauenseintrag wird üblicherweise einmal und beiläufig erteilt.** Der
+Vorbedingungsdurchgang hat auf diesem Arbeitsplatz einen Eintrag auf das
+**Benutzerprofil** gefunden (V7), der jeden Pfad darunter einschließt.
+
+### 4.3 `E4` und `E5` – die Pfadrechteschicht kennt keine Muster, und hier gar nichts
+
+Die Rechteprofile des Clients binden Pfade an eine Zugriffsart. **Ein Musterausdruck als
+Schlüssel wird abgewiesen:** verlangt sind absolute Pfade, `~/`-Pfade oder Sonderziele
+(Projektwurzel, Arbeitsbereich, Temporärverzeichnis).
+
+🔴 **Die Kernzusage `B3` verlangt genau Muster** – `.env`, `*.pem`, `*.key`,
+`secrets/**`. Sie ist in dieser Form **nicht abbildbar**.
+
+🔴 **Und auf diesem Arbeitsplatz gar nicht.** Ein Profil mit einer `deny`-Leseregel
+führt zur Abweisung *„windows unelevated restricted-token sandbox cannot enforce
+deny-read restrictions directly; refusing to run unsandboxed"*. 🟢 **Das Verhalten ist
+fail-closed und damit richtig** – der Client läuft lieber nicht, als ungeschützt zu
+laufen. ⚠️ **Für das Pack heißt es trotzdem:** `B3` steht in diesem Betriebsmodus auf
+`[NICHT ABBILDBAR]`, und die Vorbemerkung des B-Blocks zur Betriebsmodus-Abhängigkeit
+(D-35) bekommt einen zweiten Fall – diesmal einen, der nicht vom **Modus**, sondern vom
+**Betriebssystem und der Rechtestufe** abhängt.
+
+**`B3` ist eine Kernzusage.** Damit greift `clients/README.md` Abschnitt 4: Begründung
+im Pack, dokumentierte Ausnahme im Overlay des aufnehmenden Projekts, und **keine
+Inbetriebnahme ohne Freigabe durch `<SECURITY_CONTACT>`.**
+
+### 4.4 `E6` – Hooks tragen ein Vertrauensmodell über einen Hash
+
+Das Konfigurationsschema führt je Hook einen **vertrauten Hash**; die Befehlszeile kennt
+einen Schalter, der das Vertrauen übergeht und sich selbst als gefährlich bezeichnet.
+
+➡️ **Die Entsprechung zu D-281 und zu `AP2-CC-13`:** *Ein Schutz-Hook, der nicht läuft,
+blockiert nichts.* 🔴 **Und die Bindung an den Hash hat eine Folge, die D-281 nicht
+hat:** **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
+– und der Validator sieht es nicht, weil die Datei ja da ist.
+
+### 4.5 `E7` bis `E10` – die übrigen vier
+
+| # | Befund | Beleg |
+|---|---|---|
+| **E7** | Das Benutzerverzeichnis des Clients führt eine **eigene Anweisungsdatei**, die in jede Sitzung lädt | Sonde im isolierten `CODEX_HOME`, im Prompt wiedergefunden |
+| **E8** | Skills laden projektlokal aus **zwei** Ablagen; eine dritte, naheliegende an der Projektwurzel **nicht**. Die Menge ist **mit Herkunft vollständig aufzählbar** | drei Sonden an drei Orten, eine davon negativ; der Prompt führt eine Tabelle der Skillwurzeln |
+| **E9** | **Regeldateien mit Ladebedingungen gibt es nicht.** Der Geltungsbereich einer Anweisungsdatei ist ihr Verzeichnisbaum; eine Datei im Unterverzeichnis steht **nicht** vorab im Kontext | Sonde im Unterverzeichnis, im Prompt **nicht** wiedergefunden |
+| **E10** | Ein projektlokal **nicht unterstützter** Schlüssel wird in einer Startmeldung **benannt** | gemessen mit einem solchen Schlüssel; die Meldung nennt ihn wörtlich |
+
+🟢 **`E8` und `E10` sind gute Nachrichten für das Pack:** `S5` ist gemessen erfüllt, und
+ein falsch abgebildeter Konfigurationsschlüssel fällt nicht lautlos aus.
+⚠️ **`E9` nicht:** `R2` und `R3` haben eine andere Gestalt, und die Abbildung der
+Ladetrigger (`rule_triggers`) braucht eine eigene Auflösung – ein Ladetrigger ohne
+Eintrag läßt die Installation scheitern (D-26, D-27).
+
+## 5. Der Befund am eigenen Plan
+
+`docs/ROADMAP.md` führte drei Abschnitte der Form
+`### Geplant: <Posten> – Ziel-Release <Version>`:
+
+| Abschnitt | Zielangabe | Wirklichkeit |
+|---|---|---|
+| Die Umbenennung auf `Koolie` | `~0.68.0` | 🔴 erledigt mit `0.88.0` – **fünfzehn Releases** unter der Überschrift *„Geplant"* |
+| Client Pack `openai-codex` | `1.1.0` | 🔴 die **Releasetabelle derselben Datei** führte ihn auf `1.3.0` |
+| Projekt-Overlays als Installationsparameter | `1.2.0` | 🔴 `1.2.0` ausgeliefert, 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.
+
+🔴 **Die Ursache ist gemessen:** Beide Verschiebungen des Packpostens sind je einzeln
+ausgewiesen worden (D-127 auf `1.1.0`, D-339 auf `1.3.0`), und **keine hat die
+Überschrift angefaßt** – die Releasetabelle galt als der eine Ort. ➡️ *Wer eine Zahl an
+zwei Stellen führt, pflegt eine.*
+
+### 5.1 Prüfung 85 – vier Einheiten
+
+| Einheit | Gegenstand | Ergebnis |
+|---|---|---|
+| **Gegenprobe 85a** | die berichtigte ROADMAP läuft durch, und die Prüfung ist dabei nachweislich gelaufen | 🟢 |
+| **Gegenprobe 85b** | 🔴 **die, die man weglassen würde:** eine Zielangabe in der **Zukunft** muß durchlaufen | 🟢 |
+| **Sonde 85a** | eine Zielangabe, die `VERSION` erreicht hat, wird gemeldet | 🟢 |
+| **Sonde 85b** | eine Planüberschrift **ohne** Zielangabe wird gemeldet | 🟢 |
+
+🔴 **Warum Sonde 85b sein muß:** Ohne sie wäre das Streichen der Zahl der billigste Weg,
+diese Prüfung loszuwerden – und D-124 hat die Frage schon beantwortet: *ein Posten ohne
+Zahl bleibt in diesem Projekt erfahrungsgemäß lange liegen.*
+
+⚠️ **Grenze, benannt, und sie zeigt sich am ersten Fall:** Den erledigten Abschnitt hat
+die Prüfung **aus dem falschen Grund** gefangen – weil seine Zahl zufällig auch veraltet
+war. Eine Zielangabe `2.0.0` hätte dieselbe Überschrift durchgelassen. ➡️ *Eine Prüfung,
+die den richtigen Fall aus dem falschen Grund fängt, ist beim nächsten Fall blind*
+(`K-116`).
+
+## 6. Der Befund, den es nicht gab – und der Meßfehler dahinter
+
+🔴 **`V4` lautete im ersten Anlauf: 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.** Daraus
+wurde ein dritter Preis für `K-110` abgeleitet, und daraus ein Decision Record.
+
+🟢 **Es war falsch.** `build/out/` führt zwölf Träger, darunter
+`Koolie_v1.2.0_claude-code.docx` und `Koolie_v1.2.0_devin-desktop.docx`.
+
+🔴 **Die Ursache, gemessen:** Die Verzeichnisliste war auf **zehn Zeilen** beschnitten.
+Sieben Erzeugnisse, zwei Verzeichniseinträge und die Summenzeile füllten sie; die beiden
+Träger von `1.2.0` standen auf Zeile **elf** und **zwölf**.
+
+| | |
+|---|---|
+| Was die Liste sagte | sieben Erzeugnisse, das jüngste `v1.1.0` |
+| Was im Verzeichnis lag | **elf** Erzeugnisse, das jüngste `v1.2.0` |
+| Was gelesen wurde | eine fehlende **Zeile** als fehlende **Datei** |
+
+➡️ ***Eine Messung, die ihre Ausgabe beschneidet, mißt die Beschneidung.***
+
+🔴 **Und der Satz, der es hätte verhindern müssen, steht in diesem Protokoll zwei
+Abschnitte weiter oben.** Abschnitt 3 führt ihn als **Stärke** des neuen Meßmittels:
+*Ein Vorhandensein belegt sich selbst, ein Fehlen nicht.* Ein Fehlen zu belegen verlangt
+eine Messung, die **den ganzen Gegenstand sieht** – und genau das tat diese nicht.
+
+🟢 **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.***
+
+### 6.1 Warum der Befund gebucht bleibt
+
+🔴 **Weil dieses Repositorium seine Fehlerarten kennt, indem es sie aufschreibt.** D-305
+hat denselben Fall schon einmal aufgenommen – dort hatte D-301 *„einen Verlust gebucht,
+den es nicht gab"*. **D-345 hält ihn fest**, und der Zuschnitt ist diesmal enger als der
+Einzelfall: **Der Prüfapparat schneidet an vielen Stellen Ausgaben ab.** *Eine Zählung
+gehört gezählt, nicht gelistet.*
+
+🟢 **Was sachlich bleibt:** `K-110` ist **nicht** ein drittes Mal angefallen. Der
+Verfahrensschritt aus D-332 hat mit `1.2.0` gehalten – und die Erzeugnisse dieses
+Releases sind gebaut und im Erzeugnis nachgezählt (Abschnitt 9).
+
+## 7. Was für `1.4.0` entschieden werden muß, bevor ein Träger entsteht
+
+| # | Frage | Woran sie hängt |
+|---|---|---|
+| **1** | Bekommt `clientmap.py` eine **zweite Ausgabeform**? Die heutige rendert Körbe aus `Werkzeug(Muster)`-Regeln; dieser Client bindet **Pfade an Zugriffsarten** und Befehle an eigene Regeldateien | `E4`. Betrifft `B2` bis `B6`, also **vier Kernzusagen** |
+| **2** | Wie wird das **Vertrauensmodell** im B-Block ausgewiesen? Es steht über der ganzen projektlokalen Schicht, nicht nur über den Hooks | `E2`, `E6`. Betrifft `B1`, `H1`, `H2` – und die Vorbemerkung zur Betriebsmodus-Abhängigkeit (D-35) |
+| **3** | Wie steht die **verdrängbare Wurzel-Anweisung** in `R1`? Als `[TEXTUELL]` mit Begründung, oder als `[TECHNISCH]` mit benannter Bedingung? | `E1`. **Keine der beiden vorhandenen Packzeilen hat diese Gestalt** |
+| **4** | Wie werden die **Ladetrigger** abgebildet, wenn es keine gibt? `rule_triggers` läßt einen Trigger ohne Eintrag die Installation abbrechen (D-26, D-27) | `E9` |
+| **5** | Trägt das Pack **beide** Skillablagen oder eine? | `E8` |
+
+🔴 **Zwei der betroffenen Zeilen sind Kernzusagen** (`B3`, `B9`) – nach
+`clients/README.md` Abschnitt 4 brauchen sie eine Begründung im Pack, eine dokumentierte
+Ausnahme im Overlay und eine Freigabe durch `<SECURITY_CONTACT>`. **Das ist keine
+Fußnote, und deshalb rückt der Bau** (D-341).
+
+## 8. Ein Befund beim Heben selbst – `K-117`
+
+Schritt 2 des Verfahrens hat einen eigenen Befund geliefert, und er hat mit `openai-codex`
+nichts zu tun.
+
+| Projekt | Kerndateien im Arbeitsbaum | davon versioniert | Differenz |
+|---|---|---|---|
+| `devpacks/otp-generator` | 525 | 🔴 **483** | 🔴 **42** |
+| `devpacks/test-devin-framework` | 525 | 🟢 521 | 4 (Bytecode) |
+
+🔴 **Die Ursache ist eine Zeile im `.gitignore` des Projekts:** `build/` trifft auch
+`.koolie/core/build/` – und damit **die gesamte Quelle des Hauptdokuments**, die das
+Framework ausliefert.
+
+➡️ ***Ein Kern, der ausgeliefert, aber nicht versioniert wird, ist beim nächsten Klonen
+dieses Projekts unvollständig*** – und der Validator sieht es nicht, weil er den
+**Arbeitsbaum** mißt. ⚠️ **Prüfung 81 fängt es ebenfalls nicht:** Sie mißt die
+Zeilenendeform der **verfolgten** Träger, also gerade derer, die noch da sind.
+
+**Als `K-117` aufgenommen, drei Fragen vorgelegt, in diesem Release nicht entschieden.**
+
+🔴 **Und der Eintrag hat den benannten Preis von D-330 fällig gemacht:** Er ist ein
+Kerneingriff **nach** dem Heben, also mußte **erneut gehoben** werden. *Heben und Commit
+gehören als Paar* – hier zum zweiten Mal gemessen.
+
+## 9. Abnahme
+
+| Gegenstand | Ergebnis |
+|---|---|
+| Validator (84 → **85 Prüfungen**) | *(siehe Abnahmezeile der Übergabe)* |
+| Sondenlauf, beide Kodierungsumgebungen | *(siehe Abnahmezeile der Übergabe)* |
+| Zeilengleicher Vergleich nach D-49 | *(siehe Abnahmezeile der Übergabe)* |
+| Erzeugnisse der Lieferung, je Client Pack | 🟢 **gebaut und im Erzeugnis nachgezählt:** `Koolie_v1.3.0_claude-code.docx` und `Koolie_v1.3.0_devin-desktop.docx`, je **8 Diagramme** eingebettet und **36** Fundstellen der Version im Dokumentkörper; das Hauptdokument mit **13.041** Zeilen (`claude-code`) beziehungsweise **13.123** (`devin-desktop`) |
+| Übernehmende Projekte | gehoben **und dort committet** (D-343) |
+
+---
+
+## Anhang: Was dieses Protokoll nicht belegt
+
+🔴 **Der Prompt-Eingang zeigt, was das Modell SIEHT, nicht, was die Engine
+DURCHSETZT.** Jede Zeile des B-Blocks braucht weiterhin einen Lauf gegen eine reale
+Installation; `[TECHNISCH]` bleibt daran gebunden (`clients/README.md` Abschnitt 4,
+D-344).
+
+🔴 **Und alle Messungen liefen gegen ein isoliertes Benutzerverzeichnis.** Über die
+Konfiguration dieses Arbeitsplatzes ist damit **nichts** gemessen – außer dem, was der
+Vorbedingungsdurchgang gelesen hat (V7).

package/.koolie/core/tests/protocols/2026-09-23-freigabelauf-1.0.0-vorbereitung.md

@@ -0,0 +1,119 @@
+# Protokoll: Vorbereitung des Freigabelaufs `1.0.0` – `FW-CL-11`, gemessener Stand je Prüfpunkt
+
+| Feld | Inhalt |
+|---|---|
+| Datum | 2026-09-23 |
+| Release | Vorbereitung für `1.0.0` (`AP12`), erstellt im Release `0.90.0` |
+| Änderungsantrag | `CR-2026-125` (Vorbereitung), `CR-2026-127` (offene Rollenfrage) |
+| Art | **Vorbereitung, keine Freigabe.** Jeder Prüfpunkt der Checkliste `FW-CL-11` auf seinem gemessenen Stand |
+| Gegenstand | `checklists/11-framework-release.md` Version `0.2.3`, 22 Prüfpunkte |
+| Ergebnis | 🟢 **18 von 22 gedeckt.** 🔴 **Vier brauchen einen Menschen**, und einer davon ist blockierend |
+
+> 🔴 **Dies ist NICHT die abgelegte Checkliste des Releases `1.0.0`.** Es ist die
+> Vorbereitung dafür: Was maschinell gedeckt ist, ist gemessen; was ein Mensch tun muß,
+> steht als solches da und ist **nicht** abgehakt. *Eine Checkliste, die sich selbst
+> abhakt, ist keine.*
+
+---
+
+## 1. Der Stand je Prüfpunkt
+
+Legende: 🟢 gedeckt und gemessen · 🔴 braucht einen Menschen · ⚪ fällt in den
+Freigabelauf selbst
+
+### Inhalt und Konsistenz
+
+| Prüfpunkt | Stand am 2026-09-23 |
+|---|---|
+| Änderungsanträge abgeschlossen oder verschoben | ⚪ **Im Freigabelauf zu prüfen.** Gemessen: **127** Anträge, davon `CR-2026-127` **ausdrücklich offen** (Rollenfrage) |
+| Konsistenz Core ↔ Laufzeitfassung je Client Pack | 🔴 **Stichprobe durch einen Menschen.** Prüfung 2, 4, 13, 21 und 76 decken die maschinellen Anteile; die Checkliste verlangt zusätzlich Stichproben je geändertem Modul |
+| Skills konsistent zum Skill-Standard | 🟢 Prüfung 5, 25, 47, 61, 64 – Validator 0 Fehler |
+| Version je geänderter Checkliste und Prompt gepflegt | 🟢 Prüfung 13 (Artefaktversionen) |
+| Prioritätshierarchie unverändert oder begründet | ⚪ Im Freigabelauf |
+| Templates, Checklisten, Entscheidungsbäume abgeglichen | ⚪ Im Freigabelauf (`SOLL`) |
+
+### Projektneutralität
+
+| Prüfpunkt | Stand am 2026-09-23 |
+|---|---|
+| `validate-framework.py` ohne Fehler, Warnungen bewertet | 🟢 **0 Fehler, 0 Warnungen** |
+| `forbidden-terms.txt` im Release leer | 🟢 **gemessen: nur Kommentarzeilen, keine Begriffe** |
+| Manuelle Stichprobe auf projekt-/kunden-/personenspezifische Inhalte | 🔴 **Braucht einen Menschen.** Die Checkliste sagt ausdrücklich *„zusätzlich zur automatischen Prüfung"* |
+| Beispiele synthetisch gekennzeichnet, Platzhalterregister aktuell | 🟢 Prüfung 7, 14 |
+
+### Produktstand der KI-Client
+
+| Prüfpunkt | Stand am 2026-09-23 |
+|---|---|
+| Aktualitätsprüfung gegen die offizielle Clientdokumentation | 🔴 **Braucht einen Menschen.** Sie verlangt Abruf der Herstellerdokumentation und ein Urteil darüber; beides liegt außerhalb des freigegebenen Arbeitsbereichs (`AGENTS.md` Abschnitt 4: *„kein Web, keine externen Systeme ohne Freigabe"*) |
+| Produktänderungen mit Regelwirkung als Änderungsanträge behandelt | ⚪ Folgt aus dem vorigen Punkt |
+
+### Tests
+
+| Prüfpunkt | Stand am 2026-09-23 |
+|---|---|
+| Testkatalog vollständig ausgeführt | 🟢 **125 Ergebniszellen**, sechs Meßtage, zwei Nachläufe |
+| **(ab 1.0.0)** Kein Testfall auf `offen` | 🟢 **erfüllt** – Kriterium 2 von D-11 steht auf **0** |
+| Skill-Testfälle für geänderte Skills erneut ausgeführt | ⚪ Im Freigabelauf; `0.90.0` hat keinen Skill geändert |
+| Hook- und Validierungsskripte fehlerfrei | 🟢 Sondenlauf, **beide Kodierungsumgebungen** |
+| Vollständiger Durchlauf M1→M2→M3→M4 auf dem Übungsrepositorium | ⚪ `SOLL`. ⚠️ **Braucht ein Kontingent** – ein Modelllauf über vier Betriebsmodi |
+
+### Abschluss
+
+| Prüfpunkt | Stand am 2026-09-23 |
+|---|---|
+| `VERSION` erhöht, `CHANGELOG.md` ergänzt | ⚪ Im Freigabelauf |
+| Release-Archiv erzeugt, übernehmende Projekte informiert | ⚪ Im Freigabelauf |
+| **Freigabe durch den Framework Owner dokumentiert** | 🔴 **Braucht einen Menschen.** Nicht delegierbar (`V1`, `V2`, `AGENTS.md` Abschnitt 16) |
+| **(ab 1.0.0)** Alle Core-Module, Skills und Packs über `entwurf` | 🟢 **erfüllt** – 81 Träger mit Steckbriefzeile, **77 auf `pilot`**, vier Ausfüllschlitze, **0 auf `entwurf`** |
+| **(ab 1.0.0)** Kein Decision Record auf `entschieden (Vorschlag)` | 🟢 **erfüllt** seit `0.49.0` |
+| **(ab 1.0.0)** Übernahme in ein zweites Projekt nachgewiesen | 🟢 **erfüllt** – zwei übernehmende Projekte, beide gehoben (`FW-RE-01`) |
+
+---
+
+## 2. 🔴 Der blockierende Posten: die Gegenzeichnung
+
+Er steht in keinem Prüfpunkt der Checkliste, sondern im **Arbeitspaket `AP11`** – und
+solange er offen ist, ist `AP11` nicht abgeschlossen und `AP12` nicht fällig.
+
+| Menge | gegengezeichnet | offener Abschnitt | ohne Abschnitt |
+|---|---|---|---|
+| alle **122** Protokolle | 13 | 45 | 64 |
+| die **10** FW-Testprotokolle | 3 | 2 | 5 |
+
+🔴 **Es ist keine Arbeit, sondern eine Rollenfrage.** An diesem Framework arbeitet **eine**
+Person; eine Gegenzeichnung ist die Handlung einer **zweiten**. Die drei Wege und ihre
+Preise stehen in **`CR-2026-127`**, Abschnitt 4. ➡️ *Eine Pflicht, die niemand erfüllen
+kann, ist ein Befund über ihre Formulierung.*
+
+---
+
+## 3. Was die Sitzung braucht – und was sie nicht braucht
+
+**Nicht mehr nötig** (mit `0.90.0` erledigt): Die Word-Fassung ist gebaut, für beide
+Client Packs, mit acht eingebetteten Diagrammen.
+
+| Block | Inhalt | Richtwert |
+|---|---|---|
+| 1 | **Die Rollenfrage entscheiden** (`CR-2026-127` E1 bis E4) | 15 min |
+| 2 | Gegenzeichnungen nach dem gewählten Weg eintragen | 20 min |
+| 3 | **Manuelle Stichprobe** – die geänderten Träger werden vorgelegt, der Owner sieht durch | 25 min |
+| 4 | **Aktualitätsprüfung Clientdokumentation** – der Owner ruft ab, der Abgleich gegen die `[DOK]`-Aussagen läuft daneben | 30 min |
+| 5 | Freigabe dokumentieren, `VERSION` auf `1.0.0`, Abnahmelauf | danach |
+
+⚠️ **Der `SOLL`-Prüfpunkt M1→M2→M3→M4 ist der einzige Posten mit Kontingent.** Er ist ein
+`SOLL`, kein `MUSS`; wird er nicht gefahren, gehört das ausgewiesen statt weggelassen.
+
+---
+
+## 4. Was hier **nicht** steht, und warum
+
+- **Keine Zahl über die offenen Klärungspunkte.** 🔴 Sie ist mit keinem Werkzeug belastbar
+  zu ermitteln: Drei Zählungen ergaben **50**, **64** und 15 nicht erkennbare Zeilen. Die
+  Ursache ist `K-100` – die K-Zeilen stehen in **zwei** Tabellenformen mit der Statuszelle
+  an verschiedenen Stellen, und die Statuswerte folgen keinem Vokabular. Das Register führt
+  **104** Zeilen; die Übergabe nennt 13 offene. *Keine der drei Zahlen ist nachprüfbar
+  falsch, und genau das ist der Befund.* **Offene Klärungspunkte sind kein Prüfpunkt von
+  `FW-CL-11` und kein Kriterium von D-11** – sie blockieren `1.0.0` nicht.
+- **Kein Haken.** Kein Prüfpunkt dieser Vorbereitung ist abgehakt. Das Abhaken geschieht im
+  Freigabelauf, durch einen Menschen.