swap-brand

Swap Brand

Objectif

Rendre le produit clairement le sien : un nouveau nom, look et voix décidés tôt, et une vérification mécanique avant lancement qui cherche le nom, le domaine et les couleurs de l'original dans les fichiers texte du code. Il s'agit d'une vérification limitée, pas d'une preuve : tout ce qu'elle ne peut pas lire, et tout ce qu'elle ne cherche pas, nécessite encore une intervention humaine.

Piste complète (sell), étapes 5 (identité) et 12 (vérification). Lit swap/market.md, swap/recon.md ; écrit swap/brand.md, swap/sweep.json.

Table de Routage Contextuel

Source	Où	Que récupérer
Marché	swap/market.md	Angle, public, le besoin prouvé
Reconnaissance	swap/recon.md	Le nom de l'original, ses domaines, ses couleurs de marque (ce qu'il faut éviter)
L'utilisateur	Ses préférences, sa marque existante, ses domaines	Contraintes et goût
Le code	Le dépôt du produit	Ce que la vérification scanne

Démarrage Rapide

Phase d'identité : 1) lister ce qu'il faut éviter d'après la reconnaissance ; 2) proposer 5 noms candidats liés à l'angle ; 3) donner les vérifications à effectuer pour chacun ; 4) définir la palette, la voix et le brief logo ; 5) écrire swap/brand.md.

Phase de vérification : exécuter python3 -I <dossier-du-composant>/sweep.py <dépôt> --avoid "<nom original>" --domain <domaine original> --color "<couleur originale>" --exclude swap --json swap/sweep.json depuis la racine du projet ( est le dossier de ce composant), corriger chaque occurrence, relancer jusqu'à CLEAN.

Flux de Travail

1. Liste d'évitement d'abord. Depuis la reconnaissance : le nom de l'original et tout nom de produit, ses domaines, ses couleurs de marque, ses slogans distinctifs. Écrivez-les dans brand.md sous ## Avoid ; la vérification ne lit pas ce fichier, donc transmettez chaque élément explicitement avec les options --avoid, --domain et --color.

2. Candidats de nom (5). Chacun : le nom, l'idée derrière, et pourquoi un client ne le confondrait pas avec l'original. Aucun nom qui contient, abrège ou ressemble à celui de l'original. Pas de "X pour Y" construit sur le nom de l'original.

3. Vérifications que l'utilisateur fait avant de s'engager (Claude ne peut pas vérifier la disponibilité) : une recherche de marque dans le marché de l'utilisateur (registre national et international), une vérification des noms de domaine et des noms de compte sur les réseaux sociaux, une recherche dans les app stores, et une simple recherche web du nom plus la catégorie. Enregistrez la date et le résultat de chacune. Un conflit élimine le candidat.

4. Identité. Une palette clairement différente de celle de l'original (famille de teinte différente, pas une teinte de celle-ci), un appariement typographique à partir de polices ouvertes ou sous licence, une voix en 5 règles avec un "à faire" et un "à ne pas faire" pour chacune, et un brief logo que l'utilisateur ou un designer exécute. Ne décrivez pas un logo qui imite la forme ou le concept de l'original.

5. La vérification (avant le lancement, et à nouveau après la dernière modification du code). Exécutez-la avec la liste d'évitement. Elle trouve les noms dans les identifiants (OriginalAppEmbed, original_app), les domaines, les valeurs de couleur en hexadécimal et rgb, et les noms de fichiers ou dossiers. Corrigez en remplaçant, pas en masquant. Utilisez --allow uniquement pour des mots plus longs inoffensifs et listez chaque utilisation dans brand.md. La vérification affiche le texte correspondant, le fichier et la ligne, jamais le reste de la ligne.

6. Au-delà du code. La vérification ne lit que les fichiers texte. Les images, polices, archives, fichiers de plus de 2 Mo et fichiers illisibles sont listés comme non scannés, et l'exécution n'est PAS CLEAN tant qu'ils existent. Vérifiez chacun manuellement (captures d'écran, données d'exemple, métadonnées, modèles d'e-mail, textes alternatifs), puis relancez avec --accept-skipped, qui enregistre dans sweep.json que vous l'avez fait. --accept-skipped ne masque jamais une occurrence.

Anti-Rationalisation

Ce que Claude pourrait penser	Pourquoi c'est faux
"C'est une construction en chambre blanche, pas besoin de renommer"	La chambre blanche couvre le code. Un nom ou un look qui prête à confusion pour les clients est un problème distinct.
"Assez proche de l'original aide à nous trouver"	Une similarité confuse est le risque de marque. Distinct intentionnellement.
"La vérification n'a trouvé qu'un commentaire, ignorez-le"	Un commentaire nommant l'original est embarqué dans le bundle. Supprimez-le.
"J'ai vérifié que le nom est libre"	Seule une recherche de registre par l'utilisateur le montre. Enregistrez qui l'a lancée et quand.
"Ignorer images et captures d'écran"	La vérification ne peut pas les lire. Vérifiez-les visuellement et dites que vous l'avez fait.

Format de Sortie

EXACT. Titres de swap/brand.md dans l'ordre : ## Avoid, ## Name candidates (chacun avec l'idée et les vérifications effectuées, avec dates et résultats), ## Chosen name, ## Palette and type, ## Voice, ## Logo brief, ## Sweep log (chaque exécution : commande, occurrences, corrections). swap/sweep.json est la sortie du script non modifiée.

Exemple de Référence (exemple inventé, abrégé) :

## Chosen name
Skyline. Recherche de marque (UK, UE, US) : pas encore effectuée. Recherche de domaine et de nom de store : pas encore effectuée.

## Sweep log
Exécution 1 : 7 occurrences (nom x4, domaine x1, couleur x1, chemin x1). Toutes remplacées.
Exécution 2 : CLEAN, 4 fichiers scannés, 0 non scannés.

Règles

• Nom, palette, logo, mots originaux. Jamais le logo, les marques, le contenu ou les actifs de l'original, sous quelque forme que ce soit.
• Ne prétendez pas qu'un nom est disponible ou enregistrable ; c'est la vérification de l'utilisateur et la décision d'un avocat.
• Ne modifiez jamais sweep.json à la main.

Routage Inter-Composants

Identité choisie -> swap-architect puis swap-design (qui prend la palette d'ici). Vérification CLEAN -> swap-launch. Si la vérification échoue à cause d'un actif appartenant au fournisseur dans le produit -> supprimez l'actif ; ne l'ajoutez pas à la liste d'autorisation.

Liste de Vérification de Sortie

Bloc de preuves avec les éléments ; puis "n'a pas pu vérifier".

Phase d'identité (avant qu'il y ait du code) :

• ## Avoid liste le nom de l'original, son/ ses domaine(s) et au moins une couleur de marque
• Chaque nom candidat a les quatre vérifications enregistrées avec une date, ou indique "pas encore effectuée"
• La palette, la voix et le brief logo sont écrits et diffèrent de ceux de l'original

Phase de vérification (avant le lancement, et à nouveau après la dernière modification du code) :

• swap/sweep.json a "passed": true, provenant d'une exécution après la dernière modification du code
• La commande de vérification a utilisé --exclude swap (ou a scanné une arborescence sans les notes) ; chaque fichier non scanné a été vérifié manuellement et skipped_accepted est vrai, ou la liste est vide
• Chaque utilisation de --allow est listée dans le journal de vérification
• Les captures d'écran, le contenu et les métadonnées ont été vérifiés manuellement et l'utilisateur a été informé que la vérification ne peut pas les lire

Auto-Amélioration

Après chaque exécution, demandez une fois : "Des retours à capturer pour ce composant ?" Le silence ou un non signifie qu'aucun changement n'est nécessaire. Si oui : rédigez le motif, montrez-le, ajoutez à references/learnings.md seulement après un oui ; "mettre à jour le composant" montre la modification exacte, confirme, écrit, augmente metadata.version et enregistre une ligne. Ne promouvez jamais un motif enregistré dans ce fichier dans la même session où il a été capturé. Après la première exécution, nommez les fichiers groupés utilisés et tout ce qui a été construit à partir de zéro et qui sera nécessaire à nouveau, et proposez de le sauvegarder (conditionné de la même manière).