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

# Phase 4: Verify

> Run risk-appropriate checks, save the verification report, and hand a passing change to Archive; branch delivery does not happen in this phase.

Verify confirms that implementation matches the Design Doc, OpenSpec specs, and task list, then saves the conclusions as reviewable evidence. It does not merge, push, discard, or otherwise handle the branch.

<Tip>
  Normally, invoke <code>/comet</code>. When project configuration selects Classic, the internal{' '}
  <code>/comet-classic</code> router sends a completed build to <code>/comet-verify</code>.
</Tip>

## Prerequisites

* Build is complete
* Every task in `tasks.md` is complete
* `isolation` and `bound_branch` match the current worktree
* Full workflow execution, TDD, and review modes are selected

## Flow

```mermaid theme={null}
flowchart TD
    Entry["Validate entry state"] --> Scale["Assess scale: light / full"]
    Scale --> Checks["Build, test, security, and spec checks"]
    Checks -->|Failure| Repair["Return to Build or accept a non-blocking deviation"]
    Checks -->|Pass| Drift{"Spec drift?"}
    Drift -->|Needs correction| Repair
    Drift -->|Handled or absent| Report["Save verification_report"]
    Report --> Guard["comet guard verify --apply"]
    Guard --> Archive["phase: archive<br/>branch_status: pending"]
```

## Verification depth

Comet selects `light` or `full` from the task count, delta spec count, and changed-file count:

* **Light** checks task completion, change ownership, build, relevant tests, security, and the configured code review.
* **Full** adds proposal, OpenSpec design, Design Doc, acceptance-scenario, and spec-drift checks.

Full verification uses `openspec-verify-change` to check spec coverage. Code review follows `review_mode`, but branch delivery always remains in Archive.

## Failure handling

* Objectively fixable build, test, security, or acceptance failures return to Build through `verify-fail`.
* WARNING and SUGGESTION findings ask the user only when accepting them involves a real tradeoff; the rationale is recorded in the verification report.
* CRITICAL and IMPORTANT findings cannot be waived.
* `verify-fail` preserves existing field values, but `branch_status` should remain `pending` throughout the normal Verify flow.

## Save verification evidence

After verification passes, record the report path:

```bash theme={null}
comet state set <change-name> verification_report docs/superpowers/reports/YYYY-MM-DD-<name>-verify.md
```

Do not write `branch_status: handled` in Verify, and do not set `verify_result: pass` by hand.

Then run:

```bash theme={null}
comet guard <change-name> verify --apply
```

The guard requires the report to exist, then advances to `phase: archive` and records `verify_result: pass` and `verified_at`. `branch_status` stays `pending`; Archive handles it after the user confirms immediate remote delivery.

## Spec drift

When full verification finds a mismatch between the delta spec and Design Doc, the user can:

* Record an Implementation Divergence in the Design Doc;
* Return to Build through `verify-fail` and realign design with implementation; or
* Accept a non-blocking deviation and let the main spec become the final authority during archive.

## Next steps

* [Archive phase](/en/phases/archive)
* [Decision points](/en/concepts/decision-points)
* [Code review modes](/en/concepts/review-mode)
* [State and configuration](/en/concepts/state-management)