Anwendungsteil 3. Projektverfassung: das erste Regelreferendum

Status: Empfehlung. Die Trennung von immutable_principles und mutable_rules mit explizitem ttl, max_scope, rollback_condition ist eine bewährte Praxis. Das automatische Agenten-Referendum mit deterministischer Tie-Breaker-Regel ist Frontier: Seine Form hängt vom jeweiligen Team und den Modellen ab.

Für den Übungsdurchlauf genügt es, constitution.md manuell auszufüllen und zu prüfen, dass veränderliche Regeln ttl, max_scope und rollback_condition aufweisen. Das automatische Referendum und ein externer Schiedsrichter gehören zum vollständigen Production-Track.

Die „Projektverfassung" ist hier ein versionierter Satz von Invarianten, veränderlichen Regeln und dem Verfahren zur Annahme von Änderungen. Dieser Satz wird vor der 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 (womit wir arbeiten), 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 Rahmen sicherer Automatisierung: Welche Agenten-Aktionen verboten sind, welche eingeschränkt erlaubt sind, wer und wie Regeln ändert. Dies ist eine Erweiterung, kein Ersatz. 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 möchten: mission/tech-stack/roadmap beantworten die Frage „Was bauen wir?", constitution.md beantwortet die Frage „Was darf der Agent damit nicht tun, auch wenn er es noch so gerne möchte?".

Im Übungsminimum genügt eine kleine constitution.md mit zwei unveränderlichen Verboten und einer veränderlichen Regel. Das Agenten-Referendum, ein externer Schiedsrichter und die automatische Playbook-Überprüfung werden nur im vollständigen Track benötigt. Das Kapitel stützt sich auf Teil 6 des ersten Bands (woher mission.md, tech-stack.md, roadmap.md stammen) und Teil 18 (woher die Vorstellung von der Sicherheit des SDD-Prozesses stammt).

Vor dem Lesen

• Anker im ersten Band: Teil 6 führt mission.md, tech-stack.md, roadmap.md ein; Teil 18 erläutert die SDD-Sicherheit.

• Lokaler Übungsfall: 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 Durchgangs: immutable_principles und mutable_rules. Die dritte Schicht – governance_protocol – ist nachschlagbar und wird nur benötigt, wenn das Team eine Abstimmungsregel einführt.
• Was zurückzustellen ist: Agenten-Referendum, externer Schiedsrichter und automatische Playbook-Überprüfung.

Der Grund für eine separate Production-Schicht ist einfach: Szenarien wie node_not_ready oder autoscale_200pct lassen keine Zeit für Chat. Eine gefährliche Aktion muss entweder ein formales Gate passieren oder blockiert sein. Mit der Sicherheit dieses Gates befassen wir uns im Anker an Teil 18. SDD-Sicherheit. Die Verbindung zur Interaktion mit bereits laufendem Code findet sich in Teil 13. Unterstützung bestehender Projekte.

Fahrplan des Kapitels

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

1. Minimales Übungsszenario. Sie füllen constitution.md manuell aus: zwei immutable-Verbote, eine mutable-Regel mit sechs Feldern. Das ist alles, was für die Prüfung 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 Durchgang überspringbar – manuelles Ausfüllen funktioniert ebenfalls.
4. Vollständiger Track. governance_protocol, change_log, decision_hash, Referendum. Beim ersten Durchgang optional zu lesen: Sie werden relevant, sobald das Team ein automatisches Gate einführt.

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

Ziel

Am Ende des Abschnitts entwickeln Sie eine funktionierende constitution.md für die Auto-Remediation. Invarianten und veränderliche Normen werden verständlich, entwickeln sich durch das Agenten-Referendum weiter und sind in der Änderungsgenealogie vollständig nachvollziehbar.

Was das in der Praxis bringt. Der Agent handelt nicht mehr nach vereinzelten Hinweisen. Er prüft jede Entscheidung gegen einen formalen Projektvertrag. Ein solcher Vertrag hilft, die Reaktion auf wiederkehrende Vorfälle zu beschleunigen, verleiht aber nicht das Recht, automatisch Backups, Audits, Grenzen des Blast Radius und Bedingungen für sicheres Rollback zu umgehen.

Minimales Übungsszenario

Übungsfall

Für node_not_ready muss ein sanfter Agenten-Neustart in der Triage-Phase erlaubt, gefährliche Aktionen auf Produktions-Datenbanken, Backups und Audits jedoch verboten sein. Ziel ist eine kleine constitution.md, die vor jeder Produktions-Aktion mit dem Auge überprüft werden kann.

