💡 Platform feature: drive-event-reactor (configurable event-driven Drive automation using newly GA Events API)

[github-actions[bot]]

Summary

A configurable rules-engine for Google Drive that reacts to file events (added, edited, moved, trashed) in watched folders and executes user-defined actions: move/copy file, send email notification, log to a tracking Sheet, apply naming conventions, or trigger another script. Leverages the Google Workspace Events API's Drive subscriptions, which reached general availability on May 18, 2026.

Market Signal

The Google Workspace Events API's Drive subscriptions went GA on May 18, 2026 — a brand-new platform capability enabling real-time, event-driven Drive automation via Pub/Sub. Prior to this, Drive automation required polling. Zapier charges $19.99/mo+ and Make charges by operation for equivalent event-driven Drive triggers. No open-source implementation of Drive event-reactive automation exists yet. The early-mover advantage window for a free, FOSS implementation is wide open.

Additionally, Q2 2026 saw Google release official MCP servers for Drive (with copy_file support) and the Drive API gained programmatic file approval management — all signals pointing toward a richer event-driven Drive automation ecosystem.

User Signal

Existing Discussion #517 (drive-activity-digest) covers passive monitoring and reporting of Drive changes — generating a digest of what changed. This proposal fills the distinct gap of reactive automation — taking configurable action in response to changes, not just observing them. The difference is the same as "email notification of new messages" vs. "auto-label and file new messages" — observation vs. automation.

Technical Opportunity

The project's existing architecture naturally extends to an event-driven rules engine:

• Config-driven rule definitions in config.gs: {watchFolder: "...", trigger: "file_added", action: "move_to", destination: "..."}
• Deploy page config UI can render folder-picker + action selection via the existing SCRIPT_CATALOG schema pattern
• Tiered implementation path:
  • Phase 1 (MVP): Polling-based — scheduled trigger every 15 min checks folder contents against stored snapshot. Zero GCP setup required. Fits the project's zero-friction deployment model perfectly.
  • Phase 2: Events API + Pub/Sub for real-time reactivity — opt-in upgrade for power users who already have GCP projects with billing.

The dual-phase approach mirrors how the project handles other progressive complexity (e.g., Step 4 config is optional, Gemini integration is opt-in).

Assessment

Dimension	Score	Rationale
Feasibility	med	Polling MVP is straightforward (DriveApp + ScriptProperties). Events API path requires Pub/Sub setup, increasing complexity.
Impact	high	Unlocks a new class of automations (reactive vs. scheduled). Free alternative to Zapier/Make Drive triggers.
Urgency	high	Drive Events API just went GA (May 2026). First-mover window for FOSS implementation. Market is forming now.

Adversarial Review

Strongest objection: The Events API requires Google Cloud Pub/Sub topics, which need a GCP project with billing enabled. This breaks the project's core zero-friction, no-CLI deployment promise and could confuse the target audience of non-technical users.

Rebuttal: Offer a tiered approach: (1) The polling-based MVP uses simple time-based triggers to check folder contents every 15 minutes, comparing against stored snapshots — zero GCP setup required, fully deployable through the existing deploy page. This alone provides substantial value. (2) The Events API upgrade path is documented as an opt-in enhancement for power users, with a step-by-step guide. This mirrors the project's existing approach where GCP project setup is already part of the fork-maintainer onboarding (see README "One-Time GCP Setup"). The polling MVP ships first and delivers value independently.

Suggested Next Step

Design the rules schema (trigger condition + action pairs) with 3 MVP actions: move file to folder, send email notification, append row to tracking Sheet. Implement the polling-based MVP first (time-based trigger, folder content snapshot comparison via ScriptProperties). Validate polling latency (15-min interval) against user expectations and document the Events API upgrade path as a Phase 2 enhancement.