Storage Path Rules

FATAL Constraints

• NEVER allow a storage path containing .., ./, or // to pass validation. Any such path MUST be rejected immediately.
• NEVER create a storage RLS policy that omits the tenant-prefix check. Every row-level policy on storage.objects MUST enforce auth.uid() scoping.
• NEVER set a bucket to public: true when it holds tenant-specific data. HALT and ask the operator before proceeding.
• NEVER use SECURITY INVOKER for the path validation function. It MUST be SECURITY DEFINER.

Mandatory Behaviors

• Every private bucket MUST have INSERT, SELECT, and DELETE RLS policies that call storage.validate_path().
• Path validation MUST run inside Postgres (not in application code alone). Client-side checks are supplementary, not authoritative.
• Bucket folder structure MUST follow {tenant_id}/{category}/{filename} pattern. Flat or unscoped layouts are forbidden.
• When a new bucket is added to the project, the agent MUST immediately scaffold RLS policies for it before any other storage work proceeds.
• The storage.validate_path function MUST be idempotent -- re-running the migration MUST NOT produce errors or duplicate objects.