01
A PASS is a result, not proof
An AI tool can run one command, see no obvious error, and report PASS. That may only prove that one narrow check completed. It does not prove that the whole app is safe, private, reliable, or ready for real users.
Treat a PASS as a question: what exactly was checked, with which inputs, and what evidence was produced? A trustworthy report names the command, files, test cases, environment, and limits of the check.
- A clean build proves the build completed; it does not prove the user flow works
- A passing unit test proves only the behavior covered by that test
- A code search can find references but cannot prove a dashboard setting
- A successful test account does not prove another user is isolated
- “No errors found” is not the same as “all risks checked”
02
Evidence and tests actually run
Ask the reviewer to separate verified facts from conclusions. Save the output with the date, branch, environment, and commit so you can tell what was reviewed.
- Exact commands or manual steps that ran
- The result of each test, including failures and warnings
- Files, routes, migrations, or logs used as evidence
- Test users and roles used for access checks
- The commit or deployment version that was checked
- Tests that were not run because of missing access, data, or configuration
03
Assumptions and unknowns
Unknown is a useful status. It tells you what to verify next instead of hiding a gap behind a confident label.
- Mark provider dashboard settings as unknown until someone checks them
- Do not infer production environment values from local files
- Do not infer database security from the UI or client code
- List missing credentials, test data, devices, and production logs
- Record what would change the conclusion if the assumption is wrong
04
Secrets, auth, and database access
- Check that service-role, payment, webhook, and private API secrets stay server-side
- Test login, logout, expired sessions, password reset, and account deletion paths
- Test anonymous, owner, and different-user access to sensitive records
- Confirm Supabase RLS and policies against the real schema and operations
- Review logs, screenshots, prompts, and Git history for exposed values
- Never paste secret values into an AI audit prompt
05
Payments, mobile behavior, and deployment
- Payment access changes only after trusted provider and server-side checks
- Duplicate, delayed, failed, cancelled, and refunded payment events are covered
- The main flow works on a real phone, not only in a desktop preview
- The deployed environment has the intended variables, domain, redirects, and functions
- A rollback path exists for code, database changes, and configuration
- A post-deploy smoke test checks the real URL and important error states
06
Copy-paste verification prompt
Prompt 51
Forbid unsupported PASS claims
Copy-paste prompt
Review this AI-built app without changing files or printing secret values. For each area—build, tests, assumptions, secrets, auth, database/RLS, payments, mobile behavior, and deployment—report: (1) the exact evidence inspected, (2) tests actually run and their results, (3) tests not run, (4) assumptions, (5) risks, and (6) the next manual check. Use READY, BLOCKED, UNKNOWN, or NOT APPLICABLE. Do not say PASS, secure, production-ready, or verified unless the relevant evidence and test are present. If you cannot prove something from this repository, say UNKNOWN.
Run this audit before asking an AI tool to implement fixes. Review the report and test the highest-risk findings yourself.