Клієнтам плагінів більше не потрібно вручну описувати свої продукти для генерації контенту. Коли пакшот реєструється через POST /plugin/packshots (або через будь-яку іншу мутацію каталогу, що створює пакшот), воркер Qamera тепер запускає той самий аналіз зображення на основі Gemini, який використовується у вебзастосунку, і записує результат до каталогу продуктів: поля рівня зображення (side_view, background_description, photo_quality, motion_visible, contains_text) потрапляють до product_images, а поля рівня продукту (general_category, specific_category, description, characteristics) — до батьківського запису в products під час першого заповнення. Подальші завдання генерації автоматично зчитують ці значення з каталогу — більше не потрібно передавати product_name чи product_specific_category у тілі запиту.
З цього випливають дві зміни в контракті. По-перше, кожен пакшот тепер повинен мати запис у каталозі до того, як буде відправлено завдання, що на нього посилається: завдання, чий settings.packshot_asset_id не має відповідного рядка в product_packshots, остаточно завершуються помилкою з error_type='PLUGIN_JOB_MISSING_CATALOG_ENTRY'. Плагіни мають спочатку зареєструвати ресурс через POST /plugin/packshots; якщо пакшот створено без source_image_id, сервіс сам додасть відповідний рядок до product_images, щоб аналіз міг запуститись. По-друге, успадковані поля product_name, product_specific_category, product_side, product_general_category у cg_jobs.settings оголошено застарілими — вони все ще парсяться для зворотної сумісності, але воркер їх ігнорує і отримує всі метадані з каталогу Supabase. Радимо мігрувати на потік catalog-first якнайшвидше; застарілі поля емітуватимуть структурований попереджувальний запис у логах при кожному надсиланні.