Part.1 · Installation and first connection

문서 탐색: 설치·첫 사용 · 설치 후 도구 · 사용 용례 · 문제 해결 사례

처음 설치한다면: 목적에 맞는 시작점

모든 도구를 순서대로 설치할 필요는 없습니다. 다음 표에서 오늘 하려는 일을 하나 고르고 해당 안내부터 시작하십시오. 이 페이지를 여는 데에는 브라우저만 필요합니다. SDK 합성 예제를 실행하는 데에는 어플라이언스 계정·고객 활성화·실제 API 접속이 필요하지 않습니다.

각 도구의 상세 절은 설치 후 도구 목록에 있습니다. 도구가 필요한 단계에서만 설치합니다. 실제 연결·등록·Work가 필요한 시점에는 해당 릴리스의 승인된 경로가 따로 필요합니다.

설치 전 10분: 내 컴퓨터와 받은 파일 확인

1. 설치 대상을 구분합니다. VM 이미지는 서버용이고 PackrGUI·Builder는 사용자 PC용입니다. SDK는 연동 작업 PC에서 휴대형으로 쓸 수 있습니다. Document는 JSON 자료이며 별도 앱 설치 파일이 아닙니다.
2. OS와 CPU를 확인합니다. 아래는 읽기 전용 조회입니다. arm64/aarch64와 x86_64/AMD64는 서로 다른 패키지입니다. 현재 SDK의 기록된 조합은 macOS ARM64, Debian 13 AMD64, Windows AMD64입니다. 다른 Linux 배포판이나 Windows ARM을 같은 조합으로 간주하지 않습니다.
3. 받은 목록에서 본체·선택 의존성·예제·버전·지문·서명 유무·네이티브 전제 조건을 확인합니다. SDK의 Rust 세트는 선택 구성이며 온라인 환경의 기본값을 바꾸지 않습니다.
4. 빈 작업 위치를 정합니다. 설치 파일 원본, 해제한 프로그램, 수정할 입력, 실행별 결과를 분리합니다. 회사 정책상 허용된 개인 폴더를 사용하고 기존 폴더를 덮어쓰지 않습니다.
5. 필수 연결 정보가 필요한 경로라면 관리자로부터 전달받습니다. 주소만으로는 충분하지 않습니다. 계정·기기 등록 방식, 기대하는 조직·설치 신원, TLS 서버명과 지원 연락 경로까지 확인합니다.

# macOS 터미널에서만
sw_vers
uname -m
# Linux 터미널에서만
cat /etc/os-release
uname -m

# Windows PowerShell
$PSVersionTable.PSVersion
(Get-CimInstance Win32_OperatingSystem).Caption
(Get-CimInstance Win32_ComputerSystem).SystemType

파일 종류를 보고 올바른 절차 선택하기

이 문서의 범용 .pkg/.exe/.deb 파일명은 해시 명령 설명용입니다. 실제 SDK 파일을 그 이름으로 찾지 마십시오. 현재 로컬 운영자판에서는 현재 SDK 패키지 표가 본체·의존성의 실제 파일 링크와 지문을 제공합니다. 다른 구성요소는 별도의 해당 릴리스 제공 목록을 확인합니다. 존재하지 않는 포털·다운로드 링크·서명 상태를 추측하지 않습니다.

명령을 처음 복사할 때

• macOS의 터미널·Linux 셸에는 bash 예시를, Windows PowerShell에는 powershell 예시를 사용합니다. $나 PS C:\> 같은 프롬프트는 명령이 아니며 복사하지 않습니다.
• /absolute/path/..., C:\absolute\path\..., 대괄호 입력란은 내가 받은 실제 값으로 먼저 바꿀 자리입니다. 따옴표는 유지합니다. 경로에 공백이 있으면 특히 필요합니다. Unix의 ./bin/...과 Windows의 .\bin\...을 바꾸어 쓰지 않습니다.
• install_root, $installRoot 같은 변수는 해당 준비 절을 실행한 같은 셸에서만 존재합니다. 터미널을 새로 열면 아래의 재개 절차로 다시 지정합니다. 폴더명·대소문자·파일 확장자 .json.txt를 확인합니다.
• 한 블록 안에서도 한 단계씩 실행하고 결과를 읽습니다. 문서의 예상 결과는 실제 성공 로그가 아닙니다. 오류가 나오면 이어 붙인 나머지 명령을 실행하지 않습니다.
• 예제 원본을 보존하고 사본을 UTF-8로 저장합니다. Windows PowerShell 5.1의 기본 > 또는 Out-File은 UTF-16일 수 있습니다. JSON 입력은 UTF-8 편집기를 사용하고 저장 인코딩을 확인합니다.

빈 폴더를 어디에 만들지 이해하기

VibePackr-SDK-install-01/
  sdk/             압축 해제한 본체; bin, docs, examples
  dependencies/    선택 의존성 세트; 원본 검증 입력 유지
  inputs-02/       수정할 전체 input.json 사본
  runs/
    custom-01/     첫 성공 후 생기는 결과
    mcp-01/        별도 MCP 결과
    custom-api-candidate-02/  수정 입력의 새 결과

위는 폴더 관계 설명입니다. 실제 생성 명령은 SDK 절에 있습니다. runs 부모는 준비하되 custom-01 같은 최종 후보 폴더는 SDK가 만들게 둡니다. GAPE도 새 출력 경로를 사용합니다. Helper의 로그 보관 폴더와 Builder의 제품 관리 후보는 별개입니다.

어디까지 끝났는지 기록하고 다음에 이어 하기

설치·연결·후보 생성·실제 Work를 한 번에 “완료”라고 적지 않습니다. 각 연습이 끝날 때 날짜, 도구 버전·경로, 입력 지문, 실제 명령 또는 화면 작업, 결과 위치, 마지막 성공 단계와 남은 담당자를 적습니다. 문제 해결에는 이 기록이 출발점입니다.

다시 시작할 때 받은 패키지와 보관된 결과를 지우지 마십시오. SDK의 경로 재개 예시는 SDK 절에 있고, 다른 도구도 입력·출력의 절대 경로를 다시 선택합니다. 애매한 실행 결과가 남으면 먼저 기존 Work/요청 ID를 조회하고, 중복 실행을 새 시도로 해결하지 않습니다. 막힌 단계는 문제 해결 색인의 시작 분류표로 이동합니다.

이 문서를 사용하는 방법

이 문서는 고객의 담당자가 파일 수령부터 첫 Work 결과 확인까지 직접 진행하도록 돕습니다. 제품이 표시하는 상태와 해당 릴리스의 서명된 매니페스트가 최종 기준입니다. 예시와 일반 운영체제 명령이 제품의 거부 결정이나 릴리스 문서를 대신하지 않습니다.

• 담당자: 어플라이언스 설치 관리자, PackrGUI 사용자, 선택적으로 Builder 운영자. 설치·권한 부여·Pack 승인 담당자가 다를 수 있습니다.
• 준비물: 해당 릴리스의 전달 목록과 서명 검증 안내, 지원 환경 표, 고객 조직의 설치 권한, 네트워크·인증 정보, 릴리스별 지원 연락 경로. 암호·비밀키를 지원 요청에 첨부하지 마십시오.
• 완료 기준: 같은 릴리스와 설치 신원에 대해 파일 검증, 서비스 준비, 관리자 범위, 인증된 연결, 검증된 런타임 바인딩, 승인된 실제 Work, 결과와 영수증을 각각 확인합니다. 한 단계의 성공이 다음 단계의 성공을 뜻하지 않습니다.
• 중지 기준: 파일 지문·서명 불일치, 예상하지 못한 호스트 신원, 다른 고객·설치 신원, 권한 거부, 상태 무결성 경고가 나오면 다음 단계로 넘어가지 마십시오. 원본 메시지와 시각을 기록하고 릴리스별 지원 경로를 이용하십시오.

1. 전달 파일과 대상 환경 확인

1. 공식 포털이 게시된 릴리스라면 setup.vibepackr.com에서 시작합니다. 오프라인 설치라면 전달받은 Start_Setup.html을 엽니다. 포털과 오프라인 안내의 릴리스 식별자와 구성요소 목록이 같은지 확인합니다. 포털이 열리지 않는 상황은 제품 VM 장애와 구별하십시오.
2. 전달 목록에서 어플라이언스 이미지, 해당 운영체제용 PackrGUI, 선택 구성요소인 Enterprise Pack Builder와 Additional Packs의 실제 제공 여부를 확인합니다. 소개 페이지에 표시된 구성요소라도 릴리스 목록에 없으면 설치하지 않습니다.
3. 릴리스 매니페스트의 버전·플랫폼·SHA-256과 받은 파일을 대조하고, 동봉된 공식 절차로 서명을 검증합니다. 지문은 손상 여부를 확인하지만 서명 검증을 대신하지 않습니다. 일반 파일 지문 확인 예시는 macOS의 shasum -a 256 파일명, Linux의 sha256sum 파일명, Windows PowerShell의 Get-FileHash -Algorithm SHA256 파일명입니다. 파일명이 공백을 포함하면 각 셸의 인용 규칙을 따릅니다.
4. 릴리스별 호환성 표에서 대상 클라우드 또는 가상화 환경, CPU 아키텍처, 메모리·디스크, 네트워크, 인증 경로와 지원 런타임을 확인합니다. 로컬 7B 모델을 사용할 계획이라면 모델 실행에 필요한 자원을 별도로 확인하십시오. 최소 사양은 전달된 호환성 표를 따르십시오.
5. 기록할 값: 릴리스 ID, 설치 파일 이름과 지문, 이미지 식별자, 대상 플랫폼, 파일 검증 결과. 불일치 파일을 이름만 바꾸거나 다른 플랫폼 패키지로 대체하지 마십시오.

다음 단계로 진행할 조건: 전달 목록에 있는 정확한 파일의 서명과 지문이 맞고 대상 환경이 지원 목록 안에 있습니다.

받은 설치 파일을 확인하는 실제 명령 예시

이번 릴리스의 서명된 목록에 있는 파일명과 SHA-256을 사용하십시오. 아래 명령은 운영체제의 읽기 전용 파일 확인 예시입니다. 예시 파일명을 받은 파일명으로 바꾸고, 별도로 릴리스의 서명 확인 절차도 완료하십시오. 이전 안내서의 지문을 재사용하지 마십시오.

# macOS 터미널
shasum -a 256 "VibePackr-installer-for-this-platform.pkg"
# Linux 셸
sha256sum "VibePackr-installer-for-this-platform.deb"

# Windows PowerShell
Get-FileHash -Algorithm SHA256 "VibePackr-installer-for-this-platform.exe"

판정 예시: 매니페스트에는 A1..., 로컬 명령 결과에는 B2...가 표시됩니다. 설치 전에 멈추고 정확한 파일명과 두 지문을 남겨 전달 담당자에게 올바른 서명 파일을 요청하십시오. 파일명을 바꿔도 지문은 바뀌지 않습니다.

2. 고객 환경에 새 어플라이언스 배포

1. 전달된 릴리스가 지정한 서명 어플라이언스 이미지로 새 인스턴스를 배포합니다. 다른 버전의 이미지나 기존 VM을 복사해 설치 파일로 사용하지 마십시오.
2. 인스턴스 생성 후 첫 부팅이 끝날 때까지 기다립니다. 클라우드 콘솔의 실행 중은 VM 전원이 켜졌다는 뜻입니다. 제품의 서비스 준비는 제품 상태 화면 또는 릴리스별 진단으로 별도 확인합니다. 초기화 중에는 접속을 반복하기보다 공식 대기·상태 절차를 따르십시오.
3. 제품이 새로 생성한 설치 신원, 고객 조직, 서비스 엔드포인트와 연결 방법을 기록합니다. 두 독립 인스턴스가 같은 설치 신원이나 호스트 신원을 보이면 복제 상태를 의심하고 사용을 멈춥니다.
4. 관리자 또는 클라이언트의 최초 접속에서 표시되는 호스트 신원을 공식 릴리스의 검증 경로와 대조합니다. 예전 VM의 키를 새 VM에 재사용하거나 신원 경고를 무시하지 마십시오.

다음 단계로 진행할 조건: 첫 부팅이 완료되고 제품 서비스가 준비 상태이며, 이 인스턴스의 고유 설치 신원과 인증된 접근 경로가 확인됩니다.

3. 최초 관리자 등록과 허용 범위

1. 고객 환경 내부의 Customer Setup UI 또는 릴리스가 지정한 관리자 절차를 엽니다. 로컬 운영체제 로그인만으로 제품의 Appliance Administrator 권한이 생기지는 않습니다.
2. 실제 관리자가 고객·설치·지원 런타임 범위를 확인하고 제품이 요구하는 방식으로 초기 등록을 완료합니다. 자동 바인딩은 이 승인 범위 안에서 동작합니다. 어떤 환경 변화도 무조건 승인하는 기능이 아닙니다.
3. 관찰과 런타임 바인딩에 필요한 최소 권한, 적용 대상과 유효기간을 제품 화면에서 확인합니다. 계정 이름이 맞아도 고객·설치 신원이 다르면 계속 진행하지 않습니다.
4. 릴리스가 대화형 터미널 입력을 요구하는 경우, 복사한 명령을 비대화형 원격 스크립트나 파이프로 보내지 마십시오. 제품이 지정한 로컬 위자드 또는 대화형 세션에서 관리자가 직접 확인합니다.
5. 등록 후 관리자 상태를 읽기 전용으로 다시 확인합니다. 저장소 접근 오류나 Permission denied가 나오면 임의로 소유권·권한·잠금 파일을 고치지 말고 정확한 오류를 지원 경로로 전달합니다.

다음 단계로 진행할 조건: 제품이 현재 설치 신원에 대해 관리자 역할·허용 범위·유효기간을 확인합니다.

4. 로컬 런타임 감지와 자동 바인딩

1. 릴리스가 지원하는 로컬 런타임과 모델을 고객 환경에 준비합니다. 예를 들어 제공된 호환성 표에 Ollama와 Qwen 모델이 포함돼 있다면 해당 버전과 자원 요구사항을 확인합니다. 이 예시를 모든 설치의 기본 모델로 간주하지 마십시오.
2. Packr 또는 PackrGUI의 감지·설정 위자드에서 감지됨 → 검증됨 → 바인딩됨을 구별합니다. Core가 관찰한 설치·고객·런타임 신원과 관리자 범위를 검증한 뒤에만 바인딩을 적용합니다. 단순히 모델 파일이 있거나 런타임 프로세스가 실행된 것만으로 바인딩되지는 않습니다.
3. 현재 바인딩의 런타임 종류, 모델 참조, 설치 신원, 상태와 제품이 기록한 시각을 확인합니다. 바인딩 성공은 모델 추론 또는 Work 성공의 증거가 아닙니다.
4. 런타임을 교체·재시작하거나 모델 별칭이 바뀌었다면 새 관찰을 기다리고 제품이 다시 검증한 바인딩을 확인합니다. 이전 바인딩 화면만 보고 새 런타임을 사용하지 마십시오.
5. 허용 범위를 벗어난 변경이나 여러 모델 중 대상을 특정할 수 없는 상태는 위자드의 거부 사유에 따라 관리자가 해결합니다. 제품 상태 저장소를 직접 편집하거나 기존 바인딩을 강제로 재사용하지 마십시오.
6. 오프라인 운영이 필요하면 모델이 이미 로컬에 있고 릴리스가 지정한 로컬 전용 네트워크 설정이 적용되는지 확인합니다. 네트워크 정책과 제품의 실제 통신 기록을 확인하지 않고 외부 통신이 없었다고 판단하지 마십시오.

다음 단계로 진행할 조건: 제품이 현재 설치에 대해 지원 런타임과 모델의 바인딩을 검증된 상태로 표시합니다.

5. PackrGUI, 헤드리스 클라이언트와 Builder 연결

1. 릴리스 매니페스트가 지정한 해당 운영체제용 PackrGUI를 설치합니다. macOS, Windows, Linux 패키지는 서로 대체할 수 없습니다. 운영체제의 보안 경고가 뜨면 서명 상태와 전달된 설치 안내를 확인하고 보안 검사를 우회하지 마십시오.
2. 릴리스가 지정한 주소·네트워크·인증 경로로 고객 어플라이언스에 연결합니다. 제품 화면에서 서버가 응답하는지, 인증이 되었는지, 고객·설치 신원이 같은지 각각 확인합니다. 화면이 열리는 것만으로 인증된 연결은 아닙니다.
3. GUI 없이 운영한다면 릴리스가 지정한 헤드리스 CLI 또는 서비스 경로를 별도로 검사합니다. GUI 연결 성공으로 헤드리스 준비나 Work 권한을 대신 증명할 수 없습니다.
4. Enterprise Pack Builder가 실제 릴리스 구성요소일 때만 별도 설치·권한 절차를 따릅니다. Builder는 Pack 후보의 준비·검증을 지원합니다. 후보 생성이 Pack 승인·사용 권한·실행을 뜻하지 않습니다.
5. 릴리스에서 Safari 웹 passkey 확인을 요구하면 정식 HTTPS 주소와 등록된 관리자 절차를 사용합니다. passkey 등록과 매 작업 승인은 별개입니다. 브라우저 창이 열리거나 앱으로 돌아왔다는 사실만으로 Core 승인을 완료한 것으로 판단하지 마십시오. 등록이 거부되면 다른 계정의 자격 증명을 빌리지 않습니다.

연결 이후의 작업은 설치 후 도구 안내서를 따르십시오. Builder, GAPE, Integration Helper, SDK Engine, Contract & Document의 설치 위치와 사용 순서를 확인할 수 있습니다. 전체 관계를 보여주는 Non-SI 아키텍처 그림도 포함돼 있습니다.

다음 단계로 진행할 조건: 사용할 각 클라이언트 경로의 인증·설치 신원·허용 기능을 제품에서 확인합니다.

6. 첫 Work 실행과 영수증 확인

1. 릴리스가 지정한 지원 Pack 또는 시험 Work를 선택합니다. Pack의 계약·범위·사전 조건·승인·사용 권한을 실행 전에 확인합니다. Builder가 만든 후보를 승인된 Pack처럼 실행하지 않습니다.
2. 제품이 표시하는 실행 계획과 대상 환경을 확인하고, 고객이 승인한 경로로 한 건을 실행합니다. 실제 Work는 설치, 연결, 런타임 바인딩과 별도 단계입니다.
3. 로컬 모델을 사용했다면 해당 Work 기록에서 모델 호출이 실제로 일어났는지 확인합니다. 런타임이 바인딩됨으로 보이거나 모델이 응답 가능해도 Work 호출이 없을 수 있습니다.
4. 최종 상태, 결과 검증, Work 기록과 영수증을 같은 설치·릴리스 신원으로 대조합니다. 실패, 중단, 롤백, 검증 대기 상태는 성공으로 기록하지 않습니다.
5. 첫 사용 완료를 선언하기 전에 담당자가 아래 확인표를 채웁니다. 확인 안 됨은 실패와 구별해 적되 완료로 표시하지 않습니다.

실제 운영 용례

설치를 마친 뒤 어떤 기능을 어떤 순서로 확인할지는 사용 용례 색인에서 시작하십시오. 새 설치, 런타임 변경과 자동 재바인딩, PackrGUI·헤드리스 분리, Builder 후보, 첫 Work를 각각 담당자·선행 조건·증거·실패 분기까지 풀어 설명합니다. 사례 A~J는 증상이 발생했을 때 찾아보는 문제 해결 문서입니다.

7. 문제 해결 사례

다음은 설치와 사용 중 나타날 수 있는 상황별 안내입니다. 제품의 실제 오류 문구는 버전과 플랫폼에 따라 다를 수 있습니다. 각 사례의 안전한 조치까지만 직접 수행하고, 신원·권한·상태 무결성 오류는 지원 경로로 넘기십시오. 각 제목의 링크에서 상황 예시, 순서별 확인, 결과별 분기, 지원 요청 예시와 완료·중지 기준을 자세히 확인하십시오. 증상에 맞는 사례를 고르기 어렵다면 문제 해결 색인부터 보십시오.

사례 A — VM은 켜졌는데 제품은 준비되지 않음

• 증상: 클라우드 콘솔에는 VM이 실행 중이나 제품 상태는 초기화 중이거나 서비스 준비가 아닙니다.
• 먼저 확인: 첫 부팅 완료 표시와 제품 상태를 확인합니다. 필요한 초기화 구성요소가 없다는 오류가 표시되면 이미지 ID와 메시지를 기록합니다.
• 조치: 릴리스가 허용한 대기와 읽기 전용 진단을 한 번 수행합니다. 요구 구성요소가 빠졌거나 준비 상태가 계속 나오지 않으면 이미지 ID와 상태를 지원팀에 전달합니다. 고객 VM에서 임의 패키지를 설치하거나 서비스 상태 파일을 지우지 마십시오.

사례 B — SSH 또는 앱이 예전과 다른 호스트를 표시함

• 증상: 호스트 키 변경 경고, 인증된 서버 신원 불일치, 예상하지 못한 설치 신원.
• 먼저 확인: 접속하려는 인스턴스와 이전 인스턴스가 다른지, 주소·조직·설치 ID가 맞는지 확인합니다. 호스트 키가 바뀌었다면 이전 신뢰 기록을 자동으로 재사용하지 않습니다.
• 조치: 접속을 멈추고 릴리스의 공식 독립 검증 경로로 현재 호스트 신원을 확인합니다. 검증 전에 경고를 무시하거나 호스트 검사 옵션을 끄거나 저장된 키를 임의 교체하지 마십시오.

사례 C — 접속 거부가 네트워크 문제인지 인증 문제인지 불분명함

• 증상: 부팅 직후 연결 시간 초과, 로그인 실패, 또는 클라이언트는 열리지만 제품은 미인증 상태.
• 먼저 확인: VM/서비스 준비 → 공식 주소와 네트워크 경로 → 현재 계정 및 인증 방법 → 제품의 고객·설치 신원 순서로 확인합니다. 접속 시간 초과와 로그인 거부는 조치가 다릅니다.
• 조치: 릴리스가 지정한 재확인 절차를 따릅니다. 다른 사람의 키나 계정으로 우회하지 말고, 실패 단계·시각·정확한 메시지를 기록합니다.

사례 D — 관리자 등록이 비대화형 입력을 거부함

• 증상: 명령을 원격 스크립트나 파이프로 보냈을 때 실제 터미널 또는 사용자 확인이 필요하다는 거부가 나옵니다.
• 먼저 확인: 릴리스가 대화형 로컬 위자드 또는 터미널을 요구하는지 확인합니다.
• 조치: 지정된 대화형 절차에서 실제 관리자가 직접 확인합니다. 확인 단계를 자동 입력으로 흉내 내지 마십시오. 등록 후 제품의 역할·범위가 기록됐는지 다시 읽습니다.

사례 E — 관리자 등록 후 접근 오류

• 증상: 관리자는 등록됐지만 이후 관찰·바인딩이 Permission denied 또는 저장소 접근 오류로 멈춥니다.
• 먼저 확인: 제품이 표시한 거부 코드와 발생 단계, 서비스 준비 및 설치 신원을 읽기 전용으로 확인합니다. 저장소 접근 문제인지 역할·범위 거부인지 구분합니다.
• 조치: 제품 상태 파일이나 OS 권한을 임의로 바꾸지 않습니다. 해당 릴리스의 수정 여부를 확인하고 지원팀에 정확한 오류·버전을 전달합니다.

사례 F — 런타임은 보이는데 바인딩되지 않음

• 증상: 로컬 모델이 설치되고 런타임이 실행 중인데 제품은 감지됨 또는 거부됨만 표시합니다.
• 먼저 확인: 지원 모델·런타임, 설치 신원, 관리자 승인 범위, Core의 검증 상태와 거부 사유를 봅니다. 모델 별칭·런타임 주소를 바꿨다면 새 관찰 이후 상태인지 확인합니다.
• 조치: 범위 안의 환경이라면 릴리스 위자드가 지정한 재관찰 절차를 따릅니다. 범위 밖 또는 모델 선택이 모호하면 관리자에게 명시적 조치를 요청합니다. 데이터베이스를 수정해 BOUND로 표시하지 마십시오.

사례 G — 로컬 모델을 사용하려는데 메모리 또는 네트워크가 부족함

• 증상: 로컬 모델이 시작되지 않거나, 오프라인 환경에서 모델 다운로드·메타데이터 확인이 시간 초과됩니다.
• 먼저 확인: 릴리스의 모델별 메모리 요구사항, 이미 설치된 로컬 모델, 고객의 외부 통신 정책을 확인합니다. 바인딩 상태와 Work 실행 상태를 각각 확인하십시오.
• 조치: 지원 사양에 맞는 자원을 준비하고, 오프라인 운영이면 릴리스가 제공하는 로컬 모델 준비 경로를 사용합니다. 실패한 외부 요청을 추론 성공이나 무외부 통신으로 보고하지 않습니다.

사례 H — Pack 후보는 있는데 실행할 수 없음

• 증상: Builder에서 후보가 보이지만 Work 목록에 승인된 Pack으로 나오지 않거나 실행이 거부됩니다.
• 먼저 확인: 후보의 검증 상태, 승인 여부, 고객 권한, 계약 범위, 사전 조건을 각각 확인합니다.
• 조치: 제품의 승인 절차를 따릅니다. Builder 화면의 준비됨을 실행 허가로 해석하지 마십시오.

사례 I — 바인딩은 성공했지만 Work 영수증이 없음

• 증상: 런타임 상태는 바인딩됨이지만 결과나 영수증을 찾을 수 없습니다.
• 먼저 확인: Work가 실제로 제출·승인·실행됐는지, 최종 상태가 성공·실패·중단·롤백 중 무엇인지 확인합니다. 바인딩 화면만으로 영수증이 생성되지는 않습니다.
• 조치: 릴리스가 지정한 첫 Work 절차와 기록 위치를 따릅니다. 과거 바인딩 기록을 Work 영수증으로 대신하지 마십시오.

사례 J — 이미지 또는 복제 VM에 이전 사용자의 흔적이 보임

• 증상: 새 고객 VM에서 예상하지 못한 사용자 홈, 접근 키, 기존 설치 신원이나 설정이 보입니다.
• 먼저 확인: 설치에 사용한 이미지 식별자와 새 인스턴스 여부만 확인합니다. 예상하지 못한 이전 사용자 흔적이 보이면 사용을 멈춥니다.
• 조치: 해당 VM에서 작업을 시작하지 말고 배포 담당자와 지원팀에 알립니다. 기존 사용자의 파일을 고객이 직접 지워서 이미지를 승인 상태로 만들지 마십시오.

8. 변경·복구·지원 요청

1. 런타임, 모델, 네트워크, 고객·설치 범위를 바꾸면 기존 바인딩을 전제로 작업하지 말고 새 관찰 → Core 검증 → 새 바인딩 → 필요한 Work 재확인 순서로 확인합니다. 범위 밖 변경은 관리자 승인 절차를 거칩니다.
2. 실패가 반복되면 같은 명령을 무한 재시도하지 마십시오. 최초 오류, 해당 릴리스의 지원 절차, 변경 직전 상태를 기록합니다. 복구는 릴리스가 제공한 경로에서만 수행하고, 제품 내부 상태·키·영수증을 직접 수정하지 않습니다.
3. 지원 요청에는 릴리스와 구성요소 버전, 운영체제, 단계, 화면의 상태·거부 코드, 발생 시각과 시간대, 재현 순서, 수행한 안전한 조치, 영향 범위를 포함합니다. 고객 데이터·원문 프롬프트·비밀번호·비밀키·passkey 응답·전체 로그는 보내지 말고 지원팀이 지정한 최소 공개 경로를 따릅니다.
4. 긴급 중지: 서명·호스트 신원 불일치, 다른 고객/설치 ID, 권한 확대 의심, 이전 사용자 흔적, 상태 무결성 경고가 있으면 설치나 Work를 멈추고 지원팀에 첫 증거를 전달합니다.

설치 기록과 지원 자료

설치 담당자는 릴리스 ID, 이미지 ID, 실제로 설치한 플랫폼별 파일명과 지문, 지원 환경 확인 결과, 최초 관리자 범위, 인증된 연결 상태와 현재 런타임 바인딩을 기록하십시오. Work를 실행했다면 같은 설치·Work ID에 연결된 최종 상태, 결과 검증과 영수증 위치도 남깁니다.

macOS·Windows·Linux 클라이언트와 헤드리스 경로는 각각 별도로 확인하십시오. 한 플랫폼에서 연결됐더라도 다른 플랫폼의 설치·인증·권한을 확인해야 합니다. 화면과 명령이 이 안내서의 예시와 다르면 전달된 릴리스별 지침을 따르고, 제품의 실제 메시지와 수행한 단계를 지원 요청에 적으십시오. 고객 데이터와 비밀값은 제외합니다.

온라인·폐쇄망 환경과 구성요소별 작업 지도

온라인 환경은 승인된 네트워크·제공자 경로를 사용하는 구성이고, 폐쇄형 온프렘은 필요한 설치 자산·모델·문서 등을 사전에 반입하는 구성입니다. 어느 쪽도 이 안내서가 제품의 기본값으로 고정하지 않습니다. SDK의 선택 Rust 의존성 세트는 SDK 어댑터 빌드의 Rust 범위를 준비하며 어플라이언스 이미지·모델 가중치·제공자 자격 증명·모든 OS 개발 도구를 대신하지 않습니다.

운영 변경 뒤 확인할 것

클라이언트 업데이트는 해당 클라이언트의 연결·인증·설치 신원을, 런타임 변경은 새 관찰·검증·바인딩을, Pack 변경은 정확한 버전·신뢰·현재 사용 권한·사전 조건을 다시 확인합니다. 변경 전 기록과 복구 대상은 보존합니다. 문제가 생기면 처음 달라진 관찰을 기록하고 그 구성요소의 절차로 돌아갑니다.

추가 Pack은 제공된 릴리스·고객·설치 범위에 맞는 파일과 등록 절차를 사용합니다. 임의 폴더 복사나 후보 파일명 변경으로 등록·승인을 대신하지 않습니다. 처음 적용할 때도 승인된 계획과 후조건 검증·영수증을 확인합니다. 제거·되돌림은 해당 Pack이 선언한 복구 절차와 현재 권한을 따릅니다.

처음 막혔을 때: 마지막 성공 단계부터 찾기

같은 증상이라도 실패한 단계가 다르면 조치가 달라집니다. 먼저 아래 표에서 마지막으로 직접 확인한 단계를 고릅니다. 한 번 실패한 전체 설치를 처음부터 반복하거나 기존 결과를 삭제할 필요는 없습니다.

지원 요청을 실제로 작성하는 예

다음은 작성 양식입니다. 대괄호를 실제 관찰로 바꾸고, 모르는 값은 미확인이라고 적습니다. 제품이 반환하지 않은 오류 코드·성공 시각을 만들지 않습니다.

목적: [예: SDK Custom 합성 후보 처음 생성]
OS/CPU와 도구 버전: [실제 조회값]
선택 경로: [기존 툴체인 run / 선택 세트 run-offline / GUI 등]
마지막 성공: [예: analyze까지 실제 확인]
실패 단계/시각: [실제 단계, 현지 시간과 시간대]
관찰: [원문 status/reason 또는 OS 오류; 비밀값 제거]
입력/패키지 참조: [버전과 SHA-256; 고객 내용 제외]
기존 결과: [있음/없음, 새 시도와 구분]
다음 확인 요청: [예: 승인된 네이티브 전제 조건 확인]

원본 전체 로그·고객 응답·키·토큰·프로필 원문을 일괄 전송하지 않습니다. 공유 전 민감 정보를 제거한 최소 메시지·식별자만 조직의 지원 경로로 보냅니다. 문제가 해결된 뒤에는 처음 실패했던 단계와 그 영향을 받은 결과를 다시 확인하고 다음 단계로 돌아갑니다.

먼저 현재 단계를 정하십시오

문제를 “설치가 안 된다” 한 문장으로 묶지 마십시오. 가장 마지막으로 확인된 상태를 먼저 적으면 잘못된 재설치나 권한 변경을 줄일 수 있습니다.

실제 상황을 적는 짧은 예

“릴리스 [ID]의 새 VM을 배포했습니다. VM은 실행 중이고 제품은 아직 준비되지 않았습니다. 관리자 등록과 Work는 시작하지 않았습니다. 처음 보인 메시지는 [원문]이며 시각은 [시간대 포함]입니다.” 이 경우에는 A부터 확인합니다. 클라이언트 연결 오류가 동시에 보이더라도 제품 준비가 증명되기 전에는 C의 인증 설정을 바꾸지 않습니다.

반대로 제품 준비와 네트워크 도달성은 확인됐는데 로그인만 거부되면 C에서 인증을 봅니다. 바인딩 화면만 있고 Work 영수증이 없다면 I로 갑니다. 이 순서가 원인을 확정해 주지는 않지만, 아직 증명되지 않은 다음 단계를 성공으로 표시하지 않게 합니다.

즉시 멈춰야 하는 경우

서명·파일 지문 불일치, 예상 밖 호스트 신원, 다른 고객·설치 ID, 권한 확대 의심, 이전 사용자 데이터, 상태 무결성 경고가 있으면 다음 조치를 직접 실행하지 말고 해당 사례의 지원 자료만 최소한으로 모읍니다. 암호, 토큰, 개인키, passkey 응답, 고객 데이터, 전체 로그는 일반 지원 요청에 넣지 않습니다.

증상에서 다음 절차를 선택하기

온라인 환경은 승인된 네트워크·제공자 경로를 사용하는 구성이고, 폐쇄형 온프렘은 필요한 설치 자산·모델·문서 등을 사전에 반입하는 구성입니다. 어느 쪽도 이 안내서가 제품의 기본값으로 고정하지 않습니다. SDK의 선택 Rust 의존성 세트는 SDK 어댑터 빌드의 Rust 범위를 준비하며 어플라이언스 이미지·모델 가중치·제공자 자격 증명·모든 OS 개발 도구를 대신하지 않습니다.

지원 인계 양식의 예: 릴리스·구성요소·OS, 시각과 시각대, 마지막 확인 단계, 최초 거부 원문, 수행한 변경, 현재 결과, 다음 담당자. 미확인·거부·대기·실패·완료를 같은 상태로 합치지 않습니다. 비밀값과 고객 내용은 첨부하지 않습니다.

상세 예시 30개에서 가장 가까운 상황 찾기

하나의 큰 문제 유형 안에서도 증상과 조치가 다릅니다. 아래 링크의 세부 예시 ID를 찾아 상황·관찰·조치·복귀 조건을 순서대로 읽으십시오. 예시는 교육용이며 실제 장애 이력은 별도 근거가 있어야 합니다.

SDK·Builder·GAPE·Integration Helper·소스 Document의 개별 오류는 각 설치 후 도구 안내에 추가한 상세 예시도 함께 확인하십시오. 한 도구의 준비 성공을 다른 도구나 실제 Work의 성공으로 복사하지 않습니다.

설치·첫 사용 매뉴얼로 돌아가기

상황별 시작점

읽는 방법

각 용례는 상황 → 선행 조건 → 실제 진행 순서 → 실패 분기 → 완료 증거로 구성했습니다. 여러 증상이 동시에 보이면 마지막으로 확인된 상태부터 선택하십시오. 오류 해결은 사례 색인에서 증상별로 찾을 수 있습니다. 지원 요청에는 오류 원문과 릴리스·설치 신원처럼 최소 정보만 넣고 고객 데이터·비밀값은 제외하십시오.

담당자와 산출물로 용례를 선택하기

온라인 환경은 승인된 네트워크·제공자 경로를 사용하는 구성이고, 폐쇄형 온프렘은 필요한 설치 자산·모델·문서 등을 사전에 반입하는 구성입니다. 어느 쪽도 이 안내서가 제품의 기본값으로 고정하지 않습니다. SDK의 선택 Rust 의존성 세트는 SDK 어댑터 빌드의 Rust 범위를 준비하며 어플라이언스 이미지·모델 가중치·제공자 자격 증명·모든 OS 개발 도구를 대신하지 않습니다.

지원 인계 양식의 예: 릴리스·구성요소·OS, 시각과 시각대, 마지막 확인 단계, 최초 거부 원문, 수행한 변경, 현재 결과, 다음 담당자. 미확인·거부·대기·실패·완료를 같은 상태로 합치지 않습니다. 비밀값과 고객 내용은 첨부하지 않습니다.

설치·첫 사용 매뉴얼로 돌아가기

처음 사용하는 도구: 첫 결과까지의 체크리스트

아래 각 도구 안내서의 첫 실습부터 읽으십시오. 명령줄 도구는 받은 실행 파일의 절대 경로를 지정하므로 전역 PATH 등록이 필수는 아닙니다. GUI 앱은 제공된 설치 방법으로 열고 릴리스별 화면 이름을 사용합니다. 없는 메뉴나 다운로드 주소를 추측하지 않습니다.

SDK의 선택 Rust 세트는 다른 앱의 설치 프로그램이 아닙니다. 모든 도구에 Rust 설치를 요구하지 않습니다. 기존 구성의 연결을 확인하는 사람은 새 VM 생성·초기 관리자 등록을 반복하지 않습니다.

전체 구성이 연결되는 방식

이 그림은 고객이 환경과 운영을 소유하고, 연동 도구가 이해·준비·선언을 도우며, 제품이 실행을 통제하는 관계를 보여줍니다. 이미지를 별도 탭으로 열면 확대할 수 있습니다. 실제로 설치할 수 있는 도구와 지원 버전은 전달받은 구성요소 목록에서 확인하십시오.

필요한 도구 확인

필요한 도구를 아래 표에서 고르십시오. 로컬 SDK·문서 준비만 할 때는 어플라이언스 설치가 선행 조건이 아닙니다. 각 구성요소의 제공 여부, 플랫폼, 버전과 설치 파일은 함께 전달된 목록을 기준으로 확인합니다. 목록에 없는 도구는 다른 릴리스의 파일로 대체하지 마십시오.

다음 작업 선택

설치 세트에 필요한 구성

Non-SI 설치 세트에서는 고객이 Start_Setup.html에서 이 안내서까지 온라인 환경과 오프라인 환경 모두에서 이동하고, 어플라이언스·고객 워크스테이션 플랫폼·Builder·GAPE·Integration Helper·SDK 인터페이스 또는 Engine·Contract & Document 템플릿의 정확한 설치 구성요소를 확인할 수 있어야 합니다. 하나의 버전 세트 안에 플랫폼별 설치 파일을 분리해 제공할 수 있지만, 각 항목의 지문·호환성·선행 조건·설치 담당자를 표시해야 합니다. 해당 릴리스에서 제공되지 않는 항목은 그 사실과 대체 절차를 분명히 안내합니다. 문서 링크나 과거 구현만으로 설치 가능한 제품을 대신하지 않습니다.

SDK Engine은 고객의 연동 작업대에 별도로 설치합니다. 해당 운영체제용 설치 파일, 지원 어플라이언스 버전과 설치·제거 방법은 SDK Engine 안내서와 전달 목록에서 확인하십시오.

받은 파일이 목록과 다르거나 서명 검증이 실패하면 설치를 멈추고 공급자의 지원 경로에 문의하십시오. 플랫폼별 목록에 있는 검증된 파일만 설치합니다.

권장 순서

1. 어플라이언스에 연결하는 작업이라면 설치·첫 사용을 인증된 클라이언트 연결과 검증된 런타임 바인딩까지 진행하십시오. 로컬 SDK 합성 예제·Document 준비는 해당 도구의 첫 실습에서 바로 시작합니다. 도구를 열기 전에 정확한 릴리스 구성요소 목록을 확인합니다.
2. 특정 리비전의 아키텍처 확인이 필요하면 GAPE 관찰 결과와 한계를 검토합니다. 도표를 승인으로 해석하지 않습니다.
3. Document로 작업을 설명하고 공급자가 게시한 정확한 Contract·어댑터 참조를 확보합니다. Integration Helper로 지원되는 입력 범위의 후보를 검사·준비합니다.
4. 해당 릴리스가 이 대상의 SDK 인터페이스나 Engine을 제공하면 게시 리비전을 확인하고 지정된 검증·패키징 절차를 따릅니다. 릴리스 목록에 없다면 이 경로에서 멈춥니다. 인포그래픽이나 이전 SDK 산출물만 보고 현재 제공 기능으로 간주하지 않습니다.
5. 기존 지원 Pack으로 해결할 수 없으면 Builder에서 후보를 준비합니다. 후보 검증·승인·사용 권한·Work 실행을 별도 단계로 기록합니다.
6. 실제 작업은 첫 Work 안내서에 따라 진행하고 최종 영수증을 확인합니다. 준비 산출물은 영수증을 대신하지 않습니다.

공통 지원 요청 기록

릴리스·구성요소 버전, 고객·설치 신원, 입력 리비전 또는 후보 ID, 표시된 상태·사유, 마지막으로 증명된 단계와 다음 조치를 기록하십시오. 개인키·자격 증명·고객 내용·원문 프롬프트·내부 엔지니어링 내보내기는 제외합니다. 신원·서명·권한·상태 무결성이 다르면 중지합니다.

온라인·폐쇄망 환경과 구성요소별 작업 지도

온라인 환경은 승인된 네트워크·제공자 경로를 사용하는 구성이고, 폐쇄형 온프렘은 필요한 설치 자산·모델·문서 등을 사전에 반입하는 구성입니다. 어느 쪽도 이 안내서가 제품의 기본값으로 고정하지 않습니다. SDK의 선택 Rust 의존성 세트는 SDK 어댑터 빌드의 Rust 범위를 준비하며 어플라이언스 이미지·모델 가중치·제공자 자격 증명·모든 OS 개발 도구를 대신하지 않습니다.

운영 변경 뒤 확인할 것

클라이언트 업데이트는 해당 클라이언트의 연결·인증·설치 신원을, 런타임 변경은 새 관찰·검증·바인딩을, Pack 변경은 정확한 버전·신뢰·현재 사용 권한·사전 조건을 다시 확인합니다. 변경 전 기록과 복구 대상은 보존합니다. 문제가 생기면 처음 달라진 관찰을 기록하고 그 구성요소의 절차로 돌아갑니다.

추가 Pack은 제공된 릴리스·고객·설치 범위에 맞는 파일과 등록 절차를 사용합니다. 임의 폴더 복사나 후보 파일명 변경으로 등록·승인을 대신하지 않습니다. 처음 적용할 때도 승인된 계획과 후조건 검증·영수증을 확인합니다. 제거·되돌림은 해당 Pack이 선언한 복구 절차와 현재 권한을 따릅니다.

설치·첫 사용 안내서로 돌아가기

왜 이 사례가 중요한가

클라우드 콘솔에는 VM이 실행 중으로 보여도 어플라이언스는 아직 초기화 중일 수 있습니다. 클라이언트를 연결하거나 Work를 시작하기 전에 설정 화면에서 제품 준비 상태를 확인하십시오.

예시 상황

새 어플라이언스를 만들었고 클라우드 콘솔은 실행 중입니다. 그러나 PackrGUI 연결은 거부되고 제품 상태는 초기화 중 또는 서비스 준비 안 됨입니다. 이때 클라우드 상태와 제품 상태를 별도로 기록합니다.

확인 순서

1. 받은 이미지의 릴리스 ID와 인스턴스가 새 배포인지 확인합니다. 이전 시험 VM이나 다른 릴리스 이미지라면 여기서 멈춥니다.
2. 릴리스 문서에 적힌 첫 부팅 완료 기준과 정상 대기 시간을 확인합니다. 문서에 없는 임의 시간을 성공 기준으로 만들지 않습니다.
3. 클라우드의 VM 실행 상태와 제품의 서비스 준비 상태를 각각 확인합니다. 프로세스가 실행되더라도 제품 준비 상태가 없으면 다음 단계로 가지 않습니다.
4. 릴리스가 제공한 읽기 전용 진단에서 첫 부팅 단계, 필수 구성요소, 서비스 거부 사유를 확인합니다. 제품 명령이나 로그 위치는 릴리스 문서의 정확한 값만 사용합니다.
5. 같은 시각의 네트워크 오류가 있더라도, 서비스 준비가 증명되기 전에는 네트워크를 원인으로 단정하지 않습니다.

이번 릴리스가 packrctl과 정식 로컬 운영 경로를 제공한다면 아래 읽기 전용 명령으로 VM 전원과 제품 준비를 구분해 확인할 수 있습니다. 반환된 준비 상태와 사유를 읽으십시오. health의 0이 아닌 종료 상태는 UNKNOWN이나 NOT_READY일 수 있으며 무작정 VM을 재시작하라는 뜻이 아닙니다.

packrctl status --json
packrctl health --json

결과별 다음 조치

현장 판단 예시: 전원만 켜진 첫 부팅

운영자가 10:00에 새 VM을 만들고 10:02에 콘솔의 실행 중을 확인했지만, 제품 상태가 계속 초기화 중이라고 가정합니다. 이 기록으로 말할 수 있는 것은 VM 전원 상태뿐입니다. 서비스 준비, 관리자 등록 가능, 클라이언트 접속 가능은 각각 아직 확인되지 않았습니다. 이미지 ID와 첫 부팅 시각을 적고 릴리스가 지정한 대기·상태 확인을 한 번 수행합니다. 준비 거부가 지속되면 고객이 게스트 패키지나 초기화 파일을 직접 고치지 않고 지원팀으로 넘깁니다.

지원 요청 예시

“릴리스 ID [값], 인스턴스 생성 시각 [시간대 포함], VM 상태 [실행 중], 제품 상태 [화면에 보인 그대로], 첫 부팅 단계 [값], 최초 오류 [원문]입니다. 고객 Work는 시작하지 않았습니다.”

고객 데이터나 전체 시스템 로그 대신, 릴리스가 지정한 최소 상태 출력만 전달합니다.

완료·중지 기준

완료: 제품이 이 설치 신원에 대해 서비스 준비를 표시합니다. 중지: 초기화 누락, 상태 무결성 경고, 릴리스 불일치, 반복되는 준비 실패가 있으면 복구 파일 삭제·재설치·서비스 강제 시작을 하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 A-1: VM은 실행 중인데 첫 부팅은 진행 중

상황: 설치 담당자는 새 VM의 전원 상태를 확인한 직후 GUI를 엽니다. GUI는 연결 시간 초과를 보이고 제품의 첫 부팅 화면은 아직 초기화 중입니다. 계정이 틀렸다고 판단하기 전에 제품 준비 상태를 따로 확인해야 하는 상황입니다.

관찰을 이렇게 나눠 읽습니다.

• VM: 실행 중. 이 관찰은 전원 상태만 확인합니다.
• 제품: 초기화 진행 중. 준비 완료 시각은 아직 없습니다.
• GUI: 시간 초과. 제품이 준비되기 전이므로 인증 실패 원인으로 확정할 수 없습니다.

확인·조치 순서:

1. 같은 인스턴스의 이미지·생성 기록을 확인하고, 릴리스가 정한 첫 부팅 완료 표시와 정상 대기 기준을 찾습니다.
2. 정상 초기화가 계속 진행되는지 제품 상태에서 확인합니다. 준비 상태가 없는데 계정 재등록·클라이언트 재설치로 넘어가지 않습니다.
3. 준비 완료가 관찰된 뒤 그 설치 신원을 기록하고 원래 GUI 연결을 다시 확인합니다.

다음 단계로 돌아갈 조건: 동일한 새 설치가 준비 상태를 보이고 신원이 맞으면 관리자 설정으로 진행합니다. GUI 접속은 별도로 확인합니다.

해결되지 않았을 때: 공식 대기 기준을 넘기거나 진행 상태가 멈추면 첫 오류와 마지막 갱신 시각을 보존하여 이미지·배포 담당자에게 인계합니다.

상세 예시 A-2: 프로세스는 있지만 필수 초기화가 실패함

상황: 관리 화면에서 서비스 프로세스는 실행 중인데 제품 건강도는 준비되지 않음으로 표시됩니다. 첫 오류에는 필수 초기화 구성요소 또는 설정을 사용할 수 없다는 설명이 있습니다. 프로세스를 강제로 다시 시작하면 될 것처럼 보이지만 이미지와 제품 준비를 먼저 대조합니다.

관찰을 이렇게 나눠 읽습니다.

• 프로세스 시작: 확인됨. 초기화 성공은 별개입니다.
• 건강도: 준비 안 됨. 정확한 사유와 조회 시각을 기록합니다.
• 파일 목록: 전달된 이미지와 실제 이미지가 같은지 아직 대조가 필요합니다.

확인·조치 순서:

1. 전달 목록의 이미지·릴리스와 현재 인스턴스의 출처를 대조합니다. 다른 버전의 설명서와 오류를 비교하지 않습니다.
2. 제공된 읽기 전용 status·health 결과에서 최초 초기화 거부와 그 이후 상태를 구분합니다.
3. 누락 자산이 확인되면 공급자의 해당 이미지 수정·교체 절차로 인계합니다. 고객 VM에서 임의 패키지를 추가하지 않습니다.

다음 단계로 돌아갈 조건: 지원 절차 적용 뒤 현재 이미지·설치 신원과 제품 준비 결과를 다시 대조합니다. 서비스 프로세스만 다시 뜬 상태는 종료 기준이 아닙니다.

해결되지 않았을 때: 초기화 원인이 확인되지 않았거나 이미지가 다른 경우 후속 등록·Work를 보류하고 최소 오류·이미지 신원을 인계합니다.

상세 예시 A-3: 어제의 준비 화면은 정상인데 오늘 연결은 실패함

상황: 사용자는 이전에 저장한 준비 완료 화면을 근거로 서버는 정상이라고 생각합니다. 그 뒤 유지보수나 재부팅이 있었고 오늘의 제품 상태는 아직 읽지 않았습니다. 과거 성공과 현재 관찰을 나누어 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• 이전 화면: 변경 이전 시각입니다. 현재 상태의 증거로 사용하지 않습니다.
• 변경 기록: 재부팅·업데이트 시각 중 알려진 항목만 적습니다.
• 현재 상태: 확인 전입니다. 아직 네트워크 장애라고 확정하지 않습니다.

확인·조치 순서:

1. 현재 대상이 이전과 같은 인스턴스인지 확인합니다. 교체됐다면 사례 B·J의 신원 확인도 적용합니다.
2. 변경 이후의 제품 status·health와 최초 오류를 읽습니다. 준비가 확인되면 그 뒤 도달성·인증을 사례 C로 나눕니다.
3. 수정 전후 상태와 변경한 항목을 한 기록에 묶고 영향을 받은 단계만 재확인합니다.

다음 단계로 돌아갈 조건: 현재 준비·신원·클라이언트 인증이 각각 확인되면 그 범위만 복구 완료로 기록합니다.

해결되지 않았을 때: 현재 상태를 조회할 수 없으면 과거 화면으로 빈칸을 채우지 말고 미확인 단계와 관리 경로 장애를 인계합니다.

이 사례의 지원 기록을 실제로 채우기

이미지·인스턴스 출처, 생성 시각, 현재 status·health, 초기화 단계, 첫 거부와 마지막 갱신 시각.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: A-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

왜 이 사례가 중요한가

인스턴스를 교체하거나 설정을 바꾸면 호스트 키가 달라질 수 있습니다. 경고는 목적지의 신원이 아직 확인되지 않았다는 뜻이므로 검사를 끄고 재접속하지 마십시오.

예시 상황

어제 접속한 주소로 다시 연결했는데 SSH 또는 앱이 서버 신원이 변경됨을 알립니다. 사용자는 같은 VM이라고 생각하지만 실제로는 새 인스턴스, 재생성된 키, 잘못된 주소, 또는 확인되지 않은 다른 호스트일 수 있습니다.

확인 순서

1. 연결을 중단하고 경고의 발생 시각, 접속 주소, 표시된 신원 정보를 기록합니다. 비밀키나 자격 증명은 기록에 넣지 않습니다.
2. 릴리스가 허용한 관리 콘솔에서 대상 인스턴스의 이름·설치 ID·생성 또는 재시작 이력을 확인합니다. 주소만 같다는 이유로 동일 호스트라 판단하지 않습니다.
3. 제품 또는 클라우드의 독립적인 인증 경로가 제공하는 현재 호스트 신원을 대조합니다. 접속 경고가 난 바로 그 채널에서 받은 값만으로 그 채널을 신뢰하지 않습니다.
4. 두 값이 일치하고 릴리스가 신뢰 갱신 절차를 명시한 경우에만 그 절차를 사용합니다. 신뢰 갱신 권한이 없다면 관리자·지원팀에 넘깁니다.
5. 연결 후에도 고객·설치 신원이 예상한 값인지 확인합니다. 호스트 키 확인은 제품 권한 확인을 대신하지 않습니다.

결과별 다음 조치

현장 판단 예시: 같은 주소에서 공개키 경고

주소는 그대로인데 접속 도구가 다른 호스트키를 표시했다고 가정합니다. 새 인스턴스가 같은 주소를 재사용했을 수도 있고, 원래 인스턴스에서 키가 다시 생성됐을 수도 있습니다. 경고 메시지만으로 어느 쪽인지 확정할 수 없습니다. 접속을 멈춘 상태에서 관리 콘솔의 인스턴스·디스크 신원과 릴리스가 제공하는 독립 인증 경로의 현재 키를 대조합니다. 둘 중 하나라도 확인되지 않으면 저장된 신뢰 항목을 지우거나 교체하지 않습니다.

지원 요청 예시

“릴리스 ID [값], 예상 설치 ID [값], 접속 대상 [공식 별칭], 경고 시각 [시간대 포함], 경고 유형 [원문], 인스턴스 교체 여부 [확인 결과]입니다. 경고 뒤 연결은 진행하지 않았습니다.”

완료·중지 기준

완료: 현재 호스트 신원, 설치 신원, 공식 접속 대상이 독립 증거와 일치합니다. 중지: 신원 차이가 해소되지 않으면 호스트 검사 해제, 경고 무시, 저장된 키 임의 삭제·교체를 하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 B-1: VM 교체 후 같은 주소에서 호스트 키 경고

상황: 운영자가 VM을 교체했고 클라이언트는 어제와 같은 주소로 접속합니다. 경고에는 서버 키가 달라졌다고 표시됩니다. 주소 재사용은 가능한 설명이지만 접속 채널의 현재 신원이 검증된 것은 아닙니다.

관찰을 이렇게 나눠 읽습니다.

• 주소: 이전과 같음. 인스턴스 동일성을 뜻하지 않습니다.
• 관리 콘솔: 인스턴스 교체 기록을 별도로 확인합니다.
• 호스트 지문: 경고 채널의 값과 독립 경로의 값을 구분합니다.

확인·조치 순서:

1. 연결을 중단한 채 승인된 콘솔에서 현재 인스턴스·디스크·이미지 신원을 확인합니다.
2. 릴리스의 독립 인증 경로에서 현재 공개키 지문을 얻어 경고의 값과 대조합니다.
3. 정확히 일치하고 신뢰 갱신 권한이 있는 담당자가 제공된 갱신 절차를 적용한 뒤 제품 설치 신원을 확인합니다.

다음 단계로 돌아갈 조건: 현재 호스트와 제품 설치 신원이 모두 예상 값과 일치해야 접속 단계로 돌아갑니다.

해결되지 않았을 때: 독립 지문이 없거나 불일치하면 신뢰 기록 삭제·검사 해제 없이 보류하고 신원 담당자에게 인계합니다.

상세 예시 B-2: 잘못 저장된 접속 대상과 올바른 서버를 구별하기

상황: 북마크나 클라이언트 프로필의 별칭은 맞아 보이는데 연결된 제품은 예상 설치가 아닙니다. 서버 키가 유효하더라도 원래 작업 대상이 잘못 선택됐을 수 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 프로필 별칭: 사람이 붙인 이름입니다. 실제 대상 신원과 별도로 기록합니다.
• 호스트 신원: 유효해도 다른 승인 서버일 수 있습니다.
• 고객·설치 표시: 예상 값과 다르면 현재 세션을 작업에 사용하지 않습니다.

확인·조치 순서:

1. 릴리스가 지정한 실제 엔드포인트와 저장 프로필의 주소·포트를 대조합니다.
2. 현재 제품의 고객·설치 신원을 독립 설치 기록과 대조합니다. 다른 고객 내용을 열어 확인하지 않습니다.
3. 승인된 클라이언트 설정 화면에서 올바른 프로필을 선택하고 새 세션의 신원·범위를 다시 확인합니다.

다음 단계로 돌아갈 조건: 올바른 대상에 인증됐다는 현재 기록을 확인하면 원래 절차를 계속합니다.

해결되지 않았을 때: 공식 엔드포인트와 설치 신원이 연결되지 않으면 접근을 중단하고 주소·신원 담당자가 확인합니다.

상세 예시 B-3: 같은 인스턴스라고 하는데 키가 다시 바뀜

상황: 정당한 키 갱신을 한 번 확인했는데 이후 같은 인스턴스에서 다시 경고가 납니다. 재부팅이나 설정 변경이 있었다는 설명만으로 반복 갱신을 승인하지 않습니다.

관찰을 이렇게 나눠 읽습니다.

• 키 변경: 두 관찰 사이에 다시 발생했습니다. 변경 이력을 구분합니다.
• 인스턴스: 같다는 설명과 실제 콘솔 ID를 대조합니다.
• 현재 키: 이전 검증값과 다르면 다시 미확인 상태입니다.

확인·조치 순서:

1. 첫 키 갱신의 근거와 이후 경고 시각·대상을 보존합니다.
2. 승인된 변경 기록과 독립 경로의 현재 신원을 담당자가 대조합니다.
3. 원인이 확인되고 현재 값이 검증되기 전에는 접속을 반복하지 않습니다.

다음 단계로 돌아갈 조건: 담당자가 현재 호스트·설치와 변경 이력을 확인한 뒤 지정한 접속 경로만 재확인합니다.

해결되지 않았을 때: 원인 미확인의 반복 키 변경은 사용자 설정 정리로 처리하지 않고 신원 문제로 인계합니다.

이 사례의 지원 기록을 실제로 채우기

예상 대상 별칭, 경고 시각, 인스턴스 교체 여부, 독립 호스트 지문 확인 여부, 제품 설치 신원 일치 여부.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: B-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

왜 이 사례가 중요한가

시간 초과와 로그인 거부는 확인할 지점이 다릅니다. 시간 초과는 네트워크나 서비스 준비 상태를, 서버에 도달한 뒤의 거부는 인증이나 접근 범위를 먼저 확인하십시오.

예시 상황

PackrGUI가 연결을 못 합니다. 한 번은 연결 시간 초과, 다음에는 로그인 거부가 보입니다. 앞의 오류는 도달성 또는 준비 상태이고, 뒤의 오류는 인증 또는 신원 범위일 수 있습니다. 두 메시지를 별개로 기록합니다.

확인 순서

1. 현재 어플라이언스의 릴리스 ID와 설치 ID가 맞는지 확인합니다.
2. VM 실행과 제품 서비스 준비를 구분합니다. 제품이 준비되지 않았다면 사례 A부터 해결합니다.
3. 릴리스의 공식 주소·네트워크 경로와 고객 방화벽 정책을 확인합니다. 다른 포트나 공개 인터넷 경로를 임의로 열지 않습니다.
4. 도달성이 확인된 뒤에만 현재 계정, 릴리스가 지정한 로그인 방식, 계정의 고객·설치 범위를 확인합니다.
5. 인증이 성공해도 제품 화면에서 고객·설치 신원과 허용 기능을 확인합니다. 로그인 성공은 런타임 바인딩 또는 Work 권한이 아닙니다.

메시지에 따른 분기

재검증과 지원 자료

문제가 해결되면 서비스 준비 → 도달성 → 인증 → 제품 설치 신원을 다시 순서대로 확인합니다. 지원 요청에는 첫 오류와 이후 오류를 각각 원문·시각으로 적고, 접속 대상은 공개 가능한 공식 별칭으로만 적습니다. 암호, 토큰, 개인키를 보내지 않습니다.

완료·중지 기준

완료: 인증된 클라이언트가 예상 고객·설치 신원을 보여 줍니다. 중지: 신원 불일치나 인증 경로 미확인은 다른 계정·키를 빌리거나 호스트 검사를 끄는 방식으로 넘기지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 C-1: 접속 시간 초과와 서비스 미준비를 분리하기

상황: 같은 사용자 계정으로 어제는 접속됐지만 오늘은 응답이 없습니다. 로그인 화면조차 나오지 않았습니다. 이때 암호 오류를 가정하기보다 서버 준비와 승인된 경로를 순서대로 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• 클라이언트: 시간 초과이며 인증 응답은 받지 못했습니다.
• 서버 준비: 현재 결과를 확인해야 합니다.
• 주소·포트: 릴리스의 값과 비교 전에는 올바르다고 가정하지 않습니다.

확인·조치 순서:

1. 사례 A에서 현재 서비스 준비를 확인합니다. 미준비면 먼저 그 단계를 해결합니다.
2. 저장된 엔드포인트와 조직이 승인한 DNS·방화벽·접속 경로가 같은지 담당자가 확인합니다. 임의 포트를 열지 않습니다.
3. 도달성이 회복된 뒤 인증 결과와 고객·설치 신원을 별도로 확인합니다.

다음 단계로 돌아갈 조건: 같은 승인 경로로 응답·인증·신원이 확인돼야 연결 복구로 기록합니다.

