VibePackr
웹사이트 메뉴
CUSTOM EXECUTION / 범위가 정해진 작업 하나 문서 · R1

Custom Execution 가이드

단계별 첫 사용 가이드 시작

지원되는 작업을 선택하고 올바른 인계 자료를 모은 뒤 실제 결과를 확인하고 명확한 다음 단계를 남깁니다.

한국어 검토판 · 모든 작업을 전달된 버전·전제조건·증거 범위와 대조하십시오.

Guide Pack이 처음입니까?구조·안전한 사용 경계·Packtory 목록 등록 목적 보기 → 문서 패키지이며 읽는 것만으로 제품 작업 권한을 부여하지 않습니다.

첫 사용 · Custom API 후보 두 개 생성·비교하기

설치된 SDK로 전체 합성 입력을 분석해 custom-01을 만들고 custom-02에서 component·score만 바꾼 뒤 후보 파일 네 개를 확인합니다. 로컬 합성 실습이며 실제 고객 API 호출·연동 등록·실행 승인이 아닙니다.

시작 전 준비

  • Part.1 설치와 Part.5 도구 체인 설정을 먼저 마칩니다. 아래 전체 JSON 두 개·UTF-8 텍스트 편집기·새 비공개 실습 폴더를 준비합니다. 의도적으로 숫자 score를 쓰는 의도적 오류 픽스처를 정상 기준 입력으로 사용하지 않습니다.
  • Online run 또는 준비된 Offline run-offline 경로를 선택합니다. Offline은 타깃 호환 의존성 검증·네이티브 도구 준비를 완료해야 합니다. 브라우저 다운로드 폴더·추정 예제 경로 대신 Part.1의 실제 설치 경로를 사용합니다.

실제 환경에 맞게 Online 또는 Offline을 선택합니다. Online은 승인된 네트워크 접근을 사용합니다. Offline은 폐쇄 온프렘용 선택 사항으로 반입 전에 호환 제품·컴파일러·네이티브 도구 체인·선언된 의존성을 준비해야 합니다. 문서 다운로드에는 이 패키지가 없습니다.

빈 워크시트를 내려받아 guide-practice-01 같은 새 폴더에 비공개 작업 사본으로 저장합니다. JSON은 UTF-8 텍스트 편집기로 열고 따옴표와 미관찰 필드의 null을 유지하며 .json.txt가 아닌 .json으로 저장합니다. 워크시트는 기록 문서이며 제품 요청이 아닙니다. SDK나 Helper에 제출하지 마십시오.

단계를 순서대로 따라 하기

1 · 새 실습 폴더와 전체 입력 저장하기

수행할 작업: 새 비공개 폴더 guide-custom-01에 inputs·runs 하위 폴더를 만듭니다. custom-api-01.json·custom-api-02.json을 정확한 이름으로 inputs에 저장합니다. 폴더가 있으면 다른 새 이름을 정하고 경로 변수를 바꾸며 이전 폴더는 보존합니다.

결과 확인: 전체 입력 두 개가 존재합니다. 각각 request_id·correlation_id와 definition·source·mapping·fixture가 있는 draft를 포함합니다. 응답 조각만으로는 전체 SDK 입력이 되지 않습니다.

일치하지 않을 때: 브라우저가 .txt·중복 접미사를 붙이면 이전 작업을 덮어쓰지 않고 저장 파일명을 바로잡습니다. record_kind가 있는 워크시트는 기록이며 제출하지 않습니다.

2 · 스키마 확인과 첫 입력 분석하기

수행할 작업: custom-api-01.json을 엽니다. 선언 소스 출력 score는 string이고 fixture 응답은 "97"이며 STRING_TO_INTEGER 매핑이 quality_score를 대상으로 합니다. 설치된 SDK에서 아래 analyze 명령을 사용하고 종료 코드·실제 상태 및 사유를 보존합니다.

결과 확인: 문서화된 분석 검사에서 전체 입력이 수용됩니다. 스키마 선언·fixture 샘플을 실제 공급자 응답과 구분합니다.

일치하지 않을 때: 숫자 97·draft 누락·미지원 필드는 다른 입력입니다. 오류를 보존하고 사본에서 문서의 불일치만 수정한 뒤 후보 생성 전에 그 사본을 분석합니다.

3 · 선택 모드로 custom-01 한 번 생성하기

수행할 작업: Online은 inputs/custom-api-01.json과 미사용 runs/custom-01로 run을 사용합니다. Offline은 검증된 의존성과 필요한 문서의 macOS CLT 선택을 포함한 run-offline을 사용합니다. 후보 하나에 경로 하나만 사용하고 전체 반환 결과를 확인합니다.

결과 확인: 새 디렉터리에 README.md·adapter.rs·libadapter.rlib·manifest.json과 문서의 단계 및 파일 검사가 있습니다. 종료 비정상·후검사 실패는 후보 완료가 아닙니다.

일치하지 않을 때: 실패 시 custom-01·원래 결과를 보존하고 중단합니다. 실패를 숨기기 위해 즉시 명령 모드를 바꾸거나 같은 출력 디렉터리를 재사용하지 않습니다.

4 · custom-02의 응답 값 두 개만 변경하기

수행할 작업: 제공된 두 번째 입력을 첫 번째와 비교합니다. draft.fixture.response.component는 "my-test-component", score는 "88"이 되며 둘 다 문자열입니다. 새 사본에서 직접 수정하거나 제공된 두 번째 전체 파일을 사용합니다. 이 실습에서는 스키마·매핑·타깃 식별자를 바꾸지 않습니다.

결과 확인: 두 번째 전체 JSON은 값 두 개만 다릅니다. 예제 요청·상관 식별자 재사용은 문서의 로컬 SDK 실습에 한정하며 실제 Helper·Work 제출에는 적용하지 않습니다.

일치하지 않을 때: score를 JSON 숫자 88로 바꾸거나 전체 파일을 표시된 응답 조각으로 대체했으면 중단하고 문자열 타입의 전체 입력을 복원합니다.

5 · 분석 후 두 번째 미사용 출력에 생성하기

수행할 작업: custom-api-02.json을 분석한 뒤 같은 선택 명령 모드·네이티브 옵션으로 runs/custom-02를 사용합니다. custom-01을 덮어쓰지 않습니다. 필수 검사가 모두 완료되면 두 매니페스트·소스 파일을 엽니다.

결과 확인: 입력·단계 결과에 각각 연결된 후보 폴더가 두 개 있습니다. fixture 값이 바뀌어도 매핑은 같을 수 있습니다.

일치하지 않을 때: 분석·생성이 실패하면 두 번째 결과를 분리 보존하고 아래 정확한 오류 사례를 사용합니다. 완료된 custom-02를 만들기 위해 custom-01의 성공 파일을 복사하지 않습니다.

6 · 출력 비교와 후보 범위 기록하기

수행할 작업: 각 폴더의 README.md·adapter.rs·manifest.json을 읽습니다. 입력 지문·단계 결과·파일을 각각 비교합니다. 문서의 매니페스트 상태는 CUSTOMER_REVIEW_CANDIDATE이고 authority_granted는 false입니다. fixture 변경으로 adapter.rs가 같아도 매니페스트 관찰은 달라질 수 있습니다.

