Judge a release by what it broke and what Jira is tracking

**Objective:** Report the quality of release {app-version} of Bugsnag project {bugsnag-project-name}: the errors it introduced, and the Jira work in project {jira-project-key} that moved in the same window. Read-only.

**Step 1: Establish the release (bugsnag server)**

Call `bugsnag-get-release` filtered by project-name {bugsnag-project-name} and app-version {app-version}. Keep release-date, release-stage-name, errors-introduced-count, errors-seen-count, total-sessions-count and unhandled-sessions-count. If nothing comes back, list the recent app versions for the project and stop. If more than one build matches, use the earliest release-date and say so.

**Step 2: The errors since that release (bugsnag server)**

* Call `bugsnag-get-error` filtered by project-name {bugsnag-project-name} with last-seen from the release-date. Keep error-id, error-class, message, events, users, severity and status.
* Call `bugsnag-get-event` filtered by app-version {app-version} to confirm which of those errors actually occurred on this build. An error last seen after the release date did not necessarily occur on this version, so treat the event check as the evidence.

**Step 3: The Jira work in the same window (jira server)**

Call `jira-get-issue` filtered by project-key {jira-project-key} with updated from the release-date. Keep issue-key, summary, status, assignee and updated-date.

Then correlate: an issue whose summary contains one of the error ids from step 2 is a confirmed match. Everything else is only date-window context. Label the two apart and never present a date-window item as a confirmed link.

**Step 4: Report**

* A header line: version, release date, stage, sessions, unhandled session rate.
* Errors confirmed on this version, worst first by event count, each marked tracked or untracked in Jira.
* Jira issues updated in the window that are not linked to any of those errors, listed as context only.
* One closing line on whether this release looks better or worse than the release before it, using errors-introduced-count if you can read the previous release with `bugsnag-get-release`.

**Rules & Guidelines:**

* `bugsnag-get-release`, `bugsnag-get-error` and `bugsnag-get-event` are on the bugsnag server. `jira-get-issue` is on the jira server. Both servers, plus this one, must be connected.
* This prompt is read-only. Do not call `jira-add-issue`, `jira-add-issue-comment`, `jira-update-issue`, `bugsnag-fix-error` or `bugsnag-ignore-error`.
* Bugsnag and Jira share no key here except the error id in an issue summary. Say which correlations are by key and which are by time window.

**Validation:**

* If the version string in Bugsnag and the wording used in Jira differ in format, do not normalise them into a match. Report them as unmatched.
* If step 2 returns errors but no events for the version, report that the errors predate or postdate the build rather than attributing them to it.
* If Jira returns nothing in the window, say the window was quiet rather than implying no work was done.