[platform] Member Cockpit: fix Apps/Admin/Services surfaces, add the Browser service, and make Update all reliable #306

Open
opened 2026-06-18 21:12:33 +00:00 by mik-tf · 7 comments
Owner

This is the single tracking issue for a set of related problems seen on a live member instance. They are all about how a member's Cockpit presents its services, how it updates them, and which workspace a member lands in. They share the same area, so we track everything here. This issue absorbs the remaining parts of lhumina_code/home#305 (its desktop landing part already shipped and is live on all members).

Background: the Browser service was added to the member set in lhumina_code/home#279 as the local render engine that Slides uses to export to PDF and PowerPoint. While checking that it shows up correctly on a member, we found the presentation, update, and workspace issues below.

Apps and Admin pages

  • An app a member opens and uses belongs on the Apps page. An admin dashboard belongs on the Admin page. Today the Apps page also shows admin dashboards as if they were apps, which is confusing, so we will stop doing that and remove the admin shortcut button from the app cards.
  • A few apps (Slides, Whiteboard, Biz) currently use their admin dashboard as the actual user-facing app because they do not yet ship a separate user page. They stay on the Apps page for now. The proper fix is in each of those repos (give them a real user-facing page), and follow-up issues will be filed there.

Services page

  • Every service should list its parts (server, admin, web) with working links where they apply. The Router is shown without its admin link today even though it serves one, so fix the link derivation so single-binary services like the Router also show their admin link.

Browser service

  • Make the Browser service appear on the Admin and Services pages of a member. It is a background render engine for Slides, not something a member opens directly, so it does not get an Apps card.

Update all services

  • Update all currently fails partway through (for example 14 of 21 failed on a live member). The cause is that the Cockpit updates itself in the middle of the batch, which restarts it and drops the connection the rest of the update runs on. Fix the ordering so everything else updates first and the Cockpit, proxy, and router update last.

