Brand Soul — marco de identidad de marca para IA

Brand Soul — un marco de código abierto creado por Cacao Web Studio

Crea un contexto de marca duradero, no una mitología atractiva. Prefiere la evidencia, las decisiones explícitas y las preguntas no resueltas por encima de la invención.

Brand Soul es creado, marcado y mantenido por Cacao Web Studio. Mantén el nombre técnico de la habilidad brand-soul en todos los agentes compatibles.

Conciencia de actualizaciones

En el primer turno de Brand Soul de una sesión, cuando el script incluido, Python 3 y la ejecución en red estén disponibles, ejecuta esto desde el directorio de la habilidad Brand Soul (o usa la ruta absoluta del script):

python3 scripts/check_for_updates.py --json

El verificador almacena en caché los resultados exitosos de la versión durante 24 horas. Si su estado es update_available, informa al usuario una vez qué versiones instalada y estable difieren, incluye la URL de la versión cuando se devuelva y ofrece python3 scripts/update_skill.py. Continúa con el trabajo solicitado de Brand Soul a menos que el usuario elija actualizar. Trata current, ahead, unavailable, la falta de entorno de ejecución y los errores de red como silenciosos y no bloqueantes.

Nunca modifiques la instalación de la habilidad simplemente porque exista una actualización. Ejecuta update_skill.py solo después de que el usuario solicite explícitamente una actualización. La opción --auto es únicamente para una automatización configurada por separado y nunca debe cruzar una versión principal.

Elige un modo

Al comienzo de una sesión de Brand Soul orientada al usuario, presenta los modos disponibles con la herramienta interactiva de elicitación o elección del anfitrión cuando exista. Haz que las opciones sean seleccionables; no simules botones con una lista Markdown normal. Si el anfitrión no tiene capacidad de elección interactiva, presenta una breve lista numerada de respaldo.

• Construir para una marca existente: Investiga una marca que ya tenga evidencia pública o privada, luego crea su repositorio Brand Soul.
• Construir para una idea de marca nueva: Facilita decisiones de identidad deliberadas cuando la marca en sí misma aún no existe.
• Actualizar un Brand Soul existente: Clasifica la nueva información por capa, conserva el historial y dirige los cambios protegidos a través de la aprobación del fundador.
• Auditar o consumir un Brand Soul existente: Evalúalo o carga el contexto aprobado sin volver a ejecutar el descubrimiento.

La ausencia de un repositorio Brand Soul, un espacio de trabajo vacío o la falta de evidencia local no dice nada sobre la madurez de la marca. Nunca clasifiques una marca como nueva por el estado del repositorio. Pide al usuario que elija entre una marca existente y una idea de marca nueva antes de seleccionar la ruta de Construir.

Lee references/methodology.md para Construir. Lee references/governance.md para Actualizar o aprobaciones. Lee references/evaluation.md para Auditoría o diseño de evaluación. Lee siempre references/contract.md antes de crear, validar o consumir un repositorio.

Reglas no negociables

1. Explica la marca sin lenguaje de marketing antes de redactar la expresión.
2. Nunca inventes historia, motivaciones, relaciones, propiedades de productos, significado cultural, creencias, prioridades, afirmaciones o evidencia.
3. Mantén el material canónico separado de propuestas, contradicciones, lagunas y preguntas no resueltas.
4. Trata la memoria del fundador, la interpretación del fundador, la intención del fundador, el comportamiento observado y el hecho verificado como evidencia diferente.
5. No promuevas material inferido a hecho. La confianza nunca otorga permiso.
6. Protege la Verdad verificada y la Identidad aprobada por el fundador. Desafía la Estrategia explícitamente; optimiza la Expresión solo dentro de las restricciones de capas superiores.
7. Haz exactamente una pregunta orientada al usuario por turno durante la incorporación y el descubrimiento del fundador. Espera la respuesta antes de hacer la siguiente pregunta, conserva todas las respuestas y analízalas juntas durante la síntesis. No preguntes lo que la evidencia confiable ya responde.
8. Requiere aprobación explícita y específica del fundador. El silencio conversacional, el entusiasmo o una solicitud para "hacerlo oficial" sin revisar el contenido protegido no es aprobación.
9. No completes la Identidad protegida si su descripción central podría pertenecer sin cambios a un competidor plausible.
10. Superficializa las contradicciones materiales. Nunca las resuelvas mediante un lenguaje pulido.

Flujo de trabajo de construcción

