Upgrade example/recipe_server to end-to-end demo (#57, rebased) #66

Merged

timur merged 1 commit from pr-57-rebased into development

2026-05-19 15:29:24 +00:00

timur commented

2026-05-19 15:29:21 +00:00

Owner

Closes #57. Rebased onto current development (post-#59 merge). Resolved 2 modify/delete conflicts by accepting deletion (agent restructured into 5-crate workspace).

timur added 1 commit

2026-05-19 15:29:21 +00:00

example(recipe_server): scaffolded 5-crate workspace + filled trait + admin demo (#57 )

Test / test (pull_request) Failing after 2m9s

Details

Test / test (push) Failing after 2m21s

Details

25e3e24d05

Replaces the legacy single-crate example with the canonical
"scaffold → fill stubs → build → run" demo:

- Removed from the hero_rpc parent workspace (now `exclude`d). The
  `example/recipe_server/` directory is its own independent workspace,
  exactly as `hero_rpc_generator --name hero_recipes` would produce
  in a user's own repo.
- Scaffolded via the existing `hero_rpc_generator` CLI — yields
  `hero_recipes`, `hero_recipes_server`, `hero_recipes_sdk`,
  `hero_recipes_rhai`, `hero_recipes_admin`, `hero_recipes_examples`.
- Each binary crate carries its own `service.toml`; the `_server`
  main.rs uses `service_base!()` + `validate_service_toml` +
  `handle_info_flag` + `print_startup_banner` + `prepare_sockets`
  per #55 §5.
- `[patch."https://forge.ourworld.tf/lhumina_code/hero_rpc.git"]`
  on the workspace `Cargo.toml` maps the published git deps to the
  in-tree `crates/*` so the demo compiles against current source
  without forcing the same patches on downstream users.
- `RecipeServiceTrait` impl fills the three scaffolded `todo!()`
  stubs (`get_by_category`, `get_by_difficulty`, `add_to_collection`)
  — demonstrates both read-only CRUD-composing methods and
  cross-object business logic.
- `hero_recipes_admin` consumes `hero_admin_lib` for the standard
  `/health`, `/.well-known/heroservice.json`, asset, and middleware
  surface, plus a recipes-specific `/recipes` page that embeds
  `<hero-api-docs>` against the build-time-embedded OpenRPC spec.
- README walks through the scaffold → fill → build → `lab service
  start` flow and documents the AI-driven variant.
- `example/README.md` index explains when to use each example
  (recipe_server vs. recipe_sdk_rpc2 vs. petstore_*).
- `lab infocheck` reports `hero_recipes_server` and
  `hero_recipes_admin` clean; the four pre-existing failures
  elsewhere in hero_rpc (generator, hero_lifecycle, petstore_*)
  are out of scope.

Acceptance for hero_rpc#57:
- `cargo build --workspace` clean (both inner + parent workspace)
- `hero_recipes_server --info` / `--info --json` valid
- Live test: `recipe.list` + `RecipeService.get_by_category` round
  trip over UDS; `/health`, `/openrpc.json` (26 methods),
  `/.well-known/heroservice.json` all respond.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

timur merged commit ab14b20a8e into development

2026-05-19 15:29:24 +00:00

timur referenced this pull request from a commit

2026-05-19 15:29:25 +00:00

Upgrade example/recipe_server to end-to-end demo (#57, rebased) (#66)

timur referenced this pull request from lhumina_code/hero_skills

2026-05-19 15:31:15 +00:00

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