# Bounded Related Evidence Retrieval

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "related-evidence-retrieval-2026-07-22",
  "problems": [
    {
      "problemId": "related-ticket-or-product-issue-not-retrieved",
      "summary": "Auto-oncall does not perform bounded related Jira Ticket or public TiDB Issue retrieval before drafting a diagnostic reply.",
      "status": "optimized_verified",
      "issueKeys": ["APID-29188", "ST-2824"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29188#problem:ai_gap:prior-ticket-not-retrieved",
        "auto-oncall-report:staging:daily:2026-07-16:case:ST-2824#problem:ai_gap:related-issue-and-causal-chain-missed"
      ],
      "signalTextIncludesAny": [
        "要求客户提供 earlier ticket key",
        "未找到公开的 pingcap/tidb issue",
        "未使用可定位的历史升级 ticket",
        "稳定错误签名存在但未检索相关 issue"
      ],
      "observedThrough": "2026-07-22",
      "effectiveAt": "2026-07-22T12:22:00Z",
      "verifiedAt": "2026-07-22T12:31:18Z",
      "attemptedAction": "Materialize one cutoff-safe input/related-evidence.json before dry-run, live, and continuation analysis. Search same-reporter Jira metadata only when the visible case references a prior ticket, search public pingcap/tidb Issues only from stable error signatures, cap both branches at three combined candidates, and require the shared prompt to consume the evidence without exposing private Jira metadata.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/pull/458"
    }
  ]
}
-->

- Optimization ID: `related-evidence-retrieval-2026-07-22`
- Owner: auto-oncall-services Recent Focus patch agent
- Source reference: Active Focus `related-ticket-and-product-issue-retrieval`
- Implementation status: merged in `tidbcloud/aisupport#458` as `de526448`
- Effective status: deployed and verified in staging

## Bounded problem

The shared support-analysis prompt did not route explicit prior-ticket
references or stable product error signatures through a bounded related
evidence workflow. Historical replay also omitted the stable reporter account
identifier needed for a same-reporter Jira metadata search. This caused the
draft to repeat a ticket-key request or miss a directly related public product
Issue.

The candidate materializes `input/related-evidence.json` before dry-run, live
initial analysis, and continuation. Prior-ticket references trigger a
same-reporter Jira search that requests only summary, status, created, and
updated metadata. Stable textual error signatures trigger a public
`pingcap/tidb` Issue search. Both branches share a three-candidate limit and
reject evidence newer than the replay cutoff.

The shared prompt must read the manifest before asking for a ticket key or
concluding that no related Issue exists. It keeps internal Jira evidence in
replay context only, permits only public TiDB Issue links in the customer
draft, and requires a mechanism match to remain distinct from a confirmed
root cause. If a screenshot contains a signature that text extraction could
not see, the Agent may perform one equally bounded public Issue search.

## Verification

On 2026-07-22, all 403 repository tests passed. The new contract tests verify
shared dry-run/live/continuation prompt routing, metadata-only Jira fields,
cutoff JQL, stable-signature routing, the combined candidate limit, explicit
no-match behavior, privacy, and causal boundaries.

The final Recent Evaluation challenger passed both target cases and all four
blocking criteria. The candidate gate recorded six confirmed blocking
improvements, zero regressions, and zero follow-up gaps in Focus Issue #457.

Staging rollout evidence:

- `tidbcloud/aisupport#458` merged as `de526448`; staging deploy workflow run
  `29918974192` built image digest
  `sha256:2f1b67301c9fd3902685a0dd0cdb0c253297c16300d4a12b0ad89a20db8123a8`.
- `tidbcloud/app-delivery#75214` merged the same image tag. The live Deployment
  and ready Pod both used `de526448`; rollout completed successfully.
- Poller and continuation-poller logs completed without failures. DB state had
  no queued or running jobs, and both poll cursors continued to advance.

Case-specific replay and Jira refresh evidence:

- APID-29188 run `bbc8db94-5c04-44ab-a011-8d31c3962558` selected the bounded
  same-reporter upgrade candidates, stopped asking for the earlier Ticket key,
  and updated existing internal comment `23251582` under
  `auto-live:v1:APID-29188:initial`.
- ST-2824 run `13c8fc96-c884-44d8-aae2-43566e20624a` confirmed the RPC timeout,
  retry, and duplicate MPP registration chain; cited public Issue #65864 with
  OPEN state and causal limits; and updated existing internal comment
  `23210686` under `auto-live:v1:ST-2824:initial`.
- Direct Jira GET verification returned HTTP 200 and `public=false` for both
  comment IDs. DB runs `60090` and `60091` succeeded with Jira status
  `updated`; no duplicate internal comment was created.

## Unresolved gaps

- No unresolved gap remains for this bounded problem in staging.
- Production rollout remains outside this optimization and stays disabled.

## Next validation action

Keep the two verified cases in regression coverage. Add new problem signals if
a future ticket repeats an existing-key request, omits a strong public Issue
match, exceeds the three-candidate limit, or leaks internal Jira metadata.