Lista kontrolna 23 punktów dla aplikacji vibe coding przed pierwszą płatnością

Zanim twoja aplikacja vibe coding przyjmie pierwszą płatność, poproś agenta AI o sprawdzenie tych 23 punktów:

1. Istnieje jeden dokument systemu designu, a wszystkie kolory, rozmiary czcionek i odstępy są z nim zgodne.
2. Dla każdego stanu przewidziano osobne ekrany: ładowanie, brak danych i błąd.
3. Klucze prywatne są przechowywane tylko na serwerze. Pliki frontendu i historia Git są sprawdzane pod kątem wycieków, a każdy klucz kiedykolwiek ujawniony jest rotowany.
4. Każdy endpoint API weryfikuje autoryzację i uprawnienia po stronie serwera. W bazie danych włączono RLS (Row Level Security).
5. Dla wszystkich usług rozliczanych za zużycie, takich jak AI, SMS i e-mail, skonfigurowano limity wydatków lub alerty.
6. Webhooki płatności weryfikują podpis, a ponowne otrzymanie powiadomienia o tej samej płatności nie powoduje podwójnego księgowania.
7. Zwroty, anulowania i nieudane obciążenia są testowane w trybie testowym. Każdy scenariusz wykonuje się raz i kończy ustawieniem poprawnego statusu.
8. Po zakończeniu okresu próbnego lub subskrypcji dostęp jest odbierany na czas.
9. Przy przejściu z płatności testowych do produkcyjnych ponownie konfiguruje się klucze API produkcyjne i sekret podpisu webhooków.
10. Kwoty pieniężne są przechowywane jako liczby całkowite w najmniejszej jednostce waluty, jak w Stripe. Żadnych liczb zmiennoprzecinkowych: w JavaScript 0.1 + 0.2 nie jest równe 0.3.
11. Podwójne kliknięcie przycisku wysyłania tworzy tylko jedno zamówienie.
12. Podatek od sprzedaży lub VAT jest skonfigurowany dla krajów, w których sprzedajesz produkt.
13. Warunki korzystania i polityka prywatności odpowiadają rzeczywistemu działaniu aplikacji.
14. Skonfigurowano codzienne automatyczne kopie zapasowe. W darmowym planie Supabase ich nie ma, więc trzeba przejść na Pro lub ustawić własne zrzuty. Trzeba też raz przetestować odtwarzanie danych w nowej bazie.
15. Dla każdej migracji schematu bazy danych przygotowano SQL do rollbacku. Migrację i rollback testuje się na kopii danych produkcyjnych.
16. Listy zawierające ponad 1000 rekordów nie są po cichu przycinane. Domyślnie API Supabase zwraca maksymalnie 1000 wierszy.
17. Czas jest przechowywany w formacie timestamptz, a strefa czasowa każdego użytkownika zapisywana w osobnej kolumnie, aby przypomnienia przychodziły w czasie lokalnym.
18. Najpierw stosuje się miękkie usuwanie (soft delete), a RLS ukrywa również usunięte rekordy. Gdy konto jest usuwane, dane użytkownika są trwale usuwane.
19. Użytkownicy mogą eksportować własne dane.
20. Imiona z apostrofami, emoji lub tekstem od prawej do lewej nie powodują błędów w polach wprowadzania.
21. Obrazy używają formatów WebP lub AVIF, a treść poniżej widocznego obszaru ekranu jest ładowana podczas przewijania.
22. Dla pól najczęściej filtrowanych utworzono indeksy. Przy kilkudziesięciu testowych rekordach wszystko może działać szybko, ale przy rzeczywistych wolumenach danych pojawiają się spowolnienia.
23. Podłączono monitorowanie błędów, aby dowiadywać się o problemach przed użytkownikami.

Wyślij całą tę listę do agenta i dodaj na końcu następujący prompt. Agent sprawdzi każdy punkt i przedstawi wyniki w tabeli:

Rozdziel sprawdzenie między pięciu subagentów w następujących obszarach:

1. Design i wydajność.
2. Bezpieczeństwo.
3. Płatności.
4. Dane.
5. Działanie aplikacji po uruchomieniu.

Sprawdź wszystkie punkty, niczego nie zmieniając. Dla każdego punktu wskaż, czy sprawdzenie zakończyło się sukcesem, czy niepowodzeniem, oraz plik, w którym wykryto problem.

Jeśli coś można sprawdzić tylko w panelu usługi, oznacz punkt jako «Wymaga mojego potwierdzenia» i podaj instrukcję krok po kroku do ręcznego sprawdzenia.

Testuj kopie zapasowe i odtwarzanie tylko na testowej bazie danych, a płatności wyłącznie w trybie testowym. Nie zmieniaj danych produkcyjnych.

Najpierw pokaż mi tabelę wyników i niczego nie poprawiaj, dopóki nie potwierdzę.