Skip to content
← Wszystkie rozdziały

Rozdział 02

Podstawowa pętla

DWP definiuje zestaw operacji prowadzących plan od celu do ukończenia: create → execute → refine → resume → status → verify, wspieranych przez pomocników cyklu życia onboard i upgrade oraz pod-skill author (łącznie dziewięć pod-skilli). Razem tworzą pętlę, którą agent podąża przez całe życie planu. Agenci wykonują jedno zadanie naraz, walidując każdy krok przed przejściem dalej.

Ta pętla jest operacyjną formą spec-driven development. Plan jest specyfikacją, w odniesieniu do której agent pracuje, każde zadanie niesie jawne kryteria akceptacji, a krok walidacji jest bramką, która zamienia deklarację ukończenia w jego dowód. Ponieważ plan i jego dziennik postępu żyją w repozytorium, pętla jest wznawialna między sesjami i agentami.

Operacje

  • create — Wygeneruj nowy plan na podstawie celu. Agent analizuje cel, rozkłada go na sekwencyjne zadania i zapisuje pliki planu. Gdy cel jest niejednoznaczny, powinien zadać pytania doprecyzowujące przed zapisem. W trybie guided agent od razu materializuje plan Lite — kompaktową, już wykonywalną propozycję — a deweloper decyduje, czy go zachować, podnieść do planu Full z plikami zadań, edytować, czy zatrzymać się; w trybie trust agent od razu materializuje wybraną reprezentację (Lite lub Full) bez etapu przeglądu. Zobacz specyfikację dla obu reprezentacji. Analiza wymagań i kontrola jakości planu działają w każdym przypadku.
  • execute — Realizuj plan zadanie po zadaniu. Agent aktualizuje dziennik postępu po każdym zadaniu i oznacza jego status ukończenia. Nie wolno mu pomijać zadań bez zapisania powodu.
  • refine — Zmodyfikuj istniejący plan. Agent może dodawać, usuwać lub zmieniać kolejność zadań, ale musi zachować ukończoną pracę i zaktualizować tabelę zadań.
  • resume — Kontynuuj przerwany plan. Agent czyta dziennik postępu i pliki zadań, by zrekonstruować stan, a następnie kontynuuje od pierwszego nieukończonego zadania.
  • status — Raportuj postęp bez realizacji. Agent podsumowuje zadania ukończone, w toku i oczekujące i niczego nie zmienia.
  • verify — Sprawdź zgodność bez wprowadzania zmian. Agent raportuje, czy repozytorium spełnia standard i czy plan jest poprawnie sformułowany — czy każde zadanie niesie kryteria akceptacji i bramkę walidacyjną. Zobacz dokument o zgodności w specyfikacji.
  • onboard — Wprowadź agenta do repozytorium na podstawie rozumowania, tworząc AGENTS.md, przewodniki w docs/ i strukturę .agents/.
  • upgrade — Zaktualizuj harness repozytorium lub istniejące plany do nowszych wersji standardu DWP.
  • author — Twórz nowe skille, agentów lub polecenia dopasowane do konwencji repozytorium, utrzymując katalog dokumentacji w synchronizacji.

Katalog wynikowy .dwp/

Wszystkie artefakty DWP żyją w ignorowanym przez git katalogu .dwp/ w głównym katalogu repozytorium. Trzymanie przestrzeni roboczej poza kontrolą wersji oznacza, że stan roboczy planu nigdy nie zaśmieca historii projektu.

.dwp/
├── plans/
│   └── PLAN_001_<slug>/
│       ├── manifest.json
│       ├── contract.json
│       ├── journal.ndjson
│       ├── state.json
│       ├── README.md
│       ├── PROGRESS.md
│       ├── 1.task_<slug>.md
│       ├── 2.task_<slug>.md
│       └── analysis_results/
└── config.json

Dziesięciosekcyjna anatomia zadania