결과 확인: 관찰 기록에 두 입력·출력 경로·각 소스 및 라이브러리 지문·실제 매니페스트 결과·다음 연동 검토자가 있습니다. 런타임 등록·실제 API 연결을 주장하지 않습니다.

일치하지 않을 때: 라이브러리가 다르면 매니페스트 수동 수정 대신 정확한 도구 체인·입력을 비교합니다. 재현 가능하게 생성 코드를 바꾸려면 지원되는 입력 선언·매핑을 변경하고 새 후보를 만듭니다.

수정 가능한 기록·입력·출력 예시

입력 변경 · 전체 SDK 요청이 아닌 응답 조각

이 조각은 수정할 두 값의 위치만 보여줍니다. SDK 실행에는 다운로드한 전체 입력을 사용합니다. 기준 응답은 component "fixture-component"·score "97"입니다.

JSON
{
  "draft": {
    "fixture": {
      "response": {
        "component": "my-test-component",
        "score": "88"
      }
    }
  }
}

macOS / Linux · 새 비공개 폴더 생성

자신의 OS 블록만 사용합니다. 생성 성공 후 다운로드 링크로 전체 JSON 두 개를 위 inputs 폴더에 저장하고 동일 터미널에서 계속합니다. 독자용 명령 예시이며 웹페이지가 디렉터리를 생성하지는 않습니다.

Shell
# macOS / Linux: run this folder-creation block first
PRACTICE="$HOME/guide-custom-01"
(
  umask 077
  mkdir "$PRACTICE" && mkdir "$PRACTICE/inputs" "$PRACTICE/runs"
)
# Stop if mkdir reports that the folder exists.

Windows PowerShell · 새 폴더 생성

자신의 OS 블록만 사용합니다. 생성 성공 후 다운로드 링크로 전체 JSON 두 개를 위 inputs 폴더에 저장하고 동일 터미널에서 계속합니다. 독자용 명령 예시이며 웹페이지가 디렉터리를 생성하지는 않습니다.

PowerShell
$Practice = Join-Path $env:USERPROFILE 'guide-custom-01'
if (Test-Path -LiteralPath $Practice) { throw 'Choose a fresh practice folder' }
New-Item -ItemType Directory -Path $Practice -ErrorAction Stop | Out-Null
New-Item -ItemType Directory -Path (Join-Path $Practice 'inputs'),(Join-Path $Practice 'runs') -ErrorAction Stop | Out-Null

macOS / Linux · 경로 설정·분석·Online 생성

동일 터미널에서 한 줄씩 실행하고 echo $?로 종료 코드를 즉시 확인한 뒤 반환 검사를 읽고 계속합니다. 실제 설치 경로를 사용합니다. Offline은 위 run 행 대신 아래 대안을 사용합니다.

Shell
SDK_EXE="$HOME/VibePackr-SDK-install-01/sdk/bin/packr-sdk-engine"
PRACTICE="$HOME/guide-custom-01"
# First create this fresh private folder and save the two complete inputs.
# Run each line only after the previous command and result checks succeed.
"$SDK_EXE" analyze "$PRACTICE/inputs/custom-api-01.json" unused
"$SDK_EXE" run "$PRACTICE/inputs/custom-api-01.json" "$PRACTICE/runs/custom-01"
"$SDK_EXE" analyze "$PRACTICE/inputs/custom-api-02.json" unused
"$SDK_EXE" run "$PRACTICE/inputs/custom-api-02.json" "$PRACTICE/runs/custom-02"

Windows PowerShell · 분석·Online 생성

새 디렉터리 생성·입력 저장을 먼저 합니다. 프로세스 반환 코드 외에 모든 출력 검사도 유지합니다. macOS 셸 변수 할당을 PowerShell에 붙여넣지 않습니다.

PowerShell
$SdkExe = Join-Path $env:USERPROFILE 'VibePackr-SDK-install-01\sdk\bin\packr-sdk-engine.exe'
$Practice = Join-Path $env:USERPROFILE 'guide-custom-01'
& $SdkExe analyze (Join-Path $Practice 'inputs\custom-api-01.json') unused
if ($LASTEXITCODE -ne 0) { throw 'Stop and preserve analysis error' }
& $SdkExe run (Join-Path $Practice 'inputs\custom-api-01.json') (Join-Path $Practice 'runs\custom-01')
if ($LASTEXITCODE -ne 0) { throw 'Stop and preserve candidate error' }
# Continue only after inspecting all required first-candidate checks.
& $SdkExe analyze (Join-Path $Practice 'inputs\custom-api-02.json') unused
if ($LASTEXITCODE -ne 0) { throw 'Stop and preserve second analysis error' }
& $SdkExe run (Join-Path $Practice 'inputs\custom-api-02.json') (Join-Path $Practice 'runs\custom-02')
if ($LASTEXITCODE -ne 0) { throw 'Stop and preserve second candidate error' }

macOS / Linux · Offline 대안

정확한 타깃·의존성 검증 후 Online run 행 대신 사용합니다. macOS CLT 선택이 해당되면 실행 전에 run-offline 명령에 --macos-developer-selection COMMAND_LINE_TOOLS를 붙입니다. 후보 02에도 같은 선택을 유지하며 같은 출력 폴더에 대안 두 개를 실행하지 않습니다.

Shell
# macOS / Linux: use instead of run, after dependency verification
SDK_DEPS="$HOME/VibePackr-SDK-install-01/dependencies"
"$SDK_EXE" run-offline "$PRACTICE/inputs/custom-api-01.json" "$PRACTICE/runs/custom-01" "$SDK_DEPS"
# Repeat only after success, using input 02 and output custom-02.
# macOS CLT selection, if applicable, adds:
# --macos-developer-selection COMMAND_LINE_TOOLS

Windows PowerShell · Offline 대안

입력마다 분석을 먼저 합니다. 실제 검증된 의존성 경로를 사용합니다. 이 행들은 Online run을 대체하며 같은 후보 디렉터리에 Online 실행 뒤 이어 실행하지 않습니다.

PowerShell
$SdkDeps = Join-Path $env:USERPROFILE 'VibePackr-SDK-install-01\dependencies'
& $SdkExe run-offline (Join-Path $Practice 'inputs\custom-api-01.json') (Join-Path $Practice 'runs\custom-01') $SdkDeps
if ($LASTEXITCODE -ne 0) { throw 'Stop and preserve first offline candidate error' }
# Continue only after all first-candidate checks pass.
& $SdkExe run-offline (Join-Path $Practice 'inputs\custom-api-02.json') (Join-Path $Practice 'runs\custom-02') $SdkDeps
if ($LASTEXITCODE -ne 0) { throw 'Stop and preserve second offline candidate error' }

기대 출력 구성 · 자신의 실제 결과 확인

이 트리는 문서의 기대 구성이며 실행 캡처가 아닙니다. 텍스트 파일은 편집기로 엽니다. .rlib은 바이너리 라이브러리이며 더블클릭 실행 앱이 아닙니다. Part.5의 OS별 파일 지문 명령을 사용합니다.

Text
runs/
  custom-01/
    README.md
    adapter.rs
    libadapter.rlib
    manifest.json
  custom-02/
    README.md
    adapter.rs
    libadapter.rlib
    manifest.json

증거와 다음 조치가 있는 문제 해결

