@lotics/app-sdk 0.49.0 → 0.49.1

package/docs/queries.md

@@ -763,17 +763,26 @@ slice, and within it:
   layer** — `select`/`select_member`/`select_record_link` `has_any_of` / `has_all_of`, and
   `is_current_member`. These compile to containment the JSONB GIN index serves.
 - **Trigram-served:** `from_table.search` (§7).
-- **Partition scan (linear in table size):** everything else — text `contains`/`equals`,
-  number and date range predicates, negations (`has_none_of`, `is_none_of`, `not_*`),
-  emptiness, files predicates. Fine on thousands of rows; on very large tables these dominate
-  latency and are the usual timeout cause.
-
-**Filter shape drives latency.** Lead with a GIN-served membership filter or `search` where you
-can; let the scan-shaped predicates refine the already-narrowed set. Derived-layer filters run
-over the subquery result (no index), so **filter at the source layer whenever the field exists
-there** — the runtime filter is for caller-driven refinement, not for the main cut. (The engine
-pushes eligible filter-over-union predicates down automatically, but don't rely on that for
-other shapes.)
+- **B-tree-served (automatic for deployed queries):** text `equals`, number and date
+  comparisons (exact and range), and `sort` fields — for fields referenced in a **deployed
+  named query's template**. The platform provisions a partial expression index per referenced
+  field automatically: built online on `app deploy` and `app query set`, re-synced daily,
+  capped at 8 per table (fields past the cap fall back to the scan tier, with a server WARN).
+  A `{{params.…}}` value hole doesn't change this — the field key is static in the template,
+  so it still gets its index. Index-seek speed at any table size once provisioned.
+- **Partition scan (linear in table size):** everything else — text `contains`, negations
+  (`has_none_of`, `is_none_of`, `not_*`), emptiness, files predicates, and predicates/sorts on
+  fields that appear **only** in the runtime `filter`/`sort` options rather than the deployed
+  template. Fine on thousands of rows; on very large tables these dominate latency and are the
+  usual timeout cause.
+
+**Filter shape drives latency.** Equality/range/sort predicates in the deployed template are
+index-served; lead with those or a GIN-served membership filter / `search`, and let scan-shaped
+predicates refine the already-narrowed set. Derived-layer filters run over the subquery result
+(no index), so **filter at the source layer whenever the field exists there** — the runtime
+filter is for caller-driven refinement, not for the main cut (a runtime-only field gets no
+managed index). (The engine pushes eligible filter-over-union predicates down automatically,
+but don't rely on that for other shapes.)
 
 ### The authoring rules
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lotics/app-sdk",
-  "version": "0.49.0",
+  "version": "0.49.1",
   "description": "Runtime SDK for Lotics custom-code apps — typed hooks, postMessage bridge, mount entry point",
   "type": "module",
   "exports": {