prometeu-runtime/discussion/lessons/DSC-0036-prometeu-hub-ui-direction/LSN-0045-hub-ui-slices-should-prove-os-boundaries.md

107 lines
3.8 KiB
Markdown

---
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.