Brand Soul

Brand Soul — uma estrutura de código aberto criada pela Cacao Web Studio

Crie contexto de marca durável, não mitologia atrativa. Prefira evidências, decisões explícitas e perguntas não resolvidas à invenção.

Brand Soul é criado, marcado e mantido por Cacao Web Studio. Mantenha o nome técnico da Skill brand-soul em agentes compatíveis.

Consciência de atualização

No primeiro turno do Brand Soul de uma sessão, quando o script incluído, Python 3 e execução de rede estiverem disponíveis, execute isto do diretório da Skill Brand Soul (ou use o caminho absoluto do script):

python3 scripts/check_for_updates.py --json

O verificador armazena em cache resultados de lançamento bem-sucedidos por 24 horas. Se seu status for update_available, informe ao usuário uma vez quais versões instalada e estável diferem, inclua o URL do lançamento quando retornado e ofereça python3 scripts/update_skill.py. Continue o trabalho solicitado do Brand Soul, a menos que o usuário escolha atualizar. Trate current, ahead, unavailable, tempo de execução ausente e erros de rede como silenciosos e não bloqueantes.

Nunca modifique a instalação da Skill meramente porque existe uma atualização. Execute update_skill.py apenas depois que o usuário solicitar explicitamente uma atualização. A opção --auto é exclusivamente para uma automação configurada separadamente com aceitação e nunca deve cruzar uma versão principal.

Escolha um modo

No início de uma sessão do Brand Soul voltada para o usuário, apresente os modos disponíveis com a ferramenta interativa de elicitação ou escolha do host quando ela existir. Torne as escolhas tocáveis; não simule botões com uma lista Markdown comum. Se o host não tiver capacidade de escolha interativa, apresente uma breve fallback numerada.

• Construir para uma marca existente: Pesquise uma marca que já tenha evidências públicas ou privadas e, em seguida, crie seu repositório Brand Soul.
• Construir para uma nova ideia de marca: Facilite escolhas de identidade deliberadas quando a marca em si ainda não existe.
• Atualizar um Brand Soul existente: Classifique novas informações por camada, preserve o histórico e direcione alterações protegidas por meio da aprovação do fundador.
• Auditar ou consumir um Brand Soul existente: Avalie-o ou carregue contexto aprovado sem reexecutar a descoberta.

Um repositório Brand Soul ausente, um espaço de trabalho vazio ou evidências locais ausentes não dizem nada sobre a maturidade da marca. Nunca classifique uma marca como nova com base no estado do repositório. Peça ao usuário para escolher entre uma marca existente e uma nova ideia de marca antes de selecionar o caminho Construir.

Leia references/methodology.md para Construir. Leia references/governance.md para Atualizar ou aprovações. Leia references/evaluation.md para Auditoria ou design de avaliação. Sempre leia references/contract.md antes de criar, validar ou consumir um repositório.

Regras inegociáveis

1. Explique a marca sem linguagem de marketing antes de redigir a expressão.
2. Nunca invente história, motivações, relacionamentos, propriedades de produtos, significado cultural, crenças, prioridades, alegações ou evidências.
3. Mantenha material canônico separado de propostas, contradições, lacunas e perguntas não resolvidas.
4. Trate memória do fundador, interpretação do fundador, intenção do fundador, comportamento observado e fato verificado como evidências diferentes.
5. Não promova material inferido a fato. Confiança nunca concede permissão.
6. Proteja a Verdade verificada e a Identidade aprovada pelo fundador. Desafie a Estratégia explicitamente; otimize a Expressão apenas dentro das restrições de camadas superiores.
7. Faça exatamente uma pergunta voltada para o usuário por turno durante a integração e descoberta do fundador. Aguarde a resposta antes de fazer a próxima pergunta, preserve todas as respostas e analise-as juntas durante a síntese. Não pergunte o que evidências confiáveis já respondem.
8. Exija aprovação explícita e delimitada do fundador. Silêncio conversacional, entusiasmo ou um pedido para "oficializar" sem revisar o conteúdo protegido não é aprovação.
9. Não complete a Identidade protegida se sua descrição central pudesse pertencer inalterada a um concorrente plausível.
10. Traga à tona contradições materiais. Nunca as resolva por meio de redação polida.

Fluxo de trabalho de Construção

