@renoxar/koolie 1.25.0

package/.koolie/core/governance/change-requests/CR-2026-098-anforderungen-auslieferung.md

@@ -0,0 +1,93 @@
+# Änderungsantrag `CR-2026-098`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Zwei Anforderungen an die Auslieferung – die Installationsbibliothek und das frameworkeigene Unterverzeichnis |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-19 |
+| Betroffene Artefakte | `docs/ROADMAP.md` (neuer Posten `1.3.0`, Posten der Umbenennung erweitert), `governance/DECISION_LOG.md` (`K-50` erweitert, `K-75` neu), `CHANGELOG.md`, `VERSION` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Gegenstand ist der Releaseplan |
+| Art | Planänderung, keine Messung, kein Kontingent |
+| Dringlichkeit | **Regulär, mit einer Frist:** Anforderung 2 gehört in die Umbenennung (`~0.68.0`) und wird danach teurer, nicht billiger |
+
+## 1. Anlass
+
+Der Mensch hat am 2026-09-19 zwei Anforderungen an die **Auslieferung** gestellt. Beide
+betreffen nicht, was das Framework sagt, sondern **wie es in ein Zielprojekt kommt** –
+und dafür gab es bisher genau einen Weg: das Repositorium kopieren und von dort
+installieren.
+
+## 2. Anforderung 1 – die Installationsbibliothek (neuer Posten `1.3.0`)
+
+**Wortlaut sinngemäß:** Ein Zielprojekt soll das Framework nicht mehr nur als Kopie des
+ganzen Repositoriums bekommen – mit Tests, Änderungsanträgen und Protokollen – und von
+dort aus installieren. Der Weg soll **bleiben**; daneben soll es eine
+**Installationsbibliothek** geben: Der Mensch nennt Projektpfad, Client und Overlay, und
+der Installer legt an beziehungsweise hebt. Zusätzlich soll der **Lieferumfang wählbar**
+sein: alles, oder nur das zur Nutzung Nötige.
+
+**Warum das ein eigener Posten ist:** Drei Dinge des heutigen Aufbaus hängen daran, und
+alle drei sind belegt, nicht vermutet.
+
+| # | Was daran hängt | Beleg |
+|---|---|---|
+| 1 | **Der Kern liegt im Zielprojekt und wird von dort ausgeführt.** Die Hook-Kommandos der erzeugten Berechtigungsdatei zeigen auf `leitwerk-core/…` im Zielprojekt | Abschnitt 6 der Übergabe: ohne `cp -r leitwerk-core <root>/` zeigen sie ins Leere |
+| 2 | **Das Heben ersetzt das Verzeichnis, nicht einzelne Dateien** (`rm -rf` + `git archive` + `--update`) | der Zehn-Minuten-Ablauf |
+| 3 | **Mehrere Prüfungen laufen gegen den Kern im Zielprojekt** (45, 59) und `--strict-overlay` ist die Abnahme jeder Übernahme | `CR-2026-090`, D-171 |
+
+**Wo der Posten hingehört: nach `1.2.0`.** Er ändert den **Übernahmeweg**, und der muß
+gegen den dann geltenden Bestand gebaut werden – also nach der Umbenennung, nach `AP11`,
+nach `1.0.0` und nach den beiden Erweiterungen, die **neue Träger mit Pfaden** anlegen
+(Client Pack `openai-codex` in `1.1.0`, Overlay-Muster in `1.2.0`). Ein Mindestpaket, das
+davor geschnitten wird, schneidet an einem Bestand, den es danach nicht mehr gibt.
+
+## 3. Anforderung 2 – das frameworkeigene Unterverzeichnis (zur Umbenennung)
+
+**Wortlaut sinngemäß:** `koolie-core/` und `project-overlay/` sollen im Zielprojekt nicht
+im Wurzelverzeichnis liegen, sondern in einem frameworkspezifischen Unterverzeichnis,
+vorgeschlagen `.koolie/`.
+
+**Einzuordnen bei `~0.68.0`, nicht als eigener Posten.** D-127 verschiebt ohnehin
+`leitwerk-core/` nach `koolie-core/` und ändert den Wert von `<CORE_DIR>`. Beides zweimal
+zu tun hieße, jede Fundstelle zweimal anzufassen und jedes übernehmende Projekt zweimal
+zu heben.
+
+🔴 **Und es beantwortet `K-50` faktisch mit ja:** Ein Umzug ist kein Update. `install.py
+--update` schreibt an den alten Ort; ohne einen Migrationspfad bleibt in jedem
+übernehmenden Projekt der alte Baum stehen.
+
+## 4. `K-75` – die offenen Entscheidungen
+
+Sie gehören in den Antrag, der die Arbeit auslöst, nicht in den Plan:
+
+| # | Frage |
+|---|---|
+| 1 | **Punkt oder kein Punkt?** Die Anforderung nennt beides. Ein Punkt-Verzeichnis ist voreingestellt unsichtbar – für eine **Regelablage, die ein Mensch lesen soll**, ist das eine Entscheidung, keine Schreibweise. Der Bestand kennt beides: `.claude/`, `.devin/` mit Punkt, `project-overlay/` ohne |
+| 2 | **`core/` oder `koolie-core/` darunter?** `.koolie/koolie-core/` doppelt den Namen; `.koolie/core/` ist kürzer, aber ein herausgelöster Pfad `core/…` sagt nicht mehr, wem er gehört – und genau das war der Gegenstand der Clientneutralität (Prüfung 48) |
+| 3 | **Was ist das Mindestpaket?** Eine Datei, die ein Skill **mit Pfad** zitiert, kann nicht weggelassen werden, ohne den Verweis ins Leere zeigen zu lassen – **D-193 an einer neuen Stelle** |
+| 4 | **Womit prüft ein Projekt mit reduziertem Umfang seine Übernahme?** `validate-framework.py` liegt unter `tests/`, und `tests/` wäre das erste, was ein Mindestpaket wegläßt |
+| 5 | **Woher weiß der Installer beim Heben, welche Dateien dem Projekt gehören**, wenn die Quelle nicht mehr im Zielprojekt liegt? |
+| 6 | **Wo steht dann die Herkunftsangabe?** Heute in `leitwerk-core/VERSION` im Ziel; ohne sie kann weder Validator noch Mensch sagen, welcher Stand installiert ist |
+| 7 | **Vertriebsweg:** Python-Paket, Git-Bezug oder Archiv? Eine Annahme über die vorhandene Werkzeugkette wäre eine Annahme (P3) |
+
+## 5. Vorlage zur Entscheidung
+
+| # | Frage | Auflösung | Preis |
+|---|---|---|---|
+| **E1** | **Ersetzt die Installationsbibliothek den heutigen Weg?** | **Nein – sie tritt daneben** | Zwei Wege sind zu pflegen und zu prüfen. **Der Gegenpreis wäre größer:** Der heutige Weg ist der einzige, der heute belegt funktioniert, und beide übernehmenden Projekte stehen auf ihm |
+| **E2** | **Eigener Posten oder Teil von `1.2.0`?** | **Eigener Posten `1.3.0`, nach `1.2.0`** | Eine Nummer mehr. **Begründet, nicht bequem:** Der Posten ändert den Übernahmeweg, und `1.1.0` und `1.2.0` legen **neue Träger mit Pfaden** an – ein Mindestpaket, das davor geschnitten wird, schneidet an einem Bestand, den es danach nicht mehr gibt |
+| **E3** | **Wird das Unterverzeichnis ein eigener Posten oder Teil der Umbenennung?** | **Teil der Umbenennung (`~0.68.0`)** | Der Umbenennungsposten wird größer. **Der Gegenpreis ist die doppelte Arbeit:** D-127 verschiebt das Kernverzeichnis ohnehin und ändert `<CORE_DIR>`; wer beides trennt, faßt jede Fundstelle zweimal an und hebt jedes übernehmende Projekt zweimal |
+| **E4** | **Werden die sieben offenen Fragen hier entschieden?** | **Nein – `K-75`** | Ein Klärungspunkt mehr. **Der Grund ist die Trennlinie dieses Projekts:** Der Plan sagt, **was** und **wann**; die Ermessensfragen gehören einzeln vorgelegt, mit Auflösung **und Preis**, in den Antrag, der die Arbeit auslöst |
+| **E5** | **Wird in diesem Release etwas gebaut?** | **Nein – Planänderung ohne Kontingent** | Ein Einschub mehr. **Kriterium 2 bewegt sich nicht**, und das ist richtig so: Eine Anforderung aufzuschreiben ist keine Messung |
+
+## 6. Entscheidung
+
+**E1 bis E5 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-19). Kein neuer
+Decision Record – der Plan trägt die Festlegung, `K-75` die offenen Fragen.
+
+## 7. Abnahme
+
+- `validate-framework.py`: **0 Fehler, 0 Warnungen** gegen den fertigen Baum.
+- `probe-pruefungen.py` in **beiden** Kodierungsumgebungen (D-49), voller Lauf.
+- 🔴 **Prüfung 53 ist der Wirkungsnachweis dieses Antrags:** Sie rechnet die Kette der
+  Releaseplan-Posten nach, und dieser Antrag fügt eine Nummer hinzu.

