feat: snapshot CLI + Jira/Salesforce with smart seeding

[zozo123]

Summary

Adds doubleagent snapshot CLI + Jira/Salesforce fake services + the snapshot_pull tool for Airbyte connectors. No SDK dependency — each service is self-contained.

What's in this PR

1. Rust CLI: doubleagent snapshot (5 subcommands)

• pull <service> — auto-detects connector type from service.yaml:
  • type: airbyte → delegates to snapshot_pull (PyAirbyte, no Docker)
  • type: native → runs service's connector/pull.py
• list, inspect, delete, push — manage snapshot profiles

2. snapshot_pull tool (services/_lib/src/snapshot_pull/)

Standalone Python package the CLI calls for Airbyte-backed services:

• PyAirbyte backend — pip-installed connectors, no Docker needed
• Smart relational filtering — BFS traversal: 3 projects → 10 issues each → 5 comments per issue. Small, relationally-consistent datasets instead of brute-force dumps
• PII redaction — deterministic anonymization before writing to disk (emails → user-N@doubleagent.local)
• Snapshot storage — manifest + per-resource JSON files at ~/.doubleagent/snapshots/

3. Jira + Salesforce services (read-only, snapshot-backed)

Self-contained FastAPI servers with inline COW state + namespace isolation:

• /resources — list all resource types with counts
• /resources/{type} — list/search/filter resources (supports ?q=field=value)
• /resources/{type}/{id} — get by ID
• Full control plane (/_doubleagent/health, reset, seed, bootstrap, info, namespaces)

Jira: 8 streams (projects, issues, comments, sprints, boards, users, fields, workflows)
Salesforce: 8 streams (accounts, contacts, leads, opportunities, cases, users, tasks, events)

Architecture

doubleagent snapshot pull jira
  → Rust CLI reads service.yaml → type: airbyte
  → uv run python -m snapshot_pull --service jira --image airbyte/source-jira:latest \
      --streams projects,issues,... --config-env JIRA_API_TOKEN=api_token \
      --seeding-json '{"seed_streams": [...]}'
  → PyAirbyte pulls 8 streams
  → Smart filter: 3 projects → issues/sprints/boards per project → comments per issue
  → PII redacted → saved to ~/.doubleagent/snapshots/jira/default/

doubleagent start jira
  → FastAPI server loads snapshot as read-only baseline
  → /resources/projects, /resources/issues, etc.

Test plan

• cargo check — zero warnings
• Jira smoke test — health, bootstrap, resource CRUD, namespace isolation, reset
• Salesforce smoke test — health, bootstrap, resource CRUD, filtering
• python -m snapshot_pull --help — entry point works
• Python imports resolve (all 5 modules)

🤖 Generated with Claude Code

[tomerezer]

Not sure we want to integrate wit airbyte automatically ?

[zozo123]

Needs revision per feedback:

• Snapshot should work with the existing /_doubleagent/seed endpoint, not a separate /_doubleagent/bootstrap with immutable baselines
• Remove namespace isolation from Jira/Salesforce services
• Remove COW state / inlined SDK classes — use simple dict state
• The doubleagent snapshot pull + PyAirbyte infrastructure is useful, but the output should just be seed-compatible YAML/JSON files

The snapshot CLI and Airbyte connector approach are good — just need to feed into seed instead of a separate bootstrap concept.

[zozo123]

Revised — Simplified Jira/Salesforce services and CLI per feedback:

Python services:

• Removed StateOverlay/NamespaceRouter from both Jira and Salesforce servers — ~200 lines deleted each
• Replaced with simple global dict state
• Removed bootstrap/info/namespaces control plane endpoints
• Removed httpx dependency from both services
• 322 → 122 lines per service

CLI:

• Removed --hard flag from doubleagent reset
• Removed --namespace flag from doubleagent start and doubleagent run
• Removed --validate-against-real flag from doubleagent contract
• Kept snapshot subcommand (pull/list/inspect/delete/push) and --snapshot on start/run

cargo check passes clean.

[tomerezer]

I'd separate the snapshot to its own PR

[zozo123]

Superseded by #33 (consolidated PR)