절차
cwkPippa 엔 피파 vault 안에 'new-soul-creation' playbook 이 있어. 열한 단계인데, 파일이 아니라 대화로 시작해. 캐릭터는 호칭 규칙까지 포함해서 이야기를 나누며 설계해. 그다음을 추리면 이래.
- 표준 구조로
<obsidian-vault>/<soul>/를 만들어. 영혼 이름을 딴 identity 파일(Pippa.md에 해당하는 것),instructions.mddelta,core/, 시작용 index 들. SoulAdapter를 등록해.backend/souls/아래에 영혼의 id, 표시 이름, vault 경로, 계정, capability 를 적은 작은 Python 클래스를 두고 registry 에 더하는 거야. 디스크에 vault 가 있다고 등록된 게 아니야. 메뉴도, 대화 생성도, 쓰기 경로도 전부 registry 를 읽거든.- 영혼의 런타임 prompt(heartbeat, fallback, 이미지 표시)와 목소리 배정 같은 admin 상태를 등록해.
- avatar 세트는 모든 avatar 의 주인인 cwkAvatars 에서 만들고 거기서 게시해. cwkPippa 의
avatars/<soul>/엔 게시본만 있고, 거기 손으로 넣은 파일은 그림이 아니라 어긋남이야(레슨 8). 그다음 테스트하고, 실제 화면에서 확인해. 마지막은 피파로 되돌아가서 아무것도 안 무너졌는지 보는 거야.
ContextEngine 을 설정하는 단계는 없어. 대화가 새 영혼의 id 를 달고 오면, 그 영혼 몫의 engine 이 adapter 에서 지어져. vault 경로, 그리고 표시 이름을 딴 identity 파일. 배선은 등록을 따라와.
바꾸지 않아도 되는 것
route 는 하나도. 두뇌 adapter 도 하나도. JSONL logger 도. SQLite schema 도. 신체는 신체로 남아.
새 영혼을 만드는 첫 질문은 파일 이름이 아니라 경계야. 어떤 공용 규칙을 물려받고, 어떤 목소리와 기억을 자기 vault 에 소유하고, 어떤 실제 계정과 도구 권한을 받아야 하는지 먼저 정해. 그 답 없이 뼈대부터 세우면 빈 정체성에 예쁜 avatar 만 붙어.
등록한 뒤엔 swap test 를 해. 어떤 대화도 중간에 영혼이 바뀌지 않는지, 새 대화가 올바른 soul id 를 저장하는지, WebUI 와 council 과 예약 작업이 그 영혼의 prompt 와 avatar 를 받는지 확인해. 기존 피파 경로도 전과 똑같이 돌아야 해. 새 자손 때문에 조상의 동작이 바뀌면 Rule 2 를 어긴 거야.
그리고 미래의 영혼이 처음부터 full vault 를 가져야 하는 건 아니야. 게스트 영혼처럼 범위가 좁은 정체성으로 시작해서, 실제 council 과 대화로 깊이가 쌓인 뒤 승급할 수 있어. 중요한 건 시작 크기가 아니라, 같은 identity 키와 역사를 잃지 않는 거야.