---
name: runtime-evidence
description: Verify Auto Oncall questions against live Jira and Kubernetes evidence. Use for Jira issue links or keys, deployed configuration, pod health, staging or production logs, rollout state, and any request whose answer may differ from repository templates.
---

# Runtime evidence

Start with live evidence whenever the request concerns current behavior. Repository manifests describe intended state; they do not prove deployed state.

## Jira

Use `$CODEX_HOME/skills/runtime-evidence/scripts/jira-get.sh` for authenticated read-only Jira requests. Pass only a Jira REST path beginning with `/rest/api/3/issue/`, `/rest/api/3/myself`, or `/rest/servicedeskapi/request/`.

For mention or continuation problems, fetch the complete paginated comment timeline from the Jira platform API and inspect the raw ADF `mention.attrs.id`; visible `@name` text is not sufficient. Determine the expected Auto Oncall bot account ID from the live `auto-oncall-services` ConfigMap or Deployment environment, normally `AUTO_ONCALL_BOT_ASSIGNEE_ACCOUNT_ID`, in the environment that owns the behavior. Compare the ADF ID with that configured target. Repository manifests are only a fallback and must be reported as intended rather than live state.

`/rest/api/3/myself` identifies the Jira credential principal. It is not the expected mentioned bot unless live configuration explicitly uses that same account ID. Report this distinction instead of treating a human read-only Jira identity as the bot. Also confirm the comment is internal.

Never use POST, PUT, PATCH, or DELETE. Never print authentication variables.

## Auto-oncall database

Use `$CODEX_HOME/skills/runtime-evidence/scripts/database-query.py` for canonical
Auto-oncall job, run, gate, ticket-fact, feedback, and evaluation records. Pass
one read-only SQL statement with `--sql`; use `--max-rows` to lower the default
1000-row output bound when appropriate. The configured database identity has
only `SELECT` on the Auto-oncall staging database.

Start from database records when the question asks for a population, time
window, feedback presence or absence, or a join across Auto-oncall entities.
Jira access by a known issue key does not prove that the same identity can
enumerate the complete Auto-oncall population. After the database identifies
the bounded issue keys, use Jira to refresh fields such as the current
assignee when current Jira state is required.

Never print `AUTO_ONCALL_DATABASE_URL`. Never send a mutating SQL statement.

## Kubernetes

Use `kubectl` with the contexts present in `$KUBECONFIG`:

- `devops-staging-observer`: staging runtime.
- `devops-prod-observer`: production runtime when installed.

Read deployments, replicasets, pods, configmaps, jobs, cronjobs, events, services, endpoints, and pod logs. Do not request Secrets, exec into pods, port-forward, or perform a mutating command. Treat a missing context or RBAC denial as unavailable evidence.

## Agent9 sessions

Use `$CODEX_HOME/skills/runtime-evidence/scripts/agent9-session-get.py` to read
the display-safe Agent9 Console view for one exact Session. For a current replay,
take every non-null Session ID from the canonical response at
`runtimeTrace.calls[].threadId`, de-duplicate it, and retain each call name and
outcome as correlation context. `result.codexThreadId` is only a compatibility
fallback for older or single-thread direct-path responses. For one exact
Provider or runtime operation, also pass its operation ID from the Auto Oncall
run trace or Agent9 Session detail.

The script only permits `GET /api/console/sessions/{sessionId}` and
`GET /api/console/sessions/{sessionId}/operations/{operationId}`. It does not
list unrelated Sessions, read arbitrary files, mutate Agent9, or print the API
key. Correlate one investigation in this order:

1. Jira issue key and the persisted Auto Oncall job/run;
2. the replay `runId` and `runtimeTrace.calls[]` runtime correlation records;
3. each exact Agent9 Session, Turn, AgentRun, and referenced Operation record.

Do not require an `agent9` marker inside provider evidence. Platform identity
comes only from `runtimeTrace.backend`; provider evidence remains portable
across the Kubernetes and Agent9 execution backends. Runtime correlation is
operational metadata and must not be interpreted as diagnosis or Provider
evidence.

## Clinic and Wetech

Use the separately installed `clinic-api` and `wetech-op-grafana` skills when their trigger conditions apply. Follow their evidence and credential boundaries exactly. Do not substitute repository-only conclusions when a provider query fails.

## Required final evidence status

End every response with `信息来源与缺口` containing:

- live sources successfully queried;
- sources attempted but unavailable, including the exact bounded failure;
- effect of each gap on the conclusion;
- verdict `已验证` or `基于有限证据推断`.

Do not call a conclusion verified when the decisive live source was unavailable.