# Beslissingen voor morgenochtend — TestFlight-ronde Tendlo

Elk besluit heeft dezelfde opbouw: **de vraag**, **waarom het uitmaakt**, **mijn advies**, en
**wat elke keuze betekent**. Alles is gebaseerd op de code zoals die er vandaag staat
(2026-07-25). De onderbouwing per punt staat in `appstore-privacy.md`,
`testflight-metadata.md` en `privacybeleid-concept.md`.

**Volgorde is bewust:** besluit 1 t/m 4 bepalen de rest. Als je weinig tijd hebt, doe die vier.

---

## Snel overzicht

| # | Besluit | Mijn advies |
|---|---|---|
| 1 | Interne of externe testers voor de eerste build | **Intern** |
| 2 | AI-functies aan of uit in de eerste TestFlight-build | **Aan laten, standaard uit voor de gebruiker** |
| 3 | Gezondheid: health-sync accepteren of beperken | **Accepteren + goed disclosen** |
| 4 | Financieel: welk label, en wat je belooft | **Other Financial Info aanvinken, Payment Info niet** |
| 5 | PostHog-consent: nu al waterdicht maken? | **Analytics uit in de betabuild** |
| 6 | Sentry: aan/uit, regio, omgevingslabel | **Aan laten, `SENTRY_ENV=production` meegeven, regio uitzoeken** |
| 7 | Export-encryptievrijstelling | **Vrijstelling, mits jij de tekst van Apple bevestigt** |
| 8 | Waar host je het privacybeleid | **`tendlo.app/privacybeleid/`, publiek** (let op: `/privacy` is de marketingpagina) |
| 9 | Hoe komt een Apple-reviewer de app in (magic link) | **Reviewnotitie: inloggen is optioneel** |
| 10 | Accountverwijdering: nu of later | **Later, maar vóór de App Store-inzending** |
| 11 | Plus/paywall zichtbaar in de betabuild | **Placeholderprijzen verbergen** |
| 12 | Leeftijdsclassificatie en kinderen als tester | **4+ of 12+; kinderen niet als eigen tester-account** |

---

## 1. Testen we de eerste build intern of extern?

**De vraag:** krijgen de vijf testtoestellen de build via interne distributie (geen Apple-review)
of via een externe testgroep (wél Beta App Review)?

**Waarom het uitmaakt:** intern is dezelfde dag beschikbaar en vraagt bijna geen metadata.
Extern kost een reviewronde (uren tot dagen), vereist beta-beschrijving, feedback-e-mail,
contactgegevens én een publiek bereikbare privacybeleid-URL, en stelt je app bloot aan alle
risico's uit `testflight-metadata.md` §7 (HealthKit-verantwoording, AI, placeholderprijzen,
permissieteksten). Intern testen is alleen mogelijk als je elke tester een rol geeft in je App
Store Connect-account — die mensen kunnen dan ook je app-instellingen zien.

**Mijn advies: intern.** Vijf toestellen binnen één gezin is precies waarvoor interne
distributie bedoeld is. Je ontkoppelt daarmee de technische stap (krijgt de build het toestel
op?) van de juridische stap (privacybeleid, labels, review) en kunt beide rustig doen.

**Gevolgen:**

- **Intern:** morgen te doen. Nodig: iedereen een App Store Connect-rol (Developer of Marketing
  is voldoende, en geeft de minste rechten), export-compliance beantwoorden, "What to Test"
  invullen. Privacybeleid-URL en App Privacy kun je een paar dagen later doen — maar doe App
  Privacy toch snel, want je hebt hem sowieso nodig en het dwingt de juiste keuzes af.
  Nadeel: je testers zien je account-instellingen, en je test niet het pad dat echte externe
  gebruikers straks doorlopen.
- **Extern:** realistischer generale repetitie en geen ASC-rollen nodig, maar je hebt eerst
  besluit 8 (privacy-URL), 9 (reviewer-toegang) en 11 (paywall) nodig, en je loopt het risico
  op een afwijzing die je een dag of meer kost.

---

## 2. Zitten de AI-functies in de eerste TestFlight-build?

**De vraag:** laat je de AI-capture en de assistent meegaan, verberg je ze, of laat je ze weg?

