edit operation

There are four kinds, and the list is deliberately short — create a file with this content, replace this text in that file, delete this path, rename this to that.

What makes them useful is what they are not. They are not shell commands, and they are not a model with write access to a disk. The model returns a list of proposed operations and can do nothing else; it has no filesystem and no network. Every capability it appears to have is a capability the executor has, which means the boundary is somewhere you can audit rather than somewhere you have to trust.

The executor validates each path in the list against an allowlist, then applies the whole list as one unit. If any operation is invalid, none are applied. That atomicity is the point: a project is never left half-way through a change, which is the state that makes a codebase impossible to reason about and impossible to roll back cleanly.

It also makes repair tractable. A failed verification chain produces a diagnostic against a known set of applied operations, so the repair loop is correcting a specific, recorded change rather than guessing at the state of a directory.