# Org ID Environment Boundary

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "org-id-environment-boundary-2026-08-11",
  "problems": [
    {
      "problemId": "cloud-ticket-misclassified-as-unsupported-op",
      "summary": "A Cloud ticket with orgId but no clusterId could be labeled as an unsupported OP account because the environment boundary used missing clusterId without checking the canonical Cloud identity.",
      "status": "optimized_verified",
      "issueKeys": ["ST-2886"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/ST-2886#problem:cloud-ticket-misclassified-as-unsupported-op"
      ],
      "signalTextIncludesAny": [
        "不支持的 OP 账号",
        "op_unsupported",
        "orgId present but clusterId missing"
      ],
      "observedThrough": "2026-08-11",
      "effectiveAt": "2026-08-11T10:51:03.000Z",
      "verifiedAt": "2026-08-11T10:52:02.602Z",
      "attemptedAction": "Make non-empty orgId the sole Cloud identity and missing orgId the OP identity across projects, then align provider routing, prompts, and OP publication correction with that boundary.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/pull/773"
    }
  ]
}
-->

- Optimization ID: `org-id-environment-boundary-2026-08-11`
- Owner: auto-oncall-services classification and runner contracts
- Source reference: `ST-2886`, staging Job `121146`
- Implementation status: merged and deployed to staging
- Effective status: `optimized_verified`

## Bounded problem

Job `121146` received an ST ticket with a non-empty Cloud `orgId` and no
`clusterId`. The unsupported-OP policy treated the missing cluster ID as the OP
environment signal and added `op_unsupported`, even though the ticket already
had the system-owned Cloud identity. The Feishu notification therefore reported
`不支持的 OP 账号` instead of preserving the Cloud classification and its
separate missing-target state.

This record owns only the Cloud-versus-OP identity boundary and its downstream
provider/prompt consistency. It does not make `orgId` sufficient for an exact
provider query, infer a cluster from an organization, add automatic reruns for
later Jira comments, or claim that ST-2886 could have been diagnosed before the
customer supplied its cluster ID.

## Candidate change

- Treat a non-empty typed Jira `orgId` as Cloud regardless of project key.
- Treat missing `orgId` as OP regardless of project key or `clusterId`.
- Apply Wetech and Manus Account Alias routing only inside the OP branch.
- Keep exact Cloud provider execution dependent on both `orgId` and
  `clusterId`.
- Align the classifier prompt, workspace contract, diagnostic preflight, and OP
  identifier-request correction with the same boundary.

## Verification evidence

Local and CI contract tests cover the `ST-2886` shape, cross-project Cloud
routing, missing-org OP routing, Account Alias precedence, Cloud provider input
requirements, and OP publication correction. PR
`https://github.com/tidbcloud/aisupport/pull/773` was deployed to staging as
image `5b5e4bc6a46cf88060ea6c8e3bbe3fbf04594995`. The Gate-only historical replay
then exposed a compatibility gap for the ticket's `bot_assignment` owner; PR
`https://github.com/tidbcloud/aisupport/pull/774` preserved that owner kind and
was deployed as image `df6aabe86bfe5d462ea3140c209408fc1bfb089e`.

At `2026-08-11T10:52:02.602Z`, the staging Gate recalculation for Job `121146`
completed with L1 and Auto Coverage both `allowed`. The persisted coverage Gate
was updated in place under `triggerKind=bot_assignment` and now records
`lookupKeysPresent=["orgId"]`, `missingKeys=[]`, `resolutionMode=direct_answer`,
and no `op_unsupported` risk flag. This verifies the bounded environment
classification change. The replay used the ticket's current comment timeline,
so it does not evaluate the quality of an answer at the original ticket cutoff.

## Unresolved gaps

- Job `121146` remains a historical `skipped` job with its original
  `lastError=auto_coverage_disabled`; Gate-only recalculation intentionally does
  not rewrite job execution history.
- No Jira internal comment exists for this skipped job, and no Jira write was
  attempted.
- The current-timeline Gate replay does not prove that a full answer generated
  at the original ticket cutoff would be useful without a cluster ID.

## Next validation action

Use a separate case with a replay-safe historical cutoff if answer-quality
improvement without a cluster ID is evaluated later; no further action is
required for the bounded environment-classification problem.