Bootstrap and iterative development

The compiled Solana program contains the persistent on-chain rules. Bootstrap is a separate setup/recovery process that ensures the right program and initial state exist. Neither the website nor each visitor should compile or deploy programs on page load.

What needs to run when

Change	Website/backend deployment	Program compilation / deployment	State setup
Homepage layout, inspection views, search UI, backend indexing or decoder visuals	Yes, for changed site code	No, while on-chain rules remain unchanged	Only new app data/indexes as needed
Runtime RPC URL or secret	Redeploy existing Site version to apply bindings	No	Connection/readiness check
Claim authorization, on-chain evolution rules, marketplace escrow or settlement	Update affected site integration	Compile changed Rust program, then upgrade/deploy	Migration if account layout or invariants change
Public Devnet loses our program/state	Update bindings only if addresses change	Redeploy saved compatible executable; no compilation needed if unchanged	Re-fund test wallets as needed and recreate required accounts/fixtures
Binary missing, Rust/dependencies/toolchain changed, or runtime incompatible	As needed	Recompile, verify and deploy	As needed

Solana's deployment documentation treats build and deploy as separate operations; deployment accepts an existing .so file. Devnet documentation states that Devnet may undergo ledger resets.

What exists now

• The lab's connection check verifies the Devnet genesis, deployed executable, signing/decoder configuration and test-wallet balance.
• Separate compile, deploy and verification scripts exist. There are now explicit administrative recovery commands; visitor requests never bootstrap.
• The verified 33,104-byte executable is preserved in the repository at program/artifacts/discovery_registry-v0.3.0.so. Its hash and source hashes are in program/artifacts/manifest.json.
• V3 implements claims, transfers, issuance-derived rarity/initial price and scheduled state/platform test prices. V1 manual evolution remains for legacy records. On-chain puzzle proofs, production supply caps, standing listings, bids and consumer checkout are not implemented.
• A plain ownership transfer is not a sale. The test seeder separately composes payment and transfers atomically, including a five-item bundle.

Recommended bootstrap behavior

1. Read configuration, verify Devnet genesis and verify the preserved release manifest. Fail clearly on an unavailable/wrong RPC. Do not interpret a timeout, 403 or 429 as a Devnet reset.
2. Check program existence, executable bytes, version and required accounts. If already correct, perform no writes. A missing program is a recovery condition, not proof of a whole-network reset.
3. In an explicit administrative setup step, fund only what is missing, deploy the saved binary only if needed, and initialize only absent accounts. Keep signatures and checkpoints so retries do not duplicate writes.
4. Re-read resulting state, verify invariants, then mark the lab ready. Program upgrades and account migrations are deliberate release operations, not automatic reactions to page visits.

Recovery limits

A reset may erase balances, program accounts, collectible accounts and chain history. Redeploying a program does not restore those records. The present lab can recreate test fixtures; it does not promise restoration of prior ownership history or account addresses.

Reusing the exact program address after it disappears requires its program keypair. Updating an existing deployed program requires its upgrade authority. These are distinct needs. Local disposable keys are excluded from Git; Sites masks stored secrets. If the local program keypair is lost after a reset, use a fresh Devnet program address and update site configuration, or recover it from a separately arranged backup. Production backup/recovery is still undecided.

Current recovery commands

Before using a recovery command that compiles Rust or invokes the Solana CLI, verify that its required tools are installed, executable and compatible. Follow the checks and pinned reinstall instructions in Development if they are missing. Local toolchain loss is separate from on-chain recovery: restore tools as needed, then check chain state before considering any writes. A saved .so permits deployment without rebuilding, but the deployment command still needs its CLI.

1. node scripts/solana/recover-program.mjs --check: verify Devnet and the saved/deployed executable. Healthy state performs no writes. A missing program is reported explicitly; a different executable is not auto-upgraded.
2. If the program is confirmed absent, node scripts/solana/recover-program.mjs --restore deploys the preserved binary to the retained program address and verifies its bytes. It requires the original keys, installed CLI and sufficient test funding; it does not compile or request faucets automatically.
3. node scripts/solana/seed-gallery-v3.mjs --restore checks the 100 known records. If all exist it makes no writes. Partial loss stops for inspection. If all are absent and the program is ready, it archives the private journal, increments generation, recreates the same recorded payloads with retained record keys and replays the bounded test actions with new receipts. Restored V3 records retain seed/rules but receive a new program birth time, so schedules restart in the new generation.
4. An interrupted run uses --resume: recorded signatures are checked, not replaced blindly. An uncertain receipt stops the process. New source catalog/evidence then require the normal build/push/publish flow so every region uses the same generation.

The private .secrets/gallery-v3 journal retains encrypted payloads and record keypairs. Losing keys, decoder or that recovery material blocks faithful restoration. It is deliberately absent from Git. A production backup/custody strategy remains open. Restoration replays test scenarios; it does not recover arbitrary real-user ownership history.

The user-facing data API distinguishes missing program/records from invalid state, wrong network, missing decoder and unavailable RPC. It returns recovery-required only for missing required accounts; no error is described as proof of a network-wide reset. Missing old receipts are omitted and flagged. No D1 or distributed snapshot cache is involved.

Consumer integration

The Flex, Moves and Moments use actual Devnet reads and deterministic decoded test art. HOMEPAGE-V1.md defines the shared view/API and selected hybrid model. ASSET-SYSTEM.md contains remaining asset, rarity and discovery decisions. Recovery failure paths are tested without erasing the live network; a healthy program check was verified as a no-op.