refactor: move OAuth storage and drop legacy sessions

docs/onboarding.md

@@ -2,12 +2,12 @@
 summary: "Planned first-run onboarding flow for Clawdis (local vs remote, Anthropic OAuth, workspace bootstrap ritual)"
 read_when:
   - Designing the macOS onboarding assistant
-  - Implementing Pi authentication or identity setup
+  - Implementing Anthropic auth or identity setup
 ---
 <!-- {% raw %} -->
 # Onboarding (macOS app)
 
-This doc describes the intended **first-run onboarding** for Clawdis. The goal is a good “day 0” experience: pick where the Gateway runs, bind Claude (Anthropic) auth for Pi, and then let the **agent bootstrap itself** via a first-run ritual in the workspace.
+This doc describes the intended **first-run onboarding** for Clawdis. The goal is a good “day 0” experience: pick where the Gateway runs, bind Claude (Anthropic) auth for the embedded agent runtime, and then let the **agent bootstrap itself** via a first-run ritual in the workspace.
 
 ## Page order (high level)
 
@@ -19,58 +19,42 @@ This doc describes the intended **first-run onboarding** for Clawdis. The goal i
 
 First question: where does the **Gateway** run?
 
-- **Local (this Mac):** onboarding can run the Anthropic OAuth flow and write Pi’s token store locally.
+- **Local (this Mac):** onboarding can run the Anthropic OAuth flow and write the Clawdis token store locally.
 - **Remote (over SSH/tailnet):** onboarding must not run OAuth locally, because credentials must exist on the **gateway host**.
 
 Implementation note (2025-12-19): in local mode, the macOS app bundles the Gateway and enables it via a per-user launchd LaunchAgent (no global npm install/Node requirement for the user).
 
 ## 2) Local-only: Connect Claude (Anthropic OAuth)
 
-This is the “bind Pi to Clawdis” step. It is explicitly the **Anthropic (Claude Pro/Max) OAuth flow**, not a generic “login”.
+This is the “bind Clawdis to Anthropic” step. It is explicitly the **Anthropic (Claude Pro/Max) OAuth flow**, not a generic “login”.
 
 ### Recommended: OAuth
 
 The macOS app should:
 - Start the Anthropic OAuth (PKCE) flow in the user’s browser.
 - Ask the user to paste the `code#state` value.
-- Exchange it for tokens and write Pi-compatible credentials to:
-  - `~/.pi/agent/oauth.json` (file mode `0600`, directory mode `0700`)
+- Exchange it for tokens and write credentials to:
+  - `~/.clawdis/credentials/oauth.json` (file mode `0600`, directory mode `0700`)
 
-Why this location matters: it makes Pi work immediately (Clawdis doesn’t need a terminal and doesn’t need to re-implement Pi’s auth plumbing later).
+Why this location matters: it’s the Clawdis-owned OAuth store.
+On first run, Clawdis can import existing OAuth tokens from legacy p/Claude locations if present.
 
 ### Alternative: API key (instructions only)
 
 Offer an “API key” option, but for now it is **instructions only**:
 - Get an Anthropic API key.
-- Provide it to Pi (or to Clawdis’s Pi invocation) via your preferred mechanism.
+- Provide it to Clawdis via your preferred mechanism (env/config).
 
 Note: environment variables are often confusing when the Gateway is launched by a GUI app (launchd environment != your shell).
 
 ### Provider/model safety rule
 
-Clawdis should **always pass** `--provider` and `--model` when invoking Pi (don’t rely on Pi defaults).
+Clawdis should **always pass** `--provider` and `--model` when invoking the embedded agent (don’t rely on defaults).
 
-Until that is hard-coded, the equivalent configuration is:
+Example (CLI):
 
-```json5
-{
-  inbound: {
-    reply: {
-      mode: "command",
-      command: [
-        "pi",
-        "--mode",
-        "rpc",
-        "--provider",
-        "anthropic",
-        "--model",
-        "claude-opus-4-5",
-        "{{BodyStripped}}"
-      ],
-      agent: { kind: "pi", format: "json" }
-    }
-  }
-}
+```bash
+clawdis agent --mode rpc --provider anthropic --model claude-opus-4-5 "<message>"
 ```
 
 If the user skips auth, onboarding should be clear: the agent likely won’t respond until auth is configured.
@@ -136,10 +120,10 @@ Daily memory lives under `memory/` in the workspace:
 
 ## Remote mode note (why OAuth is hidden)
 
-If the Gateway runs on another machine, the Anthropic OAuth credentials must be created/stored on that host (where Pi runs).
+If the Gateway runs on another machine, the Anthropic OAuth credentials must be created/stored on that host (where the agent runtime runs).
 
 For now, remote onboarding should:
 - explain why OAuth isn’t shown
-- point the user at the credential location (`~/.pi/agent/oauth.json`) and the workspace location on the gateway host
+- point the user at the credential location (`~/.clawdis/credentials/oauth.json`) and the workspace location on the gateway host
 - mention that the **bootstrap ritual happens on the gateway host** (same BOOTSTRAP/IDENTITY/USER files)
 <!-- {% endraw %} -->