Thank you for being patient! We're working hard on resolving the issue
The tento/* tree holds provider SDKs, platform libraries, and developer
tools that sit below Lona application code. These projects should be
documented as APIs, not as incidental folders: each public module needs a clear
owner, dependency direction, and host boundary.
tento-lona-connector and
tento-lona-connector-macros define the host-agnostic row integration
contract.tento-google, tento-garmin, tento-whoop,
tento-weather, tento-linear, tento-monarch, and related crates keep
upstream API details out of app code.tento-deploy, tento-cloudflare,
tento-app-bundle, tento-ssr, and tento-core provide reusable
infrastructure and build/runtime helpers.tento-chrono, tento-tz, tento-flights,
tento-iata, tento-data-js, tento-data-ui-js, tento-sheets,
tento-stripe, tento-lisp, and tento-event-classifier own focused
business, data, rendering, or parsing logic.-js suffix,
while public imports strip it (tento-core-js exports @tento-core,
tento-ui-js exports @tento-ui, and tento-data-js exports
@tento-data).Default provider crates should be usable as SDKs without pulling in Lona host state. Host-specific row dispatch belongs behind optional connector or sync-plugin features, and concrete Lona data types should be converted at the host boundary.
When a crate needs to call an external service, it should own provider-specific request/response types and expose narrower high-level methods to callers. Application code should not need to know endpoint paths, raw scope strings, OAuth refresh details, or generated vendor model internals unless the crate is specifically a low-level client.
Each *.docs section should answer: