Make your coding agent prove its work
A behavior specification for your application, enforced on every change.
CReview summary
This pull request adds paid bookings through the mock payment app. Ripplo added three workflows for the new behavior and updated the event-type workflow for the new price field. Requiring payment on an event type and confirming a pending booking both pass. Ripplo found one regression, one visual finding, and one bug on a new workflow:
- Cancelling an unpaid booking regressed — clicking "Cancel event" fails with a server error (500) and the booking stays "accepted".
- Long attendee emails are clipped at the edge of the booking details card (predates this pull request).
- Paying from a booking's payment link never settles the payment — the booking page stays on "Your meeting is awaiting payment".
Issues
3View full detailsWhat broke: Hosts cannot cancel unpaid bookings. Clicking "Cancel event" fails with a server error (500) and the booking stays "accepted". Cancelling works on main.
Likely root cause: a backend bug in this pull request's cancel path. Cancelling now refunds the payment first, and that refund step in handleCancelBooking.ts assumes a payment exists — free bookings have none, which causes the crash.
- POST /api/cancel → 500: cannot read paymentOption of undefined
- Booking.status expected CANCELLED, still ACCEPTED
What broke: Hosts cannot read a long attendee email on the booking details card — anything past about 40 characters is cut off at the card's edge. This predates the pull request, it exists on main too.
Likely root cause: a UI bug in the booking details card. The email line in the "Who" section never wraps and the card hides anything past its edge, which clips the text.
Your meeting is awaiting payment
Complete your booking: aggredior between tenus and asporto on June 12, 2035
brendan_marquardt69+fu4vxy@yahoo.com
Need to make a change? Reschedule or Cancel
What broke: Paying from a booking's payment link charges the card, but the booking page stays on "Your meeting is awaiting payment" and the host never sees the booking confirmed.
Likely root cause: the payment link marks the charge captured but never writes the booking back to accepted, so the page keeps polling a booking that stays pending.
Payment
10:00am - 45 mins (UTC)
Create your own booking link with Cal.diy
Exhaustive coverage, not circular validation
Prove the entire workflow
Frontends lie. Ripplo checks your UI interactions against backend state mutations to make sure your application does what you think it does with no unintended side effects.
Agentic at definition time, deterministic at test time.
Your agent writes the workflow specification. Ripplo compiles each one into a covering set of deterministic tests — no waits, no retries, no flakes — that run on every change.
Fuzz tests catch the edge cases
Ripplo chains your workflows together in the background, running sequences no one wrote a test for, and surfaces the bugs that only appear several workflows deep — each with a replayable repro.
Prove the entire workflow
Frontends lie. Ripplo checks your UI interactions against backend state mutations to make sure your application does what you think it does with no unintended side effects.
Agentic at definition time, deterministic at test time.
Your agent writes the workflow specification. Ripplo compiles each one into a covering set of deterministic tests — no waits, no retries, no flakes — that run on every change.
Fuzz tests catch the edge cases
Ripplo chains your workflows together in the background, running sequences no one wrote a test for, and surfaces the bugs that only appear several workflows deep — each with a replayable repro.
What Ripplo does on every pull request
Visualizes the change
Ripplo renders the screens a user will land on and the records that change behind them, captured from the branch. A reviewer sees the effect before reading the diff.
Checks critical paths for regressions
Ripplo runs your workflows against the branch end to end, from the interface a user touches to the rows it writes. Each run seeds its own data and repeats identically, so a red check means the behavior changed.
Reports findings with evidence
When a workflow fails, Ripplo posts the failing step with the state going into it and what the application did. You can reproduce it locally from the report.
Auto-heals workflows
When your UI changes, Ripplo updates the affected workflows to match and includes the edits in its report. You review them alongside the code.
Evidence shipped with every PR
When you open a pull request, Ripplo attaches a verifiable run that proves the change works. Reviewers see evidence.
Add recurring availability so guests can book weekly slots #418
mainfromfeat/saved-carts- Hosts can set recurring availability so guests book a slot any week.
- Availability now persists across sessions, with a clear empty state.
- Existing booking flow updated to pick up recurring slots on return.
ripplo-devBotcommented3 days ago···This pull request adds recurring availability across the booking flow. Existing booking, availability, and reschedule journeys pass their covered paths, and Ripplo declared gaps where the required data cannot be created. Ripplo found no issues.
What broke: Hosts cannot cancel unpaid bookings. Clicking "Cancel event" fails with a server error (500) and the booking stays "accepted". Cancelling works on main.
Likely root cause: a backend bug in this pull request's cancel path. Cancelling now refunds the payment first, and that refund step in handleCancelBooking.ts assumes a payment exists — free bookings have none, which causes the crash.
Catches regressions, finds the cause
Ripplo catches broken behavior the moment it appears. Every failure comes with the replay evidence — the click, the request, the backend state — so you're never guessing at the cause.
Built to a legible specification
Ripplo catalogs your workflows and shows you the click-paths, playbacks, and backend mutations so you can understand how users interact with your application.
