flowchart TD
    Request --> Auth[Validate access token]
    Auth --> Org[Match organization_id]
    Org --> Role{Required role?}
    Role -->|No| Deny[403]
    Role -->|Yes| Team{Team scope required?}
    Team -->|Mismatch| Hide[404 scoped resource]
    Team --> Assignment{Farm/flock assignment required?}
    Assignment -->|Missing| Hide
    Assignment -->|Allowed| UseCase[Execute use case]
    UseCase --> Audit[Write audit trail]

Frontend visibility is a usability feature only. Backend dependencies and scope resolvers enforce access for every protected operation.

• Passwords use Argon2 through pwdlib.
• Access tokens are short-lived JWTs.
• Refresh tokens are rotated, hashed before storage, revocable, and expire independently.
• Logout revokes the current refresh-token family.
• Production secrets must come from the platform's secret manager.

Operational queries begin with organization_id. Team and farm assignment restrictions are then applied by role. Tests cover cross-organization, cross-team, and unauthorized farm access.

PostgreSQL row-level security is a possible defense-in-depth roadmap item; it is not claimed as active in this repository.

Meta webhook requests use HMAC-SHA256 validation. Provider message IDs are unique. Payload hashes, timestamps, persisted raw payloads, and processing status support replay analysis and idempotent processing.

• Maximum upload size is configurable.
• Magic bytes and detected MIME type are checked.
• Allowed formats are explicit.
• Object keys are generated rather than trusted from filenames.
• Buckets remain private.
• Access uses time-limited signed URLs.
• Original files and SHA-256 hashes are preserved.
• Automatic image diagnosis is not implemented.

Malware scanning and content-disarm services are recommended before production use.

Structured logs include correlation IDs and operational identifiers but exclude passwords, JWTs, refresh tokens, private keys, access tokens, and full sensitive message content. Audit logs record relevant state changes without replacing application revision tables.

A real deployment must define and document:

• purpose and legal basis for each personal-data category;
• minimization of user, phone, media, and message data;
• role-based need-to-know access;
• retention and deletion schedules;
• user rights and request handling;
• consent where legally required;
• processor/subprocessor agreements;
• incident response and breach notification;
• backup, restoration, and irreversible deletion behavior.

The demonstration does not constitute a complete LGPD compliance program.