Vermogen wordt de overkoepeling. Vastgoed is er één onderdeel van.

Wat je besloten hebt

Die twee zinnen samen zijn scherper dan ze los lijken. De eerste zegt: er komt een niveau erboven — Vermogen is niet een nieuwe naam voor Vastgoed en niet een uitbreiding ervan, maar een laag waaronder vastgoed hangt naast schulden, spaargeld en later beleggingen. De tweede zegt: die laag mag niets platslaan. Vastgoed is deze week juist verdiept (verhuurtype, wisseldagbolletjes, opzegtermijn-melding, objectkleur); een abstractie die daarvan "een bezitting met een waarde" maakt, breekt precies wat de tester zelf heeft aangevraagd en getest.

Dit herziet een eerder besluit. ADR-0012 (geaccepteerd 2026-07-22) legde vast dat het Vermogen-overzicht "een scherm/tab binnen het bestaande domein Financieel" zou worden — de allerlichtste vorm, expliciet géén eigen plek in de navigatie. Dat is precies wat de zin van 26 juli omdraait. Die ADR moet dus vervangen worden; zie § Wat er met de ADR's gebeurt.

Wat behouden blijft — de harde randvoorwaarde

Dit is geen terzijde maar een controlelijst: voor de fixer die het bouwt, en voor de tester die deze functies deze week zelf heeft aangevraagd en getest. Elke regel moet ná de herpositionering nog exact zo werken. Alles hieronder staat vandaag op main.

• ✓Verhuurtype per object — kortverhuur (wisselgasten) versus langlopend contract, en dat verhuurtype bepaalt zowel de agenda-weergave als de melding.lib/features/vastgoed/vastgoed/domain/rental_mode.dart:15 · kolom vastgoed_tables.dart:47
• ✓Boekingen met gast en periode, inclusief de lege-gast-conventie voor de jaarlijkse ligplek-verhuur, plus overlap-waarschuwing bij dubbele boekingen.vastgoed_tables.dart:80 (guest :87, start :90, end :93) · domain/booking_overlap.dart · presentation/add_booking_sheet.dart
• ✓De bolletjes in de agenda-dagkop — één gevuld bolletje van 10 px per object op álle gedekte dagen, met de check-in/check-out-glyph ernaast op de wisseldagen, max 4 + +n, sortering aankomst → vertrek → doorlopend.TEN-120 fase A (commit 39a4611b)
• ✓Het dag-sheet "Verhuur · datum" achter één tap-target van 44 px, met per boeking object, gast en fase/einddatum. Zonder dat landen "door wie" en "tot wanneer" nergens meer.TEN-120 fase A
• ✓Langlopend contract = 3 momenten, geen 365 dagbanden — start, opzegdatum (einde − opzegtermijn) en einde, met één melding op de opzegdatum; band en melding delen één berekende datum.TEN-120 fase A · kolom noticePeriod vastgoed_tables.dart:72
• ✓Check-in/check-out-meldingen bij kortverhuur, met de per-module meldingstermijn, meldtijd en geluid uit de module-instellingen.presentation/vastgoed_providers.dart (resyncVastgoedReminders)
• ✓showInAgenda als escape-hatch per object — raakt bewust alleen de weergave; de meldingen blijven staan als de vlag uit gaat.vastgoed_tables.dart:53
• ✓Objectkleur en object-avatar als leading in de agenda in plaats van het generieke huisje.presentation/property_avatar.dart:26 + PropertyAgendaLeading:93 · colorHex vastgoed_tables.dart:58 · vastgoed_module.dart:49-67
• ✓De agenda-mirror geeft deel-stand en eigenaar door (TEN-129) en vastgoed staat in kSelfSurfacedModules zodat de mirrors niet ook nog in de Vandaag-dagstroom en de gezinsstrip staan. Niet terugdraaien.commit d441045b · TEN-120 fase A
• ✓De aanstaande structurele fix op branch fix/ten-120-nullable-kolommen (twee kolommen client-side nullable) moet vooruit kunnen. Geen enkele variant hier vereist dat die wordt teruggedraaid.lokale branch, nog niet gemerged
• ✓Objecttypen incl. "Overige" met vrije categorie (TEN-84) en bijlagen per object.domain/property_type.dart · presentation/add_property_sheet.dart
• ✓De rendement-kaart op het objectdetail (fase 1: bevestigde + afgeronde boekingswaarde per jaar, verwacht, bruto huurrendement, jaarrente-momentopname) blijft op het objectdetail staan — niet verhuizen naar het Vermogen-overzicht.domain/property_return_calc.dart · presentation/property_detail_screen.dart:170
• ✓Het deelbeleid van vastgoed — configureerbaar met privé als fallback, cascade van object naar zijn boekingen, en de deel-hint bij een uitgezette module.lib/core/modules/share_policy.dart:120 · share_bulk_remapper.dart:120 · shared_in_disabled_module_watcher.dart:45
• ✓De per-module instellingen op module-id vastgoed — aan/uit per lid, meldingstermijn, meldtijd, geluid, verbergen voor bepaalde leden, favoriet in de snelbalk. Dit is opgeslagen data, geen code: het staat op de rij <householdId>:vastgoed.lib/core/database/tables/foundation_tables.dart:185 (ModuleStates) en :236 (MemberModulePrefs)