보존 사례는 명시된 릴리스·환경의 이미 공개된 관찰을 인용합니다. 절차 예시는 대응 방법 설명이며 추가로 관찰한 사고가 아닙니다. 이 가이드 작성을 위해 제품을 실행하지 않았습니다.

DISCOVER 통과 후 NORMALIZE 거부

보존된 실제 관찰 사례

증상: 보존 로컬 status 예제는 DISCOVER·PASSED·DISCOVERED 후 NORMALIZE·DENIED·CONTRACT_INCOMPATIBLE·lifecycle_stage null을 반환했습니다.

증거의 의미: 의도적으로 연결되지 않은 타깃은 발견 통과만으로 호환되지 않습니다. 종료 0과 의미상 거부가 함께 올 수 있으므로 status·reason을 읽어야 합니다.

공개 결과 객체 원문

JSON
{
  "operation": "NORMALIZE",
  "request_id": "example-status-discover-001",
  "status": "DENIED",
  "reason": "CONTRACT_INCOMPATIBLE",
  "lifecycle_stage": null
}

조치

  1. 두 원래 결과 발췌·소스 문서를 보존합니다.
  2. 공급자로부터 정확한 지원 타깃 Contract·어댑터 리비전을 확보합니다. 새 타깃 이름을 만들어도 경계가 해결되지 않습니다.

완료 또는 재개 확인: 의존 등록 단계 전에 완전한 호환 요청·패키지와 별도로 관찰한 정규화 성공이 필요합니다.

출처와 원래 범위 읽기

필수 속성이 선언되지 않음

보존된 실제 관찰 사례

증상: 보존 의도적 오류 예제에서 속성을 정의하지 않고 output_schema.required에 uptime을 추가하자 DENIED / SCHEMA_INCOMPATIBLE이 발생했습니다.

증거의 의미: 필수 목록·선언한 기본 타입 속성이 맞아야 하며 설명 문장은 기계 입력 필드를 정의하지 않습니다.

공개 결과 객체 원문

JSON
{
  "operation": "DISCOVER",
  "request_id": "example-status-discover-001",
  "status": "DENIED",
  "reason": "SCHEMA_INCOMPATIBLE",
  "lifecycle_stage": null
}

조치

  1. required의 각 이름을 properties와 비교하고 철자·대소문자를 확인합니다.
  2. 소스 사본에서 실제 필요한 지원 기본 타입 속성을 선언하거나 의도하지 않은 필수 항목을 제거합니다.

완료 또는 재개 확인: 제공된 지원 준비 절차로 수정한 전체 소스를 재확인하며 발췌에서 전체 R2 봉투를 만들어내지 않습니다.

출처와 원래 범위 읽기

미지원 메타데이터 필드 거부

보존된 실제 관찰 사례

증상: 보존 파싱 예제에서 프로토콜 문서에 description을 추가하자 request_id UNAVAILABLE과 DENIED / INVALID_REQUEST가 발생했습니다.

증거의 의미: 사람 설명·지원 기계 스키마는 다릅니다. 익숙한 JSON 필드라도 이곳에서 자동 허용되는 것은 아닙니다.

공개 결과 객체 원문

JSON
{
  "operation": "DISCOVER",
  "request_id": "UNAVAILABLE",
  "status": "DENIED",
  "reason": "INVALID_REQUEST",
  "lifecycle_stage": null
}

조치

  1. 파서 결과를 보존하고 전체 문서화된 소스 예제와 비교합니다.
  2. 설명 문장은 가이드·브리프로 옮기고 사본에서 미지원 기계 입력 필드를 제거합니다.

완료 또는 재개 확인: Contract를 바꾸거나 불명 필드를 묵인하지 않고 지원 소스 구성을 확인합니다.

출처와 원래 범위 읽기

미지원 MCP 리비전 거부

보존된 실제 관찰 사례

증상: MCP 리비전 2099-01-01을 사용한 보존 의도적 오류 예제는 DENIED / PROTOCOL_REVISION_MISMATCH를 반환했습니다.

증거의 의미: 트랜스크립트 리비전은 지원 협상 프로토콜과 맞아야 하며 다른 트랜스크립트에 이름만 바꿔 붙여도 호환되지 않습니다.

공개 결과 객체 원문

JSON
{
  "operation": "DISCOVER",
  "request_id": "example-mcp-discover-001",
  "status": "DENIED",
  "reason": "PROTOCOL_REVISION_MISMATCH",
  "lifecycle_stage": null
}

조치

  1. 원래 트랜스크립트·정확한 리비전 오류를 보존합니다.
  2. 제공 절차에 따라 지원 리비전에서 실제 수집한 트랜스크립트를 사용하며 버전 문자열만 바꾸지 않습니다.

완료 또는 재개 확인: 거부 필드를 없애는 대신 지원 전체 입력·실제 준비 결과로 호환성을 확인합니다.

출처와 원래 범위 읽기

score 숫자 변경 또는 전체 입력의 조각 대체

대응 절차 예시 · 새 관찰 사고 아님

증상: 설명용 예: score가 "88"이 아닌 88이거나 표시된 응답 객체만 SDK 입력으로 전달합니다.

증거의 의미: 문서의 소스 score 스키마는 string이며 STRING_TO_INTEGER는 명시적 매핑입니다. SDK에는 응답만이 아닌 전체 요청·draft 구성이 필요합니다.

조치

  1. 전체 custom-api-02.json과 비교하고 따옴표 있는 응답 문자열 두 개를 복원합니다.
  2. 실습의 다른 필드는 유지하고 새 입력 사본을 분석한 뒤 새 출력을 생성합니다.

완료 또는 재개 확인: 전체 지원 입력이 분석·모든 후보 검사를 통과해야 하며 워크시트·수동 수정 매니페스트로 대체하지 않습니다.

출처와 원래 범위 읽기

마무리와 인계

전체 입력 두 개·후보 폴더·실제 매니페스트·파일별 지문·명령 모드·도구 버전을 보존합니다. 최초 Helper B 확인은 선언 완성 후, 선택 SDK·Builder 작성 전에 수행합니다. 편집 후에는 영향을 받은 지원 검사를 다시 수행하고 별도 구현 검토·등록·Pack 승인 경로를 마친 뒤 사용합니다. 기존 구현·등록·릴리스 호환 연동은 SDK 작성을, 목표·설치 범위에 맞는 기존 승인 Pack은 Builder 작성을 생략할 수 있습니다.

가이드와 Part.1–8 연결

가이드에서 목적을 고른 뒤 해당 Part에서 정확한 도구 단계를 확인합니다. 두 문서는 같은 순서·용어·자료 역할을 사용합니다.

소스·요청·SDK 후보·실제 Work는 다른 단계이며 표에서 각 자료를 설명합니다.
소스·요청·SDK 후보·실제 Work는 다른 단계이며 표에서 각 자료를 설명합니다.

목적별 가이드

  • PoC 공통 가이드

    질문을 정하고 범위에 맞는 관찰을 모아 결과를 검토합니다. 보존 기록 독해에는 신규 설치가 필요하지 않습니다.

  • Google 심사자 가이드

    정확한 심사 전달물과 기준 증거를 연결합니다. Cloud 접근·문서 범위·실제 Google 승인은 각각 구분합니다.

  • 온프레미스 가이드

    정확한 OS·패키지·네트워크 선택·도구 체인을 준비합니다. 로컬 SDK 준비 요건이 제공된 뒤에만 해당 단축 경로를 사용합니다.

  • Custom Execution 가이드

    지원 작업을 선택합니다. 소스 문서 준비·전체 SDK 후보·실제 Work 및 보고서 확인을 서로 다른 경로로 구분합니다.

