@renoxar/koolie 1.25.0 → 2.0.0

package/.github/workflows/publish.yml

@@ -0,0 +1,177 @@
+# Veroeffentlicht Koolie auf TestPyPI, PyPI und npm - ohne Token, ueber Trusted Publishing.
+#
+# Ausloeser ist nur eine Marke v<Version>. Die Marke muss vom Framework Owner signiert sein
+# (geprueft gegen die Variable KOOLIE_ALLOWED_SIGNERS) und zu .koolie/core/VERSION passen.
+# Ablauf: pruefen und bauen -> TestPyPI mit Installationsprobe -> nach Freigabe in der
+# Umgebung "release" PyPI und npm. Scheitert ein Schritt, laeuft keiner danach.
+# Einrichtung und Ablauf: .koolie/core/governance/RELEASE_PROCESS.md, Abschnitt 4.2, Schritt 9.
+name: Veroeffentlichen
+
+on:
+  push:
+    tags:
+      - "v*"
+
+permissions:
+  contents: read
+
+concurrency:
+  group: veroeffentlichen
+  cancel-in-progress: false
+
+jobs:
+  pruefen:
+    name: Marke pruefen und Pakete bauen
+    runs-on: ubuntu-latest
+    outputs:
+      version: ${{ steps.marke.outputs.version }}
+    steps:
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          fetch-depth: 0
+          persist-credentials: false
+
+      - id: marke
+        name: Marke gegen VERSION und Signatur pruefen
+        env:
+          MARKE: ${{ github.ref_name }}
+          ERLAUBTE_SIGNIERER: ${{ vars.KOOLIE_ALLOWED_SIGNERS }}
+        run: |
+          set -euo pipefail
+          # Die annotierte Marke selbst holen; der Checkout legt sonst nur den Commit ab.
+          git fetch --force origin "refs/tags/${MARKE}:refs/tags/${MARKE}"
+          version="$(tr -d '\r\n' < .koolie/core/VERSION)"
+          if [ "${MARKE}" != "v${version}" ]; then
+            echo "::error::Marke ${MARKE} passt nicht zu VERSION ${version}"; exit 1
+          fi
+          if [ -z "${ERLAUBTE_SIGNIERER}" ]; then
+            echo "::error::Variable KOOLIE_ALLOWED_SIGNERS fehlt - ohne sie ist die Signatur nicht pruefbar"; exit 1
+          fi
+          printf '%s\n' "${ERLAUBTE_SIGNIERER}" > "${RUNNER_TEMP}/allowed_signers"
+          git config gpg.ssh.allowedSignersFile "${RUNNER_TEMP}/allowed_signers"
+          git tag -v "${MARKE}"
+          echo "version=${version}" >> "${GITHUB_OUTPUT}"
+
+      - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
+        with:
+          python-version: "3.12"
+
+      - name: Archiv aus der Marke und Pakete bauen
+        env:
+          MARKE: ${{ github.ref_name }}
+          VERSION: ${{ steps.marke.outputs.version }}
+        run: |
+          set -euo pipefail
+          git -c core.eol=lf -c core.autocrlf=input -c tar.umask=022 archive \
+            --format=tar.gz --prefix="koolie-${VERSION}/" -o "koolie-${VERSION}.tar.gz" "${MARKE}"
+          python paketquellen/bauen.py --archiv "koolie-${VERSION}.tar.gz" --aus pakete
+          mkdir -p dist/pypi dist/npm
+          cp "pakete/koolie-${VERSION}-py3-none-any.whl" dist/pypi/
+          cp "pakete/koolie-${VERSION}.tgz" dist/npm/
+          cp pakete/SHA256SUMS dist/
+          cat dist/SHA256SUMS
+
+      - uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
+        with:
+          name: pakete
+          path: dist/
+          if-no-files-found: error
+
+  testpypi:
+    name: TestPyPI und Installationsprobe
+    needs: pruefen
+    runs-on: ubuntu-latest
+    environment:
+      name: testpypi
+      url: https://test.pypi.org/project/koolie/${{ needs.pruefen.outputs.version }}/
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
+        with:
+          name: pakete
+          path: dist/
+
+      - uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33 # v1.14.2
+        with:
+          repository-url: https://test.pypi.org/legacy/
+          packages-dir: dist/pypi/
+          skip-existing: true
+
+      - uses: astral-sh/setup-uv@c18668ad3cf93ea998bef934396af7bb5c839dc7 # v10.2.0
+
+      - name: Aus TestPyPI in ein Wegwerfprojekt installieren
+        env:
+          VERSION: ${{ needs.pruefen.outputs.version }}
+          KOOLIE_NO_BANNER: "1"
+        run: |
+          set -euo pipefail
+          for i in $(seq 1 40); do
+            curl -fsS https://test.pypi.org/simple/koolie/ | grep -q "koolie-${VERSION}-py3" && break
+            sleep 15
+          done
+          projekt="${RUNNER_TEMP}/probe"
+          mkdir -p "${projekt}" && git -C "${projekt}" init -q
+          uvx --no-cache --index-url https://test.pypi.org/simple/ "koolie==${VERSION}" \
+            --target "${projekt}" --client claude-code | tee "${RUNNER_TEMP}/probe.txt"
+          grep -Eq "Zusammenfassung: [1-9][0-9]* angelegt" "${RUNNER_TEMP}/probe.txt"
+          [ "$(tr -d '\r\n' < "${projekt}/.koolie/core/VERSION")" = "${VERSION}" ]
+          echo "Probe bestanden: koolie ${VERSION} aus TestPyPI installiert"
+
+  veroeffentlichen:
+    name: PyPI und npm
+    needs: [pruefen, testpypi]
+    runs-on: ubuntu-latest
+    environment:
+      name: release
+      url: https://pypi.org/project/koolie/${{ needs.pruefen.outputs.version }}/
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
+        with:
+          name: pakete
+          path: dist/
+
+      - uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33 # v1.14.2
+        with:
+          packages-dir: dist/pypi/
+          skip-existing: true
+
+      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
+        with:
+          node-version: "24"
+          registry-url: https://registry.npmjs.org
+
+      - name: npm-Paket veroeffentlichen
+        env:
+          VERSION: ${{ needs.pruefen.outputs.version }}
+        run: |
+          set -euo pipefail
+          # Trusted Publishing braucht npm ab 11.5.1.
+          npm install -g npm@11
+          if npm view "@renoxar/koolie@${VERSION}" version >/dev/null 2>&1; then
+            echo "@renoxar/koolie@${VERSION} liegt schon auf npm - uebersprungen"
+          else
+            npm publish "dist/npm/koolie-${VERSION}.tgz" --access public
+          fi
+
+      - name: Veroeffentlichte Bytes gegen SHA256SUMS lesen
+        env:
+          VERSION: ${{ needs.pruefen.outputs.version }}
+        run: |
+          set -euo pipefail
+          soll_whl="$(grep " koolie-${VERSION}-py3-none-any.whl$" dist/SHA256SUMS | cut -d' ' -f1)"
+          soll_tgz="$(grep " koolie-${VERSION}.tgz$" dist/SHA256SUMS | cut -d' ' -f1)"
+          for i in $(seq 1 40); do
+            ist_whl="$(curl -fsS https://pypi.org/pypi/koolie/json \
+              | python3 -c "import json,sys;d=json.load(sys.stdin);print(next((u['digests']['sha256'] for u in d['releases'].get('${VERSION}',[]) if u['filename'].endswith('.whl')),''))")"
+            [ -n "${ist_whl}" ] && break
+            sleep 15
+          done
+          [ "${ist_whl}" = "${soll_whl}" ] || { echo "::error::PyPI: SHA-256 ${ist_whl} statt ${soll_whl}"; exit 1; }
+          ist_npm="$(npm view "@renoxar/koolie@${VERSION}" dist.integrity)"
+          soll_npm="sha512-$(openssl dgst -sha512 -binary "dist/npm/koolie-${VERSION}.tgz" | base64 -w0)"
+          [ "${ist_npm}" = "${soll_npm}" ] || { echo "::error::npm: ${ist_npm} statt ${soll_npm}"; exit 1; }
+          sha256sum "dist/npm/koolie-${VERSION}.tgz" | grep -q "^${soll_tgz} "
+          echo "PyPI und npm tragen die Bytes aus SHA256SUMS"

package/.koolie/QUELLREPOSITORIUM.md

@@ -1,18 +1,13 @@
 # Kennzeichen des Quellrepositoriums
 
-Diese Datei kennzeichnet das **Framework-Repositorium selbst** – im Unterschied zu einem
-Projekt, das das Framework übernommen hat. Sie trägt keinen Inhalt, der gelesen werden
-muss; ihr **Vorhandensein** ist die Aussage (D-351).
+Diese Datei kennzeichnet das Repositorium von Koolie selbst – im Unterschied zu einem
+Projekt, das Koolie übernommen hat. Ihr Inhalt ist nebensächlich; dass sie da ist, ist
+die Aussage.
 
-Der Validator unterscheidet an ihr, wo er läuft. Im Quellrepositorium prüfen die
-Prüfungen 75 und 81 alle versionierten Dateien und Prüfung 79 die Lizenz an beiden
-Stellen; in einem übernehmenden Projekt beschränken sie sich auf das Ausgelieferte, und
-Prüfung 78 enthält sich.
+Der Validator erkennt an ihr, wo er läuft. Im Quellrepositorium prüft er alle
+versionierten Dateien und die Lizenz an beiden Stellen; in einem Projekt nur das, was
+ausgeliefert wird.
 
