BentoTUI docs

BentoTUI Architecture Contract

BentoTUI ships with an explicit product architecture aimed at outcomes: ship a serious app shell in one day.

  • Bricks and recipes are copy-and-own.
  • Rooms are import-only geometry contracts.
  • Bentos are runnable templates for rapid remix.

Canonical stack order

Use this order when explaining or implementing BentoTUI:

  1. theme interface, presets, and optional global manager
  2. theme/styles helpers (Row, RowClip, ClipANSI)
  3. registry/bricks copy-and-own component layer
  4. registry/recipes copy-and-own composed flows
  5. registry/rooms import-only layout geometry
  6. surface UV compositor
  7. Bubble Tea frame (tea.NewView, AltScreen, BackgroundColor)

Layer responsibilities

  • Bricks: official UI building blocks copied into app code with bento add <brick>.
  • Recipes: copy-and-own flow patterns copied with bento add recipe <name>.
  • Rooms: stable import-only page layout contracts from registry/rooms.
  • Bentos: runnable template apps under registry/bentos/*.

Reliability guardrails

Guardrails are part of product reliability, not internal trivia:

  • Rooms do not import theme, bricks, or raw bubbles.
  • Bricks do not import other bricks.
  • Bentos/starter/scaffold/recipes avoid raw bubbles/* (spinner exception).
  • Bento View() methods do not call theme.CurrentTheme() directly; theme should be model-owned state.

Rendering rule

Every row drawn to surface-backed layouts should have explicit background ownership, usually via styles.Row(...), to avoid bleed and gaps.

Runtime baseline in v0.6.0

  • Go module baseline: go 1.25.2
  • charm.land/bubbletea/v2 v2.0.0-rc.2
  • charm.land/bubbles/v2 v2.0.0-rc.1
  • charm.land/lipgloss/v2 v2.0.0-beta.3
  • github.com/charmbracelet/ultraviolet