Add adaptive retry policy for bounded execution loops

[iKwesi]

Problem

The current repair loop is intentionally bounded, but it still relies on a fixed max_attempts model. That is safe, but not yet smart enough to distinguish productive retries from repeated non-progress.

Why it matters

If SpecForge keeps retrying without recognizing that the same failure is repeating, we waste time and create the impression of blind loop behavior instead of disciplined orchestration.

Proposed solution

Add adaptive retry policy primitives that can vary retry behavior based on execution evidence instead of a fixed attempt budget alone.

The policy should consider signals such as:

• whether the last attempt changed code meaningfully
• whether the failing test set changed
• whether the critic output changed materially
• whether the failure class is repairable vs environmental/policy/spec-blocked

Acceptance criteria

• Retry decisions can be made from execution evidence instead of only attempt_number < max_attempts.
• Non-repairable failure classes can halt immediately without consuming the full retry budget.
• The retry policy remains deterministic and auditable from recorded artifacts.
• Existing conservative defaults remain available as a fallback mode.

Related phase

Future / Research

Related subsystem/component

critic and Ralph loop controller

Related artifacts or commands

criticRalphLoop; task execution results; critic results