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