Die laatste regel is niet zomaar de laatste. Alle veertien regels hangen aan het bestaan van een module met id vastgoed. Route, agenda-mirror, item-decoratie, reminder-resync, deelbeleid en instellingen zijn alle zes op dat id gesleuteld. Zodra vastgoed géén eigen module meer is, is elk van die zes een migratie in plaats van een gegeven. Dat is de reden dat de architectuurvraag hieronder eigenlijk al beslecht is — maar ik toets dat expliciet in plaats van het aan te nemen.

Wat hoort er in Vermogen?

Een vermogensoverzicht dat schulden negeert, is misleidend. Daarom twee lijsten: bezittingen en schulden. En een derde categorie die er bewust niet in hoort: kasstroom. Vaste kosten, abonnementen, verzekeringspremies en inkomsten zeggen iets over wat er per maand stroomt, niet over wat je hebt. Die horen in de kosten-hub en blijven daar.

Bezittingen

Schulden

Eén record, meerdere beelden — de belangrijkste ontwerpregel

Terechte zorg van de eigenaar: "Een hypotheek of lening kan in meerdere modules terugkomen, dus in meerdere contexten, net zoals een abonnement ook in vaste kosten kan zitten." De angst is een Vermogen-module waar alles in verdwijnt, waarna hypotheken en leningen niet meer in de vaste kosten opduiken.

Welk veld welk beeld voedt — dit is de tabel die zichtbaar maakt dat niets uit één context verdwijnt doordat het in een andere staat:

Eén regel uit die tabel verdient nadruk, want hij is een concrete bouwinstructie: de twee beelden lezen verschillende velden van dezelfde lening. De kosten-hub gebruikt de ruwe lening, want het maandbedrag staat altijd op de parent — leningdelen kennen geen eigen maandbedrag (loan_calc.dart:58-67). Het balansbeeld moet juist effectiveLoansProvider (leningen_providers.dart:78) gebruiken, want bij een hypotheek met delen is de restschuld de som van de delen. Twee projecties, twee leesroutes, één record.

Het levende voorbeeld: de brug vaste kosten ↔ abonnementen

Dit patroon is geen theorie; het is gisteren gebouwd. TEN-125 (commit 3b34391c) maakt van een vaste kost met categorie Abonnementen automatisch óók een abonnement in de Abonnementen-module, met de markering "Vanuit vaste kosten — nog te verrijken". Uit de commitboodschap: "Geen source-veld op de abonnement-post en geen dedup-guard: de hub dedupliceert al op linkKey" en "op dezelfde post, er komt er nooit een tweede bij". Eén onderliggende post, twee plekken waar je hem ziet en verrijkt.

