@lessly/sdk-app 63.2.1 → 63.2.2

package/docs/recipes/access.md

@@ -42,6 +42,25 @@ out at all.
 the problem*, though — a failed `/me` is not a denial. See the state table in
 §2 for what each `state` means for a control.
 
+The snapshot lives **in the client instance** until `invalidate()` or until the
+client itself is recreated. There is no TTL and no background refresh: a client
+made once holds the role it loaded once, for as long as it lives.
+
+That matters because a module-level singleton `createLesslyApp` client survives
+SPA navigation and bfcache back/forward. A "reload" that does not remount the
+remote — a router push, a browser Back into a restored page — keeps the old
+snapshot, and the UI can lag the real role by minutes while `GET
+products/:id/me` would answer correctly if anyone asked it. After a role change,
+call `app.access.invalidate()` and then `load()` again (or do a full page
+reload); do not wait for the snapshot to expire, because it never does.
+
+Before you measure staleness, compare the role the App's own `/me` request
+returned — read it in the Network tab — with what the API says now. Never assume
+the role from memory: the two disagree exactly in the case you are debugging.
+And it is never the HTTP cache alone: the server sends no `Cache-Control` for
+`/me` today, so the browser only revalidates via `ETag`. Staleness you see is
+the in-memory snapshot.
+
 You can pass either a tool id or a generated method, which carries its own
 identity:
 

package/docs/rules.md

@@ -506,4 +506,17 @@ through `isAccessDenied()` for the *words*, and MUST NOT reimplement the confirm
 flow to win the colour — it would forfeit the focus trap, busy state, confirm
 phrase and step-up. Tracked as platform #2915.
 
+The snapshot has no TTL, so staleness is the App's to invalidate:
+
+- The access snapshot lives in the client instance until `invalidate()` or until
+  the client is recreated — there is no expiry and no background refresh.
+- A module-level singleton client survives SPA navigation and bfcache
+  back/forward, so a "reload" that does not remount the remote keeps the old
+  role. After a role change an App MUST call `app.access.invalidate()` and then
+  `load()` (or do a full page reload).
+- Before measuring staleness, compare the role the App's own `/me` request
+  returned (Network tab) with what the API answers now — never assume it from
+  memory. The server sends no `Cache-Control` for `/me` today and the browser
+  only revalidates via `ETag`, so the HTTP cache alone is never the explanation.
+
 See `recipes/access.md` for the load-once pattern and the empty-state shape.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lessly/sdk-app",
-  "version": "63.2.1",
+  "version": "63.2.2",
   "type": "module",
   "sideEffects": false,
   "engines": {