Project Info

FormCrash Lab

Inspiration

I started FormCrash Lab during OpenAI Build Week after exploring several developer-tool ideas. The problem I kept returning to was timing-dependent bugs: a user clicks submit twice because the first request is slow, retries an important action, refreshes at the wrong moment, or continues interacting while an earlier request is still processing. These failures do not always crash the application. Instead, they can create duplicate orders, duplicate payments, inconsistent records, or an interface that appears successful even though a request failed. My initial direction was too broad. I started building around browser recording, replay, and general failure testing, but the project gradually became a complicated Playwright dashboard without a clear product thesis. I eventually narrowed it down to one question: Can I reproduce a failure around an important user action and clearly prove that the same problem no longer happens after it is fixed? The project became more convincing when I tested recorded journeys from my own SaaS application. FormCrash exposed real problems in several flows that I had not noticed during normal manual testing. That was the point where it stopped feeling like only a hackathon demonstration.

What it does

FormCrash is a local-first, pre-production resilience-testing workbench for transactional browser journeys. A developer can: Record a successful journey in visible, controlled Chromium. Save that journey as an immutable version. Confirm the Critical Action that creates or changes application data. Approve an Outcome Check that proves the action succeeded. Review FormCrash's recommended state-changing network request and assertions. Generate reusable double-click, triple-click, and delayed-repeat tests. Run those tests and inspect screenshots, request evidence, assertions, ordered events, and a final verdict. FormCrash uses deterministic rules to rank network requests and recommend assertions. It does not require an AI model at runtime, and its recommendations remain explainable and repeatable. The bundled checkout demonstrates the core workflow clearly. The vulnerable version creates duplicate orders when checkout is submitted twice. The fixed version prevents the duplicate using client-side locking and server-side idempotency. How I built it FormCrash is implemented as a TypeScript monorepo managed with pnpm. The main components are: A Next.js and React dashboard for Projects, Journeys, Tests, Runs, configuration, and evidence review A Fastify control server that owns the Playwright browser and execution lifecycle Visible Chromium automation for recording and replay A bundled Next.js sample checkout with vulnerable and fixed modes Shared Zod contracts between the dashboard and server SQLite persistence for journeys, tests, runs, events, assertions, and screenshot metadata Server-Sent Events for live execution progress and event replay Recorded journeys, generated tests, and completed runs remain durable records instead of disappearing after a one-time automation wizard. External application support required additional systems for authentication-state capture, runtime variables, generated test identities, sensitive-value masking, and transitive secret redaction. Request recommendations are produced through deterministic scoring. FormCrash evaluates signals such as HTTP method, response status, request timing, origin, path similarity, repeated occurrences, and whether a request resembles analytics or background traffic. Assertion recommendations are also derived from captured evidence, including successful responses, visible outcomes, error indicators, URL changes, and the state of the control being repeatedly triggered. Challenges The hardest problem was not controlling Chromium. Playwright already handles that well. The difficult part was turning browser events, network traffic, screenshots, assertions, and warnings into a workflow a developer could understand. One click can trigger the real API mutation, multiple read requests, analytics calls, and background refreshes. Requiring the user to manually inspect every request would defeat the purpose of Guided mode, so I added deterministic request scoring to recommend the request most likely associated with the Critical Action. Assertions created a similar problem. Requiring developers to manually author every check would make FormCrash another test-script editor. The server therefore recommends assertions using evidence observed during the successful baseline journey. Authentication was another difficult area. FormCrash can capture and restore browser authentication state, but reliability still depends on how the target application manages sessions, redirects, cookies, and login state. The user interface also remains less polished than the underlying execution system. Some screens still expose too much technical information, and parts of the workflow require clearer guidance. What I learned The biggest lesson was that having a technically large project does not automatically make the product clear. At one stage, FormCrash had many features, but I still could not explain why someone would use it instead of writing Playwright tests. I had to stop expanding the feature set and narrow the workflow to: Critical Journey → Critical Action → Controlled Failure → Outcome Check → Before/After Proof I also learned that deterministic automation can remove substantial manual work without requiring runtime AI. Request and assertion recommendations are generated from captured evidence and explicit rules, so identical evidence produces an explainable result. Testing against my own SaaS was especially useful. Real applications contain authentication, redirects, changing data, background requests, and unpredictable interface states. Those tests demonstrated both where FormCrash is useful and where it remains fragile. How I used Codex and GPT-5.6 Codex and GPT-5.6 were used throughout the project for product planning, architecture, implementation, debugging, test creation, and refactoring. They helped me: Break the initial architecture into verifiable vertical slices Design the monorepo, contracts, execution lifecycle, and persistence model Implement browser recording, replay, assertions, and evidence capture Diagnose authentication, request-matching, navigation, and state-management problems Design and test deterministic request and assertion recommendation systems Review the product critically when it became too broad Refactor the interface and workflow around Projects, Journeys, Tests, and Runs I did not accept every generated direction unchanged. The most important human decisions were narrowing the product thesis, removing unnecessary directions, defining which evidence was safe to persist, and choosing deterministic recommendations instead of introducing a runtime AI dependency. FormCrash was built with Codex and GPT-5.6, but the resulting application does not require an OpenAI API key or an AI model while running. Accomplishments The part I am most satisfied with is that FormCrash is no longer limited to a fake checkout demonstration. It can record and replay journeys against another application, identify likely state-changing requests, recommend assertions, inject repeated interaction around a Critical Action, and persist the resulting evidence. The bundled checkout remains the clearest before-and-after proof: the vulnerable version creates two orders, while the fixed version creates only one. More importantly, I used FormCrash against workflows in my own SaaS and found actual problems. The project is not polished enough for general production use, but it demonstrated that the core idea is useful outside the bundled sample.

What's next

The most important improvements are: Making authentication capture and replay more reliable Simplifying the interface and removing unnecessary technical noise Improving the organization of journeys, tests, and runs Adding a clearer side-by-side comparison of vulnerable and fixed executions Supporting delayed, dropped, and deliberately failed requests Making local setup and external-project onboarding easier Expanding deterministic diagnosis and recovery guidance The current version proves the core workflow while making the remaining product and usability problems much clearer.

FormCrash

FormCrash is a local-first, pre-production resilience-testing application for transactional browser journeys.

It records a successful browser journey, identifies the critical state-changing action, deliberately repeats that action under controlled timing, and evaluates approved Outcome Checks. Projects, Journeys, Tests, and Runs remain durable records instead of disappearing into a one-time automation wizard.

The bundled demo focuses on a common production bug:

What happens when an impatient user submits checkout twice?

FormCrash runs the same Test against a vulnerable checkout and a fixed checkout so the failure and the recovery are both visible.

Built with Codex and GPT-5.6

FormCrash was designed and implemented during OpenAI Build Week using Codex with GPT-5.6.

Codex and GPT-5.6 accelerated:

product scoping and architecture planning;
breaking the implementation into verifiable vertical slices;
building the dashboard, control server, browser runner, contracts, and persistence layers;
designing deterministic request-ranking and assertion-recommendation rules;
writing and reviewing automated tests;
debugging authentication, replay, navigation, selector, and network-evidence problems;
refactoring the product around Projects, Journeys, Tests, and Runs.

The main human decisions included narrowing the product thesis, defining the Critical Journey workflow, choosing deterministic recommendations instead of a runtime AI dependency, reviewing generated implementations, and deciding which sensitive evidence could safely be persisted.

FormCrash does not require an OpenAI API key or an AI model while running. Codex and GPT-5.6 were used to build the application rather than as a required service inside the finished product.

Why this exists

Many damaging bugs are caused by timing and repeated user actions rather than a complete application crash.

Examples include:

duplicate orders;
duplicate payments;
duplicate form submissions;
stale or conflicting UI state;
buttons that remain active while a request is processing;
backends that do not enforce idempotency.

These failures are difficult to reproduce consistently with manual testing.

FormCrash turns one of those failure modes into a repeatable Test with:

a controlled Chromium browser;
deterministic repeated-action injection;
explicit assertions;
persisted run history;
screenshots and ordered evidence;
plain-language results.

Bundled demo

The guaranteed demo path is included in the repository.

It contains:

a vulnerable checkout that creates two orders when submitted twice;
a fixed checkout with client locking and server idempotency;
one deterministic Impatient User Test;
one recovery assertion: no more than one order should be created;
three screenshots captured during each run;
persisted events, assertions, and observed request evidence.

Expected results

Mode	Expected result	Created orders
Vulnerable	Failed	2
Fixed	Passed	1

The failed assertion in vulnerable mode is an expected product result, not a server error.

Judge testing path

No external SaaS application, account, or test data is required to evaluate the core project.

After completing the Quick start, use the bundled checkout to run the same repeated-submit Test against both modes:

Run the Vulnerable checkout and confirm that two orders are created and the recovery assertion fails.
Run the Fixed checkout and confirm that one order is created and the recovery assertion passes.
Open either saved Run to inspect screenshots, ordered events, assertions, and observed request evidence.

The full click-by-click process is documented in the Bundled fallback walkthrough.

Demo video: https://www.youtube.com/watch?v=S9u86oqdPD4

Quick start

Prerequisites

Node.js 24.11.0
Corepack
pnpm 11.13.0
Chromium installed through Playwright

Supported platforms

The submission build was developed and verified on Windows with Node.js 24.11.0 and Playwright Chromium.

macOS and Linux have not been fully verified for this submission.

Install

corepack enable
corepack prepare pnpm@11.13.0 --activate
pnpm install
pnpm --filter @formcrash/server exec playwright install chromium

If pnpm is not available directly on Windows, run the same commands through Corepack:

corepack pnpm install
corepack pnpm --filter @formcrash/server exec playwright install chromium

Start the workspace

pnpm dev

This starts:

Application	URL
Dashboard	http://localhost:3000
Control server	http://localhost:4100
Sample checkout	http://localhost:4200

Application startup never downloads a browser. Chromium must be installed explicitly before the first run.

Hackathon walkthrough

Use a staging or otherwise controlled target that you are authorized to modify. Rehearse the full path before recording because journey replay and Test execution can create real target data.

Open Projects and select the controlled target.
Record the successful browser journey, then review and save its immutable version.
From the Saved Journey, choose Configure test suite.
Confirm the Critical Action that creates or updates the business record.
Replay the journey to capture the successful outcome.
When Chromium enters Outcome selection, use the exact generated name, email, phone, or identifier shown in both the dashboard and Chromium banner to locate the newly created record among older rows.
Click the matching row, confirmation, or other visible proof and approve the Outcome Check.
Review and save. FormCrash creates the Double-click, Triple-click, and Delayed repeat Tests without running them, then returns to their Saved Journey.
Run a Test directly from the Journey and open its latest Run details without detouring through the Runs directory.
Review the immutable configuration, approved browser and request evidence, verdict, timeline, and screenshots.

Generated literals are scoped to the active baseline capture. Reusable Outcome Checks persist templates such as {{unique.name}}, not a one-off tenant or customer value.

Bundled fallback walkthrough

Start the workspace with pnpm dev.
Open http://localhost:3000.
Select Vulnerable.
Choose Run Sample Experiment (the bundled legacy demo label).
Watch FormCrash open Chromium and replay the checkout.
Confirm the result shows:
- a failed recovery assertion;
- two created orders;
- the ordered run timeline;
- before, disruption, and settled-state screenshots.
Return to the dashboard.
Select Fixed.
Run the identical Test again.
Confirm the result passes with one created order.

Recent runs are persisted and can be reopened after refreshing the dashboard or restarting the server.

How it works

The sample Test follows this sequence:

Reset sample state
→ Open the checkout
→ Complete the recorded journey
→ Reach the critical submit action
→ Trigger the action twice, 100 ms apart
→ Observe requests and created orders
→ Evaluate the duplicate-protection assertion
→ Capture screenshots and persist the result

The server owns the browser, execution state, database, screenshots, and SSE event stream. The dashboard only calls the server APIs and renders the authoritative result.

Project structure

apps/
  dashboard/        Next.js control interface
  server/           Fastify server, Playwright runner, persistence, SSE
  sample-checkout/  Vulnerable and fixed checkout target

packages/
  contracts/        Shared Zod schemas and TypeScript contracts
  test-kit/         Test builders and fixtures
  config/           Shared TypeScript configuration

