[META] Working services on the Hero Platform: each app installed, reachable from the desktop, and verified per member #304

Open
opened 2026-06-18 01:25:25 +00:00 by mik-tf · 5 comments
Owner

This issue replaces lhumina_code/home#239, which had grown into a long multi-session log. The onboarding and shared-engine plumbing it tracked is done; this is the clean current view of the remaining per-service work.

Current state

The Hero Platform is live: an admin instance plus member instances, with organizations, saved stacks and settings profiles, member onboarding, shared engines on the admin instance, and per-member data services. The Hero OS desktop now installs and updates itself on every member (lhumina_code/hero_os#159). What remains is making every Hero stack service a real working service behind the platform: installed where it belongs, reachable from the desktop, and verified on a member.

How we integrate each service (the repeatable pattern)

If we can hook the service to the platform end to end, we do it: install selection, inclusion in the build and service set, visibility in the cockpit Apps and Services pages with health, a desktop island, and the island actually reaching its backend. If we cannot finish it ourselves, we lay that integration base and the owning developers verify their service once it is wired. Each service gets its own actionable issue in its own repo, linked here. A backend may be member-local (reached over a local socket) or a shared engine on the admin instance (reached through hero_router over the authenticated overlay); the island must reach it the right way.

Status and open threads

Done means

Every app in the member bundle is installed where it belongs, opens from the desktop with its backend reachable, and has either been verified working or has its gap filed as its own issue with a clear scope.

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

This issue replaces https://forge.ourworld.tf/lhumina_code/home/issues/239, which had grown into a long multi-session log. The onboarding and shared-engine plumbing it tracked is done; this is the clean current view of the remaining per-service work. ## Current state The Hero Platform is live: an admin instance plus member instances, with organizations, saved stacks and settings profiles, member onboarding, shared engines on the admin instance, and per-member data services. The Hero OS desktop now installs and updates itself on every member (https://forge.ourworld.tf/lhumina_code/hero_os/issues/159). What remains is making every Hero stack service a real working service behind the platform: installed where it belongs, reachable from the desktop, and verified on a member. ## How we integrate each service (the repeatable pattern) If we can hook the service to the platform end to end, we do it: install selection, inclusion in the build and service set, visibility in the cockpit Apps and Services pages with health, a desktop island, and the island actually reaching its backend. If we cannot finish it ourselves, we lay that integration base and the owning developers verify their service once it is wired. Each service gets its own actionable issue in its own repo, linked here. A backend may be member-local (reached over a local socket) or a shared engine on the admin instance (reached through hero_router over the authenticated overlay); the island must reach it the right way. ## Status and open threads - Hero OS desktop: delivered and self-updating (https://forge.ourworld.tf/lhumina_code/hero_os/issues/159). - Islands reaching their backends (cross-service): https://forge.ourworld.tf/lhumina_code/home/issues/303; the desktop-side routing piece is https://forge.ourworld.tf/lhumina_code/hero_os/issues/160; the Contexts island backend is blocked on https://forge.ourworld.tf/lhumina_code/hero_osis/issues/66. - hero_office: next service to integrate (https://forge.ourworld.tf/lhumina_code/home/issues/275, https://forge.ourworld.tf/lhumina_code/home/issues/278). - Member app bundle and the cockpit Apps and Services surface: https://forge.ourworld.tf/lhumina_code/home/issues/278. - Remaining catalog apps each get a working-service pass and their own follow-up issue as we reach them. ## Done means Every app in the member bundle is installed where it belongs, opens from the desktop with its backend reachable, and has either been verified working or has its gap filed as its own issue with a clear scope. Signed-by: mik-tf <mik-tf@noreply.invalid>
Author
Owner

hero_office working-service integration: lhumina_code/hero_office#31

The install and catalog wiring already exists (hero_office is install-selectable and shows in the cockpit), and the binaries publish. The remaining work is the OnlyOffice editing engine: it now runs as one shared engine on the admin instance and is proven end to end there, with two follow-ups (serving it across separate member machines with an authenticated save callback, and deployer auto-seeding the engine settings per member). Setup is written up in the admin instance deployment runbook, Step 10.6.

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

hero_office working-service integration: https://forge.ourworld.tf/lhumina_code/hero_office/issues/31 The install and catalog wiring already exists (hero_office is install-selectable and shows in the cockpit), and the binaries publish. The remaining work is the OnlyOffice editing engine: it now runs as one shared engine on the admin instance and is proven end to end there, with two follow-ups (serving it across separate member machines with an authenticated save callback, and deployer auto-seeding the engine settings per member). Setup is written up in the admin instance deployment runbook, Step 10.6. Signed-by: mik-tf <mik-tf@noreply.invalid>
Author
Owner

Status on the OnlyOffice editor (hero_office) for working services on member instances.

Two underlying bugs were found and fixed, both merged to integration and live on the testing org:

  1. hero_foundry now creates a member's per context document store on first access instead of returning 404. The Documents app previously failed for every real member because foundry only ever seeded the system "core" context and nothing provisioned a per member context.
  2. The deployer now wires the OnlyOffice connector to each member's https FQDN instead of the member's mycelium [ipv6]:9997 address. OnlyOffice's URL parser rejects bracketed IPv6 literals (ERR_INVALID_URL), so the engine could never fetch documents or post the save callback.

The shared engine, the document fetch and convert, the JWT gate, and the per context store are all confirmed working live (the engine downloads and converts a real document from a member FQDN, and a forged token is rejected). One blocker remains before a member can actually open and edit in the desktop: the browser to engine realtime channel (OnlyOffice socket.io and websocket) does not complete through the member login floor, so the engine never receives the open command and the editor shows "Download failed". Filed as lhumina_code/hero_office#32

Separately, a member should land in their own named context (a default plus a context named for their username) rather than a leftover or shared one. Filed as lhumina_code/home#305

Status on the OnlyOffice editor (hero_office) for working services on member instances. Two underlying bugs were found and fixed, both merged to integration and live on the testing org: 1. hero_foundry now creates a member's per context document store on first access instead of returning 404. The Documents app previously failed for every real member because foundry only ever seeded the system "core" context and nothing provisioned a per member context. 2. The deployer now wires the OnlyOffice connector to each member's https FQDN instead of the member's mycelium [ipv6]:9997 address. OnlyOffice's URL parser rejects bracketed IPv6 literals (ERR_INVALID_URL), so the engine could never fetch documents or post the save callback. The shared engine, the document fetch and convert, the JWT gate, and the per context store are all confirmed working live (the engine downloads and converts a real document from a member FQDN, and a forged token is rejected). One blocker remains before a member can actually open and edit in the desktop: the browser to engine realtime channel (OnlyOffice socket.io and websocket) does not complete through the member login floor, so the engine never receives the open command and the editor shows "Download failed". Filed as https://forge.ourworld.tf/lhumina_code/hero_office/issues/32 Separately, a member should land in their own named context (a default plus a context named for their username) rather than a leftover or shared one. Filed as https://forge.ourworld.tf/lhumina_code/home/issues/305
Author
Owner

The OnlyOffice editor now works end to end for a member: open, edit, and the live collaboration socket. The blocker was an internal address leaking into the engine's browser-facing asset URLs; fixed in hero_office_admin (integration 703a9db). Details in lhumina_code/hero_office#32 . Remaining office follow-ups: give each member its own named context instead of the leftover defaults (lhumina_code/home#305), and make the shared engine restart-safe so an admin reboot does not interrupt editing.

The OnlyOffice editor now works end to end for a member: open, edit, and the live collaboration socket. The blocker was an internal address leaking into the engine's browser-facing asset URLs; fixed in hero_office_admin (integration 703a9db). Details in https://forge.ourworld.tf/lhumina_code/hero_office/issues/32 . Remaining office follow-ups: give each member its own named context instead of the leftover defaults (https://forge.ourworld.tf/lhumina_code/home/issues/305), and make the shared engine restart-safe so an admin reboot does not interrupt editing.
Author
Owner

Progress: voice dictation now works across the testing organization. The browser microphone (the click to dictate button) transcribes speech live into the input box on the member instances.

Root cause: each member instance was missing the small local voice-activity-detection (VAD) model that the voice service uses to segment speech before sending each segment to the shared transcription engine. Without that model the service only produced a transcript when the user pressed Stop, so live dictation looked like it did nothing (the mic captured audio but no text appeared). The transcription engine itself was always fine.

Fix: the voice service now fetches this model automatically on startup (idempotent and non-fatal, so it self-heals on every member and on fresh provisions). The model has also been added to all current member instances and the admin instance, and the change is documented in the hero_voice README and the admin deployment runbook. Verified live on a member instance.

This is on the integration channel only and has not been promoted to the stable channel.

Progress: voice dictation now works across the testing organization. The browser microphone (the click to dictate button) transcribes speech live into the input box on the member instances. Root cause: each member instance was missing the small local voice-activity-detection (VAD) model that the voice service uses to segment speech before sending each segment to the shared transcription engine. Without that model the service only produced a transcript when the user pressed Stop, so live dictation looked like it did nothing (the mic captured audio but no text appeared). The transcription engine itself was always fine. Fix: the voice service now fetches this model automatically on startup (idempotent and non-fatal, so it self-heals on every member and on fresh provisions). The model has also been added to all current member instances and the admin instance, and the change is documented in the hero_voice README and the admin deployment runbook. Verified live on a member instance. This is on the integration channel only and has not been promoted to the stable channel.
Author
Owner

Hero Biz now has a real backend. We built hero_biz_server, an OSIS-backed CRM service (companies, people, deals, contacts, instruments, contracts, and a projects area) with full create/read/update/delete plus search and field filters, a hermetic test suite, and a reusable step-by-step migration guide in the repo. It builds and passes green. The Biz island in the app does not show this data live yet. The remaining work to make it live for members, tracked here, is: point the Biz frontend at the new hero_biz_server sockets and reconcile the field names, then add hero_biz_server to the member install set and the router routes. A quick local end-to-end check of the frontend against the new backend is planned first as a confidence gate before that wiring.

Hero Biz now has a real backend. We built hero_biz_server, an OSIS-backed CRM service (companies, people, deals, contacts, instruments, contracts, and a projects area) with full create/read/update/delete plus search and field filters, a hermetic test suite, and a reusable step-by-step migration guide in the repo. It builds and passes green. The Biz island in the app does not show this data live yet. The remaining work to make it live for members, tracked here, is: point the Biz frontend at the new hero_biz_server sockets and reconcile the field names, then add hero_biz_server to the member install set and the router routes. A quick local end-to-end check of the frontend against the new backend is planned first as a confidence gate before that wiring.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
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#304
No description provided.