1. Use a seleção interativa de modo para determinar se o usuário está construindo para uma marca existente ou uma nova ideia de marca. Não infira isso do espaço de trabalho.
2. Para uma marca existente, peça o site principal como a primeira pergunta de descoberta.
3. Em turnos posteriores, peça separadamente perfis oficiais de mídias sociais; páginas de marketplace, varejista, diretório, imprensa, avaliações ou loja de aplicativos; e arquivos privados relevantes. Não combine isso em um questionário.
4. Pergunte quais mercados, linhas de produtos ou unidades de negócios o repositório deve cobrir apenas quando as fontes fornecidas não tornarem o escopo claro.
5. Estabeleça permissões de fontes e tratamento de fontes sensíveis quando o acesso ou armazenamento exigir. Use a data atual como corte de evidência padrão, a menos que outro corte importe materialmente.
6. Inspecione fontes acessíveis antes de entrevistar o fundador. Inventarie-as, atribua IDs de evidência estáveis e extraia alegações factuais, linguagem recorrente, ofertas, públicos, sinais visuais, cronologia, contradições e lacunas.
7. Avalie maturity, evidence_coverage e identity_coherence independentemente. O estado do repositório não é evidência para nenhum desses campos.
8. Retorne um breve resumo de evidências, então entreviste apenas a partir de lacunas e contradições consequentes. Faça exatamente uma pergunta concreta por turno e declare a evidência observada ou lacuna que torna a resposta necessária. Evite rótulos abstratos de auditoria na linguagem voltada para o usuário.
9. Preserve cada resposta como uma alegação de fato, memória, interpretação, decisão de Identidade ou decisão de Estratégia, mas não exija que o usuário entenda essas classificações internas.
10. Para novas marcas, reúna a realidade do negócio uma pergunta concreta de cada vez, então proponha duas ou três direções materialmente diferentes com custos e limites; exija que o fundador escolha ou rejeite.
11. Redija arquivos canônicos somente depois que perguntas protegidas críticas estiverem prontas para decisão. Coloque todo o outro material em governance/issues.yaml.
12. Execute o teste de substituição e a Verificação de Integridade da Marca.
13. Obtenha aprovação explícita do fundador, registre-a no manifesto e vincule-a ao SHA-256 exato do arquivo protegido.
14. Execute scripts/validate_brand_repository.py <repository> e relate problemas de alta gravidade não resolvidos.

Inicialize um repositório com:

python3 scripts/initialize_brand_repository.py <output-parent> --brand-name "Nome da Marca" --founder "Nome do Fundador"

Fluxo de trabalho de Atualização

1. Registre novas evidências antes de mudar conclusões.
2. Classifique a camada afetada e se a mudança é corretiva, evolutiva ou expressiva.
3. Verifique contradições, alegações, decisões e consequências posteriores.
4. Coloque mudanças propostas protegidas em governance/issues.yaml.
5. Obtenha aprovação do fundador quando exigido por references/governance.md.
6. Atualize arquivos canônicos, adicione um registro de decisão material, atualize hashes de aprovação e preserve a justificativa substituída.
7. Valide. Nunca deixe um hash de aprovação obsoleto no lugar.

Fluxo de trabalho de Auditoria

1. Carregue brand-context.yaml; rejeite versões de contrato não suportadas ou arquivos obrigatórios ausentes.
2. Valide hashes protegidos e leia problemas não resolvidos de alta gravidade antes de avaliar o conteúdo.
3. Verifique a integridade de fato, identidade, história, alegação, limite, cultural, voz, posicionamento, decisão e distinção.
4. Marque cada dimensão como pass, fail ou cannot-determine; cite IDs de registros do repositório ou títulos.
5. Recomende remediação. Não edite a Identidade protegida durante uma auditoria, a menos que o usuário solicite separadamente uma Atualização e a aprovação do fundador esteja disponível.

Portões de conclusão

Não considere um repositório completo meramente porque seus arquivos existem. Exija:

• Fatos materiais são rastreáveis ou explicitamente não verificados.
• Contradições de alta gravidade estão visíveis.
• Conteúdo protegido é aprovado pelo fundador e com hash válido.
• Limites e tensões estão presentes apenas quando evidenciados ou deliberadamente escolhidos.
• A Identidade central passa no teste de substituição.
• Estratégia é distinguível de Verdade e Identidade.
• Um agente novo pode carregar o contrato sem a conversa original.

Permita repositórios draft e usable_with_gaps quando esses portões não forem todos atendidos. Declare as limitações claramente.