lhumina_code/home_lhumina
0
0
Fork 0
Code Issues 79 Pull requests Projects Releases Packages Wiki Activity Actions

[platform] Converge every service to the development shape: Dioxus admin, oschema backend, voice, agent #313

New issue
Open
opened 2026-06-23 19:15:29 +00:00 by mik-tf · 7 comments
mik-tf commented 2026-06-23 19:15:29 +00:00
Owner
Copy link

Index issue for bringing every service to the same shape on the development branch. This is the tracker only; each piece of work is a short story in the relevant repo, linked below.

Target shape for every service:

  1. Admin UI is the shared Dioxus UI (hero_components), opened with ?service= through the router, and styled with dioxus-bootstrap-css (typed components, no raw Bootstrap).
  2. Backend is oschema based.
  3. The voice widget is present in the admin UI (the widget is served by hero_voice).
  4. The agent is integrated (the agent widget is served by hero_orchestrator).

Backend exceptions that stay on OSIS (do not move to oschema): hero_planner, hero_biz, cm50.

Stories per service:

Platform repos (bring onto the development branch):

Shared engines (move backend to oschema, in progress by Kristof):

  • hero_embedder_provider
  • hero_voice_provider

Already done: Dioxus admin panes for hero_biz, hero_planner, hero_kimi; development publish for hero_router, hero_cockpit, hero_components, hero_proxy.

Background: this replaces the longer write up in #309.

Signed-by: mik-tf mik-tf@noreply.invalid

Index issue for bringing every service to the same shape on the development branch. This is the tracker only; each piece of work is a short story in the relevant repo, linked below. Target shape for every service: 1. Admin UI is the shared Dioxus UI (hero_components), opened with ?service=<name> through the router, and styled with dioxus-bootstrap-css (typed components, no raw Bootstrap). 2. Backend is oschema based. 3. The voice widget is present in the admin UI (the widget is served by hero_voice). 4. The agent is integrated (the agent widget is served by hero_orchestrator). Backend exceptions that stay on OSIS (do not move to oschema): hero_planner, hero_biz, cm50. Stories per service: - [ ] hero_biz: voice lhumina_code/hero_biz#57, agent lhumina_code/hero_biz#58 - [ ] hero_planner: voice lhumina_code/hero_planner#35, agent lhumina_code/hero_planner#36 - [ ] hero_kimi: voice lhumina_code/hero_kimi_rust#13, agent lhumina_code/hero_kimi_rust#14 (oschema backend in progress) - [ ] cm50: admin coopcloud_code/cm50_app#3, voice coopcloud_code/cm50_app#4, agent coopcloud_code/cm50_app#5 - [ ] hero_books: oschema lhumina_code/hero_books#154, admin lhumina_code/hero_books#155, voice lhumina_code/hero_books#156, agent lhumina_code/hero_books#157 - [ ] hero_agent: oschema lhumina_code/hero_agent#29, admin lhumina_code/hero_agent#30 - [ ] hero_matrixchat: oschema lhumina_code/hero_matrixchat#9, admin lhumina_code/hero_matrixchat#10, voice lhumina_code/hero_matrixchat#11, agent lhumina_code/hero_matrixchat#12 - [ ] hero_shrimp: oschema lhumina_code/hero_shrimp#182, admin lhumina_code/hero_shrimp#183, voice lhumina_code/hero_shrimp#184, agent lhumina_code/hero_shrimp#185 Platform repos (bring onto the development branch): - [ ] hero_os_tfgrid_deployer: lhumina_code/hero_os_tfgrid_deployer#30 - [ ] hero_cockpit: lhumina_code/hero_cockpit#14 Shared engines (move backend to oschema, in progress by Kristof): - [ ] hero_embedder_provider - [ ] hero_voice_provider Already done: Dioxus admin panes for hero_biz, hero_planner, hero_kimi; development publish for hero_router, hero_cockpit, hero_components, hero_proxy. Background: this replaces the longer write up in #309. Signed-by: mik-tf <mik-tf@noreply.invalid>
mik-tf commented 2026-06-23 19:29:27 +00:00
Author
Owner
Copy link

