/10x-impl-review - plan kontra kod

Review istnieje po to, by wątpić - zamiast odprawiać rytuał „wygląda dobrze".Review istnieje po to, by sprawdzić - zamiast akceptować „wygląda dobrze". /10x-impl-review porównuje rzeczywistą implementację z planem: dwóch równoległych subagentów szuka dryfu i zagrożeń, komendy z kryteriów sukcesu są uruchamiane naprawdę, a wynik ląduje jako raport z werdyktem i listą findingów gotowych do triage'u.

/10X-IMPL-REVIEW // OBIETNICA PLANU KONFRONTOWANA Z DIFFEM

PO COWarhammer 40k · Zrozumienie zamiast rytuału

Problem: akceptacja bez sprawdzenia obietnic

„Rytuał uspokaja maszynę. Zrozumienie mówi, czy działa."

- herezja użyteczna, oddział kogitatorów

„Działa, mergujemy" to akceptacja bez sprawdzenia, czy kod dotrzymał obietnic planu. Dryf, niebezpieczne decyzje i łamanie konwencji kumulują się po cichu - każdy etap dokłada odrobinę, aż rozjazd staje się architekturą. /10x-impl-review łapie to, zanim się utrwali.

Dwa zakresy: review pojedynczego etapu (szybki, tuż po jego domknięciu) i pełny przegląd planu przed merge. Dwa tryby: świeży review z triage'em oraz wznowienie - zapisany raport otwiera się później i triage rusza od pozycji nierozstrzygniętych.

CEL:

najbardziej przydatny przed merge - im większy diff, tym łatwiej o dryf między tym, co plan obiecał, a tym, co kod robi.

Marcin i Przemek w teatrze odpraw nakładają planowaną trasę na gotową konstrukcję i ujawniają różnice — PO CO → PORÓWNAJ OBIETNICĘ Z WYNIKIEM
Review nie pyta tylko, czy kod wygląda dobrze — sprawdza, czy dowieziono dokładnie to, co wcześniej zatwierdzono.

WEJŚCIE → WYJŚCIE

Z planu i diffa do zapisanego raportu

Wejściem jest plan.md (change-id, ścieżka albo numer etapu) i faktyczny stan repozytorium - diff wyznaczany od daty planu. Zestawienie plików z planu z plikami z diffa daje trzy klasy: oczekiwane (w obu - weryfikuj treść), nieplanowane (tylko w diffie - zbadaj i oflaguj), brakujące (tylko w planie - potencjalnie niezaimplementowane).

Wyjściem jest raport w reviews/ folderu zmiany - zapisywany zawsze, niezależnie od tego, czy triage rusza teraz, później czy wcale. Wraz z zapisem change.md dostaje status impl_reviewed.

