Repro

Inspiration

When testing a web application, the difficult part is often not the test itself. It is getting the application into the exact state you need to inspect.

An expired account. A trial user. An unauthenticated session. A specific error state.

Reproducing these states can require creating users, changing database records, configuring subscriptions, or manually navigating through multiple steps.

I wanted to remove that setup work.

Repro lets you describe the application state you want to see, reproduce it, and inspect the real UI immediately.

We don't run your tests. We create the state you need to see.

What it does

Repro exposes application-state reproduction through three stable WebMCP tools:

list_states
reproduce_state
reset_state

Instead of creating a separate tool for every test scenario, Repro treats application states as data.

For example, an agent can discover an available state such as free_expired.

Repro applies that state to an isolated Repro session, and the application's existing UI renders normally.

This makes it possible for humans and agents to inspect production-like UI states without creating real users, payments, emails, or other production side effects.

How I built it

Repro is published as the repro-webmcp npm package.

The basic workflow is:

npm install -D repro-webmcp
npx repro scan
npx repro setup

repro scan statically analyzes an existing JavaScript or TypeScript application and discovers semantic application states from existing code, including conditional UI branches, enums, literal states, mocks, fixtures, and tests.

The discovered states become the source of truth for Repro.

repro setup prepares the runtime, browser registration, and integration boundary.

For simple supported state architectures, the connection can be generated automatically.

For more complex applications, a coding agent connects one generic bridge to the existing state boundary.

Repro generates a project-specific .repro/AGENTS.md integration guide containing both its standard integration rules and evidence discovered during the scan. A coding agent can use this to connect Repro once to the application's existing state boundary.

The important distinction is that the agent does not generate a separate test fixture for every state. It creates one generic bridge between Repro and the application's normal state/rendering system.

Dogfooding on an existing application

I tested Repro on a separate existing application that was not built for this challenge.

Before installing Repro, it contained zero manually defined Repro states.

Running repro scan discovered 20 candidate application states from the existing source code.

For this more complex application, I gave the generated integration instructions to Codex. Codex implemented one generic bridge to the application's existing authentication/session state.

After that, the same three WebMCP tools could reproduce states such as authenticated and unauthenticated, while the real application UI continued to render through its normal code path.

This dogfooding also exposed an important setup bug: the browser bootstrap was still loading an older hand-written configuration instead of the scan-generated states. I fixed the runtime/setup flow and published the fix as [email protected].

Challenges

The hardest problem was finding the right boundary between automation and application-specific integration.

Automatically discovering states is possible, but automatically modifying arbitrary application state safely is much harder. Real applications use different stores, authentication systems, module structures, and rendering architectures.

I initially considered generating state-specific fixtures, but that would simply move the manual test-setup problem somewhere else.

The architecture evolved into:

automatic state discovery + a stable runtime + one generic application bridge when necessary.

Another challenge was safety. Reproducing an expired subscription should not require modifying a real subscription. Reproducing an authenticated user should not require creating a production user.

Repro therefore focuses on reproducing the application state consumed by the UI rather than recreating the entire backend environment.

What I learned

The biggest thing I learned is that WebMCP becomes especially useful when the interface exposed to agents is semantic rather than tied to individual UI actions.

An application may contain 20, 100, or more reproducible states, but Repro still needs only three WebMCP tools.

The vocabulary remains stable while the application's states remain data.

I also learned a lot from testing the npm package against an application that was not designed around Repro. That immediately revealed assumptions that were invisible in the purpose-built demo and changed the final architecture.

What's next

After the challenge, I want to expand Repro's automatic integration support across more application architectures and frameworks.

One limitation discovered during dogfooding is multi-page applications: full-page navigation can create a new document where the WebMCP bootstrap must be initialized again. I plan to add automatic multi-entry-point instrumentation for this case.

I am also interested in exploring the same concept beyond web applications, including state reproduction for SwiftUI applications and simulator-based development workflows.

The long-term goal is simple:

Make application state an interface that both developers and agents can discover, reproduce, and inspect safely.