Skip to content

Briefing, n8n-google-migration strategy session

You are the strategy session for migrating Forge's last n8n-mediated Google API calls onto direct Python clients, and for thinking holistically about the Google OAuth + Forge Google integration architecture going forward. Justin wants to THINK, not just patch.

Read in order

  1. forge/memory/general/reference_google_oauth_architecture.md
  2. forge/memory/general/reference_google_oauth_verification_tiers.md
  3. forge/memory/handoffs/google-oauth-permanent-fix-2026-05-04.md
  4. forge/memory/general/reference_email_workflows.md
  5. forge/memory/general/reference_google_calendar_client.md
  6. forge/memory/general/reference_n8n_calendar_workflow_gotchas.md (historical, post 2026-04-30 cutover)
  7. forge/memory/general/reference_n8n_state.md

Live blocker

n8n workflow list-recent-emails (id ListEmails00001) is dead-and-erroring but still called by:

  • forge/scripts/forge_morning_report.py:232,237
  • forge/scripts/forge_telegram_inbox_brain.py:1091,1118 (likely the list_emails / search_emails bot tools)

Cannot delete the n8n workflow until those two consumers migrate to a direct Gmail client.

Deliverables

A. Audit ALL remaining n8n Google calls. grep n8n( across forge/scripts/ and list every webhook still in use. For each, classify: (1) already migrated, (2) needs migration, (3) intentionally staying on n8n and why.

B. Map current Google OAuth landscape. Which scripts use which OAuth client, which token file, refresh-token expiry posture per scope tier (Testing vs Production). Confirm or contradict the "one canonical Forge OAuth client" claim in reference_google_oauth_architecture.md.

C. Propose target architecture. Should Gmail reads go through a shared forge_gmail.py module mirroring the forge_google_calendar.py pattern? Should the inbox brain and morning report share that module? What's the right boundary between read-only ops (safe) and state-changing ops (need confirm per CLAUDE.md security rules, esp. the personal Gmail policy)?

D. Risk table. What breaks if we just delete the n8n list-recent-emails workflow without migrating? Smallest safe step that unblocks deleting the n8n surface? 1-day path vs 1-week path?

E. Write the strategy out as forge/memory/handoffs/n8n-google-migration-strategy-2026-05-11.md with: current state map, target state, migration phases with file paths, risk table, recommended order. mkdocs URL header. No em dashes. Sign [Claude Code, n8n-google-migration_Opus47].

Hard rules

  • DO NOT execute the migration in this session. Strategy + plan only. Stop at the handoff write.
  • Doctrine: zero em dashes, lead with answers, no AI giveaway phrases.
  • Justin will read the handoff and direct a follow-on worker.