API integracji wtyczek odsłania teraz pełny przepływ cyklu życia packshota znany z kanonicznego flow w aplikacji. POST /api/v1/plugin/jobs przyjmuje opcjonalne pole job_type (domyślnie photo_shoot, enum z CG_JOB_TYPES): zgłoszenia z job_type='packshot' i auto_register_packshot=true tworzą wiersz w product_packshots, który trafia do katalogu w oczekiwaniu na akceptację operatora. Istniejące endpointy POST /api/v1/plugin/jobs/{id}/accept|reject propagują teraz głos na powiązany wiersz katalogu dla zadań typu packshot, natomiast dla pozostałych zadań głosowanie pozostaje czystą metadaną. Packshoty przesyłane bezpośrednio przez operatora (POST /api/v1/plugin/packshots) są od razu akceptowane przy zapisie — operator ręczy za przesłaną zawartość.
Nowa bramka akceptacji w sesji zdjęciowej weryfikuje, że każdy subject odwołuje się do zaakceptowanego packshota dla swojego produktu. Gdy bramka jest włączona, klient wtyczki może pominąć packshot_asset_id w subjectach sesji zdjęciowej, a backend sam wybiera najnowszy zaakceptowany packshot na podstawie product_ref; jawne wartości packshot_asset_id nadal są honorowane, ale weryfikowane pod kątem tego samego produktu i statusu akceptacji. Bramka jest wdrażana stopniowo — globalna flaga środowiskowa PLUGIN_PHOTO_SHOOT_GATE_ENABLED jest domyślnie wyłączona, dzięki czemu istniejące integracje działają bez zmian, a super-administratorzy mogą włączyć ją dla wybranych kont poprzez POST /api/admin/plugin/accounts/{id}/photo-shoot-gate-toggle. Po globalnym włączeniu flagi zgłoszenia sesji zdjęciowych bez zaakceptowanego packshota będą zwracać HTTP 422 packshot_not_approved — operatorzy wtyczek powinni przed tym wdrożeniem przyjąć jawny etap packshota. Webhook job.completed zawiera teraz pole job.job_type, dzięki czemu panel wtyczki może kierować ukończone packshoty do osobnej kolejki do przeglądu.