> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trykode.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# kode verify — Run the 9-Gate Verification Pipeline

> kode verify runs Kode's 9-gate pipeline on a JSON input file containing hunks or proposed file contents. Exits 0 on PASS, 1 on FAIL.

`kode verify` runs a set of proposed code changes through Kode's full verification pipeline without applying anything to disk. Give it a JSON file of hunks or file contents, and it will check each change for syntax correctness, valid imports, call graph consistency, blast radius limits, architectural rule compliance, security vulnerabilities, sandboxed runtime behaviour, dev-tunnel previewability, and end-to-end browser correctness. Use it to validate patches generated outside of Kode, to build CI gates, or to inspect what `kode generate` produced before committing.

## Synopsis

```bash theme={null}
kode verify --input <file>
```

## Input modes

`kode verify` accepts two JSON structures:

### Hunk mode

Use hunk mode when you have structured hunks scoped to specific files — the format produced by `kode generate`. Kode applies the hunks in-memory, then runs the full verification pipeline on the resulting file contents.

```json theme={null}
{
  "hunks": [
    {
      "id": "hunk-1",
      "file_path": "internal/user/handler.go",
      "action": "MODIFY",
      "target_symbol": "CreateUser",
      "anchor_text": "func CreateUser(w http.ResponseWriter, r *http.Request) {",
      "new_text": "func CreateUser(w http.ResponseWriter, r *http.Request) {\n\tif r.Body == nil { http.Error(w, \"empty body\", 400); return }",
      "explanation": "Add nil body guard to CreateUser"
    }
  ],
  "original_files": {
    "internal/user/handler.go": "<full original file contents>"
  }
}
```

The `original_files` map provides the pre-patch file contents so Kode can apply hunks accurately. Keys must match the `file_path` field in each hunk.

### File mode

Use file mode when you have complete proposed file contents rather than diffs. Kode verifies the files directly without applying any patches.

```json theme={null}
{
  "files": {
    "internal/user/handler.go": "<complete proposed file contents>",
    "internal/user/service.go": "<complete proposed file contents>"
  }
}
```

You can also embed `block_architecture` and `architecture_rules` in the JSON itself:

```json theme={null}
{
  "files": { "...": "..." },
  "block_architecture": true,
  "architecture_rules": [
    {
      "forbidden_import_prefix": "internal/db",
      "allowed_in_packages": ["internal/repository"],
      "error_message": "Only repository packages may import internal/db"
    }
  ]
}
```

## Flags

<ParamField path="--input" type="string" required>
  Path to the JSON file containing hunks or proposed file contents. This flag is required.

  ```bash theme={null}
  kode verify --input patches.json
  ```
</ParamField>

<ParamField path="--project-dir" default="cwd" type="string">
  Project root directory. Kode resolves import paths and architecture rules relative to this directory.
</ParamField>

<ParamField path="--block-architecture" default="false" type="boolean">
  Treat architecture rule violations as hard failures. By default, architecture violations are reported but do not cause the pipeline to exit `1`. Pass this flag to enforce them strictly.

  ```bash theme={null}
  kode verify --input patches.json --block-architecture
  ```
</ParamField>

<ParamField path="--log-dir" default="<project-dir>/logs" type="string">
  Directory where Kode appends the JSONL audit log entry for this run. The file is named `kode.log`. Kode creates the directory if it does not exist.
</ParamField>

<ParamField path="--model" type="string">
  Model identifier written to the audit log entry for telemetry purposes. Does not affect verification behaviour.
</ParamField>

## Exit codes

| Code | Meaning                                                                                            |
| ---- | -------------------------------------------------------------------------------------------------- |
| `0`  | All hunks or files passed every gate (`PASS`)                                                      |
| `1`  | One or more hunks failed at least one gate (`FAIL`), or the input file could not be read or parsed |

## Output

`kode verify` writes a verdict JSON object to **stdout**:

```json theme={null}
{
  "task_id": "verify",
  "status": "PASS",
  "applied_hunks": ["internal/user/handler.go"],
  "failed_hunks": {},
  "rounds_used": 1
}
```

On failure:

```json theme={null}
{
  "task_id": "verify",
  "status": "FAIL",
  "applied_hunks": [],
  "failed_hunks": {
    "internal/user/handler.go": "syntax: unexpected token '}' at line 42"
  },
  "rounds_used": 1
}
```

An audit log entry is appended to `<log-dir>/kode.log` after every run regardless of verdict. Use [`kode stats`](/cli/stats) to aggregate and trend these entries.

## Alias

`kode verify-hunks` is a full alias for `kode verify`. It accepts the same flags and behaves identically. It exists for compatibility with scripts that used the earlier command name.

```bash theme={null}
# These are identical
kode verify --input patches.json
kode verify-hunks --input patches.json
```

## Example: manual patch-and-verify workflow

```bash theme={null}
# 1. Generate patches without applying them
kode generate "add null check to CreateUser" > hunks.json

# 2. Inspect the JSON before verifying
cat hunks.json | jq '.[] | .file_path'

# 3. Wrap in the verify input envelope (generate outputs a raw array)
echo "{\"hunks\": $(cat hunks.json), \"original_files\": {}}" > patches.json

# 4. Run verification
kode verify --input patches.json

# 5. If it passes, apply with kode generate --apply
```

<Warning>
  `kode verify` **does not run your test suite**. It validates structural properties of the code (syntax, imports, call graph, architecture, security). For end-to-end validation including test execution, use `kode loop`.
</Warning>

For an explanation of each gate and how to interpret failures, see the [gate failure troubleshooting guide](/troubleshooting/gate-failures). For a conceptual overview of the pipeline, see the [verification pipeline reference](/concepts/verification-pipeline).