[refactor] Rust _server / _ui binaries should read config from hero_proc secrets, not std::env #223

New issue

Open

opened 2026-05-06 21:14:59 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-06 21:14:59 +00:00

Owner

Context

Per the hero_proc_meta skill's canonical rule: all _ui and _server processes must read configuration exclusively from hero_proc secrets, never from OS env or config files.

Today this is widely violated across the Hero stack — most hero_*_server and hero_*_ui Rust binaries use std::env::var(…) (often via dotenvy or hand-rolled config readers) for tokens, API keys, external URLs, context names, socket dirs, and feature flags. This bypasses hero_proc's centralized secret store and forces operators to ship config via ~/.bashrc / per-service env blocks / TOML files / service_*.nu $env reads.

Sibling of:

#222 — same problem, nu install-script layer
https://forge.ourworld.tf/lhumina_code/home/issues/NNN — same problem, WASM frontend layer (sibling)

Umbrella tracker: see #225.

Audit shape

Inventory: grep -rn 'std::env::var\|env!\|option_env!\|dotenvy' lhumina_code/hero_*/crates/{hero_*_server,hero_*_ui}/src/ — produce a per-binary table of which env vars each reads.
Classify each read:
- Config-shaped (token, URL, context, feature flag) → migrate to hero_proc secret read via hero_proc_sdk
- Runtime/process-shaped (RUST_LOG, HOSTNAME, HOME) → keep as-is
Per binary, replace std::env::var("FOO") with hero_proc_sdk::secret_get("FOO") (or the right SDK call), wrap in a typed config struct.
Document the secret list per service in the service's README + hero_demo/docs/ops/DEPLOYMENT.md.

Scope (initial pass — full inventory pending)

Confirmed offenders surfaced during sessions 50–68:

hero_office: ONLYOFFICE_JWT_SECRET, CONNECTOR_EXTERNAL_URL, OO_UPSTREAM_BASE, DEFAULT_CONTEXT, HERO_SOCKET_DIR
hero_agent: AIBROKER_API_ENDPOINT (and likely OpenRouter/Groq keys)
hero_aibroker: provider API keys
hero_books: AI provider keys
hero_voice: ONNX paths (ORT_DYLIB_PATH), STT/TTS provider keys

Real number is likely 30+ secrets across the 21 services with --download wired today. First task of the issue: grep and tabulate.

Sequencing

After home#212 binary rollout completes (currently 22/29 = 76%). Same sequencing as the nu-side companion home#222.

Acceptance criteria

Inventory: per-binary table of env reads classified config vs runtime.
Zero std::env::var reads of config-shaped values in any hero_*_server / hero_*_ui crate. Runtime-shaped reads (RUST_LOG etc.) remain documented exceptions.
Each migrated service has its required secret list documented in its README + DEPLOYMENT.md.
heroci + herodemo seeded with the full secret list via hero_proc secret set.
Smoke: a fresh VM running only hero_proc secret set … and service all install --download && service all start brings up a working stack with no ~/.bashrc edits, no per-service env blocks.

References

~/.claude/skills/hero_proc_meta/SKILL.md — canonical META env-from-secrets rule
~/.claude/skills/hero_proc_secrets/SKILL.md — secret store API
~/.claude/skills/hero_proc_sdk/SKILL.md — Rust SDK for secret_get

## Context Per the `hero_proc_meta` skill's canonical rule: **all `_ui` and `_server` processes must read configuration exclusively from hero_proc secrets, never from OS env or config files.** Today this is widely violated across the Hero stack — most `hero_*_server` and `hero_*_ui` Rust binaries use `std::env::var(…)` (often via `dotenvy` or hand-rolled config readers) for tokens, API keys, external URLs, context names, socket dirs, and feature flags. This bypasses hero_proc's centralized secret store and forces operators to ship config via `~/.bashrc` / per-service `env` blocks / TOML files / `service_*.nu` `$env` reads. Sibling of: - https://forge.ourworld.tf/lhumina_code/home/issues/222 — same problem, nu install-script layer - https://forge.ourworld.tf/lhumina_code/home/issues/NNN — same problem, WASM frontend layer (sibling) Umbrella tracker: see https://forge.ourworld.tf/lhumina_code/home/issues/225. ## Audit shape 1. Inventory: `grep -rn 'std::env::var\|env!\|option_env!\|dotenvy' lhumina_code/hero_*/crates/{hero_*_server,hero_*_ui}/src/` — produce a per-binary table of which env vars each reads. 2. Classify each read: - **Config-shaped** (token, URL, context, feature flag) → migrate to hero_proc secret read via `hero_proc_sdk` - **Runtime/process-shaped** (`RUST_LOG`, `HOSTNAME`, `HOME`) → keep as-is 3. Per binary, replace `std::env::var("FOO")` with `hero_proc_sdk::secret_get("FOO")` (or the right SDK call), wrap in a typed config struct. 4. Document the secret list per service in the service's README + `hero_demo/docs/ops/DEPLOYMENT.md`. ## Scope (initial pass — full inventory pending) Confirmed offenders surfaced during sessions 50–68: - `hero_office`: `ONLYOFFICE_JWT_SECRET`, `CONNECTOR_EXTERNAL_URL`, `OO_UPSTREAM_BASE`, `DEFAULT_CONTEXT`, `HERO_SOCKET_DIR` - `hero_agent`: `AIBROKER_API_ENDPOINT` (and likely OpenRouter/Groq keys) - `hero_aibroker`: provider API keys - `hero_books`: AI provider keys - `hero_voice`: ONNX paths (`ORT_DYLIB_PATH`), STT/TTS provider keys Real number is likely 30+ secrets across the 21 services with `--download` wired today. First task of the issue: `grep` and tabulate. ## Sequencing **After home#212 binary rollout completes** (currently 22/29 = 76%). Same sequencing as the nu-side companion home#222. ## Acceptance criteria - [ ] Inventory: per-binary table of env reads classified config vs runtime. - [ ] Zero `std::env::var` reads of config-shaped values in any `hero_*_server` / `hero_*_ui` crate. Runtime-shaped reads (RUST_LOG etc.) remain documented exceptions. - [ ] Each migrated service has its required secret list documented in its README + `DEPLOYMENT.md`. - [ ] heroci + herodemo seeded with the full secret list via `hero_proc secret set`. - [ ] Smoke: a fresh VM running only `hero_proc secret set …` and `service all install --download && service all start` brings up a working stack with no `~/.bashrc` edits, no per-service env blocks. ## References - `~/.claude/skills/hero_proc_meta/SKILL.md` — canonical META env-from-secrets rule - `~/.claude/skills/hero_proc_secrets/SKILL.md` — secret store API - `~/.claude/skills/hero_proc_sdk/SKILL.md` — Rust SDK for secret_get