Module renderer 

The host-side Renderer trait.

Phase 5.B.1 introduces the abstraction that lets App be generic over its renderer. Each frontend crate (lattice-ui-tui, future lattice-ui-gpui) defines a zero-sized marker type and implements Renderer for it, specifying the renderer-native types that fill the two associated slots App carries.

Why only two associated types?

The Phase 5.B.0 field audit ([docs/dev/architecture/phase-5b-app-fields.md]) classified every field on the current [crate::App] (when it lives here after 5.B.3) against its type’s home crate. Of ~200 fields, two carry renderer-specific types:

• the cached ratatui-typed Theme adapter the TUI’s render loop reads on the hot path, and
• the per-mode pane-render dispatch registry whose function pointers take a renderer-native frame type.

Every other field is pure data or pulls from already-host-side crates. That makes the trait’s surface deliberately small. Frame-level types (Frame, InputEvent, LayoutConstraints, …) live on Phase 5.6’s separate lattice-render::Renderer trait — they have a different cardinality (one App-Renderer pairing ↔ many frame renders) and a different home.

Anchor docs

• [docs/dev/architecture/phase-5-extraction.md] — the overall Phase 5 plan.
• [docs/dev/architecture/phase-5b-app-fields.md] — the field-by-field audit that confirmed this surface.

Structs

MinimalRenderer

Headless renderer marker for host-side tests and any renderer-neutral integration test that needs a concrete R without pulling in a real renderer’s types.

Traits

Renderer

The host-side renderer abstraction.