Verify Web Apps with Construct

Construct checks a running web app in a real browser and records screenshots, a video, and the result of each expected behavior. Its results identify the Git commit and working tree used for the check.

Construct is in early access. When enabled for your organization, it is a built-in skill for type.com’s managed Claude and Codex agents. Type installs the runner in the managed sandbox automatically. Connected OpenClaw agents and agents running outside Type do not receive this managed workflow.

What it checks

Construct works with web apps from repositories outside Type’s own codebase. The app must run in the managed sandbox and be reachable on a local or private-network HTTP(S) address. The agent uses your repository’s setup instructions, dependencies, and test data.

Checks can sign in through the app’s login form, fill fields, choose options in dropdowns, attach files, click controls, follow navigation, reload pages, and assert visible results. Each expected outcome needs an assertion. Before writing a check, the agent opens the page and lists its controls, so the check uses the names your app actually shows.

Construct uses Chromium. It does not verify native mobile or desktop interfaces, background jobs with no endpoint, libraries, or command-line tools. For those changes, the agent uses the repository’s tests and explains what was checked.

Server and API changes

When a change has no page to show it, such as a new endpoint, a fix to how an order is saved or a validation rule, the agent checks it through your app’s own HTTP API. It sends requests the way your app’s clients do, signs in through your login endpoint, a test token or a saved session, and checks the status codes and values that come back. For a write, it reads the record back to prove the change was stored, not only acknowledged.

Requests go only to your running app, never to other sites. Passwords, tokens, cookies and credential headers are removed from the text the check saves, such as request logs, reports and diagnostics. Screenshots and videos show whatever the page displays, so test pages should not show secrets.

Start a check

1. Connect GitHub and give the Space access to the repository.
2. Ask for a web app change, or ask the agent to verify an existing change. Include owner/repository when it differs from the Space’s default repository.
3. Provide any missing test credentials through Type’s secure environment form. Use disposable databases and test accounts.

For example:

In acme/customer-portal, fix the search filter so it stays selected after saving an item. Verify the change and attach the browser evidence.

When Construct is enabled for your organization, changes to what web app users see or do in a connected repository are verified automatically. You do not need to request testing or recorded proof. Repository instructions guide app setup and test commands; they do not make Construct opt-in. You can explicitly ask the agent to skip Construct for a particular task.

Repository setup and test credentials

For the Space’s default checkout, the agent checks whether Type’s automatic setup is still running or has completed before starting another setup. It then starts the app using the saved run command and test environment.

When you name another repository, the agent checks its identity and follows that repository’s setup instructions. The default repository’s commands and credentials are not assumed to apply.

Tell Type how to verify your app

Add a Verification section to your repository’s AGENTS.md or CLAUDE.md, or link a file from there. The agent reads it from the checkout it is working on. Describe:

• How to start the app for testing, if it differs from your normal run command.
• How to sign in, for example the test account’s variable names or a command that creates a session. If your login goes through another site, such as an external sign-in provider, describe a test sign-in that works inside the app.
• How to prepare disposable test data.
• Where saved recipes live, if you keep any.

The section describes how to verify, not whether to. Keep secret values out of it. When your repository has no such section and a check passes, the agent can offer to write one from what worked.

Enter secrets through the secure form, not in chat or recipe files. Save the default repository’s test account for the repository, so later threads reuse it; scope credentials needed for only one check to the thread. Keep the names your repository already uses, such as E2E_EMAIL and E2E_PASSWORD. Recipes can read any variable except the credentials Type manages for the sandbox (TYPE_*, GH_TOKEN, GITHUB_TOKEN and GIT_CONFIG_*). Values a recipe reads must be at least four characters long so Construct can redact them safely. Construct uses those values only on your app’s own pages, so a link or redirect to another site cannot collect them. It removes them from its text artifacts; screenshots and video still show what the page displays. Use test accounts and avoid displaying sensitive data on the page.

If your app signs in through another site, or needs a magic link, MFA or a captcha, Construct can start signed in from a Playwright storage state file instead of using the login form. Point the agent at a file your end-to-end setup already writes, or at a dev-only command that creates a session and saves one.

