"깎기 전에 raw 돌을 저장해. 끌은 미끄러질 수 있어. 돌은 안 미끄러져야 하고."
보존 먼저, 해석은 그다음
Carve는 Pippa가 거친 계획을 읽기도 전에 뭔가 해. 정확한 입력을 보존해. 모든 carve는 raw 재료, 그러니까 붙인 텍스트랑 스크린샷을 import별 폴더에, 각각 sha256 checksum이랑 같이 저장하고, append-only op-log에 carve event를 append해. 그다음에야 뇌가 돌아. 순서가 핵심 전부야. 보존은 해석 뒤 단계가 아니라 그 앞 단계야. normalize는 판단 행위니까, 그러니까 Pippa가 흐릿한 표 셀이 뭘 뜻하는지 정하는 거니까, raw 소스는 독립적으로 살아남아야 해. 해석이 언제나 해석한 대상이랑 맞춰볼 수 있게.
op-log 규율
imports 로그는 breadcrumb이랑 같은 규율을 따라. append-only고, 읽을 때 fold되고, 절대 안 다시 쓰여. carve는 carve event를 append하고, 나중에 proposal accept는 accept event를 append해. 새 state를 반영하려고 과거 entry를 절대 안 고쳐. 새 state를 append하고 fold가 현재 view를 만들게 둬. 이게 엔진 전체를 관통하는 덮기-거부를 import에 적용한 거야. 뭐가 언제 import됐는지의 history는 증거고, 증거는 편집이 아니라 append돼.
왜 이 추적성이 남는 장사야
몇 달 뒤에 plan의 한 날이 틀려 보일 수 있어. 틀린 도시의 호텔, 안 맞는 날짜. 소스가 checksum이랑 같이 보존되고 로그됐으니까, 그날을 그게 깎인 정확한 거친 입력으로 추적해서 에러가 소스에 있었는지 깎기에 있었는지 볼 수 있어. 보존이 없으면 normalize 실수는 뿌리에서 못 고쳐. 틀린 출력은 있는데 어디서 왔는지 알 방법이 없거든. sources-first가 '계획이 어딘가 틀렸어'를 '이게 이걸 깎아낸 정확한 돌이야'로 바꿔. 미스터리랑 diff의 차이야.