Copilot engine 429 on every PR push, and a post-merge docs and index pattern: how to wire this in v0.91.8?

[travroo321]

Context. All our coding is done by Claude Code: the CLI on our own self-hosted Linux server, the desktop app, and Claude Code cloud and Projects sessions. Those sessions open the issues and PRs in our GitHub repo, and a GitHub Project board tracks them. The repo is a markdown wiki plus the scripts that run our operations, and GitHub is the single source of truth that every machine only pulls from. What we're trying to build is an agentic process-management loop: every PR carries a docs tag and a resolution written by the Claude session that made the change, and after the PR merges, a gh-aw workflow picks that up and keeps the documentation, search indexes and system map current, so the upkeep happens after PRs without anyone running it by hand. We use gh-aw (Copilot engine) for that after-PR step, and a self-hosted runner on the same server for the deterministic parts.

We run gh-aw v0.91.8 with engine: copilot (Copilot Pro, a user PAT) on a private repo that is a markdown wiki plus scripts. We want change management to run with nobody touching it, and we are stuck in a few places. Any pointers to the intended pattern would help.

The goal, in one line

A post-merge process documents every change. A Claude Code session makes the change and writes in the PR what it changed and why, with a docs tag. After the PR merges, a gh-aw workflow reads that tag and resolution and does the upkeep with no person involved: it updates or creates the right wiki page (or decides nothing is needed, or flags it), then the search indexes and the system map are rebuilt on GitHub and committed, and every machine just pulls the result.

What "done" looks like:

• No PR merges without a docs tag and a resolution.
• No page is edited by hand; pages change only through this loop.
• Nothing is built on any one machine; derived files are built after merge on GitHub.
• Auto-merge is on, and the whole loop runs without anyone pressing a button.

Who is working on it

We have assigned a team of Claude Code Projects sessions to take on this plan and start the approach. We are open to all help: answers to the questions below, a pointer to an existing pattern, an example repo, or a better way to reach this goal than the one we drew. Thank you.

Setup today

• docs-updater.md runs on pull_request (opened, synchronize, reopened, ready_for_review). A deterministic docs_scan custom job on a self-hosted runner labels the PR docs: needed, docs: no page or docs: ok. When needed, the Copilot agent (on ubuntu-latest) writes or updates wiki pages and pushes them into the PR via safe outputs, with threat detection on.
• docs-auditor.md runs daily and files doc issues.
• pr-checks.yml on the self-hosted runner is the required check (checks) in a ruleset on the default branch. Auto-merge is currently turned off by us until this works end to end.
• Issues are auto-added to a GitHub Project board with the built-in workflows.

Where we are stuck

1. 429 on the Copilot engine. 15 runs in about 25 minutes, then 429 Too Many Requests on every harness attempt (isCAPIQuotaExceededError=false); a re-run 7 minutes later also got 429. The fix for copilot_harness: "Failed to get response from the AI model … Last error: 429 Too Many Requests" misclassified as partial_execution → retries with --continue until timeout #53554 is in v0.91.8, but our logs still show retry attempts 1 to 4, so our message may be a different form. What is the recommended way to run the agent once per PR instead of per push: label_command, dropping synchronize, or user-rate-limit?
2. The design we want. The coding agent writes a "resolution" section in the PR body (what changed and why). The docs agent only reads the docs label plus that resolution and decides: copy it into the matching page, nothing needed, or flag it. It does not have to run right after each push. Is there an existing pattern for "agent reads the PR body and decides copy, skip or flag"?
3. Post-merge derived files. After a merge we want a workflow to rebuild a page index and a BM25 index (and a system map on the self-hosted runner) and commit them to the default branch. The branch has a ruleset with a required status check; GITHUB_TOKEN cannot bypass it, and a PAT push re-triggers workflows. Is "open a PR with a PAT and auto-merge it" the recommended route, or is there a gh-aw-native way?
4. Auto-merge gate. We want auto-merge back on only when checks are green and a final docs label (docs: updated, docs: new or docs: retired) is present. Labels set by GITHUB_TOKEN do not re-fire checks. What is the clean way to make the required check fail closed until the docs label is final?

What does what

Part	Tool	Responsible for
Issues	GitHub Issues + GitHub Project board built-in workflows	work items; auto-add, merged to Done, auto-close
Change	Claude Code sessions (desktop, SSH remote, cloud), claude-code-action on @claude	code changes, PRs
Checks	pr-checks.yml on a self-hosted runner, ruleset	required checks: changelog, page lint, docs gate
Merge	GitHub auto-merge	off for now; merged by hand
Docs	gh-aw docs-updater.md (scan job self-hosted, agent on ubuntu-latest), docs-auditor.md daily	pages pushed into the PR; doc issues
Model	Copilot API (Copilot Pro)	both agents
Indexes and map	scripts on our server today	page index, BM25 index, system map (we want these built after merge on GitHub)
Sync	a server cron pull, a desktop hook pull, cloud clones	every place only pulls the default branch

