wikideck/docs/operator-launch.md

Operator launch preparation and hold points

The production delivery plan defines the next engineering milestones, acceptance criteria and operator decisions. Its XMR-native pricing direction supersedes earlier production USD-price plans; existing sandbox behavior and historical order terms remain unchanged until an integrated versioned migration. Trustless settlement is a research gate, and any host-custodial fallback requires explicit approval.

Current decision: HOLD / NO-GO for mainnet, valuable assets, or payments. The production plan now distinguishes a proposed non-monetary testnet beta hosted from the operator's apartment. That beta would not be mainnet production or permission to custody funds. Review the security findings before any public exposure. The automated preflight intentionally exits nonzero for mainnet while required blockers remain. An environment variable, successful container startup or genesis timestamp cannot substitute for closing findings.

Stage-1 node resource controls and local load tooling are implemented. This is partial remediation, not capacity certification or closure of the public-node hold point.

Stage-2 encrypted wallet storage/lifecycle is implemented. Require explicit legacy migration, verified portable recovery, closure of old tabs and review of residual unlocked-page risks before considering the production wallet hold point satisfied. Local implementation/tests are not independent sign-off.

1. Safe inspection — does not launch anything

Use Node.js 24 and a clean reviewed checkout. For mainnet assessment on a host, select WIKIDECK_NETWORK=mainnet in the process environment, then run the launch:preflight package script. It runs the node entry point with --launch-preflight, prints JSON and exits. --network-manifest remains available for identity inspection only.

The preflight:

• Selects the pinned profile and reports network, chain/genesis, fixed fee policy and local gate status.
• Does not open/create a ledger or wallet, start a RandomX engine/listener, contact peers or external payment services, or write approval settings.
• Does not print environment values or payment credentials. Reports are still operational information; review them before publishing.
• Lists code blockers and missing external evidence. productionReady remains false even if startup approval variables are supplied. Fixes and independently reviewed evidence must be reflected in a future reviewed release; do not turn the report green by deleting findings.

The runtime image can execute the entry point with --launch-preflight as well; it does not include the package-script dev runner or need tsx. A Docker test target is provided for Node 24 build/test validation with Linux-native RandomX. No production launch command is supplied here while the decision is NO-GO.

Important: the report is an assessment, not an additional enforcement layer. Existing startup approval checks are still accident-prevention gates; an operator editing source or setting all approvals can bypass the intended process. Keep release/deployment permissions restricted.

2. Evidence register — all required before production sign-off

For the proposed non-monetary testnet beta only, use a separate scoped decision: the chain/network is explicitly testnet, no valuable cards are offered, real payment/custody settings remain off, mock market delivery is disabled or the deployment is demonstrably valueless, and experimental wallet/data-loss limitations are disclosed. This does not close any mainnet/live-payment hold point below. Apartment-hosting evidence must include ISP/CGNAT/reachability, TLS/proxy/backend isolation, firewall/admin/patch controls, off-host encrypted backup and restore, and external alert delivery. If these cannot be verified, do not expose the apartment host publicly; choose a managed host.

The real-money custody path is not implemented end-to-end. Production deposit/credit/withdrawal services, custody and refund policy, journal/backup/monitor integration, operator reconciliation and independent review remain missing.

Stage-4 deployment and recovery tooling adds explicit proxy trust, private loopback diagnostics/checks and stopped-node pair backup/verification/non-overwriting restore. A local native proof-replay restore drill is automated, but actual-host TLS/proxy verification, off-host recovery, alert delivery and operational ownership still require external evidence.

Stage-3 consensus calibration evidence contains a bounded local native measurement and deterministic timestamp/retarget scenarios. It is not the missing representative network-hashpower or independent consensus review evidence. Do not populate launch approvals from its illustrative targets.

For each item record owner, artifact/release ID, date, evidence location, reviewer and disposition. Empty means unverified, not passed.

