# 첫 공개 체크포인트 — 진행 중

목표는 작은 OS의 운영 모델을 가진 네이티브 마이크로 런타임을 실제 앱으로 보여주는 것이다.
작은 코어, 새 문법, 단일 버퍼 실험만으로 완료하지 않는다. 사용자가 직접 작성·변경할 수 있는
앱과 재현 가능한 실행·비용·실패 검증을 함께 공개할 수 있어야 한다.

## 공개할 작업물과 완료 증거

기존 작업물 편집·저장 흐름을 발전시킨 **네이티브 작업물 편집기**를 하나의 검증 앱으로 삼는다.
앱 정의와 현재 상태를 구분하고, 선택한 항목·내용을 변경·저장·복원하며, 다른 실행기와
변경을 주고받는다. CLI의 자동화와 네이티브 UI가 같은 앱 로직을 사용해야 한다.
현재 브라우저 UI나 Python 요청 클라이언트를 네이티브 앱 완성으로 대체하지 않는다.

| 요구 | 완료에 필요한 증거 | 현재 상태 |
|---|---|---|
| Pure가 실행·자원·연결을 소유 | 호스트 타입 없는 실행 코어, 실제 입출력 어댑터, 종료·완료·회수 검증 | 저장과 선택한 scalar 앱 입력·상태·복원을 같은 코어에 연결. [045](docs/research/045-owner-thread-async-effects.md)의 선택형 완료 원시 기능과 [048](docs/research/048-immutable-read-write-overlap.md)의 실제 HTTP 호스트에서 수명·기한·종료·쓰기 중 읽기를 검증했다. 인증 피어 통합과 일반 앱 표현은 미완료 |
| 마이크로 기본 비용 | 실행 전용 구성과 선택 기능의 분리, 코드·메모리·작업별 비용과 전체 앱 비용 공개 | [069](docs/research/069-atomic-authored-size-policy.md)에서 기본 코어 `text` 4,632 B, 유휴 영역 120 B, 작업 슬롯 216 B와 준비된 문서 정의 680 B를 유지하며 실제 문서 크기 정책을 연결했다. 정책을 선택한 소스 CLI/HTTP `text`는 36,135/44,342 B, 고정 CLI/HTTP는 19,268/26,689 B다. 현재 소스·고정 CLI 압축 묶음은 22,862/12,966 B, 고정·소스 CLI+TUI는 32,144/51,398 B이고 모두 이동 후 검증했다. Linux 1 MiB 편집 피크 RSS는 소스 CLI 2,080 KiB, 고정 CLI 2,112 KiB다. 혼합 저장소 HTTP는 456 B 커져 선택형 상한만 검토해 조정했다. HTTP·TLS·GTK는 선택 기능이며 큰 앱의 전체 피크·작업당 비용은 미완료 |
| 작성 가능한 실용 앱 | 사용자가 입력·연산·연결을 수정해 동작을 바꾸고, 새 실행기에서 상태 복원 | [069](docs/research/069-atomic-authored-size-policy.md)의 작성 가능한 문서 크기 정책이 실제 CLI·HTTP·TUI·TLS 효과를 제어하고 새 실행에서 바뀜. 기존 .pure의 네이티브 빌드·실시간 소스 적용·새 프로세스 복원 연결; JSON 프로젝트 변환·큰 앱 표현은 미완료 |
| 네이티브 사용 경험 | 실제 편집·입력·크기 변경·저장·오류 복구를 네이티브 UI에서 실행 | [035](docs/research/035-native-multi-document-window.md)의 Linux GTK 창은 여러 문서·정의 초안과 충돌을 다루지만 [036](docs/research/036-gtk-memory-boundary.md)에서 확인한 약 44 MiB RSS와 전환 중 증가 때문에 저메모리 프로필은 아니다. [044](docs/research/044-terminal-viewport-cost.md)의 선택형 네이티브 TUI는 같은 준비된 문서 앱에서 한국어·여러 행·탭 입력, 키 전환·저장·충돌·크기 변경·1 MiB 작업을 처리한다. [050](docs/research/050-bounded-document-prefix-find.md)은 1,024개 실제 문서의 목록·전환·접두어 탐색을 검사했다. 고정 TUI의 이전 Linux PTY 검사에서 1 MiB 피크 RSS는 2,832~3,168 KiB였다. 최신 고정 CLI+TUI 묶음은 32,144 B다. [053](docs/research/053-source-loaded-native-terminal-editor.md)의 선택형 소스 TUI는 같은 문서 앱을 `.pure`에서 읽고 다른 필드 배치·1 MiB 편집·1,024개 문서 탐색을 실제 PTY에서 확인했다. 현재 소스 CLI+TUI 묶음은 51,398 B다. [065](docs/research/065-native-save-latency.md)는 선택형 페이지 저장소 TUI의 실제 저장 완료 시간·코드·RSS를 검증했다. 본문 검색, 저메모리 GUI, macOS·IME·복합 문자소 처리는 남음. 정의 작성은 별도 작성 호스트가 맡는다 |
| 내부 연결과 Pure 간 RPC | 같은 앱 의미의 내부 연결·원격 연결, 수명·형식·충돌·기한·종료 처리 | [063](docs/research/063-real-in-process-routing.md)에서 실제 1 MiB 문서를 한 프로세스의 두 저장 영역에 추가 입력 버퍼 없이 전달하고 독립 충돌·회수를 검증했다. [030](docs/research/030-authenticated-document-peer.md)의 선택형 TLS 1.3 문서 피어가 CLI·HTTP·창의 같은 `editor.pure` 읽기·변경·충돌·복원을 처리. [055](docs/research/055-authenticated-peer-transport-cost.md)에서 서버 전용 선택 빌드와 같은 보안 전송의 직접 기준선을 추가하고 공통 TCP 지연을 줄였다. [058](docs/research/058-portable-authenticated-peer-check.md)은 인증·1 MiB 문서·실패 시나리오를 Linux 전용 RSS 수집 없이 실행했다. 장기 실행 영역 관리자·macOS·실패망·대규모 부하는 미완료 |
| Pure 외부와의 연결 | 일반 클라이언트와 양방향 입출력, 프로토콜 오류·호환성 검증 | 문서 창·CLI·HTTP·C TLS 피어가 같은 저장 버전과 편집 효과를 공유. 별도 Python TLS 클라이언트가 같은 문서 형식으로 읽고 쓰며 1 MiB 본문을 교환. 실서비스 상호운용성은 미완료 |
| 성능·크기 주장에 대한 근거 | 실제 앱 작업으로 동등한 직접 구현·해당 RPC 기준과 비교, 기능·보안 조건 공개 | [034](docs/research/034-hybrid-document-storage.md)에서 같은 문서 앱의 파일 쓰기 요청량은 큰 문서 약 61.9배 감소, 1 B 문서는 기본과 동일함을 확인했다. 코드 크기는 증가했다. [049](docs/research/049-idle-app-work-slots.md)에서는 실제 네이티브 앱 1,000개의 입력·저장·복원 후 메모리 비용을 비교했다. [040](docs/research/040-document-service-capacity.md)에서는 같은 문서 앱으로 호스트당 1,024개 객체·4,096 HTTP 작업·8동시 연결의 정확성·RSS·회수를 확인했다. [054](docs/research/054-direct-document-path.md)는 같은 저장 작업의 직접 호출과 Pure 경로에서 결과·최종 파일이 같음을 검사하고, Pure 비교 실행물의 `text`가 8,276 B 더 큼을 확인했다. [055](docs/research/055-authenticated-peer-transport-cost.md)는 인증 TLS 문서 읽기에서 직접 서버와 Pure 서버가 같은 결과를 내며, 공통 TCP 지연을 제거하자 짧은 루프백 배치가 크게 단축됨을 보였다. 서버 전용 Pure 빌드의 `text`는 클라이언트 겸용보다 3,472 B 작고, 동일 실험 빌드에서는 직접 서버보다 5,592 B 크다. 직접 기준선은 런타임 전체 계약과 동등하지 않고 속도 우열도 아직 미판정이다. 물리 쓰기량·장시간 서비스 부하·동등 서버 지연·Kitex 수준 성능은 미입증 |
| 공개 가능한 패키지 | 깨끗한 환경의 빌드·실행, 예제 수정 안내, 실패·한도·플랫폼별 검증 자료 | [069](docs/research/069-atomic-authored-size-policy.md)의 현재 소스 묶음을 다른 디렉터리에서 빌드해 C·TUI·실제 문서 RSS·수정한 `.pure` 동작·프로세스 내 실제 문서 전달·선택형 저장 형식 내보내기·Linux 릴리스 검사를 통과했다. 앞선 [059](docs/research/059-immutable-file-copy-path.md) 묶음은 선택형 TLS 피어·Linux 파일 간 복사도 검사했다. [056](docs/research/056-server-only-document-package.md)의 Linux 서버 전용 TLS 묶음은 클라이언트 겸용보다 압축 전체가 1,696 B 작고 두 구성 모두 검토한 상한 안에서 이동 후 인증·1 MiB 문서·복원 작업을 통과했다. 시스템 공유 라이브러리, macOS 빌드·검증, 서명·라이선스와 플랫폼별 설치 절차는 미완료 |

