Compétence Drawio Visuels

Que fait Compétence Drawio Visuels ?

Créez, reconstruisez et éditez des fichiers Draw.io natifs, modifiables par l'utilisateur, sans serveur, MCP, modèle fixe, Scene IR ou moteur de rendu personnalisé.

Par défaut, des objets, pas des modules textuels

Pour un nouveau flux explicatif — un processus, pipeline, couloir, cycle de vie de requête ou flux d'architecture — utilisez par défaut des objets reconnaissables éditables et des changements visibles. Une simple demande telle que « dessine le flux de travail » active cette règle ; l'utilisateur n'a pas besoin de demander des graphiques « picturaux », « concrets » ou « illustrés ». Choisissez le type de diagramme séparément de ce traitement visuel.

Avant de placer des nœuds, identifiez ce qui se déplace, ce qui change et qui agit. Ensuite, choisissez une silhouette, un contenu significatif ou une petite scène d'objet pour chaque objet métier principal et chaque étape de traitement : une file d'attente a des cartes de tâches séparées et une entrée/sortie ; un analyseur montre un document devenant des parties extraites ; un remboursement distingue les fonds en attente des fonds retournés. Dessinez d'abord ces parties natives, puis ajoutez des noms/actions courts. Une série de rectangles contenant des noms d'étapes échoue à cette règle par défaut, même si les étiquettes sont brèves et la disposition propre. Des serveurs répétés, des émojis ou une icône sans rapport sur une carte textuelle ne sont pas des substituts à un sens visible. Lisez visual-storytelling.md avant de créer ces flux.

Commencez par les graphiques fournis : consultez l'index des composants, lisez le XML .drawio pertinent sous assets/components/, et choisissez de réutiliser ses descendants natifs, d'adapter/combiner ses parties, ou d'utiliser sa construction comme référence pour générer un nouvel objet natif. Combinez les objets navigateur, document, message, file d'attente, travailleur, stockage, morceaux, table, vecteurs, révision, décision et notification selon les besoins de la tâche. Par exemple, composez navigateur + document → stockage, puis un message séparé → file d'attente → travailleur ; n'écrivez pas simplement ces noms dans des rectangles. Les 12 éléments de départ sont une bibliothèque de semences extensible, pas un modèle complet ou une limite de capacité ; lors de la génération d'un objet supplémentaire, empruntez des idées de construction pertinentes telles que silhouette, contenu significatif, marques d'état, imbrication et ports de connexion, puis adaptez-les au domaine. N'imposez pas la palette d'exemple de l'élément de départ et ne forcez pas une copie exacte.

Langage de composant intégré : lors de l'ajout, de la génération ou de la maintenance d'actifs réutilisables sous assets/components/, conservez chaque légende, nom de champ, valeur de texte illustrative, état, nom de page et info-bulle en anglais. Les chiffres, formules et symboles peuvent rester tels quels. Il s'agit d'une règle de création de bibliothèque : les diagrammes générés pour les utilisateurs suivent toujours leur langue demandée/source, le texte de départ étant adapté en conséquence.

Les exceptions suivent la tâche, pas la commodité : préservez la reconstruction fidèle, la portée d'une édition locale, une demande explicite de texte uniquement/boîte minimale, et la notation formelle requise. Les compartiments de classe/ER, les lignes de vie de séquence, les symboles de décision/fork/join et les limites d'état portent une sémantique réelle ; conservez-les. Une demande générique de « organigramme », de diagramme « simple », de démarreurs manquants ou la disponibilité de Mermaid n'est pas une exception. Expliquez les états par des changements d'objets visibles lorsque c'est compatible ; ne remplacez pas les relations formelles par des images. Ces valeurs par défaut s'appliquent à chaque page et survivent aux changements d'orientation/type.

Règles de base

