Arnas Donauskas 9c4a46d990 feat(beta): per-account beta_features flag on profiles, gating Flows ... Scaffolding for the upcoming WhatsApp Flows feature. The whole Flows stack (interactive button/list send + parse, server-side runner, no- code builder, templates) will land across the next ~4 PRs *behind* this gate so the owner can dogfood the feature on their own account before exposing it to teammates or downstream pullers of the OSS. What this lands: 1. `profiles.beta_features TEXT[] NOT NULL DEFAULT ARRAY[]::TEXT[]` — generic opt-in column, lives on the existing profiles table. Empty by default for every existing row. 2. `src/lib/flows/feature-flag.ts` — `isFlowsEnabled(profile)` predicate + `BETA_FEATURE_FLOWS` constant. Single source of truth for the gate; later PRs import this in every guarded surface (sidebar nav, /flows page, /api/flows routes, webhook dispatcher). 3. `Profile.beta_features` added to the shared TS type and the auth hook's local copy. Auth hook loads the column and defaults it to `[]` defensively if the DB read returns null. 4. 11 unit tests covering null/undefined/empty/mismatched cases, including case sensitivity (only lowercase `'flows'` opts in) and defensive guards against malformed input. How the owner enables it for their own account, once merged: UPDATE profiles SET beta_features = array_append(beta_features, 'flows') WHERE user_id = '<their-auth-uid>'; How we ship it to everyone, when ready: grep-and-delete the `isFlowsEnabled()` callsites in one cleanup PR. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-05-22 12:57:33 +03:00
..
migrations	feat(beta): per-account beta_features flag on profiles, gating Flows	2026-05-22 12:57:33 +03:00