권장 연동 순서와 단축 경로
  1. Part.1 · 설치·준비
  2. Part.2 · GAPE 구조 관찰
  3. Part.3A · Integration Helper 계획
  4. Part.4 · 소스 Document 작성·게시된 대상 Contract 연결
  5. Part.3B · 전체 요청 확인·구현 필요 여부 확인
  6. 필요 시 Part.5 · SDK 후보·구현 검토·별도 등록
  7. 필요 시 Part.6 · Builder Pack 후보·승인 경로
  8. Part.7 · 허용된 GUI·헤드리스 사용
  9. Part.8 · 결과·문제 해결·사람 검토

Helper B는 구현·새 Pack 필요 여부를 결정하기 전에 완성된 선언을 확인합니다. 구현·선언 변경 후에는 영향을 받은 지원 검사를 다시 수행하고 별도 구현·등록·Pack 승인 경로를 마친 뒤 사용합니다. 생성 후보는 운영 권한을 부여하지 않습니다.

목표에 필요한 경로만 선택합니다. 보존 PoC 독해는 설치 없이 시작할 수 있습니다. 제공된 로컬 SDK 실습은 Part.1 → Part.5를 따르며 새 GAPE 관찰·어플라이언스 계정이 필요하지 않습니다. 기존 승인 Pack은 현재 준비 요건 확인 후 Part.1 → Part.7 → Part.8을 따를 수 있습니다. 새 연동·Pack 작성은 조건부 전체 순서를 따릅니다.

Part 연결과 도구 역할
구성 요소역할과 기대 범위
Part.1 · 설치·초기 연결OS 준비·제공 패키지·초기 연결입니다. 설치는 실행된 Work가 아닙니다.
Part.2 · GAPE 관찰·비교·공유리비전에 고정된 구조 관찰입니다. 워크시트는 승인된 GAPE 입력 매니페스트가 아닙니다.
Part.3 · Integration Helper 사용A는 Document 작성 전 계획, B는 완성된 전체 요청 확인입니다. 단계마다 타입이 있는 status·reason을 읽습니다.
Part.4 · Contract·Document 작성소스 Document·매핑을 작성하고 제공된 대상 Contract·리비전을 사용합니다. JSON 구문만으로 의미상 호환성이 확인되지 않습니다.
Part.5 · SDK Engine 실습·연동 후보로컬 SDK 구현 후보를 생성합니다. 기존 구현·등록·릴리스 호환 연동이 요구를 충족하면 재사용합니다.
Part.6 · Builder·추가 Pack 사용새 Pack이 필요할 때 Pack 후보를 준비합니다. 목표·설치 범위에 맞는 기존 승인 Pack은 재사용합니다.
Part.7 · PackrGUI·헤드리스 사용현재 권한·사전 조건에 따라 제공 GUI·헤드리스 경로를 사용합니다. 반환된 Work 식별·결과를 확인합니다.
Part.8 · 운영·문제 해결·지원동일 Work 산출물·영수증·종결을 비교하며 사람 인수은 실제 기록될 때까지 대기로 유지합니다.
공통 용어
가이드 / Part
가이드는 목적·역할 경로이고 Part는 도구 설명입니다. 서로 보완하며 경쟁하는 두 번호 순서가 아닙니다.
Contract / 소스 Document
게시된 대상 Contract는 지원 대상·리비전을 정합니다. 소스 Document는 소스 형식을 선언합니다. 소스 선언은 실행을 승인하지 않습니다.
전체 요청 / 소스 전용 파일
전체 SDK 요청은 request_id·correlation_id와 definition·source·mapping·fixture가 있는 draft를 포함합니다. status 소스 Document는 한 구성 요소이며 전체 요청이 아닙니다.
Fixture / 실제 관찰
fixture는 선언된 로컬 실습의 합성 값을 제공합니다. 선언 필드는 실제 공급자 호출·현재 연결·고객 결과를 입증하지 않습니다.
SDK 후보 / Pack 후보
SDK 후보에는 README.md·adapter.rs·libadapter.rlib·manifest.json이 있습니다. Builder Pack 후보는 별도 제품 반환 후보이며 자체 검증·승인 경로를 가집니다. 어느 쪽도 자동으로 승인 Pack이 되지 않습니다.
워크시트 / 영수증 / 인수
워크시트는 사람 기록입니다. 영수증은 제품 실행 기록입니다. 검증 PASSED·자동화 완료와 사람 인수 대기는 함께 존재할 수 있으며 각 필드의 실제 범위를 기록합니다.
온라인 / 오프라인
구성 선택 사항입니다. Offline 제품 개발에는 정확한 선언 의존성 세트·네이티브 도구가 필요하며 오프라인 매뉴얼 ZIP은 문서 열람을 지원합니다.
입력별 올바른 출력 연결

status.read 소스 전용 예제와 read_quality SDK 실습은 서로 다른 예제입니다. 일치하는 전체 요청을 사용하고 status 소스 파일을 quality SDK 전체 요청으로 제출하지 않습니다. 아래 매핑 값은 설명을 위한 기대값이며 새 실행 캡처가 아닙니다.

파일 / 역할입력출력 / 확인
status-document.json

status.read의 소스 전용 CUSTOM_API 선언입니다. 제공된 전체 준비 요청 안에서 사용합니다.

service: string(문자열)service: string·healthy: boolean을 선언합니다. 스키마이며 관찰된 서비스 응답이 아닙니다.
read-only-custom-api.json / custom-api-01.json

유지관리되는 전체 SDK 기준 요청이며 가이드 사본은 같은 JSON입니다.

fixture.response.component = "fixture-component"; score = "97" (문자열)STRING_TO_INTEGER는 score를 기대 정수 quality_score 97로 매핑합니다. 문서의 SDK 결과는 로컬 후보입니다.
custom-api-02.json

fixture 응답 값 두 개만 바꾼 두 번째 전체 SDK 요청입니다.

component = "my-test-component"; score = "88" (문자열)기대 매핑 component는 "my-test-component", quality_score는 정수 88입니다. 실제 매니페스트·단계를 확인하며 매핑 소스는 같을 수 있습니다.
custom-api-score-number.json

정상 기준 예제가 아닌 의도적 오류 입력입니다.

선언된 문자열 스키마에 fixture.response.score = 88 (JSON 숫자) 사용실제 타입 오류 결과를 보존하며 이 예제를 성공 후보로 기록하지 않습니다.
Worksheet / SDK artifacts / Work reports

사람 기록·로컬 컴파일 후보·실제 Work 및 보고서·영수증이라는 서로 다른 산출물 종류입니다.

해당 도구·현재 타깃을 사용하며 워크시트·이전 결과를 다음 전체 요청으로 제출하지 않습니다.실제 입력·버전·후보 또는 Work 식별에 출력을 연결합니다. 파일 존재·종료 0만으로는 충분하지 않습니다.
Pack 시스템 개념 · 영문 SVG 판

사용자가 제공한 2026년 10월 8일 v1.5 개념도입니다. 고객 운영 Pack은 선언된 Contract·권한 안에서 동작하고 Builder는 검증·승인이 필요한 후보를 준비합니다. Pack 종류·자기 적응 표기는 예시·릴리스별이며 현재 실행 가능한 기능 목록이 아닙니다. 현재 표시본은 문서 변경을 반영한 영문 SVG이며, 이전 래스터 원본은 보존합니다.

Pack 시스템 개념 · 영문 SVG 판

SVG 그림 원본 크기로 열기

最新 매뉴얼 순서와 범위 참고

최신 매뉴얼과 사용 순서

최신 설치·도구 실습·문제 해결은 Part.1–8을 따르십시오. 아래 보존 예제와 워크북은 원래 릴리스·목적·관찰 범위를 유지합니다.

  1. Part.1 · 설치·준비
  2. Part.2 · GAPE 구조 관찰
  3. Part.3A · Integration Helper 계획
  4. Part.4 · 소스 Document 작성·게시된 대상 Contract 연결
  5. Part.3B · 전체 요청 확인·구현 필요 여부 확인
  6. 필요 시 Part.5 · SDK 후보·구현 검토·별도 등록
  7. 필요 시 Part.6 · Builder Pack 후보·승인 경로
  8. Part.7 · 허용된 GUI·헤드리스 사용
  9. Part.8 · 결과·문제 해결·사람 검토

Helper B는 구현·새 Pack 필요 여부를 결정하기 전에 완성된 선언을 확인합니다. 구현·선언 변경 후에는 영향을 받은 지원 검사를 다시 수행하고 별도 구현·등록·Pack 승인 경로를 마친 뒤 사용합니다. 생성 후보는 운영 권한을 부여하지 않습니다.

목표에 필요한 경로만 선택합니다. 보존 PoC 독해는 설치 없이 시작할 수 있습니다. 제공된 로컬 SDK 실습은 Part.1 → Part.5를 따르며 새 GAPE 관찰·어플라이언스 계정이 필요하지 않습니다. 기존 승인 Pack은 현재 준비 요건 확인 후 Part.1 → Part.7 → Part.8을 따를 수 있습니다. 새 연동·Pack 작성은 조건부 전체 순서를 따릅니다.

설치 릴리스와 호환되며 구현·등록된 기존 연동이 요구를 충족할 때만 SDK 작성을 생략합니다. 기존 승인 Pack이 목표와 설치 범위를 충족할 때만 Builder 제작을 생략합니다. 어느 경우든 선언 확인·연동 검증·결과 검토는 수행합니다.

Online과 Offline 모두 선택 가능한 구성

Online은 해당 설치에서 승인한 네트워크 접근을 사용합니다. Offline은 폐쇄 온프렘용 선택 사항이며, 반입 전에 정확한 OS·타깃 도구 체인과 의존성 세트를 준비합니다. 매뉴얼 ZIP에는 문서와 합성 입력이 있으며 제품 바이너리나 Rust 도구 체인은 없습니다.

다섯 작업 경로와 최신 매뉴얼 연결

아래에서 작업 경로를 선택하고 해당 Part에서 정확한 입력·기대 출력을 확인합니다. 새 선언은 Part.4, 어댑터 구현은 Part.5, Pack 작성은 Part.6, 기존 Work·보고서 점검은 Part.7–8을 사용합니다. Helper A는 Document 전에 계획하고 Helper B는 선택적 SDK·Builder 작업 전에 완성된 요청을 검사합니다. 변경 후에는 영향받는 지원 검사를 반복합니다.

Custom API 실습은 문서의 합성 JSON을 새 작업 폴더에 복사하고 의도한 필드만 수정한 뒤 설치된 SDK 절차를 사용합니다. 새 출력의 adapter.rs와 manifest.json을 확인하고 입력·출력 지문과 SDK·컴파일러·타깃 버전을 기록합니다. 생성 후보에는 문서의 연동·검증 단계가 여전히 필요합니다.

예: score나 component 변경은 어댑터 소스가 같아도 매니페스트 메타데이터를 바꿀 수 있습니다. 산출물을 각각 비교합니다. 라이브러리 지문이 다르면 재현성 결론 전에 정확한 입력·도구 체인·타깃·의존성 세트를 비교합니다.

준비 워크시트가 완성되어도 DENIED·CONTRACT_INCOMPATIBLE·의존성 누락·후검사 실패는 제품 단계의 실패 또는 차단으로 남습니다. 결과를 보존하고 새 후보에서 문서의 준비 요건을 해결하며 이전 출력은 유지합니다.

다른 가이드 선택 · Part.1–8 열기

필요한 결과 선택

  1. 선택
  2. 준비
  3. 지원되는 단계 수행
  4. 검증
  5. 종결 또는 인계

지원되는 작업 하나를 고르고 정확한 인계 자료를 확보한 뒤 정해진 단계를 따라 결과와 다음 담당자를 기록합니다. 다섯 사례는 준비·관찰·보고서 검증·승인된 구성 변경·AI 계획을 구분합니다.

입력 준비

연동 소스 문서 하나 준비

status.read 작업을 설명하고 지원 대상 패키지가 제공해야 할 내용을 식별합니다.

지금 로컬 문서 준비와 공개 결과 읽기를 할 수 있습니다. 완전한 고객용 Helper 요청 패키지는 여전히 별도의 전제조건입니다.

작업 열기 →
요건을 충족한 설치 사용

제공된 헤드리스 서비스 하나 관찰

Work를 제출하거나 서비스를 변경하지 않고 서비스 존재 여부·준비 상태·사유를 기록합니다.

지금 참고 자료를 읽을 수 있습니다. 읽기 전용 조회는 제공된 클라이언트·의도한 로컬 서비스·승인된 조회 접근 권한이 있을 때만 실행합니다.

작업 열기 →
읽기 및 검증

기존 Work 보고서 검증

전달된 JSON·PDF가 선택한 동일 Work에 속하고 보고된 파일 지문과 일치하는지 확인합니다.

지금 공개 예제를 읽을 수 있습니다. 실제 파일 확인에는 선택한 Work·리비전과 보고서 파일에 대한 승인된 접근이 필요합니다.

작업 열기 →
요건을 충족한 설치 사용

승인된 로깅 변경 하나 검토

승인된 log_level WARN 변경만 적용하고 동작 영수증·저장 값·실제 적용 동작을 구분합니다.

설정과 권한을 갖춘 관리자 설치 및 별도로 승인된 변경이 필요합니다. 기록된 로컬 수정 후보가 신규 r232 초기 설정을 제공하지는 않습니다.

작업 열기 →
인계 계획

AI 설정 인계 자료 준비

모델·ID·데이터·예산·설정 의존성을 담당자가 해결할 만큼 구체화합니다.

지금 계획을 세울 수 있습니다. 통제된 제품·제공자 호출에는 여전히 지원되는 고객 설정·정확한 런타임 바인딩·명시적인 작업 권한이 필요합니다.

작업 열기 →

준비하는 작업의 유형 이해

