r3xsean/design-process

Processus de conception

L'utilisateur décide de la direction et du goût. Les modèles jugent de l'exécution : la tâche peut-elle être accomplie, les chiffres sont-ils vrais, quelque chose casse-t-il, se cache-t-il ou induit-il en erreur ? Un score, un conseil ou un consensus de modèles ne choisit jamais entre des directions, ne les fusionne pas et ne rejette pas une décision enregistrée.

Si le projet possède sa propre compétence de conception, suivez-la ; elle peut vous renvoyer ici pour une phase.

Les fichiers du projet

Dans docs/design/, sauf si le AGENTS.md du projet nomme un autre emplacement pour ces fichiers :

• product-brief.md : vérité produit. Qui l'utilise, ce que chaque surface doit permettre de faire (sa question directrice et son mode : Opérer, Lire ou Persuader), données et états, contenu et limites de confiance. Si le projet a déjà un PRODUCT.md, le brief y renvoie au lieu de le répéter.
• DESIGN.md : les décisions de l'utilisateur, les exceptions, les écrans de référence approuvés et le journal des réactions. Une décision enregistrée l'emporte sur votre préférence. Là où aucune n'est enregistrée, l'apparence est libre ; l'interface utilisateur actuelle est une preuve, pas une décision.
• harness.md : comment les écrans et prototypes s'exécutent et sont capturés : commandes, scénarios, fenêtres d'affichage, applications concurrentes, destination des captures.
• runs/<YYYY-MM-DD-nom>/run.md : question d'une exécution, ce qui est fixé et ouvert, limites connues, membres du conseil et cible, clé de position, résultat.

Les modèles pour ces quatre fichiers se trouvent dans templates/. Si l'un des trois premiers fichiers manque, initialisez d'abord. Chaque exécution, y compris celle qui saute l'initialisation, commence son propre run.md. Les captures, manifestes, registres de résultats et feuilles de variantes vont dans le dossier ignoré par git nommé par harness.md. Les packs du conseil vont en dehors du dépôt, dans le bloc-notes temporaire de la session ou le dossier temporaire.

Les règles propres au projet priment sur cette compétence : son AGENTS.md concernant les dépendances, les serveurs de développement et ce qui est commité. Lorsque l'exécution a besoin de quelque chose que ces règles interdisent ou réservent à la discussion, demandez à l'utilisateur avant de le faire.

Flux

• Nouvelle UI : initialisation → exploration → l'utilisateur choisit → raffinement → conseil → approuver une référence → vérification → livraison via le chemin de déploiement du projet.
• UI existante : initialisation → conseil → approbation → livraison. Lorsque l'utilisateur souhaite d'abord des changements visibles, raffinez avant le conseil.

Entrez à la phase que la demande nomme ; une modification mineure entre au raffinement.

Phase	Lire d'abord
Initialisation	references/bootstrap.md, puis references/harness-contract.md pour chaque capacité nécessaire à l'exécution
Exploration	references/explore.md
Raffinement	references/refine.md, et references/craft.md avant la première modification de l'UI
Conseil	references/council.md
Utilisation d'une autre compétence de conception	references/integrations.md, avant de l'invoquer

Membres du conseil. Lorsque l'exécution atteindra le conseil, demandez à l'utilisateur au début qui y siège (le modèle et l'effort de raisonnement de chaque membre), à moins qu'il ne les ait déjà nommés. Suggérez des membres de différents fournisseurs. Enregistrez les membres dans run.md et utilisez exactement ceux-ci pour toute l'exécution. Si un membre n'est pas disponible, dites-le ; ne le remplacez jamais.

Approuver une référence. Seuls les mots de l'utilisateur approuvent un écran ; les scores ne remplacent jamais cela. Copiez ses captures dans docs/design/references/ et listez-les sous Écrans de référence dans DESIGN.md, en indiquant pour quoi chacun est la référence.

Vérification. Après la première référence approuvée, un agent neuf conçoit une surface qui n'a pas encore été conçue, à partir uniquement de cette compétence, des fichiers du projet et du harnais, et liste chaque point où il a dû deviner. Montrez le résultat à l'utilisateur. Corrigez chaque supposition dans le fichier qui aurait dû y répondre, ou enregistrez-la dans run.md comme ouverte. Terminé lorsque l'utilisateur a réagi et que chaque supposition est corrigée ou enregistrée.

Enregistrer les réactions

Chaque fois que l'utilisateur réagit à une conception, à n'importe quelle phase :

1. Ajoutez une ligne au journal des réactions de DESIGN.md par réaction : date (UTC), surface et fenêtre d'affichage, conception et exécution de capture concernées, mots de l'utilisateur cités exactement, type, portée, statut observé.
   • Type : aime (garder), n'aime pas (modifier) ou défaut (une tâche a échoué ou quelque chose s'est cassé ; ajoutez-le également au registre des résultats). Une réaction peut aimer une partie et en détester une autre ; nommez chaque partie. Une fonctionnalité pas encore construite n'est pas une réaction : listez-la sous les limites connues dans run.md.
   • Portée est ce que l'utilisateur a indiqué : cet élément, ce type de surface, ou à l'échelle du site. S'il n'en a indiqué aucune, c'est l'élément. Ne l'élargissez jamais vous-même.
   • Ce que vous avez modifié en réponse va dans le registre des résultats, pas dans la ligne.
2. Promouvez une ligne en Décision lorsque l'utilisateur la formule de manière générale. Lorsque la même réaction se reproduit sur une deuxième surface, demandez si elle s'applique généralement et ne promouvez que sur un oui. Marquez la ligne promu avec un lien.
3. Lorsqu'une réaction contredit une décision, demandez laquelle l'emporte, puis modifiez ou supprimez l'ancienne décision et marquez les lignes perdantes remplacé.

Terminé lorsque chaque réaction a une ligne et que chaque promotion cite la déclaration générale de l'utilisateur ou son oui.

Confidentialité

Les captures utilisent des données de test, des données de départ ou un compte de démonstration, jamais le compte personnel de l'utilisateur ni les enregistrements de personnes réelles. Rien montrant des données personnelles ou du contenu pour adultes ne va dans un pack du conseil, une capture de référence ou un commit.