lash-cli owns
Argument parsing, setup and stored configuration, provider materialization, concrete plugin wiring, execution-mode selection, TUI state, autonomous JSON/RPC surfaces, session navigation, export, update policy, installer assets, profiling, and binary releases.
Lash owns
The reusable runtime and facade, protocol implementations, provider factories, generic tools and plugins, stores, durable process machinery, Lashlang, trace contracts, and embedding documentation.
lash-cli
Binary bootstrap, configuration, providers, plugin composition, commands, session flows, autonomous modes, and terminal application state.
lash-tui
Terminal input, frame lifecycle, and rendering primitives.
lash-tui-extensions
Host-owned UI extension contracts and activity presentation.
lash-search-tools
FFF-backed local search and the optional Lashlang search surface.
lash-file-index
Ignore-aware file walking, filesystem notifications, and fuzzy file completion.
lash-export
Session-tree HTML and JSON export for CLI persistence and traces.
lash-autoresearch
CLI-owned applied workflow plugin and terminal extension.
harness + performance
The debug CLI harness and CLI performance helpers exercise product behavior without becoming runtime SDK contracts.
arguments + ~/.lash/config.json
│
▼
provider factories + plugin factories + store
│
▼
LashCore / LashSession
│
┌──────┴────────┐
▼ ▼
interactive TUI --print / JSON / RPC
Execution modes such as standard and rlm are Lash protocol plugins. The CLI chooses and configures one for a session; it does not implement protocol semantics itself.
lash-cli may depend on published or Git-pinned Lash SDK crates. Lash must not depend back on CLI crates. A second application that needs CLI-private code is evidence for extracting a focused SDK capability—not for making applications depend on one another.