AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase05_WeatherRoutingHardening_Implementation.txt
|
PHASE 05 IMPLEMENTATION PROMPT - WEATHER ROUTING HARDENING
Goal: Implement provenance-aware NOAA and ZIP selection so weather flows do not proceed on weak or noisy evidence. Inputs: - AI/Tasks/OrchestratorUpgrades/Orchestrator_Phase05_WeatherRoutingHardening_Strict.txt - AI/Tasks/OrchestratorUpgrades/Overview.txt Required code work: - Improve NOAA/ZIP discovery logic with structured candidate scoring and provenance validation. - Invalidate low-confidence or unrelated five-digit values from search results. - Add explicit clarification or block behavior when candidate confidence is insufficient. - Define a candidate data model with ZIP, city, state, source identifier, evidence span, extraction method, confidence, and timestamp. - Require minimum confidence and margin-over-second-place thresholds before a forecast request is executed. - Keep domain-specific routing under the same general validation and authorization constraints. Implementation constraints: - Keep generic tool validation, authorization, and retry logic separate from weather-routing work. - Preserve current behavior except where weather discovery is made more accurate and safer. - Do not implement broad telemetry privacy or final integration changes in this phase. Minimum tests to add/update: - ZIP candidate scoring tests. - Low-confidence NOAA fallback tests. - Noisy search-result rejection tests. - Clarification-trigger tests when location evidence is insufficient. 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|Weather|NOAA|ZIP|Search|Routing|Strict" Deliverable: Return changed files, the final weather-routing contract, and proof that domain-specific routing remains safe, confirmed, and provenance-aware. |