App persistence (create → read → assert token)

Body template: {"probe":"{{token}}","title":"flows-probe-{{token}}"}. Needs CORS-readable public create/list endpoints (or inconclusive). Badge only when create→read→refresh finds the token (detects false success).

Two-account authorization (User B cannot see/change User A)

Authorization evidence source: Cross-account ownership test (trust level 5/6). These are not equivalent. Unauthenticated probe alone is weaker (source: unauthenticated API probe). Tokens stay in this browser session only — not uploaded to Flows servers.

Generated edge-case tests (review / approve)

• api_probe Submitting the form empty is rejected with a clear error
• api_probe Each required field can be omitted and fails validation
• api_probe Malformed email is rejected
• api_probe Malformed phone is rejected when phone is collected
• api_probe Duplicate submission does not create two records
• api_probe Double-click submit creates only one record
• false_success_probe Failed request does not show success
• browser_automation Refresh during submission does not leave corrupt state
• api_probe Oversized input is rejected
• api_probe Unsafe strings do not execute or break storage
• api_probe Logged-out users cannot open protected pages
• api_probe Protected API rejects requests without credentials
• api_probe Expired session cannot mutate data
• browser_automation Logout in one tab invalidates mutations from another
• cross_account_probe User B cannot see or change User A’s data
• cross_account_probe Participant cannot call coach/admin endpoints

Generated from this route’s signals — you approve; you do not invent security tests.

Content probe (GET body contains text)

In-product content probe reads response text when CORS allows — not full DOM/click automation. Playwright script is optional and external.