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. Comet RC1 builds its conclusion on three layers of verification: a new read-only Reviewer Subagent first reviews the candidate implementation, the Runtime then runs the necessary checks, and finally a new read-only Verifier Subagent judges each item against brief.md, the Specs, and the acceptance items. The completion conclusion can only come from acceptance; code changes happen only in the Build stage, and the Verifier stays read-only throughout.

​
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:
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 a check fails or a failed item appears, the Runtime writes the failure reasons of each item into the latest continuation and sends the current change back to Build. The Builder revises the implementation against those failure reasons and submits a candidate implementation that has gone through a new round of read-only review. For a blocked item, the Runtime waits for the user or external conditions first; it does not treat missing information as a code defect and modify the code on its own. The acceptance scope of each repair round consists of two parts:
  • 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.
Items that already passed and are unaffected do not need to be re-accepted in each repair round. However, once the partial scope passes, one final gate remains: the Runtime resets the complete acceptance list to pending, starts a new Verifier Subagent for the final full acceptance, and only allows archiving after it passes. This “partial fix, final full confirmation” approach reduces repeated work while guarding against a new regression that a fix for one issue could introduce.

​
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

The three layers answer different questions. The Reviewer cares about code quality, the Runtime proves that the commands actually ran, and the Verifier judges whether the feature meets the requirements. The conclusions of all three layers together determine the final result.

​
A candidate implementation enters Verify with an independent review

After the Builder finishes a round of implementation, it must first start a new read-only Reviewer Subagent. The Reviewer checks the code changes of this round, the related tests, and the current acceptance scope. When it finds problems, the Builder fixes them and the code must be reviewed again. Once the review passes, the Builder submits a concise handoff to the 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;
  • the Reviewer’s pass status, a short summary, and its execution identity.
The Reviewer’s execution identity must differ from the Builder’s. The Runtime saves the handoff to comet-state.yaml and binds it to the candidate ID, the iteration, and the Builder identity. A handoff is only the recorded state of a candidate awaiting acceptance, not proof that it 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. The first Verify covers all acceptance items; a repair round covers only the items left unresolved from the previous round and those the current change may affect.
  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. verifierDispatch provides the actual workspace, the location of the requirements and evidence, the current scopeIds, the Reviewer summary, and the Runtime check results.
  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 late stale results are all rejected by the Runtime. As long as any Runtime check still fails, the Verifier cannot submit an overall pass.

​
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 add an attempt on their own. The Runtime reuses the checks the current candidate has already completed, filters duplicate requests, and returns the new results to the same Verifier. RC1 provides at most 2 rounds of supplementary checks per attempt, so an acceptance cannot keep appending commands without limit. 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 September 4, 2026