What Flows just did
Based on your request to build Fix Broken Buttons, Flows created 5 implementation stages and 15 checks.
You asked for: Find every non-working button and make each perform its intended action with loading and error states.. Flows generated 5 stages because the application requires A complete inventory of every interactive control; Each button wired to a real handler and backend action where relevant; Loading and error feedback on async buttons. Each stage tells your AI builder what to do, tests whether it actually worked, and gives a repair instruction when it fails. These checks are designed to catch: Buttons with no onClick handler at all; Handlers that only console.log; Success toasts with no underlying action.
Example failure
The form reported success, but no database record was created.
What Flows does
Flows detects the failure, generates a repair instruction, reruns the test, and stores the passing evidence.
Stages — Plan → Build → Test → Fix → Prove → Ship
5 stages · 15 checks · progressive disclosure — open a stage for details
Copy to external builder
Copies a prompt for Claude/Cursor/etc. Records prompt_copied only — not execution, commits, or checks.
Execute through Oort
Requires Sign in with Oort + a provider connection (BYOK). Keys stay on Oort. A model name in the dropdown is not the same as a live connection.
Next
Check off: Every page and modal was inspected
Add a proof note on each check — a checkbox alone is weak proof.
Probes & advanced tools are under “More verification tools”. Experience level: Settings.
Project (saved with proof)
Project binding: Unbound — complete project binding before trusting this run · missing repositoryUrl, repositoryStartCommit, environment, stack
More verification tools (probes, timeline, adapters)Show
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 Logged-out users cannot open protected pages
- api_probe Protected API rejects requests without credentials
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.
Proof strength
thin · 0/100
Heuristic from notes + probes + gates — not a production certification.
Verification adapters
- ● Deploy URL probe · idle
- ● API path probe · idle
- ● Authz probe (unauth → 401/403) · idle
- ● Browser persistence · idle
- ● App persistence (create→read) · idle
- ● Content / body text probe · idle
- ○ In-product Playwright DOM · not embedded (download external script)
Filled circles = available here. Empty = not shipped. Probes are not a production audit. Adapter docs
Step 1 of 5
Not startedInventory every interactive control
You cannot fix what you have not listed - audit first.
Flows keeps plan, checks, failures, and next steps connected
Your AI tool writes or changes the code
Repository grounds the plan only after inspect
Checks always carry a validation tier
How this plan was created
Plan from project details
Flows creates steps using the goal, requirements, stack, platform, and details you provide.
- Project description
- Selected template / route
- User-entered stack
- Constraints and notes
- Fix Broken Buttons
No repository inspection implied. Connect and inspect a codebase to ground steps in real files.
Codebase access
Checking GitHub…
Or paste a repository URL manually
Use these instructions in Claude, ChatGPT, Cursor, Emergent, or another builder.
Audit this entire app and produce a table of EVERY button, link, icon-button, and menu item: its label/location, what it is supposed to do, and its current status (WORKS / DEAD / FAKE - fake meaning it shows feedback without doing the real action). Actually inspect the handlers; do not guess. Include modals, dropdown items, and mobile-only controls.
Project context
Copies the project goal, technical details, current step, previous progress, and checks so your AI tool understands what it is working on.
Expected after this step
A complete control inventory with WORKS/DEAD/FAKE status per item.
Should not happen
- ✕Buttons with no onClick handler at all
- ✕Handlers that only console.log
- ✕Success toasts with no underlying action
- ✕Buttons that work once then break due to state bugs
Verify gate — prove this step works before continuing
Do not move on until every check is true. Add proof notes — a checked box alone is weak proof. Checks are manual by default; deploy/API probes live under “More verification tools” and do not auto-check boxes.
Do not continue if…
- !Buttons with no onClick handler at all
- !Handlers that only console.log
- !Success toasts with no underlying action
- !Buttons that work once then break due to state bugs
Repair path — if this step fails
Use the Repair Prompt when a verify gate fails. Loop: Detected → Diagnosed → Repair issued → Changed → Retested → Resolved
Show repair prompt textShow
The inventory missed controls or guessed statuses. Re-scan every route and component file for clickable elements and verify each handler's real behavior.
Your notes for this step
Definition of Done
Final route-level requirements. Manual checks — separate from per-step verify gates. Completing step gates does not auto-check these. Route completion is not a production-ready claim.