libtermy Implementation

Core Workflow

1. Inspect the current Termy checkout or upstream docs first. Treat libtermy as experimental and breaking-change prone.
2. Choose the narrowest surface:
   • Use termy_core for Rust embedders or changes that should be portable to FFI, WASM, JS, and tests.
   • Use termy_ffi for C, Swift, Objective-C, or any host that needs a stable C ABI.
   • Use the macOS Swift reference when building or tuning the native macOS host.
3. Keep terminal behavior in Rust core. Do not reimplement VT parsing, keyboard/mouse encoding, search, shell integration, color query replies, resize anchoring, config parsing, or dirty damage tracking in the host.
4. Build hosts around full-or-partial frame updates. Prefer frame_update / termy_terminal_take_frame_update over polling full snapshots in a render loop.
5. Validate at the boundary you touched before broadening test scope.

Reference Routing

• Read references/libtermy-api.md when touching termy_core, termy_ffi, ABI structs/functions, event/search/input APIs, config/render config, ownership, threading, or Rust embedding.
• Read references/macos-swift-host.md when implementing a macOS Swift app, SwiftPM linking, CTermy, LibTermyTerminal, wakeup monitoring, AppKit rendering, panes/tabs, settings, or tmux display terminals.
• Read references/optimization.md when optimizing rendering, reducing FFI marshaling, tuning cadence, avoiding CPU/RSS regressions, reviewing performance PRs, or adding gates.