-**Sie wandert nicht in ein Projekt.** Sie liegt neben dem Kern, nicht in ihm: Das Heben
-kopiert nur `.koolie/core/`, und `install.py` legt sie nicht an. ⚠️ **Wer ganz `.koolie/`
-kopiert, nimmt sie trotzdem mit** – aus einem Klon ebenso wie aus dem Release-Archiv,
-denn sie ist versioniert. `install.py` meldet sie dann; in einem Projekt gehört sie
-entfernt (D-354). Bis `1.4.0` war dieses
-Kennzeichen die Übergabe `UEBERGABE.md`; seit `1.4.1` ist die Übergabe ein lokales
-Arbeitsdokument und nicht mehr versioniert (D-350).
+**In ein Projekt gehört sie nicht.** `install.py` kopiert nur `.koolie/core/` und legt
+diese Datei nicht an. Wer von Hand ganz `.koolie/` kopiert, nimmt sie mit – dann meldet
+`install.py` sie, und sie wird im Projekt gelöscht.

package/.koolie/core/CHANGELOG.md

@@ -2,6 +2,65 @@
 
 Format: Semantic Versioning; je Release Änderungen, Migrationshinweise für Overlays und bekannte Einschränkungen. Prozess: `.koolie/core/governance/RELEASE_PROCESS.md`.
 
+## [2.0.0] - 2026-10-02
+
+**Ein sauberer öffentlicher Auftritt, das Präfix `koolie-` und die Veröffentlichung ohne Token**
+(`CR-2026-173`, **D-539** bis **D-541**, Prüfung 113 neu, Prüfung 112 erweitert; `K-210` geklärt, `K-213` bis
+`K-215` neu). Drei Stichprobenläufe `claude-code`, 1,49 USD nach Listenpreis. Kriterium 2 von D-11 bleibt 0.
+
+**Bruch**
+
+- **Die mitgelieferten Skills heißen `koolie-<name>`** (D-539): `/fw-plan` wird `/koolie-plan`, `role-re-ticket`
+  wird `koolie-ticket`, das Agentenprofil `fw-reviewer` wird `koolie-reviewer`. `koolie-*` gehört dem Framework,
+  `prj-*` dem Projekt; der Validator verlangt eindeutige Namen über alle Packs.
+
+**Neu**
+
+- **`install.py --update` migriert selbst** (D-539): Es benennt alte Skillordner und das Agentenprofil um und
+  ersetzt die alten Namen in der Berechtigungsdatei einmalig, mit Meldung; `--dry-run` und `--check` zeigen es
+  vorher. Sondenteil 19.
+- **Keine Kennungen in der Produktdokumentation** (D-540): Prüfung 113 meldet `CR-`, `D-` und `K-`-Kennungen
+  außerhalb der Nachweisschicht. Ausgenommen sind Ergebnis- und Belegspalten, die Belegspalte der
+  Fähigkeitsmatrix, Versionsverläufe und drei Kapitel des Hauptdokuments (Grenzen, Anhänge, Abschluss).
+  Sondenteil 20. Die Schreibregeln stehen in `docs/DOCUMENTATION_STANDARD.md` Abschnitt 3.
+- **Die Produktdokumentation ist neu gefasst**: Übernahmeleitfaden, Quickstart, `clients/README.md`, Regeln und
+  Prozesse, die fünf `CLIENT_PACK.md` und das Hauptdokument – ohne Entscheidungsgeschichte, kürzer. Anweisungen
+  in Skills und Laufzeitregeln sind unverändert; in `03-security.md` und `05-working-model.md` fielen nur
+  Versionsangaben und Fettdruck, die Standmarke von `koolie-refactor` ist bestätigt.
+- **Trusted Publishing für PyPI und npm** (D-541, `K-210`): Der Workflow `.github/workflows/publish.yml` am
+  GitHub-Spiegel läuft nur an einer Marke `v*`, prüft Signatur und `VERSION`, lädt auf TestPyPI mit
+  Installationsprobe und erst nach Freigabe des Owners auf PyPI (Attestierung) und npm (Provenienz). Prüfung 112
+  Gegenstand d, Sonden 112k bis 112n. Einrichtung in `RELEASE_PROCESS.md` Abschnitt 4.2.
+- Drei Ideen des Owners sind ohne Ziel-Release vorgemerkt (`K-213` bis `K-215`).
+
+**Gemessen**
+
+- Drei Stichprobenläufe `claude-code` 2.1.287: Skill per Slash, modellseitig und in einem gehobenen Projekt, alle
+  tragen, 0 Abweisungen (`tests/protocols/2026-10-02-oeffentlicher-auftritt-2.0.0.md`).
+- Der Workflow lokal: `actionlint` 1.7.12 ohne Befund, Bau und Installationsprobe aus dem Wheel, Signaturprüfung an
+  `v1.25.0` mit Gegenprobe.
+
+**Behoben**
+
+- Das Hauptdokument nannte vier Client Packs und zwölf Referenz-Skills, im Verzeichnisbaum fehlten `cursor`, `kiro`
+  und vier Kernskripte, und es beschrieb die Overlay-Sperre noch als `deny`.
+- Das Pack `software-development` nannte den Schritt `install.py --update` nicht; die Overlay-Vorlage sagte in
+  Abschnitt 6, keine Prüfung vergleiche die Konfigurationslisten (Prüfung 89 tut es).
+- `openai-codex` Abschnitt 7.1 nannte unerhoben, was die Belegzelle B6 belegt.
+
+**Migrationshinweis für Overlays**
+
+- `install.py --update` (oder `koolie --target <projekt> --update`) hebt die Skillnamen selbst; vorher zeigt
+  `--dry-run`, was umbenannt wird.
+- Von Hand: Nennt das Overlay, eine eigene Regel (`2N-overlay-*`), eine README oder eine Merge-Request-Vorlage
+  Skillnamen, auf `koolie-` umstellen. Ein projekteigener Skill mit Präfix `fw-` oder `koolie-` wird `prj-`.
+- Slash-Befehle in Notizen und Gewohnheiten: `/koolie-<name>`.
+
+**Bekannte Einschränkungen**
+
+- Der Workflow läuft erstmals an `v2.0.0`; bis zum ersten erfolgreichen Lauf bleiben die Tokens als Rückfall.
+- `K-211` und `K-212` bleiben offen.
+
 ## [1.25.0] - 2026-10-01
 
 **Ein neuer Auftritt, npm unter dem Scope und die Suche nach dem Aeltesten - und der Name, den npm fuer cookie hielt**

package/.koolie/core/LICENSE-HINWEIS.md

@@ -7,7 +7,6 @@
 | Status | `pilot` |
 | Owner (Rolle) | `<FRAMEWORK_OWNER>` |
 | Gilt für | den gesamten Inhalt dieses Frameworks – Kern, Client Packs, Regeltexte, Werkzeuge, Vorlagen und Dokumentation |
-| Entstehung | `CR-2026-126`, **D-316** bis **D-317** (2026-09-23); Rechteinhaber benannt mit `CR-2026-128`, **D-323**; SPDX-Kennung mit `CR-2026-165`, **D-507** |
 
 ## 1. Lizenz (normativ)
 
@@ -17,13 +16,13 @@ Open-Source-Definition** – jede und jeder darf es nutzen, untersuchen, ändern
 weitergeben.
 
 SPDX-Kennung: `GPL-3.0-only` – es gilt Version 3, nicht „oder jede spätere Version“
-(D-507). Das Banner des Installationsdialogs liest diese Zeile und die folgende und nennt
+. Das Banner des Installationsdialogs liest diese Zeile und die folgende und nennt
 die Kurzform `GPL-3.0`.
 
 Copyright © 2026 René Hildebrand
 
 > 🔴 **Diese eine Zeile nennt eine Person, und sie ist die einzige im ganzen Kern, die
-> das tut** (D-323, `CR-2026-128` E7). Überall sonst gilt die Projektneutralität: Rollen
+> das tut**. Überall sonst gilt die Projektneutralität: Rollen
 > statt Personen, Platzhalter statt Namen. **Hier gilt sie nicht, und der Grund ist
 > keine Ausnahme vom Prinzip, sondern seine Grenze.** Die Neutralitätsregel hält
 > **fremde** Personen aus generischen Bestandteilen – Kunden, Behörden, Kolleginnen und
@@ -35,7 +34,7 @@ Copyright © 2026 René Hildebrand
 > übernehmende Projekt. ⚠️ **Und der Widerspruch, der ihn nötig machte, ist gemessen:**
 > Die Historie dieses Repositoriums führt denselben Namen in **122 Commits** und die
 > Adresse in allen **261** – *er stand dort, wo er niemandem nützt, und fehlte dort, wo
-> er rechtlich wirkt* (D-324).
+> er rechtlich wirkt*.
 
 > Dieses Programm ist freie Software: Sie können es unter den Bedingungen der GNU General
 > Public License, Version 3, weitergeben und/oder verändern. Es wird **ohne jede
@@ -80,11 +79,11 @@ nur benutzt, entsteht keine einzige Pflicht.
 | Mit dem Framework wird ein Produkt entwickelt und verkauft | **keine Pflicht.** Das Produkt ist keine Ableitung: Es enthält keine Zeile dieses Frameworks, und die Ausgabe eines Werkzeugs ist keine Ableitung des Werkzeugs (Abschnitt 2) |
 | Das Projektrepositorium wird veröffentlicht, mit `<CORE_DIR>/` darin | `<CORE_DIR>/` steht unter GPL-3.0 – **es steht ohnehin schon so da.** Der eigene Code daneben bleibt frei: §5 GPL-3.0 nennt das ein *aggregate*, und ein gemeinsames Repositorium ist genau das |
 | Code dieses Frameworks wird **in** ein Produkt hineinkopiert | Dieser Teil wird GPL-3.0. **Das ist gewollt** und der einzige Fall, in dem die Lizenz greift |