현재 검증하지 못한 성능·격리·자동 최적화 능력을 소개 문구로 대신하지 않는다.
문서 앱과 scalar 앱은 수명·예산 코어를 공유하지만 아직 하나의 작성 가능한
앱 모델이 아니다. [069](docs/research/069-atomic-authored-size-policy.md)의 숫자
상한은 실제 문서 효과를 제어하는 첫 좁은 정책이지 범용 산술 엔진은 아니다. 저장 전용 해석은 [068](docs/research/068-opaque-app-core.md)에서 선택형 어댑터로
옮겼다. 실제 문서 수정 정책으로 scalar 규칙을 통합할 합격 조건은
[066 경계 조사](docs/research/066-application-boundary.md)에 기록했다.
코어 수치만으로 범용 앱 런타임을 완성했다고 주장하지 않는다.
macOS 저장 어댑터의 `O_NOFOLLOW` 헤더 노출 문제를 고쳤고, Linux 전용 크기·RSS
도구 없이 C 동작을 실행하는 `make -C prototypes/connections check-portable` 경로를
추가했다. Linux AArch64에서 통과했으며 Apple Silicon 빌드·실행은 아직 확인하지 않았다.
실제 터미널 작업을 검사하는 `check-portable-tui`도 Linux AArch64에서 통과했다.
이 경로는 메모리 수치를 수집하지 않으므로 기존 Linux RSS 상한 검사를 대신하지 않는다.
[Apple Silicon CI 작업](.github/workflows/native-macos-arm64.yml)은 네이티브 앱·
터미널·1 MiB RSS·프로세스 내 전달을 실제 macOS arm64에서 검사하도록 작성했다.
현재 Git 원격은 로컬 저장소라 작업 실행 결과가 없으며, macOS 통과로 표기하지 않는다.
일반 OS 전체·모든 미디어 코덱·클러스터 운영기를 한꺼번에 만드는 것도 이 체크포인트의
완료 조건으로 추가하지 않는다. 위 실제 앱에 필요한 연결을 깊게 완성한다.
코어의 4,864 B 검사를 통과하더라도 필수 실행물이나 선택한 앱의 실제 메모리가 커지면
마이크로 목표를 달성한 것이 아니다. 새 프로토콜·UI는 선택 빌드로 분리하고,
전체 앱 비용을 확인한 뒤에만 작은 앱이라는 표현을 쓴다. [043](docs/research/043-micro-package-boundary.md)부터
고정 정의 CLI·HTTP·TUI의 선택별 압축 묶음 크기도 별도 상한으로 검증한다. 작성 기능을
고정 실행 TUI에 중복해서 넣지 않고, 현재의 소스 CLI·선택형 창 경로에서 다룬다.
새 기능은 기본 코어의 `text`·인스턴스 상태, 선택 실행물의 링크 크기,
실제 작업의 전체 RSS와 배포 묶음 증가를 각각 기록한 뒤 받아들인다.
첫 두 항목만 작거나 소스 배포 파일이 작다는 이유로 마이크로라고 부르지 않는다.
기본 `make all`은 코어와 파서 없는 고정 정의 CLI만 빌드한다. 실행 중 정의를
바꾸는 소스 CLI는 `make editor`, HTTP 서버는 `make server`를 선택해야 한다.
프로세스 관리자나 VM 계층도 첫 체크포인트의 필수 비용으로 추가하지 않는다.
[059](docs/research/059-immutable-file-copy-path.md)의 Linux 선택형 파일 복사는
기존 불변 형식의 큰 편집에서 사용자 공간 호출을 줄였지만, 실제 디스크 쓰기량이나
지연 개선을 증명하지 않았으므로 기본 저장 경로로 승격하지 않는다.
[061](docs/research/061-durable-document-edit-latency.md)의 실제 1 MiB 문서
리비전 수정 비교에서는 페이지 저장이 이 Linux/ext4 호스트에서 훨씬 짧은
중앙값을 보였다. 파일 간 복사의 지연 이득은 구분되지 않았다. 페이지 형식은
추가 코드·꼬리 지연·macOS 검증이 남아 선택형으로 유지한다.
[065](docs/research/065-native-save-latency.md)는 같은 효과를 실제 네이티브
TUI의 Ctrl+S부터 저장 완료 표시까지 확인했다. 1 MiB 마지막 1 B 수정의
중앙값은 기본 93.17 ms, 선택형 페이지 22.04 ms였고, 256 B 문서는
8.54·9.23 ms였다. 선택형 소스 TUI는 코드가 4,958 B 크고 큰 문서의 저장
형식도 달라 기본으로 올리지 않았다. 기본 코어와 기본 TUI의 실행 비용은
이 선택형 실험 때문에 늘리지 않는다.
[062](docs/research/062-paged-store-rollback.md)에서 별도 디렉터리로 본문과
리비전을 내보내 기본 저장기로 다시 읽는 경로를 검증했다. 운영 중 투명한
형식 전환을 뜻하지 않는다.

