@renoxar/koolie 1.25.0

package/.koolie/core/clients/claude-code/manifest.json

@@ -0,0 +1,232 @@
+{
+  "_comment": "Maschinenlesbare Pfadabbildung dieses Client Packs. Die menschenlesbare Fassung mit Fähigkeitsmatrix steht in CLIENT_PACK.md. Besonderheit gegenüber devin-desktop: Der Client kennt Ladebedingungen nur über Dateimuster (rule_triggers.condition_field = paths); die Ladetrigger der Kernquelle werden darauf abgebildet, always_on und model_decision auf unbedingtes Laden. Hooks stehen nicht in einer eigenen Datei, sondern in .claude/settings.json.",
+  "client": "claude-code",
+  "runtime_dir": ".claude",
+  "root_instruction_file": "CLAUDE.md",
+  "permissions_file": ".claude/settings.json",
+  "skills_dir": ".claude/skills",
+  "agents_dir": ".claude/agents",
+  "pack_runtime_dir": ".claude/rules",
+  "has_rule_triggers": true,
+  "core_skill_prefix": "fw-",
+  "core_paths": [
+    ".claude/README.md"
+  ],
+  "seed_paths": [],
+  "project_owned_hint": [
+    ".claude/rules/2N-overlay-<name>.md       (Overlay-Regelerweiterungen)",
+    ".claude/rules/40-tech-<name>.md          (Packs ohne Quelle im Kern)",
+    ".claude/settings.local.json              (persönliche Überschreibungen)",
+    ".claude/skills/prj-*/                    (projektspezifische Skills)",
+    ".koolie/project-overlay/tech-packs/**            (projekteigene Packs)",
+    ".koolie/project-overlay/**                       (das gesamte Overlay)"
+  ],
+  "runtime_placeholders": {
+    "<RUNTIME_DIR>": ".claude",
+    "<ROOT_INSTRUCTION_FILE>": "CLAUDE.md",
+    "<ROOT_INSTRUCTION_LOCAL>": "CLAUDE.local.md",
+    "<PERMISSIONS_FILE>": ".claude/settings.json",
+    "<SKILLS_DIR>": ".claude/skills",
+    "<RULES_DIR>": ".claude/rules",
+    "<AGENTS_DIR>": ".claude/agents",
+    "<HOOKS_FILE>": ".claude/settings.json",
+    "<MCP_FILE>": ".mcp.json",
+    "<CLIENT_NAME>": "Claude Code"
+  },
+  "skill_frontmatter": {
+    "tools_format": "csv",
+    "tool_names": {
+      "read": [
+        "Read"
+      ],
+      "grep": [
+        "Grep"
+      ],
+      "glob": [
+        "Glob"
+      ],
+      "edit": [
+        "Edit",
+        "Write"
+      ],
+      "exec": [
+        "Bash"
+      ]
+    },
+    "model_invocation_field": "disable-model-invocation",
+    "_model_invocation_note": "AP2-CC-01: Ein Skill, dessen Quelle triggers ohne model nennt, bekommt dieses Feld auf true. Ohne die Abbildung verfiel die Zusage S4 beim Rendern - der Validator erzwang triggers: [user] in der Quelle, die installierte Fassung trug nichts davon.",
+    "skill_deny_field": "disallowed-tools",
+    "_skill_deny_note": "Die Abbildung von permissions.deny (CR-2026-057, D-64/D-65). Gemessen am 2026-09-13 (tests/protocols/2026-09-13-erhebung-disallowed-tools.md): 'disallowed-tools' nimmt das Werkzeug aus dem Vorrat und schlaegt dabei sogar eine ausdrueckliche allow-Regel - ein Skill mit 'disallowed-tools: Write, Edit' konnte NICHT schreiben, obwohl Write in der allow-Liste stand; derselbe Skill ohne das Feld konnte es. Das ist genau das, was 'allowed-tools' nach B01 nicht ist. Die Werkzeugnamen kommen aus hook_tools dieses Manifests und NICHT aus skill_frontmatter.tool_names (D-28, CR-2026-057 E2): edit -> hook_tools.write, exec -> hook_tools.exec. Der Unterschied ist gewollt und gemessen - tool_names.edit fuehrt nur Edit und Write, hook_tools.write fuehrt zusaetzlich NotebookEdit; fuer eine Sperre waere das eine Luecke, und eine Luecke in der Liste ist ausnutzbar (Lauf E der Erhebung: mit gesperrtem Write, Edit schrieb der Skill ueber Bash).",
+    "skill_deny_unmapped": "argumentmuster",
+    "_skill_deny_unmapped_note": "Was dieses Pack bewusst NICHT abbildet, deklariert statt verschwiegen (CR-2026-057 E3, Bauart wie hook_tools_absent nach D-47): befehlsgenaue Verbote der Form Exec(git push). Gemessen am 2026-09-13, Laeufe G' und G'' (tests/protocols/2026-09-13-erhebung-disallowed-tools.md Abschnitt 4.3): Ein Eintrag mit Klammer - 'disallowed-tools: Bash(echo verboten:*)' und ebenso die Schreibweise mit Leerzeichen - laesst den Befehl LAUTLOS durchlaufen, ohne Verweigerung und ohne Fehlermeldung; derselbe Skill mit 'disallowed-tools: Bash' wies beide Befehle ab. Wer ein Argumentmuster schreibt, hat deshalb GAR KEINE Schranke, nicht bloss eine groebere. Die Alternative - das ganze Werkzeug sperren - ist strenger als gemeint und macht die allow-Eintraege derselben Skills wirkungslos: fw-tests koennte seinen Testbefehl nicht mehr ausfuehren. Betroffen sind fuenf der zwoelf Quellskills, und sie sind NICHT gleich betroffen - nachgezaehlt an der erzeugten Fassung, nicht an der Quelle: DREI tragen ausschliesslich befehlsgenaue Verbote und bekommen deshalb GAR KEINE Schranke je Skill (fw-change-small, fw-refactor, fw-tests); ZWEI nennen daneben das grobe Verb edit und bekommen eine TEILWEISE Schranke - ihre Editierwerkzeuge sind gesperrt, ihre git-Verbote nicht (fw-mr-description, fw-review-support). Die uebrigen sieben sind vollstaendig abgebildet. Pruefung 33 weist jedes Argumentmuster in einer erzeugten Fassung ab.",
+    "drop_fields": [
+      "permissions",
+      "triggers"
+    ],
+    "skill_permissions_ersatz": "Seit 0.35.0 gibt es einen Ersatz, und er ist benannt schwaecher (CR-2026-057, D-64). Das Feld 'permissions' der Quelle kennt dieser Client fuer Skills nicht; es bleibt deshalb in drop_fields. Sein deny-Teil wird auf 'disallowed-tools' abgebildet, soweit er grobe Verben nennt - siehe skill_deny_field. DREI GRENZEN, und sie gehoeren zu jeder Nennung dieser Zusage: (1) Die Schranke gilt nur fuer den aufrufenden Turn; Turn 2 derselben Sitzung konnte wieder schreiben. Ein 'nur lesender' Skill ist nur waehrend seines Turns nur lesend - es ist keine Betriebsart. (2) Die Liste ist aufzaehlend; was nicht dasteht, ist offen. (3) Befehlsgenaue Verbote sind nicht ausdrueckbar - siehe skill_deny_unmapped. Fuer die fuenf Skills mit solchen Verboten bleibt es bei dem, was bis 0.34.0 fuer alle zwoelf galt: die GLOBALE Berechtigungsschicht samt Schutz-Hook, die unabhaengig vom Skill wirkt und am 2026-09-12 auch im untersagten Betriebsmodus hielt. Das ist weniger als eine Beschraenkung je Skill. Bis 0.34.0 stand hier 'Kein Ersatz je Skill - und das ist die Aussage' (B01, D-50); das war nach dem damaligen Belegstand richtig und ist seit der Erhebung vom 2026-09-13 ueberholt. D-50 selbst bleibt gueltig: Ein zusagentragendes Feld verschwindet nicht unbenannt beim Rendern."
+  },
+  "shared_core": [
+    {
+      "src": "framework/runtime/root-instruction.md",
+      "dst": "<ROOT_INSTRUCTION_FILE>"
+    },
+    {
+      "src": "framework/runtime/rules/00-framework-core.md",
+      "dst": "<RULES_DIR>/00-framework-core.md"
+    },
+    {
+      "src": "framework/runtime/rules/10-privacy-security.md",
+      "dst": "<RULES_DIR>/10-privacy-security.md"
+    },
+    {
+      "src": "framework/runtime/rules/15-development-rules.md",
+      "dst": "<RULES_DIR>/15-development-rules.md"
+    },
+    {
+      "src": "framework/runtime/agents/fw-reviewer.md",
+      "dst": "<AGENTS_DIR>/fw-reviewer.md"
+    },
+    {
+      "src": "templates/rules/21-overlay-TEMPLATE.md.template",
+      "dst": "<RULES_DIR>/21-overlay-TEMPLATE.md.template"
+    },
+    {
+      "src": "templates/rules/40-tech-TEMPLATE.md.template",
+      "dst": "<RULES_DIR>/40-tech-TEMPLATE.md.template"
+    },
+    {
+      "src": "framework/runtime/root-instruction-local.example.md",
+      "dst": "<ROOT_INSTRUCTION_LOCAL>.example"
+    },
+    {
+      "src": "framework/runtime/mcp-config.example.json",
+      "dst": "<MCP_FILE>.example"
+    }
+  ],
+  "shared_seed": [
+    {
+      "src": "framework/runtime/permissions.json",
+      "dst": "<PERMISSIONS_FILE>"
+    },
+    {
+      "src": "framework/runtime/rules/20-project-overlay.md",
+      "dst": "<RULES_DIR>/20-project-overlay.md"
+    },
+    {
+      "src": "templates/project-overlay",
+      "dst": ".koolie/project-overlay"
+    }
+  ],
+  "rule_frontmatter": "yaml",
+  "rule_triggers": {
+    "condition_field": "paths",
+    "condition_format": "list",
+    "allowed_fields": [
+      "paths"
+    ],
+    "map": {
+      "always_on": {
+        "condition": null
+      },
+      "model_decision": {
+        "condition": null
+      },
+      "glob": {
+        "condition": "paths",
+        "from": "globs"
+      }
+    }
+  },
+  "_rule_triggers_note": "AP2-CC-03: Der Client laedt jede .md-Datei der Regelablage von sich aus - ohne paths-Feld unbedingt, mit paths-Feld sobald er eine passende Datei liest. Damit sind R2 und R3 abgebildet und die @-Importe der Wurzel-Anweisung entfallen. Ein Ladetrigger der Quelle ohne Eintrag unter map laesst die Installation scheitern (D-27); ersatzloses Verwerfen waere ein Verlust der Zusage (D-26). description ist fuer Regeldateien dieses Clients nicht dokumentiert und entfaellt deshalb im Frontmatter (K-18); es steht im erzeugten Kommentar, den der Client vor dem Einspeisen entfernt.",
+  "root_instruction_imports": [],
+  "agent_frontmatter": {
+    "tools_field": "tools",
+    "tools_format": "csv",
+    "tool_names": {
+      "read": [
+        "Read"
+      ],
+      "grep": [
+        "Grep"
+      ],
+      "glob": [
+        "Glob"
+      ],
+      "edit": [
+        "Edit",
+        "Write"
+      ],
+      "exec": [
+        "Bash"
+      ]
+    }
+  },
+  "agent_start_tools": ["Agent", "Task"],
+  "_agent_start_tools_note": "Das Werkzeug, mit dem ein Skill oder der Hauptagent einen Unteragenten startet (CR-2026-058, D-70). Gemessen am 2026-09-13 (tests/protocols/2026-09-13-erhebung-unteragent.md): BEIDE Schreibweisen wirken in disallowed-tools - der Start wurde jeweils abgewiesen, kein stiller Ausfall wie bei den Argumentmustern nach D-66. Die Kanaele nennen das Werkzeug allerdings verschieden, in derselben Sitzung und fuer denselben abgewiesenen Aufruf: Der Hook-Umschlag fuehrt tool_name Agent, permission_denials im JSON-Ergebnis fuehrt Task. Wer eine Abbildung oder eine Pruefung an den Namen haengt, muss wissen, welcher Kanal welchen fuehrt - deshalb stehen hier beide. Das Feld steht bewusst NEBEN hook_tools und permission_tools und nicht darin: Ein Unteragentenstart ist keines der vier Verben (read, search, exec, write), und die Aufrufe des Unteragenten SELBST laufen ohnehin unter ihren eigenen Werkzeugnamen durch den Hook - gemessen, einschliesslich Blockade, auch mit dem benannten Matcher, den clientmap.py erzeugt (D-69).",
+  "permission_tools": {
+    "read": [
+      "Read"
+    ],
+    "search": [],
+    "write": [
+      "Edit"
+    ],
+    "exec": [
+      "Bash",
+      "PowerShell"
+    ],
+    "fetch": [
+      "WebFetch",
+      "WebSearch"
+    ],
+    "mcp": [
+      "mcp__*"
+    ],
+    "skill": [
+      "Skill"
+    ]
+  },
+  "permission_name_tools": [
+    "Skill"
+  ],
+  "_permission_name_tools_note": "Werkzeuge, deren Regelargument kein Pfad ist, sondern ein Name. Fuer sie haengt die Abbildung weder das Wurzelpraefix (permission_path_prefix) noch das Praefixzeichen (permission_exec_suffix) an, und der Validator laesst sie neben permission_path_tools zu. Gemessen am 2026-09-14 (tests/protocols/2026-09-14-erhebung-skillaufruf.md, D-82): Der Skill-Aufruf ist bei diesem Client ein eigener Werkzeugaufruf mit dem Namen Skill und laeuft ohne allow-Regel in die Rueckfrage; das Argument wird WOERTLICH verglichen - Skill(fw-code-explain) laesst den Aufruf durch (Lauf C1), Skill(fw-*) nicht (Lauf D1), und Skill(fw-plan) weist fw-code-explain ab (Lauf E1, Kontrolllauf). Deshalb zwoelf woertliche Regeln statt eines Musters.",
+  "mcp_permission_rule": {"werkzeug": "mcp__{server}__{werkzeug}", "pauschal": "mcp__*", "rueckfrage_schlaegt_freigabe": true},
+  "_mcp_permission_rule_note": "Die Regelform eines MCP-Werkzeugs in der Berechtigungsdatei (Pruefung 101, D-459). Gemessen am 2026-09-28 mit Clientversion 2.1.283 (Vorpruefung zu 1.18.0): allow auf mcp__<server>__<werkzeug> laesst ein Lesewerkzeug im Druckmodus durch, ein Schreibwerkzeug auf ask wird abgewiesen (V4); steht mcp__* im ask-Korb - so erzeugt die Kernquelle die Datei -, wird auch das einzeln freigegebene Lesewerkzeug abgewiesen (V5). Die Freigabe zum Lesen ersetzt deshalb die Pauschale durch Einzelregeln.",
+  "permission_tools_bare": [
+    "WebFetch",
+    "WebSearch",
+    "mcp__*"
+  ],
+  "permission_path_tools": [
+    "Read",
+    "Edit"
+  ],
+  "_permission_path_tools_note": "AP2-CC-02: Nur fuer diese Werkzeuge wertet der Client eine Pfadregel aus. Eine Pfadregel fuer Write, NotebookEdit, Glob oder MultiEdit wird angenommen, nie konsultiert und beim Sitzungsstart als Warnung gemeldet. Der Validator prueft die erzeugte Datei dagegen.",
+  "permission_path_prefix": "./",
+  "permission_exec_match": "prefix",
+  "permission_exec_suffix": ":*",
+  "permissions_extra": {
+    "defaultMode": "default"
+  },
+  "_permissions_extra_note": "Zusatzschluessel INNERHALB des permissions-Objekts. Was der Client auf der obersten Ebene der Einstellungsdatei liest, steht in settings_extra - die Ebene ist keine Kosmetik, sondern entscheidet, ob der Schluessel ueberhaupt gelesen wird (CR-2026-087, D-155).",
+  "settings_extra": {
+    "autoMemoryEnabled": false,
+    "attribution": {
+      "commit": "",
+      "sessionUrl": false
+    }
+  },
+  "_settings_extra_attribution_note": "CR-2026-153, D-433 (K-171). Der Client gibt dem Modell von sich aus eine Attributionsvorgabe fuer Commits mit (Standard: Trailer Co-Authored-By mit einer Adresse des Herstellers; in Cloud- und Remote-Control-Sitzungen zusaetzlich ein Trailer Claude-Session). Das widerspricht Q5 - die Commit-Nachricht beschreibt das Warum, der KI-Vermerk gehoert in den Merge Request. Gemessen im Nachlauf von 1.14.1 (K-171): Q5 im Skill verhinderte die Zeile nicht. Quelle: code.claude.com/docs/en/settings-reference.md, Abschnitt Git and attribution (QC-7). OBJEKTFORM MIT ABSICHT: Die Kurzform attribution: false gibt es erst ab 2.1.281, und aeltere Staende verwerfen laut Quelle die GANZE Einstellungsdatei, die sie enthaelt - mit Berechtigungen und Hooks. Die Zielspanne dieses Packs ist 2.1.x. pr bleibt unberuehrt: Q5 verlangt den Vermerk im Merge Request. Standard, keine Schranke: .claude/settings.local.json hat Vorrang.",
+  "_settings_extra_note": "CR-2026-087, D-154. Dieser Client fuehrt seit 2.1.x eine ZWEITE Anweisungsquelle neben CLAUDE.md und der Regelablage: Er schreibt sich selbst Notizen (code.claude.com/docs/en/memory, Abschnitt 'Auto memory'), legt sie ausserhalb des Repositoriums unter ~/.claude/projects/<projekt>/memory/ ab und laedt die ersten 200 Zeilen beziehungsweise 25 KB von MEMORY.md in JEDE Sitzung. Die Quelle sagt woertlich 'Auto memory is on by default.' Damit steht in jeder Sitzung ein Anweisungstext, den weder die Prioritaetshierarchie des Frameworks kennt noch der Validator sieht noch ein Review erreicht - er ist weder versioniert noch gegengezeichnet. Das Framework schaltet ihn deshalb ab, und zwar als Standard, nicht als Schranke: Wer ihn braucht, setzt ihn in .claude/settings.local.json wieder, die hoeheren Vorrang hat. GEGENSTUECK, das GERADE NICHT geht: syncClaudeAiSkills (Skills vom claude.ai-Konto, ebenfalls standardmaessig an) laesst sich hier NICHT abschalten - die Quelle sagt fuer diesen Schluessel ausdruecklich 'a false in .claude/settings.json is ignored', und .claude/settings.json ist die einzige Datei, die dieses Pack ausliefert (K-63).",
+  "permissions_note": "Eine Abweichung gegenueber Clients mit einem einzigen Schreibwerkzeug: Befehlsverbote wirken praefixbasiert und damit breiter (Bash(git reset:*) sperrt jedes git reset, nicht nur --hard); ihre Grenze ist eine andere Schreibweise desselben Befehls, etwa git -C . push. Pfadregeln werden von diesem Client nur fuer Read und Edit ausgewertet: Eine Pfadregel fuer Write, NotebookEdit, Glob oder MultiEdit wird angenommen, nie konsultiert und beim Sitzungsstart als Warnung gemeldet. write bildet deshalb auf Edit ab und search auf nichts; fuer den Suchkanal traegt seit 0.30.0 der Schutz-Hook statt der Berechtigungsdatei (hook_tools.search, CR-2026-047) - bis 0.13.0 erzeugte die Abbildung je Pfad zusaetzlich eine Write-Regel und ein Glob(**), zusammen 17 wirkungslose Regeln je Installation (AP2-CC-02, D-26). Eine Verweigerung des blossen Werkzeugnamens ohne Pfad wirkt weiterhin ueberall.",
+  "hook_path_fields": ["file_path", "notebook_path", "path"],
+  "_hook_path_fields_note": "Die Felder von tool_input, die bei diesem Client einen Pfad tragen. Der Schutz-Hook loest genau sie auf und haelt den aufgeloesten Pfad noch einmal gegen die Muster - das ist die Pfadidentitaet aus D-63: Grossschreibung, 8.3-Kurzname, Junction, Punkt oder Leerzeichen am Ende und ::$DATA bezeichnen unter NTFS dieselbe Datei und wurden bis 0.33.0 verschieden entschieden. Belegt an den AP2-Aufzeichnungen: Read und Write fuehren file_path, Grep fuehrt path, NotebookEdit notebook_path; Glob fuehrt pattern und keinen Pfad. Fehlt das Feld, faellt der Hook auf seine Basisliste zurueck - das ist weniger, nicht mehr (CR-2026-056 E6).",
+  "hook_tools": {"read": ["Read"], "search": ["Grep", "Glob"], "exec": ["Bash", "PowerShell"], "write": ["Edit", "Write", "NotebookEdit"], "mcp": ["mcp__.*"]},
+  "hook_mcp_prefixes": ["mcp__"],
+  "_hook_mcp_note": "MCP-Werkzeuge heissen bei diesem Client mcp__<server>__<werkzeug> - fuer projekteigene Server wie fuer die Connectoren des claude.ai-Kontos (mcp__claude_ai_<name>__...), gelesen aus der Startmeldung am 2026-09-29 (Clientversion 2.1.284). Der Matcher ist ein regulaerer Ausdruck ueber den Werkzeugnamen, mcp__.* trifft deshalb jeden Server; der Hook erkennt das Verb am Praefix aus hook_mcp_prefixes (K-184, D-486). Geprueft werden Inhalt gegen die Secret-Muster und Pfadfelder gegen die Secret-Pfadmuster, nicht die Struktur- und Kernpfade.",
+  "_hook_tools_search_note": "B04: Die Suchwerkzeuge standen bis 0.29.0 in keinem Hook-Eintrag; eine Suche ueber einen Secret-Pfad erreichte den Hook nicht (gemessen am 2026-09-12, Lauf B04-5). Der Hook ist fuer diesen Kanal die einzige technische Schranke - eine Pfadregel in der Berechtigungsdatei wuerde dieser Client fuer Grep und Glob annehmen, nie konsultieren und beim Sitzungsstart als Warnung melden (AP2-CC-02). Deshalb hook_tools ja, permission_tools nein (CR-2026-047 E3, D-47).",
+  "hook_project_dir_var": "CLAUDE_PROJECT_DIR",
+  "_import_control_note": "Kein Feld import_control - und zwar als Entscheidung, nicht als Luecke (D-37, CR-2026-038 E2). Dieser Client kennt mit claudeMdExcludes einen Mechanismus, das Framework liefert aber keine Vorgabe aus: Eine Wurzel-Anweisungsdatei im Elternverzeichnis ist im Mehrprojekt-Verzeichnis oft gewollt, ein pauschaler Ausschluss braeche legitime Anordnungen. Es bleibt bei Auskunft und Empfehlung im Client Pack, Abschnitt 8. Pruefung 22 laesst ein Pack ohne das Feld durchlaufen.",
+  "hook_fail_closed": true,
+  "_hook_fail_closed_note": "Das Eingabeschema dieses Clients ist gegen eine Installation bestaetigt (AP2-Protokoll, WN-5; Clientversion 2.1.267), und Pruefung 15 belegt, dass der Hook startet. Ein durchsetzender Hook wird deshalb mit --fail-closed aufgerufen: Eine Eingabe, die er nicht lesen kann, blockiert, statt durchgelassen zu werden. Der Schalter steht im Kommando und nicht in env - dass ein Client env an den Hook-Prozess weiterreicht, ist fuer keines der Packs belegt (D-31)."
+}

