# Changelog

## [Niet vrijgegeven]

### Beveiliging
- **De postgres-container draait niet meer als root.** Beide compose-bestanden
  starten hem met `user: "postgres"`. Alle 46 bevindingen op `postgres:18-alpine`
  zitten in één bestand — `/usr/local/bin/gosu`, dat upstream met Go 1.24.6
  compileert — en het entrypoint roept gosu alleen aan als het als root start.
  Non-root starten slaat die tak over, dus de binary draait nooit meer. De
  Alpine-pakketten in dat image zijn zelf schoon
- Getest op een bestaande database die ooit als root was aangemaakt: die start
  als non-root en de data blijft intact. Ook een verse database initialiseert
  gewoon
- Bewust géén eigen postgres-image gebouwd om die binary te verwijderen. Dat zou
  de scan op nul zetten maar je verplichten het image zelf te herbouwen bij elke
  postgres-patch — precies de achterstand die het image vier maanden op 18.4 met
  143 bevindingen hield. De afweging staat in `BEHEER.md`, zodat de volgende
  scan niet opnieuw tot dezelfde vraag leidt
- `test.ps1` waarschuwt bij stap 4 wanneer `postgres:18-alpine` in de registry
  nieuwer is dan wat er lokaal staat. Die achterstand is het werkelijke risico;
  het getal in de scan is dat niet

## [1.0.11] - 2026-09-18

### Beveiliging
- **PostgreSQL 18.4 → 18.6.** Het `postgres:18-alpine` image dat in gebruik was
  dateerde van vier maanden geleden. Dat is een patch binnen dezelfde major, dus
  de data-directory blijft geldig en er komt geen dump/restore aan te pas — het
  volume blijft gewoon staan. De kwetsbaarhedenscan op het image gaat van 143
  naar 45 bevindingen, het grootste deel in de Alpine-pakketten eronder. Wat
  overblijft (1 kritiek, 21 hoog) zit allemaal in Go's `stdlib` v1.24.6 in een
  meegecompileerde binary; dat kan alleen upstream oplossen
- `BEHEER.md` beschreef alleen de major-upgrade, met een `docker compose down
  -v` erin. Wie dat bij een patch-upgrade zou volgen, wist zijn database zonder
  dat het nodig is. De twee gevallen staan nu apart beschreven
- **De imagescan staat op nul.** De scan van 1.0.10 gaf 39 bevindingen
  (1 kritiek, 12 hoog, 15 middel, 11 laag). Geen enkele kwam uit deze
  applicatie: twintig zaten in `libssl3` en `libcrypto3` (Alpine in het
  node-image liep achter op 3.5.8-r0) en negentien in de dependencies die npm
  zelf meelevert — `tar`, `pacote`, `sigstore`, `brace-expansion`, `picomatch`,
  `ip-address`. De eigen `ip-address` van de app stond al op 10.7.0 en was dus
  nooit het probleem
- Het productie-image doet nu een `apk upgrade` aan het eind van de build. Het
  node-image wordt minder vaak herbouwd dan Alpine patches uitbrengt, dus
  OpenSSL loopt er structureel op achter
- npm, npx, corepack en yarn gaan uit het productie-image. De container start
  met `node src/server.js` en gebruikt nooit een pakketbeheerder; ze zaten er
  alleen in omdat het base-image ze meelevert. Weg met de tool is weg met die
  hele categorie, ook bij de volgende ronde — npm's dependencies zijn een
  terugkerende bron van meldingen
- Nieuwe teststap **[4/5] Imagescan** met Trivy, die het gebouwde image scant en
  faalt op CRITICAL of HIGH waarvoor een fix bestaat (`--ignore-unfixed`, want
  een CVE zonder patch hoort je release niet te blokkeren). `-Strict` trekt de
  lat naar MEDIUM en LOW, `-SkipScan` slaat hem over. Stap 1 kijkt naar de
  `package.json`'s en had geen van deze 39 gezien; deze kijkt naar wat er
  werkelijk in het image zit. `release.ps1` draait dezelfde scan vóór het
  pushen, dus een image met openstaande CVE's komt de registry niet meer in

### Toegevoegd
- **Export naar HTML.** Onder Instellingen staat naast backup en restore nu
  "Exporteren naar HTML": één zelfdragend bestand met al je gegevens, bedoeld
  als laatste vangnet. Draait de app niet meer, is de database weg en ligt er
  geen backup, dan is dit bestand nog steeds te openen — in elke browser, op een
  computer zonder internet. Er zit niets van buiten in: opmaak staat inline,
  geen lettertypen, geen afbeeldingen, geen scripts
- De pagina toont een samenvatting met de KPI's, en daaronder eigen vermogen en
  schulden per categorie met subtotalen en een eindtotaal, de voortgangstabel
  met verschil per moment, en de historie van EV en schuld. Bedragen staan met
  twee decimalen — anders dan het scherm, want dit is een archiefstuk waar de
  exacte waarde in hoort — rechts uitgelijnd met cijfers van gelijke breedte