Hold point	Required evidence	Current status
Independent protocol/application review	Report against the exact release; critical/high findings fixed and retested; reviewed accepted residual risks	Missing
Consensus launch design	Final genesis and manifest; measured starting target/hashpower; reviewed timestamp/retarget/partition/reorg attack analysis	Missing
Node availability	Bounded public APIs/client; global resource/admission controls; realistic long-chain and hostile traffic capacity report	Missing
Production wallet	At-rest/unlock/signing policy, same-origin compromise analysis, user confirmation and offline recovery drill	Missing
Real-money market, if offered	Direct wallet deposit observation and exact liability crediting, customer-authorized withdrawals, isolated treasury signing, durable reconciliation, custody policy, refund/reorg dispute controls	Not implemented; real payment must stay blocked
Mock-market policy	Ensure public users cannot mistake buyer-triggered mock payment for money; disable sandbox selling/delivery for valuable mainnet cards unless explicitly confined to a valueless trial	Unresolved
Peer/miner topology	Multiple independently administered hosts/operators/failure domains; actual online matching manifests and sufficient independent hashpower, not just two URL strings	Unverified
Edge and host security	TLS/certificate renewal, firewall, loopback backend, reviewed proxy IP trust, connection/global limits, restricted administration, patched hosts, time synchronization	Unverified
Monitoring/on-call	Alert routes and successful drills for node isolation/tip lag, native failure, deep reorgs, WAL/disk exhaustion, queue/latency saturation and market review states	Unverified
Restore/reconciliation	Consistent ledger + market SQLite/WAL backup and clean restore/revalidation; original market identity and idempotency history preserved; offline wallet recovery verified	Unverified
Release supply chain	Lockfile, reviewed base/native/toolchain versions, runtime image digest, SBOM/advisory/native/container scans, signed provenance and restricted release access	Partial: npm advisory queries and local tests only
Incident/governance	Named decision owners, market stop/containment procedure, fork/upgrade policy, communications, rollback criteria; custody/legal review if real money	Missing

3. Freeze and rehearse before authorization

1. Close the security-review blockers in a separate reviewed release. Do not change consensus rules/difficulty under an existing launched chain ID. Prelaunch changes must generate a new pinned manifest and approval target where applicable.
2. Freeze the actual UTC genesis date. 2027-01-01 is a candidate placeholder, not an announced launch. On the review date (2026-10-20), that time gate is not satisfied.
3. Freeze the exact image digest and review artifact hashes, network manifest, selected build/runtime profile, fee policy and intended public origins/peers. Confirm testnet data/backups are not reused.
4. Rehearse on isolated, disposable nonvaluable networks with the reviewed rules: initial synchronization, competing miners, partitions/reconnects, invalid traffic, restart after crash, disk pressure and full restore. Never delete production data or lower confirmations to make a rehearsal pass.
5. Verify the intended production hosts: DNS/TLS, proxy forwarded-IP handling, no direct backend access, matching chain IDs, data permissions, disk/memory/CPU capacity and observable peer freshness. /healthz alone is not acceptance evidence.
6. Confirm fee address control out of band, without requesting or transmitting any seed/private key. Checksum validation alone does not prove control. No live test payment is authorized by this document.

4. Explicit operator go/no-go meeting

Record the final release digest, immutable manifest, all hold-point dispositions, change window, operator/reviewer names, monitoring/on-call contacts, recovery point/RTO, stop conditions and signatures/approvals in your controlled operations system.

Only after independent evidence has been reviewed should the authorized operator intentionally supply the existing chain-specific startup approval and review attestation. This internal coding review is not the independent review referenced by that attestation. Do not put private keys, seed phrases, payout credentials or backup passwords in the approval record, source tree or browser environment.

The launch preflight must not be repurposed to auto-populate approvals. No approval variables have been written by this work. Payments remain mocked even if network startup is later authorized; changing that requires a separately reviewed live-settlement release and explicit payment activation process.

5. Stop conditions and containment

• Halt new marketplace activity and investigate if invoice identity/amounts disagree, delivery is ambiguous, a settled order enters review, or payout status is unknown. Do not replay an ambiguous payout or automatically clear payout markers.
• Treat deep reorgs, isolation, divergent manifests, sustained queue/latency overload, disk/WAL exhaustion, native-engine failure, key compromise or loss of monitoring as incidents. Stop accepting new risk using the approved containment procedure.
• Stopping a node does not undo confirmed transactions or cancel previously signed transfers. Do not promise financial rollback from a software rollback.
• Preserve logs and consistent backups. Never delete the ledger/market database, shorten history or change genesis to get a node to start. Remove a stale lock only after verifying that its process is stopped and completing the documented recovery review.
• Resolve conflicting chains by the reviewed consensus/incident policy; do not silently install an ad hoc checkpoint or restore stale payment state against a newer chain.

After a controlled launch, observe the agreed soak period and obtain a second operational acceptance before expanding exposure. Real payments must not be part of a mock-market soak.