@protobase/cli 0.67.4 → 0.67.5

package/dist/cli/package.js

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

package/package.json

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

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

@@ -642,7 +642,7 @@ It is Better Auth's organization plugin, with its tables named in snake_case (`o
 
 **The organization in the token.** A new session starts in the organization the person last worked in, else their oldest membership. `/api/auth/token` adds `org` (the organization), `org_role` and `app_roles` (the membership's, narrowed to the active role), read when the token is issued; a removed member's token, or one carrying an app role taken away, [stops working](#when-a-token-stops-working) on its next request. The app's authenticator makes `org` the tenant and `ctx.organization.id`, and adds `app_roles` to the global roles. `POST /api/auth/organization/switch` with `{ organizationId }` moves the session; the next token names the new organization, without signing in again. Someone with a global role may switch into any organization, without being a member, and sees there what those roles allow; each such entry is an `organization.entered` [audit event](api.md#audit-events). `GET /api/auth/organization/search?query=&offset=` lists every organization for them, ordered by slug, 20 at a time with the `total`, narrowed by text in the name or slug; the Organizations page shows it as All organizations. A list across every organization stays a resource without `.tenant`, readable by the global role; a list across the organizations someone is a member of is a `.tenant` resource with `across: 'memberships'` (see [Lists across organizations](access.md#lists-across-organizations)).
 
-**Invitations.** Better Auth's `POST /api/auth/organization/invite-member` with `{ organizationId, email, role, appRoles }`; inviting again replaces the earlier invitation, and it works for `invitationDays` (default 7). The email links to `{url}/-/invitation?token=…` (`invitationUrl`), with a token signed with the app's `secret`, since members can read invitation ids; without a mailer, the answer carries the `link` to pass on. The link page shows `GET /api/auth/invitation?token=`, accepts with `POST /api/auth/invitation/accept` for someone signed in as the invited address, and makes an account with `POST /api/auth/invitation/sign-up` (`{ token, name, password? }`) for an address without one. Someone signed in sees the invitations for their own address with Better Auth's `GET /api/auth/organization/list-user-invitations`, on the organizations page, and accepts one there with `POST /api/auth/invitation/accept-own` (`{ invitationId }`). The link page and its sign-up serve [invitations to the app](#users-page) too. [Open sign-up](#open-sign-up) is not available with organizations: an invitation is the address someone vouched for.
+**Invitations.** Better Auth's `POST /api/auth/organization/invite-member` with `{ organizationId, email, role, appRoles }`; inviting again replaces the earlier invitation, and it works for `invitationDays` (default 7). The email links to `/-/invitation?token=…` on the origin the invitation was made on ([several origins](#several-origins)), or to `invitationUrl`, with a token signed with the app's `secret`, since members can read invitation ids; without a mailer, the answer carries the `link` to pass on. The link page shows `GET /api/auth/invitation?token=`, accepts with `POST /api/auth/invitation/accept` for someone signed in as the invited address, and makes an account with `POST /api/auth/invitation/sign-up` (`{ token, name, password? }`) for an address without one. Someone signed in sees the invitations for their own address with Better Auth's `GET /api/auth/organization/list-user-invitations`, on the organizations page, and accepts one there with `POST /api/auth/invitation/accept-own` (`{ invitationId }`). The link page and its sign-up serve [invitations to the app](#users-page) too. [Open sign-up](#open-sign-up) is not available with organizations: an invitation is the address someone vouched for.
 
 **Members.** Better Auth's `list-members`, `update-member-role`, `remove-member` and `leave`; `POST /api/auth/organization/set-app-roles` (`{ memberId, appRoles }`); `POST /api/auth/organization/transfer-ownership` (`{ memberId, keepAs? }`) makes a member owner and the caller an admin in one step. `GET /api/auth/organization/current` answers the organization a session works in with the caller's roles there. `GET /api/auth/organization/people` answers the members of that organization to any of its members, as `{ people: [{ id, name, image? }] }` with `id` the user id and no email addresses; anyone who is not a member of it, signed out or with a global role only, is refused.
 
@@ -795,7 +795,7 @@ url: 'https://erp-x1.protobase.net',
 auth: { origins: ['https://admin.shop.com'], passkeyDomain: 'admin.shop.com' },
 ```
 
-- A request to one of them is answered for its own host: the sign-in callbacks, the [password reset](#password-reset) link and its `redirectTo`, and a [staff sign-in](#staff-sign-in) stay there. A request to any other host is answered for the app's `url`.
+- A request to one of them is answered for its own host: the sign-in callbacks, the [password reset](#password-reset) link and its `redirectTo`, an invitation link, to the [app](#users-page) or an [organization](#organizations), unless `invitationUrl` names another page, and a [staff sign-in](#staff-sign-in) stay there. A request to any other host is answered for the app's `url`.
 - Tokens keep the app's `url` as issuer and audience, whichever origin issued them, so the API takes them on every origin.
 - Sessions are cookies of each host: a person signs in once per origin.
 - `GET /.well-known/webauthn` answers `{ "origins": [...] }` with every origin of the app, on each of them, so its [passkeys](#passkeys) work on all. `protobase serve` and `protobase dev` send that path to the server, whatever the bundle's `api` says; a host in front must too.

package/skills/protobase/references/reference/config/sign-in.md

@@ -53,7 +53,7 @@ export default defineConfig({ auth: { roles: ['admin', 'sales', 'warehouse'], de
 - **Type:** `true | { create?: 'admins' | 'everyone'; creatorAppRoles?: 'all' | string[]; invitationDays?: number; membershipLimit?: number; deleteRecords?: 'refuse' | 'cascade'; invitationUrl?: string }`
 - **Default:** off: the app works as one organization
 
-Turns on organizations: people work in one at a time, records of `.tenant` resources are scoped to it, and roles are held globally or per membership. `create` is who may create one (default `admins`), `creatorAppRoles` the roles its creator holds there (default `all`), `invitationDays` how long an invitation works (default 7), `membershipLimit` the most members (default 1000), `deleteRecords` whether deleting one is refused while it has records (`refuse`, the default) or left to the foreign keys (`cascade`), and `invitationUrl` the page an invitation opens (default `<url>/-/invitation`). Its hooks are in `auth/hooks.ts`. See [Organizations](../auth.md#organizations).
+Turns on organizations: people work in one at a time, records of `.tenant` resources are scoped to it, and roles are held globally or per membership. `create` is who may create one (default `admins`), `creatorAppRoles` the roles its creator holds there (default `all`), `invitationDays` how long an invitation works (default 7), `membershipLimit` the most members (default 1000), `deleteRecords` whether deleting one is refused while it has records (`refuse`, the default) or left to the foreign keys (`cascade`), and `invitationUrl` the page an invitation opens (default `/-/invitation` on the origin the invitation was made on). Its hooks are in `auth/hooks.ts`. See [Organizations](../auth.md#organizations).
 
 ```ts
 export default defineConfig({ auth: { organizations: { create: 'everyone', invitationDays: 14 } } })

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

@@ -49,7 +49,7 @@ Every commit message follows [Conventional Commits](https://www.conventionalcomm
 3. The tag is pushed, and the GitHub release of the tag gets the notes.
 4. Beside the checks, a pack job takes the tag `bun run release --dry-run` predicts, and `scripts/stamp-version.mjs` writes its version into every `package.json` and `bun.lock` in the runner, never committed. `scripts/publish.mjs --pack --out` then builds every package to `dist` and packs it with Bun (the private `@protobase/presets` is not published). Once the tag is pushed, npm, under Node, publishes those tarballs with [trusted publishing](https://docs.npmjs.com/trusted-publishers) and provenance (`scripts/publish.mjs --from`); there is no npm token, and only the publish job holds the identity token it needs. A tag other than the version the tarballs were stamped with fails the publish before anything is uploaded, and a run that cut no release packs and publishes nothing.
 5. Once npm serves the packages, the tag's version is written into the `package.json` files the same way, and `bun run images:context <image>` writes each image's build context at the tag from them, and the images are built natively for `linux/amd64` and `linux/arm64` and pushed to GitHub's registry as `ghcr.io/prototeamhq/protobase:<version>` and `ghcr.io/prototeamhq/protobase-dev:<version>` (see [Deploy](../guides/deploy.md#images)). A release whose publish failed has no images.
-6. Once npm serves the packages, `scripts/bump-repos/main.ts` starts the `protobase-bump.yml` workflow, with the release's version, of each repository the `PROTOBASE_BUMP_REPOS` secret lists, using the `PROTOBASE_BUMP_TOKEN` secret; an unset or empty list bumps nothing. Each listed repository owns that workflow, with a `version` input: it moves the repository's `@protobase` packages to the release in a pull request of its own, which merges itself once its CI is green and otherwise stays open for a fix. A repository that cannot be started within a minute fails the job after the others were started, and nothing else waits on it.
+6. Once npm serves the packages, `scripts/bump-repos/main.ts` starts the `protobase-bump.yml` workflow, with the release's version, of each repository the `PROTOBASE_BUMP_REPOS` secret lists, using the `PROTOBASE_BUMP_TOKEN` secret; an unset or empty list bumps nothing, and an unset token bumps nothing with a warning in the run's summary that counts the repositories left unbumped. Each listed repository owns that workflow, with a `version` input: it moves the repository's `@protobase` packages to the release in a pull request of its own, which merges itself once its CI is green and otherwise stays open for a fix. A repository that cannot be started within a minute fails the job after the others were started, and nothing else waits on it.
 
 When `main` moved on while the checks ran, the run of the newer push releases both. `bun run release --dry-run` prints the next version and its notes without tagging anything.