Brand Soul – Open-Source Framework für Markenidentität

Brand Soul – ein von Cacao Web Studio erstelltes Open-Source-Framework

Erzeuge dauerhafte Markenkontexte, keine attraktive Mythologie. Bevorzuge Beweise, explizite Entscheidungen und offene Fragen gegenüber Erfindungen.

Brand Soul wird von Cacao Web Studio erstellt, gebrandet und gewartet. Behalte den technischen Skill-Namen brand-soul über kompatible Agenten hinweg bei.

Update-Awareness

Beim ersten Brand-Soul-Durchlauf einer Sitzung – sofern das gebündelte Skript, Python 3 und die Netzwerkausführung verfügbar sind – führe Folgendes aus dem Brand-Soul-Skill-Verzeichnis (oder mit absolutem Pfad des Skripts) aus:

python3 scripts/check_for_updates.py --json

Der Prüfer speichert erfolgreiche Ergebnisse für 24 Stunden zwischen. Wenn der Status update_available ist, teile dem Benutzer einmal mit, welche installierte und welche stabile Version voneinander abweichen, füge die Release-URL bei (sofern zurückgegeben) und biete python3 scripts/update_skill.py an. Setze die angeforderte Brand-Soul-Arbeit fort, es sei denn, der Benutzer entscheidet sich für ein Update. Behandle current, ahead, unavailable, fehlende Laufzeitumgebung und Netzwerkfehler als still und nicht blockierend.

Ändere niemals die Skill-Installation nur, weil ein Update existiert. Führe update_skill.py nur aus, nachdem der Benutzer ausdrücklich ein Update angefordert hat. Die Option --auto ist ausschließlich für eine separat konfigurierte Opt-in-Automatisierung gedacht und darf niemals eine Major-Version überspringen.

Wähle einen Modus

Zu Beginn einer benutzerorientierten Brand-Soul-Sitzung präsentiere die verfügbaren Modi mit dem interaktiven Auswahl- oder Wahlwerkzeug des Hosts, sofern vorhanden. Mache die Auswahlmöglichkeiten antippbar; simuliere keine Schaltflächen mit einer gewöhnlichen Markdown-Liste. Wenn der Host keine interaktive Auswahlmöglichkeit bietet, präsentiere eine kurze nummerierte Fallback-Liste.

• Für eine bestehende Marke aufbauen: Recherchiere eine Marke, die bereits öffentliche oder private Beweise hat, und erstelle dann ihr Brand-Soul-Repository.
• Für eine neue Markenidee aufbauen: Ermögliche bewusste Identitätsentscheidungen, wenn die Marke selbst noch nicht existiert.
• Ein bestehendes Brand Soul aktualisieren: Klassifiziere neue Informationen nach Schichten, bewahre den Verlauf und leite geschützte Änderungen über die Gründerfreigabe.
• Ein bestehendes Brand Soul überprüfen oder nutzen: Bewerte es oder lade den genehmigten Kontext, ohne die Discovery erneut durchzuführen.

Ein fehlendes Brand-Soul-Repository, ein leerer Arbeitsbereich oder fehlende lokale Beweise sagen nichts über die Markenreife aus. Klassifiziere eine Marke niemals anhand des Repository-Zustands als neu. Frage den Benutzer, ob er sich für eine bestehende Marke oder eine neue Markenidee entscheidet, bevor du den Build-Pfad wählst.

Lies references/methodology.md für den Build. Lies references/governance.md für Update oder Genehmigungen. Lies references/evaluation.md für Audit oder Evaluationsdesign. Lies immer references/contract.md, bevor du ein Repository erstellst, validierst oder nutzt.

Nicht verhandelbare Regeln

1. Erkläre die Marke ohne Marketingsprache, bevor du den Ausdruck formulierst.
2. Erfinde niemals Geschichte, Motivationen, Beziehungen, Produkteigenschaften, kulturelle Bedeutung, Überzeugungen, Prioritäten, Behauptungen oder Beweise.
3. Halte kanonisches Material getrennt von Vorschlägen, Widersprüchen, Lücken und offenen Fragen.
4. Behandle Gründererinnerung, Gründerinterpretation, Gründerabsicht, beobachtetes Verhalten und verifizierte Tatsache als unterschiedliche Beweise.
5. Befördere abgeleitetes Material nicht zur Tatsache. Vertrauen gibt niemals die Erlaubnis dazu.
6. Schütze verifizierte Wahrheit und gründerfreigegebene Identität. Hinterfrage Strategie explizit; optimiere Ausdruck nur innerhalb der Einschränkungen höherer Schichten.
7. Stelle während des Onboardings und der Gründer-Discovery genau eine benutzerorientierte Frage pro Durchgang. Warte auf die Antwort, bevor du die nächste Frage stellst, bewahre alle Antworten auf und analysiere sie gemeinsam während der Synthese. Frage nicht, was zuverlässige Beweise bereits beantworten.
8. Fordere eine explizite, abgegrenzte Gründerfreigabe. Gesprächiges Schweigen, Begeisterung oder die Aufforderung, „es offiziell zu machen“, ohne den geschützten Inhalt zu überprüfen, ist keine Freigabe.
9. Vervollständige keine geschützte Identität, wenn ihre zentrale Beschreibung unverändert zu einem plausiblen Wettbewerber gehören könnte.
10. Mache materielle Widersprüche sichtbar. Löse sie niemals durch geschliffene Formulierungen auf.

Build-Workflow

1. Verwende die interaktive Modusauswahl, um zu ermitteln, ob der Benutzer für eine bestehende Marke oder eine neue Markenidee baut. Leite dies nicht aus dem Arbeitsbereich ab.
2. Frage bei einer bestehenden Marke als erste Discovery-Frage nach der primären Website.
3. Frage in späteren Durchgängen separat nach offiziellen Social-Media-Profilen; Marktplatz-, Händler-, Verzeichnis-, Presse-, Bewertungs- oder App-Store-Seiten; sowie relevanten privaten Dateien. Kombiniere diese nicht zu einem Fragebogen.
4. Frage, welche Märkte, Produktlinien oder Geschäftsbereiche das Repository abdecken soll, nur dann, wenn die gelieferten Quellen den Umfang nicht klar machen.
5. Lege Quellberechtigungen und den Umgang mit sensiblen Quellen fest, wenn Zugriff oder Speicherung dies erfordern. Verwende das aktuelle Datum als Standard-Evidenz-Stichtag, es sei denn, ein anderer Stichtag ist materiell relevant.
6. Untersuche zugängliche Quellen, bevor du den Gründer befragst. Erfasse sie, weise stabile Evidenz-IDs zu und extrahiere faktische Behauptungen, wiederkehrende Sprache, Angebote, Zielgruppen, visuelle Signale, Chronologie, Widersprüche und Lücken.
7. Bewerte maturity, evidence_coverage und identity_coherence unabhängig voneinander. Der Repository-Zustand ist für keines dieser Felder ein Beweis.
8. Erstelle eine prägnante Evidenzzusammenfassung und befrage dann ausschließlich zu den daraus resultierenden Lücken und Widersprüchen. Stelle genau eine konkrete Frage pro Durchgang und nenne den beobachteten Beweis oder die Lücke, die die Antwort notwendig macht. Vermeide abstrakte Audit-Bezeichnungen in der benutzerorientierten Formulierung.
9. Speichere jede Antwort als Tatsachenbehauptung, Erinnerung, Interpretation, Identitätsentscheidung oder Strategieentscheidung, aber verlange nicht, dass der Benutzer diese internen Klassifikationen versteht.
10. Sammle bei neuen Marken die geschäftliche Realität schrittweise mit einer konkreten Frage pro Durchgang und schlage dann zwei oder drei materiell unterschiedliche Richtungen mit Kosten und Grenzen vor; fordere den Gründer auf, sie auszuwählen oder abzulehnen.
11. Erstelle kanonische Dateien erst, nachdem kritische geschützte Fragen entscheidungsreif sind. Platziere alles andere Material in governance/issues.yaml.
12. Führe den Substitutionstest und die Markenintegritätsprüfung durch.
13. Erhalte explizite Gründerfreigabe, dokumentiere sie im Manifest und binde sie an den exakten SHA-256 der geschützten Datei.
14. Führe scripts/validate_brand_repository.py <repository> aus und melde ungelöste Probleme mit hohem Schweregrad.

Initialisiere ein Repository mit:

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

Update-Workflow

1. Registriere neue Beweise, bevor du Schlussfolgerungen änderst.
2. Klassifiziere die betroffene Schicht und ob die Änderung korrigierend, evolutionär oder ausdrucksbezogen ist.
3. Prüfe Widersprüche, Behauptungen, Entscheidungen und nachgelagerte Konsequenzen.
4. Platziere vorgeschlagene geschützte Änderungen in governance/issues.yaml.
5. Erhalte Gründerfreigabe, wenn dies von references/governance.md gefordert wird.
6. Aktualisiere kanonische Dateien, füge einen materiellen Entscheidungsdatensatz hinzu, aktualisiere Freigabe-Hashes und bewahre die ersetzte Begründung auf.
7. Validiere. Lasse niemals einen veralteten Freigabe-Hash bestehen.

Audit-Workflow

1. Lade brand-context.yaml; lehne nicht unterstützte Vertragsversionen oder fehlende erforderliche Dateien ab.
2. Validiere geschützte Hashes und lies ungelöste Probleme mit hohem Schweregrad, bevor du den Inhalt bewertest.
3. Überprüfe die Integrität von Fakten, Identität, Geschichte, Behauptungen, Grenzen, Kultur, Stimme, Positionierung, Entscheidungen und Unterscheidbarkeit.
4. Markiere jede Dimension mit pass, fail oder cannot-determine; zitiere Repository-Datensatz-IDs oder Überschriften.
5. Empfehle Abhilfemaßnahmen. Bearbeite keine geschützte Identität während eines Audits, es sei denn, der Benutzer fordert separat ein Update an und die Gründerfreigabe ist verfügbar.

Abschlusskriterien

Bezeichne ein Repository nicht allein deshalb als abgeschlossen, weil seine Dateien existieren. Erfordere:

• Materielle Tatsachen sind nachvollziehbar oder explizit nicht verifiziert.
• Widersprüche mit hohem Schweregrad sind sichtbar.
• Geschützte Inhalte sind gründerfreigegeben und hash-validiert.
• Grenzen und Spannungen sind nur vorhanden, wenn sie belegt oder bewusst gewählt sind.
• Die zentrale Identität besteht den Substitutionstest.
• Strategie ist von Wahrheit und Identität unterscheidbar.
• Ein neuer Agent kann den Vertrag ohne die ursprüngliche Konversation laden.

Erlaube draft- und usable_with_gaps-Repositorien, wenn diese Kriterien nicht alle erfüllt sind. Gib die Einschränkungen klar an.