Kunnen leningen datzelfde mechanisme volgen? Ja, maar ze hebben het minder nodig — en het verschil is leerzaam. Die brug bestaat omdat een vaste kost die je zelf intikt nog géén onderliggend record heeft; er wordt er dan één gestubd. Bij leningen is de richting omgekeerd: de lening is er eerst en de kostenpost wordt eruit afgeleid. Dat werkt al zonder koppelrij, omdat de hub live uit de module-repo leest. Een koppelrij is pas nodig als je het bedrag in de hub wilt kunnen afwijken van de lening (het "geaccepteerde bedrag"-mechanisme). Voor de omgekeerde weg — een maandlast intikken in de hub en daar een lening van stubben — geldt hetzelfde bezwaar dat TEN-125 bij verzekeringen liet staan: je zou rente, looptijd en restschuld moeten verzinnen, en die voeden een einddatum-reminder. Voorstel: geen lening-stub vanuit de hub.

De hoofdvraag, in drie varianten

De vraag die je nog niet hebt beantwoord: blijft vastgoed een eigen module die ónder Vermogen hangt, of wordt vastgoed een sectie binnen één Vermogen-module? Dat verschil raakt navigatie, module-registratie, per-module-instellingen, deelbeleid en tier-indeling. Hieronder eerst kort de nulmeting (wat er nu besloten staat), dan drie varianten.

Wat je moet weten over het modulesysteem om de varianten te kunnen wegen:

• Er is precies één groeperingsniveau boven modules: DomainDescriptor → ModuleDescriptor.domainId, een platte string (module_descriptor.dart:74 en :113). Er is géén ModuleGroup, géén parentModuleId, géén nesting. (Wél een data-container-begrip: object → boekingen. Niet verwarren.)
• Domeinen zijn vandaag de zichtbare groepering in Mijn leven: één sectiekop per domein met de modules eronder (mijn_leven_screen.dart:106-115 en :162-186), en collapsible groepen in Modules beheren (modules_beheer_screen.dart:212-257).
• De route /domein/:id met een generiek DomainScreen bestáát al (app_router.dart:252, domain_screen.dart:17), maar niets in de app linkt ernaartoe. Er ligt dus een ongebruikte navigatielaag klaar. → Achterhaald, zie de herzieningsnotitie hieronder: die navigatielaag is verwijderd.
• Een nieuw module-id kost: registry-regel, route, deelbeleid-regel, tier, en het krijgt automatisch een module-state-rij, member-prefs en een schermsnelkoppeling voor de favorietenbalk (module_quick_action_providers.dart:39-53).
• Tier zit op de descriptor en is runtime overrijdbaar zonder release via module_tier_overrides (module_tier_overrides.dart:44). Plus-handhaving staat sinds de server-side entitlements aan (plus_entitlement.dart:31) — dat is nieuwer dan de pricing-doc suggereert.
• Een domein met sensitive: true vereist een aparte AI-opt-in per domein-id (ai_gate.dart:36-38). Dat heeft een gevolg bij verhuizen; zie de kosten van variant A.

Naast elkaar

Aanbeveling

Waarom A en niet C. De vraag "module ónder Vermogen of sectie ín Vermogen" wordt niet beslecht door welke indeling het mooiste datamodel geeft, maar door wat er al gebouwd is. Aan het module-id vastgoed hangen zes registraties in code én drie soorten opgeslagen voorkeuren. Vastgoed heeft daarnaast dingen die geen andere bezitting heeft en ook nooit zal hebben: een boekingsmodel met gasten en periodes, overlap-detectie, twee verhuurmodi die de agenda-weergave bepalen, wisseldag-glyphs, een opzegtermijn-melding en een objectkleur die als avatar in de agenda meeloopt. Dat is geen "bezitting met een waarde" — dat is een mini-PMS. Een abstractielaag die daar een sectie van maakt, moet al die eigenschappen terugbouwen als uitzonderingen binnen de generieke laag. Dat is meer werk dan de laag zelf.

Waarom A en niet B. B is goedkoper en volstrekt verdedigbaar, en als het besluit "geef ons een vermogensoverzicht" was geweest, zou ik B adviseren. Maar het besluit is "Vermogen wordt de overkoepeling, vastgoed is er één onderdeel van", en in B is Vermogen de tiende tegel naast Vastgoed in plaats van erboven. Het duurdere deel van A is niet het domein (vier regels) maar de aggregatielaag — en die heb je in B óók nodig. De extra kosten van A boven B zijn dus klein: een domein-regel, drie verhuizingen, en één keer uitleggen aan de tester dat Leningen en Spaardoelen verhuisd zijn.

