Skip to content
← Alle Kapitel

Kapitel 03

Plan- und Aufgabenvorlagen

Ein Deep Work Plan ist ein Verzeichnis von Markdown-Dateien. Die Form dieses Verzeichnisses — und jeder Datei darin — ist das, was einen Plan sowohl für Menschen als auch für Agenten prüfbar macht.

Planstruktur

Ein Plan ist ein Verzeichnis unter .dwp/plans/ mit dem Namen PLAN_001_<slug>/. Es enthält:

  • manifest.json — die Plan-Identität und der Zeiger auf seinen aktiven Vertrag, bei der Materialisierung zuerst geschrieben.
  • contract.json — Spezifikationsvertrag und Scope des Plans.
  • journal.ndjson — Reines Append-Only-Ereignisjournal.
  • state.json — ein aus dem Journal projizierter Snapshot, niemals manuell editiert.
  • README.md — Planübersicht: Ziel, Aufgabentabelle und Status.
  • PROGRESS.md — Menschenlesbares chronologisches Ausführungsprotokoll.
  • <n>.task_<slug>.md — Zehnteilige Spezifikationsdatei je Aufgabe.
  • analysis_results/ — Verzeichnis für Analyseartefakte, Berichte und Gate-Logs.

Das aktuelle 7.x-Paket erstellt standardmäßig v7-Pläne mit 2–5 Wörtern im Slug, wie schon bei v6. Der beibehaltene v5-Ablauf verwendet 2–4 Wörter (da dessen Schema die numerische ID als Wort zählt). Neue Pläne erhalten monoton steigende numerische IDs mit mindestens drei Ziffern (z. B. PLAN_001_add_payment_webhooks/). Bestehende unnummerierte PLAN_<slug>/-Ordner bleiben lesbar und werden niemals umbenannt; bestehende Pläne werden niemals stillschweigend migriert. Wenn nummerierte Pläne vorhanden sind, löst latest zum Plan mit der höchsten numerischen ID auf.

Struktur der Aufgabendatei

Jede Aufgabendatei trägt den Namen <n>.task_<slug>.md und folgt den zehn normativen Abschnitten des installierten Skills (Details zur Aufgabenstruktur siehe Die Kernschleife). Jede Aufgabe verankert sich vor dem Handeln erneut am Ziel des Plans, was einen Agenten daran hindert, über einen langen, mehrstündigen Horizont abzudriften.

Das Final Review

Jeder Plan muss mit genau einer verpflichtenden Aufgabe abschließen: dem Final Review. Es beendet den Plan in fünf streng geordneten Schritten — Sicherheitsprüfungen und Validierungs-Gates werden keinesfalls aufgeweicht:

  1. Sicherheitspass — alles prüfen, was der Plan geändert hat, auf Secrets, Injection-Risiken und neue Angriffsflächen untersuchen, docs/SECURITY.md aktuell halten und das erforderliche lokale AI Diff Reviewer-Review über den gesamten Bereich des Plans ausführen (ein fehlender Reviewer wird als local reviewer not installed-Befund erfasst, niemals stillschweigend übersprungen). Kritische Befunde blockieren den Abschluss.
  2. Validierung des Endzustands — Die vollständigen Test-, Lint- und Typecheck-Suiten des Repositorys laufen auf dem Endzustand und bestehen. Korrekturen während des Reviews invalidieren betroffene Ergebnisse und erzwingen einen erneuten Durchlauf.
  3. Abgleich der Skills — Verifizieren, dass jede Aufgabe ihre task-lokale Skill-Disposition erfasst hat, und umsetzbare Skill-Kandidaten in analysis_results/SKILLS_CANDIDATES.md abgleichen.
  4. Dokumentationsabgleich — Die Touched Surface jeder verhaltensändernden Aufgabe mit den Dokumenten abgleichen (docs/TESTING_GUIDE.md, Architektur, AGENTS.md), die diese Funktion festhalten.
  5. Abschluss — die Datensätze des Plans stimmen überein (Aufgabenliste, Fortschrittsprotokoll und bei v6- und v7-Plänen der aus dem Journal abgeleitete Snapshot und Beleg); Lieferbestandteile, Nachweise und Einschränkungen melden und den Executive Report einmalig anbieten.

README- und PROGRESS-Konventionen

Die Plan-README.md muss einen Titel (# Deep Work Plan: <name>), eine prosaische Zielformulierung, einen optionalen Abschnitt zum Quellmaterial, eine Aufgabentabelle (Nummer, Aufgabenname, Status-Checkbox) und eine Planstatus-Zeile in der Form <n>/<total> tasks complete enthalten.

PROGRESS.md ist ein reines Anhänge-Ausführungsprotokoll. Jeder Eintrag hält einen ISO-8601-Zeitstempel, die Aufgabennummer und den Aufgabennamen, was getan wurde sowie etwaige Abweichungen oder Übersprung-Gründe fest. Weil es nur jemals wächst, ist es eine zuverlässige Historie dessen, wie der Plan sich tatsächlich entfaltet hat.

Überschriften und Querverweise

Alle Überschriften verwenden Satzschreibweise (sentence case), und Dokumente vermeiden Marketing-Sprache und Ausrufezeichen. Diese Konventionen halten Pläne über Agenten hinweg und über die Zeit konsistent.