Wejście: plan.md + diff od daty planu; alternatywnie zapisany raport (wznowienie triage'u)
Wyjście: raport w context/changes/<change-id>/reviews/ z werdyktem i findingami z polem Decision
Werdykt: APPROVED / NEEDS ATTENTION / REJECTED - z werdyktami cząstkowymi w sześciu wymiarach

Marcin i Przemek nakładają na siebie zatwierdzony plan i gotową implementację — WEJŚCIE → WYJŚCIE
Plan i kod wchodzą do review jako dwa niezależne źródła, dzięki czemu różnice stają się widoczne.

MECHANIZM

Dwóch subagentów, realne komendy, triage

01 · Kontekst: plan czytany w całości, stan z sekcji Progress, reguły z lessons.md przyjmowane z góry - naruszenie zaakceptowanej reguły to mocniejszy sygnał niż generyczna uwaga stylistyczna.
02 · Zakres z gita: commity i diff od daty planu; lista plików zmienionych kontra lista z planu wyznacza, co jest oczekiwane, nieplanowane i brakujące.
03 · Subagent dryfu: dla każdej planowanej zmiany czyta faktyczny plik i orzeka: MATCH / DRIFT / MISSING / EXTRA - rozjazd intencji, nie formatowania.
04 · Subagent jakości: równolegle: bezpieczeństwo (injection, sekrety, authn/authz), wydajność (N+1, brak paginacji), niezawodność (obsługa błędów na granicach), bezpieczeństwo danych oraz zgodność ze wzorcami sąsiednich plików.
05 · Kryteria naprawdę: komendy z kryteriów automatycznych są uruchamiane, wynik porównany z deklaracjami; pozycje ręczne odhaczone bez śladu w diffie są flagowane jako możliwe zatwierdzenie w ciemno (rubber-stamping).
06 · Raport: findingi posortowane po severity, maks. 10 (pokrewne konsolidowane); zapis na dysk i stempel statusu zawsze przed pytaniem, co dalej.
07 · Triage: pętla po findingach: napraw teraz, napraw inaczej, pomiń, albo zapisz jako lekcję do lessons.md; każda decyzja wraca do zapisanego raportu, więc triage można przerwać i wznowić.

ZASADA:

review domyślnie analizuje i raportuje - edycje kodu zdarzają się wyłącznie w triage'u, gdy użytkownik jawnie wybierze naprawę konkretnego findingu.

Marcin i Przemek porównują cztery wyniki: zgodność, brak, dodatkowy element i dryf implementacji — MECHANIZM → CZTERY WERDYKTY
Review pokazuje zgodność, braki, dodatki i dryf — a potem porządkuje znaleziska według ich wpływu.

ANATOMIA

Finding - dowód zamiast opinii

Każdy finding niesie dowód w formule „plan mówił X, kod robi Y" z lokalizacją plik:linia oraz propozycję naprawy z analizą kompromisów. Dwie opcje naprawy pojawiają się tylko przy prawdziwym dylemacie - słabych alternatyw nie wymyśla się na siłę.

Para wymiarów: severity mówi, jak źle będzie, gdy problem zostanie zignorowany; impact - ile namysłu wymaga decyzja. To osie ortogonalne: CRITICAL z niskim impactem to oczywista jednolinijkowa poprawka, a WARNING z wysokim impactem zasługuje na dłuższy namysł niż niejeden CRITICAL.

Severity: CRITICAL / WARNING / OBSERVATION - waga problemu przy zignorowaniu
Impact: LOW / MEDIUM / HIGH - koszt decyzji: od szybkiej poprawki po stawkę architektoniczną
Wymiar: jeden z sześciu: Plan Adherence, Scope Discipline, Safety & Quality, Architecture, Pattern Consistency, Success Criteria
Dowód: lokalizacja plik:linia + Detail zestawiający zapis planu z faktycznym kodem
Naprawa: 1-2 opcje z mocnymi stronami, kosztami, poziomem pewności i jawnym martwym polem
Decision: PENDING → FIXED / SKIPPED / ACCEPTED / DISMISSED - pole w raporcie aktualizowane podczas triage'u

WERDYKT CAŁOŚCI:

APPROVED - wszystko przechodzi lub maks. 2 drobne ostrzeżenia; NEEDS ATTENTION - wiele ostrzeżeń lub jeden niekrytyczny FAIL; REJECTED - dowolny krytyczny FAIL (bezpieczeństwo, poważny dryf, dane, oblane testy).

Dłonie Marcina i Przemka nakładają plan na implementację i rozdzielają zgodność, brak, dodatek oraz dryf — ANATOMIA → CZTERY RODZAJE RÓŻNIC
Jedno porównanie daje cztery jawne werdykty, zamiast mieszać wszystkie uwagi w ogólnym „coś tu nie pasuje”.

GRANICE

Czego /10x-impl-review nie robi

Nie poprawia po cichu: zmiany w kodzie tylko na jawny wybór użytkownika w triage'u - i wtedy minimalne, celowane edycje, bez refaktorowania okolicy.
Nie flaguje stylu: drobne różnice stylistyczne, gdy kod działa i realizuje plan, to co najwyżej obserwacje - nie ostrzeżenia.
Nie oszczędza planu: jeśli sam plan był wadliwy (np. zaplanowano niebezpieczne podejście), review flaguje plan - nie tylko kod.
Nie kłóci się przy „pomiń": decyzja użytkownika zapisywana bez dyskusji; przy review etapu sprawdza też, czy nie złamał założeń etapów wcześniejszych.
Nie dotyka archiwum: do zarchiwizowanych planów review nie jest dopisywany - odmowa wprost.

NA STRONIE ŁAŃCUCHA:

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

Marcin i Przemek zatrzymują strumień review przed zamkniętą bramą i przekazują czerwone znalezisko do decyzji człowieka — GRANICE → DECYZJA WRACA DO CZŁOWIEKA
Agent może znaleźć i uporządkować problem, ale ryzykowny wyjątek nie przechodzi dalej bez świadomej decyzji.