@lotics/cli 0.130.1 → 0.133.0

package/dist/src/cli.js

@@ -45622,8 +45622,8 @@ import { randomUUID } from "node:crypto";
 import { tmpdir } from "node:os";
 
 // src/starter_template.ts
-var STARTER_FALLBACK_UI_VERSION = "28.1.0";
-var STARTER_FALLBACK_SDK_VERSION = "0.73.0";
+var STARTER_FALLBACK_UI_VERSION = "31.0.0";
+var STARTER_FALLBACK_SDK_VERSION = "0.75.1";
 var STARTER_REACT_NATIVE_VERSION = "0.85.3";
 var VITEST_SETUP_FILENAME = "vitest.setup.ts";
 var VITEST_SETUP_CONTENT = `import { vi } from "vitest";
@@ -68746,27 +68746,36 @@ var STATEMENT_FUNCTIONS = /* @__PURE__ */ new Set([
   "validate",
   "return"
 ]);
+var WORKFLOW_PARSE_OPTIONS = {
+  sourceType: "module",
+  allowReturnOutsideFunction: true,
+  allowAwaitOutsideFunction: true,
+  errorRecovery: false
+};
+function describeSyntaxError(source, raw, parseWith) {
+  try {
+    parseWith(["typescript"]);
+  } catch {
+    return raw;
+  }
+  return `${raw}
+
+This body parses as TypeScript but not as JavaScript \u2014 a workflow body is a JS subset, so type syntax (a parameter annotation, \`as\`, a generic) is not allowed. Remove it. If the type pass then reports an implicit \`any\`, give the VALUE a known type instead \u2014 read it from a typed source (a tool result, \`trigger.app_workflow.inputs\`) rather than annotating the parameter.`;
+}
 function parseWorkflowJs(source, opts) {
   const tooLarge = checkSourceLength(source);
   if (tooLarge) return tooLarge;
   let program;
   try {
-    program = (0, import_parser.parse)(source, {
-      sourceType: "module",
-      // We accept `return({status, message, ...});` as the canonical workflow
-      // return form. JS parses that as a ReturnStatement with a parenthesized
-      // argument, so allow top-level returns.
-      allowReturnOutsideFunction: true,
-      allowAwaitOutsideFunction: true,
-      errorRecovery: false,
-      plugins: []
-    });
+    program = (0, import_parser.parse)(source, { ...WORKFLOW_PARSE_OPTIONS, plugins: [] });
   } catch (err2) {
     const e = err2;
     return {
       ok: false,
       error: {
-        message: e.message ?? "Parse error",
+        message: describeSyntaxError(source, e.message ?? "Parse error", (plugins) => {
+          (0, import_parser.parse)(source, { ...WORKFLOW_PARSE_OPTIONS, plugins });
+        }),
         line: e.loc?.line ?? 1,
         column: (e.loc?.column ?? 0) + 1,
         construct: "syntax_error"
@@ -70674,9 +70683,14 @@ async function writeWorkflowFiles(client, projectDir, app_id, appName, workflows
       continue;
     }
     writeWorkflowFile(projectDir, alias, source, envelope);
+    const rowDescriptionSeen = res.result.description;
     writeSynced(projectDir, "workflows", alias, {
       content: contentSha(normalizeWorkflowBody(source)),
-      ...body_sha ? { live: body_sha } : {}
+      ...body_sha ? { live: body_sha } : {},
+      // What the ROW says right now. The manifest is written from the same
+      // response just below, so the two start equal and any later difference is
+      // the author's edit — which is the whole signal.
+      ...typeof rowDescriptionSeen === "string" ? { description: rowDescriptionSeen } : {}
     });
     const rowDescription = res.result.description;
     if (typeof rowDescription === "string" && rowDescription !== "" && // Skip the server's GENERATED default. It is what an undescribed alias
@@ -71262,12 +71276,14 @@ function defaultPullTarget(appId, appName) {
 }
 async function appPull(client, args) {
   const app = await client.getApp(args.app_id);
-  if (!app.current_version_id) {
+  if (!app.current_version_id && args.version === void 0) {
     throw new Error(
       `App ${app.id} has no published version yet. Deploy from another machine first, or use 'lotics app create' to scaffold a new app.`
     );
   }
-  const version2 = await client.getAppVersion(app.id, app.current_version_id);
+  const versionId = args.version ?? app.current_version_id;
+  if (!versionId) throw new Error(`App ${app.id} has no version to pull.`);
+  const version2 = await client.getAppVersion(app.id, versionId);
   const sourceUrl = await client.getAppVersionSourceUrl(app.id, version2.id);
   const targetPath = path7.resolve(args.targetPath ?? defaultPullTarget(app.id, app.name));
   fs6.mkdirSync(targetPath, { recursive: true });
@@ -71287,7 +71303,11 @@ async function appPull(client, args) {
   stampPulledManifest(targetPath, {
     app_id: app.id,
     workspace_id: app.workspace_id,
-    current_version_id: app.current_version_id,
+    // The version actually on disk, never the live pointer. Stamping "current"
+    // after pulling an OLD one would let the next deploy ship that old source as
+    // if it were built on the newest — the version guard exists to refuse
+    // exactly that, and it can only do so if this tells the truth.
+    current_version_id: versionId,
     version_number: version2.version,
     workflows: app.workflows ?? {},
     queries: app.queries ?? {},
@@ -71554,7 +71574,8 @@ function pendingBindings(args) {
   const { projectDir, meta: meta3, synced, live } = args;
   const workflows = /* @__PURE__ */ new Set([
     ...workflowBodyDrift(projectDir, meta3.workflows, synced),
-    ...divergedWorkflowAliases(meta3.workflows, live.workflows)
+    ...divergedWorkflowAliases(meta3.workflows, live.workflows),
+    ...descriptionDriftedAliases(projectDir, meta3.workflows)
   ]);
   return {
     workflows: [...workflows].sort(),
@@ -71617,6 +71638,18 @@ function driftedAgentAliases(projectDir, liveAgents) {
   }
   return drifted.sort();
 }
+function descriptionDriftedAliases(projectDir, manifestWorkflows) {
+  const baselines = readSynced(projectDir).workflows;
+  const out = [];
+  for (const [alias, declared] of Object.entries(manifestWorkflows ?? {})) {
+    const description = declared.description;
+    if (description === void 0) continue;
+    const seen = baselines[alias]?.description;
+    if (seen === void 0) continue;
+    if (description !== seen) out.push(alias);
+  }
+  return out;
+}
 function divergedWorkflowAliases(manifestWorkflows, liveWorkflows) {
   return [
     ...new Set(workflowTypeDivergences(manifestWorkflows, liveWorkflows).map((d) => d.alias))
@@ -72099,7 +72132,11 @@ async function appWorkflowSet(client, args) {
   const pushedBodySha = res.result !== null && typeof res.result === "object" ? res.result.body_sha : void 0;
   writeSynced(projectDir, "workflows", args.alias, {
     content: contentSha(source),
-    ...typeof pushedBodySha === "string" ? { live: pushedBodySha } : {}
+    ...typeof pushedBodySha === "string" ? { live: pushedBodySha } : {},
+    // This push just MADE it live, so it becomes the baseline. Recorded only
+    // when one was sent: an omitted description leaves the row's own text
+    // standing, and claiming to have seen that text would be a lie.
+    ...typeof declaration.description === "string" ? { description: declaration.description } : {}
   });
   const result = res.result ?? {};
   const workflowId = typeof result.workflow_id === "string" ? result.workflow_id : "(unknown)";
@@ -72258,6 +72295,7 @@ function parseArgs(argv) {
   const flags = {
     json: false,
     force: false,
+    fromVersion: void 0,
     timeout: void 0,
     output: void 0,
     as: void 0,
@@ -72293,6 +72331,9 @@ function parseArgs(argv) {
       case "--force":
         flags.force = true;
         break;
+      case "--from-version":
+        flags.fromVersion = argv[++i2];
+        break;
       case "--timeout":
         flags.timeout = parseInt(argv[++i2], 10);
         break;
@@ -100996,7 +101037,14 @@ Available workspaces:`);
         process.exit(1);
       }
       const targetPath = restArgs[0];
-      await appPull(client, { app_id: appId, targetPath, force: flags.force === true });
+      await appPull(client, {
+        app_id: appId,
+        targetPath,
+        force: flags.force === true,
+        // `lotics app versions` lists the ids. Give it a NEW path to read an old
+        // revision without disturbing the project you are working in.
+        version: flags.fromVersion
+      });
       return;
     }
     if (subcommand === "deploy") {

package/docs/cli_reference.md

@@ -29,8 +29,8 @@ Per-command syntax, flags, contracts, and gotchas for the public `lotics` CLI. S
 | `lotics knowledge update <id> [--from <file.md> \| --content <str>] [--name <n>] [--description <d>]` | Call `update_knowledge` with **only** the provided fields (a body from --from/--content becomes `content`; the tool diffs + CASes the content change internally, so the CLI passes no `expected_content_file_id`). At least one field required; --from and --content are mutually exclusive. |
 | `lotics knowledge rm <id>` | Archive the doc via `delete_knowledge` (`{ knowledge_doc_id }`). The REST execute path does not gate `needsApproval`, so this runs unattended. |
 | `lotics app create <name> [path]` | Scaffold a Vite+React+TS custom-code app project; POST /v1/apps; npm install; vite build; upload as v1 |
-| `lotics app pull <app_id> [path]` | Download source archive from R2 (presigned), extract, npm install, stamp package.json's `lotics` field. With no `[path]`: refresh the cwd IN PLACE when it's already this app's own project (its manifest `app_id` matches — the documented `cd <app> && lotics app pull` flow), else clone into an `<name>/` subdir; this avoids the stray nested `./<name>/` subdir a pull-from-inside-the-app used to drop. **A pull never overwrites a file that differs from what it is about to write** — it writes only what is ABSENT or already identical, keeps the rest, and reports which files it kept plus the commands that close the gap. An in-place refresh used to replace uncommitted work silently, since `tar -xzf` overwrites unconditionally and the command still exits 0. The same rule covers the two kinds the archive does NOT carry — `src/workflows/<alias>.ts` and `src/agents/<alias>.md`, both rewritten from the live row on every pull — so an unpushed body or prompt survives too. The comparison is against the app's own content, not git, so it holds for a project that was never a repo. `--force` takes the app's copy and DISCARDS local edits; there is no other way to lose them. — `workflows` and `agents` are sourced from the live App row (NOT the archived manifest), so `set_app_workflow` / `set_app_agent` authoring survives the pull. Regenerates `.lotics/app_{workflows,queries,agents}.d.ts` so `useWorkflow` / `useQuery` / `useAgentRun` stay typed, AND the runtime `.lotics/app_fields.ts` (the same linked-vs-bespoke branch `app codegen` runs, off the app row already fetched — see that row for the two forms). That one is not optional: `app deploy` tars source with `--exclude=.lotics`, so no archive can carry it, and a pulled project whose `src/` imports `F`/`OPT` would fail to build with `Could not resolve "../../.lotics/app_fields"` until `app codegen` was run by hand. The write NAMES the form and the reason, because an in-place pull can FLIP a project between them (`opctl app publish` links an origin, `package eject` unlinks it) and that changes what the module does at load. Skipped under `--view-as` (the schema is read as that member and silently drops tables they cannot see — a narrowed `F` map compiles and then throws at runtime, worse than the missing module). A binding/schema fetch failure is non-fatal and names the right recovery for what is on disk: an existing file is kept, an ABSENT one warns about the build error and points at `app codegen`. Pull GENERATES but never RECONCILES `.lotics/` — deleting a companion whose alias the manifest no longer declares is `app codegen`'s alone, since pull's authority is the server's alias set and a declared-but-not-yet-`set` alias is supported. Also writes one `src/workflows/<alias>.ts` per bound workflow (faithful body from `get_app_workflow`) and one `src/agents/<alias>.md` per bound agent (its instructions, straight off the live row) — so the prose an author actually edits lives in a file, and pull always overwrites it from live, leaving no second copy to drift. A legacy workflow alias with no rendered source, or an agent with no instructions, warns and is skipped. The stamped `lotics.agents` map carries the TYPED half only (`inputs`/`outputs`/`tool_names`/`model_tier`/…) — an agent's prose lives solely in its `.md`, so there is never a second local copy to desync; a stale `instructions` left by an older CLI is inert and disappears on the next pull |
-| `lotics app deploy -m <message>` | `-m` is OPTIONAL — omitted, the deploy derives the version message from what it actually pushed. Requiring it was the most common real failure in CLI telemetry, and a hard stop yields a retry plus filler rather than an audit trail; pass `-m` when you have a reason worth recording. npm run build; tar source + dist; POST /v1/apps/{id}/versions multipart. **One command ships everything**: before the bundle moves, a deploy pushes every binding the project has ahead of the app — an edited workflow body or declaration, edited agent prose, a changed query — through `set_app_query`, then `set_app_workflow`, then `set_app_agent`, and fails the release if any push is refused. That order is required: an agent declares the query and workflow aliases it may call, so pushing it before its own new query is refused. It never AUTHORS a binding itself — those verbs stay the single writers — and each push carries the fingerprint the project last saw live (`lotics.synced`), so a stale checkout is refused rather than overwriting another author's edit. `package.json` means the same thing for both artifacts: editing `lotics.agents.<alias>.inputs`/`outputs` is pushed exactly like the workflow equivalent (only those two fields — `set_app_agent` merges, so everything the manifest does not model is left untouched). It also regenerates `.lotics/app_fields.ts` before building, since the build INLINES it and which form is correct follows from whether the app is a package installation — a deploy that skipped it could ship an origin's baked ids into every other install. `lotics app check` reports the same set without pushing; neither has a `--strict`. Deploy also sends the manifest's `lotics.workflows` alias KEYS as `workflow_aliases`, recorded on the version row so `remove_app_workflow` can refuse to unbind an alias the served version still declares. After a successful deploy it warns about any alias the source CALLS that is NOT bound, and **unbinds the inverse** — bindings the app still serves that this bundle names nowhere. No flag: an orphan is a live, callable read path under the deployer's authority, and a deploy that adds bindings automatically but requires a decision to remove one just accumulates them. Unbinding runs AFTER the version is live, because the removal tools refuse an alias the SERVED version still declares — so doing it first is refused by the guard that makes it safe. It is skipped ENTIRELY (with a warning, never a failure) when the source computes an alias at run time, since the scan cannot tell which binding that reaches; that is the only case where the reference set is incomplete, because a binding is reachable from the bundle and from an agent's `query_aliases`/`workflow_aliases` and from nothing else — an app workflow carries no `on({...})` trigger, so no table event or schedule reaches one. A binding that will not unbind is reported and does NOT fail the release: the version is live and correct, and the leftover is the state every deploy left behind before this existed. |
+| `lotics app pull <app_id> [path]` | Download source archive from R2 (presigned), extract, npm install, stamp package.json's `lotics` field. With no `[path]`: refresh the cwd IN PLACE when it's already this app's own project (its manifest `app_id` matches — the documented `cd <app> && lotics app pull` flow), else clone into an `<name>/` subdir; this avoids the stray nested `./<name>/` subdir a pull-from-inside-the-app used to drop. **A pull never overwrites a file that differs from what it is about to write** — it writes only what is ABSENT or already identical, keeps the rest, and reports which files it kept plus the commands that close the gap. An in-place refresh used to replace uncommitted work silently, since `tar -xzf` overwrites unconditionally and the command still exits 0. The same rule covers the two kinds the archive does NOT carry — `src/workflows/<alias>.ts` and `src/agents/<alias>.md`, both rewritten from the live row on every pull — so an unpushed body or prompt survives too. The comparison is against the app's own content, not git, so it holds for a project that was never a repo. `--force` takes the app's copy and DISCARDS local edits; there is no other way to lose them. **`--from-version <apv_…>`** pulls an OLDER revision instead of the current one (`lotics app versions` lists the ids) — point it at a NEW path to read a previous revision without disturbing the project you are in. The manifest records the version actually written, never the live pointer, so a deploy from that checkout is refused by the version guard rather than shipping old source over newer. — `workflows` and `agents` are sourced from the live App row (NOT the archived manifest), so `set_app_workflow` / `set_app_agent` authoring survives the pull. Regenerates `.lotics/app_{workflows,queries,agents}.d.ts` so `useWorkflow` / `useQuery` / `useAgentRun` stay typed, AND the runtime `.lotics/app_fields.ts` (the same linked-vs-bespoke branch `app codegen` runs, off the app row already fetched — see that row for the two forms). That one is not optional: `app deploy` tars source with `--exclude=.lotics`, so no archive can carry it, and a pulled project whose `src/` imports `F`/`OPT` would fail to build with `Could not resolve "../../.lotics/app_fields"` until `app codegen` was run by hand. The write NAMES the form and the reason, because an in-place pull can FLIP a project between them (`opctl app publish` links an origin, `package eject` unlinks it) and that changes what the module does at load. Skipped under `--view-as` (the schema is read as that member and silently drops tables they cannot see — a narrowed `F` map compiles and then throws at runtime, worse than the missing module). A binding/schema fetch failure is non-fatal and names the right recovery for what is on disk: an existing file is kept, an ABSENT one warns about the build error and points at `app codegen`. Pull GENERATES but never RECONCILES `.lotics/` — deleting a companion whose alias the manifest no longer declares is `app codegen`'s alone, since pull's authority is the server's alias set and a declared-but-not-yet-`set` alias is supported. Also writes one `src/workflows/<alias>.ts` per bound workflow (faithful body from `get_app_workflow`) and one `src/agents/<alias>.md` per bound agent (its instructions, straight off the live row) — so the prose an author actually edits lives in a file, and pull always overwrites it from live, leaving no second copy to drift. A legacy workflow alias with no rendered source, or an agent with no instructions, warns and is skipped. The stamped `lotics.agents` map carries the TYPED half only (`inputs`/`outputs`/`tool_names`/`model_tier`/…) — an agent's prose lives solely in its `.md`, so there is never a second local copy to desync; a stale `instructions` left by an older CLI is inert and disappears on the next pull |
+| `lotics app deploy -m <message>` | `-m` is OPTIONAL — omitted, the deploy derives the version message from what it actually pushed. Requiring it was the most common real failure in CLI telemetry, and a hard stop yields a retry plus filler rather than an audit trail; pass `-m` when you have a reason worth recording. npm run build; tar source + dist; POST /v1/apps/{id}/versions multipart. **One command ships everything**: before the bundle moves, a deploy pushes every binding the project has ahead of the app — an edited workflow body or declaration, edited agent prose, a changed query — through `set_app_query`, then `set_app_workflow`, then `set_app_agent`, and fails the release if any push is refused. That order is required: an agent declares the query and workflow aliases it may call, so pushing it before its own new query is refused. A workflow's `description` is part of that push and is compared against the recorded baseline, not the live app — it lives on the workflow ROW, which `getApp` does not carry, so checking it live would cost one request per alias inside a deploy. It never AUTHORS a binding itself — those verbs stay the single writers — and each push carries the fingerprint the project last saw live (`lotics.synced`), so a stale checkout is refused rather than overwriting another author's edit. `package.json` means the same thing for both artifacts: editing `lotics.agents.<alias>.inputs`/`outputs` is pushed exactly like the workflow equivalent (only those two fields — `set_app_agent` merges, so everything the manifest does not model is left untouched). It also regenerates `.lotics/app_fields.ts` before building, since the build INLINES it and which form is correct follows from whether the app is a package installation — a deploy that skipped it could ship an origin's baked ids into every other install. `lotics app check` reports the same set without pushing; neither has a `--strict`. Deploy also sends the manifest's `lotics.workflows` alias KEYS as `workflow_aliases`, recorded on the version row so `remove_app_workflow` can refuse to unbind an alias the served version still declares. After a successful deploy it warns about any alias the source CALLS that is NOT bound, and **unbinds the inverse** — bindings the app still serves that this bundle names nowhere. No flag: an orphan is a live, callable read path under the deployer's authority, and a deploy that adds bindings automatically but requires a decision to remove one just accumulates them. Unbinding runs AFTER the version is live, because the removal tools refuse an alias the SERVED version still declares — so doing it first is refused by the guard that makes it safe. It is skipped ENTIRELY (with a warning, never a failure) when the source computes an alias at run time, since the scan cannot tell which binding that reaches; that is the only case where the reference set is incomplete, because a binding is reachable from the bundle and from an agent's `query_aliases`/`workflow_aliases` and from nothing else — an app workflow carries no `on({...})` trigger, so no table event or schedule reaches one. A binding that will not unbind is reported and does NOT fail the release: the version is live and correct, and the leftover is the state every deploy left behind before this existed. |
 | `lotics app versions [app_id]` | `GET /v1/apps/{id}/versions` — print deploy history newest-first (version number, timestamp, deployer name, build status, the `-m` message; `*` marks the currently-served version). app_id from the local manifest, or pass one to inspect any app without pulling it. Admin-only server-side (mirrors deploy + source download). Answers "what shipped, when, by whom" — e.g. whether a fix was live at an incident's time. The deploy pipeline already persisted all of this in `app_versions`; this is the read surface. Title → stderr, table → stdout (pipeable). |
 | `lotics app codegen [path]` | Regenerate `.lotics/*` from the manifest + workspace schema **without a deploy**. The three `.d.ts` companions (`app_{workflows,queries,agents}.d.ts`) are always rewritten (synchronous, no network). When credentials resolve, also rewrites the **runtime** `.lotics/app_fields.ts` — **branched on whether the app is a package installation** (`getApp().package_id` set, from `generate_package_fields.ts`): a **linked/published** app emits the BINDING form (`F`/`OPT`/`ROLE` resolved from the installation's LIVE binding — via `appBinding` / the `binding` RPC — at module load through `getAppBinding()` + top-level await, so the source stays portable across every install); a **bespoke** app emits the BAKED form (`generate_app_fields.ts`) — a real `.ts` exporting `F` (table→field→`"fld_…"`) + `OPT` (table→select-field→option→`"opt_…"`) keyed by display-name aliases, for the tables the app's queries reference (+ optional `package.json#lotics.codegen.tables` allowlist). Both forms share the `F`/`OPT` shape (contract aliases derive from the same slugified display names), so a published origin's deployed source compiles unchanged. Writing the BINDING form also heals the project's vitest setup (`ensureAppVitestSetup`, folded into the same write boundary): the binding form awaits `getAppBinding()` (a network call) at module load, so without a stub `npm test` fails to collect any test that imports the app graph — the heal writes `vitest.setup.ts` (mocks only `getAppBinding`, returning an echo binding: any alias → a self-identifying `fld:test:…`/`opt:test:…`/`grp:test:…` id) if absent, and warns the one-liner to add to `vite.config.ts`'s `test.setupFiles` if the wiring is missing (TS source isn't safely munged, mirroring `ensureAppTsconfig`'s JSONC-tsconfig warn). New scaffolds ship both. Also refreshes each bound workflow's `.lotics/workflows/<alias>.globals.d.ts` + re-wraps its EXISTING `src/workflows/<alias>.ts` body in the current envelope (strips + re-wraps; never re-fetches the body, so local edits survive). **`.lotics/` is reconciled to the manifest, not merely added to** — a `<alias>.globals.d.ts` whose alias the manifest no longer declares is DELETED (that directory is read as the app's alias inventory, so a companion for a binding nobody can reach misreports what the app has). Only that exact filename shape is removed; anything else in the directory is left alone. The reconcile runs before the credential branch, so it happens offline too. The authored counterpart is never deleted — a `src/workflows/<alias>.ts` the manifest does not declare is NAMED instead (`check` and `set` both take their alias set from the manifest, so editing an undeclared body is a silent no-op). A getApp / binding / schema / dts-fetch failure is non-fatal (warns, keeps the last-generated files). **Re-silvers `package.json#lotics.agents`** from the live app row whenever its `inputs`/`outputs` disagree, then rewrites the agent `.d.ts` from the refreshed block: that block is a mirror AND the offline seed for `useAgentRun` typings, so a stale copy types the app against an agent that does not exist. Refreshing here makes the divergence self-healing on a command already in the loop and keeps the remedy off `app pull` (which rewrites `src/workflows/*.ts` and would eat uncommitted body edits). The write is surgical and order-preserving (`orderedLike`), so it changes only the fields that actually differ. A hand edit to that block is therefore reverted — it never changed the agent anyway; to change one, `set_app_agent`. |
 | `lotics app check` | Every pre-flight `deploy` runs, WITHOUT building or shipping: the manifest's agent schemas against the live app row, every binding a deploy would push, aliases the source calls that nothing bound (queries, workflows AND agents), bindings the app serves that the source names nowhere, capability-gated SDK calls the manifest doesn't declare, a missing icon/theme, and a notice for any alias the source computes at runtime (invisible to every check here and to the deploy's unbind guard). Adds no rule of its own — each finding is the same helper `deploy` calls, so a green check means a deploy will not complain. **Exits 1 on what a `deploy` would REFUSE or PUSH** — an agent schema that disagrees with the live app, and any binding the project has ahead of the app (an edited workflow body or declaration, edited agent prose, a changed query). Both are things a deploy would act on, so CI gating on a green check means a deploy has nothing left to do; genuine advisories (capabilities, branding, a runtime-computed alias, orphaned bindings) stay advisory and never fail it. The point is the question being ASKABLE: these checks used to cost a build, a tar, an upload and a version row in the audit trail, which is expensive enough that the honest move was to skip them and find out in production. |

package/package.json

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