Handing a Task Back: Preconditions and an Audit Card for Releasing to the Queue

Returning a task to the pool sounds simple, yet a careless release can lose notes, hide half-done work or let a stale click undo someone else's claim. This article proposes release preconditions and an audit card. It is a conditional design recommendation only.

Release preconditions

A release is accepted only if all of these hold at the moment of the write:

The requester is the current owner, and the version matches what they saw.
The task state is claimed or started, not done.
A reason from a short list is supplied (for example: blocked on missing information, out of scope for my role, ending my shift). Free text is optional.
A handoff note is present when state is started.
Any external action in progress is recorded as completed, not completed or unknown.

If an action is unknown, the task returns as needs_check, never as plain queued, and nobody should repeat that external write automatically.

Audit card

One record per release: task id, previous owner, state at release, version before and after, reason, note, external action status, timestamp. Keep it append-only so later edits do not rewrite it.

Branches

Owner releases a claimed, unstarted task: back to queued, owner cleared.
Owner releases a started task with a note: back to queued with the note attached and a started-before flag.
Unknown external action: needs_check, flagged for a person.
Non-owner attempts release: rejected; a supervisor path may exist but is a separate decision.
Task was already requeued by lease expiry: the release changes nothing and reports it.

Worked example

Operator Dana holds three tasks.

T1 claimed, not started: released with reason out of scope. Becomes queued.
T2 started, note written, external action completed: released. Becomes queued with note.
T3 started, an external send timed out: released. Becomes needs_check.

Then Dana presses release on T1 again from an old tab. The version no longer matches, zero rows change, and the user is told it was already released.

Count: 3 tasks, 3 audit cards, 2 queued, 1 needs_check, 1 stale request rejected without a new card.

Stop conditions

Reject the release if any precondition cannot be evaluated, for example the version cannot be read. Pause the release feature if audit writes fail, because a release without a card should not happen. Treat these checks as layered constraints; they cannot prevent every mistaken release.

Proposed acceptance tests (proposed, not performed)

Release by non-owner: expect rejection.
Release of a started task without a note: expect rejection.
Release with unknown external status: expect needs_check.
Double release: expect one card and one state change.
Audit write failure: expect the release to roll back.
Release of a done task: expect rejection.