Docs

Dev mode: code review and a safety floor for your repo

Dev mode points a space at the GitHub repo its team works on. kwant reads the repo and writes a card for every merge and every open pull request, in plain words. A bot that didn't write the code reviews it. In the same space, anything that can reach production asks you first. kwant writes to GitHub only when you press Post to GitHub on a review.

The Trailhead Outfitters space right after one press on the Dev mode switch. A note in the corner says Dev mode on, watching demo-org/demo-app on main, with Open Dev desk and Undo. — One press turns it on. A note says which repo kwant found, with Undo.

Turn it on

The Dev mode switch is at the top of the sidebar, under the space's name. One press turns it on, with no setup to fill in. kwant looks at the space's teams for the repo: each team's repo link, or its folder when that folder is a git checkout. It reads this on your machine, with no network. A sign-in token inside a remote address is dropped and never logged or stored.

A short note says what it found, such as the repo and branch, with Open Dev desk and Undo. When it found several repos, no repo, or no GitHub connection that can read it, the note adds one button for that.
Switch lists the repos it found in the space, with Type a repo last.
Connect GitHub shows when no GitHub connection can read the repo. It takes you to Connections once, and Dev mode picks the repo up as soon as the connection is saved, without turning it off and on.
Turning on never fails. With no repo, the production floor and the command guards still work, and the desk waits for one.

Dev mode reads GitHub. A GitLab or Gitea repo is named in the note, but kwant doesn't read it yet.

On, the repo found, and the last five merges written up.

Before you turn it on

Dev mode reads GitHub through the GitHub connection in Loose ends, so it needs a GitHub token. Reading works with a read-only token; posting a review needs Pull requests: Read and write on a fine-grained token.

Where the token is kept. kwant's built-in password store only saves a GitHub token while every space and every bot is on Ask before running commands (new installs start on Ask only when risky). Switch them to Ask, or connect Bitwarden. While the token is in the built-in store, approvals can't go back to Off or Ask only when risky. See Approvals & passwords.

What landed

The Dev desk sits at the top of the sidebar. Its first tab, What landed, has one card per commit that reaches the watched branch: what changed in plain words, how risky it is, the commit, the pull request it came from (or "Direct push"), a diffstat for each file, and whether tests passed.

Since you last looked rolls up what's new, and Mark all seen clears it.
Draft release notes writes notes from every landed card since the last tag.
Verified goes on a merge only when another bot reviewed that exact head in kwant, every finding was fixed or dismissed, and CI on the merge is green. A pull request merged before its review was ready stays "not verified": the sticker says what was checked before the change landed, not after.

kwant checks the repo every 5 minutes. The first check writes up the last 5 merges. Card text is written by one of the space's bots, at most 30 model calls per space per day; the risk, the test checks and CI come from rules and need no model.

Reviews

The Reviews tab has one card per open pull request, written by a bot that didn't write the code, on a different engine when the space has one. A new push to the pull request gets a new review.

Review card #24, Speed up cart totals, from a feature branch into main: a Medium risk badge because a test was loosened, two tests flagged as made easier to pass, a light for each security check, and two findings, each with Fix it and Dismiss. The footer has Post to GitHub, and nothing is posted until you press it. — A second bot's review. Nothing goes to GitHub until you press it.

Risk with its reasons, from rules, not from the bot's opinion.
Does it do what was asked: what the task asked for, what's missing, and what wasn't asked for.
Tests weakened: a removed or loosened test is flagged with the lines.
Secrets and packages: Gitleaks runs over the pull request, and every new package is checked against its registry. A found secret or a package that doesn't exist always makes the card High risk. The secret itself is never shown.
Findings: Fix it sends a finding to the bot that wrote the pull request, and Dismiss sets it aside.

When the reviewer found nothing to fix, the card gets an LGTM stamp.

A review card with no findings: the two security checks that run, Secrets and New packages, are green, two more are marked for later, and an LGTM stamp sits in its top right corner: Looks good to me, the reviewer found nothing to fix. — Nothing to fix: the card says so with a stamp.

Post to GitHub

Post to GitHub puts a review card on its pull request as one GitHub review comment, posted as you and pinned to the commit that was reviewed. Findings you didn't dismiss go on their lines when the lines are in the diff; the rest go in the review's text.

The findings on review card #24 after posting, ending in a green line: Posted 13:42 as @demo-bot, 2 inline comments, with View on GitHub. — Posted once, as you, with a link to the review.

Only your press posts. kwant never approves, requests changes or merges, and a bot can't post.
Secrets are never posted. A found secret is posted only as "Possible secret in" its file and line, and keys and tokens in a finding are replaced with [redacted].
Once only. A double click makes one review, and a posted card stays posted.
New commits? If the pull request moved on since the review, nothing is posted, and a new review is on its way.
Read-only token? The card says your GitHub connection is read only, and nothing is posted.

The production floor

In a space with Dev mode on, these steps always show an approval card first, whatever the space's or the bot's approvals say, and even after "always allow":

Step	For example	Needs a backup
Push to the watched or a protected branch	`git push` to main, master, production and the like, or `gh pr merge`	No
Force push	`git push --force` to a protected branch	No
Delete a branch or tag	Deleting a protected branch or a release tag	No
Deploy	wrangler, fly, vercel `--prod`, kubectl, terraform apply, a script named deploy, ship or release	No
Migrate production	A migration that names a production database or environment	Yes
Destroy data	`DROP`, `TRUNCATE`, a `DELETE` with no `WHERE`, `docker volume rm`	Yes
Use a production connection	Any tool on a connection you marked production	No

A production floor card: Ben wants to run deploy.sh, a deploy script. It says the deploy changes the database, so it needs a backup from the last 10 minutes first, shows the blast radius and No backup yet, and offers only Back up first and Deny. — The card says what the step does and where it lands, in one sentence.

No "always allow". Allowing a floor card covers that one call, and the next one asks again.
Back up first. A step that can change production data can't be allowed until the space has a backup from the last 10 minutes. The card's Back up first runs the space's backup command, and kwant checks that it wrote a new backup file.
Mark a connection production in Connections to make every one of its tools ask, such as a GitHub app that could write to main directly.

The floor reads commands and tool calls, never what a bot says about them. It can't see inside a script with a harmless name, a command built from variables, or a deploy done through a provider's API from code. When a connection can reach production, mark it production.

Bots can't act on a pull request's text

Anyone who can open a pull request writes its title, text and diff. So the bot that writes a Dev mode card runs with no tools at all, on every engine: no MCP servers, no browser, no shell, files or web search. A turn that can't run that way fails instead of running with tools, and the card keeps its rule-based parts.

Turn it off

Turning Dev mode off takes two presses. The first lifts the switch's cover and the second, within 5 seconds, turns it off. Escape, clicking elsewhere or waiting keeps it on. The off note has Turn back on.

The Dev mode switch at the top of the sidebar after one press: outlined in amber, it reads off?, and a hint below says Press again to turn Dev mode off, with Esc to keep it on. — The first press only lifts the cover.

Off stops the checks, the reviews and the production floor. The cards stay readable, and your approval settings stay as they were.

On your phone

The Dev desk works on a phone too. Its row in the sidebar counts the reviews that are ready since you last opened the desk, and the count is the same on the phone and the desktop.

The Dev desk on a phone: the status line says it is watching demo-org/demo-app on main, above a landed card with its commit, pull request and tests line. — The desk on a phone.

Only you can see it. Bots can't read the Dev desk, its settings or its cards, because the settings hold the backup command and the cards hold the repo's diffs. None of it is in a space or bot export.