- **Het bestand is tegelijk een backup.** Onderin staat de complete ruwe data in
  een `<script type="application/json">`-blok dat de browser niet uitvoert en
  niet toont. "Backup herstellen" accepteert daarom nu naast de ZIP ook zo'n
  HTML-bestand. Eén bestand dat je zowel kunt lezen als kunt terugzetten
- Uitvoer wordt zowel als HTML als binnen het JSON-blok ge-escaped. Een post die
  `Fonds <A> & co` heet, of een `</script>` in de gegevens, sloopt de pagina
  niet en breekt de ingebakken backup niet open
- Nieuwe `utils/htmlExport.js`, met `leesHtmlBackup` voor de weg terug. Die
  gebruikt `DOMParser` en geen reguliere expressie: de gegevens kunnen van alles
  bevatten, en een parser die HTML echt begrijpt trapt daar niet in. Geen nieuwe
  dependency
- De voortgangstabel is Datum plus één kolom per categorie plus vier vaste
  kolommen — bij zes categorieën twaalf stuks, en die passen op geen enkel
  scherm. De tabellen scrollen daarom horizontaal in plaats van kolommen buiten
  beeld te laten vallen. De datumkolom blijft daarbij staan, want zonder die
  kolom weet je niet meer naar welk moment je kijkt, en een schaduwrandje
  verschijnt aan de kant waar nog inhoud zit. Dat laatste is een CSS-truc met
  meeschuivende achtergronden: de pagina mag geen scripts bevatten, maar zonder
  hint ziet niemand dat er rechts meer staat. Op print vervalt het allemaal en
  wordt de tabel kleiner gezet, zodat alle kolommen op papier alsnog meekomen
- De **initiële schuld** stond wel in de gegevens maar niet op de pagina. Hij
  hoort niet bij een schuldblok, dus zonder eigen regel viel hij buiten de
  export. Staat er nu onder de schuldentabel, met "afgelost sinds start" erbij
- Stortingen op een **verwijderde categorie** blijven in oude voortgangsrijen
  staan, maar de app toont alleen kolommen van bestaande categorieën — die
  bedragen waren dus nergens meer te zien. De export geeft ze alsnog een kolom,
  gemerkt als `Verwijderd (c9)`. Voor een bestand dat alles moet bewaren wat je
  ooit hebt ingevoerd is stil weglaten het verkeerde gedrag

## [1.0.10] - 2026-09-17

### Opgelost
- Het laatste label op de x-as viel over zijn buurman heen (`mei '26` en `26`
  over elkaar). De stap werd vanaf het begin van de reeks geteld en het laatste
  punt werd daar los bovenop geforceerd, zodat het op willekeurige afstand van
  zijn voorganger landde — bij een reeks die niet toevallig op een veelvoud
  uitkwam, pal ernaast. De stap telt nu terug vanaf het laatste punt: dat valt
  daarmee per definitie op een stap en houdt volle tussenruimte, zonder dat er
  nog een uitzondering voor nodig is
- De breedte waarop de grafiek rekent ging van 46 naar 54px per label, zodat er
  lucht tussen staat in plaats van kop-aan-kop. Over reekslengtes van 13 tot 120
  punten blijft de tussenruimte nu minimaal 57px

## [1.0.9] - 2026-09-17

### Gewijzigd
- De x-as van beide grafieken toont korte maandlabels (`sep '26`) in plaats van
  een volledige datum bij elk punt, en ze staan rechtop in plaats van 45 graden
  gedraaid. Tien tekens gedraaid kosten zo'n 45px en er passen er maar een stuk
  of veertien op de tekenbreedte; bij een langere reeks liepen ze door elkaar
  heen tot één grijze band. De grafiek rekent nu uit hoeveel labels er passen en
  toont elke n-de, met het laatste punt er altijd bij — groeit je reeks, dan dunt
  hij vanzelf verder uit
- Doordat de labels niet meer gedraaid zijn is de ruimte eronder kleiner: `pb`
  van 52 naar 30 op het dashboard en van 62 naar 34 op Voortgang. Die hoogte gaat
  naar de lijn zelf
- Nieuwe formatter `fmtMaand` in `utils/format.js`, naast `fmtDatum`
- De lijnen in de Voortgang-grafieken zijn vloeiend, net als op het dashboard.
  Ze werden met `<polyline>` als rechte segmenten getekend; nu met dezelfde
  Catmull-Rom afronding. De gradient eronder is daarmee ook een `<path>` in
  plaats van een `<polygon>`
- `crPath` stond als lokale functie in `DashboardTab.jsx` en is verhuisd naar
  `utils/grafiek.js`, samen met `vlakPad` voor de vulling onder een lijn. Twee
  grafieken die dezelfde curve horen te tekenen moeten niet elk hun eigen kopie
  hebben. In dat bestand staat ook waaróm de inleglijn bewust géén afronding
  krijgt: een spline schiet tussen twee punten iets buiten hun bereik, en bij
  een reeks die nooit terugloopt tekent dat een daling die er niet is

