lhumina_code/home
22
0
Fork 0
Code Issues 8 Pull requests Projects Releases Packages Wiki Activity Actions

fix 4 core services as needed by hero_rpc #6

New issue
Open
opened 2026-03-09 10:02:38 +00:00 by despiegk · 5 comments
despiegk commented 2026-03-09 10:02:38 +00:00
Owner
Copy link

Meeting Minutes

Topic: HERO Services Architecture – OpenRPC Standardization
Participants: Kristof (Speaker 1), Timur (Speaker 2)
Date: Not specified (transcribed meeting)

1. Objective

The meeting focused on simplifying and standardizing the architecture of core AI and data services within the HERO ecosystem.

Key goals:

  • Standardize services around OpenRPC
  • Remove scattered AI clients from the codebase
  • Introduce a clean service architecture
  • Enable generated services to easily use AI and data primitives

This will reduce complexity and make the platform easier to extend and maintain.

2. Core Services to Implement

Four core services will form the base infrastructure layer.

Core Services

  1. AI Broker
  2. Embedder
  3. Indexer
  4. Redis

Clarifications:

  • Redis provides the data reading layer for retrieval and indexing.
  • All services must communicate only through OpenRPC.
  • These services provide the core data intelligence primitives.

Together they enable:

  • AI model access and usage management
  • embedding generation
  • vector indexing
  • fast data retrieval

These primitives are sufficient to support agentic data workflows.

3. Strict OpenRPC Compliance

All four services must:

  • Use OpenRPC exclusively
  • Follow the Hero RPC server SDK standards
  • Expose clean RPC APIs
  • Avoid embedding service logic outside RPC handlers

This ensures:

  • consistent interfaces
  • easier service generation
  • cleaner architecture

4. Initialization and Runtime (zinit)

The initialization mechanism mentioned in the meeting refers to zinit, which will act as the runtime service manager.

Responsibilities of zinit:

  • service startup
  • environment variables
  • logging configuration
  • secrets management

Conceptual structure:

zinit
 ├── AI Broker
 ├── Embedder
 ├── Indexer
 └── Redis

All services should:

  • start via zinit
  • read configuration from environment variables
  • log through a unified logging system.

5. Service Startup Model

Instead of fragile scripts or Makefiles, services should self-start through the server binary.

Example:

server start

This command should automatically:

  1. Initialize environment variables
  2. Setup logging
  3. Register OpenRPC service definitions
  4. Start the service

For now, this may run inside screen sessions or similar simple runtime environments.
Later this will integrate with Hero OS service orchestration.

6. SDK Improvements

The SDK should provide helper utilities to simplify service development.

Possible additions:

  • service startup helpers
  • logging integration
  • simplified RPC client initialization
  • configuration helpers

This will reduce repeated code across services while maintaining strict architecture.

7. Service Dependency Model

zinit
 ├── AI Broker
 ├── Embedder
 ├── Indexer
 └── Redis

Dependencies:

  • Embedder uses AI Broker to generate embeddings
  • Indexer uses Embedder for vector generation
  • Redis provides storage and retrieval

All communication happens via OpenRPC calls.

8. Future Integration with Hero RPC

Once these four services are implemented and stable, Hero RPC will integrate them.

Generated OpenRPC services will automatically gain access to:

  • AI model execution
  • embedding generation
  • indexing
  • data retrieval

Architecture concept:

Generated Service
        │
        ▼
      Hero RPC
        │
        ▼
AI Broker / Embedder / Indexer / Redis

This enables agentic functionality directly in generated services.

9. Development Branch Strategy

All development should be done in dedicated branches.

Suggested branch names:

  • ai-broker
  • embedder
  • indexer
  • redis

Each service should follow the same schema structure and OpenRPC generation approach.

10. Immediate Action Items

Core Implementation

  • Implement AI Broker with OpenRPC
  • Implement Embedder
  • Implement Indexer
  • Implement Redis integration service

Standardization

  • Remove scattered AI clients
  • Ensure all interactions go through OpenRPC

SDK Work

  • Add initialization helpers
  • Integrate logging
  • Add service startup utilities

Infrastructure

  • Integrate services with zinit
  • Ensure clean startup behavior
