Deliver reviewed repairs through GitHub

Why repair context belongs in GitHub

Preserve incident evidence and approval history when work moves into the repository workflow.

A repair without its incident context is difficult to review and easy to misapply. Repository reviewers need to know what failed, which evidence supports the change, what deterministic validation established, and which assumptions remain.

GitHub delivery is a separate use case because creating an external review artifact has different permissions and consequences from detecting an incident or approving a proposal inside Seamward.

When to use this workflow

Choose GitHub delivery after investigation or validation is complete and a repository is mapped.

Use this workflow when the investigation or validated repair is ready to enter the repository team’s normal planning and review process.

• Create an issue when engineering work is understood but no approved patch is ready.
• Create a draft pull request when an approved proposal has a prepared review patch.
• Preserve the incident and validation references with the delivery record.
• Use standalone export when GitHub access is not available or desired.

Delivery requirements

Confirm the approved proposal, repository mapping, and current GitHub access.

Delivery is available only when the internal review state and external repository access agree. Re-check both immediately before creating an issue or draft pull request.

• The proposal passed deterministic validation.
• A reviewer recorded an approval.
• The integration has a current repository mapping.
• The GitHub App can access the selected repository.

Review the destination

Check the repository, base branch, service path, and delivery content.

Check the repository, base branch, service path, observed commit, and proposed content before creating an external record. Stop when any destination differs from the approved integration mapping.

Repository access can change after an integration is mapped. A revoked installation or removed repository grant must stop delivery rather than silently choosing another destination.

Deliver for review

Create an issue or draft pull request without merging or deploying the change.

Create a GitHub issue when the team needs investigation or implementation work. Create a draft pull request only when a validated patch is ready for the repository’s normal CI and review process.

1. Review the destination and generated delivery content in Seamward.
2. Confirm the external write action once.
3. Open the resulting issue or draft pull request from the recorded delivery.
4. Continue review, CI, merge, and deployment in the repository workflow.

Operating boundaries

Keep CI, review, merge, and deployment under the repository team’s existing controls.

• Issue and draft pull request creation require explicit confirmation.
• Seamward does not merge branches or deploy releases.
• Repository protections and CI remain authoritative after delivery.
• Failed access checks stop delivery and preserve the failure state for review.

• Open a repair pull requestReview requirements, patch preparation, and delivery boundaries.
• Permissions and safetyUnderstand repository grants and external write controls.