dwp-create

Einen neuen Deep Work Plan aus einem übergeordneten Ziel erstellen.

/dwp-create

1. Ziel + Kontext →
2. Zerlegen → Plan materialisieren →
3. Plan auf der Festplatte

Was es tut

dwp-create nimmt ein übergeordnetes Ziel und verwandelt es in einen strukturierten, ausführbaren Deep Work Plan. Es analysiert die Anforderungen, stellt bei Mehrdeutigkeit klärende Fragen und materialisiert einen Lite- oder Full-Plan direkt unter .dwp/plans/PLAN_<id>_<slug>/.

Verwendung

/dwp-create <goal>
/dwp-create trust lite <goal>
/dwp-create <goal> full trust

Modi und Grenzoptionen

Grenzoptionen steuern das Prüfverhalten und das Planformat. Sie können als Tokens am Anfang oder am Ende des Befehls stehen, in beliebiger Reihenfolge:

• Prüfmodi:
  • Geführt (Standard): materialisiert einen ausführbaren Lite-Planvorschlag, zeigt die beobachteten Signale und die Begründung des Formats und fragt, ob Lite beibehalten, zu Full befördert, bearbeitet oder abgebrochen werden soll.
  • Trust (trust oder auto): überspringt die Prüfung und geht direkt zu einem vorab genehmigten, startbereiten Plan über.
• Formatpräferenzen:
  • lite: drückt eine Präferenz für einen kompakten Einzeldateiplan in README.md mit verankerten Aufgabeneinträgen (#task-N) aus.
  • full: drückt eine Präferenz für zerlegte, nummerierte Aufgabendateien (N.task_<slug>.md) aus.
  • Die gleichzeitige Angabe von lite und full ist ein ausdrücklicher Konflikt.
• Terminator: -- beendet die Optionsauswertung; alles nach -- wird als wörtlicher Zielkontext interpretiert.

Verhalten

1. Anforderungsanalyse: untersucht den Repository-Kontext, die Architektur und die dokumentierten Testbefehle.
2. Klärung: stellt klärende Fragen, wenn Umfang oder Anforderungen mehrdeutig sind.
3. Monotone Zuweisung: weist unter .dwp/plans/ einen nullaufgefüllten Ordnernamen PLAN_<id>_<slug>/ zu und nutzt dabei .next-plan-id unter einer POSIX-Dateisperre (fcntl). Numerische IDs sind monoton und werden nie wiederverwendet.
4. Vertragsmaterialisierung: führt ledger.py materialize aus, um manifest.json zu schreiben, die inhaltsadressierte contract.json zu stempeln (v7-Generation mit parallel_safe-Aufgabenmarkierungen) und das initiale approval-Ereignis aufzuzeichnen.
5. Final Review: Pläne enden mit einer verpflichtenden fünfteiligen Final-Review-Aufgabe (Sicherheitsdurchlauf mit verpflichtendem lokalem Review, Validierung des Endzustands, Abgleich der Skills, Abgleich der Dokumentation, Abschluss).

Aliase

• dwp:create