webmanager-mvp/project_docs/FOLDER_UPLOAD_V1_DESIGN.md

Folder Upload v1 Design

1. Doel

Folder upload voegt waarde toe omdat de huidige uploadflow al bruikbaar is voor losse bestanden en batches, maar niet voor veelvoorkomende workflows waarbij een gebruiker een complete lokale mapstructuur naar de storage wil kopieren. Dat past logisch binnen de bestaande dual-pane workflow: het actieve paneel bepaalt al de doelmap, en upload is al een expliciete actie in de functiebalk.

De kern van v1 is niet "een nieuwe uploadarchitectuur", maar een gecontroleerde uitbreiding van de bestaande uploadflow zodat een lokale map recursief kan worden ingestuurd naar currentPath van het actieve paneel.

2. Scope

Folder Upload v1 ondersteunt expliciet:

• selectie van precies een lokale map via de browser
• recursieve upload van de inhoud van die map
• behoud van directorystructuur onder het gekozen doelpad
• target = currentPath van het actieve paneel
• hergebruik van de bestaande sequentiele uploadflow en bestaande conflictopties

Niet in scope voor v1:

• meerdere lokale mappen tegelijk
• drag & drop
• resumable upload
• chunked upload
• taskmodel-integratie
• rollback
• backendherontwerp buiten wat strikt nodig is om directorystructuur veilig te ondersteunen

Aanbevolen v1-scope met laag regressierisico:

• precies 1 geselecteerde lokale map
• recursieve upload van alle files daaronder
• directorystructuur behouden
• conflictbehandeling alleen op bestandsniveau via bestaande keuzes

3. Browserselectie

Browsermatig is folderselectie geen aparte native "map upload API" zoals bij desktop-apps, maar een file input met directory-selectie-attributen zoals webkitdirectory. In de praktijk levert dit een lijst bestanden op met relatieve paden binnen de gekozen map.

Dit past redelijk goed bij de bestaande native file picker flow:

• huidige uploadknop opent al een browser file picker
• voor folder upload kan een aparte, kleine flow dezelfde picker gebruiken, maar dan in directory-selectiemodus
• drag & drop is niet nodig voor v1

Aanbeveling:

• v1 gebruikt browser-native directory picker via input-attributen
• geen drag & drop
• geen extra dependency

4. Doelstructuur

De veiligste en meest voorspelbare semantiek voor v1 is:

• de geselecteerde mapnaam zelf wordt meegenomen in de doelstructuur
• dus upload van lokale map Photos/ naar target /Volumes/8TB/Uploads resulteert in:
  • /Volumes/8TB/Uploads/Photos/...

Dit voorkomt ambiguiteit en sluit aan op gebruikersverwachting uit file managers.

Relatieve paden:

• browser levert per bestand een relatief pad onder de gekozen rootmap
• frontend mag dat relatieve pad gebruiken als beschrijving van directorystructuur
• backend mag die structuur nooit blind vertrouwen zonder per segment validatie

Aanbevolen semantiek:

• geselecteerde mapnaam opnemen
• directorystructuur daaronder behouden
• alle relatieve padsegmenten strikt normaliseren en valideren

5. Conflictgedrag

Conflictgedrag moet in v1 voortbouwen op de bestaande uploadconflictflow.

Bestandsconflicten

Bij een bestaand doelbestand:

• Overwrite: huidig bestand overschrijven
• Overwrite all: huidige en volgende bestandsconflicten overschrijven
• Skip: huidig bestand overslaan
• Skip all: huidige en volgende bestandsconflicten overslaan
• Cancel: resterende upload stoppen

Directoryconflicten

Directoryconflict is subtieler. Als de doelmap al bestaat en ook een directory is, hoeft dat in v1 geen fout te zijn. Dat is juist het normale mechanisme om inhoud in een bestaande mapstructuur te laten landen.

Aanbevolen v1-regel:

• bestaande doel-directory: toegestaan, geen conflictmodal
• bestaande doel-directory fungeert als containermap voor verdere recursie

Typeconflicten

Als een padsegment een typeconflict veroorzaakt, bijvoorbeeld:

• lokale structuur verwacht een directory
• maar op bestemming bestaat daar een file

Dan moet dit als conflict/failure behandeld worden. De bestaande conflictknoppen kunnen dan alleen zinnig worden toegepast als overschrijven echt veilig definieerbaar is. Voor v1 is dat te riskant op directoryniveau.

Aanbevolen v1-regel:

• typeconflict directory-versus-file niet proberen slim op te lossen
• behandel als blokkade/failure voor het huidige bestand
• laat bestaande flow stoppen of conflictueel handelen op bestandsniveau, maar niet op "directory vervangen"

