← graph

fold-unclaim-semantics

Fold unclaim semantics into wg reset (clear claimed_by)

Metadata

Statusdone
Assignedagent-899
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Created2026-04-28T00:55:02.494400573+00:00
Started2026-04-28T00:56:23.925653145+00:00
Completed2026-04-28T01:09:25.149836172+00:00
Tagseval-scheduled
Eval score0.77
└ blocking impact0.90
└ completeness0.90
└ constraint fidelity0.85
└ coordination overhead0.92
└ correctness0.82
└ downstream usability0.85
└ efficiency0.85
└ intent fidelity0.78
└ style adherence0.80

Description

Description

Source: companion observation in /home/erik/workgraph/bug-dispatcher-poll-interval-too-slow.md ('Related observation' section).

wg reset --also-strip-meta resets task status but does NOT clear the claimed_by field. Result: after resetting 9 tasks, all 6 ready tasks were still claimed by dead agents from the previous run, so even when the dispatcher ticked it refused to spawn. User had to manually wg unclaim each one. From the user's POV this looked identical to the dispatcher-poll bug ('I reset and resumed, why is nothing happening?').

Fix

When wg reset resets a task to open, it should also clear claimed_by (and any other claim-related metadata: claim_expires_at, agent worktree pointers, etc. — audit what wg unclaim clears and mirror it). A task being reset should be ready for a fresh dispatcher pickup with no further hand-holding.

This is the 'do the obvious thing' fix. The user's quote: '...probably the right call — when you reset a task you almost certainly want it ready to be re-claimed.'

Edge cases to think about

  • If the task is currently in-progress with a live agent attached, what does reset do? (Probably: refuse, or kill-agent-then-reset with explicit flag — match existing wg reset behavior, just add unclaim to whatever path actually mutates state.)
  • Does wg reset already have a flag like --keep-claim for advanced users? If yes, preserve it as an opt-out. If not, don't add one preemptively.
  • Status filter: only relevant for resets that move status backwards to open / ready. Resetting to other statuses (if that's a thing) probably shouldn't auto-unclaim.

Validation

  • Failing test first: claim a task (set claimed_by), wg reset <id>, assert claimed_by is None
  • Failing test: wg reset --also-strip-meta <id> clears claimed_by AND the meta it strips today (regression check)
  • Failing test: reset on a task with no claim is a no-op for the claim field (doesn't crash)
  • Live smoke: claim 3 tasks, wg reset them, run wg ready → all 3 appear ready (no stale claims blocking)
  • Live smoke: dispatcher running at 5s poll → reset tasks get spawned on next tick without manual wg unclaim
  • cargo build + cargo test pass with no regressions

Depends on

Required by

Log