1 files changed, 39 insertions, 0 deletions

diff --git a/docs/design/004-prepared-connections.md b/docs/design/004-prepared-connections.md
new file mode 100644
index 0000000..df4ccaf
--- /dev/null
+++ b/docs/design/004-prepared-connections.md
@@ -0,0 +1,39 @@
+# 실행 준비에서 연결을 정하는 첫 범위
+
+현재 필드·동적 입력 범위 확장은 [005](005-field-connections.md)를 따른다. 아래는 첫 상수 구간 프로파일의 기준이다.
+조건부 바이트 부분 변경 `store.splice`와 네이티브 자동화 경로는 [023](../research/023-document-edits.md)에 추가했다.
+
+2026-09-23 착수 기준:
+
+- 바꿀 결정: 기존 저장·응답 순서를 C에 고정하지 않고 작성한 관계에서 접근 범위와 수명을 준비한다.
+- 남은 질문: 중첩 구간·별칭을 실행 경로에서 없애면서 범위 오류·외부 효과·소유권을 유지할 수 있는가?
+- 최소 확인: 기존 실제 TCP 저장·복원을 작성 파일로 실행하고, 일부만 필요한 응답은 최종 구간만 매핑한다.
+- 중단 기준: 작성 변경이 실제 경로에 반영되고 의미 검사를 통과하면 범용 그래프 VM·새 쿼리 엔진으로 확장하지 않는다.
+
+첫 프로파일은 `on get`·`on put` 두 요청을 다룬다. 기존 숫자/화면 DSL과 파서를 공유하지 않는
+네이티브 연결 작성 실험이며 통합 언어의 확정 문법은 아니다. 준비는 서버 시작 시 한 번 한다.
+동적 코드 생성·LLVM·JIT·요청별 그래프 순회는 필요하지 않은 범위다.
+
+값은 읽기 전용 바이트 범위와 저장 결과다. `let`은 별칭·정확한 `range` 또는 저장 호출을
+연결한다. `reply(result[, bytes])`는 결과 버전과 선택한 바이트를 호스트 응답에 연결한다.
+저장 실패는 응답 오류로 전파하며, 본문 없는 reply도 저장 호출을 생략하지 않는다.
+내구성 불확실 결과도 성공이나 롤백으로 바꾸지 않는다.
+
+읽기는 한 번의 `store.read(request.key)` 이후에 뷰를 정의한다. 쓰기는 모든 입력 뷰를
+정의한 뒤 한 번의 `store.write(request.key, request.revision, bytes)`를 호출한다.
+쓰기를 수행한 뒤 실패할 수 있는 뷰 연산을 놓는 문법은 첫 프로파일에서 거절한다.
+하나의 요청에서 여러 외부 효과·루프·동적 분기는 아직 지원하지 않는다.
+
+`range(bytes, offset, length)`는 정확한 범위를 요구한다. 잘라내거나 부족한 바이트를
+조용히 무시하지 않는다. 중첩 구간을 합칠 때 최종 범위만 검사하면 의미가 달라진다.
+예: `range(range(body, 16, 64), 16, 16)`은 최종 `[32,48)`을 쓰지만 원본이 80 B 이상이어야
+한다. 준비된 경로는 최종 범위와 원본 최소 길이를 함께 보관한다. 사용되지 않는 구간의
+오류도 보존한다. 고정된 부모 구간을 넘는 자식 범위는 작성 오류로 시작 전에 거절한다.
+
+읽기 전송은 매핑의 수명을, 쓰기 결과와 함께 입력을 돌려주는 전송은 수신 구간의 수명을
+완료·중단까지 유지한다. 개발자가 해제 함수를 작성하지 않는다. 이 수명 선택은 현재 두
+생산자의 닫힌 계약에서 도출하며 임의 외부 모듈의 소유권 추론을 구현했다고 세지 않는다.
+
+이번에 제거할 것은 뷰 정의의 실행 단계와 불필요한 전체 본문 접근이다. 별칭·부분 범위는
+원래도 본문 복사를 요구하지 않는다. 이를 실제 복사를 제거한 수치로 꾸미지 않으며,
+준비된 구간 길이를 RSS 절감으로 해석하지 않는다. 파일·커널·페이지 비용은 그대로 남는다.