Skip to main content
Verify judges the implementation item by item against the confirmed requirements; the Builder’s own statement that the code is “done” is only a clue, not a conclusion. Builder reviews implementation and evidence item by item, Runtime runs the necessary checks, and a new read-only Verifier Subagent independently evaluates brief.md, Specs, and acceptance items. Complete self-review and passing checks do not replace independent acceptance. Code changes happen only in Build; Verifier remains read-only.

​
How different results are handled

When each Verify ends, the Runtime classifies the outcome into one of the cases in the table below. Most cases advance automatically; a few pause and wait for you. First match the result type, then see what you need to do and where the flow goes next. “Not accepted” and “Verifier failed to execute” are not the same thing. The former means the implementation still does not meet the requirements, or the requirements themselves are flawed; the latter means the acceptance task itself did not complete normally. The Runtime records them separately, so an infrastructure failure is not mistaken for a product failure. Only the two rows in the table ask you to make an explicit choice from a command. The meaning of each option and the commands are described in the next section.

​
You decide whether to accept the result or adjust the goal

When the final Verifier started by the Skill has marked everything as passed, but the platform cannot prove to the Runtime that it ran independently of the Builder, the Runtime pauses and offers three mutually exclusive options: All three options are submitted through comet native next:
You can accept the result and choose delivery together, for example with --accept-result --finish keep. Comet first shows the actual workspace and the effects of each option. See Archive and delivery for the complete choices. When the platform cannot start a semantic Verifier at all, a full set of passing Runtime checks only yields a degraded result. The Runtime then pauses and offers two options: retry the acceptance (comet native next <change> --retry-verifier, which keeps the current candidate and the checks already completed and only starts a new acceptance attempt) or accept the degraded result (accept explicitly with the --confirmed action returned by the continuation). After you confirm acceptance, the report still keeps the degraded marker, noting that this was not an independent verification. The commands for the two paths:
All decision commands carry --expected-state-version and --expected-action. If the state has already changed, or the operation comes from an old page or an old task, the Runtime rejects it, so a late decision cannot overwrite the current result.

​
After a partial fix, a full acceptance must run again

After you choose --revise-implementation, or when failed items return to Build, the Runtime schedules the fix and the re-acceptance with the rules below. When checks or acceptance items fail, Runtime records their reasons in the latest continuation and returns the change to Build. Builder fixes the implementation, updates self-review for affected items, and submits a new candidate. For blocked items, Runtime waits for the missing user decision or external condition rather than treating missing information as a code defect. Builder focuses its repair on two groups:
  • the acceptance items that were still unresolved in the previous round;
  • the acceptance items the Builder declares may be affected by this round of changes.
Applicable self-review records can be retained. Runtime checks are reused only when their inputs, commands, workspace, environment, and logs remain valid. Changed code or check inputs require fresh checks. A new Verifier covers all acceptance items for the repaired candidate in one round. After full acceptance passes, the flow advances to result acceptance or Archive without resetting passed results for an identical full verification. Complete independent acceptance means all criteria for the current change, not the entire repository test suite.

​
Supervisor Change completes the final acceptance in the integration workspace

The sub-tasks of a Supervisor Change must reach active, verified, and integrated in order. A sub-task passing its own acceptance does not mean the whole Supervisor Change is complete. After all sub-tasks are integrated, the Runtime runs at least one integration check in the Supervisor’s integration worktree and performs the final Verify over the full acceptance scope. If the integrated result fails, the Runtime keeps the scene, adds repair sub-tasks based on the items that actually failed, and reconfirms the Shape. Sub-tasks that have already integrated stay as they are.

​
The verification report can be rebuilt when missing

verification.md is the user-facing acceptance report with the Runtime checks, item-by-item results, risks, limitations, and the final conclusion. The acceptance conclusion is also recorded in comet-state.yaml, so when the report is missing, the write was interrupted, or the version is stale, it can be regenerated from the recorded conclusion. Local execution from an old device cannot be reused directly after you switch devices. A candidate at verify-ready re-runs the necessary checks and starts a new Verifier; a candidate at archive-ready also returns to Verify first to reconfirm the synchronized implementation. The recovery process itself is not counted toward the failed-round or stalled counters.

​
What cannot be confirmed automatically is handed back to the user

The Runtime can confirm whether a command actually executed, whether the exit code was normal, whether the acceptance items are complete, and whether the returned result belongs to the current candidate and the current attempt. A normal Archive directly uses the accepted verification results, without re-running the same batch of checks. When a conclusion depends on whether the test itself is reasonable, or on background processes, IDE writes, or external system state that the platform does not provide, the Runtime cannot confirm it alone. When the platform cannot provide an independent Verifier or complete semantic acceptance, the Dashboard and the reports state exactly what is missing and hand the accept-or-not decision back to you.

​
Verifier protocol reference

