Part.5 · SDK Engine practice and candidates

SDK Engine: installation and candidate use online and offline

What this component does

Use this tool on an integration workstation to prepare a candidate, before any live connection or Pack registration. It accepts a declared read-only Custom API operation or an MCP transcript, each with a synthetic response. The result is a locally compiled value-mapping library and its source. The tool does not call the source API or MCP server, read credentials, change the appliance, register a Pack, or execute Work.

For the supplied-set route, use the matching generation of the separate OS-native offline Rust dependency package. This set is optional when choosing the installed-toolchain online route. It supplies the compiler, standard library, Cargo and exact declared crate versions. Rust and crates need no additional download for that declared coverage. Other OSes, targets or new crates require their own verified inputs. macOS arm64 and Debian 13 amd64 bundles use Rust 1.96.0; Windows amd64 uses Rust 1.97.1.

Native prerequisites are separate: an existing Debian system C linker and libc development files; trusted Apple developer tools and SDK on macOS; or Visual Studio 2022 BuildTools MSVC 14.44.35207 and Windows SDK 10.0.26100.0. These native assets are not redistributed. Provisioning a fresh OS with all prerequisites has not been validated.

On macOS, run-offline uses the active Apple developer tools by default (SYSTEM_ACTIVE). To select an already installed Command Line Tools package for one run, append --macos-developer-selection COMMAND_LINE_TOOLS after the dependency root. This selects the registered /Library/Developer/CommandLineTools installation and retains all trust checks. It does not change the system developer selection or fall back to another installation. The option is rejected on other operating systems.

./bin/packr-sdk-engine run-offline examples/read-only-custom-api.json ./quality-candidate /absolute/path/dependencies --macos-developer-selection COMMAND_LINE_TOOLS

Check official signing/notarization and customer activation/delivery status in the package and separately trusted release inventory. Local example success does not authorize those states.

Choose the environment first: online and offline

SDK Engine can be used in both online development and offline environments. The offline dependency set is optional provisioning for closed on-premises installations where compiling an SDK adapter may otherwise require unavailable Rust assets. It does not set an offline-only product default. Its purpose is to address dependencies that can arise while building a new integration candidate with SDK Engine.

The compatibility path below uses an installed compiler in an online development environment. Run it from the extracted SDK directory after checking the actual compiler selected by rustc --version, its supported target and native prerequisites. Choose fresh output directories. This path uses the compiler on PATH and does not provide the separate dependency set's full-tree/native-trust receipts; validate that environment separately.

rustc --version
./bin/packr-sdk-engine analyze examples/read-only-custom-api.json unused
./bin/packr-sdk-engine run examples/read-only-custom-api.json ./online-custom-candidate-01
./bin/packr-sdk-engine run examples/read-only-mcp-transcript.json ./online-mcp-candidate-01

rustc --version
if ($LASTEXITCODE -ne 0) { throw 'Rust compiler unavailable' }
.\bin\packr-sdk-engine.exe analyze .\examples\read-only-custom-api.json unused
if ($LASTEXITCODE -ne 0) { throw 'Analyze failed' }
.\bin\packr-sdk-engine.exe run .\examples\read-only-custom-api.json .\online-custom-candidate-01
if ($LASTEXITCODE -ne 0) { throw 'Custom candidate failed' }
.\bin\packr-sdk-engine.exe run .\examples\read-only-mcp-transcript.json .\online-mcp-candidate-01
if ($LASTEXITCODE -ne 0) { throw 'MCP candidate failed' }

run is retained as a compatibility command for an installed compiler. It does not establish the same checks as the separately verified dependency route. Do not use it to avoid a failed run-offline trust or permission check. The dependency-set procedure below can also be chosen on a connected machine. Neither command's synthetic examples contact a live API or MCP server.

Prepare the two archives in a fresh location

The SDK archive contains bin, docs, examples, licenses and notices. The optional Rust dependency set contains DEPENDENCIES.json, FILES.json, toolchain, cargo-home and notices. Extracting the SDK alone does not install the optional dependencies. Use a new generation-specific location to preserve earlier installations and results.

Check both archives with shasum -a 256 on macOS, sha256sum on Debian, or Get-FileHash -Algorithm SHA256 on Windows. Compare with a separately trusted component inventory. A digest obtained from the same untrusted location does not establish publisher identity. Stop on a mismatch even if the file name is unchanged.

On Linux or macOS, replace the archive paths below with the real files. The example stops if the install root already exists. Use an unshared directory under your private home; every ancestor must also exclude writes by other users.

sdk_archive="/absolute/path/sdk-package.tar.gz"
deps_archive="/absolute/path/RUST_DEPENDENCIES_OS.tar.gz"
install_root="$HOME/VibePackr-SDK-install-01"
test ! -e "$install_root" || exit 1
umask 077
mkdir -m 700 "$install_root" || exit 1
mkdir "$install_root/sdk" "$install_root/dependencies" "$install_root/runs" || exit 1
tar -xzf "$sdk_archive" -C "$install_root/sdk" || exit 1
tar -xzf "$deps_archive" -C "$install_root/dependencies" || exit 1
cd "$install_root/sdk" || exit 1

In Windows PowerShell 5.1, choose a fresh directory beneath an access-controlled user home. Check the organization's approved current-user directory and ACL first; avoid shared, synchronized or network locations. The example assumes that the parent permissions have already been verified. It neither overwrites an old directory nor changes system-wide ACLs.

$sdkArchive = 'C:\absolute\path\sdk-package.zip'
$depsArchive = 'C:\absolute\path\RUST_DEPENDENCIES_WINDOWS_AMD64.zip'
$installRoot = Join-Path $env:USERPROFILE 'VibePackr-SDK-install-01'
if (Test-Path -LiteralPath $installRoot) { throw 'Choose a fresh install root' }
New-Item -ItemType Directory -Path $installRoot -ErrorAction Stop | Out-Null
$sdkRoot = Join-Path $installRoot 'sdk'
$depsRoot = Join-Path $installRoot 'dependencies'
$runsRoot = Join-Path $installRoot 'runs'
New-Item -ItemType Directory -Path $sdkRoot,$depsRoot,$runsRoot -ErrorAction Stop | Out-Null
Expand-Archive -LiteralPath $sdkArchive -DestinationPath $sdkRoot -ErrorAction Stop
Expand-Archive -LiteralPath $depsArchive -DestinationPath $depsRoot -ErrorAction Stop
Set-Location -LiteralPath $sdkRoot

If full dependency verification rejects the permissions, do not use that installation; resolve it through the approved installation procedure. Do not disable checks, elevate the product, bypass execution policy or change the system trust store. Extraction of a dependency set is optional when using only an existing toolchain in an online environment.

Check and install the supplied package

1. Confirm that your release inventory lists SDK Engine for your workstation OS. Compare both SDK and dependency archive SHA-256 values with a separately trusted inventory before extraction. Verify a release signature when supplied; record an absent official distribution signature and distinguish an unsigned candidate from a signed release. Do not substitute a package for another OS.
2. Extract the archive into a new, access-controlled directory. Keep the directory's bin, docs, and examples together. Use the signed release's platform-specific installation instructions for any system-wide placement.
3. Extract dependencies into a separate fresh directory writable only by the trusted current user. All intermediate directories must exclude other users’ writes. Preserve the included cargo-home as verified input: do not use it as a mutable cache or merge it into a global cache. No activation script or shell session mutation is needed. Replace the absolute dependency paths below with your actual paths, verify the full tree, then check the examples.

Linux or macOS terminal:

./bin/packr-sdk-engine verify-offline-dependencies DEBIAN_13_AMD64 /absolute/path/dependencies
# On macOS arm64 replace DEBIAN_13_AMD64 with MACOS_ARM64.
test -f examples/read-only-custom-api.json
test -f examples/read-only-mcp-transcript.json
./bin/packr-sdk-engine analyze examples/read-only-custom-api.json unused

Windows PowerShell:

.\bin\packr-sdk-engine.exe verify-offline-dependencies WINDOWS_AMD64 C:\absolute\path\dependencies
Test-Path .\examples\read-only-custom-api.json
Test-Path .\examples\read-only-mcp-transcript.json
.\bin\packr-sdk-engine.exe analyze .\examples\read-only-custom-api.json unused

analyze reads the declaration without creating an output directory. A successful result reports authority_granted: false. If your release inventory lacks this component, stop and obtain the correct package through your support channel.

OS-specific examples with the optional dependency set

The commands below assume the preceding path variables remain in the same shell. Set actual absolute paths again in a new shell. The final unused argument to analyze is required by the CLI shape; it does not name a created output directory.

On macOS ARM64, this example explicitly chooses already installed Command Line Tools. The default selection is SYSTEM_ACTIVE; the option below applies only to that run.

