Standby worker pool (opt-in)

By default, every cyberine chat /run (and cyberine run --bg) cold-spawns a fresh detached child, paying the Node+tsx startup cost each time. The standby pool pre-warms N named worker slots so a subsequent /run can skip the git worktree add step inside the isolate path, cutting dispatch latency on repeated tasks within the same chat session.

Enable via env or flag:

# env var (applies to the next `cyberine chat` invocation)
CYBERINE_STANDBY_POOL=opencode-build:2,loop-deepseek:1 cyberine chat

# flag (overrides env; applies to one session only)
cyberine chat --standby opencode-build:2,loop-deepseek:1

The spec is <workerId>:<count>[,<workerId>:<count>] where workerId must match an entry in the worker-profiles table (see cyberine route output or src/core/workerProfiles.ts).

Live-vs-slot asymmetry: CLI workers (OpenCode etc.) are one-shot processes — the pool pre-creates a worktree that is reused across sequential tasks (reset to HEAD between tasks, never carrying dirty state). Loop-adapter workers (key-loop DeepSeek, OpenRouter) have the same slot model in this release; a live-process idle-loop variant is planned for a future update.

Status: while the pool is active, the chat status line shows pool: N idle M busy. Running cyberine agents (plain-text mode) also prints a compact pool summary when a snapshot exists.

Drain on exit: closing the chat session (/exit, Ctrl+C) drains the pool gracefully — all slot worktrees are reset and removed. The reaper handles any lingering processes.

Default = no pool: when CYBERINE_STANDBY_POOL is unset and --standby is not passed, the pool is never initialised and dispatch behaviour is byte-for-byte unchanged.

Env knobs: