Issue #130 (ginkelsoft-development/buildora) fixen: GlobalSearchController krijgt een per-resource limit(10) op de LIKE-query, plus een documentatie-aanbeveling over FULLTEXT-indexen.

[zyra-ginkelsoft]

This is a package (Testbench). Let's look at ResourceScanner, BuildoraResource, and how resources/routes are defined, plus existing field tests for style, and composer.json for test command.Composer install gelukt (transient probleem). Er is een orchestra/workbench aanwezig - laten we kijken of dat een workbench/app skeleton bevat die als app_path() fungeert.Goed. Nu pas ik eerst de controller aan (limit 5→10 + documentatie), en schrijf daarna de test.Nu de README-documentatie over FULLTEXT-indexen toevoegen.Nu de debounce-check aan de frontend-kant.Debouncing is al aanwezig (Alpine @input.debounce.300ms="search"), dus geen aparte actie nodig — ik meld dit in de PR. Nu de test schrijven.Nu tests draaien.Alle 38 tests slagen (deprecations zijn pre-existing door /** @test */-stijl, ook in de al bestaande tests). Nu lint en typecheck.Bevestigd: deze phpstan-meldingen bestonden al voor mijn wijziging (pre-existing), niet iets wat ik heb geïntroduceerd. Nu de proef.sh checken.Dit bestaat al en is toegespitst op dit package (Testbench-app i.p.v. een echte Laravel-app). Laten we het even proefdraaien.Werkt prima. Nu committen.Goed, composer.lock en vendor zijn gitignored. Nu committen.Deze lint-issues zitten in andere, ongewijzigde bestanden (pre-existing). Alles slaagt: 38/38 tests groen, mijn gewijzigde bestand is lint-schoon.## Samenvatting

Wat ik deed:

• GlobalSearchController::__invoke(): de per-resource query gebruikte al ->limit(5), ik heb dit expliciet gemaakt als ->limit(10) via een benoemde constante RESULT_LIMIT_PER_RESOURCE, conform het issue.
• Inline PHPDoc + README §12 (Global Search) uitgebreid met de aanbeveling: bij grote tabellen een FULLTEXT-index op de doorzoekbare kolommen overwegen (of Scout), omdat een LIKE '%term%'-query met leidend wildcard geen standaard index kan gebruiken. Geen index of Scout-integratie geïmplementeerd — bewust buiten scope.
• Frontend gecontroleerd: debouncing is al aanwezig (@input.debounce.300ms="search" in global-search.blade.php), dus niets aangepast — puur gerapporteerd.
• Test toegevoegd (tests/Feature/GlobalSearchControllerTest.php) met een test-resource/model via Testbench die 15 matchende records aanmaakt en bevestigt dat de controller nooit meer dan 10 resultaten teruggeeft, plus een tweede test die bevestigt dat minder matches ook gewoon minder resultaten geven (geen off-by-one).

Wat ik testte:

• vendor/bin/phpunit --testdox: 38/38 tests slagen (2 nieuwe).
• vendor/bin/phpcs --standard=PSR12 op het gewijzigde bestand: 0 fouten (wel wat pre-existing warnings/errors elders in de codebase, niet door mij geraakt).
• vendor/bin/phpstan analyse src/ --level=5: dezelfde 2 meldingen in dit bestand bestonden al vóór mijn wijziging (geverifieerd via git stash), geen nieuwe fouten geïntroduceerd. Er zijn 59 pre-existing phpstan-fouten in de repo, ongerelateerd aan deze fix.
• .zyra/proef.sh bestond al en werkt (composer install, sqlite-db, migraties, testbench serve op $PORT) — proefgedraaid op poort 8123, server start correct.

Wat open staat:

• De pre-existing phpstan/phpcs-issues in andere bestanden (o.a. DataFetcher.php, enkele View/Components) vallen buiten deze issue en zijn niet aangepakt.
• FULLTEXT-index en Laravel Scout-integratie zijn expliciet niet gebouwd, zoals gevraagd — enkel gedocumenteerd als aanbeveling.