Den Plan entscheidungsreif machen
Ziel, Umfang und Annahmen gehören neben Änderungen, betroffenen Systemen, Risiken und Rollback. Bestätigte Fakten müssen klar von Agent-Urteilen getrennt sein; die gewünschte Autorität wird ausdrücklich genannt.
Eine blockierende Kandidatin veröffentlichen
Nach check, build und digest startet `ow publish ./plan/document.mdw --review --no-open --timeout 900` die Prüfung. Die Kandidatenrevision ist damit der konkrete Gegenstand der Entscheidung.
ow a2ui draft check ./plan
ow a2ui draft build ./plan
ow a2ui digest ./plan/document.mdw
ow publish ./plan/document.mdw --review --no-open --timeout 900Das Ergebnis in Agent-Verhalten übersetzen
Approved erlaubt ausschließlich den geprüften Umfang. Bei Änderungswunsch wird die Quelle überarbeitet und neu eingereicht; Ablehnung, Timeout und Fehler stoppen die Ausführung und halten den Entscheidungsstand fest.
Spätere Änderungen weiter regieren
Bei materiellen Änderungen wird über dieselbe Dokumentidentität mit `--update ... --review` eine neue Kandidatin angehängt. Eine frühere Freigabe autorisiert keinen anderen Plan.
ow publish ./plan/document.mdw --update <document_id> --review --no-openFAQ
Häufige Fragen
Darf der Agent nach einer Änderungsanforderung weiterarbeiten?
Er darf den Plan überarbeiten und neu einreichen, aber weder die abgelehnte noch die mit Änderungen versehene Kandidatin ausführen.
Autorisiert eine Freigabe spätere wesentliche Änderungen?
Nein. Eine materiell andere Kandidatin braucht eine neue, genau an diese Revision gebundene Entscheidung.
Echten Workflow nutzen
Veröffentliche, was dein Agent erschafft.
Gib jedem Bericht, Dokument oder Plan eine lesefertige Seite, über die Kommentare, Entscheidungen und formale Revisionen zurückfließen.