Conception de Diagrammes
Pour les requêtes en coréen, tous les textes des diagrammes (titres, étiquettes, descriptions auxiliaires, légendes) sont écrits en coréen ; les étiquettes auxiliaires en anglais ne sont conservées que pour les noms propres strictement nécessaires. Si le style de marque est demandé, passez directement au style par défaut si l'utilisateur ne l'a pas défini. (Version coréenne modifiée : Bangguseok Pro bangpro.ai.kr · Original : github.com/cathrynlavery/diagram-design, MIT License)
Créez des diagrammes sous forme de fichiers HTML autonomes avec SVG intégré et un système de design éditorial.
Quarante-cinq types visuels. Les motifs sémantiques décrivent le comportement ; les références de type décrivent la disposition.
0. Configuration initiale — Porte du guide de style
Avant de générer votre premier diagramme dans un nouveau projet, vérifiez que le guide de style a été personnalisé.
Ne diffusez pas silencieusement des diagrammes au style par défaut dans un projet de marque.
Résolvez d'abord tout marqueur .diagram-design du projet conformément à references/profiles.md ; un marqueur résolu avec succès sélectionne son profil et contourne cette porte. Cette référence gère les échecs, la valeur par défaut protégée et le comportement de sauvegarde.
Ouvrez references/style-guide.md et vérifiez les jetons par défaut. S'ils sont toujours ceux par défaut (papier #f5f5f5, encre #2d3142, accent #bf4520), marquez une pause et demandez à l'utilisateur :
"C'est votre premier diagramme dans ce projet et le guide de style est encore par défaut. Personnaliser maintenant ? Options : (a) URL du site web, (b) compétence installée, (c) dossier/design-system local, (d) coller les jetons, (e) conserver les valeurs par défaut, (f) charger un profil sauvegardé."
Ensuite, bifurquez selon la section correspondante de references/onboarding.md ; pour (f), suivez references/profiles.md.
Une fois le guide de style personnalisé (ou l'utilisateur ayant explicitement choisi les valeurs par défaut), ignorez cette porte lors des exécutions ultérieures. Un en-tête de profil principal nomme le profil actif copié. Sans en-tête, toute valeur de rôle sémantique ou famille typographique différente des valeurs par défaut signifie "personnalisé non enregistré" : ignorez la porte et proposez de l'enregistrer en tant que profil. Des jetons tous identiques aux valeurs par défaut sans marqueur/en-tête déclenchent la porte. Après l'intégration, proposez d'enregistrer en tant que profil client nommé selon references/profiles.md.
1. Philosophie
La meilleure action est souvent la suppression.
Appliqué aux schémas :
- Chaque nœud représente une idée distincte. Deux nœuds qui voyagent toujours ensemble sont un seul nœud.
- Chaque connexion porte une information. Si la relation est évidente par la disposition, supprimez la ligne.
- Le corail est éditorial, pas un drapeau. 1 à 2 nœuds focaux par diagramme. L'utiliser sur 5 nœuds efface le signal.
- Le schéma n'est pas terminé quand tout est ajouté. Il est terminé quand rien ne peut être supprimé.
Densité cible : 4/10. Suffisamment pour être techniquement complet. Pas assez dense pour nécessiter un guide. Au-dessus de 9 nœuds, il s'agit probablement de deux diagrammes.
2. Quand l'utiliser
Utilisez pour l'un des 45 types visuels (§3) lorsqu'un lecteur apprendra plus d'un visuel que d'un texte, d'un tableau ou d'une liste à puces.
Ne pas utiliser pour :
- Diagrammes unicode rapides → un outil de texte brut séparé comme wiretext. Cette compétence n'en fournit pas.
- Listes de choses → tableau ou puces.
- Avant/après basés uniquement sur des attributs → tableau ; changements de topologie → Architecture delta.
- "Diagrammes" à une seule forme → écrivez simplement la phrase.
Avant de dessiner, demandez : Le lecteur apprendrait-il plus de cela que d'un paragraphe bien écrit ? Si non, ne dessinez pas.
3. Sélection : motif sémantique, puis type visuel
Lorsque le comportement, l'état, l'application ou le risque porte le sens, chargez d'abord references/semantic-patterns.md et choisissez un motif principal. Ensuite, choisissez le type visuel le plus proche pour la disposition. Si aucun motif ne correspond, choisissez directement le type.
| Déclencheur comportemental | Motif sémantique → type le plus proche |
|---|---|
| Fan-in, profondeur de file d'attente, capacité finie, goulot d'étranglement | File d'attente / goulot d'étranglement → Flux de données |
| Question / Entrée / Gouvernance / Sortie répétées entre les étapes | Cadre d'étape avec emplacements sémantiques → Processus |
| Une conversation ou une entrée lâche devient un artefact durable structuré | Entrée non structurée → artefact structuré → Flux de données |
| Deux traces de règles nécessitent réussite/échec/sauté/non atteint et première divergence | Traces d'évaluation de politiques appariées → Organigramme |
| Frontières de confiance plus chemins d'entrée ou de déploiement autorisés/interdits | Voie pavée sécurisée → Architecture |
| Contrôles regroupés par lieu d'application | Catalogue de gouvernance / contrôles → Pile de couches |
| Les défenses compensent les lacunes antérieures et le risque résiduel se propage | Couches de sécurité compensatoires → Pile de couches |
| Décomposition hiérarchique adressable par ID nécessitant des E/S par bloc, contraintes et un lien de code | Décomposition de bloc traçable → Arbre |
| Un sujet progresse à travers des phases, des attentes, des tentatives, des annulations et des résultats terminaux | Carte de cycle de vie → Machine d'état |
Le motif possède les primitives sémantiques et son budget plus serré ; le type possède la grammaire de disposition. Utilisez references/animation.md uniquement lorsqu'un mouvement est demandé ou clarifie matériellement un changement ordonné ; le statique reste la valeur par défaut.
Guide des types visuels (45)
| Si vous montrez… | Utilisez | Référence |
|---|---|---|
| Composants + connexions en un instantané ; domaines admin vs trafic imbriqués | Architecture | type-architecture.md |
| Changement structurel entre topologies Avant / Après synchronisées, avec un journal des modifications | Architecture delta | type-architecture-delta.md |
| Paysage informatique hérité par phase ou service ; montre l'état avant | État informatique actuel | type-it-state.md |
| Logique de décision avec branches | Organigramme | type-flowchart.md |
| Messages ordonnés dans le temps entre acteurs | Séquence | type-sequence.md |
| États + transitions + gardes | Machine d'état | type-state.md |
| Entités + champs + relations | ER / modèle de données | type-er.md |
| Événements positionnés dans le temps | Chronologie | type-timeline.md |
| Processus interfonctionnel avec transferts | Couloir | type-swimlane.md |
| Positionnement/priorisation sur deux axes | Quadrant | type-quadrant.md |
| Plusieurs entités notées sur 3–5 critères quantitatifs | Radar / Toile | type-radar.md |
| Une série quantitative à travers des catégories cycliques ; angle=catégorie, rayon=ampleur | Diagramme polaire | type-polar.md |
| Cycle de renforcement ; la dernière étape alimente la première et un hub accumule l'état | Boucle | type-loop.md |
| Hiérarchie par contenu/portée | Imbriqué | type-nested.md |
| Relations parent → enfants | Arbre | type-tree.md |
| Propriété humain/agent/équipe, reporting, routage, escalade | Organigramme | type-org-chart.md |
| Niveaux d'abstraction empilés | Pile de couches | type-layers.md |
| Parties d'un objet séparées le long d'un axe : démontage, déballage, ordre d'assemblage | Axonométrique éclaté | type-exploded.md |
| Un étage ou site vu du dessus en angle : pièces avec mobilier, bâtiments par phase | Plan axonométrique | type-axonometric-plan.md |
| Chevauchement entre ensembles | Venn | type-venn.md |
| Hiérarchie classée ou attrition de conversion | Pyramide / entonnoir | type-pyramid.md |
| Comparaison quantitative entre catégories | Diagramme à barres | type-bar.md |
| Un total de départ relié à un total d'arrivée par des contributions signées (pont budgétaire, écarts d'effectifs) | Cascade | type-waterfall.md |
| Partie-d'un-tout où les tailles relatives sont l'histoire | Treemap | type-treemap.md |
| Données croisées ; le remplissage code la valeur par cellule | Carte de chaleur | type-heatmap.md |
| Tendances continues dans le temps, changement entre exactement deux états (graphique à pente), une distribution par série (crête), ou mouvement de rang sur plusieurs instantanés (bosse) | Graphique linéaire | type-line.md |
| Tâches et phases sur une chronologie | Gantt | type-gantt.md |
| Corrélation ou distribution de deux variables ; variantes à bulles (trois variables) et en essaim (une variable, point par élément) | Nuage de points | type-scatter.md |
| Pile de données de bout en bout sur un cluster de conteneurs | Haut niveau | type-high-level.md |
| Processus séquentiel multi-acteur avec transferts de données | Processus | type-process.md |
| Stockage de données multicouche avec niveaux de qualité et politiques d'accès | Médaillon | type-medallion.md |
| Flux de données limité aux rôles : qui fait quoi à chaque étape du pipeline | Flux de données | type-data-flow.md |
| Topologie d'intégration d'une plateforme de données — sources → cœur → consommateurs | Intégration PD | type-dp-integration.md |
| Matrice des permissions d'accès par rôle / par composant | Matrice de sécurité PD | type-dp-security-matrix.md |
| Une quantité se divisant et fusionnant à travers les étapes, largeur de bande = quantité | Sankey | type-sankey.md |
| Causes d'un seul effet observé, regroupées par catégorie (analyse des causes profondes) | Arête de poisson | type-fishbone.md |
| Chaîne de valeur par rapport à l'évolution — quoi construire, acheter et ce qui bouge | Carte de Wardley | type-wardley.md |
| Travail en cours par état, avec limites WIP et éléments bloqués | Kanban | type-kanban.md |
| Ce qu'une personne fait à travers les étapes d'une expérience, et comment elle se sent | Parcours utilisateur | type-journey.md |
| Ce que le client fait vs ce que le service cache, à travers les étapes, avec une ligne de visibilité | Schéma de service | type-service-blueprint.md |
| Où le logiciel s'exécute — zones, hôtes, artefacts, répliques, ports | Déploiement | type-deployment.md |
| Ce qui dépend de quoi, avec fan-in et cycles qu'un arbre ne peut pas exprimer | Graphe de dépendances | type-dependency.md |
| Classes avec opérations, héritage, composition (autres chemins UML ailleurs) | Classe UML | type-uml-class.md |
| Colonne vertébrale narrative découpée en versions, avec la ligne de coupe | Carte d'histoire | type-story-map.md |
| Tables physiques : types SQL, contraintes, index, FK au niveau colonne | Schéma de base de données | type-db-schema.md |
Règles empiriques :
- Si un tableau à 3 colonnes communique la même chose, choisissez le tableau.
- Si deux types semblent utiles, choisissez l'axe dominant ; un motif sémantique peut ajouter des primitives spécifiques au comportement, pas une deuxième grammaire de disposition.
- Si vous dépassez le budget de complexité (§7), divisez en une vue d'ensemble + un détail.
Chargez toujours la référence de type choisie liée dans le guide avant de dessiner. Lorsqu'il est acheminé ci-dessus, chargez également semantic-patterns.md ; lorsque l'animation est choisie, chargez animation.md.
Confirmer avant de dessiner
Avant le rendu, énoncez le plan en un court message : le type visuel choisi (et le motif sémantique, s'il a été acheminé), la préréglage de taille et tout ce que le budget de complexité (§7) forcera à exclure. Si l'utilisateur est joignable, laissez-le rediriger avant de dessiner ; sinon, continuez et notez les hypothèses à côté du livrable. Sautez la pause uniquement lorsque la demande précise déjà exactement le type, la taille et le contenu.
4. Anti-patrons universels
Ceux-ci marquent les schémas "déchets d'IA" de tout type :
| Anti-patron | Pourquoi il échoue |
|---|---|
| Mode sombre + lueur cyan/violet | A l'air "technique" sans décisions de conception |
| JetBrains Mono comme police "dev" globale | Le mono est pour le contenu technique — ports, commandes, URLs. Les noms vont en Geist sans. |
| Boîtes identiques pour chaque nœud | Efface la hiérarchie |
| Légende flottant dans la zone du diagramme | Entre en collision avec les nœuds |
| Étiquettes de flèche sans rectangle de masquage | Transparaît à travers la ligne |
Texte en writing-mode vertical sur les flèches | Illisible |
| 3 cartes récapitulatives de largeur égale par défaut | Grille générique — variez les largeurs |
| Ombre sur un élément quelconque | Les ombres sont finies. Les bordures sont à la mode. |
rounded-2xl sur les boîtes | Rayon max 6–10px ou aucun |
| Corail sur chaque nœud "important" | Le corail est 1–2 accents éditoriaux, pas un système de signalisation |
| Reproduire la disposition du moteur de rendu de Mermaid | Importe l'espacement et le routage automatiques au lieu de faire une disposition éditoriale |
| Toute violation des six règles de connecteurs §6 | Échec automatique : diagonales inclinées, étiquettes touchant leur trait, masques coupés par un nœud ultérieur, chemins qui se chevauchent, points d'attache partagés, transit derrière une boîte non terminale |
Les anti-patrons spécifiques à un type vivent dans chaque référence de type liée dans le guide.
5. Système de Design
Le système de design est personnalisable. references/style-guide.md est la source unique de vérité pour les couleurs, la typographie, les jetons et la palette par défaut ; ce fichier nomme les rôles sémantiques (paper, ink, muted, accent, link, …). Pour appliquer une marque, modifiez style-guide.md ou exécutez le flux basé sur URL dans references/onboarding.md.
Lorsque les spécifications ci-dessous ou dans les références de type mentionnent "ink", "accent", "muted", etc., recherchez la valeur hexadécimale actuelle dans
style-guide.md.
Les extraits de référence de type écrivent les rôles comme des espaces réservés : {ink}, {ink @ 0.40} pour un rôle à une opacité, et {node-name}, {sublabel}, {eyebrow}, {arrow-label}, {title}, {callout} pour les polices. Résolvez chaque espace réservé par rapport à style-guide.md avant d'émettre.