Proposed owners for the stories above. This is a starting suggestion, not a hard assignment, so please check yourself and take ownership of any issues you want.

  • hero_os_tfgrid_deployer and hero_cockpit: mik-tf.
  • hero_shrimp (the agent): Thabet and Ahmed.
  • hero_kimi: Kristof, who is already finishing the oschema backend in that repo.
  • hero_embedder_provider and hero_voice_provider: Kristof, migrating both off the old stack to oschema now.
  • hero_voice (the voice widget) and hero_orchestrator (the agent widget): Scott. Every voice and agent story across the services embeds these two, so Scott owns the widgets and is the contact for the voice and agent dimensions.
  • Admin UI styling with dioxus-bootstrap-css (typed components, no raw Bootstrap), across every Dioxus admin pane: mik-tf.
  • The Dioxus admin pane and oschema backend work on hero_books, hero_matrixchat, hero_agent, and cm50: Scott and Mahmoud and team.

Signed-by: mik-tf mik-tf@noreply.invalid

Proposed owners for the stories above. This is a starting suggestion, not a hard assignment, so please check yourself and take ownership of any issues you want. - hero_os_tfgrid_deployer and hero_cockpit: mik-tf. - hero_shrimp (the agent): Thabet and Ahmed. - hero_kimi: Kristof, who is already finishing the oschema backend in that repo. - hero_embedder_provider and hero_voice_provider: Kristof, migrating both off the old stack to oschema now. - hero_voice (the voice widget) and hero_orchestrator (the agent widget): Scott. Every voice and agent story across the services embeds these two, so Scott owns the widgets and is the contact for the voice and agent dimensions. - Admin UI styling with dioxus-bootstrap-css (typed components, no raw Bootstrap), across every Dioxus admin pane: mik-tf. - The Dioxus admin pane and oschema backend work on hero_books, hero_matrixchat, hero_agent, and cm50: Scott and Mahmoud and team. Signed-by: mik-tf <mik-tf@noreply.invalid>
mik-tf commented 2026-06-23 22:44:53 +00:00
Author
Owner
Copy link

Current dev-admin lane update:

The deployer convergence work preserved the good integration base by working from a branch where origin/integration is an ancestor, then replaying the development-stack layer. The immediate compile blocker is now upstream in hero_proc: the new multi-domain secrets OpenRPC API is core-only, but deployer provisioning requires context-scoped secrets.

New blocker issue: lhumina_code/hero_proc#163

Execution order from here:

  1. Restore context-aware secrets on hero_proc development while keeping the new multi-domain route shape and one-input OpenRPC rule.
  2. Update deployer to consume the context-aware hero_proc_sdk methods.
  3. Finish deployer development convergence and install-manifest fixes.
  4. Converge cockpit to the development stack.
  5. Publish development-channel deployer/cockpit.
  6. Use the dev deployer to provision the blue-green mainnet admin VM and member instances for the Hero Explorers organization, with gent02 gateway node 8 in the target route plan.

Signed-by: mik-tf mik-tf@noreply.invalid

Current dev-admin lane update: The deployer convergence work preserved the good `integration` base by working from a branch where `origin/integration` is an ancestor, then replaying the development-stack layer. The immediate compile blocker is now upstream in `hero_proc`: the new multi-domain secrets OpenRPC API is core-only, but deployer provisioning requires context-scoped secrets. New blocker issue: https://forge.ourworld.tf/lhumina_code/hero_proc/issues/163 Execution order from here: 1. Restore context-aware secrets on `hero_proc` development while keeping the new multi-domain route shape and one-input OpenRPC rule. 2. Update deployer to consume the context-aware `hero_proc_sdk` methods. 3. Finish deployer development convergence and install-manifest fixes. 4. Converge cockpit to the development stack. 5. Publish development-channel deployer/cockpit. 6. Use the dev deployer to provision the blue-green mainnet admin VM and member instances for the Hero Explorers organization, with gent02 gateway node 8 in the target route plan. Signed-by: mik-tf <mik-tf@noreply.invalid>
mik-tf commented 2026-06-23 23:13:37 +00:00
Author
Owner
Copy link