./bin/packr-sdk-engine verify-offline-dependencies MACOS_ARM64 "$install_root/dependencies" || exit 1
./bin/packr-sdk-engine analyze examples/read-only-custom-api.json unused || exit 1
./bin/packr-sdk-engine run-offline examples/read-only-custom-api.json "$install_root/runs/custom-01" "$install_root/dependencies" --macos-developer-selection COMMAND_LINE_TOOLS || exit 1
./bin/packr-sdk-engine run-offline examples/read-only-mcp-transcript.json "$install_root/runs/mcp-01" "$install_root/dependencies" --macos-developer-selection COMMAND_LINE_TOOLS || exit 1

On Debian 13 AMD64:

./bin/packr-sdk-engine verify-offline-dependencies DEBIAN_13_AMD64 "$install_root/dependencies" || exit 1
./bin/packr-sdk-engine analyze examples/read-only-custom-api.json unused || exit 1
./bin/packr-sdk-engine run-offline examples/read-only-custom-api.json "$install_root/runs/custom-01" "$install_root/dependencies" || exit 1
./bin/packr-sdk-engine run-offline examples/read-only-mcp-transcript.json "$install_root/runs/mcp-01" "$install_root/dependencies" || exit 1

On Windows AMD64:

.\bin\packr-sdk-engine.exe verify-offline-dependencies WINDOWS_AMD64 $depsRoot
if ($LASTEXITCODE -ne 0) { throw 'Dependency verification failed' }
.\bin\packr-sdk-engine.exe analyze .\examples\read-only-custom-api.json unused
if ($LASTEXITCODE -ne 0) { throw 'Analyze failed' }
.\bin\packr-sdk-engine.exe run-offline .\examples\read-only-custom-api.json (Join-Path $runsRoot 'custom-01') $depsRoot
if ($LASTEXITCODE -ne 0) { throw 'Custom candidate failed' }
.\bin\packr-sdk-engine.exe run-offline .\examples\read-only-mcp-transcript.json (Join-Path $runsRoot 'mcp-01') $depsRoot
if ($LASTEXITCODE -ne 0) { throw 'MCP candidate failed' }

Inspect the first result and resume in a new terminal

After the OS-specific installation/run blocks create separate Custom and MCP candidates, inspect them below. SDK is not an installer that creates a desktop app icon: locate the extracted bin executable and result paths. Run commands from that SDK directory. The installed-toolchain online route does not require optional dependency variables.

If you used the installed-toolchain online run examples unchanged, results are online-custom-candidate-01 and online-mcp-candidate-01 under the SDK directory. Substitute those actual paths in the inspection commands below. runs/custom-01 and runs/mcp-01 belong to the earlier supplied-set run blocks.

Open the actual Custom result

ls -la "$install_root/runs/custom-01"
cat "$install_root/runs/custom-01/README.md"
cat "$install_root/runs/custom-01/adapter.rs"
cat "$install_root/runs/custom-01/manifest.json"

$candidate01 = Join-Path $runsRoot 'custom-01'
Get-ChildItem -LiteralPath $candidate01
Get-Content -LiteralPath (Join-Path $candidate01 'README.md') -Raw -Encoding UTF8
Get-Content -LiteralPath (Join-Path $candidate01 'adapter.rs') -Raw -Encoding UTF8
Get-Content -LiteralPath (Join-Path $candidate01 'manifest.json') -Raw -Encoding UTF8

libadapter.rlib is a Rust library; do not double-click or execute it as an OS program. Mapping 97 to an integer quality_score is part of synthetic validation, not a response from a live server. Read the original input values and compare mapping/stage records.

Create the editable input.json copy first

These commands copy the complete example into a fresh inputs-02 directory. Edit/analyze it here, then rerun in the later Edit input.json section. Choose a new number if that directory already exists.

test ! -e "$install_root/inputs-02" || exit 1
mkdir "$install_root/inputs-02" || exit 1
cp ./examples/read-only-custom-api.json "$install_root/inputs-02/input.json" || exit 1

$inputs02 = Join-Path $installRoot 'inputs-02'
if (Test-Path -LiteralPath $inputs02) { throw 'Choose a fresh input folder' }
New-Item -ItemType Directory -Path $inputs02 -ErrorAction Stop | Out-Null
Copy-Item -LiteralPath .\examples\read-only-custom-api.json -Destination (Join-Path $inputs02 'input.json') -ErrorAction Stop

Open this copy in an editor, keeping score a string "88" and setting component to "my-test-component". Changing fixture values while retaining mapping may leave adapter.rs unchanged. Preserve both the first and modified results.

