Headless 운영 안내서

01 · 이 실습이 보여주는 범위

헤드리스가 처음입니까? 실제 Work 하나를 6단계로 읽기각 단계는 운영자의 조치, 기록된 응답, 그 의미 및 계속 진행할 근거를 연결합니다. 선택한 필드를 복사하거나 같은 발췌를 다운로드할 수 있습니다. 명령 템플릿과 운영 전제조건은 이 문서에서 확인하십시오.

2026년 10월 4일, 격리된 로컬 R234 후보에서 CREATE_AUDIT_ARTIFACT의 자동화 부분이 완료되고 사람의 인수을 기다리는 Work가 반환되었습니다. 이 작업은 구조화된 로컬 감사 산출물을 만들며 임의의 고객 파일을 검사하지 않습니다. 실습 환경은 일치하는 후보 설치 프로그램으로 초기화하고, 생성된 시작 설명자를 사용해 구동했습니다. 이러한 개발 환경의 전달 경로는 고객 설치 지침이 아닙니다.

읽기 형식: Headless는 실제 CLI 선택 필드를 연결한 실행 기록 안내를 사용합니다. 문서용 독자이며 실시간 세션이나 터미널 스크린샷이 아닙니다. 사용자의 ID·경로·해시는 달라집니다. 아래 명령은 성공 경로를 설명하며 관찰된 입력 교정은 오류와 교정 절에 있습니다.

이후 대화에서 로컬 실습과 안내서를 승인했습니다. 제품의 마지막 관찰값은 AWAITING_HUMAN_ACCEPTANCE이며 별도 대화상 승인으로 제품 상태를 갱신하지는 않았습니다. 증거 수집 후 서비스를 중지했습니다.

02 · 운영 인수정보와 시작 상태 확보

1. 전달 담당자에게 설치된 packrctl 실행 파일, 일치하는 서비스 릴리스, 정확한 전용 로컬 소켓을 받으세요. 지원 플랫폼과 운영 계정을 확인합니다.
2. 서비스 운영자에게 대상 서비스의 실행 여부를 확인하거나 권한 범위에서 전달된 시작 절차를 수행하도록 요청하세요. 조회 명령은 서비스를 시작하지 않습니다. 다른 설치의 엔드포인트를 재사용하지 마세요.
3. 관리자에게 CREATE_AUDIT_ARTIFACT 실행 허용 여부를 확인하고 Work 담당자에게 승인된 미사용 키 하나, 쓰기 가능한 비공개 작업 디렉터리, 검토자를 확보하세요.
4. 서비스 운영자와 로컬 보고서 파일 접근 또는 승인된 산출물 전달 방법을 확인하세요. 누락 항목은 진행 전에 해당 담당자로부터 확보합니다.

전달받은 로컬 클라이언트 환경과 운영 계정을 사용하세요. 로컬 소켓은 원격 연결이 아닙니다. R234 실습 결과로 고객 r232 설치나 관리자 초기 설정이 입증되지는 않습니다.

03 · 모든 명령을 같은 서비스로 지정

PoC R1 문서 교정: 아래 참고 예제는 두 명령의 종료 코드를 모두 보존합니다. status_exit와 health_exit를 각각 기록하십시오. 이 문구 교정으로 아래의 보존된 관찰을 다시 실행하거나 변경하지는 않습니다.

새 비공개 작업 디렉터리에서 두 경로 자리표시자를 전달받은 절대경로로 바꾸세요. 실습 내내 같은 셸과 계정을 유지합니다. 아래 파일은 stdout을 저장하며 비공개 운영 정보가 포함될 수 있으므로 로컬에 보관하고 전체 응답을 공개하지 마세요.

PACKRCTL="/ABSOLUTE/SUPPLIED/PATH/packrctl"
SOCKET="/ABSOLUTE/SUPPLIED/PATH/control-plane.sock"
"$PACKRCTL" --help
"$PACKRCTL" --socket "$SOCKET" status --json > status.json
STATUS_EXIT=$?
"$PACKRCTL" --socket "$SOCKET" health --json > health.json
HEALTH_EXIT=$?
printf 'status_exit=%s\nhealth_exit=%s\n' "$STATUS_EXIT" "$HEALTH_EXIT"

