TaskManager: queue, cancel, and next_for(pawn) selection #67

New issue

Closed

opened 2026-09-07 20:37:18 +01:00 by liamjd · 0 comments

liamjd commented

2026-09-07 20:37:18 +01:00

Owner

Part of milestone #5. Depends on #66.

The queue every user action feeds, and the thing an idle pawn asks for work. Pure logic node, no rendering, headless-testable with stub tasks.

API:

add(task) -> int assigns id and creation sequence, emits task_added
cancel(id), complete(id) with matching signals
next_for(pawn) -> Task: highest priority first, then oldest first; skips tasks whose can_start(ctx) is false and marks them BLOCKED; returns null when nothing is workable
claim(id, pawn) / release(id) so a pawn that fails mid-task hands it back as PENDING
all() and by_status() for the debug panel

Design notes:

Resolve priority through a single function (task priority combined with a global policy object) rather than reading task.priority directly. The design docs require an Emergency Protocols override that reprioritises all labour in one action; that becomes a swap of the policy, not a rewrite of selection.
BLOCKED tasks are re-evaluated on the next next_for call, not left blocked forever; a later issue can add event-driven unblocking.
Signals live on the manager (or on GameState if other systems need them without a reference; decide and note in the PR).

AC:

Unit tests: ordering by priority then age; blocked tasks skipped and marked; null when empty or all blocked; claim/release round trip; cancel removes from selection

Part of milestone #5. Depends on #66. The queue every user action feeds, and the thing an idle pawn asks for work. Pure logic node, no rendering, headless-testable with stub tasks. API: - `add(task) -> int` assigns id and creation sequence, emits `task_added` - `cancel(id)`, `complete(id)` with matching signals - `next_for(pawn) -> Task`: highest priority first, then oldest first; skips tasks whose `can_start(ctx)` is false and marks them BLOCKED; returns null when nothing is workable - `claim(id, pawn)` / `release(id)` so a pawn that fails mid-task hands it back as PENDING - `all()` and `by_status()` for the debug panel Design notes: - Resolve priority through a single function (task priority combined with a global policy object) rather than reading `task.priority` directly. The design docs require an Emergency Protocols override that reprioritises all labour in one action; that becomes a swap of the policy, not a rewrite of selection. - BLOCKED tasks are re-evaluated on the next `next_for` call, not left blocked forever; a later issue can add event-driven unblocking. - Signals live on the manager (or on `GameState` if other systems need them without a reference; decide and note in the PR). AC: - Unit tests: ordering by priority then age; blocked tasks skipped and marked; null when empty or all blocked; claim/release round trip; cancel removes from selection

liamjd added this to the Task management for pawns milestone

2026-09-07 20:37:18 +01:00

liamjd added the

enhancement

label

2026-09-07 20:37:18 +01:00

liamjd referenced this issue

2026-09-07 20:37:19 +01:00

Parent and child tasks: blocking and cascading cancel #68

liamjd referenced this issue

2026-09-07 20:37:20 +01:00

Specialisation weighting in task selection #69