**Waarom het uitmaakt:** de AI is de enige plek waar gebruikersinhoud de EU verlaat. Foto's van
polissen, bonnen en garantiebewijzen, gedeelde tekst, opgehaalde webpagina's en je vraag aan de
assistent (mét een samenvatting van je gezinsagenda, taken, boodschappen en de namen van je
gezinsleden) gaan via je eigen Supabase-functie naar **OpenRouter in de VS**. Dat is precies
het punt dat in je eigen documentatie al openstaat: *"AI-content gaat via de proxy naar
OpenRouter — expliciet in de privacyverklaring zetten"* (`docs/OWNER-INPUTS-NEEDED.md` §5).

**Mijn advies: aan laten, want de gate is goed — maar zorg dat de disclosure klopt vóór de
build de deur uit gaat.** De verdediging is sterk: de hoofdschakelaar staat standaard uit
(`ai_settings.enabled = false` met clientdefault false), financieel en gezondheid zijn extra
uitgesloten tot je ze per onderwerp aanzet, en de AI wijzigt nooit zelf iets — je bevestigt elk
voorstel. Wat ontbreekt is één eerlijke zin in de app en in de privacyverklaring dat het naar
een Amerikaanse dienst gaat. De huidige tekst in de app noemt OpenRouter wel, maar de VS niet.

**Gevolgen:**

- **Aan laten:** je test de belangrijkste differentiator, maar je moet §6 van
  `privacybeleid-concept.md` afmaken en de VS-doorgifte benoemen. Bij externe testers hoort de
  AI-toelichting in de reviewnotities.
- **Uitzetten (bijvoorbeeld door de hoofdschakelaar te verbergen):** het privacyverhaal wordt
  simpeler en de eerste build is "veiliger", maar je test dan de functie niet die het meeste
  aandacht verdient, en je moet hem later alsnog aanzetten mét dezelfde disclosure.
- **Deelbesluit:** de **generatie van receptomslagfoto's** is een aparte route waar geen
  inhoudsmoderatie op zit (bewust, staat zo in `docs/architecture/ai.md`). Voor een gezinsapp
  met vijf testers is dat risico verwaarloosbaar, maar bij externe testers zou ik hem
  uitzetten tot je een antwoord hebt op de moderatievraag.

---

## 3. Wat doen we met de gezondheidsgegevens?

**De vraag:** accepteer je dat uit Apple Gezondheid geïmporteerde waarden (gewicht, stappen)
naar je eigen Supabase-EU gaan, of houd je gezondheid lokaal in deze fase?

> **BESLIST 27-07 (eigenaar): documentatie aanpassen, sync niet beperken.** De onware zin in
> `docs/architecture/integraties-en-privacy.md` §5 is ingetrokken en vervangen door een
> expliciete uitleg: de HealthKit-*reads* blijven on-device, maar de afgeleide rijen
> (`weight_entries`, `weight_goals`, `daily_step_counts`, `step_goals`) synchroniseren in
> cloud-modus wél naar Supabase (EU), binnen het eigen huishouden en niet naar derden.
> De concept-privacyverklaring (`privacybeleid-concept.md` §3.3) zei dit **al** correct —
> die hoefde niet aangepast. Richtlijn 5.1.3 blijft van toepassing, dus dit moet in de
> definitieve verklaring benoemd blijven.

**Waarom het uitmaakte:** dit is de zwaarste categorie in het privacylabel, en het punt waarop
Apple's richtlijn 5.1.3 van toepassing is. De eigen documentatie beweerde het tegenovergestelde
van wat de code doet; die zin ongecorrigeerd in een juridisch document overnemen zou een
onwaarheid opleveren.

Waar het buiten HealthKit om nog zwaarder wordt: de gezondheidsmodules bevatten ook
**medicatie** en **cyclusgegevens inclusief anticonceptiegebruik** — die gaan ook mee in de
sync (en die komen niet uit HealthKit, dus 5.1.3 raakt ze niet, maar de AVG wel: bijzondere
persoonsgegevens, artikel 9).

**Mijn advies: accepteren en goed disclosen.** Synchronisatie is de kernfunctie van de betaalde
laag; die eruit slopen voor gezondheid maakt het product slechter en het is niet nodig. De
bestaande bescherming is echt goed: standaard privé-per-persoon, uitgesloten van de
gezinsbrede syncstream, standaard uitgesloten van AI, en optioneel achter biometrie. Zorg wél
dat (a) de documentatie wordt gecorrigeerd, (b) §3.3 van de privacyverklaring precies zo blijft
staan als ik hem heb geschreven, en (c) je de reviewnotitie uit `testflight-metadata.md` §7.2
klaar hebt liggen.

**Gevolgen:**

