Brand Soul

Brand Soul — un cadre open-source créé par Cacao Web Studio

Créez un contexte de marque durable, pas une mythologie attrayante. Préférez les preuves, les décisions explicites et les questions non résolues à l'invention.

Brand Soul est créé, développé et maintenu par Cacao Web Studio. Conservez le nom technique de la compétence brand-soul sur les agents compatibles.

Sensibilisation aux mises à jour

Au premier tour de Brand Soul d'une session, lorsque le script fourni, Python 3 et l'exécution réseau sont disponibles, exécutez ceci depuis le répertoire de la compétence Brand Soul (ou utilisez le chemin absolu du script) :

python3 scripts/check_for_updates.py --json

Le vérificateur met en cache les résultats de version réussis pendant 24 heures. Si son statut est update_available, informez l'utilisateur une fois des versions installée et stable qui diffèrent, incluez l'URL de la version lorsqu'elle est renvoyée, et proposez python3 scripts/update_skill.py. Continuez le travail demandé à Brand Soul sauf si l'utilisateur choisit de mettre à jour. Traitez les statuts current, ahead, unavailable, l'absence d'environnement d'exécution et les erreurs réseau comme silencieux et non bloquants.

Ne modifiez jamais l'installation de la compétence simplement parce qu'une mise à jour existe. Exécutez update_skill.py uniquement après que l'utilisateur a explicitement demandé une mise à jour. L'option --auto est uniquement destinée à une automatisation distincte sur option et ne doit jamais franchir une version majeure.

Choisir un mode

Au début d'une session Brand Soul orientée utilisateur, présentez les modes disponibles avec l'outil d'élicitation ou de choix interactif de l'hôte lorsqu'il en existe un. Rendez les choix cliquables ; ne simulez pas de boutons avec une simple liste Markdown. Si l'hôte n'a pas de capacité de choix interactive, présentez un court menu numéroté de repli.

• Construire pour une marque existante: Recherchez une marque qui possède déjà des preuves publiques ou privées, puis créez son repository Brand Soul.
• Construire pour une nouvelle idée de marque: Facilitez des choix d'identité délibérés lorsque la marque elle-même n'existe pas encore.
• Mettre à jour un Brand Soul existant: Classez les nouvelles informations par couche, préservez l'historique et acheminez les modifications protégées via l'approbation du fondateur.
• Auditer ou consommer un Brand Soul existant: Évaluez-le ou chargez le contexte approuvé sans relancer la découverte.

Un repository Brand Soul manquant, un espace de travail vide ou une absence de preuves locales ne dit rien de la maturité de la marque. Ne classez jamais une marque comme nouvelle à partir de l'état du repository. Demandez à l'utilisateur de choisir entre une marque existante et une nouvelle idée de marque avant de sélectionner le chemin de construction.

Lisez references/methodology.md pour la construction. Lisez references/governance.md pour la mise à jour ou les approbations. Lisez references/evaluation.md pour l'audit ou la conception de l'évaluation. Lisez toujours references/contract.md avant de créer, valider ou consommer un repository.

Règles non négociables

1. Expliquez la marque sans langage marketing avant de rédiger l'expression.
2. N'inventez jamais d'historique, de motivations, de relations, de propriétés de produits, de signification culturelle, de croyances, de priorités, d'affirmations ou de preuves.
3. Gardez le matériel canonique séparé des propositions, des contradictions, des lacunes et des questions non résolues.
4. Traitez la mémoire du fondateur, l'interprétation du fondateur, l'intention du fondateur, le comportement observé et les faits vérifiés comme des preuves différentes.
5. Ne promouvez pas le matériel déduit au rang de fait. La confiance n'accorde jamais la permission.
6. Protégez la Vérité vérifiée et l'Identité approuvée par le fondateur. Contestez explicitement la Stratégie ; optimisez l'Expression uniquement dans les contraintes des couches supérieures.
7. Posez exactement une question par tour lors de l'intégration et de la découverte du fondateur. Attendez la réponse avant de poser la question suivante, préservez toutes les réponses et analysez-les ensemble lors de la synthèse. Ne demandez pas ce que des preuves fiables répondent déjà.
8. Exigez une approbation explicite et circonscrite du fondateur. Le silence conversationnel, l'enthousiasme ou une demande de « rendre officiel » sans examen du contenu protégé ne constitue pas une approbation.
9. Ne finalisez pas l'Identité protégée si sa description centrale pourrait appartenir sans changement à un concurrent plausible.
10. Mettez en surface les contradictions matérielles. Ne les résolvez jamais par un langage poli.

Workflow de construction

