# 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