@protobase/cli 0.69.3 → 0.70.1

package/dist/cli/package.js

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@protobase/cli",
-  "version": "0.69.3",
+  "version": "0.70.1",
   "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.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",
+    "@protobase/config": "0.70.1",
+    "@protobase/layout": "0.70.1",
+    "@protobase/query": "0.70.1",
+    "@protobase/schema": "0.70.1",
+    "@protobase/server": "0.70.1",
+    "@protobase/ui": "0.70.1",
+    "@protobase/workflows": "0.70.1",
     "@react-email/render": "^2.1.0",
     "@scalar/hono-api-reference": "^0.12.10",
     "@sentry/vite-plugin": "^11.10.0",

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

@@ -24,4 +24,4 @@ Graphs of steps the server runs along their edges, written in a language a model
 - [Guarded requests for plugins](../reference/workflow-plugins.md#sending-requests) (beta): A plugin's requests reach only public addresses, follow no redirect and read at most 10 MiB.
 - [Webhook trigger](../reference/workflows.md#appwebhook) (beta): A workflow starts from a signed call to a URL of its own, limited in size and rate.
 - [Polling triggers](../reference/workflow-plugins.md#polling-and-webhook) (beta): A workflow starts once for each new item a plugin finds on a schedule, or at each time of a cron with `app:schedule`.
-- [Connected accounts](../reference/workflows.md#connecting-an-account) (beta): People connect their own accounts at other services through OAuth from the account page, see which workflows use each one, and MCP clients list them to bind. A workflow's steps and triggers sign in with one only once its owner turned the workflow on, with tokens encrypted and refreshed. Disconnecting deletes the token, and revokes it at a provider that has a revocation endpoint and answers.
+- [Connected accounts](../reference/workflows.md#connecting-an-account) (beta): People connect their own accounts at other services through OAuth from the account page, see which workflows use each one, and MCP clients list them to bind. A workflow's steps and triggers sign in with one only once its owner turned the workflow on, with tokens encrypted and refreshed. Disconnecting deletes the token and revokes it at a provider that has a revocation endpoint, trying again for a few hours when the provider does not take it.

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

@@ -379,7 +379,7 @@ On their account page, people turn on a second step after a password or an email
 - **Authenticator app:** the page shows a QR code (and the key, to type in), the person confirms it with a code from the app, and gets ten backup codes that each work once instead of a code. New backup codes replace the old ones.
 - **Emailed code:** with mail configured, a 6-digit code mailed at each sign-in, valid for 10 minutes. An account with an app can also choose an emailed code at sign-in. Backup codes come with the app only.
 
-Turning it on, off, or making new backup codes asks for the account's password when it has one. Without one, turning it on from a session that signed in more than a day ago, on an account without a passkey, asks to [confirm it's them](#confirming-an-account-change) first. At sign-in, a correct password or code answers `{ "twoFactorRedirect": true, "twoFactorMethods": ["totp", "otp"] }` instead of a session, and `POST /api/auth/two-factor/verify-totp`, `verify-otp` or `verify-backup-code` with `{ code, trustDevice? }` finishes it; `trustDevice` skips the step in that browser for 30 days. Ten wrong codes in a row lock the account's second step for 15 minutes.
+Turning it on, off, or making new backup codes asks for the account's password when it has one. Without one, turning it on, reading the authenticator link (`/two-factor/get-totp-uri`) or making new backup codes from a session that signed in more than a day ago asks to [confirm it's them](#confirming-an-account-change) first, and the account page asks for it in place. At sign-in, a correct password or code answers `{ "twoFactorRedirect": true, "twoFactorMethods": ["totp", "otp"] }` instead of a session, and `POST /api/auth/two-factor/verify-totp`, `verify-otp` or `verify-backup-code` with `{ code, trustDevice? }` finishes it; `trustDevice` skips the step in that browser for 30 days. Ten wrong codes in a row lock the account's second step for 15 minutes.
 
 Sign-in with GitHub or another [provider](#sign-in-with-github) is not asked for the second step.
 
@@ -406,7 +406,7 @@ An account with neither a passkey nor a second step has nothing stronger to conf
 Better Auth's own check of a fresh session, which could only be met by signing out and in again, is off (`freshAge: 0`). In its place, a session that signed in more than a day ago confirms it's them in place, as above, before a change that needs it, else the change is `403 STRONG_SIGN_IN_REQUIRED`; the confirmation counts for 15 minutes:
 
 - adding a passkey;
-- turning on [two-factor authentication](#two-factor-authentication) on an account without a password, a passkey or a second step (an account with a password gives it instead);
+- turning on [two-factor authentication](#two-factor-authentication), reading its authenticator link or making new backup codes, on an account without a password (an account with a password gives it instead);
 - unlinking a sign-in provider (`/unlink-account`);
 - [deleting the account](#deleting-the-account) without a password.
 

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

@@ -223,7 +223,7 @@ A save also refuses a Task that leaves out an argument its step type needs, such
 Each connected account belongs to the person who connected it, and only that person can turn on a workflow that uses it.
 :::
 
-A trigger or step type that signs in to another service, such as a mailbox, uses an account that someone connected. Each person connects their own accounts on the **Connections** section of the account page's Profile tab. Connecting takes them to the provider and back. Under each account, the section links each workflow that uses it: those the person turned on, whose enabled version binds the account, while they may still change them. The app keeps the account's tokens on the server, encrypted, and refreshes them when they expire. **Disconnect** always deletes the token, so no step or trigger can use it again. When the connection has a revocation endpoint, it first asks the provider to revoke the token. A provider that does not answer or refuses keeps the token valid on its side, and the answer's `revoked` is false. A trigger that uses the account stops as `needs_sign_in`. Connecting again makes a new account with a new id: bind it in the workflow's `connections` and turn the workflow on again. Revoking at Google ends everything the account allowed the app, the sign-in and a linked mailbox included, and the dialog says so.
+A trigger or step type that signs in to another service, such as a mailbox, uses an account that someone connected. Each person connects their own accounts on the **Connections** section of the account page's Profile tab. Connecting takes them to the provider and back. Under each account, the section links each workflow that uses it: those the person turned on, whose enabled version binds the account, while they may still change them. The app keeps the account's tokens on the server, encrypted, and refreshes them when they expire. **Disconnect** always deletes the token, so no step or trigger can use it again. When the connection has a revocation endpoint, it first asks the provider to revoke the token. When the provider does not answer or refuses, the answer's `revoked` is false, and the app tries again later, waiting from a minute up to an hour between tries, ten tries in all. Until then it keeps the token encrypted with the app's secret, in the workflows schema's `connection_revocations`, and drops it once the provider takes it, after the last try, or once the app's secret no longer decrypts it. A provider that never takes it keeps the token valid on its side. Disconnecting answers `503` (`CONNECTIONS_STARTING`) and keeps the account while the workflows have not started, so a token the provider does not take is never dropped unqueued. The auth endpoint `/unlink-account` refuses an account that Connections lists (`403`, `CONNECTION_UNLINK_REFUSED`): disconnect it there. A trigger that uses the account stops as `needs_sign_in`. Connecting again makes a new account with a new id: bind it in the workflow's `connections` and turn the workflow on again. Revoking at Google ends everything the account allowed the app, the sign-in and a linked mailbox included, and the dialog says so.
 
 A workflow names the account each of its connections uses in its definition's `connections`, by `<plugin>:<connection>` and the account's id, which the Connections section shows, as does `list_connections` [over MCP](mcp.md#workflows):