Archetypen

Versionsumfang: Dies ist ein beibehaltenes v5.0.0-Basisdokument. Der aktuelle Standard, DWP 7.0.0, verlangt zusätzlich die zutreffenden V6_*.md- und V7_*.md-Erweiterungen aus dem Spezifikationsindex. Bestehende v5- und v6-Pläne behalten ihre aufgezeichneten Regeln.

Version 1.1. DWP erkennt drei Archetypen. Der Archetyp bestimmt, wie ein Agent onboardet, wie Pläne zugeschnitten werden und ob die maschinenlesbare Zustandsschicht erforderlich ist.

Additiv in v1.1. Der Agenten-Arbeitsbereich (§3) wird als dritter Archetyp aufgenommen: das langlebige Zuhause eines autonomen Agenten. Git wird EMPFOHLEN statt vorausgesetzt. Die beiden v1.0-Archetypen sind unverändert.

Einzel-Repository

Eine in sich geschlossene Codebasis — eine Anwendung, eine Bibliothek oder ein Service. Pläne operieren direkt auf dem Code.

Merkmale:

• Eine einzige zusammenhängende Codebasis.
• Pläne ändern Dateien in diesem Repository.
• .dwp/-Arbeitsbereich im Repository-Stammverzeichnis.

Orchestrator-Hub

Ein Koordinations-Repository, das mehrere untergeordnete Repositorys verwaltet. Pläne können untergeordnete Pläne in Sub-Repositorys erzeugen.

Merkmale:

• Koordiniert mehrere Sub-Repositorys.
• Pläne können an untergeordnete Pläne delegieren.
• Pflegt ein Register der verwalteten Repositorys.
• .dwp/-Arbeitsbereich im Hub-Stammverzeichnis verfolgt repository-übergreifenden Zustand.

Agenten-Arbeitsbereich

Ein Agenten-Arbeitsbereich ist das langlebige Arbeitszuhause eines autonomen Agenten — ein OpenClaw-Arbeitsbereich, ein Hermes-Service-Verzeichnis, das Datenverzeichnis eines Personal-Assistant-Daemons oder das persistente Volume eines Cloud-Agenten. Es ist ein Arbeitsbereich, nicht notwendigerweise ein git-Repository, und sein primäres Produkt ist die laufende Arbeit des Agenten statt einer Codebasis.

Die Erkenntnis, die diesen Archetyp ermöglicht: das Harness ist ein Arbeitsbereich, nicht speziell ein Repository. Jedes Harness-Element, das die Methodik für ein Repository definiert, hat ein direktes Arbeitsbereich-Äquivalent:

Ein Agenten-Arbeitsbereich MUSS AGENTS.md, .agents/ und .dwp/ im Arbeitsbereich-Stammverzeichnis bereitstellen.

Git ist EMPFOHLEN, nicht ERFORDERLICH. Wo git fehlt, MUSS jeder Plan die maschinenlesbare Zustandsschicht tragen: state.jsons Checkpoint, Gate-Einträge und aufgabenbezogene Zeitstempel enthalten die Wiederherstellungsinformationen, die das git-Protokoll in einem Repository enthält.

Pläne in einem Agenten-Arbeitsbereich laufen typischerweise unbeaufsichtigt: Ein geplanter Heartbeat oder Cron-Turn nimmt den offenen Plan über das DWP-Wiederaufnahme-Protokoll wieder auf, führt die nächste atomare Aufgabe aus, aktualisiert die Zustandsschicht und gibt frei. Der Plan — nicht die Sitzung — ist die Einheit der Kontinuität.

Klassifizierungsheuristik

Repository

? Mehrere verschachtelte Repositories oder eine Hub-Registry?

Nein

Einzel-Repository

• einzelne Codebasis
• Pläne ändern lokale Dateien
• .dwp/ im Stammverzeichnis des Repositorys

Ja

Orchestrator-Hub

• koordiniert Unter-Repositories
• Pläne delegieren an untergeordnete Pläne
• .dwp/-Zustand über Repositories hinweg

Als Agenten-Arbeitsbereich klassifizieren zuerst, wenn das Ziel das Arbeitsverzeichnis einer autonomen Agenten-Plattform ist — Signale: eine Plattform-Identitätsdatei (wie OpenClaws SOUL.md oder HEARTBEAT.md), kein primärer Anwendungsstack und Inhalte, die überwiegend den eigenen Zustand des Agenten darstellen. Ein starkes Plattformsignal genügt.

Andernfalls als Orchestrator-Hub klassifizieren, wenn eine klare Mehrheit der folgenden Punkte zutrifft: mehrere verschachtelte git-Repositorys oder Submodule; ein Register oder Manifest verwalteter Repositorys; Konfiguration, die auf externe Repositorys verweist. Andernfalls als Einzel-Repository klassifizieren — das ist die sichere Voreinstellung.

Wenn Signale mehrdeutig sind, MUSS der Agent dem Nutzer seine Einschätzung und Belege vorlegen und um Bestätigung bitten, bevor er fortfährt.

Onboarding-Unterschiede