Establish native micro runtime checkpoint

1 files changed, 62 insertions, 0 deletions

diff --git a/docs/research/029-native-document-window.md b/docs/research/029-native-document-window.md
new file mode 100644
index 0000000..c5084f3
--- /dev/null
+++ b/docs/research/029-native-document-window.md
@@ -0,0 +1,62 @@
+# 029 — 작성된 바이트 편집을 실제 네이티브 창에서 실행
+
+2026-09-24. Linux AArch64, C17/GCC 14.2, GTK 4.18. 첫 공개 체크포인트의 중간 결과다.
+기존 [문서 편집 연결](023-document-edits.md)을 GTK 창에 붙였다. CLI·HTTP 서버·창이
+동일한 [`editor.pure`](../../prototypes/connections/examples/editor.pure) 정의를 준비해
+동일한 실행 코어와 조건부 바이트 저장 효과를 사용한다. GTK는 **선택한 앱의 호스트
+어댑터**이며 기본 코어·CLI·서버에 들어가지 않는다.
+
+![Linux GTK 문서 창](../../prototypes/connections/results/2026-09-24-native-document-window/window.png)
+
+## 실제 사용 경로
+
+`make -C prototypes/connections window`로 선택 빌드한다. 실행 명령은
+[사용 안내](../../prototypes/connections/README.md#네이티브-문서-창)와 같다.
+창은 저장된 UTF-8 문서를 열고, GTK 텍스트 버퍼에서 편집하며, 이전 내용과 새 내용의
+공통 앞·뒤 구간을 찾아 바뀐 바이트 구간만 `store.splice`에 보낸다. 공통 구간이 UTF-8
+코드 포인트의 중간에서 끝나면 양쪽을 문자 경계로 넓힌다. 수정하지 않은 기존 본문은
+입력 메시지에 다시 싣지 않는다. 저장 구현 자체는 새 파일에 전체 범위를 다시 기록한다.
+
+저장 조건은 읽은 문서 버전이다. 다른 실행기가 먼저 저장했을 때 창은 충돌을 표시하고
+현재 초안을 유지한다. `Reload`는 미저장 초안이 있으면 거절하고, `Discard & reload`만
+명시적으로 초안을 버린다. 창 닫기·Ctrl+W도 미저장 변경을 확인한다. 수정 없이 저장하면
+저장 버전을 올리지 않는다. 이 창은 일반 바이트 편집기가 아니어서 유효하지 않은 UTF-8이나
+NUL이 든 저장 문서는 열지 않고 기존 화면을 유지한다. 해당 바이트는 기존 CLI가 다룬다.
+
+## 실제 프로세스 검증
+
+[Xvfb/GTK 사용자 흐름 결과](../../prototypes/connections/results/2026-09-24-native-document-window/gtk-flow.json)와
+[ASan/UBSan으로 계측한 C 호스트 결과](../../prototypes/connections/results/2026-09-24-native-document-window/gtk-sanitized.json)는
+실제 창의 입력·저장·재시작을 검사한다. 빈 문서 생성·복원, CLI에서 창 저장 내용 확인,
+HTTP 서버가 먼저 문서를 갱신한 뒤 창의 충돌·초안 보존, UTF-8에서 첫 두 바이트가 같은
+다른 글자로 교체, 변경 없는 저장, 미저장 종료 방지가 통과했다. 1 MiB 문서를 창에서 열고
+마지막 한 바이트를 바꾼 뒤 CLI로 전체 결과를 대조했다. 계측 빌드에서 GTK 라이브러리
+자체가 ASan으로 재빌드된 것은 아니다.
+
+기존 [연결·저장 회귀 검사](../../prototypes/connections/results/2026-09-24-native-document-window/connection-check.json)도
+통과했고, [실행 코어 예산 검사](../../prototypes/connections/results/2026-09-24-native-document-window/core-budget.json)의
+`text`는 이전과 동일한 5,932 B였다. 창용 코드는 `make all`의 필수 대상이 아니다.
+
+## 비용은 계층별로 기록
+
+같은 호스트의 [ELF 섹션 원자료](../../prototypes/connections/results/2026-09-24-native-document-window/size.txt),
+[stripped 파일 크기](../../prototypes/connections/results/2026-09-24-native-document-window/stripped.txt),
+[직접 동적 의존성](../../prototypes/connections/results/2026-09-24-native-document-window/dependencies.txt),
+[빌드·소스 해시](../../prototypes/connections/results/2026-09-24-native-document-window/build.json).
+
+| 선택 실행물 | ELF `text` | stripped 파일 | 직접 동적 의존성 |
+|---|---:|---:|---|
+| 문서 CLI | 35,807 B | 67,904 B | libc |
+| HTTP 호환 서버 | 42,761 B | 68,000 B | libc |
+| GTK 문서 창 | 43,308 B | 68,280 B | GTK·GIO·GObject·GLib·libc |
+
+창에서 1 MiB 문서를 연 뒤 Linux `/proc`로 본 **창 프로세스 RSS는 44,208 KiB**였다.
+Xvfb·커널 캐시·다른 프로세스는 포함하지 않은 수치다. ASan 빌드의 RSS는 143,168 KiB로
+별도 검증용이며 제품 비용과 비교하지 않는다. GTK의 공유 라이브러리·렌더링·텍스트 버퍼
+비용을 무시하고 68,280 B 파일을 앱 전체 크기라 부르지 않는다. 이것은 마이크로 코어를
+실제 문서 앱에 연결한 결과지만, **전체 GTK 앱이 임베디드급 메모리라는 증거는 아니다.**
+
+현재 한계는 단일 문서, 동기 저장, 버전 충돌 후 수동 재적용, GTK/Linux 호스트, 바이트
+기반 저장이다. IME·문자소 단위 위치·큰 문서의 대화식 지연·macOS 실사용은 검증하지
+않았다. 이후 [030](030-authenticated-document-peer.md)에서 선택형 인증 TLS 피어까지
+**같은 문서 작업**으로 연결했다. 실제 앱의 전체 피크·실패·사용성 비용은 계속 검증해야 한다.