# Wetech Parent Failure Evidence Preservation - Optimization ID: `wetech-parent-failure-evidence-preservation-2026-08-10` - Owner: auto-oncall-services runner - Source: read-only replays `APID-29265` run `8a81cf79-d741-4fd1-ae11-efdac4a34bfb` and `APID-29232` run `1e390c28-6ac2-4ef8-8029-da1d5a6ce9ae` - Implementation status: merged in `tidbcloud/aisupport#708` and deployed to staging - Effective status: `optimized_unverified`; available in staging, but neither post-change replay crossed the repaired parent-failure boundary ## Bounded problem Both source replays completed runner-owned Wetech acquisition rounds and materialized validated handoffs before the scenario parent failed. Before `tidbcloud/aisupport#708`, the outer scenario catch replaced those facts with an empty generic `bounded_failure` packet. Final synthesis therefore lost evidence that was already available and could only produce a weaker, less specific human-review result. This record owns only preservation of the last validated Wetech handoff across that parent failure boundary. It does not change acquisition, authentication, query selection, quota, refinement eligibility, retry behavior, safety policy, Judge behavior, Jira publication, or non-Wetech scenarios. ## Candidate change - Keep the last validated cumulative Wetech handoff in runner-owned state. - If the Wetech parent later fails, convert that handoff with the existing factual partial-packet builder instead of returning an empty generic packet. - Preserve observations, counter-evidence, acquisition gaps/errors and canonical artifact references while keeping status `bounded_failure`, completion `partial`, severity contribution `none`, and causal conclusions unresolved. - Leave the normal successful parent path unchanged. ## Verification state Deployed to staging through `tidbcloud/app-delivery#76643` at `2026-08-10T05:57:06Z` and not replay-verified. Local contract coverage proves that a realistic factual Wetech handoff remains in the packet admitted to final synthesis after a parent schema failure, while a failure before any validated handoff continues to use the existing generic packet. The first live verification attempt started on image `ba32a0b17d80e5effa746c2e170d88afd094920e`, which contained #708 and #709 but not #710. An unrelated canonical rollout replaced the Pod during the first `APID-29265` request, so the request and its run artifacts were not recoverable. That attempt supplies no case result and no verification evidence. The cases were then replayed serially in historical `mode=read` against stable live image `c8d2b1b41fa7137937ce6f7c3a82aa05e4178139`. Before and after the replays, the Deployment and optimizer CronJob rendered that same image; the single Pod was Ready with zero restarts, and `/healthz` and `/readyz` returned HTTP 200. Both read requests left database, Jira, evaluation, and Feishu publication `not_requested`. - `APID-29265` run `037a6736-258c-4610-b6f6-871cfc1f8255` used the applicable cutoff before support comment `23334700` and routed the historical window to Wetech scenario `tiflash-io-apply`. Its one 9-query batch completed 3 queries, returned 5 empty results, and failed 1 query with `grafana_query_range_failed`. The validated partial handoff carried 3 factual observations, 5 gaps, 1 error, and compact artifact references into the parent. The parent and final synthesis both succeeded normally; the scenario remained partial/inconclusive and the final result was `human_required`. The draft used the observed queue-time peak while explicitly leaving TiFlash instance mapping, write causality, and recovery unresolved. The source run `8a81cf79-d741-4fd1-ae11-efdac4a34bfb` instead stopped with `diagnostic_wetech_parent_finalization_budget_exhausted`, but this new run did not exercise the repaired fallback. - `APID-29232` run `f07a2658-a086-4874-93bf-cc682193a005` used the applicable cutoff before support comment `23284364` and routed the historical window to Wetech scenario `region-movement-scale`. Round 1 selected 10 queries and returned 9 complete results plus 1 empty result. The parent raised one load-bearing mapping question; round 2 completed all 5 aligned store/instance queries. Both parent turns and final synthesis succeeded normally. The final `human_required` draft bounded the leading explanation to correlation between coprocessor request skew and CPU skew, ruled out Region/Leader count imbalance on the available facts, and left workload identity and recovery unresolved. The source run `1e390c28-6ac2-4ef8-8029-da1d5a6ce9ae` instead stopped with `diagnostic_evidence_refinement_not_required_invalid`, but this new run also did not exercise the repaired fallback. Image `c8d2b1b4` includes the separate #710 query-capacity and diagnostic-budget change (`0ae7270ae57e6e703ac2db13dedab7a608ebd8c6`). It is therefore an explicit confounder for the successful terminal runs, especially their query counts, round count, and available parent/finalization budget. These results must not be attributed to #708 alone. Because neither replay crossed a parent budget, turn, or schema failure after a validated handoff, the bounded criterion remains unverified and the problem stays `optimized_unverified`. No Jira comment was created or refreshed. ## Next validation action Observe a naturally occurring replay, or use a non-destructive controlled case, that produces a validated Wetech handoff and then actually crosses the parent budget, turn, or schema fallback on a stable live image whose unrelated budget changes are isolated. Do not manufacture provider failure. Verify that final synthesis receives the factual partial packet; only then assess a case-specific Jira refresh under the separate publication contract.