"깎기 전에 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 의 차이야.