### Opgelost
- De tooltip van de Voortgang-grafiek toonde alleen een bedrag. Nu de x-as geen
  dagen meer noemt was dat de enige plek waar de exacte datum nog te lezen was,
  en die stond er niet in. De tooltip heeft er een datumregel bij

## [1.0.8] - 2026-09-15

### Toegevoegd
- **Kleurthema's.** Negen paletten in `frontend/src/constants/themas.js`, te kiezen
  onder Instellingen naast de dark-mode schakelaar. Thema en licht/donker staan
  los van elkaar: het thema levert het accent, de schakelaar de ondergrond. Dat
  scheelt een compleet tweede palet per thema en laat de bestaande schakelaar
  doen wat hij deed
- `useTheme(themaId, darkMode)` leidt randen, invoervelden en schaduwen af uit
  het accent van het thema, dus die kleuren vanzelf mee. Nieuwe sleutels op `T`:
  `accent`, `accentLicht`, `accentTekst`, `accentGradient`, `chartVan`,
  `chartTot`, `darkMode`, `themaId` en `themaNaam`. De bestaande sleutels houden
  hun naam en betekenis, zodat er niets hoeft te wijzigen dat ze al gebruikt
- Het accent dat tekst draagt is per ondergrond een andere stap van dezelfde
  kleur — de lichte op donker, de donkere op licht. Eén stap voor beide modi
  haalt aan één kant altijd te weinig contrast

### Opgelost
- De weergavevoorkeuren overleven een herlaad. `darkMode` stond op
  `useState(true)` en werd nergens bewaard: zette je de app op licht en laadde je
  opnieuw, dan stond je weer in het donker. Thema en modus gaan nu naar
  localStorage, net als de kolombreedtes. Ze staan los van je financiële data en
  gaan dus niet mee in de backup-ZIP
- `VoortgangTab.jsx` bepaalde de modus met `T.bg === "#0f1117"`. Die kleur is de
  achtergrond allang niet meer (dat is `#241A39`), dus de grafiek gebruikte
  altijd de lichte rasterlijnen — ook in het donker. Leest nu `T.darkMode`, wat
  met instelbare thema's sowieso de enige werkbare manier is
- De kolomkoppen van de categorieën hebben een `title`, net als de
  Opmerkingen-cellen al hadden: bij de standaardbreedte kapt "Crowdfunding" af
- De dark-mode schakelaar in `InstellingenModal.jsx` was een `<div>` met een
  klik-handler en dus niet met het toetsenbord te bedienen. Nu een
  `<button role="switch">` met `aria-checked`

### Gewijzigd
- De accenten door de hele app lopen via het thema. Ongeveer 80 verwijzingen in
  negen bestanden: knoppen, badges, de actieve tab, de doelbalk, de avatar, het
  logo in de navigatiebalk en de gradient van de vermogenslijn in de grafiek.
  `PURPLE` en `PURPLE_LIGHT` werden in vijf bestanden uit `constants/index.js`
  geïmporteerd; die blijven bestaan voor het loginscherm, maar de app leest nu
  `T.accent` en `T.accentTekst`
- De knopstijlen `primaryBtn`, `editBtn` en `addBtn` in `EigenVermogenTab.jsx` en
  `SchuldTab.jsx` zijn functies van `T` geworden, zoals `cancelBtn` al was — een
  object op moduleniveau kan het thema niet volgen
- `VBadge`, `TabBtn` en `VProgressBar` in `components/ui/index.jsx` lezen hun
  standaardkleur uit het thema in plaats van uit een geïmporteerde constante. Wie
  een kleur meegeeft houdt die, dus de categorie- en schuldkleuren blijven staan
- Een paar plekken die in lichte modus nauwelijks werkten, lopen nu ook via het
  thema: de doelbalk had `rgba(255,255,255,0.07)` als achtergrond (onzichtbaar op
  wit) en de tooltips in beide grafieken hadden een vaste donkere vulling

### Bekend
- Het loginscherm blijft bewust op de huisstijl. Daar zit bijna de helft van alle
  paarse accenten (32 van de 70) voor een scherm dat je enkele seconden ziet — en
  bij opslag per account weet je daar nog niet welk thema je moet tonen
- De kleurenkiezer voor schuldblokken (`SchuldTab.jsx`) en de categoriekleuren
  houden hun vaste lijst. Dat is data van de gebruiker, geen thema

## [1.0.7] - 2026-09-11

### Opgelost
- De tooltip van de dashboardgrafiek viel buiten de tekening zodra vermogen en
  inleg ver uit elkaar lagen. Hij werd boven het hoogste punt geplaatst en klapte
  naar onderen als daar geen ruimte was — maar dat "onderen" rekende vanaf het
  laagste punt, en met een kaart van 76px kwam hij dan onder het tekenvlak
  terecht: over de datumlabels heen en half afgekapt. Precies in het midden van
  de grafiek, waar je hem het meest gebruikt. De kaart staat nu náást de
  hoverlijn (links of rechts, afhankelijk van waar de meeste ruimte is) en wordt
  verticaal geklemd binnen het tekenvlak, dus hij past altijd

