Jak pracujemy.

• —Braki strukturalne blokują build: deklaracja bez źródła, zakresu, właściciela lub daty nie może zostać wydana.
• —Daty wymagają zer wiodących — brak jednego zera w 2026-9-18 mógłby uniemożliwić wygaśnięcie deklaracji do końca roku.
• —Wygaśnięcie NIE blokuje buildu, lecz zmienia stronę: wygasła deklaracja nie jest fałszywa, tylko niezweryfikowana. Nie usuwamy jej; oznaczamy jako oczekującą na ponowną weryfikację.
• —Karta statystyki nie może pokazywać liczby nieobecnej w powiązanej deklaracji.
• —Niewydany produkt nie może pokazywać zmyślonego ekranu; każdy zrzut podaje źródłową wersję i datę wykonania.
• —Kontrola tekstu wykrywa po nazwie 12 stwierdzeń, które wcześniej okazały się fałszywe, i blokuje ich powrót.
• —Warunek publikacji przypadku: bez zgody, stanu wyjściowego, artefaktu, zmierzonego wyniku, lekcji z niepowodzenia i daty ważności nie ma opisu.

• —Po wyłączeniu nowych zgłoszeń endpoint formularza zwraca 503. Dostarczenie przyjętych powiadomień zależy od osobnej konfiguracji poczty i wykonania workera kolejki; zamknięcie przyjmowania zgłoszeń nie anuluje oczekujących wiadomości.
• —Zgoda to nie pole wyboru, lecz osobny zapis z datowaną wersją informacji. Sama wiedza, że ktoś się zgodził, nie mówi, na co wyraził zgodę.
• —Pomiar lejka odrzuca dowolny tekst: wartości pól są ograniczone, a ścieżki nie zawierają zapytań URL. Surowe zapisy są przechowywane przez 30 dni i usuwane po wygaśnięciu przez zadanie; wykonanie usuwania w produkcji potwierdzają zapisy uruchomienia.
• —Wnioski dotyczące danych obejmują weryfikację adresu e-mail. Jej zakończenie nie oznacza realizacji dostępu, sprostowania ani usunięcia.
• —Witryna ma CSP ograniczającą źródła treści i nagłówki blokujące osadzanie przez inne strony. Strony ogólne i weryfikacja e-maila używają odmiennych reguł CSP.

• —Decyzje założyciela: publikacja w sklepie, ceny, realne pieniądze, własność kont, kwestie prawne i nieodwracalne decyzje należą wyłącznie do człowieka.
• —Prace nad bezpieczeństwem, płatnościami, migracją i prywatnością wymagają niezależnego przeglądu przed odbiorem; nikt nie zatwierdza własnej pracy. Odrzucenia rzeczywiście się zdarzają — są rundy odrzucone więcej niż raz.
• —„Gotowe” nie jest procentem: praca kończy się dopiero w stanie ACCEPTED, do którego nie można przejść bez rekordu dowodowego.
• —Etapy wymagające człowieka, urządzenia lub czasu są zapisywane jako EXTERNAL GATES, z jawnym działaniem i dowodem ukończenia.

• !Kontrola tekstu działa przy każdym buildzie, lecz cele z innych repozytoriów istnieją tylko lokalnie i w CI — wdrożenie obsługujące tę stronę wykonuje węższą wersję.
• !Studium przypadku nie wprowadza własnej liczby: wskazuje zweryfikowaną wartość z rejestru i odczytuje ją stamtąd. Dotyczy to też tytułu, etykiety metryki i sekcji „co się zmieniło”, bo są odbierane jako deklaracje. Stan wyjściowy, ograniczenia, decyzje, etykiety artefaktów, zakres zgody i lekcje z błędów pozostają swobodnym tekstem, gdzie liczby są dozwolone. Znany wyjątek: ciąg w formie identyfikatora, np. „Accuracy-95”, jest akceptowany jako etykieta.
• !Strony produktów używają dat weryfikacji dla informacji sklepowych i dostępności; wygasłe deklaracje otrzymują oznaczenie ponownej weryfikacji. Okna weryfikacji wygasły dla 5 zapisanych powierzchni. Nie obejmuje to całego tekstu promocyjnego.
• !Dostępność linków nie blokuje CI: niedziałający adres sklepu powoduje ostrzeżenie, ale nie zatrzymuje procesu.
• !CI obejmuje lint, kontrolę typów, testy, build i sprawdzanie zależności. Wyniki oceniamy w odniesieniu do zmiany i zapisu uruchomienia; lokalne kontrole nie dowodzą wydania produkcyjnego.
• !Domyślna konfiguracja wdrożenia uruchamia zadanie poczty raz dziennie. To nie zobowiązanie do terminu dostarczenia; wysyłka zależy od konfiguracji, dostawcy i pomyślnego wykonania zadania.

Powiązane: przejrzystość produktów · studia przypadków