Preservation-first

Preservation-first is the default rule for changing software that already exists. It means the agent must understand and extend the working implementation rather than replacing it with the implementation it would have chosen in isolation.

The principle protects behaviour, architecture, local knowledge and developer work. It also keeps the requested task reviewable by preventing unrelated improvements from becoming mixed with the authorized change.

Use the project’s existing implementation vocabulary

Before writing new code in an implemented area, the agent should identify how nearby code already solves comparable problems. Relevant elements can include:

• existing functions, methods and service boundaries;
• shared utilities and helper modules;
• validations, guards and permission checks;
• error-handling and logging conventions;
• dependency-injection, state-management and data-access patterns;
• naming, typing and folder conventions;
• existing tests, fixtures and verification commands;
• public interfaces and behaviours relied upon by other code.

New code should reuse or compose these elements where they are appropriate. The objective is not to imitate superficial formatting; it is to make the change behave as a coherent part of the existing software.

Local consistency takes priority over an unsolicited “better” solution

An AI model may know a newer API, a more fashionable abstraction or a theoretically cleaner architecture. That knowledge can be useful when the developer asks for an architectural decision or refactor. It is not automatic authorization to replace a working local approach.

For an ordinary feature change or bug fix, the agent follows the established implementation pattern even when another approach could be argued to be better in a greenfield project. Differences can be reported as observations, but they remain outside the implementation unless explicitly authorized.

Add what is required; do not rewrite what already works

The agent should add or minimally adjust the instructions, branches, calls, types and tests necessary to achieve the requested behaviour.

It must not, merely because it is editing the area:

• merge several working functions into a preferred abstraction;
• rewrite a method for style or brevity;
• optimize code without an identified requirement;
• rename unrelated symbols;
• reorganize modules or folders;
• replace local utilities with newly generated helpers;
• modernize syntax across the surrounding file;
• remove guards or validations that appear redundant without proving their purpose.

These changes increase the review surface and can destroy constraints encoded by the project’s history.

Preserve developer edits and uncertain-origin changes

Changes made manually by the developer are current project state, not noise to be overwritten. Before modifying a file, the agent must re-read it and integrate with what is now present.

When the origin of an existing change is uncertain, the safe default is preservation. The agent should not restore a previous snapshot, discard a diff or reconstruct the file from memory unless the developer explicitly authorizes that destructive action.

Preserve behaviour, not accidental defects

Preservation-first does not require retaining a bug that the task is intended to fix. The preserved baseline consists of behaviour and constraints outside the authorized change.

A bug fix can change the defective branch while retaining surrounding validations, interfaces and unrelated behaviour. The Task Contract should make the intended behavioural difference explicit so that “preserve” and “change” are not left to interpretation.

Minimal change is architectural, not numerical

A preservation-first implementation is not judged by the smallest number of edited lines. Sometimes the project’s existing architecture requires coordinated changes in an API, service, UI and test.

The correct surface is the smallest coherent surface that satisfies the task while preserving unrelated behaviour. Artificially forcing the change into one file can be as inconsistent as rewriting too much.

Refactoring remains possible

TCAF does not prohibit refactoring, modernization or architectural improvement. It separates them from unrelated work.

A refactor is appropriate when it is:

1. the explicit objective of the task;
2. required to make the requested behaviour possible and documented in the contract;
3. separately proposed and approved after the current task;
4. necessary to resolve a blocker that the developer accepts as an amendment.

In each case, the broader surface becomes visible and reviewable instead of entering as an opportunistic side effect.

Greenfield work still uses preservation-first once a baseline exists

A new project initially has fewer local constraints. As soon as architecture, conventions, utilities and working features are established, subsequent tasks should treat them as the current baseline.

This prevents every new AI session from reinventing the project and allows the codebase to develop a stable internal language.

What the Task Contract should record

For changes in implemented areas, the contract should make the preservation boundary concrete. Depending on the task, it can identify:

• existing methods or utilities that must be reused;
• files or behaviours that must remain unchanged;
• validations and guards that must be retained;
• developer edits already present;
• prohibited refactors or dependency changes;
• the exact behavioural delta requested;
• checks that demonstrate preserved and new behaviour.

The principle then becomes testable rather than remaining a general instruction to “be careful”.