해결되지 않았을 때: 어느 경로에서 멈추는지 확인할 수 없으면 마지막 도달 지점과 시간 초과를 네트워크 담당자에게 인계합니다.

상세 예시 C-2: 서버는 응답하지만 세션이 만료됨

상황: GUI에서 서버 신원은 확인되지만 로그인 거부가 나오고 헤드리스 조회도 현재 계정에서는 거부됩니다. 네트워크가 응답했다는 사실과 세션이 유효하다는 사실을 분리합니다.

관찰을 이렇게 나눠 읽습니다.

• 서버 응답: 있음. 단순 도달성 문제와 구별합니다.
• 세션: 만료 또는 미인증이라는 실제 표시를 원문대로 기록합니다.
• 다른 경로: GUI와 헤드리스의 계정·세션이 같다고 가정하지 않습니다.

확인·조치 순서:

1. 현재 릴리스의 로그인 방식과 계정·유효기간을 확인합니다.
2. 허용된 현재 계정으로 정식 재인증하고 반환된 고객·설치 범위를 확인합니다.
3. GUI와 헤드리스에서 필요한 각 경로를 따로 조회합니다. 사용자 토큰을 서비스에 복사하지 않습니다.

다음 단계로 돌아갈 조건: 사용할 경로의 현재 세션이 인증됐고 올바른 설치를 보여 주면 그 경로의 연결 단계가 끝납니다.

해결되지 않았을 때: 재인증해도 권한 거부가 지속되면 계정 담당자에게 정확한 범위·사유를 인계합니다. 암호·토큰은 보내지 않습니다.

상세 예시 C-3: GUI는 되는데 자동화 서비스만 접속 실패

상황: 워크스테이션 GUI는 정상인데 서버의 정기 작업은 접속 거부를 받습니다. GUI 화면을 성공 증거로 복사하지 않고 서비스의 실행 위치와 신원으로 조회합니다.

관찰을 이렇게 나눠 읽습니다.

• GUI: 현재 사용자 세션의 성공입니다.
• 자동화: 별도 계정·네트워크·허용 범위를 사용할 수 있습니다.
• 실패: 시간 초과인지 인증 거부인지 원문으로 나눕니다.

확인·조치 순서:

1. 해당 릴리스가 헤드리스 경로와 서비스 인증 절차를 제공하는지 확인합니다.
2. 서비스의 공식 접속 주소, 실행 계정, 세션 상태와 고객·설치 범위를 각각 기록합니다.
3. 담당자가 실패한 경로를 조정한 뒤 동일 서비스 신원으로 읽기 전용 상태를 재확인합니다.

다음 단계로 돌아갈 조건: GUI 성공과 별도로 헤드리스의 인증·신원·허용 기능을 확인한 경우에만 해당 자동화 경로가 준비됐다고 기록합니다.

해결되지 않았을 때: 서비스 인증이 제공되지 않거나 범위 승인이 없으면 사용자 자격 증명 복사로 대체하지 말고 미제공·미승인으로 인계합니다.

이 사례의 지원 기록을 실제로 채우기

사용 경로, 현재 서버 준비, 시간 초과·신원·인증 중 실패 단계, 세션 상태, 고객·설치 범위.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: C-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

실제 관찰과 의미

관리자 등록에는 실제 대화형 확인이 필요할 수 있습니다. 스크립트나 파이프로 보낸 값은 거부될 수 있으므로, 관리자 기능을 사용하기 전에 제품의 성공 기록을 확인하십시오.

예시 상황

설치 담당자가 자동화 스크립트에서 관리자 등록을 실행했습니다. 출력에는 사용자 확인이 필요하다는 거부가 있고, 뒤이어 바인딩 위자드는 관리자 범위를 찾지 못합니다. 여기서 임의로 “등록된 것으로 간주”하면 후속 오류를 만듭니다.

확인 순서

1. 릴리스가 요구하는 등록 방식이 로컬 설정 UI인지, 실제 대화형 터미널인지 확인합니다.
2. 시도한 방식이 파이프·예약 작업·비대화형 원격 세션이었는지 확인합니다. 비밀 입력이나 확인 단어 자체는 지원 자료에 넣지 않습니다.
3. 제품의 현재 관리자 등록 상태를 읽기 전용으로 확인합니다. 성공 기록이 없다면 후속 바인딩을 시작하지 않습니다.
4. 승인된 실제 관리자가 릴리스 절차에 따라 대화형 화면에서 고객·설치·런타임 범위를 검토하고 직접 확인합니다.
5. 등록 결과의 역할, 허용 범위, 유효기간과 설치 신원을 다시 읽습니다. OS 로그인 성공과 제품 관리자 등록을 구별합니다.

예시 분기

지원 요청 예시

“릴리스 [값], 관리자 등록 단계 [값], 입력 방식 [대화형/비대화형], 제품 거부 메시지 [원문], 등록 상태 [없음/있음/확인 불가]입니다. 비밀 입력은 첨부하지 않았습니다.”

완료·중지 기준

완료: 실제 관리자의 제품 역할과 이 설치의 허용 범위가 기록되어 읽힙니다. 중지: 확인 절차를 자동 입력으로 흉내 내거나 OS 관리자 권한을 제품 권한으로 대체하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 D-1: 원격 파이프에서 관리자 확인이 거부됨

상황: 설치 스크립트에 관리자 등록 명령을 넣었더니 실제 터미널 또는 사용자 확인이 필요하다는 거부가 나옵니다. 등록 결함으로 단정하기 전에 제공된 절차의 대화형 요구를 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• 입력 경로: 파이프·비대화형 작업입니다.
• 제품 결과: 사용자 확인 요구가 충족되지 않았습니다.
• 등록 상태: 완료된 역할·범위 기록은 아직 없습니다.

확인·조치 순서:

1. 등록 문서에서 허용하는 로컬 위자드 또는 대화형 터미널 경로를 찾습니다.
2. 실제 관리자가 해당 설치·고객·런타임 범위와 유효기간을 직접 확인합니다.
3. 등록 직후 읽기 전용 상태로 역할과 범위가 기록됐는지 확인합니다.

다음 단계로 돌아갈 조건: 사용자 확인과 제품의 등록 결과가 모두 있어야 관리자 설정 완료로 기록합니다.

해결되지 않았을 때: 대화형 경로를 사용할 수 없다면 자동 입력·확인 토큰 조작 없이 해당 조건을 담당자에게 인계합니다.

상세 예시 D-2: OS 관리자로 로그인했지만 제품 관리자 역할이 없음

상황: 운영체제 관리 권한으로 로그인한 사용자가 제품 관리 화면에서도 관리자일 것으로 기대합니다. 제품은 현재 설치의 관리자 역할이 없다고 표시합니다.

관찰을 이렇게 나눠 읽습니다.

• OS 로그인: 성공했습니다.
• 제품 역할: 해당 설치에서 미등록 또는 미확인입니다.
• 설치 범위: 다른 설치의 등록 상태를 재사용할 수 없습니다.

확인·조치 순서:

1. 현재 설치 신원을 제품에서 확인하고 기존 등록 기록이 어느 설치를 대상으로 했는지 대조합니다.
2. 제공된 제품 관리자 등록 절차를 현재 설치에서 수행할 담당자를 확인합니다.
3. OS 권한 상승 대신 제품 역할·범위·유효기간이 기록됐는지 확인합니다.

다음 단계로 돌아갈 조건: 현재 설치에 대한 제품 관리자 결과가 확인된 뒤 그 범위 안의 관찰을 수행합니다.

해결되지 않았을 때: 관리자 지정 권한이 없으면 등록을 시도해 넓히지 않고 권한 담당자에게 인계합니다.

상세 예시 D-3: 등록은 끝났지만 고객·런타임 범위가 다름

상황: 등록 완료 화면을 본 뒤 런타임 연결을 시도했지만 범위 거부가 나옵니다. 실제 기록에는 의도와 다른 고객·설치 또는 제한된 런타임 범위가 들어 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 등록 완료: 역할 존재에 대한 결과입니다.
• 허용 범위: 현재 요청을 포함하는지는 별도입니다.
• 거부 결과: 정확한 대상과 사유를 보존합니다.

확인·조치 순서:

1. 현재 설치·고객·런타임 참조와 관리자 기록의 값을 나란히 대조합니다.
2. 어느 항목이 잘못됐는지 확인한 뒤 권한 있는 담당자가 정식 범위 변경을 판단합니다.
3. 변경된 범위를 읽어 확인한 뒤 영향을 받은 관찰·검증부터 다시 진행합니다.

다음 단계로 돌아갈 조건: 현재 요청이 기록된 허용 범위 안에 있고 제품이 재검증한 결과가 있어야 진행합니다.

해결되지 않았을 때: 원래 승인 범위를 확인할 수 없으면 기존 기록을 직접 편집하지 않고 보류합니다.

이 사례의 지원 기록을 실제로 채우기

등록 경로·대화형 여부, 현재 설치 신원, 실제 관리자 확인 여부, 제품 역할·범위·유효기간.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: D-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

실제 관찰과 의미

관리자 등록이 완료돼도 제품이 정책을 읽을 때 접근 거부가 나올 수 있습니다. 등록 성공과 후속 접근 성공을 따로 확인하고 표시된 거부 사유에 따라 조치하십시오.

예시 상황

관리자 등록은 성공으로 보였습니다. 그러나 런타임을 관찰하려는 순간 Permission denied 또는 저장소 접근 오류가 뜹니다. 관리자 권한을 여러 번 다시 등록하기보다 첫 오류를 보존합니다.

확인 순서

1. 제품이 보여 준 최초 오류의 시각·단계·거부 코드를 기록합니다. 재시도로 최초 오류를 덮어쓰지 않습니다.
2. 릴리스와 설치 ID가 등록 당시와 같은지 확인합니다. 다른 설치의 정책을 읽는 상황이라면 즉시 멈춥니다.
3. 제품 서비스 준비 상태와 관리자 등록 상태를 릴리스의 읽기 전용 화면에서 각각 확인합니다.
4. 저장소 접근 오류인지, 관리자 역할이 없는 것인지, 허용 범위 밖인지 메시지를 구분합니다. 세 경우의 조치는 다릅니다.
5. 해당 릴리스의 알려진 수정·지원 지침을 확인합니다. 고객이 직접 파일 소유권이나 잠금 파일을 수정하는 단계는 아닙니다.

결과별 조치

지원 자료

릴리스·설치 ID, 최초 거부 메시지, 관리자 등록 성공 여부, 서비스 준비 상태, 발생 시각을 보내십시오. 잠금 파일, 내부 데이터베이스, 관리자 정책 원본, 비밀키, 전체 로그는 첨부하지 않습니다.

완료·중지 기준

완료: 제품이 해당 관리자 상태를 읽고 허용 범위 안의 관찰을 정상 처리합니다. 중지: 재등록 반복, 파일 권한 확대, 잠금 파일 삭제, 서비스 계정 변경을 하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 E-1: 등록 성공 뒤 첫 상태 조회에서 접근 거부

상황: 관리자 등록은 완료됐지만 이후 정책·상태를 읽는 단계에서 Permission denied가 표시됩니다. 같은 등록을 반복하기 전에 최초 등록 결과와 후속 접근 오류를 따로 보존합니다.

관찰을 이렇게 나눠 읽습니다.

• 등록 결과: 존재합니다.
• 후속 조회: 접근 거부로 종료됐습니다.
• 근거: 저장소 오류인지 역할 범위인지 아직 제품 사유로 분류해야 합니다.

확인·조치 순서:

1. 두 결과의 릴리스·설치 신원이 같은지 대조합니다.
2. 제품이 준 정확한 오류 단계·사유를 보관하고 서비스 준비도 읽기 전용으로 확인합니다.
3. 정식 지원 절차에서 해당 버전의 수정 여부를 확인합니다. 파일 소유권·잠금 파일을 직접 바꾸지 않습니다.

다음 단계로 돌아갈 조건: 지원 절차 적용 후 같은 설치에서 관리자 상태를 읽고 허용 관찰이 성공하는지 확인합니다.

해결되지 않았을 때: 내부 저장소 접근이 계속 거부되면 최초 오류와 버전을 인계하고 데이터베이스 원본은 일반 티켓에 첨부하지 않습니다.

상세 예시 E-2: 조회는 되지만 범위 밖 작업만 거부됨

상황: 관리자 상태는 정상적으로 읽히지만 특정 런타임 또는 기능 요청만 거부됩니다. 모든 접근 거부를 파일 권한 문제로 묶으면 실제 범위 거부를 놓칠 수 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 관리자 조회: 정상입니다.
• 특정 요청: 현재 허용 범위 밖이라고 표시됩니다.
• 다른 작업: 성공하더라도 해당 요청의 권한을 증명하지 않습니다.

확인·조치 순서:

1. 요청의 설치·고객·기능·런타임과 관리자 허용 범위를 대조합니다.
2. 필요한 범위 변경인지 잘못 선택한 대상인지 담당자가 구별합니다.
3. 대상 또는 승인이 정식으로 바로잡힌 뒤 같은 제한된 요청을 재확인합니다.

다음 단계로 돌아갈 조건: 허용된 범위의 요청이 성공하면 그 기능까지만 복구 완료로 기록합니다.

해결되지 않았을 때: 범위 승인이 없으면 파일 권한 확대나 서비스 계정 교체로 해결하지 않습니다.

상세 예시 E-3: 업데이트 이후 처음 나타난 저장소 접근 오류

상황: 기존 환경을 업데이트한 뒤 관리자 상태 조회가 실패합니다. 예전 정상 결과는 있지만 업데이트 이후 접근 성공은 아직 없습니다. 수정된 버전·현재 신원·실패 단계를 묶어 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• 이전 버전: 조회 성공 기록이 있습니다.
• 현재 버전: 첫 조회부터 접근 오류가 있습니다.
• 설치 신원: 변경 여부를 별도로 확인해야 합니다.

확인·조치 순서:

1. 업데이트 전후 정확한 버전과 승인된 변경 기록을 확인합니다.
2. 현재 설치·서비스·관리자 상태를 제품의 허용된 읽기 전용 진단으로 확인합니다.
3. 해당 버전의 복구·롤백 안내를 담당자가 적용하도록 인계합니다. 임의 하위 버전 파일을 섞지 않습니다.

다음 단계로 돌아갈 조건: 복구한 버전·현재 설치·정상 조회가 함께 확인돼야 해당 접근 문제가 해결됐다고 기록합니다.

해결되지 않았을 때: 복구 절차가 없거나 상태 무결성 경고가 있으면 작업을 보류하고 최소 오류·변경 내역을 인계합니다.

이 사례의 지원 기록을 실제로 채우기

등록 완료 기록, 최초 접근 거부 단계·시각, 서비스 상태, 현재 역할·범위, 변경 전후 버전.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: E-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

실제 관찰과 의미

로컬 모델을 찾는 단계와 현재 설치에 바인딩하는 단계는 별개입니다. 모델 별칭이나 런타임 주소를 바꾼 뒤에는 새 바인딩 결과를 확인하고 Work에 사용하십시오.

예시 상황

관리자는 로컬 모델이 설치된 것을 확인했습니다. PackrGUI에는 런타임이 감지됨으로 보이지만 바인딩됨은 아닙니다. 전날 모델 별칭 또는 런타임 주소를 바꿨다면 과거 상태와 현재 관찰을 구별해야 합니다.

확인 순서

1. 릴리스가 지원하는 런타임 종류와 모델인지 확인합니다. 모델 파일 존재만으로 지원 여부를 결정하지 않습니다.
2. 제품 화면에서 감지 시각, 검증 상태, 바인딩 상태를 따로 읽습니다. 이전 부팅의 상태가 아닌지 확인합니다.
3. 현재 고객·설치 ID와 관리자 승인 범위가 런타임 위치·모델을 포함하는지 확인합니다.
4. 제품이 모호성이나 범위 밖을 표시하면 그 이유를 그대로 기록합니다. 여러 모델 중 어느 것을 선택할지 고객이 추측해 저장소에 기록하지 않습니다.
5. 릴리스 위자드가 제공하는 재관찰 또는 범위 승인 절차를 사용합니다. 이후 새 바인딩의 모델 참조와 설치 ID를 읽습니다.
6. 바인딩이 완료되어도 실제 Work 호출 여부는 사례 I에서 별도로 확인합니다.

분기 예시

현장 판단 예시: 별칭 변경 뒤 과거 바인딩 표시

11:00에 런타임 별칭이 바뀌었는데 제품에는 10:30의 바인딩됨 기록이 남아 있다고 가정합니다. 10:30 기록은 변경 전 상태입니다. 11:00 이후 새 감지, Core 검증, 바인딩의 각 시각과 모델 참조가 이어져야 변경 후 자동 재바인딩을 확인할 수 있습니다. 새 감지만 있고 바인딩이 없다면 사례의 분기표로 원인을 좁힙니다.

이 표의 시각은 가상 예시입니다. 제품이 실제로 반환한 상태·거부 코드를 기록하고, 내부 저장소를 직접 편집하지 마십시오.

지원 요청 예시

“릴리스 [값], 설치 ID [값], 런타임 종류 [공개 가능한 이름], 기대 모델 [이름], 변경 시각 [값], 감지/검증/바인딩 상태 [각각], 거부 메시지 [원문]입니다. Work는 실행하지 않았습니다.”

완료·중지 기준

완료: 현재 관찰과 승인 범위에 연결된 새 바인딩이 제품에 표시됩니다. 중지: 데이터베이스를 직접 고치거나 거부된 이전 바인딩을 복사하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 F-1: 모델 파일은 있지만 런타임 관찰이 없음

상황: 운영자는 모델 파일을 준비했으므로 바인딩도 완료될 것으로 기대합니다. 제품에는 현재 런타임 관찰이 없거나 감지 단계만 표시됩니다. 파일 준비·프로세스·제품 관찰을 각각 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• 모델 파일: 존재만 확인됐습니다.
• 런타임 프로세스: 지원 버전과 실제 실행 상태를 확인해야 합니다.
• 제품 관찰: 최신 관찰·검증·바인딩이 아직 없습니다.

확인·조치 순서:

1. 릴리스가 지원하는 런타임·모델·주소와 실제 준비한 조합을 대조합니다.
2. 제품의 감지·설정 위자드에서 현재 관찰과 사유를 확인합니다.
3. 지원 범위 안에서 준비가 끝난 뒤 제품이 새 관찰을 검증했는지 확인합니다.

다음 단계로 돌아갈 조건: 현재 설치의 런타임·모델 참조가 검증·바인딩됐을 때만 바인딩 완료로 기록합니다.

해결되지 않았을 때: 지원 대상이나 관찰 경로를 확인할 수 없으면 바인딩 상태 파일을 직접 만들지 않고 담당자에게 인계합니다.

상세 예시 F-2: 별칭만 바꿨는데 이전 바인딩이 계속 보임

상황: 모델 별칭을 바꾼 뒤 화면에는 여전히 이전 바인딩이 보입니다. 화면 캐시인지, 새 관찰이 아직 없는지, 새 대상이 거부됐는지를 먼저 구분해야 합니다.

관찰을 이렇게 나눠 읽습니다.

• 변경 기록: 별칭 또는 주소의 전후 값을 구분합니다.
• 표시된 바인딩: 변경 전 관찰일 수 있습니다.
• 새 관찰: 시각·대상·거부 사유를 별도로 확인합니다.

확인·조치 순서:

1. 이전 바인딩 참조와 새로 요청한 런타임·모델 참조를 보존합니다.
2. 제품이 제공한 새 관찰·검증 절차를 사용하고 그 시각이 변경 이후인지 대조합니다.
3. 새 대상이 범위 밖이면 승인 담당자가 판단할 때까지 이전 결과를 새 대상으로 복사하지 않습니다.

다음 단계로 돌아갈 조건: 새 관찰에 묶인 대상과 바인딩이 일치해야 새 환경 적용으로 기록합니다.

해결되지 않았을 때: 새 관찰이 없거나 사유가 미확인이면 이전 바인딩을 근거로 새 Work를 시작하지 않습니다.

상세 예시 F-3: 여러 모델이 감지돼 대상 선택이 모호함

상황: 한 환경에 둘 이상의 모델이 있고 제품이 런타임은 감지했지만 자동 바인딩을 적용하지 않습니다. 사용 가능한 첫 모델을 임의로 골라 성공 처리할 수 없는 상황입니다.

관찰을 이렇게 나눠 읽습니다.

• 감지: 여러 후보가 보입니다.
• 관리자 범위: 어느 모델·런타임을 허용했는지 확인이 필요합니다.
• 제품 결과: 모호함 또는 범위 거부 사유를 그대로 보존합니다.

확인·조치 순서:

1. 원래 계획한 대상과 공급자가 지원하는 모델 조합을 먼저 특정합니다.
2. 관리자가 현재 설치의 허용 범위를 제품 절차에서 확인합니다.
3. 정확한 대상이 정해진 뒤 새 관찰·검증 결과를 읽습니다.

다음 단계로 돌아갈 조건: 의도한 단일 대상과 검증된 바인딩이 기록된 뒤 해당 범위의 사용을 계속합니다.

해결되지 않았을 때: 대상 선택 권한이나 지원 조합이 없으면 임의 기본값을 만들어 바인딩하지 않습니다.

이 사례의 지원 기록을 실제로 채우기

현재 런타임·모델 참조, 변경 전후 값, 관찰 시각, 검증 결과·거부 사유, 관리자 허용 범위.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: F-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

실제 관찰과 의미

로컬 모델 시작 실패는 모델 부재, 자원 부족, 네트워크 확인 실패 등 원인이 다를 수 있습니다. 네트워크 정책을 바꾸기 전에 정확한 메시지와 제공된 오프라인 설정 절차를 확인하십시오.

예시 상황

고객은 오프라인 환경에서 로컬 모델을 쓰려 합니다. 런타임이 모델 다운로드를 기다리거나 메타데이터 확인이 시간 초과됩니다. 또는 모델 시작이 실패하지만 화면만으로 메모리 부족인지 모델 부재인지 구분되지 않습니다.

확인 순서

1. 릴리스의 지원 모델·아키텍처·메모리·디스크 요구사항을 확인하고 그 목록에 맞춰 VM 크기를 정합니다.
2. 모델이 이미 로컬에 준비됐는지 제품 또는 릴리스가 지정한 방법으로 확인합니다. 다운로드 화면은 로컬 설치 완료가 아닙니다.
3. 고객의 오프라인 정책과 릴리스가 요구하는 로컬 전용 설정을 확인합니다. 외부 접근이 금지된 환경에서 임의로 인터넷 출구를 열지 않습니다.
4. 실패가 모델 프로세스 시작인지, 런타임 발견인지, 바인딩 검증인지 분리합니다. 문제 단계가 다르면 조치도 다릅니다.
5. 제품이 기록한 호출·실패 상태를 확인합니다. 시간 초과된 공급사 메타데이터 요청을 성공한 AI 추론으로 기록하지 않습니다.
6. 자원을 변경할 경우 고객이 승인한 환경 변경 절차 뒤 런타임을 다시 관찰·검증·바인딩합니다.

결과별 조치

지원 요청 예시

“릴리스 [값], OS/아키텍처 [값], 모델 [값], 로컬 모델 준비 여부 [값], 실패 단계 [시작/발견/검증/Work], 최초 오류 [원문], 외부 통신 정책 [허용/차단]입니다. 프롬프트와 고객 데이터는 첨부하지 않았습니다.”

완료·중지 기준

완료: 지원되는 로컬 모델이 준비되고 현재 런타임이 검증·바인딩됩니다. 실제 추론과 Work는 별도 확인이 필요합니다. 중지: 요구 사양 미확인, 비승인 인터넷 연결, 외부 추론이 없었다는 근거 없는 주장.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 G-1: 모델 로딩 중 종료되지만 메모리 부족은 아직 미확인

상황: 모델을 시작하면 곧 종료됩니다. 사용자는 무조건 메모리를 늘리려 하지만 실제 오류는 아직 확인하지 않았습니다. 자원·아키텍처·모델 준비 상태를 함께 확인해야 합니다.

관찰을 이렇게 나눠 읽습니다.

• 프로세스: 시작 후 종료됩니다.
• 실패 사유: 실제 오류 없이는 자원 부족으로 확정하지 않습니다.
• 지원 조건: 모델·아키텍처·메모리·디스크 요구사항이 비교 대상입니다.

확인·조치 순서:

1. 정확한 모델 버전·아키텍처와 릴리스 요구사항을 대조합니다.
2. 허용된 상태 조회에서 사용 가능한 자원과 최초 종료 사유를 확인합니다.
3. 실제로 부족한 자원이 확인되면 환경 담당자가 승인된 변경 후 런타임을 다시 관찰합니다.

다음 단계로 돌아갈 조건: 모델이 지원 조건에서 시작되고 현재 관찰·검증·바인딩까지 확인되면 준비 완료로 기록합니다.

해결되지 않았을 때: 정확한 실패 사유가 없으면 크기 변경·모델 교체를 반복하지 않고 종료 관찰과 지원 조건을 인계합니다.

상세 예시 G-2: 폐쇄망에 모델 파일을 반입하지 않아 다운로드 대기

상황: 폐쇄형 온프렘에 클라이언트와 SDK 의존성 세트는 반입했지만 모델은 없습니다. 런타임은 모델 다운로드를 기다립니다. Rust 의존성이 준비됐다는 사실은 모델 가중치가 준비됐다는 뜻이 아닙니다.

관찰을 이렇게 나눠 읽습니다.

• SDK 의존성: Rust 컴파일 자산에 대한 준비입니다.
• 모델: 로컬에 준비됐는지 별도 확인합니다.
• 외부 경로: 차단 정책을 임의로 열어 해결하지 않습니다.

확인·조치 순서:

1. 실제 사용할 모델·버전과 라이선스·지문·저장 요구를 제공 목록에서 확인합니다.
2. 조직이 승인한 오프라인 모델 반입 경로로 준비하도록 담당자에게 인계합니다.
3. 파일 확인 뒤 모델 시작, 현재 관찰과 바인딩을 순서대로 확인합니다.

다음 단계로 돌아갈 조건: 필요한 모델이 검증된 로컬 자산으로 준비되고 런타임 바인딩이 확인돼야 해당 준비가 끝납니다.

해결되지 않았을 때: 반입 경로나 권리가 미확인이면 임의 저장소에서 모델을 가져오지 않고 공급·라이선스 담당자에게 인계합니다.

상세 예시 G-3: 온라인 메타데이터 확인 실패와 로컬 사용을 구별하기

상황: 로컬 모델은 준비돼 있지만 외부 메타데이터 조회가 시간 초과됩니다. 이 한 결과를 전체 로컬 추론 실패 또는 외부 통신이 전혀 없었다는 증거로 사용할 수 없습니다.

관찰을 이렇게 나눠 읽습니다.

• 외부 조회: 시도 후 시간 초과입니다.
• 로컬 추론: 별도 호출 결과가 있어야 확인됩니다.
• 제품 Work: 별도 Work ID·영수증을 확인해야 합니다.

확인·조치 순서:

1. 고객 네트워크 정책과 릴리스가 제공한 로컬 전용 설정이 실제로 적용됐는지 확인합니다.
2. 외부 조회의 실패, 로컬 모델 시작, 바인딩과 Work의 관찰을 각각 기록합니다.
3. 허용된 진단으로 재확인하되 정책 변경이나 외부 모델 대체는 별도 담당자의 절차를 따릅니다.

다음 단계로 돌아갈 조건: 확인한 로컬 단계의 결과만 성공으로 기록하고 외부 조회 실패는 별도로 남깁니다.

해결되지 않았을 때: 통신 범위나 모델 선택을 확인할 수 없으면 무외부 통신·로컬 Work 완료를 주장하지 않고 인계합니다.

이 사례의 지원 기록을 실제로 채우기

OS·아키텍처, 모델·런타임 버전, 요구·현재 자원, 로컬 모델 준비, 최초 종료·외부 조회 상태.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: G-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

실제 경계

Pack Builder는 Pack을 준비하고 검증하도록 돕습니다. 후보 생성, 파일 저장, 화면의 준비 상태, passkey 등록은 각각 별도 상태입니다. 어느 하나도 고객의 Pack 승인·사용 권한·실행 권한을 자동으로 만들지 않습니다.

예시 상황

운영자가 Builder에서 Pack 후보를 만들었습니다. 미리보기와 구조 검사는 통과했지만 PackrGUI의 실행 목록에 나타나지 않거나 Work 요청이 거부됩니다. “Builder에서 만들었으니 실행할 수 있다”는 결론은 성립하지 않습니다.

확인 순서

1. 이 릴리스에 Builder가 실제 제공되는지, 설치 파일의 서명·버전이 맞는지 확인합니다.
2. 후보의 검증 상태와 결함 목록을 확인합니다. 구조 검증 통과가 실행 승인과 다른지 봅니다.
3. Pack의 정확한 버전·계약·요청 능력·대상 환경을 확인합니다.
4. 고객 설치의 Pack 승인 여부와 사용 권한을 제품 상태에서 각각 확인합니다. 다른 고객 또는 설치의 승인을 재사용하지 않습니다.
5. 실행 전 사전 조건과 필요한 별도 사용자 승인 또는 passkey 절차가 있는지 확인합니다. 브라우저가 열리거나 앱으로 돌아오는 것만으로 승인이 완료된 것은 아닙니다.
6. 제품 거부 사유가 남으면 후보를 수정하거나 승인 절차를 진행하되, 거부된 Work를 다른 경로로 실행하지 않습니다.

상태별 조치

지원 요청 예시

“릴리스 [값], Builder 버전 [값], 후보 ID/버전 [공개 가능한 값], 검증 상태 [값], 승인 상태 [값], 고객 권한 상태 [값], 최초 Work 거부 [원문]입니다.” Pack 소스, 내부 계약 원문, passkey 응답은 첨부하지 않습니다.

완료·중지 기준

완료: 정확한 Pack이 이 고객 설치에 대해 검증·승인·권한 부여됐고 사전 조건을 충족합니다. 중지: 후보를 승인 Pack으로 바꿔 표시하거나 거부된 실행을 우회하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 H-1: 후보 구조 검사는 통과했지만 승인은 대기

상황: Builder가 후보 검증 PASS를 표시해 사용자가 실행 목록에서 찾습니다. 하지만 정확한 후보 리비전에 대한 승인 기록은 아직 없습니다. 준비와 사용 승인 사이의 단계가 남아 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 후보 검증: 지정 검사 범위의 성공입니다.
• 승인: 대기 상태입니다.
• 실행: Work 시작·영수증은 없습니다.

확인·조치 순서:

1. 현재 후보 ID·리비전·지문과 검증 결과가 같은 대상을 가리키는지 확인합니다.
2. 릴리스의 승인 담당자에게 변경 목적·후보 지문·검증 결과를 인계합니다.
3. 승인 후에도 현재 고객·설치 사용 권한과 사전 조건을 별도로 확인합니다.

