Klienci pluginowi nie muszą już ręcznie opisywać swoich produktów na potrzeby generacji treści. Gdy packshot zostanie zarejestrowany przez POST /plugin/packshots (lub przez dowolną inną mutację katalogu kończącą się stworzeniem packshotu), worker Qamery uruchamia teraz tę samą analizę obrazu opartą o Gemini, którą wykorzystuje aplikacja webowa, i zapisuje wynik do katalogu produktów: pola dotyczące zdjęcia (side_view, background_description, photo_quality, motion_visible, contains_text) trafiają do product_images, a pola dotyczące produktu (general_category, specific_category, description, characteristics) — do nadrzędnego rekordu w products przy pierwszym zapisie. Kolejne zadania generacji automatycznie odczytują te wartości z katalogu — nie trzeba już przekazywać product_name ani product_specific_category w treści żądania.
Wynikają z tego dwie zmiany kontraktowe. Po pierwsze, każdy packshot musi mieć teraz wpis w katalogu zanim zostanie złożone zadanie, które się do niego odwołuje: zadania, których settings.packshot_asset_id nie ma odpowiadającego wiersza w product_packshots, kończą się trwałym błędem z error_type='PLUGIN_JOB_MISSING_CATALOG_ENTRY'. Plugin musi najpierw zarejestrować zasób przez POST /plugin/packshots; jeśli packshot zostanie utworzony bez source_image_id, serwis sam dotworzy powiązany wiersz w product_images, aby analiza mogła się uruchomić. Po drugie, legacy'owe pola product_name, product_specific_category, product_side, product_general_category w cg_jobs.settings są oznaczone jako przestarzałe — wciąż parsują się dla zachowania zgodności wstecznej, ale worker je ignoruje i pobiera wszystkie metadane z katalogu Supabase. Zalecamy migrację na przepływ catalog-first przy pierwszej okazji; pola przestarzałe będą emitować strukturalny wpis ostrzegawczy w logach przy każdym żądaniu.