Playground/Agents & workflows/Clean-room rebuild
API ACTIVITY

Usage & budget

PLAYGROUND SAFETY LIMITS

Steady requests. Visible limits.

0 active · 0/20 queued

Browser: one start every 1.2 seconds (at most 50/minute), up to 2 active calls and 20 waiting. Shared by examples in this tab. Waiting requests cancel when their run is stopped; a full queue rejects new work without an API call.

Server: 60 requests per rolling 60 seconds and 2 concurrent calls per key, per server instance. Other tabs using the same key share that instance’s allowance. This in-memory safeguard resets on restart and is not a distributed or account-wide quota.

Source: playground policy in lib/requestRateLimit.ts. TypeSafe may impose separate limits. Provider HTTP 429 pauses calls until its reported reset; without a reset time, retry requires your action. HTTP 402 is a budget/billing failure, not a pacing limit. No automatic retries or background replay.

Your TypeSafe API key

Import your key to override the shared server default.

Saved on this browser until removed or site data is cleared. Masked on screen; sent only with Jev requests through this app. The saved value is never displayed.

Connecting
OBSERVE → REBUILD → VERIFY

Clean-room rebuild

Turn observed screens and API contracts into a working app. Keep every decision and check the result.

WORKSPACE GUIDE

Clean-room rebuild

Rebuild observed screens and API contracts, then compare behavior in a real browser.

ObserveRebuildVerify

What you provide

A local catalog, contacts, or support-ticket demo plus the rebuild context. Chromium observes the original target's interface and API behavior.

What happens

The demo uses simulated Jev choices and trusted deterministic templates to observe, map, emit, and rebuild the interface in isolation.

What you get

A separately served rebuilt app, downloadable artifacts, and independent behavior and visual comparisons. Failed checks remain visible.

Walk through a run

  1. 01

    Choose a demo

    Try catalog search, contacts CRUD, or a support ticket.

  2. 02

    Run locally

    The pipeline observes a local target and rebuilds its interface with deterministic templates.

  3. 03

    Check the rebuild

    Open the rebuilt app and inspect the independent behavioral and visual comparisons.

Try this

Run the catalog demo, open the rebuilt app, search for Cloud, and compare the result with the recorded verification evidence.

Execution limits

UI demos use simulated Jev choices and require local Chromium. They do not establish live model quality or cost.

Explore the example. Check the evidence.
PREFILLED CONTEXT

Searchable catalog

Local demo · simulated Jev choices · no API key required. Real browser capture, endpoint calls, component export, and verification.

Inspect the target and interaction scenario
{
  "openapi": "/openapi/catalog",
  "screens": [
    {
      "id": "catalog",
      "path": "/catalog",
      "readyText": "Cloud notebook",
      "scenarios": [
        {
          "id": "search",
          "actions": [
            {
              "kind": "fill",
              "role": "textbox",
              "name": "Search products",
              "value": "Cloud"
            },
            {
              "kind": "click",
              "role": "button",
              "name": "Search"
            }
          ],
          "expectText": "Cloud notebook"
        }
      ]
    }
  ]
}

Needs Chromium on the server running this app. For a custom target or live Jev, use pnpm clean-room. Instructions are in docs/clean-room/README.md.

INDEPENDENT EVIDENCE

Six stages. One checkable result.

  1. 1
    Observe target
  2. 2
    Map endpoints
  3. 3
    Map screens
  4. 4
    Build components
  5. 5
    Wire actions
  6. 6
    Verify behavior
Choose an example to start.