💡 Deploy page: configuration version history with visual diff and one-click rollback

[github-actions[bot]]

Summary

Add configuration versioning to the deploy page: each time a user saves config via Step 4, store the previous config.gs content as a timestamped snapshot in Script Properties. Show returning users a "History" panel with a visual diff of what changed between versions, and offer one-click rollback to any previous configuration.

Market Signal

No competitor in the Google Apps Script automation space offers config version history. Zapier launched "Zap Version History" in 2025 for workflow versioning — setting an expectation that automation configuration should be reversible. The project's PRD identifies the returning-user config edit flow (Journey 2: Morgan updates her configuration) as a key user journey. Version history directly addresses the "did I break something?" anxiety that users face when editing existing configurations. The PRD's core insight — "adoption dies at configuration" — means config changes need to feel safe and reversible, not just possible.

User Signal

• No existing Discussion addresses config versioning, diffing, or rollback
• Discussion 💡 Schema-driven SCRIPT_CATALOG contract for Step 4 config UI #144 covers schema-driven config UI; Discussion 💡 AI-assisted configuration wizard (Gemini-powered deploy page Step 4 pre-fill) #587 covers AI-assisted config wizard — neither addresses the post-save "undo" need
• The deploy page already reads and writes config.gs via the Apps Script API (projects.getContent / projects.updateContent), so the read/write infrastructure exists
• The PRD explicitly designs for returning users who re-open the configurator with existing config pre-populated

Technical Opportunity

Script Properties can store JSON-serialized config snapshots:

• Each config.gs is typically under 1KB
• Script Properties allows 9KB per property, 500KB total per project
• Storing the last 5 versions requires approximately 5KB — well within limits

The deploy page already parses config.gs content for pre-population (PRD Journey 2), so diffing two versions is a natural extension. A lightweight client-side diff utility (simple line-by-line comparison with added/removed highlighting) renders changes visually without external dependencies.

Storage schema concept:

_config_history_1 → { timestamp, content, label }
_config_history_2 → { timestamp, content, label }
...
_config_history_meta → { count, oldest_idx, newest_idx }

Assessment

Dimension	Score	Rationale
Feasibility	high	Script Properties provides the storage backend. The deploy page already reads/writes config. Client-side diffing is well-understood. No new APIs required.
Impact	med	Reduces anxiety for returning users editing config. Prevents accidental misconfiguration from being permanent. Adds a quality-of-life feature no competitor offers.
Urgency	low	Quality-of-life improvement; not tied to external timing or competitive pressure. Best implemented alongside other deploy page enhancements.

Adversarial Review

Strongest objection: Personal automation users rarely change their config. Building version history for something that changes once every few months is over-engineering.
Rebuttal: The PRD explicitly defines the returning-user edit flow as a key journey, meaning config changes are an expected and designed-for interaction. More importantly, version history serves a psychological function: it makes users comfortable experimenting with config changes because they know they can undo. This reduces support burden (users don't need to ask "what was my old config?") and increases confidence in self-service management. The implementation cost is low (Script Properties storage + client-side diff), making the cost/benefit ratio favorable even for occasional use.

Suggested Next Step

Design the Script Properties schema for config snapshots (key naming convention, max versions, rotation policy). Mock up the History panel UI within the deploy page's Step 4 section — a collapsible timeline showing version timestamps with diff-on-click. Implement the diff rendering as a client-side JS utility with no external dependencies.