Product
From a repo and a URL to a record you can inspect.
KaleFlow does four things in order, then puts the result on one canvas. This page walks through each, with the artifact it leaves behind. Everything shown is a simulated run against a demo app.
Step 01 · Repo Brief
It reads the code and predicts where the value is.
Before KaleFlow opens your app, it reads your repository. The Repo Brief predicts the flows where your product creates value for a user: signing up, checking out, inviting a teammate.
Each predicted flow comes with where it was found in the code and how confident the brief is. A prediction is not a verdict. The crawl is what checks it against the running app.
- You give it
- A repository (
--repo .) - You get
- A list of predicted value flows
Repo Briefpredicted value flows · 4
| Flow | Found in | Confidence |
|---|---|---|
| Sign up | src/app/signup/page.tsx | 0.94 |
| Create a project | src/app/projects/new/page.tsx | 0.91 |
| Invite a teammate | src/app/settings/members/invite.tsx | 0.88 |
| Upgrade to a paid plan | src/app/billing/checkout/page.tsx | 0.86 |
Step 02 · Crawl
It explores the live app like a real user.
An AI crawler opens your live URL and works through each flow the way a person would: it reads the page, clicks, types and waits for the result.
What it finds, it compiles into repeatable automations, one replay per flow. This is the only step where AI does the driving.
- You give it
- A live URL (
--app) - You get
- One compiled replay per flow
- 14:02:07openhttps://app.example.com/signup
- 14:02:08fillEmail → a@example.com
- 14:02:08fillPassword → ••••••••••
- 14:02:09click“Create account”
- 14:02:11arrive/welcome
- 14:02:11compilereplay “Sign up” · 3 steps
frame 0100:03.87
Account created
frame 0200:06.92
Project in the list
frame 0300:08.90
AInvite sent
frame 0400:10.78
BInvite opened
frame 0500:14.23
ABoth users listed
frame 0600:17.39
Pay never enables
Fig. 3What the crawler saw, frame by frame, across four flows. Schematic captures from the simulated run.
Step 03 · Replay
The replay runs again, the same way, without AI.
A replay is deterministic. It runs the same steps in the same order every time, and it needs no model to do it.
That is what makes a failure mean something. When a replay that passed before fails now, the replay did not change. Your app did.
- You give it
- Nothing new
- You get
- The same flow, re-run on demand
| Step | Run 1compiled by the crawl | Run 2replayed, no AI | Run 3replayed, no AI |
|---|---|---|---|
| 01 Open /billing | Passed0.91s | Passed0.86s | Passed0.88s |
| 02 Choose the Team plan | Passed0.69s | Passed0.73s | Passed0.71s |
| 03 Enter a test card | Passed1.60s | Passed1.55s | Passed1.57s |
| 04 Click Pay | Passed0.84s | Passed0.88s | Failed1.04s |
| 05 See the receipt | Passed1.12s | Passed1.09s | Not run— |
| Verdict | Passed | Passed | Failed |
Fig. 4One replay, three runs. Run 3 is where the Pay button stopped enabling.
Step 04 · Evidence
Every step keeps what the browser saw.
Each replayed step saves a screenshot, video, a trace, a HAR file and the console output. Passing steps keep theirs too, so “it worked” is something you can look at.
When a step fails, start with the screenshot of the broken step. The requests and the console lines from that moment are next to it.
- Captured
- Screenshots, video, trace, HAR, console
- Kept for
- Every step, pass or fail
The screen at the moment the step failed. The Pay button is still disabled.
The whole flow as video, with a marker at each step. Jump straight to the failure.
- 00:00.00navigate/billing200 · 142 ms
- 00:00.88click“Team” planselected
- 00:01.59fillCard number4242 4242 4242 4242
- 00:03.16click“Pay”button is disabled
Each action the replay took, in order. POST /api/billing/intent returned 500 just before the click.
- 00:03.16log[checkout] plan=team interval=month
- 00:03.48warn[checkout] payment intent not ready, retrying (1/1)
- 00:03.71errorPOST /api/billing/intent 500 (Internal Server Error)
- 00:03.72errorTypeError: Cannot read properties of undefined (reading 'client_secret')
- 00:03.72error at confirmPayment (checkout.tsx:88:31)
HAR · step 04 · Click Pay0 — 720 ms
| Method | Request | Status | Time | Waterfall |
|---|---|---|---|---|
| GET | /billing/checkout | 200 | 142 ms | |
| GET | /api/billing/plans | 200 | 88 ms | |
| GET | /api/session | 200 | 54 ms | |
| POST | /api/billing/intent | 500 | 212 ms | |
| GET | /api/billing/intent/status | 404 | 61 ms |
The result · Canvas
Everything lands on one map.
The canvas shows how your flows relate and where each one succeeds or fails. Select a flow to open its steps and its evidence. Flows that need two users show both lanes and the hand-off between them.
Flow 04/billing/checkout
Upgrade to a paid plan
FailedThe Pay button never enables. The request that prepares the payment returns 500.
- 01Open /billingPassed0.88s
- 02Choose the Team planPassed0.71s
- 03Enter a test cardPassed1.57s
- 04Click PayFailed1.04s
- 05See the receiptNot run—
- screenshots
- video
- trace
- HAR
- console
Fig. 5The canvas for the simulated run. Drag to pan; select a flow to inspect it.
- 01 · user AOpen Members
- 02 · user ASend invite to user B
- Hand-off from user A to user B: invite link
- 03 · user BOpen the invite link
- 04 · user BAccept and join
- Hand-off from user B to user A: new member
- 05 · user ASee user B in Members
Fig. 6Flow 03 as a two-lane hand-off: user A invites, user B accepts.
Run it
Three commands, on your machine.
KaleFlow is local-first. Start from the CLI; use the hosted app when you want run history and sharing.
npx kaleflow init --app https://app.example.com --repo .Reads the repo and writes the Repo Brief.
npx kaleflow crawlExplores the live app and compiles replays.
✓Sign up3/3 steps3.87s
✓Create a project3/3 steps3.05s
✓Invite a teammate5/5 steps7.31s2 actors
✕Upgrade to a paid plan4/5 steps4.20sPay button disabled
evidence saved: screenshots, video, trace, HAR, console
npx kaleflow uiOpens the canvas in your browser.
Output shown is illustrative, from the simulated run above.