From d328f7474be75a13c2c71f0dca26ff6829b8baf0 Mon Sep 17 00:00:00 2001 From: functionstackx <47992694+functionstackx@users.noreply.github.com> Date: Mon, 18 May 2026 03:00:43 -0400 Subject: [PATCH] AGENTS: note sweep doesn't trigger while a PR has merge conflicts MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A stale claude/* or update-* branch with a perf-changelog.yaml conflict (most common case) sits in NO_SWEEP / NO_SUCCESS even when sweep-enabled or full-sweep-enabled is applied — the run-sweep.yml workflow needs the PR to cleanly merge into main first. Adds a paragraph under "Pull Request Sweep Labels" pointing at the existing canonical resolution recipe in KLAUD_DEBUG.md §1.1. Co-Authored-By: Claude Opus 4.7 (1M context) --- AGENTS.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 3e4247e2a..cd057f4d3 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -64,6 +64,8 @@ PRs do not run the sweep automatically - `run-sweep.yml` is gated on a label. Pi - `sweep-enabled` - runs the sweep with `--trim-conc` (each parallelism config reduced to its single highest concurrency). Default for most PRs. - `full-sweep-enabled` - runs the full intermediate concurrency sweep, identical to push-to-main. Use when intermediate points matter (e.g. a recipe change shifts the throughput/latency curve, not just its endpoints). +**The sweep does not trigger while the PR has merge conflicts.** Even with `sweep-enabled` / `full-sweep-enabled` applied, the `run-sweep.yml` workflow will not start until the PR cleanly merges into main — a stale claude/* or update-* branch with a `perf-changelog.yaml` conflict (the common case) will sit in NO_SWEEP / NO_SUCCESS until rebased. Resolution recipe is documented in `KLAUD_DEBUG.md §1.1`: `git merge origin/main`, then `git checkout origin/main -- perf-changelog.yaml`, then re-append the PR's own changelog entry at the tail. Don't 3-way merge `perf-changelog.yaml`; whitespace edits silently re-trigger the deletion check. + Push-to-main always runs the full untrimmed sweep unless `[skip-sweep]` is in the commit message. Trim logic lives in `trim_conc()` in `utils/process_changelog.py`: single-node entries are grouped by every non-`conc` field and only the highest-`conc` entry per group is kept; multi-node entries have their `conc` list collapsed to `[max(conc)]`. ## Common Tasks