관찰값: status는 RUNNING, health는 liveness READY, readiness UNKNOWN 및 AUTHORITY_READINESS_OBSERVATION_UNAVAILABLE, runtime UNKNOWN 및 LIVE_RUNTIME_OBSERVATION_UNAVAILABLE을 반환했습니다. health 종료 코드는 1이었습니다. 해당 R234 프로젝션은 권한·런타임 관찰값을 unknown으로 반환했으며 이는 Work 허용 판정이 아닙니다. 전체 준비 완료는 입증되지 않았습니다.

별도로 승인된 이번 로컬 실습에서는 정상 작업 허용 경로가 4단계 제출을 평가했습니다. 이를 다른 설치에서 불명확한 전제조건을 무시해도 된다는 뜻으로 일반화하지 마세요. 릴리스나 사유가 다르면 응답을 보존하고 제출 전에 운영자에게 확인합니다.

단계별 독자에서 이 절에 해당하는 실제 결과 읽기.

04 · 승인된 감사 작업 한 번 제출

키 자리표시자를 이번 의도적인 작업에 배정된 미사용 키로 바꾸세요. 지원되는 의도 문구는 아래 그대로 유지합니다. 이 명령은 Work를 준비·실행하고 로컬 기록을 쓰며 읽기 전용 확인이 아닙니다. 이후 별도로 승인된 실습에서는 앞선 증거를 보존하도록 새 출력 파일명을 사용하세요.

WORK_KEY="REPLACE_WITH_ONE_UNUSED_APPROVED_KEY"
"$PACKRCTL" --socket "$SOCKET" work run CREATE_AUDIT_ARTIFACT "create audit artifact" "$WORK_KEY" --json > work-run.json
RUN_EXIT=$?
printf '%s\n' "$RUN_EXIT"

로컬에서 work-run.json을 열어 다음 항목을 찾으십시오: result.work.work_id 해당 정확한 값을 요청 키와 함께 보존합니다. 응답이 없거나 모호하면 새 제출에 앞서 대조 절차로 이동하십시오. 명령 종료 코드가 0이라는 사실만으로 Work 결과가 입증되지는 않습니다.

실제 로컬 R234 응답의 선택 필드; 나머지 필드는 생략:

{
  "result": {
    "work": {
      "state": "AWAITING_HUMAN_ACCEPTANCE",
      "work_id": "work-headless-c36fddb388d8599d9f5e70e40296eae13ccfa8ddaccf3976daacfa18e2ce373e"
    },
    "reports": [
      {
        "final_result": "AUTOMATION_COMPLETED_HUMAN_ACCEPTANCE_PENDING"
      }
    ],
    "execution_retry_allowed": false,
    "human_acceptance_claimed": false,
    "replayed": false
  }
}

자동 처리가 완료되었으며 이전 결과의 재생은 아니었습니다. 사람의 승인은 미완료이고 자동 실행 재시도는 허용되지 않습니다. 이어서 동일 Work를 조회하세요.

단계별 독자에서 이 절에 해당하는 실제 결과 읽기.

05 · 반환된 정확한 Work 찾기와 조회

result.work.work_id 의 전체 값을 WORK_ID에 복사하세요. 예시 ID를 복사하거나 키에서 ID를 추정하지 마세요. 같은 실행 파일·소켓·계정으로 두 조회를 실행합니다.

WORK_ID="PASTE_EXACT_result.work.work_id_FROM_work-run.json"
"$PACKRCTL" --socket "$SOCKET" work list --limit 10 --json > work-list.json
"$PACKRCTL" --socket "$SOCKET" work show "$WORK_ID" --json > work-show.json

1. work-list.json의 works[].work_id에서 정확한 ID를 찾으세요.
2. work-show.json의 work.work_id, reports[].work_id , selected_report.canonical_report.work_id 를 WORK_ID와 비교하세요.
3. 관찰된 로컬 실행은 제출·list·show의 ID가 일치했고 work.state 는 AWAITING_HUMAN_ACCEPTANCE였습니다. 보고서 검토로 진행하세요.

