# Direct Jira recovery evidence: ST-2865 alert firing explanation

- Authorized action: use the already verified deployed replay body, skip a
  second replay, and update the existing Jira internal comment directly.
- Verified replay: `8edfd714-c07b-4a35-bafc-95a744ee9d94` with Judge verdict
  `ai_better` and no AI gaps.
- Existing DB mapping: `auto-live:v1:ST-2865:initial` already mapped ST-2865 to
  Jira comment `23432370`.
- Pre-write guard: issue key matched, comment ID matched, and Jira returned
  `public=false`.
- Write: direct Jira platform API `PUT` to comment `23432370` using the verified
  paired customer/Internal Only body; no replay was run.
- Readback: the same comment ID remained `public=false` and contained the new
  alert-rule explanation, the rule-equivalent metric boundary, the Support
  follow-up, and `自动回答: 是；人工处理: 否`.

## State boundaries

- No new comment, customer-visible write, Jira transition, or replay occurred.
- The DB mapping was already correct, so existing DB runs, evaluations,
  feedback, mapping timestamps, and Base rows were not rewritten.
- Jira normalizes Markdown inline code to its rendered `{{...}}` body form; the
  readback retained the expected text and semantics.
- This evidence records the authorized one-time Jira recovery and does not
  claim an atomic transaction between Jira and historical analytics views.