Wat er besloten is, waarom, en wat er nog open staat.

Bouw het navigatiemodel volgens concept E: vier tabposities — Vandaag · Dashboard · Mijn modules · Taken.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek, na het afwegen van vijf concepten in ../archive/implemented/design/navigatie-ontwerpconcepten.html.

Waarom

Springboard en widget-board waren tot dat moment concurrenten om één positie. Concept E maakt er twee antwoorden op twee verschillende vragen van: "waar is het?" (Mijn modules) en "hoe staat het ervoor?" (Dashboards). Daardoor hoeft Vandaag geen tweede rol te dragen en hoeft geen van beide oppervlakken zich te verantwoorden tegenover de ander.

Raakt

TEN-165 (koepel) · alle vier de fasen · vraagt een eigen ADR.

Volgorde bijgewerkt 6 augustus 2026. Hier stond Vandaag · Taken · Mijn modules · Dashboards. De eigenaar heeft de balkvolgorde vastgelegd in E-NAV-20: Dashboard staat op plek 2 en Taken op plek 4. Het model zelf verandert daar niet van — het blijven dezelfde vier oppervlakken met dezelfde rollen.

Houd Vandaag een gecureerd dagoverzicht; geef het geen tweede rol als widget-oppervlak.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek. Maakt concept D (Vandaag wordt zélf het board) overbodig.

Waarom

Zonder deze eis moest Vandaag zijn chronologie inleveren en die terugkopen met een verplichte "Je dag"-widget — een dure ruil die niets oplevert. Met een eigen Dashboards-tab vervalt de ruil. Praktisch gevolg: het beleid dat in fase 2 op Vandaag wordt vastgelegd, blijft daarna staan en hoeft niet nog eens omgegooid te worden.

Raakt

TEN-162 · fase 2 · gebied 2 in dit register.

Laat Taken zijn eigen tabpositie houden.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek. Dit is de verfijning die de eigenaar zelf aanbracht op het oorspronkelijke voorstel.

Waarom

Taken is het drukst gebruikte oppervlak van de app. Het van de tabbalk halen kost élke gebruiker een tik per bezoek, elke dag, permanent — en levert alleen ruimte op voor iets waarvan nog bewezen moet worden dat het een tabpositie waard is. De vrijgekomen positie komt van de Assistent, niet van Taken.

Raakt

TEN-165 · fase 3 · beantwoordt de openstaande vraag W5 · E-NAV-20 (wáár op de balk).

De tegenspraak met E-NAV-14 is beslecht — 6 augustus 2026: instelbaarheid wint, maar niet vóór fase 4. De vraag was: mag Taken van de balk als de gebruiker positie 4 met een andere module vult? Beide lezingen leverden werkende code op, dus dit is precies het soort punt dat een fixer stilzwijgend zou invullen. Het antwoord: deze eis gaat over de standaardstand — Taken is de standaardbezetting én de terugval van positie 4 (E-NAV-19), en wie hem zelf wegkiest doet dat bewust, met E-NAV-06 als vangnet (drie wegen naar Taken). De harde lezing — Taken kan er nooit af — is afgewezen, want dan is E-NAV-14 in zijn huidige vorm niet bouwbaar. Maar het geldt pas vanaf fase 4. In fase 1 t/m 3 ligt positie 4 vast op Taken en is er geen keuzelijst — dat is precies wat E-NAV-13 zelf al beschrijft. Er is dus geen tegenspraak, alleen een volgorde: een agent die vóór fase 4 aan de balk werkt, bouwt hier niets instelbaars.

Deze eis gaat over de tab, niet over de plek. Met E-NAV-20 staat Taken op plek 4 in plaats van plek 2. Dat raakt het argument hierboven niet: de prijs die hier vermeden wordt is een extra tik per bezoek, en die betaalt niemand — Taken houdt zijn tabpositie. Het prototype toonde die plek 4 trouwens al; wat daar als "oude stand" stond, is de besloten stand geworden.

Vervang de tab "Mijn leven" door het springboard "Mijn modules".

Herkomst

Ontwerpstuk §2 (concept B) · onderzoek, bevestigd door de eigenaar op 5 augustus 2026.

Waarom

Het huidige scherm toont 35 tegels van 136 px in 11 secties, in een volgorde die de gebruiker niet kan veranderen. Bij 29 modules is dat geen overzicht meer maar een catalogus. Een springboard met eigen volgorde, mappen en opruimen beantwoordt de vraag "waar is het?" en schaalt mee als er modules bij komen.

Raakt

TEN-163 · fase 1 · gebied 4 in dit register.

Het tablabel is beslist — 6 augustus 2026: het wordt "Modules". ADR-0024 liet de woordkeuze open en zei erbij dat hij vóór fase 1 vast moest staan. "Modules" vraagt ongeveer 41 px in plaats van 60, dus ruime marge in een tab van 64 px op een 360 px-scherm — ook bij grotere lettergrootte, waar "Mijn modules" bij textScaler 1.5 afkapte. Het scherm zelf mag wél "Mijn modules" heten: een tablabel is een wegwijzer, geen titel, en de twee hoeven niet gelijk te zijn. Concreet: l.tabsMyLife wordt "Modules", l.mijnLevenTitle blijft "Mijn modules". Dat verschil hoort expliciet in de brief, anders trekt een uitvoerder ze uit netheid gelijk.

Geef het widget-board een eigen Dashboard-tab in de tabpositie die de Assistent achterlaat; op de balk landt hij op plek 2.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek.

Waarom

Het board heeft een eigen oppervlak nodig, en de enige positie die zonder verlies vrijkomt is die van de Assistent — want AI verhuist toch al naar een permanente eigen plek (E-NAV-09). Geen enkel bestaand oppervlak levert dus iets in.

Raakt

Fase 3 · nieuw ticket "Dashboards-tab + widgetcontract" · gebied 5 · E-NAV-20 (wáár op de balk).

Bijgesteld 6 augustus 2026 — "de positie die de Assistent achterlaat" is een telling, geen plek. Wat vrijkomt is één van de vier tabposities; welk oppervlak waar op de balk staat, is met E-NAV-20 apart besloten. Uitkomst: Dashboard staat op plek 2 en Taken schuift naar plek 4 — dus naar de plek waar de Assistent vandaag staat. De onderbouwing hierboven blijft ongewijzigd: geen enkel bestaand oppervlak levert een tab in. Het prototype bouwt deze stand al.

Houd Taken bereikbaar via drie wegen: de band op Vandaag, een tegel op het springboard en een widget op het dashboard.

Herkomst

Afgeleid uit E-NAV-01 en E-NAV-03 · vastgesteld 5 augustus 2026.

Waarom

Dit staat hier zodat niemand het later als kost opschrijft. Dat Taken op drie plekken opduikt is geen dubbeling die opgeruimd moet worden — het is precies wat concept E belooft: hetzelfde ding benaderbaar vanuit "wat gebeurt er vandaag", "waar is het" en "hoe staat het ervoor". Wie dit als redundantie behandelt, sloopt de winst van het model.

Raakt

Fases 1–3 · reviews van elk van de drie oppervlakken.

Voer concept E uit in vier fasen: 1 Mijn modules · 2 Vandaag · 3 AI krijgt een eigen plek → board bouwen en beoordelen → Dashboards in de vrijgekomen positie · 4 vierde tab instelbaar en favorietenbalk optioneel.

Herkomst

Ontwerpstuk §8 · onderzoek, bevestigd en verfijnd door de eigenaar op 5 augustus 2026.

Waarom

De volgorde is geen planning maar een risicovolgorde. Fase 1 en 2 raken de tabbalk niet en leveren op zichzelf al winst. Fase 3 is de dure fase, en die begint bewust met de AI-plek: zolang AI geen eigen plek heeft, komt de vierde positie niet vrij en kan Dashboards er niet in. Binnen fase 3 wordt het board eerst gebouwd en beoordeeld vóórdat het een tabpositie krijgt — blijkt het voor een gratis gebruiker te dun, dan stopt E bij fase 2 zonder dat er iets half blijft staan.

Raakt

TEN-165 · drie nieuwe tickets (Dashboards-tab, AI-plek, instelbare vierde positie) · het implementatieplan.

Bijgesteld 6 augustus 2026 — fase 4 heeft er een voorwaarde bij gekregen. Sinds E-NAV-13 in zijn nieuwe vorm draagt de vierde positie een module. Moduleroutes zijn vandaag top-level en geen shell-branch, dus zonder E-NAV-12 bestaat de keuzelijst uit één regel (Taken) en is "instelbaar" een instelling zonder keuze — zie E-NAV-14. Fase 4 hangt daarmee aan E-NAV-12, en dat stond hier niet. De risicovolgorde blijft ongewijzigd: fase 1 t/m 3 raken dit niet, en E-NAV-08 staat nog steeds toe dat fase 4 wegblijft — dan blijft de balk staan zoals fase 3 hem achterlaat.

Lever elke fase op als een op zichzelf staand afgerond product; fase 4 mag wegblijven.

Herkomst

Afgeleid uit E-NAV-07.

Waarom

Als een fase alleen af is samen met de volgende, is de fasering een illusie en zit je vast zodra er iets tegenvalt. Fase 4 is bovendien de enige fase waarna de app per gebruiker verschilt en de enige die je niet stil terugdraait — daarom staat hij achteraan, en daarom mag hij ook overgeslagen worden.

Raakt

Werkpakket-indeling · elke fase-oplevering.

Geef AI een vaste actie in de kop (variant 3); in fase 3 alléén in de shell-AppBar.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek, op basis van de driewegvergelijking in ../archive/implemented/design/navigatie-ontwerpconcepten.html.

Waarom

Eén ingreep op één plek in de code bedient alle vier de shell-schermen; er hoeft in fase 3 geen enkel modulescherm aangeraakt te worden. Het patroon is al bewezen: TEN-164 zette op precies deze manier een instellingen-ingang op 29 moduleschermen zonder per scherm iets te configureren. De AI-knop is daar een tweeling van.

Raakt

Fase 3, stap 1 · nieuw ticket "AI krijgt een eigen plek" · beantwoordt de blokkerende vraag W7 · blokkeerde de Dashboards-tab.

Geverifieerd. AppIcons.ai bestaat al; de shell-AppBar draagt vandaag twee acties (agenda, inbox) en wordt op één plek gedefinieerd in lib/features/shell/app_shell.dart. Uitbreiden naar drie is één wijziging.

Herzien 6 augustus 2026 — de kern blijft, de variant vervalt. Wat overeind staat is de eis: AI krijgt een vaste, permanente eigen plek buiten de tabbalk, zodat de Assistent-tab vrij kan komen zonder dat de assistent iets inlevert. Wat vervalt is de uitwerking — "variant 3, een actie in de kop". Per E-NAV-10 woont AI in de rechterhelft van de centrale pil, op elk scherm. Lees deze eis dus als het besluit dát AI een eigen plek krijgt; E-NAV-10 zegt wélke. De hier genoemde route ("één ingreep in de shell-AppBar bedient alle vier de shell-schermen, geen modulescherm hoeft aangeraakt te worden") geldt niet meer: de pil vraagt juist dat de balk op álle schermen komt, en dat is een groter werkpakket. Dat staat eerlijk uitgeschreven bij E-NAV-10.

Splits de centrale knop in een pil met twee helften — vastleggen en AI — plaats hem laag (variant C), en toon de balk mét pil op álle schermen.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Begon als heropening ("De AI-knop zit nu ook altijd onder in de pil als we hem daar houden") en eindigde als besluit. Herziet zijn eigen uitspraak van 5 augustus, die de pil juist afwees.

Waarom

Eén gebaar geeft toegang tot de twee dingen die je onderweg wilt: iets vastleggen en iets vragen. Ze staan permanent op dezelfde plek, op elk scherm, en concurreren niet met de kop. En het houdt het Plus-pad prominent: voor wie geen Plus heeft is de AI-helft de zichtbaarste plek waar Plus zich laat zien, elke dag, zonder dat er een banner voor nodig is.

Raakt

Fase 3 · lib/features/shell/pa_fab.dart · lib/features/shell/pa_tab_bar.dart · lib/features/shell/app_shell.dart · E-NAV-09 (variant 3 vervalt) · E-NAV-12 (voorwaarde) · E-NAV-11 · E-MOD-09 · N-02 · ADR-0024.

Geverifieerd — de maten komen uit het prototype en uit de widgets. Vandaag: PaTabBar.height = 64, fabGap = 72, fabOverlap = 28 (pa_tab_bar.dart:31,34,38), en :51 asserteert vier tabs in een 2 + FAB + 2-opmaak (:77-88). Het langste label onder concept E is "Mijn modules", 60 px tekst. Op 360 px krijgt elke tab nu (360 − 72) / 4 = 72 px. De drie pilvarianten staan als CSS-variabelen in ../archive/implemented/design/prototype-concept-e.html, blok "Balk- en pilgeometrie".

Twee zorgen die hiermee juist vervállen. (1) De dubbele ingang. Zolang AI zowel in de pil als in de kop zou staan, waren er twee permanent zichtbare wegen naar dezelfde assistent — de dubbeling waar ADR-0024 voor waarschuwt. Met dit besluit is er één ingang, en die staat overal. (2) De kopdrukte. Omdat AI niet meer in de AppBar hoeft, worden de vaste kopacties er twee in plaats van drie; zie E-MOD-09 en E-NAV-18. De grens van vier uit E-NAV-11 blijft gelden en knelt daarna nog op precies één scherm.

Draag maximaal vier acties in een modulekop; de AI-actie komt erbij zolang er hooguit drie andere staan, en anders niet.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek: "Daarbovenin mag hij erbij komen als er maximaal drie andere icoontjes zijn, zodat er tot vier icoontjes zijn. Een vijfde icoon wordt, denk ik, te veel." Beantwoordt vraag W11 uit het ontwerpstuk §7, blootgelegd door TEN-164.

Waarom

Niet omdat vijf onmogelijk is — het past fysiek — maar omdat vijf een ruil tegen de moduletitel is, en die ruil wil je niet 29 keer hoeven maken. Zie de rekensom hieronder. Vier redt het zonder afweging; vanaf vijf moet je per scherm gaan wegen of de naam nog past, en dat is precies het soort per-scherm-oordeel dat E-MOD-09 wil opruimen. De grens is bovendien hard en geen richtlijn: zonder plafond groeit elke kop mee met elke nieuwe app-brede ingang, en dat is precies hoe de Afvalkalender ongemerkt op vier kwam.

Raakt

Fase 4 (AI op moduleschermen) · E-MOD-07 · E-MOD-09 · E-NAV-18 · TEN-164 (vervolg) · ADR-0024.

Geverifieerd — de telling klopt, en hier is hij volledig. Alle 29 moduleschermen bouwen hun eigen AppBar; TEN-164 leverde geen gedeelde kop maar een gedeelde actie (ModuleSettingsAction, lib/features/modules_beheer/presentation/module_settings_action.dart), met de afspraak: scherm-eigen acties eerst, dan het tandwiel, dan de ster (ShortcutMenuAction) als laatste. De acties zijn niet tier- of vlag-afhankelijk — op de landingsroute is het maximum gelijk aan het gewone aantal.

De grens bijt vandaag al, op één scherm. De Afvalkalender zit op vier en zijn kop is dus vol: de AI-actie komt daar niet bij, tenzij er iets anders wijkt. Op de vijf schermen met drie past AI er precies bij. Op de 23 schermen met twee of één past hij ruim. In de eindstand van deze eis alléén — dus zonder E-MOD-09 erbij — krijgt 28 van de 29 schermen een AI-knop en één niet.

De kop is voor wat je vaak doet; de instellingen zijn voor wat je één keer instelt.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Ontstond als vraag of er niet gewoon vijf iconen passen, en werd beantwoord met een betere vraag: hoort het importeren van een kalender niet gewoon in de instellingen van de afvalkalender?

Waarom

De grens van E-NAV-11 zegt hoevéél er in een kop mag; deze eis zegt wát erin hoort — en dat is de eigenlijke oplossing. Een kop die alleen dagelijkse handelingen draagt, komt vanzelf niet aan vier toe. Een kop waar ook de eenmalige instellingen in staan, loopt bij elke nieuwe module opnieuw vol, en dan zit je te onderhandelen over welk icoon mag blijven. De toets is bovendien te stellen zonder de code te kennen: doe je dit wekelijks, of deed je dit één keer toen je de module in gebruik nam?

Raakt

Fase 4 · E-NAV-11 · E-MOD-09 · E-NAV-10 · TEN-164 (vervolg — de bestemming bestaat al).

De bestemming hoeft niet gebouwd te worden. TEN-164 zette met ModuleSettingsAction (lib/features/modules_beheer/presentation/module_settings_action.dart) een instellingen-ingang op alle 29 moduleschermen, die zichzelf uit de route afleidt. Wat naar "de instellingen" verhuist, verhuist dus naar een blad dat vanuit elk modulescherm al één tik weg is. Deze eis kost daarom vooral verplaatswerk, geen nieuw oppervlak.

Zonder deze eis blijft het knellen — met, past alles. Sinds E-NAV-10 zit AI in de pil en niet in de kop, dus het vaste blok is zoeken + instellingen + favorietenster = drie. Dat laat precies één plek over voor een scherm-eigen actie binnen de grens van vier. Zes schermen hebben er vandaag één of twee — de Afvalkalender twee, en die zou met zoeken erbij op vijf komen. Na de toets hieronder houdt geen enkel scherm er meer dan één over, en past de grens van vier overal.

Houd de tabbalk zichtbaar in moduleschermen.

Herkomst

Prototype-feedback, 5 augustus 2026 · bevestigd als eigenschap van concept E.

Waarom

Vandaag verdwijnt bij het openen van een module de hele oriëntatie: geen tabbalk, geen favorietenbalk, alleen een terugknop. Van een module naar de instellingen van diezelfde module kostte daardoor zes handelingen. Met een blijvende tabbalk is een module een plek in de app in plaats van een uitstapje eruit.

Raakt

Router · lib/core/router/app_router.dart · fase 3/4 · eigen werkpakket.

Kostenwaarschuwing — geverifieerd. Dit is géén vlaggetje. De registry-moduleroutes staan vandaag in de top-level routes:-lijst, als broer van de StatefulShellRoute.indexedStack, niet erin. Ze de shell in trekken betekent: elke module een genest pad geven, per tab een eigen navigatiestapel bijhouden, en beslissen wat er gebeurt als je vanuit Vandaag een module opent en dan op tab 3 tikt. Reken op een navigatie-verbouwing en plan hem als zodanig in.

Deze eis is zwaarder gaan wegen — 6 augustus 2026. Hij stond hier als een op zichzelf staande verbetering van de oriëntatie. Sinds E-NAV-13 draagt hij ook fase 4: de vierde tabpositie wordt een module, en modules kunnen daar alleen komen te staan als hun routes shell-branches worden — precies wat deze eis doet. Zie E-NAV-14. En hij versterkt daarnaast E-NAV-10: zodra de tabbalk in moduleschermen staat, staat de centrale knop daar óók, en heeft die knop wél een moduleroute onder zich — het argument waarop de gesplitste pil op 5 augustus sneuvelde.

De deeplink-vraag is beantwoord — 6 augustus 2026: de herkomst bepaalt de terugweg. De kostenwaarschuwing hierboven noemt als productbesluit: "in welke branch landt een koud geopende deeplink naar /module/garanties, en wat gebeurt er als je vanuit Vandaag een module opent en dan op tab 3 tikt?" Antwoord: kwam je ergens vandaan — Vandaag, Modules, of zelfs een andere module — dan is dát je terugnavigatie: de module landt in díe branch en de terugweg voert daarheen terug. Is er geen historie, zoals bij een melding of een echte deeplink van buiten, dan is Mijn modules de terugval.

Let op: dit is een combinatie van de twee opties die op tafel lagen, dus beide helften moeten uitgewerkt worden. Wie alleen de terugval bouwt ("een module landt altijd in de Modules-branch") levert precies de helft die de gebruiker binnen de app nooit merkt — en breekt het gewone geval, want dan verlaat elke module-opening vanuit Vandaag stilzwijgend je Vandaag-stack. De herkomst-tak is het gewone geval; de terugval is het randgeval.

Zet drie vaste posities — Vandaag · Dashboard · Mijn modules — en maak alleen de vierde instelbaar, met een module als keuze.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Vervangt zijn eigen vorm van 5 augustus ("de vierde positie per lid instelbaar, met Dashboards als standaard").

Waarom

De drie basisschermen staan altijd en kunnen nóóit gekozen of uitgezet worden. De vierde positie is de keuze, en die keuze is een module — niet een van de basisschermen. In fase 1 t/m 3 staat daar alleen Taken; vanaf fase 4 kunnen er andere modules bij. Het argument van de eigenaar: "Doordat we daar niet een van de drie basisschermen in mogelijk maken die dan kan uitzetten, hebben we dit probleem helemaal niet." Een basisscherm kan zo per constructie niet onbereikbaar worden, en de open vraag daarover (E-NAV-17) verdampt in plaats van beantwoord te worden.

Raakt

Fase 4 · nieuw ticket "instelbare vierde positie + balk" · E-NAV-12 (draagt deze eis nu, zie E-NAV-14) · E-NAV-14 · E-NAV-19 · E-NAV-20 · E-OPS-01 (één sleutel erbij, geen migratie) · ADR-0024.