최근 10개에 ID가 없으면 저장한 ID로 직접 show를 실행하거나 문서화된 최대 100개 조회를 사용하세요. 결과 누락은 범위·재조회 확인 사항이며 재제출 이유가 아닙니다. 정확한 Work를 식별할 수 없으면 원 요청을 보존하고 지원 담당자에게 확인하세요.

이번 실습에서 대조한 실제 식별자: work-headless-c36fddb388d8599d9f5e70e40296eae13ccfa8ddaccf3976daacfa18e2ce373e

단계별 독자에서 이 절에 해당하는 실제 결과 읽기.

06 · 완료 판정 전에 결과 읽기

selected_report.canonical_report에서 다음 필드를 함께 읽으세요. 실제 로컬 R234 발췌이며 나머지 필드는 생략했습니다.

{
  "work_id": "work-headless-c36fddb388d8599d9f5e70e40296eae13ccfa8ddaccf3976daacfa18e2ce373e",
  "execution_count": 1,
  "final_result": "AUTOMATION_COMPLETED_HUMAN_ACCEPTANCE_PENDING",
  "validation_results": "PASSED",
  "closure": {
    "disposition": "AWAITING_HUMAN_ACCEPTANCE",
    "human_acceptance": null,
    "human_acceptance_required": true
  }
}

같은 Work의 receipt와 closure를 검토하고 지정된 검토자에게 결과를 전달하세요. PASSED는 기록된 검증 결과이며 AUTOMATION_COMPLETED_HUMAN_ACCEPTANCE_PENDING은 자동 처리 완료 후 사람의 검토가 남았다는 뜻입니다. 이를 승인 완료·운영환경 검증·고객 배포로 바꾸어 표현하지 마세요. 보고서가 없거나 결과가 다르면 계속하기 전에 해당 결과의 설명을 기록해야 합니다.

단계별 독자에서 이 절에 해당하는 실제 결과 읽기.

07 · 반환된 JSON과 PDF 열기

1. 자신의 show 응답에서 selected_report.json_path 와 selected_report.pdf_path 를 읽으세요. 승인된 로컬 뷰어로 정확한 경로를 열거나 운영자에게 승인된 사본을 요청합니다. 비공개 실습 경로는 여기에서 생략했습니다.
2. 두 파일의 존재와 읽기 가능 여부를 확인하세요. 파일의 Work ID·리비전을 선택된 보고서와 비교합니다. 서비스가 경로를 반환했다는 사실만으로 사용자 컴퓨터에 전달되었다고 볼 수 없습니다.
3. 바이트 검증 시 JSON 파일 SHA-256을 selected_report.projection.json_file_sha256 과, PDF 파일 SHA-256을 selected_report.projection.pdf_sha256과 비교하세요. 후자의 sha256: 접두사를 구분합니다. 플랫폼에 제공된 파일 검증 도구를 사용하세요.

실제 로컬 R234 projection 필드; 나머지 필드는 생략:

{
  "json_file_sha256": "d7c014b72ebb839269c0ab11c0c23bea7e07416178ec31583b7d10b6bc0ef996",
  "pdf_sha256": "sha256:1265657f5b51e8e63dd86a3977a91731f4f6893b37e1f1431a6977d88ddbb4f3",
  "report_sha256": "sha256:f97ee5c9726fd67e47343eb7425e56af11ad74f56a77e38636311a335ec0fc48"
}

두 파일의 지문은 다음 항목과 다릅니다: report_sha256이 항목은 보고서 지문을 식별하며 원시 JSON·PDF 파일의 체크섬이 아닙니다. 직접 실행하면 고유한 값이 생성됩니다. 이는 보고서 산출물이며, 별도의 실제 작업 출력에는 지원되는 산출물 인계 절차가 필요합니다. 원시 보고서는 비공개로 보관하고 승인된 최소 정보만 공유하십시오. 여기서 완료란 일치하고 읽을 수 있는 보고서와 사람의 인수 대기 상태를 명확히 확인한 것을 말합니다.

