Praktischer Teil 3. Projektverfassung: Erstes Regelreferendum

Status: Empfehlung. Die Trennung von immutable_principles und mutable_rules mit explizitem ttl, max_scope, rollback_condition — bewährte Praxis. Das automatische Agenten-Referendum mit deterministischem Tie-Breaker-Regelwerk — Grenzgebiet: seine Form hängt vom konkreten Team und den Modellen ab.

Für den schulischen Durchlauf genügt es, constitution.md manuell auszufüllen und zu prüfen, dass veränderliche Regeln ttl, max_scope und rollback_condition haben. Automatisches Referendum und externer Schiedsrichter gehören zum vollständigen Production-Track.

„Projektverfassung“ hier bedeutet: versionierter Satz von Invarianten, veränderbaren Regeln und Verfahren zur Annahme von Änderungen. Der Satz wird vor Ausführung gefährlicher Aktionen geprüft.

Ein Wort — zwei verschiedene Dateien

Im ersten Band ist die Projektverfassung auf drei Dateien verteilt: mission.md (warum wir das tun), tech-stack.md (worauf wir schreiben), roadmap.md (was und in welcher Reihenfolge). Dieser Vertrag beschreibt das Produkt.

Im zweiten Band erscheint unter demselben Wort eine vierte Datei — constitution.md. Sie beschreibt nicht das Produkt, sondern den Kontur sicherer Automatisierung: welche Agentenaktionen verboten sind, welche eingeschränkt erlaubt sind, wer und wie Regeln ändert. Das ist eine Aufsatz, keine Ersetzung. Die Dateien des ersten Bands bleiben an Ort und Stelle, constitution.md wird daneben hinzugefügt und vor jeder gefährlichen Aktion gelesen.

Wenn Sie eine einzeilige Trennung wünschen: mission/tech-stack/roadmap beantworten die Frage „was wir bauen“, constitution.md — die Frage „was der Agent damit nicht tun darf, auch wenn er es sehr möchte".

Im schulischen Minimum genügt eine kleine constitution.md mit zwei unveränderlichen Verboten und einer veränderlichen Regel. Agenten-Referendum, externer Schiedsrichter und automatische Playbook-Prüfung sind nur für den vollständigen Track nötig. Das Kapitel stützt sich auf Teil 6 des ersten Bands (woher mission.md, tech-stack.md, roadmap.md kommen) und Teil 18 (woher das Verständnis der SDD-Sicherheit stammt).

Vor dem Lesen

• Stütze aus dem ersten Band: Teil 6 führt mission.md, tech-stack.md, roadmap.md ein; Teil 18 erklärt SDD-Sicherheit.

• Lokaler schulischer Fall: node_not_ready, weil daran der Unterschied zwischen erlaubter sanfter Aktion und Verbot gefährlicher Operationen sichtbar wird.
• Spur für capstone/: zwei immutable_principles, eine mutable_rule und ein kurzes governance_protocol für high_memory_usage.
• Hauptbegriffe des ersten Durchlaufs: immutable_principles und mutable_rules. Die dritte Schicht — governance_protocol — ist nachschlagewerkartig, nur nötig wenn das Team eine Abstimmungsregel einführt.
• Was zurückzustellen ist: Agenten-Referendum, externer Schiedsrichter und automatische Playbook-Prüfung.

Der Grund für die separate Production-Schicht ist einfach: Szenarien wie node_not_ready oder autoscale_200pct lassen keine Zeit für Chat. Gefährliche Aktionen müssen entweder ein formales Gateway passieren oder blockiert werden. Mit der Sicherheit dieses Gateways befassen wir uns unter Bezugnahme auf Teil 18. SDD-Sicherheit. Die Verbindung zur Interaktion mit bereits laufendem Code findet sich in Teil 13. Unterstützung bestehender Projekte.

Kapitel-Roadmap

Das Kapitel ist lang und muss nicht linear gelesen werden. Bewegungskarte:

1. Minimales schulisches Szenario. Sie füllen constitution.md von Hand aus: zwei Immutable-Verbote, eine Mutable-Regel mit sechs Feldern. Das ist alles, was für die Bewertung nötig ist.
2. Schlüsselideen. Erklären, warum das Minimum so aussieht.
3. Interview über Qwen Code. Eine Möglichkeit, das Ausfüllen von constitution.md zu beschleunigen. Beim ersten Durchlauf überspringbar — manuelles Ausfüllen funktioniert ebenfalls.
4. Vollständiger Track. governance_protocol, change_log, decision_hash, Referendum. Beim ersten Durchlauf nicht zwingend zu lesen: sie werden nötig, wenn das Team ein automatisches Gateway bekommt.

Wenn Sie zum ersten Mal lesen, halten Sie nach dem Abschnitt „Schlüsselideen" an und machen Sie die Übung. Zum vollständigen Track kehren Sie zurück, nachdem Sie capstone/constitution.md mit dem minimalen Fragment abgeschlossen haben.

Ziel

Bis zum Ende des Abschnitts entwickeln Sie eine funktionierende constitution.md für Auto-Remediation. Invarianten und veränderliche Normen werden verständlich, durch Agenten-Referendum evolvierend und in der Genealogie der Änderungen vollständig nachvollziehbar.

Was das in der Praxis bringt. Der Agent handelt nicht mehr nach verstreuten Hinweisen. Er prüft jede Entscheidung gegen den formalen Projektvertrag. Solcher Vertrag hilft, die Reaktion auf wiederkehrende Incidents zu beschleunigen, verwandelt aber Geschwindigkeit nicht in das Recht, Backups, Audit, Blast-Radius-Limits und Bedingungen für sicheren Rollback automatisch zu umgehen.

Minimales schulisches Szenario

Schulischer Fall

Für node_not_ready muss ein sanfter Agenten-Neustart in der Triage-Phase erlaubt, aber gefährliche Aktionen mit Production-DB, Backups und Audit verboten werden. Ziel ist eine kleine constitution.md, die vor jeder Production-Aktion mit den Augen geprüft werden kann.

Vorbereitung

• book2/examples/templates/proposal.md — Änderungsformular.
• Eine Liste gefährlicher Aktionen, die nicht automatisch ausgeführt werden dürfen.
• Ein wiederkehrendes Unknown-Muster, das zu einer Mutable-Regel werden kann.

Für den ersten Durchlauf können Sie diesen Start-Satz nehmen:

dangerous_actions:
  - delete_namespace
  - restart_database
  - bypass_audit_trace
candidate_mutable_rule:
  incident_type: node_not_ready
  pipeline_phase: triage
  permitted_actions: ["soft_restart_agent"]
  max_scope: "single_node"

ttl: "30d"
  rollback_condition: "repeat_incidents_same_node>=2 or Safety veto"

Wenn Sie das Kapitel an Ihr Projekt anpassen, ersetzen Sie die Aktionsnamen, entfernen aber nicht max_scope, ttl und rollback_condition.

Schritte

1. Notieren Sie mindestens zwei immutable_principles als Verbote, nicht als Ratschläge.
2. Fügen Sie eine mutable_rule mit incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition hinzu.
3. Beschreiben Sie governance_protocol: Rollen, Quorum, Veto von Safety und Tie-Breaker-Regel.
4. Füllen Sie ein kurzes proposal.md aus: warum die Regel entstand, wer abgestimmt hat, wann sie aktiviert wird und wie zurückgerollt wird.
5. Prüfen Sie die Datei mit der Frage: „Welche Aktion wird der Agent nicht ausführen können, auch wenn das den MTTR senkt?". *Erwartung: Die Antwort findet sich in immutable_principles, nicht im Chat.*
6. Vergleichen Sie mit dem Runnable-Analogon aus [examples/spec-ci/](examples/spec-ci/README.md): Die Idee ist dieselbe — vor der Aktion muss ein prüfbares Gateway stehen.

Kontrollfakt

Jede veränderliche Regel hat ttl, max_scope und rollback_condition. Fehlt mindestens ein Feld, wird die Regel nicht in die Verfassung aufgenommen und bleibt ein Proposal-Entwurf.

Die Datei kann mit demselben Runnable-Analogon wie in capstone/ geprüft werden:

cd book2/examples/constitution
python3 scripts/check.py \
  --constitution specs/constitution.yaml \
  --proposal proposals/valid_proposal.md

Sie erhalten verdict: PASS. Wiederholen Sie dann mit proposals/missing_evidence.md und proposals/conflict_with_immutable.md — Sie erhalten verdict: BLOCK mit Gründen. Das ist das schulische Gateway vor der gefährlichen Aktion.

