Regenerate / retry

Problem Context

• A generated response may fail, stop, stall, be rate-limited, miss sources, produce weak output, use stale context, encounter a tool failure, or need a new variant.
• Retrying an AI answer may mean repeating the same response request, continuing a partial stream, rerunning retrieval, retrying a tool, changing model settings, or generating an alternate version.
• Regeneration may produce materially different conclusions, citations, tone, structure, tool use, or safety decisions even when the visible prompt is unchanged.
• Users may have copied, edited, commented on, cited, approved, or applied the prior answer before regeneration is requested.
• Some retry paths are subject to rate limits, backoff, idempotency, tool side effects, permission gates, or source freshness.

Selection Rules

• Choose regenerate / retry when the task is rerunning an AI response attempt, creating a new answer version, continuing a failed generation, or recovering from failed AI source or tool work.
• Use retry when the task is repeating a non-AI failed operation such as export, upload, payment, save, or sync under the same request scope.
• Use chat interface when the design problem is the full multi-turn transcript, conversation list, history, and composer; regenerate / retry is one response-level action inside that surface.
• Use streaming response when the design problem is the live partial-output lifecycle; regenerate / retry handles the recovery or alternate-version action after stop, stall, failure, or completion.
• Use prompt box when users should edit the request before generation instead of rerunning the submitted prompt.
• Use editable AI output when users directly revise the generated draft; regenerate / retry should not overwrite those manual edits without compare or recovery.
• Use source grounding display or citation display when the key task is evidence inspection rather than requesting another generated version.
• Show same prompt, edited prompt, same context, changed context, same model, changed model, same sources, refreshed sources, same tools, retried tools, and no-tool rerun differences before the user commits.
• Do not hide the prior answer, citations, tool trace, partial output, edits, or version identity when a new answer is generated.
• Do not automatically retry AI work in a tight loop when rate limits, overload, safety review, permission denial, or side-effecting tools make repetition unsafe.

Required States

• Initial answer state with prompt snapshot, response version, source scope, model or mode, and available regenerate or retry controls.
• Failed response retry state with failure reason, attempt count, preserved prompt, and Retry same prompt action.
• Stopped or partial output state with Continue partial, Retry from start, Copy partial, and Discard controls.
• Regenerating state with in-flight status, duplicate activation guard, attempt number, and previous version still available.
• Regenerated version state that shows v1 and v2 identity, changed model, changed context, changed sources, changed tools, and compare versions controls.
• Retry failed sources, retry failed tool, and no-tool rerun states when the answer depends on retrieval or tool calls.
• Rate-limited, cooldown, quota exhausted, offline, permission denied, safety blocked, and non-retryable states.
• Stale context and refreshed source states that make source freshness explicit before regeneration.
• Manual edits present state that blocks overwrite and routes users to compare, keep edited, regenerate from edit, or restore original.
• Mobile compact regeneration state that preserves prior version, prompt snapshot, source status, and retry timing.

Interaction Contract

• Retry same prompt repeats the submitted prompt and visible context unless the UI explicitly shows which context changed.
• Regenerate creates a new answer version or clearly replaces the current version with an undo and restore path.
• Previous output, partial output, citations, tool events, copied state, and review comments remain inspectable after regeneration when they affected user decisions.
• Retry failed source work and retry failed tool work are distinct from regenerating answer text.
• If model, mode, source scope, tools, safety policy, or prompt text changes between attempts, the difference is visible before or immediately after the new attempt.
• Retry controls enter a pending state and suppress duplicate activation until the attempt completes, fails, cools down, or is cancelled.
• Rate limits, cooldowns, safety blocks, permission denials, and non-retryable failures replace the action with honest recovery or explanation.
• Regeneration never discards manual edits from editable AI output unless the user chooses a replacement path with version recovery.

Implementation Checklist

• Model prompt snapshot, submitted prompt ID, response ID, response version, attempt number, partial output, previous output, selected context, source scope, tool scope, model settings, and retry status separately.
• Track regenerate reason such as weak answer, user requested variant, failed stream, failed source, failed tool, stale source, safety block, rate limit, or edited draft.
• Represent same-prompt retry, edited-prompt retry, continue partial, retry from start, regenerate alternate, retry sources, retry tools, compare versions, restore previous, and keep both as separate actions.
• Show source, tool, citation, and model differences between attempts in structured rows instead of burying them in final answer text.
• Protect side-effecting tool calls with idempotency, permission gates, or no-tool rerun options before allowing retries that can change external systems.
• Persist old answer versions long enough for copy, citation, audit, review, compare, and rollback tasks.
• Apply cooldown, retry limits, and rate-limit timing for repeated AI retries and automatic retries.
• Test same prompt retry, changed context, changed model, failed source retry, failed tool retry, stopped partial output, rate limit, safety block, manual edits, version compare, mobile wrapping, keyboard operation, and screen-reader status changes.

Common Generated-UI Mistakes

• Using one Try again button for same-prompt retry, prompt edit, tool retry, source refresh, and alternate answer generation.
• Overwriting the previous answer and citations after regeneration.
• Hiding changed model, tools, source scope, or context between attempts.
• Retrying side-effecting tools while presenting the action as harmless answer regeneration.
• Letting users regenerate over manually edited output without conflict handling.
• Using infinite automatic retries during rate limits, overload, safety review, or permission denial.
• Treating a regenerated answer as more correct without showing source, confidence, or review changes.

Critique Questions

• Will this action retry the same prompt, continue partial output, regenerate a new version, retry sources, retry tools, or edit the prompt?
• Can users see the prompt snapshot, version identity, source scope, tool scope, model settings, attempt count, and changed context?
• What happens to the previous answer, citations, copied state, comments, approvals, and manual edits?
• Which failures are retryable, cooled down, blocked, exhausted, or non-retryable?
• Does any retry path repeat side-effecting tools, and what prevents duplicate external effects?
• Would general retry, chat interface, streaming response, prompt box, or editable AI output better match the actual task?