fix: align main with hero_proc/hero_service template — service_base!() macro, git dep, full service.toml #42

Closed
timur wants to merge 0 commits from audit-41 into main
Owner

Summary

Three small fixes uncovered by §1 of #41 (main end-to-end verification against the canonical references).

  • fix(server): use service_base!() macrolab infocheck flagged hero_logic_server as missing the macro; it was hand-rolling the exact constants the macro emits. Diff −17 +2.
  • fix(deps): hero_admin_lib as git dep, not relative path — root Cargo.toml had a relative path dep to a hero_website_framework sibling that doesn't exist in the canonical lab coderoot. cargo metadata failed out of the box. Switched to the git dep both hero_proc and the hero_service template use.
  • fix(service.toml): mirror hero_proc — each per-crate file is the full service — each per-crate service.toml listed only its own binary. hero_proc's pattern (cli/server/admin all carry the same [[binaries]] list, differing only in [service.crate]) is what lab reads from <bin> --info --json. lab service --install worked but --start resolved through the CLI binary and bailed (kind = cli, not a long-running service) because it never saw the server/admin entries. All three files now list the full inventory.

Test plan

  • cargo build --workspace — clean
  • cargo metadata from canonical coderoot at ~/hero/code/hero_logic — clean (was failing on missing hero_website_framework sibling)
  • lab infocheck3 crate(s) clean, 0 finding(s) total (was 1 finding before)
  • lab service hero_logic --install — clean install, all three binaries report binaries=3 [cli, server, admin] from --info --json (was failing every --info check before)
  • Manual server+admin smoke tests with sockets bound — /health, /openrpc.json (57 methods), /.well-known/heroservice.json all pass on rpc.sock and admin.sock
  • lab service hero_logic --start — still bails (out of scope: needs an entry in hero_skills/crates/lab/src/service/service_manager.rs::SERVICE_MAP; see #41 §1 comment)
  • system.ping JSON-RPC — still 404s (out of scope: hero_rpc_server doesn't register system.* builtins; only hero_rpc2 does)

Closes part of #41 §1.

## Summary Three small fixes uncovered by §1 of #41 (`main` end-to-end verification against the canonical references). - **`fix(server): use service_base!() macro`** — `lab infocheck` flagged `hero_logic_server` as missing the macro; it was hand-rolling the exact constants the macro emits. Diff −17 +2. - **`fix(deps): hero_admin_lib as git dep, not relative path`** — root `Cargo.toml` had a relative path dep to a hero_website_framework sibling that doesn't exist in the canonical lab coderoot. `cargo metadata` failed out of the box. Switched to the git dep both `hero_proc` and the `hero_service` template use. - **`fix(service.toml): mirror hero_proc — each per-crate file is the full service`** — each per-crate `service.toml` listed only its own binary. `hero_proc`'s pattern (cli/server/admin all carry the same `[[binaries]]` list, differing only in `[service.crate]`) is what `lab` reads from `<bin> --info --json`. `lab service --install` worked but `--start` resolved through the CLI binary and bailed (`kind = cli, not a long-running service`) because it never saw the server/admin entries. All three files now list the full inventory. ## Test plan - [x] `cargo build --workspace` — clean - [x] `cargo metadata` from canonical coderoot at `~/hero/code/hero_logic` — clean (was failing on missing `hero_website_framework` sibling) - [x] `lab infocheck` — `3 crate(s) clean, 0 finding(s) total` (was 1 finding before) - [x] `lab service hero_logic --install` — clean install, all three binaries report `binaries=3 [cli, server, admin]` from `--info --json` (was failing every `--info` check before) - [x] Manual server+admin smoke tests with sockets bound — `/health`, `/openrpc.json` (57 methods), `/.well-known/heroservice.json` all pass on rpc.sock and admin.sock - [ ] `lab service hero_logic --start` — still bails (out of scope: needs an entry in `hero_skills/crates/lab/src/service/service_manager.rs::SERVICE_MAP`; see #41 §1 comment) - [ ] `system.ping` JSON-RPC — still 404s (out of scope: `hero_rpc_server` doesn't register `system.*` builtins; only `hero_rpc2` does) Closes part of #41 §1.
`lab infocheck` flagged hero_logic_server as missing the `service_base!()`
call. The binary was hand-rolling the SERVICE_TOML + BUILD_NR consts the
macro emits — same code, but the canonical wiring requires the macro so
that `lab infocheck` and downstream tooling can rely on it being present.

Drops the hand-rolled consts (kept the BUILD_NR option_env! shape
identical to what the macro emits), imports `herolib_core::service_base`,
calls `service_base!();` at module scope. hero_logic + hero_logic_admin
already used the macro; only the server crate was out of step.

Verified: cargo build -p hero_logic_server clean (1 unrelated dead-code
warning preserved), lab infocheck — 3/3 crates clean, 0 findings.

Refs hero_logic#41 §1.
The path dep `hero_admin_lib = { path = "../hero_website_framework/crates/hero_admin_lib" }`
required a hero_website_framework sibling beside hero_logic. Out-of-box
`cargo metadata` (and therefore `lab infocheck`/`lab service --install`)
failed in the canonical lab coderoot at `~/hero/code/` because the
sibling isn't cloned there — only services lab manages directly.

Switch to the git dep pattern hero_proc and the hero_service template
both use:

    hero_admin_lib = { git = "https://forge.ourworld.tf/lhumina_code/hero_website_framework.git", branch = "development" }

Builds clean (4.7s incremental), preserves the same hero_admin_lib
surface, and lets `cargo metadata` succeed without a hand-cloned
sibling.

Refs hero_logic#41 §1 + §2 (hero_proc + hero_service alignment).
hero_proc's per-crate service.toml files each declare the WHOLE service:
every binary the service ships (cli + server + admin) is listed in every
file, with the only difference being the [service.crate] field marking
which crate owns each file. hero_logic was diverging: each per-crate
service.toml listed only its own binary.

Consequence: `lab service hero_logic --start` resolves through the CLI
binary's `--info --json` to find what to start. With only `kind = "cli"`
in the embedded service.toml, lab refuses (correctly) since cli isn't a
long-running kind, and never sees the server or admin binaries at all.

Bring all three files in line with hero_proc's pattern — each crate's
service.toml now lists cli + server + admin with their sockets. The
top-level [service.crate] still identifies which crate owns the file.

Also normalize the admin crate's service.display/description back to
the canonical "Hero Logic" / "DAG control flow engine" copy from the
server (the admin had drifted to its own wording, but per hero_proc
the [service] block describes the SERVICE, not the crate).

Verified: cargo build clean (2.0s incremental), lab infocheck — 3/3
crates clean, 0 findings.

Refs hero_logic#41 §1 + §2.
timur closed this pull request 2026-05-20 05:52:59 +00:00
Author
Owner

Closed without merge button — branch was fast-forwarded directly onto main per request (no PR review needed for these three alignment fixes). All commits now at 6499aac on main.

Closed without merge button — branch was fast-forwarded directly onto `main` per request (no PR review needed for these three alignment fixes). All commits now at `6499aac` on `main`.

Pull request closed

Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
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/hero_logic!42
No description provided.