The last mile of the trail: ticket → PR → review → production deploy. Live cards follow the PR; this chain follows the deploy.

When it fires

GitHub deployment succeeded in production or prod. Merge is not enough. Approval of a waiting environment gate is not enough. The chain waits up to 300 seconds for a pull-request association, then announces with the rollout_changelog template.

Match the environment name you actually use in GitHub (prod still matches a condition written as production).

What Slack gets

<org/repo> shipped to prod
Pull requests
• #<n> <title> — @author
Commits without a pull request
• <short SHA> <commit subject>
Open deployment monitoring in Warestack

If Warestack resolves a pull request, it includes number, title, author, and GitHub link. If it cannot resolve one, it preserves the deployed SHA as an unassociated commit instead of inventing a PR. The announcement includes a Warestack monitoring link.

Requires exactly one Slack announcement. Put it on the deploy-producing repository, not on a helper repo that never deploys.

Setup

1. Confirm recent GitHub deployments: environment name, success vs failure, associated PRs.
2. Enable production_rollout_changelog on that repo, Slack destination, condition on the production environment.
3. Dry-run is not available for historical deploys; the next successful prod deploy is the proof.

Use Automation activity to confirm the wait and announcement outcome.

Propose this when

Recent GitHub deployments succeeded in production or prod on a named repo. Scope: that deploy-producing repository. Kind ID: production_rollout_changelog.

Do not

• Put this chain on a helper repo that never deploys.
• Treat merge, or a waiting environment gate, as the trigger.
• Guess the environment name — read GitHub, or write unknown.