Waarom het cost-hub-patroon dit goedkoop maakt. Zie de volgende sectie: een vermogens-aggregatie is niet alleen hetzelfde patroon als de kosten-hub, hij is een eenvoudiger geval — de drie zwaarste onderdelen van de kosten-hub vallen weg. Dat is het verschil tussen een groot en een middelgroot project.

Wat A expliciet niet oplost. Leningen hoort inhoudelijk in twee domeinen en kan er maar in één; de AI-opt-in moet één keer opnieuw voor het nieuwe domein-id; en de tester ziet haar navigatie veranderen. Dat zijn de prijzen. Ik vind ze goedkoop tegenover het alternatief, maar ze zijn echt.

Hergebruik: kan de vermogens-aggregatie het cost-hub-patroon volgen?

Ja — en het is een eenvoudiger geval. Dat is de belangrijkste bevinding voor de omvangsschatting.

De kosten-hub bestaat uit een pure bouwfunctie buildCostHub (vaste_kosten/domain/cost_hub.dart:71) die genormaliseerde CostModuleItem-objecten uit meerdere modules samenbrengt (domain/cost_post.dart:58), dedupliceert op de sleutel '<moduleId>|<sourceRef>' (cost_post.dart:322) en via één provider aan één scherm wordt gehangen (vaste_kosten_providers.dart:67). Die vorm is één-op-één over te zetten:

Wat dat betekent voor de omvang. De drie duurste onderdelen van de kosten-hub (koppel-rijen met een eigen tabel en accept-flow, afwijking-signalering met een pijplijn naar Vandaag, en wees-beheer) zijn hier niet nodig. Wat overblijft is: één pure domeinfunctie met tests, één provider, één scherm, en een doorklik per regel naar de bronmodule. Voor de eerste versie: nul migraties, nul schemaVersion-bump, nul sync-config-wijziging — en dus ook geen 4-weg lockstep en geen prod-deploy-afhankelijkheid. Dat is de reden dat dit middelgroot is en niet groot.

Één ontwerpkeuze in de aggregatie: hard gedraad of via de registry

De kosten-hub draadt zijn bronnen hard: zes ref.watch-regels en een mapper per bron in de provider (vaste_kosten_providers.dart:68-115), plus drie hardgecodeerde switches in het scherm voor icoon, label en route (vaste_kosten_screen.dart:727/736/748). Er is géén uitbreidingspunt. Het alternatief bestaat óók al in deze app: FeatureModule.todayRowSources (module_descriptor.dart:184, geplat in module_providers.dart:42) laat modules zichzelf aanmelden.

Voorstel: begin hard gedraad — met drie bronnen is een registry-hook voorbarig — maar los meteen één bekend gebrek van de kosten-hub op: daar valt de hele hub in laden of fout zodra één bron dat doet (vaste_kosten_providers.dart:75-83). Voor een vermogensoverzicht is dat onaanvaardbaar: dan is het totaal leeg omdat de spaardoelen nog laden. Degradeer per bron ("spaargeld kon niet geladen worden") en toon de rest. Zodra beleggingen erbij komen (fase V3) is dat het natuurlijke moment om naar de registry-hook te gaan.

Open vragen — dit moet jij beslissen

Dit zijn geen implementatiedetails maar productkeuzes met een verkeerd antwoord. Ik doe per vraag een voorstel, maar ik ga het niet zelf beslissen.

Kunnen boekingen automatisch binnenkomen?

Onderzoeksvraag van de eigenaar: kunnen we de vastgoed-boekingen eenvoudig aan Uplisting, Airbnb of Booking hangen, zodat boekingen gesynchroniseerd binnenkomen in plaats van dat ze continu handmatig ingevuld moeten worden? Terechte wens: bij kortverhuur verandert de boekingslijst wekelijks, en gast, periode en status worden nu alle drie met de hand ingevoerd.

Het onderscheid dat de fout veroorzaakte — en dat het ontwerp bepaalt

Wij hoeven alleen te lezen: boekingen ophalen en wijzigingen ontvangen. Dat zit volledig in de eerste rij. Het schrijven van boekingen terug naar Uplisting — het enige waarvoor de partnerroute nodig is — is voor Tendlo geen wens: de bron van waarheid voor een verhuurboeking is de channel manager, niet onze app.

