# Własny wygląd Shop Engine z pomocą Claude Code Praktyczny przewodnik: od briefu i materiałów marki do sprawdzonej zmiany strony głównej, listingu i karty produktu. Pracujesz na własnej kopii kodu, lokalnej bazie demonstracyjnej i osobnej gałęzi Git. Celem jest wygląd sklepu; ceny, podatki, dostępność, zamówienia i płatności zachowują dotychczasowe działanie. **Status materiału:** dokument przygotowany do dołączenia do wydania. Obecnie znajduje się w repozytorium strony 1282.pl; przed obietnicą „przewodnik w paczce” trzeba włączyć go do finalnej paczki Shop Engine, sprawdzić zgodność z jej wersją i zaktualizować manifest wydania. Sam ten plik nie zmienia istniejących ZIP-ów ani licencji. Mapa kodu została sprawdzona dla Shop Engine `0.1.2-rc.1`, commit `5d9f8f20410b7ca850980cee8f0cad3c7a91cf6f`. Wszystkie ścieżki poniżej są względne wobec katalogu **Shop Engine**, nie repozytorium 1282.pl. To instrukcja oparta na odczycie kodu; podczas jej przygotowania nie uruchamiano Claude Code ani poniższych komend instalacyjnych i testowych. Wyniki konkretnego wydania sprawdzaj w jego raporcie weryfikacji. ## 1. Co można zmienić i czego potrzebujesz Najpierw wykorzystaj istniejący panel na instalacji demonstracyjnej: | Zmiana | Miejsce w panelu | Co rzeczywiście istnieje | |---|---|---| | Paleta i sezonowy wygląd | `/admin/wyglad` — Szaty graficzne | Kopiowanie motywu, siedem kolorów, zestaw banerów i wygląd paska. Zapis motywu jest oddzielony od przycisku „Włącz na stronie”; zestaw bazowy jest chroniony. | | Logo, nagłówki i krótkie treści | `/admin/tresci-witryny` | Pola treści dla marki, korzyści, kategorii, polecanych produktów, bloga i stopki. | | Banery | `/admin/banery` | Zestawy banerów, kolejność, adresy docelowe i osobna grafika na telefon. | | Nawigacja | `/admin/menu` | Konfiguracja istniejącego menu. | Przestawienie sekcji strony głównej, nowy układ zdjęć produktu, gęstość listingu czy inna typografia wymagają pracy w komponentach React/Tailwind. Claude Code może pomóc czytać i zmieniać ten kod, ale rezultat wymaga przeglądu i testów. To nie jest gwarancja dowolnej przebudowy jednym poleceniem. Potrzebne są: podstawy terminala i Git, osoba umiejąca ocenić zmianę w React/TypeScript, własne materiały marki oraz środowisko opisane w `README.md` i `docs/instalacja.md`. **Uzgodniony model produktu:** jednorazowy zakup obejmuje kod źródłowy i bezterminowe korzystanie z zakupionej wersji, na własnym hostingu, z możliwością samodzielnej instalacji i dalszego rozwoju. Korzystanie z tej wersji nie wymaga wykupienia miesięcznej opieki. Opcjonalna opieka jest płatna miesięcznie; jej cena, zakres i ewentualne SLA wymagają osobnego uzgodnienia. Zakup nie obejmuje hostingu ani obietnicy bezpłatnych dożywotnich aktualizacji lub wsparcia. Zakup nie przenosi autorskich praw majątkowych i nie przyznaje prawa do odsprzedaży ani sublicencjonowania kodu. Nie zakładaj też automatycznie prawa do wdrożeń dla klientów. Szczegóły licencji trzeba zawrzeć w finalnych dokumentach wydania; techniczna możliwość modyfikacji nie rozszerza tych praw. Przed wydaniem należy dostosować `docs/licencje-i-prawa.md` w paczce do zatwierdzonego modelu oraz pozostałych uzgodnień. Ten przewodnik nie zastępuje licencji. Narzędzie nazywa się **Claude Code**. Ten przewodnik opisuje pracę nad wyglądem przy jego użyciu, a nie osobny produkt „Claude Code Design”. Konto/subskrypcja lub rozliczenie API narzędzia AI, hosting sklepu, domena i usługi zewnętrzne wymagają osobnej konfiguracji i kosztów; nie są zapewniane przez ten przewodnik. Sposoby dostępu opisuje [oficjalny quickstart Claude Code](https://code.claude.com/docs/en/quickstart). ## 2. Przygotuj brief i materiały Zapisz krótki brief, np. w lokalnym `docs/design-brief.md`: ```text Marka: [nazwa i charakter: spokojna / techniczna / premium / inny] Odbiorca: [kto kupuje i na jakim urządzeniu] Asortyment: [rodzaje produktów, warianty, typowe długości nazw] Cel tej iteracji: [np. lepsza ekspozycja zdjęć na karcie produktu] Strony objęte zmianą: [home, listing, karta produktu] Kolory i fonty: [własne wartości i licencje materiałów] Materiały: [lokalne ścieżki do logo i zdjęć] Inspiracje: [2–3 przykłady oraz konkret: typografia, rytm, galeria] Elementy zachowane: [wyszukiwarka, menu, koszyk, informacje o cenie] Poza zakresem: ceny, VAT, promocje, stany, koszyk jako model danych, checkout, dostawa, płatności, uprawnienia, dokumenty prawne i integracje. Odbiór: desktop i telefon; brak regresji; porównanie przed/po. ``` Przy inspiracjach opisz, **co** jest dobre, np. „duże zdjęcie obok krótkiej specyfikacji”. Nie zlecaj kopiowania cudzej marki, tekstów ani zdjęć. Przygotuj własne lub odpowiednio licencjonowane logo, zdjęcia i fonty. Zdjęcia towaru mają przedstawiać rzeczywisty produkt. Przykładowa realizacja Gardpol ma własny branding i rozszerzenia; nie wszystkie jej ekrany należą do standardowej paczki Shop Engine. Zrób lokalne zrzuty obecnego wyglądu: home, kategoria, produkt, koszyk — desktop oraz telefon. Używaj danych demo, bez danych klientów, panelu produkcyjnego i sekretów. Claude Code może analizować wskazany lokalny plik obrazu; sposób podania ścieżki lub dołączenia obrazu opisują [oficjalne przykłady pracy z obrazami](https://code.claude.com/docs/en/common-workflows#work-with-images). ## 3. Lokalna kopia, osobna gałąź i syntetyczna baza Przeczytaj `AGENTS.md`, `CLAUDE.md`, `docs/rozwoj-z-ai.md` i `docs/architektura.md` dostarczone z paczką. `CLAUDE.md` importuje zasady z `AGENTS.md`. Nie podłączaj katalogu produkcyjnego, jego `.env`, kopii bazy klientów ani wolumenów z danymi. ### Kod W lokalnym repozytorium sprawdź stan i utwórz nową gałąź: ```bash git status --short git switch -c design/wlasna-marka git rev-parse HEAD ``` Zapisz bazowy commit w swoich notatkach. Jeśli są istniejące zmiany, najpierw ustal ich właściciela i zakres; nie cofaj ich. Jeśli pracujesz z ZIP-em bez `.git`, utwórz repozytorium lokalne i commit bazowy z samymi źródłami przed rozpoczęciem edycji. Sprawdź `.gitignore`: `.env`, dane działania i wyniki testów nie mogą przypadkiem trafić do commitu. Nie używaj automatycznego `git add .` bez przeglądu plików. ### Środowisko deweloperskie Wymagania tej wersji: Node.js 22 oraz PostgreSQL 16. Przykład poniżej korzysta z już zainstalowanego Dockera wyłącznie do nowej bazy. Jeżeli brakuje narzędzi, potrzebny jest osobny krok instalacji — nie zlecaj agentowi instalowania lub podmieniania usług systemowych przy okazji zmiany wyglądu. Sprawdź, czy porty `55432` i `3100` oraz nazwa kontenera `shop-design-db` są wolne. W przypadku kolizji wybierz inne wartości i dostosuj adresy; nie zatrzymuj nieznanej usługi. ```bash docker run -d --name shop-design-db \ -e POSTGRES_USER=shop \ -e POSTGRES_PASSWORD=design_local_only \ -e POSTGRES_DB=shop_design_demo \ -p 127.0.0.1:55432:5432 \ postgres:16-alpine docker exec shop-design-db pg_isready -U shop -d shop_design_demo ``` `design_local_only` to jawne hasło wyłącznie tej lokalnej bazy demonstracyjnej. Kontener nie korzysta z istniejącego wolumenu sklepu. Nie używaj tego hasła ani tej bazy w produkcji. W nowej kopii źródeł zainstaluj zależności z lockfile: ```bash npm ci ``` Skopiuj `.env.example` do `.env` **tylko jeśli `.env` jeszcze nie istnieje**. W lokalnym edytorze uzupełnij ustawienia demonstracji; nie wklejaj zawartości `.env` do rozmowy z AI: ```dotenv APP_ENV=development SITE_INDEXING=off SITE_URL=http://127.0.0.1:3100 DATABASE_URL=postgresql://shop:design_local_only@127.0.0.1:55432/shop_design_demo SHOP_NAME=Sklep demonstracyjny MAIL_DISABLED=1 AUTOPAY_ENABLED=false P24_ENABLED=false INPOST_SHIPX_ENABLED=false ERP_API_ENABLED=false ERP_WRITE_ENABLED=false ``` Dla `ADMIN_SESSION_SECRET` wygeneruj osobną losową wartość lokalną, np. `openssl rand -hex 32`, i wpisz ją wyłącznie do `.env`. Nie jest to klucz produkcyjny. Pozostaw puste dane kont operatorów, SMTP, InPost i ERP. Nie włączaj tagów marketingowych. Do samego projektowania nie potrzeba rachunku bankowego ani aktywnego przelewu; ich brak może celowo blokować finalizację zamówienia. Nie zmieniaj podatków ani cen demo w ramach pracy nad wyglądem. Nie wywołuj formularzy podłączających zewnętrzne usługi. Sprawdź też, czy bieżący terminal nie dziedziczy produkcyjnego `DATABASE_URL` lub innych ustawień — zmienne procesu mogą mieć pierwszeństwo przed `.env`. Dopiero po potwierdzeniu adresu **nowej lokalnej bazy** wykonaj: ```bash npm run config:check npm run db:migrate npm run db:seed npm run owner -- create --email design@example.invalid --name "Administrator demo" npm run dev -- --hostname 127.0.0.1 --port 3100 ``` Seed tworzy syntetyczny katalog. Polecenie `owner` tworzy pierwsze lokalne konto administratora i jednorazowo pokazuje jego hasło — zapisz je prywatnie. Nie wykonuj resetu hasła istniejącej osoby. Nie uruchamiaj `npm run worker` ani całego stosu Compose do ćwiczenia wyglądu; proces w tle nie jest tu potrzebny. Sklep: `http://127.0.0.1:3100/`, panel: `http://127.0.0.1:3100/admin/login`. W drugim terminalu sprawdź: ```bash curl --fail http://127.0.0.1:3100/api/health curl --fail http://127.0.0.1:3100/robots.txt ``` Oczekuj poprawnego zdrowia bazy i blokady indeksowania. Następnie obejrzyj stronę w przeglądarce. Sam status HTTP nie potwierdza poprawnego wyglądu. ## 4. Gdzie zmieniać wygląd | Obszar | Pliki w Shop Engine | Granica zmiany | |---|---|---| | Paleta motywu | `src/lib/storefrontThemes/config.ts`, `src/lib/storefrontThemes/server.ts` | Siedem kolorów: `accent`, `hover`, `soft`, `background`, `paper`, `surface`, `ink`. Najpierw użyj panelu; nie zmieniaj zapisu, blokad i aktywacji motywów do kosmetycznej poprawki. | | Tokeny i style wspólne | `src/app/globals.css` | Tailwind 4 i zmienne `--shop-*`. Opublikowany motyw z bazy nadpisuje kolory domyślne, więc zmiana samego fallbacku nie musi być widoczna. Część kolorów i odstępów jest też w komponentach. | | Font | `src/app/layout.tsx`, `src/app/fonts/` | Lokalny Sora i zmienna `--font-sora`. Przy innym foncie dodaj legalny plik i zachowaj polskie znaki oraz czytelność. Nie zmieniaj metadanych, konfiguracji publicznej ani noindex przy okazji typografii. | | Rama sklepu | `src/app/(shop)/layout.tsx`, `src/components/shop/ShopFrame.tsx` | Nagłówek, stopka, treść. Zachowaj `ShopStateProvider`, obsługę zgód i konfigurację. | | Nagłówek i menu | `src/components/shop/SiteHeader.tsx`, `MainNav.tsx`, `HeaderActions.tsx`, `SearchBox.tsx` | Układ logo, wyszukiwarki i nawigacji. Nie gub koszyka, stanów rozwinięcia i obsługi klawiatury. | | Strona główna | `src/app/(shop)/page.tsx`, `src/components/shop/BannerCarousel.tsx`, `CategoryMosaic.tsx`, `BestsellersShelf.tsx`, `HomeBottom.tsx` | Kompozycja, proporcje zdjęć, hierarchia sekcji. Treści pochodzą z istniejącej konfiguracji i katalogu. | | Kategorie i kafle | `src/components/shop/views/CategoryView.tsx`, `src/components/shop/SeriesBrowser.tsx`, `ProductCard.tsx` | Siatka, odstępy i czytelność filtrów. Zachowaj zapytania, grupowanie wariantów, sortowanie i paginację. | | Karta produktu | `src/components/shop/pdp/ProductPdp.tsx` | Galeria, opis, specyfikacja i układ. Ten plik zawiera również ilości, warianty i akcję koszyka — modyfikuj prezentację, nie algorytmy. | | Wspólne przyciski | `src/components/ui/Button.tsx` | Warianty `primary`, `secondary`, `ghost`. Zachowaj `disabled`, `loading`, semantykę i istniejące akcje. Zmiana ma szerszy zasięg niż jedna strona. | Nie edytuj w zadaniu graficznym: `prisma/schema.prisma`, migracji, `src/lib/money.ts`, `vat.ts`, `shipping.ts`, `inventory.ts`, `couponEngine.ts`, `orders/`, `payments/`, `proforma/`, `src/app/(shop)/zamowienie/actions.ts`, endpointów płatności, logiki `ShopState.tsx` ani uprawnień. Gdy nowy układ rzeczywiście potrzebuje zmiany zachowania, wyodrębnij ją jako osobne zadanie z własną zgodą i testami. ## 5. Krótkie iteracje z Claude Code Korzystaj z własnego zatwierdzonego konta i konfiguracji. Instalację, jeśli jest potrzebna, wykonuj według [oficjalnej instrukcji](https://code.claude.com/docs/en/quickstart). Claude Code uruchomiony lokalnie nadal przekazuje kontekst do modelu przez sieć; lokalny terminal nie oznacza pracy offline. Przed użyciem ustal, czy wolno przetwarzać ten kod i obrazy u wybranego dostawcy. Zasady zależą od konta i ustawień — [dokumentacja wykorzystania danych](https://code.claude.com/docs/en/data-usage). Nie udzielono takiej zgody przez samo dostarczenie tego przewodnika. Poniższe polecenia są instrukcją do późniejszego użycia, nie zostały uruchomione przy przygotowaniu materiału. Dostępne flagi sprawdzisz przez `claude --help`; wersję przez `claude --version`. Analizę rozpocznij z katalogu lokalnej kopii sklepu: ```bash claude --permission-mode plan ``` Tryb planowania służy analizie i uzgodnieniu zmian przed edycją. Po zaakceptowaniu planu wybierz zwykły tryb z potwierdzaniem działań; do nowej sesji można użyć `claude --permission-mode default`. Nie używaj `--dangerously-skip-permissions`. Nazwy poleceń i trybów sprawdzono w [referencji CLI](https://code.claude.com/docs/en/cli-reference) i [opisie uprawnień](https://code.claude.com/docs/en/permissions), 26 października 2026 r. ### Prompt 1 — diagnoza i plan ```text Przeczytaj AGENTS.md, CLAUDE.md, docs/architektura.md, docs/rozwoj-z-ai.md i mój docs/design-brief.md. Pracujemy wyłącznie na kopii deweloperskiej. Przeanalizuj lokalne obrazy inspiracji wskazane w briefie oraz obecne UI. Zaproponuj jeden spójny kierunek: hierarchia, typografia, odstępy, zdjęcia, mobile. Wskaż, co da się zrobić w panelu, a co wymaga kodu. Podaj minimalną listę plików i sposób odbioru. Jeszcze nie edytuj. Nie czytaj .env, sekretów, danych klientów ani kopii bazy. Nie łącz się z produkcją. Bez zmiany cen, VAT, rabatów, stanów, checkoutu, płatności, uprawnień, integracji i treści prawnych. Bez nowych zależności, wysyłek, push, deploy ani udostępniania repozytorium. ``` ### Prompt 2 — jedna widoczna zmiana ```text Wykonaj zaakceptowany pierwszy etap: [np. galeria i układ karty produktu]. Edytuj tylko: [uzgodnione pliki]. Zachowaj dane, propsy, akcje, walidację i stany disabled/loading. Użyj istniejących tokenów i komponentów. Przed zmianą API Next.js sprawdź dokumentację tej zainstalowanej wersji w node_modules/next/dist/docs/. Nie zmieniaj zależności ani bazy. Uwzględnij telefon, długie nazwy, brak zdjęcia i brak stanu magazynowego. Nie dokładaj fikcyjnych opinii, efektów sprzedaży lub obietnic dostawy. Pokaż diff i wyjaśnij zmianę. Uruchom adekwatne dostępne testy lokalne, bez zewnętrznych usług. Każdy nieuruchomiony test oznacz NOT RUN. Nie commituj ani nie publikuj samodzielnie. ``` ### Prompt 3 — odbiór i regresje ```text Oceń rezultat względem briefu i lokalnych zrzutów przed/po przy szerokościach 390 oraz 1366 px; dodatkowo sprawdź 320 i 768 px. Obejrzyj rzeczywiste piksele w dostępnej przeglądarce albo wskaż, czego nie możesz sprawdzić. Sprawdź menu, wyszukiwarkę, galerię, warianty, ilość, dodanie/usunięcie, odświeżenie koszyka i Back/Forward na danych demo. Sprawdź Tab, focus, Escape w otwieranych panelach, opisy obrazów i brak poziomego przewijania. Zrób przegląd diffu pod kątem przypadkowej zmiany logiki cen i zamówień. Nie uruchamiaj pełnego E2E, dopóki nie potwierdzimy osobnego środowiska testowego i bezpiecznej konfiguracji jego syntetycznych zamówień. Podaj PASS / FAIL / BLOCKED / NOT RUN oraz konkretne dowody. ``` Najpierw odbierz jedną stronę. Dopiero później przenieś zatwierdzony rytm, kolory i elementy do pozostałych ekranów. Nie uruchamiaj dwóch agentów edytujących te same pliki jednocześnie. ## 6. Weryfikacja przed przyjęciem zmiany Standardowe komendy istnieją w `package.json` tej wersji: ```bash npm run lint npm run typecheck npm test npm run build ``` Wykonuj je na lokalnej konfiguracji z bazy demo. Nie przepisuj historycznych wyników z raportu wydania jako wyniku własnej zmiany. `npm test` bez bazy integracyjnej nie zastępuje testów integracyjnych. Build sprawdza również typy testów; `npm run build` buduje Next.js i skrypty operacyjne. Na krótką pętlę pracy można uruchomić istniejące testy wybranego obszaru, np.: ```bash npm test -- src/components/shop/pdp/ProductPdp.test.tsx src/components/ui/Button.test.tsx npm test -- src/components/shop/MainNav.test.tsx src/components/shop/SeriesBrowser.test.tsx npm test -- src/lib/storefrontThemes/server.test.ts src/lib/storefrontThemes/activation.test.ts ``` Po zmianie wspólnych elementów wykonaj pełną kontrolę powyżej. Testy DOM nie zastępują oceny wyglądu w przeglądarce. ### Integracja i pełny przebieg zakupowy Jeśli praca dotknęła zachowania koszyka, zamówień, stanów, kuponów lub płatności, przerwij etap graficzny i zatwierdź osobny zakres. W takim zadaniu obowiązują także testy integracyjne na **nowej pustej bazie**, innej niż baza podglądu: ```bash docker exec shop-design-db createdb -U shop shop_design_test_01 TEST_DATABASE_URL=postgresql://shop:design_local_only@127.0.0.1:55432/shop_design_test_01 npm run test:integration ``` Jeśli nazwa już istnieje, nie kasuj jej; wybierz nową. Skrypt `tools/run-integration-tests.mjs` akceptuje localhost i nazwę ze słowem `test`, stosuje migracje i uruchamia integracje kolejno. Same testy zapisują oraz czyszczą dane testowe — dlatego wymagana jest świeża baza, nie baza działającego sklepu. `npm run test:e2e` istnieje, ale **nie jest testem tylko do odczytu**: tworzy zamówienia, zmniejsza stany i zakłada konto pracownika. Wymaga działającej instalacji z seedem, testowego administratora, Playwright i Chromium oraz konfiguracji demonstracyjnego odbioru osobistego/przelewu. Playwright nie jest zależnością tej paczki. Jeżeli nie jest dostępny, oznacz test jako BLOCKED do czasu przygotowania narzędzia; nie instaluj go ukradkiem ani nie podłączaj produkcji. Po przygotowaniu osobnej instalacji E2E, wyłączeniu wysyłki i integracji oraz prywatnym ustawieniu `E2E_ADMIN_EMAIL` i `E2E_ADMIN_PASSWORD` na **konto testowe**: ```bash E2E_BASE_URL=http://127.0.0.1:3100 npm run test:e2e ``` Użyj tu adresu rzeczywistej instalacji E2E — przykład `3100` jest poprawny tylko wtedy, gdy właśnie ona działa na tym porcie. Skrypt nie wymusza lokalnego adresu, więc sprawdź go sam. Wymagany fixture przelewu nie oznacza przelewu bankowego: brak prawdziwego rachunku, operatora i wysyłki. Jeżeli bezpieczny fixture nie jest przygotowany, nie traktuj samego podglądu z sekcji 3 jako kompletnego środowiska E2E. Raport i screenshoty trafiają domyślnie do `e2e-results/`; nie dodawaj ich do publicznego repozytorium bez przeglądu danych. Odbiór wizualny obejmuje co najmniej: home, kategorię z filtrami, produkt z wariantem dostępnym i niedostępnym, koszyk pełny i pusty, długie nazwy, zmienne proporcje zdjęć, focus i obsługę klawiatury. Potwierdź, że po zmianie CSS nadal widać wymagane informacje o cenie i promocji. Nie poprawiaj testu przez usunięcie asercji chroniącej zachowanie. Strony panelu mogą renderować treść po zdarzeniu `load`; czekaj na konkretny element. Projekt wysyła sygnały obecności, dlatego nie opieraj oczekiwania wyłącznie na `networkidle`. ## 7. Zapis wyniku i powrót do poprzedniego wyglądu ```bash git diff --stat git diff --check git diff git status --short ``` Przejrzyj każdy plik. Dodaj do commitu tylko zaakceptowane źródła i materiały, wskazując je jawnie w `git add`. Zapisz mały commit z opisem wyglądu i wynikiem testów. Oddziel raport z lokalnymi zrzutami od paczki przeznaczonej dla klientów; skontroluj dane i prawa do wszystkich dołączanych obrazów. - **Zmiana w panelu:** wróć do zapisanego poprzedniego motywu i użyj jego aktywacji. Git nie cofa ustawień zapisanych w bazie. Logo, treści i inne ustawienia spoza motywu wymagają osobnego odtworzenia zapisanych wartości. - **Własny commit z kodem:** na czystej gałęzi `git revert ` tworzy kontrolowany commit cofający; przejrzyj go i ponów właściwe kontrole. Nie cofaj cudzych zmian. - **Niezacommitowana próba:** najpierw zachowaj diff; cofaj tylko konkretne własne zmiany. Nie używaj `git reset --hard`, `git clean -fd` ani resetowania bazy jako sposobu powrotu do poprzedniego wyglądu. Podgląd `npm run dev` zatrzymasz przez `Ctrl+C` w jego terminalu. Po zakończeniu możesz zatrzymać wyłącznie utworzony na potrzeby tego ćwiczenia kontener: `docker stop shop-design-db`. Do ponowienia: `docker start shop-design-db`, a następnie uruchom serwer deweloperski. Nie usuwaj kontenera ani jego danych, dopóki są potrzebne do przeglądu. Przed publikacją potrzebne są osobny przegląd, kopia docelowej instalacji i decyzja właściciela o wdrożeniu. Uzgodniony model jednorazowego zakupu i bezterminowego korzystania z zakupionej wersji trzeba odzwierciedlić w finalnej licencji oraz dokumentach zamówienia. Nadal wymagają uzgodnienia cena końcowa, podatki, zakres nabywców oraz cena i warunki opcjonalnej opieki. Akceptacja projektu graficznego nie uruchamia sprzedaży. Przed dodaniem tego przewodnika do opisu oferty sprawdź, czy faktycznie znajduje się w finalnej paczce, a wskazane pliki i komendy odpowiadają jej wersji.