.kanman/verify.json

Every key of the verify manifest: the local verify command for each change, and the names of the CI variables it may receive.

The verify manifest declares how a change is checked locally before it goes to review, your CI and the outcome gate. It lives at .kanman/verify.json in the repository root, next to .kanman/acceptance.json.

When it runs

After the coding agent finishes an attempt, and before the run goes to review, kanman runs the verify command in the run’s checkout:

  1. kanman reads .kanman/verify.json from your base branch, not from the run branch. A change in a run can never alter which command runs or which variables are read.
  2. It fetches the CI variables named in ci_var_keys (see below) and add the secrets for runs your team policy grants.
  3. It runs setup, then command, in cwd, within timeout_seconds.
  4. If the command fails, the coding agent gets one fix-up round with the command’s output, and kanman runs the verify command again.

Files the command creates (build output, caches, reports) are thrown away afterwards and never end up in the pull request. The result appears as the Local verify check of the run and in the evidence pack, together with the command’s output. The clean-room run of the acceptance spec stays the proof of the outcome; the local verify is an early signal that catches lint, type and unit test errors before review.

Example

The manifest of the demo repository kanman-ai/pilot-sandbox:

{
  "version": 1,
  "cwd": ".",
  "setup": "npm ci",
  "command": "npm run lint && npm run typecheck && npm test",
  "env": {
    "CI": "true"
  },
  "ci_var_keys": []
}

Keys

Key Type Required Default Description
version number yes Always 1.
cwd string no . Working directory for setup and command, relative to the repository root. Useful in monorepos. It cannot point outside the repository.
setup string no Command run once before command, for example installing dependencies. If it fails, command does not run.
command string yes The local verify command, for example npm run lint && npm test. A non-zero exit code fails the Local verify check.
env object of strings no {} Plain environment variables for setup and command. Never put secrets here.
ci_var_keys array of strings no [] Names of CI variables the verify command may receive. Names only: the values stay in your CI settings.
timeout_seconds integer no 600 Maximum run time of setup plus command. Maximum 1800.

Unknown keys are ignored. An invalid manifest shows up as an error of the Local verify check with the reason; a repository without the file skips the check.

Secrets and CI variables

ci_var_keys lists the only variables kanman reads from your repository’s CI settings, and only for the verify command:

  • GitHub: GitHub Actions variables of the repository, and organization variables the repository may use. GitHub never hands out the values of Actions secrets; for a secret, store it under secrets for runs and list it in the team policy instead.
  • GitLab: CI/CD variables of the project. Reading them needs the Maintainer role on the project for the connected account.

A name kanman cannot read is listed in the run with the reason (not found, no access), and the command runs without it. Names that kanman uses itself, such as model provider keys or PATH, are never filled in.

Values are never stored in the manifest, in the run record, in the evidence pack or in the audit log, and they are removed from the command’s output before it is saved; only the names appear.

{
  "version": 1,
  "command": "make lint test",
  "ci_var_keys": ["NPM_TOKEN", "SENTRY_DSN_TEST"],
  "timeout_seconds": 900
}

Warning

Prefer an empty ci_var_keys. A verify command that needs production credentials is a sign that tests reach outside the sandbox. See Sandbox and secrets.

Without a verify manifest

The manifest is optional. Without it, kanman relies on your CI status and the reviewer run. With it, lint and type errors are caught and fixed before a pull request is reviewed, which saves CI minutes and rework attempts.

You do not have to write it yourself: for a repository without one, kanman drafts it from the commands its CI, Makefile and scripts already run and proves it in your team environment first (see Repository setup).

Last updated: January 1, 0001

Open kanman