hero_rpc#129: re-scaffold against new generator (examples/, benches/, serial_test) #13
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "issue-129-rescaffold"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Re-scaffold of hero_service against the hero_rpc#129 generator. Picks up the three default-on emissions the new scaffolder ships:
examples/workspace member with01_connect.rs(SDK demo)benches/workspace member with commented-out criterion skeletontests/Cargo.toml[dev-dependencies] serial_test = "3"Must merge last — depends on hero_rpc PR #139 (scaffolder additions) and hero_skills PR #302 (
--example/--bench/ dual-home--testverbs).Acceptance evidence
(14 pre-existing async-trait warnings in
hero_service_serverare unrelated — introduced by hero_rpc#138 and tracked separately.)Diff stat
Zero changes under
crates/hero_service*,sdk/*,schemas/,data/, ortests/src/lib.rs— those files are scaffolder-managed and contributors' edits are preserved on re-scaffold.Decisions taken without confirmation
The example imports
hero_service_sdk::bench::BenchClientand callsBenchClient::indexed_multi_list— the first rootobject the generator discovers when iterating(domain_alphabetical, snake_alphabetical).benchcomes alphabetically beforecatalog;indexed_multiis alphabetically first insidebench. If a more interesting demo is wanted, the file is preserve-once — edit it once and the scaffolder won't overwrite.tests/Cargo.tomlgot a hand-edit for[dev-dependencies] serial_test = "3"because the existing file is preserve-once. The block landed between[dependencies]and the first[[test]], so the build-timesync_tests_cargo_tomlrewriter (which cuts from the first[[test]]line onward) preserves it.The workspace
Cargo.tomlgot"examples"and"benches"appended explicitly rather than via a scaffolder-managed regen. Same preserve-once rationale — and the explicit edit is small enough that teaching the scaffolder to merge workspace members on rerun is out of scope.Test plan
cargo check --workspace --all-targets— greencargo check -p hero_service_examples— greencargo check -p hero_service_benches— greenlab service hero_service --examplelists01_connectlab service hero_service --example 01_connectend-to-end (requires installedhero_service_serverbinary; deferred — same dispatch shape verified by hero_skills PR's unit tests + the listing case above)lab service hero_service --test5 layers green (no regression vs hero_rpc#124) — deferred to post-merge full CI runCloses part of hero_rpc#129 (Phase 4).
Re-scaffold of hero_service against the hero_rpc#129 generator. Picks up three new pieces that the scaffolder now emits by default: examples/ workspace member `hero_service_examples` Cargo.toml [[example]] 01_connect path = "01_connect.rs" src/lib.rs wrapper crate (no shared code) 01_connect.rs ~30-line SDK demo — connects via HERO_TEST_SOCKET, calls indexed_multi_list on the first discovered rootobject benches/ workspace member `hero_service_benches` Cargo.toml [[bench]] template (commented out) src/lib.rs pub use hero_service_tests::* example_bench.rs commented-out criterion skeleton tests/Cargo.toml + [dev-dependencies] serial_test = "3" Plus the matching workspace member list edit (`Cargo.toml` adds `"examples"` and `"benches"`) — preserve-once meant the existing workspace Cargo.toml wasn't rewritten by the scaffold rerun. Acceptance evidence ------------------- $ PATH_ROOT=$HOME/hero lab service hero_service --example lab service hero_service --example: available examples 01_connect (examples/) $ cargo check --workspace --all-targets Finished `dev` profile [unoptimized + debuginfo] target(s) in 26.10s (The pre-existing 14 warnings in hero_service_server are unrelated to this re-scaffold — they're async-trait migrations introduced by hero_rpc#138 and tracked separately.) The hero_skills PR landing alongside this one adds the `--example` / `--bench` / dual-home `--test` dispatch; this PR just consumes the default-on shapes the generator now emits. No code in `crates/hero_service*`, `sdk/*`, or `tests/src/lib.rs` was touched — those files are scaffolder-managed and contributors' edits are preserved on re-scaffold. Decisions taken without confirmation ------------------------------------ 1. The example imports `hero_service_sdk::bench::BenchClient` and calls `BenchClient::indexed_multi_list` — the first rootobject the generator discovers when iterating `(domain, snake_lex_sort)`. Catalog comes alphabetically after `bench`; `indexed_multi` is the alphabetically-first rootobject inside `bench`. If anyone wants a more interesting demo (`service_definition_list_full` over the catalog domain, say), the file is preserve-once — edit it once and the scaffolder won't overwrite. 2. `tests/Cargo.toml` got a hand-edit for `[dev-dependencies] serial_test = "3"` because the existing file is preserve-once. For brand-new services scaffolded after this PR, the generator emits the dev-dep automatically. The `[dev-dependencies]` block landed between `[dependencies]` and the first `[[test]]` so the build-time `sync_tests_cargo_toml` rewriter (which cuts from the first `[[test]]` line onward) keeps it untouched. 3. The workspace `Cargo.toml` got `"examples"` and `"benches"` appended explicitly rather than via a scaffolder-managed regeneration of the workspace manifest. Same preserve-once rationale — and the explicit edit is small enough that the alternative (teaching the scaffolder to "merge" workspace members on rerun) is out of scope for this PR.