engine_surgerylisted

# engine_surgery — changing the engine you are running This repo IS the engine. Every shell here runs on the code it edits, reads a DB it migrates, and is served by a process started from the tree it commits to. That is surgery on a moving car, and it has one characteristic failure mode: **a command answers confidently from a target you did not mean.** **Fork shells never load this.** A fork consumes `.super-coder/` as a gitignored dependency pinned by `engine.ref` and updates it with `./sc update`; it never authors engine changes. Granted only in the source repo. ## The four trees, and which one bites | tree | what it is | who keeps it current | |---|---|---| | your worktree | `.sc-worktrees/<shortname>` — your cwd, your branch | you; boot reports it as `sync:` | | the main checkout | resolves your `./sc`, hosts the live DB, runs the server | admin / the FnB; boot reports it as `floor:` | | the running process | code already imported — changes only on restart | the FnB | | `origin/main` | the truth | whoever merged last | `sc:11-21` derives the engine root from git's **common dir**, so `./sc` from any worktree reads the MAIN CHECKOUT. Being current in your own tree tells you nothing about it. Read the `floor:` line in ACTIVE SESSION. **Verify any claim about engine code against the remote:** ``` git show origin/main:<path> # correct ./sc help | grep <thing> # answers from the main checkout — may be stale ``` Three wrong answers in one session came from ski