# PR-Fix Workflow

Detailed execution workflow for `github-pr-fix`.

## 1) Context intake

1. If `${GITHUB_CONTEXT_DIR}/manifest.json` exists, read it first.
2. When a manifest exists:
   - confirm `kind=pr` and collection status
   - resolve available artifacts by id/path/status
3. If no manifest exists, collect PR context directly with `gh`:
   - `gh pr view <pr_number> --repo <owner/repo> --json ...`
   - `gh pr view <pr_number> --repo <owner/repo> --json files`
   - `gh api repos/<owner>/<repo>/issues/<pr_number>/comments --paginate`
   - GraphQL query for review threads when replies must be deduplicated

Use only artifacts marked `status=present`.  
If critical artifacts are missing, document limitations before remediation.

## 2) Triage and prioritization

Identify all actionable problems, then fix in order:
1. build/compile blockers
2. failing tests/regressions
3. type/import/module issues
4. lint/style issues

Treat large non-blocking refactors as defer candidates.

## 3) Fix and verify

1. Apply targeted code fixes.
2. Run relevant verification commands.
3. Commit and push fixes to the existing PR branch.

Do not publish replies before push completes.

## 4) Publish replies

Use direct `gh api` reply operations for review-thread replies and related comments.

## 5) Finalize outputs

Write/update:
- `${GITHUB_OUTPUT_DIR}/summary.md`
- `${GITHUB_OUTPUT_DIR}/manifest.json`

## Completion criteria

Run is successful only when:
1. Required fixes are committed and pushed.
2. Replies planned for this run are published.
3. `summary.md` records the replies that were posted and any residual risks.