다음 단계로 돌아갈 조건: 정확한 후보에 대한 승인·권한·사전 조건이 확인되면 실행 준비 단계로만 이동합니다.

해결되지 않았을 때: 승인이 없으면 후보를 Pack 폴더로 복사하거나 다른 계정으로 실행하지 않습니다.

상세 예시 H-2: 승인은 있지만 다른 설치의 사용 권한

상황: 한 설치에서 승인한 Pack을 다른 설치에서도 사용할 수 있을 것으로 기대합니다. 제품은 현재 설치의 사용 권한을 거부합니다. 승인 기록의 존재와 적용 범위를 나누어 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• Pack 승인: 정확한 버전·대상 범위를 확인합니다.
• 현재 설치: 승인·사용 권한의 설치와 다를 수 있습니다.
• 거부: 현재 요청의 권한 결과입니다.

확인·조치 순서:

1. 현재 고객·설치·Pack 버전과 사용 권한 기록의 참조를 대조합니다.
2. 필요한 권한을 담당자가 정식 절차로 판단합니다. 다른 설치의 파일을 복사하지 않습니다.
3. 권한이 확인된 뒤 같은 대상의 사전 조건·계획을 다시 확인합니다.

다음 단계로 돌아갈 조건: 현재 설치를 대상으로 한 권한과 계획이 확인돼야 해당 Pack의 실행 절차를 진행합니다.

해결되지 않았을 때: 권한 담당자의 확인이 없으면 승인 파일의 이름·설치 ID를 바꿔 재사용하지 않습니다.

상세 예시 H-3: 승인 뒤 후보를 수정해 지문이 달라짐

상황: 검토자가 승인한 뒤 입력 선언이나 후보 파일을 수정했습니다. 이전 승인 화면은 남아 있지만 새 후보의 지문은 달라졌습니다. 새 바이트가 승인됐는지 다시 확인해야 합니다.

관찰을 이렇게 나눠 읽습니다.

• 기존 승인: 이전 후보 지문에 대한 기록입니다.
• 현재 후보: 수정된 리비전·지문입니다.
• 현재 검증: 새 후보에 대한 결과가 필요합니다.

확인·조치 순서:

1. 수정 전후 후보 지문과 변경 목적을 보존합니다.
2. 새 후보의 검증과 승인 적용 범위를 정식 절차에서 확인합니다.
3. 현재 후보·승인·사용 권한·실행 계획의 참조를 나란히 대조합니다.

다음 단계로 돌아갈 조건: 현재 바이트를 대상으로 한 결과가 확인돼야 새 후보로 진행합니다.

해결되지 않았을 때: 이전 승인을 새 후보에 복사하거나 매니페스트 지문만 바꿔 일치시키지 않습니다.

이 사례의 지원 기록을 실제로 채우기

후보 ID·리비전·지문, 검증 대상, 승인 목적·범위, 현재 사용 권한, 사전 조건과 실제 Work 유무.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: H-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

실제 관찰과 의미

로컬 런타임이 바인딩돼 있어도 Work가 제출되지 않았을 수 있습니다. 런타임 준비와 Work 완료는 각각 다른 기록으로 확인합니다.

예시 상황

PackrGUI에 런타임 바인딩됨이 보입니다. 운영자는 첫 작업이 완료됐다고 생각하지만 Work 목록에는 결과가 없고 영수증도 없습니다. 또는 작업은 제출됐으나 상태가 대기/중단/롤백입니다.

확인 순서

1. 같은 고객·설치·릴리스 신원에서 Work가 실제 제출됐는지 확인합니다.
2. 요청한 Pack이나 작업의 승인·사용 권한·사전 조건이 충족됐는지 확인합니다.
3. 제품의 Work 기록에서 승인, 실행 시작, 모델 호출, 결과 검증, 최종 상태를 각각 확인합니다. 일부 단계가 없으면 그 지점이 현재 상한입니다.
4. 로컬 모델을 사용했다면 그 Work에 묶인 호출이 있는지 확인합니다. 모델이 일반적으로 응답 가능하다는 사실을 이 Work의 호출로 사용하지 않습니다.
5. 최종 상태가 성공인 경우에만 그 Work ID와 동일한 결과·영수증 위치를 확인합니다. 실패·중단·롤백은 성공 영수증이 아닙니다.
6. 영수증이 없으면 릴리스의 기록 조회 절차를 따르고 최초 누락 지점을 지원팀에 전달합니다. 수동 영수증 파일을 만들지 않습니다.

설치 목록에 packrctl이 있고 해당 설치에 인증됐다면, 상태가 불확실한 Work를 다시 실행하지 말고 조회하십시오. 자리표시자는 반환된 Work ID로 바꿉니다.

packrctl work list --limit 10 --json
packrctl work show "PASTE_RETURNED_WORK_ID" --json

허용된 계정의 목록이 비어 있어도 다른 계정이 Work를 제출한 적 없다고 증명되지는 않습니다. 보고서 파일이나 모델 응답은 제품의 타입이 정해진 Work·영수증 기록을 대신하지 못합니다.

어디서 멈췄는지 판단

예시: 런타임은 바인딩됐지만 Work 준비는 미확인

로컬 모델 별칭을 바꾼 뒤 어플라이언스에는 새 BOUND가 보이지만 Work 준비 상태는 UNKNOWN이라고 가정합니다. 설치·릴리스, 바인딩 시각, 권한과 런타임의 별도 상태, 제품이 표시한 정확한 사유, Work ID 유무를 기록하십시오. 준비가 계속 UNKNOWN이면 제출 전에 멈추고 그 값을 지원 경로로 전달합니다. 명령 반복, 상태 파일 수정, 바인딩 기록을 영수증으로 취급하는 방식은 Work 완료를 입증하지 못합니다.

현장 판단 예시: 모델 응답과 Work 결과 혼동

운영자가 모델 시험 질문에 응답을 받고 GUI에서 바인딩됨을 본 뒤 첫 Work 완료라고 보고하려 한다고 가정합니다. 이때 Work ID가 없다면 제출도 확인되지 않았습니다. ID가 있더라도 승인·실행 시작·모델 호출·결과 검증·종료와 영수증을 각각 확인해야 합니다. 아래 표는 자신의 설치에서 수행한 Work에 사용하십시오.

첫 누락 관문을 기록해 지원팀에 전달하십시오. 다른 Work의 영수증이나 수동 파일 생성으로 빈칸을 채우지 마십시오.

지원 요청 예시

“릴리스 [값], 설치 ID [값], Work ID [있으면], Pack/작업명 [공개 가능한 값], 마지막 확인 상태 [값], 최초 거부/누락 [원문], 모델 호출 확인 [예/아니요/확인 불가], 영수증 상태 [없음/있음]입니다.” 프롬프트·결과 원문은 보내지 않습니다.

완료·중지 기준

완료: 승인된 같은 Work의 성공 최종 상태, 검증된 결과와 영수증이 일치합니다. 중지: 바인딩 화면, 추정 호출, 다른 Work의 영수증으로 빈 기록을 채우지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 I-1: 모델 시험 응답은 있으나 Work ID가 없음

상황: 운영자는 모델 시험 응답과 바인딩됨 화면을 보고 첫 Work가 끝났다고 생각합니다. 제품 Work 목록에는 해당 요청이 없습니다. 모델 시험과 제품 실행을 구별할 필요가 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 모델 응답: 일반 시험 결과입니다.
• 바인딩: 현재 런타임 준비에 대한 결과입니다.
• Work: 제출된 실제 ID가 아직 확인되지 않습니다.

확인·조치 순서:

1. 허용된 현재 계정으로 제품 Work 목록을 읽고 해당 요청의 실제 제출 여부를 확인합니다.
2. ID가 없으면 제출 미확인으로 기록합니다. 다른 계정의 이력까지 없다고 일반화하지 않습니다.
3. 승인된 첫 Work가 필요하면 원래의 계획·승인 절차에서 시작하고 반환된 ID를 보관합니다.

다음 단계로 돌아갈 조건: 실제 Work의 승인·실행·검증·최종 상태·영수증을 확인하기 전에는 첫 Work 완료로 표시하지 않습니다.

해결되지 않았을 때: 제출 권한이나 지원 Pack이 없으면 모델 응답으로 영수증을 만들지 말고 준비 상태를 인계합니다.

상세 예시 I-2: 제출한 Work의 결과가 늦게 보임

상황: Work 제출 후 실제 ID를 받았지만 클라이언트 연결이 끊어졌습니다. 사용자는 같은 요청을 다시 실행하려 합니다. 먼저 반환된 ID로 현재 상태를 조회해야 중복 실행을 피할 수 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 제출: 실제 반환 ID가 있습니다.
• 클라이언트: 연결이 끊겼다는 사실만 확인됐습니다.
• 실행 결과: 연결 오류만으로 실패·성공을 확정할 수 없습니다.

확인·조치 순서:

1. 동일 고객·설치·Work ID를 제품의 조회 경로로 읽습니다.
2. 대기·실행 중·실패·롤백·성공 등 실제 반환 상태와 갱신 시각을 보존합니다.
3. 성공 종료라면 같은 Work의 결과 검증과 영수증을 대조합니다. 미종료라면 제공된 대기·지원 절차를 따릅니다.

다음 단계로 돌아갈 조건: 동일 Work의 종료와 결과·영수증이 확인된 뒤 그 결과로만 처리합니다.

해결되지 않았을 때: 조회가 불가능하거나 상태가 미확인이면 다시 제출하지 않고 ID·최초 연결 오류·마지막 상태를 인계합니다.

상세 예시 I-3: 보고서는 있지만 영수증의 설치·Work가 다름

상황: 공유 폴더에서 결과 파일과 영수증을 찾았지만 여러 실행 결과가 함께 있습니다. 파일 이름이 비슷하다는 이유로 현재 Work의 완료 증거로 사용할 수 없습니다.

관찰을 이렇게 나눠 읽습니다.

• 결과 파일: 존재하지만 소속 실행은 아직 미확인입니다.
• 영수증: 고객·설치·Work 참조를 확인해야 합니다.
• 제품 기록: 현재 Work의 최종 상태와 결과 지문이 비교 기준입니다.

확인·조치 순서:

1. 반환된 Work ID의 제품 기록을 먼저 읽고 현재 결과 지문을 확인합니다.
2. 영수증의 실행·설치 참조와 제공된 검증 절차의 결과를 대조합니다.
3. 불일치 파일은 원본 상태로 보존하고 다른 실행 결과와 분리하여 담당자에게 인계합니다.

다음 단계로 돌아갈 조건: 같은 실행의 기록·결과·검증된 영수증이 일치한 경우에만 완료를 기록합니다.

해결되지 않았을 때: 영수증의 ID나 해시를 직접 고쳐 맞추지 않고 현재 Work의 미확인 상태를 유지합니다.

이 사례의 지원 기록을 실제로 채우기

반환된 Work ID, 현재 고객·설치, 마지막 상태·갱신 시각, 결과 지문, 영수증 참조·검증 결과.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: I-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

실제 관찰과 의미

새로 배포한 VM에는 고유한 설치 신원과 호스트 신원이 있어야 합니다. 첫 설정에서 기존 조직명·관리자·접근 키가 보인다면 사용 전에 원인을 확인해야 합니다.

예시 상황

공식 이미지로 새 고객 VM을 만들었는데 설정 화면에 이전 조직 이름이나 이미 등록된 관리자처럼 보이는 항목이 있습니다. 또는 예상하지 못한 사용자 홈·접근 키·이미 사용된 설치 ID가 보입니다. 이 상태를 “초기 샘플”로 추정하고 계속 작업하지 않습니다.

확인 순서

1. Work를 시작하지 않고 외부 연결과 추가 사용자 등록을 멈춥니다.
2. 받은 이미지의 공식 릴리스 ID와 배포 방법, 새 인스턴스의 생성 시각을 기록합니다.
3. 제품이 표시하는 고객·설치 신원과 예상 값을 비교합니다. 다른 고객 데이터 내용은 열거나 복사하지 않습니다.
4. 클라우드 관리 화면에서 이 인스턴스가 의도한 공식 이미지에서 만들어졌는지만 확인합니다. 내부 디스크 파일을 탐색해 원인을 분석하지 않습니다.
5. 릴리스 지원 또는 배포 담당자에게 최초 발견 화면의 최소 정보, 이미지 ID, 설치 ID, 시각을 전달합니다. 담당자의 격리·교체 결정을 기다립니다.

결과별 조치

현장 판단 예시: 새 설치에 이전 계정 흔적

새 VM에서 의도하지 않은 사용자 홈이나 이전 설치 ID가 보이면, 그것이 비어 있는지 또는 고객 정보가 실제로 들어 있는지 직접 탐색하지 않습니다. 발견 자체가 새 이미지의 신원·접근 상태를 재검토해야 할 신호입니다. Work와 추가 사용자 등록을 중단하고 배포 이미지 ID, 새 인스턴스 ID, 발견 시각, 제품이 표시한 설치 신원만 최소한으로 기록합니다.

지원 요청 예시

“릴리스 [값], 공식 이미지 ID [값], 새 인스턴스 생성 시각 [시간대 포함], 예상 설치 ID [값], 실제 표시된 신원 종류 [고객/사용자/설치], 최초 발견 화면의 최소 설명 [값]입니다. Work나 추가 등록은 하지 않았습니다.”

다른 고객의 이름·파일 내용·키·전체 디스크 이미지는 일반 지원 티켓에 첨부하지 않습니다.

완료·중지 기준

완료: 공식 담당자가 이미지와 새 설치 신원을 독립적으로 검증하고 사용 재개를 명시합니다. 중지: 고객이 이전 파일을 삭제하거나 키를 바꿔 이미지를 정상으로 표시하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 J-1: 새 VM의 첫 설정에 이전 조직이 표시됨

상황: 새 설치라고 전달받았지만 첫 설정 화면에 예상하지 않은 조직이나 관리자 표시가 있습니다. 예시 데이터일 것이라고 가정해 고객 정보를 입력하기 전에 출처를 확인해야 합니다.

관찰을 이렇게 나눠 읽습니다.

• VM 생성: 새 인스턴스라는 기록이 있습니다.
• 제품 표시: 예상 조직·설치와 다릅니다.
• 내용: 이전 데이터나 자격 증명을 직접 열어 조사하지 않습니다.

확인·조치 순서:

1. Work·추가 등록·고객 데이터 입력을 중단합니다.
2. 서명 이미지·인스턴스 출처·생성 시각과 제품이 표시한 신원 종류만 최소한으로 기록합니다.
3. 이미지·배포 담당자에게 인계하고 승인된 격리·교체 결정을 따릅니다.

다음 단계로 돌아갈 조건: 담당자가 이미지와 새 설치 신원을 독립 검증하고 사용 재개를 명시해야 설정으로 돌아갑니다.

해결되지 않았을 때: 이전 표시를 지우거나 사용자 디렉터리를 삭제해 새 설치처럼 만들지 않습니다.

상세 예시 J-2: 서로 다른 VM의 설치 신원이 동일함

상황: 팀이 두 VM을 만들었는데 제품 설치 ID가 같습니다. 주소와 인스턴스 이름은 서로 다릅니다. 복제·출처 문제인지 아직 확정되지 않았더라도 두 독립 설치가 맞는지 확인해야 합니다.

관찰을 이렇게 나눠 읽습니다.

• 인스턴스: 두 개의 생성 기록이 있습니다.
• 설치 ID: 동일한 값이 표시됩니다.
• 호스트 신원: 제품 설치 신원과 별도로 확인할 항목입니다.

확인·조치 순서:

1. 두 인스턴스의 작업과 추가 등록을 보류하고 각 출처·생성 기록을 분리합니다.
2. 공식 이미지에서의 새 배포인지 기존 디스크·VM 복제인지 관리 기록으로 확인합니다.
3. 설치 신원 생성·이미지 출처 검증은 담당자에게 인계하고 ID·키를 수동 변경하지 않습니다.

다음 단계로 돌아갈 조건: 각 새 설치의 고유 신원과 승인된 사용 재개를 확인한 뒤에만 독립 환경으로 사용합니다.

해결되지 않았을 때: 두 환경을 번갈아 사용하며 문제를 숨기거나 기존 승인·권한 파일을 나눠 복사하지 않습니다.

상세 예시 J-3: 교체 VM에서도 이전 상태가 반복됨

상황: 문제가 있던 VM 대신 새 인스턴스를 만들었는데 같은 이전 상태가 보입니다. 같은 이미지를 여러 번 생성하는 것만으로 원인이 해결되지는 않습니다.

관찰을 이렇게 나눠 읽습니다.

• 첫 VM과 교체 VM: 별도의 인스턴스 기록을 보존합니다.
• 이미지: 정확한 세대와 출처를 각각 대조합니다.
• 반복 현상: 원인 확정 없이 관찰 사실로 기록합니다.

확인·조치 순서:

1. 반복 생성과 고객 데이터 투입을 멈추고 두 VM의 이미지·생성 기록·신원 표시를 최소한으로 보관합니다.
2. 공급 담당자가 원본 이미지와 설치 절차를 검증하고 정확한 교체 대상을 지정하도록 인계합니다.
3. 교체 뒤에는 새 이미지 출처·설치 신원·서비스 준비를 다시 확인합니다.

다음 단계로 돌아갈 조건: 문제를 가진 입력과 구별되는 검증된 교체 출처, 고유 신원과 재개 결정이 있어야 종료합니다.

해결되지 않았을 때: 기존 Golden·원본 이미지를 사용자 임의로 수정하거나 재봉인하지 않고 원본 증거를 보존합니다.

이 사례의 지원 기록을 실제로 채우기

공식 이미지·인스턴스 출처, 생성 시각, 표시된 신원 종류, 기대 신원 일치 여부, 중단·인계 상태.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: J-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

운영 목적과 선행 조건

전달받은 어플라이언스 이미지를 새 VM으로 배포하고 제품이 만든 설치 신원에 로컬 Appliance Administrator를 등록합니다. 배포 전에 구성요소 목록, 서명 검증 절차, 지원 환경 표와 조직의 배포 승인을 준비하십시오.

예시 대화

설치 담당자가 “VM 상태가 실행 중입니다. 이제 GUI를 연결해도 되나요?”라고 묻습니다. 관리자는 “제품의 첫 부팅과 서비스 준비가 별도로 확인되어야 합니다. 설치 신원도 새로 생성됐는지 확인하겠습니다”라고 답합니다. 이 구분이 첫 번째 관문입니다.

실행 순서와 남길 기록

1. 서명 또는 지문이 다르면 설치를 시작하지 않습니다. 파일명 변경으로 불일치를 가리지 않습니다.
2. VM 전원이 켜져도 서비스 준비 상태가 나오지 않으면 첫 부팅 사례를 따릅니다.
3. 접속 시 호스트 신원 경고가 나오면 호스트 신원 사례로 이동합니다. 확인 전 신뢰를 갱신하지 않습니다.
4. 관리자 확인을 비대화형 스크립트로 대체하지 않습니다. 등록 거부는 대화형 등록 사례에서 분류합니다.
5. 등록 직후 읽기 전용 상태로 역할·범위·유효기간을 확인합니다. OS 로그인과 제품 관리자 권한은 별개입니다.

성공과 실패의 경계

이 용례의 성공은 정확한 서명 파일, 새 설치 신원, 준비된 서비스, 실제 관리자의 기록된 범위까지입니다. 런타임 바인딩과 Work 영수증은 다음 용례에서 확인해야 합니다. 다른 고객 신원, 이전 사용자 흔적, 상태 무결성 경고가 있으면 사용을 중단하고 이미지 잔여 사례를 따릅니다.

상세 시나리오: VM 전원 상태와 제품 준비 상태가 다른 경우

예를 들어 배포 담당자가 09:00에 VM을 생성했고 클라우드 화면에 09:02부터 실행 중이 보이지만, 제품 위자드에는 아직 준비 완료가 보이지 않는다고 가정합니다. 이때 기록에는 VM 생성 시각, 이미지 ID, 제품 상태를 마지막으로 확인한 시각을 분리해 적습니다. 서비스가 준비되지 않은 동안 관리자 등록이나 GUI 인증을 시도해 나온 오류는 첫 부팅 실패의 근거가 아닐 수 있습니다. 릴리스의 대기·상태 절차를 한 번 수행하고, 준비가 계속 확인되지 않으면 사례 A로 넘깁니다.

관리자 등록은 배포 담당자와 권한 소유자가 서로 다른 조직에서도 성립해야 합니다. 배포 담당자는 설치 ID와 이미지 출처를 넘기고, 권한 소유자는 고객·설치·런타임 허용 범위를 실제 제품 화면에서 검토합니다. 이후 읽기 전용 결과에 범위와 유효기간이 표시될 때만 이 단계를 닫습니다.

인계 기록 예시

위 대괄호 값은 예시 입력란이며 실제 릴리스 값을 만들어내지 않습니다. 다른 고객 또는 이전 설치의 값이 보이면 다음 단계로 넘기지 마십시오.

운영 중 사용할 구체적인 진행 예

운영 인계는 VM 생성자와 제품 관리자 사이에서 이루어질 수 있습니다. 온라인 설치는 승인된 포털·전달 경로에서 파일을 준비하고, 폐쇄망 설치는 동일 세대의 이미지·클라이언트·필요 모델·지문·문서를 반입 전에 준비합니다. 두 환경 모두 실제 신원과 관리자 범위 확인은 설치된 제품에서 수행합니다.

이 용례를 마칠 때 대조할 기록

인계 전 같은 설치 ID에 묶인 서비스 준비·관리자 역할·범위·만료와 다음 클라이언트 담당자를 기록합니다. 관리자 등록이 미완료이면 그 상태로 인계하며 런타임·Work를 완료 처리하지 않습니다.

계획한 절차, 실제 수행한 동작, 확인된 결과와 남은 단계를 구분해 기록하십시오. 위 상황은 이해를 위한 예시이며 이 문서 갱신에서 고객 환경의 실행이 이루어진 것은 아닙니다.

사용 용례 색인으로 돌아가기

운영 목적과 선행 조건

고객이 이미 승인한 설치·런타임 범위 안에서 로컬 모델의 별칭 또는 런타임 관찰값이 바뀌었을 때, Core가 새 관찰을 검증해 바인딩을 갱신하는 흐름입니다. 현재 설치 신원, 관리자 범위, 지원 모델과 변경 전 바인딩 상태를 먼저 확보합니다.

예시 상황

운영자가 로컬 모델의 별칭을 바꿉니다. 모델 서버는 실행 중이지만 PackrGUI는 과거 바인딩 시각을 보여 줍니다. 이 시점의 “모델이 응답한다”는 사실만으로 새 모델의 바인딩을 완료했다고 말할 수 없습니다.

변경 전·후 확인표

순서대로 진행

1. 변경 내용과 시각을 기록합니다. 기존 바인딩을 삭제하거나 내부 상태 저장소를 직접 고치지 않습니다.
2. 릴리스 위자드가 제공하는 감지·재관찰 경로에서 새 런타임이 발견되는지 확인합니다.
3. 현재 관리자가 승인한 고객·설치·런타임 범위 안인지 확인합니다. 범위 밖이면 자동 적용을 기대하지 않고 관리자 결정을 받습니다.
4. 제품의 감지 → 검증 → 바인딩 상태와 거부 사유를 순서대로 읽습니다. 여러 후보 모델 중 대상이 모호하면 임의 선택하지 않습니다.
5. 새 바인딩의 모델 참조, 설치 ID, 기록 시각이 변경 이후인지 확인합니다. 이때만 바인딩 갱신을 기록합니다.
6. 실제 Work와 영수증은 별도로 실행·검증합니다. 영수증 부재 사례를 참고하십시오.

실패 분기와 지원 자료

감지되지 않으면 런타임 실행·공식 연결 경로를 확인합니다. 검증이 거부되면 바인딩 사례에 따라 범위·신원·모호성을 분리합니다. 지원 요청에는 변경 전후 상태·시각·설치 ID·제품 거부 문구만 전달하고 내부 저장소나 고객 프롬프트는 보내지 않습니다.

완료 기준

현재 변경에 대한 새 관찰과 Core의 새 바인딩이 같은 설치 신원으로 기록돼야 합니다. 이것은 Work 결과 또는 macOS·Windows 자동 바인딩 검증을 뜻하지 않습니다.

상세 시나리오: 모델 별칭만 바뀐 경우

예를 들어 10:00에 로컬 런타임의 별칭을 모델-A에서 모델-B로 바꿨다고 가정합니다. 09:40의 바인딩됨 기록은 변경 전의 증거입니다. 운영자는 10:00의 변경 기록과 이후 새 감지 시각을 나란히 놓고, Core가 같은 설치 ID와 승인 범위로 새 모델 참조를 검증했는지 봅니다. 별칭만 변경돼도 여러 후보가 동시에 보이면 임의로 하나를 선택하지 않습니다.

새 바인딩이 나오지 않는다면 단계별로 분류합니다. 런타임 자체가 발견되지 않으면 서비스 준비와 공식 연결 경로를 확인합니다. 발견은 됐으나 범위 밖이면 승인 소유자에게 넘깁니다. 검증은 됐으나 모델 대상이 모호하면 정확한 모델 선택을 요구합니다. 이전 바인딩 화면의 시각만 갱신돼 보인다면 새 바인딩으로 선언하지 않습니다.

변경 기록 예시

시각과 모델명은 절차 설명용 가상 값입니다. 실제 Work는 해당 바인딩 이후의 별도 기록으로 확인하십시오.

운영 중 사용할 구체적인 진행 예

예를 들어 유지보수 창에서 모델 별칭과 런타임 주소 중 하나만 바꿉니다. 변경 전 지원 버전, 바인딩 참조와 마지막 상태를 보관하고 변경 후 새 관찰이 어느 값에 연결됐는지 대조합니다. 온라인 확인 성공이나 로컬 프로세스 재시작만으로 새 바인딩이 적용된 것으로 판단하지 않습니다.

이 용례를 마칠 때 대조할 기록

변경 전후 런타임·모델 참조, 관찰 시각, 검증 사유, 적용된 바인딩과 이후 별도로 수행한 승인 Work를 구분합니다. 되돌림도 제품이 다시 관찰·검증한 결과를 확인합니다.

계획한 절차, 실제 수행한 동작, 확인된 결과와 남은 단계를 구분해 기록하십시오. 위 상황은 이해를 위한 예시이며 이 문서 갱신에서 고객 환경의 실행이 이루어진 것은 아닙니다.

사용 용례 색인으로 돌아가기

첫 연결 실습: 일반 사용자와 VM 관리자를 먼저 구분

목표: 이미 준비된 회사 VM에 내 클라이언트로 연결하고 같은 고객·설치 신원을 확인합니다. 이 실습은 Work를 자동 실행하지 않습니다. 회사에 VM이 아직 없다면 배포 담당자는 설치 안내 1–4절부터 진행하고, 일반 사용자는 설치 신원·준비 상태·접속 자료를 인계받습니다.

1. 관리자로부터 받아야 할 자료

호환 클라이언트의 실제 파일·지문·서명 상태, 고객·설치·릴리스 참조, 접속 endpoint와 TLS 서버명, 내 계정·기기 등록 방식, 허용 역할, 등록 만료/갱신 문의 경로를 받습니다. 릴리스가 기기별 프로필을 제공하면 조직의 안전한 전달 경로로 받습니다. 설명 페이지에 비밀키를 붙여넣거나 공통 설치 ZIP에 넣지 않습니다. 자동 등록 포털은 이 릴리스가 실제 제공할 때만 사용합니다.

2. OS별 설치와 실행 위치 확인

앱이 열리지 않으면 연결 실패가 아니라 앱 기동 단계로 기록합니다. OS의 정확한 경고, 앱 경로·버전·CPU와 동봉 파일을 확인하십시오. 운영체제 보안 설정 해제나 관리자 실행을 일반 해결책으로 사용하지 않습니다.

3. 연결·등록·신원 확인

1. 앱을 열고 해당 릴리스의 연결/프로필 선택 절차를 사용합니다. 새 서버를 추측하지 말고 관리자가 전달한 endpoint·TLS 서버명·프로필을 대조합니다.
2. 릴리스가 제공하는 사용자·기기 등록을 완료합니다. 단순 OS 로그인, 브라우저 복귀, 프로필 파일 선택만으로 등록 완료를 판단하지 않습니다. 만료 또는 미등록이면 관리자에게 그 상태를 전달합니다.
3. 제품이 표시한 고객·설치·릴리스와 관리자의 기대값을 대조합니다. 인증 상태와 서버 준비 상태를 따로 기록합니다. 다른 조직·설치가 보이면 접속을 중단합니다.
4. 처음에는 상태 조회만 확인합니다. 허용된 Work가 보이지 않으면 현재 역할·사용 권한을 관리자와 확인합니다. 일반 사용자에게 VM 관리자 로그인을 요구하지 않습니다.
5. 헤드리스도 사용할 사람만 해당 릴리스의 CLI·서비스 프로필로 별도 인증 상태를 조회합니다. GUI의 자격 증명을 임의 복사하거나 GUI 성공으로 헤드리스를 완료 처리하지 않습니다.

기대 결과: 실행한 클라이언트의 버전·경로, 같은 고객/설치 참조, 실제 인증 상태를 기록할 수 있습니다. 일반 사용자 등록이나 운영 연결이 해당 후보에서 아직 검증되지 않았다면 그 단계는 미확인으로 남습니다. 성공 화면을 가정해 채우지 않습니다.

막히면: 앱 기동 오류 → 패키지·OS 준비, 시간 초과/인증 거부 → 사례 C, 신원 변경 → 사례 B, 관리자 등록 문제 → 사례 D/E로 이동합니다. 실제 첫 Work는 별도의 첫 Work 용례를 따릅니다.

운영 목적

고객의 워크스테이션에서 GUI로 어플라이언스에 접속하고, 운영 자동화가 필요할 경우 릴리스가 제공한 별도의 헤드리스 경로를 확인합니다. 두 경로는 같은 고객 어플라이언스를 사용하더라도 설치 파일, 인증, 세션, 허용 기능과 결과 증거가 다를 수 있습니다.

예시 상황

운영자는 Mac의 PackrGUI에서 상태 화면을 볼 수 있습니다. 팀은 “그러면 Linux 서버의 헤드리스 작업도 준비됐다”고 말합니다. 이 결론은 검증되지 않았습니다. 각 클라이언트에서 직접 인증·설치 신원·기능을 확인해야 합니다.

경로별 확인표

실제 진행 순서