1. Utilisez la sélection de mode interactive pour déterminer si l'utilisateur construit pour une marque existante ou une nouvelle idée de marque. Ne déduisez pas cela de l'espace de travail.
2. Pour une marque existante, demandez le site web principal comme première question de découverte.
3. Lors des tours suivants, demandez séparément les profils sociaux officiels ; les pages de marketplace, de revendeur, d'annuaire, de presse, d'avis ou d'app store ; et les fichiers privés pertinents. Ne les combinez pas en un questionnaire.
4. Demandez quels marchés, gammes de produits ou unités commerciales le repository doit couvrir uniquement lorsque les sources fournies ne rendent pas la portée claire.
5. Établissez les autorisations de source et le traitement des sources sensibles lorsque l'accès ou le stockage l'exige. Utilisez la date actuelle comme date limite de preuve par défaut, sauf si une autre date importe matériellement.
6. Inspectez les sources accessibles avant d'interviewer le fondateur. Inventoriez-les, attribuez des identifiants de preuve stables et extrayez les affirmations factuelles, le langage récurrent, les offres, les publics, les signaux visuels, la chronologie, les contradictions et les lacunes.
7. Évaluez maturity, evidence_coverage et identity_coherence indépendamment. L'état du repository n'est une preuve pour aucun de ces champs.
8. Fournissez un bref résumé des preuves, puis interrogez uniquement à partir des lacunes et contradictions conséquentes. Posez exactement une question concrète par tour et indiquez la preuve observée ou la lacune qui rend la réponse nécessaire. Évitez les étiquettes d'audit abstraites dans le langage destiné à l'utilisateur.
9. Préservez chaque réponse comme une affirmation factuelle, un souvenir, une interprétation, une décision d'Identité ou une décision de Stratégie, mais n'exigez pas que l'utilisateur comprenne ces classifications internes.
10. Pour les nouvelles marques, recueillez la réalité commerciale une question concrète à la fois, puis proposez deux ou trois directions matériellement différentes avec leurs coûts et limites ; exigez que le fondateur les choisisse ou les rejette.
11. Rédigez les fichiers canoniques uniquement après que les questions critiques protégées sont prêtes pour décision. Mettez tout autre matériel dans governance/issues.yaml.
12. Exécutez le test de substitution et le contrôle d'intégrité de la marque.
13. Obtenez l'approbation explicite du fondateur, enregistrez-la dans le manifeste et liez-la au SHA-256 exact du fichier protégé.
14. Exécutez scripts/validate_brand_repository.py <repository> et signalez les problèmes de haute sévérité non résolus.

Initialisez un repository avec :

python3 scripts/initialize_brand_repository.py <output-parent> --brand-name "Example Brand" --founder "Founder Name"

Workflow de mise à jour

1. Enregistrez les nouvelles preuves avant de modifier les conclusions.
2. Classez la couche affectée et si le changement est correctif, évolutif ou expressif.
3. Vérifiez les contradictions, les affirmations, les décisions et les conséquences en aval.
4. Placez les modifications protégées proposées dans governance/issues.yaml.
5. Obtenez l'approbation du fondateur lorsque references/governance.md l'exige.
6. Mettez à jour les fichiers canoniques, ajoutez un enregistrement de décision matérielle, rafraîchissez les hachages d'approbation et préservez la justification remplacée.
7. Validez. Ne laissez jamais un hachage d'approbation obsolète en place.

Workflow d'audit

1. Chargez brand-context.yaml ; rejetez les versions de contrat non prises en charge ou les fichiers obligatoires manquants.
2. Validez les hachages protégés et lisez les problèmes de haute sévérité non résolus avant d'évaluer le contenu.
3. Vérifiez l'intégrité des faits, de l'identité, de l'histoire, des affirmations, des limites, de la culture, de la voix, du positionnement, des décisions et de la distinction.
4. Marquez chaque dimension pass, fail ou cannot-determine ; citez les identifiants ou les titres des enregistrements du repository.
5. Recommandez des corrections. Ne modifiez pas l'Identité protégée lors d'un audit, sauf si l'utilisateur demande séparément une mise à jour et que l'approbation du fondateur est disponible.

Conditions d'achèvement

Ne considérez pas un repository comme complet simplement parce que ses fichiers existent. Exigez :

• Les faits matériels sont traçables ou explicitement non vérifiés.
• Les contradictions de haute sévérité sont visibles.
• Le contenu protégé est approuvé par le fondateur et validé par hachage.
• Les limites et tensions sont présentes uniquement lorsqu'elles sont prouvées ou délibérément choisies.
• L'Identité centrale réussit le test de substitution.
• La Stratégie est distincte de la Vérité et de l'Identité.
• Un agent frais peut charger le contrat sans la conversation originale.

Autorisez les repositories draft et usable_with_gaps lorsque toutes ces conditions ne sont pas remplies. Énoncez clairement les limitations.