Preservation-first
Integrate requested changes with existing software without opportunistic rewrites or loss of working behavior.
Preservation-first is TCAF’s default rule for changing software that already exists:
NEW BEHAVIOR = EXISTING VERIFIED BEHAVIOR + REQUESTED DELTA
The AI should understand and extend the working implementation instead of replacing it with the solution it would have chosen in isolation.
Reuse the project’s local vocabulary
Before changing an implemented area, look for the existing pieces that already solve similar problems:
- functions, methods and service boundaries;
- shared utilities and helpers;
- validations, guards and permission checks;
- error handling and logging conventions;
- state, dependency-injection and data-access patterns;
- naming, typing and folder conventions;
- tests and verification commands;
- public interfaces used by other code.
Reuse or compose these elements when they fit the task.
Do not mix unrelated improvements into the task
A newer API or theoretically cleaner architecture can be useful when the developer asks for it. It is not automatic permission to replace a working local approach.
An ordinary feature or bug fix does not authorize unrelated renaming, modernization, dependency changes, folder moves, helper replacement or broad refactoring.
Preserve developer edits
Manual developer changes are current repository state. The AI must re-read the file before changing it and integrate with what is there now.
When the origin of an existing change is uncertain, preserve it unless the developer explicitly authorizes a destructive action.
Preserve behavior, not the bug being fixed
Preservation-first does not mean keeping the defect that the task is meant to change. The preserved baseline is the verified behavior and constraints outside the requested delta.
Minimal means coherent, not fewest lines
Sometimes one requested behavior requires coordinated changes across UI, service, API and tests. That can still be preservation-first.
The correct surface is the smallest coherent surface that satisfies the Task Contract while protecting unrelated behavior.
Refactoring is still allowed
TCAF does not prohibit refactoring. It makes the wider change explicit. Refactoring is appropriate when it is the task objective, required by the approved change, separately approved, or accepted as an amendment needed to resolve a blocker.
Once a greenfield project has established architecture and working patterns, later tasks treat that baseline the same way.