Update roadmap and review documentation

README.md

@@ -22,6 +22,8 @@ product, niet als medisch hulpmiddel. Release 1 blijft smal:
 - dashboardweergave van check-instatus, energieniveau en dagbudget
 - planningsfundering met activiteitenmodel, categorieën en skip-redenen in Supabase
 - planningpagina voor vandaag met activiteit toevoegen en directe lijstweergave
+- statusflows voor activiteiten van vandaag (`gepland`, `uitgevoerd`, `overgeslagen`, `aangepast`)
+- contextuele evaluatievelden voor overgeslagen en aangepaste activiteiten
 - energiemeter met lopend totaal ten opzichte van het dagbudget
 - niet-blokkerende waarschuwing bij budgetoverschrijding in planning en dashboard
 - eerste unit tests voor budget- en meterlogica via `Vitest`
@@ -103,13 +105,12 @@ tokens voor rustige, niet-medische feedback.
 
 De app gebruikt nu een gedeelde topnavigatie:
 
-- links: `About`, `Planning`, `Instellingen`
+- links: `About`, `Dashboard`, `Planning`, `Check-in`
 - rechts: `Account` en `Theme`
 
 `/` is de publieke `About`-pagina met informatie over de maker en de scope van
-de app. In het `Account`-menu komen ingelogde gebruikers bij `Dashboard`,
+de app. In het `Account`-menu komen ingelogde gebruikers bij `Instellingen` en
-`Check-in` en `Uitloggen`; uitgelogde gebruikers zien daar `Inloggen` en
+`Uitloggen`; uitgelogde gebruikers zien daar `Inloggen` en `Account aanmaken`.
-`Account aanmaken`.
 
 ## Interne wizard-test
 
@@ -132,7 +133,7 @@ zichtbaar als `NEXT_PUBLIC_ENABLE_TEST_WIZARD=true` staat.
 
 ## Eerstvolgende bouwstappen
 
-1. `ST-303` Autocomplete op eerdere activiteiten toevoegen
+1. `ST-403` Ongeplande activiteiten ondersteunen
-2. `ST-401` Evaluatie- en dagoverzichtslus bouwen
+2. `ST-404` Dagoverzicht bouwen
-3. `ST-404` Dagoverzicht bouwen
+3. `ST-405` Dagaggregaties server-side implementeren
 4. `ST-105` RLS-policy tests en hardening afronden

aanbeveling-claude.md

@@ -1,136 +1,305 @@
-# Aanbevelingen voor Inspannings Monitor
+# Actuele prioriteiten voor Inspannings Monitor
 
-Dit bestand bevat aanbevelingen gebaseerd op analyse van de broncode, documentatie en backlog (peildatum: 2026-04-18). Bedoeld als leidraad voor toekomstige werksessies.
+Peildatum: **19 april 2026** — bijgewerkt op basis van de huidige codebase en de
+recente implementaties voor check-in, planning, energiemeter, Dusk-thema en
+navigatiestructuur.
 
 ---
 
-## Huidige status
+## Samenvatting
 
-De volgende onderdelen zijn volledig geïmplementeerd en van goede kwaliteit:
+De app heeft inmiddels een **sterk fundament**:
 
-| Onderdeel | Status |
+- auth en protected routes werken
-|---|---|
+- onboarding en instellingen zijn aanwezig
-| Authenticatie (login, signup, e-mailbevestiging, uitloggen) | ✅ Af |
+- ochtendcheck-in en budgetlogica zijn aanwezig
-| Beveiligde routes met server-side sessiecontrole | ✅ Af |
+- planning en energiemeter zijn aanwezig
-| Onboarding flow (3 stappen, profiel- en instellingenopslag) | ✅ Af |
+- error/loading routes bestaan voor de belangrijkste dataroutes
-| Instellingenbeheer (tijdzone, herinneringen, energiepunten) | ✅ Af |
+- pending states en toastfeedback zijn aanwezig
-| Databaseschema met RLS-beleid | ✅ Af |
+- CI/CD, branch protection en Vercel-deploy staan
-| CI/CD (GitHub Actions + Vercel) | ✅ Af |
+
-| Branchbeveiliging op `main` | ✅ Af |
+De grootste winst zit nu niet meer in fundering, maar in:
+
+1. **de plan-do-evalueer-lus sluiten**
+2. **kritieke technische gaten dichten vóór launch**
+3. **test- en securitylaag versterken**
 
 ---
 
