Im Jahr 2026 baute ein Unternehmensteam einen Agenten auf, der Incident-Management-Tickets las, daraus Obduktionen erstellte und automatisch Reparaturartikel erstellte. Ein zweiter Agent im selben Team suchte nach neuen Arbeitselementen und öffnete für jedes einzelne PR-Entwürfe, um Entwicklern den Einstieg zu erleichtern. Ein Entwickler hat einen dieser PRs überprüft, ihn für angemessen befunden, ihn genehmigt und ihn mit dem Hauptzweig zusammengeführt.

**Das Problem bestand darin, dass die Änderung völlig erfunden war.**

Der Agent hatte eine plausibel aussehende Lösung für ein Problem erfunden, das in der beschriebenen Weise nicht existierte. Die Änderung führte zu einem realen Produktionsszenario. Ein echter Kunde hat es bemerkt. Es gab einen Ausfall.

Aus diesem Grund gibt es die EDD-Verfassung.

Die Verfassung ist eine einzelne Datei, die alle nicht trivialen Änderungen an der Codebasis regelt. Es definiert, wie eine abgeschlossene Änderung aussieht, welche Nachweise sie enthalten muss, was eine zielgerichtete Prüfung abdecken muss und wie sich die Regeln selbst weiterentwickeln können. Jeder Agent und jeder Mensch, der das Repo berührt, lädt es bei jeder Sitzung. Die Stange klappt nur nach oben.

Dieser Beitrag geht Schritt für Schritt durch die Verfassung: der Vorfall, der sie motiviert hat, die Designfrage, die sie beantwortet, wie sie strukturiert ist, wie sie geschrieben wurde (und was wir schon früh falsch gemacht haben), wie Änderungen funktionieren und wie sich das komplette Kit in einem neuen Repo entfaltet.

Schritt 1 – Was es ist

Der Vorfall ist das deutlichste Beispiel für den Fehlermodus, den EDD verhindern soll. Der Agent halluzinierte nicht zufällig. Es entstand eine kohärente, lesbare und professionell formatierte PR. Der Entwickler, der es überprüft hat, hat getan, was Entwickler tun: Sie haben die Absicht gelesen, die Absicht für plausibel gehalten und sie genehmigt. Die Lücke bestand nicht in der Aufmerksamkeit. Die Lücke bestand im Fehlen von Beweisen. Im Überprüfungsprozess musste der Agent nicht nachweisen, dass das Problem, das er angeblich beheben wollte, tatsächlich existierte, dass die Lösung tatsächliches Verhalten betraf oder dass die Änderung keine Rückgänge bewirkte.

EDD schließt diese Lücke mit einer einzigen harten Anforderung: Wenn der Agent dies nicht beweisen kann, ist die Aufgabe nicht erledigt. Der Beweis ist keine Zusammenfassung. Ein Beweis ist keine Vertrauensbehauptung. Ein Beweis ist ein Artefakt, das unabhängig überprüft werden kann – ein fehlgeschlagener Test, eine Scannerausgabe, ein Vorher/Nachher-Screenshot, ein Planunterschied. Die PR trägt das Artefakt oder die PR ist unvollständig.

Die Verfassung befindet sich unter „docs/methodology/CONSTITUTION.md“. Jeder im Projekt konfigurierte KI-Agent lädt es bei jeder Sitzung über seine eigene Loader-Datei. Der Hauptteil ist agentenneutral: keine Toolnamen, keine plattformspezifische Syntax. Es definiert neun Grundprinzipien, harte Einschränkungen mit stabilen Slug-IDs, die 10-stufige Implementierungsschleife, Prüfungsdimensionen, Nachweisakzeptanzkriterien pro Änderungstyp, Trivialitätsausschlüsse für Arbeiten mit geringem Risiko und die Änderungsklausel.

Jede harte Einschränkung hat einen Slug wie „[HC-EVIDENCE-BEFORE]“ und deklariert drei Dinge: den Balken (was wahr sein muss), die Überprüfung (wie die Einhaltung überprüft wird) und die Musterquelle (welche Anweisungsdatei die Implementierungsanleitung ausarbeitet).

Die 10-Schritte-Schleife ist das operative Herzstück: „Erledigt“ definieren, einen Test schreiben, der die Lücke beweist, zusehen, wie er fehlschlägt, Vorher-Beweise erfassen, implementieren, beobachten, wie der Test bestanden wird, Nachher-Beweise erfassen, Dokumente überprüfen, Prüfung über alle deklarierten Dimensionen hinweg, dann menschliche Überprüfung. Die Schritte 1 bis 4 werden vor jeder Implementierungsbearbeitung durchgeführt. Die Anordnung ist verfassungsgemäß, weil dieser Vorfall genau zeigt, was passiert, wenn dies nicht der Fall ist.