Übertragung auf high_memory_usage

Der lokale Fall des Kapitels ist node_not_ready, aber der bewertbare ist high_memory_usage. Die Übertragung geschieht durch eine Zeile des Prinzips, nicht durch Kopieren der Regel.

Wenn diese Zeile nicht formulierbar ist, hat der lokale Fall noch kein übertragbares Prinzip geliefert — kehren Sie zu ihm zurück, bevor Sie in capstone/ wechseln.

Wie das in capstone/ gelangt

Übertragen Sie in capstone/constitution.md zwei immutable_principles, eine mutable_rule und ein kurzes governance_protocol. Wenn Sie proposal.md erstellt haben, hinterlassen Sie in capstone/README.md eine Zeile mit dem Grund für das Entstehen der Regel. Übertragen Sie nicht das vollständige Agenten-Referendum, wenn es nicht gestartet wurde.

Minimales Fragment:

immutable_principles:
  - "Keine Auto-Remediation ohne audit_trace."
  - "Stateful Workload nicht ohne bestätigtes Backup anfassen."
mutable_rules:
  - incident_type: high_memory_usage
    pipeline_phase: recovery
    permitted_actions: ["restart_pod"]
    max_scope: "single_pod"
    ttl: "14d"
    rollback_condition: "memory_percent>=90% after 2 windows or 5xx increases"
governance_protocol: "Jede Ausweitung von max_scope erfordert ein separates Proposal."

Review-fähige Spur

Im schulischen Paket speichern Sie constitution.md zusammen mit proposal.md oder einem change_log-Eintrag. Eine Änderung ohne Herkunft gilt nicht als Teil des Production-SDD.

Schlüsselideen

Die erste Schicht von constitution.md — immutable_principles. Unter immutable_principles (unveränderliche Prinzipien) versteht man Regeln, die niemals automatisch deaktiviert werden können. Dazu gehören Verbote und Pflichten auf Sicherheitsebene:

• Production-DB nicht ohne aktuelles Backup neu starten;
• Backups nicht löschen, um Speicherplatz freizugeben;
• Incident nicht ohne bestätigte Stabilisierung in resolved überführen;
• Bypass in sicherheitskritischen Namespaces nicht ausführen.

Formulieren Sie diese Normen als Invarianten, nicht als Empfehlungen. Gerade sie begrenzen den Agenten im Moment des Drucks, wenn der kürzeste Weg zur MTTR-Senkung einen größeren Kaskaden-Ausfall verursachen kann.

Die zweite Schicht — mutable_rules. Das sind veränderliche Normen mit genauem Wirkungsradius (im Gegensatz zu immutable_principles kann solche Regel durch formales Verfahren aufgehoben oder umgeschrieben werden). Für jede solche Regel geben Sie mindestens sechs Felder an. Was sie bedeuten:

• incident_type — Incident-Klasse, für die die Regel gilt;
• pipeline_phase — Reaktionsphase (triage, recovery usw.);
• permitted_actions — Liste erlaubter Aktionen;

• max_scope — Limit des Blast Radius (z.B. single_node);
• ttl (time to live) — Geltungsdauer der Regel, nach der sie überprüft oder verlängert werden muss;
• rollback_condition — Bedingung, unter der die Regel automatisch zurückgerollt wird.

Ohne diese Felder wird die Änderung zu weit und beginnt, mit den Invarianten zu konkurrieren. Vergleichen Sie zwei Varianten.

Schlecht:

- id: node_not_ready_soft_restart
  incident_type: "NodeNotReady"
  permitted_actions: ["soft_restart_agent"]

Problem: kein ttl, kein max_scope, kein rollback_condition. Die Regel ist unbefristet und ohne Radius-Grenzen. Nach einem halben Jahr wird sie niemand mehr überprüfen.

Gut:

- id: node_not_ready_soft_restart
  incident_type: "NodeNotReady"
  pipeline_phase: "triage"
  permitted_actions: ["soft_restart_agent"]
  max_scope: "single_node"
  ttl: "30d"
  rollback_condition: "repeat_incidents_same_node>=2 or Safety veto"

