/10x-implement - realizacja etap po etapie

Rocinante koryguje kurs w punktach kontrolnych, zamiast lecieć do celu jednym odpaleniem.Duża zmiana rośnie od punktu kontrolnego do punktu kontrolnego, zamiast powstawać jednym diffem. /10x-implement realizuje zatwierdzony plan.md etap po etapie: każdy kończy się weryfikacją, bramą ręcznego potwierdzenia i commitem, a sekcja Progress w planie jest jedyną maszyną stanów - przerwana sesja wraca od ostatniego zielonego etapu.

/10X-IMPLEMENT // KAŻDY ETAP TO PUNKT POWROTU

PO COThe Expanse · Flip & burn

Problem: jeden wielki diff bez punktów kontrolnych

„Pół drogi ciągu, obrót, pół drogi hamowania - i korekty po drodze."

- profil lotu, który da się przerwać w każdym punkcie

Zmiana realizowana jednym ciągiem nie ma miejsc, w których można ją bezpiecznie przerwać, zweryfikować albo cofnąć. /10x-implement tnie wykonanie na etapy z planu: etap kończy się dopiero, gdy jego kryteria sukcesu są zielone, człowiek potwierdził testy ręczne, a zmiana siedzi w commicie z SHA wpisanym do Progress.

Filozofia: podążaj za intencją planu, adaptując się do zastanego kodu. Plany są projektowane starannie, ale rzeczywistość bywa nieuporządkowana - przy rozjeździe skill zatrzymuje się i przedstawia problem (oczekiwane / zastane / dlaczego to istotne), zamiast improwizować po cichu.

CEL:

przy długiej lub przerywanej pracy każdy etap to punkt powrotu: commit plus zielone kryteria zamiast jednego wielkiego diffa na koniec.

Marcin i Przemek pracują w orbitalnej stoczni, gdzie kolejne części rozwiązania powstają w osobnych zatokach — PO CO → DOWOŹ ETAPAMI
Agent realizuje zatwierdzony plan małymi etapami, a nie jedną nieprzejrzystą porcją zmian do późniejszego odgadywania.

WEJŚCIE → WYJŚCIE

Z zatwierdzonego planu do commitów per etap

Wejściem jest plan.md z folderu zmiany, opcjonalnie z numerem etapu (/10x-implement oauth-login phase 2). Skill czyta plan w całości, wszystkie pliki, do których plan się odwołuje, oraz lessons.md - zaakceptowane reguły zespołu kształtują każdą decyzję implementacyjną w tym przebiegu.

Wyjściem jest seria commitów w konwencji Conventional Commits - po jednym na etap, w formie typ(change-id): tytuł etapu (pN) - oraz odhaczona sekcja Progress, w której każdy domknięty wiersz nosi skrócony SHA zamykającego commita.

Wejście: plan.md (change-id lub ścieżka) + opcjonalny numer etapu
Wyjście: commit per etap (Conventional Commits) + Progress z SHA przy każdym wierszu
Status: change.md: implementing na wejściu, implemented po ostatnim etapie i epilogu

Marcin i Przemek realizują zatwierdzony plan etapami na kontrolowanej linii składania kodu — WEJŚCIE → WYJŚCIE
Plan trafia do realizacji etapami, a kolejny krok odblokowuje się dopiero po sprawdzeniu poprzedniego.

MECHANIZM

Rytuał końca etapu - obowiązkowa sekwencja kroków

01 · Start: pierwszy nieodhaczony wiersz Progress wyznacza miejsce startu; ukończonej pracy się ufa - weryfikacja tylko, gdy coś wygląda podejrzanie.
02 · Implementacja: etap realizowany w całości przed następnym; każdy edytowany plik trafia do zbioru plików dotkniętych - kanonicznego wejścia do stagingu, nadrzędnego wobec heurystyk z git status.
03 · Weryfikacja: komendy z kryteriów automatycznych muszą przejść; problemy naprawiane przed pójściem dalej; odhaczane wiersze Progress - po jednym na krok.
04 · Brama ręczna: skill wypisuje testy ręczne z planu i czeka na potwierdzenie człowieka; przy ostatnim etapie dokłada zbiorczą listę zaległych pozycji ręcznych z etapów wcześniejszych.
05 · Commit: staging jawnie po ścieżkach ze zbioru dotkniętych (nigdy git add -A); niezwiązane brudne ścieżki wywołują pytanie zamiast cichego dołączenia; komunikat commita zatwierdza użytkownik.
06 · SHA i dalej: skrócony SHA wraca do każdego wiersza etapu w Progress; potem decyzja: kontynuuj, wyczyść kontekst (komenda wznowienia w schowku) albo review etapu przez /10x-impl-review.
07 · Epilog: po ostatnim etapie zamykający commit epilogowy domyka SHA ostatniego etapu i status implemented - bez niego archiwizacja zatrzyma się na zmianach bez commita.