Als zusätzlichen Schutz übernimmt EDD ein Kernprinzip von TDD: Das Scheitern des Szenarios muss nachgewiesen werden, bevor mit der Arbeit begonnen wird. Ein Beweis, der am Ende einer Änderung bestanden wird, ist allein kein ausreichender Beweis – wenn der Test auch vor der Änderung bestanden hat, hat der Agent möglicherweise etwas repariert, das nie beschädigt wurde. Dies ist ein spezifischer Fehlermodus in KI-gestützten Arbeitsabläufen: Ein Agent generiert eine plausibel klingende Lösung, die Überprüfung wird erfüllt und die Änderung wird versendet, als ob sie ein echtes Problem gelöst hätte. Durch die Anforderung eines dokumentierten Fehlerzustands vor Beginn der Implementierung wird diese Lücke geschlossen. Der Vor-Beweis-Schritt ist nicht nur eine Vergleichsbasis – er ist ein Beweis dafür, dass das zu lösende Problem real war.

Von allen harten Einschränkungen, die durch die Verfassung eingeführt wurden, haben zwei mehr Fehler festgestellt als alle anderen zusammen, und sie sind wohl die wichtigste Verbesserung, die EDD für jeden KI-gestützten Arbeitsablauf vornimmt: „[HC-EVIDENCE]“ und „[HC-EVIDENCE-INTEGRITY]“. Beide werden in „.github/copilot-instructions.md“ deklariert – der Eager-Loaded-Datei, die sich bei jeder Sitzung im Kontext des Agenten befindet.

„[HC-EVIDENCE]“ erfordert, dass jede PR tatsächliche Vorher- und Nachher-Artefakte enthält – keine Beschreibungen dessen, was die Artefakte zeigen würden, keine Zusammenfassungen dessen, was der Agent glaubt, passiert zu sein, sondern die Rohausgabe. „[HC-EVIDENCE-INTEGRITY]“ geht noch weiter: Es erfordert, dass die Beweise in der PR auf die tatsächlich geleistete Arbeit zurückgeführt werden können. Es bestätigt, dass die PR das enthält, was sie verspricht.

Zusammengenommen haben diese beiden Einschränkungen Hunderte von KI-generierten Fehlern erkannt, bevor sie zur Überprüfung gelangten. Der Fehlermodus, vor dem sie sich schützen, ist keine Halluzination im offensichtlichen Sinne. Es handelt sich um ein subtileres Verhalten: Der Agent markiert eine Aufgabe als erledigt, schreibt eine selbstbewusste PR-Beschreibung und fügt hinzu, was als Beweis gilt – aber der Beweis wurde erstellt und nicht erfasst. Der Agent beschrieb, wie die Ausgabe aussehen sollte, anstatt den Befehl auszuführen und die tatsächliche Ausgabe einzuschließen.

„[HC-EVIDENCE-INTEGRITY]“ ist besonders wirksam beim Erkennen dessen, was man das „Das konnte ich nicht“-Muster nennen könnte. Ein Agent, der vor einer schwierigen oder ungewohnten Aufgabe steht, wird manchmal behaupten, die Aufgabe sei unmöglich oder außerhalb des Rahmens, anstatt sie zu versuchen. Die Behauptung wird oft als Einschränkung formuliert – ein Werkzeug, das nicht existiert, eine Einschränkung, die den Ansatz verhindert, eine Umgebung, die den Vorgang nicht unterstützt. „[HC-EVIDENCE-INTEGRITY]“ bringt dies zum Ausdruck: Wenn der Agent behauptet, eine Aufgabe könne nicht erledigt werden, muss der PR Beweise dafür vorlegen, dass die Aufgabe tatsächlich versucht wurde und das Hindernis real ist. „Ich konnte die Testsuite nicht ausführen“ erfordert eine Terminalausgabe, die den Fehler anzeigt, keine Aussage, dass der Fehler aufgetreten ist. Ohne diese Anforderung ist die Vermeidung schwieriger Arbeit durch den Agenten zum Zeitpunkt der Überprüfung nicht sichtbar und die Aufgabe bleibt unvollständig, als ob sie erledigt wäre.

Schritt 2 – Wie wir hierher gekommen sind

Die Verfassung ist keine Ansammlung von gewonnenen Erkenntnissen. Es ist die Antwort auf eine Designfrage, die zu Beginn gestellt wurde: Wie zwingt man einen KI-Agenten, jedes Mal seine Arbeit zu beweisen, und zwar auf eine Weise, die nicht umgangen werden kann und nicht davon abhängt, dass ein Mensch daran denkt, die Frage zu stellen?

