lhumina_code/home
0
0
Fork 0
Code Issues 34 Pull requests Projects Releases Packages Wiki Activity Actions

[meta] All Hero stack components should read config from hero_proc secrets (cross-layer META compliance) #225

New issue
Open
opened 2026-05-06 21:15:54 +00:00 by mik-tf · 1 comment
mik-tf commented 2026-05-06 21:15:54 +00:00
Owner
Copy link

Goal

Every Hero stack component reads config from hero_proc secrets, not from OS env / config files / option_env! / iframe params. Single canonical source across all three layers (nu scripts, native Rust, WASM).

The META rule from hero_proc_meta skill: "all _ui and _server processes must read configuration exclusively from hero_proc secrets, never from OS env or config files." This umbrella extends that principle to the install-side nu scripts and the WASM frontend, since the same operator-experience problem ("oh you forgot to export X") applies at every layer.

Why now

Surfaced sharply during session 68 (hero_office Bucket C item 4 of #212). hero_office is the only private repo in lhumina_code/; making service office install --download work required forwarding FORGEJO_TOKEN from the operator's shell, which is exactly the wrong layer. The fix landed (lhumina_code/hero_skills@c28ba16) as transition compatibility, but the right shape is hero_proc secret reads everywhere.

Children

# Layer Status
#222 nu install scripts (lib.nu + service_*.nu) open
#223 native Rust binaries (hero_*_server / hero_*_ui) open
#224 WASM frontend (hero_os shell + hero_archipelagos islands) open

Sequencing

  1. Block on home#212 (binary rollout — currently 22/29 = 76%). Don't start META work until all 29 services are wired with --download so we have a stable consumer surface to refactor.
  2. home#222 first — nu install scripts. Smallest surface, unblocks operator workflow improvements immediately.
  3. home#223 next — native Rust binaries. Bulk of the work; most secrets live here.
  4. home#224 last — WASM frontend. Depends on home#223 because the per-service /config endpoint that WASM calls is itself a Rust binary that needs to be reading from hero_proc secrets first.

End state — fresh-VM deploy contract

After all three children land, the entire Hero stack ships from a bare VM via:

# 1. Install hero_proc itself (single binary, ~5s download).
service proc install --download
service proc start --reset

# 2. Seed secrets once. Single source of operator-side config.
hero_proc secret set FORGEJO_TOKEN <value>
hero_proc secret set ONLYOFFICE_JWT_SECRET <value>
hero_proc secret set <…full canonical list…>

# 3. Install + start all 29 services. Binaries fetched from Forgejo Releases,
#    config fetched from hero_proc secrets at process start.
service all install --download
service all start

No ~/.bashrc edits. No per-service env blocks. No iframe boot-param passthrough of secrets. No option_env!-baked tokens. No "I forgot to source env.sh" incidents.

Acceptance criteria

  • All three children closed.
  • Smoke: bare TFGrid VM → working herodemo in under 15 minutes following only the contract above (no ad-hoc env edits).
  • hero_demo/docs/ops/DEPLOYMENT.md documents the canonical secret list.
  • CLAUDE.md "Reading order for new sessions" updated to point at the secret-store contract instead of source ~/hero/cfg/env/env.sh.

References

  • ~/.claude/skills/hero_proc_meta/SKILL.md
  • ~/.claude/skills/hero_proc_secrets/SKILL.md
  • #212 — binary rollout (blocking parent)
  • lhumina_code/hero_skills@c28ba16 — the env-based transition fix that triggered this umbrella

Final form — where this work lands

This META compliance umbrella is the second leg of a three-leg tripod that makes Hero deployable as an end-user product, not just a demo.

Leg Tracker Role
Binaries #212 Deterministic install (no cargo build)
Config (this) this issue Deterministic config (hero_proc secrets)
State #226 Portable per-instance + per-context data

Once all three land plus the (separately planned) auth arc, hero_router becomes the install surface in a one-session add: it already knows every running service via discovery; exposing /install/list + /install/<name> (calling into hero_proc's existing service-install path) collapses the bootstrap to two binaries — hero_router + hero_proc. From a bare HTTPS endpoint, the owner installs hero_os, then any app, all binaries fetched from Forgejo Releases, all config seeded via hero_proc secret set, all state per-context portable.

The Store island in hero_archipelagos (archipelagos/archipelagos/archipelagos/src/island.rs) already has TODO comments naming exactly this: "In the future, this Store will support downloading apps from a package registry, at which point uninstalled apps will show a 'Get' button." No new repos, no new verbs — the install path already exists; this umbrella just makes its config layer deterministic enough that the Store's "Get" button can call it without operator-side env juggling.

So this issue is not just hygiene — it's a precondition for the end-user product loop. Without it, the install path stays operator-only (must SSH and export FOO=bar per service); with it, install becomes a button click.

## Goal **Every Hero stack component reads config from hero_proc secrets, not from OS env / config files / `option_env!` / iframe params.** Single canonical source across all three layers (nu scripts, native Rust, WASM). The META rule from `hero_proc_meta` skill: "all _ui and _server processes must read configuration exclusively from hero_proc secrets, never from OS env or config files." This umbrella extends that principle to the install-side nu scripts and the WASM frontend, since the same operator-experience problem ("oh you forgot to export X") applies at every layer. ## Why now Surfaced sharply during session 68 (hero_office Bucket C item 4 of https://forge.ourworld.tf/lhumina_code/home/issues/212). hero_office is the only private repo in `lhumina_code/`; making `service office install --download` work required forwarding `FORGEJO_TOKEN` from the operator's shell, which is exactly the wrong layer. The fix landed (https://forge.ourworld.tf/lhumina_code/hero_skills/commit/c28ba16) as transition compatibility, but the right shape is hero_proc secret reads everywhere. ## Children | # | Layer | Status | |---|---|---| | https://forge.ourworld.tf/lhumina_code/home/issues/222 | nu install scripts (`lib.nu` + `service_*.nu`) | open | | https://forge.ourworld.tf/lhumina_code/home/issues/223 | native Rust binaries (`hero_*_server` / `hero_*_ui`) | open | | https://forge.ourworld.tf/lhumina_code/home/issues/224 | WASM frontend (`hero_os` shell + `hero_archipelagos` islands) | open | ## Sequencing 1. **Block on home#212** (binary rollout — currently 22/29 = 76%). Don't start META work until all 29 services are wired with `--download` so we have a stable consumer surface to refactor. 2. **home#222** first — nu install scripts. Smallest surface, unblocks operator workflow improvements immediately. 3. **home#223** next — native Rust binaries. Bulk of the work; most secrets live here. 4. **home#224** last — WASM frontend. Depends on home#223 because the per-service `/config` endpoint that WASM calls is itself a Rust binary that needs to be reading from hero_proc secrets first. ## End state — fresh-VM deploy contract After all three children land, the entire Hero stack ships from a bare VM via: ``` # 1. Install hero_proc itself (single binary, ~5s download). service proc install --download service proc start --reset # 2. Seed secrets once. Single source of operator-side config. hero_proc secret set FORGEJO_TOKEN <value> hero_proc secret set ONLYOFFICE_JWT_SECRET <value> hero_proc secret set <…full canonical list…> # 3. Install + start all 29 services. Binaries fetched from Forgejo Releases, # config fetched from hero_proc secrets at process start. service all install --download service all start ``` No `~/.bashrc` edits. No per-service env blocks. No iframe boot-param passthrough of secrets. No `option_env!`-baked tokens. No "I forgot to source env.sh" incidents. ## Acceptance criteria - [ ] All three children closed. - [ ] Smoke: bare TFGrid VM → working herodemo in under 15 minutes following only the contract above (no ad-hoc env edits). - [ ] `hero_demo/docs/ops/DEPLOYMENT.md` documents the canonical secret list. - [ ] CLAUDE.md "Reading order for new sessions" updated to point at the secret-store contract instead of `source ~/hero/cfg/env/env.sh`. ## References - `~/.claude/skills/hero_proc_meta/SKILL.md` - `~/.claude/skills/hero_proc_secrets/SKILL.md` - https://forge.ourworld.tf/lhumina_code/home/issues/212 — binary rollout (blocking parent) - https://forge.ourworld.tf/lhumina_code/hero_skills/commit/c28ba16 — the env-based transition fix that triggered this umbrella ## Final form — where this work lands This META compliance umbrella is the **second leg of a three-leg tripod** that makes Hero deployable as an end-user product, not just a demo. | Leg | Tracker | Role | |---|---|---| | Binaries | https://forge.ourworld.tf/lhumina_code/home/issues/212 | Deterministic install (no cargo build) | | Config (this) | this issue | Deterministic config (hero_proc secrets) | | State | https://forge.ourworld.tf/lhumina_code/home/issues/226 | Portable per-instance + per-context data | Once all three land plus the (separately planned) auth arc, **`hero_router` becomes the install surface** in a one-session add: it already knows every running service via discovery; exposing `/install/list` + `/install/<name>` (calling into hero_proc's existing service-install path) collapses the bootstrap to two binaries — `hero_router` + `hero_proc`. From a bare HTTPS endpoint, the owner installs `hero_os`, then any app, all binaries fetched from Forgejo Releases, all config seeded via `hero_proc secret set`, all state per-context portable. The Store island in `hero_archipelagos` (`archipelagos/archipelagos/archipelagos/src/island.rs`) already has TODO comments naming exactly this: *"In the future, this Store will support downloading apps from a package registry, at which point uninstalled apps will show a 'Get' button."* No new repos, no new verbs — the install path already exists; this umbrella just makes its config layer deterministic enough that the Store's "Get" button can call it without operator-side env juggling. So this issue is not just hygiene — it's a precondition for the end-user product loop. Without it, the install path stays operator-only (must SSH and `export FOO=bar` per service); with it, install becomes a button click.
mik-tf commented 2026-05-08 14:43:14 +00:00
Author
Owner
Copy link

First concrete instance of the META rule shipping is now tracked under home#230 Phase 2 — BASE_PATH purge across hero_biz / hero_foundry / hero_agent / hero_embedder / hero_code / hero_proc. Lands within the spirit of #223 (native Rust binaries) without unblocking the full umbrella.

First concrete instance of the META rule shipping is now tracked under [home#230](https://forge.ourworld.tf/lhumina_code/home/issues/230) Phase 2 — `BASE_PATH` purge across hero_biz / hero_foundry / hero_agent / hero_embedder / hero_code / hero_proc. Lands within the spirit of [#223](https://forge.ourworld.tf/lhumina_code/home/issues/223) (native Rust binaries) without unblocking the full umbrella.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/home#225
No description provided.