Jouw acties

Xcode heeft tijdens de proefbuild zelf een distributiecertificaat en twee provisioningprofielen in je Developer-account aangemaakt — een neveneffect van automatic signing, niet iets wat ik heb aangevraagd. De privésleutel zit in Xcode's beheerde opslag. Ik heb het nagekeken: security find-identity ziet alleen je development-certificaat, dus het distributiecertificaat staat nergens waar een gewone back-up bij komt. Op een schone Mac ben je hem dan kwijt, en dan moet je hem intrekken en opnieuw aanvragen — met alle builds die daaraan hangen.

Wat je doet

In Xcode (26.6):

1. Xcode → Settings… (of ⌘,)
2. tab Accounts, kies je Apple ID in de linkerlijst
3. klik rechtsonder op Manage Certificates…
4. zoek de regel Apple Distribution (niet Apple Development — die heb je al veilig)
5. rechtsklik erop → Export Certificate…
6. geef een wachtwoord op en noem het bestand tendlo-apple-distribution-2026-07.p12

Die naam heeft drie delen die je later alle drie nodig hebt: welke app (er zitten ook byo en snapsnel in dit Developer-account), welk soort certificaat (distribution, niet development — dat verschil is straks het hele punt), en wanneer (ze verlopen na een jaar, dus met een datum zie je meteen of je naar de oude of de nieuwe kijkt zonder hem te importeren).

Waar het NIET hoort

Niet in deze repo, en zeker niet in docs/. Die map wordt integraal naar Cloudflare Pages gedeployed — elke keer als ik de documentatie bijwerk. Die site heeft alleen een noindex-header en bewust geen toegangscontrole, dus een .p12 daar zou een publiek downloadbare privésleutel worden, zonder enige waarschuwing. Ook elders in de repo niet: er staat geen *.p12-regel in .gitignore, dus een git add -A neemt hem gewoon mee — en git-historie is permanent.

Waar het wél hoort

Als bijlage in je wachtwoordmanager, bij het item met het wachtwoord. Dan reizen bestand en wachtwoord samen, zijn ze beide versleuteld, en kun je ze niet per ongeluk scheiden — precies het scenario waar deze back-up voor bestaat. Wil je liever een bestand op schijf: een map buiten de repo die in je back-up zit (~/Documents/Certificaten/), met het wachtwoord alsnog in de manager en niet in een tekstbestand ernaast.

Gedaan

Staat op ~/Documents/Certificates/tendlo-apple-distribution-2026-07.p12. Structureel nagekeken zonder het wachtwoord: geldig PKCS#12 én de OID 1.2.840.113549.1.12.10.1.2 zit erin — dat is de versleutelde privésleutel. Een export waarin per ongeluk alleen het certificaat zit ziet er precies zo uit maar is waardeloos; dat is hier niet zo. Staat niet in git.

Het wachtwoord

Heb ik niet nodig. De build gebruikt Xcode's automatic signing, dat het certificaat rechtstreeks uit Xcode's eigen opslag haalt; deze .p12 is puur de rampenverzekering. Ik zou het alleen nodig hebben om het certificaat op een ándere machine te importeren of om CI-signing op te zetten, en er is bewust geen CI-uploadpad. Houd het in je wachtwoordmanager — een wachtwoord in een chatgesprek blijft daar staan.

Vangnet toegevoegd

In .gitignore staan nu *.p12, *.pfx, *.cer, *.mobileprovision, *.jks en *.keystore, zodat een git add -A zulk materiaal nooit meer kan meenemen. Geverifieerd dat de regel bijt.

De TestFlight-branch zet ITSAppUsesNonExemptEncryption op false. Dat is een verklaring op jouw naam, dus die zet ik niet voor je — maar er is geen knop om te vinden: staat de sleutel goed, dan vraagt App Store Connect er niet meer om. Staat hij er niet, dan blijft elke build op "Missing Compliance" hangen.

Wat je bevestigt

Dat Tendlo geen eigen versleuteling meebrengt en alleen gebruikmaakt van wat het systeem al biedt: TLS voor netwerkverkeer, de Keychain voor geheimen, en LocalAuthentication voor Face ID. Dat is de standaardsituatie en de reden dat false hier klopt.

Bevestigd

Je hebt het bevestigd; false blijft staan. De TestFlight-branch is daarmee gemerged naar main (6d475bd9), inclusief de buildscripts en het privacy-manifest. App Store Connect vraagt er nu niet meer om.

Het manifest in de app is ingevuld en zit in de geüploade build. Wat niet kan: het App Privacy-formulier in App Store Connect via de API vullen — dat endpoint bestaat niet in de publieke API (ik heb vijf varianten geprobeerd, allemaal 404). Dit is daarom het enige stukje typewerk dat echt van jou moet komen. Hieronder staat letterlijk wat je moet aanklikken, zodat het mechanisch is.

Waar

App Store Connect → Tendlo → linkerkolom onder TRUST & SAFETY → App Privacy → Get Started bij Data Collection.

Eerste vraag

"Do you or your third-party partners collect data from this app?" → Yes. (Nee zou onwaar zijn: er gaat e-mailadres naar Supabase en locatie naar de weerdienst.)

