029, 030: 047 written into 029 (the leaf as the commit: appends pass, sparse updates break, two units as said beforehand; packets as 32-row column chunks 1,318 to 44 a row); 030 the one execution path, settled but for one choice: border reading rows where the payload has them, the handler emitted with registers, typed event buffers, shared captures and whole numbers, stored lists read in their leaves (a keyed seek by the guides' keys: 813 a point end to end, cycles 348, nothing copied out), commits writing appends into the leaf's tail and sparse updates to the log, replication as 046; what goes (the executor as a path, the batch lanes, the AArch64 layer, pure_list_read each message, the 54-state walks, the generic list API on hot paths, the bytes piece tree for whole sets); the verifier's three facts (N1, N4 new; N2 widened); representation choices; the user's choice (system cc at install, or Pure's own emitter per instruction set); the order, representation first inside the executor, each step with its check

1 files changed, 32 insertions, 1 deletions

diff --git a/docs/design/029-past-one-node.md b/docs/design/029-past-one-node.md
index 286485e..bcede34 100644
--- a/docs/design/029-past-one-node.md
+++ b/docs/design/029-past-one-node.md
@@ -320,10 +320,41 @@ C의 속도로 컴파일하기 쉬운 쪽**이어야 한다. 61–183배의 절�
 4. **증명 = 제로카피 실행 허가.** 손으로 쓴 판은 패킷과 리프를 그 자리에서 읽고, 경계 검사와 예산은 지킨다. 증명이 준 것은 N1, N2,
    N4이고, 트리의 순서로 찾기에는 "정렬됨"이 하나 더 든다(키를 선언한 리스트면 저장소의 불변식이라 증명이 필요 없다).
 
-**다음 질문(지은 것이 아니다).** "리프가 곧 커밋이다". 바뀐 리프의 열 바이트가 커밋 구간이 되어 로그의 레코드를 대신하고, 필드가 여럿인
+**다음 질문(지은 것이 아니다; 아래 047에서 깨는 실험을 했다).** "리프가 곧 커밋이다". 바뀐 리프의 열 바이트가 커밋 구간이 되어 로그의 레코드를 대신하고, 필드가 여럿인
 메시지는 열 순서로 오면, 패킷, 리프, 디스크, 복제가 한 모양이 된다. 재지 않은 값이 있다. append 하나에 리프 하나(32 × 8 = 256 B)를 다시
 쓰는 것과 로그 레코드 64 B의 차이, 스냅숏 공유와 압축에 주는 영향이다. 이 원리를 세울지는 깨는 실험을 정하고 나서 정한다.
 
+## 리프가 곧 커밋인가(047, 2026-10-19)
+
+009의 "한 모양"을 원리로 세울지 깨는 실험을 했다. 주장은 이것이다. 바뀐 리프의 열 바이트가 커밋 구간이 되어 로그와 이미지를 대신하고,
+메시지의 행도 리프로 오면, 패킷, 메모리, 디스크, 복제가 한 모양이 된다. 막대와, 그것이 무엇을 뜻하는지를 돌리기 전에 적고 커밋했다
+(`a93891e`).
+- 기준선(`baseline.py`). 046의 shim과 저널로, 오늘의 저장소가 메시지 하나에 쓰는 리스트 바이트(로그와 이미지)를 커밋 하나에
+  메시지 1, 16, 256개씩 묶어 쟀다.
+- 모형(`model.py`). 메모리의 바이트 그대로(리프 296–1,320 B, 안쪽 노드 680 B) 커밋이 바뀐 리프를 쓴다고 보고 바이트를 센다. 저장소를
+  지은 것은 아니다.
+  - cow: 바뀐 리프와 그 위 경로를 새로 쓴다.
+  - tail: 끝에 덧붙이기는 셀만 마지막 리프의 빈칸에 그 자리에서 쓴다. 쥔 스냅숏은 제 커밋의 개수 너머를 읽지 않는다.
+  - inplace: 다른 바뀜도 그 자리에서 쓴다. 허용되지 않는 길이고, 왜 안 되는지 보이려고 셌다.
+  - 압축은 트리의 규칙대로 셌다.
+| 리스트 바이트/메시지, 커밋 하나에 1 / 16 / 256 | 오늘 | cow | tail | 막대 |
+|---|---|---|---|---|
+| entries(덧붙이기) | 65.5 / 15.7 / 12.4 | 1,636 / 102 / 14.5 | **25.9 / 10.9 / 10.0** | ≤ 오늘 |
+| 은행 이체(흩어진 갱신 셋과 덧붙이기 하나) | 122 / 35.6 / 30.1 | 7,428 / 2,098 / 996 | **4,826 / 1,975 / 992** | ≤ 오늘의 2배 |
+- **덧붙이기는 지나고, 흩어진 갱신은 깨진다.** 미리 적은 대로, "한 단위"는 문구대로는 틀렸다. 덧붙이기와 한꺼번에 싣기에는 리프가
+  단위다. 흩어진 바뀜에는 델타 꼴이 필요하고, 그것이 로그다. 정직한 설계는 단위 둘이다. 덧붙이기는 리프의 꼬리에 쓰고, 흩어진 갱신은
+  로그에 쓴다.
+- inplace는 바이트로는 지나지만(186 / 126 / 122), 쥔 스냅숏이 그 쓰기를 93만 / 54만 / 1만 번 본다. 쓰기와 커밋 사이에서 죽으면 옛 값도
+  잃는다. cow, tail, 아래의 delta에서는 스냅숏이 보는 쓰기가 0이다.
+- 돌린 뒤의 후보(막대 밖). 리프 뒤에 바뀜을 담을 방(델타 16 B씩)을 두고, 방이 차면 리프를 새로 쓰는 것(delta)이다. 방 8칸에서 739 /
+  545 / 292, 32칸에서 363 / 268 / 176, 128칸에서 249 / 161 / 136으로 모두 막대를 넘는다. 오늘의 로그는 바뀜 하나를 약 7.5 B에 담기 때문이다.
+  자리는 varint, 정수는 zigzag로 줄이고, 틀은 커밋에 하나다.
+- **패킷을 리프로(`packet.c`).** 오늘 `pure_list_read`는 UAX #14의 load 행(필드 여섯, 2,787행)을 행 하나에 기계 명령 1,318(사이클 372)로
+  푼다. 32행의 열 덩어리로 오면 검사하고 그 자리에서 받는 데 44.4(사이클 14.2)다. 막대(1/10 이하)를 지나고, 모든 칸이 같다. 이것은
+  메시지 형식을 바꾸는 일이다(행 대신 32행의 열 덩어리).
+- 009로 다시 보면, 항목의 셀은 패킷, 리프, 디스크의 리프 꼬리, 복제에서 한 모양(binary64)을 지킬 수 있다. 흩어진 바뀜만 다른 그릇(델타)에
+  담긴다. 로그도 정수가 아닌 값은 binary64를 그대로 담는다.
+
 ## 열린 질문: 스키마의 진화
 
 같은 항목을 두 모양으로 든다. 지금은 레코드의 모양이 바뀌면 목록을 새 모양으로 다시 써서(100만 항목에 172 ms 막음) 그동안 옛