Normalize island_url to /hero_<svc>/ui/ across all entries #121

New issue

Open

opened 2026-04-30 11:25:28 +00:00 by zaelgohary · 0 comments

zaelgohary commented

2026-04-30 11:25:28 +00:00

Member

Problem

island_url in crates/hero_os_web/src/components/island_frame.rs mixes two URL conventions for iframe islands:

"books"     => "/hero_books/ui/"      // hero_router proxy (per-service ui.sock)
"voice"     => "/hero_voice/ui/"      // hero_router proxy
"inspector" => "/hero_router/ui/"     // hero_router proxy (post #119)
"redis"     => "/hero_db/ui/"         // hero_router proxy
"proc"      => "/hero_proc/ui/"       // hero_router proxy
...
"biz"       => "/hero_biz/"           // legacy flat (hero_proxy root)
"forge"     => "/hero_forge_ui/"      // legacy flat
"indexer"   => "/hero_indexer_ui/"    // legacy flat
"cloud"     => "/hero_cloud_ui/"      // legacy flat

The legacy /hero_X_ui/ and bare-name forms come from the pre-hero_router era when each admin UI was mounted directly under hero_proxy at a flat path. They still resolve only because hero_proxy is registered as a service and forwards them — but it's an extra hop and the convention asymmetry produces real bugs:

QA audit caught /hero_compute/ui 503 (40 hits) and /hero_browser/ui 503 (106 hits) — services aren't reachable through their flat URLs.
New islands sometimes copy the wrong convention.
It's not obvious from the table which ones are broken vs intentional.

Fix

Normalize every entry to /hero_<service>/ui/. For each currently-legacy island, verify the service has a ui.sock exposed; if not, register one or drop the island metadata until it's wired up.

Affected entries: biz, business, forge, indexer, cloud, compute, proxy, router (the second one — already partially fixed via #119 for inspector).

Out of scope

Services that don't yet have a hero_router-style ui.sock (browser, compute) — those need their own deploy/config tickets.

## Problem `island_url` in `crates/hero_os_web/src/components/island_frame.rs` mixes two URL conventions for iframe islands: ```rust "books" => "/hero_books/ui/" // hero_router proxy (per-service ui.sock) "voice" => "/hero_voice/ui/" // hero_router proxy "inspector" => "/hero_router/ui/" // hero_router proxy (post #119) "redis" => "/hero_db/ui/" // hero_router proxy "proc" => "/hero_proc/ui/" // hero_router proxy ... "biz" => "/hero_biz/" // legacy flat (hero_proxy root) "forge" => "/hero_forge_ui/" // legacy flat "indexer" => "/hero_indexer_ui/" // legacy flat "cloud" => "/hero_cloud_ui/" // legacy flat ``` The legacy `/hero_X_ui/` and bare-name forms come from the pre-hero_router era when each admin UI was mounted directly under hero_proxy at a flat path. They still resolve only because hero_proxy is registered as a service and forwards them — but it's an extra hop and the convention asymmetry produces real bugs: - QA audit caught `/hero_compute/ui` 503 (40 hits) and `/hero_browser/ui` 503 (106 hits) — services aren't reachable through their flat URLs. - New islands sometimes copy the wrong convention. - It's not obvious from the table which ones are broken vs intentional. ## Fix Normalize every entry to `/hero_<service>/ui/`. For each currently-legacy island, verify the service has a `ui.sock` exposed; if not, register one or drop the island metadata until it's wired up. Affected entries: `biz`, `business`, `forge`, `indexer`, `cloud`, `compute`, `proxy`, `router` (the second one — already partially fixed via #119 for `inspector`). ## Out of scope Services that don't yet have a hero_router-style `ui.sock` (browser, compute) — those need their own deploy/config tickets.