## Meeting Minutes **Topic:** HERO Services Architecture – OpenRPC Standardization **Participants:** Kristof (Speaker 1), Timur (Speaker 2) **Date:** Not specified (transcribed meeting) --- # 1. Objective The meeting focused on **simplifying and standardizing the architecture of core AI and data services** within the HERO ecosystem. Key goals: * Standardize services around **OpenRPC** * Remove scattered AI clients from the codebase * Introduce a **clean service architecture** * Enable generated services to easily use **AI and data primitives** This will reduce complexity and make the platform easier to extend and maintain. --- # 2. Core Services to Implement Four core services will form the **base infrastructure layer**. ### Core Services 1. **AI Broker** 2. **Embedder** 3. **Indexer** 4. **Redis** Clarifications: * **Redis provides the data reading layer** for retrieval and indexing. * All services must communicate **only through OpenRPC**. * These services provide the **core data intelligence primitives**. Together they enable: * AI model access and usage management * embedding generation * vector indexing * fast data retrieval These primitives are sufficient to support **agentic data workflows**. --- # 3. Strict OpenRPC Compliance All four services must: * Use **OpenRPC exclusively** * Follow the **Hero RPC server SDK standards** * Expose clean **RPC APIs** * Avoid embedding service logic outside RPC handlers This ensures: * consistent interfaces * easier service generation * cleaner architecture --- # 4. Initialization and Runtime (`zinit`) The initialization mechanism mentioned in the meeting refers to **zinit**, which will act as the **runtime service manager**. Responsibilities of `zinit`: * service startup * environment variables * logging configuration * secrets management Conceptual structure: ``` zinit ├── AI Broker ├── Embedder ├── Indexer └── Redis ``` All services should: * start via **zinit** * read configuration from environment variables * log through a unified logging system. --- # 5. Service Startup Model Instead of fragile scripts or Makefiles, services should **self-start through the server binary**. Example: ``` server start ``` This command should automatically: 1. Initialize environment variables 2. Setup logging 3. Register OpenRPC service definitions 4. Start the service For now, this may run inside **screen sessions** or similar simple runtime environments. Later this will integrate with **Hero OS service orchestration**. --- # 6. SDK Improvements The SDK should provide helper utilities to simplify service development. Possible additions: * service startup helpers * logging integration * simplified RPC client initialization * configuration helpers This will reduce repeated code across services while maintaining strict architecture. --- # 7. Service Dependency Model ``` zinit ├── AI Broker ├── Embedder ├── Indexer └── Redis ``` Dependencies: * **Embedder uses AI Broker** to generate embeddings * **Indexer uses Embedder** for vector generation * **Redis provides storage and retrieval** All communication happens via **OpenRPC calls**. --- # 8. Future Integration with Hero RPC Once these four services are implemented and stable, **Hero RPC** will integrate them. Generated OpenRPC services will automatically gain access to: * AI model execution * embedding generation * indexing * data retrieval Architecture concept: ``` Generated Service │ ▼ Hero RPC │ ▼ AI Broker / Embedder / Indexer / Redis ``` This enables **agentic functionality** directly in generated services. --- # 9. Development Branch Strategy All development should be done in dedicated branches. Suggested branch names: * `ai-broker` * `embedder` * `indexer` * `redis` Each service should follow the **same schema structure and OpenRPC generation approach**. --- # 10. Immediate Action Items ### Core Implementation * Implement **AI Broker** with OpenRPC * Implement **Embedder** * Implement **Indexer** * Implement **Redis integration service** ### Standardization * Remove scattered AI clients * Ensure all interactions go through **OpenRPC** ### SDK Work * Add initialization helpers * Integrate logging * Add service startup utilities ### Infrastructure * Integrate services with **zinit** * Ensure clean startup behavior
despiegk added this to the ACTIVE project 2026-03-09 10:02:46 +00:00
timur commented 2026-03-09 15:18:35 +00:00
Owner
Copy link

Implementation Plan: Zinit Lifecycle Migration for 4 Core Services

Context

Per hero_rpc#7, OServer::run_cli() now provides standardized CLI subcommands (start/stop/run/status/logs/ui/zinit) with zinit lifecycle management via ZinitLifecycle (Pattern B — ZinitRPCAPIClient). The 4 core services need to adopt this same CLI pattern.

Current State

