Feature implementation

Code that works but does not belong is a defect with a delayed cost. The job is not only to make the behaviour exist — it is to make the change look like it was always there, so the next person reads one codebase instead of a pile of visitors' styles.

The failure this prevents: writing correct code in your own idiom, in the wrong layer, with a new pattern the project did not need.

1. Read before writing

Find the closest existing thing to what you are about to build and read it properly. Not skimming for API names — reading for how this project does its work:

• Where does this kind of code live, and what is it named?
• How are errors raised and handled — exceptions, result types, error returns?
• How is state accessed? Is there a repository layer, a service layer, direct queries?
• How are things configured, logged, validated, and tested here?
• What is imported from where, and what is deliberately not?