@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-137-kopierweg-kern.md

@@ -0,0 +1,144 @@
+# Änderungsantrag `CR-2026-137`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Kopierweg des Kerns – und das Archiv, aus dem er als sicher galt |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-24 |
+| Betroffene Artefakte | `README.md` (Wurzel, Warnsatz am Kopierbefehl); `docs/ADOPTION_GUIDE.md` `0.4.6` (Warnsatz in Abschnitt 2 Schritt 2, Abschnitt 3 Schritt 2, Abschnitt 4); `.koolie/QUELLREPOSITORIUM.md` (Absatz *„Sie wandert nicht in ein Projekt“*); `install.py` (neu `traegt_quellrepo_kennzeichen()` und die Auskunft am Ende des Laufs); `tests/scripts/probe-pruefungen.py` (Bündel `sonden_kennzeichen_im_projekt` **neu**: Sonde `D354`, Gegenprobe `D354a`); `governance/DECISION_LOG.md` (**D-354**); `governance/ADOPTION_REGISTRY.md`; `build/doc/00-kopf.md`, `26-qs-test.md`; `VERSION`, `CHANGELOG.md`, `docs/ROADMAP.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Übernahmeanleitung und Installationswerkzeug |
+| Art | **Korrektur.** Patch-Release nach `RELEASE_PROCESS.md` Abschnitt 1: kein Overlay-Feld berührt, keine neue Regel, **keine neue Prüfung** – eine Auskunft (Bauform von D-349) mit zwei Sondeneinheiten |
+| Dringlichkeit | Regulär; zwei Fragen des Owners vom 2026-09-24 zu `.koolie/QUELLREPOSITORIUM.md` |
+| Status | 🟢 **entschieden am 2026-09-24** (E1 bis E3), umgesetzt mit `1.4.4` |
+
+---
+
+## 1. Anlaß
+
+Der Owner hat am 2026-09-24 zwei Fragen zum Kennzeichen des Quellrepositoriums gestellt
+(D-351):
+
+- **(a)** Braucht die Übernahmeanleitung einen Warnsatz, daß nur `.koolie/core/` und nie
+  ganz `.koolie/` kopiert wird?
+- **(b)** Soll `install.py` melden, wenn es im Ziel `.koolie/QUELLREPOSITORIUM.md` findet?
+
+Beide Anleitungen nennen seit `1.4.1` den richtigen Befehl (`cp -r .koolie/core
+<projekt>/.koolie/`). Ob ein Leser, der das Verzeichnis `.koolie/` vor sich sieht, es
+**ganz** kopiert, sagt keine von beiden.
+
+## 2. Die Gegenprüfung
+
+### 2.1 🔴 Die Annahme der Vorbereitung war falsch: Auch das Release-Archiv trägt das Kennzeichen
+
+Die Vorbereitung ging davon aus, eine Kopie von ganz `.koolie/` sei nur aus dem
+**Arbeitsbaum** gefährlich – dort liegt neben dem Kern das eigene, nicht versionierte
+Overlay des Frameworks (`.koolie/project-overlay/`, `.gitignore` Zeile 36) –, aus dem
+Release-Archiv dagegen harmlos. **Gemessen:**
+
+| Quelle | `.koolie/QUELLREPOSITORIUM.md` | `.koolie/project-overlay/` |
+|---|---|---|
+| Release-Archiv `koolie-1.4.3.tar.gz` | 🔴 **enthalten** – die Datei ist versioniert, `git archive` nimmt sie mit | nicht enthalten |
+| Arbeitsbaum des Frameworks | enthalten | 🔴 **enthalten**, 18 Dateien |
+
+➡️ **Keine der beiden Quellen ist für eine Kopie von ganz `.koolie/` sicher.** Die
+Anleitung, die nur aus einer Quelle harmlos wäre, gibt es nicht – beide sind eine Falle.
+
+### 2.2 Was das Kennzeichen in einem Projekt bewirkt
+
+Wegwerf-Installation: leeres Repositorium, Kern aus dem Arbeitsbaum über `git ls-files`
+(der Weg aus `RELEASE_PROCESS.md` 4.1 Schritt 2), `install.py --client claude-code`,
+committet, `__pycache__/` ignoriert. Validator ohne `--strict-overlay`:
+
+| Lauf | Ergebnis | Was meldet |
+|---|---|---|
+| A – ohne Kennzeichen | **0 Fehler, 0 Warnungen** | – |
+| B – Kennzeichen kopiert, nicht verfolgt | 🔴 **1 Fehler** | Prüfung 79: `LICENSE: fehlt` in der Projektwurzel |
+| C – Kennzeichen committet | 🔴 **80 Fehler** | Prüfung 79 wie in B, dazu Prüfung 81 an **79** Projektträgern (Zeilenenden gegen die Mehrheit aller versionierten Träger) |
+
+🔴 **Keine der Meldungen nennt die Ursache.** Wer `LICENSE: fehlt` liest, legt eine
+Lizenz in die Projektwurzel – und hat danach ein Projekt, das dauerhaft als
+Framework-Repositorium geprüft wird. Die Prüfungen 75 und 78 melden in dieser
+Installation nichts, laufen aber ebenfalls im falschen Zweig.
+
+`install.py` meldet heute **nichts**: Die Datei kommt in keiner Zeile des Werkzeugs vor.
+
+### 2.3 🔴 Was die Kopie aus dem Arbeitsbaum beim Heben bewirkt
+
+Dieselbe Installation, in `OVERLAY.md` eine Projektmarke angehängt und committet; dann
+`cp -r <framework>/.koolie .` und `install.py --update`:
+
+| Messung | Ergebnis |
+|---|---|
+| Projektmarke in `OVERLAY.md` | 🔴 **weg** – `OVERLAY.md` und `overlay-manifest.yaml` sind die des Frameworks |
+| `install.py --update` | Exit 0; das Overlay steht in der Liste *„Projektdateien unberührt gelassen“* |
+| Kennzeichen | liegt unverfolgt im Projekt |
+
+➡️ ***Ein Werkzeug, das einen Pfad nie schreibt, kann nicht melden, was ein anderer
+Schritt dort geschrieben hat.*** Die Aussage *„`install.py` überschreibt
+`.koolie/project-overlay/` nie“* im Übernahmeleitfaden (Abschnitt 4) ist wahr – und
+genau deshalb beruhigt sie an der falschen Stelle: Überschrieben hat der Kopierbefehl
+davor. Das ist die *Zusage, die mehr verspricht als ihr Mechanismus hält*, an einem
+Satz, der für sich richtig ist.
+
+### 2.4 Warum ein Abbruch nicht baubar ist
+
+Das Framework-Repositorium erzeugt seine eigenen Wurzeldateien mit `install.py`
+(`.gitignore`: *„Im Framework-Repository sind die Wurzelbestandteile Erzeugnisse“*) und
+trägt das Kennzeichen. Gesucht nach einem Merkmal, das beide Fälle trennt:
+
+| Merkmal | trennt? |
+|---|---|
+| Kennzeichen vorhanden | nein – beide |
+| git verfolgt das Kennzeichen | 🔴 **nein** – ein Projekt, das die Kopie committet hat, sieht genauso aus; und gerade dort meldet Prüfung 81 am meisten |
+| Lage von `install.py` | nein – in beiden `<root>/.koolie/core/install.py` |
+
+---
+
+## 3. Vorlage zur Entscheidung
+
+| # | Frage | Wege und ihre Preise |
+|---|---|---|
+| **E1** | **Warnsatz an den Kopierbefehlen?** | **Ja, an allen drei Stellen des Übernahmeleitfadens und in der Wurzel-README:** Neuaufnahme (Abschnitt 2 Schritt 2), Aktualisierung (Abschnitt 3 Schritt 2 – dort steht kein Befehl, aber *„ersetzen“*), mehrere Repositories (Abschnitt 4, dort mit der Einschränkung des Satzes über `install.py`). Der Satz nennt **beide** Quellen und **beide** Folgen. Dazu der Absatz *„Sie wandert nicht in ein Projekt“* im Kennzeichen selbst. ⚠️ **Preis:** Ein Warnsatz erreicht nur, wer liest – deshalb E2 |
+| **E2** | **Auskunft oder Abbruch in `install.py`?** | **Auskunft** (Bauform von D-349): am Ende jedes Laufs mit Erstinstallation oder `--update`, solange das Kennzeichen im Ziel liegt; Exit-Code unverändert. Der Text nennt **beide** Fälle – Projekt (Datei entfernen, Overlay prüfen, weil eine Kopie aus dem Arbeitsbaum es ersetzt hat) und Framework-Repositorium (nichts zu tun). **Verworfen: Abbruch** – er träfe das Framework-Repositorium selbst, und kein Merkmal trennt die Fälle (2.4). **Verworfen: Auskunft nur bei unverfolgtem Kennzeichen** – sie schwiege in dem Projekt, das die Kopie schon committet hat. **Verworfen: das Kennzeichen per `export-ignore` aus dem Archiv nehmen** – es änderte den Archivinhalt gegen `git ls-tree` der Marke und hülfe beim Arbeitsbaum nicht. ⚠️ **Preis:** Im Framework-Repositorium steht die Auskunft bei jedem Lauf; ihr Text sagt, daß dort nichts zu tun ist |
+| **E3** | **Wirkungsnachweis** | **Bündel `sonden_kennzeichen_im_projekt`** an einer echten Installation: Sonde `D354` (Kennzeichen liegt → Hinweis, Exit 0, **und Prüfung 79 verlangt die Lizenz**) und Gegenprobe `D354a` (ohne Kennzeichen → kein Hinweis, keine Lizenzmeldung). 🔴 **Die Sonde hält zwei Stellen gegeneinander:** `install.py` und der Validator führen den Pfad des Kennzeichens je für sich; wandert eine der beiden Konstanten, fällt sie. **Gegen den Vorstand fällt `D354`** |
+
+**Nicht vorgelegt, benannt:** Die Meldungen der Prüfungen 79 und 81 nennen die Ursache
+weiterhin nicht. Sie könnten es – ein Zusatz *„geprüft als Quellrepositorium“* –, aber
+das ist ein Eingriff in vier Prüfungen für einen Fall, den jetzt zwei Stellen vorher
+abfangen. Ein bereits überschriebenes Overlay erkennt **keine** Stelle; dafür gibt es
+die Versionierung des Projekts.
+
+**Verworfen im Gespräch (Vorschlag des Owners, begründet abgelehnt):** das Kennzeichen
+in die Wurzel neben `README.md` legen, damit man ganz `.koolie/` kopieren kann. Es löst
+das Overlay-Problem nicht, und der Gewinn wäre eine Zeile – `mkdir -p` steht in beiden
+Anleitungen schon.
+
+> **Empfehlung der Vorbereitung:** E1 bis E3 wie vorgelegt. Keine neue Prüfung – die
+> Auskunft bleibt eine Auskunft (D-349), und der Validator behält seinen Gegenstand.
+
+---
+
+## 4. Umsetzung
+
+1. `README.md` und `docs/ADOPTION_GUIDE.md` (`0.4.5` → `0.4.6`): Warnsatz an den drei
+   Stellen; Abschnitt 4 schränkt den Satz über `install.py` ein.
+2. `.koolie/QUELLREPOSITORIUM.md`: Wer ganz `.koolie/` kopiert, nimmt es mit – auch aus
+   dem Archiv.
+3. `install.py`: Konstante `QUELLREPO_KENNZEICHEN`, Funktion
+   `traegt_quellrepo_kennzeichen()`, Auskunft hinter der aus D-349.
+4. `probe-pruefungen.py`: Bündel `sonden_kennzeichen_im_projekt` hinter dem Bündel zu
+   D-349.
+5. `DECISION_LOG.md`: **D-354**.
+6. `VERSION` `1.4.4`, Changelog, Roadmap, Dokumentkopf, Kapitel 26; beide übernehmenden
+   Projekte auf `1.4.4` gehoben und dort committet; Hauptdokument und Word-Fassung für
+   alle drei Packs gebaut.
+
+## 5. Abnahme
+
+Steht im Protokoll `tests/protocols/2026-09-24-kopierweg-kern.md`.
+
+## 6. Entscheidung
+
+**E1 bis E3 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-24; der Owner hat
+vorab erklärt, den Empfehlungen der Vorbereitung zu folgen). Decision Record **D-354**.
+Alle vier zählbaren Kriterien von D-11 bleiben **0**; kein Overlay-Feld berührt.

package/.koolie/core/governance/change-requests/CR-2026-138-overlay-muster-general.md

@@ -0,0 +1,118 @@
+# Änderungsantrag `CR-2026-138`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Das Overlay-Muster „General Development“ – und die Prüfung, die von fünf Pfadwerten einen sah |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-25 |
+| Betroffene Artefakte | `framework/overlay-patterns/general.md` (neu); `install.py` (`--overlay`, Füllschritt); `framework/runtime/permissions.json` (Schlitz `<READ_ONLY_PATHS>`); `tests/scripts/validate-framework.py` (**Prüfung 89**, Prüfung 59 formatgebunden); `tests/scripts/probe-pruefungen.py` (zwei Bündel); `clients/openai-codex/CLIENT_PACK.md` Abschnitt 5; `templates/project-overlay/OVERLAY.md` Abschnitt 4; `docs/ADOPTION_GUIDE.md`, `README.md`; `docs/ROADMAP.md`; `governance/DECISION_LOG.md` (**D-355** bis **D-358**, `K-69`); `governance/ADOPTION_REGISTRY.md`; `tests/TEST_CATALOG.md`; `build/doc/00-kopf.md`, `26-qs-test.md`; `VERSION`, `CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Auslieferbestand, Installationswerkzeug, Prüfapparat |
+| Art | **MINOR** nach `RELEASE_PROCESS.md` Abschnitt 1: neue Funktion (`--overlay`), neue Prüfung, neuer Schlitz der Kernquelle; kein bestehendes Overlay-Feld geändert |
+| Dringlichkeit | Posten `1.5.0` des Releaseplans (D-126, D-341, D-353) |
+| Status | 🟢 **entschieden am 2026-09-25** (E1 bis E9), umgesetzt mit `1.5.0` |
+
+---
+
+## 1. Anlaß
+
+Der Posten `1.5.0`: das optionale Projekt-Overlay *General Development*, gewählt über
+`--overlay general` (D-126), mit dem Umfang aus D-353 – Füllschritt bei der
+Erstinstallation, Wertabgleich aus `K-69`, die Frage nach `<READ_ONLY_PATHS>` in der
+Kernquelle. **Offen waren seit D-126** vier Voraussetzungen: welche Felder das Muster
+füllen darf, wer Owner ist, die Bauform und die Grenze zur Aktivierungsreife (D-57).
+
+## 2. Die Gegenprüfung
+
+### 2.1 Welche Werte ein Muster ohne Kenntnis des Projekts sicher angeben kann
+
+Die Kernquelle der Berechtigungen trägt drei Pfadschlitze, alle im `deny`-Korb:
+`<EXCLUDED_PATHS>` (Lesen und Schreiben), `<CI_CONFIG_PATHS>` und
+`<QUALITY_GATE_CONFIG_PATHS>` (Schreiben). **Jeder Wert dort verschärft.** Ein Wert, der
+auf ein Projekt nicht paßt, sperrt eine Datei, die es dort nicht gibt. Die übrigen
+Pfadplatzhalter – `<ALLOWED_PATHS>`, `<TEST_PATHS>`, `<DOC_PATHS>` – **geben frei**, und
+die Befehlsschlitze stehen im `ask`-Korb; ein Fehlgriff dort wäre eine Lockerung.
+➡️ *Die Grenze ist keine Auswahl nach Geschmack, sondern eine Richtung.*
+
+### 2.2 🔴 Prüfung 59 übersprang ihren dritten Gegenstand bei `openai-codex` still
+
+Gemessen am 2026-09-25 an einer Wegwerf-Installation von `openai-codex`:
+`<EXCLUDED_PATHS>` in `OVERLAY.md` und Laufzeitfassung auf `deploy/**` gesetzt, die
+Berechtigungsdatei unverändert. `--strict-overlay` meldete **nichts** zu diesem Wert.
+
+| Befund | Beleg |
+|---|---|
+| `.codex/config.toml` führt keinen Eintrag für `<EXCLUDED_PATHS>` und keinen für `deploy/**` | `grep` auf die Datei |
+| Gegenstand (c) von Prüfung 59 ruft `json.loads` auf und kehrt bei `JSONDecodeError` zurück – *„check_config hat das bereits gemeldet“*, was für TOML nicht stimmt | Quelltext |
+| Prüfung 59 steht **nicht** in `FORMATGEBUNDENE_PRUEFUNGEN`, und Prüfung 87 hält diese Liste gegen das Pack, **nicht gegen den Code** | Quelltext |
+
+➡️ **Die Bauform *„zwei Stellen, die einander decken“* (0.57.0):** Die Liste war
+vollständig in Bezug auf die Prüfungen, die sich auf sie berufen – und genau diese hier
+tat es nicht.
+
+### 2.3 Die vier übrigen Pfadplatzhalter in beiden Projekten
+
+| | Pilot (`claude-code`) | Übungsrepositorium (`devin-desktop`) |
+|---|---|---|
+| Quelle: alle vier in der dreispaltigen Zeile von Abschnitt 4 | ja | ja |
+| Laufzeitfassung **nennt** die Platzhalter | **ja, alle vier** | 🔴 **keinen der vier** – nur die Werte (*„Erlaubte Pfade: `backend/src/**`, …“*) |
+| Schreibweise für „kein Wert“ | `nicht vorhanden` (Quelle), `keine` (Laufzeitfassung) für `<DOC_PATHS>` | – |
+| Schreibsperre der Nur-Lese-Pfade im `deny`-Korb | von Hand, 2 Einträge | von Hand, 2 Einträge |
+
+➡️ **Die Ersetzung statt der Bindung (D-160) stand im Übungsrepositorium an vier Stellen**,
+seit dessen Laufzeitfassung besteht. Keine Prüfung konnte sie sehen, weil keine die vier
+Platzhalter las.
+
+### 2.4 Der Füllschritt an Wegwerf-Installationen aller drei Packs
+
+| Pack | Berechtigungsdatei | Laufzeitfassung | `OVERLAY.md` |
+|---|---|---|---|
+| `claude-code` | alle Werte als `Read(…)`/`Edit(…)`; kein Schlitz der drei mehr wörtlich | Wert hinter `(<EXCLUDED_PATHS>)` | drei Wertzeilen, Vermerk im Änderungsverlauf |
+| `devin-desktop` | dito mit `Read`/`Write` | dito | dito |
+| `openai-codex` | 🔴 **nur ein Teil kommt an:** Teilbäume (`.github/workflows/**` → `":workspace/.github/workflows" = "read"`) und einzelne Dateinamen; Namensmuster mit `*` nicht | dito | dito |
+
+⚠️ **Die erste Fassung der Musterdatei behauptete für `openai-codex`, die Globwerte
+erreichten die Datei gar nicht.** Die Messung hat sie berichtigt, bevor sie ausgeliefert
+wurde.
+
+## 3. Vorlage zur Entscheidung
+
+| # | Frage | Wege und ihre Preise |
+|---|---|---|
+| **E1** | **Welche Felder darf das Muster füllen?** | **Nur die drei Pfadplatzhalter im `deny`-Korb** (2.1). Die Grenze steht **im Werkzeug**: `install.py` nimmt keinen anderen Platzhalter an und bricht vor dem ersten Schreibvorgang ab. **Verworfen:** freigebende Pfade, Befehle, Rollen, Status. ⚠️ **Preis:** Das Muster füllt wenig – drei von rund vierzig Platzhaltern |
+| **E2** | **Bauform: Varianten oder Kopien?** | **Eine Wertedatei, die nur die Abweichung trägt.** `install.py` schreibt die eine Vorlage und füllt aus derselben Tabelle alle drei Träger. **Verworfen:** *n* vollständige Kopien – ein zweites Register. ⚠️ **Preis:** Der Füllschritt hängt an der Form der Wertzeilen und bricht ab, wenn ein Anker fehlt |
+| **E3** | **Wer ist Owner?** | **`<FRAMEWORK_OWNER>`**; das Muster ist ein Modulträger mit Steckbrief, Status `pilot` – `entwurf` höbe Kriterium 3 von D-11 auf 1. Es liegt unter `framework/overlay-patterns/`, **nicht** unter `templates/`, weil Prüfung 47 dort einen Ausfüllschlitz im Status verlangt |
+| **E4** | **Grenze zur Aktivierungsreife (D-57)?** | Ein Overlay aus dem Muster **besteht** `--check-overlay-ready` **nicht** – die organisatorischen Pflichtwerte bleiben offen. Eine Sonde hält es fest |
+| **E5** | **`<READ_ONLY_PATHS>` in der Kernquelle?** | **Ja, als Schlitz ohne Kernzusage.** Wirkt nur bei neuen Installationen; beide Projekte führen die Sperre schon von Hand (2.3). **Verworfen:** `core: true` – verlangte die Freigabe durch `<SECURITY_CONTACT>` für jedes Pack, das es nicht abbildet |
+| **E6** | **Wie wird `K-69` geprüft?** | **Prüfung 89**, dieselben drei Gegenstände wie 59, gleicher Schweregrad; ein Overlay, das anders bindet, bekommt eine eigene Meldung; „kein Wert“ in beiden gemessenen Schreibweisen ist die leere Menge. ⚠️ **Preis:** Das Übungsrepositorium muß beim Heben seine Laufzeitfassung umschreiben (2.3) |
+| **E7** | **Füllschritt je Client Pack?** | Laufzeitfassung und `OVERLAY.md` bei allen drei; die Berechtigungsdatei, soweit das Pack den Wert abbildet – bei `openai-codex` mit der benannten Lücke (2.4) |
+| **E8** | **Einstufung?** | **MINOR, ohne Kontingent** – gemessen an Wegwerf-Installationen, nicht mit Sitzungsläufen |
+| **E9** | **Prüfung 59 (c) formatgebunden** (2.2, im Bau gefunden) | **In `FORMATGEBUNDENE_PRUEFUNGEN` aufnehmen**, wie (c) von Prüfung 89, und in Abschnitt 5 des Packs nennen. **Verworfen:** (c) für TOML nachbauen – die Pfadrechteschicht kennt keine Musterform (D-346). ⚠️ **Preis:** Die Lücke bleibt, sie ist nur erklärt |
+
+> **Empfehlung der Vorbereitung:** E1 bis E9 wie vorgelegt.
+
+---
+
+## 4. Umsetzung
+
+1. `framework/overlay-patterns/general.md` neu; `install.py` mit `--overlay`, Füllschritt,
+   Vorlauf und vier Abbruchfällen.
+2. `permissions.json`: Schlitz `write <READ_ONLY_PATHS>`.
+3. Validator: Prüfung 89, `FORMATGEBUNDENE_PRUEFUNGEN` um 59 und 89; Register im
+   Kopfkommentar.
+4. Sondenbündel `sonden_overlay_pfadabgleich` und `sonden_overlay_muster`.
+5. Overlay-Vorlage Abschnitt 4, Leitfaden, README, Codex-Pack Abschnitt 5, Roadmap (mit
+   eigenem Planabschnitt für `1.6.0`), Decision Log, Bestandsliste, Katalog, Kopf,
+   Kapitel 26, `VERSION`, Changelog.
+6. Beide Projekte heben; im Übungsrepositorium die vier Zeilen der Laufzeitfassung auf
+   die Bindung umstellen.
+
+## 5. Abnahme
+
+Steht im Protokoll `tests/protocols/2026-09-25-overlay-muster-general.md`.
+
+## 6. Entscheidung
+
+**E1 bis E9 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-25; E1 bis E8 vor dem
+Bau vorgelegt und mit *„wie empfohlen“* beantwortet, E9 im Bau gefunden – der Owner hat
+vorab erklärt, den Empfehlungen der Vorbereitung zu folgen). Decision Records **D-355**
+bis **D-358**; `K-69` beantwortet. Alle vier zählbaren Kriterien von D-11 bleiben **0**.

