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 `.sc-state/local/content.sql` 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 the shared instance's gitignored local cache. `sc snapshot` and `sc render` run from the main checkout; the dispatcher refuses them from a linked shell worktree. The GUI **Save locally** button, `install`, `update`, and `render-check` run them for you. A working shell does not run them; its writes are captured when admin saves locally 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/local/content.sql` | **this repo's** per-instance content + memory — shells, seed/L&S, decisions, roadmap, documents, flags, projects, skill grants | no (instance-only, gitignored) | `sc snapshot` | The split: system content propagates via migrations; per-instance content stays in the snapshot. Skill *bodies* = system (migration); whic...