janpeter/inspannings-monitor
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update roadmap and review documentation

Browse source
This commit is contained in:
Janpeter Visser 2026-04-19 10:22:18 +02:00
parent 42d88ce8d6
commit 5641fffaff
2 changed files with 274 additions and 104 deletions
Download patch file Download diff file Expand all files Collapse all files

15
README.md
View file

@ -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`,
`Check-in` en `Uitloggen`; uitgelogde gebruikers zien daar `Inloggen` en
`Account aanmaken`.
de app. In het `Account`-menu komen ingelogde gebruikers bij `Instellingen` en
`Uitloggen`; uitgelogde gebruikers zien daar `Inloggen` en `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
2. `ST-401` Evaluatie- en dagoverzichtslus bouwen
3. `ST-404` Dagoverzicht bouwen
1. `ST-403` Ongeplande activiteiten ondersteunen
2. `ST-404` Dagoverzicht bouwen
3. `ST-405` Dagaggregaties server-side implementeren
4. `ST-105` RLS-policy tests en hardening afronden

363
aanbeveling-claude.md
View file

@ -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 |
|---|---|
| Authenticatie (login, signup, e-mailbevestiging, uitloggen) | ✅ Af |
| Beveiligde routes met server-side sessiecontrole | ✅ Af |
| Onboarding flow (3 stappen, profiel- en instellingenopslag) | ✅ Af |
| Instellingenbeheer (tijdzone, herinneringen, energiepunten) | ✅ Af |
| Databaseschema met RLS-beleid | ✅ Af |
| CI/CD (GitHub Actions + Vercel) | ✅ Af |
| Branchbeveiliging op `main` | ✅ Af |
- auth en protected routes werken
- onboarding en instellingen zijn aanwezig
- ochtendcheck-in en budgetlogica zijn aanwezig
- planning en energiemeter zijn aanwezig
- error/loading routes bestaan voor de belangrijkste dataroutes
- pending states en toastfeedback zijn aanwezig
- CI/CD, branch protection en Vercel-deploy staan
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)
Het hart van de applicatie. Zonder check-in heeft het dashboard geen inhoud. Bouwen als:
- 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)
Deze punten stonden eerder als aanbeveling open, maar zijn inmiddels al
afgerond of grotendeels opgelost:
### 2. ST-203 — Budgetberekening (P0, EPIC-03)
Zodra de check-in werkt, berekent de app automatisch het dagbudget op basis van de energiescore. Vereist:
- Score-naar-budget mapping (formule vastleggen vóór implementatie)
- Edge cases: score = 1, score = 10, geen check-in
- Eenheidstests voor de berekeningslogica — dit is de enige plek in het project waar tests nu echt urgent zijn
- `error.tsx` voor de belangrijkste app-routes
- `loading.tsx` voor dashboard, check-in en planning
- pending states in onboarding, settings, check-in en planning
- centrale toastlaag voor redirect- en action-feedback
- 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)
- 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
Deze punten hoeven dus **niet** opnieuw als directe actielijst te worden gezien.
---
## 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 |
|---|---|---|
| `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 |
De app ondersteunt nu:
### Laag urgent (vóór launch)
- check-in
- plannen
- energiebudget
| Probleem | Bestand(en) | Oplossing |
|---|---|---|
| Geen laadstatus tijdens server actions | `onboarding-flow.tsx`, `settings-form.tsx` | Gebruik `useTransition` + pending-state |
| Geen toast/melding na formulieropslaan | Alle clientcomponenten | shadcn/ui `toast` toevoegen |
| Booleaanse extractie uit FormData stil faalbaar | `app/**/actions.ts` | Expliciete validatie toevoegen |
Maar de daglus is nog niet af zolang de gebruiker activiteiten niet kan:
- afronden
- overslaan
- 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
- **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).
De app heeft nu unit tests voor:
### Privacy
- **DPIA nog niet gedaan (ST-803)**: Verplicht vóór launch omdat gezondheidsdata wordt verwerkt, ook al zijn het welzijnsgegevens.
- **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.
- budgetlogica
- energiemeterlogica
### Kwaliteit
- **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.
Maar in CI draaien nog alleen:
- `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
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
`getLocalDateForTimezone()` staat nu nog dubbel in:
Alle tabellen krijgen RLS-beleid op `user_id = auth.uid()`.
- `lib/check-in/service.ts`
- `lib/planning/service.ts`
### Servicelaag uitbreiden (`lib/`)
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
**Waarom nu:** klein, veilig en voorkomt toekomstige divergentie.
### Componentstrategie
- 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
**Concreet:**
### Wanneer testen toevoegen
- Start met tests bij ST-203 (budgetberekening) — pure functie, makkelijk te testen
- Voeg RLS-integratietests toe bij ST-105
- Gebruik Vitest (past bij de huidige toolchain, geen extra configuratie nodig naast het toevoegen van het pakket)
- verplaats naar `lib/dates.ts`
- importeer vanuit beide services
---
## 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)
Parallel: ST-105 (RLS), ST-701 (rate limiting)
Vóór launch: ST-802 (toegankelijkheid), ST-803 (copy + DPIA)
```
---
## Korte conclusie
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.**