snapshot

# snapshot — serialize the DB back to text Live `shell_db.db` = the single source of truth shared by every shell; a `sc mem` write is durable + visible to all shells the instant it commits. The `.db` is gitignored and reconstructs from schema, migrations, and the active per-instance snapshot on `sc rebuild` — an edit not yet serialized is discarded by a rebuild. Serializing is an admin/GUI operation, NOT a per-write shell step: it writes `.sc-state/` + the flat `_sc` mirror into the shared MAIN worktree, and from a shell's linked worktree it churns and collides with other shells. `sc snapshot` and `sc render flat` refuse unless `SC_ADMIN=1` (GUI/API, `install`, `update`, and `render-check` set it for you). A shell does not run them; its writes are captured when admin snapshots (GUI **Publish**/Snapshot button, or `SC_ADMIN=1 sc snapshot`) before a rebuild. The rest of this skill = the admin/GUI path. ## The three text serializations | File(s) | What | Propagates? | Written by | |---|---|---|---| | `schema.sql` | the v1 baseline schema | yes (forks) | hand, rarely | | `migrations/*.sql` | ordered schema + **system content** deltas (e.g. the skills catalogue) | yes (forks) | author / `sc seed-skills` | | `.sc-state/content.sql` (tracked mode) or `.sc-state/local/content.sql` (local mode) | **this repo's** per-instance content + memory — shells, seed/L&S, decisions, roadmap, documents, flags, projects, skill grants | no (instance-only) | `sc snapshot` | The split: system co...