Fix Ci

# Detect PR number
if [ -n "$1" ]; then
  PR_NUMBER=$1
elif [ -f /tmp/envoy-active-pr.txt ]; then
  PR_NUMBER=$(cat /tmp/envoy-active-pr.txt)
else
  PR_NUMBER=$(gh pr view --json number -q '.number' 2>/dev/null)
fi

if [ -z "$PR_NUMBER" ]; then
  echo "Cannot find PR. Specify: /envoy:fix-ci <pr-number>"
  exit 1
fi

OWNER=$(gh repo view --json owner -q '.owner.login')
REPO=$(gh repo view --json name -q '.name')
BRANCH=$(git branch --show-current)

# Get latest check runs
gh pr checks $PR_NUMBER --json name,state,conclusion 2>/dev/null

Step 2: Poll for Check Completion

Checks may still be running. Poll with exponential backoff:

intervals = [30s, 60s, 120s, 240s]
timeout = 15 minutes

For each interval:
  - Query: gh pr checks $PR_NUMBER --json name,state,conclusion
  - If all checks resolved (pass or fail): break
  - If still running: report progress, sleep, continue
  - If timeout: report which checks are still pending

Step 3: Classify Failures

For each failed check, download the log and classify:

# Get failed run IDs
FAILED_RUNS=$(gh run list --branch $BRANCH --status failure --json databaseId,name -q '.[] | .databaseId')

# For each failed run, get the failed log
gh run view $RUN_ID --log-failed 2>&1

Classify each failure:

Scope note: Step 1 uses gh pr checks to detect all failures — this includes both GitHub Actions workflow runs and external status checks (e.g., Vercel, Netlify). However, log download via gh run list / gh run view --log-failed only works for GitHub Actions runs. If a failed check has no corresponding workflow run, classify it as infra-issue with the note: "External status check — check the service directly."

Step 4: Handle Infrastructure Failures

If ANY failure is classified as infra-issue, escalate immediately:

**CI Infrastructure Failure — Cannot Auto-Fix**

| Workflow | Error | Type |
|----------|-------|------|
| <name> | <error excerpt> | infra-issue |

This is not a code issue. Possible causes:
- GitHub Actions runner unavailable
- Docker image pull failure
- Permission/secret configuration issue
- Resource limit (OOM, disk space)
- Network timeout

Please investigate the CI infrastructure.

Do not attempt to fix infrastructure issues. Stop here for these.

Step 5: Diagnose and Fix Code Failures

For each non-infra failure, in order of severity:

Test failures:

1. Parse test name and assertion error from log
2. Read the failing test file
3. Read the source file the test exercises
4. Understand what changed (check recent commits)
5. Fix the source code (not the test, unless the test is wrong)
6. Run the test locally to verify

Build errors:

1. Parse file path and line number from error
2. Read the file at that location
3. Fix the compilation error
4. Run build locally to verify

Lint violations:

1. Try auto-fix first: npm run lint -- --fix or dotnet format
2. If auto-fix doesn't resolve: read the file and fix manually
3. Run lint locally to verify

Fix all failures from the current CI run before pushing. Diagnose and fix each failure in order of severity (test → build → lint), verify all fixes locally (Step 6), then commit and push once. One push = one fix cycle.

# After ALL failures are fixed and verified
git add <changed-files>
git commit -m "fix: resolve CI failures — <brief summary of all fixes>"

Step 6: Verify Locally

Before pushing, run the same checks CI uses:

# Run what CI runs (adjust for project)
dotnet test
dotnet build
npm test
npm run lint
npm run build

All local checks must pass before pushing. If they don't, go back to Step 5.

Step 7: Push and Re-poll

git push

Poll for new CI run results with exponential backoff (same as Step 2).

Step 8: Loop or Escalate (Max 3 Fix Cycles)

Uses a state machine with two counters:

• FIX_CYCLE — code fix pushes (max 3)
• CONFIRM_COUNT — consecutive passing confirmations (need 3 per lib/loop-safeguards.js)

state = POLL_CI
FIX_CYCLE = 0
CONFIRM_COUNT = 0