Native stores requirements, complete target specifications, current progress, and acceptance conclusions in the project. After completing each phase, it returns to the Runtime to read the next step, and currently only processes the phase specified by the Runtime.

First determine the lowercase kebab-case name, then decide whether to use the current directory, create a branch, or create a worktree according to the Workspace Selection Reference.

The CLI will complete branch or worktree binding, maintain repository local exclusion rules, check the configuration, and create a state that can be restored across devices. Then enter the returned by the command.

If the preparation is not completed, retain the already created resources, display the failure reason in , and continue according to the recovery direction given by the Runtime or user.

After confirming the phase, only read the required reference:

First investigate the facts that can be determined from the repository, tools, and operating environment; independent facts can be assigned to subagents for investigation. Maintain the decision tree according to and the Clarification Reference, and only hand over decisions that will change user-visible results and cannot be reliably inferred to the user.

Immediately synchronize the confirmed user-visible decisions and important constraints to Decisions, brief, and complete target specifications; keep ordinary implementation choices in implementation and testing, and only enter formal requirements when they affect user-visible behavior. Acceptance items must be specific, observable, and non-repetitive.

Unresolved issues remain marked as ; do not modify the project implementation when there are blocking items. Completion criteria: All choices that affect user-visible results and unstated assumptions have been processed, there are no items, the user explicitly confirms the goal, scope, key decisions, acceptance items, and non-goals, and the Runtime has entered Build. Only use commands with in subsequent instructions to advance after the user explicitly confirms.

Build and Verify form a bounded acceptance loop: Builder submits candidates, Runtime performs necessary checks, and then a new read-only Verifier conducts acceptance. When acceptance fails, return to Build, complete modifications, and submit the next round of candidates; when all items pass, enter Archive.

represents the round of implementation candidates, and represents the number of times Verifier is started for the same candidate. When consecutive failures occur, there is no actual progress, or Verifier execution errors occur multiple times, Runtime will enter a waiting for user or blocked state at the budget upper limit. All counts are updated by Runtime, and Agent only executes the latest .

When implementing for the first time, read the current brief, complete target specifications, and all acceptance items. If Verify fails and returns to Build, first handle the failed items pointed out by Verifier, problems that prevent continued verification, and failed checks; recheck the complete specifications and all acceptance items before submitting again to avoid only fixing error points and missing other requirements.

When requirements change, first determine the attribution:

When the user explicitly supplements the current scope, handle it according to the same rules.

After completing the candidate, submit a streamlined Builder handoff summary according to the input template provided by Runtime in , including: what was done in this round, which acceptance items were handled, which development-phase checks were actually run or not run, and what known limitations remain.

This handoff is stored in , does not generate a separate file, and does not mean acceptance has been passed. Runtime will hand it over to Verifier, and Builder only needs to submit it once.

Completion criteria: The implementation and related checks reach an acceptable state, all acceptance items have been rechecked, and Runtime accepts the handoff and enters Verify.

When Runtime requires starting the Verifier (), first fill the test and check commands that need to be run for the current candidate into , and Runtime will execute them uniformly. Runtime will reuse completed checks; whether to retry or supplement checks is subject to the latest .

After Runtime returns , immediately start a new read-only Verifier subagent. If the platform does not support subagents, start a new Agent task separate from the Builder session.

Verifier first reads the acceptance items, brief, complete target Spec, actual implementation, and Runtime check results, and finally uses the Builder handoff as an investigation clue to maintain independent acceptance judgments.

Verifier remains read-only. If existing checks are insufficient, list the additional checks that need to be run in returned by Runtime, and Runtime will execute them and return the results to Verifier.

Verifier must finally mark each item as , , or , with no omissions or duplicates. When items fail or cannot be verified, write the reasons that can be directly handled in the next round of Build. When Verifier cannot be started, Verifier execution errors occur, or external information is missing, handle according to the Command Reference and latest .

Completion criteria: Runtime has accepted the complete Verifier results and clearly enters one of the states: Build, Archive, , , or .

Only continue when allows Archive. Archive directly uses the accepted acceptance results. When or requires finishing choices, display the actual change branch, target branch, and directory at once, and let the user choose to merge, push, create a PR, keep the workspace, or postpone archiving.

Only submit the implementation and official artifacts belonging to the current change, and retain other user modifications. Execute the returned by Runtime, then check the workspace finishing result ; if the result is , retain the scene and execute the recovery command in .

Completion criteria: The status is , and the user-authorized workspace finishing result is or ; handle other results according to .

Only process the latest after each command:

After executing commands that modify the status, re-query the detailed status of the change to confirm the current phase, acceptance loop, status version, and working directory. Only run when official content is needed.