Create a gust_auto_heal app for automatically repairing failed DAG runs

[marciok]

Summary

Create a new umbrella application, tentatively named gust_auto_heal, that integrates with Gust and can investigate failed DAG runs, propose a code change, validate the change, and open a pull request containing the repair.

The goal is to provide an opt-in auto-healing workflow while keeping every generated change reviewable and auditable.

Proposed workflow

1. Detect or receive a failed Gust run.
2. Inspect the run, failed task, error details, stacktrace, logs, DAG definition, and relevant source files.
3. Create an isolated working branch.
4. Generate the smallest targeted code change that addresses the failure.
5. Run configured validation commands, such as focused tests and mix precommit.
6. Push the branch and open a pull request describing:
   • the failed run and task;
   • the diagnosed cause;
   • the generated change;
   • validation results;
   • any remaining risks or uncertainty.
7. Record the healing attempt and PR URL so it is visible from Gust.

MVP scope

• Add a separate umbrella app with a clear boundary from the core gust runtime.
• Provide an explicit API or job entry point for requesting a healing attempt for a failed run.
• Read the failed run context through supported Gust interfaces rather than direct assumptions about UI state.
• Support a configurable repository, base branch, validation commands, and PR provider credentials.
• Open a draft PR only after the generated change passes the configured validations.
• Prevent concurrent healing attempts for the same run.
• Persist statuses such as queued, investigating, validating, pr_opened, and failed.

Safety requirements

• The feature is disabled by default and must be explicitly configured.
• Repository access uses least-privilege credentials.
• Generated changes are limited to an isolated branch and never pushed directly to the default branch.
• Secrets, task payloads, and logs are redacted before being sent to any model or external service.
• Every action and model decision is auditable.
• Failed validation must not open a ready-for-review PR; retain diagnostics for investigation.
• Add configurable limits for retries, changed files, execution time, and healing cost.

Acceptance criteria

• A failed run can trigger an auto-heal attempt through a documented interface.
• The new app gathers enough run and repository context to produce a targeted patch.
• The patch is applied in an isolated branch and validated with configured commands.
• A successful attempt opens a draft PR with the run context and validation summary.
• Gust exposes the healing status and resulting PR URL.
• Failure paths are persisted and surfaced without affecting normal DAG execution.
• Include focused tests for successful healing, failed validation, duplicate requests, redaction, and PR creation failure.

Open design questions

• Final app name: gust_auto_heal or gust_heal.
• Whether failed runs trigger healing automatically or require a manual action.
• Which model/provider abstraction should generate and review patches.
• Whether GitHub integration should use the CLI, REST API, or a GitHub App.