package/.koolie/core/clients/claude-code/root-template/.claude/README.md

@@ -0,0 +1,127 @@
+# `.claude/` – Laufzeitschicht für Claude Code
+
+Dieses Verzeichnis enthält alles, was Claude Code aus dem Repository liest. Es ist die einzige clientspezifische Schicht des Frameworks (Tool Independence). Alle Inhalte sind Konkretisierungen der werkzeugneutralen Regeln in `.koolie/core/framework/`.
+
+Die Durchsetzungstiefe – welche Zusage dieser Client technisch erzwingt und welche nur als Anweisung im Kontext steht – ist in der Fähigkeitsmatrix des Client Packs ausgewiesen: `.koolie/core/clients/claude-code/CLIENT_PACK.md`.
+
+| Datei / Verzeichnis | Zweck | Belegstatus |
+|---|---|---|
+| `rules/*.md` | Regeltexte (Core, Overlay, Packs); werden vom Client selbst geladen – ohne `paths`-Feld unbedingt, mit `paths`-Feld bei passenden Dateien | [DOK] (AP2, Clientversion 2.1.267) |
+| `skills/<name>/SKILL.md` | Skills, Aufruf über den Namen mit vorangestelltem Schrägstrich; Frontmatter `name`, `description`, `argument-hint`, `allowed-tools` | `[DOK]` |
+| `agents/<name>.md` | Subagentenprofile (hier: nur lesender Reviewer); Frontmatter `name`, `description`, `tools` (ergänzend `disallowedTools`) | [DOK] (AP2, Clientversion 2.1.267) |
+| `settings.json` | Berechtigungen `deny` / `ask` / `allow` **und** Hooks (projektweit, versioniert). Erzeugt aus `.koolie/core/framework/runtime/permissions.json` und `hooks.json`; hier trägt das Projekt nur die Platzhalterwerte ein | `[DOK]` Mechanismus; Regelmenge `[EMPF]`; Mustersemantik [DOK] (AP2, Clientversion 2.1.267) – gitignore-Syntax; **Pfadregeln wertet dieser Client nur für `Read` und `Edit` aus** |
+| `settings.local.json` (nicht versioniert) | persönliche Überschreibungen; im Framework nur zum Verschärfen zulässig | `[DOK]` |
+
+Im Wurzelverzeichnis liegen außerdem `CLAUDE.md` (Wurzel-Anweisung) und `.mcp.json.example` (Vorlage für MCP-Server; Standard: keine). Die Wurzel-Anweisung bindet die Regeltexte **nicht** ein; sie liegen in `rules/` und werden von dort geladen.
+
+## Zwei Unterschiede zur Fassung anderer Client Packs
+
+Die **Regeltexte sind inhaltlich identisch**. Abweichend ist nur, wie ihre Ladebedingung notiert wird.
+
+1. **Eine Bedingung statt dreier Ladetrigger.** Die Kernquelle kennt `always_on`, `model_decision` und `glob`; dieser Client kennt für Regeldateien nur die Bindung an Dateimuster (`paths`). `always_on` und `model_decision` werden deshalb beide auf unbedingtes Laden abgebildet, `glob` auf `paths`. Für `model_decision` ist das eine Verschärfung, keine Lockerung – es kostet Kontext (rund 25.000 Zeichen einschließlich `CLAUDE.md`), senkt aber kein Schutzniveau. Einzelheiten: Abschnitt „Regelablage" weiter unten.
+
+2. **Hooks stehen in `settings.json`**, nicht in einer eigenen Datei.
+
+Bis Framework-Release 0.14.0 stand hier ein dritter Unterschied – „Schreibschutz braucht zwei Regeln je Pfad". Er galt nie: Dieser Client wertet Pfadregeln ausschließlich für `Read` und `Edit` aus (AP2-CC-02, D-26).
+
+## Technology Packs
+
+Ein Technology Pack (Ebene 5) lädt über ein Dateimuster – etwa nur bei Java-Dateien. Dieser Client bildet das nativ ab: Die Laufzeitfassung des Packs liegt als `rules/40-tech-<name>.md` mit `paths:` und den Dateimustern der Technologie. Sie lädt, sobald der Client eine passende Datei liest.
+
+Zu beachten: Die Regel steht damit nicht schon zu Beginn der Aufgabe im Kontext, sondern erst nach der ersten Berührung einer passenden Datei. Ein Pack, dessen Regeln vorher gelten müssen, bleibt unbedingt geladen. Details: Abschnitt „Regelablage" weiter unten und `CLIENT_PACK.md` Abschnitt 5.
+
+## Berechtigungsmodi und Framework-Vorgabe
+
+| Modus | Verhalten | Framework-Vorgabe |
+|---|---|---|
+| `default` | Lesen automatisch; Schreiben und Befehle fragen | **Standard** für alle Kontrollstufen |
+| `acceptEdits` | Dateiänderungen automatisch; Befehle fragen | nur Kontrollstufe niedrig, nur mit Overlay-Freigabe |
+| `plan` | nur Analyse und Planung, keine Änderungen | zulässig; entspricht M1/M2 |
+| `bypassPermissions` | alles automatisch | **untersagt** (D-05) |
+
+## Regelablage (`rules/`)
+
+Die Regelablage enthält die Laufzeitfassung der Framework-Regeln. Die kanonische, werkzeugneutrale Langform liegt in `.koolie/core/framework/`. Bei Widersprüchen gilt die Langform; die Laufzeitfassung wird dann korrigiert. **Die Regeltexte sind inhaltlich identisch zu denen anderer Client Packs.** Abweichend ist ausschließlich, wie die Ladebedingung notiert wird.
+
+> **Warum dieser Abschnitt hier steht und nicht in `rules/`.** Bis 0.25.0 lag dort eine eigene README. Dieser Client lädt **jede** `.md`-Datei der Regelablage unbedingt – gemessen am 2026-09-11: Die Sitzung führte die Datei samt Inhaltsangabe in ihrem geladenen Bestand auf (K-26). Ein erklärender Text mit Belegvorbehalten hatte damit einen dauerhaften Platz im Kontext. Seit 0.26.0 gilt: **Die Regelablage enthält ausschließlich Regeln** (D-36).
+
+### Mechanismus (Belegstatus)
+
+| Aussage | Status |
+|---|---|
+| `CLAUDE.md` im Wurzelverzeichnis wird zu Beginn jeder Sitzung geladen | `[DOK]` |
+| Jede `.md`-Datei in diesem Verzeichnis wird gefunden, auch in Unterverzeichnissen | [DOK] (AP2, Clientversion 2.1.267) |
+| Eine Regeldatei **ohne** `paths`-Feld wird beim Sitzungsstart unbedingt geladen – ohne Import | [DOK] (AP2, Clientversion 2.1.267) |
+| Eine Regeldatei **mit** `paths`-Feld lädt, sobald der Client eine Datei liest, die auf eines der Glob-Muster passt | [DOK] (AP2, Clientversion 2.1.267) |
+| `paths` nimmt mehrere Muster; Klammer-Expansion (`{ts,tsx}`) ist zulässig | [DOK] (AP2, Clientversion 2.1.267) |
+| `description` ist für Regeldateien **nicht** dokumentiert und steht deshalb nicht im Frontmatter (K-18) | [DOK] (AP2, Clientversion 2.1.267) |
+| Zeichenlimit der Wurzel-Anweisung: 4 MiB je Datei; darüber wird sie übersprungen. Empfehlung: unter 200 Zeilen | [DOK] (AP2, Clientversion 2.1.267) |
+| **Ein HTML-Kommentar erreicht die Sitzung nicht.** Dieselbe Messmarke blieb unsichtbar, solange sie in Kommentarklammern stand, und war im Klartext sofort da – in der Wurzel-Anweisungsdatei **und** in der Regelablage | in einer Sitzung erhoben (2026-09-11, ERH-01) |
+
+Bis Framework-Release 0.14.0 lag diese Ablage unter `.claude/framework/` und wurde über `@pfad`-Importe in `CLAUDE.md` geladen. Der Grund dafür – „dieser Client kennt keine Ladebedingungen" – war falsch (AP2-CC-03).
+
+### Frontmatter
+
+Nur das Feld `paths` ist zulässig, und nur bei Regeln, die an Dateimuster gebunden sind; es nimmt eine Liste von Glob-Mustern. Eine Regel ohne Frontmatter lädt unbedingt. Der Validator meldet jedes andere Feld – insbesondere ein aus der Kernquelle stehen gebliebenes `trigger:` oder `globs:`, das dieser Client nicht auswertet.
+
+Der erzeugte HTML-Kommentar oberhalb des Regeltextes nennt Zweck, Ladeverhalten und den Ladetrigger der Kernquelle. **Er ist die Auskunft an den Menschen, der die Datei öffnet; in den Kontext geht er bei diesem Client nicht** – gemessen am 2026-09-11 (ERH-01). Deshalb steht dort Herkunft und keine Anweisung: Ein normativer Satz im Kommentar wäre eine Regel, die niemanden erreicht (D-38). Prüfung 23 meldet normative Schlüsselwörter in solchen Kommentaren.
+
+### Abbildung der Ladetrigger
+
+Die Kernquelle kennt drei Ladetrigger, dieser Client eine Bedingung. Was womit abgebildet wird, steht maschinenlesbar in `.koolie/core/clients/claude-code/manifest.json` unter `rule_triggers`:
+
+| Ladetrigger der Kernquelle | Fassung hier | Ladeverhalten |
+|---|---|---|
+| `always_on` | kein `paths`-Feld | bei jedem Sitzungsstart |
+| `model_decision` | kein `paths`-Feld | bei jedem Sitzungsstart – **Verschärfung**, siehe unten |
+| `glob` mit Mustern | `paths:` mit denselben Mustern | sobald der Client eine passende Datei liest |
+
+Ein Ladetrigger ohne Eintrag in dieser Abbildung lässt die Installation scheitern; er wird nicht stillschweigend verworfen (D-26, D-27).
+
+### Nummernschema und Ebenenzuordnung (Framework-Konvention `[KONZ]`)
+
+Das Schema ist über alle Client Packs gleich, damit eine Regel beim Wechsel des Clients wiedererkennbar bleibt.
+
+| Präfix | Ebene der Prioritätshierarchie | Ladebedingung hier | Pflege |
+|---|---|---|---|
+| `00-` | 3 Framework Core | unbedingt | Framework Owner |
+| `10-` | 3 Framework Core (Datenschutz/Sicherheit) | unbedingt | Framework Owner |
+| `15-` | 3 Framework Core (Entwicklungsregeln) | unbedingt | Framework Owner |
+| `20-` | 4 Project Overlay | unbedingt | Projekt (Overlay Owner) |
+| `2N-` | 4 Overlay-Regelerweiterungen | je Vorlage; `paths` zulässig | Projekt (Overlay Owner) |
+| `30-` | 6 Role Packs | unbedingt | Modul-Owner |
+| `40-` | 5 Technology Packs | `paths` mit den Dateimustern der Technologie | Modul-Owner |
+
+Die Nummern bilden die Ladereihenfolge im Dateisystem ab, nicht die Priorität. Die Priorität regelt `CLAUDE.md` Abschnitt 2 beziehungsweise `.koolie/core/governance/PRIORITY_HIERARCHY.md`.
+
+### Was die Abbildung von `model_decision` bedeutet
+
+Bei Clients mit einer modellentschiedenen Ladebedingung laden `10-` und `15-` nur, wenn die Aufgabe sie berührt. Hier sind sie **immer** geladen, weil dieser Client für Regeldateien nur die Bedingung über Dateimuster kennt.
+
+- **Für die Regelwirkung:** eine Verschärfung. Mehr Regeln sind aktiv, nicht weniger.
+- **Für den Kontext:** rund 25.000 Zeichen sind ständig belegt (`CLAUDE.md` und die vier unbedingten Regeltexte einer frischen Installation zusammen). Das Prinzip Least Context wird damit schwächer eingehalten als bei einem Client mit modellentschiedener Bedingung. Least Context ist ein Prinzip zur Ergebnisqualität, keine Sicherheitszusage – die Abweichung ist deshalb vertretbar und in `CLIENT_PACK.md` Zeile R2 ausgewiesen.
+
+Wächst der ständige Kontext durch aktivierte Packs deutlich, ist zu prüfen, ob ein Pack an Dateimuster gebunden werden kann. Der Validator meldet einen Fehler, sobald die unbedingt geladenen Texte zusammen 40.000 Zeichen überschreiten (D-387).
+
+### Grenzen dieser Ablage
+
+- **Eine pfadgebundene Regel lädt beim Lesen einer passenden Datei, nicht bei jedem Werkzeugaufruf.** Sie steht also nicht schon zu Beginn der Aufgabe im Kontext. Für Regeln, die vor der ersten Dateiberührung gelten müssen, ist `paths` deshalb ungeeignet – sie bleiben unbedingt.
+- **Eine Kernregel darf nicht an Dateimuster gebunden werden.** `00-`, `10-`, `15-` und `20-` gelten für jede Aufgabe; ein `paths`-Feld dort wäre eine Lockerung. Der Validator meldet es als Fehler.
+- **Ein ungültiges Muster trifft nichts.** Glob liest eine öffnende eckige Klammer als Beginn eines Klammerausdrucks; ein unausgeglichenes Muster trifft keine Datei, während die übrigen Muster derselben Regel weiter wirken. Eine literale Klammer wird mit vorangestelltem Rückstrich geschrieben.
+- **Klammer-Expansion hat ein Budget.** Die `paths`-Liste einer Regel teilt sich 1.000 expandierte Muster und 4 MiB; ein Muster darüber wird unexpandiert verwendet und trifft dann nichts.
+- **Nutzerlokal ausschließbar.** `claudeMdExcludes` in `.claude/settings.local.json` kann Regeldateien über ein Glob-Muster vom Laden ausnehmen. Das ist eine **Lockerung** und damit im Framework unzulässig (B9); technisch verhindert wird sie nicht. Der KI-Client selbst kann die Datei nicht schreiben – eine Verweigerungsregel auf die Laufzeitschicht steht in `deny` –, ein Mensch schon. Dasselbe Feld ist zugleich der Weg, eine Anweisungsdatei **außerhalb** des Projekts auszuschließen; das Framework liefert dafür keine Vorgabe aus (Zeile R6, D-37).
+
+### Regeln für die Regelablage
+
+- **Dort liegt nur, was Regel ist.** Ein erklärender Text gehört hierher, nicht dorthin (D-36). Der Validator meldet eine Datei in der Vorlage der Regelablage, die dem Nummernschema nicht folgt.
+- Änderungen an `00-`, `10-`, `15-` nur über einen Framework-Änderungsantrag; `20-` und `2N-` über den Overlay-Prozess des Projekts; `30-`, `40-` über den jeweiligen Modul-Owner.
+- Eine dort abgelegte Datei wirkt ohne weiteres Zutun. Eine Regel, die nicht wirken soll, gehört nicht in dieses Verzeichnis.
+- Dateien mit Endung `.template` sind Vorlagen; sie enden nicht auf `.md` und werden deshalb nicht geladen.
+
+**Migration aus einer Installation vor 0.26.0:** `install.py --update` legt diese Fassung an, **löscht die alte README der Regelablage aber nicht.** Sie ist von Hand zu entfernen; solange sie liegt, lädt sie unbedingt mit.
+
+## Validierung
+
+```text
+python .koolie/core/tests/scripts/validate-framework.py
+```