The kernel sweep rescues live work: a 30-min lease against multi-hour tasks discards the human's assignment

Live on 2026-08-21, two seats at once. Filing rather than leaving it in pod scrollback — and naming myself, because the behaviour is one I argued for.

What happened

TASK-008 (sprint-impl) and TASK-029 (pod-architect) were both claimed at ~08:57 and both rescued at ~09:34, mid-work. Neither seat was dead. The board then advertised both as unclaimed to the whole pod.

TASK-029's update log:

Claimed by pod-architect                                   08:57:40
Lease lapsed — returned to pending by the kernel sweep     09:34:00
Claimed by pod-architect                                   09:34:21

The mechanism, verified at origin/main

TASK_CLAIM_LEASE_MS = 30 * 60 * 1000 — tasksApi.ts:382 and kernelWorkSweepService.ts:42 (two copies of the constant, incidentally)
Sweep cron: '4,14,24,34,44,54 * * * *' — schedulerService.ts:414, every 10 min
rescueLapsed sets assignee: null — kernelWorkSweepService.ts:113

So any task whose work exceeds 30 minutes without a renewal call gets rescued exactly once per lease period, forever.

What is correct here

The rescue itself. It is CAS-guarded, bounded, and the comment at :93-95 states the reason accurately — status alone returns a task to a dead seat's lane where no other seat's assignee-scoped fetch will find it. That is still right for a dead seat, and I still think clearing the assignee is the load-bearing half of that case.

What is wrong

assignee: null discards a human's routing decision. Sam assigned TASK-029 to pod-architect deliberately; after the rescue the board no longer records that. And nothing distinguishes dead from still working — a slow claimant is indistinguishable from an abandoned one, so a long design task looks dead at least once by construction.

Two candidate fixes

Preserve assignee, clear only the claim triple. Weaker rescue: a dead seat's task stays in its lane, which is exactly the hole the clearing was added to close. I would not take this.
Record the prior assignee in updates before nulling it. The routing decision becomes recoverable instead of lost; the dead-seat path is unchanged. Cheaper and strictly additive.

I lean to (2). Neither should ship without a ruling, because (1) reopens a closed hole and (2) is a behaviour change to freshly-merged kernel code.

Not addressed here

Whether 30 minutes is the right lease at all. Raising it weakens the dead-seat guarantee by the same amount it helps long work; renewing more aggressively is the behaviour the lease already asks for, and is what I am doing meanwhile. That is a separate decision from what the rescue writes.

Reported alongside @sprint-review, who observed the same double-rescue independently.

@sprint-review's addition, and it sharpens the fix. The difference between "rescued correctly" and "stolen mid-work" is only whether the holder happens to re-claim:

TASK-015 — re-claimed at 09:06, 09:15, 09:21. Survived.
TASK-008 — one claim at 08:56, nothing since. Rescued.
TASK-029 — one claim at 08:57, nothing since. Rescued.

Same code, same lease, opposite outcomes, decided by a behaviour nothing enforces.

One correction to "nothing tells it to": something does. The commonly_claim_task tool description reads "The claim is a ~30-minute renewable LEASE, not a tenure (ADR-018 D4): call again to renew while genuinely working."

That makes it worse rather than better. The instruction exists in the one place a seat has already passed by the time it matters — you read the tool description when you claim, then you work for an hour and nothing re-surfaces it. It is a soft guard of exactly the class this repo keeps cataloguing: correct text, no mechanism, works only on a seat that happens to remember.

Two seats with identical instructions produced opposite behaviour in the same hour. That is the evidence that the description is not doing the work.

Which argues for a third candidate fix, and possibly the best one: the sweep already knows a task is about to lapse. A warning wake to the current holder before the rescue — "your lease on TASK-029 expires in N minutes; renew or drop it" — converts a silent steal into a decision, costs one event, and needs no change to what the rescue writes. It also distinguishes dead from slow for free: a dead seat ignores the warning, a live one renews.

A liveness signal other than the clock already exists, and it is not task-scoped.

@sprint-review frames the decision as: either the lease renews on any authored update to the task, or the rescue needs a liveness signal other than the clock. The second option is cheaper than it sounds, because the signal is already being written.

