@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-038-importsteuerung.md

@@ -0,0 +1,159 @@
+# Änderungsantrag `CR-2026-038`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Die Quellen außerhalb des Projekts lassen sich abschalten – aus der Auskunft nach D-34 kann eine Schranke werden |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-11 |
+| Betroffene Artefakte | beide `manifest.json` (neue Abbildung), `clientmap.py`, beide `CLIENT_PACK.md` (Zeile R5 und neuer Abschnitt), `governance/PRIORITY_HIERARCHY.md` (Regel 2.6, nachrichtlich), `governance/DECISION_LOG.md` (Fortschreibung D-34), `tests/scripts/validate-framework.py` (mögliche Prüfung 22) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Semantikabbildung und Abbildungsschicht; betrifft **beide** Client Packs |
+| Art | Fortschreibung von D-34 nach der Erhebung K-21/K-23 (`tests/protocols/2026-09-11-erhebungen-K21-K26.md`) |
+| Dringlichkeit | regulär; der Beschluss zu `CR-2026-031` ist noch nicht umgesetzt, beide Änderungen fallen in dieselbe Umsetzung |
+
+## 1. Anlass und Problem
+
+D-34 ist am 2026-09-11 unter einer ausdrücklich benannten Annahme entschieden worden: Eine Quelle
+außerhalb des Projekts sei **auszuweisen, nicht zu unterbinden**. K-21 stand offen, und der
+Antrag sagte dazu: „Eine Auskunft ist keine Schranke."
+
+**Die Erhebung desselben Tages hat K-21 beantwortet – mit Ja, für beide Packs.**
+
+### Was gemessen wurde
+
+| Pack | Mechanismus | Messung |
+|---|---|---|
+| `devin-desktop` | `read_config_from` in **`.devin/config.json`**, also in der Berechtigungsdatei, die das Framework ohnehin erzeugt | Mit `windsurf: false` verschwindet der Inhalt der fremden Regel aus dem Kontext; ohne die Einstellung steht er darin. Mit `claude: false` sinkt die Skill-Zahl von 69 auf 2 – die 67 fremden Skills sind weg |
+| `claude-code` | `claudeMdExcludes` in den Projekteinstellungen | Ohne die Einstellung lädt die `CLAUDE.md` eines Elternverzeichnisses mit; mit ihr bleibt allein die des Projekts |
+
+Beides ist **projektseitig** wirksam, versionierbar und steht damit in Artefakten, die das
+Framework schon heute schreibt.
+
+### Der zweite Anlass: Es sind nicht nur Anweisungen
+
+Die Erhebung hat außerhalb des Projekts auch **Konfiguration** gefunden (ERH-07):
+`~/.claude/settings.json` führt sechs `allow`-Regeln **und** Hooks für `SessionStart`,
+`PreToolUse` und `PostToolUse`; eine nutzerlokale Einstellungsdatei liegt zusätzlich im
+Elternverzeichnis des Projekts.
+
+**D-34 spricht von „Regeltexten, Skills oder Profilen".** Berechtigungen und Hooks außerhalb des
+Projekts fallen nicht darunter – obwohl gerade sie die Linien betreffen, auf denen die
+Kernzusagen B1 bis B6 stehen.
+
+### Der dritte Anlass: Die Aufzählung zeigt mehr, als lädt
+
+Zeile R5 aus `CR-2026-031` sagt zu: „Die geladenen Regelquellen sind vollständig aufzählbar."
+Gemessen ist das Gegenteil einer Lücke – ein Überschuss: Mit abgeschaltetem Import führt
+`devin rules list` die fremde Regel **weiter auf**, obwohl ihr Inhalt nicht mehr im Kontext steht
+(ERH-02). Dazu nennt `devin skills paths` die Ablage nicht, aus der 67 von 81 Skills stammen
+(ERH-03).
+
+**Die Aufzählung ist eine Auskunft des Clients über sich selbst, kein Abbild des Kontexts.**
+
+## 2. Vorgeschlagene Änderung
+
+1. **Der Kern trifft die Aussage werkzeugneutral:** Das Framework importiert **keine** Regel- und
+   Skillquellen fremder Werkzeugformate. Die eigene Wurzel-Anweisungsdatei ist davon
+   ausgenommen – sie ist bei `devin-desktop` genau eines dieser Formate.
+
+2. **Jedes Pack bildet die Aussage ab**, wie es Berechtigungen und Hooks abbildet (D-18):
+   - `devin-desktop`: `read_config_from` mit `agents_standard: true` und `cursor`, `windsurf`,
+     `claude` auf `false`, erzeugt von `clientmap.py` in die Berechtigungsdatei.
+   - `claude-code`: `claudeMdExcludes` – **nicht** als Vorgabe der Installation, siehe E2.
+   Ein Pack, dessen Client keinen solchen Mechanismus kennt, trägt die Aussage als
+   `[NICHT ABBILDBAR]` und bleibt bei der Auskunft.
+
+3. **Der Auskunftsabschnitt aus `CR-2026-031` heißt „Anweisungs- und Konfigurationsquellen
+   außerhalb des Projekts"** und führt auch Berechtigungs-, Hook- und
+   Einstellungsdateien außerhalb des Repositoriums.
+
+4. **Zeile R5 trägt den Vorbehalt aus ERH-02**: Die Aufzählung des Clients ist nicht
+   deckungsgleich mit dem, was lädt – sie kann zu viel zeigen und, wie ERH-03 belegt, auch zu
+   wenig.
+
+5. **D-34 wird fortgeschrieben**, nicht ersetzt: Der Rang bleibt, wie er ist; ergänzt wird, dass
+   eine Quelle, für die der Client eine Importsteuerung kennt, **abgeschaltet statt nur
+   ausgewiesen** wird.
+
+6. **Prüfung 22 (siehe E4):** Die installierte Berechtigungsdatei führt die Importsteuerung so,
+   wie das Manifest sie abbildet. Sonde nach D-23: Ein Wert wird in einer Kopie verfälscht – die
+   Prüfung meldet ihn.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Den Rang aus D-34.** Eine Quelle außerhalb des Projekts bleibt ebenenlos. Wer sie abschaltet,
+  ändert nicht ihren Rang, sondern ihre Anwesenheit.
+- **Die Auskunftspflicht.** Sie gilt weiter, und gerade dann: Was abgeschaltet ist, muss benannt
+  sein, sonst sucht jemand den Fehler an der falschen Stelle.
+- **`agents_standard`.** Dieser Schalter bleibt `true`. Er steuert bei `devin-desktop` das Format
+  der **eigenen** Wurzel-Anweisungsdatei; ihn abzuschalten hieße, das Framework abzuschalten.
+- **Die Prioritätshierarchie.** Regel 2.6 bleibt unverändert.
+
+## 4. Grenze der Zusage
+
+**Gemessen wurde mit drei abgeschalteten Formaten zugleich.** `windsurf: false` allein ist nicht
+geprüft; ebenso wenig, welches der drei `claudeMdExcludes`-Muster greift.
+
+**Die Importsteuerung räumt das Register nicht.** `devin rules list` führt die Quelle weiter auf
+(ERH-02). Wer die Wirkung prüfen will, muss den Kontext messen, nicht das Register lesen – genau
+die Unterscheidung, an der `AP2-DD-10` hing.
+
+**Der Vorrang gegenüber der nutzerglobalen Konfiguration ist unbekannt.** Die Dokumentation nennt
+dieselben Schlüssel für `%APPDATA%\devin\config.json`. Ob eine nutzerglobale Einstellung die
+projektseitige aufhebt, ist **nicht gemessen** – neu als **K-27**. Fiele die Antwort ungünstig
+aus, wäre die Schranke wieder eine Auskunft.
+
+**Ein Mensch kann sie zurücknehmen.** Die Einstellung steht in der Berechtigungsdatei; der
+KI-Client darf sie nicht schreiben, eine Person schon. Das ist dieselbe Grenze wie bei B9.
+
+**Die Maßnahme nimmt etwas weg.** Wer 67 Skills eines anderen Werkzeugs gewohnt ist, verliert sie
+in Projekten mit dieser Installation. Das ist die Absicht – aber es ist eine Absicht, die jemand
+erklären muss.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Fremdformate bei `devin-desktop` abschalten? | **Ja.** Die Quelle lädt sonst unbedingt und ebenenlos in jedes Projekt; die Steuerung liegt in einer Datei, die das Framework ohnehin schreibt | Skills und Regeln anderer Werkzeuge stehen in einem Projekt mit dieser Installation nicht mehr zur Verfügung. Wer sie braucht, braucht eine Ausnahme |
+| E2 | `claudeMdExcludes` als Vorgabe der Installation bei `claude-code`? | **Nein.** Eine `CLAUDE.md` im Elternverzeichnis ist im Mehrprojekt-Verzeichnis oft **gewollt**; ein pauschaler Ausschluss bräche legitime Anordnungen | Bei diesem Pack bleibt es bei Auskunft und Empfehlung – die Lage ist damit zwischen den Packs verschieden, und die Matrix muss das zeigen |
+| E3 | Auskunft auf Konfigurationsquellen erweitern? | **Ja.** Berechtigungen und Hooks außerhalb des Projekts betreffen genau die Linien, auf denen B1 bis B6 stehen | Der Abschnitt wird länger und verlangt bei jeder Erhebung mehr Arbeit |
+| E4 | Prüfung 22 aufnehmen? | **Ja.** Ohne sie ist die Importsteuerung eine Zeile, die eine Installation still verlieren kann – der Befundtyp dieses Projekts | Eine Prüfung mehr, gebunden an ein clientspezifisches Feld; ein Pack ohne den Mechanismus muss ausdrücklich ausgenommen sein |
+| E5 | K-27 (Vorrang nutzerglobal gegen projektseitig) vor der Umsetzung erheben? | **Erledigt am 2026-09-11.** Ergebnis im Nachtrag unten: Die Benutzerkonfiguration hat Vorrang | Die Antwort ist ungünstig – sie kostet die Einstufung, nicht die Maßnahme |
+
+> **Vor der Entscheidung Abschnitt 7 lesen.** K-27 ist nach dem Verfassen dieses Antrags erhoben worden; das Ergebnis ändert die Einstufung der Maßnahme und bringt eine sechste Frage mit.
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** |
+| Datum | 2026-09-11 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | E1 bis E6 wie vorgelegt, mit der Änderung aus dem Nachtrag: Die Importsteuerung wird gesetzt (`agents_standard` bleibt **true** – das ist die eigene Wurzel-Anweisungsdatei), ihre Einstufung ist jedoch **`[TEXTUELL]`**, weil die Benutzerkonfiguration Vorrang hat (K-27); bei `claude-code` **keine** Vorgabe von `claudeMdExcludes`; die Auskunft umfasst auch **Konfigurationsquellen**; Zeile R5 trägt den Vorbehalt aus ERH-02; Prüfung 22 kommt hinzu; **E6: Zeile B9 im Pack `devin-desktop` wird auf den gemessenen Stand gebracht** (ERH-11 widerlegt die Zusage für diesen Client). Ziel-Release 0.26.0 |
+| Umsetzung | **mit Release 0.26.0** – Einzelheiten und Nachweise in `leitwerk-core/CHANGELOG.md` |
+
+## 7. Nachtrag 2026-09-11 – K-27 ist erhoben, und die Antwort ist ungünstig
+
+`tests/protocols/2026-09-11-erhebungen-K21-K26.md`, Abschnitt 7.
+
+**Die nutzerglobale Einstellung hat Vorrang vor der projektseitigen** – gemessen in beiden
+Richtungen. Was Abschnitt 4 als Risiko benannt hat, ist eingetreten: „Fiele die Antwort ungünstig
+aus, wäre die Schranke wieder eine Auskunft."
+
+**Was das für diesen Antrag ändert – und was nicht:**
+
+- **Die Maßnahme bleibt richtig.** Ein Standard, der ohne Zutun gilt, ist besser als keiner. Wo
+  die Benutzerkonfiguration schweigt – der Normalfall – wirkt die projektseitige Einstellung;
+  das ist gemessen.
+- **Die Einstufung ändert sich.** Die Zeile ist `[TEXTUELL]`, nicht `[TECHNISCH]`: Das Framework
+  setzt einen Standard, den es nicht durchsetzt. Alles andere wäre die Art Zusage, gegen die
+  dieses Projekt seine Sonden gebaut hat.
+- **B9 ist bei diesem Pack widerlegt, nicht nur unbelegt** (ERH-11). Der VERIFY-Marker der Zeile
+  („ob der Client eine Lockerung technisch verhindert") ist aufgelöst: Er verhindert sie nicht.
+  Das gehört in dieselbe Umsetzung – als Korrektur der Zeile B9 und als bekannte Abweichung in
+  Abschnitt 5 des Packs.
+
+**Neue Frage zur Entscheidung:**
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E6 | B9 im Pack `devin-desktop` auf den gemessenen Stand bringen? | **Ja.** Die Zeile trägt heute einen offenen Marker, wo eine Messung vorliegt – und die Messung widerlegt die Zusage für diesen Client | Das Pack weist eine Zusage weniger aus. Dafür steht in der Matrix, was gilt, statt einer Frage, die beantwortet ist |

package/.koolie/core/governance/change-requests/CR-2026-039-normative-saetze-in-kommentaren.md

@@ -0,0 +1,124 @@
+# Änderungsantrag `CR-2026-039`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Ein normativer Satz im Kopfkommentar der Wurzel-Anweisungsdatei erreicht die Sitzung nicht |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-11 |
+| Betroffene Artefakte | `framework/runtime/root-instruction.md` (Kopfkommentar), `clients/claude-code/CLIENT_PACK.md` (Abschnitt zu K-18), `tests/scripts/validate-framework.py` (mögliche Prüfung 23), `governance/DECISION_LOG.md` (Klärungstabelle) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Laufzeitfassung der Wurzel-Anweisung |
+| Art | Befund aus der Erhebung vom 2026-09-11 (ERH-01); **keine AP2-Kennung** |
+| Dringlichkeit | regulär – die betroffene Zusage ist technisch anderweitig durchgesetzt (Abschnitt 4) |
+
+## 1. Anlass und Problem
+
+Die Wurzel-Anweisungsdatei beider Packs trägt denselben Kopfkommentar:
+
+```html
+<!-- Framework Core, Ebene 1. Version: siehe leitwerk-core/VERSION. Owner: <FRAMEWORK_OWNER>.
+     Diese Datei ist projektneutral. Projektspezifische Werte stehen ausschließlich in
+     project-overlay/OVERLAY.md und werden über <RULES_DIR>/20-project-overlay.md geladen.
+     Diese Datei darf nur über den Änderungsprozess des Frameworks geändert werden. -->
+```
+
+Der letzte Satz ist eine **Anweisung**. Er steht in der Datei, die der Client zu Beginn jeder
+Sitzung lädt, und liest sich wie jede andere Regel des Frameworks.
+
+**Er erreicht die Sitzung nicht.**
+
+### Die Messung
+
+In einer frischen `claude-code`-Installation wurde dieselbe Messmarke zweimal gesetzt: einmal in
+einem HTML-Kommentar, einmal als Klartextzeile – in der Wurzel-Anweisungsdatei **und** in einer
+Datei der Regelablage.
+
+| Fassung | Marke im Kontext? |
+|---|---|
+| `<!-- Messmarke … KENNSATZ-WURZEL-9915 -->` | **nein** |
+| `Messmarke der Erhebung: KENNSATZ-KLARTEXT-5560` | **ja**, wörtlich wiedergegeben |
+
+Dazu die Selbstauskunft derselben Sitzung, gefragt nach der letzten Zeile ihrer
+Projektanweisung: Sie nannte den letzten **Absatz** des Fließtextes und fügte von sich aus hinzu,
+das sei die letzte Zeile des *eingespeisten* Textes – ob die Datei auf der Platte weitergehe,
+könne sie ohne Lesen nicht sagen.
+
+**Der Client entfernt Kommentare, bevor er den Text einspeist.** Was im Kommentar steht, ist für
+Menschen geschrieben, auch wenn es wie eine Anweisung klingt.
+
+### Warum das trotz geringer Tragweite zählt
+
+Es ist der Befundtyp, den dieses Projekt verfolgt – **eine Zusage, die mehr verspricht, als sie
+leistet** –, und diesmal steht er im sichtbarsten Artefakt des Frameworks, in der ersten Datei,
+die jede Sitzung lädt. Er ist nicht dadurch harmlos, dass er folgenlos blieb; er ist dadurch
+harmlos, dass **eine andere Linie** ihn auffängt (Abschnitt 4).
+
+### Der Zusammenhang mit K-18
+
+`CR-2026-017` hat für `claude-code` entschieden, Zweck, Ladeverhalten und den Ladetrigger der
+Kernquelle je Regeldatei in einen HTML-Kommentar zu schreiben – weil `description` für
+Regeldateien dieses Clients nicht dokumentiert ist (K-18).
+
+Das bleibt richtig, bekommt aber eine gemessene Kante: Bei `devin-desktop` steht die
+Zweckbeschreibung im Frontmatter und geht bei einer modellentschiedenen Regel in die Auswahl ein;
+bei `claude-code` steht sie im Kommentar und geht nirgends ein. **Dieselbe Regeldatei erklärt sich
+dem Modell beim einen Client und nur dem Menschen beim anderen.** Praktisch trägt das wenig, weil
+dieser Client alle Regeltexte unbedingt lädt – aber es war nicht gewollt und bis heute nicht
+gemessen.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Normative Sätze verlassen den Kommentar.** Der Satz über den Änderungsprozess gehört in den
+   Fließtext der Wurzel-Anweisungsdatei – oder er entfällt, weil die Berechtigungsdatei ihn
+   ohnehin durchsetzt (siehe E1). Was im Kommentar bleibt, ist Herkunft: Ebene, Version, Owner,
+   Ladeverhalten.
+
+2. **Der Kommentar wird als das ausgewiesen, was er ist.** In `clients/claude-code/CLIENT_PACK.md`
+   erhält der Abschnitt zu K-18 einen Satz: Der Kommentar ist die Auskunft an den **Menschen**,
+   der die Datei öffnet; in den Kontext geht er bei diesem Client nicht.
+
+3. **Prüfung 23 (siehe E3):** In den Laufzeitartefakten des Kerns steht in einem HTML-Kommentar
+   kein normatives Schlüsselwort (`MUSS`, `DARF NICHT`, `SOLL`, `nur über den Änderungsprozess`).
+   Sonde nach D-23: ein solcher Satz in einer Kopie – die Prüfung meldet ihn.
+
+4. **K-28 neu:** Entfernt auch `devin-desktop` HTML-Kommentare vor dem Einspeisen? Gemessen ist
+   das nur für einen Client. Solange es offen ist, gilt die Annahme für beide – die strengere
+   Lesart.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Die Entscheidung aus K-18.** Zweck und Ladeverhalten bleiben im Kommentar; sie sind Auskunft,
+  keine Anweisung.
+- **Die Regeltexte.** Kein Regelinhalt wird verschoben.
+- **Die Wirkung der Regeln.** Alles, was im Fließtext steht, ist gemessen im Kontext – die
+  Erhebung hat für vier Regeldateien und die Wurzel-Anweisung genau das bestätigt.
+
+## 4. Grenze der Zusage
+
+**Der betroffene Satz ist technisch durchgesetzt, nur eben nicht durch sich selbst.** Die
+Berechtigungsdatei verweigert das Schreiben der Wurzel-Anweisungsdatei (`Write(AGENTS.md)`,
+`Edit(CLAUDE.md)`), und der Schutz-Hook prüft denselben Pfad. Der Befund kostet keine Sperre – er
+kostet die Verlässlichkeit der Aussage, dass in dieser Datei steht, was gilt.
+
+**Gemessen ist ein Client.** Für `devin-desktop` ist es unbelegt (K-28).
+
+**Gemessen sind zwei Dateiarten**, Wurzel-Anweisung und Regelablage. Für Skills und
+Agentenprofile ist es nicht erhoben.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Satz in den Fließtext heben oder streichen? | **In den Fließtext.** Die technische Durchsetzung ersetzt die Aussage nicht: Wer die Datei öffnet, soll den Änderungsprozess finden, und das Modell soll ihn nennen können, statt nur abzuprallen | Die Wurzel-Anweisungsdatei wächst um einen Satz – in der Datei, für die das Framework selbst Least Context fordert |
+| E2 | Auch die übrigen Kommentarinhalte verschieben? | **Nein.** Herkunft, Version und Ladeverhalten sind Auskunft an den Menschen und gehören nicht in den Kontext | Die Asymmetrie zwischen den Packs bleibt: Beim einen geht die Zweckbeschreibung in die Regelauswahl ein, beim anderen nicht |
+| E3 | Prüfung 23 aufnehmen? | **Ja.** Sie ist billig, und sie trifft genau den Fehler, der hier unterlaufen ist | Eine Wortlistenprüfung meldet auch eine zutreffende Erwähnung im Kommentar – etwa einen Verweis auf eine Regel. Fehlalarme sind möglich |
+| E4 | K-28 vor der Umsetzung erheben? | **Nein, danach.** Die Abhilfe ist für beide Packs dieselbe und in beiden Fällen richtig | Bis zur Messung bleibt offen, ob das Pack `devin-desktop` überhaupt betroffen ist |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **angenommen** |
+| Datum | 2026-09-11 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | E1 bis E4 wie vorgelegt: Der normative Satz wandert in den **Fließtext** der Wurzel-Anweisungsdatei statt ersatzlos zu entfallen; die übrigen Kommentarinhalte (Ebene, Version, Owner, Ladeverhalten) bleiben als Auskunft an den Menschen; **Prüfung 23** meldet normative Schlüsselwörter in HTML-Kommentaren der Laufzeitartefakte; K-28 wird **nach** der Umsetzung erhoben. Ziel-Release 0.26.0 |
+| Umsetzung | **mit Release 0.26.0** – Einzelheiten und Nachweise in `leitwerk-core/CHANGELOG.md` |

package/.koolie/core/governance/change-requests/CR-2026-040-erh01-ist-clientgebunden.md

@@ -0,0 +1,115 @@
+# Änderungsantrag `CR-2026-040`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Der Kern schreibt einen Befund über **einen** Client als Aussage über **alle** – K-28 widerlegt ihn für das zweite Pack |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `framework/runtime/root-instruction.md` (Kopfkommentar), `tests/scripts/validate-framework.py` (Kopfkommentar und Meldungstext der Prüfung 23), `clients/devin-desktop/CLIENT_PACK.md` (Regelladung), `governance/DECISION_LOG.md` (K-28, D-38) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Laufzeitfassung der Wurzel-Anweisung und Validator |
+| Art | Befund aus der Erhebung vom 2026-09-12 (K-28); **keine AP2-Kennung** |
+| Dringlichkeit | regulär – die Maßnahme aus `CR-2026-039` bleibt in der Sache richtig; falsch ist ihre **Begründung** |
+
+## 1. Anlass und Problem
+
+`CR-2026-039` hat einen normativen Satz aus dem Kopfkommentar der Wurzel-Anweisungsdatei in den
+Fließtext gehoben, weil der Kommentar die Sitzung nicht erreicht (ERH-01). An seiner Stelle steht
+seither im Kommentar derselben Datei der Satz:
+
+```text
+Ein Kommentar erreicht die Sitzung nicht (ERH-01) - was gilt, steht im Fließtext, Abschnitt 2.
+```
+
+Dieselbe Aussage trägt der Validator an drei Stellen – im Kopfkommentar, in der Beschreibung der
+Prüfung 23 und in ihrem Meldungstext.
+
+**Der Satz ist für das zweite Pack falsch.** Am 2026-09-12 ist K-28 erhoben worden
+(`tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`, Abschnitt 2.1): Bei
+`devin-desktop` steht der Kommentar **wörtlich** im Regelblock, den der Client selbst bildet – die
+Mitschrift führt ihn samt Kommentarklammern, und die Sitzung gab die Marke aus dem Kommentar
+zurück, ohne eine Datei zu lesen (`"tool_calls": []`).
+
+### Warum das nicht bloß eine Ungenauigkeit ist
+
+`framework/runtime/root-instruction.md` und der Validator sind **Kernartefakte**. Sie sind
+werkzeugneutral – das ist der Sinn von D-15 und D-28. Ein Satz, der das Verhalten **eines**
+Clients zur allgemeinen Eigenschaft erklärt, ist dort dieselbe Konstruktion, die dieses Projekt
+seit Releases in Client Packs aufspürt: eine Aussage, die mehr behauptet, als gemessen ist. Dass
+sie diesmal in einem Kommentar steht, den bei `claude-code` niemand liest, macht es nicht besser –
+bei `devin-desktop` steht sie in jeder Sitzung im Kontext, und dort ist sie unzutreffend.
+
+### Was dadurch **nicht** falsch wird
+
+Die Maßnahme selbst trägt weiter, und zwar mit einer besseren Begründung als bisher:
+
+> Ein Kommentar in einem Kernartefakt erreicht die Sitzung **bei dem einen Client, beim anderen
+> nicht.** Genau deshalb ist er als Ablageort für einen normativen Satz untauglich: Was gilt,
+> darf nicht davon abhängen, mit welchem Werkzeug gearbeitet wird.
+
+Das ist stärker als die alte Begründung. Die alte sagte „erreicht die Sitzung nicht" und wäre mit
+einem Client, der Kommentare durchreicht, hinfällig. Die neue sagt „erreicht sie uneinheitlich"
+und wird durch genau diese Messung **bestätigt**.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Kopfkommentar der Wurzel-Anweisungsdatei.** Statt einer Behauptung über Clients ein Satz
+   über den Kern:
+
+   > `Was gilt, steht im Fließtext, Abschnitt 2 - ein Kommentar erreicht nicht jede Sitzung`
+   > `(ERH-01, K-28).`
+
+2. **Prüfung 23 im Validator.** Kopfkommentar und Meldungstext werden entsprechend gefasst: Die
+   Prüfung besteht, weil das Ladeverhalten von HTML-Kommentaren **clientabhängig** ist, nicht weil
+   Kommentare grundsätzlich verloren gingen. Die Prüfung selbst, ihre Wortliste und ihre Sonde
+   bleiben unverändert – es ändert sich kein Prüfergebnis.
+
+3. **`clients/devin-desktop/CLIENT_PACK.md`.** Der Abschnitt zur Regelladung erhält den gemessenen
+   Satz: Bei diesem Client geht der HTML-Kommentar einer Regeldatei **in den Kontext ein**.
+   Damit steht in beiden Packs, was für den jeweiligen Client gilt – das ist der Ort dafür, nicht
+   der Kern.
+
+4. **K-28 schließt** (`governance/DECISION_LOG.md`): beantwortet mit „nein", Beleg das Protokoll
+   vom 2026-09-12.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Prüfung 23 bleibt, wie sie ist.** Weder Wortliste noch Sonde noch Gegenprobe werden berührt;
+  kein Prüfergebnis ändert sich. Geändert wird ausschließlich die Begründung im Text.
+- **D-38 bleibt gültig.** Normative Aussagen gehören in den Fließtext. Die Entscheidung wird
+  bestätigt, nicht aufgehoben – nur ihre Begründung wird die belastbarere.
+- **Der Kommentar von `CR-2026-039` wird nicht zurückgenommen.** Der normative Satz bleibt im
+  Fließtext.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern, weil die falsche Aussage in einem Kernartefakt steht; die
+      clientgebundene Aussage wandert ins Pack.
+- [x] Verschärfungsprinzip: unberührt, es ändert sich keine Regel.
+- [x] Widerspruchsfreiheit: D-38, `CR-2026-039`, Prüfung 23, beide Packs gelesen.
+- [x] Laufzeitfassungen betroffen: ja, `framework/runtime/root-instruction.md`; beide Packs
+      erzeugen daraus, die Änderung erreicht beide über `install.py`.
+- [x] Belegstatus: gemessen, ein Lauf mit Positivkontrolle und Mitschrift.
+- [ ] Test- und Validierungsbedarf: Validatorlauf; **keine** neue Prüfung, **keine** neue Sonde –
+      Prüfung 23 bleibt unverändert.
+- [x] Overlays: nicht betroffen.
+- [ ] Dokumentation: CHANGELOG, Decision Log (K-28, D-38 fortgeschrieben).
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Den Satz im Kern korrigieren oder streichen? | **Korrigieren.** Ein Hinweis, warum der Fließtext der Ort ist, gehört an die Stelle, an der jemand den Kommentar erweitern will. Gestrichen wäre die Falle wieder unmarkiert | Der Kommentar der Wurzel-Anweisungsdatei bleibt eine Zeile lang – in der Datei, für die das Framework Least Context fordert |
+| E2 | Prüfung 23 im Zuschnitt ändern? | **Nein.** Sie trifft weiterhin genau den Fehler, und ihre Berechtigung wird durch K-28 eher größer: Was bei einem Client verschwindet und beim anderen mitläuft, ist als Ablageort erst recht untauglich | Die Prüfung bleibt eine Wortlistenprüfung mit den bekannten Fehlalarmen (`CR-2026-039` E3) |
+| E3 | Den gemessenen Satz ins Pack `devin-desktop` aufnehmen? | **Ja.** Er ist für die Regelladung dieses Clients erheblich und steht sonst nirgends: Wer dort einen Kommentar schreibt, schreibt in den Sitzungskontext | Eine weitere Zeile im Pack; die Asymmetrie zwischen den Packs wird sichtbar statt stillschweigend |
+| E4 | Die strengere Lesart für `devin-desktop` beibehalten? | **Ja, aber neu begründet.** Nicht mehr „vorsorglich, weil unerhoben", sondern „weil das Verhalten clientabhängig ist". Aus einer Annahme wird ein Grund | Keiner in der Sache. Der Preis ist redaktionell: Zwei Stellen tragen künftig unterschiedliche Begründungen für dieselbe Regel |
+| E5 | Auch den `claude-code`-Abschnitt zu K-18 anfassen? | **Nein.** Er beschreibt korrekt das Verhalten **seines** Clients und ist durch ERH-01 gedeckt | Die Formulierung „zählt hier vorsorglich zum ständigen Kontext" bleibt stehen, obwohl ERH-01 sie erübrigt – ein eigener, kleinerer Befund für eine spätere Durchsicht |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle fünf Fragen wie vorgelegt.** E1 korrigieren statt streichen; E2 Prüfung 23 im Zuschnitt unverändert; E3 der gemessene Satz kommt in das Pack `devin-desktop`; E4 die strengere Lesart bleibt, neu begründet; E5 der `claude-code`-Abschnitt zu K-18 bleibt unberührt |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **Kein Prüfergebnis darf sich ändern.** Nachgewiesen: Validator vor und nach der Änderung 0 Fehler, 0 Warnungen; Sonde und Gegenprobe zu Prüfung 23 unverändert bestanden. Die Sonde zu Prüfung 23 hat dabei ihren Suchtext verloren und musste nachgezogen werden – der Vorfall steht in D-43 |
+| Umsetzung | umgesetzt mit `0.27.0` |

package/.koolie/core/governance/change-requests/CR-2026-041-s5-nicht-abbildbar.md

@@ -0,0 +1,128 @@
+# Änderungsantrag `CR-2026-041`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | S5 ist bei `claude-code` `[NICHT ABBILDBAR]` – und die Folge, die `clients/README.md` daran knüpft, ist nicht gemeint |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `clients/README.md` (Abschnitt 4, verbindliche Folgen), `clients/claude-code/CLIENT_PACK.md` (S5), `clients/devin-desktop/CLIENT_PACK.md` (S5), `clients/_template/CLIENT_PACK.md`, `governance/DECISION_LOG.md` |
+| Ebene laut Entscheidungsbaum 6 | Kern – Bedeutung und Rechtsfolge einer Einstufungsklasse; betrifft **beide** Client Packs |
+| Art | Befund aus der Erhebung vom 2026-09-12 (S5); Präzisierung der Folgen von `[NICHT ABBILDBAR]` |
+| Dringlichkeit | regulär – aber vor dem nächsten Onboarding zu entscheiden, weil die Folge eine Inbetriebnahme blockiert |
+
+## 1. Anlass und Problem
+
+Die Erhebung vom 2026-09-12 hat S5 für `claude-code` beantwortet
+(`tests/protocols/2026-09-12-erhebungen-K28-S5-B9-bypass.md`, Abschnitt 2.2). Das Ergebnis ist
+zweigeteilt:
+
+- **Gut:** Fremde Skill-Ablagen führt dieser Client nicht mit. Vier Sonden in vier fremden
+  Ablagen blieben ungeführt, die fünfte in der eigenen Ablage wurde geführt.
+- **Nicht gut:** Die Zusage der Zeile selbst – *vollständig aufzählbar, samt Herkunft und
+  Aufrufbarkeit* – ist nicht eingelöst. Es gibt **kein Aufzählungskommando**: `claude --help`
+  kennt keinen Unterbefehl für Skills, `claude doctor` nennt keine Skill-Pfade, und die Sitzung
+  erhält Skills als Name und Kurzbeschreibung ohne Pfad. Sie antwortete auf die Frage nach der
+  Herkunft wörtlich „Herkunft unbekannt — für alle 84".
+
+Die Zeile trägt deshalb seit dieser Messung `[NICHT ABBILDBAR]`. Das ist die zutreffende
+Einstufung: *„Der Client bietet keinen Mechanismus."*
+
+### Die Folge, die daran hängt
+
+`clients/README.md` Abschnitt 4 knüpft daran eine verbindliche Folge:
+
+> Ein Client Pack, das eine **Kernzusage** auf `[NICHT ABBILDBAR]` setzt, DARF nicht ohne Freigabe
+> durch `<SECURITY_CONTACT>` in Betrieb genommen werden.
+
+**Der Begriff „Kernzusage" ist nirgends definiert.** Die Spaltenüberschrift der Matrix heißt
+„Zusage des Frameworks"; der B-Block führt eine eigene Spalte „Kern" mit `ja`/`–`; der erste
+Aufzählungspunkt desselben Abschnitts spricht enger von „einer Kernzusage **aus
+`_core_rules_integrity`**". Ob S5 darunter fällt, lässt sich dem Text nicht entnehmen.
+
+Das ist keine Spitzfindigkeit, sondern entscheidet zwei Dinge auf einmal:
+
+1. Ob das Pack `claude-code` ab sofort eine Freigabe von `<SECURITY_CONTACT>` braucht.
+2. Ob D-27 noch gilt. Die Roadmap führt als Ergebnis: *„keine Einstufung des Packs steht mehr auf
+   `[NICHT ABBILDBAR]`."* Seit dieser Messung steht wieder eine dort.
+
+### Warum die Sperrklausel hier vermutlich nicht gemeint war
+
+Sie steht zwischen zwei Sätzen, die beide von **Sicherheitszusagen** handeln – der erste nennt
+`_core_rules_integrity` ausdrücklich, der dritte verlangt für `[TECHNISCH]` einen Beleg gegen eine
+reale Installation. S5 ist keine Sicherheitszusage, sondern eine **Transparenzzusage**: Sie sagt
+nicht zu, dass etwas verhindert wird, sondern dass man nachsehen kann. Ihr Ausfall ist ernst –
+aber er sperrt keine Schranke auf.
+
+**Die Gegenprobe fällt allerdings unangenehm aus.** Gerade weil ein Skill Verfahren in die Sitzung
+bringt, die niemand im Projekt gelesen hat (`AP2-DD-16`, K-24), ist Aufzählbarkeit das einzige
+Mittel, das überhaupt bemerkt. Wer die Sperrklausel hier abräumt, sollte den Verlust ersetzen und
+nicht bloß abbuchen – siehe E3.
+
+## 2. Vorgeschlagene Änderung
+
+1. **`clients/README.md` Abschnitt 4 definiert „Kernzusage".** Formulierungsvorschlag:
+
+   > **Kernzusage** im Sinne dieses Abschnitts ist jede Zeile des B-Blocks mit `Kern = ja` sowie
+   > jede Regel aus `_core_rules_integrity` der Berechtigungsdatei. Zusagen der übrigen Blöcke
+   > sind Fähigkeitszusagen: Ihr Ausfall wird im Pack begründet und im Overlay des aufnehmenden
+   > Projekts als bekannte Einschränkung geführt, sperrt die Inbetriebnahme aber nicht.
+
+2. **S5 wird im Pack als das ausgewiesen, was fehlt** – nicht nur als Klasse. Die Zeile trägt
+   bereits den Messbefund; ergänzt wird der Hinweis auf den Ersatz nach E3.
+
+3. **Ersatz durch das Framework statt durch den Client (E3).** Die Installation kennt jeden Skill,
+   den sie schreibt, und der Validator liest die Ablage ohnehin. Vorgeschlagen wird ein
+   Aufzählungsschalter des Frameworks – `install.py --list-skills` –, der je Skill Name, Pfad,
+   Herkunft (Kern, Overlay, Projekt) und Aufrufbarkeit (`disable-model-invocation`) ausgibt.
+   **Das ersetzt nicht, was der Client verschweigt** – Skills aus Ablagen außerhalb des
+   Repositoriums sieht auch das Framework nicht –, aber es macht den Teil aufzählbar, für den das
+   Framework einstehen kann.
+
+4. **Die Zeile S5 des Packs `devin-desktop` wird nachgezogen.** Dort steht `[TEXTUELL]` mit dem
+   Vorbehalt aus ERH-03 (die Pfadauskunft nennt die größte Ablage nicht). ERH-17 setzt daneben
+   einen zweiten Befund: Der Block `<available_skills>` **nennt** je Skill den vollen Quellpfad –
+   die Auskunft existiert, nur nicht in dem Kommando, das sie verspricht. Beides gehört in die
+   Zeile.
+
+5. **D-27 und die Roadmap** werden fortgeschrieben: Der Satz „keine Einstufung steht mehr auf
+   `[NICHT ABBILDBAR]`" beschreibt einen Stand, der seit dem 2026-09-12 nicht mehr gilt.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Die Einstufung selbst.** `[NICHT ABBILDBAR]` ist gemessen und steht nicht zur Disposition.
+  Zur Entscheidung steht allein, welche Folge das Regelwerk daran knüpft.
+- **Die Definition der drei Klassen.** Abschnitt 4 behält seine Tabelle unverändert.
+- **S4.** Die Zusage über benutzergetriggerte Skills ist am selben Tag an ihrer Wirkung belegt
+  worden (ERH-13) und wird hier nicht berührt.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern – die Klausel steht in `clients/README.md` und gilt für jedes Pack.
+- [x] Verschärfungsprinzip: Die vorgeschlagene Definition **lockert** eine Klausel. Sie ist
+      deshalb ausdrücklich als Ermessensfrage vorgelegt (E1) und nicht als Redaktion.
+- [x] Widerspruchsfreiheit: D-27, `CR-2026-017`, `CR-2026-032`, D-34 gelesen.
+- [ ] Laufzeitfassungen betroffen: nur bei Annahme von E3 (`install.py`).
+- [x] Belegstatus: gemessen, ein Lauf mit Positivkontrolle und vier Negativsonden.
+- [ ] Test- und Validierungsbedarf: bei Annahme von E3 eine Prüfung samt Sonde nach D-23.
+- [x] Overlays: Bei Annahme von E1 führt das aufnehmende Projekt S5 als bekannte Einschränkung.
+- [ ] Dokumentation: CHANGELOG, Decision Log, ROADMAP (Stand zu D-27).
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | Sperrt `[NICHT ABBILDBAR]` bei S5 die Inbetriebnahme? | **Nein – und der Begriff „Kernzusage" wird definiert, statt im Einzelfall ausgelegt zu werden.** Eine Transparenzzusage ist keine Schranke; die Klausel war für Sicherheitszusagen gedacht | Eine Klausel wird gelockert, und zwar in dem Augenblick, in dem sie das erste Mal greifen würde. Das ist der unangenehmste denkbare Zeitpunkt für eine Lockerung – und genau deshalb gehört die Frage vorgelegt und nicht redaktionell entschieden |
+| E2 | Die Definition im Kern oder je Pack? | **Im Kern** (`clients/README.md`). Eine Rechtsfolge, die für jedes Pack gilt, darf nicht je Pack ausgelegt werden | Der Kern wächst um eine Definition. Wer ein neues Pack schreibt, muss sie kennen |
+| E3 | Den Ausfall durch das Framework ersetzen? | **Ja, `install.py --list-skills`.** Aufzählbarkeit ist das einzige Mittel, das einen unbemerkten Skill überhaupt bemerkt; sie ganz aufzugeben, wäre die schlechtere Lage | Ein neuer Schalter, eine neue Prüfung, eine neue Sonde. Und eine Teilauskunft, die mehr verspricht, als sie leistet, wenn niemand dazusagt, dass fremde Ablagen darin fehlen – genau der Befundtyp dieses Projekts. Der Satz muss in die Ausgabe, nicht nur in die Dokumentation |
+| E4 | S5 bei `devin-desktop` nachziehen? | **Ja.** ERH-17 ist dort ein eigener Befund: Die Herkunft steht im Sitzungskontext, das Kommando gibt sie nicht. Das gehört neben ERH-03 in dieselbe Zeile | Die Zeile wird lang. Sie trägt dann drei Belege für dieselbe Zusage, zwei davon einschränkend |
+| E5 | D-27 als überholt kennzeichnen? | **Fortschreiben, nicht aufheben.** Der Satz war zum Zeitpunkt der Entscheidung richtig; er beschreibt einen Stand, keinen Beschluss | Die Roadmap-Tabelle trägt eine Einschränkung in einer Zeile, die bisher als Erfolg gelesen wurde |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle fünf Fragen wie vorgelegt.** E1 `[NICHT ABBILDBAR]` bei S5 sperrt die Inbetriebnahme **nicht**; der Begriff „Kernzusage" wird definiert statt im Einzelfall ausgelegt. E2 die Definition steht im Kern. E3 der Ausfall wird ersetzt: `install.py --list-skills`. E4 S5 bei `devin-desktop` wird um ERH-17 nachgezogen. E5 D-27 wird fortgeschrieben, nicht aufgehoben |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | **Die Lockerung gilt nur zusammen mit dem Ersatz.** Eine Fähigkeitszusage auf `[NICHT ABBILDBAR]` MUSS den Ersatz benennen oder festhalten, dass es keinen gibt; **Prüfung 25** setzt das durch und ist nach D-23 mit Sonde und Gegenprobe belegt. Beim ersten Lauf meldete sie **zwei** Zeilen ohne benannten Ersatz (S5 und X2) – die Lücke, gegen die sie gebaut ist, war bereits da. Die Ausgabe von `--list-skills` MUSS ihre eigene Grenze nennen; auch das ist als Sonde belegt |
+| Umsetzung | umgesetzt mit `0.27.0` |

package/.koolie/core/governance/change-requests/CR-2026-042-abwesenheitsnachweis-suchwerkzeug.md

@@ -0,0 +1,102 @@
+# Änderungsantrag `CR-2026-042`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Ein Abwesenheitsnachweis über das Suchwerkzeug ist für Punktdateien keiner |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-12 |
+| Betroffene Artefakte | `tests/TEST_CATALOG.md` (Verfahren Nummer 7), `tests/protocols/README.md`, `clients/claude-code/CLIENT_PACK.md` (Werkzeugblock) |
+| Ebene laut Entscheidungsbaum 6 | Kern – Nachweisverfahren |
+| Art | Befund aus der Erhebung vom 2026-09-12 (ERH-12); **keine AP2-Kennung** |
+| Dringlichkeit | regulär – aber vor dem nächsten Abwesenheitsnachweis zu entscheiden |
+
+## 1. Anlass und Problem
+
+Nummer 7 des Testkatalogs verlangt seit `CR-2026-034`, dass ein Nachweis aus dem **Ausbleiben**
+einer Wirkung den Lauf selbst belegt – durch Ausgabe, Aufzeichnung oder eine Positivkontrolle im
+selben Lauf. Die Regel richtet sich gegen den stillen Abbruch (`AP2-DD-13`, ERH-05): ein Lauf,
+der mit Exit 0 endet und nichts getan hat.
+
+**Am 2026-09-12 ist eine zweite Bauart desselben Fehlers aufgetreten, gegen die Nummer 7 nicht
+schützt.** Im ersten B9-Lauf berichtete die Sitzung, die Messdatei `.env` existiere nicht, und
+belegte das mit zwei Suchläufen:
+
+| Befehl | Ergebnis |
+|---|---|
+| `Glob .env*` | `No files found` |
+| `Glob **/.env*` | `No files found` |
+
+**Die Datei lag im Verzeichnis.** Sie war im selben Lauf über einen anderen Weg lesbar; ihr Inhalt
+steht in drei späteren Läufen desselben Protokolls im Ergebnis. Das Suchwerkzeug dieses Clients
+führt Punktdateien nicht auf.
+
+### Warum Nummer 7 das nicht abfängt
+
+Der Lauf hatte alles, was Nummer 7 verlangt: eine Ausgabe, eine Positivkontrolle, die gelang, und
+ein Werkzeug, das ordnungsgemäß antwortete. Es fehlte keine Wirkung – **das Werkzeug hat
+gearbeitet und ein falsches Ergebnis geliefert.** Eine Positivkontrolle an einer anderen Datei
+hätte den Fehler nicht gezeigt, denn sie trifft eine Datei ohne führenden Punkt.
+
+Der Lauf wäre als sauberer Abwesenheitsnachweis durchgegangen: „gesucht, zweifach, nichts
+gefunden". Er hätte in ein Protokoll gehen und dort die Annahme tragen können, eine geprüfte Datei
+sei nicht vorhanden. Gemerkt hat es nur, wer wusste, dass er die Datei selbst angelegt hatte.
+
+## 2. Vorgeschlagene Änderung
+
+1. **Nummer 7 des Testkatalogs erhält einen zweiten Absatz.** Formulierungsvorschlag:
+
+   > **Ein Werkzeugergebnis ist kein Abwesenheitsnachweis.** Wo der Nachweis lautet „die Datei,
+   > der Eintrag, die Marke ist nicht da", MUSS die Abwesenheit mit einem Mittel geprüft werden,
+   > dessen Trefferbild für den geprüften Gegenstand belegt ist – und die Prüfung MUSS eine
+   > **Anwesenheitsprobe desselben Gegenstandstyps** enthalten. Für Punktdateien ist das
+   > Suchwerkzeug mindestens eines Clients ungeeignet: Es meldet `No files found` für eine
+   > vorhandene Datei (ERH-12).
+
+2. **`tests/protocols/README.md`** nimmt die Bauart in die Zeile zu Nummer 7 auf: Neben dem
+   „Beleg des Laufs selbst" steht künftig „und, bei einem Abwesenheitsnachweis über ein
+   Suchwerkzeug, eine Anwesenheitsprobe desselben Gegenstandstyps".
+
+3. **`clients/claude-code/CLIENT_PACK.md`** hält den Befund beim Werkzeug fest, wo er hingehört:
+   Das Suchwerkzeug dieses Clients führt Punktdateien nicht auf; gemessen mit zwei Mustern gegen
+   eine vorhandene Datei.
+
+## 3. Was dieser Antrag nicht ändert
+
+- **Nummer 7 bleibt in Kraft.** Der Absatz ergänzt sie, er ersetzt nichts. Die Positivkontrolle
+  im selben Lauf bleibt Pflicht.
+- **Keine Prüfung im Validator.** Der Befund betrifft ein Verfahren für Menschen und Sitzungen,
+  nicht ein Artefakt im Repositorium. Eine Prüfung hätte nichts zu lesen.
+- **Die bisherigen Protokolle werden nicht neu bewertet.** Ob eines von ihnen einen
+  Abwesenheitsnachweis über ein Suchwerkzeug führt, ist offen – die Durchsicht der Altprotokolle
+  nach `CR-2026-034` E4 steht ohnehin aus und bekommt mit diesem Antrag ein zweites Kriterium.
+
+## 4. Prüffragen
+
+- [x] Richtige Ebene: Kern – Nummer 7 ist ein Verfahren des Testkatalogs.
+- [x] Verschärfungsprinzip: Der Absatz verschärft; er lockert nichts.
+- [x] Widerspruchsfreiheit: `CR-2026-034`, Nummer 7, ERH-05 gelesen.
+- [x] Laufzeitfassungen: nicht betroffen.
+- [x] Belegstatus: gemessen, zwei Muster gegen eine nachweislich vorhandene Datei.
+- [x] Test- und Validierungsbedarf: keiner – keine neue Prüfung, keine Sonde.
+- [x] Overlays: nicht betroffen.
+- [ ] Dokumentation: CHANGELOG, und die Durchsicht nach `CR-2026-034` E4 erhält ein zweites
+      Kriterium.
+
+## 5. Vorlage zur Entscheidung
+
+| Nr. | Frage | Auflösung | Preis |
+|---|---|---|---|
+| E1 | In den Testkatalog oder nur ins Client Pack? | **In beide, mit verschiedener Reichweite.** Ins Pack der gemessene Werkzeugbefund, in den Katalog die Verfahrensregel: Der Fehler ist nicht an dieses eine Werkzeug gebunden, sondern an die Bauart „Abwesenheit durch Suchen belegen" | Nummer 7 wächst. Sie war ein Absatz und wird zwei – eine Verfahrensvorschrift, die niemand liest, nützt nichts |
+| E2 | Anwesenheitsprobe desselben Gegenstandstyps verlangen? | **Ja.** Genau das hätte den Fehler gezeigt: eine zweite Punktdatei, die gefunden werden **muss**. Eine Positivkontrolle an einer gewöhnlichen Datei genügt nicht | Jeder Abwesenheitsnachweis wird um einen Handgriff teurer. Bei einem Verfahren, das ohnehin schon Positivkontrolle und Mitschrift verlangt, ist das spürbar |
+| E3 | Eine Prüfung im Validator? | **Nein.** Es gibt nichts zu lesen: Der Befund betrifft, wie gemessen wird, nicht was im Repositorium steht | Die Regel bleibt auf Disziplin angewiesen. Das ist die schwächste Durchsetzungsform, die dieses Projekt kennt – und für ein Verfahren die einzige mögliche |
+| E4 | Die Altprotokolle daraufhin durchsehen? | **Ja, im selben Zug wie `CR-2026-034` E4.** Zwei Kriterien in einem Durchgang statt zweier Durchgänge | Die ohnehin ausstehende Durchsicht wird aufwendiger und rückt damit weiter nach hinten |
+
+## 6. Entscheidung
+
+| Feld | Inhalt |
+|---|---|
+| Entscheidung | **Angenommen, alle vier Fragen wie vorgelegt.** E1 in Testkatalog **und** Client Pack, mit verschiedener Reichweite; E2 die Anwesenheitsprobe desselben Gegenstandstyps wird verlangt; E3 keine Validatorprüfung – es gibt nichts zu lesen; E4 die Altprotokolle werden im selben Zug wie `CR-2026-034` E4 durchgesehen |
+| Datum | 2026-09-12 |
+| Entscheidende Rolle | `<FRAMEWORK_OWNER>` |
+| Auflagen | Die Durchsicht der Altprotokolle nach `CR-2026-034` E4 führt künftig **zwei** Kriterien und steht weiterhin aus. Im Wirkungsnachweis selbst ist die Regel bereits angewandt: `probe-pruefungen.py` prüft seit 0.27.0 vor jedem Sondenlauf, ob die Sonde den Baum überhaupt verändert hat |
+| Umsetzung | umgesetzt mit `0.27.0` |