feat(hero_proc_server): make FORGE_TOKEN optional at bootstrap (D-06) #97

Merged

mik-tf merged 2 commits from development_mik_proc_token_optional into development

2026-05-07 01:53:07 +00:00

mik-tf commented

2026-05-07 01:37:38 +00:00

Owner

Summary

Drops the hero_proc_server hard-fail exit on missing FORGE_TOKEN env. The supervisor itself does not need a Forgejo credential to manage local processes; operations that genuinely need it (secret pull/secret push, forge merge-driven service installs) fail individually with their own error messages.

This is the structural fix locked by D-06: forge-token-bootstrap-optional in the ai-pipeline workspace.

Why

Bootstrap chicken-and-egg: hero_proc_server is the secrets store. It cannot read its own FORGE_TOKEN secret before it boots. The only place to obtain it pre-boot is OS env, which forces every fresh VM to export it manually before the very first boot — directly contradicting the home#121 onboarding flow ("mosh in → service_complete").
The supervisor's job is local. Process supervision, action management, the local socket APIs — none need to talk to Forgejo. Forge-touching operations are post-bootstrap concerns layered on top of a working supervisor.

Commits

chore: cargo fmt --all + clippy --fix workspace cleanup — pre-existing fmt + clippy debt across 106 files surfaced by the pre-merge gate (cargo fmt --all -- --check && cargo clippy --workspace --all-targets --keep-going -- -D warnings). Mechanical only, no behavior change. Bundled here so the next commit lands on a green workspace.
feat(hero_proc_server): make FORGE_TOKEN optional at bootstrap — drop the early hard-fail in crates/hero_proc_server/src/main.rs; log truthful forge_token status (set / unset with consequence reminder) after tracing init; bump buildenv.sh VERSION 0.4.4 → 0.5.0 to align with the already-bumped workspace Cargo.toml.

Validation

End-to-end on heroci with the patched binary in place and no FORGE_TOKEN/FORGEJO_TOKEN in env: hero_proc_server boots healthy and the startup log line correctly states forge_token="unset (forge ops will fail until set via env or secret pull)".

Old v0.4.4 binary in the same env exits with error: FORGE_TOKEN environment variable is required but not set. — confirming the hard-fail removal is the load-bearing change.

With FORGE_TOKEN set, behavior is unchanged (log says forge_token="set").

Test plan

cargo fmt --all -- --check
cargo clippy --workspace --all-targets --keep-going -- -D warnings
cargo build --workspace
direct binary smoke on heroci with FORGE_TOKEN unset → starts cleanly
direct binary smoke on heroci with FORGE_TOKEN set → starts cleanly, logs "set"
tag v0.5.0-rc1 + CI publishes 3 musl assets at https://forge.ourworld.tf/lhumina_code/hero_proc/releases/tag/v0.5.0-rc1
redeploy on heroci via service_proc install --download --version v0.5.0-rc1 + service_proc start --download (no FORGE_TOKEN) → green

Refs

D-06 forge-token-bootstrap-optional (ai-pipeline workspace decisions/D-06-forge-token-bootstrap-optional.md)
lhumina_code/home#225 (META compliance umbrella)
lhumina_code/home#121 (HeroOS dev environment / onboarding flow that this unblocks)

Companion PR on hero_skills (forthcoming): nu wrapper soft-warn on missing FORGE_TOKEN + svc_verify_binaries_fresh download-aware + 14 services with uniform service_X start --download.

