@abloatai/ablo 0.40.0 → 0.42.0

package/CHANGELOG.md

@@ -1,5 +1,62 @@
 # Changelog
 
+## 0.42.0
+
+### `ablo whoami`: what does this key act on?
+
+`whoami` returns the server-confirmed organization, project, and branch a key
+acts on, or fails. Where `status` is the broad health report and deliberately
+degrades when an older or unreachable server cannot confirm identity, `whoami`
+is the strict form of the question, which makes it safe to run before a
+`connect` or `deregister` instead of inferring a key's scope from a failed
+mutation.
+
+### Bound sessions resolve their schema again
+
+Every read seam that honored a first-party schema binding substituted the
+owner's organization but kept the caller's own branch, a location where the
+owner's schema never lives. Bound sessions therefore resolved an empty schema:
+bootstraps returned no models and every query answered `unknown_model`. Reads
+and commits now resolve the model map on the owner's branch axis, and an
+absent branch resolves to the owner's root.
+
+### Re-pushing an unchanged schema no longer fails
+
+The unchanged-schema fast path skipped the provisioning deferral the real
+migration path has, so an identical `ablo push` was refused on any plane that
+had no DDL to run. The fast path now defers exactly like the real path, and a
+second push of the same schema succeeds with nothing left undone.
+
+## 0.41.0
+
+### Log in before you have a schema
+
+`mintUserSessionKey` accepts `controlPlaneOnly` as a third grant form, for
+sessions that exist to prove identity to the dashboard and control surfaces
+rather than to read or write data. An organization that has pushed no schema
+can now complete `ablo login`, which is the very credential pushing requires;
+the old circle (push needs keys, keys need login, login needed a schema) is
+gone. Data sessions are unchanged, and a control-plane session holds no model
+authority.
+
+### `connect apply` asks before it touches your database
+
+The locate preflight runs before provisioning. When another plane of your
+organization already holds the source, `connect apply` refuses with exit 1,
+names `ablo connect deregister` as the way out, and leaves your database
+exactly as it found it; the same conflict used to be discovered only after a
+run had created roles and a publication. A connection string without a
+password is refused at registration with the field named, instead of failing
+later as a masked server error.
+
+### A CLI that says when a command does not exist
+
+Typing a command the CLI does not recognize used to print the full help and
+exit zero. It now fails with the name it did not recognize and, when a
+plausible target exists, the command to use: a typo lands on the intended
+command, and a wrong-but-reasonable name like `disconnect` points at
+`ablo connect deregister`.
+
 ## 0.40.0
 
 ### The price is a contract, and the pricing page derives from it

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@abloatai/ablo",
-  "version": "0.40.0",
+  "version": "0.42.0",
   "description": "The public Ablo SDK for coordinated reads, commits, claims, observation, and reactive applications.",
   "license": "Apache-2.0",
   "type": "module",
@@ -124,8 +124,8 @@
     "directory": "packages/ablo"
   },
   "dependencies": {
-    "@abloatai/humans": "^0.40.0",
-    "@abloatai/transaction": "^0.40.0"
+    "@abloatai/humans": "^0.42.0",
+    "@abloatai/transaction": "^0.42.0"
   },
   "peerDependencies": {
     "ai": "^6.0.0 || ^7.0.0",