Skip to main content
Native can promote multiple changes simultaneously. Each Change has its own requirements, acceptance status, branches, and working directories, and the Runtime is responsible for maintaining these boundaries. Agents can thus be implemented in parallel, and users can restore any one of the changes at any time, while avoiding writing code, status, or verification results to incorrect tasks. Parallel protection is divided into two layers: worktree isolates uncommitted code, and Spec conflict checking protects formal requirements. The former addresses “where the code is written”, while the latter addresses “in what order should multiple changes update the same Spec simultaneously”.

​
Change organizational mode

The relationship between the goals determines how the Change is organized: Supervisor Change is responsible for child splitting and integration within a large target. This page focuses on how multiple independent changes can advance in parallel within the same repository.

​
Automatic workspace isolation

When you say “parallel processing”, “simultaneous advancement” or “completed with multiple sessions”, Native will directly select worktree for the new Change. Each Change acquires an independent branch and working directory. Once created, the Agent will enter the preparation.projectRoot returned by the Runtime to continue working. This process will reuse existing resources in combination with the current status of the warehouse:
  • When the registered worktree matches the Change branch, continue to use the original directory.
  • When the branch still exists and the original worktree has been removed, the Runtime rebuilds the working directory.
  • When a branch is renamed, taken over by another task, or its affiliation cannot be confirmed, the Runtime pauses and requests rebinding.
When the user has not specified the parallel mode, Native will decide to directly use the current directory based on whether there are uncommitted jobs and active changes in the current directory, or ask you to choose among current, branch and worktree.

​
Change Workspace binding

The Runtime will save the isolation method, Change branch, target branch and working directory binding for Change. This information will be rechecked before subsequent writing. When the current branch, directory type, or project root does not match the record, Change enters a waiting state and returns the correct working directory. This binding can prevent several common types of errors:
  • Continue to modify the changes that originally belonged to the linked worktree in the main workspace;
  • After switching to another branch, the state of the old Change is continued.
  • Copy the command from the old dialogue and continue building or archiving in the error directory;
  • Two working directories simultaneously claim to be valid locations for the same Change.
Even if the platform still passes in the main directory of the repository, Native will recognize the current actual linked worktree and leave the operation in the corresponding directory. When there are multiple bindings that match each other, the Runtime will report ambiguity and allow the user to decide which source to retain.

​
Discovery and recovery across workspaces

When restoring, Native will scan the Git registered worktree, read the project configuration and Change status in each directory, and then prioritize the results with consistent workspace bindings. You can start from any registered working directory in the repository. The Agent will find the actual location of the Change and then continue there. Therefore, when switching sessions or reopening a project, the Change status on the disk and the workspace binding jointly provide the basis for recovery. Users only participate in the selection when multiple candidates are reasonable, the binding has drifted, or the original branch affiliation has changed. To view all changes and their actual directories, you can run:
These commands are used to check the status. Normal recovery is automatically completed by Native.

​
Spec Conflict Detection

Each Spec describes a complete set of product behaviors, such as authentication, billing or notification. The certification Spec can be saved in specs/authentication/spec.md. Each Change will declare in comet-state.yaml which Spec it intends to create, modify or delete. Before archiving, the Runtime scans all active changes in the registered worktree to identify those that simultaneously modify the same Spec. This check focuses on product semantics. Even if two changes modify different code files, as long as both are ready to update the official Spec authentication, there will be a conflict in the archiving sequence. On the contrary, modifying the changes of authentication and billing respectively can continue to perform parallel Build and Verify, and then undergo normal Git integration checks upon final delivery. This enables conflicts to be exposed before canonical Spec updates, usually earlier than Git conflict tags. The team can first handle the sequence of product behaviors and then deal with code integration in the final delivery.

​
Spec archiving sequence

When multiple active changes declare the same Spec, the Runtime will pause in the Archive and list the related changes. Please decide which one to archive first. This choice determines the sequence of Spec updates, and the work already completed by both parties remains in their respective changes. Update the canonical Spec with the first archived Change. The subsequent Change re-reads the latest Spec, aligns its own target with the new baseline, and then completes the required implementation and acceptance. The Verify result before the conflict only proves the behavior under the old baseline, while the result after re-alignment requires new evidence. For example, both add-session-expiry and support-passkeys modify authentication:
  1. The two changes are independently built and verified in their respective worktrees;
  2. Archive found that they jointly declared authentication;
  3. You choose to file add-session-expiry first;
  4. support-passkeys aligning based on the updated certification Spec and then continuing to Archive.

​
Requirements and acceptance drift protection

Archive will also recalculate the target Spec and acceptance items currently declared by Change and compare them with the content saved at the time of Shape confirmation. When the Spec declaration, acceptance text, or coverage relationship changes, the Runtime will return the Change to the Shape, update the requirements, and reconfirm. This check distinguishes the requirement drift caused by parallel modifications from ordinary implementation changes. The code can continue to evolve, but changes in formal requirements and acceptance boundaries need to be reconfirmed. The old verification report should also be consistent with the current status version.

​
User decision boundary

In daily parallel processes, Native handles worktree creation, reuse, state discovery, and binding checks. Users mainly make decisions at three locations:
  • When creating requirements, specify whether they belong to the same overall goal or several independent goals.
  • When there is a real ambiguity regarding the ownership of the workspace, confirm the correct directory or branch.
  • When multiple changes declare the same Spec, determine the Archive order.
Git conflicts at the code level are still resolved based on the actual content of the repository. Native retains the requirements, status, and acceptance records of each Change, allowing for the return to the correct task to continue verification after conflict resolution is completed. Continue reading: Supervisor Change, Products and Status , Safety and Recovery and Recovery and Fault Handling .
Last modified on September 4, 2026