Erlauben Sie zum Beispiel einen sanften Neustart (soft restart) für incident:NodeNotReady in der Phase triage, verbieten Sie ihn aber für incident:DBWriteLag in der Phase recovery. Dieselbe Aktion hat in verschiedenen Kontexten unterschiedliches Risiko für Daten und Verfügbarkeit.

Halt für den ersten Durchlauf

Wenn Sie hier zum ersten Mal sind, haben Sie bereits alles für die Kapitelbewertung: zwei Immutable-Verbote, eine Mutable-Regel mit sechs Feldern, Verständnis des Unterschieds zu mission/tech-stack/roadmap des ersten Bands. Danach folgt der vollständige Track — governance_protocol, change_log, decision_hash, Referendum. Diese Mechanismen werden nötig, wenn das Team ein automatisches Gateway und drei-vier Rollen-Personen dazu bekommt. Für die bewertbare capstone/constitution.md sind sie nicht obligatorisch.

Wenn es in Ihrem Projekt noch keine einzige automatische Aktion gibt, gehen Sie direkt zum Abschnitt „Artefakte und Fertigkeitskriterien“, und den vollständigen Track lesen Sie nach Kapitel 8 nach (dort tauchen Rollen erneut im Datei-Schiedsgericht auf).

Vollständiger Track: governance_protocol

Machen Sie den Evolutions-Trigger beobachtbar: drei oder mehr wiederholte unvorhergesehene Incidents mit derselben pattern_id lösen ein obligatorisches Änderungsreferendum aus. Solcher Schwellenwert trennt einzelne Anomalie von stabiler Regellücke und erlaubt nicht, die Verfassung nach jedem lauten Alarm zu ändern.

Fixieren Sie ein Aggregationsfenster, z.B. 48 Stunden. In die Kandidaten-Änderung (dasselbe proposal.md, das zum Referendum gestellt wird) nehmen Sie auf:

• Eingangsereignisse;
• aktuelle unknown-Klassifikation;
• vermutetes Risiko;
• erwartete Wirkung;
• Aufhebungsbedingung.

Warum hier gleich mehrere Rollen, wenn im ersten Band ein Mensch für Review genügte. In Teil 16 des ersten Bands reichte ein Reviewer, weil Review-Objekt der Code einer Feature im schulischen AgentClinic war. Preis des Fehlers — Feature neu machen. Im Production-Szenario ist Review-Objekt anders: automatische gefährliche Aktion auf einem lebendigen Service. Preis des Fehlers — verlorene Daten, ausgeweiteter Blast Radius, verstecktes Schließen von P0. Ein einzelner Prüfer versagt nicht, weil er nicht intelligent genug ist, sondern weil es einem Menschen schwerfällt, gleichzeitig Korrektheit der Invariante, Anwendbarkeit des Playbooks und Risiko für Production im Kopf zu behalten. Daher wird die Prüfung auf Rollen verteilt, jede mit ihrer engen Frage. In minimaler Form können das noch immer drei Modelle desselben Agents sein, die dieselbe Datei nacheinander lesen — aber ihre Fragen sind unterschiedlich.

Beschreiben Sie das Abstimmungsverfahren in governance_protocol. Dazu gehören Agenten-Rollen, Stimmgewichte, Quorum, Einberufungszeit und deterministische Tie-Break-Auflösung. Minimale Besetzung — drei Rollen:

• Verifier (Verifizierer) sucht nach Invarianten-Verletzungen;
• Implementor (Implementierer) bewertet die Anwendbarkeit im Playbook;
• Safety (Sicherheit) prüft Blast Radius, Privatsphäre und Rollback-Bedingungen.

Für Annahme setzen Sie Quorum auf zwei Stimmen, Regel 2 approve + no Safety-veto, Einberufung innerhalb von 15 Minuten nach Trigger-Auslösung und Tie-Breaker-Regel safety-first. Bei dieser Auflösung führt kritisches Risiko von Safety immer zur Ablehnung.

Die vierte Rolle, Koordinator, stimmt in governance_protocol nicht ab. Sie erscheint auf der nächsten Ebene — im Datei-Schiedsgericht (Teil 8), wo sie judgment.md und die Rundenordnung führt. Hier, in der Verfassung, protokolliert der Koordinator nur das Abstimmungsergebnis in change_log.