이번 실습에서는 실제 JSON·PDF 파일 해시가 반환된 projection과 일치했고 JSON 내용은 선택된 보고서와 일치했습니다. 이어서 네이티브 뷰어에서 PDF를 렌더링했습니다. 별도의 생성 출력 파일을 주장하지 않습니다.

macOS 파일 확인

두 자리표시자를 반환된 경로로 바꿉니다. 각 파일 옆에 출력된 체크섬을 위 projection 필드와 대조합니다. 미리보기의 파일 → 열기로 PDF를 열고 첫 페이지에서 Work, 실행 횟수, 검증 결과를 확인합니다.

REPORT_JSON="PASTE_EXACT_selected_report.json_path"
REPORT_PDF="PASTE_EXACT_selected_report.pdf_path"
shasum -a 256 "$REPORT_JSON" "$REPORT_PDF"

단계별 독자에서 이 절에 해당하는 실제 결과 읽기.

08 · 관찰된 입력 오류와 교정 이해

성공 실행 전에는 이전 안내의 “Create a local lineage artifact for this approved operator exercise” 문구를 사용했습니다. 필수 audit 단어가 빠져 있었습니다. 응답은 PACKR_OPERATOR_STATUS_UNAVAILABLE 이었고 내부 사유는 PACKR_IPC_MALFORMED_REQUEST 및 SEMANTIC_INTENT_TYPE_UNRESOLVED였습니다. 내부 사유를 읽으세요. 이 오류만으로 서비스 중단이 입증되지는 않습니다.

1. 운영자는 실패 응답을 보존하고 같은 계정·설치에서 work list를 조회했습니다.
2. 해당 조회의 works·admissions·executions·reports·receipts·closures는 비어 있었습니다. plan이나 Work 실행에는 도달하지 않았습니다. 로컬 세션 기록은 이미 변경되었을 수 있으므로 상태 변경이 전혀 없었다는 주장은 아닙니다.
3. 지원되는 입력 조건을 확인한 뒤 create audit artifact로 한 번 교정 제출했습니다. 이 제출이 4–7단계의 Work를 만들었으며 기존 Work를 재시도한 것이 아닙니다.

잘못된 문구를 테스트로 재현하거나 자동 교정 반복을 만들지 마세요. 시간 초과나 완료 여부가 불명확하면 먼저 재조회합니다. 범위가 한정된 빈 목록만으로 모든 Work의 부재가 입증되지는 않습니다. 기존 Work를 찾으면 재제출 대신 조회하세요. 시도 이력을 보존합니다. 검토 후 서비스 종료는 운영자와 전달된 절차의 책임이며 종료 권한이 있는 서비스만 중지하세요.

다음 절은 상세 명령 참조를 보존합니다. 이전 연결 실패 캡처는 별도 관찰이며 이번 성공한 로컬 실습의 결과가 아닙니다.

증거 수집 후 운영자는 이번 실습의 서비스만 중지하고 런타임 상태를 보존했습니다. 종료된 실습 엔드포인트를 다시 사용하려면 별도로 승인된 시작이 필요하며 앞서 기록된 RUNNING은 현재 실행 상태를 보장하지 않습니다.

별도의 읽기 전용 문법 교정

실제 도움말 호출에서 --json --hepl 은 종료 코드 2, PACKR_OPERATOR_INVALID_ARGUMENT 및 알 수 없는 옵션 사유를 반환했습니다. --help 로 교정하자 종료 코드 0과 지원 명령 목록이 반환되었습니다. 이 파서 단계 확인은 서비스 요청이나 상태 변경을 하지 않았습니다. 세션 메타데이터를 기록할 수 있었던 위의 Work 준비 거부와 구분하세요. 옵션 철자를 고치며 이 오류 때문에 서비스를 재시작하거나 Work를 제출하지 않습니다.

단계별 독자에서 이 절에 해당하는 실제 결과 읽기.

09 · 참조 — 설치된 어플라이언스에서 시작하기

Headless는 PackrGUI를 계속 열어 두지 않고 VibePackr를 운영하는 방식입니다. 로컬 상태·상태 점검·등록된 Work에는 packrctl 을 사용합니다. 제품 서비스가 실행과 기록을 소유하므로 데스크톱 창을 닫았다고 서비스가 중지된 것은 아닙니다.

1. 전달받은 릴리스, 승인된 어플라이언스, 설치 식별자, 운영자 계정을 확인합니다.
2. 설치된 클라이언트가 해당 설치의 로컬 엔드포인트에 연결되는지 확인합니다. 다른 컴퓨터에서 복사한 경로를 사용하지 않습니다.
3. Work를 제출하기 전에 해당 설치의 지원 구성과 허용 작업 범위를 확인합니다.

릴리스 경계: r232에는 범위가 제한된 최초 부팅 및 저위험 헤드리스 Work 한 건의 증거가 있습니다. 신규 고객의 관리 경로는 초기 관리자 설정(C7)에서 여전히 차단되어 있습니다. 이 명령으로 어플라이언스를 설치하거나 관리자를 설정하지는 않습니다. 이 가이드만으로 완전한 고객 설치 절차가 입증되는 것은 아닙니다.

데스크톱 관찰은 PackrGUI, 서비스 수명주기와 관리자 설정 전제조건은 VibePackr 관리자을 참고합니다.

운영 인계 자료 확보

납품 담당자에게 아래 고객용 인계 자료를 요청합니다. 아래 역할은 조직 내 책임 배정이며 추가 제품 역할을 뜻하지 않습니다.

r232 C7 경계에서 지원되는 관리자 인계 자료가 없다면 정확한 누락 항목을 납품 담당자에게 돌려보냅니다. 이 체크리스트로 자격증명이나 권한을 만들지 않습니다.

완전한 운영 경로 선택

어플라이언스 또는 명시적으로 제공된 로컬 클라이언트 환경의 터미널에서 지정 운영자로 실행합니다. 데스크톱 터미널이 자동으로 원격 어플라이언스를 가리키지는 않습니다. 아래 소켓 명령은 로컬 엔드포인트 선택이며 SSH 또는 원격 관리 연결을 만들지 않습니다.

데스크톱 작업·자산 탐색·관리 중 선택하려면 사용 워크플로우 허브 에서 시작합니다.

10 · 참조 — 연결과 기준 상태 확인

해당 설치에서 권한을 가진 로컬 운영자로 실행합니다. 기존 서비스를 조회하며 서비스를 시작하지 않습니다.

packrctl --help
packrctl status
packrctl health
packrctl status --json

설치에 기본값이 아닌 로컬 소켓이 지정되어 있으면 절대 경로를 입력합니다.

packrctl --socket /ABSOLUTE/INSTALLATION/control-plane.sock status --json

위 경로는 자리표시자입니다. --timeout-seconds 는 1–300초를 허용하며 기본값은 90초입니다. 대기 시간을 늘려도 실행 권한은 바뀌지 않습니다. 조회 실패 시 명령, 시간, 종료 코드, 반환 사유를 보존합니다.

11 · 참조 — 생존 상태와 작업 준비 상태 구분

status 는 Service, Readiness, Authority, ETS, Packtory, Runtime, Work 수, Last Receipt, Snapshot Revision을 표시합니다. health 는 Liveness, Core Readiness, General Work, Product Asset Work를 구분합니다. 구성요소의 상태와 사유를 함께 확인합니다.

짧은 시나리오: 서비스가 실행 중이고 General Work는 준비되었지만 Product Asset Work가 준비되지 않았다면 자산 의존 Work의 Packtory/ETS 바인딩을 확인합니다. 이 상태만으로 서비스 재설치가 필요하다고 판단하지 않습니다. 이는 해석 예시이며 실제 출력 기록이 아닙니다.

12 · 참조 — 실제 로컬 상태 조회 실패 읽기

이전 연결 끊김 관찰 · 2026년 10월 4일. MacBook 로컬 R234 후보는 이전에 연결 거부 응답을 반환했습니다. 이 보존된 관찰은 기존 기본 엔드포인트를 사용했으며, 앞서 설명한 격리 설치 및 성공한 Work와는 별개입니다.

