Which failures should the orchestrator retry automatically, with what bounded retry counts, and when should it stop and request human help? Cover Herdr startup/control, remote repository cloning, worker runs, local checks, PR operations, the four review axes, merges, and state reconciliation. Define how retries avoid duplicate agents, worktrees, comments, or PRs.
Current related defaults: the Herdr planner caps retries at two; the existing implementation orchestrator caps review/fix rounds at three. Decide whether to reuse or change these limits.
Part of #27
## Question
Which failures should the orchestrator retry automatically, with what bounded retry counts, and when should it stop and request human help? Cover Herdr startup/control, remote repository cloning, worker runs, local checks, PR operations, the four review axes, merges, and state reconciliation. Define how retries avoid duplicate agents, worktrees, comments, or PRs.
Current related defaults: the Herdr planner caps retries at two; the existing implementation orchestrator caps review/fix rounds at three. Decide whether to reuse or change these limits.
Decision: Retry only transient infrastructure failures, with at most two retries after the initial attempt (three attempts total). Do not retry semantic failures or failed checks/reviews without first addressing the cause. Keep the existing three review/fix rounds as a separate ceiling.\n\nFor uncertain side effects (worker spawn, PR creation, comments, merges, state writes), reconcile current state before any repeat; never blindly replay. If the outcome remains uncertain, stop and escalate.\n\nEscalate immediately for auth/permission failures, unresolved side effects or state mismatches, and decisions needing human judgment. After retry/review limits are exhausted, preserve state and evidence and request human help.
Decision: Retry only transient infrastructure failures, with at most two retries after the initial attempt (three attempts total). Do not retry semantic failures or failed checks/reviews without first addressing the cause. Keep the existing three review/fix rounds as a separate ceiling.\n\nFor uncertain side effects (worker spawn, PR creation, comments, merges, state writes), reconcile current state before any repeat; never blindly replay. If the outcome remains uncertain, stop and escalate.\n\nEscalate immediately for auth/permission failures, unresolved side effects or state mismatches, and decisions needing human judgment. After retry/review limits are exhausted, preserve state and evidence and request human help.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of #27
Question
Which failures should the orchestrator retry automatically, with what bounded retry counts, and when should it stop and request human help? Cover Herdr startup/control, remote repository cloning, worker runs, local checks, PR operations, the four review axes, merges, and state reconciliation. Define how retries avoid duplicate agents, worktrees, comments, or PRs.
Current related defaults: the Herdr planner caps retries at two; the existing implementation orchestrator caps review/fix rounds at three. Decide whether to reuse or change these limits.
Decision: Retry only transient infrastructure failures, with at most two retries after the initial attempt (three attempts total). Do not retry semantic failures or failed checks/reviews without first addressing the cause. Keep the existing three review/fix rounds as a separate ceiling.\n\nFor uncertain side effects (worker spawn, PR creation, comments, merges, state writes), reconcile current state before any repeat; never blindly replay. If the outcome remains uncertain, stop and escalate.\n\nEscalate immediately for auth/permission failures, unresolved side effects or state mismatches, and decisions needing human judgment. After retry/review limits are exhausted, preserve state and evidence and request human help.