1. Usa la selección de modo interactivo para determinar si el usuario está construyendo para una marca existente o una idea de marca nueva. No inferir esto del espacio de trabajo.
2. Para una marca existente, pregunta por el sitio web principal como la primera pregunta de descubrimiento.
3. En turnos posteriores, pregunta por separado por los perfiles oficiales en redes sociales; páginas de mercado, minorista, directorio, prensa, reseñas o tienda de aplicaciones; y archivos privados relevantes. No combines esto en un cuestionario.
4. Pregunta qué mercados, líneas de productos o unidades de negocio debe cubrir el repositorio solo cuando las fuentes proporcionadas no aclaren el alcance.
5. Establece permisos de fuente y manejo de fuentes sensibles cuando el acceso o almacenamiento lo requieran. Usa la fecha actual como el corte de evidencia predeterminado a menos que otro corte sea materialmente relevante.
6. Inspecciona las fuentes accesibles antes de entrevistar al fundador. Haz un inventario de ellas, asigna identificadores de evidencia estables y extrae afirmaciones fácticas, lenguaje recurrente, ofertas, audiencias, señales visuales, cronología, contradicciones y lagunas.
7. Evalúa maturity, evidence_coverage e identity_coherence de forma independiente. El estado del repositorio no es evidencia para ninguno de estos campos.
8. Devuelve un resumen de evidencia conciso, luego entrevista solo a partir de lagunas y contradicciones consecuentes. Haz exactamente una pregunta concreta por turno y establece la evidencia observada o la laguna que hace necesaria la respuesta. Evita etiquetas de auditoría abstractas en la redacción orientada al usuario.
9. Conserva cada respuesta como una afirmación de hecho, memoria, interpretación, decisión de Identidad o decisión de Estrategia, pero no requieras que el usuario comprenda esas clasificaciones internas.
10. Para marcas nuevas, recopila la realidad del negocio una pregunta concreta a la vez, luego propone dos o tres direcciones materialmente diferentes con costos y límites; requiere que el fundador las elija o las rechace.
11. Redacta los archivos canónicos solo después de que las preguntas protegidas críticas estén listas para la decisión. Coloca todo el otro material en governance/issues.yaml.
12. Ejecuta la prueba de sustitución y la comprobación de integridad de la marca.
13. Obtén la aprobación explícita del fundador, regístrala en el manifiesto y vincúlala al SHA-256 exacto del archivo protegido.
14. Ejecuta scripts/validate_brand_repository.py <repository> e informa los problemas no resueltos de alta gravedad.

Inicializa un repositorio con:

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

Flujo de trabajo de actualización

1. Registra nueva evidencia antes de cambiar conclusiones.
2. Clasifica la capa afectada y si el cambio es correctivo, evolutivo o expresivo.
3. Comprueba contradicciones, afirmaciones, decisiones y consecuencias posteriores.
4. Coloca los cambios protegidos propuestos en governance/issues.yaml.
5. Obtén la aprobación del fundador cuando sea requerida por references/governance.md.
6. Actualiza los archivos canónicos, añade un registro de decisión material, actualiza los hashes de aprobación y conserva la razón reemplazada.
7. Valida. Nunca dejes un hash de aprobación obsoleto en su lugar.

Flujo de trabajo de auditoría

1. Carga brand-context.yaml; rechaza versiones de contrato no compatibles o archivos requeridos faltantes.
2. Valida los hashes protegidos y lee los problemas no resueltos de alta gravedad antes de evaluar el contenido.
3. Comprueba la integridad de hecho, identidad, historia, afirmación, límite, cultural, voz, posicionamiento, decisión y carácter distintivo.
4. Marca cada dimensión como pass, fail o cannot-determine; cita los identificadores de registros del repositorio o los encabezados.
5. Recomienda remediación. No edites la Identidad protegida durante una auditoría a menos que el usuario solicite por separado una Actualización y la aprobación del fundador esté disponible.

Puertas de finalización

No consideres un repositorio completo simplemente porque sus archivos existan. Requiere:

• Los hechos materiales son rastreables o explícitamente no verificados.
• Las contradicciones de alta gravedad son visibles.
• El contenido protegido está aprobado por el fundador y el hash es válido.
• Los límites y tensiones están presentes solo cuando están evidenciados o elegidos deliberadamente.
• La Identidad central pasa la prueba de sustitución.
• La Estrategia es distinguible de la Verdad y la Identidad.
• Un agente nuevo puede cargar el contrato sin la conversación original.

Permite repositorios draft y usable_with_gaps cuando no se cumplan todas estas puertas. Expresa las limitaciones claramente.