Zes types aanvinken

Vink precies deze aan, en niets anders:

1. Contact Info → Email Address
2. Contact Info → Name
3. User Content → Other User Content
4. Health & Fitness → Health
5. Location → Coarse Location ← let op: Coarse, niet Precise
6. User Content → Photos or Videos

Per type de drie vervolgvragen

Voor alle zes geldt hetzelfde antwoord op twee vragen:
· "How is this data used?" → App Functionality (en niets anders)
· "Is this data used to track you?" → No
Alleen de derde vraag verschilt:
· "Is this data linked to the user's identity?" → Yes voor e-mail, naam, user content, health en foto's · No voor locatie.

Die ene locatie-regel

Locatie is grof en niet gekoppeld. Dat voelt tegenintuïtief — bij locatie denk je aan "die weet wie ik ben" — maar het volgt uit de code: de positie gaat op kilometerniveau naar Open-Meteo, een dienst die geen sleutel en geen account vraagt. Er gaat dus niets identificerends mee, en de positie wordt niet opgeslagen. Kies je hier Precise of Linked, dan wijkt het formulier af van het manifest in de build, en dat is een afwijzingsgrond.

Tot slot

Publish bovenaan. Zonder publiceren blijft het formulier concept en blokkeert het de externe distributie.

Enforcement staat aan, dus een tester zonder rij in plus_entitlements loopt tegen een harde grens waar niets achter zit. De Paid Apps Agreement en de nog niet aangemaakte abonnementen blokkeren TestFlight niet — er is geen paywall die stukloopt.

Geen actie nodig

Ik heb het nagekeken op productie in plaats van er blind een grant bij te zetten: alle vier de huishoudens hebben al een actieve admin-grant op tier family, zonder einddatum — inclusief het echte testhuishouden (4 leden). Enforcement blijft dus aan, zoals je wilde, en er hoefde niets bij.

A gekozen en uitgevoerd

De rubriek heet nu "Vakantiegeld & rapportgeld" — in nl, en én de. De ondertitel is meegetrokken zodat hij niet meer hetzelfde zegt als de titel. Geen migratie: dit is puur een l10n-sleutel.

Ook nagelopen

De widget-test, twee codecommentaren en de module-documentatie noemden de oude naam ook; die zijn mee. Eén golden-test brak op 0,67% pixelverschil — ik heb het verschilbeeld bekeken en dat zat uitsluitend in de titelbalk, niet in de kaarten, dus de golden is bijgewerkt.

Blijft open op TEN-47

De twee andere wensen op dat ticket (lange notitie inklapbaar maken, en een indicatie dát er een notitie is) heb je niet beslist, dus die heb ik laten staan. Het ticket blijft in Triage.

De architectuurdocumentatie zegt: "Health-reads blijven on-device; er gaat niets naar Tendlo-servers of derden." Voor de HealthKit-reads zelf klopt dat. Maar de daaruit afgeleide rijen — gewicht, gewichtsdoelen, dagelijkse stappen, stapdoelen — staan in het PowerSync-schema én vier keer in de server-side sync-config, en gaan dus wél naar Supabase.

Gekozen: documentatie eerlijk maken

De onware zin is ingetrokken. Er staat nu expliciet dat de HealthKit-reads on-device blijven, maar dat de afgeleide rijen (gewicht, gewichtsdoel, stappen, stapdoel) in cloud-modus wél naar Supabase (EU) synchroniseren — binnen het eigen huishouden, niet naar derden. Met de toevoeging dat wie dit écht on-device wil houden, de cloud-sync niet aanzet: dat is de enige stand waarin de oude belofte klopte.

Meevaller

De concept-privacyverklaring zei dit al helemaal correct (§3.3: "Gebruik je cloudsynchronisatie, dan worden ze dus ook op onze servers in de EU opgeslagen"). Alleen het interne architectuurdocument loog. Er stond dus geen onwaarheid in het juridische document — dat was mijn zorg en die blijkt ongegrond.

Blijft gelden

Richtlijn 5.1.3 is nog steeds van toepassing, dus dit moet in de definitieve verklaring benoemd blijven. De twee release-documenten die dit als openstaand aanmerkten zijn bijgewerkt.

Spraak

De tekst zegt "spraakherkenning op je toestel", maar de on-device-vlag wordt nergens gezet — geen enkele treffer in de hele lib/.

Agenda

De tekst belooft dat Tendlo afspraken in je apparaat-agenda kan zetten, terwijl de koppeling read-only is.

Gekozen: belofte waarmaken, eerst refinen

TEN-140 (spraak) en TEN-141 (agenda schrijven) staan in Triage, met in de beschrijving de open punten op product- én techniekvlak die we samen moeten doorlopen. Ik heb ze bewust niet naar Todo gezet en er niets aan gebouwd.

Waarom dit geen kleine tickets zijn

