[platform] Member Cockpit: fix Apps/Admin/Services surfaces, add the Browser service, and make Update all reliable #306
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/home_lhumina#306
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
Services page
Browser service
Update all services
Office default workspace (moved from #305)
Context switcher for regular members (moved from #305)
Proof on a real member
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 .
Progress: the Cockpit changes are shipped to the integration channel and proven live on member instances.
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.
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.
Two more member-instance integration gaps found while testing (good progress, not fully there):
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).
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.
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:
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.
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
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:
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:
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. 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).