Custom은 제공된 환경을 위한 작업을 뜻합니다. 임의의 코드 실행이나 새로운 제품 계약을 의미하지 않습니다.

  • 전달된 버전이 일치하고 접근과 작업 허용이 확인된 경우에만 문서화된 인터페이스를 사용합니다. 동결 이미지 외부에서 바뀌는 파일·구성을 기록하십시오.
  • 연결된 관리자 시연은 격리된 수정 후보를 사용했습니다. 소스 수정은 과거 시연의 맥락이며 Golden r232를 수정하라는 지침이 아닙니다.
  • 신규 r232의 관리자 의존 사용은 C7에서 여전히 차단됩니다. 누락된 전달물·지원 설정은 담당자 인계 자료에 기록합니다.
  • Helper 준비·GAPE 투영 읽기·AI 연결 계획의 입력과 완료 지점은 서로 다릅니다. 준비 단계 성공은 실시간 연결을 입증하지 않습니다.
정확한 전제조건 인계 기록 →

작업 하나를 정해진 결과까지 수행

기대 관찰은 확인할 내용을 설명합니다. 빈 워크북에는 자신의 관찰만 입력하십시오.

입력 준비연동 소스 문서 하나 준비
현재 경로
지금 로컬 문서 준비와 공개 결과 읽기를 할 수 있습니다. 완전한 고객용 Helper 요청 패키지는 여전히 별도의 전제조건입니다.
목표
status.read 작업을 설명하고 지원 대상 패키지가 제공해야 할 내용을 식별합니다.
예상되는 변경
호출자 소유의 로컬 문서만 생성·편집합니다. 제품 등록·런타임 구성·제공자 요청은 수행하지 않습니다.
증거 범위
여기서는 JSON 문법과 소스 필드를 검토할 수 있습니다. 공개된 DISCOVER PASSED는 로컬 소스 탐색을 입증하며, NORMALIZE DENIED / CONTRACT_INCOMPATIBLE에서는 대상 호환성이 미확정입니다.

준비할 입력

  • 비밀이 아닌 작업 브리프 및 서비스 설명 담당자.
  • 공개 status-document.json 소스 예제와 필드 참고 자료. 원본을 보존하고 사본을 편집합니다.
  • 제공된 도구·빌드·대상 참조를 기록하거나 알 수 없음으로 표시합니다. 기록된 macOS Helper 빌드 식별자는 입증되지 않았습니다.

1. 소스 설명

브리프에 읽기 작업 이름, 입력 service:string 및 출력 service:string·healthy:boolean을 명시합니다. 선언된 구조를 실제 요청 값이나 실시간 응답과 구분하십시오.

기대 관찰
서비스 호출을 주장하지 않는 검토 가능한 작업 설명 한 건.
보존
작업 브리프, 데이터 담당자 및 승인된 비기밀 샘플 참조.
일치하지 않을 때
의도한 서비스나 데이터 사용이 불명확하면 담당자에게 설명을 돌려보냅니다.
상세 참고 자료 →

2. 소스 사본 편집 및 확인

CUSTOM_API 필드 표에 따라 프로토콜 리비전 1, 기본형 속성 유형 및 일관된 필수 목록을 유지합니다. Python 3가 있으면 공개된 JSON 문법 검사를 사용합니다. 메모는 지원하지 않는 JSON 필드 대신 브리프에 남깁니다.

기대 관찰
읽을 수 있는 JSON 소스 문서. 문법 성공은 제품 검증과 별도로 기록합니다.
보존
원본·소스 사본 참조, 의도한 편집 및 실제 문법 결과.
일치하지 않을 때
사본에서 식별된 형식 오류만 수정합니다. 계약·자격 증명 필드를 만들어 추가하지 마십시오.
상세 참고 자료 →

3. 소스와 요청 봉투 구분

아직 필요한 공급자 소유 계약·어댑터 ID와 리비전을 나열합니다. 소스는 일치하는 완전한 요청의 draft.source에 들어갑니다. 공개 조각을 조합해 유효한 요청이라고 주장하거나 소스를 r2-discover에 직접 전달하지 마십시오.

기대 관찰
완전한 버전별 요청, 지원 대상 및 설치 경로를 위해 필요한 구체적인 누락 제공물 목록.
보존
제공된 대상 참조 또는 명시적인 알 수 없음과 담당 공급자 연락처.
일치하지 않을 때
일치하는 완전한 패키지가 없으면 제품 준비 명령 전에 중단합니다.
상세 참고 자료 →

4. 보존된 결과 읽기 및 인계

공개된 DISCOVER·NORMALIZE 발췌를 함께 읽고 각 operation·request_id·status·reason·lifecycle_stage를 기록합니다. 두 발췌의 요청 ID는 동일한 과거 값이며 검토할 기록이지 재사용할 키가 아닙니다. R2의 의미상 거부도 프로세스 종료 코드 0을 반환할 수 있으므로 JSON 결과를 읽으십시오.

기대 관찰
탐색 성공과 정규화 거부를 구분해 유지하고, 다음 담당자에게 누락된 대상·패키지 문제를 전달합니다.
보존
인용 발췌와 별도의 해석·다음 조치 메모.
일치하지 않을 때
DISCOVER PASSED만으로 정규화·등록·연결된 실행을 주장하지 마십시오.
상세 참고 자료 →

이 범위의 마무리

소스 사본, 실제로 수행한 문법 검사 결과, 올바르게 해석한 보존 결과 및 담당자를 명시한 누락 제공물 인계를 기록합니다.

종결 또는 인계

데이터 담당자의 보존 기준에 따라 원본·편집 사본을 보관합니다. 이 준비 경로에는 중지할 서비스가 없습니다. 공급자가 일치하는 완전한 패키지와 범위를 제공한 뒤에만 제품 준비를 계속합니다.

요건을 충족한 설치 사용제공된 헤드리스 서비스 하나 관찰
현재 경로
지금 참고 자료를 읽을 수 있습니다. 읽기 전용 조회는 제공된 클라이언트·의도한 로컬 서비스·승인된 조회 접근 권한이 있을 때만 실행합니다.
목표
Work를 제출하거나 서비스를 변경하지 않고 서비스 존재 여부·준비 상태·사유를 기록합니다.
예상되는 변경
서비스 상태를 조회하고 로컬 관찰 파일을 작성합니다. 서비스 시작·제공자 구성·Work 제출은 하지 않습니다.
증거 범위
조회 성공은 해당 대상·시각에 반환된 관찰을 입증합니다. Work 권한을 부여하거나 모든 의존 준비 항목을 입증하지는 않습니다.

준비할 입력

  • 정확한 클라이언트·서비스 릴리스, 지원 플랫폼 및 운영자 계정.
  • 제공된 로컬 소켓 및 의도한 서비스의 실행 확인. 데스크톱 터미널이 자동으로 어플라이언스 연결이 되는 것은 아닙니다.
  • 허용된 status·health 접근 및 새로운 비공개 출력 디렉터리.

1. 관찰 대상 확인

클라이언트 경로·서비스 릴리스·소켓·계정을 운영자 인계 자료와 대조합니다. 참고 도움말 검사로 제공된 명령을 확인하십시오.

기대 관찰
의도한 로컬 조회 맥락을 식별했습니다.
보존
대상·릴리스 및 비밀이 아닌 인계 참조.
일치하지 않을 때
클라이언트나 엔드포인트가 없으면 조회 전에 전달 담당자·운영자에게 인계합니다.
상세 참고 자료 →

2. status와 health 각각 수집

같은 클라이언트·소켓·계정으로 제공된 기준 상태 명령을 따릅니다. 각 종료 코드를 즉시 기록하고 status.json·health.json을 비공개로 보존합니다.

