Die Spezifikation entscheidungsreif machen
- Problem, Nutzende und Nicht-Ziele
- Belege zum Ist-Zustand
- vorgeschlagenes Verhalten und öffentliche Verträge
- Daten, Berechtigungen und Fehlersemantik
- Risiken, Migration, Rollback und offene Fragen
- konkret erbetene Freigabe
Fakten, Vorschläge und Roadmap sichtbar trennen
Es muss auf einen Blick klar sein, welches Verhalten heute existiert, was diese Spezifikation ändern will und was nur eine spätere Möglichkeit ist. Souveräner Ton ersetzt keinen Status.
Eine Kandidatin zur Prüfung veröffentlichen
Das Spec-Archiv lokal validieren und mit --review veröffentlichen. Änderungswünsche werden am Quell-Draft eingearbeitet und als neue Kandidatin vorgelegt.
ow a2ui draft check ./spec
ow a2ui draft build ./spec
ow a2ui digest ./spec/document.mdw
ow publish ./spec/document.mdw --review --no-open --timeout 900Die Umsetzung an die Freigabe binden
In Implementierungsnotizen, Release-Evidenz und Audit-Unterlagen den festen Link der freigegebenen Version verwenden. Bei wesentlicher Umfangsänderung braucht es eine neue Kandidatin.
FAQ
Häufige Fragen
Soll die Umsetzung auf die kanonische Spezifikation oder eine feste Version verlinken?
Für den Umsetzungsvertrag auf die unveränderliche freigegebene Version; die kanonische URL zeigt den aktuellen formalen Stand.
Kann ein Agent seine eigene Spezifikation freigeben?
Nein. Die Review-Schleife verlangt eine ausdrückliche menschliche Entscheidung; fehlende Freigabe blockiert den Agent.
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.