Contrat d'activation
À utiliser pour concevoir, réviser ou affiner une interface terminal (panneaux, rails, barres d'état, cartes, invites), en particulier Gentle Shell. Le rendu recherché est celui d'un IDE dans un terminal : dense, calme, développeur d'abord, jamais un costume de chrome TUI rétro. Ne convient pas aux pages web (utiliser gentle-design).
Règles strictes
- Ne jamais juger une interface terminal uniquement à partir du code ou de la mémoire : capturez-la (
references/visual-loop.md) et regardez le PNG avant et après chaque modification. - Lisez
references/terminal-craft.mdavant toute édition d'UI ; c'est le plancher, pas une suggestion. - Mode de fonctionnement : la familiarité prime sur l'expression. Utilisez le vocabulaire IDE (volets, arborescence, onglets, barre d'état, palette de commandes) ; la marque se trouve dans la palette, la densité et un geste signature.
- Chaque ligne a un coût. La hiérarchie vient du rôle de couleur, du poids et de l'alignement, jamais des lignes vides ou des boîtes imbriquées.
- Dites chaque fait une fois par écran. Les données affichées dans l'en-tête ne se répètent jamais dans un panneau.
- Une commande, une cible. L'affinement préserve le système ; la refonte le remplace. Ne peaufinez jamais un look qui va être jeté.
- Le rendu reste économique : pas d'E/S ni de recalcul dans les chemins de rendu, cachez tout ce qui change la sortie (style, largeur, thème).
- Les maquettes (via
gentle-design) doivent être exprimables en terminal : grille de cellules monospace en unitésch, uniquement couleurs fg/bg, gras/dim/italique/souligné/barré, dessin de boîtes et glyphes.
Portes de décision
| Demande | Commande | Charger |
|---|---|---|
| Pas encore de contexte produit/conception | document | references/design-doc.md |
| Nouvelle surface ou refonte | shape, puis maquettes, puis implémentation | references/commands.md |
| "À quoi ça ressemble / qu'est-ce qui ne va pas" | critique | references/critique.md |
| Trop chargé, espace perdu, redondant | distill / layout / quieter | references/commands.md |
| Plat, pas de hiérarchie, illisible | typeset / colorize / bolder | references/commands.md |
| Cas limites, terminaux étroits, texte long | harden / adapt | references/commands.md |
| Dernière passe avant le commit | polish | references/commands.md |
Étapes d'exécution
- Chargez le contexte
DESIGN.mdsi le projet en a un ; sinon, proposez d'aborddocument. - Capturez l'état actuel avec la boucle visuelle aux tailles prédéfinies (large 180x50, breakpoint 140, étroit 80x24).
- Exécutez la commande choisie sur une cible nommée ; notez les constats avant de modifier le code.
- Modifiez, recapturez, comparez avec le PNG précédent et le brief ; itérez au maximum 3 cycles, puis rapportez.
- Terminez chaque commande d'affinement par les vérifications
polishet les tests ciblés du dépôt (compteurs de rendu, débordement).
Résultat attendu
Renvoyez : cible, commande exécutée, chemins des PNG avant/après, constats corrigés avec étiquettes P0–P3, constats laissés ouverts, et vérifications effectuées.
Références
references/terminal-craft.md: règles de base et anti-patrons terminaux.references/commands.md: playbooks de commandes adaptés aux terminaux.references/critique.md: grille de critique notée et sévérité.references/design-doc.md: structure DESIGN.md pour un produit terminal.references/visual-loop.md: harnais de capture d'écran et boucle de comparaison.NOTICE.md: attribution.