Module buffers 

Buffer kind + id + flags – moved from lattice-ui-tui to the renderer-agnostic substrate in Phase 5.2 first wave.

The actual definitions live in lattice-core; this module is a thin re-export so the canonical host-side path (lattice_host::buffers::BufferKind) lives next to the rest of the host’s substrate. lattice-ui-tui::buffers continues to work via pub use lattice_host::buffers; so call sites that haven’t migrated yet don’t break.

Structs

BufferFlags

Vim-style per-buffer flags (DESIGN.md §5.9). The shape is fixed now so additions don’t churn every call site; v1 ships with listed populated (:bn / :bp / :ls skip unlisted buffers once the wiring lands) and hidden reserved for “keep loaded without a window” semantics. Both default to “normal buffer” (listed = true, hidden = false).

BufferId

Stable monotonic handle identifying one buffer instance. Two buffers with the same BufferKind still have distinct ids. The App allocates these via BufferId::next at buffer- creation time and stores them on each buffer + on every position-history entry.

Enums

BufferKind

Which kind of buffer the App’s input pipeline currently routes to. The chord grammar, motions, and position history are shared; kind only matters at a few discrete decision points: which cursor a motion mutates, whether mutating actions are accepted (most non-document kinds are read-only), and which buffer-local bindings apply (Help binds <CR> to follow-link, FileTree binds <CR> to follow-entry, etc.).