package/.koolie/core/governance/change-requests/CR-2026-099-k74-und-vorbedingungen-buendel-3.md

@@ -0,0 +1,119 @@
+# Änderungsantrag `CR-2026-099`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | `K-74` entschieden und die Vorbedingungen von Bündel 3 – die Marke, die keine Ausgabemarke ist, und die Vorbedingung aus einem fremden Strang |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-19 |
+| Betroffene Artefakte | zehn `framework/skills/*/TESTS.md` (18 Markennennungen, drei Vorbedingungen, zwei Ergebnisvermerke), `docs/RUNTIME_GLOSSARY.md` (neuer Abschnitt, Version `0.3.0` → `0.4.0`), `tests/TEST_CATALOG.md` (Punkt 4, Nachweisspanne), `onboarding/exercises/README.md` (`UEB-18` bis `UEB-20`), `tests/scripts/validate-framework.py` (**Prüfung 64**), `tests/scripts/probe-pruefungen.py` (vier Sonden, drei Gegenproben), `governance/DECISION_LOG.md` (**D-197**, **D-198**, `K-74` erledigt), `docs/ROADMAP.md`, `tests/protocols/2026-09-19-vorbedingungen-buendel-3.md` (neu), `CHANGELOG.md`, `VERSION`; **außerhalb des Repositoriums:** das Übungsrepositorium (`UEB-18` bis `UEB-20`, Mentorenblatt) |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Gegenstand sind Testblätter, Laufzeitglossar und Prüfapparat |
+| Art | Herrichtung vor einem Meßtag, **keine Messung, kein Kontingent** |
+| Dringlichkeit | **Regulär, mit einer Frist:** Beides gehört **vor** Bündel 3 – `K-74` laut Decision Log, die Vorbedingungen nach fünfzehn Durchgängen Erfahrung |
+
+## 1. Anlass
+
+Zwei Dinge stehen vor dem Meßtag von Bündel 3, und beide sind im Vorfeld benannt worden:
+`K-74` (die Ausgabemarken) und der Vorbedingungsdurchgang. **Beide haben mehr gefunden,
+als ihr Auftrag erwarten ließ.**
+
+## 2. `K-74` – die Frage, die die Zählung nicht gestellt hatte
+
+`K-74` hat am 2026-09-19 gezählt: `[HALT]` und `[RÜCKFRAGE]` stehen mit 145 Fundstellen in
+54 anweisenden Trägern im Kern und sind in keinem Kernmodul und keinem Glossar erklärt.
+Die Vorlage nannte zwei Auflösungen – die Marken erklären oder die Zellen auf die Form
+abstellen.
+
+🔴 **Die entscheidende Frage war eine dritte, und sie stand in keiner Fassung des
+Klärungspunkts: In WELCHEM Abschnitt steht die Marke?** Ausgezählt über die zwölf Skills:
+
+| Marke | Abschnitt 5 (Ausgabeformat) | Abschnitt 6 (Qualitätskriterien) | Abschnitt 2, 3, 7 |
+|---|---|---|---|
+| `[HALT]` | 3 – **nur** `fw-plan`, `fw-bugfix-prepare`, `fw-change-small` | 3 – dieselben drei | 42 |
+| `[RÜCKFRAGE]` | **0** | **0** | 43 |
+
+🔴 **`[RÜCKFRAGE]` ist gar keine Ausgabemarke.** Sie ist durchgehend **Handlungsmarke**:
+`| Kontrollstufe nicht angegeben \| [RÜCKFRAGE] |` heißt *frage zurück*, nicht *schreibe
+die Zeichenfolge*. **`[HALT]` ist beides, je nach Skill** – und wo sie Abnahmekriterium
+ist, sagt Abschnitt 6 *„ist **erkennbar**"*, nicht *„wörtlich"*.
+
+🔴 **Ein gemessener Lauf hatte es vorgeführt, bevor es benannt war.** `sk004n01` (Bündel 2)
+schrieb `[HALT]` – Abschnitt 6 von `fw-plan` verlangt es – und `[RÜCKFRAGE]` **nicht**,
+obwohl er zurückfragte, und zwar genau in der verlangten Form. **Der Lauf hatte in beidem
+recht; die Zelle verlangte trotzdem beides.**
+
+**Gemessen über alle dreizehn Blätter: 18 Nennungen in 17 Zellen sind ungedeckt**, zehn
+gedeckt. In Bündel 3 sind **9 von 13** ungedeckt – alle **sechs** Nennungen von `fw-refactor`
+(fünf Zellen, `SK-007-N04` nennt beide Marken), beide von `fw-tests` und eine von
+`fw-change-small`.
+
+⚠️ **Und die Zählung von `K-74` war wieder zu klein.** Nachgezählt gegen den Kern,
+Aufzeichnungen ausgenommen (D-141): `[HALT]` **101** statt 92 Fundstellen, `[RÜCKFRAGE]`
+**54** statt 52 ohne die ASCII-Form. **Wer hier eine Zahl liest, zählt sie nach – auch die
+eigene.**
+
+## 3. Die achtzehn Vorbedingungen – fünfzehn tragen, drei nicht
+
+**Zum fünfzehnten Mal in Folge der billigste Befund des Releases**, und alle drei Befunde
+fielen **vor** dem ersten Lauf an.
+
+| Zelle | Was fehlte | Abhilfe |
+|---|---|---|
+| `SK-005-P02` | Ein **bestätigter Plan**, der eine Datei nennt, während der Ist-Zustand eine zweite erfordert. **Ein Plan ist ein Artefakt eines LAUFS** – die fünfte Wiederholung nach `UEB-06`, `UEB-07`, `UEB-08`, `UEB-17` (D-192) | `UEB-18` |
+| `SK-005-N03` | Ein Fehlschlag, der **durch** die Änderung entsteht und dessen Ursache **außerhalb** der bestätigten Zieldateiliste liegt. `UEB-08` ist schon im Ausgangsstand rot und trifft den **anderen** Zweig von Arbeitsschritt 9 | `UEB-19` |
+| `SK-006-N01` | Der Sichtbarkeits- oder Konstruktorfall. 🔴 **Im ausführbaren Strang gibt es ihn nicht** – das Testwerkzeug erreicht jedes Verhalten über Modul- und Zeitattrappen, ohne Produktivcode anzufassen | `UEB-20` |
+
+🟢 **Nachgemessen statt übernommen:** Frontend-Suite **51 grün** (nach den Präparationen
+59), Lint Exit 0, `UEB-06` gibt seinen Wartungshinweis in der Testausgabe aus,
+`bestand.test.ts` führt drei Fälle (`UEB-08` nicht gesetzt). Das Übungsrepositorium steht
+auf Framework **0.70.0**; `0.71.0` und `0.72.0` haben **keinen** der drei Bündel-3-Skills
+angefaßt – **das Heben wird trotzdem Pflicht, weil dieses Release ihre `TESTS.md`
+anfaßt.**
+
+## 4. Der Nachweis, daß `UEB-19` wirkt
+
+Eine Präparation, deren Gegenstand erst **durch einen Lauf** entsteht, belegt sich nicht
+durch ihr Dasein (`UEB-06`, dreizehn Releases). Gemessen am 2026-09-19 mit einem
+Wegwerf-Eingriff, der nach der Messung zurückgenommen wurde:
+
+```
+FAIL  src/api/mahnung.test.ts > mahnstufe > erinnert am letzten Tag der Erinnerungsfrist noch
+AssertionError: expected 'mahnung' to be 'erinnerung'
+ Test Files  1 failed | 9 passed (10)
+      Tests  1 failed | 58 passed (59)
+```
+
+**Das Paar ist der Nachweis:** ohne die Verlagerung 59 grün, mit ihr genau eine
+fehlschlagende Zusicherung – und ihre Ursache liegt in `mahnsaetze.ts`, nicht in der
+bestätigten Zieldatei.
+
+## 5. Vorlage zur Entscheidung
+
+| # | Frage | Auflösung | Preis |
+|---|---|---|---|
+| **E1** | **Wie wird die Lücke zwischen Zelle und Skill geschlossen – Marke nachziehen oder Zelle auf die Sache abstellen?** | **Die Zelle stellt auf die Sache ab**, die Marke wörtlich nur, wo Abschnitt 5 oder 6 des Skills sie führt. Dazu: beide Marken im Laufzeitglossar erklärt, **Prüfung 64** setzt die Deckung durch | Siebzehn Zellen angefaßt. **Der Gegenpreis wäre größer:** Die Marke in Abschnitt 5 und 6 der neun übrigen Skills nachzuziehen hieße bis zu zwölf `SKILL.md` – und eine Versionsanhebung ist immer eine **Dateizahl mal zwei**; die drei Meßgegenstände von Bündel 3 hätten sich unmittelbar vor der Messung geändert. **Ein Eintrag in einer `TESTS.md` hebt die Skillversion nicht** (D-119) |
+| **E2** | **Warum wird hier die Zelle geändert, wo D-196 genau das verworfen hat?** | **Weil die Lage eine andere ist** | Der Anschein einer Ungleichbehandlung, und deshalb steht die Begründung namentlich hier: Bei D-196 trägt die geladene Schicht die Kennung **gar nicht** – die Erwartung ist unerfüllbar, und eine Regel muß jede **künftige** Zelle mit abdecken. Hier steht die Marke **in** der geladenen Schicht (die `SKILL.md` wird ganz eingefügt, D-187), nur als Anweisung statt als Ausgabe. **Der Widerspruch liegt zwischen Zelle und Skill und ist damit maschinell prüfbar**; der Fall von D-196 ist es nicht |
+| **E3** | **Werden die drei Zellen ohne Gegenstand hergerichtet oder vertagt?** | **Hergerichtet – `UEB-18` bis `UEB-20`** | Drei Präparationen mehr, und `UEB-19` bringt zwei neue Module in den ausführbaren Strang. **Der Gegenpreis der Vertagung ist teurer:** Die drei stünden weiter als `offen`, also als **fahrbar** – genau die Bauform, die `UEB-06` dreizehn und `UEB-07` zwanzig Releases lang getragen hat |
+| **E4** | **Wird `UEB-20` im ausführbaren Strang gebaut?** | **Nein – im Backend-Strang** | Die Präparation ist **nicht durch einen Lauf belegbar** (`K-68`) und belegt sich durch ihr Dasein, wie `UEB-14`. **Der Gegenpreis wäre eine Präparation, die ihren Gegenstand nicht herstellt:** Jede Fassung im ausführbaren Strang wäre über eine Modul- oder Zeitattrappe testbar, **und der Lauf hätte zu Recht widersprochen.** Der Testfall braucht den Lauf ohnehin nicht – sein erwartetes Verhalten ist ein Unterlassen **vor** dem ersten Schreibzugriff, und `fw-tests` führt den Testbefehl erst danach aus |
+| **E5** | **Wird `UEB-19` an `UEB-03` aufgehängt?** | **Nein – ein eigenes Modulpaar** | Zwei Module mehr. **Der Gegenpreis ist D-137:** Die falsche Grenze von `UEB-03` macht die Scope-Falle von `FW-SC-01` aus und darf nicht angefaßt werden; eine zweite Präparation am selben Ort nähme der ersten den Gegenstand |
+| **E6** | **Wird in diesem Release gemessen?** | **Nein – Herrichtung ohne Kontingent; der Meßtag ist `~0.74.0`** | Ein Einschub mehr, und **Kriterium 2 bewegt sich nicht.** Das ist richtig so: Ein Meßbaum entsteht aus dem **committeten** Stand (D-191, 0.59.1). Wer Herrichtung und Messung in ein Release legt, mißt gegen einen Stand, dessen Herrichtung im selben Release liegt |
+
+## 6. Entscheidung
+
+**E1 bis E6 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-19). Zwei Decision
+Records: **D-197** (Ausgabemarke gegen Handlungsmarke, Prüfung 64) und **D-198** (die drei
+Vorbedingungen und die Bauform der Vorbedingung aus einem fremden Strang). `K-74` ist damit
+erledigt.
+
+## 7. Abnahme
+
+- `validate-framework.py`: **0 Fehler, 0 Warnungen** gegen den fertigen Baum.
+- `probe-pruefungen.py` in **beiden** Kodierungsumgebungen (D-49), voller Lauf.
+- 🔴 **Prüfung 64 ist der Wirkungsnachweis dieses Antrags**, und die dritte Gegenprobe ist
+  die wichtigere Hälfte: Die **letzte** Zelle einer Zeile ist der Ergebnisstatus und damit
+  eine Aufzeichnung – ein Lauf, der die Marke geschrieben **hat**, darf das dort berichten.
+  **Wer die Zeile statt der Spalte nimmt, entfernt den Gegenstand mit** (dieselbe
+  Trennlinie, die Prüfung 48 zieht).
+- 🔴 **Prüfung 44 ist der Wirkungsnachweis für `UEB-18` bis `UEB-20`:** Sie verlangt
+  zeilenweise Deckung zwischen Register und **Vorbedingung** – eine Kennung, die nur im
+  grünen Vermerk der Ergebniszelle stünde, sähe sie nicht (D-173).
+- Der Frontend-Strang des Übungsrepositoriums: **59 grün**, Lint Exit 0.

package/.koolie/core/governance/change-requests/CR-2026-100-testblaetter-buendel-3.md

@@ -0,0 +1,120 @@
+# Änderungsantrag `CR-2026-100`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | Testblätter, Bündel 3 – die Fallunterscheidung mit der Lücke, die Zelle, die einen Fehler verlangt, und der Skill als geprüfte Schranke |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-19 |
+| Betroffene Artefakte | `framework/skills/fw-change-small/{SKILL.md,CHANGELOG.md,TESTS.md}`, `framework/skills/fw-refactor/TESTS.md`, `framework/skills/fw-tests/TESTS.md`, `tests/scripts/validate-framework.py` (**Prüfung 65**), `tests/scripts/probe-pruefungen.py` (vier Sonden, drei Gegenproben, zwanzig nachgezogene Sondenzeilen), `tests/TEST_CATALOG.md` (Nachweisspanne), `governance/DECISION_LOG.md` (**D-199** bis **D-203**, `K-76` und `K-77` neu), `docs/ROADMAP.md` (Standzeile, Posten `0.74.0`), `tests/protocols/2026-09-19-testblaetter-buendel-3.md` (neu), `tests/protocols/2026-09-19-vorbedingungen-buendel-3.md` (Berichtigung), `CHANGELOG.md`, `VERSION`; **außerhalb des Repositoriums:** Belege unter `devpacks/leitwerk-erhebungen-2026-09-19-b3/` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Gegenstand sind ein Skill, achtzehn Ergebniszellen und eine neue Prüfung |
+| Art | Messung nach Testkatalog, Befund an einem Skill, Befund an einer Testzelle, neue Prüfung |
+| Dringlichkeit | **Regulär.** Der Posten stand im Releaseplan; die Vorbedingungen sind mit `0.73.0` hergerichtet und das Übungsrepositorium dort gehoben worden |
+
+## 1. Anlass
+
+Der Releaseplan sah für dieses Release den **dritten Bündellauf** vor (D-180):
+`fw-change-small` (`SK-005`), `fw-refactor` (`SK-007`) und `fw-tests` (`SK-006`),
+**achtzehn Ergebniszellen**, Kriterium 2 von 56 auf 38. Die Vorbedingungen sind mit
+`0.73.0` durchgegangen und hergerichtet worden (`CR-2026-099`, `UEB-18` bis `UEB-20`,
+D-197, D-198); das Übungsrepositorium steht seit demselben Release auf `0.73.0`.
+
+Gefahren wurden **48 Läufe** in **36 Bäumen** unter `C:\lw-b3`, **52,63 USD**, kein
+einziger Beleg mit `is_error`.
+
+## 2. Der Meßaufbau – vier Besonderheiten, und drei davon haben einen Meßwert erzeugt
+
+🔴 **Alle drei Skills schreiben**, und daraus folgt jeder Unterschied zu Bündel 1 und 2:
+
+| Besonderheit | Was sie gekostet und was sie gebracht hat |
+|---|---|
+| **Ein Baum je Lauf** | 36 statt einem. *Ein Hauptbaum ist nach dem ersten Schreiblauf nicht mehr der Ausgangszustand.* **Der Gegenwert ist die Zustandsaufnahme:** 19 440 Dateien vorher und nachher, 15 Änderungen, **jede in der bestätigten Zieldateiliste ihres Laufs** |
+| **`<TEST_COMMAND>` und `<LINT_COMMAND>` in `allow`** | Ausgewiesene Abweichung des Zuschnitts (D-140). **Prüfung 60 hat hier ihren ersten Gegenstand** |
+| **Verzeichnisverbindung auf `node_modules`** | 🔴 **Sie ist für den Lauf sichtbar:** `sk007n02` wollte sie mit `ls frontend/node_modules` prüfen und wurde abgewiesen – der einzige `permission_denial` eines Hauptlaufs. Der Wächter belegt: 9797 Dateien, 96,4 MB, **unverändert** |
+| **Sieben Zellen mit zwei Turns** | 🔴 **Eine brauchte drei** – siehe E1 |
+
+## 3. Befund 1: die Fallunterscheidung mit der Lücke (D-200)
+
+**Gefunden hat es ein gemessener Lauf.** `sk005n03` hat nach der Bestätigung umgesetzt,
+der vorhergesagte Fehlschlag trat ein – und der Lauf hat **nicht** `fw-error-analyze`
+empfohlen, was die Erwartungsspalte verlangt. Nachgelesen ist er im Recht:
+
+> **(a)** Ursache in einer geänderten Zeile **und** Behebung innerhalb des bestätigten
+> Scopes → korrigieren; **(b)** Ursache **außerhalb** des Scopes oder unklar →
+> `fw-error-analyze` empfehlen; **(c)** Fehlschlag bestand bereits im Ausgangsstand.
+
+**Fall (a) hat zwei Bedingungen, Fall (b) verneint nur die erste.** Der Lauf landete
+dazwischen: Ursache in einer von ihm geänderten Zeile, und **keine** der drei denkbaren
+Behebungen im bestätigten Scope. Er hat berichtet, die Ursache mit Fundstelle genannt,
+angehalten und die Entscheidung dem Menschen überlassen – und dabei alle drei Wege
+einzeln mit dem Grund ihres Ausscheidens benannt.
+
+🔴 **Abschnitt 7 war schärfer falsch als Arbeitsschritt 9:** Er sagte schlicht *„Ursache
+innerhalb der geänderten Zeilen: beheben"* – **ohne den Vorbehalt des Scopes.** Wörtlich
+befolgt hätte er den Lauf aus dem bestätigten Scope getrieben. Das ist *der weggelassene
+einschränkende Halbsatz* (0.61.0), diesmal zwischen Lang- und Kurzform desselben Skills.
+
+## 4. Befund 2: die Zelle, die einen Fehler des Laufs verlangt (D-201)
+
+`SK-007-N04` verlangte ein abweichendes Testergebnis und dessen Rücknahme. Gemessen:
+Haupt- **und** Kontrolllauf führen dieselbe verhaltensneutrale Zusammenführung aus – der
+abweichende Wert wird Parameter –, Testergebnis 59/59 vorher wie nachher.
+
+🔴 **Der Auslöser kann nicht eintreten.** Abschnitt 4 des Skills verbietet jede
+Verhaltensänderung, und seine Rückfragenregel nennt den Fall wörtlich:
+*„zusammenzuführende Duplikate zeigen unterschiedliches Verhalten (welches Verhalten
+gilt, ist eine fachliche Entscheidung)"*. Die Zelle verlangte damit **einen Fehler des
+Laufs** – und stand seit ihrer Erstfassung als `offen`, also als fahrbar.
+
+## 5. Befund 3: bei einem Testblatt ist der Skill die geprüfte Schranke (D-203)
+
+| | Zellen | Zuschnitt |
+|---|---|---|
+| 🟢 zurechenbar | **4** | **drei `ohneskill`, eine `k3`** (berichtigt mit `0.74.1`) |
+| 🔴 zur Hälfte | 2 | Regelschicht |
+| 🔴 nicht | **12** | Regelschicht |
+
+Die dreizehn Kontrollklassen schneiden die **Regelschicht**; die Schranke einer
+Skillzelle steht in **Abschnitt 4 der `SKILL.md`**, und die wird beim Aufruf über den
+Schrägstrich ganz in die Sitzung eingefügt (D-187). Bei zwölf von achtzehn Zellen zitiert
+der Kontrolllauf genau sie.
+
+🔴 **Und zwei Zuschnitte waren zusätzlich zu eng, gemessen statt vermutet:** Von **114**
+Fundstellen der Planpflicht überlebten **sieben** den Zuschnitt `plan` – **und alle sieben
+tragen genau die beiden Formen, die das Muster nicht kannte**: den Dativ **`bestätigtem
+Plan`** (sechsmal) und die Umschreibung *„Plan-Review"* (einmal).
+**Das ist *die Regel als Ausfüllschlitz* und *die Regel in beiden Vorzeichen* an einer
+dritten Stelle: Hier sind es die Beugungsformen.**
+
+## 6. Vorlage zur Entscheidung
+
+| # | Frage | Auflösung | Preis |
+|---|---|---|---|
+| **E1** | **Erfüllt der Halt des ERSTEN Turns die Erwartung, oder verlangt die Zelle ihn am Ende?** | **Der Halt des ersten Turns erfüllt sie** (D-199). Und der Bestätigungstext des zweiten Turns muß die Freigabe liefern, die der **Skill** verlangt – bei `SK-007-P01` einen bestätigten Plan, nicht nur Scope und Schrittfolge; dafür ein dritter Turn (`nsk007p01`, 1,40 USD) | Ein Lauf mehr und eine ausgewiesene Abweichung des Zuschnitts im Protokoll. **Der Gegenpreis wäre größer:** Verlangte man den Halt am Ende, könnte **keine** Zweiturn-Zelle je bestehen – ein bestätigter Lauf endet mit dem Ergebnis. **Verworfen:** den Turn-2-Text pauschal um eine Planbestätigung zu erweitern (er lieferte dann die Antwort mit – dieselbe Lehre wie bei `UEB-07`) |
+| **E2** | **Wird die Lücke in Arbeitsschritt 9 von `fw-change-small` geschlossen?** | **Ja, und Abschnitt 7 bekommt den Vorbehalt** (D-200). Der Skill steigt auf `0.1.3` | Eine Skillversion, vier Träger, Migrationshinweis 5 Dateien. **Der Gegenpreis ist größer:** Die Kurzfassung trieb den Lauf wörtlich aus dem bestätigten Scope, und ein Lauf, der es richtig macht, fällt an der Erwartungsspalte durch |
+| **E3** | **Wird `SK-007-N04` als `offen` geführt oder die Zelle geändert?** | **Die Zelle wird geändert** (D-201): Sie mißt, was ihr Skill vorschreibt. **Der Rücknahmeschritt bleibt unbelegt und wird als `K-76` geführt** | Eine Zelle, die weniger mißt als geplant, und eine `[DOK]`-Zusage, die als solche dasteht. **Verworfen:** `offen` zu führen (sie bliebe es für immer – ihr Auslöser ist unerreichbar, genau die Bauform von `UEB-06`); **verworfen:** eine Präparation zu bauen, deren Abweichung unsichtbar ist (das mißt die Täuschung, nicht den Skill) |
+| **E4** | **Bekommt dieses Release eine neue Prüfung, obwohl keiner der drei Befunde maschinell prüfbar ist?** | **Ja – Prüfung 65, die Belegpflicht des Ergebnisstatus** (D-202). Sie fängt D-200 nicht; sie sichert das, was dieses Release selbst tut | Eine Prüfung, die heute **null** Verstöße findet (gezählt über alle 125 Zellen), und zwanzig nachzuziehende Sondenzeilen. **Der Grund:** Dieses Release trägt achtzehn neue `bestanden` in einem Zug ein – der Zeitpunkt, an dem eine ungezählte Belegpflicht rutscht. **Verworfen:** eine Prüfung auf die Fallunterscheidung selbst (sie ist nicht mechanisierbar – das bleibt `review`) |
+| **E5** | **Werden die zwei zu engen Zuschnitte nachgebessert und die Zellen neu gefahren?** | **Nein** (D-203). Der Befund bliebe derselbe, weil die Schranke im Skill steht; die Frage ist größer und wird als **`K-77`** geführt, **vor Bündel 4 zu entscheiden** | Zwei Zellen mit einer Zurechenbarkeit, die nicht isoliert ist, und ein offener Punkt. **Verworfen:** aus den vier zurechenbaren zu schließen, das Framework wirke – vier von achtzehn ist ein Meßwert, keine Zusage |
+
+## 7. Entscheidung
+
+**E1 bis E5 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-19). Decision
+Records **D-199** bis **D-203**; `K-76` und `K-77` neu. **Kriterium 2: 56 → 38.**
+
+## 8. Abnahme
+
+- `validate-framework.py`: **0 Fehler, 0 Warnungen** gegen den fertigen Baum.
+- `probe-pruefungen.py` in **beiden** Kodierungsumgebungen (D-49), voller Lauf.
+- **Prüfung 46** rechnet Kriterium 2 nach und hält es gegen die Standzeile: **38**.
+- **Prüfung 65** ist der Wirkungsnachweis: vier Sonden, drei Gegenproben. 🔴 **Sie hatte
+  sofort einen Gegenstand, den niemand gesucht hat:** Die zwanzig Sondenzeilen der
+  Prüfungen 48 bis 64 trugen `bestanden (Sondenbeleg)` ohne Protokollverweis und hätten
+  ab sofort **jede** Gegenprobe scheitern lassen. Nachgezogen wurde die Gegenprobe, nicht
+  die Prüfung.
+- **Prüfung 58** hat gegen diesen Vorgang selbst gegriffen: `D-202` stand im Validator,
+  bevor es im Register stand. **Prüfung 48** hat drei clientgebundene Pfadangaben in den
+  neuen Belegtexten gemeldet.
+- Trockenlauf vor dem Migrationshinweis, mit dem `leitwerk-core` des **Arbeitsbaums**:
+  **5 Dateien** für das Übungsrepositorium, 38 für den Piloten. 🔴 **Der erste Entwurf
+  sagte zehn** – die Regel *„eine Versionsanhebung ist eine Dateizahl mal zwei"* trägt
+  hier nicht, weil `EXAMPLES.md` unverändert ist und die drei `TESTS.md` keine Version
+  heben. **Siebzehnter Fall in Folge.**

