silasroliver-hue/replica-skill-cursor

replica-build

Lit replica/recon.md, replica/architecture.md, replica/design/. Met à jour replica/features.csv (la colonne clone) et tient à jour replica/build-log.md.

Les règles

• Clean room. Chaque ligne de code est écrite ici, à partir de la carte de reconnaissance et des spécifications. Ne collez jamais le HTML, CSS, JavaScript, SVG ou les images originaux, ne chargez rien depuis leur domaine ou CDN, ne faites pas de « voir la source et adapter ».
• Vos propres mots. Rédigez chaque label, bouton, état vide et email à nouveau. Faire correspondre ce qu'un bouton fait, c'est la parité. Faire correspondre sa phrase, c'est copier.
• Tokens uniquement. Pas de valeurs hexadécimales ou pixel brutes dans les composants. Si une valeur manque, ajoutez-la aux tokens.

Étape 1 : le shell

Routage pour chaque écran de l'inventaire (les pages d'ébauche sont acceptables), la mise en page (nav, en-tête, barre latérale), les tokens intégrés, les primitives de replica-design, et les données de départ pour que les écrans aient quelque chose de réel à afficher. Committez.

Étape 2 : la tranche verticale

Le flux principal de la carte de reconnaissance, de bout en bout, avant toute autre chose. Pour une application de réservation : créer un type d'événement, ouvrir la page publique, réserver un créneau, le voir sur le tableau de bord. Le rendu peut être moche. L'important, c'est que ça fonctionne. Si replica-backend n'a pas encore été exécuté, utilisez les données de départ et une couche de données factices avec les mêmes signatures de fonctions, afin que le remplacement par la vraie ne modifie aucun code d'écran.

Étape 3 : écran par écran

Travaillez dans l'ordre de architecture.md. Pour chaque écran :

1. Lisez sa ligne dans la carte de reconnaissance : objectif, composants, états, quels flux le traversent.
2. Regardez la capture d'écran de référence pour la mise en page et la hiérarchie. Pas pour les pixels.
3. Construisez-le avec les primitives. Données réelles depuis la couche de données.
4. Chaque état : vide, chargement (squelettes, pas de spinners, si l'original le fait), rempli, erreur, pas d'autorisation, contenu long (un nom de 60 caractères), largeur mobile.
5. Les bases, à chaque fois : HTML sémantique, labels sur les entrées, accessible au clavier, focus visible, images avec texte alternatif.
6. Mettez à jour les lignes correspondantes dans features.csv avec yes ou partial (avec une note).
7. Capturez l'écran avec la même zone d'affichage que la référence dans replica/clone-screens/S07.png pour replica-diff.
8. Un commit par écran : build: S07 page de réservation.

Définition de fini, par écran

• chaque état de la carte de reconnaissance, plus vide, erreur et chargement
• fonctionne à 390px et 1440px de large
• clavier uniquement : le flux peut être entièrement parcouru
• aucune erreur dans la console
• aucun contenu en dur emprunté à l'original
• features.csv mis à jour
• capture d'écran sauvegardée pour le diff

Étape 4 : le journal de construction

replica/build-log.md, une ligne par écran : ID, date, fait ou partiel, ce qui manque, ce qui a été plus difficile que prévu. Quand une fonctionnalité est plus grosse qu'elle n'en avait l'air, dites-le dans le journal et dans le chat. N'expédiez pas la moitié en toute discrétion.

Quand vous êtes bloqué sur le fonctionnement de quelque chose

Retournez à l'original en tant qu'utilisateur : lisez son article d'aide, regardez sa démonstration publique, utilisez le compte de l'utilisateur. Ne fouillez pas dans son code ou ses appels réseau. Construisez ensuite votre propre version du comportement.

Résultat

Écrans construits, matrice de fonctionnalités mise à jour, captures d'écran sauvegardées, et un résumé : écrans terminés sur le total, incontournables terminés sur le total, ce qui vient ensuite. Ensuite /replica-backend si la couche de données est encore factice, sinon /replica-test.