• Traitez le fichier .drawio actuel comme la source de vérité interne modifiable. Par défaut, livrez uniquement des images PNG par page et un aperçu HTML ; conservez les fichiers natifs dans un répertoire de travail interne, en dehors du répertoire de livraison, et ne les liez pas dans la remise. Ne livrez des fichiers natifs, SVG, PDF ou autres formats que sur demande explicite.
• Ne remplacez jamais une entrée. Chaque écriture mécanique doit utiliser un nouveau chemin de sortie, y compris les fichiers de travail internes.
• N'imposez pas de thème, liste de formes, type de diagramme, grille de coordonnées ou recette de disposition.
• Suivez le type de diagramme, la notation et l'orientation spécifiés par l'utilisateur. Lorsqu'ils ne sont pas spécifiés, choisissez la présentation qui répond le mieux à la question réelle de la tâche, y compris les formes UML et non UML ; ne réduisez pas par défaut chaque demande à un organigramme ou un couloir. Utilisez diagram-selection.md lors du choix ou d'un changement substantiel de la présentation.
• Appliquez la règle par défaut « objets d'abord » ci-dessus aux nouveaux flux explicatifs ; les symboles de contrôle standard et les démarreurs de composants réutilisables la prennent en charge sans imposer un catalogue d'icônes fixe.
• Pour les organigrammes verticaux, faites passer le chemin principal de haut en bas, placez les branches parallèles côte à côte, étiquetez les sorties des diamants de décision et regroupez les vérifications de support dans une boîte gris clair en pointillés avec un objectif en langage simple.
• Lorsqu'un moteur central coordonne des modules externes, placez le cœur au centre, regroupez les entrées et les travailleurs de chaque côté, et utilisez des flèches numérotées avec des étiquettes d'action pour guider le lecteur à travers une tâche. Le cas échéant, acheminez les retours au-dessus du cœur, placez les décisions humaines et les canaux de notification en dessous, et montrez un exemple de flux de travail en bas. Choisissez les couleurs en fonction du sujet.
• Conservez les formes, pochoirs, styles, géométrie, points de passage, couches, groupes et métadonnées d'encapsulation Draw.io natifs arbitraires.
• Préférez un canevas ou un conteneur plus grand à des nœuds, étiquettes ou corridors de routage compressés. Un fichier sans collision n'est pas nécessairement spacieux, lisible ou bien composé.
• Prévoyez l'espace pour les étiquettes de connecteur avant de placer les nœuds adjacents. Les étiquettes longues doivent tenir entre les formes connectées avec un dégagement visible, ou utiliser des sauts de ligne explicites/une autre position d'étiquette claire. Résolvez les risques d'étiquette de point d'extrémité et vérifiez les limites réelles du texte rendu avant de marquer un diagramme comme prêt ; voir dégagement d'étiquette de connecteur.
• Pour le contenu nouvellement créé ou considérablement remanié, définissez flowAnimation=1 natif sur les bords de flux sémantique dirigé par défaut, y compris les flux normaux, secondaires, de données, d'exception et de nouvelle tentative. Laissez les références, annotations, conteneurs, regroupements et relations purement structurelles statiques. Laissez l'intention explicite de l'utilisateur remplacer cette politique.
• Préservez les styles d'animation non liés lors d'une édition locale, sauf si une normalisation de l'animation est demandée. Si le mouvement obscurcit la hiérarchie, rendez les flux sémantiques de priorité inférieure statiques lors du rendu QA au lieu de modifier leur topologie.
• Traitez l'animation du connecteur comme un effet visuel, jamais comme un contournement de routage ou de collision.
• Utilisez la CLI fournie uniquement pour inspecter, interroger, corriger, valider, vérifier la mise en page/la topologie, orchestrer l'exportation Desktop/Web, le HTML d'accompagnement, le CRUD de page, la liste de versions, la publication et la restauration. Elle ne crée pas, ne dispose pas et n'implémente pas de moteur de rendu ; render délègue à Draw.io Desktop, web-svg-bridge délègue une page sélectionnée à Draw.io Web officiel, et l'aperçu HTML délègue au visualiseur distant officiel.
• Traitez <base>-vNNN comme une version de livraison logique partagée par ses images et son HTML, et non comme chaque écriture interne. Le versionnage natif reste interne sauf si la livraison de la source est demandée. Par défaut, un changement approuvé par l'utilisateur consomme au plus une nouvelle version sœur.
• Conservez chaque --page-index public de la CLI basé sur zéro, correspondant à l'index renvoyé par inspect. Préférez les ID de page stables pour le travail multipage.
• Limitez chaque document à 15 pages. La CLI rejette les documents existants plus grands et les ajouts au-delà de cette limite avec PAGE_COUNT_LIMIT ; ne tronquez jamais les pages pour la satisfaire.
• N'activez pas cette compétence en même temps que la compétence officielle drawio@drawio ; cette compétence porte déjà le même chemin de création Mermaid/XML natif.

