Skip to main content
Writing the change is only part of finishing it. Validation is the work an agent does afterward to show that the result builds, passes the right tests, and behaves as expected. FlowDeck always requires the smallest relevant tests and any checks the repository explicitly defines as gates. The Validation settings control the extra runtime checks and evidence an agent gathers after those required checks, so you can choose between a faster handoff and a more comprehensive review.

Why FlowDeck validates more

FlowDeck is built to let agents do more than edit files. An agent can use the project’s saved target to build and test, run the real app, exercise changed flows, inspect logs, and capture evidence from simulators and devices. That makes it possible to catch problems a code diff or clean build cannot reveal, such as clipped text, a broken interaction, or state that fails only after the app is launched. Balanced is the default: tests, build/launch, then one check of the changed flow and its visible result. It checks both light and dark only for appearance-dependent styling changes; otherwise it uses the current appearance. It checks changed loading/empty/error/permission states, but does not add rotation, resizing, adjacent flows, or extra devices.

Choose a starting point

The preset at the top of Settings ▸ AI Workflows ▸ Validation sets every option below it. You can then change any option independently. When you do, the preset reads Custom. Choosing a named preset again resets all five options to that preset.

Lean

Runs relevant tests, confirms compilation and successful launch, then stops. Uses the saved target, no screenshots or recordings, and a brief report.

Balanced

Adds one check of the changed flow and visible UI. Captures useful visual evidence. No video, rotation, or extra devices. This is the default.

Thorough

Adds relevant edge cases, supported orientations/window sizes, and one additional target with a meaningful compatibility difference. Captures evidence during those checks and reports a compact results matrix.

Customize each method

Run the app

Controls how much runtime behavior the agent exercises after the required checks pass. The other controls independently select artifacts, targets, and reporting; preset names add no extra instructions. For documentation-only work, validate the documents. For libraries/CLIs, use their test or executable entry point rather than launching an unrelated app.

Screenshots

Controls still-image evidence. It does not decide whether the agent runs tests or checks the app.

Screen recordings

Controls video evidence for behavior that a still image cannot explain well.

Additional devices

Controls whether the agent repeats relevant runtime checks beyond the saved target.

Final report

Controls how much validation detail appears in the agent’s final response. It changes the report, not the checks that are required.

What never changes

Validation preferences never let an agent skip required tests, repository gates, safety rules, permission requirements, or honest reporting. An agent must not claim a check or artifact it did not produce. A setting can reduce extra runtime work or evidence, but it cannot turn a failed check into completed work. Test-driven development controls whether a test is written and run before implementation; it does not turn that focused red-green cycle into a full test suite, UI sweep, or device matrix. Validation stops when the selected checks pass and the changed behavior is proven. If a check fails, the agent investigates that failure and repeats the smallest affected scope. A failure is not permission to start a general compatibility sweep. Changes take effect when a session is next configured or restored, and for Team workers hired after the change. They do not rewrite the instructions of an agent that is already running.