# UI_F6_PURE_MOVE_V1

## 1. Doel

`F6` moet in de UI een expliciete pure `Move`-actie worden.

Waarom:
- `F2` heeft nu een eigen rename-flow
- daarmee is de oorspronkelijke gecombineerde `Rename/Move`-semantiek in de UI niet meer nodig
- een pure `Move`-flow maakt de functietoetsen voorspelbaarder:
  - `F2 = Rename`
  - `F6 = Move`
- dit sluit beter aan op klassieke file-manager verwachtingen en vermindert cognitieve ruis in de popup-flow

Belangrijk bestaande context:
- move-functionaliteit bestaat backendmatig al
- move-functionaliteit bestaat UI-matig al
- file move, directory move binnen huidige scope en batch move binnen huidige scope werken al
- deze stap gaat dus niet over nieuwe move-capaciteit, maar over het vereenvoudigen van de UI-flow rond de bestaande move-actie

## 2. Scope

De pure `Move`-flow in v1 moet de bestaande move-scope UI-matig netjes afdekken voor zover die al ondersteund wordt.

In scope:
- exact 1 file
- exact 1 directory
- meerdere files
- meerdere directories
- gemengde selectie van files + directories

Voorwaarde:
- alleen binnen de bestaande huidige move-scope
- alles wat backendmatig al geblokkeerd is, blijft geblokkeerd
- de UI mag dat duidelijker presenteren, maar mag de scope niet verbreden

Niet in scope:
- nieuwe backend move-capaciteit
- nieuwe tasksemantiek
- nieuwe batch-semantieken buiten de bestaande backend
- rename binnen `F6`

## 3. Gewenst gedrag

`F6` en de `Move`-knop moeten exact dezelfde frontendflow gebruiken.

Kernregel:
- `F6` keyboard shortcut = pure move-flow
- `Move`-knop in functiebalk = exact dezelfde pure move-flow
- beide gebruiken dezelfde centrale frontendhandler

Popupregel:
- de bestaande move-popup wordt een pure move-popup
- geen rename-invoerveld in deze flow
- geen naamwijzigingssemantiek in deze flow
- de popup richt zich alleen op doelpad of doelmap voor verplaatsen

Interactie:
- `Enter` bevestigt
- `Escape` annuleert
- `X` sluit popup

Gedragslijn per context:
- exact 1 item: popup toont expliciete move-context voor dat item
- meerdere items: popup toont batch move-context
- popuptekst en labels moeten spreken in termen van `Move`, niet `Rename/Move`

## 4. Relatie met bestaande move-scope

Wat al bestaat en alleen hergebruikt moet worden:
- single file move
- single directory move binnen de huidige scope
- batch move binnen de huidige scope
- task-based move
- bestaande validaties en blokkades

Dat betekent:
- de pure `Move`-popup hoeft geen nieuwe backendbeslissingen te nemen
- de frontend mag alleen een duidelijkere presentatie en dispatchlaag geven
- validatiefouten zoals cross-root blokkades, subtree-blokkades, mixed-root blokkades en bestaande destination-conflicten blijven door de bestaande backend en bestaande UI-validatie worden afgevangen

Pragmatische consequentie:
- de move-popup moet vooral destination-gericht zijn
- submit moet direct de bestaande move-logica aanroepen
- geen impliciete keuze meer tussen rename en move in deze flow

## 5. Relatie met F2 Rename

Na invoering van pure `F6 Move` geldt:
- `F2` blijft exclusief voor rename
- `Rename`-knop blijft exclusief voor rename
- `F6` wordt exclusief voor move
- `Move`-knop wordt exclusief voor move

Belangrijk ontwerpprincipe:
- geen gedeelde rename/move-popup meer
- `F2` en `F6` krijgen elk een eigen, semantisch heldere popupflow
- dit maakt toekomstige onderhoud en UX-consistentie eenvoudiger

## 6. UI-semantiek

### Welke contextinformatie is nuttig

Voor een pure move-popup is nuttig:
- broninformatie: welk item of hoeveel items geselecteerd zijn
- destination-informatie: waarheen wordt verplaatst
- bij batch move: doelmap in plaats van volledig doelpad per item

### Default destination

Aanbevolen defaultvoorstel:
- gebruik het current path van het inactieve paneel als destination-basis

Voor exact 1 item:
- toon een destination pad of destination map duidelijk, afhankelijk van de bestaande implementatierichting
- aanbevolen: toon volledig destination path, vooraf ingevuld op basis van het inactieve paneel + itemnaam
- dit houdt aan bij de bestaande move-aanroepsemantiek voor single-item move

Voor batch move:
- toon aantal geselecteerde items
- toon doelmap = current path van het inactieve paneel
- geen rename-achtige tekst of naamveld per item

### Foutmeldingen en blokkades

Compact tonen in de popup of bestaande errorzone:
- destination exists
- mixed roots not allowed
- destination inside source not allowed
- cross-root directory move not supported
- andere bestaande backendfouten

Belangrijk:
- foutmeldingen moeten move-gericht geformuleerd zijn
- geen verwijzing naar rename of gecombineerde semantiek

## 7. Regressierisico

Belangrijkste risico's:
- per ongeluk opnieuw bouwen van bestaande move-functionaliteit in plaats van die te hergebruiken
- verwarring tussen oude gecombineerde popup en nieuwe pure move-popup
- inconsistente keyboard- en knopwiring tussen `F6` en `Move`
- onbedoelde impact op de al werkende `F2 Rename`-flow

Mitigatie:
- `F6` en `Move` één centrale pure move-handler laten delen
- bestaande backend move-calls intact laten
- `F2` volledig gescheiden houden
- popup-tekst en labels expliciet move-only maken
- geen backendwijzigingen in deze stap

## 8. Teststrategie

UI smoke/regressietests:
- functiebalk bevat `Move` met `F6`
- `F6` wiring blijft aanwezig
- `Move`-knop gebruikt dezelfde handler als `F6`
- move-popupcontainer aanwezig en move-only geëtiketteerd
- rename-popup blijft apart aanwezig voor `F2`

Handmatige validatie:
- exact 1 file -> `F6` opent pure move-popup
- exact 1 directory -> `F6` opent pure move-popup binnen huidige scope
- meerdere files -> batch move-popup blijft logisch werken
- meerdere directories -> batch move-popup blijft logisch werken binnen huidige scope
- gemengde selectie -> bestaande batch move-scope en blokkades blijven correct
- `F2 Rename` blijft volledig los en ongewijzigd

Bestaande regressies die bewaakt moeten blijven:
- single file move same-root
- single file move cross-root
- single directory move binnen huidige scope
- batch move file-only
- batch move met directories binnen huidige scope
- blokkades voor mixed roots, subtree en symlink source

## 9. Aanbeveling

Aanbevolen v1-richting met laag regressierisico:
- maak `F6` en `Move` UI-semantisch puur move-only
- verwijder rename-semantiek uit de `F6`-popupflow
- behoud en hergebruik alle bestaande move-logica, validaties en backendcalls
- houd `F2 Rename` volledig apart

Waarom dit de veiligste richting is:
- maximale herbruik van bestaande backend en UI-logica
- minimale semantische overlap tussen `Rename` en `Move`
- duidelijkere functietoetsbetekenis
- laag regressierisico omdat de verandering vooral UI-opschoning is, geen capability-uitbreiding