De opsomming ís de balkvolgorde — sinds 6 augustus 2026 besloten. Dat de eigenaar de drie vaste posities in déze volgorde noemde, liet twee lezingen toe; hij heeft de eerste bevestigd in E-NAV-20. De balk wordt Vandaag · Dashboard · Modules · Taken, dus de "vierde positie" uit deze eis is ook letterlijk de vierde plek.

Gevolg dat je moet uitspreken: de Assistent verliest zijn tab definitief. In de vorm van 5 augustus was de Assistent nog een van de keuzes voor positie 4. Nu de vierde positie een module draagt en de Assistent geen module is, is er geen weg terug naar de tabbalk. Dat is consistent met de verhuizing van AI naar de kop of de pil (E-NAV-09/E-NAV-10) — maar het maakt die verhuizing wel tot de énige ingang naar de assistent, en dus tot een besluit dat je niet halverwege kunt laten staan. /assistent blijft als branch bestaan; alleen de tab verdwijnt.

Correctie op het argument — het is sterk, maar het lost niet álles op. De blokkerende vorm van het geen-tab-actief-probleem is inderdaad weg: geen enkel basisscherm kan zijn tab nog kwijtraken, dus er is geen oppervlak dat onbereikbaar wordt. Dat is precies wat het panel en ADR-0024 als blokkerend markeerden, en dat vervalt. Maar de weergave "geen tab in accentkleur" moet er alsnog komen, en niet zuinig ook: met E-NAV-12 staat de tabbalk straks op 29 moduleschermen, waarvan er hooguit één de module op positie 4 is. Op de andere 28 is er dus geen actieve tab. Wat eerst een randgeval was, wordt de gewone stand — maar het is een renderregel van een paar regels, geen productbesluit meer.

De volgorde erbij, uitgesproken op 6 augustus 2026. "In fase 1 t/m 3 staat daar alleen Taken" stond hier als beschrijving; het is nu ook een instructie. Tot fase 4 ligt positie 4 vast op Taken: geen keuzelijst, geen voorkeur-lezing, geen halve aanleg daarvan. Zo is de spanning met E-NAV-03 geen tegenspraak maar een volgorde — zie de toelichting daar.

Beperk de keuzelijst voor tabpositie 4 tot wat de router kan dragen: tot E-NAV-12 af is, is dat alleen Taken.

Herkomst

Afgeleid uit E-NAV-13 (nieuwe vorm, 6 augustus 2026) · onderzoek in app_router.dart. Vervangt de eerdere vorm, die de lijst beperkte tot "oppervlakken die een shell-branch zijn en blijven" en Dashboards, Assistent, Agenda en Boodschappen voorstelde.

Waarom

Een shell-branch houdt zijn navigatie- en scrollstaat vast en heeft binnenin de tabbalk; een gewone push-route begint elke keer opnieuw en dekt de balk af. Een module op de tabbalk zetten terwijl haar route top-level is, levert dus een tab die je kunt aantikken maar die nooit actief kan oplichten — je duwt een scherm over de balk heen die je net hebt aangetikt. Daarom groeit deze lijst pas mee met E-NAV-12.

Raakt

Fase 4 · E-NAV-12 (voorwaarde, geen bijzaak) · E-NAV-13.

Geverifieerd — waarom Taken wél kan en de andere 29 niet. lib/core/router/app_router.dart:146-183 definieert precies vier StatefulShellBranches: /vandaag, /taken, /mijn-leven, /assistent. /taken is er één van, dus Taken kán vandaag op de tabbalk staan zonder één regel router. De 29 registry-moduleroutes staan als ...registryRoutes op :262 in de top-level lijst, buiten de shell — die kunnen het dus niet.

Nuance bij "de keuze is een module": Taken ís technisch geen registry-module. Er is geen ModuleDescriptor voor Taken; het id 'taken' staat in kCoreSurfaceModuleIds (lib/core/modules/module_registry.dart:15) — de set kernoppervlakken die voor ieder lid altijd aan staat, zónder persoonlijke activatie-toggle, zónder gezinsset-default en zónder beheerder-blokkade. In fase 1 t/m 3 wordt de vierde positie dus gevuld door een kernoppervlak dat toevallig ook een branch is. Dat is geen bezwaar — het is de reden dat E-NAV-19 Taken als terugval kan aanwijzen — maar noem het zo in het implementatieplan, anders gaat een fixer een ModuleDescriptor voor Taken zoeken die er niet is.

De spanning met E-NAV-03 is beslecht — 6 augustus 2026. Deze eis laat elke module positie 4 innemen, wat betekent dat Taken van de balk kan. Instelbaarheid wint — E-NAV-03 gaat over de standaardstand, en E-NAV-06 draagt de rest — maar pas vanaf fase 4. Tot dan is de lijst niet "één regel lang omdat de router het niet aankan", maar afwezig: positie 4 ligt vast. Dat maakt het verschil voor een uitvoerder in fase 1 t/m 3, die dus geen keuzemechanisme aanlegt waarvan de enige keuze Taken is.

Waarom de oude lijst vervalt. Dashboards is nu een vaste positie en staat dus niet meer in een keuzelijst; de Assistent verliest zijn tab definitief (E-NAV-13). Van de vier voorgestelde oppervlakken blijven er nul over. De prijskaartjes die ADR-0024 aan Agenda en Boodschappen hing — /agenda van push-route naar branch promoveren, en eerst een stabiel /boodschappen-pad maken — vervallen daarmee ook als fase-4-werk: onder het nieuwe model is de vraag niet "welke oppervlakken promoveren we" maar "wanneer doen we E-NAV-12".

Ontkoppel de tab-index van de branch-index vóór de Dashboards-tab landt.

Herkomst

Afgeleid uit E-NAV-05 en E-NAV-14 · onderzoek in app_shell.dart.

Waarom

Vandaag is de tab-index letterlijk de branch-index: de shell geeft hem rechtstreeks door. Zodra Dashboards een eigen branch krijgt terwijl /assistent als branch blijft bestaan, zijn het vijf branches en vier tabs en klopt de gelijkstelling niet meer. De afbeelding is klein (een constante lijst), maar hij verhuist daarmee van fase 4 naar fase 3 — en de hidden-module-redirect en de deeplinks mogen de oude aanname dan evenmin nog maken.

Raakt

Fase 3 · lib/features/shell/app_shell.dart · hiddenModuleRedirect · deeplinks.

Maak de favorietenbalk uitschakelbaar (fase 4).

Herkomst

Eigenaar, 5 augustus 2026 · gesprek.

Waarom

De balk kostte tot nu toe 52 px die niemand kon terugkrijgen. In een eerder voorstel was die ruimte nodig als AI-plek; met E-NAV-09 is dat niet langer zo. Daarmee is dit geen ruil meer maar een schone opruimkeuze: wie de balk niet gebruikt, hoort hem uit te kunnen zetten.

Raakt

Fase 4 · lib/features/shell/quick_actions/ · E-OPS-01.

Correctie na verificatie. De balk bestaat (ShellQuickActionsBar, vast 52 px in de shell-AppBar) en de inhoud ervan is al per lid instelbaar en gesynct via de _shell-rij. Maar de balk zelf kan vandaag niet uit: hij hangt onvoorwaardelijk in de AppBar en claimt zijn 52 px altijd, ook leeg (dan toont hij een "Beheren"-knop). Deze eis is dus nieuw werk, geen instelling die alleen nog ontsloten hoeft te worden.

Dashboards kan zijn tab niet kwijtraken: het is een vaste positie.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek — beantwoord door E-NAV-13, niet los besloten. Stond als vraag W10 uit ontwerpstuk §7.

Waarom

De vraag luidde: "wat gebeurt er met Dashboards als iemand tabpositie 4 aan iets anders geeft?" Onder het nieuwe model kán dat niet — Dashboard is een van de drie vaste posities en de vierde positie draagt een module. Het board is dus altijd één tik weg, en de vraag of het "een gewone bestemming of een tab-gebonden oppervlak" is, hoeft niet meer beantwoord te worden: het is een tab-gebonden oppervlak, permanent.

Raakt

Fase 4 · E-NAV-13 · nieuw ticket "instelbare vierde positie + balk" · ADR-0024.

Dit is een vraag die vervalt, geen vraag die beantwoord is. Het verschil doet ertoe voor wie later terugleest: er is geen afweging gemaakt tussen "board bereikbaar via Mijn modules" en "board als tab" — het model maakt de tweede variant de enige mogelijke. Wordt E-NAV-13 ooit herzien, dan komt deze vraag in volle omvang terug.

Blijft desondanks waar en waardevol: de tegel op Mijn modules waarmee het board in fase 3b beoordeeld wordt, mag blijven staan. Hij kost niets, hij bestaat al in die fase, en hij is de tweede weg die E-NAV-06 voor Taken óók vanzelfsprekend vindt.

Val terug op Taken als de module op tabpositie 4 wegvalt, en bewaar de keuze zodat de tab vanzelf terugkomt.

Herkomst

Afgeleid uit E-NAV-13 · het randgeval dat het nieuwe model overhoudt, uitgewerkt op 6 augustus 2026.

Waarom

Er is één gat dat het nieuwe model niet dicht: de gebruiker zet positie 4 op een module en zet die module daarna uit — of kiest een Plus-module en verliest Plus. Dan wijst de tab naar iets dat er niet meer is. Het gat is klein, maar zonder uitspraak vindt een fixer het pas als een tester erop stuit, en dan staat er een tab die crasht of leeg blijft.

Raakt

Fase 4 · E-NAV-13 · hiddenModuleRedirect · E-OPS-01 · E-OPS-03.

Waarom uitgerekend Taken, en waarom dit geen nieuw mechanisme is. Taken is het enige oppervlak dat zélf nooit kan wegvallen: 'taken' staat in kCoreSurfaceModuleIds (module_registry.dart:15) — altijd aan voor ieder lid, geen persoonlijke toggle, geen beheerder-blokkade, en gratis. Een terugval op iets dat zelf uitgezet kan worden, verplaatst het probleem alleen. En de vorm is bekend: hiddenModuleRedirect stuurt een verboden of Plus-gesloten moduleroute al naar een vaste bestemming (app_router.dart:287 en :298), en module_settings_action.dart:38 doet hetzelfde als je de module uitzet waar je in staat. Het enige nieuwe is welke bestemming.

Wegvallen en nog-niet-weten zijn twee verschillende dingen — 6 augustus 2026. De terugval hierboven mag niet ook bij elke koude start gebeuren. De entitlement wordt bij het opstarten opgehaald en geldt zolang als "geen Plus"; zonder maatregel zou de tab van een betalende gebruiker bij élke start eerst terugvallen op Taken en daarna terugspringen — en een tabbalk die tijdens het opstarten van bezetting wisselt leest als een defect. Besluit: de oppervlaktegate kent een derde uitkomst, nog onbekend; zolang die geldt houdt de balk zijn vorige bekende bezetting (en zonder vorige stand een rustige laadweergave). De terugval geldt pas als het verdict daadwerkelijk geweigerd is. Zie ADR-0022.

De keuze wordt niet gewist, alleen niet gehonoreerd — en ze staat in een eigen rij. De voorkeur blijft als id opgeslagen; de terugval gebeurt bij het lezen. Bijgesteld 6 augustus 2026: hier stond "in de _shell-rij". De tabkeuze krijgt een eigen rij voor navigatie, naast springboard, dashboards en Vandaag (zie E-OPS-04) — zodat je tabvoorkeur niet sneuvelt doordat je op een ander toestel je springboard herordent. Zet de gebruiker de module weer aan of komt zijn Plus terug, dan staat zijn tab er vanzelf weer — zonder dat hij hem opnieuw moet kiezen. Dat is exact de redenering van E-OPS-03 ("het item blijft in de lijst staan en rendert simpelweg niet") toegepast op de tabbalk, en het vraagt geen migratie en geen extra sleutel. Wat je ervoor accepteert: bij het aflopen van Plus verandert de tabbalk zonder aankondiging. Dat hoort mee in de tekst van het Plus-afloopscherm, niet in een eigen melding.

Zet de balk in de volgorde Vandaag · Dashboard · Modules · Taken; de vierde positie is ook de vierde plek, en Taken verhuist daarheen.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Beantwoordt de vraag die bij het vastleggen van E-NAV-13 ontstond en die twee kanten op kon: de opsomming Vandaag · Dashboard · Mijn modules was balkvolgorde, niet alleen een opsomming. Vervangt het voorstel dat hier stond (Taken op plek 2 houden, Dashboard op plek 4) — een eigenaar-uitspraak overrulet een advies.

Waarom

Dat Taken van plek 2 naar plek 4 schuift is bewust, geen bijvangst van de nummering. De drie vaste posities staan in de volgorde waarin je ze op een dag gebruikt — wat gebeurt er vandaag, hoe staat het ervoor, waar is het — en de instelbare plek staat achteraan, waar hij ook van bezetting mag wisselen zonder dat de rest verschuift. Daarmee is "de vierde positie" uit E-NAV-13, E-NAV-14 en E-NAV-19 letterlijk de vierde plek: één begrip in de code, in de instellingen en op het scherm, in plaats van een nummer dat iets anders betekent dan wat de gebruiker ziet.

Raakt

Fase 3c en 4 · E-NAV-01 · E-NAV-03 · E-NAV-05 · N-05 · lib/features/shell/pa_tab_bar.dart · ADR-0024 (B1, fase 3c).

Plek 4 is de rechteronderhoek, en die is voor een duim juist góéd bereikbaar. pa_tab_bar.dart:77-88 legt de rij hard uit als tab(0) · tab(1) · fabGap · tab(2) · tab(3): plek 2 ligt links van de centrale pil, plek 4 uiterst rechts. Hier stond eerder dat het drukst gebruikte oppervlak daarmee "naar de verste hoek" zou verhuizen. Dat argument gaat niet op. Op een telefoon in één hand ligt de duim in rust bij de onderrand aan de kant waarmee je vasthoudt; de rechteronderhoek is voor de rechterduim het gemákkelijkste doel van de hele balk, niet het verste — ver zijn de bovenhoeken. De prijs die E-NAV-03 wilde vermijden was een extra tik per bezoek, en die prijs betaalt niemand: Taken houdt zijn tab, alleen op een andere plek.

Wat er wél verandert, en voor wie. Bestaande gebruikers zien Taken één plek opschuiven — spiergeheugen dat één keer bijgesteld moet worden, en dat is de hele kost. Er verandert niets aan bereikbaarheid (elk oppervlak blijft één tik weg), niets aan de router (welke branch op welke index staat is een constante lijst, zie E-NAV-15) en niets aan de opmaak van de balk: het blijven vier tabs in de 2 + pil + 2-vorm. Wat mee moet: de golden test/features/shell/goldens/tab_bar_4.png en de labelvolgorde in app_shell.dart:26-34.

Het prototype houdt deze volgorde al aan. ../archive/implemented/design/prototype-concept-e.html definieert TABS als Vandaag · Dashboards · Mijn modules · Taken. Wat tot nu toe als "het prototype loopt achter op de tabvolgorde" in de leeswijzer stond, klopt daarmee niet meer: op dit punt liep het vooruit. Er komt hier dus geen corpuswerk-item bij — anders dan bij E-MOD-05, waar het prototype wél moet worden bijgewerkt.

Deel Vandaag in vier banden: Je dag · Nog te doen · Signalen · Klaar.

Herkomst

Ontwerpstuk §3 (variant T4) · onderzoek, bevestigd door de eigenaar op 5 augustus 2026.

Waarom

Vandaag bestaat nu uit vijftien secties uit elf bronnen, elk op een hardgecodeerd volgordegetal, elk met een eigen plafond of geen plafond. Elke nieuwe module vraagt opnieuw "op welk getal?" en niemand kan die vraag beantwoorden. Met vier banden kiest een nieuwe sectie een band, en de band bepaalt het plafond. De vraag verdwijnt in plaats van dat hij elke keer opnieuw beslecht wordt.

Raakt

TEN-162 · fase 2 · lib/features/today/ · TodaySection.orderHint.

Naast de vier banden staat een vijfde laag: chroom — besloten 6 augustus 2026. Vier secties passen in geen enkele band en hoefden dat ook niet: het Vandaag-menu, de gezinsstrook "wie doet wat", de quote en de stappenteller. Ze houden hun huidige plek en volgorde en vallen buiten het plafond van E-VDG-02. (De header stond al als chroom vastgelegd.)

Chroom is een eigen laag, geen vijfde band en geen restbak — en dat verschil is de hele instructie. Bandblokken renderen als blok; chroom-secties sorteren op hun eigen volgordegetal tussen die blokken door. Wie chroom als blok groepeert, schuift "wie doet wat" en het Vandaag-menu naar boven, naast de header — een zichtbare regressie. De toets op de uitvoering is één zin: de pagina blijft er exact hetzelfde uitzien. Wat het besluit óók vastlegt: het Vandaag-menu gaat dus niet naar "Je dag", en TEN-42 wordt niet teruggedraaid.

Toon maximaal één signaalkaart tegelijk; berg de rest op achter "en X meer…".

Herkomst

Eigenaar, 5 augustus 2026 · gesprek (besluit D1 in het ontwerpstuk).

Waarom

De aanspreekkaarten hebben vandaag drie losse budgetten van drie zonder gedeeld plafond, en discovery-kaarten staan bovendien boven de dagstroom. Op een vers account zie je daardoor vier kaarten vóór je eigen dag. Eén kaart dwingt de app om te kiezen in plaats van alles te tonen.

Raakt

TEN-162 · TEN-137 (suggestielaag) · TEN-150 (discovery) · fase 2.

Gevolg dat je moet accepteren. Met een budget van drie mocht de rangschikking middelmatig zijn. Met één kaart is de rangschikking het hele product van die band: kiest hij verkeerd, dan is dat de enige die de gebruiker die dag ziet. En "en X meer…" is daarmee geen restbak maar een tweede oppervlak dat doorzoekbaar moet zijn.

Die rangschikking is inmiddels vastgelegd. Op 6 augustus 2026 is de dringendheidsschaal beslist: een vaste rangorde in vier lagen, zie E-VDG-12. Daarmee is deze eis niet langer een belofte zonder mechanisme. Het plafond zelf wordt afgedwongen door een signaal-collector op de band en niet door een rijbudget per sectie — zie ADR-0021 en de herziening bij E-WID-15.

Herzien 6 augustus 2026 — de rest klapt inline uit, en het zoeken vervalt. Na het bekijken van build 1420 stelde de eigenaar vast dat "en X meer…" hoort te doen wat het zegt: de overige signaalkaarten verschijnen ónder de eerste, op het scherm zelf, en dezelfde knop klapt ze weer in. Er is dus geen tweede oppervlak meer — het bodemblad vervalt. Daarmee vervalt ook het zoekveld dat aan dat oppervlak hing: het gaat om hooguit een handvol signalen, en zoeken in vijf kaarten die je al ziet lost een probleem op dat er niet is. Lees de zin hierboven — "en X meer… is daarmee geen restbak maar een tweede oppervlak dat doorzoekbaar moet zijn" — dus als vervallen; wat eruit overeind blijft is dat het géén restbak is. Wat niet verandert: het plafond. Ingeklapt, de stand waarin het scherm opent, staat er nog steeds precies één kaart; alleen de weg naar de rest is korter. En de rangschikking blijft het hele product van deze band, want die ene kaart is nog altijd wat je zonder handeling ziet. Het veld TodaySignal.searchText blijft bestaan — het voedt de app-brede zoekfunctie, niet deze band.

Plaats de signaalkaart in band 3, nooit boven band 1.

Herkomst

Afgeleid uit E-VDG-01 en E-VDG-02.

Waarom

Eén kaart die bovenaan staat is nog steeds een kaart die vóór je dag komt. Vandaag begint met je dag; wat de app zélf opmerkt komt daarna. Zonder deze eis lost het plafond het probleem maar half op.

Raakt

TEN-162 · fase 2.

Laat een verstreken afspraak de hele dag staan; vink hem nooit automatisch af binnen de dag.

Herkomst

Eigenaar · besluit D3, gebouwd als TEN-144.

Waarom

"Voorbij" en "klaar" zijn twee verschillende dingen. Een afspraak die om 14:00 begon is om 15:00 voorbij, maar of hij klaar is, weet alleen de gebruiker. Hem automatisch wegzetten haalt informatie weg die iemand die dag nog nodig heeft — en verbergt precies datgene waarvan je wilt onthouden of het gelukt is.

Raakt

TEN-144 (gemerged) · lib/features/today/domain/today_schedule.dart · test/features/today/agenda_past_row_test.dart.

Geverifieerd — gebouwd. Een verstreken agendarij blijft in de dagstroom staan, gedimd en afvinkbaar. De semantiek "voorbij ≠ klaar" is expliciet in de code vastgelegd.

Schuif een verstreken afspraak 24 uur na de eindtijd automatisch door naar Klaar.

Herkomst

Eigenaar · tweede helft van besluit D3, gebouwd als TEN-175.

Waarom

Zonder deze helft blijft een niet-afgevinkte afspraak eeuwig in de dagstroom hangen en groeit Vandaag dicht met gisteren. 24 uur is lang genoeg dat de gebruiker de kans heeft gehad hem zelf af te vinken, en kort genoeg dat de dagstroom schoon blijft.

Raakt

TEN-175 (gemerged) · kAgendaAutoDoneGrace · test/features/today/agenda_auto_done_test.dart.

Correctie na verificatie. De grens loopt 24 uur vanaf de effectieve eindtijd van de afspraak, niet vanaf het einde van de kalenderdag — "de afspraak is wat de gebruiker onthoudt, niet de datum". Een afspraak zonder eindtijd krijgt één aangenomen uur; een hele-dag-afspraak eindigt om middernacht ná zijn eigen dag. De overgang wordt geschreven als een gewone dismissal, zodat ongedaan maken blijft werken, en vuurt hooguit één keer per item per dag.

Laat gebeurtenissen met hun dag verlopen; laat verplichtingen staan tot ze gedaan of weggelegd zijn.

Herkomst

Ontstaan als vraag bij TEN-175 ("hoe lang blijft iets op Vandaag staan?") · beslecht door de eigenaar op 6 augustus 2026.

Waarom

Het antwoord is geen nieuwe instelling maar een eigenschap van het soort item. Een verjaardag, een afvalbak, een afspraak — die hebben de volgende dag geen betekenis meer; ze horen te verlopen. Een taak, een boodschap, een openstaande betaling — die zijn morgen nog steeds verschuldigd; die horen te blijven. Een schuifknop "hoe lang blijft dit staan" zou de gebruiker laten instellen wat de app zelf hoort te weten, en zou bovendien op elke bron hetzelfde getal opdringen terwijl de bronnen wezenlijk verschillen.

Raakt

TEN-175 · fase 2 · TodayLane · lib/features/today/domain/today_schedule.dart · lib/features/today/domain/today_horizons.dart · E-VDG-09 · E-VDG-10.

Geverifieerd — dit regelt de achterkant, niet de voorkant. Er bestaat al een vooruitkijk-venster per module (todayHorizonDefaults, instelbaar in het instellingenblad): hoe ver vooruit een item opduikt. Dat venster blijft precies zoals het is. De registry codeert de nieuwe regel bovendien al gedeeltelijk: verjaardagen: 0 (alleen de dag zelf), de afvalkalender staat er bewust niet in ("buitenzetten is a same-day action"), en taken: 7 vooruit — met achterstallige taken altijd zichtbaar, want het filter is dagen ≤ venster en dat getal is negatief zodra iets over tijd is (idem voor onderhoud). Deze eis gaat over de achterkant: wat er gebeurt nadat de dag voorbij is. Vooruit is een instelling; achteruit is een eigenschap van het soort.

Grace: 24 uur na de eindtijd — hergebruikt uit TEN-175, geen nieuwe keuze. De eigenaar wil geen harde middernacht-grens, en die bestaat al: kAgendaAutoDoneGrace = Duration(hours: 24), geteld vanaf agendaItemEffectiveEnd. TEN-175 heeft de twee lastige gevallen al beslecht en die keuzes gelden nu voor élke gebeurtenis: een gebeurtenis zonder eindtijd krijgt één aangenomen uur (kAssumedAppointmentDuration, zodat iets dat net begonnen is niet meteen "voorbij" heet), en een hele dag loopt tot middernacht ná zijn eigen dag — niet tot 00:00 van de dag zelf. Een heledaggebeurtenis van maandag verlaat de dagstroom dus dinsdagnacht om 00:00, niet maandagnacht. Zo valt er niets onder iemands handen weg terwijl hij nog wakker is.

Laad de dag van gisteren mee zolang de uitloop van 24 uur nog loopt.

Herkomst

Afgeleid uit E-VDG-06 · gemeld door de fixer van TEN-175 en geverifieerd in de code op 5 augustus 2026.

Waarom

Vandaag laadt precies één kalenderdag: de agendaprovider mergt van now tot now, en de doorschuiflus loopt alleen over díe lijst. Een gebeurtenis van gisteren is dus alleen nog zichtbaar voor de regel zolang de merge van gisteren in het geheugen staat — alleen als de app over middernacht heen open blijft. Na een herstart is er niets meer om door te schuiven. Zolang dat zo is, is de uitloop uit E-VDG-06 een belofte die de app meestal niet waarmaakt: de gebeurtenis is na middernacht niet netjes doorgeschoven maar gewoon weg — precies wat de uitloop moest voorkomen. Daarom is dit geen losse afweging meer maar een gevolg: laad gisteren mee en filter, of de grace-periode bestaat alleen op papier. Dit is nadrukkelijk geen bug in TEN-175 maar een grens van het datamodel eronder.

Raakt

TEN-175 (vervolg) · todayEventsProvider en _todayEvents in lib/features/agenda/presentation/agenda_providers.dart · fase 2.

Twee dingen om in de begroting mee te nemen. De bestaande tests injecteren de agendalijst rechtstreeks en omzeilen daarmee de eendaagse merge — het herstartpad is dus niet gedekt en vraagt een eigen test. En Vandaag berekent now per build zonder ticker, dus er is ook geen timer die de regel opnieuw beoordeelt terwijl het scherm openstaat.

Deel elke Vandaag-bron expliciet in bij gebeurtenis of verplichting, en houd die indeling gelijk aan de baan.

Herkomst

Afgeleid uit E-VDG-06 · nagelopen tegen alle elf geregistreerde rijbronnen op 6 augustus 2026.

Waarom

Een regel die per soort verschilt, moet per bron te beantwoorden zijn — anders wordt het bij elke nieuwe module opnieuw een discussie. Het goede nieuws is dat de indeling al bestaat: elke rij draagt een TodayLane, en de vier banden dragen hem al zichtbaar — "Je dag" is de baan flow, "Nog te doen" is de baan todo. Deze eis maakt dat wat het nu impliciet is: flow = gebeurtenis, todo = verplichting. Een nieuwe bron kiest daarmee geen baan meer maar beantwoordt één vraag — verloopt dit met zijn dag? — en de baan volgt.

Raakt

Fase 2 · TodayLane in lib/core/today/today_item.dart · alle elf TodayRowSource-registraties · E-VDG-01.

Wat "weggelegd" betekent, verschilt per soort — en dat is precies goed. De dismissal-tabel is op (item, dag) gesleuteld. Voor een gebeurtenis is dat het einde: hij komt toch niet terug. Voor een verplichting is het "vandaag even niet" — hij staat er morgen weer, want de verplichting is niet verdwenen. Eén mechanisme, twee betekenissen, allebei de bedoelde. Let op bij het bouwen: die dismissals zijn local-only in PowerSync en dragen geen lid-id — ze synchroniseren dus niet en volgen je niet naar een tweede toestel. Voor gebeurtenissen is dat verdedigbaar; voor alles wat als verplichting telt, is het een bekend gat (zie E-VDG-11).

Geef agenda-items géén instelling "wil je dit afvinken" — stel bij het aanmaken één vraag: een afspraak is "moet je hier zijn", een taak is "moet je dit doen".

Herkomst

Eigenaar, 6 augustus 2026 · gesprek — bevestigt de aanbeveling uit docs/design/agenda-of-taak.html. Begon als vraag, hardop gedacht: "misschien is het verschil een taak met datum en tijd versus een echt agenda-item".

Waarom

Een schakelaar per agenda-item maakt van dat item een schaduwtaak: iets dat je afvinkt maar dat nergens meetelt. Het onderscheid dat de eigenaar zoekt bestaat al — taken, routines en afspraken zijn drie dingen in de app. Wat ontbreekt is niet een schakelaar achteraf maar een keuze bij het aanmaken. Die keuze wordt in gewone taal gesteld en de twee antwoorden staan hieronder letterlijk: het zijn de woorden die in de interface komen te staan. Het eerste antwoord wordt een afspraak — verloopt met zijn dag, geen vinkje. Het tweede wordt een taak met een tijd — afvinkbaar met een staat die synchroniseert, toewijsbaar met gevolg, telt mee, en blijft tot hij gedaan is. Dat is E-VDG-06 toegepast op het invoerscherm in plaats van op de weergave.

Raakt

Fase 2 · TEN-185 (randvoorwaarde) · lib/features/agenda/presentation/add_appointment_sheet.dart · lib/features/tasks/presentation/add_task_sheet.dart · docs/design/agenda-of-taak.html.

Het schaduwtaak-argument houdt stand — op twee van de drie punten, en het echte argument is sterker dan het derde. Geverifieerd: een als afspraak bewaard item telt niet mee in openstaande taken (de tellingen lezen alleen de takenlijst; de agenda staat er als los veld naast) en verschijnt niet in Taken. Maar "niet toewijsbaar" klopt niet letterlijk: een afspraak kent wél leden — er is een "Voor wie?"-kiezer — alleen is dat betrokkenheid, een ander veld dan de toewijzing van een taak, en er telt niets op. Wat het argument mist en wat zwaarder weegt: het vinkje op een agendarij is een local-only dismissal — die synchroniseert niet, draagt geen lid-id en volgt je niet naar een tweede toestel. Een afgevinkte afspraak is dus voor niemand anders afgevinkt en op je tablet niet gebeurd; een afgevinkte taak wél. Dát is de bodem onder de aanbeveling.

De randvoorwaarden zijn eigen werk, niet dat van deze eis. De volledige kolom-voor-kolom-vergelijking van de twee tabellen staat in docs/design/agenda-of-taak.html §4; de twee wegen om een taak met een tijd in de agenda te krijgen, met kosten, in §5. TEN-185 is de ingang voor de ontbrekende velden.

Geef de band "Nog te doen" een vaste voet "Alle taken ›", ook wanneer de band leeg is.

Herkomst

Ontwerpstuk §3 · onderzoek, versterkt door E-NAV-01.

Waarom

Onder concept E is deze band niet alleen een lijstje maar ook een navigatieroute naar Taken — een van de drie wegen uit E-NAV-06. Vandaag verdwijnt de hele sectie zodra er geen taken zijn, en daarmee verdwijnt ook de route. Een lege band hoort één regel te tonen ("Geen taken vandaag — Alle taken ›"), niet niets.

Raakt

TEN-162 · fase 2 · lib/features/today/…/todo_section.dart.

Geef een module twee schakelaars voor Vandaag: één voor items en één voor signalen.

Herkomst

Ontwerpstuk §7, vraag D6 · onderzoek, beslecht door de eigenaar op 6 augustus 2026: "Mogen er 2 zijn."

Waarom

Eén schakelaar is te grof: wie de suggesties van een module niet wil, wil de items vaak nog wél. Een app-brede knop geeft geen keuze per module. De twee schakelaars vallen samen met een grens die er al ligt: items dekt band 1+2 (rijbronnen — wat er van jou in de dag staat), signalen dekt band 3 (gaten en suggesties — wat de app zélf opmerkt). Dat is dezelfde scheiding als de vier-paden-grens, dus de schakelaars volgen de architectuur in plaats van er een tweede indeling overheen te leggen. Gelaagd zoals voorgesteld: persoonlijk, anders gezin, anders de standaard van de module.

Raakt

TEN-161 · TEN-162 · fase 2 · TodaySection.moduleId · TodaySection.band.

De blokkade op fase 2 vervalt. Deze vraag stond als blokkerend voor fase 2 genoteerd omdat TEN-161 er niet zonder gebouwd kon worden. Met dit besluit kunnen TEN-161 en TEN-162 in één beweging. Band 4 (Klaar) krijgt géén eigen schakelaar: die band toont wat de gebruiker zelf heeft afgehandeld en volgt dus de schakelaar van de band waar het item vandaan kwam.

Rangschik de signaalband op een vaste rangorde in vier lagen; laat de laag volgen uit de aard van het signaal en niet uit wat een module zelf vindt.

Herkomst

Eigenaar, 6 augustus 2026 · beantwoordt de vraag die ADR-0021 als "niet stilzwijgend in te vullen" had gemarkeerd: waarop weegt een uitnodiging tegen een aankondiging tegen een ongepland avondeten?

Waarom

E-VDG-02 zegt het zelf: met één zichtbare kaart is de rangschikking het hele product van die band. Een cijfer per signaal of "de meest recente wint" lost dat niet op — het eerste laat elke module zijn eigen belang inschatten, het tweede beloont wie het vaakst iets stuurt. De onderliggende regel is: hoe minder omkeerbaar het gemis, hoe hoger. Aan die regel wordt een nieuw soort signaal getoetst, niet aan gelijkenis met een bestaand voorbeeld. Dat de laag uit de aard volgt en niet uit een instelling is dezelfde keuze als bij gebeurtenis-versus-verplichting: zo kan een nieuwe module zichzelf niet vooraan zetten.

Raakt

TEN-162 · fase 2 · ADR-0021 (besluit 3, de signaal-collector) · E-VDG-01 · E-VDG-02 · public.announcements (nieuwe ernstkolom).

Binnen een laag wint de dichtstbijzijnde deadline; heeft geen van beide er een, dan het jongste signaal. Geverifieerd op 6 augustus 2026 welke bronnen dat vandaag kunnen leveren: suggesties heeft een echte vervaldatum (VandaagSuggestion.dueDate), announcement heeft startsAt/endsAt, share-hint heeft alleen recency (updatedAt), gaps heeft geen datum maar wel GapTone als ernstproxy, en discovery en invite hebben niets sorteerbaars. Uitnodigingen dragen zelfs geen tijdstempel, dus bij meer dan één uitnodiging is "het jongste" pas uit te rekenen als die bron een aanmaakmoment meelevert. Dit zijn de zes signaalbronnen die er zijn — de overige negen Vandaag-secties leveren dagrijen of chroom.

Aankondigingen kennen twee ernstniveaus. Een gewone aankondiging (nieuwe functie, tip) volgt de rangorde en kan dus achter "en X meer…" belanden. Een dringende (storing, gegevensverlies, iets dat actie vraagt) staat boven het plafond en verschijnt altijd — buiten de collector om, niet als laag 0 erbinnen, zodat hij niet met een uitnodiging om voorrang concurreert. Dat kost één vlag bij het versturen, gezet door de exploitant; technisch is dat een nieuwe kolom op de server-only tabel public.announcements, die vandaag geen ernstveld heeft (segment is doelgroep, geen ernst). Die vlag moet spaarzaam gebruikt worden, en dat hoort bij de knop te staan: een dringende aankondiging die niet dringend is, leert mensen de kaart te negeren — en dan werkt hij ook niet op de dag dat er écht iets aan de hand is. Dit is het enige mechanisme dat het plafond van E-VDG-02 mag doorbreken.

De spanning bij laag 2 is beslecht — 6 augustus 2026: de suggestiebron splitst per item. Het voorbeeld bij laag 2 — "een verlopende verzekering" — landt in de code op de suggestiebron, en die stond als bron in laag 4. Gekozen: lezing (a). Een suggestie mét een naderende vervaldatum valt in laag 2; de rest blijft laag 4. De bron bepaalt de laag dus per item in plaats van één keer voor alles. Lezing (b) — laag 2 reserveren voor bronnen die er nog niet zijn — is afgewezen.

Waarom, en wat het zichtbaar verandert. De aanwezigheid van een deadline is een eigenschap van het item, geen oordeel van de module — precies de onderliggende regel van deze eis, en het houdt overeind dat een module zichzelf niet vooraan kan zetten: hij kan alleen een datum melden die er is. Gevolg op het scherm: "verloopt over drie dagen" staat vanaf nu boven een aankondiging van de exploitant. Met een plafond van één kaart (E-VDG-02) is dat het verschil tussen die kaart wel of niet zien, en dat is de bedoeling. Voor de bouwer: de laag is een waarde per signaal, nooit een constante op de bron — anders staat de laag op twee plekken.

Sla springboard-volgorde, mappen, dashboards en de Vandaag-indeling per lid en gesynct op, in de bestaande _shell-rij van member_module_prefs.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek (besluit C1), onderbouwd met onderzoek in de database-laag.

Waarom

Twee dingen tegelijk. Inhoudelijk: een indeling is een persoonlijke voorkeur, geen huishoudensafspraak — het is jóuw beginscherm. Praktisch: de voorziening bestaat al en draagt vandaag de favorietenbalk en de inklapstanden op Vandaag. Aansluiten kost geen nieuwe tabel, geen migratie, geen sync-stream, geen RLS-regel en geen schemaVersion-bump. TEN-127 is het precedent dat dit patroon al bewezen heeft.

Raakt

Alle vier de fasen · lib/core/database/daos/member_module_prefs_dao.dart · powersync_cloud/sync-config.yaml · TEN-127.

Geverifieerd. De drift-tabel MemberModulePrefs bestaat met kolommen moduleId + prefsJson; de constante kShellModuleId = '_shell' bestaat en wordt al gebruikt voor favorieten en deel-hints. De rij-id is deterministisch '<ownerId>:<moduleId>' en een Postgres-trigger dwingt af dat het echt privé blijft. De sync-stream levert alleen de rijen van het eigen lid en is bewust niet opgenomen in de gedeelde stream. Let op de naamgeving in een ADR: de eigenaarskolom heet owner_id, er is geen member_id.

Bijgesteld: niet één _shell-rij, maar een rij per oppervlak — en sinds 6 augustus 2026 óók een eigen rij voor navigatie. De kop van deze eis zegt "in de bestaande _shell-rij"; ADR-0020 heeft dat op 6 augustus vervangen door één rij per oppervlak binnen dezelfde tabel (springboard · dashboards · Vandaag), omdat één gedeelde rij betekent dat twee toestellen die verschillende oppervlakken bewerken elkaar overschrijven. Later die dag is daar een vierde rij bij gekomen: de tabkeuze uit E-NAV-13/E-NAV-19 is geen oppervlak maar hoort ook niet in de gedeelde rij — zo kan je tabvoorkeur niet sneuvelen doordat je op een ander toestel je springboard herordent. Aan het "geen migratie"-antwoord verandert dit niets, en het telt ook niet op: het argument is per rij hetzelfde (vrije tekstkolom zonder CHECK, een trigger die alleen string-concat doet, een sync-query die er niet op filtert).

Sla de maat van een widget los van zijn configuratie op.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek.

Waarom

Anders is een maatwissel een vernietigende handeling. Wie een widget van "halve breedte · laag" naar "volle breedte · hoog" zet en daarbij zijn instellingen kwijtraakt, wisselt nooit meer van maat — en dan is het stelsel van vier maten dood papier. Deze eis is de voorwaarde onder E-WID-06.

Raakt

Fase 3 · nieuw ticket "Dashboards-tab + widgetcontract" · E-WID-06.

Wijkt af van het prototype. Het prototype bewaart een widget als één paar {module, maat} — de maat zit dáár ín het widget-record en er is geen aparte configuratielaag. Deze eis is dus een expliciete correctie op wat er in het prototype staat, en moet in het widgetcontract meegenomen worden vóórdat er data landt.

Sla posities op als id's, niet als indexposities.

Herkomst

Ontwerpstuk §5 en §6 · onderzoek, bevestigd door de eigenaar op 5 augustus 2026. Geldt voor springboard én dashboard.

Waarom

Een module die uitgaat of achter Plus verdwijnt, hoort zijn plek te houden. Bewaar je indexposities, dan schuift bij elk wegvallend item de hele indeling op en is de zorgvuldig gemaakte volgorde van een gebruiker in één sync-slag weg. Met id's blijft het item in de lijst staan en rendert het simpelweg niet — precies wat de favorietenbalk vandaag al doet met onbekende id's.

Raakt

Fase 1 en 3 · E-OPS-01 · E-MOD-10.

Bewaak de schrijfdruk op de _shell-rij: schrijf per sleutel, niet de hele rij.

Herkomst

Afgeleid uit E-OPS-01 · risiconotitie uit het ontwerpstuk.

Waarom

Die ene rij draagt straks zes soorten voorkeur in plaats van twee: favorieten, inklapstanden, deel-hints, springboard-indeling, dashboards en tabpositie 4. Bij last-write-wins kunnen twee toestellen elkaars wijziging overschrijven omdat ze van een andere gelezen basis vertrekken. Dit is geen reden om de opzet te verlaten — het is een reden om de schrijfvorm er nu al op in te richten.

Raakt

Alle fasen · sync · de patch-codec van de _shell-rij.

Herzien: de conflicteenheid is het oppervlak, en de tabkeuze krijgt er een eigen rij bij. Het "waarom" hierboven — één rij die straks zes soorten voorkeur draagt — is precies het probleem dat ADR-0020 op 6 augustus 2026 heeft opgelost, maar niet met "schrijf per sleutel". Per sleutel schrijven bestaat over de lijn niet: de kleinst mogelijke conflicteenheid is de kolom. De oplossing is daarom een rij per oppervlak — springboard, dashboards, Vandaag — en later op dezelfde dag is besloten dat de tabkeuze een eigen rij voor navigatie krijgt, naast die drie. Vier gescheiden rijen, dus vier gescheiden conflicteenheden.

Wat er van deze eis overeind blijft, en het is niet niks. Binnen één rij geldt nog steeds last-write-wins, dus schrijven gaat altijd via de patch-vorm (een patch over de opgeslagen bag), nooit als volledige bag-snapshot. Die codec bestaat en beschermt precies hiertegen; hem vervangen door een hele-bag-write sloopt de bescherming waarvoor hij gebouwd is.

Deel map- en dashboardnamen niet tussen leden.

Herkomst