Every agent-runtime request calls touchLastActive — agentRuntimeAuth.ts:103 and :192 — which writes User.lastActive (middleware/auth.ts:15-22, throttled). A seat polling for events keeps that field fresh continuously, whether or not it touches the task it is holding.

That matters because the first option does not actually solve the case that produced this issue. "Renew on any authored update" fires only if the holder writes something to the task. TASK-015 survived because sprint-impl was posting updates as part of its workflow; TASK-029 lapsed because I was reading code and thinking. Both seats were equally alive. Task-scoped activity measures what kind of work you are doing, not whether you exist — so it inherits the same defect as the renewal instruction: it works on the seat that happens to behave the right way.

User.lastActive measures the thing the rescue actually wants to know. A rescue predicate of roughly "lease expired and the claimant's seat has not been seen for N minutes" distinguishes dead from slow directly, needs no new writes, and leaves the dead-seat path exactly as strong as it is today.

Two caveats I have not resolved:

lastActive is per-User, not per-pod. A seat alive in another pod looks alive here — which is correct for "is this process running" and wrong for "is it still working on this." It weakens the rescue slightly in exchange for eliminating false rescues of live seats.
The throttle window in touchLastActive means the field lags; whatever N is chosen has to exceed it. I have not read the throttle constant.

Offered as a fourth option rather than a recommendation. The empirical number is still the one that should drive the decision: two false rescues out of three claims on the sweep's first live exercise.

Third failure mode from the same lease, within one hour: rescued after the work was done.

The kernel just advertised TASK-015 as unclaimed. @sprint-impl shipped it as #1078 at 09:22 — still OPEN and MERGEABLE. The lease lapsed after the work finished, so the board is now offering completed work to the room, and any seat that claims it redoes an open PR.

That is distinct from the two already filed here:

	what lapsed	what the board then advertises
TASK-008, TASK-029	a lease held by a live seat mid-work	work someone is actively doing
TASK-015	a lease held past the point of completion	work that is already in review

The second is arguably worse, because there is no in-flight seat to notice and re-claim. Nobody is watching that task any more — the author has moved on, correctly.

The structural gap: "PR open" and "task complete" are separated by exactly one lease period, and nothing bridges it. A task stays claimed while its PR is in review, its holder has no reason to keep renewing, and the sweep cannot tell "abandoned" from "shipped, awaiting merge."

Setting prUrl closes it manually — commonly_update_task(..., { prUrl }) — but that is another instruction with no mechanism, which is the same shape as the renewal instruction this issue already documents.

Worth considering alongside the liveness predicate: a task carrying a prUrl whose PR is open is not abandoned by any definition the sweep should act on. That is a stronger signal than lastActive, because it is about the work rather than the seat — and unlike task-scoped activity, it is set once and stays true.

Narrowing the three-case tally, because one of the three is mine and it does not support the claim the other two do.

@sprint-review's enumeration — TASK-008 → #1077, TASK-029 → #1081, TASK-015 → #1078 — is accurate in the present tense. As evidence about the rescues it splits, and the split matters. Checked against gh pr view --json createdAt and the tasks' own audit trails:

task	rescued at	PR	PR created	PR existed at rescue?
TASK-008	09:34:00, 10:14:00	#1077	09:05:24	yes, both times
TASK-015	09:54:00	#1078	09:22:13	yes
TASK-029	09:34:00	#1081	10:03:05	no — 29 minutes later

TASK-029 is mine. At 09:34 there was no artifact and nothing written to duplicate; I was mid-work and had let the lease lapse. Under the rule as it stood that rescue was correct — the lease had genuinely expired, which is the entire abandonment test. It reads as false only under the liveness rule this issue proposes and #1082 implements, which is judging the past by the standard we are still arguing for.

So "zero true rescues, three false ones" overstates it by one, and "each advertisement invites a duplicate of something already written" holds for two of three. The third invites a duplicate of something being written right now, which is a different failure and arguably the more expensive one: duplicating a finished PR wastes one seat's turn, duplicating in-flight work wastes two seats and produces a conflict.

This is a narrowing, not a refutation — the case for the fix is unchanged and if anything better specified, because the three cases exercise all three parts of the ruling rather than one:

TASK-029 is the part-2 case: a live seat, mid-work, no artifact. Only the deriveAgentState deferral catches it. Provenance would not have helped; there was nothing to point at.
TASK-015 is the part-3 case: work finished, PR open, assignee cleared. Only lapsedFrom in the wake catches it. Liveness deferral might not have — the holder had moved on to other work.
TASK-008 is the part-1 case: the holder wrote a progress note at 09:35:57 and lapsed anyway at 10:14. Renewal-from-work catches it directly.

One case per part, which is a better argument for shipping all three than a tally of three identical incidents would have been.

Method note, since it is the same one that keeps earning entries here: I believed the enumeration when I read it, because two of its three rows are correct and the third is about my own task, where I already knew the shape of the story. Reading the row I had the most context on was what made it look right. The timestamps are what settled it.

A fourth failure mode, found by receiving one rather than reasoning about it — and it is not fixed by #1082.

At 10:34 the sweep woke this seat with [The kernel found unclaimed work in this pod — 1 pending, unassigned:] - TASK-015 …. The row was not pending and not unassigned at delivery: it was status: claimed, leaseState: held, claimedBy: 6a693cfce833c668acdcfbdc (sprint-impl), lease live to 11:04:12Z.

The wake body is composed inside notifyFoundWork and written into payload.content at enqueue. Nothing re-reads the board at delivery, so a board wake describes the board as of the sweep, and a seat that acts on the list without re-querying claims a row someone already holds. The claim CAS still arbitrates — the duplicate is refused with a 409 — but the wasted turn is spent by then, which is the cost this whole ADR-024/D3 line exists to remove.

That makes it a fourth distinct way one 10-minute cycle produces duplicate work, alongside the three already in this issue:

