/resolve-publish

name: resolve-publish
description: Commit the validated fix and follow local-only, workflow-owned, or direct PR publication.

Step 3 — Commit, push, and open the pull request (author path only)

This step applies **only when you authored a fix in Step 2B** — it's about *opening* a PR. (The review path 2A adopts the existing PR instead of opening one, then goes straight to Step 4 to land it.) Once the set is genuinely green:

**Check again before publishing.** Once the fix and PR body are ready, repeat Step 1's search immediately before creating a new PR, or before the final handoff to a CI publisher. Inspect only new or changed candidates, using Step 2A if one may cover the bug; preserve your work while evaluating it. Recheck the state of earlier candidates too: if one merged, use the shared repro audit on updated main before deciding whether your fix is still needed. Record the check and decision in `fix_summary`. Skip this refresh for `skip_push` and updates to an existing PR.

Choose the publication mode before proceeding

• **Local-only (`skip_push: true`)** — commit the fix and stop at Step 3.2. No PR

will be published automatically, so do not prepare a PR body or run Step 4. This takes precedence even when CI appended a generic publisher contract.

• **Workflow-owned publication (`skip_push: false` plus an explicit CI publisher

contract)** — do not push or make any `gh` write. Prepare and validate `.omnigent/pr-body.md` using the body-writing instructions in Step 3.4, but do not run its `gh pr create` command. Complete the deferred live-validation preparation described in Step 4.4, then write the final handoff and stop. The publisher performs the GitHub writes; do not run the PR-facing CI/preview/review loop in the rest of Step 4.

• **Direct publication (no publisher contract)** — perform all of Step 3, then

drive the published PR through Step 4, except for the draft proposal below.

**Unresolved design choice:** after completing the investigation and available validation in `resolve-investigate`, publish a direct author proposal with `gh pr create --draft`. Explain the choice, evidence, alternatives, and remaining checks in the body. Emit a `partially_fixed` handoff with the decision in `remaining_work`. Skip preview, readiness checks, and the Step 4 review loop that requires a ready PR; do not mark it ready merely to trigger automation. This is a reviewable proposal, not proof the bug is fixed. For workflow-owned publication, prepare the same body and incomplete handoff and obey the supplied publisher contract; do not assume it supports drafts. `skip_push` still means local only.

In workflow-owned mode, `.omnigent/` is intentionally gitignored, so body transport does not rely on the file being committed. The workflow captures `pr-body.md` separately in the resolve artifact bundle alongside the committed checkpoint, then restores it into the publication worktree before running the PR finalizer. The finalizer validates and uses that restored file as the PR description; without it, the publisher can only construct a less readable fallback from machine-oriented handoff fields.

Checked publication provided by CI

When `.omnigent/pr-gate.json` exists, use the `pr.py` helper supplied in the `resolve-drive-pr` skill directory. This mode replaces the direct GitHub write and token-recovery recipes below. Keep Git pushes on the supplied credential; never decode another token or change credential configuration.

| Action | Helper arguments | | --- | --- | | Open a PR after the required checks | `create --title TITLE --body-file FILE --base main` | | Update its description | `edit --number N --body-file FILE` | | Reply to findings | `comment --number N --body-file FILE` | | Submit a review without approval | `review --number N --head SHA --event COMMENT --body-file FILE` | | Mark a draft ready | `ready --number N` |

Run the helper from the fix checkout. Use `review_cycle.py request` for review requests; CI routes it through the host. Follow CI's review budget and warning policy. Actions the helper does not support remain maintainer actions; never recover a broader credential, approve, or merge to work around that boundary.

Legacy direct publication: GitHub write token

The following token setup applies only when CI has not supplied the checked publication helper and has explicitly authorized direct publication.

Any write to GitHub — `git push`, `gh pr create`, `gh pr edit --add-reviewer`, `gh pr comment`, `gh pr close` — needs the resolve-agent App installation token (`omni-resolve-agent[bot]`, Contents and Pull requests: write; Actions: read and write on `omnigent-ai/omnigent`). Actions access is needed to read review runs and completion artifacts and dispatch both review workflows.

**Your shell does not inherit it in a usable env var**: you run inside the session's runner process (a different process, often a different machine when hosted on `--server`), so `$GH_TOKEN` in your shell is empty and a bare `git push` fails with a 403 / permission error. This is **not** a missing/expired/read-only token — the write credential IS on this machine, in the git config of your checkout. Recover it before any GitHub write.

**The reliable source is the checkout's persisted `http.extraheader`.** `actions/checkout` bakes the App installation token into your repo's git config as an `AUTHORIZATION: basic <base64>` header (git worktrees share it via the common config, so it's readable from your fix worktree too). Decode it and export it as `GH_TOKEN`:

# Run from anywhere inside your checkout / fix worktree. The extraheader value is
# base64("x-access-token:<token>"), so strip the prefix, base64 -d, take the part
# after the colon.
export GH_TOKEN="$(git config --get http.https://github.com/.extraheader \
  | sed 's/^AUTHORIZATION: basic //' | base64 -d | cut -d: -f2-)"
[ -n "$GH_TOKEN" ] || echo "no extraheader token found in git config"
gh auth setup-g