lab service <service-name> --start only starts one binary, not every kind=server|admin|web #254

New issue

Open

opened 2026-05-15 19:43:11 +00:00 by mik-tf · 1 comment

mik-tf commented

2026-05-15 19:43:11 +00:00

Owner

Observed (session 95 / hero_code sweep, lab build #50469 + #54726)

The hero_service_check_fix SKILL §6 claims:

lab service … --start reads each binary's service.toml (via <bin> --info --json) and starts every kind = "server" | "admin" | "web" binary directly — no subcommand, no wrapper script.

Empirically lab service <service-name> --install --start only starts ONE binary — the server matching the service name. Verified end-to-end on hero_code after its service.toml manifests were unified to the canonical pattern (each crate lists all 3 binaries: cli + server + admin):

$ lab service hero_code --install --start
  starting hero_code_server …
  hero_code_server is running
  smoke tests: 6 passed

hero_code_admin is NOT started, despite kind = "admin" being declared in service.toml. To start it I had to invoke lab service hero_code_admin --start separately:

$ lab service hero_code_admin --start
  starting hero_code_admin …
  hero_code_admin is running
  smoke tests: 2 passed

After both: hero_proc service list showed both hero_code_server and hero_code_admin registered + running.

Either / or

Either (a) update lab to iterate every kind=server|admin|web binary in the resolved service.toml, or (b) update the hero_service_check_fix SKILL §6 to reflect the per-binary invocation pattern that's actually implemented.

This will be hit by every multi-binary service the sweep touches (most of T1 + T2).

Refs: lhumina_code/hero_proc#102 (sweep tracker), lhumina_code/hero_code#15 (first repo where this surfaced).

## Observed (session 95 / hero_code sweep, lab build #50469 + #54726) The `hero_service_check_fix` SKILL §6 claims: > `lab service … --start` reads each binary's `service.toml` (via `<bin> --info --json`) and starts every `kind = "server" | "admin" | "web"` binary directly — no subcommand, no wrapper script. Empirically `lab service <service-name> --install --start` only starts ONE binary — the server matching the service name. Verified end-to-end on `hero_code` after its service.toml manifests were unified to the canonical pattern (each crate lists all 3 binaries: cli + server + admin): ``` $ lab service hero_code --install --start starting hero_code_server … hero_code_server is running smoke tests: 6 passed ``` `hero_code_admin` is NOT started, despite `kind = "admin"` being declared in service.toml. To start it I had to invoke `lab service hero_code_admin --start` separately: ``` $ lab service hero_code_admin --start starting hero_code_admin … hero_code_admin is running smoke tests: 2 passed ``` After both: `hero_proc service list` showed both `hero_code_server` and `hero_code_admin` registered + running. ## Either / or Either (a) update lab to iterate every `kind=server|admin|web` binary in the resolved service.toml, **or** (b) update the `hero_service_check_fix` SKILL §6 to reflect the per-binary invocation pattern that's actually implemented. This will be hit by every multi-binary service the sweep touches (most of T1 + T2). Refs: https://forge.ourworld.tf/lhumina_code/hero_proc/issues/102 (sweep tracker), https://forge.ourworld.tf/lhumina_code/hero_code/pulls/15 (first repo where this surfaced).

mik-tf referenced this issue from lhumina_code/hero_proc

2026-05-15 19:47:44 +00:00

finish building & service files #102

mik-tf referenced this issue from lhumina_code/hero_code

2026-05-15 19:55:42 +00:00

fix(service.toml): unify per-crate manifests to list all hero_code binaries #15

mik-tf referenced this issue from a commit

2026-05-15 20:03:54 +00:00

fix(lab/service): close 3 sweep-blocking lab service bugs

mik-tf referenced this issue

2026-05-15 20:04:16 +00:00

fix(lab/service): close 3 sweep-blocking lab service bugs (#254/#255/#256) #257

mik-tf commented

2026-05-15 20:04:52 +00:00

Author

Owner

Fix in PR #257 — awaiting squash-merge gate.

Verified under lab build #54729 during testing on the hero_proc#102 sweep:

lab service hero_code --start now starts both server and admin via a single invocation (8/8 smoke checks).
start_hero_proc no longer destroys a live hero_proc socket on false-negative liveness probe.
Missing screen fails fast with a clear pointer to lab install base BEFORE any state cleanup.

Fix in [PR #257](https://forge.ourworld.tf/lhumina_code/hero_skills/pulls/257) — awaiting squash-merge gate. Verified under lab build #54729 during testing on the hero_proc#102 sweep: - `lab service hero_code --start` now starts both server and admin via a single invocation (8/8 smoke checks). - `start_hero_proc` no longer destroys a live hero_proc socket on false-negative liveness probe. - Missing `screen` fails fast with a clear pointer to `lab install base` BEFORE any state cleanup.

mik-tf referenced this issue from a commit

2026-05-15 20:47:20 +00:00

fix(lab/service): close 3 sweep-blocking lab service bugs (#254/#255/#256) (#257)

mik-tf referenced this issue from lhumina_code/hero_proc

2026-05-15 20:51:19 +00:00

finish building & service files #102

~~mik-tf referenced this issue from lhumina_code/hero_demo 2026-05-16 00:33:48 +00:00~~

[vision] Hero OS as an ambient AI desktop — sovereign, voice-native, multi-context #52

mik-tf referenced this issue from lhumina_code/hero_proc

2026-05-16 01:37:26 +00:00

chore(hero_proc): D-10 sweep — canonical service.toml + cargo update + dep audit #103