-| Das Framework selbst wird weitergegeben, entgeltlich oder unentgeltlich | Es muss unter GPL-3.0 weitergegeben werden, mit Quelltext. **Ein Umbenennen-und-proprietär-Verkaufen ist damit ausgeschlossen** – das war der tragende Grund der Lizenzwahl (D-316) |
+| Das Framework selbst wird weitergegeben, entgeltlich oder unentgeltlich | Es muss unter GPL-3.0 weitergegeben werden, mit Quelltext. **Ein Umbenennen-und-proprietär-Verkaufen ist damit ausgeschlossen** – das war der tragende Grund der Lizenzwahl |
 
 ## 4. Die verworfenen Alternativen (Erläuterung)
 
-Beides ist in `CR-2026-126` Abschnitt 4 einzeln vorgelegt und in D-316 entschieden:
+Zwei Alternativen lagen nahe:
 
 - **Apache-2.0** – verworfen: Sie erlaubt ausdrücklich, das Werk umzubenennen, zu schließen
   und zu verkaufen. Ihr einziger Riegel ist §6, und der schützt den **Namen**, nicht die

package/.koolie/core/OWNERS.md

@@ -16,7 +16,7 @@
 | Datenschutzmodell (FW-CORE-02) | `.koolie/core/framework/core/02-privacy.md`, Regelablage `10-*` | `<FRAMEWORK_OWNER>` mit `<DATA_PROTECTION_CONTACT>` | – |
 | Sicherheitsmodell (FW-CORE-03), Berechtigungen, Hooks | `.koolie/core/framework/core/03-security.md`, `.koolie/core/framework/runtime/permissions.json`, `.koolie/core/framework/runtime/hooks.json`, `.koolie/core/clientmap.py`, `.koolie/core/tests/scripts/hook-*` | `<FRAMEWORK_OWNER>` mit `<SECURITY_CONTACT>` | – |
 | Role Pack Softwareentwicklung | `.koolie/core/framework/role-packs/software-development/`, Regelablage `30-role-software-development.md` | `<FRAMEWORK_OWNER>` (bis Benennung Modul-Owner: `<TBD>`) | – |
-| Role Pack Requirements Engineering (RP-RE), Skill `role-re-ticket` | `.koolie/core/framework/role-packs/requirements-engineering/` | `<FRAMEWORK_OWNER>` | `<TBD: Rolle>` |
+| Role Pack Requirements Engineering (RP-RE), Skill `koolie-ticket` | `.koolie/core/framework/role-packs/requirements-engineering/` | `<FRAMEWORK_OWNER>` | `<TBD: Rolle>` |
 | Technology Packs | `.koolie/core/framework/tech-packs/` | je Pack `<TBD: Modul-Owner>` | – |
 | Client Packs (Abbildung auf KI-Clients) | `.koolie/core/clients/` | `<FRAMEWORK_OWNER>` | `<SECURITY_CONTACT>` für Kernzusagen ohne technische Durchsetzung |
 | Client Pack `devin-desktop` (CP-DD) | `.koolie/core/clients/devin-desktop/` | `<FRAMEWORK_OWNER>` | `<TBD: Rolle>` |
@@ -24,7 +24,7 @@
 | Client Pack `openai-codex` (CP-OC) | `.koolie/core/clients/openai-codex/` | `<FRAMEWORK_OWNER>` | `<TBD: Rolle>` |
 | Client Pack `kiro` (CP-KI) | `.koolie/core/clients/kiro/` | `<FRAMEWORK_OWNER>` | `<TBD: Rolle>` |
 | Client Pack `cursor` (CP-CU) | `.koolie/core/clients/cursor/` | `<FRAMEWORK_OWNER>` | `<TBD: Rolle>` |
-| Framework-Skills FW-SK-001…012 | Skill-Ablage `fw-*` | `<FRAMEWORK_OWNER>` (bis Benennung Modul-Owner je Gruppe) | – |
+| Framework-Skills FW-SK-001…012 | Skill-Ablage `koolie-*` | `<FRAMEWORK_OWNER>` (bis Benennung Modul-Owner je Gruppe) | – |
 | Prompt-Bibliothek | `.koolie/core/prompts/` | `<FRAMEWORK_OWNER>` | – |
 | Checklisten und Entscheidungsbäume | `.koolie/core/checklists/`, `.koolie/core/decision-trees/` | `<FRAMEWORK_OWNER>` | – |
 | Onboarding | `.koolie/core/onboarding/` | `<FRAMEWORK_OWNER>` mit Mentorinnen und Mentoren | – |

package/.koolie/core/VERSION

@@ -1 +1 @@
-1.25.0
+2.0.0

package/.koolie/core/build/doc/00-kopf.md

@@ -4,15 +4,15 @@
 
 | | |
 |---|---|
-| Dokumentversion | 1.25.0 (entspricht Framework-Release 1.25.0) |
+| Dokumentversion | 2.0.0 (entspricht Framework-Release 2.0.0) |
 | Stand | 2026-09-28 |
-| Status | **Kein Modulträger steht auf `entwurf`.** Gezählt am 2026-09-22 über den ganzen Kern: 81 Träger führen eine Steckbriefzeile, davon **77 auf `pilot`** und vier als Ausfüllschlitz einer Vorlage – Kriterium 3 der 1.0.0-Definition ist seit Release 0.53.0 erfüllt und wird bei jedem Validatorlauf nachgerechnet (Prüfung 46). Die technische Validierung gegen reale Installationen ist als Roadmap-Arbeitspaket AP2 **gefahren und mit Release 0.86.0 zu Ende geführt**; die Protokolle liegen unter `.koolie/core/tests/protocols/`. Was zwischen diesem Stand und 1.0.0 liegt, steht im Releaseplan der Roadmap (Kap. 30) |
+| Status | Kein Modulträger steht auf `entwurf`; Prüfung 46 rechnet das bei jedem Validatorlauf nach. Die technische Validierung gegen reale Installationen (Roadmap-Arbeitspaket AP2) ist abgeschlossen; die Protokolle liegen unter `.koolie/core/tests/protocols/`. Was als Nächstes kommt, steht in der Roadmap (Kap. 30) |
 | Vertraulichkeit | projektneutral – enthält keine organisations-, kunden-, personen- oder infrastrukturspezifischen Inhalte; Beispiele sind synthetisch |
-| Zielprodukt | Kein einzelnes. Der Kern ist werkzeugneutral; die Bindung an einen KI-Client leistet ein **Client Pack** (`.koolie/core/clients/`). Ausgeliefert werden fünf: `devin-desktop`, `claude-code`, `openai-codex`, `kiro` und `cursor` (Reifegrad `pilot`). **Welches Produkt ein Pack abbildet, gegen welche verbindliche Zielversion und mit welchem Stand der Produktbeobachtung, steht im Pack selbst** (Kap. 7a, 15.1) – nicht hier: Diese Angaben ändern sich mit dem Produkt, und der Kern soll sich nicht mit ihm ändern. |
-| **Reproduzierbarkeit** | Das Dokument wird aus dem Repository assembliert und baut aus einem frischen Auscheckstand. Laufzeitdateien stammen aus einer Referenzinstallation, die beim Bau entsteht; jede trägt die Angabe, aus welchem Client Pack sie kommt. |
+| Zielprodukt | Kein einzelnes. Der Kern ist werkzeugneutral; die Bindung an einen KI-Client leistet ein **Client Pack** (`.koolie/core/clients/`). Ausgeliefert werden fünf: `devin-desktop`, `claude-code`, `openai-codex`, `kiro` und `cursor` (Reifegrad `pilot`). Welches Produkt ein Pack abbildet, gegen welche Zielversion und mit welchem Stand der Produktbeobachtung, steht im Pack selbst (Kap. 7a, 15.1), weil sich diese Angaben mit dem Produkt ändern. |
+| Reproduzierbarkeit | Das Dokument wird aus dem Repository assembliert und baut aus einem frischen Auscheckstand. Laufzeitdateien stammen aus einer Referenzinstallation, die beim Bau entsteht; jede trägt die Angabe, aus welchem Client Pack sie kommt. |
 | Bestandteile der Lieferung | dieses Hauptdokument (Markdown und Word) und das Referenz-Repository – das Repository ist die maßgebliche, versionierte Quelle aller eingebetteten Artefakte |
 | Autorenschaft | erstellt als beauftragte Ausarbeitung; Verantwortungsübernahme durch `<FRAMEWORK_OWNER>` bei Übernahme |
 
-**Warum Koolie?** Ein **Koolie** ist ein australischer Hütehund, und das Bild ist die Aufgabenbeschreibung dieses Frameworks: Ein Hütehund treibt die Herde nicht, und er ersetzt den Schäfer nicht – er hält sie beisammen und in Richtung. Er arbeitet selbständig, aber auf Anweisung, und er hält Grenzen, ohne zu beißen. Genau das tut dieses Framework mit einem KI-Client: Es macht ihn nicht besser, und es entscheidet nichts an seiner Stelle – es hält ihn in der Spur, an den Grenzen und an den Stellen, an denen ein Mensch entscheidet. Ein Koolie ist außerdem eine **Gebrauchsrasse, kein Schauhund**, und das ist hier ein Anspruch: Was in diesem Dokument steht, muss im Alltag eines Projekts tragen, nicht in einer Vorführung gut aussehen. Die Namensentscheidung mit ihrer Begründung und den verworfenen Alternativen steht als D-125 im Decision Log (Kap. 29.2).
+**Warum Koolie?** Ein Koolie ist ein australischer Hütehund. Er treibt die Herde nicht und ersetzt den Schäfer nicht; er hält sie beisammen und in Richtung, selbständig, aber auf Anweisung. Das tut dieses Framework mit einem KI-Client: Es entscheidet nichts an seiner Stelle, sondern hält ihn in der Spur, an den Grenzen und an den Stellen, an denen ein Mensch entscheidet. Und ein Koolie ist eine Gebrauchsrasse, kein Schauhund: Was hier steht, muss im Alltag eines Projekts tragen.
 
