Add hero_osis selfstart CLI (hero_proc_service_selfstart pattern) #32

New issue

Open

opened 2026-04-21 07:51:55 +00:00 by mahmoud · 0 comments

mahmoud commented

2026-04-21 07:51:55 +00:00

Owner

Problem

This repo does not follow the hero_proc_service_selfstart pattern used by every other Hero service (except hero_office, tracked separately).

A hero_osis binary does exist at crates/hero_osis_server/src/bin/hero_osis.rs, but it is auto-generated by build.rs and is a multi-domain orchestrator — it spawns every OSIS domain server (ai, base, business, calendar, code, communication, embedder, files, finance, flow, identity, job, ledger, media, network, projects, settings) in one tokio runtime. It is a server, not a lifecycle CLI.

As a consequence, tools/modules/services/service_osis.nu in hero_skills has to hand-transcribe the hero_proc action spec rather than delegating to a canonical Rust --start / --stop definition.

Proposed solution

Add a separate selfstart CLI — suggestion: new crate crates/hero_osis_daemon/ producing binary hero_osis_daemon (keeping the existing hero_osis orchestrator binary untouched, since it is used at runtime inside the supervised service).

hero_osis_daemon --start    # register the orchestrator with hero_proc and start it
hero_osis_daemon --stop     # stop and unregister via hero_proc

Alternative naming if preferred: rename hero_osis → hero_osis_orchestrator and free up the hero_osis name for the selfstart CLI. That matches the hero_claude / hero_voice precedent better but requires touching build.rs and downstream references.

Scope

New crate crates/hero_osis_daemon/ (lib-less, one src/main.rs) added to the workspace members list.
[[bin]] name = "hero_osis_daemon" (or hero_osis after rename — operator's call).
Depends on hero_proc_sdk (git, branch development) and clap.
main.rs pattern: identical to hero_voice/crates/hero_voice/src/bin/hero_voice.rs:
- clap struct with --start / --stop flags.
- build_service_definition() that returns a ServiceBuildResult. OSIS is 18 domain servers + 1 admin UI. The action spec should either:
  - register a single hero_osis action that execs the orchestrator binary (simplest), OR
  - register the orchestrator plus the admin UI as two actions (matches the UI/server split used by every other selfstart CLI).
- self_start() / self_stop() → hero_proc_sdk::lifecycle::restart_service / stop_service.
Update buildenv.sh → add hero_osis_daemon (or whatever binary name is chosen) to BINARIES.
Update root Cargo.toml [workspace].members to include the new crate.
Update README.md with the --start/--stop usage block.

Reference exemplars

lhumina_code/hero_voice/crates/hero_voice/src/bin/hero_voice.rs — lean two-action selfstart.
lhumina_code/hero_agent/crates/hero_agent_daemon/src/main.rs — _daemon crate naming precedent.
lhumina_code/hero_claude/crates/hero_claude/src/main.rs — rich action spec with env pass-through.

Downstream effect

Once this lands, tools/modules/services/service_osis.nu in hero_skills can be refactored to a thin delegator, removing the action-spec duplication.

See the hero_proc_service_selfstart skill for the canonical pattern description.

Refs: lhumina_code/hero_skills#75

## Problem This repo does not follow the `hero_proc_service_selfstart` pattern used by every other Hero service (except `hero_office`, tracked separately). A `hero_osis` binary does exist at `crates/hero_osis_server/src/bin/hero_osis.rs`, but it is **auto-generated by `build.rs`** and is a multi-domain orchestrator — it spawns every OSIS domain server (`ai`, `base`, `business`, `calendar`, `code`, `communication`, `embedder`, `files`, `finance`, `flow`, `identity`, `job`, `ledger`, `media`, `network`, `projects`, `settings`) in one tokio runtime. It is a server, not a lifecycle CLI. As a consequence, `tools/modules/services/service_osis.nu` in `hero_skills` has to hand-transcribe the hero_proc action spec rather than delegating to a canonical Rust `--start` / `--stop` definition. ## Proposed solution Add a separate selfstart CLI — suggestion: new crate `crates/hero_osis_daemon/` producing binary `hero_osis_daemon` (keeping the existing `hero_osis` orchestrator binary untouched, since it is used at runtime inside the supervised service). ```bash hero_osis_daemon --start # register the orchestrator with hero_proc and start it hero_osis_daemon --stop # stop and unregister via hero_proc ``` Alternative naming if preferred: rename `hero_osis` → `hero_osis_orchestrator` and free up the `hero_osis` name for the selfstart CLI. That matches the `hero_claude` / `hero_voice` precedent better but requires touching `build.rs` and downstream references. ## Scope - New crate `crates/hero_osis_daemon/` (lib-less, one `src/main.rs`) added to the workspace members list. - `[[bin]] name = "hero_osis_daemon"` (or `hero_osis` after rename — operator's call). - Depends on `hero_proc_sdk` (git, branch `development`) and `clap`. - `main.rs` pattern: identical to `hero_voice/crates/hero_voice/src/bin/hero_voice.rs`: - `clap` struct with `--start` / `--stop` flags. - `build_service_definition()` that returns a `ServiceBuildResult`. OSIS is 18 domain servers + 1 admin UI. The action spec should either: - register a single `hero_osis` action that execs the orchestrator binary (simplest), OR - register the orchestrator plus the admin UI as two actions (matches the UI/server split used by every other selfstart CLI). - `self_start()` / `self_stop()` → `hero_proc_sdk::lifecycle::restart_service` / `stop_service`. - Update `buildenv.sh` → add `hero_osis_daemon` (or whatever binary name is chosen) to `BINARIES`. - Update root `Cargo.toml` `[workspace].members` to include the new crate. - Update `README.md` with the `--start/--stop` usage block. ## Reference exemplars - `lhumina_code/hero_voice/crates/hero_voice/src/bin/hero_voice.rs` — lean two-action selfstart. - `lhumina_code/hero_agent/crates/hero_agent_daemon/src/main.rs` — `_daemon` crate naming precedent. - `lhumina_code/hero_claude/crates/hero_claude/src/main.rs` — rich action spec with env pass-through. ## Downstream effect Once this lands, `tools/modules/services/service_osis.nu` in `hero_skills` can be refactored to a thin delegator, removing the action-spec duplication. See the `hero_proc_service_selfstart` skill for the canonical pattern description. Refs: https://forge.ourworld.tf/lhumina_code/hero_skills/issues/75