After opening a new terminal

These commands restore the existing installation paths. Do not extract again or delete old results. Replace the root name if you used a different one, and select a fresh result directory for the next run.

install_root="$HOME/VibePackr-SDK-install-01"
test -f "$install_root/sdk/bin/packr-sdk-engine" || exit 1
cd "$install_root/sdk" || exit 1

$installRoot = Join-Path $env:USERPROFILE 'VibePackr-SDK-install-01'
$sdkRoot = Join-Path $installRoot 'sdk'
$depsRoot = Join-Path $installRoot 'dependencies'
$runsRoot = Join-Path $installRoot 'runs'
Set-Location -LiteralPath $sdkRoot -ErrorAction Stop
if (!(Test-Path -LiteralPath '.\bin\packr-sdk-engine.exe' -PathType Leaf)) { throw 'SDK path does not match the prior installation' }

Return path: executable missing → install root/nested extraction directory; analyze refusal → complete input/encoding; build refusal → selected dependencies/native prerequisites; output refusal → fresh name. Never open a failed temporary stage as a successful candidate.

Example declaration

The included file declares one synthetic read_quality operation. The source returns component and a string score; the target contract expects component and integer quality_score. This mapping is local preparation only.

{
  "definition": {
    "integration_id": "acme-quality-hub",
    "operation_id": "read_quality",
    "credential_requirements": [],
    "execution_boundary": "READ_ONLY_SYNTHETIC_SANDBOX"
  },
  "mapping": {
    "field_mappings": [
      {"source": "component", "target": "component", "transform": "IDENTITY"},
      {"source": "score", "target": "quality_score", "transform": "STRING_TO_INTEGER"}
    ]
  },
  "fixture": {
    "scope": "LOCAL_SYNTHETIC_SANDBOX",
    "response": {"component": "fixture-component", "score": "97"}
  }
}

This excerpt explains the fields; run the complete supplied JSON file, which also binds the exact registered Contract, adapter, schema digest, permissions, and evidence capabilities. Do not place a password, token, private key, or real customer response in a fixture.

Example: a legacy repository exposed through MCP

If your organization exposes a legacy repository through a supported MCP interface, start with examples/read-only-mcp-transcript.json. Its synthetic transcript declares tools/list and a read-only read_repository tool. The mapping copies name to repository_id and sha to revision. The Engine parses the supplied transcript; it does not establish an MCP session.

./bin/packr-sdk-engine analyze examples/read-only-mcp-transcript.json unused
./bin/packr-sdk-engine run-offline examples/read-only-mcp-transcript.json ./repository-candidate /absolute/path/dependencies

Windows PowerShell:

.\bin\packr-sdk-engine.exe analyze .\examples\read-only-mcp-transcript.json unused
.\bin\packr-sdk-engine.exe run-offline .\examples\read-only-mcp-transcript.json .\repository-candidate C:\absolute\path\dependencies

Before substituting a real declaration, confirm the exact operation, field types, read-only permission, contract revision, and synthetic response with the integration owner. A live MCP tool call and any credential use require their own approved connection workflow.

Run the five stages

From the extracted package directory, choose an output directory that does not already exist:

./bin/packr-sdk-engine run-offline examples/read-only-custom-api.json ./quality-candidate /absolute/path/dependencies

Windows:

.\bin\packr-sdk-engine.exe run-offline .\examples\read-only-custom-api.json .\quality-candidate C:\absolute\path\dependencies

One command performs the stages in order:

1. ANALYZE_GAP checks the registered Contract, adapter, protocol revision, read-only operation, bounded input, and synthetic fixture.
2. GENERATE creates adapter.rs, a local mapping function. It contains no API transport, credential handling, or Work execution path.
3. BUILD invokes the absolute packaged rustc after full tree verification to compile libadapter.rlib from that generated source.
4. VALIDATE compiles and runs a temporary fixture test. It verifies the expected mapping and denial of an unknown source field. The temporary fixture source and test executable are removed after success.
5. PACKAGE writes README.md and manifest.json. The manifest records the input digest, compiler version, SHA-256 for the three candidate files, and the input and output digest of each stage.

The expected output directory contains exactly adapter.rs, libadapter.rlib, README.md, and manifest.json. The v2 manifest includes offline_execution: minimal public digests for the pre/post tree, compiler, native prerequisites, environment and argv. It is an unsigned observation record, not independent runtime attestation or a release signature. Check the manifest. The result is CUSTOMER_REVIEW_CANDIDATE; it is not a live integration or an authorization decision.

