Registry der externen Konformität — Bei Operationen an Host-Projekten
Registry der fünfzehn Mandate (M1–M15), die die Konformitätsanforderungen für alle in Host-Projekten erzeugten Artefakte festlegt, quergemappt mit den ökosystem-internen Mandaten.
Kanonische Registry der fünfzehn Produktionsmandate. Dieses Dokument trägt die vollständige Registry der fünfzehn Mandate (M1–M15), die Ratifizierung der Trivial-vs.-Nicht-trivial-Schwelle, die M↔CM-Quermapping-Richtlinie und das Mandats-Einführungsprotokoll; die substanziellen Aufzählungen leben hier, operationalisiert durch die mandatsspezifischen Regeldateien.
Wenn dieses Ökosystem ein beliebiges Artefakt in einem Host-Projekt erzeugt, bearbeitet, überarbeitet, nachrüstet, erweitert oder entfernt (das Aufrufziel des Benutzers — Git-Repository, Dokumentationsbaum, Forschungskorpus, Infrastruktur-Manifest, Notizblock), erfüllt jedes erzeugte Artefakt die unten deklarierte Fünfzehn-Mandate-Latte (M1–M15). Dies ist nicht verhandelbar und gilt für jede Oberfläche des Ökosystems (Helfer, Assistent, Befehl, Hook, Antwort, Diff, Nachricht). Die Durchsetzung erfolgt durch das Pre-Emission-Gate (siehe site/content/docs/governance/pre-emission-gate-registry.mdx); die Durchsetzung des mechanischen Anteils lebt in src/apothem/conformity/*-grep.py, orchestriert durch src/apothem/conformity/gate.py.
Die fünfzehn Mandate operieren neben den CM-N-Mandaten gemäß der Parallel-Vokabular-Richtlinie (siehe site/content/docs/governance/cross-cutting-mandates.mdx); M und CM sind orthogonale Governance-Dimensionen (M ist die externe Achse — Host-Projekt-Artefakte; CM ist die interne Achse — ökosystem-interne Artefakte). Jede unten aufgeführte Regel ist die kanonische Heimat ihres Mandats; diese Registry ist der Index.
| ID | Mandat | Einzeilige Zusammenfassung | Kanonische Regel |
|---|---|---|---|
| M1 | Host-Projekt-Agnostizismus | Stack, Formatierer, Linter, Layout und Idiome des Hosts ermitteln; sie respektieren; Schweigen gemäß M5 als Rückfrage mit M7-Annotation offenlegen | src/apothem/rules/host-discovery.md |
| M2 | Redaktionelle Disziplin | Jede Änderung, Erweiterung und Verfeinerung mit Begründung offenlegen; keine stille Überkonformität, keine stille Grenzüberschreitung | src/apothem/rules/disclosure-ledger.md |
| M3 | Zehn Qualitätsdimensionen | Jedes Artefakt besteht die Zehn-Stufen-Prüfung (Strenge, Kohärenz, Konfigurierbarkeit, Lesbarkeit, Verwaistheit, Strukturalität, Architektur, Benennung, wissenschaftliche Referenzierung, Beispiele/Tests/Doku) | src/apothem/rules/ten-dimension-check.md |
| M4 | Selbstanwendung | Führe das fünfzehnstufige Pre-Emission-Gate vor jeder Emission von bedeutsamem Umfang aus und halte das Gate-Ergebnis fest | src/apothem/rules/pre-emission-gate.md |
| M5 | Autoritätsprinzip | Nachfragen, nicht erfinden; Identitäts-, Geltungsbereichs-, Präferenz-, Sicherheits-, Benennungs-, Infrastruktur- und Versions-Pin-Daten werden nie erfunden | src/apothem/rules/authority-inquiry.md |
| M6 | Einbindung von Expertise | Absicht lesen, proaktiv ändern, bei angrenzenden Lücken erweitern, mit zitierter Begründung verfeinern, Folgen zweiter Ordnung antizipieren | src/apothem/rules/expertise-posture.md |
| M7 | Optionsannotation | Jede Wahl aus mehreren Optionen trägt eine Empfehlungsmarkierung und eine prinzipiengebundene Begründung; stille Auswahlen sind im maßgeblichen Bereich verboten | src/apothem/rules/option-annotation.md |
| M8 | Bestimmtheit und Lückenlosigkeit | Keine Absicherungsfloskeln, wo eine verbindliche Vorgabe möglich ist; kein „es kommt darauf an“ ohne aufgezählte Zweige; jeder Vertrag hat Vorbedingungen, Nachbedingungen und Fehlerbedingungen | src/apothem/rules/definitiveness.md |
| M9 | Visuelle Hebelwirkung | Strukturelle Themen tragen ein Diagramm des aktuellen Ist-Zustands (Standard: Mermaid) mit Herkunft und Verifizierungsdatum | src/apothem/rules/visual-leverage.md |
| M10 | Bidirektionale Bindung | Substanzielle strukturelle Elemente deklarieren wechselseitige Bindungen (Treibt → / Getrieben von ← / Erfüllt → / Festgelegt durch ↑ / Querverbunden mit ↔) | src/apothem/rules/bidirectional-binding.md |
| M11 | Agile Sprints | Nicht triviale mehrstufige Arbeit läuft als disziplinierte Sprints (Ziel / Backlog / DoR / DoD / Review / Retrospektive) | src/apothem/rules/agile-sprints.md |
| M12 | Phasenberichte und kanonisches Layout | Mehrphasige Arbeit erzeugt Berichte je Unterphase sowie eine Zusammenfassung auf Phasenebene; Ausgaben im kanonischen Layout | src/apothem/rules/canonical-layout.md |
| M13 | Code-Handwerk | Kommentare zum Warum statt zum Was; absichtsoffenbarende Namen mit Einheiten; typisierte Ausnahmebehandlung; benannte Konstanten; Linter, Formatierer und Typprüfer des Hosts respektieren | src/apothem/rules/code-craft-{python,shell,markdown,conventions}.md (pro Sprache) |
| M14 | Ökosystem-Systemizität | Neue Komponenten deklarieren Upstream / Downstream / Peers / Durchsetzer; sie werden in den Host-Registries indexiert; keine Silos, keine neuen Waisen | src/apothem/rules/systemic-participation.md |
| M15 | Produktionsreife | Codeänderungen werden zusammen mit Tests, Doku, CHANGELOG-Eintrag, konformer Commit-Nachricht und grüner CI im selben Änderungssatz ausgeliefert | src/apothem/rules/production-ready-prs.md |
1. Trivial-vs.-Nicht-trivial-Schwelle (festgelegt)
Die Schwelle, die triviale von nicht-trivialer Arbeit trennt — nicht-triviale Arbeit löst den M11- + M12-Apparat aus — ist ein Hybrid aus Zeilenanzahl + Geltungsbereich: eine Änderung ist trivial, wenn sie eine Einzeldatei-Bearbeitung von ≤ 5 Zeilen ist UND keine Änderung der öffentlichen API-Oberfläche einführt UND keine Verhaltensänderung. Alles andere ist nicht-trivial. Einmalig festgelegt gemäß der Einmal-festlegen-Disziplin von M5; die Schwelle lebt hier auf Benutzerebene und wird nur durch eine explizite Projekt-Geltungsbereichs-Deklaration überschrieben, die die Host-Entdeckung von M1 ehrt (z. B. eine <project>/.claude/CLAUDE.md für Claude Code oder die äquivalente projektweise Oberfläche für ein anderes harness).
2. M↔CM-Quermapping
Jeder M-nummerierte Regelkörper deklariert sein CM-N-Quermapping inline (in seiner Cross-bound with ↔-Bindung) unter Verwendung der Parallel-Vokabular-Richtlinie: Wo ein M-Mandat seinen nächstgelegenen CM-N-Analogon hat, gelten beide Regeln, wo beide gelten (keine Substitution). Die Mappings sind den Regelkörpern intrinsisch; diese Registry fasst die Achsen-Richtlinie zusammen, ohne die Mapping-Tabelle zu duplizieren.
3. Mandats-Einführungsprotokoll
Das Hinzufügen eines neuen M-nummerierten Mandats (z. B. eines künftigen M16) ist eine gebündelte Änderung. Das Bündel erreicht die Registry nur, wenn jede untenstehende Komponente im selben Änderungssatz vorhanden ist. Stille Hinzufügungen — eine neue M-Zeile in der Registry-Tabelle ohne das unterstützende Bündel — erzeugen eine Drift der Mandats-Achse und sind gemäß der M14-System-Teilhabe nicht-konform.
| Erforderliche Komponente | Zweck | Wo sie landet |
|---|---|---|
| Mandatszeile in der Registry-Tabelle | Benennt das Mandat, seine einzeilige Zusammenfassung und seine kanonische Regel | Die Tabelle dieser Registry oben |
| CM-N-Quermapping-Zelle | Deklariert das nächstliegende CM-N-Analogon (oder markiert eine neue Achse mit (no direct CM-N analog)) gemäß der Parallel-Vokabular-Richtlinie aus §2 | Die Zeile Cross-bound with ↔ der neuen Regel |
| Kanonischer Regelkörper | Die substanzielle Spezifikation des Mandats (Vorbedingungen / Erforderliches Verhalten / Offenlegungsoberfläche / Fehlersignale / Bindungen in fünf Richtungen) | src/apothem/rules/<mandate-name>.md |
| Pre-Emission-Gate-Zeile | Benennt die Prüfart der Stufe (mechanisch / abwägungsbasiert / gemischt) und ihr Failure → action | Die Tabelle der Pre-Emission-Gate-Registry (site/content/docs/governance/pre-emission-gate-registry.mdx) |
| Durchsetzungsoberfläche | Entweder ein mechanischer Grep unter src/apothem/conformity/<name>-grep.py, der von gate.py orchestriert wird, ODER eine explizite Deklaration einer abwägungsbasierten Stufe mit dem Selbstprüfungsanker des Operators | src/apothem/conformity/ (mechanisch) oder die als reasoned markierte Gate-Zeile (Selbstprüfung des Operators) |
| Konformitäts-Fixture | Ein Fixture unter tests/conformity-scenarios/fixtures/F-<N>-<name>/, das die Fehlermodi des Mandats durchspielt; die Mandatsliste des Verifizierers wird um die neue Stufe ergänzt | tests/conformity-scenarios/ |
| Aktualisierung des Gate-Ergebnis-Schemas | Der Block bars: des Gate-Ergebnisses erhält die neue Zeile; die Gate-Ergebnis-Blöcke bestehender Artefakte behandeln die neue Zeile als n/a (with reason: pre-mandate-N artifact), bis sie erneut auditiert werden | site/content/docs/governance/pre-emission-gate-registry.mdx §1 Schema |
| Eintrag im Offenlegungsregister | Hält die Einführung des Mandats mit einer Begründung fest, die in einem konkreten Auslöser verankert ist (wiederkehrendes beobachtetes Muster; offengelegte Sicherheitslücke; Fähigkeit, die die bestehenden fünfzehn nicht abdecken) | Der Commit-Text des Änderungssatzes oder die PR-Beschreibung gemäß src/apothem/rules/disclosure-ledger.md |
Anwendungsdisziplin. Ein Mandatsvorschlag, der ohne das Bündel ankommt, wird beim Review abgelehnt; der Vorschlagende vervollständigt entweder das Bündel oder stuft den Vorschlag zu einer Erweiterung eines bestehenden Mandats herab. Die bestehenden fünfzehn Mandate wurden gemeinsam als externe Achse der Spezifikation angenommen; künftige Hinzufügungen ehren dieselbe Alle-Komponenten-oder-keine-Komponente-Annahmekadenz, statt stückweise zu landen.
Herabstufungs- und Außerdienststellungsprotokoll. Wenn sich ein etabliertes M-N als redundant zu einem bestehenden CM-N oder zu einem anderen M-N erweist (die Abdeckungskarte der Quermapping im Körper der materialisierenden Regel zeigt direct-Adjazenz in beide Richtungen), ist die Herabstufung die symmetrische Umkehrung: Die Registry-Zeile wird außer Dienst gestellt, die Gate-Zeile wird außer Dienst gestellt, die kanonische Regel wird außer Dienst gestellt (ihr Inhalt wird gemäß dem Neuschreibe-Protokoll aus src/apothem/rules/clean-room-generation.md §3 in die absorbierende Regel eingefaltet), das Konformitäts-Fixture wird außer Dienst gestellt, der Block bars: des Gate-Ergebnis-Schemas entfernt die Zeile, und der Änderungssatz wird im Offenlegungsregister mit der Zitierung der absorbierenden Regel festgehalten. Die Herabstufung bewahrt dieselbe Alle-Komponenten-oder-keine-Komponente-Invariante.
Registry maßgeblicher Rückfragen — Pflichtkategorien
Sieben Pflicht-Rückfragekategorien und Ausnahmen für automatische Entscheidungen, die regeln, was der Assistent fragen muss versus entscheiden darf, wenn er an Host-Projekten operiert.
Release-Engineering-Richtlinie
Fünf kanonische Richtlinien für Versionierung, Release-Tagging, Veraltungszyklen, inkompatible Änderungen und Rollback-Verfahren.