What you get back

The agent treats your request as a set of parts and checks each part on its own: in the browser when you would see it on a page, through your app’s API when you would not. You get one attachment and one short reply.

The attachment is a video of the check when any part ran in the browser, with a short caption for each API call. When every part was checked through the API, it is the API transcript instead: each request the agent sent and the response that came back.

The reply is short. It starts with the status and whether the same check failed before the change, then has one line for each part of your request: what was observed, and where to look, either a time in the video or the server’s response. A last line lists anything the check did not show, when there is something. Ask the agent how it was checked to hear about the test account, test data and regression tests. For example:

Verified — the same check failed before the change.

- Archive an order from the orders page: the button removes "Ana" from the list, and it stays gone after reload (0:04).
- Archived orders are stored: reading the order back returns archived: true.
- Shipped orders can't be archived: the server answers 409 "order has shipped" and the order stays active.

Not shown: how the list behaves with many archived orders.

Before calling a change Verified, the agent has the evidence reviewed by a fresh sub-agent. The sub-agent starts without the conversation and receives only your request, copied from the thread, and the evidence for each part: grids of frames and page text from the recording, and the requests and responses. It judges what the app did rather than the agent’s code or reasoning, and runs on the same account as the rest of the agent’s work. It checks each part against your request and that nothing you asked for is missing. When your request implies you would see something on a page and the check only looked at responses, it does not pass that part. If the review fails, the agent fixes the app or the check and runs it again, or reports the change as Unverified with what the reviewer saw.

Before it changes code, the agent runs the same check on the old code and confirms it fails, so it knows the check catches the change, whether that is a bug fix or new behavior. Construct confirms the final check is the same one that failed on the old code, and the reviewer sees that result. The agent does this in the same checkout and does not set up a second copy of your app.

The status is Verified, Unverified, or Skipped. Unverified means the change can be reviewed but Construct or the review could not finish or pass, or some part did not work; the part lines show which. Skipped means you asked to skip it, or the change has nothing Construct can check through a page or your app’s API. These are agent-reported statuses, not a server-enforced delivery gate.

The run’s detailed records stay in the sandbox: screenshots, the result and hash manifest, and a self-contained HTML report. Ask the agent to attach them if you want them.

A recording shows the app as it ran in the sandbox. It does not establish behavior in other browsers or with production data and configuration.

Troubleshoot

What you see	What to do
The Construct skill is unavailable	Confirm you are using a managed Claude or Codex agent and that early access is enabled for your organization. Contact support if needed.
construct is missing or its doctor check fails	Ask the agent to report the diagnostic output. Type manages the installation; do not install a replacement browser workflow.
Repository setup is still running	Wait for the existing setup and inspect its log. Starting another copy can conflict with dependency installation or database setup.
The app cannot start	Check the target repository’s setup/run commands and provide the missing test variables through the secure form.
A submodule is uninitialized	Initialize the repository’s submodules with git submodule update --init --recursive, then rerun. Construct includes initialized submodules, including nested changes, in its working-tree check.
The base URL redirects to another site	Construct follows redirects within the app, such as / to /login, but not to another site such as an external sign-in page. Start from a page the app serves itself with a test sign-in that works inside the app, or provide a storage state file so the check starts signed in.
The app returns an HTTP error	Inspect the app logs. Allow HTTP errors only when the intended check is an error page.
The working tree changed during the check	The failure names the files that changed. If your app writes them while it runs, such as a local database, uploads or logs, store that data outside the checkout or ignore those paths. Otherwise finish edits or code generation, then rerun.
A check fails, or passes, because of data from an earlier run	Your app keeps data between runs. Ask the agent to name the records its check creates with {run:id}, a value that is new on each run, and to check those names.
The failure says the browser is on a different page	The app redirected the browser, for example to a sign-in page or because a feature flag is off. Fix the sign-in or flag setup rather than the check.
The review failed	Read what the reviewer saw. The app may be wrong, or the recording may not show the requested behavior clearly. Ask the agent to fix it and record again.
The result is not ready to deliver	Inspect the failing outcome or evidence diagnostic. A passing page assertion alone does not replace the final video and evidence checks.