Skip to main content
New changes use SDK Runs with local execution data in the user Comet data directory. References to .comet/runtime/native/, standalone YAML recovery, and --finish apply only to Compat. For default SDK operations, see Runtime and Archive delivery.
Just because a model can write code doesn’t mean the result meets the requirements. It may miss an acceptance item or mistake “the test command has been run” for “the function has passed”. Native Loop connects implementation to acceptance: Builder implements the requirements, Runtime controls progression and records evidence, and a fresh read-only Verifier Subagent independently evaluates brief.md, Specs, and acceptance items. A change can be archived only after necessary checks and complete acceptance pass. Each implementation round has explicit constraints: its inputs, available evidence, remaining failures or retries, and stopping conditions. The model does not iterate indefinitely.

​
The implementation and acceptance loop

An independent Verifier covers the complete acceptance scope for every formal candidate. If only a few items fail, Builder focuses on those items and any others affected by the repair. Valid checks are retained, and a new Verifier covers all criteria in one round to catch regressions in previously passing behavior. Therefore, Native Loop takes into account two things simultaneously: it does not repeat irrelevant work during the repair stage and does not lower the acceptance standards before delivery.

​
Division of responsibilities between Agent and Runtime

Builder submits a candidate implementation, not proof that it passed. Before Verify, Builder must review implementation locations, evidence, and limitations for all confirmed criteria. Missing or unfinished work remains in Build. Runtime executes necessary checks, and an independent read-only Verifier decides whether the requirements are met. Self-review does not replace independent acceptance. Verifier reads acceptance items, brief, Specs, actual implementation, and check results first. It reads Builder’s summary last as an investigative lead, reducing the influence of Builder’s own assessment.

​
The acceptance process led by Runtime

  1. Lock the candidate implementation. The Runtime records the candidate ID, the current implementation round, and the scope of this acceptance to ensure that subsequent results correspond to the correct code version.
  2. Run necessary checks. The Runtime executes test, build, or other project commands. The check results provided by Builder are only for reference and cannot replace the actual execution results of Runtime.
  3. Start the new Verifier Subagent. The Verifier checks the code in read-only mode and gives a conclusion only once for each acceptance ID within the current range.
  4. Verify the returned result. If the result contains missing items, duplicates, unknown acceptance ids, expired responses or identity mismatches, the Runtime will directly reject it and will not mistakenly mark it as passed.
  5. Decide on the next step. After the full acceptance is passed, it can be filed. Return to Build when acceptance items have failed; pause when product decisions or external information are needed and return the decision-making power to the user.
If the existing evidence is insufficient, the Verifier can request supplementary examination. The Runtime will perform checks and save the results, and then proceed with the current acceptance to prevent the Verifier from relying on guesswork to draw conclusions when there is insufficient evidence.

​
Partial repair and final full acceptance

Suppose the complete scope is A1–A8 and the first Verify fails A3 and A7. Builder focuses on A3 and A7 and checks what else the repair affects. The next Verifier still covers A1–A8.
  • Changed check inputs require fresh execution. Reuse requires valid inputs, commands, environment, and evidence.
  • Failed acceptance returns its reasons to Build.
  • Full acceptance advances to result acceptance or Archive, without another identical full verification.
This focused repair with complete independent acceptance keeps regression coverage while avoiding repeated work that remains valid. Complete acceptance means all criteria for the change. See Verification and repair for the authoritative rules. Within a candidate, Runtime can reuse completed checks. Verifier requests missing evidence through request-checks; Runtime executes and records those commands, limits request rounds, and filters duplicates. Full logs stay local; the user report presents conclusions and relevant summaries.

​
Progress counters: iteration and attempt

The Native Loop uses two dimensions to locate the current progress: For instance, when the Runtime starts a new Verifier acceptance attempt for the same candidate implementation, attempt will increase, but iteration remains unchanged. The Verifier requests supplementary checks in the current attempt and does not add attempt separately. Only after the Builder modifies the code and submits a new candidate implementation will iteration proceed to the next round. An acceptance result belongs only to the execution it came from: when the Runtime records a result, it saves it together with the candidate ID, the Verifier that performed the acceptance, the iteration and attempt at the time, and the acceptance scope. So when a slow old task returns its result very late and it does not match the current state, the Runtime does not adopt it. Long-running tasks, recovery from interruption, and parallel execution all rely on this rule to keep state from being overwritten by old results.

