@happyvertical/smrt-profiles 0.39.17 → 0.40.1

package/AGENTS.md

@@ -112,7 +112,11 @@ import { smrtProfilesGenerateBioPrompt } from '@happyvertical/smrt-profiles';
   existing email match through this helper; User/session provisioning still
   rejects unsafe linked Profiles before creating authentication state. Use
   `UserCollection.getOrCreateFromOidc()` for owner-aware verified-email reuse and
-  its supported transaction-bound resolver hook.
+  its supported transaction-bound hooks. A pre-provisioned owned Person remains
+  fail-closed unless the application explicitly uses `authorizeProfileOwner`
+  to select both the canonical Profile and its existing approved sole owner;
+  the users package revalidates those IDs, emails, and identity authority in
+  the provisioning transaction.
 - **Email storage and identity matching differ**: `Profile.email` has an
   exact-value DB constraint. Identity boundaries query readonly indexed
   `Profile.emailKey`, derived by the shared TypeScript

package/README.md

@@ -175,7 +175,12 @@ errors, and permitted row creation; the Profiles and Users suites execute its
 applicable rows directly. In particular, Profile-only exact reuse preserves an
 established legacy link because it creates no User/session authentication state,
 while `UserCollection.getOrCreateFromOidc()` remains owner-aware and fail-closed.
-Use the Users API for verified-email reuse and application reconciliation.
+Use the Users API for verified-email reuse and application reconciliation. Its
+`authorizeProfileOwner` option is the only supported exception for a new
+issuer/subject targeting a pre-provisioned owned Person: the users package
+atomically verifies the canonical Profile, sole approved owner, matching User
+email, and non-rebindable identity. Without that explicit application
+authorization, the owned Profile still returns `profile_owned`.
 
 `Profile` and `ProfileCollection` both expose `getAssets()`, `addAsset()`, and
 `removeAsset()` helpers backed by `profile_assets`. Typical relationships are