dkod

Verification Pipeline

The verification pipeline runs lint, type-checking, and tests against a changeset to confirm structural correctness. It is called explicitly via dk_verify — typically by the harness orchestrator during the landing pipeline (submit → verify → review → approve → merge → push).

Verification vs. Review

Verification and code review are complementary quality gates:

Verification (dk_verify)Review (dk_review)
What it checksCorrectness — lint, type-check, testsQuality — patterns, security, conventions
When it runsExplicitly, when called by the agent or harnessLocal review runs automatically on every dk_submit; deep review runs async with BYOK
OutputPass/fail per gate with structured errorsScore (1–5) with findings by severity
Purpose"Does the code compile and pass tests?""Is the code well-written and safe?"

Both must pass before the harness approves a changeset. In the landing pipeline, the orchestrator calls dk_verify first (correctness), then dk_review (quality), and only proceeds to dk_approve if both pass.

How It Works

When an agent or the harness calls dk_verify, dkod runs the project's lint, type-check, and test commands against the changeset in an isolated environment. Results are streamed back as each gate completes — the agent receives structured pass/fail data with error details, file paths, and suggested fixes.

{
  "status": "passed",
  "gates": [
    { "name": "typecheck", "status": "passed", "duration_ms": 1200 },
    { "name": "lint", "status": "passed", "duration_ms": 400 },
    { "name": "affected_tests", "status": "passed", "duration_ms": 8500 }
  ]
}

If any required gate fails, the agent gets structured failure data and can immediately fix and resubmit — no waiting for CI, no parsing log output.

In the Harness

The harness orchestrator calls dk_verify as part of the landing pipeline:

  1. Generator agent calls dk_submit (local review runs automatically, returns review_summary)
  2. Orchestrator calls dk_verify — runs lint, type-check, tests
  3. Orchestrator calls dk_review — gets full review findings
  4. If both pass, orchestrator calls dk_approve → dk_merge → dk_push
  5. If either fails, the generator is re-dispatched with the failure details to fix and resubmit

Next Steps