Free, no-signup field guide

The regression checklist for AI-written pull requests.

Use this after a coding agent says it is done. The goal is not more test output. The goal is evidence that the changed user behavior still works from a clean start.

Run the checklist

Governing primitive

Identify the one real user outcome that must still work before testing anything downstream.

Pass condition

Require observable behavior, state, logs, and recovery evidence instead of a green command alone.

Restart rule

If a bug is fixed after the final run, discard that run and start the complete proof again.

Gate 1

Scope the real change

Make the intended outcome and blast radius explicit before trusting generated tests.

Write the required user outcome in one plain sentence.
List the exact files, services, data, integrations, and user groups the change can affect.
Record the current behavior before changing it, including the failure you intend to fix.
Name forbidden surfaces such as credentials, billing, production data, migrations, and deployment controls.

Gate 2

Reproduce before repairing

A fix is unproven when the original failure was never observed under controlled conditions.

Reproduce the failure from disposable, known state before editing code.
Capture the browser or API behavior, relevant state, and the exact error logs.
Find the governing cause instead of patching the visible symptom.
Confirm the reproduction does not touch unrelated processes, ports, users, or production records.

Gate 3

Attack the seams agents miss

Locally plausible code often fails where state, permissions, retries, and systems meet.

Test unauthenticated access, wrong ownership, expired state, and insufficient permission.
Test empty, malformed, oversized, duplicate, and boundary inputs.
Test concurrent requests, retries, double clicks, and interrupted work.
Test downstream timeout, unavailable dependency, partial response, and recovery.
Test the real browser flow on desktop and mobile, including loading and error states.

Gate 4

Protect state and recovery

The change is not safe when the only path out of failure is manual improvisation.

Prove database migrations and destructive operations against an isolated copy first.
Verify secrets, personal data, and internal errors never enter pages, logs, or artifacts.
Make repeated external side effects safe or explicitly reject duplicates.
Identify the exact rollback target and test that recovery restores working behavior.

Gate 5

Run the final proof from zero

The final result must stand on one clean run, not a sequence of manual rescues.

Start with fresh browser, process, and test state appropriate to the real user journey.
Satisfy every user-specific requirement in that same run without approval overrides or hidden workarounds.
Read happy-path and error logs, then verify the expected data and side-effect counts.
If any bug is fixed after this run, discard its result and rerun from the beginning.
Preserve the exact inputs, versions, screenshots, logs, and result needed to repeat the proof.

Stop the merge when

The expected behavior cannot be reproduced before the fix.
The change touches authorization without a negative ownership test.
A migration or destructive action has no isolated restore proof.
The only evidence is a unit test while the real user path remains untested.
The final run needs a timeout extension, manual resume, approval override, or unexplained workaround.

Outcome:
Real user path:
Baseline and reproduced failure:
Risk surfaces:
Negative and concurrency cases:
Fresh end-to-end run:
Logs and state checked:
Rollback proof:
Known gap:

Did an AI-written change still escape this gate?

Failsafe is a proposed pull-request gate that would run this proof against the real app. It is not built. Ten developers who want this gate decide whether it should be, and the founding ten get the first year free.

Join the founding ten