Support multiple Google accounts / named connector profiles for Gmail, Drive, Calendar, Contacts, and Tasks

[enkayxyz]

Problem Statement

What problem does this solve? Why is this needed?

First, thank you for the incredible work on OpenJarvis. The local-first, on-device personal AI direction is exactly the framework I’ve been looking for.

Right now, I am trying to use OpenJarvis as a unified personal intelligence layer across multiple real-life identities and contexts (personal, work, research projects, family, etc.). In practice, this means managing data across multiple distinct Google accounts.

Currently, the Google connector flow is single-account oriented. Running a bootstrap command like:

jarvis connect gdrive

### Proposed Solution

Introduce support for **named connector profiles / account aliases** across the core credential management layer and CLI. 

#### 1. Explicit Parameter Scoping in the CLI
Allow users to isolate credential buckets during authentication:
```bash
jarvis connect google --account personal
jarvis connect google --account work
jarvis connect google --account research

Or at the individual primitive level:

Bash
jarvis connect gdrive --profile personal
jarvis connect gmail --profile work

2. Segmented Storage Hierarchy
Instead of flattening everything into a singular google.json or gdrive.json, store tokens cleanly by account alias:

Plaintext
~/.openjarvis/connectors/google/accounts/personal.json
~/.openjarvis/connectors/google/accounts/work.json
A single OAuth execution should still maintain the convenience of authorizing Gmail, Drive, Calendar, Contacts, and Tasks simultaneously for that single named profile instance (e.g., creating gmail:personal, gdrive:personal, etc.).

3. Source-Aware Document Indexing & Retrieval
Documents emitted by the sync pipelines should embed deterministic profile metadata:

Python
metadata = {
  "account": "work",
  "connector": "gmail",
  "source_email": "user@company.com"
}
This enables Persona-Scoped Queries like:

"Summarize only my work email and calendar from this morning."

"Search my research Drive, but ignore my personal files."

4. Account Filters in Config and Core Primitives
Update the standard tool definitions to accept an optional account argument to prevent accidental cross-account data bleeding:

Python
gmail_search_emails(query="invoice", account="work")
gcalendar_list_events(account="family")
Expose this mapping inside config.toml for specialized Operatives and custom local loops:

Ini, TOML
[connectors.google.accounts.personal]
enabled = true

[connectors.google.accounts.work]
enabled = true

[digest]
accounts = ["personal", "work"]

[agent]
default_accounts = ["personal"]
Potential UX Layout:
Bash
jarvis accounts list
jarvis accounts add personal --provider google
jarvis connect google --account personal
jarvis ask --account work "What critical updates did I miss?"
jarvis ask --accounts personal,work "Where do my calendars conflict today?"

### **Primitive Area**
*Select **`Intelligence`** from your template dropdown, or add this to the text body:*
`Touches: Connectors (Gmail, GDrive, GCalendar), CLI (connect_cmd), Storage/Memory Primitives`

### **Alternatives Considered**
```markdown
### Any alternative solutions or features you've considered.

I have successfully bypassed this manually by isolating completely separate OpenJarvis configuration environments via the shell environment:
```bash
JARVIS_CONFIG_PATH=~/.openjarvis_work/config.toml jarvis connect gdrive
While this successfully keeps credentials separated, it splits the entire workspace, local vector storage backends, and semantic indexes entirely. This fragmentation prevents the Orchestrator from running unified cross-account indexing, cross-calendar conflict analysis, or comprehensive multi-account personal daily digests.


### **Additional Context**
```markdown
### Additional Context

Because OpenJarvis runs entirely on-device, this feature perfectly reinforces its core value proposition. Users shouldn't have to choose between their personal data privacy and their professional data isolation. Bringing multi-account tracking on-device allows absolute corporate/personal boundary enforcement without throwing away the unified utility of a local agent.

I am running on macOS and would be happy to help test/validate experimental m

### Primitive Area

Intelligence

### Alternatives Considered

creating multiple jarvis installs would be clumsy or creating multiple roots and shells to run them

[enkayxyz]

Google Account Profiles: Analysis Layer Plan

This note extends the Google connector profile work from the connect/auth layer
into analysis, retrieval, citations, and test coverage.

Goal

Named Google profiles should not stop at token storage. Once users connect
accounts such as personal, work, research, subscriptions, or banqer,
OpenJarvis should preserve that account boundary through indexing and analysis
so a query can intentionally search one persona, several personas, or all
indexed Google data.

Data Model

Connector documents now carry profile metadata:

metadata = {
    "account": "work",
    "source_profile": "work",
    "connector": "gmail",
}

Google document IDs are also account-aware where applicable, for example:

gmail:work:<message-id>
gdrive:research:<file-id>
gcalendar:family:<event-id>

The knowledge store exposes both plain connector IDs and account-scoped IDs in
distinct_sources():

gmail
gmail:work
gdrive:research
gcalendar:family

Retrieval Semantics

Analysis supports two equivalent scoping styles:

store.retrieve("renewals", source="gmail:work")
hybrid.search("renewals", sources=["gmail"], accounts=["work"])

The first form is useful for direct retrieval and config-style source lists.
The second form is useful for planners because account aliases can be combined
with multiple connectors:

hybrid.search(
    "calendar conflicts",
    sources=["gcalendar"],
    accounts=["personal", "work"],
)

HybridSearch applies account filters with
json_extract(metadata, '$.account'), so source and account filters intersect
instead of overwriting each other. For example, sources=["gdrive"] plus
accounts=["work"] returns work Drive chunks, not work Gmail or personal Drive.

Planner Behavior

The research loop exposes a structured accounts search parameter:

search(query, person=None, time_range=None, sources=None, accounts=None, limit=20)

Planner rules now tell the model:

• Use sources=[...] when the user names a connector such as Gmail, Drive, or
  Calendar.
• Use account-scoped source IDs such as gmail:work only when they appear in
  the connected-sources list.
• Use accounts=[...] when the user names a persona/profile/account such as
  "work account", "personal Drive", or "research calendar".
• Combine both filters when the user names both a connector and an account, for
  example sources=["gmail"], accounts=["work"].

Example user requests:

Summarize only my work email and calendar.
Search my research Drive, not personal Drive.
What overlaps between my personal calendar and project calendar?
Find docs related to x0bni across my project account and personal notes.

Citation And UI Metadata

Search hits now include:

SearchHit.account
SearchHit.source_profile

build_sources_for_client() passes both fields through to the citation payload
so the UI can render provenance such as Gmail / work and follow-up queries can
preserve the same profile scope.

Sync API

The connector sync API accepts an optional account query parameter:

POST /api/connectors/{connector_id}/sync?account=work
GET  /api/connectors/{connector_id}/sync-status?account=work

Sync state is keyed by connector/profile pair. A long-running gmail:work sync
does not hide or overwrite gmail:personal status.

Migration

For a clean install that already has one legacy Google profile:

jarvis connect google --account work

This creates a fresh token at:

~/.openjarvis/connectors/google/accounts/work.json

If reauthenticating is not desirable, copy the legacy token:

mkdir -p ~/.openjarvis/connectors/google/accounts
cp ~/.openjarvis/connectors/google.json \
  ~/.openjarvis/connectors/google/accounts/work.json

Then run a profile sync so newly indexed chunks receive account metadata.

Test Plan

Connector/auth/profile tests:

uv run --extra dev pytest \
  tests/connectors/test_oauth_flow.py \
  tests/connectors/test_gmail.py \
  tests/connectors/test_store.py \
  tests/cli/test_connect.py

Analysis-layer tests:

uv run --extra dev pytest \
  tests/agents/test_research_loop.py \
  tests/connectors/test_hybrid_search.py

Lint:

uv run --extra dev ruff check \
  src/openjarvis/agents/research_loop.py \
  src/openjarvis/connectors/hybrid_search.py \
  src/openjarvis/server/connectors_router.py \
  tests/agents/test_research_loop.py \
  tests/connectors/test_hybrid_search.py