Acceptance & Verification
How Kavi generates acceptance criteria and verifies mission completion through command, file, and manual checks.
Acceptance & Verification
Every mission carries an AcceptancePack that defines what "done" means and how to verify it. Kavi auto-generates acceptance criteria from your prompt, synthesizes verification checks from your repository context, and runs them before allowing a mission to land.
AcceptancePack
The acceptance pack is the top-level container for verification data:
| Field | Type | Description |
|---|---|---|
id | string | Unique identifier |
summary | string | Human-readable summary of the acceptance pack |
criteria | string[] | Auto-generated acceptance criteria (plain-language statements) |
checks | AcceptanceCheck[] | Concrete verification actions to run |
status | AcceptancePackStatus | Overall status: pending, passed, or failed |
createdAt | string | ISO timestamp of creation |
updatedAt | string | ISO timestamp of last update |
AcceptancePackStatus
The pack status is computed from the individual check statuses:
- pending -- at least one check has not yet run and none have failed
- passed -- every check is either
passedorskipped - failed -- at least one check has
failed
Acceptance Checks
Each check is a concrete verification action. There are three kinds:
AcceptanceCheckKind
| Kind | What it does |
|---|---|
command | Runs a shell command and checks the exit code (0 = pass) |
file | Checks that a file path exists in the repository |
manual | Flags an item for operator review (automatically skipped during automated verification) |
AcceptanceCheckStatus
| Status | Meaning |
|---|---|
pending | Not yet evaluated |
passed | Check succeeded |
failed | Check failed |
skipped | Check was not applicable or was a manual check during automated verification |
AcceptanceCheck Fields
| Field | Type | Description |
|---|---|---|
id | string | Unique identifier |
title | string | Short description of what is being verified |
kind | AcceptanceCheckKind | The type of check: command, file, or manual |
command | string | null | Shell command to run (for command checks) |
path | string | null | File path to verify (for file checks) |
status | AcceptanceCheckStatus | Current check status |
detail | string | Extended description or the command text |
lastRunAt | string | null | ISO timestamp of the last run |
lastOutput | string | null | Output from the last run |
Auto-Generated Criteria
When a mission is created, Kavi analyzes the prompt text and generates acceptance criteria. The following rules drive criteria generation:
Base criterion (always added)
Every mission receives:
"The requested slice is implemented in a coherent, runnable state."
UI / frontend keywords
If the prompt contains terms like ui, ux, frontend, design, screen, page, component, or layout, Kavi adds:
"User-facing behavior is understandable and coherent for the requested flow."
Backend keywords
If the prompt contains terms like api, backend, server, database, worker, queue, contract, or schema, Kavi adds:
"Backend and contract behavior match the requested implementation scope."
Test keywords
If the prompt contains terms like test, smoke, verify, validation, qa, or review, Kavi adds:
"There is at least one practical validation path for the delivered work."
Documentation keywords
If the prompt contains terms like readme, docs, documentation, onboard, or setup, Kavi adds:
"The repo explains how to run or understand the delivered slice."
Synthesized Checks from Repository Context
Beyond the criteria, Kavi inspects the repository to generate concrete verification checks. This happens when acceptance verification is triggered and examines the following:
| Repository Signal | Generated Check |
|---|---|
package.json with a test script | Command check: runs npm test (or pnpm test, yarn test, bun run test based on lockfile detection) |
package.json with a build script (and frontend-related changes) | Command check: runs the build command |
go.mod exists | Command check: go test ./... |
Cargo.toml exists | Command check: cargo test |
pyproject.toml, pytest.ini, or tests/ directory exists | Command check: pytest |
README.md exists or docs keywords in prompt | File check: verifies README.md exists |
| Backend keywords and backend file paths in completed tasks | File check: verifies backend implementation files exist |
| Frontend keywords and frontend file paths in completed tasks | File check: verifies frontend implementation files exist |
Kavi also adds a manual check for operator review of the mission output. This check is automatically marked as skipped during automated verification runs so it does not block landing.
Package manager detection uses lockfile presence: pnpm-lock.yaml for pnpm, yarn.lock for yarn, bun.lockb or bun.lock for bun, and falls back to npm.
Verification Workflow
When all mission tasks complete, Kavi transitions the mission to awaiting_acceptance and verification can be triggered.
Synthesize checks
Kavi scans the repository for test runners, build scripts, and documentation markers. Checks are deduplicated by a composite key of kind, command, path, and title, so re-running synthesis does not create duplicate checks.
Merge into integration workspace
Verification runs against the integration worktree, which merges all agent worktrees into a single workspace. This ensures checks run against the combined state of all agent work.
Execute command checks
Each command check runs in the integration workspace. The exit code determines pass/fail, and stdout/stderr are captured in lastOutput.
Test file existence
Each file check verifies the specified path exists in the repository.
Mark manual checks as skipped
Manual checks are marked skipped during automated verification. The operator can review these separately.
Compute pack status
The overall acceptance status is recomputed: passed if all checks are passed or skipped, failed if any check failed, pending otherwise. The mission status transitions accordingly:
- All passed/skipped: mission moves to
ready_to_land - Any failed: mission moves to
blocked
CLI Commands
Use the following CLI commands to work with acceptance:
# Inspect the current mission's acceptance pack
kavi accept
# Run verification checks against the integration workspace
kavi verifykavi accept displays the acceptance criteria, checks, and their current statuses. kavi verify triggers the full verification workflow described above.