ToshqulovLaziz/naqsh

Que fait naqsh ?

v0.6. <skill> ci-dessous désigne le répertoire de base de cette compétence. Les scripts nécessitent Node ≥ 22 et un Chrome/Edge local ; rien à installer.

1. Routage

Indiquez la surface et le mode sur une seule ligne avant toute autre chose.

Surface	Signaux	À lire
page	landing, portfolio, marketing, produit, one-pager	references/page.md
app	ERP, admin, tableau de bord, tableau, formulaire, paramètres, CRUD	references/app.md

Mode	Touche au code ?	Résultat
build	oui, nouvelle UI	UI + DESIGN.md
redesign	oui ; conserve comportement, données et contenu	UI + DESIGN.md
audit	non	constats classés avec fichier:ligne et correctif

Lisez toujours references/rules.md avant d'exécuter les contrôles. Si personne ne peut répondre aux questions, décidez et notez pourquoi.

2. Contexte

• Stack, styles, tokens existants, polices et leur chargement, changement de thème (+ sa clé localStorage), i18n (+ clé de locale), routes, commande de build.
• Ce qui peut changer et ce qui ne doit pas changer (autres pages, composants partagés, logique métier).
• Locales : si l'une d'elles utilise le cyrillique, chaque police choisie doit le prendre en charge.

3. Référence initiale

Exécutez les deux contrôles sur l'état actuel et conservez le résultat : c'est l'« avant » du rapport, et cela révèle souvent de vrais bogues (polices jamais chargées, contraste, débordement).

node <skill>/scripts/lint.mjs <projectRoot>
node <skill>/scripts/inspect.mjs http://localhost:PORT --surface <surface> --routes ... --locales ... --themes ...

Mode audit : suivez references/audit.md à partir d'ici et arrêtez-vous. Ne modifiez pas les fichiers du projet.

4. Inventaire

• Sujet : 8 à 12 éléments propres à ce produit ou cette personne (noms, lieux, chiffres réels, travaux réels).
• Contenu : pour chaque emplacement visuel, notez real (réel), picture (pouvant être sourcé honnêtement) ou absent. N'inventez jamais de preuve : pas de faux logos, témoignages, métriques ou captures d'écran.
• Public et tâche : qui regarde, ce qu'ils doivent faire ou apprendre en premier.

5. Direction (traitée, guidée par le goût)

node <skill>/scripts/deal.mjs --surface <page|app> --options 3 --project <projectRoot>

Le script note la bibliothèque par rapport au profil de goût de l'utilisateur (~/.naqsh/taste.json, surchargeable par projet dans <project>/.naqsh/taste.json) et aux choix récents, et distribue 3 directions issues de familles différentes.

• Si l'utilisateur est présent, montrez les trois (idée, typographie, palette, héroïne) et laissez-le choisir. Sinon, choisissez la meilleure adaptation au contenu et expliquez pourquoi.
• deal.mjs --pick <id> imprime la fiche complète (sections, animation, import de police, tokens clair/sombre) et enregistre le choix. Construisez à partir de la fiche : son type, sa palette et son héroïne sont le contrat. Adaptez les tailles et sections au contenu réel ; ne déviez qu'avec une raison écrite (par exemple, contenu manquant).
• page : lisez aussi references/page.md. app : lisez aussi references/app.md ; le bloc system de la fiche décide du shell, de la densité, des KPI, du tableau, du statut et du style des graphiques.

Brief vs goût. Les adjectifs d'un brief (« calme », « minimal », « professionnel ») décrivent la tâche, pas l'apparence. Répondez-y par la clarté, la densité et la retenue dans l'animation, pas en choisissant une direction que le profil de goût évite. N'abandonnez jamais une direction uniquement parce qu'elle est plus audacieuse que l'adjectif du brief ; si le brief et le goût sont vraiment en conflit, choisissez pour le goût et notez-le dans DESIGN.md.

Retour sur le goût. Quand l'utilisateur dit ce qu'il aime ou n'aime pas dans un résultat, mettez à jour ~/.naqsh/taste.json (boldness 1–5, temperature warm|cool|neutral|any, typeStyles, likes, avoid, notes) et informez-le. Les préférences qui ne valent que pour une surface vont dans son bloc page ou app, qui surcharge les clés générales.

6. Socle (jamais dérogé ; les scripts vérifient la plupart des points)

• Texte visible issu de l'i18n dans chaque locale ; pas de copie inventée.
• Les polices se chargent et couvrent chaque script de la locale ; la plus longue locale tient à 375 px.
• @import de police au-dessus de @import "tailwindcss" ; styles d'élément à l'intérieur de @layer base.
• Pas de défilement horizontal de la page ; overflow-x: clip, jamais hidden/100vw.
• Contraste ≥ 4,5:1 (3:1 pour les grands textes) dans chaque thème ; focus visible ; cibles ≥ 24 px (44 recommandé).
• prefers-reduced-motion respecté ; pas de transition: all ; animer transform/opacity.
• Nouveaux tokens cadrés pour que les pages non touchées ne changent pas.

7. Signes d'interface générée (réflexe : ne déroger que lorsque la fiche distribuée le permet)

Indigo/violet par défaut de Tailwind ; lueur, verre, blobs d'aurore, icônes en orbite, boutons scintillants, texte dégradé ; intertitres en capitales espacées au-dessus de chaque titre ; grilles de cartes identiques (coins arrondis + ombre) ; bande héroïque de métriques rondes ; le même nom ou titre répété dans un écran. L'échelle audacieuse, la couleur forte et le contraste serif/sans ne sont pas des signes — la timidité est aussi un échec : si le résultat pourrait passer pour un modèle, poussez l'idée de la fiche plus fort.

8. Boucle de construction

1. Tokens (cadrés) → écran principal / héroïne → le reste.
2. Après chaque étape : lint. Après l'écran principal : construire, prévisualiser, inspect sur cette route uniquement (largeur maximale + minimale, première locale, les deux thèmes). À la fin : la matrice complète. Ouvrez les captures d'écran et regardez chaque fois. Corrigez, répétez — au maximum 3 cycles après la première passe complète. Lisez uniquement les fichiers que vous modifiez ; gardez les tours courts.
3. Passe détail : lisez references/components.md ; chaque contrôle est construit selon elle (aucun native-control laissé sans dérogation), le moment signature existe. Exécutez inspect ... --details et ouvrez chaque recadrage dans <out>/details/ ; corrigez jusqu'à ce que chacun paraisse intentionnel à 2x.
4. Une fois la passe détail terminée et la construction à 0 échec du socle, écrivez DESIGN.md (brouillon) et lancez le relecteur dans un contexte frais — outil Agent, subagent_type: "naqsh:naqsh-reviewer" — avec : la racine du projet, la surface, le mode, l'ID de direction, le chemin <skill>, le dossier de captures d'écran (avec details/), l'URL de prévisualisation et les indicateurs inspect. Appliquez ses correctifs floor (socle), idea (idée) et fidelity (fidélité) (les autres à votre jugement), relancez les contrôles. Un cycle de relecture ; un second seulement si le verdict était rework. Si aucun outil Agent n'est disponible, faites la relecture vous-même à partir de agents/naqsh-reviewer.md après avoir revu les captures d'écran.
5. Terminez avec 0 échec du socle, chaque réflexe corrigé ou dérogé, et le build du projet réussi. Arrêtez le serveur de prévisualisation.

9. Rapport

Écrivez DESIGN.md dans la racine du projet (ou là où l'utilisateur le dit) : options distribuées et le choix, phrase d'idée, tokens, typographie, décisions clés, le moment signature, compteurs avant → après, dérogations avec raisons, contrôles jugés, éléments ouverts. Terminez en demandant à l'utilisateur ce qu'il a aimé et ce qu'il n'a pas aimé, afin d'améliorer le profil de goût.