-## Volgende prioriteiten (volgorde uit backlog)
+## Wat al op orde is
 
-### 1. ST-201 — Ochtendcheck-in UI (P0, EPIC-03)
+Deze punten stonden eerder als aanbeveling open, maar zijn inmiddels al
-Het hart van de applicatie. Zonder check-in heeft het dashboard geen inhoud. Bouwen als:
+afgerond of grotendeels opgelost:
-- Energieschuifregelaar (1–10)
-- Slaapkwaliteitsinput (goed / matig / slecht)
-- Opslaan in nieuwe tabel `morning_check_ins`
-- Check-in status tonen op het dashboard (al ingevoerd of nog niet)
 
-### 2. ST-203 — Budgetberekening (P0, EPIC-03)
+- `error.tsx` voor de belangrijkste app-routes
-Zodra de check-in werkt, berekent de app automatisch het dagbudget op basis van de energiescore. Vereist:
+- `loading.tsx` voor dashboard, check-in en planning
-- Score-naar-budget mapping (formule vastleggen vóór implementatie)
+- pending states in onboarding, settings, check-in en planning
-- Edge cases: score = 1, score = 10, geen check-in
+- centrale toastlaag voor redirect- en action-feedback
-- Eenheidstests voor de berekeningslogica — dit is de enige plek in het project waar tests nu echt urgent zijn
+- expliciete `FormData`-validatie
+- wizard-core en onboarding-refactor
+- ochtendcheck-in en budget v1
+- planning, energiemeter en niet-blokkerende budgetwaarschuwing
+- Dusk-themafundering en toegankelijkheidspolish
+- topnavigatie met publieke About-pagina
 
-### 3. ST-301 t/m ST-305 — Dagplanning en energiemeter (P0, EPIC-04)
+Deze punten hoeven dus **niet** opnieuw als directe actielijst te worden gezien.
-- Activiteiteninvoer met categorie, duur en energiepuntschatting
-- Lopende energiemeter (resterend budget)
-- Waarschuwing bij overschrijding (niet-blokkerend)
-- Vereist nieuwe tabellen: `activities`, `activity_instances`, `activity_categories`
-
-### 4. ST-401 t/m ST-405 — Evaluatie en dagoverzicht (P0, EPIC-05)
-- Activiteiten afvinken als voltooid, overgeslagen of aangepast
-- Dagelijkse samenvatting: gepland vs. werkelijk
-- Sluit de plan-do-evaluate-lus
-
-### 5. ST-105 — RLS hardening (P0, EPIC-08, parallel uitvoeren)
-RLS-beleid is aangemaakt maar nog niet grondig getest. Voer dit parallel uit aan de feature-bouw:
-- Testscripts schrijven die proberen om andermans rijen te lezen/schrijven
-- Bevestigen dat `service_role`-key nergens in de frontend of Vercel-configuratie staat
 
 ---
 
-## Technische schuld
+## Nu doen
 
-De huidige code is van goede kwaliteit, maar bevat een aantal verbeterpunten die bij de volgende feature-bouwfase opgepakt kunnen worden — niet nu, maar vóór launch.
+Dit zijn de hoogste actuele prioriteiten voor de eerstvolgende sprint.
 
-### Matig urgent
+### 1. ST-401 t/m ST-405 — Evaluatie en dagoverzicht
 
-| Probleem | Bestand(en) | Oplossing |
+De app ondersteunt nu:
-|---|---|---|
-| `getParamValue()` 4× gedupliceerd | `app/*/page.tsx` | Verplaats naar `lib/auth/params.ts` |
-| `onboarding-flow.tsx` is 343 regels | `components/onboarding/onboarding-flow.tsx` | Splits in drie stapcomponenten |
-| `settings-form.tsx` dupliceert toestandslogica van onboarding | `components/settings/settings-form.tsx` | Extraheer gedeelde hook |
 
