@abloatai/ablo 0.64.2 → 0.64.3

package/CHANGELOG.md

@@ -1,5 +1,51 @@
 # Changelog
 
+## 0.64.3
+
+### Existing connections make room for new tables
+
+`ablo connect apply --tables` now checks the requested tables even when an
+existing connection reports ready. It reconciles publication membership before
+returning, keeping existing credentials intact. If a snapshot needs recovery,
+the requested tables are reconciled before that recovery begins; a snapshot
+already in progress is left undisturbed.
+
+Generated PostgreSQL setup also includes the replica identity needed to retain
+old row values for updates and deletes. The companion sync-server changes track
+snapshot coverage against the active schema, so adding a model cannot inherit
+an older snapshot's readiness. Those server changes require a runtime rollout;
+upgrading the CLI alone does not deploy them.
+
+### One session mint at browser startup
+
+A cold reactive client now uses its first session credential to resolve identity,
+avoiding a second call to the application's session endpoint and its membership
+checks. Later refreshes still obtain a fresh credential. The React guide also
+clarifies application-owned disposal, account switching and startup retry.
+
+The browser packages now include their event emitter dependency. Applications
+can bundle the React entry with an ordinary browser bundler without supplying a
+Node `events` polyfill themselves.
+
+### A clearer boundary for customer accounts
+
+The customer-isolation guide now follows one application connection, explicit
+model subject rules and sessions minted from verified membership. It separates
+your application's account IDs from Ablo organization, project and branch scope,
+and explains what must change in writers, existing rows and database policies
+when adopting that model. Session and API-key guidance use the same distinction.
+
+### Prepare schema SQL without a connection
+
+`ablo migrate --offline` generates schema SQL without database credentials or an
+Ablo API key. It prints the SQL or writes it with `--output`, using the same
+planner as a connected migration. The output is explicitly unvalidated: applying
+a migration still requires the connected deployment checks, as do previews that
+omit `--offline`.
+
+This release introduces no breaking API changes. Ablo, Transaction, Humans and
+the CLI are published together at 0.64.3.
+
 ## 0.64.2
 
 ### More complete upgrade guidance

package/docs/api-keys.md

@@ -234,7 +234,7 @@ Both management scopes are explicit grants on `mk_` credentials. Runtime
 `sk_`, `rk_`, `pk_`, and `ek_` credentials cannot become management
 credentials through an empty scope set or a CLI fallback.
 
-Branch binding remains an authority boundary even when a key has no granular
+For ordinary application keys, branch binding remains an authority boundary even when a key has no granular
 scope strings: a temporary child key can act only inside that child. It cannot
 manage siblings or gain root authority.
 
@@ -253,11 +253,23 @@ Treat that key as a dedicated minting credential:
 - rotate it on a schedule and revoke it immediately after suspected exposure;
 - log the target `organizationId`, minted session id, and request id for audit.
 
-The scope's broad name describes the cross-organization check it passes, not
-the authority of each resulting session. The session can act only inside the
-named customer organization and only for the models/verbs in `can`. See
-[Customer Organizations](./customer-organizations.md) for the complete
-integration.
+The issuer's `organization:act-as` grant can target **any organization**. Ablo
+does not enforce an application-customer allowlist for that authority. A resulting
+session is restricted by its target organization, model operations and expiry,
+but restricting a session does not narrow the issuer's power to mint another.
+Cross-organization mints select the target organization's root branch, including
+when the issuer is bound to a child branch.
+
+Normal dashboard key provisioning does not grant this scope. Ablo operators
+provision it using `apps/sync-server/scripts/provision-platform-key.ts` with
+`--org=<issuer-org> --branch=<issuer-branch> --env=sandbox` (or `production`). The
+script requires control-plane database access and emits a new secret once.
+The environment flag controls the credential prefix; it does not force target
+sessions onto a staging branch.
+
+For customers sharing one application, use model subject rules and verified
+session groups with an ordinary application key. See
+[Serving Many Customers](./customer-organizations.md).
 
 ## Current and legacy key spellings
 

package/docs/cli.md

