Laravel Traits

• Cuando una lógica se reutiliza entre clases, colócala en un Trait
• Nada de lógica copiada/pegada, nada de duplicación entre componentes
• Un trait es para comportamiento que opera sobre $this. Una función pura que solo transforma sus argumentos — da formato o normaliza un valor — debe ir en un helper, porque un trait la convertiría en un método de cada clase que lo use
• Ubicación del trait según el tipo:
  • Traits de Model → app/Traits/ (App\Traits)
  • Traits de Livewire → app/Livewire/Traits/ (App\Livewire\Traits)
• Cuando un trait encapsula una funcionalidad, mantén esa funcionalidad autocontenida: propiedades, relaciones, scopes, métodos y cualquier registro de observer propio del trait mediante bootTraitName(). Los observers específicos del model deben conservar solo el comportamiento exclusivo de ese model.
• Nombra un trait de funcionalidad según la funcionalidad que encapsula — HasReferrals para la funcionalidad de referidos — y úsalo en el model al que pertenece esa funcionalidad.
• Extrae traits de funcionalidad solo para funcionalidades que un model tiene, pero no que es. No muevas los métodos de dominio propios de un model a un trait solo para cumplir con la cantidad.

• Cuando un trait contiene métodos de más de una sección, los comentarios de sección deben estar presentes (la división). Los comentarios de sección son opcionales solo cuando el trait tiene una sola sección. La redacción es libre, como en los modelos, dentro del mismo límite: como máximo cuatro palabras que nombren el grupo, sin punto final. Lo que se comprueba es que haya un comentario encima del primer método de cada sección, escrito en formato multilínea /* */.
• El orden es relativo, no obligatorio: Funciones estáticas → Funciones → Scopes → Relationships → Attributes. Solo debe fallar cuando los métodos que realmente existen estén fuera de orden; nunca debe fallar porque falte una sección.
• Las propiedades se declaran al principio del trait, antes de cualquier método.
• Los accessors y mutators en un trait pertenecen a la sección Attributes: un mutator como setPinAttribute() no debe ir bajo Functions, incluso cuando sea el único método de atributo del trait.
• Un comentario de sección se aplica a todos los métodos siguientes hasta el siguiente comentario de sección o el final del trait. No exijas que los accessors/mutators estén físicamente dentro de un bloque de comentario; los comentarios de PHP son marcadores, no envoltorios.
• Si la respuesta determina que un orden de secciones está permitido, debe aprobar ese punto. No enumeres observaciones de orden permitido como fallos.

Un método de relación devuelve una query que el caller sigue moldeando; no debe persistir nada. No llames a firstOrCreate(), create(), updateOrCreate() ni save() dentro de un método de relación. Cuando un registro deba existir antes de poder leer la relación, materialízalo en un método explícito con nombre (p. ej. ensureBillingAccount()) que los callers invoquen cuando estén por escribir, y deja la relación como una query pura. Cuando un paquete no está, devuelve una relación vacía neutra en lugar de escribir un registro fallback.