# test 오프라인 누적 배포 준비 재개

6개 archive(약64.289GiB)의 순차 반출/전체 검증을 완료했다. 수정 source commit 때문에 설치 패키지 봉인 전이다.
`package.json`과 별도 승인 SHA256가 없는 준비본을 USB에서 적용하지 않는다.

## 읽는 순서

1. `checkpoint.ko.md`: 단계와 승인 경계.
2. `reports/cleanup-result.json`: 다운로드 cache 정리 결과.
3. `reports/operator-tests-r02.log`, `operator-validation-r02.json`: 최종55개 격리 표적 검증.
4. `reports/r02/export-progress.json`: 완료한 image와 실패/진행 상태.
5. `Contextra_Offline_Preparation_20261103_r02/images`: 완료 자료. 원래 경로는 `reports/locations.json`으로 연결했다.
6. `reports/final-validation.json`: 운영 대조, min/root 여유, source Gate와 미실시 항목.

## 고정 경계

- 서비스 image별 순차 저장이며 실제 Runtime·네트워크·Docker 설정·GPU·채널·Event는 변경하지 않는다.
- test 준비 전용 root 최저 보호선10GiB/선제 중단12GiB다. 실제 설치/복귀와 다른 서버의 기준은 바꾸지 않는다.
- 관련 image/build cache/volume/journal은 보존했다. 기존 run의 부분 tar도 그대로 둔다.
- 새 후보의 Runtime 소스·모델·native는 기존 검증 근거를 재사용한다. 이번에는 엔진 테스트나 튜닝을 하지 않는다.
- 수정 source가 승인 commit으로 고정되기 전에는 봉인하지 않는다. `UNSEALED_PREVIEW`는 실행용 배포본이 아니다.

## 사용자의 첫 수동 단계

먼저 이번 소스 수정의 Git Closeout을 검토하고 승인한다. 그 다음 동일 archive로 봉인을 재개한다.
봉인 완료 후 Windows 다운로드 → USB 복사 → 서버 읽기 전용 검사 → staging → 사용자 유지보수 정지/적용 순서다.
기존 USB 자료는 보존하고, 큰 tar를 그대로 운반할 수 있는 파일시스템과 여유 공간을 먼저 확인한다.
FAT32처럼 단일 파일 제한이 있으면 기존 도구의2GiB 분할/재결합과 지문 검증을 사용한다. 이번에 USB를 포맷하지 않는다.

실제 적용 전에 Event 목적지가 test 연계 환경인지 확인한다. 다른 현장 목적지이면 시험을 시작하지 않는다.
같은 image가 이미 설치돼 있으면 load를 생략할 수 있다. 따라서 이번 준비와 후속 수동 성공만으로
빈 Docker 저장소의 cold load, 청계산 actual 호환, 실제 rollback 또는 장시간 안정성을 검증했다고 보지 않는다.