package/.koolie/core/governance/change-requests/CR-2026-139-overlay-muster-dokumente.md

@@ -0,0 +1,105 @@
+# Änderungsantrag `CR-2026-139`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Best Practices im Overlay-Muster „General“ – und das Register, das auf nichts zeigen durfte |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-25 |
+| Betroffene Artefakte | `framework/overlay-patterns/general.md` (`0.2.0`); `framework/overlay-patterns/general/documents/` (sechs Dokumente, neu); `install.py` (Dokumente, Manifest, Abbruchfälle); `tests/scripts/validate-framework.py` (Prüfung 8); `tests/scripts/probe-pruefungen.py` (Sonden `8a`, `8b`, `M359` bis `M359c`); `tests/TEST_CATALOG.md`; `docs/ADOPTION_GUIDE.md`, `README.md`; `docs/ROADMAP.md`; `governance/DECISION_LOG.md` (**D-359** bis **D-361**); `governance/ADOPTION_REGISTRY.md`; `build/doc/00-kopf.md`, `26-qs-test.md`; `VERSION`, `CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Auslieferbestand, Installationswerkzeug, Prüfapparat |
+| Art | **MINOR** nach `RELEASE_PROCESS.md` Abschnitt 1: neuer Auslieferbestand und erweiterte Prüfung; kein bestehendes Overlay-Feld geändert |
+| Dringlichkeit | Auftrag des Owners vom 2026-09-25, **vor** dem Installer |
+| Status | 🟢 **entschieden am 2026-09-25** (E1 bis E10), umgesetzt mit `1.6.0` |
+
+---
+
+## 1. Anlaß
+
+Der `<FRAMEWORK_OWNER>` hat am 2026-09-25 beauftragt, daß das Muster `general`
+**allgemeingültige Best Practices der Softwareentwicklung** für die Bereiche des Overlays
+mitliefert – Coding Guidelines, Definition of Ready, Definition of Done und so weiter –,
+**nur, was auf jedes Softwareprojekt paßt**. `1.5.0` hat das nicht getan: Das Muster füllt
+drei sperrende Pfadplatzhalter und sonst nichts (D-355).
+
+## 2. Die Gegenprüfung
+
+### 2.1 Was der Kern schon regelt
+
+Der Kern führt für KI-unterstützte Arbeit bereits eine normative Definition of Done
+(`04-quality.md` Abschnitt 3), Anforderungen an Änderungen (Q1 bis Q8), Review-Prüfpunkte
+(`07-review-rules.md`, RV1 bis RV12) und die Checklisten 03 (vor der Änderung), 05 (Tests),
+06 (Sicherheit), 07 (neue Abhängigkeiten) und 08 (Merge Request). **Ein Musterdokument,
+das davon etwas wiederholt, wäre ein zweites Register.**
+
+🔴 **Ein Widerspruch, gefunden bevor geschrieben wurde:** Die *Pfadfinderregel* in ihrer
+üblichen Form – *„Code sauberer hinterlassen, als man ihn vorfand“* – widerspricht **Q1**
+(ein Ziel je Änderung) und **RV1** (Scope-Treue). Sie gehört zu den verbreitetsten Clean-
+Code-Regeln und paßt trotzdem nicht in dieses Framework, jedenfalls nicht ungekürzt.
+
+### 2.2 Was die Dokumentablage der Vorlage anbietet
+
+`templates/project-overlay/documents/` führt dreizehn Typen; das Manifest kennt dieselben
+und `other`. Sieben davon beschreiben das Projekt (`architecture`, `roadmap`, `deployment`,
+`roles`, `glossary`) oder werden vom Kern getragen (`ai-governance`, `ai-process-model`).
+**Sechs bleiben, die ein allgemeines Dokument tragen können.**
+
+### 2.3 🔴 Prüfung 8 prüft nicht, ob ein registriertes Dokument existiert
+
+`check_manifest` prüft Kopfschlüssel, Pflichtfelder und Aufzählungswerte – **nicht, ob
+unter `path` etwas liegt**. Ein Manifest, dessen Einträge auf nichts zeigen, besteht.
+Gezählt am 2026-09-25: Beide übernehmenden Projekte führen nur existierende Pfade (Pilot
+14, Übungsrepositorium 7 Einträge). **Prüfung 8 hatte keine einzige Sonde.**
+
+### 2.4 Der Status eines Dokuments und Kriterium 3
+
+Ein Steckbrief mit Status `entwurf` in einem Kernträger hebt Kriterium 3 von D-11
+(Prüfung 46, 47). Die Dokumente tragen deshalb **keinen** Steckbrief; der Status
+`entwurf` steht im **Manifest des Projekts**, wo er den Lebenszyklus des Projektdokuments
+beschreibt. Modulträger bleibt das Muster.
+
+## 3. Vorlage zur Entscheidung
+
+| # | Frage | Wege und ihre Preise |
+|---|---|---|
+| **E1** | **Ort** | **Registrierte Dokumente unter `documents/<typ>/`**, im Muster mitgeliefert, im Manifest eingetragen. **Verworfen:** Text in `OVERLAY.md` Abschnitt 9 bis 12 – bei jedem Projekt mit eigenen Dokumenten ein zweites Register |
+| **E2** | **Grenze zum Kern** | **Nur ergänzen und verweisen, nichts wiederholen** (2.1); jedes Dokument sagt in einem eigenen Abschnitt, wo die Grenze liegt; bei Widerspruch gilt der Kern. Die Pfadfinderregel nur eingeschränkt |
+| **E3** | **Inhaltliche Grenze** | **Nur allgemein anerkannte, werkzeug- und sprachneutrale Praktiken**; keine Schwellenwerte, keine Werkzeugnamen, keine Vorgaben, die Vorgehensmodell, Teamgröße oder Plattform voraussetzen. D-355 wird fortgeschrieben, nicht aufgehoben. ⚠️ **Preis:** Keine Maschine prüft, ob ein Satz auf jedes Projekt paßt |
+| **E4** | **Status** | Kontextklasse K1, im Manifest `entwurf`, **Vorschlagsvermerk im Kopf jedes Dokuments**; kein eigener Steckbrief (2.4). Das Overlay bleibt nicht aktivierungsreif |
+| **E5** | **Laden** | **`on-demand`**; die K1-Liste der Laufzeitfassung bleibt offen. ⚠️ **Preis:** Bis der Overlay Owner freigibt, wirken die Dokumente nicht auf den Client. **Verworfen:** `summary`/`rule` – sofort wirksam mit ungeprüftem Inhalt, dazu weitere Träger je Pack |
+| **E6** | **Beispiele der Manifestvorlage** | **Ersetzen**, nicht ergänzen – drei Einträge mit Ausfüllschlitz neben sechs echten wären ein Register mit Einträgen, die auf nichts zeigen |
+| **E7** | **Auswahl der Typen** | **Sechs:** `coding-guidelines`, `definition-of-ready`, `definition-of-done`, `quality`, `security`, `branching-strategy` (2.2) |
+| **E8** | **Weitere Platzhalter, Bestandsprojekte** | **Keine weiteren Platzhalter** (`<PROJECT_RULES_PATH>`, DoR/DoD-Pfade bleiben offen). **Kein Modus für Bestandsprojekte** (D-126); der Leitfaden beschreibt die Übernahme von Hand |
+| **E9** | **Release** | **MINOR `1.6.0`**, ohne Kontingent; der Installer rückt auf **`1.7.0`** – er bietet `--overlay` an und soll das vollständige Muster ausliefern. ⚠️ **Preis:** die dritte Verschiebung des Installers (D-339, D-341) |
+| **E10** | **Prüfbarkeit** (im Zuge der Vorbereitung gefunden, 2.3) | **Sonden `M359` bis `M359c`** an echten Erstinstallationen, und **Prüfung 8 prüft die Existenz von `path` und – bei `load: rule` – `rule_file`**, außer der Pfad trägt einen Ausfüllschlitz. **Verworfen:** eine eigene Prüfung für die Musterablage – `install.py` hält Ablage und Beschreibung ohnehin gegeneinander und bricht ab |
+
+> **Empfehlung der Vorbereitung:** E1 bis E10 wie vorgelegt.
+
+---
+
+## 4. Umsetzung
+
+1. Sechs Dokumente unter `framework/overlay-patterns/general/documents/<typ>/muster-general.md`.
+2. `general.md` auf `0.2.0`: Abschnitt *„Die Dokumente“* mit Grenze, Tabelle der Typen und
+   dem, was bewußt fehlt.
+3. `install.py`: `muster_dokumente()`, `muster_manifest()`, Schreiben der Dokumente bei der
+   Erstinstallation, Vermerk im Änderungsverlauf, Hinweis am Ende des Laufs, Abbruch bei
+   vorhandenen Dokumenten.
+4. Validator: Prüfung 8 um die Existenz erweitert; Sondenmenge um Prüfung 8.
+5. Sonden `8a`, `8b`, Gegenprobe `8a`; im Bündel `sonden_overlay_muster` die Sonden `M359`
+   bis `M359b` und die Gegenprobe `M359c`.
+6. Leitfaden (Abschnitt 2 und 3), README, Roadmap, Decision Log, Bestandsliste, Katalog,
+   Kopf, Kapitel 26, `VERSION`, Changelog.
+7. Beide Projekte heben; das Muster erreicht sie nicht.
+
+## 5. Abnahme
+
+Steht im Protokoll `tests/protocols/2026-09-25-overlay-muster-dokumente.md`.
+
+## 6. Entscheidung
+
+**E1 bis E10 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-25; E1 bis E9 vor dem
+Bau vorgelegt und mit *„Machen wir es“* angenommen. Von E10 war die Sonde vorgelegt und der
+Befund an Prüfung 8 benannt; die Erweiterung der Prüfung selbst ist im Bau entschieden worden –
+der Owner hat vorab erklärt, den Empfehlungen der Vorbereitung zu folgen).
+Decision Records **D-359** bis **D-361**. Alle vier zählbaren Kriterien von D-11 bleiben
+**0**.

package/.koolie/core/governance/change-requests/CR-2026-140-installer-je-zielsystem.md

@@ -0,0 +1,120 @@
+# Änderungsantrag `CR-2026-140`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Installer je Zielsystem – und die Prüfung, die ohne PyYAML Fehler erfand |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-25 |
+| Betroffene Artefakte | `install.cmd`, `install.command` (neu, Wurzel); `install_dialog.py` (neu); `install.py` (`--target`, `PYTHON_MINDEST`); `tests/scripts/validate-framework.py` (Prüfung 33, `TEXT_EXT`); `tests/scripts/probe-pruefungen.py` (Bündel `sonden_kopierweg`, `sonden_ohne_pyyaml`, Sonden `6s`); `docs/ADOPTION_GUIDE.md`, `README.md`; `governance/RELEASE_PROCESS.md` (Schritt 2); `docs/ROADMAP.md`; `governance/DECISION_LOG.md` (**D-362** bis **D-366**); `governance/ADOPTION_REGISTRY.md`; `build/doc/00-kopf.md`, `15-referenzstruktur.md`, `26-qs-test.md`; `VERSION`, `CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Installationswerkzeug, Auslieferbestand, Prüfapparat |
+| Art | **MINOR** nach `RELEASE_PROCESS.md` Abschnitt 1: neuer Übernahmeweg neben dem bisherigen, erweiterte Prüfung; kein Overlay-Feld geändert |
+| Dringlichkeit | Vorgabe des Owners vom 2026-09-25; Ziel-Release `1.7.0` nach D-361 |
+| Status | 🟢 **entschieden am 2026-09-25** (E1 bis E11), umgesetzt mit `1.7.0` |
+
+---
+
+## 1. Anlaß
+
+Ein Zielprojekt bekam das Framework bis `1.6.0` über einen Handgriff: den Kern aus Archiv
+oder Klon ins Projekt kopieren, dann `install.py` dort aufrufen (`CR-2026-098`, `K-75`).
+Der `<FRAMEWORK_OWNER>` hat am 2026-09-25 vorgegeben: **ein Installer je Zielsystem, im
+Fokus Windows und macOS**; wer Linux oder ein anderes Unix nutzt, bleibt beim bisherigen
+Weg. Der Posten war dreimal gerückt (D-339, D-341, D-361).
+
+## 2. Die Gegenprüfung
+
+### 2.1 Woran der Handweg zweimal gebrochen ist
+
+Wer ganz `.koolie/` kopiert, nimmt das Kennzeichen des Quellrepositoriums und aus einem
+Klon dessen Overlay mit (D-354); wer mit `git archive HEAD` hebt, liefert den Stand von
+vorhin (D-333). **Beides sind Fehler des Handgriffs, nicht des Werkzeugs** – ein Werkzeug,
+das nur den Kern kopiert, kann sie nicht machen.
+
+### 2.2 Was der Zielrechner mitbringen muß
+
+`install.py`, der Validator und die Hooks sind Python. Die Hooks laufen in jeder Sitzung;
+**ein Installer ohne Python-Voraussetzung verschöbe die Frage in die erste Sitzung.**
+Gemessen am 2026-09-25 mit Python 3.8.20 neben 3.14: Installationen aller drei Packs
+byteweise gleich, der Validator mit PyYAML zeilengleich, alle 41 Python-Träger
+kompilieren. 3.7 war auf dem Meßplatz nicht beschaffbar.
+
+### 2.3 Die Startbedingungen der beiden Systeme
+
+| System | Befund | Folge |
+|---|---|---|
+| Windows | `Get-ExecutionPolicy -List`: `LocalMachine AllSigned`, `CurrentUser RemoteSigned` – ein heruntergeladenes `.ps1` startet per Doppelklick nicht | Starter als `.cmd` |
+| Windows | `WindowsApps\python.exe` liegt im Suchpfad und startet ohne installiertes Python kein Python | Versionsprobe statt Namensprobe; `clientmap.python_interpreter()` kennt die Falle schon |
+| Windows | Das Archiv liefert mit ausdrücklicher Zeilenendeform LF (D-328); `cmd.exe` findet Sprungmarken in LF-Dateien nicht zuverlässig | Starter ohne Sprungmarke, Sonde `T365` |
+| macOS | Ein `.command` öffnet sich per Doppelklick im Terminal, **wenn** es ausführbar ist; kein Träger des Repositoriums trug `100755` | Modus gesetzt, Sonde `T365` |
+| macOS | `/usr/bin/python3` ist ohne Command Line Tools ein Platzhalter | Versionsprobe |
+
+### 2.4 🔴 Prüfung 33 erfand ohne PyYAML Fehler
+
+Beim Messen der Mindestversion: Ohne PyYAML meldete der Validator an **jeder**
+`claude-code`-Installation neun Skills mit leerem `disallowed-tools` – Prüfung 33 las aus
+dem Rohtext des Frontmatters mit `.get()` nichts. Die Warnung dazu sagte, die Prüfungen
+4, 5 und 8 liefen *„eingeschränkt“*; Prüfung 33 nannte sie nicht, und sie lief nicht
+eingeschränkt, sondern falsch. **Das trifft den Installer:** Der Starter installiert kein
+PyYAML nach.
+
+### 2.5 🔴 Die Starter lagen außerhalb des Prüfapparats
+
+`TEXT_EXT` führte weder `.cmd` noch `.command`. Nach der Aufnahme meldete die
+Inhaltsprüfung in beiden Startern sofort eine URL außerhalb der Allowlist.
+
+### 2.6 Der Lieferumfang
+
+Die Roadmap nannte einen **wählbaren Lieferumfang** (*„alles oder nur das zur Nutzung
+Nötige“*). Gemessen: Hooks und Validator liegen unter `tests/scripts/`. Der naheliegende
+Schnitt *„ohne `tests/`“* bräche jede Installation.
+
+## 3. Vorlage zur Entscheidung
+
+Vorgelegt am 2026-09-25 als Fragen (a) bis (j), angenommen mit *„a – i passt“*.
+
+| # | Frage | Wege und ihre Preise |
+|---|---|---|
+| **E1** | **Python voraussetzen?** (a) | **Ja, dünne Starter je System**, eine Installationslogik. **Verworfen:** eigenständige Programme – Bau je System, Signatur und Notarisierung, und die Hooks brauchten trotzdem Python |
+| **E2** | **Mindestversion** (b) | **Messen, nicht setzen:** 3.8 (2.2). ⚠️ **Preis:** unter Windows gemessen, auf macOS übertragen |
+| **E3** | **Starter unter Windows** (c) | **`install.cmd`** (2.3); unter macOS **`install.command`** |
+| **E4** | **Ort der Kopierlogik** (d) | **`install.py --target`**; die Starter suchen nur Python |
+| **E5** | **Bedienung** (e) | **Die Starter fragen**, `install.py` bleibt parametergesteuert. Die Fragen stehen in `install_dialog.py`, nicht in den Starterdateien – zwei Shell-Dialekte wären zwei Dialoge |
+| **E6** | **Heben** (f) | **Derselbe Starter hebt**, wenn im Projekt ein Kern liegt (`--target --update`); `RELEASE_PROCESS.md` Schritt 2 nennt den Befehl |
+| **E7** | **Prüfbarkeit der Starter** (aus der Umsetzung, 2.3 und 2.5) | **`TEXT_EXT` um `.cmd`, `.command`**; Sonde `T365` für Sprungmarke und Modus, `T363` für die Mindestversion an drei Stellen |
+| **E8** | **Nachinstallieren** (h) | **Nein** – weder Python noch PyYAML; der Starter nennt den Weg und hält an |
+| **E9** | **Ablage** (i) | **Wurzel des Archivs** |
+| **E10** | **Prüfung 33 ohne PyYAML** (aus der Messung, 2.4) | **Zeilenweiser Rückfall** für das einzeilige Feld. **Verworfen:** aussetzen – das schaltete die Prüfung gegen B01 genau auf den Zielrechnern ab |
+| **E11** | **Lieferumfang** (g) | **Nicht in `1.7.0`**, eigener Posten `1.8.0` (2.6) |
+| (j) | **Abnahme auf macOS** | ⚠️ **Offen.** Geprüft unter Git Bash und Linux (`dash`); die Abnahme auf macOS liegt beim Owner |
+
+> **Empfehlung der Vorbereitung:** E1 bis E11 wie vorgelegt.
+
+---
+
+## 4. Umsetzung
+
+1. `install.py`: `--target <projekt>` (nur mit `--update`, `--client`, `--overlay`,
+   `--dry-run`), `quelle_kerndateien()` (Klon: `git ls-files`, nur wenn die Klonwurzel die
+   Quellwurzel ist; sonst Verzeichnis ohne `__pycache__` und `build/out`), Kopie über
+   `core.koolie-neu`, Tausch über `core.koolie-alt`, Aufruf des kopierten `install.py`,
+   Rückbau bei dessen Scheitern; `PYTHON_MINDEST` und Prüfung beim Start.
+2. `install_dialog.py`: Projektverzeichnis (hineingezogener Pfad), bei vorhandenem Kern
+   Heben, sonst Client und Muster; Befehl zeigen, bestätigen, ausführen; `q` bricht ab.
+3. `install.cmd`, `install.command` in der Wurzel; `install.command` mit `100755`.
+4. Validator: `_flaches_feld()` für Prüfung 33; `TEXT_EXT` um `.cmd`, `.command`.
+5. Sonden: Bündel `sonden_kopierweg` (`T362` bis `T362h`, `T363`, `T365`), Bündel
+   `sonden_ohne_pyyaml` (`S364`, `S364a`), Sonden `6s` an beiden Startern.
+6. Leitfaden, README, Schritt 2 des Release-Prozesses, Roadmap, Decision Log,
+   Bestandsliste, Kopf, Kapitel 15 und 26, `VERSION`, Changelog.
+7. Beide Projekte heben – **zum ersten Mal mit `--target --update`**.
+
+## 5. Abnahme
+
+Steht im Protokoll `tests/protocols/2026-09-25-installer-je-zielsystem.md`.
+
+## 6. Entscheidung
+
+**E1 bis E11 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-25; (a) bis (i) vor
+dem Bau vorgelegt und angenommen, E7 und E10 aus der Umsetzung – der Owner hat vorab
+erklärt, den Empfehlungen der Vorbereitung zu folgen). (j) bleibt offen. Decision Records
+**D-362** bis **D-366**. Alle vier zählbaren Kriterien von D-11 bleiben **0**.

