Part.6 · Builder and Additional Packs

Builder: prepare a Pack candidate after setup

First candidate exercise: input through handover

Goal: prepare the release's supplied read-only exercise Pack/candidate as a new revision and inspect validation. Do not modify an operational Pack or choose a service-changing Work for the first exercise. If no exercise input is supplied, write the goal below and request a compatible example from support.

1. Open the OS-specific app using its install instructions. Confirm connected customer/installation/release and Builder role. Stop if only an app window is open without connection.
2. Open the supplied exercise candidate or supported Pack using the release's selection/import procedure. Use version-specific screen names. Record candidate ID, original revision and input.
3. Write this human goal note, not JSON/API input: Purpose: one synthetic inspection result / Input: supplied synthetic data / Output: review result / Changes: no customer service changes / Failure: inspect declared recovery state. Populate supported product fields in the provided template's format.
4. Save a new candidate and record the actual returned ID/revision. Run its validation and inspect that revision's result, reasons and missing fields. Saving and validation are separate checks.
5. For a refusal, correct only the reported declaration and validate the new revision. On success, hand over the candidate reference, validation, purpose and pending approval/entitlement. File creation is not a reason to execute Work.

Expected output: the product's candidate reference and validation record. Do not expect SDK adapter.rs or a GAPE snapshot. For product-managed candidates use the release's export procedure rather than finding and copying arbitrary state files.

Next exercise: follow first Work only after approval, current entitlement and preconditions are established. If validation passed while approval is pending, record candidate preparation/handover complete, Work not executed. Continue with BLD cases and case H below.

Before opening Builder

1. Confirm the appliance release and Builder platform package are compatible, signed, and included in the delivery inventory. A Mac package does not establish Windows or Linux installability.
2. Confirm appliance readiness, authenticated Builder role, customer and installation identity, and a validated runtime binding if the candidate needs it. A local socket refusal or an open Builder window is not an authenticated server connection.
3. Identify the existing Pack or capability you intend to extend. If an approved Pack already meets the need, use its supported path instead of creating a duplicate.

Prepare and validate

1. Write the intended outcome, target environment, allowed inputs, data boundary, preconditions, and rollback disposition. For example: “Create one audit artifact for this installation; read only the declared source; record a receipt; do not change a customer service.”
2. Select only a Contract and capability supplied for the release. Do not invent a capability identifier because an input document is syntactically valid.
3. Create the candidate in Builder, then run the product's candidate validation. Record candidate ID, revision, validation status, exact reason, and the rule that was checked. Fix a reported declaration defect in the candidate and validate again; do not alter Core policy files.
4. Submit the validated candidate through the release's approval route. Confirm formal Pack approval and customer-installation entitlement separately. A passkey can identify a person for a particular approval only when the release's enrollment and server verification path is available; opening Safari and returning to the app proves neither enrollment nor approval.
5. Before Work, read the plan, target, current authority and preconditions. Execute through the governed product route only after those checks pass, then match the final result to its receipt.

Worked example: validation passes, Work is refused

Here is an illustrative operator record, not a Builder API payload or an observed receipt. Enter actual values from the installed release and keep the refusal separate from validation:

Release: [signed release ID]
Installation: [customer-approved reference]
Candidate: [Builder candidate ID and revision]
Validation: PASS (structure only)
Approval: PENDING
Entitlement: NOT_CHECKED
Work: NOT_STARTED
Next owner: Pack approval owner

The candidate declares an audit artifact and structural validation returns PASS. Work submission returns “approval pending.” Record candidate validated / execution not authorized. The next action belongs to the approval owner; repeating submission, using a different account, or copying the candidate into a Pack directory cannot change that state. If approval exists but entitlement is missing, the entitlement owner must resolve the exact customer and installation scope.

Worked example: browser returns without an approval

The passkey page opens and returns to Builder, but Core does not show a verified approval for the same session, plan, and candidate. Keep the Work in a denied or pending state. Check the displayed correlation ID and the release-defined credential enrollment status; do not paste passkey responses into a support ticket.

Completion evidence

Candidate preparation ends with a validated candidate and a recorded handover. Approved Pack use requires separate approval, entitlement, current preconditions, actual Work, validated result, and matching receipt. See the candidate refusal case and first Work guide.

A practical operational use case

Suppose a team needs a weekly inspection artifact with a different input shape. First check whether the supported input of an existing approved Pack already covers it. If a new candidate is needed, retain the original Pack reference, changed declaration, candidate revision and validation result. The approver reviews that exact candidate digest; the operator separately checks the current installation entitlement and preconditions.

Symptom-specific checks and return to operation

