Rename Installation to Instance
Follows the portal: the noun is "instance" everywhere the app says it — UI strings, CLI output, error details, docs and comments. The wire keys (`instance_id`, `instance_token`) and the hub route this calls move with it. An existing cloud.json is adopted rather than refused: without the key alias the dataclass fails to parse, which the caller swallows and reads as "never enrolled" instead of "reconnect". `instance_key` on a node type becomes `target_key`. It means the outside thing a node points at, which is a different sense of the word, and keeping both would put two meanings of "instance" in one codebase. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015YrQnKV3bnQd4K342y8tKj
This commit is contained in:
+1
-1
@@ -108,7 +108,7 @@ The backend settings load `../.env` relative to `backend/` through pydantic-sett
|
||||
exported environment variable always outranks the file, which is how the suite pins its own
|
||||
configuration.
|
||||
|
||||
`DATA_DIR` is where this installation keeps everything: the SQLite database, the flow git
|
||||
`DATA_DIR` is where this instance keeps everything: the SQLite database, the flow git
|
||||
repository, `secrets.enc`, `oauth-key.pem`, `cloud.json`, artifacts and the user venv. Each
|
||||
path derives from it and can still be set on its own — the compose stack spells all of them
|
||||
out against `/data`.
|
||||
|
||||
Reference in New Issue
Block a user