Verify

Before a release reaches your users, Appbricx tests it the way a careful tester would: it signs in as each kind of user, tries what they should and shouldn't 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, and a deploy refuses to go out while anything is red.

When to use it

After every change. Agents run it after each apply and fix what it reports before calling the work done. deploy runs it again on its own.

The three stages

• Static: the contract is valid, every page is reachable from some role's navigation, and the generated code and your components type-check.
• Data: each demo sign-in works; every role is tried against every table for read, create, update and delete (writes rolled back) and compared with the contract; signed-out visitors can't read private tables; workflows are armed; a backup exists.
• Browser: headless Chromium signs in as each role and opens every page it can reach, checking for errors.

Run it

# from your agent: the verify tool
# from a terminal or CI (exit code 1 when red)
appbricx verify
appbricx deploy            # runs verify first and refuses on red

# over HTTP
curl -sS -X POST "https://appbricx.com/api/dev/v1/projects/$P/verify" \
  -H "Authorization: Bearer $TOKEN"

In the builder, Backend, Production check runs the same checks on development.

A real report

This is the report for the booking app from the tutorial, trimmed:

{
  "status": "pass",
  "stages": [
    { "stage": "static", "status": "pass", "checks": [
      { "id": "contract", "status": "pass", "evidence": "4 table(s), 2 role(s), 8 page(s), 4 workflow(s)" },
      { "id": "reachability", "status": "pass", "evidence": "every page is reachable by at least one role" },
      { "id": "typecheck", "status": "pass", "evidence": "tsc clean in 26s" } ] },
    { "stage": "data", "status": "pass", "checks": [
      { "id": "logins", "status": "pass", "evidence": "Sign-in works for 3 demo logins (instructor, member)" },
      { "id": "role-matrix", "status": "pass", "evidence": "Permissions match the plan for 2 roles × 4 tables (read, create, update, delete)" },
      { "id": "anonymous", "status": "pass", "evidence": "Signed-out visitors can't read the 2 private tables (member, booking); instructor, session are public by design" },
      { "id": "workflows", "status": "pass", "evidence": "4 workflows armed: …" },
      { "id": "backups", "status": "skipped", "evidence": "No database backups yet, one is taken automatically before every publish" } ] },
    { "stage": "browser", "status": "pass", "checks": [
      { "id": "walk:instructor", "status": "pass", "evidence": "signed in as instructor; opened 6 page(s) with no errors" },
      { "id": "walk:member", "status": "pass", "evidence": "signed in as member; opened 2 page(s) with no errors" },
      { "id": "nav-scope", "status": "pass", "evidence": "every role is offered only its own pages" } ] }
  ]
}

Reading a failure

• Every failing check names the role, table or page, with evidence and a fix.
• Fix the contract, apply, and verify again until status is pass.
• Look at the anonymous line on every app: it lists which tables signed-out visitors can read. If one should be private, set its access.

Gotchas

• Skipped is never pass. A skipped stage means the release is unverified. The backups check skips until the first publish, which takes one.
• Verify uses the demo sign-ins. Keep at least one seed row per persona so each role can be tested.
• skipVerify exists for emergencies. Deploying past a red report is your call, and the report still comes back.
• Pair it with screenshot: verify proves behaviour, screenshots show how it looks.

Related

• Access and roles
• Publishing, domains and rollback
• MCP tools reference