# 실행 준비에서 연결을 정하는 첫 범위

현재 필드·동적 입력 범위 확장은 [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 절감으로 해석하지 않는다. 파일·커널·페이지 비용은 그대로 남는다.