Service Binary Current Zinit Current CLI
hero_aibroker hero_aibroker_openrpc None --bind <socket>
hero_embedder hero_embedder_server Pattern A (ZinitHandle + ServiceConfigBuilder) --start flag
hero_index_server hero_indexer_server Makefile zinit add-service --dir, --socket
hero_redis hero_redis_server Makefile zinit add-service --socket, --data-dir, --port, etc.

Migration Approach

These services use custom RPC implementations (not OSIS), so they can't use OServer::run_cli() directly. Instead, each service will:

  1. Add zinit_sdk (from geomind_code/zinit, development_kristof branch) and clap dependencies
  2. Implement the same CLI subcommand pattern as ServerCli/ServerCommand from hero_rpc
  3. Use ZinitLifecycle-equivalent code for start/stop/status/logs/ui/zinit subcommands
  4. Move existing server logic under the run subcommand with service-specific args

Per-Service Plan

1. hero_aibroker (hero_aibroker_openrpc)

  • Wrap current main() into run_server() under run subcommand
  • run accepts --bind <socket> (existing arg)
  • start registers with zinit, exec = <binary> run
  • No old zinit code to remove

2. hero_embedder (hero_embedder_server)

  • Replace old zinit = { version = "0.3.9" } with zinit_sdk
  • Remove --start flag + ZinitHandle/ServiceConfigBuilder code
  • Add standard CLI subcommands
  • run subcommand calls existing run_server()
  • start uses ZinitLifecycle Pattern B

3. hero_index_server (hero_indexer_server)

  • Add zinit_sdk dependency
  • Add standard CLI subcommands with --dir and --socket under run
  • Remove Makefile zinit management

4. hero_redis (hero_redis_server)

  • Add zinit_sdk dependency
  • Add standard CLI subcommands with all existing args under run
  • Handle multi-protocol correctly (RESP2 + JSON-RPC both start in run)
  • start passes relevant args to zinit exec command

CLI Pattern (Same for All)

<service> start          # Register with zinit + start
<service> stop           # Stop via zinit
<service> run [--args]   # Run directly (development mode)
<service> status         # Query zinit status
<service> logs [-n 100]  # Fetch zinit logs
<service> ui             # Open admin UI
<service> zinit          # Open zinit web UI

Dependencies

zinit_sdk = { git = "https://forge.ourworld.tf/geomind_code/zinit.git", branch = "development_kristof" }
clap = { version = "4.5", features = ["derive", "env"] }
open = "5"

Reference

  • hero_rpc#7: OServer::run_cli() implementation
  • hero_rpc crates/server/src/server/lifecycle.rs: ZinitLifecycle reference
  • hero_os#12: Already migrated to this pattern
## Implementation Plan: Zinit Lifecycle Migration for 4 Core Services ### Context Per hero_rpc#7, `OServer::run_cli()` now provides standardized CLI subcommands (`start/stop/run/status/logs/ui/zinit`) with zinit lifecycle management via `ZinitLifecycle` (Pattern B — `ZinitRPCAPIClient`). The 4 core services need to adopt this same CLI pattern. ### Current State | Service | Binary | Current Zinit | Current CLI | |---------|--------|---------------|-------------| | **hero_aibroker** | `hero_aibroker_openrpc` | None | `--bind <socket>` | | **hero_embedder** | `hero_embedder_server` | Pattern A (`ZinitHandle` + `ServiceConfigBuilder`) | `--start` flag | | **hero_index_server** | `hero_indexer_server` | Makefile `zinit add-service` | `--dir`, `--socket` | | **hero_redis** | `hero_redis_server` | Makefile `zinit add-service` | `--socket`, `--data-dir`, `--port`, etc. | ### Migration Approach These services use custom RPC implementations (not OSIS), so they can't use `OServer::run_cli()` directly. Instead, each service will: 1. Add `zinit_sdk` (from `geomind_code/zinit`, `development_kristof` branch) and `clap` dependencies 2. Implement the **same CLI subcommand pattern** as `ServerCli`/`ServerCommand` from hero_rpc 3. Use `ZinitLifecycle`-equivalent code for `start/stop/status/logs/ui/zinit` subcommands 4. Move existing server logic under the `run` subcommand with service-specific args ### Per-Service Plan #### 1. hero_aibroker (`hero_aibroker_openrpc`) - Wrap current `main()` into `run_server()` under `run` subcommand - `run` accepts `--bind <socket>` (existing arg) - `start` registers with zinit, exec = `<binary> run` - No old zinit code to remove #### 2. hero_embedder (`hero_embedder_server`) - Replace old `zinit = { version = "0.3.9" }` with `zinit_sdk` - Remove `--start` flag + `ZinitHandle`/`ServiceConfigBuilder` code - Add standard CLI subcommands - `run` subcommand calls existing `run_server()` - `start` uses `ZinitLifecycle` Pattern B #### 3. hero_index_server (`hero_indexer_server`) - Add `zinit_sdk` dependency - Add standard CLI subcommands with `--dir` and `--socket` under `run` - Remove Makefile zinit management #### 4. hero_redis (`hero_redis_server`) - Add `zinit_sdk` dependency - Add standard CLI subcommands with all existing args under `run` - Handle multi-protocol correctly (RESP2 + JSON-RPC both start in `run`) - `start` passes relevant args to zinit exec command ### CLI Pattern (Same for All) ``` <service> start # Register with zinit + start <service> stop # Stop via zinit <service> run [--args] # Run directly (development mode) <service> status # Query zinit status <service> logs [-n 100] # Fetch zinit logs <service> ui # Open admin UI <service> zinit # Open zinit web UI ``` ### Dependencies ```toml zinit_sdk = { git = "https://forge.ourworld.tf/geomind_code/zinit.git", branch = "development_kristof" } clap = { version = "4.5", features = ["derive", "env"] } open = "5" ``` ### Reference - hero_rpc#7: `OServer::run_cli()` implementation - hero_rpc `crates/server/src/server/lifecycle.rs`: `ZinitLifecycle` reference - hero_os#12: Already migrated to this pattern
timur commented 2026-03-09 15:34:36 +00:00
Owner
Copy link