- **Accepteren:** in het label vink je Health & Fitness aan, gekoppeld aan identiteit, doel
  App Functionality. Dat is een zwaar ogend label, maar wel het juiste, en het staat naast
  "geen tracking" — dat is een goed verhaal.
- **Gezondheid lokaal houden:** technisch een ingreep in de syncstreams (niet triviaal), en
  gezondheidsgegevens verschijnen dan niet op je tweede toestel. Alleen zinvol als je de
  categorie principieel buiten je cloud wilt houden.
- **Wat je hoe dan ook moet doen:** in de app expliciet toestemming vastleggen voor
  gezondheidsgegevens (artikel 9 AVG) — nu is die er alleen impliciet via de HealthKit-prompt
  en het aanzetten van de module.

---

## 4. Hoe label je de financiële gegevens?

**De vraag:** vink je in App Privacy alleen "Other Financial Info" aan, of ook "Payment Info"?

**Waarom het uitmaakt:** Apple rekent onder *Payment Info* uitdrukkelijk ook
bankrekeningnummers. Als je die opslaat en het niet meldt, is dat een verkeerd label. Meld je
iets dat je niet opslaat, dan schrik je gebruikers onnodig af.

**Wat de code doet:** `bank_accounts` bewaart alleen `bank`, **`iban_last4`**, `holder` en een
vrij `note`-veld; `payment_cards` alleen `name`, **`last4`** en soort
(`supabase/migrations/0002_domain_tables.sql:409-436`). Er wordt dus **geen volledig rekening-
of kaartnummer** opgeslagen. Wat wél gedetailleerd is: inkomen, vaste lasten, leningen,
spaardoelen, verzekeringen, en de zakgeldadministratie per kind.

**Mijn advies: "Other Financial Info" aanvinken, "Payment Info" niet**, en in de
privacyverklaring expliciet schrijven dat je alleen de laatste vier cijfers bewaart. Dat is
zowel eerlijk als geruststellend.

**Gevolgen:**

- **Zonder Payment Info:** correcter en minder afschrikwekkend. Risico: het `note`-veld bij een
  bankrekening is vrije tekst, dus een gebruiker kán er een volledig IBAN in typen. Overweeg
  een korte waarschuwing bij dat veld.
- **Met Payment Info:** maximaal veilig richting Apple, maar je claimt iets dat je niet doet.

---

## 5. Analytics: laten we PostHog aan staan in de betabuild?

**De vraag:** gaat de PostHog-key mee in de TestFlight-build, en zo ja: repareer je eerst dat
de SDK ook zonder toestemming contact maakt?

**Waarom het uitmaakt:** de toestemmingsgate zelf is in orde en beter dan je documentatie
suggereert — `analyticsConsent` staat standaard op `false` met de comment "opt-in required,
privacy-first", en `ConsentGatedAnalytics` blokkeert élk event zonder toestemming. **Maar** de
SDK wordt onvoorwaardelijk geïnitialiseerd (`lib/main.dart:51-52`) met de standaardwaarden voor
`optOut`, `preloadFeatureFlags` en `surveys`. Gevolg: bij elke koude start doet de app een
verzoek naar `eu.i.posthog.com` — met een anonieme id en dus je IP-adres — ook als je geen
toestemming hebt gegeven. Er gaan geen events, maar er is wel contact. Dat maakt de zin
"analytics staat uit tot je hem aanzet" strikt genomen onjuist.

Daar komt bij: er is **geen toestemmingsstap in de onboarding**; de toggle staat verstopt in
Instellingen → Privacy.

**Mijn advies: geef de PostHog-key niet mee in de eerste TestFlight-build.** Je hebt met vijf
testers uit één gezin niets aan productanalytics — je krijgt je feedback via Telegram/Linear —
en je haalt daarmee in één klap een hele datacategorie uit het privacylabel en een discussie
uit je privacyverklaring. Zet hem aan zodra de opt-in netjes in de onboarding staat.

**Gevolgen:**

- **Key eruit:** "Usage Data" hoeft niet aangevinkt (mits je het ook echt zo houdt), en je
  privacytekst wordt eenvoudiger. Nadeel: geen inzicht in gebruik — bij vijf testers verwaarloosbaar.
- **Key erin, ongewijzigd:** vink Product Interaction aan (niet gekoppeld, analytics) en pas de
  formulering aan naar "gebruiksgegevens worden pas verzameld na toestemming; de
  analysecomponent maakt bij het starten wel verbinding".
- **Key erin, na reparatie** (initialiseren pas ná toestemming, of starten met `optOut = true`
  plus `preloadFeatureFlags`/`surveys` uit): dan klopt de belofte volledig. Kleine ingreep,
  maar het is codewerk en dus voor een volgende ronde.

---

## 6. Crashrapportage: aan, en met welke instellingen?

**De vraag:** gaat de Sentry-DSN mee, en accepteer je dat crashrapportage niet uit te zetten is?

**Waarom het uitmaakt:** crashrapportage is bij een beta juist waardevol — je wíl weten waarom
een toestel vastloopt. Maar drie dingen kloppen nu niet helemaal:

1. Sentry is **niet** gekoppeld aan de privacytoggle; als je in je tekst "analytics is opt-in"
   schrijft, dekt dat de crashdata niet. (In `privacybeleid-concept.md` §7 heb ik dit als
   gerechtvaardigd belang beschreven — dat is de nette route.)
2. In release-builds worden `debugPrint`-regels automatisch breadcrumbs bij een crashrapport,
   en er is geen filter. In uitzonderlijke gevallen kan daar een bestandsnaam, een member-id of
   een ruwe databasefoutmelding met een veldwaarde in zitten.
3. `SENTRY_ENV` heeft als default `development` en wordt door het buildscript niet meegegeven —
   je betarapporten komen dus binnen met het label "development".

**Mijn advies: aan laten, maar geef `SENTRY_ENV=production` (of `beta`) mee, en zoek uit of je
Sentry-organisatie in de EU of de VS draait.** Dat laatste bepaalt of er een doorgifte buiten
de EU in je privacyverklaring moet.

> **Beantwoord op 13 augustus 2026.** Sentry draait nu in de **EU** (`de.sentry.io`,
> organisatie `aqua-it-bv-eu`); er is voor foutrapportage dus géén doorgifte buiten de EU meer.
> Zie TEN-228.

**Gevolgen:**

- **Aan, zoals nu:** je krijgt bruikbare crashdata; je moet in de verklaring vermelden dat
  foutrapporten in uitzonderlijke gevallen een fragment van je gegevens kunnen bevatten, en dat
  crashrapportage niet uit te zetten is.
- **Uit voor de beta:** minder inzicht precies wanneer je het nodig hebt. Niet aan te raden.
- **Nog te doen (later):** een filterfunctie op uitgaande rapporten, en desgewenst een
  aan/uit-schakelaar naast de analytics-toggle.

---

## 7. Valt de app onder de export-encryptievrijstelling?

**De vraag:** antwoord je bij de upload dat de app geen niet-vrijgestelde versleuteling
gebruikt (in `Info.plist`: `ITSAppUsesNonExemptEncryption = false`)?

**Waarom het uitmaakt:** zonder antwoord blijft elke build in App Store Connect hangen op
"Missing Compliance" en kan hij niet naar testers. Het is bovendien een verklaring aan de
Amerikaanse exportautoriteiten, niet alleen een Apple-formaliteit.

**Wat de app doet:** uitsluitend standaard-HTTPS/TLS naar Supabase, PowerSync, Open-Meteo,
PostHog, Sentry en door de gebruiker opgegeven kalenderfeeds; SHA-256-hashing van de
app-lock-PIN (hashing is geen versleuteling); Keychain/Keystore via het platform. **Geen eigen
cryptografie, geen SQLCipher, geen versleutelde database.**

**Mijn advies: dit profiel valt normaal onder de vrijstelling — antwoord dus dat je geen
niet-vrijgestelde versleuteling gebruikt.** Maar lees de tekst die Apple bij de vraag toont zelf
en bevestig hem zelf; ik ben geen exportjurist en dit is jouw verklaring. Let ook op de losse
vraag over Frankrijk als die verschijnt.

**Gevolgen:**

- **Vrijstelling:** de build gaat door zonder verdere administratie. Zet het bij voorkeur als
  sleutel in `Info.plist` zodat je de vraag niet elke upload opnieuw krijgt (build-kant).
- **Geen vrijstelling claimen:** je komt in een traject met jaarlijkse zelfclassificatie en
  eventueel een registratienummer. Onnodig zwaar voor wat deze app doet.
- **Niets antwoorden:** de build blijft staan. Geen optie.

---

## 8. Waar komt het privacybeleid te staan?

**De vraag:** op welke publieke URL host je de privacyverklaring?

**Waarom het uitmaakt:** voor externe TestFlight-testers is de privacybeleid-URL een verplicht
veld, en voor de App Store sowieso. De URL moet **zonder inloggen** bereikbaar zijn — de
bestaande docs-site staat op een Cloudflare Pages-adres met `noindex` en is bewust niet-vindbaar;
dat is prima als hosting, maar gebruik dan wel een nette, blijvende URL.

**Besluit (2026-07-27): `https://tendlo.app/privacybeleid/`.** Het volledige beleid staat live
op de marketingsite, naast `https://tendlo.app/voorwaarden/`, `https://tendlo.app/support/`
(Support URL) en `https://tendlo.app/account-verwijderen/` (Delete Account URL voor Google
Play). Let op: `tendlo.app/privacy` is de marketing-privacypagina en dus níet de beleids-URL.

**Gevolgen:**

- **Eigen domein:** eenmalig wat werk (pagina publiceren, DNS staat al), daarna klaar voor de
  App Store.
- **Pages-URL hergebruiken:** morgen klaar, maar je zit vast aan een willekeurige hostname in
  je storevermelding, of je moet later alles omzetten.
- **Controleer:** geen Access-poort ervoor, en de pagina moet ook zonder JavaScript leesbaar
  zijn.

---

## 9. Hoe komt een Apple-reviewer de app in?

**De vraag:** alleen relevant bij externe testers — hoe beoordeelt Apple een app waarvan het
inloggen via een e-maillink verloopt?

**Waarom het uitmaakt:** de reviewer kan die mail niet ontvangen. Zonder antwoord op dit punt
is "we konden niet inloggen" de meest waarschijnlijke afwijzingsreden.

**Mijn advies: leg in de reviewnotities uit dat inloggen niet nodig is om de app te
beoordelen.** Dat is hier gewoon waar — de app werkt volledig lokaal zonder account, en dat is
een sterk punt in plaats van een verontschuldiging. De concept-tekst staat in
`testflight-metadata.md` §7.1.

**Gevolgen:**

- **Alleen uitleggen:** meestal voldoende, en niets in te richten. Risico: de reviewer wil de
  cloudfunctionaliteit toch zien.
- **Testaccount met vaste code:** Supabase kent een instelling voor een testadres met een vaste
  eenmalige code. Verifieer dat eerst in het dashboard; als het werkt, is het de nettste
  oplossing. Zet hem na de review weer uit — een vaste code is een permanente achterdeur.
- **Niets regelen:** vraagt om een afwijzingsronde.

---

## 10. Bouwen we accountverwijdering nu of later?

**De vraag:** moet de in-app "verwijder mijn account en mijn servergegevens" er nu al zijn?

**Waarom het uitmaakt:** Apple eist dat apps waarin je een account kunt aanmaken, dat account
ook in de app kunnen laten verwijderen (richtlijn 5.1.1(v)). Nu wist het privacyscherm alleen
lokale gegevens; serverzijdig bestaat alleen een beheerdersroute, en die verwijdert bovendien
wel de databaserijen maar níét de opgeslagen bestanden. Voor TestFlight is dit geen blokker,
voor de App Store wel. Vanuit de AVG is het bovendien een recht dat je moet kunnen waarmaken.

**Mijn advies: niet nu, wel als harde voorwaarde vóór de App Store-inzending** — en zet in de
privacyverklaring eerlijk dat verwijderen momenteel op verzoek gaat, met een e-mailadres en een
termijn die je waarmaakt.

**Gevolgen:**

- **Later:** je haalt de TestFlight-ronde zonder vertraging, maar je hebt een openstaande
  belofte in je privacyverklaring die je moet nakomen.
- **Nu bouwen:** dagen werk (Edge Function + UI + het opruimen van de opgeslagen bestanden) en
  het houdt de beta op. Niet nodig voor vijf testers binnen één gezin.

---

## 11. Blijft de Plus-/abonnementskant zichtbaar in de betabuild?

**De vraag:** laat je de upsell-sheet met **placeholderprijzen** staan terwijl er geen
aankoopflow in de app zit?

**Waarom het uitmaakt:** de RevenueCat-SDK zit niet in de app; er is dus geen enkele manier om
te kopen, terwijl de sheet prijzen toont. Voor TestFlight is een onaffe functie toegestaan,
maar zichtbare nepprijzen zonder werkende aankoop is precies waar reviewers op reageren — en
bij de App Store-inzending is het een harde grond (geen placeholder-content; digitale aankopen
moeten via in-app aankoop lopen). Bovendien verwart het je testers: alle Plus-modules staan nu
feitelijk open omdat de afdwinging uitstaat.