​
Progress judgment based on unresolved acceptance items

The Runtime does not assume that progress has been made just because “a lot of code has been changed this time”. It will compare the acceptance items that remain unresolved for two consecutive rounds: only when the unresolved items are indeed reduced and no new unresolved items are added can it be considered that reliable progress has been made. In set terms, the current unresolved items must form a strict subset of the previous round. The Runtime records the following counts:
  • no_progress_count: The number of times that have not been strictly reduced for unresolved acceptance.
  • failed_iteration_count: Realize the rounds that have not passed the acceptance.
  • execution_failure_count: The number of times the Verifier task itself fails to execute.
When there is no reliable progress for two consecutive rounds, the Runtime will require the Builder to adopt a different approach to the repair. If there is still no progress in the third round, the Loop will be paused, allowing the user to decide on the next step. The number of failed acceptance rounds is also subject to the native.max_verify_failures limit, with a default maximum of 5 rounds. Failed acceptance and Verifier execution errors are recorded separately. The former means requirements are unmet or need clarification; the latter means the task did not complete normally. The Runtime permits at most 3 consecutive execution errors and 2 supplementary-check rounds per acceptance attempt. At the limit it pauses rather than retrying indefinitely or treating an error as success.

​
Fall back precisely according to the type of problem

The issues exposed by Verify are not necessarily all code errors. The Runtime will return the corresponding stage based on the type of problem:
  • Implementation omissions or code defects: go back to Build and fix the existing implementation;
  • Changes in user-visible behavior or acceptance criteria: return to Shape, update the requirements and ask the user to reconfirm;
  • New requirements that are not related to the current change: create another change to avoid expanding the current acceptance scope;
  • Lack of user decision or external conditions: enter await-user and specify what information needs to be supplemented.
In this way, Loop will not rewrite the confirmed goals at will just to “run the process smoothly”.

​
A persistent state that can be recovered across tasks

The Native Loop does not rely on a certain model and always remembers the entire context. The Runtime will save the states for different purposes separately:
  • comet-state.yaml saves a stable state that is synchronizable and recoverable, as well as the next step.
  • verification.md saves user-readable acceptance reports;
  • .comet/runtime/native/ saves the running status, logs, locks and transaction information of this machine.
After a task is interrupted or switched to another device, the Runtime will rebuild the process based on a trusted YAML state. Unfinished local tasks will be regarded as interrupted. Even if the current change has entered the “archivable” state on another device, it still needs to be re-verified after changing devices and cannot directly follow the execution conclusion on the original device. The recovery process itself will not be counted towards the number of acceptance failures or halts.

​
Automatic progression with clear boundaries

The Runtime will stop the automatic advancement in the following situations and return a clear action:
  • There are still product decisions, external conditions or blocked acceptance items that need to be handled by users.
  • The current code, branch, worktree or artifact root is inconsistent with the Runtime record;
  • There is no reliable progress, failed rounds or execution errors reaching the budget;
  • The Verifier is unavailable, or the current platform cannot prove that it is independent of the Builder.
  • When multiple parallel changes modify the same capability, the archiving sequence needs to be determined first.
Some platforms can start the Verifier but cannot prove to the Runtime that it is indeed running in an independent task. In such cases, the Runtime will truthfully mark this reliability limit and require the user to confirm the result. It will not package “has been isolated as much as possible” as “has completed independent acceptance”.

​
The core value of Native Loop

  • Credible completion criteria: Archiving depends on Runtime checks and item-by-item acceptance, rather than Builder’s own statement.
  • Independent acceptance: Builder reviews implementation and evidence, Runtime runs checks, and Verifier independently evaluates requirements.
  • Controlled repair cost: Focus on unresolved items, retain valid checks, and independently verify the complete scope.
  • Bounded execution: Stalled progress, acceptance failures, execution errors, and supplementary checks have explicit limits.
  • Recoverable progress: State is recorded on disk, stale responses are rejected, and recovery does not depend on model memory.
  • Visible limitations: Requirement changes, external blockers, or insufficient independence pause the flow with an explanation.
The model continues to be responsible for understanding and implementing what it excels at, while the Runtime transforms the delivery process into a verifiable, recoverable, and auditable workflow. Continue reading Verification and repair for the Verifier protocol and failure handling, and Task progress and interruption recovery for continuation and recovery.
Last modified on October 22, 2026