Part.1~8은 현재 도구별 매뉴얼, W1~W4와 GUI-01 같은 코드는 그 안의 실습입니다. Use Case 1~5는 보존한 작업 안내 번호이며 Part 번호와 다릅니다. Case A~J와 SDK-1·IH-1 같은 코드는 문제 해결 사례입니다. 이전 파일 이름과 pN 절 주소는 기존 북마크용으로 유지하므로 현재 Part는 본문 제목으로 확인합니다.

전체 흐름·Helper 전후 단계·SDK·Builder 생략 조건

새 연동·Pack의 권장 순서. 본문에서 각 단계와 생략 조건을 설명합니다. — SDK와 Builder는 필요한 경우 사용하며 등록·승인은 별도로 확인합니다.

먼저 작업 종류를 고르십시오

설치 뒤 모든 도구를 한 번씩 실행하는 절차는 아닙니다. 새 연동과 새 Pack을 만드는 경우의 권장 흐름은 아래와 같습니다. Part 번호는 기본 작성·사용 흐름에 맞췄습니다. Part.4 선언 뒤에는 Part.3B 검증으로 돌아가며, 필요 없는 SDK·Builder 작성은 생략합니다.

설치·환경 준비 — Part.1: 사용할 도구와 OS, Appliance·클라이언트 연결이 필요한 범위를 먼저 준비합니다.
GAPE로 구조 확인 — Part.2: 제공된 승인 snapshot/뷰어에서 대상 구성요소·인터페이스·리비전을 읽습니다. 새 관찰이 필요한 담당자만 승인 manifest와 소스로 snapshot을 생성합니다. 구조가 이미 확인된 단순 연동은 이 결과를 재사용할 수 있습니다.
Integration Helper로 계획 — Part.3: 연결하려는 기능과 정확한 대상, 필요한 입력·매핑·구현 공백을 정리합니다. GAPE 기반 r2-plan-architecture는 해당 릴리스의 완전한 계획 입력과 기존 Contract·registry·owner·authority 참조가 있을 때 사용합니다. 이것은 뒤의 r2-discover 요청과 다른 입력입니다. 지금 제공한 Custom API 실습 JSON을 계획 명령에 넣지 마십시오.
Document 작성·Contract 연결 — Part.4: 소스 API/MCP 입출력, required, 합성 fixture와 명시적 매핑을 완성합니다. 대상 Contract는 공급자가 이미 게시한 정확한 리비전을 선택합니다. 이 단계에서 고객이 제품 Contract를 새로 발행하는 것은 아닙니다. 계획에 쓰는 대상 참조는 3단계에서도 필요합니다.
Helper로 선언 검증·후보 준비 — Part.3: 완전한 요청으로 discover → normalize → validate → prepare → status를 한 단계씩 확인합니다. 거부 또는 구현 필요 상태에서는 그 사유를 해결합니다. 선언을 수정하면 영향을 받은 검증으로 돌아갑니다.
새 어댑터 구현이 필요한 경우 SDK Engine — Part.5: 지원되는 선언으로 analyze/generate/build/validate/package 후보를 만듭니다. adapter.rs, libadapter.rlib, README.md, manifest.json을 검토합니다. 이 SDK 후보는 합성 자료 기반이며 실제 API 전송 구현·인증·운영 연결을 보증하지 않습니다. 필요한 구현과 검토 뒤 릴리스가 제공하는 별도의 등록 경로로 인계하고 정확한 결과를 확인합니다. 구현된 기존 연동을 사용하면 이 단계를 생략합니다.
새 Pack이 필요한 경우 Builder — Part.6: 사용할 수 있다고 확인된 정확한 기능·연동 참조로 작업의 입력·출력·사전 조건·실패 처리를 구성하고 Pack 후보를 검증합니다. SDK의 .rlib를 Builder에 복사·불러오는 자동 연결 절차는 여기서 제공하지 않습니다. 기존 승인 Pack으로 해결되면 Builder 작성도 생략합니다.
검증·승인·사용 권한 확인 후 운영 — Part.7/8: Pack/연동 등록, Work 바인딩·승인·현재 사전 조건은 각각 확인합니다. PackrGUI 또는 헤드리스의 승인된 실행 경로에서 결과와 영수증을 대조합니다. 이 문서의 현재 작업은 고객 활성화·전달·실제 Work 실행을 진행하지 않습니다.

왜 Helper가 두 번 나오는가