-**Lesehinweise:** Verbindlichkeit wird durchgängig über **MUSS / SOLL / KANN / DARF NICHT** ausgedrückt; normative Abschnitte sind als solche gekennzeichnet, Erläuterungen tragen den Zusatz „(Erläuterung)", Beispiele sind stets „**Beispiel (synthetisch)**". Jede Aussage über Produktfunktionen eines KI-Clients trägt einen Belegstatus: `[DOK]` offiziell dokumentiert (Quellen in Anhang 31.4), `[EMPF]` technisch begründete, noch nicht in einer Installation ausgeführte Empfehlung, `[KONZ]` konzeptioneller Vorschlag ohne Produktbezug; offene Prüfpunkte tragen den Belegstand `BELEG OFFEN` mit Grund und Datum. Variable Inhalte erscheinen ausschließlich als Platzhalter in spitzen Klammern (Register in Anhang 31.3); offene Projektentscheidungen als `<TBD: …>`. Verweise der Form `.koolie/core/framework/core/…` bezeichnen Dateien des Referenz-Repositorys. Bestandteile der Laufzeitschicht werden im Fließtext mit **Begriffen** benannt (Wurzel-Anweisungsdatei, Regelablage, Berechtigungsdatei …); ihre Pfade je Client Pack führt Anhang 31.2.
+**Lesehinweise:** Verbindlichkeit wird durchgängig über MUSS / SOLL / KANN / DARF NICHT ausgedrückt; normative Abschnitte sind als solche gekennzeichnet, Erläuterungen tragen den Zusatz „(Erläuterung)", Beispiele sind stets „Beispiel (synthetisch)". Jede Aussage über Produktfunktionen eines KI-Clients trägt einen Belegstatus: `[DOK]` offiziell dokumentiert (Quellen in Anhang 31.4), `[EMPF]` technisch begründete, noch nicht in einer Installation ausgeführte Empfehlung, `[KONZ]` konzeptioneller Vorschlag ohne Produktbezug; offene Prüfpunkte tragen den Belegstand `BELEG OFFEN` mit Grund und Datum. Variable Inhalte erscheinen ausschließlich als Platzhalter in spitzen Klammern (Register in Anhang 31.3); offene Projektentscheidungen als `<TBD: …>`. Verweise der Form `.koolie/core/framework/core/…` bezeichnen Dateien des Referenz-Repositorys. Bestandteile der Laufzeitschicht werden im Fließtext mit **Begriffen** benannt (Wurzel-Anweisungsdatei, Regelablage, Berechtigungsdatei …); ihre Pfade je Client Pack führt Anhang 31.2.

package/.koolie/core/build/doc/01-executive-summary.md

@@ -1,24 +1,24 @@
 # 1 Executive Summary
 
-Dieses Dokument liefert ein projektneutrales, wiederverwendbares und erweiterbares Framework für den professionellen Einsatz von **KI-Codierassistenten** in Softwareentwicklungsteams – als methodisches Vorgehensmodell **und** als sofort nutzbare technische Referenzimplementierung in Form eines Repositorys. Erster Einsatzzweck ist die strukturierte Einführung des Werkzeugs und das Onboarding neuer Entwicklerinnen und Entwickler in einem bestehenden Projekt; die Übertragung auf weitere Teams und Projekte ist konstruktiv vorgesehen und beschränkt sich auf den Austausch einer einzigen Ebene, des Project Overlays.
+Dieses Dokument beschreibt ein projektneutrales, wiederverwendbares und erweiterbares Framework für den Einsatz von KI-Codierassistenten in Softwareentwicklungsteams: ein Vorgehensmodell und eine sofort nutzbare Referenzimplementierung als Repository. Erster Einsatzzweck ist die Einführung des Werkzeugs und das Onboarding neuer Entwicklerinnen und Entwickler in einem bestehenden Projekt. Für ein weiteres Team oder Projekt wird nur eine Ebene getauscht, das Project Overlay.
 
-**Der Kern ist werkzeugneutral, und das ist nachprüfbar gemeint.** Welcher Assistent zum Einsatz kommt, legt ein **Client Pack** fest (Kap. 7a) – eine Abbildungsschicht, die keine Regel einführt und keine lockert. Ausgeliefert werden vier: `claude-code`, `devin-desktop`, `openai-codex` und – mit Reifegrad `pilot` – `kiro`; die Regelmenge ist bei allen dieselbe. Jedes Pack führt eine **Fähigkeitsmatrix**: jede technische Zusage des Frameworks, eingestuft als `[TECHNISCH]` (die Engine erzwingt sie), `[TEXTUELL]` (nur Anweisung im Kontext) oder `[NICHT ABBILDBAR]`. Damit wird sichtbar, was ein Werkzeug tatsächlich durchsetzt – denn ein Framework, dessen Schutzzusagen bei einem Client von der Engine erzwungen werden und bei einem anderen nur als Prosa im Prompt stehen, erzeugt sonst falsche Sicherheit. Die Matrizen sind unterschiedlich lang, weil eine Zusage, für die ein Client keinen Mechanismus hat, bei ihm keine Zeile bekommt; ihre Gesamtzahlen lassen sich deshalb nicht vergleichen (Kap. 7a.3).
+**Der Kern ist werkzeugneutral.** Welcher Assistent zum Einsatz kommt, legt ein **Client Pack** fest (Kap. 7a), eine Abbildungsschicht, die keine Regel einführt und keine lockert. Ausgeliefert werden fünf: `claude-code`, `devin-desktop`, `openai-codex`, `kiro` und `cursor`, alle mit Reifegrad `pilot`; die Regelmenge ist bei allen dieselbe. Jedes Pack führt eine Fähigkeitsmatrix, die jede technische Zusage des Frameworks einstuft: `[TECHNISCH]` (die Engine erzwingt sie), `[TEXTUELL]` (nur Anweisung im Kontext) oder `[NICHT ABBILDBAR]`. So ist sichtbar, was ein Werkzeug tatsächlich durchsetzt und wo eine Schutzzusage nur als Text im Prompt steht. Die Matrizen sind unterschiedlich lang, weil eine Zusage ohne Mechanismus beim Client keine Zeile bekommt; ihre Gesamtzahlen lassen sich deshalb nicht vergleichen (Kap. 7a.3).
 
 Das Framework beantwortet die zehn Leitfragen des Auftrags so:
 
 - **Sicherer und kontrollierter Einsatz:** Vier Kontrollschichten wirken zusammen – organisationsweite Einstellungen, versionierte Repository-Konfiguration (Berechtigungen mit `deny`-Vorrang, Hooks, Regeln), Sitzungsdisziplin (rückfragender Standardmodus, Einzelbestätigungen) und menschliche Prüfung entlang bestehender Quality Gates.
-- **Was der Assistent darf**, regeln sechs Betriebsmodi (M1 Analyse bis M5 Dokumentation, dazu M6 für das Eintragen von Entscheidungen des Menschen in das Overlay – nur mit Mandat) in Verbindung mit einer dreistufigen Risikoklassifizierung (niedrig/mittel/hoch, Maximumprinzip über dreizehn Faktoren); **was er nie darf**, fixiert eine zwölfteilige Delegationsverbotsliste (Freigaben, Merges, Releases, Architekturentscheidungen, Secrets, Echtdaten und weitere).
-- **Kontext** wird über vier Klassen (K0–K3) aufgabenbezogen bereitgestellt – mit technischer Absicherung gegen die häufigsten Fehler.
+- **Was der Assistent darf**, regeln sechs Betriebsmodi (M1 Analyse bis M5 Dokumentation, dazu M6 für das Eintragen von Entscheidungen des Menschen in das Overlay, nur mit Mandat) zusammen mit einer dreistufigen Risikoklassifizierung (niedrig/mittel/hoch, Maximumprinzip über dreizehn Faktoren). **Was er nie darf**, legt eine Delegationsverbotsliste mit zwölf Punkten fest (Freigaben, Merges, Releases, Architekturentscheidungen, Secrets, Echtdaten und weitere).
+- **Kontext** wird über vier Klassen (K0–K3) aufgabenbezogen bereitgestellt, mit technischer Absicherung gegen die häufigsten Fehler.
 - **Regeln, Skills und Prompts** sind über eine Vier-plus-zwei-Ebenen-Architektur strukturiert (Framework Core, Role Packs, Technology Packs, Project Overlay, dazu Organisationsvorgaben und flüchtiger Aufgabenkontext) und über eine achtstufige, widerspruchsgeprüfte Prioritätshierarchie geordnet.
 - **Onboarding** erfolgt über ein Programm mit Übungen, Negativübungen (Ködern) und dokumentierter Freigabe.
 - **Prüfung und Freigabe** von KI-Ergebnissen laufen ausschließlich über die bestehenden Reviews und Gates, ergänzt um KI-spezifische Prüfpunkte.
 - **Versionierung, Pflege und Übertragung** regelt ein Governance-Betriebsmodell mit Release-Prozess, Testkatalog und Übernahmeleitfaden.
 - **Nutzen und Risiken** misst ein Pilotkonzept mit ausdrücklich projektspezifisch festzulegenden Zielwerten.
 
