@renoxar/koolie 1.25.0

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

@@ -0,0 +1,150 @@
+# Protokoll: Freigabelauf `1.0.0` – die abgelegte Checkliste `FW-CL-11`
+
+| Feld | Inhalt |
+|---|---|
+| Datum | 2026-09-23 |
+| Release | **`1.0.0`** (`AP12`) |
+| Änderungsantrag | `CR-2026-128` |
+| Art | **Freigabelauf.** Jeder Prüfpunkt der Checkliste `FW-CL-11` auf seinem gemessenen Stand |
+| Gegenstand | `checklists/11-framework-release.md` Version `0.3.0`, **24 Prüfpunkte** – 22 MUSS, 2 SOLL |
+| Ergebnis | 🟢 **20 von 24 gedeckt** – maschinell oder aus einem Beleg. 🔴 **Drei sind die Handlung eines Menschen** (9, 20 Schritt 1, 21), ⚪ **einer ist ein `SOLL` und wird ausgewiesen statt gefahren** (18) |
+
+> 🔴 **KEIN PRÜFPUNKT IST HIER ABGEHAKT.** Was gemessen ist, steht mit seinem Meßwert da;
+> was ein Mensch tun muß, steht als solches da. **Das Abhaken ist die Handlung des
+> Menschen, und der Freigabe-Commit ist seine Unterschrift** (D-319, D-321).
+> *Eine Checkliste, die sich selbst abhakt, ist keine.*
+
+> ⚠️ **Die Vorbereitung vom `0.90.0` nannte „22 Prüfpunkte" und listete 23.** Gemessen
+> sind es **24** – mit Prüfung 80 ist einer hinzugekommen, die Differenz davor war schon
+> da (`CR-2026-128` B5). Dieses Protokoll ersetzt die Vorbereitung nicht; sie bleibt als
+> Aufzeichnung ihres Standes stehen.
+
+---
+
+## 1. Inhalt und Konsistenz
+
+| # | Prüfpunkt | Gewicht | Gemessener Stand |
+|---|---|---|---|
+| 1 | Änderungsanträge abgeschlossen oder ausdrücklich verschoben | MUSS | 🟢 **128 Anträge, keiner offen.** `CR-2026-127` (Rollenfrage) ist mit `0.91.0` entschieden, `CR-2026-128` mit diesem Release. Ausdrücklich **verschoben**: das Client Pack `openai-codex` auf `1.1.0` (D-124, D-127) |
+| 2 | Konsistenz Core ↔ Laufzeitfassung je Client Pack | MUSS | 🟢 **Gedeckt, und der Grund ist gemessen: dieses Release ändert kein Core-Modul und keine Regelablage** – **16 Träger, davon 0 unter `framework/`**. Die Checkliste verlangt Stichproben *„je geändertem Modul"*; es gibt keines. **Maschinell:** Prüfungen 2, 4, 13, 21, 76 – Validator **0 Fehler, 0 Warnungen**. ⚠️ Die Stichprobe auf **Inhalte** ist Prüfpunkt 9 und davon zu trennen |
+| 3 | Skills konsistent zum Skill-Standard | MUSS | 🟢 Prüfungen 5, 25, 47, 61, 64. **Dieses Release ändert keinen Skill** – gemessen an `git status`: 0 Träger unter `skills/` |
+| 4 | Version je geänderter Checkliste und je geändertem Prompt gepflegt | MUSS | 🟢 Prüfung 13. **Geändert und gepflegt:** `RELEASE_PROCESS.md` `0.1.4` → `0.2.0` (neuer Abschnitt 4.1), `LICENSE-HINWEIS.md` `0.1.0` → `0.2.0`. **Keine Checkliste, kein Prompt berührt** |
+| 5 | Prioritätshierarchie unverändert oder begründet | MUSS | 🟢 **Unverändert.** `PRIORITY_HIERARCHY.md` steht auf `0.2.1` und ist in diesem Release nicht angefaßt (gemessen an `git status`) |
+| 6 | Templates, Checklisten, Entscheidungsbäume abgeglichen | SOLL | 🟢 **Kein Gegenstand:** Dieses Release ändert kein Modul, gegen das sie abzugleichen wären. Die einzige Regeländerung – Abschnitt 4.1 des Release-Prozesses – ist in `FW-CL-11` bereits als Prüfpunkt 20 abgebildet |
+
+## 2. Projektneutralität
+
+| # | Prüfpunkt | Gewicht | Gemessener Stand |
+|---|---|---|---|
+| 7 | `validate-framework.py` ohne Fehler, Warnungen bewertet | MUSS | 🟢 **0 Fehler, 0 Warnungen**, gemessen am fertigen Baum. **81 Prüfungen**. 🟢 **Und zusätzlich gegen BEIDE übernehmenden Projekte gefahren** (`--strict-overlay`) – dort fielen zwei strukturelle Befunde an Prüfung 78 und 79, beide mit D-326 behoben |
+| 8 | `forbidden-terms.txt` im Release leer | MUSS | 🟢 **Gemessen: nur Kommentarzeilen, kein Begriff** |
+| 9 | **Manuelle Stichprobe** auf projekt-, kunden- oder personenspezifische Inhalte | MUSS | 🟢 **DURCHGEFÜHRT – und sie hat geliefert.** Der Owner hat den **Klarnamen im Copyright-Vermerk als falsch geschrieben erkannt** (D-323, Nachtrag): Das Werkzeug hatte die Schreibweise aus dem Autorenfeld der Git-Historie abgeleitet, und **die führt ihn in allen 122 Merge-Commits falsch**. 🔴 **Keine der 81 Prüfungen konnte das sehen** – die Inhaltsprüfung kennt keinen Personennamen (`K-109`). ➡️ *Genau dafür verlangt die Checkliste die Stichprobe **zusätzlich** zur automatischen Prüfung, und hier hat der Satz seinen Beleg bekommen.* **Die sechzehn geänderten Träger liegen in Abschnitt 6 vor** |
+| 10 | Beispiele synthetisch gekennzeichnet, Platzhalterregister aktuell | MUSS | 🟢 Prüfungen 7, 14, 50 |
+
+## 3. Produktstand der KI-Client
+
+| # | Prüfpunkt | Gewicht | Gemessener Stand |
+|---|---|---|---|
+| 11 | **Aktualitätsprüfung** gegen die offizielle Clientdokumentation | MUSS | 🟢 **Gefahren am 2026-09-18 als `FW-AK-01`** (`tests/protocols/2026-09-18-FW-AK-01.md`): **22 Quellen** (17 `QD`, 5 `QC`), **beide** Produkt-Changelogs – `devin-desktop` bis **3.10.31** (16.09.), `claude-code` bis **2.1.275** (17.09.). **Zwölf Quellen trugen ihren Beleg unverändert, zehn nicht; dreizehn Befunde, sämtlich als `CR-2026-087` erfaßt.** ⚠️ **Die Frist ist fünf Tage und sechs Releases** – der Prüfpunkt verlangt *„durchgeführt"*, nicht *„am Tag der Freigabe durchgeführt"*. Was danach kam, ist Produktbeobachtung nach `RELEASE_PROCESS.md` Abschnitt 6 |
+| 12 | Produktänderungen mit Regelwirkung als Änderungsanträge behandelt | MUSS | 🟢 **`CR-2026-087` mit dreizehn Befunden**, vier davon als Klärungspunkte `K-62` bis `K-65`; `K-62` ist mit `0.85.0` geschlossen |
+
+## 4. Tests
+
+| # | Prüfpunkt | Gewicht | Gemessener Stand |
+|---|---|---|---|
+| 13 | Testkatalog vollständig ausgeführt | MUSS | 🟢 **125 Ergebniszellen** – 38 im zentralen Katalog, 87 in dreizehn Testblättern. Sechs Meßtage, zwei Nachläufe |
+| 14 | **(ab 1.0.0)** Kein Testfall auf `offen` | MUSS | 🟢 **Kriterium 2 von D-11 = 0**, von Prüfung 46 ausgerechnet. Kette: `111 → … → 5 → 0`, erfüllt seit `0.84.0` |
+| 15 | Skill-Testfälle für geänderte Skills erneut ausgeführt | MUSS | 🟢 **Kein Gegenstand: dieses Release ändert keinen Skill** |
+| 16 | Hook- und Validierungsskripte laufen fehlerfrei | MUSS | 🟢 **Sondenlauf in beiden Kodierungsumgebungen, zweimal gefahren**: **322 angemeldete Einheiten**, **447 Ergebniszeilen**, **0 Unterschiede in 480 Zeilen** im zeilengleichen Vergleich nach D-49 – und der **vierte Durchgang zeilengleich zum dritten**. 🔴 **Eine Grenze, benannt:** Der letzte Handgriff an diesem Baum ist die **Freigabezeile in Abschnitt 7.1** – *der fertige Baum entsteht erst mit der Handlung des Menschen, und deshalb kann kein Werkzeug gegen ihn abnehmen.* Die Deckung ist ein Validatorlauf danach; **Prüfung 81** fängt dabei den Fall, der in dieser Sitzung zweimal eintrat |
+| 17 | Jedes Abnahmeprotokoll trägt seine Gegenzeichnung | MUSS | 🟢 **Prüfung 80.** Zehn Abnahmeprotokolle, alle mit Abschnitt und ohne offenes `<TBD>`; **sieben davon ausdrücklich als Selbstgegenzeichnung ausgewiesen** (D-319) |
+| 18 | Vollständiger Durchlauf `M1`→`M2`→`M3`→`M4` auf dem Übungsrepositorium | SOLL | ⚪ **NICHT GEFAHREN, und das steht hier statt zu fehlen.** Er braucht ein Sitzungskontingent – ein Modelllauf über vier Betriebsmodi. Er ist ein `SOLL`, kein `MUSS`. ➡️ *Ein nicht gefahrenes `SOLL` ist ein Meßwert, ein verschwiegenes ist ein Befund* |
+
+## 5. Abschluß
+
+| # | Prüfpunkt | Gewicht | Gemessener Stand |
+|---|---|---|---|
+| 19 | `VERSION` erhöht, `CHANGELOG.md` ergänzt | MUSS | 🟢 `VERSION` = **`1.0.0`**; `CHANGELOG.md` mit Änderungen, **Migrationshinweisen** (keine Overlay-Felder berührt; ⚠️ das **Versionierungsregime** ändert sich) und **bekannten Einschränkungen** |
+| 20 | **Release-Archiv erzeugt und abgelegt; übernehmende Projekte informiert** | MUSS | 🔴 **Das Verfahren steht seit diesem Release** (`RELEASE_PROCESS.md` Abschnitt 4.1, D-321) – **bis `0.91.0` gab es keines, und `git tag` lieferte in 106 Release-Commits null.** 🔴 **Schritt 1, die signierte Marke, ist die Handlung des Menschen** und liegt als Befehl vor (Abschnitt 7). 🟢 **Übernehmende Projekte: beide auf `1.0.0` gehoben**, Bestandsliste in `governance/ADOPTION_REGISTRY.md` |
+| 21 | **Freigabe des Releases durch den Framework Owner dokumentiert** | MUSS | 🔴 **BRAUCHT EINEN MENSCHEN. Nicht delegierbar** (`V1`, `V2`, `AGENTS.md` Abschnitt 16, D-319). Die Zeile in Abschnitt 7 ist vorbereitet und **leer**; der Freigabe-Commit ist die Unterschrift |
+| 22 | **(ab 1.0.0)** Alle Core-Module, Skills und Packs über `entwurf` | MUSS | 🟢 **Kriterium 3 von D-11 = 0.** 81 Träger mit Steckbriefzeile, **77 auf `pilot`**, vier Ausfüllschlitze, **0 auf `entwurf`** |
+| 23 | **(ab 1.0.0)** Kein Decision Record auf `entschieden (Vorschlag)` | MUSS | 🟢 **Kriterium 4 von D-11 = 0**, erfüllt seit `0.49.0`. **327 Decision Records** |
+| 24 | **(ab 1.0.0)** Übernahme in mindestens ein zweites Projekt nachgewiesen | MUSS | 🟢 **Kriterium 5 von D-11 erfüllt** – **zwei** übernehmende Projekte, beide mit `1.0.0` gehoben (`FW-RE-01`). ⚠️ **Prüfung 46 zählt dieses Kriterium ausdrücklich nicht** (eine Enthaltung), und genau deshalb stand sein Nachweis bis heute drei Releases zurück. **Ab jetzt führt ihn `governance/ADOPTION_REGISTRY.md`** (D-322) |
+
+---
+
+## 6. Vorlage für die manuelle Stichprobe (Prüfpunkt 9)
+
+**Sechzehn Träger sind in diesem Release geändert oder neu.** Kein Core-Modul, keine
+Regelablage, kein Skill, kein Prompt, keine Checkliste.
+
+⚠️ **Diese Zahl stand hier zuerst auf „dreizehn", während die Tabelle darunter sechzehn
+führte** – gezählt vor den drei Trägern, die bei der Umsetzung dazukamen (`D-326`,
+dieses Protokoll, die Übergabe). *Der Durchgang vor dem Commit trägt sich zum
+siebenunddreißigsten Mal.*
+
+| Träger | Art | Worauf zu sehen ist |
+|---|---|---|
+| `.gitattributes` | **neu** | Eine Zeile Wirkung, sechzehn Zeilen Begründung |
+| `.koolie/core/VERSION` | geändert | `1.0.0` |
+| `.koolie/core/CHANGELOG.md` | geändert | Der Release-Eintrag. **ASCII-Umschrift geprüft: null Umlaute** |
+| `.koolie/core/LICENSE-HINWEIS.md` | geändert | 🔴 **Hier steht der Klarname des Rechteinhabers** – die einzige Personennennung im ganzen Kern, gewollt nach D-323. **Das ist der Träger, den die Stichprobe zuerst ansieht** |
+| `.koolie/core/governance/DECISION_LOG.md` | geändert | D-320 bis D-327, K-108, K-109; K-81 und K-107 geschlossen |
+| `.koolie/core/governance/RELEASE_PROCESS.md` | geändert | Abschnitt 4.1 neu, Version `0.2.0` |
+| `.koolie/core/governance/ADOPTION_REGISTRY.md` | **neu** | ⚠️ **Enthält Pfade dieses Arbeitsplatzes** (`devpacks/…`) – projektneutral formuliert, aber der Punkt, an dem Arbeitsplatzwissen einsickern könnte |
+| `.koolie/core/governance/change-requests/CR-2026-128-…md` | **neu** | Der Antrag mit zwölf Befunden |
+| `.koolie/core/docs/ROADMAP.md` | geändert | Releaseplan: `1.0.0` als *dieses Release* |
+| `.koolie/core/build/doc/00-kopf.md` | geändert | Dokumentversion `1.0.0` |
+| `.koolie/core/build/doc/26-qs-test.md` | geändert | Die drei Zahlen des Prüfapparats |
+| `.koolie/core/tests/TEST_CATALOG.md` | geändert | Sondenmenge `18 bis 81` |
+| `.koolie/core/tests/scripts/validate-framework.py` | geändert | Prüfung 81 neu, Prüfung 78 erweitert |
+| `.koolie/core/tests/scripts/probe-pruefungen.py` | geändert | Fünf neue Sondeneinheiten |
+| `.koolie/core/tests/protocols/2026-09-23-freigabelauf-1.0.0.md` | **neu** | Dieses Protokoll |
+| `UEBERGABE.md` | geändert | Die Übergabe zum Stand `1.0.0` |
+
+⚠️ **Die automatische Prüfung deckt davon:** Secret-Muster, E-Mail-Adressen,
+IP-Adressen, interne Hostnamen, URLs außerhalb der Allowlist, projektlokale Sperrbegriffe,
+Produktnamen im Kern und Arbeitsplatzpfade (Prüfungen 6, 14, 71). 🔴 **Sie deckt
+NICHT: Personennamen** – gemessen in diesem Release, und als `K-109` aufgenommen. **Genau
+dafür verlangt die Checkliste die Stichprobe zusätzlich.**
+
+---
+
+## 7. Die zwei Handlungen des Menschen
+
+### 7.1 Die Freigabe (Prüfpunkt 21)
+
+**Diese Zeile ist leer und bleibt es, bis der Owner sie füllt.** Die Form folgt D-319: Die
+Zeile sagt, **was** freigegeben wurde – der Commit sagt, **wer**.
+
+| Rolle | Datum | Umfang |
+|---|---|---|
+| `René Hildebrand` | `2026-09-23` | `Protokoll gelesen und Träger durchgesehen.` |
+
+### 7.2 Die signierte Marke (Prüfpunkt 20, Schritt 1)
+
+🔴 **Ein Werkzeug kann sie setzen und mit dem vorhandenen Schlüssel sogar signieren – und
+genau deshalb darf es nicht** (D-321). Die Befehle liegen in `FREIGABE-1.0.0.txt` neben
+der Commit-Nachricht.
+
+🟢 **Gesetzt am 2026-09-23 durch den Framework Owner:** `v1.0.0`, annotiert und
+SSH-signiert.
+
+> 🔴 **Und die Verifikation schlug fehl, obwohl die Signatur da war.** `git tag -v v1.0.0`
+> gab die Tag-Nachricht aus und schwieg über die Signatur – Ursache war ein fehlendes
+> `gpg.ssh.allowedSignersFile`, nicht eine fehlende Unterschrift (**D-327**). Nach der
+> Einrichtung: `Good "git" signature … with ED25519 key`.
+> ➡️ *Eine Signatur ohne hinterlegten Unterzeichner belegt, daß **jemand** mit diesem
+> Schlüssel unterschrieben hat – nicht, **wem** der Schlüssel gehört.* Der Ablauf steht
+> seither in `RELEASE_PROCESS.md` Abschnitt 4.1.
+
+---
+
+## 8. Was dieser Lauf **nicht** behauptet
+
+- **Er erklärt das Framework nicht für im Realbetrieb erprobt.** D-11 verlangt das
+  ausdrücklich nicht; `AP8` bis `AP10` sind projektseitig und **keine** Vorbedingung für
+  `1.0.0` (`CR-2026-001`).
+- **Er sagt nichts über den Produktstand nach dem 2026-09-18.** Siehe Prüfpunkt 11.
+- **Er zählt die offenen Klärungspunkte nicht.** Sie sind kein Prüfpunkt von `FW-CL-11`
+  und kein Kriterium von D-11; ihre Zahl bleibt nach `K-100` unermittelbar.
+- **Er entscheidet die Veröffentlichung nicht** (`K-108`).

package/.koolie/core/tests/protocols/2026-09-23-gegenzeichnung-rollenfrage.md

@@ -0,0 +1,198 @@
+# Protokoll: Die Gegenzeichnung – eine Rollenfrage, kein Arbeitsposten
+
+| Feld | Inhalt |
+|---|---|
+| Datum | 2026-09-23 |
+| Release | `0.91.0` |
+| Änderungsantrag | `CR-2026-127` (E1 bis E5 entschieden) |
+| Art | Governance-Entscheidung, eine neue Prüfung, sieben Gegenzeichnungen – **keine Sitzung, kein Kontingent, kein Modelllauf** |
+| Gegenstand | Der letzte offene Posten von `AP11`: die Gegenzeichnung der Protokolle |
+| Ergebnis | 🟢 **`AP11` ist abgeschlossen.** **D-319**, **Prüfung 80**, `K-107` neu. 🔴 **Der eigene Vorschlag zu E3 ist im Durchgang gefallen** |
+
+---
+
+## 1. Der Befund, der den Posten getragen hat, war schon gebucht – und unvollständig
+
+`0.89.0` hat die Gegenzeichnung nicht gefahren und den Grund als **Abgrenzung**
+aufgeschrieben:
+
+> *„Eine Gegenzeichnung ist die Handlung einer **zweiten Rolle**. Ein Werkzeug, das
+> `<TBD: Rolle>` durch einen Rollennamen ersetzt, **fälscht sie**."*
+
+**Das trägt.** Was dort fehlte, ist die Folge: **An diesem Framework arbeitet eine
+Person.** Es gibt keine zweite Rolle, und damit war die Pflicht in ihrer damaligen Form
+**nicht erfüllbar** – nicht aus Nachlässigkeit, sondern konstruktiv.
+
+➡️ ***Eine Pflicht, die niemand erfüllen kann, ist ein Befund über ihre Formulierung.***
+🔴 **Das ist die Bauform *die Regel mit leerer Schnittmenge*** (D-189, `K-72`) – bisher
+an einer Testzelle gemessen, hier **an einer Governance-Regel**.
+
+## 2. Der Zuschnitt ist gemessen, nicht gewählt
+
+**Nicht jedes Protokoll ist eine Abnahme.** Von 125 sind die meisten Arbeits- und
+Meßprotokolle, die ihren Beleg in sich tragen. Eine Gegenzeichnung sagt etwas anderes:
+*Eine zweite Person hat geprüft und steht dafür ein.*
+
+| Menge | Zählregel A (nur Überschrift) | Zählregel B (auch Tabellenzeile) |
+|---|---|---|
+| **Gesamtbestand** | 13 / 45 / 64 von **122** (Stand `0.89.0`) | 17 / 47 / 61 von **125** (Stand `0.91.0`) |
+| **die zehn Abnahmeprotokolle** | **3 / 2 / 5** | **3 / 2 / 5** |
+
+➡️ ***Ein Gegenstand, der unter zwei Zählregeln derselbe ist, ist der richtige
+Gegenstand.*** Der Gesamtbestand ist es nicht: Er gibt zwei Zahlen, und keine davon ist
+nachprüfbar falsch.
+
+## 3. 🔴 Der eigene Vorschlag zu E3 ist im Durchgang gefallen
+
+`CR-2026-127` E3 schlug vor, die offenen `<TBD>` **zu entfernen**, wo der Abschnitt nach
+der Abgrenzung entfällt. **Beim Hinsehen kippt das.**
+
+| Befund | Folge |
+|---|---|
+| Es sind **45** Träger, nicht wenige | ein Sweep, keine Handreichung |
+| Sie stehen in **drei verschiedenen Tabellenformen** | eine einzelne Metadatenzeile, ein Abschnitt mit voll-`<TBD>`-Zeile, ein Abschnitt mit `<TBD: Rolle>`/`<TBD: Datum>` |
+| Protokolle sind **Chronik** (D-273) | *„die Chronik beschreibt einen vergangenen Zustand und wandert nicht mit"* |
+
+🔴 **Und das `<TBD>` ist dort inhaltlich richtig:** Es hält fest, daß zu jenem Zeitpunkt
+eine Gegenzeichnung **vorgesehen und nicht erfolgt** war. ➡️ *Wer eine Aufzeichnung
+nachträglich glattzieht, verliert genau die Angabe, die sie trägt.*
+
+🟢 **Auflösung:** Die Abgrenzung steht **einmal** an den drei Stellen, an denen sie gilt –
+`checklists/11-framework-release.md`, `tests/protocols/README.md`, `governance/RACI.md` –
+und **nicht fünfundvierzigmal in den Aufzeichnungen.**
+
+## 4. 🆕 Die Frage, die erst beim Vorbereiten entstand: Was **ist** die Unterschrift?
+
+Sie stand in keinem Abschnitt des Antrags und ist die wichtigste: **Wenn ein Werkzeug die
+Zeile schreibt – was macht sie dann zu einer Unterschrift?**
+
+🔴 **Eine Fehleinschätzung war dabei zu berichtigen.** Die Vorbereitung hatte zunächst
+gesagt, ein Werkzeug *könne* den Commit nicht setzen. **Es kann.** Git ist auf diesem
+Arbeitsplatz mit der Identität des Owners konfiguriert, und alle Commits der beiden
+vorangegangenen Releases sind so entstanden. **Genau deshalb darf es den Commit für die
+Gegenzeichnung nicht setzen** – die Fälschung wanderte sonst nur aus der Markdown-Zeile in
+die Commit-Metadaten.
+
+🟢 **Die Auflösung (D-319, E5):**
+
+| Träger | Aussage |
+|---|---|
+| die **Zeile** im Protokoll | **WAS** gegengezeichnet wurde: Rolle, Datum, Umfang |
+| der **Commit** | **WER** – die Identität des Owners, gesetzt von ihm |
+
+➡️ *Damit wird die Fälschung **unmöglich** statt nur verboten.* Ein Werkzeug kann den Text
+hinlegen; den Akt kann es nicht vollziehen.
+
+⚠️ **Preis, benannt und gemessen:** Die Commits dieses Repositoriums sind **nicht
+signiert** (`%G?` liefert `N` für jeden). Die Unterschrift ist damit so stark wie der
+Schreibzugriff. `K-107` führt die Frage auf ein signiertes Tag für `1.0.0` weiter.
+
+## 5. Was gezeichnet wurde
+
+| Protokoll | vorher | jetzt |
+|---|---|---|
+| `2026-09-18-FW-AK-01.md` | `<TBD: Rolle>` / `<TBD: Datum>` | gezeichnet |
+| `2026-09-18-FW-KO-05.md` | drei `<TBD>` in einer Zeile | gezeichnet |
+| `2026-09-10-FW-DS-03.md` | **kein Abschnitt** | Abschnitt angelegt, gezeichnet |
+| `2026-09-10-FW-KO-01.md` | **kein Abschnitt** | Abschnitt angelegt, gezeichnet |
+| `2026-09-10-FW-KO-04.md` | **kein Abschnitt** | Abschnitt angelegt, gezeichnet |
+| `2026-09-10-FW-RE-02.md` | **kein Abschnitt** | Abschnitt angelegt, gezeichnet |
+| `2026-09-10-FW-ZA-05.md` | **kein Abschnitt** | Abschnitt angelegt, gezeichnet |
+
+**Die drei übrigen** – `FW-KO-02`, `FW-VN-01` und dessen Wiederholung – trugen ihre
+Gegenzeichnung schon und sind **unberührt**.
+
+⚠️ **Der Umfang steht so da, wie der Owner ihn genannt hat:** *„Protokoll vollständig
+gelesen"*. **Keine Silbe mehr.** Eine Vorbereitung, die dem Gegenzeichner Prüfungen
+zuschreibt, die er nicht genannt hat, ist dieselbe Fälschung mit besseren Manieren.
+
+## 6. Prüfung 80 – und sie war beim ersten Lauf rot über genau die sieben
+
+**Fünf Einheiten, und die letzte trägt die Entscheidung:**
+
+| Einheit | Gegenstand | Ergebnis |
+|---|---|---|
+| Sonde `80a` | einem Abnahmeprotokoll fehlt der Abschnitt | 🟢 mit Dateinamen gemeldet |
+| Sonde `80b` | ein offenes `<TBD>` im Abschnitt | 🟢 gemeldet |
+| Sonde `80c` | kein Träger paßt mehr auf das Namensmuster | 🟢 verlorener Anker gemeldet |
+| Gegenprobe `80a` | ausgelieferter Bestand | 🟢 läuft durch |
+| Gegenprobe `80b` | ein offenes `<TBD>` in einem **Arbeitsprotokoll** | 🟢 **bleibt unbeanstandet** |
+
+🔴 **Gegenprobe `80b` ist die, die man weglassen würde, und sie trägt den ganzen
+Zuschnitt.** Ohne sie wäre D-319 eine Behauptung im Kopfkommentar statt eine gemessene
+Eigenschaft – und die Prüfung verlangte still die Gegenzeichnung von 125 Protokollen
+statt von zehn.
+
+🔴 **Jede Sonde prüft ihre eigene Fundstelle.** Der Bestand trägt sieben frisch
+gezeichnete Protokolle; eine Sonde, die nur auf den Meldungstext prüft, bestünde **auch
+ohne Präparation**. Der Erwartungstext nennt deshalb den **Dateinamen** des Opfers –
+dieselbe Bauform wie Sonde `75a`.
+
+## 7. Der Durchgang vor dem Commit – zum sechsunddreißigsten Mal in Folge
+
+| Zahl oder Aussage | zuerst genannt | nachgezählt |
+|---|---|---|
+| E3: die offenen `<TBD>` | „entfernen" (eigener Vorschlag) | 🔴 **stehenlassen** – 45 Träger, drei Tabellenformen, Chronik (D-273) |
+| *„ein Werkzeug kann den Commit nicht setzen"* | in der Vorbereitung behauptet | 🔴 **falsch** – es kann, und genau deshalb darf es nicht |
+| Protokolle gesamt | „122" (Stand `0.89.0`) | ⚠️ **125**, und die Zahl hängt an der Zählregel |
+| offene Gegenzeichnungen gesamt | 13 / 45 / 64 | ⚠️ **17 / 47 / 61** unter der zweiten Regel – *zwei Regeln, zwei Zahlen* |
+| die zehn Abnahmeprotokolle | 3 / 2 / 5 | 🟢 **3 / 2 / 5** unter **beiden** Regeln |
+| Prüfungen | – | 🟢 **80** |
+
+> 🔴 **Zwei der sechs Zeilen sind eigene Aussagen dieser Vorbereitung**, und beide sind
+> gefallen: der Vorschlag zu E3 und der Satz über den Commit. *Auch eine Aussage, die man
+> eine Stunde vorher selbst geschrieben hat, gehört an ihrem Gegenstand nachgesehen.*
+
+## 8. Abnahme
+
+| Schritt | Ergebnis |
+|---|---|
+| `assemble.py` (`devin-desktop`) | 🟢 1.975.665 Zeichen, 12.902 Zeilen |
+| `build-docx.py` (`devin-desktop`) | 🟢 `Koolie_v0.91.0_devin-desktop.docx`, 1.979.134 Bytes, **8 Diagramme** |
+| `assemble.py --client claude-code` | 🟢 1.979.336 Zeichen, 12.820 Zeilen |
+| `build-docx.py` (`claude-code`) | 🟢 `Koolie_v0.91.0_claude-code.docx`, 1.980.448 Bytes, **8 Diagramme** |
+| `validate-framework.py --root .` | 🟢 **0 Fehler, 0 Warnungen** |
+| `probe-pruefungen.py .` **ohne** `PYTHONIOENCODING` | 🟢 **Exit 0** – **441 Einheiten** (264 Sonden, 154 Gegenproben, 23 Selbstproben), 3.856,4 s in **486,3 s** Wanduhr |
+| `probe-pruefungen.py .` **mit** `PYTHONIOENCODING=utf-8` | 🟢 **Exit 0**, dieselben 441 Einheiten, 3.686,9 s in **461,0 s** Wanduhr |
+| Zeilengleicher Vergleich nach D-49 | 🟢 **0 Unterschiede in 473 Zeilen** oberhalb der Trennlinie |
+| Zählung der Einheiten | 🔴 **Nachgezählt:** 264 + 154 + 23 = **441**. `0.90.0` meldete 436; die fünf neuen sind die Sonden `80a` bis `80c` und die Gegenproben `80a` und `80b` |
+
+🔴 **Prüfung 80 war vor der Gegenzeichnung rot – über genau die sieben Protokolle.** Der
+grüne Lauf hier ist deshalb kein Formalismus: *Die Abnahme konnte erst gelingen, nachdem
+ein Mensch gezeichnet hat.*
+
+**Drei Durchgänge.**
+
+| Durchgang | Baum | Ergebnis |
+|---|---|---|
+| 1 | Teillauf `--nur 80`, vor dem vollen Apparat | 🟢 alle fünf Einheiten bestanden |
+| 2 | voller Lauf, beide Umgebungen | 🟢 **473 Zeilen, 0 Unterschiede**, 441 Einheiten |
+| 3 | **Abnahmelauf**, nach dem Eintrag dieses Abschnitts | 🟢 Exit 0 in beiden Umgebungen, **473 Zeilen, 0 Unterschiede**, 441 Einheiten – und **zeilengleich zum zweiten Durchgang**. 🟢 *Das belegt, was es belegen soll:* Der Eintrag dieses Abschnitts ist Prosa in einem Träger, auf den keine Sonde zugreift – und die Ausgabe ist Zeile für Zeile dieselbe |
+| 4 | **Bestätigungslauf**, nach der Berichtigung der Zeilenenden | 🟢 Exit 0 in beiden Umgebungen, **473 Zeilen, 0 Unterschiede**, 441 Einheiten – und **zeilengleich zum dritten Durchgang**. 🔴 **Anlaß:** Der Eintrag der Abnahme hat **28 reine LF-Zeilenenden** in einen CRLF-Bestand geschleppt. **Keine Prüfung erfaßt das** – gefunden hat es der nächste Suchtext, der deshalb nicht mehr traf. *Ein Sondenlauf mißt den Baum, in dem er startet*, also wurde er neu gefahren |
+⚠️ **Nach der Zeile über Durchgang 4 ist nicht erneut gefahren worden.** Belegt ist die Zeilengleichheit durch die Durchgänge 2 → 3 und 3 → 4, zwischen denen ebenfalls nur Prosa in genau diesem Träger stand – auf den keine Sonde zugreift. *Eine Abnahmetabelle, die einen Lauf behauptet, den es nicht gab, ist derselbe Befundtyp wie die Zusage über einen Vorgang, den niemand ausgeführt hat* (D-309).
+
+
+⚠️ **Die Laufzeiten sind nach dem Lauf eingetragen** und stehen unterhalb der Trennlinie –
+nach D-94 nicht Teil des zeilengleichen Vergleichs.
+
+---
+
+## 9. Was **nicht** gefahren wurde, mit gemessenem Grund
+
+| Posten | Warum nicht |
+|---|---|
+| **Signatur der Commits** | `K-107`. Sie ist kein Posten dieses Releases, sondern eine Entscheidung über das Verfahren – und sie berührt die Veröffentlichung (Klarnamen in 109 Releases Historie) |
+| **`K-100`** | unverändert offen und teurer als gebucht: Ohne Statusvokabular bleibt die Zahl der offenen Klärungspunkte auch nach der Verschiebung unzählbar |
+| **Die drei übrigen menschlichen Prüfpunkte von `FW-CL-11`** | manuelle Stichprobe, Aktualitätsprüfung gegen die Clientdokumentation, dokumentierte Freigabe. Sie gehören in den Freigabelauf `AP12` und stehen im Vorbereitungsprotokoll vom selben Tag |
+
+## 10. Gegenzeichnung
+
+Rollen statt Personen (`framework/runtime/rules/20-project-overlay.md`).
+
+| Rolle | Datum | Umfang |
+|---|---|---|
+| Durchführung (KI-gestützt, Sitzung) | 2026-09-23 | Vorbereitung, Prüfung 80, sieben Abschnitte |
+| Gegenzeichnung: `<FRAMEWORK_OWNER>` | 2026-09-23 | Protokoll vollständig gelesen |
+
+🔴 **Selbstgegenzeichnung: keine zweite Rolle vorhanden** (D-319). *Die Zeile sagt, WAS
+gegengezeichnet wurde; der Commit sagt, WER.*

