platepilot

Rollback runbook

When to use

Use rollback when a validated change makes the local scaffold unusable or, in a future environment, when a release causes sustained errors, data-integrity risk, privacy exposure, or a failed health gate.

Rollback is not automatically safe for data-contract or schema changes. Prefer containment and a reviewed forward fix when reverting would corrupt or hide data.

M0 local recovery

  1. Preserve useful non-sensitive error output; never copy tokens, photos, or personal records.
  2. Stop the affected development process.
  3. Return the working tree to a known reviewed revision using the team’s normal version-control workflow.

  4. Recreate dependencies from the lockfile:

    corepack pnpm install --frozen-lockfile
corepack pnpm prisma:generate

  5. Validate local service configuration and the workspace:

    corepack pnpm compose:config
corepack pnpm check
  6. Start the required local processes and verify /health.

Do not delete Docker volumes merely to hide a compatibility defect. If synthetic local state can be discarded intentionally, docker compose down -v removes it permanently; confirm no needed data exists first.

Future beta containment

All steps are PENDING until real infrastructure exists:

  1. Declare an incident and pause additional releases.
  2. Protect data first: disable the affected write path/provider or put the service into an approved reduced mode.
  3. Identify the last known-good immutable API and worker artifacts.
  4. Check schema and contract compatibility before changing runtime versions.
  5. Roll back one controlled stage using the approved deployment mechanism.
  6. Verify health, error rate, authorization, queues, data integrity, and critical adult/manual flows.
  7. Decide whether queued jobs need pause, replay, deduplication, or quarantine.
  8. Communicate status and continue heightened monitoring.

Database and irreversible changes

PENDING: adopt expand/contract migrations, backward-compatible queue contracts, and tested restoration. Never run an ad hoc destructive migration or restore over the only copy. A backup restore is a separate incident-level decision under Backup and restore.

Exit criteria