💡 Step 5 — Manage: deployed-script status dashboard in deploy page

[github-actions[bot]]

Summary

Extend the deploy page with a Step 5 — Manage: a dashboard view of every script the user has deployed via the page, showing trigger status, last run time, last run result, and one-click controls to pause/resume/reconfigure. This closes the loop between "I deployed this thing" and "is it still working?" — currently a complete blind spot once the user closes the deploy tab.

Market Signal

Every mature no-code automation platform — Zapier, Make, n8n, Lindy — leads its UI with a "My Workflows" / "Run history" dashboard. It's the second screen users see after onboarding because trust in an automation is a function of observability, not initial setup. Multiple 2026 trend reports name "agentic, context-aware workflows" as the direction of travel, and observability is the floor those features have to stand on. The gap between deploy-and-forget and managed-automation is the single biggest UX delta between this project and its commercial peers.

User Signal

The PRD explicitly lists this as a Phase 3 vision item: "Monitoring / last-run status dashboard." Journey 2 in the PRD ("Morgan Updates Her Configuration Six Weeks Later") already imagines the user returning to the deploy page weeks later — but offers no answer to the question every returning user will actually have first: "is it still running?" The journey jumps straight to editing config, skipping over the moment of doubt that real users will have.

Technical Opportunity

The plumbing is largely there:

• The deploy page already stores project IDs in localStorage for idempotent deploys → that same list is the input to the Manage view.
• The OAuth scopes already include script.projects and (per PRD) script.deployments / trigger access for verification → no new consent prompts.
• The Apps Script API exposes projects.list, projects.deployments.list, and (via Cloud Logging or stack-driver) execution history. The script-accessible / trigger-active checks from Step 4's save verification are already wired up — surfacing them on a separate screen is reuse, not new work.
• Each script's code.gs could optionally write a LAST_RUN row to a known PropertiesService key, giving the dashboard a richer payload without depending on Cloud Logging.

Assessment

Dimension	Score	Rationale
Feasibility	medium	Most APIs and verification logic exist; the new work is the dashboard UI itself plus an optional LAST_RUN convention each script opts into
Impact	high	Closes the biggest "is it working?" trust gap; turns the deploy page from a one-shot wizard into a place users return to; unlocks the "Managed automation" framing
Urgency	medium	Not a fire today, but the value compounds with every additional script in the catalog and every week a user goes without checking — the first script in the catalog ages 6 weeks before the next return visit

Adversarial Review

Strongest objection: "Building a real dashboard means quotas, polling, error states, multi-script enumeration, history, and a UI that has to stay coherent across browsers — that's a much bigger lift than 'extend Step 4' and you'll spend months on it before any user benefits."

Rebuttal: Ship the minimum viable dashboard first: a single screen listing the project IDs in localStorage, each row showing only the three checks Step 4 already runs (config present ✅ · trigger active ✅ · script accessible ✅) and the project's last-modified timestamp from projects.get. That's an afternoon of work, zero new APIs, zero new scopes, and it answers the user's actual first question ("is it running?"). Run history, pause/resume, and richer telemetry are explicit Phase 2 follow-ups — but the Phase 1 cut is small enough to ship inside one PR and immediately useful.

Suggested Next Step

Create a product brief for "Step 5 MVP" scoped narrowly to: list deployed projects from localStorage, run the three existing verification checks per project, render a status grid, link each row back into Step 4 for reconfigure. Defer pause/resume and run history to a Phase 2 brief.

---

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