# Manus Monica Target Support

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "manus-monica-target-2026-07-21",
  "problems": [
    {
      "problemId": "manus-monica-target-not-supported",
      "summary": "Manus OP documentation defines vida and monica, but auto-oncall only supports the vida target.",
      "status": "optimized_verified",
      "issueKeys": ["*"],
      "sourceRefs": [],
      "signalTextIncludesAny": ["manus monica", "monica target", "monica cluster", "manus only supports vida"],
      "observedThrough": "2026-07-21",
      "effectiveAt": "2026-07-21T04:06:00Z",
      "verifiedAt": "2026-07-21T04:10:00Z",
      "attemptedAction": "Add exact monica routing, direct Prometheus metrics, target-specific Dashboard credentials, and no-fallback target selection.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/pull/400"
    }
  ]
}
-->

- Optimization ID: `manus-monica-target-2026-07-21`
- Owner: auto-oncall-services
- Source type: internal Manus OP environment documentation correction
- Source reference: Manus Grafana and Dashboard Wiki revision 226
- Bounded problem: the Manus transport and diagnosis routing hard-code `vida`,
  while the documented OP production environment contains both `vida` and
  `monica`.

## Status

- Implementation: complete in `tidbcloud/aisupport#400`
- Effective/deployment: staging image
  `9138c1c2b7a2617e183364c12560cc136a2e640b`; app-delivery registration
  `tidbcloud/app-delivery#75040`; image rollout `tidbcloud/app-delivery#75042`
- Problem status: `optimized_verified`

## Baseline evidence

- The live skill target map contains only `vida`.
- The Manus environment document lists `vida` and `monica` as separate targets
  with separate endpoints.
- `monica` Dashboard authentication succeeds with its documented credential;
  its direct Prometheus health and build-info endpoints return HTTP 200.
- Existing `vida` Grafana credentials and the documented `monica` Dashboard
  credential both return HTTP 401 against `monica` Grafana, so the change must
  not pretend that Grafana access is available or share credentials across
  targets.

## Post-change verification

- Verified at `2026-07-21T04:10:00Z` on the live staging pod.
- Deployment and Recent Optimizer both run image `9138c1c2...` and reference
  the target-specific `MANUS_MONICA_DASHBOARD_*` keys from the manually managed
  Secret.
- Installed target map contains exactly `vida` and `monica`.
- `health --target vida` passed with Grafana datasource `vida` and Dashboard
  authentication; `health --target monica` passed with direct Prometheus and
  its target-specific Dashboard authentication.
- `sum(up)` returned numeric series for both targets: `vida` 11 points and
  `monica` 11 points.
- Slow Query Dashboard reads returned records for both targets. The live
  field-selection response reported `process_keys` and `total_keys` in the
  requested projection with no unsupported fields.
- Runtime classification selected `manus_target:monica` only when `monica` was
  explicit; missing or ambiguous targets remained `clarification_needed` with
  `manus_target` missing.
- Deployment was ready at generation 157; DB had no `queued` or `running`
  jobs; post-rollout logs contained no failure event.

## Unresolved gaps and next action

- This optimization was sourced from the Manus environment document, not from
  a Jira case, so there is no existing Jira internal comment to refresh.
- On the first real monica Jira case, rerun its dry-run after analysis, verify
  the exact-target evidence path, and update the mapped Jira internal comment
  so later Focus and report generation consume the post-change answer.