Fix Pipeline

---
name: workflow:remote:fix-pipeline
description: Iterative pipeline repair loop until successful completion
argument-hint: "--portal <platform> [--file <path>] [--project <name>] [--repo <name>] [--pipeline <id-or-name>] [--branch <branch>] [--target-branch <branch>] [--deps <repo>:<branch>[,<repo>:<branch>...]] [--work-item <id>] [--run <id>] [--max-iterations <count>] [--description <text>]"
parameters:
  - name: portal
    description: DevOps platform (azure)
    required: true
  - name: file
    description: Local workspace file path (e.g. pipeline YAML) — infers project, repo, branch, and pipeline from git worktree metadata
    required: false
  - name: project
    description: Azure DevOps project name — can be inferred from --file
    required: false
  - name: repo
    description: Repository name — can be inferred from --file
    required: false
  - name: pipeline
    description: Pipeline ID or name to fix — can be inferred from --file
    required: false
  - name: branch
    description: Working branch for the primary pipeline repo — can be inferred from --file
    required: false
  - name: target-branch
    description: Base branch for pull requests (defaults to main)
    required: false
  - name: deps
    description: Comma-separated list of additional repo:branch pairs that the primary pipeline references (e.g. template-repo:feature/fix,shared-lib:feature/fix) — each receives its own remote:implement invocation
    required: false
  - name: work-item
    description: Work item ID to link fixes to (optional; skips work-item phases in remote:implement when absent)
    required: false
  - name: run
    description: Starting run ID to debug (defaults to latest)
    required: false
  - name: max-iterations
    description: Safety limit on loop iterations (default 5)
    required: false
  - name: description
    description: Additional context or instructions for the operation
    required: false
agents:
  - name: zzaia-devops-specialist
    description: Queries pipeline logs, triggers runs, tracks run IDs and completion status
---

## PURPOSE

Automate iterative pipeline repair by cycling through debug, fix, and re-run phases until the pipeline completes successfully. Each iteration collects structured issue reports from pipeline logs, implements targeted fixes, triggers a new run, and evaluates results. The loop terminates on success or when max iterations is reached.

## WORKFLOW PHASES

1. **Initialize Loop** — Resolve parameters and set iteration counter; no pipeline calls in this phase

   - Set iteration counter to 0 and record start time
   - If `--file` is provided, resolve git worktree context to infer `--project`, `--repo`, `--branch`, and `--pipeline` from remote URL, current branch, and YAML filename
   - If `--deps` is provided, parse it into a list of `{repo, branch}` pairs to form the **working-set** alongside the primary `{repo, branch}`
   - If `--deps` is not provided, inspect pipeline YAML `resources.repositories` and `extends.repository` blocks to auto-detect referenced repos; for each detected repo, use the `ref` field value in the YAML as the branch (strip `refs/heads/` prefix); if no `ref` field is present, use the primary `--branch`; add each `{repo, branch}` pair to the working-set
   - Store working-set, parameters, and iteration counter in session state — this phase runs exactly once

2. **Debug Pipeline** — Collect structured failure report for the current run

   - Call `/behavior:devops:pipeline --action debug` with `--portal <portal> --project <project> --pipeline <pipeline> --branch <branch>`; if `--run` was provided (or a run ID was captured in a previous iteration), include `--run <run-id>`; omit the argument when no run ID is known, letting the behavior resolve the latest run
   - Capture structured issue report with all failed steps, errors, and warnings; map each failure to the repo in the working-set that owns the affected file
   - Record the run ID returned by this call for use in subsequent iterations
   - Record initial issue count for this iteration

3. **Implement Fixes** — Invoke `remote:implement` once per repo in the working-set

   - For each `{repo, branch}` in the working-set that has failures attributed to it:
     - Call `/workflow:remote:implement` with:
       - `--portal <portal> --project <project> --repo <repo> --working-branch <branch> --target-branch <target-branch|main>`
       - `--description "Fix pipeline failures: <failures-attributed-to-this-repo>"`
       - `--work-item <work-item>` if provided; omit otherwise
       - `--auto-continue`
     - `remote:implement` returns a fix summary containing: list of modified files (with repo and relative path), commit SHA, and PR URL
   - Invoke all `remote:implement` calls sequentially in dependency order (dependency repos first, primary repo last)
   - Collect all fix summaries for use in Phase 4

4. **Configure Template Resource** — Point the primary pipeline to dependency branches when a referenced pipeline was changed

   - Inspect fix summaries from Phase 3: a dependency repo was changed if any modified file's repo matches a repo in the working-set other than the primary repo
   - **If no dependency repo was changed**: skip this phase entirely and proceed to Phase 5
   - **If one or more dependency repos were changed**:
     - For each changed dependency repo, call `/behavior:devops:pipeline --action update` to patch the primary pipeline's `resources.repositories` entry for that repo, setting `ref` to `refs/heads/<dependency-branch>`
     - If the primary pipeline does not yet have a `resources.repositories` entry for a dependency repo, call `/behavior:devops:pipeline --action create` to register a minimal validation pipeline that includes the dependency branch reference
     - Set `<pipeline>` to the updated/created pipeline for all subsequent phases
   - **MANDATORY** Every dependency repo `ref` in the primary pipeline must target `refs/heads/<dependency-branch>` bef