# Verification and Definition of Done

## Purpose

Define what it means for agent work and tickets to be complete.

Agents can move fast, but ticket closure must be based on evidence, not confidence, narrative, or a single agent's claim.

## Core Principle

No meaningful ticket is done until the result has been verified against its acceptance criteria and reviewed by a separate context/agent when risk or complexity justifies it.

## Verification Is Evidence

Verification should answer:

- What changed?
- Where did it change?
- Why was it changed?
- How was it tested or inspected?
- What still was not verified?
- How can it be rolled back?
- What follow-up tickets or risks remain?

Acceptable evidence includes:

- `git status --short`
- `git diff` / `git diff --stat`
- test command output
- syntax/type/lint checks
- service status checks
- HTTP/API health checks
- log excerpts
- screenshots or user confirmation for UI-only behavior
- server change-log entries
- runbook updates
- reviewer notes in `06-review.md` or ticket closeout notes

## Definition of Done Levels

### Level 0 — Captured / Planned

Done means:
- request is captured in inbox/ticket;
- goal and next action are clear enough to resume.

No implementation verification required.

### Level 1 — Documentation-only Change

Done means:
- docs changed are scoped;
- links/references are correct enough for expected use;
- another context or reviewer pass checks important process docs before relying on them;
- ticket notes mention what was updated.

### Level 2 — Repo Code / Tooling Change

Done means:
- git status/diff reviewed;
- relevant tests/smoke checks run or explicitly not available;
- behavior documented;
- rollback is ordinary git revert or documented;
- reviewer/verifier pass checks scope and output.

### Level 3 — Service / Infrastructure Change

Done means:
- preflight and lock/registry requirements were followed;
- live state verified after change;
- service health verified from an approved client/path;
- server change log updated;
- runbook/status/inventory updated as applicable;
- rollback or snapshot path documented;
- independent review/verifier pass checks docs and live-state evidence.

### Level 4 — Security / Secrets / Critical Data Change

Done means all Level 3 requirements plus:
- explicit user authorization for risky/security-sensitive action;
- no secrets exposed in logs/docs/chat;
- backup/recovery/break-glass requirements satisfied or clearly recorded as blockers;
- restore/recovery test completed or scheduled before critical dependence;
- second context/agent review is mandatory before marking done.

## Reviewer / Verifier Requirement

For meaningful work, the implementer should not be the only verifier.

Use a separate context/agent for review when:

- infrastructure changed;
- security/secrets are involved;
- code/tooling will be reused by agents;
- the ticket spans multiple files/systems;
- prior agents failed or the working tree is dirty;
- the user will rely on the result operationally.

The reviewer should check:

- acceptance criteria;
- changed files/diffs;
- verification evidence;
- unresolved risks;
- rollback notes;
- related tickets/dependencies.

## Not Done States

A ticket should not be marked done if:

- verification is missing;
- implementation only partially satisfies acceptance criteria;
- a required user action is pending;
- a dependency is unresolved;
- rollback is unknown for a risky change;
- live state differs from docs;
- another active ticket was silently bypassed or contradicted;
- critical follow-up is hidden in chat only.

Use statuses such as `Waiting`, `Blocked`, or `Partially Complete` notes instead.

## Closeout Checklist

Before marking a ticket done:

- [ ] Acceptance criteria checked or revised
- [ ] Changed files/systems listed
- [ ] Commands/tests/checks recorded
- [ ] Verification not performed is explicitly listed
- [ ] Risks/follow-ups recorded as tickets or notes
- [ ] Related tickets/dependencies linked
- [ ] Runbooks/status/inventory updated if applicable
- [ ] Server change log updated if server-side changes occurred
- [ ] Rollback/restore notes recorded
- [ ] Reviewer/verifier pass completed for meaningful work

## Agent Behavior

Agents should be proactive about completing tickets, but cautious about declaring completion.

A good completion response says:

```text
Implemented/updated: <what>
Verified: <evidence>
Not verified: <limits>
Risks/follow-ups: <items>
Rollback: <how>
Reviewer: <who/what checked>
Ticket status: <Done/Waiting/Blocked>
```

A bad completion response says only:

```text
Done.
```