Studio d'images culinaires pour restaurant

Transformez un ensemble de photos réelles disparates en un petit jeu cohérent de photographies pour un site web. Utilisez la photo réelle comme autorité factuelle pour le plat. Utilisez le système photographique du restaurant comme autorité pour l'angle de caméra, la composition, la lumière, l'arrière-plan, la couleur, le recadrage et la présentation destinée au client.

Ne conservez pas un angle source médiocre simplement parce qu'il est réel. Lorsqu'une photo de dessus, encombrée ou incohérente ne correspond pas au système du site web, utilisez reference-restage pour présenter le même plat depuis l'angle verrouillé destiné au client. Ne laissez jamais le remplacement changer les faits du plat.

Lisez références/food-image-playbook.md avant de collecter, planifier, générer ou réviser. Copiez les structures intégrées Manifest V3 et Style Lock au lieu d'inventer un ordre de travail.

Choisir le mode

Collecter : Récupérer les candidats réels d'un seul restaurant et enregistrer la provenance.
Auditer : Vérifier l'identité du restaurant, la visibilité du plat, l'angle source et le risque de remplacement. Ne pas générer.
Créer : Verrouiller un système photographique, router chaque source, générer une photo conçue par source réelle et conserver les durées.
Réparer : Régénérer à partir de la source réelle et du système photographique verrouillé après avoir diagnostiqué un échec de validation.
Réviser : Conserver automatiquement l'artefact source/sortie canonique et les cinq décisions de QA.

Laissez $restaurant-demo-builder établir les preuves commerciales, l'audience, la mise en page du site et les emplacements d'images pour une démo complète. Utilisez cette compétence pour le système photographique culinaire et les actifs.

Garder la révision des preuves non bloquante

Considérez les fiches canoniques de candidats, sources et source-vs-sortie comme des enregistrements de preuves automatiques, et non comme des demandes d'approbation. Dès qu'une fiche source canonique existe, enregistrez chaque source éligible avec status: recorded, reviewer: workflow, validez l'étape generate et continuez vers la génération d'image sans attendre l'utilisateur. Après la QA de sortie, enregistrez la comparaison canonique de la même manière et continuez vers la porte de la démo privée.

Arrêtez-vous uniquement lorsque les preuves ou la validation échouent, qu'un enregistrement actuel changes-requested existe, que la source ne peut pas soutenir honnêtement l'image proposée, ou que l'utilisateur demande explicitement une pause de l'exécution en cours. L'inspection humaine reste disponible plus tard et peut créer des changes-requested ; elle n'est jamais un prérequis pour la génération. Conservez la confirmation factuelle du propriétaire et les droits de publication comme des portes de lancement séparées.

Appliquer le contrat Manifest V3

Exigez que chaque image culinaire de démo satisfasse toutes ces règles :

Lier exactement un served-dish-photo visuel principal unique du même restaurant.
Sauvegarder la source non modifiée localement avec l'identité de la plateforme, l'URL originale et le SHA-256.
Fournir cette source réelle au générateur d'image (imagegen). Ne jamais utiliser de génération alimentaire par prompt uniquement.
Enregistrer source_assessment.camera_view, l'adéquation à la présentation client et le risque de détail caché.
Compléter un photography_system au niveau du restaurant avant la génération.
Utiliser constrained-edit uniquement lorsque la source correspond déjà à ce système.
Utiliser reference-restage lorsque l'angle de caméra, la composition ou la présentation client doit changer.
Bloquer les remplacements d'angle avec un risque élevé de détail caché jusqu'à ce qu'une autre vue réelle soit disponible.
Accepter une vue corroborante uniquement lorsqu'il s'agit d'un autre served-dish-photo audité en direct du même restaurant avec un enregistrement de correspondance exacte du même plat.
Enregistrer un plan de transformation par plat et les ajustements d'appétit autorisés.
Enregistrer le début, la fin et la durée de la génération d'image.
Décoder complètement la sortie, enregistrer sa largeur et hauteur réelles, et vérifier son ratio de pixels par rapport au système photographique.
Passer les cinq portes séparées : fidélité, cohérence stylistique, optimisation de l'appétit, artefacts IA et préparation pour le site web.
Sauvegarder les artefacts canoniques de la source réelle et de la source-vs-image conçue.
Passer l'étape demo du Manifest avant de copier la sortie dans un site web.

