I hope this is the right place to post issues, GitHub seems closed
The below is ai generated, but human-confirmed 
//
Dragging any row in a list-layout section sends it to the top, no matter where you drop it — the Panel posts position: 1. Kirby 5.5.3, plain install, no plugins, no custom CSS, default blueprints. Chromium.
It’s geometry, not logic. .k-item-sort-handle sits at inset-inline-start: -28px, so the handle is entirely outside the row box, and since k-items passes handle: true a drag can only start there. SortableJS treats clientX < contentRect.left - 10 as “insert before the first element”. With the list at x=272 the threshold is 262 and the handle centre is at 258 — so the condition is already true at mousedown, before anything has moved. Only the rightmost 10 of the 28 handle pixels are safe, which is why it looks intermittent.
Steps to reproduce
- Plain 5.5.2, site blueprint with a pages section (default list layout).
- Add eight listed pages.
- Open /panel/site, grab the handle on the last row, drop it on the second-to-last one.
Expected: it moves up one. Actual: it jumps to position 1, request body {“status”:“listed”,“position”:1}.
Grabbing at x=268 instead of x=250 gives the correct position: 10. Same if you grab at 250 and nudge right before moving up — so the Y evaluation is fine, the X check just overrides it.
Worth flagging: sorting commits immediately, so one bad drop rewrites the whole numbering with no undo.
Anything that keeps the pointer within 10px of contentRect.left fixes it — move the handle inside the item’s border box, extend the box to cover it, or raise the spacer past the offset.