💡 Schema-driven SCRIPT_CATALOG contract for Step 4 config UI

[github-actions[bot]]

Summary

Formalize a schema contract for SCRIPT_CATALOG in deploy/index.html so that adding a new automation to the catalog becomes a pure-data operation: contributors declare config fields (label picker, calendar dropdown, Drive picker, text input, multi-row group, etc.) in a JSON schema and Step 4 renders the form automatically — no new HTML, no new event handlers, no new save logic per script. This converts a documented intent ("the deploy page is architected as a script host, not a script-specific UI") into an enforceable contract.

Market Signal

The wider no-code automation ecosystem competes precisely on catalog breadth — Zapier's moat is its 6,000+ app integrations; n8n's growth lever is its community-contributed nodes. Every successful no-code platform eventually invests in a schema-driven node/connector contract for exactly this reason: the unit cost of adding the Nth integration must approach zero. This project is at the inflection point now (3 scripts) where the schema contract is the cheapest it will ever be to introduce, and where the marginal cost of not having one starts compounding with every script added.

User Signal

The PRD explicitly flags this as a Phase 1 risk: "Catalog grows faster than config UI can support new schemas → Mitigation: Define a schema contract for SCRIPT_CATALOG entries; Step 4 renders any conforming schema." The risk is named, the mitigation is named, but no idea/issue is currently tracking it. Meanwhile calendar-to-briefing-doc already exists in the repo as a third script, meaning the moment the catalog grows further, the cost of inconsistent ad-hoc config UIs becomes real.

Technical Opportunity

The current Step 4 implementation already renders different forms per script — but as imperative branches. Refactoring to a schema interpreter is a contained, well-bounded change:

• The field types needed are already implemented somewhere in the page (label dropdown, calendar dropdown, Drive Picker for Doc/Folder/Sheet, text input, multi-row group). The work is extracting them into reusable renderers keyed by type, not inventing new ones.
• Playwright E2E tests for the existing flows become the regression net for the refactor.
• Once landed, the gmail-ai-triage proposal and any future contributor script ship without touching index.html at all — they only add a catalog entry.

Assessment

Dimension	Score	Rationale
Feasibility	high	Pure refactor — no new APIs, no new scopes, no new dependencies; existing E2E tests catch regressions
Impact	high	Multiplier effect on every future script idea (including the AI-triage proposal); converts a known PRD risk into a closed item; lowers contributor friction toward the README's "growing catalog" vision
Urgency	medium	Not customer-facing on its own, but every script added without it makes the eventual refactor more expensive; right now is the cheapest it will ever be

Adversarial Review

Strongest objection: "This is a pure refactor with no user-visible value. Users don't reward platform work, and you're spending the engineering budget that could ship a third user-facing script instead."

Rebuttal: The refactor is prerequisite work for the next script, not a substitute for it. Every catalog addition from now on either (a) duplicates an imperative config-UI branch — accumulating debt the PRD already names as a risk — or (b) gets blocked on this refactor anyway when the duplication becomes painful. Doing the refactor as part of shipping the next script (e.g. bundle it with the gmail-ai-triage work) means it pays for itself immediately and the user-visible deliverable still ships. Pure-refactor framing is the wrong frame.

Suggested Next Step

Discuss with the team whether to bundle this refactor with the next catalog addition (recommended) or land it as a standalone preparatory PR. Then write a short architecture note proposing the schema shape (type, key, label, helpText, validation, picker config) and the renderer registry, and validate against the three existing scripts as a paper exercise before any code changes.

---

Proposed by the BMAD Analyst (Mary) on 2026-04-07.
Workflow run