品牌之魂

Brand Soul — 一个由 Cacao Web Studio 创建的开源框架

创建持久的品牌上下文，而不是迷人的神话。偏好证据、明确的决策和未解决的问题，而非凭空创造。

Brand Soul 由 Cacao Web Studio 创建、推广并维护。在兼容的代理中，请保持技术技能名称为 brand-soul。

更新感知

在会话的第一次 Brand Soul 交互时，当捆绑的脚本、Python 3 和网络执行可用时，从 Brand Soul 技能目录（或使用脚本的绝对路径）运行以下命令：

python3 scripts/check_for_updates.py --json

检查器会将成功的发布结果缓存 24 小时。如果其状态为 update_available，则向用户告知已安装版本和稳定版本之间存在差异，在返回时包含发布 URL，并提供 python3 scripts/update_skill.py。除非用户选择更新，否则继续执行所请求的 Brand Soul 工作。将 current、ahead、unavailable、缺失运行时和网络错误视为静默且非阻塞。

永远不要仅仅因为存在更新就修改技能安装。仅在用户明确请求更新时运行 update_skill.py。--auto 选项仅供单独配置的 opt-in 自动化使用，并且绝不能跨越主版本。

选择模式

在面向用户的 Brand Soul 会话开始时，当存在宿主提供的交互式提示或选择工具时，展示可用的模式。使选项可点击；不要使用普通的 Markdown 列表模拟按钮。如果宿主没有交互式选择能力，则提供一个简短的编号备用列表。

• 为现有品牌构建：研究一个已有公开或私有证据的品牌，然后创建其 Brand Soul 仓库。
• 为新品牌创意构建：在品牌本身尚不存在时，促进审慎的身份选择。
• 更新现有 Brand Soul：按层分类新信息，保留历史，并通过创始人审批路由受保护的更改。
• 审计或消费现有 Brand Soul：评估它或加载已批准的上下文，无需重新运行发现。

缺少 Brand Soul 仓库、空的工作区或缺失本地证据并不能说明品牌的成熟度。切勿根据仓库状态将品牌分类为新的。在选择构建路径之前，请用户选择是现有品牌还是新品牌创意。

阅读 references/methodology.md 以了解构建方法。阅读 references/governance.md 以了解更新或审批。阅读 references/evaluation.md 以了解审计或评估设计。在创建、验证或消费仓库之前，务必阅读 references/contract.md。

不可协商的规则

1. 在起草表达之前，先不用营销语言解释品牌。
2. 永远不要编造历史、动机、关系、产品属性、文化含义、信仰、优先事项、主张或证据。
3. 将规范材料与提议、矛盾、差距和未解决的问题分开保存。
4. 将创始人的记忆、创始人的解读、创始人的意图、观察到的行为和可验证的事实视为不同的证据。
5. 不要将推断出的材料提升为事实。自信永远不能给予许可。
6. 保护经过验证的真理和创始人批准的身份。明确挑战策略；仅在高层约束内优化表达。
7. 在入职和创始人发现期间，每轮只问一个面向用户的问题。等待答案后再问下一个问题，保留所有答案，并在综合时一起分析。不要问可靠证据已经回答了的问题。
8. 要求明确、范围明确的创始人批准。未审查受保护内容的对话沉默、热情或“使其正式化”的请求不构成批准。
9. 如果受保护身份的核心描述可以不加更改地适用于一个合理的竞争对手，则不要完成该身份。
10. 指出实质性的矛盾。永远不要通过美化措辞来解决它们。

构建工作流

1. 使用交互式模式选择来确定用户是为现有品牌还是新品牌创意进行构建。不要从工作区推断这一点。
2. 对于现有品牌，将主要网站作为第一个发现问题提问。
3. 在后续轮次中，分别询问官方社交媒体资料；市场、零售商、目录、新闻稿、评论或应用商店页面；以及相关的私有文件。不要将它们合并成一个问卷。
4. 仅当所提供的来源未明确范围时，才询问仓库应涵盖哪些市场、产品线或业务部门。
5. 当需要访问或存储时，建立源权限和敏感源处理。除非其他截止日期有实质意义，否则使用当前日期作为默认证据截止日期。
6. 在接受创始人面试之前检查可访问的来源。对其进行盘点，分配稳定的证据 ID，并提取事实性声明、重复出现的语言、优惠、受众、视觉信号、时间线、矛盾和差距。
7. 独立评估 maturity、evidence_coverage 和 identity_coherence。仓库状态不是这些字段中任何一个的证据。
8. 返回一份简洁的证据摘要，然后仅根据重要的差距和矛盾进行面试。每轮只问一个具体问题，并说明使答案成为必要的观察到的证据或差距。避免在面向用户的措辞中使用抽象的审计标签。
9. 将每个答案保留为事实声明、记忆、解读、身份决定或策略决定，但不要要求用户理解这些内部分类。
10. 对于新品牌，一次问一个具体问题来收集业务现实，然后提出两个或三个实质不同的方向，并附上成本和边界；要求创始人选择或拒绝它们。
11. 仅在关键受保护问题做出决定后起草规范文件。将所有其他材料放入 governance/issues.yaml。
12. 运行替代测试和品牌完整性检查。
13. 获得明确的创始人批准，将其记录在清单中，并将其绑定到确切的受保护文件 SHA-256。
14. 运行 scripts/validate_brand_repository.py <repository> 并报告未解决的高严重性问题。

使用以下命令初始化仓库：

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

更新工作流

1. 在改变结论之前注册新证据。
2. 分类受影响的层以及更改是修正性的、演进性的还是表达性的。
3. 检查矛盾、声明、决定和下游后果。
4. 将提议的受保护更改放入 governance/issues.yaml。
5. 当 references/governance.md 要求时，获得创始人批准。
6. 更新规范文件，添加实质性决策记录，刷新批准哈希，并保留被取代的论证依据。
7. 验证。永远不要留下过时的批准哈希。

审计工作流

1. 加载 brand-context.yaml；拒绝不支持的合约版本或缺少必需文件。
2. 验证受保护哈希，并在评估内容之前读取未解决的高严重性问题。
3. 检查事实、身份、故事、声明、边界、文化、声音、定位、决策和独特性完整性。
4. 将每个维度标记为 pass、fail 或 cannot-determine；引用仓库记录 ID 或标题。
5. 推荐补救措施。除非用户单独请求更新并且创始人批准可用，否则不要在审计期间编辑受保护的身份。

完成门控

不要仅仅因为文件存在就声称仓库完成。要求：

• 实质性事实可追溯或明确未验证。
• 高严重性矛盾可见。
• 受保护内容已获创始人批准且哈希有效。
• 边界和紧张关系仅在存在证据或经过深思熟虑的选择时才存在。
• 核心身份通过了替代测试。
• 策略与真理和身份可区分。
• 一个新代理无需原始对话即可加载合约。

当这些门控并非全部满足时，允许使用 draft 和 usable_with_gaps 仓库。明确说明限制。