AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase01_CompletionGate_Implementation.txt
|
PHASE 01 COMPLETION GATE PROMPT - PROVE REDUCER OWNERSHIP AT THE LIVE EXECUTION SEAM
Goal: Close the final Phase 01 gap by proving the live orchestration loop is reducer-owned rather than relying on mutable `RunLoopState` as the runtime source of truth. Inputs: - AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase01_StateModelAndDecisionPipeline_Implementation.txt - AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase01_StateModelAndDecisionPipeline_Strict.txt - LogsAndExports/Logs/TechAgentMarkdown/TechAgent_20260905_215529_36688.md Problem statement: - The reducer-backed state model exists and the build/tests pass. - However, the live orchestration path still relies on direct `RunLoopState` mutation and therefore does not fully satisfy the Phase 01 acceptance criteria. - The remaining gap is not a broad architecture change; it is a bounded completion gate at the live execution seam. - We must prove that each phase outcome is routed through the reducer and that runtime execution is no longer silently bypassing the explicit state contract. Required code work: - Identify every remaining direct mutation in the live run loop that still updates `RunLoopState` in place. - Replace or bound those assignments so each phase outcome is mediated by `OrchestratorStateReducer.Reduce` or by an explicitly documented, fail-closed compatibility adapter. - Keep the state session as the authoritative runtime state for: - phase progression - iteration counters - cancellation and deadline status - repair and clarification tracking - duplicate tool-result handling - finalization and terminal-state enforcement - Preserve all safety invariants: - authorization constraints - confirmation rules - sandboxing - refusal logic - execution safety - deadline and cancellation checks - Maintain fail-closed behavior for unknown contract versions and illegal transitions. - If a compatibility adapter is retained, it must be temporary, explicit, and tested; it cannot remain a silent bypass. - Add the missing migration and compatibility guidance needed for persisted state evolution and deterministic rollback behavior. Implementation constraints: - Keep this patch bounded to the execution seam and directly related contract/test surfaces. - Do not broaden into unrelated orchestration architecture or tool-policy work. - Do not weaken safety or authorization. - Do not leave hidden mutable state in the main loop. - Do not add telemetry or diagnostics that bypass redaction or resource ceilings. Minimum tests to add/update: - A focused integration test proving the live orchestration path is reducer-owned and no longer relies on direct `RunLoopState` mutation for critical iteration transitions. - Transition tests covering legal and illegal flows, terminal-state rejection, and cancellation/deadline expiration. - Duplicate tool-result idempotency tests. - Unknown-version compatibility rejection tests. - A compatibility migration test for persisted state or adapter behavior if any wrapper remains. - A weather/forecast regression test proving the required output content is present for those execution paths. 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|Execution|Tool|Safety|Retry|Loop|Policy|Telemetry|Weather|Authorization" Deliverable: Return changed files, the exact live-seam migration path, proof that the reducer is the runtime authority, and evidence that weather/forecast behavior remains valid and compliant. 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 live loop still assigns directly to `RunLoopState` for phase or iteration state, stop and continue the migration. - If a compatibility adapter remains silent or undocumented, stop and make it explicit and tested. - If any acceptance check still fails—including weather/forecast completeness—treat it as blocking. - If the patch expands beyond the seam, stop and keep it bounded. Fallback behavior: - Fallback A: route the live loop through a minimal reducer-backed adapter and keep `RunLoopState` strictly as a compatibility layer. - Fallback B: preserve behavior with an explicit fail-closed adapter and tests if migration is too risky. - Fallback C: after one failed repair cycle, emit FAILED_VALIDATION with exact failing assertions and the offending transition or runtime bypass. Acceptance criteria: - The live orchestration execution path is reducer-owned. - The legacy mutable loop is no longer the runtime source of truth for phase progression and iteration-state transitions. - State ordering remains explicit, deterministic, and safe. - Cancellation, deadline, iteration-limit, duplicate-result, and unknown-version checks are enforced at runtime. - Weather and forecast output is validated for required completeness. - No safety invariant is weakened. Output results in markdown using this structure: 1) Summary 2) Files changed 3) Migration and compatibility notes 4) Tests added/updated 5) Validation results 6) Step-budget report (planned vs actual counts) |