-### Laag urgent (vóór launch)
+- check-in
+- plannen
+- energiebudget
 
-| Probleem | Bestand(en) | Oplossing |
+Maar de daglus is nog niet af zolang de gebruiker activiteiten niet kan:
-|---|---|---|
+
-| Geen laadstatus tijdens server actions | `onboarding-flow.tsx`, `settings-form.tsx` | Gebruik `useTransition` + pending-state |
+- afronden
-| Geen toast/melding na formulieropslaan | Alle clientcomponenten | shadcn/ui `toast` toevoegen |
+- overslaan
-| Booleaanse extractie uit FormData stil faalbaar | `app/**/actions.ts` | Expliciete validatie toevoegen |
+- aanpassen
+- samenvatten in een dagoverzicht
+
+**Waarom nu:** dit is de grootste productmatige ontbrekende schakel. De app
+voelt nu al nuttig, maar nog niet “rond”.
+
+**Concreet:**
+
+- activiteitstatus wijzigen naar `completed`, `skipped`, `adjusted`
+- ongeplande activiteit kunnen toevoegen
+- dagaggregaties berekenen
+- dagoverzicht tonen met totalen en statusverdeling
 
 ---
 
-## Risico's en aandachtspunten vóór launch
+### 2. `npm test` toevoegen aan CI
 
-### Security
+De app heeft nu unit tests voor:
-- **Oud `service_role`-geheim in git-history**: Sleutel is als gecompromitteerd behandeld en niet meer in gebruik. Git-history opschonen is nog niet gedaan. Voer dit uit vóór publieke launch als extra voorzorgsmaatregel (`git filter-repo` of BFG Repo Cleaner).
-- **RLS nog niet gehard (ST-105)**: Blokkeer launch totdat dit getest is.
-- **Rate limiting ontbreekt (ST-701)**: Sign-up en sign-in eindpunten zijn momenteel niet beperkt op applicatieniveau (Supabase heeft eigen throttling, maar expliciete applicatielaag ontbreekt).
 
-### Privacy
+- budgetlogica
-- **DPIA nog niet gedaan (ST-803)**: Verplicht vóór launch omdat gezondheidsdata wordt verwerkt, ook al zijn het welzijnsgegevens.
+- energiemeterlogica
-- **Copyreview (ST-803)**: Alle teksten moeten door een copycheck — geen medische claims, geen diagnoses, geen therapeutisch advies. Dit is een harde launchpoort.
-- **Gegevensretentie**: Nog geen beleid of implementatie voor het verwijderen van oude daggegevens.
 
-### Kwaliteit
+Maar in CI draaien nog alleen:
-- **Geen testinfrastructuur**: Er zijn geen tests. Minimaal de budgetberekening (ST-203) en RLS-beleid vereisen geautomatiseerde tests vóór launch.
+
-- **Geen toegankelijkheidsaudit (ST-802)**: WCAG 2.1 AA is de norm; nog niet gecontroleerd.
+- `lint`
+- `build`
+
+**Waarom nu:** dit is een kleine wijziging met directe kwaliteitswinst.
+
+**Concreet:**
+
+- voeg `npm run test` toe aan `.github/workflows/ci.yml`
 
 ---
 
-## Architectuuradvies voor de volgende bouwfase
+### 3. Tijdzonehelper dedupliceren
 
-### Databaseschema uitbreiden
+`getLocalDateForTimezone()` staat nu nog dubbel in:
-Voeg tabellen toe in deze volgorde (met migraties in `/supabase/migrations/`):
-1. `morning_check_ins` — energiescore, slaapkwaliteit, berekend budget, datum
-2. `activity_categories` — referentiedata (naam, standaard energiepunten)
-3. `activities` — geplande activiteiten per dag per gebruiker
-4. `activity_instances` — werkelijk uitgevoerd, overgeslagen of aangepast
-5. `skip_reasons` — optionele referentiedata
 