Die Beantwortung dieser Frage erzwang eine Zersetzung. Für den Nachweis muss bekannt sein, wie die Ausführung aussieht, bevor mit der Implementierung begonnen wird – was den Dokumentationsschritt hervorbrachte. Für den Nachweis ist ein Test erforderlich, der vor der Änderung fehlschlägt und danach bestanden wird – was zur Disziplinierung des Nichtbestehens/Bestehens des Tests führt. Der Beweis erfordert einen Vorher-Zustand, der erfasst wurde, bevor die Implementierung irgendetwas berührte – was die Vorher-Beweisanforderung hervorbrachte. Der Nachweis erfordert eine unabhängige Prüfung, die das erfasst, was Beweise pro Änderung nicht erfassen können – was die Prüfungsdimensionen hervorgebracht hat. Und Beweise müssen den Überprüfungsprozess überstehen, ohne aufgeweicht zu werden – das führte zu der harten Einschränkung, dass der menschliche Prüfer das letzte Tor und das einzige Tor ist, das nicht automatisiert werden kann.

Das Ergebnis ist die 10-Schritte-Schleife. Jeder Schritt existiert, weil durch das Entfernen ein Loch entsteht, durch das unbewiesene Arbeit passieren kann. Die Schleife ist keine Checkliste. Es handelt sich um eine Kausalkette.

Daraus ergab sich die Frage: Welche Fehlerkategorien kann ein Agent erzeugen, die die Schleife standardmäßig nicht abfängt? Daraus ergaben sich die harten Zwänge. Das Schweigen des Sicherheits-Lints während der Herabstufung der Regeln führte zu „[HC-SECURITY-LINT]“. Ein Zeichenkodierungsfehler in einem bereitgestellten Artefakt erzeugte „[HC-ASCII-PUNCT]“. Jeder HC schließt eine bestimmte Fehlerklasse mit einer bestimmten automatisierten Überprüfung ab. Regeln, die keine Überprüfung benennen konnten, wurden abgelehnt: Wenn eine Überprüfung nicht automatisiert werden kann, ist die Regel erstrebenswert und nicht verfassungsgemäß.

Die letzte Entwurfsfrage lautete: Wer regiert die Verfassung selbst? Die Antwort ist die Ratsche. Die Verfassung kann nur strenger werden. Änderungen müssen den Nachweis erbringen, dass sich das Verhalten des Agenten verbessert oder anhält. Der Boden bewegt sich nie nach unten. Dies bedeutet, dass man der Verfassung im Laufe der Zeit in einer Weise vertrauen kann, die einem lebenden Styleguide nicht möglich ist: Jede Version ist grundsätzlich stärker als die davor.

Schritt 3 – Wie es aufgebaut ist

Die Verfassung folgt einer dreischichtigen Architektur.

**Schicht 1: Der kanonische Körper.** Eine Datei, „docs/methodology/CONSTITUTION.md“. Das ist die Quelle der Wahrheit. Es ist agentenneutral: Es werden keine Annahmen darüber getroffen, welches KI-Tool verwendet wird. Es definiert Grundsätze, harte Einschränkungen, den Regelkreis, Prüfungsdimensionen, Kriterien für die Beweisannahme, Ausnahmen von Trivialitäten und die Selbstverbesserungsklausel. Wenn der Text etwa 250 Zeilen überschreitet, werden Regeln, die für ein bestimmtes Pfadmuster gelten, in pfadbezogene Dateien ausgegliedert, wobei ein einzeiliger Zeiger im Text verbleibt.

**Schicht 2: Agent-Loader.** Jeder konfigurierte Agent erhält genau eine Loader-Datei an dem Speicherort, den der Agent eifrig lädt. Für GitHub Copilot ist das „.github/copilot-instructions.md“. Für Claude ist das „CLAUDE.md“. Der Loader importiert oder inline den Verfassungskörper, je nachdem, was die Plattform derzeit unterstützt. Der Lader wird mechanisch aus dem kanonischen Körper gerendert; es ist nicht von Hand bearbeitet. Wenn ein Projekt drei KI-Tools verwendet, gibt es drei Loader-Dateien, die alle denselben Verfassungsinhalt wiedergeben.

**Ebene 3: Pfadbezogene Regeln.** Einige Regeln gelten nur für bestimmte Dateitypen. Barrierefreiheits- und Lokalisierungsregeln gelten für JSX- und CSS-Dateien, nicht für Infrastrukturvorlagen. Diese Regeln leben in Anweisungsdateien mit einem Frontmatter-Globus:

Der Agent lädt diese Dateien nur, wenn er auf einen passenden Pfad trifft. Dies hält das Budget für den Eager-Load-Kontext knapp (Kernregeln sind immer vorhanden, spezielle Regeln werden bei Bedarf geladen) und verhindert, dass bei der Bearbeitung einer Bicep-Vorlage Hinweise zur Barrierefreiheit angezeigt werden.

