Przejdź do głównej zawartości

Zasady wzorców doświadczenia

Techniczny: DraftAkceptacja: Draft

Wzorzec opisuje powtarzalne zadanie klienta i zachowanie usługi: zebranie danych, oczekiwanie, porównanie, kontynuację, podpis albo płatność. Nie jest pojedynczym komponentem ani kopią aktualnego ekranu sklepu.

Źródłem są uzgodnione ścieżki JDG i zdrowia. Dla każdego wzorca pokaż: warunek wejścia, wiedzę klienta, dane systemu, treść, możliwe działania, wyjście oraz przypadek przerwania. Oddziel brak danych, błąd techniczny i rzeczywistą odmowę TU. Każdy z nich wymaga innego komunikatu i dalszego kroku.

Najpierw projektujemy docelowy przebieg. Zastane rozwiązania są materiałem do wykorzystania, nie warunkiem rozpoczęcia pracy ani wzorem do odtworzenia.

@todo(patterns): wykonać poniższy brief, przedstawić rezultat i dowody odbioru. Usunięcie znacznika nie jest wykonaniem zadania.

  • Zakres: Katalog wzorców wynika z docelowych ścieżek i wyjątków, nie tylko starego kodu. Każdy pokazuje stan, treść, działanie i dowód.
  • Konwencja: najpierw reguła lub gotowe zastosowanie, potem przykład i kontrprzykład, następnie granice oraz sposób sprawdzenia. Nie zastępuj materiału opisem planu jego przygotowania.
  • Źródła: platforma marki; zaakceptowane decyzje warsztatów. Zastane demo lub deklaracja PoC nie zatwierdzają nowej reguły.
  • Powiązania: Platforma marki, Mikrocopy i komunikaty operacyjne.
  • Granica swobody: możesz redagować i pokazywać istniejące ustalenia. Nową obietnicę, wybór wizualny, dane firmy i twierdzenie produktowe przedstaw do decyzji; nie uzupełniaj z pamięci.

Sprawdź rzeczywisty render i użycie wspólnego kodu, desktop/mobile, jasny/ciemny tryb oraz właściwe konteksty portali. Bramka techniczna: pnpm design:check; przed wydaniem także pnpm design:audit. Sam opis ani zielony test innego demo nie jest dowodem odbioru tego elementu.