lhumina_code/home
0
0
Fork 0
Code Issues 68 Pull requests Projects Releases Packages Wiki Activity Actions

Hero sandbox: expanded tester app bundle and cockpit Apps/Services UI #278

New issue
Open
opened 2026-06-09 21:57:02 +00:00 by mik-tf · 1 comment
mik-tf commented 2026-06-09 21:57:02 +00:00
Owner
Copy link

Goal

Expand the tester VM base bundle and make the tester cockpit expose two clear pages:

  • Apps: human-facing launchers / app UI dashboards.
  • Services: complete installed/running service inventory.

This is tester VM cockpit scope, not deployer admin UI scope.

Base Bundle Target

Keep the existing core:

  • hero_proxy
  • hero_router
  • hero_proc
  • hero_cockpit
  • hero_db
  • hero_slides
  • hero_whiteboard
  • hero_planner
  • hero_kimi
  • hero_voice
  • hero_orchestrator

Add the larger default app set:

  • hero_books
  • hero_office
  • hero_os
  • hero_collab
  • hero_biz

Do not add hero_agent for now. Kimi remains the main assistant experience. Keep hero_orchestrator because it powers agent actions/buttons and the agent/voice widget integrations.

Tester VM Sizing

Default tester VMs should currently use 2 TFGrid slices. With today's hero_compute model, one slice is coupled to 1 vCPU + 4 GB RAM, so the practical default profile is:

  • 2 vCPU
  • 8 GB RAM
  • minimum 32 GB SSD per tester

This is not the ideal product profile, but it is the practical default for the expanded bundle until hero_compute supports independent CPU/RAM/disk profiles. Current tester VMs mount a fixed 16 GB rootfs and 32 GB /data volume, while existing ready testers use roughly 1-1.3 GB for the installed Hero stack. The expanded bundle is expected to fit in this profile; verification must prove that with real install usage.

The desired future profile is closer to 2 vCPU + 4 GB RAM + 32 GB /data, with larger optional profiles for heavier demos or document-heavy use. That is not representable cleanly with only slice_count today.

For this issue, verification must prove the expanded default bundle fits the current two-slice profile. The deployer should not show or auto-select nodes as suitable when a default tester would receive less than 32 GB SSD; very low-disk-per-slice nodes should be avoided for new tester provisioning.

Live Slice Resource Detail

One TFGrid slice currently means:

  • CPU: 1 vCPU (cpu_count = slice_count).
  • RAM: 4 GB (memory_gb = 4 per slice).
  • Storage: node-dependent, from the compute daemon slice catalog, not a universal constant.

Current live catalog examples on the admin deployer:

  • main/0001 (tfnode-3467): 1 slice = 1 vCPU, 4 GB RAM, 138 GB disk, so a 2-slice tester gets 276 GB disk and comfortably qualifies.
  • qa/0001 (tfnode-5): 1 slice = 1 vCPU, 4 GB RAM, 18 GB disk, so a 2-slice tester gets 36 GB disk and qualifies with limited headroom.
  • qa/000n (tfnode-2): 1 slice = 1 vCPU, 4 GB RAM, 9 GB disk, so a 2-slice tester gets 18 GB disk and should not qualify for the 32 GB floor.

This makes disk the risky axis for the expanded bundle on some QA nodes, but 50 GB is too conservative for the current bundle and would unnecessarily reject usable 36 GB testers.

UI Model

Apps page:

  • Shows only human-facing app entries.
  • Expected entries: Kimi, Books, Office, Hero OS, Planner, Whiteboard, Slides, Voice, Collab, Biz.
  • Include Orchestrator only when there is a clear user-facing action surface, otherwise keep it visible on Services/Admin only.
  • Each app should expose the right actions: open app UI, open admin UI when distinct, or one button when they are the same surface.

Services page:

  • Shows every installed/running service, including server/admin/web binaries.
  • Should include status, route/socket if available, version/build when available, and links/actions such as logs, restart, admin UI.

Important Classification Rule