Office default workspace (moved from #305)

  • A member's Office should default to the member's own workspace rather than a leftover shared one (it currently falls back to a workspace called demo). Set it at provision time so Office follows the member's own workspace.

Context switcher for regular members (moved from #305)

  • A regular member should not see the admin-style context switcher that lists other workspaces (core, demo, and similar). This depends on the workspaces backend, which is not built on members yet, tracked at lhumina_code/hero_osis#66 and lhumina_code/home#303 . Parked here until that backend is available.

Proof on a real member

  • Enable Slides on a member, run an update, and export a slide deck to PDF and PowerPoint to confirm the whole path works end to end.

Most of the work is in the Cockpit. The deploy and the export proof are done on a live member.

End state (what done looks like)

The goal this builds toward is a single live member instance that shows the whole experience working together: the Hero OS desktop running with the workspaces backend so its panels are populated, Office opening and editing real spreadsheets and documents, and the assistant (Kimi) able to operate apps on request through the tool gateway, for example asking it to add something in Planner or draw on the Whiteboard. The individual pieces have each been shown before, so this is about assembling them on one member and confirming they work together. Two parts depend on other work: the desktop panels need the workspaces backend (lhumina_code/hero_osis#66), and the assistant operating apps through the tool gateway is tracked at lhumina_code/hero_orchestrator#1 .

This is the single tracking issue for a set of related problems seen on a live member instance. They are all about how a member's Cockpit presents its services, how it updates them, and which workspace a member lands in. They share the same area, so we track everything here. This issue absorbs the remaining parts of https://forge.ourworld.tf/lhumina_code/home/issues/305 (its desktop landing part already shipped and is live on all members). Background: the Browser service was added to the member set in https://forge.ourworld.tf/lhumina_code/home/issues/279 as the local render engine that Slides uses to export to PDF and PowerPoint. While checking that it shows up correctly on a member, we found the presentation, update, and workspace issues below. Apps and Admin pages - An app a member opens and uses belongs on the Apps page. An admin dashboard belongs on the Admin page. Today the Apps page also shows admin dashboards as if they were apps, which is confusing, so we will stop doing that and remove the admin shortcut button from the app cards. - A few apps (Slides, Whiteboard, Biz) currently use their admin dashboard as the actual user-facing app because they do not yet ship a separate user page. They stay on the Apps page for now. The proper fix is in each of those repos (give them a real user-facing page), and follow-up issues will be filed there. Services page - Every service should list its parts (server, admin, web) with working links where they apply. The Router is shown without its admin link today even though it serves one, so fix the link derivation so single-binary services like the Router also show their admin link. Browser service - Make the Browser service appear on the Admin and Services pages of a member. It is a background render engine for Slides, not something a member opens directly, so it does not get an Apps card. Update all services - Update all currently fails partway through (for example 14 of 21 failed on a live member). The cause is that the Cockpit updates itself in the middle of the batch, which restarts it and drops the connection the rest of the update runs on. Fix the ordering so everything else updates first and the Cockpit, proxy, and router update last. Office default workspace (moved from #305) - A member's Office should default to the member's own workspace rather than a leftover shared one (it currently falls back to a workspace called demo). Set it at provision time so Office follows the member's own workspace. Context switcher for regular members (moved from #305) - A regular member should not see the admin-style context switcher that lists other workspaces (core, demo, and similar). This depends on the workspaces backend, which is not built on members yet, tracked at https://forge.ourworld.tf/lhumina_code/hero_osis/issues/66 and https://forge.ourworld.tf/lhumina_code/home/issues/303 . Parked here until that backend is available. Proof on a real member - Enable Slides on a member, run an update, and export a slide deck to PDF and PowerPoint to confirm the whole path works end to end. Most of the work is in the Cockpit. The deploy and the export proof are done on a live member. End state (what done looks like) The goal this builds toward is a single live member instance that shows the whole experience working together: the Hero OS desktop running with the workspaces backend so its panels are populated, Office opening and editing real spreadsheets and documents, and the assistant (Kimi) able to operate apps on request through the tool gateway, for example asking it to add something in Planner or draw on the Whiteboard. The individual pieces have each been shown before, so this is about assembling them on one member and confirming they work together. Two parts depend on other work: the desktop panels need the workspaces backend (https://forge.ourworld.tf/lhumina_code/hero_osis/issues/66), and the assistant operating apps through the tool gateway is tracked at https://forge.ourworld.tf/lhumina_code/hero_orchestrator/issues/1 .
Author
Owner

Progress: the Cockpit changes are shipped to the integration channel and proven live on member instances.

  • The Browser service now shows on the Admin and Services pages, and not on the Apps page (it is a background render engine, not an app).
  • The Router now shows its admin link on the Services page.
  • The redundant Admin button is removed from the Apps cards.
  • Update all now updates the serving path (proxy, router, cockpit) last, so the Cockpit cannot restart in the middle of the batch and drop the connection the rest of the update runs on.

Proven on a member that runs the Browser (admin card plus services link, absent from Apps) and on the member whose Update all had failed (router link present, no app admin buttons, the new ordering is live in the served page). The admin console was updated the same way. The rest of the fleet picks the change up from the integration channel.

Remaining: Office defaulting to the member's own workspace, and the in-app Slides export to PDF and PowerPoint on a member with Slides enabled.

Progress: the Cockpit changes are shipped to the integration channel and proven live on member instances. - The Browser service now shows on the Admin and Services pages, and not on the Apps page (it is a background render engine, not an app). - The Router now shows its admin link on the Services page. - The redundant Admin button is removed from the Apps cards. - Update all now updates the serving path (proxy, router, cockpit) last, so the Cockpit cannot restart in the middle of the batch and drop the connection the rest of the update runs on. Proven on a member that runs the Browser (admin card plus services link, absent from Apps) and on the member whose Update all had failed (router link present, no app admin buttons, the new ordering is live in the served page). The admin console was updated the same way. The rest of the fleet picks the change up from the integration channel. Remaining: Office defaulting to the member's own workspace, and the in-app Slides export to PDF and PowerPoint on a member with Slides enabled.
Author
Owner

Update: the Office default workspace item is done too. The deployer now points hero_office's default context at the member's own workspace at install and update (it was falling back to a shared demo workspace), shipped to the integration channel and proven on a live member (its Office now defaults to the member's own context). So of the Cockpit and workspace items, what remains is the live acceptance: a real Update all run end to end, and the in-app Slides export to PDF and PowerPoint on a member with Slides enabled.

Update: the Office default workspace item is done too. The deployer now points hero_office's default context at the member's own workspace at install and update (it was falling back to a shared demo workspace), shipped to the integration channel and proven on a live member (its Office now defaults to the member's own context). So of the Cockpit and workspace items, what remains is the live acceptance: a real Update all run end to end, and the in-app Slides export to PDF and PowerPoint on a member with Slides enabled.
Author
Owner

Two more member-instance integration gaps found while testing (good progress, not fully there):

  1. Hero OS does not land a member in their own workspace when opened from the Cockpit. Clicking Hero OS from the Cockpit lands on a default workspace (threefold for one member, geomind for another) instead of the member's own; a hard refresh lands correctly on the member's own workspace. The server-side redirect to the member workspace works on a direct visit, but the desktop app itself defaults to a built-in workspace (or the last-used one) on load, so it does not honor the member's seeded workspace from the Cockpit link. The fix is for the desktop to default to the member's own seeded workspace; this is also tied to the workspaces backend being unavailable (lhumina_code/hero_osis#66).

  2. The Hero Router page links to the internal address. On the Router admin page, clicking a service (for example Hero Cockpit) navigates to 127.0.0.1:9988/..., the router's internal address, which the browser cannot reach. The links should be built from the member's public address instead.

Working well: a member can open Hero Office and see a document, and the Cockpit Apps, Admin, and Services surfaces from this work render correctly.

Two more member-instance integration gaps found while testing (good progress, not fully there): 1. Hero OS does not land a member in their own workspace when opened from the Cockpit. Clicking Hero OS from the Cockpit lands on a default workspace (threefold for one member, geomind for another) instead of the member's own; a hard refresh lands correctly on the member's own workspace. The server-side redirect to the member workspace works on a direct visit, but the desktop app itself defaults to a built-in workspace (or the last-used one) on load, so it does not honor the member's seeded workspace from the Cockpit link. The fix is for the desktop to default to the member's own seeded workspace; this is also tied to the workspaces backend being unavailable (https://forge.ourworld.tf/lhumina_code/hero_osis/issues/66). 2. The Hero Router page links to the internal address. On the Router admin page, clicking a service (for example Hero Cockpit) navigates to 127.0.0.1:9988/..., the router's internal address, which the browser cannot reach. The links should be built from the member's public address instead. Working well: a member can open Hero Office and see a document, and the Cockpit Apps, Admin, and Services surfaces from this work render correctly.
Author
Owner

Adding to the definition of done for a fully working member instance: the AI operating layer must be confirmed working end to end, not just the apps. Specifically we need to confirm, on a live member:

  • Voice works: speech to text, text to speech, and the wake word, through the shared voice engine.
  • The Kimi assistant chat works.
  • The assistant can operate apps over the tool gateway (MCP), for example asking it to add something in Planner or draw on the Whiteboard. This is the part tracked at lhumina_code/hero_orchestrator#1 .

The shared embedder and voice engines already run on the admin instance; this item is about confirming the full assistant-plus-voice-plus-tools loop is actually usable on a member. This is the heart of the product (the assistant is the operating layer, not a feature), so it sits alongside the desktop, Office, and Slides items as a release-blocking part of the end state.

Adding to the definition of done for a fully working member instance: the AI operating layer must be confirmed working end to end, not just the apps. Specifically we need to confirm, on a live member: - Voice works: speech to text, text to speech, and the wake word, through the shared voice engine. - The Kimi assistant chat works. - The assistant can operate apps over the tool gateway (MCP), for example asking it to add something in Planner or draw on the Whiteboard. This is the part tracked at https://forge.ourworld.tf/lhumina_code/hero_orchestrator/issues/1 . The shared embedder and voice engines already run on the admin instance; this item is about confirming the full assistant-plus-voice-plus-tools loop is actually usable on a member. This is the heart of the product (the assistant is the operating layer, not a feature), so it sits alongside the desktop, Office, and Slides items as a release-blocking part of the end state.
Author
Owner

Progress update. Update all now completes fully on the member that had been failing: a real run finished 21 of 21 bundles with zero failures, and the serving path (proxy, router, and the Cockpit itself) is updated last so it can no longer cut its own connection in the middle of the batch. The Router discovery page and the sidebar, service detail and MCP pages now build their links from the member's public address instead of the internal loopback, so the links are reachable from a browser (fix is on a branch, proven live on a member, ready to merge). Filed upstream requests for dedicated user facing app surfaces on Slides, Whiteboard and Biz (hero_slides#102, hero_whiteboard#228, hero_biz#55). Confirmed the Slides PDF and PPTX export's external dependency works from a member: the dom-to-pptx library loads from the CDN into the member's headless browser and exposes its export function. One separate problem surfaced: the current hero_code release build does not run on member VMs and Update all exposes it (tracked in hero_code#19). Remaining for the all-in-one member: the workspaces backend so the desktop islands populate, the assistant operating apps over the tool gateway, and a live voice and assistant pass.

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

Progress update. Update all now completes fully on the member that had been failing: a real run finished 21 of 21 bundles with zero failures, and the serving path (proxy, router, and the Cockpit itself) is updated last so it can no longer cut its own connection in the middle of the batch. The Router discovery page and the sidebar, service detail and MCP pages now build their links from the member's public address instead of the internal loopback, so the links are reachable from a browser (fix is on a branch, proven live on a member, ready to merge). Filed upstream requests for dedicated user facing app surfaces on Slides, Whiteboard and Biz (hero_slides#102, hero_whiteboard#228, hero_biz#55). Confirmed the Slides PDF and PPTX export's external dependency works from a member: the dom-to-pptx library loads from the CDN into the member's headless browser and exposes its export function. One separate problem surfaced: the current hero_code release build does not run on member VMs and Update all exposes it (tracked in hero_code#19). Remaining for the all-in-one member: the workspaces backend so the desktop islands populate, the assistant operating apps over the tool gateway, and a live voice and assistant pass. Signed-by: mik-tf <mik-tf@noreply.invalid>
Author
Owner

Status update and the concrete path to finishing this on the integration line.

Done and proven on a live member. The Cockpit presentation and update work is complete: the Apps, Admin and Services pages now show the right things, the Browser render service appears on Admin and Services (not Apps), Update all completes fully (a real run did 21 of 21 with zero failures on the member that had previously been failing 14 of 21), the Router page links now point at the member's public address instead of an internal loopback, and Office defaults to the member's own workspace. Upstream requests for proper user-facing pages were filed on Slides, Whiteboard and Biz.

The big remaining piece is the workspaces backend (hero_osis), which the empty desktop panels and the regular-member context switcher both depend on (lhumina_code/hero_osis#66). The good news is that this is no longer blocked on an outside developer. The forward-port already exists on the migration branches, and the code generation has moved into a new repository, hero_blueprint. With the right combination the backend now builds cleanly from a clean checkout:

  • hero_osis on branch fix/rpc2-migration
  • hero_blueprint on branch main (this now holds the rpc2, generator and osis crates, not hero_rpc)
  • hero_lib on branch main

With that set the backend server compiles with zero errors and the binary runs. The only remaining blocker to boot is a naming clash: both the personal address book (identity) and the CRM (business) define a type called Contact, so both try to register the same create method on the shared transport and the server refuses to start. The fix is to rename the CRM one (already done in the schema) and follow that rename through the hand-written CRM service code (about 27 call sites).

Remaining work to reach the end state (one member with everything working), in order:

  1. Finish the Contact rename so the backend boots cleanly.
  2. Bring the backend onto the integration line and into the member install set, running it with each member's own workspaces.
  3. Confirm the desktop panels populate (Contexts, Finance and the rest) and the regular-member context switcher behaves, on a live member.
  4. Confirm the assistant can operate apps through the tool gateway (lhumina_code/hero_orchestrator#1), plus a live voice and chat pass.
  5. The Slides export proof end to end (enable Slides, run an update, export a deck to PDF and PowerPoint). The export's external dependency is already confirmed working from a member.

Separately, a release-build problem was found and resolved. The code editor service (hero_code) was being published as a binary that could not start on member machines, which Update all exposed. Rebuilding on the fixed builder image fixed it and it runs on members now (lhumina_code/hero_code#19).

The Cockpit, Update all, Router link and Office fixes are merged on the integration line and CI is republishing them, so the fleet picks them up on the next update.

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

Status update and the concrete path to finishing this on the integration line. **Done and proven on a live member.** The Cockpit presentation and update work is complete: the Apps, Admin and Services pages now show the right things, the Browser render service appears on Admin and Services (not Apps), Update all completes fully (a real run did 21 of 21 with zero failures on the member that had previously been failing 14 of 21), the Router page links now point at the member's public address instead of an internal loopback, and Office defaults to the member's own workspace. Upstream requests for proper user-facing pages were filed on Slides, Whiteboard and Biz. **The big remaining piece is the workspaces backend (hero_osis)**, which the empty desktop panels and the regular-member context switcher both depend on (https://forge.ourworld.tf/lhumina_code/hero_osis/issues/66). The good news is that this is no longer blocked on an outside developer. The forward-port already exists on the migration branches, and the code generation has moved into a new repository, hero_blueprint. With the right combination the backend now builds cleanly from a clean checkout: - hero_osis on branch fix/rpc2-migration - hero_blueprint on branch main (this now holds the rpc2, generator and osis crates, not hero_rpc) - hero_lib on branch main With that set the backend server compiles with zero errors and the binary runs. The only remaining blocker to boot is a naming clash: both the personal address book (identity) and the CRM (business) define a type called Contact, so both try to register the same create method on the shared transport and the server refuses to start. The fix is to rename the CRM one (already done in the schema) and follow that rename through the hand-written CRM service code (about 27 call sites). **Remaining work to reach the end state (one member with everything working), in order:** 1. Finish the Contact rename so the backend boots cleanly. 2. Bring the backend onto the integration line and into the member install set, running it with each member's own workspaces. 3. Confirm the desktop panels populate (Contexts, Finance and the rest) and the regular-member context switcher behaves, on a live member. 4. Confirm the assistant can operate apps through the tool gateway (https://forge.ourworld.tf/lhumina_code/hero_orchestrator/issues/1), plus a live voice and chat pass. 5. The Slides export proof end to end (enable Slides, run an update, export a deck to PDF and PowerPoint). The export's external dependency is already confirmed working from a member. **Separately, a release-build problem was found and resolved.** The code editor service (hero_code) was being published as a binary that could not start on member machines, which Update all exposed. Rebuilding on the fixed builder image fixed it and it runs on members now (https://forge.ourworld.tf/lhumina_code/hero_code/issues/19). The Cockpit, Update all, Router link and Office fixes are merged on the integration line and CI is republishing them, so the fleet picks them up on the next update. Signed-by: mik-tf <mik-tf@noreply.invalid>
Author
Owner

Status update. The cockpit surfaces (Apps, Admin, Services), the Browser service, and a resilient Update all are in place and were proven on a live member, including a full Update all pass. Remaining before this can close: in-app export of slide decks to PDF and PowerPoint, and live progress feedback while Update all runs (tracked in lhumina_code/home#302).

Status update. The cockpit surfaces (Apps, Admin, Services), the Browser service, and a resilient Update all are in place and were proven on a live member, including a full Update all pass. Remaining before this can close: in-app export of slide decks to PDF and PowerPoint, and live progress feedback while Update all runs (tracked in https://forge.ourworld.tf/lhumina_code/home/issues/302).
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#306
No description provided.