/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.

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.

Get the GitHub write token (needed for every push / `gh` write)

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`+`pull_requests` write on `omnigent-ai/omnigent`). **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-git   # route git pushes through gh's credential helper with this token

• Do this **once** at the start of Step 3 (and again in Step 4 if a later

`gh`/`git push` call reports it lost auth). Then push, open the PR, request the reviewer, and comment normally — all of them use this token. Confirm it works and is write-scoped with `gh auth status` / a cheap `gh api /repos/omnigent-ai/omnigent` before relying on it.

• **Do not go hunting elsewhere first.** The token is **not** reachable via

`/proc/*/environ` (that is denied in the session sandbox), and the ambient `github-actions[bot]` credential is read-only on `omnigent-ai/omnigent` (it's scoped to `omnigent-internal`) — both are dead ends that waste the turn. The extraheader above is the one that works.

• If the extraheader is genuinely absent (rare — e.g. a `skip_push` run, or the

checkout didn't persist it), report that exact fact in `maintainer_review` with the command output. **Never** substitute a guess like "token expired" or "PAT is read-only" — those are false and drop the hand-off silently. Only a real, quoted failure goes in `maintainer_review`.

• CI may also configure `omnigent.forkPushTokenFile`. That is a separate

maintainer credential for one purpose only: pushing a fix to an existing fork PR whose author enabled maintainer edits. Never export it as `GH_TOKEN` and never pass it to `gh`; PR creation, comments, reviews, labels, and every other visible action must continue using the App token so GitHub attributes them to `omni-resolve-agent[bot]`.

Once the set is genuinely green:

1. **Commit** the fix and the tests on the working branch (the fix builds on the repro branch, so the reproduction test and the fix land in one reviewable diff). Follow the repo's commit conventions. **Never commit workspace artifacts.** The commit must contain only the fix and its reproduction test — nothing else. In particular, **never** stage or commit the `recordings/` clips or any `.omnigent/` handoff files (e.g. `.omnigent/repro-handoff.json`