@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-069-bytecode-des-kerns.md

@@ -0,0 +1,108 @@
+# Änderungsantrag `CR-2026-069`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Beide Projekte versionieren den Bytecode des Kerns – der Übernahmeleitfaden nennt nur die Zeilen, die man weglassen soll |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-15 |
+| Betroffene Artefakte | `docs/ADOPTION_GUIDE.md` (Abschnitt 2), `tests/scripts/validate-framework.py` (Prüfung 45 neu, Register), `tests/scripts/probe-pruefungen.py` (vier Sonden, zwei Gegenproben, `aufraeumen()`, Selbstprobe `A3`), `tests/TEST_CATALOG.md` (`FW-KO-01`), `governance/DECISION_LOG.md`, `docs/ROADMAP.md`, `CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Übernahmeleitfaden und Prüfapparat sind Framework-Gut |
+| Art | Änderung |
+| Dringlichkeit | **Regulär.** Der Schaden ist Hygiene, nicht Sicherheit – aber er trifft **zwei von zwei** Projekten, und das macht ihn zu einer Eigenschaft des Leitfadens, nicht der Projekte |
+
+## 1. Anlass
+
+**Gefunden beim Heben des Piloten** (Kandidat 4 der Übergabe, 0.41.0 → 0.46.0), nicht
+gesucht. Beim Ersetzen von `leitwerk-core/` standen zwei `.pyc`-Dateien als „modified" im
+Arbeitsbaum – versionierter Bytecode eines Werkzeugs, das bei jedem Lauf neuen erzeugt.
+
+### Abgezählt am 2026-09-15
+
+| Projekt | Framework-Stand | Versionierte Bytecode-Dateien unter `leitwerk-core/` | `.gitignore` deckt `__pycache__` |
+|---|---|---|---|
+| `devpacks/otp-generator` (Pilot) | 0.41.0 | **6** | nein |
+| `devpacks/test-devin-framework` (Übungsrepo) | 0.45.0 | **2** | nein |
+| `devpacks/leitwerk` (Framework selbst) | 0.46.0 | 0 | **ja** |
+
+**Zwei von zwei.** Das Framework-Repositorium selbst hat die Zeile seit jeher – und genau
+deshalb ist der Fehler dort nie aufgefallen.
+
+### Warum das kein Versehen der Projekte ist
+
+`docs/ADOPTION_GUIDE.md` Abschnitt 2 sagte zur `.gitignore` genau einen Satz: *„Übernimm
+die `.gitignore` des Framework-Repositorys **nicht** unverändert"* – und nennt dann die
+vier Zeilen, die ein Projekt **weglassen** muss. Welche Zeile es **braucht**, stand
+nirgends.
+
+> **Das ist die Bauform des Befunds von 0.45.0, ein zweites Mal:** *Eine Anweisung, die
+> die halbe Migration beschreibt, ist gefährlicher als keine.* Wer dem Leitfaden wörtlich
+> folgt, schreibt eine eigene `.gitignore` – und hat danach keine Zeile gegen den
+> Bytecode, weil ihm niemand gesagt hat, dass er eine braucht.
+
+### Was der Schaden ist, und was er nicht ist
+
+**Kein Sicherheitsproblem.** Bytecode des Frameworks enthält keine Projektgeheimnisse.
+Der Schaden ist:
+
+- **Dauerrauschen im Arbeitsbaum.** Zwei der sechs Dateien standen beim Auschecken des
+  Piloten als geändert da, ohne dass jemand etwas getan hätte.
+- **Ein Erzeugnis, das seine Quelle überlebt.** Nach dem Heben des Piloten zeigte `git
+  status` vier `.pyc` als **gelöscht** – sie gehörten zu einem Kern, den es nicht mehr
+  gibt, und wären als Löschung committet worden.
+- **Ein falscher Eindruck von Vollständigkeit.** Wer `leitwerk-core/` ersetzt, ersetzt
+  nicht den Bytecode; die Versionierung führt dann beides nebeneinander.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Der Leitfaden nennt die Zeile.** Abschnitt 2 bekommt den Gegensatz zu den vier
+   Weglass-Zeilen: `__pycache__/` gehört hinein, mit Begründung und mit dem Weg für
+   bereits versionierte Dateien (`git rm -r --cached`).
+2. **Prüfung 45** mit **zwei Gegenständen**: die Regel in der `.gitignore` und der
+   Bestand über `git ls-files`.
+3. **Vier Sonden und zwei Gegenproben** nach D-23.
+4. **`aufraeumen()` löst den Schreibschutz** – siehe Abschnitt 3, das ist beim Bauen
+   angefallen.
+
+## 3. Was beim Bauen angefallen ist – der Aufräumer aus 0.46.0 hatte seinen ersten Fall
+
+Die Sonde zu Gegenstand 2 legt ein echtes Repositorium an (`git init`). **Git schreibt
+seine Objektdateien schreibgeschützt.** Der Aufräumer von 0.46.0 versuchte dreimal über
+anderthalb Sekunden zu löschen und meldete dreimal dasselbe:
+
+```
+AUFRAEUMER -    FEHL  sonden_bytecode: C:\…\lw-inst-p8auo49r bleibt liegen
+        [WinError 5] Zugriff verweigert: …\.git\objects\03\7c6087d4df…
+        3 Versuche ueber 1,5 s, danach aufgegeben.
+```
+
+**Der Aufräumer hatte recht und war trotzdem nutzlos.** Er meldete einen Zustand, den er
+selbst hätte auflösen können: *Warten hilft gegen eine gehaltene Datei und gar nichts
+gegen eine schreibgeschützte.* Die Roadmap führte das als offenen Punkt („unerhoben, ob
+drei Versuche für den echten Fall reichen") – **der Fall ist da, und die Antwort ist
+nein.**
+
+Jeder Versuch ab dem zweiten nimmt jetzt zuerst den Schreibschutz weg. **Die Selbstprobe
+`A3` misst es**, denn eine Behebung ohne Sonde ist nach D-23 keine.
+
+## 4. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | **Prüft 45 die Regel, den Bestand, oder beides?** | **Beides.** Gegenstand 1 vergleicht die `.gitignore` gegen eine Liste wirksamer Schreibweisen; Gegenstand 2 zählt über `git ls-files`, was unter `<CORE_DIR>/` verfolgt ist | **Die Regel allein wäre die halbe Migration ein zweites Mal:** Git liest die `.gitignore` für bereits verfolgte Dateien **nicht**. Wer die Zeile nachträgt und `git rm --cached` vergisst, bekäme einen grünen Lauf und hätte die sechs Dateien weiter im Repositorium. Der Bestand allein wiederum sagt nicht, wie man die Wiederholung verhindert. Preis von „beides": eine bedingte Prüfhälfte, und ihre Sonde braucht ein echtes Repositorium – `kopie()` lässt `.git` weg, das geht nur im Bündel |
+| **E2** | **Was tut Gegenstand 2, wo git fehlt?** | **Er sagt als Warnung, dass er nicht gelaufen ist.** Dieselbe Bauform, die dieses Skript für das fehlende PyYAML schon hat | **Jede Sonde dieses Skripts erzeugt die Warnung** – sie läuft auf einer Kopie ohne `.git`. Das ist gewollt und harmlos (Gegenproben verlangen 0 **Fehler**, nicht 0 Warnungen), aber die Ausgabe wird um eine Zeile länger. Verworfen: schweigen – eine Prüfhälfte, die stumm ausfällt, ist der Befundtyp selbst |
+| **E3** | **Was gilt bei fehlender `.gitignore`?** | **Warnung.** Ob ein Projekt überhaupt versioniert, kann kein Validator wissen | **Wer die Datei löscht, macht Gegenstand 1 zur Warnung statt zum Fehler.** Gegenstand 2 fängt den echten Fall trotzdem, sobald git da ist. Verworfen: Fehler (ein Projekt ohne Versionierung bekäme einen Fehler, den es nicht abstellen kann) und Schweigen (der verlorene Anker, den 28, 29, 31 und 40 ausdrücklich selbst melden) |
+| **E4** | **Welche Schreibweisen gelten als Deckung?** | **Eine kleine ausdrückliche Liste:** `__pycache__/`, `__pycache__`, `**/__pycache__/`, `*.pyc`, `**/*.pyc` | **Was die Liste nicht kennt, meldet sie** – ein Projekt mit einer exotischen, aber wirksamen Schreibweise bekommt einen falschen Fehler. Die Gegenprobe belegt, dass `*.pyc` allein durchläuft. Verworfen: nur `__pycache__/` (dann wäre ein richtiges Projekt rot – der Fehler, den Prüfung 37 einmal gemacht hat) und `git check-ignore` (dann bräuchte **auch** Gegenstand 1 git, und man könnte ihn gleich weglassen) |
+| **E5** | **Schreibt `install.py --update` die Zeile selbst?** | **Nein.** Der Leitfaden nennt sie, die Prüfung verlangt sie, das Projekt trägt sie ein | **Bequem wäre es.** Aber die `.gitignore` ist eine Projektdatei, und das Framework hat dort noch nie hineingeschrieben – D-46 ist gerade darum gebaut. Die Zusage „Projektdateien bleiben unberührt" trüge ab dann eine Ausnahme, und das Werkzeug müsste den Aufbau einer fremden Datei kennen |
+| **E6** | **Wie wird der Schreibschutz behandelt?** | **Jeder Versuch ab dem zweiten löst ihn im ganzen Baum**, leise, danach der nächste Löschversuch. Ohne `onerror`/`onexc` von `shutil.rmtree` | Die beiden Namen haben sich zwischen den Python-Fassungen abgelöst; **ein Nachweiswerkzeug, das an der Fassung seines Interpreters hängt, ist genau das, was D-49 abgeschafft hat.** Preis: ein zusätzlicher Baumdurchlauf je Fehlversuch – er fällt nur an, wenn ohnehin etwas klemmt |
+
+## 5. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen.** E1 bis E4 wie vorgelegt am 2026-09-15 durch den Framework Owner entschieden; E5 ebenfalls; **E6 ist beim Bauen angefallen** und folgt aus D-23 – eine Behebung ohne Sonde ist keine |
+| Datum | 2026-09-15 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Eintrag | D-97 (der Bytecode des Kerns gehört nicht in die Versionierung, und die Prüfung fragt nach Regel **und** Bestand) |
+| Auflagen | **Der Gegenbeweis gehört dazu und ist eigen:** Die vier Sonden MÜSSEN gegen 0.46.0 fallen, **und die beiden Gegenproben MÜSSEN dort bestehen** – ein zulässiger Zustand läuft auch ohne die neue Prüfung durch. Dazu die Abzählung an beiden Projekten, nicht nur am Piloten |
+| Ziel-Release | `0.47.0` |
+| Umsetzung | umgesetzt mit `0.47.0` |

package/.koolie/core/governance/change-requests/CR-2026-070-d11-zaehler.md

@@ -0,0 +1,114 @@
+# Änderungsantrag `CR-2026-070`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Alle vier Zählregeln des 1.0.0-Standes greifen daneben – vier von vier Zahlen sind falsch, jede auf eine andere Art |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-15 |
+| Betroffene Artefakte | `tests/scripts/validate-framework.py` (Prüfung 46 neu, Register), `tests/scripts/probe-pruefungen.py` (sechs Sonden, drei Gegenproben), `docs/ROADMAP.md` (Standzeile, Zählregeln), `tests/TEST_CATALOG.md` (`FW-KO-01`), `governance/DECISION_LOG.md`, `README.md` (Nebenbefund), `CHANGELOG.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Prüfapparat und Fortschrittsmaßstab sind Framework-Gut |
+| Art | Änderung |
+| Dringlichkeit | **Regulär.** Kein Sicherheitsbezug. Aber der Gegenstand ist der Maßstab, an dem dieses Repositorium seinen einzigen offenen Meilenstein misst – und er misst falsch |
+
+## 1. Anlass
+
+**Gesucht war Kandidat 2 der Übergabe:** eine Prüfung, die den 1.0.0-Stand nachzählt,
+statt ihn in einem gepflegten Absatz zu führen. Die Roadmap hält die Ermessensfrage dazu
+seit 0.44.0 offen und verlangt ausdrücklich, sie **vor** dem Bauen zu entscheiden.
+
+**Beim Nachzählen der vier Kriterien, zur Vorbereitung eben dieser Entscheidung, fiel der
+Befund an.** Er war nicht gesucht, und er ist größer als die Aufgabe: **Nicht die Zahlen
+sind veraltet – die Regeln, die sie ausrechnen, sind falsch.** Vier von vier, jede auf
+eine andere Art.
+
+### Abgezählt am 2026-09-15
+
+| # | Kriterium (D-11) | Was die Roadmap als Zählregel nennt | Geglaubt | **Gezählt** | Warum die Regel danebengreift |
+|---|---|---|---|---|---|
+| **1** | kein unbearbeiteter `VERIFY`-Marker | `grep -rl "VERIFY AGAINST CURRENT CLIENT DOCUMENTATION"` | 27 in 26 Dateien | **29** | Sie kennt **eine von zwei** registrierten Schreibweisen. `docs/PLACEHOLDER_REGISTRY.md:80` führt `<VERIFY AGAINST CURRENT DEVIN DOCUMENTATION>` als zulässige Altform **mit derselben Frist „vor Version 1.0.0"** – und die trägt allein im Client Pack `devin-desktop` **sieben** Fundstellen, dazu **zwei** in dessen `root-template/.devin/README.md`, also in einer Datei, die **jede** Devin-Installation bekommt. Der Befehl meldet dort **null** |
+| **2** | Testkatalog ohne `offen` | „Ergebnisspalte in `tests/TEST_CATALOG.md`, dazu die dezentralen `TESTS.md` je Skill" | 103 (31 + 72) | **118** (31 + 87) | „je Skill" wurde als **zwölf** Dateien gelesen. Es sind **dreizehn**: `framework/role-packs/requirements-engineering/skills/role-re-ticket/TESTS.md` mit **15** offenen Zellen wurde nie mitgezählt. Ein Role-Pack-Skill ist ein Skill |
+| **3** | alle Modulstatus über `entwurf` | „Steckbriefzeile in `framework/core/`, `framework/skills/*/SKILL.md`, `framework/role-packs/`, `framework/tech-packs/`" | 16 | **69** | Die Ablagenliste deckt **ein Viertel** des Bestands. `checklists/` (11), `prompts/` (12), `governance/` (7), `decision-trees/` (6), `onboarding/` (4), `docs/` (3), `clients/` (4), `pilot/` (2), `tests/` (2), `templates/` (1) führen dieselbe Steckbriefzeile und stehen **sämtlich** auf `entwurf`. **Und `framework/core/` ist genannt und trägt überhaupt keine Statuszeile** – ein Zählort ohne Gegenstand. Dazu: `role-packs/software-development/ROLE_PACK.md` trägt `entwurf (Referenzpack der Erstfassung)`; ein Gleichheitsvergleich sieht sie nicht |
+| **4** | keine Decision Records `entschieden (Vorschlag)` | „`governance/DECISION_LOG.md`" | 16 | **9** | Die 16 ist die Trefferzahl eines rohen `grep`. Sie zählt mit: die **Legende** in Zeile 4, die das Wort erklärt; **fünf Klärungspunkte** (`K-08`, `K-12`, `K-13`, `K-17`, `K-18`), die keine Decision Records sind; und **`D-11` selbst**, weil dort der Kriterientext steht. Übrig bleiben **neun** echte: `D-01` bis `D-08` und `D-10` |
+
+**Zwei Zahlen zu klein, eine viermal zu klein, eine fast doppelt zu groß.** Keine davon
+ist je falsch geschrieben worden – das ist der Punkt. Jede ist das richtige Ergebnis
+einer Regel, die weniger kann, als ihr Kriterium verlangt.
+
+### Warum das der Befundtyp dieses Projekts ist, eine Ebene höher
+
+0.42.0 fand fünf handgepflegte Zahlen über den **Prüfapparat**, nach zwölf Releases
+sämtlich falsch. Die Roadmap zog daraus die richtige Lehre und schrieb sie auf:
+
+> **Hier stehen keine Zahlen, sondern die Befehle, die sie ausrechnen.**
+
+**Die Lehre war richtig und die Umsetzung hat sie nicht eingelöst.** Ein Befehl, den
+niemand ausführt, ist keine Ausrechnung – er ist eine Zahl mit einem Zwischenschritt.
+Und weil ihn niemand ausführt, fällt auch nicht auf, dass er das Falsche zählt.
+
+**Der Unterschied zu 0.42.0 ist einer im Ort, nicht in der Bauform:** Dort stand die
+falsche Zahl über den Prüfstand, hier über den **Meilenstein**. Es gibt in diesem
+Repositorium genau ein Ziel, und sein Stand war an vier von vier Stellen unrichtig.
+
+### Ein Fallstrick, der beim Bauen zuschnappte – und derselbe Befund ist
+
+Die erste Fassung des Zählers benutzte `glob.glob(..., recursive=True)`.
+**Python's `glob` überspringt Pfadbestandteile, die mit einem Punkt beginnen.** Damit
+fehlten fünfzehn Dateien des Kerns, darunter genau die zwei Träger, die den Befund zu
+Kriterium 1 tragen: `clients/*/root-template/.devin/README.md` und
+`.../.claude/README.md`. **Der Zähler hätte 27 gemeldet statt 29** – und wäre damit
+zufällig auf die geglaubte Zahl gekommen.
+
+**Eine Zählregel, die einen Träger still überspringt, war der Anlass dieses Antrags.**
+Sie ist beim Bauen der Abhilfe ein zweites Mal entstanden. Der Zähler läuft deshalb über
+`os.walk`, und eine Selbstprobe belegt es (Abschnitt 3, E7).
+
+### Nebenbefund: die Wurzel-README nennt die Altform
+
+`README.md:165` beschreibt die Konventionen dieses Frameworks und nennt dabei
+`<VERIFY AGAINST CURRENT DEVIN DOCUMENTATION>` – die **clientgebundene** Altform, an
+einer werkzeugneutralen Stelle. Seit `CR-2026-024` ist die neutrale Form die im Kern zu
+verwendende (D-02). Prüfung 14 greift dort nicht: Sie misst die Ablagen des Kerns, und
+die Wurzel-README ist keine. **Korrigiert, nicht geprüft** – eine Prüfung für eine Datei,
+die jedes Projekt durch seine eigene ersetzt, wäre ohne Gegenstand.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Prüfung 46** – der D-11-Zähler. Sie rechnet die vier maschinell zählbaren Kriterien
+   aus und hält sie gegen **eine** Standzeile in `docs/ROADMAP.md`. Abweichung in
+   **beide** Richtungen ist ein Fehler; die Meldung nennt die gezählte Zahl, damit die
+   Behebung ein Kopiervorgang ist.
+2. **Die Standzeile** in `docs/ROADMAP.md`, wörtlich vorgeschrieben, genau einmal. Fehlt
+   sie, meldet die Prüfung den **verlorenen Anker** selbst – die Bauform der Prüfungen
+   28, 29, 31 und 40.
+3. **Die vier Zählregeln der Roadmaptabelle werden durch die des Zählers ersetzt** und
+   dort so beschrieben, wie er zählt. Eine Tabelle, die einen anderen Befehl nennt als
+   den ausgeführten, ist das zweite Register neben dem ersten.
+4. **Sechs Sonden und drei Gegenproben** nach D-23, dazu eine Selbstprobe auf den
+   `glob`-Fallstrick.
+5. **`README.md:165`** trägt die neutrale Markerform (Nebenbefund).
+
+## 3. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | **Welche Bauform hat der Zähler?** Die Roadmap stellt die Frage seit 0.44.0 und verlangt sie vor dem Bauen entschieden | **Die Bauform von Prüfung 40 und 31: Der Stand steht ausgerechnet an genau einer Stelle, und die Prüfung hält die geschriebene Zahl gegen die gezählte.** Nicht der offene Punkt ist der Fehler, sondern die falsche Zahl | **Jeder Fortschritt macht den Lauf rot, bis die Zahl nachgezogen ist** – auch der Fortschritt in die richtige Richtung. **Das ist gewollt:** Genau dieses Nachziehen ist der Vorgang, der heute unterbleibt, und er kostet eine Zeile. Verworfen: **(a) ein Fehler je offenem Punkt** – 225 Fehler im Lauf, jeder Lauf rot, die Prüfung binnen eines Releases abgeschaltet; **(b) nur berichten** – dann ist es keine Prüfung, sondern derselbe gepflegte Absatz mit mehr Zeilen, und der Befund dieses Antrags wäre damit nicht gefunden worden |
+| **E2** | **Welcher Zählbereich?** Der Validator läuft auch in jedem übernehmenden Projekt | **Nur `<CORE_DIR>/`**, ohne `build/` (Erzeugnis), `CHANGELOG.md`, `governance/change-requests/` und `tests/protocols/` (datierte, abgeschlossene Aufzeichnungen) | **Der Kern ist in jeder Installation derselbe** – `install.py --check` ist genau dafür da –, also ist die Zahl installationsunabhängig und die Prüfung läuft überall gleich. Preis: **Fundstellen außerhalb des Kerns zählen nicht**, auch echte. `README.md:165` ist so eine, und sie ist deshalb per Hand korrigiert statt geprüft. Verworfen: **das ganze Repositorium** – dann meldete jede Installation eine andere Zahl und die Standzeile wäre in keinem Projekt richtig; **die vier Ausnahmen mitzählen** – dann stiege die Zahl mit jedem Protokoll, das den Marker erwähnt, und sie könnte nie sinken, weil ein datierter Bericht nicht bearbeitbar ist |
+| **E3** | **Zählt bei Kriterium 1 auch die Fundstelle, die den Marker nur *nennt*?** Registerzeile, Glossarzeile, Arbeitsanweisung | **Ja. Keine Ausnahmeliste.** Die Zahl ist ein **Pegel**, kein Arbeitsvorrat | **Kriterium 1 kann damit nicht auf null gehen, solange der Marker sein eigenes Register und seine Glossarzeile hat – und das ist richtig so:** `PLACEHOLDER_REGISTRY.md` schreibt beiden Formen in der Spalte „Ersetzung/Frist" ausdrücklich **„vor Version 1.0.0"** vor. Ein Platzhalter, dessen letzte Aussage verifiziert ist, gehört aus dem Register; sonst führt das Repositorium einen Platzhalter ohne Gegenstand. **Der Zähler verlangt am Ende genau das.** Verworfen: eine benannte Ausnahmeliste – sie träfe **ein Drittel** der Fundstellen, wäre reines Ermessen und müsste selbst gegen Verrotten bewacht werden; eine gepflegte Liste über eine gepflegte Zahl ist keine Verbesserung |
+| **E4** | **Beide Markerschreibweisen?** | **Ja – `CLIENT` und `DEVIN`.** Ein Muster, kein zweiter Befehl | Die Altform ist **registriert und zulässig** (nur im Client Pack `devin-desktop`, Prüfung 14 setzt das durch) – aber sie trägt dieselbe Frist. **Wer nur die neutrale Form zählt, hält ein Client Pack mit sieben offenen Verifikationsbedarfen für fertig.** Preis: keiner, der Regex kostet ein `(?:…|…)` |
+| **E5** | **Welche Träger bei Kriterium 2?** | **Jede `TESTS.md` unter `<CORE_DIR>/`, gefunden durch Baumdurchlauf** – keine Liste, kein Ablagenpräfix | **Eine Glob-Suche kann keine dreizehnte Datei übersehen; eine Liste kann es, und sie hat es.** Preis: Wer eine `TESTS.md` an einem unerwarteten Ort anlegt, sieht seine Zahl steigen – das ist die Meldung, nicht der Fehler |
+| **E6** | **Welche Träger bei Kriterium 3 – die vier genannten Ablagen oder der ganze Bestand?** | **Der ganze Bestand: jede Steckbriefzeile `\| Status \| … \|` in den ersten sechzig Zeilen einer `.md` des Kerns.** Verglichen wird das **erste Wort** des Werts, damit `entwurf (Referenzpack der Erstfassung)` mitzählt | **Die Zahl springt von 16 auf 69, und Kriterium 3 sieht mit einem Schlag viermal so groß aus.** Das ist keine Verschlechterung, sondern die Lage: D-11 sagt „**alle** Modulstatus", nicht „die der vier Ablagen", und **keiner der 69 steht über `entwurf`** – das Lebenszyklusmodell aus `08-skill-conventions.md` Abschnitt 7 ist in diesem Repositorium **noch nie angewendet worden**. Verworfen: bei den vier Ablagen bleiben – dann bliebe ein Kriterium klein, indem es drei Viertel seines Gegenstands nicht ansieht |
+| **E7** | **Wie wird der `glob`-Fallstrick verhindert, der beim Bauen zuschnappte?** | **`os.walk` statt `glob`, und eine Selbstprobe `C1`, die beide Verfahren auf demselben Baum gegeneinander abzählt** | Ohne sie wäre die Abhilfe eine Behauptung – **und die Wiederholung war schon einmal billiger als die Vorsicht.** Preis: eine Einheit mehr im Sondenlauf, unter einer Sekunde. Verworfen: ein Kommentar über dem `os.walk` – ein Kommentar hat keinen Mechanismus, und das ist der Befundtyp dieses Repositoriums |
+| **E8** | **Meldet die Prüfung „1.0.0-reif", wenn alle vier Zahlen null sind?** | **Nein, sie braucht dafür keinen eigenen Gegenstand.** Steht in der Roadmap `Kriterium 1 = 0, Kriterium 2 = 0, Kriterium 3 = 0, Kriterium 4 = 0` und der Lauf ist grün, **dann ist das die Meldung** – erzwungen, nicht behauptet | Preis: Es steht kein Satz da, der „reif" sagt. Dafür gibt es auch keinen fünften Gegenstand, der heute nichts fängt und morgen gepflegt werden muss. **Kriterium 5 zählt der Zähler nicht** – „Übernahme in ein zweites Projekt nachgewiesen" ist keine Zahl. Das ist eine **Enthaltung**, und sie steht im Kopfkommentar |
+| **E9** | **Was geschieht mit den Zählbefehlen in der Roadmaptabelle?** | **Sie werden durch die Regeln des Zählers ersetzt**, in derselben Tabelle, mit dem Hinweis, dass Prüfung 46 sie ausführt | **Ein zweites Register neben dem ersten wird mit jedem Release falscher** – dieser Befundtyp ist in diesem Repositorium sechsmal gefunden worden, und der vorliegende Antrag ist der siebte Fall. Preis: Die Roadmap trägt ab jetzt wieder Zahlen, was ihr eigener Absatz von 0.42.0 ausschließt. **Der Absatz schließt *gepflegte* Zahlen aus; eine Zahl, die eine Prüfung hält, ist das Gegenteil** – er gehört umgeschrieben, nicht umgangen |
+
+## 4. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen.** E1 bis E9 wie vorgelegt am 2026-09-15 durch den Framework Owner entschieden. **E7 ist beim Bauen angefallen** und folgt aus D-23 – eine Behebung ohne Sonde ist keine |
+| Datum | 2026-09-15 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Decision-Log-Eintrag | D-98 (der 1.0.0-Stand wird ausgerechnet und gegen eine einzige Standzeile gehalten), D-99 (der Zählbereich ist der Kern, und Kriterium 3 misst den ganzen Bestand) |
+| Auflagen | **Der Gegenbeweis gehört dazu:** Die sechs Sonden MÜSSEN gegen 0.47.0 fallen, die drei Gegenproben dort bestehen. **Dazu die Abzählung selbst:** Jede der vier alten Zählregeln ist mit ihrer Fundstelle und ihrem Grund im Protokoll auszuweisen – eine Behauptung „vier von vier falsch" ohne die vier Nachweise wäre genau die Bauform, die dieser Antrag beanstandet |
+| Ziel-Release | `0.48.0` |
+| Umsetzung | umgesetzt mit `0.48.0` |

package/.koolie/core/governance/change-requests/CR-2026-071-strukturentscheidungen-bestaetigen.md

@@ -0,0 +1,322 @@
+# Änderungsantrag `CR-2026-071`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die neun Strukturentscheidungen sind bestätigt – und die drei Einwände, die sie zweiunddreißig Releases lang aufgehalten haben, zielten an der Entscheidung vorbei |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-15 |
+| Betroffene Artefakte | `governance/DECISION_LOG.md` (D-01 bis D-08, D-10, K-08, Legende, D-100, D-101), `docs/ROADMAP.md` (Standzeile, Kriterientabelle, Abschnitt „Strukturentscheidungen bestätigen", AP3), `tests/scripts/probe-pruefungen.py` (Sonde 46f), `CHANGELOG.md`, `tests/protocols/2026-09-15-gegenpruefung-strukturentscheidungen.md`, `tests/protocols/2026-09-15-wirkungsnachweise-0.49.0.md` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Gegenstand sind die Strukturentscheidungen des Frameworks selbst |
+| Art | Änderung (Statuswechsel), Fortschreibung |
+| Dringlichkeit | **Regulär.** Kein Sicherheitsbezug. Der Gegenstand ist Arbeitspaket `AP3` der Roadmap mit Priorität P1 und Kriterium 4 von D-11 |
+
+## 1. Anlass
+
+**Beauftragt, nicht gefunden.** Das ist der erste Unterschied zu den fünf Releases davor:
+Dieser Antrag geht nicht auf einen Befund zurück, sondern auf eine Anweisung. Sie folgt
+aus der Messung, die `CR-2026-070` beigebracht hat.
+
+Prüfung 46 zählt seit 0.48.0 die vier maschinell zählbaren Kriterien von D-11 bei jedem
+Lauf. Ihre erste Anwendung war eine rückwirkende Messung über dreiundzwanzig
+Releasestände, und ihr Ergebnis ist die Begründung dieses Antrags:
+
+| Release | K1 | K2 | K3 | K4 | Summe |
+|---|---|---|---|---|---|
+| 0.26.0 | 30 | 117 | 67 | 9 | **223** |
+| 0.33.0 | 31 | 118 | 69 | 9 | **227** |
+| 0.35.0 … 0.48.0 | 29 | 118 | 69 | 9 | **225** |
+
+**Kriterium 4 steht seit 0.26.0 auf neun. Es stand auch davor auf neun.** Die neun
+Records tragen ihr Datum vom **2026-09-01**, dem Tag der Erstfassung 0.1.0 – seither sind
+**neunundvierzig Releases** vergangen, und keiner hat einen davon gehoben.
+
+**Der Vorgang war vorbereitet.** `CR-2026-019` hat am 2026-09-10 die Vorbedingung
+geschaffen: Acht der zehn Records beschrieben einen Stand, den es nicht mehr gab; alle
+acht sind fortgeschrieben worden. Derselbe Antrag hat die Entscheidung selbst
+ausdrücklich **nicht** getroffen, sondern je Record vorgelegt (Abschnitt 4) – und
+festgehalten, dass sieben ohne erkennbaren Einwand dastehen und drei mit einem benannten.
+
+**Diese Vorlage ist seit zweiunddreißig Releases unbeantwortet.** Sie steht bis heute als
+offener Haken in Abschnitt 7 von `CR-2026-019`:
+
+> - [ ] **Zur Entscheidung offen:** der Statuswechsel je Record (Abschnitt 4). Drei
+>   tragen einen benannten Einwand: D-05 (AP2-CC-12 offen), D-07 (K-20 bei
+>   `devin-desktop` unbelegt), D-10 (K-04 offen)
+
+**Der eigentliche Befund dieses Antrags steht in Abschnitt 3, und er war nicht gesucht:**
+Alle drei Einwände zielen an der Entscheidung vorbei, gegen die sie vorgebracht sind.
+Zwei von ihnen knüpfen die Bestätigung an Bedingungen, die **D-11 selbst ausdrücklich
+ausnimmt**. Der dritte verwechselt eine Regel mit ihrer Durchsetzungstiefe bei einem
+Client – der Unterscheidung, für die es **D-12** gibt.
+
+> **Es ist nicht so, dass niemand entschieden hätte. Es ist so, dass die Bedingung falsch
+> gewählt war – und eine falsch gewählte Bedingung wartet für immer.**
+
+## 2. Die Gegenprüfung: neun Records, je Record ein Urteil
+
+Nach D-23 gehört jeder Befund gegengeprüft, bevor er umgesetzt wird. Hier ist der
+Gegenstand kein Befund, sondern eine Bestätigung – die Gegenprüfung fragt deshalb nicht
+„stimmt der Befund?", sondern: **Trägt die Begründung von 2026-09-01 heute noch, und
+womit ist das belegt?**
+
+Vollständig mit Fundstellen und Messungen in
+`tests/protocols/2026-09-15-gegenpruefung-strukturentscheidungen.md`. Kurzfassung:
+
+| ID | Gegenstand | Begründung von 2026-09-01 | Trägt sie heute? | Beleg – gemessen, nicht gelesen |
+|---|---|---|---|---|
+| **D-01** | Ebenenmodell | „Vorgabe des Auftrags; Ebenen B und E sind für Separation of Concerns erforderlich" | **Ja** | `governance/PRIORITY_HIERARCHY.md` führt acht Stufen; Ebene B ist Stufe 2 und hat unter `framework/org-policies/` einen Einbindungspunkt mit zwei Dateien, Ebene E ist Stufe 8. Die Alternative „drei Ebenen ohne Packs" ist durch **zwei** Role Packs praktisch widerlegt. **Ehrlich dazu:** Von den beiden Packebenen ist eine besetzt; ein Technology Pack liegt bisher nur als Vorlage vor – das ist eine Aktivität von `AP4` und keine Frage an das Ebenenmodell |
+| **D-02** | Lang- und Laufzeitform | „Tool Independence und Least Context" | **Ja, und stärker als damals** | D-12 bis D-14 haben die Naht benannt und maschinenlesbar gemacht: Beide Client Packs führen ein `manifest.json`, aus dem `install.py` und der Validator die Pfade lesen. 2026-09-01 war das eine Absicht, heute ist es eine Datei |
+| **D-03** | Vier-Dateien-Struktur je Skill | „Trennung normativ/erläuternd; Least Context" | **Ja** | **13 von 13** Skills tragen genau `SKILL.md`, `EXAMPLES.md`, `TESTS.md`, `CHANGELOG.md` – abgezählt, nicht behauptet. Least Context ist seit dem 2026-09-12 gemessen (`ERH-13`) und am 2026-09-14 ein zweites Mal: Von zwölf Framework-Skills erscheinen **drei** in der Skill-Auflistung einer echten Sitzung, die übrigen neun hält `disable-model-invocation` aus dem Kontext (Zusage S4) |
+| **D-04** | Berechtigungsdatei, restriktiver Standard | „Secure by Default" | **Ja, und seit D-18 geprüft statt zugesagt** | `framework/runtime/permissions.json` führt **53** `deny`-, **5** `ask`- und **19** `allow`-Regeln; die Kernzusagen werden als `_core_rules_integrity.deny_must_contain` aus derselben Quelle erzeugt (`clientmap.py`) und vom Validator gegen sie gehalten |
+| **D-05** | Berechtigungsmodi | „Human Accountability, Review before Adoption" | **Ja** – Einwand siehe Abschnitt 3.1 | Das Verbot steht in beiden Client Packs; bei `claude-code` zusätzlich technisch sperrbar (AP2-CC-05). Das Framework liefert **genau ein** Agentenprofil aus (`framework/runtime/agents/fw-reviewer.md`), und es setzt das Feld nicht, um das der Einwand geht |
+| **D-06** | Prioritätshierarchie, Verschärfungsprinzip | „Auflösung des Zielkonflikts Core über Overlay gegen Overlay definiert die Projektwerte" | **Ja** | Das Verschärfungsprinzip ist Regel 2.1 von `PRIORITY_HIERARCHY.md` und seit D-18 an der tragenden Stelle eine **geprüfte Eigenschaft**: Die Semantikabbildung lässt die Installation scheitern, wenn eine `deny`- oder `ask`-Regel kein Zielwerkzeug hat, und untersagt bei `allow` jede Verbreiterung |
+| **D-07** | Kontextklassen K0 bis K3 | „Operationalisierbarkeit statt abstrakter Regeln" | **Ja** – Einwand siehe Abschnitt 3.2 | Die vier Klassen stehen in `framework/core/02-privacy.md` Abschnitt 2, vollständig auch in der Laufzeitschicht (D-24). Die Alternative „Freitextregeln" hätte weder die Auffangkategorie in 2.1 noch die Vorrangregel in 2.2 tragen können |
+| **D-08** | Metadaten im Dateikörper | „Toleranz unbekannter Frontmatter-Schlüssel nicht belegt" | **Die Entscheidung ja – die Begründung nicht mehr** | Siehe Abschnitt 2.1. Die Form ist durchgehend angewendet: die Steckbriefzeile `\| Status \| … \|` steht in **69** Kerndateien, und Prüfung 46 zählt sie |
+| **D-10** | Erweiterungsmodule, standardmäßig deaktiviert | „K-04 offen; Secure by Default" | **Ja** – Einwand siehe Abschnitt 3.3 | Seit 0.5.0 kein Vorsatz mehr, sondern erzeugt: `framework/runtime/` liefert **nur** `mcp-config.example.json`, keine wirksame Konfiguration, und `permissions.json` stellt **alle** MCP-Werkzeuge in `ask` (`{"tool": "mcp", "pattern": "*"}`) |
+
+### 2.1 D-08 ist der einzige Sonderfall – und er ist kein Hindernis
+
+**Bei acht von neun trägt die Begründung von 2026-09-01 unverändert. Bei D-08 trägt sie
+nicht mehr, und die Entscheidung steht trotzdem** – auf einem anderen Grund.
+
+Die Begründung war eine **Vorsichtsannahme**: Weil die Toleranz unbekannter
+Frontmatter-Schlüssel unbelegt war, sollten Framework-Metadaten nicht ins Frontmatter.
+Für `claude-code` ist die Lage seither geklärt (K-18): Die Herstellerdokumentation zählt
+die Felder je Artefaktart abschließend auf, und die Abbildung erzeugt seit D-26 und D-27
+**nur** dokumentierte Felder. Ein Metadatenfeld im Frontmatter wäre dort heute kein
+Risiko mehr, sondern ein **undokumentiertes Feld** – Ballast ohne Durchsetzung. Für
+`devin-desktop` ist die Frage unverändert unbelegt; dort trägt die alte Begründung weiter.
+
+**Dieselbe Entscheidung, zwei Gründe, je Client ein anderer.** Das ist genau die Lage,
+für die es die Fähigkeitsmatrix gibt, und es ist kein Einwand gegen die Bestätigung. Der
+Statustext hält beides fest, damit niemand die Begründung von 2026-09-01 für die heutige
+hält.
+
+> **Eine Bestätigung ist keine Behauptung, dass sich nichts geändert hat.** Sie ist die
+> Feststellung, dass die Entscheidung heute trägt – und wo sie es aus einem anderen Grund
+> tut, gehört der andere Grund hingeschrieben.
+
+## 3. Die drei Einwände aus `CR-2026-019` – und was sie wirklich treffen
+
+### 3.1 D-05 / `AP2-CC-12`: ein Einwand gegen die Durchsetzungstiefe, nicht gegen die Regel
+
+**Der Einwand, wörtlich:** Ob die Sperre gegen den Modus ohne Rückfragen auch für das Feld
+`permissionMode` eines Subagentenprofils gilt, ist nicht dokumentiert.
+
+**Gemessen: die Frage ist unverändert offen.** Die Erhebung vom 2026-09-13 über
+Unteragenten führt sie ausdrücklich unter „Was diese Erhebung nicht belegt": „`permissionMode`
+im Profil (`AP2-CC-12`, offene Teilfrage zu M2). **Unberührt.**"
+
+**Und sie ist trotzdem kein Einwand gegen D-05.** D-05 entscheidet, dass der Modus ohne
+Rückfragen **untersagt** ist. `AP2-CC-12` fragt, ob ein bestimmter Client dieses Verbot auf
+einem bestimmten Weg zusätzlich **technisch** erzwingen kann. Das sind zwei verschiedene
+Dinge, und dass sie zwei sind, ist keine Auslegung, sondern **D-12**: Jede technische
+Zusage wird je Client als `[TECHNISCH]`, `[TEXTUELL]` oder `[NICHT ABBILDBAR]`
+eingestuft, weil eine Regel auch dort gilt, wo die Engine sie nicht erzwingt.
+
+> **Wer eine Regel erst bestätigt, wenn jeder Client sie technisch erzwingt, hat D-12
+> abgeschafft** – und mit ihr die halbe Begründung des Frameworks.
+
+**Dazu ein Messwert, der die Reichweite des Einwands bemisst:** Das Framework liefert
+**genau ein** Agentenprofil aus, und es setzt das Feld `permissionMode` **nicht**. Die
+offene Frage hat in den ausgelieferten Artefakten keinen Träger. Sie bleibt offen, sie
+bleibt eine Verifikationsschuld der Fähigkeitsmatrix – **und sie steht in Kriterium 1 von
+D-11, nicht in Kriterium 4.**
+
+### 3.2 D-07 / `K-20`: das Modell beantwortet den Einwand in seinem eigenen Abschnitt 1.3
+
+**Der Einwand, wörtlich:** K-20 – Art und Ort der Codebasis-Indexierung – ist bei
+`devin-desktop` unbelegt; das Datenschutzmodell setzt eine Aussage darüber voraus.
+
+**Der zweite Halbsatz ist falsch, und der Gegenbeweis steht im Modell selbst.**
+`framework/core/02-privacy.md` regelt den Fall der fehlenden Aussage ausdrücklich:
+
+> Abschnitt 1.3: *Bis zum Vorliegen dieser Prüfung gilt die restriktivste Auslegung: Nur
+> Kontextklasse K0 und K1 dürfen bereitgestellt werden …*
+>
+> Abschnitt 2.2 Regel 3: *Fehlt eine Einstufung, gilt K3.*
+
+**Das Modell setzt die Aussage nicht voraus – es enthält die Regel für ihr Fehlen.** Ein
+Modell, das seinen eigenen unbeantworteten Eingabewert auffängt, wird durch dessen
+Unbeantwortetheit nicht geschwächt; es wird durch sie **vorgeführt**. Dass K-20 offen ist,
+ist ein Argument **für** D-07 und gegen die Alternative „Freitextregeln", die für diesen
+Fall gar keine Antwort gehabt hätte.
+
+**Dazu die Zuständigkeit:** Abschnitt 1.2 desselben Moduls erklärt die vertraglichen und
+technischen Bedingungen – Verarbeitungsorte, Aufbewahrung, Codebasis-Indexierung –
+ausdrücklich für **organisationsspezifisch** und verlangt sie vor der Einführung geprüft
+und im Overlay referenziert. **Das ist Aufgabe der aufnehmenden Organisation, und D-11
+nimmt genau das aus.** Der offene Rest von K-20 ist ein VERIFY-Marker – **Kriterium 1**,
+nicht Kriterium 4. Ihn zur Bedingung von Kriterium 4 zu machen, koppelt zwei Kriterien,
+die D-11 getrennt aufzählt.
+
+### 3.3 D-10 / `K-04`: die Zusage hat ein Gegenüber, und es ist ein Mechanismus
+
+**Der Einwand, wörtlich:** K-04 – Nutzungsumfang Cloud/CLI – ist offen und liegt außerhalb
+des Frameworks. Solange die Organisation ihn nicht festgelegt hat, ist „vorgesehen,
+standardmäßig deaktiviert" eine Zusage ohne Gegenüber.
+
+**Zwei Gründe, und der zweite ist der stärkere.**
+
+**Erstens die Zuständigkeit.** K-04 nennt als entscheidende Rolle „Projektleitung mit
+Informationssicherheit" und trägt den Platzhalter `<TBD: Freigabe Cloud/CLI-Nutzung>`. Das
+ist eine **organisatorische Freigabe**. D-11 sagt dazu einen Satz, und er ist eindeutig:
+*Pilot, Onboarding und organisatorische Freigabe sind **nicht** Vorbedingung, sondern
+Aufgabe der aufnehmenden Organisation.* Ein Einwand, der genau das zur Vorbedingung macht,
+steht gegen die Entscheidung, deren Kriterium er bedienen will.
+
+**Zweitens der Mechanismus.** „Eine Zusage ohne Gegenüber" trifft seit 0.5.0 nicht mehr zu,
+und das ist nachzählbar: `framework/runtime/` liefert **keine** wirksame MCP-Konfiguration
+aus, sondern nur `mcp-config.example.json`; `permissions.json` stellt **alle**
+MCP-Werkzeuge in `ask`. Die Deaktivierung ist erzeugt, nicht versprochen. **D-10 ist
+gerade die Entscheidung, die das Framework sicher hält, solange K-04 offen ist** – sie
+braucht K-04 nicht beantwortet, sie ist die Antwort auf seine Offenheit.
+
+### 3.4 Was die drei gemeinsam haben
+
+| Einwand | Wogegen er sich richtet | Wozu er gehört |
+|---|---|---|
+| `AP2-CC-12` (D-05) | die Durchsetzungstiefe **eines** Clients | Fähigkeitsmatrix (D-12), Kriterium 1 von D-11 |
+| `K-20` (D-07) | eine **Eingabe** des Modells, deren Fehlen das Modell selbst regelt | organisatorische Prüfung, Kriterium 1 von D-11 |
+| `K-04` (D-10) | eine **organisatorische Freigabe** | aufnehmende Organisation – von D-11 ausdrücklich ausgenommen |
+
+**Keiner der drei richtet sich gegen die Entscheidung, gegen die er vorgebracht ist.**
+Alle drei sind gute Fragen, keine davon ist beantwortet, und keine davon gehört zu
+Kriterium 4.
+
+> **Der wiederkehrende Befundtyp dieses Repositoriums, eine Ebene höher:** Sonst ist es
+> *eine Zusage, die mehr verspricht, als sie leistet*. Hier ist es **eine Bedingung, die
+> mehr verlangt, als ihr Kriterium fordert** – und das hält genauso zuverlässig auf, wie
+> eine zu schwache Zusage durchlässt. Zweiunddreißig Releases lang, mit einem grünen
+> Validator bei jedem einzelnen.
+
+## 4. Nebenbefunde
+
+### 4.1 Die Legende erklärt vier Statuswerte, die Tabelle führt sieben
+
+**Beim Nachzählen der Statuszelle, also beim Vorbereiten eben dieses Antrags, angefallen.**
+Die Legende in Zeile 4 von `DECISION_LOG.md` nennt `geklärt`, `entschieden (Vorschlag)`,
+`offen` und `verify`. Abgezählt über beide Tabellen:
+
+| Statuswert | Vorkommen | In der Legende? |
+|---|---|---|
+| `entschieden (CR-2026-NNN)` | **89** Decision Records | **nein** |
+| `ersetzt durch D-11` | 1 (D-09) | **nein** |
+| `offen by design` | 1 (K-16) | **nein** |
+| `geklärt durch Auftrag` | 1 (K-09) | **nein** |
+| `entschieden (Vorschlag)` | 9 Records, 5 Klärungspunkte | ja |
+| `geklärt`, `offen`, `verify` | übrige | ja |
+
+**Der meistverwendete Statuswert des Dokuments steht nicht in seiner Legende** – seit
+D-11 und neunundachtzig Records. Das ist der Befundtyp dieses
+Repositoriums in seiner Grundform: ein Verzeichnis, das seinen eigenen Bestand nicht
+vollständig nennt.
+
+**Berichtigt, nicht geprüft.** Eine Prüfung, die das Vokabular der Statuszellen gegen die
+Legende hält, ist baubar und wäre die richtige Abhilfe. Sie ist hier **bewusst nicht
+gebaut**: Der `<FRAMEWORK_OWNER>` hat für dieses Release angeordnet, keine neue Prüfung zu
+bauen, bevor sich eine der vier D-11-Zahlen bewegt hat. **Sie bewegt sich mit diesem
+Release** – die Prüfung ist damit ab dem nächsten zulässig und steht als Kandidat. Siehe
+E5.
+
+### 4.2 `K-08` ist die offene Entscheidung von `AP3` und trägt denselben Statuswert
+
+`AP3` führt in seinem Feld „Offene Entscheidungen" genau einen Eintrag: *Bestätigung der
+8-stufigen Hierarchie (K-08)*. K-08 steht auf `entschieden (Vorschlag)` und sagt in der
+Sache dasselbe wie D-01 und D-06.
+
+**D-01 und D-06 zu bestätigen und K-08 stehen zu lassen, hieße denselben Sachverhalt in
+zwei Zuständen zu führen** – das zweite Register neben dem ersten, und dieses Repositorium
+hat diesen Befundtyp in seinem eigenen Bestand siebenmal gefunden. K-08 geht mit.
+
+**Die vier übrigen Klärungspunkte auf `entschieden (Vorschlag)` gehen nicht mit.** Sie
+tragen offene Teilfragen und keinen Decision Record: K-12 (Skill-Ablage – die Discovery
+ist unverifiziert, die Sache ist durch D-15 und D-16 ohnehin in eine Pfadabbildung je Pack
+überführt), K-13 (Ablage und Verteilung), K-17 (Sprache) und K-18 (Frontmatter-Felder –
+für einen Client geklärt, für den anderen `verify`). Siehe E4.
+
+### 4.3 Nachtrag zum Protokoll von `CR-2026-070`
+
+Das Protokoll `2026-09-15-gegenpruefung-d11-zaehlregeln.md` formuliert die Zeile zum
+seriellen Abnahmelauf **vorsichtiger, als die Messung es verlangt**: Es sagt, der Vergleich
+sei an einem Zwischenstand gemessen, weil der serielle Lauf gegen den endgültigen Wortlaut
+bei Protokollabschluss noch nicht zurück war. **Er ist es inzwischen, und er ist grün** –
+Exit 0, 250 Ergebniszeilen, sortiert deckungsgleich mit dem nebenläufigen Lauf, 977 s auf
+einer Bahn gegen 128 s auf acht. Das ist kein Fehler im Protokoll (es behauptet weniger,
+als wahr ist) und kein eigenes Release wert; es ist hier nachgetragen, wie die Übergabe es
+vorgesehen hat.
+
+## 5. Vorgeschlagene Änderung
+
+1. **Die neun Records D-01 bis D-08 und D-10 wechseln den Status** auf
+   `entschieden (CR-2026-071)`. Der Wortlaut von 2026-09-01 und die Fortschreibung aus
+   `CR-2026-019` bleiben unverändert stehen (die Regel aus `CR-2026-019`: ein Decision Log
+   ist ein Verlaufsdokument). Angehängt wird je Record ein Satz, der die Bestätigung datiert
+   und den Beleg nennt, auf dem sie steht.
+2. **`K-08` wird mitbestätigt** – die offene Entscheidung von `AP3`, in der Sache D-01 und
+   D-06.
+3. **Die Legende führt die Statuswerte, die die Tabellen wirklich verwenden** (Nebenbefund
+   4.1).
+4. **Zwei neue Decision Records:** D-100 (die Bestätigung und ihr Maßstab), D-101 (das
+   Statusvokabular des Decision Logs).
+5. **Die Standzeile in `docs/ROADMAP.md`** wird nachgezogen: Kriterium 4 von **9 auf 0**.
+   Das ist der Vorgang, für den Prüfung 46 gebaut ist – **ohne ihn wäre der Lauf rot**.
+6. **Sonde 46f wird umgebaut.** Sie hob bisher D-10 aus `entschieden (Vorschlag)` und
+   belegte damit die Richtung „Fortschritt nicht nachgezogen". Nach diesem Release hat die
+   Hebung keinen Gegenstand mehr – die Sonde **stellt ihren Defekt jetzt her statt ihn zu
+   entfernen** und deckt die Richtung, die bisher **keine** Sonde deckte: den **Rückfall**.
+7. **Die Roadmap** zieht Kriterientabelle, den Abschnitt „Strukturentscheidungen
+   bestätigen" und das Feld „Offene Entscheidungen" von `AP3` nach.
+
+## 6. Vorlage zur Entscheidung
+
+| Nr. | Frage | Vorschlag | Preis |
+|---|---|---|---|
+| **E1** | **Welcher Statuswert?** „Bestätigen" ist der Vorgang; welcher Zustand steht danach da? | **`entschieden (CR-2026-071)`** – derselbe Wert, den die übrigen **89** Records tragen. Der Vorgang steht in der Antragsnummer und im angehängten Satz, nicht in einem eigenen Wort | **Der Unterschied zwischen „vorgeschlagen und bestätigt" und „von Anfang an entschieden" ist danach nur noch im Text der Zelle zu lesen, nicht mehr am Statuswort.** Das ist hinnehmbar, weil die Zelle ihn ausdrücklich nennt und das Datum 2026-09-01 stehen bleibt. Verworfen: **ein eigener Wert `bestätigt`** – ein zweites Vokabular für denselben Zustand, und Prüfung 46 müsste es mitlernen; genau der Befundtyp, den dieses Repositorium siebenmal gefunden hat |
+| **E2** | **Alle neun in einem Antrag – oder je Record ein eigener?** | **Alle neun in einem.** Sie teilen den Anlass (`AP3`), das Datum, die Vorlage aus `CR-2026-019` und den Maßstab | Preis: Wer später nachliest, warum **ein** Record bestätigt wurde, liest einen Antrag über neun. **Aufgefangen durch die Zeile je Record in Abschnitt 2** – und neun Anträge über denselben Vorgang wären neun Kopien derselben Begründung. Verworfen: **nur die sieben ohne Einwand bestätigen** – das hätte die drei Einwände ein zweites Mal ungeprüft stehen gelassen, und ihre Prüfung ist der Ertrag dieses Antrags |
+| **E3** | **Was geschieht mit den drei Einwänden – aufgelöst oder übergangen?** | **Aufgelöst, einzeln, mit Beleg** (Abschnitt 3). Die drei **Fragen** bleiben offen und behalten ihren Ort: `AP2-CC-12` in der Fähigkeitsmatrix, K-20 und K-04 in der Klärungstabelle | **Es bleibt drei offene Fragen zu einem bestätigten Bestand.** Das ist die Lage und nicht ihre Verschleierung: Keine der drei ist eine Frage nach Kriterium 4. Verworfen: **die Bestätigung bis zu ihrer Beantwortung zurückstellen** – das ist genau das, was zweiunddreißig Releases lang geschehen ist, und zwei der drei liegen ausdrücklich außerhalb des Einflussbereichs des `<FRAMEWORK_OWNER>`, den D-11 zum Maßstab macht |
+| **E4** | **Gehen die fünf Klärungspunkte auf `entschieden (Vorschlag)` mit?** | **Nur `K-08`.** Es ist die namentlich genannte offene Entscheidung von `AP3` und sagt in der Sache dasselbe wie D-01 und D-06 | **Vier Klärungspunkte behalten einen Statuswert, den kein Decision Record mehr trägt.** Das ist gewollt: Ein Klärungspunkt ist eine **Frage**, ein Decision Record eine **Festlegung**, und bei allen vieren ist ein Teil der Frage unbeantwortet (K-12 Discovery unverifiziert, K-18 bei einem Client `verify`). Prüfung 46 zählt sie nicht – das ist seit `CR-2026-070` entschieden und hier nicht neu aufzumachen. Verworfen: **alle fünf mitnehmen** – das hätte vier offene Fragen für entschieden erklärt, um eine Zahl zu senken, die sie gar nicht zählt |
+| **E5** | **Bekommt das Statusvokabular eine Prüfung?** Die Legende nannte vier von sieben Werten | **Nein, nicht in diesem Release.** Die Legende wird berichtigt; die Prüfung steht als Kandidat für das nächste | **Eine Zusage ohne Mechanismus, und der Antrag sagt es selbst.** Der Grund ist eine ausdrückliche Anweisung des `<FRAMEWORK_OWNER>` vom 2026-09-15: keine neue Prüfung, bevor sich eine der vier D-11-Zahlen bewegt hat. **Mit diesem Release bewegt sie sich** – die Sperre fällt danach, und der Kandidat steht in der Roadmap. Verworfen: **die Prüfung gleich mitbauen** – dann wäre dieses Release wieder zur Hälfte Arbeit am Prüfapparat, und genau das war der Anlass der Anweisung |
+| **E6** | **Was wird aus Sonde 46f?** Sie hebt D-10 aus `entschieden (Vorschlag)`; nach diesem Release gibt es dort nichts mehr zu heben | **Umbauen: Sie setzt einen bestätigten Record auf `entschieden (Vorschlag)` zurück** und belegt damit den **Rückfall** – die Richtung, die bisher keine Sonde deckte, weil Kriterium 4 nie null war | **Die Richtung „Fortschritt nicht nachgezogen" verliert bei Kriterium 4 ihre Sonde.** Sie bleibt gedeckt: Sonde 46a stellt eine Zahl der Standzeile zu hoch und erzeugt genau diese Meldung. Verworfen: **die Sonde auf ein anderes Kriterium umhängen** – dann prüfte sie nicht mehr den Gegenstand, an dem der Rückfall wirklich eintreten kann; **die Sonde entfernen** – eine Prüfung ohne Sonde gilt nach D-23 als nicht vorhanden, und Prüfung 46 hat vier Gegenstände |
+| **E7** | **Muss die Standzeile in demselben Release nachgezogen werden?** | **Ja, im selben Patch.** Ohne sie ist der Lauf rot | **Keiner – das ist der Preis, den `CR-2026-070` E1 ausdrücklich gewollt hat.** Dies ist der erste Fall, in dem der Mechanismus greift, und er greift bei einem Fortschritt. **Gemessen zwischen zwei Patches:** Nach dem Statuswechsel im Decision Log und **vor** dem Nachziehen der Standzeile meldete der Lauf gegen den Arbeitsbaum genau **einen** Fehler, und zwar über einen **Fortschritt** – `Kriterium 4 … ist gezählt 0, die Standzeile nennt 9`. Ohne diese Bauform stünde dort heute noch neun |
+
+## 7. Prüffragen (durch Owner auszufüllen)
+
+- [x] Richtige Ebene nach Entscheidungsbaum 6? — Ja. Gegenstand sind die Strukturentscheidungen des Kerns; geändert werden ein Governance-Dokument, die Roadmap und eine Sonde. Keine Regel wird eingeführt oder gelockert.
+- [x] Verschärfungsprinzip eingehalten? — Nicht berührt. Keine Regel ändert ihren Inhalt; neun Festlegungen wechseln ihren Status.
+- [x] Widerspruchsfreiheit geprüft? — Gegenstand von Abschnitt 2 und 3. Gelesen: `PRIORITY_HIERARCHY.md`, `framework/core/02-privacy.md`, `framework/core/08-skill-conventions.md`, beide `CLIENT_PACK.md`, `framework/runtime/permissions.json`, `clientmap.py`, `CR-2026-018`, `CR-2026-019`, `CR-2026-070`, `tests/protocols/2026-09-13-erhebung-unteragent.md`.
+- [x] Laufzeitfassungen betroffen? — Nein. Weder Wurzel-Anweisungsdatei noch Regelablage noch Berechtigungsdatei ändern sich; `install.py --check` bleibt unberührt.
+- [x] Belegstatus korrekt? — Jede Zeile von Abschnitt 2 nennt eine gemessene Fundstelle. Die drei offenen Fragen sind als **offen** geführt und nicht als beantwortet ausgegeben.
+- [x] Test- und Validierungsbedarf? — Keine neue Prüfung (E5). **Eine bestehende Sonde bricht und wird umgebaut** (E6); der Gegenbeweis dazu steht im Wirkungsnachweis. Validator und Sondenlauf in beiden Kodierungsumgebungen.
+- [x] Auswirkungen auf Overlays und laufende Onboardings? — Keine. Der Kern bleibt byte-gleich bis auf Governance- und Dokumenttexte; Prüfung 46 läuft in jeder Installation mit derselben Standzeile.
+- [x] Dokumentation? — CHANGELOG, Decision Log (D-100, D-101), Roadmap (Standzeile, Kriterientabelle, `AP3`), Protokolle.
+
+## 8. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen.** E1 bis E7 wie vorgelegt am 2026-09-15 durch den Framework Owner entschieden |
+| Datum | 2026-09-15 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Begründung | Die Vorlage aus `CR-2026-019` liegt seit zweiunddreißig Releases unbeantwortet vor. Ihre Gegenprüfung zeigt: Bei acht von neun Records trägt die Begründung von 2026-09-01 unverändert, bei D-08 trägt die Entscheidung auf einem anderen Grund – und die drei benannten Einwände richten sich sämtlich gegen etwas anderes als die Entscheidung, gegen die sie vorgebracht sind. Zwei von ihnen machen zur Bedingung, was D-11 ausdrücklich ausnimmt. **Eine falsch gewählte Bedingung wartet für immer**; sie wird hier nicht erfüllt, sondern richtiggestellt |
+| Decision-Log-Eintrag | **D-100** (die neun sind bestätigt; Maßstab ist die tragende Begründung, nicht die unveränderte), **D-101** (das Statusvokabular des Decision Logs steht vollständig in seiner Legende) |
+| Auflagen | **Der Gegenbeweis gehört dazu:** Die umgebaute Sonde 46f MUSS gegen 0.48.0 fallen und gegen `main` bestehen. **Dazu ist zu messen, was die alte Fassung auf dem neuen Stand anrichten würde** – und das Ergebnis gehört ins Protokoll, auch wenn es unbequemer ist als erwartet: Sie meldet **nicht** `[Praeparation gebrochen]`, sondern ihr Suchtext trifft weiterhin – im Verlaufszusatz der Zelle, also an einer Stelle, die Prüfung 46 gar nicht liest. Der Baumvergleich meldet dann kein `[nichts praepariert]`, und der Fehlschlag sähe aus wie ein Befund an der Prüfung, wo einer an der Sonde vorliegt. **Das ist der schlechteste der drei möglichen Zustände, und er ist der Grund, warum die neue Fassung den ANFANG der Statuszelle trifft statt eine Zeichenkette irgendwo in ihr.** **Dazu die Gegenprüfung selbst:** Jeder der neun Records ist mit seiner Begründung, seinem Beleg und seinem Urteil im Protokoll auszuweisen; eine Bestätigung ohne die neun Nachweise wäre genau die Bauform, die dieses Repositorium beanstandet |
+| Ziel-Release | `0.49.0` |
+| Umsetzung | umgesetzt mit `0.49.0` |
+
+## 9. Umsetzung (nach Annahme)
+
+- [x] D-01 bis D-08 und D-10 auf `entschieden (CR-2026-071)`; Wortlaut, Begründung und Datum von 2026-09-01 sowie die Fortschreibung aus `CR-2026-019` unverändert stehen gelassen
+- [x] Je Record ein angehängter Satz mit Datum und Beleg der Bestätigung
+- [x] `K-08` mitbestätigt (E4)
+- [x] Legende um `entschieden (CR-…)`, `ersetzt durch …`, `offen by design` und `geklärt durch Auftrag` ergänzt (D-101)
+- [x] D-100 und D-101 eingetragen
+- [x] Standzeile in `docs/ROADMAP.md`: Kriterium 4 von 9 auf **0** (E7)
+- [x] Sonde 46f umgebaut (E6), Gegenbeweis gegen 0.48.0 im Wirkungsnachweis
+- [x] Roadmap: Kriterientabelle, Abschnitt „Strukturentscheidungen bestätigen", `AP3` nachgezogen
+- [x] Validator 0 Fehler, 0 Warnungen; Sondenlauf in beiden Kodierungsumgebungen über 251 Zeilen zeilengleich, Exit 0 (154 Sonden, 62 Gegenproben, 12 Selbstproben – unverändert gegenüber 0.48.0)
+- [x] Gegenbeweis gegen 0.48.0: **genau eine Abweichung**, und es ist Sonde 46f mit `[Praeparation gebrochen]`
+- [x] Die zweite Richtung der Auflage gemessen – die alte Fassung hätte **danebengetroffen statt gebrochen**; der Antragstext ist gegen die Messung berichtigt worden, nicht umgekehrt
+- [x] Wirkungsnachweis: `tests/protocols/2026-09-15-wirkungsnachweise-0.49.0.md`
+- [ ] **Folgearbeit:** Die Prüfung auf das Statusvokabular des Decision Logs (E5, Nebenbefund 4.1) – ab dem nächsten Release zulässig, weil sich mit diesem eine der vier D-11-Zahlen bewegt hat
+- [ ] **Folgearbeit:** Die vier Klärungspunkte K-12, K-13, K-17 und K-18 (E4) – je ein eigener Vorgang, weil bei allen vieren ein Teil der Frage unbeantwortet ist