Skip to main content
Common questions about the applicable scenarios of Native, the four-stage workflow, state that syncs across devices, verification, recovery, and conflict handling.

​
Basic concepts

When the main models are Fable 5, GPT-5.6 and other strong models of the same level, Native should be given priority: These models can be independently planned and implemented. Imposing methodological constraints would instead waste their capabilities. Native leaves the choice of methods to it and only locks in the results and evidence. When the model capability profile is lower and more explicit process constraints are required, Classic is used. It provides five-stage governance including open, design, build, verify, and archive through OpenSpec and Superpowers. Two workflows are selected by .comet/config.yaml.
Not dependent. Native comes with Shape, Build, Verify, Archive and Runtime. Only Classic Just installed and used Classic references such as OpenSpec and Superpowers.
Builder only submits the implementation handoff. The Runtime first runs the necessary checks and then dispatches a new read-only Verifier Cover all A1… An. When the platform cannot start an independent Verifier, Comet pauses and offers two options: “retry the acceptance” (--retry-verifier, which keeps the current candidate and the checks already completed) or “accept the degraded result”. Only after accepting the degraded result can it enter Archive, and the downgrade will be indicated in the report.
Acceptance failure, inspection failure, missing Verifier items or invalid results will all be written into the next continuation and change returns Build. After the next round repairs based on failure reasons, a new Builder and a new Verifier will be adopted Start anew.
Sure. Shape and Build require synchronized briefs, Specs and comet-state.yaml;” verification.md is a reconfigurable report. Verify or archive-ready On another device, the local execution state will be reconstructed and reconfirmed, and the old local results will not be directly reused.
comet-state.yaml save stage, Loop, acceptance, handoff, check summary, Verifier Conclusion, blockage and next step are cross-device stable boundaries. .comet/runtime/native/ only saves this machine state.json, logs, locks and transactions can be rebuilt when they are missing or the versions do not match.
Batch First, the problem dependencies will be sorted out, and then the questions that are already available in the current premise will be asked again to reduce repetitive back-and-forth. Sequential It can still be configured to ask the most upstream question by round. Both need to confirm shared understanding before building.
The current Verifier requests the Runtime to execute through request-checks. Runtime It will remove duplicate equivalent plans, limit the number of request rounds and return results. Do not create a “Check receipt” by yourself or fill in “Pass” in the status file.
Sure. When creating a change, the current, branch, and worktree selections will be displayed when applicable. .comet/current-change.json only selects the next write attribution and does not limit the number of active changes. When two changes need to modify the same capability, the Archive will require a clear order.

​
Supervisor Change

Supervisor Change is suitable when an overall goal contains at least two results that can be independently implemented and verified, and unified integration and final acceptance are still required. The Runtime allocates children by acceptance items, manages dependencies and independent worktrees, and verifies the complete target after all children are integrated.Goals without a common final acceptance should create multiple independent changes. When multiple parts need to frequently modify the same core area, or when the splitting cost is higher than the parallel benefit, continue to use a single Native Change.
The advancement mode only decides where each child runs; split results, dependencies, acceptance, and integration rules stay the same in both modes. Multi-session collaboration is coordinated by the current session, with priority given to Codex independent sessions or Claude Code Agent Teams; single-session advancement is completed by the current session in sequence.When the Runtime confirms the Supervisor Shape, it saves the selection as coordination_mode. When restoring tasks or re-entering Shape due to changes in requirements, this option will be used without repeated inquiries.
Comet will first re-read the Runtime and will not determine that the child has been completed based on the residual information of the old session. When persisting to multi-session, if the independent session or Agent Team is unavailable, it will automatically switch to subagent instead of switching to a single session.Tasks that have been distributed but lost will first inactivate the old runId through supervisor-cancel, and then be redistributed using the new task package and runId. The late results of the old execution will be rejected. When the subagent is also unavailable, Comet will report a real block.

​
Recovery and troubleshooting

If the change is merely to complete the implementation of the confirmed goal, continue to Build and Verify the Loop. When changes modify the user-visible target, scope, or acceptance criteria, Native will make change return a Shape, record the new decision, and invalidate the old validation. Even if the change is archive-ready, the requirements should be reconfirmed first, and then new verification results should be obtained for the current goal.
The status can be determined first through comet status and comet native doctor <change-name>. active changes that can be migrated will be conservatively migrated according to the actions returned by the Runtime; The old version of the archive remains read-only. Do not manually move the old Runtime, modify the status file, or copy the validation records.After the upgrade, run comet update first to refresh the Skill and Runtime. comet native doctor <change-name> --repair will only be run when Doctor explicitly provides a repair action.
Run first:
Do not manually modify comet-state.yaml, .comet/current-change.json or .comet/runtime/native/. If the code, artifact root, branch/worktree are not synchronized, or the active/archive directory is mixed, the Runtime will return the specific await-user/blocked actions. The change-local Runtime, old receipt/evidence or native.snapshot configuration left by the old version is only used for migration and read-only compatibility. The newly created Portable State change in RC1 will not continue to create this old version of the ledger. Continue reading: Native Configuration , Product and Status , Verification and Repair and Recovery Manual .
Last modified on September 4, 2026