💡 Deploy-page onboarding for the AI scripts (manifest, Script Properties secrets step, catalog + README listing)

[github-actions[bot]]

Summary

Bring gmail-ai-classifier, drive-ai-ingester and gmail-retention-policy into the browser deploy flow. Upload their appsscript.json manifests, add a Step 4 'Secrets & properties' panel that writes Script Properties (API key, model, root folder) instead of config.gs, and list the scripts in the README catalog. Today the most capable scripts are the only ones that require clasp and a terminal.

Market Signal

The PRD's core insight is that 'adoption dies at configuration'. The browser flow is the project's stated moat compared with Zapier and Make, and Zapier now offers AI classification steps inside its ordinary editor. Google Workspace Studio has been rolling out to end users since March 2026, which raises expectations for no-code setup of AI agents. A clasp-only install puts the AI scripts out of reach of the target user (Morgan in the PRD journeys).

User Signal

The deploy catalog (src/deploy/index.js) lists only gmail-to-drive-by-labels, calendar-to-sheets and calendar-to-briefing-doc. The README catalog lists only two scripts. gmail-ai-classifier/README.md tells users to run 'npx @google/clasp login/create/push' and to hand-enter 10+ Script Properties. PRs #649 and #628 shipped these scripts in the last 30 days, so they are the newest and most active area of the codebase.

Technical Opportunity

The deploy page already does projects.create and updateContent with a file list, so adding appsscript.json (with advanced services and oauthScopes) to the uploaded files is incremental. The AI scripts read configuration through PropertiesService. Apps Script API updateContent cannot set Script Properties directly, so the cleanest path is to deploy a tiny generated setup.gs with a one-shot function the user runs once (or exposes as a web-app doGet) to write the properties. A schema-driven catalog contract (idea #144) would let the panel render property fields from metadata.

Assessment

Dimension	Score	Rationale
Feasibility	med	Grounded in existing seams described above
Impact	high	See Market and User Signal
Urgency	med	See Market Signal (dated platform changes)

Adversarial Review

Strongest objection: Handling an API key or PAT in a static web page is a security risk, and the classifier's GitHub-sync and multi-account features are too advanced for a no-code audience anyway.

Rebuttal: The key never needs to leave the browser except to go into the user's own Apps Script project over the same OAuth session that already writes code. It does not go to any server of ours. The minimum viable version can omit GitHub sync entirely (it is already optional) and expose only GEMINI_API_KEY, the model and the Drive root folder. Leaving the newest AI scripts CLI-only contradicts the product positioning and hides them from every deploy-page user.

Suggested Next Step

Spike: add gmail-retention-policy, which needs no AI key, to the deploy catalog including its appsscript.json, to prove manifest upload works. Then design the Properties panel for gmail-ai-classifier, limited to GEMINI_API_KEY, GEMINI_MODEL and DRIVE_ROOT_FOLDER_ID, with the privacy-tier notice from the privacy-safe AI proposal.

---

Generated by the weekly feature-ideation agent (Mary, BMAD Analyst). Sources: Gemini API terms · Gemini deprecations · Apps Script release notes · Vertex AI advanced service · Gmail Gemini era · SaneBox review · Workspace Studio