Ontwerp opleveren voor issue #123 (buildora): een record-level authorization hook toevoegen aan BuildoraResource zodat IDOR (elke user met resource-permission kan elk record zien) wordt voorkomen.

[zyra-ginkelsoft]

Goed, proef.sh bestaat al en past correct bij dit package (geen host-app, Testbench-gebaseerd). Ik test of het nog werkt.Zoals proef.sh al zelf afvangt — normale install faalt op ext-gd, met fallback. Dat is verwacht gedrag; laat proef.sh dat zelf oplossen.Composer install lukt met de fallback. Nu de rest van proef.sh: sqlite db + migraties.proef.sh werkt nog steeds prima. Nu server kort testen op een poort en daarna stoppen.proef.sh functioneert. Nu de bestaande unittests draaien om baseline te checken, en verder de relevante bestanden verkennen (Datatable/QueryFactory verwezen in taak zit blijkbaar in src/Resources, niet src/Datatable — laat me checken of er ook een src/Support/BuildoraResource.php of src/Datatable/QueryFactory.php bestaat zoals de taak zegt).Nu schrijf ik het ontwerpdocument als reactie op issue #123, volgens het bestaande patroon in .zyra/.Nu proef.sh nog even end-to-end bevestigen (was al gedaan), en dan committen..zyra/proef.sh bestond al en werkte, dus geen wijziging nodig daar — alleen het nieuwe ontwerpdocument toevoegen.## Samenvatting

Wat ik deed: onderzocht waar de IDOR daadwerkelijk zit (BuildoraController::show() loopt via QueryFactory, maar edit()/update()/destroy() bypassen die volledig met een rechtstreekse getModelInstance()->findOrFail(); DataFetcher en ExportManager lopen wél via QueryFactory). Op basis daarvan een ontwerp gemaakt met twee onafhankelijke, backwards-compatible hooks:

• scopeQuery(Builder $query): Builder (default no-op) — toegepast in QueryFactory::make(), plus een nieuwe newScopedQuery()-helper op BuildoraResource zodat ook edit()/update()/destroy() (die nu buiten QueryFactory om gaan) mee-filteren. Ontoegankelijke records → 404.
• policy(): ?string (default null) — nieuwe authorizeRecord()-helper in BuildoraController die Gate::authorize() aanroept in show()/edit()/update()/destroy(). Ontoegankelijke records → 403.

Beide zijn los of samen te gebruiken; backwards compatibility is expliciet geborgd (default no-op = huidig gedrag, letterlijk aangetoond). Testscenario (regressie + scopeQuery + policy, voor show/edit/update/destroy) en het CLAUDE.md-documentatievoorbeeld zijn uitgeschreven. Ook een bewust buiten scope gelaten kanttekening genoemd (RelationDatatableController heeft hetzelfde patroon voor het parent-record, apart issue voorstellen).

Er is geen productiecode aangepast — dit is een ontwerptaak. Het volledige ontwerp staat in .zyra/issue-123-comment.md, klaar om als reactie op issue #123 geplaatst te worden (ik heb zelf geen GitHub-toegang in deze werkplaats, net als bij eerdere taken hier).

Wat ik testte: .zyra/proef.sh bestond al en past bij dit package (geen host-app, Orchestra Testbench) — ik heb 'm end-to-end doorlopen: composer install (met de al aanwezige ext-gd-fallback), sqlite-db aanmaken, migraties draaien, en kort de server op een testport gestart — alles werkt ongewijzigd. Ook vendor/bin/phpunit gedraaid (36/36 groen) als baseline, zowel voor als na het toevoegen van het ontwerpdocument (dat geen code raakt).

Wat nog open staat: dit is puur het ontwerp; de bouwtaak (implementatie van scopeQuery()/newScopedQuery()/policy() in BuildoraResource.php, QueryFactory.php en BuildoraController.php, plus de nieuwe testklasse en CLAUDE.md-update) moet nog gedaan worden door een volgende agent. Iemand met GitHub-toegang moet de tekst uit .zyra/issue-123-comment.md nog als comment op issue #123 plaatsen.