Edit input.json and generate a second candidate

Copy the complete supplied examples/read-only-custom-api.json into input.json in a fresh input workspace. Preserve the original example and first output. Edit only these two values in a text editor and save as UTF-8. Do not replace the whole file with this excerpt.

draft.fixture.response.component = "my-test-component"
draft.fixture.response.score = "88"

Keep score quoted: the source field is a string and STRING_TO_INTEGER converts it to integer quality_score. Do not guess replacements for Contract IDs, adapter revisions, schema digests, permissions or evidence capabilities. PowerShell 5.1's default Out-File can write UTF-16; choose UTF-8 in your JSON editor.

For example, create a fresh inputs-02 directory under the install root and save input.json there before running the following. On macOS retain the Apple tools selection used earlier. Never merge the two candidate directories.

./bin/packr-sdk-engine analyze "$install_root/inputs-02/input.json" unused
./bin/packr-sdk-engine run-offline "$install_root/inputs-02/input.json" "$install_root/runs/custom-api-candidate-02" "$install_root/dependencies"
# For an explicit macOS CLT selection append: --macos-developer-selection COMMAND_LINE_TOOLS

$input02 = Join-Path $installRoot 'inputs-02\input.json'
.\bin\packr-sdk-engine.exe analyze $input02 unused
if ($LASTEXITCODE -ne 0) { throw 'Analyze failed' }
.\bin\packr-sdk-engine.exe run-offline $input02 (Join-Path $runsRoot 'custom-api-candidate-02') $depsRoot
if ($LASTEXITCODE -ne 0) { throw 'Candidate failed' }

If you selected the installed-toolchain online path, use run with the same input and a fresh output; omit the dependency path and macOS selection option. Keep records for the two execution paths separate.

Read adapter.rs and manifest.json and compare outputs

adapter.rs contains field-mapping code. Changing only synthetic response values while retaining mapping rules may leave that source unchanged. manifest.json records the individual input, artifacts and stages, so input digests, paths and observations can differ. Do not expect .rlib hashes from different OSes or compiler versions to match.

cat "$install_root/runs/custom-api-candidate-02/adapter.rs"
cat "$install_root/runs/custom-api-candidate-02/manifest.json"

Get-Content -LiteralPath (Join-Path $runsRoot 'custom-api-candidate-02\adapter.rs')
Get-Content -LiteralPath (Join-Path $runsRoot 'custom-api-candidate-02\manifest.json') -Raw
Get-FileHash -LiteralPath (Join-Path $runsRoot 'custom-api-candidate-02\libadapter.rlib') -Algorithm SHA256

Editing generated source invalidates the recorded manifest hashes. For a reproducible Engine candidate, edit supported declarations/mappings in the input JSON and rerun into a new directory. Do not edit the manifest to represent altered artifacts as previously validated. Arbitrary Rust code, additional crates and live networking are outside this synthetic example's validation coverage.

Check reproducibility by rerunning the same complete input on the same OS with the exact SDK, compiler and dependencies into another fresh directory, then comparing SHA-256 for adapter.rs and libadapter.rlib. Comparing two different inputs answers a different question. Entire manifest hashes need not match; inspect all five stages, artifact/input digests and before/after dependency-tree digests as well.

Common problems and exact actions

run-offline builds in a private sibling stage, performs post-use verification, then publishes with an atomic no-replace move. On failure the final path remains absent, while a private stage and failure record may remain. Never consume a stage as a candidate. A later run does not automatically reuse earlier failed stages or results. Retain its error output when contacting support; remove any customer data before sharing it.

Update, retain, remove and prepare security review materials

Extract each SDK generation into a separate directory and compare its dependency set and digest inventory. Preserve earlier inputs, packages and outputs while validating the new location, then change the working path. To roll back, select the recorded previous SDK with its matching dependencies and input. Do not overwrite or reuse an old candidate directory automatically.

Before removal retain the input JSON, edits, candidate artifacts/manifests and support record. Manage the portable installation separately from results. This procedure installs no system service and changes no global Rustup/Cargo configuration; it does not require removing those settings or a pre-existing organizational toolchain.

For security review retain package/dependency digests, exact versions and OS, file inventory, LICENSE/NOTICE, any supplied SBOM and advisory-query date, and actual checks with their limits. Distinguish unsigned candidates from signed releases. Matching digests establish byte identity; the manifest is not independent execution attestation. Known-marker checks do not guarantee universal secret absence or certify every supply-chain, privilege, network-isolation or current vulnerability property.

