The step, not the run
A failure names the step it died on and quotes what it was looking for, instead of handing you a stack trace and a screenshot.
Your assistant says done. It never opened the app.
One flow, recorded once, in the browser you already have open.
It opens your app in a browser window - local, or a deployed address like a Lovable URL. Click through one flow and close it. It writes a real Playwright spec you can open and read.
Let the assistant work. A refactor, a new feature, a fix - whatever you were going to do anyway.
It replays the flow in a real browser against your app and says in plain English what broke.
When the change was the point, take the new state as the baseline and carry on from there.
A page that loads is not a page that works
No stack trace and no screenshot to squint at. Three facts, in the order you would ask for them.
A failure names the step it died on and quotes what it was looking for, instead of handing you a stack trace and a screenshot.
Every pass is written to a history file, so a failure can say the flow was fine eight minutes ago - which tells you it was the last change, not the one before.
Console errors and failed requests are compared against the last good run, so you are shown what is new rather than everything the page prints.
Everything it makes is a readable file in your project. Delete any of them and it starts again from what is left.
The recording, as a plain Playwright spec
One line per run, so a failure knows when it last passed
The URL and title a passing flow landed on
The rule that makes an assistant check before it says done
It copies the shape of your Supabase or Postgres database - tables, columns, the rules about who may see what - never a row. It attacks the copy with four questions, tells you in plain English what got through, and deletes it.
Every report ends with what was not tested, and why. Finding nothing is never called safe - it is called these attacks, this time, lost.
npx kryptheon-night
Add the MCP server and your assistant gets all of it as tools: record a flow with you, check it after every change, scan the database. It is told not to call a change done until the check passes.
Once, before anything else: install Node.js, the LTS version. Then pick the tool you use.
{
"mcpServers": {
"kryptheon": {
"command": "npx",
"args": [
"-y",
"kryptheon-mcp"
]
}
}
}Replace the command line with these two:
"command": "cmd", "args": ["/c", "npx", "-y", "kryptheon-mcp"]
Add your Supabase connection string next to "args". Never paste it into the chat - that puts the password to your whole database in a transcript.
"env": { "KN_DATABASE_URL": "postgresql://..." }“Check my app.”
Or: “record my app at https://my-app.lovable.app”. Lovable, Bolt, v0, ChatGPT and Claude.ai in the browser only accept hosted servers, so Kryptheon cannot be added to them yet.
There is no paid tier and no plan to compare against. This is the entire list.
It is Playwright underneath, and the file it writes is an ordinary spec you can open and edit. What it adds is the recording, the baseline it keeps after a pass, and a failure report written in plain English instead of a stack trace.
No. It records in a browser on your computer, replays against your local app, and writes its history to a file in your project. There is no account, no API key and no server to talk to.
A value typed into a password field is never written into the spec. It is replaced with an environment variable reference and the run tells you which variable to set in your .env file, which stays out of git.
That is enough. Open a terminal and run npx kryptheon@latest record with your app's address. It sets up a folder for the recordings itself - from your home folder it makes one called kryptheon-tests - and tells you where it is. After each change, run npx kryptheon check from that folder.
That is the point. Add the MCP server and your assistant gets the tools directly: it records with you, checks after every change, and is told not to call a change done until the check passes. Without MCP, npx kryptheon setup-ai writes the same rule into CLAUDE.md, AGENTS.md and .cursorrules, and npx kryptheon check --quiet keeps the output short.
No. It reads the shape of your database - table names, columns and the rules about who may see what - rebuilds that shape in a throwaway schema, attacks the copy, and deletes it afterwards - also when the scan fails partway. None of your rows is read, changed or copied.
Postgres, including any Supabase project you own. It needs the connection string, which Supabase shows under Project Settings, Database. An app on Lovable Cloud - Lovable's built-in backend - does not hand one out, so the scan cannot reach it yet.
It will never say so. Nothing found means these attacks, this time, lost. Every report ends with what was not tested and why, because an attack that never ran looks exactly like one that was refused.
It says so and exits zero. A fresh project with no recordings is not a failure, and reporting it as one only sends an assistant off trying to fix something that is not broken.