Bootstrap canonical `hero_service` template repo (toy domain: managing Hero services) #261

New issue

Open

opened 2026-05-18 12:37:12 +00:00 by timur · 2 comments

timur commented

2026-05-18 12:37:12 +00:00

Owner

Goal

Create a top-level template repo that contributors clone as the starting point for a new Hero service, and that doubles as a meta-example: its toy domain is "managing Hero services" — so the same template is intended to evolve into the production "service that creates services" later.

Naming — resolve collision first

There is already a crate named hero_service at hero_rpc/crates/service/. A top-level repo of the same name would collide on Cargo workspace dependency names.

Options:

A. Name the repo hero_service_template (clear, no collision).
B. Name the repo hero_service and rename the inner hero_rpc crate to hero_lifecycle (or merge it into herolib_core::base per the hero_rpc codegen-alignment issue — which would also kill the collision).
C. Pick a different domain name (hero_servicer, hero_factory).

My recommendation: B is cleanest long-term and aligns with the lifecycle-reconciliation work already planned in hero_rpc. A is the safe interim. Comment with your call.

What the repo should contain

Generated by hero_rpc scaffold (when that exists — see hero_rpc issues), then hand-tuned:

Workspace with _server, _admin, _sdk, _examples crates (and _web if a public-facing surface is desired).
schemas/services/services.oschema defining a ServiceDefinition root object (name, repo, schemas, binaries, sockets, status) — i.e. the data model behind the meta-domain.
Per-binary service.toml, build.rs ≤5 lines, main.rs using service_base!() + herolib_core::base wiring.
_admin UI wired to hero_website_lib showing a list/detail view of ServiceDefinition records.
README walking through the AI-driven flow (scaffold → fill stubs → build → lab service start), referencing the new scaffold skill.
.forgejo/workflows/build-linux.yaml per the forge-release-workflow skill.

Why "toy domain = managing services" matters

Two wins for the same effort:

Contributors get a real-but-tiny example to mimic.
The schemas + handlers we write here are the literal seed of the future "hero scaffold service" — instead of building it twice, we evolve this template into the production service.

Acceptance

