---
id: LSN-0045
discussion: DSC-0036
decision: DEC-0028
title: Hub UI Slices Should Prove OS Boundaries
status: done
created: 2026-05-15
tags: [hub, ui, shell, lifecycle, window-manager]
---

# Hub UI Slices Should Prove OS Boundaries

## Context

The first Prometeu Hub visual slice introduced a retro/minimalist Home surface
with two fake native Shell apps, `ShellA` and `ShellB`. The visible work was
small by design: two launch buttons, simple green/blue app windows, mouse click
activation, and a close affordance.

The important result was not only the look. The slice proved that a system UI
can become more visual without taking ownership away from `SystemOS` and
Firmware.

## Key Lessons

### Keep visual intent separate from OS effects

The Hub now emits explicit system-profile actions for user intent. Launching a
Shell app is represented as an action; Firmware/SystemOS creates the native
Shell task, process, and task-owned window.

This preserves the useful split:

```text
Hub renders and navigates
Hub emits intent
Firmware/SystemOS executes lifecycle, task, process, and window ownership
```

That split is more important than the exact shape of the first UI.

### A small visual slice can validate lifecycle

The implementation deliberately avoided a generic catalog, toolkit, tabs,
footer bar, and controller navigation. Even with that narrow scope, it proved
the critical flow:

```text
Hub/Home -> ShellA or ShellB -> task-owned window -> close -> lifecycle close -> Hub/Home
```

This is the right kind of first UI milestone: it exercises the OS model instead
of only drawing a mock screen.

### Existing input may be enough for the first cut

The desktop host already maps pointer state into the runtime touch bridge. The
Hub slice reused that path for mouse/click hit testing instead of inventing a
new input system.

The result is intentionally simple: button rectangles in 270p space, click-edge
activation, and a close hit target. Controller focus can build on this later,
but it does not need to be solved before the Shell lifecycle flow is proven.

### Font assets are not the same as font integration

Pixel Operator is present as TrueType assets under `assets/pixel-operator/`,
but the current runtime text path is a built-in bitmap glyph renderer exposed
through `GfxBridge::draw_text`.

Deferring TrueType integration was correct because adding a TTF loader, font
manager, rasterizer, or public font contract would have expanded the UI slice
into unrelated architecture. The existing bitmap text remains compatible with
the retro direction until a dedicated font decision exists.

## Pitfalls

- Do not let visual components call task/process managers directly.
- Do not treat window removal as app close; Shell app close must go through
  lifecycle.
- Do not turn the first two buttons into a generic app catalog by accident.
- Do not introduce a broad UI toolkit before multiple real Hub surfaces need
  shared components.
- Do not interpret the Pixel Operator asset as a completed font system.

## Evidence

The implementation evidence for this slice was:

- `cargo test -p prometeu-system`: 83 passed.
- `cargo test -p prometeu-firmware`: 17 passed.
- `cargo test -p prometeu-host-desktop-winit`: 25 passed, 5 ignored.
- `discussion validate`: passed.

The firmware tests cover launching Shell apps through Hub actions, creating
task-owned windows, and closing through lifecycle back to Hub. The system tests
cover local hit testing and layout/action coupling for the Hub slice.

## References

- `DEC-0028` - Prometeu Hub Initial Retro Shell UI Slice.
- `PLN-0062` - Native Shell Launch and Lifecycle Wiring.
- `PLN-0063` - Hub Mouse Input and Click Routing.
- `PLN-0064` - Retro Hub Home and Fake Shell UI.
- `PLN-0065` - Pixel Operator Font Integration.
- `PLN-0066` - Hub UI Slice Validation and Lesson.