AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase02_FinalCompletionSupplementalPrompt.txt
|
PHASE 02 FINAL COMPLETION PROMPT - FIX THE ITERATION-LIMIT AUTO-RETRY REGRESSION AND COMPLETE ACCEPTANCE
Goal: Resolve the exact remaining Phase 02 regression and complete the acceptance gate by restoring the intended automatic retry behavior when the orchestrator reaches an iteration limit while the retry budget remains valid. Inputs: - AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase02_CancellationBudgetsRetry_Implementation.txt - AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase02_CancellationBudgetsRetry_Strict.txt - LogsAndExports/Logs/TechAgentMarkdown/TechAgent_20260905_221832_36688.md Problem statement: - The implementation added structured retry-metadata handling and per-tool timeout enforcement, and the build succeeded. - The targeted retry/cancellation/budget test command still fails on two specific regression assertions: - `AgentOrchestratorTests.RunAsync_AutoRetryOnIterationLimit_CompletesOnRetry` - `AgentOrchestratorTests.RunAsync_AutoRetryOnIterationLimit_ReturnsDetailedMessageAfterRetryFailure` - The actual behavior is returning `## Agent Iteration Limit Reached...` instead of completing the retry and returning the expected final answer from retry. - The detailed message also no longer contains the expected substring `- initial iteration_limit used: 1`. - The fix must not regress the newly added timeout and structured retry metadata behavior; it must restore the intended auto-retry semantics for valid iteration-limit cases while keeping the new budget logic intact. Required code work: - Restore the original auto-retry-on-iteration-limit behavior when the condition is retryable and the shared run budget still permits a retry. - Keep the new structured `OrchestratorRetryDecision` metadata and `RunBudget` enforcement, but make sure the actual orchestration path still continues into the retry flow instead of terminating early into an iteration-limit final message. - Preserve structured retry classification for cancellation, deadline expiration, tool timeout, and retry exhaustion. - Ensure the retry decision path respects: - retryability metadata - side-effect safety - remaining budget - max-attempt exhaustion - cancellation precedence - Do not weaken authorization, confirmation, sandboxing, refusal logic, or execution safety. - Preserve the detailed message behavior expected by the existing retry test contract. Implementation constraints: - Keep the fix narrow and focused on the remaining regression. - Do not broaden into unrelated orchestrator architecture or policy work. - Do not override authorization, execution safety, or confirmation checks. - Do not add speculative abstractions beyond the retry decision contract already introduced. Required repair focus: - Fix the actual decision path that decides whether an iteration-limit condition is a terminal failure or an eligible retry. - Preserve the intended user-visible output when the retry succeeds and when the detailed retry message is emitted. - Ensure the message includes the expected iteration-limit details in the retry summary. Minimum tests to add/update: - Restore and pass the exact failing test cases listed above. - Add or update any missing coverage needed to keep the retry metadata and live orchestration behavior explicit and testable. - Preserve the timeout/cancellation/retry-budget tests added in the prior bounded patch. Validation commands: - dotnet build src/TechToolbox.Agent/TechToolbox.Agent.csproj -c Release - dotnet test src/TechToolbox.Agent/Tests/TechToolbox.Agent.Tests.csproj -c Release --filter "Orchestrator|Retry|Cancellation|Timeout|Budget|Strict" Deliverable: Return changed files, the corrected retry decision flow, the final run-budget/retry contract, and proof that the targeted Phase 02 acceptance tests pass without regressing the timeout and budget changes. Step budget (hard limits): 1) Discovery: <= 6 read/search tool calls. 2) Edits: <= 8 file edits total. 3) Validation: 1 build + 1 targeted test run; allow exactly 1 repair cycle if failures are phase-related. 4) Stop once acceptance criteria pass. Loop guards: - If the fix expands beyond the iteration-limit retry regression, stop and keep the patch bounded. - If retryability metadata or run-budget checks are bypassed, stop and fix the decision path before continuing. - If the retry path still terminates into `## Agent Iteration Limit Reached...`, stop and restore the retry flow. - If the detailed message no longer contains the expected iteration_limit detail, stop and restore the summary output. Fallback behavior: - Fallback A: restore the retry flow for valid iteration-limit retries while keeping the new retry metadata and timeout checks. - Fallback B: if the issue is in the budget/retry decision boundary, repair that boundary only and keep the rest of the patch intact. - Fallback C: after one failed repair cycle, emit FAILED_VALIDATION with the exact failing assertions and the offending decision path. Acceptance criteria: - `RunAsync_AutoRetryOnIterationLimit_CompletesOnRetry` passes. - `RunAsync_AutoRetryOnIterationLimit_ReturnsDetailedMessageAfterRetryFailure` passes. - The structured retry metadata and tool-timeout contracts remain intact. - Retry exhaustion, cancellation, deadline expiration, and tool timeout behavior remain explicit and testable. - No safety invariant is weakened. Output results in markdown using this structure: 1) Summary 2) Files changed 3) Cancellation and retry contract 4) Tests added/updated 5) Validation results 6) Step-budget report (planned vs actual counts) |