Pełna doktryna jako reguły operacyjne

1. 1

   Skille i refaktoring pod kontrolą

   Powtarzalny, sprawdzony wzorzec warto zamknąć w skillu — wtedy agent ma gotowe narzędzie zamiast wymyślać je za każdym razem od nowa. Refaktoring jest dyscypliną, nie sprzątaniem przy okazji: najpierw zielone testy jako siatka bezpieczeństwa, potem zmiana struktury bez zmiany zachowania, na końcu znów zielono. Nie miesza się refaktoringu z nową funkcjonalnością w jednym commicie. Kiedy nie ma testów, które obronią zmianę, najpierw piszesz testy.

2. 2

   Model danych i normalizacja

   Dane projektuje się tak, by się nie powielały i łatwo zmieniały: wartości słownikowe trzymane w jednym miejscu, slug zamiast gołego ID tam, gdzie URL ma być czytelny i trwały, wzorzec aktywnego wiersza zamiast twardego kasowania historii. Denormalizacja bywa potrzebna dla wydajności, ale jest decyzją świadomą i opisaną, nie efektem ubocznym pośpiechu. Pytanie kontrolne: „jeśli ta wartość zmieni się jutro, w ilu miejscach trzeba ją poprawić?”. Dobra odpowiedź to „w jednym”.

3. 3

   Elastyczność, skalowalność, wydajność

   Warstwy aplikacji rozdziela się, a zmienne zachowania chowa za feature flagami, żeby produkt rósł bez przepisywania go od zera. Wydajność to dyscyplina pomiaru: najpierw mierzysz i znajdujesz realne wąskie gardło, dopiero potem optymalizujesz — indeksy (w tym częściowe) tam, gdzie zapytania bolą, koniec z problemem N+1, streaming dużych odpowiedzi zamiast ładowania wszystkiego do pamięci. Wybór między „skala do zera” a „zawsze włączony” robisz świadomie, pod profil ruchu. Szybkość udowadnia się liczbami przed i po, nie wrażeniem.

4. 4

   Odporność operacyjna

   Po wdrożeniu w serwis uderzają realni użytkownicy i zewnętrzne systemy — i wtedy okazuje się, czy jest odporny. Limity zapytań, timeouty i bezpieczne wartości brzegowe sprawiają, że jeden zły request albo wolna zależność nie kładą całości. Obsługa zdarzeń jest idempotentna: ten sam sygnał odebrany dwa razy nie psuje stanu. Projektujesz pod awarię zależności, nie tylko pod szczęśliwą ścieżkę — bo zewnętrzne API kiedyś padnie, a Twój serwis ma to przetrwać z godnością.

5. 5

   Widoczność i dane z sieci

   SEO robi się porządnie: hreflang dla wersji językowych, dane strukturalne (JSON-LD), świadome E-E-A-T/YMYL tam, gdzie temat jest wrażliwy, a parytet językowy traktujesz jak test, nie życzenie. Pozyskiwanie danych z sieci, delegowanie zadań do API AI i chatboty to funkcje produktu z własnym kontraktem: scraping z poszanowaniem limitów i kosztów, zadania do AI opisane jak każde inne wejście-wyjście, chatbot sterowalny konfiguracją bez kolejnego deployu. Każda z tych rzeczy ma być tania, przewidywalna i odwracalna.

Rozdziały tego poziomu