Set bounded retries and human escalation policy #28

Closed
opened 2026-10-06 11:56:37 -04:00 by steve · 1 comment
Owner

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.

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.
steve added the wayfinder:grilling label 2026-10-06 11:56:37 -04:00
steve self-assigned this 2026-10-06 12:02:04 -04:00
Author
Owner

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.
steve closed this issue 2026-10-06 12:04:46 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: steve/skills#28