Afgeleid uit E-OPS-01.

Waarom

Staat hier zodat het geen verrassing wordt. "Per lid" betekent dat lid B niet ziet wat lid A verzint — geen gedeelde mapnamen, geen gedeeld dashboard. Dat is de bedoeling, maar het is wél een verwachting die je in de teksten en in de gezinservaring moet meenemen.

Raakt

Fase 1 en 3 · gezinservaring · E-PLUS-07.

Sla de dashboardindeling op als een lijst van widget-instanties — elk met een eigen id, een maat en een eigen configuratie — niet als een verzameling module-id's.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek, als antwoord op open vraag V5 uit docs/archive/implemented/design/widget-interfaces-en-modulecontracten.html (TEN-179).

Waarom

Dit is de opslagkant van E-WID-13. Zolang een widget wordt bewaard als "module plus maat", kan dezelfde module maar één keer op een board staan en is vijf keer dezelfde lijstwidget met vijf verschillende lijsten onmogelijk. Met een eigen id per instantie is het onderscheid tussen twee widgets van dezelfde soort een gegeven in plaats van een randgeval — en kan een bewerking (maat wisselen, verplaatsen, verwijderen) precies één instantie raken.

Raakt

Fase 3 · E-OPS-01 (nog steeds dezelfde _shell-rij, nog steeds geen migratie) · E-OPS-02 · E-OPS-03 · TEN-179.

Overrulet het ontwerpstuk. TEN-179 stelt de recordvorm {moduleId, widgetId, maat, config} voor — zonder eigen instantie-id, met widgetId uniek binnen de module. Die vorm kan de eis hierboven niet dragen. Wat er wél uit blijft staan: maat en config náást elkaar (E-OPS-02), volgorde op id's en niet op posities (E-OPS-03), en de terugvalregel dat een ingetrokken maat terugvalt op de eerste beschikbare maat terwijl config blijft staan.

Bied een zichtbare knop "Nieuwe map" als primaire weg om een map te maken.

Herkomst

Prototype-feedback, 5 augustus 2026 · bevestigd door de eigenaar.

Waarom

Mappen zijn in dit ontwerp een randvoorwaarde, niet een extraatje: zonder mappen schaalt het springboard niet mee met 29 modules. Iets noodzakelijks mag niet afhangen van een gebaar dat je moet kennen, gericht moet uitvoeren, én alleen werkt in een stand die je ook al moet ontdekken. Dat is een te dun fundament.

Raakt

TEN-163 · fase 1.

Bied het sleepgebaar (tegel op tegel) als tweede weg naar een map — nooit als de enige.

Herkomst

Prototype-feedback, 5 augustus 2026 · bevestigd door de eigenaar.

Waarom

Het gebaar is snel en vertrouwd voor wie het kent, dus het verdient een plek. Maar de knop is de weg en het gebaar is de snelweg. Praktisch gevolg dat je in de planning mag gebruiken: valt het bouwen van het sleepgebaar duur uit, dan is dit het eerste dat sneuvelt zonder dat er functionaliteit verdwijnt. Bij een omgekeerde keuze zou het schrappen van het gebaar de functie zelf onbereikbaar maken.

Raakt

TEN-163 · fase 1 · E-MOD-01.

Maak een module uit een map sleepbaar, met daarnaast een niet-sleep-weg via het lang-indrukmenu.

Herkomst

Prototype-feedback, 5 augustus 2026 · eigenaar.

Waarom

Dezelfde redenering als E-MOD-01, maar dan voor de omgekeerde beweging. Een map in kunnen zonder eruit te kunnen is een val. En omdat het lang-indrukmenu er toch al is (verplaatsen, van beginscherm halen, op Vandaag tonen, instellingen), kost de tweede weg hier bijna niets.

Raakt

TEN-163 · fase 1 · TEN-164 (het menu bestaat al).

Laat een map die leeg raakt vanzelf verdwijnen.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Sleept de gebruiker de laatste module eruit, dan is de map weg.

Waarom

Het is het gedrag dat iedereen van iOS kent — daar hoeft niemand iets voor te leren, en afwijken van een bekend patroon kost meer dan het oplevert. En een lege map is een lege huls: hij vertegenwoordigt niets meer, neemt wel een plek in het raster in, en levert alleen opruimwerk op dat de gebruiker later zelf moet doen.

Raakt

TEN-163 · fase 1 · E-MOD-03 · E-MOD-05 · E-MOD-10 · E-OPS-03.

Geverifieerd — het prototype bouwt dit al zo; schets en besluit lopen gelijk. ejectFromFolder() in docs/archive/implemented/design/prototype-concept-e.html doet if(f.items.length===0){ S.board.splice(fi,1); … dissolved=true; }, en de hint in het mappaneel zegt letterlijk: "Haal je de laatste eruit, dan verdwijnt de lege map vanzelf." Er hoeft dus niets herbouwd te worden — dit besluit bevestigt wat er staat.

Correctie op dit register. Bij deze eis stond tot vandaag als herkomst: "het prototype laat een lege map gewoon staan". Dat klopt niet en heeft de vraag zwaarder doen lijken dan hij was; de regel hierboven is er sinds de tweede prototyperonde.

Laat een tegel die uit een map wordt gehaald achteraan op het springboard landen.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek: "aangezien je vanuit een drawer sleept die over icons heen gaat is het precies neerzetten sowieso niet echt handig."

Waarom

Je mikt op een beginscherm dat op dat moment achter het mappaneel ligt — je ziet niet waar je loslaat. Doen alsof de losplek betekenis heeft is dus schijnprecisie: de gebruiker krijgt een uitkomst die van toeval afhangt en die hij niet kon sturen. Achteraan is altijd dezelfde plek, ongeacht waar je loslaat, en het is bovendien het enige antwoord dat óók klopt voor de menu-weg uit E-MOD-03, waar helemaal geen losplek bestaat. Daarmee geven de twee wegen hetzelfde resultaat — wat de eigenlijke vraag was.

Raakt

TEN-163 · fase 1 · E-MOD-03 · E-MOD-04 · E-OPS-03 · corpuswerk (prototype bijwerken).

Wijkt af van het prototype — het prototype moet hierop aangepast worden. ejectFromFolder() zet de tegel vandaag direct naast de map (var at=fi+1), met in de toelichting exact dezelfde onderbouwing over het niet kunnen mikken, maar met een andere uitkomst: "Achteraan zetten is wél voorspelbaar, maar dan moet je hem gaan zoeken in een raster van 29 modules. Naast de map is allebei." De eigenaar kiest anders, en een eigenaar-uitspraak overrulet een ontwerpstuk. Het besluit hierboven geldt; het prototype loopt achter en staat als los punt op de corpuswerk-lijst.

Gebruik de domeinen als startpunt in de vorm van mappen; op het beginscherm van de gebruiker vervangt de map het domein. In de catalogus blijft het domein de vaste categorie.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Neemt het voorstel uit ontwerpstuk §7 (vraag E1) over. Herformuleerd op de avond van 6 augustus 2026, toen de eigenaar de grens uitsprak: domeinen ordenen wat de app te bieden heeft, mappen ordenen wat de gebruiker ervan gemaakt heeft.

Waarom

Eén ordeningsbegrip per gebied, niet twee door elkaar. Bij de overgang worden de bestaande domeinen eenmalig omgezet naar mappen, zodat niemand op een leeg raster start; vanaf dat moment is op het springboard en het dashboard de map de waarheid. Twee begrippen dóór elkaar op hetzelfde scherm zou betekenen dat de gebruiker moet snappen waarom zijn eigen map niet hetzelfde is als een domein — en dat is een uitleg die je nooit meer kwijtraakt. Maar in de catalogus — onboarding, modulebeheer, meldingeninstellingen, AI-instellingen — heeft de gebruiker nog niets ingericht; daar is een map leeg begrip en het domein juist de enige beschikbare ordening.

Raakt

TEN-163 · fase 1 · /domein/:id (vervallen — verwijderd met F1-9, merge 20f1b910, 6 augustus 2026) · E-MOD-04 · E-OPS-03. Niet modulebeheer, onboarding, meldingeninstellingen of AI-instellingen — die blijven op domein ordenen.

Correctie op de telling: het zijn er tien, niet elf. Er bestaan precies tien DomainDescriptors, elk gedeclareerd in zijn eigen feature-module en samengevoegd in module_registry.dart:43-45: gezin, planning, financieel, huis, gezondheid, vastgoed, voorraad, documenten, bewaarlijsten en welzijn. De elfde sectie op Mijn leven is geen domein maar de gecureerde "Populair"-strook (mijn_leven_screen.dart:66-102). Er worden dus tien mappen aangemaakt bij de conversie, niet elf.

En op 6 augustus 2026 werden het er zes — deze telling is achterhaald. De correctie hierboven beschrijft de registry zoals die tot 6 augustus 2026 was; sinds merge 0ea70a81 staan de zes domeinen op één plek in lib/features/app_domains.dart:81-120 en zijn de tien domein-id's hierboven verdwenen (financieel heet nu geld). Met E-MOD-13 zijn de tien domeinen opnieuw gesneden tot zes — Eten · Gezin · Huis · Geld · Gezondheid · Bewaren — en maakt de conversie dus zes mappen. Deze eis zelf verandert niet: domeinen worden mappen, en de map is daarna de waarheid van de gebruiker. Alleen het getal eronder verandert, en de reden staat in E-MOD-13: vier van de tien domeinen heetten precies zoals hun enige module, en zes van de tien droegen er maar één. Dat er zes mappen zijn en niet tien is dus geen bijstelling van deze eis maar het gevolg van een besluit erboven.

Geef het mappaneel een "Map opheffen"; de modules komen terug op het springboard op de plek waar de map stond, in hun onderlinge volgorde.

Herkomst

Eigenaar, avond 6 augustus 2026 · beantwoordt de vraag die het fase-0/1-plan als §6 open vraag 4 had genoteerd ("bestaat map opheffen?"). Het prototype had de knop al zonder dat er een eis over ging.

Waarom

Zonder deze handeling is een map met acht modules alleen ontbindbaar door acht keer uit te halen — en dan staan ze alle acht achteraan, in een volgorde die van je tempo afhing. Dat is geen opruimhandeling maar een straf op het proberen. En dat de plek van de map behouden blijft, is hier wél te verantwoorden: een map ís een groep die bij elkaar hoort en die de gebruiker zelf op die plek heeft gezet. De plek draagt betekenis die hij zelf heeft aangebracht.

Raakt

TEN-163 · fase 1 · F1-8 · E-MOD-04 · E-MOD-05 · E-OPS-03.

Geverifieerd — het prototype doet dit hier al goed, in tegenstelling tot ejectFromFolder. dissolvefolder in docs/archive/implemented/design/prototype-concept-e.html:2420-2425 vervangt de map-entry door zijn items op dezelfde index: S.board.splice.apply(S.board,[fi,1].concat(items)), met een melding "Map … opgeheven". Dat is exact deze eis. Bij deze knop loopt het prototype dus niet achter en mag hij als referentie dienen — anders dan bij ejectFromFolder en rmtile/rmbyid, waar hij dat wél doet (E-MOD-05, E-MOD-10).

Twee dingen die hierbij horen en niet vergeten mogen worden. Eén: opheffen krijgt dezelfde melding met "ongedaan maken" als E-MOD-04 en E-MOD-05 — terugdraaien zet de map terug op zijn index, met zijn naam en zijn hele inhoud. Eén mechanisme bedient nu drie eisen. Twee: opheffen is een handeling van de gebruiker en verwijdert de map dus echt, ook als er nog niet-renderende id's in staan — dat is de grens uit E-MOD-10, en die id's verhuizen mee naar het springboard in plaats van te verdwijnen.

Toon bij een zoekresultaat de naam van de map waar de module in zit.

Herkomst

Prototype-feedback, 5 augustus 2026 · door de eigenaar expliciet als waardevol bevestigd.

Waarom

Mappen maken dingen vindbaar én verstoppen ze. Zoeken kijkt dwars door mappen heen, maar zonder de mapnaam leert de gebruiker nooit wáár iets staat en blijft hij zoeken in plaats van navigeren. De mapnaam maakt van elk zoekresultaat een kleine les in de eigen indeling.

Raakt

TEN-163 · fase 1.

Geef het springboard een zoekveld bovenaan.

Herkomst

Ontwerpstuk §2 · onderzoek, daar aangeduid als harde randvoorwaarde.

Waarom

Zodra de gebruiker mag ordenen, verbergen en in mappen stoppen, is er geen vaste plek meer waar iets "hoort" te staan. Zoeken is de ontsnapping die dat mogelijk maakt. Zonder zoekveld is elke opruimhandeling ook een risico.

Raakt

TEN-163 · fase 1 · E-MOD-07.

Geef elke module bovenin dezelfde kop, met zoeken en instellingen.

Herkomst

Prototype-feedback, 5 augustus 2026 · door de eigenaar expliciet als waardevol bevestigd, en gevraagd consequent over de hele app. Bijgesteld 6 augustus 2026: de derde vaste actie (AI) vervalt.

Waarom

Vandaag verschilt elke modulekop en moet je per module opnieuw leren waar iets zit. Dezelfde vaste acties op dezelfde plek maakt van 29 losse schermen één app. De instellingen-ingang is met TEN-164 al zo gebouwd — die leidt zichzelf af uit de route en werkt daardoor op alle moduleschermen zonder per scherm iets te configureren. Zoeken volgt dat patroon.

Raakt

TEN-164 (gemerged, levert het patroon) · E-NAV-10 · E-NAV-18 · begrensd door E-NAV-11 (hoeveel acties past een kop).

Waarom AI hier verdwenen is. Deze eis vroeg drie vaste acties: zoeken, AI en instellingen. Sinds E-NAV-10 zit de AI-ingang in de centrale pil, en die pil staat op álle schermen — dus ook op elk modulescherm. Een tweede AI-knop in de kop zou daar direct boven staan: twee ingangen naar dezelfde assistent, in één beeld. Hij vervalt dus niet omdat AI minder belangrijk werd, maar omdat hij er al staat.

Wat dat oplevert, en wat het niet oplevert. Het vaste blok is nu zoeken + instellingen — plus de favorietenster, die deze eis nooit noemde maar die op 28 van de 29 moduleschermen staat. Vast blok = drie, dus binnen de grens van vier (E-NAV-11) blijft er één plek over voor een scherm-eigen actie. Dat is niet vanzelf genoeg: de Afvalkalender heeft er twee en zou op vijf uitkomen. Wat daar gebeurt staat in E-NAV-18 — de ICS-import verhuist naar de module-instellingen, en dan past het.

Onthoud de plek van een module die uitgezet wordt: het id blijft in de map staan en rendert niet.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek — akkoord met het voorstel uit ontwerpstuk §7 (vraag C2) zoals het hier stond.

Waarom

Vergeet de app de plek, dan komt de module bij heraanzetten ergens anders terug en is de indeling van de gebruiker stiekem veranderd — een verandering die hij niet heeft aangebracht en niet kan terugdraaien, omdat hij niet weet dat het gebeurd is. Onthouden betekent dat uitzetten en weer aanzetten samen niets doen, en dat is de enige uitkomst waarbij een gebruiker zijn ordening durft te vertrouwen.

Raakt

TEN-163 · fase 1 · E-OPS-03 · E-MOD-04 · E-MOD-06.

Geen gevolg voor het opslagformaat — dat is al besloten. E-OPS-03 legt vast dat posities als id's worden opgeslagen en niet als indexposities, met exact deze motivering: "met id's blijft het item in de lijst staan en rendert het simpelweg niet — precies wat de favorietenbalk vandaag al doet met onbekende id's". Deze eis is dus de toepassing van E-OPS-03 op mapinhoud, geen nieuwe vorm. Er is geen extra veld, geen migratie en geen tweede lijst met "onthouden plekken" nodig.

"Van beginscherm halen" valt hier óók onder — besloten 6 augustus 2026. Het prototype heeft twee wegen om een tegel van het springboard te halen: het minus-knopje in de bewerkstand en "Van beginscherm halen" in het lang-indrukmenu. Of dat een andere handeling was dan uitzetten — met een eigen opslageffect — stond open. Antwoord: het onthoudt zijn plek. De positie blijft opgeslagen maar rendert niet; zet je de module weer aan, dan staat hij terug wáár hij stond, inclusief in de map waar hij in zat. Dat is exact het patroon dat de favorietenbalk al gebruikt met onbekende id's, en dus deze eis toegepast op een tweede handeling — geen nieuw begrip. Wat daarmee is afgewezen: een aparte "niet op mijn springboard"-staat naast uitzetten. Die zou een vijfde poort toevoegen aan een zichtbaarheidsgate die er al vier heeft, met tegengestelde faalrichtingen.

Het prototype doet dit verkeerd, en dat is corpuswerk. ../archive/implemented/design/prototype-concept-e.html haalt bij beide wegen het item uit de indeling. Dat is het tegenovergestelde van dit besluit en het is de gevaarlijkste van de plekken waar het prototype achterloopt: een uitvoerder die het als referentie neemt, bouwt een eenrichtingsdeur. Het prototype moet worden bijgewerkt of van een zichtbare notitie voorzien.

Bepaal de kern uit een regel, niet uit een lijst: kern is een module waar andere modules op voortbouwen. Dat zijn er drie — Agenda, Taken en Lijstjes.

Herkomst

Eigenaar, avond 6 augustus 2026 · gesprek, naar aanleiding van bevinding A-OB-1 uit de sectie-audit (V1) in het fase-2-plan.

Waarom

De kern-set was een historische lijst: vier id's die ooit de eerste tabbladen waren. Zo'n lijst kan geen enkele volgende vraag beantwoorden — bij elke nieuwe module begint dezelfde discussie opnieuw, en er is geen argument om hem mee te winnen of te verliezen. De regel is: kern is wat een hoofdentiteit levert waar andere modules op voortbouwen. Een afspraak (Agenda), een taak (Taken) en een lijst (Lijstjes) zijn de drie dingen waar de rest van de app in praat: modules maken taken aan, hangen dingen in de agenda en leggen lijsten aan. Zet je die uit, dan valt er meer om dan die ene module. Dát is wat "altijd aan" rechtvaardigt, en niets anders.

Raakt

TEN-163 · fase 1 · fase 2 (V8, V10) · kCoreSurfaceModuleIds (module_registry.dart:14-19) · module_providers.dart:396 · modulebeheer (modules_beheer_screen.dart:120-151, modules_beheer_providers.dart:34,:62, module_settings_action.dart:78) · E-VDG-08 · E-MOD-06.

Wat er meebeweegt, en wat expliciet níet. Zijn Vandaag-rijbron draagt al moduleId: 'boodschappen' (shopping_today_source.dart:50-52) en zijn assistent-bijdrage staat al achter een zichtbaarheidscheck (assistant_providers.dart:390); die twee gaan vanzelf werken zodra de poort niet meer onvoorwaardelijk true geeft — dat is het hele punt. Niet mee verandert het deelbeleid: Boodschappen blijft één gezinslijst en wordt niet ineens naar privé configureerbaar (share_policy.dart:134-136, TEN-55).

Bijgesteld 6 augustus 2026 — de staart van deze eis telde verkeerd. Hier stond: "en E-MOD-06 gevolg 1 telt voortaan drie losse kernoppervlakken boven de mappen in plaats van vier". Dat klopt half. Boodschappen gaat er terecht uit, maar Lijstjes hoort er wél in — en die stond niet in de "Populair"-strook waar die zin op geënt was. Het zijn er dus weer vier: Vandaag · Taken · Agenda · Lijstjes (E-MOD-14). Dat Vandaag geen registry-module is en Lijstjes wel, verandert daar niets aan: geen van de vier heeft een domainId, dus geen van de vier wordt mapinhoud.

Geverifieerd — de code liep hier al vooruit en staat inmiddels goed. kSpringboardCoreSurfaceIds (lib/core/modules/springboard_layout.dart:116-121) bevat Vandaag · Taken · Agenda · Lijstjes, precies deze eis; gerepareerd in c9fe4be3, met vangrails op test/core/modules/springboard_layout_test.dart:311-327. Wat nog achterloopt is kCoreSurfaceModuleIds (lib/core/modules/module_registry.dart:14-19), dat nog 'boodschappen' bevat en géén 'vandaag' — plus de doc-comment bij ModuleDescriptor.tier (lib/core/modules/module_descriptor.dart:124-127), die de gratis kern nog als "Agenda/Taken/Vandaag/Boodschappen" beschrijft. Allebei belegd bij het pakket dat Boodschappen zijn descriptor geeft.

Snijd de domeinen opnieuw tot zes: Eten · Gezin · Huis · Geld · Gezondheid · Bewaren. Een gebied draagt minstens twee modules.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Doorloop van het domeinen- en startstandenstuk, variant A3 gekozen boven A1, A2 en A4. Sluit OV-1 van dat stuk: Boodschappen landt in eten.

Waarom

De domeinindeling van vandaag is geen indeling van de app maar een afdruk van lib/features/: elke feature-map declareerde één domein, ook als er maar één module in zat. Dat verklaart in één keer waarom zes van de tien domeinen precies één module dragen en waarom er vier domeinen zijn die heten zoals hun enige inhoud (Bewaarlijsten bevat Bewaarlijsten, Vastgoed bevat Vastgoed, Voorraad bevat Voorraad, Documenten bevat Documenten). Zolang dat alleen een kop in modulebeheer was, kostte het weinig. Vanaf E-MOD-06 wordt het de startindeling van het beginscherm van iedere gebruiker, en vanaf dat moment mag de app er niet meer aan zitten — een map is een belofte dat er meerdere dingen in zitten, en vier mappen die je opent voor één ding is een omweg die je nooit meer weghaalt. Dit is het laatste moment waarop de indeling gratis te herzien is. Aan de andere kant stond financieel met negen modules: bijna een derde van de app in één map, wat het ordeningsprobleem alleen een niveau dieper duwt.

Raakt

Fase 1 · E-MOD-06 (zes mappen in plaats van tien) · E-MOD-14 · E-MOD-16 · E-MOD-15 · modulebeheer, onboarding, meldingeninstellingen en AI-instellingen (die blijven alle vier op domein ordenen).

Nageteld: 4 + 6 + 4 + 7 + 5 + 3 = 29. Dat zijn de 29 huidige ModuleDescriptors min Quote (E-MOD-15) plus Boodschappen. Kleinste gebied 3, grootste 7 — geen enkel gebied vraagt een sub-niveau, geen enkel gebied draagt er één. De regel achter het minimum is twee: dat is de definitie van een groep. Eén is geen groep; het is een tegel met een deurtje ervoor.

Het voorstel telde er 30 — dit is de bijgestelde telling. Het bronstuk zette Quote als zesde module in Gezondheid, omdat een module schrappen geen bouwkeuze is en het stuk die niet zelf mocht maken. Met E-MOD-15 is dat besloten en telt Gezondheid er vijf.

Seed het springboard met vier losse tegels en zes mappen: Vandaag · Taken · Agenda · Lijstjes, daaronder de zes gebieden. Tien tegels, drie rijen, geen scroll.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Variant B2 gekozen boven B1 (alles in een map "Basis"), B3 (gratis los, Plus in mappen) en B4 (plat raster zonder mappen).

Waarom

Een startstand heeft twee manieren om te falen. Nietszeggend — zeven grijze deurtjes waarachter alles verstopt zit — leert niemand wat de tab is, en zet Taken op twee tikken terwijl E-NAV-06 juist drie korte wegen belooft. Slim op de verkeerde as is erger: sorteer je op tier, dan wordt de indeling bevroren op het abonnement dat iemand op dag één had, en die bevriezing is onomkeerbaar omdat E-MOD-10 terecht verbiedt dat de app een opgeslagen indeling herschrijft. Tien tegels in drie rijen van vier is de enige stand die op één blik past, meteen uitlegt hoe het scherm werkt — boven staat wat je doet, onder staat waar je het over hebt — en geen enkele beslissing neemt die later omgedraaid moet worden.

Raakt

Fase 1 · F1-2 (dit ís de conversieseed) · E-MOD-06 · E-MOD-12 · E-MOD-13 · E-OPS-01 · E-OPS-03.

Vier losse oppervlakken, niet drie — dit keert de staart van E-MOD-12 om. Die eis sloot af met "voortaan drie losse kernoppervlakken in plaats van vier", omdat Boodschappen de kern verlaat. Maar die zin was geënt op de "Populair"-strook (Vandaag · Taken · Agenda · Boodschappen) en niet op de kern-set, en Lijstjes ontbrak in allebei de tellingen. Het zijn er vier.

Wat je hiervoor opgeeft. Zichtbaarheid van individuele modules op dag één: een nieuwe gebruiker ziet zes mapnamen en geen modulenamen. Dat is opgevangen door het zoekveld (E-MOD-08) dat de mapnaam bij het resultaat toont (E-MOD-07), en door de onboarding, die op domein blijft ordenen en dus dezelfde zes koppen gebruikt.

Maak Quote een instelling van Vandaag in plaats van een module — en lever die instellingen er dan ook echt bij.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Sluit OV-2 van het domeinenstuk, waar drie opties lagen: (i) Quote wordt module in Gezondheid, (ii) Quote blijft module in een niet-gevoelig domein, (iii) Quote is geen module maar een instelling van Vandaag. Optie (iii) gekozen, mét een voorwaarde.

Waarom

Quote is een dagelijkse spreuk die zichzelf al als TodaySection op Vandaag zet, en waarvan de landings-favoriet al bewust was uitgezet omdat het scherm niets toevoegt. Het is dus een tegel die niemand tikt, met een eigen route en — tot E-MOD-13 — een eigen domein voor één spreuk. Als module in Gezondheid zou hij bovendien de gevoeligheidsvlag van dat domein overnemen, wat voor een spreuk onzin is. Er verdwijnt hier een tegel, een route en een domein tegelijk — en geen functionaliteit. De quote-sectie op Vandaag blijft staan, in de laag chroom en buiten het signaalplafond (E-VDG-01).

Raakt

Fase 1 · fase 2 · E-MOD-13 (het domein welzijn vervalt) · E-VDG-01 · E-VDG-08 · ADR-0021 · ADR-0022.

Vervolgwerk — deze eis is pas af met een pakket. Dat pakket (a) brengt thema-selectie, gewichten, taalkeuze en meldingstijdstip naar de Vandaag-instellingen, (b) registreert de TodaySection ergens anders nu welzijn_module.dart vervalt, en (c) doet een uitspraak over favorieten en archief. Zolang dat pakket er niet is, is deze eis niet uitgevoerd door de module simpelweg te schrappen.

Dat pakket is er — W4 in het fase-2-plan, gebouwd op 6 augustus 2026. De schakelaar is QuotePrefs.showOnToday (eigen sleutel, device-lokaal, standaard aan); de sectie staat geregistreerd in quote_module.dart, onveranderd in chroom op orderHint 10 en zonder moduleId; en /vandaag/quote draagt de schakelaar, de thema's met gewichten, de taal, meldingen aan/uit, het meldingstijdstip, de favorieten en het archief van veertien dagen. Twee ingangen: een vaste regel in Instellingen — die er óók is als er nog geen thema gekozen is en er dus geen kaart op Vandaag staat — en het ingedrukt-houden-menu van de quote-kaart zelf. Wat resteert is niet deze eis maar F1-2: de map Welzijn uit de conversieseed van het Modules-scherm.

Geef de nieuwe gebieden nieuwe id's — en zet de AI-toestemmingen mee om, want die hangen aan het domein-id.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Sluit OV-6 (nieuwe id's of alleen nieuwe labels) en OV-3 (Garanties en Wagenpark verlaten het gevoelige gebied) van het domeinenstuk.

Waarom

Bestaande id's hergebruiken met een nieuw label is gratis voor de tekstsnaren en voor de gesyncte opt-in-set, en duur voor iedereen die de code later leest: een domein voorraad dat "Eten" heet en Boodschappen bevat is een val die je niet ziet aankomen. Nieuwe id's zijn eerlijk. Maar ze kosten iets echts, en dat is de kern van deze eis: een hernoeming zonder omzetting van de opt-in-set zet iemands AI-toestemming stilletjes uit — de poort weigert dan zonder melding, en de gebruiker ziet alleen dat AI "het niet doet". Dat is geen cosmetische wijziging maar een gedragswijziging met een onzichtbare faalrichting.

Raakt

Fase 1 · E-MOD-13 · E-OPS-01 · ADR-0022 · de AI-poort en de AI-instellingen.

Benoem elke maat met breedte én hoogte ("halve breedte · laag"), nooit als "1×1" of "2×2".

Herkomst

Prototype-feedback, 5 augustus 2026 · eigenaar. De rasternotatie bleek onbegrijpelijk.

Waarom

"1×1" zegt niemand iets: het veronderstelt dat je het raster kent dat je juist niet ziet. "Klein / breed / groot" dekt de hoogte niet. Met eerst de breedte en dan de hoogte — altijd in die volgorde — kun je de vier maten uit elkaar houden zonder ze te leren. De vier namen zijn: halve breedte · laag, halve breedte · hoog, volle breedte · laag, volle breedte · hoog.

Raakt

Fase 3 · widgetgalerij · alle teksten rond widgets · vertaalsleutels.

Voer vier maten in, inclusief "halve breedte · hoog".

Herkomst

Prototype-feedback, 5 augustus 2026 · eigenaar.

Waarom

Volgt rechtstreeks uit E-WID-01: als "vol" twee hoogtes kent en "half" maar één, is de naamgeving scheef en is het geen stelsel maar een lijstje. Twee breedtes maal twee hoogtes is uitlegbaar; drie willekeurige maten niet.

Raakt

Fase 3 · widgetcontract · rasterindeling van het dashboard.

Correctie op het ontwerpstuk. ../archive/implemented/design/navigatie-ontwerpconcepten.html §6 kent nog drie maten (1×1, strook, 2×2) en zegt daar expliciet bij dat meer dan drie het raster rommelig maakt. Deze eis vervangt dat: de vierde maat is toegevoegd omdat de benaming er anders niet uitkomt. Wie §6 leest, leest op dit punt een achterhaalde stand.

Maak widgets interactief: een taak afvinken en een boodschap toevoegen moet vanaf het dashboard kunnen.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek. Alleen-lezende widgets zijn expliciet afgekeurd.

Waarom

Een dashboard dat alleen kijkt, dwingt je bij elke handeling naar een ander scherm — en dan had je net zo goed meteen daarheen kunnen gaan. De hele belofte van "hoe staat het ervoor?" valt weg als je er niets aan kunt doen. Mensen gaan het bovendien tóch proberen; een widget die niet reageert leest als kapot.

Raakt

Fase 3 · nieuw ticket "Dashboards-tab + widgetcontract" · beantwoordt de blokkerende vraag W2 · TEN-138 (rij-swipe).

Overrulet het ontwerpstuk. §6 van ../archive/implemented/design/navigatie-ontwerpconcepten.html adviseert het tegenovergestelde — "widgets tonen, ze doen niet" — met als argument dat read-only een fractie van het werk is en gebaarconflicten vermijdt. De eigenaar heeft anders beslist. Neem de prijs mee in het plan: een rechten-check per rij, een ongedaan-maken-verhaal per widget, en het vervallen van veeg-navigatie tussen dashboards (E-WID-11).

Laat een module die maar één maat biedt met één tik toevoegen.

Herkomst

Prototype-feedback, 5 augustus 2026 · eigenaar.

Waarom

Een keuzestap tonen waar niets te kiezen valt is pure vertraging. Als er één maat is, is de module aantikken al de hele beslissing.

Raakt

Fase 3 · widgetgalerij.

Nog niet in het prototype. Daar kost toevoegen altijd twee tikken: eerst de modulerij, dan de maatkaart — ook bij één beschikbare maat.

Maak de maat-indicatoren in de modulerij zelf aanklikbaar, als snelweg naar toevoegen.

Herkomst

Prototype-feedback, 5 augustus 2026 · eigenaar.

Waarom

De indicatoren tonen al precies wat je krijgt — de vorm, niet een woord dat je moet lezen. Ze dan alleen decoratief laten zijn, betekent dat de gebruiker eerst de rij moet openvouwen om dezelfde blokjes nog een keer te zien voordat hij mag kiezen. Wie weet wat hij wil, hoort meteen te kunnen kiezen; wie het niet weet, opent de rij.

Raakt

Fase 3 · widgetgalerij · E-WID-04.

Nog niet in het prototype. Daar is de hele rij één trefvlak en zijn de blokjes rechts niet afzonderlijk aanklikbaar.

Laat een geplaatste widget in de bewerkstand van maat wisselen, zonder verlies.

Herkomst

Prototype-feedback, 5 augustus 2026 · eigenaar.

Waarom

Je weet pas of een maat klopt als de widget op je board staat tussen de andere. Is wisselen alleen mogelijk door verwijderen en opnieuw toevoegen, dan is elke heroverweging een straf en blijft iedereen bij de eerste gok. Dit is de gebruikerskant van E-OPS-02: los opslaan is de voorwaarde, verliesvrij wisselen is de belofte.

Raakt

Fase 3 · E-OPS-02 · bewerkstand van het dashboard.

Nog niet in het prototype. Daar kun je een widget alleen verwijderen en opnieuw toevoegen; geen van beide bronstukken beschrijft een maatwissel.

Laat een tik op een rij ín een widget de module openen; uitklappen is daar niet de logische actie.

Herkomst

Prototype-feedback, 5 augustus 2026 · eigenaar.

Waarom

Een widget is een samenvatting. Wie op een regel tikt wil méér zien dan de samenvatting geeft, en dat "meer" woont in de module — niet in een uitgeklapt regeltje binnen een tegel van halve breedte, waar toch geen ruimte is. Dit botst niet met E-WID-03: afvinken gebeurt via de checkbox in de rij (E-INT-01), openen via de tekst.

Raakt

Fase 3 · widgetcontract · E-INT-01 · E-INT-02.

Correctie op het prototype. Daar is de regeltekst in een widget zélf de afvinkknop — een tik op de tekst vinkt af en opent de module dus níet. Dat wijkt af van deze eis én van E-INT-01, en van de manier waarop de echte app het op Vandaag al doet.

Laat een module een bestaand, generiek widgettype vullen of uitbreiden; een volledig eigen widget is de uitzondering die verantwoord moet worden.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek.

Waarom

Met 29 modules maal vier maten loopt "elke module zijn eigen widget" uit op een onhoudbare hoeveelheid eenmalige code, en op een dashboard dat er per tegel anders uitziet. Herbruikbare typen houden het aantal te onderhouden onderdelen laag én zorgen dat een nieuwe module een widget kan leveren zonder ontwerpronde. De uitzondering blijft toegestaan — maar als uitzondering, met een reden.

Raakt

Fase 3 · widgetcontract · elke toekomstige module.

Laat elke module declareren welke maten hij aankan, en toon in de galerij waaróm een module er niet in staat.

Herkomst

Afgeleid uit E-WID-02, E-WID-04 en E-WID-08 · ontwerpstuk §6.

Waarom

Zonder declaratie weet de galerij niet welke maatkaarten hij moet tonen en kan E-WID-04 niet bestaan. En een module die ontbreekt zonder uitleg leest als een fout: de gebruiker moet kunnen zien of de module uitstaat of gewoon geen widget heeft.

Raakt

Fase 3 · ModuleDescriptor · widgetgalerij.

Start een verse installatie nooit met een leeg dashboard.

Herkomst

Ontwerpstuk §6 · onderzoek.

Waarom

Een leeg board is een gemaakte toestand, geen begintoestand. Wie op dag één een lege tab opent, weet niet wat de tab is en komt niet terug — en dan wordt er nooit gemeten of het board werkt. De startstand toont Taken, Agenda, Boodschappen en één widget per aangezette gratis module.

Raakt

Fase 3 · E-PLUS-01 (het board moet ook gratis gevuld zijn).

Bijgesteld 6 augustus 2026: Agenda hoort niet in de startstand. De zin hierboven noemt "Taken, Agenda, Boodschappen"; het widgetonderzoek (TEN-179 §6) verbiedt in de startstand juist elke tijdlijnkaart, en Agenda is daar als tijdlijnkaart geclassificeerd — met als argument dat een dag-zware startstand het board "Vandaag in een ander jasje" maakt. Beide stonden als besloten. Uitkomst: Agenda is beschikbaar als widget maar staat niet standaard op het dashboard. Wie hem wil, heeft hem — hij staat gewoon in de galerij; wie het dashboard voor het eerst ziet, krijgt hem niet.

Waarom dat geen compromis is maar de tegenspraak oplost. Deze eis ging over beschikbaarheid (het board mag niet leeg zijn), het onderzoek over de startstand (de eerste indruk mag geen tweede Vandaag zijn). Die twee kunnen tegelijk waar zijn zodra je ze uit elkaar trekt.

Bijgesteld 6 augustus 2026, tweede keer: de startstand is zes widgets, en de eis en de seed spreken elkaar niet meer tegen. Hierboven stond, en in de "waarom" hierboven staat nog, "één widget per aangezette gratis module". Letterlijk uitgevoerd zijn dat acht widgets — Taken, Boodschappen, Lijstjes, Bewaarlijsten, Maaltijden, Verjaardagen, Schoolvakanties, Afvalkalender — en dat is de lezing die een uitvoerder overneemt. De eigenaar heeft op 6 augustus 2026 expliciet als keuze bevestigd dat de seed er zes telt, met de lezing "per gratis module is er een widget beschíkbaar". De startstand zelf staat in E-WID-19.

Waarom acht de verkeerde uitkomst is. Drie van de acht zijn lijstkaarten van dezelfde bouwsteen (Taken, Lijstjes, Bewaarlijsten — het widgetonderzoek zegt dat met zoveel woorden: "Bewaarlijsten: dezelfde bouwsteen als Lijstjes"), en drie keer dezelfde kaartvorm onder elkaar leest als een fout in plaats van als een keuze. Het is bovendien ruim twee schermen scrollen op dag één. En bij Lijstjes komt er een keuze bij die op dag één niet te maken is: die widget vraagt welke lijst hij toont, en op een verse installatie is er nog geen lijst om te kiezen.

Wat deze eis blijft zeggen, onverkort: start een verse installatie nooit met een leeg dashboard, en zet er geen tijdlijnkaart in. Het aantal is met E-WID-19 ingevuld; de eis zelf gaat over niet-leeg-starten en die staat.

Seed het dashboard met één bord van zes widgets voor iedereen; zonder Plus komen er twee uitgeschakelde voorbeeldwidgets onder. Geen tweede startstand.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Variant C2 gekozen boven C1 (de letterlijke lezing van E-WID-10), C3 (twee startstanden, gratis en Plus) en C4 (drie widgets). Sluit OV-5 van het domeinenstuk.

Waarom

Een gratis dashboard dat halfleeg voelt verkoopt geen Plus, en een dashboard vol met wat je niet hebt ergert. Die twee vangen elkaar op zodra je ze uit elkaar trekt in bord en etalage. Het bord is voor iedereen hetzelfde en is uit gratis bronnen volledig te vullen — zes werkende widgets, waarvan één groot en interactief. De etalage is twee kaarten en staat onderaan, waar ze verleidt zonder in de weg te zitten. Daarmee is het verschil tussen gratis en Plus op dag één zichtbaar zonder dat het pijn doet, en blijft er precies één seed te onderhouden.

Raakt

Fase 3 · B10 · E-WID-10 · E-WID-12 · E-OPS-06 · E-PLUS-01 · E-PLUS-02 · E-PLUS-03 · E-WID-03.

Waarom Gewicht en Voorraad de twee etalagekaarten zijn, en niet twee willekeurige. Het widgetonderzoek stelt vast dat het probleem van het gratis bord niet het aantal widgets is maar welke soorten ontbreken: een gratis gebruiker ziet nooit een verloopkaart (een grafiek) en bijna nooit een aandachtkaart. Dat zijn precies de twee soorten die het dashboard onderscheiden van Vandaag. Zet je die twee als etalage neer, dan toont de app niet "je mist een module" maar "je mist een manier van kijken" — en dat is het eerlijkste argument dat Plus heeft.

De volgorde is niet willekeurig. Boven staat wat je aanraakt (Taken, Boodschappen), in het midden wat je moet weten (Afval, Menu, Verjaardagen, Schoolvakantie), onder wat je zou kunnen hebben. Geen tijdlijnkaart, dus geen tweede Vandaag — E-WID-10 houdt daarmee stand, ook al wijkt het aantal af van de letter.

Navigeer niet met een veeg tussen dashboards.

Herkomst

Afgeleid uit E-WID-03 · gebaarconflict met TEN-138.

Waarom

Zodra widgets interactief zijn, komt de app-brede rij-swipe uit TEN-138 ook binnen een widget terecht. Een horizontale veeg over een board zou dan twee dingen tegelijk kunnen betekenen — sleep je de rij of de pagina? Dat is precies het conflict waarop concept C is afgeketst. Komen er meerdere dashboards, dan navigeer je via de titel als keuzemenu.

Raakt

Fase 3 · TEN-138 · E-WID-12.

Bouw één dashboard, en sla het op in een vorm die er later meer toestaat.

Herkomst

Ontwerpstuk §7, vraag W1 · onderzoek, beslecht door de eigenaar op 6 augustus 2026: één dashboard voor nu, later mogelijk meer.

Waarom

Het verschil tussen één en meer zit in navigatie en in benaming, niet in opslag. Eén bord houdt fase 3 klein — geen kiezer, geen titelmenu, geen lege tweede pagina — terwijl het opslagformaat de deur openhoudt. Precies de aanbeveling uit het widget-interfaceonderzoek: bewaar een lijst in plaats van één kaart, in dezelfde _shell-rij en met dezelfde patch-codec (E-OPS-01).

Raakt

Fase 3 · E-OPS-01 · E-WID-11 · E-OPS-06.

De blokkade op fase 3 vervalt — en twee gevolgen die bepalen of "later meer" straks écht gratis is. 1. Meervoud-klaar vanaf dag één: de opslag is een lijst van dashboards, elk met een eigen id, een naam en een lijst widget-instanties — ook als er precies één in staat. Slaat fase 3 één object op, dan is meervoud later een migratie in plaats van een schermwijziging. 2. De garantie "Taken staat standaard op je dashboard" geldt bij meervoud alleen op het eerste bord. Een tweede bord begint leeg; anders zou elk nieuw bord dezelfde widget opdringen. Dit stond al in het onderzoek en staat hier zodat het bij de uitbreiding niet opnieuw uitgezocht wordt.

Behandel een geplaatste widget als een instantie, niet als een combinatie van module en maat.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek, op open vraag V5 uit het widget-interfaceonderzoek (TEN-179).

Waarom

"Welke module" is niet wat een widget ís — het is één van zijn eigenschappen. Vijf lijstwidgets met elk een andere lijst zijn vijf verschillende dingen op je board, geen vijf keer hetzelfde. Zodra je een widget als instantie ziet, zijn maat wisselen, verplaatsen en verwijderen handelingen op één object, en hoeft nergens uitgezocht te worden "welke van de twee taken-widgets bedoel je".

Raakt

Fase 3 · E-OPS-06 · E-WID-14 · E-WID-06 · TEN-179.

Sta meerdere widgets van dezelfde soort op één dashboard toe; voorkom alleen de exacte dubbeling — zelfde module én zelfde maat én zelfde configuratie.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek, op open vraag V5 (TEN-179).

Waarom

Een gezin met een boodschappenlijst, een klusjeslijst en drie bewaarlijsten wil die naast elkaar zien — dat is precies waar een dashboard voor is. Een bovengrens per module zou die gebruiker uitleggen dat zijn eigen indeling verboden is, terwijl er geen enkel technisch bezwaar tegen is. Wat wél tegengehouden hoort te worden is de exacte dubbeling: twee widgets die letterlijk hetzelfde tonen, zijn altijd een vergissing en nooit een keuze. Daarmee is de regel bovendien afdwingbaar zonder iemand te beperken.

Raakt

Fase 3 · E-WID-13 · E-OPS-06 · widgetgalerij (de dubbeling-check) · TEN-179 · zie ook N-10.

Overrulet het voorstel in TEN-179, dat "hooguit twee widgets per module" adviseerde met als argument dat drie "verzamelen" wordt. De eigenaar heeft die grens verworpen; alleen de exacte dubbeling blijft over.

Neem de overige adviezen uit ../archive/implemented/design/widget-interfaces-en-modulecontracten.html over, inclusief de daar voorgestelde antwoorden op de open vragen.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek, na lezing van het stuk (TEN-179).

Waarom

Dit staat hier zodat niemand dat document nog leest als "een voorstel dat nog openstaat". De adviezen zijn aangenomen en de daar gestelde open vragen zijn met hun voorgestelde antwoord beslecht. Concreet betekent dat onder meer: acht generieke widgetsoorten in plaats van een widget per module; één databron met een weergave per maat in plaats van drie losse widgets; interactie uitsluitend via knoppen en nooit via een gebaar; een toevoeg-knop opent het bestaande invoerblad in plaats van een eigen veld; rechten en ongedaan maken via de bestaande voorzieningen; één meting-bouwsteen vóór de eerste verloopkaart; één herhaalberekening in de kern; TodaySection krijgt moduleId, band en rijbudget terwijl orderHint vervalt; en zichtbaarheid en Plus blijven van de app, niet van de module.

Raakt

Fase 2 en 3 · TEN-179 · de negen ADR's die dat stuk zelf aanwijst · E-VDG-01 · E-VDG-02 · E-VDG-08.

Twee uitzonderingen. Deze eis geldt behalve waar dit register het stuk expliciet overrulet: E-WID-14 (geen bovengrens per module), E-OPS-06 (instanties met een eigen id) en E-WID-16 (de lijstkaart krijgt wél een strook).

Bied de lijstkaart ook aan als strook — volle breedte, laag.

Herkomst

Eigenaar, 5 augustus 2026 · visuele beoordeling van de schetsen in TEN-179: de voorbeelden hielden zichtbaar ruimte over.

Waarom

De lijstkaart is de meest gevraagde widget van allemaal — het is de widget waarmee je afvinkt zonder de app in te gaan. Hem alleen in de twee grootste vormen aanbieden dwingt iemand met vier lijsten om zijn halve board eraan te geven. En het argument dat één laag "dan een telkaart" wordt, bleek in de schetsen niet te kloppen: er bleef ruimte over.

Raakt

Fase 3 · widgetcontract (matenlijst van de lijstkaart) · E-WID-17 · TEN-179.

Overrulet het ontwerpstuk. TEN-179 zet bij de lijstkaart uitdrukkelijk "strook: nee", met als reden "één laag hoog past hooguit één regel — dan is het een telkaart en geen lijst". Die redenering vervalt.

Houd "halve breedte · hoog" een volwaardige maat in het stelsel; een soort die breedte nodig heeft, stelt die maat als ondergrens en niet als omissie.

Herkomst

Eigenaar, 5 augustus 2026 · visuele beoordeling van TEN-179. Bevestigt E-WID-02.

Waarom

Twee dingen tegelijk. Eén: de vierde maat is geen bijverschijnsel van de lijstkaart maar een gelijkwaardig lid van het stelsel — anders klopt de benaming niet (E-WID-01) en is het weer een lijstje in plaats van twee breedtes maal twee hoogtes. Twee: dat niet elke soort hem aanbiedt, is geen gat. Een grafiek of een tijdlijn met tijden in een kolom links heeft breedte nodig; die soorten hebben dus een ondergrens, en dat is een eigenschap van het soort. "Deze maat ontbreekt bij de verloopkaart" is geen bug die opgelost moet worden.

Raakt

Fase 3 · widgetcontract (maten per soort) · widgetgalerij · E-WID-02 · E-WID-09 · TEN-179.

Ruimt een inconsistentie op. In de eerste versie van TEN-179 kwam deze vorm alleen informeel voor — als "tegel over twee lagen", uitsluitend binnen de lijstkaart — en kenden de maatwisselaar en het opslagveld maar drie waarden. Dat is inmiddels rechtgezet: het stuk kent nu vier volwaardige maten, sinds 6 augustus 2026 onder de namen uit E-WID-18 (Klein · Hoog · Breed · Groot — besloten, niet langer een voorstel). Met deze eis is de vierde maat een gewoon lid van het stelsel en moeten wisselaar, matenlijst en opslag hem alle drie kennen. In code is de vierde maat fullTall; de vierde naam is Groot.

Noem de vier maten Klein · Hoog · Breed · Groot, met één woordenlijst voor interface, documentatie en code.

Herkomst

Geconstateerd bij het naast elkaar leggen van E-WID-01 en TEN-179, 5 augustus 2026 · voorstel opgesteld op verzoek van de eigenaar, 6 augustus 2026 · akkoord gegeven door de eigenaar op 6 augustus 2026; het register liep daarop achter en is op de avond van dezelfde dag bijgewerkt.

Waarom

Er lopen twee stelsels naast elkaar. E-WID-01 eist namen die breedte én hoogte dragen ("volle breedte · laag"). TEN-179 gebruikt de korte namen tegel · strook · paneel — die de hoogte juist níét dragen ("tegel" zegt niets over hoog of laag). Dat is geen smaakverschil: het heeft al schade gedaan. Het onderzoeksstuk sprak van drie maten terwijl het register er vier kende, precies omdat een naam zonder hoogte-as de vierde maat niet kan benoemen (E-WID-17). Twee woordenlijsten voor dezelfde vier dingen is hoe documentatie uit elkaar loopt.

Raakt

Fase 3 · widgetgalerij · vertaalsleutels · maatwisselaar · opslagveld maat · E-WID-01 · E-WID-17 · TEN-179.

Zelf getoetst — één echt bezwaar, en het is oplosbaar. Loopt "Hoog" door "Groot" heen? In een kale opsomming enigszins: beide klinken als "meer", en niets in het woord "Hoog" verraadt dat het de smalle maat is. Naast het maatvoorbeeld in de galerij valt dat weg — dáár is de naam een handvat, geen definitie. Het bezwaar geldt dus voor lopende tekst, niet voor de galerij. Het echte bezwaar is grammaticaal: dit zijn bijvoeglijke naamwoorden, terwijl tegel · strook · paneel zelfstandige naamwoorden waren. "Op een paneel passen vijf regels" wordt "op een Groot passen vijf regels" — dat leest niet. Aanbevolen oplossing: geef ze één vast zelfstandig naamwoord om bij te horen — een kleine kaart · een hoge kaart · een brede kaart · een grote kaart. Het label in de interface blijft dan één woord (Klein · Hoog · Breed · Groot), en lopende tekst krijgt zijn naamwoord terug zonder een tweede woordenlijst. Zonder die afspraak verschijnt "de maat Groot" en "een Groot" door elkaar, en is het stelsel binnen een half document weer scheef.

Wat de wissel kostte — en hij is al gedaan. ../archive/implemented/design/widget-interfaces-en-modulecontracten.html is omgezet: de oude korte namen stonden er 142 keer (tegel 78 · strook 31 · paneel 33), waarvan 133 vindplaatsen op ruim honderd regels zijn omgezet — de negen die blijven staan zijn andere woorden (tegelijk, actiestrook, knoppenstrook, weekstrook). De plekken waar de maatnaam primair is, zijn allemaal meegegaan: de maattabel, de matrix soort-maal-maat (vier kolomkoppen plus acht rijen celtekst), de maatwisselaars in de schetsen, de acht Maten-regels in de modulecontracten, de capaciteitsregel, de startstand-tabel en het opslagvoorbeeld — dat nu halfLow · halfTall · fullLow · fullTall toont in plaats van 'paneel', 'hogeTegel' en 'strook'. Lopende tekst kreeg de kaart-vorm ("op een hoge kaart past…"). Er staat nog géén code, dus dit was een tekstuele herziening van één document; kiest de eigenaar andere woorden, dan is het dezelfde ingreep nog een keer.

Afvinken gebeurt uitsluitend via de checkbox, eventueel aangevuld met een swipe.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek, naar aanleiding van een afwijking in het prototype.

Waarom

Afvinken is een handeling met gevolgen: het item verdwijnt uit beeld. Dat mag nooit het gevolg zijn van een tik die iemand deed om iets te lezen. Eén eenduidig trefvlak — het vakje — betekent dat je nooit per ongeluk afvinkt, en dat de rest van de rij vrij is voor lezen en navigeren.

Raakt

App-breed · Vandaag · Taken · widgets (E-WID-07) · TEN-138 (de swipe-aanvulling).

Geverifieerd — de echte app doet dit al goed. In lib/features/today/presentation/widgets/today_row_card.dart zit de afvinkactie uitsluitend op de Checkbox; de rij eromheen roept nooit de dismiss-actie aan. Nuance: de swipe-aanvulling bestaat op Vandaag nog niet — er is een generieke SwipeActionPane in lib/shared/widgets/swipe_actions.dart, maar de Vandaag-rijen gebruiken die niet. "Eventueel aangevuld met een swipe" is dus toekomstig werk (TEN-138), geen bestaande stand.

Een tik op de tekst klapt de titel uit; hij mag nooit afvinken.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek.

Waarom

Rijtitels worden afgekapt, en soms is de afgekapte staart precies het stuk dat je nodig hebt ("tandarts Sanne 15:30"). Er moet dus een manier zijn om de volledige titel te lezen zonder het item aan te raken in de zin van "klaar". Uitklappen is die manier — en meteen de reden dat de tik níet mag afvinken.

Raakt

App-breed · today_row_card.dart · E-WID-07 (binnen een widget geldt de andere regel).

Geverifieerd, met één nuance die je moet weten. De rijkaart kent drie gevallen. Rijen mét een detailpaneel klappen uit bij een tik (agendarijen doen dat). Rijen zónder detailpaneel én zonder eigen tikactie klappen ook uit — de titel verliest daar zijn afkapping. Maar een rij mét een eigen tikactie en zonder detailpaneel navigeert bij een tik en klapt dus niet uit. In geen van de drie gevallen wordt er afgevinkt, dus de harde helft van de eis staat. Wil je "uitklappen" overal, dan is dat derde geval een expliciet werkpunt.

Laat de centrale knop niet functioneel over de inhoud vallen: elke scrollende lijst heeft genoeg bodemruimte om de laatste rij vrij te scrollen.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek.

Waarom

Een zwevende knop die de laatste rij bedekt maakt precies dat item onbereikbaar — en het is altijd het item dat je nodig hebt, want het staat onderaan. Dit is geen esthetische regel maar een bereikbaarheidsregel, en hij geldt op élk scherm dat scrollt, ook op moduleschermen met een eigen knop.

Raakt

App-breed · elk nieuw scrollend scherm · reviewpunt bij elke module.

Geverifieerd — er zijn twee patronen, gebruik het juiste. Moduleschermen met een eigen knop gebruiken AppSpacing.fabClearance (88 px, in lib/core/theme/app_dimens.dart, ruim 39 aanroepen). De drie scrollende shell-schermen gebruiken PaTabBar.scrollPaddingOf(context), dat de tabbalkhoogte, de veilige zone onderaan én de FAB-overlap optelt. Noem in een ADR of werkpakket welk van de twee van toepassing is; ze zijn niet uitwisselbaar.

Houd elk trefvlak op minimaal 48 px (Material) respectievelijk 44 pt (Apple).

Herkomst

Afgeleid uit de rekenregel waarmee E-NAV-10 is beslist · 5 augustus 2026.

Waarom

Deze grens is de reden dat de gesplitste knop is afgewezen. Als hij zwaar genoeg weegt om een navigatievariant te laten sneuvelen, hoort hij ook te gelden voor alles wat daarna gebouwd wordt — anders is het een argument van gelegenheid. Let hierop bij checkboxen in een widget van halve breedte: het prototype tekent daar vakjes van 19 px.

Raakt

App-breed · widgets (E-WID-03) · E-INT-01.

Leg één minimale afstand vast tussen een interactief element en de inhoud erboven, als getal en app-breed — niet per kaart naar smaak.

Herkomst

Eigenaar, 5 augustus 2026 · visuele beoordeling van de widgetschetsen in TEN-179.

Waarom

Een knop die tegen een voortgangsbalk of een grafiek aan staat, is een treffer-risico en niet alleen lelijk: de duim landt op het randje en raakt óf niets óf het verkeerde. Zonder vastgelegd getal wordt die afstand per kaart opnieuw op gevoel gekozen, gaat hij bij de eerste krappe widget als eerste sneuvelen, en is er in een review niets om naar te wijzen. Eén norm maakt er een controleerbaar feit van.

Raakt

App-breed · widgetcontract · lib/core/theme/app_dimens.dart · E-INT-04 · TEN-179.

Waar het getal vandaan moet komen. Er is al een schaal: AppSpacing.xs = 6, sm = 8, md = 10, lg = 12, xl = 16. De widgetschetsen in TEN-179 gebruiken vandaag 5 tot 6 px boven de actiestrook — de onderkant van die schaal. Voorstel: neem 12 px (AppSpacing.lg) als norm en geef hem een eigen naam in AppSpacing, zodat de regel vindbaar is in plaats van overgeschreven. De eis is dat er één getal is; de exacte waarde mag de eigenaar bijstellen, maar "per kaart naar smaak" is er niet meer bij.

Behandel witruimte die in een widget overblijft als een signaal — een te grote maat of te weinig inhoud — en niet als esthetisch detail.

Herkomst

Eigenaar, 5 augustus 2026 · visuele beoordeling van de widgetschetsen in TEN-179.

Waarom

Een halfvolle widget kost de gebruiker net zoveel ruimte op zijn board als een volle, en geeft er minder voor terug — dus overgebleven ruimte is altijd een bevinding. Ze zegt óf dat de maat te groot is voor wat de soort te melden heeft, óf dat de inhoud te dun is en er iets bij hoort. Wie het als opmaak behandelt, vult het op met lucht en verliest allebei die signalen. Dit is meteen de aanleiding geweest voor E-WID-16: de lijstkaart hield ruimte over, dus kwam er een kleinere maat bij.

Raakt

Fase 3 · widgetcontract (maten per soort) · elke widget-review · E-WID-09 · E-WID-16 · E-WID-17 · TEN-179.

Houd het dashboard bruikbaar in de gratis variant.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek.

Waarom

Een tabpositie die voor een gratis gebruiker leeg is, is een tabpositie die je weggooit. En een Plus-muur om de functie heen zetten leert de gebruiker niets over wat Plus is — het leert hem alleen dat een kwart van zijn navigatiebalk niet van hem is.

Raakt

Fase 3 · E-NAV-05 · E-WID-10 · TEN-149/150/157.

Meetpunt, niet vrijblijvend. Zonder Plus zijn er 4 kernoppervlakken plus 5 gratis modules — ongeveer 8 tot 12 widgetbronnen tegenover ruim 30 mét Plus. Blijkt bij de beoordeling in fase 3 dat het board voor een gratis gebruiker een tweede Vandaag wordt, dan is dat volgens de fasering (E-NAV-07) reden om E bij fase 2 te stoppen.

Toon Plus-widgets zichtbaar maar uitgeschakeld, met hun echte vorm.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek. Uitgewerkt in het Plus-ontwerpstuk §4.

Waarom

Een gratis gebruiker mag goed zien wat hij mist, en dat is bewust marketing. Een grijze tegel op het springboard toont een naam; een uitgeschakelde widget toont de vorm van wat je zou krijgen. Dat maakt het dashboard het beste verkooppunt dat de app heeft — winst tonen in plaats van een slot tonen.

Raakt

Fase 3 · TEN-149 · E-PLUS-03.

Laden is niet hetzelfde als geen recht — besloten 6 augustus 2026. Deze eis beschrijft wat een gebruiker zonder Plus ziet. Er was geen antwoord op de vraag wat een gebruiker ziet zolang de app het nog niet weet: het Plus-recht wordt bij het opstarten opgehaald en geldt zolang als "geen Plus". Zonder maatregel ziet een betalende gebruiker bij elke koude start seconden lang zijn Plus-rijen verdwijnen en zijn Plus-widgets als "Voorbeeld" — geen flikkering van één frame, maar de duur van een netwerkquery. Besluit: de oppervlaktegate krijgt drie uitkomsten — toegestaan, geweigerd en nog onbekend. Bij onbekend toont de app de vorige bekende stand, en zonder vorige stand een rustige laadweergave. Geen etalage, geen lege balk. De etalage uit deze eis geldt dus pas als vaststaat dát er geen Plus is. Zie ADR-0022; hetzelfde geldt voor E-PLUS-03, E-PLUS-04 en de tabbalk onder E-NAV-19.

En Vandaag mag die poort krijgen — met een veilige startwaarde, besloten avond 6 augustus 2026. Vandaag kende tot nu toe geen enkel tier-besef. Met de Plus-poort erin hangt de zichtbaarheid van dagrijen af van effectiveTier (module_tier_overrides.dart:44-47), die een tabel leest die bij het opstarten anoniem wordt opgehaald en in SharedPreferences gecacht (ModuleTierOverrides.build()/refresh(), :77-95). De regel: tot de eerste geslaagde verversing geldt tonen. Een offline toestel of een verse installatie verbergt dus nooit iets op grond van een gok; de faalrichting is altijd "te veel tonen", nooit "stil iets weghalen". Dit is dezelfde derde stand als hierboven, toegepast op poort 4. Wat dat in de bouw kost, en dat is geverifieerd: die stand bestaat vandaag niet. _readCache() degradeert bij élke fout — en ook bij "nog nooit iets opgehaald" — naar const {} (:97-116), wat niet te onderscheiden is van "opgehaald, en er zijn geen overrides". Er moet dus een heb-ik-dit-ooit-geweten-stand bij; alleen dán kan de gate "onbekend" antwoorden in plaats van te raden.

Label verzonnen vulling verplicht als "Voorbeeld".

Herkomst

Plus-ontwerpstuk §4 · onderzoek, als harde regel geformuleerd.

Waarom

Volgt op E-PLUS-02: als je de echte vorm toont, toon je ook data — en een etalage die eruitziet als jouw gegevens maar het niet is, kost precies één keer vertrouwen. Het label is de prijs voor het mogen tonen van de vorm.

Raakt

Fase 3 · TEN-149 · elke vergrendelde widget.

Toon de AI-knop zonder Plus zichtbaar maar uit; een tik opent het Plus-vlak met AI-context.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek, aangescherpt in het Plus-ontwerpstuk §4.

Waarom

AI verliest in fase 3 zijn tab en wordt een icoon in de kop (E-NAV-09). Voor het zichtbaarste Plus-onderdeel van de app is dat weinig — dus die ene knop moet zijn werk doen als trechter. Hij hoort er te staan zodat je weet dát hij bestaat en wáár hij zit. En hij moet reageren: een knop die niets doet leest voor een gebruiker als een bug, niet als een slot.

Raakt

Fase 3 · TEN-150 · E-NAV-09 · E-PLUS-10.

Geef twee weken gratis proef op alle vier de producten.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek. Vastgelegd in App Store Connect.

Waarom

24 van de 29 modules zitten achter Plus. Zonder proef kan een nieuwe gebruiker onmogelijk beoordelen of dat de moeite waard is, en beslist hij op basis van een grijs raster. Twee weken is lang genoeg om een gezinsritme één keer rond te maken.

Raakt

TEN-157 · koopflow (B5) · E-PLUS-08.

Hanteer de vastgestelde prijzen — Solo € 39,99 per jaar en € 5,99 per maand, Gezin € 59,99 per jaar en € 7,99 per maand — en lees ze uit de aanbieding in plaats van ze vast te zetten in code.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek. De vier producten bestaan sinds 5 augustus 2026 in App Store Connect.

