Multi-audience release notes from a Git tag

Build a Cosmos workflow that turns a freshly-pushed release tag into three audience-segmented release notes: executive, engineering, and customer: plus a committed changelog file.

Trigger: a webhook fires when a Git tag matching a release pattern (v*, prod-*, staging-*) is pushed. The matched prefix selects the target environment.

Steps:
1. Resolve the previous tag for the same environment by walking the tag history with the same prefix. Capture both the previous and current tag names, dates, and SHAs.
2. Decision: "Any commits since the previous tag?".
   - If no, post a short "no-op release" notice to the engineering Slack channel, append the result to the release log, and end.
   - If yes, continue.
3. Collect every commit and merged pull request in the range. Pull author, files touched, conventional-commit scope, and any CHANGELOG / breaking-change hints from PR bodies and trailers.
4. Fetch ticket metadata for every issue reference found in the commit messages and PR descriptions. Pull from Jira and Linear by id; record feature descriptions, breaking-change flags, and customer-impact tags. If a referenced ticket cannot be found, log the gap and continue with commit-message-only context for that change.
5. Classify the changes into features, fixes, deprecations, security, and infra/ops. Each entry keeps a link back to its commit, PR, and ticket.
6. Draft three audience-segmented release notes with the LLM:
   - Executive: business impact, KPI delta, top risks, rollback posture.
   - Engineering runbook: migration steps, config and feature-flag changes, monitoring alerts to watch, rollback procedure.
   - Customer-facing: new features, breaking changes, upgrade instructions, deprecations.
   On rate-limit or transient model errors, retry with exponential backoff (1s, 2s, 4s, 8s, capped at 60s, max 5 attempts) before failing the step.
7. Run a safety pass over all three drafts: redact secrets, internal hostnames, customer PII, and unannounced product names. Block any draft that still leaks before publishing.
8. Send the package to a release manager for sign-off. They can approve, request edits (loop back over the relevant draft), or reject.
9. Decision: "Approved?".
   - If no, file a manual-intervention ticket in Linear with the drafts, the failing checks, and the responsible commit / PR list, and page the release on-call. End.
   - If yes, post each segment in parallel to its Slack channel (exec-releases, engineering, customer-announcements) and commit CHANGELOG-{environment}-{version}.md to the repository on a dated branch with the release manager as PR author.

Constraints:
- Never publish anything that contains secrets, internal hostnames, customer PII, or unannounced product names: the safety pass is mandatory.
- Always cite the commit SHA, PR number, and ticket id behind every bullet so reviewers can audit the draft.
- Always require an explicit human sign-off before posting to customer-facing channels; auto-publish to internal channels only after that sign-off.
- LLM calls must use exponential backoff on rate-limit and transient errors; never silently drop a section because of a model failure.
- Append every run (no-op, published, intervention) to a release log so cycle time, ticket coverage, and breaking-change frequency can be tracked over time.