New repo exists at forge.ourworld.tf/lhumina_code/<chosen-name>.
git clone → cargo build → lab infocheck → lab service <name> --start all succeed without manual edits.
The scaffold skill (#scaffold-check-refactor-skills) references this repo as its "clone-me" starting point.
This issue records the naming-collision decision (A/B/C) for posterity.

Depends on

hero_rpc #scaffold-full-service-repo (the tool that produces it)
hero_rpc #codegen-alignment (so the generated output is current)
hero_website_framework #drop-admin-lib-alias (so the _admin wiring uses one name)
#scaffold-check-refactor-skills (the skill that references this repo)

## Goal Create a top-level template repo that contributors clone as the starting point for a new Hero service, and that doubles as a meta-example: its toy domain is **"managing Hero services"** — so the same template is intended to evolve into the production "service that creates services" later. ## Naming — resolve collision first There is already a crate named `hero_service` at `hero_rpc/crates/service/`. A top-level repo of the same name would collide on Cargo workspace dependency names. **Options:** - **A.** Name the repo `hero_service_template` (clear, no collision). - **B.** Name the repo `hero_service` and rename the inner hero_rpc crate to `hero_lifecycle` (or merge it into `herolib_core::base` per the hero_rpc codegen-alignment issue — which would also kill the collision). - **C.** Pick a different domain name (`hero_servicer`, `hero_factory`). My recommendation: **B** is cleanest long-term and aligns with the lifecycle-reconciliation work already planned in hero_rpc. **A** is the safe interim. Comment with your call. ## What the repo should contain Generated by `hero_rpc scaffold` (when that exists — see hero_rpc issues), then hand-tuned: - Workspace with `_server`, `_admin`, `_sdk`, `_examples` crates (and `_web` if a public-facing surface is desired). - `schemas/services/services.oschema` defining a `ServiceDefinition` root object (name, repo, schemas, binaries, sockets, status) — i.e. the data model behind the meta-domain. - Per-binary `service.toml`, `build.rs` ≤5 lines, `main.rs` using `service_base!()` + `herolib_core::base` wiring. - `_admin` UI wired to `hero_website_lib` showing a list/detail view of `ServiceDefinition` records. - README walking through the AI-driven flow (scaffold → fill stubs → build → lab service start), referencing the new scaffold skill. - `.forgejo/workflows/build-linux.yaml` per the `forge-release-workflow` skill. ## Why "toy domain = managing services" matters Two wins for the same effort: 1. Contributors get a real-but-tiny example to mimic. 2. The schemas + handlers we write here are the *literal seed* of the future "hero scaffold service" — instead of building it twice, we evolve this template into the production service. ## Acceptance - New repo exists at `forge.ourworld.tf/lhumina_code/<chosen-name>`. - `git clone` → `cargo build` → `lab infocheck` → `lab service <name> --start` all succeed without manual edits. - The scaffold skill (#scaffold-check-refactor-skills) references this repo as its "clone-me" starting point. - This issue records the naming-collision decision (A/B/C) for posterity. ## Depends on - hero_rpc #scaffold-full-service-repo (the tool that produces it) - hero_rpc #codegen-alignment (so the generated output is current) - hero_website_framework #drop-admin-lib-alias (so the `_admin` wiring uses one name) - #scaffold-check-refactor-skills (the skill that references this repo)

timur referenced this issue from lhumina_code/hero_rpc

2026-05-18 13:27:10 +00:00

Scaffold full service repo from template (hero_rpc scaffold) #54

timur referenced this issue

2026-05-18 14:40:33 +00:00

[META] Standardize Hero service architecture — template, hero_rpc alignment, framework hoist, skills #262

timur commented

2026-05-18 14:41:22 +00:00

Author

Owner

Parent / context tracker: hero_skills#262 — read it before starting work on this issue. Locked decisions, reference materials, and execution order live there. Iterate via comments here; consolidation passes on the body only after feedback settles.

Parent / context tracker: [hero_skills#262](https://forge.ourworld.tf/lhumina_code/hero_skills/issues/262) — read it before starting work on this issue. Locked decisions, reference materials, and execution order live there. Iterate via comments here; consolidation passes on the body only after feedback settles.

timur commented

2026-05-18 14:54:12 +00:00

Author

Owner

Decision: B (confirmed by Timur)

Template repo name: hero_service (top-level in lhumina_code).
Inner crate at hero_rpc/crates/service/ (Cargo package hero_service) gets renamed to hero_lifecycle — recent commits there show it's still actively developed, so rename rather than delete. Cross-action item tracked in hero_rpc#55 (correction comment landed there).

Action items locked

Rename hero_rpc/crates/service/ → hero_rpc/crates/hero_lifecycle/. Update package name to hero_lifecycle. Update all downstream [workspace.dependencies] references (hero_service = → hero_lifecycle = ).
After rename is in, create lhumina_code/hero_service repo by running the updated hero_rpc scaffold against a services domain OSchema.
First-pass schema: ServiceDefinition root object (name, repo, schemas, binaries, sockets, status) — the seed of the future production "service that creates services".

Blocked on hero_rpc#54 + #55 landing first. Out of scope for tier-1 agent work.

## Decision: B (confirmed by Timur) - Template repo name: **`hero_service`** (top-level in `lhumina_code`). - Inner crate at `hero_rpc/crates/service/` (Cargo package `hero_service`) gets renamed to **`hero_lifecycle`** — recent commits there show it's still actively developed, so rename rather than delete. Cross-action item tracked in [hero_rpc#55](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/55) (correction comment landed there). ### Action items locked - [ ] Rename `hero_rpc/crates/service/` → `hero_rpc/crates/hero_lifecycle/`. Update package name to `hero_lifecycle`. Update all downstream `[workspace.dependencies]` references (`hero_service = ` → `hero_lifecycle = `). - [ ] After rename is in, create `lhumina_code/hero_service` repo by running the updated `hero_rpc scaffold` against a `services` domain OSchema. - [ ] First-pass schema: `ServiceDefinition` root object (name, repo, schemas, binaries, sockets, status) — the seed of the future production "service that creates services". Blocked on [hero_rpc#54](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/54) + [#55](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/55) landing first. Out of scope for tier-1 agent work.