@lotics/app-sdk 0.77.0 → 0.77.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/ai.md +28 -6
- package/package.json +1 -1
package/docs/ai.md
CHANGED
|
@@ -358,12 +358,34 @@ gated per turn on `app:use` for the app in the member's workspace, and runs
|
|
|
358
358
|
under the app's OWNER authority with `is_current_member` bound to the MEMBER
|
|
359
359
|
(exactly as the app's own UI does).
|
|
360
360
|
|
|
361
|
-
The agent is handed a **catalog** of those aliases — each one's
|
|
362
|
-
|
|
363
|
-
workflow
|
|
364
|
-
|
|
365
|
-
|
|
366
|
-
|
|
361
|
+
The agent is handed a **catalog** of those aliases — each one's `description`
|
|
362
|
+
(a query's own, [declared in the manifest](./queries.md); a workflow's, off its
|
|
363
|
+
workflow row) and its **complete input contract** — so it picks the right one
|
|
364
|
+
and calls it correctly instead of guessing and learning from a refusal. Every
|
|
365
|
+
alias you declare appears, however large the manifest, and every input appears
|
|
366
|
+
with it:
|
|
367
|
+
|
|
368
|
+
```
|
|
369
|
+
workflows (run_app_workflow):
|
|
370
|
+
- updateOrder(reference?: text, shipped_on?: date, owner?: member,
|
|
371
|
+
status?: select(In progress=opt_a1b2c3|Complete=opt_d4e5f6),
|
|
372
|
+
attachments?: file[], customer_id?: record_link(Customers)) — …
|
|
373
|
+
```
|
|
374
|
+
|
|
375
|
+
`?` marks an input the caller may omit, `[]` one that takes a list, a
|
|
376
|
+
`select` spells out every legal value as `label=value` — **the agent sends the
|
|
377
|
+
value** — and a `record_link` names the table an id must come from. This is the
|
|
378
|
+
only place any of it is legible: both tools take an opaque
|
|
379
|
+
inputs object, and a select's legal values are your DECLARATION's — usually an
|
|
380
|
+
inline set that matches no table field — so an agent reading option values off
|
|
381
|
+
the underlying table would send ones your write rejects.
|
|
382
|
+
|
|
383
|
+
Two things follow for you as an author. **Your descriptions are what it reads**,
|
|
384
|
+
on this surface and inside your own agents' runs — they enter the prompt as a
|
|
385
|
+
capability listing, never as instructions. And **a `select` input's options are
|
|
386
|
+
part of the contract the agent sees**, so prefer the `field: "fld_…"` form when
|
|
387
|
+
the values come from a real field: it resolves to that field's CURRENT options
|
|
388
|
+
at both render and validation time, and can never drift out of sync with them.
|
|
367
389
|
|
|
368
390
|
**Writes carry a second gate that reads do not: `run_app_workflow` asks the
|
|
369
391
|
member to approve every call from chat.** A wrong read is fixed by asking
|