Que fait DanLogo · Soft Order 柔性秩序 ?
Organique dans la forme, précis dans l'exécution : poussé doucement, aligné avec exactitude ; en train de se faire, une seule chose reste inachevée.
La direction Soft Order de la série danlogo. Elle définit le caractère et la qualité, pas la forme, la couleur ou la technique : le style est verrouillé au niveau du langage formel — arcs, grappes de modules, contrastes, surfaces plates, et un ordre invisible — la forme concrète est à réinventer pour chaque projet. Elle s'inscrit dans la lignée de l'abstraction biomorphique + le modernisme organique + le design procédural, avec des racines dans le "sheng sheng" du Yi Jing et la "résonance de l'esprit" de Xie He : la forme est le résultat d'un processus et de règles. Issue de la déconstruction du projet EonPoint "01 Yuansheng" (cases/).
Sans limite de secteur : l'utilisateur choisit en fonction de son esthétique ; le secteur influe uniquement sur le thème, pas sur le style.
À lire en premier
Avant de commencer un projet, lisez dans l'ordre les trois premiers chapitres sur le style ; le quatrième se lit à partir de la phase 6 :
references/philosophy.md— Coordonnées philosophiques et huit principes de conception : pourquoi ce designreferences/style-dna.md— Composition centrale "groupe et écart", langage formel verrouillé, huit gènes, potentiomètres et pierre de touche : à quoi cela ressemblereferences/creative-methods.md— Sept méthodes créatives et anti-homogénéisation : comment inventer du nouveau à chaque foisreferences/style-extension.md— Extension du style : système, mises en situation, présentation (phases 6-8)
references/exemplars.md (généalogie stylistique : œuvres d'art, d'architecture, d'objets, de marques dans la même veine, et "quel chemin suivre selon l'ambiance souhaitée") et cases/index.md (thèmes déjà utilisés) se lisent après la phase 2, une fois la liste des thèmes candidats établie — pour éliminer les réponses par défaut et les thèmes en conflit. Les lire avant vous influencerait. Les cas complets ne se lisent que lorsque vous avez besoin de référence sur "jusqu'où aller", et seulement pour en emprunter la méthode, pas la forme. Les autres fichiers se lisent à la phase correspondante (voir tableau).
Trois niveaux d'exigences
| Niveau | Contenu | Peut-il changer ? |
|---|---|---|
| Qualité (commune à la série) | references/quality-gates.md | Chaque projet doit les passer |
| Gènes du style (ce style) | "Groupe et écart" et huit gènes de style-dna.md + huit auto-vérifications de philosophy.md | Par défaut respecté ; ajuster sur demande explicite de l'utilisateur et noter dans decisions.md |
| Zone de liberté créative | Processus (thème), langage formel, nombre de parties, manière de souligner, intensité, température de couleur, personnalité des caractères, composition, matériau | À réinventer pour chaque projet ; au moins deux "potentiomètres" doivent être clairement différents de tous les cas déjà réalisés |
Trois rappels :
- C'est d'abord un graphisme. Un graphisme composé de plusieurs parties doit se lire comme une chose ou une image, avec un contour, une surface ; pas un tas de pièces, pas une variation de lettres, de mots ou de signes de ponctuation, pas un assemblage de lignes (cf.
quality-gates.md"Comment juger si c'est un graphisme"). - Jugez par le caractère, pas par les éléments. Les formes, processus, couleurs et caractères des cas concrets sont les réponses de cette marque-là, pas une prescription du style.
- Les règles doivent exister, mais être invisibles. Ne pas pouvoir énoncer les règles, c'est du bricolage ; voir la grille, c'est de la rigidité. Ce style se tient entre les deux : les règles sont exactes, chaque individu conserve une minuscule marge de déviation.
Neuf phases
Détails, règles de numérotation, conditions de sortie dans references/workflow.md. Chaque phase se termine par une confirmation explicite de l'utilisateur ; l'utilisateur peut à tout moment revenir en arrière, ajouter, modifier, fusionner.
| Phase | Quoi faire | Production par round | À lire |
|---|---|---|---|
| 1 Brief | L'utilisateur fournit les infos ; l'IA pose les questions manquantes en une fois (≤10), doit demander "quel processus est en train de se produire dans la marque" | Carte de brief | workflow.md, philosophy.md §2 |
| 2 Concept | Trouver d'abord le processus, puis la forme ; après la liste des candidats, lire les exemples et l'index des cas | 5 cartes concept (chacune avec croquis en noir et blanc), modifiables, ajoutables, fusionnables | creative-methods.md, exemplars.md, cases/index.md, quality-gates.md (auto-vérification graphisme du croquis) |
| 3 Prototype | Pour chaque concept retenu, générer des formes ; ne travailler que la forme, d'abord en noir et blanc ; essayer obligatoirement la connexion, le rythme des espacements, la règle des intervalles, la "chose ouverte" | ≥3 prototypes par concept + vérification de non-redondance | style-dna.md, craft.md, quality-gates.md |
| 4 Raffinement graphique | Écrire les règles → les appliquer exactement → réintroduire la déviation minimale → schéma de construction, version petite taille | Graphisme raffiné + liste de règles | craft.md, quality-gates.md, creative-methods.md méthodes 2-4 |
| 5 Finalisation | Police sur mesure + palette de couleurs en même temps : forme souple, caractères durs ; couleurs nommées d'après des objets | 2-3 combinaisons "police + couleur" par graphisme + vérification complète de non-redondance | craft.md, style-dna.md |
| 6 Système | Combinaisons, changement de couleurs, espacement, taille minimale, usages interdits, graphisme auxiliaire, animation | Jeu complet SVG/PNG | deliverables.md, style-extension.md |
| 7 Mises en situation | Choisir 6-10 scénarios selon le secteur | Illustrations des scénarios | deliverables.md, style-extension.md |
| 8 Présentation | Document de présentation + notes de discours + dossier des fichiers sources + re-vérification de non-redondance | Présentation | deliverables.md, style-extension.md, adapters/ |
| 9 Rétrospective | Demander activement si ce projet peut optimiser le skill | Suggestion de modifications, à écrire après approbation de l'utilisateur | workflow.md §9 |
Tout au long du projet
- Archivage du projet : un dossier par projet et un fichier
decisions.md(première ligne :skill: danlogo-softorder v<version>), qui note ce qui a été montré à chaque round, les mots de l'utilisateur, ce qui a été validé et rejeté. Si vous reprenez un projet existant, lisez-le d'abord. - Structure d'abord : avant la phase 5, examinez la structure en noir et blanc ; l'accent du style est d'abord établi par la position et la relation, la couleur ne fait que renforcer, donc pas de couleur avant la phase 5.
- Écrivez les règles : dès la phase 3, chaque prototype est accompagné d'une règle ; à partir de la phase 4, les règles sont paramétrées et générées par code, modifiez les règles, pas les formes individuellement.
- Rejet = retour en arrière, pas d'ajout : changez de thème ou de prototype, n'ajoutez pas de décoration sur l'image existante ; "trop régulier" = réintroduire la déviation, "assemblage" = unifier les règles.
- Vérification de non-redondance trois fois : préliminaire après les prototypes, complète avant la finalisation, re-vérification avant la présentation (
quality-gates.md). - Regardez les rendus en vrai : pour juger si c'est beau, basez-vous toujours sur les images rendues, y compris la miniature en 16 px et les jonctions agrandies à 400%.
- Communication : utilisez le langage de l'utilisateur. À chaque round, dites d'abord en une phrase ce qui a été fait, puis listez les propositions numérotées avec une phrase de concept, donnez une recommandation et une raison, demandez si c'est verrouillé, modifié ou continué. Pour les retours courts, consultez d'abord
references/feedback-playbook.mdet "mots flous" dansstyle-dna.md. - Les données client ne sont placées que dans le dossier du projet, pas dans le skill.
Quand plusieurs styles danlogo coexistent
Si l'utilisateur nomme un style, utilisez ce skill. Si le decisions.md du projet spécifie un skill, suivez-le. Si rien n'est spécifié et que plusieurs styles danlogo sont installés, listez d'abord les styles installés, demandez à l'utilisateur de choisir, puis commencez.
Outils et fichiers
scripts/: outils génériques — génération géométrique et SVG (geom.py), feuille de comparaison (sheet.py), SVG vers PNG (render.sh), tableau de vérification du graphisme et de la lisibilité (review.py), mises en situation (mockup.py) ; ce style a des outils géométriques flexibles spécifiques — transitions tangentielles et groupes organiques (cells.py,geo.py), résolution de déviation minimale (solve.py), moteur de traits et contours pour police sur mesure (type5.py,outline4.py). Voirscripts/README.md. Copiez-les danssrc/du projet.examples/eonpoint-yuansheng/src/: code de génération complet du cas EonPoint. Apprenez son approche d'ingénierie (paramétrisation des règles, résolution de déviation minimale, correction visuelle des caractères, export batch, schéma de construction), ne réutilisez pas ses formes ni ses polices.PROMPT-CARD.md: carte de prompt du style, à copier-coller à une IA qui n'a pas installé ce skill.adapters/for-claude.md,adapters/for-codex.md: différences entre les outils AI pour voir les images, faire des présentations, prévisualiser des pages web.evals/briefs.md: briefs de test pour vérifier que ce skill ne fait pas toutes les marques identiques.
Les cinq fichiers de references/ marqués danlogo-core (workflow, quality-gates, craft, deliverables, feedback-playbook) sont communs à toute la série danlogo, cohérents entre tous les styles ; les quatre chapitres propres à ce style sont philosophy, style-dna, creative-methods, style-extension : les trois premiers concernent le logo lui-même, le quatrième l'esthétique du système, des mises en situation et de la présentation, pour que l'ensemble du design émane du même caractère que le logo.