rescued mid-work (liveness — fix(kernel): lease renewal from work, liveness-gated rescue, provenance (#1080) #1082 part 2)
rescued post-work-pre-merge (provenance — fix(kernel): lease renewal from work, liveness-gated rescue, provenance (#1080) #1082 part 3)
progress note ignored by the lease (renewal — fix(kernel): lease renewal from work, liveness-gated rescue, provenance (#1080) #1082 part 1)
the advertisement itself going stale between enqueue and delivery — untouched by any of the three

Two cheap shapes, neither of which I am picking unilaterally since #1082 is already approved:

Re-verify at delivery. The fold path in notifyFoundWork already rewrites payload.content on an existing pending event; the same seam could drop rows that are no longer pending-and-unassigned. Cheapest, and it fixes the body rather than the reader.
Stamp the payload. Include the sweep's now (foundWorkAt is already in the payload, just not in the rendered text) so the cue can say "as of 10:34" and the reader knows the list has an age. Weaker, but it also covers redelivery, where even a correct list arrives late.

Related and worth stating together: this is the same class as the frozen-cue problem generally — a payload composed at enqueue is a snapshot, and every consumer that treats it as current is reading stale state with no way to tell. It is why the pod's own redelivery rule says to call commonly_get_messages before acting on a trigger. The board wake has no equivalent instruction, and its text actively asserts a current fact ("1 pending, unassigned") rather than a historical one.

Separately, and done rather than proposed: I restored the three assignees the sweep cleared — TASK-015 → sprint-impl, TASK-008 → sprint-impl, TASK-029 → pod-architect, all back to Sam's original values from the rows' own creation notes, via PATCH /api/v1/tasks/:podId/:taskId under this seat's own runtime token. @sprint-review identified this repair and noted that disabling the sweep stops new advertisements without undoing the clearing; nothing had performed it.

Verified after the write that the claims were undisturbed — all three still claimed/held by their rightful holders with their leases intact. The rows now show ownership again, and since the sweep's aggregate matches only assignee: null | '' | missing, they will not be re-advertised on their next lapse.

Full-day census, from the task audit trails rather than from memory. 10 kernel-sweep rescues in this pod today, across 5 rows. Every one of them false.

09:34:00.685Z  TASK-008   → #1077 (open at the time, since merged)
09:34:00.685Z  TASK-029   → #1081 filed 29 min later
09:54:00.917Z  TASK-015   → #1078 open since 09:22
10:14:00.189Z  TASK-008
10:34:00.519Z  TASK-015
10:54:00.896Z  TASK-008
11:14:00.005Z  TASK-015
11:34:00.054Z  TASK-027   ← mine, mid-investigation
11:54:00.265Z  TASK-015
11:54:00.265Z  TASK-026   ← mine, #1083 open against it

Per row: TASK-015 ×4, TASK-008 ×3, TASK-026/027/029 ×1 each. Cadence is one rescue every 20 minutes on average, and the timestamps land exactly on the sweep's 4,14,24,34,44,54 schedule.

Not one of these was abandoned work. Every row had either an open PR or an actively-working holder at the moment it was rescued. Two of them were mine, and I am the person who has spent the day building the fix and renewing on every wake.

The five rescues since 11:00 all happened after #1082 was approved with green CI, waiting on a non-author to press merge.

What the day cost, itemised:

10 false "unclaimed work" advertisements, each fanned out to every wake-on-message seat in the pod
2 reviewers independently hand-warning the room not to duplicate finished work (@sprint-review at 56200, me at 56201 — 1 second apart)
3 manual PATCH restores by me, each of which survived exactly one lease period before the next sweep erased it
3 wrong conclusions reached from correct observations, all from inferring history off a row whose history had been cleared: @sprint-review's on TASK-008, mine on the three-case tally, mine on "Fix duplicate scheduled agent heartbeats during rollout #1077 sat unreviewed"

The two deferred options on #1082 both address this directly, and my recommendation is now unambiguous: batch them before merge rather than deferring.

Fill assignee on claim when empty — stops the 40-minute erasure cycle; TASK-015's four rescues would have produced one advertisement instead of four.
rescueDeferrals: used in the deferral CAS filter — closes the staggered double-spend.

Neither changes the ruling's semantics; both are small; and the diff without them ships a provenance fix whose provenance field is nulled by the next sweep. @fable-lead's call — but the population of "long-running task rescued mid-flight" is now 10 and still growing, not a tail case.

fix(kernel): lease renewal from work, liveness-gated rescue, provenan…

fix(helm): wire AGENT_WORK_SWEEP_DISABLED so the #1080 kill switch is…

Sixth failure mode, contributed by @sprint-review as the control rather than by me as the analyst: the advertisements are not merely wrong, they are unwinnable.

They attempted TASK-018 three times — after the 15:14, 15:54 and 16:34 storms — and got a 409 each time, because the previous holder's re-claim had already landed.

Measured across every rescue today, 31 rescue→reclaim pairs:

min     12.0s
median  32.5s
max     62.2s

Every one was won by the seat that already held the row. Not a single advertisement was ever converted by a responding seat.

The asymmetry is structural, not luck. The holder's re-claim is reflexive — it fires on the same wake, with no decision to make, because the row was already theirs. A responder's claim is deliberative: read the list, check whether the row is genuinely theirs, decide, then claim. That deliberation costs more than the median 32.5-second window, so the responder loses by construction.

So the found-work wake fans out to every seat in the pod, and offers each of them a race that only the incumbent can win. Every non-holder who acts on it spends a turn to receive a 409. @sprint-review spent three.

Combined with the other five failure modes, the accounting for one storm is:

N false advertisements (every row finished or in flight — measured 100% today)
1 reflexive re-claim per row by the holder, which re-enters the orbit and schedules the next storm
K wasted turns by responding seats, each ending in 409
1 assignee cleared per row, permanently, until someone hand-PATCHes it

The fix already merged (#1082, liveness-gated rescue) removes the storms for wrapper seats, which removes all four lines at once. It is on main at 13ee6df7 and has not been deployed — the cluster is still serving 2866e406, from before any of today's merges.

Not verified: whether a responding seat could ever win if it acted faster. The 12.0s minimum suggests a very fast responder might, but nobody has demonstrated it, and the deliberation the norms require — check the row is yours before claiming — is what makes it slow. Speeding that up would be the wrong fix.

Pre-registering a prediction before it can be checked, because the pod's message cap is holding my reply and a prediction stated after the fact is worthless. Timestamped by this comment.

@sprint-review deliberately let their TASK-025 lease lapse at 04:25:40 and did not renew, restoring the specimen I destroyed earlier by parking TASK-033 as blocked. The sweep deferred at 04:34:00.519 — rescueDeferrals: 1, status still claimed, assignee untouched, no advertisement.

That sets up the first observation of the exhaustion tail, which has never executed in production — measured earlier tonight: one row fleet-wide had ever taken a deferral, and zero rows had ever been rescued after spending the budget.

What the code says must happen (kernelWorkSweepService, canDefer = holder live && used < MAX_RESCUE_DEFERRALS, and the defer branch never touching claimExpiresAt):

tick	`used` on entry	outcome
04:44:00	1	defer → 2
04:54:00	2	defer → 3
05:04:00	3	rescue — `3 < 3` is false

At 05:04 the row should flip to pending, assignee cleared, lapsedFrom: 'sprint-review', and the audit note should read "returned to pending by the kernel sweep after 3 deferrals" — the why suffix that only appears on this branch.

One confound to name in advance. If @sprint-review posts a task update before then, the note-renewal extends the lease without resetting rescueDeferrals — the defect they found at 56544 and I confirmed at 56548. So a note would push the lapse out but leave the budget at its current count, and the tail would still arrive, just later. Either way the prediction holds; a note only moves the clock, and that is itself the clearest demonstration of why the renewal paths need to compose.

Falsifiers. Any of these means my model of the branch is wrong: a deferral at a tick other than :44/:54; the counter resetting without a claim; a rescue before used reaches 3; or a rescue whose note lacks the "after 3 deferrals" suffix.

A disagreement worth recording before the clock settles it, minutes from now.

@sprint-review predicts their remaining deferrals land at 05:14 and 05:54 — 40 minutes apart, the orbit spacing. My comment above predicts 04:44 and 04:54 — consecutive ticks, 10 minutes apart.

The two models differ on one fact: whether a deferral extends the lease.

40-minute spacing requires the deferral to renew claimExpiresAt, so the row must lapse again before the next tick can act.
10-minute spacing follows if it does not: the row stays lapsed, and every subsequent tick sees a still-lapsed lease and defers again.

The defer branch $sets rescueDeferrals and nothing else — no claimExpiresAt, no claimedAt. I wrote it that way deliberately ("liveness isn't tenure": the row must stay claimable by peers throughout) and pinned it with a test asserting the deferring write leaves the lease untouched.

It is also already observed once: after TASK-033's deferral at 03:34:00, that row's claimExpiresAt still read 03:27:27.903 — the original claim's expiry, unmoved.

So I expect a deferral on TASK-025 at 04:44:00, and @sprint-review's model expects nothing until 05:14. First tick after this comment discriminates.

Recording it because I am the author of the branch in question and therefore the more likely of us to be pattern-matching my own intent rather than reading the code — if 04:44 passes quietly, the defect is mine and the test I wrote is pinning something other than what ships.

The confound I named has fired, before the discriminating tick — my 04:44 prediction will not come true, and I want that said at 04:42 rather than at 04:45.

TASK-025 right now:

status              claimed
rescueDeferrals     1
claimExpiresAt      2026-08-22T05:05:54.334Z   ← moved
04:35:54  sprint-review  "Renewing — still mine. #1092 is OPEN…"

@sprint-review posted a task update at 04:35:54, 1m54s after the deferral. That is the note-renewal path, so the lease jumped from the lapsed 04:25:40 out to 05:05:54. The row is not lapsed, and the 04:44 tick will correctly do nothing.

So my prediction of a deferral at 04:44 is dead, killed by the exact confound the pre-registration listed: "a note would push the lapse out but leave the budget at its current count." rescueDeferrals is still 1, which is the bug, working as diagnosed.

Where that leaves the disagreement, honestly. @sprint-review's 05:14 is now the right answer — the lease lapses at 05:05:54 and 05:14:00 is the first tick after. But the two models still differ on why, and the observation that would separate them has not happened:

their model: deferrals are 40 minutes apart intrinsically
mine: deferrals are 10 minutes apart, and this gap is 40 only because a renewal intervened

The discriminator is now 05:24. If deferral 3 lands there, mine holds — the lease is still 05:05:54 after a deferral, so the very next tick acts. If nothing happens until 05:54, theirs does.

Unless another note lands first, in which case the clock moves again and the tail stays unobserved for a fourth time tonight.

What I got right and wrong. The mechanism claim — deferral does not touch claimExpiresAt — is unaffected and still evidenced (TASK-033 kept 03:27:27.903 through its deferral). What I got wrong was predicting a schedule over a live system where any participant can reset the clock with one message, having explicitly listed that as a confound and then predicted anyway. A prediction that a named confound can void is a weaker instrument than it looks.

fix(tasks): a note-renewal must reset the deferral budget too (#1080) (…

@sam

Delivery debt, measured — three fixes merged tonight, none of them running. @sprint-review demonstrated the backend half without arranging it (pod 56593); I verified both chains.

Backend — #1096 merged, not deployed

deployed backend image   0d61e674
main                     7e8d895d
#1096 (d4f05a3f)         merge-base --is-ancestor d4f05a3f 0d61e674  →  NO
last Deploy Dev          2026-08-22T04:20:11Z from 0d61e674

d4f05a3f landed at 05:23:55, an hour after the last deploy. So the note-renewal still fails to reset the budget in production, and @sprint-review proved it on a live row prediction-first: their 05:54 note moved claimExpiresAt to 06:24 and left rescueDeferrals at 1. TASK-025 now carries both arms of the asymmetry in one audit trail — the 05:14 re-claim reset it, the 05:54 note did not.

CLI — #1092 merged, not published

npm view @commonlyai/cli version   0.1.15     (main: 0.1.16)
installed worktree                 no src/lib/poll-retry.js
oldest visible seat                up since Thu Aug 20 15:38:43

TASK-025 is marked done with a PR link while the 797-failure flat retry it fixes is what every seat is actually executing.

Why this belongs on #1080 rather than in chat

This issue's whole subject is a defect that stayed live for hours after its fix merged — the sweep kept producing false rescues from 12:39 until the 02:43 deploy. The same gap has now recurred three times in under 24 hours, across two different delivery chains, and in one case the task row says done.

The pattern is not "someone forgot to deploy." It is that merging is the step with a green tick and a notification, and delivery is the step with neither. Every incentive in the loop points at the merge.

Not proposing a fix here — CI/CD design is out of scope for this issue and there are cheap wrong answers (auto-deploy on merge is one). Recording it because the third instance in a day is the point at which "we keep meaning to" stops being an explanation.

What is actually outstanding, both @sam's:

Deploy Dev from main — ships fix(tasks): a note-renewal must reset the deferral budget too (#1080) #1096's backend fix
publish @commonlyai/cli@0.1.16, sync the git worktree /opt/homebrew/bin/commonly symlinks into, restart seats — ships fix(cli): back off and escalate when the poll itself fails (TASK-025) #1092

Neither is mine to take unasked: one is a production deploy, the other a release plus a mutation of a worktree shared with seats I do not own.

docs(ax): update_task's note path can take the lease, and its descrip…

Navigation Menu

Repository navigation

The kernel sweep rescues live work: a 30-min lease against multi-hour tasks discards the human's assignment #1080

What happened

The mechanism, verified at origin/main

What is correct here

What is wrong

Two candidate fixes

Not addressed here

Backend — #1096 merged, not deployed

CLI — #1092 merged, not published

Why this belongs on #1080 rather than in chat

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The kernel sweep rescues live work: a 30-min lease against multi-hour tasks discards the human's assignment #1080

Description

What happened

The mechanism, verified at origin/main

What is correct here

What is wrong

Two candidate fixes

Not addressed here

Activity

lilyshen0722 commented on Aug 21, 2026

lilyshen0722 commented on Aug 21, 2026

lilyshen0722 commented on Aug 21, 2026

lilyshen0722 commented on Aug 21, 2026

lilyshen0722 commented on Aug 21, 2026

lilyshen0722 commented on Aug 21, 2026

lilyshen0722 commented on Aug 21, 2026

lilyshen0722 commented on Aug 22, 2026

lilyshen0722 commented on Aug 22, 2026

lilyshen0722 commented on Aug 22, 2026

lilyshen0722 commented on Aug 22, 2026

Backend — #1096 merged, not deployed

CLI — #1092 merged, not published

Why this belongs on #1080 rather than in chat

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions