# Wetech Dashboard target session readiness

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-dashboard-session-readiness-2026-09-03",
  "problems": [
    {
      "problemId": "wetech-dashboard-target-and-pzero-session-not-ready",
      "summary": "Wetech Dashboard evidence stopped before the target cluster query because the proxy shell was classified as a P81 credential page and persisted PZero authorization failures were not recovered on the Dashboard path.",
      "status": "optimized_verified",
      "applicability": "Wetech Dashboard-backed TopSQL, Slow Query, and Statements acquisition through the Perimeter81 Dashboard Proxy, including a persisted authorization rejected for an inconsistent browser identity.",
      "issueKeys": ["APID-29437"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29437#problem:wetech-dashboard-session-not-ready"
      ],
      "signalTextIncludesAny": [
        "dashboard_session_not_ready",
        "INCONSISTENT_USER_AGENT",
        "dashboard_proxy_target_advanced"
      ],
      "observedThrough": "2026-09-03",
      "effectiveAt": "2026-09-03T10:18:00Z",
      "verifiedAt": "2026-09-03T10:20:00Z",
      "attemptedAction": "Open the exact configured Dashboard target, distinguish its SQL login from P81 identity pages, detect the PZero connect response-body identity rejection, and retry once in a fresh browser context before executing the bounded query.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/pull/1307"
    }
  ]
}
-->

## Problem

The APID-29437 read replay reached Wetech through Perimeter81 and completed its Grafana metric calls, but both Slow Query and TopSQL stopped with `dashboard_session_not_ready`. Runtime diagnostics showed the Dashboard Proxy shell with its cluster-search input populated and no `dashboard_credentials_submitted` action.

The Managed Wetech Provider Executor treated every `*.perimeter81.com` page as a P81 credential page. After P81 completed and the application landed on the Dashboard Proxy shell, the broad text-input selector filled the cluster-search control instead of opening the exact target cluster. The target TiDB Dashboard frame and its monitor login were therefore never reached.

The first live v33 canary then exposed a second provider-owned session boundary: a persisted P81 authorization created with another browser identity made `/api/applications/connect` return `INCONSISTENT_USER_AGENT`. That failure was present only in the response body, and Dashboard did not yet share Grafana's one-time fresh-context recovery.

## Owner

`tools/agent9-auto-oncall/managed-wetech/` owns the Wetech browser transport, target Dashboard route, Organization Auth consumption, and readiness result. The Evidence Agent, Scenario Diagnostic Agent, Router, and Final Response Agent are unchanged.

## Change

- Restrict P81 credential submission to pages with P81 identity markers and keep application continuation on the explicit `/connect` route.
- Identify Dashboard frames by the exact configured cluster proxy path rather than accepting the proxy shell itself as a Dashboard frame.
- From the proxy shell, open the configured target through its `openTab` contract, with the same bounded iframe fallback used by the local Wetech helper.
- Continue to submit the existing Organization Auth-backed Dashboard credentials only inside that exact target frame.
- Detect `INCONSISTENT_USER_AGENT` from the bounded PZero connect response diagnostics and retry Dashboard login once in a fresh browser context without the incompatible persisted authorization.
- Publish the complete behavior as immutable Wetech Managed Tool v34; v33 remains immutable as the canary that exposed the second boundary.

## Verification

- Package tests assert exact target-frame navigation precedes Dashboard credential submission and that the proxy shell is not classified as a P81 credential page.
- Package tests also assert Dashboard detects the PZero response-body failure and performs only the existing bounded fresh-context recovery.
- Local package build and release tests validate the immutable v34 manifest and installation reference.
- A local Docker canary returned one real bounded Asia SaaS01 Slow Query row with no diagnostic error.
- The post-rollout APID-29437 bet-order canary used Wetech v34 and returned one real bounded Slow Query row with no error code; the Agent9 Turn completed successfully.