lab infocheck: canonical pattern for non-service binaries in lib workspaces (hero_lib, hero_rpc)? #258

New issue

Open

opened 2026-05-17 19:14:03 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-17 19:14:03 +00:00

Owner

Situation

Running lab infocheck across the 35 demo-set repos: 11 clean, 24 with findings (~300 total). Two of the foundational libraries fail for the same surprising reason — they contain helper/demo binaries that aren't real services.

hero_lib — 3 of 4 crates fail (ai_archive, clients, web). These ship a main.rs but are internal helpers, not services. Same situation as the cleanup we filed at hero_lib#139.
hero_rpc — all 5 crates fail (generator, service, petstore_client, petstore_server, recipe_server). Codegen tooling + OpenRPC examples, not services.

Each binary triggers the same 4 findings: missing service.toml, service_base!(), validate_service_toml, handle_info_flag. Combined that's 39 of the ~300 findings — but it's one underlying problem, not 39.

Question

What's the canonical pattern for helper / demo / codegen binaries that live in a lib workspace but aren't services?

Delete the binary targets from Cargo.toml → pure library crates. Cleanest, but loses ergonomic cargo run --bin <demo> usage.
Add minimal service_base!() with kind = "cmdline" + trivial service.toml. Satisfies the contract.
Opt-out metadata — e.g. [package.metadata.lab_builder] skip_info_check = true — so lab infocheck and lab build's --info gate both skip non-service binaries.

Should lab build --repair bootstrap canonical-base wiring on wholesale-shape repos (0/N service_base!() coverage)? A pilot on hero_editor showed --repair doesn't engage on --info-gate failures, only on cargo compile errors. If by design, the path for those repos is manual or lab agent-driven sweep — just confirming.

## Situation Running `lab infocheck` across the 35 demo-set repos: **11 clean, 24 with findings (~300 total).** Two of the foundational libraries fail for the same surprising reason — they contain helper/demo binaries that aren't real services. - **hero_lib** — 3 of 4 crates fail (`ai_archive`, `clients`, `web`). These ship a `main.rs` but are internal helpers, not services. Same situation as the cleanup we filed at [hero_lib#139](https://forge.ourworld.tf/lhumina_code/hero_lib/issues/139). - **hero_rpc** — all 5 crates fail (`generator`, `service`, `petstore_client`, `petstore_server`, `recipe_server`). Codegen tooling + OpenRPC examples, not services. Each binary triggers the same 4 findings: missing `service.toml`, `service_base!()`, `validate_service_toml`, `handle_info_flag`. Combined that's 39 of the ~300 findings — but it's one underlying problem, not 39. ## Question What's the canonical pattern for helper / demo / codegen binaries that live in a lib workspace but aren't services? 1. **Delete the binary targets** from `Cargo.toml` → pure library crates. Cleanest, but loses ergonomic `cargo run --bin <demo>` usage. 2. **Add minimal `service_base!()`** with `kind = "cmdline"` + trivial `service.toml`. Satisfies the contract. 3. **Opt-out metadata** — e.g. `[package.metadata.lab_builder] skip_info_check = true` — so `lab infocheck` and `lab build`'s `--info` gate both skip non-service binaries. ## Related clarification Should `lab build --repair` bootstrap canonical-base wiring on wholesale-shape repos (0/N `service_base!()` coverage)? A pilot on `hero_editor` showed `--repair` doesn't engage on `--info`-gate failures, only on cargo compile errors. If by design, the path for those repos is manual or `lab agent`-driven sweep — just confirming.