# Review an automation exception before retrying

Illustrative planning brief; no automatic product import.

Illustrative run: a task operation times out after submission, so the automation cannot tell whether the record was saved.

## Decision

Reconcile current state and input validity before deciding to retry, repair or stop.

## Owned work

- Classify the observed failure
  - Owner role: Operator
  - Acceptance evidence: Timeout, rejected input and access failure are distinguished.
- Check current state
  - Owner role: Workflow owner
  - Acceptance evidence: A safe read looks for evidence of the intended operation.
- Choose the recovery action
  - Owner role: Operator
  - Acceptance evidence: Retry or repair follows actual state and the interface’s documented contract.

## Workflow

1. Preserve the intended target and request scope.
2. Read state before repeating an uncertain write.
3. Record the recovery decision and verification evidence.

## Judgment

Do not generalize idempotency from one operation to another; task creation and sprint transitions have different contracts.


## Illustrative delivery brief

Observed: the write response is uncertain.
Check: current saved state and target evidence.
Do not assume: the operation failed or is universally idempotent.
Decision: reconcile, then retry/repair/stop according to the actual contract.


## Workflow questions

### Is every timeout safe to retry?

No. The first operation may have succeeded; reconcile saved evidence before repeating it.

### What if the input was rejected?

Repair the documented invalid condition rather than repeatedly resubmitting identical input.

## Product connection

Check whether work was already saved before recording or retrying the related TeamBoostAI task action.

Confirm account availability before adopting this manual outline.