Plugin clients no longer need to describe their products by hand for content generation. When a packshot is registered via POST /plugin/packshots (or via any catalog mutation that produces a packshot), the Qamera worker now runs the same Gemini-based image analysis used by the in-app flow and writes the result to the product catalog: image-level fields (side_view, background_description, photo_quality, motion_visible, contains_text) land on product_images, and product-level fields (general_category, specific_category, description, characteristics) land on the parent products row the first time they are populated. Subsequent generation jobs read these values from the catalog automatically — no product_name or product_specific_category needs to be passed in the job body anymore.
Two contract changes follow from this. First, every packshot must now have a catalog entry before a job that references it is submitted: jobs whose settings.packshot_asset_id has no matching product_packshots row fail permanently with error_type='PLUGIN_JOB_MISSING_CATALOG_ENTRY'. Plugins must register via POST /plugin/packshots first; if a packshot is created without a source_image_id, the service auto-creates a backing product_images row so analysis can run. Second, the legacy product_name, product_specific_category, product_side, product_general_category fields inside cg_jobs.settings are deprecated — they still parse for backward compatibility but are ignored by the worker, which now sources all metadata from the Supabase catalog. Migrate to the catalog-first flow at your earliest convenience; deprecated fields will emit a structured warning log entry per submission.