Vorbereitung

• book2/examples/templates/proposal.md – Form einer Änderung.
• 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 Durchgang können Sie mit folgendem Startset beginnen:

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 eigenes Projekt anpassen, ersetzen Sie die Aktionsnamen, entfernen jedoch max_scope, ttl und rollback_condition nicht.

Schritte

1. Halten Sie mindestens zwei immutable_principles als Verbote fest, 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, Safety-Veto und Tie-Breaker-Regel.
4. Füllen Sie eine kurze proposal.md aus: warum die Regel entstand, wer abgestimmt hat, wann sie aktiviert wird und wie ein Rollback erfolgt.
5. Prüfen Sie die Datei mit der Frage: „Welche Aktion kann der Agent nicht ausführen, selbst wenn das die MTTR senkt?" *Erwartung: Die Antwort steht in den immutable_principles, nicht im Chat.*
6. Vergleichen Sie mit dem lauffähigen Analogon aus [examples/spec-ci/](examples/spec-ci/README.md): Die Idee ist dieselbe – vor der Aktion muss ein prüfbares Gate stehen.

Kontrolltatsache

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

Die Datei können Sie mit demselben lauffähigen Analogon prüfen wie in capstone/:

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

Sie erhalten verdict: PASS. Wiederholen Sie dies anschließend mit proposals/missing_evidence.md und proposals/conflict_with_immutable.md – Sie erhalten verdict: BLOCK mit Begründungen. Dies ist das Übungsgate vor der gefährlichen Aktion.

Übertragung auf high_memory_usage

Der lokale Fall des Kapitels ist node_not_ready, der Prüfungsfall ist high_memory_usage. Die Übertragung erfolgt durch eine einzige Prinzipien-Zeile, nicht durch Kopieren der Regel.

Wenn sich diese Zeile nicht formulieren lässt, hat der lokale Fall noch kein übertragbares Prinzip geliefert – kehren Sie zu ihm zurück, bevor Sie zu capstone/ wechseln.

Wie dies in capstone/ einfließt

Übertragen Sie in capstone/constitution.md zwei immutable_principles, eine mutable_rule und ein kurzes governance_protocol. Falls Sie eine proposal.md erstellt haben, vermerken Sie in capstone/README.md eine Zeile mit dem Grund für die Regel. Übernehmen Sie kein vollständiges Agenten-Referendum, wenn es nicht ausgeführt wurde.

Minimales Fragment:

immutable_principles:
  - "Keine Auto-Remediation ohne audit_trace."
  - "Stateful-Workloads 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 Erweiterung von max_scope erfordert einen separaten Vorschlag."

Überprüfbare Spur

Im Übungspaket bewahren Sie constitution.md zusammen mit proposal.md oder einem change_log-Eintrag auf. Eine Änderung ohne Herkunft gilt nicht als Teil des produktiven SDD.

Schlüsselideen

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

• Produktions-Datenbanken nicht ohne aktuelles Backup neu starten;
• Backups nicht zur Speicherfreigabe löschen;
• einen Vorfall nicht in resolved überführen, ohne bestätigte Stabilisierung;
• keinen Bypass in einem sicherheitskritischen Namespace ausführen.

Formulieren Sie diese Normen als Invarianten, nicht als Empfehlungen. Genau sie schränken den Agenten im Moment des Drucks ein, wenn der kürzeste Weg zur MTTR-Senkung einen größeren Ausfallkaskadeneffekt erzeugen kann.

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

• incident_type – die Klasse des Vorfalls, für die die Regel gilt;
• pipeline_phase – die Reaktionsphase (triage, recovery usw.);
• permitted_actions – die Liste erlaubter Aktionen;

• max_scope – die Grenze des Blast Radius (z. B. single_node);
• ttl (Time to Live) – die Gültigkeitsdauer der Regel, nach der sie überprüft oder verlängert werden muss;
• rollback_condition – die Bedingung, unter der die Regel automatisch zurückgerollt wird.

Ohne diese Felder wird eine Änderung zu breit 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: Es fehlen ttl, max_scope, rollback_condition. Die Regel ist unbefristet und ohne Begrenzung des Radius. 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 beispielsweise einen sanften Neustart (soft restart) für incident:NodeNotReady in der Phase triage, verbieten Sie ihn jedoch für incident:DBWriteLag in der Phase recovery. Dieselbe Aktion hat in unterschiedlichen Kontexten unterschiedliche Risiken für Daten und Verfügbarkeit.

