modernize ai_rhai for broker-first herolib_ai (child of home#219) #16

New issue

Open

opened 2026-05-06 18:02:31 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-06 18:02:31 +00:00

Owner

Overview

crates/ai_rhai is bound to the pre-rewrite herolib_ai API. After the broker-first AI architecture landed on hero_lib (commit lhumina_code/hero_lib@bb69b40a refactor(ai): rewrite as broker-first architecture), this binding crate no longer compiles against current hero_lib development.

This is a child task of home#219 — apps consume LLM/voice via hero_lib AI client → hero_aibroker. hero_lib_rhai is in the same offender bucket as hero_biz#15 — it instantiates a Rhai surface against the old client.

How this surfaced

Filed during session 65 of the home#212 build-binaries arc. PR #15 unblocked the first CI release by rev-pinning all 14 herolib_* deps to commit ab985c901e591e69c06fd0abd924a6159c8cc77d (the merge point of the deleted development_casper branch). That kept v0.1.0-rc2 bit-identical to the last known-good source state but preserves the pre-rewrite API debt.

When we switched the deps to branch = "development" to test, cargo check --workspace returned 39 errors in crates/ai_rhai/src/lib.rs clustered into a few API-change patterns:

Old (pre-rewrite)	New (current development)
`client.generate_image_to_file(model, prompt, path, config)`	`client.generate_image(...)` returns `ImageGenerationResponse`; file save now goes through the response object (see `lhumina_code/hero_lib@633810f6` `feat(ai): ImageRef enum with sync URL/path/bytes resolution` and `lhumina_code/hero_lib@19ffd708` `feat(ai): image generation builder with local-file & multi-image support`)
`Model::all()` (iterator over registered models)	Removed — `Model` is no longer iterable. Replaced by `Model::new(...)` / `Model::pinned(...)`.
`Model::name()` (and several closure-typed `.map(\|m\| ...)` callsites)	Type signature changed; closures no longer infer.
Direct provider-specific calls	Should now go through `hero_aibroker`.

Acceptance

crates/ai_rhai/src/lib.rs compiles against current hero_lib development HEAD
cargo check --workspace --target x86_64-unknown-linux-musl clean
All 14 herolib_* deps in Cargo.toml switched from rev = "ab985c9…" back to branch = "development" (matching herolib_core and the other workspace deps)
Rhai-side AI surface routes through hero_aibroker (not direct providers), per home#219
CI run on a fresh tag publishes 4 release assets without dep-resolution errors
Issue closed by referencing the PR that lifts the rev-pin

META: lhumina_code/home#219
Parent build-binaries META: lhumina_code/home#212
Unblock PR (the rev-pin workaround): #15
Sister offender: lhumina_code/hero_biz#15

## Overview `crates/ai_rhai` is bound to the **pre-rewrite** `herolib_ai` API. After the broker-first AI architecture landed on `hero_lib` (commit https://forge.ourworld.tf/lhumina_code/hero_lib/commit/bb69b40a `refactor(ai): rewrite as broker-first architecture`), this binding crate no longer compiles against current `hero_lib` development. This is a child task of [home#219 — apps consume LLM/voice via hero_lib AI client → hero_aibroker](https://forge.ourworld.tf/lhumina_code/home/issues/219). hero_lib_rhai is in the same offender bucket as [hero_biz#15](https://forge.ourworld.tf/lhumina_code/hero_biz/issues/15) — it instantiates a Rhai surface against the old client. ## How this surfaced Filed during session 65 of the home#212 build-binaries arc. PR https://forge.ourworld.tf/lhumina_code/hero_lib_rhai/pulls/15 unblocked the first CI release by **rev-pinning** all 14 `herolib_*` deps to commit `ab985c901e591e69c06fd0abd924a6159c8cc77d` (the merge point of the deleted `development_casper` branch). That kept v0.1.0-rc2 bit-identical to the last known-good source state but preserves the pre-rewrite API debt. When we switched the deps to `branch = "development"` to test, `cargo check --workspace` returned **39 errors in `crates/ai_rhai/src/lib.rs`** clustered into a few API-change patterns: | Old (pre-rewrite) | New (current development) | |---|---| | `client.generate_image_to_file(model, prompt, path, config)` | `client.generate_image(...)` returns `ImageGenerationResponse`; file save now goes through the response object (see https://forge.ourworld.tf/lhumina_code/hero_lib/commit/633810f6 `feat(ai): ImageRef enum with sync URL/path/bytes resolution` and https://forge.ourworld.tf/lhumina_code/hero_lib/commit/19ffd708 `feat(ai): image generation builder with local-file & multi-image support`) | | `Model::all()` (iterator over registered models) | Removed — `Model` is no longer iterable. Replaced by `Model::new(...)` / `Model::pinned(...)`. | | `Model::name()` (and several closure-typed `.map(\|m\| ...)` callsites) | Type signature changed; closures no longer infer. | | Direct provider-specific calls | Should now go through `hero_aibroker`. | ## Acceptance - [ ] `crates/ai_rhai/src/lib.rs` compiles against current `hero_lib` `development` HEAD - [ ] `cargo check --workspace --target x86_64-unknown-linux-musl` clean - [ ] All 14 `herolib_*` deps in `Cargo.toml` switched from `rev = "ab985c9…"` back to `branch = "development"` (matching `herolib_core` and the other workspace deps) - [ ] Rhai-side AI surface routes through `hero_aibroker` (not direct providers), per home#219 - [ ] CI run on a fresh tag publishes 4 release assets without dep-resolution errors - [ ] Issue closed by referencing the PR that lifts the rev-pin ## Related - META: https://forge.ourworld.tf/lhumina_code/home/issues/219 - Parent build-binaries META: https://forge.ourworld.tf/lhumina_code/home/issues/212 - Unblock PR (the rev-pin workaround): https://forge.ourworld.tf/lhumina_code/hero_lib_rhai/pulls/15 - Sister offender: https://forge.ourworld.tf/lhumina_code/hero_biz/issues/15