Concepts

Verification gate

How Duscode proves a task works. It runs your project's typecheck, lint and tests after every change, sends failures back to Dus, and reports Verified or Not verified.

"Done" in Duscode means your project's checks pass, not that the model says so. After any task that changed files, Duscode runs your project's checks. If one fails, Dus gets the output and fixes the cause. The gate is one source of evidence for the task's Proof of Work, which says Verified only when something checked the final state and nothing is open. If a check runs out of time, the task says Couldn't verify in time: not a failure, and the check's usual time decides how long Duscode waits next time.

Which checks run

If you haven't configured any checks, Duscode detects them:

JavaScript and TypeScript projects. It uses the typecheck, lint and test scripts in package.json, in that order. A test script that only says "no test specified" is skipped. The package manager comes from the lockfile: pnpm, yarn, bun, or npm otherwise. That gives commands such as pnpm typecheck or npm test.
Other stacks. If there's no package.json, Duscode uses the test, lint and typecheck commands of the project's architecture blueprint. For Django or Laravel, for example, that's their own test runner.
No package.json and no blueprint means no checks, so no gate.

Project details (click the project's name in the top bar) lists the detected checks under Tests (gate).

Set your own checks

List the commands in your project's .duscode/config.json:

json

{
  "checks": ["pnpm typecheck", "pnpm lint", "pnpm test -- --run"]
}

"checks": [] turns the gate off for that project. See Configuration.

What happens on failure

The checks run in order, and the first failure stops the run.
Dus receives the end of the output and is told to fix the cause, not the check.
Duscode runs the checks again. If they still fail after the first fix attempt, Dus moves up a tier.
After two fix attempts the task ends Not verified: checks fail, and you decide what to do next.

Checks run through the same command tool as everything else, without asking you, so the command blocklist still applies.

Warning
Checks come from the project's own files (package.json scripts or .duscode/config.json), and they run automatically at the end of a task. Only open projects whose scripts you trust, as you would before running npm test yourself.

How long a check may run

A check gets at least 10 minutes, or three times its usual time on your machine, whichever is longer. Duscode remembers how long each check took on your machine, for each project (in its own folder under ~/.duscode, not in your repository), and goes by the middle of the last ten runs. A typecheck that usually takes 8 minutes may therefore run for 24. No check is given more than 2 hours.

If a check is still running when its time is up, Duscode stops it and the task ends Couldn't verify in time. That is not a failure: Dus is not sent back to fix anything, the task isn't marked Not verified, and the check isn't counted as passing either. The message names the command and says how long it waited, and the task summary says to run it yourself. A slow check that was cut off is not remembered as "usual", so one hang can't stretch the next limit. If another check does fail, that failure is reported as usual.

Running the checks yourself

Click Run tests in Project details; the results open in the Tests tab of the work pane. This runs every check, not just up to the first failure, so you see lint and tests together. Failed checks open with their output. Ask Dus to fix them sends the failures to Dus as a new request. You can't run checks while Dus is working in that session.

Browser smoke check

For web apps, you can add a smoke check to the gate. It loads the session's live preview in a headless browser and fails on an error status or an uncaught page error:

json

{ "browserCheck": true }

It runs only while a preview is running, and is skipped if the headless browser isn't installed. See Web and browser checks.

Merging runs the checks too

Merge into in the Git view runs the checks in the session's worktree before merging. If a check fails, nothing is merged. See Git, commits and pull requests.