Verification: Zinit Lifecycle Migration Complete

All 4 core services have been migrated to the standardized zinit lifecycle CLI pattern (Pattern B — ZinitRPCAPIClient).

Changes Pushed

Repo Branch Commit Binary
hero_aibroker development_standardize 0c273a0 hero_aibroker_openrpc
hero_embedder development 144af04 hero_embedder_server
hero_index_server development c33d249 hero_indexer_server
hero_redis development 464b33e hero_redis_server

Build Verification

All 4 services compile clean (cargo check passes with zero errors):

hero_aibroker_openrpc  — 1 warning (unused run_args API surface)
hero_embedder_server   — 1 warning (unused run_args API surface)
hero_indexer_server    — 1 warning (unused run_args API surface)
hero_redis_server      — 1 warning (unused run_args API surface)

CLI Verification

All 4 services show identical CLI interface:

Usage: <service> <COMMAND>

Commands:
  start   Register with zinit and start as a managed service
  stop    Stop the zinit-managed service
  run     Run the server directly (development mode, no zinit)
  status  Show service status from zinit
  logs    Show service logs from zinit
  ui      Open the service's admin UI in the browser
  zinit   Open the zinit web UI for this service

What Changed

  • hero_aibroker: Added zinit_sdk dep + lifecycle module. Old --bind arg moved under run subcommand.
  • hero_embedder: Replaced zinit = 0.3.9 (Pattern A, ZinitHandle) with zinit_sdk (Pattern B). Removed --start flag, added 7 subcommands.
  • hero_index_server: Added zinit_sdk dep + lifecycle module. Old --dir/--socket args moved under run subcommand.
  • hero_redis: Added zinit_sdk dep + lifecycle module. All existing args (--socket, --data-dir, --port, --encryption-key, --admin-pubkey, --admin-secret, --verbose) preserved under run subcommand. Multi-protocol (RESP2 + JSON-RPC) unchanged.

Pattern Used

Each service has:

  1. lifecycle.rs — Self-contained ZinitLifecycle struct using ZinitRPCAPIClient
  2. CLI subcommands — Clap-based Cli/Command matching the ServerCli/ServerCommand pattern from hero_rpc_server
  3. run subcommand — Contains all existing server logic
  4. start/stop/status/logs — Delegated to ZinitLifecycle

Makefile Note

Existing Makefile targets (make run, etc.) still work but should be updated to use the new CLI pattern:

  • make run → <service> run (dev mode)
  • make service → <service> start (zinit-managed)
  • make stop → <service> stop