Dziesięć sekcji powyższego diagramu definiuje anatomiczną strukturę każdego pliku zadania w planie Full. Ta kolejność zapewnia, że każda jednostka pracy jest w pełni samowystarczalna, jednoznaczna i podatna na niezależny audyt:

  1. Cel — jeden akapit określający, co zadanie osiąga.
  2. Kontekst — tło, odnośniki i powód istnienia tego zadania.
  3. Powierzchnia dotknięta — co zadanie zmienia i klasa ryzyka, która wybiera jej walidację.
  4. Kroki — uporządkowane, konkretne działania do wykonania.
  5. Kryteria akceptacji — lista warunków definiujących ukończenie.
  6. Walidacja — polecenia lub testy do uruchomienia, by zweryfikować pracę.
  7. Pliki — ścieżki, które mają zostać utworzone lub zmodyfikowane.
  8. Zależności — inne zadania lub zewnętrzne wymagania wstępne.
  9. Ryzyka — co może pójść nie tak oraz środki zaradcze.
  10. Ukończenie i dziennik — znacznik statusu plus chronologiczne notatki.

Walidacja, ukończenie i wznowienie

Walidacja jest częścią zadania, a nie czymś doraźnym: każde zadanie wskazuje polecenia lub testy dowodzące jego ukończenia, a agent uruchamia je przed oznaczeniem ukończenia. Testy są tu pełnoprawne — zadanie, które dodaje nową funkcjonalność lub zmienia zachowanie, musi dodać lub zaktualizować automatyczne testy tego zachowania i uruchomić pełną kontrolę jakości kodu repozytorium (testy plus lint i sprawdzanie typów), a nie tylko potwierdzić, że budowanie się powiodło; istniejące testy muszą pozostać zielone, zaktualizowane do zamierzonego zachowania, a nie pominięte. Bezpieczeństwo jest pełnoprawne tak samo — każde zadanie, które dotyka uwierzytelniania, obsługi wejścia, sekretów, powierzchni sieci lub zależności, niesie oczekiwania bezpieczeństwa tej zmiany w swoich kryteriach akceptacji i utrzymuje każdy commit wolnym od sekretów, a każdy plan kończy się Final Review — przeglądem bezpieczeństwa całego zestawu zmian, pełną walidacją stanu końcowego i uzgodnieniem decyzji dotyczących skills. Ukończenie zapisywane jest jawnym znacznikiem statusu ([ ] nierozpoczęte, [~] w toku, [x] ukończone, [!] zablokowane) w sekcji Ukończenie i dziennik. Wznowienie opiera się na tych znacznikach i dzienniku postępu — agent może odtworzyć dokładnie miejsce, w którym plan się zatrzymał, i kontynuować od pierwszego nieukończonego zadania, bez powtarzania zakończonej pracy.

v6 i v7: ta sama metodyka, ściślejsza struktura

Aktualny standard DWP to 7.0.0, wdrażany przez linię skilla 7.x. Ten pakiet domyślnie tworzy każdy nowy plan w v7; jawne żądanie v6 nadal materializuje plan v6. Istniejące plany v1, v2, v5 i v6 zachowują zapisaną generację i nigdy nie są po cichu migrowane; przeniesienie planu v5 do v6 wymaga wyraźnego polecenia migracji.

v6 zachowuje tę samą metodykę plan → zadania → bramki walidacji → ukończenie, polecenia slash i lokalizację .dwp/plans/. Zaostrza strukturę inżynieryjną przez kontrakt, dziennik, manifesty kontekstu zadań, harmonogram i odrzucanie pustej listy dozwolonych możliwości. v7 zachowuje tę warstwę zapisów i dodaje opcjonalny znacznik zadania parallel_safe, zdarzenie dziennika delegation dla ograniczonej pracy przekazanej innemu agentowi oraz rejestr addonów .dwp/config.json; bez włączonego addonu delegowania każdy plan nadal wykonuje się sekwencyjnie w bieżącej sesji. Decyzja architektoniczna to GO; empirycznej niegorszości wyników agentów nie zmierzono.