webmanager-mvp/project_docs/UI_FEEDACK.md

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, task_repository.py, copy_task_service.py en move_task_service.py.
• Taskstatussen die al bestaan in 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 en POST /api/files/download/archive/{task_id}/cancel.
• Copy/move workers in tasks_runner.py hebben geen cooperative cancel checks.
• Copy/move history bestaat al via history_repository.py: queued, completed, failed.

B. Bestaande frontend feedback

• In de hoofd-UI starten copy en move vanuit 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, 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:
  • 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

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