1 analyse

De repo heeft al een bruikbaar taskmodel voor copy, move, download en duplicate, maar de main WebUI gebruikt dat model voor copy/move nog nauwelijks. In de hoofd-UI ziet de gebruiker na start nu vooral een korte statusregel of summary; live voortgang staat feitelijk alleen in `F1 > Settings > Logs`. Daardoor ontbreekt directe, persistente feedback in de hoofd-UI en is er geen zichtbare rem op dubbel starten.

Belangrijkste conclusie:

- Copy en move hebben al echte backend-tasks met progressvelden.
- De bron van truth voor lopende copy/move-taken is al `/api/tasks`.
- Er bestaat nu geen cancel/abort voor copy of move.
- Een eerlijke abortknop voor copy/move kan dus nu niet frontend-only worden toegevoegd.
- De kleinste veilige stap is een compacte live task-indicator in de bestaande header/toolbar-zone, gevoed door de bestaande task-feed.

2 bestaande functionaliteit

A. Taskmodel / backend

- `copy` en `move` gebruiken hetzelfde taskmechanisme via [tasks_runner.py](/workspace/webmanager-mvp/webui/backend/app/tasks_runner.py), [task_repository.py](/workspace/webmanager-mvp/webui/backend/app/db/task_repository.py), [copy_task_service.py](/workspace/webmanager-mvp/webui/backend/app/services/copy_task_service.py) en [move_task_service.py](/workspace/webmanager-mvp/webui/backend/app/services/move_task_service.py).
- Taskstatussen die al bestaan in [task_repository.py](/workspace/webmanager-mvp/webui/backend/app/db/task_repository.py):
  - `queued`
  - `running`
  - `completed`
  - `failed`
  - daarnaast voor download ook `requested`, `preparing`, `ready`, `cancelled`
- Progressinformatie bestaat al:
  - files: `done_bytes`, `total_bytes`, `current_item`
  - batch/directory: `done_items`, `total_items`, `current_item`
- Copy:
  - file copy gebruikt byte-progress callback
  - directory copy is grof: `0/1` naar `1/1`
  - batch copy gebruikt item-progress
- Move:
  - same-root file move heeft praktisch geen tussentijdse progress, alleen start/einde
  - cross-root file move gebruikt copy-progress en delete na afloop
  - directory move is grof `0/1` naar `1/1`
  - batch move gebruikt item-progress
- Er is al read-API voor tasks:
  - `GET /api/tasks`
  - `GET /api/tasks/{task_id}`
- Er is geen cancel-API voor copy/move.
- De enige echte cancel in de repo zit nu bij archive-downloads in [archive_download_task_service.py](/workspace/webmanager-mvp/webui/backend/app/services/archive_download_task_service.py) en `POST /api/files/download/archive/{task_id}/cancel`.
- Copy/move workers in [tasks_runner.py](/workspace/webmanager-mvp/webui/backend/app/tasks_runner.py) hebben geen cooperative cancel checks.
- Copy/move history bestaat al via [history_repository.py](/workspace/webmanager-mvp/webui/backend/app/db/history_repository.py): `queued`, `completed`, `failed`.

B. Bestaande frontend feedback

- In de hoofd-UI starten copy en move vanuit [app.js](/workspace/webmanager-mvp/webui/html/app.js):
  - `startCopySelected()`
  - `executeMoveSelection()`
- Huidige feedback voor copy/move:
  - `setStatus(...)` onderin/headerstatus
  - `showActionSummary(...)`
  - `openFeedbackModal(...)` via `actions-error`
- Die feedback is niet persistent als live taskweergave.
- Er is nu geen compacte taskindicator in de hoofd-UI.
- `state.selectedTaskId` en `refreshTasksSnapshot()` bestaan al in [app.js](/workspace/webmanager-mvp/webui/html/app.js), maar worden voor copy/move alleen gebruikt om een snapshotcount op te halen; er is geen zichtbare hoofd-UI-component die dit toont.
- Buiten download is er geen modal of popover voor actieve taken in de hoofd-UI.

C. Logs / history / settings

- `F1 > Settings > Logs` toont al twee side-by-side secties:
  - `Tasks`
  - `History`
- Deze UI gebruikt al de bestaande feeds:
  - `/api/tasks`
  - `/api/history`
- Polling bestaat al in [app.js](/workspace/webmanager-mvp/webui/html/app.js):
  - `loadTasksForSettings()`
  - `loadHistoryForSettings()`
  - `loadLogsAndTasksForSettings()`
  - `scheduleSettingsLogsPolling()`
- De UI rendert taskdetails al compact via `formatTaskLine(task)`:
  - status
  - source/destination
  - `done_items/total_items`
  - `current_item`
- Dat betekent dat de repo al een bruikbare frontend formatteringslaag heeft die ook buiten Settings herbruikbaar is.

D. Abort/cancel haalbaarheid

- Copy/move kunnen nu technisch niet veilig worden afgebroken via bestaande code.
- Er is geen taskstatus-overgang of API-contract voor copy/move-cancel.
- Er is geen cooperative worker-check in copy/move loops.
- Er is geen rollback.
- Eerlijke cancelsemantiek voor copy/move zou dus moeten zijn:
  - stop resterende verwerking zo snel mogelijk op een checkpunt
  - reeds verwerkte bestanden blijven zoals ze zijn
  - geen rollback
- Maar die semantiek is nog niet geïmplementeerd.
- Conclusie: een abortknop voor copy/move is nu buiten scope zonder backendwerk.

3 scope

Minimale veilige volgende stap, op basis van wat al bestaat:

- frontend-only hoofd-UI verbetering
- geen layoutwijziging van de dual-pane browse-UI
- geen nieuw vast paneel
- wel een compacte task/status chip in bestaande headerbar of function-bar zone
- alleen zichtbaar als er actieve taken zijn (`queued`, `running`, en eventueel download `requested/preparing`)
- klik opent een kleine popover/dropdown met actieve taken
- popover hergebruikt bestaande taskdata en formattering uit `/api/tasks`
- popover bevat link/actie naar `F1 > Settings > Logs`
- geen abortknop voor copy/move in deze fase

Waarom dit binnen scope past:

- gebruikt bestaande task-feed
- gebruikt bestaande taaksemantiek
- verandert de hoofd-layout niet
- geeft persistente feedback zonder modal-first patroon
- is compatibel met de OneDrive-achtige richting: compacte indicator, detail op aanvraag

4 impact

Positief:

- gebruiker ziet direct in de hoofd-UI dat copy/move loopt
- feedback blijft zichtbaar zolang taak actief is
- minder kans op dubbel starten
- geen extra structureel paneel
- F1 Logs blijft intact als detailbron

Beperkingen:

- zonder backendwerk is er nog geen eerlijke cancel voor copy/move
- progress blijft zo nauwkeurig als bestaande taskdata toelaat
- same-root move en directory move blijven qua progress relatief grof

5 risico

Laag tot middel als alleen de voorgestelde frontendstap wordt gebouwd.

Belangrijkste risico’s:

- polling in de hoofd-UI kan onrustig worden als hij niet net zo stabiel wordt gebouwd als de bestaande Settings-polling
- een te opvallende indicator kan visueel concurreren met de bestaande headerstatus
- als een abortknop zonder backendsteun zou worden toegevoegd, zou dat misleidend zijn; dat moet expliciet niet gebeuren

Expliciet risico buiten scope:

- copy/move-cancel vereist backend-aanpassing aan taskmodel, runner en waarschijnlijk history

6 testplan

Voor de minimale frontendstap:

- gerichte UI smoke/golden checks voor:
  - indicator aanwezig in header/toolbar markup
  - indicator alleen bedoeld voor actieve taken
  - popover/dropdown markup aanwezig
  - link naar bestaande logs-entrypoint aanwezig
- gerichte JS-checks voor:
  - actieve taken worden uit `/api/tasks` gefilterd
  - `queued`/`running` tonen indicator
  - `completed`/`failed` verdwijnen uit de actieve indicator
  - polling start/stop logisch zonder extra layoutreset
- geen backend golden updates nodig zolang `/api/tasks` contract ongewijzigd blijft

Niet nu testen:

- abort voor copy/move, want die functionaliteit bestaat nog niet

7 acceptatiecriteria

Voor de voorgestelde minimale stap:

- Een gestart copy- of move-proces is zichtbaar in de hoofd-UI zonder navigatie naar `F1 > Settings / Logs`.
- De oplossing verandert de dual-panel layout niet structureel.
- De feedback blijft zichtbaar zolang de taak actief is.
- De oplossing gebruikt bestaande taskdata als bron van truth.
- Er wordt geen fake progress getoond.
- Er wordt geen fake cancelknop getoond voor copy/move.
- Bestaande task/log/history-functionaliteit blijft intact.
- API-contract blijft ongewijzigd.

Voor abort/cancel:

- Niet acceptabel in deze fase zonder backendsteun.
- Eerst aparte backendfase nodig.

8 codex-uitvoering / voorstel

Huidige stap:

- Alleen analyse uitgevoerd.
- Geen functionele implementatie gedaan.

Waarom:

- `CHANGE_POLICY.md` zegt dat frontend flow aanpassen eerst een voorstel nodig heeft.
- De opdracht vroeg expliciet om eerst grondige repo-inspectie en pas daarna een minimaal voorstel.
- Cancel/abort voor copy/move is niet eerlijk implementeerbaar zonder backendwerk.

Minimaal wijzigingsvoorstel dat ik hierna zou uitvoeren als vervolgstap:

1. Frontend-only compacte task chip
- plaats in `#title-zone-actions` of direct naast `#status`
- toont bijvoorbeeld:
  - `1 task running`
  - `3 active tasks`

2. Kleine popover/dropdown
- opent op klik op de chip
- toont alleen actieve taken uit `/api/tasks`
- hergebruikt bestaande `formatTaskLine(task)` of een kleine variant daarop
- toont eerlijke status:
  - `queued`
  - `running`
  - eventueel later download `requested/preparing`

3. Polling hergebruik
- hergebruik bestaande `/api/tasks`
- implementeer lichte polling alleen als er actieve taken zijn of als de popover open is
- gebruik stabiele rerender-aanpak zoals in Settings > Logs

4. Doorgang naar detail
- knop of link `View in Logs`
- opent bestaande `F1 > Settings > Logs`

5. Expliciet nog niet doen
- geen cancelknop voor copy/move
- geen extra paneel
- geen fake progressbar

Vervolgvoorstel voor latere backendfase als abort gewenst is:

- copy/move taskstatus uitbreiden met `cancelled`
- cancel-endpoint voor copy/move
- cooperative checks in `TaskRunner` tussen items/chunks
- eerlijke semantiek:
  - stop resterende verwerking
  - reeds verwerkte bestanden blijven bestaan
  - geen rollback

9 gewijzigde bestanden

- [project_docs/UI_FEEDACK.md](/workspace/webmanager-mvp/project_docs/UI_FEEDACK.md)

10 uitgevoerde tests

Wel gedaan:

- code-inspectie van backend taskmodel, runners, services, routes en frontend task/log UI

Niet gedaan:

- geen functionele tests
- geen implementatiechecks

Reden:

- deze stap is bewust alleen analyse + voorstel, geen implementatie