Choisir la présentation

Séparez le type de diagramme de l'outil de création. Choisissez en fonction de ce que le lecteur doit comprendre : progression, responsabilités, interactions, états, structure, déploiement, mouvement de données ou comparaison. Un diagramme fourni, un format explicite ou une édition locale demandée contraint ce choix. Lorsque l'utilisateur le laisse ouvert, faites le choix de manière autonome, expliquez-le brièvement si utile, et poursuivez ; ne forcez pas l'utilisateur à sélectionner dans un catalogue. Lisez diagram-selection.md pour le guide question-vers-forme et les compromis.

Appliquez le traitement visuel par défaut ou l'exception explicite de la tâche sur toutes les pages et révisions. N'ajoutez pas de page d'accompagnement en texte brut comme substitut à une explication basée sur des objets.

Ensuite, choisissez les objets et la notation appropriés à cette présentation. Les illustrations concrètes peuvent expliquer les charges utiles et les transformations, tandis que les symboles formels UML, ER et autres doivent conserver leurs conventions sémantiques. Ne traitez pas chaque boîte de classe, d'état ou de schéma étiquetée comme un défaut de flux textuel lourd.

Choisir le flux de travail

Requête	Flux de travail
Expliquer un processus, pipeline, couloir, cycle de vie ou flux d'architecture	Preuve/propriété → visual-storytelling → constructions objet/état → XML natif direct → QA du moteur de rendu officiel
Créer un diagramme structurel formel ou un diagramme à boîtes explicitement minimal	Préserver notation/contenu → Mermaid s'il conserve la représentation prévue et que Desktop est disponible ; sinon XML natif
Créer avec des formes/styles/positions personnalisés	XML natif direct → .drawio
Créer à partir d'un PDF ou d'un texte	Lire la source → extraire la structure prise en charge → choisir la représentation en utilisant les mêmes valeurs par défaut → XML natif ou Mermaid approprié
Reconstruire à partir d'une image	Inspecter à la résolution d'origine → cellules natives modifiables → comparaison d'aperçu optionnelle
Vérifier les conflits visuels	check-layout → render Desktop → inspecter l'image → petite correction → re-rendu ; revenir au HTML du visualiseur
Vérifier un flux métier	check-topology avec des points de départ, terminaux et arêtes requis connus
Visualiser sans Desktop	preview → .html d'accompagnement avec nombre/noms de pages visibles utilisant le visualiseur distant officiel
Exporter SVG sans Desktop	Préférer une session de bouclage web_svg_session.py ; conserver web-svg-bridge → commit-web-svg pour la récupération manuelle
Exporter ou appliquer une disposition demandée	Créer d'abord .drawio → CLI Draw.io Desktop
Édition, cible inconnue	inspect → query → patch
Édition, ID de page et de cellule connus	query → patch
Édition, résultat CLI récent et fiable a déjà une révision et une cible	patch
Ajouter, renommer ou supprimer une page	inspect → page add/rename/delete
Lister ou restaurer une version de fichier	versions ou versions → inspect old → restore
Publier un fichier de travail terminé	inspect working → publish
Visualiser une ou plusieurs cellules connues	query
Vérifier un fichier de manière indépendante	validate

