Pre-fix algorithm only considered status == "open" child items in
active plans. Two consequences agents flagged in BUG-987 / BUG-990:
1. In-progress items never appeared. The most likely "what should I
work on next" answer is "the work the user is already on" —
pre-fix the engine returned [] when nothing was open AND a task
was actively in-progress.
2. Blocked items appeared. Suggesting work that has unresolved
blockers wastes the user's time when they go to start it.
Algorithm changes (internal/server/handlers_dashboard.go):
- Include both `open` and active-status (in-progress / fixing /
exploring / etc., via existing isActiveStatus helper) child items.
- Filter out items with at least one active "blocks" link from a
non-done blocker. Mirrors the attention-section logic, factored
into a new itemBlockedByActive helper.
- Sort: in-progress first (always wins over open, regardless of
priority), then by priority rank within each bucket. Pinned in
test expectations.
- Reason text distinguishes "In-progress task..." vs "Open task..."
so agents see why an item was suggested.
Tests:
- TestDashboardSuggestedNext expectations updated for new ordering
(in-progress wins over open). Test now covers the in-progress
surfacing path the bug specifically wanted.
- New TestDashboardSuggestedNext_FiltersBlockedItems exercises the
blocker-filter — explicitly creates a blocks link and confirms
the blocked task is suppressed even at critical priority.
Out of scope: high-priority orphan suggestions (items not in any
active plan). The bug item flagged this as a stretch goal; this PR
sticks to the active-plan-children scope of the existing algorithm.
Adding orphans would need a sort/relevance model since "everything
high priority" can be a long list.
Parent: BUG-990.
xarmian
48bbe7453b