# Zasady pracy w projekcie — publiczny starter Ten kompletny, zanonimizowany szablon powstał na podstawie aktualnego `starter/project/AGENTS.md` w Codex Engineering System. Zachowuje jego strukturę i reguły. Dopiski `PO CO` wyjaśniają rolę sekcji; pola w nawiasach trzeba uzupełnić wyłącznie na podstawie rzeczywistego projektu. To szkielet do uzupełnienia przed użyciem. Zastąp pola w nawiasach na podstawie rzeczywistych plików i decyzji zespołu. Nie wpisuj danych dostępowych. Zachowaj ten plik jako krótki kontrakt i mapę źródeł. Nie dopisuj tu bieżącego statusu, kolejnych punktów kontrolnych, pełnej historii decyzji ani wyników testów. Zapisuj je w jednym planie, rejestrze decyzji lub dowodach i podawaj odnośniki. Po większej zmianie sprawdź rozmiar pliku oraz w świeżej sesji poproś Codexa o wskazanie odczytanych instrukcji. Domyślny łączny limit instrukcji projektowych wynosi 32 KiB; zwiększenie go nie naprawia źle rozdzielonej wiedzy. ## Cel i źródła - Cel projektu: [uzgodniony cel]. - Wymagania i oczekiwane zachowanie: [istniejący plik lub odnośnik]. - Budowa rozwiązania i ważne decyzje: [istniejące źródło]. - Jeden aktualny plan zadania: [miejsce zapisu]. - Kod i ustawienia pokazują obecny stan. Rozbieżność z wymaganiami zgłoś, zamiast po cichu zmieniać oczekiwania. ## Wykonanie i odbiór - Uruchomienie projektu: [sprawdzona komenda lub jawny brak]. - Testy i pozostałe sprawdzenia: [sprawdzone komendy lub jawne braki]. - Ścieżka pracy: [funkcja przygotowywana do odbioru technicznego / własny projekt]. - Przed zmianą w środowisku firmowym lub współdzielonym opisz jeden zatwierdzony pakiet prac: zamierzony rezultat, znane pliki lub obszary, sprawdzenia, istotne ryzyka i oczekiwany zasięg. O ile kontrakt projektu nie zawęża tej zgody, obejmuje ona implementację, zwykłe naprawy, testy, regresje, niezależny przegląd, dotkniętą dokumentację źródłową oraz odwracalne aktualizacje już zatwierdzonego lokalnego demo. Nie obejmuje automatycznie commitów, pushy, publikacji ani innego działania zewnętrznego. - Wykonaj zatwierdzony pakiet przez znaczący etap. Pytaj ponownie tylko, gdy zmienia się cel, zakres, kryteria odbioru lub istotne ryzyko, albo gdy obowiązuje osobna bramka człowieka. Blokadę hosta, sandboxa, konta, narzędzia lub polityki nazwij zgodnie z jej źródłem; nigdy nie przedstawiaj jej jako ogólnej potrzeby ponownego zatwierdzenia zwykłej naprawy. - Przy funkcji przygotowywanej przez osobę bez doświadczenia programistycznego obowiązuje odbiór przez uprawnioną osobę techniczną. Agent może przygotować przegląd, ale nie zastępuje człowieka. Do tego czasu status to oczekiwanie na CR. - Odbiór techniczny obejmuje sekrety, bezpieczeństwo, dane, uprawnienia i zgodność z zasadami projektu. Nie umieszczaj wartości sekretów w raporcie. - Warunki zakończenia: uzgodniony wynik, wymagane sprawdzenia, niezależna ocena, zamknięte wymagane poprawki i decyzje, aktualna wiedza oraz ujawnione ograniczenia. - Zapisz dowody dla ocenianej wersji i następny krok w istniejącym planie. ## Zasady zespołu - Dozwolony zakres samodzielnej pracy: [uzgodniony zakres]. - Decyzje i działania wymagające zgody: [granice ustalone przez zespół]. - Osoba lub rola odbierająca wynik: [uzgodniona odpowiedzialność]. - Nie zmieniaj celu ani standardów zespołu bez właściwej zgody. - Pracując równocześnie, uzgodnij obszary zmian i sposób ich połączenia. - Informacje i plan pozostają wspólne niezależnie od używanego asystenta. - Nie kopiuj tu ustawień kont ani preferencji pojedynczej osoby. - Naprawa kodu sprawdzającego istniejące uprawnienia lub już dostarczone dane logowania może być zwykłą pracą w zatwierdzonym pakiecie. Nowe albo szersze uprawnienie, zmieniony lub ujawniony sekret, słabsza kontrola, zmiana konta albo polityki tożsamości produkcyjnej wymaga właściwej bramki człowieka. ## Instrukcje obszarów i Skills - Regułę dotyczącą tylko jednego obszaru zapisz w najbliższej instrukcji tego obszaru i wskaż tutaj jedynie warunek jej odczytu. - Powtarzalny specjalistyczny proces umieść w Skill. Dla Codexa projektowy Skill powinien znajdować się w `.agents/skills//SKILL.md`. - Jeśli zespół synchronizuje Skills do kilku narzędzi, wskaż jedno źródło, wszystkie obsługiwane katalogi, manifest plików zarządzanych oraz komendę wykrywającą brak, zmianę treści, dodatkowy plik i starą kopię. - Mechanizm synchronizacji może usuwać wyłącznie pliki, które sam wcześniej oznaczył jako zarządzane. Musi odrzucać nazwy i ścieżki wychodzące poza dozwolony katalog oraz zachowywać Skills zainstalowane niezależnie. Gdy docelowy plik istnieje poza manifestem, zatrzymaj pracę; nie nadpisuj go ani nie przejmuj do manifestu bez jawnej decyzji. - Po zmianie sprawdź odkrywanie reguł i Skills w świeżej sesji każdego używanego narzędzia. Obecność pliku nie dowodzi, że narzędzie go odczytuje. ## Ochrona dostępu i zgodność technologii - Nigdy nie proś o dane logowania, hasła, kody jednorazowe ani prywatne klucze w rozmowie. Nie odczytuj ani nie ujawniaj wartości sekretów. - Nie wyłączaj sandboxa ani nie rozszerzaj uprawnień, żeby ominąć blokadę. - Nigdy nie wyłączaj ani nie obchodź automatycznej kontroli bezpieczeństwa. - Rozpoznaj istniejące technologie i potwierdź standard zespołu. Nowe technologie lub dostawcy wymagają uzgodnienia przed implementacją. ## Technologie i interfejs - Kontrakt technologiczny w aktualnym planie: [odnośnik albo jawny brak]. - Frontend: [wymagany lub wybrany standard i wersja]. - Backend, baza danych i logowanie: [standardy i wersje]. - Testy, hosting i wdrażanie: [standardy oraz sprawdzone komendy]. - Elementy wymagane / preferowane / niedozwolone / nieustalone: [źródło decyzji]. - Kontrakt interfejsu w aktualnym planie: [odnośnik albo nie dotyczy]. - Biblioteka komponentów i design system: [standard i wersja albo jawny brak]. - Brand book lub inne źródło wyglądu: [odnośnik albo jawny brak]. - Katalog komponentów i ekrany referencyjne: [odnośnik albo jawny brak]. - Telefon, dostępność i wspólne stany interfejsu: [uzgodnione wymagania]. - Nie wybieraj nieustalonej technologii samodzielnie. Przedstaw rekomendację, koszt, ograniczenia i najwyżej jedną alternatywę; przed instalacją uzyskaj decyzję. - Przed budową nowych ekranów użyj istniejącego standardu. Jeśli go nie ma, zaproponuj najwyżej trzy biblioteki zgodne z frontendem i jeden kierunek. Po wyborze stosuj kontrakt zamiast projektować każdy widok od początku. ## Raportowanie postępu i następnego kroku - Po każdym zadaniu podaj wynik, wykonane sprawdzenia, ograniczenia i aktualny etap z planu. Rozróżnij wykonanie, sprawdzenie i wymagany odbiór; oczekującego przeglądu człowieka nie oznaczaj jako zakończonego odbioru. - Zakończ raport zdaniem „Następny krok: …”, podając konkretną czynność z planu oraz wykonawcę lub osobę podejmującą decyzję. Nazwij wymagane zgody i blokady. - Po zakończeniu etapu zaktualizuj istniejący plan w zatwierdzonym zakresie, wskaż zakończony i kolejny etap oraz postęp całego zaplanowanego zakresu. Jeśli aktualizacja nie jest dozwolona, zgłoś oczekującą aktualizację. - Postęp wyliczaj z aktualnego planu: podaj źródło, licznik i mianownik, np. „6 z 20 zadań odebranych — 30% liczby zadań; 2 z 8 etapów zakończone”. Nie utożsamiaj liczby zadań z czasem, nakładem pracy ani gotowością produktu. Nie licz zadań częściowych jako odebranych ani podzadań drugi raz. - Jeśli plan stosuje uzgodnione wagi, podaj sposób liczenia. Nie wymyślaj wag ani procentu. Przy zmianie zakresu wyjaśnij zmianę podstawy obliczeń. Gdy brak pełnego planu, podaj znany stan bez procentu i bez wymyślania etapów. - Korzystaj z jednego istniejącego planu; nie twórz osobnego dokumentu postępu. Wskazanie następnego kroku nie rozszerza zgody na pracę. Jeśli dalsza praca jest zlecona i dozwolona, raportuj i kontynuuj bez zbędnego zatrzymania. - Gdy cały uzgodniony zakres jest zakończony, powiedz to. Nie dodawaj zadań tylko po to, by mieć następny krok; wskaż oczekujący odbiór, jeśli dotyczy, albo brak dalszych prac w uzgodnionym zakresie. ## Sesja Live Demo - Po znaczącym etapie przygotuj wiarygodny pokaz i rozpocznij Sesję Live Demo: nazwij projekt oraz etap i wyjaśnij „Pokazuję, Ty komentujesz, ja szybko poprawiam; docelowa implementacja ze wszystkimi wymaganiami technicznymi następuje po akceptacji demo”. Użyj widocznego Computer Use i aktywnej rozmowy głosowej; gdy głos jest niedostępny, powiedz o tym i użyj krótkiego tekstu. - Prowadź po jednym widoku: „Akceptujesz ten widok?”. Tak → następny widok; nie → „Co zmienić?”. Bezpośrednie uwagi realizuj bez dodatkowego pytania. Mała zmiana → sprawdzenie stosowne do ryzyka → ten sam odświeżony podgląd. Nie przerywaj serii uwag; bez pełnych testów, szerokich porządków i aktualizacji całej dokumentacji po każdej korekcie wizualnej. Ryzykowne zmiany sprawdzaj od razu. Checkpoint sprawdza stan techniczny, ale nie kończy sesji. - Podpowiadaj dalsze uwagi albo zamknięcie sesji. Koniec uwag nie jest akceptacją. Po pokazaniu wszystkich zgłoszonych zmian zapytaj osobno o akceptację demo nazwanego etapu i rozpoczęcie docelowej implementacji. Naturalna jednoznaczna odpowiedź wystarcza; nie wymagaj komend ani ponownej zgody. Niejasności wyjaśnij. Akceptacja widoku, cisza i „OK” po pojedynczej poprawce nie zatwierdzają całości. - Przerwa bez akceptacji wstrzymuje sesję. Stan, decyzje, odrzucone warianty, otwarte uwagi i zaakceptowaną wersję zapisuj w jednym istniejącym planie. Nie twórz nowego worktree ani dziennika dla każdej uwagi. Przed zmianą projektu zapisz stan, po powrocie potwierdź właściwy kontekst. - Po akceptacji doprowadź całą zmianę do wymagań architektury, testów, bezpieczeństwa i integracji projektu, usuń prowizorki i wykonaj obowiązkowe kontrole przed odbiorem. Zmiana zaakceptowanego zachowania wraca na demo. Akceptacja demo nie zastępuje odbioru technicznego ani zgód na merge lub wydanie. - Używaj bezpiecznego podglądu i fikcyjnych danych; zachowaj ochronę sekretów, granice kont i wymagane zgody. Dla etapu bez interfejsu pokaż artefakt i dowody sprawdzenia. Przy blokadzie podaj powód i „demo oczekuje” w istniejącym planie. Nie deklaruj niewykonanego pokazu. Po sesji podaj stan etapu i następny krok.