What problem does it solve? Defining Doctrine entities in OrangeHRM requires following strict project-specific conventions—flat namespaces, docblock-only annotations, table naming prefixes, external entity listeners, and a Decorator pattern—that are easy to get wrong and silently break discovery, lazy loading, or change tracking. ## Core Features & Use Cases - Entity Definition Conventions: Covers the flat OrangeHRM\Entity namespace, @ORM\Entity/@ORM\Table annotations, ohrm_ vs hs_hr_ table naming, column types, reserved-word quoting, and integer AUTO_INCREMENT IDs. - Relations & Collections: Documents ManyToOne, OneToMany, ManyToMany, and OneToOne mappings with mappedBy/inversedBy, @JoinColumn/@JoinTable, and mandatory ArrayCollection initialization in constructors. - Lifecycle & Decorator Patterns: Explains @ORM\EntityListeners for field encryption (the only lifecycle pattern used) and the DecoratorTrait + sibling Decorator class for DB-touching logic like setXById shortcuts. - Use Case: When adding a new Widget entity with an owner relation to Employee, follow the recipes to annotate the class, initialize collections, write a Decorator with setOwnerByEmpNumber, and avoid pitfalls like missing referencedColumnName="emp_number". ## Quick Start Ask the agent to create a new Doctrine entity with a ManyToOne relation to Employee following the OrangeHRM entity conventions.