The flow we are aiming for

graph TD
    O1[Issue opened<br>by a coding session or a workflow] --> T[Issue template<br>tag, resolution, page<br>not built]
    T --> P7[Project board auto-add]
    P7 --> A[Coding session makes the change]
    A --> PR[PR: Closes #n + docs tag + resolution<br>fields not built]
    PR --> B[Required check: needs tag and resolution<br>not built]
    B --> C[Auto-merge<br>off today]
    C --> CL[Issue closes via Closes #n]
    C --> D[gh-aw docs agent, Copilot engine<br>reads tag and resolution, runs on its own time]
    D --> E[BM25 search over committed index]
    E --> F{Match?}
    F -->|moderate| G[Copy or patch into page]
    F -->|high + overwrite| H[Replace page]
    F -->|none / new item| X[New page + tag]
    F -->|no action| I[docs: ok]
    F -->|conflict| J[Flag: new issue]
    X --> G
    G --> K[Docs PR merges]
    H --> K
    K --> R[After-merge build: indexes + map<br>committed to default branch<br>not built]
    R --> M[Default branch]
    M --> S1[Server pulls]
    M --> S2[Cloud clones]
    M --> S3[Desktop pulls]

Loading

Thanks for any guidance, especially on 1 and 3.

[tomm1990]

The 429 is a new Copilot engine start on every synchronize. The v0.91.8 change that classifies that error does not reduce how many starts you launch. PR concurrency with cancel-in-progress only drops the older run. The run for the latest push still calls Copilot, and retries 1 to 4 are that call failing, not a second bug.

user-rate-limit will not cap this while the actor has write. Default ignored-roles is admin, maintain, and write, so your user PAT is exempt. It is also N runs per window per user, not once per PR. label_command is an extra click, and those runs bypass the daily AI credit guardrail, so it is the wrong throttle.

Split the jobs:

1. Keep docs_scan and pr-checks on pull_request (opened, synchronize, ready_for_review). No engine in that workflow. If docs_scan lives inside docs-updater.md, every push still starts Copilot.
2. Start the Copilot workflow once, after merge, and only when the PR body already has the resolution section.

repository_dispatch is one of the two events GITHUB_TOKEN is allowed to fire. Gate workflow:

name: docs-updater-gate
on:
  pull_request:
    types: [closed]
permissions:
  contents: write
jobs:
  dispatch:
    if: github.event.pull_request.merged == true && contains(github.event.pull_request.body, '## Resolution')
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          curl -sS -X POST \
            -H "Authorization: Bearer ${GH_TOKEN}" \
            -H "Accept: application/vnd.github+json" \
            "https://api.github.com/repos/${GITHUB_REPOSITORY}/dispatches" \
            -d "{\"event_type\":\"docs-update\",\"client_payload\":{\"pr_number\":${{ github.event.pull_request.number }}}}"

Use the heading the coding session already writes. ## Resolution above is only the example. Recompile docs-updater.md with:

on:
  repository_dispatch:
    types: [docs-update]

The prompt should read github.event.client_payload.pr_number, then gh pr view that PR, and only copy, skip, or flag. There is no separate resolution API. That is the pattern for question 2.

For the indexes, do not push to main with GITHUB_TOKEN, and do not push to main with a PAT.

• A PR opened with GITHUB_TOKEN does not trigger pull_request workflows, so the required check stays pending and auto-merge never goes green.
• A PAT push to main does re-trigger workflows.

From the self-hosted index job, use a fine-grained PAT or a GitHub App token with contents and pull requests write. Push branch indexes/auto and open a PR with that token. In pr-checks, if github.head_ref == 'indexes/auto', exit 0 so the generated PR is not asked for a resolution section. Auto-merge can then go green.

Stop the loop on the index workflow:

on:
  push:
    branches: [main]
    paths-ignore:
      - 'indexes/**'
      - 'system-map/**'

Merging the index PR only touches those paths, so it does not build again. A docs PR that edits wiki pages still does.

On the label gate: a label applied with GITHUB_TOKEN will not re-run pr-checks. Do not wait for labeled. Fail pr-checks when the body is missing the resolution section. That check already re-runs on synchronize, which is when the coding session updates the body. Keep the docs label as a marker. The required checks are this body check and the docs-updater conclusion, not a second workflow waiting on the label.