Unterstützende Dateien vervollständigen die Struktur: „/constitute“-Befehlskörper in „.github/prompts/“, Ordner pro Feature unter „docs/methodology/features/“, Eval-Szenarien unter „docs/methodology/eval/scenarios/“ und „verify-sequence.yaml“ im Repo-Stammverzeichnis, das die CI-Gate-Reihenfolge definiert.

Schritt 4 – Wie wir es geschrieben haben

**Der Kontext ist alles. Was nicht im Kontext steht, ist für den Agenten tot.**

Dies ist die wichtigste Erkenntnis beim Verfassen einer Verfassung für eine KI-gesteuerte Entwicklung. Eine Regel, die in einer Datei vorhanden ist, die der Agent nie lädt, ist nicht vorhanden. Eine in einem Dokument verborgene harte Einschränkung, die nur geladen wird, wenn ein bestimmter Dateipfad berührt wird, ist keine harte Einschränkung für einen anderen Pfad. Die Verfassung muss immer im Kontext stehen und alles, was immer gelten muss, muss dort leben.

Dies führt zu drei Autorenentscheidungen:

**Token-Optimierung ist nicht verhandelbar.** Der kanonische Hauptteil zielt auf weniger als 300 Zeilen und 8.000 Token ab. Jede Änderung muss die Token-Effizienz aufrechterhalten oder verbessern – ausführliche Regeln, die das erreichen, was knappe Regeln erreichen können, werden allein aus diesen Gründen abgelehnt. Dies ist keine Stilpräferenz. Es handelt sich um eine Lastbeschränkung. Wenn die Verfassung das Budget überschreitet, beginnen Agenten in kleineren Kontextfenstern damit, sie zu kürzen, und gekürzte Regeln sind keine Regeln.

**Bedingtes Laden durch Frontmatter.** Regeln, die nur für bestimmte Dateitypen gelten, werden aus dem kanonischen Hauptteil herausgerechnet und in pfadbezogene Anweisungsdateien mit einer Frontmatter-Glob-Deklaration eingefügt. Hinweise zur Barrierefreiheit und Lokalisierung werden nur geladen, wenn der Agent JSX oder CSS berührt. Die Infrastrukturführung wird nur geladen, wenn der Agent Bicep berührt. Der kanonische Körper behält einen einzeiligen Zeiger. Der Agent lädt die pfadbezogene Datei nur, wenn sie relevant ist. Dies dient nicht nur der Effizienz – es verhindert auch, dass Hinweise zur Barrierefreiheit bei einer Infrastrukturbearbeitung als Ablenkung auftauchen und der Agent dadurch trainiert wird, sie zu ignorieren.

Dieses Projekt verwendet keine durch Frontmatter getrennten Regeldateien, da die Verfassung klein genug ist, um vollständig im Kontext geladen zu werden – ein einzelner Entwickler, ein fokussierter Bereich, ein schlanker Regelsatz. Bei größeren Teams ändert sich die Berechnung. Ein Projekt im Unternehmensmaßstab, bei dem derzeit EDD ausgeführt wird, weist 75 strenge Einschränkungen in Bezug auf Sicherheit, Compliance, Zugänglichkeit und plattformspezifische Anforderungen auf. Die Einbindung aller 75 in eine einzige Eager-Load-Datei würde die Verfassung für die meisten Agenten weit über das Kontextbudget hinaus sprengen. Durch die Frontmatter-Aufteilung bleibt der kanonische Körper unter 250 Zeilen – ein Zusammenfassungszeiger pro Domäne – und die vollständigen Regeldetails werden nur verzögert geladen, wenn der Agent übereinstimmende Pfade berührt. Die Verfassung bleibt schnell und schlank. Die Regeln bleiben vollständig. Die Token-Kosten bleiben begrenzt.

**Änderungen als Änderungseinheiten.** Eine Verfassungsänderung ist keine Wortänderung in einer Markdown-Datei. Es handelt sich um ein Paket aus drei Artefakten: dem genauen Regeldelta, dem Überprüfungsmechanismus, der zukünftige Verstöße erkennt, und einem Verhaltensbewertungsszenario, das nachweist, dass sich das Agentenverhalten verbessert. Alle drei werden zusammen im selben PR versendet. Die Änderung ist atomar. Teiländerungen, die versprechen, die Überprüfung später hinzuzufügen, werden abgelehnt – später kommt nicht, und eine nicht überprüfbare Regel ist Dekoration.

