Isolation with worktrees

A worktree is a second working folder linked to the same Git repository. HelmIt can use one to experiment or develop a change without mixing its files with work in the main project. This isolation is optional: for most tasks, the agent works directly in the open project.

When the agent chooses isolation

At the start of implementing a task, the agent decides whether to work directly in the project or open a temporary worktree. It makes that choice before starting a change that needs isolation or delegating parallel work. If a risk appears during execution, it can reconsider. You do not need to choose the mechanism: describe the outcome you want and any constraints you wish to set.

The agent is likely to isolate an experiment that may be discarded, a risky migration that needs separate evaluation, or two independent pieces of work running in parallel. Several tasks in a plan do not, by themselves, justify a worktree: setup and integration also take time.

TWO WAYS TO WORK The agent chooses how to work

Main project Before editing or delegating, it checks whether isolation is needed.

Work directly The normal path for sequential tasks.

Temporary worktree Used when separating files and changes helps.

Review, integrate, and prove Useful work enters the project; the temporary worktree is removed.

The diagram shows two ways to carry out a change. On the isolated path, the agent reviews the differences before integrating the result. A delegated executor never commits to the user’s branch; the agent responsible for delivery coordinates commits and integration. Neither path changes task or requirement traceability.

What stays separate

The worktree carries versioned project files, but not HelmIt’s temporary session state. This keeps two agents from competing over the same execution record. An agent receiving isolated work needs the expected outcome, relevant context, and a way to verify its part.

A worktree protects the main project from local changes made in that other folder. It does not isolate the entire computer: absolute paths, network access, databases, and external services remain subject to the same access and authorization rules.

Proof uses a different kind of isolation

Even when implementation happens directly in the project, HelmIt creates short-lived worktrees to run checks against the exact content being recorded. At task completion, proof uses the content staged for the commit; at integration and ship, it uses committed content. Repository-relative test and build output stays out of your working folder and is discarded after the checks.

Every logical commit crosses the independent Git floor. A complete suite runs at integration when dependency convergence or risk justifies it, and always for final delivery proof. Choosing a worktree for implementation does not change those checks.