같은 로컬 빌드의 CLI로 읽기 전용 health --json 조회를 수행해 아래 결과를 얻었습니다. 실제 CLI 출력의 텍스트 기록이며 터미널 스크린샷이나 정상 상태 예제가 아닙니다. 비공개 엔드포인트 경로는 공개 요약에서 생략했습니다.

종료 코드와 오류를 함께 보존합니다. 설치 운영자에게 제공된 엔드포인트와 의도한 서비스 확인을 요청하세요. 이 관찰이 기존 상태의 시작·복구·교체 권한을 주지는 않습니다. 위의 로컬 R234 실습은 별도로 실제 Work와 결과 재조회를 기록합니다.

13 · 참조 — 자동화에서 상태 점검 사용

packrctl health --quiet
packrctl health --json

두 명령은 각각의 대안입니다. --quiet 는 health에서만 지원하며 --json과 함께 사용할 수 없습니다. Quiet 모드는 일반 상태 표시를 숨깁니다. 오류와 종료 상태는 보존합니다.

모든 0이 아닌 종료 코드를 서비스 재시작으로 바꾸는 자동화 규칙을 작성하지 마십시오. 권한 실패는 접근 권한 검토로, 준비 상태 실패는 지정된 구성 요소 담당자에게 전달합니다.

작업 1 — 예정된 점검 진행 여부 판단

입력: 어플라이언스 운영자가 로컬 계정·엔드포인트를 전달했습니다. 목표: 서비스를 변경하지 않고 준비 상태 판단을 기록합니다. POSIX 셸에서 아래 단발성 예시를 실행합니다. 구성된 기본 엔드포인트를 사용하며 인계 자료에서 요구하면 앞서 확인한 소켓 옵션을 추가합니다.

#!/bin/sh
packrctl health --quiet
health_exit=$?
case "$health_exit" in
  0) printf '%s\n' 'Health ready; review operation authorization separately.' ;;
  1) printf '%s\n' 'Not ready: inspect packrctl health --json and component reasons.' ;;
  2) printf '%s\n' 'Check invocation arguments before another query.' ;;
  3) printf '%s\n' 'Ask the appliance operator to check endpoint and service.' ;;
  4) printf '%s\n' 'Ask the administrator to review the operator binding.' ;;
  *) printf '%s\n' 'Unexpected exit: retain the literal error for support.' ;;
esac
exit "$health_exit"

1. 오류 원문과 원래 종료 코드를 보존합니다. 예시에는 재시도·재시작·Work 제출이 없습니다.
2. 종료 코드 1이면 위의 별도 JSON health 조회로 첫 미준비 구성요소와 사유를 확인합니다. 3이면 엔드포인트·오류를 운영자에게, 4이면 자격증명을 제외한 바인딩 문맥을 관리자에게 전달합니다.
3. 책임자가 원인을 해결한 뒤 health를 한 번 더 조회하여 같은 구성요소를 비교합니다. 종료 코드·구성요소 사유를 기록하면 이 점검을 마칩니다. Work는 해당 준비 상태와 권한 요건을 모두 충족한 뒤 진행합니다.

14 · 참조 — 내 Work 찾기와 조회

packrctl work list --limit 10 --json
packrctl work show WORK_ID --json

WORK_ID 를 자신의 Work에서 반환된 식별자로 바꿉니다. 목록 기본값은 25이며 1–100을 허용하고 최근 갱신 순으로 정렬됩니다. 로컬 조회는 동일하게 인증된 설치/로컬 주체 범위이므로 빈 목록이 어플라이언스 전체에 Work가 없다는 뜻은 아닙니다.

r232의 이 명령은 --json이 없어도 구조화된 JSON을 반환합니다. 목록에는 works, admissions, executions, receipts, closures, reports , canonical_revision이 포함됩니다. 상세에는 선택한 work, invocation, reports , selected_report가 포함됩니다. Work ID로 기록을 연결하며 같은 화면에 있다고 같은 작업으로 판단하지 않습니다.

선택·결과의 예외 상황

15 · 참고 — 등록된 저위험 작업 하나 실행