-Die Referenzimplementierung liefert die zentrale Agentenanweisung, eine vollständige Project-Overlay-Vorlage mit Manifest-Mechanismus für dreizehn projektspezifische Dokumenttypen, zwölf Referenz-Skills mit Testfällen, ein Role Pack mit einem dreizehnten Skill, zwölf Prompt-Vorlagen, elf Checklisten, sechs validierte Entscheidungsbäume, das Onboarding-Paket, einen Testkatalog mit Prüf-Skripten sowie RACI-, Prozess- und Roadmap-Vorlagen. Die **Laufzeitschicht** – das, was der Assistent tatsächlich liest – wird dabei nicht von Hand gepflegt, sondern bei der Installation aus dem Kern in die Form des gewählten Client Packs erzeugt. Installiert wird über einen Starter für Windows oder macOS, der Projektverzeichnis, Client Pack und auf Wunsch ein Overlay-Muster abfragt und den Kern in das Projekt kopiert (Kap. 15.2, 28).
+Die Referenzimplementierung liefert die zentrale Agentenanweisung, eine Project-Overlay-Vorlage mit Manifest für dreizehn projektspezifische Dokumenttypen, dreizehn Referenz-Skills mit Testfällen, ein Role Pack mit einem weiteren Skill, zwölf Prompt-Vorlagen, elf Checklisten, sechs Entscheidungsbäume, das Onboarding-Paket, einen Testkatalog mit Prüfskripten sowie RACI-, Prozess- und Roadmap-Vorlagen. Die **Laufzeitschicht**, also das, was der Assistent tatsächlich liest, wird nicht von Hand gepflegt, sondern bei der Installation aus dem Kern in der Form des gewählten Client Packs erzeugt. Installiert wird über eine Paketquelle (`uvx koolie`, `npx @renoxar/koolie`) oder einen Starter für Windows oder macOS; beide fragen Projektverzeichnis, Client Pack und auf Wunsch ein Overlay-Muster ab und kopieren den Kern in das Projekt (Kap. 15.2, 28).
 
-**Was das Framework kostet, ist gemessen** (Kap. 28, Abschnitt 7): Eine kleine Aufgabe wird mit dem Framework rund zwei- bis dreimal so teuer, eine größere rund doppelt so teuer – bei Listenpreisen von 2026-09-26 einige Cent je Aufgabe. Die feste Last je Modellaufruf (4.400 bis 15.000 Token je Client Pack) kommt fast immer aus dem Cache; den Unterschied macht die Arbeitsweise – Fundstellen, Skill, Ergebnisbericht. **Und die Schutzschicht wirkt nur für eine Sitzung, die im Verzeichnis der Installation startet**; bei mehreren Repositories gehört je Repository eine Installation dazu (Kap. 28, Abschnitt 4).
+**Kosten** (gemessen, Kap. 28, Abschnitt 7): Eine kleine Aufgabe wird mit dem Framework rund zwei- bis dreimal so teuer, eine größere rund doppelt so teuer, bei Listenpreisen von 2026-09-26 einige Cent je Aufgabe. Die feste Last je Modellaufruf (4.400 bis 15.000 Token je Client Pack) kommt fast immer aus dem Cache; den Unterschied macht die Arbeitsweise mit Fundstellen, Skill und Ergebnisbericht. Die Schutzschicht wirkt nur für eine Sitzung, die im Verzeichnis der Installation startet; bei mehreren Repositories braucht jedes eine eigene Installation (Kap. 28, Abschnitt 4).
 
-**Wesentliche Grenze der Aussagen:** Die fünf Fähigkeitsmatrizen sind unterschiedlich weit belegt. Für `devin-desktop` ist die Validierung an einer realen Installation (Roadmap-AP2) abgeschlossen; offen ist genau eine Zeile, und zwar dauerhaft, weil ihre Frage von außen nicht beobachtbar ist. Für `claude-code` liegt ein Abgleich mit der Herstellerdokumentation einer benannten Clientversion vor, dazu Messungen für einen Teil der Zeilen; die übrigen Wirkungsnachweise stehen aus. Für `openai-codex` stammen alle Belege aus Messungen am Client selbst; einige Zeilen sind noch offen, und eine Beobachtung der Herstellerdokumentation fehlt. Für `kiro` ist die Kommandozeile gemessen, die Zeilen der IDE sind es nicht, und die Hooks laufen nur in der interaktiven Sitzung. Für `cursor` ist die Kommandozeile unter Windows gemessen; die Zeilen der IDE und die Schreibweise der Pfadmuster für macOS und Linux sind es nicht. Welche Zeile wie belegt ist, sagt die Belegspalte der jeweiligen Matrix. Alle produktbezogenen Aussagen tragen Belegstatus; Offenes sagt `BELEG OFFEN` **mit Grund und Datum und ohne Frist** – ein Belegstand sagt, was heute belegt ist, nicht, bis wann es belegt sein muss.
+**Wesentliche Grenze der Aussagen:** Die fünf Fähigkeitsmatrizen sind unterschiedlich weit belegt. Für `devin-desktop` ist die Validierung an einer realen Installation abgeschlossen; offen ist genau eine Zeile, und zwar dauerhaft, weil ihre Frage von außen nicht beobachtbar ist. Für `claude-code` liegt ein Abgleich mit der Herstellerdokumentation einer benannten Clientversion vor, dazu Messungen für einen Teil der Zeilen; die übrigen Wirkungsnachweise stehen aus. Für `openai-codex` stammen alle Belege aus Messungen am Client selbst; einige Zeilen sind noch offen, und eine Beobachtung der Herstellerdokumentation fehlt. Für `kiro` ist die Kommandozeile gemessen, die Zeilen der IDE sind es nicht, und die Hooks laufen nur in der interaktiven Sitzung. Für `cursor` ist die Kommandozeile unter Windows gemessen; die Zeilen der IDE und die Schreibweise der Pfadmuster für macOS und Linux sind es nicht. Welche Zeile wie belegt ist, sagt die Belegspalte der jeweiligen Matrix. Alle produktbezogenen Aussagen tragen Belegstatus; Offenes trägt `BELEG OFFEN` mit Grund und Datum, ohne Frist.
 
-**Empfohlene nächste Schritte für ein aufnehmendes Projekt:** Rollen besetzen und Datenschutz-/Vertragsprüfung beauftragen (AP1), Client Pack wählen und Overlay ausfüllen (AP4), Sicherheits- und Datenschutzfreigabe einholen (AP6) – der Weg steht in Kap. 30 und im Abschlussteil.
+**Nächste Schritte für ein aufnehmendes Projekt:** Rollen besetzen und Datenschutz- und Vertragsprüfung beauftragen (AP1), Client Pack wählen und Overlay ausfüllen (AP4), Sicherheits- und Datenschutzfreigabe einholen (AP6). Der Weg steht in Kap. 30 und im Abschlussteil.

package/.koolie/core/build/doc/03-ziele-nichtziele.md

@@ -20,9 +20,9 @@
 |---|---|---|
 | N1 | Maximierung des Automatisierungsgrads oder „autonome" Entwicklung | Human Accountability ist Grundprinzip; Autonomie-Modi sind untersagt beziehungsweise ausnahmepflichtig |
 | N2 | Ersatz bestehender Prozesse, Reviews, Gates oder Rollen | Das Framework ergänzt; es ersetzt nichts (P6) |
-| N3 | Rechtliche Bewertung oder Compliance-Freigabe (Datenschutzrecht, Lizenzrecht, KI-Regulierung) | Liegt bei den zuständigen Rollen der Organisation; das Framework liefert operative Anschlusspunkte und benennt Prüfbedarfe (K-06) |
+| N3 | Rechtliche Bewertung oder Compliance-Freigabe (Datenschutzrecht, Lizenzrecht, KI-Regulierung) | Liegt bei den zuständigen Rollen der Organisation; das Framework liefert operative Anschlusspunkte und benennt Prüfbedarfe |
 | N4 | Bewertung oder Überwachung von Personen anhand von Nutzungs- oder Pilotdaten | Ausdrücklich ausgeschlossen (V7, Metrik-Grundsätze) |
 | N5 | Produktdokumentation oder Schulung für einen KI-Client als Produkt | Das Framework referenziert die offizielle Dokumentation; es dupliziert sie nicht |
 | N6 | Vollständige technologie- oder branchenspezifische Regelwerke in der Erstfassung | Technology Packs entstehen projektbezogen; die Struktur dafür ist Teil des Frameworks |
-| N7 | Abdeckung anderer Einsatzformen (Cloud-Sitzungen, Läufe ohne beobachtende Person, Fremdagenten) im Kern der Erstfassung | Als Erweiterung vorgesehen, standardmäßig deaktiviert (D-10, D-386, K-04). Ein Kommandozeilen-Client in einer beobachteten Sitzung gehört zum Kern |
+| N7 | Abdeckung anderer Einsatzformen (Cloud-Sitzungen, Läufe ohne beobachtende Person, Fremdagenten) im Kern der Erstfassung | Als Erweiterung vorgesehen, standardmäßig deaktiviert. Ein Kommandozeilen-Client in einer beobachteten Sitzung gehört zum Kern |
 | N8 | Garantie fehlerfreier KI-Ergebnisse | Unerreichbar; das Framework macht Fehler früh sichtbar und begrenzt ihre Wirkung |

package/.koolie/core/build/doc/04-geltungsbereich.md

@@ -4,7 +4,7 @@
 
 Das Framework gilt für den Einsatz eines **KI-Codierassistenten** in Softwareentwicklungsprojekten mit Git-basiertem Entwicklungsprozess und den im verfügbaren Kontext genannten generischen Werkzeugklassen (Issue Tracking wie `<ISSUE_TRACKER>`, Git-Repository, Merge beziehungsweise Pull Requests, `<CI_CD_PLATFORM>`, statische Codeanalyse, automatisierte Tests, technische Dokumentation, Teamkommunikation und Wissensmanagement). Es umfasst Governance, Datenschutz- und Sicherheitsmodell, Arbeitsmodell, Skills, Prompts, Checklisten, Entscheidungsbäume, Onboarding, Framework-Qualitätssicherung, Pilotierung und Übernahme.
 
-Vorausgesetzt ist die **lokale, beobachtete** Nutzung: Der Assistent läuft in der Entwicklungsumgebung, eine Person verfolgt die Sitzung. Nicht Teil des Kerngeltungsbereichs – strukturell vorbereitet und standardmäßig deaktiviert (D-10, `<TBD: Freigabe Cloud/CLI-Nutzung>`): Cloud-Sitzungen, nicht-interaktive Läufe ohne beobachtende Person (auch die eines Kommandozeilen-Clients), automatisierte Reviews, Fremdagenten über offene Agentenprotokolle sowie Hintergrundläufe. Ausgeschlossen ist damit der Betrieb ohne beobachtende Person, nicht eine Oberfläche: Ein Kommandozeilen-Client in einer interaktiven Sitzung, die eine Person verfolgt, gehört zum Kerngeltungsbereich (D-386). Eine Freigabe dieser Formen erfordert eine Erweiterung des Sicherheitsmodells über den Änderungsprozess.
+Vorausgesetzt ist die **lokale, beobachtete** Nutzung: Der Assistent läuft in der Entwicklungsumgebung, eine Person verfolgt die Sitzung. Nicht Teil des Kerngeltungsbereichs, strukturell vorbereitet und standardmäßig deaktiviert (`<TBD: Freigabe Cloud/CLI-Nutzung>`): Cloud-Sitzungen, nicht-interaktive Läufe ohne beobachtende Person (auch die eines Kommandozeilen-Clients), automatisierte Reviews, Fremdagenten über offene Agentenprotokolle sowie Hintergrundläufe. Ausgeschlossen ist damit der Betrieb ohne beobachtende Person, nicht eine Oberfläche: Ein Kommandozeilen-Client in einer interaktiven Sitzung, die eine Person verfolgt, gehört zum Kerngeltungsbereich. Eine Freigabe dieser Formen erfordert eine Erweiterung des Sicherheitsmodells über den Änderungsprozess.
 
 **Welcher** Assistent zum Einsatz kommt, legt das gewählte Client Pack fest (Kap. 7a). Der Geltungsbereich ist davon unabhängig; die Durchsetzungstiefe der Zusagen ist es nicht – sie steht in der Fähigkeitsmatrix des Packs und ist vor Inbetriebnahme zu bewerten.
 
@@ -14,12 +14,12 @@ Es gilt für alle Personen, die im Geltungsbereich eines aktiven Project Overlay
 
 ## 4.3 Organisatorisch und zeitlich
 
-Je Projekt wird der Geltungsbereich durch das Project Overlay konkretisiert (Repositorys, Pfade, Rollen, Freigaben); ohne aktives Overlay ist produktiver Einsatz unzulässig (nur Onboarding-Übungen auf dem synthetischen Übungsrepository). Voraussetzungen auf Organisationsebene – Werkzeugfreigabe, Datenschutz- und Vertragsprüfung, administrativ gesetzte Team-Einstellungen – sind Eingangsbedingungen (Klärungspunkte K-04 bis K-06) und werden über die Ebene der Organisationsvorgaben eingebunden. Das Framework gilt ab Übernahme (Adoption) in der jeweils referenzierten Release-Version bis zur Deaktivierung des Overlays.
+Je Projekt wird der Geltungsbereich durch das Project Overlay konkretisiert (Repositorys, Pfade, Rollen, Freigaben); ohne aktives Overlay ist produktiver Einsatz unzulässig (nur Onboarding-Übungen auf dem synthetischen Übungsrepository). Voraussetzungen auf Organisationsebene – Werkzeugfreigabe, Datenschutz- und Vertragsprüfung, administrativ gesetzte Team-Einstellungen – sind Eingangsbedingungen (offene Klärungspunkte, Kap. 29.2) und werden über die Ebene der Organisationsvorgaben eingebunden. Das Framework gilt ab Übernahme (Adoption) in der jeweils referenzierten Release-Version bis zur Deaktivierung des Overlays.
 
 ## 4.4 Produktstand und Grenzen der Aussagen
 
 Das Framework legt keinen Produktstand fest – ein Client Pack tut es. Jedes Pack nennt in seinem Kopf die **geprüfte Clientversion** und das Datum der Prüfung; ohne diese Angabe ist keine Einstufung `[TECHNISCH]` zulässig (Kap. 7a).
 
-Für das in diesem Dokument durchgehend verwendete Pack `devin-desktop` stehen die verbindliche Zielspanne, die geprüfte Punktversion, das Datum der Prüfung und der Stand der Produktbeobachtung **im Pack selbst** (Kap. 15.1). Sie stehen dort und nicht hier, weil sie sich mit dem Produkt ändern: Die Zielspanne ist der *geprüfte* Geltungsbereich und nicht der aktuelle Produktstand, und das Pack weist den Abstand zwischen beiden ausdrücklich aus, damit die Spanne nicht als „aktuell" gelesen wird.
+Für das in diesem Dokument durchgehend verwendete Pack `devin-desktop` stehen Zielspanne, geprüfte Punktversion, Prüfdatum und Stand der Produktbeobachtung im Pack selbst (Kap. 15.1), weil sie sich mit dem Produkt ändern. Die Zielspanne ist der geprüfte Geltungsbereich, nicht der aktuelle Produktstand; das Pack weist den Abstand zwischen beiden aus.
 
-Alle produktbezogenen Aussagen tragen Belegstatus. **Die verbindliche Zielversion jedes ausgelieferten Packs ist festgelegt** (D-112). Wie weit seine Zeilen belegt sind, ist je Pack verschieden (Kap. 1, 7a.3); welche Zeile wie weit belegt ist, sagt die Belegspalte der jeweiligen Matrix – je Zeile, nicht als Gesamturteil.
+Alle produktbezogenen Aussagen tragen Belegstatus. Die verbindliche Zielversion jedes ausgelieferten Packs ist festgelegt. Wie weit seine Zeilen belegt sind, ist je Pack verschieden (Kap. 1, 7a.3); welche Zeile wie weit belegt ist, sagt die Belegspalte der jeweiligen Matrix – je Zeile, nicht als Gesamturteil.

package/.koolie/core/build/doc/05-glossar.md

@@ -6,11 +6,11 @@
 | Client Pack | Abbildungsschicht für genau einen KI-Client: Pfadabbildung, Semantikabbildung und Fähigkeitsmatrix (Kap. 7a). Keine Regelebene |
 | Fähigkeitsmatrix | Einstufung jeder technischen Zusage des Frameworks je Client: `[TECHNISCH]` erzwungen · `[TEXTUELL]` nur Anweisung · `[NICHT ABBILDBAR]`. Die Zeilenzahl ist je Pack verschieden – ein Client, der für eine Zusage keinen Mechanismus hat, bekommt dafür auch keine Zeile (Kap. 7a.3) |
 | Kernzusage B1–B6 | Die sechs Zusagen, die dem Integritätsblock der Berechtigungsdatei entsprechen; eine Abweichung von `[TECHNISCH]` ist begründungs- und freigabepflichtig |
-| `claude-code` · `devin-desktop` · `openai-codex` | Die drei ausgelieferten Client Packs. **Welches Produkt, welcher Agent und welche geprüfte Version dahinterstehen, nennt der Kopf des jeweiligen Packs** (Kap. 7a.3, 15.1) – dieser Kern nennt es nicht, weil er sich sonst mit dem Produkt änderte (D-02, D-129). In diesem Dokument ist `devin-desktop` das durchgehende Beispiel |
+| `claude-code` · `devin-desktop` · `openai-codex` · `kiro` · `cursor` | Die fünf ausgelieferten Client Packs. Welches Produkt, welcher Agent und welche geprüfte Version dahinterstehen, nennt der Kopf des jeweiligen Packs (Kap. 7a.3, 15.1); der Kern nennt es nicht, weil er sich sonst mit dem Produkt änderte. In diesem Dokument ist `devin-desktop` das durchgehende Beispiel |
 | Wurzel-Anweisungsdatei | zentrale Agentenanweisung im Wurzelverzeichnis; wird zu Beginn jeder Sitzung geladen `[DOK]`. Dateiname je Client Pack (Anhang 31.2) |
-| Regel (Rule) | Markdown-Datei in der Regelablage mit Ladebedingung. Quellform: Frontmatter `description`, `trigger` (`always_on`, `model_decision`, `glob`, `manual`, `agent`) und bei `glob` zusätzlich `globs`. Die Ladebedingung wird bei der Installation auf die Bedingungssprache des Clients abgebildet (D-27); welche das ist, steht im Client Pack `[DOK]` |
+| Regel (Rule) | Markdown-Datei in der Regelablage mit Ladebedingung. Quellform: Frontmatter `description`, `trigger` (`always_on`, `model_decision`, `glob`, `manual`, `agent`) und bei `glob` zusätzlich `globs`. Die Ladebedingung wird bei der Installation auf die Bedingungssprache des Clients abgebildet; welche das ist, steht im Client Pack `[DOK]` |
 | Skill | versionierte, testbare Arbeitsanweisung in der Skill-Ablage (`<name>/SKILL.md`); Aufruf `/name` `[DOK]`; Standard in Kap. 18 |
-| Subagent | eigenständiges Agentenprofil für abgegrenzte Teilaufgaben `[DOK]`; im Framework nur das lesende Profil `fw-reviewer` |
+| Subagent | eigenständiges Agentenprofil für abgegrenzte Teilaufgaben `[DOK]`; im Framework nur das lesende Profil `koolie-reviewer` |
 | Hook | konfigurierter Eingriffspunkt im Agenten-Lebenszyklus (Hook-Konfiguration), kann Aktionen blockieren `[DOK]` |
 | Permission-Modus | Bestätigungsverhalten des Clients; Framework-Standard ist der Modus, der bei Schreiben und Befehlen rückfragt. Bezeichnungen je Client (bei `devin-desktop`: Normal, Accept Edits, Smart, Bypass, Autonomous `[DOK]`) |
 | Berechtigungsregeln | `deny`/`ask`/`allow`-Regeln in der Berechtigungsdatei; `deny` gewinnt immer `[DOK]`. Die Regelmenge liegt werkzeugneutral im Kern, die Werkzeugnamen entstehen aus der Semantikabbildung (Kap. 7a) |