Uplisting is de voorkeursroute

Op elk punt beter dan de iCal-route die hieronder als terugval blijft staan:

• Eén koppeling dekt Airbnb én Booking.com. Uplisting is de channel manager die die kanalen al bundelt; de boeking draagt een channel-veld met waarden als airbnb_official en booking_dot_com. We hoeven dus niet per platform iets te bouwen — en we hoeven al helemaal niet langs de gesloten deuren van Airbnb en Booking.com (zie hieronder).
• Het is de eigen data van de gebruiker, geautoriseerd met zijn eigen key, in plaats van een publieke geheime kalender-URL. Dat is zowel functioneel als privacy-technisch een betere basis.
• Webhooks in plaats van pollen. booking_created, booking_updated en booking_removed — dus ook een expliciet signaal bij annulering. Precies wat iCal structureel niet kan (daar is een annulering een stille verdwijning).
• Annuleringen zijn opvraagbaar, niet alleen als gebeurtenis: de boekingenlijst per pand geeft ook geannuleerde boekingen terug, dus een herstel-na-downtime kan de werkelijkheid opnieuw vaststellen zonder te gokken.

Airbnb en Booking.com direct: dicht

iCal als terugval — voor wie geen Uplisting heeft

Uplisting is de beste route voor deze eigenaar, maar het vereist wel dat de gebruiker Uplisting-klant is (abonnement vanaf ongeveer £72 per maand). Voor de eigenaar is dat al zo; voor een willekeurige Tendlo-gebruiker met één vakantiewoning niet. Daarom blijft iCal in het ontwerp staan als tweede implementatie — en als vangnet mocht de Uplisting-API onvoldoende blijken. Wat erin zit verschilt sterk per platform, en dat bepaalt de belofte die je erbij zet:

Airbnb heeft zijn feed op 1 december 2019 bewust uitgekleed om privacyredenen: de titel is sindsdien letterlijk SUMMARY:Reserved en de omschrijving bevat alleen een link naar de reservering plus de laatste vier cijfers van het telefoonnummer. Booking.com geeft alleen datums met een statuslabel. Concreet betekent dat:

Wat de app al heeft — geldt voor de iCal-route

Dit is de belangrijkste bevinding van de hele sectie: Tendlo importeert al iCal-feeds, in productie, op twee plekken.

• Een volwaardige, tolerante iCal-parser — lib/features/gezin/sportkalender/data/ical_parser.dart (148 regels), gebouwd op het pakket icalendar_parser (pubspec.yaml:63). Die heeft de klassieke valkuilen al opgelost: UID-stabiliteit met een synthetische terugval als de feed geen UID geeft (:26-29), VALUE=DATE versus DATE-TIME (:40), UTC en TZID omgerekend naar toesteltijd met een terugval voor onbekende zones zoals Outlook's "W. Europe Standard Time" (:33-38), en een FormatException als de URL een HTML-foutpagina teruggeeft in plaats van een kalender (:4-5).
• Een werkend import-patroon met herkomst — sport_events.externalUid is nullable met de dartdoc "UID of the source VEVENT when this event was imported; null for hand-entered events" (sportkalender_tables.dart:81-84). De import doet zoek-op-uid-dan-bijwerken-anders-invoegen (drift_sportkalender_repository.dart:304-334), aangestuurd door importIcalForTeam (sportkalender_providers.dart:241) met een overrijdbare HTTP-client zodat het testbaar is (:48).
• Een tweede, onafhankelijke .ics-import voor de afvalkalender, mét bestand- én URL-invoer (afvalkalender/data/ics_afval_importer.dart).
• En de boekingssemantiek klopt al toevallig precies. Boekingen worden in deze app behandeld als half-open [start, end) met einde = check-out-dag, expliciet zodat rug-aan-rug-boekingen niet als overlap gelden (domain/booking_overlap.dart:8-10). Dat is exact de conventie die verhuurplatform-feeds gebruiken voor hun DTEND. De beruchte off-by-one op de vertrekdag is hier dus geen conversie maar een gelijkheid.

Wat dat betekent: een iCal-import voor boekingen is in deze app géén nieuw traject. Het is een derde toepassing van een patroon dat al twee keer draait en getest is.