이 명령은 Work와 로컬 산출물을 생성합니다. 설치 준비 상태와 작업 권한이 확인된 경우에만 사용합니다. 등록된 CREATE_AUDIT_ARTIFACT 작업은 구조화된 로컬 계보 산출물을 생성하며 임의의 첨부 내용을 감사하지 않습니다.

packrctl work run CREATE_AUDIT_ARTIFACT "create audit artifact" "REPLACE_WITH_UNIQUE_APPROVED_KEY" --json

1. 승인된 비기밀 의도와, 의도적으로 한 번 실행할 이 작업에 사용할 새 키를 선택하십시오. 키 자리표시자를 교체합니다.
2. 한 번 제출하고 반환된 prepared_plan 과 result를 보존합니다.
3. 반환된 Work 식별자를 읽고 work show로 확인합니다.
4. 완료로 판단하기 전에 보고서 결과, 검증, 영수증을 확인합니다.

run 도우미는 한 번의 호출에서 준비와 실행을 수행합니다. 임의 셸, 범용 AI 프롬프트 실행기, 파일 감사 명령이 아닙니다. 시간 초과는 재실행 허가가 아닙니다. 정확한 재현에는 동일한 준비 요청이 필요하며 편의 명령을 다시 실행하면 다른 계획이 만들어져 기존 키와 충돌할 수 있습니다.

작업 2 — Work 한 건을 제출부터 검토까지 추적

입력: 위 운영 인계 자료를 사용합니다. 명령의 의도는 로컬 R234 실습에서 사용한 지원 문구입니다. Work 담당자는 키 자리표시자를 실제 실습용 미사용 승인 키로 교체해야 합니다. 아래 모든 단계는 그 제출에서 반환된 Work 한 건을 대상으로 합니다.

1. 기준 health/status 명령으로 설치·준비 상태를 기록합니다. 필요한 구성요소나 권한이 해결되지 않았다면 제출 전에 멈춥니다.
2. 위 CREATE_AUDIT_ARTIFACT 명령을 한 번 실행하고 반환된 result.work.work_id를 찾습니다. 키와 함께 정확한 값을 보존하며 의도 문구로 ID를 추정하지 않습니다.
3. 실행 packrctl work list --limit 10 --json동일 항목을 찾으십시오: work_id 다음 위치에서 works없으면 계정·범위 및 최근 목록 개수 제한을 확인합니다. 표시되게 하려고 대체 Work를 제출하지 마십시오.
4. packrctl work show WORK_ID --json의 자리표시자를 정확한 ID로 바꿔 실행합니다. work.work_id · reports[].work_id 를 보관 ID와 대조하고 다음 절의 보고서 읽기로 진행합니다.
5. 제출 시간이 초과되면 신규 제출 전에 다음 절의 중단 응답 분기를 따릅니다. show가 거부되면 관리자가 원래 계정·설치 범위를 확인하며 거부를 우회하려고 계정을 바꾸지 않습니다.

16 · 참조 — 완료와 중단된 작업 해석

result.work, reports[].final_result, replayed , canonical_revision을 읽습니다. 보고서 참조나 프로세스 종료만으로 충분하지 않습니다.

응답 중단 사례: 키와 요청 문맥을 보존하고 자신의 Work 목록에서 일치하는 Work를 조회합니다. 다음 조치 전에 보고서와 영향을 확인합니다. 정확한 결과를 대조할 수 없다면 제출을 멈추고 민감정보를 제거한 식별자를 지원 담당자에게 제공합니다.

선택된 보고서와 산출물 읽기

합성 읽기 예시: 아래 가상 식별자와 일부 필드는 show 응답 해석을 돕습니다. 완전한 응답·실제 실행 기록·스키마 검증 fixture가 아닌 부분 발췌입니다.

{
  "work": {
    "work_id": "work-headless-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    "state": "AWAITING_HUMAN_ACCEPTANCE"
  },
  "selected_report": {
    "canonical_report": {
      "work_id": "work-headless-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "final_result": "AUTOMATION_COMPLETED_HUMAN_ACCEPTANCE_PENDING",
      "validation_results": "PASSED",
      "closure": {
        "human_acceptance_required": true,
        "human_acceptance": null
      }
    }
  }
}

1. 실제 selected_report.canonical_report에서 Work ID, final_result, validation_results, receipt , closure를 대조합니다. 예시는 검증 통과지만 사람의 인수은 대기 상태입니다. 지정된 Work 검토자에게 인수 검토를 배정합니다.
2. selected_report.projection 과 반환된 selected_report.json_path / selected_report.pdf_path를 확인합니다. JSON은 정본 보고서이고 PDF는 읽기용 투영입니다. 정확한 반환 경로를 승인된 로컬 뷰어로 열거나 운영자에게 승인된 사본을 요청합니다. 저장 디렉터리를 추정하거나 반환 경로만으로 파일 전달을 주장하지 않습니다.
3. 같은 Work·리비전의 JSON/PDF 보고서 산출물을 읽습니다. 보고서 참조와 selected_report.canonical_report.report_sha256를 기록하고 없거나 열리지 않으면 참조와 함께 운영자에게 전달합니다. 이 안내서의 명령에는 별도 보고서 다운로드 동사가 없습니다. 보고서 외에 작업의 실제 출력물을 전달받으려면 설치에서 지원하는 산출물 인계가 필요합니다.
4. 완료 확인: 제출 한 번, 일치하는 Work 하나, 읽을 수 있는 보고서 및 검증·영수증·종결 검토를 확보하고, 사람의 인수은 대기 상태 또는 별도의 기록으로 명시합니다. 선택된 보고서가 null이거나 영수증이 없으면 완료 주장을 멈추고 Work ID와 결과 원문을 지원 담당자에게 전달하십시오.

17 · 참조 — 런타임과 자산 의존성 확인

packrctl packtory status --json
packrctl ets status --json

status, reason_code, binding_configured , 보고된 개수를 읽습니다. 바인딩 설정은 사용 가능한 저장 또는 상관관계 경로의 증거가 아닙니다. ETS는 상관관계를, Packtory는 기록된 자산을 보고합니다. 알 수 없는 개수는 그대로 알 수 없음입니다.

런타임 선택·구성과 Work에 실제 바인딩된 런타임은 다릅니다. 제공되는 Work/GUI 투영에서 요청값과 실제 선택을 비교합니다. 전달된 런타임 설정이 AUTO, PREFER , PIN을 지원하는 경우 각 선택을 구분하며 고정한 런타임이 조용히 교체되었다고 해석하지 않습니다. 임의의 packrctl 구성 플래그 대신 전달된 구성 화면을 사용합니다.

자산 관리는 Packtory 관리자 , 제공되는 투영은 PackrGUI 에서 이어갑니다.

Work에 필요한 의존성만 확인

1. Work 담당자가 의도한 작업에 Packtory 자산이나 ETS 상관관계가 필요한지 정합니다. 같은 로컬 운영자 터미널에서 위 해당 상태 명령을 실행합니다.
2. 바인딩 플래그를 상태·사유와 함께 읽습니다. 구성되지 않았다면 설치 관리자에게 해당 설치의 지원 바인딩 인계를 요청합니다. 이 안내서는 구성 명령을 제공하지 않습니다.
3. 구성은 되었지만 준비 상태가 아니면 구성 요소 담당자에게 사유·대상·관찰 시간을 전달합니다. 기록된 개수가 0이라는 사실만으로 준비된 빈 목록과 조회할 수 없는 투영을 구분할 수는 없습니다.
4. 책임자가 전제조건을 해결한 뒤 해당 읽기 전용 조회와 health를 다시 수행합니다. 완료는 관련 의존성을 이해하고 필요한 준비 상태를 기록한 것이며 새 자산·상관관계 생성 주장이 아닙니다.

18 · 참조 — 서비스 변경 전에 진단하기

승인된 서비스 복구 후 status와 health를 반복하고 원래 Work를 확인합니다. 업데이트/롤백과 복구는 VibePackr 관리자에서 다룹니다. 지원 요청에는 릴리스, 명령, 시간, 종료 코드, 구성요소 사유, 민감정보를 제거한 Work/보고서 참조를 보존합니다. 자격증명, 기밀 의도, 원시 요청, 무제한 로그는 제외합니다. 문제 해결을 참고합니다.