Comet Verify

Comet Phase 4: Verify and Close (Verify)

Prerequisites

• Code committed (Phase 3 complete)
• All tasks.md tasks completed

Steps

0a. Output Language Constraint

Verification reports and branch-handling notes must use the language of the user request that triggered this workflow.

0b. Entry State Verification (Entry Check)

Execute entry verification:

COMET_ENV="${COMET_ENV:-$(find . "$HOME"/.*/skills "$HOME/.config" "$HOME/.gemini" -path '*/comet/scripts/comet-env.sh' -type f -print -quit 2>/dev/null)}"
if [ -z "$COMET_ENV" ]; then
  echo "ERROR: comet-env.sh not found. Ensure the comet skill is installed." >&2
  return 1
fi
. "$COMET_ENV"
"$COMET_BASH" "$COMET_STATE" check <change-name> verify

Proceed to Step 1 after verification passes. The script outputs specific failure reasons when verification fails.

Idempotency: All verify phase checks can be safely re-executed. If verify_result is already pass and branch_status is handled, verification is complete — execute guard to transition. If verify_result is pending, start verification from the beginning.

1. Scale Assessment

Execute scale assessment:

"$COMET_BASH" "$COMET_STATE" scale <change-name>

The script automatically counts tasks, delta spec count, changed file count, determines light or full verification mode, and sets the verify_mode field. Decision rule (any condition triggers full): tasks > 3, delta spec capabilities > 1, changed files > 4.

Before verification begins, handle uncommitted changes through comet/reference/dirty-worktree.md protocol. Verify phase special handling:

1. If dirty diff belongs to current change and involves implementation, tests, tasks, delta spec, or design doc changes, do not fix or commit directly in verify phase; report failures and enter Step 1b verification failure decision blocking point
2. If dirty diff is only verify phase artifacts (e.g., verification report draft, branch handling records), may continue and record state in verify phase
3. If dirty diff shows implementation but tasks.md not checked, treat as build state lag; report failures and enter Step 1b, let user decide to roll back for fix or accept deviation

Only after user chooses fix, allow rollback to build phase:

# Execute only after user confirms fix
"$COMET_BASH" "$COMET_STATE" transition <change-name> verify-fail

Note: When verify-fail rolls back to build, branch_status is not reset. If branch handling was already completed during the first verify attempt, skip the branch handling step on re-verify and keep the existing branch_status: handled.

Note: If every task in build phase was committed, the script's file count based on working tree diff may underestimate change scale. In this case, must read plan file header base-ref and verify with commit range:

PLAN=$("$COMET_BASH" "$COMET_STATE" get <change-name> plan)
BASE_REF=$(grep '^base-ref:' "$PLAN" 2>/dev/null | head -1 | sed 's/^base-ref: *//')
git diff --stat "$BASE_REF"...HEAD

If commit range shows changes exceed lightweight threshold (> 4 files, cross-module coordination, or delta spec spans more than 1 capability), manually set to full verification:

"$COMET_BASH" "$COMET_STATE" set <change-name> verify_mode full

Override mechanism: If the agent or user believes the automated assessment is inappropriate, override at any time with "$COMET_BASH" "$COMET_STATE" set <change-name> verify_mode <light|full>.

1b. Verification Failure Decision (Blocking Point)

When verification does not pass, must follow the comet/reference/decision-point.md protocol to pause and wait for the user to decide whether to fix or accept the deviation. Must not automatically run "$COMET_BASH" "$COMET_STATE" transition <change-name> verify-fail, nor automatically invoke /comet-build.

When pausing, must list:

• Failed items
• Whether CRITICAL or IMPORTANT (build failure, test failure, security issues, core acceptance scenario failure, lightweight code review correctness/security/edge-case issue)
• Recommended handling approach

Uncertainty principle: When severity is unclear, downgrade (SUGGESTION > WARNING > CRITICAL). Only use CRITICAL for build failures, test failures, and security issues; ambiguous or uncertain issues should be WARNING or SUGGESTION.

After user selection, continue as follows:

• Fix all: Run "$COMET_BASH" "$COMET_STATE" transition <change-name> verify-fail, then invoke /comet-build to fix
• Handle item by item: CRITICAL or IMPORTANT failures must be fixed; WARNING/SUGGESTION failures may choose to accept deviation, but must record acceptance reason and impact scope in verification report. If any CRITICAL or IMPORTANT failure exists, skipping fix to accept all is not allowed

Retry limit: After 3 consecutive verify-fail cycles, on the 4th failure the agent must not automatically choose to continue fixing; must use the current platform's available user input/confirmation mechanism to pause with only two options: "Accept all deviations and record" or "Continue fixing", for the user to explicitly decide.

2. Artifact Context Loading (Hash On-Demand Read)

When verification needs to read OpenSpec artifacts, first check whether they have changed since the design phase:

RECORDED_HASH=$("$COMET_BASH" "$COMET_STATE" get <change-name> handoff_hash)
CURRENT_HASH=$("$COMET_BASH" "$COMET_HANDOFF" <change-name> --hash-only 2>/dev/null || echo "")

• If RECORDED_HASH = CURRENT_HASH and both are non-empty and neither is null: OpenSpec artifacts are unchanged. tasks.md does not need to be re-read in full (use grep -c '\- \[ \]' tasks.md to confirm completion count). proposal.md, design.md, and delta specs must still be read for comparison checks.
• If RECORDED_HASH is empty, is null, or differs from CURRENT_HASH: artifacts have changed or hash was never recorded. Read all required files in full normally.

This optimization only skips re-reading tasks.md in full. proposal.md and design.md contain the full context needed for verification checks and must not be skipped due to hash match.

Immediately execute: Use the Skill tool to load the Superpowers verification-before-completion skill. Skipping this step is prohibited.

After the skill loads, follow the verify_mode branch:

2a. Lightweight Verification (Small Changes)

Run these 6 checks:

1. All tasks.md tasks completed [x]
2. Changed files match tasks.md descriptions (git diff --stat / git diff --cached --stat / git diff --stat <base-ref>...HEAD compared against tasks content)
3. Build passes (run project-specific build command, e.g., npm run build, mvn compile, cargo build, etc.)
4. Related tests pass
5. No obvious security issues (no hardcoded keys, no new unsafe operations)
6. Lightweight code review passes: use the Skill tool to load the Superpowers requesting-code-review skill and request a lightweight review that checks only correctness, security, and edge cases

The lightweight code review input should be limited to this change's diff, tasks.md, and necessary test results; the review scope covers implementation correctness, security risk, and edge cases only, and does not perform spec coverage, Design Doc consistency, or drift checks. If the review finds CRITICAL or IMPORTANT issues, treat verification as failed and enter Step 1b.

Pass criteria: All 6 items OK, no CRITICAL or IMPORTANT issues.

When not passing: Report failures, enter Step 1b verification failure decision blocking point. Only after user confirms fix, execute the following command to record failure and roll back to build phase, then invoke /comet-build to fix:

# Execute only after user confirms fix
"$COMET_BASH" "$COMET_STATE" transition <change-name> verify-fail

Report format: Brief table listing 6 check results + PASS/FAIL.

Skipped items (not checked in lightweight verification):

• spec scenario coverage
• design doc consistency deep comparison
• code pattern consistency suggestions that do not affect correctness, security, or edge cases
• delta spec and design doc drift detection