Registry der übergreifenden Mandate (CM-1–CM-28)

Kanonische Registry der übergreifenden Mandate. Dieses Dokument trägt den vollständigen Inhalt der CM-N-Registry; die inhaltlichen Aufzählungen liegen hier und werden durch die Regeldateien unter src/apothem/rules/ operationalisiert. Jede Sitzung, die den ausführlichen CM-N-Inhalt benötigt, lädt dieses Dokument bei Bedarf.

Selbstreferenz-Ausnahme der RegistryCopy Anchor Link

Dieses Dokument IST die kanonische CM-N-Registry — es ist die Quelle, in der die Token CM-1 bis CM-28 definiert werden. Diese Token im eigenen Inhalt der Registry erneut zu nennen, ist kanonisch und kein Durchsickern plan-interner Terminologie. Die Invariante der Codebase-Isolation gilt weiterhin mit voller Kraft für jedes andere Artefakt, das keine veröffentlichte Dokumentation ist (Regeln, Helfer, Befehle, Hooks, Schemas, Skripte, Werkzeuge, Tests, README, CONTRIBUTING, Changelogs, Commit-Betreffzeilen/-Nachrichtentexte, Branch-Namen, PR-Titel/-Beschreibungen): keine CM-N- / TM-N- / CP-N-Token, ausschließlich natürliche Domänensprache.

Veröffentlichte Dokumentationsseiten unter site/content/docs/ dürfen ein Mandat über seine CM-N-ID zitieren, weil diese Registry und die Referenzseite der Regeln diese IDs für die Leser definieren. Eine Seite, die eine ID zitiert, SOLLTE das Mandat daneben in einfachen Worten benennen und DARF KEINE plan-internen Abschnittsnummern eines Mandats zitieren. TM-N- und CP-N-Token bleiben aus der veröffentlichten Dokumentation heraus, ebenso die übrigen verbotenen Begriffe im CM-7-Block unten.

NamensräumeCopy Anchor Link

