Thema: Praxisteil 3. Projektverfassung: das erste Regelfreferendum
Schwierigkeitsgrad: Mittel
Geschätzte Lernzeit: 2-3 Stunden
Voraussetzungen: Vertrautheit mit dem Material des ersten Bandes: den Dateien mission.md, tech-stack.md, roadmap.md (Teil 6).
Verständnis der Grundlagen der SDD-Prozesssicherheit (Teil 18 des ersten Bandes).
Grundlegende Kenntnisse im Umgang mit den Formaten YAML und Markdown.
Lernziele: Lernen, Produktverträge (mission/tech-stack/roadmap) klar von der Sicherheitsverfassung der Automatisierung (constitution.md) zu trennen.
Unveränderliche Prinzipien (immutable_principles) als strenge Verbote und nicht als Empfehlungen formulieren können.
Die Erstellung veränderlicher Regeln (mutable_rules) mit verpflichtender Ausfüllung aller 6 kritischen Felder (incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition) beherrschen.
Das Basisprotokoll zur Steuerung (governance_protocol) verstehen und beschreiben können, einschließlich der Agentenrollen, Abstimmungsregeln und Vetobedingungen.
Praktische Fähigkeit erwerben, Regeln von einem Vorfall (node_not_ready) auf einen anderen (high_memory_usage) zu übertragen, ohne sie blind zu kopieren.
Übersicht: Dieser Abschnitt widmet sich der Erstellung der „Projektverfassung“ – einem versionierten Regelsatz und Einschränkungsset für sichere Automatisierung (Auto-Remediation) und die Arbeit von KI-Agenten. Während die Dateien des ersten Bandes (mission.md, tech-stack.md, roadmap.md) die Frage beantworten „was wir bauen“, beantwortet die neue Datei constitution.md die Frage „was der Agent damit nicht tun darf, selbst wenn er es unbedingt möchte“. Die Verfassung besteht aus zwei Hauptschichten: immutable_principles (unveränderliche Verbote, die Datenbank, Backups und Audit schützen) und mutable_rules (veränderliche Regeln mit streng begrenztem Wirkungsradius, Lebensdauer und Rückrollbedingungen). Im Abschnitt wird auch das Verfahren zur Annahme von Änderungen durch ein Agentenreferendum behandelt, das Regeländerungen transparent und nachvollziehbar macht.
Schlüsselkonzepte: Constitution.md: Versionierter Satz von Invarianten und veränderlichen Regeln, der den Rahmen der sicheren Automatisierung beschreibt. Wird vor der Ausführung jeglicher gefährlicher Aktionen durch den Agenten geprüft.
Immutable principles: Unveränderliche Prinzipien – Verbotsregeln, die niemals automatisch deaktiviert werden können (zum Beispiel das Verbot, Backups zu löschen oder die Datenbank ohne Sicherung neu zu starten). Schränken den Agenten im Moment des Drucks zur Senkung der MTTR ein.
Mutable rules: Veränderliche Normen mit genau definiertem Wirkungsradius, die durch ein formelles Verfahren aufgehoben oder umgeschrieben werden können. Müssen 6 Felder enthalten: incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition.
Governance protocol: Steuerungsprotokoll, das das Abstimmungsverfahren (Referendum) für Änderungen an der Verfassung beschreibt. Umfasst Rollen (Verifier, Implementor, Safety), Stimmgewicht, Quorum und die Tie-Breaker-Regel bei Stimmengleichheit.
Ttl (time to live): Lebensdauer einer veränderlichen Regel. Nach Ablauf dieser Frist muss die Regel überprüft oder verlängert werden, um das Entstehen unbefristeter und vergessener Genehmigungen zu verhindern.
Max scope: Maximaler Wirkungsradius (blast radius) für eine veränderliche Regel (zum Beispiel single_node oder single_pod). Schützt vor massiven kaskadierenden Ausfällen.
Rollback condition: Bedingung für das automatische Zurückrollen einer veränderlichen Regel (zum Beispiel Wiederauftreten des Vorfalls oder Veto durch die Safety-Rolle).
Proposal.md: Form einer Änderung, die dem Referendum vorgelegt wird. Muss den Entstehungsgrund, den Vorfalls-Kontext, die Stimmen und die Aktivierungsbedingungen enthalten.
Übungsaufgaben: Name: Audit einer veränderlichen Regel (mutable_rule)
Problem: Unten ist ein Fragment einer veränderlichen Regel angegeben, die von einem Entwickler geschrieben wurde. Finden Sie die kritischen Fehler, aufgrund derer die Regel nicht in constitution.md aufgenommen werden kann, und erklären Sie deren Auswirkung auf die Systemsicherheit.
- id: db_write_lag_restart
incident_type: "DBWriteLag"
permitted_actions: ["restart_database"]Lösung: 1. Es fehlt pipeline_phase: Es ist unklar, in welcher Phase (triage, recovery) die Aktion erlaubt ist.
- Es fehlt max_scope: Keine Begrenzung des Wirkungsradius. Die Aktion könnte auf den gesamten Cluster angewendet werden.
- Es fehlt ttl: Die Regel wird unbefristet. In einem halben Jahr wird sich niemand an den Grund ihrer Erstellung erinnern.
- Es fehlt rollback_condition: Es gibt keinen Mechanismus zum automatischen Zurückrollen bei Verschlimmerung der Situation.
Ergebnis: Eine solche Regel ist zu weitreichend und birgt das Risiko von Datenverlust.
Komplexität: intermediate
Name: Entwicklung von immutable_principles
Problem: Formulieren Sie zwei unveränderliche Prinzipien (immutable_principles) für ein Vorfallautomatisierungsprojekt. Sie müssen strenge Verbote sein, keine Wünsche.
Lösung: Beispiel für korrekte Formulierungen:
- „Es ist verboten, Sicherungskopien zur Freigabe von Speicherplatz automatisch zu löschen“.
- „Es ist verboten, einen Vorfall in den Status resolved zu überführen, ohne zwei aufeinanderfolgende Stabilisierungsbestätigungen (OK) vom Monitoring-System zu erhalten“.
Falsches Beispiel (Empfehlung): „Es ist wünschenswert, Backups nicht ohne Notwendigkeit zu löschen“.
Komplexität: beginner
Name: Übertragung einer Regel auf einen neuen Vorfall (high_memory_usage)
Problem: Sie müssen die Erfahrung mit node_not_ready auf den Vorfall high_memory_usage übertragen. Schreiben Sie die veränderliche Regel (mutable_rule) im YAML-Format. Erlauben Sie den Neustart des Pods (restart_pod) in der Phase recovery, mit einer Laufzeit von 14 Tagen, mit Zurückrollen bei Anstieg von 5xx-Fehlern oder wenn der Speicher >= 90% beträgt.
Lösung: ```yaml
- 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"
Komplexität: advanced
Fallstudien:
Name: Auto-Remediation des Vorfalls NodeNotReady
Szenario: In der Produktionsumgebung tritt regelmäßig der Vorfall NodeNotReady auf. Der KI-Agent schlägt vor, im Bestreben, die Ausfallzeit (MTTR) zu minimieren, automatisch Knoten und Agenten ohne menschliches Zutun neu zu starten.
Aufgabe: Balance zwischen Reaktionsgeschwindigkeit und Sicherheit. Wenn der Agent den falschen Knoten neu startet oder in eine Stateful-Workload ohne Backup eingreift, verlängert sich die Ausfallzeit, und Daten können verloren gehen. Ein formelles Gateway ist erforderlich.
Lösung: Das Team führt constitution.md ein. In den immutable_principles wird das Verbot festgehalten, Stateful-Workloads ohne Backup anzufassen. In den mutable_rules wird 'soft_restart_agent' strikt mit max_scope: 'single_node', ttl: '30d' und einer Rückrollbedingung bei wiederholten Ausfällen hinzugefügt. Es wird ein governance_protocol mit Quorum (2 approve) und Vetorecht für die Safety-Rolle erstellt.
Ergebnis: Der Agent erhielt die Möglichkeit, schnell auf ein bekanntes Problem zu reagieren (weicher Neustart), aber das System blockiert ihn automatisch, wenn er versucht, eine gefährliche Aktion auszuführen (harter Neustart der Datenbank) oder die Schadenszone zu überschreiten.
Gewonnene Erkenntnisse:
Die Wiederherstellungsgeschwindigkeit (MTTR) darf nicht durch Umgehung des Audits und der Sicherung erreicht werden.
Jede Genehmigung zur Auto-Remediation muss ein Verfallsdatum (ttl) und einen begrenzten Wirkungsradius (max_scope) haben.
Veränderliche Regeln ohne Rückrollbedingungen werden zu unbefristeten und gefährlichen Schlupflöchern.
Verwandte Konzepte:
immutable_principles
mutable_rules
max_scope
Name: Verfassungsgateway: Prüfung von proposal.md
Szenario: Das Monitoring-System hat in den letzten 48 Stunden 3 unbekannte Vorfälle mit derselben pattern_id erfasst. Der Prozess des Agentenreferendums zur Erstellung einer neuen Regel wurde eingeleitet.
Aufgabe: Sicherstellen, dass die vorgeschlagene Änderung (proposal.md) an der Verfassung die grundlegenden Sicherheitsinvarianten nicht verletzt und alle notwendigen Informationen für die Nachvollziehbarkeit (provenance) enthält.
Lösung: Verwendung eines runnable-Pendants (Skript check.py). Der Koordinator-Agent erstellt proposal.md mit Nachweisen. Anschließend liest das Skript die Verfassung und den Vorschlag und prüft das Vorhandensein aller 6 Felder für neue Regeln. Die Verifier-Rolle prüft die formale Logik, und Safety bewertet die Risiken einer Erweiterung des Wirkungsradius.
Ergebnis: Das Skript gibt das Urteil aus: PASS oder BLOCK. Wenn die Regel angenommen wird, wird ein Eintrag im change_log mit version, parent_version, Abstimmungsergebnissen (votes), decision_hash und activation_time vorgenommen. Es entsteht eine nachvollziehbare Entscheidungsgenealogie.
Gewonnene Erkenntnisse:
Eine Änderung ohne Herkunft (ohne Festhalten von Grund und Kontext) ist kein Teil eines sicheren Prozesses.
Die Automatisierung der Regelprüfung durch Skripte ist zuverlässiger als die manuelle Überprüfung durch einen Menschen unter Druck.
Die Genealogie der Änderungen muss einen kryptographischen Hash (decision_hash) enthalten, um vor unbefugter Änderung der Geschichte zu schützen.
Verwandte Konzepte:
governance_protocol
change_log
decision_hash
Lerntipps:
Halten Sie bei der ersten Lektüre im Abschnitt „Schlüsselideen“ an und gehen Sie zur Praxis über. Die vollständige Strecke (Referendum, Hashes, Schiedsverfahren) lernen Sie besser nach der Festigung der Grundlagen.
Formulieren Sie Invarianten so, dass die Antwort auf die Frage „welche Aktion der Agent nicht ausführen können wird, selbst wenn dies die MTTR senkt?“ im Text der Datei liegt, nicht im Chat mit dem Entwickler.
Verwenden Sie das Prüfskript (check.py) in frühen Phasen. Wenn das Skript Ihren Vorschlag blockiert (verdict: BLOCK), weist es sofort auf die fehlenden Felder (ttl, max_scope) hin.
Bei der Übertragung von Regeln von einer Domäne auf eine andere (zum Beispiel von node_not_ready auf high_memory_usage) passen Sie die Rückrollbedingungen (rollback_condition) an, anstatt sie blind zu kopieren.
Zusätzliche Ressourcen:
Vorlagenvorschlag (proposal.md): book2/examples/templates/proposal.md – verwenden Sie diese Vorlage, um Ihre ersten Vorschläge für die Verfassung zu formulieren.
Verfassungsprüfskript: book2/examples/constitution/scripts/check.py – runnable-Pendant zur Prüfung Ihrer YAML-Dateien auf Übereinstimmung mit den 6 Pflichtfeldern.
Teil 6 des ersten Bandes: Grundlage zur Erstellung von Produktspezifikationen (mission.md, tech-stack.md, roadmap.md), die nicht durch constitution.md ersetzt werden.
Teil 18 des ersten Bandes: Grundlagen der SDD-Prozesssicherheit, die erklären, warum gefährliche Aktionen ein formelles Gateway durchlaufen müssen.
Zusammenfassung: Die Projektverfassung (constitution.md) ist ein kritischer Sicherheitsrahmen, der trennt, was der KI-Agent anpassen darf, von dem, was er nicht ausschalten darf. Sie besteht aus unveränderlichen Invarianten (immutable_principles), die Daten und Audit schützen, und veränderlichen Normen (mutable_rules), die strenge Grenzen (max_scope), eine Lebensdauer (ttl) und Rückrollbedingungen haben müssen. Für das Bestehen des Themas genügt es, eine minimale Datei mit zwei Verboten, einer veränderlichen Regel mit 6 Feldern und einem kurzen Steuerungsprotokoll zu erstellen, wobei sichergestellt wird, dass jede Erweiterung der Agentenrechte nachvollziehbar und begründet ist.