Arc update:

  • The secret-store blocker has a concrete fix on hero_proc branch development_mik_secrets_context: context-aware generated API restored over the existing (context_name, key) storage model, with CLI context support and a restored context-isolation functional case.
  • Deployer branch development_mik has been moved to the restored API shape and verified against the local hero_proc branch using a non-persistent Cargo patch.
  • Integration work is still preserved in deployer: origin/integration is an ancestor of development_mik.

Remaining order is now mechanical: land/publish hero_proc#163 to development, refresh deployer against that SDK from Forge development, then continue cockpit convergence and the Hero Explorers mainnet admin/member deployment path.

Signed-by: mik-tf mik-tf@noreply.invalid

Arc update: - The secret-store blocker has a concrete fix on hero_proc branch development_mik_secrets_context: context-aware generated API restored over the existing (context_name, key) storage model, with CLI context support and a restored context-isolation functional case. - Deployer branch development_mik has been moved to the restored API shape and verified against the local hero_proc branch using a non-persistent Cargo patch. - Integration work is still preserved in deployer: origin/integration is an ancestor of development_mik. Remaining order is now mechanical: land/publish hero_proc#163 to development, refresh deployer against that SDK from Forge development, then continue cockpit convergence and the Hero Explorers mainnet admin/member deployment path. Signed-by: mik-tf <mik-tf@noreply.invalid>
mik-tf commented 2026-06-24 06:32:48 +00:00
Author
Owner
Copy link

Development-channel mainnet proof is live.

Current result:

  • Hero Explorers organization exists in deployer with stack Hero Explorers Development on latest-development and apps hero_biz, hero_planner, hero_kimi.
  • Three Forge users were created: heroexplorer01, heroexplorer02, heroexplorer03.
  • Three member VMs are running on mainnet node 8 / gent02 and are install_state=ready:
  • The local admin machine is running the hardened deployer/cockpit path against mainnet compute twin 14199.
  • The old integration/testing-org path was not touched.

Notes:

  • Node 7084 was checked but is currently down/unhealthy; node 8 was used with explicit shared-mainnet placement gates.
  • Final deployer release run 30022 is still running for commit 1218f91; the deployed local admin already has that final server installed.
  • Follow-ups: prove a fresh member install from the final published deployer release, decide whether to add hero_db_server to the release set, and decide whether hero_kimi_web should be part of the default stack or only the running Kimi Rust server.

Signed-by: mik-tf mik-tf@noreply.invalid

Development-channel mainnet proof is live. Current result: - Hero Explorers organization exists in deployer with stack `Hero Explorers Development` on `latest-development` and apps `hero_biz`, `hero_planner`, `hero_kimi`. - Three Forge users were created: `heroexplorer01`, `heroexplorer02`, `heroexplorer03`. - Three member VMs are running on mainnet node 8 / gent02 and are `install_state=ready`: - https://heroexplorer01.gent02.grid.tf - https://heroexplorer02.gent02.grid.tf - https://heroexplorer03.gent02.grid.tf - The local admin machine is running the hardened deployer/cockpit path against mainnet compute twin `14199`. - The old integration/testing-org path was not touched. Notes: - Node 7084 was checked but is currently down/unhealthy; node 8 was used with explicit shared-mainnet placement gates. - Final deployer release run 30022 is still running for commit `1218f91`; the deployed local admin already has that final server installed. - Follow-ups: prove a fresh member install from the final published deployer release, decide whether to add `hero_db_server` to the release set, and decide whether `hero_kimi_web` should be part of the default stack or only the running Kimi Rust server. Signed-by: mik-tf <mik-tf@noreply.invalid>
mahmoud commented 2026-06-24 07:43:24 +00:00
Owner
Copy link