package/.koolie/core/build/doc/07-architektur.md

@@ -39,11 +39,11 @@ Allgemeingültige Regeln in elf Modulen – FW-CORE-00 bis FW-CORE-10: 00 Leitpr
 
 ## 7.3 Ebene 6 – Role Packs (optional, rollenbezogen)
 
-Module je Tätigkeit. **Ausgeliefert werden zwei:** Softwareentwicklung als Referenzpack (`RP-DEV`) und Requirements Engineering (`RP-RE`) mit dem Skill `role-re-ticket` – dem dreizehnten Skill des Frameworks und dem einzigen, der nicht aus dem Kern stammt. Softwarearchitektur, Testing und QA, DevOps, Dokumentation und Code Review sind strukturell vorgesehen. Ein Role Pack konkretisiert Arbeitsweise, typische Aufgaben mit Modus- und Stufenzuordnung, rollenspezifische Kontextquellen, Prüfpunkte und gegebenenfalls Skills (`role-<pack>-…`). Es enthält keine Governance-Regeln und keine Projektwerte; Aktivierung erfolgt je Projekt über das Overlay; die Laufzeitfassung `30-*` lädt bei Relevanz; kennt ein Client keine modellentschiedene Ladebedingung, lädt sie dort unbedingt.
+Module je Tätigkeit. **Ausgeliefert werden zwei:** Softwareentwicklung als Referenzpack (`RP-DEV`) und Requirements Engineering (`RP-RE`) mit dem Skill `koolie-ticket`, dem einzigen Skill, der nicht aus dem Kern stammt. Softwarearchitektur, Testing und QA, DevOps, Dokumentation und Code Review sind strukturell vorgesehen. Ein Role Pack konkretisiert Arbeitsweise, typische Aufgaben mit Modus- und Stufenzuordnung, rollenspezifische Kontextquellen, Prüfpunkte und gegebenenfalls Skills (`koolie-…`). Es enthält keine Governance-Regeln und keine Projektwerte; Aktivierung erfolgt je Projekt über das Overlay; die Laufzeitfassung `30-*` lädt bei Relevanz; kennt ein Client keine modellentschiedene Ladebedingung, lädt sie dort unbedingt.
 
 ## 7.4 Ebene 5 – Technology Packs (optional, technologiebezogen)
 
-Module je Technologieaspekt (Programmiersprache, Anwendungsframework, Build-System, Testframework, Datenbank, API-Technologie, Frontend, Backend, Container, CI/CD). Inhalt: Konventionen und Idiome, Testkonventionen, typische Fehlerquellen KI-generierten Codes in dieser Technologie, technologiespezifische Sicherheitsmuster, gegebenenfalls Skills (`tech-<pack>-…`). Die Laufzeitfassung `40-*` bindet sich an die Dateimuster der Technologie und lädt genau dann, wenn passende Dateien berührt werden `[DOK]` – vorausgesetzt, der Client kennt an Dateimuster gebundene Regeln. Ein Client ohne diesen Mechanismus braucht einen der Ersatzwege aus seiner Fähigkeitsmatrix. Ausgeliefert wird bewusst eine Vorlage statt eines konkreten Packs; das erste Pack für `<TECH_STACK>` entsteht in Roadmap-AP4.
+Module je Technologieaspekt (Programmiersprache, Anwendungsframework, Build-System, Testframework, Datenbank, API-Technologie, Frontend, Backend, Container, CI/CD). Inhalt: Konventionen und Idiome, Testkonventionen, typische Fehlerquellen KI-generierten Codes in dieser Technologie, technologiespezifische Sicherheitsmuster, gegebenenfalls Skills (`koolie-…`). Die Laufzeitfassung `40-*` bindet sich an die Dateimuster der Technologie und lädt genau dann, wenn passende Dateien berührt werden `[DOK]` – vorausgesetzt, der Client kennt an Dateimuster gebundene Regeln. Ein Client ohne diesen Mechanismus braucht einen der Ersatzwege aus seiner Fähigkeitsmatrix. Ausgeliefert wird bewusst eine Vorlage statt eines konkreten Packs; das erste Pack für `<TECH_STACK>` entsteht in Roadmap-AP4.
 
 ## 7.5 Ebene 4 – Project Overlay (ausschließlich projektspezifisch)
 

package/.koolie/core/build/doc/07a-abbildungsschicht.md

@@ -26,27 +26,27 @@ Kern jedes Client Packs. Sie stuft jede technische Zusage des Frameworks in eine
 
 Sechs dieser Zusagen sind **Kernzusagen** (B1 bis B6) und entsprechen dem Integritätsblock der Berechtigungsdatei. Weicht eine von `[TECHNISCH]` ab, ist sie im Pack einzeln zu begründen, im Overlay als Ausnahme zu führen und durch `<SECURITY_CONTACT>` freizugeben.
 
-Dieses Dokument verwendet `devin-desktop` als durchgehendes Beispiel; seine Matrix steht in Kap. 15.1. Zum Vergleich hier die beiden anderen Packs – derselbe Kern, andere Clients. Zuerst `claude-code`:
+Dieses Dokument verwendet `devin-desktop` als durchgehendes Beispiel; seine Matrix steht in Kap. 15.1. Zum Vergleich folgen zwei weitere Packs, derselbe Kern an anderen Clients. Zuerst `claude-code`:
 
 {{EMBED-RAW:.koolie/core/clients/claude-code/CLIENT_PACK.md:1}}
-Dann `openai-codex`, dessen Belege durchweg Messungen sind (D-396):
+Dann `openai-codex`, dessen Belege durchweg Messungen sind:
 
 {{EMBED-RAW:.koolie/core/clients/openai-codex/CLIENT_PACK.md:1}}
-Der Vergleich der Matrizen ist die Probe aufs Exempel: `devin-desktop` und `claude-code` bilden alle sechs Kernzusagen ab – **drei davon technisch in jedem Zugriffskanal** (B1, B2, B6), drei nur für den direkten Zugriff (B3, B4, B5); für Shell und Unterprozess tragen sie die Regelschicht. Bei `openai-codex` sind B3 und B5 `[NICHT ABBILDBAR]`; das Pack begründet es, und ein Projekt braucht dafür eine dokumentierte Ausnahme mit Freigabe durch `<SECURITY_CONTACT>` (siehe oben).
+Im Vergleich: `devin-desktop` und `claude-code` bilden alle sechs Kernzusagen ab, drei davon technisch in jedem Zugriffskanal (B1, B2, B6), drei nur für den direkten Zugriff (B3, B4, B5); für Shell und Unterprozess trägt dort die Regelschicht. Bei `openai-codex` sind B3 und B5 `[NICHT ABBILDBAR]`; das Pack begründet es, und ein Projekt braucht dafür eine dokumentierte Ausnahme mit Freigabe durch `<SECURITY_CONTACT>` (siehe oben).
 
-**Ein Vergleich der Gesamtzahlen trägt dagegen nicht, und das hat zwei Gründe.** Erstens sind die Matrizen unterschiedlich lang. Zweitens – und das wiegt schwerer – **messen die Zahlen Verschiedenes:** Die Belege sind auf verschiedenen Wegen gewonnen – durch Beobachtung an einer laufenden Installation, durch Messung am Client oder durch Abgleich mit der Herstellerdokumentation –, und welcher Weg für eine Zeile gilt, sagt ihre Belegspalte. Bei `claude-code` ist der Beleg überwiegend ein Dokumentenabgleich, bei `openai-codex` durchweg eine Messung. **Ein Dokumentenabgleich belegt `[DOK]`, nicht `[TECHNISCH]` im Sinne einer beobachteten Wirkung.** Die Summen stehen in Abschnitt 3 jedes Packs; Prüfung 31 rechnet sie bei jedem Validatorlauf aus der Matrix nach.
+**Ein Vergleich der Gesamtzahlen trägt dagegen nicht.** Die Matrizen sind unterschiedlich lang, und die Zahlen messen Verschiedenes: Die Belege stammen aus Beobachtung an einer laufenden Installation, aus Messung am Client oder aus dem Abgleich mit der Herstellerdokumentation; welcher Weg für eine Zeile gilt, sagt ihre Belegspalte. Bei `claude-code` ist der Beleg überwiegend ein Dokumentenabgleich, bei `openai-codex` durchweg eine Messung. **Ein Dokumentenabgleich belegt `[DOK]`, nicht `[TECHNISCH]` im Sinne einer beobachteten Wirkung.** Die Summen stehen in Abschnitt 3 jedes Packs; Prüfung 31 rechnet sie bei jedem Validatorlauf aus der Matrix nach.
 
 ## 7a.4 Form und Semantik
 
-Ein Client Pack enthält **drei Dateien** – die Fähigkeitsmatrix `CLIENT_PACK.md`, die maschinenlesbare Abbildung `manifest.json` und eine erklärende README der Laufzeitschicht unter `root-template/`. Alles Übrige liegt einmal im Kern und wird bei der Installation übersetzt. Dabei sind zwei Fälle zu unterscheiden, und der Unterschied ist wesentlich:
+Ein Client Pack enthält drei Dateien: die Fähigkeitsmatrix `CLIENT_PACK.md`, die maschinenlesbare Abbildung `manifest.json` und eine erklärende README der Laufzeitschicht unter `root-template/`. Alles Übrige liegt einmal im Kern und wird bei der Installation übersetzt. Dabei gibt es zwei Fälle:
 
 **Formtransformation.** Der Inhalt ist derselbe, nur die Schreibweise unterscheidet sich – ein Frontmatter-Feld heißt anders, eine Werkzeugliste ist kommagetrennt statt eingerückt. Das betrifft Regeltexte, Wurzel-Anweisung, Agentenprofil, Skills und die Vorlagen.
 
