Inspiration
What it does
How we built it
Challenges we ran into
Accomplishments that we're proud of
What we learned
What's next for Showrunner
## Inspiration
A product demo can fail because of one tiny release change: a renamed button, a stale path, or a missed fallback. Teams often discover that drift only when they are already presenting. SHOWRUNNER treats a demo like a release artifact: map it, rehearse it, verify it, and carry a proven recovery route onto the stage.
## What it does
SHOWRUNNER turns a product release into a bounded, rehearsed, stage-ready story.
An approved user can connect a real public GitHub repository and public HTTPS deployment. SHOWRUNNER resolves the repository's default branch and exact commit, performs a server-side deployment handshake, and stores the user's workspace, project, and release under Supabase Row Level Security.
The Build Week recovery proof then runs a fixed, authorized Atlas product scenario. SHOWRUNNER compiles a seven-beat story, opens an isolated Chromium context, performs the allowed actions, captures sanitized evidence, and detects a deliberately renamed semantic control.
The server creates a small set of safe recovery candidates. GPT-5.6 selects one candidate by ID, and SHOWRUNNER replays the complete story in another clean browser context. Strict deterministic checks, not the model, decide whether the release is READY.
A successful rehearsal produces an evidence-backed readiness receipt and a persistent Stage Session with Play, Pause, Next Beat, and Previous Beat controls.
The public-repository import and Atlas rehearsal are intentionally separate in this competition build. Imported projects receive real source mapping and deployment validation, while the full browser recovery proof runs only against the clearly labelled, authorized sample.
## How we built it
- React, Vite, and TypeScript power the control-room interface.
- Zod and canonical JSON contracts keep run state fail-closed.
- GPT-5.6 Structured Outputs provide bounded story planning and sanitized locator-candidate selection.
- Playwright runs the approved rehearsal and recovery replay in isolated Chromium contexts.
- Screenshots and sanitized logs are content-addressed and bound to the verified receipt.
- A Node service on Google Cloud Run provides exact-origin CORS, request limits, idempotent run summaries, and server-authoritative Stage state.
- Supabase Auth, an explicit access table, and RLS isolate workspaces, projects, and releases.
- GitHub's public REST API resolves public repositories and exact commits without storing a GitHub token.
- A bounded HTTPS checker rejects private addresses, revalidates redirects, pins connections, and enforces strict time and byte limits.
- Vercel hosts the production frontend.
GPT-5.6 never receives arbitrary browser authority. It cannot provide URLs, selectors, commands, code changes, or readiness verdicts. It can only return data matching narrow server schemas. Deterministic execution and verified evidence control the Stage gate.
## How we used Codex
Codex was the primary build collaborator throughout Build Week. It helped research the competition rules, narrow the concept and safety boundary, implement the frontend and backend, review responsive design, write contracts and tests, debug authentication and deployment, verify the browser flow, and prepare the judging documentation.
Key human decisions included restricting the model to bounded structured data, keeping imported-project validation separate from the authorized Atlas proof, and making READY a server-side integrity result instead of an AI opinion or frontend animation.
## Challenges we ran into
The hardest problem was making the system adaptive without giving a model unsafe or unverifiable browser control. We separated proposal from authority: the server creates every allowed action and candidate, GPT-5.6 can only organize or select from those inputs, and deterministic checks verify the result.
## Accomplishments that we're proud of
- A real clean-browser rehearsal and complete recovery replay.
- Bounded GPT-5.6 planning and candidate selection.
- Content-addressed evidence checked before receipt creation.
- A fail-closed Stage gate with persistent presenter controls.
- Invite-only access and token-free public-repository onboarding.
- 118 automated tests covering contracts, runtime, browser execution, recovery, evidence, authentication, and Stage state.
## What we learned
Reliable AI developer tools need a clear boundary between proposing an action and proving an outcome. A model can make a workflow more adaptive, but a stage-ready verdict should come from deterministic execution and evidence.
## What's next
Next milestones include queued isolated workers for imported releases, hostile-code sandboxing, a private GitHub App, authenticated target applications, reusable demo templates, and team collaboration.
Log in or sign up for Devpost to join the conversation.