# Implementation and File Safety Contract

## Purpose

Make scoped changes while preserving user work and obtaining natural tool
feedback.

## Editing rules

- Use the workspace's approved patch/edit mechanism for source modifications.
- Make the smallest coherent change that satisfies the observed contract.
- Preserve unrelated edits and avoid repository-wide mechanical rewrites unless
  the task explicitly requires them.
- Do not use destructive reset, checkout, or broad deletion operations without
  explicit authorization.
- Keep mutations atomic where practical: grouped edits should either all apply
  or report the exact conflict.

## Natural edit safety

Tool-level safeguards are useful when they report real filesystem state:

- Exact old-text matching prevents accidental replacement of the wrong target.
- An available file hash can provide compare-and-swap protection.
- An explicit stale hash or missing text is evidence that the target changed or
  the premise was wrong.

Runner/controller policy should not replace these natural outcomes with
synthetic admission failures. The model needs the actual tool result in order
to revise its hypothesis.

## Mutation evidence

After a mutation, record or retain:

- affected paths;
- before/after identity when available;
- the exact tool result;
- which previously successful verification is now stale;
- the next meaningful proof check.