What happens
A leader can set a task to in_progress with owner: alice, and the update succeeds and persists, but idle Alice receives no task prompt. The only delivery path auto-claims unowned pending tasks, so the newly owned in-progress task can never be auto-claimed or delivered.
Deterministic reproduction
Evidence branch: https://github.com/netbrah/qwen-code-upstream-pr/tree/agent-team-red-repros
Commit: c3be5500d9
cd packages/core
npx vitest run src/tools/team-lifecycle.test.ts
Expected current baseline: 6 controls pass and one intentional assertion fails. The test:
- Creates and reserves a task as
in_progress before Alice exists, proving auto-claim cannot consume it.
- Spawns idle Alice and verifies she has no queued task prompt.
- Calls the real leader
TaskUpdateTool with status: in_progress, owner: alice.
- Waits for exactly one task prompt and receives none.
A separate control proves ordinary leader-to-idle-teammate delivery works through SendMessageTool.
Root-cause boundary
TaskUpdateTool persists the requested status/owner update and triggers task listeners. TeamManager then scans only pending, unowned tasks; it constructs a task prompt only after claimTask() succeeds. A manually assigned in_progress task is intentionally excluded from that route, with no direct dispatch path.
Expected behavior
Current leader-facing instructions say TaskUpdate ownership assigns work to an idle teammate. That documented dispatch behavior should enqueue one task prompt for the selected idle teammate.
A product redesign could instead reject a non-dispatchable assignment transition, but it would need to update that leader-facing contract and retain regression coverage. It must not report persistence success for a task that has no delivery path.
Scope
This is separate from blank task-list filtering and from #9276 ordinary-message/shutdown discriminator issue. It is a manual assignment lifecycle defect.
Related to #9276 and #9281. Additional related evidence issues will be linked here.
What happens
A leader can set a task to
in_progresswithowner: alice, and the update succeeds and persists, but idle Alice receives no task prompt. The only delivery path auto-claims unownedpendingtasks, so the newly owned in-progress task can never be auto-claimed or delivered.Deterministic reproduction
Evidence branch: https://github.com/netbrah/qwen-code-upstream-pr/tree/agent-team-red-repros
Commit:
c3be5500d9cd packages/core npx vitest run src/tools/team-lifecycle.test.tsExpected current baseline: 6 controls pass and one intentional assertion fails. The test:
in_progressbefore Alice exists, proving auto-claim cannot consume it.TaskUpdateToolwithstatus: in_progress, owner: alice.A separate control proves ordinary leader-to-idle-teammate delivery works through
SendMessageTool.Root-cause boundary
TaskUpdateToolpersists the requested status/owner update and triggers task listeners.TeamManagerthen scans onlypending, unowned tasks; it constructs a task prompt only afterclaimTask()succeeds. A manually assignedin_progresstask is intentionally excluded from that route, with no direct dispatch path.Expected behavior
Current leader-facing instructions say
TaskUpdateownership assigns work to an idle teammate. That documented dispatch behavior should enqueue one task prompt for the selected idle teammate.A product redesign could instead reject a non-dispatchable assignment transition, but it would need to update that leader-facing contract and retain regression coverage. It must not report persistence success for a task that has no delivery path.
Scope
This is separate from blank task-list filtering and from #9276 ordinary-message/shutdown discriminator issue. It is a manual assignment lifecycle defect.
Related to #9276 and #9281. Additional related evidence issues will be linked here.