-Alle tabellen krijgen RLS-beleid op `user_id = auth.uid()`.
+- `lib/check-in/service.ts`
+- `lib/planning/service.ts`
 
-### Servicelaag uitbreiden (`lib/`)
+**Waarom nu:** klein, veilig en voorkomt toekomstige divergentie.
-Volg het bestaande patroon in `lib/profile/service.ts`:
-- Maak `lib/checkin/service.ts` voor ochtendcheck-in logica
-- Maak `lib/planning/service.ts` voor activiteitenbeheer
-- Houd serveracties (`app/**/actions.ts`) dun — valideren, delegeren naar service, redirecten
 
-### Componentstrategie
+**Concreet:**
-- Gebruik het bestaande shadcn/ui-fundament (`components/ui/`)
-- Voeg geen nieuwe UI-bibliotheek toe
-- Bouw feature-componenten in eigen mappen (`components/checkin/`, `components/planning/`, `components/evaluation/`)
-- Voeg `useTransition` toe zodra een form meer dan één server roundtrip kost
 
-### Wanneer testen toevoegen
+- verplaats naar `lib/dates.ts`
-- Start met tests bij ST-203 (budgetberekening) — pure functie, makkelijk te testen
+- importeer vanuit beide services
-- Voeg RLS-integratietests toe bij ST-105
-- Gebruik Vitest (past bij de huidige toolchain, geen extra configuratie nodig naast het toevoegen van het pakket)
 
 ---
 
-## Samenvatting prioriteitsvolgorde
+### 4. Onverwachte DB-fouten consistenter afvangen in server actions
 
