Send back the delivery, keep the task: a concrete rework loop

This worked handoff uses a synthetic example.

A rejected delivery does not automatically mean a new task is needed. If the requested outcome is unchanged and the same runner can correct the problem, opening another ticket splits the acceptance criteria from the evidence that failed them.

Suppose the task is to preserve the order of records in a CSV export. An agent-assisted patch sorts them alphabetically instead. The output looks tidy, but it violates the original contract. The useful review response names that mismatch and requests proof of correction on the existing task.

Write the rejection against a criterion

Criterion C1: exported rows retain input order.
Observed mismatch: the implementation sorts by display name.
Example input IDs: [42, 7, 19]
Required output IDs: [42, 7, 19]
Rework: remove sorting from this export path; preserve field escaping.
Proof: add an order-preservation assertion and rerun the existing suite.
Scope: no new ordering preference or export UI changes.

This is concrete enough for the runner to reproduce. It does not require guessing what “wrong ordering” means, and it does not expand the task into a configurable sorting feature.

Choose the transition that matches ownership

In Wagglet's workflow, sending a delivery back returns the task to Claimed with the same runner. Reopening returns it to Open and clears the claim. Both preserve earlier evidence, but they make different ownership decisions.

Delivered attempt A
  -> review: C1 failed, preserve input order
  -> send back: same runner, rework attempt
  -> corrected implementation + new evidence
  -> Delivered attempt B
  -> reviewer checks C1 and regression coverage
  -> accept, or request a specific remaining correction

Keep the old report available for context. Make clear that it is no longer the standing answer. Otherwise, a reviewer can accidentally inspect the earlier screenshot or test result while reading the corrected implementation.

Give the agent a bounded rework brief

The human author or reviewer prepares the correction request. The runner executes it with their own authorized tools. The agent receives the current task context and the review feedback, then proposes and checks the repair. A qualified reviewer judges the new evidence rather than accepting the agent's confidence as proof.

For the synthetic export example, a small regression fixture can make the correction visible:

const input = [{ id: 42 }, { id: 7 }, { id: 19 }];
const expectedIds = [42, 7, 19];
// Wire this assertion to the real export-and-parse path in your test suite.
// assert.deepEqual(parseCsv(exportCsv(input)).map(r => Number(r.id)), expectedIds);

The commented assertion is an integration instruction, not a runnable claim about functions supplied by this post. Use the actual serializer and parser in the repository. A test that merely copies the input array would not exercise the defect.

Report the correction by criterion

The new delivery should identify the tested revision, the removed ordering behavior, the regression assertion, and the actual run result. It should also say whether existing escaping checks ran. Preserving order while breaking quoted fields is not an acceptable correction.

A compact report can use three sentences: “C1 is addressed by removing the sort in the export path. The new test sends IDs 42, 7, and 19 through the serializer and verifies their parsed order. The attached run output and diff refer to the recorded revision.” Only use those sentences once the described work actually exists.

Know when separate work is justified

If review reveals a new requirement, such as a user-selectable sort order, the author should decide whether it belongs in the current contract. Do not quietly add it to the repair. Likewise, if the current runner lacks the required access or expertise, reopen for a new authorized runner rather than leaving ownership ambiguous.

Human supervised AI execution benefits from this distinction. Rework preserves the original outcome and corrects the evidence or implementation. New work changes the outcome. Keeping that boundary explicit makes the history easier to read and the next review easier to conduct.