Reviewing changes

Qyant works one of two ways, and you chose which when you signed up.

• Changes apply automatically. Qyant edits the project and the preview updates. Nothing to approve — you look at the result and keep going. If a change was wrong, pick an earlier version from the version menu. This is the default if you told us you don't write code.
• You review every change. Qyant proposes edits and waits. You read the diff and accept or reject it, file by file if you like. This is the default if you told us you write code professionally.

Either way nothing is lost: every change creates a version, and versions are permanent.

Switching between them

Settings → Reviewing changes → "Review each change before it applies."

One switch, available to everyone, changeable at any time. Turn it on if you want to read diffs; turn it off if approving changes is slowing you down. It takes effect on your next prompt.

When changes apply automatically

The edits are written as soon as the model finishes, the preview reloads, and the version number goes up. You'll see the preview update in place — a skeleton while it reloads, never a blank screen.

If something comes out wrong, open the version menu above the preview — the button showing your current version, like v13. It lists every version with its date and what changed; pick one and your files return to how they were then.

Switching versions moves which one you are on — it does not add another. Every version stays in the list, including the ones after the one you picked, so you can switch forward again just as easily.

Occasionally a change can't be applied automatically — a conflict, or the sandbox being mid-restart. When that happens Qyant shows a single Apply changes button instead of failing silently. Your work is saved either way.

The review panel

When a response finishes, its file changes appear as a list: created files, updated files and deletions, each with a coloured marker in the file tree. Click any file to see the diff — added lines, removed lines, with the surrounding context.

You have three choices per change set:

• Accept all — every file is written, the project's version increments, the sandbox receives the files and the preview reloads.
• Reject — the whole proposal is discarded. The chat keeps the model's message so you can refer to it in your next prompt.
• Per-file — accept some files and reject others from the diff view. Accepted files become one version; rejected ones are dropped.

Until you choose, the proposal stays pending and the preview keeps running the last accepted version.

This panel only appears when "Review each change" is on. With it off, these edits would already be live.

Versions

Every accepted change set — and every manual save in the editor — creates a new version: a full, immutable snapshot of the project's files. The version number is shown in the project header (v13) and in each review card (v12 → v13).

Rolling back

Open the version menu above the preview and pick any version. Your files become exactly what they were then, and the project is now on that version — nothing new is created. Every other version stays in the list, so switching back and forward costs nothing. The sandbox is synced and the preview reloads immediately.

Reviewing well

These apply when review is switched on.

• Read the deletions first. Removed lines are where surprises hide.
• Check lib/db.ts and schema changes carefully. Database changes are the hardest to undo once real data is in.
• Reject early. If the direction is wrong, reject and re-prompt; don't accept and then ask for a fix on top.
• Trust but verify the preview. Accepting reloads the preview in a few seconds — click through the feature before the next prompt.

What happens to .env

The model can read the variable names in your .env but never the values of managed secrets (DATABASE_URL is shown to it as <managed-by-qyant>). When you accept a change that touches .env, Qyant restores the real values before writing. See Environment variables.