1. 각 플랫폼별 정확한 설치 파일을 릴리스 매니페스트와 대조합니다. Mac 패키지의 성공으로 Windows 패키지를 승인하지 않습니다.
2. GUI에서 서비스 응답, 인증 완료, 고객·설치 ID, 현재 허용 기능을 각각 확인합니다. 창이 열린 상태는 인증 완료가 아닙니다.
3. 헤드리스가 릴리스에 포함됐다면 별도의 공식 절차로 인증·연결·허용 범위를 확인합니다. GUI 자격 증명을 임의로 복사하지 않습니다.
4. 두 경로에서 같은 설치를 보는지 대조하되, 서로의 세션이나 권한을 자동으로 같다고 처리하지 않습니다.
5. 실제 Work를 수행할 때는 사용한 바로 그 경로의 최종 상태와 영수증을 확인합니다. 경로가 다르면 따로 기록합니다.

이번 릴리스가 packrctl을 제공할 때의 읽기 전용 확인

설치 담당자로부터 승인된 로컬 접근 경로를 받은 뒤, 설치 목록에 packrctl이 있는 경우 아래 명령으로 상태와 건강도를 읽으십시오. 권한 있는 어플라이언스 또는 관리 클라이언트에서만 실행합니다. 이 명령으로 GUI 세션을 인증하거나 Work를 승인할 수는 없습니다.

packrctl status --json > headless-status.json
packrctl health --json > headless-health.json

셸 종료 상태뿐 아니라 JSON의 준비 상태와 사유를 읽으십시오. UNKNOWN은 READY가 아닙니다. 정확한 전달 목록에 packrctl이 없으면 개발용 바이너리를 가져오지 말고 헤드리스 경로를 미제공으로 기록합니다.

실패 분기

한 경로만 실패하면 성공한 경로의 설정을 복제하기 전에 연결·인증 사례로 실패 지점을 분류합니다. 호스트 신원 경고는 신원 사례에서 즉시 중지합니다.

완료 기준

각 경로의 설치 파일·연결·인증·설치 ID·사용할 기능을 직접 확인한 뒤에만 해당 경로를 검증됨으로 기록하십시오.

제공된 구성요소 확인

플랫폼마다 전달 목록의 설치 파일 이름·서명·지원 버전·연결 방식을 확인하십시오. 설치 후에는 서버 신원, 인증 세션, 일치하는 고객·설치 ID를 기록합니다. 해당 플랫폼의 설치 파일이나 헤드리스 클라이언트가 목록에 없다면 다른 패키지를 사용하기 전에 공급자가 제공하는 지원 경로를 확인하십시오.

상세 시나리오: GUI만 연결되는 상황

Mac의 PackrGUI가 같은 설치 ID를 보여 주지만 서버 자동화 작업은 접속하지 못한다고 가정합니다. GUI의 인증 계정, 토큰 유효기간, 네트워크 경로는 자동화 서비스의 것과 다를 수 있습니다. GUI 화면을 캡처해 헤드리스 인증 성공으로 제출하지 마십시오. 헤드리스가 해당 릴리스의 제공 목록에 있는지부터 확인하고, 있다면 그 경로의 계정·주소·거부 사유를 별도로 기록합니다.

반대로 헤드리스 상태 조회가 성공해도 GUI 화면이 열리고 현재 세션에 같은 권한이 있는지 알 수 없습니다. 두 경로의 마지막 확인 단계가 다르면 가장 뒤처진 경로를 정확히 표시합니다. 예를 들어 GUI는 인증·신원 일치, 헤드리스는 네트워크 도달만 확인으로 적습니다.

플랫폼별 검증 기록 양식

실증 전에는 미확인으로 적습니다. 한 칸의 성공을 다른 운영체제나 경로에 복사하지 마십시오.

운영 중 사용할 구체적인 진행 예

예를 들어 데스크톱 GUI는 정상인데 예약 자동화가 거부됩니다. GUI 사용자 세션과 자동화 서비스의 실행 위치·사용 계정·네트워크 경로·설치 범위가 각각 같은지 확인합니다. GUI의 토큰이나 키를 자동화에 복사하지 말고 해당 릴리스가 제공하는 서비스 인증 절차를 사용합니다.

이 용례를 마칠 때 대조할 기록

GUI와 헤드리스의 설치 파일·버전·인증 결과·설치 ID·허용 기능·상태 조회 결과를 한 표의 별도 행으로 남깁니다. 어느 한 경로가 미제공이면 그대로 기록하고 실제 Work 영수증은 실행한 경로에 연결합니다.

계획한 절차, 실제 수행한 동작, 확인된 결과와 남은 단계를 구분해 기록하십시오. 위 상황은 이해를 위한 예시이며 이 문서 갱신에서 고객 환경의 실행이 이루어진 것은 아닙니다.

사용 용례 색인으로 돌아가기

운영 목적

고객이 필요한 기능을 Pack 후보로 준비·검증하고, 정식 권한 담당자가 승인·사용 권한을 별도로 확인할 수 있도록 인계합니다. 기존 Pack으로 해결 가능한지 먼저 확인하며, 새로운 후보를 만들었다는 이유만으로 실행 경로를 열지 않습니다.

예시 대화

Builder 사용자가 “검증 통과 표시가 떴으니 지금 실행하겠습니다”라고 말합니다. 관리자는 “그것은 후보 검증 결과입니다. 고객 설치의 Pack 승인, 사용 권한, 계약 범위, 사전 조건을 각각 확인해야 합니다”라고 답합니다.

상태와 소유자

순서대로 진행

1. 릴리스가 Builder를 제공하는지, Builder 설치 파일의 버전·서명을 확인합니다.
2. 지원 범위 안의 요구사항을 정의하고 후보의 계약·데이터 범위·사전 조건을 작성합니다. 범위 밖 기능을 지원되는 것처럼 표시하지 않습니다.
3. Builder의 검증 결과와 결함 목록을 확인하고 후보를 수정합니다. 검증 결과의 정확한 범위만 기록합니다.
4. 승인 담당자에게 후보 ID·버전·요청 능력·검증 결과를 제출합니다. 소스 전체나 고객 데이터는 필요한 승인 경로 외로 보내지 않습니다.
5. 승인과 사용 권한이 이 고객 설치에 각각 적용됐는지 제품 상태로 확인합니다. passkey 등록이 요구된다면 릴리스가 지정한 관리자 감독 경로를 사용하며, 브라우저 왕복만으로 승인 완료를 주장하지 않습니다.
6. 실제 Work는 별도 계획·승인·사전 조건을 확인한 뒤 실행하고 영수증으로 검증합니다.

거부되었을 때

Builder 후보 사례의 검증·승인·권한·사전 조건 분기로 이동합니다. 후보를 직접 배포 디렉터리에 복사하거나 거부된 명령을 다른 계정으로 실행하지 않습니다.

완료 기준

이 용례의 준비 완료는 후보 검증과 정식 승인·사용 권한 상태가 각각 확인됨입니다. 이것은 Work 성공을 뜻하지 않습니다.

상세 시나리오: 후보는 검증됐지만 실행이 거부됨

Builder에서 후보의 구조 검증이 통과했는데 실행 버튼 또는 Work 제출이 거부됐다고 가정합니다. 이것은 곧바로 제품 고장을 의미하지 않습니다. 후보의 구조·계약 검증, 승인 주체의 판단, 설치별 사용 권한, 실행 시점의 사전 조건은 서로 다른 관문입니다. 어느 관문에서 멈췄는지 제품의 원문 상태로 분류합니다.

예를 들어 후보 검증 PASS와 승인 대기 상태가 함께 표시되면 후보 준비 완료, 실행 권한 없음으로 기록합니다. 승인된 Pack이어도 현재 고객·설치 범위나 사전 조건이 맞지 않으면 이 실행은 진행하지 않습니다. 거부 상태를 바꾸려고 후보 파일이나 정책 저장소를 직접 수정하지 마십시오.

승인 인계 양식

대괄호는 실제 제품 기록을 채우기 위한 자리입니다. 검증 PASS를 승인 상태 칸에 복사하지 마십시오.

운영 중 사용할 구체적인 진행 예

예를 들어 기존 점검 Pack의 입력을 새 대상에 맞게 변경합니다. 기존 Pack의 지원 범위를 먼저 확인하고, 필요한 후보만 새 리비전으로 생성합니다. 승인 검토를 받은 뒤 후보를 다시 수정했다면 이전 승인과 새 후보를 같은 것으로 취급하지 않습니다.

이 용례를 마칠 때 대조할 기록

후보 생성·검증, 승인, 설치별 사용 권한, 사전 조건과 Work 영수증을 각각 별도 상태로 적습니다. 인계에는 실행하지 않은 단계와 다음 권한 담당자도 포함합니다.

계획한 절차, 실제 수행한 동작, 확인된 결과와 남은 단계를 구분해 기록하십시오. 위 상황은 이해를 위한 예시이며 이 문서 갱신에서 고객 환경의 실행이 이루어진 것은 아닙니다.

사용 용례 색인으로 돌아가기

운영 목적과 시작 조건

고객이 지원되는 Pack 또는 릴리스가 지정한 시험 작업 한 건을 제품의 통제된 경로로 실행하고, 같은 설치·Work ID의 최종 결과와 영수증을 확인합니다. 서비스 준비, 인증된 연결, 관리자 범위, 현재 런타임 바인딩이 먼저 확인돼야 합니다.

예시 상황

운영자가 “Qwen이 바인딩됐으므로 첫 Work가 끝났습니다”라고 보고합니다. 검토자는 “Work ID, 실행 승인, 모델 호출, 결과 검증, 영수증이 같은 작업에 연결됐습니까?”라고 확인합니다. 아직 Work를 제출하지 않았다면 보고할 수 있는 상태는 런타임 준비까지입니다.

단계별 확인표

실제 진행 순서

1. 승인된 대상 한 건을 고르고 실행 계획·대상 환경을 확인합니다. Builder 후보를 승인 Pack으로 취급하지 않습니다.
2. 고객이 허용한 사용자 승인 경로를 완료합니다. passkey 등록·브라우저 복귀·실제 Work 승인은 서로 다른 단계입니다.
3. Work 제출 후 제품이 기록한 ID를 확보하고, 그 ID의 승인·시작·실행 상태를 순서대로 읽습니다.
4. 로컬 AI 모델을 사용한 경우, 일반적인 모델 응답이 아니라 그 Work에 연결된 호출을 확인합니다.
5. 결과 검증, 실패·롤백 여부, 최종 영수증을 같은 릴리스·설치·Work ID에 결합합니다. 실패·중단·롤백은 성공으로 바꾸어 쓰지 않습니다.
6. 영수증이 없으면 영수증 부재 사례의 마지막 확인 상태부터 조사합니다. 기록을 수동으로 생성하지 않습니다.

승인된 설치에서만 사용하는 조건부 CLI 예시

전달받은 릴리스가 packrctl과 CREATE_AUDIT_ARTIFACT 작업을 제공한다면, 이 Work 한 건의 승인과 어플라이언스의 권한·사전 조건을 확인한 뒤에만 아래 예시를 사용하십시오. 키는 승인받은 미사용 값으로 바꿉니다. 이 작업은 로컬 감사 산출물을 만들며 첨부 고객 문서를 감사하거나 Qwen 모델을 호출하지 않습니다.

packrctl work run CREATE_AUDIT_ARTIFACT "create audit artifact" \
  "REPLACE_WITH_ONE_UNUSED_APPROVED_KEY" --json > work-run.json
# 반환된 result.work.work_id를 복사합니다. Work ID를 만들지 마십시오.
packrctl work show "PASTE_RETURNED_WORK_ID" --json > work-show.json

반환 기록에서 타입 결과·최종 상태·검증·영수증 참조·사람의 최종 인수 상태를 따로 확인하십시오. 종료 코드나 JSON 파일 생성만으로 성공 영수증이 되지 않습니다. 결과가 불확실하면 work run을 다시 내지 말고 원래 요청을 제품이 지원하는 경로로 대조하십시오.

지원 요청과 완료 기준

지원 요청에는 릴리스·설치·Work ID, 사용 Pack/작업의 공개 가능한 이름, 마지막 확인 단계, 최초 오류, 영수증 상태만 적습니다. 프롬프트·고객 데이터·원시 결과는 일반 티켓에 넣지 않습니다. 완료: 승인된 같은 Work의 성공 최종 상태, 검증된 결과, 영수증이 함께 확인됩니다.

상세 시나리오: 모델은 응답하지만 Work 영수증이 없는 경우

운영자가 로컬 모델의 응답을 확인하고 “첫 Work 성공”이라고 보고하려 한다고 가정합니다. 먼저 Work ID가 있는지 확인합니다. ID가 없다면 제품에 Work가 접수됐다는 증거부터 없습니다. ID가 있어도 승인, 시작, 모델 호출, 결과 검증, 최종 상태가 각각 기록됐는지 읽습니다. 모델의 일반 응답은 특정 Work에 묶인 호출을 대신하지 않습니다.

예를 들어 로컬 모델 별칭을 바꾼 뒤 GUI에는 새 BOUND가 보이지만 Work 준비는 UNKNOWN일 수 있습니다. 현재 설치가 보여 주는 권한·런타임·Work 준비 상태와 정확한 사유 코드를 기록하십시오. 필요한 준비 상태가 확인될 때까지 Work를 제출하지 말고, UNKNOWN이 계속되면 그 값을 릴리스 지원 경로로 전달하십시오. 아래 표에는 자신의 첫 Work 기록을 채웁니다.

한 건의 Work 증거표

실패·중단·롤백 결과를 영수증 파일의 존재만으로 성공 처리하지 않습니다. 문제를 전달할 때는 처음 빠진 관문을 보고하고 원문 프롬프트와 결과물은 일반 지원 요청에 포함하지 마십시오.

운영 중 사용할 구체적인 진행 예

예를 들어 승인된 읽기 작업 한 건을 계획합니다. 실행 직전 동일 설치·Pack·입력·현재 권한과 계획을 확인하고 반환된 실제 Work ID를 보관합니다. 연결 문제로 결과가 늦게 보이더라도 같은 ID의 조회 경로를 사용하며, 결과를 얻기 위해 새 Work를 중복 실행하지 않습니다.

이 용례를 마칠 때 대조할 기록

최종 상태, 후조건 검증, 결과 지문, Work 기록과 영수증이 모두 같은 실행을 가리키는지 확인합니다. 실패·롤백·대기·미확인은 각각 기록하고 모델의 독립 응답을 제품 영수증으로 대체하지 않습니다.

계획한 절차, 실제 수행한 동작, 확인된 결과와 남은 단계를 구분해 기록하십시오. 위 상황은 이해를 위한 예시이며 이 문서 갱신에서 고객 환경의 실행이 이루어진 것은 아닙니다.

사용 용례 색인으로 돌아가기

첫 후보 실습: 입력부터 인계까지

목표: 해당 릴리스가 제공한 읽기 전용 연습 Pack/후보를 새 리비전으로 준비하고 검증 결과를 읽습니다. 기존 운영 Pack을 수정하거나 서비스 변경 Work를 처음 연습으로 사용하지 않습니다. 제공된 연습 입력이 없으면 아래 목표 작성까지만 진행하고 지원 담당자에게 호환 예제를 요청합니다.

1. 해당 OS용 앱을 설치 안내대로 열고, 연결된 고객·설치·릴리스 및 Builder 역할을 확인합니다. 앱 창만 열리고 연결이 없으면 그 지점에서 멈춥니다.
2. 릴리스가 제공한 연습 후보 또는 지원 Pack을 제품의 제공된 선택/불러오기 절차로 엽니다. 화면 이름은 버전 안내를 따릅니다. 후보 ID·원본 리비전·원본 입력을 기록합니다.
3. 다음은 사람이 작성할 목표 메모입니다. JSON/API 입력 칸에 그대로 붙이지 않습니다. 목적: 합성 점검 결과 한 건 / 입력: 제공된 합성 자료 / 출력: 검토용 결과 / 변경: 고객 서비스 변경 없음 / 실패: 선언된 복구 상태 확인을 적고, 제품이 지원하는 입력 필드에 제공 템플릿의 형식으로 입력합니다.
4. 새 후보를 저장하고 제품이 반환한 실제 ID·리비전을 기록합니다. 검증 기능을 실행해 그 리비전의 결과·사유·누락 필드를 확인합니다. 저장과 검증은 별도 확인입니다.
5. 거부되면 정확히 표시된 선언만 수정하고 새 리비전을 검증합니다. 통과했다면 후보 참조, 검증 결과, 목적과 미완료 승인·사용 권한을 인계합니다. 파일이 생성됐다는 이유로 Work를 실행하지 않습니다.

예상 산출물: 제품이 반환한 후보 참조와 검증 기록입니다. SDK의 adapter.rs나 GAPE snapshot이 생성될 것으로 기대하지 않습니다. 후보를 제품이 관리한다면 임의 파일 경로를 찾아 복사하는 대신 릴리스의 내보내기 절차를 사용합니다.

다음 연습: 승인된 후보의 실제 사용은 승인·현재 사용 권한·사전 조건이 갖춰졌을 때 첫 Work 용례로 진행합니다. 검증은 통과했지만 승인이 대기라면 이번 실습은 후보 준비/인계 완료, Work 미실행으로 남깁니다. 아래 BLD 사례와 사례 H에서 상태별로 이어갑니다.

Builder를 열기 전

1. 어플라이언스 릴리스와 해당 운영체제의 Builder 패키지가 호환되고 서명·제공 목록에 포함됐는지 확인하십시오. Mac 패키지로 Windows·Linux 설치 가능성을 주장하지 않습니다.
2. 어플라이언스 준비 상태, 인증된 Builder 역할, 고객·설치 신원, 후보에 필요하다면 검증된 런타임 바인딩을 확인합니다. 로컬 소켓 연결 거부나 열린 Builder 창은 인증된 서버 연결이 아닙니다.
3. 확장하려는 기존 Pack 또는 기능을 찾습니다. 승인된 기존 Pack으로 해결되면 그 지원 경로를 사용합니다.

준비와 검증

1. 원하는 결과, 대상 환경, 허용 입력, 데이터 경계, 사전 조건과 롤백 처리를 적습니다. 예: “이 설치에 감사 산출물 한 건을 만들고, 선언된 소스만 읽고, 영수증을 남기며, 고객 서비스를 변경하지 않는다.”
2. 해당 릴리스가 제공한 Contract와 기능만 선택합니다. 입력 문서의 JSON 문법이 맞는다는 이유로 기능 식별자를 만들어내지 않습니다.
3. Builder에서 후보를 만든 뒤 제품의 후보 검증을 실행합니다. 후보 ID·리비전·검증 상태·정확한 사유·검사 규칙을 기록합니다. 선언 결함은 후보에서 수정하고 다시 검증하며 Core 정책 파일은 직접 바꾸지 않습니다.
4. 검증된 후보를 릴리스의 승인 경로로 제출합니다. 정식 Pack 승인과 고객 설치별 사용 권한을 따로 확인합니다. 릴리스의 등록·서버 검증 경로가 있을 때에만 passkey로 특정 승인의 사용자를 확인할 수 있습니다. Safari 열기와 앱 복귀만으로는 등록·승인이 증명되지 않습니다.
5. Work 전에 계획·대상·현재 권한·사전 조건을 확인합니다. 관문이 통과한 경우에만 통제된 제품 경로로 실행하고 최종 결과를 영수증과 대조합니다.

예시: 후보 검증은 통과했지만 Work가 거부됨

아래는 작성 예시이며 Builder API 입력이나 실제 영수증이 아닙니다. 설치된 릴리스의 실제 값을 넣고 검증과 거부를 분리해 기록하십시오.

릴리스: [서명 릴리스 ID]
설치: [고객이 허용한 참조]
후보: [Builder 후보 ID와 리비전]
검증: PASS (구조만)
승인: PENDING
사용 권한: NOT_CHECKED
Work: NOT_STARTED
다음 담당자: Pack 승인 담당자

후보가 감사 산출물을 선언하고 구조 검증에서 PASS를 받았는데 Work 제출은 “승인 대기”를 반환합니다. 이 상태는 후보 검증 완료 / 실행 권한 없음으로 기록합니다. 다음 조치는 승인 담당자의 몫입니다. 반복 제출, 다른 계정 사용, Pack 디렉터리로 후보 복사는 상태를 바꾸지 못합니다. 승인 후 사용 권한이 없다면 권한 담당자가 정확한 고객·설치 범위를 확인해야 합니다.

예시: 브라우저가 돌아왔지만 승인 기록이 없음

passkey 페이지가 열렸다 Builder로 돌아왔지만 Core에 동일 세션·계획·후보의 검증된 승인이 없습니다. Work는 거부 또는 대기 상태로 유지합니다. 표시된 correlation ID와 릴리스의 자격 증명 등록 상태를 확인하고, passkey 응답 원문을 지원 요청에 넣지 않습니다.

완료 증거

후보 준비는 검증된 후보와 인계 기록까지입니다. 승인된 Pack 사용에는 별도 승인·사용 권한·현재 사전 조건·실제 Work·검증 결과·일치하는 영수증이 필요합니다. 후보 거부 사례와 첫 Work 안내를 참고하십시오.

단계별 실제 사용 용례

예를 들어 주간 점검 산출물을 만드는 기존 Pack을 팀의 입력 형식에 맞게 준비한다고 가정합니다. 먼저 기존 승인 Pack의 지원 입력으로 해결되는지 확인합니다. 새 후보가 필요하면 원래 Pack 참조, 변경한 입력 선언, 후보 리비전과 검증 결과를 함께 남깁니다. 승인 담당자는 정확히 그 후보 지문을 검토하고, 운영 담당자는 현재 설치의 사용 권한과 사전 조건을 별도로 확인합니다.

증상별 확인과 복귀 확인

다음 담당자에게 넘길 최소 기록

인계 항목: 원본 Pack 참조, 후보 ID·리비전·지문, 변경 목적, 지원 플랫폼, 검증 결과, 승인 상태, 사용 권한 상태, 사전 조건, 롤백 처리와 다음 담당자. 실제 Work가 없으면 후보 준비 완료까지만 기록합니다.

도구별 문제 해결 사례 읽기

다음은 지원되는 입력·명령·권한 경계를 바탕으로 구성한 교육용 사례입니다. 제품의 실제 상태·사유와 함께 읽고, 자신의 실행 기록 없이 예시의 결과를 성공 이력으로 사용하지 않습니다. 온라인과 오프라인 환경 모두에 적용되는 확인 항목과 선택 의존성 경로에만 해당하는 항목을 구별합니다.

상세 예시 BLD-1: 브라우저 확인 후 앱에 돌아왔지만 승인 기록 없음

상황: 사용자는 passkey 페이지에서 앱으로 돌아왔으므로 후보가 승인됐다고 생각합니다. 제품에는 같은 후보·계획·세션의 검증된 승인 기록이 보이지 않습니다.

관찰을 이렇게 나눠 읽습니다.

• 브라우저 복귀: 화면 이동만 확인합니다.
• 자격 증명 등록: 개별 작업 승인은 별도입니다.
• 후보·계획: 승인 대상과 현재 값이 같아야 합니다.

확인·조치 순서:

1. 반환된 상관관계 참조와 현재 후보·계획을 제품 상태에서 대조합니다.
2. 해당 릴리스의 등록·서버 승인 확인 경로가 제공되는지 확인합니다.
3. 권한 담당자가 현재 상태를 확인하기 전에는 Work를 시작하지 않습니다.

다음 단계로 돌아갈 조건: 제품이 정확한 대상의 승인을 확인한 뒤 사용 권한·사전 조건을 별도로 대조합니다.

해결되지 않았을 때: passkey 응답 원문·다른 계정의 자격 증명으로 빈 승인 기록을 채우지 않습니다.

상세 예시 BLD-2: 실행 실패 후 일부 산출물과 롤백 상태가 남음

상황: 후보 또는 승인 Pack 작업이 실패했는데 출력 파일 일부가 보입니다. 파일 존재만으로 성공으로 보거나, 파일만 지우고 재실행하기 전에 제품의 실패·롤백 상태를 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• 파일 존재: 일부 동작의 흔적일 수 있습니다.
• Work 상태: 실패·롤백·후조건 검증을 별도로 확인합니다.
• 승인: 실패 뒤 새 실행에 그대로 적용되는지 추정하지 않습니다.

확인·조치 순서:

1. 해당 Work·계획·후보 신원과 마지막 검증 결과를 보존합니다.
2. Pack이 선언한 지원 복구 절차와 롤백 결과를 담당자가 확인합니다.
3. 현재 상태가 확인된 뒤 새 계획·권한·사전 조건을 정식 경로에서 평가합니다.

다음 단계로 돌아갈 조건: 검증된 복구 상태와 이후 승인된 실행의 결과를 구분해 기록합니다.

해결되지 않았을 때: 원본 결과 삭제·수동 성공 표시·다른 경로 실행으로 실패 상태를 숨기지 않습니다.

설치 후 도구 목록

첫 관찰 실습: 입력 준비, 실행, 결과 열기

먼저 받은 파일을 확인합니다. 승인된 snapshot과 뷰어만 받은 사람은 제공된 HTML 뷰어를 브라우저에서 열어 snapshot ID·소스 리비전·공개 등급을 읽고 노드 하나를 선택합니다. 소스나 매니페스트를 새로 만들 필요가 없습니다. 실행 파일과 승인 manifest를 받은 담당자는 아래 로컬 관찰을 진행할 수 있습니다. 일반 소스 Document나 SDK input.json을 GAPE 매니페스트로 사용하지 않습니다.

실행할 파일과 새 출력 경로 지정

gape_exe/$gapeExe는 제공된 실행 파일, manifest/$gapeManifest는 실제 승인 매니페스트의 절대 경로로 바꿉니다. 그 매니페스트가 지정한 소스 위치와 리비전도 존재해야 합니다. 새 출력의 부모 폴더만 준비하고 gape-observation-01은 만들지 않습니다. 경로를 추측해 소스 범위를 넓히지 않습니다.

gape_exe="/absolute/path/packr-gape"
gape_manifest="/absolute/path/approved-manifest.json"
gape_output="$HOME/gape-observation-01"
test -f "$gape_exe" && test -f "$gape_manifest" || exit 1
test ! -e "$gape_output" || exit 1
"$gape_exe" snapshot "$gape_manifest" "$gape_output" || exit 1
"$gape_exe" validate-snapshot "$gape_output/gape-architecture-snapshot.json" || exit 1
ls -la "$gape_output"

$gapeExe = 'C:\absolute\path\packr-gape.exe'
$gapeManifest = 'C:\absolute\path\approved-manifest.json'
$gapeOutput = Join-Path $env:USERPROFILE 'gape-observation-01'
if (!(Test-Path -LiteralPath $gapeExe -PathType Leaf) -or !(Test-Path -LiteralPath $gapeManifest -PathType Leaf)) { throw 'Executable or approved manifest missing' }
if (Test-Path -LiteralPath $gapeOutput) { throw 'Choose a fresh output path' }
& $gapeExe snapshot $gapeManifest $gapeOutput
if ($LASTEXITCODE -ne 0) { throw 'Snapshot failed' }
& $gapeExe validate-snapshot (Join-Path $gapeOutput 'gape-architecture-snapshot.json')
if ($LASTEXITCODE -ne 0) { throw 'Snapshot validation failed' }
Get-ChildItem -LiteralPath $gapeOutput

무엇을 읽나: snapshot 명령의 JSON에는 snapshot ID와 노드·관계·finding 수, execution_authority: NONE이 표시됩니다. finding 수가 0일 것이라고 가정하지 않습니다. 검사 결과와 실제 생성 파일을 보존하고, 동봉된 뷰어가 있으면 그 파일을 엽니다. 뷰어가 없다면 snapshot JSON을 편집기에서 읽습니다. HTML 파일 이름을 임의로 추측하지 않습니다.

짧은 과제: 노드 하나의 이름·소스 리비전·연결된 관계·관찰 한계를 기록합니다. 이전 snapshot과 비교하려면 두 원본을 보존하고 제공된 compare before.json after.json 명령의 지원 여부를 릴리스에서 확인합니다. 관찰 밖의 동작은 추정하지 않습니다. 내부 엔지니어링 snapshot은 외부 공유하지 않고 승인된 PUBLIC_SAFE 투영을 사용합니다.

막히면: 실행 파일 없음은 설치 준비, 소스 경로/리비전 없음은 승인 입력 준비, snapshot 검사 실패는 관찰 검사 단계로 기록합니다. 아래 GAPE-1/2로 이동하며 임의 manifest 작성으로 관찰 범위를 확대하지 않습니다.

사용할 때

연동 담당자가 제안한 작업이 어느 구성요소와 인터페이스에 의존하는지 파악할 때 사용합니다. 해당 릴리스가 GAPE 도구와 승인된 입력 매니페스트를 제공하는지 확인하십시오. 일반 소스 폴더·스크린샷·아키텍처 인포그래픽은 매니페스트가 아닙니다.

관찰 준비

1. 승인된 소스 버전, 관찰할 폴더, 제외 대상, 예상 규칙과 공유 범위를 기록합니다. GAPE 결과는 선택한 저장 버전에 대한 관찰입니다. 저장하지 않은 변경이나 실제 실행 중의 동작은 결과에 포함되지 않을 수 있습니다.
2. 구성요소 목록에 packr-gape와 승인된 매니페스트가 있다면 새 출력 폴더에서 packr-gape snapshot manifest.json new-output-folder를 실행합니다. 둘 중 하나가 없다면 지원되는 관찰 절차를 문의하십시오.
3. 해당 명령이 제공된 경우 packr-gape validate-snapshot gape-architecture-snapshot.json으로 생성 결과를 확인합니다. 이는 snapshot의 구조·출처 검사이지 실제 런타임 동작 검증이 아닙니다.
4. 승인된 오프라인 뷰어에서 노드·관계 하나를 선택하고 소스 리비전과 관찰 한계를 적습니다. 별도 Contract 또는 소유자 규칙과 대조하십시오. UNRESOLVED·STALE은 그대로 이슈로 남기며 뷰어를 고쳐 일치처럼 표시하지 않습니다.
5. 허용된 곳에는 PUBLIC_SAFE 투영만 공유합니다. 엔지니어링 입력·내부 경로·소스 위치·상세 판정은 승인된 엔지니어링 환경에 보관합니다.

실제 릴리스가 GAPE를 제공할 때의 명령 예시

아래 명령은 설치 목록에 packr-gape와 조회 권한이 있는 소스용 승인 매니페스트가 모두 있을 때만 사용하십시오. 출력 폴더는 새로 만들어야 합니다. validate-snapshot은 snapshot 검사이며 실행 중인 어플라이언스 검사가 아닙니다.

packr-gape snapshot approved-manifest.json new-observation-folder
packr-gape validate-snapshot new-observation-folder/gape-architecture-snapshot.json

실제 릴리스가 생성한 파일명이 다르면 그 이름을 사용합니다. 매니페스트 지문·소스 리비전·snapshot ID·검사 결과와 execution_authority: NONE을 기록하십시오. 실행 파일이나 승인 매니페스트가 없으면 이 경로를 중지하고 이번 릴리스에서 미제공으로 기록합니다.

예시: 도표에 어댑터 연결이 보임

운영자가 GAPE snapshot에서 PackrGUI와 연동 어댑터 사이의 관계를 봅니다. 이 관계는 STATIC_SOURCE입니다. 실제 고객 런타임은 다른 기능 구성으로 동작할 수 있고 동적 호출은 저장된 소스 관찰 범위 밖일 수 있습니다. snapshot에 표시된 정확한 소스 버전을 기록하고 담당자에게 제공된 Contract와 연결 증거를 확인하십시오. 배포 기록에 “연결됨”이나 “승인됨”이라고 쓰지 않습니다.

예시: 관찰과 예상 규칙이 다름

snapshot에 인터페이스 연관은 있지만 예상 소유자 규칙이 없거나 다른 리비전의 규칙입니다. GAPE는 UNRESOLVED 또는 STALE을 표시합니다. 매니페스트 신원·snapshot 지문·판정·정확한 리비전을 보존하십시오. 담당자가 Contract와 소스를 별도로 대조해야 하며 그림을 새로 그리는 일은 복구가 아닙니다.

완료 증거

매니페스트, snapshot 검증 결과, 선택한 투영, 리비전, 공개 등급, 관찰 한계와 미해결 판정이 기록되면 관찰이 끝납니다. 연동 등록과 Work는 별도 절차입니다. Integration Helper 또는 Contract & Document 안내로 이어가십시오.

단계별 실제 사용 용례

예를 들어 새 연동 요청 전에 담당자가 데이터가 어느 구성요소를 거치는지 검토합니다. 승인된 매니페스트의 저장 리비전을 고정하고 노드 하나와 그 관계를 추적합니다. 관찰 출처와 확인되지 않은 동적 경로를 함께 적고, 다른 리비전의 문서와 비교할 때는 두 리비전을 모두 표시합니다. 운영 장애 원인을 이 그림만으로 확정하지 않습니다.

증상별 확인과 복귀 확인

다음 담당자에게 넘길 최소 기록

인계 항목: 소스 리비전, 매니페스트 지문, snapshot 지문, 관찰 범위, 공개 등급, 선택한 노드·관계, 미해결 항목과 다음 확인 담당자. snapshot 검증 결과와 실제 런타임 증거는 별도로 기록합니다.

도구별 문제 해결 사례 읽기

다음은 지원되는 입력·명령·권한 경계를 바탕으로 구성한 교육용 사례입니다. 제품의 실제 상태·사유와 함께 읽고, 자신의 실행 기록 없이 예시의 결과를 성공 이력으로 사용하지 않습니다. 온라인과 오프라인 환경 모두에 적용되는 확인 항목과 선택 의존성 경로에만 해당하는 항목을 구별합니다.

상세 예시 GAPE-1: 코드는 변경됐지만 예전 snapshot을 검토함

상황: 담당자가 현재 설계와 다르다고 보고한 그림은 이전 저장 리비전의 snapshot입니다. 현재 소스, 승인 매니페스트와 관찰 결과의 리비전을 먼저 구별합니다.

관찰을 이렇게 나눠 읽습니다.

• 그림: 특정 snapshot ID·소스 리비전을 가집니다.
• 현재 소스: 저장되지 않은 변경은 관찰에 포함되지 않을 수 있습니다.
• 검증: snapshot 구조 검사는 런타임 검증이 아닙니다.

확인·조치 순서:

1. 매니페스트 지문·snapshot 생성 시점·정확한 저장 리비전을 대조합니다.
2. 새 관찰이 필요하면 승인된 입력과 제공된 명령으로 새 출력 폴더를 사용합니다.
3. 이전·새 결과를 함께 보존하고 변경된 관계와 관찰 한계를 표시합니다.

다음 단계로 돌아갈 조건: 현재 검토 대상 리비전과 검증된 snapshot이 맞으면 그 범위의 관찰 검토를 계속합니다.

해결되지 않았을 때: 매니페스트나 리비전이 미확인이면 그림을 고쳐 일치시키지 않고 해당 관찰을 미확인으로 남깁니다.

상세 예시 GAPE-2: 필터 또는 관찰 범위 때문에 노드가 보이지 않음

상황: 검색에서 구성요소가 나오지 않아 기능이 없다고 생각합니다. 하지만 선택한 필터·매니페스트 제외 규칙·지원 언어에 따라 표시와 관찰 범위가 달라질 수 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 검색 결과 없음: 화면의 선택 범위에 대한 결과입니다.
• 매니페스트: 관찰 폴더·제외 규칙을 정합니다.
• 구현 부재: 이 화면만으로 확정할 수 없습니다.

확인·조치 순서:

1. 검색어·필터를 확인하고 원래 관찰의 범위·리비전·제외 목록을 읽습니다.
2. 다른 범위가 필요하면 승인된 입력을 가진 담당자에게 요청합니다. 내부 자료를 공개 뷰에 추가하지 않습니다.
3. 관찰 밖·표시 필터·실제 미확인을 구별해 기록하고 필요한 소스 근거를 담당자에게 인계합니다.

다음 단계로 돌아갈 조건: 해당 리비전과 범위의 관계를 확인한 경우에만 그 관찰을 인용합니다.

해결되지 않았을 때: 소스 근거가 없으면 미구현·기능 없음으로 단정하지 않습니다.

설치 후 도구 목록

첫 준비 실습: 전체 요청 한 건을 단계별로 읽기

준비물: 버전이 맞는 Helper 실행 파일, 완전한 request.json, 공급자가 게시한 대상 참조. SDK와 Helper는 별도 실행 파일입니다. SDK의 발췌 JSON만 저장해 이 요청을 대신하지 않습니다. SDK 전체 예제를 재사용하려면 그 Helper 릴리스에서도 동일한 대상·envelope를 지원하는지 먼저 확인합니다.

1. 제공된 요청 원본을 보존하고 작업용 사본을 만듭니다. request_id, correlation_id, draft 전체와 그 안의 definition/source/mapping/fixture를 확인합니다. 실제 API 토큰은 넣지 않습니다.
2. 아래 실행 파일·요청 경로를 실제 절대 경로로 바꿉니다. helper-first-01은 새 로그 폴더입니다. 첫 명령만 실행하고 결과를 읽습니다.
3. stdout의 status, reason, lifecycle_stage, next_required_actions, 후보 지문을 확인합니다. next_action이라는 단일 필드가 있다고 가정하지 않습니다. 이 CLI는 타입 거부 결과를 출력하면서 종료 코드 0일 수 있으므로 `$LASTEXITCODE`/종료 코드만으로 다음 단계에 가지 않습니다.
4. 발견이 통과한 경우에만 기존 절의 normalize → validate → prepare → status를 각각 같은 요청 사본으로 실행합니다. 이전 명령의 JSON 결과를 다음 명령의 입력으로 바꾸지 않습니다. 각 명령은 전체 요청을 받습니다.
5. DENIED, 구현 필요, 권한 필요 또는 모르는 상태면 해당 결과를 보존하고 다음 조치를 읽습니다. 첫 연습에 r2-submit은 필요하지 않습니다. 요청을 수정할 때는 새 사본·새 로그 폴더를 사용합니다.

helper_exe="/absolute/path/packr-integration-helper"
helper_request="/absolute/path/request.json"
helper_logs="$HOME/helper-first-01"
test -f "$helper_exe" && test -f "$helper_request" || exit 1
test ! -e "$helper_logs" || exit 1
mkdir "$helper_logs" || exit 1
"$helper_exe" r2-discover "$helper_request" > "$helper_logs/01-discover.json" 2> "$helper_logs/01-discover.stderr.txt"
helper_exit=$?
cat "$helper_logs/01-discover.json"
cat "$helper_logs/01-discover.stderr.txt"
# helper_exit와 JSON의 status/reason을 별도로 기록합니다.

$helperExe = 'C:\absolute\path\packr-integration-helper.exe'
$helperRequest = 'C:\absolute\path\request.json'
$helperLogs = Join-Path $env:USERPROFILE 'helper-first-01'
if (Test-Path -LiteralPath $helperLogs) { throw 'Choose a fresh log folder' }
New-Item -ItemType Directory -Path $helperLogs -ErrorAction Stop | Out-Null
& $helperExe r2-discover $helperRequest 2> (Join-Path $helperLogs '01-discover.stderr.txt') | Out-File -LiteralPath (Join-Path $helperLogs '01-discover.json') -Encoding utf8
$helperExit = $LASTEXITCODE
Get-Content -LiteralPath (Join-Path $helperLogs '01-discover.json') -Raw -Encoding UTF8
Get-Content -LiteralPath (Join-Path $helperLogs '01-discover.stderr.txt')

위 파일은 로그이며 그 자체를 새 요청으로 제출하지 않습니다. 후속 결과도 02-normalize, 03-validate, 04-prepare, 05-status처럼 구분해 저장합니다. 예상 연습 결과는 단계 판정과 후보 준비 기록이며 실제 API 연결·등록·Work가 아닙니다. 게시된 대상이 없다면 TARGET_NOT_PROVIDED는 담당자의 진행 기록으로 쓰고, 제품이 실제 출력한 reason과 구분하십시오. 아래 IH-1/2에서 거부와 인계 예를 확인합니다.

입력과 담당자

후보 준비

1. 지원되는 소스 형식으로 읽기 전용 작업부터 설명합니다. 예: status.read의 입력 service 문자열과 출력 service·healthy. 실제 토큰이나 고객 응답은 문서에 붙여넣지 않습니다.
2. 공급자가 게시한 대상 Contract·어댑터 리비전을 확보합니다. 없으면 TARGET_NOT_PROVIDED로 기록하십시오. 비슷해 보이는 표시 이름은 유효한 대상 매칭이 아닙니다.
3. 해당 릴리스가 제공한 완전한 요청 파일을 사용합니다. 포함된 Helper가 r2-discover, r2-normalize, r2-validate, r2-prepare, r2-status를 제공한다면 request.json으로 이 순서대로 진행합니다. 매 단계의 상태·사유·다음 조치를 보존하십시오.
4. 실제 결과가 거부한 필드 또는 매핑만 고칩니다. 제한된 예시 형식은 기본 자료형과 명시적 매핑을 지원합니다. 지원되지 않는 변환이나 매핑되지 않은 필수 필드는 계속 거부됩니다. REQUIRES_IMPLEMENTATION scaffold에는 실제 어댑터 구현이 추가로 필요합니다.
5. 릴리스의 승인된 제출 경로에서만 r2-submit을 사용합니다. 신뢰된 등록 전송 경로가 없는 CLI는 REQUIRES_AUTHORITY를 반환합니다. 정식 등록에는 정확한 후보·목적에 묶인 별도의 유효한 승인이 필요합니다. 등록되어도 Work 바인딩·승인이 자동으로 생기지 않습니다.

재현 가능한 로컬 준비 예시

전달 목록에 Helper 실행 파일과 버전에 맞는 완전한 request.json이 있다면 아래 단계를 하나씩 실행합니다. 각 JSON에서 status·reason·단계·다음 조치를 읽고 진행하십시오. 셸 종료 코드만으로 통과를 판단하지 않습니다. 요청에는 위의 status.read 설명 대신 릴리스가 제공한 지원 대상 참조가 필요합니다.

packr-integration-helper r2-discover request.json > 01-discover.json
packr-integration-helper r2-normalize request.json > 02-normalize.json
packr-integration-helper r2-validate request.json > 03-validate.json
packr-integration-helper r2-prepare request.json > 04-prepare.json
packr-integration-helper r2-status request.json > 05-status.json

판정 예시: 발견 결과가 status=PASSED, reason=NONE, lifecycle_stage=DISCOVERED라도 정규화가 DENIED / CONTRACT_INCOMPATIBLE을 반환할 수 있습니다. 두 결과를 모두 보존하고 prepare 전에 멈춰 게시된 올바른 대상을 확보하십시오. 앞 단계가 거부됐는데 다섯 명령을 무조건 연속 실행하지 마십시오.

예시: 소스는 통과, 대상은 거부

합성 status.read 문서에 대해 r2-discover가 status=PASSED, reason=NONE, lifecycle_stage=DISCOVERED를 반환합니다. 게시된 대상이 묶이지 않아 r2-normalize는 DENIED / CONTRACT_INCOMPATIBLE을 반환합니다. 소스 문서 구조는 받아들여졌지만 연동은 준비되지 않았습니다. 공급자 또는 연동 담당자에게 정확한 대상 참조를 요청하십시오. Contract ID를 임의로 만들거나 표시 이름만 맞춰 통과시키지 않습니다.

예시: 후보 제출 후 등록되지 않음

검증된 후보의 제출 결과가 REQUIRES_AUTHORITY입니다. 후보 지문과 요청한 승인 목적을 기록합니다. 권한 담당자가 정확한 후보를 native 등록 경로에서 평가해야 합니다. CLI 반복 실행이나 옵션 추가로 준비 상태를 등록으로 바꿀 수 없습니다.

완료 증거

입력·대상 리비전, 요청 신원, 단계별 타입 결과, 후보 지문, 미해결 문제와 다음 담당자가 기록되면 준비 단계가 끝납니다. 실제 제공자 연결·등록·바인딩·승인된 Work·영수증에는 각각 별도 증거가 필요합니다. 소스 선언은 Contract & Document를 참고하십시오.

단계별 실제 사용 용례

예를 들어 서비스 상태를 읽는 소스 Document와 공급자가 게시한 대상 참조를 연결합니다. 첫 시도는 합성 데이터로 준비하고 단계마다 상태·사유·다음 조치를 읽습니다. 정규화가 거부되면 그 뒤 prepare·submit으로 넘기지 않습니다. 입력을 고쳤다면 요청 리비전과 지문을 새로 기록하여 이전 거부와 새 결과를 구별합니다.

증상별 확인과 복귀 확인

다음 담당자에게 넘길 최소 기록

인계 항목: 전체 요청 지문, 소스·대상 리비전, 요청·상관관계 ID, 각 단계의 타입 결과, 후보 지문, scaffold의 구현 필요 여부, 제출·등록 상태와 다음 담당자. 실제 API 연결 시험은 준비 결과와 구분합니다.

도구별 문제 해결 사례 읽기

다음은 지원되는 입력·명령·권한 경계를 바탕으로 구성한 교육용 사례입니다. 제품의 실제 상태·사유와 함께 읽고, 자신의 실행 기록 없이 예시의 결과를 성공 이력으로 사용하지 않습니다. 온라인과 오프라인 환경 모두에 적용되는 확인 항목과 선택 의존성 경로에만 해당하는 항목을 구별합니다.

상세 예시 IH-1: 발견은 통과했지만 대상 정규화가 거부됨

상황: 합성 소스 Document의 read_quality는 발견됐지만 전체 요청은 다른 Contract·어댑터 리비전을 가리킵니다. 발견 PASS 뒤 prepare까지 무조건 실행하면 첫 거부를 놓칩니다.

관찰을 이렇게 나눠 읽습니다.

• 발견: status=PASSED, reason=NONE, lifecycle_stage=DISCOVERED는 소스 발견 결과입니다.
• 정규화: DENIED / CONTRACT_INCOMPATIBLE은 대상 호환 거부입니다.
• 후보 준비: 아직 완료되지 않았습니다.

확인·조치 순서:

1. 정규화의 상태·사유·다음 조치를 보존하고 후속 prepare·submit을 멈춥니다.
2. 공급자가 게시한 정확한 대상과 전체 요청의 참조를 대조합니다. 이름만 비슷한 대상을 고르지 않습니다.
3. 지원되는 참조를 확보한 뒤 수정 요청의 리비전·지문을 보관하고 영향을 받은 단계부터 검사합니다.

다음 단계로 돌아갈 조건: 해당 요청이 정규화·의미 검증을 통과한 뒤에만 후보 준비 결과를 확인합니다.

해결되지 않았을 때: 게시된 대상이 없으면 ID·스키마 지문을 만들어 맞추지 않고 대상 미제공으로 인계합니다.

상세 예시 IH-2: prepare 산출물은 있지만 제출이 권한을 요구함

상황: 후보 준비 결과가 만들어졌지만 CLI 제출은 REQUIRES_AUTHORITY를 반환합니다. 로컬 후보 파일을 서버 등록 위치에 복사하면 해결되는 문제가 아닙니다.

관찰을 이렇게 나눠 읽습니다.

• prepare: 후보 준비 결과입니다.
• submit: 신뢰된 등록 경로·정확한 승인 목적을 요구합니다.
• Work: 등록·바인딩·실행은 별도입니다.

확인·조치 순서:

1. 후보 지문과 제출 결과·요청·상관관계 ID를 보존합니다.
2. 해당 릴리스가 실제 등록 전송 경로와 담당자를 제공하는지 확인합니다.
3. 정확한 후보·목적·고객·설치 범위에 대한 승인된 등록 절차로 인계합니다.

다음 단계로 돌아갈 조건: 등록 담당자의 실제 결과를 확인한 경우에만 등록으로 기록하고 Work는 따로 확인합니다.

해결되지 않았을 때: CLI 반복 제출이나 자격 증명 복사로 준비 상태를 등록 상태로 바꾸지 않습니다.

설치 후 도구 목록

첫 문서 실습: 파일 저장부터 Helper 인계까지

목표: 아래의 완전한 소스 Document를 quality-document.json으로 저장하고 문법을 확인합니다. 이 파일은 소스 선언만 담습니다. SDK/Helper의 전체 요청이나 GAPE 매니페스트가 아닙니다.

1. 조직이 허용한 새 작업 폴더를 만들고 텍스트 편집기를 엽니다. 아래 JSON 블록의 {부터 마지막 }까지만 복사합니다. 코드 울타리와 json 표시는 파일에 넣지 않습니다.
2. 파일 이름을 quality-document.json, 인코딩을 UTF-8로 저장합니다. Word/서식 문서 형식이 아닌 일반 텍스트를 사용하고 .json.txt가 붙지 않았는지 확인합니다. 저장한 파일을 다시 열어 operations.read_quality가 있는지 읽습니다.
3. macOS/Linux에 Python 3가 이미 준비돼 있다면 아래 명령을 사용합니다. Windows는 PowerShell의 내장 JSON 파서를 사용할 수 있으므로 이 실습 때문에 Python 설치가 필수는 아닙니다.
4. 문법 통과 후 properties의 resource/component/score와 각 required 목록을 대조합니다. 이 검토와 JSON 파싱은 제품의 의미 검증을 대신하지 않습니다.
5. 원본 사본을 보존한 뒤 공급자가 제공한 전체 요청의 draft.source에 문서 객체를 넣습니다. 파일 경로 문자열이나 JSON을 이중 인코딩한 문자열을 넣지 않습니다. 대상 참조·매핑·fixture는 제공된 요청에서 별도로 확인하고 Helper 첫 준비 실습으로 이동합니다.

document_path="/absolute/path/quality-document.json"
python3 -m json.tool "$document_path"

$documentPath = 'C:\absolute\path\quality-document.json'
Get-Content -LiteralPath $documentPath -Raw -Encoding UTF8 -ErrorAction Stop | ConvertFrom-Json -ErrorAction Stop | Format-List
Get-FileHash -LiteralPath $documentPath -Algorithm SHA256

기대 결과: JSON 파서는 객체를 표시하고 파싱 오류를 내지 않습니다. 문법 오류라면 줄/열과 쉼표·따옴표·중괄호를 확인합니다. 이 파서는 중복 키나 제품 미지원 스키마 전체를 판정하지 않습니다. 문법 확인 완료 / Helper 의미 검증 미실행으로 기록하고, 실제 Helper 결과가 나왔을 때 별도 추가합니다.

작은 수정 연습: 새 사본에서 입력 이름을 바꾸려면 properties, required, 요청의 명시적 매핑과 지원 대상 영향을 함께 검토합니다. 처음에는 제공된 원본으로 한 번 확인한 뒤 바꾸십시오. DOC-1/2 사례는 이름 불일치와 전체 요청 누락을 다룹니다.

수정 중인 산출물 구분

범위가 정해진 소스 Document 작성

1. 짧은 목표와 데이터 경계를 적습니다. 예: read_quality는 리소스 이름을 받아 구성요소 이름과 품질 점수를 문자열로 반환합니다. 리소스를 변경하지 않습니다.
2. 지원되는 CUSTOM_API 형식에서 document_kind는 CUSTOM_API, protocol_revision은 지원되는 값으로 하고 operations 아래에 read_quality를 둡니다. input_schema는 필수 resource 문자열을 가진 object, output_schema는 필수 component와 score 문자열을 가진 object로 선언합니다. 문장 속 필드 이름은 설명이며 완전한 JSON 파일이 아니므로 구두점과 중첩은 아래의 완전한 예시를 사용하십시오.
3. 속성 이름과 required 목록을 일치시킵니다. 제한된 예시는 지원되는 기본 자료형만 받습니다. 중첩 object·배열·추가 JSON Schema 키워드·중복 키·주석이 묵시적으로 허용되지는 않습니다. 자격 증명이나 실제 운영 응답을 schema의 기본값·설명에 넣지 않습니다.
4. 로컬 사본에서 앞의 OS별 파서 명령으로 JSON 문법을 확인합니다. 문법 PASS는 JSON 파싱만 증명합니다. 수정할 때 원본과 지문을 보존합니다.
5. 공급자가 게시한 정확한 기능·Contract·어댑터·작업·리비전 식별자를 확보합니다. 이 참조는 독립 소스 Document가 아니라 릴리스가 정한 요청 envelope에 넣습니다. 이후 Integration Helper 준비 절차를 따릅니다.

완전한 소스 Document 예시

아래 CUSTOM_API 예시는 읽기 전용 read_quality 작업을 선언합니다. 실제 API를 호출하거나 제품 Contract를 만들지 않습니다. JSON을 quality-document.json으로 저장하고 해당 릴리스가 제공한 완전한 요청의 draft.source에 넣은 뒤 호환되는 지원 대상 참조를 지정하십시오.

{
  "document_kind": "CUSTOM_API",
  "protocol_revision": "1",
  "operations": {
    "read_quality": {
      "input_schema": {
        "type": "object",
        "properties": {"resource": {"type": "string"}},
        "required": ["resource"]
      },
      "output_schema": {
        "type": "object",
        "properties": {
          "component": {"type": "string"},
          "score": {"type": "string"}
        },
        "required": ["component", "score"]
      }
    }
  }
}

python3 -m json.tool quality-document.json > /dev/null
sha256sum quality-document.json

첫 명령은 JSON 문법만 확인합니다. macOS는 shasum -a 256 quality-document.json, Windows PowerShell은 Get-FileHash -Algorithm SHA256 quality-document.json을 사용하십시오. 완전한 envelope·대상·매핑의 적합성은 Helper의 타입 판정으로 별도 확인해야 합니다.

예시: JSON은 유효하지만 대상 리비전이 다름

소스 Document가 파싱되고 발견 단계에서 read_quality가 받아들여졌지만 요청은 다른 릴리스의 어댑터 리비전을 참조합니다. 정규화 단계는 대상을 거부합니다. 릴리스 매니페스트와 공급자 참조를 대조하고, 승인된 호환 값이 실제로 있을 때만 새 요청의 대상 리비전을 바로잡습니다. 소스 작업 이름만 바꿔 우연히 맞추면 불일치를 숨기게 됩니다.

예시: 필드 이름만 바꾸고 required를 그대로 둠

편집자가 입력 속성 resource를 resource_name으로 바꾸고 required: ["resource"]는 그대로 둡니다. JSON 문법은 유효하지만 선언 의미가 일치하지 않습니다. 속성을 되돌리거나 required 목록을 고친 뒤 같은 로컬 파서와 Helper 검증을 다시 수행하십시오. 문법 검사 통과를 Contract 검증으로 해석하지 않습니다.

완료 증거

소스 Document의 리비전·지문, 게시된 대상 참조, 요청 신원, 타입이 정해진 Helper 결과와 남은 승인 담당자를 보관합니다. 실제 인증·등록·런타임 증거 전에는 “연결됨”, Work와 영수증 전에는 “실행됨”이라고 표시하지 않습니다.

단계별 실제 사용 용례

예를 들어 읽기 전용 품질 조회에 출력 필드 하나를 추가하려고 합니다. 사람용 목표, 소스 스키마, 대상 참조와 전체 요청 envelope를 각각 구분합니다. 출력 속성과 required 목록, 실제 합성 응답, 명시적 매핑을 함께 검토하고 지원되지 않는 스키마 확장은 그대로 별도 구현 요구로 남깁니다. 제품이 발행한 Contract를 고객 문서로 대체하지 않습니다.

증상별 확인과 복귀 확인

다음 담당자에게 넘길 최소 기록

인계 항목: 소스 Document 리비전·지문, 요청 envelope 리비전, 게시된 Contract·어댑터 참조, 매핑 규칙, 합성 입력·예상 출력, 문법·의미 검증 결과와 변경 이유. 실제 값이 없는 템플릿과 실행 가능한 전체 요청을 구분합니다.

도구별 문제 해결 사례 읽기

다음은 지원되는 입력·명령·권한 경계를 바탕으로 구성한 교육용 사례입니다. 제품의 실제 상태·사유와 함께 읽고, 자신의 실행 기록 없이 예시의 결과를 성공 이력으로 사용하지 않습니다. 온라인과 오프라인 환경 모두에 적용되는 확인 항목과 선택 의존성 경로에만 해당하는 항목을 구별합니다.

상세 예시 DOC-1: 속성 이름만 바꾸고 required는 그대로 둠

상황: 입력 속성 resource를 resource_name으로 바꿨지만 required에는 resource가 남아 있습니다. JSON 문법 검사는 통과해도 선언의 의미는 일치하지 않습니다.

관찰을 이렇게 나눠 읽습니다.

• 문법: JSON 파싱은 가능합니다.
• 선언: properties와 required가 다른 이름을 가리킵니다.
• 대상·매핑: 소스 변경의 영향을 따로 확인해야 합니다.

확인·조치 순서:

1. 전체 소스 Document와 원본 리비전·지문을 보존합니다.
2. 실제 의도한 입력 이름을 정하고 속성·required·명시적 매핑을 지원 범위 안에서 맞춥니다.
3. 로컬 JSON 문법과 Helper 의미 검증을 각각 수행하고 결과를 구분합니다.

다음 단계로 돌아갈 조건: 문법과 의미 검증이 모두 확인된 새 요청을 후속 준비에 사용합니다.

해결되지 않았을 때: 지원되지 않는 스키마 확장은 임의로 허용하지 않고 추가 구현 요구로 남깁니다.

상세 예시 DOC-2: 소스 Document 발췌를 전체 요청으로 실행함

상황: 사용자는 안내서의 짧은 CUSTOM_API 예시만 저장해 Helper 또는 SDK 입력으로 보냅니다. 소스 설명은 맞지만 요청·대상·매핑·합성 응답을 포함한 전체 envelope는 아닙니다.

관찰을 이렇게 나눠 읽습니다.

• 소스 Document: draft.source에 들어갈 자료입니다.
• 전체 요청: request_id·correlation_id·draft와 지원 참조가 필요합니다.
• 발췌: 필드를 설명하는 예시이며 바로 실행 가능한 전체 입력이 아닙니다.

확인·조치 순서:

1. 제공된 버전에 맞는 전체 요청 템플릿을 확보하고 원본을 보존합니다.
2. 소스·대상·매핑·합성 응답을 각각의 정해진 위치에 채웁니다. 비밀값·실제 고객 응답은 넣지 않습니다.
3. 문법 확인 뒤 제품의 analyze 또는 Helper 단계 판정으로 의미를 확인합니다.

다음 단계로 돌아갈 조건: 완전한 요청과 게시된 대상이 지원 범위 안에서 검증됐을 때 후보 준비로 진행합니다.

해결되지 않았을 때: 필수 대상 참조가 없으면 설명용 값을 실제 식별자로 추측해 사용하지 않습니다.

설치 후 도구 목록

Navigate: Installation and first use · Post-install tools · Use cases · Troubleshooting cases

First installation: choose your starting point

You do not need to install every tool in sequence. Choose one goal below. Only a browser is needed to read this page. SDK synthetic exercises do not require an appliance account, customer activation or a live API connection.

Find each tool in the post-install tool index. Install a tool when its step needs it. Live connection, registration and Work require the release's separately authorized route.

Ten-minute preparation: computer and supplied files

1. Identify the installation target. VM images belong on the server; PackrGUI and Builder run on the workstation. SDK can run portably on the integration workstation. A Document is JSON data, not a separate application installer.
2. Check OS and CPU using the read-only commands below. arm64/aarch64 and x86_64/AMD64 require different packages. Current recorded SDK combinations are macOS ARM64, Debian 13 AMD64 and Windows AMD64; another Linux distribution or Windows ARM is not the same combination.
3. Check the supplied inventory for the main program, optional dependencies, examples, version, digest, signature status and native prerequisites. The SDK Rust set is optional; it does not change the connected environment's default.
4. Choose a fresh workspace. Separate original archives, extracted programs, editable inputs and per-run results. Use an organization-approved private folder; preserve existing directories.
5. For connection-dependent routes obtain the required profile from your administrator. An address alone is insufficient: obtain account/device enrollment instructions, expected organization/installation identity, TLS server name and support route.

# macOS Terminal only
sw_vers
uname -m
# Linux terminal only
cat /etc/os-release
uname -m

# Windows PowerShell
$PSVersionTable.PSVersion
(Get-CimInstance Win32_OperatingSystem).Caption
(Get-CimInstance Win32_ComputerSystem).SystemType

Choose the procedure by file type

Generic .pkg/.exe/.deb names later in this guide only illustrate hashing. Do not look for the SDK under those names. In this local operator edition the current SDK packages table links the actual archives and digests. Other components need their own release inventory. Do not assume a portal, download URL or signature status exists.

Before copying a command

• Use bash examples in macOS Terminal/Linux shells and powershell examples in Windows PowerShell. Prompts such as $ or PS C:\> are not part of commands.
• Replace /absolute/path/..., C:\absolute\path\... and bracketed fields with your actual supplied values first. Keep the quotes, especially for spaces. Do not interchange Unix ./bin/... and Windows .\bin\... paths.
• Variables such as install_root and $installRoot exist only in the shell where you initialized them. A new terminal requires the resume instructions below. Check folder spelling, case and accidental .json.txt extensions.
• Run one step at a time and inspect the result, even inside a command block. Expected output in this guide is not an execution record. Stop subsequent commands when a step fails.
• Preserve original examples and save copies as UTF-8. PowerShell 5.1's default > or Out-File may write UTF-16. Use a UTF-8 editor for input JSON and check its save encoding.

Understand the folder layout