## [1.0.6] - 2026-09-11

### Toegevoegd
- De grafiek "Ontwikkeling van Eigen Vermogen" op het dashboard heeft een tweede
  lijn: de **cumulatief geïnvesteerde fiat**. Die is opgebouwd uit dezelfde
  gegevens als de KPI's erboven — het oudste voortgangsmoment telt als inleg,
  elke latere rij telt zijn stortingen erbij op — zodat het laatste punt van de
  lijn exact gelijk is aan "Totaal geïnvesteerde fiat". Het verschil tussen de
  twee lijnen is je rendement, en dat staat nu ook in de tooltip: vermogen,
  ingelegd en resultaat per datum
- Legenda boven de grafiek, nodig zodra er meer dan één lijn in staat

### Gewijzigd
- De inleglijn wordt met rechte segmenten getekend en niet met de
  Catmull-Rom-afronding van de vermogenslijn. Cumulatieve inleg loopt nooit
  terug, maar de bezier-afronding trekt tussen twee ongelijke stortingen een
  doorbuiging onder het vorige punt — dan zou de grafiek een daling tonen die
  in de data niet bestaat
- De y-as schaalt op beide reeksen. Op alleen de vermogenswaarden zou de
  inleglijn buiten beeld lopen zodra je meer hebt ingelegd dan het vermogen
  waard is
- De schermentabel in `README.md` beschreef het Dashboard als "totaal eigen
  vermogen, schulden en netto vermogen". Dat klopte niet: `DashboardTab.jsx`
  leest `totSchuld` helemaal niet en toont geen schuld en geen nettowaarde — dat
  staat op het Voortgang-tabblad. De rij noemt nu wat er wél staat (KPI's over
  inleg, vermogen, winst en ROI, de doelbalk en de grafiek), met een alinea
  eronder over de twee lijnen

### Bekend
- De screenshot bovenaan `README.md` is van vóór deze wijziging en toont de
  grafiek nog met één lijn

## [1.0.5] - 2026-09-11

### Gewijzigd
- De documentatie is gelijkgetrokken met de code. `README.md`: de bestandsboom
  miste `backend/src/logger.js`, `docker/check-updates.mjs`,
  `frontend/public/`, `InstellingenModal.jsx`, `LoginBackground.jsx` en de
  losse bestanden in `utils/`, en noemde de update-route `update-check` terwijl
  het bestand `routes/update.js` heet. De schermentabel gebruikt nu de labels
  zoals ze in `constants/index.js` staan ("Schuld", "Voortgang Schuld & EV") en
  vermeldt **Instellingen** — thema plus backup/restore via ZIP, dat nergens in
  de README stond
- De tabel "wat de app met een verzoek doet" (in beide bestanden) noemde alleen
  `/assets/...` en de SPA-fallback. `server.js` kent vier gevallen: `no-store`
  op de API en op HTML, een jaar `immutable` op de gehashte bundels,
  `must-revalidate` op bestanden met een vaste naam (`favicon.svg`, `icons/*`)
  en een echte 404 op een pad mét extensie waar geen bestand achter zit
- `BEHEER.md` beschreef `Bewerker` als "data lezen en bewerken" en `Viewer` als
  "alleen lezen". Zo werkt het niet: `requireAdmin` is de enige rolcontrole in
  de code en bewaakt alleen `/api/users`. Een `Viewer` mag daardoor gewoon zijn
  eigen data schrijven — geen gat in de afscherming, want `/api/data` gaat altijd
  over de rij van het eigen token, maar wél iets anders dan er stond. De sectie
  zegt nu wat de code doet en wat er nodig is voor een echt read-only account
- `README.md` en `BEHEER.md` wijzen bij backup naar het juiste niveau: de ZIP
  onder Instellingen bevat alleen de data van de ingelogde gebruiker, `pg_dump`
  is de volledige servercopie
- `DATABASE_URL` staat in de variabelentabel van `README.md`. Hij wordt door
  `docker-compose.yml` samengesteld uit de `POSTGRES_*` waarden, dus zelf zetten
  is alleen nodig buiten Compose

## [1.0.4] - 2026-09-10

### Gewijzigd
- Git-tags krijgen weer een `v`-prefix (`v1.0.4`), net als t/m `v1.0.0`. Sinds
  1.0.1 was dat `1.0.1`, `1.0.2`, `1.0.3` — en omdat Gitea de tag op de
  release-pagina toont, stond daar het kale nummer terwijl de release-naam wél
  `v1.0.3` was. De image-tags in de registry houden bewust géén `v`; dat is de
  conventie voor container-tags. De update-check verdraagt beide: backend en
  frontend strippen een leidende `v` voordat ze versies vergelijken

### Opgelost
- Het omzetten van de changelog-kop slokte de lege regel eronder op, waardoor
  `## [x.x.x] - datum` direct tegen `### Toegevoegd` aan kwam te staan. Oorzaak
  was `\s*$` in het zoekpatroon: `\s` matcht ook newlines. Het patroon eindigt nu
  op `[ \t]*(?=\r?$)` — een lookahead, want dit bestand heeft CRLF en met alleen
  `[ \t]*$` matchte de kop helemaal niet meer (de `\r` zit ertussen). Zo blijft
  de match binnen één regel én blijft het regeleinde ongemoeid

