Should Angular components that use drag and drop be migrated to the Pragmatic-based `sortable-lists` foundation, or stay on Dragula until each surface gets its Angular → Rails/Hotwire rewrite?

This gates step 4 of the rollout plan in #DREAM-677 — and, transitively, when the `dragula` npm dependency can be removed.

### Inventory (as of 2026-07)

**Dragula-based, via the shared Angular `DragAndDropService`** (`frontend/src/app/shared/helpers/drag-and-drop/drag-and-drop.service.ts`):

* Boards — `board-list.component.ts`, `board-list-container.component.ts`, `board-partitioned-page.component.ts`
* Work-package table reorder / card view / grid — `drag-and-drop-transformer.ts`, `wp-card-view.component.ts`, `wp-grid.component.ts`
* Team planner calendar — `calendar-drag-drop.service.ts`
* BIM BCF list — `bcf-list.component.ts`
* Draggable autocompleter — `draggable-autocomplete.component.ts`
* Dashboards / grids widgets — grids module

**Angular CDK drag-drop based — explicitly out of scope** (stays on CDK until the surface itself is rewritten):

* Board column reordering — `board-list-container.component.ts` (`CdkDragDrop`)
* Grids module drag handles

Begin of the insertion*(Correction 2026-07-13: the team planner calendar and the draggable autocompleter use Dragula directly, not via `DragAndDropService`.)*

End of the insertion ### Decision criteria

Migrate an Angular Dragula surface to the new foundation only if **both** hold:

1. A supported integration path between Pragmatic DnD / `sortable-lists` and the Angular component exists, **or** creating one is trivial (< a few hours of work).
2. The surface is not already scheduled for an Angular → Rails/Hotwire rewrite that would make the DnD migration throwaway work.

Otherwise: leave the surface on Dragula until its rewrite, and accept that `dragula` cannot be dropped from `package.json` (#DREAM-677 step 5) while any Angular consumer remains.

### Begin of the insertionDecision (2026-07-13)

**Migrate the Angular Dragula surfaces to Pragmatic now**, without waiting for per-surface Hotwire rewrites. Decision taken unilaterally by Alex to unblock #DREAM-677 step 4.

Strategy: reimplement the shared `DragAndDropService` on Pragmatic behind its unchanged public API (#DREAM-756), with per-surface verification children: Boards (#DREAM-757), work-package table/card view/grid (#DREAM-758), BIM BCF list (#DREAM-759), dashboards/grids widgets (#DREAM-760). The direct Dragula consumers migrate separately: #DREAM-755 (draggable autocompleter, branch in flight) and #DREAM-761 (team planner). Final cleanup and removal of the `dragula` dependency: #DREAM-762.

Because the service API stays unchanged, the migration is not throwaway work even for surfaces later rewritten to Hotwire. Angular CDK usages remain out of scope as stated above.

###End of the insertion Open questions Begin of the insertion— resolvedEnd of the insertion

* Boards: DnD migration in place vs. waiting for a full Hotwire rewrite Begin of the deletion of boardsEnd of the deletion — Begin of the insertion**superseded**: the API-unchanged service rewrite migrates boards in place without throwaway work, whicheverEnd of the insertion Begin of the deletion whichEnd of the deletion comes first on the Begin of the insertionroadmap.End of the insertion Begin of the deletion roadmap?End of the deletion
* Begin of the deletion Does theEnd of the deletion Turbo morph guard Begin of the deletion approach even applyEnd of the deletion inside Angular-managed Begin of the insertionDOM — **N/A**: Angular-managed DOM is not morphed by Turbo, so noEnd of the insertion Begin of the deletion DOM, or would an Angular integration need its ownEnd of the deletion registration lifecycle for Pragmatic's element Begin of the insertionattributes is needed there.End of the insertion Begin of the deletion attributes?End of the deletion