lab service <svc> --install --start fails when service-name binary is kind=cli #259

New issue

Open

opened 2026-05-18 03:12:06 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-18 03:12:06 +00:00

Owner

Surfaced by s110 hero_logic D-10 closure (hero_proc#102 / #105 runbook).

Problem

lab service hero_logic --install --start fails:

  using installed /home/pctwo/hero/bin/hero_logic
  fail hero_logic: '/home/pctwo/hero/bin/hero_logic' is kind = "cli", not a long-running service.
--start only manages kind = server | admin | web.
lab service: 1 of 1 'hero_logic' component(s) failed to start: ["hero_logic"]

This affects every D-10 sweep service that has a CLI binary named identically to the service: hero_slides, hero_books, hero_biz, hero_collab, hero_office, hero_foundry, hero_indexer, hero_logic, and every future sweep that follows the s101+ template.

Workaround that works: invoke per daemon binary:

lab service hero_logic_server --install --start   # ✓ 4/4 smoke pass
lab service hero_logic_admin --install --start    # ✓ 2/2 smoke pass

Expected behavior

Per hero_service_check_fix/SKILL.md:189:

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.

So when given a service name whose primary binary is kind = cli, lab should:

Run <svc-named-bin> --info --json to get the full [[binaries]] manifest.
Iterate the manifest, picking every entry with kind ∈ {server, admin, web}.
Start each as a separate hero_proc action.
Skip kind = cli entries (they're invoked by humans/scripts, not lifecycle-managed).

Current behavior: lab picks the single binary $PATH_ROOT/bin/<svc> and refuses if it's not server/admin/web.

Affected sweeps

Service	s	Binary name	Workaround used at smoke
hero_slides	s101	hero_slides (cli)	per-daemon `lab service hero_slides_server --start`
hero_books	s102	hero_books (cli)	same
hero_biz	s103	hero_biz (cli)	same
hero_collab	s104	hero_collab (cli)	same
hero_office	s105	hero_office (cli)	same
hero_foundry	s107	hero_foundry (cli)	same
hero_indexer	s109	hero_indexer (cli)	same
hero_logic	s110	hero_logic (cli)	same

Same shape across the entire D-10 sweep arc.

Proposed fix

In lab's service <svc> --start resolution logic: when $PATH_ROOT/bin/<svc> is kind = cli, parse its --info --json output, iterate [[binaries]], and start each daemon binary as a separate action. Same --install semantics propagate to each daemon.

Refs: hero_proc#102, hero_proc#105, hero_service_check_fix/SKILL.md.

Surfaced by s110 hero_logic D-10 closure ([hero_proc#102](https://forge.ourworld.tf/lhumina_code/hero_proc/issues/102) / [#105 runbook](https://forge.ourworld.tf/lhumina_code/hero_proc/issues/105)). ## Problem `lab service hero_logic --install --start` fails: ``` using installed /home/pctwo/hero/bin/hero_logic fail hero_logic: '/home/pctwo/hero/bin/hero_logic' is kind = "cli", not a long-running service. --start only manages kind = server | admin | web. lab service: 1 of 1 'hero_logic' component(s) failed to start: ["hero_logic"] ``` This affects **every** D-10 sweep service that has a CLI binary named identically to the service: hero_slides, hero_books, hero_biz, hero_collab, hero_office, hero_foundry, hero_indexer, hero_logic, and every future sweep that follows the s101+ template. Workaround that works: invoke per daemon binary: ```bash lab service hero_logic_server --install --start # ✓ 4/4 smoke pass lab service hero_logic_admin --install --start # ✓ 2/2 smoke pass ``` ## Expected behavior Per `hero_service_check_fix/SKILL.md:189`: > `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. So when given a service name whose primary binary is `kind = cli`, lab should: 1. Run `<svc-named-bin> --info --json` to get the full `[[binaries]]` manifest. 2. Iterate the manifest, picking every entry with `kind ∈ {server, admin, web}`. 3. Start each as a separate hero_proc action. 4. Skip `kind = cli` entries (they're invoked by humans/scripts, not lifecycle-managed). Current behavior: lab picks the single binary `$PATH_ROOT/bin/<svc>` and refuses if it's not server/admin/web. ## Affected sweeps | Service | s | Binary name | Workaround used at smoke | |---|---|---|---| | hero_slides | s101 | hero_slides (cli) | per-daemon `lab service hero_slides_server --start` | | hero_books | s102 | hero_books (cli) | same | | hero_biz | s103 | hero_biz (cli) | same | | hero_collab | s104 | hero_collab (cli) | same | | hero_office | s105 | hero_office (cli) | same | | hero_foundry | s107 | hero_foundry (cli) | same | | hero_indexer | s109 | hero_indexer (cli) | same | | hero_logic | s110 | hero_logic (cli) | same | Same shape across the entire D-10 sweep arc. ## Proposed fix In lab's `service <svc> --start` resolution logic: when `$PATH_ROOT/bin/<svc>` is `kind = cli`, parse its `--info --json` output, iterate `[[binaries]]`, and start each daemon binary as a separate action. Same `--install` semantics propagate to each daemon. Refs: [hero_proc#102](https://forge.ourworld.tf/lhumina_code/hero_proc/issues/102), [hero_proc#105](https://forge.ourworld.tf/lhumina_code/hero_proc/issues/105), `hero_service_check_fix/SKILL.md`.