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

New issue

Open

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

timur commented 2026-05-18 12:37:09 +00:00

Owner

Copy link

Goal

Give hero_rpc a first-class scaffolding capability that produces an entire new Hero service repo aligned with current standards — so a contributor (or AI agent) can go from oschema to a running, lab-installable service in minutes.

This is separate from the codegen capability (see #55) which runs after scaffolding, every build.

Reference services

These are the services to mimic. Pull development branch first.

Service	What to mimic	What NOT to mimic
hero_proc (repo)	Binary wiring — service_base!(), validate_service_toml, handle_info_flag, embedded service.toml. PURPOSE.md is the canonical example of that doc.	—
hero_compute (repo)	Workspace layout (resolver 3, edition 2024) and hero_rpc OSchema dep set in Cargo.toml.	Its _server/src/main.rs uses an older run/start/stop/status/serve subcommand pattern with no service_base!() — do NOT carry that over. Wiring must follow hero_proc.

Note: hero_inspector is out-of-date and intentionally left out as a reference.

Alignment with hero_skills (must satisfy lab infocheck)

The scaffolded output must pass these skills clean with zero manual edits:

• skills/hero/service/hero_service.md — startup banner, --info, --help, BUILD_NR via option_env!("HERO_BUILD_NR").
• skills/hero/service/hero_service_toml_info.md — service.toml schema (herolib_core::base::ServiceToml), service_base!() macro, --info flag contract, closed enums (Kind, Category, Protocol, SockType).
• skills/hero/service/hero_service_check_fix.md — lab infocheck, socket paths under $HERO_SOCKET_DIR/<service>/<type>.sock, naming suffixes (_server/_admin/_sdk/_web/_app), no Makefile / scripts/*.sh / service_<name>.nu.
• skills/hero/... herolib_base skill — print_startup_banner and prepare_sockets from herolib_core::base (no hand-rolled equivalents).
• skills/forge-release-workflow — .forgejo/workflows/build-linux.yaml.
• skills/hero/sockets — HERO_SOCKET_DIR conventions and the router homepage card naming rule (admin.sock / web_<name>.sock, never bare web.sock).

What to generate

Given an input (service name + initial .oschema file + optional flags), produce a complete repo:

• Cargo.toml workspace (resolver = "3", edition 2024, rust-version 1.92+, deps from hero_compute as a starting point)
• crates/hero_<name>_server/ — RPC daemon (binary). Wiring mirrors hero_proc_server/src/main.rs.
• crates/hero_<name>_sdk/ — generated client SDK (see #55).
• crates/hero_<name>_admin/ — admin UI binary wired to hero_website_lib. Templates use Askama by default — Hero ecosystem default is compile-time Askama (matches hero_proc_admin). Tera is reserved for cases that genuinely need runtime template loading (user-editable content like blog posts); none of the default admin screens do. The scaffolded _admin consumes framework default screens as-is even if hero_website_framework's own existing templates remain Tera until separately migrated.
• crates/hero_<name>_examples/ — runnable examples crate using the generated SDK.
• crates/hero_<name>/ — CLI client. Only generated if the user opts in (--cli flag). Per hero_service_check_fix §5, a CLI that only does selfstart provides no value and must be omitted.
• Per-binary service.toml at each crate root.
• schemas/<domain>/<domain>.oschema seeded from input.
• Each binary's src/main.rs pre-wired with service_base!(), validate_service_toml(SERVICE_TOML), handle_info_flag(SERVICE_TOML), print_startup_banner, prepare_sockets — no hand-rolled equivalents.
• Per-binary build.rs reduced to ≤5 lines (depends on #56).
• README.md — overview, quickstart, references lab service <name> --start only (never make, never bash scripts).
• PURPOSE.md — repo-level document listing components, internal crates, key features, lifecycle commands. Required by hero_service_check_fix §1 ("Read PURPOSE.md to know which components exist, if it doesn't exist generate it"). Model the file on hero_proc/PURPOSE.md: tables for Binary | Role | Socket and Crate | Role, then a short "Key Features" section. Lifecycle commands must only reference lab service ... (§6 of the check skill).
• .gitignore, .forgejo/workflows/build-linux.yaml per forge-release-workflow skill.
• No Makefile, no scripts/*.sh, no service_<name>.nu (ADR-0001).

Naming

Follow the table in hero_skills/skills/hero/service/hero_service_check_fix.md §2:

Component	Binary name	Required
Server	hero_<name>_server	yes
Admin UI	hero_<name>_admin	yes (paired with server)
SDK	hero_<name>_sdk (lib)	yes
CLI	hero_<name>	only if non-trivial
End-user web	hero_<name>_web	optional

Never _ui, _cli, _cmd.

CLI surface

hero_rpc scaffold <name> --schema <path-to-oschema> [--no-admin] [--no-sdk] [--cli] [--out <dir>]
hero_rpc scaffold <name> --from-service-toml <path>   # re-scaffold from an existing service.toml

Exposing this as lab service new <name> is a separate follow-up issue (to be opened against this repo or hero_skills once this scaffold capability lands).

Out of scope

• Filling in business logic in the generated trait stub — that's the contributor's job; the stub file must be clearly marked.
• Admin UI screens beyond the framework defaults (#4 covers what the framework offers).
• The lab service new subcommand (follow-up).

Acceptance

• hero_rpc scaffold tasks --schema sample.oschema --out /tmp/hero_tasks produces a workspace where cargo build && lab infocheck both succeed with zero manual edits.
• Every generated service.toml deserialises into herolib_core::base::ServiceToml.
• Every generated binary answers --info and --info --json from its embedded service.toml (no hand-rolled JSON shape).
• The generated _admin binary serves the framework default templates at admin.sock.
• The generated _server binary passes the smoke tests in hero_service_check_fix.md §7 (/health, /openrpc.json, /.well-known/heroservice.json, JSON-RPC system.ping).
• lab service <name> --install && lab service <name> --start succeeds.
• PURPOSE.md and README.md exist and reference only lab service ... commands for lifecycle.

Related

• #55 — Codegen alignment (runs after scaffold, every build).
• #56 — Modularize generator/src/build/build.rs (lets the scaffolded build.rs be ≤5 lines).
• #57 — Upgrade example/recipe_server (consumes this end-to-end).
• hero_website_framework#4 — Reusable admin components the scaffolded _admin will inherit.
• hero_website_framework#5 — Drop hero_admin_lib alias (so scaffolded _admin imports the canonical name).
• hero_web_template#4 — Shared stylesheets.
• hero_skills#260 — Scaffold/check/refactor context skills + refresh existing service skills.
• hero_skills#261 — Bootstrap canonical hero_service template repo (consumes this scaffold).
• Reference repos: hero_proc (wiring), hero_compute (layout + deps).
• Reference skills: hero_skills/skills/hero/service/.

## Goal Give hero_rpc a first-class **scaffolding** capability that produces an entire new Hero service repo aligned with current standards — so a contributor (or AI agent) can go from `oschema` to a running, lab-installable service in minutes. This is separate from the **codegen** capability (see #55) which runs *after* scaffolding, every build. ## Reference services These are the services to mimic. Pull `development` branch first. | Service | What to mimic | What NOT to mimic | |---|---|---| | `hero_proc` ([repo](https://forge.ourworld.tf/lhumina_code/hero_proc)) | **Binary wiring** — `service_base!()`, `validate_service_toml`, `handle_info_flag`, embedded `service.toml`. `PURPOSE.md` is the canonical example of that doc. | — | | `hero_compute` ([repo](https://forge.ourworld.tf/lhumina_code/hero_compute)) | **Workspace layout** (resolver 3, edition 2024) and **hero_rpc OSchema dep set** in `Cargo.toml`. | Its `_server/src/main.rs` uses an older `run/start/stop/status/serve` subcommand pattern with no `service_base!()` — do NOT carry that over. Wiring must follow `hero_proc`. | Note: `hero_inspector` is out-of-date and intentionally left out as a reference. ## Alignment with hero_skills (must satisfy `lab infocheck`) The scaffolded output must pass these skills clean with **zero** manual edits: - [`skills/hero/service/hero_service.md`](https://forge.ourworld.tf/lhumina_code/hero_skills/src/branch/development/skills/hero/service/hero_service.md) — startup banner, `--info`, `--help`, `BUILD_NR` via `option_env!("HERO_BUILD_NR")`. - [`skills/hero/service/hero_service_toml_info.md`](https://forge.ourworld.tf/lhumina_code/hero_skills/src/branch/development/skills/hero/service/hero_service_toml_info.md) — `service.toml` schema (`herolib_core::base::ServiceToml`), `service_base!()` macro, `--info` flag contract, closed enums (`Kind`, `Category`, `Protocol`, `SockType`). - [`skills/hero/service/hero_service_check_fix.md`](https://forge.ourworld.tf/lhumina_code/hero_skills/src/branch/development/skills/hero/service/hero_service_check_fix.md) — `lab infocheck`, socket paths under `$HERO_SOCKET_DIR/<service>/<type>.sock`, naming suffixes (`_server`/`_admin`/`_sdk`/`_web`/`_app`), no `Makefile` / `scripts/*.sh` / `service_<name>.nu`. - `skills/hero/...` `herolib_base` skill — `print_startup_banner` and `prepare_sockets` from `herolib_core::base` (no hand-rolled equivalents). - [`skills/forge-release-workflow`](https://forge.ourworld.tf/lhumina_code/hero_skills) — `.forgejo/workflows/build-linux.yaml`. - `skills/hero/sockets` — `HERO_SOCKET_DIR` conventions and the router homepage card naming rule (`admin.sock` / `web_<name>.sock`, never bare `web.sock`). ## What to generate Given an input (service name + initial `.oschema` file + optional flags), produce a complete repo: - `Cargo.toml` workspace (`resolver = "3"`, edition 2024, rust-version 1.92+, deps from `hero_compute` as a starting point) - `crates/hero_<name>_server/` — RPC daemon (binary). Wiring mirrors `hero_proc_server/src/main.rs`. - `crates/hero_<name>_sdk/` — generated client SDK (see #55). - `crates/hero_<name>_admin/` — admin UI binary wired to `hero_website_lib`. **Templates use Askama by default** — Hero ecosystem default is compile-time Askama (matches `hero_proc_admin`). Tera is reserved for cases that genuinely need runtime template loading (user-editable content like blog posts); none of the default admin screens do. The scaffolded `_admin` consumes framework default screens as-is even if `hero_website_framework`'s own existing templates remain Tera until separately migrated. - `crates/hero_<name>_examples/` — runnable examples crate using the generated SDK. - `crates/hero_<name>/` — CLI client. **Only generated if the user opts in** (`--cli` flag). Per `hero_service_check_fix` §5, a CLI that only does `selfstart` provides no value and must be omitted. - Per-binary `service.toml` at each crate root. - `schemas/<domain>/<domain>.oschema` seeded from input. - Each binary's `src/main.rs` pre-wired with `service_base!()`, `validate_service_toml(SERVICE_TOML)`, `handle_info_flag(SERVICE_TOML)`, `print_startup_banner`, `prepare_sockets` — no hand-rolled equivalents. - Per-binary `build.rs` reduced to **≤5 lines** (depends on #56). - `README.md` — overview, quickstart, references `lab service <name> --start` only (never `make`, never bash scripts). - `PURPOSE.md` — repo-level document listing components, internal crates, key features, lifecycle commands. Required by `hero_service_check_fix` §1 ("Read `PURPOSE.md` to know which components exist, if it doesn't exist generate it"). Model the file on [`hero_proc/PURPOSE.md`](https://forge.ourworld.tf/lhumina_code/hero_proc/src/branch/development/PURPOSE.md): tables for `Binary | Role | Socket` and `Crate | Role`, then a short "Key Features" section. Lifecycle commands must only reference `lab service ...` (§6 of the check skill). - `.gitignore`, `.forgejo/workflows/build-linux.yaml` per `forge-release-workflow` skill. - **No** `Makefile`, **no** `scripts/*.sh`, **no** `service_<name>.nu` (ADR-0001). ## Naming Follow the table in `hero_skills/skills/hero/service/hero_service_check_fix.md` §2: | Component | Binary name | Required | |---|---|---| | Server | `hero_<name>_server` | yes | | Admin UI | `hero_<name>_admin` | yes (paired with server) | | SDK | `hero_<name>_sdk` (lib) | yes | | CLI | `hero_<name>` | only if non-trivial | | End-user web | `hero_<name>_web` | optional | Never `_ui`, `_cli`, `_cmd`. ## CLI surface ``` hero_rpc scaffold <name> --schema <path-to-oschema> [--no-admin] [--no-sdk] [--cli] [--out <dir>] hero_rpc scaffold <name> --from-service-toml <path> # re-scaffold from an existing service.toml ``` **Exposing this as `lab service new <name>` is a separate follow-up issue** (to be opened against this repo or `hero_skills` once this scaffold capability lands). ## Out of scope - Filling in business logic in the generated trait stub — that's the contributor's job; the stub file must be clearly marked. - Admin UI screens beyond the framework defaults (#4 covers what the framework offers). - The `lab service new` subcommand (follow-up). ## Acceptance - `hero_rpc scaffold tasks --schema sample.oschema --out /tmp/hero_tasks` produces a workspace where `cargo build && lab infocheck` both succeed with zero manual edits. - Every generated `service.toml` deserialises into `herolib_core::base::ServiceToml`. - Every generated binary answers `--info` and `--info --json` from its embedded `service.toml` (no hand-rolled JSON shape). - The generated `_admin` binary serves the framework default templates at `admin.sock`. - The generated `_server` binary passes the smoke tests in `hero_service_check_fix.md` §7 (`/health`, `/openrpc.json`, `/.well-known/heroservice.json`, JSON-RPC `system.ping`). - `lab service <name> --install && lab service <name> --start` succeeds. - `PURPOSE.md` and `README.md` exist and reference only `lab service ...` commands for lifecycle. ## Related - [#55](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/55) — Codegen alignment (runs after scaffold, every build). - [#56](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/56) — Modularize `generator/src/build/build.rs` (lets the scaffolded `build.rs` be ≤5 lines). - [#57](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/57) — Upgrade `example/recipe_server` (consumes this end-to-end). - [hero_website_framework#4](https://forge.ourworld.tf/lhumina_code/hero_website_framework/issues/4) — Reusable admin components the scaffolded `_admin` will inherit. - [hero_website_framework#5](https://forge.ourworld.tf/lhumina_code/hero_website_framework/issues/5) — Drop `hero_admin_lib` alias (so scaffolded `_admin` imports the canonical name). - [hero_web_template#4](https://forge.ourworld.tf/lhumina_code/hero_web_template/issues/4) — Shared stylesheets. - [hero_skills#260](https://forge.ourworld.tf/lhumina_code/hero_skills/issues/260) — Scaffold/check/refactor context skills + refresh existing service skills. - [hero_skills#261](https://forge.ourworld.tf/lhumina_code/hero_skills/issues/261) — Bootstrap canonical `hero_service` template repo (consumes this scaffold). - Reference repos: [`hero_proc`](https://forge.ourworld.tf/lhumina_code/hero_proc) (wiring), [`hero_compute`](https://forge.ourworld.tf/lhumina_code/hero_compute) (layout + deps). - Reference skills: [`hero_skills/skills/hero/service/`](https://forge.ourworld.tf/lhumina_code/hero_skills/src/branch/development/skills/hero/service).

timur commented 2026-05-18 13:23:08 +00:00

Author

Owner

Copy link

Lets double check that the scaffolded repo we want to create is aligned with latest standards and best practices from hero_skills. What is the purpose of PURPOSE.md stubs and what do they do, where are they mentioned? CLI Surface is good, and exposing this as lab sub command can be an issue that follows. lets also update the initial issue description related section to properly link to other issues and repos.

Lets double check that the scaffolded repo we want to create is aligned with latest standards and best practices from hero_skills. What is the purpose of PURPOSE.md stubs and what do they do, where are they mentioned? CLI Surface is good, and exposing this as lab sub command can be an issue that follows. lets also update the initial issue description related section to properly link to other issues and repos.

timur referenced this issue 2026-05-18 14:00:21 +00:00

Codegen alignment with current standards (service.toml, SDK, _admin, lab lifecycle) #55

timur referenced this issue from lhumina_code/hero_skills 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:19 +00:00

Author

Owner

Copy link

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:10 +00:00

Author

Owner

Copy link

Existing scaffolder — context for agents

I missed that this repo already has a scaffolder. On latest development:

crates/generator/src/build/scaffold.rs — 1208 lines, exposes WorkspaceScaffolder. Today it generates a 5-crate workspace:

hero_<name>/
├── Cargo.toml              # workspace
├── Makefile                # ← must be removed (ADR-0001: lab only)
├── buildenv.sh
├── schemas/                # oschema
├── data/mock/              # seed data
├── docs/schemas/           # generated docs
└── crates/
    ├── hero_<name>/        # core lib
    ├── hero_<name>_server/ # ✓
    ├── hero_<name>_client/ # ← rename to _sdk per hero_skills
    ├── hero_<name>_rhai/   # bindings
    └── hero_<name>_ui/     # ← rename to _admin per hero_skills (never _ui)

This issue is now: extend + correct WorkspaceScaffolder, not build from scratch. Required deltas (all of these are locked decisions from the META — hero_skills#262):

• Rename generated crate: _client → _sdk. Update all references in the scaffolder.
• Rename generated crate: _ui → _admin. Update method names (with_ui() / generate_ui / generate_ui_crate) accordingly.
• Add hero_<name>_examples/ crate generation (runnable SDK usage examples).
• Generate service.toml per binary crate (server, admin) matching herolib_core::base::ServiceToml.
• Wire generated _admin against hero_admin_lib (Axum + rust-embed, not Tera/SQLite).
• Pre-wire generated main.rs with service_base!(), validate_service_toml, handle_info_flag, print_startup_banner, prepare_sockets (per hero_proc reference).
• Drop Makefile generation (ADR-0001: lab is the single lifecycle tool — no Makefile, no scripts/*.sh, no service_<name>.nu).
• Generate PURPOSE.md (per hero_service_check_fix skill §1) and README.md that reference only lab service ... for lifecycle.
• Generate .forgejo/workflows/build-linux.yaml per forge-release-workflow skill.
• Add Python SDK as a fourth target alongside JS/TS + Rhai (new in scope — confirmed in #55 comment 33681).

## Existing scaffolder — context for agents I missed that this repo already has a scaffolder. On latest `development`: **[`crates/generator/src/build/scaffold.rs`](https://forge.ourworld.tf/lhumina_code/hero_rpc/src/branch/development/crates/generator/src/build/scaffold.rs)** — 1208 lines, exposes `WorkspaceScaffolder`. Today it generates a 5-crate workspace: ``` hero_<name>/ ├── Cargo.toml # workspace ├── Makefile # ← must be removed (ADR-0001: lab only) ├── buildenv.sh ├── schemas/ # oschema ├── data/mock/ # seed data ├── docs/schemas/ # generated docs └── crates/ ├── hero_<name>/ # core lib ├── hero_<name>_server/ # ✓ ├── hero_<name>_client/ # ← rename to _sdk per hero_skills ├── hero_<name>_rhai/ # bindings └── hero_<name>_ui/ # ← rename to _admin per hero_skills (never _ui) ``` **This issue is now: extend + correct `WorkspaceScaffolder`**, not build from scratch. Required deltas (all of these are locked decisions from the META — [hero_skills#262](https://forge.ourworld.tf/lhumina_code/hero_skills/issues/262)): - [ ] Rename generated crate: `_client` → `_sdk`. Update all references in the scaffolder. - [ ] Rename generated crate: `_ui` → `_admin`. Update method names (`with_ui()` / `generate_ui` / `generate_ui_crate`) accordingly. - [ ] Add `hero_<name>_examples/` crate generation (runnable SDK usage examples). - [ ] Generate `service.toml` per binary crate (server, admin) matching `herolib_core::base::ServiceToml`. - [ ] Wire generated `_admin` against [`hero_admin_lib`](https://forge.ourworld.tf/lhumina_code/hero_website_framework/src/branch/development/crates/hero_admin_lib) (Axum + rust-embed, not Tera/SQLite). - [ ] Pre-wire generated `main.rs` with `service_base!()`, `validate_service_toml`, `handle_info_flag`, `print_startup_banner`, `prepare_sockets` (per hero_proc reference). - [ ] Drop Makefile generation (ADR-0001: `lab` is the single lifecycle tool — no `Makefile`, no `scripts/*.sh`, no `service_<name>.nu`). - [ ] Generate `PURPOSE.md` (per `hero_service_check_fix` skill §1) and `README.md` that reference only `lab service ...` for lifecycle. - [ ] Generate `.forgejo/workflows/build-linux.yaml` per `forge-release-workflow` skill. - [ ] Add Python SDK as a fourth target alongside JS/TS + Rhai (new in scope — confirmed in [#55 comment 33681](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/55#issuecomment-33681)).

timur referenced this issue 2026-05-18 14:54:10 +00:00

Codegen alignment with current standards (service.toml, SDK, _admin, lab lifecycle) #55

timur referenced this issue 2026-05-18 14:54:11 +00:00

Upgrade example/recipe_server to end-to-end demo of new pattern #57

timur referenced this issue from lhumina_code/hero_skills 2026-05-18 14:54:12 +00:00

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

timur referenced this issue from lhumina_code/hero_skills 2026-05-18 14:54:12 +00:00

Add scaffold / check / refactor context skills + refresh existing service skills #260

timur referenced this issue from a commit 2026-05-19 02:38:33 +00:00

hero/service skills: add scaffold / check / refactor skills (#260 tier-3)

timur referenced this issue from a commit 2026-05-19 02:41:10 +00:00

feat(scaffold): #54 examples crate + PURPOSE.md + README + CI + drop Makefile

timur commented 2026-05-19 02:41:37 +00:00

Author

Owner

Copy link

#54 remaining scope landed on issue-54-scaffold-extend

Branched off issue-55-codegen-alignment per the META directive (#54 builds on #55 wiring). Single commit, 3cd7605.

Deltas (all in crates/generator/src/build/scaffold.rs)

Delta	Status
Drop Makefile + buildenv.sh generation (ADR-0001)	✅
Generate hero_<name>_examples/ crate (Cargo.toml + src/lib.rs + examples/01_connect.rs)	✅
Generate PURPOSE.md modelled on hero_proc/PURPOSE.md — Binary | Role | Socket and Crate | Role tables, Key Features, Service Management, lifecycle = lab service ... only	✅
Generate README.md — quickstart, components, domains, smoke test; lifecycle = lab service ... only (no make, no bash, no nu)	✅
Generate .gitignore	✅
Generate .forgejo/workflows/build-linux.yaml per forge-release-workflow skill (self-contained Rust variant, tag → musl release binaries)	✅

Bonus: unblock lab infocheck

The pre-#54 scaffolder shipped crates/hero_<name>/ and crates/hero_<name>_sdk/ without a src/lib.rs, so cargo metadata errored out with "no targets specified in the manifest" before build.rs codegen had a chance to fill them in. That made lab infocheck (and every workspace-wide tool) abort on the very first crate. Added 2-line pub mod services; stubs that the OSchema generator then enriches on the first build. No other changes needed.

Acceptance — lab infocheck clean, zero manual edits

$ cargo run -p hero_rpc_generator --bin hero_rpc_generator -- \
    --name hero_demo --workspace-dir $TMP --no-rhai
$ cd $TMP && git init -q && lab infocheck
repo: $TMP
crates discovered: 2
  ok   $TMP/crates/hero_demo_admin
  ok   $TMP/crates/hero_demo_server
summary: 2 crate(s) clean, 0 crate(s) with issues, 0 finding(s) total

Tests

10 new scaffold tests against the on-disk artefacts (replacing the prior unit-only style). cargo test -p hero_rpc_generator → 121 passed, 1 ignored (was 110). cargo fmt --check clean.

Out-of-scope items flagged for follow-up

Not done here, by design:

• CLI flags --no-admin / --no-sdk / --cli / --from-service-toml / --out as listed in the issue body. The existing --no-admin / --no-rhai already work; the new flags are CLI-binary edits, not scaffolder logic. Will be its own small commit if needed before the PR opens.
• Renaming _rhai to a different suffix — the issue body doesn't ask for this; current _rhai matches the existing pattern.
• Acceptance test cargo build && lab infocheck — cargo build against the scaffolded workspace can't pass in CI today because the generated crates pin hero_lifecycle / hero_admin_lib to branch = "development", and #55's hero_lifecycle rename hasn't merged yet. Will pass automatically once #55 merges to development. lab infocheck does pass right now (it only needs cargo metadata, not a full build).

Branch

issue-54-scaffold-extend — based on issue-55-codegen-alignment. Should be merged via PR after the #55 PR lands on development (or rebased onto development if #55 is merged first).

## #54 remaining scope landed on `issue-54-scaffold-extend` Branched off `issue-55-codegen-alignment` per the META directive (#54 builds on #55 wiring). Single commit, [`3cd7605`](https://forge.ourworld.tf/lhumina_code/hero_rpc/commit/3cd7605). ### Deltas (all in `crates/generator/src/build/scaffold.rs`) | Delta | Status | |---|---| | Drop `Makefile` + `buildenv.sh` generation (ADR-0001) | ✅ | | Generate `hero_<name>_examples/` crate (`Cargo.toml` + `src/lib.rs` + `examples/01_connect.rs`) | ✅ | | Generate `PURPOSE.md` modelled on [`hero_proc/PURPOSE.md`](https://forge.ourworld.tf/lhumina_code/hero_proc/src/branch/development/PURPOSE.md) — `Binary \| Role \| Socket` and `Crate \| Role` tables, Key Features, Service Management, lifecycle = `lab service ...` only | ✅ | | Generate `README.md` — quickstart, components, domains, smoke test; lifecycle = `lab service ...` only (no `make`, no bash, no nu) | ✅ | | Generate `.gitignore` | ✅ | | Generate `.forgejo/workflows/build-linux.yaml` per `forge-release-workflow` skill (self-contained Rust variant, tag → musl release binaries) | ✅ | ### Bonus: unblock `lab infocheck` The pre-#54 scaffolder shipped `crates/hero_<name>/` and `crates/hero_<name>_sdk/` *without* a `src/lib.rs`, so `cargo metadata` errored out with *"no targets specified in the manifest"* before `build.rs` codegen had a chance to fill them in. That made `lab infocheck` (and every workspace-wide tool) abort on the very first crate. Added 2-line `pub mod services;` stubs that the OSchema generator then enriches on the first build. No other changes needed. ### Acceptance — `lab infocheck` clean, zero manual edits ``` $ cargo run -p hero_rpc_generator --bin hero_rpc_generator -- \ --name hero_demo --workspace-dir $TMP --no-rhai $ cd $TMP && git init -q && lab infocheck repo: $TMP crates discovered: 2 ok $TMP/crates/hero_demo_admin ok $TMP/crates/hero_demo_server summary: 2 crate(s) clean, 0 crate(s) with issues, 0 finding(s) total ``` ### Tests 10 new scaffold tests against the on-disk artefacts (replacing the prior unit-only style). `cargo test -p hero_rpc_generator` → **121 passed, 1 ignored** (was 110). `cargo fmt --check` clean. ### Out-of-scope items flagged for follow-up Not done here, by design: - **CLI flags `--no-admin` / `--no-sdk` / `--cli` / `--from-service-toml` / `--out`** as listed in the issue body. The existing `--no-admin` / `--no-rhai` already work; the new flags are CLI-binary edits, not scaffolder logic. Will be its own small commit if needed before the PR opens. - **Renaming `_rhai` to a different suffix** — the issue body doesn't ask for this; current `_rhai` matches the existing pattern. - **Acceptance test `cargo build && lab infocheck`** — `cargo build` against the scaffolded workspace can't pass in CI today because the generated crates pin `hero_lifecycle` / `hero_admin_lib` to `branch = "development"`, and #55's `hero_lifecycle` rename hasn't merged yet. Will pass automatically once #55 merges to `development`. `lab infocheck` *does* pass right now (it only needs `cargo metadata`, not a full build). ### Branch [`issue-54-scaffold-extend`](https://forge.ourworld.tf/lhumina_code/hero_rpc/src/branch/issue-54-scaffold-extend) — based on `issue-55-codegen-alignment`. Should be merged via PR **after** the #55 PR lands on `development` (or rebased onto `development` if #55 is merged first).

timur referenced this issue from lhumina_code/hero_skills 2026-05-19 02:41:59 +00:00

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

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

development

issue-60-method-translators

issue-54-scaffold-extend

issue-55-codegen-alignment

development_refactor_list_full

fix/input-schema-and-find

main

development_jan

v0.1.0

Labels

Clear labels   

prio_critical

  

prio_low

  

type_bug

  

type_contact

  

type_issue

  

type_lead

  

type_question

  

type_story

  

type_task

No labels

prio_critical

prio_low

type_bug

type_contact

type_issue

type_lead

type_question

type_story

type_task

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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#54

No description provided.