LLLin000/dashscope-patent-flowchart

Figures d'étapes de processus biologiques — cahier de jeu composé

Générez des figures autonomes et précises pour les étapes de processus biologiques, de biomatériaux, d'ingénierie tissulaire et de laboratoire.

Limite de confiance : Seules les cartes de mapping vérifiées par la source peuvent introduire des affirmations scientifiques. La vérification de rendu inspecte la conformité des pixels avec la carte de mapping ; elle ne peut pas améliorer ou créer d'affirmations source. Les images de style et de référence ne décident jamais de la science.

Structure : atomes → molécules → ce cahier de jeu

Cette compétence est un composé (cahier de jeu). Elle ne contient pas la procédure elle-même — elle orchestre des molécules (composites), qui enchaînent explicitement des atomes (capacités).

composés (ce cahier de jeu) : choisir le mode, exécuter les molécules, conserver le jugement
  └─ composites/ : workflows délimités, ordre atomique explicite (2-6 atomes chacun)
       └─ capabilities/ : primitives mono-objectif, quasi-déterministes

La profondeur est limitée à deux niveaux intentionnellement : les molécules appellent les atomes directement, les atomes n'appellent jamais d'autres atomes, le cahier de jeu ne dépasse jamais les molécules. Un graphe plus profond est là où la fiabilité de l'agent s'effondre.

• Atomes (capabilities/) : un objectif, un artefact, mécanique. Aucun jugement sur l'orchestration.
• Molécules (composites/) : une tâche délimitée avec des instructions explicites "appeler l'atome X, puis l'atome Y". Minimise la prise de décision à l'exécution.
• Ce cahier de jeu : sélection de mode, ordonnancement, escalade et invariants qui priment sur tout.

Carte des molécules

Molécule	Fichier	Enchaîne les atomes
analyser-projet	composites/analyze-project.md	extraire-texte-source → analyser-entités → construire-bible-matériaux → extraire-feuille-style (si référence)
planifier-étape	composites/plan-step.md	écrire-carte-mapping → vérifier-carte-mapping → Porte 1
rendre-étape	composites/render-step.md	assembler-invite → rendre-image → exécuter-sonde (itérer dans le budget)
finaliser-étape	composites/finalize-step.md	ajuster-étiquettes (+ construire-dossier-preuve sur demande)

Prise en charge — demander avant de commencer

Au début de la tâche, clarifiez les options définies par l'utilisateur en un seul tour avec l'outil question (demander), avant de toucher aux fichiers :

1. Type de tâche — achemine le workflow (tableau ci-dessous).
2. Mode de tâche — rapide (exploration, reste BROUILLON) ou vérifié (livrable final).
3. Mode Porte 1 — strict_vérifié (vérification humaine de la source) ou agent_brouillon (pas de porte humaine).
4. Source — brevet / article / protocole / DOCX / PDF / texte collé ; chemin ou fichier.
5. Image de référence — fournie (style uniquement) ou aucune.
6. Budget d'itération par étape (par défaut 5 rendus).
7. Livrables — PNG uniquement, PNG + étiquettes, ou PNG + étiquettes + dossier de preuve.
8. Modèle — par défaut qwen-image-3.0-pro, ou récupérer le catalogue (capabilities/list-image-models.md, scripts/list_image_models.py) et laisser l'utilisateur choisir ; enregistrer le choix dans model_choice.json.

Ne devinez pas les options que l'utilisateur peut répondre en un seul tour. Réutilisez les réponses précédentes lorsque vous continuez un projet existant.

Orchestration

Type de tâche → routage du workflow

Type de tâche	Molécules à exécuter	Notes
Figure d'étape unique nouvelle	planifier-étape → rendre-étape (+ finaliser-étape si vérifié)	exécuter analyser-projet seulement si aucune bible de projet n'existe encore
Ensemble complet de figures (multi-étapes)	analyser-projet → par étape : planifier-étape → rendre-étape → finaliser-étape	pipeline complet
Réviser un rendu d'étape existant	rendre-étape uniquement	réutiliser la carte vérifiée ; relancer la Porte 1 seulement si la carte change
Réétiqueter un rendu accepté	finaliser-étape (ajuster-étiquettes uniquement)	pas de nouveau rendu
Dossier de preuve / audit	finaliser-étape (construire-dossier-preuve uniquement)	indexe les artefacts existants
Exploration / esquisse de style	planifier-étape (agent_brouillon, minimal) → rendre-étape	la sortie reste BROUILLON/NON VÉRIFIÉ

