Boost in-progress items and their ancestors in sort scoring

[Copilot]

Items with in-progress status and their ancestor epics were sorted at base priority, burying active work beneath unstarted items of equal or lower priority. This adds score multiplier boosts in computeScore() so active work surfaces higher in all sortIndex-based views.

Changes

src/database.ts

• sortItemsByScore(): Before sorting, pre-computes a Set<string> of IDs that are ancestors of any in-progress item by walking each in-progress item's parent chain. Max-depth guard of 50 prevents infinite loops on circular refs. O(1) lookup per item during sort.

• computeScore(): Accepts the pre-computed ancestor set and applies two hardcoded multipliers as a final step:

  • IN_PROGRESS_BOOST = 1.5 — item is itself in-progress
  • PARENT_IN_PROGRESS_BOOST = 1.25 — item is an ancestor of an in-progress item
  • Non-stacking: direct boost takes precedence; no double-multiplying
  • Blocked items: no boost applied; existing -10000 penalty dominates

// Applied after all additive score components
if (item.status !== 'blocked') {
  if (item.status === 'in-progress') {
    score *= IN_PROGRESS_BOOST;          // 1.5x
  } else if (ancestorsOfInProgress?.has(item.id)) {
    score *= PARENT_IN_PROGRESS_BOOST;   // 1.25x
  }
}

Stored priority field is never modified — boost is a transient scoring adjustment only.

tests/database.test.ts

Seven new tests under in-progress boost in computeScore / reSort:

• Direct in-progress boost
• Ancestor-of-in-progress boost (including multi-depth grandparent)
• Non-stacking when item is both in-progress and an ancestor of in-progress
• Blocked ancestor excluded from boost
• priority field unchanged after reSort()
• No ancestor boost when in-progress child is completed

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/graphql
  • Triggering command: /usr/bin/gh gh issue create --repo owner/name --title Item without GitHub mapping --body-file - --verify g/tests/cli/mockworktree bash -bin�� rev-parse g/tmp-worktree-8r9gNT/wt -bin/git -C /tmp/wl-wt-err-rrev-parse /bin/sh bash (http block)
  • Triggering command: /usr/bin/gh gh issue create --repo owner/name --title Item 1 --body-file - g/tmp-worktree-8--import (http block)
  • Triggering command: /usr/bin/gh gh issue create --repo owner/name --title Item 2 --body-file - --allow-empty bin/bash bash -bin�� ls-remote --exit-code bin/bash refs/worklog/datbash r5QQ6/wt bin/bash bash (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Boost in-progress items in sorting algorithm</issue_title>
<issue_description>

Boost in-progress items in sorting algorithm

Apply score multiplier boosts in computeScore() for in-progress items (1.5x) and their ancestors (1.25x) so that epics with active work are not buried in sortIndex-based views.

Problem statement

When a child work item is marked in_progress, its parent (and ancestors) remain at their base priority in sort ordering. This means epics and parent items with active work can be buried below unstarted items of equal or lower priority, reducing visibility of active work across all sortIndex consumers (wl list, TUI, and any future views).

Users

• Human operators reviewing work item lists to understand project status and identify where active work is happening.
  • As an operator, I want parent items with in-progress children to sort higher so I can quickly see which epics have active work without scanning the entire list.
• AI agents that rely on sortIndex ordering to understand project context and prioritize related work.
  • As an agent, I want the sort order to reflect where active work is happening so I can make better decisions about related items.

Success criteria

1. Items with status in_progress receive a score multiplier boost (e.g. 1.5x) in computeScore() during reSort().
2. All ancestors (parent, grandparent, etc.) of an in_progress item receive a score multiplier boost (e.g. 1.25x) in computeScore() during reSort(), applied at a flat rate regardless of depth.
3. Boosts do not stack: if an item is itself in_progress, only the direct in-progress boost applies (not the ancestor boost on top of it).
4. Items with blocked status do not receive any in-progress boost (the existing -10000 blocked penalty remains dominant).
5. The stored priority field is never modified — boosts apply only to the computed score used for sortIndex assignment.
6. Existing tests continue to pass; new tests cover: direct in-progress boost, ancestor-of-in-progress boost, non-stacking behavior, blocked items excluded from boost, and edge cases (all children closed, multiple in-progress children at different depths).

Constraints

• Sorting only: The boost applies in computeScore() / reSort(). The wl next selection pipeline (findNextWorkItemFromItems) continues to filter out in-progress items as before. The indirect effect of changed sortIndex values on wl next ordering is acceptable.
• Hardcoded defaults: Boost multiplier values are hardcoded constants (not configurable via CLI or config file). Configurability can be added later if needed.
• No stored field changes: The boost is a transient scoring adjustment. No new database columns or schema changes are required.
• Descendant traversal: Determining whether an item has an in-progress descendant requires traversing down the child hierarchy. A max-depth guard must be applied to prevent infinite loops if circular parent references exist.

Existing state

The scoring algorithm lives in src/database.ts:

• computeScore() (lines 1065-1138) computes a numeric score as a weighted sum of priority (1000/level), blocks-high-priority boost (500), age (10/day), effort (20), recency (100), and blocked penalty (-10000). There is currently no status-based boost for in-progress items.
• reSort() (lines 280-288) calls computeScore() for all active items and reassigns sortIndex values.
• computeEffectivePriority() (lines 840-906) computes effective priority via inheritance from dependency edges and parent-child relationships. This is used by the wl next selection pipeline but not by computeScore().

The wl next command (src/commands/next.ts) auto-calls reSort() before selection, so score changes will indirectly affect wl next recommendations.

Desired change

Modify computeScore() in src/database.ts to apply two new score multipliers:

1. Direct in-progress boost: If the item's status is in_progress (and not blocked), multiply the final score by a hardcoded constant (e.g. IN_PROGRESS_BOOST = 1.5).
2. Ancestor-of-in-progress boost: If the item has any descendant (child, grandchild, etc.) with status in_progress, and the item itself is not in_progress and not blocked, multiply the final score by a constant (e.g. PARENT_IN_PROGRESS_BOOST = 1.25). Apply the same multiplier regardless of ancestor depth.
3. Non-stacking rule: If an item qualifies for both boosts, apply only the direct in-progress boost (1.5x).

The descendant check will need to traverse children (and their children) to detect any in-progress descendant. This may require access to the item store within computeScore() or a pre-computed lookup of items with in-progress descendants.

Key files likely affected:

• src/database.ts — computeScore(), possibly n...

• Fixes Boost in-progress items in sorting algorithm #785

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.