refactor(env): explicit defaults.env with placeholders; drop auto-injection

A service/job's env is now exactly its defaults.env — castle injects no hidden
convention vars. Values support ${port}/${data_dir}/${name} placeholders
(resolved at deploy, alongside ${secret:…}), so a program's own env var names
map to castle's computed values without hardcoding.

Why: the auto-injected <PREFIX>_PORT/<PREFIX>_DATA_DIR were a guess at the
program's env names — right for castle-scaffolded services, dead weight for
adopted ones (lakehouse carried two dead vars; notification-bridge/backup jobs
too). They also weren't visible in the config editor (computed at deploy), which
was the source of the 'four env vars but the UI shows none' mystery.

- core: resolve_env_vars gains a context (${port}/${data_dir}/${name});
  deploy builds env from defaults.env only — no <PREFIX>_* injection, no
  port_env. Removed the port_env field and the dead _env_prefix helper.
- cli: 'service/job create' gains repeatable --env KEY=VALUE (replaces
  --port-env); 'program create' scaffolds <PREFIX>_PORT/_DATA_DIR: ${…} for new
  daemons.
- app: removed the 'Port env' field; the Environment editor (defaults.env) is
  the single place, with a placeholder hint.
- live migration: central-context/castle-api/power-graph/protonmail mapped their
  real vars explicitly; lakehouse → just LAKEHOUSED_DAEMON_PORT: ${port}, data
  stays in ~/.lakehoused. Verified all services healthy on their ports, dead
  vars gone, zero failed units.
- docs: registry.md/design.md/stack guides + findings updated to the explicit
  model.

core 94 / cli 24 / api 52 green; ruff + app build clean.
This commit is contained in:
2026-06-14 17:06:46 -07:00
parent fd562f7468
commit 7314b5cddb
13 changed files with 122 additions and 89 deletions

View File

@@ -40,10 +40,13 @@ the daemon's built-in default and we declared the same value. Castle's
convention assumes a castle-aware program; an adopted one doesn't read
`<PREFIX>_PORT`.
**Fix:** let a service declare which env var carries the port, e.g.
`expose.http.port_env: LAKEHOUSED_DAEMON_PORT`, so castle sets *that* to the
configured port and genuinely drives the bind. (`defaults.env` is the manual
workaround.)
**Fixed** (superseding the interim `port_env` field): auto-injection of the
convention vars was dropped entirely. A service's env is now exactly its
`defaults.env`, with `${port}`/`${data_dir}`/`${name}` placeholders for castle's
computed values. lakehouse maps just what it reads —
`LAKEHOUSED_DAEMON_PORT: ${port}` — and keeps its own data root, with no dead
vars. Castle-native services map their `<PREFIX>_PORT`/`_DATA_DIR` the same way
(scaffolded by `castle program create`).
### #3 — `castle deploy` regenerates the Caddyfile but never reloads Caddy (High, bug)