package/.koolie/core/tests/protocols/2026-09-23-reihenfolge-des-hebens.md

@@ -0,0 +1,220 @@
+# Protokoll: Die Reihenfolge des Hebens – ein Prüfpunkt und sein eigener Zeitpunkt
+
+| Feld | Inhalt |
+|---|---|
+| Datum | 2026-09-23 |
+| Release | **`1.1.0`** |
+| Änderungsantrag | `CR-2026-130` |
+| Art | **Arbeitsprotokoll.** Gegenstand sind ein Prüfpunkt, ein Verfahren und der ausgelieferte Bestand zweier Projekte |
+| Prüfmittel | `review` – Auszählung im Bestand, dazu der Validator in beiden übernehmenden Projekten |
+| Ergebnis | 🟢 **Die offene Frage aus `1.0.1` ist beantwortet: ja zu beidem.** 🔴 **Und der Schuldposten war größer als gebucht – an drei Stellen statt an einer** |
+
+> 🔴 **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ß
+
+Die Übergabe zu `1.0.1` hat einen Schuldposten gebucht und die Frage ausdrücklich offen
+gelassen:
+
+> ⚠️ *„Zu prüfen: Gehört das Heben vor den Release-Commit, und muß `RELEASE_PROCESS.md`
+> Abschnitt 4.1 die Reihenfolge nennen? Heute sagt er sie nicht."*
+
+**Anlaß war der zweite Fall in zwei Releases.** `1.0.0` hat die Bestandsliste angelegt,
+und ihr erster Eintrag war zugleich ihr erster Befund: beide übernehmenden Projekte
+standen **drei Releases** hinter `main`. `1.0.1` hat es wiederholt.
+
+## 2. Der Vorbedingungsdurchgang – neunzehnmal in Folge der billigste Befund
+
+Gemessen **vor dem ersten Handgriff**, elf Befunde. Die beiden, die diesen Posten
+betreffen:
+
+| # | Befund | gemessen an |
+|---|---|---|
+| **V7** | 🔴 Die Word-Fassung stand auf `v1.0.0`. `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 | `build/out/` führte `Koolie_v1.0.0_*.docx`, keine Fassung `v1.0.1` |
+| **V9** | 🔴 **Die Bestandsliste war an ZWEI Stellen falsch, nicht an einer** | siehe Abschnitt 3 |
+
+## 3. Die Messung: die Liste wird an einer Stelle geführt und an zwei ausgeliefert
+
+| Ort | `.koolie/core/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 erreichte 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, daß ein Verfahrensschritt allein hier nicht
+getragen hätte:** Er stünde im Framework und wäre in beiden Installationen unbelegt.
+
+## 4. Der Befund am Prüfpunkt selbst – er ist größer als der Schuldposten
+
+Prüfpunkt 20 von `FW-CL-11` lautete:
+
+> *„**MUSS** Release-Archiv erzeugt und abgelegt; übernehmende Projekte informiert."*
+
+**Ein Haken, zwei Gegenstände** – und ihre frühesten möglichen Zeitpunkte liegen auf
+entgegengesetzten Seiten des Release-Commits:
+
+| Hälfte | frühestens | warum |
+|---|---|---|
+| Archiv erzeugt und abgelegt | **nach** dem Commit | 4.1 baut das Archiv aus der **Marke**, und die sitzt auf dem Release-Commit |
+| Projekte informiert | **vor** dem Commit | die Quelle ist der Arbeitsbaum, und der trägt die neue `VERSION` bereits |
+
+🔴 **Die Checkliste wird vor dem Release durchgegangen** – ihre eigene Kopfzeile sagt es.
+**Die erste Hälfte konnte zu diesem Zeitpunkt noch nie erfüllt sein**, auch nicht in
+`1.0.0`, dem Release, das das Archivverfahren eingeführt hat.
+
+➡️ ***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.***
+
+## 5. Warum das Heben vor den Commit gehört – und es ist nicht die Ordentlichkeit einer Liste
+
+| 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 an zwei Stellen falsch |
+
+➡️ ***Das Heben ist ein Lauf gegen eine fremde Installation, nicht die Fortschreibung
+einer Tabelle.*** Wer es hinter den Merge legt, verlegt einen Prüfschritt hinter die
+Freigabe, die er absichern soll.
+
+## 6. Prüfung 82 – und die Gegenprobe, die man weglassen würde
+
+Fünf Einheiten, gefahren am 2026-09-23:
+
+| Art | Kennung | Gegenstand | Ergebnis |
+|---|---|---|---|
+| Gegenprobe | `82a` | der ausgelieferte Bestand läuft durch, und die Prüfung ist dabei nachweislich gelaufen | 🟢 |
+| **Gegenprobe** | **`82b`** | 🔴 **die D-299-Probe:** ein übernehmendes Projekt, das Releases zurückliegt, muß **grün** sein – Liste und `VERSION` kommen byte-gleich aus demselben Release | 🟢 |
+| Sonde | `82a` | eine Bestandszeile auf einem anderen Stand wird gemeldet, mit dem Projektnamen | 🟢 |
+| Sonde | `82b` | der verlorene Anker (Spaltenüberschrift entfernt) wird gemeldet, statt leise zu bestehen | 🟢 |
+| Sonde | `82c` | eine Tabelle ohne Datenzeile meldet eine Warnung und **kein** Meßergebnis | 🟢 |
+
+🔴 **`82b` ist die, die man weglassen würde, und sie trägt den ganzen Zuschnitt.** Ohne
+sie wäre die Installationsfestigkeit eine Behauptung im Kopfkommentar statt eine
+gemessene Eigenschaft – und genau das hat `0.90.0` zweimal gekostet (D-326).
+
+**Keine Einheit hält eine Versionsnummer wörtlich.** Sie lesen den Stand aus `VERSION`
+und rechnen daran; eine Sonde, die einen Wert mitpflegen muß, fällt beim nächsten
+Release aus, und zwar als scheinbarer Befund.
+
+⚠️ **Grenze, benannt: Prüfung 82 mißt die Behauptung der Zeile, nicht den Stand des
+Projekts.** 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*.
+
+## 7. 🔴 Zwei Befunde fielen erst beim Umsetzen
+
+### 7.1 Das Werkzeug des Hebens war an den Commit gebunden (D-333)
+
+Der eingespielte Ablauf hebt so:
+
+> *„`rm -rf .koolie/core`, dann `git -C ../koolie archive HEAD .koolie/core | tar -x -C .`"*
+
+und die Arbeitsanweisung sagt dazu wörtlich: *„für den echten Vorgang **nach dem Merge**
+`git archive`"*.
+
+🔴 **Das ist genau das, was D-330 ausschließt.** Vor dem Commit trägt `HEAD` das Release
+noch nicht; ein so gehobenes Projekt bekäme den Stand von vorhin. **Zwei Regeln, die
+einander die Voraussetzung entziehen** – die Bauform aus D-146 (`K-54`), hier an einem
+Ablauf statt an einem Regeltext.
+
+🟢 **Gemessen, und der Ersatz ist gleich groß:**
+
+```
+git ls-files -z .koolie/core | tar --null -T - -cf -   ->  519 Träger (Arbeitsbaum)
+git archive HEAD .koolie/core                          ->  517 Träger (committet)
+
+diff der beiden Mengen:
+  + .koolie/core/governance/change-requests/CR-2026-130-reihenfolge-des-hebens.md
+  + .koolie/core/tests/protocols/2026-09-23-reihenfolge-des-hebens.md
+```
+
+🔴 **Die Differenz sind genau der Änderungsantrag und das Protokoll dieses Releases.**
+➡️ ***Wer vor dem Commit mit `git archive HEAD` hebt, liefert ein Projekt aus, dem der
+Antrag und das Protokoll des Releases fehlen*** – der Beleg für D-333 in Reinform.
+⚠️ **Nachgezählt im Durchgang vor dem Commit:** Beim ersten Messen lagen beide Verfahren
+bei **517**, weil die neuen Träger noch nicht verfolgt waren. *Eine Zahl, die man an
+einem Zwischenstand mißt, beschreibt den Zwischenstand.*
+
+⚠️ **Die Beschränkung auf das Verfolgte ist nicht verzichtbar** – sie hält Bytecode und
+`build/out/` draußen, und genau dafür stand `git archive` da.
+
+### 7.2 Das Heben ist der LETZTE Eingriff in den Kern, nicht der erste (D-333)
+
+🔴 **Unmittelbar nach dem ersten Durchlauf zugeschnappt.** Die **Overlay-Version** steht
+erst **nach** dem Heben fest – sie ist eine Eigenschaft des Projekts, nicht des
+Releases. Die Bestandsliste mußte deshalb noch einmal angefaßt werden, und danach trugen
+beide Projekte einen Stand, den es nicht gibt.
+
+➡️ ***Jede Änderung an `.koolie/core/**` nach dem Heben macht die Kopien wieder falsch.***
+
+🟢 **Die Übergabe darf danach noch geschrieben werden** – sie liegt **außerhalb** des
+Kerns (D-216) und wird in kein Projekt installiert. *Sie ist der einzige Träger des
+Release-Commits, der das darf, und sie darf es nur deshalb.*
+
+## 8. Das Heben, gefahren – und was es gekostet hat
+
+| Projekt | Framework | Overlay | Validator `--strict-overlay` |
+|---|---|---|---|
+| `devpacks/otp-generator` | `1.0.1` → **`1.1.0`** | `0.3.2` → **`0.3.3`** | **1 Fehler, 2 Warnungen** – identisch mit dem Stand vor dem Heben. Der Fehler ist Projektarbeit (gesperrter Begriff in `CHANGELOG.md`) |
+| `devpacks/test-devin-framework` | `1.0.1` → **`1.1.0`** | `1.0.1` → **`1.1.0`** | 🟢 **0 Fehler, 1 Warnung** – die Warnung ist `K-88` (Laufzeitfassung 6.023 von 6.000 Zeichen, SOLL) |
+
+🟢 **Prüfung 82 ist in beiden Projekten grün.** Das ist der Nachweis, daß die
+Reihenfolge trägt – und derselbe Lauf wäre vor diesem Release in beiden rot gewesen.
+
+⚠️ **Der Overlay-Wert steht in DREI Trägern, und der Validator meldet sie
+nacheinander.** Beim Piloten ist genau das eingetreten: Erst `OVERLAY.md`, dann das
+Manifest, dann die Laufzeitfassung – drei Läufe für einen Vorgang. **Beim
+Übungsrepositorium, wo alle drei gemeinsam gesetzt wurden, trat die zweite Meldung nie
+auf.** *Die Lehre stand in der Arbeitsanweisung und ist trotzdem zugeschnappt.*
+
+## 8a. 🔴 Ein dritter Befund fiel beim Setzen der Marke
+
+**Der Antrag führte als `E7`:** *„`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.** Beide vorhandenen Marken tragen sie:
+
+```
+v1.0.0   … Alle fuenf Kriterien aus D-11 erfuellt.
+         Freigegeben durch den Framework Owner am 2026-09-23.
+v1.0.1   … CR-2026-129, D-328.
+         Freigegeben durch den Framework Owner am 2026-09-23.
+```
+
+und zwar **innerhalb der Signatur**. ➡️ ***Die Marke ist die Freigabe*** – und das
+bestätigt D-334 an seinem eigenen Gegenstand: Der Commit trägt keine Unterschrift, die
+**Marke** trägt sie.
+
+🔴 **Was bleibt, ist ein anderer Befund: Kein Träger schreibt es vor.** Abschnitt 4.1
+verlangte von der Markennachricht *„Release, Antrag und die Entscheidungen"* – die
+Freigabe stand dort nicht, und `FW-CL-11` nannte 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.**
+
+🟢 **Aufgelöst:** Abschnitt 4.1 Schritt 4 nennt die Freigabezeile als Pflichtbestandteil,
+`FW-CL-11` nennt die Marke als ihren Ort. ⚠️ **Keine Prüfung kann das durchsetzen** – der
+Markentext liegt im Tag-Objekt, nicht im Arbeitsbaum (`K-111`).
+
+## 9. Was dieses Release nicht leistet
+
+- **Prüfung 82 mißt die Behauptung, nicht die Tatsache** (D-331). Die Projekte liegen
+  außerhalb des Repositoriums; eine Prüfung, die sie sucht, wäre auf jedem anderen
+  Arbeitsplatz rot (D-299).
+- **Keine Prüfung erreicht die Erzeugnisse der Lieferung** – Hauptdokument und
+  Word-Fassung unter `build/out/`, das Archiv ganz außerhalb. Der Ersatz ist an beiden
+  Stellen ein **Verfahrensschritt**, und damit schwächer (`K-110`).
+- **Die Reihenfolge ist an EINEM Release erprobt**, nämlich diesem. Ob sie trägt, sagt
+  das nächste.