Bij spraak: onDevice: true is een verzoek — niet elk toestel en niet elke taal heeft een on-device-model, en on-device is merkbaar minder accuraat bij namen en Nederlands met achtergrondgeluid. Precies de use-case. Dus: weigeren of terugvallen?
Bij de agenda: terugschrijven is een tweerichtings-koppeling. Dat vraagt een device-event-id per afspraak (kolom → migratie → vier-weg sync-lockstep), een keuze over conflicten als beide kanten wijzigen, en een privacybeslissing of een gedeelde afspraak in andermans agenda mag verschijnen.

Mijn vraag bij de refinement

Bij de agenda leg ik expliciet de vraag terug of "waarmaken" hier echt de gewenste richting is, of dat de lees-koppeling eigenlijk voldoet en alleen de tekst niet klopt. Het scopeverschil is groot genoeg om die vraag nog één keer te stellen — dat staat ook zo op het ticket.

SENTRY_PA_DSN ontbrak in je shell-profiel, dus de define werd niet meegegeven — ook niet in de builds die op de toestellen staan. Crashes kwamen dus nergens aan. Je gaf me toestemming om hem erin te zetten; dat is gebeurd. De build op jouw telefoon van vanmiddag heeft hem nog niet — die is gemaakt vóór deze wijziging. De volgende build pikt hem op.

Fout van mij, gecorrigeerd

De DSN die ik je gisteren gaf hoorde bij het Sentry-project byo, niet bij Tendlo. Tendlo-crashes zouden daarmee in het BYO-project zijn geland. Ik heb de projectlijst opgehaald en de juiste DSN van project mijn-pa gepakt; die staat nu in ~/.zprofile (met een back-up van het oude bestand ernaast). Teruggelezen en gecontroleerd dat de variabele klopt.

EU: dat kan ik niet voor je doen

Je wilde het uit de VS. Dat kán niet met een DSN-wissel. Sentry ondersteunt geen regio-migratie van een bestaande organisatie, en jouw account heeft alleen de US-regio beschikbaar (/users/me/regions/ geeft alleen us). EU vraagt dus een nieuwe organisatie, aangemaakt via het EU-aanmeldpad. Gevolgen die je eerst moet wegen: BYO en de twee snapsnel-projecten zitten in dezelfde organisatie, de bestaande issue-historie blijft in de VS achter, en een nieuwe organisatie betekent apart ledenbeheer en een apart plan.

Opgelost op 13 augustus 2026: de EU-organisatie aqua-it-bv-eu is aangemaakt en de DSN is omgezet. BYO zit nog op de oude organisatie — zie BYO-337.

Opruimen — mijn fout

Bij het uitzoeken hiervan heb ik een POST gedaan die ik als test bedoelde, maar die is geslaagd: er staat nu een lege organisatie probe-dry-run in je Sentry-account. Nul projecten, dus hij doet niets, maar hij hoort er niet. Ik kan hem niet verwijderen — de token mist org:admin (403). Verwijderen doe je zo: sentry.io → wissel naar probe-dry-run → Settings → General Settings → onderaan Remove Organization. Sorry, dat had ik niet moeten doen zonder eerst te controleren of het endpoint droog kon draaien.

Voor nu

Tot de EU-organisatie er is landen crashes in de VS. Dat is een doorgifte naar een derde land en hoort in de privacyverklaring te staan; dat punt staat op TEN-142. Wil je liever géén crashrapportage dan crashrapportage in de VS, zeg het dan — dan haal ik de DSN er weer uit.

PostHog ís consent-gated en blokkeert events, maar de SDK wordt onvoorwaardelijk geïnitialiseerd — dus bij elke koude start gaat er een request met IP heen. Sentry is helemaal niet consent-gated.

Akkoord voor de testronde

Blijft zoals het is voor de TestFlight-ronde binnen één gezin. De opvolging staat als TEN-142 in Triage: initialisatie achter de consent-gate (niet alleen het dempen van events), SDK's afsluiten bij intrekken, en de Sentry-breadcrumbs uit debugPrint in release beoordelen — daar kan gebruikersinhoud in zitten. De EU-doorgifte hangt aan hetzelfde ticket.

Deze drie staan in Todo en zijn door de ontwerp-gate, maar bouwen vóór de antwoorden levert werk op dat herzien moet worden. De zes vragen staan met advies op de varianten-pagina: waardebepaling · dubbeltelling van een financieringslening · bruto of netto · doen auto's mee · doet een bankrekeningsaldo mee · per kijker of gezinsbreed.

Wat je doet

Zeg "neem me door de Vermogen-vragen", dan doe ik ze één voor één met advies — net als hierboven. Reken op tien minuten.

Van de zes die de verrijkers adviseerden bestaan er drie (TEN-139, TEN-137, TEN-138). Deze liggen er nog; ik maak ze niet zelf aan.

Back-up 2.0

Bijlagen mee-exporteren, versleuteld bestand, herstelwizard met samenvoeg-keuze. Het defect-deel zit al in TEN-134 (Todo); dit is het vervolg.

Klantenkaarten opsplitsen

In kern, foto's en scannen. Pas zinvol als je TEN-132 vrijgeeft.

Rooster opsplitsen

In cyclus-model, conflictwaarschuwing en AI-herkenning. Idem voor TEN-133.