Lisez references/authoring.md pour la création, l'aperçu, la détection Desktop, la disposition et l'exportation. Lisez references/web-svg-export.md uniquement lorsque Desktop est indisponible et que des SVG explicitement demandés doivent être exportés via Draw.io Web officiel. Lisez references/layout-authoring.md lors de la création d'un diagramme encombré, du maintien de la cohérence visuelle entre les pages, de l'interprétation de check-layout ou de l'exécution d'un QA visuel rendu. Lisez references/topology.md lorsqu'un chemin de processus, de cycle de vie ou de requête doit être connecté. Lisez references/source-to-diagram.md lorsque la source est un PDF, du texte ou une image. Lisez references/drawio-xml.md uniquement pour la création XML directe. Lisez references/patch-contract.md avant de construire un correctif. Lisez references/versioning.md pour les commandes de page et l'historique immuable.

Planifier une livraison logique

• Avant d'écrire, cartographiez chaque changement demandé vers sa page/cellule, les sorties de décision requises, les contraintes critiques de début/terminal/arête, les effets secondaires ou chemins d'erreur, la terminologie, et toutes les pages affectées.
• Pour les nouveaux documents multi-pages, définissez les rôles visuels propres au document avant la création et réutilisez les fondations de page, la typographie, les styles de composants répétés et le style des relations entre les pages. Lors de l'ajout ou de la modification de contenu, héritez de la convention de document existante dans la portée demandée. Suivez la cohérence visuelle du document pour la sélection des rôles, les exceptions intentionnelles et l'acceptation inter-pages.
• Pour une modification atomique qui n'aura pas besoin de correction ultérieure de topologie, de disposition ou visuelle, écrivez directement dans une nouvelle version native interne.
• Pour les modifications multi-pages ou toute tâche susceptible de nécessiter une correction QA, créez un répertoire temporaire appartenant à l'Agent et écrivez working-01.drawio, working-02.drawio, etc. Effectuez toutes les modifications et vérifications demandées là-bas ; publish est facultatif pour un instantané final interne ou une livraison native explicitement demandée.
• Générez le HTML de livraison et les PNG par page à partir du même instantané natif final vérifié ; un livrable .drawio publié n'est pas requis. Pour le HTML destiné à l'utilisateur, intégrez un rendu vérifié de chaque page avec preview --fallback-png (répétez dans l'ordre des pages). Vérifiez le HTML livré avec le visualiseur distant bloqué, y compris à une largeur étroite. Un rendu en ligne réussi ne vérifie pas l'aperçu du destinataire. Si aucun rendu officiel n'est disponible, étiquetez le HTML comme « en ligne uniquement » et divulguez la limitation. Les aperçus temporaires sont des artefacts QA, pas des livrables.
• Après avoir vérifié les images et le HTML autonomes, supprimez uniquement les fichiers QA jetables créés par cette tâche ; conservez l'instantané natif final en interne pour les modifications ultérieures. Ne nettoyez jamais les versions formelles existantes sans autorisation explicite de l'utilisateur.

Créer

1. Lisez references/authoring.md et choisissez la représentation avant de choisir une syntaxe. Pour un nouveau flux explicatif, utilisez la règle par défaut « objets d'abord » et le XML natif direct ; la disponibilité de Desktop modifie l'exportation, pas l'exigence visuelle. Utilisez Mermaid uniquement lorsqu'il conserve la sémantique/la représentation choisie, comme un diagramme structurel formel ou un diagramme à boîtes explicitement minimal. Détectez Desktop pour la conversion/l'exportation.
2. Choisissez une base descriptive en minuscules avec traits d'union, réservez <base>-v001 pour la livraison initiale d'image/HTML et conservez son instantané .drawio interne...