VibePackr-SDK-install-01/
  sdk/             extracted program; bin, docs, examples
  dependencies/    optional set; retain as verification input
  inputs-02/       editable complete input.json copy
  runs/
    custom-01/     created after the first successful run
    mcp-01/        separate MCP result
    custom-api-candidate-02/  new result for modified input

This is a layout illustration; SDK sections contain creation commands. Prepare the runs parent, then let the SDK create final candidate directories such as custom-01. GAPE also uses a fresh output path. Helper log directories and product-managed Builder candidates are separate.

Record progress and resume later

Record installation, connection, candidate generation and real Work separately. At the end of each exercise save the date, tool version/path, input digest, actual command or UI action, result location, last successful step and next owner. Troubleshooting starts with this record.

On resuming, preserve archives and results. The SDK guide shows how to restore path variables; select absolute input/output paths again for other tools too. If execution is uncertain, query the existing Work/request ID before acting; a new submission is not a way to resolve a possibly duplicated operation. Use the troubleshooting index for the blocked step.

How to use this guide

This guide helps customer operators proceed from receiving files to checking the first Work result. Product status and the signed manifest for the exact release are authoritative. Examples and generic operating-system commands do not override product refusals or release instructions.

• Audience: appliance installation administrator, PackrGUI user, and optionally Builder operator. Installation, permission grants, and Pack approval may have different owners.
• Before you begin: the release delivery inventory and signature instructions, supported-environment list, authority to install in your organization, network and authentication details, and the release support route. Never attach passwords or private keys to a support request.
• Completion condition: separately confirm file verification, service readiness, administrator scope, authenticated connection, validated runtime binding, authorized actual Work, and its result and receipt for the same release and installation. Success at one step does not establish success at the next.
• Stop condition: stop before the next step if a file digest or signature differs, the host identity is unexpected, the customer or installation identity differs, permission is denied, or state integrity is warned about. Record the original message and time, then use the release support route.

1. Check the delivery and target environment

1. For a release with a published official portal, begin at setup.vibepackr.com. For offline setup, open the delivered Start_Setup.html. Confirm that the portal and offline page name the same release and component inventory. Distinguish a portal outage from an appliance problem.
2. Check the delivery inventory for the appliance image, PackrGUI for your operating system, and the actual availability of optional Enterprise Pack Builder and Additional Packs. A component shown on an introduction page must not be installed unless the release inventory includes it.
3. Compare the received files with the version, platform, and SHA-256 values in the release manifest, then verify signatures using the supplied official procedure. A digest detects changed bytes but does not replace signature verification. Generic file-hash examples are shasum -a 256 filename on macOS, sha256sum filename on Linux, and Get-FileHash -Algorithm SHA256 filename in Windows PowerShell. Follow your shell's quoting rules for filenames with spaces.
4. Check the release compatibility list for the supported cloud or virtualization target, CPU architecture, memory and disk, network and authentication path, and runtime. If you plan to use a local 7B model, check its execution resources separately. Use the supplied compatibility list for minimum requirements.
5. Record the release ID, filenames and digests, image identity, target platform, and verification result. Do not rename a mismatching file to make it appear valid or substitute another platform's package.

Continue when: the exact delivered files have matching signatures and digests and the target environment is supported.

Worked file check on the receiving workstation

Use the filename and expected SHA-256 from this release's signed inventory. These are read-only operating-system commands. Replace the example filename with the received file and complete the release's signature verification separately. Do not use a digest copied from an older guide.

# macOS Terminal
shasum -a 256 "VibePackr-installer-for-this-platform.pkg"
# Linux shell
sha256sum "VibePackr-installer-for-this-platform.deb"

# Windows PowerShell
Get-FileHash -Algorithm SHA256 "VibePackr-installer-for-this-platform.exe"

Example decision: the manifest says A1... while the local command prints B2.... Stop before installation, retain the exact filename and two digests, and ask the delivery owner for a corrected signed file. Renaming the file does not change its digest.

2. Deploy a new appliance in the customer environment

1. Deploy a new instance from the signed appliance image supplied for your release. Do not substitute an image from another version or copy an existing VM as an installer.
2. Allow first boot to finish. Running in a cloud console means the VM is powered on. Confirm product service readiness separately in product status or the release diagnostic. During initialization, follow the official wait and status procedure instead of repeatedly attempting connections.
3. Record the newly generated installation identity, customer organization, service endpoint, and connection method. If two independent instances display the same installation or host identity, stop use and investigate the clone state.
4. Compare the host identity displayed on first administrator or client connection against the release's official verification route. Do not reuse an earlier VM's key for a new VM or ignore an identity warning.

Continue when: first boot has finished, the product service reports ready, and the unique installation identity and authenticated access route are confirmed.

3. Register the first administrator and allowed scope

1. Open the Customer Setup UI inside the customer environment or the administrator procedure named by the release. An operating-system login alone does not create the product's Appliance Administrator authority.
2. Have the actual administrator confirm the customer, installation, and supported runtime scope, then finish enrollment using the product's required method. Automatic binding operates inside that approved scope. It does not approve every possible environment change.
3. Confirm the minimum observation and runtime-binding permissions, target, and validity period in product status. Stop if the account name is right but the customer or installation identity differs.
4. If the release requires interactive terminal input, do not pipe copied commands through a non-interactive remote script. The administrator must confirm directly in the designated local wizard or interactive session.
5. Read administrator status again after enrollment. If storage access or Permission denied occurs, do not repair ownership, permissions, or lock files by hand. Send the exact error through the release support route.

Continue when: the product confirms the administrator role, allowed scope, and validity period for this installation.

4. Discover and automatically bind a local runtime

1. Prepare a local runtime and model supported by your release. For example, if the supplied compatibility list includes Ollama and a Qwen model, confirm their versions and resource requirements. Do not treat the example as a default model for every installation.
2. Distinguish detected → validated → bound in the Packr or PackrGUI setup wizard. Core applies a binding only after validating the observed installation, customer, and runtime identity against administrator scope. A model file or running runtime process alone is not a binding.
3. Check the current binding's runtime type, model reference, installation identity, status, and recorded time. A binding does not establish that inference or Work ran.
4. After replacing or restarting the runtime, or changing a model alias, wait for a fresh observation and confirm the product's new validated binding. Do not use an old binding screen as proof of the new runtime.
5. For an out-of-scope change or ambiguous model selection, use the administrator action shown by the wizard. Do not edit product storage or force reuse of a prior binding.
6. For offline operation, confirm that the model is already local and the release's local-only network configuration is effective. Check your network policy and actual communication record before concluding that no external traffic occurred.

Continue when: the product shows a validated binding for the supported runtime and model on this installation.

5. Connect PackrGUI, headless clients, and Builder

1. Install PackrGUI for your operating system as named by the release manifest. macOS, Windows, and Linux packages are not interchangeable. If your operating system displays a security warning, check the signature and supplied installation instructions; do not bypass its security checks.
2. Connect to the customer appliance through the address, network, and authentication route named by the release. Separately confirm that the server responds, authentication succeeds, and customer and installation identities match in product status. An open window does not prove an authenticated connection.
3. If you operate without a GUI, check the release's headless CLI or service route separately. A successful GUI connection does not prove headless readiness or Work authority.
4. Install Enterprise Pack Builder only when it is an actual component of this release, following its separate installer and permission guide. Builder helps prepare and validate Pack candidates. Creating a candidate does not approve, entitle, or execute a Pack.
5. If the release requires Safari web passkey verification, use the official HTTPS origin and supervised enrollment procedure. Passkey enrollment and approval for each Work are different actions. A browser opening or returning to the app does not itself prove Core approval. Never borrow another account's credential after a refusal.

For the next tasks after connection, use the post-install tools guide. It explains where to install and how to use Builder, GAPE, Integration Helper, SDK Engine, and Contract & Document. It also includes the Non-SI architecture diagram.

Continue when: the product confirms authentication, installation identity, and permitted functions for each client route you plan to use.

6. Run the first Work and inspect its receipt

1. Select a supported Pack or test Work named by the release. Check its contract, scope, preconditions, approval, and entitlement before execution. Do not run a Builder candidate as though it were an approved Pack.
2. Review the product's execution plan and target environment, then run one Work through the customer-authorized path. Actual Work is a separate step from installation, connection, and runtime binding.
3. If the Work uses a local model, confirm in that Work record that a model call actually occurred. A bound runtime or responsive model can exist without a Work call.
4. Compare final status, result validation, Work record, and receipt against the same installation and release identity. A failure, stop, rollback, or pending validation is not a success receipt.
5. Complete the following checklist before declaring first use. Record not checked separately from failure, but do not mark it complete.

Operational use cases

After installation, start at the use-case index to follow the work in order. New installation, runtime change and rebinding, separate PackrGUI and headless routes, Builder candidates, and first Work each describe owners, prerequisites, evidence, and failure branches. Cases A–J below are symptom-driven troubleshooting guides.

7. Troubleshooting examples

The following situations may arise during installation and use. Exact product messages can vary by version and platform. Perform only the safe action shown here; pass identity, authority, and state-integrity failures to the support route. Open each linked case for a worked example, ordered checks, outcome branches, sample support request, and completion and stop conditions. If you are unsure which case fits, start with the troubleshooting index.

Case A — The VM is running but the product is not ready

• Symptom: The cloud console shows a running VM while product status is still initializing or the service is not ready.
• Check first: Inspect the first-boot completion indicator and product status. If an error says that a required initialization component is missing, record the image ID and message.
• Safe action: Follow the release's wait and read-only diagnostic procedure once. If a component is missing or readiness never appears, send the image ID and status to support. Do not install random packages or delete service state files in the customer VM.

Case B — SSH or the app shows a different host identity

• Symptom: A host-key change warning, authenticated server identity mismatch, or unexpected installation identity.
• Check first: Determine whether you are connecting to a new instance rather than the old one, and verify the address, organization, and installation ID. Do not automatically reuse an old trust entry after a host-key change.
• Safe action: Stop the connection and verify the current host identity using the release's independent official route. Do not ignore the warning, disable host checks, or replace a stored key before verification.

Case C — A connection refusal could be network or authentication

• Symptom: A connection timeout immediately after boot, login refusal, or a client window that opens but remains unauthenticated.
• Check first: Check in order: VM and service readiness, official address and network path, current account and authentication method, then product customer and installation identity. A timeout and a login refusal require different actions.
• Safe action: Follow the release's stated recheck procedure. Do not switch to another person's key or account. Record the failing stage, time, and exact message.

Case D — Administrator enrollment refuses non-interactive input

• Symptom: A command sent by remote script or pipe is refused because a real terminal or user confirmation is required.
• Check first: See whether the release requires an interactive local wizard or terminal.
• Safe action: Have the actual administrator complete the designated interactive procedure. Do not simulate confirmation with automated input. Read back the recorded role and scope afterward.

Case E — Storage access fails after administrator enrollment

• Symptom: The administrator was registered, but subsequent observation or binding stops with Permission denied or a storage access error.
• Check first: Read the displayed refusal code and stage, service readiness, and installation identity. Distinguish a storage access error from a role or scope refusal.
• Safe action: Do not change product state files or OS permissions by hand. Check whether your release includes the fix and send support the exact error and version.

Case F — The runtime is visible but not bound

• Symptom: A local model is installed and the runtime is running, but product status says only detected or refused.
• Check first: Check supported model and runtime, installation identity, administrator scope, Core validation state, and refusal reason. If the model alias or runtime address changed, confirm the status follows a fresh observation.
• Safe action: For an in-scope environment, follow the release wizard's re-observation procedure. For an out-of-scope or ambiguous model, request the explicit administrator action. Do not edit the database to display BOUND.

Case G — Local model startup lacks memory or network access

• Symptom: The local model does not start, or a download or metadata check times out in an offline environment.
• Check first: Check the release's model-specific memory requirements, whether the model is already local, and your organization's external-network policy. Check binding status and Work status separately.
• Safe action: Provision resources that meet the supported requirements and use the release's local-model preparation route for offline operation. Do not report failed outbound attempts as successful inference or as zero outbound traffic.

Case H — A Pack candidate exists but cannot be run

• Symptom: Builder displays a candidate, but it is not listed as an approved Pack for Work or execution is refused.
• Check first: Separately confirm candidate validation, approval, customer entitlement, contract scope, and preconditions.
• Safe action: Follow the product approval procedure. Prepared in Builder is not execution permission.

Case I — Binding succeeded but there is no Work receipt

• Symptom: Runtime status says bound, but no result or receipt is available.
• Check first: Determine whether a Work was actually submitted, approved, and executed, and whether its final status is success, failure, stop, or rollback. A binding screen alone does not create a receipt.
• Safe action: Follow the release's first-Work procedure and record location. Never substitute an earlier binding record for a Work receipt.

Case J — A new VM contains an earlier user's traces

• Symptom: A new customer VM exposes an unexpected user home, access key, prior installation identity, or settings.
• Check first: Confirm the image identity and whether this is a new instance. Stop use if unexpected traces of an earlier user are present.
• Safe action: Do not begin Work on that VM; notify the deployment owner and support. Do not delete another user's files to make an unverified image appear approved.

8. Changes, recovery, and support requests

1. After changing a runtime, model, network, customer, or installation scope, do not assume the old binding still applies. Confirm new observation → Core validation → new binding → any required Work recheck. An out-of-scope change needs the administrator procedure.
2. If a failure repeats, do not retry indefinitely. Preserve the first error, the release's support procedure, and the state before the change. Recover only through the release-provided route; do not edit internal product state, keys, or receipts.
3. Include the release and component versions, operating system, step, displayed state or refusal code, time and time zone, reproduction steps, safe actions already taken, and scope of impact in a support request. Do not send customer data, raw prompts, passwords, private keys, passkey responses, or full logs. Use the minimum-disclosure path directed by support.
4. Stop urgently for a signature or host-identity mismatch, different customer or installation ID, suspected privilege expansion, prior-user residue, or a state-integrity warning. Stop installation or Work and provide the first evidence to support.

Installation record and support details

The installer should record the release and image IDs, the exact files and digests installed on each platform, supported-environment checks, initial administrator scope, authenticated connections, and current runtime binding. For any Work that was run, keep its final state, result validation, and receipt location with the same installation and Work ID.

Check macOS, Windows and Linux clients and the headless route separately. A connection on one platform does not verify installation, authentication or permissions on another. If a screen or command differs from the example here, follow the instructions supplied with your release and include the product's actual message and your steps in a support request. Exclude customer data and secrets.

Online/closed-network environments and component task map

Online operation uses approved network/provider routes; closed on-premises operation provisions required installation assets, models and documentation before transfer. This guide fixes neither as the product default. The optional SDK Rust dependency set prepares SDK adapter-build Rust coverage; it does not replace appliance images, model weights, provider credentials or all native OS development tools.

Checks after operational changes

After a client update recheck that client’s connection, authentication and installation identity. After a runtime change recheck fresh observation, validation and binding. After a Pack change recheck exact version, trust, current entitlement and preconditions. Retain the previous records and recovery target. If something changes unexpectedly, record the first differing observation and return to that component’s procedure.

Additional Packs use files and registration procedures appropriate to the supplied release, customer and installation scope. Copying a folder or renaming a candidate does not replace registration/approval. First application requires the approved plan, postcondition validation and receipt. Removal/rollback follows that Pack’s declared recovery procedure and current authority.

First blockage: start from the last confirmed step

The same symptom can require different actions at different stages. Choose the last step you directly confirmed below. A failed step does not require repeating the entire installation or deleting earlier results.

Write an actionable support request

This is a worksheet. Replace brackets with actual observations; write unconfirmed for unknown values. Do not invent product error codes or success timestamps.

Goal: [e.g. first SDK Custom synthetic candidate]
OS/CPU and tool version: [actual observations]
Selected route: [installed-toolchain run / supplied-set run-offline / GUI, etc.]
Last success: [e.g. analyze actually confirmed]
Failed step/time: [actual stage, local timestamp and timezone]
Observation: [actual status/reason or OS error; redact secrets]
Input/package reference: [version and SHA-256; no customer contents]
Earlier results: [present/absent; distinguish this attempt]
Next check requested: [e.g. approved native prerequisites]

Do not send raw full logs, customer responses, keys, tokens or profile contents in bulk. Share only redacted minimal messages/identifiers through the organization's support route. After resolution, recheck the first failed step and affected outputs, then continue.

First identify the current stage

Do not collapse every problem into “installation failed.” Record the last state you actually confirmed. This reduces unnecessary reinstalls and permission changes.

A short worked example

“I deployed a new VM for release [ID]. The VM runs, but the product is not ready. I have not enrolled an administrator or started Work. The first message was [verbatim] at [time with zone].” Start with A. Even if a client connection error appears at the same time, do not change authentication settings under C before product readiness is proven.

Conversely, if product readiness and network reachability are confirmed but login alone is refused, use C for authentication. If only a binding screen exists and there is no Work receipt, use I. This order does not prove a root cause. It prevents declaring an unproven later stage successful.

Stop immediately when

Stop self-service for a signature or file-digest mismatch, unexpected host identity, different customer or installation ID, suspected privilege expansion, earlier-user data, or state-integrity warning. Collect only the minimum case-specific support evidence. Do not put passwords, tokens, private keys, passkey responses, customer data, or full logs in an ordinary support request.

Choose the next procedure from the symptom

Online operation uses approved network/provider routes; closed on-premises operation provisions required installation assets, models and documentation before transfer. This guide fixes neither as the product default. The optional SDK Rust dependency set prepares SDK adapter-build Rust coverage; it does not replace appliance images, model weights, provider credentials or all native OS development tools.

Example support handover: release/component/OS, time and timezone, last confirmed stage, first refusal, performed change, current result and next owner. Keep unconfirmed, refused, waiting, failed and completed states distinct. Exclude secrets and customer content.

Find the closest of 30 detailed scenarios

A broad issue category can contain different symptoms and remedies. Follow the example IDs below through situation, observation, action and resumption criteria. They are teaching scenarios; actual incident histories require separate evidence.

For SDK, Builder, GAPE, Integration Helper and source Document issues, also use the detailed examples in the post-install tool guides. Do not transfer preparation success between tools or to actual Work.

Back to installation and first-use guide

Choose by task

How to use this collection

Each use case follows situation → prerequisites → steps → failure branches → completion evidence. If several symptoms appear, start at the last proven state. For symptom-specific resolution, use the case index. Include only minimal release, installation, and verbatim error details in support requests; omit customer content and secrets.

Choose a use case by owner and output

Online operation uses approved network/provider routes; closed on-premises operation provisions required installation assets, models and documentation before transfer. This guide fixes neither as the product default. The optional SDK Rust dependency set prepares SDK adapter-build Rust coverage; it does not replace appliance images, model weights, provider credentials or all native OS development tools.

Example support handover: release/component/OS, time and timezone, last confirmed stage, first refusal, performed change, current result and next owner. Keep unconfirmed, refused, waiting, failed and completed states distinct. Exclude secrets and customer content.

Back to installation and first-use guide

First use: checklist for the first result

Start with each guide's first exercise. CLI examples select an absolute executable path, so a global PATH change is unnecessary. Launch GUI apps using the supplied installation procedure and release-specific screen names; do not invent menus or download URLs.

The optional SDK Rust set is not an installer for other applications. Rust installation is not required for every tool. Users checking an existing installation do not create another VM or repeat initial administrator enrollment.

How the parts fit together

This diagram shows how your organization owns its environment and operations, while integration tools help you understand, prepare and declare work and the product controls execution. Open the image in a separate tab to zoom. Check the supplied component list for tools and versions available to install.

Check the tools you need

Choose the tools you need below. Local SDK exercises and Document preparation do not require appliance installation first. Confirm each component's availability, platform, version and installer in the supplied component list. Do not substitute a file from another release for a missing tool.

Choose the next task

What the installation set must contain

The Non-SI installation set must let a customer reach these guides online or offline from Start_Setup.html and identify the exact installable components for the appliance, the customer's workstation platform, Builder, GAPE, Integration Helper, SDK interfaces or Engine, and Contract & Document templates. Components can be delivered in separate platform installers inside one versioned set; they must be listed with hashes, compatibility, prerequisites, and the responsible installer. The set must also explain when a component is unavailable for the specific release. A documentation link or a historical implementation is not a substitute for an installable, validated component.

Install the SDK Engine separately on your integration workstation. Check the SDK Engine guide and supplied component list for the platform installer, supported appliance version, and installation and removal steps.

If a received file does not match the supplied list or signature verification fails, stop installation and contact your supplier's support route. Install only the verified file listed for your platform.

Recommended sequence

1. For appliance-connected work, complete installation and first use through an authenticated client and validated runtime binding. Local SDK synthetic examples and Document preparation start directly at their first exercises. Check each tool in the exact release inventory before opening it.
2. Use GAPE if a revision-bound architecture question matters. Review the observation and its limits; do not use a diagram as an approval.
3. Define the operation in a Document and obtain the exact supported Contract and adapter reference from the supplier. Integration Helper can then validate and prepare a candidate within its supported input format.
4. If the release supplies an SDK interface or Engine for this target, verify its published revision and follow its validation and package procedure. If the release does not list it, stop that path; do not infer availability from this infographic or an older SDK artifact.
5. Use Builder to prepare a Pack candidate if a supported existing Pack is insufficient. Keep candidate validation, approval, entitlement, and Work execution as separate recorded steps.
6. For an actual operation, follow the first Work guide and verify its final receipt. A preparation artifact cannot replace the receipt.

Common support record

Record the release and component versions, customer and installation identity, the exact input revision or candidate ID, the typed status and reason, the last proven step, and the expected next action. Omit private keys, credentials, customer payloads, raw prompts, and internal engineering exports. Stop when identity, signature, authority, or state integrity differs.

Online/closed-network environments and component task map

Online operation uses approved network/provider routes; closed on-premises operation provisions required installation assets, models and documentation before transfer. This guide fixes neither as the product default. The optional SDK Rust dependency set prepares SDK adapter-build Rust coverage; it does not replace appliance images, model weights, provider credentials or all native OS development tools.

Checks after operational changes

After a client update recheck that client’s connection, authentication and installation identity. After a runtime change recheck fresh observation, validation and binding. After a Pack change recheck exact version, trust, current entitlement and preconditions. Retain the previous records and recovery target. If something changes unexpectedly, record the first differing observation and return to that component’s procedure.

Additional Packs use files and registration procedures appropriate to the supplied release, customer and installation scope. Copying a folder or renaming a candidate does not replace registration/approval. First application requires the approved plan, postcondition validation and receipt. Removal/rollback follows that Pack’s declared recovery procedure and current authority.

Back to installation and first-use guide

Why this case matters

A cloud console can report Running while the appliance is still initializing. Confirm product readiness in the setup interface before connecting clients or starting Work.

Example situation

You created a new appliance and the cloud console says Running. PackrGUI cannot connect, while product status says initializing or service not ready. Record the cloud and product states separately.

Check in this order

1. Confirm the received image's release ID and that this is a new deployment. Stop if it is an older test VM or a different release image.
2. Read the release's first-boot completion condition and expected wait procedure. Do not invent an arbitrary time limit as a success condition.
3. Inspect VM running state and product service readiness separately. A running process is not enough when product readiness is absent.
4. Use only the release-provided read-only diagnostic to inspect the first-boot stage, required components, and service refusal reason. Use exact commands and log locations from the release guide.
5. Even if a network error appears at the same time, do not assume networking is the cause before service readiness is established.

If this release supplies packrctl and the authorized local operating route, these read-only commands show why VM power and product readiness need separate checks. Read the returned readiness and reason fields; a nonzero health exit can represent UNKNOWN or NOT_READY and is not a reason to restart the VM blindly.

packrctl status --json
packrctl health --json

What to do with the result

Field decision example: first boot has power only

Assume an operator creates a VM at 10:00 and sees running in the console at 10:02, while product status remains initializing. The evidence establishes VM power only. Service readiness, administrator enrollment, and client access remain unverified. Record image ID and boot time, perform the release-defined wait and status check once, then escalate a persistent refusal. Do not repair guest packages or initialization files directly on the customer VM.

Example support request

“Release ID [value], instance creation time [with zone], VM state [Running], product status [exact displayed text], first-boot stage [value], and first error [verbatim]. No customer Work was started.”

Send the minimum status output named by the release, not customer data or a full system log.

Completion and stop conditions

Complete: the product reports service readiness for this installation identity. Stop: an initialization gap, integrity warning, release mismatch, or repeated readiness failure appears. Do not delete recovery files, reinstall, or force-start services.

Distinguish three similar-looking symptoms

Return to the original procedure after correction

Record the first refused stage and the corrected item, then check its current result. Recheck earlier proven stages when the change affects them. Proceed only with the required current evidence. Include exact version, time with timezone, failed stage/reason, last confirmed state, change and recheck result in support handover. The illustrative table is not an established cause or execution history.

How to read the detailed cases

The three cases below are worked teaching scenarios for realistic field conditions. Their illustrative states are not invented product error codes or customer incident histories. Distinguish causes using values observed in your own installation. Cite supplied execution records only within their recorded scope.

Each example supplies context, observations, discriminating checks/actions, resumption criteria and unresolved handover. One symptom can have several causes; do not blindly continue after the first refusal.

Worked scenario A-1: The VM is running while first boot is still in progress

Situation: An installer opens the GUI as soon as a new VM powers on. The GUI times out while the first-boot view still shows initialization. Product readiness must be checked before attributing the symptom to credentials.

Read these observations separately.

• VM: running. This confirms power only.
• Product: initializing. No readiness completion has been recorded.
• GUI: timeout. Before readiness, this does not establish an authentication cause.

Check and action sequence:

1. Check image and creation records for the same instance, then locate the release-defined completion signal and wait policy.
2. Check whether initialization is making progress in product status. Do not reenroll accounts or reinstall clients while readiness is absent.
3. After readiness is observed, record installation identity and recheck the original GUI connection.

Condition for resuming: Proceed to administrator setup only when that new installation is ready and identity matches; verify GUI connection separately.

If still unresolved: If the supplied wait limit is exceeded or progress stops, retain the first error and last update time and hand over to the image/deployment owner.

Worked scenario A-2: A process exists but required initialization fails

Situation: The management view shows a running service process while product health remains not ready. The first error describes an unavailable required initialization component or configuration. Compare the image and product readiness before treating a restart as a fix.

Read these observations separately.

• Process start: confirmed. Initialization success is separate.
• Health: not ready. Retain its exact reason and observation time.
• Inventory: delivered and actual image identity still need comparison.

Check and action sequence:

1. Compare current instance provenance with the delivered image/release. Do not interpret it using another version’s instructions.
2. Separate the first initialization refusal from later status using supplied read-only status/health output.
3. If a missing asset is confirmed, use the supplier’s image repair/replacement procedure; do not add arbitrary guest packages.

Condition for resuming: After supported correction, recheck current image/installation identity and readiness. A restarted process alone does not close the case.

If still unresolved: With an unconfirmed cause or different image, hold enrollment/Work and hand over minimal errors and image identity.

Worked scenario A-3: Yesterday’s readiness screenshot is healthy but today’s connection fails

Situation: A user assumes the server is healthy because an earlier readiness screenshot exists. Maintenance or a reboot occurred later, and today’s product status has not been read. Separate prior success from current observation.

Read these observations separately.

• Earlier screenshot: predates the change; it is not current-state evidence.
• Change record: retain only known reboot/update times.
• Current state: unconfirmed; a network fault is not established yet.

Check and action sequence:

1. Check whether the current target is the same instance. A replacement also needs Cases B/J identity checks.
2. Read post-change status/health and first errors. Once readiness is confirmed, separate reachability/authentication with Case C.
3. Bind before/after status to the actual change and recheck affected stages.

Condition for resuming: Record recovery only for the current readiness, identity and client authentication actually reconfirmed.

If still unresolved: If current status cannot be read, retain that unconfirmed stage and management-path issue instead of filling it with an old screenshot.

Fill the case-specific support record

Image/instance provenance, creation time, current status/health, initialization stage, first refusal and last update time.

Keep original status separate from interpretation and include a timezone. This is a record worksheet, not a product API request or execution receipt.

case: A-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

Exclude full logs, customer data, keys, tokens and passkey responses from ordinary tickets. Retain originals after handover. Changes to authority, identity or deployment scope follow the appropriate owner’s supported procedure.

Back to installation and first-use guide

Why this case matters

A host key may change when an instance is replaced or reconfigured. A warning means the identity of the destination is not yet confirmed; do not disable the check to reconnect.

Example situation

You reconnect to yesterday's address and SSH or the app warns that the server identity changed. You may believe it is the same VM, but it could be a new instance, a regenerated key, a wrong address, or an unverified host.

Check in this order

1. Stop the connection. Record the warning time, destination, and displayed identity information. Do not include private keys or credentials.
2. In the release-approved management console, confirm the target instance name, installation ID, and creation or restart history. An unchanged address does not prove an unchanged host.
3. Compare the current host identity through an independent authenticated route supplied by the product or cloud. A value obtained only through the warned connection cannot authenticate that same connection.
4. Follow a release-defined trust-update procedure only when the independent values match and you have authority to update trust. Otherwise hand the case to the administrator or support.
5. After connection, separately confirm the customer and installation identity. Host-key proof does not grant product authority.

What to do with the result

Field decision example: key warning at an unchanged address

Suppose a connection tool reports a different host key at the same address. A new instance might reuse the address, or the original instance might have regenerated its key. The warning alone cannot decide which. Keep the connection stopped while comparing instance and disk identity in the management console with the current key from a release-approved independent authenticated route. If either side is unavailable, do not delete or replace saved trust.

Example support request

“Release ID [value], expected installation ID [value], target [official alias], warning time [with zone], warning type [verbatim], and instance-replacement check [result]. I did not proceed after the warning.”

Completion and stop conditions

Complete: current host identity, installation identity, and official destination match independent evidence. Stop: if any identity mismatch remains, do not disable host checks, ignore the warning, or arbitrarily delete or replace saved keys.

Distinguish three similar-looking symptoms

Return to the original procedure after correction

Record the first refused stage and the corrected item, then check its current result. Recheck earlier proven stages when the change affects them. Proceed only with the required current evidence. Include exact version, time with timezone, failed stage/reason, last confirmed state, change and recheck result in support handover. The illustrative table is not an established cause or execution history.

How to read the detailed cases

The three cases below are worked teaching scenarios for realistic field conditions. Their illustrative states are not invented product error codes or customer incident histories. Distinguish causes using values observed in your own installation. Cite supplied execution records only within their recorded scope.

Each example supplies context, observations, discriminating checks/actions, resumption criteria and unresolved handover. One symptom can have several causes; do not blindly continue after the first refusal.

Worked scenario B-1: Host-key warning after a replacement VM reuses an address

Situation: An operator replaces a VM and the client connects to yesterday’s address. The client warns that the server key changed. Address reuse is a possible explanation, not verified identity for the current channel.

Read these observations separately.

• Address: unchanged; this does not establish the same instance.
• Management console: independently check the replacement record.
• Host fingerprint: distinguish the warning-channel value from an independent value.

Check and action sequence:

1. Keep the connection stopped while checking current instance/disk/image identity through the approved console.
2. Obtain the current public-key fingerprint through the release’s independent authenticated route and compare it.
3. Only after a match, have an authorized owner apply the supplied trust-update procedure and verify product installation identity.

Condition for resuming: Return to connection only after both current host and product installation identity match expectations.

If still unresolved: Without an independent match, hold and hand over to the identity owner; do not delete trust records or disable checking.

Worked scenario B-2: Distinguish a stale saved endpoint from the intended server

Situation: A bookmark or client-profile alias looks familiar, but the connected product is not the expected installation. Even a valid server key does not establish that the intended work target was selected.

Read these observations separately.

• Profile alias: a human label; retain it separately from target identity.
• Host identity: may be valid for another approved server.
• Customer/installation display: do not use the session for work when it differs.

Check and action sequence:

1. Compare the published endpoint with the saved profile’s actual address and port.
2. Compare customer/installation identity with independent installation records; do not inspect another customer’s content.
3. Select the correct profile through approved client settings and recheck identity/scope in a fresh session.

Condition for resuming: Continue only with current evidence of authentication to the intended target.

If still unresolved: If the official endpoint cannot be bound to the intended installation, stop access and involve address/identity owners.

Worked scenario B-3: The host is said to be unchanged but its key changes again

Situation: A legitimate key update was verified once, but another warning occurs for the same claimed instance. A reboot or configuration-change explanation alone does not authorize repeated trust updates.

Read these observations separately.

• Key change: occurred again between observations; retain each transition.
• Instance: compare the claim of sameness with actual console identity.
• Current key: a difference from the verified value is unconfirmed again.

Check and action sequence:

1. Retain the first update’s basis and the later warning’s time and target.
2. Have the owner compare approved changes with current independently obtained identity.
3. Do not repeat connection until the cause and current identity are verified.

Condition for resuming: Recheck the specified connection only after the owner verifies current host/installation and change history.

If still unresolved: Escalate unexplained repeated key changes as an identity issue, not routine profile cleanup.

Fill the case-specific support record

Expected target alias, warning time, replacement history, independent fingerprint verification and product installation identity match.

Keep original status separate from interpretation and include a timezone. This is a record worksheet, not a product API request or execution receipt.

case: B-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

Exclude full logs, customer data, keys, tokens and passkey responses from ordinary tickets. Retain originals after handover. Changes to authority, identity or deployment scope follow the appropriate owner’s supported procedure.

Back to installation and first-use guide

Why this case matters

A timeout and a login refusal require different checks. A timeout can indicate reachability or service readiness; a refusal after reaching the server points to authentication or access scope.

Example situation

PackrGUI cannot connect. One attempt reports connection timed out; the next reports login refused. The first may concern reachability or readiness, while the second may concern authentication or scope. Record them as separate events.

Check in this order

1. Confirm the current appliance release ID and installation ID.
2. Distinguish a running VM from a ready product service. If the product is not ready, resolve Case A first.
3. Check the official release destination and network route against the customer's firewall policy. Do not open a different port or public Internet route on your own.
4. Only after reachability is established, check the current account, release-specified login method, and its customer and installation scope.
5. Even after authentication succeeds, confirm the customer and installation identity and permitted functions in product status. Login alone is not runtime binding or Work authority.

Branch by message

Recheck and support evidence

After a remedy, recheck service readiness → reachability → authentication → product installation identity in order. Include both the first and later errors with their exact text and times in support requests. Identify the destination only by an official shareable alias. Never send a password, token, or private key.

Completion and stop conditions

Complete: an authenticated client displays the expected customer and installation identity. Stop: do not work around identity mismatch or an unverified auth route by borrowing an account or key or disabling host checks.

Distinguish three similar-looking symptoms

Return to the original procedure after correction

Record the first refused stage and the corrected item, then check its current result. Recheck earlier proven stages when the change affects them. Proceed only with the required current evidence. Include exact version, time with timezone, failed stage/reason, last confirmed state, change and recheck result in support handover. The illustrative table is not an established cause or execution history.

How to read the detailed cases

The three cases below are worked teaching scenarios for realistic field conditions. Their illustrative states are not invented product error codes or customer incident histories. Distinguish causes using values observed in your own installation. Cite supplied execution records only within their recorded scope.

Each example supplies context, observations, discriminating checks/actions, resumption criteria and unresolved handover. One symptom can have several causes; do not blindly continue after the first refusal.

Worked scenario C-1: Separate a connection timeout from product unreadiness

Situation: The same account worked yesterday, but today there is no response and no login prompt. Check server readiness and the approved route before assuming a password problem.

Read these observations separately.

• Client: timed out without an authentication response.
• Server readiness: requires a current observation.
• Address/port: not assumed correct before comparison with the release.

Check and action sequence:

1. Confirm current readiness with Case A; resolve unreadiness first.
2. Have the owner compare the endpoint with approved DNS/firewall/access routes; do not open arbitrary ports.
3. After reachability recovers, check authentication and customer/installation identity separately.

Condition for resuming: Record connection recovery only when response, authentication and identity are confirmed on the approved route.

If still unresolved: If the failing segment is unknown, hand over the last reachable point and timeout to the network owner.

Worked scenario C-2: The server responds but the session has expired

Situation: The GUI verifies server identity but login is refused; headless queries are also refused for the current account. Separate a responding network from a valid session.

Read these observations separately.

• Server response: present; separate it from simple reachability failure.
• Session: retain the exact observed expired/unauthenticated message.
• Other route: do not assume GUI and headless share the same account/session.

Check and action sequence:

1. Check the release login method, account and validity period.
2. Reauthenticate the permitted current account through the supported flow and check returned customer/installation scope.
3. Query each needed GUI/headless route separately; do not copy user tokens into a service.

Condition for resuming: The connection stage closes for the route whose current authenticated session shows the correct installation.

If still unresolved: If authorization still refuses after reauthentication, hand exact scope/reason to the account owner without passwords or tokens.

Worked scenario C-3: GUI works while the automation service cannot connect

Situation: The workstation GUI works, but a scheduled server task is refused. Query from the service’s execution location and identity instead of reusing the GUI screenshot as success evidence.

Read these observations separately.

• GUI: success for the current user session.
• Automation: may use another account, route and permitted scope.
• Failure: distinguish timeout from authentication refusal using the original message.

Check and action sequence:

1. Check that the release supplies a headless route and service-authentication procedure.
2. Record the service endpoint, execution account, session and customer/installation scope separately.
3. After the owner corrects the failing route, recheck read-only status with the same service identity.

Condition for resuming: Record automation readiness only after its own authentication, identity and permitted functions are confirmed.

If still unresolved: If service authentication or scope authority is unavailable, hand over that state instead of copying user credentials.

Fill the case-specific support record

Access route, current readiness, timeout/identity/authentication failure stage, session state and customer/installation scope.

Keep original status separate from interpretation and include a timezone. This is a record worksheet, not a product API request or execution receipt.

case: C-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

Exclude full logs, customer data, keys, tokens and passkey responses from ordinary tickets. Retain originals after handover. Changes to authority, identity or deployment scope follow the appropriate owner’s supported procedure.

Back to installation and first-use guide

Observed pattern and meaning

Administrator enrollment may require a live, interactive confirmation. A value sent through a script or pipe can be refused. Confirm the product's success record before using administrator functions.

Example situation

An installation operator ran administrator enrollment from an automation script. The output refuses it because user confirmation is required. The binding wizard then cannot find administrator scope. Treating the command as successful would create a second failure.

Check in this order

1. Find whether the release requires the local setup UI or a genuinely interactive terminal for enrollment.
2. Determine whether the attempt came from a pipe, scheduled task, or non-interactive remote session. Do not include a secret input or confirmation word in support evidence.
3. Read current product administrator enrollment status without changing it. Do not start subsequent binding if there is no success record.
4. Have the authorized actual administrator review customer, installation, and runtime scope and confirm directly in the release-designated interactive flow.
5. Read back the resulting role, allowed scope, validity period, and installation identity. Distinguish OS login from product administrator enrollment.

Example branches

Example support request

“Release [value], enrollment stage [value], input method [interactive/non-interactive], product refusal [verbatim], enrollment status [none/present/unavailable]. No secret input is attached.”

Completion and stop conditions

Complete: the real administrator's product role and scope for this installation are recorded and readable. Stop: do not fake confirmation with automation or substitute OS administrator rights for product authority.

Distinguish three similar-looking symptoms

Return to the original procedure after correction

Record the first refused stage and the corrected item, then check its current result. Recheck earlier proven stages when the change affects them. Proceed only with the required current evidence. Include exact version, time with timezone, failed stage/reason, last confirmed state, change and recheck result in support handover. The illustrative table is not an established cause or execution history.

How to read the detailed cases

The three cases below are worked teaching scenarios for realistic field conditions. Their illustrative states are not invented product error codes or customer incident histories. Distinguish causes using values observed in your own installation. Cite supplied execution records only within their recorded scope.

Each example supplies context, observations, discriminating checks/actions, resumption criteria and unresolved handover. One symptom can have several causes; do not blindly continue after the first refusal.

Worked scenario D-1: Administrator confirmation is refused through a remote pipe

Situation: A setup script runs enrollment and receives a refusal requiring a real terminal or user confirmation. Check the supplied interactive requirement before treating it as an enrollment defect.

Read these observations separately.

• Input route: pipe or noninteractive job.
• Product result: the required human confirmation was not satisfied.
• Enrollment: no completed role/scope record exists yet.

Check and action sequence:

1. Locate the supported local wizard or interactive-terminal enrollment route.
2. Have the actual administrator review installation/customer/runtime scope and expiry.
3. Immediately read back the recorded role and scope after enrollment.

Condition for resuming: Record administrator setup complete only with human confirmation and product enrollment results.

If still unresolved: If the interactive route is unavailable, hand over that constraint without automated confirmation or token manipulation.

Worked scenario D-2: An OS administrator logs in without a product administrator role

Situation: An OS administrator expects the same authority inside the product. The product indicates no administrator role for the current installation.

Read these observations separately.

• OS login: succeeded.
• Product role: absent or unconfirmed for this installation.
• Installation scope: another installation’s enrollment is not reusable.

Check and action sequence:

1. Check current product installation identity against the subject of earlier enrollment.
2. Identify the owner authorized to enroll a product administrator for this installation.
3. Check recorded product role/scope/expiry instead of elevating OS privileges.

Condition for resuming: Perform observations within scope only after confirming product administrator enrollment for the current installation.

If still unresolved: Without enrollment authority, hand over to its owner rather than expanding scope through attempts.

Worked scenario D-3: Enrollment completes with an unexpected customer/runtime scope

Situation: After enrollment appears complete, runtime binding is refused. The recorded scope refers to another customer/installation or a narrower runtime scope than intended.

Read these observations separately.

• Enrollment completion: establishes role existence.
• Permitted scope: coverage of the current request is separate.
• Refusal: retain its exact target and reason.

Check and action sequence:

1. Compare current installation/customer/runtime references with the administrator record.
2. Identify the mismatch and have the authorized owner decide a supported scope change.
3. Read back changed scope, then restart the affected observation/validation stage.

Condition for resuming: Proceed only when the request is within recorded scope and the product has revalidated it.

If still unresolved: Hold when original authority cannot be established; do not edit stored enrollment records.

Fill the case-specific support record

Enrollment route/interactivity, current installation identity, actual human confirmation and product role/scope/expiry.

Keep original status separate from interpretation and include a timezone. This is a record worksheet, not a product API request or execution receipt.

case: D-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

Exclude full logs, customer data, keys, tokens and passkey responses from ordinary tickets. Retain originals after handover. Changes to authority, identity or deployment scope follow the appropriate owner’s supported procedure.

Back to installation and first-use guide

Observed pattern and meaning

An administrator may complete enrollment and still see an access refusal when the product reads the policy. Verify enrollment success and subsequent access success separately; the refusal reason determines the next step.

Example situation

Enrollment appeared successful. The first runtime observation then returns Permission denied or a storage-access error. Preserve the first error instead of enrolling the administrator repeatedly.

Check in this order

1. Record the first product error's time, stage, and refusal code. Do not overwrite the first event with retries.
2. Confirm the release and installation ID still match those used at enrollment. Stop if the product may be reading another installation's policy.
3. Inspect product service readiness and administrator enrollment status separately in the release's read-only status view.
4. Distinguish storage-access failure from absent administrator role and from out-of-scope authority. These require different responses.
5. Consult the exact release's known-fix or support guidance. Editing file ownership or lock files is not a customer troubleshooting step.

What to do with the result

Support evidence

Provide release and installation IDs, first refusal message, whether enrollment succeeded, service readiness, and time. Do not attach lock files, the internal database, raw administrator policy, private keys, or full logs.

Completion and stop conditions

Complete: the product can read the administrator status and process an allowed observation. Stop: do not repeat enrollment, widen file permissions, delete a lock file, or change the service account.

Distinguish three similar-looking symptoms

Return to the original procedure after correction

Record the first refused stage and the corrected item, then check its current result. Recheck earlier proven stages when the change affects them. Proceed only with the required current evidence. Include exact version, time with timezone, failed stage/reason, last confirmed state, change and recheck result in support handover. The illustrative table is not an established cause or execution history.

How to read the detailed cases

The three cases below are worked teaching scenarios for realistic field conditions. Their illustrative states are not invented product error codes or customer incident histories. Distinguish causes using values observed in your own installation. Cite supplied execution records only within their recorded scope.

Each example supplies context, observations, discriminating checks/actions, resumption criteria and unresolved handover. One symptom can have several causes; do not blindly continue after the first refusal.

Worked scenario E-1: The first status read fails after successful enrollment

Situation: Enrollment completes, but a later policy/status read shows Permission denied. Preserve enrollment and the first access error separately before repeating enrollment.

Read these observations separately.

• Enrollment result: exists.
• Subsequent read: ended in access refusal.
• Basis: product reasons must still distinguish store access from role scope.

Check and action sequence:

1. Compare release and installation identity for both results.
2. Retain the exact failed stage/reason and read-only service readiness.
3. Check supported corrections for that version; do not change file ownership or lock files directly.

Condition for resuming: After supported correction, read the administrator state and confirm permitted observation for the same installation.

If still unresolved: If store access remains refused, hand over the first error/version without attaching the database to an ordinary ticket.

Worked scenario E-2: Reads work but out-of-scope operations are refused

Situation: Administrator status reads normally while one runtime/capability request is refused. Treating every refusal as filesystem permissions can hide an actual scope boundary.

Read these observations separately.

• Administrator read: succeeds.
• Specific request: reported outside current scope.
• Other operations: success does not authorize this request.

Check and action sequence:

1. Compare requested installation/customer/capability/runtime with permitted scope.
2. Have the owner distinguish a necessary scope change from an incorrectly selected target.
3. After a supported target/authority correction, recheck the same bounded request.

Condition for resuming: Record recovery only for the permitted capability successfully rechecked.

If still unresolved: Without scope authority, do not broaden permissions or replace service accounts.

Worked scenario E-3: Store access first fails after an update

Situation: An existing installation fails its administrator status read after an update. Earlier successful reads exist, but none after the update. Bind changed version, current identity and failed stage together.

Read these observations separately.

• Earlier version: successful read is recorded.
• Current version: the first read fails.
• Installation identity: any change must be checked separately.

Check and action sequence:

1. Check exact before/after versions and the approved change record.
2. Use allowed read-only diagnostics for current installation/service/administrator state.
3. Have the owner use that version’s recovery/rollback procedure; do not mix arbitrary older files.

Condition for resuming: Close this access issue only with a confirmed recovery version, current installation and successful read.

If still unresolved: Hold without a supported recovery procedure or on an integrity warning; hand over minimal errors and change history.

Fill the case-specific support record

Enrollment result, first access failure stage/time, service state, current role/scope and before/after versions.

Keep original status separate from interpretation and include a timezone. This is a record worksheet, not a product API request or execution receipt.

case: E-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

Exclude full logs, customer data, keys, tokens and passkey responses from ordinary tickets. Retain originals after handover. Changes to authority, identity or deployment scope follow the appropriate owner’s supported procedure.

Back to installation and first-use guide

Observed pattern and meaning

Finding a local model and binding it to this installation are separate steps. After a model alias or runtime address changes, check the current binding result before using the model for Work.

Example situation

The administrator confirms the local model is installed. PackrGUI says the runtime is detected but not bound. If a model alias or runtime address changed yesterday, distinguish the old state from the current observation.

Check in this order

1. Confirm the runtime type and model are supported by this release. A model file alone does not establish support.
2. Read detection time, validation status, and binding status separately. Check that the view is not from an earlier boot.
3. Confirm the current customer and installation IDs and whether the approved administrator scope includes this runtime location and model.
4. Preserve any ambiguity or out-of-scope reason exactly as shown. Do not guess which of several models to write into product storage.
5. Use the release wizard's re-observation or scope-approval procedure. Then read the new binding model reference and installation ID.
6. Even after binding, check actual Work calls separately in Case I.

Example branches

Field decision example: old binding after an alias change

Assume a runtime alias changes at 11:00 while the product still shows a bound record from 10:30. That record belongs to the prior state. A new discovery time, Core validation, and binding time and model reference after 11:00 are needed to establish rebinding. New detection alone is insufficient; use the branch table above to locate the first refused gate.

Times are illustrative. Record actual product state and refusal codes; do not edit internal storage.

Example support request

“Release [value], installation ID [value], runtime type [shareable name], expected model [name], change time [value], detection/validation/binding states [separately], refusal [verbatim]. No Work was run.”

Completion and stop conditions

Complete: the product displays a fresh binding linked to the current observation and approved scope. Stop: do not edit the database or copy an earlier refused binding.

Distinguish three similar-looking symptoms

Return to the original procedure after correction

Record the first refused stage and the corrected item, then check its current result. Recheck earlier proven stages when the change affects them. Proceed only with the required current evidence. Include exact version, time with timezone, failed stage/reason, last confirmed state, change and recheck result in support handover. The illustrative table is not an established cause or execution history.

How to read the detailed cases

The three cases below are worked teaching scenarios for realistic field conditions. Their illustrative states are not invented product error codes or customer incident histories. Distinguish causes using values observed in your own installation. Cite supplied execution records only within their recorded scope.

Each example supplies context, observations, discriminating checks/actions, resumption criteria and unresolved handover. One symptom can have several causes; do not blindly continue after the first refusal.

Worked scenario F-1: Model files exist without an observed runtime

Situation: An operator expects binding because model files were provisioned. The product has no current runtime observation or only discovery status. Check file provisioning, process state and product observation separately.

Read these observations separately.

• Model files: presence only is confirmed.
• Runtime process: supported version and actual execution need checking.
• Product observation: fresh observation/validation/binding is not established.

Check and action sequence:

1. Compare provisioned runtime/model/address with release-supported combinations.
2. Read current observation and reason in the product discovery/setup flow.
3. After supported preparation, confirm product validation of a fresh observation.

Condition for resuming: Record binding complete only for validated/bound current installation runtime/model references.

If still unresolved: Without a supported target/observation route, hand over instead of creating binding-state files.

Worked scenario F-2: An alias changes while the old binding remains visible

Situation: After a model alias change, the screen still shows the old binding. Distinguish an old display, absent fresh observation and a refused new target before deciding what changed.

Read these observations separately.

• Change record: distinguish before/after alias or address values.
• Displayed binding: may refer to a pre-change observation.
• Fresh observation: separately check time, target and any refusal.

Check and action sequence:

1. Retain previous binding references and newly intended runtime/model references.
2. Use the supplied observation/validation procedure and compare its time with the change.
3. If the new target is out of scope, await its authority owner instead of copying old results.

Condition for resuming: Record application of the new environment only when the fresh observation’s target and binding match.

If still unresolved: Do not start new Work for the changed target on an old binding when fresh observation/reasons are unconfirmed.

Worked scenario F-3: Several models are discovered and the intended target is ambiguous

Situation: Several models exist and the product discovers a runtime without applying binding. Selecting the first available model arbitrarily would not establish the intended supported target.

Read these observations separately.

• Discovery: multiple candidates are visible.
• Administrator scope: the permitted model/runtime needs checking.
• Product result: preserve ambiguity/scope refusal as returned.

Check and action sequence:

1. Identify the intended target and supplier-supported combination first.
2. Have the administrator check current installation scope through the product flow.
3. After the exact target is established, read fresh observation/validation results.

Condition for resuming: Continue within scope only after the intended target and validated binding are recorded.

If still unresolved: Do not invent a default target without selection authority or a supported combination.

Fill the case-specific support record

Current runtime/model references, before/after values, observation time, validation/refusal and permitted administrator scope.

Keep original status separate from interpretation and include a timezone. This is a record worksheet, not a product API request or execution receipt.

case: F-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

Exclude full logs, customer data, keys, tokens and passkey responses from ordinary tickets. Retain originals after handover. Changes to authority, identity or deployment scope follow the appropriate owner’s supported procedure.

Back to installation and first-use guide

Observed pattern and meaning

Local model startup can fail because a model is unavailable, resources are insufficient, or a network check cannot complete. Check the exact message and the supplied offline setup procedure before changing network policy.

Example situation

A customer plans to use a local model in an offline environment. The runtime waits for a model download or a metadata check times out. Alternatively, model startup fails, but the screen alone does not distinguish insufficient memory from a missing model.

Check in this order

1. Check the release's supported model, architecture, memory, and disk requirements. Size the VM from that list.
2. Confirm by the product or release-defined method that the model is already available locally. A download screen is not proof of local installation.
3. Confirm the customer's offline policy and the release-required local-only configuration. Do not open an Internet egress path on your own in a restricted environment.
4. Separate model-process startup, runtime discovery, binding validation, and Work execution. Different failing stages need different actions.
5. Read recorded call and failure status. Do not report a timed-out vendor metadata request as successful AI inference.
6. If resources change, follow the customer's approved environment-change procedure and observe, validate, and bind the runtime again.

What to do with the result

Example support request

“Release [value], OS/architecture [value], model [value], local model presence [value], failing stage [startup/discovery/validation/Work], first error [verbatim], external-network policy [allowed/blocked]. No prompts or customer data attached.”

Completion and stop conditions

Complete: the supported local model is prepared and the current runtime is validated and bound. Actual inference and Work still require separate checks. Stop: unknown requirements, unapproved Internet access, or an unsupported claim that no external inference occurred.

Distinguish three similar-looking symptoms

Return to the original procedure after correction

Record the first refused stage and the corrected item, then check its current result. Recheck earlier proven stages when the change affects them. Proceed only with the required current evidence. Include exact version, time with timezone, failed stage/reason, last confirmed state, change and recheck result in support handover. The illustrative table is not an established cause or execution history.

How to read the detailed cases

The three cases below are worked teaching scenarios for realistic field conditions. Their illustrative states are not invented product error codes or customer incident histories. Distinguish causes using values observed in your own installation. Cite supplied execution records only within their recorded scope.

Each example supplies context, observations, discriminating checks/actions, resumption criteria and unresolved handover. One symptom can have several causes; do not blindly continue after the first refusal.

Worked scenario G-1: The model exits during loading but memory shortage is unconfirmed

Situation: The model exits shortly after startup. A user wants to add memory before checking the error. Resource, architecture and model provisioning facts need to be reviewed together.

Read these observations separately.

• Process: starts and then exits.
• Failure reason: resource shortage is not established without the actual error.
• Support conditions: compare model, architecture, memory and disk requirements.

Check and action sequence:

1. Compare exact model version/architecture with release requirements.
2. Read available resources and first exit reason through permitted diagnostics.
3. If a resource shortage is confirmed, have the environment owner apply an approved change and observe again.

Condition for resuming: Record preparation complete when the model starts under supported conditions and current observation/validation/binding are confirmed.

If still unresolved: Without an exact failure reason, hand over exit observations/support requirements instead of repeatedly resizing or replacing models.

Worked scenario G-2: A closed network waits for model files that were not provisioned

Situation: A closed on-premises environment has client packages and SDK dependencies but no model files. The runtime waits for a model download. Provisioned Rust dependencies do not establish model-weight availability.

Read these observations separately.

• SDK dependencies: provisioning for Rust compilation.
• Model: local provisioning needs a separate check.
• External route: do not open a blocked policy to resolve provisioning.

Check and action sequence:

1. Check intended model/version, licensing, digests and storage requirements in supplied inventories.
2. Have the owner provision it through an approved offline model-import route.
3. After file verification, check model start, fresh observation and binding in sequence.

Condition for resuming: Close preparation only with verified local model assets and confirmed runtime binding.

If still unresolved: With an unconfirmed import route or rights, involve provisioning/licensing owners instead of fetching arbitrary model files.

Worked scenario G-3: Separate an online metadata failure from local operation

Situation: A local model is provisioned while an external metadata request times out. That result alone establishes neither failure of all local inference nor absence of external communication.

Read these observations separately.

• External lookup: attempted and timed out.
• Local inference: requires its own invocation/result.
• Product Work: requires separate Work identity/receipt checks.

Check and action sequence:

1. Check customer policy and actual application of supplied local-only configuration.
2. Record external lookup failure, local model start, binding and Work observations separately.
3. Recheck with allowed diagnostics; policy changes or external-model substitution follow their owners’ separate procedures.

Condition for resuming: Record success only for confirmed local stages and retain external lookup failure separately.

If still unresolved: Without confirmed communication scope/model selection, hand over without claiming no external traffic or completed local Work.

Fill the case-specific support record

OS/architecture, model/runtime versions, required/current resources, local provisioning, first exit and external lookup status.

Keep original status separate from interpretation and include a timezone. This is a record worksheet, not a product API request or execution receipt.

case: G-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

Exclude full logs, customer data, keys, tokens and passkey responses from ordinary tickets. Retain originals after handover. Changes to authority, identity or deployment scope follow the appropriate owner’s supported procedure.

Back to installation and first-use guide

The real boundary

Pack Builder helps prepare and validate Packs. Candidate creation, saving a file, a prepared screen state, and passkey enrollment are separate states. None automatically grants customer Pack approval, entitlement, or execution authority.

Example situation

An operator creates a Pack candidate in Builder. Preview and structural validation pass, yet it does not appear in PackrGUI's execution list or a Work request is refused. “Builder made it, so it can run” is not a valid conclusion.

Check in this order

1. Confirm this release actually supplies Builder and that its installer signature and version match.
2. Inspect candidate validation status and its defect list. Distinguish structural validation from execution approval.
3. Confirm the Pack's exact version, contract, requested capability, and target environment.
4. Inspect Pack approval and customer entitlement separately for this installation. Do not reuse approval from another customer or installation.
5. Review preconditions and any separate user approval or passkey requirement. A browser opening or returning to the app does not prove approval.
6. If a refusal remains, repair the candidate or follow the approval process. Do not run refused Work through another path.

What to do with the state

Example support request

“Release [value], Builder version [value], candidate ID/version [shareable value], validation [state], approval [state], customer entitlement [state], first Work refusal [verbatim].” Do not attach Pack source, internal contract text, or a passkey response.

Completion and stop conditions

Complete: the exact Pack is validated, approved, and entitled for this customer installation, with preconditions met. Stop: do not relabel a candidate as an approved Pack or bypass refused execution.

Distinguish three similar-looking symptoms

Return to the original procedure after correction

Record the first refused stage and the corrected item, then check its current result. Recheck earlier proven stages when the change affects them. Proceed only with the required current evidence. Include exact version, time with timezone, failed stage/reason, last confirmed state, change and recheck result in support handover. The illustrative table is not an established cause or execution history.

How to read the detailed cases

The three cases below are worked teaching scenarios for realistic field conditions. Their illustrative states are not invented product error codes or customer incident histories. Distinguish causes using values observed in your own installation. Cite supplied execution records only within their recorded scope.

Each example supplies context, observations, discriminating checks/actions, resumption criteria and unresolved handover. One symptom can have several causes; do not blindly continue after the first refusal.

Worked scenario H-1: Candidate structure validates while approval is pending

Situation: Builder shows candidate validation PASS and the user looks for it in the execution list. No approval exists for that exact revision yet; a stage remains between preparation and approved use.

Read these observations separately.

• Candidate validation: success within its specified checks.
• Approval: pending.
• Execution: no Work start/receipt exists.

Check and action sequence:

1. Check that candidate ID/revision/digest and validation result refer to the same bytes.
2. Hand purpose, candidate digest and validation to the release approval owner.
3. After approval, separately check current customer/installation entitlement and preconditions.

Condition for resuming: Move only to execution preparation after exact-candidate approval, entitlement and preconditions are confirmed.

If still unresolved: Without approval, do not copy the candidate into Pack folders or execute through another account.

Worked scenario H-2: Approval exists but entitlement belongs to another installation

Situation: A Pack approved for one installation is expected to work in another. The product refuses current-installation entitlement. Separate approval existence from its applicable scope.

Read these observations separately.

• Pack approval: check its exact version and scope.
• Current installation: may differ from the approved/entitled installation.
• Refusal: an authority result for the current request.

Check and action sequence:

1. Compare current customer/installation/Pack version with entitlement references.
2. Have the authority owner decide the needed entitlement through supported procedures; do not copy another installation’s files.
3. After entitlement is confirmed, recheck preconditions/plan for the same target.

Condition for resuming: Proceed with that Pack only when authority and plan are confirmed for the current installation.

If still unresolved: Without the authority owner’s confirmation, do not rename approval files or edit installation IDs for reuse.

Worked scenario H-3: The candidate changes after approval

Situation: A declaration or candidate file changes after review. The earlier approval screen remains, but the candidate digest differs. Determine whether the new bytes are actually covered.

Read these observations separately.

• Existing approval: refers to the previous candidate digest.
• Current candidate: changed revision/digest.
• Current validation: requires a result for the changed candidate.

Check and action sequence:

1. Retain before/after digests and change purpose.
2. Use the supported process to check validation and approval coverage for the new candidate.
3. Reconcile references across the current candidate, approval, entitlement and execution plan.

Condition for resuming: Proceed with the changed candidate only when current bytes are covered by the required results.

If still unresolved: Do not copy an old approval or edit only manifest digests to make references appear aligned.

Fill the case-specific support record

Candidate ID/revision/digest, validation subject, approval purpose/scope, current entitlement, preconditions and actual Work presence.

Keep original status separate from interpretation and include a timezone. This is a record worksheet, not a product API request or execution receipt.

case: H-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

Exclude full logs, customer data, keys, tokens and passkey responses from ordinary tickets. Retain originals after handover. Changes to authority, identity or deployment scope follow the appropriate owner’s supported procedure.

Back to installation and first-use guide

Observed pattern and meaning

A local runtime can be bound without any Work being submitted. Runtime readiness and completed Work have different records.

Example situation