Build 230 • Separate processes, one 43-gate blocker authority

Prelaunch Operations Map

Use each launch tool for its own job. Startup Readiness keeps every unresolved blocker and proof requirement—including the D1 Visual Image Manifest; the pages below run the technical and operational stages in order.

Prelaunch stages from product proof and deployment preflight through controlled go-live and live monitoring
Process map • stage results still require production evidence

Startup Readiness remains the complete blocker register

Never remove a gate merely because another page tests part of it. Save status, owner, due date, evidence, correction and retest results in the D1-backed Startup Readiness Cockpit. A green specialist screen is supporting evidence—not permission to ignore another open Critical gate.

Loading the current blocker summary…

Open all Startup blockers
1

Product Release Preflight

Purpose: prove each intended launch product has accurate facts, approved media, inventory, packaging, content and public presentation.

  1. Freeze the small launch-product list.
  2. Run every product row and the IMAGES_REQUIRED manifest.
  3. Open each public product page after corrections.
  4. Save accepted warnings and owner evidence.

Pass: every launch product is green, manually reviewed and free of missing/fallback/placeholder imagery.

If failed: correct the owning product, media, inventory or packaging record—never hide the warning.

Open Product Preflight
2

Deployment Preflight

Purpose: inspect the package before production changes: schema compatibility, current migration, Functions syntax, one-H1, metadata, canonical, JSON, image alt, CSS and fallback health.

  1. Run the local/static release checks.
  2. Confirm the current migration has no explicit SQL transaction statements.
  3. Resolve every blocker.
  4. Save/export the preflight result.

Pass: zero blockers and a recoverable D1 point exists.

If failed: stop; correct the package and rerun the entire preflight.

Open Deployment Preflight
3

Safe Deploy Package

Purpose: confirm exactly which archive, migration, schema, changed files and post-deploy actions are being released.

  1. Compare build label and manifest.
  2. Apply one current migration only.
  3. Deploy the complete ZIP.
  4. Record deployment and migration identifiers.

Pass: the deployed tree and D1 ledger match the approved package.

If failed: restore the previous deployment or D1 point and investigate before continuing.

Open Safe Deploy
4

Post-Deploy Smoke Tests

Purpose: prove the live deployment actually serves its core public/admin/API journeys after the release.

  1. Test public routes signed out.
  2. Test login and protected routes.
  3. Test shop, product, cart and safe API reads.
  4. Check mobile layout, CSS, errors and fallbacks.

Pass: every critical live URL and journey has current evidence.

If failed: stop promotion, record the exact route/result, fix or roll back, then repeat all smoke tests.

Open Smoke Tests
5

Deploy Readiness

Purpose: make the final promotion decision using blocker counts, rollback status, manifest evidence and release-control checks.

  1. Confirm all Critical Startup gates are closed.
  2. Review smoke-test and rollback evidence.
  3. Confirm owner and stop conditions.
  4. Record the final decision.

Pass: explicit approval exists and no unresolved Critical gate remains.

If failed: return to the named blocker; do not promote around it.

Open Deploy Readiness
6

Go-Live Execution

Purpose: perform the controlled opening steps—not another generic test screen.

  1. Confirm the small product/stock scope.
  2. Enable only approved public paths.
  3. Record opening time and owner on duty.
  4. Queue immediate monitoring.

Pass: the controlled opening is observable, reversible and within approved scope.

If failed: pause checkout/public promotion and use the documented rollback or product-hide control.

Open Go-Live Execution
7

Live Ops Follow-through

Purpose: monitor real orders, inventory, payments, email, customer support, refunds, incidents and public content after opening.

  1. Watch the first transactions in real time.
  2. Reconcile system records.
  3. Record incidents and customer recovery.
  4. Reopen affected Startup gates when evidence changes.

Pass: operations remain reconciled and every incident has an owner/outcome.

If failed: activate the stop condition, preserve evidence, recover customers and reopen the related readiness gate.

Open Live Ops

Detailed written playbooks

PRELAUNCH_PROCESS_PLAYBOOKS.md explains each standalone process click by click. STARTUP_GO_LIVE_GUIDE.md retains every individual blocker and its correction/evidence/retest instructions.