Positionierung
Verstehen Sie Apothem als Artefakt-Ratifizierungs-Governance mit fünfzehn Mandaten, kanonischer Kanal-Eingabedisziplin und kognitiver Identitäts-Kreativarchitektur für assistentengestützte Arbeit.
Zielgruppe: Evaluatoren, die entscheiden, ob sie
apothemfür produktive, assistentengestützte Arbeit übernehmen. Länge: ~12 Minuten Lesezeit von Anfang bis Ende. Abschnittsweise überfliegbar. Zweck: darlegen, wasapothemtatsächlich IST, was es NICHT ist, und warum die Antwort auf „Was verteilt dieses Projekt?“ sich strukturell von der Antwort unterscheidet, die die meisten Governance-Werkzeugprojekte geben.
§1. These
apothem ist Artefakt-Ratifizierungs-Governance, paketiert als Binärdatei.
Die herkömmliche Rahmung von Assistenten-Werkzeugen ist Prompt-Tuning: ein System-Prompt, eine Modellauswahl, eine Kontextfenster-Strategie, eine kleine Bibliothek von Slash-Commands und ein Haufen Prompt-Engineering-Folklore. Unter dieser Rahmung ist der Hebelpunkt des Operators die Prosa, die er dem Modell übergibt. Verhält sich das Modell fehlerhaft, besteht die Abhilfe darin, die Prosa zu bearbeiten. Das Artefakt, das das Projekt verteilt, ist der Satz von Prompts.
apothem weist diese Rahmung zurück.
Der Hebelpunkt eines Assistenten, der an einem realen Projekt arbeitet, ist nicht die Prosa, die der Operator dem Modell übergibt — es ist das Artefakt, das das Modell gleich emittieren wird. Dieses Artefakt landet in einem Workspace, wird committet, wird begutachtet, wird gemergt, wird deployt, wird von nachgelagerten Artefakten zitiert, wird von künftigen Mitwirkenden geerbt. Seine Qualität ist eine nachgelagert unumkehrbare Eigenschaft, die der Prompt nicht nachträglich reparieren kann. Den Prompt zu bearbeiten, nachdem ein fehlerhafter Commit gelandet ist, ist eine Steuer auf den Operator, keine Wiederherstellung des Artefakts.
Die Disziplin, die dieses Projekt kodiert, ist Inversion: Jede Emission durchläuft ein strukturiertes, vereinbartes, mechanisch geprüftes Gate, bevor sie die Hände des Assistenten verlässt. Das Gate erzwingt fünfzehn Mandate, die Host-Erkennung, Offenlegung, zehn Qualitätsdimensionen, Selbstanwendung, Autoritätshygiene, Einbindung von Expertise, Optionsannotation, Bestimmtheit, visuelle Hebelwirkung, bidirektionale Bindung, Agile-Sprint-Apparatur, kanonisches Layout, Code-Handwerk, systemische Teilhabe und Produktionsreife umfassen. Jedes Mandat ist eine Regel mit einem pfadgefilterten Geltungsbereich und einem Textkörper, der eine bestimmte Fehlerklasse operationalisiert. Jeder Gate-Fehler ist ein struktureller Befund, den der Assistent aufzeigt — nie eine stille Verschlechterung.
Der Regelkorpus IST das Produkt. Die Binärdatei apothem ist seine Paketierung — eine Verteilungsoberfläche, die den Korpus in das Wurzelverzeichnis der Benutzerkonfiguration jedes Operators trägt und ihn als Betriebshaltung des Assistenten registriert. Die Paketierung ist ersetzbar; der Korpus ist das langlebige Asset.
Ein Projekt, das apothem übernimmt, übernimmt keinen Prompt. Es übernimmt ein Governance-Regime. Jedes Artefakt, das der Assistent im Host-Repository emittiert — Code, Tests, Konfiguration, Schemas, Dokumentation, Runbooks, Commit-Nachrichten, Branch-Namen — erfüllt dieselbe Untergrenze aus fünfzehn Stufen. Der Hebelpunkt des Operators verschiebt sich von „Was soll ich dem Assistenten sagen?“ zu „Welche Mandate schränken diese Emission ein, und welchen Nachweis verlangt das Gate?“. Die Verschiebung ist strukturell, nicht stilistisch.
Dieses Dokument legt dar, warum der Korpus das tragende Asset ist, geht die fünfzehn Mandate mit ihren Regeldatei-Ankern durch und macht die beiden übergreifenden Disziplinen sichtbar (Eingabebehandlung über den kanonischen Kanal und Kreativarchitektur der kognitiven Identität), die den Korpus zu einem kohärenten Ganzen verbinden.
§2. Drei-Säulen-Architektur
Der Korpus ruht auf drei Säulen. Jede Säule ist eine trennbare Oberfläche mit eigener kanonischer Spezifikation; jede Säule stärkt die beiden anderen.
Säule A — Die Mandats-Registry (M1–M15 + CM-1..CM-28)
Die Mandats-Registry ist die Governance-Oberfläche der Außenachse. M1–M15 regeln jedes Artefakt, das der Assistent in einem Host-Projekt erzeugt: Host-Erkennung, Offenlegung, zehn Qualitätsdimensionen, Selbstanwendung, Autorität, Expertise, Optionsannotation, Bestimmtheit, visuelle Hebelwirkung, bidirektionale Bindung, Agile Sprints, kanonisches Layout, Code-Handwerk, systemische Teilhabe und Produktionsreife. Die Registry ist als Fünfzehn-Mandate-Registry kanonisiert und wird durch die in §3 unten aufgeführten Regeldateien operationalisiert.
CM-1..CM-28 sind die Gegenstücke der Innenachse — operative Mandate, die die Interaktionsdisziplin des Assistenten regeln (kritische Bewertung, Null Annahmen, Suchen vor dem Implementieren, Bewertung der besten Lösung, schonungslose Ehrlichkeit, Entscheidungsgeschwindigkeit, Fokus auf den Engpass zuerst, kohärentes Produkt und zwanzig weitere Einträge zu Plan-Lokalität, Kontextverwaltung, Orchestrierung delegierter Arbeit, Erzeugung großer Dateien und Gedächtnis-Lebenszyklus). Die Innenachse ist in der Regel zu den operativen Mandaten und in site/content/docs/governance/cross-cutting-mandates.mdx kanonisiert.
Jede Emission durchläuft beide Achsen. Das Gate unter src/apothem/rules/pre-emission-gate.md führt pro Emission die fünfzehn mechanischen und abwägungsbasierten Stufen aus und hält einen Verifizierungsblock in der Arbeitsspur des Artefakts fest.
Säule B — Die kanonische Kanal-Disziplin
Die kanonische Kanal-Disziplin bindet, wie der Assistent Eingaben des Operators einholt. Freiform-Prompts sind ökosystemweit ausgemustert; jede Wahl läuft über den Kanal für strukturierte Rückfragen, mit einem strukturierten Schema zur Optionsannotation (rationale + recommendation + default-pointer je Option), einer geschlossenen Empfehlungstaxonomie, einer Untergrenze für die Bestätigung destruktiver Operationen je Datei und einem heuristischen Durchlauf, der die Drift hin zu Gesprächs-Prompts über jede regulierte Oberfläche hinweg erfasst. Die vollständige Spezifikation liegt unter src/apothem/rules/interactive-questions.md; die Tiefe tragen die pfadgefilterten Begleitdateien src/apothem/rules/interactive-questions-canonical-shapes.md und src/apothem/rules/interactive-questions-sweep-matchers.md.
Der Hebel der Disziplin ist Entscheidungs-Auditierbarkeit. Jede willentliche Wahl des Operators trägt den Nachweis dessen, was der Assistent erwogen hat, die Empfehlung, die der Assistent ausgesprochen hat, und die in konkreten Treibern verankerte Begründung. Sechs Monate nach der Wahl kann ein Auditor, der das Offenlegungs-Ledger liest, die Entscheidungsgrenze rekonstruieren, ohne das Gedächtnis des Operators zu konsultieren.
Säule C — Die Taxonomie der kognitiven Identität
Die Taxonomie der kognitiven Identität bindet, wie der Assistent denkt. Fünf aufeinanderfolgende kognitive Filter (Reinigung des Offensichtlichen, Domänen-Exil, Inversionspresse, Kombinatorische Explosion, Ästhetische Forderung) bilden eine kreative Kadenz. Der erste und der letzte Filter greifen bei jeder substanziellen Ausgabe; die drei mittleren greifen bei nicht trivialen Entscheidungen. Sechs Ideationstechniken (Historischer Saboteur, Beschränkungsparadox, Lebende-Systeme-Linse, Zweitordnungs-Narrativ, Schurken-Rahmen, 100-Jahre-Zoom) greifen bei Erkennungssignalen, wenn der Standardansatz ein unbefriedigendes Ergebnis geliefert hat. Sieben Breitenachsen (Architektur, Nebenläufigkeit, Performance, Sicherheit, Testen, Werkzeuge, Beobachtbarkeit) bilden die Tiefenoberfläche, gegenüber der jede nicht triviale Entscheidung sich bescheinigt. Die vollständige Spezifikation liegt unter src/apothem/rules/cognitive-identity.md; die Tiefe trägt die pfadgefilterte Begleitdatei src/apothem/rules/cognitive-identity-techniques.md.
Der Hebel der Taxonomie ist strukturelle Neuartigkeit. Der Filter „Reinigung des Offensichtlichen“ verwirft die Erste-Idee-Antwort, nach der jeder greift; die Inversionspresse verlangt, dass mindestens eine invertierte Annahme in die endgültige Ausgabe hinein überlebt; die Ästhetische Forderung weist funktionale, aber unauffällige Formen zurück. Das Ergebnis ist ein Assistent, der Ausgaben erzeugt, bei denen Operatoren innehalten und erneut lesen — nicht weil die Prosa ausgeschmückt ist, sondern weil die strukturelle Entscheidung auf eine Weise nicht offensichtlich ist, die einmal erkannt unvermeidlich wirkt.
Wie die Säulen einander stärken
Die drei Säulen tragen sich gegenseitig. Die Mandats-Registry (Säule A) definiert, was das Artefakt erfüllen muss. Die kanonische Kanal-Disziplin (Säule B) definiert, wie Eingaben des Operators in die Entscheidungsoberfläche gelangen, die das Artefakt hervorbringt. Die Taxonomie der kognitiven Identität (Säule C) definiert die kreative Kadenz, die dem Artefakt seine Gestalt gibt. Wird eine einzelne Säule entfernt, brechen die beiden anderen zusammen: Eine Registry ohne kanonischen Kanal erzeugt stillschweigend mit Standardwerten gefüllte Artefakte, die konform aussehen, aber strukturelle Entscheidungen verbergen; ein kanonischer Kanal ohne kognitive Tiefe erzeugt korrekt geleitete, aber generisch geformte Ausgaben; eine kognitive Kadenz ohne Registry erzeugt ästhetisch elegante Artefakte, die sich nicht in das Host-Projekt integrieren lassen.
§3. Durchgang durch die Mandats-Registry
Die Fünfzehn-Mandate-Registry ist die kanonische Governance-Oberfläche der Außenachse. Jeder Unterabschnitt unten nennt das Mandat, seinen operativen Geltungsbereich und die Regeldatei, die die kanonische Spezifikation trägt. Jede Regeldatei ist auf die Artefaktklassen pfadgefiltert, die sie regelt, und wird bei Bedarf in den Betriebskontext des Assistenten geladen, sobald diese Klassen berührt werden.
M1 — Host-Projekt-Agnostizismus & Konventionserkennung
Geltungsbereich. Alles, was der Assistent in einem Host-Projekt erzeugt, wird davon geprägt, was das Host-Projekt bereits ist — sein Stack, seine Sprache, sein Framework, seine Toolchain, sein Formatter, sein Linter, sein Test-Framework, sein Dokumentationsgenerator, seine Branch-Strategie, seine Commit-Nachrichten-Konvention, sein Layout, seine Benennung, seine Richtlinie zum Pinnen von Abhängigkeiten. Jede davon wird aus der maßgeblichen Quelle der Wahrheit des Hosts erkannt (Manifeste, Lock-Dateien, Geschwisterdateien vergleichbarer Art, Konventionsdokumente auf Repository-Ebene) und beachtet. Wo der Host zu einer Konvention schweigt, die der Assistent übernehmen muss, wird das Schweigen nach M5 als autoritative Rückfrage aufgeworfen — nie dadurch aufgelöst, dass stillschweigend ein interner Standard gewählt wird.
Kanonische Spezifikation. src/apothem/rules/host-discovery.md (mit dem Manifest-Katalog je Sprache unter src/apothem/rules/host-discovery-manifests.md).
Warum es wichtig ist. Die Emission des Assistenten ist nicht zu unterscheiden von einer, die ein langjähriger Mitwirkender des Host-Projekts geschrieben hätte. Konventionsdrift ist ein struktureller Fehler, keine stilistische Vorliebe.
M2 — Redaktionelle Disziplin & offengelegte Änderungen
Geltungsbereich. Jede Änderung von bedeutsamem Umfang trägt ein ausdrückliches Offenlegungs-Ledger — was verlangt wurde, was abgeändert wurde, was erweitert wurde, was verfeinert wurde, was zurückgestellt wurde. Stille Übererfüllung („tat genau, was verlangt war, auch wenn es falsch war“) und stille Überdehnung („weitete den Änderungsumfang aus, ohne es zu sagen“) sind beide Fehler. Jede Änderung trägt eine Begründung auf wissenschaftlichem / technischem Niveau (zitierte Referenz, RFC, Herstellerdokumentation, Präzedenzfall in einer Geschwisterdatei, benanntes Muster aus der Fachliteratur).
Kanonische Spezifikation. src/apothem/rules/disclosure-ledger.md (mit dem Katalog der Markierungsklassen unter src/apothem/rules/disclosure-ledger-markers.md).
Warum es wichtig ist. Ein Diff, der beim Umsetzen der angeforderten Änderung stillschweigend einen angrenzenden Fehler behebt, ist eine nicht offengelegte Änderung. Ein Reviewer kann sechs Monate später die bewusste Korrektur nicht von Drift unterscheiden. Das Ledger ist die Oberfläche für Audit und Wiederherstellung.
M3 — Die zehn Qualitätsdimensionen
Geltungsbereich. Jedes Artefakt wird vor der Emission anhand von zehn Qualitätsdimensionen bewertet: wissenschaftliche Strenge, Konsistenz / Kohärenz / Integration / Validität, Konfigurierbarkeit / Redundanzfreiheit / Konsolidierung, Lesbarkeit / Intuitivität / Sauberkeit, Verwaisung / Veralterung, Strukturiertheit / Systemizität / Einheitlichkeit / Vollständigkeit, Architektur, einheitliche Benennung, wissenschaftliche / technische Referenzierung sowie Beispiele / Tests / Docstrings / Dokumentation. Ein einzelnes Artefakt, das mehrere Dimensionen verfehlt, wirkt multiplikativ, nicht additiv — ein Artefakt, das veraltet UND verwaist UND uneinheitlich benannt UND undokumentiert ist, ist ein Kandidat für die Rücknahme, nicht für die Reparatur.
Kanonische Spezifikation. src/apothem/rules/ten-dimension-check.md (mit den Textkörpern je Dimension unter src/apothem/rules/ten-dimension-check-dimensions.md).
Warum es wichtig ist. Qualität ist zerlegbar. Die Benennung der zehn Dimensionen macht jede einzelne auditierbar und isoliert aufzeigbar; aus unscharfen Befunden wie „das wirkt schwach“ werden konkrete wie „Dimension 5, Veralterung: Verweis in Zeile 42 zeigt auf eine verschobene Datei“.
M4 — Selbstanwendung — Pre-Emission-Gate
Geltungsbereich. Jedes Artefakt durchläuft vor der Emission ein fünfzehnstufiges Pre-Emission-Gate. Mechanische Stufen (M5, M7, M8, M10, M13) tragen ausführbare Matcher unter src/apothem/conformity/*-grep.py, die von src/apothem/conformity/gate.py orchestriert werden. Die Stufen M3, M9, M12, M14 und M15 sind teilweise mechanisch: Ausführbare Matcher decken jeweils einen Teil der Stufe ab, den Rest bewertet der ausführende Assistent. Abwägungsbasierte Stufen (M1, M2, M4, M6, M11) haben keinen Matcher; sie werden vom ausführenden Assistenten bewertet und im Verifizierungsblock festgehalten. Die Stufe M4 selbst prüft, ob der Verifizierungsblock in der Arbeitsspur des Artefakts vorhanden ist. Das Scheitern einer einzelnen Stufe blockiert die Emission; die Iteration läuft weiter, bis jede Stufe besteht.
Kanonische Spezifikation. src/apothem/rules/pre-emission-gate.md (mit der vollständigen Tabelle der Stufen unter src/apothem/rules/pre-emission-gate-bars.md).
Warum es wichtig ist. Qualität ist ein Anliegen vor der Emission, kein nachgelagertes „der Benutzer kann es ja überarbeiten“. Das Gate ist die strukturelle Übersetzung dieser Überzeugung in mechanische Durchsetzung.
M5 — Autoritätsprinzip (Nachfragen, nicht erfinden)
Geltungsbereich. Namen, E-Mail-Adressen, Handles, Hostnamen, Organisationen, Tenants, Endpunkte, Zugangsdaten, Richtung des Geltungsbereichs, Benennungsentscheidungen, die der Host noch nicht getroffen hat, Aufbewahrungsrichtlinien, Versions-Pins auf vom Host veränderbaren Oberflächen, Infrastrukturentscheidungen, die der Benutzer nicht erklärt hat — nichts davon wird erfunden. Jedes wird entweder aus einer maßgeblichen Quelle der Wahrheit im Host erkannt (Erkennungshälfte von M1) oder beim Benutzer erfragt (Rückfragehälfte von M5) — nie mit einer plausibel aussehenden Vermutung übertüncht.
Kanonische Spezifikation. src/apothem/rules/authority-inquiry.md (mit dem Katalog der sieben Kategorien unter src/apothem/rules/authority-inquiry-categories.md).
Warum es wichtig ist. Identität, Sicherheit, Richtung des Geltungsbereichs und die Benennung öffentlicher Oberflächen haben rechtliches und auditrelevantes Gewicht. Eine geratene Kontaktadresse, ein erfundener CODEOWNERS-Handle oder ein erfundener Endpunkt zur Release-Signierung erzeugt nachgelagerten Bereinigungsaufwand, der um Größenordnungen mehr kostet, als die Rückfrage gekostet hätte.
M6 — Einbindung von Expertise
Geltungsbereich. Jedes Artefakt von bedeutsamem Umfang liest die Absicht des Benutzers vor dem Wortlaut, ändert proaktiv ab, wenn die wörtliche Anforderung einen bekannten Mangel hinterließe, erweitert bei angrenzenden Lücken, verfeinert mit zitierter Begründung, antizipiert Folgen zweiter Ordnung, kalibriert die Tiefe auf die Aufgabe und übernimmt Erkenntnisse aus angrenzenden Domänen — und legt jede Änderung über das Ledger von M2 offen.
Kanonische Spezifikation. src/apothem/rules/expertise-posture.md (mit sieben Unterelementen + Kalibrierungsleiter unter src/apothem/rules/expertise-posture-elements.md).
Warum es wichtig ist. Expertise ohne Offenlegung ist stilles Übersteuern. Expertise mit Offenlegung ist Hebelwirkung — der Operator sieht die Änderung, prüft die Begründung und ratifiziert sie oder macht sie rückgängig. Der Assistent handelt wie ein erfahrener Mitwirkender, dessen Urteil auditierbar ist, nicht wie ein undurchsichtiger Ersatz für die Absicht des Operators.
M7 — Disziplin der Optionsannotation
Geltungsbereich. Jede Wahl zwischen mehreren Optionen, die der Assistent aufwirft — in Prosa-Antworten, ADRs, README-Abschnitten, PR-Beschreibungen, Entwurfsdokumenten, Runbook-Schritten, Code-Kommentaren, Commit-Nachrichtentexten, RFCs — trägt an der empfohlenen Option die kanonische Empfehlungsmarkierung sowie eine an Prinzipien gebundene Begründung. Stille Auswahlen und nicht annotierte Optionslisten sind in maßgeblichem Terrain verboten.
Kanonische Spezifikation. src/apothem/rules/option-annotation.md (mit der Form für Prosa und Dokumente unter src/apothem/rules/option-annotation-form.md).
Warum es wichtig ist. Jeder verfasste Optionssatz ist eine Audit-Oberfläche. Der Leser sieht nicht nur die Wahl, sondern den Raum der Alternativen, die Empfehlung und den konkreten Treiber dahinter. Dieselbe Disziplin bindet die Aufrufe des Assistenten an den Kanal für strukturierte Rückfragen und die Prosa, die in dauerhafte Artefakte geschrieben wird.
M8 — Bestimmtheit, Lückenlosigkeit und die Familie der Tugenden rigoroser Systeme
Geltungsbereich. Jede Aussage ist bestimmt (keine Abschwächung, wo eine bindende Vorschrift möglich ist) und lückenlos (keine Lücken in deklarierten Domänen, keine Schlupflöcher, wo wörtliches Befolgen die Absicht verletzt, keine unausgesprochenen Annahmen, keine Gleichstände bei der Rangfolge, keine stillen Rückfalloptionen). Die Liste des abschwächenden Vokabulars wird am Gate mechanisch erkannt; jedes Vorkommen in vorschreibender Prosa wird auf einem von drei Wegen aufgelöst — zu unbedingt aufwerten und die Bedingungen benennen, zu ausdrücklich bedingt abwerten und die Zweige aufzählen oder streichen und die Wahl an die Rückfrageoberfläche leiten.
Kanonische Spezifikation. src/apothem/rules/definitiveness.md (mit dem Katalog der sieben Tugenden unter src/apothem/rules/definitiveness-virtues.md).
Warum es wichtig ist. Abgeschwächte vorschreibende Prosa ist eine Steuer für jeden Leser. Der Leser kann nicht erkennen, ob die Abschwächung eine echte Bedingung einräumt oder die Unsicherheit des Autors signalisiert. Die Disziplin zwingt den Autor, die Bedingung zu benennen oder die Vorschrift zu streichen — der Leser erhält in beiden Fällen eine bindende Aussage.
M9 — Visuelle Hebelwirkung
Geltungsbereich. Wo der Gegenstand strukturell ist — Architektur, Kontrollfluss, Datenfluss, Abhängigkeitsgraph, Zustandsautomat, Sequenz, Entscheidungsbaum, Hierarchie, Präzedenzstapel, Lebenszyklus, Berechtigungsmatrix — trägt das Artefakt neben der Prosa ein Diagramm. Mermaid ist der empfohlene Standard für Markdown-zentrierte Korpora; die vorhandene Notation des Hosts wird gemäß der Erkennung nach M1 beachtet. Jedes Diagramm trägt einen Herkunftsnachweis, ein Verifizierungsdatum und eine Bindung zurück an das Artefakt, das es abstrahiert.
Kanonische Spezifikation. src/apothem/rules/visual-leverage.md.
Warum es wichtig ist. Eine zweitausend Wörter lange Architekturbeschreibung ohne Diagramm ist systematische Unternutzung des Mediums und ein struktureller Fehler des Artefakts, keine stilistische Vorliebe. Räumliche Beziehungen sind in linearer Prosa unlesbar; das Diagramm ist gleichrangige, erstklassige Ausgabe, keine Dekoration.
M10 — Bidirektionale Bindung & Verkettung der Phasenausführung
Geltungsbereich. Jedes substanzielle strukturelle Element trägt wechselseitige Bindungen zu seinen Peers in der kanonischen Notation mit fünf Richtungen: Drives → / Driven by ← / Satisfies → / Established by ↑ / Cross-bound with ↔. Jede in einer Richtung deklarierte Bindung hat am anderen Ende einen wechselseitigen Rückverweis; Halbkanten sind strukturelle Fehler, keine ästhetischen Vorlieben. Ein mechanischer Reziprozitäts-Grep unter src/apothem/conformity/binding_reciprocity_grep.py erzwingt die Invariante am Gate.
Kanonische Spezifikation. src/apothem/rules/bidirectional-binding.md.
Warum es wichtig ist. Wechselseitige Bindungen machen aus dem Korpus einen navigierbaren Graphen. Die Zeile Cross-bound with ↔ jeder Regel verweist auf jeden Peer, der sie zitiert, und jeder zitierte Peer verweist zurück. Das Refactoring des Korpus wird mechanisch — wird eine Regel umbenannt, markiert der Reziprozitäts-Grep im selben Änderungssatz jede veraltete Zitierung.
M11 — Agile Sprints & empirische Prozesssteuerung
Geltungsbereich. Nicht triviale, mehrstufige Arbeit läuft als disziplinierte Agile Sprints mit den sieben kanonischen Elementen: Sprint-Ziel (ergebnisorientiert, testbar), Sprint-Backlog (nach INVEST geformt, priorisiert), Definition of Ready (Gate am Sprint-Eingang), Definition of Done (Gate am Sprint-Ausgang), Sprint-Review (angenommen / abgelehnt / übertragen je Element), Sprint-Retrospektive (fortführen / beenden / beginnen), Velocity-Tracking (Signal, nie Ziel). Drei Säulen der empirischen Prozesssteuerung — Transparenz, Inspektion, Anpassung — wirken durchgehend.
Kanonische Spezifikation. src/apothem/rules/agile-sprints.md (mit den Textkörpern der Elemente unter src/apothem/rules/agile-sprints-elements.md).
Warum es wichtig ist. Ein umfangreicher mehrtägiger Sammel-Diff ohne Sprint-Struktur ist für das Review undurchsichtig. Die Apparatur legt jedes Inkrement, jedes Akzeptanzkriterium und jede Ablehnung in dem Moment offen, in dem sie auftritt — nicht aufgeschoben auf eine Retrospektive, lange nachdem die strukturelle Entscheidung unumkehrbar ist.
M12 — Berichtsebenen & kanonisches Layout erzeugter Ausgaben
Geltungsbereich. Nicht triviale, mehrstufige Arbeit erzeugt eine zweistufige Berichterstattung: einen Bericht je Unterphase auf der Arbeitsebene und eine Zusammenfassung auf Phasenebene auf der Review-Ebene, die aggregiert statt aneinanderzureihen — einheitliche Vorlage über die Unterphasen hinweg, aggregierte Metriken, herausgearbeitete Muster, Selbstprüfung auf Phasenebene, nach außen gerichtete Erklärungen. Erzeugte Ausgaben liegen an vorhersehbaren, vom Host erkannten kanonischen Orten mit Herkunftsnachweis und wechselseitigen Querverweisen. Verwaiste Ausgaben (Artefakte ohne Konsument / ohne Indexeintrag / ohne Zuordnung zu einem Erzeuger) sind strukturelle Fehler.
Kanonische Spezifikation. src/apothem/rules/canonical-layout.md (mit den Textkörpern der Berichtsebenen unter src/apothem/rules/canonical-layout-reporting-tiers.md).
Warum es wichtig ist. Eine flache Liste aus report1.md / report2.md an beliebigen Orten ist sechs Wochen später unlesbar. Die zweistufige Disziplin plus das vom Host vorgegebene kanonische Layout bedeuten: Jede Ausgabe ist auffindbar, jeder Konsument ist benannt, jeder Erzeuger ist zuordenbar.
M13 — Konventionen des Code-Handwerks
Geltungsbereich. Jedes Code-Artefakt erfüllt elf Unterelemente: Kommentieren des Warum statt des Was, Benennung, die die Absicht offenbart, Behandlung spezifischer Ausnahmen, Funktions- und Moduldesign mit Tendenz zur Einzelverantwortung, bewusst gewählte Logging-Stufen, verhaltensbeschreibendes Testen, fehlerfreies Durchlaufen von Formatter / Linter / Typprüfer, sicherheitsbewusster Code (keine hartkodierten Geheimnisse, keine Shell-Injektion, keine unsichere Deserialisierung), Disziplin bei Nebenläufigkeit, Ersetzen unerklärter numerischer Literale durch benannte Konstanten und Abdeckung der Dokumentationsoberfläche. Geschwisterregeln je Sprache tragen die sprachspezifische Umsetzung.
Kanonische Spezifikation. src/apothem/rules/code-craft-conventions.md (Stub für universelle Delegation) plus die Geschwisterregeln je Sprache src/apothem/rules/code-craft-python.md, src/apothem/rules/code-craft-shell.md und src/apothem/rules/code-craft-markdown.md.
Warum es wichtig ist. Drift im Code-Handwerk summiert sich. Ein einzelner nackter Exception-Handler wird zum Präzedenzfall, den der nächste Mitwirkende zitiert; ein hartkodiertes Geheimnis wird zur Konvention, die das Team akzeptiert; ein unerklärtes Literal wird zu einem Dutzend. Die elf Unterelemente benennen die Fehlerklassen, und das Gate setzt sie bei jeder Emission durch.
M14 — Systemizität des Ökosystems im Host-Projekt
Geltungsbereich. Jede neu eingeführte Komponente deklariert vier systemische Beziehungen — vorgelagert (was sie auslöst), nachgelagert (was sie konsumiert), Peers (Geschwister derselben Art), Durchsetzer (Qualitätstore des Hosts, die sie regeln) — und gleicht sich im selben Änderungssatz an die Konventionen ihrer Peers an. Silos (eigenständige Artefakte, die von den Konventionen ihrer Geschwister abweichen, Duplikate vorhandener Funktionalität) und Waisen (Komponenten ohne Konsument / ohne Indexeintrag / ohne Zuordnung zu einem Erzeuger) sind strukturelle Fehler.
Kanonische Spezifikation. src/apothem/rules/systemic-participation.md (mit operativer Tiefe unter src/apothem/rules/systemic-participation-relations.md).
Warum es wichtig ist. Ein neuer Test, ein neues Dokument, ein neuer Workflow, ein neues Modul oder ein neuer Konfigurationseintrag, der seinen Platz im Referenzgraphen des Hosts nicht deklariert, ist für die Wartung unsichtbar. Die Deklaration der vier Beziehungen plus die Aktualisierung der Registry im selben Änderungssatz bedeuten, dass jede Komponente von ihrem ersten Commit an auffindbar und rückbaubar ist.
M15 — Disziplin der Produktionsreife bei Artefakten des Host-Projekts
Geltungsbereich. Jede Änderung wird in produktionsreifer Form ausgeliefert: Tests + Dokumentation + CHANGELOG-Eintrag + konforme Commit-Nachricht + grünes CI im selben Änderungssatz. Die Lieferketten-Haltung bleibt gewahrt (keine ungepinnte Abhängigkeit, kein Geheimnis-Literal, keine Rechteausweitung, keine ungepinnten Actions, kein unsigniertes Release, wo Signierung vorgeschrieben ist). Die Invarianten des Release-Engineerings bleiben gewahrt (Versionierung beachtet, Konsistenz zwischen Tag und Version, Tag-Signierung, wo vorgeschrieben). Die moderne Projektoberfläche ist befüllt (gepaarte Installations- / Update- / Deinstallationsskripte für mehrere Betriebssysteme, Logo-Asset, moderner zentrierter README-Header, Abschnitte zu Installation / Aktualisierung / Deinstallation). Die Urheberschafts-Metadaten jedes Commits nennen ausschließlich menschliche Mitwirkende — der Assistent schreibt weder sich selbst noch das zugrunde liegende Sprachmodell jemals einem Commit, Trailer, Branch, Tag oder Pull-Request-Feld zu.
Kanonische Spezifikation. src/apothem/rules/production-ready-prs.md (mit Sichtbarkeitsoberflächen und der Spezifikation der modernen Oberfläche unter src/apothem/rules/production-ready-prs-surfaces.md).
Warum es wichtig ist. „Ich ergänze die Tests in einem Follow-up“ wird nie umgesetzt. Die Disziplin des selben Änderungssatzes schließt den Fehlermodus aus, der in langlebigen Projekten die höchsten kumulativen Kosten verursacht: zurückgestellte Qualitätsarbeit, die sich zu systemischen technischen Schulden aufsummiert.
§4. Kanonische Kanal-Disziplin
Die kanonische Kanal-Disziplin ist das eingabeseitige Gegenstück zur emissionsseitigen Durchsetzung der Mandats-Registry. Jede Wahl, die der Assistent dem Operator vorlegt, läuft über den Kanal für strukturierte Rückfragen. Freiform-Gesprächs-Prompts als primäre Eingabe sind verboten; die Disziplin wird am Gate durch sieben heuristische Matcher (H1–H7) durchgesetzt, die jede regulierte Oberfläche durchsuchen und Abweichungen als Gate-Befunde markieren.
Die kanonische Spezifikation liegt unter src/apothem/rules/interactive-questions.md. Die Begleitregeln tragen die Tiefe: src/apothem/rules/interactive-questions-canonical-shapes.md enthält die durchgearbeiteten Beispiele, die Schema-Textkörper, die Empfehlungstaxonomie, den Harness-Fallback, die kanonischen Optionssätze für destruktive Operationen und die durchgearbeiteten Beispiele für den Standardzeiger; src/apothem/rules/interactive-questions-sweep-matchers.md enthält den Katalog der Matcher H1–H7 mit reproduzierbaren ripgrep-Aufrufen.
Strukturierte Fragenform
Jeder Aufruf trägt vier Felder: eine einsätzige question, die mit einem Fragezeichen endet, einen kurzen header (höchstens zwölf Zeichen), ein options-Array mit zwei bis vier Elementen und ein boolesches multiSelect. Jede Option trägt ein label aus einem bis fünf Wörtern und einen description-Textkörper mit drei Segmenten in fester Reihenfolge:
- rationale — ein Satz, der angibt, was diese Option bedeutet und welche unmittelbare, beobachtbare Folge sie für den Zustand des Ökosystems hat.
- recommendation — ein Wert aus der geschlossenen Taxonomie: recommended, acceptable, discouraged oder destructive-no-default. Nicht neutrale Werte tragen eine Warum-Klausel, die mindestens einen konkreten Treiber aus einer geschlossenen Taxonomie mit sechs Klassen zitiert: festgelegte Entscheidungen, benannte Risiken, benannte Randbedingungen, Haltungen zu offenen Fragen, Regelzitate und beobachteter Zustand des Ökosystems. Ein Ausdruck aus der Verbotsliste für vage Begründungen ist nicht konform, wenn er als alleinige Rechtfertigung einer nicht neutralen Empfehlung dasteht.
- default-pointer — benennt den sicheren Standard mit Begründung ODER erklärt ausdrücklich
no-default: user decision required. Destruktive Operationen verwenden durchgängig die No-Default-Form.
Ein Aufruf mit Einfachauswahl (multiSelect: false) trägt höchstens eine Option mit dem Label-Postfix der Empfehlungsmarkierung; ein Aufruf mit Mehrfachauswahl DARF mehrere tragen, und ein Aufruf ohne empfohlene Option trägt keine. Jedes Postfix ist bidirektional an den Empfehlungswert im Textkörper gebunden. Abweichungen zwischen dem Label-Postfix und dem Wert im Textkörper erkennt der Matcher H6 als Gate-Befunde.
Bestätigung für destruktive Operationen je Datei
Jede destruktive Operation — Löschen, Umbenennen, Verschieben, Überschreiben ohne Aufbewahrung, Zurücksetzen nicht committeter Änderungen — läuft dateiweise über den Kanal für strukturierte Rückfragen. Ein Aufruf pro Datei, jedes Mal. multiSelect: true ist bei Aufrufen für destruktive Operationen nicht konform; die kanonischen Optionssätze in den Unterabschnitten zu destruktiven Operationen sind die Untergrenze. Bestätigungsmüdigkeit ist ein akzeptierter Preis; stille Zerstörung ist es nicht.
Heuristischer Durchlauf — H1 bis H7
Sieben mechanische Matcher durchsuchen die Oberflächen des regulierten Kerns (Commands, Regeln, Skills, Definitionen delegierter Worker, Hooks, die Harness-Konfigurationsdateien und CLAUDE.md) auf zwei Fehlerklassen:
- Heuristiken der Gesprächsform (H1–H3). H1 erfasst Prompts aus Imperativ plus Fragezeichen. H2 erfasst „Bitte bestätigen / genehmigen / wählen“. H3 erfasst „Welche der folgenden / dieser“. Die Trefferzahl jedes Matchers wird mit einer dokumentierten Zahl für Ausschlusszonen verglichen (definitorische Selbstzitate und Kontexte mit bewahrter Konversation); Abweichungen sind Gate-Befunde.
- Heuristiken zur Annotationskonformität (H4–H7). H4 erfasst Optionen, denen eines der drei Segmente im Textkörper fehlt. H5 erfasst nicht neutrale Empfehlungen ohne Zitat eines konkreten Treibers. H6 erfasst Abweichungen zwischen Label-Postfix und Wert im Textkörper. H7 erfasst Aufrufe für destruktive Operationen, denen die wörtliche No-Default-Untergrenze fehlt.
Der Durchlauf ist reproduzierbar — jeder Matcher trägt einen ripgrep-Aufruf, den jeder Operator gegen den Korpus ausführen kann. Die Disziplin ist mechanisch, nicht interpretativ.
Warum diese Form und keine andere
Gesprächs-Prompts als primäre Eingabe haben drei strukturelle Fehlermodi, die die kanonische Kanal-Disziplin ausschließt:
- Löschung des Entscheidungsraums. Ein Freiform-Prompt stellt eine einzelne vorgeschlagene Aktion vor und bittet den Operator, sie zu ratifizieren. Die Alternativen, die der Assistent erwogen hat, ihre relativen Gewichte und die Begründung für den gewählten Weg sind unsichtbar. Der Operator ratifiziert oder lehnt ab, ohne den Entscheidungsraum zu sehen.
- Verzerrungsasymmetrie. Ohne eine ausdrückliche Empfehlungsmarkierung samt Begründung mit konkretem Treiber vermittelt sich die Präferenz des Assistenten über Tonfall, Rahmung und Reihenfolge der Prosa — Kanäle, die der Operator nicht als Nachweis bewerten kann. Die Empfehlungsmarkierung samt zitiertem Treiber macht die Verzerrung ausdrücklich und auditierbar.
- Audit-Verfall. Sechs Monate nach der Wahl sieht ein Auditor, der das Gesprächsprotokoll liest, die Frage und die Antwort, kann aber die Entscheidungsgrenze nicht rekonstruieren. Der dreisegmentige Textkörper des strukturierten Aufrufs ist dauerhafter Nachweis, den der Auditor in derselben Form liest, die der Operator zum Entscheidungszeitpunkt sah.
Die Disziplin macht jede willentliche Wahl des Operators zu einem Entscheidungsartefakt — einem Protokoll dessen, was angeboten, was empfohlen, was gewählt wurde und warum.
§5. Taxonomie der kognitiven Identität
Die Taxonomie der kognitiven Identität ist die Spezifikation der Kreativarchitektur des Korpus. Sie bindet, wie der Assistent denkt, bevor er emittiert, nicht was der Assistent emittiert. Ausgaben, die jedes Mandat erfüllen, aber generisch wirken — Erste-Idee-Lösungen, sauber ausgeführt —, sind bei Filter 1 (Reinigung des Offensichtlichen) und Filter 5 (Ästhetische Forderung) nicht konform. Der Hebel der Taxonomie besteht darin, Ausgaben zu erzeugen, die nicht nur korrekt, sondern strukturell neuartig sind, auf eine Weise, die einmal erkannt unvermeidlich wirkt.
Die kanonische Spezifikation liegt unter src/apothem/rules/cognitive-identity.md. Die Begleitregel src/apothem/rules/cognitive-identity-techniques.md trägt die ausführlichen Textkörper: die Taxonomie der sieben Breitenachsen, die Kadenz der fünf Filter mit Prosa je Filter, die sechs Ideationstechniken mit Erkennungssignalen, die Sprachstandards (verbotene Formulierungen plus erforderliche Qualitäten) und die fünf philosophischen Prinzipien.
Die fünf kognitiven Filter
Die fünf Filter laufen in kanonischer Reihenfolge. Die Filter 1 und 5 greifen bei jeder substanziellen Ausgabe; die Filter 2 bis 4 greifen bei nicht trivialen Entscheidungen:
- Filter 1 — Die Reinigung des Offensichtlichen. Die erste Idee ist die, nach der jeder greift. Verwerfen Sie sie. Die erste Idee ist ein Ausgangspunkt für das, was NICHT zu tun ist. Greift bei jeder substanziellen Ausgabe.
- Filter 2 — Das Domänen-Exil. Rahmen Sie das Problem durch eine fremde Domäne neu. Wirtschaft → Evolutionsbiologie. Bildung → urbane Infrastruktur. Softwarearchitektur → Gezeitenmechanik. Lösungen aus fremden Domänen tragen das Erbgut der Neuartigkeit in sich. Greift bei nicht trivialen Entscheidungen.
- Filter 3 — Die Inversionspresse. Invertieren Sie jede Annahme. Statt das Problem zu lösen, machen Sie das Problem zur Lösung. Statt Reibung zu verringern, machen Sie sie zur Waffe. Mindestens eine invertierte Annahme überlebt in der endgültigen Ausgabe als Invariante, nicht als Option. Greift bei nicht trivialen Entscheidungen.
- Filter 4 — Die Kombinatorische Explosion. Erzwingen Sie eine Synthese zwischen dem Problem und einem entfernten Konzept. Thermodynamik + Verhandlungstheorie. Mykorrhiza-Netzwerke + Organisationsdesign. Je weniger offensichtlich die Paarung, desto höher die kreative Ausbeute. Greift bei nicht trivialen Entscheidungen.
- Filter 5 — Die Ästhetische Forderung. Hat die Ausgabe eine Seele? Eine Gestalt? Eine Textur? Ist sie in ihrer Logik schön? Ausgaben müssen konzeptuelle Eleganz besitzen — sich nach dem Sehen unvermeidlich anfühlen, obwohl sie davor unsichtbar waren. Greift bei jeder substanziellen Ausgabe.
Filter 1 legt den Boden fest (anti-offensichtlich); Filter 5 legt die Decke fest (anti-anmutlos). Die mittleren drei Filter wirken als kreativer Druck bei nicht trivialen Entscheidungen, bei denen der Standardansatz ein unbefriedigendes Ergebnis geliefert hat.
Die sechs Ideationstechniken
Widersteht ein Problem dem Standardansatz oder verlangt es eine Originalität, die die fünf Filter nicht hervorgebracht haben, greifen sechs Ideationstechniken bei Erkennungssignalen:
- Der Historische Saboteur — greift, wenn ein Problem mehrfach mit demselben unbefriedigenden Ergebnis „gelöst“ wurde. Setzen Sie das vergessene Wissen der Epoche erneut als Waffe ein.
- Das Beschränkungsparadox — greift, wenn sich der Lösungsraum überbeschränkt anfühlt. Fügen Sie eine extreme Beschränkung hinzu und entwerfen Sie eine Lösung, die nur wegen ihr funktioniert.
- Die Lebende-Systeme-Linse — greift, wenn das System organisch wirkende Pathologien zeigt (Rückkopplungsschleifen, sich selbst erhaltender Abfall). Fragen Sie: Was nährt es, was reproduziert es, was würde es töten, welcher evolutionäre Druck hat es hervorgebracht?
- Das Zweitordnungs-Narrativ — greift, wenn ein Vorschlag technisch verpufft, aber sozialen Widerstand hervorruft. Beginnen Sie mit dem, was der Vorschlag daran ändert, wie Menschen denken, nicht mit dem, was er tut.
- Der Schurken-Rahmen — greift, wenn ein Vorschlag jeden Stakeholder berücksichtigt und niemanden zufriedenstellt. Bestimmen Sie, wer die Idee HASSEN würde, und entwerfen Sie gezielt so, dass dieser Hass verstärkt wird.
- Der 100-Jahre-Zoom — greift, wenn die gesamte Problemrahmung Randbedingungen annimmt, die voraussichtlich keine zehn oder mehr Jahre überdauern. Projizieren Sie nach vorn; holen Sie die künftige Klarheit zurück.
Jede Technik greift einen eigenen kognitiven blinden Fleck an. Die Wahl der falschen Technik erzeugt Rauschen, keine Einsicht; die Erkennungssignale sind die Auslösebedingungen, keine optionalen Gedankenexperimente.
Die sieben Breitenachsen
Jede nicht triviale Entscheidung bescheinigt sich gegenüber sieben kanonischen Expertise-Achsen:
- Architektur — Systemdesign, Modularität, Schichtung, Integrationsgrenzen.
- Nebenläufigkeit — Race Conditions, Deadlocks, asynchrone Koordination, Parallelität.
- Performance — Durchsatz, Latenz, Ressourcenbudgets, quantitative Gates.
- Sicherheit — Authn / Authz, Umgang mit Geheimnissen, Angriffsflächen, defensive Programmierung.
- Testen — Abdeckung, Isolation, Disziplin beim Mocking, Auffangen von Regressionen.
- Werkzeuge — Lint / Format / CI / CD / Instrumentierung zur Beobachtbarkeit.
- Beobachtbarkeit — Logging, Metriken, Tracing, Alerting, Debugbarkeit.
Jede Emission bescheinigt, welche Achsen zutreffen, welche mit Begründung nicht anwendbar sind und welche durch den Expertiserahmen begrenzt sind (die Achse trifft zu, übersteigt aber den Expertiserahmen des Assistenten; die Lücke ist erkannt und wird zur Schließung weitergeleitet). Die sieben Achsen bilden die Tiefenoberfläche, anhand derer die zehn Qualitätsdimensionen von M3 bewertet werden; die Änderungen je Achse werden unter <harness-root>/memory/expertise-gap-log.md verfolgt. Die Achse Performance trägt ihre eigene pfadgefilterte Doktrin unter src/apothem/rules/performance-discipline.md mit Budgets je Klasse (Hook-Handler, Orchestrator des Konformitäts-Gates, Test-Suite, Start delegierter Worker) und quantitativen Gates unter src/apothem/benchmarks/.
Sprachstandards
Die Taxonomie verbietet in substanziellen Ausgaben eine geschlossene Liste von Vokabular: Marketing-Intensivierer, die Kurzformeln des Konsensappells und jede Abschwächung, die eine Idee entkräftet, bevor sie ankommt. Erforderliche Qualitäten ersetzen sie: Spezifität (vage Ideen sind Gesten, keine Ideen), Überraschung (der Leser sieht sie nicht kommen), innere Logik (in sich selbst kohärent), Generativität (bringt nachgelagert weitere Ideen hervor) und Spannung (die besten Ideen enthalten einen produktiven Widerspruch).
Warum diese Taxonomie und nicht „sei kreativ“
„Sei kreativ“ ist eine Anweisung ohne Hebelwirkung. Die Taxonomie der kognitiven Identität zerlegt Kreativität in mechanische Oberflächen: Filter, die in kanonischer Reihenfolge greifen, Techniken, die bei Erkennungssignalen greifen, Achsen, gegenüber denen die Ausgabe sich bescheinigt, und eine Disziplin beim Vokabular, die die Abkürzungen abfängt, zu denen ein Autor unter Kostendruck neigt. Die Taxonomie ist operationalisierte kognitive Architektur — jede substanzielle Ausgabe durchläuft die ständigen Filter und jede nicht triviale Entscheidung die vollständige Kadenz, ein Nachweis, den der Operator auditieren kann, kein Gefühl, von dem der Operator hofft, dass der Assistent es einhält.
§6. Schluss
apothem ist nicht die Binärdatei, die Sie installieren. Die Binärdatei ist die Paketierung, die den Korpus in das native Konfigurationsverzeichnis jedes unterstützten Werkzeugs materialisiert — über Adapter je Harness unter src/apothem/harnesses/<harness>/ — und ihn als Betriebshaltung des Assistenten registriert. Das Produkt ist der Korpus — fünfzehn Mandate plus achtundzwanzig übergreifende Mandate plus die kanonische Kanal-Disziplin plus die Taxonomie der kognitiven Identität — und die Regeldateien unter src/apothem/rules/*.md sind seine kanonische Spezifikation.
Ein Projekt, das apothem übernimmt, übernimmt das Governance-Regime, nicht die Prompts. Jedes Artefakt, das der Assistent in Ihrem Repository erzeugt — Code, Tests, Konfiguration, Schemas, Dokumentation, Runbooks, Commit-Nachrichten, Branch-Namen — durchläuft dasselbe fünfzehnstufige Pre-Emission-Gate, trägt dasselbe Offenlegungs-Ledger, beachtet dieselben vom Host erkannten Konventionen, deklariert dieselben wechselseitigen Bindungen, erfüllt dieselben Unterelemente des Code-Handwerks und wird in derselben produktionsreifen Form ausgeliefert. Der Hebelpunkt des Operators verschiebt sich vom Prompt-Tuning zur Artefakt-Ratifizierung.
Um die Behauptung direkt zu prüfen, lesen Sie den Korpus. Klonen Sie das Repository, wechseln Sie nach src/apothem/rules/ und lesen Sie die Regeldateien in beliebiger Reihenfolge — jede Regel ist in sich geschlossen, jede Bindung ist wechselseitig, jeder Querverweis löst sich zu einem bestimmten Regelpfad plus Abschnittsanker auf. Die Regeln beschreiben zusammen einen Assistenten, der Code so schreibt, wie ein erfahrener Mitwirkender Ihres Projekts ihn schreiben würde; die Binärdatei ist die Oberfläche, die sie ausliefert.
Der Korpus ist das, was bleibt, nachdem sich die Binärdatei geändert hat.
gh repo clone ahmed-g-gad/apothem
$EDITOR src/apothem/rules/*.mdDas Lesen ist die Evaluation.
Governance
Apothem-Governance: die internen Qualitäts-Governance-Registries und -Richtlinien, denen jedes erzeugte Artefakt, jede Version und jede Badge-Oberfläche gerecht werden muss.
Registry der übergreifenden Mandate (CM-1–CM-28)
Vollständige Registry und Definitionen der ökosysteminternen übergreifenden Mandate (CM-1–CM-28), die alle Interaktionen und Pipeline-Operationen regeln.