Say that i64 is in, and what it found (016)

016 is built: bool and i64. The second stage's findings: an integer
literal takes the other side's type, found by compiling it on trial
(linear once the wanted type is passed down); a literal with no context
stays a number, so no program changes meaning and modules without i64
are the same bytes; one rule carries values between numbers, bools and
i64s; and the number paths passed the timing criterion, with what i64
had added to them counted and halved (110). The checkpoint lists bool
and i64 in the app model and drops i64 from what is left.

1 files changed, 26 insertions, 1 deletions

diff --git a/docs/design/016-bool-and-i64.md b/docs/design/016-bool-and-i64.md
index f69c4ff..0298e1a 100644
--- a/docs/design/016-bool-and-i64.md
+++ b/docs/design/016-bool-and-i64.md
@@ -1,6 +1,6 @@
 # 016 — 참·거짓과 정확한 정수: `bool`과 `i64`
 
-작성일: 2026-09-30. 상태: 1단계(`bool`) 구현, 검사로 고정. 2단계(`i64`) 설계.
+작성일: 2026-09-30. 상태: 1단계(`bool`)와 2단계(`i64`) 구현, 검사로 고정.
 aup의 v0c에 남은 것(aup `docs/design/002-dsl-direction.md`의 `i64 bool`)이고,
 [015](015-boundary-meaning.md)가 정한 경계마다의 값의 뜻에 두 종류를 더한다.
 
@@ -131,6 +131,31 @@ aup의 원칙(002)을 따른다. 위치가 정수가 아니듯 참·거짓은 �
 - 통과 조건: 모두 초록이고, 수의 경로는 그대로다. 은행 질의([091](../research/091-queries.md))와 TPC-C(RAM, W=1)를 전과 후
   번갈아 여섯 쌍 재서, 중앙값이 3% 넘게 느려지지 않는다.
 
+### 2단계에서 알게 된 것
+
+- **리터럴의 타입은 다른 쪽이 정한다.** `1 + x`에서 1을 내보낼 때는 x의 타입을 아직 모른다. aup는 다른 쪽을 시험 삼아
+  컴파일해 타입만 알고 되돌린다. 리터럴만의 식(`60 * 60 * 1000`, 리터럴을 고르는 `if`)도 통째로 다른 쪽을 따른다. 처음
+  구현은 시험 컴파일이 겹치면 한 겹마다 두 배가 됐다(괄호 22겹에 0.25초). 원하는 타입을 아래로 넘겨 식마다 한 번만 보게
+  했다(30겹에 1 ms 미만). aup의 검사가 30겹을 지킨다.
+- **문맥이 없는 리터럴은 수로 남는다.** 그래서 있던 프로그램의 뜻이 바뀌지 않는다. `-7 / 2`는 전처럼 −3.5이고, i64의 내림
+  나눗셈은 한쪽이 i64일 때다(`i64(-7) / 2`는 −4). i64를 쓰지 않는 프로그램은 모듈이 바이트까지 같다. i64 전과 후의 aup가
+  예제 18개(aup 10, Vega 8), TPC-C, 은행, 은행의 질의 넷을 같은 바이트로 빌드한다.
+- **값 칸을 겹치는 것은 따로 했다**(`600f576`). 옮기는 명령이 비트를 복사하고 계산하는 명령만 수로 읽게 바꾼 것만으로는
+  모든 검사가 그대로였다. i64는 그 위에 더했다.
+- **옮기는 규칙은 하나다.** 모듈 교체, 저장된 값과 항목을 다른 모듈이 읽을 때, 기다리던 보냄을 옮길 때가 모두
+  `pure_cell_as` 하나를 쓴다. 수·bool·i64 사이에서 맞으면 옮기고 아니면 기본값이라는 규칙이 한 곳에 있다. 실패의 이름도
+  세 표에 나뉘어 있던 것을 `pure_fault_name` 하나로 모았다(`overflow`가 새로 생겼다).
+- **수의 경로.** 기준을 채웠다(TPC-C 처리량의 중앙값 −0.6%, 은행 질의 0.0%에서 +2.2%). 시간으로는 가리지 못하는 1–3%는
+  명령을 세어 봤다. i64가 수의 경로에 더한 두 곳을 걷어냈다. 잎 단위의 폴드가 항목마다 i64인지 묻던 것과, 인라인되지 않게 된
+  칸 읽기다. 남은 것은 명령 +0.4%에서 +1.4%다([110](../research/110-counting-instead-of-timing.md)).
+
+검사: Pure test-module에 i64 산술의 끝값 28가지와 검증 거절 14가지, 키 있는 i64 목록의 앱(순서, 넘치는 합, 되돌린 추가,
+8바이트 메시지와 보냄, 모든 자릿수), 옮기기와 교체, 메모리와 대조하는 저장 셋(재시작, 이미지 46개)을 더했다. `server_meaning`은
+값마다 i64 필드를 싣고 끝값 13개를 나가는 길 일곱에서 본다(거절 84가지, i64는 거절의 종류까지). aup는 i64 진단 18가지, 받아들이는
+형식(30겹의 식이 선형인지도), 2^53 너머와 끝값을 사건마다 보는 검사, 생성 프로그램의 i64 값을 더했다. Vega는 i64 보기가 CLI,
+TUI, 문장, 웹에서 모든 자릿수로 보이는지 본다. 커밋: Pure `600f576`·`8c92f4c`·`fc65d66`·`fcc1f67`, aup `24d95e1`, Vega
+`49e0df3`.
+
 ## 1단계의 검사
 
 - aup: 진단(수를 조건으로, bool 산술, bool 크기 비교, bool 키), 받아들이는 형식, 참조 모델.