docs/
  product/          Product requirements
  architecture/     Runner, replay, recommendation, and evidence design
  implementation/   Roadmap and implementation boundaries

var/
  database/         Generated SQLite database
  screenshots/      Generated run screenshots
  auth/             Generated browser storage state
  exports/          Reserved generated exports

Generated runtime data under var/ is ignored by Git.

Testing an external application

The bundled checkout is the guaranteed deterministic path. The reusable external workflow is designed for authorized local, staging, and controlled pre-production targets.

The reusable external workflow is available at:

http://localhost:3000/projects

It supports:

creating a project for a controlled HTTP or HTTPS target;
recording a same-tab journey in visible Chromium;
reviewing and saving an immutable Journey version;
approving a recorded click or form submission as the Critical Action;
replaying the Journey once to approve browser-visible Outcome Checks, with exact synthetic identities displayed during selection;
explicitly approving sanitized request evidence captured during recording, or bounded evidence from an existing prior Run, without another discovery replay;
atomically saving Double-click, Triple-click, and Delayed repeat as three sibling Tests;
returning to the Saved Journey, where each Test can be run and its latest Run details opened directly;
reviewing immutable Test versions, canonical verdicts, events, evidence, warnings, and screenshots.

There is one supported Test editor. Optional Technical checks add bounded browser assertions for visibility, hidden or disabled state, text, retained fields, and final URLs. They supplement approved Outcome Checks rather than replacing them.

Supported recorded actions

top-frame navigation;
click;
text input;
checkbox and radio changes;
dropdown selection;
form submission.

Explicitly unsupported or limited

iframes;
CAPTCHA;
file uploads;
third-party payment pages;
drag and drop;
contenteditable editors;
new-tab workflows;
unsupported Shadow DOM targets.

Unsupported actions produce warnings rather than being silently recorded.

Authentication and runtime variables

FormCrash can capture and restore browser storage state for a controlled test application.

Runtime variables use this format:

FORMCRASH_VAR_<NAME>

Example:

FORMCRASH_VAR_API_TOKEN

Values may also be supplied ephemerally for a replay or Test run.

Secret values and values derived from them are resolved in memory and excluded from persisted snapshots, API responses, events, errors, and screenshot metadata. Sensitive browser fields are added to the screenshot mask list when their target locator remains available.

Safety boundaries

FormCrash is intended for local, staging, and controlled pre-production environments.

Production targets require explicit confirmation before replay, Outcome capture, or repeated-action execution. Prefer staging for demonstrations.

Before-run and cleanup hooks accept only bounded POST or DELETE requests. They should only be used against controlled test environments.

The runner executes one browser run at a time. A concurrent sample-run request receives HTTP 409 and is not queued.

Configuration

Variable	Default	Purpose
`DASHBOARD_PORT`	`3000`	Dashboard port
`SERVER_PORT`	`4100`	Control-server port
`SAMPLE_CHECKOUT_PORT`	`4200`	Sample-checkout port
`SERVER_HOST`	local default	Control-server bind address
`NEXT_PUBLIC_FORMCRASH_SERVER_URL`	`http://localhost:4100`	Browser-visible server URL
`FORMCRASH_DASHBOARD_ORIGINS`	`http://localhost:3000`	Allowed dashboard origins
`FORMCRASH_BROWSER_HEADLESS`	`false`	Run visible Chromium by default
`FORMCRASH_BROWSER_TIMEOUT_MS`	`10000`	Bounded browser timeout
`SAMPLE_CHECKOUT_BASE_URL`	`http://localhost:4200`	Bundled checkout target
`FORMCRASH_DATABASE_PATH`	`./var/database/formcrash.db`	SQLite database path
`FORMCRASH_ARTIFACT_ROOT`	`./var`	Generated artifact root

The root launcher reads environment variables but does not load .env files automatically.

Contributing

Contributions are welcome. Keep changes focused, preserve existing behavior outside the proposed scope, and represent incomplete or unsafe states honestly.

Before writing code

