Receiving a Git archive does not prove another supplier can rebuild the website. A lockfile, runtime, package-manager version and install flags can determine a different dependency tree. Commission a reproducible handover receipt without placing registry tokens or production secrets in the archive.
Primary evidence and claim boundaries
npm ci requires an existing lockfile, errors when it conflicts with package.json and does not rewrite those files. npm documents that dependency-tree-affecting flags used when making the lockfile may need to be supplied again. Primary reference · Read 18 October 2026.
Filled acceptance example
Original synthetic teaching scenario, not a client case, provider integration test or business result. The example policy needs the actual owner’s approval; scroll the table on narrow screens.
| Input and state | Declared check | Expected output and decision |
|---|---|---|
| Synthetic manifest: Node22.13.0, npm11, lockSHA=L1 | Recorded install flag: legacy-peer-deps=true | Handover contains versions, lock identity and reviewed flag |
| package.json changed; lock stillL1 | Dependency declarations disagree | npm ci should fail; do not silently update lock to hide it |
| Install succeeds; build output differs | Different environment/input evidence | Investigate; install success is not identical build proof |
| Archive includes a real registry token | Credential detected | Stop handover and arrange owner-controlled secret handling |
Practical handover procedure
- Record source commit, lockfile hash, runtime/package-manager versions, required non-secret configuration and install/build commands. Separate secret provisioning from source delivery.
- Have the replacement supplier rebuild in an authorised isolated clean environment and retain exit status, dependency resolution and artefact hashes. Do not run install scripts from unknown projects without review.
- Compare representative routes and required runtime bindings after the build. Treat external APIs, storage and deployment permissions as separate handover items.
Interpret the outcome
The filled manifest tells a second supplier what to reproduce. It does not guarantee bit-for-bit output from every toolchain or that a working build can deploy without external services. The conflicting-lock row is an intended failure that protects the approved dependency record.
Acceptance decision
Require a redacted clean rebuild receipt and a separately verified runtime handover. A ZIP file or an install success badge is insufficient.
Limits and unverified work
Synthetic environment identifiers, not instructions to replace this site’s frozen dependencies. No installation, token transfer, upgrade or production rebuild is executed by the example.
Download the filled bilingual acceptance record — Contains the inputs, steps, expectations and limits. This is a teaching record, not an executable production integration.
Related next decision: Plan a separate restore drill for data and services.