AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase02_AcceptanceGate_SupplementalPrompt.txt
|
PHASE 02 ACCEPTANCE-GATE SUPPLEMENTAL PROMPT - COMPLETE THE BOUNDED REMAINING WORK
Goal: Close the remaining Phase 02 acceptance gap by finishing the bounded work that was deferred in the partial implementation: per-tool timeout enforcement, structured retry integration, and focused tests that prove the retry/cancellation semantics are enforced in the live orchestration flow. Inputs: - AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase02_CancellationBudgetsRetry_Implementation.txt - AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase02_CancellationBudgetsRetry_Strict.txt - LogsAndExports/Logs/TechAgentMarkdown/TechAgent_20260905_220421_36688.md Problem statement: - The current Phase 02 patch created a shared run budget, added deadline/cancellation propagation, and introduced structured failure metadata, but it remains partial. - The report explicitly states the acceptance status is not complete because per-tool deadlines, full structured retry integration, and phase-specific tests remain outstanding. - This is not a broad rewrite; it is a bounded completion task focused on the remaining acceptance criteria. Required code work: - Finish propagation of the shared budget and cancellation token into tool execution boundaries and per-tool timeout handling. - Ensure all retry decisions are classified with structured retry codes and retryability metadata, not just the top-level budget guard. - Integrate the structured failure metadata into the orchestration decision path so retry exhaustion, cancellation, deadline expiration, and tool timeout states are observable and testable. - Preserve the safety invariants: authorization, confirmation, sandboxing, refusal logic, and execution safety remain outside the retry/budget abstraction. - Keep the shared run budget authoritative and monotonic across all primary attempts and automatic retries. - Ensure the budget is checked before each iteration and before each retry decision, with explicit behavior for retry exhaustion and cancellation scenarios. Implementation constraints: - Keep scope bounded to the remaining Phase 02 acceptance gaps only. - Do not broaden into unrelated orchestrator architecture or memory/privacy work. - Do not weaken safety or policy checks. - Do not add new retry semantics that override authorization or execution safety. - Maintain deterministic, explicit behavior. Minimum tests to add/update: - Per-tool timeout and deadline tests. - Structured retry classification and retry-exhaustion tests. - Cancellation propagation tests for tool and model execution boundaries. - Integration tests proving the run budget and retry metadata influence orchestration decisions. - State-level tests for deadline/cancellation/retry exhaustion behavior. 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 final cancellation and retry contract, proof that per-tool deadlines and retry exhaustion are enforced, and evidence that the phase acceptance criteria are now satisfied. 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 work expands beyond the remaining acceptance criteria, stop and keep the patch bounded. - If retry classification is only partial, stop and complete the structured integration before continuing. - If tool timeout behavior is still untested or not enforced, stop and finish the boundary enforcement. - If the budget is not consistent across primary and retry attempts, stop and fix it before validation. Fallback behavior: - Fallback A: finish the missing tool-level timeout and retry classification using the existing shared budget contract. - Fallback B: if a broader integration is needed, keep it minimal and test-backed; do not introduce new abstractions. - Fallback C: after one failed repair cycle, emit FAILED_VALIDATION with the exact failing assertions and the incomplete acceptance condition. Acceptance criteria: - Per-tool timeout and deadline behavior are enforced. - Retry decisions are structured and classified with explicit retryability metadata. - The shared run budget is consistently enforced across normal execution and automatic retries. - Cancellation and deadline exhaustion are observable and testable. - The live orchestration flow is covered by focused tests proving the missing behavior. - Safety and authorization invariants remain unchanged. 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) |