Fork and clone the repository, then create a focused branch such as feature/run-filtering or fix/outcome-selection.
Install the workspace and Chromium using the Quick start instructions.
Read docs/product/ui-direction.md and docs/product/active-bugs.md before changing the dashboard. Read the relevant product and architecture documents for the area being changed.
For a large feature, schema change, or new runner capability, open an issue first so the behavior and safety boundary can be agreed before implementation.

Engineering expectations

Preserve the persistent Project → Journey → Test → Run information architecture. Do not turn the application into a global wizard.
Keep real backend behavior connected. Do not hide active defects with placeholders, removed error states, relabeling, or weakened tests.
Treat browser execution and target data as potentially destructive. Use local or staging fixtures and never commit runtime data, credentials, authentication state, databases, or screenshots from real targets.
Update shared contracts before their server and dashboard consumers when a public shape changes.
Add focused regression coverage for every behavioral change. Browser-sensitive work should include visible-browser verification when the environment supports it.
Avoid unrelated cleanup or mass formatting in the same pull request.

Validate the change

Run the tests closest to the changed package while developing:

pnpm --filter @formcrash/contracts test
pnpm --filter @formcrash/dashboard test
pnpm --filter @formcrash/server test

Before opening a pull request, run pnpm verify. If a repository-wide check exposes an unrelated pre-existing failure, do not rewrite unrelated files; run focused checks for the touched files and document the exact baseline failure in the pull request.

A pull request should include:

the user problem and resulting behavior;
the intentionally changed files and any migration or compatibility impact;
tests and manual verification performed;
screenshots for meaningful dashboard changes;
remaining limitations, skipped verification, and data-safety considerations.

Verification

Run the complete non-destructive verification suite:

pnpm verify

Individual commands:

pnpm format:check
pnpm lint
pnpm typecheck
pnpm test
pnpm build

Persistence tests use temporary directories and do not write to the active var/ directory.

Resetting local state

To clear FormCrash run history:

stop the server;
remove generated database files under var/database/;
remove generated run directories under var/screenshots/;
keep the committed .gitkeep files;
restart the workspace.

To clear only the bundled checkout's in-memory orders and idempotency state, use its reset action or:

POST http://localhost:4200/api/test-support/reset

Current scope

Implemented:

vulnerable and fixed sample checkout;
deterministic duplicate-submit Test;
visible Playwright execution;
persisted runs, events, assertions, and screenshots;
replayable SSE progress;
external project creation;
immutable Journey recording and replay;
authentication capture;
runtime variables and secret redaction;
Critical Action and Outcome Check approval;
generated safe identities with exact active-capture guidance and template-only persistence;
recording-time and prior-Run request evidence with deterministic ranking and explicit approval;
one Test editor that atomically creates three reusable sibling Tests;
stable Test identities with immutable version and Run history;
Saved Journey Test actions for Run, latest Run details, record details, and editing;
canonical verdicts that distinguish failed, passed, could-not-verify, and runner-error outcomes;
network, UI, field-retention, and URL assertions;
persisted external-run evidence.

Not currently implemented:

complete generic before-and-after proof across arbitrary external targets;
PDF or HTML exports;
CI orchestration;
cloud execution;
additional failure injectors;
generic business-record count inference;
runtime OpenAI or other LLM features.

Documentation

Product requirements: docs/product/prd.md
Product UI direction: docs/product/ui-direction.md
Active bugs and verification gaps: docs/product/active-bugs.md
Multi-Test acceptance record: docs/product/multi-test-acceptance.md
Architecture and data flow: docs/architecture/data-flow.md
High-fidelity replay contract: docs/architecture/high-fidelity-replay.md
Request recommendation model: docs/architecture/request-recommendation.md
Assertion recommendation model: docs/architecture/assertion-recommendation.md

License

FormCrash is licensed under the MIT License. See /LICENSE.

Analysis

Compare with all teams

View

Metric

Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.

Technology

Found in codeClaimed only

CSSIn code
HTMLIn code
JavaScriptIn code
Next.jsIn code
ReactIn code
SQLIn code
TypeScriptIn code
Node.jsClaimed

7 of 8 appear in the indexed code. 1 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.

AI coding agents

CodexConfig

Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.

Codebase size

Source size

3.2 MB

Source files

299

Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.