# Sharp release compatibility methodology

## Decision scope

The service answers one narrow question: which of the tested **sharp** releases should an automated client pin for a clean Linux amd64 deployment target?

It does not prove compatibility with an existing repository, lockfile, application, framework or production workload.

## Proof profile: `native+nft-v1`

Each package-version and target tuple must be reproduced in an ephemeral, non-root container. The proof factory performs:

1. an offline `npm ci` from an immutable package version, with lifecycle scripts disabled;
2. CommonJS and ESM imports;
3. a real native PNG transformation;
4. `@vercel/nft` tracing of the runnable entry point;
5. offline replay of the traced artifact after the install network is disabled;
6. a second independent attempt to detect nondeterminism.

The resulting bundle records the npm integrity, OCI image digest, harness digest, exact commands, exit states, sanitized evidence and a canonical evidence digest. The v1 runner disables package lifecycle scripts and does not initiate a source build. A missing usable prebuilt therefore cannot become a recommendation; any separately attested source-build evidence would remain conditional.

## Selection rule

The service selects the numerically newest of 0.35.1, 0.35.2 and 0.35.3 that completed every required stage through a prebuilt binary in two consistent runs. A source-build-only pass is reported but never outranks an older prebuilt pass. If no prebuilt candidate passes, the response is `CONDITIONAL` and emits no production npm pin. Node 26 always returns `PREVIEW_ONLY`, even when every stage passes.

## Request-time behavior

Paid HTTP requests only read an existing proof bundle. They never download or execute an npm package. Unsupported input is rejected before x402 settlement.

## Readiness boundary

The safe fallback repository is a contract fixture and is deliberately marked `productionReady: false`; its PASS values are not measured facts. `GET /ready` remains HTTP 503 until a reproduced, immutable and externally attested proof bundle replaces that fallback. Clients must use the live readiness fields, not assume readiness from this documentation.