DreamJeans Autopilot
Sklep DreamJeans codziennie dostaje setki nowych produktów z hurtowni — każdy rozmiar jako osobna, „surowa" pozycja, bez zdjęć i opisów. Ręczne doprowadzenie tego do sprzedaży zajmowałoby długie godziny każdego dnia. Zbudowaliśmy dla klienta autorski system, który robi to wszystko sam, w nocy. Rano właściciel otwiera jeden e-mail i w 30 sekund wie, co pojawiło się w sklepie i czy coś wymaga uwagi. To rozwiązanie szyte na miarę tego sklepu i jego integracji.
Schemat działania — krok po kroku
Nowy towar z hurtowni
Produkty spływają automatycznie z magazynu i Baselinkera — na razie jako pojedyncze rozmiary, bez zdjęć i opisów.
Łączenie rozmiarów
System scala wszystkie rozmiary jednego modelu w jeden produkt z wygodnym wyborem rozmiaru.
Zdjęcia produktów
Automatycznie pobiera oficjalne zdjęcia od producenta i podpina je do właściwych produktów i galerii.
Opisy i kategorie (AI)
Sztuczna inteligencja pisze unikalne opisy, dobiera kategorie i tagi — spójnie i pod SEO.
Kontrola jakości
Produkt bez zdjęcia lub opisu nie trafia na sklep — czeka i zostanie dokończony kolejnej nocy.
Publikacja
Gotowe, kompletne produkty pojawiają się w sklepie — od razu gotowe do sprzedaży.
Mail z podsumowaniem
Rano właściciel dostaje jeden czytelny raport: co dodano, co wymaga uwagi, kondycja sklepu.
Co to daje
Godziny pracy każdego dnia
Setki produktów miesięcznie przygotowywane bez ręcznego klikania — czas wraca do biznesu.
Działa, gdy sklep śpi
Cały proces dzieje się w nocy. Rano asortyment jest gotowy, bez porannego „zatoru".
Spójna, wysoka jakość
Każdy produkt z opisem, zdjęciem i kategorią. Nic niedokończonego nie ląduje na sklepie.
Szyte na miarę
Zbudowane pod konkretny sklep i jego integracje (Baselinker, hurtownia, producent).
Pełna kontrola i bezpieczniki
Wyłącznik awaryjny, brak nakładania się procesów i raport błędów — system pod kontrolą.
Szybciej na sprzedaż
Nowy towar trafia do sklepu następnego dnia, a nie po tygodniach ręcznej obróbki.
Szczegóły
Co dokładnie dzieje się każdej nocy
O ustalonej godzinie system uruchamia się sam i prowadzi nowy towar przez kolejne etapy: najpierw łączy luźne rozmiary w jeden produkt, potem pobiera zdjęcia od producenta, następnie zleca sztucznej inteligencji napisanie opisów oraz dobór kategorii i tagów, a na końcu publikuje tylko te produkty, które są kompletne. Wszystko dzieje się małymi porcjami, żeby niczego nie przeciążyć — proces jest wznawialny i sam pilnuje kolejności.
Z czego zbudowany jest system
To zestaw współpracujących modułów, każdy odpowiada za jeden etap: łączenie wariantów, pobieranie zdjęć, generowanie opisów przez AI, bramka jakości (ukrywa niekompletne produkty) oraz monitor kondycji sklepu. Nad wszystkim czuwa „dyrygent" — Autopilot — który uruchamia je w odpowiedniej kolejności i zbiera wyniki w jeden raport. Dzięki temu, że moduły są niezależne, system jest stabilny i łatwy do rozwijania.
Bezpieczeństwo i kontrola
Właściciel ma pełną kontrolę: jest wyłącznik awaryjny (kill-switch), zabezpieczenie przed nakładaniem się dwóch procesów oraz tryb testowy na żądanie. Błąd przy jednym produkcie (np. brak zdjęcia u producenta) nie przerywa całej nocy — zostaje zapisany w raporcie, a produkt wraca do kolejki następnym razem. Każdy poranny e-mail zawiera też krótki „stan zdrowia" sklepu.
Dla zainteresowanych — jak to wygląda „pod maską". Autopilot to osobna wtyczka-orkiestrator, która nie duplikuje logiki, tylko dyryguje istniejącymi, niezależnymi silnikami. Stan procesu trzyma w bazie (maszyna stanu), a pracę rozkłada na wiele krótkich zadań kolejki Action Scheduler — żaden etap nie jest jednym długim procesem, który host mógłby ubić. Wyzwalany jest realnym cronem systemowym przez WP-CLI o stałej godzinie (nie WP-Cron, który odpala się tylko przy ruchu).
Architektura: orkiestrator + niezależne silniki
Autopilot wywołuje headless (bez nonce i kontekstu zalogowanego admina) cztery silniki: wc-variant-linker (scan_new → create_variants), bs-image-linker (cdn_prepare → fetch_batch z budżetem ~60 s i wznawianiem przez next_offset), woo-ai-generator (get_products → generate_product z retry i walidacją języka) oraz hide-products-no-image (pasywna bramka czytająca _wag_status, zdjęcie i długość opisu). Silniki są niezależne i spięte meta-kluczami _GLOBAL / _wag_status — całość jest stabilna i łatwa do rozwijania.
Maszyna stanu i kolejka zadań
Proces to twarda sekwencja etapów: warianty → zdjęcia → opisy → widoczność. Każde wywołanie przetwarza jedną paczkę i przeplanowuje siebie (as_enqueue_async_action), aż kolejka etapu się opróżni — wtedy następuje przejście do kolejnego etapu. Dodatkowo bramkowanie per-produkt: etap AI pomija produkt bez zdjęcia, który wróci następnej nocy. Dzięki temu mieścimy się w limitach czasu hosta i proces jest w pełni wznawialny.
Odporność na błędy i telemetria
Każdy element paczki jest w try/catch — błąd (np. brak zdjęcia na CDN producenta albo chwilowy błąd sieci) trafia do stats.errors[] z kontekstem (produkt, etap, treść), a pętla jedzie dalej, zamiast wywalać całą noc. Telemetria rozróżnia „brak na CDN" (placeholder) od realnego błędu sieci. Bezpieczniki: kill-switch, blokada nakładania się runów oraz tryb dry-run na żądanie.
Dane, grupowanie i raport
Rodziny produktów grupujemy po pierwszym tokenie nazwy (stabilny HEAD), bo integracja zaczęła wsuwać EAN-13 jako SKU i zepsuła grupowanie po SKU — to autorski workaround dopasowany do realiów sklepu. Rozmiary rozpoznaje 5 wzorców variant-linkera. Raport to mail HTML (wp_mail) do wielu odbiorców, ze snapshotem kondycji bazy (db-health) w stopce; historia runów ląduje w tabeli wp_djap_runs.