Package Layout

lazy_cuh/
  core/           Plain framework models, events, and commands
  input/          Action IDs, key bindings, and navigation state
  keybar/         Keybar models and renderers
  layout/         Item-to-line rendering and wrapping
  modals/         Modal models and pure modal state transitions
  styles/         Terminal palette and theme helpers
  viewport/       Visual line mapping and scroll policy
  view/           Panel and tab specs plus title rendering
  widgets/        Textual adapters, including modal widgets
  examples/       Demo apps that consume lazy-cuh like downstream apps

  hints.py        Neutral key-hint projection from action metadata

  actions.py      Compatibility export for lazy_cuh.input.actions
  commands.py     Compatibility export for lazy_cuh.core.commands
  events.py       Compatibility export for lazy_cuh.core.events
  items.py        Compatibility export for lazy_cuh.core.items
  navigation.py   Compatibility export for lazy_cuh.input.navigation
  panels.py       Compatibility export for lazy_cuh.view.panels

The public package is intentionally small while the API is being designed, but the internal folders are split by responsibility from the start. Reusable logic should move into the focused packages, not into compatibility modules.

Import Rule Of Thumb

Use lazy_cuh for common app-building primitives, use focused subpackages for deeper framework work, and use lazy_cuh.widgets only at the Textual boundary.

The demo app in lazy_cuh.examples.demo should follow the same rule. If the demo has to reach into private modules to build a normal app, the public API is missing something.

For complexity limits and API ergonomics review, see Code Quality.