Merge pull request #439 from agentrhq/chore/docs-site-v0.7-stale-cleanup

docs: refresh Mintlify site for v0.7 and remove stale references

Author: manojbajaj95

docs/site/changelog.mdx

@@ -8,56 +8,66 @@ keywords: ["authsome changelog", "authsome release notes", "authsome version his
 
 A curated summary of authsome releases. For the full per-commit log, see [CHANGELOG.md](https://github.com/agentrhq/authsome/blob/main/CHANGELOG.md) in the repository.
 
-<Update label="0.2.4" description="2026-05-08">
-  **Admin audit dashboard.** The local daemon serves an interactive audit dashboard.
+<Update label="0.7" description="2026-06-16">
+  **Documentation refresh.** Public Mintlify docs updated for the Principal / Vault / Identity model. Retired profile-based terminology, removed references to the old in-process `AuthService` library API, and aligned installation, doctor, and daemon API pages with the current storage layout.
 
-  **Browser SSO.** Support for browser SSO via Chrome cookie reading.
-
-  **Customizable home directory.** `AUTHSOME_HOME` overrides the default `~/.authsome/` location. Useful for per-project credential isolation and CI.
+  **Current integration surface.** CLI commands, `authsome run` proxy injection, `authsome export`, and the daemon HTTP API (with PoP JWT auth) are the supported paths for agents and tooling.
+</Update>
 
-  **Notion DCR provider.** Added `notion_dcr` (Dynamic Client Registration) variant for the MCP endpoint at `mcp.notion.com`.
+<Update label="0.6.x" description="2026-06-06 to 2026-06-09">
+  **Next.js dashboard.** Static dashboard served from the daemon root with provider and connection management UI.
 
-  **Improved error handling.** Custom error propagation between the daemon server and CLI client.
+  **Self-hosting.** Docker Compose setup and self-hosting guide for running the daemon outside a laptop.
 
-  **Non-interactive register.** New `--yes` flag on `authsome register` skips the confirmation prompt in scripts.
+  **Provider expansion.** Bundled providers for Google Workspace services, Jira, Confluence, YouTube, Vertex AI, Todoist, Cloudflare, Outlook, Word, Calendar, Zoom, Reddit, and more.
 
-  **Distinct exit code for cancelled credential entry** (exit code 8) so scripts can distinguish user cancellation from authentication failure.
+  **Architecture cleanup.** Multi-server-compatible identities, cleaner UI auth flows, and client/server home directory split (`~/.authsome/client/` vs `~/.authsome/server/`).
 </Update>
 
-<Update label="0.2.3" description="2026-05-01">
-  Documentation pass. Added demo video to README.
-</Update>
+<Update label="0.5.0" description="2026-05-29">
+  ⚠ **Breaking:** Principal claim flow required for vault access. Existing local installs must register a Principal and accept the identity claim.
 
-<Update label="0.2.2" description="2026-04-29">
-  **Audit logging.** Structured JSON event log written to `~/.authsome/audit.log` for every significant action (login, logout, revoke, export, register). See [Audit log format](/reference/audit-log).
+  ⚠ **Breaking:** Vault encryption moved to Argon2id KEK/DEK model. Fernet-encrypted vaults cannot be read back; re-login required.
 
-  **List output rendered as a table.** `authsome list` shows providers, source (bundled / custom), auth type, default connection, and status in a single tabular view.
+  **Audit events and principal roles.** Structured audit logging with admin/user roles. Admin audit dashboard.
 
-  **Expanded `whoami` context.** Reports the home directory, encryption mode, registered identity handle, and DID.
+  **Browser SSO.** Chrome cookie reading for providers that support it.
 
-  **Regex proxy host URLs.** Provider definitions can declare `api_url: "regex:..."` to match multiple hosts behind a single provider (used by Google and Linear).
+  **Anthropic and Gemini** bundled providers added.
 </Update>
 
-<Update label="0.2.1" description="2026-04-28">
-  Fix: set connection `api_url` directly from the resolved provider definition.
+<Update label="0.4.0" description="2026-05-25">
+  ⚠ **Breaking:** Principal, Vault, and Identity replace the old profile model. Credentials are namespaced under `vault:<vault_id>:...`. See [Principal, Vault, and Identity](/concepts/principal-vault-identity).
+
+  **Claim flow.** Identities must claim a Principal before accessing credentials.
+
+  **Master key rotation.** `rekey` command and API endpoint.
+
+  **CLI restructure.** Provider and admin command namespaces.
 </Update>
 
-<Update label="0.2.0" description="2026-04-28">
-  **Architectural restructure.** Vault and AuthLayer split into separate layers with a documented protocol boundary. Public Python API consolidated around `AuthService` and `AuthLayer` (re-exported from the top-level `authsome` package). CLI commands and flags are unchanged. See [Architecture](/concepts/architecture).
+<Update label="0.3.x" description="2026-05-20">
+  **Configurable proxy scope.** `connected_allow` and related proxy modes in client config.
+
+  **Health checks.** Readiness validates connections for the active identity.
+
+  **Telemetry.** Opt-out PostHog analytics via environment variables.
+</Update>
 
-  **Browser bridge for sensitive input.** OAuth `client_secret` and API keys are now collected through a local browser form (or `getpass` fallback). Sensitive values are no longer accepted as command-line arguments.
+<Update label="0.2.x" description="2026-04-28 to 2026-05-08">
+  **Browser bridge for sensitive input.** OAuth `client_secret` and API keys collected through a local browser form.
 
-  **`{base_url}` templating.** Multi-tenant providers (GitHub Enterprise, Okta, GitLab self-managed) declare a default `base_url` and `--base-url` overrides it at login time. See [Custom providers](/guides/custom-providers#multi-tenant-providers).
+  **`{base_url}` templating.** Multi-tenant providers (GitHub Enterprise, Okta, GitLab self-managed).
 
-  **`--verbose` and `--log-file` flags.** loguru-backed file logging with `--verbose` for DEBUG to stderr.
+  **Audit logging.** Structured JSON event log for login, logout, revoke, and export.
 
-  **mitmproxy CA injection.** Subprocesses started by `authsome run` get a combined system + mitmproxy CA bundle so SDKs trust the proxy by default.
+  **Admin audit dashboard** and **Notion DCR** provider.
 
-  ⚠ **Breaking:** the older `AuthClient` entry point is gone. Library users should switch to `from authsome.server.dependencies import create_auth_service`. See [Python library](/reference/python-library).
+  **`AUTHSOME_HOME`** for per-project credential isolation.
 </Update>
 
 <Update label="0.1.x" description="up to 2026-04-24">
-  Initial public series. Established the CLI surface (`login`, `logout`, `revoke`, `remove`, `list`, `inspect`, `get`, `export`, `run`, `register`, `doctor`, `whoami`), the four flow types (PKCE, device code, DCR + PKCE, API key), and the bundled provider set. Major additions in this series include the proxy runner, RC publishing, OAuth scope support, the `--force` flag, and several bundled-provider additions (Ashby, Klaviyo, and others).
+  Initial public series. Established the CLI surface, four flow types (PKCE, device code, DCR + PKCE, API key), bundled providers, and the proxy runner.
 </Update>
 
 ## Versioning
@@ -79,7 +89,7 @@ pip install --upgrade authsome
 uvx authsome@latest --version
 ```
 
-Stored credentials, providers, and `config.json` persist across upgrades. The `schema_version` field in `~/.authsome/config.json` and on every `ConnectionRecord` is reserved for forward-compatibility migrations.
+Stored credentials, providers, and client config persist across upgrades. Connection records carry a `schema_version` field reserved for forward-compatibility migrations.
 
 ## What's next
 

docs/site/concepts/provider-registry.mdx

@@ -46,7 +46,7 @@ For full templates and the field-by-field schema. For a worked OAuth example usi
 
 ## Bundled providers do not imply bundled credentials
 
-A bundled provider definition only describes how to talk to a service. It does not include OAuth client credentials. The first time you log in to an OAuth2 provider, authsome collects your `client_id` and `client_secret` through a secure browser bridge and stores them encrypted in your profile.
+A bundled provider definition only describes how to talk to a service. It does not include OAuth client credentials. The first time you log in to an OAuth2 provider, authsome collects your `client_id` and `client_secret` through a secure browser bridge and stores them encrypted in your vault.
 
 For services that support Dynamic Client Registration (DCR), the `dcr_pkce` flow registers a fresh OAuth client automatically, no `client_id` collection needed.
 
@@ -64,7 +64,7 @@ For services where the base URL varies per deployment (GitHub Enterprise, Okta,
 }
 ```
 
-During `authsome login`, the user is prompted for the base URL with the JSON value as the default. A custom base URL is saved to the profile and used for all future token refreshes on that connection.
+During `authsome login`, the user is prompted for the base URL with the JSON value as the default. A custom base URL is saved to the vault and used for all future token refreshes on that connection.
 
 ## Adding your own providers
 

docs/site/concepts/proxy-injection.mdx

@@ -20,7 +20,7 @@ The child process never sees the raw secret.
     When the child makes an HTTP(S) call, mitmproxy decrypts and inspects the request. It looks at the destination host.
   </Step>
   <Step title="The proxy matches by api_url">
-    Authsome iterates the registered providers and matches the request host against each provider's `api_url` field. On a match, it asks the AuthLayer for fresh credentials (refreshing if necessary) and injects the right `Authorization` header.
+    Authsome iterates the registered providers and matches the request host against each provider's `api_url` field. On a match, it asks the daemon for fresh credentials (refreshing if necessary) and injects the right `Authorization` header.
   </Step>
   <Step title="The request is forwarded">
     The authenticated request goes to the external API. The response streams back through the proxy unchanged.

docs/site/concepts/the-daemon.mdx

@@ -16,7 +16,7 @@ Authentication flows hold state. They involve asynchronous steps like browser re
 - **Session state:** Multi-step operations and token refresh logic need a place to live.
 - **Secure injection:** The proxy needs an isolated component to fetch fresh tokens without exposing the Vault decryption keys to the proxy process itself.
 
-The daemon solves this. It runs a persistent, in-memory coordinator that manages browser bridges, handles OAuth callbacks, serves the dashboard, and orchestrates the Vault and Auth layers. 
+The daemon solves this. It runs a persistent coordinator that manages browser bridges, handles OAuth callbacks, serves the dashboard, and orchestrates vault access and credential lifecycle. 
 
 ## Trust boundary and authorization
 

docs/site/guides/custom-providers.mdx

@@ -169,7 +169,7 @@ authsome login acmecrm
 authsome get acmecrm --field status   # → connected
 ```
 
-For OAuth2 providers without DCR, authsome opens a local browser form on first login to collect `client_id` and `client_secret`. They are stored encrypted under the active profile and reused on every subsequent login. They are never accepted as command-line arguments.
+For OAuth2 providers without DCR, authsome opens a local browser form on first login to collect `client_id` and `client_secret`. They are stored encrypted in the active vault and reused on every subsequent login. They are never accepted as command-line arguments.
 
 ## Multi-tenant providers
 

docs/site/guides/headless-device-code.mdx

@@ -68,7 +68,7 @@ In CI, you can capture the authorization URL and code from the command output an
 authsome login github --flow device_code 2>&1 | tee login.log
 ```
 
-The login command waits until the device flow either completes, expires, or is cancelled. For unattended CI you typically log in once on a developer machine and then commit the encrypted profile (or, more often, run the agent only on machines that already have an authenticated profile).
+The login command waits until the device flow either completes, expires, or is cancelled. For unattended CI you typically log in once on a developer machine and then copy the encrypted vault data (or, more often, run the agent only on machines that already have an authenticated vault).
 
 ## API key providers
 

docs/site/guides/login-with-oauth.mdx

@@ -52,7 +52,7 @@ This is what happens:
 
 <Steps>
   <Step title="Client credential collection (first time only)">
-    Authsome opens a local form at `http://127.0.0.1:7998`. Paste your `client_id` and `client_secret`. They are encrypted and stored under your profile, then reused on every subsequent login.
+    Authsome opens a local form at `http://127.0.0.1:7998`. Paste your `client_id` and `client_secret`. They are encrypted and stored in your vault, then reused on every subsequent login.
   </Step>
   <Step title="Authorization redirect">
     A second browser window opens to the provider's authorization page. Approve the requested scopes.

docs/site/guides/multiple-connections.mdx

@@ -66,13 +66,10 @@ authsome login github --connection work --force
 authsome run -- python my_agent.py
 ```
 
-Or use the library, which accepts `connection=` directly:
+Or export credentials for a specific connection:
 
-```python
-from authsome.server.dependencies import create_auth_service
-
-auth = create_auth_service()
-token = auth.get_access_token("github", connection="work")
+```bash
+eval "$(authsome export github --connection work --format env)"
 ```
 
 ## Remove a connection

docs/site/installation.mdx

@@ -49,7 +49,7 @@ Authsome runs on Python 3.13 or newer. It ships as a single PyPI package with no
     Pin a version:
 
     ```bash
-    uvx authsome@0.2.4 --version
+    uvx authsome@0.7 --version
     ```
 
     Use `uvx` when you don't want a persistent install (sandboxed environments, one-off scripts). Every command shown in the rest of the docs as `authsome <subcommand>` works as `uvx authsome@latest <subcommand>` here.
@@ -87,15 +87,16 @@ On `authsome onboard`, authsome initializes its home directory at `~/.authsome/`
 
 ```text
 ~/.authsome/
-  config.json
-  audit.log
-  identities/<generated-handle>.json
-  identities/<generated-handle>.key
+  client/
+    config.json           active identity, proxy mode
+    logs/authsome.log
+    identities/<handle>.json
+    identities/<handle>.key
   server/
     master.key            mode 0600
-    kv_store/
-    identity_registry.json
-    daemon/
+    authsome.db           identity/principal/vault registries
+    kv_store/             encrypted credential blobs
+    logs/authsome.log
 ```
 
 On a fresh `onboard`, authsome resolves the master key source in this order:
@@ -119,7 +120,6 @@ For a remote or self-hosted daemon, pass `--base-url` once; authsome saves it in
 authsome onboard --base-url https://authsome.example.com
 ```
 
-
 ## Choose the encryption backend
 
 By default, authsome uses `encryption.mode = "auto"` and applies the precedence above. To pin the daemon to the local file or OS keychain instead, edit the Authsome config:
@@ -135,7 +135,7 @@ By default, authsome uses `encryption.mode = "auto"` and applies the precedence
 
 Re-run `authsome doctor` to confirm the backend is reachable. The trade-offs are covered in [Encryption at rest](/security/encryption).
 
-Older installs that used the implicit `default` profile must run `authsome onboard` again. This release does not migrate credentials under old `profile:default:*` keys.
+Upgrading from releases before 0.4 (the old profile model) requires a fresh `authsome onboard` and re-login. Credentials under `profile:*` keys are not migrated automatically. See [Changelog](/changelog).
 
 ## Optional: trust the proxy CA
 

docs/site/integrations/agents/anthropic-sdk.mdx

@@ -49,21 +49,20 @@ authsome run -- python my_agent.py
 
 The SDK initializes with `ANTHROPIC_API_KEY=authsome-proxy-managed`. Outbound requests to `api.anthropic.com` are intercepted and authenticated at the proxy layer.
 
-## Alternative: pass the key explicitly
+## Alternative: export into the environment
+
+```bash
+eval "$(authsome export anthropic --format env)"
+python my_agent.py
+```
+
+Or read the key in Python after export:
 
 ```python
-from authsome.server.dependencies import create_auth_service
+import os
 from anthropic import Anthropic
 
-auth = create_auth_service()
-client = Anthropic(api_key=auth.get_access_token("anthropic"))
-
-resp = client.messages.create(
-    model="claude-sonnet-4-5",
-    max_tokens=1024,
-    messages=[{"role": "user", "content": "ping"}],
-)
-print(resp.content[0].text)
+client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
 ```
 
 ## Multi-account workflows
@@ -73,11 +72,8 @@ authsome login anthropic --connection personal
 authsome login anthropic --connection team
 ```
 
-In code:
-
-```python
-key = auth.get_access_token("anthropic", connection="team")
-client = Anthropic(api_key=key)
+```bash
+eval "$(authsome export anthropic --connection team --format env)"
 ```
 
 ## What's next