Migration from local PLUR

The supported model is side-by-side, not cutover: your local PLUR keeps your personal engrams; the Enterprise server holds team-shared scopes. One MCP server routes reads and writes to both, based on scope.

Why side-by-side:

1. Privacy posture. Your ~/.plur/ has years of personal context. Pushing all of it to a shared server is a one-way decision.
2. No correctness benefit. Enterprise speaks the same protocol; the only thing local does better is “stays local” — that’s the feature.
3. Deliberate sharing. Every engram that goes to a shared scope should be a conscious decision.

1. Connect your local PLUR to Enterprise

Get an API key from /me/api-keys on the Enterprise server (a plur_sk_... value, shown once). Then register the server as a remote store — from your AI client, via the MCP tool:

plur_stores_add url="https://plur.your-org.com/sse"
                token="plur_sk_..."
                scope="group:your-org/your-team"

Repeat once per team scope you participate in (the same token can be reused — server permissions limit what each scope can read/write). Or from the CLI:

plur init-remote --url https://plur.your-org.com --token plur_sk_...

Verify with plur_stores_list — you should see your local primary store plus every remote scope.

2. Use it normally

No special addressing needed. plur_learn routes by scope; plur_recall queries every configured store and merges:

plur_learn statement="we use 4-space indent"
           # → no scope = local only

plur_learn statement="team uses TypeScript strict mode"
           scope="group:your-org/your-team"
           # → routed to the Enterprise store (scope matches the remote)

plur_recall query="indent"
           # → local + remote results, merged

Where the engram should live	Scope to use	Store it lands in
Just you (drafts, scratch, personal habits)	omit scope	local
Your team	group:your-org/your-team	Enterprise
Anything matching a registered remote scope	the matching scope	Enterprise

3. Importing existing engrams you think are team-shared

The principle: migrate what generalises, keep what’s personal. Deploy conventions and architecture decisions generalise; editor preferences and personal corrections don’t.

Option A: hand-pick + republish (recommended)

Export candidates locally, eyeball them, then re-learn each one into the team scope:

plur recall --query "your topic" --json > shareable.json
# review, strip anything personal, then per engram:
# plur_learn statement="..." scope="group:your-org/your-team"

Manual and slow, but every engram gets a deliberate share decision.

Option B: scripted import via the REST API

POST /api/v1/engrams writes one engram per request, with the same auth and permission checks as plur_learn. For bulk import, loop over your exported JSON. Option A is still the recommended default.

What you don’t migrate

• Episodes — timeline records, not portable knowledge. They stay local.
• Activation history — re-accumulates from real use on the server.
• Pinning — a server-side flag; Enterprise editors/admins decide what to pin.

Token notes

• API keys (recommended): long-lived, individually revocable from /me/api-keys.
• JWTs: 30-day sessions with no silent refresh — usable but you’ll re-authenticate monthly. Use API keys for anything automated.

When to fully cut over

Don’t. Side-by-side is the long-term shape: local for personal, Enterprise for shared. The split is the value, not a transitional inconvenience.