Minimum handover to the next owner

Handover: original Pack reference, candidate ID/revision/digest, intended change, supported platform, validation, approval, entitlement, preconditions, rollback disposition and next owner. If no Work ran, record candidate preparation only.

Read the tool-specific troubleshooting examples

These teaching examples use documented input, command and authority boundaries. Read them alongside actual product states/reasons; do not treat illustrative outcomes as execution history. Distinguish checks shared by online/offline environments from checks specific to the optional dependency route.

Worked scenario BLD-1: The app returns from browser confirmation without an approval record

Situation: A user returns from a passkey page and assumes approval. The product has no verified approval for the same candidate, plan and session.

Read these observations separately.

• Browser return: confirms navigation only.
• Credential enrollment: separate from a particular operation’s approval.
• Candidate/plan: must match the approval subject.

Check and action sequence:

1. Compare returned correlation references and current candidate/plan in product state.
2. Check that the release supplies the enrollment/server approval verification route.
3. Do not start Work before the authority owner confirms current state.

Condition for resuming: After product confirmation of exact-subject approval, separately check entitlement/preconditions.

If still unresolved: Do not fill missing approval with raw passkey responses or another account’s credentials.

Worked scenario BLD-2: A failed run leaves partial artifacts and a rollback state

Situation: A candidate/approved Pack operation fails but leaves some files. Before treating presence as success or deleting files and retrying, inspect product failure/rollback state.

Read these observations separately.

• File presence: may indicate partial activity only.
• Work state: check failure, rollback and postcondition validation separately.
• Authority: do not assume it automatically covers a new execution.

Check and action sequence:

1. Retain Work/plan/candidate identity and last validation result.
2. Have the owner check the Pack’s supported recovery procedure and rollback result.
3. After current state is established, evaluate new plan/authority/preconditions through the supported route.

Condition for resuming: Record validated recovery separately from any later authorized execution.

If still unresolved: Do not hide failure by deleting original results, marking manual success or using another execution route.

Post-install tools

Use case 4: Prepare a Builder candidate for Pack approval

Operational goal

A customer prepares and validates a needed function as a Pack candidate, then hands it to the authorized approval and entitlement owners. Check first whether an existing Pack solves the need. Creating a new candidate does not open an execution path.

Example conversation

A Builder user says, “Validation shows passed, so I will run it now.” The administrator replies, “That is candidate validation. We still need Pack approval, entitlement for this installation, contract scope, and preconditions separately.”

States and owners

Work through the sequence

1. Confirm this release supplies Builder and verify Builder installer version and signature.
2. Define requirements inside supported scope and specify the candidate's contract, data boundary, and preconditions. Do not present out-of-scope behavior as supported.
3. Inspect Builder validation and defects, then revise the candidate. Record only the exact scope of validation.
4. Submit candidate ID, version, requested capability, and validation result to the approval owner. Do not send full source or customer data outside the necessary approval path.
5. Confirm approval and entitlement separately for this customer installation in product status. If passkey enrollment is required, use the release-defined supervised administrator route; browser return alone is not approval.
6. For actual Work, separately review the plan, approval, and preconditions, then verify execution with a receipt.

When refused

Use the validation, approval, entitlement, and precondition branches in the Builder candidate case. Do not copy the candidate into a deployment directory or run a refused command under another account.

Completion condition

Preparation is complete only when candidate validation and formal approval and entitlement are each confirmed. This does not mean Work succeeded.

Detailed scenario: candidate validated, execution refused

Suppose Builder reports that a candidate passed structural validation, but Work submission is refused. This is not automatically a product defect. Structure and contract validation, approval owner decision, installation entitlement, and execution-time preconditions are distinct gates. Classify the first stopped gate from the product's actual state.

For example, candidate validation PASS with approval pending means candidate prepared, no execution authority. Even an approved Pack cannot run for a mismatched customer or installation scope or failed precondition. Do not edit candidate files or policy storage to force a permitted state.

Approval handover worksheet

Brackets are fields for actual product records. Do not copy validation PASS into the approval field.

A concrete operational walkthrough

For example, adapt an inspection Pack input to a new target. Check existing Pack coverage first, then create only the needed candidate as a new revision. If the candidate changes after review, do not treat the previous approval as covering the new bytes.

Records to reconcile before closing this use case

Record candidate generation/validation, approval, installation entitlement, preconditions and Work receipt as separate states. Include unexecuted stages and the next authority owner.

Keep the planned procedure, performed actions, observed results and remaining stages separate. This scenario explains the procedure; the documentation update does not execute it in a customer environment.

Back to use-case index

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

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

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