# Wetech Grafana application continuation after P81 MFA ## Owner and evidence - Owner: AOS Wetech Managed Tool Provider Executor, not the local compatibility helper, Evidence Agent, Scenario Diagnostic Agent, or Final Response Agent. - Base: fetched `origin/main` at `50369ad23b7a382bff00ee8ca050a7083f85534d`. - Exact failed operation: `op_693e46eccfcb41e7bf0d70db5b79ed88`, session `sess_4ef639d3a45a44c6a2a43f27d278bd98`, turn `turn_582855ac93864a778df205fc51d98cad`, Wetech v39 digest `5852eb8fc9709f32cb725ccbde7b91498044f5fb4e9435397b799fd1765a7ffc`. - Its safe `managed_tool_sandbox_diagnostic` from the live Agent9 Pod shows `p81_credentials_submitted`, `p81_totp_submission_attempted`, then `p81_totp_accepted`. The final page is the P81 tenant `/devices/downloads`; the Grafana `/api/user` probe still returns HTTP 307 to `/connect`. `pzeroApplicationEvents=[]`: no application connection was observed. - Current installation readback retains `networkAccess=unrestricted`. The result's package-level `networkMode=restricted` does not establish that the effective installation lost its grant. This exact failure has no recorded `INCONSISTENT_USER_AGENT` rejection, so the unrelated Dashboard response-body recovery branch is not the selected repair. - Query attempt 1 rejected `unit`; the same-turn changed attempt passed that validation and reached login. No invalid-unit relaxation is part of this repair. The separate Skill reads failed with `workspace setup failed` in Agent9; that Runtime failure is not repaired by changing Provider login. ## Change and preservation The Grafana loop recognizes only accepted MFA followed by `/devices/downloads` on the exact tenant host returned by the existing Pzero redirect probe. It returns to the configured original Grafana URL once using the existing `pzeroResumeAttempted` flag and remaining login budget. It does not submit credentials or MFA again, select another cluster, navigate an arbitrary application link, extend the deadline, or bypass explicit authorization errors. The local simulator also mounts the current source's imported `dashboard-query-contract.mjs`; without that mount its `/tool/index.mjs` cannot load the current package even when Docker is available. ## Validation history and remaining diagnostic boundary - TypeScript build passed. The deterministic test executes the production login loop against a fake browser: before the patch, both resume assertions failed; after the patch all six tests passed. It also preserves cached-session success, one-time resume, the original deadline, unrelated portal rejection, and explicit authorization failure. - Thirteen focused existing Grafana/Pzero/Dashboard/Docker package tests pass; syntax and diff checks pass. These are not real Provider data. - The first `npm run simulate:wetech-managed-tool` stopped before browser startup with `spawn docker ENOENT`. `/usr/bin/docker` then pointed to the absent `/mnt/wsl/docker-desktop/cli-tools/usr/bin/docker` mount. The user was asked to restore Docker Desktop's WSL integration. - Docker was restored by the user. Both the ordinary dedicated-state run and one isolated empty-state run completed the pinned Docker query, each returning one real series, six points, and maximum 1 for five-minute `vector(1)`. The empty-state request digest is `0af8057cc0e1e74c4b97c45d0333ae48b14cdc0e99e130f93078fd7cd42f29f0`. These verify local authentication and Provider transport, not live E2B. - Published immutable Wetech v40 package `a58f26cf0bd8315dea1d5b70f5dc646915097dae6a30d272493dc9eb7cfb2f0e` and bundle `c31d65dbf5693059ef8d99ab3ce7baca43e329360e3881c548529e5f342db487`; downloaded the exact versioned bundle and verified its SHA-256. Historical package objects remain pinned and unchanged. Publication alone grants no installation or execution authority; the candidate was not yet live at that publication step. - Full suite: 1098/1098 passed after updating the two affected version-39 package/release expectations to v40. No behavior was changed to silence them. - Source PR #1346 merged as `b21ab14d52f6e4d76f3ed07efd8e41b290ef1db5` after CI passed. AOS-owned package rollout loaded the new bundle into both Agent9 Pods with loader exit 0; their existing Agent9 image stayed unchanged. `/livez` and `/readyz` returned HTTP 200. - Staging release 33957518958 succeeded, upgrading the exact Evidence Agent installation to v40 with its existing `networkAccess=unrestricted` grant. app-delivery PRs #79324/#79325 merged. The live analysis service subsequently read back the source SHA above with Ready true, zero restarts, and HTTP 200 root/health/readiness endpoints. - One actual Agent9/E2B canary for `asia-prod/SaaS02` returned real five-minute `vector(1)` data (one series, six points, maximum 1) in 54066 ms. Session `sess_dfb532ed76224d6dadf3838c5da3c0fd`, Turn `turn_db747be27b16409f98ddb646e8e68203`, and Managed Tool operation `op_a67484ad65cc420cab4d90e3e97e93fa` bind that result to exact v40 digest. One preceding client setup stopped with HTTP 404 before any model Turn or Provider call because it read the session response's wrong ID field; fixing the canary client did not change production source or add a Provider retry. - One APID-29251 `mode=read` replay completed against the verified live image: run `050168a0-b27e-48fb-aad7-de368574b284`, HTTP 200, wall time 616711 ms, answer fingerprint `b5efd7ae497608dd1ac96fc9deded45d5fd0d4706321d36a3ae08a53de624095`. Evidence Skill reading succeeded this time. Five metric requests plus one Slow Query request completed without a Tool error. Acquisition is `complete`, capability verified true, and `failureCodes=[]`; the previous validation error and Pzero session failure did not recur. - All six historical queries returned empty results for 2026-07-26 09:00–09:55 UTC+8. This establishes successful transport, not retention expiry, an absence of historical hotspots, or valid SQL causality. Scenario Diagnostic remains inconclusive and the final answer does not confirm ANALYZE as root cause. Router retained `asia-prod/SaaS02` and customer confirmation; final `decision=human_required`. Judge returned `different_but_valid` with `eligibility=ai_human_required`, not a verified root-cause comparison. - `optimized_verified` applies only to this operational authentication and application-resume problem: deterministic regression, actual local data, exact-package live canary data, and the post-deployment ticket's successful Provider execution verify that boundary. It does not mark the ticket or its diagnosis optimization verified. Per the operational-change verification contract, this transport repair does not require a Jira comment refresh. - API response, exact canary result, and run evidence archive are retained in `~/.cache/aos-model-comparisons/20260905-wetech-v40-deployed-replay/`. Publication reports database/Jira/evaluation/Feishu all `not_requested`. No further replay is required for this repair. Investigating historical data coverage or screenshot-only causality is separate follow-up scope.