## 구현 순서와 현재 근거

1. **실행 코어와 호스트 책임 분리.** 기존 저장·응답 경로를 그대로 사용해 영역의 작업 접수,
   준비·실행·완료·회수와 내부 결과 전달을 구현한다. 현재 [022](docs/research/022-execution-core.md)에
   기록한 코드와 검증이 있다. 첫 체크포인트 전체 완료가 아니다.
2. **앱 작성 모델 통합.** get/put 전용 프로필을 실제 작업물의 입력·계산·상태·효과에 필요한
   범위로 확장하고, CLI·UI·원격 입력이 같은 준비된 앱을 실행하도록 만든다. [023](docs/research/023-document-edits.md)은
   네이티브 CLI와 HTTP의 같은 부분 변경 효과, 코어 비용 경계까지 구현한 중간 결과다.
   [024](docs/research/024-native-app-instances.md)에서는 기존 Workbench 작성물을 독립된 네이티브
   계산 인스턴스로 실행하고 같은 코어에서 입력·상태·조건부 저장·복원을 연결했다.
   [025](docs/research/025-native-authoring-shell.md)에서는 선택형 Linux 네이티브 작성 창에서
   정의 교체까지 같은 코어의 작업으로 연결하고 CLI·창 비용을 각각 확인했다.
   [026](docs/research/026-secure-peer-link.md)에서는 선택형 인증 피어에서 같은 앱 작업을
   원격으로 실행하고 CLI·피어 비용을 분리했다.
   [027](docs/research/027-fixed-native-capacity.md)에서는 고정 정의의 실제 용량만 예약해
   반복 메모리를 줄이고 11개 작성물의 동작 일치를 확인했다.
   [028](docs/research/028-shared-fixed-program.md)에서는 CLI·피어의 정의를 한 번 링크하고
   인스턴스에는 가변 상태만 남겨 반복 비용을 더 줄였다.
   [029](docs/research/029-native-document-window.md)에서는 기존 문서 편집 효과를 Linux
   GTK 창에 붙여 CLI·HTTP와 같은 문서 변경·충돌·복원을 검증했다. UI 비용은 별도다.
   [030](docs/research/030-authenticated-document-peer.md)에서는 같은 문서 편집 효과를
   인증된 Pure 피어와 일반 Python TLS 클라이언트에 연결하고, 소비하지 않는 응답 본문을
   선택적으로 전송하지 않는 경로와 선택 빌드 전체 비용을 확인했다.
   [031](docs/research/031-relocatable-document-preview.md)에서는 같은 앱을 선택형 Linux
   묶음으로 만들어 다른 디렉터리에서 전체 경로를 재검증하고, 1바이트 편집도 저장 파일
   전체를 다시 쓰는 현재 한계를 계산했다.
   [032](docs/research/032-micro-native-authoring-boundary.md)에서는 문서 창과 정의 적용을
   통합한 뒤, 기본 배포를 CLI만 선택하도록 줄이고 실제 CLI RSS 회귀 검사를 추가했다.
   [033](docs/research/033-paged-document-storage.md)에서는 같은 문서 앱에 선택형
   페이지 저장 경로를 연결해 큰 문서의 쓰기량 감소와 작은 문서의 손해를 함께 확인했다.
   [034](docs/research/034-hybrid-document-storage.md)에서는 작은 값에 기존 파일 형식을
   적용해 그 손해를 제거하고, 늘어난 코드 크기와 역호환 경계를 검증했다.
   [035](docs/research/035-native-multi-document-window.md)에서는 선택형 네이티브 창에서
   여러 문서를 열고 초안·정의·읽기 실패를 보호해 실제 앱 조작 범위를 넓혔다.
   [036](docs/research/036-gtk-memory-boundary.md)에서는 반복 문서 전환의 힙 증가를
   GTK 텍스트 갱신 경계까지 분리했다. 작은 기본 실행물의 비용과 선택형 GUI의
   비용을 혼동하지 않으며, 이 창을 저메모리 목표 달성으로 취급하지 않는다.
   [037](docs/research/037-build-time-prepared-runner.md)에서는 기존 문서 앱의 검증된
   연결을 빌드 시 준비해 파서 없는 실행기를 만들었다. 기존 문서 작업과 세 가지
   정의의 결과 일치를 확인하고, 링크 코드 크기·실제 RSS·이동 패키지 비용을
   별도로 기록했다. 실행 중 작성 기능은 기존 소스 경로에 남아 있다.
   [038](docs/research/038-fixed-http-document-host.md)에서는 같은 준비된 문서
   앱을 파서 없는 HTTP 호스트에도 연결했다. CLI·소스 HTTP와 저장 버전·1 MiB
   본문·충돌을 교차 검증하고, 느린 수신자의 응답 대여가 예산을 차지하다가
   전송 후 회수됨을 확인했다. CLI+HTTP 묶음을 다른 디렉터리에서도 실행했다.
   [039](docs/research/039-idle-http-wakeups.md)에서는 두 HTTP 호스트가 유휴 중
   50ms마다 깨어나던 경로를 연결 기한에 따른 대기로 바꿨다. 신호가 대기 직전에
   도착해 종료가 멈출 수 있는 경합도 Linux `ppoll`의 원자적 마스크로 막았다. 보관된 실행물과
   현재 실행물의 시스템 호출 추적으로 차이를 확인하고 기한·종료·패키지 동작을
   재검증했다.
   [040](docs/research/040-document-service-capacity.md)에서는 같은 문서 앱을
   1,024개 저장 객체와 8개 동시 클라이언트에 적용했다. 소스 정의·고정 정의
   HTTP 호스트에서 각 4,096개 작업의 응답과 최종 문서 해시를 검증하고,
   프로세스 메모리·버퍼 회수·남은 입력 복사량을 기록했다.
   [041](docs/research/041-posix-idle-signal-wakeup.md)에서는 Linux 전용
   `ppoll` 대기를 POSIX 신호 알림 파이프와 `poll`로 교체하고, 추가된 코드·
   파일 디스크립터 비용과 실제 종료·문서 작업을 검증했다. macOS 빌드는 남는다.
   [042](docs/research/042-micro-native-terminal-editor.md)에서는 같은 준비된
   문서 앱을 선택형 저메모리 터미널 편집기로 연결했다. 실제 PTY의 한국어
   입력·문서 전환·저장·충돌·크기 변경·1 MiB 수정과 터미널 복구를 검사하고,
   실행물·프로세스·이동 가능한 CLI+TUI 묶음의 비용을 따로 기록했다.
   [043](docs/research/043-micro-package-boundary.md)에서는 고정 정의 CLI·HTTP·TUI의
   네 가지 선택 묶음 전체 크기에 상한을 적용하고, 모두 다른 위치에서 다시 실행했다.
   [044](docs/research/044-terminal-viewport-cost.md)에서는 실제 TUI의 1 MiB 화면 갱신
   비용을 줄이고, 여러 행·탭 문서를 다시 열지 못하던 결함을 고쳤다. 동일 PTY 화면
   바이트와 편집·복원 결과를 확인하고, 추가 코드·RSS·전체 묶음 비용을 기록했다.
   [045](docs/research/045-owner-thread-async-effects.md)에서는 기본 코어를 키우지 않고
   선택형 비동기 효과 완료 경로를 만들었다. 실제 문서 저장소와 기존 `editor.pure`로
   요청 해제 후 완료, 다른 작업의 선행 완료, 영역 간 본문 전달, 예산·종료를 확인했다.
   [046](docs/research/046-optional-async-document-http.md)에서는 선택형 HTTP 호스트의
   단일 저장 작업자와 완료 파이프를 실제 문서 앱에 붙였다. 지연된 저장 효과 중
   다른 연결의 응답·기한·종료와 1,024개 문서 작업의 결과·메모리 비용을 확인했다.
   [047](docs/research/047-bounded-native-document-browser.md)에서는 저메모리 TUI가
   실제 저장 문서를 목록에서 다시 찾도록 했다. 1,024개 문서의 탐색·전환·회수와
   증가한 TUI 코드·이동 묶음 비용을 검증했고 기본 CLI·실행 코어는 유지했다.
   [048](docs/research/048-immutable-read-write-overlap.md)에서는 기존 문서의 쓰기를
   파일 동기화 직전에 멈춘 동안 이전 버전 읽기와 이후 새 버전 읽기를 검증했다.
   선택형 호스트만 작업자 둘로 늘리고 기본 코어·HTTP 크기를 유지했으며,
   1,024개 문서 작업에서 선택형 호스트의 전체 프로세스 메모리 비용을 기록했다.
   [049](docs/research/049-idle-app-work-slots.md)에서는 동기 네이티브 앱의 작업 슬롯을
   호출 중에만 연결해 유휴 앱 1,000개의 반복 메모리를 줄였다. 코어·스택·실행물
   증가 비용과 저장·복원·피어·TUI의 기존 동작을 함께 확인했다.
   [050](docs/research/050-bounded-document-prefix-find.md)에서는 선택형 TUI의 정렬된
   실제 문서 1,024개에서 추가 인덱스 없이 이름 접두어를 찾아 열었다. 코어를
   늘리지 않고 TUI 코드·RSS·이동 묶음 비용을 확인했으며, macOS TUI 헤더
   노출을 수정했다.
   [051](docs/research/051-optional-runtime-metrics.md)에서는 기본 영역의 누적 계측을
   선택형으로 분리했다. 같은 실제 앱 1,000개의 입력·저장·복원에서 영역 크기,
   전체 RSS와 이동 가능한 CLI·TUI 묶음 비용을 확인했다.
   [052](docs/research/052-clean-native-source-preview.md)에서는 C 실행 경로와 작성
   소스의 재현 가능한 묶음을 만들고, 깨끗한 디렉터리에서 빌드·테스트·실제
   문서 편집과 `.pure` 규칙 수정을 검증했다. macOS 실행과 라이선스는 남는다.
   [053](docs/research/053-source-loaded-native-terminal-editor.md)에서는 같은 TUI가
   선택형 `.pure` 소스 정의를 실행하도록 연결했다. 필드 배치를 바꾼 정의의
   실제 편집·저장, 이동 묶음의 PTY 작업과 선택 비용을 확인했다.
   [054](docs/research/054-direct-document-path.md)에서는 기존 문서 앱의 생성·읽기·
   부분 편집·재읽기를 직접 저장 호출과 Pure 경로로 각각 실행했다. 같은 결과와
   저장 파일을 확인했으며, 실행물 코드 비용과 ext4 지연의 변동을 공개했다.
   [055](docs/research/055-authenticated-peer-transport-cost.md)에서는 같은 정의와
   인증 TLS 경계의 직접 서버를 비교했다. 양쪽 공통 TCP 지연을 제거하고
   서버 전용 선택 빌드의 크기·RSS·보안 시나리오를 검사했다.
   [056](docs/research/056-server-only-document-package.md)에서는 서버 전용 TLS
   피어와 CLI를 선택한 압축 묶음으로 만들고 전체 크기 상한을 적용했다.
   다른 위치에 풀어 외부 클라이언트의 인증·1 MiB 편집·복원 및 CLI 공유를 확인했다.
   [057](docs/research/057-portable-native-terminal-check.md)에서는 실제 PTY 편집
   검사의 Linux 전용 RSS 수집을 분리하고 고정·소스 정의 TUI를 휴대형 경로에서
   실행했다. 소스 묶음의 이동 후 검사와 기존 Linux RSS 상한도 다시 통과했다.
   새 검사는 개발용 Python·Make 경로에만 있으며 C 런타임 코드는 키우지 않았다.
   [058](docs/research/058-portable-authenticated-peer-check.md)에서는 선택형
   TLS 피어 검사에서도 Linux 전용 RSS 수집을 분리했다. 범용·서버 전용
   C 피어와 외부 클라이언트의 인증·문서·실패 작업을 실제 소켓과 이동한
   소스 묶음에서 실행하고 기존 Linux 코드·RSS 비용을 별도로 확인했다.
   [059](docs/research/059-immutable-file-copy-path.md)에서는 기존 1 MiB
   불변 문서의 1 B 수정에서 원본 읽기·새 파일 쓰기 호출을 추적했다.
   Linux 파일 간 복사를 선택하면 같은 결과·프로세스 RSS로 호출 수를
   줄였으며, 기본 코어는 그대로 두고 선택형 코드 증가를 기록했다.
   [060](docs/research/060-host-native-checkpoint.md)에서는 기존 C·실제 PTY 검사와
   고정/소스 CLI의 1 MiB 문서 생성·읽기·1 B 수정을 한 명령으로 재현하도록 했다.
   Linux AArch64에서는 통과했고 기존 RSS 상한도 유지했다. 측정 도우미는 macOS
   `wait4` 원시 단위를 KiB로 정규화하지만 Apple Silicon 실측은 아직 없다.
   [061](docs/research/061-durable-document-edit-latency.md)에서는 같은 앱의
   1 MiB 내구성 문서 편집을 기본·파일 간 복사·페이지 저장으로 직접 실행했다.
   각 방식 18회와 연속 70회 수정에서 결과·리비전·저장 공간·완료 시간·
   페이지 재구성을 확인하고 선택형 저장 전략의 이득과 제한을 분리했다.
   [062](docs/research/062-paged-store-rollback.md)에서는 선택형 페이지 저장소의
   문서 본문·리비전을 기존 기본 형식의 새 저장 디렉터리로 내보냈다.
   실제 다섯 문서와 1,024개 추가 문서의 재읽기, 변환 중 쓰기 차단·실패 시
   미공개·이후 기본 저장기 수정까지 확인했다. 런타임 코드는 그대로다.
   [063](docs/research/063-real-in-process-routing.md)에서는 실제 1 MiB 문서를
   한 프로세스의 두 독립된 Pure 영역으로 전달했다. 대상 입력 할당기를
   비활성화해도 결과가 같고, 원본 티켓 해제 후 수명·부분 충돌·예산 거절·복원·회수를
   확인했다. 코어 변경 없이 선택형 네이티브 명령만 추가했다.
   [064](docs/research/064-release-callback-reentrancy.md)에서는 자원 해제 콜백이
   같은 영역에 재진입해 슬롯 회수 상태를 바꿀 수 있던 경로를 막았다. 기본
   코드는 72 B 늘었으나 6 KiB 상한과 영역 128 B를 유지했고, 실제 앱·
   새 소스 묶음의 검증을 통과했다.
   [065](docs/research/065-native-save-latency.md)에서는 기존 선택형 페이지
   저장소를 실제 네이티브 TUI에 연결해 Ctrl+S 완료 시간·코드·RSS를 비교했다.
   기본·선택형 CLI+TUI를 각각 이동해 검증하고, 선택형 경로도 깨끗한 소스
   빌드에서 다시 실행했다. 기본 코어와 기본 저장 경로는 유지했다.
   [066](docs/research/066-application-boundary.md)에서는 문서의 저장 전용
   연산과 scalar 앱의 이벤트 우회 연결이 아직 하나의 작성 모델이 아님을
   코드에서 확인하고, 기존 문서 수정에 계산 정책을 결합할 합격 조건을 정했다.
   [067](docs/research/067-work-slot-layout.md)에서는 활성 작업 슬롯을
   224→216 B로 줄이면서 기본 코어 코드를 5,980 B로 유지했다. 비동기·
   네이티브 C 앱·TUI·실제 문서 전달을 검증하고 당시 소스 묶음과 네 가지
   실행 묶음을 다른 위치에서 확인했다. macOS 실행은 남아 있다.
   [068](docs/research/068-opaque-app-core.md)에서는 문서 해석을 기본 코어 밖의
   선택형 어댑터로 옮겼다. 기본 코어 `text` 4,632 B, 유휴 영역 120 B를
   검증하고, 선택형 HTTP의 증가 비용까지 공개했다. 동기·비동기 서비스와
   인증 피어의 실제 문서 작업, 이동한 새 소스·실행 묶음을 검사했다.
   [069](docs/research/069-atomic-authored-size-policy.md)에서는 작성한 최종 문서
   크기 상한을 같은 저장 버전의 쓰기 잠금 안에서 검사했다. 기본 코어와
   준비된 정의 크기를 늘리지 않고 CLI·HTTP·TUI·인증 피어의 결과와
   선택형 호스트 코드 비용을 함께 검증했다. 일반 계산 모델은 남아 있다.
   [070](docs/research/070-micro-default-build.md)에서는 기본 빌드를 코어와
   파서 없는 고정 정의 CLI로 제한하고 깨끗한 소스 추출에서 선택 기능이
   기본 출력에 섞이지 않는지 확인했다. 링크 코드가 줄었지만 RSS 개선은
   입증하지 않았다.
3. **실제 네이티브 앱과 통신.** 작성·편집·저장·복원·충돌 처리를 연결하고 자체 통신 형식과
   검증된 보안 전송을 붙인다. 외부 호환 입력·출력도 유지한다.
4. **규모·실패·사용성 확인과 공개 자료.** 큰 작업물·느린 소비자·혼합 작업에서 구조가
   유효한지 확인한다. 기능·정확성·필요한 보안을 유지한 비교만 수행하고 약한 부분을 수정한다.

각 단계는 앞 단계의 실제 작업물을 확장한다. 새로운 빈 데모나 별개의 미니 언어를 반복해서
만들지 않는다. 목표를 한 번의 작업 분량이나 이미 통과한 테스트 범위로 축소하지 않는다.