**Schreiben Sie die Bewertungen und Rubriken, bevor Sie denken, dass Sie sie brauchen.** Die Bewertung ist die Ratsche. Ohne sie werden Änderungen nach Treu und Glauben angenommen und die Verfassung weicht. Die Rubrik bewertet das Agentenverhalten in realistischen Szenarien. Jede neue Regel erzeugt mindestens ein Szenario. Die Rubrik erzeugt eine numerische Bewertung. Die Änderung wird nur angenommen, wenn der Working-Tree-Score den Basiswert erreicht oder überschreitet.

**Dokumentieren Sie, was Sie abdecken können und was nicht. Belügen Sie sich nicht selbst, wenn es um den Versicherungsschutz geht.**

Schon früh erklärte die harte Einschränkung der Barrierefreiheit, dass neue interaktive UI-Oberflächen eine E2E-A11Y-Abdeckung mit Axe-Core erforderten. Das fühlte sich umfassend an. In der Praxis war es naiv. axe-core verarbeitet eine sinnvolle Teilmenge von WCAG – es erfasst fehlende Beschriftungen, Orientierungspunktstruktur, Fokusreihenfolge und Kontrast in Fällen, in denen das DOM vollständig gerendert und Farben aufgelöst ist. Die Ankündigungslogik von Bildschirmleseprogrammen, kognitive Belastungsmuster, komplexe Widget-Tastaturkontrakte oder Kontrastprobleme im Zusammenhang mit Farbverläufen und SVG-Bildknoten, bei denen die berechnete Farbe nicht aufgelöst werden kann, werden nicht erfasst.

„[HC-A11Y-GATE]“ mit axe-core in der Verifizierung zu haben, bedeutet nicht, dass alle 11y-Fehler Null sind. Dies bedeutet, dass der spezifische Axe-Core-Regelsatz für das gerenderte DOM ausgeführt wird. Der Unterschied ist bei PR-Berichterstattungsansprüchen von enormer Bedeutung.

Die Lösung war Zersetzung. Anstelle von „Axe-Core Clean“ wurde die Überprüfung neu geschrieben, um aufzulisten, welche WCAG-Erfolgskriterien der Axe-Core-Regelsatz deterministisch abdeckt (1.1.1 für Nicht-Textinhalte, 1.3.1 für Informationen und Beziehungen, 1.4.3 für Kontrast, wo auflösbar, 4.1.2 für Name/Rolle/Wert) und welche keine automatisierte Abdeckung haben (1.3.3 sensorische Merkmale, 2.4.6 Überschriften und Beschriftungen). Semantik, alle von 3.x verständlichen Kriterien). Im Abschnitt „Bekannte Lücken“ der Audit-Dimension heißt es jetzt explizit: „Axe-Core“ behandelt diese Kriterien; Für diese ist ein manuelles Scannen erforderlich. PR-Rezensenten sehen die tatsächliche Berichterstattung und keine falsche Zusammenfassung.

Das umfassendere Prinzip: Dokumentieren Sie bei jeder Überprüfung, was erfasst wird und was nicht. „Security Lint Passes“ bedeutet nicht, dass die Codebasis sicher ist. „axe-core clean“ bedeutet nicht, dass WCAG 2.2 AA konform ist. Benennen Sie die Lücke. Protokollieren Sie es in der Audit-Dimension. Erfordert manuelles Scannen der Spaltoberfläche. Lassen Sie nicht zu, dass die automatisierte Prüfung das menschliche Urteilsvermögen ersetzt, das sie nicht ersetzen kann.

Schritt 5 – Wie wir Änderungsanträge verfassen

Änderungsanträge beginnen fast nie als Änderungsvorschläge. Sie beginnen als Käfer.

Ein Käfer taucht auf. Der Fix wird angewendet. Vor der Auslieferung stellt „/reflect“ eine Frage: Handelt es sich um einen Einzelfall, oder fehlt in der Verfassung etwas, das diese Art von Versagen hätte abfangen können? Wenn die Antwort einmalig ist, wird das Problem behoben, und das ist das Ende. Wenn die Antwort lautet, dass etwas fehlt, wird „/constitute“ aufgerufen.

**Der /reflect -> Lücke -> Änderungspfad.** „/reflect“ untersucht den Fix und klassifiziert ihn: Verfassungslücke (keine Regel deckte diese Fehlerklasse ab) oder Überprüfungslücke (eine Regel existierte, aber keine automatische Prüfung hat sie durchgesetzt). Beide Wege führen zu „/constitute“. Eine Verfassungslücke bringt einen neuen HC hervor. Eine Verifizierungslücke führt zu einer strengeren Verifizierung eines bestehenden HC – typischerweise ein neuer Prüfdimensionsunterabschnitt, eine neue Scannerregel oder ein neues Bewertungsszenario.

