[Bug]: Usage-limit auto-resume restarts delegated children of settled parents, which can reactivate those parents#27944

Note

Written by Claude Opus 5.5 on behalf of the reporter, from read-only inspection of their local projections and of the code on main. Not reproduced in a fresh run.

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Have a parent thread with delegated child tasks that stopped on a usage limit, with Resume after usage limits off.
Settle the parent. The children stay unsettled, because settling does not propagate to them.
Turn on Resume after usage limits at any time after the children's reset.

Expected behavior

Work the user has put away stays put. A child whose parent is settled is not resumed by the sweep, and the settled parent is not reactivated as a result.

Actual behavior

The sweep arms and resumes each child, because it only looks at the child's own settlement state (worker, candidates query). lineage is not consulted at either point.

When a resumed child finishes, the existing delegated-completion wake (#4499) can then pull a settled parent back to active and start a new run on it. That wake is intended for normal delegation. The problem here is that nobody asked for the resume that triggered it.

Impact

Provider allowance is spent on abandoned work, and settled threads reappear as active with no user action. It happens in one burst when the setting is enabled.

Observed on 2026-10-31, within about 35 seconds of enabling the setting:

11 children of one parent settled about 28 hours earlier were resumed. Their failures predated the settle, and their resets were 26 to 33 hours overdue.
Three other settled parent threads were reactivated by child completion wakes (settledOverride null with a fresh unsettledAt). Each started a new run, which failed in 1 to 3 seconds on that provider's own limit.

Version or commit

Observed on desktop 0.1.5. The checks linked above are unchanged on main at 2b15ba077d.

Environment

macOS desktop app. The logic is server-side and not platform-specific.

Logs or stack traces

The local event log and command receipts were empty, so the order comes from projections: limit-resume: message ids, settledAt/unsettledAt, and run timestamps. The cause of the parent reactivation is inferred from those records and the wake message text.

Workaround

Before enabling the setting, archive or settle the limited children individually. Turning the setting off does not cancel recoveries that are already armed.

#21716 and #21735 cover the age of a fresh arm, which is scoped to age only. A 24-hour limit would have stopped this burst, but not a child whose reset is under 24 hours old with a settled parent.
#18928 is the inverse: auto-settle cancelling a pending resume.