API інтеграції плагінів тепер відкриває повний канонічний життєвий цикл пакшота. POST /api/v1/plugin/jobs приймає необов'язкове поле job_type (за замовчуванням photo_shoot, enum з CG_JOB_TYPES): запити з job_type='packshot' та auto_register_packshot=true створюють рядок у product_packshots, який потрапляє до каталогу й очікує на схвалення оператора. Існуючі ендпоінти POST /api/v1/plugin/jobs/{id}/accept|reject тепер каскадують голос на пов'язаний рядок каталогу для завдань типу packshot, тоді як для інших завдань голосування залишається чистими метаданими. Пакшоти, завантажені оператором через POST /api/v1/plugin/packshots, автоматично позначаються як прийняті при вставці — оператор сам ручається за вміст.
Новий бар'єр прийняття у фотосесії перевіряє, що кожен subject посилається на прийнятий пакшот для свого продукту. Коли бар'єр увімкнено, клієнт плагіна може не передавати packshot_asset_id у subjects фотосесії, а бекенд сам обирає найновіший прийнятий пакшот за product_ref; явні значення packshot_asset_id досі підтримуються, але перевіряються на відповідність тому ж продукту та стану «прийнято». Бар'єр впроваджується поступово — глобальний прапорець середовища PLUGIN_PHOTO_SHOOT_GATE_ENABLED за замовчуванням вимкнено, тож наявні інтеграції працюють без змін, а супер-адміністратори можуть увімкнути його для окремих облікових записів через POST /api/admin/plugin/accounts/{id}/photo-shoot-gate-toggle. Після глобального ввімкнення прапорця запити фотосесії без прийнятого пакшоту повертатимуть HTTP 422 packshot_not_approved — оператори плагінів мають перейти на явний крок генерації пакшота до цього моменту. Вебхук job.completed тепер містить поле job.job_type, тож бек-офіс плагіна може спрямовувати готові пакшоти до окремої черги перегляду.