Si aucune photo crédible de plat réel n'existe, gardez l'emplacement textuel, utilisez une image non alimentaire approuvée séparément, choisissez un autre plat photographié ou demandez une photo du propriétaire.

Considérez une photo du propriétaire comme un candidat d'acquisition futur, pas un visuel principal, jusqu'à ce qu'elle ait un enregistrement de collecteur implémenté, un décodage de pixels complet, une fiche candidate canonique et un audit candidat équivalent à Apify/Masa. Manifest V3 n'admet actuellement que les photos auditées d'Apify Google Maps et de Masa comme visuels principaux.

Préparer l'ordre de travail

Créez output/food-image-studio/<restaurant-slug>/ avec sources/, prompts/, drafts/, selected/ et review/. Utilisez :

assets/image-manifest-template.json pour image-manifest.json.
assets/style-lock-template.md pour style-lock.md.

Utilisez des noms de fichiers ASCII en minuscules. Ne placez jamais de jetons API, de clés privées ou de secrets de compte dans ces fichiers.

Dans les commandes, résolvez <food-image-skill> à partir du localisateur de compétences disponibles de cette compétence.

Collecter les références de plats réels

Exécutez le collecteur uniquement pour le restaurant sélectionné :

APIFY_TOKEN=... python3 <food-image-skill>/scripts/collect_real_references.py apify \
  --place-id <google-place-id> \
  --max-images 20 \
  --output-dir <work-order>

python3 <food-image-skill>/scripts/collect_real_references.py masa \
  --store-id <masa-store-id> \
  --item-name <exact-menu-item-name> \
  --output-dir <work-order>

Pour une URL Maps, fournissez également le Place ID connu indépendamment ; l'enregistrement retourné doit correspondre :

APIFY_TOKEN=... python3 <food-image-skill>/scripts/collect_real_references.py apify \
  --maps-url <exact-google-maps-place-url> \
  --expected-place-id <google-place-id> \
  --output-dir <work-order>

Le collecteur décode complètement les pixels JPEG, PNG et WebP et rejette les sources en dessous de 300 px de bord court ou de 150 000 pixels totaux. Il exige qu'Apify retourne le Place ID verrouillé et que Masa retourne le StoreID demandé dans la réponse ou le contexte de l'élément de menu. Il ne traite jamais l'identifiant demandé seul comme une preuve.

Les importations JSON hors ligne sont uniquement du matériel d'audit reproductible. Elles conservent leur hachage d'entrée et leur niveau offline-audit-only, mais ne peuvent pas être promues ni entrer dans une démo.

Enregistrer l'audit indépendant des candidats

Générez la fiche canonique des candidats non classés :

python3 <food-image-skill>/scripts/make_candidate_sheet.py \
  --source-index <work-order>/source-index.json \
  --out <work-order>/review/candidate-sources.svg

Inspectez chaque candidat local avec view_image et la fiche conservée. Rejetez les captures d'écran, menus, placeholders, images de stock, images synthétiques, aliments obscurs et mauvais établissements. Enregistrez la classification comme une étape d'audit automatique ; ne vous arrêtez pas pour approbation utilisateur :

python3 <food-image-skill>/scripts/record_candidate_review.py \
  --source-index <work-order>/source-index.json \
  --candidate-sheet <work-order>/review/candidate-sources.svg \
  --candidate-id <candidate-id> \
  --out <work-order>/review/<candidate-id>.json \
  --status recorded \
  --reviewer workflow \
  --classification served-dish-photo \
  --restaurant-match verified \
  --restaurant-match-notes <identity-evidence> \
  --dish-visibility served-dish-visible \
  --visual-notes <visible-served-dish-evidence> \
  --notes <audit-summary>

L'enregistrement d'audit verrouille l'ID candidat, le hachage source non modifié, le hachage de l'index source, le hachage de la fiche candidat canonique, le relecteur, l'horodatage, la classification et les constats visuels. Enregistrez les candidats non alimentaires sous leur classification réelle et ne les promouvez pas. Un enregistrement ultérieur changes-requested bloque immédiatement la promotion et la validation de la démo.

Évaluer l'instantané avant de choisir un mode

Enregistrez l'angle de vue de la caméra source comme overhead, near-overhead, three-quarter, low-angle, straight-on ou unknown. Ensuite enregistrez :

fit : la source correspond déjà au système photographique ; autorisez constrained-edit.
restage-required : le plat est factuel mais l'angle ou la composition n'est pas destinée au client ; nécessite reference-restage.
unusable : l'aliment est trop obscurci ou incertain ; bloquez la génération.

N'appelez pas un instantané de dessus fit lorsque le système verrouillé destiné au client est three-quarter-tabletop. L'échec de Sake Sushi est l'anti-modèle canonique : une source réelle de dessus ne peut pas passer simplement parce qu'une modification conserve la même composition de dessus.

Le validateur applique la compatibilité de famille de caméras. Les sources overhead et near-overhead ne peuvent pas être marquées fit pour three-quarter-tabletop, low-tabletop ou straight-on ; les vues incompatibles doivent être restage-required, définir angle_change_required: true et utiliser reference-restage.

Promouvez un candidat par sortie proposée :

python3 <food-image-skill>/scripts/promote_candidate.py \
  --source-index <work-order>/source-index.json \
  --candidate-review <work-order>/review/<candidate-id>.json \
  --manifest <work-order>/image-manifest.json \
  --candidate-id <candidate-id> \
  --dish-id <dish-id> \
  --dish-name <dish-name> \
  --restaurant-name <restaurant-name> \
  --restaurant-slug <restaurant-slug> \
  --location <location> \
  --google-place-id <place-id> \
  --dish-match-status <exact-or-category-only> \
  --dish-match-notes <name-or-category-evidence> \
  --source-camera-view overhead \
  --customer-facing-fit restage-required \
  --hidden-detail-risk medium \
  --composition-notes <why-the-snapshot-needs-restaging> \
  --angle-change-required yes \
  --generation-mode reference-restage

Utilisez --masa-store-id au lieu de --google-place-id pour Masa.

La promotion n'accepte qu'un recorded / audit-record actuel classé comme served-dish-photo provenant d'une collection live-verified. Elle copie la provenance originale complète et les métadonnées source dans le Manifest. Les fichiers source-index et candidate-review restent liés par hachage et sont revalidés à chaque étape ultérieure.

Considérez live-verified comme une preuve attestée par le workflow, pas une signature cryptographique d'Apify ou Masa. Une personne ayant un accès en écriture à l'ordre de travail peut modifier le JSON local et recalculer les hachages locaux. Lorsque la provenance est contestée ou avant qu'un lancement public ne dépende de cet actif, réexécutez la collection du fournisseur en direct, comparez l'identité du restaurant retournée et le hachage de l'image, ou remplacez-le par un actif propriétaire approuvé ayant passé un audit futur d'ingestion propriétaire. Ne décrivez jamais la chaîne locale comme infalsifiable.

Verrouiller un système photographique conçu

Complétez à la fois le photography_system structuré et style-lock.md avant la génération. Verrouillez une famille de caméras principale pour l'ensemble du restaurant, normalement un système three-quarter-tabletop reproductible autour de 35–45 degrés pour une photographie culinaire destinée au client. Enregistrez une tolérance d'angle ne dépassant pas 15 degrés.

Verrouillez toutes ces variables :