Waar de sync draait — en waarom webhooks dat beslissen

Bij de Uplisting-route is dit geen afweging meer maar een gevolg: een webhook heeft een publiek HTTPS-eindpunt nodig. Dat kan een telefoon niet zijn. De sync hoort dus server-side, en het patroon staat er al: supabase/functions/revenuecat-webhook is precies dit — een edge function die een webhook van een externe partij ontvangt. Er staan zes edge functions in deze repo.

De rate limits maken pollen bovendien onaantrekkelijk: 5 verzoeken per seconde en 100 per minuut per IP, en maximaal 15 per minuut per pand. Eén server die pollt is te doen; vier gezinstoestellen die elk pollen, tikt met meerdere panden snel tegen die grens aan — en de API-key zou dan op elk toestel moeten staan. Bij de iCal-terugval geldt hetzelfde argument: Airbnb beperkt handmatig verversen expliciet ("we're only able to request updates from the other website so many times") en ververst zelf maar elke ~3 uur.

Herkomst en conflicten — de regel die dit veilig maakt

Zonder herkomst-veld overschrijft een import het handwerk van de gebruiker, of ontstaan er dubbele boekingen. bookings heeft nu géén herkomst-veld (vastgoed_tables.dart:80-106: object, gast, start, eind, status, bedrag). Dat is een additieve kolom, naar het model dat al bestaat.

• external_uid (nullable) — leeg = met de hand ingevoerd; gevuld = uit een externe bron. Exact zoals sport_events.externalUid. Omdat er nu twee bronnen in beeld zijn, hoort er een external_source naast (uplisting / ical): dezelfde boeking via twee routes moet niet twee rijen worden, en het scherm moet kunnen zeggen waar een boeking vandaan komt.
• Wie wint: een import mag alléén rijen aanraken met een external_uid dat hij zelf herkent. Handmatige boekingen worden nooit door een import gewijzigd of verwijderd. Velden die de gebruiker zelf heeft aangevuld op een geïmporteerde rij blijven staan; de import werkt alleen bij wat hij zelf geleverd heeft. Bij Uplisting kantelt dat deels: als gastnaam en bedrag uit de bron komen, is de bron daarvoor gezaghebbend en is de vraag juist omgekeerd — mag de gebruiker ze lokaal overschrijven, en verliest hij die aanpassing dan bij de volgende webhook? Voorstel: een handmatige wijziging op een geïmporteerd veld plakt (wordt niet overschreven) en het scherm laat zien dat het van de bron afwijkt.
• Verdwijnen is het lastige geval — bij iCal. Bij Uplisting is dit juist opgelost: er is een expliciete booking_removed-gebeurtenis en geannuleerde boekingen zijn opvraagbaar. Dat is een van de sterkste argumenten voor die route. Bij iCal geldt: een annulering levert géén tombstone: er is geen STATUS:CANCELLED en geen METHOD:CANCEL, de gebeurtenis houdt simpelweg op te bestaan. Het gevolg: een afgekapte of half-opgehaalde feed ziet er identiek uit aan "alles is geannuleerd". Voorstel: een verdwenen geïmporteerde boeking wordt gemarkeerd als "niet meer in de kalender" en de gebruiker beslist — precies zoals de kosten-hub een wees-koppelrij zichtbaar houdt in plaats van hem stil te verwijderen. En als er later automatisch geannuleerd wordt, alleen achter een sanity-guard: de feed moet schoon geparseerd zijn én netjes eindigen op END:VCALENDAR, en een feed die van veel naar bijna niets gaat, is een fout tot de gebruiker hem bevestigt.
• Voorlopige boekingen. Airbnb blokkeert de kalender óók voor aanvragen die nog op acceptatie wachten, en er komen "spook"-blokkades voorbij van afgebroken afrekeningen. Uplisting kent een filter hiervoor, de platforms zelf niet. Reken erop dat een klein deel van de geïmporteerde blokkades geen echte boeking is — nog een reden om automatisch verwijderen niet als eerste te bouwen.
• Overlap: de bestaande overlap-detectie blijft gelden. Een geïmporteerde boeking die overlapt met een handmatige is een signaal aan de gebruiker, geen fout die de import zelf oplost.
• Eén bron per object. Bij iCal: één feed-URL per object (twee platforms op hetzelfde object geeft anders twee rijen voor dezelfde week). Bij Uplisting: één koppeling per huishouden die álle panden dekt, waarbij elk Uplisting-pand aan een Tendlo-object gekoppeld moet worden — dat is een eenmalige "welk pand is welk object?"-stap die in het ontwerp hoort en makkelijk vergeten wordt.

Privacy — zwaarder bij de Uplisting-route, niet lichter

Drie dingen die geregeld moeten zijn vóór dit live gaat, en die nu niet in de privacyverklaring staan (docs/release/privacybeleid-concept.md):

• Gastnamen zijn persoonsgegevens van derden. Die gast heeft geen relatie met Tendlo en heeft nergens iets ingevuld. Hoeveel er meekomt hangt van de route af: uit Airbnb- en Booking-iCal komt geen naam (uit Airbnb wel de laatste vier cijfers van een telefoonnummer); uit Uplisting komt vermoedelijk juist het meeste — naam, e-mail én telefoon. Precies de reden dat de betere route ook de zwaardere privacyroute is. Dit hoort in §3.2 van de verklaring ("de gegevens die je zelf in de app zet" wordt "…en gegevens die via een verhuurkoppeling binnenkomen") met een rechtsgrond in §8, en het verdient een bewuste keuze of we e-mail en telefoon van gasten überhaupt willen opslaan. Voorstel: nee — sla naam en periode op, laat contactgegevens buiten Tendlo. Wat je niet opslaat, hoef je niet te beschermen.
• Er komt een verwerker bij, en de backend gaat meekijken. Uplisting wordt daarmee een ontvanger/verwerker die in §5.2 hoort ("de diensten die we inschakelen"), en omdat de webhook server-side landt, passeren gastgegevens onze eigen backend — anders dan bij een puur client-side import. Dat vraagt een regel in §5.2 en, bij echte uitrol, een verwerkersovereenkomst.
• De sleutel en de feed-URL zijn geheimen. Een iCal-feed-URL is een onbeveiligde geheime link: wie hem heeft, ziet de kalender, voor altijd. De Uplisting-API-key is erger: die geeft toegang tot het hele account. Geen van beide mag in logs, in foutrapportage (Sentry), in een screenshot of in een back-up terechtkomen, en geen van beide hoort op de toestellen — bij een server-side sync staan ze in de serveromgeving, niet in een gesyncte tabel. Dat is een verschil met mijn eerdere schets, waarin de feed-URL nog een kolom op het object was.

Tier

Een externe koppeling is typisch betaald, en dat komt hier gratis mee: Vastgoed is al Plus, dus de import zit automatisch achter de Plus-grens. Er is geen nieuwe tier-regel nodig. Wél een overweging: dit is precies het type feature dat een "Premium"-vlak boven Plus zou kunnen rechtvaardigen (open punt 8 in de pricing-doc). Nu niet beslissen.

Conclusie

Eén eigen ontwerp-gate waard voordat er code in gaat: het raakt een externe partij, een server-side component met een sleutel, twee kolommen, de privacyverklaring (drie paragrafen) en een gebruikersbelofte. Het hangt niet aan de Vermogen-varianten en kan dus los.

Herkomst van de claims in deze sectie

Waarschuwing voor wie dit later bouwt: er circuleert op GitHub een "Airbnb iCal sample" met volledige gastnamen, e-mailadressen en telefoonnummers. Die is verzonnen — hij spreekt Airbnb's privacywijziging van december 2019 tegen. Bouw je parserverwachtingen daar niet op.

Fasering — vroeg iets bruikbaars

Een leeg vermogensoverzicht dat pas na drie maanden klopt, is waardeloos. Daarom is V0 zo gekozen dat het op zichzelf waarde heeft en geen enkele migratie nodig heeft. Als je na V0 stopt, heb je nog steeds iets dat klopt.

Tier-indeling

Geldende split (owner-besluit 2026-06-17, vastgelegd in business/verdienmodel-en-pricing.md): 9 gratis — de vier kern-surfaces plus Maaltijden, Verjaardagen, Schoolvakanties, Afvalkalender en Bewaarlijsten — en al het overige Plus, inclusief álle AI en cloud-sync. Registry-default is Plus (module_descriptor.dart:108).

