nature-image2ppt

Nature Image2PPT

Utilisez ce répertoire comme environnement d'exécution complet. Exécutez les actions déterministes uniquement via :

python <image2ppt-root>/cli/image2ppt/cli.py <commande> ...

Utilisez Python 3.10 ou ultérieur avec requirements.txt installé. Lorsqu'un environnement dédié existe, remplacez <image2ppt-root>/.venv/bin/python sur macOS/Linux ou <image2ppt-root>/.venv/Scripts/python.exe sur Windows pour chaque commande python ci-dessous. Ne continuez pas après un échec de doctor ; installez uniquement la dépendance manquante signalée, puis relancez-le.

Ne découvrez ni n'invoquez un autre Skill, CLI, Prompt, Schéma, module ou machine d'état.

Lire les contrats locaux progressivement

Lisez toujours references/workflow.md. Lisez references/runtime-dependencies.md uniquement pour la configuration ou les échecs de doctor, et lisez references/ocr-text-hints-contract.md uniquement lors du choix ou du dépannage de l'OCR.

Avant d'écrire un manifeste de page, lisez references/page-decision-tree.md et references/manifest-schema.md. Ajoutez uniquement les références nécessaires à cette page :

• page structurée ou composée : references/region-decomposition.md et references/object-routing.md;
• flèches : references/manifest-arrow-extension.md;
• ressources matricielles ou travail backend d'image : references/assets-provenance-contract.md.

Avant d'accepter ou de livrer une sortie, lisez references/qa-contract.md.

Préserver la source unique de vérité

• Traitez page_jobs.json comme la seule source d'état de page.
• Traitez chaque pages/page_NNN/manifest.json comme la seule source de contenu de page.
• Traitez deck_manifest.json comme la source de l'assemblage final.
• Utilisez uniquement prepare, run next/dispatch/record/reset/hints/finalize et les commandes de page dans le CLI local pour les opérations de cycle de vie avec état.
• Conservez les preuves de région sémantique dans manifest.json.image2ppt_region_decomposition.
• Ne créez jamais un deuxième fichier de tâche, plan de reconstruction, normalisateur OCR, contrôleur de page, empaqueteur ou chemin de finalisation.
• Laissez le QA supplémentaire signaler les échecs ; ne le laissez jamais modifier l'état du cycle de vie.

Conserver chaque écriture dans son répertoire propriétaire

• La construction, la validation, les indices et le QA d'une page peuvent lire et écrire uniquement à l'intérieur de ce répertoire de page. Les chemins de manifeste, les ressources enregistrées, les formules, les rapports, les aperçus et les remplacements --out ne doivent pas utiliser .., les liens symboliques ou les chemins absolus pour s'en échapper. La seule exception d'entrée externe est un résultat explicite d'outil d'image fourni à image import ou en tant que process-sheet --asset-sheet-source ; il est copié dans la page avant de devenir une dépendance de construction.
• Les manifestes de niveau d'exécution et les sorties finales doivent rester à l'intérieur du répertoire d'exécution préparé. La finalisation reconstruit dans un fichier temporaire du même répertoire et le publie de manière atomique uniquement après une construction réussie.
• Traitez tout rejet de limite comme une défaillance dure ; ne copiez pas le fichier rejeté dans le champ d'application et ne le présentez pas comme une sortie d'exécution.

Préserver le comportement pré-migration

• Traitez l'auto-confinement comme une migration de chemin/import/point d'entrée, pas une refonte du comportement de reconstruction.
• Générez chaque Prompt de travailleur à partir de la couche de base locale complète plus la couche de profil Image2PPT préservée. Ne condensez, n'interprétez pas différemment ou ne remplacez aucune des deux couches.
• Préférez la stratégie visuelle précédemment validée lorsque plusieurs routes satisfont aux contrats. Conservez les objets mesurés simples natifs et conservez les ressources complexes limitées chaque fois qu'un redessin natif réduirait la fidélité.
• Ne ré-écrivez jamais une page de référence acceptée simplement pour prouver l'indépendance de l'exécution.

Exécuter le workflow

Sélection du backend d'image

Utilisez builtin-imagegen lorsque l'environnement d'exécution de l'agent expose image_gen.imagegen ; c'est le backend préféré car le travailleur peut inspecter les entrées d'édition et importer le résultat local explicite. Utilisez le contrat d'image CLI uniquement lorsque l'outil intégré n'est pas disponible, génère une erreur, ne peut pas lire une entrée ou ne renvoie aucune sortie locale valide. Un argument optionnel manquant tel que le modèle, le masque, la taille, la qualité ou le chemin de sortie n'autorise jamais le repli. Enregistrez le producteur réel et la raison de repli autorisée dans imagegen-jobs.json.

Le contrat d'image CLI est neutre vis-à-vis du fournisseur à la frontière de transport. Sélectionnez codex-oauth uniquement pour les identifiants de modèle GPT Image. Sélectionnez openai-compatible-api pour tout modèle spécifique au fournisseur dont le point de terminaison implémente le schéma /images/generations et/ou /images/edits compatible OpenAI. N'inférez pas le backend d'image à partir du modèle de langage de la tâche. Utilisez un backend explicite lorsque la provenance est importante ; auto utilise Codex OAuth uniquement pour les identifiants GPT Image compatibles et sinon sélectionne l'API configurée sans envoyer les informations d'identification Codex OAuth à des tiers.

1. Pré-vol et choix de l'OCR

python <image2ppt-root>/cli/image2ppt/cli.py doctor --json

Utilisez Baidu AI Studio PADDLE_OCR_TOKEN lorsqu'il est configuré. S'il est absent, dites à l'utilisateur une fois que le repli local builtin-ink mesure la géométrie du texte mais ne reconnaît pas les caractères ; proposez le chemin de configuration dans references/ocr-text-hints-contract.md. Respectez un choix hors ligne uniquement.

