Hero sandbox demo (go-to-production): cover the meeting demo, deployed from main #244
Labels
No labels
meeting-notes
meeting-transcript
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/home#244
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?
Goal
Make the Hero OS sandbox cover the go-to-production demo, deployed from
the stable
mainbranch on the dedicated node. Source of truth for scopeis the meeting:
kristof_ahmed_go2production.md.
The demo: a user provisions a VM on the grid, gets cockpit access, and
runs the agent (kimi rust, exposed as web with MCP tools to whiteboard
and planner) to drive Planner plus Whiteboard/Slides artifacts, with
voice. Nothing beyond this is in scope (no books / grounded search /
memory for this demo).
How releases work
Per-branch rolling release: a push to
mainpublishes thelatestrelease, a push to
developmentpublishes thedevrelease. The sandboxinstall downloads
latest, so once a component publishes frommaintheinstall tracks
main. Moving a component to main = (1) rolling workflowon main + CI green so
latestis from main, (2) the small stable-librarymigration if it still uses the old service API, (3) set default branch to
main.Demo components → repo → status
latestis from current main (add rolling if stale)Plan (MVP first)
main(publish-only):hero_router(done),hero_planner,hero_slides(CI building). (in progress)hero_kimi_rust+hero_whiteboarddefault=main; publishhero_voice_provider; migratehero_voice. Completes the meeting demo (agent -> planner/whiteboard, by voice).Boundary
The deployment components (deployer, cockpit) are ours and done. While the
team is offline we are also doing the publish-switch and the small library
migrations on the demo components above; each is a CI-file or the same
migration already done on proxy / router / proc / cockpit, recorded here.
This tracker is scoped to the meeting demo only; org-wide migration of the
~70 other lhumina_code repos is out of scope here.
Status update from the deployment side.
Done:
Blocked (needs a maintainer of hero_proxy):
This is the general pattern we are tracking: each shared library main needs its own dependencies pointed at the stable branches, not just the leaf apps.
Update: the three deployment-side repos are now on main.
Thanks to the hero_proxy maintainer for pointing its main dependencies at the stable branches, which unblocked the cockpit.
Still outstanding for the whole sandbox to deploy purely from main (maintainer-owned, tracked above): the app and engine repos still default to development, and hero_embedder_provider still has no release. Each app repo will likely need the same small hero_lifecycle migration the cockpit just did.
Hero sandbox demo: move deployment to the main branchto Hero sandbox demo (go-to-production): cover the meeting demo, deployed from mainPhase 2 done: live MVP bring-up from main on the dedicated node.
A fresh tester was provisioned on the rented node and installed the demo base bundle from the latest (main) releases, reaching install state ready. The base bundle is now scoped to the demo apps (cockpit, planner, slides, whiteboard, agent, voice) on top of the always-on base (proxy, router, supervisor, the per-tester data store, orchestrator). Content libraries, the knowledge store, and business records were dropped from the default install and are install-on-demand instead. The data store (hero_db) was added to the base because slides persists to it, and without it slides could fail its first boot.
All demo apps serve on the tester and route through the public gateway behind the Forge login gate (landing 200; cockpit, planner, slides, whiteboard all redirect to login as expected). Provisioning and the gateway path are healthy (the earlier contract-cancel 502 was delete-only, not the forward path). The deployer change is on main and republishing latest; the deployment runbook demo-app scope was updated to match.
Next: Phase 3 (agent kimi_rust + voice from main), then Phase 4 cutover.
Demo tester is live and the old testers are cleaned up.
alicelight (the meeting demo) is provisioned from main on the dedicated node and installs the base bundle to ready: cockpit, planner, slides, whiteboard, voice all serve and route through the public gateway behind the Forge login at https://alicelight.gent01.qa.grid.tf. It has a working login account.
All earlier development-era testers (alice123, alice124, alice125, ruy, and a couple of throwaways) were decommissioned and their user records removed, so the only tester now is alicelight. Deleting VMs works again (the earlier teardown failures have cleared); back-to-back contract cancellations need a compute-daemon restart between each, tracked separately.
The full-stack demo tester (books, memory, grounded search) is tracked as alicefull in #246, gated on those apps publishing from main.
mik-tf referenced this issue2026-06-03 23:37:40 +00:00
State update: the last two base components are now on the stable branch. The gateway WebSocket forwarding fix (so the assistant chat connects on a tester domain) and the assistant's four deploy fixes (web address form, provider key read from the environment, prefix-correct asset paths, and its setup files embedded in the binary) are merged to main and CI is republishing the stable release. These were proven on the live tester using locally built fast-path binaries; the remaining step to call this done is to provision one brand-new tester from the stable release and confirm it comes up working with no manual fixes: the assistant opens, is styled, and chats; planner, slides, and whiteboard serve; and voice loads.