The choices above rest on the mechanism below. You do not need to read these details before making everyday choices; come back here when you want to know how a result is produced, how the boundaries are drawn, or how the limits are enforced.

​
The three verification layers

Builder provides implementation and evidence leads, Runtime proves checks actually ran, and Verifier independently determines whether the requirements are met. Verifier supplies the final acceptance conclusion.

​
A candidate enters Verify with complete self-review

After implementation, Builder checks every confirmed acceptance requirement: whether it is implemented, where the code is, what evidence supports it, and what limitations remain. Missing work stays in Build. Ordinary candidates and Supervisor parent candidates do not require a separate preliminary Reviewer; independent Verifier acceptance remains required. After completing self-review, Builder submits a concise handoff to Runtime that includes:
  • what was completed in this round;
  • which acceptance IDs were addressed;
  • which development-time checks actually ran, and which did not;
  • the current known limitations;
  • implementation and evidence self-review for every confirmed acceptance item.
Runtime saves handoff to comet-state.yaml and binds it to the candidate ID, iteration, and Builder identity. A handoff records a candidate awaiting acceptance; it does not prove the candidate passed.

​
The Runtime runs checks first, then the Verifier accepts items one by one

Once a candidate enters Verify, the flow proceeds in this order:
  1. Determine the acceptance scope. A formal Verifier covers all acceptance items for the current candidate. The repair summary identifies previous unresolved items and those affected by the new changes.
  2. Run the necessary checks. The Runtime runs the tests, builds, or other project commands and records status, exit codes, duration, and summaries. The verification commands carried by the project policy (see Project rules) also run here as necessary checks, and a policy is promoted to enforced only when its check genuinely passes.
  3. Prepare the acceptance context. The successful Builder-check response directly returns verifierDispatch, including the actual workspace, requirements and evidence locations, acceptance scope, startup receipt input, and Runtime check results. No extra query or repeated dispatch is needed.
  4. Start a new Verifier Subagent. The Verifier stays read-only and gives one conclusion per acceptance ID in the current scope.
  5. Validate and accept the result. The Runtime checks that the candidate, identity, round, attempt, and acceptance scope match before deciding the next step.
The Verifier reads the current acceptance scenario, brief.md, the complete target Specs, the actual implementation, and the Runtime check results first, and only treats the Builder handoff as an investigative lead at the end. This order reduces how much the Builder’s own account influences the acceptance judgment. Each scopeId must appear exactly once and can only be marked:
  • passed: the implementation satisfies this acceptance item;
  • failed: the implementation does not satisfy it and needs to return to Build;
  • blocked: a user decision, external condition, or other necessary information is missing, so no judgment is possible yet.
Missing items, duplicates, unknown IDs, identity mismatches, and stale results are rejected. Correctable fields, formatting, or scope errors can be fixed and resubmitted using the current template within the same Verifier task. An old candidate or task result cannot be relabeled with a new identity. All Runtime checks must pass before Verifier can submit an overall pass.

​
Wait for the existing Verifier

The task includes startup receipt input. Before startup is confirmed, the Agent checks whether the platform accepted the launch and recovers the original task. After confirmation, it waits for that same Verifier. A delayed receipt or wait-tool timeout alone does not mean execution failed. Register an execution error and retry only after the platform confirms failure, execution timeout, task loss, or completion without a usable result.

​
Supplementary checks are still executed by the Runtime

When the existing evidence is insufficient, the Verifier can ask for extra checks through request-checks. It only states what should run; the Runtime executes and records the commands. Supplementary checks belong to the current Verifier attempt and do not increase it. Runtime reuses completed checks, filters duplicate requests, and returns results to the same Verifier. At most 2 supplementary rounds are allowed per attempt. Failed repeatable checks can be explicitly requested again within existing limits; assertion failures remain failures and are not retried automatically. The full stdout and stderr stay in the local log; the user-facing report shows only the conclusions and the necessary summaries. Long output is truncated in the preview, but a valid check is not failed just because the log is long.

​
The repair loop has an explicit limit

The Runtime measures progress by whether the unresolved acceptance items truly decreased. Progress only counts as reliable when the current round has fewer unresolved items than the previous round and no new unresolved items appeared.
  • After two consecutive rounds without reliable progress, the Runtime asks the Builder to change its repair approach.
  • After three consecutive rounds without progress, the flow enters await-user.
  • When the failed acceptance rounds reach native.max_verify_failures, the flow enters await-user. The default limit is 5.
  • When the Verifier fails to execute 3 times in a row, the flow enters blocked and waits for an explicit retry action.
The Runtime updates all of these counters. Repeating the same command, rewording the description, or reporting the same cause again does not reset the failure history. Continue reading Native Loop for the full Build ↔ Verify loop. Then read Continuous advancement and Recovery playbook for how state advances and how exceptions are recovered.
Last modified on October 3, 2026