@lotics/cli 0.292.2 → 0.293.0

package/dist/src/client.d.ts

@@ -126,6 +126,10 @@ export interface ToolInfo {
     name: string;
     description: string;
     input_schema: unknown;
+    /** The answer's shape; empty for a tool answering prose. */
+    output_schema?: unknown;
+    /** A step a workflow body calls, never run from the CLI. */
+    workflow_only?: true;
 }
 /**
  * A single knowledge doc with its HYDRATED body — the shape of

package/docs/design.md

@@ -223,6 +223,10 @@ captured — and files it as a new row of the record's `timeline` child (`into`)
   glyph names it — on every option of a select read down a column (how it was paid, the channel, the mode).
 - Every files field is drawn somewhere — a section's `fields`, a `files` block, the `image`, or where the
   act making it stands.
+- The paperwork is the proof of the work, so every paper the job takes in and every document it issues has a
+  place on the record, in the section where that work happens: a files field per purpose (what arrived, what
+  was issued to the customer, to the carrier, to the authority), each kept visible after the stage that made it,
+  and a source — a screenshot, an email, a sheet — on the row whose figure came from it.
 - A screen with none of these is bland, and bland is a finding: text drawn where a treatment above exists
   is a change to the model.
 

package/docs/workflows.md

@@ -51,7 +51,7 @@ await send_email({
 | step | syntax |
 |---|---|
 | tool call, kept | `const <id> = await <tool>({ ...inputs });` — also `let x = await …` and `x = await …` |
-| tool call | `await <tool>({ ...inputs });` |
+| tool call | `await <tool>({ ...inputs });` — a connection's tools too, each a workflow step (`bkav_submit_invoices`, `gmail_send_email`, …); a step that fails ends the run with its reason unless a `try`/`catch` around it handles it |
 | agent | `const <id> = await agent({ instructions, input, tools, model, output });` — see **An agent step** |
 | app agent | `const <id> = await app_agent({ alias: "<agent alias>", input: { ... } });` — runs one of the app's declared agents, in an app workflow only, and resolves to its declared outputs or its final text. `wait: false` only starts the run and resolves to `{ run_id }`; the run's failure is then its own, not the workflow's. Refused in a run an agent started. |
 | bind | `const <id> = <expression>;` — evaluated once; later steps read `<id>`. Bind any expression used twice. |
@@ -64,6 +64,9 @@ await send_email({
 | return | `return({ status: "success" \| "error", message: <expr>, field_errors: { ... }? });` |
 | validate | `validate({ checks: [{ fail_when: <expr>, field_key: "...", message: <expr> }, ...] });` |
 
+Every step's inputs, the values each takes and its answer: `lotics tools <name>` prints them, a connection's steps
+included; `query_integration_tools` lists the workspace's connections and the steps each opens.
+
 `return` is a call, not a JavaScript `return` statement. `validate` ends the workflow with an error
 when a check's `fail_when` is truthy; the check's `field_key` names the control its message lands on —
 in an app workflow a declared input, or the `fld_` key of a field on a table the body names; a field of

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lotics/cli",
-  "version": "0.292.2",
+  "version": "0.293.0",
   "description": "Lotics SDK and CLI for AI agents",
   "type": "module",
   "bin": {