angle cible, hauteur de caméra, rendu de l'objectif et échelle du sujet ;
ratio d'aspect, recadrage et espace négatif du site web ;
surface, famille d'arrière-plan et retenue des accessoires ;
direction de la lumière, qualité de la lumière et caractère des ombres ;
exposition, balance des blancs, saturation et contraste ;
traitement de l'appétit et imperfections réelles acceptables ;
les indices naturels nécessaires pour éviter un aspect rendu par IA.

Utilisez une famille de caméras principale pour l'ensemble. N'alternez pas de manière décontractée entre des images de dessus, de face et à trois quarts.

Planifier une optimisation honnête de l'appétit

Enregistrez les ajustements spécifiques au plat avant de générer des prompts. Autorisez uniquement les améliorations soutenues par la source :

augmenter modestement l'exposition et corriger la balance des blancs ;
rendre le pain ou la croûte existants naturellement plus chauds et plus dorés ;
clarifier une saisie existante, un bord croustillant, une couleur de légume ou un brillant de sauce ;
nettoyer les détails d'arrière-plan distrayants et améliorer le placement de l'assiette ;
préserver les variations de service ordinaires, les coupes irrégulières et l'asymétrie de la source.

N'inventez pas de brunissement, de marques de gril, de garniture, d'ingrédients, de sauce, de vapeur, de portion, de récipient ou de vaisselle de luxe. "Plus appétissant" est un objectif de présentation, pas une permission de redessiner l'aliment.

Enregistrer automatiquement l'artefact source

Exigez que le système photographique structuré, le style lock et chaque plan de transformation soient complets avant de créer la fiche source :

python3 <food-image-skill>/scripts/validate_manifest.py \
  --manifest <image-manifest.json> \
  --stage plan

Ensuite créez et conservez la fiche source canonique et enregistrez-la sans vous arrêter :

python3 <food-image-skill>/scripts/make_contact_sheet.py \
  --manifest <image-manifest.json> \
  --stage source \
  --out <work-order>/review/source-review.svg

python3 <food-image-skill>/scripts/record_review.py \
  --manifest <image-manifest.json> \
  --dish-id <dish-id> \
  --gate source \
  --status recorded \
  --reviewer workflow \
  --notes <source-angle-route-and-evidence-notes>

Ne vous arrêtez pas après avoir rendu la fiche. Enregistrez automatiquement chaque source éligible, remplacez tous les marqueurs TODO de prompt, exigez validate_manifest.py --stage generate, et passez directement à la génération d'image lorsque la validation réussit.

Générer la photo conçue

Utilisez $imagegen. Fournissez le visuel principal dans chaque appel et ajoutez des vues corroborantes réelles lorsque le risque de détail caché l'exige. Dans chaque prompt :

Pour chaque ID corroborant, enregistrez source_assessment.supporting_source_matches.<source-id> avec status: exact et des notes spécifiques du même plat. Incluez uniquement ces vues réelles auditées après le visuel principal dans output.input_source_ids ; les documents de menu, photos de lieu, images de stock et images synthétiques ne peuvent pas satisfaire le risque de détail caché.

Nommez l'ID source et constrained-edit ou reference-restage.
Nommez la famille de caméras cible et l'angle cible explicitement.
Considérez la source réelle comme vérité du plat et le système photographique comme vérité de présentation.
Répétez les faits alimentaires vérifiés, les quantités, la portion, les accompagnements, la sauce, la cuisson et le récipient.
Décrivez uniquement la composition prévue et les améliorations d'appétit.
Préservez les irrégularités réelles et la présentation ordinaire d'un restaurant indépendant.
Interdisez le brillant plastique, la texture cireuse, la géométrie répétée, la symétrie parfaite, les bords déformés, les effets factices, le texte et les logos.
Faites une image uniquement du plat ; aucun arrière-plan de restaurant, aucune table complète, aucun serveur ni client.

LucasH1225/restaurant-website-skills

Qu'est-ce que restaurant-website-skills ?

Demander à votre IA préférée

Documentation