Brand Soul

Brand Soul — Cacao Web Studio가 만든 오픈소스 프레임워크

매력적인 신화가 아닌, 지속 가능한 브랜드 컨텍스트를 만드세요. 발명보다 증거, 명시적 결정, 미해결 질문을 선호하세요.

Brand Soul은 Cacao Web Studio에서 만들고 브랜딩하며 유지 관리합니다. 호환 에이전트 전반에서 기술적인 Skill 이름 brand-soul을 유지하세요.

업데이트 인식

세션의 첫 Brand Soul 턴에, 번들 스크립트, Python 3, 네트워크 실행이 가능할 때 Brand Soul Skill 디렉토리에서 다음을 실행하세요(또는 스크립트의 절대 경로 사용):

python3 scripts/check_for_updates.py --json

체커는 성공적인 릴리스 결과를 24시간 동안 캐시합니다. 상태가 update_available이면 설치된 버전과 안정 버전이 다르다는 것을 사용자에게 한 번 알리고, 반환될 때 릴리스 URL을 포함하며 python3 scripts/update_skill.py를 제안하세요. 사용자가 업데이트를 선택하지 않는 한 요청된 Brand Soul 작업을 계속하세요. current, ahead, unavailable, 런타임 누락, 네트워크 오류는 자동으로 무시하고 차단하지 마세요.

단순히 업데이트가 존재한다는 이유만으로 Skill 설치를 수정하지 마세요. 사용자가 명시적으로 업데이트를 요청한 후에만 update_skill.py를 실행하세요. --auto 옵션은 별도로 구성된 옵트인 자동화 전용이며 주요 버전을 절대 넘지 않아야 합니다.

모드 선택

사용자 대면 Brand Soul 세션 시작 시, 호스트의 대화형 유도 또는 선택 도구가 있을 때 사용 가능한 모드를 제시하세요. 선택 항목을 탭 가능하게 만드세요. 일반 Markdown 목록으로 버튼을 시뮬레이션하지 마세요. 호스트에 대화형 선택 기능이 없으면 짧은 번호 매기기 대체 방식을 제시하세요.

• 기존 브랜드 구축: 공개 또는 비공개 증거가 있는 브랜드를 조사한 후 Brand Soul 저장소를 만듭니다.
• 신규 브랜드 아이디어 구축: 브랜드 자체가 아직 존재하지 않을 때 의도적인 정체성 선택을 용이하게 합니다.
• 기존 Brand Soul 업데이트: 새 정보를 레이어별로 분류하고, 기록을 보존하며, 보호된 변경 사항을 창업자 승인을 통해 라우팅합니다.
• 기존 Brand Soul 감사 또는 소비: 평가하거나 승인된 컨텍스트를 로드하여 발견 프로세스를 다시 실행하지 않습니다.

Brand Soul 저장소가 없거나, 작업 공간이 비어 있거나, 로컬 증거가 없다고 해서 브랜드의 성숙도가 결정되지는 않습니다. 저장소 상태만으로 브랜드를 신규로 분류하지 마세요. Build 경로를 선택하기 전에 사용자에게 기존 브랜드와 신규 브랜드 아이디어 중 하나를 선택하도록 요청하세요.

Build를 위해 references/methodology.md를 읽으세요. Update 또는 승인을 위해 references/governance.md를 읽으세요. Audit 또는 평가 설계를 위해 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. 개선을 권장하세요. 사용자가 별도로 Update를 요청하고 창업자 승인이 가능하지 않은 한 감사 중에 보호된 정체성을 편집하지 마세요.

완료 게이트

파일이 존재한다고 해서 저장소가 완료되었다고 말하지 마세요. 다음을 요구하세요:

• 중요 사실이 추적 가능하거나 명시적으로 검증되지 않았습니다.
• 높은 심각도 모순이 표시됩니다.
• 보호된 콘텐츠가 창업자 승인을 받았고 해시가 유효합니다.
• 경계와 긴장은 증거가 있거나 의도적으로 선택된 경우에만 존재합니다.
• 중앙 정체성이 대체 테스트를 통과합니다.
• 전략이 진실 및 정체성과 구별 가능합니다.
• 새로운 에이전트가 원래 대화 없이 계약을 로드할 수 있습니다.

이러한 게이트가 모두 충족되지 않을 때 draft 및 usable_with_gaps 저장소를 허용하세요. 제한 사항을 명확히 명시하세요.