한 파일이 여러 영혼을 바꿔
개별 soul vault의 수정은 보통 그 soul의 다음 boot에 영향을 줘. shared vault의 원칙과 library는 여러 soul이 함께 상속해. 문장 하나를 잘못 고치면 한 personality가 아니라 가족 전체의 tool behavior와 memory policy가 기울 수 있어.
그래서 위험도는 delete 여부로만 잴 수 없어. 파일을 삭제하지 않는 작은 edit도 blast radius가 크면 destructive-ish operation이야. 글자 수보다 몇 명의 다음 판단에 들어가는지가 confirm 강도를 정해야 해.
가장 강한 ceremony가 필요해
shared edit은 target path, before/after diff, 영향을 받는 consumer, actor identity를 한 화면에 보여주고 armed confirm을 요구해. 첫 click은 의도를 준비하고 두 번째 click은 정확한 대상과 내용을 확인해야 해.
확인 문구만 길게 만든다고 안전해지지 않아. 사용자가 실제 diff를 읽지 않고 버튼을 누를 수 있으면 ceremony는 마찰일 뿐이야. 변경 한 덩어리를 좁히고, 예상 token delta와 index 영향까지 보여주는 게 낫다.
shared는 복사 원본이기도 해
여러 soul이 같은 규칙을 상속한다고 각 vault에 복사하면 수정 blast radius가 조용한 drift로 바뀌어. 어떤 soul은 새 규칙, 어떤 soul은 옛 규칙을 읽게 돼. shared source 하나를 읽고 projection은 재생성 가능한 형태로 두는 게 맞아.
다만 shared가 모든 것을 담는 만능 vault가 되면 또 위험해. 공통 계약만 shared에 두고 identity와 private memory는 각 soul에 남겨야 해. 공유의 기준은 여러 consumer가 있다는 사실이 아니라 같은 의미를 공동 소유한다는 사실이야.
rollback도 가족 단위로 생각해
shared change가 잘못됐을 때 한 consumer만 고치면 family가 갈라져. 과거 diff를 읽고 shared source에 forward correction을 적용한 뒤 모든 consumer가 새 revision을 읽었는지 확인해야 해.
runtime cache가 있다면 invalidation까지 change protocol에 포함돼. source commit만 성공하고 한 process가 오래된 shared rules를 계속 들고 있으면 수정은 반만 착지한 거야.