## [1.0.3] - 2026-09-10

### Toegevoegd
- `release.ps1` zet de changelog-kop `## [Niet vrijgegeven]` nu zelf om naar
  `## [x.x.x] - datum`, net zoals het al deed met `frontend/package.json` en de
  README-badge. Handmatig omzetten hoeft dus niet meer
- Staat er ook na die omzetting niets over deze versie in `Changelog.md`, dan
  breekt het script af **vóór** de build met de melding wat je moet toevoegen.
  Eerder viel het stil terug op de tekst `"Release x.x.x"` en meldde het
  "Gepubliceerd" — dat overkwam 0.1.9 en 1.0.2, en is achteraf alleen met een
  `PATCH` op de release te herstellen. Nieuwe switch `-NoChangelog` om bewust
  zonder release-notes te publiceren
- `release.ps1` zet na een geslaagde release de versie in de root
  `package.json` op `x.x.(x+1)-dev`. Dat was voorheen de laatste handmatige stap
  van de release-workflow. Het staat bewust ná het publiceren, zodat een
  afgebroken release het nummer niet vooruit schuift

### Opgelost
- **`-DryRun` in combinatie met `-Force` verwijderde écht de Git-tag.** De twee
  commando's in stap 4 (`git tag -d` en `git push origin :refs/tags/x.x.x`)
  liepen niet via `Invoke-Cmd` en hadden dus geen droogloop-controle. Gitea
  ruimt de release op zodra de tag verdwijnt, dus een droogloop kon een
  gepubliceerde release wissen — zo is de release van 1.0.2 verloren gegaan en
  opnieuw aangemaakt. Onder `-DryRun` worden beide nu alleen gemeld

### Gewijzigd
- De changelog-controle staat vóór de drie auto-updates, zodat een afgebroken
  release geen gewijzigde bestanden achterlaat terwijl hij "er is niets
  gepubliceerd" meldt
- Stap 5 leest de release-notes uit het geheugen in plaats van opnieuw van
  schijf. Een droogloop schrijft de kop niet, en toonde daardoor de placeholder
  in de payload — precies wat je met een droogloop wilt uitsluiten
- De Quick Start in `README.md` begint nu met het ophalen van
  `docker-compose.yml` (clone, of alleen die twee bestanden via `raw`). Zonder
  dat bestand antwoordt `docker compose pull` met `no configuration file
  provided: not found`, en die stap ontbrak. Beide foutmeldingen staan er nu bij
  met hun oorzaak

## [1.0.2] - 2026-09-10

### Gewijzigd
- De update-melding op het belletje toont alleen nog de kop, de versieregel en de
  link naar de release. De release-notes stonden er als ruwe Markdown in — in een
  kaart van 280px leverde dat zichtbare `### `-koppen en afgekapte regels op.
  `/api/update-check` stuurt `notes` nog wel mee, zodat ze later ergens met meer
  ruimte gebruikt kunnen worden
- `BEHEER.md` legt vast dat de release-link uit Gitea's `ROOT_URL` wordt
  samengesteld en niet per release wordt opgeslagen: na een `ROOT_URL`-wijziging
  plus herstart zijn álle releases in één keer goed, ook de oude. Verder staat er
  nu hoe je aan het verschil tussen `401` en `403` ziet of een token nog leeft, en
  hoe je anoniem over https fetcht als SSH niet meedoet

## [1.0.1] - 2026-09-10

### Toegevoegd
- Kolommen in de tabellen op Eigen Vermogen ("Geïnvesteerde Fiat") en Voortgang
  zijn versleepbaar: pak de rechterrand van een kolomkop. De breedtes gaan per
  tabel naar localStorage, dus ze overleven een tabwissel en een herlaad;
  dubbelklik op de greep zet één kolom terug op zijn standaardbreedte. De logica
  staat in de nieuwe hook `frontend/src/hooks/useKolomBreedtes.js`, de greep zelf
  is `.kolom-grip` in `App.css`

### Gewijzigd
- De `Vibe`-organisatie in Gitea staat op **public**, dus lezen vereist geen
  token meer: `git clone`, `docker compose pull` en de update-check werken
  anoniem. `UPDATE_CHECK_TOKEN` in `.env` is daarmee optioneel — de code
  ondersteunt hem nog als vangnet voor het geval de organisatie weer privé
  wordt. Schrijven verandert niet: `docker push` en het aanmaken van een release
  hebben nog steeds het werkstation-token nodig
- Het tweetoken-model in `BEHEER.md` is teruggebracht tot **één** Gitea-token op
  het werkstation, met `write:package` en `write:repository`. Het host-token is
  niet meer nodig (pull en update-check zijn anoniem), `git push` gaat over SSH,
  en `REGISTRY_TOKEN` hoeft niet apart: `release.ps1` en `dev.ps1` vielen daar al
  terug op `GITEA_TOKEN`. Geen code-wijziging, alleen minder te beheren