Halt für den ersten Durchgang

Wenn Sie hier zum ersten Mal sind, haben Sie zu diesem Zeitpunkt alles für die Kapitelprüfung: zwei immutable-Verbote, eine mutable-Regel mit sechs Feldern, das Verständnis des Unterschieds zwischen ihr und mission/tech-stack/roadmap des ersten Bands. Weiter geht es mit dem vollständigen Track – governance_protocol, change_log, decision_hash, Referendum. Diese Mechanismen werden benötigt, sobald das Team ein automatisches Gate und drei bis vier Personen-Rollen darum herum hat. Für die prüfungsrelevante capstone/constitution.md sind sie nicht zwingend.

Wenn Sie im Projekt noch keine einzige automatische Aktion haben, gehen Sie direkt zum Abschnitt „Artefakte und Fertigkeitskriterien" und lesen den vollständigen Track nach Kapitel 8 zu Ende (dort tauchen Rollen erneut im Datei-Schiedsverfahren auf).

Vollständiger Track: governance_protocol

Machen Sie den Evolutionstrigger beobachtbar: Drei oder mehr wiederholte unvorhergesehene Vorfälle mit derselben pattern_id lösen ein obligatorisches Referendum über den Änderungsvorschlag aus. Ein solcher Schwellenwert trennt eine einzelne Anomalie von einer anhaltenden Regellücke und verhindert, dass die Verfassung nach jeder lauten Warnung geändert wird.

Legen Sie das Aggregationsfenster fest, beispielsweise 48 Stunden. In den Kandidaten-Vorschlag (jenes proposal.md, das dem Referendum vorgelegt wird) aufnehmen:

• Eingangsereignisse;
• die aktuelle Klassifikation unknown;
• das angenommene Risiko;
• die erwartete Wirkung;
• die Rücknahmebedingung.

Warum hier sofort mehrere Rollen nötig sind, obwohl im ersten Band eine Person das Review machte. In Teil 16 des ersten Bands genügte ein Reviewer, weil der Reviewgegenstand der Feature-Code in der Übungs-AgentClinic war. Der Fehlerpreis war, das Feature neu zu schreiben. In einem Produktionsszenario ist der Reviewgegenstand anders: eine automatische gefährliche Aktion auf einem laufenden Dienst. Der Fehlerpreis sind verlorene Daten, ein erweiterter Blast Radius, ein verborgenes Schließen eines P0. Ein einzelner Prüfer kommt nicht zurecht, nicht weil er zu wenig kompetent wäre, sondern weil es für einen Menschen schwierig ist, gleichzeitig die Korrektheit der Invariante, die Anwendbarkeit des Playbooks und das Risiko für die Produktion im Kopf zu behalten. Deshalb wird die Prüfung auf Rollen verteilt, jede mit ihrer eigenen engen Frage. In minimaler Form können dies immer noch drei Modelle desselben Agenten sein, die nacheinander dieselbe Datei lesen – doch ihre Fragen sind unterschiedlich.

Beschreiben Sie das Abstimmungsverfahren in governance_protocol. Dazu gehören die Rollen der Agenten, Stimmgewichte, Quorum, Einberufungszeit und die deterministische Tie-Breaker-Regel. Die Mindestzusammensetzung sind drei Rollen:

• Verifier sucht nach Invariantenverletzungen;
• Implementor bewertet die Anwendbarkeit im Playbook;
• Safety prüft den Blast Radius, den Datenschutz und die Rücknahmebedingungen.

Für die Annahme setzen Sie ein Quorum von zwei Stimmen, die Regel 2 approve + no Safety-veto, eine Einberufung innerhalb von 15 Minuten nach Auslösen des Triggers und die Tie-Breaker-Regel safety-first. Bei einem solchen Tie-Breaker führt ein kritisches Risiko von Safety stets zur Ablehnung.

Die vierte Rolle, der Koordinator, stimmt in governance_protocol nicht ab. Sie erscheint auf der nächsten Ebene – im Datei-Schiedsverfahren (Teil 8), wo sie judgment.md und die Rundungsreihenfolge führt. Hier, in der Verfassung, trägt der Koordinator das Abstimmungsergebnis nur in den change_log ein.

Halten Sie jede Aktualisierung als unveränderliche Spur fest, nicht als Änderung ohne Herkunft. In den Eintrag aufnehmen:

• version und parent_version – die aktuelle und vorherige Version der Verfassung;
• reason – der Grund der Änderung;
• votes – die Abstimmungsergebnisse nach Rollen;

• decision_hash – der kryptografische Hash der Entscheidung, mit dem sie später neu berechnet und überprüft werden kann;
• incident_context – die Ereignisse, die den Trigger ausgelöst haben;
• activation_time – der Zeitpunkt, ab dem die Änderung wirksam ist;
• einen Link auf den Diff innerhalb des Repositoriums.

Ein solches Journal verwandelt die Änderungshistorie in eine Beweiskette. Falls später die Frage aufkommt, warum der Agent die Berechtigung zur Ausführung einer Aktion erhielt, steht die Antwort nicht im Team-Chat, sondern in der reproduzierbaren Entscheidungsgenealogie.

Beispiele und Anwendung

Die Grundstruktur 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"

overnance_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 Gate-Prüfungen vor der Playbook-Ausführung, nicht danach. Die Schrittreihenfolge ist:

1. Ein lokales Skript prüft immutable_principles und mutable_rules;
2. Qwen Code im Plan-Modus erläutert Risiko und Lücken;
3. der Ausführende erhält die Berechtigung zur Aktion.

Die Befehle /constitution und /tasks sind keine eingebauten Befehle von Qwen Code. Falls sie benötigt werden, richten Sie sie als projekteigene Custom Commands ein.

Interview über Qwen Code

Bevor Sie constitution.md manuell schreiben, führen Sie dasselbe Interview wie in Teil 6 des ersten Bands. Die Produktionsschicht fügt der klassischen Dreiheit mission/tech-stack/roadmap zwei Konturen hinzu, und in diese Konturen darf man nicht ohne ausdrückliche menschliche Entscheidungen eintreten: Welche Aktionen darf der Agent ohne Bestätigung ausführen, wer erhält ein Veto, welcher maximale Blast Radius ist in der Phase triage erlaubt.

Anfrage:

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

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

Stelle mir vor dem Schreiben genau drei gruppierte Fragen:
1. Welche Agenten-Aktionen in der Produktion sind immer verboten (Backups, Audit, Secrets).
2. Welche Aktionen können in der Triage-Phase mit Blast-Radius-Limit und TTL delegiert werden.
3. Wer stimmt ab, wer hat Veto, bei welchem Schwellenwert wird das Referendum einberufen.

Schreibe noch keine Dateien. Zeige mir nach meinen Antworten einen Änderungsplan und warte auf Freigabe.

Falls Qwen Code sofort beginnt, YAML zu schreiben, ohne zu fragen, stoppen Sie es:

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

Eine gute menschliche Antwort auf das Interview enthält Entscheidungen, keine Wünsche:

Unveränderliche Prinzipien:
Keine automatischen Neustarts von Produktions-Datenbanken ohne geprüftes Backup.
Kein automatisches Löschen von Backups, Audits und Secrets – auch nicht unter Speicherdruck.
Ein Vorfall geht nicht in resolved über, ohne zwei aufeinanderfolgende OKs.

Veränderliche Regeln:
In der Triage-Phase ist für NodeNotReady soft_restart_agent mit max_scope=single_node und ttl=30d erlaubt.
Rollback der Regel – bei zwei wiederholten Vorfällen auf demselben Knoten oder Safety-Veto.
max_scope darf nicht ohne Referendum erweitert werden.

Governance:
Abstimmen: Verifier, Implementor, Safety. Jede Stimme zählt 1.
Quorum – 2 approve und kein Veto von Safety.
Das Referendum wird nach drei unknown-Vorfällen mit derselben pattern_id innerhalb von 48 Stunden einberufen.
Tie-Breaker – safety_first.

Bitten Sie anschließend 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 keine Dateien, gib eine Liste der Abweichungen zurück.

Typische Fehler an dieser Stelle:

• eine unveränderliche Regel ist als „nach Möglichkeit vermeiden" formuliert – das ist eine Empfehlung, kein Verbot;
• einer veränderlichen Regel fehlt rollback_condition, und bei einem Vorfall bleibt sie unbefristet;
• governance_protocol beschreibt keine Tie-Breaker-Regel – bei Stimmengleichheit hängt das System;
• change_log fehlt, und schon die erste Verfassungsänderung verliert ihre Provenienz.

Erst nach dem Durchgang durch diese Liste fixieren Sie den Entwurf in Ihrem Projekt. Im Übungs-book2/ erfordert dieser Schritt keine Git-Befehle: Wichtig ist eine lesbare constitution.md mit Herkunft der Regel.

