Problem
Some Phase 4 tasks appear too large for a single code-migrator invocation to converge, even with failure recovery loops (failure-adjudicator -> code-migrator -> parity/build/test re-check). In these cases, retries can repeat without materially reducing the unresolved issue set.
Recent behavior shows task-001 repeatedly failing parity with non-minor issues despite multiple recovery attempts, eventually ending in terminal exhaustion.
Goal
Add an optional replanning stage that triggers after repeated recovery failures, so AAMF can split or re-scope an oversized task instead of repeatedly remediating the same broad unit.
Proposed behavior
When a task hits repeated recovery attempts (e.g., parity/build/test recovery loop) and unresolved non-minor issues persist:
- Detect likely non-convergence (same/similar unresolved issue set across attempts).
- Trigger replanning for the failing task scope (behind a config flag).
- Produce replacement sub-tasks (narrower line ranges / smaller file subsets).
- Inject sub-tasks into the Phase 4 queue with dependency-safe rewiring.
- Continue migration from the newly decomposed tasks.
Initial trigger criteria (proposal)
- Recovery attempts >= configurable threshold (default 2 or 3)
- AND unresolved non-minor issues remain
- AND issue-set delta indicates low progress (high overlap with prior attempt)
Config proposal
Add options such as:
options.replanning.enabled: boolean (default false)options.replanning.triggerAttempts: numberoptions.replanning.maxSubtasks: numberoptions.replanning.minIssueOverlapForTrigger: number
Implementation notes
- Reuse existing task-decomposition contracts where possible (
task-decomposer schema).
- Record replanning events in checkpoint/progress for resume safety and observability.
- Ensure deterministic IDs for generated sub-tasks (e.g.,
task-001a, task-001b or stable hashed suffixes).
- Preserve existing behavior when replanning is disabled.
Acceptance criteria
Nice-to-have follow-ups
- Surface replanning metrics (trigger count, avg subtasks created, convergence delta).
- Add guardrails to avoid repeated replan loops on the same original task.
Problem
Some Phase 4 tasks appear too large for a single
code-migratorinvocation to converge, even with failure recovery loops (failure-adjudicator->code-migrator-> parity/build/test re-check). In these cases, retries can repeat without materially reducing the unresolved issue set.Recent behavior shows
task-001repeatedly failing parity with non-minor issues despite multiple recovery attempts, eventually ending in terminal exhaustion.Goal
Add an optional replanning stage that triggers after repeated recovery failures, so AAMF can split or re-scope an oversized task instead of repeatedly remediating the same broad unit.
Proposed behavior
When a task hits repeated recovery attempts (e.g., parity/build/test recovery loop) and unresolved non-minor issues persist:
Initial trigger criteria (proposal)
Config proposal
Add options such as:
options.replanning.enabled: boolean(defaultfalse)options.replanning.triggerAttempts: numberoptions.replanning.maxSubtasks: numberoptions.replanning.minIssueOverlapForTrigger: numberImplementation notes
task-decomposerschema).task-001a,task-001bor stable hashed suffixes).Acceptance criteria
Nice-to-have follow-ups