Re-index — oschema backend + Dioxus admin UI status

Re-checked every service in this tracker against the current development branch today, so the index reflects what's actually landed (not stale checkouts). Method: git grep for openrpc_server! / serve_domains vs hero_rpc_derive on the freshly-fetched origin/development ref, plus the Forge tree API for repos I don't have cloned, cross-checked against the canonical skills (hero_server_migration, hero_admin_ui).

Backend → oschema (new openrpc_server! + serve_domains stack, served at /api/{domain}/rpc)

Service Status on development
hero_kimi (hero_kimi_rust) ✅ done — openrpc_server! + serve_domains + oschema/main/* (ahead of the "in progress" note)
hero_books #154 ❌ still hero_rpc_derive / OSIS (osis_server_generated.rs)
hero_agent #29 ❌ still hero_rpc_derive, no oschema
hero_matrixchat #9 ❌ no _server crate yet; only a legacy schema/service.oschema
hero_shrimp #182 ❌ still hero_rpc_derive, no oschema

Exceptions staying on OSIS (correct as-is): hero_planner, hero_biz, cm50.
Shared engines (Kristof): hero_embedder still on hero_rpc_derive; hero_voice_provider not verified here.

Dioxus admin UI (panes in hero_components)

✅ Present today: hero_biz, hero_planner, hero_kimi (the three credited above) plus hero_voice, hero_aibroker, hero_collab, hero_proxy, hero_whiteboard, hero_browser, and the hero_router/hero_proc operational consoles.
❌ Missing: hero_books #155, hero_agent #30, hero_matrixchat #10, hero_shrimp #183, cm50 #3.

Correction to the index

  • hero_whiteboard is already migrated to the new oschema stack on development (openrpc_server! + serve_domains + oschema/main/) — flagging in case the tracker assumed otherwise.

Bottom line

The four services needing both dimensions are hero_books, hero_agent, hero_matrixchat, hero_shrimp; cm50 needs the admin pane only (backend stays OSIS). Cross-cutting gaps that still apply everywhere: the voice widget is not embedded shell-wide (only hero_voice has a demo tab), and the no-raw-bootstrap styling gate (tools/check-no-raw-bootstrap.mjs) is not in CI.

Please correct me on any repo I've mis-read — happy to re-verify.

## Re-index — oschema backend + Dioxus admin UI status Re-checked every service in this tracker against the current `development` branch today, so the index reflects what's actually landed (not stale checkouts). **Method:** `git grep` for `openrpc_server!` / `serve_domains` vs `hero_rpc_derive` on the freshly-fetched `origin/development` ref, plus the Forge tree API for repos I don't have cloned, cross-checked against the canonical skills (`hero_server_migration`, `hero_admin_ui`). ### Backend → oschema (new `openrpc_server!` + `serve_domains` stack, served at `/api/{domain}/rpc`) | Service | Status on `development` | |---|---| | hero_kimi (hero_kimi_rust) | ✅ **done** — `openrpc_server!` + `serve_domains` + `oschema/main/*` (ahead of the "in progress" note) | | hero_books #154 | ❌ still `hero_rpc_derive` / OSIS (`osis_server_generated.rs`) | | hero_agent #29 | ❌ still `hero_rpc_derive`, no oschema | | hero_matrixchat #9 | ❌ no `_server` crate yet; only a legacy `schema/service.oschema` | | hero_shrimp #182 | ❌ still `hero_rpc_derive`, no oschema | **Exceptions staying on OSIS (correct as-is):** hero_planner, hero_biz, cm50. **Shared engines (Kristof):** hero_embedder still on `hero_rpc_derive`; hero_voice_provider not verified here. ### Dioxus admin UI (panes in `hero_components`) ✅ **Present today:** hero_biz, hero_planner, hero_kimi (the three credited above) **plus** hero_voice, hero_aibroker, hero_collab, hero_proxy, hero_whiteboard, **hero_browser**, and the hero_router/hero_proc operational consoles. ❌ **Missing:** hero_books #155, hero_agent #30, hero_matrixchat #10, hero_shrimp #183, cm50 #3. ### Correction to the index - **hero_whiteboard** is **already migrated** to the new oschema stack on `development` (`openrpc_server!` + `serve_domains` + `oschema/main/`) — flagging in case the tracker assumed otherwise. ### Bottom line The four services needing **both** dimensions are **hero_books, hero_agent, hero_matrixchat, hero_shrimp**; **cm50** needs the admin pane only (backend stays OSIS). Cross-cutting gaps that still apply everywhere: the **voice widget is not embedded shell-wide** (only hero_voice has a demo tab), and the no-raw-bootstrap styling gate (`tools/check-no-raw-bootstrap.mjs`) is **not in CI**. Please correct me on any repo I've mis-read — happy to re-verify.
mahmoud commented 2026-06-24 07:43:24 +00:00
Owner
Copy link

hero_browser ✅ done · taking hero_books next

hero_browser is fully converged and merged to development (tracked under #309):

  • Backend → oschema: server migrated to openrpc_server! + serve_domains (single main domain at /api/main/rpc, 47 methods, verbatim snake_case names); _sdk regenerated with hero_lib's openrpc_client! (not the legacy hero_rpc_derive); _test suite green.
  • Dioxus admin: Sessions + Activity panes live in hero_components (with the pool's session/page/capacity stats), typed dioxus-bootstrap-css only.
  • Cleanup: the old Askama hero_browser_admin crate has been removed (after the hero_components pane reached parity), incl. workspace member, CLI wiring, admin.sock, and docs.

I'm taking hero_books next (#154 oschema, #155 admin).

hero_books — current status (recon on development)

  • Backend: still OSIS — crates/hero_books_lib/.../osis_server_generated.rs, hero_rpc_derive in the workspace + _sdk. Authoritative spec at crates/hero_books_server/openrpc.json. Not on openrpc_server! yet.
  • Good news: the .oschema schemas largely already exist — specs/schemas/publishing/* (book, page, site, theme, navigation, icon, ontology, …) and specs/schemas/webservice/* (admin, books, import, pdf, search). So schema authoring is mostly a reconcile-and-point job, not from scratch.
  • Admin: old Askama hero_books_admin crate present; no hero_components pane yet.
  • Consumers to regenerate: hero_books_sdk (→ hero_lib openrpc_client!), hero_books_admin proxy, hero_books_examples, the web crate.

Plan (following hero_server_migration + hero_admin_ui, same shape as hero_browser)

  1. Step-0 recon + decisions: domain layout (publishing rootobjects + webservice groups admin/books/import/pdf/search → one main vs multi-domain), wire-name rename, [rootobject]-over-existing-store, daemon lifecycle, scope.
  2. Point openrpc_server! at the existing oschema → generate trait/types/spec; diff against openrpc.json.
  3. Port handler bodies into rpc/*_impl.rs; delete OSIS/dispatcher; regen _sdk; fix _test.
  4. Add the hero_books admin pane in hero_components (tabs_for), then retire hero_books_admin after parity + sign-off.

Will share the concrete schema/domain proposal after Step-0 recon before writing code.

## hero_browser ✅ done · taking hero_books next **hero_browser is fully converged and merged to `development`** (tracked under #309): - **Backend → oschema:** server migrated to `openrpc_server!` + `serve_domains` (single `main` domain at `/api/main/rpc`, 47 methods, verbatim snake_case names); `_sdk` regenerated with hero_lib's `openrpc_client!` (not the legacy `hero_rpc_derive`); `_test` suite green. - **Dioxus admin:** Sessions + Activity panes live in `hero_components` (with the pool's session/page/capacity stats), typed `dioxus-bootstrap-css` only. - **Cleanup:** the old Askama `hero_browser_admin` crate has been **removed** (after the hero_components pane reached parity), incl. workspace member, CLI wiring, `admin.sock`, and docs. **I'm taking hero_books next** (#154 oschema, #155 admin). ### hero_books — current status (recon on `development`) - **Backend:** still OSIS — `crates/hero_books_lib/.../osis_server_generated.rs`, `hero_rpc_derive` in the workspace + `_sdk`. Authoritative spec at `crates/hero_books_server/openrpc.json`. **Not** on `openrpc_server!` yet. - **Good news:** the `.oschema` schemas largely **already exist** — `specs/schemas/publishing/*` (book, page, site, theme, navigation, icon, ontology, …) and `specs/schemas/webservice/*` (admin, books, import, pdf, search). So schema authoring is mostly a reconcile-and-point job, not from scratch. - **Admin:** old Askama `hero_books_admin` crate present; no `hero_components` pane yet. - **Consumers to regenerate:** `hero_books_sdk` (→ hero_lib `openrpc_client!`), `hero_books_admin` proxy, `hero_books_examples`, the web crate. ### Plan (following `hero_server_migration` + `hero_admin_ui`, same shape as hero_browser) 1. Step-0 recon + decisions: **domain layout** (publishing rootobjects + webservice groups admin/books/import/pdf/search → one `main` vs multi-domain), wire-name rename, `[rootobject]`-over-existing-store, daemon lifecycle, scope. 2. Point `openrpc_server!` at the existing oschema → generate trait/types/spec; diff against `openrpc.json`. 3. Port handler bodies into `rpc/*_impl.rs`; delete OSIS/dispatcher; regen `_sdk`; fix `_test`. 4. Add the hero_books admin pane in `hero_components` (`tabs_for`), then retire `hero_books_admin` after parity + sign-off. Will share the concrete schema/domain proposal after Step-0 recon before writing code.
mahmoud commented 2026-06-24 11:37:14 +00:00
Owner
Copy link

Dev-branch dependency audit — Cargo.toml deps not tracking development

Audited every hero repo's development branch for forge git deps not on branch = "development" (the policy: on development we track development at the tip). Filed a tracking issue per offender:

Pinned to main (stale — should flip to development):

Deliberately frozen on hero_macros_previous / rev-pins (need a full de-freeze / oschema migration):

Already in flight:

Everything else audited (hero_components, hero_lib, hero_proc, hero_router, hero_db, hero_whiteboard, hero_code, hero_skills, …) is clean on development.

### Dev-branch dependency audit — `Cargo.toml` deps not tracking `development` Audited every hero repo's `development` branch for forge git deps not on `branch = "development"` (the policy: on `development` we track `development` at the tip). Filed a tracking issue per offender: **Pinned to `main` (stale — should flip to `development`):** - lhumina_code/hero_aibroker#167 — `herolib_*`, `hero_lifecycle`, `hero_proc_sdk`, `hero_admin_lib`, `hero_archipelagos_core` (note: not a pure flip — `herolib_derive` is gone on dev → needs the oschema client migration) - lhumina_code/hero_codescalers#38 — `hero_admin_lib` **Deliberately frozen on `hero_macros_previous` / rev-pins (need a full de-freeze / oschema migration):** - lhumina_code/hero_compute#140 - lhumina_code/hero_os#161 **Already in flight:** - hero_books — fixed in lhumina_code/hero_books#158 (oschema migration + full de-freeze; PR open). hero_browser already merged. Everything else audited (hero_components, hero_lib, hero_proc, hero_router, hero_db, hero_whiteboard, hero_code, hero_skills, …) is clean on `development`.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
main
No results found.
Labels
Clear labels   
meeting-notes

Meeting notes and follow-ups

  
meeting-sensitive

Sensitive meeting; no shared archive or AI processing

  
meeting-transcript

Raw meeting transcript; AI drafts the report

  
platform

Hero platform work: the integrated stack + deployer/onboarding/gateway/admin/lab (the whole-product layer)

  
service

Hero service work: a feature/bug inside one app (slides, books, voice, biz, ...)

No labels
meeting-notes
meeting-sensitive
meeting-transcript
platform
service
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
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/home_lhumina#313
No description provided.