@protobase/cli 0.69.2 → 0.69.3

package/dist/cli/package.js

@@ -1,4 +1,4 @@
 //#region package.json
-var version = "0.69.2";
+var version = "0.69.3";
 //#endregion
 export { version };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@protobase/cli",
-  "version": "0.69.2",
+  "version": "0.69.3",
   "description": "The protobase command: scaffold, doctor, dev, build and serve a Protobase project.",
   "license": "Apache-2.0",
   "repository": {
@@ -43,13 +43,13 @@
   "dependencies": {
     "@better-auth/core": "^1.7.12",
     "@hono/node-server": "^2.1.3",
-    "@protobase/config": "0.69.2",
-    "@protobase/layout": "0.69.2",
-    "@protobase/query": "0.69.2",
-    "@protobase/schema": "0.69.2",
-    "@protobase/server": "0.69.2",
-    "@protobase/ui": "0.69.2",
-    "@protobase/workflows": "0.69.2",
+    "@protobase/config": "0.69.3",
+    "@protobase/layout": "0.69.3",
+    "@protobase/query": "0.69.3",
+    "@protobase/schema": "0.69.3",
+    "@protobase/server": "0.69.3",
+    "@protobase/ui": "0.69.3",
+    "@protobase/workflows": "0.69.3",
     "@react-email/render": "^2.1.0",
     "@scalar/hono-api-reference": "^0.12.10",
     "@sentry/vite-plugin": "^11.10.0",

package/skills/protobase/references/reference/workflows.md

@@ -235,11 +235,10 @@ A workflow names the account each of its connections uses in its definition's `c
 - **Turning it on is the consent.** A workflow that uses a connection is turned on only by the owner of every account it names, signed in as themselves. Someone else, staff signed in as the owner, and an outside app acting for them get a `403` problem (`own-sign-in-only`), the same for an account that is not there. Over MCP, `enable_workflow` answers that the owner turns it on in the admin app. A save that keeps such a workflow on is turned on again by the person saving it, so only the owner saves it while it is on; anyone else turns it off first.
 - **At run time:** each time a step or trigger asks for a token, the app checks again. The version it runs must name the account, the person who turned that version on must own it, and that person must still be allowed to change the workflow in its tenant. Otherwise the step fails with `not_connected`. The same happens once the workflow is turned off, once the account is disconnected, and once that person lost the right to change workflows, even between two requests of one step. A run never records the token.
 - **Signing in again:** when the provider refuses a refresh token (`invalid_grant`), the step fails with `link_expired`, and every trigger on that account waits as `needs_sign_in`. The Connections section marks the account. Connecting the same account again, without disconnecting it first, resumes the triggers from where they stopped. A refresh that fails otherwise, as when the provider is down, fails only that try, which a `Retry` or the next poll repeats, and the account stays connected.
+- **Turning it off:** turning the workflow off, turning on a version with another trigger, or deleting the workflow ends a webhook trigger's subscription at the provider. The stop signs in through the account the subscription was made with, as the person who turned that version on, for that one call only; runs and steps still get `not_connected`. While that account is disconnected or no longer that person's, or when the provider refuses its sign-in, the trigger stays `stopping` in `workflow_triggers` with `not_connected`, as does one turned on before the app recorded who turned it on.
 
 A workflow uses one person's accounts: one whose connections name accounts of two people can never be turned on.
 
-<gap>Turning off a workflow whose webhook trigger signs in through a connection cannot end its subscription at the provider because the consent ends with the workflow and an unsubscribe that outlives it is not implemented; the trigger stays `stopping` with that error in `workflow_triggers`.</gap>
-
 ## Step types
 
 The built-in step types are the `app` plugin's, written on the same [plugin interface](workflow-plugins.md) as any other; a plugin's step is a Task with `"Resource": "<plugin>:<key>"`. A step's `Arguments` are checked against its type's input schema before it runs: one that does not fit fails as `<Prefix>.InvalidArguments`, such as `Http.InvalidArguments`.