# Current Configuration Lookup Scope

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "current-config-lookup-scope-2026-08-27",
  "problems": [
    {
      "problemId": "current-config-lookup-expanded-into-causal-diagnosis",
      "summary": "TCID-13091 was correctly routed as a read-only configuration inspection, but the Scenario Diagnostic Agent expanded four current-value lookups into Region-movement causality, metrics, logs, per-instance consistency, and a second refinement round.",
      "status": "optimized_unverified",
      "applicability": "Provider-backed cluster-runtime tickets whose immediate request is only the current values of explicitly named configuration parameters.",
      "issueKeys": ["TCID-13091"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/TCID-13091#problem:current-config-lookup-expanded-into-causal-diagnosis"
      ],
      "signalTextIncludesAny": [
        "current request is read-only configuration inspection",
        "current configuration values",
        "TCID-13091"
      ],
      "observedThrough": "2026-08-27",
      "effectiveAt": "2026-08-27T12:11:00Z",
      "verifiedAt": null,
      "attemptedAction": "Normalize the classifier-owned current read-only configuration task to a stable signal and pass it directly to the Scenario Diagnostic Agent, limiting the evidence objective to the exact current values and provenance of the named parameters.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/pull/1128"
    }
  ]
}
-->

- Optimization ID: `current-config-lookup-scope-2026-08-27`
- Owner: Scenario Diagnostic Agent initial evidence objective
- Source: TCID-13091 read replay `299f6cf7-ccfb-49ff-9675-ea8b2a850500`
- Implementation status: merged in PR #1128 and live on staging SHA
  `3336a726d8abeb56591d7e29d45111bc0b07a816`
- Effective status: `optimized_unverified`

## Bounded problem

The live replay classified the immediate request correctly and reached the new
configuration operation, but the Scenario Diagnostic Agent asked whether the
settings controlled Region movement and required uniform runtime state plus a
stronger alternative. The Evidence Agent consequently ran 11 first-round
queries, three refinement queries, and used incorrect expanded TiKV parameter
names. The run took 559.3 seconds and still returned only the two PD values.

## Candidate change

When the routed signal is exactly `current request is read-only configuration
inspection`, the Scenario Diagnostic Agent owns a factual lookup rather than a
causal incident diagnosis. Its evidence question must preserve the parameter
spellings from the frozen ticket and ask only for one authoritative current
value and provenance per key. It must not add performance causality, alternative
constraints, incident-window metrics, logs, activities, per-instance
consistency, or a possible later mutation.

## Verification evidence

The first prompt contract test used the bare signal text. Deployed read replay
`71b498bf-f4fc-41ee-9c43-df1f260b0891` emitted a source-qualified reference;
its exact match failed, so the replay ran 12 queries, returned only the two PD
values, and took 432.6 seconds. A later live Router no longer copied the
classifier signal into `signalRefs` at all. Server-side replay
`31f7c92f-efbf-4307-9e6e-efb4349e12f2` therefore asked a causal Region-movement
question, issued one 11-query batch plus four individual failed configuration
repair calls, spent 315.8 seconds in the scenario stage, and ended
`human_required`. The configuration calls failed validation before network
execution (`requestCount=0`). The correction now supplies the classifier-owned
current-configuration intent directly to the Scenario Diagnostic Agent; its
test deliberately omits that text from Router `signalRefs`.

The post-deployment read replay
`6e4c6f2e-aa70-479e-8b36-26947ba6eeaf` completed at
2026-08-27T12:16:17Z. Its evidence request named only the four current values
and provenance. It ran no metric, log, activity, topology, or refinement query,
and returned PD values 64/64 plus TiKV values 32/32 through the Clinic-first,
CloudConfig-fallback configuration operation. This passes the bounded
query-expansion criterion.

## Unresolved gaps

- No Jira internal comment refresh is authorized by this read-replay task.
- The separate Agent9 validation-retry latency observed in the same replay is
  tracked independently; it does not reopen this query-expansion problem.

## Next validation action

Run an authorized `mode=write` refresh when requested, verify the stable
`public=false` Jira internal comment, and only then promote this problem to
`optimized_verified`.