Second instance on one account: settings-file selector and per-instance job names

[renmengye]

Lets an operator run a second, fully separate Outerloop instance on the same cluster account, for example a sandbox target with different role settings, next to a production fleet.

What changes

• OUTERLOOP_ENV_FILE (process environment only): an absolute path to the operator settings file. Default unchanged (~/.config/outerloop/.env); same trust rules. Used by start, init, status, harness commands, the deploy step and the resident loop, and carried through the chain's resubmits. An empty value means the default.
• Per-instance scheduler names keyed on the settings file, not the state root. With the default settings file, the job names stay exactly outerloop-resident and outerloop-tick, whatever the root; any other settings file gets a stable 12-hex suffix on both. Start, stop, status, self-heal, the chain script and printed hints all use the instance's names, so two instances never see or cancel each other's jobs. Tick lease and heartbeat are per state root.
• Docs: "Running two instances on one account" (separate state root, settings file and resident job; per-user scheduler caps are shared; two instances cannot share one settings file).

Compatibility (RELEASING.md)

Legacy default settings, including settings files with no OUTERLOOP_ROOT line (the root passed at start and carried in the job environment), keep outerloop-resident and outerloop-tick; no migration or operator action, and the first upgraded tick keeps recognizing the running chain. Persisted state formats are unchanged, including in-flight runs and PRs. Rolling back the default fleet is safe; stop additional instances before rolling back to a version without instance isolation.

Tests

The production case above (no root in the settings file, non-default root) keeps both names, mutation-checked; a selected settings file gets stable suffixed names; a path resolving to the default file is the default instance; an empty selector is the default; the selector survives both resubmit paths; stop/status/self-heal only touch their own instance; lease and heartbeat per root. Gate: 2635 passed, 6 skipped; ruff, format, mypy clean.

Built by codex from my brief; my cross-review caught that identity must not be inferred from the state root (a live deployment's settings file does not name it) and the empty-selector edge.

🤖 Generated with Claude Code

[github-actions]

Round 1 — reviewed head 3eadea8e — reviewer summarizer:hermes/gpt-5.6-terra over coverage+credentials+deployment+general+lifecycle+prose.

terra
Advisory findings from outerloop — the code owner decides. Reply to disagree; the outerloop:no-review label opts this PR out.

Verdict: 1 blocking, 1 advisory.

1 finding attached to the lines below.

Advisory (non-blocking):

• Queue status hides scheduler jobs for selected settings files. [lifecycle] Instance jobs are now named outerloop-resident-<suffix> and outerloop-tick-<suffix>, but this matcher accepts only the unsuffixed names, so a selected instance’s own resident and tick jobs are omitted from its queue view. (src/outerloop/climbboard.py:893; high confidence)

Merged two findings. Rejected as duplicates: the coverage and general whitespace-selector reports make the same scripts/tick_deploy.sh:17 claim as credentials and are merged under [coverage+credentials+general]; deployment and prose supplied no findings.

[github-actions]

Round 1 — reviewed head f1ab11d4 — reviewer hermes/gpt-5.6-terra.

terra
Advisory findings from outerloop — the code owner decides. Reply to disagree; the outerloop:no-review label opts this PR out.

Verdict: no defects found.