Redenen: elke bron die Vermogen aggregeert is zelf al Plus (Vastgoed, Leningen, Spaardoelen). Een gratis gebruiker zou dus per definitie een leeg scherm zien — dat is een slechtere ervaring dan een eerlijke Plus-badge. En als aggregatie over meerdere modules is het precies het type "overzicht dat je nergens anders krijgt" waar een abonnement voor is.

Twee dingen om te weten. Ten eerste: Plus-handhaving staat sinds de server-side entitlements aan (plus_entitlement.dart:31), met een harde router-gate (app_router.dart:273-295). Dat is nieuwer dan de pricing-doc zegt, die nog van "enforcement staat uit" uitgaat — die doc loopt achter en moet bijgewerkt worden. Ten tweede: de tier is runtime instelbaar zonder release via de tabel module_tier_overrides (module_tier_overrides.dart:44). Als je Vermogen tijdelijk gratis wilt openzetten als lokkertje, kan dat zonder store-release.

Als er ooit een pakketvlak boven Plus komt (in de pricing-doc staat "Premium" als open punt), is een vermogensoverzicht een plausibele kandidaat daarvoor. Dat is nu geen beslissing die genomen hoeft te worden — noteren is genoeg.

Tickets en ADR's

Hoe de tickets zich tot deze fasering verhouden

Moet er een ADR volgen?

Ja, en er moet er ook één vervangen worden. De conventie in docs/architecture/adr/ is NNNN-slug.md met een kop # ADR-NNNN — titel, een **Status:**-regel met datum en ticket, en de secties Context · Besluit · Alternatieven · Consequenties. Hoogste nummer nu is 0019, dus het volgende is 0020.

• ADR-0020 — Vermogen-positionering v2, te schrijven na jouw keuze. docs/architecture/adr/0012-vermogen-positionering.md moet dan op superseded met een verwijzing: besluit 2 van die ADR ("scherm/tab binnen Financieel, geen nieuw module-id") is precies wat 26 juli omdraait. ADR-0012 verwijderen mag niet — het archiefbeleid schrijft een banner met datum en verwijzing voor.
• ADR-0014 (rekenlaag) blijft grotendeels staan, maar zijn definitie van vermogen moet worden aangevuld met de uitkomst van de open vragen 1–5 (peildatum, dedupe-regel, bruto/netto, auto's, saldo).
• ADR-0018 staat nog op VOORSTEL en is deels ingehaald door de werkelijkheid: zijn sectie C (verhuurmodus + agenda) is inmiddels gebouwd en getest via TEN-120 (migratie 0076). Die ADR moet worden bijgewerkt naar wat er echt staat, en zijn secties A en B doorschuiven naar V2.
• Dit document is géén ADR: het is een levend ontwerpdocument met varianten en open vragen. De ADR's leggen de gekozen uitkomst vast; dit stuk legt de afweging vast.

Wat ik van je nodig heb om verder te kunnen

1. Een variant: A (aanbevolen), B, of C.
2. De zeven open vragen uit § Zeven — of minimaal 1, 2 en 3, want zonder die drie kan de rekenlaag niet gebouwd worden zonder aannames. Vraag 7 (hypotheek op meerdere objecten) hoeft níet vóór V0: mijn voorstel is dat V0 het huishoudniveau gebruikt, wat al correct is — maar als je wél overwaarde per object wilt, wil ik dat vóór V2 weten, want dan komt er een tabel bij.
3. Groen licht voor de Uplisting-route uit § Acht, plus twee kleine dingen die alleen jij kunt doen: de mail naar partner@uplisting.io voor de volledige API-documentatie, en of je wilt dat we samen één leesaanroep op je eigen account doen om te zien welke velden er echt in een boeking zitten. Daarna maak ik daar een eigen ontwerpronde voor. Dit staat los van de variantkeuze en mag later.

Zodra je een variant kiest, is de volgende stap: ADR-0020 schrijven, ADR-0012 op superseded zetten, en een implementatieplan voor V0 (dat is klein en migratievrij, dus dat kan meteen door de gewone fix-poort).