Waarom

De prijzen zijn definitief — het woord "richtprijs" dat nu in de app staat kan weg. Uitlezen in plaats van hardcoderen is geen nettigheid maar noodzaak: Apple past bedragen per land aan, en een hardgecodeerd bedrag naast een afwijkend bedrag in de koopdialoog is precies het soort tegenstrijdigheid dat een review afkeurt.

Raakt

TEN-157 · koopflow (B5) · _familyAnnualPrice in de huidige upsell.

Nuance na verificatie. De vier abonnementen bestáán in App Store Connect, maar zijn nog niet bruikbaar: er ontbreekt per product een reviewschermafbeelding en de review zelf. Zonder goedgekeurde producten geeft de SDK een lege aanbieding terug — "de producten bestaan" is dus niet hetzelfde als "de prijzen zijn op te halen".

Geef bij het gezinsabonnement élk lid Plus, ook tijdens de proefperiode.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek.

Waarom

Het product dat verkocht wordt is een gezinservaring. Wie in de proefweken als enige Plus heeft, kan precies dat niet beoordelen — hij ziet een betere solo-app, niet het gezin dat samenwerkt. De proef zou dan het verkeerde ding testen.

Raakt

TEN-157 · plus_entitlements · gezinsdeling · E-OPS-05.

Gevolg voor de teksten. Een scherm na aankoop krijgt hierdoor ook leden te zien die zelf niets gekocht hebben. "Bedankt voor je aankoop" is dus geen bruikbare kop.

Maak de proefperiode zichtbaar op de plekken waar iemand tegen een grens loopt.

Herkomst

Eigenaar, 5 augustus 2026 · na het doorlopen van het prototype ("het valt niet echt op dat je een proefperiode kan doen").

Waarom

De proef wordt vandaag op één plek genoemd, en dan nog als "binnenkort", tegenover meer dan vijftig plekken waar de grens gevoeld wordt. Een aanbieding die alleen bestaat waar niemand hem zoekt, bestaat niet. Het moment van de grens is bovendien het enige moment waarop de gebruiker zélf al bedacht heeft dat hij iets wil.

Raakt

TEN-150 · docs/design/plus-presentatie-en-upgradepad.html voor de uitwerking (label-provider, Vandaag-regel, springboard-strip, onboarding).

Toon het label "14 dagen gratis" alleen wanneer de proef voor déze gebruiker echt beschikbaar is.

Herkomst

Afgeleid uit E-PLUS-08 en E-PLUS-10.

Waarom

Als het label overal komt te staan, komt het ook te staan bij wie de proef al verbruikt heeft. De aanbieding geldt per Apple-account; anders lieg je. Val in dat geval terug op "Plus".

Raakt

plusTrialAvailableProvider · koopflow (B5) · TEN-150.

Zet geen knop in een echte build die niets doet.

Herkomst

Eigenaar, 5 augustus 2026 · gesprek. Als harde regel opgenomen in het Plus-ontwerpstuk §7.

Waarom

De koopflow bestaat nog niet. Een knop met "Begin je 14 gratis dagen" die vervolgens niets doet is de enige variant die gegarandeerd een bugmelding oplevert — en hij kost het vertrouwen van precies de testers die je nodig hebt. Kies één van twee: de knop staat er niet en het Plus-vlak legt alleen uit, óf de knop staat er wel maar alleen in een testbuild achter een define.

Raakt

Elke build tot B5 · E-PLUS-04 · E-PLUS-09.

Stand van zaken, geverifieerd. Handhaving staat áán (plusEnforcementProvider = true; het commentaar "OFF until B5" ernaast is verouderd), plusTrialAvailableProvider staat hard op false, _startTrial is een lege pop met een TODO(B5), en er zit geen aankoop-SDK in pubspec.yaml. Er is dus vandaag geen enkel scherm dat iets kan verkopen.

Laat het inloggen vóór de aankoop vallen; de koopknop staat achter de sessie.

Herkomst

Eigenaar, 6 augustus 2026 · beslecht in het voordeel van ADR-0023 (B1), ná de eerdere uitspraak op het voorstel in het Plus-ontwerpstuk §8, vraag 2.

Waarom

De volgorde is Plus-vlak → account maken of inloggen → koopdialoog; Purchases.logIn(<supabase user id>) gaat vooraf aan élke koopaanroep, zodat app_user_id altijd onze user-id is en de bestaande webhook ongewijzigd werkt. Drie redenen, alle drie tegen de code gecontroleerd. (1) Een Solo-recht kan zonder begunstigd lid niet opgeslagen worden: 0042:25-26 eist check (tier <> 'solo' or beneficiary_member_id is not null), en vóór het account bestaat er geen lid; de tabel heeft bovendien alleen een select-policy (0042:31-35). (2) De webhook accepteert geen anonieme RevenueCat-id en er is geen claim-pad: revenuecat-webhook/index.ts:47 leest alleen event.app_user_id en :63-66 geeft bij $RCAnonymousID een 200 met skipped — geen retry, geen wachtrij, en nul treffers op claim/ pending in die function. (3) Cloud-sync is zélf de Plus-functie (plus_entitlement.dart:3-7), dus een proef zonder account test het verkeerde product.

Raakt

TEN-157 · koopflow (B5) · plusEntitlementProvider · ADR-0023 (B1).

De eerdere formulering van deze eis — "laat het inloggen ná de aankoop vallen" — is ingetrokken. Die versie nam het voorstel uit ontwerpstuk §8 vraag 2 over ("laat de App Store-koop eerst slagen en koppel het account daarna") en woog uitsluitend conversie op het koopscherm; de drie blokkades hierboven bleven daarbij buiten beschouwing. Kom je dat oude advies nog ergens tegen — in een ouder werkpakket, in een oude comment op TEN-157, of in een aangehaalde versie van §8 — dan is het achterhaald. De tegenspraak met ADR-0023 is hiermee weg en dit punt houdt de koopflow niet langer op.

Bewaar een module die zonder Plus wordt aangevinkt als wens, device-lokaal.

Herkomst

Eigenaar, 6 augustus 2026 · akkoord op het voorstel in het Plus-ontwerpstuk §8, vraag 1. Niet langer blokkerend.

Waarom

In de onboarding mag iemand ook Plus-modules aantikken; die keuze is de brug naar het proefaanbod een stap later. Blijft die keuze bewaard, dan staan de modules klaar zodra Plus aangaat en voelt de proef als "wat ik zelf koos". Verdwijnt hij, dan moet de gebruiker alles opnieuw doen op het moment dat hij net betaald heeft. De wens gaat device-lokaal in SharedPreferences in plaats van in de syncbare database; dat maakt een migratie en de gezinsset/persoonlijk-vraag overbodig.

Raakt

TEN-149 · TEN-157 · onboarding · E-PLUS-11.

Houd de "bewaard"-groep permanent zichtbaar nadat Plus is weggevallen.

Herkomst

Eigenaar, 6 augustus 2026 · Plus-ontwerpstuk §8, vraag 7. De oorspronkelijke vraag ging over "proefdata"; het antwoord is breder en valt uiteen in drie lagen.

Waarom

De belofte bij afloop is dat er nooit iets verwijderd wordt omdat een abonnement stopt — "er is niets weg, er staat alleen wat op slot". De tellingen in die groep komen uit de lokale database, en die blijft bestaan; er is dus geen reden ze ooit te laten verdwijnen. Het oorspronkelijke voorstel ("permanent") klopt, maar om een andere reden dan er stond.

Raakt

TEN-157 · afloopscherm · springboard · E-PLUS-27 · E-PLUS-28.

Niet te verwarren met de bewaartermijn. Deze eis gaat over de lokale laag. De cloudkopie heeft wél een termijn (E-PLUS-28) en de bijlagen zijn de enige laag die daarna echt verloren gaat (E-PLUS-29).

Toon géén permanente proefteller op Vandaag.

Herkomst

Eigenaar, 6 augustus 2026 · afwijzing van het voorstel in het Plus-ontwerpstuk §3 ("Nog 7 dagen Plus-proef · Regel het nu").

Waarom

Bij een automatisch verlengend abonnement met introductieaanbieding is de gewenste uitkomst dat de proef omzet in betaald. Een dagelijkse teller met "regel het nu" leest dan niet als service maar als een uitnodiging om op te zeggen — een churn-herinnering in de vermomming van behulpzaamheid. Bovendien nodigt hij veertien dagen lang uit om over de kosten na te denken, elke ochtend opnieuw, en juist in de periode waarin de gebruiker nog nauwelijks waarde heeft opgebouwd. Je vraagt om de beslissing op het zwakste moment dat er is.

Raakt

TEN-150 · Plus-ontwerpstuk §3 · N-11 · E-PLUS-15 t/m E-PLUS-17.

Waar het minimum wél ligt: bij de aankoop. Apple eist volledige informatie op het aankoopmoment — titel, duur van het abonnement én van de proef, prijs, dat er bij bevestiging wordt afgeschreven, dat het automatisch verlengt tenzij minimaal 24 uur vóór het einde van de periode wordt opgezegd, dat de afschrijving binnen 24 uur vóór het einde plaatsvindt, waar de gebruiker het abonnement beheert, en dat een ongebruikt deel van een proefperiode vervalt bij aankoop. Er is geen enkele eis voor een permanente teller of een herinnering in de app tijdens de proef. Onzeker en niet om op te bouwen: of Apple zélf waarschuwt vóórdat een proef omzet in betaald — de bronnen spreken elkaar daarop tegen.

Zet de proefstatus als regel in Instellingen.

Herkomst

Eigenaar, 6 augustus 2026 · akkoord op voorstel 1 uit Plus-ontwerpstuk §3 · vervanger van E-PLUS-14. De eerdere aarzeling ("we zijn nog niet zeker of we die herinneringen willen doen") is hiermee opgeheven voor dít voorstel.

Waarom

"Plus-proef · loopt tot 19 augustus · daarna € 59,99 per jaar": status waar je hem zoekt, niet waar je hem niet kunt ontwijken. Vindbaar en eerlijk zonder dagelijkse aandacht te vragen. Het is geen herinnering maar een statusregel — hij vraagt niets, onderbreekt niets, en hij is de plek waarheen alle andere Plus-teksten wijzen. Dat is precies waarom dit het minst omstreden van de drie vervangers was en waarom het als enige zonder voorbehoud doorgaat: het kost bijna niets en het kan niets kapotmaken.

Raakt

TEN-150 · Instellingen · period_type en expires_at uit ADR-0023 (B3) · E-PLUS-16 · E-PLUS-17.

Het bereik van deze regel is beperkt, en dat is nu belangrijker geworden. Een deel van de gebruikers opent Instellingen nooit. Zolang E-PLUS-16 nog een moment vooraf zou toevoegen, was dat een aanvaardbaar gat; met de afwijzing daarvan is deze regel het enige wat er tíjdens een normale proef in de app over te vinden is. Wie hem niet zoekt, hoort pas iets ná de afschrijving (E-PLUS-17). Dat is een bewuste uitkomst, geen omissie — period_type is nodig om de regel niet boven een betaald jaarabonnement te laten verschijnen.

Toon géén bericht vooraf tijdens een proef die gewoon doorloopt; toon alleen een afteller mét de gevolgen zodra iemand actief heeft opgezegd.

Herkomst

Eigenaar, 6 augustus 2026 · afwijzing van voorstel 2 uit Plus-ontwerpstuk §3, mét één uitzondering. Het voorgestelde moment rond dag 11 of 12 is geschrapt.

Waarom

Bij de normale gang van zaken is er niets aan de hand: de proef gaat over in betaald, dat is de gewenste uitkomst, en een scherm dat daar aandacht op vestigt is — hoe vriendelijk ook geformuleerd — een uitnodiging om op te zeggen. Een terugblik met cijfers verandert daar niets aan; hij vraagt nog steeds om de beslissing op een moment dat de gebruiker er niet om vroeg. De uitzondering is de spiegel daarvan: zodra iemand zélf heeft opgezegd, is er wél iets aan de hand, en dan zwijgen is oneerlijk. Dán telt de app af en zegt er concreet bij wat er verdwijnt — "je proef loopt over 3 dagen af; hierna verlies je toegang tot Budget, Auto en Documenten". Dat is dezelfde regel als E-PLUS-24 en E-PLUS-25, hier toegepast op de proef: de app reageert op een gebeurtenis, nooit op een klok.

Raakt

TEN-150 · TEN-157 · ADR-0023 (B3) — will_renew is de trigger · E-PLUS-24 · E-PLUS-25 (dáár staat de uitwerking van de afteller) · E-PLUS-17.

Wat hiermee vervalt. Het dag-11/12-moment, de terugblik met tellingen ("7 van je 24 modules in gebruik", "3 toestellen in huis"), de knoppen "Plus houden" / "Ik wil straks stoppen", en de eis dat er een stopknop bij dat scherm hoort. Dat scherm bestaat niet meer, dus die eis ook niet. De schets ervan is uit Plus-ontwerpstuk §3 verwijderd; wat daar overblijft zijn de statusregel (E-PLUS-15) en de bevestiging achteraf (E-PLUS-17).

Geen enkele Apple-eis staat hier tegenover. Het minimum ligt volledig op het aankoopmoment (zie E-PLUS-14); er is geen verplichting tot een teller of een herinnering tijdens de proef. Wat dit besluit wél verzwaart is E-PLUS-17: die bevestiging is nu het enige moment waarop de app iets zegt over de eerste afschrijving, en dat is de reden dat die eis niet geschrapt kan worden zonder dat de app in een normale proef volledig zwijgt over het geld.

Toon één rustige bevestiging nadat de proef in een betaald abonnement is omgezet.

Herkomst

Eigenaar, 6 augustus 2026 · akkoord op voorstel 3 uit Plus-ontwerpstuk §3 · vervanger van E-PLUS-14.

Waarom

"Je Plus is actief", met wat er verandert en waar je het beheert. Eén keer, direct na de eerste afschrijving, zonder knop die iets verkoopt. Dit voorkomt de verrassingsafschrijving die eindigt in terugboekingen en recensies van één ster — het verschil tussen "ik was het vergeten maar ik wist het" en "ze hebben me stilletjes afgeschreven". Het kost niets aan conversie, want de afschrijving is dan al gedaan.

Raakt

TEN-157 · de entitlement-listener uit §5 · ADR-0023 (B3) — de overgang period_type TRIAL → NORMAL is het signaal · E-PLUS-16 · E-PLUS-07 · E-PLUS-18.

Dit gaat verder dan het Apple-minimum, en dat is bewust. Het strikte minimum is informeren bij de aankoop en daarna zwijgen; dat converteert op korte termijn beter. Maar een stille afschrijving die iemand pas op zijn bankafschrift ziet, kost een terugboeking, een recensie en een gebruiker die niet terugkomt. Met E-PLUS-16 afgewezen is dit het enige scherm dat die uitkomst nog tegenhoudt.

Laat het welkomstscherm per abonnement verschillen; toon de gezinsbelofte alleen bij Gezin.

Herkomst

Eigenaar, 6 augustus 2026 · na het lezen van het welkomstscherm in het Plus-ontwerpstuk §5.

Waarom

De kaart "Nodig je gezin uit — iedereen krijgt Plus, zonder extra kosten" is bij Solo niet overbodig maar onwaar. Een Solo-koper die op die kaart tikt en zijn gezin uitnodigt, denkt ze Plus te hebben gegeven terwijl ze in de gratis variant landen. Een verkeerde belofte op het moment dat iemand net betaald heeft is de duurste die er is: hij wordt pas ontdekt als er iemand anders bij betrokken is die het ook niet begrijpt.

Raakt

TEN-157 · E-PLUS-07 · E-PLUS-19 · welkomstscherm §5.

Technisch gratis. tier zit al in de rij die de listener leest (plus_entitlement.dart:52-56); het is één conditie om de rij weg te laten.

Toon een Solo-koper op de plek van de uitnodigingskaart een eerlijk upgrade-aanbod: "wil je dat je gezin ook Plus heeft? Dat is Gezin, € 20 per jaar meer."

Herkomst

Eigenaar, 6 augustus 2026 · akkoord op Solo-variant B uit Plus-ontwerpstuk §5 · volgt op E-PLUS-18, dat alleen het negatieve besluit vastlegde.

Waarom

Er stond twee antwoorden open: niets tonen, of één regel. Het is de regel geworden, omdat het sinds E-PLUS-21 geen verkooppraatje meer is maar relevante informatie: wie later iemand uitnodigt, móét op dat moment upgraden. Dat één keer rustig zeggen op het moment dat iemand aandachtig is, is eerlijker dan het later als verrassing te laten komen. Waar bij Gezin een belofte stond die klopt ("iedereen krijgt Plus"), staat hier dus een aanbod dat óók klopt — inclusief de prijs.

Raakt

TEN-157 · welkomstscherm §5 · E-PLUS-06 (prijs uit de aanbieding, niet uit een vaste string) · E-PLUS-18 · E-PLUS-21.

Positioneer Solo als het abonnement voor één account: één persoon logt in, met onbeperkt leden zónder account erbij.

Herkomst

Eigenaar, 6 augustus 2026 · beantwoordt de open vraag "Solo in een huishouden van vier" uit het Plus-ontwerpstuk §8, vraag 10. Later diezelfde dag herzien: de grens ligt bij het aantal accounts, niet bij het aantal leden — zie het blok hieronder.

Waarom

Volgens het freemium-besluit is cloud-sync zelf een Plus-functie. Waar het misgaat is dus niet "iemand gebruikt gezinsfuncties" maar "er zijn twee mensen die inloggen en er synchroniseert er één": dan werkt het gedeelde huishouden — de kern van het product — voor de helft van de mensen niet. Zolang er één account is, speelt dat niet, hoeveel leden er ook in het huishouden staan. Solo is dus "één persoon logt in", en Gezin is "twee of meer mensen loggen in".

Raakt

TEN-157 · E-PLUS-21 · E-PLUS-22 · E-PLUS-35 · prijsvolgorde op het Plus-vlak · ADR-0023 (de twee-Solo-botsing) · ADR-0020 (bevinding 7b).

Feitelijke afwijking, geverifieerd op 6 augustus 2026. In de code zit cloud-sync vandaag niet achter Plus: app_root.dart:115-117 schakelt cloud in op hasCloudSync && session != null, zonder entitlement-check. Alleen de doc-comment in plus_entitlement.dart:3-7 beweert dat het Plus is. Wat er nu gebeurt wijkt dus af van wat er besloten is — dat bepaalt of dit vandaag al een probleem is (nee) of pas zodra de gate erin gaat (ja). Zie ook E-PLUS-33.

Sta een Solo-abonnee niet toe iemand uit te nodigen zonder op dat moment te upgraden naar Gezin; een lid zónder account toevoegen raakt niets.

Herkomst

Eigenaar, 6 augustus 2026 · de handhaving bij E-PLUS-20. Later diezelfde dag herzien van "een tweede lid toevoegen" naar "iemand uitnodigen" — zie het blok hieronder.

Waarom

Je kunt als Solo geen tweede account opbouwen om daarna pas te betalen: het uitnodigen ís het upgrade-moment. En uitnodigen is precies de handeling die een tweede account maakt — daarmee valt de poort samen met de grens uit E-PLUS-20 in plaats van er iets naast te zetten. De poort ligt bij het uitnodigen en niet bij het gebruik achteraf: dat is de enige plek waar hij te begrijpen is en niet als straf voelt.

Raakt

TEN-157 · Instellingen → Huishouden · uitnodigingen · kindprofielen · koopflow (B5) · E-PLUS-22.

De flow. Waar: op elk scherm dat tot een uitnodiging leidt — één poort, meerdere deuren. Wat de gebruiker ziet: geen foutmelding maar een uitleg met een prijs, mét de naam van de persoon die hij net wilde uitnodigen. Bij doorgaan: de koopdialoog voor de upgrade, en pas ná een geslaagde upgrade gaat de uitnodiging de deur uit. Bij afbreken: het lid wordt niet toegevoegd en er blijft niets achter — geen half-toegevoegd lid, geen zwevende uitnodiging, geen "pending"-toestand die later opgeruimd moet worden. Elke andere keuze creëert een huishouden met meer accounts dan het abonnement toestaat, en dat is precies het probleem dat deze poort oplost.

Bied Solo niet aan zodra een huishouden meer dan één account heeft; toon dan alleen Gezin.

Herkomst

Eigenaar, 6 augustus 2026 · akkoord op het voorstel dat naast E-PLUS-21 was opengehouden. Later diezelfde dag herzien: geteld worden accounts, niet leden — zie het blok hieronder.

Waarom

De poort van E-PLUS-21 voorkomt nieuwe gemengde situaties, maar er zijn vandaag al huishoudens met meerdere accounts en die zijn er niet doorheen gekomen — de poort bestaat nog niet. Daarom wordt er bij het kopen gekeken hoeveel accounts het huishouden heeft; zijn het er meer dan één, dan is alleen Gezin te koop, met de zin "voor jullie alle vier". Dan hoeft er nergens iets geblokkeerd of teruggedraaid te worden en is de regel op elk moment uit te leggen. Het alternatief — Solo toestaan met een uitleg erbij — levert precies de asymmetrie op die E-PLUS-20 wilde wegnemen. Dit is bovendien consistent met E-PLUS-21: daar vereist het maken van een tweede account een upgrade, hier is het bestáán ervan een reden om Solo niet aan te bieden.

