Jeden projekt. Jedne jasne zasady.

Problem i interpretacja: Bez tych odnośników agent może uznać stary opis albo własne przypuszczenie za obowiązującą decyzję. Kod pokazuje obecny stan, ale nie jest automatycznie zgodą na zmianę celu.

Kiedy Codex używa: Na początku zadania, zanim wybierze pliki do zmiany albo zaproponuje rozwiązanie.

Co czytelnik dopasowuje: Wstaw nazwę celu oraz prawdziwe odnośniki do wymagań, decyzji i planu. W Adrian Lab są to między innymi docs/plan.md i kanoniczny article.md danego materiału.

Efekt: Codex rozpoczyna pracę od właściwego celu i wie, gdzie sprawdzić obowiązujące ustalenia.

Odbiór techniczny obejmuje sekrety, bezpieczeństwo, dane, uprawnienia i zgodność z zasadami projektu. Warunki zakończenia obejmują uzgodniony rezultat, wymagane kontrole, niezależną ocenę, zamknięte poprawki i decyzje, aktualną wiedzę, ujawnione ograniczenia oraz dowód zapisany dla ocenianej wersji.

Problem i interpretacja: Działający build nie jest jeszcze odbiorem technicznym. Sekcja rozdziela wykonanie przez agenta, sprawdzenia oraz decyzję osoby odpowiedzialnej. Jedna zgoda na konkretny pakiet pozwala dokończyć zwykłą pracę w jego granicach; nie jest zgodą na działania zewnętrzne.

Kiedy Codex używa: Gdy przygotowuje zmianę do oceny i gdy raportuje jej status.

Co czytelnik dopasowuje: Podaj tylko komendy, które ktoś już sprawdził; jeśli ich nie ma, napisz to wprost. W Adrian Lab root AGENTS.md podaje między innymi npm run build, npm test i testy zawartości.

Efekt: osoba odbierająca wynik widzi, co uruchomić, co zostało sprawdzone i czego jeszcze brakuje.

Problem i interpretacja: „Pomóż z projektem” nie daje zgody na zmianę celu, standardów, publikację ani równoległe edytowanie tych samych plików. Wspólny plan ma przechowywać stan niezależnie od historii rozmów. Granicę dostępu oceniaj według skutku, nie nazwy pliku lub podsystemu.

Kiedy Codex używa: Przed zmianą zakresu, przekazaniem pracy innej osobie lub wykonaniem działania wymagającego decyzji.

Co czytelnik dopasowuje: Opisz prawdziwy zakres i role. W projekcie jednoosobowym możesz wskazać siebie jako osobę podejmującą decyzję, ale nadal nazwij działania, które wymagają Twojej wyraźnej zgody.

Efekt: Codex wie, które działania może wykonać, a przy których ma zatrzymać się po decyzję.

Powtarzalny proces specjalistyczny trafia do Skill, a nie do coraz dłuższego root AGENTS.md.

Problem i interpretacja: Jeden wielki plik miesza zasady, które dotyczą różnych osób i plików. Sam fakt, że plik Skill istnieje, nie dowodzi jeszcze, że używane narzędzie go odkrywa.

Kiedy Codex używa: Gdy zaczyna pracę w konkretnym katalogu albo gdy proces powtarza się na tyle często, że warto go opisać raz.

Co czytelnik dopasowuje: Dodaj tylko instrukcje i Skills, które rzeczywiście istnieją. Adrian Lab ma content/AGENTS.md dla materiałów; root AGENTS.md mówi, kiedy go przeczytać. Nie twórz synchronizacji Skills bez realnej potrzeby. Jeżeli synchronizacja istnieje, może usuwać wyłącznie własne zarządzane pliki, musi blokować ścieżki wychodzące poza dozwolony katalog, zachowywać niezależnie zainstalowane Skills i zatrzymywać się przy konflikcie poza manifestem. Po zmianie potwierdź odkrywanie w świeżej sesji każdego narzędzia.

Efekt: zasady są blisko pracy, której dotyczą, a narzędzie ma potwierdzone instrukcje zamiast przypadkowych plików.

Agent działa w istniejących granicach dostępu i najpierw rozpoznaje stos technologiczny.

Problem i interpretacja: Prośba o „szybkie obejście” blokady lub instalację nowego narzędzia może naruszyć zasady dostępu i stworzyć koszt utrzymania. Naprawa walidacji istniejącego dostępu nie oznacza jego rozszerzenia. Brak decyzji o technologii nie jest decyzją pozytywną.

Kiedy Codex używa: Zanim poprosi o uprawnienia, połączy zewnętrzną usługę, doda zależność lub odczyta konfigurację.

Co czytelnik dopasowuje: Wpisz obowiązujące standardy i granice kont w sposób bezpieczny, bez wartości sekretów. Adrian Lab dodatkowo zakazuje zapisywania tokenów, danych klientów i prywatnych materiałów w repozytorium.

Efekt: agent działa w ustalonych granicach bez ujawniania sekretów ani omijania ochrony dostępu.

Sekcja obejmuje również bibliotekę komponentów, design system, brand book, ekrany referencyjne, telefon, dostępność i wspólne stany interfejsu.

Problem i interpretacja: Agent nie powinien dobierać frameworka, biblioteki UI lub systemu logowania tylko dlatego, że zna je z innego projektu. Dla interfejsu ta sama zasada dotyczy design systemu, ekranów referencyjnych, telefonu i dostępności.

Kiedy Codex używa: Przed implementacją, instalacją zależności albo budową nowego ekranu.

