Skip to content
← Alle Kapitel

Kapitel 02

Die Kernschleife

DWP definiert eine kleine Menge von Operationen, die einen Plan von einem Ziel zu abgeschlossener, prüfbarer Arbeit bewegen: create → execute → refine → resume → status, mit verify als Konformitätsprüfung, die das Ergebnis bestätigt. Gemeinsam bilden sie die Schleife, der ein Agent über die gesamte Lebensdauer eines Plans folgt. Agenten führen eine Aufgabe nach der anderen aus und validieren jeden Schritt, bevor sie weitergehen.

Diese Schleife ist die operative Form von spec-driven Development. Der Plan ist die Spezifikation, gegen die ein Agent ausführt, jede Aufgabe trägt explizite Akzeptanzkriterien, und der Validierungsschritt ist das Gate, das eine Behauptung des Abschlusses in einen Beleg dafür verwandelt. Weil der Plan und sein Fortschrittsprotokoll im Repository leben, ist die Schleife über Sitzungen und Agenten hinweg wiederaufnehmbar.

Die Operationen

Der Methodik-Skill delegiert die Entwicklerabsicht an neun spezialisierte Sub-Skills: sechs Kernausführungs-Operationen, zwei Lebenszyklus-Helfer und eine Authoring-Engine:

  • create — Einen neuen Plan aus einem Ziel erzeugen. Der Agent analysiert das Ziel, zerlegt es in aufeinanderfolgende Aufgaben und schreibt die Plandateien. Im geführten Modus materialisiert der Agent direkt einen Lite-Plan — einen kompakten, bereits ausführbaren Vorschlag —, den man behalten, zu einem Full-Plan befördern, bearbeiten oder abbrechen kann; im Trust-Modus materialisiert der Agent die gewählte Darstellung (Lite oder Full) direkt ohne Review-Schritt. Anforderungsanalyse und Plan-Qualitätsprüfung laufen in beiden Modi.
  • execute — Den Plan Aufgabe für Aufgabe sequenziell ausführen. Der Agent aktualisiert nach jeder Aufgabe das Fortschrittsprotokoll, führt Validierungs-Gates aus und committet. Im Trust-Modus läuft die Ausführung unbeaufsichtigt ohne Nachfragen zwischen Aufgaben weiter.
  • refine — Einen bestehenden Plan anpassen (Aufgaben hinzufügen, bearbeiten, teilen oder umordnen oder einen Lite-Plan zu Full befördern). Abgeschlossene Nachweise bleiben strikt erhalten und unbestätigte Kriterienaufweichungen sind verboten.
  • resume — Einen unterbrochenen Plan fortsetzen. Der Agent liest das Append-Only-Journal und die Aufgabendateien, rekonstruiert den Zustand und setzt ab der ersten unvollständigen Aufgabe fort, ohne fertige Arbeit zu wiederholen.
  • status — Den Fortschritt berichten, ohne auszuführen (strikt schreibgeschützt). Der Agent fasst erledigte, laufende und offene Aufgaben zusammen und ändert nichts.
  • verify — Konformität prüfen, ohne etwas zu ändern (strikt schreibgeschützt). Der Agent berichtet, ob das Repository den AI-first-Standard erfüllt und ob Planaufgaben explizite Kriterien und Validierungs-Gates tragen.
  • onboard — Das Ziel-Repository analysieren und durch Reasoning — niemals per Copy-Paste — ein angepasstes AGENTS.md, eine docs/-Hierarchie, Moduldokumentation und das .agents/-Kit mit Symlinks aufbauen.
  • upgrade — Upstream-Releases prüfen, Entwicklerzustimmung vor dem Download einholen, gepinnte stabile Tags installieren und lokale Anpassungen abgleichen, ohne bestehende .dwp/-Pläne zu verändern.
  • author — Repository-lokale Skills, Agenten oder Slash-Befehle für reale wiederkehrende Workflows erstellen und weiterentwickeln sowie den .agents/docs/-Katalog synchron halten.

Das .dwp/-Ausgabeverzeichnis

Alle DWP-Artefakte liegen unter einem per gitignore ausgeschlossenen .dwp/-Verzeichnis im Repository-Stammverzeichnis. Den Arbeitsbereich aus der Versionskontrolle herauszuhalten bedeutet, dass der Arbeitszustand eines Plans niemals den Projektverlauf verunreinigt. Addon-Konfigurationen auf Repository-Ebene werden in .dwp/config.json (dwp-config/v1) festgehalten, während Pläne in flachen nummerierten Verzeichnissen liegen:

.dwp/
├── config.json
└── plans/
    └── PLAN_001_<slug>/
        ├── manifest.json
        ├── contract.json
        ├── journal.ndjson
        ├── state.json
        ├── README.md
        ├── PROGRESS.md
        ├── 1.task_<slug>.md
        ├── 2.task_<slug>.md
        └── analysis_results/

Die zehnteilige Aufgaben-Anatomie

Jede Aufgabendatei folgt den oben dargestellten zehn normativen Abschnitten in der vom installierten Skill definierten Reihenfolge.

  1. Goal — ein Absatz, der festhält, was die Aufgabe erreicht.
  2. Context — Hintergrund, Links und warum diese Aufgabe existiert.
  3. Touched Surface — was die Aufgabe ändert und die Risikoklasse, die ihre Validierung wählt.
  4. Steps — geordnete, konkrete auszuführende Handlungen.
  5. Acceptance criteria — eine Checkliste von Bedingungen, die „erledigt“ definieren.
  6. Validation — Befehle oder Tests, die auszuführen sind, um die Arbeit zu verifizieren.
  7. Files — Pfade, die voraussichtlich erstellt oder geändert werden.
  8. Dependencies — andere Aufgaben oder externe Voraussetzungen.
  9. Risks — was schiefgehen könnte und Gegenmaßnahmen.
  10. Completion & Log — eine Statusmarkierung plus chronologische Notizen.

Validierung, Abschluss und Wiederaufnahme

Validierung ist Teil der Aufgabe, kein nachträglicher Gedanke: Jede Aufgabe benennt die Befehle oder Tests, die belegen, dass sie erledigt ist, und der Agent führt sie aus, bevor er den Abschluss markiert. Tests sind hier erstklassig — eine Aufgabe, die neue Funktionalität hinzufügt oder Verhalten ändert, muss automatisierte Tests für dieses Verhalten hinzufügen oder aktualisieren und die vollständige Code-Qualitätsprüfung des Repositorys ausführen (Tests plus Lint und Typprüfung), nicht nur bestätigen, dass der Build gelingt; bestehende Tests müssen grün bleiben, an das beabsichtigte Verhalten angepasst statt übersprungen. Sicherheit ist auf dieselbe Weise erstklassig — jede Aufgabe, die Authentifizierung, Eingabeverarbeitung, Secrets, Netzwerk-Oberfläche oder Abhängigkeiten berührt, trägt die Sicherheitserwartungen dieser Änderung in ihren Akzeptanzkriterien und hält jeden Commit frei von Secrets, und jeder Plan schließt mit dem Final Review — dem Sicherheitstest über den gesamten Änderungssatz, der vollständigen Validierung auf dem Endzustand und dem Abgleich der Skills-Entscheidungen. Der Abschluss wird mit einer expliziten Statusmarkierung ([ ] nicht begonnen, [~] in Arbeit, [x] erledigt, [!] blockiert) im Abschnitt Completion & Log festgehalten. Die Wiederaufnahme stützt sich auf diese Markierungen und das Fortschrittsprotokoll — ein Agent kann genau rekonstruieren, wo der Plan stehengeblieben ist, und ab der ersten unvollständigen Aufgabe fortsetzen, ohne fertige Arbeit erneut zu erledigen.

v6 und v7: dieselbe Methodik, strengere Struktur

Der aktuelle DWP-Standard ist 7.0.0, umgesetzt durch die 7.x-Skill-Linie. Dieses Paket verwendet standardmäßig v7 für jeden neuen Plan; eine ausdrückliche v6-Anforderung materialisiert weiterhin einen v6-Plan. Bestehende v1-, v2-, v5- und v6-Pläne behalten ihre aufgezeichnete Generation und werden nie stillschweigend migriert; die Überführung eines v5-Plans zu v6 erfordert einen ausdrücklichen Migrationsauftrag.

v6 behält dieselbe Methodik aus Plan → Aufgaben → Validierungsschranken → Abschluss, dieselben Slash-Befehle und den Speicherort .dwp/plans/ bei. Die technische Struktur wird durch Vertrag, Journal, Kontextmanifeste pro Aufgabe, Scheduler und die Ablehnung einer leeren Allowlist strenger. v7 behält diese Aufzeichnungsschicht bei und ergänzt eine optionale Task-Markierung parallel_safe, ein Journal-Ereignis delegation für begrenzte, an einen anderen Agenten übergebene Arbeit sowie die Addon-Registry .dwp/config.json; ohne aktiviertes Delegations-Addon läuft jeder Plan weiterhin sequenziell in der aktuellen Sitzung. Die Architekturentscheidung lautet GO; eine empirische Nichtunterlegenheit der Agentenergebnisse wurde nicht gemessen.