Archetipi

Versione 1.1. DWP riconosce tre archetipi. L’archetipo determina come un agente fa l’onboarding, come vengono definiti gli ambiti dei piani e se il livello di stato leggibile dalle macchine è richiesto.

Additivo in v1.1. Il workspace agente (§3) si aggiunge come terzo archetipo: la casa di lunga durata di un agente autonomo. Git diventa RACCOMANDATO anziché presupposto. I due archetipi v1.0 sono invariati.

Repository individuale

Un codebase autosufficiente — un’applicazione, una libreria o un servizio. I piani operano direttamente sul codice.

Caratteristiche:

• Singolo codebase coerente.
• I piani modificano file in questo repository.
• Workspace .dwp/ nella radice del repository.

Hub orchestratore

Un repository di coordinamento che gestisce più repository figli. I piani possono generare piani figli nei sotto-repository.

Caratteristiche:

• Coordina più sotto-repository.
• I piani possono delegare a piani figli.
• Mantiene un registro dei repository gestiti.
• Il workspace .dwp/ nella radice dell’hub traccia lo stato tra i repository.

Workspace agente

Un workspace agente è la casa di lavoro di lunga durata di un agente autonomo — un workspace OpenClaw, una directory di servizio Hermes, la directory dei dati di un daemon di assistente personale, o un volume persistente di un agente cloud. È un workspace, non necessariamente un repository git, e il suo prodotto principale è il lavoro in corso dell’agente piuttosto che un singolo codebase.

L’intuizione che rende possibile questo archetipo: la harness è un workspace, non specificamente un repository. Ogni elemento della harness che la metodologia definisce per un repository ha un equivalente diretto nel workspace:

Un workspace agente DEVE fornire AGENTS.md, .agents/ e .dwp/ nella radice del workspace.

Git è RACCOMANDATO, non OBBLIGATORIO. Dove git è assente, ogni piano DEVE portare il livello di stato leggibile dalle macchine: il checkpoint di state.json, i gate record e i timestamp per attività portano le informazioni di recupero che il git log porta in un repository.

I piani in un workspace agente vengono tipicamente eseguiti in modo non presidiato: un heartbeat o un turno cron pianificato riprende il piano aperto tramite il Protocollo di Ripresa DWP, esegue la prossima attività atomica, aggiorna il livello di stato e cede il controllo. Il piano — non la sessione — è l’unità di continuità.

Euristica di classificazione

Repository

? Più repository annidati o un registro di hub?

No

Repository individuale

• codice base unico
• i piani modificano file locali
• .dwp/ nella radice del repository

Sì

Hub orchestratore

• coordina i sotto-repository
• i piani delegano a piani figli
• stato .dwp/ condiviso tra repository

Classificare come workspace agente per primo, quando il target è la directory di lavoro di una piattaforma di agenti autonomi — segnali: un file di identità della piattaforma (come SOUL.md o HEARTBEAT.md di OpenClaw), nessuno stack applicativo principale e contenuto che è prevalentemente lo stato proprio dell’agente. Un singolo segnale forte della piattaforma è sufficiente.

In caso contrario, classificare come hub orchestratore quando la chiara maggioranza dei seguenti segnali è presente: più repository git annidati o submodule; un registro o manifest di repository gestiti; configurazione che punta a repository esterni. Classificare come repository individuale negli altri casi — è il comportamento sicuro predefinito.

Quando i segnali sono ambigui, l’agente DEVE presentare la propria valutazione e le prove all’utente e chiedere conferma prima di procedere.

Differenze nell’onboarding