@User Good initial stab! A few comments: - From the document, it's not quite obvious what the role of the engine-client is. I might have misunderstood it in the comments below. - I personally would partition this maybe slightly differently: 1. Core / Engine, the "business logic" for most of the functionalities like lookups, diagnostics, publishing etc. 2. LSP server, delegates calls to core 3. VSCode extension, calls LSP server and manages the UI. In some cases might call core directly, but the execution will then happen in VS Code process (see below). 4. CLI, calls core directly - To get the lookup results into extension, I believe server extension communication can be extended with custom JSON RPC messages (thus: extension asks completion -> server asks it from core -> core constructs that from its index, returns to server -> server returns result to extension) - IIRC, file watching is done by the VS Code, and it will notify the LSP server whenever any file relevant for the extension is changed. Typically every change would cause index refresh + sending status + diagnostics from server to extension (probably with some throttling). - IIRC, the watched files are set in the extension's package.json - Things like creating daily notes, I would delegate via extension -> core, so that CLI can then do similar thing via CLI -> core (thus logic for it would only reside in core)