Part.6 · Builder·추가 Pack 사용

Builder: 설치 후 Pack 후보 준비

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

목표: 해당 릴리스가 제공한 읽기 전용 연습 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. 현재 상태가 확인된 뒤 새 계획·권한·사전 조건을 정식 경로에서 평가합니다.

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

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

설치 후 도구 목록

용례 4: Builder 후보를 승인 가능한 Pack으로 준비하기

운영 목적

고객이 필요한 기능을 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 영수증을 각각 별도 상태로 적습니다. 인계에는 실행하지 않은 단계와 다음 권한 담당자도 포함합니다.

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

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