Konformität

Version 1.3. Status: Stabil. Dieses Dokument definiert, was es bedeutet, dass ein Repository Deep Work Plan-konform ist — also AI-first und agenten-steuerbar. Die Schlüsselwörter MUSS, DARF NICHT, SOLLTE, SOLLTE NICHT und KANN sind so zu interpretieren, wie in RFC 2119 beschrieben.

Konformität existiert, damit „AI-first“ eine objektive, prüfbare Eigenschaft ist und kein Eindruck. Ein Repository erfüllt die untenstehenden Kriterien entweder oder nicht. Die verify-Sub-Skill (/dwp-verify) prüft sie mechanisch.

Ein konformes Repository

Ein DWP-konformes Repository MUSS alles Folgende erfüllen. Jedes Artefakt MUSS für das Repository durchdacht sein — angepasst an seine echten Sprachen, Frameworks und Befehle. Ein generischer Platzhalter, ein Platzhaltertext oder aus einem anderen Repository kopierter Inhalt erfüllt kein Kriterium.

1. AGENTS.md im Stammverzeichnis. Das Repository MUSS eine Wurzel-AGENTS.md enthalten, die (a) einen Index der Dokumentation, (b) die verpflichtenden Regeln für das Repository und (c) einen Quick-Commands-Block enthält, dessen Befehle in diesem Repository echt und ausführbar sind. Platzhalter-Befehle (zum Beispiel npm test in einem Repository, das kein npm nutzt) DÜRFEN NICHT erscheinen. Der Index DARF NICHT auf eine docs/-Datei verlinken, die nicht existiert, und die Datei SOLLTE innerhalb eines Budgets von 150–500 Zeilen bleiben, indem Detail in docs/ verschoben und von dort verlinkt wird, statt unbegrenzt zu wachsen.
2. CLAUDE.md löst sich zu AGENTS.md auf. Eine CLAUDE.md MUSS existieren und sich zu AGENTS.md auflösen (ein Symlink oder ein Äquivalent, das eine einzige Quelle der Wahrheit garantiert). Die beiden DÜRFEN NICHT auseinandergehen.
3. Eine docs/-Hierarchie. Das Repository MUSS ein docs/-Verzeichnis enthalten, das die Standardkategorien (Architektur, Standards, Testing, Entwicklungsbefehle, Sicherheit und Agenten-Onboarding) mit echtem, repository-spezifischem Inhalt abdeckt. Komplexe Module SOLLTEN ihre eigene README.md tragen. Der Testing-Leitfaden MUSS eine echte Test-, Lint- und Typprüfungs-Toolchain definieren — oder, für ein Repository, das keine hat, ein konkretes Setup, das während des Onboardings aus dem Stack vorgeschlagen wird. Ein leerer Testing-Leitfaden oder „keine Tests“ erfüllt dieses Kriterium nicht: Ohne einen definierten Weg, Verhalten zu validieren, hat ein Plan kein objektives Validierungs-Gate.
4. Ein .agents/-Verzeichnis. Das Repository MUSS ein .agents/-Verzeichnis mit agents/, commands/ und skills/ enthalten, plus einen Katalog unter .agents/docs/, der dem entspricht, was auf der Festplatte liegt. Die dwp-*-Befehle MÜSSEN schlanke Delegatoren an die installierte Skill sein. Ein .claude-Pfad MUSS sich zu .agents auflösen.
5. Ein per gitignore ausgeschlossener .dwp/-Arbeitsbereich. Das Repository MUSS ein .dwp/-Verzeichnis mit plans/ enthalten, und .dwp/ MUSS per gitignore ausgeschlossen sein. Ein tmp/-Scratch-Bereich SOLLTE existieren und SOLLTE per gitignore ausgeschlossen sein.
6. Die Methodik-Skill ist auflösbar. Die Deep Work Plan Skill MUSS so installiert oder referenziert sein, dass ein Agent im Repository ihre Sub-Skills aufrufen kann.

Ein Repository ist mit null optionalen Addons vollständig konform. Die optionalen Addons (devcontainer, Dailybot, dependency-upgrade, design-system) DÜRFEN NICHT für die Konformität erforderlich sein. Seit Standard 2.3.0 ist die lokale Überprüfung des AI Diff Reviewer (vendorte Skill + Erweiterungsdatei) Teil der Baseline: Ihr Fehlen ist ein Fehler für ein Repository, das 2.3.0 oder neuer deklariert, und ein Harness-Versions-Befund für ein Legacy-Repository. Ihre CI-Oberfläche bleibt optional.

Ein wohlgeformter Plan

Ein Deep Work Plan in .dwp/plans/ ist wohlgeformt, wenn:

1. Jede Aufgabe MUSS einen expliziten Umfang, Akzeptanzkriterien und mindestens ein Validierungs-Gate deklarieren (einen Befehl oder eine Prüfung, die objektiv besteht oder durchfällt).
2. Jede Aufgabe, die neue Kernfunktionalität hinzufügt oder Produktverhalten ändert, MUSS automatisierte Testabdeckung für dieses Verhalten in ihren Akzeptanzkriterien umfassen und MUSS die Tests des Repositorys zusammen mit seinen Lint- und Typprüfungen in ihrem Validierungs-Gate ausführen — nicht den Build allein. Bestehende Tests MÜSSEN grün bleiben; eine Verhaltensänderung MUSS einen Test, den sie bricht, anpassen, statt ihn zu löschen oder zu überspringen. Reine Dokumentations-, Konfigurations- oder Recherche-Aufgaben sind von der Erstellung von Tests befreit, führen aber dennoch das Gate des Repositorys aus.
3. Jede Aufgabe, die Authentifizierung, Eingabeverarbeitung, Geheimnisse oder Konfiguration, Netzwerkoberfläche oder Abhängigkeiten berührt, MUSS die Sicherheitserwartungen dieser Änderung in ihren Akzeptanzkriterien tragen, und jeder Commit MUSS frei von Geheimnismaterial sein.
4. Der Plan MUSS den Fortschritt persistieren, sodass die Arbeit eine Unterbrechung übersteht und von einem anderen Agenten wiederaufgenommen werden kann. Eine Aufgabe DARF NICHT als completed erfasst werden, solange irgendeiner ihrer Validierungs-Gate-Datensätze noch einen fehlschlagenden, ungelösten Lauf zeigt, und das eigene Abschlussprotokoll einer Aufgabe DARF NICHT ihrem erfassten Status widersprechen (zum Beispiel ist eine completed-Aufgabe, deren Protokoll noch „Status: pending“ liest, ein Mangel, kein Bestehen).
5. Der Plan MUSS mit seiner aufgezeichneten Abschlussprüfung schließen. Ein Plan, der unter dieser Version verfasst wurde, MUSS mit genau einem verpflichtenden Final Review enden — dem Sicherheitstest, der Validierung des Endzustands und dem Abgleich der Skills-Entscheidungen. Ein Plan, der unter einer früheren Version verfasst wurde, endet mit den drei verpflichtenden Abschlussaufgaben (Security Review, Skills & Agents Discovery, Executive Report) und bleibt konform. Ein kritischer Sicherheitsbefund blockiert den Abschluss, bis er behoben oder ausdrücklich akzeptiert wurde. Der Abschluss selbst ist eine verifizierte, wiederherstellbare Transaktion und kein bloßer Statuswechsel: Die letzte Aufgabe schließt über einen abgesicherten Veröffentlichungsschritt ab, der die Artefakte des fertigen Plans validiert, bevor er den Zustand schreibt, und einen maschinell prüfbaren FINALIZATION.json-Beleg hinterlässt; eine unterbrochene Veröffentlichung wird aus Nachweisen wiederhergestellt, niemals stillschweigend erneut für abgeschlossen erklärt. Jeder Nachweiszeiger, den ein Gate-Datensatz zitiert, MUSS innerhalb des eigenen Ordners des Plans auflösen — ein hängender oder entweichender Zeiger ist ein Befund, kein bestehender Nachweis.
6. Aufgaben SOLLTEN sich vor der Ausführung erneut am Ziel des Plans verankern, um ein Abdriften über einen langen Horizont zu verhindern.

Konformität verifizieren

Konformität SOLLTE mechanisch verifiziert werden statt durch Inspektion. Das Ausführen von /dwp-verify erzeugt einen Bestanden/Nicht-bestanden-Bericht anhand der obigen Kriterien: das Vorhandensein und der echte Inhalt von AGENTS.md, die CLAUDE.md-Auflösung, die docs/-Kategorien, der .agents/-Abgleich Katalog gegen Festplatte, der gitignore-Status von .dwp/ und tmp/ und — für einen Plan —, dass jede Aufgabe Akzeptanzkriterien und ein Validierungs-Gate trägt, mit Testabdeckung für verhaltensändernde Aufgaben und dem Vorhandensein der aufgezeichneten Abschlussprüfung. Für einen Plan prüft er außerdem, dass das Markdown des Plans und sein maschinenlesbarer Zustand übereinstimmen (ein desynchronisiertes README und state.json ist ein Befund, niemals ein stilles Bestehen), dass abgeschlossene Aufgaben widerspruchsfreien Gate- und Protokollnachweis tragen, und — wo ein abgeschlossener Plan es erreicht — dass ein Veröffentlichungsbeleg den behaupteten Abschluss stützt. Der Prüfer ist versionsbewusst: Er MUSS einen Legacy-Plan (drei verpflichtende Abschlussaufgaben, keine Touched Surface) als konform akzeptieren und MUSS einen Plan zurückweisen, der diese Version deklariert und objektiv unter ihr ungültig ist. Er meldet außerdem eine fehlende oder veraltete DWP standard:-Provenienzzeile als Befund, der das zielgerichtete Harness-Upgrade benennt. Die mechanische Schicht ist ehrlich zu ihren Grenzen: ohne fähigen Interpreter (Python 3.9+) endet sie mit einem von null verschiedenen Exit-Code und einem expliziten UNVERIFIED-Verdiktor, statt ihre Prüfungen zu überspringen — ein Prüfer berichtet nie ein Ergebnis, das er nicht geprüft hat.

Ein Repository SOLLTE nach dem Onboarding und nach jedem abgeschlossenen Plan erneut verifiziert werden, sodass die Konformität aufrechterhalten und nicht nur einmal behauptet wird.