## Summary Drops the hero_proc_server hard-fail exit on missing `FORGE_TOKEN` env. The supervisor itself does not need a Forgejo credential to manage local processes; operations that genuinely need it (`secret pull`/`secret push`, `forge merge`-driven service installs) fail individually with their own error messages. This is the structural fix locked by **D-06: forge-token-bootstrap-optional** in the ai-pipeline workspace. ## Why - Bootstrap chicken-and-egg: hero_proc_server *is* the secrets store. It cannot read its own FORGE_TOKEN secret before it boots. The only place to obtain it pre-boot is OS env, which forces every fresh VM to export it manually before the very first boot — directly contradicting the home#121 onboarding flow ("mosh in → service_complete"). - The supervisor's job is local. Process supervision, action management, the local socket APIs — none need to talk to Forgejo. Forge-touching operations are post-bootstrap concerns layered on top of a working supervisor. ## Commits 1. `chore: cargo fmt --all + clippy --fix workspace cleanup` — pre-existing fmt + clippy debt across 106 files surfaced by the pre-merge gate (`cargo fmt --all -- --check && cargo clippy --workspace --all-targets --keep-going -- -D warnings`). Mechanical only, no behavior change. Bundled here so the next commit lands on a green workspace. 2. `feat(hero_proc_server): make FORGE_TOKEN optional at bootstrap` — drop the early hard-fail in `crates/hero_proc_server/src/main.rs`; log truthful `forge_token` status (set / unset with consequence reminder) after tracing init; bump `buildenv.sh` VERSION 0.4.4 → 0.5.0 to align with the already-bumped workspace Cargo.toml. ## Validation End-to-end on heroci with the patched binary in place and no `FORGE_TOKEN`/`FORGEJO_TOKEN` in env: hero_proc_server boots healthy and the startup log line correctly states `forge_token="unset (forge ops will fail until set via env or `secret pull`)"`. Old v0.4.4 binary in the same env exits with `error: FORGE_TOKEN environment variable is required but not set.` — confirming the hard-fail removal is the load-bearing change. With `FORGE_TOKEN` set, behavior is unchanged (log says `forge_token="set"`). ## Test plan - [x] cargo fmt --all -- --check - [x] cargo clippy --workspace --all-targets --keep-going -- -D warnings - [x] cargo build --workspace - [x] direct binary smoke on heroci with FORGE_TOKEN unset → starts cleanly - [x] direct binary smoke on heroci with FORGE_TOKEN set → starts cleanly, logs "set" - [ ] tag v0.5.0-rc1 + CI publishes 3 musl assets at https://forge.ourworld.tf/lhumina_code/hero_proc/releases/tag/v0.5.0-rc1 - [ ] redeploy on heroci via `service_proc install --download --version v0.5.0-rc1` + `service_proc start --download` (no FORGE_TOKEN) → green ## Refs - D-06 forge-token-bootstrap-optional (ai-pipeline workspace `decisions/D-06-forge-token-bootstrap-optional.md`) - https://forge.ourworld.tf/lhumina_code/home/issues/225 (META compliance umbrella) - https://forge.ourworld.tf/lhumina_code/home/issues/121 (HeroOS dev environment / onboarding flow that this unblocks) Companion PR on hero_skills (forthcoming): nu wrapper soft-warn on missing FORGE_TOKEN + `svc_verify_binaries_fresh` download-aware + 14 services with uniform `service_X start --download`.

mik-tf added 2 commits

2026-05-07 01:37:38 +00:00

chore: cargo fmt --all + clippy --fix workspace cleanup 59e4176f13

Pre-existing fmt + clippy debt across 106 files in the workspace, surfaced
by the pre-merge gate (`cargo fmt --all -- --check && cargo clippy
--workspace --all-targets --keep-going -- -D warnings`).

- Mechanical `cargo fmt --all` (whitespace + line wrapping; no semantic change).
- Mechanical `cargo clippy --fix --workspace --all-targets --keep-going`
  applied auto-suggestions (single_match → if let, unwrap_or_else →
  unwrap_or_default, unused-imports drop).
- One manual fix in `crates/hero_proc_app/src/app.rs:65-72` collapsing
  identical match arms (clippy::if_same_then_else: `services` and the
  fallback both went to `(Page::Services, None)`).

No behavior change. Bundling here so the next commit (FORGE_TOKEN
bootstrap fix) lands on a green workspace.

Signed-off-by: mik-tf

feat(hero_proc_server): make FORGE_TOKEN optional at bootstrap

Tests / test (pull_request) Failing after 3m47s

Details

Build and Test / build (pull_request) Failing after 4m22s

Details

Build Linux / build-linux (push) Successful in 2m45s

Details

745bf0f723

The supervisor must start regardless of whether FORGE_TOKEN is present
in the OS environment. Operations that genuinely need a Forgejo
credential (`secret pull`, `secret push`, `forge merge`-driven service
installs) fail individually at their call sites with their own error
messages.

This unblocks the canonical home#121 onboarding flow on a fresh VM
("mosh in → service_complete") which previously required exporting
FORGE_TOKEN before the very first boot — there was no place to read
it from beforehand because hero_proc_server *is* the secrets store
that holds it.

Changes:
- crates/hero_proc_server/src/main.rs: drop the early hard-fail
  exit(1) on missing FORGE_TOKEN. Replace the always-"set" log line
  with a truthful status string (set / unset (with consequence
  reminder)) emitted after tracing init.
- buildenv.sh: VERSION 0.4.4 → 0.5.0 (workspace was already at 0.5.0;
  this aligns the release tag).

Validated end-to-end on heroci with the patched binary in place and
no FORGE_TOKEN/FORGEJO_TOKEN in env: hero_proc_server boots healthy
and the startup log line correctly states
`forge_token="unset (forge ops will fail until set via env or
\`secret pull\`)"`. With FORGE_TOKEN set, behavior is unchanged.

See decision: D-06 forge-token-bootstrap-optional in the
ai-pipeline workspace.

Refs: lhumina_code/home#225

Signed-off-by: mik-tf