Which exception states could a generated task pack include?

Ask for an exception catalogue that connects each generated state to an allowed recovery or escalation path.

- A duplicate request linked to the existing case rather than processed again. - Contradictory instructions from the same authorised requester across two channels. - A missing supporting attachment that leaves a change awaiting evidence. - A dependent system outage that leaves propagation queued for retry. - A withdrawn request whose downstream action already requires cancellation. - A customer record merge that changes the identifier used by an open case. - An unsupported requested value that requires a permitted alternative or refusal.

Each exception should carry enough state to explain why normal processing cannot finish. A queued update needs a retry condition. A contradictory instruction needs an explicit resolution rule or a way to obtain clarification. A withdrawn request needs a record of any action that can no longer simply be discarded.

MirrorFirm could generate these branches as related task variants with different tool responses and permitted outcomes. The catalogue gives builders a concrete basis for implementing recovery behaviour, rather than attaching generic error messages to an otherwise successful path. It also makes the limits of each branch inspectable.