fix: keep kanban drag drop from opening detail

[franksong2702]

Thinking Path

• Kanban cards are draggable and clickable, and both interactions currently share the same card surface.
• Drag/drop status changes should update the board in place, not imply that the user explicitly selected the moved task.
• The old path could open the detail pane in two ways: a trailing synthetic click after drag/drop, and the generic task-update helper opening detail after every PATCH.
• This PR keeps explicit card click and keyboard activation unchanged while making drag/drop a board-only status update.

What Changed

• Added a short click-suppression window around Kanban drag start/end/drop so browser-emitted trailing clicks do not open task detail.
• Routed drag/drop PATCHes through updateKanbanTask(..., {openDetail: false}) so board refreshes do not programmatically select the moved task.
• Left normal card click, keyboard activation, and quick-action status buttons on their existing detail-opening path.
• Added a static regression test that pins both failure paths.
• Added an Unreleased changelog entry.

Why It Matters

Dragging a Kanban card is a status update, not a task-selection action. Keeping drag/drop from opening the detail pane makes the board behave predictably and avoids surprising context switches while users reorganize work.

Closes #2529.

Verification

• node --check static/panels.js
• python3 -m pytest tests/test_kanban_ui_static.py::test_kanban_dragging_card_does_not_open_detail_on_drop_click tests/test_kanban_ui_static.py::test_kanban_ui_parity_polish_adds_card_metadata_quick_actions_and_swimlanes -q
• python3 -m pytest tests/test_kanban_ui_static.py -q
• git diff --check

Screenshots are not included because this is an interaction-state fix with no visual layout change; the regression is whether drag/drop opens the detail pane.

Risks / Follow-ups

• The click suppressor is intentionally short-lived and scoped to card opening only; keyboard activation still opens task detail.
• This does not change Kanban backend status semantics, dispatcher rules, board selection, or task detail rendering.

Model Used

OpenAI Codex (GPT-5). AI assisted with code review, implementation, and verification.

[nesquena-hermes]

Summary

Reading static/panels.js:1267-1320 on this branch against origin/master, and the test in tests/test_kanban_ui_static.py:695-749, the fix correctly identifies and patches both failure paths called out in #2529:

1. The browser's trailing synthetic click after drag/drop. Suppressed via the time-windowed _kanbanSuppressCardClickUntil set on ondragstart/ondragend/ondrop, checked by the new openKanbanCard() interceptor on the card's onclick.
2. The implicit detail-pane open inside updateKanbanTask() after every PATCH. Now opt-out via {openDetail: false}, only used by the drop path; the explicit click, the Enter/space activation, and quickKanbanCardAction() keep the old open-detail behavior.

The split is the right shape: drag/drop is a status mutation, explicit click is a selection.

Code reference

The card template change at static/panels.js:1384 (this branch):

return `<article class="kanban-card ${esc(stale)}" data-kanban-task-id="${esc(task.id)}" draggable="true" ondragstart="dragKanbanTask(event, '${esc(task.id)}')" ondragend="finishKanbanDrag(event)" onclick="return openKanbanCard(event, '${esc(task.id)}')" tabindex="0" role="button" onkeydown="if(event.key==='Enter'||event.key===' '){event.preventDefault();loadKanbanTask('${esc(task.id)}')}">

And the drop handler at static/panels.js:1314-1322:

async function dropKanbanTask(event, status){
  _kanbanSuppressNextCardClick();
  event.preventDefault();
  event.stopPropagation();
  clearKanbanDrop(event);
  const taskId = event.dataTransfer ? event.dataTransfer.getData('text/plain') : '';
  if (taskId && status) await updateKanbanTask(taskId, {status}, {openDetail: false});
  _kanbanSuppressNextCardClick();
}

The updateKanbanTask signature change at static/panels.js:2297-2308 correctly defaults openDetail to true, so existing call sites (quickKanbanCardAction, the quick-action lifecycle buttons at :2317, the task-modal save at :2265, the cron-from-task path) keep their current behavior unchanged.

Diagnosis / Recommendation

The approach is sound. Two small notes that may or may not matter for landing:

1. The 700ms window is generous but bounded. Browsers emit the trailing click essentially synchronously with dragend; 700ms covers slow event loops on low-end machines without making the card feel unresponsive after a normal click. Worth keeping as-is.

2. The double-call to _kanbanSuppressNextCardClick() inside dropKanbanTask is defensive belt-and-suspenders. The first call arms the window before the async PATCH; the second re-arms after the await in case loadKanban(true) re-rendered the DOM mid-flight and the click fires against the new card node. That's actually a real concern — updateKanbanTask() awaits loadKanban(true) which calls _kanbanRenderBoard(), regenerating _kanbanCard() HTML and replacing the article element the user dropped onto. The re-arm makes sense.

3. The card stays at role="button" and tabindex="0", and Enter/Space keep using loadKanbanTask directly without the click suppressor. That's intentional and correct per the PR description — keyboard activation should always open detail, since there's no drag/drop synthesis path on keyboard activation.

Verification

The static test at tests/test_kanban_ui_static.py:695-749 pins every contract surface the runtime depends on: the existence of the four new functions, the _kanbanSuppressNextCardClick calls inside dragKanbanTask / finishKanbanDrag / dropKanbanTask, the {openDetail: false} argument shape, the event.stopPropagation() inside drop, and that the card template no longer wires onclick="loadKanbanTask(...)" directly. That's the right level of coverage for a JS-only behavior change without browser fixture infrastructure.

One thing the static test doesn't cover but probably can't easily: confirming the time-window logic in openKanbanCard actually allows a click through after the window expires. The token check via assert "Date.now()" in open_body plus _kanbanSuppressCardClickUntil is structural only. That's fine — the alternative needs a JSDOM harness which isn't in this repo's test stack.

Looks good for merge.