lhumina_code/hero_cockpit
0
0
Fork 0
Code Issues 9 Pull requests Projects Releases 2 Packages Wiki Activity Actions

Services page: surface uninstalled components with one-click Install button #11

New issue
Open
opened 2026-05-28 04:51:33 +00:00 by mik-tf · 1 comment
mik-tf commented 2026-05-28 04:51:33 +00:00
Owner
Copy link

Today the cockpit's Services page lists only services hero_proc already knows about. Components that are part of the canonical demo stack but not yet started (because their dependency isn't met, e.g. hero_books needs hero_aibroker which needs a BYO AI key) are invisible from the cockpit, so a tester who pastes their AI key in Settings has no UI path to actually bring the dependent service up. Proposal: list every component from the host's cockpit-services.toml (or the canonical 12-component array); render rows for services hero_proc doesn't know about as greyed-out with an "Install" button instead of the normal restart/stop/upgrade icons. The button shells out to lab build <repo> --download --install + lab service <name> --start server-side (lab is already on the VM and is what setup-binaries.sh uses), polls until the service appears in hero_proc, then the row brightens in place with the full action set. No row movement, no separate "available" section — just per-row state toggle. Closes the tester-side UX gap where alice signs into her cockpit, pastes an AI key, but has no way to start hero_books from the UI.

Today the cockpit's Services page lists only services hero_proc already knows about. Components that are part of the canonical demo stack but not yet started (because their dependency isn't met, e.g. hero_books needs hero_aibroker which needs a BYO AI key) are invisible from the cockpit, so a tester who pastes their AI key in Settings has no UI path to actually bring the dependent service up. Proposal: list every component from the host's `cockpit-services.toml` (or the canonical 12-component array); render rows for services hero_proc doesn't know about as greyed-out with an "Install" button instead of the normal restart/stop/upgrade icons. The button shells out to `lab build <repo> --download --install` + `lab service <name> --start` server-side (lab is already on the VM and is what setup-binaries.sh uses), polls until the service appears in hero_proc, then the row brightens in place with the full action set. No row movement, no separate "available" section — just per-row state toggle. Closes the tester-side UX gap where alice signs into her cockpit, pastes an AI key, but has no way to start hero_books from the UI.
mik-tf commented 2026-05-28 05:37:35 +00:00
Author
Owner
Copy link

Scope expansion — full Hero service catalog, not just the auto-installed set

After live-walking the s172d demo, a sharper framing of this issue: the cockpit Services page is the platform's service catalog, period. There is no separate "store" surface to ship later. So the scope of this issue is broader than "render the 12 auto-installed components":

  • Source of truth: the canonical Hero service set (the 35-repo demo set tracked in the workspace, of which ~15-18 are user-facing services with a UI binary; the rest are libraries, docs, or pure infrastructure).
  • At provision time: 12 canonical demo components are auto-installed by the deployer (today's A-30 stack). The cockpit renders those rows with the normal action set (start, stop, restart, upgrade, URL).
  • Catalog rows: every other user-facing Hero service (Hero Embedder for per-tester docs grounding, Hero Indexer for search, Hero Collab for OnlyOffice integration on larger VMs, Hero Assistance, Hero Foundry, Hero Archipelagos, etc.) renders as a greyed-out row with an Install button. Clicking Install fires lab build <repo> --download --install then lab service start server-side, polls until the service appears in Hero Proc's service list, then the row brightens in place with the full action set.
  • Filter: include any service with at least one binary declaring a web UI socket in its service.toml. Pure-infrastructure services without a UI (Hero Router, Hero DB, etc.) can either be filtered out of the tester-facing view entirely or shown in a separate "Infrastructure" section.

This collapses what was previously planned as a future "hero_store" catalog arc into the same Services page that already exists. No new top-level surface; the cockpit IS the catalog. The hero_store-style separate browseable marketplace concept is deferred until paid services and onboarding flows exist (a future paid-tier concern).

**Scope expansion — full Hero service catalog, not just the auto-installed set** After live-walking the s172d demo, a sharper framing of this issue: the cockpit Services page is the platform's service catalog, period. There is no separate "store" surface to ship later. So the scope of this issue is broader than "render the 12 auto-installed components": - **Source of truth**: the canonical Hero service set (the 35-repo demo set tracked in the workspace, of which ~15-18 are user-facing services with a UI binary; the rest are libraries, docs, or pure infrastructure). - **At provision time**: 12 canonical demo components are auto-installed by the deployer (today's A-30 stack). The cockpit renders those rows with the normal action set (start, stop, restart, upgrade, URL). - **Catalog rows**: every other user-facing Hero service (Hero Embedder for per-tester docs grounding, Hero Indexer for search, Hero Collab for OnlyOffice integration on larger VMs, Hero Assistance, Hero Foundry, Hero Archipelagos, etc.) renders as a greyed-out row with an Install button. Clicking Install fires `lab build <repo> --download --install` then `lab service start` server-side, polls until the service appears in Hero Proc's service list, then the row brightens in place with the full action set. - **Filter**: include any service with at least one binary declaring a web UI socket in its service.toml. Pure-infrastructure services without a UI (Hero Router, Hero DB, etc.) can either be filtered out of the tester-facing view entirely or shown in a separate "Infrastructure" section. This collapses what was previously planned as a future "hero_store" catalog arc into the same Services page that already exists. No new top-level surface; the cockpit IS the catalog. The hero_store-style separate browseable marketplace concept is deferred until paid services and onboarding flows exist (a future paid-tier concern).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
development
integration
latest
dev
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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/hero_cockpit#11
No description provided.