> Verfassungsgate: lauffähiges Analogon und Projektschnittstelle. Die lauffähige Prüfung liegt in [examples/constitution/](examples/constitution/README.md) – sie liest die Verfassungs-YAML und Markdown mit YAML-Frontmatter (Änderungsvorschlag), gibt verdict: PASS|BLOCK und eine Liste der Blocker zurück. Für die Prüfung genügt das. In einem realen Projekt wird dieses Gate um zwei weitere Schritte ergänzt: einer Anfrage an Qwen Code im Plan-Modus und der Prüfung von max_scope des Playbooks gegen max_scope der Regel. Alle drei Schritte erfolgen 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 auf Ihrer Verfassung und Ihrem Playbook
python3 scripts/constitution/check.py \
  --constitution specs/constitution.yaml \
  --proposal proposals/<your-proposal>.md

# [project script] – Qwen im Plan-Modus, separates Gate
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[Vorfall] --> B[Plan-Modus und Skripte gegen immutable] --> C[Prüfung mutable rules] --> D[Zulassung / Block] --> E[Ausgeführte Aktion]
C --> F[Unknown-Vorfall] --> G[Unknown-Schwelle erreicht] --> H[Erstellung des Vorschlags] --> I[Referendum] --> J[Commit] --> K[Neue Verfassung]

Das Referendum lässt sich gut an einem Replay-Szenario üben. Drei gleiche unknown-Vorfälle erzeugen proposal.md, die Agenten stimmen ab, und die angenommene Änderung wird mit einem Entscheidungs-Hash in den change_log aufgenommen.

Beispiel: Eine temporäre Regel hotfix_ticketing_flood kann für 12 Stunden vereinfachtes Ticket-Routing erlauben. Voraussetzung ist ein Checkpoint und die Beibehaltung des unveränderlichen Verbots, Audits zu verlieren. Prüfen Sie nach der Annahme, dass die Änderung nicht unbefristet geworden ist. Stellen Sie sicher, dass ttl, rollback_condition, decision_hash und activation_time gemeinsam mit dem Änderungseintrag im Repository sichtbar sind.

Zusammenfassung

constitution.md zieht für die Auto-Remediation die Grenze zwischen dem, was der Agent anpassen darf, und dem, was er zugunsten einer lokalen Optimierung nicht abschalten darf.

Die Rollen der Schichten innerhalb dieser Grenze sind:

• Invarianten schützen Backups, Audits, Daten und kritische Zonen;
• die veränderliche Schicht erlaubt es, Playbooks anhand wiederkehrender Vorfälle zu präzisieren;
• das Agenten-Referendum macht Regeländerungen überprüfbar;
• die Änderungsgenealogie bewahrt Grund, Stimmen, Entscheidungs-Hash und Aktivierungszeitpunkt.

Diese Normen werden anschließend im LLM-Duell geprüft: Verifier gegen Implementor.

Artefakte und Fertigkeitskriterien

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

Übung

1. Öffnen Sie book2/examples/templates/proposal.md und füllen Sie es für eine gefährliche Domäne (Deployment, Migrationen, Vorfälle, Secrets): 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; die Kontrolltatsache aus dem Übungsszenario ist erfüllt.
2. Halten Sie governance_protocol fest: Rollen, Quorum, Safety-Veto und Tie-Breaker-Regel; stellen Sie die Frage „Welche Aktion kann der Agent nicht ausführen, selbst wenn das die MTTR senkt?". *Erwartung: Die Antwort steht in den 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 Übungsszenario des Kapitels); falls Sie eine proposal.md ausgeführt haben, fügen Sie in capstone/README.md eine Zeile mit dem Grund für die Regel hinzu. Erwartung: Eine Änderung ohne Herkunft gelangt nicht in das SDD-Paket.

Kontrollfragen

1. Welche Projektregeln sollten unveränderlich sein und welche nicht?
2. Warum benötigt eine veränderliche Regel eine ttl, und was passiert ohne sie nach einem Jahr?
3. Was sollte bei einem Safety-Veto geschehen, und warum lässt es sich nicht mit zwei approve umgehen?
4. Nach drei gleichen NodeNotReady innerhalb von 48 Stunden hat der Referendum-Trigger ausgelöst, aber in diesem Moment läuft ein aktiver Vorfall. Was tun Sie mit der Änderung – annehmen, zurückstellen oder den Trigger zurückrollen?