Allin — data, CRM & comms

The app calls a Supabase function called record_consent_granted every time someone completes the consent screen, and again reads/writes when someone changes a toggle in Settings → Privacy. That function did not exist anywhere in the backend — not in a migration, not deployed. The call is wrapped in a silent try?, so it failed with zero error and nobody would have noticed. There was no durable, provable record anywhere that a person had ever consented to anything, and no record of anyone withdrawing consent in Settings either.

GDPR Article 7(1) requires being able to demonstrate that someone consented — not just that the app currently behaves as if they did. The actual protection (not sending analytics/ads events if someone said no) is enforced separately, client-side, so that part was fine — this gap was specifically about having no audit trail to prove it.

A user_consents table (one row per grant/withdrawal: user id, which consent, on/off, timestamp, copy version) plus the record_consent_granted function the app already calls, plus a second function for single-toggle changes from Settings. iOS wired to call both.

Built and committed — backend branch feat/gdpr-consent-record, iOS on the release branch. Not yet deployed/pushed.

Anthropic processes real check-in and plan-intake text (memory, belief, trigger, reflection) to classify emotion/crisis risk and compose plans. Their standard terms say this isn't used to train models, but a formal signed agreement confirming that isn't in place yet. Unlike some processors, this likely needs an actual support/Console request, not just accepting a checkbox.

Marie — I can't execute this, it's a real external ask.

Supabase hosts every table Allin has, including all the special-category check-in/plan text, directly and unencrypted. Of all 8 processors on the checklist, this one holds the most, so an unconfirmed DPA here is the highest-blast-radius gap even though Supabase is infrastructure, not a "third party" in the way Segment/Amplitude feel.

Marie — check Supabase's DPA acceptance/terms directly in their dashboard or with support.

The version of recommend-plan tracked on main is FTS-only (no Anthropic call) — but the function actually running in production uses a Claude/Anthropic composition path. Whoever pushes main next, for an unrelated reason, would silently redeploy the stale FTS-only version over the correct live one, undetected, per CI's normal path-based deploy trigger.

Needs the real live source pulled and reconciled with the tracked repo before any further backend push — flagging again since it's still unresolved and it's exactly the kind of thing that gets silently broken by an unrelated commit.

The function that fans erasure out to Amplitude + Customer.io (in addition to the existing Supabase-side delete_user()) is written, committed, and confirmed to have the 4 secrets it needs already live. It's just never been deployed. Until it is, someone deleting their account today only has their Supabase data removed — Amplitude/Customer.io still hold whatever they had.

Needs your explicit go to actually deploy — this touches live infrastructure, so it's not something to bundle into "build everything."

Was "medium-high" on the original checklist specifically because of the email it used to receive — now that's fixed, the data flowing there is lower-sensitivity, but a signed DPA is still required regardless of how sensitive the data is. Worth confirming, not urgent.

Workspace 216147 is EU-region, so the usual cross-border-transfer concern may not apply at all — but that needs explicit confirmation rather than assuming, since "probably fine" isn't the same as verified.

The current secret key is legacy-format and doesn't work against RevenueCat's v2 API — needed for any direct entitlement/subscription auditing. Generate a new v2 secret key in the RevenueCat dashboard when convenient; not urgent since the webhook-based sync into user_entitlements already works independently of this.

Amplitude/Customer.io erasure work independently of this and don't need it. This only affects deleting a person's raw record inside Segment itself, and there's no accessible UI path to get these credentials in this workspace. Restating its real priority (medium, not high) rather than re-opening it — you already called this one.

Only device/advertiser id ever reaches Meta, and only when both ATT and the advertising toggle are on. No special-category data involved.

Purchases require processing subscription data as a matter of fulfilling the contract — no special-category data, lowest legal exposure of the group.