feat(auth): add shared resource controls

docs/dashboard-auth-cli.md

@@ -26,6 +26,7 @@ Dashboard auth and account context metadata are separate:
 
 - `dashboard_auth`: protects dashboard access with username/password
 - `accounts.<name>.context_mode/context_group`: controls isolated vs shared account context
+- `accounts.<name>.shared_resource_mode`: controls plugins/commands/skills/agents/settings.json sharing
 
 Account context is isolation-first. The recommended two-account route is:
 
@@ -48,15 +49,22 @@ Shared continuity depth:
 - `standard` (default): shares project workspace context only
 - `deeper` (advanced opt-in): also syncs `session-env`, `file-history`, `shell-snapshots`, `todos`
 
-`ccs auth show <profile>` reports credential isolation, settings sync state, history lane, and whether plain `ccs` currently uses the same resume lane.
+`ccs auth show <profile>` reports credential isolation, shared resource mode, settings sync state, history lane, and whether plain `ccs` currently uses the same resume lane.
 
-Non-bare account profiles share the basic Claude `settings.json` with native Claude:
+Non-bare account profiles share Claude-local resources with native Claude:
 
 ```text
 ~/.ccs/instances/<profile>/settings.json -> ~/.ccs/shared/settings.json -> ~/.claude/settings.json
 ```
 
-This keeps ordinary Claude settings in sync without copying account tokens. Local history is separate: if users want future plain `ccs` and `ccs ck` sessions to resume from the same account lane, run `ccs auth default ck` after backing up the current native lane with `ccs auth backup default`.
+This keeps ordinary Claude settings, plugins, commands, skills, and agents in sync without copying account tokens. Existing accounts can opt out or back in:
+
+```bash
+ccs auth resources work --mode profile-local
+ccs auth resources work --mode shared
+```
+
+Local history is separate: if users want future plain `ccs` and `ccs ck` sessions to resume from the same account lane, run `ccs auth default ck` after backing up the current native lane with `ccs auth backup default`.
 
 `context_group` normalization and validation:
 
@@ -83,6 +91,13 @@ Dashboard accounts context editing:
 - rejects CLIProxy OAuth account keys for this route
 - applies normalization/validation rules above
 
+Shared resource editing:
+
+- `PUT /api/accounts/:name/shared-resources` updates `shared_resource_mode` for existing auth accounts
+- accepts only `shared` or `profile-local`
+- rejects CLIProxy OAuth account keys for this route
+- reconciles the account instance after metadata is updated
+
 ## Commands
 
 ### `ccs config auth setup`

docs/session-sharing-technical-analysis.md

@@ -26,7 +26,7 @@ ccs personal
 
 This keeps usage and credentials isolated. Each account owns its own Claude config directory, login state, and `.anthropic` credentials.
 
-Basic Claude settings are shared for non-bare account profiles:
+Shared Resources are separate from History Sync. By default, non-bare account profiles inherit Claude-local resources from native Claude:
 
 ```text
 ~/.ccs/instances/<account>/settings.json
@@ -34,7 +34,17 @@ Basic Claude settings are shared for non-bare account profiles:
   -> ~/.claude/settings.json
 ```
 
-This is for ordinary Claude Code settings, hooks, commands, skills, agents, and plugins. It is not token sharing. `ccs auth show <account>` reports the current `Settings`, `History`, and `Plain ccs` lanes so users can see whether settings and resume history are aligned.
+This covers ordinary Claude Code `settings.json`, commands, skills, agents, and plugins. It is not token sharing. `ccs auth show <account>` reports `Resources`, `Settings`, `History`, and `Plain ccs` lanes so users can see whether shared resources and resume history are aligned.
+
+For existing accounts, change Shared Resources from the CLI:
+
+```bash
+ccs auth resources work --mode profile-local
+ccs auth resources work --mode shared
+```
+
+- `shared`: link plugins, commands, skills, agents, and `settings.json` from the shared Claude resource layout.
+- `profile-local`: detach those shared resources for the account. This is the existing `--bare` behavior exposed as an existing-account setting.
 
 Only opt in to shared history when both accounts should see the same local continuity:
 
@@ -42,7 +52,7 @@ Only opt in to shared history when both accounts should see the same local conti
 ccs auth create work2 --share-context --context-group daily --deeper-continuity
 ```
 
-For existing accounts, use Dashboard -> Accounts -> Sync on both accounts, set both to `shared`, and use the same `History Sync Group`. Use `deeper` only when users expect stronger local handoff beyond project context.
+For existing History Sync, use Dashboard -> Accounts -> Sync on both accounts, set both to `shared`, and use the same `History Sync Group`. Use `deeper` only when users expect stronger local handoff beyond project context. History Sync does not control plugins or `settings.json`; use `ccs auth resources` for that.
 
 ## Why This Is Safe Enough
 
@@ -147,11 +157,20 @@ ccs auth create backup2 --share-context --context-group sprint-a --deeper-contin
 
 ### Existing account
 
+History Sync:
+
 - Open `ccs config`
 - Go to `Accounts`
 - Click the pencil icon (`Edit History Sync`)
 - Choose `isolated` or `shared`, set group, and (optionally) choose deeper continuity
 
+Shared Resources:
+
+```bash
+ccs auth resources work --mode profile-local
+ccs auth resources work --mode shared
+```
+
 No account recreation required for this workflow.
 
 ### Backup Before Changing Sync
@@ -172,6 +191,7 @@ ccs auth backup default
 - Shared context is local filesystem sharing. It does not bypass remote provider permission models.
 - Session continuity still depends on what the upstream tool/provider stores and allows.
 - Context sharing should only be enabled for accounts you intentionally trust to share workspace history.
+- Dashboard controls for existing-account Shared Resources are tracked separately; CLI/API support is the source of truth until that UI lands.
 
 ## Alternative: CLIProxy Claude Pool