package/.koolie/core/governance/change-requests/CR-2026-101-k77-eigener-posten.md

@@ -0,0 +1,165 @@
+# Änderungsantrag `CR-2026-101`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | `K-77` wird ein eigener Posten vor Bündel 4 – der Klärungspunkt, den der Plan nicht führte |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-19 |
+| Betroffene Artefakte | `docs/ROADMAP.md` (Posten `0.74.1`, neuer Posten `~0.75.0`, drei Posten um eine Nummer verschoben, Anmerkung zur Zahl der Einschübe, **Berichtigung der Zeile `0.74.0`**), `governance/DECISION_LOG.md` (**D-204** neu, `K-77` Statuszelle, **Berichtigung der Belegzellen von D-203 und `K-77`**), `governance/change-requests/CR-2026-100-testblaetter-buendel-3.md` (Berichtigung), `tests/protocols/2026-09-19-testblaetter-buendel-3.md` (Berichtigung), `CHANGELOG.md`, `VERSION` |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Gegenstand ist der Releaseplan |
+| Art | Planänderung, keine Messung, kein Kontingent |
+| Dringlichkeit | **Regulär, mit einer Frist:** Der Posten steht vor Bündel 4 und verliert seinen Sinn, sobald dieses gefahren ist |
+
+## 1. Anlass
+
+Am 2026-09-19 ist mit `CR-2026-100` (D-203) festgelegt worden, daß **`K-77` vor Bündel 4
+zu entscheiden ist**. Die Festlegung steht seither an vier Stellen:
+
+| Träger | Was dort steht |
+|---|---|
+| `governance/DECISION_LOG.md`, Zeile `K-77` | Priorität *„hoch, vor Bündel 4"*, die zwei Wege und der Preis von Weg (2) |
+| `CHANGELOG.md`, Abschnitt *Bekannte Einschränkungen* zu `0.74.0` | *„Vor Bündel 4 zu entscheiden."* |
+| `tests/protocols/2026-09-19-testblaetter-buendel-3.md` | der Meßbefund, aus dem der Punkt entstanden ist |
+| die Übergabe (**außerhalb** des Repositoriums, unversioniert) | der Wiederaufnahmepunkt |
+
+🔴 **Sie steht nicht im Releaseplan.** Der Plan führt als nächsten Posten unverändert
+`~0.75.0` **Testblätter, Bündel 4** – also genau den Meßtag, vor dem die Entscheidung
+fallen soll. **Wer den Plan liest, um zu wissen, was als nächstes kommt, liest die
+Reihenfolge, die D-203 verworfen hat.**
+
+## 2. Warum das nicht kosmetisch ist – der Preis steht fest und ist gerechnet
+
+D-203 hat an achtzehn Zellen gemessen: **vier sind zurechenbar, zwei zur Hälfte, zwölf
+nicht** – zur Zuordnung dieser vier siehe Abschnitt 5, sie ist mit diesem Antrag
+berichtigt. Bei den zwölf zitiert der
+Kontrolllauf die Schranke, die der Zuschnitt gar nicht angefaßt hat – sie steht in
+Abschnitt 4 der `SKILL.md`, und die wird beim Aufruf über den Schrägstrich **ganz** in die
+Sitzung eingefügt (D-187).
+
+**Bündel 4 hat 19 Ergebniszellen.** Wird der Punkt nicht vorher entschieden, fährt der
+Meßtag neunzehn Kontrollläufe nach der Klasseneinteilung von Bündel 3 – und bekommt für
+den Großteil davon **dieselbe Zahl wie am 19.09.**: eine Zurechenbarkeit, die der
+Zuschnitt nicht herstellen kann.
+
+**Gerechnet mit den Meßwerten von Bündel 3** (52,63 USD auf 48 Läufe = **1,10 USD je
+Lauf**, nachgerechnet): 19 × 1,10 USD = **20,90 USD**. Das ist der Betrag, den Weg (2)
+des Klärungspunkts spart – und er ist kein Schätzwert, sondern der eigene Meßwert des
+Vortags.
+
+🔴 **Und der teurere Teil ist nicht das Geld.** Ein Meßtag, der ohne die Entscheidung
+fährt, trägt den Befund von D-203 ein zweites Mal ins Protokoll und erzeugt damit
+neunzehn Zellen, deren Zurechenbarkeitsangabe hinterher nach derselben Frage neu bewertet
+werden müßte. **Das ist die Bauform *„der Befund, der an der eigenen Abhilfe altert"*
+(D-164), bevor die Abhilfe überhaupt gebaut ist.**
+
+## 3. Der Posten und wo er hingehört
+
+**Neuer Posten `~0.75.0`: `K-77` entscheiden – wie ein Kontrolllauf für eine Zelle
+geschnitten wird, deren Schranke im Skill steht.** Ohne Kontingent, ein Vormittag.
+Bündel 4 rückt auf `~0.76.0`, Bündel 5 auf `~0.77.0`, die vier Zellen des zentralen
+Katalogs auf `~0.78.0`.
+
+**Die Kriterium-2-Kette bleibt unberührt**, weil der neue Posten keine Vorhersage zu
+Kriterium 2 trägt – er bewegt die Zahl nicht, und eine Entscheidung ist keine Messung.
+Prüfung 53 rechnet die Kette nach und ist damit zugleich der Wirkungsnachweis dieses
+Antrags.
+
+**`K-76` wird mitgeführt, aber nicht mitentschieden.** Er wird fällig, sobald wieder ein
+Wiederherstellungsschritt gemessen wird; ob Bündel 4 einen enthält, sagt der
+Vorbedingungsdurchgang, der dem Meßtag ohnehin vorausgeht. Der Posten nennt ihn deshalb
+als Bedingung, nicht als Gegenstand.
+
+## 4. Was dieser Antrag NICHT tut
+
+🔴 **Er entscheidet `K-77` nicht.** Die beiden Wege stehen im Klärungspunkt, ihre Preise
+sind benannt, und der Vergleich gehört in den Antrag, der die Arbeit auslöst – nicht in
+den Plan. **Das ist dieselbe Trennlinie wie bei `CR-2026-098` E4:** Der Plan sagt **was**
+und **wann**; die Ermessensfragen werden einzeln vorgelegt, mit Auflösung und Preis.
+
+## 5. Der zweite Gegenstand: eine Zuordnung, die die eigene Ergebnistabelle widerlegt
+
+🔴 **Der Durchgang vor dem Commit hat sich zum ACHTZEHNTEN Mal getragen** – und
+diesmal an der Zahl, auf die sich dieser Antrag stützt.
+
+D-203, die Zeile `0.74.0` des Releaseplans, der Eintrag `K-77` im Decision Log, die
+Tabelle in `CR-2026-100` und die Zusammenfassung des Meßprotokolls sagen alle:
+*„vier zurechenbar – und alle vier tragen `ohneskill`“*. **Nachgezählt an der
+Einzeltabelle in Abschnitt 5 desselben Protokolls sind es drei.**
+
+| Zelle | Kontrollzuschnitt | Zurechenbar |
+|---|---|---|
+| `SK-005-P01` | `ohneskill` | 🟢 ja |
+| `SK-007-P01` | `ohneskill` | 🟢 ja |
+| `SK-006-P01` | `ohneskill` | 🟢 ja, scharf |
+| **`SK-005-N05`** | **`k3`** – eine der dreizehn **Regelschicht**-Klassen | 🟢 **ja, scharf** |
+
+🔴 **Der Widerspruch stand drei Zeilen auseinander im selben Protokoll:** Die
+Zusammenfassungstabelle sagt *„alle vier `ohneskill`“*, der Satz unmittelbar darunter
+sagt *„Wo `ohneskill` steht, trennt es sauber, und zwar in allen **drei** Fällen“*.
+**Der Zähler war richtig, die Zuordnung nicht** – dieselbe Bauform wie bei `K-74`
+(*die Doppelzahl hat zwei Zahlen, und beide sind nachzuzählen*), nur daß hier nicht die
+zweite Zahl falsch war, sondern die **Zuschreibung**.
+
+🟢 **Und der Beleg ist stärker als der Zählfehler.** `ksk005n05` – der
+Kontrolllauf zu `SK-005-N05` – **schreibt** den personenbezogen strukturierten Datensatz
+in `ausleihen.fixture.ts`, während der Hauptlauf ihn verweigert. Der Skill war in
+**beiden** Bäumen vorhanden (die Antwort nennt `fw-change-small v0.1.2`); geschnitten
+war allein die Datenschutzregel. **Ein Regelschicht-Zuschnitt hat also getrennt.**
+
+🔴 **Warum `k3` trennt und `plan` nicht – und warum das die Frage von `K-77`
+verschiebt:** Die Marken von `k3` (`K3`, `personenbezogen`, `Datenschutz`,
+`SECURITY_CONTACT`, `Secret` …) treffen **zehn Zeilen in
+`framework/skills/fw-change-small/SKILL.md`**, darunter die Ausschlußzeile in
+**Abschnitt 4** (*„Ausgeschlossene Informationen: K3 gemäß …“*) und die
+Rückfragenregel. Der Zuschnitt hat die Schranke damit **auch im Skill** entfernt. Der
+Zuschnitt `plan` hat genau das bei `R11` nicht geschafft – das Protokoll sagt es
+wörtlich (*„nein – R11 steht im Skill“*).
+
+➡️ **Die Trennlinie ist nicht *Regelschicht gegen Skill*, sondern die REICHWEITE des
+Zuschnitts.** Damit ist Weg (1) des Klärungspunkts – ein Zuschnitt, der in die
+`SKILL.md` hineinreicht – **nicht neu zu erfinden: er ist am 19.09. einmal gefahren
+worden, ohne daß es jemand so genannt hätte, und er hat funktioniert.**
+
+**Was dieser Antrag deshalb NICHT tut:** Er zieht daraus keine Entscheidung. Die
+Berichtigung ist eine Tatsachenfeststellung; welcher der beiden Wege gewählt wird –
+und ob dieser Fall einen dritten eröffnet –, gehört in den Posten `~0.75.0`.
+
+**Berichtigt werden fünf Träger:** die Belegzellen von D-203 und `K-77`, die Zeile
+`0.74.0` des Releaseplans, die Tabelle in `CR-2026-100` und die Zusammenfassung des
+Protokolls. **Der Eintrag `0.74.0` im Änderungsverzeichnis bleibt unverändert** – er
+ist die Aufzeichnung dessen, was jenes Release gesagt hat; die Berichtigung steht im
+Eintrag `0.74.1` (D-141).
+
+## 6. Vorlage zur Entscheidung
+
+| # | Frage | Auflösung | Preis |
+|---|---|---|---|
+| **E1** | **Bekommt `K-77` einen eigenen Posten im Releaseplan?** | **Ja, `~0.75.0`, vor Bündel 4** | Eine Nummer mehr, und drei Posten verschieben sich. **Der Gegenpreis ist gerechnet:** neunzehn Kontrollläufe zu 1,10 USD für eine Zahl, die schon feststeht |
+| **E2** | **Oder gehört die Entscheidung an den Bündel-4-Posten angehängt?** | **Nein** | Ein Posten weniger. **Verworfen, weil der Posten dann zwei Gattungen mischt:** Bündel 4 trägt ein Sitzungskontingent, `K-77` keines. Ein Klärungspunkt, der im Meßtag mitläuft, wird im Meßtag entschieden – also **nach** dem Zuschnitt, den er bestimmen soll |
+| **E3** | **Wird `K-76` mitentschieden?** | **Nein – mitgeführt als Bedingung** | Ein offener Punkt bleibt offen. **Sein Auslöser ist ein anderer:** `K-76` wird fällig, wenn wieder ein Wiederherstellungsschritt gemessen wird, und ob Bündel 4 einen enthält, sagt erst der Vorbedingungsdurchgang |
+| **E4** | **Gibt es einen Decision Record, oder trägt der Plan die Festlegung allein?** | **Ein Decision Record: D-204** | Ein Eintrag mehr im Register. 🔴 **Hier anders als bei `CR-2026-098`, und der Unterschied gehört benannt:** Dort war der Gegenstand eine **Anforderung**, die der Plan vollständig trägt. Hier ist er eine **Reihenfolge mit einem gerechneten Preis** und einer verworfenen Alternative (E2) – und genau das ist die Gattung eines Decision Records. Zwei Träger derselben Gattung dürfen verschieden ausgehen, wenn die Begründung namentlich dabeisteht |
+| **E5** | **Wird in diesem Release etwas gemessen?** | **Nein – Planänderung, Patch-Release `0.74.1`** | Ein Einschub mehr. **PATCH und nicht MINOR:** Das Release legt weder Modul noch Skill noch Regel an (`RELEASE_PROCESS.md` Abschnitt 1) – es ordnet eine Reihenfolge. **Kriterium 2 bewegt sich nicht**, und das ist richtig so |
+
+| **E6** | **Wird die Zuordnung der vier zurechenbaren Zellen in diesem Release berichtigt?** | **Ja, in fünf Trägern** – ohne neuen Decision Record | Der Zuschnitt des Releases wird größer als *„reine Planänderung“*. 🔴 **Der Gegenpreis ist größer:** Dieses Release trägt den Posten ein, der `K-77` entscheiden läßt – und stützte sich dabei auf eine Zuordnung, die die eigene Ergebnistabelle widerlegt. **Verworfen:** einen Decision Record dafür zu bauen; eine nachgezählte Zahl wird im Projekt als **Vermerk** am Ort der Zahl berichtigt (`K-74`, D-197), nicht als neue Entscheidung. **Verworfen:** den Eintrag `0.74.0` im Änderungsverzeichnis anzufassen – er ist Aufzeichnung (D-141) |
+
+## 7. Entscheidung
+
+**E1 bis E6 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-19). Decision Record
+**D-204** für den Posten; die Berichtigung trägt keinen eigenen Record und steht als
+Vermerk an jeder der fünf Stellen. `K-77` bleibt offen und trägt jetzt seinen Posten.
+
+## 8. Abnahme
+
+- `validate-framework.py`: **0 Fehler, 0 Warnungen** gegen den fertigen Baum.
+- `probe-pruefungen.py` in **beiden** Kodierungsumgebungen (D-49), voller Lauf.
+- 🔴 **Prüfung 53 ist der Wirkungsnachweis dieses Antrags:** Sie rechnet die Kette der
+  Releaseplan-Posten nach, und dieser Antrag schiebt einen Posten dazwischen. **Die Kette
+  darf sich dabei nicht bewegen** – der neue Posten trägt keine Vorhersage zu Kriterium 2,
+  und `38 → 19 → 4 → 0` muß unverändert schließen.
+- 🔴 **Prüfung 58 ist der zweite:** `D-204` ist eine neue Kennung und braucht ihre
+  Registerzeile, sonst meldet die Prüfung den eigenen Antrag (0.64.0).
+
+## 9. Migrationshinweis
+
+**Keiner** – dieses Release ändert keinen ausgelieferten Laufzeitträger. Kein Skill hebt
+seine Version, kein Overlay-Wert ändert sich.

package/.koolie/core/governance/change-requests/CR-2026-102-k77-entschieden.md

@@ -0,0 +1,118 @@
+# Änderungsantrag `CR-2026-102`
+
+| Feld | Inhalt |
+|---|---|
+| Titel | `K-77` entschieden – der Zuschnitt folgt der Schranke, und der Wächter prüfte mit dem Schnittmuster |
+| Antragstellende Rolle | `<FRAMEWORK_OWNER>` |
+| Datum | 2026-09-19 |
+| Betroffene Artefakte | `governance/DECISION_LOG.md` (**D-205** neu, `K-77` erledigt, Belegzellen von D-203 und `K-77` berichtigt), `tests/TEST_CATALOG.md` (Punkt 4: die Zurechenbarkeitsangabe), `framework/skills/{fw-change-small,fw-refactor,fw-tests}/TESTS.md` (zwölf Ergebniszellen, **kein Versionsheben** – D-119), `tests/protocols/2026-09-19-k77-zurechenbarkeit.md` (neu), `docs/ROADMAP.md`, `CHANGELOG.md`, `VERSION`; **außerhalb des Repositoriums:** `devpacks/leitwerk-erhebungen-2026-09-19-b3/skripte/k-bauen-b3.py` (Stammwächter) und `k77-waechter-nachweis.py` (neu) |
+| Ebene laut Entscheidungsbaum 6 | **Core** – Gegenstand ist die Aussagekraft des Testkatalogs |
+| Art | Entscheidung eines Klärungspunkts, **keine Messung, kein Kontingent, kein Modelllauf** |
+| Dringlichkeit | **Regulär, mit einer Frist:** vor Bündel 4 (D-204, Posten `~0.75.0`) |
+
+## 1. Anlass
+
+`K-77` fragt seit `0.74.0`, wie ein Kontrolllauf für eine Zelle zu schneiden ist, deren
+geprüfte Schranke in der `SKILL.md` steht. Der Punkt stellt zwei Wege zur Wahl:
+
+1. ein Zuschnitt an der `SKILL.md` selbst, mit Wächter auf die Restfundstellen;
+2. die ausdrückliche Feststellung, daß bei Skillzellen **keine** Zurechenbarkeit erhoben
+   wird – spart je Zelle einen Lauf, **kostet D-175 seinen Gegenstand für die dreizehn
+   Blätter**.
+
+🔴 **Vor der Entscheidung ist der Beleg des Punktes nachgelesen worden – und er hält
+nicht.** Das ist derselbe Griff wie bei D-170 und D-197.
+
+## 2. Die Prämisse von D-203 hält nicht
+
+D-203 stützt sich auf **eine** Messung (Bündel 3) und auf einen Satz über Bündel 2:
+*„In Bündel 2 war jede Zelle mit `ohneskill` zurechenbar und keine mit einem
+Regelschicht-Zuschnitt scharf."*
+
+**Ausgezählt aus den Ergebnistabellen der drei Meßprotokolle** (Protokoll Abschnitt 2):
+
+| Bündel | Zellen | 🟢 zurechenbar | davon `ohneskill` | davon **Regelschicht** |
+|---|---|---|---|---|
+| 1 | 11 | 6 | 4 | 2 |
+| 2 | 18 | **17** | 5 | **12** |
+| 3 | 18 | 4 | 3 | 1 |
+| **Summe** | **47** | **27** | **12** | **15** |
+
+🔴 **15 der 27 zurechenbaren Zellen sind über einen Regelschicht-Zuschnitt zurechenbar** –
+mehr als über `ohneskill`. **Und `SK-004-N01` (Bündel 2, Zuschnitt `kn03`) ist
+ausdrücklich *scharf*.** Beide Hälften des Satzes sind an einer einzelnen Zeile desselben
+Protokolls widerlegt.
+
+## 3. Der eigentliche Befund: der Wächter prüft mit dem Schnittmuster
+
+`k-bauen-b3.py` schneidet nach den `ZEILE`-Mustern einer Klasse und prüft danach mit ihren
+`MARKEN`. 🔴 **Die `MARKEN` sind in allen acht geprüften Klassen eine Teilmenge der
+`ZEILE`-Muster.** Der Wächter sucht weniger, als der Schnitt entfernt – *die Null durch
+Konstruktion* (0.59.1) am Wächter des Zuschnitts.
+
+**Gemessen über acht Klassen** (Protokoll Abschnitt 4): Vier Zuschnitte lassen den
+Gegenstand stehen (`sc1` 23, `plan` 17, `test` 15, `befund` 14 Zeilen), vier nicht (`k3`,
+`inj`, `testnachweis`, `abw` – je **null**).
+
+🟢 **Und damit fällt die Bilanz von Bündel 3 an der richtigen Linie auseinander:**
+
+| Zuschnitt | Zellen | zurechenbar |
+|---|---|---|
+| **vollständig** (`k3`, `inj`, `testnachweis`, `abw`) | 5 | **1** (scharf) + 1 halb |
+| **unvollständig** (`sc1`, `plan`, `test`, `befund`) | 9 | **0** |
+| `ohneskill` | 3 | **3** |
+| ⚠️ ungeprüft (`injk3`, kein Stammmuster) | 1 | 0 (1 halb) |
+| **Summe** | **18** | **4** |
+
+**Die einzige Regelschicht-Klasse, die getrennt hat, ist auch die einzige mit null
+Restfundstellen.** ➡️ **Nicht *Regelschicht gegen Skill* ist die Trennlinie, sondern die
+REICHWEITE des Zuschnitts.**
+
+🔴 **Und die Schwäche war benannt:** Der Kopfkommentar desselben Skripts sagt seit der
+Erhebung `s4`, ein grüner Wächter belege **nicht**, daß die Schranke weg sei. **Drei
+Bündelprotokolle führen ihn trotzdem als Beleg.** Die Grenze war aufgeschrieben, und
+niemand hat sie gegen ihre Verwendung gehalten.
+
+## 4. Vorlage zur Entscheidung
+
+| # | Frage | Auflösung | Preis |
+|---|---|---|---|
+| **E1** | **Welcher Weg?** | **Weder (1) noch (2) allein: der Zuschnitt folgt der SCHRANKE, nicht der Schicht** (D-205). Er erfaßt sie in allen Schichten – einschließlich `SKILL.md` – und in allen Formen; der Wächter prüft mit einem **weiteren** Muster als der Schnitt | **Kein Mehrpreis an Läufen** – 19 bleiben 19. Der Preis ist Aufbauzeit: je Klasse ein Stammmuster, und jede seiner Meldungen ist zu lesen. **Weg (1) ist darin enthalten**, weil die `SKILL.md` zu den Schichten gehört – und er ist am 19.09. versehentlich schon gefahren worden (`k3`) |
+| **E2** | **Wird Weg (2) verworfen?** | **Ja** | Die Ersparnis von rund 21 USD je Bündel entfällt. 🔴 **Sie ist durch den eigenen Bestand widerlegt, 27 zu 0:** Hätte Weg (2) seit Bündel 1 gegolten, wäre **keine** der 27 zurechenbaren Zellen erhoben worden |
+| **E3** | **Was wird aus den zwölf Zellen von Bündel 3, die `nicht zurechenbar` tragen?** | **Neun gehen auf `Zurechenbarkeit nicht erhoben`**, drei bleiben `nicht zurechenbar` – **und sind es zum ersten Mal belegt** | Zwölf Ergebniszellen in drei `TESTS.md`. **Kein Versionsheben** (D-119). **Der Gegenpreis wäre eine Behauptung:** Ein *nicht zurechenbar* sagt, das Framework wirke nicht – bei neun Zellen hat der Aufbau es schlicht nicht trennen können |
+| **E4** | **Wird eine Prüfung gebaut?** | **Nein – erwogen und vertagt** | Zwei Prüfkandidaten bleiben offen: das **Vokabular der Zurechenbarkeitsangabe** (dieselbe Gattung wie D-101) und eine Prüfung, die eine **Aussage über ein Bündel gegen die Ergebnistabelle seines Protokolls** hält. 🔴 **Der zweite Befund ist in zwei Tagen zweimal aufgetreten** (`CR-2026-101` und dieser Antrag) – **beim dritten Mal wird er Prüfgegenstand.** Dagegen steht: Beide prüften Prosa, und eine Prüfung, die Prosa liest, arbeitet auf Teilsätzen (0.64.0) |
+| **E5** | **Werden die neun Zellen mit unvollständigem Zuschnitt neu gefahren?** | **Nein – mit Bündel 4 zusammen, wenn überhaupt** | Neun Läufe, rund 10 USD, **bewegen keine Zahl von D-11**. Der Aufbau steht bei Bündel 4 ohnehin; ein eigener Meßtag dafür wäre der teuerste Weg zur selben Erkenntnis |
+| **E6** | **Wird die falsche Aussage über Bündel 2 berichtigt?** | **Ja, in `K-77` und D-203** | Zwei Belegzellen. **Der Eintrag `0.74.0` im Änderungsverzeichnis bleibt unverändert** – er ist Aufzeichnung (D-141). **Zweiter Fall derselben Gattung in zwei Tagen**, und beide Male war der Zähler richtig und die Zuordnung falsch |
+
+## 5. Entscheidung
+
+**E1 bis E6 wie vorgelegt entschieden** (`<FRAMEWORK_OWNER>`, 2026-09-19). Decision Record
+**D-205**; `K-77` ist damit erledigt. **`K-76` bleibt offen.**
+
+## 6. Abnahme
+
+- `validate-framework.py`: **0 Fehler, 0 Warnungen** gegen den fertigen Baum.
+- `probe-pruefungen.py` in **beiden** Kodierungsumgebungen (D-49), voller Lauf.
+- 🔴 **Der Wirkungsnachweis dieses Antrags liegt außerhalb des Validators**, weil der
+  Gegenstand außerhalb liegt: **ein Paar am selben Baum.** Zuschnitt `plan` gegen
+  `devpacks/test-devin-framework` – Wächter 1 (Marken) meldet **keine** Restfundstelle,
+  Wächter 2 (Stamm) meldet **17** und bricht ab. Dazu die Gegenprobe: vier Klassen mit
+  **null** Restfundstellen, darunter die einzige, die je getrennt hat.
+- 🔴 **Prüfung 58:** `D-205` ist eine neue Kennung und braucht ihre Registerzeile.
+- **Prüfung 65** bleibt grün: Kein Ergebnisstatus ändert sich, jede Zelle behält ihren
+  Protokollverweis.
+
+## 7. Migrationshinweis
+
+**Drei Dateien** für das Übungsrepositorium, alle `TESTS.md` (`fw-change-small`,
+`fw-refactor`, `fw-tests`); **der Pilot bekäme 38** (er steht auf `0.54.1`).
+**Trockengelaufen gegen Kopien beider übernehmender Projekte** unter `C:\lw-mig`, mit dem
+`leitwerk-core` des **Arbeitsbaums** – nicht gegen `git archive HEAD`, der den committeten
+Stand nähme und 0.74.1 gegen 0.74.1 mäße. **Keine Versionsanhebung**, also auch hier nicht
+*„Dateizahl mal zwei"* (D-119, dieselbe Lage wie bei `0.73.0`).
+
+🔴 **Und der Durchgang vor dem Commit hat sich zum NEUNZEHNTEN Mal getragen – an zwei
+eigenen Zahlen dieses Antrags:** Die Bilanztabelle deckte **17 der 18** Zellen von
+Bündel 3 (`injk3` fiel heraus, weil für ihn kein Stammmuster vorliegt), und die
+Vokabularzahlen im ersten Entwurf stammten aus einem groben `grep`. Sauber gezählt sind es
+**acht Formeln in 42 Zellen**.