Plan, publish and verify on Testnet-10

This guide describes the boundary between local preparation and an external operator. It does not contain keys, wallet material or a broadcast shortcut.

1. Prepare locally

ktape deploy plan .\my-app\source-manifest.json --network testnet-10
ktape deploy preflight .\my-app\source-manifest.json --network testnet-10

The plan and preflight are unsigned local projections. Validate the Profile Package, artifact, Developer Lock, network policy, resource envelope and expiry before handing the plan to an authorized provider.

2. Cross the external boundary

The external signer/operator must independently verify the exact plan, network, predecessor state, UTXO roles, adapter admission and resource quote. The provider owns signing and broadcast. KTAPEOUT tooling does not receive or store private keys.

Do not treat a submission acknowledgement, local receipt or single RPC result as final state. The operator must return the declared receipt contract and the required independent readback evidence.

3. Read back

ktape deploy readback .\receipt.json

Readback is accepted only when the receipt binds the network, application, release, artifact/profile lock and successor state required by the adapter. Otherwise keep the outcome UNAVAILABLE, PROOF_INCOMPLETE or another conservative status.

Testnet-10 evidence remains testnet evidence. It does not authorize Mainnet or turn a Profile-specific adapter into a generic L1 admission path.

Browser delivery after readback

Browser hosting is a separate delivery step from L1 publication. Keep the Application Package/Release commitment distinct from a separately published Runtime resource sidecar. If changed bytes are inside the Package/Release, follow the immutable Release maintenance path. A sidecar can be refreshed under the same tuple only when its existing publisher contract permits it and the exact network, application, release and package digest remain bound; this does not make those bytes NameClaim-authorized. A location-only locator refresh is valid only when the complete resource table is unchanged.

Stage the chosen Runtime snapshot, apply environment-specific origin settings, then generate the Pages manifest and run the existing Pages checker. It checks the route-pinned manifest/locator digests and their resource table; a shipped static mirror must match the same declared bytes. Deploy the complete output tree while preserving relative paths. A hosting failure is repaired by syncing that artifact, not by repeating the L1 publication. Hash/readback evidence describes byte consistency only; it does not establish publisher authority or consensus finality.

Public TN10 Registry identity

The candidate includes the selected public Registry manifest and Bridge trust anchor under release-evidence/tn10/. Use these files as the initial, versioned identity inputs for a client-side read path:

• official Registry manifest
• Bridge trust anchor
• public deployment readback

The manifest and trust anchor must agree on the Testnet-10 network, manifest digest, genesis commitment, Profile hash, covenant ID and policy hashes. The published tuple identifies the declared Registry root; it is not a substitute for a fresh dual-source readback and does not authorize signing or broadcast.

Maintain an existing release

Maintenance is a separate operation from an ordinary state transition. A changed program, resource envelope or dependency set requires a new immutable Release and a complete target commitment. An incompatible state representation also requires the Profile-owned migration contract and explicit authorization. Version numbers alone do not prove compatibility.

Use the CLI's maintenance and history commands to create and verify an unsigned, hash-bound plan. Recheck the network, predecessor, exact plan, authorization, expiry and fee ceiling before any external signer sees it. Keep private keys outside KTAPEOUT tooling. A local journal or successful command is not a chain receipt; SUBMISSION_UNKNOWN must be queried before retrying, and a stale predecessor requires replanning.

Switch a canonical name only after the target is readable, the applicable migration has completed, and a fresh resolution/session check agrees with the confirmed Release. Existing name read or rebind evidence does not prove a full content publication and migration cycle.

The current public candidate provides local/read-only maintenance, genesis-provenance, rebuild and readback validation. The Native-KAS adapter, Namespace Registry compiler/genesis builder and signer-specific handoff remain outside this minimal package pending a separate source and evidence review.