Deliver reviewed repairs through GitHub

When incident work moves into a repository, the evidence usually collapses into a two-line ticket, and the engineer rediscovers the contract, the assumptions, and the reason the fix was approved. GitHub delivery carries the whole chain across instead, while your repository's controls stay authoritative: Seamward never merges and never deploys.

The scenario

The email-rename repair from validate fixes before release is approved. The integration is mapped to acme/candidate-api, and the team wants the fix in their normal review flow.

What gets delivered

An issue, when the team needs the work tracked before a patch ships. Its title and body are generated from the incident:

[Seamward] Candidate webhooks: 15 observations changed shape at $.candidate.email_address
## Incident            summary, integration, affected records, observed release and commit## Proposed repair     - Copy `$.candidate.email` -> `$.candidate.email_address`### Assumptions        recorded assumptions, or "None recorded"### Evidence references linked observation and finding ids## Validation and approval   replay passed, risk, fingerprint, approver, rationale

Every issue ends with the same sentence, verbatim: "Seamward has not changed, merged, or deployed application code. An engineer must review and implement the approved repair."

A pull request, when the validated patch is ready for CI and review:

Branch   seamward/repair-rep_7f3k2m          based on the repository's default branchTitle    [Seamward] Candidate webhooks repair: 15 observations changed shape...Commit   fix: apply Seamward repair rep_7f3k2mStatus   draft by default, or open when explicitly selected; one or more approved filesBody     approved repair summary + integrity record (diff hash, patch and         proposal fingerprints, approver, rationale)

Delivery requirements

Delivery is available only when the internal state and the external access both hold: the proposal passed validation and carries an approval, the artifact fingerprint still matches what was approved, the integration has a live repository mapping, and the GitHub App installation has the needed permissions (draft PRs require Contents and Pull requests set to Read and write; Seamward reports github_pull_request_permission_required until they are).

The approval section identifies the exact authenticated reviewer captured at decision time, including the stored name, email, and workspace role. Seeded examples are explicitly marked as demo evidence. File names in the source review open the exact file at the immutable commit used to prepare the patch, and existing source line numbers link to their corresponding GitHub lines.

Deliver for review

1. Review the destination and the generated content in Seamward. Preparing the patch does not write to GitHub.
2. Confirm the external write once. The dialog states the exact repository and that Seamward will not merge or deploy.
3. Open the resulting issue or draft PR from the recorded delivery.
4. Continue review, CI, merge, and deployment in your repository workflow.

After a pull request is merged

Configure the Seamward GitHub App to receive Pull requests webhook events. A signed pull_request event updates the matching delivery by repository and pull request number. Seamward records whether the pull request is Draft, Open, Closed, or Merged, plus the merge commit, time, and GitHub actor when GitHub reports a merge.

The incident remains open after merge because a GitHub merge does not prove that the change is running. Deploy the change through your normal release workflow and send monitored traffic. Existing health checks continue to decide whether the incident criteria have cleared. Automatic attribution of a deployment to the recorded merge commit is planned and is not part of the current merge webhook flow.

Safety mechanics

The delivery machinery is built to fail closed:

• Idempotent: a hidden marker ties each delivery to its artifact, so retrying finds the existing issue or PR instead of duplicating it.
• Conflict-safe: if the review branch moved since the patch was prepared and its content differs, delivery stops with github_branch_conflict rather than overwriting anything.
• Access-safe: an uninstalled or suspended installation, or a removed repository grant, fails delivery with github_repository_unavailable instead of silently choosing another destination.
• Least privilege: every operation mints a short-lived token scoped to the single repository and the minimum permission it needs.
• Webhook-authenticated: merge state changes only from a correctly signed GitHub webhook, and the GitHub delivery identifier makes repeated events idempotent.

Operating boundaries

• Issue and pull request title and Markdown content are reviewable and editable before delivery.
• Pull request creation requires an explicit Draft or Open choice.
• Seamward does not merge branches or deploy releases.
• Repository protections and CI remain authoritative after delivery.
• Pull request merge tracking requires the GitHub App's Pull requests event subscription.
• Failed access checks stop delivery and preserve the failure state for review.

Related: Open a repair pull request for the step-by-step, and Permissions and safety for the grant model.