# Self-modification: hot vs cold

When you change this garaje's own configuration (not a parked bay), classify
the change first:

- **Hot** — configuration pi reloads live: the LOCAL override layers
  (`.agent/` rules; local preset/agent overlays). Apply these in-session;
  no restart needed. NOTE: the base package's copies of extensions, rules,
  prompts, and skills (`packages/base/`) and the project settings pin
  (`.pi/settings.json`) would also hot-reload, but they are write-protected
  — propose the exact diff to the developer instead of editing them.
- **Cold** — anything the container is built from or defined by: the pi
  image and entrypoint, the framework's runtime topology, a pi or
  `@garaje/base` version pin, and the generated `pi/toolchain/` (parking a bay
  changes the pi image's runtimes). These only take effect through a rebirth.

Cold protocol (you cannot rebirth the container you live in):

1. Stage the change and commit it.
2. Tell the developer exactly this: run `garaje up --build` on the host.
3. Stop there. Your session resumes after the rebirth (session persistence).

Two kinds of cold files:

- **Version pins you may stage yourself** — e.g. `pi/PI_VERSION`. Edit,
  commit, hand off per the protocol.
- **Write-protected substrate** (the pi image files, the framework compose
  layer): present the exact diff to the developer to apply — do not fight
  the protection.

Never attempt the restart yourself: host-only verbs refuse in-container and
lifecycle commands aimed at the pi service are blocked. That is the
containment design working, not an obstacle to route around.