Summary

The Kanban dashboard PATCH /tasks/:id endpoint allows setting status='running' via _set_status_direct(), bypassing the dispatcher/claim path (kanban_db.claim_task()) that atomically creates run rows, claim locks, expiry timestamps, and worker process metadata.

Problem

A dashboard/API caller can transition any task to running without an active worker, claim lock, or task_runs row. These tasks become stuck in running state with no way to recover except manual DB intervention, and violate Kanban's run-history invariants.

Fix

Reject status='running' with HTTP 400 in the dashboard PATCH handler, requiring all transitions to running to go through the canonical claim_task() dispatcher path.

# Before
elif s in ("todo", "running", "triage"):
    ok = _set_status_direct(conn, task_id, s)

# After  
elif s == "running":
    raise HTTPException(
        status_code=400,
        detail="Cannot set status to 'running' directly; use the dispatcher/claim path",
    )
elif s in ("todo", "triage"):
    ok = _set_status_direct(conn, task_id, s)

Scope

• plugins/kanban/dashboard/plugin_api.py: 1 file, 6 lines changed

Testing

• 261 kanban tests pass (1 pre-existing failure unrelated to this change)

Closes #19535