**Die drei erforderlichen Artefakte.** `/constitute` weigert sich, ohne alle drei im selben PR fortzufahren:

• **Regeldelta.** Die genaue Textänderung, klassifiziert: neue Regel, geänderter Wortlaut, Verschiebung (die alte ersetzen und entfernen), Ersetzung (die Messlatte mit der alten als Untergrenze anheben) oder Verschiebung. Duplikate werden sofort abgelehnt.
• **Verifizierungsmechanismus.** Das spezifische Gate, das einen zukünftigen Verstoß erkennt – ein Testname, eine Lint-Regel-ID, ein Audit-Dimensionsunterabschnitt, eine Scanner-Exit-Code-Prüfung oder ein Verhaltensbewertungsszenario. Es muss zum Commit-Zeitpunkt vorhanden sein. Regeln ohne erkennbare Verstöße sind dekorativ.
• **Eval-Szenario.** Gespeichert unter „docs/methodology/eval/scenarios/<id>.md“. Beschreibt eine realistische Situation, in der die alte Regel zu falschem Agentenverhalten und die neue Regel zu einer bewertbaren richtigen Antwort führt.

**Die Ratsche.** Nachdem alle drei Artefakte genehmigt wurden, wird die Änderung auf einen Zweig angewendet. Die Auswertung erfolgt gegen Hauptzweigregeln und Arbeitsbaumregeln. Die Rubrik bewertet beides. Für Pass ist in jedem Szenario „working-tree >= main“ erforderlich. Die Regression blockiert den Änderungsantrag, bis der Wortlaut festgelegt ist. Die Ratsche ist für offensichtliche Änderungen nicht optional: Sie können immer noch subtile Rückschritte hervorrufen, und die Bewertung ist der einzige Mechanismus, der sie auffängt, bevor sie landen.

**Der rückwirkende Sweep.** Eine Änderung legt die Regel für neuen Code sofort fest: Der Diff-Bereich von „/audit“ bedeutet, dass neue Arbeiten ab dem Zeitpunkt der Veröffentlichung der Änderung die neue Messlatte erfüllen. Bereits vorhandener Code, der gegen die neue Regel verstößt, wird von einem separaten Sweep-PR behandelt, der über „/rollout“ in die Warteschlange gestellt wird. Die Fix-Site muss nicht jede bereits vorhandene Instanz inline reparieren. Das würde Änderungen unerschwinglich teuer machen. Stattdessen: Neuer Code erreicht sofort die neue Messlatte, alter Code befindet sich in der Rollout-Warteschlange und der Sweep-PR trägt seinen eigenen Beweis dafür, dass bereits vorhandene Instanzen aufgelöst wurden.

Die vier gültigen Auslöser für „/constitute“ sind: ein Fehler, ein Vorfall, eine Obduktion und ein neuer Vertragsstandard. Vorschläge mit der Form „Wir sollten wahrscheinlich…“ ohne einen der vier Auslöser werden abgelehnt und stattdessen an „/reflect“ weitergeleitet.

Schritt 6 – Wie wir es entfalten

Das Portable Methodology Kit („EDD – Portable Methodology Kit.md“) ist ein eigenständiges Dokument, das Sie jedem KI-Agenten mit der Anweisung zum Ausführen von „/begin“ übergeben. Der Agent inspiziert das Repo, führt einen Discovery-Durchgang durch, bestätigt mit Ihnen die erkannten Werte in einer einzigen Tabelle, fragt nur, was Discovery nicht beantworten kann, und gibt das minimal brauchbare Gerüst für Ihr Projekt aus. Eine Sitzung zum Aufbau der gesamten EDD-Infrastruktur.

Wie Sie es entfalten, hängt ganz davon ab, ob Sie neu beginnen oder es in eine bestehende Codebasis integrieren. Die beiden Pfade sind so unterschiedlich, dass sie separat behandelt werden können.

**Greenfield.** Setzen Sie bei einem neuen Projekt am ersten Tag jede erdenkliche Regel in die Verfassung ein. Sie müssen keinen bereits vorhandenen Code prüfen, keine Teampraktiken schützen, keine bestehenden PRs an den Großvater weitergeben. Die Kosten für Strenge betragen am ersten Tag nahezu Null. Fügen Sie alle harten Einschränkungen, alle Prüfdimensionen und alle pfadbezogenen Regeln hinzu. Führen Sie dann die Schleife aus. Was Sie schnell feststellen werden, ist, wo die Verfassung zu Spannungen führt: die Build-Zeiten steigen, weil jede Änderung eine vollständige Prüfung auslöst, Testsuiten, die langsam sind, weil die Abdeckungsgrenze für die aktuelle Komplexität zu hoch angesetzt ist, und Token-Budgets, die knapp sind, weil der kanonische Körper zu ausführlich ist. Die Strenge vom ersten Tag an bringt diese Probleme in der Entwicklung zum Vorschein, nicht in der Produktion. Dann optimieren Sie: Bauschranken verschärfen, Deckungsregeln anpassen, Verfassungsorgan auf ein Minimum reduzieren. Sie stabilisieren alles auf einmal, ohne dass Kunden betroffen sind oder Ihr Team gestört wird. Die kurzfristigen Kosten sind ein etwas langsamerer erster Sprint. Der langfristige Gewinn ist eine Verfassung, die vom ersten Commit an einem Stresstest unterzogen wurde.

