feat: Renamen functionaliteit aangepast

project_docs/UI_F2_RENAME_V1.md

@@ -0,0 +1,164 @@
+# UI_F2_RENAME_V1
+
+## 1. Doel
+
+`Rename` moet een expliciete eigen UI-flow krijgen via `F2`, los van de bestaande `F6` move-flow.
+
+Waarom:
+- `Rename` is conceptueel een andere actie dan `Move`
+- een eigen `F2`-flow sluit beter aan op klassieke file-manager bediening
+- het maakt de UI voorspelbaarder: `F2` = naam wijzigen, `F6` = verplaatsen
+- het vereenvoudigt later de verdere scheiding tussen rename en move in de UI, zonder backendwijziging
+
+Bestaande context:
+- rename-functionaliteit bestaat backendmatig al via het bestaande rename-endpoint
+- move-functionaliteit bestaat backendmatig al via het bestaande move-endpoint
+- `F6`/move-flow bestaat al in de UI
+- in deze stap moet dus niets nieuws in backend of API worden ontworpen; alleen een nette eigen rename-flow in de frontend
+
+## 2. Scope
+
+In scope voor v1:
+- exact 1 file geselecteerd
+- exact 1 directory geselecteerd
+- `F2` keyboard shortcut
+- `Rename`-knop in de functiebalk
+- compacte rename-popup
+
+Out of scope:
+- batch rename
+- rename van meerdere selectie-items
+- herontwerp van `F6`
+- backendwijzigingen
+- nieuwe dependencies
+
+## 3. Gewenst gedrag
+
+`F2` en de bestaande `Rename`-knop moeten exact dezelfde UI-flow gebruiken.
+
+Voorstel:
+- `F2` keyboard shortcut activeert de rename-flow
+- `Rename`-knop in functiebalk activeert exact dezelfde flow
+- beide openen een compacte rename-popup
+
+Popup-eigenschappen:
+- titel: `Rename`
+- toont context van het geselecteerde item
+- invoerveld bevat alleen de huidige naam
+- dus niet het volledige pad
+- focus direct in het invoerveld
+- tekst vooraf geselecteerd zodat overschrijven snel kan
+- `Enter` bevestigt
+- `Escape` annuleert
+- `X` rechtsboven sluit de popup
+
+Belangrijk semantisch verschil met `F6`:
+- `F2 Rename` werkt op naamniveau binnen dezelfde parent
+- de popup toont en bewerkt alleen de naam
+- geen destination pad, geen implicit move-semantiek
+
+## 4. Validatie
+
+Frontendvalidatie in v1 moet klein blijven en vooral duidelijke UX geven. De backend blijft de bron van waarheid.
+
+Frontend moet minimaal blokkeren of afvangen:
+- lege naam
+- ongewijzigde naam
+- namen met `/`
+- namen die triviaal ongeldig zijn zoals `.` of `..`
+
+Aanpak:
+- lichte pre-validatie in de popup voor snelle feedback
+- daarna altijd het bestaande rename-endpoint gebruiken
+- backend-validatie blijft leidend voor definitieve afhandeling
+
+Geen nieuwe rename-semantiek ontwerpen:
+- geen padbewerkingen in de popup
+- geen move-achtige fallback
+- geen root- of parent-wijziging
+
+## 5. Files en directories
+
+Exact 1 file:
+- rename toegestaan
+- popup opent met huidige bestandsnaam
+- bevestigen gebruikt bestaande backend-rename
+
+Exact 1 directory:
+- rename toegestaan
+- popup opent met huidige mapnaam
+- bevestigen gebruikt bestaande backend-rename
+
+Meerdere geselecteerde items:
+- in v1 niet ondersteunen
+- `F2` en `Rename` doen functioneel niets destructiefs
+- aanbevolen UX: knop disabled bij `selectedItems.length !== 1`
+- voor keyboardshortcut: geen actie als rename in de huidige context disabled zou zijn
+
+Dit sluit aan op de bestaande regel dat keyboardshortcuts dezelfde enabled/disabled toestand moeten respecteren als de functiebalkknoppen.
+
+## 6. Relatie met bestaande flows
+
+Herbruik:
+- bestaande backend rename-functionaliteit hergebruiken
+- bestaande move-functionaliteit ongemoeid laten
+- bestaande selectie- en active-pane-logica hergebruiken
+
+Regels:
+- `F2` en `Rename`-knop delen exact dezelfde frontendflow
+- `F6` blijft ongewijzigd in deze stap
+- bestaande `F6` rename/move-popup wordt niet herontworpen in deze stap
+- geen dubbele implementatie van backendlogica; alleen een aparte UI-laag voor rename
+
+Pragmatische richting:
+- introduceer een aparte compacte rename-popup
+- submit roept hetzelfde backend-endpoint aan als de huidige renameknop al gebruikt
+- succesvolle rename refresht alleen het actieve paneel, zoals nu al logisch is voor rename
+
+## 7. Regressierisico
+
+Belangrijkste risico's:
+- selectieflow: `F2` mag niet reageren bij ongeldige selectie
+- popup-focus: paneelkeyboard mag niet doorwerken terwijl de rename-popup open is
+- interactie met `F6`: geen verwarring of gedeelde state tussen rename-popup en bestaande rename/move-popup
+- onbedoeld herbouwen van bestaande rename/move-logica in plaats van hergebruik
+
+Mitigatie:
+- `F2` dezelfde disabled-context laten volgen als de `Rename`-knop
+- aparte popup-state voor rename, niet hergebruik van de complexere `F6` destination-popup
+- bestaande backend-rename endpoint direct blijven gebruiken
+- geen aanpassing aan `F6` in deze stap
+
+## 8. Teststrategie
+
+UI smoke/regressietests:
+- functiebalk bevat `Rename` met `F2`-hint
+- rename-popupcontainer aanwezig in HTML
+- rename-popup bevat invoerveld en sluitknop
+- `F2` wiring aanwezig in frontendcode
+- bestaande `F6` wiring blijft aanwezig
+
+Handmatige validatie:
+- exact 1 file geselecteerd -> `F2` opent rename-popup met alleen naam
+- exact 1 directory geselecteerd -> `F2` opent rename-popup met alleen naam
+- `Enter` bevestigt
+- `Escape` sluit
+- `X` sluit
+- meerdere selectie -> `F2` doet niets / rename blijft disabled
+- succesvolle rename refresht actief paneel
+- `F6` move-flow blijft ongewijzigd werken
+
+## 9. Aanbeveling
+
+Aanbevolen v1-richting met laag regressierisico:
+- voeg een aparte compacte rename-popup toe voor `F2` en de `Rename`-knop
+- werk alleen met de naam van exact 1 geselecteerd item
+- gebruik het bestaande backend rename-endpoint zonder nieuwe semantiek
+- laat `F2` en de `Rename`-knop exact dezelfde flow delen
+- laat `F6` volledig ongemoeid in deze stap
+
+Waarom dit de veiligste richting is:
+- duidelijke scheiding tussen rename en move in de UI
+- minimaal risico op regressie in bestaande move-flow
+- geen backendwerk nodig
+- sluit goed aan op klassieke file-manager verwachtingen