기대 관찰
각 종료 코드를 가진 조회 관찰 2건 또는 수행하지 않았거나 실패한 정확한 단계.
보존
관찰 시각·명령 참조·종료 코드·민감정보를 제거한 출처 참조.
일치하지 않을 때
전송 실패는 서비스를 자동 시작·재시작할 사유가 아닙니다.
상세 참고 자료 →

3. 구성 요소 상태 해석

생존·준비·권한·런타임 상태와 관련 사유를 원문대로 복사합니다. UNKNOWN을 명시하고 영향받는 구성 요소 담당자에게 다음 작업을 막는지 확인합니다.

기대 관찰
서비스 존재와 작업별 준비 상태를 구분한 관찰 요약.
보존
상태·사유 원문 및 다음 담당자에게 묻는 질문.
일치하지 않을 때
과거 실습의 예외를 이 설치에 적용하거나 종료 코드 0으로 권한을 추정하지 마십시오.
상세 참고 자료 →

이 범위의 마무리

의도한 대상과 실제 조회 결과를 기록하고, 답이 없는 준비 상태 질문에 담당자를 지정합니다.

종결 또는 인계

민감정보를 제거한 관찰을 보존하고 제공된 서비스는 그대로 둡니다. Work를 제출하지 않았음을 기록합니다. 이후 서비스·Work 동작은 별도로 지원되고 승인된 경로를 따릅니다.

읽기 및 검증기존 Work 보고서 검증
현재 경로
지금 공개 예제를 읽을 수 있습니다. 실제 파일 확인에는 선택한 Work·리비전과 보고서 파일에 대한 승인된 접근이 필요합니다.
목표
전달된 JSON·PDF가 선택한 동일 Work에 속하고 보고된 파일 지문과 일치하는지 확인합니다.
예상되는 변경
선택한 기록·파일을 읽고 로컬 검토 메모를 저장할 수 있습니다. 새 Work나 대체 보고서는 만들지 않습니다.
증거 범위
과거 비교를 읽으면 그 공개 자료가 보고한 내용을 확인할 수 있습니다. 현재 일치를 확인하려면 자신의 파일 관찰이 필요하며, 검증과 사람의 인수은 별개입니다.

준비할 입력

  • 권한 있는 운영자나 일치하는 읽기 조회에서 제공한 기존 Work ID 및 선택된 보고서 리비전.
  • 실제로 반환된 JSON·PDF 경로 또는 인계 출처를 확인할 수 있는 승인된 사본.
  • 해당 플랫폼에 승인된 로컬 뷰어·파일 검증기. 원시 보고서는 비공개로 보관합니다.

1. 선택한 기록 연결

같은 설치·계정 맥락을 유지하며 저장한 Work ID를 가능한 list·show·선택 보고서 참조와 대조합니다. 선택한 리비전을 기록하십시오.

기대 관찰
출처를 확인할 수 있는 Work·보고서 리비전 하나 또는 명시적인 불일치.
보존
Work·보고서·리비전 참조 및 동일 식별자 관찰.
일치하지 않을 때
선택 보고서가 없거나 식별자가 다르면 파일 확인 완료 주장을 중단합니다.
상세 참고 자료 →

2. 결과 및 종결 읽기

execution_count·validation_results·final_result·receipt/closure 및 반환된 retry·replay 필드를 복사합니다. human_acceptance의 null·대기 상태는 반환된 그대로 유지합니다.

기대 관찰
결과 원문과 제품 인수 상태를 검토자 판단과 별도로 기록합니다.
보존
선택한 보고서 필드 및 출처 참조.
일치하지 않을 때
제공되지 않은 값을 기록 예제로 채우지 마십시오.
상세 참고 자료 →

3. 실제 파일 검증

반환 경로나 승인된 사본을 사용합니다. JSON 바이트는 json_file_sha256, PDF 바이트는 pdf_sha256과 비교하고 비교할 때만 sha256: 접두부를 제거합니다. PDF를 열어 Work·결과를 JSON과 대조합니다.

기대 관찰
읽을 수 있고 지문 비교를 관찰한 동일 리비전 파일 또는 식별된 접근·불일치 문제.
보존
기대·관찰 파일 지문과 열람·식별자 관찰. 비공개 경로는 로컬에 보관합니다.
일치하지 않을 때
report_sha256은 원시 파일 체크섬이 아닙니다. 파일 누락·불일치는 서비스 운영자에게 전달하며 조용히 재생성하지 마십시오.
상세 참고 자료 →

이 범위의 마무리

검토에는 수행한 선택 파일 검사의 정확한 범위와 제품 인수 상태 원문을 기록합니다. 읽기만 수행했다면 그렇게 표시합니다.

종결 또는 인계

데이터 담당자의 보존 결정에 따라 원시 파일을 보관하고 승인된 참조만 공유합니다. 누락된 전달·검증에는 담당자를 기록합니다. 이 작업은 서비스를 중지하거나 Work를 수락하지 않습니다.

요건을 충족한 설치 사용승인된 로깅 변경 하나 검토
현재 경로
설정과 권한을 갖춘 관리자 설치 및 별도로 승인된 변경이 필요합니다. 기록된 로컬 수정 후보가 신규 r232 초기 설정을 제공하지는 않습니다.
목표
승인된 log_level WARN 변경만 적용하고 동작 영수증·저장 값·실제 적용 동작을 구분합니다.
예상되는 변경
승인 후 등록된 log_level 설정을 바꿀 수 있습니다. 표시된 {"log_level":"WARN"} 조각은 완전한 요청이 아니며, 이 구성 계약은 서비스 재시작을 요구하지 않습니다.
증거 범위
적용 결정·변경 플래그·리비전·감사 참조는 범위 내 기록된 동작을 입증합니다. 일반 투영은 값을 표시하지 않으므로 실제 WARN 적용은 설치가 지원하는 관찰로 확인해야 합니다.

준비할 입력

  • 정확한 조직·어플라이언스·설치, 현재 관리자·권한 참조 및 제공된 연결 프로필.
  • 변경 담당자의 정확한 승인, 현재 상태 검토 및 지원되는 구성 페이로드·절차.
  • 보존·복구 처리 방안 및 필요한 경우 지원되는 저장·적용 값 관찰.

1. 연결 및 기준 상태 수집

제공된 관리자 연결 체크리스트를 따릅니다. 반환된 대상 식별자를 확인하고 Refresh 후 어플라이언스 상태 리비전과 구성 리비전을 각각 기록합니다.

기대 관찰
현재 권한이 확인된 대상 및 그 대상에 귀속되는 기준 상태.
보존
대상·권한 참조·관찰 시각·두 리비전. 비공개 프로필 값은 로컬에 보관합니다.
일치하지 않을 때
대상 불일치나 관리자 설정 누락이 있으면 변경 경로를 중단합니다.
상세 참고 자료 →

2. 검토 및 한 번 제출

Appliance → Update configuration을 엽니다. Target·Expected revision을 현재 어플라이언스 상태 리비전과 대조하고, Requested change를 담당자가 승인한 log_level WARN 변경과 비교합니다. 다르면 취소하고 제공된 승인 범위에서만 한 번 제출합니다.

기대 관찰
미리 채운 APPLIED가 아닌 실제 결정·사유·변경 플래그·감사 참조.
보존
승인된 의도한 변경·예상 리비전·동작 응답 원문.
일치하지 않을 때
오래된 리비전은 새로 고침 후 재검토합니다. 불확실한 시간 초과는 기존 요청을 보존·대조한 뒤에만 다음 제출을 고려합니다.
상세 참고 자료 →

3. 영수증과 효과의 별도 검증

새로 고침 후 Audit에서 일치하는 동작·리비전을 확인합니다. 저장·적용 값은 운영자가 제공한 지원 관찰 경로로만 기록하고 그렇지 않으면 미관찰로 둡니다. 리비전 변경만으로 실제 적용 값을 시험한 것은 아닙니다.

기대 관찰
동작·리비전 증거 및 별도의 관찰되었거나 미해결인 저장·적용 상태 기록.
보존
감사 참조·동작 후 리비전·저장·적용 관찰의 출처.
일치하지 않을 때
효과가 입증되지 않으면 운영자에게 관찰을 배정합니다. 재시작으로 공백을 가리지 마십시오.
상세 참고 자료 →

4. 결과 보존 및 연결 해제

승인된 변경이 적용된 채 유지되는지 또는 명시적인 복구 결정을 기다리는지 기록합니다. 검토 후 연결을 해제합니다. 저장된 프로필 필드는 현재 스냅샷이 아닙니다. 필요하면 별도로 제공·승인된 복구 절차만 사용합니다.

기대 관찰
최종 연결 상태·보존된 변경 처리·다음 담당자를 명시합니다.
보존
최소 지원 기록 및 보존·복구 절차 참조.
일치하지 않을 때
일반 정리 작업으로 관리되는 프로필·키를 삭제하거나 반대 변경을 만들어 내지 마십시오.
상세 참고 자료 →

이 범위의 마무리

승인된 동작 한 건과 일치하는 감사·리비전을 기록합니다. 저장·적용 증거는 지원 경로로 관찰했거나 명시적인 미해결 상태여야 합니다.

종결 또는 인계

승인된 상태를 보존하거나 변경 담당자에게 복구 결정을 인계합니다. 연결을 해제하고 필수 이력을 보존합니다. 이 사례는 자동 롤백·서비스 재시작·고객 초기 설정을 하지 않습니다.

인계 계획AI 설정 인계 자료 준비
현재 경로
지금 계획을 세울 수 있습니다. 통제된 제품·제공자 호출에는 여전히 지원되는 고객 설정·정확한 런타임 바인딩·명시적인 작업 권한이 필요합니다.
목표
모델·ID·데이터·예산·설정 의존성을 담당자가 해결할 만큼 구체화합니다.
예상되는 변경
계획 워크시트만 만듭니다. API 활성화·IAM 변경·런타임 구성·Vertex AI 호출은 하지 않습니다.
증거 범위
완성한 계획은 실제 ID·모델·위치·바인딩·비용·데이터 조건을 확인할 담당자를 식별합니다. 연결된 AI나 고객 전체 과정의 증거가 아닙니다. GAPE 관찰·보조 도구의 문서 검토는 Vertex 실행과 별개입니다.

준비할 입력

  • 지정된 PoC·클라우드/AI·데이터 담당자 및 허용된 사용 사례 질문 하나.
  • 비밀이 아닌 프로젝트·위치·모델 선택 또는 명시적인 알 수 없음과 ID 담당자 참조.
  • 정확한 전달 릴리스 및 제공된 설정·바인딩 절차 참조 또는 누락 절차 요청 기록.

1. 비밀이 아닌 선택값 작성

공개 AI 워크시트에 프로젝트·지원 위치·정확한 모델·ID 담당자·승인된 데이터 등급·예산·재시도 한도를 기록합니다. 누락 값은 알 수 없음으로 둡니다.

기대 관찰
토큰·키·만들어 낸 모델 기본값이 없는 구체적인 계획.
보존
워크시트 및 담당자 확인 참조.
일치하지 않을 때
후속 설정에 앞서 불명확한 데이터 사용이나 비용 책임을 해결합니다.
상세 참고 자료 →

2. 설정 증거 배정

클라우드 담당자에게 API·청구, VM에 실제 연결된 서비스 ID, 추론 권한·접근 범위, 모델·위치 정책 및 네트워크를 확인하도록 요청합니다. 전달 담당자에게 정확한 지원 바인딩·설정 경로를 요청합니다. 증거에 따라 각 항목을 제공됨·대기·알 수 없음으로 기록합니다.

기대 관찰
각 전제조건에 담당자와 확보할 증거가 있습니다.
보존
비밀이 아닌 절차·ID 담당자·의존성 참조.
일치하지 않을 때
신규 r232의 관리자 의존 설정은 C7에서 여전히 중단 상태입니다. 테스트 초기화 도구나 다른 플랫폼의 인증 절차로 대체하지 마십시오.
상세 참고 자료 →

3. 향후 검사 정의 및 인계

별도 승인된 작은 작업이 입증할 항목을 합의합니다. 실제 선택한 모델·위치, 호출 전송 여부, 반환 결과, 제품 검증 및 측정 비용입니다. 기대 문구와 기록된 응답을 구분하십시오.

기대 관찰
범위가 정해진 향후 검사·중단 조건·담당자 및 재개 인계. 이 계획으로 호출을 수행하지 않았습니다.
보존
기대 결과·예산·보존 계획·누락 증거 목록.
일치하지 않을 때
선택된 런타임으로 제공자 호출을 추정하거나 누락 전제조건을 채우려고 제공자·모델을 조용히 바꾸지 마십시오.
상세 참고 자료 →

이 범위의 마무리

담당자는 제안한 작업, 필요한 설정 증거, 비용·데이터 한도 및 향후 승인된 평가의 정확한 조건을 확인할 수 있습니다.

종결 또는 인계

계획 기록을 보존하고 실제 호출·결과·비용 필드는 비워 둡니다. 지원되는 설정 문제를 전달·클라우드 담당자에게 인계합니다. 이 계획이 클라우드 리소스나 자격 증명 정리를 의미하지는 않습니다.

중단된 단계까지 포함한 완성 기록 보기

읽기 실습 예제는 서비스 상태 Document에서 공개 탐색 결과와 정규화 거부까지 추적합니다. 연동을 미해결로 유지하면서 유용한 담당자 인계를 보여 줍니다.

비공개 작업 기록 유지

범위가 정해진 기업 평가 · 다음 단계

고객 환경에서 통제된 작업 흐름 하나를 평가하십시오.

평가할 AI 작업 흐름 하나와 대상 실행 경계·승인 요건을 정리하세요. 기록된 로컬 R234 사례와 비교하거나 구조화된 PoC 평가 순서를 따르고, 2026년 10월 18일 영문·한국어 기술 백서를 참고하세요.

평가 문의 (이메일) 11단계 PoC 가이드 시작 → 기술 백서 (2026년 10월 18일 PDF) 한국어 PDF (KR)

연락 경계 안내: “평가 문의”를 클릭하면 로컬 메일 프로그램이 다음 수신 주소로 열립니다: support@vibepackr.com 로 구조화된 문의 양식이 열립니다. 이메일 전송만으로 지원 사례가 등록되거나 어플라이언스가 구성되지는 않습니다. 자격 증명·개인정보·기밀 로그를 포함하지 마십시오.