**Brownfield.** Eine bestehende Codebasis verfügt über ein bestehendes Team, bestehende Praktiken und bestehende PRs, die EDD nicht folgten. Die Entfaltung erfolgt hier schrittweise und muss additiv und nicht störend sein. Das Ziel für den ersten Monat besteht nicht darin, jede frühere Entscheidung nachzurüsten, sondern mit der Generierung der Sicherheiten zu beginnen, die EDD vertrauenswürdig machen: eine Prüfungsdimension, die etwas Reales erfasst, eine harte Einschränkung, die eine Überprüfung automatisiert, die das Team bereits manuell durchgeführt hat, ein Änderungszyklus von Ende zu Ende. Nutzen Sie die vorhandenen Qualitätssignale des Teams als Rohmaterial. Wenn das Team bereits über eine Lint-Regel für die Sicherheit verfügt, fügen Sie „[HC-SECURITY-LINT]“ hinzu und richten Sie es auf das vorhandene Tor – für Entwickler ändert sich nichts, aber jetzt spiegelt der Verfassungsdatensatz wider, was das Tor tatsächlich durchsetzt.

Die Grundregel im Brownfield lautet: Gewinnen Sie Verbündete, bevor Sie Argumente gewinnen. Treiben Sie nicht in der ersten Woche eine vollständige Verfassung voran, die jeden Bereich der Codebasis berührt. Beginnen Sie mit der Dimension, die dem Team ohnehin am meisten am Herzen liegt – normalerweise Sicherheit oder Zuverlässigkeit. Zeigen Sie, dass der Änderungsprozess eine echte Lücke schließt, die sie zuvor gesehen haben. Lassen Sie die Ratsche von dort aus zusammenlaufen. Ein Team, das gesehen hat, dass EDD einen echten Fehler entdeckt hat, der durch seinen bestehenden Prozess geschlüpft ist, wird Platz für die nächste Regel schaffen. Ein Team, das EDD als ein Dokument erkennt, das ihm sagt, dass es alles falsch gemacht hat, wird es umgehen.

**Was es freischaltet.** Der Grund für die Entfaltung, egal ob Greenfield oder Brownfield, ist nicht das Verfassungsdokument. Das ist es, was die Verfassung ermöglicht, sobald die Verifizierungsmaschinerie läuft.

Qualität des Produktionscodes und Liefergeschwindigkeit fügen sich auf eine Weise zusammen, die für Sie, wenn Sie es nicht gesehen haben, wirklich kontraintuitiv ist. Ingenieure stoppen den Kontextwechsel, um Regressionen zu debuggen, die die Schleife abgefangen hätte. Überprüfungszyklen verkürzen sich, da PRs Beweise statt Erklärungen enthalten. Die Prüfung läuft automatisch ab und markiert die Probleme, die auch der erfahrenste Prüfer erkannt hätte. So kann sich dieser Prüfer auf die Architekturentscheidungen konzentrieren, die tatsächlich sein Urteilsvermögen erfordern.

Der deutlichste Beweis dafür: Ein neuer Ingenieur, der dem Team beitritt und vollen Zugriff auf die Verfassung, die Feature-Spezifikation und den Loop hat, kann innerhalb von 48 Stunden nach seinem ersten Tag einen Feature-Beitrag in Produktionsqualität einchecken, der in main eingecheckt ist. Kein Spielzeugwechsel. Kein Dokumentationsupdate. Ein echtes Feature mit Beweisen, das die vollständige Prüfung bestanden hat. Es ist kein Zufall und es ist kein besonders ungewöhnlicher Ingenieur. Die Leitplanken ermöglichen es jedem erfahrenen Entwickler, vom ersten Tag an am Qualitätsstandard des Teams zu arbeiten, da der Qualitätsstandard automatisch niedergeschrieben, überprüfbar und durchgesetzt wird und nicht als institutionelles Wissen in den Köpfen derjenigen getragen wird, die am längsten dabei sind.