- De tabellen op Eigen Vermogen en Voortgang staan op `table-layout: fixed`,
  nodig om ingestelde kolombreedtes te respecteren. Gevolg: lange tekst rekt een
  kolom niet meer op maar wordt afgekapt met een ellips. De Opmerkingen-cellen
  hebben een `title`, dus hover geeft de volledige tekst
- Het label bij een beschikbare update in "Over VibeFinance" is "Nieuwe versie"
  (was "Nieuwste versie" in 1.0.0)

### Opgelost
- De sticky kolomkop van die tabellen was in dark mode maar 30% dekkend: hij
  gebruikte `T.card` (`rgba(22,23,27,0.30)`), waardoor de rijen tijdens het
  scrollen zichtbaar door de koptekst heen liepen. Nu `T.popupBg`, de
  ondoorzichtige variant die al in het thema stond
- In dev bakte Vite de versie uit `frontend/package.json` in in plaats van de
  versie uit de root `package.json`. `VITE_APP_VERSION` kwam alleen als
  build-arg mee, maar de `development`-stage in de `Dockerfile` declareert die
  `ARG` niet — en Vite bakt de constante in bij het *starten* van de dev-server,
  niet bij het bouwen van het image. De variabele staat nu in de
  runtime-omgeving van de dev-container; `vite.config.js` valt met `||` (was
  `??`) terug op `package.json` als hij leeg is
- API-antwoorden sturen nu `Cache-Control: no-store`. Ze hadden alleen een
  `ETag` en geen cache-beleid, waardoor de browser zelf mocht bepalen hoe lang
  hij ze hergebruikte — per browser en profiel verschillend. Gevolg: de
  update-melding bleef in Brave op een oud antwoord hangen (nog van vóór het
  werkende token) terwijl een verse Edge het goede kreeg

## [1.0.0] - 2026-09-09

### Gewijzigd
- `BEHEER.md` heeft één centrale `## Tokens`-sectie met het tweetoken-model
  (werkstation `write:*`, Docker-host `read:*`) plus de betekenis van een 401,
  403 en 404 van Gitea; de Registry-, pull- en update-secties verwijzen daarnaar
  in plaats van de scopes elk apart uit te leggen
- `.env.example` noemt bij `UPDATE_CHECK_TOKEN` de vereiste scope
  (`read:repository`) en wat je ziet als die ontbreekt
- "Over VibeFinance" noemt de beschikbare update nu "Nieuwste versie" in plaats
  van "Nieuw beschikbaar"
- `README.md` bijgewerkt: de Quick Start noemt de `docker login` die een pull uit
  de privé-registry vereist (die stap ontbrak), de release-sectie verwijst naar
  `.env.release` en `write:repository`, en `UPDATE_CHECK_TOKEN` noemt zijn scope
- `release.ps1` werkt de versiebadge in `README.md` bij, net als de versie in
  `frontend/package.json` — die badge stond drie releases achter. Een `-DryRun`
  meldt de wijziging en schrijft niet
- `README.md` heeft ruimte voor een screenshot onder de badges
  (`docs/screenshot-dashboard.png`); `docs/` staat in `.dockerignore` en `.png`
  en `.jpg` zijn in `.gitattributes` als binair vastgelegd
- Badges `React_18` → `React_19` (de app draait op React 19.2)
- `BEHEER.md` legt bij de release-workflow vast wat het script zelf bijwerkt
  (`frontend/package.json` en de README-badge), en dat de changelog-kop exact
  `## [x.x.x]` moet zijn — anders vallen de release-notes terug op
  `"Release x.x.x"`, zoals bij 0.1.9 gebeurde
- Projectboom in `README.md` bevat `docs/` en `frontend/src/version.js`

## [0.1.9] - 2026-09-09

### Gewijzigd
- `release.ps1` leest een `.env.release` naast het script in (niet in git), zodat
  `GITEA_TOKEN` en de registry-credentials niet elke shell opnieuw gezet hoeven
  te worden; een variabele die al in de omgeving staat wint, en alleen de namen
  worden gelogd
- `.gitignore` negeert nu alle `.env.*` op `.env.example` na — `.env.release`
  zou anders door een `git add .` in git belanden
- `BEHEER.md` beschrijft welke token-scopes waarvoor nodig zijn
  (`write:package` voor de registry, `write:repository` voor een release) en
  hoe je een 404 in stap 5 nakijkt
- De draaiende versie komt uit de build in plaats van uit een bestand: de
  frontend leest `__APP_VERSION__` via het nieuwe `src/version.js`, niet meer
  rechtstreeks uit `frontend/package.json`. `vite.config.js` definieerde die
  constante al, maar niets gebruikte hem — een productie-image gebouwd terwijl
  er een `-dev` in `package.json` stond, sloeg de update-check stil helemaal
  over

## [0.1.8] - 2026-09-09

### Gewijzigd
- `BEHEER.md` beschrijft de registry-login die een deploy-machine nodig heeft om
  te kunnen pullen: het package is privé, dus ook `docker compose pull` vraagt
  een token (`read:package`) — anoniem geeft de registry `401 Unauthorized`
- Testsuite dekt nu het serveren van de favicon, de cache-headers daarop en de
  404 op ontbrekende bestanden
- `release.ps1 -DryRun` schrijft de frontend-versie niet meer echt weg: een
  droogloop meldde de sync wél en voerde hem óók uit, waardoor er na een
  `-DryRun` een gewijzigde `frontend/package.json` bleef liggen

### Opgelost
- De favicon bleef weg in de browser: `favicon.svg` en `icons/*` hebben geen
  hash in hun naam, maar kregen wel een jaar `immutable` mee — een eenmaal
  verkeerd gecacht antwoord revalideerde daardoor nooit meer. Alleen de
  gehashte bundels in `/assets` houden die cache; de rest revalideert
- `/favicon.ico` en `/apple-touch-icon.png` gaven via de SPA-fallback
  `index.html` terug met status 200 en `text/html` — de browser kreeg HTML waar
  hij een icoon verwachtte en toonde stil niets, zonder zichtbare fout. Paden
  met een bestandsextensie geven nu een echte 404

## [0.1.7] - 2026-09-08

### Gewijzigd
- Versienummer opgehoogd naar 0.1.7
- Eerste release vanaf de opnieuw aangemaakte Gitea-repository, met `main`
  als hoofdbranch

## [0.1.6] - 2026-09-04

### Gewijzigd
- **Migratie naar 2 containers**: de Express-app serveert nu zelf de gebouwde
  frontend op `/` (met SPA-fallback naar `index.html`); de aparte nginx-container
  is vervallen. Eén image, één origin, geen interne proxy — bedoeld voor
  self-hosting op een Raspberry Pi
- Nieuwe multi-stage `Dockerfile` in de root met targets `test`, `development`
  en `production`; `frontend/Dockerfile`, `frontend/nginx-spa.conf` en
  `backend/Dockerfile` zijn verwijderd
- `docker-compose.yml` bevat alleen nog `app` en `postgres`; de app publiceert
  `APP_PORT` (standaard 3400) naar containerpoort 3001
- Dev-stack draait beide processen in één container (`docker/dev-entrypoint.sh`):
  API met `node --watch` en de Vite dev-server met hot reload
- Rate limiting geldt alleen nog voor `/api` — statische bestanden werden anders
  na 200 requests geblokkeerd
- Content-Security-Policy via Helmet toegespitst op wat de frontend laadt
  (Google Fonts, inline styles, base64-avatars)
- Assets met hash worden een jaar `immutable` gecached, `index.html` nooit
- Schema-initialisatie zit nu in `initDb()` in plaats van bij het importeren van
  `db.js`, zodat de app zonder database te importeren is (tests)
- `dev.ps1`, `release.ps1` en de shell-wrappers werken met één app-image;
  `dev.ps1 up` wist de dev-database niet langer (alleen `dev.ps1 down`)
- `release.ps1` draait de testsuite vóór het publiceren en bouwt voor
  `linux/amd64` + `linux/arm64`
- Dependencies naar de nieuwste versies: React 19.2, Vite 8.2,
  @vitejs/plugin-react 6.1, Express 5.2, Helmet 8.3, express-rate-limit 8.7,
  pino 10.3 / pino-http 11, pg 8.23, dotenv 17.4, bcryptjs 3.0, ESLint 9.39
  (frontend) / 10.9 (backend)
- Express 5 vereist benoemde wildcards in routes; `app.use("/api/*")` en
  `app.get("*")` vervangen door een prefix-mount en pad-loze middleware
- `dev.ps1 up` gebruikt `--renew-anon-volumes`, anders blijven de oude
  `node_modules` in de dev-container staan na een upgrade
- Vite 8 bundelt met Rolldown: `manualChunks` (object-vorm) vervangen door
  `build.rollupOptions.output.advancedChunks`
- `release.ps1` controleert vóór de build of origin bereikbaar is en of je op de
  registry bent ingelogd, in plaats van pas na een multi-arch build te stranden
  op `401 Unauthorized`. Logt zelf in met `REGISTRY_USER` + `REGISTRY_TOKEN`
  wanneer die gezet zijn; `dev.ps1 push` doet dezelfde controle
- Git-commando's in `release.ps1` draaien met `BatchMode=yes`, zodat het script
  niet blijft hangen op een wachtwoordprompt van SSH
- `release.ps1`, `dev.ps1` en `test.ps1` eindigen expliciet met exitcode 0, en de
  slotregel van een `-DryRun` zegt nu dat er niets is gepubliceerd
- Mislukte stappen in `release.ps1` geven geen PowerShell-stacktrace meer maar
  een gerichte melding: bij een mislukte push wordt de registry-login opnieuw
  getest en volgt de bijbehorende instructie, bij een mislukte tag-push het
  https-alternatief

### Toegevoegd
- Testsuite: `backend/test/app.test.js` (11 tests met `node --test`) voor de
  API-routes, SPA-fallback, cache-headers en security-headers
- `test.ps1` / `test.sh`: backend-tests, productiebuild en smoketest op de
  echte 2-container stack
- `.env.example`, `.dockerignore` en `.gitignore`
- `STATIC_DIR` als omgevingsvariabele (map met de frontend-build)
- Dependency-check als eerste stap van de testsuite: `docker/check-updates.mjs`
  vergelijkt beide `package.json`'s met het npm-register, met bewuste
  uitzonderingen in `docker/update-exceptions.json` (`-Strict` om te falen,
  `-SkipDeps` om over te slaan)
- ESLint flat configs (`frontend/eslint.config.js`, `backend/eslint.config.js`) —
  `npm run lint` werkte voorheen niet, er was geen configuratie
- Lockfiles voor beide packages (`backend/package-lock.json` was er niet)
- `.gitattributes`: shell-scripts en Docker-bestanden altijd met LF, anders
  faalt het shebang in de container

---

## [0.1.5] - 2026-09-04

### Toegevoegd
- Donut-grafieken: hover per categorie toont naam, bedrag en percentage

### Gewijzigd
- Update-check loopt nu via de eigen backend (`/api/update-check`) in plaats van
  rechtstreeks naar de Gitea API — de browser blokkeerde die call (geen CORS-headers)
- Versievergelijking is semver-based: alleen een hoger versienummer meldt, `-dev`
  builds melden niets meer
- Update-check herhaalt zich elk half uur en bij terugkeer naar het tabblad
  (was: eenmalig bij laden)
- `release.ps1` maakt de Gitea-release aan met de changelog-sectie als release-notes
  (een kale Git-tag komt niet in `releases/latest` en gaf dus geen melding)
- Middenwaarde in de donut schaalt mee met de beschikbare ruimte

### Opgelost
- Donkere spleten tussen de donut-segmenten (de tussenruimte liet de achtergrondbaan zien)
- De update-melding op het belletje bleef altijd leeg door de geblokkeerde API-call

---

## [0.1.3] - 2026-04-16

### Toegevoegd
- Versienummer met logo zichtbaar boven de logout-knop in de sidebar

### Gewijzigd
- Registry verplaatst van intern IP (`10.0.3.108:3000`) naar publieke DuckDNS-hostnaam (`vibehoogie.duckdns.org`) — toegankelijk via Nginx Proxy Manager
- PostgreSQL productie geüpgraded van versie 16 naar 18 (volume mount aangepast naar `/var/lib/postgresql`)
- Witte rand rondom de app verwijderd (globale CSS reset toegevoegd, `App.css` gekoppeld aan `App.jsx`)

### Opgelost
- Login gaf "Kan geen verbinding maken met de server": `nginx-spa.conf` miste een `/api/` proxy-blok naar de backend-container — alle API-calls kwamen niet aan

---

## [0.0.4] - 2026-04-08

### Toegevoegd
- _Nog in ontwikkeling_

---

## [0.0.3] - 2026-04-08

### Toegevoegd
- Gebruikersbeheer haalt accounts op uit de backend API (was: localStorage)
- Gebruikers bewerken: naam, e-mailadres en wachtwoord aanpassen via ✏️ knop
- Nieuwe gebruiker aanmaken vereist nu ook een wachtwoord
- Eerste geregistreerde gebruiker krijgt automatisch de Admin-rol
- `aangemaakt` kolom toegevoegd aan de `users` tabel (zichtbaar in gebruikersbeheer)
- Custom dropdown component voor rolselectie (past donker thema)
- Voortgang overzicht gebruikt eigen `evVoortgangHistory` — los van geïnvesteerde fiat

### Opgelost
- Data ging verloren na container restart: PostgreSQL 18 gebruikt een ander `PGDATA` pad (`/var/lib/postgresql/18/docker`). Volume nu gemount op `/var/lib/postgresql`
- Geïnvesteerde fiat invullen vulde automatisch ook het voortgangsoverzicht in

---

## [0.0.2] - 2026-04-01

### Toegevoegd
- PostgreSQL als persistente database (vervangt in-memory opslag)
- JWT authenticatie met instelbare vervaltijd
- Backup en restore via ZIP-bestand
- Rate limiting op auth-endpoints
- Helmet security headers
- Docker multi-stage builds (dev / productie)
- Dev script (`dev.ps1` / `dev.sh`) voor bouwen, starten en pushen

### Gewijzigd
- Gebruikersdata per account opgeslagen (niet meer gedeeld)

---

## [0.0.1] - 2026-03-01

### Toegevoegd
- Initiële release van VibeFinance
- Dashboard met overzicht van eigen vermogen, schulden en netto vermogen
- Eigen vermogen beheer met categorieën en historiek
- Schulden beheer met blokken en afbetalingsoverzicht
- Voortgangspagina met grafieken (EV en schuld over tijd)
- Gebruikersbeheer en authenticatie
- Dark mode ondersteuning