-Die Ladebedingung einer Regel ist dagegen **keine** Formfrage, sondern eine zweite Semantikabbildung (D-27): Die Kernquelle kennt fünf Ladetrigger, ein Client kennt seine eigene Bedingungssprache. Bei `claude-code` heißt sie `paths` und bindet eine Regel an Glob-Muster; `always_on` und `model_decision` bilden dort auf unbedingtes Laden ab – eine Verschärfung. Ein Ladetrigger ohne Eintrag in der Abbildung lässt die Installation scheitern; er wird nicht verworfen.
+Die Ladebedingung einer Regel ist dagegen keine Formfrage, sondern eine zweite Semantikabbildung: Die Kernquelle kennt fünf Ladetrigger, ein Client kennt seine eigene Bedingungssprache. Bei `claude-code` heißt sie `paths` und bindet eine Regel an Glob-Muster; `always_on` und `model_decision` bilden dort auf unbedingtes Laden ab – eine Verschärfung. Ein Ladetrigger ohne Eintrag in der Abbildung lässt die Installation scheitern; er wird nicht verworfen.
 
 **Semantikabbildung.** Die Werkzeuge selbst unterscheiden sich. Ein Client trennt Ändern und Anlegen in zwei Werkzeuge, ein anderer nicht; Befehlsverbote greifen hier wörtlich (`Exec(git reset --hard)`) und dort präfixbasiert (`Bash(git reset:*)`); Netzzugriff ist einmal ein Werkzeug mit Muster und einmal zwei ohne. Das betrifft Berechtigungen und Hooks – und damit genau die Regeln, an denen die Kernzusagen hängen.
 
-Für den zweiten Fall genügt Sorgfalt nicht. Eine beim Nachziehen vergessene Regel wäre eine stille Lücke, während die Fähigkeitsmatrix weiterhin `[TECHNISCH]` behauptet. Die Abbildung erzwingt deshalb drei Eigenschaften und bricht die Installation ab, wenn eine verletzt ist:
+Eine beim Nachziehen vergessene Regel wäre hier eine stille Lücke, während die Fähigkeitsmatrix weiter `[TECHNISCH]` behauptet. Die Abbildung erzwingt deshalb drei Eigenschaften und bricht die Installation ab, wenn eine verletzt ist:
 
 | Zusicherung | Warum |
 |---|---|
@@ -61,6 +61,6 @@ Die werkzeugneutrale Regelmenge, aus der jedes Pack seine Berechtigungen erzeugt
 {{EMBED:.koolie/core/framework/runtime/permissions.json:json}}
 ## 7a.5 Was das für ein Projekt bedeutet
 
-Die Wahl des Client Packs fällt bei der Erstinstallation (`install.py --client`; der Dialog der Starter fragt sie ab, Kap. 15.2) und wird im Overlay dokumentiert. Sie ist keine Geschmacksfrage: Bevor ein Pack in Betrieb geht, ist seine Fähigkeitsmatrix zu lesen und jede Kernzusage ohne technische Durchsetzung freizugeben. Ein Wechsel des Clients ist ein eigener Vorgang mit erneuter Bewertung – nicht ein Schalter.
+Die Wahl des Client Packs fällt bei der Erstinstallation (`install.py --client`; der Dialog fragt sie ab, Kap. 15.2) und wird im Overlay dokumentiert. Bevor ein Pack in Betrieb geht, ist seine Fähigkeitsmatrix zu lesen und jede Kernzusage ohne technische Durchsetzung freizugeben. Ein Wechsel des Clients ist ein eigener Vorgang mit erneuter Bewertung.
 
-Für ein weiteres Client Pack ist Roadmap-AP2 mit der Fähigkeitsmatrix des neuen Packs zu wiederholen. Solange dessen Zielversion nicht festgelegt und geprüft ist, gilt das Pack als **unbelegt**.
+Ein neues Client Pack durchläuft dieselbe Validierung an einer realen Installation (Roadmap-AP2) mit seiner eigenen Fähigkeitsmatrix. Solange seine Zielversion nicht festgelegt und geprüft ist, gilt es als unbelegt.

package/.koolie/core/build/doc/08-trennung.md

@@ -2,7 +2,7 @@
 
 ## 8.1 Das Trennprinzip
 
-Die Wiederverwendbarkeit des Frameworks steht und fällt mit einer harten Regel: **Ein Projektwechsel tauscht ausschließlich Ebene 4 (Project Overlay); er darf niemals Anpassungen am Framework Core erzwingen.** Umgekehrt enthält der Core keine einzige projektspezifische Angabe – wo er Projektwissen braucht, definiert er eine benannte Schnittstelle in Form eines registrierten Platzhalters (`<ALLOWED_PATHS>`, `<TEST_COMMAND>`, `<APPROVAL_ROLE>` …), die das Overlay füllt.
+Die Wiederverwendbarkeit hängt an einer Regel: **Ein Projektwechsel tauscht ausschließlich Ebene 4 (Project Overlay); er darf nie Anpassungen am Framework Core erzwingen.** Umgekehrt enthält der Core keine projektspezifische Angabe; wo er Projektwissen braucht, definiert er eine benannte Schnittstelle in Form eines registrierten Platzhalters (`<ALLOWED_PATHS>`, `<TEST_COMMAND>`, `<APPROVAL_ROLE>` …), die das Overlay füllt.
 
 ## 8.2 Mechanik der Trennung
 
@@ -10,7 +10,7 @@ Die Wiederverwendbarkeit des Frameworks steht und fällt mit einer harten Regel:
 |---|---|
 | Platzhalter-Schnittstellen (Anhang 31.3) | Core-Regeln bleiben generisch formulierbar; Projekte füllen Werte ausschließlich im Overlay und in der Berechtigungsdatei |
 | Verschärfungsprinzip (Kap. 25) | Das Overlay darf konkretisieren und verschärfen, nie lockern – Core-Garantien gelten damit projektübergreifend |
-| Getrennte Ablage und Ownership | Core: Framework Owner über Releases; Overlay: Overlay Owner über den Projektprozess; technische Schreibsperren (`Write(.koolie/core/**)` – das Kernverzeichnis als Ganzes, einschließlich der Skripte, die die Schutzzusagen durchsetzen –, dazu Laufzeitschicht, Wurzel-Anweisungsdatei und `Write(.koolie/project-overlay/**)` als `deny`) |
+| Getrennte Ablage und Ownership | Core: Framework Owner über Releases; Overlay: Overlay Owner über den Projektprozess; technische Schreibsperren: `Write(.koolie/core/**)` für das ganze Kernverzeichnis einschließlich der Skripte, die die Schutzzusagen durchsetzen, dazu Laufzeitschicht und Wurzel-Anweisungsdatei als `deny`; das Overlay sperrt der Schutz-Hook, solange kein Mandat es deckt |
 | Dokumenten-Manifest | Projektwissen wird als registriertes Dokument mit Klasse und Ladeverhalten eingebunden – nie durch Editieren von Core-Dateien (Kap. 17) |
 | Integritätsprüfung | `validate-framework.py` prüft unter anderem, dass die Kernregeln in der Berechtigungsdatei unverändert enthalten sind (`_core_rules_integrity`) und Overlay-Pflichtfelder gefüllt sind (`--strict-overlay`) |
 | Release-Abgleich | Bei Übernahme und Aktualisierung werden Core-Bestandteile byte-gleich aus dem Release übernommen (Adoption Guide, CL-10/CL-11) |
@@ -21,4 +21,4 @@ Regeln mit gemischtem Charakter werden getrennt: die generische Logik wandert mi
 
 ## 8.4 Nachweis der Trennung
 
-Alle versionierten Markdown-Dateien des Kerns – beim Bau dieses Dokuments {{ZAHL:*.md}} – werden bei jedem Validatorlauf automatisiert auf Projektneutralität geprüft (Sperrbegriffs-, E-Mail-, IP-, Hostnamen- und URL-Prüfungen; Kap. 26). **Der Validator prüft zusätzlich die Werkzeugneutralität selbst:** Kein anweisender Träger des Kerns nennt einen Produktnamen oder einen Pfad, der genau einem Client Pack gehört (Prüfung 14 und 48). Sämtliche variablen Inhalte laufen über das Platzhalterregister; die Overlay-Vorlage ist eine reine Vorlage mit Ausfüllhinweisen und `<TBD>`-Feldern. Das Overlay-Muster *General Development* (`--overlay general`) füllt davon nur Platzhalter, deren Wert eine Sperre ist, und bringt allgemeine, projektneutrale Musterdokumente mit (D-355, D-359). Synthetische Beispiele sind als solche gekennzeichnet und verwenden offensichtlich fiktive Bezeichner.
+Alle versionierten Markdown-Dateien des Kerns – beim Bau dieses Dokuments {{ZAHL:*.md}} – werden bei jedem Validatorlauf automatisiert auf Projektneutralität geprüft (Sperrbegriffs-, E-Mail-, IP-, Hostnamen- und URL-Prüfungen; Kap. 26). Der Validator prüft außerdem die Werkzeugneutralität: Kein anweisender Träger des Kerns nennt einen Produktnamen oder einen Pfad, der genau einem Client Pack gehört (Prüfung 14 und 48). Sämtliche variablen Inhalte laufen über das Platzhalterregister; die Overlay-Vorlage ist eine reine Vorlage mit Ausfüllhinweisen und `<TBD>`-Feldern. Das Overlay-Muster *General Development* (`--overlay general`) füllt davon nur Platzhalter, deren Wert eine Sperre ist, und bringt allgemeine, projektneutrale Musterdokumente mit. Synthetische Beispiele sind als solche gekennzeichnet und verwenden offensichtlich fiktive Bezeichner.