docs+test(privacy): trek het dubbele ontwerp in en bewaak de faalrichting (#651) #739

Merged

brenno merged 2 commits from feat/privacy-terzijdelegging-651 into main

2026-07-23 12:34:44 +00:00

brenno commented

2026-07-23 12:34:33 +00:00

Owner

Het meeste van wat ik voor #651 bouwde was duplicaatwerk — een parallelle sessie bouwde tegelijk hetzelfde. Wat hier overblijft is wat wél iets toevoegt; de rest heb ik laten vallen.

Het dubbele ontwerp ingetrokken

Twee sessies schreven parallel een ontwerp voor deze functie. Het hunne (FILE_FORMAT §6.7, PR #732) landde eerst; het mijne (docs/design/PRIVACY_DISMISSALS.md, PR #734) merge er schoon bovenop omdat git alleen een nieuw bestand zag — de botsing was semantisch en dus onzichtbaar. Twee ontwerpen voor één bestandsformaat is erger dan geen ontwerp, dus het mijne gaat eruit, mét zijn registratie en zijn 31 vertaalsleutels.

Hun redenering verslaat de mijne op het punt dat ertoe doet. Ik schreef dat het commitment de waarde beschermt. Dat is niet waar tegen iemand die het deck heeft — die leest de dia gewoon. Hun tekst zegt dat met zoveel woorden en geeft de twee eerlijke redenen: geen tweede kopie van een persoonsgegeven met een eigen levensduur, en een zout per deck tegen kruisverbanden tussen decks.

Twee dingen die alleen in mijn versie stonden gaan mee naar §6.7:

OQ-1, door de beheerder bevestigd: een terzijdelegging verloopt níét bij een wijziging van de regel, met de reden erbij zodat de andere kant niet opnieuw wordt voorgesteld.
De exportpoort als open vraag. "Verborgen in het paneel" en "niet opgelost" waren al beslist; wat de póórt met een terzijdelegging doet niet. Beide kanten hebben een prijs — als onopgelost tellen levert een permanent geblokkeerde export op waarvan de enige uitweg de globale schakelaar is, precies wat deze functie vervangt; als opgelost tellen meldt de poort een schoonheid die de nalevingsteller met opzet weigert te melden. Staat er nu als besluit-in-afwachting in plaats van als aanname.

Eén toets die er nog niet was

De vijf bestaande toetsen dekken wat er moet gebeuren. Deze dekt wat er niet mag gebeuren: matchedTextOf geeft null zodra het fragment weg is of korter werd dan de opgeslagen positie. Gaf het in plaats daarvan een afgekapt stuk tekst terug, dan hasht dat ooit toevallig naar een terzijdelegging en verbergt de app iets wat niemand heeft bekeken.

Rechtstreeks getoetst en niet via het paneel: dáár lopen de scan en het deck altijd gelijk op, dus die tak komt er nooit langs en een toets erop zou niets bewijzen. Nagelopen dát hij vangt — met de begrenzing vervangen door een clamp valt hij om.

Wat ik heb weggegooid, en waarom het hier staat

Een eigen withoutDismissed met een gememoiseerde tekstkaart per dia. Die is weg omdat hun matchedTextOf er al is en werkt. Het enige verschil dat overblijft is prestatie: hun versie bouwt de fragmentenlijst van een dia opnieuw op per bevinding, de mijne één keer per dia. Op een dia met veel treffers is dat kwadratisch werk in een pad dat bij élke deckwijziging draait. Ik heb dat níét gemeten, dus ik dien het niet in als verbetering — het is een aanwijzing voor wie er ooit met de prestatiebril naar kijkt.

Poort: make check groen.

Refs #651

**Het meeste van wat ik voor #651 bouwde was duplicaatwerk** — een parallelle sessie bouwde tegelijk hetzelfde. Wat hier overblijft is wat wél iets toevoegt; de rest heb ik laten vallen. ## Het dubbele ontwerp ingetrokken Twee sessies schreven parallel een ontwerp voor deze functie. Het hunne (FILE_FORMAT §6.7, PR #732) landde eerst; het mijne (`docs/design/PRIVACY_DISMISSALS.md`, PR #734) merge er schoon bovenop omdat git alleen een nieuw bestand zag — de botsing was semantisch en dus onzichtbaar. Twee ontwerpen voor één bestandsformaat is erger dan geen ontwerp, dus het mijne gaat eruit, mét zijn registratie en zijn 31 vertaalsleutels. **Hun redenering verslaat de mijne op het punt dat ertoe doet.** Ik schreef dat het commitment de waarde beschermt. Dat is niet waar tegen iemand die het deck heeft — die leest de dia gewoon. Hun tekst zegt dat met zoveel woorden en geeft de twee eerlijke redenen: geen tweede kopie van een persoonsgegeven met een eigen levensduur, en een zout per deck tegen kruisverbanden tussen decks. Twee dingen die alleen in mijn versie stonden gaan mee naar §6.7: - **OQ-1, door de beheerder bevestigd:** een terzijdelegging verloopt níét bij een wijziging van de regel, met de reden erbij zodat de andere kant niet opnieuw wordt voorgesteld. - **De exportpoort als open vraag.** "Verborgen in het paneel" en "niet opgelost" waren al beslist; wat de póórt met een terzijdelegging doet niet. Beide kanten hebben een prijs — als onopgelost tellen levert een permanent geblokkeerde export op waarvan de enige uitweg de globale schakelaar is, precies wat deze functie vervangt; als opgelost tellen meldt de poort een schoonheid die de nalevingsteller met opzet weigert te melden. Staat er nu als besluit-in-afwachting in plaats van als aanname. ## Eén toets die er nog niet was De vijf bestaande toetsen dekken wat er moet gebeuren. Deze dekt wat er **niet** mag gebeuren: `matchedTextOf` geeft null zodra het fragment weg is of korter werd dan de opgeslagen positie. Gaf het in plaats daarvan een afgekapt stuk tekst terug, dan hasht dat ooit toevallig naar een terzijdelegging en verbergt de app iets wat niemand heeft bekeken. Rechtstreeks getoetst en niet via het paneel: dáár lopen de scan en het deck altijd gelijk op, dus die tak komt er nooit langs en een toets erop zou niets bewijzen. Nagelopen dát hij vangt — met de begrenzing vervangen door een clamp valt hij om. ## Wat ik heb weggegooid, en waarom het hier staat Een eigen `withoutDismissed` met een gememoiseerde tekstkaart per dia. Die is weg omdat hun `matchedTextOf` er al is en werkt. Het enige verschil dat overblijft is prestatie: hun versie bouwt de fragmentenlijst van een dia opnieuw op per bevinding, de mijne één keer per dia. Op een dia met veel treffers is dat kwadratisch werk in een pad dat bij élke deckwijziging draait. Ik heb dat níét gemeten, dus ik dien het niet in als verbetering — het is een aanwijzing voor wie er ooit met de prestatiebril naar kijkt. Poort: `make check` groen. Refs #651

brenno added 2 commits

2026-07-23 12:34:33 +00:00

docs: trek het dubbele ontwerp voor #651 in, vouw op wat het toevoegde 7d3c3db3aa

Twee sessies schreven parallel een ontwerp voor dezelfde functie. Het hunne
(FILE_FORMAT §6.7, PR #732) landde eerst en is bovendien beter beredeneerd op de
punten waar we verschilden; het mijne (docs/design/PRIVACY_DISMISSALS.md, PR
#734) merge er schoon bovenop omdat git alleen een nieuw bestand zag. Twee
ontwerpen voor één bestandsformaat is erger dan geen ontwerp, dus het mijne
gaat eruit — mét zijn registratie en zijn 31 vertaalsleutels, want een sleutel
die nergens meer heen wijst is schuld die geen poort ziet.

Waar hun redenering de mijne verslaat, en dat is het onthouden waard: ik
schreef dat het commitment de waarde beschermt. Dat is niet waar tegen iemand
die het deck heeft — die leest de dia gewoon. Hun tekst zegt dat met zoveel
woorden en geeft de twee eerlijke redenen: geen tweede kopie van een
persoonsgegeven met een eigen levensduur, en een zout per deck tegen
kruisverbanden. Dat is scherper dan wat ik had.

Twee dingen die alleen in mijn versie stonden gaan mee naar §6.7:

- OQ-1, door de beheerder bevestigd: een terzijdelegging verloopt níét bij een
  wijziging van de regel, met de reden erbij zodat de andere kant niet opnieuw
  wordt voorgesteld;
- de exportpoort. "Verborgen in het paneel" en "niet opgelost" waren al
  beslist, maar wat de poort met een terzijdelegging doet niet — en dat is een
  echte splitsing, want beide kanten hebben een prijs. Staat er nu als open
  vraag in plaats van als aanname.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

test(privacy): bewaak de veilige faalrichting van matchedTextOf (#651 ) 69d9645d85

De vijf bestaande toetsen dekken wat er moet gebeuren; deze dekt wat er níét
mag gebeuren. `matchedTextOf` geeft null zodra het fragment weg is of korter
werd dan de opgeslagen positie — de dia is dan bewerkt sinds de scan. Gaf het
in plaats daarvan een afgekapt stuk tekst terug, dan hasht dat ooit toevallig
naar een terzijdelegging en verbergt de app iets wat niemand heeft bekeken.

Rechtstreeks getoetst en niet via het paneel: dáár lopen de scan en het deck
altijd gelijk op, dus die tak komt er nooit langs en een toets erop zou niets
bewijzen.

Nagelopen dat hij werkelijk vangt: met de begrenzing vervangen door een clamp
valt de toets om, met de begrenzing terug staat hij weer groen.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

brenno merged commit 71397ddcc1 into main

2026-07-23 12:34:44 +00:00

brenno referenced this pull request from a commit

2026-07-23 12:34:45 +00:00

Merge pull request 'docs+test(privacy): trek het dubbele ontwerp in en bewaak de faalrichting (#651)' (#739) from feat/privacy-terzijdelegging-651 into main

brenno referenced this pull request

2026-07-23 12:35:15 +00:00

[Feature] Dismiss a single privacy finding, not just the whole rule #651

brenno referenced this pull request

2026-07-23 22:10:33 +00:00

[Feature] Dismiss a single privacy finding, not just the whole rule #651