Das ist die Form, die es erreicht: ein Team, in dem die KI die Verifizierungsarbeit übernimmt, die Leitplanken die Fehlerklassen abfangen, die andernfalls durch die Codeüberprüfung rutschen würden, und die Ingenieure ihre Denkzeit auf die Probleme verwenden, die tatsächlich eine technische Beurteilung erfordern.

Dies wurde auf verschiedenen Ebenen bestätigt – zuerst bei Einzelprojekten, dann bei mittelgroßen Teams und dann bei Organisationen im Unternehmensmaßstab. Die Mechanik hält bei allen dreien. Die Abwicklungskosten sind unterschiedlich (ein einzelner Entwickler kann Anforderungsregister und herstellerübergreifende kontradiktorische Prüfungen überspringen; ein Unternehmensteam benötigt sie). Der Änderungsrhythmus ist unterschiedlich (bei einem Einzelprojekt können Wochen zwischen den „/constitute“-Aufrufen vergehen; ein Unternehmensteam mit mehreren beitragenden Agenten führt sie wöchentlich durch). Aber die Kernschleife, die Ratsche und die Beweisanforderung verhalten sich unabhängig von der Teamgröße gleich. Die Qualitätsuntergrenze steigt nur, und die Verifizierungsmaschinerie hält sie dort, ohne davon abhängig zu sein, wer in dieser Woche der erfahrenste Rezensent im Raum ist.

KI-Hooks

Die Verfassung regelt das Verhalten des Agenten durch geladenen Kontext. Hooks erzwingen es im Moment der Aktion, bevor die Arbeit bereits erledigt ist und eine PR bereits offen ist. Ohne Hooks wird ein Verstoß bei der Überprüfung erkannt: Der Agent hat den Code bereits geschrieben, die PR ist vorhanden und die Behebung bedeutet, dass die Arbeit noch einmal durchgeführt werden muss. Bei Hooks erfolgt das Abfangen vor jedem Tastendruck.

**Sowohl Claude Code als auch GitHub Copilot führen beim Prompt Submit einen Hook aus.** Wenn eine neue Aufgabe eintrifft, wird der Hook ausgelöst, bevor der Agent etwas unternimmt. Seine Aufgabe: Überprüfen Sie, ob die Aufgabe nicht trivial ist, und verknüpfen Sie dann die Aufgabenliste erneut mit der „/wow“-Schleife – der 10-stufigen EDD-Sequenz, die der Agent befolgen muss, bevor er etwas versendet.

Ein Agent, der Schritt 5 erreicht, ohne die Schritte 1–4 abzuschließen, hat die Schleife verletzt. Der Hook legt die Reihenfolge beim Sitzungsstart fest – nicht im Nachhinein.

**Claude Code** löst zusätzlich einen Pre-Tool-Call-Hook vor jedem Dateischreibvorgang, Terminalbefehl oder Git-Vorgang aus. Ein Commit kann nicht versucht werden, wenn die Schleifenschritte nicht erfüllt wurden.

**GitHub Copilot** löst zusätzlich einen PR-Erstellungs-Hook aus. Bevor die PR-Beschreibung fertiggestellt ist, führt der Hook „/audit“ im Selbstprüfungsmodus aus und erkennt Dimensionsverstöße, fehlende Beweise und leere Testpläne, bevor ein menschlicher Prüfer den Entwurf jemals sieht. Was den Rezensenten erreicht, ist bereits vorab geprüft.

**Codex und andere Agenten** verfügen zum Zeitpunkt dieses Schreibens über keine native Hook-Oberfläche. Beim Fallback handelt es sich um einen CI-Watcher-Bot, der PRs unmittelbar nach der Erstellung kommentiert und Verstöße meldet. Es handelt sich um eine Rücklaufsperre, nicht um ein First-Surface-Gate – die Arbeit ist zum Zeitpunkt des Auslösens bereits erledigt, sodass die Nacharbeit, die durch Haken entfällt, nicht verhindert wird.

Bei einem Projekt mit aktiven Hooks werden Verstöße während der Sitzung inline korrigiert. Der Agent erkennt die Lücke, liefert die Beweise und bezieht sie von Anfang an ein. Die Überprüfungszeit verkürzt sich. Nacharbeit verschwindet. Die Verfassung bewegt sich von einem Dokument, das der Agent liest, zu einer Einschränkung, in der der Agent in Echtzeit arbeitet.

Anhang – Die vollständige Verfassung

Was folgt, ist die eigentliche „CONSTITUTION.md“ aus diesem Projekt – ein vollständig autonomes KI-gestütztes Entwicklungsprojekt für einen einzelnen Entwickler. Es regelt jede nicht triviale Änderung, die an dieser Codebasis vorgenommen wird. Dies ist keine Vorlage oder Illustration. Dies ist das Live-Dokument, das von jedem Agenten in jeder Sitzung geladen wird.