Verification and results

What you achieve

Before anyone approves a patch, FixControl tests it in a sandbox: an isolated, temporary environment holding the project's code with the patch applied. The result shows, step by step, what ran and what did not. That way a reviewer knows exactly what was proven — and what was not.

What a test checks

A sandbox run consists of fixed steps, derived from your repository:

Step	What happens	Counts towards the result
Install	Install dependencies, the way npm, Composer, pip or Maven do.	Yes: if installing fails, there is no result.
Static check	Type-checking or static analysis, for example `tsc`, mypy, PHPStan or Psalm.	Yes, where the project has such a check.
Lint and formatting	Style and formatting checks.	Usually as advice; they do not block.
Build	Build the project.	Yes, where the build is the verdict (for example Go, Java, .NET, Angular); for Node the build is often advisory.
Migrations	Apply database migrations.	Only when a database for verification runs is configured; otherwise this step is skipped.
Tests	The project's test suite, plus tests the patch brings with it.	Yes. Failures that already existed do not count against the patch; new failures do.
UI tests	Browser tests the patch brings with it (for example Playwright, Cypress or Odoo tours), in a browser without a screen.	Yes, when the patch brings them.
Start the application	Start the application and wait until it answers.	Yes, where the verified environment knows how the application starts.

Each step ends as passed, failed, skipped, timed out or error.

What a green result does and does not prove

A passing step proves that step only.

A passing build says nothing about the tests.
Passing tests say nothing about whether the application starts. That is why Did the application start? is a check of its own.
A successful start says nothing about how screens look. Only UI tests prove that, or a person looking at a preview.
A preview is human inspection, not an automated check. A verdict on a preview never replaces a test result.

When a step did not run, FixControl says so. A test that did not run is never green.

Reading the result

Open the run from Sandbox runs, or from the Sandbox validation check on the patch.

The tests

Heading	Meaning
Tests passed — regression-aware	The suite ran and the patch causes no new failures.
Tests failed — regression-aware	The patch causes new failures, or a test the patch should make pass is failing.
Tests never ran — no verdict	An earlier step stopped the run. Empty counters mean "not measured" here, not "clean".
Tests ran nothing — no verdict	The test step completed without error but executed nothing. That is not evidence.
UI tests could not run in this test environment	The environment has no browser for the patch's UI tests.
The patch's UI tests did not run	The UI test step selected nothing.

Did the application start?

Status	Meaning
Started and answered	The application came up and answered, with this change in it.
Did not start	FixControl could not start the application with this change. Treat the run as red, even if the tests passed.
Not started	Nobody checked whether the application still starts.
Not verified here	The environment declares nothing to start. The tests then say nothing about whether the application runs.

On the patch you see the checks Sandbox validation and Application start, each with the status passed, needs attention, waived, failed or in progress. Waived is not passed: nobody proved it, and someone accepted that by name and date. See Delivering changes for what this means for delivery.

Starting a test

Who: anyone with the organization role admin, manager or operator can start a test and read results. Only admins and managers can change a verdict.

On the issue page: Test in sandbox, when there is a patch that has not been tested yet.
On the patch page: Verify in the sandbox.
In a work session: Run verification.

After an AI agent has created a patch, FixControl usually starts the test itself.

When prerequisites are missing

FixControl first has to know how your application is built and started. It derives that from your repository, and where that is not enough, the AI proposes an environment that the sandbox then has to prove for real. Only a passing run produces a verified environment. This is on by default; see Change validation for the details.

If that does not succeed within the fixed number of attempts, FixControl stops with one concrete question under What FixControl needs to know — for example which runtime version, system package or start command is needed. Answer it and choose Answer and retry. If an answer cannot help, it says An answer cannot move this with the reason.

What you know yourself about starting your application goes under Environments → Environment settings in the project. Those settings are checked by the same rules as the AI's proposals and still have to be proven by a run.

Three kinds of failure are treated separately:

The tests failed — a verdict about your code. This can lead to a new, AI-prepared version of the patch.
The environment failed — an image that would not load, a dependency that would not install, a service that never came up. This never leads to a proposed change to your code.
The application did not start — the tests passed, the start did not. The patch is then not delivered.

Where the test runs

In FixControl's own isolated environment — the default. Every run gets its own temporary container, cleaned up afterwards.
In your own environment — where configured, through a runner you install yourself with the FC Agent. This is a pilot and off by default. A runner in your own environment cannot prove that the application starts; see Change validation.

What cannot be tested (yet)

.NET Framework (net48) and WinDev are recognized, but FixControl does not run them today. A run then stops with a message naming exactly what is missing, instead of a green result that proves nothing. A Windows environment for .NET Framework has been built, but it is not switched on and not yet proven. WinDev needs a licensed PC SOFT installation, which FixControl does not provide.
A codebase with no test runner, type-checker or build configuration produces the message No verification steps could be derived, not a green run.

Looking at a preview

A preview starts the application with the patch in it, so you can look at it yourself. Previews are on by default; an admin or manager can switch them off for the workspace under Settings → Overview & progress → Settings for this workspace.

What you need first: a passing run with a patch, a verified environment, and an environment that knows how the application starts.

Open the patch and choose Start a preview. Starting takes a few minutes; you get a notification once the preview is ready or did not start.
Choose Open preview. You must be signed in and have read access to the project. A preview is not a shareable link.
After looking, record a verdict: This looks right or This does not look right.

A preview stops by itself: after 30 minutes without use or after 4 hours, and at most three run at the same time per workspace. Starting, stopping and recording a verdict need management rights on the project. A project that requires validation in your own environment gets no preview.

Your verdict is recorded next to the automated validation, with your name and the time. It never replaces a test result and never opens an approval gate by itself.

Letting failures be investigated in the test environment

Where you switch this on, the developer agent may run a limited number of commands after a failed run, inside the container the run failed in, to see what went wrong. It cannot change anything there; the container is removed afterwards. This is off by default. An admin or manager switches it on from the failed run with Switch this on, or under Settings → Overview & progress (Investigate failures inside the test environment).