+Validatiefouten worden al goed afgehandeld. Wat nog niet overal strak genoeg is:
+
+- onverwachte Supabase/DB-fouten
+- partiële storingen in servicecalls
+
+Nu eindigen sommige fouten nog als generieke exception, terwijl de gebruiker
+beter een nette foutcode/toast kan krijgen.
+
+**Waarom nu:** dit verhoogt herstelbaarheid zonder grote refactor.
+
+**Concreet:**
+
+- alle action-bestanden nalopen
+- onverwachte servicefouten mappen naar gebruikersvriendelijke foutcodes
+- bestaande `status/error`-toastpatronen hergebruiken
+
+---
+
+## Daarna doen
+
+Deze punten zijn belangrijk, maar komen logisch ná de evaluatiefase.
+
+### 5. ST-105 — RLS hardening en echte policy-tests
+
+RLS staat aan en ziet er inhoudelijk goed uit, maar is nog niet systematisch
+getest tegen misbruikscenario’s.
+
+**Concreet:**
+
+- SQL-tests of handmatige scripts schrijven
+- lezen/schrijven van andermans rijen expliciet proberen
+- checken dat frontend/Vercel geen admin-secret gebruikt
+
+**Waarom daarna:** belangrijk vóór launch, maar blokkeert de volgende productstap
+niet direct.
+
+---
+
+### 6. Testdekking uitbreiden rond pure logica
+
+Na de bestaande budget- en meter-tests zijn dit de beste vervolgstukken:
+
+- `lib/forms/parse.ts`
+- toekomstige dagaggregatie voor evaluatie
+- tijdzone/datumhelpers zodra die gedeeld zijn
+
+**Waarom daarna:** klein en waardevol, maar minder productkritisch dan ST-401.
+
+---
+
+### 7. Transactie of RPC voor onboarding-opslag
+
+`completeOnboardingForCurrentUser()` doet nu twee losse updates:
+
+- `profiles`
+- `user_settings`
+
+Dat werkt, maar kent een klein risico op partiële opslag als de tweede write
+faalt.
+
+**Concreet:**
+
+- ofwel Supabase RPC
+- ofwel server-side transactiepad waar haalbaar
+
+**Waarom daarna:** belangrijk voor netheid en robuustheid, maar geen acute
+blokkade.
+
+---
+
+## Vóór launch
+
+Deze punten hoeven niet allemaal in de volgende sprint, maar moeten wel vóór een
+serieuze publieke introductie op orde zijn.
+
+### 8. Logging en monitoring
+
+Nu ontbreekt nog een echte productieloglaag zoals:
+
+- Sentry
+- of vergelijkbare error monitoring
+
+**Nodig voor:**
+
+- incidenten terugvinden
+- onverwachte action-/DB-fouten volgen
+- regressies sneller herkennen
+
+---
+
+### 9. Rate limiting
+
+Nu leunt auth vooral op Supabase-limieten. Voor de app zelf ontbreekt nog
+bewuste begrenzing op mutaties zoals:
+
+- check-in opslaan
+- activiteit toevoegen
+- latere evaluatie-updates
+
+**Doel:** misbruik, spam en piekgedrag beperken.
+
+---
+
+### 10. Secret-history cleanup
+
+Een oude Supabase `service_role` key heeft eerder in de git-history gestaan.
+
+Ook al is die key niet meer actief in de app, vóór publieke launch is het nog
+steeds verstandig om:
+
+- die geschiedenis op te schonen
+- en te bevestigen dat de sleutel niet meer bruikbaar is
+
+---
+
+### 11. Accessibility, copy en privacy-review
+
+Voor launch nog nalopen:
+
+- toetsenbord- en screenreaderflow op kritieke routes
+- wellness/self-management copy zonder medische framing
+- privacy/DPIA-check passend bij jullie positionering
+
+---
+
+## Later
+
+Deze punten zijn nuttig, maar nu nog niet de beste besteding van tijd.
+
+### 12. Paginering en schaaloptimalisaties
+
+Bij de huidige MVP is de activiteitslijst nog klein. Zaken als:
+
+- paginering
+- geavanceerde caching
+- query-optimisaties voor grote datasets
+
+zijn voorlopig geen topprioriteit.
+
+---
+
+### 13. Supabase codegeneratie voor types
+
+De huidige handmatige mapping is nog beheersbaar. Codegeneratie via Supabase CLI
+kan later waardevol worden, maar nu voegt het waarschijnlijk meer toolinglast
+toe dan directe winst.
+
+---
+
+### 14. Zwaardere compliance-laag
+
+Formele zorgcompliance, audittrail en NEN-achtige eisen zijn pas logisch als de
+productpositionering echt opschuift richting zorgmarkt. Voor de huidige
+wellness-first MVP is dat nog niet de eerstvolgende stap.
+
+---
+
+## Aangescherpte prioriteitsvolgorde
+
+```text
+Nu:         ST-401–405 (evaluatie en dagoverzicht)
+Nu:         npm test toevoegen aan CI
+Nu:         getLocalDateForTimezone() dedupliceren naar lib/dates.ts
+Nu:         onverwachte DB-fouten in actions consistenter mappen
+Daarna:     ST-105 (RLS hardening en policy-tests)
+Daarna:     extra tests voor parse- en aggregatielogica
+Daarna:     onboarding-opslag transactioneler maken
+Vóór launch: logging/monitoring
+Vóór launch: rate limiting
+Vóór launch: secret-history cleanup
+Vóór launch: accessibility/copy/privacy review
+Later:      paginering, codegen, zwaardere compliance-laag
 ```
-Nu:         ST-201 (ochtendcheck-in UI)
+
-Dan:        ST-203 (budgetlogica + eerste tests)
+---
-Daarna:     ST-301–305 (dagplanning)
+
-Daarna:     ST-401–405 (evaluatie)
+## Korte conclusie
-Parallel:   ST-105 (RLS), ST-701 (rate limiting)
+
-Vóór launch: ST-802 (toegankelijkheid), ST-803 (copy + DPIA)
+De app is niet meer in de fase van “fundering ontbreekt”. Die fase is grotendeels
-```
+voorbij. De actuele focus moet nu verschuiven naar:
+
+- de gebruikerslus afmaken
+- reliability aanscherpen
+- en launch-risico’s gecontroleerd terugdringen
+
+De beste volgende inhoudelijke stap is daarom nog steeds:
+
+**`ST-401 t/m ST-405` — evaluatie en dagoverzicht.**