ZASADA:

przy rozjeździe z planem trzy wyjścia, decyzja człowieka: adaptuj i kontynuuj, pomiń ten fragment, albo zatrzymaj się i wróć do planowania.

Marcin i Przemek przepuszczają etap implementacji przez zieloną kontrolę i zatrzymują pracę przy czerwonym dryfie — MECHANIZM → WERYFIKACJA LUB STOP
Zielona weryfikacja zamyka etap. Dryf strukturalny oddaje decyzję człowiekowi zamiast uruchamiać zgadywanie.

ANATOMIA

Progress - maszyna stanów bez plików stanu

Sekcja Progress na dole plan.md to jedyne źródło prawdy o wykonaniu: żadnego JSON-a obok, żadnych markerów w komentarzach, żadnego pliku pomocniczego. Stan nie jest przechowywany, tylko wyprowadzany: pierwszy nieodhaczony wiersz = następny krok; etap bieżący = nagłówek nad nim; ukończenie = stosunek odhaczonych do wszystkich.

Skill mutuje wyłącznie Progress - bloki etapów (Overview, Changes Required, Success Criteria) są tylko do odczytu. W środku etapu odhaczone wiersze bez SHA to poprawny stan pośredni; SHA dopisuje się zbiorczo na końcu etapu, po zamykającym commicie.

Wiersz: checkbox + indeks N.M + tytuł kryterium; po domknięciu etapu dochodzi skrócony SHA commita
Podział: podsekcje Automated (komendy, testy, typy) i Manual (człowiek patrzy na wynik) per etap
Indeksy: 1-based, unikalne w etapie, nigdy nie przenumerowywane; usunięte kroki zostawiają luki
Etapy bez diffa: etap czysto ręczny nie tworzy commita i zostaje bez SHA - /10x-archive zgłosi to jako ostrzeżenie informacyjne, nie błąd

„GDZIE JESTEM?":

odpowiedź zawsze wynika z parsowania Progress - dzięki temu przerwana sesja wraca od ostatniego zielonego etapu, nie od zera, a stan nie może się rozjechać z rzeczywistością.

Dłonie Marcina i Przemka montują moduł, którego czerwony test zmienia się na zielony przed otwarciem kolejnego etapu — ANATOMIA → SPRAWDŹ, ZAPISZ, IDŹ DALEJ
Każdy etap kończy się weryfikacją i osobnym zapisem stanu, dzięki czemu pracę można bezpiecznie wznowić.

GRANICE

Czego /10x-implement nie robi

Nie odhacza za człowieka: pozycje ręczne czekają na potwierdzenie użytkownika - bez wyjątków.
Nie commituje hurtem: żadnego git add -A ani git add . - staging wyłącznie jawnymi ścieżkami ze zbioru plików dotkniętych.
Nie obchodzi bramek: nigdy --no-verify ani --amend; po nieudanym hooku naprawa problemu i nowy commit, nie poprawianie historii.
Nie edytuje planu: bloki etapów są read-only; mutacji podlega wyłącznie sekcja Progress i change.md.
Nie wykonuje archiwum: plan w context/archive/ = odmowa i wskazanie /10x-new.

NA STRONIE ŁAŃCUCHA:

wróć do kroku 04 (implement) na stronie Core Skills Chain - kontekst całego łańcucha i sąsiednie kroki.

Marcin zatrzymuje linię implementacji przy czerwonym błędzie strukturalnym, a Przemek zamyka dostęp do kolejnego modułu — GRANICE → TWARDY STOP
Gdy problem wykracza poza zatwierdzony plan, agent zatrzymuje pracę i oddaje decyzję człowiekowi.