## Verification: Zinit Lifecycle Migration Complete All 4 core services have been migrated to the standardized zinit lifecycle CLI pattern (Pattern B — `ZinitRPCAPIClient`). ### Changes Pushed | Repo | Branch | Commit | Binary | |------|--------|--------|--------| | **hero_aibroker** | `development_standardize` | `0c273a0` | `hero_aibroker_openrpc` | | **hero_embedder** | `development` | `144af04` | `hero_embedder_server` | | **hero_index_server** | `development` | `c33d249` | `hero_indexer_server` | | **hero_redis** | `development` | `464b33e` | `hero_redis_server` | ### Build Verification All 4 services compile clean (`cargo check` passes with zero errors): ``` hero_aibroker_openrpc — 1 warning (unused run_args API surface) hero_embedder_server — 1 warning (unused run_args API surface) hero_indexer_server — 1 warning (unused run_args API surface) hero_redis_server — 1 warning (unused run_args API surface) ``` ### CLI Verification All 4 services show identical CLI interface: ``` Usage: <service> <COMMAND> Commands: start Register with zinit and start as a managed service stop Stop the zinit-managed service run Run the server directly (development mode, no zinit) status Show service status from zinit logs Show service logs from zinit ui Open the service's admin UI in the browser zinit Open the zinit web UI for this service ``` ### What Changed - **hero_aibroker**: Added `zinit_sdk` dep + lifecycle module. Old `--bind` arg moved under `run` subcommand. - **hero_embedder**: Replaced `zinit = 0.3.9` (Pattern A, `ZinitHandle`) with `zinit_sdk` (Pattern B). Removed `--start` flag, added 7 subcommands. - **hero_index_server**: Added `zinit_sdk` dep + lifecycle module. Old `--dir`/`--socket` args moved under `run` subcommand. - **hero_redis**: Added `zinit_sdk` dep + lifecycle module. All existing args (`--socket`, `--data-dir`, `--port`, `--encryption-key`, `--admin-pubkey`, `--admin-secret`, `--verbose`) preserved under `run` subcommand. Multi-protocol (RESP2 + JSON-RPC) unchanged. ### Pattern Used Each service has: 1. `lifecycle.rs` — Self-contained `ZinitLifecycle` struct using `ZinitRPCAPIClient` 2. CLI subcommands — Clap-based `Cli`/`Command` matching the `ServerCli`/`ServerCommand` pattern from `hero_rpc_server` 3. `run` subcommand — Contains all existing server logic 4. `start/stop/status/logs` — Delegated to `ZinitLifecycle` ### Makefile Note Existing Makefile targets (`make run`, etc.) still work but should be updated to use the new CLI pattern: - `make run` → `<service> run` (dev mode) - `make service` → `<service> start` (zinit-managed) - `make stop` → `<service> stop`
timur commented 2026-03-10 07:41:47 +00:00
Owner
Copy link

Best practice established: zinit-only lifecycle for all Hero binaries

After implementing this in hero_os, we've converged on these conventions that should apply to all repos adopting zinit lifecycle:

1. No standalone/direct mode

All server binaries run exclusively through zinit. The run subcommand exists only as the internal entry point that zinit invokes — developers never call it directly.

2. cargo update before start

make start must run cargo update first to pick up latest git dependency changes (e.g. hero_rpc fixes). This prevents stale dependency bugs.

3. make run = start + stream logs + stop on Ctrl-C

For developer experience, make run should:

  • Start services via zinit
  • Stream logs in the foreground
  • On Ctrl-C, stop the zinit services and exit

This gives devs the feel of running directly while getting zinit's process management.

4. HTTP/UI crates also use ZinitLifecycle

Not just OpenRPC servers — the HTTP static-file server (hero_os_ui) also uses ZinitLifecycle from hero_rpc_server. Any binary that should be supervised gets the same treatment.

5. Makefile pattern

start: update build  ## Start via zinit (background)
	cargo run -p my_server -- start

run: start  ## Start + stream logs (Ctrl-C stops)
	@trap 'cargo run -p my_server -- stop' INT TERM; \
	while true; do cargo run -p my_server -- logs -n 10; sleep 2; done

stop:  ## Stop zinit services
	cargo run -p my_server -- stop

