Establish native micro runtime checkpoint

1 files changed, 115 insertions, 0 deletions

diff --git a/docs/research/015-shared-rules.md b/docs/research/015-shared-rules.md
new file mode 100644
index 0000000..44f6544
--- /dev/null
+++ b/docs/research/015-shared-rules.md
@@ -0,0 +1,115 @@
+# 015 — 대상별 값과 공유 규칙 본문
+
+2026-09-23. 여러 도형을 배치하는 작업에서 같은 이동·놓기·취소 반응이 대상마다
+복제되던 문제를 다뤘다. 규칙을 한 번 작성하고, 컴파일된 명령도 한 벌만 보관하며,
+각 입력 연결은 대상의 연속된 상태 구간을 지정한다.
+
+## 사용하는 형태
+
+```text
+record Position { x=0; y=0 }
+item green = Position(x=80,y=120)
+item blue = Position(x=280,y=160)
+rule move(t: Position) {
+  t.x = event_x
+  t.y = event_y
+}
+on drag_green.move use move(green)
+on drag_blue.move use move(blue)
+```
+
+전체 작성물 [shared-layout.pure](../../prototypes/workbench/examples/shared-layout.pure)는
+잡은 위치 유지, 제한된 영역의 이동, 놓기 확정, 취소 복귀, 선택한 대상의 방향키 조정을 포함한다.
+화면의 **공유 규칙으로 배치**에서 불러와 적용할 수 있다.
+`go_right` 한 곳을 고치면 연결된 세 대상이 같은 변경을 사용한다.
+대상별 입력과 출력 연결은 명시적으로 작성한다.
+
+## 실행 표현
+
+`record`는 필드의 기본값, `item`은 그 필드의 실제 값, `rule`은 공유되는 반응이다.
+각 item의 필드는 기존 숫자 상태 배열의 연속 구간에 놓인다. `green.x` 같은 이름은
+작성·수정·저장의 식별자이며, 이벤트마다 문자열을 찾아 실행하지 않는다.
+
+규칙 본문은 첫 사용 위치에서 한 번만 내린다. 연결마다 본문 범위와 대상 필드의
+시작 위치·개수를 기록한다. 읽기·쓰기는 `base + field_offset`으로 실제 상태에 접근한다.
+필드 번호 목록, 인자 값 복사, 별도 레코드 객체, VM 호출 스택을 추가하지 않았다.
+표시 표현식은 직접 해석된 기존 상태 읽기를 쓰므로 계산 캐시도 실제 필드 변경을 추적한다.
+
+매개변수 하나는 정확히 같은 record 타입의 item에 연결한다. 다른 타입, 누락된 필드,
+범위를 벗어난 슬롯, 잘못된 본문 공유는 거절한다. 사용하지 않은 규칙도 이름과 필드를
+검사하지만 명령 저장량에는 포함하지 않는다. 매개변수 이름이 전역 item 이름과 겹칠 때
+없는 필드를 전역 값으로 잘못 해석하지 않도록 검사한다.
+
+한 사건의 모든 연결은 기존처럼 작성 순서대로 실행한다. 뒤쪽 연결이 실패하면 앞쪽
+연결의 변경과 전역 상태 변경까지 함께 취소한다. 같은 item을 두 번 연결하면 두 번 실행한다.
+코드를 공유한다는 이유로 입력이나 효과를 생략하지 않는다.
+
+## 확인한 구조적 차이
+
+동일한 최종 코어에서 기존 `layout.pure`와 공유 규칙 작성물을 컴파일한 회계다.
+실행 시간 비교나 처리량 벤치마크는 아니다.
+
+| 항목 | 기존 명시적 반복 | 공유 규칙 |
+|---|---:|---:|
+| 저장된 명령 | 319 | 117 |
+| 이벤트 연결 | 16 | 24 |
+| 사용 중인 명령·연결 자료 | 5,360 B | 2,256 B |
+| 숫자 상태 | 22 | 25 |
+
+공유 버전의 추가 세 상태는 예제가 명시한 대상별 `id`다. 기존 키 반응의 대상별 조건을
+각 연결에 나누면서 연결 수는 늘었다. 코드 저장량 감소를 전체 메모리 감소나 속도 향상으로
+해석하면 안 된다. 각 대상의 값과 입력 소유권은 계속 필요하다.
+
+연결 구조체는 12 B에서 16 B로 늘었다. 활성·준비 프로그램의 고정 연결 배열 때문에
+코어 예약 공간은 이전 19,392 B에서 **19,904 B**로 512 B 늘었다.
+Wasm 선형 메모리 한도는 64 KiB다. 사용 중인 자료와 고정 예약 공간을 별도로 기록한다.
+이 구조가 모든 작은 작성물에 메모리 이득이라는 주장은 하지 않는다.
+[구조 회계](../../prototypes/workbench/results/2026-09-23-shared-rules/representation.json)는
+동일 ABI의 두 작성물을 비교하며 이전 12 B 연결 구조체의 수치를 섞지 않는다.
+
+## 의미 보존과 검증
+
+기존 작성물과 공유 버전에 같은 입력을 전달해 모든 대상의 위치·잡은 위치·취소 위치·
+조작 여부·선택·출력 값을 비교했다. 두 대상의 동시 조작, 한 대상의 취소, 키보드 조정,
+영역 밖 이동과 놓기 이후의 결과가 일치했다.
+
+선언 순서와 record 필드 순서를 바꿔도 `item.field` 이름으로 값을 보존하고 물리 연결을
+다시 만든다. 삭제한 item의 값은 사라지며 재선언은 새로운 초기값에서 시작한다.
+배치 파일은 물리 슬롯 번호를 저장하지 않는다. 새 실행기에서 소스를 다시 컴파일하고
+이름을 검사한 다음 정의와 값을 함께 확정한다. 이전 version2 형식은 유지한다.
+생성되는 필드 이름이 소스보다 길어질 수 있어, 최대 크기의 유효한 저장 파일을 자체
+로더가 거절하지 않도록 파일 크기 상한도 해당 이름 수를 포함해 정했다.
+
+- 네이티브 32개: 공유 명령의 독립 필드 접근, 같은 대상의 반복 연결, 여러 연결의
+  원자성, 누락·잘못된 범위·부분 중첩 거절과 기존 코어 기능.
+- JavaScript 75개: 규칙 하나의 명령 수가 연결 증가로 복제되지 않음, 컴파일 오류,
+  이전 작업물과 의미 동등성, 순서 변경·제거·복원, 캐시 무효화, 기존 작성·파일 기능.
+- 브라우저 23개: 공유 규칙 한 곳 수정, 서로 다른 대상에 적용, 선언 순서 변경,
+  실제 마우스와 두 접촉의 독립 이동·취소, 다운로드와 새 페이지 복원, 파일 읽기 충돌.
+
+기존 작성 흐름의 브라우저 회귀 검사 44개도 통과했다.
+
+브라우저는 Linux Chromium이며 터치는 CDP 입력이다. 실제 모바일 하드웨어나 Codex 내장
+브라우저에서 이번 공유 규칙 흐름까지 사용자가 확인한 것은 아니다.
+
+근거: [Node 검증](../../prototypes/workbench/results/2026-09-23-shared-rules/verification.json),
+[코어 빌드](../../prototypes/workbench/results/2026-09-23-shared-rules/build.json),
+[브라우저 결과](../../prototypes/workbench/results/2026-09-23-shared-rules/shared-browser.json),
+[재현 스크립트](../../prototypes/workbench/qa-shared-rules.js),
+[계약](../../prototypes/workbench/CONTRACT.md).
+
+## 남은 제약과 다음 방향
+
+매개변수화된 규칙은 기존 프로그래밍 개념이다. 이번 결과는 이 작성·실행·저장 경로에서
+실제 명령 복제를 없애면서 상태와 조작 의미를 보존한 구현이다.
+현재 record당 필드는 1~8개이고, 모든 item의 필드는 합쳐서 상태 32개 한도에 포함된다.
+입력 8개·출력 24개 한도도 그대로다. 일반 함수 호출, 동적 대상 생성·삭제는 없다.
+
+이름으로 보존하는 정적 필드와 동적 대상의 생명주기 핸들은 다르다.
+예제의 `id`와 `selected`는 작성한 숫자 상태라서 중복 방지나 선택 정책을 실행기가
+자동 보장하지 않는다. 재사용한 ID를 오래된 입력이 가리키는 문제까지 해결한 것으로 세지 않는다.
+
+다음 제약은 대상마다 필요한 입력 연결과 키 사건의 모든 연결 순회다.
+**실행 중 대상 추가·삭제와 선택한 대상만 실행하는 경로**를 검토할 때,
+삭제·재사용 뒤 오래된 입력과 저장된 선택이 잘못된 대상에 적용되지 않는 식별 규칙이 필요하다.
+규모를 키운 속도 수치보다 이 작업 조건을 먼저 고정한다.