Upgrade example/recipe_server to end-to-end new-pattern demo (#57) #65

Closed

timur wants to merge 1 commit from issue-57-recipe-server-e2e into development

timur commented

2026-05-19 15:28:17 +00:00

Owner

Closes #57. Regenerates recipe_server as 5-crate workspace via scaffolder; lab infocheck clean; live JSON-RPC works.

timur added 1 commit

2026-05-19 15:28:17 +00:00

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

Test / test (push) Failing after 2m14s

Details

Test / test (pull_request) Failing after 3m15s

Details

13ee65cd01

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 closed this pull request

2026-05-19 15:28:48 +00:00

timur referenced this pull request

2026-05-21 16:14:23 +00:00

Generator: unify SDK ↔ server types and seeding (single source of truth) #117