Fixieren Sie jedes Update als unveränderliche Spur, nicht als herkunftlose Änderung. In den Eintrag nehmen Sie auf:

• version und parent_version — aktuelle und vorherige Verfassungsversion;
• reason — Grund der Änderung;
• votes — Abstimmungsergebnisse nach Rollen;

• decision_hash — kryptografischer Hash der Entscheidung, anhand derer sie später nachrechenbar und prüfbar ist;
• incident_context — Ereignisse, die den Trigger ausgelöst haben;
• activation_time — Zeitpunkt, ab dem die Änderung wirkt;
• Verweis auf den Unterschied (diff) innerhalb des Repositories.

Solches Journal verwandelt die Änderungshistorie in eine Beweiskette. Wenn später die Frage aufkommt, warum der Agent das Recht hatte, eine Aktion auszuführen, wird die Antwort nicht im Chat des Teams, sondern in einer reproduzierbaren Entscheidungs-Genealogie zu finden sein.

Beispiele und Anwendung

Die Basisstruktur von constitution.md kann so aussehen:

immutable_principles:
  - id: prod_db_no_restart_without_backup
    rule: "Production database restart is forbidden unless a verified backup exists."
    enforcement: "always_on"

  - id: backups_are_protected_assets
    rule: "Backup deletion, overwrite, or quarantine bypass cannot be executed automatically."
    enforcement: "always_on"

mutable_rules:
  - id: node_not_ready_soft_restart_triage
    incident_type: "NodeNotReady"
    pipeline_phase: "triage"
    permitted_actions:
      - "cordon_node"
      - "soft_restart_agent"
    max_scope: "single_node"
    ttl: "30d"

rollback_condition: "increase in repeat incidents or Safety veto"

governance_protocol:
  roles:
    verifier:
      vote_weight: 1
    implementor:
      vote_weight: 1
    safety:
      vote_weight: 1
      veto: "critical_risk"
  quorum: 2
  pass_rule: "at_least_2_approve_and_no_safety_veto"
  convene_after: "3_unknown_incidents_same_pattern"
  convene_within: "15m"
  tie_breaker: "safety_first_then_latest_matching_precedent"

change_log:
  - version: "1.2.0"
    parent_version: "1.1.0"
    reason: "3 unknown NodeNotReady incidents in 48h"
    votes:
      verifier: "approve"
      implementor: "approve"
      safety: "abstain"
    decision_hash: "sha256:..."
    activation_time: "2026-05-17T12:00:00Z"

Binden Sie die Verfassung an Gateway-Prüfungen vor der Playbook-Ausführung an, nicht danach. Die Schrittfolge:

1. lokales Skript prüft immutable_principles und mutable_rules;
2. Qwen Code im Planungsmodus (Plan Mode) erklärt Risiko und Lücken;
3. der Ausführende erhält die Handlungserlaubnis.

Die Befehle /constitution und /tasks sind keine eingebauten Befehle von Qwen Code. Falls nötig, formulieren Sie sie als benutzerdefinierte Projektbefehle (project custom commands).

Interview über Qwen Code

Bevor Sie constitution.md von Hand schreiben, führen Sie dasselbe Interview wie in Teil 6 des ersten Bands. Die Production-Schicht fügt der klassischen Triade mission/tech-stack/roadmap zwei Konturen hinzu, und in diese Konturen darf man ohne explizite Menschen-Entscheidungen nicht eintreten: welche Aktionen der Agent ohne Bestätigung ausführen darf, wer Veto bekommt, welcher maximale Blast Radius in der Phase triage erlaubt ist.

Anfrage:

/clear
Wir erweitern die Verfassung von AgentClinic-production.
Sieh dir @specs/mission.md, @specs/tech-stack.md, @specs/roadmap.md
und @specs/playbooks/node-not-ready.md an.

Erstelle einen Entwurf von @specs/constitution.md mit drei Sektionen:
- immutable_principles
- mutable_rules
- governance_protocol

Bevor du auf die Platte schreibst, stell mir genau drei gruppierte Fragen:
1. Welche Agenten-Aktionen in Production sind immer verboten (Backups, Audit, Secrets).
2. Welche Aktionen können in der Phase triage mit Blast-Radius-Limit und TTL delegiert werden.
3. Wer stimmt ab, wer hat Veto, nach welchem Schwellenwert wird das Referendum einberufen.