package/.koolie/core/governance/change-requests/CR-2026-141-lieferumfang.md

@@ -0,0 +1,123 @@
+# Änderungsantrag `CR-2026-141`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der wählbare Lieferumfang – und die Liste, die sich nicht ableiten ließ |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-25 |
+| Betroffene Artefakte | `clientmap.py` (`NACHWEIS_ABLAGEN`, `lieferumfang()`); `install.py` (`--lieferumfang`, `LIEFERUMFANG`, Pfadgrenze); `install_dialog.py`; `tests/scripts/validate-framework.py` (**Prüfung 90**, `HINWEIS`, Prüfungen 12, 76, 77, 80); `tests/scripts/probe-pruefungen.py` (Bündel `sonden_lieferumfang`, Sonden `90`, `90a`, `T362`); `tests/TEST_CATALOG.md`; `docs/ADOPTION_GUIDE.md`, `README.md`; `governance/RELEASE_PROCESS.md` (Schritte 5 und 6); `docs/ROADMAP.md`; `governance/DECISION_LOG.md` (**D-367** bis **D-370**, `K-75`, `K-122`); `governance/ADOPTION_REGISTRY.md`; `build/doc/00-kopf.md`, `15-referenzstruktur.md`, `26-qs-test.md`, `31-anhaenge.md`; `VERSION`, `CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Installationswerkzeug, Auslieferbestand, Prüfapparat |
+| Art | **MINOR** nach `RELEASE_PROCESS.md` Abschnitt 1: neue Wahl beim Übernehmen, neue Prüfung, neue Ausgabeform; der Standard bleibt der bisherige Umfang, kein Overlay-Feld geändert |
+| Dringlichkeit | Posten `1.8.0` nach D-366 |
+| Status | 🟢 **entschieden am 2026-09-25** (E1 bis E10), umgesetzt mit `1.8.0` |
+
+---
+
+## 1. Anlaß
+
+`K-75` fragt seit `0.72.0`, was ins **Mindestpaket** gehört und womit ein Projekt mit
+reduziertem Umfang seine Übernahme prüft. `1.7.0` hat den Lieferumfang aus dem Posten des
+Installers gelöst (D-366): Hooks und Validator liegen unter `tests/scripts/`, der Schnitt
+*„ohne `tests/`“* bräche jede Installation, und **die Liste gehört abgeleitet, nicht
+aufgezählt** – sonst fehlt nach dem ersten neuen Träger einer.
+
+## 2. Die Gegenprüfung
+
+Gemessen am 2026-09-25 an sechs frischen Installationen (drei Packs, je ohne und mit
+Muster `general`), außerhalb des Repositoriums.
+
+### 2.1 🔴 Die Lesespur taugt nicht
+
+Jede Datei, die Installer und Validator im Projekt öffnen, protokolliert über einen
+Audit-Hook: **549 von 549** Kerndateien. Der Validator prüft Inhalte über den ganzen Baum.
+*Was gelesen wird, ist nicht, was nötig ist.*
+
+### 2.2 🔴 Die Verweishülle taugt nicht
+
+Transitiv über die Verweisauswertung von Prüfung 12 (Markdown-Links und Framework-Pfade in
+Backticks), ausgehend von den installierten Trägern: mit Verzeichnisverweisen **548 von
+548**. Ohne Verzeichnisverweise bleiben **39 Protokolle, 5 Anträge und 6 Träger aus
+`build/`** in der Hülle – und es fallen **die Skillquellen, die Laufzeitschicht und
+`templates/project-overlay/`** heraus, ohne die `install.py --update` nicht läuft. Zu groß
+und zu klein zugleich.
+
+### 2.3 🟢 Der Validator ist das Orakel
+
+Aus einer Kopie der Installation die vier Ablagen der Nachweisschicht entfernt –
+`governance/change-requests`, `tests/protocols`, `tests/erhebungen`, `build`, zusammen
+**350 von 550 Dateien, rund 47 % der Bytes** – und die Validatorausgabe gegen die volle
+Installation gehalten. **In allen drei Packs gleich:**
+
+| Neu gegenüber voll | Anzahl | Woher |
+|---|---|---|
+| *„Pfadangabe existiert nicht“*, Ziel `tests/protocols/` | **70** (33 verschiedene Ziele) | `TEST_CATALOG` 22, Skillquellen 17, installierte Skills 14, `framework/core` 5, `EDGE_CASES` 4, übrige 8 |
+| Prüfung ohne Gegenstand | **3** | 76 (`tests/erhebungen/ablage.py`), 77 (`build/doc/00-kopf.md`), 80 (`tests/protocols/`) |
+| sonst | **0** | – |
+
+Die 70 Verweise sind **Herkunftsangaben**: Die Aussage des verweisenden Trägers steht ohne
+die Datei. Sonst hängt kein Werkzeug an der Nachweisschicht.
+
+### 2.4 Nebenbefund: die Windows-Pfadgrenze
+
+Die erste Messung legte die Projekte im Ablagebereich der Sitzung an. `--target` brach beim
+Kopieren ab: `…\core.koolie-neu\framework\role-packs\requirements-engineering\runtime\30-role-requirements-engineering.md`
+riß die Grenze von 259 Zeichen. Der Rückbau hielt, **die Meldung fragte, ob eine Datei
+geöffnet sei.** Längster Kernpfad 102 Zeichen; ab 146 Zeichen Projektpfad scheitert es.
+
+### 2.5 Nebenbefund: der Dateimodus des Archivs
+
+Beim Nachzählen von `koolie-1.7.0.tar.gz`: `install.command` mit `0775`, jede Datei `0664` –
+gits Voreinstellung `tar.umask=0002`. Mit `-c tar.umask=022`: `0755` und `0644`, zweimal
+bytegleich. Das Archiv ist vor der Veröffentlichung so neu erzeugt worden.
+
+## 3. Vorlage zur Entscheidung
+
+Vorgelegt am 2026-09-25 als Fragen (a) bis (j), angenommen mit *„Passt“*.
+
+| # | Frage | Wege und ihre Preise |
+|---|---|---|
+| **E1** | **Wie wird die Liste abgeleitet?** (a) | **Umgekehrt: aufgezählt ist die Nachweisschicht, geschlossen nach Ablageort, an einer Stelle** (`clientmap.NACHWEIS_ABLAGEN`); `nutzung` ist der Kern ohne sie. Ob die Nutzung auskommt, entscheidet der Validator (2.3), gehalten von einer Sonde. **Verworfen:** Lesespur (2.1), Verweishülle (2.2), Kennzeichnung je Datei – dieselbe Aufzählung, verteilt über 550 Träger |
+| **E2** | **Die 70 Verweise** (b) | **Herkunftsangaben:** In einer reduzierten Installation meldet Prüfung 12 sie nicht, sondern zählt sie in einer `HINWEIS`-Zeile; im Quellrepositorium bleibt sie streng. **Verworfen:** auf Kennungen umschreiben – 70 Eingriffe in Belege; zitierte Protokolle mitliefern – wieder eine Liste |
+| **E3** | **Die Prüfungen 76, 77 und 80** (c) | **Prüfen nur das Gelieferte, mit je einer `HINWEIS`-Zeile.** Still übersprungen wäre die Bauform, die `1.4.0` abgestellt hat (D-346). Dazu die **Ausgabeform `HINWEIS`**, die weder Fehler noch Warnung ist; eine volle Installation trägt keine |
+| **E4** | **Wo steht die Wahl?** (d) | **`.koolie/core/LIEFERUMFANG`** neben `VERSION`, geschrieben bei jedem `--target`; ohne Datei gilt `voll`. Das Heben übernimmt sie, gewechselt wird nur ausdrücklich; eine reduzierte Quelle liefert keinen vollen Kern. **Prüfung 90** hält die Angabe gegen den Bestand. **Verworfen:** die Wahl am Zustand erkennen – täuschbar |
+| **E5** | **Standard und Bedienung** (e), (f) | **`voll` bleibt Standard**; `--lieferumfang voll` oder `nutzung`, **nur mit `--target`**; der Dialog fragt bei der Erstinstallation, beim Heben nennt er den bisherigen Umfang |
+| **E6** | **Große Einzelträger** (g) | **Nicht in `1.8.0`** – `CHANGELOG.md`, `DECISION_LOG.md`, `ROADMAP.md`, Sondenskript, zusammen rund 26 % der Bytes, wären eine Aufzählung einzelner Dateien. Offen als **`K-122`** |
+| **E7** | **Archive** (h) | **Eines, voll.** Reduziert wird beim Installieren |
+| **E8** | **Pfadgrenze** (i) | **Vorprüfung in `install.py`** gegen das längere Zwischenverzeichnis, mit Pfad, Länge und Überschuß; Sonde `T368` |
+| **E9** | **Dateimodus des Archivs** (j) | **`-c tar.umask=022` in Schritt 5**, der Modus als Gegenstand von Schritt 6 |
+| **E10** | **Qualitätssicherungsrelease** (Frage des Owners während des Baus) | **`1.9.0`, direkt nach `1.8.0`:** Nach `1.8.0` ist kein grundsätzlicher Posten geplant; `K-67` hat kein Ziel-Release. Beginnt mit einem Vorbedingungsdurchgang, der Dokumentliste und Kriterien festlegt |
+
+> **Empfehlung der Vorbereitung:** E1 bis E10 wie vorgelegt.
+
+---
+
+## 4. Umsetzung
+
+1. `clientmap.py`: `LIEFERUMFANG_DATEI`, `LIEFERUMFAENGE`, `NACHWEIS_ABLAGEN`,
+   `ist_nachweis()`, `lieferumfang()`.
+2. `install.py`: `--lieferumfang` (nur mit `--target`), Umfang aus Angabe, bisheriger Datei
+   oder `voll`; Filter der Nachweisschicht; `LIEFERUMFANG` ins Zwischenverzeichnis;
+   Verweigerung bei reduzierter Quelle; Zeile *„Umfang:“* samt Wechsel; Vorprüfung der
+   Pfadgrenze (`PFAD_GRENZE_DATEI`, `PFAD_GRENZE_VERZEICHNIS`).
+3. `install_dialog.py`: Frage nach dem Umfang bei der Erstinstallation.
+4. Validator: `HINWEISE`/`hinweis()`, `reduziert()`, `nicht_geliefert()`; Prüfung 12
+   (Herkunftsangaben), 76, 77, 80 (nur Geliefertes); **Prüfung 90**; `LIEFERUMFANG` als
+   Verweisziel im Quellrepositorium; Register und Sondenmenge bis 90.
+5. Sonden: Bündel `sonden_lieferumfang` (`L367` bis `L367e`, `90b`, `90c`, `T368`), Sonden
+   `90`, `90a`; `T362` erwartet `LIEFERUMFANG`, `T362g` die neue Frage.
+6. Leitfaden, README, Release-Prozess (Schritte 5 und 6, dazu die Schrittnummern einer
+   Begründung berichtigt), Roadmap (Standüberschrift, `1.8.0`, Planabschnitt `1.9.0`),
+   Decision Log, Bestandsliste, Kapitel 00, 15, 26, 31, `VERSION`, Changelog.
+7. Beide Projekte heben – mit `--target --update`, **voll** wie bisher.
+
+## 5. Abnahme
+
+Steht im Protokoll `tests/protocols/2026-09-25-lieferumfang.md`.
+
+## 6. Entscheidung
+
+**E1 bis E10 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-25; (a) bis (j) vor
+dem Bau vorgelegt und angenommen, E10 als Frage des Owners während des Baus – der Owner
+hat vorab erklärt, den Empfehlungen der Vorbereitung zu folgen). Decision Records
+**D-367** bis **D-370**; `K-75` beantwortet, `K-122` neu. Alle vier zählbaren Kriterien
+von D-11 bleiben **0**.