We're auditing a Symfony MessageController. The CRUD looks standard — create, update, delete, list. We start reviewing the code, noting security issues, fat controllers, missing validations. And then we open the Message entity.
The broadcast field is a string with values "Y" and "N". The type field is an int with no enum, magic numbers scattered across the controller. The title field in PHP is called titre in the database. And that's when the real question hits: are we auditing the controller, or are we auditing the entity?
If we fix the controller now, we'll write code that checks broadcast === "Y". When we fix the entity later to use a bool, we'll have to come back and touch this controller again. Same code, audited twice, modified twice. That's exactly what we want to avoid.
The three possible orders
Facing a legacy Symfony project with 15 entities, 20 controllers, a handful of services and listeners, there are three ways to organize an audit. None is universally bad — but only one avoids the systematic rework trap.
