Summary

Add an optional model-declared encryption metadata layer (approach B) that assembles the encryptedFieldsMap from class attributes, as a compatible extension on top of the configuration-driven approach (approach A, the v1 default).

Details* A model declares its encrypted fields with an attribute, for example #[EncryptedFields(field => mapping)], mirroring Doctrine ODM.

• The configuration lists the model classes to encrypt, so the package does not scan the whole application to discover them.
• The assembled encryptedFieldsMap replaces the hand-written config map. Approach A stays the default; this is a compatible future extension and changes only where the map comes from.

Key concerns

• Model class detection: Laravel has no native registry of model classes. Use the explicit class list in the config, or a filesystem or classmap scan. The explicit list avoids loading the whole application.
• Runtime performance: loading and reflecting the listed model classes before the application is initialized can have autoload side effects. The detection and map assembly must be cached and cheap, and the cost must be documented.
• Composition: per-model metadata must compose with safeContent hiding and the native encrypted cast.

Related

• Epic: [PHPLARA-50|https://jira.mongodb.org/browse/PHPLARA-50]
• Scope: [Queryable Encryption in Laravel|https://docs.google.com/document/d/1d5rHlUQQBk8oG3xAKX58uKTLAmuT8CUBfTyZknVDvjE/edit?tab=t.eyxusmsiv22h]