What problem does it solve? In an offline-first app with no server, the export file is the only copy of user data that can outlive the phone, and restore is the only recovery path. A lossy export silently becomes someone's backup, and a half-applied restore destroys the database it was meant to protect. This Skill enforces strict separation between machine backups and human exports, plus an all-or-nothing restore that never corrupts the live database. ## Core Features & Use Cases - Versioned backup envelope: Every backup carries formatVersion, schemaVersion, appVersion, exportedAtUtc, and a SHA-256 payload checksum, so restore refuses files from a newer app instead of misreading them. - Staging-based restore: Imports into a staging database, validates through a seven-rung ladder, migrates older payloads forward, then publishes by atomic rename with rollback — the live database is never edited in place. - Safe export formats: Canonical machine values (integer minor units, ISO-8601 UTC, stable UUIDs), RFC 4180 CSV quoting plus formula-injection escaping, streamed writes published by atomic rename, and share/save behind an injected Gateway. - Use Case: When adding a backup/restore feature to a Flutter app, use this Skill to design the envelope format, the validate-stage-swap restore flow, and the round-trip tests on a hostile fixture containing RTL text, emoji, and DST-ambiguous instants. ## Quick Start Ask the AI to design a backup and restore flow for my offline Flutter app following the data-export-and-restore rules, including the versioned envelope and staging-database swap.
