Comet Verify

Comet Phase 4: Verify

After entry returns layout, follow comet-classic/reference/classic-layout.md to bind each logical root to its directory. Do not reload the protocol if it is already in context. Use the adapter for OpenSpec CLI calls and the bound <classic-*> roots for paths; do not run an extra root show first.

Prerequisites

• Code is committed; Phase 3 is complete.
• Every task in tasks.md is complete.

Steps

0a. Set the output language

Use configuration.language from this invocation's entry result for the report. Do not query the language field separately.

0b. Validate entry state

Use the supported comet CLI in comet-classic/reference/scripts.md for these checks. When resuming from any entry, first follow comet-classic/reference/context-recovery.md:

comet state select <change-name>
comet state check <change-name> verify --json

When the previous phase's guard already returned this phase's state, continue from that state and agent.continuation without repeating select/check; run the entry checks above only when resuming, after workspace changes, or after external state changes. Continue from the returned layout, configuration, nextAction, task information, and coordination summary. If checks and the integration review remain valid, finish only the missing work instead of rerunning the phase. After context loss, use --recover --details --json when full records are needed. Handle the reported cause of any failure.

If select/check returns BLOCKED — or a branch-binding ERROR — because bound_branch differs from the current branch, pause under comet-classic/reference/decision-point.md. Offer a single choice: return to the bound branch and rerun entry checks, or, after the user explicitly confirms that the current branch should take over this change, run comet state rebind <change-name> and rerun entry checks. Do not switch or rebind branches yourself.

Continue from recorded results: If verify_result is pass, proceed to archive. Keep branch_status at pending until the archive commit and final branch handling are complete. If verify_result is pending, inspect existing reports and results, then resume unfinished checks.

After context loss, follow evidence.scopes: reuse local results marked revalidated; rerun the parts marked rerun-required. Do not repeat completed requirements analysis or reviews that still apply. Do not assume external checks are idempotent or their environments remain unchanged.

1. Assess the change size

Run:

comet state scale <change-name>

The script counts tasks, delta specs, and changed files, returning a light/full recommendation without changing verify_mode. Use --json for data.recommendation, data.selected, and data.metrics. Preserve an already selected mode. Otherwise, choose based on risk and record it with comet state set <change-name> verify_mode <light|full>. Scale recommends full if any of these hold: tasks > 3, delta-spec capabilities > 1, or changed files > 8.

comet state scale resolves the baseline from the plan's base-ref, falling back to state base_ref when the plan is unavailable. Do not reread plan frontmatter or build a second scale calculation manually.

Before verification, inspect uncommitted changes under comet-classic/reference/dirty-worktree.md. Apply these Verify-specific rules:

1. Include uncommitted changes clearly belonging to this change in the verification input. Continue verifying, but do not modify or commit implementation, tests, tasks, delta spec, or the Design Doc in Verify. Documentation-only edits (the neutral document set defined in comet-build: Markdown plus LICENSE/NOTICE/AUTHORS at the repository root, and Markdown/.txt/.rst under docs/, doc/, documentation/, .github/, excluding OpenSpec and Superpowers artifacts) may be completed normally in Verify — they are not implementation writes, they do not invalidate check evidence by default, and they do not require verify-fail.
2. If uncommitted changes are Verify artifacts, such as a draft report, continue completing them and recording state in Verify.
3. If implementation exists but tasks.md is unchecked, Build's task record is behind the code. Run verify-fail directly to return to Build, inspect evidence, and update task state. Do not ask whether to accept unfinished tasks.
4. If ownership cannot be established or the changes belong to another change, report the stopping condition from dirty-worktree. Do not offer “continue/ignore” before ownership is known.

To return to Build for repairs or missing state:

comet state transition <change-name> verify-fail

Adjust verification mode: If the Agent or user considers the automatic recommendation unsuitable, change the mode with comet state set <change-name> verify_mode <light|full>.

Small changes do not waive risk checks. Authentication/authorization, data migrations, concurrency, public APIs, and cross-module interface requirements need their relevant risk scenarios verified. Use full when light cannot cover them.

1b. Repair verification failures and handle user decisions

On failure, read the consecutive failure count and nextAction from the latest entry. Query comet state get <change-name> verify_failures only if the field is missing; do not treat a missing field as zero. Automatically return to Build for the first 3 repairable failures: report the failure, run comet state transition <change-name> verify-fail, then invoke /comet-build to finish only missing implementation, checks, reviews, or task marks. Do not repeat completed work.

Report:

• The failed items.
• Whether they are CRITICAL or IMPORTANT: build/test failures, security issues, core acceptance failures, or correctness/security/edge-case issues from the simplified code review.
• The recommended response.

When severity is uncertain, use the lower level. Use CRITICAL only for build failures, test failures, or security issues. Use IMPORTANT for definite effects on core acceptance or correctness. Mark vague or uncertain issues WARNING or SUGGESTION.

Handle them as follows:

• CRITICAL/IMPORTANT or a clearly repairable in-scope issue: return to Build automatically while below the limit. Do not add “should I fix it?” approval or allow the deviation to be accepted.
• WARNING/SUGGESTION whose fix changes behavior, scope, or risk tradeoffs: follow comet-classic/reference/decision-point.md and let the user choose repair or acceptance. Record the reason and affected scope if accepted.
• WARNING/SUGGESTION with a safe, local fix and no tradeoff: repair automatically while below the limit; low severity alone does not require a pause.

Accepting WARNING/SUGGESTION deviations or choosing a strategy after the fourth failure requires a user decision. When current verify_failures >= 3, do not automatically run another verify-fail. Offer only “Continue repairing” or “Stop this workflow and seek an external decision.” Record the next failure and return to Build only after the user chooses to continue. CRITICAL/IMPORTANT findings can never be waived.

2. Read the artifacts needed for verification

When verification needs OpenSpec artifacts, use the handoff status already returned by entry. Run this only if entry lacks the current comparison:

comet handoff <change-name> --hash-only

Read the [HANDOFF] status: verdict from stderr and act on it; the stdout hash stays for scripted callers and is never compared by hand:

• FRESH: reuse artifact content already in context, read only acceptance sections still missing, and still verify task completion marks.
• STALE (changed: <files>): read the listed changed artifacts in full before verifying acceptance against them; if runtime's NEXT suggests comet handoff <change-name> design --write, run it before reading.
• STALE without a file list: read every required source file in full because the recorded handoff is missing or predates the current artifacts.

A FRESH verdict does not mean the content is still in context. After context loss, truncation, or uncertainty about what was read, reload the corresponding sources. A handoff summary cannot replace acceptance clauses that have not been read.

Autonomous performs the actual checks and records results under this Skill without requiring an external verification skill. Other strategies load Superpowers verification-before-completion through the Skill tool. No strategy may declare verification successful based only on self-assessment.

Verify owns the single final integration code review for the whole change. Build retains task/section reviews only. Before taking the verify_mode branch, review the final diff, including fixes from Build reviews:

• review_mode: off: skip automatic code review and record why in the report.
• review_mode: standard|thorough: dispatch an independent reviewer across the entire change. Check requirements, actual diffs, check results, and repairs, focusing on correctness, security, and edge cases. Autonomous needs no external review skill; other strategies load requesting-code-review once. Reuse a valid review covering the current final diff. After input changes, review affected parts rather than unconditionally repeating the whole review. Stop if independent review is unavailable; implementer self-review is not a substitute.

Return CRITICAL/IMPORTANT integration-review findings to Build under Step 1b. Handle non-CRITICAL deviations using Step 1b's tradeoff rules. Then follow verify_mode: