Establish native micro runtime checkpoint

1 files changed, 116 insertions, 0 deletions

diff --git a/docs/research/017-web-layout-boundary.md b/docs/research/017-web-layout-boundary.md
new file mode 100644
index 0000000..042c969
--- /dev/null
+++ b/docs/research/017-web-layout-boundary.md
@@ -0,0 +1,116 @@
+# 017 — 웹 레이아웃을 복제하지 않는 문서 작업
+
+**범위 정정 — 2026-09-23:** 아래 결과는 브라우저 호스트에 한정한다. Pure의 목표는 앱 로직·
+net·RPC·DB·UI를 다루는 독립 네이티브 애플리케이션 런타임이다. UI는 일부다.
+웹 호환성을 브라우저에 레이아웃·편집을 맡기는 것으로 해석한 것은
+Codex의 오류다. 이 실험의 기능 검증은 보존하지만, Pure 자체의 레이아웃·텍스트·입력 체계가
+불필요하다는 근거로 사용하지 않는다. 현재 구현 방향은 [010 로드맵](010-roadmap.md)을 따른다.
+
+2026-09-23. 일반 텍스트를 열고 편집·읽기·저장하는 화면에 Pure를 연결했다.
+**이 작업에서는 레이아웃 트리·텍스트·스크롤 위치를 VM으로 옮길 필요가 없었다.**
+크기 변경과 줄바꿈은 브라우저가 처리하고, Pure에는 사용자가 정한 패널 비율 하나만 둔다.
+
+이것은 실제 UI 조건을 확인한 구현·기능 검증이다. 전체 메모리 절감, 새로운 압축 원리,
+대규모 앱 성능 우위의 증거는 아니다. 화면 하나의 분할 비율을 위해 VM을 추가할 성능상의
+근거도 얻지 않았다. 기존 실행 규칙을 표준 웹 호스트에 연결하는 경계를 확인한 단계다.
+
+## 직접 확인하기
+
+기존 작업 화면을 새로고침하고 **문서 편집 · 반응형 레이아웃 작업 화면** 링크를 연다.
+직접 주소는 서버의 `/document.html`이다.
+
+1. 일반 UTF-8 `.txt` 파일을 열거나 빈 문서에 작성한다. **예제 문서**도 있다.
+2. 가운데 경계를 끌거나 방향키·슬라이더로 두 패널의 폭을 조절한다.
+3. 조작 중 창 크기를 바꾸거나 Esc로 취소한다. 좁은 화면에서는 두 패널이 위아래로 놓인다.
+4. 양쪽을 독립적으로 스크롤하고, 텍스트를 고치고 실행 취소한다.
+5. `.txt 저장`으로 다른 편집기에서도 읽을 수 있는 파일을 내려받는다.
+6. **분할 규칙 수정**에서 `clamp(event_value,20,80)`을 `clamp(event_value,30,70)`으로
+   바꾸어 적용한다. HTML 어댑터를 바꾸지 않아도 같은 컨트롤의 제한이 바뀐다.
+
+파일은 텍스트만 저장한다. 패널 비율·Pure 규칙을 묶는 자체 문서 형식은 만들지 않았다.
+임포트/익스포트는 파일당 2 MiB까지이고, UTF-8 오류는 현재 문서를 유지한 채 거절한다.
+브라우저 textarea의 줄바꿈 정규화 때문에 저장은 LF·BOM 없음으로 이루어진다.
+원본 파일의 모든 바이트를 그대로 보존하는 편집기라는 뜻은 아니다.
+
+## 어디에서 무엇을 소유하는가
+
+| 자료/작업 | 소유자 | 연결에서 하는 일 |
+|---|---|---|
+| 작성 중인 텍스트·선택·실행 취소 | 브라우저 기본 textarea | 입력 후 읽기 화면에 텍스트 전달 |
+| 읽기 화면의 글자 배치·줄바꿈·스크롤 | DOM/CSS/브라우저 | 문서가 바뀔 때만 텍스트 갱신 |
+| 패널의 실제 크기·좁은 화면 배치 | CSS Grid/media query | 비율 하나를 CSS 변수로 전달 |
+| 사용자가 요청한 분할 비율의 정책 | Pure 숫자 상태·규칙 | range/포인터/키보드가 같은 숫자 입력을 사용 |
+| 접촉 소유권·취소 시작값·기하 캐시 | 브라우저 어댑터 | 조작 시작과 무효화 뒤 필요한 좌표만 읽음 |
+
+문서 크기나 줄 수가 늘어나도 이번 정책의 VM 상태는 비율 하나다. viewport width,
+DOMRect 배열, 텍스트 AST, 스크롤 위치를 VM 상태로 복제하지 않는다. 레이아웃 연산이
+없어진 것은 아니다. 브라우저가 그 연산과 관련 저장 공간을 담당한다.
+
+읽기 화면은 textarea와 별도의 텍스트 표현을 갖는다. 따라서 **제로 카피 문서 모델은 아니다.**
+별도 JS 문서 모델과 Wasm 문자열 사본은 만들지 않았지만, 브라우저 내부의 텍스트·undo·
+레이아웃 저장 공간과 파일 읽기/인코딩의 임시 버퍼는 여전히 필요하다.
+
+## 필요한 경계만 추가했다
+
+기존 실행기는 키·포인터·프레임 입력은 받았지만 네이티브 숫자 컨트롤의 값을 직접 받을
+경로가 없었다. 다음 입력을 추가했다.
+
+```text
+state ratio = 50
+input split = value
+on split.change { ratio = clamp(event_value,20,80) }
+```
+
+호스트는 `runtime.change('split',65,'range')`, CLI는 `change split 65`를 사용한다.
+값은 유한한 숫자이고 사건 동안만 존재한다. 규칙이 저장한 값만 상태가 된다.
+기존 원자적 이벤트 실행·실패 취소·공유 규칙·표시 캐시 무효화를 그대로 사용한다.
+문서 호스트는 HTML로 출력하므로 가짜 도형 선언이나 SVG 장면을 만들지 않는다.
+출력 도형이 없는 프로그램에서는 사용하지 않는 표시값 배열도 생성하지 않도록 했다.
+
+[정의](../../prototypes/workbench/examples/document.pure)의 실제 표현은 상태 1개,
+입력 2개, 반응 2개, 명령 7개다. 활성 상태는 8 B, 명령·연결은 144 B다.
+하지만 코어는 여전히 **20,064 B를 예약하고 Wasm 선형 메모리는 64 KiB**다.
+이 숫자는 브라우저 앱 전체 메모리가 아니며, 작은 상태만으로 전체 효율을 주장하지 않는다.
+
+포인터 이동은 프레임당 마지막 좌표만 전달한다. 놓을 때 대기 중인 이동을 먼저 처리하고,
+취소는 시작 비율로 복귀한다. 크기 변경·스크롤은 기하 캐시를 무효화하지만 그 콜백에서
+레이아웃을 읽거나 쓰지 않는다. 다음 조작이 실제로 필요할 때 읽는다.
+관찰된 0회는 애플리케이션의 해당 API 호출 수이며 브라우저 내부 레이아웃 비용 0을 뜻하지 않는다.
+
+## 확인한 것과 한계
+
+- 네이티브 37개, Node/CLI 87개 검사 통과. 새 숫자 사건의 컨텍스트, 잘못된 입력,
+  비유한 수, 여러 반응의 실패 원자성, 공유 규칙, 캐시, 저장·복원을 포함한다.
+- 문서 브라우저 검사 32개: 창 크기 변경·독립 스크롤·네이티브 컨트롤·실제 마우스와
+  CDP 터치·조작 중 resize·취소·표준 파일 다운로드와 새 페이지 왕복·늦게 끝난 파일 읽기
+  거절·Unicode 편집·네이티브 undo·미완성 조합 중 출력 보류·규칙 수정·Wasm 실패 시 문서 기능 유지.
+- 기존 작성 흐름 44개도 통과했다. 기본 화면의 숫자 입력 컨트롤 3개, 잘못된 출력·조작 중 교체·파일 크기 등의
+  추가 확인 6개도 통과했다.
+- 창 크기 변경과 스크롤에서 Pure 이벤트·문서 재전달·앱 기하 읽기가 증가하지 않음을
+  확인했다. 비율 변경도 문서 재전달을 일으키지 않는다. 이는 소유권 검증이며 속도 비교가 아니다.
+
+환경은 Linux Chromium이다. 한글 조합의 순서는 합성 composition 사건으로 확인했고,
+실제 운영체제 IME·물리 모바일 기기·전체 접근성 적합성을 검증한 것은 아니다.
+분할 조작은 [W3C의 separator 의미와 키보드 지침](https://www.w3.org/WAI/ARIA/apg/patterns/windowsplitter/)을
+참고했다. 포인터 캡처·취소는 [Pointer Events](https://www.w3.org/TR/pointerevents3/),
+크기 관찰 경계는 [Resize Observer](https://drafts.csswg.org/resize-observer/)를 참고했다.
+표준을 재발명한 것으로 세지 않는다.
+
+[검증 자료와 재현](../../prototypes/workbench/results/2026-09-23-web-layout/README.md),
+[실행 계약](../../prototypes/workbench/CONTRACT.md),
+[문서 호스트](../../prototypes/workbench/web/document.mjs),
+[입력 어댑터](../../prototypes/workbench/web/split-input.mjs).
+
+## 당시 결정의 정정과 남은 한계
+
+당시 ‘기존 환경과의 경계가 이미 목적을 충족하므로 자체 레이아웃을 추가하지 않는다’는
+결론은 철회한다. 브라우저를 필수 기반으로 삼은 이 구현은 독립 네이티브 UI 목표를 충족하지
+않는다. 현재 HTML 화면은 직접 작성한 호스트이며 현재 DSL이 일반 UI 전체를 표현하지도 않는다.
+Pure의 UI 체계가 배치·입력·출력을 소유하는 일은 애플리케이션 런타임 구현의 일부다.
+다음 우선순위는 로드맵의 실행·수명 계약과 UI·RPC·DB를 연결하는 실제 작업을 따른다.
+이는 모든 기능을 현재 VM에 넣거나 새 문서·미디어 포맷을 먼저 만들겠다는 뜻은 아니다.
+
+남아 있는 구체적 비용은 **텍스트 한 부분을 편집해도 읽기 화면의 전체 문자열을 갱신하는 것**이다.
+좁은 화면에서 읽기 패널이 보이지 않을 때도 지금은 갱신한다. 이 웹 호스트의 추가 최적화는
+미룬다. 표준 파일 왕복·숫자 입력·취소 등의 동작은 네이티브 구현에서 참고하되, DOM/CSS에
+맡긴 비용이 제거됐다고 계산하지 않는다. 표준 파일을 포기하거나 새 포맷의 우위를 가정하지 않는다.