Modes

• rapide — exploration : mapping minimal, agent_brouillon, pas de portes humaines, pas d'étiquettes, pas de dossier de preuve. Sortie BROUILLON/NON VÉRIFIÉ.
• vérifié — livrable final : analyse complète, Porte 1 strict_vérifié, étiquetage, Porte 3, dossier de preuve optionnel.

Chaque molécule se termine par un artefact nommé et un état de vérification ; ne sautez jamais la sortie requise d'une molécule. En cas de sortie BROUILLON/NON VÉRIFIÉ : indiquez-le explicitement ; ne la présentez jamais comme vérifiée.

Entrées requises

1. Source scientifique (brevet / article / protocole / DOCX / texte PDF ou description utilisateur) — l'autorité pour l'opération, l'identité et l'état.
2. Image de référence optionnelle (style uniquement).
3. Mode de tâche et mode Porte 1.

Sorties requises

Pour chaque étape générée, le workflow DOIT produire :

Fichier	Molécule	Contenu
project_material_bible.yaml	analyser-projet	Analyse Phase 0 (une fois par projet)
stepN_mapping.yaml	planifier-étape	carte de mapping + statut de vérification
stepN_prompt.txt	rendre-étape	invite finale textuelle
stepN_vXX.png + .json	rendre-étape	un candidat par version + métadonnées
stepN_probe.yaml	rendre-étape	résultats de la sonde Porte 2
stepN_labeled.png	finaliser-étape	après la Porte 3 (mode vérifié)

Portes

Porte	Emplacement	Ce qu'elle vérifie
Porte 1	planifier-étape	carte de mapping ↔ source ouverte (humain, mode strict)
Porte 2	rendre-étape	rendu ↔ carte de mapping (sondes fixes)
Porte 3	finaliser-étape	étiquettes ↔ pixels livrés

Aucun autre artefact dans ce workflow n'est une porte de vérité. Tout le reste est documentation, hygiène ou substrat exécutable.

Invariants requis

1. Source faisant autorité pour l'opération, l'identité, l'état.
2. Aucune opération ou entité scientifique inventée pour la composition.
3. Entités répétées : un descripteur canonique par projet ; les jetons d'identité stables sauf si une transition déclarée justifie un déplacement.
4. Propriétés incertaines restent génériques ou OUVERTES ; jamais résolues silencieusement.
5. Bible de style / image de référence ≠ preuve scientifique.
6. La topologie provient de la carte de mapping vérifiée.
7. Les étiquettes et les pixels livrés sont en accord.
8. Le succès de l'API ≠ acceptation visuelle ou scientifique.
9. Une vérification de source ignorée produit BROUILLON/NON VÉRIFIÉ, jamais une affirmation vérifiée.

Structure du dépôt

SKILL.md                  ce cahier de jeu (composé)
composites/               molécules
capabilities/             atomes
schemas/                  Schémas JSON pour bible de matériaux / carte de mapping / métadonnées de rendu / sonde
adapters/                 contrat spécifique au moteur de rendu (dashscope.md)
scripts/                  moteur de rendu générique (generate_image.py)
examples/                 artefacts travaillés (hydrogel_patent/)
.env.example              modèle de clé ; copier dans .env localement

Extension

• Nouvelle opération mono-objectif → ajouter un capabilities/*.md, le garder mécanique, lui donner un schéma ou script s'il en touche un.
• Nouvelle tâche délimitée → ajouter un composites/*.md qui enchaîne des atomes existants ; privilégier la réutilisation des atomes plutôt que d'en créer de nouveaux.
• Nouveau travail de haut niveau → composer des molécules dans ce cahier de jeu (ou un nouveau cahier de jeu).
• Une capacité qui appelle une autre capacité est une molécule par définition ; n'approfondissez pas la couche atomique.