CM-N = Konfigurationsmandat (hier definiert oder in src/apothem/rules/*.md gemäß der Regeltabelle in site/content/docs/reference/rules.mdx); TM-N = Template-Mandat (definiert in src/apothem/skills/plan-suite/master-template.md §4 „General Mandates“, TM-1–28); CP-N = Kernprinzip (definiert im selben Template, §6 „Core Principles“, CP-1–27). Das Plan-Suite-Template ist die kanonische TM/CP-Registry — /plan-Befehle lösen Querverweise über diese Datei auf. Helfer-Artefakte (Regeln, Helfer, Befehle, Hooks) zitieren diese Registry per Verweis.

AktivierungCopy Anchor Link

CM-1–10 + kognitive Identität regeln alle Interaktionen. CM-11, CM-13 (Unterregeln A bis C), CM-15, CM-16, CM-20 gelten nur innerhalb der /plan-Pipeline. Die Unterregel D von CM-13 gilt für jeden git-Schreibvorgang und die Unterregel E für die Ziele von git mv / git rm sowie für Pfade im Commit-Nachrichtentext, innerhalb wie außerhalb dieser Pipeline. CM-12, CM-14, CM-17–19, CM-21–22, CM-24–26 gelten universell. CM-23, CM-27, CM-28 gelten universell innerhalb ihres deklarierten Pfadfilter-Geltungsbereichs. Standard-Ernsthaftigkeitsstufe für Ad-hoc-Arbeit: PERSONAL_USE. Ein Mandat gilt unabhängig davon, ob seine Regel beim Start geladen wird: Vier Regeln werden in jeder Sitzung geladen (agnostic-posture, authority-inquiry, session-closure, context-management), und die übrigen werden bei einem passenden Pfad, über den Regelindex oder über eine Regel, einen Skill oder einen Befehl geladen, die sie zitieren.

CM-1–10 (Operativ)Copy Anchor Link

(1) Kritische Bewertung (→TM-10), (2) Null Annahmen (→TM-1), (3) Konfigurationsgesteuert (→TM-2), (4) Suchen vor dem Implementieren (→TM-4), (5) Beste Lösung (→TM-7), (6) Selbstverbesserung (→CP-20), (7) Kohärentes Produkt (→TM-11), (8) Fokus auf den Engpass zuerst, (9) Entscheidungsgeschwindigkeit, (10) Schonungslose Ehrlichkeit. Vollständige Definitionen mit Verstoßindikatoren: src/apothem/rules/operational-mandates.md.

CM-7 (Plan-interne Isolation)Copy Anchor Link

Dies ist die codebase-seitige Facette von CM-7; die Facette der Produktvollständigkeit ist als Kohärentes Produkt (→TM-11) in src/apothem/rules/operational-mandates.md §CM-7 dokumentiert. Beide Bezeichnungen beziehen sich auf dasselbe Mandat.

Codebase-Artefakte dürfen NIEMALS plan-interne Verweise enthalten. Verbotene Begriffe (kanonischer Block — gleichrangige Konsumenten verweisen auf diese Aufzählung): TM-N, CM-N, CP-N, „Resumption Contract“, „Phase Output Registry“, „convention anchors“, Namen von Phasenordnern, Dateinamen der Plan-Suite (PROGRESS.md, PLAN-NOTES.md, PREAMBLE, MASTER-PLAN), Namen der Ernsthaftigkeitsstufen (EXPLORING, PERSONAL_USE, SHARED, PUBLIC_LAUNCH). Geschützte Artefakte: Quellcode, Tests, Konfigurationen, Schemas, Build-Skripte, Daten, Assets, Commit-Nachrichten, Branch-Namen, PR-Titel/-Beschreibungen, README, CONTRIBUTING, API-Dokumentation, Changelogs — jedes Artefakt, das außerhalb des Apothem-Quellbaums sichtbar ist (die Installationsziele je Harness, etwa ~/.claude/ für Claude Code). Ausschließlich natürliche Domänensprache. Die einzige Ausnahme ist die veröffentlichte Dokumentation unter site/content/docs/, die CM-N-IDs zitieren darf, wie in der Selbstreferenz-Ausnahme der Registry oben beschrieben. Gleichrangige Konsumenten (jeder zitiert diesen Block per Verweis, statt ihn erneut aufzuzählen): src/apothem/hooks/messages/pretooluse-bash.md, src/apothem/hooks/messages/pretooluse-write.md, src/apothem/hooks/messages/pretooluse-edit.md, src/apothem/hooks/messages/pretooluse-notebookedit.md, die Verstoßindikatoren in src/apothem/rules/operational-mandates.md §CM-7.

CM-11 (Plan-Integrität)Copy Anchor Link

A — Prosatreue: Jede Anforderung ist Prosa↔Plan nachvollziehbar. Scorecard: PASS ≥90% STRONG/0 ABSENT. B — Interne Konsistenz: Dokumentübergreifende Kohärenz innerhalb der Plan-Suite. Scorecard: PASS 100%. C — Gates: FAIL blockiert die Ausführung ab SHARED+ (Override durch den Product Owner bei SHARED mit protokollierter Begründung erlaubt; harte Blockade bei PUBLIC_LAUNCH). Beratend bei PERSONAL_USE.

CM-12 (Kontextverwaltung)Copy Anchor Link

Schlanke Kontextverwaltung zu jeder Zeit — siehe die Regel zu CM-24. Vier Unterstufen sind im Abschnitt zur Unterreferenz-Konvention weiter unten aufgezählt. Die Kompaktierungsdisziplin (CM-19) regelt den Vorgang des Kompaktierens; CM-12 regelt die Disziplin im Dauerzustand.

CM-13 (Commits)Copy Anchor Link

• A — Rhythmus je Aufgabe: Je Aufgabe ab SHARED+. Je Phase bei PERSONAL_USE. Optional bei EXPLORING.
• B — Qualitäts-/Behebungs-Commits: Korrekturen für Qualitätstore und Behebungsänderungen werden sofort committet, getrennt von der Feature-Arbeit.
• C — Gate am Phasenende: Keine nicht committeten Änderungen überschreiten Phasengrenzen. Die CM-7-Isolation gilt für alle git-Artefakte. Bei PUBLIC_LAUNCH: GPG-signierte Commits (git commit -S) erforderlich.
• D — Ausschließlich menschliche Urheberschaft: Jede Urheberschaftsoberfläche in jedem git-Artefakt (Commit-Betreff, Commit-Nachrichtentext, Author:, Co-Authored-By:-Trailer, Signed-off-by:-Trailer, Branch-Name, Tag-Name, Tag-Annotation, Stash-Name, Inhalt von git-notes, PR-Titel, PR-Beschreibung) nennt ausschließlich menschliche Mitwirkende. Der Assistent schreibt niemals sich selbst, das zugrunde liegende Sprachmodell, die Laufzeit / den Harness / die IDE / die Erweiterung / den Anbieter oder ein sonstiges automatisiertes Werkzeug einer dieser Oberflächen zu. Verbotene Muster sind in src/apothem/rules/production-ready-prs.md §6 (Commit-Message Discipline → Human-only authorship) aufgezählt und werden dort mechanisch durchgesetzt; der Matcher in src/apothem/hooks/messages/pretooluse-bash.md, Scan 3, greift bei jedem git-schreibenden Bash-Aufruf.
• E — Disziplin bei numerischen Präfixen für git-mv- / git-rm-Ziele: Numerische Präfixe (NN-) auf Dateisystempfaden vermitteln eine Reihenfolge und gelten nur dort, wo die Reihenfolge intrinsisch ist — Sequenzen von Phasenordnern, Sequenzen von Unterphasen, vom Host erkannte ordinale Benennungsschemata. Einzelstücke auf Wurzelebene ohne gleichrangige Sequenz tragen kein numerisches Präfix; eines hinzuzufügen, ist bedeutungslose Dekoration, die fälschlich eine Reihenfolgebeziehung signalisiert, die nicht existiert. Vollständige Spezifikation in src/apothem/rules/canonical-layout.md §2.1. Mechanisch durchgesetzt in src/apothem/hooks/messages/pretooluse-bash.md, Scan 2, bei git mv / git rm und bei Pfadverweisen im Commit-Nachrichtentext.

CM-14 (Sitzungsprotokolle)Copy Anchor Link

Start: Blind Bootstrap ausführen (CM-24 §6). Ende: Phase Exit (CM-24 §2.5) + Gedächtnisauswertung (CM-26) + Artefaktentwicklung (CM-22 §2+§4) ausführen.

CM-15–21 (Pipeline)Copy Anchor Link

CM-15 und CM-16 sind hier inline definiert (keine separate Regel); CM-17–21 delegieren gemäß der Regeltabelle in site/content/docs/reference/rules.mdx an Regeln. Die Überschrift fasst diese Mandate thematisch zusammen; ihr Geltungsbereich folgt dem Absatz zur Aktivierung: CM-15, CM-16 und CM-20 gelten nur innerhalb der /plan-Pipeline, und CM-17–19 sowie CM-21 gelten universell.

• CM-15 Kollektive Kohärenz: Verifizieren, dass Plan-Artefakte nach einer Änderung kohärent bleiben.
• CM-16 Autonome Ausführung: Ab SHARED+ niemals zwischen Phasen anhalten. Kompaktierung an Phasenübergängen verpflichtend (PERSONAL_USE+).
• CM-17 Worker-Teams: Teams delegierter Worker für parallelisierbare Arbeit einsetzen — siehe die Regel zu CM-25.
• CM-18 Fehlerbehebung: Sechs allgemeine Klassen (CM-24 §8); Klassen der Planausführung in TM-18. Nach 3 Fehlschlägen eskalieren.
• CM-19 Kompaktierungsdisziplin: Proaktive Auslöser für die Kompaktierung — siehe CM-24 §3.
• CM-20 Pipeline-Orchestrierung: prose→[approval]→generate→[approval]→review→[approval]→execute(01→NN). Review-Techniken: src/apothem/rules/planning-techniques.md.
• CM-21 Kreative Qualität: Kognitive Filter sind Qualitätstore, keine Dekoration. Skalierung gemäß der Regel zur kognitiven Identität, §2.

CM-22–28 (An Regeln delegiert)Copy Anchor Link

Einzeilige Anker für die an Regeln delegierten Mandate (die vollständigen Spezifikationen liegen in den zitierten Dateien):

• CM-22 Wachsamkeit für Konventionen — Ökosystem-Konventionen und proaktive Weiterentwicklung von Artefakten. Siehe src/apothem/rules/persistent-conventions-vigilance.md.
• CM-23 Erzeugung großer Dateien — Protokoll zum inkrementellen Anhängen für Dateien oberhalb der Schwelle für einen einzelnen Schreibvorgang. Siehe src/apothem/rules/large-file-generation.md.
• CM-24 Protokoll der Kontextverwaltung — Externalisierung, Kompaktierung, Blind Bootstrap und Budgetdisziplin. Siehe src/apothem/rules/context-management.md.
• CM-25 Worker-Orchestrierung — Einsatzmuster, Rückgabeverträge, Kontextisolation. Vollständige Spezifikation in der Regel zur Worker-Orchestrierung.
• CM-26 Lebenszyklus des automatischen Gedächtnisses — Gedächtnisdisziplin, Organisation von Themendateien, Auswertung am Sitzungsende. Siehe src/apothem/rules/auto-memory.md.
• CM-27 Schichten der Clean Architecture — Trennung von Domain / Application / Infrastructure / Presentation. Siehe src/apothem/rules/clean-architecture-layers.md.
• CM-28 Senior-Architekt für Python — Leitplanken zu SOLID, Stil, Tests und Sicherheit für Python-Artefakte. Siehe src/apothem/rules/code-craft-python.md.

An Regeln delegierte vs. inline definierte MandateCopy Anchor Link

• An Regeln delegiert (vollständige Spezifikation in src/apothem/rules/): siehe die Spalte „Implements“ der Regeltabelle in site/content/docs/reference/rules.mdx. Umfasst CM-1–10, CM-12, CM-14, CM-17–28.
• Inline definiert (vollständige Spezifikation hier, keine separate Regel): CM-11 (Plan-Integrität), CM-13 (Commits; die Unterregeln D und E verweisen für ihre ausführliche Spezifikation auf Regeldateien), CM-15 (Kollektive Kohärenz), CM-16 (Autonome Ausführung).

Unterreferenz-KonventionCopy Anchor Link

Befehle verwenden Buchstabensuffixe, um auf bestimmte Unterabschnitte innerhalb von Mandaten zu verweisen. Muster: CM-N + Suffixbuchstabe = Regelabschnitt. Konvention zur Groß-/Kleinschreibung: Großbuchstaben als Suffix bezeichnen strukturelle Unterabschnitte innerhalb eines Mandats; Kleinbuchstaben als Suffix bezeichnen feiner gegliederte Direktiven innerhalb einer Stufe der Kontextverwaltung. Die kanonische Zuordnungstabelle der Unterreferenz-Schlüssel (registry-interne Definitionen) steht im folgenden Codeblock:

CM-11A = Prose Fidelity
CM-11B = Internal Consistency
CM-11C = Gates

CM-12a = lean ingestion / demand loading (context-management §7.2)
CM-12b = budget awareness (§7.1)
CM-12c = budget pressure response (§7.3)
CM-12d = per-task effort calibration (context-management §7.4 — D3 stratified taxonomy; PHASE.md frontmatter is the per-phase override surface)

CM-13A = per-task commits
CM-13B = quality / remediation commits
CM-13C = end-of-phase commit gate
CM-13D = human-only authorship
CM-13E = numeric-prefix discipline on git mv / git rm targets

CM-23A = pre-generation size assessment (§1)
CM-23B = incremental generation protocol (§2)

CM-24B = proactive externalization (§2)

CM-25A = worker-team patterns (§1)
CM-25C = return-contract enforcement (§4)
CM-25E = isolation / non-duplication (§5)