comet-verify
Comet Phase 4: Verify
On first entering a phase, handing off to a new Agent, or restoring context, read and follow Task Context and Artifact Language. Prefer the current continuation or claimed Action's contextRequest; do not retrieve repeatedly during uninterrupted work in the same phase.
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.
SDK Run path
On first entering the current SDK phase, handing off to a new Agent, or restoring context, read phase entry and recovery and the current phase's section in that reference. Reuse them when already available and still valid in this session. Continue with the phase below; recovery routes based on nextAction.kind apply only to older responses without a continuation mode.
Reuse the latest valid response for the same change, workspace, and Run: agent.continuation, data.nextAction, phase, revision, and path summaries. Run comet state next <change-name> --json only for cold recovery, workspace or external state changes, a stale response version, or missing information needed for the current step; loading the next Skill is not a reason to query again. Runtime still validates current versions and evidence on writes; cached context cannot bypass checks or approval. Confirm data.runtimeFormat: sdk, data.phase: verify, and nextAction.kind, and work in the bound projectRoot. Run comet classic workspace resolve <change-name> --json only when paths are missing or the binding has changed; use comet state check <change-name> verify --json only when current task, workspace, or evidence summaries are missing. For reconcile, use comet state check <change-name> verify --recover --json to investigate the original Action and check; stop if its result remains unknown.
- Follow the risk assessment, integrated review, and light/full verification methods in SDK execution methods, but use the SDK Run as evidence authority. Do not call legacy
state scale,state set,comet handoff, orcomet checkevidence commands. For implementation or task defects, report the specific failure. Only when<profile>.verify.runis pending (<profile>is full, hotfix, or tweak), runcomet state transition <change-name> verify-fail --reason "<failure-reason>". It records a failed Verify Action and returns to Build. Follow the current Build Action from that response; querystate next --jsononly if continuation information is missing. Investigate existing failed or unknown checks before reporting another failure. - When verification passes, write actual checks, evidence references, independent review, and acceptable deviations in a repository report at
<report-ref>. Run directlycomet guard <change-name> verify --report <report-ref> --apply -- <program> [args...]with an explicit complete verification command. Guard records the report, evidence, and real check receipt in one Run; a manual claim is insufficient. On check failure, use the failure receipt and current Build or Verify Action from the same response; querystate next --jsononly if they are missing, and follow the latest Action. - After Guard succeeds, use that response directly; run
comet state next <change-name> --jsononly if phase or nextAction is missing. Load/comet-archiveonly when phase is Archive andnextAction.kindpoints there. Verify passing does not itself authorize Archive; obtain the current delivery decision there.
Compat path
The remaining original Runtime steps apply only to runtimeFormat: compat. Read Compat operations and continue its current phase. SDK does not load that reference.