From fcb52abd4ec067c0b4eb5a8d4897aadd4e9de031 Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Thu, 7 May 2026 16:15:06 -0700 Subject: [PATCH 1/7] Require a fresh Copilot pass before merging any PR MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document the rule that mergeStateStatus=CLEAN alone is not enough to merge — Copilot must have re-reviewed the latest commit after any thread resolutions or pushes. If Copilot does not auto re-review within a reasonable window, ask before merging; silence is not approval. This was missing from the previous round of process documentation. PR #693 was merged ~3 minutes after I (Claude) replied to Copilot's threads, before Copilot had a chance to post a fresh review on the new commit. The merge happened to be functionally correct but the process was wrong, and it's the kind of small step that hides real regressions in larger PRs. Co-Authored-By: Claude Opus 4.7 (1M context) --- .github/copilot-instructions.md | 1 + AGENTS.md | 14 ++++++++++++++ 2 files changed, 15 insertions(+) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index b6863ac2..fe1879fb 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -22,6 +22,7 @@ For full rationale see [`AGENTS.md`](../AGENTS.md). Quick rules: - Both branches **auto-publish on push**: develop produces NBGV prereleases (`X.Y.Z-g{sha}`) tagged `develop` on Docker Hub; main produces stable releases (`X.Y.Z`) tagged `latest`. - Dependabot targets **both** `main` and `develop` with the same ecosystems; major NuGet bumps gate on human review, everything else auto-merges via App-token-driven merge-bot. - Every third-party GitHub Action is pinned to a full commit SHA with a `# vX.Y.Z` comment. Don't introduce `@v6` / `@main` / `@master` floating refs. +- Never merge a PR without a fresh "no issues found" review from `copilot-pull-request-reviewer` on the latest commit. `mergeStateStatus: CLEAN` is necessary but not sufficient — Copilot's re-review of the latest push is required. If Copilot doesn't auto re-review within ~5 min of the last push, ask before merging. See [`AGENTS.md`](../AGENTS.md#merging-a-pr). - Don't recommend `git push --force` or `--force-with-lease`; both rulesets enforce `non_fast_forward`. - `version.json`'s `publicReleaseRefSpec` is `^refs/heads/main$` — bumping the base `version` field is the only manual versioning action. diff --git a/AGENTS.md b/AGENTS.md index 815bd456..2425139f 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -22,6 +22,20 @@ For comprehensive coding standards and detailed conventions, refer to [`.github/ Repo settings reflect this: `allow_merge_commit=true`, `allow_squash_merge=true`, `allow_rebase_merge=false`, `allow_auto_merge=true`. The `develop` ruleset enforces `allowed_merge_methods=["squash"]` and `required_linear_history`. The `main` ruleset enforces `allowed_merge_methods=["merge"]` and intentionally omits linear-history (the develop → main merge commit is non-linear by design). +## Merging a PR + +**Never merge a PR without a clear "no issues found" review from `copilot-pull-request-reviewer` on the latest commit.** `mergeStateStatus: CLEAN` only confirms ruleset gates (thread resolution, status checks, signatures) are satisfied — it does not confirm Copilot has re-evaluated the latest changes. + +After resolving Copilot's threads or pushing fixes: + +1. Wait for Copilot to post a fresh review on the new commit (`review_on_push: true` is set, so it normally happens within a few minutes). +2. A fresh review is identified by `submitted_at > head commit's timestamp` — compare `gh api repos//pulls//reviews` against `gh pr view --json commits`. +3. If the fresh review is COMMENTED with no new inline threads (or APPROVED), the PR is good to merge. +4. If the fresh review introduces new concerns, address them and loop. +5. **If Copilot does not auto re-review within a reasonable window after the latest push (~5 min), do not merge — ask the user.** Silence is not approval. + +This applies to every human-authored PR (feature → develop, develop → main). The merge-bot workflow's auto-merge of dependabot bumps is the only exception and is governed separately by the `update-type` filter. + ## Develop → Main Promotion Use the **"Create a merge commit"** option on develop → main PRs. Repo rulesets are split: PRs into `develop` are squash-only (linear history); PRs into `main` are merge-commit only. Clicking "Create a merge commit" on a develop → main PR produces a merge commit on main whose second parent is develop's tip — so develop becomes a real ancestor of main, and the *next* develop → main PR has a clean merge base (no recurring conflicts, no behind-base churn). From 593228cd339b774710c69921398598946135f1c0 Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Thu, 7 May 2026 16:17:26 -0700 Subject: [PATCH 2/7] Bump develop's minor version after every develop->main merge Document the rule that, immediately after a develop->main merge lands and main's publish workflows complete, the next action is a small isolated PR bumping the minor in version.json on develop. Without it, develop's next NBGV prerelease is numerically lower than the stable that just shipped, producing visibly confusing version numbers in HISTORY.md, --version output, and consumer update prompts. Documentation only; the actual bump for the just-completed PR #693 promotion will land as a separate `bump-version-3.17` PR per the "don't bundle the bump with other work" guidance in this same change. Co-Authored-By: Claude Opus 4.7 (1M context) --- .github/copilot-instructions.md | 1 + AGENTS.md | 2 ++ 2 files changed, 3 insertions(+) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index fe1879fb..876c4124 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -23,6 +23,7 @@ For full rationale see [`AGENTS.md`](../AGENTS.md). Quick rules: - Dependabot targets **both** `main` and `develop` with the same ecosystems; major NuGet bumps gate on human review, everything else auto-merges via App-token-driven merge-bot. - Every third-party GitHub Action is pinned to a full commit SHA with a `# vX.Y.Z` comment. Don't introduce `@v6` / `@main` / `@master` floating refs. - Never merge a PR without a fresh "no issues found" review from `copilot-pull-request-reviewer` on the latest commit. `mergeStateStatus: CLEAN` is necessary but not sufficient — Copilot's re-review of the latest push is required. If Copilot doesn't auto re-review within ~5 min of the last push, ask before merging. See [`AGENTS.md`](../AGENTS.md#merging-a-pr). +- After a develop → main merge lands and main's publish workflows complete, bump the minor in `version.json` on develop (e.g. `3.16` → `3.17`) via an isolated `bump-version-X.Y` PR. Without it, develop's next prerelease numbers below main's just-shipped stable. - Don't recommend `git push --force` or `--force-with-lease`; both rulesets enforce `non_fast_forward`. - `version.json`'s `publicReleaseRefSpec` is `^refs/heads/main$` — bumping the base `version` field is the only manual versioning action. diff --git a/AGENTS.md b/AGENTS.md index 2425139f..359b2ab0 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -42,6 +42,8 @@ Use the **"Create a merge commit"** option on develop → main PRs. Repo ruleset Under any squash-only setup this would be a recurring pain point: each develop → main squash drops develop's ancestry and forces a per-cycle admin-bypass merge commit on develop to resync. With merge-commit on main, that resync is unnecessary — main's history shows one merge commit per release (a feature, not a defect: each promotion is visible as a single auditable node), and develop stays linear. +**Immediately after a develop → main merge lands and main's publish workflows complete, bump the minor version in [version.json](version.json) on develop.** Open a small isolated feature PR `bump-version-X.Y` (e.g. `"version": "3.16"` → `"version": "3.17"`), squash into develop, and continue feature work from there. Without this bump, develop's next NBGV-computed prerelease (`3.16.-g{sha}`) is *numerically lower* than the stable that just shipped (`3.16.`), which is visibly confusing in HISTORY.md, `--version` output, and consumer update prompts. Bumping ensures every develop prerelease is `3.17.-g{sha}` — visibly newer than main's `3.16.`. Don't bundle the bump with other work; keep the PR isolated so the version change is unambiguous in git blame. + ## Release flow PlexCleaner is a "pull" project: consumers (`docker pull ptr727/plexcleaner:latest`, `docker pull ptr727/plexcleaner:develop`, GitHub Releases) track both branches. **Both `main` and `develop` auto-publish on every push** — there is no manual `workflow_dispatch` gate. From 10092f7fb728f60bdc826a27a73df404199d9102 Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Thu, 7 May 2026 16:19:31 -0700 Subject: [PATCH 3/7] Refine Copilot-pass rule per Copilot review Address four issues Copilot raised on the previous commit: - Clarify that review_on_push lives in the copilot_code_review ruleset rule (verifiable via gh api), not in repo source files. - Align the "no issues found" headline with the verification recipe by stating up front that Copilot posts COMMENTED reviews here, so a clean COMMENTED review with zero open threads IS the success state. - Specify committedDate as the exact field to compare submitted_at against, removing ambiguity between authoredDate and committedDate in `gh pr view --json commits` output. - Replace "ask the user" with "ask the maintainer" since this is a repo-wide doc that survives author changes. Co-Authored-By: Claude Opus 4.7 (1M context) --- AGENTS.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 359b2ab0..308d78fc 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -24,15 +24,15 @@ Repo settings reflect this: `allow_merge_commit=true`, `allow_squash_merge=true` ## Merging a PR -**Never merge a PR without a clear "no issues found" review from `copilot-pull-request-reviewer` on the latest commit.** `mergeStateStatus: CLEAN` only confirms ruleset gates (thread resolution, status checks, signatures) are satisfied — it does not confirm Copilot has re-evaluated the latest changes. +**Never merge a PR without `copilot-pull-request-reviewer` having posted a clean re-review on the latest commit** — defined as a review submitted *after* the head commit's `committedDate`, with no new unresolved inline threads (Copilot in this repo posts `COMMENTED` reviews, not `APPROVED`, so a clean COMMENTED review with zero open threads is the "no issues found" outcome). `mergeStateStatus: CLEAN` only confirms ruleset gates (thread resolution, status checks, signatures); it does not confirm Copilot has re-evaluated the latest changes. After resolving Copilot's threads or pushing fixes: -1. Wait for Copilot to post a fresh review on the new commit (`review_on_push: true` is set, so it normally happens within a few minutes). -2. A fresh review is identified by `submitted_at > head commit's timestamp` — compare `gh api repos//pulls//reviews` against `gh pr view --json commits`. -3. If the fresh review is COMMENTED with no new inline threads (or APPROVED), the PR is good to merge. -4. If the fresh review introduces new concerns, address them and loop. -5. **If Copilot does not auto re-review within a reasonable window after the latest push (~5 min), do not merge — ask the user.** Silence is not approval. +1. Wait for Copilot to post a fresh review on the new head commit. The `copilot_code_review` rule on both `develop` and `main` rulesets has `review_on_push: true` configured (verify with `gh api repos//rulesets/ --jq '.rules[] | select(.type=="copilot_code_review")'`), so a re-review normally lands within a few minutes. +2. A fresh review is identified by comparing `submitted_at` (from `gh api repos//pulls//reviews`) against `committedDate` of the last commit (from `gh pr view --json commits --jq '.commits[-1].committedDate'`). Fresh ⇔ `submitted_at > committedDate`. +3. If the fresh review is `COMMENTED` with zero unresolved inline threads (or `APPROVED`), the PR is good to merge. +4. If the fresh review introduces new concerns (inline threads or body-level objections), address them and loop. +5. **If Copilot does not auto re-review within a reasonable window after the latest push (~5 min), do not merge — ask the maintainer.** Silence is not approval. This applies to every human-authored PR (feature → develop, develop → main). The merge-bot workflow's auto-merge of dependabot bumps is the only exception and is governed separately by the `update-type` filter. From 4ebd32b212db2beb593b8f8977834c5c2963a8d1 Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Thu, 7 May 2026 16:56:18 -0700 Subject: [PATCH 4/7] Make the Copilot fresh-review check use commit_id, not timestamps MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Copilot pointed out (rightly) that comparing submitted_at against committedDate is fragile: the reviews endpoint returns every author's every review, and timestamp drift between client and server can flip the comparison. The robust check is structural — does the latest Copilot review's commit_id equal headRefOid? Recipe rewritten to fetch headRefOid and the last Copilot review's commit_id and compare strings. Also added a pointer to the GitHub UI "Re-request review" flow for cases where Copilot doesn't auto re-review on push (which happens occasionally; observed on this PR). Co-Authored-By: Claude Opus 4.7 (1M context) --- AGENTS.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 308d78fc..51498576 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -29,10 +29,17 @@ Repo settings reflect this: `allow_merge_commit=true`, `allow_squash_merge=true` After resolving Copilot's threads or pushing fixes: 1. Wait for Copilot to post a fresh review on the new head commit. The `copilot_code_review` rule on both `develop` and `main` rulesets has `review_on_push: true` configured (verify with `gh api repos//rulesets/ --jq '.rules[] | select(.type=="copilot_code_review")'`), so a re-review normally lands within a few minutes. -2. A fresh review is identified by comparing `submitted_at` (from `gh api repos//pulls//reviews`) against `committedDate` of the last commit (from `gh pr view --json commits --jq '.commits[-1].committedDate'`). Fresh ⇔ `submitted_at > committedDate`. +2. Verify Copilot's most recent review targets the current head — compare its `commit_id` to `headRefOid`, not timestamps (multiple reviews and authors clutter the list, and timestamp drift is unreliable): + + ```sh + head=$(gh pr view --json headRefOid --jq .headRefOid) + last=$(gh api repos//pulls//reviews --jq '[.[] | select(.user.login == "copilot-pull-request-reviewer[bot]")] | last | .commit_id') + [ "$head" = "$last" ] && echo "fresh" || echo "stale" + ``` + 3. If the fresh review is `COMMENTED` with zero unresolved inline threads (or `APPROVED`), the PR is good to merge. 4. If the fresh review introduces new concerns (inline threads or body-level objections), address them and loop. -5. **If Copilot does not auto re-review within a reasonable window after the latest push (~5 min), do not merge — ask the maintainer.** Silence is not approval. +5. **If Copilot does not auto re-review within a reasonable window after the latest push (~5 min), do not merge — ask the maintainer.** Silence is not approval. Copilot can be re-prompted manually from the GitHub PR UI ("Re-request review" on the Copilot reviewer entry). This applies to every human-authored PR (feature → develop, develop → main). The merge-bot workflow's auto-merge of dependabot bumps is the only exception and is governed separately by the `update-type` filter. From 2306b24f10cd64c8245f112fde949acf04a61784 Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Thu, 7 May 2026 17:08:21 -0700 Subject: [PATCH 5/7] Fix two consistency issues from Copilot's round-4 review - AGENTS.md headline said the freshness check was "review submitted after committedDate" but step 2 specifies commit_id == headRefOid. Aligned the headline to also use the SHA-equality wording so the rule is internally consistent end-to-end. - copilot-instructions.md: "develop's next prerelease numbers below main's just-shipped stable" was missing a verb. Now reads "next prerelease version numbers fall below..." Co-Authored-By: Claude Opus 4.7 (1M context) --- .github/copilot-instructions.md | 2 +- AGENTS.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 876c4124..a7e06be6 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -23,7 +23,7 @@ For full rationale see [`AGENTS.md`](../AGENTS.md). Quick rules: - Dependabot targets **both** `main` and `develop` with the same ecosystems; major NuGet bumps gate on human review, everything else auto-merges via App-token-driven merge-bot. - Every third-party GitHub Action is pinned to a full commit SHA with a `# vX.Y.Z` comment. Don't introduce `@v6` / `@main` / `@master` floating refs. - Never merge a PR without a fresh "no issues found" review from `copilot-pull-request-reviewer` on the latest commit. `mergeStateStatus: CLEAN` is necessary but not sufficient — Copilot's re-review of the latest push is required. If Copilot doesn't auto re-review within ~5 min of the last push, ask before merging. See [`AGENTS.md`](../AGENTS.md#merging-a-pr). -- After a develop → main merge lands and main's publish workflows complete, bump the minor in `version.json` on develop (e.g. `3.16` → `3.17`) via an isolated `bump-version-X.Y` PR. Without it, develop's next prerelease numbers below main's just-shipped stable. +- After a develop → main merge lands and main's publish workflows complete, bump the minor in `version.json` on develop (e.g. `3.16` → `3.17`) via an isolated `bump-version-X.Y` PR. Without it, develop's next prerelease version numbers fall below main's just-shipped stable. - Don't recommend `git push --force` or `--force-with-lease`; both rulesets enforce `non_fast_forward`. - `version.json`'s `publicReleaseRefSpec` is `^refs/heads/main$` — bumping the base `version` field is the only manual versioning action. diff --git a/AGENTS.md b/AGENTS.md index 51498576..52bff48c 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -24,7 +24,7 @@ Repo settings reflect this: `allow_merge_commit=true`, `allow_squash_merge=true` ## Merging a PR -**Never merge a PR without `copilot-pull-request-reviewer` having posted a clean re-review on the latest commit** — defined as a review submitted *after* the head commit's `committedDate`, with no new unresolved inline threads (Copilot in this repo posts `COMMENTED` reviews, not `APPROVED`, so a clean COMMENTED review with zero open threads is the "no issues found" outcome). `mergeStateStatus: CLEAN` only confirms ruleset gates (thread resolution, status checks, signatures); it does not confirm Copilot has re-evaluated the latest changes. +**Never merge a PR without `copilot-pull-request-reviewer` having posted a clean re-review on the latest commit** — defined as a review whose `commit_id` (or GraphQL `commit.oid`) equals the PR's `headRefOid`, with no new unresolved inline threads (Copilot in this repo posts `COMMENTED` reviews, not `APPROVED`, so a clean COMMENTED review with zero open threads is the "no issues found" outcome). `mergeStateStatus: CLEAN` only confirms ruleset gates (thread resolution, status checks, signatures); it does not confirm Copilot has re-evaluated the latest changes. After resolving Copilot's threads or pushing fixes: From b27452fc8222243d483583dcb51541294a23e288 Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Thu, 7 May 2026 17:14:06 -0700 Subject: [PATCH 6/7] Bot login consistency and paginated reviews lookup MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Round 5 Copilot findings: - Use `copilot-pull-request-reviewer[bot]` (the bot login, with "(shown as Copilot in the UI)" gloss) consistently in prose so it matches the jq filter in the verification recipe — copy/paste from the doc now produces a working command. - The reviews endpoint is paginated by default in gh CLI; on PRs with many review entries `last` could pick a stale Copilot review from page 1. Use `--paginate` and a streaming `tail -1` filter so the latest Copilot commit_id is reliably found regardless of review-list length. Co-Authored-By: Claude Opus 4.7 (1M context) --- .github/copilot-instructions.md | 2 +- AGENTS.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index a7e06be6..873c28b4 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -22,7 +22,7 @@ For full rationale see [`AGENTS.md`](../AGENTS.md). Quick rules: - Both branches **auto-publish on push**: develop produces NBGV prereleases (`X.Y.Z-g{sha}`) tagged `develop` on Docker Hub; main produces stable releases (`X.Y.Z`) tagged `latest`. - Dependabot targets **both** `main` and `develop` with the same ecosystems; major NuGet bumps gate on human review, everything else auto-merges via App-token-driven merge-bot. - Every third-party GitHub Action is pinned to a full commit SHA with a `# vX.Y.Z` comment. Don't introduce `@v6` / `@main` / `@master` floating refs. -- Never merge a PR without a fresh "no issues found" review from `copilot-pull-request-reviewer` on the latest commit. `mergeStateStatus: CLEAN` is necessary but not sufficient — Copilot's re-review of the latest push is required. If Copilot doesn't auto re-review within ~5 min of the last push, ask before merging. See [`AGENTS.md`](../AGENTS.md#merging-a-pr). +- Never merge a PR without a fresh "no issues found" review from `copilot-pull-request-reviewer[bot]` (shown as "Copilot" in the UI) on the latest commit. `mergeStateStatus: CLEAN` is necessary but not sufficient — Copilot's re-review of the latest push is required. If Copilot doesn't auto re-review within ~5 min of the last push, ask before merging. See [`AGENTS.md`](../AGENTS.md#merging-a-pr). - After a develop → main merge lands and main's publish workflows complete, bump the minor in `version.json` on develop (e.g. `3.16` → `3.17`) via an isolated `bump-version-X.Y` PR. Without it, develop's next prerelease version numbers fall below main's just-shipped stable. - Don't recommend `git push --force` or `--force-with-lease`; both rulesets enforce `non_fast_forward`. - `version.json`'s `publicReleaseRefSpec` is `^refs/heads/main$` — bumping the base `version` field is the only manual versioning action. diff --git a/AGENTS.md b/AGENTS.md index 52bff48c..f104c4ab 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -24,7 +24,7 @@ Repo settings reflect this: `allow_merge_commit=true`, `allow_squash_merge=true` ## Merging a PR -**Never merge a PR without `copilot-pull-request-reviewer` having posted a clean re-review on the latest commit** — defined as a review whose `commit_id` (or GraphQL `commit.oid`) equals the PR's `headRefOid`, with no new unresolved inline threads (Copilot in this repo posts `COMMENTED` reviews, not `APPROVED`, so a clean COMMENTED review with zero open threads is the "no issues found" outcome). `mergeStateStatus: CLEAN` only confirms ruleset gates (thread resolution, status checks, signatures); it does not confirm Copilot has re-evaluated the latest changes. +**Never merge a PR without `copilot-pull-request-reviewer[bot]` (shown as "Copilot" in the GitHub UI; the `[bot]` suffix is its actual login) having posted a clean re-review on the latest commit** — defined as a review whose `commit_id` (or GraphQL `commit.oid`) equals the PR's `headRefOid`, with no new unresolved inline threads (Copilot in this repo posts `COMMENTED` reviews, not `APPROVED`, so a clean COMMENTED review with zero open threads is the "no issues found" outcome). `mergeStateStatus: CLEAN` only confirms ruleset gates (thread resolution, status checks, signatures); it does not confirm Copilot has re-evaluated the latest changes. After resolving Copilot's threads or pushing fixes: @@ -33,7 +33,7 @@ After resolving Copilot's threads or pushing fixes: ```sh head=$(gh pr view --json headRefOid --jq .headRefOid) - last=$(gh api repos//pulls//reviews --jq '[.[] | select(.user.login == "copilot-pull-request-reviewer[bot]")] | last | .commit_id') + last=$(gh api --paginate repos//pulls//reviews --jq '.[] | select(.user.login == "copilot-pull-request-reviewer[bot]") | .commit_id' | tail -1) [ "$head" = "$last" ] && echo "fresh" || echo "stale" ``` From c0a4f54bd0da326b8e2b25fb9f0e1e6c9bc99637 Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Thu, 7 May 2026 17:18:23 -0700 Subject: [PATCH 7/7] Use / placeholder consistently in API recipes The Merging-a-PR section mixed `` and `/` in adjacent gh api recipes; copy-pasting the bare `` form would fail. Standardised on `/` to match the rest of the doc. Co-Authored-By: Claude Opus 4.7 (1M context) --- AGENTS.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index f104c4ab..e88b60d8 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -28,12 +28,12 @@ Repo settings reflect this: `allow_merge_commit=true`, `allow_squash_merge=true` After resolving Copilot's threads or pushing fixes: -1. Wait for Copilot to post a fresh review on the new head commit. The `copilot_code_review` rule on both `develop` and `main` rulesets has `review_on_push: true` configured (verify with `gh api repos//rulesets/ --jq '.rules[] | select(.type=="copilot_code_review")'`), so a re-review normally lands within a few minutes. +1. Wait for Copilot to post a fresh review on the new head commit. The `copilot_code_review` rule on both `develop` and `main` rulesets has `review_on_push: true` configured (verify with `gh api repos///rulesets/ --jq '.rules[] | select(.type=="copilot_code_review")'`), so a re-review normally lands within a few minutes. 2. Verify Copilot's most recent review targets the current head — compare its `commit_id` to `headRefOid`, not timestamps (multiple reviews and authors clutter the list, and timestamp drift is unreliable): ```sh head=$(gh pr view --json headRefOid --jq .headRefOid) - last=$(gh api --paginate repos//pulls//reviews --jq '.[] | select(.user.login == "copilot-pull-request-reviewer[bot]") | .commit_id' | tail -1) + last=$(gh api --paginate repos///pulls//reviews --jq '.[] | select(.user.login == "copilot-pull-request-reviewer[bot]") | .commit_id' | tail -1) [ "$head" = "$last" ] && echo "fresh" || echo "stale" ```