@tanagram/lore 0.1.106 → 0.1.107

package/README.md

@@ -240,15 +240,19 @@ dirs so they don't stomp each other:
 | prod | `~/.lore/`      | `~/.lore/log.txt`     |
 | dev  | `~/.lore-dev/`  | `~/.lore-dev/log.txt` |
 
-`lore login` asks the Lore API for public WorkOS CLI Auth configuration, starts
-WorkOS's device-code flow, prints the verification URL and user code, and polls
-WorkOS until it receives JWT access and refresh tokens. It stores those tokens
-in the active state dir as `token` and `refresh_token` (for example,
-`~/.lore-dev/token` and `~/.lore-dev/refresh_token` in local dev). When the
-access token is expired or will expire within 10 seconds, authenticated
-commands use the refresh token to rotate a new access token automatically. The
-CLI does not read token environment variables; use `lore logout` to remove the
-stored tokens.
+`lore login` discovers WorkOS AuthKit from the Lore MCP resource metadata,
+starts WorkOS's device-code flow, prints the verification URL and user code, and
+polls WorkOS until it receives JWT access and refresh tokens. Token persistence,
+legacy migration, OAuth discovery caching, and refresh-token rotation live in
+`@lore/identity-store`, shared with the Lore plugin. The CLI stores the
+canonical token record as `tokens.json` in the active state dir (for example,
+`~/.lore-dev/tokens.json` in local dev) and caches OAuth discovery beside it as
+`discovery-cache.json`. When the access token is expired or will expire within
+10 seconds, authenticated commands use the refresh token to rotate a new access
+token automatically. Transient refresh failures preserve the refresh token for a
+later retry; only an AuthKit `invalid_grant` response clears local tokens and
+requires login again. The CLI does not read token environment variables; use
+`lore logout` to remove the stored tokens.
 
 Run `lore logs` to print the active log file path. In dev, log lines also
 tee to stderr so you see them while iterating; in prod the file is the only