Use the separately supplied procedures and authority for appliance registration, live connections, customer activation/delivery and Work. Return to the post-install tool index or prepare the next integration declaration using the source Document guide.

Support record

Record both package digests and whether a signature was supplied, workstation OS, verified compiler version, input JSON digest, target Contract and adapter revisions, stage result, candidate manifest, and your integration owner. For a later live run, record the separate appliance registration decision and Work receipt. Keep secrets and raw customer responses out of the support record.

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 SDK-1: After extracting only the SDK, distinguish dependency and native prerequisites

Situation: The SDK executable opens, but an optional-dependency build does not start. Check SDK extraction, Rust-set verification and native OS tooling as separate stages.

Read these observations separately.

• SDK: bin/docs/examples confirm SDK file preparation only.
• Dependencies: matching-OS DEPENDENCIES.json/FILES.json/toolchain belong in a separate root.
• Native tools: release prerequisites are separate from the Rust set.

Check and action sequence:

1. Record whether this is the installed-toolchain or optional-set route; this scenario concerns the latter.
2. Compare SDK/set digests and platform, then use verify-offline-dependencies with the exact absolute root.
3. If refusal remains after tree verification, check native prerequisites, path permissions and product reasons; do not switch routes to avoid checks.

Condition for resuming: Record preparation complete only after selected-route prerequisites and all five stages pass into fresh output.

If still unresolved: Hand over exact missing assets/unsupported combinations; do not fill gaps with arbitrary downloads or mixed global caches.

Worked scenario SDK-2: Select an installed macOS CLT package for one run

Situation: A Mac has multiple Apple tool installations. A run using the active system selection is refused while registered Command Line Tools are also installed. Presence alone does not establish trust validation.

Read these observations separately.

• Default tool selection: SYSTEM_ACTIVE; this is separate from an online/offline operating default.
• COMMAND_LINE_TOOLS selects an already installed registered location.
• Trust checks: still apply to the selected tools.

Check and action sequence:

1. Check SDK/dependency generation and Apple tools/SDK prerequisites.
2. Append the documented --macos-developer-selection COMMAND_LINE_TOOLS after the dependency root and choose fresh output.
3. If refused again, retain the exact reason; do not change global developer selection, the trust store or official signing status.

Condition for resuming: Record success only for the selected tools and candidate validation actually observed for that run.

If still unresolved: Hand over absent/refused CLT prerequisites; do not use the option on another OS.

Worked scenario SDK-3: Changing score to a number or replacing the request with an excerpt

Situation: A user changes score to 88 without quotes or saves only an explanatory excerpt as input.json. Valid JSON syntax does not establish the declared type or complete request structure.

Read these observations separately.

• Original example: contains the full request_id/correlation_id/draft.
• score: source schema requires a string; the mapped quality_score is integer.
• Encoding: PowerShell 5.1 default file output may not be UTF-8.

Check and action sequence:

1. Copy the complete original into a fresh input path; set draft.fixture.response.score to "88" and component to "my-test-component".
2. Check UTF-8 and completeness, then inspect analyze; do not guess edits to target IDs or schema digests.
3. Run the selected route into fresh output and inspect manifest, source and library together.

Condition for resuming: Close only that candidate when the edited supported input and its five stages/artifact digests are confirmed.

If still unresolved: Do not represent a remaining target/authority/data-boundary refusal as resolved by editing fixture values.

Worked scenario SDK-4: adapter.rs matches but the library digest differs

Situation: Two outputs have identical adapter.rs but different libadapter.rlib digests. Before comparing paths alone, establish whether input, OS, compiler, SDK, dependencies and command are identical.

Read these observations separately.

• Matching source digest: does not establish all build inputs.
• Different OS/compiler/SDK generations: do not assume identical libraries.
• Manifest: per-run observations can make its overall digest differ.

Check and action sequence:

1. Compare full input digest, compiler, SDK, dependencies, platform and execution route side by side.
2. For same-input reproducibility, use the identical verified combination in fresh output and retain previous results/failures.
3. Compare adapter.rs and libadapter.rlib separately and read stages/before-after dependencies; do not edit manifests to force a match.

Condition for resuming: Record matching repeats as reproducibility for that OS/version/input combination only.

If still unresolved: If conditions match but bytes differ, hand over package/input/artifact digests and minimal run records; do not turn failed protection checks into success.