Hero onboarding / paid-tier marketplace (deferred; sandbox catalog absorbed into hero_cockpit#11 + #12) #68

Closed
opened 2026-05-28 02:44:36 +00:00 by mik-tf · 1 comment

What

A new Hero service hero_store that presents every Hero service available in the workspace as a browsable catalog inside a tester's cockpit, with one-click install / uninstall onto that tester's own VM.

Think of it as hero_router (which discovers what's already installed on this VM) plus an upstream registry view (everything that COULD be installed). All free in the test sandbox.

Why

After s172d closes the load-bearing tester-onboarding loop, every tester VM ships the canonical 12-component A-30 stack. That's a great starting set, but the Hero ecosystem has many more services (the D-07 35-set, plus future additions). A tester who wants to try hero_codescalers, hero_embedder, hero_office, hero_slides_v2, or some future hero_X shouldn't need to SSH in and run setup scripts by hand. They should be able to browse a catalog inside their cockpit and click Install.

The story extends:

  • Start with the base (12-component A-30 stack) + hero_books preloaded with docs_hero (so the tester can immediately read how Hero OS works in their own Books instance).
  • From cockpit, open hero_store (a sibling to hero_proxy, hero_router, etc).
  • See cards for every available Hero service with description, dependencies, install button.
  • Click Install. Behind the scenes: hero_store calls a per-tester install RPC that adds the service to this tester's stack and starts it.
  • Click Uninstall: stops + removes the service from the tester's hero_proc + cleans its data directories.

How (sketch)

Depends on the hero_tester_install Rust crate landing first — that gives us typed InstallManifest semantics. Then:

  1. Catalog source: query the Forge API for all repos in lhumina_code/ org that contain .forgejo/workflows/lab-publish.yaml. Cache + display.
  2. Service metadata: each service publishes a small service.toml already; extend the spec with a [catalog] section (display name, description, category, screenshot URL, dependencies). hero_store reads these from the Forge API.
  3. Install RPC: a new RPC on the tester VM (could be part of the existing hero_proc or a new hero_install service) that takes a service name and runs the install: lab build --download --install <name>, register with hero_proc, start. The hero_tester_install crate gets a runtime mode here.
  4. Uninstall RPC: stop service, hero_proc service remove <name>, clean data dirs (with confirmation).
  5. UI: cockpit card / page listing installed vs available services with install/uninstall buttons. Live state via hero_proc service.status_all.
  6. Allowlist (sandbox-only): which services testers can install. Probably the whole D-07 35-set by default in sandbox.

Scope estimate

A focused 2-3 day arc once hero_tester_install + L-11 land. Mostly cockpit UI work + a small new service. No new architectural decisions needed — leverages existing lab build --download + hero_proc service add + service.toml.

Not yet

This is post-v1-sandbox polish. Not in scope for home#238 closure (which is the v1 sandbox bar). File as vision so it's not lost.

Filed from s172c /stop, 2026-05-28.

## What A new Hero service `hero_store` that presents every Hero service available in the workspace as a browsable catalog inside a tester's cockpit, with one-click install / uninstall onto that tester's own VM. Think of it as `hero_router` (which discovers what's already installed on this VM) plus an upstream registry view (everything that COULD be installed). All free in the test sandbox. ## Why After s172d closes the load-bearing tester-onboarding loop, every tester VM ships the canonical 12-component A-30 stack. That's a great starting set, but the Hero ecosystem has many more services (the D-07 35-set, plus future additions). A tester who wants to try `hero_codescalers`, `hero_embedder`, `hero_office`, `hero_slides_v2`, or some future `hero_X` shouldn't need to SSH in and run setup scripts by hand. They should be able to browse a catalog inside their cockpit and click Install. The story extends: - Start with the base (12-component A-30 stack) + `hero_books` preloaded with `docs_hero` (so the tester can immediately read how Hero OS works in their own Books instance). - From cockpit, open `hero_store` (a sibling to `hero_proxy`, `hero_router`, etc). - See cards for every available Hero service with description, dependencies, install button. - Click Install. Behind the scenes: hero_store calls a per-tester install RPC that adds the service to this tester's stack and starts it. - Click Uninstall: stops + removes the service from the tester's `hero_proc` + cleans its data directories. ## How (sketch) Depends on the [hero_tester_install Rust crate](https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/17) landing first — that gives us typed `InstallManifest` semantics. Then: 1. **Catalog source**: query the Forge API for all repos in `lhumina_code/` org that contain `.forgejo/workflows/lab-publish.yaml`. Cache + display. 2. **Service metadata**: each service publishes a small `service.toml` already; extend the spec with a `[catalog]` section (display name, description, category, screenshot URL, dependencies). hero_store reads these from the Forge API. 3. **Install RPC**: a new RPC on the tester VM (could be part of the existing `hero_proc` or a new `hero_install` service) that takes a service name and runs the install: `lab build --download --install <name>`, register with `hero_proc`, start. The hero_tester_install crate gets a runtime mode here. 4. **Uninstall RPC**: stop service, `hero_proc service remove <name>`, clean data dirs (with confirmation). 5. **UI**: cockpit card / page listing installed vs available services with install/uninstall buttons. Live state via hero_proc `service.status_all`. 6. **Allowlist** (sandbox-only): which services testers can install. Probably the whole D-07 35-set by default in sandbox. ## Scope estimate A focused 2-3 day arc once hero_tester_install + L-11 land. Mostly cockpit UI work + a small new service. No new architectural decisions needed — leverages existing `lab build --download` + `hero_proc service add` + service.toml. ## Not yet This is post-v1-sandbox polish. Not in scope for home#238 closure (which is the v1 sandbox bar). File as vision so it's not lost. ## Related - [hero_demo#52](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/52) — overall Hero OS vision - [hero_os_tfgrid_deployer#17](https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/17) — hero_tester_install Rust crate (dependency) - [home#238](https://forge.ourworld.tf/lhumina_code/home/issues/238) — current sandbox arc (this is the next-level after that closes) Filed from s172c /stop, 2026-05-28.
Author

Status update — superseded by cockpit Services page polish

After the s172d demo walk it became clear that the cockpit Services page (issues hero_cockpit#11 and hero_cockpit#12) absorbs the entire service catalog concern for the free / sandbox tier. There is no separate "store" surface to build:

  • hero_cockpit#11 — render every user-facing Hero service with installed-or-not state, Install button for uninstalled ones (the scope was just expanded to cover the full canonical Hero service set, not just the 12 auto-installed demo components).
  • hero_cockpit#12 — clickable URL column so the tester can open any installed service directly.

Together those two issues are the catalog. Once both ship (planned for the next session), the cockpit IS the platform's service catalog for the sandbox tier.

The original framing of this issue as a "hero_store" with searchable browseable marketplace shape only makes sense once paid services and onboarding flows exist (subscription tiers, billing, third-party developer publishing, curated featured-content surfaces). That is a real future concern but it lives with the paid-tier onboarding arc, not the free-tier demo. Recommend closing this issue and re-filing under a "paid-tier marketplace and onboarding" tracker when that work is scheduled.

**Status update — superseded by cockpit Services page polish** After the s172d demo walk it became clear that the cockpit Services page (issues hero_cockpit#11 and hero_cockpit#12) absorbs the entire service catalog concern for the free / sandbox tier. There is no separate "store" surface to build: - hero_cockpit#11 — render every user-facing Hero service with installed-or-not state, Install button for uninstalled ones (the scope was just expanded to cover the full canonical Hero service set, not just the 12 auto-installed demo components). - hero_cockpit#12 — clickable URL column so the tester can open any installed service directly. Together those two issues are the catalog. Once both ship (planned for the next session), the cockpit IS the platform's service catalog for the sandbox tier. The original framing of this issue as a "hero_store" with searchable browseable marketplace shape only makes sense once paid services and onboarding flows exist (subscription tiers, billing, third-party developer publishing, curated featured-content surfaces). That is a real future concern but it lives with the paid-tier onboarding arc, not the free-tier demo. Recommend closing this issue and re-filing under a "paid-tier marketplace and onboarding" tracker when that work is scheduled.
mik-tf changed title from Vision: hero_store — discoverable on-demand Hero service catalog for tester VMs to Hero onboarding / paid-tier marketplace (deferred; sandbox catalog absorbed into hero_cockpit#11 + #12) 2026-05-28 05:37:55 +00:00
Sign in to join this conversation.
No labels
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_research/hero_demo#68
No description provided.