🏗️ Architecture: How should we scope the OAuth credential delegation implemen...

Date: 2026-03-18
Time: 17:19:09 UTC
Session: gspace1-234.10
Agent: architecture
Confidence: 91%
Status: ✅ Documented

📋 Decision Context

Question:

How should we scope the OAuth credential delegation implementation across Jarvis phases?

Task: S234: Jarvis Evolution - OAuth scoping decision

🎯 Decision Made

Chosen:

Phased OAuth MVP: Phase 3a delivers end-to-end Google OAuth (schema + backend endpoints + PKCE + encryption + agent tool), Phase 3b adds providers (GitHub/Slack/Notion) + frontend UI + admin dashboard. Deferred: token health cron, Composio integration, frontend Connected Services tab. Agent-based connect via chat for MVP.

Options Considered:

1. Full OAuth spec implementation in one phase (all 4 providers + frontend + cron)
2. Phased MVP: Google-only core flow first, then expand (chosen)
3. Skip OAuth entirely, use Composio from day 1

💭 Reasoning

The full spec's OAuth design is sound but massive (8+ files, 6 endpoints, 4 providers, cron jobs, frontend UI). Attempting everything at once risks half-built infrastructure. The critical path for user value is: connect Google → agent reads calendar. This requires only the core flow (schema, encrypt, consent, callback, proxy, tool). Additional providers are the same pattern with different config. Frontend UI can come after the backend is validated. Token health cron is nice-to-have — tokens last 1 hour, manual reconnect is acceptable for MVP. The agent-based approach (oauth_connect tool returns a clickable link in chat) actually delivers a better initial UX than building a full settings page.

📁 Files Involved

• docs/superpowers/plans/2026-03-18-jarvis-p3-oauth-mvp.md

🔗 Related

• Decision ID: dev_1773854348990_glpwcry
• Session: 234
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation