How every release is checked

Before a release reaches your users, Appbricx checks it the way a careful tester would: it signs in as each kind of user, tries what they should and should not be able to do, and opens every page in a real browser. You get a report with what passed, what failed and how to fix it, so you ship with evidence instead of hope.

Why it matters

Coding agents move fast.Verify catches the change that quietly broke a page or let one role read another's data.
Proof for your clients. The report and screenshots show that each role sees the right pages and only its own data.
Deploys are gated. A deploy refuses to go out when verify is red, unless you explicitly skip it.

The three stages

1. Static

The contract is valid and consistent.
Every page can be reached from the navigation of some role.
The generated code and your components typecheck.

2. Data

Signs in as each demo role.
Builds the permission matrix: every role against every table, for read, create, edit and delete, compared with what the contract says.
Checks that an anonymous visitor cannot read private tables.
Checks that workflows are armed (their triggers are in place).
Checks that a backup exists.

3. Browser

Headless Chromium signs in as each role.
It opens every page that role can reach.
It takes a screenshot of each one, so you can see the result.

Skipped is never pass. If a stage cannot run (for example, no browser is available), the report says it was skipped. It is not counted as a pass, and you should treat the release as unverified until it runs.

Run it

From your coding agent

Call the verify tool on the MCP server. Agents run it after each change and fix what it reports before calling the work done.

From your terminal or CI

appbricx verify          # prints the report, non-zero exit when red
appbricx deploy          # runs verify first and refuses on red

See the CLI for exit codes you can use in a pipeline.

Over HTTP

curl -sS -X POST "$API/projects/$P/verify" -H "Authorization: Bearer $TOKEN"

See the dev HTTP API.

Reading the report

Each check shows pass, fail or skipped, with the role, table or page it concerns.
A failed permission check names the role, the table and the action.
Screenshots from the browser stage are attached so you can look before you ship.