@@ -133,7 +133,7 @@ branch-bound runtime credential before starting application code.
 | `ablo branch list\|status\|check\|create\|ensure\|credential\|delete` | Manage and diagnose immutable branch planes and expiring credentials.                          | Run `ablo branch --help`; use `--json` for automation.                                                   |
 | `ablo logs`                        | Tail the resolved runtime credential's branch activity. Follows by default.                                                                          | `-n, --tail <N>`, `--since <dur\|ts>`, `--model`, `--op`, `--json`, `--no-follow` |
 | `ablo push`                        | **Hosted**: upload the schema to Ablo; the server diffs, migrates, and activates it.                                                         | `--force`, `--rename old:new`, `--backfill model.field=value`, `--schema`, `--export`, `--url`         |
-| `ablo migrate`                     | **Direct Postgres**: provision just the synced models (plus the adapter's `ablo_outbox` / `ablo_idempotency`) in your own `DATABASE_URL`. Leaves your other tables alone.                                                          | `--dry-run`, `--output <file>`, `--schema`, `--export`                                                 |
+| `ablo migrate`                     | **Direct Postgres**: provision just the synced models (plus the adapter's `ablo_outbox` / `ablo_idempotency`) in your own `DATABASE_URL`. Leaves your other tables alone.                                                          | `--offline`, `--dry-run`, `--output <file>`, `--schema`, `--export`                                                 |
 | `ablo pull`                        | **Direct Postgres**: generate `defineSchema(...)` from your existing tables (read-only, like `prisma db pull`).                              | `--out <path>`, `--app-schema <name>`, `--import <pkg>`, `--force`                                     |
 | `ablo check`                       | **Direct Postgres**: verify your _existing_ tables fit the schema (read-only, no schema changes).                                                       | `--schema <path>`, `--export <name>`, `--app-schema <name>`                                            |
 | `ablo connect plan\|apply\|check\|rotate\|deregister` | **Direct Postgres**: register and maintain a database plane. Here `--schema` means the existing PostgreSQL namespace, never a TypeScript file. | `--url <postgres-url>`, `--schema <postgres-schema>`, `--env-file <path>`, `--yes` |
@@ -266,9 +266,16 @@ server applies the change and version-gates connecting clients.
 ```bash
 ablo migrate --dry-run            # preview the exact SQL
 ablo migrate                      # apply to DATABASE_URL
-ablo migrate --output schema.sql  # write SQL to a file
+ablo migrate --output schema.sql  # write SQL to a file after connected validation
+ablo migrate --offline --output schema.sql  # generate SQL without credentials
 ```
 
+`--offline` uses the same schema SQL generator without reading database or Ablo
+credentials. Omit `--output` to print SQL. This is schema generation, not a
+validated deployment plan: it cannot detect existing-data conflicts or drift.
+Run `ablo migrate` with credentials to validate and apply; `--dry-run` and
+`--output` without `--offline` retain connected validation.
+
 ### One database, two schemas
 
 `ablo migrate` does **not** own your whole database. It creates exactly the

package/docs/customer-organizations.md

@@ -1,184 +1,147 @@
 # Serving Many Customers
 
-> One account, one schema, and a session scoped to the customer whose data it may read.
+> One application connection, customer subject rules, and sessions minted from verified membership.
 
-Serving many customers from one backend has two shapes, and the first question
-is whether isolating them is a security boundary or a routing convenience.
+For a multi-account application, keep one Ablo organization, one project for the
+application, and one branch per environment. Your customers remain rows in your
+own database. Their existing account IDs can identify the subjects authorized by
+Ablo; they do not need corresponding Ablo account registrations.
 
-**Use a model `subject` rule for account isolation inside one project.** Bind
-`accountId` to the `account` group, mint sessions only after verifying membership,
-and use those scoped sessions for server operations too. The complete
-[account multiplayer walkthrough](./examples/account-multiplayer.md) shows this
-composition and its verification path.
+## What each layer owns
 
-A separate Ablo organization per customer is another tenant boundary. It is not
-required merely because your application has accounts.
+| Layer | Meaning | Boundary |
+| --- | --- | --- |
+| Ablo organization | Your team's Ablo account | Outer organization authority |
+| Project | Your application and its schema | Application data plane |
+| Branch | An environment of that application | Connection, retained log and branch-bound credentials |
+| Customer subject | An account in your application | A model rule checks the row against verified session groups |
+| Session | One human or agent's granted access | Subject membership, model operations and expiry |
 
-**Sync-group routing alone is not subject authorization.** The older routing-only
-example below illustrates delivery configuration; add subject rules before using
-that pattern as a customer security boundary. The limitations below describe
-models without subject rules, not subject-protected models.
+`organizationId` on a session names the outer Ablo organization. It does not
+select an account inside your application. A model's `subject` declares that
+inner boundary; session `groups` supplies the authenticated membership needed
+to pass it. Routing groups alone are not row authorization.
 
-```ts
-// 1. src/ablo/schema.ts — your customer table is a scope root.
-import { defineSchema, identityRole, relation, model, z } from '@abloatai/ablo/schema';
-
-export const schema = defineSchema(
-  {
-    // Its rows form the group `customer:<id>`; the kind comes from `groups.root`.
-    customers: model(
-      { name: z.string() },
-      { groups: { root: 'customer' } },
-    ),
-    // A child inherits its customer's group through the `parent` edge.
-    decks: model(
-      { customerId: z.string(), title: z.string() },
-      { relations: { customer: relation.belongsTo('customers', 'customerId', { parent: true }) } },
-    ),
-  },
-  {
-    identityRoles: [
-      identityRole({ kind: 'org', source: 'organizationId' }),
-      identityRole({ kind: 'user', source: 'userId' }),
-    ],
-  },
-);
-```
+## Declare the customer boundary
+
+Use an explicit required account field on every customer-protected model:
 
 ```ts
-// 2. app/api/ablo-session/route.ts — mint for one customer, on your backend.
-import { syncGroup } from '@abloatai/ablo/schema';
-import { sessions } from '@/ablo/sessions';
-
-export const POST = sessions.handler({
-  authenticate: () => currentSignedInMember(),
-  grant: ({ principal: member }) => ({
-    user: { id: member.userId },
-    can: { customers: ['read'], decks: ['read', 'create', 'update'] },
-    groups: [syncGroup('customer', member.customerId)],
-  }),
+import { defineSchema, model, z } from '@abloatai/ablo/schema';
+
+export const schema = defineSchema({
+  conversationSummaries: model({
+    accountId: z.string().min(1),
+    title: z.string(),
+  }, { subject: { field: 'accountId', group: 'account' }, load: 'instant' }),
 });
 ```
 
-That is the whole integration. The rest of this page is why each line is where
-it is.
-
-## What each layer is
-
-Four things carry a name in this arrangement, and mixing two of them up is the
-one mistake worth spending a page to prevent.
-
-| Layer | What it is | Where it lives |
-|---|---|---|
-| Your account | The organization you signed up with. Colleagues join it with their own logins and share one bill. | Ablo |
-| Your application | A project. One per app you run, bound to one schema in your database. | Ablo |
-| Your customer | A row in your own table, with your own id on it. | Your database |
-| One person's session | An `ek_` your backend mints, cut to one customer's group. | Minted per sign-in |
-
-Your customers sit in the third row. They are not accounts, because an account
-is something you invite colleagues into. They are not projects, because a
-project binds to a Postgres schema and you run one application, not one per
-customer.
-
-Your `sk_` already carries your account, so a session never names it. What the
-session adds is which customer the person in front of it may read.
-
-## Where the boundary is enforced
+The subject rule requires the session to hold `account:<row.accountId>`. Keep
+account IDs from Better Auth, or another membership system, in this field.
+The outer tenancy column `organization_id` retains the owning Ablo organization;
+it is not a second name for the customer account field.
 
-Two mechanisms do different jobs, and the difference is the whole of this page.
+Push the schema to the application branch and apply subject policies through
+[supported connection setup](./data-sources.md). Updating TypeScript alone does
+not update the server schema, existing rows or database policies. For an existing
+projection, migrate its writer and backfill as well as its model declaration.
 
-**Your account is the tenant boundary.** Every row Ablo stores carries your
-organization, project, and branch, and all three are compared on every read and
-every write, from the credential rather than the request. A client cannot reach
-past them by asking. This is the boundary that holds unconditionally.
+## Mint after verifying membership
 
-**Without a subject rule, sync groups are a routing cut inside your account.** They decide which changes are delivered and which rows a
-log-served read returns. That is routing. It is not a universal authorization
-boundary, and the gaps are specific:
-
-| Path | Group cut applied |
-|---|---|
-| Live delivery and fan-out | Yes |
-| HTTP read on a log-served plane (a connected database) | Yes |
-| HTTP read on a hosted or direct-query plane | **No.** Scoped by organization |
-| Writes | **No.** The groups are recorded on the change, never checked against the row |
-| Claim listings and presence | Yes |
-
-So a session cut to one customer, on a hosted plane, can read another
-customer's rows over HTTP; and on any plane it can write to them. What stops it
-today is the organization, which both customers share under this shape.
-
-If isolating your customers is a security requirement, give each one its own
-Ablo organization. The stronger row-and-subject authorization that would make
-this shape safe on every path is not in the engine yet.
-
-## Naming a group
-
-Build a group with the `syncGroup(kind, id)` helper rather than a string. The
-kind is the one you declared in `groups.root`, and the id is your own
-identifier for the customer.
+Your backend authenticates the person and verifies membership in the requested
+account on every mint. Use the verified account ID, never an unchecked request
+parameter:
 
 ```ts
-groups: [syncGroup('customer', member.customerId)]
+import Sessions from '@abloatai/ablo/sessions';
+import { syncGroup } from '@abloatai/ablo/schema';
+import { schema } from './schema';
+
+const sessions = Sessions({ schema, apiKey: process.env.ABLO_API_KEY! });
+const session = await sessions.create({
+  user: { id: verifiedMember.userId },
+  groups: [syncGroup('account', verifiedMember.accountId)],
+  can: { conversationSummaries: ['read'] },
+  ttlSeconds: 300,
+});
 ```
 
-Resolve `member.customerId` from the membership you just authenticated on the
-server. A signed-in person can put any value in a request body, and the session
-you mint is what decides what they can read.
+This session inherits the issuer's organization, project and branch. No
+`organizationId` override or `organization:act-as` grant is needed. The model's
+subject rule authorizes rows; `can` authorizes operations. A list filter merely
+selects a view.
 
-## When a customer should be its own organization
+The [account multiplayer walkthrough](./examples/account-multiplayer.md) contains
+the complete server membership handler, browser lifecycle and scoped server
+writes. A secret-key singleton must not substitute for a subject-scoped session
+when performing customer operations.
 
-Whenever their isolation has to hold. Give each customer its own Ablo
-organization when one of them reading or writing another's rows would be an
-incident rather than a bug, when you cannot audit group coverage across every
-model, or when a customer is a separate paying business that signs in to Ablo
-itself and invites its own developers.
+## Share one database connection
 
-Your backend then names the customer's organization on the mint, which takes a
-secret key carrying `organization:act-as`. The customer never sees Ablo; the
-scope exists because the session leaves the organization the key belongs to.
+Customers with subject-protected rows in the same application branch use that
+branch's connected database and schema. There is no per-customer connection
+registration. Ablo serves connected-plane reads from its retained log, populated
+from the database; readiness and snapshot coverage still need verification.
 
-## Onboarding a customer
+A Data Source is selected by organization, project and branch. Neither a subject
+ID nor a routing group selects a different connection.
 
-Insert the row. There is nothing to register with Ablo, because the group is
-derived from the row's id, and the first session minted against it is delivered
-its data.
+## Where isolation is enforced
 
-Add a project only when you add an application. `npx ablo projects create` takes
-a management credential from `ablo login`, and one project holds one schema.
+For models with subject rules, the server checks subject membership beneath the
+UI across bootstrap, known-ID and list HTTP reads, live delivery and catch-up.
+Write authorization checks the row's subject too. Routing membership in another
+group does not bypass the subject rule. Models without subject rules do not gain
+customer isolation merely because a session names an account group.
 
-## Troubleshooting
+Before enabling browser reads, test two real accounts against the deployed SDK,
+server and connection configuration:
 
-### A session reads nothing
+- Bootstrap exposes only the authorized account's rows.
+- Reading another account's known row ID over HTTP is denied.
+- Live updates and reconnect catch-up do not expose foreign rows.
+- Switching accounts disposes the previous client and does not display its
+  IndexedDB data in the newly authorized account.
 
-Check the groups the session was minted with against the kind in `groups.root`.
-A group whose kind is not declared matches nothing, which reads as an empty
-database rather than an error.
+The maintained example and authorization journeys provide runnable checks;
+local tests are not evidence that a deployed fleet has the same behavior.
+[Groups and shared context](./groups.md) describes cache clearing and membership
+changes. An external membership change does not automatically revoke every
+already-issued session, and offline cached copies cannot be remotely retracted.
 
-### A session reads another customer's rows
+## When to use separate Ablo organizations
 
-Check that the model declares a `parent` edge up to the scope root. A model with
-no group of its own and no parent belongs to no group, so a group cut does not
-narrow it.
+Choose separate organizations when customers own separate Ablo accounts or need
+separate outer data planes. The engine can use an unregistered organization
+scope ID; this does not register an Ablo billing account or connect a database.
 
-### The mint is refused
+Cross-organization minting requires a secret key explicitly granted
+`organization:act-as`. That authority can target any organization; there is no
+application-customer allowlist on the grant. Normal dashboard key creation does
+not grant it. It is operator-provisioned platform authority, not a prerequisite
+for serving customers through the shared-application pattern above.
 
-Naming `organizationId` reaches into a different account and takes
-`organization:act-as`. A platform serving its own customers names groups
-instead, and its key needs no scope at all.
+A cross-organization session uses the target organization's default project and
+root branch. It does **not** inherit the issuer's staging branch. Its schema may
+come from the issuer's project, but its data connection does not: every target
+plane needs its own supported data-source setup. Sharing a schema artifact alone
+does not establish shared Aurora reads.
 
-## See it yourself
+See [Sessions](./sessions.md) for schema binding and [API keys](./api-keys.md) for
+the authority and lifecycle of a platform mint key.
 
-```
-npx ablo whoami --json
-```
+## Troubleshooting
 
-The `syncGroups` it reports are the cut the engine will apply. If a customer's
-group is missing there, no read will show its rows.
+**The mint is refused.** For customers inside one application, omit
+`organizationId`, declare subject rules and grant verified account groups. Do
+not remove the override without migrating a model that currently uses the
+customer ID as its outer tenancy column.
 
-## Related guides
+**A session reads nothing.** Check the branch, pushed subject rule, stored account
+field, granted groups and connection readiness. A schema shared across
+organizations does not share the source connection.
 
-- [Identity & Sync Groups](/identity) — how groups are declared and resolved.
-- [Sessions](/sessions) — session lifetime, refresh, and revocation.
-- [API Keys](/api-keys) — credential classes and scopes.
-- [Projects](/projects) — one project per application.
+**A session reads another customer's row.** Check the actual pushed model's
+subject declaration and the session's verified groups. A parent edge, routing
+group or client filter alone is not an authorization rule.

package/docs/examples/account-multiplayer.md

@@ -50,7 +50,8 @@ Your application authenticates the person and verifies membership on every
 mint. The subject rule authorizes rows; `groups` proves membership; `can`
 authorizes operations. Synchronization delivers the authorized data. A list
 filter helps select a view but does not establish any of these permissions.
-The provider's `userId` prop is informational, not an authentication mechanism.
+React reads application identity from your auth context; the provider accepts
+no `userId` prop.
 
 ## Browser reads and server writes share the scope
 

package/docs/react.md

@@ -181,6 +181,12 @@ for the requested account on every mint; the URL itself grants no access.
 See the [account multiplayer walkthrough](./examples/account-multiplayer.md)
 for the complete ownership boundary and runnable component.
 
+Use `onError` to show a startup failure outside the bootstrap gate. After a
+transient failure, remount the provider with the same client to retry readiness;
+failed `ready()` attempts are retryable. After logout or an account change,
+create a fresh client instead. Strict Mode may create two client instances in
+development; each instance owns its own credential lifecycle.
+
 ## Render immediately with connection status
 
 `useAblo(ablo => ablo.status)` works during provider startup, in passthrough children and in

package/docs/sessions.md

@@ -182,7 +182,7 @@ for the actor.
 |---|---|---|
 | `user` / `agent` | both | The actor. `id` becomes the token's `participantId`. Pass exactly one. |
 | `can` | both | Required non-empty per-model operation allowlist, typed off the schema. |
-| `organizationId` | user | Mint into a customer organization instead of the key's own. Requires `organization:act-as`. |
+| `organizationId` | user | Select another Ablo organization, not an application account. Requires `organization:act-as`; uses the target root branch. |
 | `schemaProject` | user | Override the schema project for a cross-org mint. Usually omitted because the owning key's project is the default. |
 | `groups` | both | Narrow the session below its default scope. Omit to inherit. |
 | `ttlSeconds` | both | Lifetime in seconds. Defaults to `900` (15m). |
@@ -273,34 +273,24 @@ Some apps need each customer to be its **own** tenant — a hard data boundary
 scoping. The law-firm shape (Legora): every firm is its own org, many users
 inside it.
 
-Choose the boundary before minting sessions:
+For customers sharing one application connection, declare a model `subject`
+rule and mint verified account `groups` with the ordinary application key. Keep
+its organization, project and branch. The [customer guide](./customer-organizations.md)
+owns the complete tenancy model, migration requirements and isolation checks.
 
-| Customer model | Isolation guarantee | Use when |
-|---|---|---|
-| One Ablo organization, customer scope roots | Every model's declared `policy` | Cross-customer access is intentional or every model explicitly partitions by the customer root |
-| One Ablo organization per customer | Structural organization filtering and RLS on every row | Customers must be isolated even when a model has no customer policy |
-
-Sync-group routing controls which changes are delivered; it does not grant or
-deny reads. Do not use scope roots as a tenant security boundary unless every
-model declares the matching policy. If that invariant is difficult to audit,
-use one organization per customer.
-
-For the complete key, backend-route, browser, lifecycle, and troubleshooting
-flow, see [Customer Organizations](./customer-organizations.md).
-
-The problem that creates: if each customer is a separate org, a naïve setup would
-make you re-push your schema into every new customer's org. You don't have to.
-Keep **one** project as the home of your schema. When its key mints into another
-organization, Ablo automatically resolves the session's *schema* from that key's
-project while its *data* stays in the customer's own org:
+Separate Ablo organizations are separate data planes. A cross-organization user
+session can reuse the issuer's schema artifact, but it uses the target
+organization's default project and root branch. It does not inherit the issuer's
+staging branch or database connection. Each target plane needs its own supported
+data-source setup.
 
 ```ts
-const ablo = Ablo({ schema, apiKey: process.env.ABLO_PLATFORM_KEY });
-const { token } = await sessions.create({
+const sessions = Sessions({ schema, apiKey: process.env.ABLO_PLATFORM_KEY! });
+const session = await sessions.create({
   user: { id: userId },
-  organizationId, // DATA → this customer's isolated org
+  organizationId, // A separate Ablo organization and data plane.
   can: { records: ['read', 'update'] },
-  ttlSeconds: 3600,
+  ttlSeconds: 300,
 });
 ```
 
@@ -322,10 +312,10 @@ your users in the key's own organization.
 
 ## Security
 
-The whole safety argument is the short TTL: a session token leaked from a
-browser (XSS) is valid for minutes, scoped to one actor's data, and can't mint
-anything or touch the control plane. Contrast `sk_`, which would be a full org
-compromise — which is exactly why it never leaves your server.
+Session authority combines the organization/project/branch boundary, model
+subject rules, verified groups, the `can` allowlist and expiry. A short TTL limits
+exposure; it does not create row isolation. Keep issuer secret keys on the
+server and verify membership whenever issuing or renewing customer sessions.
 
 ## User vs. agent sessions
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@abloatai/ablo",
-  "version": "0.64.2",
+  "version": "0.64.3",
   "description": "The public Ablo SDK for coordinated reads, commits, claims, observation, and reactive applications.",
   "license": "Apache-2.0",
   "type": "module",
@@ -120,6 +120,7 @@
     "verify:context-package": "node scripts/verify-context-package.mjs",
     "typecheck": "tsc --noEmit && tsc -p typetests/tsconfig.json && tsc -p examples/tsconfig.json",
     "test": "vitest run",
+    "test:browser-bundle": "node scripts/check-browser-bundle.mjs",
     "generate:errors": "tsx --conditions=@ablo/source scripts/generate-error-docs.mts",
     "lint:errors": "tsx --conditions=@ablo/source scripts/check-error-docs.mts",
     "generate:pricing": "tsx scripts/generate-pricing-docs.mts",
@@ -146,8 +147,8 @@
     "directory": "packages/ablo"
   },
   "dependencies": {
-    "@abloatai/humans": "0.64.2",
-    "@abloatai/transaction": "0.64.2",
+    "@abloatai/humans": "0.64.3",
+    "@abloatai/transaction": "0.64.3",
     "zod": "^4.4.3"
   },
   "peerDependencies": {