Dateien noch nicht schreiben. Nach meinen Antworten zeige den Änderungsplan, warte auf Zustimmung.

Wenn Qwen Code sofort YAML ohne Fragen zu schreiben beginnt, stoppen Sie ihn:

Stopp. Schreibe keine Dateien vor dem Interview.
Stell zuerst die drei gruppierten Fragen, wie in QWEN.md angegeben.

Eine gute Menschen-Antwort im Interview enthält Entscheidungen, nicht Wünsche:

Unveränderliche Prinzipien:
Keine Auto-Neustarts von Production-DB ohne geprüftes Backup.
Kein automatisches Löschen von Backups, Audit und Secrets — auch nicht unter Druck der Speicherplatz-Freigabe.
Incident geht nicht ohne zwei aufeinanderfolgende OK in resolved.

Veränderliche Regeln:
In der Phase triage für NodeNotReady ist soft_restart_agent mit max_scope=single_node und ttl=30d erlaubt.
Rollback der Regel — bei zwei wiederholten Incidents auf demselben Knoten oder Veto von Safety.
Ausweitung von max_scope ohne Referendum verboten.

Governance:
Stimmen ab Verifier, Implementor, Safety. Jede Stimme gleich 1.
Quorum — 2 approve und kein Safety-Veto.
Referendum wird nach drei Unknown-Incidents mit derselben pattern_id in 48 Stunden einberufen.
Tie-Breaker-Regel — safety_first.

Dann bitten Sie Qwen, den eigenen Entwurf zu prüfen:

Prüfe @specs/constitution.md.
Finde Immutable-Regeln, die als Empfehlungen formuliert sind.

Finde Mutable-Regeln ohne ttl, max_scope oder rollback_condition.
Finde governance_protocol ohne Tie-Breaker-Regel.
Ändere Dateien nicht, gib Liste der Nichtkonformitäten zurück.

Typische Fehler in diesem Schritt:

• unveränderliche Regel als „möglichst vermeiden" geschrieben — das ist Empfehlung, nicht Verbot;
• veränderliche Regel ohne rollback_condition, bleibt bei Incident unbefristet;
• governance_protocol beschreibt keine Tie-Breaker-Regel — bei Gleichstand hängt das System;
• change_log fehlt, und die erste Verfassungsänderung verliert die Herkunft.

Erst nach Durchlauf dieser Liste fixieren Sie den Entwurf in Ihrem Projekt. Im schulischen book2/ erfordert dieser Schritt keine Git-Befehle: wichtig ist eine lesbare constitution.md mit Herkunft der Regel.

> Verfassungs-Gateway: Runnable-Analogon und Projekt-Interface. Die Runnable-Prüfung liegt in [examples/constitution/](examples/constitution/README.md) — sie liest YAML der Verfassung und Markdown mit YAML-Frontmatter (Änderungsvorschlag), gibt verdict: PASS|BLOCK und Blocker-Liste zurück. Für die Bewertung genügt sie. Im realen Projekt wird dieses Gateway um zwei weitere Schritte ergänzt: Anfrage an Qwen Code im Planungsmodus (Plan Mode) und Prüfung von Playbook-max_scope gegen Regel-max_scope. Alle drei Schritte laufen als ein Block.

# [runnable] — Prüfung des Vorschlags gegen die Verfassung
python3 book2/examples/constitution/scripts/check.py \
  --constitution book2/examples/constitution/specs/constitution.yaml \
  --proposal book2/examples/constitution/proposals/valid_proposal.md

# [project script] — dieselben Prüfungen an Ihrer Verfassung und Ihrem Playbook
python3 scripts/constitution/check.py \
  --constitution specs/constitution.yaml \
  --proposal proposals/<your-proposal>.md

# [project script] — Qwen im Planungsmodus, separates Gateway
qwen -p "Prüfe @specs/constitution.yaml und @specs/playbooks/node-not-ready.md.
Modus: nur Planung. Sage, ob der Remediation-Plan immutable_principles verletzt

und welche mutable_rules für die Zulassung nötig sind." \
  --approval-mode plan \
  --output-format json \
  > out/node-not-ready-constitution-review.json

flowchart TD
A[Incident] --> B[Plan Mode und scripts gegen immutable] --> C[Prüfung mutable rules] --> D[Zulassung / Block] --> E[Ausgeführte Aktion]
C --> F[Unknown Incident] --> G[Unknown-Schwellenwert erreicht] --> H[Formulierung Proposal] --> I[Referendum] --> J[Commit] --> K[Neue Verfassung]

Das Referendum lässt sich bequem an einem Replay-Szenario trainieren. Drei identische unknown-Incidents erzeugen proposal.md, Agents stimmen ab, und die angenommene Änderung gelangt mit Entscheidungs-Hash in change_log.

Beispiel: die temporäre Regel hotfix_ticketing_flood kann vereinfachtes Ticket-Routing für 12 Stunden erlauben. Bedingung — Vorhandensein eines Wiederherstellungspunkts (Checkpoint) und Erhalt des unveränderlichen Verbotes gegen Audit-Verlust. Nach Annahme prüfen Sie, dass die Änderung nicht unbefristet wurde. Vergewissern Sie sich, dass ttl, rollback_condition, decision_hash und activation_time zusammen mit dem Änderungseintrag im Repository sichtbar sind.

Fazit

constitution.md setzt für Auto-Remediation die Grenze zwischen dem, was der Agent anpassen kann, und dem, was er nicht das Recht hat, für lokale Optimierung zu deaktivieren.

Die Rollen der Schichten in dieser Grenze sind:

• Invarianten schützen Backups, Audit, Daten und kritische Zonen;
• veränderliche Schicht erlaubt die Verfeinerung von Playbooks bei wiederkehrenden Incidents;
• Agenten-Referendum macht Regeländerung prüfbar;
• Änderungs-Genealogie bewahrt Grund, Stimmen, Entscheidungs-Hash und Aktivierungszeitpunkt.

Als Nächstes werden diese Normen in der LLM-Duell geprüft: Verifizierer gegen Implementierer.

Artefakte und Fertigkeitskriterien

Der vollständige Track fügt mehrere Änderungen mit unterschiedlichen Blast-Radii hinzu, change_log-Eintrag mit parent_version, Stimmen und decision_hash sowie ein Projekt-Gateway, das die Verfassung vor Playbook-Ausführung prüft. Betrachten Sie ihn als fertig, wenn das Gateway tatsächlich Verletzungen der unveränderlichen Schicht vor Ausführung blockiert, das Referendum Quorum, Safety-Veto und deterministische Tie-Breaker-Regel hat, und die angenommene Änderung vom Incident-Kontext bis zum Unterschied (diff) nachvollziehbar ist.

Praxis

1. Öffnen Sie book2/examples/templates/proposal.md und füllen Sie es für eine gefährliche Domäne (Deployment, Migrationen, Incidents, Secrets) aus: mindestens zwei immutable_principles (als Verbote) und eine mutable_rule mit incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition. Erwartung: jede veränderliche Regel enthält alle sechs Felder; der Kontrollfakt aus dem schulischen Szenario ist erfüllt.
2. Notieren Sie governance_protocol: Rollen, Quorum, Safety-Veto und Tie-Breaker-Regel; stellen Sie die Frage „Welche Aktion wird der Agent nicht ausführen können, auch wenn das den MTTR senkt?". *Erwartung: Die Antwort findet sich in immutable_principles, nicht im Chat.*

1. Übertragen Sie in capstone/constitution.md zwei immutable_principles, eine mutable_rule und ein kurzes governance_protocol (Format — Fragment im schulischen Szenario des Kapitels); wenn Sie proposal.md gestartet haben, fügen Sie in capstone/README.md eine Zeile mit dem Grund für das Entstehen der Regel hinzu. Erwartung: Änderung ohne Herkunft gelangt nicht in das SDD-Paket.

Kontrollfragen

1. Welche Projektregeln müssen unveränderlich sein, und welche nicht?
2. Warum braucht eine veränderliche Regel ttl und was geschieht ohne sie nach einem Jahr?
3. Was muss bei Safety-Veto geschehen und warum lässt es sich nicht mit zwei approve umgehen?
4. Nach drei gleichen NodeNotReady in 48 Stunden löste der Referendum-Trigger aus, aber in diesem Moment läuft ein aktiver Incident. Was machen Sie mit der Änderung — annehmen, verschieben oder den Trigger zurückrollen?