AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase02_CancellationBudgetsRetry_Strict.txt
|
STRICT MODE: Harden orchestration cancellation, budgets, and retry semantics.
Mission: - Complete this phase with bounded steps and deterministic fallback behavior. - Apply changes ONLY within orchestrator run lifecycle, retry ownership, and directly related execution contracts. Concrete scope: - AI/Tasks/OrchestratorUpgrades/Overview.txt - AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase02_CancellationBudgetsRetry_Strict.txt - Orchestrator run and retry helpers, cancellation propagation, timeout contracts, total-run budget tracking, and structured failure classification. Requirements: - Add `CancellationToken` support throughout orchestrator execution and tool invocation. - Define one total run budget spanning model calls, tool calls, wall-clock time, and output size. - Replace string-based retry logic with structured result codes and explicit retryability decisions. - Ensure deterministic failures are not retried unless the recovery action changes the root cause. - Add per-tool timeout semantics plus run deadline handling. - Define cancellation precedence relative to retry, finalization, and deadline exhaustion, including the safe behavior for partial side effects from timed-out tools. - Use monotonic time sources for deadlines and define whether delayed retries consume the total budget. - Preserve current behavior where the task is only to make retry and cancellation semantics consistent and bounded. - Keep the model deterministic, centralized, and mechanically testable. - Add characterization or phase-specific tests before or alongside each major change. - Do not expand into full tool-policy registry work, path validation, or telemetry privacy changes beyond what is required to finalize cancellation and retry behavior. - Enforce sensitive-data redaction and resource-limit checks in any diagnostics or logging introduced here. - Do not weaken authorization, confirmation, sandboxing, or execution safety requirements. - Define compatibility and rollback behavior for deadline or retry-contract changes that alter existing orchestrator semantics. 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 cancellation or retry logic starts to overlap with tool authorization or policy evaluation, stop and re-establish the owning abstraction. - If repeated retry refactoring becomes a broader rewrite than cancellation and budget hardening, stop and keep the phase boundary explicit. Fallback behavior: - Fallback A: introduce structured retry reasons and deadline state before altering behavior broadly. - Fallback B: preserve current retry heuristics and add a single budget wrapper or gate around them. - Fallback C: after one failed repair cycle, emit FAILED_VALIDATION with the exact failing assertions. Acceptance criteria: - Orchestrator execution supports cancellation and deadlines consistently. - Retry behavior is driven by structured reasons rather than string matching. - A total run budget exists and is applied uniformly to retries. - Per-tool and total-run timeouts are explicit and enforced. - Characterization or phase-specific tests cover timeout, cancellation, and retry exhaustion. - Logging and diagnostics redact sensitive data and respect resource limits. - The orchestration layer does not weaken authorization, confirmation, sandboxing, or execution safety requirements. 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" 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) |