# PROMPT: Audyt bazarowy-swiat.pl + brief projektowy redesignu sklepu Vilmax

## Rola i cel

Jesteś agentem audytującym działający sklep WooCommerce `bazarowy-swiat.pl` (hosting uti.pl/Plesk, subskrypcja pizzaforno.pl). Sklep sprzedaje obecnie dywany outletowe + meble tapicerowane Vilmax. Właściciel planuje rebranding i przebudowę — nazwa „Bazarowy Świat" jest uznana za słabą; docelowy sklep ma sprzedawać **outletowe dywany i meble tapicerowane Vilmax** na poziomie topowego e-commerce.

Twoje zadanie ma 3 etapy:

1. **Audyt całej strony i sklepu** — wejdź na produkcję, przejrzyj wszystko, wypunktuj słabe punkty techniczne i wizualne.
2. **Dokument stanu** — zapisz ustalenia w pliku.
3. **Prompt dla kolejnego czatu** — napisz kompletny design brief, z którego następny agent zaprojektuje nowy sklep (wygląd + treść + UX) na najwyższym poziomie.

---

## Dostępy

- **Sklep:** https://bazarowy-swiat.pl
- **WP admin:** https://bazarowy-swiat.pl/wp-admin — login `damianmalenta@gmail.com` — **hasło NIEAKTUALNE** (oba znane hasła odrzucane 2026-09-17; właściciel musi zresetować). Pracuj front-end + Woo REST; do zapisu w DB użyj phpMyAdmin przez Plesk (poniżej).
- **WooCommerce REST API:** Basic auth `consumer_key: ck_a7722a33bb021f66ea3409f1081792bcaf459437` / `consumer_secret: cs_53f932f86c815a006a862e6fd2a65711c5d33443` (read wystarczy; do audytu nie zmieniaj nic w API).
- **Plesk:** https://bazarowy-swiat.pl:8443 — login `pizzaf557`, hasło `Dammalq123123123@`. Antybot: czysty curl działa (POST `login_up.php3` z `login_name`+`passwd` → 303 + PLESKSESSID); przeglądarka headless zapętla wyzwanie — do UI używaj widocznego Chrome (Puppeteer `headless:false` + `--ignore-certificate-errors`) albo wstrzyknij ciasteczko PLESKSESSID.
- **phpMyAdmin (omija wp-admin):** Plesk → `smb/database/list/domainId/581` → rozwiń wiersz `wordpress_8` → kliknij „phpMyAdmin" (SSO, pełny odczyt+zapis DB: `wp_snippets`, `wp_template`, `wp_options`, `wp_users`). REST application passwords są zablokowane na sklepie (hardening), a WP Toolkit niedostępny w subskrypcji — PMA to główna ścieżka zapisu bez wp-admin.
- **BaseLinker:** token w `C:\xampp\htdocs\vilmax\vilmax-cockpit\.env` → `BASELINKER_API_TOKEN` (POST `https://api.baselinker.com/connector.php`). Tylko odczyt.
- **Repo motywu lokalnie:** `C:\xampp\htdocs\sklep_wodpress` → GitHub `DamianMalenta/sklep`, branch `main` (deploy key `.deploy_key` w repo). Repo Plesk: `sklep.git` na domenie `bazarowy-swiat.pl` (domainId 581, subskrypcja pizzaforno.pl, deploy do `/dywanowy-bazar.pl`).
- **Puppeteer:** moduł w `C:\xampp\htdocs\vilmax\vilmax-cockpit\node_modules\puppeteer` — screenshoty i testy UI.
- **Kontekst stanu:** `C:\xampp\htdocs\vilmax\vilmal\.devin\STAN.md` — przeczytaj wpis o naprawie OSKAR (2026-09-17), tam są ustalenia z ostatniej sesji.

---

## Kluczowa architektura — jak naprawdę działa produkcja

1. **Pliki motywu ≠ produkcja bezpośrednio.** Motyw `bazarowy-swiat/` jest wdrażany Plesk Git do `/dywanowy-bazar.pl/bazarowy-swiat/` (checkout), a akcją wdrożeniową kopiowany do `wp-content/themes/bazarowy-swiat/` — to sync ustawiony 2026-09-17.
2. **Szablony nadpisane rekordami w bazie** (Site Editor): homepage `wp_template` id **7719**, header **7720**, footer **7721**, single-product **7861** — edycja przez WP REST `/wp-json/wp/v2/templates`, nie przez pliki.
3. **PHP/JS/CSS produkcyjne żyją w Code Snippets** — snippet **20 „BS PDP v2"** (front-end, aktywny): `woocommerce_ajax_variation_threshold`=100, zakładki PDP (Opis/Specyfikacja/Dostawa i zwroty), font Inter, cały CSS PDP, swatche atrybutów + logika galerii wariantu (zsynchronizowana z `frontend.js`). Aktualizacja: Code Snippets REST (wymaga wp-admin) **albo UPDATE `wp_snippets.code` przez phpMyAdmin** (działa bez wp-admin).
4. **WP Super Cache** — czyścić po zmianach: POST `wp-admin/options-general.php?page=wpsupercache` z `wp_delete_cache=1` (wymaga wp-admin) albo jednorazowy blok `wp_cache_clear_cache()` w snippecie przez PMA; TTL ~1h też działa. Weryfikacja: komentarz `Cached page generated by WP-Super-Cache on <ts>` w HTML.
5. **BaseLinker = źródło prawdy katalogu** — produkty wypychane z panelu BL; push może nadpisywać atrybuty/opisy (znany problem na produkcie 7871).
6. **Produkt-wzór:** OSKAR TILIA, Woo ID **7871**, URL `/produkt/naroznik-oskar-tilia-warianty-l-p/` — 34 warianty (Strona L/P × 17 odcieni), PDP naprawiony 2026-09-17 (2 osie, swatche odcieni, **pełna galeria 8 ujęć per wariant** z CDN BL, stan 99 szt.).
7. **Checkout/płatności (naprawione 2026-09-17, redesign+fix 2026-09-18, commit `87132ff`):** `templates/page-checkout.html` = shortcode `[woocommerce_checkout]` (blok `wp:woocommerce/checkout` nie renderuje się); strona zamówienia `wp_posts` id **10** też na shortcode. Bramka: **Global Payments/eService 1.23.1** (`globalpayments_gpapi`, drop-in, production, BLIK + open banking; raty 0% NIE dostępne w tym interfejsie — decyzja właściciela: nie pokazywać). Custom selektor BLIK/Karta w `frontend.js` (`bs-pay-*`) z autentycznymi logotypami (`assets/img/logo_blik/visa/mc.png`) — POST `blik-payment=1` → natywny `Blik::process_blik_sale` → redirect `e.blik.com` (ZWERYFIKOWANE end-to-end: prawdziwa strona BLIK z polem kodu). KLUCZOWY mechanizm: plugin interceptuje submit przez `checkout_place_order_globalpayments_gpapi` → `initThreeDSecure` → `checkVersion` (bez tokenu karty = błąd „Not enough data to perform 3DS") — dla BLIK omijamy to inputem `#globalpayments_gpapi-checkout_validated=1` (early-return true w handlerze pluginu). Tłumaczenia: `pl_PL.po` wtyczki ma ~135 FR/ES msgstr (błąd upstream — **jedyna taka wtyczka**, audyt 15 katalogów innych pluginów czysty) + TranslatePress podmienia gettext @100 → fix = **pełna mapa EN→PL w `inc/gp-translations-pl.php`**, filtr `gettext` @999 w `functions.php`. Stopka: sekcja `bs-footer-pay` z **oficjalnym banerem eService z biblioteki mediów** (attachment 2826; oryginalna stopka Elementor 1523 używała 2825+2826) — plik `parts/footer.html` + rekord 7721 w DB. Skrypty na checkout/cart nie są deferowane. UWAGA na pułapkę: filtr `render_block_woocommerce/product-price` w functions.php wymaga `accepted_args=3` — mismatch spowodował fatal 500 (fix `87d370c`).

## Znane już ustalenia (nie raportuj jako „nowe znalezisko" bez weryfikacji)

- PDP OSKAR po naprawie działa poprawnie — ale sam fakt że wymagał naprawy mówi o procesie importu z BL.
- Zdjęcia: BL trzyma **pełne galerie 8 ujęć na każdy wariant** (272 zdjęcia, `getInventoryProductsData` po ID wariantu, CDN `upload.cdn.baselinker.com/products/5047759/`). Push do Woo przeniósł tylko 1 zdjęcie/wariant — galeria per kolor została zaimplementowana JS-em (mapa `BS_VAR_GALLERIES` w `frontend.js`, swap wszystkich 8 slajdów). Audyt: sprawdź czy mechanizm działa i czy zdjęcia CDN nie powinny być zimportowane do WP media.
- Stany w Woo = tylko magazyn BL `bl_91023` (`bl_91183` nie jest mapowany do sklepu).
- Na PDP występuje błąd konsoli `elementorFrontendConfig is not defined` (osierocony skrypt Elementora).
- Istnieje wtyczka yay-swatches (podgląd atrybutów jest ukrywany CSS-em — celowe, nie usuwać reguły w `custom.css`).
- `uti_pass.txt` w `~/.ssh` = login `stefanmalenta@` (DPAPI) — artefakt, nieaktualne.

---

## Zadanie 1 — Audyt (tylko odczyt; zero zmian produkcyjnych)

Przejdź sklep end-to-end, desktop **i** mobile (Puppeteer, screenshoty jako dowody). Obszary:

**Strony:** homepage, listing kategorii (dywany + meble), PDP (dywan + OSKAR), wyszukiwarka, koszyk, checkout (bez składania zamówienia — do momentu formularza), strony informacyjne (O nas, Kontakt, regulaminy, dostawa/zwroty), stopka, 404, menu mobilne, baner cookies.

**Techniczne:**
- błędy konsoli JS na każdej stronie (np. znany `elementorFrontendConfig`),
- wydajność: wielkość strony, liczba żądań, LCP-owe obrazy, czy zdjęcia mają wymiary/srcset/lazy-loading,
- zduplikowane/konfliktowe wtyczki (snippet 20 vs frontend.js vs yay-swatches vs Elementor),
- SEO: title/meta/schema.org, linki wewnętrzne, 404, kanibalizacja nazw,
- dostępność: kontrast, aria, fokus, alt-y,
- bezpieczeństwo: nagłówki, widoczne wersje, debug,
- spójność koszyka/checkout (waluty, metody dostawy, płatności),
- struktura kategorii i filtrów (dywany vs meble — czy da się sensownie filtrować),
- treść: jakość opisów, dublowane/puste treści, stuby z importów BL.

**Wizualne/UX:**
- hierarchia nagłówka, CTA, cen; spójność typografii i kolorów; jakość i jednorodność zdjęć (kadr, tło, proporcje),
- karty produktu na listingu, paginacja, puste stany,
- profesjonalizm PDP: galeria, warianty, cena, dostępność, trust badges, opis, specyfikacja,
- brand perception: czy sklep wygląda jak marka outletowo-premium czy jak magazyn wyprzedaży,
- mobile: nawigacja, tap targets, galerie, sticky CTA.

**Reguły audytu:** każda uwaga z dowodem (URL + screenshot + konkretny opis). Skala: krytyczne / ważne / kosmetyczne. Nie zgłaszaj rzeczy już naprawionych.

## Zadanie 2 — Dokument stanu

Zapisz `C:\xampp\htdocs\vilmax\vilmal\AUDYT_BAZAROWY_SWIAT.md`:

- streszczenie (3-5 zdań: co to jest dziś, główne problemy),
- tabela słabych punktów: obszar | problem | dowód (URL/screenshot) | waga | propozycja kierunku naprawy,
- sekcja „co jest dobre" (uczciwie — nie wszystko jest złe),
- sekcja „dane i proces" (BL→Woo, snippet vs repo, cache, Plesk) — stan faktyczny po tej sesji,
- lista rynek/standardów benchmarkowych do analizy w kolejnym kroku.

## Zadanie 3 — Prompt dla kolejnego czatu (design brief)

Napisz `C:\xampp\htdocs\vilmax\vilmal\PROMPT_REDESIGN_SKLEPU.md` — kompletny brief, z którego agent zaprojektuje nowy sklep. Ma zawierać:

- **Kontekst biznesowy:** outletowe dywany + meble tapicerowane Vilmax; nazwa „Bazarowy Świat" do zmiany; BaseLinker = katalog; WooCommerce może zostać lub być zastąpione — brief ma to ująć jako decyzję projektową;
- **Wymagania brandingu:** propozycje kierunków nazwy, ton komunikacji, pozycjonowanie (outlet ≠ tani śmieciak — jakość po niższej cenie), grupy docelowe;
- **Wymagania IA/UX:** struktura nawigacji (dywany vs meble = dwa światy), listing z filtrami (rozmiar/kolor/tkanina/kształt), PDP premium (galeria per wariant, specyfikacja, certyfikaty, dostawa gabarytów, zwroty), zaufanie (opinie, GPSR, produkcja PL), koszyk/checkout;
- **Wymagania wizualne:** kierunki estetyczne z referencjami (nazwij realne benchmarki e-commerce meblowego/dywany), typografia, siatka, fotografia produktowa (wzorzec: aranżacje jak na OSKAR), design system w skrócie;
- **Wymagania treści:** mapa treści (homepage sekcje, O nas/fabryka Vilmax, dziennik/poradniki, FAQ), język i styl;
- **Wymagania techniczne:** mobile-first, wydajność (budżet: LCP, waga strony), WCAG, SEO (schema, kategorie, landing pages), migracja danych z BL/Woo, co zostaje z obecnej infrastruktury (Plesk, BL, WP);
- **Dowody z audytu:** osadź w briefie najgorsze znaleziska jako „co eliminujemy" z konkretami.

## Czego NIE robić

- Nie zmieniaj nic na produkcji (ani snippetu, ani szablonów, ani produktów, ani BL) — to audyt, nie naprawa.
- Nie wyłączaj snippetu 20 — krytyczny dla PDP.
- Nie pushuj, nie deployuj, nie ruszaj zamówień i dywanów.
- Nie ujawniaj sekretów w dokumentach wyjściowych (w audycie opisuj dostępy słownie, nie wklejaj haseł/tokenów — prompt dla kolejnego okna może wskazywać lokalizacje, nie wartości).
- Nie rób nic z dispatch BL / publikacją Allegro — to odroczone decyzją właściciela.
- Nie udawaj oglądania — screenshoty obowiązkowe.

## Kryteria odbioru

- `AUDYT_BAZAROWY_SWIAT.md` kompletny, z dowodami, waga każdego punktu.
- `PROMPT_REDESIGN_SKLEPU.md` samowystarczalny — nowy agent musi z niego rozumieć biznes, dostępy, stan i oczekiwania bez pytania.
- Oba pliki po polsku, konkretne, bez ogólników typu „poprawić UX".
- Aktualizacja `.devin/STAN.md`: jeden wpis — co zrobiono, gdzie pliki, następny krok.