Incidents — Avoca production signals

Running log of Avoca-side incidents and signals visible from Slack and the codebase that affect Lazer's posture. Newest on top. The purpose: know what's going on, protect ourselves from blast-radius surprises, and have something concrete to reference when communicating with the Lazer team.

TLDR (last 36h)

• Strict-RLS migration #10049 created broad blast radius. Locked members to service_role only, silently broke every team-scoped policy that delegates to allow_if_team_member(). ~13 downstream PRs migrated user-session writes onto API + service client. Twilio brand-onboarding was the loudest casualty (orphan Twilio subaccounts on retry). Saba named the pattern explicitly. Bharat publicly critiqued the rollout's comms. See strict-RLS migration.
• PostgREST FK ambiguity on service_areas → teams. Migration 20260508120003 added a second FK (route_to_team_id); teams ... service_areas(*) embeds broke until PR #10202 disambiguated getTypeData. Latent pattern across other embeds not yet swept. See PostgREST FK ambiguity.
• Public Supabase buckets under governance review. 8 public buckets surfaced; owners identified; direction = signed-URL proxy. No code change yet. See public bucket posture.

Why these matter to us

• Every gated write we ship should mirror the API + service-client pattern, not user-session through a server action.
• Treat implicit-FK embedded selects as a latent bug; prefer table!fk_name(*) syntax in any embed against a table that has more than one FK to the parent.
• Bucket posture is the security thread to watch if our work ever touches Supabase Storage (hold-music, voice samples, customer assets).

Incidents (newest first)

Date	Incident	Status
2026-05-11	Strict-RLS migration blast radius	sweep in progress
2026-05-11	PostgREST FK ambiguity (service_areas → teams)	fixed; latent risk
2026-05-11	Public Supabase bucket posture	governance review

Adjacent signals (watchlist)

Not full incidents, but worth tracking:

• AutoOps schema role reassignment (2026-05-11, Jackson). Reassigning autoops_* tables from avoca-api role to postgres. Our lane (reschedule/cancel writes against autoops_team_configs etc.). Reportedly non-disruptive. Worth confirming no avoca-api-specific grant is load-bearing for our writes after the reassignment lands.
• incident.io as canonical incident channel (Christian). Proposal: create incidents early from any convenient surface, consolidate comms in the auto-created channel, auto-post heads-up to #product-support. Suggested bar: more than a handful of teams affected, real user impact, not yet resolved. If we trigger or witness an incident inside this environment, that's the channel norm.
• Two Supabase migrations directories in avoca-next. supabase/migrations/ at the repo root and apps/web/supabase/migrations/. Schema history lives across both; grep both when investigating.
• Disabled triggers cleanup (Jackson, 2026-05-12). on_invite_accepted and the four create_business_unit_mappings_trigger triggers on appointment_types, residence_types, service_types, service_areas. All currently disabled. Not our lane unless business_unit_maps ends up in our scope.

Conventions

• Each incident gets one page named YYYY-MM-DD-<short-slug>.md. Stable URL, shareable in Slack.
• Intel-brief depth (not forensic). Sections: what happened, why we care, the fix, what to mirror.
• Adjacent signals stay in the index until they graduate to an actual incident.