Co czytelnik dopasowuje: Uzupełnij wyłącznie zatwierdzone technologie, wersje i źródła decyzji. W Adrian Lab root AGENTS.md wskazuje React 19, Vite 6 i istniejący język wizualny strony głównej; nie dopisuje nieistniejącego backendu. Gdy standard nie jest ustalony, agent przedstawia koszt i ograniczenia oraz najwyżej jedną alternatywę technologiczną; dla biblioteki UI najwyżej trzy zgodne propozycje i jeden kierunek. Instalacja czeka na decyzję.

Efekt: nowa funkcja rozwija uzgodniony stos i interfejs, zamiast wprowadzać przypadkowe narzędzia.

Jeśli podaje postęp, wylicza go z jednego aktualnego planu wraz ze źródłem, licznikiem i mianownikiem. Nie utożsamia liczby zadań z czasem lub gotowością produktu, nie liczy częściowych zadań jako odebranych i nie wymyśla wag ani procentów.

Problem i interpretacja: Status „gotowe” łatwo ukrywa brak testu albo oczekujący odbiór. Procent postępu ma sens wyłącznie wtedy, gdy wynika z aktualnego planu i podaje licznik oraz mianownik.

Kiedy Codex używa: Na końcu zadania i po zakończeniu znaczącego etapu.

Co czytelnik dopasowuje: Wskaż jedno istniejące miejsce stanu. W Adrian Lab jest nim docs/plan.md lub content/QUEUE.md, zależnie od obszaru. Nie twórz osobnego dziennika tylko po to, aby raportować postęp. Gdy plan jest niepełny, podaj znany stan bez procentu. Gdy cały zakres jest zakończony, wskaż odbiór albo brak dalszej pracy zamiast dopisywać sztuczny następny krok.

Efekt: raport odróżnia wykonanie od odbioru i wskazuje osobę odpowiedzialną za następny konkretny ruch.

Pokazujesz jeden widok lub przepływ, zbierasz uwagi, robisz małą poprawkę i kontrolę stosowną do ryzyka, a potem pokazujesz ten sam widok. Po całej serii zmian pytasz osobno o akceptację nazwanego etapu. Przerwa bez akceptacji wstrzymuje sesję, a stan i otwarte uwagi trafiają do istniejącego planu.

Problem i interpretacja: Koniec komentarzy, cisza albo „OK” po jednej drobnej korekcie nie oznaczają automatycznie akceptacji całego demo. Akceptacja demo także nie zastępuje odbioru technicznego, zgody na merge ani publikacji.

Kiedy Codex używa: Po znaczącym etapie zmiany interfejsu; dla etapu bez interfejsu pokazuje artefakt i dowody sprawdzenia. Po akceptacji doprowadza zmianę do wymagań architektury, testów, bezpieczeństwa i integracji, usuwa prowizorki i wykonuje wymagane kontrole. Zmiana zaakceptowanego zachowania wraca na demo.

Co czytelnik dopasowuje: Nazwij projekt, etap i widoki, które naprawdę da się pokazać. Użyj bezpiecznego podglądu i fikcyjnych danych, zachowaj ochronę sekretów i granice kont. Akceptacja demo nie zastępuje odbioru technicznego ani zgody na merge lub wydanie. Przy blokadzie podaj powód i zapisz „demo oczekuje” w istniejącym planie; nie deklaruj pokazu, którego nie przeprowadzono.

Efekt: użytkownik ocenia widoczny etap, a zespół zachowuje jasną granicę między demo, odbiorem technicznym i wydaniem.

Co mówi: W Adrian Lab plan jawnie ogłasza, że jest jedynym aktywnym planem, a każdy etap ma nazwany status, właściciela, rezultat i dowód.

Problem i interpretacja: Status zapisany tylko w historii rozmowy szybko traci aktualność. Kilka równoległych planów może podawać sprzeczne następne kroki. Jeden plan daje następnej sesji sprawdzalny punkt startu.

Kiedy Codex używa: Na początku zadania, na znaczącej granicy etapu, przed przekazaniem pracy oraz wtedy, gdy raportuje status i następny krok. Samo istnienie docs/plan.md nie powoduje jego automatycznego wczytania.

Co czytelnik dopasowuje: W swoim projekcie wybierz jedną ścieżkę planu i wskaż ją w AGENTS.md. Nie kopiuj historycznych etapów Adrian Lab. Użyj własnych etapów, właścicieli, dowodów i bramek.

Efekt: stan projektu pozostaje w jednym miejscu, które następna sesja może sprawdzić bez odtwarzania historii rozmowy.

Co mówi: Rzeczywisty L-002 oddziela obserwację, przyczynę, dowód, zastosowanie i status. Zapisuje relację: wniosek w learnings.md → trwała wskazówka w root AGENTS.md → szczegółowe zasady w content/AGENTS.md.

Problem i interpretacja: Bez dowodu przypadkowa jednorazowa sytuacja może stać się zbyt szeroką regułą. Z kolei reguła istniejąca tylko w rejestrze wniosków może nie zostać użyta, ponieważ zwykły Markdown nie jest automatycznie instrukcją.

Kiedy Codex używa: Gdy powtarzalny błąd lub obserwacja ma dowód i zmienia przyszły sposób pracy. Po potwierdzeniu przenosi właściwą zasadę do jednego obowiązującego miejsca, a w rejestrze pozostawia dowód i odnośnik.

Co czytelnik dopasowuje: Jeżeli Twój projekt nie potrzebuje takiego rejestru, usuń plik i jego odnośnik. Nie kopiuj statusu aktywny z Adrian Lab: najpierw przeprowadź własną weryfikację w świeżym zadaniu.

Efekt: sprawdzony wniosek staje się trwałą zasadą, a nie niezweryfikowaną notatką.