Document database SQL release workflow

README.md

@@ -56,7 +56,7 @@ Run one container with one Python worker: analysis jobs and retry payloads are i
 
 The production database must have the analysis functions and action-review structures used by secret-protected `/internal/analysis` routes. The database also needs the profile columns shown in `../Database/schema.sql` and a private `profile-images` Supabase Storage bucket for JPG, PNG, and WEBP files up to 4 MB. The frontend resizes profile photos to at most 1280 pixels and encodes them as WebP before upload. The backend reads and writes images through its service-role client; browsers access them through authenticated API routes with private, versioned browser caching.
 
-Before deploying access-control or deletion changes, run [`../Database/updates/access-permissions.sql`](../Database/updates/access-permissions.sql) in the Supabase SQL Editor. Apply the Auth profile-link and public-table security SQL supplied in the release conversation; it stops if orphaned profile rows exist. These database changes do not replace the ownership and admin checks required on every Backend service-role route. The full policy is documented in [`../Database/access-permissions.md`](../Database/access-permissions.md).
+For existing Supabase projects, apply the database SQL supplied in the chat for each update. The full schema is maintained in [`../Database/schema.sql`](../Database/schema.sql), and the access rules are documented in [`../Database/access-permissions.md`](../Database/access-permissions.md). Database RLS does not replace the ownership and admin checks required on every Backend service-role route.
 
 To remove the unused `players.dominant_foot` and `players.notes` columns from an existing database, apply `../Database/migrations/20261017_remove_player_dominant_foot_notes.sql` in the Supabase SQL Editor.