Raakt

TEN-157 · koopflow (B5) · het Plus-vlak (plankeuze) · E-PLUS-20 · E-PLUS-21 · ADR-0023 — de twee-Solo-botsing wordt hierdoor zeldzamer maar verdwijnt niet.

Wie vandaag al Solo heeft in zo'n huishouden houdt dat, ongemoeid. Dit is een regel over kopen, niet over hebben: een bestaand Solo-recht wordt niet ingetrokken, niet gedegradeerd en niet geblokkeerd zodra er een tweede account in het huishouden blijkt te staan. Er wordt niets teruggedraaid en niemand raakt iets kwijt. Wat zo iemand merkt is alleen dit: de andere accounts in dat huishouden krijgen géén Plus (dat is wat Solo is), en op het Plus-vlak wordt hem bij een volgende aankoop of verlenging alleen Gezin aangeboden. Er komt geen dwingende melding en geen afteller — dat zou een gebruiker straffen voor een situatie die door onze eigen ontbrekende poort is ontstaan. De asymmetrie lost zichzelf op zodra hij ooit naar Gezin gaat, en tot die tijd is hij zichtbaar en uitlegbaar in plaats van stil.

Dit heft de twee-Solo-botsing níet op. Twee huishoudens die elk een Solo-abonnement hebben en later samengevoegd worden, komen nog steeds op dezelfde rij in plus_entitlements uit; en deze regel werkt alleen vooruit. De sleutel per aankoop uit ADR-0023 (B2) blijft dus onverkort nodig — dat is de enige maatregel die ook op bestaande situaties werkt.

Behandel "de proef loopt af zonder aankoop" als uitzondering, niet als de normale afloop.

Herkomst

Eigenaar, 6 augustus 2026 · correctie op de opzet van het Plus-ontwerpstuk §6.

Waarom

Bij een auto-verlengend abonnement met introductieaanbieding is de standaarduitkomst dat de proef overgaat in betaald, en daarna dat dat abonnement doorloopt. Plus verliezen is een afwijking, en die heeft altijd een aanwijsbare oorzaak: actief opzeggen, verlengen uitzetten, een betalingsprobleem of een terugbetaling. Dat is meer dan woordkeuze — het bepaalt wanneer de app iets mag zeggen: niet op een klok die naar het einde telt, maar op een gebeurtenis die daadwerkelijk heeft plaatsgevonden.

Raakt

TEN-157 · Plus-ontwerpstuk §6 · E-PLUS-24.

Toon geen opzegpad zolang er niets is opgezegd.

Herkomst

Eigenaar, 6 augustus 2026 · sluit aan op E-PLUS-14.

Waarom

Een eerdere versie van §6 zette "Doorgaan met Plus" en "Opzeggen in de App Store" naast elkaar in een waarschuwing op dag 11. Dat strookt niet met het besluit om niet naar opzeggen te duwen: het is dezelfde uitnodiging als de permanente teller, alleen met een nettere motivering. Waar niets aan de hand is, zegt de app niets.

Raakt

TEN-157 · Plus-ontwerpstuk §6 · E-PLUS-25.

Toon ná een opzegging wél een afteller, met de concrete gevolgen erbij.

Herkomst

Eigenaar, 6 augustus 2026 · de keerzijde van E-PLUS-24.

Waarom

"Je hebt opgezegd, je proef loopt over 3 dagen af. Hierna verlies je toegang tot Budget, Auto en Documenten." Nu is er wél iets aan de hand, en dit is het enige moment waarop de kosten van stoppen concreet worden — daarmee is het meteen het sterkste re-conversiemoment dat er is. Niet "nog 3 dagen gratis", maar wát je over drie dagen niet meer kunt.

Raakt

TEN-157 · ADR-0023 (B3) — vereist will_renew en lapse_reason · E-PLUS-30 (de bijlagendownload hoort hier ook).

Geldt voor proef én betaald abonnement, met dezelfde schermen en zwaardere aantallen. Niet voor een naderende jaarlijkse verlenging waar niets is opgezegd: de afteller vóór de eerste afschrijving is een proef-ding omdat daar iets van gratis naar betaald gaat; een verlenging verandert niets aan de situatie en verdient dus geen scherm.

Maak bij het wegvallen van Plus glashelder dat de toegang tot die gegevens weg is, met een upgradepad dat de eerder gebruikte modules bij naam noemt.

Herkomst

Eigenaar, 6 augustus 2026 · Plus-ontwerpstuk §6.

Waarom

"Je gegevens zijn er nog, je kunt er alleen niet meer bij" is de enige formulering die tegelijk waar en begrijpelijk is. En het upgradepad wordt pas overtuigend als het over déze gebruiker gaat: "je gebruikte Budget, Auto en Documenten — met Plus staan ze er weer." Bij een jaarklant weegt dat zwaarder dan bij een proefgebruiker, omdat de aantallen groter zijn; dat verschil ontstaat vanzelf uit echte tellingen en vraagt geen tweede flow.

Raakt

TEN-157 · afloopscherm · E-PLUS-13 · E-PLUS-31.

Randgeval dat het afloopscherm de volle lading geeft. Wie op de láátste dag opzegt krijgt geen afteller — opzegging en verlies vallen samen. Hetzelfde geldt bij een terugbetaling. Alles wat in de afteller staat (welke modules op slot gaan, hoeveel bijlagen er zijn, de downloadknop) moet daarom óók op het afloopscherm staan. Dat de bijlagen daarna nog 90 dagen bereikbaar blijven (E-PLUS-28) is precies wat dit randgeval draaglijk maakt.

Verwijder nooit gegevens omdat een abonnement afloopt.

Herkomst

Eigenaar, 6 augustus 2026 · Plus-ontwerpstuk §6.

Waarom

Vergrendelen mag, wissen niet. Wie stopt met betalen heeft nog steeds recht op wat hij zelf heeft ingevoerd. Daarnaast een praktisch argument dat net zo hard is: zonder bewaring kan "toch weer Plus" niets terugbrengen, en dat is erger dan de opslag die je ermee uitspaart.

Raakt

TEN-157 · E-PLUS-13 · E-PLUS-28 · E-PLUS-29.

Geverifieerd, 6 augustus 2026 — en dit vereenvoudigt de hele vraag. Tendlo is local-first en er is geen enkel pad waarin het verlies van een Plus-recht data verwijdert: de runtime-modus hangt uitsluitend aan de Supabase-sessie (app_root.dart:115-117) en de sync-laag kent het begrip Plus niet. Wat er bij Plus-verlies gebeurt is puur een toegangsgrens — route-gate (app_router.dart:282-288), vergrendelde tegel (mijn_leven_screen.dart:55-61), gefilterde snelacties (module_quick_action_providers.dart:75-95). Wél gewist wordt er bij uitloggen (sync_connection.dart:53-57, disconnectAndClear()), bij "alles op dit toestel wissen" (data_reset_service.dart:51-68) en bij een huishoudenswissel (household_session_reset.dart:42) — geen van drieën gekoppeld aan het entitlement.

Uitgezocht op 6 augustus 2026 — de eerder gemelde valkuil is kleiner dan hij klonk. Free-modus en cloud-modus gebruiken inderdaad twee bestanden: app_database.dart:1490-1494 (mijn_pa) tegenover powersync_open.dart:10-12 (mijn_pa.ps.db). Bij uitloggen roept sync_connection.dart:53-57 disconnectAndClear() aan, dat in de PowerSync-laag select powersync_clear(1) uitvoert: het bestand wordt niet verwijderd, de tabellen worden geleegd — nergens in lib/ staat een pad dat mijn_pa.ps.db van schijf haalt. De cloudkopie bij Supabase blijft onaangeroerd (het uitlogpad raakt de server niet; de delete-tak van supabase_connector.dart:270-278 draait alleen op een echte gebruikersverwijdering), dus opnieuw inloggen brengt alles terug. Het is dus verdwijning uit beeld, niet dataverlies.

Twee uitzonderingen waar het wél echt weg is — vragen een eigen ticket. (1) powersync_clear(1) gooit óók de openstaande upload-wachtrij weg zonder die te versturen — precies waarom "alles op dit toestel wissen" hem gebruikt (data_reset_service.dart:38-44, privacy_screen.dart:120-128). Wie offline iets invoert en daarna uitlogt, verliest dat definitief; de server heeft het nooit gezien. De uitlogknop is een kale knop zonder bevestiging en zonder wachten op de wachtrij (instellingen_screen.dart:400-402). (2) Ná de 90 dagen uit E-PLUS-28 is de cloudkopie opgeruimd en is mijn_pa.ps.db het énige exemplaar; uitloggen leegt dat en er is niets om van terug te halen. De volgorde "Plus valt weg → 90 dagen verstrijken → uitloggen" is daarmee wél permanent verlies. Beide worden ondervangen door één ingreep: een bevestiging bij uitloggen die zegt wat er van het toestel verdwijnt, of er nog iets in de wachtrij staat, en of er nog een cloudkopie is.

Ruim de cloudkopie 90 dagen na het wegvallen van Plus op; de lokale kopie blijft.

Herkomst

Eigenaar, 6 augustus 2026 · akkoord op het voorstel van 90 dagen.

Waarom

Lang genoeg dat opnieuw Plus nemen alles terugbrengt alsof er niets gebeurd is — ook op een nieuw toestel — en kort genoeg om als bewaartermijn met een doel te verdedigen. Daarna opruimen. Omdat de lokale kopie blijft bestaan (E-PLUS-27), raakt deze termijn alleen de mogelijkheid om elders terug te halen.

Raakt

TEN-157 · Postgres/PowerSync · privacyverklaring (E-PLUS-32) · E-PLUS-29.

Waarschuw expliciet dat bijlagen alleen in de cloud bestaan en na de bewaartermijn echt verloren gaan.

Herkomst

Eigenaar, 6 augustus 2026 · op de vondst uit de verrijking van TEN-158.

Waarom

Van alle lagen is dit de enige waar de bewaartermijn tot echt verlies leidt. Foto's en documenten bestaan nergens anders, dus "er wordt niets verwijderd" geldt voor hen niet zonder voorbehoud. De waarschuwing hoort op drie plekken: in de afteller na opzegging (E-PLUS-25), op het afloopscherm (E-PLUS-26) en in het back-upscherm zelf.

Raakt

TEN-158 · TEN-157 · E-PLUS-30.

Geverifieerd, 6 augustus 2026. Bijlagen zijn metadata plus een pad; de bytes staan uitsluitend in Supabase Storage (attachments_table.dart:3-7, bucket in attachment_storage_service.dart:14). Er is geen persistente lokale cache: weergave gaat via Image.network op een signed URL van een uur, en er zit geen cached_network_image of flutter_cache_manager in pubspec.yaml. Bijlagen zijn daarmee ook nu al niet offline beschikbaar.

Geef de back-up een optie "inclusief bijlagen", en bied hem actief aan op het moment van opzeggen.

Herkomst

Eigenaar, 6 augustus 2026 · voorstel van de eigenaar zelf, als sluitstuk op de bewaarregel.

Waarom

Met bijlagen in de export is 90 dagen geen risico maar een ruime overgangsperiode: wie stopt kan álles meenemen, ook wat alleen in de cloud staat. Het is een keuze, geen standaard — bijlagen maken de export vele malen groter en de meeste exports hebben ze niet nodig, dus de omvang staat er zichtbaar bij en verandert de knop mee. Actief aanbieden bij opzegging omdat wie opzegt 90 dagen heeft om zijn bijlagen op te halen en daar zelf niet aan denkt. De eerlijke bijvangst: "download je bijlagen voordat ze verdwijnen" is oprechte service én een moment waarop iemand voelt wat hij opgeeft — dat mag, zolang de service echt is en de knop echt werkt.

Raakt

TEN-158 (bestemming, bewaring en de geëxporteerd-markering — die ontwerpvragen horen dáár en niet in het Plus-stuk) · TEN-173 (de te vroeg gezette markering, gefixt) · E-PLUS-29 · E-PLUS-33.

Geverifieerd, 6 augustus 2026. De back-up zit niet achter Plus: backup_screen.dart kent geen entitlement en de route /backup (app_router.dart:239-240) valt buiten de Plus-gate, die alleen module-routes matcht. De huidige export bevat alleen databasetabellen (backup_service.dart:40-75; :211-218 base64't alleen BLOB-kólommen, en de attachments-tabel heeft er geen) — van de bijlagen gaan dus alleen pad en metadata mee. Bijkomende beperking om te kennen: de export is lid-gescoopt, niet huishoudensbreed (backup_service.dart:3-9, :182-205).

Formuleer de afloop als "Plus valt weg", niet als "de proefperiode loopt af".

Herkomst

Eigenaar, 6 augustus 2026 · correctie op het Plus-ontwerpstuk §6, waar de "bewaard"-groep nog "Uit je proef" heette.

Waarom

Precies dezelfde situatie geldt voor iemand die na een jaar betaald abonnement opzegt — en die heeft veel méér opgebouwd. Eén model, één set schermen, één bewaarregel. Het verschil in gewicht ontstaat vanzelf uit echte tellingen en vraagt geen tweede flow.

Raakt

TEN-157 · alle teksten in §6 · E-PLUS-26 · E-PLUS-13.

Waar het verschil wél echt is, blijft het staan. De afteller vóór de eerste afschrijving is een proef-ding; de jaarlijkse verlenging is dat niet (E-PLUS-25). Generaliseren mag die twee niet op één hoop gooien.

Leg de bewaartermijn vast in de privacyverklaring, met doel en grens, en ruim aantoonbaar op.

Herkomst

Afgeleid uit E-PLUS-28 · AVG.

Waarom

Een bewaartermijn heeft onder de AVG een doel en een grens nodig en moet in de privacyverklaring staan. Het doel is hier goed te formuleren — "zodat je je abonnement kunt hervatten zonder gegevensverlies" — en de grens is de termijn zelf. Daarbij hoort dat het opruimen aantoonbaar gebeurt (een geplande taak, niet een voornemen) en dat de gebruiker de termijn kan bekorten door zijn account te verwijderen.

Raakt

Privacyverklaring · een geplande opruimtaak op de server · E-PLUS-28.

Storage lezen en exporteren blijven binnen de bewaartermijn van 90 dagen werken zonder Plus.

Herkomst

Eigenaar, 6 augustus 2026 — geaccepteerd. Oorspronkelijk afgeleid uit E-PLUS-28 en E-PLUS-30 · geverifieerd in de code op 6 augustus 2026. Zonder deze eis is de bewaartermijn een lege belofte zodra cloud-sync achter Plus gaat.

Waarom

Bijlagen worden opgehaald met een signed URL en die vereist een geldige Supabase-sessie (attachment_repository.dart:74-79, attachment_storage_service.dart:44-67). Vandaag gaat dat goed, want cloud-modus hangt aan de sessie en niet aan het entitlement (app_root.dart:115-117) — wie Plus verliest maar ingelogd blijft, kan zijn bijlagen de volle 90 dagen binnenhalen. Dat verandert zodra cloud-sync daadwerkelijk achter Plus gezet wordt, zoals het freemium-besluit voorschrijft: dan verbreekt het verlies van Plus de verbinding en zijn de bijlagen op datzelfde moment onbereikbaar — en is de bewaartermijn een lege belofte. Dit is een architectuurvoorwaarde, geen detail.

Raakt

ADR-0023 · E-PLUS-20 · E-PLUS-30 · de toekomstige Plus-gate op cloud-sync.

Hanteer één bewaartermijn van 90 dagen voor iedereen; laat hem niet meeschalen met de abonnementsduur.

Herkomst

Eigenaar, 6 augustus 2026 · beantwoordt de vraag die naast het besluit van 90 dagen (E-PLUS-28) was opengehouden.

Waarom

Een jaarklant heeft meer opgebouwd dan een proefgebruiker en verliest dus meer als de termijn verstrijkt — dat pleitte voor meeschalen. Toch één regel: één termijn is uitlegbaar aan een klant, differentiëren niet. "Negentig dagen" staat in één zin in de privacyverklaring en is in één query te implementeren; meeschalen levert een gesprek op dat je niet wint ("ik heb elf maanden betaald, waarom krijg ik dan de korte termijn?") en maakt van de bewaartermijn een variabele die overal meegedragen moet worden. Het verschil in gewicht wordt bovendien al opgevangen door E-PLUS-30: wie meer heeft, heeft ook meer reden om te exporteren, en de knop staat er.

Raakt

E-PLUS-28 · E-PLUS-32 · de opruimtaak op de server.

Deel co-ouderschap standaard niet met de andere ouder: het zijn twee aparte huishoudens, elk met eigen gegevens.

Herkomst

Eigenaar, 6 augustus 2026 · beantwoordt de vraag die ontstond bij de herziening van E-PLUS-20 (de accountgrens): hoort een ex-partner bij het huishouden met een eigen account?

Waarom

Nee. De co-ouderschapsmodule beschrijft perioden binnen één huishouden — bij wie de kinderen wanneer zijn — en de andere ouder doet daar niet aan mee. Twee gescheiden ouders zijn twee huishoudens met eigen gegevens, en dat is ook wat de gegevenslaag vandaag afdwingt: alles leeft binnen één huishouden en één RLS-scope. Synchronisatie tussen die twee is toekomstmuziek en nadrukkelijk niets voor nu.

Raakt

TEN-157 · co-ouderschap · E-PLUS-20 · E-PLUS-21 · E-PLUS-22.

Dit bevestigt de accountgrens. De module draait volledig binnen één huishouden en maakt dus geen tweede account aan. De alleenstaande ouder uit het scenario bij E-PLUS-20 blijft daarmee Solo, óók als ze co-ouderschap gebruikt — precies de uitkomst die de herziening moest opleveren. Er is geen pad waarlangs het gebruik van deze module iemand ongemerkt naar Gezin duwt.

Aandachtspunt voor later — geen eis, en er wordt nu niets voor gebouwd. Zou er ooit synchronisatie tussen twee huishoudens komen, dan is dat een wezenlijk ander model: gegevens delen over de grens van een huishouden én van een RLS-scope heen, terwijl vandaag alles binnen één huishouden leeft. Zorg dat het huidige ontwerp dat niet per ongeluk onmogelijk maakt, maar bouw er nu niets voor — geen kolom, geen vlag, geen "voorbereidend" veld. En als het er ooit komt: zoiets vraagt bewuste, wederzijdse instemming van beide ouders en mag nooit standaard aanstaan. Het gaat over mensen die uit elkaar zijn; een deelstand die per ongeluk aan staat is daar geen ongemak maar een echt probleem.

De gratis modules zijn er tien, niet negen: Lijstjes hoort in de opsomming.

Herkomst

Eigenaar, 6 augustus 2026 · gesprek. Sluit OV-4 van het domeinenstuk, dat de vraag stelde of het weglaten van Lijstjes bedoeld was of een omissie.

Waarom

Het freemium-besluit somde er negen op: Vandaag, Taken, Agenda, Boodschappen, Maaltijden, Verjaardagen, Schoolvakanties, Afvalkalender, Bewaarlijsten. Lijstjes ontbrak, en dat kán niet kloppen: hij staat in kCoreSurfaceModuleIds (lib/core/modules/module_registry.dart:14-19), staat dus voor ieder lid altijd aan, heeft geen activatie-schakelaar en is met E-MOD-12 uitdrukkelijk kern. Een module die je niet kunt uitzetten, kun je ook niet verkopen. De lijst miste een regel.

Raakt

E-MOD-12 · E-WID-10 · E-WID-19 · E-PLUS-01 · memory freemium-tier-split · elke plek in het corpus waar de negen worden opgesomd.

Dit is een correctie van een telling, geen herverdeling van tiers. Er verhuist geen enkele module van Plus naar gratis of andersom. De tier-grens zelf — cloud-sync, gezinsdeling en álle AI zijn Plus — blijft precies waar hij lag.

Nageteld in de code. Precies vijf registry-modules dragen tier: ModuleTier.free: bewaarlijsten (lib/features/bewaarlijsten/bewaarlijsten_module.dart:35), schoolvakanties (lib/features/gezin/gezin_module.dart:91), verjaardagen (:101), afvalkalender (lib/features/planning/planning_module.dart:96) en maaltijden (:124). Daarbij de vier kernoppervlakken — Taken, Agenda, Lijstjes en Boodschappen — en de tab Vandaag: 5 + 4 + 1 = 10.

Let op de noemer: de tien en de registratietelling meten niet hetzelfde. Vandaag, Taken, Agenda en Lijstjes zijn géén ModuleDescriptors, dus ze komen niet voor in een telling over de registry. Na E-MOD-12 verschuift Boodschappen wél naar de registry, en dan luidt dezelfde tien anders opgeteld: zes gratis registry-modules (de vijf hierboven plus Boodschappen), drie kernoppervlakken (Taken · Agenda · Lijstjes) en de tab Vandaag — nog steeds tien. Van de 29 modules uit E-MOD-13 zijn er dan zes gratis en 23 Plus. Wie die twee tellingen naast elkaar legt zonder de noemer erbij te zeggen, ziet een tegenspraak die er niet is.