Implemented in hero_os (hero_os#12) and hero_rpc#7. Apply same pattern to AI Broker, Embedder, Indexer, Redis services.

## Best practice established: zinit-only lifecycle for all Hero binaries After implementing this in hero_os, we've converged on these conventions that should apply to all repos adopting zinit lifecycle: ### 1. No standalone/direct mode All server binaries run exclusively through zinit. The `run` subcommand exists only as the internal entry point that zinit invokes — developers never call it directly. ### 2. `cargo update` before `start` `make start` must run `cargo update` first to pick up latest git dependency changes (e.g. hero_rpc fixes). This prevents stale dependency bugs. ### 3. `make run` = start + stream logs + stop on Ctrl-C For developer experience, `make run` should: - Start services via zinit - Stream logs in the foreground - On Ctrl-C, stop the zinit services and exit This gives devs the feel of running directly while getting zinit's process management. ### 4. HTTP/UI crates also use ZinitLifecycle Not just OpenRPC servers — the HTTP static-file server (`hero_os_ui`) also uses `ZinitLifecycle` from `hero_rpc_server`. Any binary that should be supervised gets the same treatment. ### 5. Makefile pattern ```makefile start: update build ## Start via zinit (background) cargo run -p my_server -- start run: start ## Start + stream logs (Ctrl-C stops) @trap 'cargo run -p my_server -- stop' INT TERM; \ while true; do cargo run -p my_server -- logs -n 10; sleep 2; done stop: ## Stop zinit services cargo run -p my_server -- stop ``` Implemented in hero_os (hero_os#12) and hero_rpc#7. Apply same pattern to AI Broker, Embedder, Indexer, Redis services.
timur commented 2026-03-10 08:25:44 +00:00
Owner
Copy link

Zinit Lifecycle Convention Standardized

The CLI subcommand naming for all hero_rpc-based servers is now finalized:

Command Purpose
run Developer command — start via zinit + stream logs + stop on Ctrl-C
start Start via zinit in the background
stop Stop the zinit-managed service
serve Internal — what zinit invokes to run the process (never call manually)
status / logs Query zinit

For OpenRPC servers (OServer pattern)

Use OServer::run_cli() — handles all subcommands automatically. The run_fn callback is only invoked for serve.

For non-OpenRPC servers (e.g. HTTP/UI servers)

Use ZinitLifecycle directly with your own clap CLI:

match cli.command {
    Command::Run => lifecycle.run().await,
    Command::Start => lifecycle.start().await,
    Command::Stop => lifecycle.stop().await,
    Command::Status => lifecycle.status().await,
    Command::Logs { lines } => lifecycle.logs(lines).await,
    Command::Serve { .. } => run_my_server(..).await,  // actual server code
}

Makefile best practice

run: update build  ## Developer command — start + stream logs
	cargo run -p my_server -- run

start: update build  ## Background start
	cargo run -p my_server -- start

No Makefile-level log polling — ZinitLifecycle::run() handles everything.

Applied in

  • hero_rpc (9d338ad) — core implementation
  • hero_os (4fa4073) — both hero_os_server (OpenRPC) and hero_os_ui (HTTP, uses ZinitLifecycle directly)
  • hero_skills — lifecycle skill updated

Action for other repos

Any repo with a hero_rpc-generated server should adopt this convention:

  1. Update to latest hero_rpc (cargo update)
  2. If the repo has an HTTP/UI binary, add ZinitLifecycle with the Run/Serve pattern shown above
  3. Update Makefile to delegate to CLI subcommands
## Zinit Lifecycle Convention Standardized The CLI subcommand naming for all hero_rpc-based servers is now finalized: | Command | Purpose | |---------|---------| | `run` | **Developer command** — start via zinit + stream logs + stop on Ctrl-C | | `start` | Start via zinit in the background | | `stop` | Stop the zinit-managed service | | `serve` | **Internal** — what zinit invokes to run the process (never call manually) | | `status` / `logs` | Query zinit | ### For OpenRPC servers (OServer pattern) Use `OServer::run_cli()` — handles all subcommands automatically. The `run_fn` callback is only invoked for `serve`. ### For non-OpenRPC servers (e.g. HTTP/UI servers) Use `ZinitLifecycle` directly with your own clap CLI: ```rust match cli.command { Command::Run => lifecycle.run().await, Command::Start => lifecycle.start().await, Command::Stop => lifecycle.stop().await, Command::Status => lifecycle.status().await, Command::Logs { lines } => lifecycle.logs(lines).await, Command::Serve { .. } => run_my_server(..).await, // actual server code } ``` ### Makefile best practice ```makefile run: update build ## Developer command — start + stream logs cargo run -p my_server -- run start: update build ## Background start cargo run -p my_server -- start ``` No Makefile-level log polling — `ZinitLifecycle::run()` handles everything. ### Applied in - **hero_rpc** (9d338ad) — core implementation - **hero_os** (4fa4073) — both `hero_os_server` (OpenRPC) and `hero_os_ui` (HTTP, uses ZinitLifecycle directly) - **hero_skills** — lifecycle skill updated ### Action for other repos Any repo with a hero_rpc-generated server should adopt this convention: 1. Update to latest `hero_rpc` (`cargo update`) 2. If the repo has an HTTP/UI binary, add `ZinitLifecycle` with the `Run/Serve` pattern shown above 3. Update Makefile to delegate to CLI subcommands
timur commented 2026-03-10 08:47:20 +00:00
Owner
Copy link

Zinit Lifecycle Serve Rename — Applied to All 4 Repos

The serve rename convention has been applied to all 4 service repos:

Changes per repo

All repos received identical structural changes:

  1. CLI subcommands renamed:

    • run → Developer command (start via zinit + stream logs + stop on Ctrl-C)
    • serve → Internal (what zinit invokes to run the actual server process)
    • start → Start via zinit in background
    • stop / status / logs / ui / zinit — unchanged

  2. lifecycle.rs updated:

    • exec_command() now generates {binary} serve (was {binary} run)
    • Added run() method (start + poll logs + Ctrl-C stop)
    • Fixed zinit socket path to ~/hero/var/sockets/zinit_server.sock

  3. Makefile updated:

    • make run → cargo run -p <server> -- run (zinit-managed, streams logs)
    • make start → cargo run -p <server> -- start (background)
    • make stop → cargo run -p <server> -- stop
    • make rundev → cargo run -p <server> -- serve (direct, no zinit)

Repos & commits

Repo Branch Commit Status
hero_aibroker development_standardize 415ac19 compiles clean
hero_embedder development 0351b0d compiles clean
hero_index_server development f3ae5d6 compiles clean
hero_redis development abecd5f compiles clean

Reference pattern

Follows the hero_os (development_timur) reference implementation and hero_rpc commit 9d338ad.

# Developer workflow
hero_embedder_server run      # start + stream logs + Ctrl-C stops
hero_embedder_server start    # start in background
hero_embedder_server stop     # stop service
hero_embedder_server serve    # internal: zinit calls this
## Zinit Lifecycle Serve Rename — Applied to All 4 Repos The serve rename convention has been applied to all 4 service repos: ### Changes per repo All repos received identical structural changes: 1. **CLI subcommands renamed:** - `run` → Developer command (start via zinit + stream logs + stop on Ctrl-C) - `serve` → Internal (what zinit invokes to run the actual server process) - `start` → Start via zinit in background - `stop` / `status` / `logs` / `ui` / `zinit` — unchanged 2. **lifecycle.rs updated:** - `exec_command()` now generates `{binary} serve` (was `{binary} run`) - Added `run()` method (start + poll logs + Ctrl-C stop) - Fixed zinit socket path to `~/hero/var/sockets/zinit_server.sock` 3. **Makefile updated:** - `make run` → `cargo run -p <server> -- run` (zinit-managed, streams logs) - `make start` → `cargo run -p <server> -- start` (background) - `make stop` → `cargo run -p <server> -- stop` - `make rundev` → `cargo run -p <server> -- serve` (direct, no zinit) ### Repos & commits | Repo | Branch | Commit | Status | |------|--------|--------|--------| | hero_aibroker | `development_standardize` | `415ac19` | compiles clean | | hero_embedder | `development` | `0351b0d` | compiles clean | | hero_index_server | `development` | `f3ae5d6` | compiles clean | | hero_redis | `development` | `abecd5f` | compiles clean | ### Reference pattern Follows the hero_os (development_timur) reference implementation and hero_rpc commit `9d338ad`. ```bash # Developer workflow hero_embedder_server run # start + stream logs + Ctrl-C stops hero_embedder_server start # start in background hero_embedder_server stop # stop service hero_embedder_server serve # internal: zinit calls this ```
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
ACTIVE
Assignees
Clear assignees
No assignees
timur
2 participants
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/home#6
No description provided.