Queue retry decision

Synthetic example: choose a recovery policy before changing a background worker. Replace this content when creating a real artifact.

1. Choice chips — single and multiple selection

Choose one recovery policy and any constraints that should shape it.

2. Reply builder — updates as choices change

Copy the result back to your coding agent.

your response
Choose a policy to build a response.

3. Copy buttons — individual finding or final prompt

This finding is illustrative. Replace it with a verified file reference in a real review.

“A network timeout does not prove that the provider rejected the request.”

prompt for the next step

4. Knowledge check — understanding, not authorization

A wrong answer points to an explanation. Passing this check never grants permission to deploy or spend.

1. What does a request timeout establish?
↳ Read the timeout note and try again.
2. What should happen before retrying an uncertain paid job?
↳ Read the recovery note and try again.
✓ Understanding checked 0/2

5. Collapsible detail — deeper explanation on demand

Keep the first read short without hiding material constraints.

Why a timeout is ambiguous failure mode

The provider may have accepted the request before the connection failed. Retrying blindly may duplicate work or charges.

What reconciliation means recovery

Look up the provider request ID or other durable evidence, record the actual outcome, then decide whether a new request is needed.

6. Filters — narrow a longer review

Only cards with a category participate in filtering.

Finding — timeout after dispatch

The worker records a timeout but may already have sent the provider request.

Finding — no replay key

The example request has no stable idempotency key yet.

Decision — recovery policy

Choose automatic idempotent retry or manual reconciliation.

Decision — spend bound

Set a maximum charge before any retry policy is enabled.