# Deterministic Wetech Browser-backed Transport

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "deterministic-wetech-auth-bootstrap-2026-08-10",
  "problems": [
    {
      "problemId": "wetech-browser-cannot-run-inside-diagnostic-sandbox",
      "summary": "After diagnostic filesystem isolation is enabled, Wetech auth and provider fallback launch Chromium inside the Codex Linux sandbox, where Chromium exits with SIGTRAP and prevents usable provider evidence.",
      "status": "optimized_unverified",
      "issueKeys": ["APID-29265", "APID-29232"],
      "sourceRefs": [
        "https://github.com/tidbcloud/aisupport/issues/606#problem:wetech-auth-browser-sandbox-sigtrap"
      ],
      "signalTextIncludesAny": [
        "BrowserType.launch_persistent_context: Target page, context or browser has been closed",
        "signal=SIGTRAP",
        "op_batch_target_invalid",
        "diagnostic_wetech_batch_missing_after_acquisition"
      ],
      "observedThrough": "2026-08-10",
      "effectiveAt": "2026-08-10T18:39:01+08:00",
      "verifiedAt": null,
      "attemptedAction": "Remove the Wetech auth Agent, make acquisition Agent planning-only and offline, and have the runner execute exactly one argument-array readiness helper plus one serial batch per round with bounded signals, run-scoped TMPDIR, and compact outputs only.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/actions/runs/31379692471"
    }
  ]
}
-->

- Optimization ID: `deterministic-wetech-auth-bootstrap-2026-08-10`
- Owner: auto-oncall-services runner
- Source reference: staging `APID-29265` replay runs
  `48c07b3e-1549-44e3-9243-e89683ecbeb4` and
  `09676c41-ec3d-4cc9-9a74-7562bd62cb3a`; browser-transport verification
  run `ce5d46aa-fbd4-4d83-a641-ea88570e8cb7`
- Implementation status: deployed to staging in image `3995421bf077e7d54fd304c90bc648c01eff0acc`
- Effective status: `optimized_unverified`

## Bounded problem

The Wetech helper succeeds directly in the staging Pod, but the same
Playwright persistent-browser launch exits with `SIGTRAP` when an auth or
acquisition Agent runs it inside the Codex Linux sandbox. Filesystem allowlisting and a
run-scoped `TMPDIR` do not change that process-level incompatibility. Opening
the auth Agent to unrestricted execution would also reopen sibling run inputs.

This record owns only where the existing Wetech browser-backed transport is
executed. It does not change provider queries, scenario selection, batch or round limits, judgment,
Jira publication, attachments, required capabilities, or Focus lifecycle.

## Candidate change

- Do not create an auth Agent or auth model turn.
- Let the runner execute exactly one Wetech `datasources --prometheus-only`
  readiness command with an argument array and the frozen route target.
- Preserve the existing provider lock, 120-second helper login bound, outer
  bootstrap stage budget, headless browser profile, and no-fallback behavior.
- Keep only compact region, cluster, session, status, timing, and bounded
  failure fields. Do not persist datasource inventory, cookies, credentials,
  stdout, or stderr.
- Keep acquisition Agent planning-only and offline; let the runner execute the
  one serial batch outside the Agent sandbox, then materialize its compact
  handoff. Keep judgment Agent tool-free and offline.

## Verification evidence

Local tests execute fake readiness and batch helpers with the exact argument lists,
accept prefixed 2FA progress text, return only compact references, and prove a
datasource UID cannot escape into auth context. The auth-only deployment then
proved readiness in 25.5 seconds for run `9194bc0a-eb2d-48de-8602-447a152951b5`,
but its Agent-owned batch reproduced the same browser `SIGTRAP`; this bounded
the remaining change to provider transport. The complete local suite passes
with 711 tests.

The staging deployment completed through
[aisupport run 31379692471](https://github.com/tidbcloud/aisupport/actions/runs/31379692471)
and [app-delivery PR 76696](https://github.com/tidbcloud/app-delivery/pull/76696).
The live Pod was Ready with zero restarts on image `3995421bf077e7d54fd304c90bc648c01eff0acc`.
Read-only replay `ce5d46aa-fbd4-4d83-a641-ea88570e8cb7` then proved:

- runner-owned readiness resolved `wetech:asia-prod:SaaS01` in 24.4 seconds,
  with no auth Codex turn;
- the planning Agent invoked no provider command and did not inspect another
  run;
- the runner-owned serial batch completed in 56.0 seconds with ten queries,
  seven usable results, three explicit empty results, and no browser failure;
- the child handoff passed seven compact observations, three gaps, and ten
  artifact refs to the parent; and
- final evidence acquisition was `complete` with provider capability verified.

## Unresolved gaps

- A separate `APID-29265` replay, `0ec2e7b6-a081-4192-b5b4-2568635c6c1e`,
  classified a cluster alias but omitted `route.anchor.entity`; it stopped
  before readiness with `diagnostic_wetech_target_missing`.
- `APID-29232` replay `f2830456-9404-44e0-a231-7415ad66b310` supplied target
  `nowallet`, but readiness returned `diagnostic_wetech_readiness_target_invalid`.
  These target-resolution failures are outside this browser-transport record
  and must not be fixed here.
- No Jira comment has been changed.

## Next validation action

Handle the two target-resolution signals as separate bounded work. After their
own acceptance criteria pass, replay the affected case and, with explicit Jira
write authorization, update and read back the existing internal comment before
promoting this record to `optimized_verified`.