Add release-doctor agentic workflow for automated release pipeline monitoring

[Copilot]

The release pipeline has grown complex (prepare-release → PR → release → CHANGELOG update → package manifests), making failures difficult to diagnose. This adds automated monitoring and diagnostic issue creation.

Implementation

New agentic workflow (.github/workflows/release-doctor.md):

• Triggers on completion of prepare-release.yml, release.yml, update-package-manifests.yml
• Exits immediately on success; investigates only failures
• Uses GitHub Copilot engine with GitHub MCP server, cache-memory, and web-fetch tools

Seven investigation phases:

1. Early exit if workflow succeeded (no noise)
2. Triage failed jobs and extract context
3. Deep log analysis with pattern recognition
4. Release integrity verification (binaries, CHANGELOG sync, version consistency)
5. Historical pattern analysis via cache-memory
6. Root cause classification (build errors, auth issues, manifest failures)
7. Automated issue creation with diagnostic report

Verification checks:

• All 6 platform binaries present in GitHub release (Linux/macOS/Windows × AMD64/ARM64)
• CHANGELOG.md synchronized on main and release branches
• Cargo.toml version matches release tag
• Package manifest update PR created

Issue structure:

# Release Pipeline Failure: [Brief Description]

**Workflow Run ID**: 12345
**Commit**: abc1234

## Failure Summary
[2-3 sentence overview]

## Release Integrity Status
✅/❌ GitHub Release Created
✅/❌ All 6 Binaries Present
✅/❌ CHANGELOG Synchronized
✅/❌ Version Consistency

## Root Cause Analysis
[Detailed explanation with error logs]

## Recommended Actions
1. [Specific command or fix]
2. [Next action]

Permissions: Read-only except issues: write (via safe-outputs for security)

Documentation: Added release-doctor to the agentic workflows list in docs/design/agentic-workflows.md alongside other agentic workflows (Issue Triage Bot, Scout Research Agent, CI Doctor).

Example Scenario

When the release workflow fails to build ARM64 macOS binary:

1. Doctor analyzes build job logs
2. Verifies 5 of 6 binaries uploaded (missing darwin_arm64)
3. Checks if target was added (rustup target add aarch64-apple-darwin)
4. Creates issue with specific remediation: runner availability or toolchain configuration
5. Searches for similar past failures via cache-memory

Original prompt

Since the release pipeline is getting increasingly more complicated

pre-release -> PR -> release -> update homebrew and winget

We need a separate agentic workflow called release-doctor that can detect if the release process failed at some point (if one of the piepline jobs failed, the entire process should be considered failure) and then raise an issue to this repository to describe the failure.

You should figure out the right permissions that it should have to examine the workflows

It should have undersatnding of the release process and have visibility to jobs logs and artifacts propose the right fix.

It should also check if the release binary in github release page and make sure that the release note relfects the changes in the changelog and make sure that the versions in the main branch is the right version.

You should think about how this agentic workflow is triggered (perhaps at any point of the failure of the release pieplines)

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Mossaka]

@copilot delete

[Copilot]

Done in e55e3ed. Removed the CHANGELOG entry for release-doctor.

[Mossaka]

@copilot the monitor pipeline should not be in release.md. but it should be documented in the docs on what agentic workflow we use

[Copilot]

Done in e55e3ed. Moved the release-doctor documentation from RELEASE.md to docs/design/agentic-workflows.md where it's listed alongside other agentic workflows.