6. Backend-impact

De bestaande backend uploadbasis is grotendeels herbruikbaar voor de feitelijke bestandsoverdracht, maar folder upload heeft waarschijnlijk extra backendondersteuning nodig voor directorystructuur.

Het bestaande endpoint ondersteunt nu:

• 1 file per request
• target_path
• basename-validatie

Voor folder upload is minimaal een van deze routes nodig:

Route A: frontend maakt directories expliciet aan

• frontend leest relatieve paden
• frontend zorgt eerst dat directories bestaan via bestaand mkdir endpoint
• daarna uploadt frontend elk bestand naar het juiste target_path

Voordelen:

• weinig nieuw backendcontract
• hergebruik van bestaande mkdir en upload

Nadelen:

• meer frontendcoordinatie
• meer requests

Route B: upload-endpoint accepteert veilige relatieve subpath

• per bestand meegeven:
  • target_path
  • relative_path
  • file
• backend maakt ontbrekende directories aan na validatie

Voordelen:

• schonere folder-uploadflow
• minder frontendcomplexiteit

Nadelen:

• nieuw backendcontract
• iets meer validatielogica

Aanbeveling voor laag regressierisico:

• v1 folder upload liever via Route A ontwerpen:
  • frontend maakt directories expliciet aan via bestaande of lichte mkdir-flow
  • frontend uploadt bestanden daarna via bestaand endpoint
• alleen als dat in praktijk te onhandig blijkt, Route B overwegen

Beide varianten moeten blijven leunen op:

• path_guard
• bestaande whitelist/root-containment
• bestaande naamvalidatie per segment

7. Frontend-impact

De bestaande sequentiele uploadflow kan worden uitgebreid zonder herontwerp:

• browser levert lijst bestanden uit de gekozen map
• frontend groepeert impliciet op relatieve directorystructuur
• frontend zorgt dat doel-directories bestaan
• frontend uploadt daarna de files sequentieel

Voortgang bij veel bestanden:

• huidige compacte progress UI kan blijven
• tonen:
  • aantal totaal
  • huidig bestand
  • doelpad of huidige relatieve submap indien nuttig
• geen zware task-UI nodig in v1

Aanbevolen v1-richting:

• zelfde uploadmodal/progresscomponent als nu
• alleen uitbreiden met "uploading folder X to path Y"
• geen tweede aparte uploadarchitectuur

8. Regressierisico

Belangrijkste risico's:

• security: relatieve paden uit browser niet blind vertrouwen
• diepe mapstructuren: veel requests, langzame voortgang
• gedeeltelijke successen/failures: batch kan halverwege stoppen
• conflictcomplexiteit: directoryconflicten versus bestandsconflicten
• UI-complexiteit: folder upload mag bestaande file upload niet verwarren

Specifiek risico:

• een ogenschijnlijk simpele folder-upload kan ongemerkt uitgroeien tot een mini-sync-engine
• dat moet expliciet vermeden worden

9. Teststrategie

Backend golden tests

Als folder upload later gebouwd wordt, minimaal testen:

• create-mkdir-then-upload flow voor nested directorystructuur
• traversal blokkade op relatieve padsegmenten
• invalid filename segment blokkade
• typeconflict file-versus-directory
• conflict op bestaand bestand
• upload naar bestaande directorystructuur

UI smoke/regressietests

• folder-upload startpunt aanwezig
• progress UI blijft werken
• conflictopties blijven intact
• actieve-paneel target blijft leidend

Handmatige validatie

• map met alleen files
• map met nested subdirs
• map met enkele conflicten
• map met typeconflict
• lange/brede directorystructuur

10. Aanbeveling

De aanbevolen v1-richting met laag regressierisico is:

• ondersteun precies 1 lokale map
• behoud de geselecteerde mapnaam in de doelstructuur
• gebruik browser-native directory picker
• breid de bestaande sequentiele uploadflow uit in plaats van een nieuwe architectuur te bouwen
• houd conflictbehandeling primair op bestandsniveau
• behandel bestaande directories als toegestaan
• vermijd drag & drop, taskintegratie, chunking en resumable uploads

Concreet aanbevolen technische richting:

• eerst proberen met bestaande architectuur en expliciete directorycreatie vanuit frontend
• alleen als dat te fragiel blijkt een kleine backenduitbreiding voor veilige relatieve paden ontwerpen

Dit houdt folder upload klein, bruikbaar en beheersbaar zonder de bestaande uploadflow opnieuw uit te vinden.