Change an existing feature

Changing an existing feature requires stronger preservation rules than creating an isolated new area. The agent must understand how the feature currently works before proposing edits.

Inspect the implementation first

Read the smallest relevant set of files and identify:

• entry points and public behaviour;
• existing methods, services, utilities and guards;
• validation, error handling and state-management patterns;
• tests and manual checks already used for the feature;
• developer changes already present in the working tree;
• callers and neighbouring behaviour that must remain stable.

Contract the delta, not a replacement design

The Task Contract should describe the required behavioural difference and the minimal allowed edit surface. It must identify working behaviour to preserve.

A theoretically cleaner implementation is not authorization to rewrite the feature.

Implement preservation-first

Prefer, in order:

1. reuse of existing methods and abstractions;
2. a local addition that follows nearby patterns;
3. the smallest adjustment required to existing logic;
4. a separate explicit refactoring task when structural change is genuinely needed.

Do not merge functions, rename broad APIs, replace libraries, reorganize folders or modernize syntax unless the approved task requires it.

Integrate developer edits

If the developer changes the feature during the task, re-read the current files and adapt the remaining work. Never restore the agent’s earlier version over newer human changes.

Verify the affected behaviour

Use targeted tests, build checks and manual verification appropriate to the existing project. Check both the requested new behaviour and the preserved behaviour most likely to regress.

Report collateral issues separately rather than fixing them opportunistically.