**Mijn advies: verberg de prijzen (of de hele upsell-sheet) in de betabuild** en zet in "What
to Test" één zin dat abonnementen deze ronde buiten scope vallen.

**Gevolgen:**

- **Verbergen:** minder ruis bij testers, geen reviewrisico. Kleine ingreep aan de app-kant.
- **Laten staan:** bij interne distributie waarschijnlijk zonder gevolgen; bij externe review
  een reëel risico op een opmerking.
- **Let op voor later:** zodra de RevenueCat-SDK erin gaat, moet je **Purchases › Purchase
  History** toevoegen aan het privacylabel en RevenueCat/Apple opnemen in de verwerkerslijst.

---

## 12. Leeftijdsclassificatie en: mogen kinderen zelf tester zijn?

**De vraag:** welke leeftijdsclassificatie geef je op, en krijgen de kinderen in het gezin een
eigen TestFlight-account?

**Waarom het uitmaakt:** de leeftijdsclassificatie is een vragenlijst in App Store Connect en is
nodig voor de storevermelding. Deze app bevat geen geweld, gokken of volwassen inhoud, maar de
cyclusmodule geeft wel uitleg over menstruatie en anticonceptie — dat kan onder "incidentele of
milde medische/behandelinformatie" vallen, wat de classificatie omhoog duwt. Los daarvan: een
TestFlight-tester moet een Apple Account hebben, en voor kinderen gelden daar aparte regels
(gezinsdeling, Vraag om te kopen).

**Mijn advies: vul de vragenlijst eerlijk in en accepteer 4+ of 12+ — kies niet strategisch.**
En laat de kinderen deze ronde meetesten op een toestel dat door een ouder beheerd wordt, in
plaats van ze een eigen tester-account te geven.

**Gevolgen:**

- **Eerlijk invullen:** mogelijk 12+ door de cyclusmodule. Dat is geen probleem voor een
  gezinsapp en beter dan een correctie achteraf.
- **Kinderen als eigen tester:** je moet dan omgaan met de Apple-Account-regels voor
  minderjarigen, en met de AVG-vraag rond toestemming voor kinderen onder 16 — die de app nu
  helemaal niet afvangt (geen leeftijdscontrole, geen toestemmingsmoment bij het uitnodigen van
  een kind).
- **Los hiervan te beslissen:** je bent géén "Kids Category"-app en moet dat ook niet worden —
  die categorie heeft eigen, zware regels. Positioneer Tendlo als app voor volwassenen die het
  huishouden beheren.

---

## Kleinere punten — beslis of laat beslissen, maar ze houden de beta niet tegen

1. **Permissietekst agenda** belooft schrijven naar je apparaat-agenda, terwijl de app alleen
   leest. Aanpassen (build-kant).
2. **Permissietekst spraak** belooft on-device-herkenning die niet wordt afgedwongen. Óf
   `onDevice: true` zetten, óf de tekst aanpassen. Kies één van beide vóór de App Store.
3. **`PrivacyInfo.xcprivacy` ontbreekt** in de app-target. Kan een ITMS-91053-melding na upload
   geven. Doorgeven aan de build/signing-kant.
4. **Bijlagen zijn afgeschermd per huishouden, niet per eigenaar.** Repareren of eerlijk
   opschrijven — zie het `[BESLUIT]`-blok in `privacybeleid-concept.md` §5.1.
5. **Gegevens-export is onversleutelde JSON** met gezondheid en financiën. Tendlo bewaart de
   laatste drie exports in Application Support; die map is uitgesloten van de iCloud-back-up.
   Het scherm benoemt daarom expliciet dat dit een leesbare export is en geen volledige
   huishoudback-up.
6. **Bewaartermijnen bestaan niet.** Er draait geen enkele opschoning: verwijderde items,
   `ai_usage_logs` en auditregels blijven eeuwig staan. Zodra je in de privacyverklaring een
   termijn opschrijft, moet er iets zijn dat hem uitvoert.
7. **Verwerkersovereenkomsten** met Supabase, PowerSync, OpenRouter, Resend, PostHog, Sentry en
   (later) RevenueCat formeel accepteren en bewaren; en vastleggen op welke grondslag de
   doorgifte naar de VS plaatsvindt.
8. **Corrigeer `docs/architecture/integraties-en-privacy.md` §5** — de zin dat
   gezondheidsgegevens on-device blijven is onjuist en is de bron waaruit een privacyverklaring
   zou worden overgeschreven.