Know when a BugHerd fix is live before you retest

**Objective:** Tell whether the fix for task `{task-number}` in the BugHerd project `{project-name}` has been committed to `{repository}` and deployed from the branch `{branch}` (default main), so the task can be retested.

How the two systems are linked: a BugHerd task created from a GitHub issue carries "<repository>#<issue number>" in its external-id. A GitHub issue created from BugHerd starts its title with "[BugHerd <project name> #<task number>]".

**Step 1: Read the task**

Call `bugherd-get-projects` with `name.contains` set to `{project-name}`. If nothing matches, say so and stop. If several match, list their names and project-id values and ask which one; do not guess. Then call `bugherd-get-tasks` with `project-id` and `task-number` (then `bugherd-get-archived-tasks` if not found). If it is not found, stop.

**Step 2: Find the GitHub issue**

If the external-id is "{repository}#<n>", call `github-get-issue` with `company` and `issue-number` n. Otherwise call `github-get-issue` with `company` and `title.contains` set to "[BugHerd" plus the project name and " #" plus the task number. Note the issue's status and closed-date. If there is no issue, carry on with Step 3 using the task number alone.

**Step 3: Find the fixing commits**

Call `github-get-commit` with `company` and `message.contains` set to "#<issue number>" when there is an issue, and again with `message.contains` set to "BugHerd #<task number>". Keep commits dated after the task was created.

**Step 4: Check the deploy**

Call `github-get-workflow-run` with `company`, `branch` set to the branch and `created-date.from` set to the earliest fixing commit's commit-date. A run whose conclusion is success and whose sha is a fixing commit, or that started after the last fixing commit, has shipped the fix.

**Step 5: Report**

* **Verdict:** shipped, committed but not deployed, deploy failed, or no fix found.
* **Evidence:** issue (number, status, issue-url), commits (sha, author, date, first line of message), workflow run (name, run-number, conclusion, date, url).
* **Next step:** retest the page on the site, wait for a deploy, or chase the developer.

**Rules & Guidelines:**

* Tools named bugherd-... are on the bugherd MCP server; tools named github-... are on the github MCP server. Every GitHub tool takes the repository as its `company` parameter. If either set of tools is missing, say which server is not connected and stop.
* This prompt is read-only. Do not call any BugHerd write tool (`bugherd-add-task`, `bugherd-add-feedback`, `bugherd-update-task`, `bugherd-move-task`, `bugherd-add-comment`, `bugherd-add-attachment-from-url`, `bugherd-add-project`, `bugherd-update-project`, `bugherd-add-project-member`, `bugherd-add-guest-to-project`) or any GitHub write tool (`github-add-issue`, `github-update-issue`, `github-add-issue-comment`, `github-update-issue-comment`, `github-add-issue-assignee`, `github-add-issue-label`, `github-lock-issue`, `github-unlock-issue`, `github-add-milestone`, `github-update-milestone`, `github-enable-workflow`, `github-disable-workflow`, `github-rerun-workflow-run`, `github-cancel-workflow-run`).
* A commit mentioning the number is evidence, not proof; say so when the message is ambiguous.

**Validation:**

* If no issue and no commit mention the task, the verdict is "no fix found".