앞에서는 어디에 무엇을 연결할지 계획하고, 뒤에서는 완성한 선언·대상·매핑을 기계적으로 검증합니다. 소스 선언이 전혀 없는 상태에서 모든 Helper 명령을 실행할 수 있다는 뜻이 아닙니다. 기존 대상 Contract는 계획 전부터 확보하고, 소스 Document와 매핑은 Helper 결과를 보며 보완합니다. SDK와 Builder는 선언이 빠진 중간을 대신 채우는 도구가 아닙니다.

필요한 단계만 고르는 세 가지 예

상황	따라갈 경로	다음 단계로 넘길 것
이미 승인된 Pack을 사용	설치·연결 → GUI/헤드리스 → 현재 권한·사전 조건 → Work 결과 확인	정확한 Pack/설치/Work 참조와 영수증
기존에 등록된 기능으로 새 Pack 구성	설치 → 기존 기능·대상 확인 → Builder → 후보 검증·승인·사용	기능 리비전, Pack 후보, 검증과 승인 기록
새 Custom API 연동과 새 Pack 구성	설치 → GAPE → Helper 계획 → Document·대상 연결 → Helper 검증 → 필요 시 SDK → 별도 구현 검토·등록 → Builder → 승인 후 사용	단계별 입력·리비전·판정·후보와 미완료 항목

시작·복귀·인계 지점

지금 가진 것 또는 막힌 곳	다음 행동
GAPE 뷰어만 있고 소스 접근 권한은 없음	받은 승인 뷰어에서 범위를 읽습니다. 새 스캔을 위해 소스를 임의 수집하지 않습니다.
게시된 대상 Contract/계획 입력이 없음	제공된 참조를 확보합니다. 표시 이름으로 대상을 만들지 않습니다. 소스 Document 초안은 별도로 작성할 수 있습니다.
Helper가 매핑·필수 필드·대상 리비전을 거부	Part.5에서 해당 선언을 고치고 Helper의 영향을 받은 단계로 돌아갑니다.
Helper scaffold가 REQUIRES_IMPLEMENTATION	Part.7의 지원 범위와 구현 담당자를 확인합니다. scaffold 생성·SDK 빌드는 실제 연결 완료가 아닙니다.
SDK 후보는 있으나 등록되지 않음	별도 등록 담당자에게 후보와 검증 범위를 인계합니다. Builder/Work로 자동 승격하지 않습니다.
Builder 후보 검증은 통과, 승인·권한은 대기	후보를 보존하고 정확한 승인·설치 범위의 결과를 기다립니다. 검증과 실제 사용을 따로 기록합니다.

온라인·오프라인 모두 같은 업무 흐름을 사용할 수 있습니다. SDK 선택 Rust 의존성 세트는 빌드 환경 선택이며 전체 제품의 기본 모드가 아닙니다.

연결·승인·등록에는 해당 설치에 제공된 실제 자료를 사용하십시오. 이 안내서가 이를 구성하지는 않습니다. 교육용 예시는 고객 실행 증거가 아닙니다. Apple 공식 서명·공증과 고객 활성화·전달은 계속 보류합니다.

가이드와 Part.1–8 연결

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

목적별 가이드

PoC 공통 가이드
질문을 정하고 범위에 맞는 관찰을 모아 결과를 검토합니다. 보존 기록 독해에는 신규 설치가 필요하지 않습니다.
Google 심사자 가이드
정확한 심사 전달물과 기준 증거를 연결합니다. Cloud 접근·문서 범위·실제 Google 승인은 각각 구분합니다.
온프레미스 가이드
정확한 OS·패키지·네트워크 선택·도구 체인을 준비합니다. 로컬 SDK 준비 요건이 제공된 뒤에만 해당 단축 경로를 사용합니다.
Custom Execution 가이드
지원 작업을 선택합니다. 소스 문서 준비·전체 SDK 후보·실제 Work 및 보고서 확인을 서로 다른 경로로 구분합니다.
가이드 링크는 네트워크가 필요한 공개 웹사이트를 엽니다. 이 오프라인 매뉴얼과 로컬 예제는 네트워크 없이 읽을 수 있습니다.

권장 연동 순서와 단축 경로

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

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

Part 연결과 도구 역할

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·자동화 완료와 사람 인수 대기는 함께 존재할 수 있으며 각 필드의 실제 범위를 기록합니다.
Online / Offline: 구성 선택 사항입니다. 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만으로는 충분하지 않습니다.

복잡성과 사용자 경험의 개념도

사용자가 제공한 개념 그림입니다. n(n−1)/2 표는 단순 무방향 그래프의 이론적 최대 관계 수이며 측정한 연동 수·벤치마크가 아닙니다. 구성 요소·기능은 릴리스별이며 심사자 접근·고객 실행 증거가 아닙니다. 현재 표시본은 문서 변경을 반영한 영문 SVG이며, 이전 래스터 원본은 보존합니다.