# Safety Launch Protocol — Transfer of Thoughts (CPR‑Ready)

**Status:** Canonical product/ops intent.  
**Audience:** Founder, operators, agents shipping deploy-facing work.  
**Related:** [ALPHA_OPS.md](ALPHA_OPS.md) · [ALPHA_TESTER.md](ALPHA_TESTER.md) · [persistence-product-spec.md](persistence-product-spec.md) · [object-store.md](object-store.md) · User trust page: [`data-safety.html`](../data-safety.html)

BizBarrel requires a formal Safety Launch Protocol to guarantee that no user data is ever lost, corrupted, overwritten, or accidentally replaced during development or deployment. The system must enforce multi‑layer backups, redundant storage, staging‑first deployment, and automated verification before any production changes occur. The protocol exists to prevent accidental FTP overwrites, misconfigured uploads, or human error from impacting live user data.

> **Honesty layer:** Sections 1–8 below are the **target protocol**. The **Alpha now** section states what is true today (founder‑gated live eval). Do not claim enterprise backup guarantees to testers until the matching ops layers are running.

---

## 1. Core Principle

User data is sacred. No deployment, update, or maintenance action may proceed unless the system confirms that all backup layers are healthy, recent, and fully synchronized. Production must be treated as a protected environment with strict write controls.

## 2. Backup Architecture

- **Daily full database snapshots** stored off‑server, retained for 30 days.
- **Hourly incremental backups** capturing only changed rows, retained for 48 hours.
- **Triple‑copy redundancy:**
  - Primary: production server
  - Secondary: mirrored read‑only server
  - Tertiary: cloud archive (S3/B2/Wasabi)
- **User‑level versioning:** every chain, note, feed, and Organizer item maintains its own version history. Users can restore individual items; administrators can restore globally.

## 3. Deployment Safety

- **Pre‑Launch Backup Lock:** deployment is blocked unless fresh DB and file snapshots exist and off‑server mirrors are synced.
- **Staging‑First Rule:** all uploads go to `/staging` first; automated checks run; only then can files be promoted to `/prod`.
- **Production Write Lock:** production cannot be modified unless manually unlocked. The lock auto‑reverts after 30 minutes.

## 4. Redundancy & Recovery

- **Shadow copies** of all user data maintained in parallel with live data.
- **Point‑in‑time recovery** available for critical incidents.
- **Disaster Recovery Mode:** if production becomes unstable, the system switches to read‑only mode using mirrored data until full restoration is complete.

## 5. Monitoring & Verification

- **Backup Health Dashboard** showing:
  - Last backup timestamp
  - Backup size
  - Mirror sync status
  - Restore test results
  - Alerts for failures
- **Weekly automated restore tests:** temporary environment is spun up, backups restored, integrity validated, environment destroyed.

## 6. User Trust Layer

- **Data Safety Page:** users can view their version history, export their data, and understand how BizBarrel protects their information.  
  → Public page today: [`data-safety.html`](../data-safety.html) (theme × Display compliant). Item‑level restore UI and full export pack are phased.
- **Transparent retention policy:** clear explanation of snapshot schedules and recovery guarantees.

## 7. Operational Discipline

- No direct FTP uploads to production.
- No manual file edits on production.
- All changes flow through staging and automated checks.
- All deployments require explicit human confirmation after backup verification.

## 8. Purpose

This protocol ensures BizBarrel can scale, collaborate, and operate safely without risking user chains, notes, Organizer entries, shared workspaces, or any future modules. It transforms BizBarrel from a clever indie tool into a trustworthy platform with enterprise‑grade data protection.

---

## Alpha now (founder‑gated live)

Until §2–§5 are automated in production, operators **must**:

| Practice | Detail |
|----------|--------|
| Manual DB + uploads backup before schema/migrations | See [ALPHA_OPS.md](ALPHA_OPS.md) (album/object‑store pre‑flight) |
| Prefer `live/` configs; never commit secrets | `live/config_db.php`, `live/config_mail.php` |
| Migrations via CLI runners only | `php db/db_run_create.php` + `sql/run_*.php` — not FTP of random SQL |
| No direct prod file surgery | Edit locally / staging tree; promote deliberately |
| Tester honesty | [ALPHA_TESTER.md](ALPHA_TESTER.md): do not store irreplaceable data only in BizBarrel during alpha |
| Partial versioning already in product | Photo album versions; blog post revisions (owner); Stash Box put‑away — not universal item history yet |

### Phased build toward full protocol

1. **P0 — Ops discipline** (this doc + ALPHA_OPS habits) — *in force for alpha*  
2. **P1 — Scheduled off‑server DB + `uploads/` snapshots** (daily minimum)  
3. **P2 — Staging promote path + pre‑deploy backup check script**  
4. **P3 — Mirror / cloud tertiary + restore drill automation**  
5. **P4 — Backup Health Dashboard (owner/admin) + user export pack**  
6. **P5 — Broader per‑item version history beyond photos/blog revisions**

Agents and humans shipping deploy‑facing changes must not assert that P1–P5 are live unless the matching infra exists.