hero_service::HeroService::ui() should default to admin.sock (post-s76 _ui→_admin rebrand) #52

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

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

Problem

hero_service::HeroService::ui() defaults to ui.sock (crates/service/src/service.rs:170ServiceKind::Uidefault_socket()"ui.sock"). But the workspace-wide _ui→_admin rebrand (session 76, home#228 + home#229) shifted every admin daemon to bind admin.sock. The defaults are out of sync.

Result: every CLI that uses HeroService::ui("hero_X_admin") either registers an action with ui.sock (which doesn't match the daemon's actual binding — kill_other and health checks miss the real socket) or has to override per-call:

HeroService::ui("hero_logic_admin").socket_name("admin.sock")

Live example: hero_logic ba74b2b crates/hero_logic/src/main.rs:60.

Proposed fix

Three options, in order of preference:

  1. Rename ServiceKind::UiServiceKind::Admin with default admin.sock. Add a ServiceKind::Web if a separate web-kind needs ui.sock semantics for non-admin frontends. Most aligned with service.toml kind enum (server | admin | web | cli).
  2. Change ServiceKind::Ui's default to admin.sock, document the rename history, keep the variant name as-is. Less disruptive — single-line default change.
  3. Add a HeroService::admin(name) constructor that's identical to ui() but defaults to admin.sock. Coexists with ui() (which keeps ui.sock for legacy callers). Most backward-compatible.

I'd lean (2) — minimal disruption, single-line default change, and aligned with workspace convention as of s76.

Affected callers

Any CLI using HeroService::ui(...) without .socket_name(...). Quick grep across workspace:

$ rg "HeroService::ui\(" lhumina_code/ --type rust

Refs: home#228, home#229 (rebrand METAs), hero_proc#102, hero_proc#105.

Surfaced by s110 hero_logic D-10 closure ([hero_proc#102](https://forge.ourworld.tf/lhumina_code/hero_proc/issues/102)). ## Problem `hero_service::HeroService::ui()` defaults to `ui.sock` (`crates/service/src/service.rs:170` — `ServiceKind::Ui` → `default_socket()` → `"ui.sock"`). But the workspace-wide `_ui→_admin` rebrand (session 76, [home#228](https://forge.ourworld.tf/lhumina_code/home/issues/228) + [home#229](https://forge.ourworld.tf/lhumina_code/home/issues/229)) shifted every admin daemon to bind `admin.sock`. The defaults are out of sync. Result: every CLI that uses `HeroService::ui("hero_X_admin")` either registers an action with `ui.sock` (which doesn't match the daemon's actual binding — kill_other and health checks miss the real socket) or has to override per-call: ```rust HeroService::ui("hero_logic_admin").socket_name("admin.sock") ``` Live example: [hero_logic ba74b2b](https://forge.ourworld.tf/lhumina_code/hero_logic/commit/ba74b2b) `crates/hero_logic/src/main.rs:60`. ## Proposed fix Three options, in order of preference: 1. **Rename `ServiceKind::Ui` → `ServiceKind::Admin`** with default `admin.sock`. Add a `ServiceKind::Web` if a separate web-kind needs `ui.sock` semantics for non-admin frontends. Most aligned with `service.toml` kind enum (`server | admin | web | cli`). 2. **Change `ServiceKind::Ui`'s default to `admin.sock`**, document the rename history, keep the variant name as-is. Less disruptive — single-line default change. 3. **Add a `HeroService::admin(name)` constructor** that's identical to `ui()` but defaults to `admin.sock`. Coexists with `ui()` (which keeps `ui.sock` for legacy callers). Most backward-compatible. I'd lean (2) — minimal disruption, single-line default change, and aligned with workspace convention as of s76. ## Affected callers Any CLI using `HeroService::ui(...)` without `.socket_name(...)`. Quick grep across workspace: ``` $ rg "HeroService::ui\(" lhumina_code/ --type rust ``` Refs: [home#228](https://forge.ourworld.tf/lhumina_code/home/issues/228), [home#229](https://forge.ourworld.tf/lhumina_code/home/issues/229) (rebrand METAs), [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).
Sign in to join this conversation.
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_rpc#52
No description provided.