Brand Soul — Cacao Web Studio 推出的開源品牌靈魂框架

Brand Soul — Cacao Web Studio 推出的開源框架

建立持久的品牌脈絡，而非吸引人的神話。偏好證據、明確決策與未解決問題，而非憑空想像。

Brand Soul 由 Cacao Web Studio 創立、品牌化與維護。在相容代理之間請保持技術技能名稱為 brand-soul。

更新提醒

在 Brand Soul 每次工作階段的第一輪，當 bundled 腳本、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 選項僅供獨立設定的選擇性自動化使用，且絕不能跨越主要版本。

選擇模式

在與使用者互動的 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. 取得明確的創辦人核准，記錄在 manifest 中，並將其綁定到確切的受保護檔案 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 狀態的儲存庫。並清楚說明其限制。