self_update

# self_update — laying a new floor under your own feet The local shell updates its own substrate — no external rebuild. All state lives in the DB and engine code is read live each session, so a code-only update touches no data; a schema change applies as an in-place migration, never a destructive rebuild. `current_state`, narrative, decisions, flags, seed, and L&S all carry across. This is succession for the substrate: you handing off to you. ## When - An engine update is available and you choose the moment — no external race. - The running prompt + schema were read at the old boot -> reboot after the update; they refresh only on the far side. ## Procedure 1. **Clean tree first.** `git -C <repo> status` -> clean. Commit, PR, or discard any prior update's output BEFORE running again — a fresh `sc update` on top of a stranded one stacks two engine bumps into one diff. Glance at `current_state` + make it true for now (the snapshot captures it). 2. **Run.** `sc update` — fetches the engine from the `super-coder` remote, materializes it into the gitignored `.super-coder/` dir (engine = dependency, not fork source), pins the new upstream SHA in `.sc-state/engine.ref` (prior saved as `engine.ref.prev`), backs up the live DB, applies pending migrations in place, syncs the skills catalogue, re-grants common skills, maps the repo, re-snapshots the live state. - `sc update --no-fetch` = reconcile against the current working tree (offline / dev); e...