Priority Queue¶

Tasks that are eligible to run can be reordered in the dashboard without touching BACKLOG.md. The new tasks/.priority-order.yml file is a transient priority overlay: listed IDs are picked first by the runner (in the listed order), the rest follow normal BACKLOG order. The file is "user-driven state", not product data — it can be cleared, hand-edited, or just ignored.

Reordering in the UI¶

A horizontal chip-row at the bottom of the project view shows every runnable task. The order of chips is the order the runner will pick from — among tasks whose dependencies are satisfied. Three ways to reorder:

Drag-and-drop (desktop, mouse)¶

Click and drag a chip to a new position. A 4 px drag threshold means a plain click still triggers onSelect (opens the task) instead of starting a drag. A drop indicator shows where the chip will land; auto-scroll kicks in at the viewport edge.

Long-press drag (mobile, touch)¶

Long-press a chip for 350 ms — it "lifts" with a vibration pulse — then drag and drop. Touch-targets are 44 px so the chips work cleanly with thumbs.

Keyboard¶

Tab to a chip, then:

Key	Action
`←` / `→`	Move the chip one position in either direction
`Esc`	Cancel — restore the previous order
`Enter`	Confirm the new position

ARIA roles role="listbox" + role="option" are set so screen readers announce the reorder operation.

Visual cues¶

📌 omordnad (N) badge on the OverviewView card when at least one project has an active priority overlay.
Återställ ordning link on the right edge of the chip-row clears the overlay and returns to pure BACKLOG order.

File format: `tasks/.priority-order.yml`¶

# Auto-generated by craft-easy-agentic dashboard.
# Tasks listed here are picked up by the runner BEFORE the
# default BACKLOG.md order. Edit by drag-and-drop in the UI
# or directly here — both paths are supported. Empty list (or
# missing file) means "use BACKLOG order".
order:
  - CA-T007
  - CA-T010

The file is a strict allow-listed write target: only <project>/tasks/.priority-order.yml can be written via the priority API. Anything else → 400.

Hand-editing¶

Edit the file directly with any text editor. The file-watcher snaps up the change within 3 s (mtime backstop on top of the inotify watch).

A broken yml is silently degraded to "empty list" with a WARN log — a fat-fingered hand-edit can never crash the runner. A task that becomes complete ([x]) or disappears from BACKLOG is automatically stripped from the file at the next watcher tick.

Concurrency safety¶

PUT/DELETE on the priority endpoint serialise via a per-project mutex. The atomic write goes via tempfile + rename(2) so a crash mid-write can't leave a half-written file. Two clients posting simultaneously cannot race on the same yml.

Interaction with the runner¶

The bash runner (runner/run-backlog.sh) reads .priority-order.yml via a strict awk pipe — no yq dependency, matching exactly the format the Rust parser produces. A broken file → no-op (BACKLOG order).

get_eligible_tasks
   └─ 1. Compute eligible set (deps satisfied, no lock)
   └─ 2. Apply priority overlay:
         tasks listed in .priority-order.yml come first
         (in listed order); rest in BACKLOG order

Tasks already running (locks in tasks/.tasks-state/locks/) are NOT affected by priority changes — only the next wave picks according to the new order.

API reference¶

Method	Path	Body	Returns
`PUT`	`/api/projects/{slug}/queue/order`	`{ "order": ["TASK-A", "TASK-B"] }`	`200` ok / `422` `{ error, ids }` on unknown or duplicate IDs / `400` on bad JSON
`DELETE`	`/api/projects/{slug}/queue/order`	—	`200` (idempotent — clears the file)

ProjectListItem.priority_count is exposed so the OverviewView card can render the 📌 badge without fetching a full snapshot per project.

Why an overlay, not a BACKLOG.md rewrite¶

BACKLOG.md is the canonical record of which tasks exist and how they depend on each other. It's commit-tracked, owner-curated, and meant to be stable. The priority overlay is the answer to "which of these am I focusing on right this minute" — transient, personal state, not something you commit. Keeping them separate means:

Reordering on your phone doesn't dirty git.
Multiple users can reorder without merge conflicts.
Resetting (Återställ ordning) deletes the overlay file; the canonical order is unchanged.