Hero v1 Roadmap: how the pieces compose toward a single binary release #120
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?
TL;DR. Hero is converging on a single binary that runs the whole stack (hero_compute#45). Project 13 has the pieces but not the order. This suggests six phases for composing them into v1, plus one process rule: stage cross-repo refactors the way #118 does, so we stop hitting breaks like hero_osis#23.
Hi guys!
Hero is converging on one shape: a single statically linked binary that runs the whole stack (osis, agent, embedder, aibroker, books, collab, the lot), installable with one command, logged in once via hero_proxy, rendered in a Dioxus web desktop. That's where hero_compute#45 points, and it's what Timur's rename work (hero_rpc#13), Mahmoud's osis consolidation, the auth move to hero_proxy (#118), and the 100% Dioxus SPA goal (#104) are all converging on.
Right now the Hero OS demo runs online via
hero_zero(the repo previously known ashero_services), which packages every service binary, service TOML, seed file, and runtime asset into one Docker image and runs it on a TFGrid VM. That's been useful for shipping demos fast, but it's a transitional layer. Once hero_compute#45 lands (one binary, all services inside it), hero_zero's assembly role mostly goes away, and deploying Hero becomes a one-line install anywhere.Project 13 tracks the individual work. What it doesn't show is the order. A lot of these pieces depend on each other, and shipping them out of sequence is what causes problems like last week's hero_osis#23, where the embedder SDK got removed before
hero_archipelagos_intelligencewas migrated, and downstream builds broke until we pinned.So here's a suggested order, six phases, all grounded in tickets already on the board:
bin_companions. Nothing downstream stabilizes until these do.hero_service.toml. hero_zero shrinks to pack-only.One suggestion for how to move through this without repeating the hero_osis#23 kind of break: make the #118 pattern the default for any cross-repo refactor. That rollout staged cleanly, consumers prepared first, producer followed, nothing orphaned. Using it as the standard would prevent the flip-flops we've been running into.
This is meant to sit alongside project 13, not replace it. The board stays the source of truth for what's actively moving. This just tries to show how the moving pieces assemble into v1.
Hi @despiegk, I've been trying to figure out how project 13 composes into v1, and this is my best attempt at mapping it. If the ordering makes sense, happy to go deeper on any phase. If not, close it. The project ACTIVE is the actual source of truth and this is just me sketching. Can loop in @timur and @mahmoud if it's worth pursuing.