2. Préparer une exécution

python <image2ppt-root>/cli/image2ppt/cli.py prepare <entrée...> \
  --out-root output/image2ppt --image-backend builtin-imagegen

Pour épingler un fournisseur/modèle tiers configuré pour une provenance vérifiable, préparez avec --image-backend openai-compatible-api. Le contrat d'exécution enregistre le IMAGE2PPT_IMAGE_MODEL exact à partir de la configuration du projet actif ou de l'environnement ; il ne substitue pas un modèle GPT Image par défaut simplement parce qu'aucun indicateur --model n'a été passé.

Utilisez --no-text-hints uniquement lorsque le traitement OCR est intentionnellement désactivé. Régénérez les indices sans créer une nouvelle exécution si nécessaire :

python <image2ppt-root>/cli/image2ppt/cli.py run hints <rép-exécution>

3. Avancer et réclamer les pages

python <image2ppt-root>/cli/image2ppt/cli.py run next <rép-exécution> --json
python <image2ppt-root>/scripts/build_page_worker_prompt.py \
  <rép-exécution> --page <id-page> --out <rép-absolu-page>/worker-prompt.md
python <image2ppt-root>/cli/image2ppt/cli.py run dispatch \
  <rép-exécution> --page <id-page> --agent-id <id> --prompt-file <prompt-absolu>

Pour une page exactement, réclamez-la avec --local et reconstruisez-la dans l'agent actuel. Pour plusieurs pages, répartissez les travailleurs de page indépendants jusqu'à la capacité dans page_jobs.json. Ne réinitialisez pas un travailleur en direct simplement parce qu'il est lent.

4. Reconstruire et valider chaque page

Planifiez une page structurée comme 3 à 5 régions sémantiques et acheminez chaque région indépendamment. Utilisez des diagrammes composés mesurés : mesurez chaque nœud, relation et ancrage protégé. Conservez les cercles mesurables, les cartes, les relations droites/en pointillés et les connecteurs simples natifs. Utilisez des ressources transparentes limitées uniquement pour les sous-parties locales complexes.

Représentez une flèche fine comme un seul connecteur avec sa pointe de flèche sur le même objet. Représentez une flèche remplie comme une seule forme automatique Flèche, avec un texte d'étiquette centré à l'intérieur du même objet. Ne construisez jamais une flèche ordinaire à partir d'une ligne plus un triangle et n'aplatissez jamais un graphe de connaissances entier en une seule image.

Écrivez de nouveaux manifestes de page avec schema_version: 2. Utilisez des éléments visual_inventory structurés avec des valeurs kind et representation explicites, et écrivez une observation quality_evidence concrète pour chaque vérification de qualité obligatoire. Le rendu des formules est une porte dure : un moteur manquant, un convertisseur ou une compilation échouée doit maintenir la page en échec sauf si l'utilisateur approuve explicitement cette exception de formule exacte et que le manifeste enregistre à la fois user_approved_exception: true et une approval_note concrète.

Le Prompt du travailleur effectue la séquence déterministe. Ses portes finales sont :

python <image2ppt-root>/cli/image2ppt/cli.py page build <rép-page>
python <image2ppt-root>/scripts/run_image2ppt_qa.py <rép-page>
# La première exécution écrit visual-review-evidence.template.json et reste en attente.
# Inspectez source.png par rapport à render/rendered.png, copiez et complétez le modèle
# en tant que visual-review-evidence.json, réparez si nécessaire, puis :
python <image2ppt-root>/scripts/run_image2ppt_qa.py <rép-page> \
  --visual-review-status reviewed \
  --visual-review-evidence <rép-page>/visual-review-evidence.json
python <image2ppt-root>/cli/image2ppt/cli.py page contact-sheet <rép-page>

Le fichier de preuves doit couvrir les hachages source/rendu actuels et chaque vérification obligatoire avec une observation spécifique. --visual-review-notes est un contexte optionnel et ne peut pas remplacer le fichier de preuves.

Enregistrez seulement après la validation standard et le passage des portes de région, de flèche et de rendu Image2PPT :

python <image2ppt-root>/cli/image2ppt/cli.py run record \
  <rép-exécution> --page <id-page> --agent-id <id>

Utilisez le même cycle de vie run reset → dispatch → record pour réparer les pages rejetées.

5. Finaliser et revalider le diaporama reconstruit

Lorsque run next signale finalize, exécutez :

python <image2ppt-root>/cli/image2ppt/cli.py run finalize <rép-exécution>
python <image2ppt-root>/scripts/run_final_image2ppt_qa.py <rép-exécution>
# La première exécution écrit final/visual-review-evidence.template.json et reste en attente.
# Inspectez chaque diapositive rendue, complétez final/visual-review-evidence.json, puis :
python <image2ppt-root>/scripts/run_final_image2ppt_qa.py <rép-exécution> \
  --visual-review-status reviewed \
  --visual-review-evidence <rép-exécution>/final/visual-review-evidence.json

La finalisation reconstruit à partir des manifestes de page, préserve les notes de l'orateur source, valide le package et écrit la sortie enregistrée par deck_manifest.json. Le QA final réapplique les flèches de manifeste, vérifie l'atomicité des flèches et la structure composée, rend chaque diapositive, vérifie l'intégrité des notes de l'orateur et écrit final/image2ppt_qa.json.

Livrer

Retournez le chemin final du PPTX, la validation finale standard et final/image2ppt_qa.json. Signalez quels visuels complexes restent des ressources bitmap remplaçables. N'appelez pas le diaporama complet tant qu'une porte de page/finale est en attente ou a échoué.