Suffixes are only hints. _admin may be the app UI for services such as hero_office, hero_os, hero_whiteboard, hero_collab, and hero_biz. Prefer service metadata or a curated registry over suffix heuristics.

Implementation Notes

  • Deployer: extend A30_STACK_COMPONENTS for the new base bundle.
  • Installer: extend COMPONENT_REPO for missing repos such as hero_office and hero_os; hero_books/collab/biz are already known in the installer map.
  • Verify latest release artifacts and binary names for hero_office and hero_os before wiring start behavior.
  • Check hero_demo for prior shape:
    • profiles/tester.toml
    • services/hero_os.toml
    • services/hero_office.toml
  • Cockpit should add Apps and Services pages on the tester VM, not the deployer admin.
  • Discovery should use hero_proc/router/service metadata where possible, plus a curated fallback classification.

Acceptance Criteria

  • A fresh tester VM install includes the expanded default bundle and reaches ready.
  • Generated cockpit-services.toml includes the intended app components.
  • Apps page presents clean app launchers and distinguishes app UI vs admin UI.
  • Services page lists the raw service inventory and status.
  • Weird admin-as-app cases are labelled clearly and do not depend only on _admin suffix logic.
  • Existing provisioning/install tests are updated.

Related

Source Capture

This issue consolidates home#275, including: add more apps to the base bundle, add hero_office, the original 4 GB RAM target, and separate user-facing apps from admin/service dashboards. Current implementation uses 2 slices (8 GB RAM) because hero_compute couples CPU and RAM; decoupling remains future work.

## Goal Expand the tester VM base bundle and make the tester cockpit expose two clear pages: - **Apps**: human-facing launchers / app UI dashboards. - **Services**: complete installed/running service inventory. This is tester VM cockpit scope, not deployer admin UI scope. ## Base Bundle Target Keep the existing core: - hero_proxy - hero_router - hero_proc - hero_cockpit - hero_db - hero_slides - hero_whiteboard - hero_planner - hero_kimi - hero_voice - hero_orchestrator Add the larger default app set: - hero_books - hero_office - hero_os - hero_collab - hero_biz Do **not** add hero_agent for now. Kimi remains the main assistant experience. Keep hero_orchestrator because it powers agent actions/buttons and the agent/voice widget integrations. ## Tester VM Sizing Default tester VMs should currently use **2 TFGrid slices**. With today's `hero_compute` model, one slice is coupled to **1 vCPU + 4 GB RAM**, so the practical default profile is: - **2 vCPU** - **8 GB RAM** - **minimum 32 GB SSD per tester** This is not the ideal product profile, but it is the practical default for the expanded bundle until `hero_compute` supports independent CPU/RAM/disk profiles. Current tester VMs mount a fixed **16 GB rootfs** and **32 GB `/data`** volume, while existing ready testers use roughly 1-1.3 GB for the installed Hero stack. The expanded bundle is expected to fit in this profile; verification must prove that with real install usage. The desired future profile is closer to **2 vCPU + 4 GB RAM + 32 GB `/data`**, with larger optional profiles for heavier demos or document-heavy use. That is not representable cleanly with only `slice_count` today. For this issue, verification must prove the expanded default bundle fits the current two-slice profile. The deployer should not show or auto-select nodes as suitable when a default tester would receive less than 32 GB SSD; very low-disk-per-slice nodes should be avoided for new tester provisioning. ## Live Slice Resource Detail One TFGrid slice currently means: - **CPU:** 1 vCPU (`cpu_count = slice_count`). - **RAM:** 4 GB (`memory_gb = 4` per slice). - **Storage:** node-dependent, from the compute daemon slice catalog, not a universal constant. Current live catalog examples on the admin deployer: - `main/0001` (`tfnode-3467`): 1 slice = 1 vCPU, 4 GB RAM, 138 GB disk, so a 2-slice tester gets 276 GB disk and comfortably qualifies. - `qa/0001` (`tfnode-5`): 1 slice = 1 vCPU, 4 GB RAM, 18 GB disk, so a 2-slice tester gets 36 GB disk and qualifies with limited headroom. - `qa/000n` (`tfnode-2`): 1 slice = 1 vCPU, 4 GB RAM, 9 GB disk, so a 2-slice tester gets 18 GB disk and should not qualify for the 32 GB floor. This makes disk the risky axis for the expanded bundle on some QA nodes, but 50 GB is too conservative for the current bundle and would unnecessarily reject usable 36 GB testers. ## UI Model Apps page: - Shows only human-facing app entries. - Expected entries: Kimi, Books, Office, Hero OS, Planner, Whiteboard, Slides, Voice, Collab, Biz. - Include Orchestrator only when there is a clear user-facing action surface, otherwise keep it visible on Services/Admin only. - Each app should expose the right actions: open app UI, open admin UI when distinct, or one button when they are the same surface. Services page: - Shows every installed/running service, including server/admin/web binaries. - Should include status, route/socket if available, version/build when available, and links/actions such as logs, restart, admin UI. ## Important Classification Rule Suffixes are only hints. `_admin` may be the app UI for services such as hero_office, hero_os, hero_whiteboard, hero_collab, and hero_biz. Prefer service metadata or a curated registry over suffix heuristics. ## Implementation Notes - Deployer: extend `A30_STACK_COMPONENTS` for the new base bundle. - Installer: extend `COMPONENT_REPO` for missing repos such as hero_office and hero_os; hero_books/collab/biz are already known in the installer map. - Verify latest release artifacts and binary names for hero_office and hero_os before wiring start behavior. - Check hero_demo for prior shape: - `profiles/tester.toml` - `services/hero_os.toml` - `services/hero_office.toml` - Cockpit should add Apps and Services pages on the tester VM, not the deployer admin. - Discovery should use hero_proc/router/service metadata where possible, plus a curated fallback classification. ## Acceptance Criteria - A fresh tester VM install includes the expanded default bundle and reaches ready. - Generated `cockpit-services.toml` includes the intended app components. - Apps page presents clean app launchers and distinguishes app UI vs admin UI. - Services page lists the raw service inventory and status. - Weird admin-as-app cases are labelled clearly and do not depend only on `_admin` suffix logic. - Existing provisioning/install tests are updated. ## Related - #241 - #257 - #259 ## Source Capture This issue consolidates [home#275](https://forge.ourworld.tf/lhumina_code/home/issues/275), including: add more apps to the base bundle, add hero_office, the original 4 GB RAM target, and separate user-facing apps from admin/service dashboards. Current implementation uses 2 slices (8 GB RAM) because `hero_compute` couples CPU and RAM; decoupling remains future work.
mik-tf commented 2026-06-09 22:11:14 +00:00
Author
Owner
Copy link

Sizing note from the deployer follow-up: new tester VMs should default to 1 TFGrid slice = 4 GB RAM, no more.

For the current stack this is plausible because heavy shared engines are intended to live off the tester VM. For the expanded bundle in this issue, 4 GB is an assumption we must prove during verification, especially around hero_office/OnlyOffice and any local indexing/embedder-like workloads.

Acceptance expectation: do not silently raise the default RAM if the expanded bundle is tight. Either keep heavy pieces off-tester, reduce service footprint, or introduce an explicit separate full profile. The default demo tester should stay 4 GB unless we make a deliberate product decision otherwise.

Sizing note from the deployer follow-up: new tester VMs should default to **1 TFGrid slice = 4 GB RAM**, no more. For the current stack this is plausible because heavy shared engines are intended to live off the tester VM. For the expanded bundle in this issue, 4 GB is an assumption we must prove during verification, especially around hero_office/OnlyOffice and any local indexing/embedder-like workloads. Acceptance expectation: do not silently raise the default RAM if the expanded bundle is tight. Either keep heavy pieces off-tester, reduce service footprint, or introduce an explicit separate full profile. The default demo tester should stay 4 GB unless we make a deliberate product decision otherwise.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
main
No results found.
Labels
Clear labels   
meeting-notes

Meeting notes and follow-ups

  
meeting-transcript

Raw meeting transcript; AI drafts the report

No labels
meeting-notes
meeting-transcript
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/home#278
No description provided.